面向对象分析与设计学习（一）

OOA&D的第一步，就是了解用户需求，并将其转换为业务用例图

这里要注意三点：

1、业务用例仅从系统业务角度关注的用例，而不是系统提供的用例，业务用例关心“系统该实现什么业务”而不是“系统提供了哪些功能”；

2、业务用例仅包含客户“感兴趣”的内容；

3、业务用例中所有用例必须是客户能够看得懂的用例，如果该用例客户看不懂，那么他就不适合做为业务用例。

OOA&D的第二步，就是为业务用例图中各个用例绘制活动图

活动图描述了这个业务用例中，用户可能会进行的操作序列。活动图有个很重要的使命：从业务用例分析出系统用例。

OOA&D的第三步，就是从活动图中选出系统用例

找出所有的备选系统用例后，我们要对他们进行合并和筛选。合并就是将相同的用例合并成一个，筛选就是将不符合系统用例条件的备选用例去掉。
一个系统用例应该是实际使用系统的用户所进行的一个操作

OOA&D的第四步，就是根据系统用例设计用户规约

用例规约唯一的要求就是“清晰易懂”

OOA&D的第五步，就是绘制业务领域类图

完成了上面几步，下面应该是绘制业务领域类图了。所谓业务领域类图要描述一下三点：

1、系统中有哪些实体；

2、这些实体能做什么操作；

3、实体间的关系。

这里要特别强调：这里的实体不是Actor，而是Actor使用系统时使用的所调用的实体，是处在系统边界之内的实体。

理解以上这段话非常重要，我经常看到由于混淆了实体和Actor的关系而导致画出的领域类图不准确或职责分配不准确。
大家可能还注意到，我们这里没有给出每个实体的属性。其实，在领域分析阶段，实体的属性并不重要，重要的是找出实体的操作。

OOA&D的第六步，就是绘制实现类图

以上这几步，就是分析的过程。而下面的步骤就是设计了。
1、设计没有分析那么好描述，因为分析是“客户面”，它只关心系统本身的功能和业务，而不关心任何和计算机有关的东西。但是，设计和平台、语言、开发模型等内容关系紧密，因而很难找出一个一致的过程。但是，一般在设计过程中实现类图是要绘制的。
2、实现类图和领域类图不一样，它描述的是真正系统的静态结构，是和最后的代码完全一致的。因此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。因此，实现类图是很复杂的，而且是平台技术有关的。

OOA&D的第七步，就是绘制序列图

有了静态结构，我们还要给出动态结构，这样，才能看清系统间的类是如何交互的，从而有效帮助程序员进行编码工作。
序列图在实际中是很多的，几乎每个类方法都配有相应的序列图。