面向对象的需求分析优秀PPT.ppt

《面向对象的需求分析优秀PPT.ppt》由会员分享，可在线阅读，更多相关《面向对象的需求分析优秀PPT.ppt（115页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、面向对象的需求分析第一页，本课件共有115页什么是面向对象Coad和Yourdon给出了一个定义：“面向对象=对象+类+继承继承+通信通信”。如果一个软件系统是使用这样 4 个概念设计和实现的，则我们认为这个软件系统是面向对象的。一个面向对象的程序的每一成份应是对象，计算是通过新的对象的建立和对象之间的通信来执行的。51 面向对象的概念与思想面向对象的概念与思想第二页，本课件共有115页对象（objectobject）对象是面向对象开发模式的基本成份。每个对象可用它本身的一组属性和它可以执行的一组操作来定义。属性属性一般只能通过执行对象的操作来改变。操作操作又称为方法或服务，它描述了对象执行的

2、功又称为方法或服务，它描述了对象执行的功能，若通过消息传递，还可以为其它对象使用。能，若通过消息传递，还可以为其它对象使用。第三页，本课件共有115页价格尺寸重量位置颜色购买销售称重移动属性服务家具对象的组成、表示及意义(例如：人的特征：姓名、性别、年龄等，行为：衣、食、住、行等。)第四页，本课件共有115页第五页，本课件共有115页第六页，本课件共有115页消息（消息（Message）消息是一个对象与另一个对象的通信单元，是要求某个对象执行类中定义的某个操作的规格说明。发送给一个对象的消息定义了一个方法名和一个参数表（可能是空的），并指定某一个对象。一个对象接收的消息则调用消息中指定的方法，

3、并将形式参数与参数表中相应的值结合起来。第七页，本课件共有115页类类(class)类是一组具有相同数据结构和相同操作的对象的集合。类的定义包括一组数据属性和在数据上的一组合法操作。类定义可以视为一个具有类似特性与共同行为的对象的模板，可用来产生对象。在一个类中，每个对象都是类的实例(Instance)，它们都可使用类中提供的函数。对象的状态则包含在它的实例变量，即实例的属性中。第八页，本课件共有115页类 两个四边形对象第九页，本课件共有115页Quadrilateral类的每个对象有同样的一组实例变量和方法。就这个意义来讲，类Quadrilateral给我们提供了一个模板，表示了所有四边形

4、对象。类常常可看做是一个抽象数据类型(ADT)的实现。但更合适的是把类看做是某种概念的模型。第十页，本课件共有115页类的实现常常使用其它类的实例，它们提供了该类所需要的服务。这些实例应当受到保护不被其它对象存取，包括同一个类的其它实例。在四边形的例子中，定义4个point类的实例作为Quadrilateral类的实例的4个顶点。这些point对象不能被其它对象存取。第十一页，本课件共有115页李杰李杰男广东软件1980.49#楼129室看书实验上课运动杨芳服务王辉男湖南计算机控制1979.19#楼320室杨芳女北京系统结构1979.125#楼418室姓名性别籍贯专业出生年月住址学生属性王辉属

5、性属性属性看书实验上课运动服务看书实验上课运动服务看书实验上课运动服务对象、类与实例第十二页，本课件共有115页把具有相同特征和行为的对象归在一起就形成了类。类成为某些对象的模板，抽象地描述了属于该类的全部对象的属性和操作。属于某个类的对象叫做该类的实例。对象的状态则包含在它的实例变量，即实例的属性中。第十三页，本课件共有115页继承(Inheritance)继承是使用已存在的定义做为基础建立新定义的技术。新类的定义可以是既存类所声明的数据和新类所增加的声明的组合。新类复用既存的定义，而不要求修改既存类。既存类可当做基类来引用，则新类相应地可当做派生类来引用。第十四页，本课件共有115页第十五

6、页，本课件共有115页使用继承设计一个新类，可以视为描述一个新的对象集，它是既存类所描述对象集的子集合。这个新的子集合可以认为是既存类的一个特殊化。Quadrilateral类 是 Polygon类 的 特 殊 化。Quadrilateral是限制为四条边的多边形。我们还可 以 进 一 步 地 把 类 Quadrilateral特 殊 化 为Rectangle。第十六页，本课件共有115页类Quadrilateral的界面可以等同于类Polygon的界面，而Rectangle类的界面又与Quadrilateral类的界面相同。新类的界面还可以被看做是既存类界面的一个扩充界面。例如，从一个既存的

7、车辆类派生的四轮驱动车类可能不仅是车辆类子集合定义的特殊化，而且还可能在新类的界面中引入新的能力。第十七页，本课件共有115页类的继承层次类的继承层次第十八页，本课件共有115页 在在类类的的继继承承层层次次中中，Quadrilateral的实际参数可以替换Polygon的形式参数。类Quadrilateral的界面与类Polygon的界面是相容的Quadrilateral的的界界面面可可响响应应Polygon界面的所有消息。第十九页，本课件共有115页汽车运货车救火车大轿车起重车特殊类对一般类的继承关系特殊类对一般类的继承关系第二十页，本课件共有115页5.1.2.面向对象软件开发的分析模型

8、面向对象软件开发的分析模型面向对象分析过程分为论域分析和应用分析。论域分析建立大致的系统实现环境，应用分析则根据特定应用的需求进行论域分析。第二十一页，本课件共有115页(1)OOA分析的基本原则和任务为建立分析模型，要运用如下的5个基本原则：建立信息域模型；描述功能；表达行为；划分功能、数据、行为模型，揭示更多的细节；用早期的模型描述问题的实质，用后期的模型给出实现的细节。第二十二页，本课件共有115页OOA需完成的任务是：软件工程师和用户必须充分沟通，以了解基本的用户需求；必须标识类(即定义其属性和操作)；必须定义类的层次；应当表达对象与对象之间的关系(即对象的连接)；必须模型化对象的行为

9、；反复地做任务，直到模型建成。第二十三页，本课件共有115页广泛使用的广泛使用的OOA方法有以下几种：方法有以下几种：Booch方法：Booch方法包含“微开发过程”和“宏开发过程”。微开发过程定义了一组任务，并在宏开发过程的每一步骤中反复使用它们，以维持演进途径。BoochOOA宏开发过程的任务包括标识类和对象、标识类和对象的语义、定义类与对象间的关系，以及进行一系列求精从而实现分析模型。第二十四页，本课件共有115页Rumbaugh方法：Rumbaugh和他的同事提出的对象模型化技术(OMT)用于分析、系统设计和对象级设计。分析活动建立三个模型：对象模型(描述对象、类、层次和关系)，动态模

10、型(描述对象和系统的行为)，功能模型(类似于高层的DFD，描述穿越系统的信息流)。第二十五页，本课件共有115页Coad和Yourdon方法：Coad和Yourdong方法常常被认为是最容易学习的OOA方法。建模符号相当简单，而且开发分析模型的导引直接明了。其OOA过程概述如下：使用“要找什么”准则标识对象；定义对象之间的一般化特殊化结构；定义对象之间的整体部分结构；标识主题(系统构件的表示)；定义属性及对象之间的实例连接；定义服务及对象之间的消息连接。第二十六页，本课件共有115页Jacobson方法：也称为OOSE(面向对象软件工程)。Jacobson方法与其它方法的不同之处在于他特别强调

11、使用实例(usecase)用以描述用户与系统之间如何交互的场景。Jacobson方法概述如下：标识系统的用户和它们的整体责任；通过定义参与者及其职责、使用实例、对象和关系的初步视图，建立需求模型；通过标识界面对象、建立界面对象的结构视图、表示对象行为、分离出每个对象的子系统和模型，建立分析模型。第二十七页，本课件共有115页(5)统一的OOA方法(UML)1.统一的建模语言(UML)已经在企业中广泛使用，它把Booch、Rumbaugh和Jacobson等各自独立的OOA和OOD方法中最优秀的特色组合成一个统一的方法。UML允许软件工程师使用由一组语法的语义的实用的规则支配的符号来表示分析模型

12、。2在UML中用5种不同的视图来表示一个系统，这些视图从不同的侧面描述系统。每一个视图由一组图形来定义。第二十八页，本课件共有115页这些视图概述如下：用户模型视图：这个视图从用户(在UML中叫做参与者)角度来表示系统。它用使用实例(usecase)来建立模型，并用它来描述来自终端用户方面的可用的场景。结构模型视图：从系统内部来看数据和功能性。即对静态结构(类、对象和关系)模型化。第二十九页，本课件共有115页行为模型视图：这种视图表示了系统动态和行为。它还描述了在用户模型视图和结构模型视图中所描述的各种结构元素之间的交互和协作。实现模型视图：将系统的结构和行为表达成为易于转换为实现的方式。环

13、境模型视图：表示系统实现环境的结构和行为。通常，UML分析建模的注意力放在系统的用户模型和结构模型视图，而UML设计建模则定位在行为模型、实现模型和环境模型。第三十页，本课件共有115页52UML概述1.UML主要以BOOCH方法、OMT方法（71）和OOSE方法为基础，同时也吸收了其他面向对象建模方法的优点，形成一种概念清晰、表达能力丰富、适用范围广泛的面向对象的标准建模语言。2.UML共定义了十种视图，并将其分为如下四类：用例图、静态图、行为图、实现图等 UML的语言机制的语言机制第三十一页，本课件共有115页(1)用例图（usecasediagram）。从外部用户的角度描述系统的功能，并

14、指出功能的执行者。(2)静态图。包括类图（classdiagram）、对象图（objectdiagram）和包图（packdiagram）。类图描述系统的静态结构，类图的节点表示系统中的类及其属性和操作，类图的边表示类之间的联系，包括继承、关联、依赖、聚合等。对象图是类图一个实例，它描述在某种状态下或在某一时间段，系统中活跃的对象及其关系。在对象图，一个类可以拥有多个活跃的对象实例。包图描述系统的分解结构，它表示包（package）以及包之间的关系。包由子包及类组成。包之间的关系包括继承、构成与依赖关系。第三十二页，本课件共有115页(3)行为图。包括交互图（interactivediagra

15、m）、状态图（statechardiagram）与活动图（activitydiagram），它们从不同的侧面刻画系统的动态行为。交互图描述描述对象之间的消息传递，它又可分为顺序图（sequencediagram）与合作图（collaborationdiagram）两种形式。顺序图强调对象之间消息发送的时间序。合作图更强调对象间的动态协作关系。合作图也可通过消息序号之间消息发送的时间序。只不过这种表示不如顺序图那样直观。第三十三页，本课件共有115页状态图描述类的对象的动态行为，它包含对象所有可能的状态、在每个状态下能够响应的事件以及事件发生时的状态迁移与响应动作。活动图描述系统为完成某项功能而

16、执行的操作序例，这些操作序列可以并发和同上。活动图中包含控制和信息流。控制流表示一个操作完成后对其后操作的触发，信息流则刻画操作之间的信息交换。第三十四页，本课件共有115页（4）实现图（implementatindiagram）。包括构件图（componentdiagram）与部署图（deploymetndiagram），它们描述软件实现系统的组成和分布状况。构件图描述软件实现系统中各组成部件以及它们之间的信赖关系。构件图主要用于理解和分析软件各部分之间的相互影响程度。部署图描述作为软件系统运行环境的硬件及网络的物理体系结构，其节点表示实际的计算机和设备，边表示节点之间物理连接关系，也可显示

17、连接的类型及节点之间的依赖性。第三十五页，本课件共有115页某大学的课程注册管理系统包含个用例某大学的课程注册管理系统包含个用例 第三十六页，本课件共有115页课表维护：教务管理人员用之设置或修改课程属性（课程的时间、地点、上课老师等）和增删课程；个人课程规划：学生使用“个人课程规划”用例选课和修改自己的个人课表，收费管理系统根据每个学生的选课情况计算其应缴费用；选课学生花名册查询：老师使用“选课学生花名册查询”用例获取选定其所开课程的学生花名册。第三十七页，本课件共有115页课程注册管理系统包含的课程注册管理系统包含的8个类（类图）。个类（类图）。第三十八页，本课件共有115页用用UML顺序

18、图表示顺序图表示“个人课程规划个人课程规划”用例中的学生用例中的学生选课过程选课过程 第三十九页，本课件共有115页用用UML协作图表示协作图表示“个人课程规划个人课程规划”用例中的学生用例中的学生选课过程选课过程(与上图等价与上图等价)第四十页，本课件共有115页UML状态图示例状态图示例 第四十一页，本课件共有115页5.2.2基于基于UML的软件开发过程的软件开发过程一种迭代的渐进式软件开发过程，它包含4个阶段：初启、细化、构造和移交。1.初初启启:在初启阶段，软件项目的发起人确定项目的主要目标和范围，并进行初步的可行性分析和经济效益分析。第四十二页，本课件共有115页 2.细细化化:细

19、化阶段的开始标志着项目的正式确立,软件项目组在此阶段需要完成以下工作：（）初步的需求分析。采用UML的用例描述目标软件系统所有比较重要、比较有风险的用例，利用用例图表示参与者与用例以及用例与用例之间的关系。采用UML的类图表示目标软件系统所基于的应用领域中的概念之间的关系。这些相互关联的概念构成领域模型。领域模型一方面可以帮助软件项目组理解业务背景，与业务专家进行有效沟通；另一方面，随着软件开发阶段的不断推进，领域模型将成为软件结构的主要基础。如果领域中含有明显的流程处理成分，可以考虑利用UML的活动图来刻画领域中的工作流，并标识业务流程中的并发、同步等特征。第四十三页，本课件共有115页（）

20、初步的高层设计。如果目标软件系统的规模比较庞大，那么经初步需求分析获得的用例和类将会非常多。此时，可以考虑根据用例、类在业务领域中的关系，或者根据业务领域中某种有意义的分类方法将整个软件系统划分为若干包，利用UML的包图刻画这些包及其间的关系。这样，用例、用例图、类、类图将依据包的划分方法分属于不同的包，从而得到整个目标软件系统的高层结构。第四十四页，本课件共有115页（）部分的详细设计。对于系统中某些重要的或者比较高的用例，可以采用交互图进一步探讨其内部实现过程。同样，对于系统中的关键类，也可以详细研究其属性和操作，并在UML类图中加以表现。因此，这里倡导的软件开发过程并不在时间轴上严格划分

21、分析与设计、总体设计与详细设计，而是根据软件元素（用例、类等）的重要性和风险程度确立优先细化原则，建议软件项目组优先考虑重要的、比较有风险的用例和类，不能将风险的识别和解决延迟到细化阶段之后。第四十五页，本课件共有115页（）部分的原型构造。在许多情形下，针对某些复杂的用例构造可实际运行的耐用消费品型是降低技术风险、让用户帮助软件项目组确认用户需求的最有效的方法。为了构造原型，需要针对用例生成详尽的交互图，对所有相关类给出明确的属性和操作定义。第四十六页，本课件共有115页综上所述，在细化阶段可能需要使用的UML语言机制包括：描述用户需求的用例用用例图、表示领域概念模型的类图、表示业务流程处理

22、的活动图、表示系统高层结构的包图和表示用例内部实现过程的交互图等。细化阶段的结束条件是，所有主要的用户需求已通过用例和用例图得以描述；所有重要的风险已被标识，并对风险应对措施了如指掌；能够比较精确地估算实现每一用例的时间。第四十七页，本课件共有115页3.构造在构造阶段,开发人员通过一系列的迭代完成对所有用例的软件实现工作,在每次迭代中实现一部分用例.以迭代方式实现所有用例的好处在于,用户可以及早参与对已实现用例的实际评价,并提出改进意见.这样可有效降低大型软件系统的开发风险。第四十八页，本课件共有115页在实际开始构造软件系统之前，有必要预先制定迭代计划。计划的制定需遵循如下两项原则：（）用

23、户变为业务价值较大的用例应优先安排；（）开发人员评估后认为开发风险较高的用例应优先安排。在迭代计划中，要确定迭代次数、每次迭代所需时间以及每次迭代中应完成（或部分完成）的用例。第四十九页，本课件共有115页每次迭代过程由针对用例的分析、设计、编码、测试和集成5相子阶段构成。在集成之后，用户可以对用例的实现效果进行评价，并提出修改意见。这些修改意见可以在本次迭代过程中立即实现，也可以在下次迭代中再予以考虑。构造过程中，需要使用UML的交互图来设计用例的实现方法。为了与设计得出的交互图协调一致，需要修改或精化在细化阶段绘制的作为领域模型的类图，增加一些为软件实现所必需的类、类的属性或方法。第五十页

24、，本课件共有115页UML的活动图可以在构造阶段用来表示复杂的算法过程和有多个对象参与的业务处理过程。活动图尤其适用于表示过程中的并发和同步。在构造阶段的每次迭代过程中，可以对细化阶段绘出的懈图进行修改或精化，以便包图切实反映目标软件系统最顶层的结构划分状况。第五十一页，本课件共有115页在构造阶段可能需要使用的在构造阶段可能需要使用的UML语言机制包语言机制包括：括：.用例及用例图。它们是开发人员在构造阶段进行分析和设计的基础。类图。在领域概念模型的基础上引进为软件实现所必需的类、属性和方法。交互图。表示针对用例设计的软件实现方法。状态图。表示类的对象的状态事件响应行为。活动图。表示复杂的算

25、法过程，尤其是过程中的并发和同步。包图。表示目标软件系统的顶层结构。构什图。部署图第五十二页，本课件共有115页4移交在移交阶段，开发人员将构造阶段获得的软件系统在用户实际工作环境（或接近实际的模拟环境）中试运行，根据用户的修改意见进行少量调整。第五十三页，本课件共有115页63基于基于UML的需求分析的需求分析基于UML的需求分析大致可分为以下步骤：（）利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总、分类、抽象。形成用例；确定执行者与用例、用例与用例图之间的关系，生成用例图第五十四页，本课件共有115页注注意意:两个步骤并没有时序关系，它们可以并行展开，如图上图

26、中上图中,从描述开始分开走两个步骤从描述开始分开走两个步骤第五十五页，本课件共有115页（）利用包图及类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。第五十六页，本课件共有115页5.3.1开发场景开发场景场场景景是指从单个执行者的角度观察目标软件系统的功能和外部行为。这种功能通过系统与用户之间的交互来表征。场景是用户与系统之间进行交互的一组具体的动作。相对于用例（见5.3.2节）而言，场景是用例的实例，而用例是某类场景的共同抽象

27、。对场景的完事描述应包含场景名称、执行者实例，场景名称、执行者实例，前置条件、事件流和后置条件前置条件、事件流和后置条件。第五十七页，本课件共有115页“家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与用户进行信息交互。配置操作包括：(1)指定每一传感器的种类和编号；(2)设置开、关机密码；(3)指定报警电话电码；(4)指定报警延迟和电话重拨延迟时间(以秒为单位)；例：家庭保安系统例：家庭保安系统第五十八页，本课件共有115页根据以上初步描述:该系统具有“系统配置”、“开机”、“关机”、“门窗监测”、“烟雾监测”和“复位”等场景。当软件系统收到传感器发出的数

28、据后，判别是否出现异常事件。如果是，则在指定的延迟时间内拨报警电话号码，拨号操作将按照重拨延迟反复进行，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。第五十九页，本课件共有115页门窗监测场景的具体描述：场景名称：场景名称：门窗监测。参与执行者实例：参与执行者实例：警报器、报警电话、显示器和门窗监视器前置条件：前置条件：系统已开机。主事件流：主事件流：(1)门窗监视器发现门或窗户发生异动，向软件系统报告异常事件。(2)软件系统启动警报器并拨报警电话号码。(3)报警电话接通后，软件系统播出语音，报告异常事件发生的时间、地点和事件的性质（门窗异动）。(4)系统在控制面板的显示器上报

29、警时间及当前状态（报警：门窗异动）。后置条件：后置条件：系统处于“报警”状态。第六十页，本课件共有115页场景分类场景分类根据场景作用的不同，可以将其划分为以下类型：(1)实际场景。对实际的业务处理流程或其优化流程的描述。它是用户需求的重要组成部分。(2)设想场景。分析人员对目标软件系统投入应用后经改进或优化的业务流程的描述。这种可视为一种纸面原型,用于帮助分析人员挖掘潜在的用户需求。第六十一页，本课件共有115页(3)评价场景。以确认需求或提出改进建议为主要目的的业务流程描述。评价场景可以在用例生成后用例进行实例化而形成，以便用户对用例进行评价或改进。(4)培训场景。面向开发人员及用户解释系

30、统的功能和外部行为的业务流程描述。第六十二页，本课件共有115页获取场景的方法获取场景的方法:回答以下问题:(1)目标软件系统有哪些执行者？(2)执行者希望系统执行哪些？(3)执行者希望获得哪些信息？这些信息由谁生成？由谁修改？(4)执行者需要通知系统哪些事件？系统响应这些事件时会表现出哪些外部行为？(5)系统将通告执行者哪些事件？第六十三页，本课件共有115页 小结小结:确定执行者和场景的关键在于理解业务领域和初步需求描述文档。场景将促成开发人员和用户对业务处理流程和目标软件系统的功能范围的共同理解。在场景确定之后，通过对场景的汇总、分类归并和抽象即可形成用例。第六十四页，本课件共有115页

31、5.3.2 生成用例生成用例 用例含义用例含义：1.从外部用户的视角看，一个用例是执行者（actor）与目标软件系统之间的一次典型的交互作用。2.从软件系统内部的视角出发，一个用例代表系统执行的一系列动作，动作执行的结果能够被外部的执行者所察觉。执行者执行者是指外部用户或外部实体在系统中扮演的角色。第六十五页，本课件共有115页用例的完整描述用例的完整描述包含：用例名称、能与执行者、前置条件、一个主事件流、零到多个辅事件流和后置条件。主事件流主事件流表示正常情况下执行者与系统之间的信息交互及动作序列，辅事件流辅事件流则表示特殊情况或异常情况下的信息交互及动作序列。用例主要来源于用例主要来源于分

32、析人员对场景的分类和抽象，即将相似的场景进行归并，使一个用例可以通过实例化和参数调节而涵盖多个场景。第六十六页，本课件共有115页例例:“家庭保安系统家庭保安系统”其中的“开机”、“关机”、“复位”3个场景可以归并为“命令处理”，3个场景之间的差异通过用户命令种类的不同而体现。“门窗监测”、“烟雾监测”两个场景也可归并为统一的“传感器监测”用例。对于熟悉业务领域的分析师而言，也可以略过场景，直接从业务需求描述中获取用例。在“家庭保安系统”中，执行者有“用户”、“传感器”、“报警电话”和“显示器”，用例有“系统配置”、“命令响应”和“传感器监测”。第六十七页，本课件共有115页以“传感器监测”为

33、例说明用例的一向描述格式用例名称用例名称:传感器监测。参参与与执执行行者者:各类传感器、警报器、报警电话和显示器。前置条件前置条件:系统已开机。第六十八页，本课件共有115页主事件流：主事件流：(1)传感器向目标软件系统上报其监测数据，系统判别监测数据是否正常。(2)如果不正常，系统启动警报器，拨报警电话号码。(3)报警电话接通后，软件系统播出语音，报告异常事件发生的时间、地点和事件的性质。(4)系统在控制面板的显示器上显示报警时间及当前状态（报警）。第六十九页，本课件共有115页辅事件流：辅事件流：(1)如果报警电话无人接听，则按照重拨延迟反复拨号，直至电话接通，再转入主事件流的步骤（3）。

34、(2)如果重拨次数达到系统预设的最大次数，电话仍无人接听，则跳过主事件流的步骤（3），转入步骤（4）。后后置置条条件件：如果已发现异常监测数据，系统处于“报警“状态；否则，系统处于正常的监测状态。第七十页，本课件共有115页5.3.3用活动图表示用例用活动图表示用例用例的描述既可采用自然语言，也可采用活动图。活动图。后一表示未能更为精确和直观。第七十一页，本课件共有115页UML活动图活动图用例的事件流或操作均表示为一系列的活动，每个活动在活动图中被表示为一个节点。节点之间的有向边表示活动的执行顺序。在节点间的连接边上可以附加条件表达工，以表示在有向过的源节点执行完成后，如果条件成立，则开始执

35、行有向边的目标节点所表示的活动；如果条件不成立，则目标节点的活动不被执行。条件表达式一般出现在以菱形为源节点的有向边上。第七十二页，本课件共有115页第七十三页，本课件共有115页菱形在活动图中属特殊节点，用来表示条件判断。菱形在活动图中属特殊节点，用来表示条件判断。例如，在图.8中，“密码验证”活动的有向边上。如果“（密码正确）”，则开始“开始选择功能”活动；否则，回到“输入密码“活动。第七十四页，本课件共有115页活动图还可以表示处理过程的并发。活动图的同步条（水平或垂直粗线）可以将一条有向边分叉为多个并发执行的分支进程，或将多个有向边上的进程同步合并为一个进程。例如，在图.8中，当用户选

36、择取款操作，输入取款金额，肯系统验证其要求的金额小于等于余额之后，系统分叉为两个并发进程：点钞、出钞和扣减余额、打印交易信息。此后，再合并为一个进程，进行“选择功能”活动。第七十五页，本课件共有115页为了描述活动的责任对象，活动图引进了“泳道”的概念。泳道是由垂直长线分割出来的矩形区域，在泳道上方的对象负责该矫形区域内的所有活动。例如，在图5.8中，类“Customer”的对象负责“插入银行卡”、“输入密码”、“选择功能”和“输入金额”4项活动，其余活动由类“ATMsystem”的对象负责。第七十六页，本课件共有115页用用 例例 的的活活 动动 图图表表 示示“传 感 器监 测”用例第七十

37、七页，本课件共有115页生成用例图生成用例图执行者与用例之间的关系有两例种：触发执行与信息交换。执行者与用例之间可能兼具这两种关系;例如，“在家庭保安系统”中，执行者“用户”在触发用例“命令响应”的同时，还要向用例传送命令信息。在UML用例图中，从执行者指向用例的边表示触发执行和/或信息交换，从用例指向执行者的边则表示用例将其生成的信息传递给执行者。第七十八页，本课件共有115页UML的用例与用例之间存在如下两种关系：(1)使用（use）关系。如果有一个公共的动作序列存在于多个用例中，为避免重复，并使需求模型更简洁，可以将公共动作序列抽出来的构成新的独立用例。这样，原来的多个用例与新的用例之间

38、便通过使用关系来连接。例如，在“家庭保安系统”中“系统配置”和“命令响应”两个用例使用公共的“密码验证”子用例。第七十九页，本课件共有115页(2)扩展（extend）关系。如果一个用例的动作序列完全包含另一个用例的动作序列，且前者含有后者所不具备的一些特殊情况下的处理动作，则称前者扩展后者。例如，图5.10听“传感器监测”用例仅包含正常的处理流程，而“报警电话未接通”用例除正常流程处还增加了“重复拨号”以及“重拨次数达到最大次数仍无人接听”这两种异常处理动作。第八十页，本课件共有115页“家庭保安系统家庭保安系统”的用例图的用例图 第八十一页，本课件共有115页5.3.5建立顶层架构建立顶层

39、架构顶层架构的主要目的顶层架构的主要目的是为后续的分析和设计活动建立一种结构和分划，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。顶层架构是分析和设计的阶段成果的承载体。随着开发过程的推进，框架中的内容不断丰富、翔实，最终演进为完事的面向对象软件结构。UML包图是表示顶层架构的适当机制，第八十二页，本课件共有115页1.UML包图包图包包是UML对类进行分组的一种机制。可以从某种视角将具有比较密切的关联的一些类划分为一个包，分属于不同包的两个类之间的关联则比较松散。包的划分是实现“分而治之”的重要技术手段。包之间存在两种关系：依赖和构成。如果对类A的修

40、改将导致类B的改变，则称B领带于A。如果两个包中存在具有依赖关系的两个类，则认为这两个分属的包之间存在依赖关系。第八十三页，本课件共有115页例:第八十四页，本课件共有115页例如，上图中的“订单”包依赖于“客户”包。包的构成关系是指包是可以嵌套的，即包中不仅可包含类，还可以包含子包。在上图中，“领域”包由“订单”和“客户”两个子包构成。上图中，“数据库接口”类仅定义抽象的数据访问、数据操作的接口函数，而“Oracle接口”包和“DB2接口”包则基于具体的数据库管理系统逐一实现了通用接口中定义的抽象接口函数。为了表示软件架构，还需要在包之间引进一种称为“连接器”的边。连接器用来表示包之间的信息

41、传递、事件发送和软件调用等关系，且有单向和双向（即无向）之分。第八十五页，本课件共有115页2.软件顶层架构的设计软件顶层架构的设计建立软件系统顶层架构的基本方法是，结合实际需求，人既往的架构设计经验模型中选取适当者，再进行微调或局部改造。第八十六页，本课件共有115页目前有如下几种主要的架构模式：目前有如下几种主要的架构模式：（）流程处理模式。流程处理系统以算法和数据引进中心，其系统功能由一系列的处理步骤构成，相邻的处理步骤之间以数据流通管道相互连接。下图表示具有3处理步骤的流程处理模式。这些处理步骤都使用公共的系统服务（例如数据库访问服务），处理命令来自用户界面，处理的进度和结果也通过用户

42、界面呈现。第八十七页，本课件共有115页第八十八页，本课件共有115页（）客户/服务器模式。如图.13所示，客户端负责用户输入和处理结果的呈现，服务器端则负责后台的业务逻辑处理。第八十九页，本课件共有115页模型视图控制器（MVC）模式。如下图该模式将整个软件系统划分为模型，视图和控制器3个部分。模型负责维护并保存具有持久性的业务数据，实现业务处理功能，并将业务数据的变化情况及时通知视图；视图负责呈现模型的业务数据，响应模型变化通知，更新呈现形式，并向控制器传递用户的界面动作；控制器负责将用户的界面动作映射为模型中业务处理功能并实际调用之，然后根据模型返回的业务处理结果选择新的视图。MVC模式

43、特别适合于分布应用软件，尤其是Web应用系统。第九十页，本课件共有115页第九十一页，本课件共有115页（）分层模式。如图.15所示，分层模式将整个软件系统分为若干层次，最顶层直接面向用户提供软件系统的操作界面，其余各层为紧邻其上的层次提供服务。层次划时分的主要原则是：较蝗变化的软件部分（例如用户界面、与业务逻辑紧密相关的部件）置于较高层次，较稳定的软件部分（例如公共的技术服务部件）则位于较低层次；每一层次尽量只访问其紧邻下层提供的服务，避免越级访问，尤其要避免逆向访问（上层模块为下层模块提供服务）；。第九十二页，本课件共有115页在许多情况下，可以将目标软件系统的外部接口置入较低层次，目标软

44、件系统其余部分对处部系统的访问或操作均通过这些外部接口所提供的公共服务来完成。分层模式可以有效地降低软件系统的耦合度，因此其应用十分普遍第九十三页，本课件共有115页在确立顶层架构的过程中，需综合考虑以下因素：（）架构中包的数量。原则上，如果每个包中包含的软件元素（例如类）的数量过多，应考虑将其进一步细分；如果过少，则说明架构过早地陷入了细节，架构划分返工的可能性较大，同时也不合理地限制了后续分析和设计活动的自由空间。（）架构中包之间的耦合度。包之间的依赖关系和连接关系应尽量简单、稀疏，例如，在分层结构中，通常要求某一层中的软件元素只与同层及相邻下一层的元素之间存在依赖关系。第九十四页，本课件

45、共有115页（）软件元素的稳定性。要尽量抽取不稳定的软件元素之中相对稳定的部分将不稳定的软件元素分类聚集于少数几个包中，以提高软件系统的可维护性。（）软件元素的必然性。可以将可选功能和必须实现的功能分置于架构中不同的包或子包之中。（）作为软件系统运行环境的物理网络拓朴。根据软件元素在分布环境的部署情况区分顶层架构中的包，可以使包之间的消息传递与物理节点之间的通信相吻合，使后续的分析和设计活动受益于顶层架构中明确定义的通信关系。第九十五页，本课件共有115页（）软件元素的安全、保密级别。根据安全访问的权限划分顶层架构中的包或者子包。（）开发团队的技术专长。根据开发人员在问题领域和软件技术领域不同

46、的专长划分顶层架构中的包，使每个包都能分配给最适合的开发人员进行后续的分析、设计、编码和测试等，从而有利于并行开发。第九十六页，本课件共有115页5.3.6建立领域概念模型建立领域概念模型1.在用户需求和相关的业务领域中,抽取全局性的概念,并研究这些概念之间的关系。2.在UML中，用类表示概念，用类图表示领域概念模型。第九十七页，本课件共有115页1UML类图类图UML的类包含3个部分：类的名称、属性列表和方法列表，其表示图元如图 注意注意:在需求分析的早期不需要一次性列举类的所有属性和方法。刚开始可以仅标识类名，以后随着分析、设计的不断推进而逐步完善属性列表和方法列表。第九十八页，本课件共有

47、115页UML类之间的关系的主要有继承、聚集、关联和依类之间的关系的主要有继承、聚集、关联和依赖。赖。1.1.继承关系继承关系表示子类重用父类的属性的操作，子类的对象也是父类的对象例例(如图如图)“教务管理人员”、“学生”和“老师”都是泛化的“用户”类的子类，它们继承来自“用户”类的用户姓名、标识码、密码等属性以及用户注册、密码验证、退出系统等操作，第九十九页，本课件共有115页聚集关系聚集关系是部分整体关系的直接模拟。细分为普通聚集和构成关系两种。普通聚集关系是一个部件类对象可同时参与多个整体类对象;构成关系则限定一个部件类对象在任意时刻只能参与一个整体类对象，部件类对象与整体类对象共存亡。

48、例如图第一百页，本课件共有115页关联关系表示在两个类的对象之间存在着一种用于消息传递的稳定通道。例如，在课程注册管理系统中，“学生”类“老师”类与“课程设置”类之间存在关联关系，因为“课程设置”肯定与选课学生和授课老师有关，学生和教师他都需要查询课程设置中有关信息，如上课时间、地点和选课学生清单等。第一百零一页，本课件共有115页参与聚集、构成和关联关系的两个类的对象之间往往存在着数量对应关系，这种关系是业务规则的具体表现。当分析和设计推进到一定阶段之后，应该将这种数量对应关系在这三种关系的表示边上明确地标示出来。例如，上图表示对于每个“课程设置”对象，选课学生应不少于10个，不多于50个。

49、每个学生在一个学期中所选的课程应不少于4门、不多于8门。第一百零二页，本课件共有115页依赖关系是关联关系的弱化，表示被依赖的类的变化会影响到依赖类。依赖关系的起因有：依赖类的对象需要向被依赖害的对象传递消息；被依赖害作为依赖类的操作的形参类型。前一种情况不仅可以且依赖关系实现，也可以用关联关系及强化形式（聚合和构成）来实现。第一百零三页，本课件共有115页这两种实现方法的区别在于，依赖关系仅表示一种临时性的消息传递通道，一旦依赖类对象的操作完成，该通道立即消失；关联关系及其强化形式则表示消息传递通道在整个对象的生命周期中稳定存在。关联是依赖的强化，聚合是关联的强化，构成是聚合的强化。第一百零

50、四页，本课件共有115页例如，在图.11中，“订单”包中的类仅依赖于“数据库接口”包中的类（接口），并不需要在它们之间建立关联关系，因为对数据库的访问和操作仅在订单处理类的函数中局部进行。第一百零五页，本课件共有115页2领域概念模型的建立领域概念模型的建立为建立以UML类图表示的领域概念模型，必须首先标识关键概念。关键概念的来源包括：1.业务需求描述和用例说明；2业务领域中的相关规范、标准和术语定义；3.反映业务领域知识的既往经验例如，“家庭保安系统”的领域概念模型如图5.18所示。第一百零六页，本课件共有115页第一百零七页，本课件共有115页上图中新引入了“用户命令处理器”、“系统配置管