发布时间 : 星期二 文章UML期末复习 - 图文更新完毕开始阅读1ae9aae95ef7ba0d4a733b85
《UML》复习资料 第一章 UML建模技术
一、建模的意义 1、常见的模型
（1）生活相关：气象图、道路交通图、交通标志?
（2）展示相关：建筑物模型、沙盘、公司总部的3D复制品? （3）数据分析相关：条形图、饼状图?
（4）业务分析相关：组织结构图、跨职能流程图?? （5）设计相关：建筑平面图、管线图、电路板设计图 2、模型是对现实的简化，建模是为了更好地理解系统。
①模型帮助我们按照实际情况或需求对系统可视化；②模型允许我们规约系统的结构、行为；③模型给出了一个构造系统的模板；④模型对我们作出的决策进行文档化；
二、建模的原理：①选择创建什么模型对如何动手解决问题和如何形成解决方案有意义深远的影响。②可以在不同的精度级别上表示每一种模型③单个模型或视图是不充分的。对每个重要的系统最好用一小组几乎独立的模型从多个视角去逼近。 三、选择UML
1、使用UML建立对象模型来映射现实世界
2、统一的国际标准建模语言UML—— Unified Modeling Language. ①Unified：组合了当前最好的面向对象软件建模方法
②Modeling：用于表达现实的简化视图，以便于面向对象软件系统的设计与实现 ③Language：UML主要是遵循精确语法的图形语言 UML是一种统一的、标准化的建模语言； UML是一种应用面很广泛的建模语言
3、目标：提供全面的建模语言（为所有事情所有人），便于开发组所有成员通信交流 4、可以建立什么模型 模型的种类 业务模型 需求模型 模型的用途 对业务过程、工作流、组织的建模 对捕获的需求进行整理和分析的工具，辅助开发人员 与用户进行沟通 5、草图与蓝图
蓝图一般是指采用CASE工具绘制的、正式的、规范的UML模型；草图则通常是指手工绘制的、规范度较低的在纸张的UML模型
大胆地绘制草图，尽可能基于草图进行讨论。对于局部的、重要性不高的、共享范围较小的UML模型，直接将草图扫描到电脑存档即可；对于全局的、重要性高的、高度共享的，在草图的基础上用CASE工具绘制成为正式的蓝图，并将其纳入统一的模型管理中 6、谁应该建模
①业务建模：以领域专家为主，需求分析人员是主力，系统分析员、架构师可参与
②需求模型：以需求分析人员为主，系统分析员是主力，领域专家提供指导，架构师和资深开发人员参与③设计模型：高层设计模型以架构师为主，系统分析员从需求方面提供支持，资深开发人员从技术实现方面提供支持。详细设计模型则以资深开发人员为主，架构师提供指导。④实现模型：以资深开发人员（设计人员）为主，架构师提供总体指导。⑤数据库模型：以数据库开发人员为主，架构师提供指导，资深开发人员（设计人员）予以配合。
1.4 UML的特点：①统一的标准②面向对象③可视化，表示能力强④跟过程无关⑤易于学习使用 【理解】
1、UML是一种语言：①遵循特定的规则；②允许创建各种模型；③并不告诉设计者需要创建哪些模型；④并不提供开发过程
2、UML是可视化语言：①UML是图形化语言；②图形便于交流（一幅图抵上千文字） 3、UML是用于构造系统或理解系统的语言；UML既支持正向工程，又支持反向工程 4、UML是文档化语言：①将所建造的系统记录下来；②便于新程序员跟进；③开发产品新版本时很有用处 【误区】
1、UML是一种方法论？只是规范、标准，没有方法指南，只有方法的概念 2、UML是一堆图形？还有文字
第 1 页 共 42 页
实现模型 用来理清软件的组成、部署方案，为安装与维护人员 的工作提供指导 数据库模型 设计模型 包含高层设计（架构模型）和详细设计模型，用于统 一开发人员、沟通设计信息 设计数据库的结构、表结构以及与应用系统的交互 3、UML只能应用与面向对象开发？还可以建模业务、数据库、工作流等等 4、UML是Rational Rose里的建模符号？Rational Rose只是其中一种建模工具
第二章 UML组成
一、 UML组成
（1）基本构造块：也就是建模元素，是模型的主体
（2）UML规则：也就是支配基本构造块如何放在一起的规则 （3）公共机制：运用于整个UML模型中的公共机制、扩展机制 二、事物构造块
1、事物构造块：是对模型中最具有代表性的成分的抽象
（1）结构事物：UML中的名词，它是模型的静态部分，描述概念或物理元素。
（2）行为事物：UML中的动词，它是模型中的动态部分，是一种跨越时间、空间的行为。 （3）分组事物：UML中的容器，用来组织模型，使模型更加的结构化。
（4）注释事务：UML中的解释部分，和代码中的注释语句一样，是用来描述模型的。 2、面向对象视角下的世界
①首先建立反应现实世界中不同事物的“构造块”，然后确定“构造块”之间的“关系”，再确定各个构造块的属性和“行为”。这样，在软件系统中就可以模拟现实世界的“构造块”之间的交互与协作
②面向对象软件开发的核心思想就是高内聚（封装）、低耦合（消息驱动），使用简洁的接口拼合简单的部件 3、分类
（1）结构事物
1）类和对象：①类是对一组具有相同属性、相同操作、相同关系和相同语义的对象的抽象②UML中类是用一个矩形表示的，它包含三个区域，最上面是类名、中间是类的属性、最下面是类的方法③对象则是类的一个实例
2）接口：接口是描述某个类或构件的一个服务操作集
3）主动类：①主动类实际上是一种特殊的类。引用它的原因，实际上是在开发中需要有一些类能够起到启动控制活动的作用②主动类是指其对象至少拥有一个进程或线程，能够启动控制活动的类
4）用例：①用例是著名的大师Ivar Jacobson首先提出的，现已经成为了面向对象软件开发中一个需求分析的最常用工具②用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。
5）协作：①定义了一个交互，它是由一组共同工作以提供某协作行为的角色和其他元素构成的一个群体。②对于某个用例的实现就可以表示为一个协作
6）构件：①在实际的软件系统中，有许多要比“类”更大的实体，例如一个COM组件、一个DLL文件、一个JavaBeans、一个执行文件等等。为了更好地对在UML模型中对它们进行表示，就引入了构件（也译为组件）
②构件是系统设计的一个模块化部分，它隐藏了内部的实现，对外提供了一组外部接口。在系统中满足相同接口的组件可以自由地替换
7）节点：①为了能够有效地对部署的结构进行建模，UML引入了节点这一概念，它可以用来描述实际的PC机、打印机、服务器等软件运行的基础硬件②节点是运行时存在的物理元素，它表示了一种可计算的资源，通常至少有存储空间和处理能力 （2）行为事物
1）交互（interaction）：①是在特定语境中，共同完成某个任务的一组对象之间交换的信息集合 ②交互的表示法很简单，就是一条有向直线，并在上面标有操作名
2）状态机（state machine）：①是一个对象或交互在生命周期内响应事件所经历的状态序列②在UML模型中将状态画为一个圆角矩形，并在矩形内写出状态名称及其子状态 （3）分组事物 包（Package）
对于一个中大型的软件系统而言，通常会包含大量的类，因此也就会存在大量的结构事物、行为事物，为了能够更加有效地对其进行整合，生成或简或繁、或宏观或微观的模型，就需要对其进
第 2 页 共 42 页
行分组。在UML中，提供了“包（Package）”来完成这一目标 （4）注释事物
结构事物：是模型的主要构造块，行为事物则是补充了模型中的动态部分，分组事物而是用来更好地组织模型，似乎已经很完整了。而注释事物则是用来锦上添花的，它是用来在UML模型上添加适当的解释部分
三、关系：关联（association）、泛化（generalization）、实现（realization）、依赖（dependency） 四、 UML规则
1、命名：也就是为事物、关系和图起名字。和任何语言一样，名字都是一个标识符
2、范围：与类的作用域相似，包括所有者作用域（owner scope）和目标作用域（target scope）两类 3、可见性： 可见性 规则 标准 Rose Rose 表示 属性 方法 public 任一元素，若能访问包容器，就可以访问它 + protected 只有包容器中元素或包容器后代才能够看到它 # private 只有包容器中的元素才能够看得到它 - package 只有声明在同一包中的元素才能够看到该元素 ~ 第三章 用例图
一、用例图的组成
用例（Use Case）、参与者（角色，Actor）、关系（Relationship） 1、用例 （1）Use Case:
①系统、子系统或类与外部的参与者（actor）交互的动作序列的说明，包括各种序列及出错序列。②用例分析可以认为是对系统功能的分解。
（2）怎样确定用例的粒度？①用例的粒度（用例的大小）可大可小，一般一个系统宜控制在20
个用例左右。②用例是系统级的、抽象的描述，不是细化的（是做什么，非怎样做）③对复杂的系统可以划分为若干子系统处理。
（3）怎样获取用例？①参与者希望系统执行什么任务？②参与者在系统中访问哪些信息（创建、存储、修改、删除等）？③需要将外界的哪些信息提供给系统？④需要将系统的哪个事件告诉参与者？⑤如何维护系统？ 2、 参与者（角色）Actor
（1）系统外部的参与者，可以是人、外部硬件、其他系统，甚至时间。
（2）怎样识别参与者？①谁向系统提供信息？②谁从系统获取（使用）信息？③谁操作系统？ ④谁维护系统？⑤系统使用哪些外部资源？⑥系统是否和已经存在的系统交互？⑦是否有事情自动在预计时间发生？ 【理解】
①Actor不是指人，而是指代表某一种特定功能的角色，因此同一个人可能对应很多个Actor。②Actor是虚拟的概念，可以指外部系统和设备。③如果一个角色的操作是由另外一个角色代理完成的，请建立该角色到另外角色的依赖。
3、关系：关联（association）、包含（include）、扩展（extend）、泛化（generalization） （1）关联
①用单向箭头表示，只表示谁启动用例，不考虑信息的双向流动；每个用例都有角色启动，除包含和扩展用例②无论用例和角色是否存在双向数据交流，关联总是由角色指向用例。 （2）包含include
①箭头方向由基本用例指向被包含用例；②两个以上用例有共同功能，可分解到单独用例，形成包含依赖；③执行基用例时，每次都必须调用被包含用例，被包含用例也可单独执行；
④一个用例过于复杂，可以分解成小用例，构成包含依赖（三个被包含的用例合起来实现完整的事件流，不能单独调用）；
第 3 页 共 42 页
（3）扩展（extend）
①一个用例（在某些扩展点上）扩展另一个用例的功能 ，构成新用例；
②扩展用例依赖于被扩展依赖（基本用例），只是部分片断组成，不是完整的独立用例，无法单独执行；
（4）泛化（generalization）
①一个用例和其几种情形的用例间构成泛化。②往往父用例表示为抽象用例（abstract）。
【理解】
二、 用例图
显示系统和外部实体交互的图。
三、 用例描述
（1）更详细地描述用例的功能
（2）主要组成：用例名称、简要说明/描述、优先级、参与者、前提条件、主事件流、其他事件流、扩展点、后置条件
用例编号 [为用例制定一个唯一的编号，通常格式为UCxx] 用例名称 [应为一个动词短语，让读者一目了然地知道用例的目标] 用例概述 [用例的目标，一个概要性的描述] 范围 [用例的设计范围] 主参与者 [该用例的主Actor，在此列出名称，并简要的描述它] 次要参与者 [该用例的次要Actor，在此列出名称，并简要的描述它] 项目相关人 项目相关人 利益 利益说明 [项目相关人员名称] [从该用例获取的利益] …… …… （3）用例描述模板 前置条件 [即启动该用例所应该满足的条件。] 后置条件 [即该用例完成之后，将执行什么动作。] 成功保证 [描述当前目标完成后，环境变化情况。] 基本事件流 步骤 活动 第 4 页 共 42 页