主题

内容

第一部分 ICONIX过程概述

讨论：代码为啥改来改去？

如何使用最少的投入完成从需求到编码的过度

较小UML建模技术—ICONIX思想

构造系统时的重要问题

谁是系统的用户(参与者)，他们想完成何种工作？

何为“现实世界”(问题域)对象，它们之间存在何种联系？

每个用例需要何种对象？

在每次用例交互，对象是如何协作的？

如何处理实时控制问题？

在具体细节上，实际上准备如何建立该系统？

ICONIX OOA&OOD框架

ICONIX过程—4个阶段

第二部分 面向对象分析

绘制高层类图

领域建模

领域的概念

领域建模的目的

领域建模的产出

域类的较佳来源

领域建模的活动：

识别类

建立归纳关系

建立类间关联

开发关联类

绘制高层类图

领域建模训练

领域建模综述

领域建模10个典型的错误

• 10.立刻给关联指定多重度（multiplicity）,确保每个关联都有明确的多重度

• 9.对名词和动词做过度的分析，而背离初衷

• 8.不对用例和时序图进行研究，就将操作分配给类

• 7.在确保已满足用户需求之前，对代码进行优化以提高重用性

• 6.对于每个“部分(part-of)”关联，就使用聚集还是组合(composition)而争论不休

• 5.未对问题空间进行建模之前，就假定一种具体的实现策略

• 4.将类命名为难以理解的名称，而不是直观的名称

• 3.直接进行实现结构，如友元关系和参数化类

• 2.在域类和关系型数据库表之间建立1对1的映射

• 1.对早的执行“模式化”，将导致根据同用户问题毫无关系的模式创建解决方案

用例建模

用例的基本概念

用例建模的目的

用例建模的产出

分析层用例

设计层用例

用例之间的关系

归纳关系

包含关系

扩展关系

用例图

用例描述

练习：用例建模

原型

原型概述

原型法工作流程

原型法的优缺点

关于原型系统的基本原则

• 区分两种原型系统： 抛弃型原型 演化型原型

• 原型化难以理解的需求

• 尽快将抛弃型原型交付给客户,不必考虑质量

• 必须注意精选正要开发的原型系统所包含的特性,使其能真正达到预期的目的

• 决不把抛弃型原型系统发展成为系统

• 利用原型减少软件开发的风险

与原型有关的度量数据

需求评审

需求评审10条典型的错误

第三部分 面向对象初步设计

面向对象初步设计概述

建立需求与设计之间的桥梁

健壮性分析

健壮性分析的目的

健壮性分析的产出

健壮性分析的流程

• 1，检查用例的正常性

• 2，检查用例的完整性

• 3，对象确认

• 4，初步设计：对象分类

• 5，执行健壮性分析

• 6，更新域（静态）模型

对象分类

• 边界对象

• 实体对象

• 控制对象

健壮性图的规则

• 动作者只能与边界对象交谈

• 边界对象只能与控制体和动作者交谈

• 实体对象只能与控制体进行交谈

• 控制体即能跟控制对象交谈，也能跟边界对象交谈，不能跟动作者交谈

案例：健壮性分析

练习：健壮性分析

健壮性分析与静态模型的反馈循环

初步设计评审

第四部分  面向对象详细设计

面向对象详细设计概述

面向对象详细设计

详细设计的目的

详细设计的产出

详细设计的流程

动态模型

时序图

状态图

活动图

协作图

动态模型注意点

• 过度使用这些图会导致分析崩溃

• 不要为具有两种状态的对象绘制状态图

• 协作图在实时、分布式系统中是实用的

• 要避免分析崩溃就要知道需要建立那些模型

• 不要为建模而建模

10个绘制时序图的要点

• 10.需要为每个用例绘制一张顺序图。

• 9.顺序图应该匹配于相关用例的叙述流。

• 8. 为每一个完整的用例绘制一张唯一的时序图，只有管理唯一的顺序图非常困难的时候，才把图分开。

• 7.对象间的消息调用类上的操作。

• 6.如果在开始绘制顺序图时陷入困境，很可能是因为没有正确编写用例或没有完成健壮性分析。

• 5.通过研究系统的动态行为，了解包含在静态模型中的类需要哪些属性与操作

• 4.牢记顺序图时制定行为分配的工具。

• 3.当在详细层上研究系统用法时，其实是在给问题域对象添加解决方案空间对象。

• 2.把基础结构、框架和帮助者对象纳入设计，设计模式通常是有帮助的，这是OOD真正发生的地方

• 1.在顺序图空白处写下最初的需求层文本，这提供了可视化需求跟踪

关键设计评审

第五部分  面向对象分析设计总结

10种导致用例分析崩溃的做法

• 10.在静态模型中的每个关联末尾放置基数指示器。

• 9.为每个功能需求编写一个用例。

• 8.为每张顺序图绘制一张协作图。

• 7.每张协作图上包含整个脚本，不侧重关键事务。

• 6.为静态模型中的每个类绘制状态图。

• 5.在协作图上花费几小时处理消息信号。

• 4.为整个系统绘制一张巨大的多层级的状态图。

• 3.通过顺序图直接从需求层用例跳到详细设计。

• 2.在需求模型结束之前，做了大量的详细设计工作，在需求结束后，重复几次设计。

• 1.创建了数以百计的状态图，每张状态图包含两种状态。