第7章 面向对象分析与设计

1、 2022-5-24 1结束返回第7章 面向对象分析与设计第7章 面向对象分析与设计2022-5-24 2结束返回第7章 面向对象分析与设计2022-5-24 3结束返回 系统分析的本质是建立业务领域的逻辑模型逻辑模型，描述业务领域对象如何交互以实现用例定义。它的目的是定义计算机系统的行为，以及怎样与业务环境交互，用面向开发人员的术语来描述系统，形成系统“需要做什么”的描述。 分析工作的目标是产生分析模型，产生三个重要的分析制品： 分析类用例实现构架分析工作的目标分析制品图 分析类:业务领域中建模的主要概念。 用例实现:演示分析类的实例(对象)如何交互以实现由用例所说明的系统行为。 构架:对业

2、务领域中的类进行划分组织、形成领域的整体结构。 本节中在描述计算机系统行为用例实现时，将使用UML的顺序图、协同图、类图和状态图。第7章 面向对象分析与设计2022-5-24 4结束返回7.1.1 7.1.1 分析类分析类 分析类的概念分析类的概念分析类应该展示非常“高级层次”的属性集合。 它们表示最终设计类可能具有的属性。可以说分析类为设计类捕获候选属性。同时，分析类的操作分析类的操作说明必须提供关键服务。在设计中，它们可能分解成一个或多个实际的、可实现的方法方法。在分析中，分析类避免实现细节，常常由下面几部分组成： BankAccountbalancenam

3、enumberwithDraw()depoist()calculateInterest()图7.1账户分析类 名称: :这是必需的。 属性: :尽管只有候选属性的重要子集在此时建模，属性名称是必需的。属性的类型是可选的。 操作:在分析中，操作仅是类职责的高级层次的陈述。只在它们对于理解该模型很重要时，显示操作的参数和返回类型。 构造型:如果它们将增加模型的清晰性，可以显示出来。 总之，分析类的核心思想是，尽力捕获抽象的本质，忽略实现细节到设计阶段。如图7.1的银行账户分析类。第7章 面向对象分析与设计2022-5-24 5结束返回那么，如何产生良好的分析类呢？下面给出几点做法： 名称反映目的。

4、 建模问题域的一个特定元素是简洁的抽象。 清晰地映射到问题域中可识别的特征。 具有小的、良好定义的职责集合。 高内聚、低耦合。7.1.1 7.1.1 分析类分析类 分析类的概念分析类的概念第7章 面向对象分析与设计2022-5-24 6结束返回UML中，类有三种不同的构造类型，分别称为实体类、边实体类、边界类和控制类界类和控制类，如图7.3所示： UML UML类的构造型类的构造型在面向对象系统的分析与设计中，它们的角色是不同的。实体类边界类控制类构造类型构造类型图实体类实体类主要用来为持续存在的对象建模，系统也需要保存关于这些对象

5、的长期信息。 边界类边界类是用来控制与外界交互的，例如窗口类。 控制类控制类将复杂行为组织起来，这些行为涉及了大量边界类和实体类。第7章 面向对象分析与设计2022-5-24 7结束返回Customer图7.2 实体类的UML符号Customer图7.3 用标签表示的实体类 实体类的符号如图7.2所示，也可以使用普通的标签类符号表示，如图7.3所示 UML UML类的构造型类的构造型(1)实体类第7章 面向对象分析与设计2022-5-24 8结束返回BankAccount_EntryScreen图7.4 边界类的UML符号表示 边界类 边界类如图7.4所示。边界类

6、定义了系统与外部世界交互的接口，它可能是窗口，也可能是电子交易接口。 所有用例都会涉及到某种形式的边界类，或者也可能是大量的边界类，来处理与外部世界的交互。这是用例复杂行为的外在表现。 UML UML类的构造型类的构造型 边界类的角色是把参与者提供的信息翻译成控制类和实体类响应的内部事件，并按照参与者能够理解的形式表示出这些对象的响应。 对于人作为参与者来说，边界类的实例通常是以显示屏或者指印输出的形式出现，对于其它系统作为参与者的情况，边界类可能是以协议的形式出现。第7章 面向对象分析与设计2022-5-24 9结束返回 控制类 控制类如图7.5所示。控制类用于

7、在许多对象之间进行调解。一般地，当用例的行为涉及到大量对象的协作，控制类此时作为调解人。Customer_Manager图7.5 控制类的UML符号 UML UML类的构造型类的构造型 那么，如何寻找分析类呢？实际上，这是OO分析与设计的核心问题。 实际上，找出“恰当”的类依赖于个体分析师的知识面、技术和经验。他们常用名词/动词和CRC(类、职责以及协作方法)来寻找分析类。 本章中，我们将使用另一种方法来寻找分析类。基本思想是：在用例实现的过程中，由顺序图驱动来寻找分析类。第7章 面向对象分析与设计2022-5-24 10结束返回7.1.2 7.1.2 顺序图顺序图

8、 系统分析中，顺序图是这样一种方法，它研究需求分析阶段中搜集来的用例，将用例定义中的顺序和在用例中相互作用的对象串在一起。其中在使用顺序图时，要么连接到已知对象上，要么创建新的对象来支持这个用例。 顺序图表示以时间序列安排的对象交互的二维图。对象沿着图顶部排列，交互则按照时间顺序从上到下列出来。这些交互告诉我们，对象单独的和组合的行为是什么。 由此，设计人员就能找到可以实现的把行为映射成类的方法。 我们遵循的过程是从已得出的用例中识别一系列代表性脚本，并用顺序图将其细化，其中脚本集应包括用例中的所有替代路线和主要路线。接着，把顺序图转换化协作图，最后，把协作图转化为类图。第7章 面向对象分析与

9、设计2022-5-24 11结束返回 现在，再来讨论图书馆信息管理系统的借书用例。对此用例，首先考虑主要路线：1.管理员打开借书窗口。2.管理员得到借书者号，并将其输入显示屏。3.管理员点击确认按钮。4.查询用户及已借书的详细信息，并显示在屏幕上。5.管理员核实用户可以借书。6.管理员得到书目号，将其输入在屏幕上，并提交。7.管理员确认此书目可以借阅。8.系统生成一条借阅记录。必要时，6、7、8三步将重复进行，直至超过借阅最大数。7.1.2 7.1.2 顺序图顺序图第7章 面向对象分析与设计2022-5-24 12结束返回图7.6 借书用例顺序图起点 顺序图将支持脚本的对象组合起来排列在顶部。

10、对于借书用例的主要路线，给出下面的顺序图。 7.1.2 7.1.2 顺序图顺序图 主要路线的第一步是：管理员打开借书窗口。这给出了顺序图的起始点，如图7.6所示。这表明有一个管理员Librarian(一个参与者)使用借书窗口Lend_Window(一个边界对象)来进行借书的信息输入，这里引入Lend_Window，来控制与该脚本的所有交互。第7章 面向对象分析与设计2022-5-24 13结束返回 分析主要路线的下一步：管理员得到借书者号，并将其输入显示屏。当管理员把用户借书证号输入以后，这里不大可能需要涉及到其他任何对象，直至第三步管理员提交(submit)为止。 图7.7 顺序图扩展7.1

11、.2 7.1.2 顺序图顺序图 提交可能通过输入顾客号之后点击返回，或者通过按钮，或者通过扫描仪扫入借书证号来实现。无论哪一种方式，都可以扩展顺序图来合并提交，从而得到如图7.7所示的顺序图。第7章 面向对象分析与设计2022-5-24 14结束返回 分析第四步：查询用户及已借书的详细信息，并显示在屏幕上。 这意味着需要某个对象来存储用户的姓名、班级、借阅的最大数量和目前已借书数量，明智的做法是将这些信息组合到一个叫User的单独对象中。由于User对象需要持续存在的，并与现实世界的实体，即借书者严格对应的，因此，它是一个实体对象。7.1.2 7.1.2 顺序图顺序图第7章 面向对象分析与设计

12、2022-5-24 15结束返回 这说明我们的系统中可能有UserUser类的实体对象类的实体对象，该类有借书号(userID)、姓名(name)、班级(class)、最大借阅数量(max)、目前已借的书数量(currentBook)等属性。 对于此步，我们还应该看到，系统有用户已借书的借阅记录对象借阅记录对象来记录存储借阅情况，它包括：借出日期(loanDate)、到期日期(dueDate)、归还日期（returnDate）书库地点(store_Address)。 因此，系统中可能有一个类类LoanLoan,它有属性loanID、loanDate 、dueDate、returnDate、st

13、roeAddress。显然，我们需要书目对象，所以系统中也可能有Item这个类。如图7.8所示。图7.8 顺序图扩展7.1.2 7.1.2 顺序图顺序图第7章 面向对象分析与设计2022-5-24 16结束返回有了上面3个类，我们给出主要路线前四步的顺序图，如图7.9所示。图7.9 顺序图进一步扩展7.1.2 7.1.2 顺序图顺序图第7章 面向对象分析与设计2022-5-24 17结束返回 对于主要路线的第5步：管理员核实用户可以借书。这主要由管理员对查询的信息进行人工的核实来完成。 下面我们来分析第6步：管理员得到书目号，将其输入在屏幕上，并提交。 第7步：管理员确认此书目可以借阅。这几步

14、中，显然有一个书目对象，它存储itemID、ISBN(书号)，从而系统中有一个类Item，它包含两个属性。进而得到如图7.10所示的顺序图。图7.10 顺序图进一步添加第7章 面向对象分析与设计2022-5-24 18结束返回图7.11 顺序图进一步添加接下来，分析第8步：系统生成一条借阅记录。对应图7.11的顺序图。7.1.2 7.1.2 顺序图顺序图第7章 面向对象分析与设计2022-5-24 19结束返回 现在，有了比较细化的顺序图。但是，显然窗口负责大量的控制信息，因此要求窗口对象保存与借阅有关的信息，如User对象、Item对象和Loan对象。这显得窗口职责太多，我们推荐使用在任何用

15、例中都考虑的结构，也就是该用例的控制对象。于是得到图7.12的顺序图。图7.12 借书用例的顺序图在图7.12的顺序图中，对象和参与者下的垂直是时间线，表明了对象随着时间推移的发展历程。箭头可以指向任何方向，并不是只能从左向右，表示对象之间存在通信。箭头并不表示通信的方向，通常是双向通信，而表示哪一个对象引发了这次通信。第7章 面向对象分析与设计2022-5-24 20结束返回 顺序图是用例行为序列与域对象之间非常简洁的链接。实际上，这是找到域对象的最好方法之一。如果集体研究域对象，则往往标识出过多的域对象。 而像上述这样，逐步获得所需要的对象来描述系统行为，一点不多余。应当把顺序图作为用例与

16、对象间的主要链接。 在整个设计阶段，我们会发现顺序图允许你添加越来越多的细节，直至可以确定对象操作的具体细节，派生出属性。7.1.2 7.1.2 顺序图顺序图第7章 面向对象分析与设计2022-5-24 21结束返回 综上所述，给出一些细化用例的简单指导方针： 为该用例标识有代表性的脚本集，包括所有的替代路线和异常路线。 为每个脚本生成如上的顺序图。 把参与者放在左边。 标识边界对象(可能多于一个)，如显示屏。 为脚本的每个步骤画出活动者与边界对象之间的交互。 对于与边界对象的每次交互，确定是否需要和另一个对象交互(简单的数据输入极少涉及与其他对象的交互)。 如果交互是与一个单独的实体对象进行

17、的，则创建实体对象并直接为其请求服务。 如果交互是与许多实体对象进行的，则考虑创建中间控制对象来监管通信。第7章 面向对象分析与设计2022-5-24 22结束返回7.1.3 7.1.3 协作图协作图 协作图是顺序图的一种补充形式，它关注对象交互的结构方面。面向对象的系统通过对象协作来提供其行为，单独的对象只能提供部分行为。 当对象进行协作时，它们能够提供复杂而功能强大的行为。为此，对象交换信息与请求，这些请求的路线就可以用协作图来描述。它显示在特定时刻协作的特定对象，类似oo运行系统的快照。 实际上，这些请求的路线在顺序图中已经定义过了，但是，用另一种不同的方式把它们画出来也是有用的。 第7

18、章 面向对象分析与设计2022-5-24 23结束返回图7.13 借书协作图7.1.3 7.1.3 协作图协作图 对于上面的借书顺序图，它的协作图如下图7.13所示。这样做的好处在于通信线路上看上去更清楚直观。第7章 面向对象分析与设计2022-5-24 24结束返回 协作图类似于简化的类图，可以将它翻译成类图。考虑协作图中对象间的通信，就能开始标识支持关系的对象所需要的操作。研究通信中交换的信息，会发现对象需要记录的属性。当然，这在设计阶段进行考虑。协作图与类图的关键区别在于： 协作图表现了系统一次特定执行中类的关系，而类图表示的是所有潜在执行中类的关系。 协作图可以记录对象间交换的信息，但

19、类图不能。 类图记录了在对象及其属性上进行的操作，但协作图不能。7.1.3 7.1.3 协作图协作图 第7章 面向对象分析与设计2022-5-24 25结束返回7.1.4 7.1.4 类图类图 确定了域对象和交互之后，就可以在类图中记录关于所需要数据的一些信息。 在分析阶段，类图中用关联来联系两个类，而不应该使用属性来联系它们。也就是说，不要用属性来表示对象之间的关系，而应该使用关联。 使用关联能够表示两个对象之间的任何关系，而且能把关系表示得更清楚、更醒目。这样做能够清晰地反映问题的固有本质，而不是实现方法。 第7章 面向对象分析与设计2022-5-24 26结束返回7.1.4 7.1.4

20、类图类图 图7.14显示了一个类图，这个类图反映了图7.13中协作图的结构,考虑替代路线的预订情况，我们引入Reservation类。 同时，由上述可知，相同的书可能有好几本，因此，我们又引入一个Title类来表示书的标题，而用Item类来表示具体的一本书。 在这一阶段，我们还不知道User与Item之间、User与Loan之间、以及Item与Loan之间的关系。但是，很快发现它们之间是有关联的。下面给出寻找的重要关联。第7章 面向对象分析与设计2022-5-24 27结束返回 Title和Item类之间的关联 每个标题可以有多个副本，即有多个书目。标题是不可外借的，书目才是出借的对象主体。它

21、们之间是一种聚合关系，两者是包容关系，是一种强关联。 一个标题对象可以一个书目对象都没有，但一个书目对象必然属于一个标题对象。 7.1.4 7.1.4 类图类图第7章 面向对象分析与设计2022-5-24 28结束返回 User类和Item类的关联 用户借阅书目时,每个用户可以借阅多个书目，每个书目同时只能被一个借书者借阅。但这儿有一个Loan类。借阅记录是应该放在User类中还是应该放在Item类中呢？ 如果放在User类中，则需要对用户所借的每一本书目都要加一个属性到User类中，这样就使用户类变得非常复杂。 如果借阅记录放在Item类中，则需要对每借此本书的用户添加一个属性到Item类中

22、。 因此，无论把借阅记录放在哪一个类中都不合适。借阅记录是User类和Item类之间的一种一对多的关联关系属性，而不是与两者独自有关。也就是说，借阅记录与User和Item并没有本质的关系，只有在两个对象产生借阅关系时才会产生借阅记录。7.1.4 7.1.4 类图类图第7章 面向对象分析与设计2022-5-24 29结束返回 User类和Title类的关联 如果一个标题没有相应书目可借的话，用户可以预订该标题。每个用户可以预订多个标题，每个标题也可以有多个用户预订。其中和Reservation类之间的关系如上分析。7.1.4 7.1.4 类图类图第7章 面向对象分析与设计2022-5-24 3

23、0结束返回图7.14 借书类图第7章 面向对象分析与设计2022-5-24 31结束返回7.1.5 7.1.5 构架分析构架分析 构架分析的目的是尽力最小化系统中的耦合数量，把分析类组织成一组内聚的分析包，进而组织成分区和层。 当然，类的划分与组织应该根据业务用例、类的性质及类之间的关联对类进行划分组织。这样就可以得到构架。第7章 面向对象分析与设计2022-5-24 32结束返回7.1.5 7.1.5 构架分析构架分析 对于图书馆信息管理系统的流通业务来说，借书类图中包含大部分的类，但是我们知道，还有还书窗体(Return_Window)、预订窗体(Reservation_Window)。

24、将以上这些对象与原来的业务对象分为两组：所有的窗体类组织在一起放在GUI包中，所有的业务类组织在一起放在Business包中。 第7章 面向对象分析与设计2022-5-24 33结束返回7.1.5 7.1.5 构架分析构架分析图7.15 领域构架图 由于GUI包中的窗体类要访问Business包中的业务类，因此，它们之间存在包的依赖关系,进而可初步得到图7.15的构架图。 第7章 面向对象分析与设计2022-5-24 34结束返回7.1.6 7.1.6 状态图状态图 状态图一般并不用于系统分析，除非一个对象有某些复杂的行为需要考虑。 当然，状态图可以帮助分析人员、设计人员和开发人员理解系统中对

25、象的行为。状态图只是针对单个对象建模，通过分析单个对象的内部状态转换来了解一个对象行为。 对于有多种内部状态的对象，状态图可以显示对象如何从一种状态转换到另一种状态，以及对象在不同状态中的不同行为。使用状态图可以了解对象行为更多的动态细节。 第7章 面向对象分析与设计2022-5-24 35结束返回7.1.6 7.1.6 状态图状态图 状态图在设计阶段使用得最为普遍。它可以描述一些对象在其生命周期内状态之间的转换。 图7.16描述了书对象状态之间的转换。当图书上架以后，图书就转为在馆可借状态中，然后在外借和在馆之间转换。只有在在馆或外借状态下，对象才能关闭。图7.16 图书的状态图借阅归还第7

26、章 面向对象分析与设计2022-5-24 36结束返回7.1.7 7.1.7 用户接口用户接口图7.18 借书窗口原型图7.18展示了图书馆信息管理系统中用户借书窗口的原型。 第7章 面向对象分析与设计2022-5-24 37结束返回 图7.19展示了图书馆信息管理系统流通业务中可能使用的屏幕组织。 罚款屏幕欢迎屏幕借书屏幕续借屏幕预约屏幕还书屏幕管理员登陆屏幕流通业务选择屏幕图7.19 屏幕组织图7.1.7 7.1.7 用户接口用户接口录第7章 面向对象分析与设计2022-5-24 38结束返回7.1.7 7.1.7 用户接口用户接口再见！第7章 面向对象分析与设计2022-5-24 39结

27、束返回7.2 7.2 系统设计系统设计系统的设计可分为:构架设计阶段 详细设计阶段 构架设计阶段：这是一个从较高层次的进行的设计，是对问题的解和建立解决方法的高层决策。构架定义了系统的总体结构，包括技术构架(如计算机、网络、数据库、开发环境)和应用构架(应用程序如何划分和融入技术构架中)。应该提醒的是：需要在详细设计前考虑构架。 详细设计阶段：主要是决定在实现过程中使用的类和关联的全部定义，以及用于实现操作的各种方法的算法和接口。所有的类都尽可能地进行详细描述，给编写代码的程序员一个清晰的规范说明。 系统设计的输出结果是： 系统构架 设计子系统 详细的顺序图 详细的设计类图 操作说明书 数据库

28、定义 组件结构图7.20 系统设计分类图第7章 面向对象分析与设计2022-5-24 40结束返回7.2.1 7.2.1 构架设计构架设计 在系统分析中，初步考虑过构架。在设计阶段，需要对它们进行细化。构架(有时也叫体系结构)决定了整个应用系统的外形。 构架包括：技术构架和应用构架两种。构架设计可分为:技术构架应用构架图7.21 构架设计分类图 技术构架：包括计算机、网络、工具、包和数据库等等。它是安装和运行应用程序的一个大致框架。它对于应用程序的性能和承载性都有着重要的影响。它往往从应用程序的需要，系统开发的企业文化，到技术产生的市场等诸多因素来进行选择。 应用构架：是关于应用程序如何划分和

29、融入技术构架的问题。大多数应用系统都是基于网络的，需要考虑很多影响系统性能和可承载性的因素。应用构架被看做软件组件的层次结构，每一层都有特定的作用和职责。此外，应用构架还需要考虑非功能性需求，如完整性、可靠性和可恢复性。第7章 面向对象分析与设计2022-5-24 41结束返回 现代技术构架现代技术构架 软件构架从传统的两层C/S(Client/Server)结构到三层C/S结构，发展到目前使用的多层B/S(Browser/Server )结构。 下面介绍三层结构，这是现代构架的一种普通形式。三层结构分散在通过局域网和互联网相连的服务器和微机网络中。 一个用例的处

30、理过程被分成三个基本部分：一是用户接口，二是同控制对象相关的业务逻辑，三是同实体对象相关的数据服务。它的物理外观如图7.22所示。 图7.22 现代技术构架的基础网络PC应用服务器数据服务器第7章 面向对象分析与设计2022-5-24 42结束返回 三层构架的逻辑视图模型如图7.23所示。 表示层处理所有与用户的交互，而且同其他系统交互的元素也位于该层。 业务逻辑层是应用运行的核心。 而持久层通常是关系型数据库，也可能是文件系统。图7.23 现代构架的逻辑视图表示层业务逻辑层存储层 现代技术构架现代技术构架第7章 面向对象分析与设计2022-5-24 43结束返回

31、 当这个构架扩展到互联网时，它的物理外观如图7.24所示。这里用Web服务器作为同用户打交道的接口。PC通过浏览器来访问应用，Web服务器将通过应用服务器来发送请求，由应用服务器对数据服务器进行操作。网络仍然可以是局域网，当然可以是互联网。 图7.24 有Web的现代构架网络PC应用服务器数据服务器Web服务器 现代技术构架现代技术构架 目前，这种形式的物理构架变得非常普通。开发本身的简单性，以及Web应用开发的简单性，使得它们对于很多应用具有相当的吸收力。这种构架也符合图7.23所示的逻辑视图，但是,表示层被分为浏览器(界面层)和Web服务器两部分。第7章 面向

32、对象分析与设计2022-5-24 44结束返回 图书馆信息管理系统的构架图书馆信息管理系统的构架 图书馆信息管理系统是服务于全校师生的系统，没有它教师、学生的教学和科研工作将不能很好的开展，因此，对于构架设计有着重大的意义。 系统的可靠性和性能也是重要的，系统要求能处理大多数严重故障。在应用中，使用Internet界面需求，要求选择工具时，应该有浏览器配置，并将它作为应用的一部分。这里采用现有的成功解决方案。 第7章 面向对象分析与设计2022-5-24 45结束返回 图书馆信息管理系统的构架图书馆信息管理系统的构架图7.25 图书馆

33、信息管理系统的物理构架数据库服务器WEB服务器应用服务器IE浏览器IE浏览器 整个图书馆信息管理系统的物理构架如图7.25所示。该构架包括一个数据库服务器，运行在一台独立的计算机上, WEB服务器和应用服务器运行在另一台的计算机上, 客户端配有浏览器。 技术构架第7章 面向对象分析与设计2022-5-24 46结束返回 表示层语言 现代互联网的表示层语言是HTML。但是随着XML语言的出现，增强了表示层的功能。由于HTML的简单性，该系统采用HTML语言来作为表示层的开发语言，同时，为了处理一些动态的交互，也采用ASP.NET语言。 业务逻辑 按计划应用程序的生命周期应超过十年。可用的应用程序

34、开发语言很广泛，从C+、JAVA到C#都可以使用。JAVA和C#是我们应该首选的。 描述工具描述工具 这里我们选择C#基于以下几点原因。 首先，C#是非常新的语言。 第二C#具有可移值性，允许其所运行的计算机系统改变。 第三C#可以很好地与现代中间件相配合，而且它又是Microsoft的软件产品，几乎提供了一整套的实现技术。 第四它相对于JAVA来说，它的运行速度要快。第7章 面向对象分析与设计2022-5-24 47结束返回 存储层 在存储方面除了采用关系型数据库和SQL语言之外，没有值得考虑的存储形式。对于图书馆信息管理系统的项目来说，这几乎是一个自动的选择。但是，在选择提供者时，却要考虑

35、很多因素。不同的数据库有不同的特点，例如价格、性能和可靠性等。 目前，市场有Oracle、SQL Server、DB2等数据库产品。 对于该系统，因为要求有高性能和可靠性。所以，选用SQL Server 2005数据库服务器，购买磁盘阵列来保证数据的可靠性和性能。 描述工具描述工具第7章 面向对象分析与设计2022-5-24 48结束返回 包和组件 目前市场上有很多包和组件支持现有的图书馆业务，可供我们来选择。但是，因为很多包和组件的功能都不能充分地支持当前的具体业务，所以，我们决定自己来开发。 描述工具描述工具第7章 面向对象分析与设计2022-5-24 49结束返回 连接和中间件 IE和W

36、EB服务器之间通过企业网上的HTTP协议相连接。在确定了应用的构建形式之后，这是自然而然的选择。这个协议在互联网和企业网上都能很好地运行，企业网提供了性能保障。 在应用服务器和数据服务器之间，采用MicroSoft的ADO.NET中间件来解决对象和记录之间的转换与连接。WEB服务器选择IIS6.0。使用ASP.NET处理WEB服务器和应用服务器之间的连接。 描述工具描述工具第7章 面向对象分析与设计2022-5-24 50结束返回 应用构架应用构架 相对于上面的物理构架，图书馆信息管理系统的应用构架相应地分为三层。 除了在系统分析阶段关注的用户界面和业务对象之外，还需要设计业务对象的存储问题。

37、虽然在分析阶段用户并没有对界面和存储提出更多的要求，但这些都是作为系统的设计和实现人员必须要考虑的问题。本案例的应用构架如图7.26所示。 图书馆信息管理系统的构架图书馆信息管理系统的构架第7章 面向对象分析与设计2022-5-24 51结束返回图7.26 应用构架 图书馆信息管理系统的构架图书馆信息管理系统的构架 这里采用了包来描述应用构架。 GUI包含了系统中的窗口界面，这些窗口界面是基于HTML的。该包和Bussiness包协作。 Business包包含哪些实际存储数据的类和控制类。 Database包为Business包中的实

38、体类提供服务，以便它们能够持续地存储。 Database包依赖于ADO.NET包，它主要解决数据库的连接，实体对象和数据库中记录的转换等工作。第7章 面向对象分析与设计2022-5-24 52结束返回7.2.2 7.2.2 详细设计详细设计 得出系统的构架后，接下来进行系统的详细设计。根据构架的层次结构，对每一层所进行详细设计，包括类的详细设计，以及层与层之间的接口设计等。 设计类设计类 设计类剖析设计类剖析 设计关联设计关联 顺序图顺序图 协

39、作图协作图 操作定义操作定义 用户接口用户接口 组件组件第7章 面向对象分析与设计2022-5-24 53结束返回7.2.2 7.2.2 详细设计详细设计 设计类设计类 在分析中，类来源于问题域。这是一组描述你试图去解决问题的需求。前面,我们已知道，协作图可以转化成类图协作图可以转化成类图。设计类来自两个方面的考虑： 设计类设计类是已经完成了规格说明并且达到能够被实现程度的类。设计的主要输出是一个类的集合设计的主要输出是一个类的集合，它们用类图进行描述，类与类之间相互联系，并

40、被组织在一起以便能实现用例中的脚本。第7章 面向对象分析与设计2022-5-24 54结束返回7.2.2 7.2.2 详细设计详细设计 设计类设计类 解域。它是技术构架中的实用类库和诸如Time、Date、String、Collection等可复用组件的领域。诸如通信、数据库的中间件，以及诸如DCOM、CORBA、EJB组件框架也在解域中。这个解域也包括GUI框架，如Java的Swing、MFC等。这个解域提供了使你能够实现系统的技术工具。 对分析类的精化，精化包括添加实现细节。在进行精化时，常常会发现非常高级的分析类需要被分解成两个或多个详细的设计类。分析类与那

41、些描述它们实现的一个或多个设计类之间存在跟踪关系。 第7章 面向对象分析与设计2022-5-24 55结束返回7.2.2 7.2.2 详细设计详细设计 设计类剖析设计类剖析 在分析中，尽量捕获系统需要的行为，而完全不必考虑如何实现这些行为。在设计中，你就必须准确地说明类是如何完成它们的职责的。为此，必须完成以下任务： 得到类完整的属性集合，包括详细说明的名称、类型、可见性和一些默认值(可选)。 将得到的操作转化成一个或多个方法的完整集合。第7章 面向对象分析与设计2022-5-24 56结束返回7.2.2 7.2.2 详细设计详细设计

42、 设计类剖设计类剖析析 信息存储在属性当中。在设计中，属性的细节需要进行全面的描述。最终，属性必须用某种计算机语言来实现，属性的全部细节都会被完整的实现。UML可以对属性进行详细的定义，而不是仅仅对它进行命名。在UML中，一个完整的属性定义语法如下：visibility visibility NameMultiplicityNameMultiplicity: : Type_expressionType_expression = = Initial_valueInitial_value 属性属性第7章 面向对象分析与设计2022-5-24 57结束返回7.2.2 7.2.2 详细设计详细设计7.

43、2.2.2 设计类剖设计类剖析析可见性助记词含义+ +Public对能引用该属性所属对象的其它对象可见或可被修改。- -Private其它对象不能看见或修改属性,不可以被继承。# #Protected 其他对象不能看见或修改属性，可以被继承。表7.1 属性的可见性 属性属性visibility( (可见性) )决定谁可以访问该属性。一般有三种可见性，它的含意如表7.1所示。第7章 面向对象分析与设计2022-5-24 58结束返回7.2.2 详细设计详细设计 设计类剖设计类剖析析 操作操作 操作是在一个对象中操作完成处理功能。实际上，在一个完全面向

44、对象的系统中，所有的处理都是在操作内部执行的。 操作可以操纵对象的属性和调用其他对象的操作，如果可见性允许，操作也可以操纵其他对象的属性。 在分析过程中，我们在顺序图和协作图中考虑的对象之间的交互是通过操作实现的。第7章 面向对象分析与设计2022-5-24 59结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联 系统分析中，已经考虑过分析类之间的关联。当设计时，要将分析类之间的关联精化成设计类之间的关联。 分析中捕获的许多关系不能像显示的那样直接地实现，但是又必须能够实现。 例如，双向关联，几乎没有一种OO语言支持它。再如关联类、多对多关联等。第

45、7章 面向对象分析与设计2022-5-24 60结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联 所有的设计关联必须具有以下的特性： 导航性：它表明可从源类的任何对象到目标类的一个多个对象(根据多重性确定)遍历。 在UML中，导航性由关联带箭头来表示(默认为双向可导航)，表从不可导航。可以这样理解：消息仅能在箭头的方向上传递。例如图7.27中，对象Order(订货单)能够向对象Product（产品）发送消息，但消息不能反向发送。图7.27 导航性 最小化类之间的耦合，是面向对象的良好设计。使用导航性是一种好的做法。通过使得Order和Produc

46、t间单向关联，简单地从对象Order到Product对象导航，但不能从相反的方向导航。对象Product不知道它们参与了特定的Order，因此没有到Order的耦合。第7章 面向对象分析与设计2022-5-24 61结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联 两端的多重性：显示对象之间关联的个数。它往往反映了业务规则，在设计中必须确定。将分析关联精化成设计关联包括以下内容： 在恰当的地方将关联精化成聚合或组合关系。 实现关联类。 实现一对多关联。 实现多对多关联。 实现双向关联。第7章 面向对象分析与设计2022-5-24 62结束返回7.

47、2.2 详细设计详细设计 设计关联设计关联 聚合是整体与部分关系的一种，其中聚合由许多部分组成。 在整体与部分关系中，一个对象(整体)使用另一个对象(部分)的服务。因此，在关系中整体趋向于支配和控制关系的一端，反之，部分趋向于为整体的请求提供服务，因而更加被动。 聚合与组合聚合与组合第7章 面向对象分析与设计2022-5-24 63结束返回7.2.2 详细设计详细设计 设计关联设计关联PrinterComputer0.*0.10.*0.1图7.28 聚合 聚合与组合聚合与组合 事实上，如果只有从整体到部分的导航性，那么部分甚至不知道自

48、己是整体的一个部分。这是一种松散的对象之间的关系，如图7.28所示的计算机与打印机的关系。在此关系中，我们看到： 一台Coumputer可能连接到零台或多台Printers. 任何时候一台Printer连接到零台或是一台Computer。 许多台Coumputers 可以使用一台给定的Printer. 即使没有所连接的Computers，那台Printer也可以存在。 在客观意义上，这台Printer是独立于这台Computer的。第7章 面向对象分析与设计2022-5-24 64结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联 聚合与组合聚合与

49、组合由此例看出，聚合语义如下： 聚合能够不依赖于部分而存在。 部分可以独立于聚合而存在。 如果有一些部分遗失，聚合会给人不完整的感觉。 部分的所有权可以由几个聚合来共享。第7章 面向对象分析与设计2022-5-24 65结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联 聚合与组合聚合与组合 组合是一种更强形式聚合，也具有类似的语义。它也是整体与部分关系中的一种，二者的关键区别在于，在组合中的部分脱离了整体就不能存在。此外，组合中每个部分属于一个整体，也只能属于一个整体，而在聚合中一个部分可以由几个整体共享。例如鼠标和它的按钮之间的关系以及人和他的

50、手的关系。 组合的语义是：部分在某一时刻仅仅只能属于一个整体；整体惟一地负责处理它的所有部分；倘若对于部分的职责由其他对象来承担的话，组成也就可以放松这些职责；如果一个整体销毁的话，它必须将它所有的部分销毁，或者把负责处理它们的权利交给其他的一些对象。第7章 面向对象分析与设计2022-5-24 66结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联 在设计中，在任何时候要将关联精化成聚合或组合关系。而且，分析关联往往以聚合或组合结束。在确定使用聚合或者组合之后，应当按照下面的步骤进行精化： 添加多重性和角色名称到关联。 确定关联的哪一端是整体，哪

51、一端是部分。 考虑整体一端的多重性。如果正好是1，那么可能使用组合；否则就必须使用聚合。 添加从整体到部分的导航性，即设计关联必须是单向的。 如何精化分析关系如何精化分析关系第7章 面向对象分析与设计2022-5-24 67结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联图7.29 多对一关联 一对一关联一对一关联 一对一关联意味着两个类之间的一种非常强的关系，在不违背设计原则下，可以将二者合并成一个类。假如它们不能合并，可以把它们设计成组合关系，或者一个类进一步精化成另一个类的属性。 多对一关联多对一关联 多对一关联发生在整体一端的多重性大于1

52、，而部分一端的多重性恰好是1的情况。显然，这时部分被许多整体共享，要使用聚合。如图7.29所示。第7章 面向对象分析与设计2022-5-24 68结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联 在一对多关联中，在关系的部分一端多重性大于1。为了实现这一关系我们要使用实现语言提供的集合实用类。这时整体一端是组合关系，部分一端要有一个对象汇集。 目前，一些流行的面向对象语言，如C#、Java都提供了泛型的集合支持，可以直接提供使用。 一对多关联一对多关联第7章 面向对象分析与设计2022-5-24 69结束返回7.2.2 7.2.2 详细设计详细设

53、计 设计关联设计关联 普遍使用的OO语言当中没有一种能直接地支持多对多关联，它们是纯分析关系。因此，它们必须具体化成正常的类、聚合、组合或者依赖。 在分析中，可能对所有权和导航性非常模糊，但是在设计中必须进行详细地说明。所以，必须确定多对多关联的哪一端是整体，然后再使用恰当的聚合或者组合。 多对多关联多对多关联第7章 面向对象分析与设计2022-5-24 70结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联 当我们确定一端是整体后，往往引入一个新的对象来实现多对多关联，这个新的对象往往是集合对象。 借助于集合对象，分

54、别建模为1对多和多对一关联，从而即可实现多对多关联，如图7.30。 该例中，以Resource对策为中心，借助于Allocation分配对象，实现多对多关联。图7.30 多对多关联实现多对多关联第7章 面向对象分析与设计2022-5-24 71结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联 双向关联双向关联 实际中，经常遇到这种情况，类A的对象a使用了类B对象b的服务，并且对象B需要回调和使用对象a的服务。 这种情况在GUI编程中经常使用，如拥有多个Button对象的GUI窗口控件，每个Button对象需要窗口对象提供的服务。对于这种情况，把它

55、转化成两个单向关联或依赖。图7.31给出双向关联设计的例子。第7章 面向对象分析与设计2022-5-24 72结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联图7.31 双向关联设计 双向关联双向关联 当整体把指向它自身的引用作为参数传递给部分的方法之一，或者组成部分在它方法中实例化整体时，要使用依赖关系代替关联。第7章 面向对象分析与设计2022-5-24 73结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联 关联类是纯分析结果，在当前使用OO语言中不能直接实现。因此必须在设计模型中去掉。我们应当

56、将关联类具体化成正常的类，联合使用聚合、组合或者依赖来捕获关联类的语义。 如图7.32所示，Company（公司）和Person （雇员）多对多关联之间有一个关联类Job（工作）来记录薪水。PersonCompany*Jobsalary图7.32 关联类 关联类关联类第7章 面向对象分析与设计2022-5-24 74结束返回7.2.2 7.2.2 详细设计详细设计 设计关联设计关联 图7.32转化成设计模型如图7.33所示。此图中，已经失去了关联类的语义。Job类的每一端形成惟一配对。一个Job对象对应一个Company对象和一个Person对象。CompanyP

57、ersonJobsalary*1*11*1*图7.33 设计关联类需要注意的是，关联类是在多对多关联的前提下才会出现。它解决的方法如多对多关联。 关联类关联类第7章 面向对象分析与设计2022-5-24 75结束返回再见！第7章 面向对象分析与设计2022-5-24 76结束返回7.2.2 7.2.2 详细设计详细设计 顺序图顺序图 系统分析阶段我们使用顺序图，作为一种展开用例和详细描述用例操作的方法。在系统分析中，已经产生了一个很好的关于系统外部行为的描述，以及一些对象。实体对象边界对象控制对象系统分析相应于现实世界实体的候选对象与现实世界进行接口的边界对象对实

58、体对象之间进行交互控制的控制对象系统分析夹断产生的对象示意图第7章 面向对象分析与设计2022-5-24 77结束返回7.2.2 7.2.2 详细设计详细设计 顺序图顺序图 系统设计阶段要进一步讨论顺序图，作为系统设计的开始点。需要做两件事件。 首先，必须考虑对象本身。它们是可实施的吗？它们是否需要在那些方面更改结构？ 其次，顺序图之间的交互需要操作的支持。需要定义这些操作以及它们交换的信息。第7章 面向对象分析与设计2022-5-24 78结束返回7.2.2 7.2.2 详细设计详细设计 顺序图顺序图 一个设计模式就是一个设计的布局

59、。模式的使用已经成为软件工程中广泛争议的话题。这里介绍一些对系统组织非常有用的模式。 如果通过边界对象、控制对象和实体对象来看用例扩充的过程，会看到一个交互系统的通用模式，如图7.32所示。 一些交互系统的设计模式一些交互系统的设计模式第7章 面向对象分析与设计2022-5-24 79结束返回7.2.2 7.2.2 详细设计详细设计 顺序图顺序图图7.32 交互系统的标准设计模式 这是一个在交互式系统中被再三重复的模式。用户和边界对象打交道，边界对象通常是屏幕。 实际上，交互可能包含相当多的信息交换，如，用户完成一个表单的时候。边界对象会请求某些控制对象去执行工作

60、，如，当用户按下提交键时，控制对象将工作委托给一些实体对象。第7章 面向对象分析与设计2022-5-24 80结束返回7.2.2 7.2.2 详细设计详细设计 顺序图顺序图 相应于前面介绍的三层构架。表示层处理所有交互的细节，中间层处理业务逻辑，底层存储持久信息。需要强调的是，实体对象如何保持持久的。通常可以把此功能放在C2控制对象中，也可以由实体对象自己来处理，后者更加符合面向对象设计原则。这个问题的解决方案如后面的设计模式。 图7.33 简单设计模式 在逻辑不是特别复杂的实例中，可以使用一个简单的模式，如图7.33所示。 用于构建小应用的许多简单工具都使用这种