软件工程.ppt

2024/4/21 周日1第六章面向对象的需求分析o面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。它包含面向对象风格的图形语言机制以及用于指导需求分析的面向对象方法学。o面向对象的思想最初起源于1960年代中期的仿真程序设计语言Simula67。1980年代初出现的Smalltalk语言及其程序设计环境对面向对象技术的推广应用起到了显著的促进作用。o1990年代中后期诞生并迅速成熟的UML（统一建模语言，UnifiedModelingLanguage）是面向对象技术发展的一个重要里程碑。UML统一了面向对象建模的基本概念、术语和表示方法，不仅为面向对象的软件开发过程提供了能力丰富的表达手段，而且也为软件开发人员提供了互相交流、分享经验的共用语言。2024/4/21 周日2面向对象的需求分析o面向对象的概念与思想oUML概述o基于UML的需求分析以“家庭保安系统”为实例，介绍与需求分析相关的部分UML语言机制以及基于UML的面向对象的需求分析方法和过程。第六章面向对象的需求分析2024/4/21 周日36.1面向对象的概念与思想o客观世界中的应用问题都是由实体及其相互关系构成的。o可以将客观世界中与应用问题有关的实体及其属性抽象为问题空间中的对象。o为应用问题寻求软件解，是借助于计算机语言对其提供的实体施加某些动作，以动作的结果给出问题的解。汇编语言提供的实体是寄存器、存储单元；过程式程序设计语言提供的实体是变元、数组、记录、文件等。这些实体构成解空间中的对象。o问题空间中对象的行为是丰富多彩的，而软件解空间中对象的行为却是单调刻板的。例如，存储单元只能作存取操作，文件只能作读、写和定位操作。o只有借助于相当复杂的方法操纵解空间中的对象才能得到问题的软件解。这就是所谓的“语义断层”。第六章面向对象的需求分析2024/4/21 周日4面向对象的概念与思想o面向对象(Object-Oriented,简称OO)的需求分析方法通过提供对象、对象间消息传递等语言机制让分析人员在解空间中直接模拟问题空间中的对象及其行为，从而削减了语义断层，为需求建模活动提供了直观、自然的语言支持和方法学指导。6.1面向对象的概念与思想2024/4/21 周日5面向对象的概念与思想为了在解空间模拟现实问题并与人类的思维习惯相一致，OO方法学包容了以下核心概念：(1)对象对象是现实世界中个体或事物的抽象表示，是其属性和相关操作的封装。属性表示对象的性质，属性值规定了对象所有可能的状态。对象的操作是指该对象可以展现的外部服务。例如，大型客机可视为对象，它具有位置、速度、颜色、容量等属性，对于该对象可施行起飞、降落、加速、维修等操作，这些操作将或多或少地改变飞机的属性值(状态)。6.1面向对象的概念与思想2024/4/21 周日6面向对象的概念与思想（2）类。类表示某些对象在属性和操作方面的共同特征。例如，直升飞机、大型客机、轰炸机可归为飞行器类。共同属性有：位置、速度和颜色等。共同操作有：起飞、降落、加速和维修等。6.1面向对象的概念与思想2024/4/21 周日7面向对象的概念与思想(3)继承类之间的继承关系是现实世界中遗传关系的模拟，它表示类之间的内在联系以及对属性和操作的共享，即，子类可以沿用父类(被继承类)的某些特征。子类也可以具有自己独有的属性和操作。例如，飞行器、汽车和轮船可归于交通工具类，飞行器类可以继承交通工具类的某些属性和操作。6.1面向对象的概念与思想2024/4/21 周日8面向对象的概念与思想(4)聚集现实世界普遍存在部分整体关系。例如，飞机可由发动机、机身、机械控制系统、电子控制系统等构成。部分整体关系在OO方法学中表示为类之间的聚集关系。在聚集关系下，部分类的对象是整体类对象的一个组成部分。6.1面向对象的概念与思想2024/4/21 周日9面向对象的概念与思想（5）消息消息传递是对象与其外部世界相互关联的唯一途径。对象可以向其它对象发送消息以请求服务，也可以响应其它对象传来的消息，完成自身固有的某些操作，从而服务于其它对象。例如，直升飞机可以响应轮船的海难急救信号，起飞，加速，飞赴出事地点并实施救援作业。因为对象的操作主要用来响应外来消息并为其它对象提供服务，所以它们也被称作“外部服务”。面向对象=对象+类+继承+聚集+消息。6.1面向对象的概念与思想2024/4/21 周日106.2UML概述6.2.1UML的语言机制UML主 要 以 Booch方 法、OMT方 法 71和OOSE方法为基础，同时也吸收了其他面向对象建模方法的优点，形成了一种概念清晰、表达能力丰富、适用范围广泛的面向对象的标准建模语言。第六章面向对象的需求分析2024/4/21 周日11UML的语言机制UML通过图形化的表示机制从多个侧面刻画系统的分析和设计模型。UML共定义十种视图，可分四类：(1)用例图（usecasediagram）从外部用户的角度描述系统的功能，并指出功能的执行者。6.2UML概述2024/4/21 周日12UML的语言机制(2)静态图q类图(classdiagram)、类图描述系统的静态结构，类图的结点表示系统中的类及其属性和操作，类图的边表示类之间的联系，包括继承、关联、依赖、聚合等。q对象图(objectdiagram)对象图是类图的一个实例。它描述在某种状态下，或者在某一时间段系统中活跃的对象及其关系。在对象图中，一个类可以拥有多个活跃的对象实例。q包图(packagediagram)包图描述系统的分解，表示包(package)以及包之间的关系。包由子包及类组成。包之间的关系包括继承、构成与依赖关系。6.2UML概述2024/4/21 周日13UML的语言机制(3)行为图o交互图(interactivediagram)o状态图(statechartdiagram)o活动图(activitydiagram)它们从不同的侧面刻画系统的动态行为。交互图描述对象之间的消息传递。它又可分为顺序图(sequencediagram)与 合 作 图(collaborationdiagram)两种形式。顺序图强调对象之间消息发送的时间序。合作图更强调对象间的动态协作关系。合作图也可通过消息序号来表示消息传递的时间序，只不过这种表示不如顺序图那样直观。6.2UML概述2024/4/21 周日14UML的语言机制o状态图描述类的对象的动态行为。o它包含对象所有可能的状态、活动图描述系统为完成某项功能而执行的操作序列，这些在每个状态下能够响应的事件以及事件发生时的状态迁移与响应动作。操作序列可以并发和同步。o活动图中包含控制流和信息流。控制流表示一个操作完成后对其后续操作的触发，信息流则刻画操作之间的信息交换。6.2UML概述2024/4/21 周日15UML的语言机制(4)实现图(implementationdiagram)描述软件系统的实现。o构件图(componentdiagram)描述软件实现系统中各组成部件以及它们之间的依赖关系。一个部件可能是一个资源描述文件、一个二进制文件或一个可执行文件。构件图用于理解和分析软件各部分之间的相互影响程度。6.2UML概述2024/4/21 周日16UML的语言机制o部署图(deploymentdiagram)描述软件系统运行环境的硬件及网络的物理体系结构。结点表示实际的计算机和设备，边表示结点之间的物理连接关系,也可显示连接的类型及结点之间的依赖性。在结点内部，可以放置可执行部件和对象以显示结点与可执行软件单元之间的对应关系。部署图对于软件安装工程师有重要的参考价值。6.2UML概述2024/4/21 周日17例:课程注册管理系统的用例图o课表维护、个人课程规划和选课学生花名册查询。教务管理人员使用“课表维护”用例，设置或修改课程属性（课程的时间、地点、上课老师等），增删课程；o学生使用“个人课程规划”用例选课、修改自己的个人课表，收费管理系统根据每个学生的选课情况计算其应缴费用；o老师使用“选课学生花名册查询”用例获取选定其所开课程的学生花名册。6.2UML概述2024/4/21 周日18课程注册管理系统的用例图o图6.2表示课程注册管理系统包括：“教务管理人员”、“学生”、“老师”、“课程”、“课程设置”、“课程注册表”、“课程注册管理器”、“课程管理器”八个类。o前三个类为一般化的“用户”类的子类。一门“课程”可由一到多个“课程设置”构成，例如，对于全校性的公共基础课，由于选修的学生太多，必须安排不同的老师、不同的教室或者不同的时间段。o“学生”、“老师”与“课程设置”之间，“课程注册表”与“课程注册管理器”之间，以及“课程注册管理器”与“课程”之间存在着关联关系。6.2UML概述2024/4/21 周日19课程注册管理系统的类图6.2UML概述2024/4/21 周日20用UML顺序图表示“个人课程规划”用例中的学生选课过程6.2UML概述2024/4/21 周日21用UML协作图表示“个人课程规划”用例中的学生选课过程o6.2UML概述2024/4/21 周日22UML状态图示例o“课程设置”对象的状态图表示，每个“课程设置”最多只能容纳50个选课学生。6.2UML概述2024/4/21 周日23UML的语言机制o本章的后续章节将结合需求分析过程介绍UML的用例图、包图、类图和活动图o第十章将结合软件设计过程介绍顺序图、协作图、状态图和活动图。6.2UML概述2024/4/21 周日246.3基于UML的需求分析初步业务需求描述形成后，基于UML的需求分析分为以下步骤：（1）利用用例及用例图表示需求：从业务需求描述出发获取执行者和场景；对场景进行汇总、分类、抽象，形成用例；确定执行者与用例、用例与用例图之间的关系，生成用例图。（2）利用包图及类图表示目标软件系统的总体框架结构：根据领域知识、业务需求和工作经验，设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。第六章面向对象的需求分析2024/4/21 周日25需求分析过程6.3基于UML的需求分析2024/4/21 周日266.3.1开发场景o场景从单个执行者的角度观察目标软件系统的功能和外部行为。这种功能通过系统与用户之间的交互表征。场景是用户与系统进行交互的一组具体的动作。场景是用例的实例，而用例是某类场景的共同抽象。o对场景的完整描述包含场景名称、执行者实例、前置条件、事件流和后置条件。o如，“家庭保安系统”的初步需求描述，具有系统配置、开机、关机、门窗监测、烟雾监测、复位等场景。6.3基于UML的需求分析2024/4/21 周日27监测场景的描述场景名称：门窗监测。参与执行者实例：警报器，报警电话，显示器，门窗监视器。前置条件：系统已开机。事件流：（1）门窗监视器发现门或窗户发生异动，向软件系统报告异常事件。（2）软件系统启动警报器并拨报警电话号码。（3）报警电话接通后，软件系统播出语音，报告异常事件发生的时间、地点和事件的性质（门窗异动）。（4）系统在控制面板的显示器上显示报警时间及当前状态（报警：门窗异动）。后置条件：系统处于“报警”状态。6.3基于UML的需求分析2024/4/21 周日28场景的分类(1)实际场景对实际的业务处理流程或其优化流程的描述，是用户需求的重要组成部分。(2)设想场景分析人员对目标软件系统投入应用后经改进或优化的业务流程的描述。这种场景是纸面原型，帮助分析人员挖掘潜在的用户需求。(3)评价场景确认需求或提出改进建议为主要目的的业务流程描述。评价场景可以在用例生成后对用例进行实例化而形成，以便用户对用例进行评价或改进。(4)培训场景：面向开发人员及用户解释系统的功能和外部行为的业务流程描述。6.3基于UML的需求分析2024/4/21 周日29场景的获取确定执行者和场景的关键在于理解业务领域和初步需求描述文档。下列问题的回答可帮助分析人员获取场景：（1）目标软件系统有哪些执行者？（2）执行者希望系统执行的任务有哪些？（3）执行者希望获得哪些信息？这些信息由谁生成？由谁修改？（4）执行者需要通知系统哪些事件？系统响应这些事件时会表现出哪些外部行为？（5）系统将通告执行者哪些事件？场景将促成开发人员和用户对于业务处理流程和目标软件系统的功能范围的共同理解。在场景确定之后，通过对场景的汇总、分类归并、抽象即可形成用例。6.3基于UML的需求分析2024/4/21 周日306.3.2生成用例o从外部用户的视角看，一个用例是执行者(actor)与目标软件系统之间一次典型的交互作用。o从软件系统内部的视角出发，一个用例代表着系统执行的一系列动作，动作执行的结果能够被外部的执行者所察觉。o执行者指外部用户或外部实体在系统中扮演的角色。o如果多个用户在使用目标软件系统时扮演同一角色，这些用户用单一执行者表示。o如果一个用户扮演多种角色，则需要用多个执行者来表示同一用户。6.3基于UML的需求分析2024/4/21 周日31生成用例o对用例的完整描述包括用例名称、参与执行者、前置条件、一个主事件流、0到多个辅事件流、后置条件。o主事件流表示正常情况下执行者与系统之间的信息交互及动作序列，辅事件流则表示特殊情况或异常情况下的信息交互及动作序列。o显式地分隔主、辅事件流是为了使分析人员首先聚焦于正常的业务处理流程，同时也便于用例的读者理解业务需求。6.3基于UML的需求分析2024/4/21 周日32生成用例用例源于分析人员对场景的分类和抽象，对相似场景进行归并，使得一个用例可以通过实例化、参数调节而涵盖多个场景。例如，“家庭保安系统”中的“开机”、“关机”、“复位”三个场景可以归并为“命令处理”用例，三个场景之间的差异通过用户命令区分。门窗监测、烟雾监测两个场景可归并为统一的“传感器监测”用例。熟悉业务领域的分析师，可以略过场景，直接从业务需求描述中获取用例。在家庭保安系统中，执行者有“用户”、“传感器”、“警报器”、“报警电话”、“显示器”，用例有“系统配置”、“命令响应”和“传感器监测”。6.3基于UML的需求分析2024/4/21 周日33“传感器监测”用例的描述用例名称：传感器监测参与执行者：各类传感器，警报器，报警电话，显示器前置条件：系统已开机。主事件流：（1）传感器向目标软件系统上报其监测数据，系统判断监测数据正常。（2）如果不正常，系统启动警报器，拨报警电话号码。（3）报警电话接通后，软件系统播出语音，报告异常事件发生的时间、地点和事件的性质。（4）系统在控制面板的显示器上显示报警时间及当前状态（报警）。6.3基于UML的需求分析2024/4/21 周日34“传感器监测”用例的描述辅事件流：（1）如果报警电话无人接听，则按照重拨延迟反复拨号，直至电话接通，再转入主事件流的步骤（3）。（2）如果重拨次数达到系统预设的最大次数，电话仍无人接听，则跳过主事件流的步骤（3），转入步骤（4）。后置条件：如果已发现异常的监测数据，系统处于“报警”状态；否则系统处于正常的“监测”状态。6.3基于UML的需求分析2024/4/21 周日356.3.3用活动图表示用例o用例的描述既可采用自然语言，也可采用活动图，活动图表示法更为精确、直观。o下面介绍活动图的语法机制，然后结合实例说明如何用活动图表示用例。6.3基于UML的需求分析2024/4/21 周日361UML活动图o用例的事件流或者操作均可表示为一系列的活动，每个活动在活动图中被表示为一个结点。o结点之间的有向边表示顺序执行的活动。o在结点间的连接边上可以附加条件表达式，表示在有向连接边的源结点执行完成后，如果条件成立，则开始执行有向连接边的目标结点所表示的活动；如果条件不成立，则目标结点的活动不执行。o菱形在活动图中表示条件判断，条件表达式一般出现在以菱形为源结点的有向边上。o活动图可以表示过程的并发。活动图的同步条(水平或者垂直粗线)可以将一条有向连接边分叉为多个并发执行的分支进程，或将多个有向连接边上的进程同步合并为一个进程。6.3基于UML的需求分析2024/4/21 周日37UML活动图泳道o为了描述活动的责任对象，活动图引进了“泳道”的概念。泳道是由垂直长线分割出来的矩形区域，在泳道上方的对象负责该矩形区域内的所有活动。如，在图6.8中，类“Customer”的对象负责“插入银行卡”、“输入密码”、“选择功能”、“输入金额”四项活动，其余活动由类“ATMsystem”的对象负责。6.3基于UML的需求分析2024/4/21 周日38典型的活动图6.3基于UML的需求分析2024/4/21 周日392用例的活动图表示传感器监测用例活动图6.3基于UML的需求分析2024/4/21 周日406.3.4生成用例图o执行者与用例之间的关系o触发执行o信息交换o触发执行与信息交换o如，在“家庭保安系统”中，执行者“用户”在触发用例“命令响应”的同时，还要向用例传送命令信息。o在UML用例图中，从执行者指向用例的边表示触发执行和/或信息交换，从用例指向执行者的边则表示用例将生成的信息传递给执行者。6.3基于UML的需求分析2024/4/21 周日41UML用例与用例之间的关系（1）使用（use）关系，如果多个用例都有一个公共的动作序列，为避免重复并使模型简洁，可以将公共动作序列抽取出来，构成新的独立用例。原来的多个用例与新的用例之间通过使用关系连接。如，“家庭保安系统”中，“系统配置”和“命令响应”两个用例都使用公共的“密码验证”子用例。（2）扩展（extend）关系。如果一个用例的动作序列完全包含另一个用例的动作序列，且前者含有后者所不具备的一些特殊情况下的处理动作，则称前者扩展后者。例如，图6.10中的“传感器监测”用例仅包含正常的处理流程，而“报警电话未接通”用例除正常流程外还增加了“重复拨号”以及“重拨次数达到最大次数仍无人接听”这两种异常处理动作。6.3基于UML的需求分析2024/4/21 周日42“家庭保安系统”的用例图6.3基于UML的需求分析2024/4/21 周日436.3.5建立顶层架构o顶层架构的主要目的是为后续的分析和设计活动建立一种结构和分划，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。o顶层架构是分析和设计阶段的成果。随着开发过程的推进，框架中的内容不断丰富、翔实，最终演进为完整的面向对象软件结构。6.3基于UML的需求分析2024/4/21 周日441UML包图oUML包图是表示顶层架构的机制。下面首先介绍包图的语法机制，然后探讨建立顶层架构的方法与原则。o包是UML支持对类分组的一种机制。可以从某种视角，将某些关联密切的类划为一个包，而不同包的两个类的关联应比较松散。o对于大型软件系统，包的划分是实现“分而治之”的重要技术手段。6.3基于UML的需求分析2024/4/21 周日45UML包图包的依赖和构成关系o如果对类A的修改将导致类B的改变，则称B依赖于A。如果两个包中存在具有依赖关系的两个类，则称这两个包之间存在依赖关系。o包的构成关系包可以嵌套，包可包含类，也可包含子包。o为了表示软件架构，还需要在包之间引进“连接器”边，连接器表示包之间的信息传递、事件发送、软件调用等关系。o连接器分为单向和双向（即无向）。6.3基于UML的需求分析2024/4/21 周日46包图示例o“领域”包由“订单”和“客户”两个子包构成，“订单”包依赖于“客户”包。o数据库接口类仅定义抽象数据访问，数据操作。Oracle接口包和DB2接口包基于具体的数据库管理系统实现通用接口定义的抽象接口函数。6.3基于UML的需求分析2024/4/21 周日472软件顶层架构的设计方法结合实际需求，选取架构模式，再进行局部调整。主要架构模式o流程处理模式o客户/服务器模式、o模型视图控制器模式o分层模式6.3基于UML的需求分析2024/4/21 周日48软件顶层架构的设计（1）流程处理模式。o流程处理系统以算法和数据结构为中心，其系统功能由一系列的处理步骤构成，相邻处理步骤用数据流通管道连接。o流程处理模式适用于批处理方式的软件系统，不适合交互式系统。6.3基于UML的需求分析2024/4/21 周日49流程处理模式o流程处理模式具有三个处理步骤。o步骤都使用公共的系统服务（例如数据库访问服务），命令处理和命令处理的进度、结果都通过用户界面。6.3基于UML的需求分析2024/4/21 周日50客户/服务器模式（2）客户/服务器模式。客户端负责用户输入和处理结果的呈现，服务端负责后台业务处理。6.3基于UML的需求分析2024/4/21 周日51模型视图控制器（MVC）模式（3）模型视图控制器模式软件系统由模型、视图和控制器三部分组成。模型负责维护并保存具有持久性的业务数据，实现业务处理功能，并将业务数据的变化情况及时通知视图。视图负责呈现模型中包含的业务数据，响应模型变化通知，更新呈现形式，向控制器传递用户的界面动作。控制器负责将用户的界面动作映射为模型中的业务处理功能并实际调用之，然后根据模型返回的业务处理结果选择新的视图。MVC模式特别适合于分布式应用软件，尤其是Web应用系统6.3基于UML的需求分析2024/4/21 周日52分层模式（4）分层模式o将整个软件系统分为若干层次，最顶层直接面向用户提供软件系统的操作界面，其余各层为紧邻其上的层次提供服务。o分层模式可以有效降低软件系统的耦合度，应用普遍。6.3基于UML的需求分析2024/4/21 周日53分层模式层次划分的主要原则o易变化的部分，如用户界面、与业务逻辑紧密相关的部件，置于高层o稳定部分，如公共的技术服务部件，置于低层；o每层都尽量访问紧邻的下层，避免越级访问，尤其要避免逆向访问即，上层模块为下层模块提供服务；o将目标软件系统的外部接口置入较低层次，系统其余部分对外部系统的访问或操作通过这些外部接口提供的服务来完成。6.3基于UML的需求分析2024/4/21 周日54软件架构o在全面了解软件架构样式的前提下，对于具体的应用需求而言，影响顶层架构选取的主要因素在于分析人员的经验以及他们对每种架构样式与当前软件项目之间匹配程度的判断。o大型软件的顶层架构往往需要使用多种架构样式。如，整个目标软件系统采用分层结构，在系统的不同层次内再分别使用适宜的其他类型的架构模式。6.3基于UML的需求分析2024/4/21 周日55确立软件架构（1）架构中包的数量包中软件元素过多，应对包进一步细分；如果过少，则说明架构过早地陷入细节。（2）架构中包之间的耦合度包的依赖关系、连接关系应尽量简单、松散，如，在分层结构中，通常要求某一层的软件元素只与同层及下一层的元素存在依赖关系。（3）软件元素的稳定性抽取不稳定的软件元素的相对稳定部分，将不稳定的软件元素分类聚集在少数几个包中，以提高软件系统的可维护性。6.3基于UML的需求分析2024/4/21 周日56确立软件架构（4）软件元素的分类将软件可选功能和必须实现功能的软件元素分别置于架构的不同包或子包中。（5）作为软件系统运行环境的物理网络拓朴根据软件元素在分布环境中的布局，划分顶层架构的包，使包的消息传递与物理节点的通信相协调，顶层架构定义的通信关系支持后续的分析和设计活动。6.3基于UML的需求分析2024/4/21 周日57确立软件架构（6）软件元素的安全、保密级别。根据安全访问的权限划分顶层架构中的包或者子包。（7）开发团队的技术专长。根据开发人员在问题和技术领域的专长划分顶层架构，使得每个包的开发都能充分发挥开发人员和团队的技术专长（8）调整软件架构，支持并行开发。6.3基于UML的需求分析2024/4/21 周日586.3.6建立领域概念模型o在用户需求和相关的业务领域中，有一些全局性的概念对于理解需求至关重要。因此，有必要抽取这些概念，研究这些概念之间的关系。oUML类图是表示领域概念模型的机制。下面首先介绍类图的语法机制，然后探讨建立领域概念模型的方法。6.3基于UML的需求分析2024/4/21 周日591UML类图o在UML中，用类表示概念，用类图表示领域概念模型。o在需求分析的早期，不需要一次性列举类的所有属性和方法。刚开始可以仅标识类名，以后随着分析、设计的不断推进而逐步完善属性列表和方法列表。6.3基于UML的需求分析2024/4/21 周日60UML类图oUML的类包含三个部分：o类的名称o属性列表o方法列表o表示图元如图所示。oUML类之间的关系主要有继承、聚集、关联和依赖。o继承关系表示子类重用父类的属性和操作，子类的对象也是父类的对象，有时也称父 类 是 子 类 的 泛 化（generalization）。6.3基于UML的需求分析2024/4/21 周日61UML类图o在课程管理系统中，“教务管理人员”、“学生”和“老师”都是泛化的“用户”类的子类，它们继承来自“用户”类的用户姓名、标识码、密码等属性，以及用户注册、密码验证、退出系统等操作，见图6.2。o类之间的聚集关系是现实世界部分整体关系的模拟。6.3基于UML的需求分析2024/4/21 周日62聚集和构成关系的表示图元UML将聚集关系分为o普通聚集关系:一个部件对象可同时参与多个整体对象。o构成关系:限定一个部件对象在任意时刻只能参与一个整体类的对象，部件类对象与整体类对象共存亡。6.3基于UML的需求分析2024/4/21 周日63关联关系o关联关系表示两个类的对象之间存在着用于消息传递的稳定通道。如，在课程注册管理系统中，“学生”类、“老师”类与“课程设置”类之间存在关联关系，因为“课程设置”与选课学生和授课老师有关，学生和老师都需要查询课程设置的有关信息。o两个类的对象之间往往存在着数量对应关系，这种关系是业务规则的具体表现。因此，当分析和设计推进到一定阶段之后，应该在聚集、构成和关联关系的表示边上明确标示。如，图6.2表示每个“课程设置”对象应不少于10个、不多于50个选课学生。每个学生在一个学期中选课的课程不少于4门、不多于8门。6.3基于UML的需求分析2024/4/21 周日64依赖关系依赖关系依赖类B的对象需要向被依赖类A的对象传递消息；被依赖类A可作为依赖类B操作的形参类型。o依赖关系表示临时性的消息传递通道，操作完成通道消失；o关联关系及强化形态表示消息传递通道在整个对象的生命周期中稳定存在。6.3基于UML的需求分析2024/4/21 周日65依赖关系如，在图6.11中，“订单”包中的类仅依赖于“数据库接口”包中的类（接口），并不需要在它们之间建立关联关系，因为，对数据库的访问和操作仅在订单处理类的函数体中的局部进行。o依赖关系是关联关系的弱化，它表示被依赖的类的变化会影响到依赖类。o依赖的强化是关联，关联的强化是聚合，聚合的强化是构成。6.3基于UML的需求分析2024/4/21 周日662建立领域概念模型为建立UML类图表示的领域概念模型，首先要标识关键概念。关键概念（1）业务需求描述、用例说明；（2）业务领域中的相关规范、标准、术语定义；（3）反映业务领域知识的既往经验。“家庭保安系统”的领域概念模型如图6.18所示。6.3基于UML的需求分析2024/4/21 周日67“家庭保安系统”的领域概念模型6.3基于UML的需求分析2024/4/21 周日68家庭保安系统”的领域概念模型图6.18中新引入了“用户命令处理器”、“系统配置管理器”、“监测器”、“异常事件”和“日志管理器”五个新类。o“用户命令处理器”接收来自用户的操作命令，并将命令处理结果反馈至显示面板。o“系统配置管理器”保存系统的配置信息，协助“用户命令处理器”完成用户对系统配置信息修改，还要负责向系统中的其他类提供配置信息的查询服务。6.3基于UML的需求分析2024/4/21 周日69家庭保安系统”的领域概念模型o“监测器”负责接收传感器的数据，根据系统配置信息判别异常状况，在异常发生时生成“异常事件”对象、触发警报器并拔报警电话。o“日志管理器”向系统中的其他类提供日志的记录和查询服务，日志信息应包括用户命令及处理结果、配置更改的历史记录，异常状况的历史记录等。6.3基于UML的需求分析2024/4/21 周日70小结本章介绍了面向对象的基本概念，概述了UML的语言机制和基于UML的软件开发过程。基于UML的需求分析方法和过程是本章的重点，主要步骤是：(1)从业务需求描述出发标识用例，生成表示用例内容的活动图(可选)，生成表示用例之间、用例与执行者之间关系的用例图。(2)根据领域知识、业务需求描述和既往经验，建立以包图表示的目标软件系统的顶层架构，形成以类图表示的领域概念模型。第六章面向对象的需求分析2024/4/21 周日71谢谢