第一章 UML简介
Rose支持的开发视图及其作用：
1. Business Use Case框图
表示整个机构提供的功能。用来设置系统情景和形成创建用例的基础。它显示了业务用例和业务角色之间的交互。业务用例表示公司执行的过程，业务角色表示业务要交互的对象。
2. Use Case框图
表示用例和角色间的交互。用例表示从用户角度对系统的要求，因此表示系统功能。角色是系统主体，表示提供和接收系统信息的人或系统。这种框图西那是哪个角色使用用例，并显示角色何时从用例收到信息。
业务用例和用例并非一一对应。
3. Activity框图
描述工作流。
4. Sequence框图
显示用例的功能流程。框图顶部显示涉及的角色和对象，每个箭头表示角色与对象或对象与对象之间为完成所需功能而传递的消息。只显示对象而不显示类。
5. Collaboration框图
内容与Sequence相同，但表现形式不是按照时间顺序，而是根据对象平铺。
6. Class框图
显示类的内容和相互关系。
7. Statechart框图
对复杂对象，可能包含多个状态。使用该框图来描述多个状态之间的转换关系。
8. Component框图
描述模型的物理视图，显示系统中软件组件及相互关系。一个.h文件是一个组件，一个.cpp文件是一个组件，一个.exe也是一个组件。通过该框图描述它们之间的依赖关系。一般一个可执行文件及其所依赖的源文件对应着一个Component框图。
9. Deployment框图
描述网络的物理布局和各个组件的位置。
RUP（Rational Unified Process）的四个阶段和所使用的框图
1. 开始
收集信息和进行概念验证。使用Business Use Case框图、Use Case框图。
2. 细化
细化用例和作出结构性决策。分析、设计、编码和测试。使用Use Case框图、Activity框图、Sequence框图、Collaboration框图、Statechart框图、Component框图。
3. 构造
编码。使用之间产生的框图，通过正、逆向工程。使用Deployment框图。
4. 交接
向用户进行最后的准备和部署阶段。更新Component和Deployment框图。
第二章 Rose之游
本章简介了Rose的界面使用方法。
模型的作用
1. 小组使用Business Use Case框图了解系统针对的业务
2. 客户和系统管理员使用Use Case框图取得系统的高级视图，确定项目范围
3. 项目管理员使用Use Case框图和文档分解项目
4. 分析人员和客户使用Use Case文档了解系统提供的功能
5. 技术作者使用Use Case文档编写用户手册和培训计划。
6. 分析人员和开发人员使用Sequence和Collaboration框图了解系统的逻辑流程、系统中对象和对象间消息。
7. 测试人员使用Use Case文档和Sequence、Collaboration框图编写测试脚本
8. 开发人员使用Class框图和Statechart框图取得系统各个部分的细节及相互关系。
9. 部署人员用Component和Deployment框图显示姚创建的可执行文件、DLL文件和其它组件以及这些组件在网络上的部署位置
10. 整个小组使用模型确保代码遵循了需求，代码恶意回溯到需求。
11. 使用正向过程和逆向过程保证模型和代码的同步。
Rose模型的四个视图
1. Use Case视图：
包含系统中的所有角色、使用案例和Use Case框图，还可能包含Sequence框图和Collaboration框图。Use Case视图是系统中与实现无关的视图，它关心系统功能的高级形状，而不关心系统的具体实现方法。
通过Use Case视图，测试人员可以编写测试脚本，技术作者可以编写用户文档，分析人员和客户可以确认获得的所有需求，开发人员可以看到系统创建哪些高级组件、系统逻辑如何。
2. Logical视图：
关注系统如何实现用例中提出的功能。它关注的焦点是系统的逻辑结构，要标识系统组件，检查系统的信息和功能，检查组件之间的关系。一般为开发人员和架构师使用。
Interaction框图可以在Use Case视图中出现，也可以在Logical视图中出现。前者重的Interaction框图显示高层结构，独立于实现。例如其中可以有分析类，这是独立于语言的类。而后者重的Interaction框图则基于具体的语言实现，其中的类是设计类。分析类可以对应着多个设计类。
3. Component视图：
主要用户是负责控制代码和编译部署应用程序的人，描述了代码、组件、可执行文件组织的物理结构。
4. Deployment视图：
关注系统的实际部署，可能与系统的逻辑结构不同。
第三章 业务模型
本章介绍业务本身，与业务交互的实体和设计系统之前业务环境中真正进行的工作流。
业务模型概念
业务模型研究机构。在建立业务模型的过程中，要检查机构的结构及公司的角色和它们之间的相互联系。还要介绍结构的工作流；公司中的主要过程；这些过程如何工作；效率如何；是否有瓶颈。业务模型关心以下两个方面：第一，机构的边界和它要与谁通信？第二，机构中的工作流及如何优化机构中的工作流？
业务模型包括以下概念：
1. 业务角色
是系统外部和系统交互的一切。每个角色都和公司的活动有关。
2. 业务工人
是机构中的角色。是角色而不是位置，一个人可以扮演多个角色，而只能处于一个位置。
3. 业务用例
业务用例是机构中的一组相关工作流，对业务角色有用。业务用例告诉人们机构做什么，以及做什么会有利于业务和参与人员的工作。机构中的全部业务用例一起完整的描述业务目标。
业务用例可以使用两种方式建档描述，一种是文字脚本，另一种是活动框图（下面介绍）。
4. Business Use Case框图
显示机构的业务用例、业务角色、业务工人及之间的相互交互；提供了公司的工作、公司内的角色与公司外的角色的完整模型；指定了机构的范围，可以看到机构的内容和边界。
5. Activity框图（活动框图）
以图例方式显示用例的工作流。
1) 实心点表示开始状态
2) 导角矩形称为活动。活动是工作流中的步骤，是业务工人要完成的任务。活动中包含多个操作：
a) 进入活动时发生的操作，标有entry
b) 活动进行时发生的操作，直到离开活动，标有do
c) 离开活动时发生的操作，标有exit
d) 特定事件发生时的操作，标有event和事件名。
3) 根据业务角色和业务工人分为多个泳道。
4) 活动中包含多个操作。列在活动（导角矩形）中。
5) 菱形表示分枝
6) 水平线称为同步。
7) 一般矩形表示对象。这些对象受工作流影响，在工作流执行中改变状态。
6. 业务实体
机构经营业务期间使用的对象或业务过程中产生的对象。
7. 机构单元
是业务工人、业务实体和其它业务模型单元的集合，是组织业务模型的机制。
建立业务模型的步骤
1. 标识业务角色
2. 标识业务工人
3. 标识业务用例
4. 显示交互（前面三者之间的交互），使用Business Use Case框图
5. 建档细节，包括使用活动框图描述业务用例，使用业务用例报表描述用例的其它信息。
使用Rose创建业务模型的一些技巧
1. 使用Tools->Options->Toolbar中添加框图左边的工具
2. 添加项一般只要将工具栏中的图标拖入框图。
3. Delete只是在框图中删除，浏览区中依旧保存；彻底删除需要使用Ctrl+D。
4. 浏览区中一项的下级枝叶不表示包含关系，如果另一项跟该项相关，则会列在该项的枝叶中。
5.Query菜单中可以添加、管理项
6. Report菜单中可以查看项的属性
7. 浏览区的Associations下面描述了所有关系，关系的枝叶是关系的相关项。
8. Organization Unit是Packet的一个构造型，似乎没有什么特别的，除了图标。
9. 具体操作参考书本，只要明晓各个概念和其功能，则很容易使用Rose操作。
第四章 用例和角色
用例包括系统内的一切，角色包括系统外的一切
业务用例模型和系统用例模型的区别
1. 用例在业务模型中描述业务的工作，在系统模型中描述业务中系统的工作。
2. 角色在业务模型中是在机构之外，在系统模型中是在系统之外，但可能在结构之内。
3. 业务工人在业务模型中在机构之内，在系统模型中不使用。
4. 业务用例跟系统用例并非一对一。业务用例一般是高级的，一个业务用例经常对应多个系统用例。每个系统用例都可以回溯到一个业务用例，而不是所有业务用例都有系统用例支持。
系统用例模型中的主要概念
角色
角色是与所建系统交互的人或物，描述系统范围外的一切。角色有三大类：系统用户、与所建系统交互的其它系统和时间。
用例
用例是系统提供的功能块，它演示人们如何使用系统。通过用例，能够将系统实现和系统目标分开。开发人员可以了解用户的需求和期望，用户可以了解系统提供的功能。
用例独立于实现、是系统的高级视图、只关心系统外的用户。
事件流
事件流用来描述用例的细节，建档用例的逻辑流程。它详细描述了系统用户的工作和系统本身的工作。它虽很详细，但独立于实现方法。
事件流通常包括：
1. 简要说明
描述了该用例的作用，应包含执行用例的不同类型用户和用户通过这个用例要达到的最终结果。
2. 前提条件
列出开始用例之前必须满足的条件。因为Use Case框图并不描述用例执行的顺序，前提条件可以描述这种顺序。
3. 主事件流
4. 其它事件流
事件流可以使用文本方式、表格方式和活动框图的方式。事件流的模式：用户进行操作，系统作出响应；然后用户再操作，系统再响应；一直重复下去。
5. 事后条件
是用例执行完毕后必须为真的条件。和前提条件一样，事后条件可以增加用例顺序方面的信息。
关系
描述角色和用例之间的关系。分为下列关系
1. 包含关系
是一个用例的功能可以在另一个用例中使用。表示为虚箭头加<<include>>字样。
2. 扩展关系
允许一个用例（可选）扩展另一个用例的功能。表示为虚箭头加<<extend>>字样。
3. 泛化关系
Use Case框图
显示了系统中用例与角色及其相互关系。
有下列注意事项：
1. 不要建模角色与角色之间的关系。
2. 不要在两个用例之间直接画箭头。
3. 每个用例都应该由角色启动。
4. 可以把数据库成整个Use Case框图下面的层。
活动框图
用来建模用例的事件流。类似于前一章业务建模中的活动框图。
使用Rose创建系统用例模型的几个技巧
1. 浏览角色实例的方法：选中一个角色，然后Report->Show Instances。会列出角色所在的Sequence框图和Collaboration框图。
2. 浏览用例关系的方法：选中一个用例，然后Report->Show Usage，会列出关系名和关系连接的项名。
3. 浏览用例参与者的方法：选中一个用例，然后Report->Show Participants in UC，列出用例包含的类。
4. 活动框图一般在用例下面创建，即作为用例的枝叶。
第五章 对象交互
介绍如何建模系统对象之间的交互。
Interaction框图
它一步一步显示用例的流程。包括：流中需要什么对象；对象相互发送什么消息；什么角色启动流；消息按什么顺序发送。每个用例一般对应多个Interaction框图，每一个对应事件流中的一种情形。事件流的信息可以从用例模型中的Activity框图获得。
Interaction框图包含角色、对象和交互的消息。有两种Interaction框图：Sequence框图和Collaboration框图。前者按时间排序，用于通过情形检查逻辑流程；后者平铺对象，很容易看出哪个对象和哪个对象进行通信。前者可以显示控制焦点，后者可以显示数据流。二者功能基本相同，只是表现形式不同。
创建Interaction框图的流程：
1. 寻找对象
对象包括以下类型
1) 实体对象。这些对象保存信息，并最终可能映射数据库中的表和字段。
2) 边界对象。位于系统和外部世界之间的边界上。它包括系统的窗口/窗体和对外界的接口。
3) 控制对象。控制用例的流程，协调其它对象和控制总体逻辑流程。
可以看出，这是一种基于MVC的寻找对象方式。
2. 寻找角色
Interaction框图中的角色时对事件流启动工作流的外部刺激。每个在特定情形下接收和发送系统消息的角色都在该情形的框图中显示。
3. 将消息加进框图
包括对象之间的交互消息和对象与角色之间的交互消息。
Interaction框图的两步法
第一步，关注客户关心的高级信息，消息不映射操作，对象不映射类。只是为了让分析人员、客户和对业务流程感兴趣的其他人了解系统的逻辑流程。
第二步，客户同一第一步框图的流程之后，小组加进更多细节。消息映射操作，对象映射类。并设置一些详细的对象和消息的属性。对开发人员、测试人员和项目组其他人员作用比较大。
Sequence框图
每个用例有几个流程，每个Sequence框图对应用例的一个流程。
每个对象都有一条生命线，就是对象下面的竖虚线。初始化对象时生命线开始，删除时生命线结束。两个对象的生命线之间画一条消息，表示对象通信。每个消息表示一个对象向另一个对象进行函数调用。消息可以自反。
生命线可以通过“X”结束。
一般而言，一个流程对应着一个Sequence框图。但有时为了减少框图数量，在框图中使用脚本指定if和else。但太多if，else会导致不明了，所以还是尽量不用。脚本在rose中就是一个text框。
Collaboration框图
相对Sequence框图，容易看出对象之间的关系，但对象顺序信息不明显。
关于对象的说明
每个对象可以指定一个类，而且应该指定一个类。
对象的持续性可以有三种选择：
1. 持续，表示对象保存在数据库或其它形式的永久存储体中。
2. 静态，表示对象在程序运行期间一直保存在内存中。
3. 临时，表示对象只是短时间保存在内存中。
Rose可以用一个图标表示同一个类的多个实例，在Sequence框图中使用单图标实例，在Collaboration中可以使用多图标实例。
关于消息的说明
消息可以指定一个类的操作。如果要指定，之前必须确保接收对象映射为一个类。
消息有如下同步选项：
1. 简单。用于单控制线程。
2. 同步，客户发出消息后，等待供应者响应该消息。
3. 阻止：客户发出消息给供应者，如果供应者无法立即接收消息，则客户放弃该消息。
4. 超时：客户发出消息给供应者并等待指定时间。如果供应者无法在指定时间内接收消息，则客户放弃该消息。
5. 异步：客户发出消息给供应者，然后客户继续处理。
6. 过程调用：客户向供应者发消息，然后客户机等待处理消息的整个嵌套顺序完成之后才能继续（？？？）
7. 返回：表示从过程返回调用。
消息频率有两个选项：
1. 定期发送
2. 不定期发送，即只发送一次。
使用Rose操作Interaction框图的技巧
1. 加入对象有两种方法：一是将框图工具栏中的对象图标拖拉入框图；二是将浏览区中的类直接拖入框图，会产生一个该类的匿名对象。
2. 删除对象：使用Ctrl+D。
3. 加减角色：将流量区中的对象拖入框图和Ctrl+D。
4. 将对象映射为类的两种方法：一是在Specification中指定class，二是直接将class拖到对象中。
5. 确保所有对象映射类：Report->Show Unresolved Objects。
6. 使用F5保持Sequence框图和Collaboration框图的同步。
7. 设置框图属性：Tools->Options->Diagram。
第六章 类和包
介绍类本身及如何组成包。
寻找类的方法
两种方法：
1. 从用例的事件流发现类。事件流中的名次分为角色、类、类属性和其它四类。
2. 从Interaction框图发现类。通过框图中对象的共性寻找类。框图中的每个对象都有映射到相应的类。
对应这两种方法，存在先建立类框图和先建立Interaction框图两中建模路径。
1. 先建Interaction框图：优点是可以一步一步认真检查完成事件流所需要的对象，确保使用每个类。Sequence框图是很好的组织方法，可以根据需要创建与删除对象，不限于已经定义的类清单。缺点是不同小组使用不同方法设计框图，导致类责任的重叠。
2. 先建Class框图。优点是在生成Sequence框图之前确定体系结构层和通讯模式。后面生成Sequence框图，只要符合Class框图，就不会破坏体系结构。但限制太严。
个人认为，个体开发可以使用方法1，因为便于理清思路，形成所需要的类。而且从事件流到Sequence框图过渡会比较自然。
类的版型
版型机制可以将类进行分类。分析过程中，可以根据功能将类进行分类。UML中有三种基本类版型用于分析：边界、实体和控制。
边界类
边界类位于系统和外界的交界处、包括所有窗体、报表、打印机、扫描仪等硬件的接口以及与其它系统的接口。
要寻找和定义边界类，可以检查Use Case框图。每个角色/用例交互至少要有一个边界类。边界类使角色能与系统交互。
并非每个角色/用例对都要创建唯一边界类，可以共用。
实体类
实体类保存要放进永久存储体的信息。可以查看事件流中的名词，其中许多都是系统中的实体类。另一种方法是检查数据库结构。如果已经完成数据库设计，则可以看表名。每个表要创建一个实体类。表中永久保存记录信息，而实体类在系统运行时在内存中保存信息。
控制类
负责协调其它类的工作，每个用例通常有一个控制类，控制用例中的事件顺序。
控制类本身不完成任何功能，其它类并不向控制类发送许多消息，而是由控制类发出许多消息。控制类只是向其它类委托责任。控制类有权知道和执行机构的业务规则，可以运行其他流和知道在发生错误时如何处理。为此，控制类也称为管理者类。
控制类可以被多个用例共用。
类的类型
除了一般类外，还有
1. 参数化类
2. 实例化类
3. 类实用程序
4. 参数化类实用程序
5. 实例化类实用程序
6. 接口
类的其它特性
可见性
1. Public
2. Protected
3. Private
4. Package或Implementation
类基数
表示类的实例数
类的存储需求
表示每个类对象要求的相对或绝对内存量。
类持续性
1. Persistent：类对象存放在数据库或别的永久存储体横纵
2. Transient：类对象不存放在永久存储体中
类并发性
1. Sequential：只有一个控制线程时，类会正常工作。不保证多线程仍然正常工作。
2. Guarded：存在多个线程时，类正常工作。但不同线程中的类应该相互协作，保证不会相互干扰。
3. Active：类有自己的控制线程
4. Synchronous：存在多个线程，类正常工作不需要与其它类协作，因为类本身能处理互斥情形。
抽象类属性
包
使用包将功能相近的类集合在一起，可以便于管理。
使用Rose建立和管理类/包的技巧
1. Format->Layout Diagram可以对齐框图中的项。Format->Autosize All可以调整框图中项的大小。
2. 浏览包含类的Interaction框图的方法：Report->Show Instances
第七章 属性与操作
寻找属性的方法
属性的来源包括事件流、需求文档、用例文档、数据库结构。
属性的规范
数据类型
可以是内置数据类型，也可以是用Rose模型中定义的类名。
属性版型
属性初始值
属性可见性
1. Public：所有其它类可以访问
2. Private：其它类无法访问
3. Protected：类及其子孙类可以访问
4. Package或implementation：表示对该包内的类公开。
属性控制
描述属性如何存放在类中
1. By value：属性存放在类中
2. By Reference：属性放在类外，属性的引用或指针存放在类中
3. Unspecified：未指定。
静态属性
派生属性
派生属性是从一个或几个属性创建出来的属性。UML中，派生属性前加/。
寻找操作的方法
寻找操作很简单，创建SequenceCollaboration框图时，就完成了寻找操作的主要工作。要考虑四种不同类型的操作：实现者、管理者、访问和帮助器。
1. 实现者操作：每个操作来自Interaction框图中的消息，而这些消息来自事件流的细节，事件流来自用例，用例来自需求。
2. 管理者操作。管理者操作管理对象的创建和构造。
3. 访问操作。用来获得属性和修改属性。
4. 帮助器操作。类完成任务所需的操作，其它类不需要知道这个操作。
操作的规范
操作版型
1. Implementor：实现某种业务逻辑的操作
2. Manager：构造器、析构器和内存管理操作
3. Access：让其它类浏览或编辑属性的操作
4. Helper：一个类的专用或保护操作，其它类无法访问
它们都不是Rose自动提供的，需要自己设置。
操作可见性
1. Public
2. Private
3. Protected
4. Package或implementation
变元默认值
操作协议
操作协议描述客户可以对对象进行操作，以及操作执行的顺序。
操作限定
指定操作的语言特定限定。
操作异常
操作Exceptions字段可以列出操作可抛出的异常
操作长度
Size字段指定操作运行时所需的内存量
操作时间
执行该操作所需的大概时间量
操作并发性
指定多控制线程中的操作行为。有三个选项：
1. Sequential：只有一个控制线程时，操作正常工作。另一个操作运行前，这个操作必须完成。
2. Guarded：存在多个控制操作，但不同线程中的类应相互协作，保证不出现干扰，操作才能正常运行。
3. Synchronous：存在多个控制线程时，操作正常运行。调用时，操作在一个线程中运行到完成，但其它操作可以在其它线程中同时运行。类正常工作，不需要与其它类相互协作，因为类本身处理互斥情形。
操作前提条件
运行操作之前必须符合的条件。
操作事后条件
运行操作之后要符合的条件。
操作词法
指定操作的工作。可以使用伪代码，或文字说明。或一个Interaction框图。
使用Rose处理属性和操作的方法
1. 默认属性可见性图标是Rose图标而不是UML图标。修改办法是：Tools->Options->取消Visibility as Icons。
2. 将操作映射为Collaboration图中消息的方法：先决条件是消息指向的对象必须已经映射到某个类。在消息操作规范中指定name为目标类的一个操作或者右键消息中选择目标类的一个操作。新建消息对应的操作可以在类中新建，也可以右键消息，然后选择<new operation>。
3. 显示/隐藏属性的方法：
1) 显示所有属性：右键类弹出菜单，Options->Show All Attributes
2) 显示类的所选属性：右键类弹出菜单Options->Select Compartment Item，Edit Compartment窗口的所要属性。
3) 抑止一个类的属性：右键类弹出菜单，Options->Suppress Attributes。抑止与隐藏的区别是前者连分隔线也不显示。
4) 改变显示属性的默认选项：Tools->Options->Diagrams->用Suppress Attributes和Show All Attributes复选框设置默认选项。
5) 对操作的显示/隐藏方法类似。
4. 类的右键菜单中Options下面还可以设置可见性、版型的显示/隐藏。