WEB案例开发第2章-AscentWeb医药商务系统课件.ppt
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《WEB案例开发第2章-AscentWeb医药商务系统课件.ppt》由用户(晟晟文业)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- WEB 案例 开发 AscentWeb 医药 商务 系统 课件
- 资源描述:
-
1、第2 2章 AscentWeb AscentWeb医药商务系统 学习目的与要求 本章主要介绍软件统一开发流程RUP,软件统一建模语言UML。并详细阐述了AscentWeb医药商务系统项目概况及项目的需求与UML建模。通过本章学习你能够:了解RUP软件统一开发流程。了解UML统一建模技术。通过AscentWeb医药商务系统项目实践掌握UML建模技术。本章主要内容RUP:包括RUP软件统一开发流程工作阶段和核心工作流。UML:UML统一建模技术。AscentWeb医药商务系统:项目开发背景,项目需求分析与设计建模。2.1 2.1 项目开发背景知识 2.1.1 项目开发流程2.1.1 2.1.1 项
2、目开发流程统 一 开 发 流 程RUP(Rational Unified Process)统一开发流程RUPRUP从纵向来看,项目的生命周期或工作流包括项目需求分析、系统分析和设计、实现、测试和维护。从横向来看,项目开发可以分为四个阶段:起始(Inception),细化(Elaboration),建造(Construction)和移交(transition)。每个阶段都包括一次或者多次的迭代。在每次迭代中,您根据不同的要求或工作流(如需求、分析和设计等)投入不同的工作量。项目生命周期 (1)项目需求分析 需求分析阶段的活动包括:定义潜在的角色(角色指使用系统的人,以及与系统相互作用的软、硬件环
3、境);识别问题域中的对象和关系,以及基于需求规范说明和角色的需要发现用例(use case)和详细描述用例。(2)系统分析和设计 系统分析阶段是基于问题和用户需求的描述,建立现实世界的计算机实现模型。系统设计是结合问题域的知识和目标系统的体系结构(求解域),将目标系统分解为子系统;之后基于分析模型添加细节,完成系统设计。项目生命周期 (3)实现又称编码或开发阶段,也就是将设计转换为特定的编程语言或硬件,同时保持先进性、灵活性和可扩展性。在这个阶段,设计阶段的类被转换为使用面向对象编程语言编制(不推荐使用过程语言)的实际代码。这一任务可能比较困难,也可能比较容易,主要取决于所使用的编程语言本身的
4、能力。(4)测试和维护测试是检验系统是否满足用户功能需求以便增加用户对系统的信心。系统经过测试后整个开发流程告一段落,进入运行维护或新的功能扩展时期。项目开发阶段 (1)起始阶段(The Inception Phase)对于新的开发项目来说,起始阶段是很重要的。在项目继续进行前,我们必须处理重要的业务与需求风险。对于那些增强现有系统的项目,起始阶段是比较短暂的,但是其目的仍是确定该项目的实施价值及可行性。起始阶段有4个重要活动:制定项目的范围 计划并准备业务案例 综合分析,得出备选构架 准备项目环境项目开发阶段 (2)细化阶段(The Elaboration Phase)细化阶段的目标是为系统
5、构架设立基线(baseline),为在构建阶段开展的大量的设计与实施工作打下坚实的基础。构架是通过考虑最重要的需求与评估风险演进而来的。构架的稳定性是通过一个或多个构架原型(prototype)进行评估的。项目开发阶段 (3)构建阶段(The Construction Phase)构建阶段的目标是完成系统开发。构建阶段从某种意义上来看是一个制造过程,其中重点工作就是管理资源、控制操作,以优化成本、日程和质量。因此,在此阶段,管理理念应该进行一个转换:从起始阶段和细化阶段的知识产品开发转换到构建和交付阶段的部署产品的开发。构建阶段的每次迭代都具有三个关键活动:管理资源与控制过程开发与测试组件对迭
6、代进行评估项目开发阶段 (4)交付阶段(The Transition Phase)交付阶段的焦点就是确保软件对于最终用户是可用的。交付阶段包括为发布应用而进行的产品测试,在用户反馈的基础上做微小的调整等内容。在生命周期的这个时刻,用户反馈主要集中在精确调整产品、配置、安装,以及可用性等问题上。交付阶段的关键活动如下:确定最终用户支持资料 在用户的环境中测试可交付的产品基于用户反馈精确调整产品向最终用户交付最终产品2.1.1 2.1.1 项目开发流程极限编程(eXtreme Programming,简称XP)极限编程是一套能快速开发高质量软件所需的价值观、原则和活动的集合,使软件能以尽可能快的速
7、度开发出来并向客户提供最高的效益。XP在很多方面都和传统意义上得软件工程不同,同时,它也和传统得管理和项目计划得方法不同。这些方法在软件工程和其他管理活动中都有借鉴意义。2.1.1 2.1.1 项目开发流程XP具有12个过程,只有完全使用12个过程才是真正使用了XP,只是简单使用了其中一个方法并不代表使用了XP。现场客户(On-site Customer)计划博弈(Planning Game)系统隐喻(System Design)简化设计(Simple Design)集体拥有代码(Collective Code Ownership)结对编程(Pair Programming)测试驱动(Test
8、-driver)小型发布(Small Release)重构(Refactoring)持续集成(Continous integration)每周40小时工作制(40-hour Weeks)代码规范(Coding Standards)2.1.1 2.1.1 项目开发流程下面是极限编程的有效实践:完整团队 XP项目的所有参与者(开发人员、客户、测试人员等)一起工作在一个开放的场所中,他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。计划游戏计划是持续的、循序渐进的。每2周,开发人员就为下2周估算候选特性的成本,而客户则根据成本和商务价值来选择要实现的
9、特性。客户测试作为选择每个所期望的特性的一部分,客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。2.1.1 2.1.1 项目开发流程下面是极限编程的有效实践:简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试,不包含任何重复,表达出了编写者想表达的所有东西,并且包含尽可能少的代码。结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。测试驱动开发编写单元测试是一个验证行为,更是一个设计行为。同样,它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环,尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作,他们先增加一个失败的测试,
10、然后使之通过。2.1.1 2.1.1 项目开发流程下面是极限编程的有效实践:改进设计随时利用重构方法改进已经腐化的代码,保持代码尽可能的干净、具有表达力。持续集成团队总是使系统完整地被集成。一个人拆入(Check in)后,其它所有人责任代码集成。集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责,每个人都可以参与任何其它方面的开发。2.1.1 2.1.1 项目开发流程下面是极限编程的有效实践:编码标准 系统中所有的代码看起来就好像是被单独一人编写的。隐喻 将整个系统联系在一起的全局视图;它是系统的未来影像,是它使得所有单独模块的位置和外观
11、变得明显直观。如果模块的外观与整个隐喻不符,那么你就知道该模块是错误的。可持续的速度 团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作,他们保存精力,他们把项目看作是马拉松长跑,而不是全速短跑。极限编程是一组简单、具体的实践,这些实践结合在形成了一个敏捷开发过程。2.1.2 UML2.1.2 UML概述UML(Unified Modeling Language)是实)是实现项目开发流程的一个重要工具。它是一套可视化现项目开发流程的一个重要工具。它是一套可视化建模语言,由各种图来表达。图就是用来显示各种建模语言,由各种图来表达。图就是用来显示各种模型元素符号的实际图形,这些元素经过特
12、定的排模型元素符号的实际图形,这些元素经过特定的排列组合来阐明系统的某个特定部分或方面。一般来列组合来阐明系统的某个特定部分或方面。一般来说,一个系统模型拥有多个不同类型的图。一个图说,一个系统模型拥有多个不同类型的图。一个图是某个特定视图的一部分。通常,图是被分配给视是某个特定视图的一部分。通常,图是被分配给视图来绘制的。另外,根据图中显示的内容,某些图图来绘制的。另外,根据图中显示的内容,某些图可以是多个不同视图的组成部分。可以是多个不同视图的组成部分。2.1.2 UML2.1.2 UML概述2.1.2 UML2.1.2 UML概述用例图(Use-case DiagramUse-case
13、Diagram)用例图(Use-case Diagram)显示多个外部参与者,以及他们与系统之间的交互和连接。一个用例是对系统提供的某个功能(该系统的一个特定用法)的描述。虽然实际的用例通常用普通文本来描述,但是也可以利用一个活动图来描述用例。用例仅仅描述系统参与者从外部通过对系统的观察而得到的那些功能,并不描述这些功能在系统内部是如何实现的。也就是说,用例定义系统的功能需求。用例图(Use-case DiagramUse-case Diagram)一个超市系统的用例图 Buy ItemsLog InCustomerRefund Purchased ItemsCashier类图(Class D
14、iagram)类图(Class Diagram)用来显示系统中各个类的静态结构。类代表系统内处理的事物。这些类可以以多种方式相互连接在一起,包括关联(类互相连接)、依赖(一个类依赖/使用另一个类)、特殊化(一个类是另一个类的特化)或者打包(多个类组合为一个单元)。所有的这些关系连同每个类的内部结构都在类图中显示。其中,一个类的内部结构是用该类的属性和操作表示的。因为类图所描述的结构在系统生命周期的任何一处都是有效的,所以通常认为类图是静态的。类图(Class Diagram)旅馆系统的类图 对象图(Object Diagram)对象图(Object Diagram)是类图的一个变体,它使用的符
15、号与类图几乎一样。对象图和类图之间的区别是:对象图用于显示类的多个对象实例,而不是实际的类。所以,对象图就是类图的一个实例,显示系统执行时的一个可能的快照在某一时间点上系统可能呈现的样子。虽然对象图使用与类图相同的符号,但是有两处例外:用带下划线的对象名称来表示对象和显示一个关系中的所有实例。对象图(Object Diagram)显示类的类图和显示类的实例的对象图 状态图(State Diagram)状态图(State Diagram)是对类的描述的补充。它用于显示类的对象可能具备的所有状态,以及那些引起状态改变的事件。对象的一个事件可以是另一个对象向其发送的消息,例如到了某个指定的时刻,或者
16、已经满足了某条件。状态的变化称之为转换(Transition)。一个转换也可以有一个与之相连的动作,后者用以指定完成该状态转换应该执行的操作。状态图(State Diagram)电梯系统的状态图 序列图(Sequence DiagramSequence Diagram)序列图(Sequence Diagram)显示多个对象之间的动态协作。序列图重点是显示对象之间发送的消息的时间顺序。它也显示对象之间的交互,也就是在系统执行时,某个指定时间点将发生的事情。序列图由多个用垂直线显示的对象组成,图中时间从上到下推移,并且序列图显示对象之间随着时间的推移而交换的消息或函数。消息是用带消息箭头的直线表示
17、的,并且它位于垂直对象线之间。时间说明以及其他注释放到一个脚本中,并将其放置在顺序图的页边空白处。序列图(Sequence DiagramSequence Diagram)打印服务器的序列图 协作图(Collaboration Diagram)协作图(Collaboration Diagram)像顺序图一样显示动态协作。为了显示一个协作,通常需要在顺序图和协作图之间做选择。除了显示消息的交换(称之为交互)以外,协作图也显示对象以及它们之间的关系(上下文)。通常,选择序列图还是协作图的决定条件是:如果时间或顺序是需要重点强调的方面,那么选择序列图;如果上下文是需要重点强调的方面,那么选择协作图。
展开阅读全文