第10章面向对象分析
不论采用哪种方法开发软件，分析的过程都是提取系统需求的过程。分析工作主要包括3项内容，这就是理解、表达和验证。首先，系统分析员通过与用户及领域专家的充分交流，力求完全理解用户需求和该应用领域中的关键性的背景知识，并用某种无二义性的方式把这种理解表达成文档资料。分析过程得出的最重要的文档资料是软件需求规格说明(在面向对象分析中，主要由对象模型、动态模型和功能模型组成)。
由于问题复杂，而且人与人之间的交流带有随意性和非形式化的特点，上述理解过程通常不能一次就达到理想的效果。因此，还必须进一步验证软件需求规格说明的正确性、完整性和有效性，如果发现了问题则进行修正。显然，需求分析过程是系统分析员与用户及领域专家反复交流和多次修正的过程。也就是说，理解和验证的过程通常交替进行，反复迭代，而且往往需要利用原型系统作为辅助工具。
面向对象分析(OOA)的关键是识别出问题域内的类与对象，并分析它们相互间的关系，最终建立起问题域的简洁、精确、可理解的正确模型。在用面向对象观点建立起的3种模型中，对象模型是最基本、最重要、最核心的。
10.1面向对象分析的基本过程
10.1.1 概述
面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程。
通常，面向对象分析过程从分析陈述用户需求的文件开始。可能由用户(包括出资开发该软件的业主代表及最终用户)单方面写出需求陈述，也可能由系统分析员配合用户，共同写出需求陈述。当软件项目采用招标方式确定开发单位时，“标书”往往可以作为初步的需求陈述。
需求陈述通常是不完整、不准确的，而且往往是非正式的。通过分析，可以发现和改正原始陈述中的二义性和不一致性，补充遗漏的内容，从而使需求陈述更完整、更准确。因此，不应该认为需求陈述是一成不变的，而应该把它作为细化和完善实际需求的基础。在分析需求陈述的过程中，系统分析员需要反复多次地与用户协商、讨论、交流信息，还应该通过调研了解现有的类似系统。正如以前多次讲过的，快速建立起一个可在计算机上运行的原型系统，非常有助于分析员和用户之间的交流和理解，从而能更正确地提炼出用户的需求。
接下来，系统分析员应该深入理解用户需求，抽象出目标系统的本质属性，并用模型准确地表示出来。用自然语言书写的需求陈述通常是有二义性的，内容往往不完整、不一致。分析模型应该成为对问题的精确而又简洁的表示。后继的设计阶段将以分析模型为基础。更重要的是，通过建立分析模型能够纠正在开发早期对问题域的误解。
在面向对象建模的过程中，系统分析员必须认真向领域专家学习。尤其是建模过程中的分类工作往往有
很大难度。继承关系的建立实质上是知识抽取过程，它必须反映出一定深度的领域知识，这不是系统分析员单方面努力所能做到的，必须有领域专家的密切配合才能完成。
在面向对象建模的过程中，还应该仔细研究以前针对相同的或类似的问题域进行面向对象分析所得到的结果。由于面向对象分析结果的稳定性和可重用性，这些结果在当前项目中往往有许多是可以重用的。
10.1.2 3个子模型与5个层次
正如9.3节所述，面向对象建模得到的模型包含系统的3个要素，即静态结构(对象模型)、交互次序(动态模型)和数据变换(功能模型)。解决的问题不同，这3个子模型的重要程度也不同：几乎解决任何一个问题，都需要从客观世界实体及实体问相互关系抽象出极有价值的对象模型；当问题涉及交互作用和时序时(例如，用户界面及过程控制等)，动态模型是重要的；解决运算量很大的问题(例如，高级语言编译、科学与工程计算等)，则涉及重要的功能模型。动态模型和功能模型中都包含了对象模型中的操作(即服务或方法)。
复杂问题(大型系统)的对象模型通常由下述5个层次组成：主题层、类与对象层、结构层、属性层和服务层，如图10.1所示。
这5个层次很像叠在一起的5张透明塑料片，它们一层比一层显现出对象模型的更多细节。在概念上，这5个层次是整个模型的5张水平切片。
在本书第9章中已经讲述了类与对象(即UML的“类”)、结构(即类或对象之间的关系)、属性和服务的概念，现在再简要地介绍一下主题(或范畴)的概念。主题是指导读者(包括系统分析员、软件设计人员、领域专家、管理人员、用户等，总之，”读者”泛指所有需要读懂系统模型的人)理解大型、复杂模型的一种机制。也就是说，通过划分主题把一个大型、复杂的对象模型分解成几个不同的概念范畴。心理研究表明，人类的短期记忆能力一般限于一次记忆5～9个对象，这就是著名的7±2原则。面向对象分析从下述两个方面来体现这条原则：控制可见性和指导读者的注意力。
首先，面向对象分析通过控制读者能见到的层次数目来控制可见性。其次，面向对象分析增加了一个主题层，它可以从一个相当高的层次描述总体模型，并对读者的注意力加以指导。
上述5个层次对应着在面向对象分析过程中建立对象模型的5项主要活动：出类与对象，识别结构，识别主题，定义属性，定义服务。必须强调指出的是，我们说的是。”5项
活动”，而没有说5个步骤，事实上，这5项工作完全没有必要顺序完成，也无须彻底完成一项工作以后再开始另外一项工作。虽然这5项活动的抽象层次不同，但是在进行面向对象分析时并不需要严格遵守自顶向下的原则。人们往往喜欢先在一个较高的抽象层次上工作，如果在思考过程中突然想到一个具体事物，就会把注意力转移到深入分析发掘这个具体领域，然后又返回到原先所在的较高的抽象层次。例如，分析员出一个类与对象，想到在这个类中应该包含的一个服务，于是把这个服务的名字写在服务层，然后又返回到类与对象层，继续寻问题域中的另一个类与对象。
通常在完整地定义每个类中的服务之前，需要先建立起动态模型和功能模型，通过对这两种模型的研究，能够更正确更合理地确定每个类应该提供哪些服务。
综上所述，在概念上可以认为，面向对象分析大体上按照下列顺序进行：寻类与对象，识别结构，识别主题，定义属性，建立动态模型，建立功能模型，定义服务。但是，正如前面已经多次强调指出过的，分析不可能严格地按照预定顺序进行，大型、复杂系统的模型需要反复构造多遍才能建成。通常，
先构造出模型的子集，然后再逐渐扩充，直到完全、充分地理解了整个问题，才能最终把模型建立起来。
分析也不是一个机械的过程。大多数需求陈述都缺乏必要的信息，所缺少的信息主要从用户和领域专家那里获取，同时也需要从分析员对问题域的背景知识中提取。在分析过程中，系统分析员必须与领域专家及用户反复交流，以便澄清二义性，改正错误的概念，补足缺少的信息。面向对象建立的系统模型，尽管在最终完成之前还是不准确、不完整的，但对做到准确、无歧义的交流仍然是大有益处的。
10.2 需求陈述
10.2.1 书写要点
通常，需求陈述的内容包括：问题范围，功能需求，性能需求，应用环境及假设条件等。
总之，需求陈述应该阐明“做什么”而不是“怎样做”。它应该描述用户的需求而不是提出解决问题的方法。应该指出哪些是系统必要的性质，哪些是任选的性质。应该避免对设计策略施加过多的约束，也不要描述系统的内部结构，因为这样做将限制实现的灵活性。对系统性能及系统与外界环境交互协议的描述，是合适的需求。此外，对采用的软件工程标准、模块构造准则、将来可能做的扩充以及可维护性要求等方面的描述，也都是适当的需求。
书写需求陈述时，要尽力做到语法正确，而且应该慎重选用名词、动词、形容词和同义词。
不少用户书写的需求陈述，都把实际需求和设计决策混为一谈。系统分析
员必须把需求与实现策略区分开，后者是一类伪需求，分析员至少应该认识到它们不是问题域的本质性质。
需求陈述可简可繁。对人们熟悉的传统问题的陈述，可能相当详细，相反，对陌生领域项目的需求，开始时可能写不出具体细节。
绝大多数需求陈述都是有二义性的、不完整的、甚至不一致的。某些需求有明显错误，还有一些需求虽然表述得很准确，但它们对系统行为存在不良影响或者实现起来造价太高。另外一些需求初看起来很合理，但却并没有真正反映用户的需要。应该看到，需求陈述仅仅是理解用户需求的出发点，它并不是一成不变的文档。不能指望没有经过全面、深入分析的需求陈述是完整、准确、有效的。随后进行的面向对象分析的目的，就是全面深入地理解问题域和用户的真实需求，建立起问题域的精确模型。对象模型是什么
系统分析员必须与用户及领域专家密切配合协同工作，共同提炼和整理用户需求。在这个过程中，很可能需要快速建立起原型系统，以便与用户更有效地交流。
10.2.2  例子
图10.2所示的自动取款机(ATM)系统，是本书讲述面向对象分析和面向对象设计时使用的一个实例。
下面陈述对ATM 系统的需求：
某银行拟开发一个自动取款机系统，它是一个由自动取款机、中央计算机、分行计算机及柜员终端组成的网络系统。ATM 和中央计算机由总行投资购买。总行拥有多台ATM ，分别设在全市各主要街道上。分行负责提供分行计算机和柜员终端。柜员终端设在分行营业厅及分行下属的各个储蓄所内。该系统的软件开发成本由各个分行分摊。
银行柜员使用柜员终端处理储户提交的储蓄事务。储户可以用现金或支票向自己拥有的某个账户内存款或开新账户。储户也可以从自己的账户中取款。通常，一个储户可能拥有多个账户。柜员负责把储户提
交的存款或取款事务输进柜员终端，接收储户交来的现金或支票，或付给储户现金。柜员终端与相应的分行计算机通信，分行计算机具体处理针对某个账户的事务并且维护账户。
拥有银行账户的储户有权申请领取现金兑换卡。使用现金兑换卡可以通过ATM 访问自己的账户。目前仅限于用现金兑换卡在ATM 上提取现金(即取款)
，或
查询有关自己账户的信息(例如，某个指定账户上的余额)。将来可能还要求使用ATM办理转账、存款等事务。
所谓现金兑换卡就是一张特制的磁卡，上面有分行代码和卡号。分行代码惟一标识总行下属的一个分行，卡号确定了这张卡可以访问哪些账户。通常，一张卡可以访问储户的若干个账户，但是不一定能访问这个储户的全部账户。每张现金兑换卡仅属于一个储户所有，但是，同一张卡可能有多个副本，因此，必须考虑同时在若干台ATM上使用同样的现金兑换卡的可能性。也就是说，系统应该能够处理并发的访问。
当用户把现金兑换卡插入ATM之后，ATM就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。首先，ATM要求用户输入密码，接下来ATM把从这张卡上读到的信息以及用户输
入的密码传给中央计算机，请求中央计算机核对这些信息并处理这次事务。中央计算机根据卡上的分行代码确定这次事务与分行的对应关系，并且委托相应的分行计算机验证用户密码。如果用户输入的密码是正确的，ATM就要求用户选择事务类型(取款、查询等)。当用户选择取款时，ATM请求用户输入取款额。最后，ATM从现金出口吐出现金，并且打印出账单交给用户。
10.3建立对象模型
面向对象分析首要的工作，是建立问题域的对象模型。这个模型描述了现实世界中的“类与对象”以及它们之间的关系，表示了目标系统的静态数据结构。静态数据结构对应用细节依赖较少，比较容易确定；当用户的需求变化时，静态数据结构相对来说比较稳定。因此，用面向对象方法开发绝大多数软件时，都首先建立对象模型，然后再建立另外两个子模型。
需求陈述、应用领域的专业知识以及关于客观世界的常识，是建立对象模型时的主要信息来源。
如前所述，对象模型通常有5个层次。典型的工作步骤是：首先确定对象类和关联(因为它们影响系统整体结构和解决问题的方法)，对于大型复杂问题还要进一步划分出若干个主题；然后给类和关联增添属性，以进一步描述它们；接下来利用适当的继承关系进一步合并和组织类。而对类中操作的最后确定，则需等到建立了动态模型和功能模型之后，因为这两个子模型更准确地描述了对类中提供的服务的需求。
应该再一次强调指出的是，人认识客观世界的过程是一个渐进过程，是在继承前人知识的基础上，经反复迭代而不断深化的。因此，面向对象分析不可能严格按照顺序线性进行。初始的分析模型通常都是不准确不完整甚至包含错误的，必须在随后的反复分析中加以扩充和更正。此外，在面向对象分析的每一步，都应该仔细分析研究以前针对相同的或类似的问题域进行面向对象分析所得到的结果，并尽可能在本项目中重用这些结果。以后在讲述面向对象分析的具体过程时，对上述内容将不再赘述。
10.3.1 确定类与对象
类与对象是在问题域中客观存在的，系统分析员的主要任务就是通过分析

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。