WEB案例开发第2章-AscentWeb医药商务系统

第2章AscentWeb医药商务系统学习目的与要求本章主要介绍软件统一开发流程RUP，软件统一建模语言UML。并详细阐述了AscentWeb医药商务系统项目概况及项目的需求与UML建模。通过本章学习你能够：•了解RUP软件统一开发流程。•了解UML统一建模技术。•通过AscentWeb医药商务系统项目实践掌握UML建模技术。本章主要内容RUP：包括RUP软件统一开发流程工作阶段和核心工作流。UML：UML统一建模技术。AscentWeb医药商务系统：项目开发背景，项目需求分析与设计建模。2.1项目开发背景知识2.1.1项目开发流程2.1.1项目开发流程统一开发流程RUP（RationalUnifiedProcess）统一开发流程RUP从纵向来看，项目的生命周期或工作流包括项目需求分析、系统分析和设计、实现、测试和维护。从横向来看，项目开发可以分为四个阶段：起始（Inception），细化（Elaboration），建造（Construction）和移交（transition）。每个阶段都包括一次或者多次的迭代。在每次迭代中，您根据不同的要求或工作流（如需求、分析和设计等）投入不同的工作量。项目生命周期（1）项目需求分析需求分析阶段的活动包括：定义潜在的角色（角色指使用系统的人，以及与系统相互作用的软、硬件环境）；识别问题域中的对象和关系，以及基于需求规范说明和角色的需要发现用例（usecase）和详细描述用例。（2）系统分析和设计系统分析阶段是基于问题和用户需求的描述，建立现实世界的计算机实现模型。系统设计是结合问题域的知识和目标系统的体系结构（求解域），将目标系统分解为子系统；之后基于分析模型添加细节，完成系统设计。项目生命周期（3）实现•又称编码或开发阶段，也就是将设计转换为特定的编程语言或硬件，同时保持先进性、灵活性和可扩展性。在这个阶段，设计阶段的类被转换为使用面向对象编程语言编制（不推荐使用过程语言）的实际代码。这一任务可能比较困难，也可能比较容易，主要取决于所使用的编程语言本身的能力。（4）测试和维护•测试是检验系统是否满足用户功能需求以便增加用户对系统的信心。系统经过测试后整个开发流程告一段落，进入运行维护或新的功能扩展时期。项目开发阶段（1）起始阶段（TheInceptionPhase）对于新的开发项目来说，起始阶段是很重要的。在项目继续进行前，我们必须处理重要的业务与需求风险。对于那些增强现有系统的项目，起始阶段是比较短暂的，但是其目的仍是确定该项目的实施价值及可行性。起始阶段有4个重要活动：制定项目的范围计划并准备业务案例综合分析，得出备选构架准备项目环境项目开发阶段（2）细化阶段（TheElaborationPhase）细化阶段的目标是为系统构架设立基线（baseline），为在构建阶段开展的大量的设计与实施工作打下坚实的基础。构架是通过考虑最重要的需求与评估风险演进而来的。构架的稳定性是通过一个或多个构架原型（prototype）进行评估的。项目开发阶段（3）构建阶段（TheConstructionPhase）构建阶段的目标是完成系统开发。构建阶段从某种意义上来看是一个制造过程，其中重点工作就是管理资源、控制操作，以优化成本、日程和质量。因此，在此阶段，管理理念应该进行一个转换：从起始阶段和细化阶段的知识产品开发转换到构建和交付阶段的部署产品的开发。构建阶段的每次迭代都具有三个关键活动：•管理资源与控制过程•开发与测试组件•对迭代进行评估项目开发阶段（4）交付阶段（TheTransitionPhase）交付阶段的焦点就是确保软件对于最终用户是可用的。交付阶段包括为发布应用而进行的产品测试，在用户反馈的基础上做微小的调整等内容。在生命周期的这个时刻，用户反馈主要集中在精确调整产品、配置、安装，以及可用性等问题上。交付阶段的关键活动如下：•确定最终用户支持资料•在用户的环境中测试可交付的产品•基于用户反馈精确调整产品•向最终用户交付最终产品2.1.1项目开发流程极限编程（eXtremeProgramming,简称XP）极限编程是一套能快速开发高质量软件所需的价值观、原则和活动的集合，使软件能以尽可能快的速度开发出来并向客户提供最高的效益。XP在很多方面都和传统意义上得软件工程不同，同时，它也和传统得管理和项目计划得方法不同。这些方法在软件工程和其他管理活动中都有借鉴意义。2.1.1项目开发流程XP具有12个过程，只有完全使用12个过程才是真正使用了XP，只是简单使用了其中一个方法并不代表使用了XP。现场客户（On-siteCustomer）计划博弈（PlanningGame）系统隐喻（SystemDesign）简化设计（SimpleDesign）集体拥有代码（CollectiveCodeOwnership）结对编程（PairProgramming）测试驱动（Test-driver）小型发布（SmallRelease）重构（Refactoring）持续集成（Continousintegration）每周40小时工作制（40-hourWeeks）代码规范（CodingStandards）2.1.1项目开发流程下面是极限编程的有效实践：•完整团队XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。•计划游戏计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。•客户测试作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。2.1.1项目开发流程下面是极限编程的有效实践：•简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。•结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。•测试驱动开发编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。2.1.1项目开发流程下面是极限编程的有效实践：•改进设计随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。•持续集成团队总是使系统完整地被集成。一个人拆入（Checkin）后，其它所有人责任代码集成。•集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。2.1.1项目开发流程下面是极限编程的有效实践：•编码标准系统中所有的代码看起来就好像是被单独一人编写的。•隐喻将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。•可持续的速度团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。极限编程是一组简单、具体的实践，这些实践结合在形成了一个敏捷开发过程。2.1.2UML概述UML（UnifiedModelingLanguage）是实现项目开发流程的一个重要工具。它是一套可视化建模语言，由各种图来表达。图就是用来显示各种模型元素符号的实际图形，这些元素经过特定的排列组合来阐明系统的某个特定部分或方面。一般来说，一个系统模型拥有多个不同类型的图。一个图是某个特定视图的一部分。通常，图是被分配给视图来绘制的。另外，根据图中显示的内容，某些图可以是多个不同视图的组成部分。2.1.2UML概述图具体分为静态模型和动态模型两大类。其中静态模型包括：用例图（UsecaseDiagrams）类图（ClassDiagrams）对象图（ObjectDiagrams）组件图（ComponentDiagrams）部署图（DeploymentDiagrams）2.1.2UML概述动态模型包括：序列图（SequenceDiagrams）协作图（CollaborationDiagrams）状态图（StateChartDiagrams）行为图（ActivityDiagrams）用例图（Use-caseDiagram）用例图（Use-caseDiagram）显示多个外部参与者，以及他们与系统之间的交互和连接。一个用例是对系统提供的某个功能（该系统的一个特定用法）的描述。虽然实际的用例通常用普通文本来描述，但是也可以利用一个活动图来描述用例。用例仅仅描述系统参与者从外部通过对系统的观察而得到的那些功能，并不描述这些功能在系统内部是如何实现的。也就是说，用例定义系统的功能需求。用例图（Use-caseDiagram）一个超市系统的用例图BuyItemsLogInCustomerRefundPurchasedItemsCashier类图（ClassDiagram）类图（ClassDiagram）用来显示系统中各个类的静态结构。类代表系统内处理的事物。这些类可以以多种方式相互连接在一起，包括关联（类互相连接）、依赖（一个类依赖/使用另一个类）、特殊化（一个类是另一个类的特化）或者打包（多个类组合为一个单元）。所有的这些关系连同每个类的内部结构都在类图中显示。其中，一个类的内部结构是用该类的属性和操作表示的。因为类图所描述的结构在系统生命周期的任何一处都是有效的，所以通常认为类图是静态的。类图（ClassDiagram）旅馆系统的类图对象图（ObjectDiagram）对象图（ObjectDiagram）是类图的一个变体，它使用的符号与类图几乎一样。对象图和类图之间的区别是：对象图用于显示类的多个对象实例，而不是实际的类。所以，对象图就是类图的一个实例，显示系统执行时的一个可能的快照——在某一时间点上系统可能呈现的样子。虽然对象图使用与类图相同的符号，但是有两处例外：用带下划线的对象名称来表示对象和显示一个关系中的所有实例。对象图（ObjectDiagram）显示类的类图和显示类的实例的对象图状态图（StateDiagram）状态图（StateDiagram）是对类的描述的补充。它用于显示类的对象可能具备的所有状态，以及那些引起状态改变的事件。对象的一个事件可以是另一个对象向其发送的消息，例如到了某个指定的时刻，或者已经满足了某条件。状态的变化称之为转换（Transition）。一个转换也可以有一个与之相连的动作，后者用以指定完成该状态转换应该执行的操作。状态图（StateDiagram）电梯系统的状态图序列图（SequenceDiagram）序列图（SequenceDiagram）显示多个对象之间的动态协作。序列图重点是显示对象之间发送的消息的时间顺序。它也显示对象之间的交互，也就是在系统执行时，某个指定时间点将发生的事情。序列图由多个用垂直线显示的对象组成，图中时间从上到下推移，并且序列图显示对象之间随着时间的推移而交换的消息或函数。消息是用带消息箭头的直线表示的，并且它位于垂直对象线之间。时间说明以及其他注释放到一个脚本中，并将其放置在顺序图的页边空白处。序列图（SequenceDiagram）打印服务器的序列图协作图（CollaborationDiagram）协作图（CollaborationDiagram）像顺序图一样显示动态协作。为了显示一个协作，通常需要在顺序图和协作图之间做选择。除了显示消息的交换（称之为交互）以外，协作图也显示对象以及它们之间的关系（上下文）。通常，选择序列图还是协作图的决定条件是：如果时间或顺序是需要重点强调的方面，那么选择序列图；如果上下文是需要重点强调的方面，那么选择协作图。序列图和协作图都用于显示对象之间的交互