1、第10章 UML建模语言,10.1 模型的作用 10.2 统一建模语言UML 10.3 UML模型 10.4 常见图的用法与内容,2019/1/1,第8章 运行与维护,2/56,10.1 模型的作用,借助于模型实现对复杂系统的认识，是一种有效手段； 实际的管理信息系统是一个复杂的系统，我们要开发以计算机处理为基础的现代管理信息系统，首先就得认识、理解原有的系统或手工业务，经过反复讨论和修改以后，构造出新的管理信息系统方案。在这一过程中，模型起着非常关键的作用。 模型可以帮助我们以化简的形式捕捉现实系统中问题的本质； 通过模型可以把被讨论的概念可视化，把你心目中的系统实现方案勾勒出来，把它变成大
2、家能够看得见的东西，便于讨论和修改； 模型有助于在由“问题”到“方案”的过渡过程中更好的认知、理解和沟通。 结论：学习建模是学习软件开发（包括管理信息系统开发）的一项基本技能。,2019/1/1,第8章 运行与维护,3/56,10.1 模型的作用,10.1.1 什么是模型 10.1.2 建模的价值,2019/1/1,第8章 运行与维护,4/56,10.1.1 什么是模型,模型并不深奥。 在你和别人讨论问题时，把你想表达的东西以简化的形式画到纸上，这就是模型，哪怕是随便勾画了几笔，只要有助于表达问题，它就是模型了。模型可以描述系统的静态结构，也可以描述系统的动态行为；可以描述系统的宏观面貌，也可
3、以描述系统内的微观交互场景。 简单地讲，模型是对现实的简化、或者说，模型是简化的现实； 模型会先于方案而存在，模型提供了营造方案的蓝图。,2019/1/1,第8章 运行与维护,5/56,建模是有目的,建模的目的，是为了认识复杂的问题（或系统）；简化是认识复杂系统的一种有效方法；而建模是简化问题的有效手段； “简化”是有目的的进行的 准确地讲，一个具体的模型是人对现实系统抽象认知的结果，这一结果取决于人和他观察问题的角度。人是认知活动的主体，他在认识一个事物的时候，往往是带有主观意志的，即他会从自己的立场或角度来看问题。 从某个角度看问题，排除不必要的干扰，把问题化简，抓住主要矛盾和事物的本质，
4、这就是建模的目的。 打一个比方，一座大楼在土木设计师眼里可能是一堆钢筋混凝土和表面材质；在管道设计师眼里可能是一堆管子和接头；在网络工程师眼里可能是一堆网络设备和布线。不同主体对同一客体的认识结果有赖于各自的视角，即看问题的角度。这样能更好地集中注意力，从而有效地解决关键问题。,2019/1/1,第8章 运行与维护,6/56,建模是有原则的,在建立模型的过程中，建模者的主观立场或认识问题的角度，被强调为认知活动的原则，这很重要。 建模过程就是简化问题的过程，就是要把某些主要的关键的东西勾勒出来，把对讨论问题无关紧要的东西暂时略去，以免干扰视线。 因此，在讨论一个系统中的某个问题的时候，我们不是
5、把整个系统都详细地表述出来以后再进行讨论，而习惯于从某个角度整理出一个从某个侧面观察的问题模型，这就是建模的原则。 对于一个系统，基于不同的简化动机（目的）和简化水平（原则），可以得到多个模型，这样有助于更深刻和更准确地把握系统的本质。,2019/1/1,第8章 运行与维护,7/56,对模型的评价,利用价值高的模型就是好模型； 针对特定的建模“动机”和“原则（抽象层次）”，我们通常会忽略那些与特定抽象层次无关的次要因素，而强调那些具有广泛影响力的主要因素，这就是在追求模型的使用价值。 换言之，内容多的模型未必是好模型，因为价值高的内容有可能被价值不高的内容淹没了。 模型的的好坏，取决于两个因素
6、，即建模的“视角（动机）”和“抽象层次”，这两个因素决定了模型有没有把握问题的本质和有没有洽到好处的排除掉干挠视线的次要因素，便于清晰的认识问题。,2019/1/1,第8章 运行与维护,8/56,模型的表述,模型是一组具有完整语义的信息，包括两个方面的含义： 一方面，模型是对现实的简化； 另一方面，模型反映了认知主体（开发人员）对问题域认识的视角和抽象层次。不同的视角，表现为各种类型的图（Diagram）及其包含的元素和关联；不同的抽象层次，表现为不同类型的视图（View）。两者都是模型不可或缺的要素。 尽管说模型是简化的现实，并强调化简价值，但这并不意味着可以片面地夸大图示信息的作用，好的模
7、型应该是图文并茂，其关键是可用和易用。,2019/1/1,第8章 运行与维护,9/56,10.1.2 建模的价值,建模（Modeling）是捕捉问题本质的过程。为了降低风险和获得高回报，建模活动普遍应用于各种行业，信息系统（软件）开发更不例外。为了说明建模的价值，Grady Booch曾经给出过一个经典的类比： 盖一个宠物窝棚、修一个乡间别墅和建一座摩天大楼，三种工作对建筑规划图纸的依赖程度有质的差异。建立一个简单的系统，模型可有可无；建立一个比较复杂的系统，模型的必要性增大；建立一个高度复杂的系统，模型则不可缺少。应用处理简单系统的方法对待复杂系统通常是行不通的，这好比用搭建一个宠物窝棚的方
8、法来营造一座摩天大厦。 建模的意义随着系统复杂程度的增加而越发显著，从起初借助于模型以更好地理解系统，到后来不得不借助模型来理解系统。人脑对复杂问题的理解能力是有限的，与模型相应的特定视角和抽象层次是简化复杂问题的有效出发点。,2019/1/1,第8章 运行与维护,10/56,建模对于复杂软件系统的开发是必要的 目前，我们开发的软件，特别是商业软件，通常一开始就很不简单，并且复杂性随着时间的演进和技术的发展持续上升。一个复杂软件系统的开发必须面对多种未知因素、多个开发人员、复杂的开发工具和永远不够用的时间。开发人员不可能、更没有必要去了解从问题到方案的所有细节。他们需要那些基于特定视角的、有助
9、于解决问题的并且是完整的某一部分信息，即所谓的模型。总之，建模对于复杂软件系统的开发是必要的。 建模活动是有意识的、有目的、有原则、有计划的严密工作 广义上讲，无论出于何种动机，只要在问题到方案之间做出一些过渡性的努力，哪怕只是在草稿或白板上画了几笔，实际上就是在建模了。不过有意识和无意识的建模活动对模型的质量或价值的影响很大。有意识的建模活动通常是有计划的、有准备的和早动手的。通过这样的建模活动，得到的模型通常是完整的、一致的和可复用的。无意识的建模活动，通常是随机的、无准备的和补救性的，得到的模型往往是零散的、混乱的和一次性的。 准确地讲，建模活动直观地记录下认知和求解过程，支持团队成员之
10、间的有效沟通，为重复利用各个阶段积累的智力成果创造了有利的条件。 概括地讲，建模简化了认知过程，化简了求解过程。,2019/1/1,第8章 运行与维护,11/56,10.2 统一建模语言UML,为了表达问题，你可以使用任何能够说明问题的图形符号、文字、表格、线条等，只要能说明问题，所有这些都可以作为建模的工具。 在管理信息系统的开发过程中，建模是必不可少的。在结构化的系统分析与设计过程中，我们学过的主要建模工具包括数据流图、数据字典、结构图等；UML则是面向对象的开发方法中使用的主要建模工具之一。 统一建模语言UML，全称是Unified Modeling Language。 掌握UML的建模
11、技术，是面向对象分析与设计的基本技能之一。,2019/1/1,第8章 运行与维护,12/56,Jim Rumbaugh是IBM杰出的工程师，如今他正领导IBM Rational分部的软件建模工作。他和Grady Booch、Ivar Jacobson并称为发明UML的“三友”，UML在1997年被国际对象组织接收为建模标准。他也参与了RUP的开发并且曾经是面向对象分析与设计方面的OMT的主要开发者。上周，InfoWorld编辑在在Santa Clara召开的SD West2005会议上对Rumbaugh进行了访谈，讨论了UML、SOA (service-oriented architectur
12、es) 和 ESB (enterprise service bus)技术。Rumbaugh对微软及其在UML上的骑墙姿势表示了不屑。,2019/1/1,第8章 运行与维护,13/56,UML的来历,20世纪90年代初，很多面向对象的方法已经拥有自己的符号体系，其中有三种比较突出： Jim Rumbaugh的OMT方法， Grady Booch的Booch方法 Ivar Jacobson的OOSE方法。 不同的方法和符号体系各有所长：OMT擅长分析，Booch擅长设计，OOSE则擅长业务建模。那个时期的面向对象技术人员没有我们这么幸运，为了建立比较丰满的模型并进行有效的沟通，他们需要掌握不同的符
13、号体系，并且花费一些精力去翻译和转述用不同符号体系表述的模型。,2019/1/1,第8章 运行与维护,14/56,UML的来历,在后来的几年中，上述三位大师在各自的著作中自然而然地融入了其他两种方法的技术内容。 Jim Rumbaugh于1994年离开GE加入Grady Booch所在的Rational公司，开始和Grady Booch协同研究一种统一的方法。一年后，Unified Method 0.8诞生了。 同年，Rational收购了Ivar Jacobson所在的Objectory公司，Ivar Jacobson从此也成为Rational的一员。Unified Method不久更名为U
14、ML。 仰仗三位面向对象方法学大师的威望，基于数十位业内重量级人物历时两年的通力合作，并充分考虑到多个合作伙伴的反馈意见，UML一步步趋于成熟。1997年9月，UML1.1被提交到国际对象管理组织，同年11月被该组织认定为标准的建模语言。 统一建模语言，顾名思义有三个要点：统一（Unified）、建模（Modeling）和语言（Language）。,2019/1/1,第8章 运行与维护,15/56,把握UML的优势和学习方法,“统一”是UML的核心。它提升了开发团队的沟通效率，节约了以往用于翻译和转述的开销，屏蔽了藏匿于含糊语义中的风险。 在传统的方法中，它们各自拥有专用的符号系统，这也是长期
15、以来潜在的沟通壁垒，而使用UML表述的内容能被各类人员所理解，包括用户、领域专家、分析师、设计师、程序员、测试人员和培训师等。通过UML，他们可以充分地理解并表述自己所关注的那部分内容。 “建模”体现了UML的使用价值。UML在制定过程中汲取了多种建模方法的精华，包括业务建模和数据建模等。 UML的使用价值不可能脱离特定类型的建模活动。对于学习者而言，如果以掌握UML的符号和规则为最终目的，你将所获甚微。尽管UML所表述的内容可以贯穿系统开发的整个生命周期，但UML不同于普通的程序设计语言，所以仅仅掌握UML的符号和规则并不能得到实际的解决方案。,2019/1/1,第8章 运行与维护,16/5
16、6,把握UML的优势和学习方法,“语言”是UML的普遍价值的表现 语言的一层基本含义是一套按照特定规则和模式组成的符号系统，被拥有相同传统和习惯的人群所使用。我们在日常生活中将“拥有共同语言”看做是能够有效沟通的必要条件。近年来，软件开发所涉及的技术飞速发展，不同技术门类所使用的建模语言自成体系，同时也具有很大的局限性，表现形式的差异往往掩盖了本质内容的相通。幸好，与人类的自然语言不同的是，在软件开发过程中使用的建模语言不涉及宗教和文化等诸多历史或地域障碍。在博采众长的基础上，UML作为一种共通的和可扩展的语言，其描述能力适用于软件开发中各种技术门类的建模活动。自然语言是人类对客观世界建模最直
17、接有效的表述形式；类似地，UML是迄今为止，软件开发人员进行统一建模活动最直接有效的表述形式。不仅如此，UML还是能被软件开发环境所理解的语言。 通常，我们没必要在掌握所有的词汇和语法之后才开始使用一种语言。掌握语言的关键在于有目的地使用，学习UML的情况很类似。在开始阶段，基于一个明确目标，集中精力理解一些必要的词汇和语法，在使用中深入体会才是事半功倍的做法。,2019/1/1,第8章 运行与维护,17/56,10.3 UML模型,下面以实用为目标，简单介绍一些UML的基本语义、内容组织与表述规则，内容包括三小节： 10.3.1 模型的基本内容 10.3.2 UML的语义扩展 10.3.3
18、模型的组织结构,2019/1/1,第8章 运行与维护,18/56,10.3.1 模型的基本内容,概念上，UML用于描述模型的基本词汇有三类：要素、关系和图。 “要素”是模型中的核心内容，可以形象地理解为“点”； “关系”在逻辑上将要素联系在一起，可以形象地理解为“线”； “图”将一组要素和关系展现出来，可以形象地理解为“面”。 总体上看，由这些“点”、“线”、“面”组成了“立体”的模型。,2019/1/1,第8章 运行与维护,19/56,1第一类词汇要素,UML中有四种类型的要素。 （1）表述结构的要素，包括“Use Case”、“类（Class）”、“接口（Interface）”和“协作（C
19、ollaboration）”。 （2）表述行为的要素，包括“交互（Interaction）”和“状态机（State Machine）”。 （3）用于组织模型内容的要素，即“包（Package）”。 （4）用做辅助说明的要素，即“注释（Notes）”。,2019/1/1,第8章 运行与维护,20/56,2第二类词汇关系,UML中有四种类型的关系。 （1）关联关系（Association），表达两个类的实例之间存在连接。聚集关系（Aggregation）与组合关系（Composition）是关联关系的两种强化形式。 （2）依赖关系（Dependency），依赖者“使用”被依赖者的关系。 （3）泛化
20、关系（Generalization），表达“特殊的”与“一般的”的关系。 （4）实现关系（Realization），“被实现者”是要求的说明，“实现者”是针对要求的解决方案。,2019/1/1,第8章 运行与维护,21/56,3第三类词汇图,UML中有九种图，实践中常用的有六种，包括两种静态图和四种动态图。 （1）Use Case图：Use Case图是一种静态图，主要用于展示Use Case、Actor及其关系。 （2）类图：类图也是一种静态图，主要用于展示类、接口、包及其关系。 （3）序列图（Sequence）：序列图是一种动态图，用于按时序展示对象间的消息传递场景。 （4）协作图（Col
21、laboration）：协作图是一种动态图，其核心内容与序列图相对应，与序列图表示的是相同的内容，但它并不是关注对象之间消息传递的场景，而是强调对象间由于收发消息而关联起来的一种组织结构。序列图和协作图统称交互图（Interaction Diagram）。 （5）状态图（Statechart Diagram）：状态图也是一种动态图，主要用于展示对象在其生命周期中可能经历的状态，以及在这些状态上对事件的响应能力。 （6）活动图（Activity Diagram）：活动图也是一种动态图，用于展示系统从一个活动流转到另一个活动的可能路径与判断条件。 其他三种静态图分别为对象图（Object Diag
22、ram）、构件图（Component Diagram）和部署图（Deployment Diagram）。,2019/1/1,第8章 运行与维护,22/56,10.3.2 UML的语义扩展,作为一种语言，UML除了提供基本词汇，还给出了对自身描述能力的三种扩展机制，即构造型（Stereotype）、标注值（Tagged value）和约束（Constraint）。 本书实例中主要使用“构造型”扩展基本模型词汇的语义，来表达新的概念。在后续的分析与设计活动中，主要用到以下几种。 （1）类的构造型。在系统分析阶段的“提取分析类”活动中将使用实体类、控制类和边界类；在“确定核心元素”活动中将使用“子系
23、统代理”；在“引入外围元素”活动中将使用角色。实质上，接口也是类的一种构造型。 （2）包的构造型。在“选用构架模式”活动中将使用层次；在“确定核心元素”活动中将使用子系统。,2019/1/1,第8章 运行与维护,23/56,10.3.2 UML的语义扩展,（3）Use Case的构造型。“Use Case实现”是Use Case的一种构造型，表述用分析或设计元素实现局部需求的协作内容；“设计机制”，表述解决特定技术问题的协作模式。 上述构造型是UML应用建模中常见的语义扩展形式，在后面章节结合特定应用场合会具体讲到相关的概念和用法。,2019/1/1,第8章 运行与维护,24/56,10.3.
24、3 模型的组织结构,总体上，模型的内容通过包以及包的层层嵌套组织在一起。 模型中的包类似于Windows系统管理磁盘文件的目录结构，如图10.1所示。包将一堆零散的模型内容简单地组织在一起，目的是更易于理解和管理。 模型应该能够反映建模者和使用者的特定视角，它就是建模动机，表现为的模型中的“构架视图”（Archiecture View）。 正如在土木设计师眼里的大楼可能是一堆钢筋混凝土和表面材质，同样一座大楼，在管道设计师眼里可能是一堆管子和接头，在网络工程师眼里可能是一堆网络设备和布线：不同主体对同一客体的认识结果有赖于各自的视角，即看问题的角度。这样能更好地集中注意力，从而有效地解决关键问
25、题。 在模型中，构架视图用包的形式表达。每一种特定的“视角”对应一种类型的构架视图，在Rational Rose建模工具中，用Use Case视图（Use Case View）描述需求模型；用逻辑视图（Logical View）描述设计模型。还有组件视图和部署视图分别用于描述实施模型和系统整体部署。,图10.1 模型的组织结构,2019/1/1,第8章 运行与维护,25/56,10.4 常见图的用法与内容,UML中的主要“词汇”包括：“要素”、“关系”和“图”； “图”UML的主要“词汇”之一，是为了实现建模目的而使用的一种表现手段，有时一种图可用于不同场合以满足特定的要求。图不仅表述了建模的
26、最终结果，同样记录了认知求解的轨迹。 基于“以用为本”的原则，本节概念性地说明几种图，其中着重强调两方面的内容： 第一，图的用法及其在模型中的位置； 第二，包含的关键内容。,2019/1/1,第8章 运行与维护,26/56,10.4.1 Use Case图,2019/1/1,第8章 运行与维护,27/56,1用于描述系统与外部环境交互关系的Use Case图,（1）用法及在模型中的位置 Use Case图主要用于描述系统和外部环境的交互关系，如图10.2所示。概念上，Use Case的集合表达了拟建系统的全部，Actor的集合表达了外部环境，Use Case和Actor之间的连线的集合则表达拟
27、建系统和外部环境的边界。影院售票系统Use Case图如图10.3所示。,图10.2 描述拟建系统与外部环境的Use Case图,图10.3 影院售票系统Use Case图,2019/1/1,第8章 运行与维护,28/56,这种用法的Use Case图通常位于“Use Case模型”的“Use Cases”包内，如图10.4所示。 通常将Actors和Use Case放在不同的包中。,图10.4 Use Case图在模型中的位置,2019/1/1,第8章 运行与维护,29/56,（2）关键内容。 Actor。Actor在图中表现为火柴棍儿。简单讲，Actor代表拟建系统外部和系统进行交互的某类
28、人或系统，可以称为与系统有交互的外部实体。 Use Case。Use Case在图中表现为一个椭圆。Use Case定义了一组相关的由系统执行的动作序列，将有价值的可见结果提供给Actor。 Use Case与外部的交互活动中可能涉及若干个Actor，但是只有一个主动要求得到有价值的可见结果，常被称之为主导（Primary）Actor。主导Actor触发交互活动，它到相应的Use Case的连线是标有箭头的。与该Use Case相连的其他Actor则为被动Actor，相应的连线不标箭头。 通信关联。Actor和Use Case之间的连线称为通信关联，表示Actor和相应的Use Case之间的
29、交互。无论有没有箭头，通信关联都表示介于Actor和相应Use Case之间的双向会话，用箭头仅表示Actor触发Use Case的执行。,2019/1/1,第8章 运行与维护,30/56,2用于描述需求模型与设计模型关系的Use Case图,（1）用法与相对位置 这里使用Use Case图描述功能需求部分的Use Case与相应的设计内容，“Use Case实现”之间的可追溯关联如图10.5所示。概念上，“Use Case实现”是指用拟定的方案实现用户提出的需求（用use case表达的需求），如图10.6所示。,图10.5 用Use Case图表示可追溯的关联,2019/1/1,第8章 运
30、行与维护,31/56,（2）关键内容。 Use Case实现。“Use Case实现”用虚线边框的椭圆表示，其中描述的是设计内容，即如何用设计方案实现Use Case描述的需求。描述这些设计内容使用的图一般包括“序列图”、“协作图”、“活动图”、“类图”等。 实现关系。实现关系是“Use Case实现”到Use Case之间的连线。设计工作完成时，Use Case模型中的每个Use Case在设计模型中至少有一个“Use Case实现”与之对应，“Use Case实现”和“Use Case”之间有可能是多对一的关系。通俗地讲，一种要求可以通过多种办法解决。 通常，在设计模型的“Use Case
31、实现”包中，对应每一个Use Case建立一个以该Use Case命名的包，在此放置对应该Use Case的“Use Case实现”的模型内容，如图10.6所示。,图10.6 描述需求模型与设计模型关系的Use Case图,2019/1/1,第8章 运行与维护,32/56,10.4.2 表述类、接口和子系统之间关系的类图,1用法与相对位置 类图是应用最广泛的一种图，描述拟建系统各个层面的静态结构，主要用于表述类、接口和子系统之间的关系，如图10.7所示。 这种用法的类图可以进一步划分为三种不同的情形，尽管表现形式相似，但是它们通常位于模型的不同位置。,图10.7 描述类、接口和子系统之间关系的
32、类图,2019/1/1,第8章 运行与维护,33/56,（1）第一种情形，用于描述参与某一特定协作的类、接口和子系统之间的关系。这种情形的类图被称为“参与类图”。“Use Case实现”与“构架机制”是两种典型的协作，“参与类图”是隶属于这两种类型的协作内容，如图10.8、图10.9所示。构架机制指的也是一组对象的协作关系，在后面章节会具体讲到。,图10.8 “Use Case实现”中的“参与类图”,图10.9 “构架机制”中的“参与类图”,2019/1/1,第8章 运行与维护,34/56,（2）第二种情形，表述同一包中的类、接口和子系统之间的关系。这种类图通常出现在相应的包中，如图10.10
33、所示。 （3）第三种情形，针对上述两种情形以外的其他目的，表述类、接口和子系统之间的关系。这种情形的类图可以出现在需要的任何位置。,图10.10 表述包内部关系的类图,2019/1/1,第8章 运行与维护,35/56,2关键内容 （1）类。类用于描述一组具有相同属性、操作、关系和语义的对象。如图10.11所示，上面是类的名称，通常其首字母大写，中间是属性，下面是类的操作。,图10.11 类的UML表述,2019/1/1,第8章 运行与维护,36/56,（2）接口（Interface）。接口用来说明一个类或子系统应该提供的服务。在形式上接口是一组操作的集合。如图10.12所示，是接口的两种UML
34、表述形式：第一种是简略的表述，只有一个圆圈和接口的名称，没有显示接口中定义的操作；第二种是详细的表述，在形式上，接口与类的性质相似。 （3）子系统（Subsystem）。子系统是一组元素的集合。子系统所具有的行为特征在概念上与类相似。用包的构造型表述子系统，如图10.13所示。,图10.12 接口的两种UML表述形式,图10.13 子系统的UML表述形式,2019/1/1,第8章 运行与维护,37/56,（4）关联关系（Association）。关联关系的基本含义是两个类的实例之间存在稳定的“连接”，可以用于传递消息。当一个类的对象作为另一个类的对象的变量成员时，两个类之间就有关联关系存在。图
35、10.14给出一个通俗的实例。 关联关系的多重性（Multiplicity）表示A的多少个实例对应B的一个实例。图10.15给出一个通俗实例，一只麻雀两条腿，一只螃蟹八条腿。 在对多重性没有明确认识的时候，可暂不做标注。当然，如果多重性非常明显，也可省略标注。在分析和设计过程中，多重性主要用来表述业务规则，常见的标识方式有“1”、“*”、“01”、“0*”、“1*”等。,图10.14 关联关系的基本含义,图10.15 关联关系中的多重性表示,2019/1/1,第8章 运行与维护,38/56,关联关系的访问方向表示某一方的实例能够“访问”另一方的实例。至少存在一个可用的访问方向，如果仅存在一个可
36、用的访问方向，那么关联关系是单向的，用箭头表述这一概念，两端都没有箭头的连线表述关联关系是双向的。如图10.16所示，在一个小公司里，公司的总裁认识所有的职员，当然每个职员都认识公司的总裁；在大公司里则有所不同，所有的职员都认识公司的总裁，但是总裁通常只认识核心职员，并不认识那些外围职员，因而大公司总裁和大公司外围职员之间的关联关系是单方向的。,图10.16 关联关系的访问方向,2019/1/1,第8章 运行与维护,39/56,关联关系中的角色（Role），表示该类在对方眼里所扮演的角色或用途，或者说对方是如何看待自己的，即类A的实例对类B的实例的具体含义。可以结合图10.17中的实例加以理解
37、：一个领域专家对一个行业协会而言是一个成员，一个行业协会对一个领域专家而言是一个信息来源；依次类推。,图10.17 关联关系中的角色示例,2019/1/1,第8章 运行与维护,40/56,聚合关联（Aggregation）是关联关系的一种强化形式，表示两个类的实例之间有“整体”与“部分”的关系：处于空心菱形符号一端的类是“整体”，另一端的类是“部分”。 如图10.18所示，连队和士兵是整体和部分的关系。如果“整体”的多重性大于1，表示“部分”的实例可以被多个“整体”的实例“共享”。例如，球队和球员就可能是这种关系：一个球员既可以是俱乐部球队的球员，同时也可以是国家队的球员。聚合关联并不隐含“整
38、体”的实例消失将导致“部分”的实例也消失。例如，球队解散了，球员还在。,图10.18 关联关系中的聚合示例,2019/1/1,第8章 运行与维护,41/56,（5）依赖关系（Dependency）。依赖关系表达“使用”的语义，用带箭头的虚线表示， 如图10.19所示。相对于关联关系而言，依赖关系是一种比较弱的关联，“被依赖者”类的变化有可能影响“依赖者”。,图10.19 依赖关系的示例,2019/1/1,第8章 运行与维护,42/56,（6）泛化关系（Generalization）。类B（相对特殊）到类A（相对一般）的泛化关系表示“类B是类A的一种”。通常称类B为子类，称类A为父类。 如图10
39、.20所示，一名足球运动员同时也是一位大球运动员、球类运动员和运动员（越来越笼统）。 在一般意义上，泛化关系和继承（Inheritance）是可以互换的概念。如果要加以区别，那么泛化关系是一种关系的名称，而继承则是反映和实现泛化关系的一种机制。,图10.20 泛化关系的示例,2019/1/1,第8章 运行与维护,43/56,（7）实现关系（Realization）。实现关系中的一方（甲方）作为要求被提出，另一方（乙方）具本履行要求中声明的任务。类图中出现的实现关系大多表述子系统或类实现接口。如图10.21所示，实现关系的表述方式为虚线加上一个空心的箭头，雇用“保姆”或将孩子送到“幼儿园”都可以
40、完成接口“照顾学龄前儿童”中规定的任务。 如图10.22所示，因为“照顾学龄前儿童”是一个接口，所以图10.21还可以表示成图10.22所示的简略形式。 如图10.23所示，以日常生活为例，将关联、依赖、泛化和实现四种关系反映在同一张类图中，希望有助于理解它们的语义区别。,图10.21 实现关系的表示,图10.22 实现关系的（简略）示例,图10.23 日常生活四种关系的举例,2019/1/1,第8章 运行与维护,44/56,10.4.3 序列图,2019/1/1,第8章 运行与维护,45/56,1用序列图描述局部分析与设计的场景,（1）用法与相对位置。 序列图用于描述动态行为，直观易懂，是最
41、常用的一种交互图，如图10.24所示。描述局部分析和设计场景的序列图位于“Use Case实现”的协作中，如图10.25所示。通常，Use Case中的每一个事件序列对应“Use Case实现”中的一张序列图。,图10.24 序列图示例,图10.25 序列图在模型中的位置,2019/1/1,第8章 运行与维护,46/56,（2）关键内容。 对象。概念上，对象是一个具有明确边界的、封装着状态与行为的实体。状态表现为属性的一组取值以及同其他对象的“连接”状况，行为是指对象自身的行动以及对外界请求的响应。 在序列图中，对象的符号有三种表示方式：第一种，仅仅给出所属类的名字，不指明特定的对象（例如，A
42、uthor表示某个作者）；第二种，仅仅给出对象的名字，不指出所属类（例如，amos:表示一个名称为amos的对象）；第三种，同时给出对象和类的名字（例如，amos:Author表示一个叫做amos的作者）。同一序列图中出现的某一类的多个不同实例时，须指明每个对象的具体名称。 序列图中，对象符号正下方是一条垂直的虚线，称对象生存线。沿对象生存线上展开的细长矩形为控制焦点，表述来自其他对象的消息被回应的时间跨度。,2019/1/1,第8章 运行与维护,47/56, 消息。消息是对象间通信的具体内容，消息表述为一条对象生存线到另一条对象生存线的带箭头的水平实线，箭头指向接受消息的对象，见图10.24
43、。如果消息被对象发至其自身，称为返身消息。消息由序号、名称和参数组成。序号可以是连续编号或层次化编号，名称是必须的内容，参数按需而定。,2019/1/1,第8章 运行与维护,48/56,2用序列图描述构架机制的典型场景,序列图还用于描述“构架机制”的典型应用场景，在模型中的相对位置如图10.26所示，这种序列图中的关键内容与前一种用法没有区别。,图10.26 描述“构架机制”场景的序列图的位置,2019/1/1,第8章 运行与维护,49/56,10.4.4 协作图用于描述局部分析与设计的场景,协作图是另一种形式的交互图，如图10.27所示。协作图的本质内容（“对象”和“消息”）与相关的序列图存
44、在明显的对应关系，图10.27和图10.24是等价的。在协作图中，传递消息的对象之间存在一条连线，表示消息传递的通道。 可以通过序列图直接生成相应的协作图。在Rose中的操作步骤为：首先选中序列图，然后在主菜单中选择“Browse | Create Collaboration Diagram”，这样就可以自动生成对应于该序列图的协作图了。,图10.27 用序列图生成的协作图,2019/1/1,第8章 运行与维护,50/56,协作图主要用于描述局部分析和设计中的特定场景，其特点是强调对象间的结构关系。这种用法的协作图位于“Use Case实现”的协作中，其相对位置如图10.28所示。通常，只关注
45、那些对应重要事件序列的协作图，即不是所有的序列图都有必要给出相应的协作图。,图10.28 协作图在模型中的相对位置,2019/1/1,第8章 运行与维护,51/56,10.4.5 状态图,1用法与相对位置 状态图用于展示某对象在其生命周期中可能处于的几种状态、在这些状态中的行为、发生状态转换的事件及其相关的动作。一个类所处的全部可能状态及相关行为构成了这个类的状态机。 图10.29给出了一个通俗的状态图的例子，该状态图描述了人一生中的各类状态及转变。人从出生到死亡的生命周期内，要么处于清醒状态，要么处于睡眠状态；静躺超过15分钟从清醒状态转入睡眠状态；闹钟一响，人会睁开眼睛醒来；进入睡眠状态必
46、然暂停有意识的思维活动，在清醒状态时可能吃饭、工作或者锻炼身体。,图10.29 状态图示例,2019/1/1,第8章 运行与维护,52/56,描述类状态特征的状态图隶属于该类的状态机，在模型中的相对位置如图10.30所示。一个状态机可以有多张状态图来描述。,图10.30 状态图在模型中的位置,2019/1/1,第8章 运行与维护,53/56,2关键内容 （1）状态（State）。状态是一个对象在生存周期内处于的某一种情形，限定了该对象对事件的响应能力。状态在图中表述为没有棱角的矩形。有两种比较特殊的状态：初始状态，用实心圆点表示；结束状态，用实心圆点加一个圆圈表示。一个状态机只能有一个初始状态
47、，但可能有多种结束状态。 对象在某个状态中有两种类型的行为：第一，动作（Action），动作是与状态转变相关的行为，是不可能再分的一个原子化行为，不可能被打断；第二，活动（Activity），活动是与某一状态相关的非原子化行为，有可能被打断。 （2）转移（Transition）。转移是指在某种激励条件下从一个状态转移到另一个状态的过程。转移通常是满足特定条件时对某种事件（Event）的响应。,2019/1/1,第8章 运行与维护,54/56,10.4.6 活动图,1用法与相对位置 活动图就是通常所说的流程图，用于描述Use Case的事件流结构。图10.31给出一个活动图的示例，说明“获得软件
48、需求”的流程。 本书中，活动图主要用于描述Use Case中的事件流结构。这种用法的活动图归属于某一特定期Use Case，在模型中的相对位置如图10.32所示。,图10.31 活动图示例,图10.32 描述Use Case事件流结构的 活动图在模型中的相对位置,2019/1/1,第8章 运行与维护,55/56,2关键内容 （1）活动（Activity）。活动在图中表现为一个标有名称的鼓形图标。 （2）判断（Decision）。根据特定条件判断活动的转移路径，在图中表现为菱形图标。,2019/1/1,第8章 运行与维护,56/56,本 章 小 结,模型不仅是一种表述工具，更是一种思维与交流沟通
49、的工具。为了便于表述问题，我们把复杂的现实系统简化为模型，以理解系统的本质特征。为了使技术人员能够理解用户的意图或需求，我们使用模型来表述我们理解的系统内容。为了实现拟建系统，我们通过模型演化，不断丰富模型的内容，把从用户专业领域提取出来的模型经过演化，最终得到可以适合用计算机实现的模型。这些用途正是建模的价值所在。 手工维护一个复杂的信息系统模型几乎是不可能的。UML是在综合了几种面向对象方法的基础上，推出的一种统一建模语言，它是我们进行面向对象建模的有力辅助工具。 UML作为一种建模语言，强调的就是它的表述与沟通能力。它有一套可视化的符号、一套表述机制。为了增强其表述能力，UML还提供了一种语义扩展机制，即构造型。UML常用的六种图包括Use Case图、序列图、协作图、状态图、活动图和类图。 Rational Rose是目前常用的UML建模工具。Rose建模中，包括用例视图、逻辑视图、组件视图和部署视图。在每种视图中，使用“包”作为管理手段，将模型的相应内容组织在不同的视图中。在“包”中建立相应的图、表及文字描述。 学习UML语言，不在于理解其符号的含义和语言机制，更重要的是理解面向对象的思想。把面向对象的思想融入到建模过程中。运用UML符号与机制体现出面向对象的建模思想与分析和设计的结果。,
