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