1. UML概述 地位、产生、定义
   1. 软件开发方法的演变
      1. 没有方法
      2. 功能分解法
         1. 代码级
      3. 数据流法
         1. 企业级
         2. 系统是数据加工机
      4. 信息建模法
         1. 面向数据
         2. 数据与责任分离
      5. 面向对象法
         1. 数据与责任结合
         2. 描述现实世界
   2. 面向对象方法
      1. OOAD
         1. Object-oriented analysis and design
      2. 90年代初，有一定影响力的OOAD方法有50多种
   3. （统一为）UML
      1. Unified Modeling Language
      2. 模型
         1. 现实的简单化
         2. 建模
            1. 建模是为了理解某件事物是否能够正常工作
            2. 建模是为了能够更好地理解我们正在开发的系统
      3. UML定义
         1. UML是一种绘制软件蓝图的标准语言
         2. 可以使用UML对软件密集型系统的制品进行以下工作
            1. 可视化 visualizing
            2. 详述 specifying
            3. 构造 constructing
            4. 文档化 documenting
      4. UML特点
         1. 统一标准
         2. 面向对象
         3. 可视化、表示能力强大
         4. 独立于过程
         5. 概念明确
      5. UML的9种图
         1. 用例图
            1. 业务建模、需求、测试
         2. 结构
            1. 类图
            2. 业务建模、分析、设计
            3. 对象图
            4. 业务建模、分析、设计
            5. 构件图
            6. 设计
            7. 部署图
            8. 设计
         3. 行为
            1. 序列图
            2. 业务建模、分析、设计
            3. 协作图
            4. 业务建模、分析、设计
            5. 状态图
            6. 需求、分析、设计
            7. 活动图
            8. 业务建模、设计
2. 面向对象基础与UML的组成
   1. 面向对象概念
      1. 面向对象的基本原理
         1. Object Orientation
            1. Abstraction
            2. 类或操作等项目的基本属性
            3. 一个项目的抽象依赖于你定义抽象的上下文
            4. 抽象是在项目周围绘制一个清晰框架的手段
            5. Encapsulation
            6. 把相关概念组合进一个项目中，如类或组件
            7. 封装描述了如何在系统中划分功能的问题
            8. 分装是把框体涂黑的做法
            9. Modularity
            10. 把复杂的事务分解成可以处理的部分
            11. 帮助人们更好地理解复杂系统
            12. Hierarchy
            13. is a
            14. 特殊类的对象拥有其一般类的全部属性和方法，称作特殊类对一般类的继承
            15. 分为单继承和多继承
            16. polymorphism
            17. 多态指的是使一个实体在不同的上下文条件下具有不同意义或用法的能力
            18. 多态是保证系统有较好的适应性的一个重要手段，也是用OO技术所表现出来的一个重要特征。
      2. 对象
         1. 特点
            1. 具有标识
            2. 具有状态
            3. 具有行为
      3. 对象和类
         1. 一个类表示一组相似的对象
         2. 对象是类的实例
         3. 属性是类知道的事情
         4. 方法是类完成的事情
      4. 类
         1. 具有相同属性和方法的一组对象的集合，它为属于该类的全部对象提供了统一的抽象描述，其内部包括属性和方法两个主要部分。
         2. 类的属性和操作
            1. 属性 attribute
            2. 操作 operation
            3. 是一个服务的实现，该服务可以由类的任何对象请求以影响其行为
         3. 特点
            1. 同类对象具有相同的属性和方法，是指它们的定义形式相同，而不是说每个对象的属性值都相同。
            2. 类是静态的 类的存在、语义和关系在程序执行前就已经定义好了。
            3. 对象是动态的 对象在程序执行时可以被创建和删除。
   2. 建模元素
      1. 包
         1. 包是用来组织UML模型的基本分组事物。它有变体，如框架、模型和子系统等（它们是包的不同种类）。
         2. 用包把建模元素安排成可作为一个组来处理的较大的组块：
            1. 一些元素在保外是可见的。
            2. 另一些元素要隐藏到包内。
      2. 消息
         1. 消息就是想对象发出的服务请求，它包含下述信息：
            1. 提供服务的对象标识
            2. 服务（方法）标识
            3. 输入信息
            4. 回答信息
   3. UML的组成
      1. 构造块
         1. 事物 是对模型中最有代表性的成分的抽象
            1. 结构事物
            2. UML模型中的名词，是模型中的静态部分，如类、接口、协作、用例、活动类、组件、节点
            3. 行为事物
            4. UML模型中的动词，是模型的动态部分，如交互、状态机、活动
            5. 分组事物
            6. 包，用于把模型分解成“盒子”
            7. 注解事物
            8. 用来描述、说明或标注模型的任何元素
         2. 关系 把事物结合在一起
            1. 关联
            2. 描述对象之间的一组链接
            3. 依赖
            4. 事物的改变引起依赖事物的语义改变
            5. 泛化
            6. 一个元素是另一个元素的特化，而且它可以取代更一般的元素
            7. 实现
            8. 类元之间的关系，一个类元说明一份契约，另一个类元保证实现该契约
         3. 图 聚集了相关的事物
            1. 类图 class diagrams
            2. 对象图 object diagrams
            3. 构件图 component diagrams
            4. 部署图 deployment diagrams
            5. 顺序图 sequence diagrams
            6. 协作图 collaboration diagrams
            7. 用例图 use case diagrams
            8. 状态图 statechart diagrams
            9. 活动图 activity diagrams
      2. 公共机制
         1. 规格说明 详述
         2. 修饰 修饰
         3. 公共分类 通用划分
         4. 扩展机制
      3. 规则
         1. 命名
            1. 为事物、关系和图起的名字
         2. 范围
            1. 使名字具有特定含义的语境
         3. 可见性
            1. 这些名字如何让其他成分看见和使用
         4. 完整性
            1. 事物如何正确、一致地互相联系
         5. 执行
            1. 运行或模拟动态模型的含义是什么
   4. 体系结构
      1. 可视化、详述、构造和文档化一个软件密集型系统，要求从几个角度去观察系统
         1. 1
            1. 用例视图 use case view
            2. 用例视图由描述可被最终用户、分析人员、测试人员看到的系统行为的用例组成。
            3. 用例视图实际上没有描述软件系统的组织，而是描述了形成系统体系结构的动力。
            4. 在UML中，该视图的静态方面由用例图表现；动态方面由交互图、状态图和活动图表现
         2. 4
            1. 设计视图 design view
            2. 设计视图包含了类、接口和协作，它们形成了问题及其解决方案的词汇。
            3. 这种视图主要支持系统的功能需求，即系统应该给最终用户的服务。
            4. 在UML中，该视图的静态方面由类图、对象图表现；动态方面由交互图、状态图和活动图表现
            5. 交互视图 interaction view
            6. 交互视图展示了系统的不同部分之间的控制流，包括可能的并发和同步机制。
            7. 该视图主要针对性能、可伸缩性、系统的吞吐量。
            8. 在UML中，对该视图的静态方面和动态方面的表现与设计图相同，但着重于控制系统的主动类和它们之间流动的消息。
            9. 实现视图 implementation view
            10. 实现视图包含了用于装配与发布物理系统的制品。
            11. 这种视图主要针对系统发布的配置管理，它由一些独立的文件组成；这些文件可以用各种方法装配，以产生运行系统
            12. 它也关于从逻辑的类和构件到物理制品的映射。
            13. 在UML中，该视图的静态方面由构件图表现，动态方面由交互图、状态图和活动图表现
            14. 部署视图 deployment view
            15. 部署视图包含了形成系统硬件拓扑结构的节点（系统在其上运行）。
            16. 这种视图主要描述组成物理系统的部件的分布、交付、安装。
            17. 在UML中，该视图的静态方面由部署图表现，动态方面由交互图，状态图和活动图表现
   5. Rose的使用
      1. 四个视图
         1. Use Case
            1. 用例图
            2. 顺序图
            3. 协作图
            4. 活动图
         2. Logical
            1. 类图
            2. 状态图
         3. Component
            1. 组件图
         4. Deployment
            1. 部署图
3. 用例图
   1. 定义 显示一组用例、参与者以及它们之间关系的图
   2. 应用
      1. 用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和行为，因此，对整个软件开发工程而言，用例图是至关重要的。
      2. 用例图定义和描述了系统的外部可见行为，是分析、设计直至组装测试的重要依据。
      3. 让用户参与前期的系统分析与设计。
   3. Use Case 对开发的意义
      1. 把需求、分析和设计、实现、测试绑到一起
   4. 组成
      1. 用例 Use Case
      2. 参与者 Actor
      3. 关系 Relationship
   5. 用例建模技术
      1. 识别参与者
         1. 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物。
         2. 参与者可能是人、另外一个系统、时间的流逝等
         3. 识别参与者的方法
            1. 谁使用系统的主要功能
            2. 谁改变系统的数据
            3. 谁从系统获取信息
            4. 谁需要系统的支持以完成日常工作任务
            5. 谁负责日常维护、管理并保证系统正常运行
            6. 系统管理员
            7. 系统需要应付（处理）那些硬设备
            8. 系统需要和那些外部系统交互
            9. 谁（或什么）对系统运行产生的结果（值）感兴趣
            10. 时间、气温等内部外部条件
         4. 参与者的泛化
      2. 识别用例
         1. 定义：一个用例定义一组用例实例。
            1. 用例实例是系统执行的一系列动作，这些动作将生成特定主角（参与者）可观测的结果值。
         2. 用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。
         3. 特点
            1. 用例描述了用户提出的一些可见的需求
            2. 用例可大可小
            3. 用例对应一个具体的用户目标
         4. 列出事件
            1. 外部事件
            2. 内部事件
            3. 来自系统内部和时间有关
            4. 主语+动词+（宾语）
         5. 识别用例的方法
            1. 特定参与者希望系统提供什么功能
            2. 系统是否存储和检索信息，如果是，由哪个参与者触发
            3. 当系统改变状态时，是否通知参与者
            4. 是否存在影响系统的外部事件，哪个参与者通知系统这些事件
         6. 注意事项
            1. 可观测 用例止于系统边界
            2. 用例描述交互，而不是系统的内在活动
            3. 结果值 用例是由意义的目标
            4. 系统执行 结果值由系统生成
            5. 由参与者观测 业务语言、用户观点
            6. 业务语言而非技术语言
            7. 用户观点而非系统观点
         7. 用例的命名
            1. 执行者视角
            2. （状语）动词+（定语+）宾语
         8. 要点
            1. 用例的粒度
            2. 用例要有路径，路径要有步骤；而这一切都是可观测的
            3. 最常犯错误：
            4. 粒度过细，陷入功能分解
            5. 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言
            6. 把步骤当用例
            7. 把系统活动当用例
            8. CRUD
            9. C(Create)
            10. R(Read)
            11. U(Update)
            12. D(Delete)
            13. 所有业务最终都会成为CRUD？
            14. CRUD能为Actor提供价值？
            15. CRUD掩盖业务，锐变成关系数据库的建模：
            16. “系统就是数据的增删改查”
            17. 关心数据的存储和维护，反而忽略了用户的目的
            18. 如果确实是CRUD？
            19. 如果CRUD不涉及复杂的交互，一个用例“管理××”即可
            20. 不管是C、R、U、D，都是为了完成“管理”目标
            21. 甚至很多种的基本数据管理都可以用一个用例表示
      3. 识别用例间的关系
         1. include
            1. Topic
            2. 包含关系把几个用例的公共步骤分离成一个单独的被包含用例。
            3. 即在一个用例中重用另一个用例中的步骤。
         2. extend
            1. Topic
            2. 扩展用例是在原用例的基础上增加新的步骤序列性成的。
            3. 原用例被称为基用例(base use case)。扩展只能发生在基用例的序列中的某个具体制定点上，这个点叫做扩展点(extension points)。
            4. 和包含的关系
            5. 在扩展关系中，基用例不必知道扩展用例的任何细节，事实上基用例没有扩展也是完整的，只有特定的条件发生了，扩展用例的行为才被执行，而包含关系则不同。
         3. generalization
            1. Topic
            2. 和类一样，泛化是指一个用例继承了另一个用例，在用例继承中，子用例可以从父用例继承行为和含义，还可以增加自己的行为。
            3. Topic
            4. 子用例可以出现在父用例出现的任何位置
         4. 绘图的建议
            1. 防止过度图形化
            2. 用例的重点在于书写文本，而不是图和用例关系，不要花很多小时甚至几天讨论用例图和用例关系
      4. 用例阐述
         1. 场景 scenario
            1. 是参与者和被讨论系统之间的一系列特定活动和交互。
            2. 每个用例是一组场景的集合，而每个场景又是一个步骤序列。
            3. 用例阐述文档针对每个用例，描述各个场景
         2. 最好由业务人员接受训练写出优美的用例文档
         3. 用例阐述组成
            1. 用例标识
            2. 用例名称
            3. 涉及的参与者
            4. 用例概述
            5. 前置条件Preconditions
            6. 在用例开始前系统的状态
            7. 把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件
            8. 说明在用例触发之前什么必须为真
            9. 某些用例依赖于其他用例
            10. 一个用例在离开系统时，可能是另一个用例的前置条件
            11. 有助于识别漏掉的用例
            12. 如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例
            13. 后置条件Postconditions
            14. 后置条件约束用例执行后系统的状态
            15. 用例执行后什么必须为真
            16. 对于有多个事件流的用例，则应有多个后置条件
            17. 事件流Flow of events
            18. 事件流描述要点
            19. 1.只书写“可观测”的（说人话）
            20. 2.使用主动语句
            21. 3.句子必须以参与者或系统作为主语
            22. 4.不要涉及界面细节
            23. 5.分支和循环
            24. 分支：可以放到扩展路径
            25. 循环：直接描述
            26. 分支流Subflows
            27. 备选流Alternate flow
4. 活动图
   1. 什么是活动图(Activity Diagram)?
      1. 活动图描述了从活动到活动的流。
      2. 活动图从本质上说，是一个流程图，它显示出一个过程的各个步骤。
   2. 活动图的特性
      1. 活动图是对系统的动态行为建模的五个图之一。
      2. 活动图中一个活动结束后将立即进入下一个活动。
   3. 活动图的用途
      1. 为什么要在UML中引入活动图?
         1. 在OMT, Booch, OOSE方法中没有活动图的概念。
      2. 活动图对表示并发行为很有用。活动图的应用非常广泛，包括：
         1. 1. 对系统的工作流(workflow)建模，即对系统的业务过程建模。(Use Case分析)
         2. 2. 对具体的操作建模，描述计算过程的细节。
   4. 活动图与流程图的区别
      1. 1.流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环， 各个处理过程之间有严格的顺序和时间关系；而活动图描述的是对象活 动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的 处理过程。
      2. 2.活动图能够表示并发活动的情形，而流程图不能
      3. 3.活动图是面向对象的，流程图是面向过程的。
   5. 活动图与状态图比较
      1. 1.活动图和状态图描述的重点不同
         1. 活动图描述的是从activity到activity的控制流， 而状态图描述的是对象的状态及状态之间的转移。
      2. 2.活动图和状态图使用的场合不同：
         1. 对于以下几种情况可以使用活动图：
            1. 分析用例
            2. 理解涉及多个用例的工作流
            3. 处理多线程应用
         2. 对于下面的情况要使用状态图：
            1. 显示一个对象在其生命周期内的行为
         3. 说明：如果要显示多个对象之间的交互情况，可用顺序图或协作图。
   6. 活动图中的基本概念
      1. activity 活动
         1. action 和 activity 的区别
            1. action是原子的，而activity可进一步分解。
         2. 动作状态
            1. 动作状态是指执行原子的、不可中断的动作，并在此动作完成后通过完成转换向另一个状态。
            2. 特点
            3. 1.是原子的，无法分解
            4. 2.不可中断，一旦开始运行就不能中断，一直运行到结束。
            5. 3.瞬时的，它所占处理时间极短，有时甚至可以忽略。
         3. 活动状态
         4. 活动状态用于表达状态机中的非原子的运行。
         5. 特点
            1. 1.可以分解成其他子活动或动作状态。由于它是一组不可中断的 动作或操作的组合，所以不可以被中断。
            2. 2.活动状态的内部活动可以用另一个活动图来表示。
      2. transition 转移
      3. swimlane 泳道
         1. 每个泳道代表一个责任区。
      4. branch 分支
         1. A branch is an element in a state machine in which a single trigger leads to more than one possible outcome, each with its own guard condition.
         2. 注意，在所有的输出转换中，监护条件不能重叠，而且它们应该覆盖所有的可能性。
      5. fork and join 分叉和汇合
         1. 在建模的时候可能会遇到对象在运行时存在两个或多个并发运行的控制流。
         2. 在UML中可以使用“分叉”把路径分为两个或多个的并发运行控制流， 然后使用“汇合”同步这些并发流。
         3. 从概念上说，分叉的每一个控制流都是并发的，但实际中，这些流可以是时序交替的。
      6. object flow 对象流
         1. 在活动图中可以出现对象，对象可以作为活动的输入或输出。
   7. 怎样绘制活动图
      1. 这些任务都以迭代的方式执行
      2. 1.确定活动图的范围
      3. 2.增加起点和终点
      4. 3.添加活动
      5. 4.添加活动间的转变
      6. 5.添加决策点
      7. 6.找出可并行活动之处
5. 类图 对象图 包图
   1. 类图
      1. 什么是类图
         1. 类、对象和它们之间的关系是面向对象技术中最基本的元素。 类图技术是OO方法的核心。
         2. 类图标加上它们之间的关系就构成了类图。
      2. 类图的应用
         1. 类图用于对系统静态设计视图建模。 与数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。
         2. 类图中可以包含接口、包、关系等建模元素，也可以包含对象、链等实例。
         3. 类图典型的应用在下面三种建模：
            1. 对系统的词汇建模
            2. 对简单协作建模
            3. 对逻辑数据库模式建模
      3. 类图的组成
         1. 类
            1. 边界类
            2. 边界类处理系统环境与系统之间的通信，为用户或另一个系统提供了接口。
            3. 边界类组成了系统中依赖与环境的部分，边界类用于为系统的接口建模， 代表了系统和系统外的一些实体之间的接口。
            4. 实体类
            5. 实体类是模拟必须被存储的信息和关联行为的类
            6. 实体对象是实体类的实例，被用来保存或更新关于某个现象的信息，通常是持久性的。
            7. 实体类通常是独立于他们的环境，对于系统环境如何与系统通信是不敏感的。
            8. 控制类
            9. 控制类是用来为特定于一个或几个用例的控制行为建模的类。
            10. 控制对象是控制类的实例，它经常控制其他的对象，所以控制对象的行为是协调类型的， 控制类协调实现用例的规定行为所需要的事件。
            11. 控制类封装类特定于用例的行为，通常依赖于应用程序的类。
         2. 接口
            1. 接口是一组用于描述类或构件的一个服务的操作。
            2. 在图形上，把接口画为一个圆；其扩展形式是接口表示为一个构造型化类。
         3. 协作
            1. 协作是一组类、接口和其他元素的群体，它们共同工作， 提供比各组成部分的功能总和更强的合作行为。
         4. 依赖、泛化和关联关系
            1. 依赖：它表示类之间的使用关系（包括精化、跟踪和绑定关系）
            2. 有两个元素X、Y，如果修改元素X的定义可能会引起对另一个元素Y的定义的修改，则称元素Y依赖于元素X。
            3. 在类中，依赖由各种原因引起，如：一个类向另一个类发消息；一个类是另一个类的某个操作参数类型。
            4. 泛化：它把一般类连接到它的特殊类
            5. 定义了一般元素和特殊元素之间的分类关系。
            6. 在UML中，泛化表示为一头为空心三角形的连线。
            7. 泛化意味着子类的对象可以被用在父类的对象可能出现的任何地方，但反之不行。
            8. 泛化为“is-kind-of”的关系
            9. 多数情况，用类和接口间的泛化指明继承关系。
            10. 关联：它表示对象之间的结构关系。
            11. 关联表示两个类之间存在某种语义上的联系，它是一种结构关系， 规定了一种事物的对象可以和另一种事物的对象相联系。
            12. 关联的图标：在类图中，关联用一条把类连接在一起的实线表示。
            13. 关联名称
            14. 可以给关联加上关联名，来描述关联的作用。
            15. 通常是动词或动词短语
            16. 关联命名的原则是该命名是否有助于理解该模型。
            17. 关联角色
            18. 关联两端的类可以某种角色参与关联
            19. 如果在关联上没有标出角色名，则隐含地用类的名称作为角色名。
            20. 关联的多重性
            21. 角色还具有多重性，表示有多少个对象参与该关联。
            22. 聚集
            23. 特殊形式的关联
            24. 表示类之间的整体与部分的关系
            25. 子主题 3
            26. 组合
            27. 特殊形式的聚集
            28. 组合中的整体与部分具有同样的生存期
            29. 子主题 3
         5. 还可以包含
            1. 注解、约束
            2. 包或子系统，二者都用于把模型元素聚集成更大的组件。
      4. 类图的抽象层次
         1. 在软件开发的不同阶段使用的类图具有不同的抽象层次
         2. 一般地，类图可分为三个层次，即概念层、说明层、实现层。
            1. 概念层(Conceptual)类图描述应用领域中的概念，一般地，这些概念和类有很自然的联系，但两者并没有直接的映射关系。
            2. 说明层(Specification)类图描述软件的接口部分，而不是软件的实现部分。
            3. 实现层(Implementation)类图才真正考虑类的实现问题，揭示实现细节
      5. 建立类图的一般步骤
         1. 1.研究分析问题领域
         2. 2.发现对象与类，明确它们的含义和责任，确定属性。
            1. 找类的方法
            2. 抽取名词
            3. 排除
            4. 系统本身
            5. 可以作为某类的方法或属性出现
            6. 不相关
            7. 交互的系统不出现在本类图中
         3. 3.发现类之间的关系。把类之间的关系用关联、泛化、聚集、组合、依赖等关系表达出来。
         4. 4.设计类与关系。 调整和细化已得到的类和类之间的关系，解决诸如命名冲突、功能重复等问题。
         5. 5.绘制类图并编制相应的说明。
   2. 对象图
      1. 对象图是表示在某一时间点上一组对象以及它们的关系的图。
      2. 在图形上，对象图是顶点和弧的集合。
      3. 对象图的模型元素有对象和链。 对象是类的实例；对象之间的链是类之间的关联的实例。
      4. 对象与类的图形表示相似，UML中对象图与类图具有相同的表示形式。
      5. 对象图实质上是类图的一个实例。
      6. 对象图的使用相当有限，主要用于表达数据结构的示例，以及了解系统在某个特定时刻的具体情况。
   3. 包
      1. 包是用于把元素组织成祖的通用机制。
      2. 在图形上，把包画为带标签的文件夹。
      3. 包的有关说明
         1. 包名分为simple name 和 path name 两种形式
            1. Camera
            2. Sensors::Vision::Camera
         2. 包中可以包含其它建模元素，如class,interface,component, node,use case,package,...
         3. 包可以嵌套，但嵌套层次不要过深。
         4. 包没有实例，即在系统运行时见不到包。
         5. 包之间可以存在依赖关系，
         6. 但这种依赖关系不存在传递性。
      4. 包的应用
         1. 对建模元素进行分组
         2. 设计良好的包把一些语义上接近并倾向于一起变化的元素组织在一起。
         3. 在Rose中，包可以提供一些特殊的功能，如
            1. 在数据建模中，用包表示模式和域包；在数据模型和对象模型之间的转换是以包为单位进行的；
            2. 在Web建模中，包可以表示某一虚拟目录(virtual directory)，在该目录下的所有web元素都在这个包中；
            3. 包在Rose中还可以作为控制单元(controlled unit)，以方便团队开发和配置管理。
6. 交互图（顺序图、协作图）
   1. 描述系统的动态建模以及如何在一个模型中捕获它。
   2. 对象需要交互
      1. 对象相互链接的地方就有交互
      2. 具有对象协作的系统、子系统语境中
         1. 如Web商务系统，客户对象、服务器对象间交互
      3. 操作实现语境中
         1. 操作的参数、局部变量、全局对象相互交互完成操作的实现算法
      4. 类语境中
         1. 通过交互显示类的属性是如何相互协作的
   3. 对象通过消息交互
      1. Message，传递信息的对象之间所进行的通信，消息带有对将要发生的活动的期望。
      2. 一个消息实例的接受可看作一个事件的实例
      3. 发送消息引发的动作：执行可执行语句——导致状态改变
   4. 定义(interaction diagram)
      1. 交互图是一种详细表示对象之间以及对象与系统外部的参与者之间动态联系的图形文档。
      2. 交互图是用来描述对象之间的动态协作关系以及协作过程中的行为次序， 它常常用来描述一个用例的行为，显示该用例中所涉及的对象和这些对象之间的消息传递情况。
   5. 两种形式
      1. 顺序图
         1. 强调消息的时间顺序的交互图。 图形上是一张表，对象沿X轴排列，消息沿Y轴按时间顺序排列。
      2. 协作图
         1. 强调发送和接收消息的对象之间的组织结构的交互图。 图形上是定点和弧的结合
   6. 顺序图(sequence diagram)
      1. 定义
         1. 顺序图描述了对象之间传递消息的时间顺序，它用来表示用例中的行为顺序。
      2. 主要元素
         1. Object（包括actor实例）
            1. 顺序图和协作图描述的是对象之间的消息发送关系，而不是类之间的关系。
            2. 在顺序图中并不包括系统中的所有类的对象。 也有可能某些对象属于同一个类。
            3. 常见命名方式
            4. Topic
         2. Lifeline（生命线）
         3. Focus of control（控制焦点）和activation（激活期）
         4. Message
            1. 消息的类型
            2. 同步消息
            3. Topic
            4. 异步消息
            5. Topic
            6. 返回消息
            7. Topic
      3. 特点
         1. 顺序图是一个二维图形。在顺序图中水平方向为对象维，沿水平方向排列参与交互的对象； 竖向方向为时间维，沿垂直向下方向按时间递增顺序列出各对象所发出和接收的消息。
         2. 水平轴上的对象间的相互顺序并不重要。
         3. 顺序图不表示对象间的关联关系。
      4. 建立顺序图的步骤
         1. 1.确定交互过程的上下文
         2. 2.识别参与交互过程的对象
         3. 3.为每个对象设置生命线，即确定哪些对象存在于整个交互过程中， 哪些对象在交互过程中被创建和撤销
         4. 4.从引发这个交互过程的初始消息开始， 在生命线之间从顶到下依次画出随后的各个消息
         5. 5.如果需要表示消息的嵌套，或/和表示消息发生时的时间点，则采用FOC
         6. 6.如果需要说明时间约束，则在消息旁边加上约束说明
         7. 7.如果需要，可以为每个消息附上前置条件和后置条件
   7. 协作图(collaboration diagram)
      1. 定义
         1. 协作图包含一组对象和链，用于描述系统的行为是如何由系统的成分协作实现的。
      2. 组成元素
         1. Object(包括actor实例，多对象，主动对象)
         2. Message
         3. Link(链)
      3. 建立协作图的步骤
         1. 1.确定交互过程的上下文
         2. 2.识别参与交互过程的对象
         3. 3.如果需要，为每个对象设置初始特性
         4. 4.确定对象之间的链，以及沿着链的消息
         5. 5.从引发这个交互过程的初始消息开始，将随后的每个消息附到相应的链上
         6. 6.如果需要表示消息的嵌套，则用Dewey十进制表示法
         7. 7.如果需要说明时间约束，则在消息旁边加上约束说明
         8. 8.如果需要，可以为每个消息附上前置条件和后置条件
   8. 顺序图和协作图的比较
      1. 相同
         1. 顺序图和协作图都是用于描述模型动态特性的交互图。
         2. 顺序图和协作图从语义上讲是相同的，他们只是从不同的方面来描述一次交互。
      2. 不同
         1. 顺序图强调消息的时间顺序，协作图强调参加交互的对象的组织。
         2. 两者可以相互转换
   9. 从用例到类
      1. 顺序图是你可以可视化地对系统逻辑建模。
      2. 对象、类和参与者都在顺序图中进行了描述。
      3. 理解分析阶段的基本逻辑，在设计阶段详细将其突出出来。
7. 动态图总结
   1. 顺序图 VS 协作图
      1. 交互图描述了对象之间的交互。
      2. 顺序图强调消息的时间顺序，协作图强调参加交互的对象的组织。
   2. 状态图 VS 活动图
      1. 活动图描述的是从活动到活动的控制流，而状态图描述的是对象的状态机状态之间的转移。
      2. 状态图适用于描述跨越多个用例的单个对象的行为： 活动图适用于描述多个对象和多个用例的活动的总次序。
8. 状态图
   1. Review
      1. 对象具有状态
         1. 对象的状态是由class中的属性代表的。
   2. 什么是状态图
      1. 状态图强调了从状态到状态的控制流。 规定了对象在生命周期中响应事件所经历的状态的序列以及对象 对这些事件的响应。
   3. 状态图的应用
      1. 主要用于建立类的一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列， 引起状态转移的事件，以及因状态转移而伴随的动作。
   4. 状态图的特性
      1. Rose中，状态图不生成代码，但状态图在检查，调试和描述类的动态行为时非常有用。
      2. 状态图适合于描述跨越多个用例的单个对象的行为，而不适合描述多个对象之间的行为协作，因此，常常将状态图与其它技术组合使用。
      3. 活动图适合于描述多个对象和多个用例的活动的总次序。
      4. 交互图适合于描述单个用例中的多个对象的行为。
   5. 状态图中的基本概念
      1. State（状态）
         1. 一个状态是指在对象的生命期中的一个条件或状况，在此期间对象将满足某些条件、 执行某些活动或等待某些事件。
         2. 状态的特点
            1. 一个状态只能有一个初态，而终态可以有多个，也可以没有终态。
            2. 一个状态有以下几个部分
            3. 状态名
            4. 入口动作
            5. 出口动作
            6. 动作
      2. Action（动作）
      3. Transition（转移）
         1. 一个转移是两个状态之间的一种关系，表示对象将在第一个状态中执行一定的动作， 并在某个特定事件发生时进入第二个状态。
      4. Event（事件）
         1. 一个事件是对一个在时间和空间上占有一定位置的有意义的事情的详细说明。
         2. 事件产生的原因包括：调用、满足条件的状态的出现、到达时间点或经历某一时间段、发送信号等。
         3. 事件引发转移
            1. 对于一个给定的状态，最终只能产生一个转移，因此从相同的状态出来的、 事件相同的几个转移之间的条件应该是互斥的。
            2. Topic
   6. 状态建模技术
      1. 1、可以分成若干个场景，考虑每个场景的状态变化：
         1. （1）找出适合用模型描述其行为的类
         2. （2）确定对象可能存在的状态
         3. （3）确定引起状态转换的事件
         4. （4）确定转换进行时对象执行的相应动作
         5. （5）对建模的结果进行相应的精化和细化
      2. 2、然后将这些复合成一个完整的状态图。