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