UML考题复习
复习重点：
| 章节 | 复习重点 |
|---|---|
| 第一章 | 掌握uml的定义 |
| 第二章：UML概述 | ①重点为构造块部分，尤其是关系；②明晰9种图概念；③能够举出物件的概念和实例；④顺序图，用例图、类图、活动图相关概念以及具体画法掌握 |
| 第三章：用例建模 | ①掌握流程；②用例文档的编写；③用例之间的关系与用法 |
| 第四章：用例分析 | ①分析建模题（50分）：涉及画图 |
1. UML相关概念
Unified Modeling Language，统一建模语言
UML是对象管理组织制定的一个通用的、可视化的建模语言标准，可以用来可视化、描述、构造和文档化软件密集型的各种工件。
UML建模过程通常分为四个部分：分析阶段、设计阶段、实现阶段、部署阶段。
2.UML的概述
这一章要求掌握：
- 重点为构造块部分，尤其是关系
- 明晰9种图概念
- 能够举出物件的概念和实例
- 顺序图，用例图、类图、活动图相关概念以及具体画法掌握
2.1 构造块
2.1.1 物件（Things）
2.1.1.1 结构物件
① 类
具有相同属性、操作、关系和语义的对象集合的总称。（注意符号表示，uml中类被画成矩形）
注意：
- 属性名第1个英文单词首字母小写，其他单词首字母大写（其实也就是小驼峰命名法）
- public：+；protect：#；private：-；package：~
- 操作名第1个英文单词首字母小写，其他单词首字母大写
按照类的作用，类被分为以下三类：
-
实体类：业务领域中的客观事物，名字用名词或名词短语。
-
界面类：描述系统与外界之间交互的系统要素，包括用户界面、系统和设备接口，命名使用名词或名词短语。
-
控制类：表示系统用来进行调度、协调、处理，以及业务处理的系统要素，命名使用动词或动词短语。
② 接口
接口未给出实现的对象行为的描述，接口是可以在整个模型中反复使用的一组行为，是一个没有属性而只有方法的类。
③ 组件
是系统设计的一个模块化部分（也可以理解为一个封装完好的物理实现单元），它隐藏了内部的实现，对外提供了一组定义明确的接口，并且由于它对接口的实现过程与外部元素独立，所以组件具有可替换性（组件可以是源代码、可执行程序或动态库）。
④ 节点
代表系统运行时的物理单元，主要用于系统物理方面的建模，通常拥有一些内存，并具有处理能力。
部署图中的节点往往包括计算能力、基本内存、位置方面的内容。
节点类型：处理器（Processor）和设备（Device）。
2.1.1.3 分组物件
⑤ 包
用于把在语义上相关的建模元素分组为内聚的单元。
2.1.1.4 注释物件
⑥ 注解
2.2 关系
关系：用于把物件联系在一起，关系说明两个或多个物件是如何语义相关的。
2.2.1 关联
① 关联association：has a
| 关联的类型 | 图示 |
|---|---|
| 连接、聚合、组合 |  |
| 连接 ——表示两个类对象之间有导航关系（比如指针的使用） |  |
| 聚合 ——has a，对象A是对象B的一个组成成分 |  |
| 组合 ——强语义的聚合，整体对象消失，部分对象也消失 |  |
2.2.2 依赖
② 依赖dependence ：use a
一个模型元素的变化会影响另一个模型元素。
2.2.3 泛化
③ 泛化generalization ：is a or is a kind of
泛化是一般化和具体化之间的一种关系。继承就是泛化的一种。
2.2.4 实现
④ 实现realization ：like a
实现关系被用来规定接口和实现接口的类或组件之间的关系。
是指一个class实现interface接口（一个或者多个），表示类具备了某种能力，实现是类与接口中最常见的关系。
2.3 图
图：是展现物件的集合。
uml包括五大类图（共有9种图形）
UML的静态建模机制包括：
用例图 (Use case diagram)
类图 (Class diagram)
对象图 (Object diagram )
构件图 (Component diagram)
配置图 (Deployment diagram)
包 (Package)
（表格中橘色字体表示图不要求掌握，红色为需要重点掌握内容）
| UML类型 | Ⅰ：structural diagram（静态模型结构图） | Ⅱ：behavioral diagram（动态模型行为图） |
|---|---|---|
| 1 | 类图 | 用例图 |
| 2 | 对象图 | 顺序图 |
| 3 | 组（构）件图 | 协作图（通信图） |
| 4 | 部署图 | 状态图 |
| 5 | 复合结构图 | 活动图 |
| 6 | 包图 | 交互概要图 |
| 7 | 计时图 |
2.3.Ⅰ.1 类图（重点）
类图：详细描述了系统内各个对象的类型，以及这些类之间的静态关系。
类图=类+关系+约束（多重性，属性和方法）
类图的作用：
①为开发人员提供这种模仿现实世界的表达方式
②让分析员使用客户所采用的术语和客户交流，促使客户说出所要解决的问题的重要细节
类中的属性首字母不可大写！
多重性：指某个类具有多个对象可以和另一个类的1个对象关联。
VOPC：View Of Participating Classes 参与类图
vopc是简化的类图，强调类之间的关系而不用详细写出类的属性与方法。VOPC只有关联关系。
2.3.Ⅰ.2 对象图
对象图：描述对象及其关系的图
对象图=对象+链
对象图与类图的关系：对象图是更接近于客观世界的图，在抽象类图之前，最好先建模对象图，这样类图才能落地。
| 类图 | 对象图 |
|---|---|
| 包含三部分：类名、类的属性和类的操作 | 包含两部分：对象的名称和对象的属性 |
| 类的名称栏只包含类名 | 对象的名称栏包含“对象名：类名” |
| 类的属性栏定义了所有属性的特征 | 对象的属性栏定义了属性的当前值 |
| 类中列出了操作 | 对象图中不包含操作内容，因为对属于同一个类的对象，其操作都是相同的 |
| 类中使用了关联连接，关联中使用名称、角色以及约束等特征定义 | 对象使用链进行连接，链中包含名称、角色 |
| 类代表的是对对象的分类所以必须说明可以参与关联的对象的数目 | 对象代表的是单独的实体，所有的链都是一对一的，因此不涉及到多重性。 |
参考来源
例题：
2.3.Ⅰ.3 组件图
组件图：为系统中的组件建模，展示了组件间相互依赖的网络结构。
组件图=组件+接口+关系+端口+连接器
组件间的关系：虚线加一个开箭头（依赖关系），由需接口指向供接口。
组件需要包含和使用一些类的功能，故可以在组件中画出这些类和类间的关系。
2.3.Ⅰ.4 部署图
部署图：
- 用于描述软件执行所需要的处理器和设备的拓扑结构，常用在实施阶段。
- 是系统静态下的物理结构建模。
- 是一个运行时的硬件节点以及在这些节点上运行的软件的静态结构模型。
| 部署图组成 | 内容 | uml中的表现形式 |
|---|---|---|
| 制品 | 一个模型、描述或软件，通常以文件的形式存在，比如.exe |  |
| 节点 | 被部署到的硬件或软件环境，有两种类型：①执行环境节点《ExecutionEnvironment》；②设备节点《device》 |  |
| 通信路径 | 表示节点间的通信，用实心线表示 |  |
部署图显示了运行软件系统的物理硬件，以及如何将软件部署到硬件上（将制品部署到节点上，依赖关系，箭头指向节点）。
2.3.Ⅰ.6 包图
包图：可以把每个包视作存放诸多模型元素的文件夹，将用例进行了分类。
2.3.Ⅱ.1 用例图（重点）
用例图：用来显示在系统（或其他实体）内的用例与系统参与者之间的关系。
用例图=参与者+用例+关系
用例的关系有泛化 (generalization)、扩展 (extend)和包含 (include)
《include》：由原始用例指向划分出来的用例
《extend》：由拓展用例指向原始用例
2.3.Ⅱ.2 顺序图（重点）
顺序图用于捕获系统运行中对象之间有顺序的交互，强调的是消息交互的时间顺序。
顺序图通常按照执行者角色 用户接口 控制类 业务层 后台数据库从左向右排列各个对象。
Sequence Diagrams（顺序图）
顺序图=交互的参与者+生命线+活动条+消息
消息的命名：
d = get (id1:ItemID,id2:ItemID) ：Item
消息的名字是get，它有两个参数，id1和id2，这两个参数都是ItemID类型的，消息返回类Item的对象，该对象被存储在消息调用方的属性d中
| 消息符号 | 意义 |
|---|---|
 实体箭头 |
同步消息：对象A必须等待B的消息返回才能继续执行下一个行为 |
 开放式箭头 |
异步消息：对象A向B发送一个消息即可继续执行下一个行为 |
 |
对象创建消息：表示对象在交互过程中被创建 |
 |
对象销毁消息：表示一个对象可以通过 对象销毁消息 销毁另一个对象或者它本身，同时画“X”标识该对象被销毁 |
 |
自我调用消息：消息从一个对象发送到它本身 |
 |
消息值的返回（虚线） |
| 交互框 | 意义 |
|---|---|
 |
alt：选择片段，表达互斥的条件逻辑，与if else相似 |
 |
loop：循环片段，条件为真的时候循环；例如：左图中[m,n]是指至少执行m次，最多执行n次 |
 |
opt：可选片段，为真时执行 |
 |
并行片段：表达并行执行 |
参考来源
2.3.Ⅱ.3 通信图
Communication Diagram 通信图（也叫协作图）
通信图=交互的参与者+通信链+消息
通信图是基于交互作用的对象行为建模，强调对象之间在交互作用时的关联。
| 消息 | 意义 |
|---|---|
 |
自我委派消息 |
 |
控制消息：当条件为真时才会发送 |
| 嵌套消息和子消息：当一个消息导致了另一个消息被发送的时候，第二个消息被称为嵌套在第一个消息里，这样的消息称为嵌套消息，用多级消息号表示消息的嵌套 | |
 |
循环：用“*”表示 |
 |
并发消息：顺序号标识 |
2.3.Ⅱ.4 状态图
状态图：描述了一个实体基于事件反映的动态行为，显示了该实体是如何根据当前所处的状态对不同的事件作出反应的。
状态图=状态+迁移
状态由一个带圆角的矩形表示，状态图的图标可以分为3部分：名称、内部转换和嵌套状态。
(1)名称：表示状态的名字，通常用字符串表示。一个状态的名称在状态图所在的上下文中应该是唯一的
(2)内部转换：在内部转换中可以包含进入或者走出此状态应该执行的活动或动作，它们将响应对象所接收到的事件，但是不改变对象的状态。
(3)嵌套状态图：状态图中的状态有两种：简单状态和组合状态。简单状态不包含其他状态，组合状态是包含子状态的状态。在组合状态的嵌套状态图部分包含的就是此状态的子状态。
| 状态的种类 | 图示 |
|---|---|
| 简单状态：没有子状态，只有一组转换和可能的入口和出口动作 |  |
| 复合状态：由一组或多组子状态图组成 |  |
| 初始状态：状态图状态的起点 |  |
| 终止状态 |  |
| 结合状态：将两个转换连接成一次就可以完成的转换 |  |
| 历史状态：保存组成状态中先前被激活的状态 |  |
应用标签可以表示状态的内部活动。
迁移：指从一个状态到另一个状态的瞬间变化过程。
uml提供了以下三种迁移的文字标签：
①触发trigger：指明何种条件可以导致迁移发生
②警戒条件guard：指为了让警戒发生而必须为真的布尔表达式
③行为behavior：指为响应事件而执行的行为，迁移行为指当迁移发生时所执行一个不可中断的活动
以上三部分组成的文字标签来解释该迁移的发生事件，格式为：
触发【警戒条件】/ 行为
2.3.Ⅱ.5 活动图（重点）
活动图： 活动图是一种描述过程逻辑、业务流程和工作流程的技术。它本质上是一个流程图，显示从一个活动或动作到另一个活动或动作的控制流。UML活动被用于描述复杂的企业流程、用例场景或为具体业务的逻辑建模
活动图=活动+动作+活动边+活动节点
| 活动图组成 | 具体内容 |
|---|---|
| 活动 | 由一个或多个动作组成的行为 |
| 动作 | 活动的一个基本执行单位 |
| 活动边 | 箭头指向动作或节点 |
| 活动节点 | 除了动作以外的其他活动信息 |
活动划分或泳道：活动划分将一个活动图中的活动元素分组，每一组的上方表明该组元素所属对象，这样很容易通过划分看到活动的参与者。
活动边分类：
- 当活动边连接的是两个动作时，这种活动边称为控制流(Control Flow)
- 对象流：当活动边连接动作与数值或活动与数值时。用于描述活动中数据输出输入。
活动节点
- 参数节点
- 对象节点（表示活动中移动的数据）
- 控制节点
-
起始节点：活动的开始节点
-
判断节点：通过布尔值的不同选择不同输出流
-
汇合节点：两个输入边不需要同时到达汇合节点
-
分叉节点：一个动作在该店点同时并行产生多个并发活动边
-
结合节点：多个并发活动在该点产生正确的返回值后，再一起传递给该节点的唯一输出边
-
终点节点
-
2.3.Ⅱ.6交互概要图
交互图：描述的是对象之间的动态合作关系以及合作过程中的行为次序。. UML 交互图常常用来描述一个用例的行为，显示该用例中所涉及的对象以及这些对象之间的消息传递情况，即一个用例的实现过程。
例题：
UML图中适合描述单个用例中多个对象之间的协作行为的是（ 交互图 ）；适合描述跨越多个用例的单个对象的行为的是（ 状态图 ），适合描述多个对象跨越多个用例时的总面貌的是（ 活动图 ）
2.3 构架
“4+1”View Model：指从5个不同视角来描述软件体系结构。
| “4+1”分别指 | 各自含义 |
|---|---|
| ①逻辑视图logical view | 重点展示对象和类是如何组成系统、实现所需系统行为的。 |
| ②进程视图process view | 是逻辑视图面向进程的变体，将系统中的可执行线程进程作为活动类进行建模表达系统性能、可伸缩性和吞吐量等性质。 |
| ③实现视图implementation view（物理视图） | 对组成基于系统的物理代码的文件和组件进行建模，以示组件之间的依赖。 |
| ④部署视图deployment view（开发视图) | 系统的拓扑结构。 |
| ⑤场景/用例视图use case view | 描述项目需求，以上所有图都是用例视图派生而得。 |
逻辑视图通常刻画架构方面内容，其描述可以围绕前四个视图进行组织，然后结合用例或场景进行说明，形成第五个视图（每个视图只关心系统的一个侧面，5个视图结合起来，才能反映系统的全部内容）。
在 ROSE中，顺序图和协作图（或通信图）通常建立在逻辑图下的use case realization包中。
例题步骤：
①找出系统外部参与者，确定系统边界和范围
②确定各参与者所期望的系统行为
③把这些系统行为命名为用例
④确定用例之间的关系
⑤绘制用例图
⑥描述事件流
- UML中顺序图和协作图可以相互转换，因为协作图和序列图表达的信息一样，只是方法不同而已。
| 协作图 | 顺序图 |
|---|---|
| 明确表示了角色关系，通过协作角色来限定协作中的对象或链 | |
| 不将时间作为单独的维来表示，必须使用顺序号来判断消息的顺序以及并行线程 | 强调消息调用的时间顺序 |
| 协作图侧重对象间的关系，时间顺序可以从对象流经的顺序编号中获得 | 序列图侧重时间顺序 |
| 协作图被用于过程的详细设计 | 序列图被用于表示方案 |
- 关于用例建模的适用情况
| 适合用例建模的情况 | 不适合使用用例建模的情况 |
|---|---|
| 系统由功能需求所主导 | 系统有非功能需求所主导 |
| 系统具有很多类型的用户，系统对他们提供不同的功能 | 系统具有很少的用户 |
| 系统具有很多接口 | 系统具有很少的接口 |
（补充）非功能性需求（Robert Grady软件质量准则“FURPS”，也就是以下这些人为不可操控）：
①功能性（Functionality）
②使用性（Usability）
③可靠性（Reliability）
④性能（Performance）
⑤可支持性（Supportability）
- 面向对象分析和设计（OOA,OOD,OOP,OOT）
首先，OO(object-oriented)的概念为:基于对象概念,以对象为中心,以类和继承为构造机制,来认识,理解,刻画客观世界和设计,构建相应的软件系统的一门方法。
| 分类 | 内容 |
|---|---|
| OOA(object-oriented analysis，面向对象分析) | 其实就是进一步对oo进行细化,初步得出该oo的属性与方法(或者简单的理解:在得出的文档中对接口的粗略定义) |
| OOD(object-oriented design，面向对象设计) | OO方法中一个中间过渡环节,其主要作用是对ooa分析的结果作进一步的规范化整理，以便能够被OOP直接接受------整理和定义oo的属性和方法 |
| OOP(object-oriented programming，面向对象语言) | 把组件的实现和接口分开，并且让组件具有多态性----(抽象,继承,封装,多态)面向接口编程 |
OOA面向对象分析方法的五个基本步骤
①识别对象：包括标识潜在的对象和筛选对象两步
②识别对象的属性
③识别对象的行为
④识别对象所属的类
⑤定义主题词
例题：关于面向对象分析（OOA）与设计（OOD）的描述中，正确的是：分析构建的模型比较小，设计构建的模型比较大。
- 子系统
概念：子系统是一种模型元素，它具有包（其中可包含其他模型元素）和类（其具有行为）的语义。 子系统的行为由它所包含的类或其他子系统提供。 子系统实现一个或多个接口，这些接口定义子系统可以执行的行为。在UML2.0中，子系统是组件的一个特别版本。
例题：包与子系统
①包和子系统都有容器的含义，即都可以包含其他模型元素。
②二者都可以对外提供行为，包是通过其包含的公共可见性的类的公共方法，子系统则是通过接口提供对外行为。
③子系统良好的封装性使得它和包相比具有更好的可复用性。
-
受控单元（controlled unit）
Controlled Unit是可以进行版本控制的模型元素，在ROSE中，模型文件本身被打包存储为.mdl文件从而成为受控单元，Component View则被打包成.sub文件而成为受控单元。
①受控单元是指可以进行版本控制的模型元素。
②包是可以作为受控单元的最小元素。
③受控单元可以根据需要被加载到工作空间或从工作空间卸载。 -
场景、用例、用例图的关系
场景是用来描述用户和系统之间交互的顺序的步骤。
用例是为了达到某一用户目标而组合在一起的一组场景。
用例图用来显示在系统（或其它实体）内的用例与系统参与者之间的关系。 -
model的概念：对复杂事务的简化，通过建立模型可以对目标系统进行可视化描述，详细描述其静态结构和动态行为，提供构造系统的模板，并且可以作为文档记录在分析设计系统中做出的种种决策。
-
diagram的概念：由建模元素和关联关系组合在一起来表达一定的内容。
例题：
模型与图的关系？
模型是利用视图和图来构建的，其中视图刻画了系统的不同透视内容，即从不同角度对系统进行观察得到的内容；图用来刻画系统的构造块，是一种刻画系统类、接口、合作、组件、节点、依赖、泛化、关联关系等部件的图形工具。
- 类中的三种构造型
①界面类：用来描述系统与外界之间交互的系统要素，也称为边界类。用界面类封装了系统和外界环境之间的交互后，如果外界环境与系统交互方式发生了变化，例如其他系统的通信方式、协议发生改变，只需要修改界面类即可，即将系统内部与外部进行了有效的隔离。
②实体类：一般对应着在业务领域中的客观事物，是对系统内重要的数据信息及其操作，或业务逻辑运算进行封装。实体类一般处于被动状态，不会主动与界面类和控制类对象进行交互。实体类是一种很好的复用单元，可以再同一业务领域内的多个系统间进行复用。
③控制类标识系统用来进行调度、协调、处理，以及业务处理的系统要素。通过控制类对象协调边界类和实体类对象完成当前用例的行为。控制类的作用使得界面类和实体类独立于用例的执行逻辑。 - 用例实现（Use-case realization）：是设计模型中的元素，说明了一个用例是如何实现其行为的。
用例实现中包含的工件（artifact）有：
①静态类图：刻画参与一个用例的一组对象所属的类及类间的关系。
②动态交互图：刻画参与一个用例的一组对象之间的动态交互关系，具体可以是顺序图、协作图。
用例实现与用例之间的关系 ：用例实现对应于设计模型下的元素，是对用例的实现，二者之间是实现关系，建立了设计模型到用例模型之间的追溯关系。 - 抽象、封装、模块化是面向对象的基本原则。
- 面向对象的三个基本特征是：封装、继承、多态。
- 设计模式：一般分为三类——创建模式、结构模型、行为模式。
创建型模式包含：1、FactoryMethod(工厂方法模式)；2、Abstract Factory(抽象工厂模式)；3、Singleton(单例模式)。4、Builder(建造者模式、生成器模式)。5、Prototype(原型模式).
结构型模式包含：6、Bridge(桥接模式)；7、Adapter(适配器模式)；8、Decorator(装饰模式)；9、Composite(组合模式)；10、Flyweight(享元模式)；11、Facade(外观模式)；12、Proxy(代理模式).
行为模式包含：13、TemplateMethod(模板方法模式)；14、Strategy(策略模式)；15、State(状态模式)；16、Observer(观察者模式)；17、Memento(备忘录模式)。18、Mediator(中介者模式)；19、Command(命令模式)。20、Visitor(訪问者模式)；21、Chain of Responsibility(责任链模式)；22、Iterator(迭代器模式)；23、Interpreter(解释器模式).
| 模式名称 | 概述 |
|---|---|
| 创建型模式 | |
| Factory Method | 定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。 |
| Abstract Factory | 提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们详细的类。 |
| Singleton | 保证一个类仅有一个实例。并提供一个訪问它的全局訪问点。 |
| Builder | 将一个复杂对象的构建与它的表示分离。使得相同的构建过程能够创建不同的表示。 |
| Prototype | 用原型实例指定创建对象的种类，而且通过拷贝这个原型来创建新的对象。 |
| 结构性模式 | |
| Bridge | 将抽象部分与它的实现部分分离，使它们都能够独立地变化。 |
| Adapter | 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类能够一起工作。 |
| Decorator | 动态地给一个对象加入一些额外的职责。就扩展功能而言， Decorator模式比生成子类方式更为灵活。 |
| Composite | 将对象组合成树形结构以表示“部分-总体”的层次结构。Composite使得客户对单个对象和复合对象的使用具有一致性。 |
| Flyweight | 运用共享技术有效地支持大量细粒度的对象。 |
| Facade | 为子系统中的一组接口提供一个一致的界面。 Facade模式定义了一个高层接口，这个接口使得这一子系统更加easy使用。 |
| Proxy | 为其他对象提供一个代理以控制对这个对象的訪问。 |
| 行为型模式 | |
| Template Method | 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类能够不改变一个算法的结构就可以重定义该算法的某些特定步骤。 |
| Strategy | 定义一系列的算法,把它们一个个封装起来, 而且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。 |
| State | 同意一个对象在其内部状态改变时改变它的行为。对象看起来似乎改动了它所属的类。 |
| Observer | 定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,全部依赖于它的对象都得到通知并自己主动刷新。 |
| Memento | 在不破坏封装性的前提下。捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。 |
| Mediator | 用一个中介对象来封装一系列的对象交互。中介者使各对象不须要显式地相互引用，从而使其耦合松散，而且能够独立地改变它们之间的交互。 |
| Command | 将一个请求封装为一个对象。从而使你可用不同的请求对客户进行參数化。对请求排队或记录请求日志，以及支持可取消的操作。 |
| Visitor | 表示一个作用于某对象结构中的各元素的操作。它使你能够在不改变各元素的类的前提下定义作用于这些元素的新操作。 |
| Chain of Responsibility | 为解除请求的发送者和接收者之间耦合。而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。 |
| Iterator | 提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。 |
| Interpreter | 给定一个语言, 定义它的文法的一种表示，并定义一个解释器, 该解释器使用该表示来解释语言中的句子。 |
- RUP
| RUP中将软件生命周期划分的阶段 | 每个阶段所完成的工作 |
|---|---|
| 初始阶段Inception | 不是需求分析而是可行性分析 |
| 细化阶段Elaboration | 不是需求分析或设计过程，而是迭代式实现核心体系结构，缓解高风险问题 |
| 构造阶段Construction | 实现遗留下来的风险较低和比较容易的元素，准备部署 |
| 移交阶段Trasition | 测试，部署 |
- 在使用rose的时候.rose的类里面有个stereotype的选项.选择了不同的选项类会呈现不同的图形效果。stereotype可以用来扩展uml元素的语义。
- 软件体系结构：是指一个系统的有目的的设计和规划，这个设计规划既不描述活动，也不描述系统怎样开发，它只描述系统的组成元素及其相互的交互协作。
- 一个UML模型只描述了一个系统要做什么，它并没有告诉我们系统怎么做。
- 型构（signature）:在操作名后面的括号中可以说明操作所需要的参数和参数的类型。 有一种操作叫函数，它在完成操作后要返回一个返回值。 上述全部的操作信息被称为操作的型构。
- OMT方法
OMT是Object Modeling Technique的缩写, 意为对象建模技术.
1991年，James Rumbaugh在<<面向对象的建模与设计>>一书中提出了面向对象分析与设计OMT方法。
OMT方法的OOA模型包括对象模型、动态模型和功能模型。 - 多对象是UML 协作图 中的概念。
- 具有多重属性值的UML图形包括类图、部署图。
- 顺序图、实现图（构件图、部署图）可以清楚地表达并发行为。
- 方法、工具、过程是软件工程的三要素。
- 状态机
状态机是对系统行为中受事件驱动的方面进行建模，状态机专门用于定义依赖于状态的行为(即根据模型元素所处的状态而有所变化的行为)。
①状态机由状态组成，各状y态由转移链接在一起。
②可能具有状态机的对象包括:类、子系统、用例、接口(以声明实现该接口的对象必须满足的状态)和协议(以声明实现该协议的对象必须满足的状态)。
③状态机最多地用于建立对象在其生命期内的行为模型。当对象具有依赖于状态的行为时，尤其需要使用状态机。 - RUP（Rational Unified Process)：统一软件开发过程的四个阶段
①初始阶段
②细化阶段
③构造阶段
④提交阶段 - 一个对象和另一个对象之间，通过消息来进行通信。消息通信在面向对象的语言中即方法调用。
- 用例图流程：用例描述；用例分析；识别对象；设计类图；设计顺序图