面向对象的需求分析

面向对象的需求分析第1页，共115页，2023年，2月20日，星期四什么是面向对象Coad和Yourdon给出了一个定义：“面向对象=对象+类+继承+通信”。如果一个软件系统是使用这样4个概念设计和实现的，则我们认为这个软件系统是面向对象的。一个面向对象的程序的每一成份应是对象，计算是通过新的对象的建立和对象之间的通信来执行的。5．1面向对象的概念与思想

第2页，共115页，2023年，2月20日，星期四对象（object）对象是面向对象开发模式的基本成份。每个对象可用它本身的一组属性和它可以执行的一组操作来定义。属性一般只能通过执行对象的操作来改变。操作又称为方法或服务，它描述了对象执行的功能，若通过消息传递，还可以为其它对象使用。第3页，共115页，2023年，2月20日，星期四价格尺寸重量位置颜色购买销售称重移动属性服务家具对象的组成、表示及意义(例如：人的特征：姓名、性别、年龄等，行为：衣、食、住、行等。)第4页，共115页，2023年，2月20日，星期四第5页，共115页，2023年，2月20日，星期四第6页，共115页，2023年，2月20日，星期四消息（Message）消息是一个对象与另一个对象的通信单元，是要求某个对象执行类中定义的某个操作的规格说明。发送给一个对象的消息定义了一个方法名和一个参数表（可能是空的），并指定某一个对象。一个对象接收的消息则调用消息中指定的方法，并将形式参数与参数表中相应的值结合起来。第7页，共115页，2023年，2月20日，星期四类(class)类是一组具有相同数据结构和相同操作的对象的集合。类的定义包括一组数据属性和在数据上的一组合法操作。类定义可以视为一个具有类似特性与共同行为的对象的模板，可用来产生对象。在一个类中，每个对象都是类的实例(Instance)，它们都可使用类中提供的函数。对象的状态则包含在它的实例变量，即实例的属性中。第8页，共115页，2023年，2月20日，星期四类←两个四边形对象第9页，共115页，2023年，2月20日，星期四Quadrilateral类的每个对象有同样的一组实例变量和方法。就这个意义来讲，类Quadrilateral给我们提供了一个模板，表示了所有四边形对象。类常常可看做是一个抽象数据类型(ADT)的实现。但更合适的是把类看做是某种概念的模型。第10页，共115页，2023年，2月20日，星期四类的实现常常使用其它类的实例，它们提供了该类所需要的服务。这些实例应当受到保护不被其它对象存取，包括同一个类的其它实例。在四边形的例子中，定义4个point类的实例作为Quadrilateral类的实例的4个顶点。这些point对象不能被其它对象存取。第11页，共115页，2023年，2月20日，星期四李杰李杰男广东软件1980.49#楼129室看书实验上课运动杨芳服务王辉男湖南计算机控制1979.19#楼320室杨芳女北京系统结构1979.125#楼418室姓名性别籍贯专业出生年月住址学生属性王辉属性属性属性看书实验上课运动服务看书实验上课运动服务看书实验上课运动服务

对象、类与实例第12页，共115页，2023年，2月20日，星期四把具有相同特征和行为的对象归在一起就形成了类。类成为某些对象的模板，抽象地描述了属于该类的全部对象的属性和操作。属于某个类的对象叫做该类的实例。对象的状态则包含在它的实例变量，即实例的属性中。

第13页，共115页，2023年，2月20日，星期四继承(Inheritance)继承是使用已存在的定义做为基础建立新定义的技术。新类的定义可以是既存类所声明的数据和新类所增加的声明的组合。新类复用既存的定义，而不要求修改既存类。既存类可当做基类来引用，则新类相应地可当做派生类来引用。第14页，共115页，2023年，2月20日，星期四第15页，共115页，2023年，2月20日，星期四使用继承设计一个新类，可以视为描述一个新的对象集，它是既存类所描述对象集的子集合。这个新的子集合可以认为是既存类的一个特殊化。Quadrilateral类是Polygon类的特殊化。Quadrilateral是限制为四条边的多边形。我们还可以进一步地把类Quadrilateral特殊化为Rectangle

。第16页，共115页，2023年，2月20日，星期四类Quadrilateral的界面可以等同于类Polygon的界面，而Rectangle类的界面又与Quadrilateral类的界面相同。新类的界面还可以被看做是既存类界面的一个扩充界面。例如，从一个既存的车辆类派生的四轮驱动车类可能不仅是车辆类子集合定义的特殊化，而且还可能在新类的界面中引入新的能力。第17页，共115页，2023年，2月20日，星期四类的继承层次第18页，共115页，2023年，2月20日，星期四在类的继承层次中，Quadrilateral的实际参数可以替换Polygon的形式参数。类Quadrilateral的界面与类Polygon的界面是相容的Quadrilateral的界面可响应Polygon界面的所有消息。第19页，共115页，2023年，2月20日，星期四汽车运货车救火车大轿车起重车特殊类对一般类的继承关系第20页，共115页，2023年，2月20日，星期四5.1.2.面向对象软件开发的分析模型面向对象分析过程分为论域分析和应用分析。论域分析建立大致的系统实现环境，应用分析则根据特定应用的需求进行论域分析。

第21页，共115页，2023年，2月20日，星期四(1)OOA分析的基本原则和任务为建立分析模型，要运用如下的5个基本原则：①

建立信息域模型；②

描述功能；③

表达行为；④

划分功能、数据、行为模型，揭示更多的细节；⑤

用早期的模型描述问题的实质，用后期的模型给出实现的细节。

第22页，共115页，2023年，2月20日，星期四OOA需完成的任务是：①软件工程师和用户必须充分沟通，以了解基本的用户需求；②必须标识类(即定义其属性和操作)；③必须定义类的层次；④应当表达对象与对象之间的关系(即对象的连接)；⑤必须模型化对象的行为；⑥

反复地做任务①―⑤，直到模型建成。

第23页，共115页，2023年，2月20日，星期四广泛使用的OOA方法有以下几种：

Booch方法

：Booch方法包含“微开发过程”和“宏开发过程”。微开发过程定义了一组任务，并在宏开发过程的每一步骤中反复使用它们，以维持演进途径。BoochOOA宏开发过程的任务包括标识类和对象、标识类和对象的语义、定义类与对象间的关系，以及进行一系列求精从而实现分析模型。

第24页，共115页，2023年，2月20日，星期四②

Rumbaugh方法

：Rumbaugh和他的同事提出的对象模型化技术(OMT)用于分析、系统设计和对象级设计。分析活动建立三个模型：对象模型(描述对象、类、层次和关系)，动态模型(描述对象和系统的行为)，功能模型(类似于高层的DFD，描述穿越系统的信息流)。

第25页，共115页，2023年，2月20日，星期四③Coad和Yourdon方法：Coad和Yourdong方法常常被认为是最容易学习的OOA方法。建模符号相当简单，而且开发分析模型的导引直接明了。其OOA过程概述如下：使用“要找什么”准则标识对象；定义对象之间的一般化∕特殊化结构；定义对象之间的整体∕部分结构；标识主题(系统构件的表示)；定义属性及对象之间的实例连接；

定义服务及对象之间的消息连接。

第26页，共115页，2023年，2月20日，星期四④Jacobson方法：也称为OOSE(面向对象软件工程)。Jacobson方法与其它方法的不同之处在于他特别强调使用实例(usecase)——用以描述用户与系统之间如何交互的场景。Jacobson方法概述如下：标识系统的用户和它们的整体责任；通过定义参与者及其职责、使用实例、对象和关系的初步视图，建立需求模型；

通过标识界面对象、建立界面对象的结构视图、表示对象行为、分离出每个对象的子系统和模型，建立分析模型。

第27页，共115页，2023年，2月20日，星期四(5)统一的OOA方法(UML)1.统一的建模语言(UML)已经在企业中广泛使用，它把Booch、Rumbaugh和Jacobson等各自独立的OOA和OOD方法中最优秀的特色组合成一个统一的方法。UML允许软件工程师使用由一组语法的语义的实用的规则支配的符号来表示分析模型。2在UML中用5种不同的视图来表示一个系统，这些视图从不同的侧面描述系统。每一个视图由一组图形来定义。第28页，共115页，2023年，2月20日，星期四这些视图概述如下：用户模型视图：这个视图从用户(在UML中叫做参与者)角度来表示系统。它用使用实例(usecase)来建立模型，并用它来描述来自终端用户方面的可用的场景。结构模型视图：从系统内部来看数据和功能性。即对静态结构(类、对象和关系)模型化。第29页，共115页，2023年，2月20日，星期四行为模型视图：这种视图表示了系统动态和行为。它还描述了在用户模型视图和结构模型视图中所描述的各种结构元素之间的交互和协作。实现模型视图：将系统的结构和行为表达成为易于转换为实现的方式。环境模型视图：表示系统实现环境的结构和行为。通常，UML分析建模的注意力放在系统的用户模型和结构模型视图，而UML设计建模则定位在行为模型、实现模型和环境模型。第30页，共115页，2023年，2月20日，星期四5．2UML概述

1.UML主要以BOOCH方法、OMT方法（71）和OOSE方法为基础，同时也吸收了其他面向对象建模方法的优点，形成一种概念清晰、表达能力丰富、适用范围广泛的面向对象的标准建模语言。

2.UML共定义了十种视图，并将其分为如下四类：用例图、静态图、行为图、实现图等

UML的语言机制第31页，共115页，2023年，2月20日，星期四(1)用例图（usecasediagram）。从外部用户的角度描述系统的功能，并指出功能的执行者。

(2)静态图。包括类图（classdiagram）、对象图（objectdiagram）和包图（packdiagram）。类图描述系统的静态结构，类图的节点表示系统中的类及其属性和操作，类图的边表示类之间的联系，包括继承、关联、依赖、聚合等。对象图是类图一个实例，它描述在某种状态下或在某一时间段，系统中活跃的对象及其关系。在对象图，一个类可以拥有多个活跃的对象实例。包图描述系统的分解结构，它表示包（package）以及包之间的关系。包由子包及类组成。包之间的关系包括继承、构成与依赖关系。第32页，共115页，2023年，2月20日，星期四(3)行为图。包括交互图（interactivediagram）、状态图（statechardiagram）与活动图（activitydiagram），它们从不同的侧面刻画系统的动态行为。交互图描述描述对象之间的消息传递，它又可分为顺序图（sequencediagram）与合作图（collaborationdiagram）两种形式。顺序图强调对象之间消息发送的时间序。合作图更强调对象间的动态协作关系。合作图也可通过

消息序号之间消息发送的时间序。只不过这种表示不如顺序图那样直观。第33页，共115页，2023年，2月20日，星期四状态图描述类的对象的动态行为，它包含对象所有可能的状态、在每个状态下能够响应的事件以及事件发生时的状态迁移与响应动作。活动图描述系统为完成某项功能而执行的操作序例，这些操作序列可以并发和同上。活动图中包含控制和信息流。控制流表示一个操作完成后对其后操作的触发，信息流则刻画操作之间的信息交换。第34页，共115页，2023年，2月20日，星期四（4）实现图（implementatindiagram）。包括构件图（componentdiagram）与部署图（deploymetndiagram），它们描述软件实现系统的组成和分布状况。构件图描述软件实现系统中各组成部件以及它们之间的信赖关系。构件图主要用于理解和分析软件各部分之间的相互影响程度。部署图描述作为软件系统运行环境的硬件及网络的物理体系结构，其节点表示实际的计算机和设备，边表示节点之间物理连接关系，也可显示连接的类型及节点之间的依赖性。第35页，共115页，2023年，2月20日，星期四某大学的课程注册管理系统包含３个用例

第36页，共115页，2023年，2月20日，星期四课表维护：教务管理人员用之设置或修改课程属性（课程的时间、地点、上课老师等）和增删课程；个人课程规划：学生使用“个人课程规划”用例选课和修改自己的个人课表，收费管理系统根据每个学生的选课情况计算其应缴费用；选课学生花名册查询：老师使用“选课学生花名册查询”用例获取选定其所开课程的学生花名册。第37页，共115页，2023年，2月20日，星期四课程注册管理系统包含的8个类（类图）。

第38页，共115页，2023年，2月20日，星期四用UML顺序图表示“个人课程规划”用例中的学生选课过程

第39页，共115页，2023年，2月20日，星期四用UML协作图表示“个人课程规划”用例中的学生选课过程

(与上图等价)第40页，共115页，2023年，2月20日，星期四UML状态图示例

第41页，共115页，2023年，2月20日，星期四5.2.2基于UML的软件开发过程一种迭代的渐进式软件开发过程，它包含4个阶段：初启、细化、构造和移交。

1.初启:在初启阶段，软件项目的发起人确定项目的主要目标和范围，并进行初步的可行性分析和经济效益分析。

第42页，共115页，2023年，2月20日，星期四

2.细化:细化阶段的开始标志着项目的正式确立,软件项目组在此阶段需要完成以下工作：（１）初步的需求分析。采用UML的用例描述目标软件系统所有比较重要、比较有风险的用例，利用用例图表示参与者与用例以及用例与用例之间的关系。采用UML的类图表示目标软件系统所基于的应用领域中的概念之间的关系。这些相互关联的概念构成领域模型。领域模型一方面可以帮助软件项目组理解业务背景，与业务专家进行有效沟通；另一方面，随着软件开发阶段的不断推进，领域模型将成为软件结构的主要基础。如果领域中含有明显的流程处理成分，可以考虑利用UML的活动图来刻画领域中的工作流，并标识业务流程中的并发、同步等特征。第43页，共115页，2023年，2月20日，星期四（２）初步的高层设计。如果目标软件系统的规模比较庞大，那么经初步需求分析获得的用例和类将会非常多。此时，可以考虑根据用例、类在业务领域中的关系，或者根据业务领域中某种有意义的分类方法将整个软件系统划分为若干包，利用UML的包图刻画这些包及其间的关系。这样，用例、用例图、类、类图将依据包的划分方法分属于不同的包，从而得到整个目标软件系统的高层结构。

第44页，共115页，2023年，2月20日，星期四（３）部分的详细设计。对于系统中某些重要的或者比较高的用例，可以采用交互图进一步探讨其内部实现过程。同样，对于系统中的关键类，也可以详细研究其属性和操作，并在UML类图中加以表现。因此，这里倡导的软件开发过程并不在时间轴上严格划分分析与设计、总体设计与详细设计，而是根据软件元素（用例、类等）的重要性和风险程度确立优先细化原则，建议软件项目组优先考虑重要的、比较有风险的用例和类，不能将风险的识别和解决延迟到细化阶段之后。第45页，共115页，2023年，2月20日，星期四（４）部分的原型构造。在许多情形下，针对某些复杂的用例构造可实际运行的耐用消费品型是降低技术风险、让用户帮助软件项目组确认用户需求的最有效的方法。为了构造原型，需要针对用例生成详尽的交互图，对所有相关类给出明确的属性和操作定义。第46页，共115页，2023年，2月20日，星期四综上所述，在细化阶段可能需要使用的UML语言机制包括：描述用户需求的用例用用例图、表示领域概念模型的类图、表示业务流程处理的活动图、表示系统高层结构的包图和表示用例内部实现过程的交互图等。细化阶段的结束条件是，所有主要的用户需求已通过用例和用例图得以描述；所有重要的风险已被标识，并对风险应对措施了如指掌；能够比较精确地估算实现每一用例的时间。第47页，共115页，2023年，2月20日，星期四3.构造在构造阶段,开发人员通过一系列的迭代完成对所有用例的软件实现工作,在每次迭代中实现一部分用例.以迭代方式实现所有用例的好处在于,用户可以及早参与对已实现用例的实际评价,并提出改进意见.这样可有效降低大型软件系统的开发风险。

第48页，共115页，2023年，2月20日，星期四在实际开始构造软件系统之前，有必要预先制定迭代计划。计划的制定需遵循如下两项原则：（１）用户变为业务价值较大的用例应优先安排；（２）开发人员评估后认为开发风险较高的用例应优先安排。在迭代计划中，要确定迭代次数、每次迭代所需时间以及每次迭代中应完成（或部分完成）的用例。

第49页，共115页，2023年，2月20日，星期四每次迭代过程由针对用例的分析、设计、编码、测试和集成5相子阶段构成。在集成之后，用户可以对用例的实现效果进行评价，并提出修改意见。这些修改意见可以在本次迭代过程中立即实现，也可以在下次迭代中再予以考虑。

构造过程中，需要使用UML的交互图来设计用例的实现方法。为了与设计得出的交互图协调一致，需要修改或精化在细化阶段绘制的作为领域模型的类图，增加一些为软件实现所必需的类、类的属性或方法。

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

第52页，共115页，2023年，2月20日，星期四4移交在移交阶段，开发人员将构造阶段获得的软件系统在用户实际工作环境（或接近实际的模拟环境）中试运行，根据用户的修改意见进行少量调整。

第53页，共115页，2023年，2月20日，星期四6．3基于UML的需求分析

基于UML的需求分析大致可分为以下步骤：（１）利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总、分类、抽象。形成用例；确定执行者与用例、用例与用例图之间的关系，生成用例图

第54页，共115页，2023年，2月20日，星期四注意:两个步骤并没有时序关系，它们可以并行展开，如图上图中,从描述开始分开走两个步骤第55页，共115页，2023年，2月20日，星期四（２）利用包图及类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。

第56页，共115页，2023年，2月20日，星期四5.3.1开发场景场景是指从单个执行者的角度观察目标软件系统的功能和外部行为。这种功能通过系统与用户之间的交互来表征。场景是用户与系统之间进行交互的一组具体的动作。相对于用例（见5.3.2节）而言，场景是用例的实例，而用例是某类场景的共同抽象。对场景的完事描述应包含场景名称、执行者实例，前置条件、事件流和后置条件。

第57页，共115页，2023年，2月20日，星期四“家庭保安系统”的软件允许用户在安装时进行系统配置，实施对传感器的监控并通过控制面板与用户进行信息交互。配置操作包括：(1)指定每一传感器的种类和编号；(2)设置开、关机密码；(3)指定报警电话电码；(4)指定报警延迟和电话重拨延迟时间(以秒为单位)；例：家庭保安系统第58页，共115页，2023年，2月20日，星期四根据以上初步描述:该系统具有“系统配置”、“开机”、“关机”、“门窗监测”、“烟雾监测”和“复位”等场景。

当软件系统收到传感器发出的数据后，判别是否出现异常事件。

如果是，则在指定的延迟时间内拨报警电话号码，拨号操作将按照重拨延迟反复进行，直至电话接通。然后软件系统负责报告时间、地点和异常事件的性质。

第59页，共115页，2023年，2月20日，星期四门窗监测场景的具体描述：场景名称：门窗监测。参与执行者实例：警报器、报警电话、显示器和门窗监视器前置条件：系统已开机。主事件流：(1)门窗监视器发现门或窗户发生异动，向软件系统报告异常事件。(2)软件系统启动警报器并拨报警电话号码。(3)报警电话接通后，软件系统播出语音，报告异常事件发生的时间、地点和事件的性质（门窗异动）。(4)系统在控制面板的显示器上报警时间及当前状态（报警：门窗异动）。后置条件：系统处于“报警”状态。第60页，共115页，2023年，2月20日，星期四场景分类根据场景作用的不同，可以将其划分为以下类型：(1)实际场景。对实际的业务处理流程或其优化流程的描述。它是用户需求的重要组成部分。(2)设想场景。分析人员对目标软件系统投入应用后经改进或优化的业务流程的描述。这种可视为一种纸面原型,用于帮助分析人员挖掘潜在的用户需求。第61页，共115页，2023年，2月20日，星期四(3)评价场景。以确认需求或提出改进建议为主要目的的业务流程描述。评价场景可以在用例生成后用例进行实例化而形成，以便用户对用例进行评价或改进。(4)培训场景。面向开发人员及用户解释系统的功能和外部行为的业务流程描述。

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

第64页，共115页，2023年，2月20日，星期四5.3.2生成用例

用例含义：

1.从外部用户的视角看，一个用例是执行者（actor）与目标软件系统之间的一次典型的交互作用。

2.从软件系统内部的视角出发，一个用例代表系统执行的一系列动作，动作执行的结果能够被外部的执行者所察觉。

执行者是指外部用户或外部实体在系统中扮演的角色。

第65页，共115页，2023年，2月20日，星期四用例的完整描述包含：用例名称、能与执行者、前置条件、一个主事件流、零到多个辅事件流和后置条件。主事件流表示正常情况下执行者与系统之间的信息交互及动作序列，辅事件流则表示特殊情况或异常情况下的信息交互及动作序列。用例主要来源于分析人员对场景的分类和抽象，即将相似的场景进行归并，使一个用例可以通过实例化和参数调节而涵盖多个场景。第66页，共115页，2023年，2月20日，星期四例:“家庭保安系统”其中的“开机”、“关机”、“复位”3个场景可以归并为“命令处理”，3个场景之间的差异通过用户命令种类的不同而体现。“门窗监测”、“烟雾监测”两个场景也可归并为统一的“传感器监测”用例。对于熟悉业务领域的分析师而言，也可以略过场景，直接从业务需求描述中获取用例。在“家庭保安系统”中，执行者有“用户”、“传感器”、“报警电话”和“显示器”，用例有“系统配置”、“命令响应”和“传感器监测”。

第67页，共115页，2023年，2月20日，星期四以“传感器监测”为例说明用例的一向描述格式用例名称:

传感器监测。参与执行者:

各类传感器、警报器、报警电话和显示器。前置条件:

系统已开机。第68页，共115页，2023年，2月20日，星期四主事件流：(1)传感器向目标软件系统上报其监测数据，系统判别监测数据是否正常。(2)如果不正常，系统启动警报器，拨报警电话号码。(3)报警电话接通后，软件系统播出语音，报告异常事件发生的时间、地点和事件的性质。(4)系统在控制面板的显示器上显示报警时间及当前状态（报警）。第69页，共115页，2023年，2月20日，星期四辅事件流：(1)如果报警电话无人接听，则按照重拨延迟反复拨号，直至电话接通，再转入主事件流的步骤（3）。(2)如果重拨次数达到系统预设的最大次数，电话仍无人接听，则跳过主事件流的步骤（3），转入步骤（4）。后置条件：如果已发现异常监测数据，系统处于“报警“状态；否则，系统处于正常的监测状态。第70页，共115页，2023年，2月20日，星期四5.3.3用活动图表示用例

用例的描述既可采用自然语言，也可采用活动图。

活动图。后一表示未能更为精确和直观。

第71页，共115页，2023年，2月20日，星期四UML活动图用例的事件流或操作均表示为一系列的活动，每个活动在活动图中被表示为一个节点。节点之间的有向边表示活动的执行顺序。在节点间的连接边上可以附加条件表达工，以表示在有向过的源节点执行完成后，如果条件成立，则开始执行有向边的目标节点所表示的活动；如果条件不成立，则目标节点的活动不被执行。条件表达式一般出现在以菱形为源节点的有向边上。第72页，共115页，2023年，2月20日，星期四第73页，共115页，2023年，2月20日，星期四菱形在活动图中属特殊节点，用来表示条件判断。

菱形在活动图中属特殊节点，用来表示条件判断。例如，在图５.8中，“密码验证”活动的有向边上。如果“（密码正确）”，则开始“开始选择功能”活动；否则，回到“输入密码“活动。第74页，共115页，2023年，2月20日，星期四活动图还可以表示处理过程的并发。活动图的同步条（水平或垂直粗线）可以将一条有向边分叉为多个并发执行的分支进程，或将多个有向边上的进程同步合并为一个进程。例如，在图５.8中，当用户选择取款操作，输入取款金额，肯系统验证其要求的金额小于等于余额之后，系统分叉为两个并发进程：点钞、出钞和扣减余额、打印交易信息。此后，再合并为一个进程，进行“选择功能”活动。

第75页，共115页，2023年，2月20日，星期四为了描述活动的责任对象，活动图引进了“泳道”的概念。泳道是由垂直长线分割出来的矩形区域，在泳道上方的对象负责该矫形区域内的所有活动。例如，在图5.8中，类“Customer”的对象负责“插入银行卡”、“输入密码”、“选择功能”和“输入金额”4项活动，其余活动由类“ATMsystem”的对象负责。

第76页，共115页，2023年，2月20日，星期四用例的活动图表示[“传感器监测”用例]第77页，共115页，2023年，2月20日，星期四生成用例图

执行者与用例之间的关系有两例种：触发执行与信息交换。执行者与用例之间可能兼具这两种关系;例如，“在家庭保安系统”中，执行者“用户”在触发用例“命令响应”的同时，还要向用例传送命令信息。在UML用例图中，从执行者指向用例的边表示触发执行和/或信息交换，从用例指向执行者的边则表示用例将其生成的信息传递给执行者。第78页，共115页，2023年，2月20日，星期四UML的用例与用例之间存在如下两种关系：(1)使用（use）关系。如果有一个公共的动作序列存在于多个用例中，为避免重复，并使需求模型更简洁，可以将公共动作序列抽出来的构成新的独立用例。这样，原来的多个用例与新的用例之间便通过使用关系来连接。例如，在“家庭保安系统”中“系统配置”和“命令响应”两个用例使用公共的“密码验证”子用例。

第79页，共115页，2023年，2月20日，星期四(2)扩展（extend）关系。如果一个用例的动作序列完全包含另一个用例的动作序列，且前者含有后者所不具备的一些特殊情况下的处理动作，则称前者扩展后者。例如，图5.10听“传感器监测”用例仅包含正常的处理流程，而“报警电话未接通”用例除正常流程处还增加了“重复拨号”以及“重拨次数达到最大次数仍无人接听”这两种异常处理动作。第80页，共115页，2023年，2月20日，星期四“家庭保安系统”的用例图

第81页，共115页，2023年，2月20日，星期四5.3.5建立顶层架构

顶层架构的主要目的是为后续的分析和设计活动建立一种结构和分划，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。顶层架构是分析和设计的阶段成果的承载体。随着开发过程的推进，框架中的内容不断丰富、翔实，最终演进为完事的面向对象软件结构。

UML包图是表示顶层架构的适当机制，

第82页，共115页，2023年，2月20日，星期四1.UML包图

包是UML对类进行分组的一种机制。可以从某种视角将具有比较密切的关联的一些类划分为一个包，分属于不同包的两个类之间的关联则比较松散。包的划分是实现“分而治之”的重要技术手段。

包之间存在两种关系：依赖和构成。如果对类A的修改将导致类B的改变，则称B领带于A。如果两个包中存在具有依赖关系的两个类，则认为这两个分属的包之间存在依赖关系。

第83页，共115页，2023年，2月20日，星期四例:第84页，共115页，2023年，2月20日，星期四例如，上图中的“订单”包依赖于“客户”包。包的构成关系是指包是可以嵌套的，即包中不仅可包含类，还可以包含子包。在上图中，“领域”包由“订单”和“客户”两个子包构成。上图中，“数据库接口”类仅定义抽象的数据访问、数据操作的接口函数，而“Oracle接口”包和“DB2接口”包则基于具体的数据库管理系统逐一实现了通用接口中定义的抽象接口函数。为了表示软件架构，还需要在包之间引进一种称为“连接器”的边。连接器用来表示包之间的信息传递、事件发送和软件调用等关系，且有单向和双向（即无向）之分。

第85页，共115页，2023年，2月20日，星期四2.软件顶层架构的设计建立软件系统顶层架构的基本方法是，结合实际需求，人既往的架构设计经验模型中选取适当者，再进行微调或局部改造。

第86页，共115页，2023年，2月20日，星期四目前有如下几种主要的架构模式：

（１）流程处理模式。流程处理系统以算法和数据引进中心，其系统功能由一系列的处理步骤构成，相邻的处理步骤之间以数据流通管道相互连接。

下图表示具有3处理步骤的流程处理模式。这些处理步骤都使用公共的系统服务（例如数据库访问服务），处理命令来自用户界面，处理的进度和结果也通过用户界面呈现。

第87页，共115页，2023年，2月20日，星期四第88页，共115页，2023年，2月20日，星期四（２）客户/服务器模式。如图５.13所示，客户端负责用户输入和处理结果的呈现，服务器端则负责后台的业务逻辑处理。

第89页，共115页，2023年，2月20日，星期四模型

–视图

–控制器（MVC）模式。如下图该模式将整个软件系统划分为模型，视图和控制器3个部分。模型负责维护并保存具有持久性的业务数据，实现业务处理功能，并将业务数据的变化情况及时通知视图；视图负责呈现模型的业务数据，响应模型变化通知，更新呈现形式，并向控制器传递用户的界面动作；控制器负责将用户的界面动作映射为模型中业务处理功能并实际调用之，然后根据模型返回的业务处理结果选择新的视图。MVC模式特别适合于分布应用软件，尤其是Web应用系统。

第90页，共115页，2023年，2月20日，星期四第91页，共115页，2023年，2月20日，星期四（４）分层模式。如图５.15所示，分层模式将整个软件系统分为若干层次，最顶层直接面向用户提供软件系统的操作界面，其余各层为紧邻其上的层次提供服务。层次划时分的主要原则是：较蝗变化的软件部分（例如用户界面、与业务逻辑紧密相关的部件）置于较高层次，较稳定的软件部分（例如公共的技术服务部件）则位于较低层次；每一层次尽量只访问其紧邻下层提供的服务，避免越级访问，尤其要避免逆向访问（上层模块为下层模块提供服务）；。

第92页，共115页，2023年，2月20日，星期四在许多情况下，可以将目标软件系统的外部接口置入较低层次，目标软件系统其余部分对处部系统的访问或操作均通过这些外部接口所提供的公共服务来完成。分层模式可以有效地降低软件系统的耦合度，因此其应用十分普遍第93页，共115页，2023年，2月20日，星期四在确立顶层架构的过程中，需综合考虑以下因素：（１）架构中包的数量。原则上，如果每个包中包含的软件元素（例如类）的数量过多，应考虑将其进一步细分；如果过少，则说明架构过早地陷入了细节，架构划分返工的可能性较大，同时也不合理地限制了后续分析和设计活动的自由空间。（２）架构中包之间的耦合度。包之间的依赖关系和连接关系应尽量简单、稀疏，例如，在分层结构中，通常要求某一层中的软件元素只与同层及相邻下一层的元素之间存在依赖关系。第94页，共115页，2023年，2月20日，星期四（３）软件元素的稳定性。要尽量抽取不稳定的软件元素之中相对稳定的部分将不稳定的软件元素分类聚集于少数几个包中，以提高软件系统的可维护性。（４）软件元素的必然性。可以将可选功能和必须实现的功能分置于架构中不同的包或子包之中。（５）作为软件系统运行环境的物理网络拓朴。根据软件元素在分布环境的部署情况区分顶层架构中的包，可以使包之间的消息传递与物理节点之间的通信相吻合，使后续的分析和设计活动受益于顶层架构中明确定义的通信关系。第95页，共115页，2023年，2月20日，星期四（６）软件元素的安全、保密级别。根据安全访问的权限划分顶层架构中的包或者子包。（７）开发团队的技术专长。根据开发人员在问题领域和软件技术领域不同的专长划分顶层架构中的包，使每个包都能分配给最适合的开发人员进行后续的分析、设计、编码和测试等，从而有利于并行开发。第96页，共115页，2023年，2月20日，星期四5.3.6建立领域概念模型

1.在用户需求和相关的业务领域中,抽取全局性的概念,并研究这些概念之间的关系。2.在UML中，用类表示概念，用类图表示领域概念模型。

第97页，共115页，2023年，2月20日，星期四1．UML类图

UML的类包含3个部分：类的名称、属性列表和方法列表，其表示图元如图

注意:在需求分析的早期不需要一次性列举类的所有属性和方法。刚开始可以仅标识类名，以后随着分析、设计的不断推进而逐步完善属性列表和方法列表。

第98页，共115页，2023年，2月20日，星期四UML类之间的关系的主要有继承、聚集、关联和依赖。

1.继承关系表示子类重用父类的属性的操作，子类的对象也是父类的对象例(如图)“教务管理人员”、“学生”和“老师”都是泛化的“用户”类的子类，它们继承来自“用户”类的用户姓名、标识码、密码等属性以及用户注册、密码验证、退出系统等操作，第99页，共115页，2023年，2月20日，星期四聚集关系是部分

–整体关系的直接模拟。

细分为普通聚集和构成关系两种。普通聚集关系是一个部件类对象可同时参与多个整体类对象;构成关系则限定一个部件类对象在任意时刻只能参与一个整体类对象，部件类对象与整体类对象共存亡。例如图第100页，共115页，2023年，2月20日，星期四关联关系表示在两个类的对象之间存在着一种用于消息传递的稳定通道。例如，在课程注册管理系统中，“学生”类“老师”类与“课程设置”类之间存在关联关系，因为“课程设置”肯定与选课学生和授课老师有关，学生和教师他都需要查询课程设置中有关信息，如上课时间、地点和选课学生清单等。第101页，共115页，2023年，2月20日，星期四参与聚集、构成和关联关系的两个类的对象之间往往存在着数量对应关系，这种关系是业务规则的具体表现。当分析和设计推进到一定阶段之后，应该将这种数量对应关系在这三种关系的表示边上明确地标示出来。例如，上图表示对于每个“课程设置”对象，选课学生应不少于10个，不多于50个。每个学生在一个学期中所选的课程应不少于4门、不多于8门。第102页，共115页，2023年，2