第7章 面向对象的设计.docx
《第7章 面向对象的设计.docx》由会员分享，可在线阅读，更多相关《第7章 面向对象的设计.docx（21页珍藏版）》请在冰豆网上搜索。
第7章面向对象的设计
第7章面向对象的分析与设计
本章讲述面向对象的核心内容—面向对象的分析与设计。
在实际的软件项目开发中，这两个阶段是交替进行、没有先后次序的。
面向对象分析侧重于“系统需要做什么”的分析；面向对象的设计侧重于“系统如何做”的解决方案。
主要内容包括系统分析；系统设计和对象持久化设计。
7.1基本内容
7.1.1系统分析
系统分析的本质是建立业务领域的逻辑模型，描述业务领域对象如何交互以实现用例定义。
它的目的是定义计算机系统的行为，以及怎样与业务环境交互，用面向开发人员的术语来描述系统，形成系统“需要做什么”的描述。
分析工作的目标是产生分析模型，产生三个重要的分析制品：
分析类：
业务领域中建模的主要概念。
用例实现：
演示分析类的实例（对象）如何交互以实现由用例所说明的系统行为。
构架：
对业务领域中的类进行划分组织、形成领域的整体结构。
1．系统分析的一些“经验法则”
⑴分析模型总是使用业务语言。
⑵创建“讲故事”的模型。
⑶注重捕获大的场面。
⑷清晰地区分问题域（业务需求）和解域（详细的设计考虑），总是关注存在于问题域的抽象。
⑸如果看起来在自然的、强迫的抽象层次，则考虑是否用继承关系。
分析中永远不要为了代码复用而使用继承。
继承是类之间耦合的最强形式。
⑹尽力最小化类之间的耦合。
类之间的每个关联都在它们之间建立耦合。
⑺保持模型简单。
每个分析模型内部能够抽象出简单的分析模型。
简化的方法之一是审视一般情况而不是特殊情况。
2．分析类
（1）分析类的概念
分析类代表问题域中的简洁抽象，应该使用清晰的和无歧义的方法映射到某个真实世界业务概念。
分析类一般由下面几部分组成：
名称：
这是必需的。
属性：
只有候选属性的重要子集在此时建模，属性名称是必需的，属性的类型是可选的。
操作：
在分析中，操作仅是类职责的高级层次的陈述。
只在它们对于理解该模型很重要时，显示操作的参数和返回类型。
构造型：
如果它们将增加模型的清晰性，可以显示出来。
产生良好的分析类的几点原则：
①名称反映目的。
②建模问题域的一个特定元素是简洁的抽象。
③清晰地映射到问题域中可识别的特征。
④具有小的、良好定义的职责集合。
⑤高内聚、低耦合。
（2）UML类的构造型
UML中，类有三种不同的构造类型，分别称为实体类、边界类和控制类。
实体类主要用来为持续存在的对象建模，系统也需要保存关于这些对象的长期信息。
边界类是用来控制与外界交互的。
控制类将复杂行为组织起来，这些行为涉及了大量边界类和实体类。
寻找分析类是OO分析与设计的核心问题。
Meyer在<>指出：
“不存在找出恰当分析类的简单算法。
如果这样的算法存在，那么意味着存在没有错误的方法来设计OO软件，这同找出没有错误的方法证明数学定理一样是不可能的。
”但这并不代表没有任何办法来寻找分析类。
实际上，找出“恰当”的类依赖于分析师的知识面、技术和经验。
他们常用名词/动词和CRC（类、职责以及协作方法）来寻找分析类。
教材中使用另一种方法来寻找分析类。
基本思想是在用例实现的过程中，由顺序图驱动来寻找分析类。
3．顺序图
系统分析中，顺序图是这样一种方法，它研究需求分析阶段中搜集来的用例，将用例定义中的顺序和在用例中相互作用的对象串在一起。
顺序图表示以时间序列安排的对象交互的二维图。
顺序图有助于分析，顺序图通向设计。
画顺序图是比较困难的，分析人员常常设计许多问题让项目相关者来阐明，而需求分析常常忽略一些顺序的细节。
作为设计师应该清楚，没有哪个分析过程能自始至终顺利进行，是一个不断进行细化的迭代过程。
4．协作图
分析中协作图是顺序图的一种补充形式，它关注对象交互的结构方面。
面向对象的系统通过对象协作来提供其行为，单独的对象只能提供部分行为。
当对象进行协作时，它们能够提供复杂而功能强大的行为。
5．类图
确定了域对象和交互之后，就可以在类图中记录关于所需要数据的一些信息。
在分析阶段，类图中用关联来联系两个类，而不应该使用属性来联系它们。
使用关联能够表示两个对象之间的任何关系，而且能把关系表示得更清楚、更醒目。
这样做能够清晰地反映问题的固有本质，而不是实现方法。
类图是几乎贯穿面向对象方法中的核心建模技术，在项目开发的各个阶段都会使用它。
系统分析阶段类图构建的质量如何将直接影响到下一阶段的工作是否存在偏差。
要尽量保持类图的简洁清晰，如果系统中的类或类之间的关联太多的话，可以把一个大的类图适当地分解为几个相对小的部分，每个部分放在一个包中，然后建立包之间的关联。
6．构架分析
构架分析的目的是尽力最小化系统中的耦合数量，把分析类组织成一组内聚的分析包，进而组织成分区和层。
根据业务用例、类的性质及类之间的关联对类进行划分组织，这样就可以得到构架。
7．状态图
状态图一般并不用于系统分析，除非一个对象有某些复杂的行为需要考虑。
但状态图可以帮助分析人员、设计人员和开发人员理解系统中对象的行为。
状态图只是针对单个对象建模，通过分析单个对象的内部状态转换来了解一个对象行为。
对于有多种内部状态的对象，状态图可以显示对象如何从一种状态转换到另一种状态，以及对象在不同状态中的不同行为。
使用状态图可以了解对象行为更多的动态细节。
8．用户接口
在系统分析阶段，使用户参与并阐明问题的最有效的方法之一是提供原型界面。
用户接口可以直观地提供未来系统的界面，当用户接口较多时，应该对用户接口进行建模，即对它们之间的调用关系进行建模。
7.1.2系统设计
系统分析对系统的外部行为提供了全面的定义，并对系统总体结构进行了描述，它的焦点是创建系统的逻辑模型，捕获系统为满足用户需求而必须提供的功能。
而一个软件设计者比较关心的是系统要提供哪些功能，以及系统如何才能提供这些功能，存储如何管理，系统的各组成部分如何结构化，如何将系统划分成子系统，各子系统间如何联系，系统的可靠性如何，一旦发生灾难将如何处理等等。
在很大程度上，分析和设计是可以同时进行的，这是面向对象方法的显著特点。
系统的设计可分为两个阶段：
构架设计阶段：
这是一个从较高层次进行的设计，是对问题的解和建立解决方法的高层决策。
构架定义了系统的总体结构，包括技术构架（如计算机、网络、数据库、开发环境）和应用构架（应用程序如何划分和融入技术构架中）。
详细设计阶段：
主要是决定在实现过程中使用的类和关联的全部定义，以及用于实现操作的各种方法的算法和接口。
所有的类都尽可能地进行详细描述，给编写代码的程序员一个清晰的规范说明。
系统设计的输出结果是：
系统构架、设计子系统、详细的顺序图、详细的设计类图、操作说明书、数据库定义和组件结构等。
1．构架设计
构架（有时也叫体系结构）决定了整个应用系统的外形。
构架包括：
技术构架和应用构架两种。
技术构架包括计算机、网络、工具、包和数据库等等。
它是安装和运行应用程序的一个大致框架。
它对于应用程序的性能和承载性都有着重要的影响。
它往往从应用程序的需要，系统开发的企业文化，到技术产生的市场等诸多因素来进行选择。
应用构架是关于应用程序如何划分和融入技术构架的问题。
大多数应用系统都是基于网络的，需要考虑很多影响系统性能和可承载性的因素。
应用构架被看做软件组件的层次结构，每一层都有特定的作用和职责。
此外，应用构架还需要考虑非功能性需求，如完整性、可靠性和可恢复性。
在很多情况下，构架不需要完全由自己来设计，因为针对特定的问题也许有很多现成的解决方案，某些解决方案在其他同类系统中已经得到成功的应用，可以供我们借鉴或直接使用。
技术构架是与运行程序的计算机、将这些计算机相连的网络、程序设计语言以及用于开发和集成应用的软件相关的。
可供选择的构架有无数种，但是，要选择一个最合适的构架却是一个具有挑战性的问题。
软件构架从传统的两层C/S结构发展到三层C/S结构和多层B/S结构，目前使用最多的是多层B/S结构。
三层结构分散在通过局域网和互联网相连的服务器和微机网络中。
通常，一个用例的处理过程被分成三个基本部分：
一个是用户接口、二是同控制对象相关的业务逻辑，第三是同实体对象相关的数据服务。
一旦采用了多层的概念，就要考虑层与层之间的接口。
现代构架设计，各层相应的语言和工具的选择：
①表示层语言用于管理与用户交互的界面。
它们应该擅长于数据采集和数据表示，并对数据提供基本的检查。
对于C/S的程序，表示层可以选用VisualB,Java和Delphi。
对于互联网的应用，表示层语言几乎是HTML，XML结合样式表现也在开始流行。
选择的标准是语言能提供对界面的适用性，至于如何进行部署（如，在网上通过浏览器的应用），是属于技术储备的实用性投资多少的问题。
②业务逻辑层的语言选择。
选择业务逻辑层的语言一方面依赖于所选择的交互界面语言，另一方面也依赖于一些其它因素。
比如编程语言与操作系统的配合情况，以及与交互界面有关的包的配合情况。
Java、C#等语言与Web服务器有着良好的接口，如果只是C/S结构的程序，也可以选择C++或C等。
③存储层的语言和工具。
目前，几乎所有的数据库都选择SQL语言，而且都选用关系数据库。
在选择具体的数据库时主要考虑价格和性能。
许多数据库的卖主同时也出售一些围绕逻辑层和表示层的开发环境。
SQL提供了一个清晰而又一致的方式来查找数据、选择要使用的相关部分、重新检索、保存和修改数据。
关系型数据库的简单性有望在可预见的将来使其仍保持现有的地位。
④连接和中间件。
目前，大型应用都集成了在不同平台和不同语言下开发的大量组件，如何使它们相互通信和协作成为构架设计的一项重要任务。
通常，有三种主要的方法。
第一是实时紧密耦合系统，使得一个系统能够立即响应另一个系统；第二种方法是缓慢连接，组件需要交换信息，但是，可以等待另一个系统用完为止；第三种方法是数据交换，信息被分组后批量提交。
该方法可以采用文件交换的技术来实现，这是最松散的系统集成形式。
采用何种方法更合适，主要依赖于响应时间的要求。
通常松散耦合使得系统更健壮、更可靠并易于试用。
紧密耦合使系统响应速度快，但有时会更脆弱。
总的原则是，首先考虑采用松散耦合系统。
2．详细设计
得出系统的构架后，接下来就要进行系统的详细设计。
根据构架的层次结构，对每一层进行详细设计，包括类的详细设计，以及层与层之间的接口设计等。
需要强调的是，实际开发软件过程中，这些阶段没有明显的区别，实际上还有反复。
⑴设计类
设计类是为了完成规格说明并且达到能够被实现程度的类。
设计的主要输出是一个类的集合，它们用类图进行描述，类与类之间相互联系，并被组织在一起以便能实现用例中的脚本。
设计类来自两个方面的考虑：
①对分析类的精化，精化包括添加实现细节。
在进行精化时，常常会发现非常高级的分析类需要被分解成两个或多个详细的设计类。
分析类与那些描述它们实现的一个或多个设计类之间存在跟踪关系。
②解域。
它是技术构架中的实用类库和诸如Time、Date、String、Collection等可复用组件的领域。
诸如通信、数据库的中间件，以及诸如DCOM、CORBA、EJB组件框架也在解域中。
这个解域也包括GUI框架，如Java的Swing、MFC等。
这个解域提供了使你能够实现系统的技术工具。
⑵设计类剖析
在分析中，尽量捕获系统需要的行为，而完全不必考虑如何实现这些行为。
在设计中，就必须准确地说明类是如何完成它们的职责的。
为此，必须完成以下任务：
①得到类完整的属性集合，包括详细说明的名称、类型、可见性和一些默认值（可选）。
②将得到的操作转化成一个或多个方法的完整集合。
信息存储在属性当中。
在设计中，属性的细节需要进行全面的描述。
最终，属性必须用某种计算机语言来实现，属性的全部细节都会被完整的实现。
在UML中，一个完整的属性定义语法如下：
visibilityName[Multiplicity]:
Type_expression=Initial_value
需要说明的是，封装性是面向对象的一个核心机制。
一般来说，属性的修改和访问都通过属性所属对象的操作来进行，而不是直接进行。
设计好类的属性以后，接着要设计类可以执行的操作。
对于操作，首先要考虑的是操作签名（signature）。
它定义了调用操作的精确格式以及操作交换的信息，是对象之间交换信息的基本协议。
UML中，操作记号的一般语法是：
visibilityname（parameter_list）:
return_type
⑶良好的设计类应具备的基本特征
一个良好设计的类该当具备下列几个基本特征：
①完整性。
提供给类的客户可能预期的所有功能。
②充分性。
要保证类的所有方法注重实现隐藏在类背后的意图，应当恰好包含所需要的方法集合并且没有多余的方法。
③原始性。
方法应当设计成提供单一原始的原子服务。
类不应提供多种方法做同一件事情，这样容易使类的客户迷惑，并且会导致维护负担和一致性问题。
④高内聚。
⑤低耦合。
特定的类应当与那些仅仅足以帮助它实现职责的类产生关联，并且应该只关联那些存在真正语义链接的类，这就是低耦合。
⑷设计关联
在设计时，要将分析类之间的关联精化成设计类之间的关联。
分析中捕获的许多关系不能像显示的那样直接地实现，但是又必须能够实现。
所有的设计关联必须具有以下的特性：
①导航性。
表明可从源类的任何对象到目标类的一个或多个对象（根据多重性确定）遍历。
在UML中，导航性由关联带箭头来表示（默认为双向可导航），Χ表示不可导航。
②两端的多重性。
显示对象之间关联的个数。
它往往反映了业务规则，在设计中必须确定。
将分析关联精化成设计关联包括以下内容：
①在恰当的地方将关联精化成聚合或组合关系。
②实现关联类。
③实现一对多关联。
④实现多对多关联。
⑤实现双向关联。
7.1.3对象持久化设计
对象的持久化设计，就是把对象存储在关系数据库中。
这包含两个步骤：
首先，是对象的数据库实现；其次，实现对象和数据库记录之间的转化。
⑴存储对象和关系
对象的属性通常对应关系型数据库表中的列，而一个对象对应表中的一行。
复杂性只会随着属性的复杂化而增加，解决的技巧是将复杂的属性分散到不同的表中，并通过关键字将这些表链接起来。
实现关联时，关联必须通过关系表示，从而会出现一种有趣的现象。
对象之间需要相互进行引用，通常是通过保留其他对象的属性来实现的。
当对象存在于计算机内存时，由编程语言来处理这些问题。
当对象存储在数据库中时，链接需要定义得很清晰。
设计者需要添加特殊的属性来实现链接。
最后，这些属性作为关键字存储到数据库表中。
①实现一对多关系
在一对多关联中，一个对象可以与多个对象相链接。
这时一是整体，多是部分。
一个对象要记录与它相连的多个对象，没有什么便捷的方法可用。
在编程语言中，可以通过在关系的一端设置一个汇集来实现。
在数据库中，关系的多端记录这种关系才有意义。
因而，用于在“多”端存储对象的表，都会附加一个列（或多列）以便存储位于关系的“1”端对象的关键字。
②实现多对一关系
在多对一关联中的“多”属于整体。
由于多属于整体，因此，要在多的一端增加一列来链接到另一端。
③实现一对一关系
可以将一个对象的关键字加入另一个对象中，从而建立链接。
⑵对象持久化方法
当运行的应用程序终止后，怎么去处理对象呢？
对于属性是静态的对象，在完成设计后，就会保持不变。
它们的属性值一般已保存在特定的文件中，一旦需要创建，由程序直接从文件中创建。
因此,只需要简单地释放它们就可以了。
还有一些临时性对象，虽然其属性是动态的，一般在完成其生命周期后，也就可以让其永远地消失了。
但有一些对象，在程序的下一次执行中必须恢复本次执行时的属性值。
也就是说，这类对象在程序结束后，需要保存其属性值及与其他对象的关系，以便在下一次执行时从中创建或恢复出这些对象。
所谓对象持久化，简单地说，就是研究对象永久性存储的问题。
如何实现对象到关系数据库的映射是对象持久化最基本的问题。
对象持久化不但要解决对象存储的基本问题，还要提供一种具有鲁棒性的持久化方法，使得对象的存储对于程序设计者是透明的，也就是说，程序设计者无需了解对象是如何存储的，甚至不需要知道存储在什么机制中。
对于关系数据库，有三种不同的对象持久化方法。
①在类程序中嵌入SQL语言方法
直接在类程序中嵌入SQL语言来实现对象到关系数据库的映射和存储是最常用的、最容易想到的、也是最易实现的。
该方法的优点是编写代码快速。
对于小型应用来说，也是一种可行的方法。
其缺点是将域类直接和关系数据库的模式耦合起来，降低了代码的可维护性和可扩展性。
②数据类法
改进的方法是将SQL代码集中起来，包装在一个或多个数据类中。
这种将SQL代码和类程序分离的方法比直接在类源码中嵌入SQL代码的方法要好一些，但仍然只适用于40～50个类的小型应用，即使采用SQL代码包装在数据类中的方法，数据库的结构的改变将导致数据类源码的修改，整个应用程序还需要重新编译。
③持久化层方法
所谓持久化层就是在面向对象层次体系结构中有一个专门负责对象持久化的对象类型层次。
采用持久化层可以实现数据库结构对类源码的透明性，即数据库结构的改变不会影响类源码。
这种方法适合于大规模、关键任务应用。
优点是程序开发者无需了解关系数据库结构。
缺点是对应用系统的性能有所影响。
当然，如果持久化层设计得比较合理，这种影响会很小。
7.2重点难点学习提示
本章的学习目的是使学生能够在面向对象软件开发中，对软件实现架构设计和详细设计。
读者应对以下几个重点、难点问题进行深入的学习，切实掌握好面向对象软件设计的基本方法。
1．面向对象技术的设计准则
系统设计的优劣直接影响软件质量。
在设计阶段一定要遵循设计准则，按照设计策略设计出优秀的方案。
面向对象设计应遵循以下准则和策略。
⑴设计准则
①模块化。
模块化是软件设计的重要准则。
在面向对象开发方法中，将对象定义为模块。
对象把数据结构和作用在数据上的操作封装起来构成模块。
②抽象。
类是一种抽象数据类型，在该数据类型之上，可以创建对象（类的成员）。
③信息隐藏。
在面向对象方法中，对象是属性和服务的封装体，这就实现了信息隐藏。
类结构分离了接口与实现，类的属性的表示方法和操作的实现算法，对于类的用户来说，都应该是隐藏的，用户只能通过公共接口访问类的属性。
④弱耦合。
耦全是指一个软件结构内不同模块之间互联的依赖关系。
依赖关系越多耦合度越强，依赖关系越少耦合度越弱。
衡量设计优良的一个重要标准就是弱耦合，弱耦合的设计中某个对象的改变不会或很少影响到其他对象。
这样给理解、测试和修改带来很大的方便。
⑤强内聚。
内聚是一个模块内各个元素彼此结合的紧密程度。
结合得越紧密内聚越强，结合得越不紧密内聚越弱。
强内聚也是衡量设计优良的一个重要标准。
在面向对象设计中，内聚可分为服务内聚、类内聚和一般-特殊内聚。
服务内聚是指一个服务应该是单一的，即只完成一个任务；类内聚要求类的属性和服务应该是高内聚的，而且它们应该是系统任务所必需的。
一个类应该只有一个功能，如果某个类有多个功能，通常应该把它分解成多个专用的类；一般-特殊内聚表示：
一般-特殊结构符合领域知识的表示形式，也就是说，特殊类应该尽量地继承一般类的属性和服务。
这样的一般特殊结构是高内聚的。
⑥可重用。
在面向对象设计中，一个类的设计应该具有通用性，为开发相似的系统提供软件重用可能。
软件重用可以提高软件开发生产率，确保目标系统质量。
可重用是面向对象开发方法的一个重要特征。
因此，在面向对象开发过程中，为了实现重用，既要尽量重用已有的类，又要创建可重用的新类。
⑵设计策略
①设计结果应该清晰易懂。
良好的设计结果应该是清晰易懂的，它能提高软件的可维护性和可重用性。
设计时采用以下几个策略能使结果清晰易懂。
●命名一致。
命名应该与专业领域的名字一致，并且要是符合人们习惯的名字。
不同类中相似服务的名字应该相同。
●重用协议（公共接口）。
在设计中应该使用已经建立了类的协议，避免重复劳动或重复定义带来的差异（不统一）。
这些协议可能是其他设计人员已经建立了类的协议，或是类库中已有的协议。
●减少消息连接。
尽量采用已有标准的消息连接，去掉不必要的消息连接。
采用统一模式建立自己需要的消息连接，以便理解和使用，增强可理解性和可使用性。
●避免模糊的定义。
应该定义具有明确、有限用途的类，避免那些模糊的、不准确的类定义。
②一般-特殊结构的深度应适当。
从基类派生子类，再从子类派生下一层子类，这样的一般-特殊结构的类层次数应该适当，不必过于细化，层次的深度应该是有限的。
一般来说，在一个中等规模（大约包含100个类）的系统中，类层次数应保持为7±2。
③设计简单的类。
类设计应该尽量小而简单，便于开发和管理。
实践表明，简单一个类的定义在50行左右（或两屏）。
简单类可按照下列策略定义。
●避免包含太多的属性。
一个类包含的属性多少将决定类的复杂程度。
一个类包含太多的属性表明该类太复杂了，就可能有过多的作用在这些属性上的服务。
●避免提供太多服务。
一个类包含的服务多少也是决定类的复杂程度的一个重要因素。
一般来说，一个类提供的公共服务不要超过7个。
●明确精练的定义。
如果一个类的任务简单了，则它的定义就明确精练了，通常任务简单的类可用几个简单的语句描述。
●简化对象间的通信。
每个对象应该独立完成任务。
也就是说，对象在完成任务时，尽量不要依赖于其他对象的配合（帮助），对象之间过多的领带会破坏类的简明性和清晰性。
虽然，遵循上述设计策略能设计出明确精练的较小的类，但在开发大型软件系统中，必定会有大量较小的类设计出来，这将会导致类间的通信变复杂，采用划分“主题”的方法，可以解决这个问题。
④设计简单的协议。
消息中的参数越多表示对象之间传递的消息越复杂，这样表明对象之间的领带关系越复杂。
一般来说，简单消息中的参数不要超过3个。
过多的参数会导致对象的修改较复杂，因为对一个对象的修改往往导致其他对象的修改。
⑤设计简单的服务。
类中的服务应该设计得既简单又小，用3～5行源程序比较适合。
服务的源程序中不要包含过多的语句行，或者复杂的语句控制结构。
如果一个服务非常复杂，则应该检查该服务的控制结构，并进行分解和细化，尽量避免设计复杂的服务。
⑥减少设计变动。
随着方案逐渐成熟，改动也应该越来越小，这样才能设计出优良的结果。
2．面向对象设计的五个层次、四个部分
面向对象设计是在面向对象分析模型的基础上建立对象模型的过程。
两个阶段同样是建立对象模型，只是面向对象分析建立了问题域的对象模型，而面向对象设计建立的是求解域的对象模型。
因此，面积对象设计也由主题、类-&-对象、结构、属性和服务等到五个层次组成，并且又扩充了问题域（PDC）、人机交互（HIC）、任务管理（TMC）和数据管理（DMC）四个部分。
这五个层次就象五个透明的图层，而整个模型象是由五个图层（水平切片）合并而成的，五个层次一层比一层描述得更具体、更明确；四大组成部分又可想象成为整个模型的四个垂直切片。
不同的应用系统中，这四个子系统的侧重程度和规模都不同，应该根据系统规模的大小确定子系统的数目。
在复杂的系统中，子系统可能要继续分解；对于小系统来说，可能要合并小的子系统。
3．问题域子系统设计
问题域子系统设计也称问题域部分（PDC，ProblemDomainComponent）。
面向对象分析到面向对象设计是一个平滑的过渡，即没有间断没有明确的分界线。
面向对象分析建立系统的问题域对象模型，而面向对象设计是建立求解域的对象模型。
都是建模，但两者必定性质不同，分析建模可以与系统的具体实现无关，设计建模则要考虑系统的具体实现环境的约束。
面向对象方法中的一个主要目标是保持问题域组织框架的完整性、
升级会员 