面向对象的分析与设计

面向对象的分析与设计6.1面向对象分析面向对象分析（OOA）的目的是更好地理解系统及其功能需求。也就是说OOA要求人们辨识用户需求的系统功能、支持所需系统功能的对象、对象的数据属性、相关的行为，以及对象之间的关联。通常，面向对象分析包含三个活动：建模系统功能、发现并确定业务对象、组织对象并确定其关系。下面将结合UML的相关图示，介绍面向对象的分析过程。第2页,共85页，2024年2月25日，星期天6.1.1优化用例模型用例模型，也就是用例图，它采用业务需求用例建模系统功能需求。在此期间，记录的用例仅仅包含了有关业务事件的一般性信息，其目标是快速地记录所有的业务事件（用例），以便定义和验证需求。通常在依据业务需求建模时，会生成用例图，但是为了文件管理及用户阅读，还会生成参与者词汇表、用例词汇表和用例描述表。第3页,共85页，2024年2月25日，星期天

参与者词汇表用例词汇表对用例图中的所有参与者、用例进行文字描述，分别见表6.1和表6.2。编号词汇同义词描述编号用例名称用例描述参与者表6.1参与者词汇表表6.2用例词汇表第4页,共85页，2024年2月25日，星期天用例描述表对每个用例进行详细描述。当准备用例描述时，首先在高层记录，以便尽快理解系统的事件和量级，然后再回到每个用例，扩展它以完全记录业务需求描述。对于高层的用例描述，通常包括如下内容：作者、日期、版本、用例名称、用例类型、用例ID、优先权（表示用例的重要性）、来源（表示哪个实体触发用例的创建，该实体可能是一个需求、一个特殊的文档或者某个关联人员）、主要业务参与者、其他业务参与者、其他有利益的关联人员及描述。用例描述的高层版本见表6.3。第5页,共85页，2024年2月25日，星期天用例名称用例类型：业务需求：□系统分析：□用例ID优先权来源主要业务参与者其他业务参与者其他有利益的关联人员描述作者：

日期：版本：表6.3用例描述表的高层版本第6页,共85页，2024年2月25日，星期天

对于每个确定的事件，需要进一步扩展用例的典型事件过程和替代过程。用例的典型事件过程是从参与者发起用例直到业务事件结束的步骤描述，通常记录主要时间发生的主要步骤（典型过程）；替代过程即记录了用例的异常或例外分支。对于用例描述表的扩展版本，通常多了如下内容：前置条件、触发器（发起用例执行的事件）、典型事件过程、替代事件过程、结论（描述用例什么时候成功结束）、后置条件、业务规则（说明新系统必须服从的业务政策或规程）、实现约束和说明（表示可能影响用例实现和有助于构架规划的非功能需求）、假设（记录用例时作者做出的假设）及开放问题（在用例最终确定之前需要解决或研究的问题）。用例描述的扩展版本见表6.4。第7页,共85页，2024年2月25日，星期天用例名称用例类型：业务需求：□系统分析：□用例ID优先权来源主要业务参与者其他业务参与者其他有利益的关联人员描述前置条件触发器典型事件过程参与者动作系统响应替代事件过程结论后置条件业务规则实现约束和说明假设开放问题作者：

日期：版本：表6.4用例描述表的扩展版本第8页,共85页，2024年2月25日，星期天而在进行面向对象分析时，对于每个以前定义的用例，将基于开发过程中了解到的事实对这些用例进行细化，让其包含更多的细节，如用户界面需求。为了准备进行对象建模，需要将业务需求用例模型转换成分析用例模型。第9页,共85页，2024年2月25日，星期天1、确定、定义并记录新的参与者在创建了业务需求用例模型和其最终被系统所有者批准之间，系统分析员和开发团队的其他成员通过与关联人员交换和研究项目发布物，继续了解系统成功还需要什么。通过这些努力，有可能会发现需求被定义和记录的额外参与者。第10页,共85页，2024年2月25日，星期天2、确定、定义并记录新的用例作为一般规则，用于处理业务事件的每种类型的用户接口都需要自己的用例。以银行业为例，在ATM中存款的用例将不用于在柜台存款的用例。处理的目的相同，许多步骤也相同，但实际的系统用户可能不同，用户采用特定的技术（ATM及为出纳设计的GUI界面）如何与系统交互可能不同。新确定的用例需要被定义到前面准备好的用例参与者词汇表中。第11页,共85页，2024年2月25日，星期天3、确定任何复用的可能性正如上一步所述，当两个用例有同样的业务目标但接口技术和实现的系统用户不同时，两个用例可能共享公共的步骤。为了消除冗余步骤，可以将这些公共步骤提取成独立的用例，称为抽象用例；当分析用例，发现用例包含多个步骤构成的复杂功能并且难以理解时，可以将更复杂的用例提取成专门的用例，称为扩展用例。新的用例也需要被定义到前面准备好的用例参与者词汇表中。第12页,共85页，2024年2月25日，星期天4、细化用例模型图由于发现了新的参与者和/或用例，需要修改前面构造的用例模型图以包括这些新的内容，并完成新的用例描述表。第13页,共85页，2024年2月25日，星期天5、记录系统分析用例描述一旦修订了所有的业务需求并被用户批准，将细化每个用例包含更多的信息以便详细地说明系统功能。把得到的用例称为系统分析用例，该用例没有太多的实现细节，除了描述系统用户用来与系统交互的手段（WindowsGUI、Internet浏览器、电话等）的高层信息。系统分析用例包含从系统用户角度的描述。从与系统交互的角度看，系统分析用例比业务需求用例（需求阶段的用例）交互得更自然。系统分析用例在生命周期的设计阶段将被进一步细化，以说明如何实现。在进入设计阶段之前，所有开放的问题和要确定的问题都被解决了，这一点很重要，因为每个决策都会影响设计的特性。第14页,共85页，2024年2月25日，星期天6、记录抽象用例描述和扩展用例描述记录扩展用例和抽象用例的描述与记录常规用例的描述十分类似，但是有几个主要的区别。抽象和扩展用例不是由参与者发起的，而是由其他用例调用的。而且，抽象和扩展用例一般比较短，不需要那么多描述条件。此外，在“用例类型”中的选项为“抽象”和“扩展”。抽象/扩展用例描述表的版本见表6.5。第15页,共85页，2024年2月25日，星期天用例名称用例类型：抽象：□扩展：□用例ID优先权来源参与者描述前置条件典型事件过程替代事件过程后置条件作者：

日期：版本：表6.5扩展/抽象用例描述表的版本第16页,共85页，2024年2月25日，星期天当被两个以上的用例调用时，可以采用抽象用例；当扩展单个用例的功能时，可以采用扩展用例。此外，抽象用例可以调用其他抽象和/或扩展用例，扩展用例也可以调用其他抽象和/或扩展用例，因此，这提供了许多用例的复用。当完成系统分析用例的定义后，就可以开始确定用例中包含的对象了。这些对象表示了业务领域的事物或实体。在这里，先用一两句话集中描述这些对象，以后会扩展他们的定义，以包含关于每个对象的更多的细节信息。第17页,共85页，2024年2月25日，星期天6.1.2绘制建模活动图

UML提供了活动图用于建模系统的过程、步骤和活动。系统分析员使用活动图可以更好地理解用例步骤的流程和顺序。活动图类似于流程图，图形化地描述了业务过程或用例的活动顺序流程。它们不同于流程图，他们提供了描述并行活动的机制。因此，对于建模那些操作正在进行时的活动，以及那些活动的结果，流程图特别合适。活动图很灵活，既可以用于分析阶段，也可以用于设计阶段。第18页,共85页，2024年2月25日，星期天对于每个用例，至少可以构造一个活动图。通常，通过用例描述表中的典型事件过程和替代事件过程来构造活动图。如果用例很长，包含复杂的逻辑，则可以构造多个活动图。但是不会对每一个用例都绘制活动图，只对具有复杂逻辑的用例（甚至只是用例的一个片段）绘制活动图。活动图可以帮助人们思考系统逻辑，也可以用于与程序员交流逻辑。第19页,共85页，2024年2月25日，星期天6.1.3绘制系统顺序图在逻辑设计阶段一些面向对象方法使用的另一种工具便是系统顺序图。顺序图描述了在用例执行或操作过程中对象如何通过消息相互交互。面向对象的世界是由对象之间发送的消息驱动的。系统顺序图可以帮助人们开始确定进入和退出系统的高层消息。以后这些消息将成为单个对象的责任，对象通过与其他对象交互完成这些责任。对于系统顺序图，没有包括用例任何的可选过程，也就是说它通过用例的单一的路径描述了单个场景。所以对于一个用例来说，一套完整的系统顺序图可能包括几幅图形。第20页,共85页，2024年2月25日，星期天6.1.4确定业务对象在试图确定对象时，许多方法学专家建议查找需求文档或者其他相关文档，并标记出表示潜在对象的名词。这可能是一项复杂和任务，因为涉及的名词很多。用例模型为这个问题提供了一个解决方案，即将整个系统分解成用例。这些相对较小的用例减少了挑选名词的工作量，并且使用该技术更为有效。以下即为确定业务对象的步骤。第21页,共85页，2024年2月25日，星期天1、发现潜在对象这需要检查每个用例以发现对应业务实体或事件的名词。把用例描述表里涉及的所有名词都标出来，添加到潜在对象列表中，供进一步分析使用。第22页,共85页，2024年2月25日，星期天2、筛选建议的对象不是在列表中的所有候选名词都表示了问题域内的有用的业务对象。按照下列原则，对每个名词进行筛选，决定是保留，还是从列表中删除。是否是另一个对象的同义词？是否是系统范围之外的名词？是否是需要进一步解释的不清楚的名词？是否是描述了另一个对象的行为或属性的名词？第23页,共85页，2024年2月25日，星期天如果对于某个候选名词，以上任何问题的答案都是“是”，那么应该从列表中删除。如果发现某个候选名词是属性，则把她急了在另一个列表中，以防忘记。以后会用它们构造类图。如果发现某个候选名词不能确定是否应该删除，则还是把该名词保留在列表中，因为将来发现它不是对象而删除它，要比类图构造好了再增加它容易的多。第24页,共85页，2024年2月25日，星期天6.1.5组织对象及其关系一旦确定了系统的业务对象，就要组织这些对象，并记录对象之间的主要概念关系。类图以图形化的方式描述对象及其关联关系，在该图中还包括多重性、关联关系、泛化关系等。第25页,共85页，2024年2月25日，星期天1、确定多重性和关联关系在这一步，需要确定存在于对象/类之间的关联关系。两个对象/类之间的关联关系是一个对象/类“需要知道”另一个对象/类的东西，关联关系允许一个对象/类交叉引用另一个对象/类，并能够向它发送消息。一旦确定了关联关系，就必须确定关联关系的多重性。这里的关联关系，是指不包含聚合关系和组合关系的关联关系。对于这两种关系，会在最后确定。第26页,共85页，2024年2月25日，星期天在确定多重关联关系时，可以采用矩阵法，即用一个矩阵把对象/类作为列标题和行标题列出，然后检查矩阵中显示在一行上的每个对象/类与显示在一列上的对象/类之间的关联关系。关联关系的名称和多重性可以直接记录在矩阵的交叉单元格中，见表6.6对象/类01对象/类02对象/类03……对象/类01X对象/类02X对象/类03X……X表6.6矩阵法第27页,共85页，2024年2月25日，星期天2、确定泛化关系一旦确定了基本的关联关系及其多重性，就必须确定是否存在泛化关系。泛化关系也称为分类层次或者“isa”关系，由父类和子类构成。父类具有一般性，其中包含了层次中的公共属性和操作；子类则是特殊的，其中包含了那个对象转悠的属性和操作，但它也继承了父类的属性和操作。泛化关系可以通过类图查看。如果两个具有一对一多重性的对象之间存在关联关系，并且可以表达一个对象是另一个对象的一种类型，那么就有了一个泛化关系。另外，可以寻找具有公共属性和操作的对象，可以将公共属性和操作加以组合成为一个新的父类。通过使用泛化，可以促进对象和程序代码的复用。第28页,共85页，2024年2月25日，星期天3、确定聚合/组合关系在这一步，必须确定是否存在聚合或组合关系。聚合/组合关系是特殊的关联关系。如果一个对象是另一个对象的一部分，可被称为整体/部分关系。4、准备类图根据前三步的操作，建立一个UML类图。第29页,共85页，2024年2月25日，星期天6.2从分析到设计面向对象设计强调定义软件对象，并且使这些软件对象相互协作来满足用户需求。面向对象分析和面向对象设计使用统一的表示方法，在二者之间并没有十分清晰的分界线，从面向对象分析道设计是一个逐渐扩充模型的过程。在设计开始之前，分析不必圆满完成。分析和设计是一个反复迭代的过程。第30页,共85页，2024年2月25日，星期天面向对象设计阶段的内容包括：从面向对象分析对问题域的分析结果出发，从问题域、人机交互、任务管理和数据管理4个部分出发，针对实现的要求进行必要的增补和调整。第31页,共85页，2024年2月25日，星期天1、问题域部分系统所要处理的问题范围，在需求分析和面向对象分析的过程中，通过用例图等基本确定了系统所要处理的主要问题的范围；在面向对象设计的过程中，将针对系统所处在的特定的实现环境，进行问题范围的进一步设计。第32页,共85页，2024年2月25日，星期天2、人机交互部分根据用户选用的图形用户界面系统和特定用户对人机界面的要求而设计的系统使用界面。它在很大程度上依赖于所用的图形用户界面环境，由新定义的人机界面类和对象组成。第33页,共85页，2024年2月25日，星期天3、任务管理部分用于定义系统中需要并发执行的各个任务，包括任务的定义、通信和协调，以及硬件分配、外部系统及设备约定。可能包括的类有“任务”类和“任务协调”等。4、数据管理部分按选定的数据管理系统而设计的负责对象的存储及检索的系统组成部分。它与物理的数据管理方法无关，可以是普通文件、带标记语言的文件、关系型数据库、面向对象数据库等。可能包括的类有“存储服务”类，协调每个需求永久保持的对象的存储。第34页,共85页，2024年2月25日，星期天6.3面向对象设计6.3.1问题域部分的设计问题域部分由与系统问题有关的对象构成，并且在特定的实现条件（如编程语言）下提供用户所需功能的组成部分。它是在分析模型的基础上按实现的要求进行必要的修改、调整和补充得到的。可见，面向对象设计是在面向对象分析的基础上的扩充，其表示方法和含义是一致的，没有本质的区别。原因如下：第35页,共85页，2024年2月25日，星期天首先，从面向对象分析到面向对象设计不是一个突变的过程，而是在对面向对象分析的结果做深入分析的基础上，结合具体的实现环境和要求，对面向对象分析结果的改动和增补，这是一个循序渐进的过程。其次，分析模型的改动和增补的结果是在设计方面、编程方面与问题域之间的转换尽可能相近而形成的一种修改准则，即对于一个特定问题的设计要考虑其需要的实际变化。第36页,共85页，2024年2月25日，星期天最后，在实际中，用户的需求总是处于不断的变化中，这就要求系统也必须能够适应不断变化的要求。在进行问题域部分设计时，至少从以下4个方面来对分析模型进行增补和修改：增加一般类、实现复用、提高性能、完善细节。第37页,共85页，2024年2月25日，星期天1、增加一般类对象的创建、删除、复制、转存等行为实际上是系统行为，而不是个别对象自身的行为。各种面向对象程序设计语言往往可在某种程度上统一地解决这些问题，所以在分析阶段不要求在各个对象中定义与此有关的属性和操作。而应该根据编程语言提供的支持，统一定义系统中全部对象类或某一部分对象类共同需要的属性和操作，称之为一般类。第38页,共85页，2024年2月25日，星期天在面向对象分析中定义一般类的主要目的是：集中地描述问题域中事物的共同特征，将多个类都具有的特征提升到一般类中进行表示。在面向对象设计中定义一般类的主要目的是：描述特定条件下某些（全部或部分）类的共同实现策略，用一个一般类集中地给出多个类的实现都要使用的属性和操作。其他类在定义时，只需要继承这个一般类，从而避免相同属性和操作的重复定义，避免程序冗余。第39页,共85页，2024年2月25日，星期天2、实现复用相比结构化方法，面向对象方法可提供良好的软件复用性。软件复用可分为分析级、设计级和程序代码级等不同级别。在开发过程中的各个阶段充分利用不同级别的复用构件，可以显著提高系统的开发效率和质量。目前，很多面向对象程序设计语言都带有一个比较完整的类库，类库中的每个类都是可以复用的。第40页,共85页，2024年2月25日，星期天1）直接复用：类库中的类恰好与系统的要求完全相符。2）通过继承复用：可复用的类中的属性和操作都是系统中所需要的，但是并不完整，则可以通过继承来复用。第41页,共85页，2024年2月25日，星期天3、提高性能尽管计算机的计算速度大大提高了，但是对许多系统（尤其是实时系统）而言，性能也是至关重要的。系统的性能是用户要求的内容之一，而由于性能与许多因素相关，如硬件设备、网络、数据管理系统、图形用户界面和编程语言等，因此将它放到面向对象设计阶段考虑。第42页,共85页，2024年2月25日，星期天影响性能的因素可分为以下三个方面：1）网络传输时间：不同的网络环境，对系统性能的影响是巨大的，它包括系统分布方案、网络拓扑结构、数据传输速率和网络拥挤状况等因素。2）数据存取时间：数据存取时间即将数据在外部存储设备上进行存取的时间。在不同类型的存储设备上，存取时间不同。第43页,共85页，2024年2月25日，星期天3）数据处理时间：显示了系统中计算的复杂性程度，由于影响系统性能的因素很多，也比较复杂，所以只有在具体问题中具体考虑，找出影响性能问题的主要因素后，才能逐步解决。下面有几种可以改进性能的措施：在对象之间具有高度繁忙的消息流通的情况下，这种高度耦合可能需要把两个或更多的类进行合并。在类及对象中扩充一些保存临时结果的属性。避开正常的数据抽象原则而允许服务从其他对象中强行获得属性值。第44页,共85页，2024年2月25日，星期天4、完善设计设计得到的结果将直接转换为实际编程语言的对象、类定义。在分析阶段已经从问题域的角度出发，建立了许多对象的细节，这对设计有很大的帮助。在设计阶段，设计工作需要进一步细化，它将给出一个完全可实现的面向对象模型，凡是需要让程序员知道的对象，包括对象的每一个属性、操作和其他必要的细节，都应该在分析模型中说明或定义清楚。第45页,共85页，2024年2月25日，星期天1）弥补分析模型的不足2）解决分析阶段推迟考虑的问题3）设计对象和操作第46页,共85页，2024年2月25日，星期天6.3.2人机交互部分的设计人机交互部分是面向对象设计外围组成部分之一，它所包含的对象构成了系统的人机界面。现在，计算机的人机界面大多采用图形用户界面。它以形象、直观等特点拉近了计算机与用户之间的距离，也是计算机得以迅速为用户所接受的基础。第47页,共85页，2024年2月25日，星期天设计人机交互部分的策略由以下几点构成：对使用者（人）的分类与描述，设计命令层，不断原型化；设计人机交互部分的类。这些活动的次序反映了人机交互设计中正常的优先事项集合：首先是人，然后是任务，最后是工具。第48页,共85页，2024年2月25日，星期天1、对使用者（人）的分类与描述设计实现满足用户习惯和需要的操作方式，必须首先研究用户，设身处地地考察用户的实际情况，其中需要考虑用户希望系统能够达到什么样的目的，要完成什么样的任务，设计者能够提供什么工具来支持这些任务，工具如何做得最协调等。第49页,共85页，2024年2月25日，星期天可以将使用者按照某种分类准则分为不同的类型。按技能层次分类，可分为初学者、中级水平人员、高级水平人员等。对于划分不要类型的使用者，他们各自的操作习惯和使用方式或多或少都有一些区别。对于定义的每一类使用者，考虑下述问题：谁，目的，特征（年龄、教育水平、限制等），关键的成功因素，必须/想要，喜欢/不喜欢/有偏见，熟练程度，任务脚本。对于每一类使用者，把这些问题搞清楚，并写下其中每一个人的情况。第50页,共85页，2024年2月25日，星期天2、设计命令层命令层可能以多种形式呈现给用户，如命令行、一个菜单或一系列图标。命令层是使用过程抽象组织可用服务的一种体现。在这一点上，设计转到了如何体现使用过程抽象组织所需的服务。第51页,共85页，2024年2月25日，星期天为了细化命令层，要考虑排列、整体/部分组合、宽度与深度的对比、减少操作步骤等问题。排列。在开发这个层次时，要细心地选择醒目的服务名，并在这个层次的各部分合理安排服务名，把使用最频繁的服务名放在前边，按照用户的工作步骤排列。整体/部分组合。通过服务本身发现整体/部分模式，以帮助在命令层中对服务进行组织和分块。第52页,共85页，2024年2月25日，星期天宽度与深度的对比。根据人脑短期记忆的局限特点，设计每块有3项的3个块的宽度，把深度限制在大约3层左右，这样用户就不必为知道他进入应用有多远而大伤脑筋了。减少操作步骤。使点取、推动及键盘操作减少到最少，并能完成用户所要求的工作，同时，为系统的高水平用户提供操作捷径。第53页,共85页，2024年2月25日，星期天3、不断原型化原型化是人机交互行为对人机交互部分的设计来说是至关重要的一步，用户需要不断使用、细化假设的交互界面，以进一步完善和改进人机交互部分的设计。4、设计人机交互部分的类人机交互部分的类在很大程度上依赖于所选用的图形用户界面，如XWindows、Motif、Windows，不同的图形用户界面具有基本的区别，如字型、坐标系统及事件等。此时，需要根据选定的图形用户界面及前面的策略设计人机交互部分的类，包括窗口、菜单、滚动条、按钮等。第54页,共85页，2024年2月25日，星期天6.3.3任务管理部分的设计任务又称为进程（进程是一连串的，由其代码所定义），若干任务并发执行时叫做多任务。单处理机上的多任务，可能需要一个任务在其他任务执行期间与他们协作和通信。在操作系统的支持下，这些任务以时间片轮转的方式运行，产生同时运行的感觉。多处理机硬件结构，每台处理机需要独立的任务，此时要增加支持进程间通信的任务；任务增加了设计、编码和过程的复杂性，因此必须细心地选择并做出最终调整。第55页,共85页，2024年2月25日，星期天但是对某些应用来说，任务能简化总体设计和编码。独立的任务把必须并发执行的行为分离开来，这种并发行为可以在多个独立的处理机上实现，或者在运行多任务操行系统的处理机上模拟。任务的调整和选择，遵照下述策略：识别事件驱动任务，识别时钟驱动任务，识别优先任务和关键任务，识别协调者，审查每个任务，定义每个任务。这种策略的要点是识别并设计任务，加上包含在每个任务中的服务。第56页,共85页，2024年2月25日，星期天1、识别事件驱动任务有些任务是事件驱动的，这些任务可能是负责与设备、其他处理机或者其他系统通信的。任务可以设计成由某个事件来触发，该事件常常针对一些数据的到达发出信号。数据可能来自输入数据行，或者来自由另一个任务写入的数据缓冲区。这类任务的执行过程见书P220。第57页,共85页，2024年2月25日，星期天2、识别时钟驱动任务这类任务按特定的时间间隔被触发去进行某些处理。某些设备需要周期性地数据采集和控制，某些人机界面、子系统、任务、处理机或其他系统可能要周期性地通信，这正是时钟驱动任务的用途。这类任务的执行过程见书P220。第58页,共85页，2024年2月25日，星期天3、识别优先任务和关键任务优先任务既包括高优先级的也包括低优先级的处理需要。关键任务用来分离出对于系统的成败特别关键的那些处理，这种处理通常具有特别严格的安全性要求。第59页,共85页，2024年2月25日，星期天4、识别协调者有三个或者更多的任务时，可考虑另外增加一个任务，这个任务起到协调者的作用。这样一个任务加在上边时，现场切换时间（从一个任务转到另一个任务的时间）可能使这种设计方法遇到困难，但这个任务可为封装任务之间的协作带来好处，其行为可以用一个状态转换矩阵描述。用这样的任务来协调其他任务，不要用它去实现那些本应属于分配给被协调的任务所包含的类及对象的服务。第60页,共85页，2024年2月25日，星期天5、审查每个任务必须使任务的数目保持最少额度。无论在开发阶段还是在维护阶段，每次仅仅能理解一个或少数几个正在进行的任务。设计多任务协调的主要问题之一是设计者常常迷恋于定义太多的任务。因此要审查每个任务，确保它能满足一个或多个选择任务的工程标准——事件驱动、时钟驱动、优先/关键任务或者协调者。第61页,共85页，2024年2月25日，星期天6、定义每个任务定义任务包括任务的内容，以及它是如何协调和如何通信的。（1）任务的内容（2）如何协调（3）如何通信第62页,共85页，2024年2月25日，星期天6.3.4数据管理部分的设计数据管理部分在面向对象设计中负责与具体的数据管理系统相衔接的组成部分。它为系统中需要长久存储的对象，提供了在选择的数据管理系统中进行数据存储的能力。数据存储问题在大多数的系统中都是必须涉及的。在面向对象设计中，数据是以属性的方式存在于对象之中的，因此数据存储问题表现为对象的存储，这样的对象称为永久对象，即需要长期存储的对象。在进行数据分析和设计时要说明哪些是永久对象，同时需要设计具体的措施来解决对象的存储问题。数据管理部分就是用面向对象的概念和方法针对具体的存储系统设计相应的解决办法的。第63页,共85页，2024年2月25日，星期天在向对象设计中，永久对象的存储可以采用不同的数据管理系统来解决。例如，可以采用文件系统、关系数据库系统（RDBMS），也可以采用面向对象的数据库系统（OODBMS）等。从理论上讲，采用OODBMS应当是最合适的选择，但是在具体应用系统的开发过程中，有许多需考虑的因素，这些因素对数据管理系统的选择有很大的影响，有时，选择文件系统或关系数据库系统可能更为适合。数据管理方法主要包括两个方面：文件系统和数据库系统。文件系统可以是局部文件系统，也可以是分布式文件系统；数据库管理可以是关系数据库系统，也可以是面向对象的数据库系统，P221页表8.7对不同数据管理系统进行了简单的讨论。第64页,共85页，2024年2月25日，星期天6.4面向对象设计原则设计良好系统的含义是什么？首先应该是符合系统需求，能达到需求中所规定的功能要求和相应的技术指标，而这只是衡量设计是否达标的准则，其次，良好的系统应容易理解，可变更性好，易于重用，从模型到实现不会有任何特殊的困难，程序开发高效可靠，实现成本低，人们也乐于使用这样的系统。设计糟糕的系统则相反，其结构凌乱，晦涩难懂。本节介绍一些面向对象设计的原则，这些原则有助于开发人员设计出良好的系统。第65页,共85页，2024年2月25日，星期天6.4.1开放封闭原则一个模块在扩展性方面应该是开放的，而在更改性方面应该是封闭的。因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。示例见书P223页。第66页,共85页，2024年2月25日，星期天6.4.2单一职责原则这个原则的核心含义是：一个类应该有且仅有一个职责。关于职责的含义，面向对象大师Robert.CMartin有一个著名的定义：所谓一个类的职责是指引起该类变化的原因，如果一个类具有一个以上的职责，那么就会有多个不同的原因引起该类变化，其实就是耦合了多个互补相关的职责，就会降低这个类的内聚性。示例见书P224页。第67页,共85页，2024年2月25日，星期天6.4.3Liskov替换原则子类应当可以替换父类，并且能够出现在父类出现的任何地方。这个原则是Liskov于1987年提出的。一个能够反映这个原则的例子是圆和椭圆，圆是椭圆一个特殊子类，因此任何出现椭圆的地方，圆均可以出现，但反过来就可能行不通。用类图表示时，类B作为椭圆类，类C是圆类，它是一个特殊的椭圆类，继承了类B的属性和方法。运用替换原则时，应该尽量把类B设计为抽象类或者接口，让类C继承类B，并实现操作A和操作B。运行时，类C实例类替换B，这样即可进行新类的扩展，同时无需对类A进行修改。示例见书P225页。第68页,共85页，2024年2月25日，星期天6.4.4依赖倒置原则第一，高层模块不应该依赖于低层模块，二者都应该依赖于抽象；第二，抽象不应该依赖于细节，细节应该依赖于抽象。在进行结构化设计时，总体结构设计时创建一些高层模块实现应用程序中的重要策略选择和业务模型，低层则实现具体的细节，低层模块被高层，模块所调用，低层模块的改动会直接影响到高层模块，换言之，高层模块依赖于低层模块，然而一个良好的面向对象设计，其模块依赖结构相对于上述传统的结构化设计的结构而言就是“倒置”了。第69页,共85页，2024年2月25日，星期天按照自上而下的依赖关系，高层的策略设置模块往往是无法重用的，如果设法让高层模块独立于低层模块，则实现重用就变为可能。依赖倒置原则的启发式建议是“依赖于抽象”，具体做法是将高层需要的服务声明为抽象接口，高层使用这些接口，低层模块实现这些接口，使高层不再依赖于低层，而是依赖于抽象接口，同样低层也依赖于抽象接口。示例见书P226页。第70页,共85页，2024年2月25日，星期天6.4.5接口隔离原则接口隔离原则用来解决“胖”的接口所具有的特点。如果一个类（或接口类）不具备高内聚性，就表示该类具有“胖”的接口。通常这些接口被多个使用者使用，而每个使用者很少用到所有接口方法。但是一旦某个方法发生变化，即使使用者没有使用到这些方法，还是会受到影响，因此增加了不必要的复杂性和重复，所带来的“臭味”称为接口污染，即和某个类关联的程序被一个它不需要的方法污染了。第71页,共85页，2024年2月25日，星期天接口污染还导致了使用接口的程序之间的耦合，要避免这些耦合，需要对接口进行分离，将“胖”的接口分解成多组方法，每一组方法服务于一组不同的客户程序，这样，为每个使用者提供只包含了要用到的方法的类（或接口），就可以保护使用者不被无用的方法影响。一个接口被隔离成为多组方法后，可能存在这样的类，他们需要用到两组方法或者更多，要实现这样的客户程序可以采用委托模式或多继承模式。第72页,共85页，2024年2月25日，星期天6.5面向对象设计过程在6.1节中，基于理想条件并依赖于一些硬件或软件方案确定了对象和用例。本节将继续按照上述思路进行面向对象设计过程的讨论。在面向对象设计活动中，主要通过对这些对象和用例加以精炼，以反映所建议的方案的实际环境。通常来说，面向对象设计包括三个活动：精炼用例模型；建模支持用例情境的类交互、行为和状态；修改对象模型以反映实现环境。第73页,共85页，2024年2月25日，星期天6.5.1精炼用例模型在用例建模的这次迭代中，将对用例加以精炼，从而包括参与者（或用户）如何实际地与系统接口及系统如何响应刺激处理业务事件的细节。虽然精炼用例通常是耗时且繁琐的，但是这项工作必须完成，这些用例将是系统实现期间开发用户手册和测试脚本的基础，而且，在系统实现期间，程序员将使用这些用例构造应用程序。第74页,共85页，2024年2月25日，星期天在下面的步骤中，将调整每个用例，使他们使用实现环境或“现实”，并且记录下调整的结果。重要的是每个用例都被高度细化，并且描述了用户同系统的交互，用户可以使用这些精炼后的用例验证系统设计，并且程序员也可以使用用例说明过程和接口。1、将分析用例转换成设计用例2、修改用例模型图和其他文档以反映新用例第75页,共85页，2024年2月25日，星期天6.5.2建模支持用例情境的类交互、行为和状态1、确定并分类用例设计类在这个步骤中，将确定并分类设计类，通常包括实体类、接口类和控制类。这些设计类说明了用例中的功能需求，而且还要确定类之间的交互、类责任和行为。第76页,共85页，2024年2月25日，星期天2、确定类属性在分析和设计阶段，都可以确定类属性，在将分析用例转变成设计用例的工作中，开始引用用例文本中的属性，在这一步中，检查每个用例中以前没有被确定的附加属性，而且还要修改类图以包括这些属性。第77页,共85页，2024年2月25日，星期天3、确定类操作和责任一旦确定了支持用例功能所需的所有对象，就要重点定义它们的特殊操作（行为）和责任。通过检查用例描述表，以确定所有的“动词短语”，通常“动词短语”建议了完成一个用例情境所需的操作。一旦确定了操作，就必须