OOAD
OOAD(Object-Oriented Analysis and Design)介绍
1. OOAD方法论的定义
答：1) 一种面向对象的系统建模技术;
2) 将系统描述为许多相互作用的有关系对象;
3) 系统中相互作用的对象被组织成类;
4) OO方法论由以下三部分组成：
. 一个过程
. 一个符号
. 一系列规则
2. 在一个OOAD软件开发过程，我们要完成二个不同的工作：
答：1) 分析阶段我们主要：
. 建立一个清晰的商业问题的视图;
. 概述系统必须执行的任务;
. 建立商业问题描述的通用词汇;
. 概述商业问题的最佳方案。
2) 设计阶段我们主要：
. 解决商业问题;
. 定义“how”代替“what”;
. 介绍将使系统工作的支撑元素;
. 定义系统的实现策略。
3. 对象
答：1) 是单个的、唯一确认的实体或项目;
2) 作为面向对象的构建块被使用;
3) 有身份、数据和行为;
4) 可以是简单或复杂的;
5) 可以是真实或想象的;
6) 有属性和操作;
7) 是一个类的动态实例;
4. 类
答：多个相同对象的一种抽象，对象都创建自类
5. 面向对象编程的特征
答：1) Abstraction(抽象):
. 忽略细节，处理对象或实体本质的特征;
. 简化功能以及信息;
. 帮助用户和对象交互;
2) Encapsulation(封装):
. 隐藏对象的数据;
. 处理每个对象的二种视图：
a. 外部视图：显示一个对象做什么;
b. 内部视图：显示对象如何完成它的任务;
3) Association(关联)
. 对象间交互的方式;
. 一个对象使用另一个对象的服务或操作另一个对象，这时候对象相互关联。
4) Aggregation(聚合)
. 定义一个对象是另一个对象的一个组成部分;
. 是一种比较强的关联;
. 通过“Has A”关系可进行确认。一辆车有轮子、座椅以及门，它们是一部车的组成部分。假如你移除其间的任何一部分，车没有了相应的功能，但仍是一部车。
5) Composition(合成)
. 一个对象包含另一个对象;
. 是最强的关联形式;
. 通过“contain”关系可进行确认。
. 假设部件不存在，对象亦不存在。
6) Inheritance(继承)
. 是一种根据既存类定义新类的机制;
. 通过“Is A”或者“Kind of”关系可进行确认;
. 允许你组织相关类，这样这些类可共同地被管理以及重用。
7) Cohesion(内聚)和Coupling(耦合)
. Cohesion: 一个或一组类对系统中单个功能贡献程度的度量;
. Coupling: 二个或多个类间对联系紧密程度的度量;
8) Polymorphism(多态)
. 不同对象完成相同语义上的结果;
. 基于继承;
. 多态功能的实现依赖于它应用的对象;
. 举例：足球-扔-需二只手、网球-扔-只需一只手，同样是扔，有不同的实现。当你将不同的球给一个小孩子，他知道是用一只手还是二只手。小孩都知道多态。
6. 开发过程预览
答：1) 传统开发过程：
. 瀑布式开发：需求->分析->设计->实现->测试。每个步骤完成和文档化后才进入下一个阶段。
. 假设在后期阶段出现问题，很难返回到先前阶段。
. 项目组成员花费大量时间和精力于每个阶段确保它是正确的.
. 各阶段所用符号和术语均是变化的。完成的软件虽然正确，但与它所表现的商业逻辑相关甚少。
2) OOAD开发过程
. 典型的处理方式是将一个项目作为一系列的小项目;
. UML(Unified Modeling Language)是一种符号，不是一个处理过程;
. USDP(Unified Software Development Process)是迭代增量式的;
. USDP和RUP(Rational Unified Process)都是流行的OOAD过程。
7. 迭代增量式项目生命周期
答：1) “迭代”指生命周期中每一个步骤;
2) 迭代的结果便是整个项目功能完成的一步步增长;
3) 在每个迭代的构建阶段，你应该：
. 选择并分析相关的用例;
. 使用选择的体系结构创建一个设计;
. 用组件实现设计;
. 检验组件满足用例。
8. 迭代增量生命周期的主要阶段
答：1) Inception(开始)阶段：
. 这个阶段的增长集中在：
a. 开始项目;
b. 为这个项目建立起商业原则;
c. 定义一个商业问题;
d. 识别潜在的风险;
e. 定义对问题更好理解的范围;
f. 创建对商业问题的解释文档。
. 每个循环包括一至多个反复，每个阶段的完成结果都是里程碑式的。
2) Elaboration(细节)阶段：
. 这个阶段的增长集中在：
a. 高水平的分析和设计;
b. 为项目建立一个架构体系的基线;
c. 监测潜在的风险;
d. 创建一个实现项目目标的构建计划;
3) The Construction(构建)阶段：
. 这个阶段的增长集中在软件项目日益成型;
4) The Transition(跃迁)阶段:
. 这个阶段的增长集中在:
a. 发布产品给客户;
b. 完成beta测试;
c. 实现性能调整、用户培训以及接受度测试。
9. 阶段期间的工作步骤
答：1) 每个阶段由以下五个工作步骤组成：
. 需求
. 分析
. 设计
. 实现
. 测试
2) 不同的反复对每个工作步骤完成的程度不同;
3) 早期的反复在深度上覆盖了第一个工作步骤，以后的反复在深度上覆盖了最后的工作步骤。
4) 8/2原则：假如完成了80%, 即可进入下一个反复。
10. 反复和工作步骤
答：1) 在每个反复过程，根据需求你可以包括五个工作步骤中的任何一个。
2) 早期的反复过程集中在靠前的工作步骤，后期的反复过程集中在靠后的工作步骤。
3) 当你发现应该修改早先工作步骤中的某些错误，你可以：
. 继续并在下一个反复过程中修正;
. 继续并增加一个新的反复过程修正问题;
. 假如时间允许，返回到当前的反复并修正这个问题。
4) 不同的反复执行每个工作步骤于不同的程度。
11. 迭代增量生命周期的好处
答：1) 减少费用;
2) 对项目进度的更好保证;
3) 对于开发团队而言开发速度更快;
4) 可适应用户需求的改变;
UML(Unified Modeling Language)介绍
1. UML定义
答：1) UML是一种图形化语言用于：
. 说明;
. 构建;
. 肉眼观察;
. 文档化系统原型;
2) 在分析阶段，你创建类图以帮助你理解商业概念(还没有实现的细节);
3) 在构建阶段，我们通过为相同的类图增加附加的细节——实现商业细节;
2. UML和蓝图的关系
答：开发OOAD程序——UML
建房——蓝图
3. UML图形类型
答：1) 静态模型：代表你正在建模的软件系统的基本结构;
2) 动态模型：强调了系统的行为;
4. 静态模型
答：1) 构建以及文档化一个系统的静态方面;
2) 反映了一个软件系统基本的、稳定的框架;
3) 创建问题主要元素的代表;
4) 由以下图形组成：
. 用例图
. 类图
. 对象图
. 组件以及部署图
5. 动态图
答：1) 构建显示系统行为的图形;
2) 由以下图形组成：
. 时序图
. 协作图
. 状态图
. 活动图
6. 用例图
答：1) 显示谁或什么使用系统以及它的特征;
2) 一个用例图中特征的用户称为“actors”;
3) 用例用椭圆表示;
4) 为使建模容易，用例图需区分先后顺序;
7. 类图
答：1) 代表一系列包含普通属性和特征的对象;
2) 结构化的图形显示了一系列的类、接口、对象间的协作以及关系;
3) 由一至多个描述了以下信息的矩形组成：
. 类型(类名)
. 可选择的属性
. 操作部分
8. 对象图
答：1) 代表一个明确的对象
2) 结构化的图形显示了一系列对象以及他们之间的关系
9. 组件图
答：显示软件组件间的关系
10. 部署图
答：显示能用于部署软件应用程序的物理设备
11. 时序图
答：1) 不同对象一定时间范围发生的消息;
2) 强调消息的时间顺序
12. 协作图
答：1) 显示了使用消息期间对象间的协作;
2) 强调发送和接收消息的结构化组织;
13. 状态转换图
答：强调对象行为的事件顺序
14. 活动图
答：1) 描述一项活动到另外一项间的流程
2) 强调一项活动到另外一项间的流程
15. 包的符号
答：1) 指组织项目的一种方式;
2) 通常用于控制类的名域空间;
3) 在UML中使用包组织类、软件组件、硬件组件、其它包以及和你模型相关的任何其它东西
2004-11-5 星期五 阴
需求和初始化分析
1. 开始开发过程
答：1) 分析最初的工作流;
2) 收集信息;
3) 创建一个问题的状态;
4) 创建用例;
5) 引介组件以及部署图;
2. 收集信息
答：你可从许多资源中收集信息，这些资源包括：
. 用户的初始化需求详情
. 行业专家
. 顾客和用户
. 管理者
. 市场
. 以前类似项目
3. 避免习惯性的假设
答：1) 你必须避免习惯性的假设，包括：
. 用户是天真的，开发者最清楚
. 需求是静态的
. 一开始便能建立正确的方案
2) 记住项目的发展以及客户的需求均是变化的。
3) 为了避免这些假设，我们应该：
. 明确用户的需求
. 确保你的模型能适应不断变化的需求
. 确保你能修改你的模型
4. 行业专家
答：1) 指某个特定商业领域的专家
2) 可大致细分为：
. 通用行业专家
. 特定应用程序行业专家以及当前商业领域专家
. 类似商业领域专家
3) 没有行业专家，从其它领域抽象通用元素很困难
5. 问题声明
答：1) 文档清楚地描述了客户和系统需求吗？
2) 用户输入对于文档很重要
3) 使用客户熟悉的语言词汇
4) 句义清楚，不用行话
5) 函盖项目范围内的细节
6) 详细说明问题的背景
7) 详细说明所知的约束
8) 问题声明提供了关于商业背景、范围以及计算机术语无关方面的约束。它用于作为确认问题范围的基础。
6. 对象和类的侯选值
答：1) 可从问题声明中确定
2) 给问题声明中的名词短语加下划线以建设对象和类侯选值列表
3) 在接下去的分析阶段，你需要确定你系统中所需的对象和类的列表
7. 数据字典
答：1) 描述了用于项目所有词汇的文档
2) 通过和用户沟通积累所得的条款
3) 用于整个项目和系统
4) 在整个项目期间会不断地加入新的术语
5) 帮助消除歧义
6) 必须对所有项目组成员可用
7) 数据字典对于大型项目中各团队沟通非常重要。这时，它既是商业文档也是系统文档。
8. 创建用例
答：1) 一个用例是用户和系统交互的图形化的表现形式;
2) 是定义和理解系统需求和背景的工具;
3) 是任何系统某一方面的简单印象。当你将所有印象收集在一块，你便拥有了系统的整个描述;
4) 图形具体表现为实线的椭圆。
9. 用例图中的“include”和“extend”
答：1) “include”集中于包含关系，完成某个模块之前，你必须使用另一个模块;
2) “extend”集中于扩展关系，也许或也许不基于某个模块，不是强制性的;
10. 用例中的情节假设
答：1) 用例从用户的角度显示了软件的功能。也许存在超过一种方式完成一指定功能。
2) 一个假设情节指用例的一个实例——从开始到结束的一个逻辑路径。
3) 情节假设不包括有条件的声明——因为它们描述了用户多个可能路径中的一种。
4) 所有的情节假设从相同的方式开始，但结果却不同。
5) 一个用例中成功或不成功的路径都应该显示出来——在一个ATM中，你必须考虑一些情节诸如用户个人身份号码输入不对或者金额不足。
11. 用例表单
答：1) 每个用例的摘要
2) 用例表单不是UML的内容，但是建议完成它。
3) 在这个表单中，包括以下项目：
. 用例名称
. 参与者
. 优先权
. 状态
. 扩展内容部分
. 预处理/假想情节
. 提交条件
. 事件流
. 可选路径
. 执行
. 频率
12. 活动图
答：1) 创建用例图后，你可以使用图形说明活动或工作流
2) 图形化了所有用例假想情节
3) 显示活动、过程或工作流
13. 风险评估
答：1) 有必要对项目进行风险评估
2) 用例可以是风险评估的起点
3) 高风险的用例应该在早期的迭代中开发
4) 风险能出现在以下方面：
. 需求风险
. 技术风险
. 技能风险
. 资源风险
. 政策风险
14. 需求风险
答：1) 需求风险指没完全满足客户需求
2) 你应该使工作于该系统的所有用户和管理者都参与进来
15. 技术风险
答：记住已证实过的技术比未证实的技术所冒风险要小
16. 技能风险
答：确信你有所需的全部技能
17. 资源和政策风险
答：1) 资源风险指超出时间和资金预算
2) 政治风险指与现行的政治规则冲突
18. 包图
答：1) UML中存在符号以包装任何逻辑相关的UML元素(类、对象、用例等等);
2) 就像Java一样，相关的类组织成不同的包;
3) 这个符号像文件夹图标;
4) 有助于降低复杂性;
5) 包间可存在依赖关系;
6) 包有助于：
. 查看没有太多细节的大图;
. 查看独立的小部分;
. 创建部件中的一小部分;
. 显示组件间的依赖性;
. 组件图显示了代码物理组织形式，可以是一个类文件、Java源文件、jar文件、Java中的包、共享库、对象代码、RDB等等;
. 当一个组件改变，它能影响其它——依赖性;
. 组件应该有一个良好的接口，这样你可以使用其它实现该接口的组件去替换它。
19. 部署图介绍
答：1) 显示了硬件组件间的物理关系;
2) 每个符号代表了一些硬件设备：服务器、工作站、个人PC、传感器、时钟、电话交换机等。
3) 当你获得信息的时候可在任何阶段添加以及修正。
4) 符号间的连接伴随着协议一起显示。
系统对象和类分析(I)
1. 分析阶段的理解
答：1) 定义系统必须做什么;
2) 避免描述和实现的问题;
3) 专注于系统的组件;
4) 分析阶段确定对象在运行时需要什么以确保系统正确的功能;
5) 分析阶段在需求收集阶段和用例阶段之后，在系统设计阶段之前;
6) 在确定哪些是类和对象的时候，你应该回答以下问题：
. 什么对象组成了这个系统?
. 什么是可能的类?
. 每个对象或类的责任是什么？
. 对象和类间是如何相联系的？
7) 记住将所有新项目加入数据字典;
2. 关键字的提取
答：1) 当你定义组成系统的对象时，你应该创建一个满足系统功能对象的列表;
2) 列表中的对象称为对象侯选值;
3) 然后你可以为这个列表中最重要的对象准备一个子列表;
4) 关键字代表了系统中主要或第一位的对象;
3. 用UML表示对象和类
答：1) 对象模型显示了逻辑和特理的静态视图;
2) 对象模型有二种图：
. 类图：显示了你必须创建一个系统所需的类。在运行时你可使用一个类创建许多对象。类图必须显示类间所有可能关系。
. 对象图：代表了系统中真实的对象，描述了特定案例中外在关系。
3) 你可以使用主键去创建类图和对象图。
4) 类图在整个分析阶段都会被更新和修正。
4. 属性和方法
答：1) 对象包含了定义对象状态的属性;
2) 方法定义了对象能执行的操作;
3) 因此类必须定义这些属性和方法;
4) 在类执行之前，你必须定义所有的属性和方法;
5) 但是很多属性和方法到设计阶段才知道，加上所有你能加的先;
6) 在设计阶段存在的属性和方法足够了，但是他们的类型和参数还不够。
5. 属性和方法
答：二种类型的属性:
. 普通属性：是一个对象中真实存在的变量或常量。一个普通属性将会存储对象中一些有意义的值。
. 衍生属性：并未存储在系统中，通过系统中其它信息计算得出。
6. 联接和链接
答：1) 联接——针对类而言
. 指类图中用直线表示的关系;
. 线可以是水平也可以是垂直的;
. 可以在关系线上给一个逻辑名称描述这个关系;
2) 链接——针对对象而言
. 指对象图中二个对象间的关系;
7. 联接和多样性
答：1) 多样性显示了一个类中对象和另一个类中对象联系的可能性;
2) 在类图中，每个类只有一个矩形，因此联接会确定一个类有多少个对象链接于另一个类的对象;
3) 联接线的末端有标记;
8. 多样性的值
答：1) 2: 刚好二个;
2) *: 0至多个;
3) 5..15: 5到15个;
4) 2,4,6: 2、4、6个;
5) 10..*: 最少10个;
6) 0..10: 最多10个;
9. 复杂性的联接
答：1) 多样性标记“*”出现在联接的两端;
2) 你命名了类图中所有联接并分配了多样性后，是时候重新审视他们并尝试解决复杂联接。可使用联接类或符合条件联接。
10. 联接类(类似于数据库中索引表)
答：1) 这意味着联接它本身必须编码为一个类，这个类带有解决冲突的属性;
2) 这种技术用于分析阶段解决多对多关系;
11. 符合条件的联接
答：1) 通过使用属性值可解决多对多问题;
2) 分配一个唯一的属性值;
系统对象和类分析(II)
1. 分析阶段的逻辑关系
答：1) 在一个系统中必须存在一些关系以便进行适当地操作;
2) 逻辑关系表达了一个类和另一个类如何关联、一个对象怎样得到或使用另一个对象;
3) 问下列问题：
. 一个类依赖于另一个类的某些功能吗？
. 是否存在一种非常强的关系以致一个对象缺少了另一个便不能存在？
4) 在这个模块讨论的逻辑关系如下：
. 继承(Inheritance):
a. 一般;
b. 特殊
. 多态(Polymorphism)
. 关联(Association)
a. 聚合(Aggregation)
b. 组合(Composition)
2. 继承(Inheritance)
答：1) 继承的概念描述了你如何在一组类似或相同目的类间共享或得到属性以及功能;
2) 单继承和多重继承;
3) 使用继承，我们能够 ：
. 降低全部系统的尺寸;
. 改善设计和维护的功能;
4) Car、Bus、Train、Airplane、Ship, 他们都是交通工具。他们可以移动以及驾驶，它们可以将人从A地运往B地。
3. 子类和超类
答：1) 当一个类继承自其它类，它被称为“子类”;
2) 当一个类被继承自其它类，它被称为“超类”;
4. 继承的分析
答：继承的二种类型：
. 一般继承：
|ˉˉˉˉˉ| |ˉˉˉˉˉ| |ˉˉˉˉˉ|
| Dog | | Cat | | Mammal |
|__________| |__________| |__________|
|-numLegs | |-numLegs | ——> |-numLegs |
|ˉˉˉˉˉ| |ˉˉˉˉˉ| |ˉˉˉˉˉ|
|+eat() | |+eat() | |+eat() |
|+bark() | |+meow() | |__________|
|__________| |__________| △
│
|ˉˉˉˉˉˉˉˉˉˉ|
| |
|ˉˉˉˉˉ| |ˉˉˉˉˉ|
| Dog | | Cat |
|__________| |__________|
|ˉˉˉˉˉ| |ˉˉˉˉˉ|
|+bark() | |+meow() |
|__________| |__________|
. 特殊继承：
|ˉˉˉˉˉ| |ˉˉˉˉˉ|
| Mammal | | Mammal |
|__________| |__________|
|-numLegs | |-numLegs |
|ˉˉˉˉˉ| |ˉˉˉˉˉ|
|+eat() | |+eat() |
|__________| |__________|
△ ——> △
│ │
|ˉˉˉˉˉˉˉˉˉˉ| |ˉˉˉˉˉˉˉ|ˉˉˉˉˉˉ|
| | | | |
|ˉˉˉˉˉ| |ˉˉˉˉˉ| |ˉˉˉˉˉ| |ˉˉˉˉˉ| |ˉˉˉˉˉ|
| Dog | | Cat | | Dog | | Cat | | Sheep |
|__________| |__________| |__________| |__________| |__________|
|ˉˉˉˉˉ| |ˉˉˉˉˉ| |ˉˉˉˉˉ| |ˉˉˉˉˉ| |ˉˉˉˉˉ|
|+bark() | |+meow() | |+bark() | |+meow() | |+baa() |
|__________| |__________| |__________| |__________| |__________|
5. 多态
答：1) 是一个和继承关系密切的OO术语;
2) 多态这个名字来源于希腊，意思是“多种形态”;
3) 从分析透视图看来，多态意味着不同类型和多种属性可分配于类;
4) Java和C++支持多态;
6. 抽象类
答：1) 是一些包含未实现功能的类，这些类不能实例化。一个类继承了一个抽象类继承了所有方法(包括抽象方法);
2) 任何类继承了抽象类后除非实现了所有的抽象方法，否则也是抽象的;
7. UML中关于抽象类的符号
答：1) 抽象类的类名为斜体;
2) 抽象方法名也是斜体;
8. 反身关联
答：1) 对象图中，相同类的二个实体间的联系;
2) 但是在类图中只有一个类代表这些对象;
3) 因此，这种关联回转到相同的类。这样的关联称为反身关联;
4) 反身关联在关联线的末端必须存在角色名字。这明确地说明你是如何关联这个类的二个对象。
wife
|ˉˉˉˉˉˉ|
|ˉˉˉˉˉ| |
| Person | |
|__________| |married
|ˉˉˉˉˉ| |
|__________| |
↑____________|
husband
9. 关联(Association)
答：1) 关联用于描述类图中二个类间的关系;
2) 包括一些更紧密关系诸如：聚合(Aggregation)和组合(Composition)
. 联系：厨师使用刀;
. 聚合：一辆车有一个车载电台;
. 组合：一辆车一般只包括一个发动机;
|ˉˉˉˉˉ| |ˉˉˉˉˉ|
| Chef | chops with | Knife |
|__________|------------>|__________|
|ˉˉˉˉˉ| |ˉˉˉˉˉ|
|__________| |__________|
10. 聚合(Aggregation)
答：1) 是关联中的一种;
2) 更紧密的关联方式;
3) 聚合是一种整体/部分关系，但“部分”可能被其它对象共享，因而有可能在“整体”外存活。
4) 表现为“Has A”关系;
|ˉˉˉˉˉ| |ˉˉˉˉˉ|
| Car | has a | CarRadio |
|__________| ◇-------------|__________|
|ˉˉˉˉˉ| |ˉˉˉˉˉ|
|__________| |__________|
11. 组合(Composition)
答: 1) 最紧密的关联方式;
2) 表现为“always contains”关系, 例如：车不能没有引擎
3) 在UML图上表现为一黑色的菱形
|ˉˉˉˉˉ| |ˉˉˉˉˉ|
| Car | driven by | Enginee |
|__________| ◆-------------|__________|
|ˉˉˉˉˉ| |ˉˉˉˉˉ|
|__________| |__________|
动态模型分析
1. 在分析阶段创建动态模型
答：1) 一旦在分析阶段完成对象模型建模，你可以开始对系统和对象在整个时间段内运作方式进行建模，这称为动态建模。
2) 动态建模发生二次：
. 在逻辑分析阶段(确信每个操作都是可能的)
a. 时序图(Sequence diagrams)/协作图(Collaboration diagram);
b. 状态转换图(State transition diagram);
c. 活动图(Activity diagram);
. 在物理设计阶段(分配方法描述给对应的类)
2. 责任
答：在OOA&D中，“责任”指：
. 一个类知道什么(状态);
. 一个类做什么(行为);
. 一个类型知道什么(状态);
. 一个类型做什么(行为);
3. 分配责任
答：在分配责任时，很重要去确定以及实现以下内容:
. 专家(指你所分配责任的类完全可实现其责任，这减小了额外对象的依赖以及支持低耦合);
. 创建者(谁应该创建一个实例);
. 高聚合(一个类的属性一起完成得很好);
. 低耦合(减少对象间的依赖性);
4. 改变的必要
答：1) 一个系统中的对象存在是因为它们完成一些作务帮助系统完成它们的目标;
2) 每个任务需要一定时间完成以及需要在对象间传递一些信息;
3) 系统中的每个对象代表一组特定的活动;
4) 你也应该考虑一个操作中所调用的对象以及它们是如何交互去完成这个操作的, 一个对象所完成的每个操作或子操作是如何改变对象的内在状态的;
5. 时序图
答：1) 模仿一定时间内一个系统的单个操作;
2) 每个时序图：
. 和一个用例或一个用例中的一个情景直接联系;
. 确定每个过程中所调用的对象;
. 确定在一个过程中发现的行业或事件;
. 确定在每个过程中必须传输什么信息;
. 确定每个行为后需要什么响应;
. 对于每个用例至少产生一个时序图
3) 在分析阶段，他们仅影响交互。在设计阶段，每个交互将会转为一个方法调用。
4) 一个用例至少一个时序图, 时序图可以制作得很复杂以显示一个用例的多个情景，但最好还是每个情景对应一个时序图。
6. 协作图
答：1) 可以作为时序图的可选对象;
2) 对象通过标有序号的箭头连接，这些箭头显示了信息的流程;
3) 箭头从动作源指向目标对象;
4) 箭头标有序号显示了在一个情景中它们使用的顺序;
5) 协作图看上去像对象图的子集。操作中被调用的对象在图中表现为装有对象名称的盒子。
7. 状态转换图
答：1) 时序图和协作图显示了在一定时间段内系统中对象是如何传递信息的;
2) 状态转换图显示了在一定时间段内一个对象是如何改变的，它的方法是如何被其它对象所调用;
3) 组成：状态和事件;
4) 箭头用于显示对象各种状态间的路径;
5) 每个箭头显示了该对象是如何完成特定事件;
8. 状态
答：1) 所有对象均有状态，任何对象的当前状态由存储于其属性中的值指示;
2) 设想一台打印机，它要么闲置、要么忙碌，打印机只有二种状态：闲置和忙碌;
9. 事件
答：1) 事件是一个对象从一种状态转换到另一种状态的促进因素;
2) 事件表现为方法调用。方法是一个对象的某些或一系列改变状态的任务;
3) 当一些对象调用打印机的print()方法,状态由闲置改变为忙碌，print()方法的调用就是导致状态改变的事件;
4) 一个对象通常处于它状态中的一种，这意味着他们是稳定的。同时也意味着状态的改变应该越快越好。
|ˉˉˉˉˉ| print |ˉˉˉˉˉ|
| idle |--------------->| busy |
●----->| | | |
| |<---------------| |
|__________| eof |__________|
|
| delete
↓
◎
10. 活动图
答：1) 显示一个对象和工作流的关系以及描述了相应的处理方法;
2) 每个用例只有一个活动图;
3) 每个活动表现为一个圆，该圆上有连接线连到下一个活动。这个连接线被称为板机(trigger);
4) 一个活动能产生多个板机，这依赖于活动的结果;
