软件工程概论1O-2-UML及面向对象的建模过程课件.ppt

1、第10章 面向对象的开发过程2/1102023-1-2610.2 UML及面向对象的建模过程及面向对象的建模过程n1 建模过程框架建模过程框架n2 建模语言建模语言UML及及Case工具工具n3 UML模型树型组织结构模型树型组织结构n4 UML对模型内容的表述对模型内容的表述3/1102023-1-2610.2.1 面向对象的建模过程框架面向对象的建模过程框架n 1 建模过程比较n 2 建模过程框架n 3 迭代策略n 4 人员分工与职责4/1102023-1-261.建模过程比较需求调查需求调查 需求分析需求分析 概要设计概要设计 详细设计详细设计 编程编程 系统流程图；系统流程图；高层数据

2、流图；高层数据流图；文档等文档等数据流程图；数据流程图；数据字典；数据字典；处理逻辑表达工处理逻辑表达工具；具；功能结构图；功能结构图；两个设计策略；两个设计策略；结构优化（独立结构优化（独立性）；性）；程序结构；程序结构；数据库；数据库；代码；代码；用原代码按用原代码按程度框图写程度框图写程度程度用例图；用例图；用例报告；用例报告；其他文档等其他文档等定义类属性定义类属性和方法；和方法；实现类的方实现类的方法；法；有哪些类？有哪些类？类应该有哪些属性？类应该有哪些属性？类应该有哪些操作？类应该有哪些操作？按责任识别一些类；按责任识别一些类；构造交互场景，实现用构造交互场景，实现用例描述的功能

3、；例描述的功能；根据交互中，请求与响根据交互中，请求与响应消息的情况，为类归应消息的情况，为类归纳责任；纳责任；将与应用相关的类的责将与应用相关的类的责任细化为操作；任细化为操作；为使用软件方式实现系为使用软件方式实现系统功能，再引入一些类，统功能，再引入一些类，并归纳操作；并归纳操作；细化属性；细化属性；细化操作；细化操作；5/1102023-1-262.面向对象的建模过程框架面向对象的建模过程框架图图10.1 建模过程框架建模过程框架6/1102023-1-263建模过程中的迭代策略建模过程中的迭代策略n 支持迭代策略是软件工程过程的基本要求。支持迭代策略是软件工程过程的基本要求。n 图图

4、10.1所示的建模过程与所示的建模过程与Rational统一过程体现了同统一过程体现了同样的核心思想原则，即以样的核心思想原则，即以Use Case 驱动、以体系构驱动、以体系构架为核心的迭代化开发。架为核心的迭代化开发。7/1102023-1-26n 前两项任务以分析为核心，目的是抽取设计要素；后三前两项任务以分析为核心，目的是抽取设计要素；后三项任务以设计为核心，目的是构造设计方案。项任务以设计为核心，目的是构造设计方案。n 五项任务中包括五项任务中包括14个活动，个活动，14个活动进一步可以细化为个活动进一步可以细化为若干个步骤，建模实践中可以灵活运用。若干个步骤，建模实践中可以灵活运用

5、。8/1102023-1-26迭代策略的体现迭代策略的体现n 由于在全局分析任务中引入了由于在全局分析任务中引入了“选定分析局部选定分析局部”活动，活动，建模过程可以充分地支持迭代化开发的策略，如图建模过程可以充分地支持迭代化开发的策略，如图10.1所示。所示。n 通常，全局分析任务中前几项活动在后续迭代中可以被通常，全局分析任务中前几项活动在后续迭代中可以被略去。略去。9/1102023-1-26n 理解迭代策略的关键是领会迭代化开发策略的思想。理解迭代策略的关键是领会迭代化开发策略的思想。n 迭代化方法中通常不作过多的假设，尽量降低对既往工作迭代化方法中通常不作过多的假设，尽量降低对既往工

6、作结果进行大面积否定的可能。结果进行大面积否定的可能。n 因为在实践中，前期活动中过度的假设往往会导致后续工因为在实践中，前期活动中过度的假设往往会导致后续工作不得不将错就错，表面上还能满足要求，但暗中牺牲了作不得不将错就错，表面上还能满足要求，但暗中牺牲了整体的质量和持续演进的能力。整体的质量和持续演进的能力。10/1102023-1-264.建模活动中人员的分工与职责建模活动中人员的分工与职责n 参与建模过程的技术人员主要是系统分析师和设计师参与建模过程的技术人员主要是系统分析师和设计师n（注意：系统分析师也就是系统分析员，设计师也就是注意：系统分析师也就是系统分析员，设计师也就是软件工程

7、师。为便于讨论问题，本书后面章节中统一使软件工程师。为便于讨论问题，本书后面章节中统一使用分析师与设计师的叫法用分析师与设计师的叫法）。）。11/1102023-1-26n 在个人综合素质方面，分析师应该具有领导才能，能够在个人综合素质方面，分析师应该具有领导才能，能够在压力下做出关键性的决策，并善始善终；能够赢得项在压力下做出关键性的决策，并善始善终；能够赢得项目经理、用户、用户群体以及管理团队的认同和尊敬，目经理、用户、用户群体以及管理团队的认同和尊敬，尤其善于和项目经理紧密协作；在各个方面都能表现出尤其善于和项目经理紧密协作；在各个方面都能表现出面向目标的实干作风。面向目标的实干作风。1

8、2/1102023-1-26n 在专业技能方面，与其他角色相比，分析师一般具有全在专业技能方面，与其他角色相比，分析师一般具有全方位的技能，他对相关知识的见解重在广度，而不是深方位的技能，他对相关知识的见解重在广度，而不是深度。度。n 分析师不仅需要具备软件工程师的各项技能，而且应该分析师不仅需要具备软件工程师的各项技能，而且应该具有用户专业领域和软件开发领域的实践经验，从而有具有用户专业领域和软件开发领域的实践经验，从而有能力在无法获得完整信息的情况下迅速领悟问题，并根能力在无法获得完整信息的情况下迅速领悟问题，并根据经验做出审慎的判断。据经验做出审慎的判断。13/1102023-1-26n

9、 分析师有可能是一个团队，但其中应有一人具有足分析师有可能是一个团队，但其中应有一人具有足够的权威。够的权威。n 设计师关注的焦点主要在系统的局部或细节上。设计师关注的焦点主要在系统的局部或细节上。14/1102023-1-26n 设计师应该掌握的技能包括：设计师应该掌握的技能包括：v 理解以理解以Use Case建模技术捕获和描述的软件需求；建模技术捕获和描述的软件需求；v 在分析师的统一协调下，应用在分析师的统一协调下，应用UML进行局部的面向进行局部的面向对象分析和设计；对象分析和设计；v 了解主流的实施技术，如设计语言和开发环境。了解主流的实施技术，如设计语言和开发环境。15/1102

10、023-1-26n 从图从图10.1中不难看出，分析师负责全局性的分析和设计中不难看出，分析师负责全局性的分析和设计问题，设计师负责局部性的分析和设计问题以及细节性问题，设计师负责局部性的分析和设计问题以及细节性的设计问题。的设计问题。n 按照图按照图10.1所示，建模的迭代过程中部署了两次全局到所示，建模的迭代过程中部署了两次全局到局部的过渡，每一次过渡都为分析师和设计师之间提供局部的过渡，每一次过渡都为分析师和设计师之间提供了沟通的机会，这为提升设计方案的质量和完整性创造了沟通的机会，这为提升设计方案的质量和完整性创造了有利条件。了有利条件。16/1102023-1-262建模过程的框架图

11、11.1 建模过程框架图图10.117/1102023-1-2610.2.2 建模语言建模语言UML及及Case工具工具n UML，全称是，全称是Unified Modeling Language,为统一建为统一建模语言。模语言。n 1 UML的来历的来历n 2 UML的优势的优势n 3 掌握掌握UML的学习方法的学习方法n 4 Rational Rose软件（建模工具）软件（建模工具）18/1102023-1-261 UML的来历 n 20世纪世纪90年代初，很多面向对象的方法已经拥有自己的年代初，很多面向对象的方法已经拥有自己的符号体系，其中有三种比较突出：符号体系，其中有三种比较突出：v

12、 James Rumbaugh博士的博士的OMT方法，方法，v Grady Booch的的Booch方法方法v Ivar Jacobson博士的博士的OOSE方法。方法。19/1102023-1-26James Rumbaugh 博士博士 Ivar Jacobson雅各布森博士雅各布森博士 Grady Booch科德布奇科德布奇 20/1102023-1-26n 不同的方法和符号体系各有所长：不同的方法和符号体系各有所长：v OMT擅长分析擅长分析v Booch擅长设计擅长设计v OOSE则擅长业务建模则擅长业务建模n 那个时期，为了建立比较丰满的模型并进行有效的沟通，那个时期，为了建立比较丰

13、满的模型并进行有效的沟通，需要掌握不同的符号体系，并且花费一些精力去翻译和需要掌握不同的符号体系，并且花费一些精力去翻译和转述模型。转述模型。21/1102023-1-26UML的来历n 后来，上述三位大师在各自的著作中自然而然地融入了后来，上述三位大师在各自的著作中自然而然地融入了其他两种方法的技术内容其他两种方法的技术内容n Jim Rumbaugh于于1994年离开年离开GE加入加入Grady Booch所所在的在的Rational公司，开始和公司，开始和Grady Booch协同研究一种协同研究一种统一的方法。统一的方法。n 一年后，一年后，Unified Method 0.8诞生了。

14、诞生了。n 同年，同年，Rational收购了收购了Ivar Jacobson所在的所在的Objectory公司，公司，Ivar Jacobson从此也成为从此也成为Rational的一员。的一员。n Unified Method不久更名为不久更名为UML。22/1102023-1-26UML的由来？n Jim Rumbaugh是IBM杰出的工程师，如今他正领导IBM Rational分部的软件建模工作。他和Grady Booch、Ivar Jacobson并称为发明UML的“三友”n UML在1997年被国际对象组织接收为建模标准。23/1102023-1-262 UML的优势n 统一建模语

15、言，顾名思义有三个要点：统一（Unified）、建模（Modeling）和语言（Language）。24/1102023-1-26理解UML的优势n（1）“统一统一”是是UML的核心的核心n UML它提升了开发团队的沟通效率，节约了以往用于翻它提升了开发团队的沟通效率，节约了以往用于翻译和转述的开销，屏蔽了藏匿于含糊语义中的风险。译和转述的开销，屏蔽了藏匿于含糊语义中的风险。v 符号系统不统一，是长期以来潜在的沟通壁垒，而使符号系统不统一，是长期以来潜在的沟通壁垒，而使用用UMLUML表述的内容能被各类人员所理解，包括用户、表述的内容能被各类人员所理解，包括用户、领域专家、分析师、设计师、程序

16、员、测试人员和培领域专家、分析师、设计师、程序员、测试人员和培训师等。训师等。v 通过通过UMLUML，他们可以充分地理解并表述自己所关注的，他们可以充分地理解并表述自己所关注的那部分内容。那部分内容。25/1102023-1-26（2）“建模建模”体现了体现了UML的使用价值的使用价值n UML在制定过程中汲取了多种建模方法的精华，包括业在制定过程中汲取了多种建模方法的精华，包括业务建模和数据建模等。务建模和数据建模等。v UMLUML的使用价值体现在特定类型的建模活动中的使用价值体现在特定类型的建模活动中,学习者，学习者，如果以掌握如果以掌握UMLUML的符号和规则为最终目的，那将所获的符

17、号和规则为最终目的，那将所获甚微。甚微。v 尽管尽管UMLUML所表述的内容可以贯穿系统开发的整个生命所表述的内容可以贯穿系统开发的整个生命周期，但周期，但UMLUML不同于普通的程序设计语言，所以仅仅不同于普通的程序设计语言，所以仅仅掌握掌握UMLUML的符号和规则并不能得到实际的解决方案。的符号和规则并不能得到实际的解决方案。26/1102023-1-26（3）“语言语言”是是UML的普遍价值的表现的普遍价值的表现v 语言的一层基本含义是一套按照特定规则和模式组成的语言的一层基本含义是一套按照特定规则和模式组成的符号系统，被拥有相同传统和习惯的人群所使用。符号系统，被拥有相同传统和习惯的人

18、群所使用。v 语言是有效沟通工具。近年来，软件开发所涉及的技术语言是有效沟通工具。近年来，软件开发所涉及的技术飞速发展，不同技术门类所使用的建模语言自成体系，飞速发展，不同技术门类所使用的建模语言自成体系，同时也具有很大的局限性，表现形式的差异往往掩盖了同时也具有很大的局限性，表现形式的差异往往掩盖了本质内容的相通。本质内容的相通。UMLUML打通了这种壁垒。打通了这种壁垒。27/1102023-1-263 掌握掌握UML的学习方法的学习方法n 通常，我们没必要在掌握所有的词汇和语法之后才开始通常，我们没必要在掌握所有的词汇和语法之后才开始使用一种语言。使用一种语言。n 掌握语言的关键在于有目

19、的地使用，学习掌握语言的关键在于有目的地使用，学习UML的情况很的情况很类似。类似。n 在开始阶段，基于一个明确目标，集中精力理解一些必在开始阶段，基于一个明确目标，集中精力理解一些必要的词汇和语法，在使用中深入体会才是事半功倍的做要的词汇和语法，在使用中深入体会才是事半功倍的做法。法。28/1102023-1-264 Rational Rose软件（建模工具）n UML语言规定了统一的建模符号与规则，在具体建模实语言规定了统一的建模符号与规则，在具体建模实践活动中，常借助于软件工具完成建模活动。践活动中，常借助于软件工具完成建模活动。n 常用的建模工具常用的建模工具Rosen 演示演示Ros

20、e安装与使用安装与使用29/1102023-1-2610.2 UML及建模过程及建模过程n1 建模过程框架建模过程框架n2 建模语言建模语言UML及及Case工具工具n3 UML模型树型组织结构模型树型组织结构n4 UML对模型内容的表述对模型内容的表述30/1102023-1-2610.2.3 UML模型的树型组织结构模型的树型组织结构n 下面以实用为目标，简单介绍一些使用UML建立的面向对象的模型基本情况31/1102023-1-26n 总体上，模型的内容通过“包”以及“包”的层层嵌套组织在一起，构成树型结构。v 模型中的“包”类似于Windows系统管理磁盘文件的目录结构，如图4.3所示

21、。包将一堆零散的模型内容简单地组织在一起，目的是更易于理解和管理。32/1102023-1-26用用“包包”组织模型内容组织模型内容图图10.3 模型的组织结构模型的组织结构 33/1102023-1-26第一层“包”，被称为“视图view”n 在需求定义阶段，从调查与分析用户需求的视角，得到在需求定义阶段，从调查与分析用户需求的视角，得到的就是需求模型的就是需求模型n 在设计阶段，从实现用户需求的视角，得到的就是设计在设计阶段，从实现用户需求的视角，得到的就是设计模型模型n 模型应该能够反映建模者和使用者的特定视角，它就是模型应该能够反映建模者和使用者的特定视角，它就是建模动机，表现为的模型

22、中的建模动机，表现为的模型中的“构架视图构架视图”（Archiecture View）。）。34/1102023-1-26n 在模型中，构架视图用包的形式表达。每一种特定的在模型中，构架视图用包的形式表达。每一种特定的“视角视角”对应一种类型的构架视图，在对应一种类型的构架视图，在Rational Rose建模工具中：建模工具中：n 用用“用例视图用例视图”（Use Case View）描述需求模型；）描述需求模型；n 用用“逻辑视图逻辑视图”（Logical View）描述设计模型。）描述设计模型。n 还有组件视图和部署视图分别用于描述实施模型和系统整体还有组件视图和部署视图分别用于描述实施

23、模型和系统整体部署。部署。35/1102023-1-26图图10.3 模型的树型组织结构模型的树型组织结构 36/1102023-1-26n 演示树型结构的模型中，每个演示树型结构的模型中，每个“包包”中存放的具体模型中存放的具体模型内容。内容。n 解释解释“包包”的构造型（的构造型（Stereotype）v“视图视图”、“层层”的本质上也是的本质上也是“包包”。n“构造型构造型”UML提供的语义扩展机制，在随后的内容中，提供的语义扩展机制，在随后的内容中，我们还会见到我们还会见到“类类”的构造型，的构造型，“Use case的构造型等。的构造型等。37/1102023-1-2610.2 UM

24、L及建模过程及建模过程n1 建模过程框架建模过程框架n2 建模语言建模语言UML及及Case工具工具n3 UML模型树型组织结构模型树型组织结构n4 UML对模型内容的表述对模型内容的表述38/1102023-1-2610.2.4 UML对模型内容的表述对模型内容的表述n 概念上，概念上，UML用于描述模型的基本词汇有三类：用于描述模型的基本词汇有三类：v“要素要素”v“关系关系”v“图图”39/1102023-1-261.UML中的要素中的要素n“要素要素”是是UML提供的一些基本符号提供的一些基本符号v 如如“Use Case”“角色角色”“”“类类”“”“接口接口”“”“子系子系统统”“

25、”“包包”等等40/1102023-1-262.UML中的中的“关系关系”n“关系关系”是是UML对各种要素之间不同类型关联关系的表对各种要素之间不同类型关联关系的表述述n UML对对“要素要素”之间的关系表述为四种类型之间的关系表述为四种类型41/1102023-1-26（1）关联关系（）关联关系（Association）n 表达两个类的实例之间存在连接表达两个类的实例之间存在连接v 聚集关系（聚集关系（Aggregation）和组合关系）和组合关系（Composition）是关联关系的两种强化形式）是关联关系的两种强化形式v UML中，将二者合称为中，将二者合称为“聚合聚合”关系，不加区别

26、关系，不加区别图图10.4 聚合关系聚合关系42/1102023-1-26（2）依赖关系（Dependency）n Dependency（依赖）or instantiates(实例化）n 依赖者“使用”被依赖者的关系图图10.5 依赖关系依赖关系43/1102023-1-26（3）泛化关系（Generalization）n 表达“特殊的”与“一般的”的关系。图图10.6 泛化关系泛化关系44/1102023-1-26（4）实现关系（Realization）n“被实现者”是要求的说明，“实现者”是针对要求的解决方案。图图10.7 实现关系实现关系45/1102023-1-26简化的表示方法图图1

27、0.8 实现关系的简化形式实现关系的简化形式46/1102023-1-263.UML中的中的“图图”n“图”是表述模型“动态”行为和“表态”结构的主要工具。UML中有九种图，常用的有六种n 两种表示静态结构的图v 包括：“Use Case图”“类图”n 四种表示动态场景的图v 包括：“序列图”“协作图”“活动图”“状态图”47/1102023-1-261.Use Case图图图10.9 影院售票系统影院售票系统Use Case图图48/1102023-1-26表述追溯关联的Use Case图n Use Case图主要用于表述系统的主要业务构成和系统与外部角色的交互（即系统的边界）n 主要内容包

28、括：Use Case和Actorn 与用于表示模型中的可追溯关联系图图10.10 用用Use Case图表示可追溯的关联图表示可追溯的关联49/1102023-1-26Use Case图在模型中的位置n 这种用法的Use Case图通常位于“Use Case模型”的“Use Cases”包内，如图10.11所示。n 通常将Actors和Use Case放在不同的包中。图图10.11 Use Case图在模型中的位置图在模型中的位置50/1102023-1-26主动角色与被动角色n Use Case与外部的交互活动中可能涉及若干个Actor，但是只有一个主动要求得到有价值的可见结果，常被称之为主

29、导（Primary）Actor。主导Actor触发交互活动，它到相应的Use Case的连线是标有箭头的。n 与该Use Case相连的其他Actor则为被动Actor，相应的连线不标箭头。51/1102023-1-26n Actor和Use Case之间的连线称为通信关联，表示Actor和相应的Use Case之间的交互。n 无论有没有箭头，通信关联都表示介于Actor和相应Use Case之间的双向会话n 用箭头仅表示Actor触发Use Case的执行52/1102023-1-26Use Case的构造型Use Case实现n 概念上，“Use Case实现”是指用拟定的方案实现用户提出

30、的需求（用use case表达的需求），如图10.12所示。53/1102023-1-26图图10.12 Use Case实现实现n本质上，本质上，“Use Case”和和“Use Case实现实现”都是一个都是一个“包包”的概念的概念nUse Case中可以存放中可以存放Use Case报告、报告、局部局部Use case图、活动图等，以对图、活动图等，以对需求进行定义需求进行定义nUse Case实现中，存放的是实现方实现中，存放的是实现方案，如序列图、协作图、类图、活动案，如序列图、协作图、类图、活动图等图等54/1102023-1-262.类图n 类图也是一种静态图，主要用于展示类、接

31、口、包及其关系。55/1102023-1-26类图图图10.12 类图类图56/1102023-1-26较少详细的类图图图10.13 详细的类图详细的类图57/1102023-1-26n 类图中，表示“类”及“类的构造型”之间的关联关系n 类的构造型包括“关键抽象”、各种类型的“分析类”、“接口”、“子系统”、“子系统代理”等n 类图，是分析设计的重要结果，是编程的重要依据58/1102023-1-26n 类图中，除了可以表述前面讲过的几种关联关系类型以外，还可以表示出更加详细的关联信息：59/1102023-1-26关联关系的多重性（Multiplicity）n 表示A的多少个实例对应B的一

32、个实例n 图10.14给出一个通俗实例，一只麻雀两条腿，一只螃蟹八条腿。60/1102023-1-26图图10.14 关联关系中的多重性表示关联关系中的多重性表示 61/1102023-1-26n 在对多重性没有明确认识的时候，可暂不做标注。当然，如果多重性非常明显，也可省略标注。n 在分析和设计过程中，多重性主要用来表述业务规则，常见的标识方式有“1”、“*”、“0.1”、“0.*”、“1.*”等。62/1102023-1-26图图10.15 关联关系中的聚合示例关联关系中的聚合示例 63/1102023-1-26关联关系的访问方向n 关联关系的访问方向表示某一方的实例能够“访问”另一方的实

33、例。如图10.16所示图图10.16 关联关系的访问方向关联关系的访问方向64/1102023-1-26n 在一个小公司里，公司的总裁认识所有的职员，当然每在一个小公司里，公司的总裁认识所有的职员，当然每个职员都认识公司的总裁；个职员都认识公司的总裁；n 在大公司里则有所不同，所有的职员都认识公司的总裁，在大公司里则有所不同，所有的职员都认识公司的总裁，但是总裁通常只认识核心职员，并不认识那些外围职员，但是总裁通常只认识核心职员，并不认识那些外围职员，因而大公司总裁和大公司外围职员之间的关联关系是单因而大公司总裁和大公司外围职员之间的关联关系是单方向的。方向的。65/1102023-1-26n

34、 至少存在一个可用的访问方向，如果仅存在一个可至少存在一个可用的访问方向，如果仅存在一个可用的访问方向，那么关联关系是单向的，用箭头表用的访问方向，那么关联关系是单向的，用箭头表述这一概念，两端都没有箭头的连线表述关联关系述这一概念，两端都没有箭头的连线表述关联关系是双向的。是双向的。66/1102023-1-26关联关系中的角色（Role）n 表示该类在对方眼里所扮演的角色或用途，或者说对方是如何看待自己的，即类A的实例对类B的实例的具体含义。可以结合图10.17中的实例加以理解：一个领域专家对一个行业协会而言是一个成员，一个行业协会对一个领域专家而言是一个信息来源；依次类推。67/1102

35、023-1-26图图10.17 关联关系中的角色示例关联关系中的角色示例 68/1102023-1-263.序列图n 序列图是和序列图是和Use Case报告对应的内容报告对应的内容n 一个一个Use Case报告，一般包括一个报告，一般包括一个“基本事件序列基本事件序列”和若干个和若干个“备选事件序列备选事件序列”；每一个序列，都可以用一；每一个序列，都可以用一个个“序列图序列图”表述其动态交互场景，所以说，序列图是表述其动态交互场景，所以说，序列图是对对Use Case报告的转述。报告的转述。n 序列图，是为其参与类归纳其数据和责任的关键活动场序列图，是为其参与类归纳其数据和责任的关键活动

36、场景。景。69/1102023-1-26图图10.18 序列图序列图70/1102023-1-26n 消息消息n 消息是对象间通信的具体内容，消息表述为一条对象生消息是对象间通信的具体内容，消息表述为一条对象生存线到另一条对象生存线的带箭头的水平实线，箭头指存线到另一条对象生存线的带箭头的水平实线，箭头指向接受消息的对象。向接受消息的对象。n 如果消息被对象发至其自身，称为返身消息。如果消息被对象发至其自身，称为返身消息。n 消息由序号、名称和参数组成。序号可以是连续编号或消息由序号、名称和参数组成。序号可以是连续编号或层次化编号，名称是必须的内容，参数按需而定。层次化编号，名称是必须的内容，

37、参数按需而定。71/1102023-1-26序列图图图10.19 序列图（表述分析类之间的协作场景）序列图（表述分析类之间的协作场景）72/1102023-1-26n 这里的几种符号，是类的几个构造型：n 实体类、控制类和边界类；n 这是在“提取分析类”的过程中，使用的概念n 分析类的具体构造型，更能说明其参与协作中的职责n 在后续的建模过程中还会看到“子系统代理”、同样都是具有特殊含意类的构造型73/1102023-1-26较详细的序例图图图10.20 序列图序列图74/1102023-1-264.协作图n 协作图（Collaboration）n 协作图是一种动态图，其核心内容与序列图相对应

38、，与序列图表示的是相同的内容，但它并不是关注对象之间消息传递的场景，而是强调对象间由于收发消息而关联起来的一种组织结构。序列图和协作图统称交互图（Interaction Diagram）。75/1102023-1-26图图10.21 用序列图生成的协作图用序列图生成的协作图76/1102023-1-26协作图举例图图10.22 协作图协作图77/1102023-1-26n 可以通过序列图直接生成相应的协作图。在Rose中的操作步骤为：首先选中序列图，然后在主菜单中选择“Browse|Create Collaboration Diagram”，这样就可以自动生成对应于该序列图的协作图了。n 图1

39、0.22就是根据图10.19自动生成的78/1102023-1-26n 协作图主要用于描述局部分析和设计中的特定场景，其特点是强调对象间的结构关系。这种用法的协作图位于“Use Case实现”的协作中，通常，只关注那些对应重要事件序列的协作图，即不是所有的序列图都有必要给出相应的协作图。79/1102023-1-265.状态图（Statechart Diagram）n状态图也是一种动态图，主要用于展示对象在其生命周期中可状态图也是一种动态图，主要用于展示对象在其生命周期中可能经历的状态，以及在这些状态上对事件的响应能力。能经历的状态，以及在这些状态上对事件的响应能力。80/1102023-1-

40、26“接口接口“概念概念图图10.23 状态图状态图81/1102023-1-26图图10.24 状态图在模型中的位置状态图在模型中的位置 82/1102023-1-266.活动图（Activity Diagram）n 活动图也是一种动态图，用于展示系统从一个活动流转活动图也是一种动态图，用于展示系统从一个活动流转到另一个活动的可能路径与判断条件。到另一个活动的可能路径与判断条件。n 其他三种静态图分别为对象图（其他三种静态图分别为对象图（Object Diagram）、构）、构件图（件图（Component Diagram）和部署图）和部署图（Deployment Diagram）。）。83

41、/1102023-1-26活动图图图10.25 活动图活动图84/1102023-1-26总结：对建模活动的进一步认识n 注注:这部分内容可以不讲这部分内容可以不讲85/1102023-1-26总结对建模活动的进一步认识n 模型可以描述系统的静态结构，也可以描述系统的动态模型可以描述系统的静态结构，也可以描述系统的动态行为；可以描述系统的宏观面貌，也可以描述系统内的行为；可以描述系统的宏观面貌，也可以描述系统内的微观交互场景。微观交互场景。86/1102023-1-26n 模型会先于方案而存在，模型提供了营造方案的蓝图。87/1102023-1-26（1）建模是有目的n 从某个角度看问题，排除

42、不必要的干扰，把问题化简，抓住主要矛盾和事物的本质，这就是建模的目的。v 打一个比方，一座大楼在土木设计师眼里可能是一堆钢筋混凝土和表面材质；在管道设计师眼里可能是一堆管子和接头；在网络工程师眼里可能是一堆网络设备和布线。不同主体对同一客体的认识结果有赖于各自的视角，即看问题的角度。这样能更好地集中注意力，从而有效地解决关键问题。88/1102023-1-26（2）建模是有原则的n 在建立模型的过程中，建模者的主观立场或认识问题的角度，被强调为认知活动的原则，这很重要。n 建模过程就是简化问题的过程，就是要把某些主要的关键的东西勾勒出来，把对讨论问题无关紧要的东西暂时略去，以免干扰视线。v 因

43、此，在讨论一个系统中的某个问题的时候，我们不是把整个系统都详细地表述出来以后再进行讨论，而习惯于从某个角度整理出一个从某个侧面观察的问题模型，这就是建模的原则。89/1102023-1-26n 对于一个系统，基于不同的简化动机（目的）和简化水平（原则），可以得到多个模型，这样有助于更深刻和更准确地把握系统的本质。90/1102023-1-2610.6.3 对模型的评价n 利用价值高的模型就是好模型；v 针对特定的建模“动机”和“原则（抽象层次）”，我们通常会忽略那些与特定抽象层次无关的次要因素，而强调那些具有广泛影响力的主要因素，这就是在追求模型的使用价值。v 换言之，内容多的模型未必是好模型

44、，因为价值高的内容有可能被价值不高的内容淹没了。91/1102023-1-26v 模型的的好坏，取决于两个因素，即建模的“视角（动机）”和“抽象层次”，这两个因素决定了模型有没有把握问题的本质和有没有洽到好处的排除掉干挠视线的次要因素，便于清晰的认识问题。92/1102023-1-26（3）模型的表述n 模型是一组具有完整语义的信息，包括两个方面的含义：v 一方面，模型是对现实的简化；v 另一方面，模型反映了认知主体（开发人员）对问题域认识的视角和抽象层次。不同的视角，表现为各种类型的图（Diagram）及其包含的元素和关联；不同的抽象层次，表现为不同类型的视图（View）。两者都是模型不可或

45、缺的要素。93/1102023-1-26n 尽管说模型是简化的现实，并强调化简价值，但这并不意味着可以片面地夸大图示信息的作用，好的模型应该是图文并茂，其关键是可用和易用。94/1102023-1-26（4）建模的价值n 建模（Modeling）是捕捉问题本质的过程。为了降低风险和获得高回报，建模活动普遍应用于各种行业，信息系统（软件）开发更不例外。为了说明建模的价值，Grady Booch曾经给出过一个经典的类比：95/1102023-1-26v 盖一个宠物窝棚、修一个乡间别墅和建一座摩天大楼，三种工作对建筑规划图纸的依赖程度有质的差异。建立一个简单的系统，模型可有可无；建立一个比较复杂的系

46、统，模型的必要性增大；建立一个高度复杂的系统，模型则不可缺少。应用处理简单系统的方法对待复杂系统通常是行不通的，这好比用搭建一个宠物窝棚的方法来营造一座摩天大厦。96/1102023-1-26n 建模的意义随着系统复杂程度的增加而越发显著，从起初借助于模型以更好地理解系统，到后来不得不借助模型来理解系统。人脑对复杂问题的理解能力是有限的，与模型相应的特定视角和抽象层次是简化复杂问题的有效出发点。97/1102023-1-26n 建模对于复杂软件系统的开发是必要的v 目前，我们开发的软件，特别是商业软件，通常一开始就很不简单，并且复杂性随着时间的演进和技术的发展持续上升。一个复杂软件系统的开发必

47、须面对多种未知因素、多个开发人员、复杂的开发工具和永远不够用的时间。开发人员不可能、更没有必要去了解从问题到方案的所有细节。他们需要那些基于特定视角的、有助于解决问题的并且是完整的某一部分信息，即所谓的模型。总之，建模对于复杂软件系统的开发是必要的。98/1102023-1-26n 建模活动是有意识的、有目的、有原则、有计划的严密工作v 广义上讲，无论出于何种动机，只要在问题到方案之间做出一些过渡性的努力，哪怕只是在草稿或白板上画了几笔，实际上就是在建模了。v 不过有意识和无意识的建模活动对模型的质量或价值的影响很大。有意识的建模活动通常是有计划的、有准备的和早动手的。通过这样的建模活动，得到

48、的模型通常是完整的、一致的和可复用的。无意识的建模活动，通常是随机的、无准备的和补救性的，得到的模型往往是零散的、混乱的和一次性的。99/1102023-1-26n 准确地讲，建模活动直观地记录下认知和求解过程，支持团队成员之间的有效沟通，为重复利用各个阶段积累的智力成果创造了有利的条件。n 概括地讲，建模简化了认知过程，化简了求解过程。100/1102023-1-26本 章 小 结 n 模型不仅是一种表述工具，更是一种思维与交流沟通的工具。为了便于表述问题，我们把复杂的现实系统简化为模型，以理解系统的本质特征。为了使技术人员能够理解用户的意图或需求，我们使用模型来表述我们理解的系统内容。为了

49、实现拟建系统，我们通过模型演化，不断丰富模型的内容，把从用户专业领域提取出来的模型经过演化，最终得到可以适合用计算机实现的模型。这些用途正是建模的价值所在。101/1102023-1-26n 手工维护一个复杂的信息系统模型几乎是不可能的。UML是在综合了几种面向对象方法的基础上，推出的一种统一建模语言，它是我们进行面向对象建模的有力辅助工具。n UML作为一种建模语言，强调的就是它的表述与沟通能力。它有一套可视化的符号、一套表述机制。为了增强其表述能力，UML还提供了一种语义扩展机制，即构造型。UML常用的六种图包括Use Case图、序列图、协作图、状态图、活动图和类图。102/110202

50、3-1-26n Rational Rose是目前常用的UML建模工具。Rose建模中，包括用例视图、逻辑视图、组件视图和部署视图。在每种视图中，使用“包”作为管理手段，将模型的相应内容组织在不同的视图中。在“包”中建立相应的图、表及文字描述。n 学习UML语言，不在于理解其符号的含义和语言机制，更重要的是理解面向对象的思想。把面向对象的思想融入到建模过程中。运用UML符号与机制体现出面向对象的建模思想与分析和设计的结果。103/1102023-1-26思 考 题n10-1 简述什么是模型。n10-2 在系统分析与设计活动中，模型的价值体现在哪里？n10-3 UML的构成要素有哪些？在应用中它如