面向对象分析.ppt

第9章 面向对象分析 9.1 面向对象分析过程面向对象分析过程 9.2 建立对象模型建立对象模型 9.3 建立动态模型建立动态模型 9.4 建立功能模型建立功能模型 9.5 定义服务定义服务 9.1 9.1 面向对象分析过程面向对象分析过程 1. 1. 分析过程概述分析过程概述 分析过程就是提取系统的需求的过程，是指为了满足用户的需求，系统必须“做什么”，而不是“怎么做”(系统如何实现)系统分析通常是从一个需求文档(陈述)和用户一系列的讨论开始的一般来说，由用户、领域专家、系统的开发者以及其他有关人员参加制定需求文档需求文档应给出一个完整的、一致的和灵活的描述，表明系统需求的一切，而且应是可管理的；需求文档应包括功能操作和操作特征，如使用的容易性、可靠性、可维护性等性能，还应包括软件必须处理的接口、适应环境以及其他设计上的约束 首先，系统分析员要对需求文档进行分析需求文档通常是不完整、不准确的，也可能还是非正式的通过分析可以发现和改正需求文档中的歧义性、不一致性，剔除冗余的内容，挖掘潜在的内容，弥补不足，从而使需求文档更完整、更准确在分析需求的过程中，系统分析员不仅应该反复、多次地与用户讨论、交流信息，还应该调研、观察、了解现有的类似系统。

快速地建立一个原型系统，通过在计算机上运行原型系统，使得分析员和用户尽快交流和相互理解，从而能更正确地、更完整地提取和确定用户的需求 然后，是需求建模系统分析员根据提取的用户需求，深入理解用户需求，识别出问题域内的对象，并分析它们相互之间的关系，抽象出目标系统应该完成的需求任务，并用OOA模型准确地表示出来，即用面向对象观点建立对象模型、动态模型和功能模型OOA模型是面向对象设计(OOD)的基础，它应该准确地、简洁地表示问题通过建立模型，可避免理解上的片面性，提高目标系统的正确性、可靠性在此基础上，编写出面向对象的需求规格说明 最后，是需求评审通过用户、领域专家、系统分析员和系统设计人员的评审，并进行反复修改后，确定需求规格说明 需求分析是复杂而又艰辛的过程系统分析人员应该多和用户交流，认真和领域专家探讨必须在领域专家的指导和密切配合下进行，才能有效地完成任务 2. 2. 实例需求文档实例需求文档 需求文档也叫需求陈述或问题陈述陈述需求是开发任何一个系统的首要任务主要陈述用户的需求，即该系统应该“做什么”， 而不是“怎么做”(系统如何实现)应该陈述系统任务是什么，而不是解决问题的方法。

需求陈述必须要将解决问题的目标清楚地表达出来，如果目标模糊，将会影响系统分析、设计和实现等后续开发阶段的工作分析人员和用户一起研究和讨论才能准确表达用户的要求，并找出遗漏的信息图9.1 ATM系统 ATM系统的需求陈述： 1) 问题综述 某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计算机、分行计算机及营业终端组成的网络系统ATM和中央计算机由总行投资购买总行拥有多台ATM，分别设在全市各主要街道上分行负责提供分行计算机和营业终端营业终端设在分行下属的各个储蓄所内该系统的软件开发成本由各个分行共同承担 2) 实施陈述 银行营业员使用营业终端处理储户提交的储蓄事务储户可以用现金或支票向自己拥有的某个账户内存款或开新账户，储户也可以从自己的账户中取款通常，一个储户可能拥有多个账户营业员负责把储户提交的存款或取款事务输进营业终端，接收储户交来的现金或支票，或者付给储户现金营业终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户 拥有银行账户的储户有权申请领取现金兑换卡使用兑换卡可以通过ATM访问自己的账户。

目前，仅限于用现金兑换卡在ATM上提取现金(即取款)，或查询有关自己账户的信息(例如，某个指定账户上的余额)将来可能还要求使用ATM办理转账、存款等事务 所谓现金兑换卡，就是一张特制的磁卡，上面有分行代码和卡号分行代码惟一标识总行下属的一个分行，卡号确定了这张卡可以访问哪些账户通常，一张卡可以访问储户的若干个账户，但是不一定能访问这个储户的全部账户每张现金兑换卡仅属于一个储户所有，但是，同一张卡可能有多个副本，因此，必须考虑同时在若干台ATM上使用同样的现金兑换卡的可能性也就是说，系统应该能够处理并发的访问 当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息首先，ATM要求用户输入密码，接下来，ATM把从这张卡上读到的信息以及用户输入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户密码如果用户输入的密码是正确的，ATM就要求用户选择事务类型(取款、查询等)当用户选择取款时，ATM请求用户输入取款额最后，ATM从现金出口输出现金，并且打印出账单交给用户。

 3. 3. 面向对象分析的三个模型与五个层次面向对象分析的三个模型与五个层次 1) 面向对象分析的三个模型 面向对象建模是面向对象分析的关键面向对象的模型包括：对象模型、动态模型和功能模型对象模型描述了系统的静态结构；动态模型描述了系统的互交次序；功能模型描述了系统的数据变换不同的问题，三个子模型的侧重程度不同，但是，对象模型是最基础的、最核心的、最重要的无论解决什么问题，首先要在问题域中提取和定义出对象模型当问题涉及用户界与过程控制时，动态模型是重点如果问题涉及大量数据变换，则功能模型非常重要对象模型中的操作(服务)可以出现在动态模型和功能模型内 2) 面向对象分析的五个层次 面向对象分析由五个主要活动组成，即确定类-＆-对象、识别结构、识别主题、定义属性和定义服务(方法)对于一个复杂问题的面向对象的模型可用五个层次表示：类-＆-对象层、结构层，主题层、属性层和服务层，见图9.2 主题(Subject)层：主题给出分析模型的总体概貌，是控制读者在同一时间所能考虑的模型规模的机制 类-&-对象(Class & Object)层：对象是数据及其处理的抽象。

它反映了保存有关信息和与现实世界交互的能力图9.2  对象模型的五个层次  结构(Structure)层：结构表示问题域的复杂性类 - 成员结构反映了一般 - 特殊关系，整体 - 部分结构反映了整体 - 部分的关系 属性(Attribute)层：属性是数据元素，用来描述对象或分类结构的实例，可在图中给出并在对象的储存中指定，即给出对象定义的同时，指定属性 服务(Serves)层：服务是接收到消息后必须执行的一些处理，可在图上标明它并在对象的储存中指定，即给出对象定义的同时，定义服务 五个层次就像合并在一起的五个透明的图层一样，每一层从不同角度将对象模型更细化、更具体化 3) 五个层次对应的五个活动 面向对象的模型的五个层次对应着分析建模的五个主要活动这五个活动的工作可以不按顺序进行，也没必要完成一项活动后才开始另一项活动工作也就是说，五个主要活动可以同时(并行)处理；可以从较高抽象层转移到较低的具体层，然后再返回到较高抽象层继续处理；当系统分析员在确定类-＆-对象的同时，想到该类的服务，则可以先确定服务后，再返回去继续寻找类-＆-对象；没有必要遵循自顶向下，逐步求精的原则。

 4) 面向对象分析流程 一般情况下，面向对象分析过程可按照下列流程进行：确定类-＆-对象、识别结构、识别主题、定义属性、建立动态模型、建立功能模型、定义服务(方法)但是，对于大型的、复杂的问题，不可能严格按照上面流程进行，需要反复多次进行寻找、确定、识别、建立和定义来构造模型，即先构造出模型的雏形或部分，再逐步扩充、修改、求精直至满意为止，最后，构造出符合问题域需求的正确的、准确的、完整的目标系统的模型，并编写出需求规格说明下面我们介绍三个模型的建立和五个层次的定义 9.2 9.2 建立对象模型建立对象模型 对象模型描述了系统的数据结构，它是三个模型的最关键的一个模型它的作用是描述系统的静态结构，包括构成系统的类和对象，它们的属性和操作，以及它们之间的联系面向对象方法是以对象为基础来构造系统，而不是以功能为基础来构造系统对象模型为建立动态模型和功能模型提供了实质性的框架对象模型是基础，动态模型和功能模型在此基础上创建也就是说，一个系统首先创建对象模型，然后再创建动态模型和功能模型 在建立对象模型时，我们的目标是从问题域中提炼出对目标系统有价值的概念对象模型描述了问题域中的类-＆-对象以及它们之间的关系，表示了目标系统的静态数据结构。

一般来说，当用户的需求变化时，静态数据结构相对来说比较稳定静态数据结构较少地依赖应用细节，因此，比较容易确定 对象模型通常有五个层次建立对象时，首先确定类-＆-对象和关联，对于大型复杂问题，还要进一步划分出若干个主题；然后给类和关联增补进一步描述的属性；接着利用继承关系适当的合并和组织类因为动态模型和功能模型更准确地描述了类中所提供的服务的需求，所以，类中操作(服务)需等到建立了这两个模型之后再确定 面向对象分析是复杂而又艰辛的过程，是系统分析员经反复迭代逐步深化的认知过程来创建模型，将初始的分析模型变为最终的分析模型也可以研究、借鉴以前对相同的或类似的问题域进行面向对象分析后所得到的结果，这样既可以实现重用，又可以提高系统分析效率9.2.1 9.2.1 确定类确定类- -＆＆- -对象对象 系统分析员的主要任务是在问题域中，通过分析找出客观存在的类-＆-对象首先，识别所有潜在的(候选的)类-＆-对象；然后，从潜在的类-＆-对象中筛选掉不正确的或不合适的，通过筛选，剔除冗余的类-＆-对象之后，精选出可作为目标系统的正式类-＆-对象 1. 1. 识别潜在的类识别潜在的类- -＆＆- -对象对象 1) 对象类型 对象是人们要研究的任何事物及对问题域中有意义的事物的抽象，它们既可能是物理实体，也可能是抽象概念(规则、计划和事件)。

具体地说，对象可分为如下几种类型： (1) 物理实体：指有形的实物，例如，飞机、汽车、计算机、书或机房等 (2) 人或组织的角色：例如，医生、教师、学生、工人、部门或公司等 (3) 事件：指在特定时间所发生的事，例如，飞行、演出、开会、访问或事故等 (4) 性能说明：指厂商对产品性能的说明，如产品名字、型号、规格和各种性能指标等 2) 初步分析 对象具有很强的表达能力和描述功能在面向对象分析时，可以参照上述几类常见事物，找出在当前问题域中潜在的类-＆-对象 另外，还可以以自然语言书写的需求文档(陈述)为依据，这种分析方法比较简单，是一种非正式分析文档中的名词可作为潜在(候选)的类-＆-对象，形容词可作为线索来确定属性，动词可作为潜在的服务(操作)找出候选者之后，还必须经过严格地筛选，清除掉那些不正确的或不必要的事物，保留正确的或必要的事物这个结果可作为更详细、更精确的正式的面向对象分析的雏形，当然，也是正式的面向对象分析的一个良好的开端 3) 实例分析 下面以ATM系统为例，说明非正式分析过程仔细阅读9.1节给出的需求陈述，从陈述中找出下列名词作为类-＆-对象的初步的候选者。

银行、自动取款机(ATM)、系统、中央计算机、分行计算机、营业终端、网络、总行、分行、软件、成本、市、街道、营业厅、储蓄所营业员、储户、现金、支票、账户、事务、现金兑换卡、余额、磁卡、分行代码、卡号、用户、副本、信息、密码、类型、取款额、账单以及访问等 通常，在需求陈述中不会一个不漏地写出问题域中所有有关的类-＆-对象，因此，分析员应该根据领域知识或常识进一步把隐含的类-＆-对象提取出来例如，在ATM系统的需求陈述中虽然没写“通信链路”和“事务日志”，但是，根据领域知识和常识可以知道，在ATM系统中应该包含这两个实体 2. 2. 筛选出正确的类筛选出正确的类- -＆＆- -对象对象 在现实世界中，存在着许多对象，但仅可讨论而已，不能全部纳入系统中去通过非正式分析找出的候选对象，仅仅是提供给分析员的初步的候选者，接下来，还应该对每个候选对象进行严格考察、筛选，从中去掉不正确的或不必要的，仅保留正确的或必要的对象这些对象才确实是应该记录其信息或需要其提供服务的对象 假定已经找到了一个候选对象，这时又发现了另一个可能成为对象的实体，那么，是否应该将它作为对象放到模型中去呢？这时应该根据下列准则筛选对象，剔除不正确或不必要的类-＆-对象。

 1) 剔除冗余准则 若两个类表达了同样的信息，则应该保留在此问题域中最富于描述力的那个名称，去掉冗余的类 上面初步分析得出了ATM系统的34个候选的类，其中，储户与用户，现金兑换卡与磁卡及副本分别描述了相同的信息，因此，应该将“用户”、“磁卡”、“副本”等冗余的类去掉，仅保留“储户”和“现金兑换卡”这两个类 2) 无关准则 删除那些与问题没有多少关系或根本无关的类，仅把与问题密切相关的类-＆-对象放进目标系统中有些类在其他问题中可能很重要，但与当前要解决的问题无关，同样也应该把它们删掉如，在ATM系统中，应该去掉 “成本”、“市”、“街道”、“营业厅”和“储蓄所”等候选类因为，该系统并不处理软件开发成本的问题，而且ATM和营业员终端放置的地点与本软件的关系也不大 3) 模糊准则 在初步分析时，列出来的作为候选的类-＆-对象中，可能有一些模糊的、泛指的名词，其中，有的是系统无须记忆的信息；有的是在需求陈述中，它们所暗示的事务，有更明确更具体的名词来表示因此，通常应去掉这些笼统的或模糊的类在ATM系统中，“银行”实际指总行或分行，“访问”在这里实际指事务，“信息”的具体内容在需求陈述中随后就指明了。

此外，还有一些笼统含糊的名词因此，在本例中，应该去掉“银行”、“网络”、“系统”、“软件”、“信息”和“访问”等候选类 4) 属性准则 对象是用属性来描述的，若有些名词只是其他对象的属性的描述，则应该把这些名词从候选类-＆-对象中去掉当然，如果某个性质具有很强的独立性，则应把它作为类而不是作为属性在ATM系统中，“现金”、“支票”、“取款额”、“账单”、“余额”、“分行代码”、“卡号”、“密码”和“类型”等，实际上都应该作为属性而不是作为类在分析人员考虑不周的地方，该准则能帮助他筛选潜在的对象 5) 操作准则 在需求陈述中，有时可能使用一些既可作为名词又可作为动词的词，此时，应根据它们在本问题中的含义来决定它们是作为类还是作为类中定义的操作 例如，通常把“拨号”当作动词，当构造模型时，确实应该把它作为一个操作，而不是一个类但是，在开发的自动记账系统时，把“拨号”作为重要的一个类，因为，它有自己的日期、时间、受话地点等属性总之，当一个操作具有属性需独立存在时，应该作为类-＆-对象而不是作为类的操作 6) 实现准则 在分析阶段，应该去掉仅和实现有关的候选的类-＆-对象。

这是因为，在设计和实现阶段，这些类-＆-对象可能是重要的，但是，目标系统实现不应该在分析阶段考虑，不然会分散我们的注意力 例如，在ATM系统中，“事务日志”无非是对一系列事务的记录，它的确切表示方式是面向对象设计的议题；“通信链路”在逻辑上是一种联系，在系统实现时它是关联链的物理实现因此，应该暂时去掉“事务日志”和“通信链路”这两个类，在设计或实现时再考虑它们 综上所述，在ATM系统的例子中，经过初步筛选，剩下了下列类-＆-对象：ATM、中央计算机、分行计算机、营业终端、总行、分行、营业员、储户、账户、事务和现金兑换卡等9.2.2 9.2.2 确定关联确定关联 两个或多个对象之间的相互依赖、相互作用的关系就是关联一般情况下，在初步分析问题域中的类-＆-对象确定之后，接着就可以分析、确定类-＆-对象之间存在的关联关系由于在整个开发过程中，从OOA→OOD，面向对象概念和表示符号都是一致的，因此，分析员可以不按照这样的工作顺序，灵活地选取自己习惯的工作方式 分析、确定关联，能促使分析员考虑问题域的边缘情况，有助于发现那些潜在的类-＆-对象 聚集关系(整体 - 部分关系)是关联的一个特例，在分析、确定关联的过程中，不必明确地去区分关联和聚集。

 1. 1. 初步确定关联初步确定关联 通常，关联关系在需求陈述中，使用描述性动词或动词词组来表示因此，通过分析需求陈述，首先，直接提取需求陈述中的动词词组来初步确定多数的关联，然后，还能挖掘一些在陈述中隐含的关联最后，根据问题域实体间的相互依赖、相互作用关系，分析员还应该与用户及领域专家讨论，作再进一步的补充 以ATM系统为例，用直接提取动词短语得出关联、 需求陈述中隐含关联和根据问题域知识得出关联等方法，经过分析，初步确定出如表9.1所示的关联在表9.1中，标“×”符号的关联表示是删掉的关联，标“△×”符号的关联表示是分解后又删掉的关联表表9.1 9.1 确定确定ATMATM系统的关联系统的关联确定方法关        联直接提取动词短语得出关联 (1)  ATM、中央计算机、分行计算机及营业员终端组成网络 (×) (2) 总行拥有多台ATM (△×)(3)  ATM设在主要街道上 (×)(4) 分行提供分行计算机和营业终端 (△×)   (5) 营业终端设在分行营业厅及储蓄所内 (×)(6) 分行分摊软件开发成本 (×)(7) 储户拥有账户 (8) 分行计算机处理针对账户的事务 (△×)(9) 分行计算机维护账户 (△×)(10) 营业终端与分行计算机通信 (11) 营业员输入针对账户的事务 (△×)(12) ATM与中央计算机交换关于事务的信息 (△×)(13) 中央计算机确定事务与分行的对应关系 (△×)(14) ATM读现金兑换卡 (×)(15) ATM与用户交互 (×)(16) ATM输出现金 (×)(17) ATM打印账单 (×)(18) 系统处理并发的访问 (×)续表确定方法关        联需求陈述中隐含关联(19) 总行由各个分行组成(20) 分行保管账户(21) 总行拥有中央计算机(22) 系统维护事务日志 (×)(23) 系统提供必要的安全性 (×)(24) 储户拥有现金兑换卡 根据问题域知识得出关联(25) 现金兑换卡访问账户 (26) 分行聘用营业员 续表进一步完善关联(27) 中央计算机与分行通信(中央计算机确定事务与分行的对应关系改名)(28) 营业员输入事务 (营业员输入针对账户的事务的分解)(29) 事务修改账户 (同上)(30) 分行计算机处理事务 (分行计算机处理针对账户的事务的分解)(31) 事务处理账户 (同上)(32)  ATM与中央计算机通信 (ATM与中央计算机交换关于事务的信息)(33) 在ATM上输入事务 (同上)(34) 总行拥有中央计算机 (总行拥有多台ATM的分解)(35) 分行保管账户 (分行计算机维护账户)(36) 事务修改账户 (同上)(37) 分行拥有分行计算机(分行提供分行计算机和营业终端的分解)(38) 分行拥有营业终端 (同上)(39) 营业员输入营业事务(增补)(40) 营业事务输进营业终端(增补)(41) 在ATM上输入远程事务(增补)(42) 远程事务由现金兑换卡授权(增补) 2. 2. 筛选筛选 1) 删除已去掉的类之间的关联 在分析、确定类-＆-对象的过程中，如果已经删掉了某个候选类，则与这个类有关的关联也应该删掉，或用其他类重新表达这个关联。

例如，在ATM系统中，由于已经删掉了“系统”、“网络”、“市”、“街道”、“成本”、“软件”、“事务日志”、“现金”、“营业厅”、“储蓄所”和“账单”等候选类，因此，与这些类有关的八个(表9.1中的(1)，(3)，(5)，(6)，(16)，(17)，(22)，(23))关联也应该删掉 2) 删除与问题无关的关联或实现阶段的关联 在侯选类中，应该把与本问题域无关的关联或与实现密切相关的关联删去 例如，在ATM系统中，“系统处理并发的访问”只提醒我们在实现阶段需要使用实现并发访问的算法，以处理并发事务，并没有标明对象之间的新关联(表9.1中序号为(18)的关联)，因此，应删去它 3) 删除瞬时动作 关联应该描述问题域的静态结构，而不应该是一个瞬时事件，因此应删除瞬时事件的关联 例如，在ATM系统中，“ATM读现金兑换卡”描述了ATM与用户交互周期中的一个动作，它并不是ATM与现金兑换卡之间的固有关系，因此应该删去类似地，还应该删去“ATM与用户交互”这个候选的关联表9.1中序号为(14)和(15)的关联) 如果用动作表述的需求隐含了问题域的某种基本结构，则应该用适当的动词词组重新表示这个关联。

例如，在ATM系统的需求陈述中，“中央计算机确定事务与分行的对应关系”隐含了结构上“中央计算机与分行通信”的关系(表9.1中序号为(13)的关联)，因此，应该删去 4) 多元关联分解 多元关联是三个或三个以上对象之间的关联，多数可以分解为二元关联或用词组描述成限定的关联 例如，在ATM系统中，“营业员输入针对账户的事务”可以分解成“营业员输入事务”和“事务修改账户”两个二元关联，而“分行计算机处理针对账户的事务”也可以做类似的分解(表9.1中序号为(11)和(8)的关联)ATM与中央计算机交换关于事务的信息”这个候选的关联，实际上隐含了“ATM与中央计算机通信”和“在ATM上输入事务”这两个二元关联(表9.1中序号为(12)的关联) 5) 派生关联 有的关联可以用已有的、必要的关联来定义时，应该去掉这些冗余的关联 例如，在ATM系统中，“总行拥有多台ATM” 派生了“总行拥有中央计算机”和‘ATM与中央计算机通信”这两个关联，而“分行计算机维护账户”的实际含义是，“分行保管账户”和“事务修改账户”(表9.1中序号为(2)和(9)的关联) 3. 3. 完善关联完善关联 经过筛选后余下的关联不够精确、完善时，应该进一步分解和增补，以调整关联。

改进方法如下： 1) 重命名 关联的命名相当重要，准确的名字有利于读者理解因此，如有不合适的、含义不清的名字，应该重新选择含义更明确的名字来作为关联名 例如，将“分行提供分行计算机和营业员终端”改为“分行拥有分行计算机”和“分行拥有营业员终端”就更明确些(在表9.1中序号为(4)的关联) 2) 分解 为了能够适用于不同的关联，必要时应该分解以前确定的类-＆-对象 例如，在ATM系统中，应该把“事务”分解成“远程事务”和“营业事务” 3) 增补 发现了遗漏的关联或分解类-＆-对象之后需要新关联时，应该及时增补 例如，在ATM系统中，把“事务”分解成上述两类之后，需要补充“营业员输入营业事务”、“营业员事务输进营业终端”、“在ATM上输入远程事务”和“远程事务由现金兑换卡授权”等关联(表9.1序号为(39)、(40)、(41)和(42)的关联) 4) 标明阶数 当确定各个关联的类型之后，可以初步地确定关联的阶数随着系统分析反复改进，阶数也会经常改动 图9.3是经上述分析过程之后得出的ATM系统的原始对象图图9.3 ATM系统初始对象模型图9.2.3 9.2.3 确定属性确定属性 1. 1. 为何确定属性为何确定属性 属性是用来描述类-&-对象的特性的。

一个属性是一个数据项(状态信息)，类中对象都有相应的值(状态)目前，面向对象分析模型越来越专门化，而且更加详细，每个类-&-对象都由属性描述，而属性则按照类-＆-对象的规范来描述属性放在类-&-对象表示符号的中间部位 在面向对象分析中，“属性”用来反映问题域和系统的任务属性能帮助我们更深入、更具体的认识类-＆-对象和结构，换句话说，属性能为“类-＆-对象”以及“结构”提供更多的细节，因此，在一个系统中，确定属性是非常重要的 2. 2. 如何确定属性如何确定属性 选择属性的过程包括分析和选择两步一般来说，分析强调对象的外观或功能，选择则强调目标系统的需求 属性是对象的性质，通常用名词词组和形容词来表示首先，在需求陈述中找出属性或通过分析找出属性这些属性必须是问题域中对象的基本性质，而且在目标系统中是必要的也就是说，只考虑与目标系统相关的属性，不考虑超出目标系统范围的属性然后，删除不正确的和不必要的属性，选择正确的和必要的属性最后，恰当的给属性命名 删除属性的标准如下： 1) 区别对象和属性 对象是在应用领域内具有自身性质的实体若某个实体的独立存在相当重要，而相比之下它的值不那么重要，则应把它作为一个对象而不是对象的属性。

同一个实体在不同的应用领域中是作对象还是作属性，需要根据应用需求具体分析而定例如，在邮政目录中，“城市”是一个属性，而在人口普查中，“城市”却看作为对象  2) 区别链属性和属性 在分析过程中，不应该把链属性作为对象的属性若某个性质依赖于某个关联链的存在，则该性质是链属性而不是属性链属性在多对多关联中很明显，在整个开发过程中，不要把它作为两个关联对象中任意一个的属性 3) 区别限定词和属性 当属性固定下来后，能减少关联的阶数时，则可将该属性重新定义成为一个限定词如ATM系统中，分行代码、聘员号、账号和站号等都是限定词，而不要把它误认为属性再如，在图9.3中，“分行代码”不但可作为关联“分行组成总行”上的限定词，也可作为关联“中央计算机”与“分行计算机”的限定词，这样，就将该关联的一对多的通信关系减少为一对一的通信关系 4) 区别内部值和属性 若某个性质是对象的非公开的内部状态时，则应该将这个属性从对象模型中删掉 5) 避免细化 一个对象的属性不能过于细化，在分析过程中，应去掉那些对大多数操作没有影响的属性 经过以上精选后，确定的ATM系统中的各个类的属性可参见图9.4所示。

在9.4图中，又增补了一些限定词图9.4 带有属性与主题的ATM对象模型 (1) “卡号”：前面的分析过程中，遗漏了“分行发放现金兑换卡”这一关联，现在发现了，因而就把“卡号”这个限定词补上 (2) “账号”是关联“分行保管账号”上的限定词 (3) “聘员号”是关联“分行聘用营业员”上的限定词 (4) “站号”是关联“分行拥有营业终端”、“营业终端与分行计算机通信”和“中央计算机与ATM通信”等上的限定词9.2.4 9.2.4 确定主题确定主题 1. 1. 为何确定主题为何确定主题 主题是一种指导开发者或用户研究大型复杂模型的机制主题是一种手段，有助于分解大型项目以便分组承担任务此外，主题还可以给出面向对象分析和设计的模型总体概貌 主题所依据的原理是整体 - 部分关系的扩充一个系统模型可以包含多个主题，也就是说，主题是整个问题域和系统任务的一部分，是用来与整个问题域和系统任务(总体)进行通信的部分 2. 2. 如何确定主题如何确定主题 是否划分主题要看目标系统的大小，若开发很小的系统，则没必要划分主题；若开发大型、复杂的系统，则为了降低复杂程度，应将系统再进一步划分成几个不同的主题，使得开发者便于分组承担任务，小组成员能集中精力考虑承担范畴内的内容。

对于含有较多对象的系统，应采用选择、精炼和构造的方法来确定主题首先，由高级分析员粗略地识别对象和关联，然后初步选择主题经进一步分析，在更深入了解系统结构的基础上，修改和精炼主题最后，按问题领域构造出一个主题(主题编号和主题名) 按问题领域确定主题，应该将相互间依赖和交互较多的对象确定为同一个主题我们确定“总行”、“分行”和“ATM”等为ATM系统中的三个主题，用①、②和③分别表示这三个主题的编号，如图9.4所示 该例不是很复杂，可以不引入主题层，在这里主要是为了说明如何确定主题为了使图简单、清晰，在下面的章节中讨论这个例子时将忽略主题层9.2.5 9.2.5 识别结构识别结构 1. 1. 为何识别结构为何识别结构 确定了类的属性后，就可以利用继承来共享公共的性质，以结构的形式重新组织类结构是问题域复杂关系的表示，它与系统的任务直接相关一般 - 特殊结构具有继承性，一般类和对象的属性和方法一旦被识别，即可在特殊类和对象中使用 2. 2. 如何识别结构如何识别结构 通常，可用以下两种方法来建立继承(分类)关系 1) 自底向上识别 自底向上识别是抽象出现有类的共同性质来一般化成父类，找出具有相似的属性、操作和关联的类来发现继承。

例如，在ATM系统中，“远程事务”和“营业事务”可以一般化为“事务”(父类)也可以将“ATM”和“营业终端”一般化为“输入站”(父类)在识别中，应尽可能应用现实世界中的常用分类结构，如不能直接使用现有的类，可以将属性或类稍加细化再表示出来 2) 自顶向下识别 自顶向下识别是把现有的类细化为更具体的子类，通常，具体化的子类可以在应用领域中直接找出来如具体化类与现有实际情况矛盾时，说明该类定义不当，需要重新考虑例如，在ATM系统中，“远程事务”和“营业事务”是“事务”(父类)的具体化类(子类)同样，“ATM”和“营业终端”是“输入站”(父类)的具体化类(子类)在类层次结构中，特殊类共有的属性应放在父类中特殊类中应定义自己独有的属性，当然它可以继承父类的属性加入继承的ATM对象模型如图9.5所示图9.5 带有属性和继承的ATM对象模型9.2.6 9.2.6 优化对象模型优化对象模型 通过以上各步，对象模型就建立起来了，但这样不能确保模型是完全正确的，还应反复修改，不断完善与优化在建模的各个阶段，一旦发现了缺陷，就必须返回到前面阶段进行修改有些细化工作(如定义服务)要等到动态模型和功能模型建完以后才能进行。

在建模的过程中，不一定按前述的工作顺序进行，分析员完全可以以自己的独特方法进行，既可以将几个阶段并行处理，又可以随意组织前述工作顺序如果是初次使用面向对象方法，建议还是按照前述顺序进行比较好 1. 1. 删除冗余的类删除冗余的类 如果某类中缺少属性、操作和关联，则可删除该类 2. 2. 分解类分解类 “现金兑换卡”可分为“卡权限”和“现金兑换卡”两个功能，前者表示储户访问账户的权限，后者则表示含有分行代码和卡号的数据载体 3. 3. 补充关联补充关联 一个“事务”由若干个“更新”组成，它们构成整体 - 部分关系一个“更新”是一个动作，即对账户所做的一次处理，如存款、取款、查询等更新”有类型、金额等属性，所以，可补充定义成为一个单独类，“事务”与它构成整体-部分关系 4. 4. 合并类合并类 如在一个应用系统中，两个类虽然名字不同，但是它们所完成的任务以及与其他类的关系也相同，这时可将这两个类合并成为一个类例如，“分行”与“分行计算机”合并为“分行” 同样，可将“总行”与“中央计算机”合并成为“总行” 通过进一步的优化，得出如图9.6所示的ATM对象模型。

图9.6 优化后的ATM对象模型9.3 9.3 建立动态模型建立动态模型 当对象模型建立起来后，接着可以建立动态模型动态模型的概念和表示方法前一章已经介绍了，本节以ATM系统为例，对动态模型的建立方法给予叙述 建立动态模型对于每个系统并不是都重要，这要看开发系统的类型而定对于数据库系统来说，动态模型并不重要，如果是交互式系统，建立动态模型却是非常重要的 对于一个系统来说，功能模型指明了系统应该“做什么”，而动态模型则明确规定了“什么时候做”即在何种状态下、接受了什么事件的触发，来确定对象的可能事件的顺序 建立动态模型的步骤： (1) 编写典型的对话脚本； (2) 从脚本中提取出事件，联系该事件与其目标对象； (3) 组织事件的顺序和状态(采用状态图描绘)； (4) 比较各个不同对象的状态图，检查对象之间的一致性，确保事件之间的匹配9.3.1 9.3.1 编写脚本编写脚本 1. 1. 脚本的概念脚本的概念 当系统与用户交互时，为了对目标系统的行为有更具体的认识，用脚本表示系统的行为脚本描述用户(或其他外部设备)与目标系统之间的一个或多个典型的交互过程，利用脚本来建立动态模型。

在建立动态模型的过程时，为了确保整个交互过程的正确性和清晰性，不遗漏重要的交互步骤，首先要编写脚本，为建立动态模型奠定基础 脚本是事件序列，当系统中的对象与外部用户发生互换信息时，就产生一个事件，所呼唤的信息值就是该事件的参数对于事件来说，确定触发事件的动作对象和该事件的参数是非常重要的屏幕布局和输出格式是外观的界面，一般是不会影响交互行为的逻辑和所交换的信息的 2. 2. 准备脚本准备脚本 有时，在需求陈述中已经描写了完整的交互过程，但还需要花很大精力构思交互的形式ATM系统的需求陈述虽然表明了应从储户那里获得有关事务的信息，但并没有准确说明获得信息的具体过程和需要什么参数，动作顺序如何等还是模糊的因此，编写脚本的过程，是分析用户对系统交互行为的需求的过程，需要用户参与，提出意见，并审查和更改 首先，编写正常情况的脚本然后，考虑特殊情况脚本，例如输入或输出的数据的值域最后，考虑用户出错情况脚本，例如，非法输入值或响应失败等此外，还应该考虑在基本交互行为之上的“通用”交互行为，如帮助要求和状态查询等表表9.2 ATM9.2 ATM系统的正常情况下的脚本系统的正常情况下的脚本序号脚          本1ATM请储户插卡；储户插入一张现金兑换卡2ATM接受该卡并读它上面的分行代码和卡号3ATM要求储户输入密码；储户输入自己的密码，如“5461”等数字4 ATM请求总行验证卡号和密码；总行要求“9”号分行核对储户密码，然后通知ATM说这张卡有效5ATM要求储户选择事务类型(取款、转账、查询等)；储户选择“取款”6ATM要求储户输入取款额；储户输入如“505”等数字7 ATM确认取款额在预先规定的限额内，然后要求总行处理这个事务；总行把请求转给分行，该分行成功地处理完这项事务并返回该账户的新余额8ATM输出现金并请储户拿走这些现金；储户拿走现金9ATM问储户是否继续这项事务；储户回答“不”10ATM打印账单，退出现金兑换卡，请储户拿走它们；储户取走账单和卡表表9.3 ATM9.3 ATM系统的异常情况下的脚本系统的异常情况下的脚本序号脚          本1ATM请储户插卡；储户插入一张现金兑换卡2ATM接受这张卡并顺序读它上面的数字3ATM要求密码；储户误输入如“5555”等数字4ATM请求总行验证输入的数字和密码；总行在向有关分行咨询之后拒绝这张卡5ATM显示“密码错”，并请储户重新输入密码；储户输入“5461”等数字；ATM请总行验证后知道这次输入的密码正确6ATM请储户选择事务类型；储户选择“取款”7ATM询问取款额；储户改变主意，不想取款了，随之按“取消”键8ATM退出现金兑换卡，并请储户拿走它；储户拿走他的卡9ATM请储户插卡9.3.2 9.3.2 事件跟踪图事件跟踪图 准备好脚本，就为建立动态模型奠定了必要的基础；然后，需进一步明确事件及事件与对象的关系，可以画出事件跟踪图；接着在脚本和事件跟踪图的基础上，再画出状态图；最后，由状态图组成动态模型。

然而，在画出事件跟踪图之前，首要任务是进一步确定事件及事件与对象的关系 1. 1. 确定事件确定事件 前面准备的脚本，理解时不是很简明，可能存在歧义性为了有助于建立动态模型，应该认真分析脚本的各个步骤，以便从中确定所有外部事件事件包括系统与用户(或外部设备)交互的所有信号、输入、输出、中断和动作等从脚本中容易发现正常事件，但是，应注意不要遗漏了出错条件和异常事件 例如，储户插入现金兑换卡、储户输入密码和ATM输出现金等都是对象的动作事件再如，储户插入现金兑换卡与系统要求密码，是对象到对象的交互行为的事件 通过分析，在应用系统中，找出系统所有的事件后，还需要确定事件与对象的关系也就是对于一个事件来说，哪个对象是事件的发送者，哪个对象又是事件的接收者某事件对于发送者来说是输出事件，对于接收者来说则是输入事件有时一个事件可能既是输出事件又是输入事件，这是因为对象将事件发给了自己 2. 2. 画出事件跟踪图画出事件跟踪图 经过分析，确定事件以及每类事件的发送对象和接收对象之后，可以将脚本进一步扩充，画出事件跟踪图，即不同对象间的事件排序表事件跟踪图能形象、清晰地表示事件序列以及事件与对象的关系。

在事件跟踪图中，一个类-＆-对象用一条竖线表示，每个事件用一条水平的箭头线表示，箭头从事件的发送对象出发指向接收对象事件按照先后顺序排列，也就是说，画在最上面的水平箭头线代表最先发生的事件，画在最下面的水平箭头线所代表的事件最晚发生箭头线之间的间距，并不表示两个事件之间的精确时间差，箭头线的相对位置仅表示事件发生的先后次序图9.7 ATM系统正常情况下的事件跟踪图9.3.3 9.3.3 状态图状态图 画出事件跟踪图后，可根据事件跟踪图再画出状态图状态图描绘事件与对象状态的关系如果一个事件可以驱动某个对象从一种状态变为另一种状态，那么由该事件引起的状态改变称为“转换"某个对象接收了一个事件以后，会转换成什么样的状态，这取决于该对象的当前状态和所接收的事件 1. 1. 确定状态图中的事件与类确定状态图中的事件与类- -＆＆- -对象对象 一般情况下，状态图确定了由事件序列引出的状态序列，因而，可用一张状态图描绘一类对象的行为在动态模型中，并不是任何一个类-＆-对象的行为都需要用一张状态图描绘，我们只需考虑那些具有重要交互行为的类就行了 2. 2. 状态图表示状态图表示 一个状态图反映对象接收和发送的事件：每个脚本或事件跟踪图都对应状态图中的一条路径(即箭头线)，路径上应标以事件名；两个事件之间的间隔就是一个状态，应给每个状态取个有意义的名字。

这就是事件和状态的一个序列初始图 3. 3. 画状态图的策略画状态图的策略 1) 考虑分支点 画出了初始状态图之后，再合并其他脚本的事件跟踪图到该初始的状态图中首先，在以前考虑过的脚本中找出分支点，例如，“验证账户”是个分支点，因为验证的结果可能是“账户有效”，也可能是“无效账户”然后，把其他脚本中的事件序列作为一条可选的路径并入已有的状态图中 2) 考虑异常情况 状态图不但要考虑正常事件，还需要考虑边界情况、特殊情况和异常情况(例如，用户要求取消正在处理事务)当发生了异常事件后，系统应给出出错处理的脚本，并且并入已有的状态图中 3) 补充遗漏情况 状态图的构造应考虑所有脚本，并且在包含影响某类对象状态的全部事件因而，在完成初始状态图后，应进一步检查状态图，发现有遗漏的情况，应该立即补充遗漏脚本，并且并入已有的状态图中 4. 4. 实例分析实例分析 在ATM系统中，“现金兑换卡”、“事务”和“账户”等是被动对象，并不发送事件；“储户”和“营业员”是系统外部的动作对象，无须在系统内实现它们；“ATM”、“营业终端”、“总行”和“分行”都是相互发送事件的主动对象，由于“营业终端”的状态图和“ATM”的状态图类似，因此，只需要考虑它们的状态图。

“ATM”、“总行”和“分行”的状态图请见图9.8、图9.9和图9.10这些状态图都是简化的、粗略的，尤其对异常情况和出错情况等考虑不周(例如，图9.8并没有表示在网络通信链路不通时的系统行为，在这种情况下，ATM停止处理储户事务)图9.8 ATM类的状态图图9.9 总行类的状态图图9.10 分行类的状态图9.3.4 9.3.4 优化动态模型优化动态模型 每个类的动态行为用一张状态图来描绘，各个类的状态图通过共享事件合并起来，从而构成系统的动态模型也就是说，动态模型是基于事件共享而互相关联的一组状态图的集合多个类的状态图完成之后，还需要检查系统级的完整性和一致性每个事件应该有个发送者和接收者，当发送者和接收者是同一个对象时，对无前驱或后续的状态应该着重检查，如果这种状态既不是交互序列的起点，又不是终点，则一定是个错误 在ATM系统中，如总行类的状态图中，事件“分行代码错”是由总行发出的，但是在ATM类的状态图中，并没有一个状态接收这个事件因此，在ATM类的状态图中应该再补充一个状态“do：显示分行代码错信息”，它接收由前驱状态“do：验证账户”发出的事件“分行代码错”，它的后续状态是“退卡”。

9.4 9.4 建立功能模型建立功能模型 1. 1. 基本系统模型图基本系统模型图 基本系统模型是用来确定系统的边界和输入/输出数据流的基本系统模型仅包含一个加工，它代表被开发系统的加工和变换数据的整体功能它的输入流是该系统的输入数据，输出流是系统的输出数据输入/输出数据是系统与外部世界之间的交互事件的参数数据由数据源点(外部实体)流入系统，经过系统处理后，流出到数据终点(外部实体) ATM系统的基本系统模型请见图9.11它包含两个外部实体，一个是储户，它既是数据源点又是数据终点，储户将事务(如，密码、事务类型、金额等)由营业员通过营业终端提交给系统，或系统可给储户提供信息(如，金额、账单等)；另一个是现金兑换卡，它是数据源点，系统从它上面读取分行代码和卡号等信息图9.11 ATM系统的基本系统模型 2. 2. 细化数据流图细化数据流图 首先，把基本系统模型中的处理框逐步分解，得到描述系统加工和变换数据的基本功能的若干个处理框，然后，构成功能级数据流图ATM系统的功能级数据流图如图9.12所示图9.12 ATM系统的功能级数据流图 3. 3. 功能描述功能描述 当数据流图分解到一定程度后，就应该对图中各个处理进行描述。

描述功能可用自然语言、流程图、IPO图(或表)和伪码等工具，描述可用说明性的或过程性的说明性描述着重描述处理所代表的功能；过程性描述着重描述实现处理功能的算法 例如，“更新账户”处理的功能描述如下： 更新账户处理 输入：账户，数量，事务类型；输出：现金，收据，信息IF 取款数目超过账户当前余额 THEN 退出事务，不付出现金；IF 取款数目不超过账户当前余额 THEN 记账并付出储户要求的现金；IF 事务是存款 THEN 建立账户并无现金付出；IF 事务是状态请求 THEN 无现金付出； 在上述任何情况下，显示账单内容为：ATM编号、日期、时间、账户编号、事务类型、事务数量(若有)以及新的余额9.5 9.5 定定 义义 服服 务务 1. 1. 访问对象属性的操作访问对象属性的操作 在对象模型中，对类中定义的每个属性都是可以访问的，应该提供访问这些属性的服务因此，需要定义访问这些属性的读、写操作这些操作在对象模型中没有显式表示出来，但隐含在属性内 2. 2. 来自事件驱动的操作来自事件驱动的操作 发往对象的事件驱动修改对象状态(即属性值)，对象被驱动后的行为可定义成为一个操作，并通过执行该操作提供相应的服务。

也就是说，当对象接收到事件后，在事件驱动下完成相应的服务例如，在ATM系统中，发往分行的事件“请分行验卡”驱动该对象的服务“验证卡号”；而事件“处理分行事务”驱动分行对象的服务“更新账户” 3. 3. 处理对应的操作处理对应的操作 数据流图中的每个处理都对应于一个对象(也可能是若干个对象)上的操作可将完成每个处理的功能定义成为相应的操作例如，在ATM系统中，数据流图上的处理“验证密码”就可以定义成为一个“验证密码”操作，该分行对象通过执行这个操作提供“验证密码”服务 4. 4. 消除冗余操作消除冗余操作 利用继承机制减少服务定义将相似类(子类)中共享的属性和操作，最好定义在父类中，可利用继承关系消除冗余的定义，共享的属性和操作，简化实现。