第10章 面向对象的分析 本章内容结构 本章引言 学习目标 教学内容 本章小结 思考和练习 课堂讨论 2017年3月18日.

Presentation on theme: "第10章 面向对象的分析 本章内容结构 本章引言 学习目标 教学内容 本章小结 思考和练习 课堂讨论 2017年3月18日."— Presentation transcript:

1 第10章 面向对象的分析 本章内容结构 本章引言 学习目标 教学内容 本章小结 思考和练习 课堂讨论 2017年3月18日

2 本章引言 需求分析的任务是对目标系统提出完整、准确、清晰、具体的要求，分析工作主要包括3 项内容：理解、表达和验证。一般地，可通过对象模型、用例（功能）模型、动态行为模型和物理实现模型来表达分析结果。 本章将主要围绕面向对象的分析过程展开，内容包括面向对象分析过程概述及4种模型的建立（对象模型、用例模型、动态行为模型和物理实现模型）。 为实现上述目的，通常需要按照下述步骤完成相关工作： ① 在客户和软件工程师之间对基本用户需求进行交流； ② 定义类（包含属性和方法）；③ 定义类的层次结构； ④ 定义类与类之间的关系； ⑤ 为对象行为和物理实现建模； ⑥ 重复上述步骤直到模型完成。 2017年3月18日

3 学习目标 掌握面向对象分析的 4种模型的特点、用法及相互作用 理解和掌握4种模型在面向对象分析过程中的应用 2017年3月18日

4 教学内容 10.1 面向对象的分析过程 10.2 建立用例模型 10.3 建立对象模型 10.4 建立动态行为模型
10.1 面向对象的分析过程 10.2 建立用例模型 10.3 建立对象模型 10.4 建立动态行为模型 10.5 建立物理实现模型 10.6 面向对象软件开发过程的案例分析 10.7 本章小结和习题 2017年3月18日

5 10.1 面向对象的分析过程 面向对象的分析就是抽取和整理用户需求并建立问题领域精确模型的过程；
10.1 面向对象的分析过程 面向对象的分析就是抽取和整理用户需求并建立问题领域精确模型的过程； 面向对象分析过程，首要的是先建模，通常需要建立4 种形式的模型： 用类和对象表示的对象（静态）模型； 由用例和场景表示的用例（功能）模型； 由状态机图和交互图表示的动态行为模型； 由构件图和部署图表示的物理实现模型。 这4 种模型从4 个不同的角度描述目标系统，从不同侧面反映系统的实质内容，总体可以全面反映对目标系统的需求。其中对象（静态）模型是上述分析阶段几个模型的核心，是动态模型和功能模型的框架。 2017年3月18日

6 10.1 面向对象的分析过程 不同的面向对象方法建模的步骤各有不同，有些方法从建立对象模型入手，而有些方法从建立用例模型入手，在使用各种工具辅助建模时，用例视图一般位于浏览器的最顶部，预示着一般地建议首先建立用例模型，当然工具本身并不限制必须先建立用例模型。目前普遍的做法是从用例建模开始（尤其是对新项目），在实际建模时往往在几个模型之间交替进行，多次迭代和反复。 在面向对象分析建模中需注意，首先，必须向领域专家学习领域知识，必须有领域专家的密切配合；其次，应该仔细研究以前针对相同的或类似的问题域进行面向对象分析得到的结果，这些结果在当前项目中往往有许多是可重用的。 2017年3月18日

7 10.1 面向对象的分析过程 10.1.1 用例模型 10.1.2 对象模型 10.1.3 动态模型 10.1.4 物理（实现）模型
10.1 面向对象的分析过程 用例模型 对象模型 动态模型 物理（实现）模型 种模型之间的关系 2017年3月18日

8 用例模型 用例（功能）模型往往是从用户需求的角度来描述系统，指明系统应该“做什么”，直接反映用户对目标系统的需求，描述数据在系统中的变换过程及系统的功能。 在 UML 中，把用用例图建立起来的系统模型也称为用例模型。建立用例模型有助于软件开发人员更深入地理解问题域，改进和完善自己的分析和设计过程。 通常，用例模型由一组用例图和数据流图组成，数据流图主要起辅助作用。 UML 中的用例图是进行需求分析和建立功能模型的强有力工具。用例模型的建立是系统开发者和用户反复讨论的结果，描述了开发者和用户对需求规格所达成的共识。 2017年3月18日

9 10.1.2 对象模型 面向对象方法强调围绕对象而不是围绕功能来构造系统。
对象模型 面向对象方法强调围绕对象而不是围绕功能来构造系统。 对象模型是面向对象方法最基础、最核心，也是最重要的模型。该模型主要关心系统中对象的结构、属性与操作，以及对象与对象之间关系的映射，是对模拟客观世界的对象及对象彼此间的关系静态结构的描述，为建立动态模型和用例（功能）模型提供了实质性的框架。 对象模型通过对象、类的属性、操作及其相互联系的描述，给出系统静态结构的刻画，在UML 中常用类图和对象图来描述。 2017年3月18日

10 10.1.3 动态模型 动态模型可以借助于交互（顺序图或通信图）或状态机（状态图或活动图）进行建模。
动态模型 动态模型可以借助于交互（顺序图或通信图）或状态机（状态图或活动图）进行建模。 交互主要用于对共同工作的群体对象的行为建模，而状态机则是对单个对象的行为建模。 动态模型可以先从简单的顺序图或通信图的建模开始，这将有助于找出系统中更重要的用例，用以对用例模型进行补充和扩展。 动态模型表示瞬时的、行为化的、系统的“控制”性质，定义对象模型中对象的合法变化序列，描述系统中不同对象类之间的交互。 当问题系统涉及交互作用和时序，如用户界面交互和过程控制时，动态模型是重点。 2017年3月18日

11 物理（实现）模型 物理实现模型关注的是系统实现过程的建模，常常用构件图和部署图表示静态的物理实现模型，用交互图和状态机描述动态实现模型。 物理实现模型从实现子系统和实现元素（即构件）的角度来表现系统实现的物理组成。 实现模型与设计模型的映射既可以非常紧密也可以非常松散，但最好是保持一对一的映射关系（即一个设计包对应一个设计子系统，这样可以保证从设计到源代码的可追溯性更容易些）。 构件和节点分别是物理实现模型中构件图和部署图的基本组成部件，可以通过组织类的方式来组织构件，用包将构件分组，也可以通过描述构件之间的依赖、泛化、关联和实现关系来组织构件。 2017年3月18日

12 种模型之间的关系 4 种模型，分别从4 个不同侧面描述所要开发的系统，这4 种模型相互补充、相互配合，使人们对系统的认识更加全面。 对象模型是必须建立的，是核心模型之一，为其他3 种模型奠定了基础； 用例（功能）模型指明系统应该“做什么”，一般选择用例图或数据流图来描述，用例模型从用户的角度描述系统功能，是整个后续工作的基础，也是测试与验收的依据； 动态模型明确规定什么时候（即在何种状态下接受什么事件的触发）做什么事情，当问题涉及交互作用和时序（如用户交互和过程控制）时，动态模型尤为重要； 物理实现模型通过构件图和部署图描述系统实现和分析设计中的对应关系； 2017年3月18日

13 10.1.5 4 种模型之间的关系 下面扼要地叙述这4 种模型之间的关系： （1）针对每个类建立的动态模型，描述类实例的生存周期或运行周期。
种模型之间的关系 下面扼要地叙述这4 种模型之间的关系： （1）针对每个类建立的动态模型，描述类实例的生存周期或运行周期。 （2）状态转换驱使行为发生，这些行为在数据流图中被映射成处理，在用例图中被映射成用例，它们同时与类图中的服务相对应。 （3）用例（功能）模型中的用例（或处理）对应于对象模型中的类所提供的服务。 （4）数据流图中的数据存储及数据的源点/终点通常是对象模型中的对象。 （5）数据流图中的数据流往往是对象模型中对象的属性值，也可能是整个对象。 （6）用例图中的参与者可能是对象模型中的对象。 （7）用例（功能）模型中的用例（或处理）可能产生动态模型中的事件。 （8）对象模型描述数据流图中的数据流、数据存储及数据源点/终点的结构 （9）物理实现模型中的构件通常对应对象模型中的类。 2017年3月18日

14 10.2 建立用例模型 10.2.1 需求分析与用例建模 10.2.2 确定系统范围和系统边界 10.2.3 确定参与者
10.2 建立用例模型 用例是从用户的角度出发来描述系统的功能，用例图用于展示系统将提供什么样的功能，以及用户将如何与系统交互来使用这些功能。 需求分析与用例建模 确定系统范围和系统边界 确定参与者 确定用例 确定用例之间的关系 2017年3月18日

15 需求分析与用例建模 建立用例模型的目的是提取和分析足够的需求信息，该模型应该表达用户需要什么，而不涉及系统将如何构造和实现的细节。 用例模型由若干个用例图组成，主要用于需求分析阶段。 建立用例模型的过程就是对系统进行功能需求分析的过程。建立用例模型的过程包括确定系统范围和边界、确定参与者、确定用例、确定用例之间的关系等几个步骤。 2017年3月18日

16 10.2.2 确定系统范围和系统边界 系统边界可以帮助分析人员清晰地划分要建模的子系统，同时系统边界也为软件系统建立了范围。
确定系统范围和系统边界 系统边界可以帮助分析人员清晰地划分要建模的子系统，同时系统边界也为软件系统建立了范围。 项目范围通常包括系统功能、资源和可用时间等方面的约束。 要确定项目范围，必须完成以下几件事情：确认系统需求；设定需求的优先级别以确定后续迭代的顺序；估计实现需求所要求的工作量；分析实现系统每项需求的影响。另外，在创建项目范围时，需要估计项目中实现每个新增需求的影响。 在 UML 表示法中，系统是由一条边界包围起来的未知空间，系统只通过边界上的有限个接口与外部交互。 系统边界是一个系统所包含的所有系统成分与系统以外各事物的分界线，通常用矩形框表示，但边界不是用例图的必要成分 2017年3月18日

17 确定参与者 参与者（Actor，也叫做活动者）是具有行为能力的事物；可以是一个人（由所扮演的角色来识别）、计算机系统或硬件设备，它们位于系统边界之外，通过和系统进行有意义的交互来实现它们的目标。 参与者可以发出请求，要求系统提供服务，系统以某种方式进行响应，或者把响应的结果给其他的参与者； 系统也可以向参与者发出请求，参与者对此做出响应。 按照在系统中的作用，可以将参与者分为主要参与者、次要参与者和后台参与者。 2017年3月18日

18 确定参与者 主要参与者指的是在使用系统服务的过程中满足自己目标的那些参与者，如使用在线考试系统的任课教师和学生。识别出这类参与者，可以帮助找到用户目标，从而确定系统的功能需求。一般将主要参与者画在用例图中系统边界的左边。 次要参与者指的是为系统提供服务的那些参与者，如一个对信用卡支付进行授权的外部系统。识别出这类参与者，可以帮助确定外部接口和协议。 后台参与者指的是对用例的行为感兴趣的那些参与者，如政府的税务机关。识别出这类参与者，可以保证找到所有方面的兴趣并让用例满足它。一般将次要参与者和后台参与者画在用例图中系统边界的右边。 2017年3月18日

19 确定参与者 识别参与者的任务就是找到参与者并明确其在系统中要实现的目标。 通常通过回答以下问题找到参与者。 （1）谁使用系统的主要功能？ （2）谁需要系统的支持以完成其日常工作任务？ （3）谁负责维护、管理并保证系统的正常运行？ （4）系统需要和哪些外部系统交互？ （5）系统需要处理哪些设备？ （6）对系统产生的结果感兴趣的人或事物是哪些？ 2017年3月18日

20 确定参与者 也可以通过回答以下问题识别参与者的目标。 （1）某个参与者要求系统为其提供什么功能？该参与者需要做哪些工作（可能有些工作需要系统帮助完成）？ （2）参与者需要阅读、创建、销毁、更新或存储系统中的某些（类）信息吗？ （3）系统中的事件一定要告知参与者吗？参与者需要告诉系统一些什么吗？那些系统内部的事件从功能的角度代表什么？ （4）由于系统新功能的识别（如那些典型的还没有实现自动化的人工系统），参与者的日常工作被简化或效率提高了吗？若是，则该用例对于该参与者有意义、值得实现。 2017年3月18日

21 确定参与者 因为参与者是一个类，所以在参与者之间可以引入类之间的继承关系，通过定义某个抽象参与者来简化参与者的定义。如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另一个参与者中，这组参与者再从中继承，这种关系称为参与者之间的继承关系。 2017年3月18日

22 确定用例 一个用例（Use Case）描述系统的一项功能，功能被描述为一组动作序列（场景）的集合。每一个动作序列表示参与者与系统的一次交互，将为参与者产生一个可观察的结果值。每一个用例使用动词短语定义，该短语描述了系统必须完成的目标。 2017年3月18日

23 确定用例 对用例定义的理解包括以下几个方面。 （1）一个用例描述系统的一项功能，是参与者使用系统来达成目标时一组相关的成功场景（Scenario）和失败场景的集合。 （2）用例通常是由某个参与者来驱动执行，只有当外部的参与者与系统交互时，该功能才会发生作用。 （3）用例中，只描述参与者可以看到的系统行为特征。 （4）用例描述的是一个参与者所使用的一项系统级功能，该项功能应该相对完整。 （5）可观察的结果值是指系统对参与者的动作要做出响应，在经过若干次交互之后，系统把最终有意义的结果值反馈给参与者。 2017年3月18日

24 10.2.4 确定用例 用例的确定可以从参与者角度出发，识别每类参与者在系统中要实现的目标，从中抽取用例。 用例可以分为3种不同的级别：
确定用例 用例的确定可以从参与者角度出发，识别每类参与者在系统中要实现的目标，从中抽取用例。 用例可以分为3种不同的级别： 企业级别的目标，如盈利、扩大目标市场等； 用户级别的目标，如取款、在线考试等； 子功能级别的目标，如验证用户身份、记录系统日志等。 识别用例重点要识别的是用户级别用例。 2017年3月18日

25 确定用例 用例描述的目标是将用例的功能和应用场景描述清楚，包括：用例在何时开始，何时结束；参与者何时与系统交互；交互什么内容；所有可能的交互场景等。 对用例的描述，可以用自然语言，也可以采用用户自定义的语言。为了更清楚地说明问题，也可以采用面向对象的类图、顺序图、状态图或活动图来做进一步的描述。用例描述模板参见表10.1。 2017年3月18日

26 确定用例 2017年3月18日

27 确定用例之间的关系 用例之间主要有两大类关系，即包含和扩展，可以细分为4种关系：包含、使用、扩展和泛化关系，它们的共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通过不同的方法来重用这个公共的用例，以减少模型维护的工作量。 2017年3月18日

28 确定用例之间的关系 1．包含关系 包含关系可以把几个用例的公共步骤分离出来，成为一个单独的被包含用例，以便多个用例复用。用例A在其内部说明的某一位置上显式地使用用例B行为的结果，称为用例A包含用例B。注意用例包含关系中要避免用例中相同功能的重复描述，避免过长的用例。用例图参见图10.1。 2017年3月18日

29 确定用例之间的关系 2．扩展关系 扩展关系可以在不能改变已有用例（也称为基用例）的情况下，在已有用例的扩展点上扩展用例的功能，扩展用例中必须包含触发和扩展点说明。扩展用例用于为已有用例添加新的行为，根据已有用例的扩展点当前状态判断是否执行自己，扩展用例对基用例不可见。例如，图书管理系统中，管理员在接收还书操作时要判断是否涉及罚款事件，罚款和还书行为相对独立，而且给还书操作添加了新行为。扩展用例的图示如图10.2所示。 2017年3月18日

30 确定用例之间的关系 2017年3月18日

31 确定用例之间的关系 3．泛化关系 泛化关系和类中的泛化概念是一样的，子用例继承父用 例的行为和含义，还可以增加或覆盖父用例的行为；子用例 可以出现在任何父用例出现的位置（父和子均有具体的实 例），也可以重载它。用例之间的泛化关系示意图参见图10.3。 2017年3月18日

32 确定用例之间的关系 通过包含、扩展和泛化关系描述的棋牌馆管理系统分析示例参见图10.4。 2017年3月18日

33 确定用例之间的关系 4．使用关系 使用关系非常像一个函数调用，以这种方式被使用的用例称为抽象用例，因为它不能单独存在而必须被其他用例使用。用例之间的使用关系示意图参见图10.5。 2017年3月18日

34 10.3 建立对象模型 10.3.1 确定类和对象 10.3.2 确定关联 10.3.3 确定属性 10.3.4 建立对象类图
10.3 建立对象模型 确定类和对象 确定关联 确定属性 建立对象类图 划分主题 优化对象模型 2017年3月18日

35 确定类和对象 面向对象分析的第一个层次主要是识别类和对象，类和对象是对与应用有关的概念的抽象。实际操作中，分析员需要首先找出候选的类和对象，包括：可感知的物理实体，如汽车等；人或组织的角色，如学生等；应该记忆的事件，如球赛等；两个或多个事件的相互作用，通常具有交易或接触性质，如教学等；需要说明的概念，如法律等。除此之外，更简单直接的一种非正式分析方法是将需求描述中的名词作为类和对象的候选者，然后进行筛选，去掉不正确或无关的类和对象。最后通过区分实体类、边界类和控制类来检查对象模型的完整性。 2017年3月18日

36 确定类和对象 筛选过程主要依据下列标准来删除不正确或不必要的类和对象： ① 冗余：如果两个类表达同样的信息，则应合并这两个类或对象的说明； ② 无关：系统只需要包含与本系统密切相关的类或对象； ③ 笼统：需求分析中除了明确的名词之外，还包含一些笼统、泛指的名词，分析系统需求，确定有更明确描述的前提下，应该把笼统的名词类或对象去掉； ④ 属性：如果分析过程中，某个类只有一个属性，可以考虑将它作为另一个类的属性； ⑤ 操作：需求陈述中如果使用一些既可做动词也可做名词的词汇，应该根据本系统的要求，正确决定把它们作为类还是类中的操作； ⑥ 实现：分析阶段不应过早考虑系统的实现问题，所以应该去掉只和实现有关的候选类和对象。 2017年3月18日

37 确定类和对象 在对象建模时，一般地首先从问题域的实体类入手分析，如果能够在分析过程中同时考虑类和对象的不同类型，一方面有助于深刻理解系统，另一方面可以检查对象模型完整性。 实体类表示系统将跟踪的持久信息；边界类表示参与者与系统之间的交互，边界对象收集来自参与者的信息，并转换为可用于实体类和控制类的对象的表示形式，边界类对象只对用户界面进行粗略的建模，不涉及如菜单项、滚动条等细节；控制类对象负责用例的实现，协调实体类和边界类对象，控制类对象在现实世界中没有具体的对应物，它通常从边界类对象处收集信息，然后把这些信息分配给实体类对象。 2017年3月18日

38 确定类和对象 但边界类和实体类之间并不是必须有控制类，只有当用例的事件流比较复杂并具有可以独立于系统的接口（边界类）或存储信息（实体类）的动态行为时，才有系统控制类。如事务管理器、资源协调器和错误处理器等都可以作为控制类。分析过程中，实体类、边界类和控制类分别用UML的不同的图形标记，参见图10.7。 2017年3月18日

39 确定关联 在确定了类和对象之后，需要确定类和对象之间的关系。关联是指两个或多个对象之间的相互依赖、相互作用关系的统称。分析、确定对象类之间的关联关系，能促使分析员考虑问题域的边缘情况，有助于发现那些尚未被发现的类和对象。大多数关联可以通过直接提取需求陈述中的动词或动词词组得到，同时还需要进一步分析需求分析中隐含的关联。另外，通过与用户及领域专家的交流，还可能补充一些潜在的关联。 2017年3月18日

40 确定关联 标识关联的启发式规则有： ① 从需求描述中查找动词或动词短语，识别动作的主体和客体，从角色寻找关联； ② 准确地命名关联和角色； ③ 尽量使用常用的修饰词标识名字空间和关键属性； ④ 应删除派生关联，即可由其他关联导出的关联； ⑤ 在一组关联被确定下来之前，先不必考虑实例之间的多重性； ⑥ 为适用于不同的关联，必要时要分解以前确定的类； ⑦ 分析过程中，及时补上遗漏的关联。 2017年3月18日

41 确定关联 类模型的结构及由类和子类构成的类层次，表示问题域中的复杂关系，是客观世界实体间关系的抽象。从结构角度分析，类及对象间的关系可概括为归纳关系和组合关系。其中归纳关系（一般-特殊结构、分类结构）是针对事物类之间的组织关系；组合关系（整体-部分结构、组装结构）是表示事物的整体与部分之间的组合关系。 如果再细化的话，类和对象之间的关联关系可以分为继承、实现、依赖、关联、聚集和组合关系，但在分析、确定关联的过程中，早期不必花过多精力去区分这几种关系，事实上，聚集和组合都是关联的一种特例，这些关联关系的细化可以留待设计过程中再行细化。 2017年3月18日

42 确定属性 属性是对前面已识别的类和对象做进一步的说明，借助于属性能够对类和对象的结构有更深入、更具体的认识。需求陈述中，属性通常用名词词组表示。对于需求陈述中没有显式说明的内容，需要借助于领域知识和常识找到相应属性。属性的确定既与问题域有关，也与目标系统的任务有关。类的属性所描述的是状态信息，每个实例（对象）的属性值表达了该实例（对象）的状态值。 标识属性的方法和策略：只考虑与具体应用直接相关的属性，不考虑那些超出所要解决的问题范围的属性；先找出最重要的属性，再逐渐把其余属性增添进去；分析阶段不考虑纯粹用于实现的属性。 2017年3月18日

43 10.3.3 确定属性 属性的标识也有一些启发式规则，如： 每个对象至少需包含一个编号属性，如_id； 系统的所有存储数据必须定义为属性；
确定属性 属性的标识也有一些启发式规则，如： 每个对象至少需包含一个编号属性，如_id； 系统的所有存储数据必须定义为属性； 导出属性应该略去； 描述对象的外部不可见状态的分析属性应该从分析模型中删掉； 最后考虑取值范围、极限值、缺省值、建立和存取权限、精确度、是否会受到其他属性值影响等。 2017年3月18日

44 建立对象类图 在软件开发的不同阶段都会用到类图，但这些类图表示了不同层次的抽象。在分析阶段，类图主要研究领域概念；在设计阶段，类图主要描述类与类之间的接口关系；在实现阶段，类图描述软件系统中类的实现，因此，在不同阶段类图有不同的层次。概念层的类图描述应用领域的概念，与现实世界及所研究的问题相关；说明层的类图描述软件的接口部分，在概念层类描述的基础上增加了和接口有关的描述属性；实现层的类图揭示软件的实现部分，此时的类才是严格意义上的类，包含了类图所有的内容。3个不同层次的类图描述参见图10.8。 2017年3月18日

45 建立对象类图 2017年3月18日

46 建立对象类图 建立类图的原则如下。 ① 简化的原则。在项目点初始阶段不要使用所有完备的符号，主要能够有效表达语义就可以。 ② 分层理解的原则。根据项目开发的不同阶段，使用不同层次的类图进行表达，便于理解，不要一开始就陷入实现的细节中去。 ③ 关注关键点的原则。不要试图为每个事物都画完善的模型，应该把精力放在关键点上。 2017年3月18日

47 建立对象类图 类图建模，就是要表达类与类之间的关系，以便于人们理解系统的静态逻辑，通常需要对两个方面建模：对简单协作建模和对数据库模式建模。对象图是表示在某一时刻一组对象及它们之间的关系的图形表示。对象图由结点和它们之间的连线组成，这里的结点可以是对象或类。对象图是类图的实例化，其表示方法也和类图相似。参见图10.9，其中对象名常用“对象名：类名”来表示。任何一个类都可以实例化为很多对象，每个对象具有不同的属性值和相同的操作，因此对象图只包含两部分：对象名和特定的属性值。对象图显示对象集及其相互关系，代表系统某个时刻的状态。通过分析和设计阶段创建的对象图，可以捕获交互点静态部分，详细描述瞬态图，还可以捕获类的实例和连接 2017年3月18日

48 划分主题 在开发大型、复杂的系统时，为了降低复杂程度，人们习惯于把系统再进一步划分成几个不同的主题，也就是在概念上把系统包含的内容分解成若干个范畴。主题是按照问题领域来确定的，不同主题内的对象类之间的相互依赖和交互应尽可能少。 在开发很小的系统时，可能根本无需引入主题层；对于含有较多对象的系统，则往往先识别出类与对象和关联，然后划分主题，并用它作为指导开发者和用户观察整个模型的一种机制；对于规模极大的系统，则首先由高级分析员粗略地识别对象和关联，然后初步划分主题，经进一步分析，对系统结构有更深入的了解后，再进一步修改和精炼主题。在UML中，主题可以通过包图来表现。 2017年3月18日

49 优化对象模型 事实上，通过前述步骤建立的对象模型很难一次就得到满意的结果。好在面向对象的分析方法支持迭代和反复过程，在建模的任何一个环节，如果发现有分析遗漏或出错，都可以返回到对应点进行修改和完善，经过多次反复修改，才能逐步完善，从而得到正确的对象模型。 另外，在优化过程中，通常还可以包含对前述工作的逐步优化，如删除冗余的类，根据需要合并或分解的类，补充部分关联关系，对类结构层次进行优化（如识别继承关系）等。 2017年3月18日

50 10.4 建立动态行为模型 10.4.1 建立顺序图 10.4.2 建立通信图 10.4.3 建立状态图 10.4.4 建立活动图
10.4 建立动态行为模型 本章第一节已经简单介绍了动态模型的概念，在开发交互式系统时，动态模型起着重要的作用。 交互图和状态机都用于系统的动态方面建模。其中交互图包括顺序图和通信图（UML1.0中为协作图）。状态机包括活动图和状态图，本节从这4种图形的角度介绍系统动态行为模型的建立方法。 建立顺序图 建立通信图 建立状态图 建立活动图 2017年3月18日

51 建立顺序图 顺序图表示类（对象）按时间顺序的消息交换过程，体现出系统用例的行为。顺序图是用来显示参与者如何采用若干顺序步骤与系统对象交互的模型。在交互期间，参与者会向系统发送事件，系统通过响应这些事件来满足参与者的目标。在顺序图中，所有的系统都被当作黑盒子看待，顺序图的重点是参与者发起的跨越系统边界的事件。系统行为描述系统做什么，而不解释系统怎么做。系统顺序图是对系统行为所做的描述的一部分。 2017年3月18日

52 建立顺序图 每个用例需要一张或多张顺序图来描述其行为。每张顺序图显示用例的一个特定的行为序列。需要注意的是，不要一次性创建所有用例所有场景的系统顺序图，应该只为当前迭代所选择的场景创建系统顺序图。 顺序图有两个主要的标记符：活动对象和这些活动对象之间的通信消息。活动对象可以是任何在系统中扮演角色的对象，不管是对象实例还是参与者。活动对象之间发送的消息是顺序图的关键。消息说明了对象之间的控制流，对象是如何交互的，以及什么条件会改变控制流。 2017年3月18日

53 建立顺序图 对象拖出的长虚线称为生命线。生命线说明按照时间顺序对象所发生的事件。消息用从活动对象生命线到接收对象生命线的箭头表示，箭头上面标记要发送的消息。 对于Compile Application用例，可以创建一个成功编译工作流的顺序图，参见图10.10。这个顺序图中有4个活动对象：Developer、Compiler、Linker和FileSystem。Developer是系统的参与者。Compiler是Developer交互的应用程序。Linker是一个用来链接对象文件的独立进程。FileSystem是系统层功能的包装器，用来执行文件的输入和输出例程。 2017年3月18日

54 建立顺序图 Compile Application用例的顺序图 操作： ①Developer请求Compiler执行 编译； ②Compiler请求FileSystem加载 文件； ③Compiler通知自己执行编译； ④Compiler请求FileSystem保存 对象代码； ⑤Compiler请求Linker链接对象代码； ⑥Linker请求FileSystem加载对象代码； ⑦Liker通知自己执行链接； ⑧Linker请求FileSystem保存编译的结果。 2017年3月18日

55 建立通信图 与顺序图类似，通信图也是描述类（对象）之间的关联及其彼此之间的消息通信，但顺序图强调交互的时间次序，而通信图强调交互的空间结构，这两者在语义上是等价的，二者可以相互转换，而不会丢失信息。在支持UML的建模工具如Rational Rose或StarUML中，一般地主要做出其中一种图，另一种图可以通过工具转换得到，详细操作参见相关书籍。 要使由类构成的系统具有指定功能，这些类的实例（对象）需要彼此通信和交互。通信图主要关心对象之间的交互。 2017年3月18日

56 建立通信图 通信图的构成主要包括对象、链接和消息3部分。除了对象之外，在通信图中还可以使用对象角色和类角色代替对象；链接用来在通信图中关联对象，链接的目的是让消息在不同系统对象之间传递，链接以连接两个对象的单一线条表示；消息是通信图中对象与对象之间通信的方式，消息又可以分为简单消息、异步消息、同步消息和反身消息，分别参见图10.11～图10.14。另外，图10.15通过同一个用例的顺序图和通信图示例给出两者之间的对比。 2017年3月18日

57 建立通信图 2017年3月18日

58 建立状态图 状态是对对象属性值的一种抽象，各对象之间相互触发（即作用）就形成了一系列的状态变化。一个触发行为称作一个事件。一个事件分开两个状态，一个状态隔开两个事件。事件表示时刻，状态代表时间间隔。状态图通过建立类对象的生存周期模型来描述对象的状态、触发状态转换的事件及对象随时间变化的动态行为（对事件的响应）。每个类的动态行为用一张状态图来描绘，各个类的状态图通过共享事件合并起来，从而构成系统的动态模型。 2017年3月18日

59 建立状态图 1．状态机及状态图的定义 状态机包含了一个类的对象在其生命期间所有状态的序列及对象对接受到的事件所产生的反应，利用状态机可以精确地描述对象的行为。状态机的组成包括状态、转换、事件、活动、动作。状态机可以通过状态图或活动图来描述。 状态图由表示状态的结点和表示状态之间转换的带箭头的直线组成，表现从一个状态到另一个状态的控制流，是展示状态与状态转换的图。状态图的组成包括状态、转换、初始状态、终结状态、判定。 2017年3月18日

60 建立状态图 在UML的表示中，状态由一个带圆角的矩形表示，状态图标可以分为3部分：名称、内部转换和嵌套状态。转换用带箭头的直线表示，一端连接源状态即转出的状态，箭头一端连接目标状态即转入的状态；转换可以标注与此转换相关的选项，如事件、动作和监护条件。初始状态代表状态图的起始位置，只能作为转换的源，而不能作为转换的目标，初始状态在一个状态图中只允许有一个，它用一个实心的圆表示。终止状态是模型元素的最后状态，是一个状态图的终止点，终止状态只能作为转换的目标，而不能作为转换的源。一个状态图中可以有多个终止状态，用一个套有一个实心圆的空心圆表示终止状态。状态图中的判定用空心小菱形表示，工作流在判定处按监护条件的取值而发生分支，根据监护条件的真假可以触发不同的分支转换。因为监护条件为布尔表达式，所以通常条件下的判定只有一个入转换和两个出转换。状态图示例参见图10.16。 2017年3月18日

61 建立状态图 2017年3月18日

62 建立状态图 2．状态 状态图中的状态一般是给定类对象中的一组属性值，这组属性值是对象所有属性的子集。在对系统建模时，可以只关心那些明显影响对象行为的属性及由它们表达的对象状态，而不用理睬那些与对象行为无关的状态。状态可以分为简单状态（指不包含其他状态的状态，没有子结构，但可以具有内部转换、入口动作和出口动作等）和复合状态（包含一些嵌套的子状态的状态）。每个状态的组成包括状态名、活动、入口动作和出口动作。入口动作和出口动作表示进入或退出这个状态所要执行的动作，入口动作用“entry/要执行的动作”表达，而出口动作用“exit/要执行的动作”表达。 2017年3月18日

63 建立状态图 3．事件 事件表示在某一特定的时间或空间出现的能够引发状态改变的一种运动变化。事件是一个激励的出现，它定义一个触发子以触发对象改变其状态，任何影响对象的事物都可以是事件。事件种类包括以下几种。 入口事件：表示一个入口的动作序列，在进入状态时执行。入口事件的动作是原子的，并且先于人和内部活动或转换。 出口事件：表示一个出口的动作序列，在退出状态时执行。出口事件也是原子的，它跟在所有的内部活动之后，但是先于所有的出口转换。 动作事件：也称为“do事件”，表示对一个嵌套状态机的调用。与动作事件相关的活动必定引用嵌套状态机，而非引用包含它的对象的操作。 2017年3月18日

64 建立状态图 信号事件：信号是指从一个对象到另一个对象的明确的单向信息流动，信号事件指发送或接收信号的事件，发送者和接收者可以是同一个对象。 调用事件：至少涉及两个以上的对象，指一个对象对调用的接收。调用事件既可以为同步调用，也可以为异步调用。 修改事件：依靠特定属性值的布尔表达式所表示的条件的满足来触发状态的转换，修改事件表示一种具有时间持续性的，并且可能是涉及全局的计算过程。 时间事件：代表时间的流逝，指在绝对时间上或在某个时间间隔内发生的事情所引起的事件。 延迟事件：指在本状态不处理，要推迟到另外一个状态才处理的事件。 2017年3月18日

65 建立状态图 4．转换 转换表示当一个特定事件发生或者某些条件得到满足时，一个源状态下的对象在完成一定的动作后将发生状态转变。UML中转换用带箭头的直线表示，一端连接源状态即转出的状态，箭头一端连接另一个称之为目标状态的状态。转换进入的状态为活动状态，转换离开的状态变为非活动状态。转换的组成包括源状态、目标状态、触发事件、监护条件、动作。转换可以标注与此转换相关的选项，如事件、动作和监护条件。 2017年3月18日

66 建立状态图 转换种类包括以下几种。 外部转换：外部转换是一种改变对象状态的转换，是最常见的一种转换。外部转换用从源状态到目标状态的箭头表示。 内部转换：内部转换有一个源状态但是没有目标状态，它转换后的状态仍旧是它本身。内部转换的激发规则和改变状态的外部转换的激发规则相同。内部转换用于对不改变状态的插入动作建立模型。 内部转换和自转换（完成转换）不同。自转换是离开本状态后重新进入该状态，它会激发状态的入口动作和出口动作的执行。内部转换自始至终都不离开本状态，所以没有出口或入口事件，也就不执行入口和出口动作。 2017年3月18日

67 建立状态图 完成转换：完成转换又称为自转换。完成转换是因为没有标明触发器事件的转换是由状态中的活动的完成引起的，是自然而然完成的转换。完成转换也可以带一个监护条件，这个监护条件在状态中的活动完成时被赋值，而非活动完成后被赋值。 复合转换：复合转换由简单转换组成，这些简单转换通过分支判定、分叉或接合组合在一起。除了双分支判定，还有多条件的分支判定。多条件的分支判定又分为链式的和非链式的分支，分别参见图10.17和图10.18。 2017年3月18日

68 建立状态图 2017年3月18日

69 建立状态图 5．触发事件 触发也称为迁移，是指从一个状态到另一个状态的瞬时变化。触发事件是能够引起状态转换的事件，触发事件可以是信号、调用、时间段等。触发的源和目标通常是不同的状态，但也可能会相同。 6．监护条件 监护条件也称为警戒条件，是触发转换必须满足的条件，它是一个布尔表达式。监护条件只能在触发事件发生时被赋值一次，如果在转换发生后监护条件才由假变为真，那么转换也不会被触发。从一个状态引出的多个转换可以有同样的触发器事件，但是每个转换必须具有不同的监护条件。注意，监护条件与变化事件不同——监护条件只会触发一次，而变化事件实际上是要连续检查的。 7．动作 动作是一组可执行语句或者计算处理过程。动作可以包括发送消息给另一个对象、操作调用、设置返回值、创建和销毁对象等。动作是原子的，不可中断的，动作或动作序列的执行不会被同时发生的其他动作影响或终止。整个系统可以在同一时间执行多个动作。 2017年3月18日

70 建立状态图 8．状态图的建模步骤 ① 找出适合用模型描述其行为的类。不需要给所有的类都创建状态图，只有具有重要动态行为的类才需要。 ② 确定对象可能存在的状态。 ③ 确定引起状态转换的事件。 ④ 确定转换进行时对象执行的相应动作。 ⑤ 对建模的结果进行相应的精化和细化。 2017年3月18日

71 建立状态图 9．建立状态图 在开发交互式系统时，动态模型中的状态图起着重要作用。建立状态图的步骤如下。 ① 编写典型交互行为脚本，必须保证脚本中不遗漏常见的交互行为。 ② 从脚本中提取出事物，确定触发每个事件的动作对象及接受事件的目标对象。 ③ 排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘出来。 ④ 比较各个对象的状态图，检查它们之间的一致性，确保事件之间的匹配。 2017年3月18日

72 建立活动图 活动是某件事情正在进行的状态，既可以是现实生活中正在进行的某一项工作（写文章、维修机器等），也可以是软件系统中正在运行的某个类对象的一个操作。活动具体表现为由一系列动作组成的执行过程。将各种活动及不同活动之间的转换用图形进行表示，就构成了活动图，活动图的作用是对系统的行为建模。 2017年3月18日

73 建立活动图 1、活动图与流程图 传统的流程图的各种成分在活动图中都有，活动图在本质上是一种流程图，同时活动图借鉴了工作流建模、Petri网等领域的相关概念，其表达能力比流程图更强，应用范围也更宽。 但活动图与流程图是有区别的，不能将两个概念混淆： 首先，流程图着重描述处理过程，它的主要控制结构是顺序、选择和循环，各个处理过程之间有严格的顺序和时间关系，活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程； 其次，活动图能够表示并发活动的情形，而流程图不能； 最后，活动图是面向对象的，而流程图是面向过程的。 2017年3月18日

74 建立活动图 2．活动图与状态图 活动图与状态图都是状态机的表现形式，但是两者还是有本质区别：活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程；状态图着重描述从一个状态到另一个状态的流程，主要有外部事件的参与。 2017年3月18日

75 建立活动图 3．活动图的组成及 UML 图形表示 活动图的UML图形表示中，如果一个活动引发下一个活动，两个活动的图标之间用带箭头的直线连接。与状态图类似，活动图也有起点和终点，表示法和状态图相同。活动图中还包括分支与合并、分叉与汇合等模型元素。分支与合并的图标和状态图中判定的图标相同，而分叉与汇合则用一条加粗的线段表示。活动图的示例描述参见图10.19。 2017年3月18日

76 建立活动图 2017年3月18日

77 建立活动图 UML的活动图中包含的图形元素有动作状态、活动状态、动作流、分支与合并、分叉与汇合、分区和对象流等。 动作状态：指执行原子的、不可中断的动作并在此动作完成后通过完成转换转向另一个状态。在UML中，动作状态使用平滑的圆角矩形表示，动作状态所表示的动作写在圆角矩形内部。动作状态有如下特点。 （1）动作状态是原子的，它是构造活动图的最小单位，已经无法分解为更小的部分。 （2）动作状态是不可中断的，它一旦开始运行就不能中断，一直运行到结束。 （3）动作状态是瞬时的行为，它所占用的处理时间极短，有时甚至可以忽略。 （4）动作状态可以有入转换，入转换既可以是动作流，也可以是对象流。动作状态至少有一条出转换，这条转换以内部动作的完成为起点，与外部事件无关。 （5）动作状态和状态图中的状态不同，它不能有入口动作和出口动作，更不能有内部转移。 （6）在一张活动图中，动作状态允许多处出现。 2017年3月18日

78 建立活动图 活动状态：用于表达状态机中的非原子的运行。活动状态的表示图标和动作状态相同，都是平滑的圆角矩形，稍有不同的是活动状态可以在图标中给出入口动作和出口动作等信息。 活动状态的特点如下。 （1）活动状态可以分解成其他子活动或动作状态，由于它是一组不可中断的动作或操作的组合，所以可以被中断。 （2）活动状态的内部活动可以用另一个活动图来表示。 （3）和动作状态不同，活动状态可以有入口动作和出口动作，也可以有内部转移。 （4）动作状态是活动状态的一个特例，如果某个活动状态只包括一个动作，那么它就是一个动作状态。 2017年3月18日

79 建立活动图 动作流：所有动作状态之间的转换流称之为动作流。与状态图不同，活动图的转换一般都不需要特定事件的触发。一个动作状态执行完本状态需要完成的动作后，会自发转换到另外一个状态。一个活动图有很多动作或者活动状态，活动图通常开始于初始状态，然后自动转换到活动图的第一个动作状态，一旦该状态的动作完成后，控制就会不加延迟地转换到下一个动作状态或者活动状态。转换不断重复进行，直到碰到一个分支或者终止状态为止。 分支与合并：条件行为用分支和合并表达。动作流一般会自动进行控制转换，直到遇到分支。分支在软件系统流程中很常见，一般用于表示对象类所具有的条件行为。一个无条件的动作流可以在一个动作状态的动作完成后自动触发动作状态的转换，以激发下一个动作状态，有条件的动作流则需要根据条件，即一个布尔表达式的真假来判定动作的流向。活动图中的分支与合并示例参见图10.20。 2017年3月18日

80 建立活动图 2017年3月18日

81 建立活动图 分叉与汇合：对象在运行时可能会存在两个或者多个并发运行的控制流，为了对并发的控制流建模，在UML中引入了分叉与汇合的概念。分叉和汇合都使用加粗的水平线段表示。分叉用于将动作流分为两个或者多个并发运行的分支，而汇合则用于同步这些并发分支，以达到共同完成一项事务的目的。分叉可以用来描述并发线程，每个分叉可以有一个输入转换和两个或多个输出转换，每个转换都可以是独立的控制流。汇合代表两个或多个并发控制流同步发生，当所有的控制流都达到汇合点后，控制才能继续往下进行。每个汇合可以有两个或多个输入转换和一个输出转换。活动图中的分叉与汇合示例参见图10.21。 2017年3月18日

82 建立活动图 2017年3月18日

83 建立活动图 分区：分区（UML1.0中称为泳道）将活动图中的活动划分为若干组，并把每一组指定给负责这组活动的业务组织，即对象。分区标识负责活动的对象的范围，明确表示哪些活动是由哪些对象进行的。在包含分区的活动图中，每个活动只能明确地属于一个分区。在活动图中，分区可以用垂直或水平实线绘出（UML1.0中的泳道只能是垂直线），本例只给出垂直线标识的分区示例。垂直线分隔的区域就是分区，在分区上方可以给出分区的名字或对象（对象类）的名字，该对象（对象类）负责该分区内的全部活动。分区没有顺序，不同分区中的活动既可以顺序进行也可以并发进行。动作流和对象流允许穿越分隔线。活动图中分区示例参见图10.22。 2017年3月18日

84 建立活动图 2017年3月18日

85 建立活动图 对象流：对象流是动作状态或者活动状态与对象之间的依赖关系，表示动作使用对象或者动作对对象的影响。用活动图描述某个对象时，可以把涉及的对象放置在活动图中，并用一个依赖将其连接到进行创建、修改和撤销的动作状态或者活动状态上，对象的这种使用方法就构成了对象流。在活动图中，对象流用带有箭头的虚线表示。如果箭头从动作状态出发指向对象，则表示动作对对象施加了一定的影响。施加的影响包括创建、修改和撤销等。如果箭头从对象指向动作状态，则表示该动作使用对象流所指向的对象。活动图中对象流示例参见图10.23。 2017年3月18日

86 建立活动图 2017年3月18日

87 建立活动图 对象流中对象的特点： （1）一个对象可以由多个动作操纵； （2）一个动作输出的对象可以作为另一动作输入的对象； （3）在活动图中，同一个对象可以多次出现，它的每一次出现表明该对象正处于对象生存期的不同时间点。 4．活动的分解 一个活动可以分为若干个动作或子活动，这些动作和子活动本身又可以组成一个活动图。不含内嵌活动或动作的活动称之为简单活动；嵌套了若干活动或动作的活动称之为组合活动，组合活动有自己的名字和相应的子活动图。示例参见图10.24。 2017年3月18日

88 建立活动图 2017年3月18日

89 建立活动图 5．活动图建模技术 活动图建模步骤如下。 （1）识别要对工作流描述的类或对象。找出负责工作流实现的业务对象，这些对象可以是显示业务领域的实体，也可以是一种抽象的概念和事物。找出业务对象的目的是为每一个重要的业务对象建立分区。 （2）确定工作流初始状态和终止状态，明确工作流边界。 （3）对动作状态或活动状态建模。找出随时间发生的动作和活动，将它们表示为动作状态或活动状态。 （4）对动作流建模。对动作流建模时，可以首先处理顺序动作，接着处理分支与合并等条件行为，然后处理分叉与汇合等并发行为。 （5）对对象流建模。找出与工作流相关的重要对象，并将其连接到相应的动作状态和活动状态。 （6）对建立的模型进行精化和细化。 2017年3月18日

90 10.5 建立物理实现模型 构件图用来建模系统的各个构件及其关系，这些构件通过功能或者文件组织在一起。使用构件图可以帮助读者了解某个功能位于软件包的哪一位置，以及各个版本的软件各包含哪些功能等。部署图用来帮助读者了解软件中的各个构件驻留在什么硬件位置，以及这些硬件之间的交互关系。部署图用来展示运行时进行处理的结点和在结点上生存的制品的配置，实质上是针对系统结点的类图。 构件图和部署图统称为实现图，是对面向对象系统的物理方面建模的图。 建立构件图 建立部署图 2017年3月18日

91 建立构件图 建立构件图 1、构件 构件是一个相对独立的可装配的物理块，一般作为一个独立的文件存在。构件具有确定的接口，相互之间可以调用，构件之间存在依赖关系。构件定义了一个系统的功能，一个构件是一个或多个类的实现。 UML2.0将构件划分为部署构件、工作产品构件、执行构件。部署构件是运行系统需要配置的构件，如DLL、EXE、COM+、CORBA构件、EJB、动态Web页、数据库表等；工作产品构件如Java、C++等源代码文件、数据文件等，这些构件可以产生部署构件；执行构件指系统执行后得到的结果构件。 2017年3月18日

92 建立构件图 构件和类非常相似，两者都有名称；都可以实现一组接口；都可以参与依赖关系；都可以被嵌套；都可以有实例；都可以参与交互。但两者又有所不同：类是逻辑抽象，构件是物理抽象，即构件可以位于结点上；构件是对其他逻辑元素，如类、协作的物理实现，也就是说，构件是软件系统的一个物理单元；类可以有属性和操作，而构件通常只有操作，而且这些操作只能通过构件的接口才能使用。 在UML中，构件通过左部带有两个小矩形的大矩形来表示，如图10.25所示。 2017年3月18日

93 建立构件图 2．构件的接口 就像对类的访问只能通过类的公有操作进行一样，对构件定义的操作的访问也只能通过构件的接口进行。也就是说，一个构件可以访问另一个构件所提供的服务。这样，提供服务的构件呈现一个提供服务的接口，访问服务的构件使用所需的接口。 接口和构件之间的关系分为两种：实现关系和依赖关系，如图10.26所示。简略图中，接口和构件之间用实线连接表示实现关系；而接口和构件之间用虚线箭头连接则表示依赖关系，箭头从依赖的对象指向被依赖的对象。 2017年3月18日

94 建立构件图 2017年3月18日

95 建立构件图 3．对构件和构件关系建模的用途 ① 使客户能够看到最终系统的结构和功能。 ② 让开发者有一个工作目标。 ③ 让编写技术文档和帮助文件的技术人员能够理解所写的文档是哪方面内容。 ④ 利于复用。 4．构件图（Component Diagram） 构件图是描述构件及其相互关系的图，构件之间是依赖关系。通常，构件图包含3种元素：构件、接口和依赖关系。每个构件实现一些接口，并使用另一些接口。 2017年3月18日

96 建立构件图 （1）源代码文件建模（构件图） 有助于可视化源代码文件之间的编译依赖关系。 策略： ① 识别出感兴趣的相关源代码文件集合，把它们表示成《file》的构件； ② 对于较大的系统，利用包对源代码文件进行分组； ③ 如有必要，可以为构件添加相应的标记值，说明版本号、作者等信息； ④ 用依赖关系对这些文件之间的编译依赖关系建模。 图10.27所示的源代码文件建模的构件图中有signal.h 的两个版本，这个头文件被文件 interp.cpp和signal.cpp引用，interp.cpp依赖于irp.h。 2017年3月18日

97 建立构件图 2017年3月18日

98 建立构件图 （2）可执行文件和库建模 对构成系统的实现构件建模，如果系统由若干个可执行程序和相关对象库构成，最好文档化。图10.28所示的是可执行文件和构件库建模的示意图，图10.29所示的是一个C程序的组成构件图示例。 策略： ① 识别所要建模的构件集合，一般是一个结点上的部分或全部构件； ② 为构件选择合适的构造型； ③ 对每一个构件，考虑与相邻构件之间的关系，通常涉及接口； 2017年3月18日

99 建立构件图 2017年3月18日

100 建立构件图 （3）表、文件和文档建模 对系统中附属实现构件，如数据文件、帮助文档、脚本、日志文件等进行建模。图10.30所示是关于表、文件和文档建模的一个构件图示例。 策略： ① 识别出作为系统的物理实现部分的附属构件； ② 将这些事物建模为构件； ③ 对这些附属构件与其他可执行程序、库及接口之间的关系建模。 2017年3月18日

101 建立构件图 2017年3月18日

102 建立部署图 部署图（Deployment Diagram）也称配置图、实施图，用来描述系统中计算结点的拓扑结构和通信路径与结点上运行的软件构件等。部署图由结点和结点间的关联关系组成，描述运行软件的系统中硬件和软件的物理结构，一般一个系统仅有一个部署图。通常部署图由体系结构工程师、网络工程师或系统工程师来描述。 2017年3月18日

103 建立部署图 1．部署图的要素 （1）结点（Node） 结点表示独立计算资源的物理设备，通常拥有一些内存，并具有一定的处理能力，可以分为处理机（Processor）和设备（Device）两类。处理机是能够执行软件、具有计算能力的结点，包括主机、服务器、客户机等。设备是没有计算能力的结点，通常情况下都是通过其接口为外部提供某种服务，如打印机、传感器、终端等。在UML中，结点用一个立方体来表示。 2017年3月18日

104 建立部署图 结点和构件相比，两者都有名称和关系；都可以有实例；都可以被嵌套；都可以参与交互。但两者也有不同：构件是参与系统执行的事物，而结点是执行构件的事物；构件表示逻辑元素的物理包装，而结点表示构件的物理配置。 部署图可以将结点和构件结合起来，以建模处理资源和软件实现之间的关系。当构件驻留在某个结点时，可以将它建模在图上该结点的内部。为显示构件之间的逻辑通信，需要添加一条表示依赖关系的虚线箭头。 2017年3月18日

105 建立部署图 （2）连接 连接表示两个结点之间的物理连接关系，用直线表示，在连接上可以加多重性、角色、约束等。连接代表一种交流的机制，可以是物理媒介或软件协议。部署图可以显示结点及它们之间的必要连接，也可以显示这些连接的类型，还可以显示构件和构件之间的依赖关系，但是每个构件必须存在于某些结点上。 2017年3月18日

106 建立部署图 2．如何开发部署模型 部署模型通常与构件模型并行开发，为了开发部署模型，可以迭代使用以下步骤： （1）确定模型范围； （2）确定分布结构； （3）确定结点和它们的连接； （4）把构件分布到结点； （5）为不同构件之间的依赖建模。 2017年3月18日

107 建立部署图 【例10.1】 为家用计算机系统创建部署模型。 （1）确定模型范围：家用计算机。 （2）确定分布结构：以计算机为中心的网络。 （3）确定结点和它们的连接：结点包括计算机、调制解调器、ISP、显示器、打印机，它们分别以不同方式连接。 （4）把构件分布到结点。计算机中有软件构件：Windows、Office、IE。 （5）为不同构件之间的依赖建模。 按照上述步骤为家用计算机系统创建的部署模型参见图10.31。 2017年3月18日

108 建立部署图 2017年3月18日

109 建立部署图 【例10.2】 建模一个网上扫描系统的部署图。其详细的需求如下所述。 （1）扫描仪用来扫描产品信息。扫描仪通过内部的PCI总线连接到网卡。需要编写代码来控制扫描仪，代码驻留在扫描仪内部。 （2）扫描仪通过无线网卡与插入到Web服务器KONG的无线hub通信，服务器通过HTTP协议向客户PC提供Web页。 （3）Web服务器安装定制的Web服务器软件，通过专用数据访问构件与产品数据库交互。 （4）在客户的PC上将提供专用的浏览器软件，它运行产品查询插件，只与定制的Web服务器通信。 2017年3月18日

110 建立部署图 解决方案如下。 第一项任务是确定系统的结点，图10.32显示需求列表中提及的所有硬件。 第二项任务是为确定的结点添加通信关联，从需求列表中可以确定如下所示通信关联。 扫描仪通过内部的PCI总线连接到网卡；网卡通过无线电波与无线hub通信；无线hub通过USB连接到名为KONG的服务器实例；KONG Web服务器通过HTTP与客户构件通信。添加通信关联后的硬件结点图示参见图10.33。 接下来第三步需要确定构件和其他内容，如类和对象。 2017年3月18日

111 建立部署图 2017年3月18日

112 建立部署图 需求列表显示下列构件可以用于图中：控制扫描仪的代码（名为ScanEngine构件）；定制的Web服务器软件（名为WebSeverSoft构件）；专用的数据访问构件（名为DataAccess构件）；专用的浏览器软件（名为Browser构件）；产品查询插件（名为ProductLookupAddIn构件）。另外，前面还提到了产品数据库，但是它不必像前面的几个项目那样也建模为软件构件，要把产品数据库建模为一个类实例ProductDB。添加构件和其他内容后的结点图示参见图10.34。 2017年3月18日

113 建立部署图 2017年3月18日

114 建立部署图 实现部署图的最后一步是添加构件和对象之间的依赖关系。本题目具有下列依赖关系：WebServerSoft构件依赖于DataAccess构件；DataAccess构件依赖于ProductDB对象；专用浏览器软件只通过运行查询插件与定制的Web服务器交互，它提供依赖关系：Browser构件依赖于WebServerSoft构件；ProductLookupAddln构件依赖于Browser构件。 添加构件和对象之间的依赖关系后，最终完成的网上扫描系统的部署图参见图10.35。 2017年3月18日

115 建立部署图 2017年3月18日

116 建立部署图 3．几种部署图建模方法 （1）构件的分布建模 ① 将系统中每个有意义的构件部署到一个给定的结点上。 ② 如有必要，可以将同一个构件同时放在多个不同的结点上。 ③ 构件在结点上的部署，可以参考【例10.2】。 （2）嵌入式系统建模 ① 识别嵌入式系统中的设备和结点。 ② 使用构造型结点对处理器和设备建模。 ③ 在部署图中对处理器和设备间的关系进行建模。 ④ 必要时，可以把设备展开，用更详细的部署 图对它的结构进行建模。参考图10.36示例。 2017年3月18日

117 建立部署图 2017年3月18日

118 建立部署图 （3）客户机/服务器建模 ① 识别代表客户机和服务器的结点。 ② 标识出与系统行为有密切关系的设备。 ③ 利用构造型为处理器和设备提供可视化表示。 ④ 在部署图中为这些结点的拓扑结构建模。 参考图10.37示例。 2017年3月18日

119 建立部署图 2017年3月18日

120 10.6 面向对象软件开发过程的案例分析 10.6.1 系统需求 10.6.2 系统用例模型 10.6.3 系统对象模型
10.6 面向对象软件开发过程的案例分析 系统需求 系统用例模型 系统对象模型 系统动态行为模型 系统物理实现模型 2017年3月18日

121 10.6.1 系统需求 系统需求 给出一个汽车租赁系统实例用于分析。 分析问题领域
系统需求 系统需求 给出一个汽车租赁系统实例用于分析。 分析问题领域 分析问题领域是软件系统开发的一项基本工作，结果是对问题领域给出明确定义，明确目标所主要完成的工作。主要任务是对问题领域进行抽象，提出解决方案，进行需求分析，确定系统职责范围，功能需求，信能需求，应用环境及假设条件。 （1）定义活动者 根据系统的职责范围和需求确定活动者。 （2）Use Case图 每一张Use Case图都是一个活动者与系统在交互中执行的有关事务序列。

122 系统用例模型 汽车租赁系统 Customer的Use Case图 此系统 的三方面 需求

123 10.6.3 系统对象模型 汽车租赁系统软件的静态结构图 对系统 涉及到 的对象 和关系 进行 分类 对象划分为 不同的类。 每个类包含
系统对象模型 汽车租赁系统软件的静态结构图 对系统 涉及到 的对象 和关系 进行 分类 对象划分为 不同的类。 每个类包含 名字和属性

124 系统动态行为模型 顺序图提供了使用事件的详细视图，它是按时间顺序显示了相互作用，有助于文档化应用程序的逻辑，显示了参与的双方及它们之间传递的信息。 汽车租赁系统软件的顺序图

125 系统动态行为模型 通信图表是另一类型的交互图表，与顺序图表相似，它显示了使用事件中的一组对象如何与另一组通信，每个消息都被标上的序号以显示它发生的顺序。 汽车租赁系统软件的通信图

126 系统动态行为模型 一个对象的状态由某个时刻的属性决定。对象在外部刺激的影响下在不同的状态间装换。状态表映射这些状态及使对象处于特定状态的激发事件。 汽车租赁系统软件中Car的状态图

127 系统动态行为模型 活动图表显示了与发生的活动相对应的逻辑。活动图表与一个特定的类或使用事件相关，显示了执行特定操作涉及到的步骤。 汽车租赁活动的软件活动图

128 系统物理实现模型 构件图表显示了组成系统整个结构的不同的软件子系统，它构建在一个中心数据库上，因为库存水平是按小时发生变化的，所有部分就必须有精确到分钟的详细信息。 汽车租赁系统软件的构件图

129 本章小结 面向对象的分析就是抽取和整理用户需求，并建立问题领域精确模型的过程。分析工作主要包括3 项内容：理解、表达和验证。与传统的面向数据流的结构化方法以功能为导向的分析不同，面向对象的分析以对象类作为分析的基础，借助于面向对象方法进行需求分析，构建的是面向类的模型。一般地，可通过对象模型、用例（功能）模型、动态（行为）模型和物理实现模型来表达分析结果。本章最后通过一个简化的汽车租赁系统的分析过程给出面向对象分析的应用案例。 本章以面向对象的概念为基础，介绍了以这4 种模型为基础进行建模的基本方法和注意事项，为面向对象软件的分析过程提供指导。 2017年3月18日

130 思考和练习 10.1 面向对象建模主要建立哪几种模型？各自的特点是什么？ 10.2 什么是面向对象的分析？对象模型的层次是什么？ 10.3 用例建模包含哪几个步骤？ 10.4 对象模型包含哪些内容？对象建模的步骤是什么？ 10.5 动态模型主要是通过UML 的哪些图形来表示？这些UML 图形分别建模问题中的哪些方面？各有什么特点？ 10.6 物理实现模型包含UML 的哪些图形？每种图的特点是什么？ 10.7 什么叫构件，构件有哪几种类型，UML 中构件怎么表示？构件图的作用是什么？ 10.8 部署图的作用是什么？ 2017年3月18日

131 思考和练习（续） 10.9 阅读下面的部署图10.46，要求： ① 标识出通用结点； ② 标识出实例化的结点； ③ 标识出通信关联； ④ 标识出构件之间的关系。 2017年3月18日

132 2017年3月18日

133 课堂讨论 Q & A