分析过程得出的最重要的文档资料是软件需求规格说明(在面向对象分析中，主要由对象模型、动态模型和功能模型组成)。 　　面向对象分析(OOA)的关键是识别出问题域内的类与对象，并分析它们相互间的关系，最终建立起问题域的简洁、精确、可理解的正确模型。 　　在用面向对象观点建立起的三种模型中，对象模型是最基本、最重要、最核心的。

　　　　　　　　　　　　　　　　　　　面向对象开发过程的应用生存期模型

　　　　　　　　　　　　　　　　　　　　　　　　　　OOA分析过程

面向对象建模得到系统3子模型： 　　静态结构——对象模型 　　交互次序——动态模型 　　数据变换——功能模型

动态模型和功能模型中都包含了对象模型中的操作(即服务或方法)。复杂问题的对象模型通常由5个层次组成，这5个层次，一层比一层显现出对象模型的更多细节。在概念上，这5个层次是整个模型的5张水平切片。

5个层次对应着在面向对象分析过程中建立对象模型的5项主要活动：

在概念上可以认为，面向对象分析大体上按照下列顺序进行： 　　寻找类与对象，识别结构，识别主题，定义属性，建立动态模型，建立功能模型，定义服务。 　　但是，分析不可能严格地按照预定顺序进行，大型、复杂系统的模型需要反复构造多遍才能建成。 　　通常，先构造出模型的子集，然后再逐渐扩充，直到完全、充分地理解了整个问题，才能最终把模型建立起来。

需求陈述的内容包括：问题范围，功能需求，性能需求，应用环境及假设条件等。 　　　需求陈述应该阐明“做什么”，指出哪些是系统必要的性质，哪些是任选的性质。 　　　不能指望没有经过全面、深入分析的需求陈述是完整、准确、有效的。随后进行的面向对象分析的目的，就是全面深入地理解问题域和用户的真实需求，建立起问题域的精确模型。

自动取款机(ATM)系统，如图所示。 　　某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计算机、分行计算机及柜员终端组成的网络系统。ATM和中央计算机由总行投资购买。总行拥有多台ATM，分别设在全市各主要街道上。分行负责提供分行计算机和柜员终端。柜员终端设在分行营业厅及分行下属的各个储蓄所内。该系统的软件开发成本由各个分行分摊。 　　银行柜员使用柜员终端处理储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户内存款或开新账户。储户也可以从自己的账户中取款。通常，一个储户可能拥有多个账户。柜员负责把储户提交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。 　　拥有银行账户的储户有权申请领取现金兑换卡。 使用现金兑换卡可以通过ATM访问自己的账户。目前仅限于用现金兑换卡在ATM上提取现金(即取款)，或查询有关自己账户的信息(例如，某个指定账户上的余额)。将来可能还要求使用ATM办理转账、存款等事务。 所谓现金兑换卡就是一张特制的磁卡，上面有分行代码和卡号。分行代码惟一标识总行下属的一个分行，卡号确定了这张卡可以访问哪些账户。 　　通常，一张卡可以访问储户的若干个账户，但是不一定能访问这个储户的全部账户。每张现金兑换卡仅属于一个储户所有，但是，同一张卡可能有多个副本，因此，必须考虑同时在若干台ATM 上使用同样的现金兑换卡的可能性。也就是说，系统应该能够处理并发的访问。 当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。 　　首先，ATM要求用户输入密码，接下来ATM把从这张卡上读到的信息以及用户输入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务。中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户密码。如果用户输入的密码是正确的，ATM就要求用户选择事务类型(取款、查询等)。当用户选择取款时，ATM请求用户输入取款额。最后，ATM从现金出口吐出现金，并且打印出账单交给用户。

用面向对象方法开发绝大多数软件时，首先建立对象模型，然后再建立另外两个子模型。

对象模型通常有5个层次，有一定的开发步骤和规律： 　　首先确定对象类和关联①，对于大型复杂问题还要进一步划分出若干个主题②； 　　其次为类和关联增添属性③，进一步描述它们；利用适当的继承④关系进一步合并和组织类； 　　暂时不确定类中操作⑤（服务，建立动态模型和功能模型之后，更准确地描述了对类中提供的服务的需求）。 　　面向对象的分析过程，是一个需要反复迭代、逐步深化、逐步完善的过程。

类与对象在问题域中客观存在的，需要通过分析找出这些类与对象，具体做法：

对象是对问题域中有意义的事物的抽象，大多数客观事物可分为下述5类： 　　(1) 可感知的物理实体；例如：飞机、汽车、书、 　　房屋等等。 　　(2) 人或组织的角色；例如：医生、教师、雇主、雇员、计算机系、财务处等等。 　　(3) 应该记忆的事件；例如：飞行、演出、访问、交通事故等等。 　　(4) 两个或多个对象的相互作用，通常具有交易或接触的性质；例如：购买、纳税、结婚等等。 　　(5) 需要说明的概念；例如：政策、保险政策、版权法等等。 可参照上述5类常见事物，找出候选类与对象。

另一种是非正式分析（更简单）。 　　这种分析方法以用自然语言书写的需求陈述为依据，把陈述中的名词作为类与对象的候选者，用形容词作为确定属性的线索，把动词作为服务(操作)的候选者。 　　当然，这种方法选取的候选者往往不准确，须经更进一步的严格筛选。 　　 　　以ATM系统为例，说明非正式分析过程。

银行，自动取款机(ATM)，系统，中央计算机，分行计算机，柜员终端，网络，总行，分行，软件，成本，市，街道，营业厅，储蓄所，柜员，储户，现金，支票，账户，事务，现金兑换卡，余额，磁卡，分行代码，卡号，用户，副本，信息，密码，类型，取款额，账单，访问。 根据领域知识或常识进一步把隐含的类与对象提取出来：“通信链路”和“事务日志”。

严格考察每个候选对象，去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象。 　　筛选时主要依据下列标准，删除不正确或不必要的类与对象：

如果两个类表达了同样的信息，则应该保留在此问题域中最富于描述力的名称。 　　用非正式分析法得出了34个候选的类。 　　其中储户与用户、现金兑换卡与磁卡及副本，分别描述了相同的两类信息，因此，应该去掉“用户”、“磁卡”、“副本”等冗余的类，仅保留“储户”和“现金兑换卡”这两个类。

许多对象与系统无关，应该把它们删掉。 　　在ATM系统中，不处理分摊软件开发成本问题，并且ATM和柜员终端放置的地点与本系统关系不大。 　　因此，应该去掉候选类“成本”、“市”、“街道”、“营业厅”和“储蓄所”。

通常把笼统的或模糊的类去掉。 　　在ATM系统中，“银行”实际指总行或分行， “访问”在这里实际指事务，“信息”的具体内容在需求陈述中随后就指明了。此外还有一些笼统含糊的名词。总之，在本例中应该去掉“银行”、“网络”、“系统”、“软件”、“信息”、“访问”等候选类。

在需求陈述中有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类与对象中去掉。 　　在ATM系统的例子中，“现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”、“类型”等，实际上都应该作为属性对待。

在需求陈述中一些既可作为名词，又可作为动词的词，应确定作为类还是作为类中定义的操作。 　　例如，谈到电话时“拨号”通常当作动词，当构造电话模型时确实应该把它作为一个操作，而不是一个类。但在开发电话的自动记账系统时，“拨号”需要有自己的属性(日期、时间、受话地点等)，应该把它作为一个类。 　　本身具有属性需独立存在的操作，应该作为类与对象。

应该去掉仅仅和实现有关的候选的类与对象（分析阶段不要过早考虑实现，分散注意力）。 　　在ATM系统的例子中，“事务日志”是对一系列事务的记录，它是面向对象设计的议题；“通信链路”在逻辑上是一种联系，在系统实现时它是关联类的物理实现。 应该暂时去掉“事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们。

综上所述，在ATM系统的例子中，经过初步筛选，剩下下列类与对象：ATM、中央计算机、分行计算机、柜员终端、总行、分行、柜员、储户、账户、事务、现金兑换卡。(11个类对象)

两个或多个对象之间的相互依赖、相互作用的关系就是关联。 　　确定关联，能促使分析员考虑问题域的边缘情况，有助于发现那些尚未被发现的类与对象。

在需求陈述中使用的描述性动词或动词词组，通常表示关联关系，大多数关联可以通过直接提取需求陈述中的动词词组而得出。

进一步分析需求陈述，还能发现陈述中隐含的关联。另外与用户及领域专家对问题域实体间的相互依赖、作用关系，再进一步补充一些关联。

以ATM系统为例，经分析初步确定出下列关联：

ATM、中央计算机、分行计算机及柜员终端组成网络；

总行拥有多台ATM；

ATM设在主要街道上；

分行提供分行计算机和柜员终端；

柜员终端设在分行营业厅及储蓄所内；

分行分摊软件开发成本；储户拥有账户；

分行计算机处理针对账户的事务；

分行计算机维护账户。

柜员终端与分行计算机通信；柜员输入针对账户的事务；

ATM与中央计算机交换关于事务的信息；中央计算机确定事务与分行的对应关系；

ATM读现金兑换卡；

ATM与用户交互；

ATM吐出现金； ATM打印账单；

系统处理并发的访问。

分行保管账户；总行拥有中央计算机；系统维护事务日志；系统提供必要的安全性；储户拥有现金兑换卡。

根据下述标准删除候选的关联：

删除那些已被删除的候选类相关的关联。 已删除的候选类：系统、网络、市、街道、成本、软件、事务日志、现金、营业厅、储蓄所、账单等；与这些类有关的下列8个关联也应该删去： ①ATM、中央计算机、分行计算机及柜员终端组成网络； ②ATM设在主要街道上； ③分行分摊软件开发成本； ④系统提供必要的安全性； ⑤系统维护事务日志； ⑥ATM吐出现金； ⑦TM打印账单； ⑧柜员终端设在分行营业厅及储蓄所内。

例如：例子中“系统处理并发的访问”，并发事件没有设计对象间的新关联（没有提供新的关联），它只是需要在实现阶段实现并发访问的算法，以处理并发事务。

关联应该描述问题域的静态结构，而不应该是一个瞬时事件。 　　例如：“ATM读现金兑换卡”描述了ATM与用户交互周期中的一个动作，并不是ATM与现金兑换卡之间的固有关系→删去。 类似，删去“ATM与用户交互”候选的关联。

一般将三个或三个以上对象间的关联，分解为二元关联或用词组描述成限定的关联。 　　在ATM系统中，“柜员输入针对账户的事务” 可分解成“柜员输入事务”和“事务修改账户” 这样两个二元关联。 　　“分行计算机处理针对账户的事务”同上分解。 　　“ATM与中央计算机交换关于事务的信息”候选关联，隐含了“ATM与中央计算机通信”和“在ATM上输入事务”这两个二元关联。 (5) 派生关联 去掉可以用其他关联定义的冗余关联。 在ATM系统的例子中： “总行拥有多台ATM ”实质上是“总行拥有中央计算机”和“ATM与中央计算机通信”这两个关联组合的结果； “分行计算机维护账户”的实际含义是“分行保管账户”和“事务修改账户”。

从几个方面进一步完善经筛选后余下的关联：

选择含义更明确的名字作为关联名。 “分行提供分行计算机和柜员终端”改为： “分行拥有分行计算机” “分行拥有柜员终端”。

分解以前确定的类与对象，以适用不同的关联。 在ATM系统中，应把“事务”分解成“远程事务”和“柜员事务”（12个类与对象）。

发现了遗漏的关联及时补上。 在ATM系统中，把“事务”分解成上述两类之后，需要补充“柜员输入柜员事务”、“柜员事务输进柜员终端”、“在ATM上输入远程事务” 和“远程事务由现金兑换卡授权”等关联。

初步判定各关联类型，并粗略确定关联的重数，伴随着对问题认识的逐渐深入，重数也会改动。 12个类与对象：ATM、中央计算机、分行计算机、柜员终端、总行、分行、柜员、储户、账户、“远程事务”、“柜员事务”、现金兑换卡。 　各类对象之间的关联： 总行拥有中央计算机（1:1）； ATM与中央计算机通信(n:1)；总行由各分行组成(1:n); 分行拥有分行计算机(1:1)；分行拥有柜员终端(1:n)；储户拥有账户(1:n)；柜员终端与分行计算机通信(n:1) ；柜员输入柜员事务(1:n); 分行保管账户(1:n); 柜员事务修改账户(1:n); 柜员终端输入柜员事务(1:n)；中央计算机与分行计算机通信(1:n) ； ATM输入远程事务(1:n)；远程事务修改帐户(n:1) ; 现金兑换卡授权远程事务(1:n) ；储户拥有现金兑换卡(1:n) ；现金兑换卡访问账户(n:n) ；分行雇用柜员(1:n) ； 下图是经上述分析过程之后得出的ATM系统原始的类图：

为了降低复杂度，将一个大的系统再进一步划分成几个不同的主题。 当系统对象较多（系统规模较大），可参照如下进行：先识别出类与对象和关联，然后划分主题，并用它作为指导开发者和用户观察整个模型的一种机制； 对于规模极大的系统，则首先由高级分析员粗略地识别对象和关联，然后初步划分主题，经进一步分析，对系统结构有更深入的了解之后，再进一步修改和精炼主题。

划分主体的原则： 应按问题领域而不是用功能分解方法来确定主题。另外，各个主题内对象应较少依赖和交互。 以ATM系统为例，可以把它划分成总行（包含总行和中央计算机这两个类）、分行（包含分行、分行计算机、柜员终端、柜员事务、柜员和账户等类）和ATM（包含ATM、远程事务、现金兑换卡和储户等类）等3个主题。 教材中ATM系统是一个简化的系统，将不考虑主题层。

属性是对象的性质，藉助于属性我们能对类与对象和结构有更深入更具体的认识。注意，在分析阶段不要用属性来表示对象间的关系，使用关联能够表示两个对象间的任何关系，而且把关系表示得更清晰、更醒目。 一般说来，确定属性的过程包括分析和选择两个步骤。

属性是对象的性质，确定属性有助于我们对类与对象和结构有更深入更具体的认识。 确定属性的过程包括分析和选择两个步骤。

一般在需求陈述中用名词词组表示属性，例如 “汽车的颜色”或“光标的位置”。 往往用形容词表示可枚举的具体属性，例如， “红色的”、“打开的”。 此外还需要领域知识和常识才能分析得出需要的属性。 由于属性对问题域的基本结构影响很小。结构相对稳定，属性可能随时间的推移而改变了。 在分析中首先找出最重要的属性，再逐渐把其余属性增添进去。

删掉不正确的或不必要的属性：

如果某个实体的独立存在比它的值更重要，则应把它作为一个对象而不是对象的属性。同一个实体在不同应用领域中可扮演

如果某个性质依赖于某个关联链的存在，则该性质是关联类的属性，在分析阶段不应该把它作为一般对象的属性。 如：学生选课程（n:m）,成绩是关联类属性。

在ATM系统的例子中，“分行代码”、“账号”、“雇员号”等都是限定词。 使用关系限定符可以

产品 AK47 = new 产品Finder().Find产品ByName(“AK47”); decimal price = AK47.价格s[2008].标准价格; 或者为价格Finder添加一个 FindBy产品Id年度() 函数 产品 AK47 = new 产品Finder().FindByName(“AK47”); 价格 AK47价格 = new 价格Finder().FindBy产品Id年度(AK47.产品 Id, 2008); decimal price = AK47价格.标准价格

如果某个性质是对象的非公开的内部状态，则应该从对象模型中删掉这个属性。

在分析阶段应该忽略那些对大多数操作都没有影响的属性。

往往是由于类的划分不准确造成，分解成两个不同的类。 经过筛选之后，得到ATM系统中各个类的属性，如图所示：

继承关系的建立实质上是知识抽取过程，它应该反映出一定深度的领域知识，因此必须有领域专家密切配合才能完成。 可使用两种方式建立继承(泛化)关系：

模拟人类归纳思维过程，从现有类抽象出共同性质泛化出父类。 例如，在ATM系统中，“远程事务”和“柜员事务”是类似的，可以泛化出父类“事务”； 可以从“ATM”和“柜员终端”泛化出父类“输入站”。

模拟人类的演绎思维过程，从现有类细化成更具体的子类。 这个过程比较自然，但避免过细。 如图是增加了继承关系之后的ATM对象模型。

面向对象开发过程是反复修改、逐步完善的过程。 　　相对结构分析、设计技术而言，面向对象更容易实现反复修改、逐步完善的过程。 　　下面以ATM系统为例，讨论可能做的修改：

“现金兑换卡”它是ATM获得分行代码和卡号等数据的数据载体，又具有鉴别储户使用ATM的权限的卡的两个独立功能。 “现金兑换卡”类→“卡权限”和“现金兑换卡”两个类，将使每个类的功能更单一。 10.3.6 反复修改

“分行”与“分行计算机”对分析系统没有区别的意义→合并。类似合并“总行”和“中央计算机”。 如图是修改后的ATM对象模型，更简单、清晰。

动态模型，UML状态图、结构化分析状态转换图。 对于仅存储静态数据的系统(例如数据库)来说，动态模型并没有什么意义，例如：MIS。 在开发交互式系统时，动态模型起着很重要的作用，具体步骤：

脚本是系统在某一执行期间内出现的一系列事件，是对用户(或设备)与目标系统之间的交互过程的描述。 　　脚本的目的：对目标系统的行为进一步的认识。 脚本的内容： 　　①编写正常情况的脚本； 　　②考虑特殊情况，例如输入或输出的数据为最大值(或最小值) ； 　　③考虑出错情况，例输入的值为非法值或响应失败。

用户界面不是分析阶段考虑的重点（信息流和控制流作为重点），但是也需要考虑用户界面，确保能够完成全部必要的信息交换，而不会丢失重要的信息。 　　　图是初步设想出的ATM界面格式。

状态图的绘制步骤： 　　①完整、正确的脚本； 　　②事件跟踪图（简易的UML顺序图）； 　　③状态图。 　　因为，脚本用自然语言书写，阅读时会有二义性。 　　确定事件，分析各脚本（正常、异常），提取所有外部事件（包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断、动作等等）。正常事件易找，异常事件和出错条件易遗漏。传递信息的对象的动作、大多数对象到对象的交互行为都对应着事件。 　　如图所示，事件跟踪图（简易顺序图）。 竖线——对象，横线——事件，箭头——作用方向。

状态图描绘事件与对象状态的关系。 　　集中精力仅考虑具有重要交互行为的那些类。 　　事件序列引出状态序列。 具体方法： 　　选定事件跟踪图中的一条竖线（一个类对象），仅考虑指向该条竖线的那些箭头线（事件），将这些事件作为状态图中的有向边(即箭头线)，边上标以事件名。 　　两个事件之间的间隔就是一个状态。 　　根据一张事件跟踪图画出状态图之后，再把其他脚本的事件跟踪图合并到已画出的状态图中。 　　例如ATM系统，在考虑正常情况后，需要考虑异常情况。 　　为此需在事件跟踪图中找出以前考虑过的脚本的分支点(例如“验证账户”就是一个分支点，因为验证的结果可能是“账户有效”，也可能是“无效账户”，然后把其他脚本中的事件序列并入已有的状态图中，作为一条可选的路径。

在ATM系统中： 　　“ATM”、“柜员终端”、“总行”和“分行” 都是主动对象，它们相互发送事件； 　　“现金兑换卡”、“事务”和“账户”是被动对象，并不发送事件。 　　“储户”和“柜员”虽然也是动作对象，但是，它们都是系统外部的因素，无须在系统内实现它们。 　　因此，只需要考虑“ATM”、“总行”、“柜员终端”和“分行”的状态图，如下各图（由于“柜员终端”同“ATM”类似，略）。

ATM类的状态图 

在完成了每个具有重要交互行为的类的状态图之后，应该检查系统级的完整性和一致性。

以ATM系统为例。在总行类的状态图中，事件 “分行代码错”是由总行发出的，但是在ATM类的状态图中并没有一个状态接受这个事件。因此，在ATM类的状态图中应该再补充一个状态“do/显示分行代码错信息”，它接受由前驱状态“do/验证账户”发出的事件“分行代码错”，它的后续状态是“退卡”。

通常在建立了对象模型和动态模型之后再建立功能模型。 功能模型由一组数据流图组成。 其中的处理功能可以用IPO图(或表)、伪码等多种方式进一步描述。

描述处理框的功能——要着重描述每个处理框所代表的功能，而不是实现功能的具体算法。 可利用IPO图、伪代码等。

在确定类中服务时应考虑如下:

类中定义的每个属性都是可访问的，即都定义了读、写该类每个属性的操作（服务）。 但这些常规操作一般不在类图中显示表示（设计时考虑即可）。

在状态图中，事件是某对象接收到的消息，根据消息选择符指定的操作修改对象状态(即属性值)，并启动相应的服务。 　　例如ATM系统： 　　　发往ATM对象的事件“中止”，启动该对象的服务“打印账单”； 　　　发往分行的事件“请分行验卡”启动该对象的服务“验证卡号”； 　　　事件“处理分行事务”启动分行对象的服务 　　　“更新账户”。

综合考虑状态图和数据流图，确定对象应提供服务。 　　例如，在ATM系统中，从状态图上看出分行对象应该提供“验证卡号”服务，而在数据流图上与之对应的处理框是“验卡”，根据实际应该完成的功能看，该对象提供的这个服务应该是“验卡”。

只要不违背领域知识和常识，就尽量抽取出相似类的公共属性和操作，以建立这些类的新父类，并在类等级的不同层次中正确地定义各个服务。