面向对象分析与设计框架

设计

背景

好像总是没有足够的时间来完成建模、 分析和设计工作，总是过早地进入到 编码阶段

以最少的投入，完成需求到编码的过渡

构造系统时需要弄明白的几个问题

• 谁是系统的用户(参与者)，他们想完成何种工作?
• 何为“现实世界”(问题域)对象，它们之间存在何种联系?
• 每个用例需要何种对象?
• 在每次用例交互，对象是如何协作的?
• 如何处理实时控制问题?
• 在具体细节上，实际上准备如何建立该系统?

问题答案

4个阶段

需求分析

• 绘制高层类图
• 可以做快速原型
• 使用用例图确定用例
• 把用例组织成组包
• 给用例与域对象分配功能需求

产出：用户界面原型、用例模型、领域模型、高层类图
里程碑：需求评审

初步设计

• 编写用例描述
• 执行健壮性分析
• 完成类图更新

产出：用例图、健壮性图、领域模型、类图
里程碑：初步设计评审

详细设计

• 为对象分配行为------------------------------>时序图
• 通过添加详细信息来结束静态模型----------------->完整的类图
• 与小组成员一起来验证设计是否满足所有已确定的需求

产出：时序图、完整的类图、(协作图、状态图)
里程碑：详细/关键设计评审

画时序图注意点：

• 确定那些需在对象间传送的消息
• 绘制时序图，其中用例放在左边，时序图放置在右边。当发现属性与操作时，更新类图
• 如果愿意，可以使用协作图来显示关键的类间事务
• 如果愿意，可以使用状态图来显示实时行为

编码实现

• 如果需要，在实现阶段绘制一些图，如部署图、构件图
• 编写代码/生成代码
• 执行单元测试与集成测试
• 执行系统测试与用户验收测试

产出：代码
里程碑：交付

领域建模

• 领域概念：
  问题域，一个包含现实世界事务与概念的领域,在用例建模中起一个术语表的作用

• 领域建模目的
  确定真实世界中的抽象,确定对象以及他们之间的关系

• 域类的最佳来源
  高层级需求、详细需求描述、问题空间的专业知识

领域建模任务

领域建模的任务:找到代表现实世界中的事务与概念的对象

建模活动

这些活动的执行没有固定必然的顺序，是不断重复细化的

识别类

• 类
  一组具有相同属性、同样行为、共同关系和相同语义的对象
• 属性
  识别名词或名词短语:成为类或属性。注意:所有名词应该是属性
• 方法
  识别动词或动词短语:成为类的操作或关联

建立归纳关系

• 归纳关系：即继承、泛化
• 这些关系在现实中一定要是真实的
• 增强可复用性的手段之一

建立类间关联

• 类间关联是两个类的静态关系,不是动作
• 泛化 聚合 组合 依赖

开发关联类

• 关联类拥有关联和类特性：一个关联类可以看作是一个拥有类特性的关联，或者可以看作是一个拥有关联特性的类。

• 它不仅仅是用于连接一些分类器，而是还定义了属于关联关系本身的特征，这些特征是只属于关联关系本身而不属于任何关联分类器的

产出

高层类图

用例建模

• 用例
  用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

• 参与者
  是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。

用例建模目的

用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。

用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。

用例图(Use Case Diagram)

确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。

寻找参与者

• 系统开发完成之后，有哪些人会使用这个系统？
• 系统需要从哪些人或其他系统中获得数据？
• 系统会为哪些人或其他系统提供数据？
• 系统会与哪些其他系统相关联？
• 系统是由谁来维护和管理的？

确定用例

• 参与者为什么要使用该系统？
• 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？
• 参与者是否会将外部的某些事件通知给该系统？
• 系统是否会将内部的某些事件通知该参与者？

用例规约(Use Case Specification)

针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。

• 简要说明 (Brief Description)
  简要介绍该用例的作用和目的。

• 事件流 (Flow of Event)
  包括基本流和备选流，事件流应该表示出所有的场景。

• 用例场景 (Use-Case Scenario)
  包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。

• 特殊需求 (Special Requirement)
  描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。

• 前置条件 (Pre-Condition)
  执行用例之前系统必须所处的状态。

• 后置条件 (Post-Condition)
  用例执行完毕后系统可能处于的一组状态。

用例规约-转帐.doc54.5kB

用例建模参考

健壮性分析

我们通过健壮性图进行健壮性分析:先绘制健壮性图，仔细检查用例文本，检查每一个 句子，然后根据句子的描述绘制出参与者、边界对象、实体对象和控制器以及图中不同元素间的关系。然后评审健壮性图，通过观察用例文本和图是否‘图文一致’ 来发现问题，修改用例文本，当然也要修改静态模型。在这个阶段，因该把一些关键属性添加到类图中。

• 边界对象
  参与者使用该对象与系统进 行交流，窗口、屏幕、对话框、菜单， 从原型、用例文本中识别

• 实体对象
  来自域模型;映射到数据表; 存取数据

• 控制对象
  该对象在边界对象与实体对象中扮演粘合剂;也称为控制体，体系 应用程序的逻辑;体现业务规则及策略; 在实现的时候可能不会是独立的类

健壮性分析的目的

• 检查用例的正确性及完整性
• 为MVC模型分离对象
• 为用例与设计之间填补语义缺口

健壮性分析的产出

• 健壮性图
• 具有详细属性的类图

健壮性图的规则

• 动作者只能与边界对象交谈
• 边界对象只能与控制体和动作者交 谈
• 实体对象只能与控制体进行交谈
• 控制体即能跟控制对象交谈，也能 跟边界对象交谈，不能跟动作者交谈

实例

需求

用例:进行交易

• 基本进程
  助理交易员使用债券交易输入窗口来输入本交易的初值，系统在处理该交易前验证 公共交易值与债券特殊值的有效性(例如 确定证券利率是合理的)
• 可替换过程
  如果验证失败，则通知用户，高亮显示错 误值，然后从用户处获得新值

健壮性图

时序图

动态模型的核心，描述了系统在运行时间的行为，包括系统如何完 成这些行为

目的

• 在边界、控制、实体对象中分配行为
• 显示运行期间各个对象之间的交互过程
• 确定类间的操作分配

产出

• 动态模型
• 静态模型

画时序图步骤

1、将用例描述复制到时序图的左 边空白处
2、添加实体对象
3、添加边界对象与参与者
4、设法解决控制体，一次一个， 然后弄清楚如何在协作对象中分配 行为

时序图要素

实例