计算机管理信息系统——10章_UML.ppt

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