第10章面向对象的设计方法用例实现Word文件下载.docx
《第10章面向对象的设计方法用例实现Word文件下载.docx》由会员分享，可在线阅读，更多相关《第10章面向对象的设计方法用例实现Word文件下载.docx（42页珍藏版）》请在冰豆网上搜索。
Billsantora笑着说：
“等等，只完成这六个主要功能的编码和运行并不意味着项目的结束。
这个项目还需要一年的时问来完成。
“是的，我知道。
但是两个月之后我们可以做出点东西来就很好。
不单只有我对项目有信心，用户也愿意看到事情有所进展。
“没错，别忘了我开始提出用UP来做这个项目的时候是多么的艰难！
因为UP是一种迭代的方法，所以为以后的迭代制定计划是比较困难的。
我花了很长的时问让大家相信这个项目的风险不是很大。
因为每次迭代只有六个星期的时间，所以在开始阶段就要展示一些东西。
你不知道设计通过评审之后，我的压力就会减轻很多。
大家做了很多工作来确保设计的可靠性，我们觉得很有信心。
能够得到认可是多么好的一件事。
在接下来的两个星期我们还有一些关于新系统的基本工作要做。
“采用渐增式的方法很有意义。
我尤其喜欢你给每个用例设计做的详细的顺序图。
支持每个用例的三层设计，你做得非常好。
我能明白每个用例是怎样完成的，但是我还是不太明白先进的面向对象技术。
我想当你证明用同样的基本设计可以既为我们内部银行出纳员又为Web端的用户设计系统时，大家会拍手为你叫好的，祝你成功!
BillSantorla回应了MaryGarcia的祝贺，说：
“类图的设计怎么样？
你不觉得类图使得类和方法看上去更加明白吗？
我们在组内讨论的时候都是用它们进行交流的，它们确实能帮助程序员写出好的、可靠的代码。
“顺便问一下，你们安排再和用户进行复审了吗？
”MaryGarcia问。
“没有，我们在开发用例和创建用例描述的时候和用户联系比较紧密。
我们还和用户共同开发了所有这些用例的原型。
所以，我们无须向用户解释设计模型的细节，就可以对这些用例进行编码了。
毕竟，几个星期后我们要给他们展示一些东西。
然后，我们和用户有下一轮的会议，让他们给我们的工作提意见，我们便可以开始下一阶段的迭代。
我们需要他们的意见来开发下一阶段的用例描述。
“我很期待看见第一阶段的成果。
在项目的后续开发过程中可以测试这些核心功能是很有意义的。
让我再次祝贺你。
”MaryGarcia建议和Bill一起去吃午饭。
概述
回忆一下第2部分，面向对象分析是由两个目标组成的，即发现和理解。
发现是由发现事实的活动组成的，比如和系统用户面谈，而理解是提取从被采访用户那里得到的信息并且构造相互关联的广泛的模型的过程。
在第5章，学习了如何识别问题的主要类和用例，这些类和用例提供了理解系统需求的基本信息。
在第7章，学习了如何通过细节描述、活动图和系统顺序图（SSD）扩展每一个用例的方法，以及通过继续精炼域模型类图的方法来完成面向对象分析需求模型。
建立模型是理解用户需求必不可少的部分，同时也影响着最终的系统。
然而，要记住建立分析模型的目的不是描述新的系统，而是更精确地理解系统需求。
第9章介绍了结构和详细设计方面的概念。
你现在已经知道了系统设计要关注很多系统方面的问题，如网络设计、应用设计、数据库设计、用户界面设计和系统界面设计。
本章和下一章的主要问题是如何开发面向对象设计模型，程序员要用这些模型来为系统编码。
两个必须开发的最重要的模型是设计类图和交互图（顺序图和协作图）。
你将学到如何为三层设计中的每一层开发设计类图，这三层包括域层、可视层和数据访问层。
设计类图扩充了分析阶段开发的域模型。
交互图也扩展了分析阶段开发的系统顺序图。
我们还将讨论如何将类关联到包图中，并说明其中的联系和依赖。
最后，我们讨论一些优秀的设计准则，以及应用这些准则的方法。
10.1面向对象设计——分析和程序设计的桥梁
如果我们把开发新的软件系统比做盖房子的话，我们说分析就像是建筑师最开始的设计草图和方案图。
这些草图描绘了房屋的主人对卧室、地板、布局、位置等的想法。
然而，仅有这些草图承包人是不知道该如何建造房子的，他需要更详细的信息。
所以，建筑师需要利用草图做出更详细的计划，称之为蓝图。
蓝图详细规定了墙、地板和天花板的样子，对电线和管道设备，甚至是该用什么样的材料都进行了详细的说明。
这些详细的蓝图和软件开发者构建的设计模型是类似地。
可以进一步类推，草图设计好之后，屋主可以再提出他们的要求，但是屋主一般不参加细节设计。
屋主评估并纠正设计细节，但是墙内线路和管道的设计是专家或是建筑师指导承包人完成的。
类似地，在软件设计中，细节设计规范主要是由软件设计专家完成的，用户只是偶尔参与——主要是为了对设计进行纠正。
所以什么是面向对象设计呢？
它是一个建立一系列面向对象设计模型的过程，程序员利用这些模型对系统进行编码和测试。
系统设计是用户需求和新系统程序设计之间必不可少的桥梁。
建筑者如果没有蓝图，是怎样也不会建造出比狗窝或是小屋大的东西的，同样，系统开发者如果没有设计模型是不会开发出一个大规模的系统的。
有的时候，学生在做课程设计的时候需要开发个人的网页或是小型的系统，但是他们认为设计模型不重要。
但是要记住，对于建造狗窝来说蓝图可能不重要，但是对于复杂的东西，比如说房屋，蓝图是必不可少的。
我们这章讲的应用软件的设计，只是面向对象设计的一部分。
正如你在第9章中学到的，用户界面设计、网络设计、控制和安垒设计、数据库设计同样也需要设计任务和设计模型。
10.1.1面向对象程序设计概述
要理解面向对象程序设计，我们首先要理解一个面向对象程序是如何工作的。
面向对象程序是由一系列协同完成某一任务的程序对象组成。
每个程序对象有程序逻辑和一些必要的属性，这些逻辑和属性封装在一个单元中。
对象之间通过互相传递消息来协调工作，它们共同工作来完成主程序的功能。
图10-1描述了一个面向对象程序是如何工作的。
这个程序包括一个输入窗口对象，该窗口用来输入学生ID，以及其他信息。
当学生输入ID后，窗口对象会发出消息（消息2）给学生类，程序会产生一个新的学生对象（实例），同时也转到数据库中取得学生信息并把这些信息组成一个对象（消息3）。
一旦那样执行了，新的学生对象会给窗口对象返回一个消息并显示在屏幕上。
职员此时会输入个人信息的更改（消息4），与此同时，发送了消息的另一个消息序列可用来更新程序中的学生对象和数据库中的学生信息。
面向对象程序有个一般性问题，即到底是谁在控制这一切呢？
在结构化程序中，哪个模块是主模块，哪个模块控制着计算任务，这都是很明显的。
然而在面向对象程序中，这就不明显了。
实际上没有哪个模块能进行控制。
没错，有一个启动程序，但是一旦程序开始执行，就没有哪个模块或对象来控制了。
图10-1面向对象事件驱动程序流
让我们用一个或许是你很熟悉的类比——计算机类比来比较一下面向对象程序和结构化程序的不同。
主机是一个具有强大计算能力的大型机，一个主机也许连接并控制着几千个独立的终端，终端只有在主机指令下才会工作。
主机也能对数据库进行存取，这一点很像结构化程序。
相反，许多由网线连接起来的独立的计算机组成了一个个人计算机网络。
每个计算机都有计算能力。
如果你在一台计算机士工作，你能通过一个信息或产生求助信号联系另一台计算机。
例如，网络上一些计算机也许有很大的硬盘和能访问的数据库，我们称它们为文件服务器。
其他资源，如网络打印机。
如果你在一个网络环境中工作并且需要打印一些东西，你的计算机就会发出一个请求打印的消息给控制打印机的计算机。
在许多你所熟悉的网络中，各个独立的计算机没有单独且一致的任务，但可以假设有一个中心任务。
每个计算机能完成整个任务的部分功能。
计算机共同工作，通过互相之间再次发送消息来完成整个计算任务。
这种系统工作与所设计的面向对象的系统或程序很相似。
一个面向对象系统由一系列计算对象组成。
每个对象都封装了它自身的数据和程序逻辑。
分析员通过一个类来定义程序逻辑的结构和数据字段。
类定义描述了一个执行对象的结构或模板。
只有当程序开始执行时，对象才能存在。
这个过程我们称之为类模块的实例化，或基于类定义所提供的模板生成对象实例。
实例化：
根据类定义所提供的模板创建对象。
面向对象设计的目标是识别并确定所有对象，并生成每个用例，比如用户界面对象、问题域对象及数据库访问对象。
正如第9章所讨论的，由于在逻辑上我们可以把对象分为三层，因此被称为多层设计。
除了识别类以外，另一个设计目标是用足够的细节来说明每一个类，使得程序员能理解这些对象是如何协同工作以生成用例的，并可以为每一个类编写面向对象的代码。
对于一个学生注册系统，用程序语言实现的部分类的定义可以参考图10-2（a）和10-2（b）。
我们先用Java实现了类的定义，然后用VisualBasic.NET实现了类的定义。
（a）用Java实现的学生类的定义
图10-2学生注册系统的类的定义
（b）用VisualBasic实现的学生类的定义
图10-2（续）
作为面向对象系统的设计者，你要为程序员编写初始的类定义提供足够的细节，并可以不断在代码中添加细节。
在下面的部分你会看到，面向对象设计的主要部分是设计类图、交互图，还要设计有些类的状态图。
比如，一个设计类说明帮助定义了属性和方法。
在本章的后半部分你会学到设计类的具体方法，但是作为一个很重要的例子，我们可以先看一下图10-3。
你应该可以看出这些属性和方法对应图10-2中的哪部分代码。
注意，类名、属性和方法名来源于设计类符号。
当然在设计类的时候，我们比较自由地缩减了第一个名字和最后一个名字来简化名字，并且把所有的地址成分组合到一起，称之为地址。
如果程序员不知道是否该把这些简化了的名字分开，那么设计者就不能这样进行简化。
其他需要被加入到类定义中的代码能够从其他的设计模型中获得，包括交互图和功能图。
当我们讨论设计类的时候，要不断回过头来看看图10-2中的代码，可以帮助我们看到设计和编程实现之间的联系。
我们还要讨论面向对象设计中的其他模型和图，这些其他模型如包图和部署图，它们对文档设计是很有用的。
但是要记住，主要的面向对象设计模型是设计类图和交互图，有些地方还需要状态图。
图10-3Student类的简化设计类
10.1.2面向对象设计过程和模型
在这一章中，我们关注了三个面向对象设计模型，即设计类图、交互图和包图。
图10-4说明了用哪种分析方法来开发哪种设计模型。
左边的模型——用例图，用例描述和活动图，域模型类图和系统顺序图——是在分析阶段开发的。
右边的那些模型——设计类图，交互图和包图——将在设计阶段开发。
从图中的箭头可以看出，交互图是设计中的核心图，在这一章中你将学到如何开发交互图。
本章你还将学到的主要设计模型是设计类图。
它的主要功能是编写文档并描述新系统中要建立的程序类。
它们描述了程序设计中一系列需要的面向对象类、类之间的联系、特征名称和属性、方法名称和属性。
如图10-4所示，这些信息有两种来源：
域模型类图和交互图。
事实上，设计类图和交互图之间的箭头有两个方向。
双向箭头说明了设计类图中的一些信息要用来完成交互图，而交互图中的一些信息也被用来完成设计类图。
设计过程要求一些步骤，包括迭代。
首先创建设计类图的基础版本，或是初步模型。
初步模型中要包含一些诸如属性名称的基本信息，以便用来设计交互图。
图10-4带有各自输入模型的设计模型
设计中的第二个阶段是开发交互图，即为每一个用例产生一个交互图。
开发一个交互图需要很多步骤，交互图决定了哪些对象一起工作，以及怎样协同工作。
开发交互图是面向对象系统设计的核心。
正如图10-4所示，交互图的输入模型使用了用例图、用例描述、系统顺序图和设计类图。
我们称这些设计模型的最终开发结果为用例的实现。
在这个例子中，术语实现指的是对每个用例的详细系统过程进行说明，而不是实现用例。
换句话说，是制定了软件的蓝图。
因此，不仅仅只有面向对象分析是用例驱动的，面向对象的设计也是用例驱动的。
也就是说，设计是由一个用例接着一个用例完成的。
用例的实现：
对每个用例的详细系统过程的说明。
面向对象设计中的第三步是，根据开发交互图时得到的信息，回过头来设计类图和开发方法名称。
可视化和特征信息也是在设计类图的迭代中被修改的。
设计的最后一步是，用包图将设计类图分割成相关的功能。
有几种分割系统的方法。
一种方法是建立子系统，另一种方法是分层。
在第9章中，我们已经学习了多层和多级结构。
本章中，我们将学习如何将设计类图分解成多个包，以表示多层系统中不同的层次。
我们关注的是基本的多层设计，有可视层（用户界面类）、域层（来自问题域模型类图的问题域类）和数据层（数据访问类）。
注意用来表示域层的几个术语。
同义术语包括域层、问题域层和业务逻辑层。
包图可以使我们从较高的层次去看待最终的系统。
10.2设计类和设计类图
如图10-4所示，设计类图和详细交互图均使用对方作为设计时的输入，二者的开发过程是平行的。
设计类图的第一次迭代是基于域模型和工程设计准则的。
初步设计类图用于辅助开发交互图。
由于设计决策是在交互图的开发过程中制定的，所以结果又可以用来完善设计类图。
正如我们前面提到的，设计类图是面向对象分析时开发的域模型类图的扩展。
域模型类图揭示了问题域类和它们之间的联系。
由于分析是一个发现的过程，所以分析人员一般不大关心属性或方法的细节。
然而在面向对象的程序设计中，类的属性必须被声明成公开的或私有的，每一个属性必须定义类型，比如字符型或数字型。
在设计阶段，详细定义这些细节是很重要的，详细定义传递给方法并返回结果的参数也是很重要的。
有的时候，分析人员还要定义每种方法的内在逻辑。
设计类图是域设计模型类图更详细的体现。
我们通过集成来自交互图和其他模型的信息来完成它。
当开发者建立设计类图时，还要在以前的域模型的基础上增加很多类。
因为设计的目的是了解需求，所以重点是说明定义问题域的类。
然而要建立一个完整的面向对象系统，还要定义很多其他设计类。
如图10-1所示，输入窗口对象和数据库对象就是这些必须被定义的额外类的例子。
当这些类被定义后，我们通常会在不同的类图中证明它们。
系统中的类能被分解到各种不同的类图中，比如说用户界面类，同时我们也用子系统来开发各种类图。
关键是类图绘制是一种灵活运用的工具。
我们现在来介绍开发设计类图的第一次迭代中使用的设计类图符号和设计准则。
10.2.1设计类图符号
统一建模语言（UML）没有说明设计类符号和域模型符号的区别，但实际上二者是存在区别的，原因主要是由于设计模型和域模型的目标不同。
域模型展现的是用户工作环境下的情况，以及它们之间的联系。
类不是特指软件类，但是只要我们开始创建设计类图，我们就要定义软件类。
因为在设计过程中要定义很多不同类型的设计类，UML使用了一种特殊的符号，叫做构造型，它允许设计者为每一个类指明一个专门的类型。
构造型将模型元素以特定的类型分类。
通过说明我们想要强调的特征来扩展模型元素的基本定义。
构造型的符号就是将类型的名称放到书名符号中，像《控制》这样。
当你开始设计一个用例图的时候，首先要定义一个构造型。
前面已经学过，角色和用例之间的连接线表明了一种关系，以及用例之间关系的类型，称为《包含》关系。
这就是一个构造型，因为它把一个用例的关系归类为包含另一个用例。
构造型：
按照模型元素的特征进行归类的一种方式，用《》符号描述。
有四种类型的设计类被认为是标准的设计类：
实体类、控制类、边界类和数据访问类。
图10-5展示了用来识别这四种构造型的符号。
两种类型的符号可以用于设计类。
左边的表示类的方框给出了完整的符号。
在每个方框中，名称上方是构造型。
右边的圆形符号是这些构造型的速记符号，叫做图标。
我们会经常使用这些构造型图标，但是在大多数情况下我们更倾向于使用完整的符号。
实体类是问题域类的设计标识符。
换句话说，它来自域模型。
这些对象通常是被动的，因为它们只是等待事情的发生，通常它们还是持久类。
一个持久类在程序结束后仍然存在。
也就是说，在系统关闭后这些数据仍要存在。
很明显，实现的方法就是将它们写入文件或数据库。
图10-5设计模型中的标准构造型
边界类是存在于系统的自动化边界上的。
在一个计算机系统中，这些类可以是窗口类或是所有和用户界面有关的其他类。
控制类是在边界类和实体类中间起协调作用的类。
换句话说，它负责从边界类对象获取信息，然后发送到适当的实体类对象，就像是域层和可视层之间的一个开关或是控制器。
数据访问类是从数据库获取信息或向数据库发送信息的类。
不同于向实体类方法中插入数据库访问逻辑（包括SQL语句），在设计中通常包含一个访问数据库的独立的类的层次。
实体类：
是问题域类的设计标识符。
持久类：
程序结束后仍然存在的实体类。
边界类：
存在于系统的自动化边界上的类，如输入窗口。
控制类：
是在边界类和实体类中间起协调作用的类，在域层和可视层之间起开关控制
的作用。
数据访问类：
是从数据库获取信息。
10.2.2设计类符号
图10-6详细说明了设计类符号。
名字部分包括类名和构造型信息。
下面的两个部分包含了关于属性和方法更详细的信息。
图10-6定义设计类的内部符号
分析员用来定义属性的格式如下：
属性可见性（+表示可见，-表示不可见。
可见性表示其他对象是否能直接访问这些属性）；
属性名称；
类型表达式（例如，字符型、字符串型、整型、数字型、货币型或日期型）；
初值；
原型（在花括号内），比如{关键字}。
第三部分包含了方法特征信息。
方法特征显示了需要调用这个方法的所有信息。
它给出了这些要发送消息的格式，包括如下内容：
方法可见性；
方法名；
类型表达式（方法返回参数的类型）；
方法参数列表（输入参数）。
方法特征：
描述调用该方法所需的所有信息的符号。
在面向对象的程序设计中，分析员通过使用完整标识来识别每一个方法。
一些面向对象语言允许多个方法使用同一个名称，因此要将它们区分开来，我们就要使用参数表。
在这些语言中，需要用方法名和参数表去激活相应的方法。
例如，假设我们想通过客户ID或客户名来取得客户记录，那么我们就可以建立两个方法，并为这两个方法起同一个名字，例如，“getCustomer（CustomerlD）”和“getCustomer（CustomerName）”。
我们把getCustomer叫做方法重载——即这两个方法有同一个名字。
想要知道哪个方法被激活，则编译器需要知道包含参数是什么——即输入的参数是一个数字（CustomerID）还是一个字符串（customerName）。
第7章说明了学生注册系统的域模型的几个类。
图10-7进一步比较了域模型学生类和设计类图学生类。
域模型属性列表包含了所有在分析活动中发现的属性。
设计类图包含了关于属性类型、初值和原型的更多的信息，它也可以包含用来声明的构造型，Student类就是一个《实体》构造型。
在设计类图Student类中，第三部分包含了类的方法特征。
大多数方法特征是在设计交互图的时候建立的。
记住，UML是一种笼统的面向对象的符号技术，而不是特定的某一种语言。
所以，这些符号和程序设计方法中的符号不完全一样。
图10-7域图和设计类图的学生类例子
比如，对于有程序设计经验的人来说，使用的构造器符号是CreateStudent：
student（name，adress，maior）。
构造器是用来建立类的新对象的方法。
在很多程序设计语言中，构造器和类有同样的名字。
然而，我们使用创建语句来跟踪在交互图中使用的信息名称。
图中还说明了另一个构造器。
在第二个方法中，只有StudentID被传递进来。
这说明一个学生只有ID的信息，构造器要自己填充学生的其他信息。
这通常要求访问数据库以获得该字段的值。
图中用横线标识出来的叫做findAboveHours（inthours）：
StudentArray的方法是一种专门的方法。
在面向对象方法中，类是创建个体对象和实例的模板。
对类的每个实例大多数方法都适用。
但是，分析员常常需要立即检查所有的实例。
这种类型的方法称为类级方法，它们用下划线表示出来了。
在VB.NET里，这种方法称为共享方法；
而在Java里，它是静态方法。
这种方法是由类而不是由类的某一对象执行的。
因为这些方法在类级别应用，它们不依赖于某一对象的存在，如果需要，就可以通过所有的对象访问数据。
在这个例子里，findAboveHours方法审查了类的所有例子，返回了那些总小时数比输入参数大的学生队列。
类级方法：
与类而不是类的对象相关的方法。
10.2.3一些基本的设计准则
既然你已经了解了一个面向对象程序是如何运行的，也学习了设计类的符号，让我们来回顾一些指导设计决策的基本准则。
在本章中，我们讨论面向对象设计的步骤时，会提到这些好的面向对象设计的准则。
以下的这些基本准则对面向对象设计的每一部分都很重要。
封装和信息隐藏
封装是一种设计概念，它说明了一个对象包含数据和程序逻辑的独立单元。
每个对象都是内部携带自己的数据，并提供访问数据的方法，而且还提供一系列调用对象方法的服务。
用这种方法设计软件的一个好处就是软件开发人员可以用搭积木的方式设计系统。
几乎所有的工程规范都有像积木块一样的标准单元，它们可以组合形成最终的设计。
被封装的对象等价于软件的每一个积木块。
封装：
是一种设计准则，规定数据和程序逻辑包含在一个独立的单元中。
程序员依靠封装带来的好处支持对象重用的思想。
每一种面向对象的语言都有一些在系统中被反复使用的标准对象。
这些对象的标准集提供了在同一系统中多次使用的基本服务——有时甚至是在不同的系统中多次使用。
重用的一个最普遍的例子是为计算机或网络应用设计用户界面。
设计者通常重用相同的类来开发窗口和诸如按钮、菜单、图标等的窗口部件。
问题域类也会被重用。
对象重用：
是一种设计准则，说明标准对象可以在系统中反复使用。
和封装相关的概念是信息隐藏。
信息隐藏的意思是，和一个对象有关的数据对外部世界是不可见的。
换句话说，对象的属性是私有的。
用一组方法来访问和修改数据。
虽然这条准则主要是一个程序上的概念，并且主要有利于编程和测试，但它是一些重要准则的基础。
如果对数据属性的访问是通过10.2.4节中将要介绍到的方法名称的标准接口来实现，则系统中对象间的联系和耦合会好的多。
信息隐藏：
是一种设计准则，指和一个对象有关的数据对外部世界是不可见的，通过使用一组方法来访问和修改这些数据。
导航可见性
就像前面提到的，面向对象系统是相互作用
升级会员 