南邮普本《UML系统分析与设计》期末考试复习(2018版v2)

UML系统分析与设计班级A：B150411-12课堂授课：第1-9、11-15周周二第8-9节，教4－204第2、4、8、10、12、14周四第6-7节，教4－204课程实验：第7、9、11、13周周四第8-9节

软信实验室（计算机学科楼）课程考试考核方式和成绩评定平时成绩：共占总评的30%。根据出勤和上课情况、作业、实验等方面综合打分。期末考试：占总评的70%。笔试、闭卷、中文。课程总成绩=平时成绩+期末考试成绩。考试安排待定请关注教务处通知

考试:题型与分值客观题：选择题（10小题，每题2分）：20分填空题（5小题，每题2分）：10分判断题（5小题，每题2分）：10分名词解释题（2小题，每题5分）：10分简答题（3小题，每题6分）：18分解答题（2小题，每题10分）：20分主观题综合题：12分考试:范围选择题、填空题、判断题见精简PPT名词解释题（课本附录A等）构件图关联类构造型限定符组合状态重数考试:范围简答题见作业题型解答题见作业题型综合题类似课程实验UML系统分析与设计（精简）班级A：B150411-12等第1讲:统一建模语言概述1.1软件建模为什么软件建模？模型可以促进项目有关人员对系统的理解和交流模型有助于挑选出代价较小的解决方案模型可以缩短系统的开发周期怎样软件建模？1.抽象出系统的不同视图2.用精确的表示法来建立模型3.在模型转换为实现的过程中逐渐添加进相关细节成功建模的三要素表示法工具过程第1讲:统一建模语言概述1.1软件建模分析与设计模型描述现实世界应用的结构（分析阶段)描述被提议软件系统的结构（设计阶段）面向对象方法在分析与设计阶段使用同样的标记法结构化方法使用不同的分析与设计标记法应用系统UML主要构成视图(views)一个系统应从不同的角度进行描述,从一个角度观察到的系统称为一个视图（view）。视图由多个图（Diagrams）构成，不是一个图表（Graph）,而是在某一个抽象层上，对系统的抽象表示。要为系统建立一个完整的模型图，需定义一定数量的视图，每个视图表示系统的一个特殊的方面。视图把建模语言和系统开发时选择的方法或过程连接起来。第1讲:统一建模语言概述1.3

UML概念模型UML主要构成视图(views)第1讲:统一建模语言概述1.3

UML概念模型设计视图过程视图实现视图部署视图用例视图Use

caseView描述系统的外部特性、系统功能等。UML主要构成视图(views)第1讲:统一建模语言概述1.3

UML概念模型设计视图过程视图实现视图部署视图用例视图DesignView

描述系统设计特征，包括结构模型视图和行为模型视图，前者描述系统的静态结构(类图、对象图)，后者描述系统的动态行为(交互图、状态图、活动图)。UML主要构成视图(views)第1讲:统一建模语言概述1.3

UML概念模型设计视图过程视图实现视图部署视图用例视图ProcessView表示系统内部的控制机制。常用类图描述过程结构，用交互图描述过程行为。UML主要构成视图(views)第1讲:统一建模语言概述1.3

UML概念模型设计视图过程视图实现视图部署视图用例视图DeploymentView配置视图描述系统的物理配置特征。用配置图表示。UML主要构成视图(views)第1讲:统一建模语言概述1.3

UML概念模型设计视图过程视图实现视图部署视图用例视图ImplementationView表示系统的实现特征，常用构件图表示。UML主要构成模型元素(Modelelements)代表面向对象中的类，对象，关系和消息等概念构成图的最基本的常用的元素一个模型元素可以用于多个不同的图中第1讲:统一建模语言概述1.3

UML概念模型第2讲:软件开发过程2.1面向对象的软件开发面向对象的软件分析获取用户基本需求标识类和对象定义类的结构和层次表示类(对象)间的关系为对象行为建模第2讲:软件开发过程2.2

Rational统一过程RUP（RationalUnifiedProcess）二维开发模型在RUP中，软件开发生命周期根据时间和RUP的核心工作流划分为二维空间。第2讲:软件开发过程2.2

Rational统一过程RUP（RationalUnifiedProcess）二维开发模型在RUP中，工作流横轴表示项目的时间维，是过程展开的生命周期特征，体现开发过程的动态结构。第2讲:软件开发过程2.2

Rational统一过程RUP（RationalUnifiedProcess）9个核心工作流，分为6个核心过程工作流（CoreProcessWorkflows）和3个核心支持工作流（CoreSupportingWorkflows）。第2讲:软件开发过程2.2

Rational统一过程RUP（RationalUnifiedProcess）四个阶段：软件产品生命周期被分成单独的开发周期：初始（先启）、细化（精化）、构造、发布（产品化）第2讲:软件开发过程2.2

Rational统一过程RUP（RationalUnifiedProcess）四个阶段初始（先启）：定义整个项目的范围细化（精化）：制定项目计划、描述功能、建立架构框架构造（构建）：构造软件产品发布（产品化）：将软件产品移交到最终用户手中先启精化构建产品化时间第2讲:软件开发过程2.3

敏捷开发敏捷宣言人和交互重于过程和工具可以工作的软件重于求全责备的文档客户合作重于合同谈判随时应对变化重于循规蹈矩。团队方法论工具第3讲:用例图3.0用例建模用例图

用例图是从用户的角度来描述系统所实现的功能，它标明了用例的参与者，同时确定了参与者和用例之间的关联关系。在软件的需求分析阶段，往往采用用例图来建立系统需求模型。第3讲:用例图3.0用例建模用例图三种主要建模元素用例（UseCase）参与者（Actor）依赖、类属和关联关系用例图可选元素注释和约束包系统边界框第3讲:用例图3.0用例建模用例图元素之间的关系（relationship）关联（association）包含（include）扩展（extend）泛化（generalization）第3讲:用例图3.1参与者具有某一种特定功能的角色，参与者是虚拟的概念，它可以是人，也可以是外部系统或设备等。参与用例的执行过程通过向系统输入或请求系统输入某些事件来触发系统的执行由参与用例时所担当的角色来表示每个参与者可以参与一个或多个用例参与者不是系统的一部分，它们处于系统的外部。

第3讲:用例图3.1参与者参与者间的关系在用例图中，使用泛化关系来描述多个参与者之间的公共行为。参与者间的泛化关系第3讲:用例图3.2用例对系统、子系统或类与参与者交互动作序列的说明用例的执行给参与者带来可见的价值是对一组场景（脚本，scenarios)共同行为特征的抽象场景是用例的一次完整、具体的执行过程；是在系统中按照某个顺序执行一系列相关动作，实现某种功能的操作集合多个用例组成系统，参与者以某种场景与系统交互，请求系统执行用例，以获得可见的价值用例与场景的关系，如同类与对象的关系用例表示符号：第3讲:用例图3.2用例：事件流事件流场景中系统行为的一个特定动作序列描述参与者执行用例时，发生的所有可能交互脚本与用例的关系就象实例与类的关系，脚本是用例的一个实例。对一个用例的完整说明，包括：基本事件流(basiccourseofevents)：描述交互时的正常场景扩展事件流，即可选的或例外的事件流(alternativeandexceptionalcoursesofevents)：正常场景之外的情况第3讲:用例图3.2用例：关系1.参与者与用例之间的关联（association）关系参与者到用例的单向箭头只表示谁启动用例，不考虑信息的双向流动每个用例都由角色启动，除了包含和扩展用例第3讲:用例图3.2用例：关系2.用例之间的泛化（generalization）关系原因：如果系统中的一个或几个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。图示：用例中的泛化关系用带空心箭头的实线来表示，箭头的方向指向父用例说明：子用例表示父用例的特殊形式，子用例从父用例继承行为和属性，还可以添加自己的行为，或覆盖、改变所继承的行为。第3讲:用例图3.2用例：关系3.用例之间的包含（include）关系原因：（1）如果两个以上用例有大量一致功能，可将这个功能分解到另一个用例中，其他用例可和这个用例建立包含关系。（2）一个用例功能太多，可用包含关系建模两个小用例。第3讲:用例图3.2用例：关系3.用例之间的包含（include）关系包含关系把几个用例的公共步骤分离成一个单独的被包含用例。通常，把包含用例称为客户用例，被包含用例称作提供者用例。第3讲:用例图3.2用例：关系3.用例之间的包含（include）关系图示：带构造型《include》的虚线箭头由基本用例指向被包含用例两个以上的用例有共同功能，可分解到单独用例，形成包含依赖执行基本用例时，每次都必须调用被包含用例，被包含用例也可单独执行。注：一个用例功能过多需分解成小用例，构成包含依赖。第3讲:用例图3.2用例：关系4.用例之间的扩展（extend）关系

扩展关系是把新行为插入到已有用例的方法基础用例（被扩展用例）提供了一组扩展点，在这些新的扩展点中可以添加新的行为扩展用例提供了一组插入片段，这些片段能够被插入到基础用例的扩展点上第3讲:用例图3.2用例：关系4.用例之间的扩展（extend）关系基础用例（被扩展用例）不必知道扩展用例的任何细节，它仅为其提供扩展点。基础用例即使没有扩展用例也是完整的，这点与包含关系有所不同。第3讲:用例图3.3用例图系统功能模型图，显示系统与外部参与者交互作用图中呈现参与者、用例，以及它们之间的关系对系统、子系统或类的行为进行可视化建模描述用户的功能需求，强调谁在使用系统、系统可以完成哪些功能使用户能够理解如何使用图中元素使开发者能够实现图中元素注用例分析技术是一种公认有效的用户需求获取、分析和描述技术第4讲:类图和对象图

4.1

类和对象类（Class）的UML图标：属性属性（Attribute）是类的命名的性质，属性在类图标的属性分隔框中用文字串说明。属性有在类中唯一的属性名或标识符。冒号“:”后跟属性值的数据类型。属性名后跟的方括号中的内容是可选项目。多重性（Multiplicity）用多值表达式表示，其值是该类的每个实例的属性值的个数。多值表达式的格式为：integer，integer，…或低界..高界属性可视性属性名[多重性]：类型=初始值第4讲:类图和对象图

4.1

类和对象类（Class）的UML图标：属性—可视性可视性（Visibility）用以下可视性标记表示：+（公共），#（保护），–（私用）可视性也可以用以下关键字表示：public（公共）、protected（保护）、private（私用）若可视性标记为“+”或“public”，则为公共属性，可以被外部对象访问。若可视性标记为“#”或“protected”，则为保护属性，可以被本类或子类的对象访问。若可视性标记为“–”或“private”，则为私用属性，不可以被外部对象访问，只能为本类的对象使用。可视性可以缺省，表示该属性不可视。第4讲:类图和对象图

4.1

类和对象类的UML图标：操作（类的行为特征或动态特征）一个类可以有多个操作，也可以没有一个操作；没有一个操作的类常用于表达接口或数据表。操作用文字串说明，在类中有唯一的操作名或标识符。参数列表是可选项目，即一个操作可以有参数，也可以没有参数，由逗号分隔的操作的形式参数组成，其格式为：参数名：类型=缺省值，…返回列表由逗号分隔的操作的返回值类型表达式组成，其格式为：返回类型或返回名字=类型，…操作可视性操作名（参数列表）：返回列表（性质）第4讲:类图和对象图

4.1

类和对象类的UML图标：总结类（Class）具有相似结构、行为和关系的一组对象的描述组成名称：类的唯一标识属性：描述类的静态特征操作：说明类所提供的服务职责：定义类的责任和义务约束：指明类满足的规则符号第4讲:类图和对象图

4.1

类和对象类的UML图标：总结属性[可见性]属性名[:类型][‘[’多重性[次序]‘]’][=初始值][{特性}]可见性：可访问性多重性：属性值个数格式次序：属性值顺序特性：属性约束操作[可见性]操作名[(参数列表)][:返回类型][{特性}]第4讲:类图和对象图

4.1

类和对象类的UML图标：接口类、抽象类、模板类接口：一组操作的集合，只有操作的声明而没有实现标准图形、变体图形，没有属性不要求实现类和接口类概念本质上是一致的，仅是实现了接口类定义者的契约抽象类：不能被实例化的类，一般至少包含一个抽象操作类名、抽象操作名均为斜体模版类：一种参数化的类，在编译时把模版参数绑定到不同的数据类型，从而产生不同的类；模版化的类具有相同行为，但数据类型不同。(标准图形)(变体图形)接口抽象类模版参数模版类第4讲:类图和对象图

4.1

类和对象类的UML图标：分析类边界类（boundary）边界类处理系统环境与系统内部之间的通信，边界类为用户或另一个系统（即参与者）提供了接口，例如窗体、对话框、报表、与外部设备或系统交互的类等边界类可以通过用例确定，因为参与者必须通过边界类参与用例边界类的UML符号表示：第4讲:类图和对象图

4.1

类和对象类的UML图标：分析类实体类（entity）实体类是模拟必须被存储的信息和其关联行为的类。保存永久信息，最终可能映射数据库中的表和字段实体类的UML符号表示：第4讲:类图和对象图

4.1

类和对象类的UML图标：分析类控制类（control）控制类是用来为特定于一个或多个用例的控制行为建模的类。一个用例有一个控制类，协调其他类工作和控制总体逻辑流程例如：命令处理程序第4讲:类图和对象图

4.1

类和对象对象（Object）的UML图标对象是唯一的，可以标识的；每个对象都是不同的，即使它具有相同的属性。对象的UML图标用实线矩形框表示，含有若干分隔框。对象名分隔框中包含一个对象的名字，对象名的格式为：

对象名:类名对象名分隔框中的状态列表，表示该对象的并发状态。对象的属性分隔框含有该对象的属性值。对象图标不含有操作框。第4讲:类图和对象图

4.2关系类之间的关系关联（association）泛化（generalization）实现（realization）依赖（dependence）聚合组合第4讲:类图和对象图

4.2关系关联（association）关联用一条把类连接在一起的实线表示，一个关联至少有两个关联端，每个关联端连接到一个类，关联端是有序的。关联线旁可以标出关联的名字，线旁的小实心三角箭头表示关联的方向，从源类指向目标类，箭头起关联的导航作用。

第4讲:类图和对象图

4.2关系关联（association）关联可以是单向的或双向的，如果该关联是双向的，就不必标出方向箭头。在关联端可有多重性标记，规定该类中有多少个对象参与该关联。在关联的类图标旁可以标出类的角色名（Role），角色表示被关联的类参与关联的特定的行为。

第4讲:类图和对象图

4.2关系关联（association）带有限定符的关联称为限定关联（QualifiedAssociation）。限定符的值确定如何划分和标识该关联的目标类的对象。源类的一个带有限定符值的对象，唯一地选择目标类的一个划分。目标类的每一个对象只能是某一个划分的成员。第4讲:类图和对象图

4.2关系关联（association）关联本身也有特性，通过关联类（AssociationClass）可以进一步描述关联的属性、操作，以及其他信息。第4讲:类图和对象图

4.2关系关联（association）总结双向关联单向关联聚合关联弱的整体与部分关系组合关联强的整体与部分关系关联类自反关联限定关联派生关联第4讲:类图和对象图

4.2关系关联（association）：聚合（Aggregation）表示事物的部分/整体关系的较弱的情况。聚合也称为“has-a”联系。在关联线端加一个小空心菱形表示聚合，菱形连接代表整体事物的类，称之为聚合类，另一个关联端连接代表部分事物的类。例：圆和多边形是图形格式的两个聚合类第4讲:类图和对象图

4.2关系关联（association）：组合（Composition）表示事物的部分/整体关系的较强的情况。组合也称为“contains-a”联系。在关联线端加一个小实心菱形表示组合，菱形连接代表整体事物的类，称之为组合类，另一个关联端连接代表部分事物的类。例：圆由点组成，“圆”是组合类，“点”是成分类；多边形也是由点组成的，是一个组合类。第4讲:类图和对象图

4.2关系关联（association）：关联类（Associationclass）既是关联又是类，有属于关联类的属性两个类之间具有多对多的关系，并且有些属性不属于关联两端任何一个类第4讲:类图和对象图

4.2关系泛化（generalization）一般元素与特殊元素的关系目的子类继承、共享父类的属性和操作可以使子类的实例用于任何父类被 声明使用的地方，实现多态继承父类的公共(public)和保 护（protected）特性被 子类继承父类派生出的子类表面相同，行为不同第4讲:类图和对象图

4.2关系泛化（generalization）：多态每个子类的实现方法各不相 同，但外界的调用是一样的例如：

Shape*myShape; Line*myLine myLine=newLine; myShape=myLine；

myShape.draw();第4讲:类图和对象图

4.2关系实现（realization）一个元素完成另外一个元素的操作功能例如：接口类及其实现接口没有属性，方法只声明不实现，由实现类具体定义方法的实现部分第4讲:类图和对象图

4.2关系对象之间的关系链接（link）

意味着导航，代表一个对象对另一对象的引用第4讲:类图和对象图

4.3类图最广泛的一种UML模型，描述系统的结构表述类、协作、接口及其关系类图元素类、接口、协作、关系、注释、约束等关系连接类、协作与接口注释对类和接口进行说明约束对类和接口进行约束第4讲:类图和对象图

4.4对象图表示对象和对象之间链接关系的图,类图的实例表示对象和对象之间链接关系的图表达了系统数据在给定时刻的一个“快照”，代表系统的一个局部状态全部对象的链接图，表达了系统的对象模型，对象模型是软件开发OO方法学的核心。第5讲:活动图5.1活动图的基本要素活动（Activity）：指示要完成某项工作的动作或表示工作流的步骤现实世界中的一项工作，如写文章、修机器等（或者）执行某个软件的例行程序，如运行类中的操作等。活动图的基本要素状态转移、动作流分支分叉、汇合泳道对象流...第5讲:活动图5.1活动图的基本要素：状态（State）状态（State）：在对象的生命周期中满足某些条件、执行某些活动或等待某些事件时的一个条件或状况使用带圆端的方框表示动作状态活动图中最小单位的构造块，表示原子动作三个特性：原子性、不可中断性、瞬时性活动状态可被分解成其他子活动或动作状态，能够被中断，占有有限的时间可理解为一个组合，其控制流由其他活动状态或动作状态组成。第5讲:活动图5.1活动图的基本要素：状态（State）状态（State）：在对象的生命周期中满足某些条件、执行某些活动或等待某些事件时的一个条件或状况使用带圆端的方框表示特殊状态起始状态(startstate)：表示一个工作流程的开始，用实心圆点来表示。终止状态(endstate)：表示一个活动图的最后和终结状态，用实心圆点外加一个小圆圈来表示第5讲:活动图5.1活动图的基本要素：动作状态（ActionState）动作状态（ActionState）：用于为实体的原子动作或算法的执行步骤建立模型可以有入转移，入转移可以是动作流或对象流。至少有一条出转移，它不是基于外部事件的，而是隐含表示内部动作的完成。不能有入口动作和出口动作，也不能有内部转移。必须指定在单条泳道内，表明负责该泳道的对象运行该动作状态中的动作。在一张活动图中，一个动作状态允许多处出现，实际上这表示同一个动作的不同状态。动作状态必须延迟所有的无关事件。所谓无关事件是指不出现在动作状态的出转移中的事件。第5讲:活动图5.1活动图的基本要素：转移（transition）转移（transition）：两个状态间的一种关系表示对象将在当前状态中执行动作，并在某个特定事件发生或某个特定的条件满足时进入后继状态。用一条简单的实箭线表示一个转移：第5讲:活动图5.1活动图的基本要素：动作流（ActionFlow）动作流（ActionFlow）是一个实体的不同动作状态之间的转移，说明状态之间的控制流。一个无条件的动作流代表无触发转移或完成转移，对它不附加监护条件，在一个动作状态的动作完成后自动发生动作状态的转移，激活下一个动作状态。在表示一个有条件的动作流的实箭线上需要标出“[监护条件]/动作”（动作部分可以缺省）。方括号中的保安条件是一个布尔表达式，当其值为真时，执行斜杠“/”后面的动作，发生动作状态的转移，进入下一个动作状态。第5讲:活动图5.1活动图的基本要素：分支（Branch）分支（Branch）：描述基于某个条件的可选择路径一个分支可以有一个进入转移和两个或多个输出转移。在每条输出转移上都有监护条件表达式保护，当且仅当监护条件表达式为真时，该输出路径才有效。在所有输出转移中，其监护条件不能重叠，而且它们应该覆盖所有的可能性。分支在图形表示上用菱形表示动作流可以有多条件的分支决策情况，分支决策可以是链式的和非链式的第5讲:活动图5.1活动图的基本要素：分叉（fork）和汇合（join）分叉（fork）和汇合（join）在UML中使用分叉和汇合表示并行发生的事件流分叉表示把一个单独的控制流分成两个或多个并发的控制流。一个分叉可以有一个进入转移和两个或多个输出转移，每一个转移表示一个独立的控制流。汇合表示两个或多个并发控制流的同步发生，一个汇合可以有两个或多个进入转移和一个输出转移。分叉和汇合应该是平衡的分叉和汇合在图形上都使用同步条来表示，同步条通常用一条粗的水平线（同步杆，Synchronizationbar）表示：第5讲:活动图5.1活动图的基本要素：分叉（fork）和汇合（join）分叉（fork）和汇合（join）“分叉”同步杆有一条入转移箭线和两条或多条出转移箭线，每一条表示一个独立的控制流。“分叉”表示当入转移被触发时，所有与出转移对应的活动就并行进行。“汇合”同步杆有两条或多条入转移箭线和一条出转移箭线，每一条表示一个独立的控制流。在“汇合”之前的所有与入转移对应的活动一直是并行进行的。在“汇合”点这些并发的控制流实现同步，即只有当所有的入转移全部完成其活动后才发生一个出转移。第5讲:活动图5.1活动图的基本要素：泳道（swimlane）泳道（swimlane）将一个活动图中的活动状态进行分组，每一组表示一个特定的类、人或部门，他们负责完成组内的活动。描述每个活动是由哪个对象负责完成每个组被称为一个泳道，用一条垂直实线与邻居分开每个活动都明确属于一个泳道，不可以跨越泳道，而转移则可以跨越泳道第5讲:活动图5.1活动图的基本要素：对象流（objectstream）对象流（objectstream）包括依赖关系和对象的应用被称为对象流。对象流是动作和对象间的关联对象流可用于对下列关系建模：动作状态对对象的使用动作状态对对象的影响在UML中，使用矩形表示对象，对象和动作之间使用带箭头的虚线连接，带箭头的虚线表示对象流第6讲:交互图（InteractionDiagram）6.1

顺序图描述了对象之间传送消息的时间顺序，用来表示用例中的行为顺序。当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。序列图包含了4个标记符号，分别是：对象类角色（ClassRole）生命线（Lifeline）消息（Message）激活（Activation）第6讲:交互图（InteractionDiagram）6.1

顺序图描述了对象之间传送消息的时间顺序，用来表示用例中的行为顺序。顺序图包含了4个标记符号，分别是：对象类角色（ClassRole）：矩形，符号与对象图相同生命线（Lifeline）：虚线，表示对象生存期消息（Message）：箭头线，表示对象间消息通信激活（Activation）：矩形条，表示对象正在执行一些活动第6讲:交互图（InteractionDiagram）6.1

顺序图激活顺序图可以描述对象的激活（Activation）和去激活（Deactivation）。激活表示该对象被占用以完成某个任务去激活指的是对象处于空闲状态，在等待消息。为了表示对象是激活的，可以将对象的生命线拓宽成为矩形。第6讲:交互图（InteractionDiagram）6.2

协作图（UML2中的通信图）描述对象之间的消息交互，强调对象在交互中承担角色语义上与顺序图是完全等价的，可以相互转换协作图的组成元素对象类角色消息链接第6讲:交互图（InteractionDiagram）6.2

协作图（UML2中的通信图）作用描述、强调交互发生时，每个对象承担的职责显示对象相互协作时充当的角色强调交互的时间和序列，选择顺序图建模强调交互的上下文相关，选择协作图建模阐明对象之间交互的角色，以实现特定用例或用例中特定部分的行为，便于确定类的职责和接口第7讲:状态机图7.1状态机状态机被定义为一个行为状态机表示一个模型元素在其生命期间的情况：从该模型元素的开始状态起，响应事件，执行某些动作，引起转移到新状态，又在新状态下响应事件，执行动作，引起转移到另一个状态，如此继续，直到终结状态。UNIX进程的状态和转移状态机概念编译技术:用有限状态机描述词法分析过程操作系统:进程调度、缓冲区调度等采用状态机描述UML:对系统的动态特征建模第7讲:状态机图7.1状态机状态机组成状态（State）：一个模型元素在生存期的一种状况，如满足某些条件，进行某些活动，或等待某些事件的出现等。一个状态在一个有限的时间段内存在。转移（Transition）：一个模型元素的不同状态之间的联系。在事件的触发下，一个状态可以转移到另一个状态。事件（Event）：一个有意义的出现（Occurrence）的说明。该出现在某个时间和空间点发生，并且立即触发一个状态的转移。活动（Activity）：在状态机中进行的一个非原子的执行，它由一系列的动作组成。动作（Action）：一个可执行的原子计算，它导致状态的变更或返回一个值。第7讲:状态机图7.2状态机图状态机图的图形元素

1．状态状态用一个带圆角的矩形框表示，框内标有状态的名称和其他一些信息状态图标可以进一步划分成3个分隔框：名称框、内部转移框和嵌套状态机图框在名称框中标出状态的名称在内部转移框中规定动作或活动简单状态：嵌套状态机图分隔框可缺省组合状态（CompositeState）：包含有子状态，在嵌套状态机图的分隔框内放置被嵌套的子状态机图。状态的图形表示

第7讲:状态机图7.2状态机图状态机图的图形元素

2．转移转移用实箭线表示，箭尾连接出发状态，即源状态，箭头连接到达状态，即目标状态。在箭线上可以标示与该转移有关的选项：事件、监护条件（GuardCondition）和动作。当处于源状态的对象接收到一个事件，并且监护条件得到满足（如果有监护条件的话）时，则执行相应的动作，并从源状态转移到目标状态。如果在转移箭线上不标示触发转移的事件时，则从源状态转移到目标状态是自动进行的。第7讲:状态机图7.2状态机图状态机图的图形元素3．初始状态（InitialState）模型元素的初始状况，代表一个状态机图的起始点，是一个伪状态（PseudoState）用一个实心的圆表示4．终结状态（FinalState）

模型元素的最后的状态，代表一个状态机图的终止点，是一个伪状态。用一个圆中套一个小实心圆表示。第7讲:状态机图7.2状态机图状态机图的图形元素5．判定（Decision）在状态机图中的一个特定的位置，工作流（Workflow）在此按监护条件的取值而发生分支。用空心小菱形表示。一般，判定只有一个入转移和两个出转移，监护条件为布尔表达式。根据监护条件表达式的值为“真”或“假”，触发不同的分支转移。判定也可以是有一个入转移和多个出转移。第7讲:状态机图7.2状态机图状态机图的图形元素6．同步（Synchronization）同步可视化地定义了并发工作流的分叉（Fork）与汇合（Join）。分叉是一个源状态分为两个或两个以上的目标状态，汇合是两个以上的源状态连接为一个目标状态。在分叉与汇合之间的工作流是并行执行的。同步在状态机图中用一条粗短实线表示，称为同步杆第7讲:状态机图7.3状态组合状态一个不含内嵌套状态的状态，称为简单状态。如果一个状态内嵌套了若干个状态，则称该状态为超状态（Superstate）或组合状态（CompositeState），其中被嵌套的状态称为子状态（Substate）。子状态本身仍然可以是一个组合状态。超状态中的每一个被嵌套的状态机图所表示的子状态机，都对应于该超状态内的正在进行的一个活动。子状态机图的所在区域必有自己的初始状态和终结状态。对组合状态的一个入转移代表对其子区域内的初始状态的入转移；对子区域内的终结状态的转移代表包含它的组合状态的相应活动的完成。注意，动作（Action）与活动（Activity）的含义是不同的。第7讲:状态机图7.3状态历史状态在一个组合状态中所包含的一个由顺序子状态构成的子状态机中，必定有一个子初始状态。每次进入该组合状态，被嵌套的子状态机从它的子初始状态开始运作（除非直接转移到特定的子状态）。有的情况下，当离开一个组合状态后，又重新进入该组合状态，但是不希望从它的子初始状态开始运作，而是直接进入到上次离开该组合状态时的最后一个子状态。历史状态（HistoryState）代表上次离开组合状态时的最后一个活动子状态。每当转移到组合状态中的历史状态时，对象便恢复上次离开该组合状态时的最后一个活动子状态，并执行入口动作。第7讲:状态机图7.3状态历史状态历史状态用一个含有字母“H”的小圆圈表示。历史状态只是一个伪状态（PseudoState）的图形标记，只能作为一个组合状态中的子状态，不能在顶层状态机图中使用。历史状态可以有任意个从外部状态来的入转移，至多有一个无标签的出转移，它进入到一个子状态机。一个影碟机对象工作的部分状态机图第7讲:状态机图7.6状态机图的应用7.6.2CD播放器小结第8讲:物理图（PhysicalDiagram）8.0

导引UML提供了两种物理表示图形：构件图和部署图。构件图表示系统中的不同物理构件及其关系。表达的是系统代码本身的结构。部署图由节点构成，节点代表系统的硬件，构件在节点上驻留并执行。表示系统的软件构件与硬件之间的关系。表达的是运行系统的结构。构件图和部署图用于建立系统的实现模型。第8讲:物理图（PhysicalDiagram）8.1

构件图（ComponentDiagram）1、构件的定义系统的物理的可替换的单位，它把系统的实现打包，并提供一组接口的实现（Realization）。代表系统的一个物理实现块，代表逻辑模型元素如类、接口、协同等的物理打包。本身遵从和提供一组接口的实现，它们代表了由驻留在构件内部的模型元素所实现的服务。用于对系统配置节点上的物理事物建立模型。构件的类型系统的配置构件，如COM+构件、JavaBeans等。软件开发过程中的产物，如软件代码（源码、二进制码和可执行码）等。第8讲:物理图（PhysicalDiagram）8.1

构件图2、构件的表示法图标是一个大矩形的左边嵌二个小矩形。必须有名字在构件名之后或之下，可以用括在花括号中的文字（即标记值）说明构件的性质，如“{version=2.0}”等。第8讲:物理图（PhysicalDiagram）8.1构件图8、构件的依赖关系依赖关系图publicclassA{ ……}publicclassBextendsA{ ……}publicclassA{ publicvoidanOperation(BtheB){ ……}}第8讲:物理图（PhysicalDiagram）8.1构件图8、构件的依赖关系依赖关系图publicclassA{ privateBaLink; ……}}第8讲:物理图（PhysicalDiagram）8.1构件图9、构件图：定义构件图由构件、接口和构件之间的关系构成，其中的构件可以是源码、二进制码或可执行程序。表示系统中的不同物理部件及其关系，它表达的是系统代码本身的结构。只有型（Type）的形式，没有实例形式。为了显示构件的实例需要使用部署图。用于下列事物建立模型：系统的源代码、系统的发布版本、物理数据库、自适应系统等。建立业务模型，此时的构件是业务的过程和文档。建立开发期间的软件产物的依赖关系，用于系统开发的管理。第8讲:物理图（PhysicalDiagram）8.2

部署图（DeploymentDiagram）1、节点的定义存在于运行期间的系统的物理元素代表计算机资源，通常为处理器（Processor）或其他硬件设备，系统的构件可以配置在节点上。图标为一个三维立方体图形，如下图所示。第8讲:物理图（PhysicalDiagram）8.2部署图1、节点的定义存在于运行期间的系统的物理元素节点必须有名字，可以是一个简单名，或用路径名。与类一样，节点可以用标记值说明名字的性质。与类一样，节点可以区分为型和实例，型代表计算资源的不同类型，实例代表特定的具体的计算机资源。对象和构件实例可以驻留在节点实例上，而且可以从一个节点向另一个节点迁移。节点执行构件，构件是被节点执行的事物。一个节点可以与其它的节点、构件、对象有关联。节点和类、协同、构件等模型元素一样可以组织成包。第8讲:物理图（PhysicalDiagram）8.2部署图2、节点的关系节点与节点通过物理连接（Connection）发生关系物理连接如以太网络、共享总线等，从硬件方面保证了系统的节点协同运行。节点与节点、节点与构件之间存在着多种类型的关系。第8讲:物理图（PhysicalDiagram）8.2部署图2、节点的关系（1）通信关系（关联）通信关系是节点之间的一种关联，是节点之间的通信路径或连接的模型。通信关系的表示法是用一条实关联线连接两个节点。在实关联线上可以加构造型以表达节点间的通信路径或连接的性质。通信关系表示法示例

第8讲:物理图（PhysicalDiagram）8.2部署图2、节点的关系（2）成为关系成为关系是构件与构件、构件与对象、对象与对象之间的依赖关系。成为关系不是节点之间的关系，但是它是构件或对象在节点之间的迁移的模型。成为关系说明源对象（或构件）和目标对象（或构件）是在不同时间点的同一个对象（或构件），而且它们的状态和角色不同。成为关系可以用标记值“{time=…}”说明其时间性质，即构件或对象在什么时间发生迁移活动。第8讲:物理图（PhysicalDiagram）8.2部署图2、节点的关系（2）成为关系表示法是用一条虚箭线从一个节点中的构件指向另一个节点中的构件或从一个节点中的对象指向另一个节点中的对象，并可在虚箭线上加有构造型<<becomes>>。成为关系表示法示例

第8讲:物理图（PhysicalDiagram）8.2部署图3、部署图的定义由节点与节点之间的关系构成，包括构件之间、节点与构件之间、构件与构件之间的关系。表示分布式系统的软件构件与硬件之间的关系，它表达的是运行系统的结构。主要用于对在网络环境运行的分布式系统建立系统物理模型，或者对嵌入式系统建模。可以用于建立业务模型，此时的“运行系统”就是业务的组织机构和资源（人力、设备等）。第9讲:模型管理图9.1包：语义和表示包（Package）是一种对模型元素进行成组组织的通用机制。包用于定义一个名字空间（Namespace）或容器（Container），它本身是UML的一种模型元素。对包中的元素作为一个整体对待，并且控制它们的可视性和存取。包的图标是一个大矩形（内容框）的左上角带一个小矩形（名字框）名字可是一个简单名或路径名。在包名之后或之下，可用括在花括号中的文字（约束）说明包的性质，如“{abstract}”、“{version}”等第9讲:模型管理图9.2包的联系：依赖与输入依赖包与包之间的联系主要有两种：依赖和泛化。依赖：两个包所含模型元素之间存在着一个或多个依赖

对于由类组成的包，如果在两个包的任何类之间存在着任何一种依赖，则这两个包之间存在着依赖。包的依赖联系同样是用一条虚箭线表示，虚箭线从依赖包（源）指向独立包（目标）。包的依赖联系没有传递性。第9讲:模型管理图9.2包的联系：依赖与输入依赖包与包之间的联系主要有两种：依赖和泛化。包的依赖联系可以加上许多构造型规定它的语义，其中最常见的一种依赖是输入依赖。输入依赖（ImportDependency）是包与包之间的一种存取（Access）依赖关系。输入（Importing）是指允许一个包中的元素存取另一个包中的元素。输入依赖是单向的，没有传递性。包的公共部分，即其可视性为“公共”的模型元素，称为包的输出（Export）。包的输出只对另一个与它有输入依赖的包才是可视的、可存取的。注意：存取依赖联系的另一个构造型<<Access>>，与<<Import>>的含义略有差别。第9讲:模型管理图9.2包的联系：合并包与包之间的联系主要有两种：依赖和泛化。包之间的合并联系是一种依赖关系，用一条带有构造型<<Merge>>的虚箭线表示，从接受合并包（ReceivingPackage）指向被合并包（MergedPackage）。允许被合并包的内容与接受合并包的内容合并：即（在概念上而非物理上）把被合并包中的全部元素合并加入到接受合并包中被合并包与接受合并包中的那些具有相同名称的元素则合并成一个唯一的元素，它拥有两者的特征。当定义在不同的包中的模型元素具有相同的名称并且表达相同的概念时，就需要使用包合并联系。第9讲:模型管理图9.2包的联系：泛化包与包之间的联系主要有两种：依赖（尤其是输入依赖）和泛化。泛化：特殊性包必须遵循一般性包的接口一般性包可加上一个性质说明“{abstract}”，表明它只不过是定义了一个接口，该接口可以由多个特殊包实现。与类的继承相同，特殊包从一般包继承其所含的公共类，并且可重载和添加自己的类。特殊包可代替一般包，用在一般包使用的任何地方。第9讲:模型管理图9.3包图包图由包和包之间的联系构成。包图的图形节点是包，节点之间用弧（依赖或泛化）连接。包图是维护和控制系统总体结构的重要建模工具。包在很多方面与类相似，但是在建立系统模型时特别要注意区别包与类。类是问题领域或解决方案中的事物的抽象，包是把这些事物组织成模型的一种机制。包可以没有标识，因为它没有实例，在运行系统中不可见；类必须有标识，它有实例，类的实例（对象）是运行系统的组成元素。一个简单的约束约束是布尔断言（Booleanassertions）非形式写出的约束应当用花括号“{}”括起来放在所描述的模型元素的内部或紧靠所描述元素的地方也可放在注解的图标内，用虚线连接到所描述的模型元素第10讲:约束（Constraint）第10讲:约束（Constraint）10.2对象约束语言对象约束语言（ObjectConstraintLanguage，OCL）用于表示UML模型中施加于模型元素上的约束。OCL是一种纯表达式语言，它用表达式表示约束。OCL的表达式确保没有副作用，对一个OCL表达式进行求值将返回一个值，它在系统模型中不改变。OCL是一种规格说明语言（SpecificationLanguage）。所有有关实现的问题都不能用OCL表达。OCL不是一种程序设计语言，不能用OCL编写程序，不能用OCL编写程序逻辑和控制流程。每个OCL约束有一个上下文将OCL表达式和被约束的模型元素连接在一起。约束能够表示在图上或者写在一个独立的文本文档中附加到该模型。在被约束元素中在一个附加的注解（note）中第10讲:约束（Constraint）10.3

约束的上下文（Context）人事系统第10讲:约束（Constraint）10.4

导航表达式从上下文对象开始，我们沿着链接到达其他对象通过一个关联进行导航，需要使用：关联端的角色名（therolenameatthefarendoftheassociation）或者关联端的类名（thenameoftheclassatthefarend）导航过程需要遍历这个对象网的一部分，所以称表示这些对象的表达是为导航表达式圆点标识进行分隔第10讲:约束（Constraint）10.4

导航表达式类不变量（ClassInvariants）类不变量是类的性质，是指对该类的所有实例，在所有时间，该不变量为真。“anaccount’sbalancemustbeinagivenrange”contextSavingsAccountinv: balance>0andbalance<25000第10讲:约束（Constraint）10.7构造型的约束前置条件（Preconditions）特别为操作而使用的约束前置条件（Preconditions

）表示的是在一个操作调用前必须为真的事情“youcanonlywithdrawanamountlessthanthebalanceinanaccount”contextSavingsAccount::withdraw(amt:Real)pre:amt<balance第10讲:约束（Constraint）10.7构造型的约束后置条件（Postconditions）后置条件（Postconditions）指明操作的结果，通过比较该操作执行前和执行后的属性值表示。“withdrawtheamountgiventoit”contextSavingsAccount::withdraw(amt:Real)post:balance=balance@pre-amt‘balance@pre’denotesthebalancebeforetheoperationexecuted第10讲:约束（Constraint）10.7构造型的约束第11讲:统一建模语言应用11.4

实现模型：类的实现类第11讲:统一建模语言应用11.4

实现模型：类的实现泛化第11讲:统一建模语言应用11.4

实现模型：类的实现类的重数第11讲:统一建模语言应用11.4

实现模型：类的实现关联的实现：单向（初步）第11讲:统一建模语言应用11.4

实现模型：类的实现关联的实现：单向（改进）第11讲:统一建模语言应用11.4

实现模型：类的实现关联的实现：单向第11讲:统一建模语言应用11.4

实现模型：类的实现关联的实现：单向（可选关联）第11讲:统一建模语言应用11.4

实现模型：类的实现关联的实现：双向（引用完整性）第11讲:统一建模语言应用11.4

实现模型：类的实现关联的实现：双向（两个类同时维护关联）第11讲:统一建模语言应用11.4

实现模型：类的实现关联的实现：双向（一个类维护关联）第11讲:统一建模语言应用11.4

实现模型：类的实现关联的实现：限定关联第11讲:统一建模语言应用11.4

实现模型：类的实现关联的实现：关联类第11讲:统一建模语言应用11.4

实现模型：类的实现约束的实现第11讲:统一建模语言应用11.4

实现模型：类的实现操作的实现第11讲:统一建模语言应用11.4

实现模型：逆向工程（源代码产生UML文档）第11讲:统一建模语言应用11.4

实现模型：逆向工程（源代码产生UML文档）第11讲:统一建模语言应用11.4

实现模型：逆向工程（源代码产生UML文档）第11讲:统一建模语言应用11.4

实现模型：逆向工程（源代码产生UML文档）第11讲:统一建模语言应用11.4

实现模型：实现原则开-闭原则1988年，BertrandMeyer提出了开闭原则“软件实体应当对扩展开放，对修改关闭”软件系统中包含的各种组件，例如模块（Modules）、类（Classes）以及功能（Functions）等等，应该在不修改现有代码的基础上，引入新功能。“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；“闭”，是指对于原有代码的修改是封闭的，即不应该修改原有的代码。第11讲:统一建模语言应用11.4

实现模型：实现原则无具体超类避免维护具体的超类Liskov替换原则Liskov于1987年提出了一个关于继承的原则“继承必须确保超类所拥有的性质在子类中仍然成立。”也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系。交互决定结构根据对象之间的交互确定设计中的对象所属的类之间的结构关系UML系统分析与设计（习题）班级A：B150417班级B：B150411-12等作业11.3Asthetextmakesclear,thatitisimportanttodistinguishthefollowingtwothings:• TheuseofUMLnotationstodescribeasoftwaresystem;• TheuseofUMLnotationstosupportadevelopmentprocess.ItcouldbearguedthatbecauseUML,alongwithsimilarnotationsandlanguages,hasevolvedtosupportdevelopment,itsnotationscannotbeunderstoodwithoutreferencetotheiruseinthedevelopmentprocess.ItcanthereforehelpinlearningUMLtoconnectthevariousnotationswiththeirtypicaluses.Ontheotherhand,themeaningofthevariousdiagramsinnowaydependsontheiruseinoneoranotherprocess.Diagramsdocumentcertainpropertiesofasoftwaresystem,nottheprocessbywhichitwasdeveloped.作业11.3Asmanydifferentprocessesareusedfordevelopingsoftware,itisimportanttohaveanunderstandingofUMLnotationsthatisindependentoftheirapplicationinthedevelopmentprocess.Itismoreplausiblethattheroleofadesignprocessistoassistdesignerstoproducedesignsthatareinsomesense"well-structured".Theanalogywithprogramminglanguagesmighthelptomakethisclear.Simplyknowingthesyntaxofalanguagedoesnotmeanthatprogrammerswillautomaticallywriteelegant,maintainableandefficientprograms.Definitionofthesepropertiesisnotpartofthelanguageitself;itismoreaquestionoflearninghowthelanguageisbestapplied.MuchthesamegoesforadesignlanguagelikeUML,andoneroleforadesignprocessistoensurethatthedesignswhichareproducedhavetherequiredhigh-levelproperties.作业24.2作业24.2ThisdiagramisnotquiteequivalenttoFigure4.7.BothdiagramsspecifythesamecapabilitiesfortheReceptionistandHeadWaiteractors,butinadditionFigure4.7definesanactorStaffwhoonlyhastheabilitytodisplaybookings.Nosuchactorisdefinedinthediagramabove,thoughaStaffactorcouldeasilybeaddedifrequired.Becausethisisasimplediagram,thereisnotmuchdifferenceincomplexitybetweenthetwoversions.Inmorecomplicateddiagrams,however,theuseofactorgeneralizationcansignificantlyreducethenumberofassociationsthathavetobeshown,thussimplifyingthediagram.Theuseof"superactors"alsomakesiteasiertoseewhenusecasescanbeperformedbyavarietyofactors.作业32.2（中文课本第28页）作业32.2（a）解答作业32.2（中文课本第28页）作业32.2（b）解答作业32.2（中文课本第28页）作业32.2（c）解答作业42.5（中文课本第30页）作业42.5（a）解答作业42.5（b）解答Althoughitisplausibletoassumethattheorderofmessagesinthisdiagramischeckpoint;read;read;read;transcribe,thisassumptionisbasedentirelyonourknowledgeofthereal-worldsituationbeingmodelled.Onewayofspecifyingtheorderofmessageswouldbetonumberthem.WaysofspecifyingthesequencingofmessagesmoreformallyarediscussedinChapter9.Afurtherambiguityinthisdiagramisthatitisnotentirelyclearwhetherasingletranscribemessageissentafterallthedatahasbeenreadfromthesensors,orifeachreadisfollowedbyacorrespondingtranscribe.作业42.5（c）解答Aclassdiagramconsistentwiththeobjectdiagramgivenaboveisshownbelow.AnabstractSensorclassisintroducedsothatthethreelinksfromthemonitoringstationtotheindividualsensorobjectscanbemodelledbyoneassociation.作业58.2（中文课本第138页）作业58.2（中文课本第138页）作业58.2（a）解答作业58.2（b）解答作业58.2（c）解答作业58.2（d）解答作业58.2（e）解答作业68.3（中文课本第138页）作业68.3解答(a)Valid.(b)Invalid,becauseaccordingtotheclassdiagrameveryinstanceofCmustbelinkedtopreciselyoneinstanceofclassD.So`standalone'instancesofCarenotpermitted.(c)Invalid,becausetheinstanceofclassDislinkedtotwoinstancesofclassC,contrarytotheclassdiagramwhichspecifiesthatitshouldbelinkedtoatmostoneinstanceofC.(d)Invalid,becausetheinstanceofclassCislinkedtotwoinstancesofclassD,contrarytotheclassdiagramwhichspecifiesthatitshouldbelinkedtoexactlyoneinstanceofD.(e)Invalid,becausethereisnoassociationintheclassdiagramforthelinkbetweenthetwoinstancesofclassDtobeaninstanceof.(f)Valid.InstancesofclassDareoptionallylinkedtoinstancesofclassC,sothereisnoproblemwitha`standalone'instanceofD.作业78.5（中文课本第138页）作业78.5解答作业88.9（中文课本第140页）作业88.9解答IftheabstractdrawoperationwasomittedfromtheShapeclass,itwouldbeimpossibletoinvokethe`draw'operationonashapewithoutknowingwhatsubclassitbelongedto.Inotherwords,codesuchasthefollowingwouldnotwork:Shapes=newRectangle();s.draw();作业88.9解答Itwouldbenecessarytocasttheobjecttoitsspecificsubclassfirst:Shapes=newRectangle();((Rectangle)s).draw();Thiswouldfrustrateamajorbenefitofusinggeneralization,namelyt