现在要象之前那个HeadFirst 面向对象的那篇文章一样，对一个面向对象建模的过程进行一个描述。
第一步：能过用例划定需求
需求分析是一个大问题，有一种用来发现和列举需求的特别技术，这就是用例建模。
我在需要在开始开发前就给出一个系统需要完成的功能清单。
用例是用文件或图片的开式，去描述一个系统中特定的目的或结果。
需求大概可以分为以下两种，一种是功能性需求，这种需求是要求系统必须完成某种目的或者是用户要求实现的系统所拥有的功能。
另一种是技术性需求，这主要涉及系统的内部如何构建，以满足功能需求。
要获取完全的需求，必须让用户参与进来。最终用户是最了解系统功能的专家，在定义用例的阶段就让用户参与进来是基本的要求。理想情况下，应该让用户或代码撰写部分或全部的用例，并且请他们确认用例的正确性。
操作者代表了成型后的系统要交互的对象，它驱动了用例。操作者一般可以分成两类，一类是人，一类是系统本身。必须为系统的每种角色创建一个操作者，这些角色代表各系统有关的用户。要区分这些角色，我闪一般会先查阅需求规格说明书。
我们应该尽早确定系统功能覆盖的范围，避免需求膨胀或范围延伸。
一旦确定了系统的操作者，我们就可能想要为他们创建用例图。事实上，用例是系统行为的签名。
用例的开发过程是迭代的，当后面的用例已经不再发生变化，我们的工作可能就完成了。通过充分询问和回访用户，小组定期走查所有用例，才能保证不遗漏重要的用例。
第二步：对系统的静态、数据方面进行建模
确立需要创建和实体化何种对象类型的过程称为准备静态模型.
描述对象如何协作才能满足需求的过程称为动态模型.
为了给系统确定合适的类,我们需要搜寻和收集各种信息,并且不断的进行排除.
我们可以对需求规格说明书进行名词的提取.然后进行步精简候选的类列表.接着重新察看用例,确定这些是否应该被看成类.
在分析的早期阶段,我们还要用数据字典,对于每个候选类,数据字典应当包含基于系统上下文的对该条目的简单定义,以及有助于说明该定义的例子.
接着我们要开始决定类间的关系,可以通过对需求规格说明书上进行动词短语分析.
要决定每个域类的attribute时,我们要重新研究一下前面那些被我们剔除的候选类,很有可能,它就就是arrtibute
在静态建模的时候,肯定是少不了UML符号的,我们要用它来画类图,画对象图.
第三步,对系统的动态/行为方面建模
类图的构件有:类,关联/聚合,Attribute,普通化/特殊化的类层次,操作/方法
为了决定方法该是什么,必须实例我们对于系统静态结构的了解,创建一个动态模型来完善模型.在这个环节里,我们会接触到事件,预想场景,时序图,协作图
第四步,对模型进行总结
到这,关于对象建模就差不多完了.接着,我们还得测试一下我们的模型,重新检查一下需求,重用模型.
第五步,编程
首先搭建环境,对于群集类的使用十分重要.
一开始我们可以开发出命令驱动的程序.
我们要回顾一下系统的类图,进一步减少类图中无用的特性
接着,我们要进一步完美我们的应用程序,增加持久化特性
接着,我们可以开始添加图形化用户界面
最后测试,
最后交付...