第7章面向对象系统设计

第7章面向对象系统设计

第7章面向对象系统设计7.1系统体系结构设计

7.2子系统耦合度与聚合度7.3子系统与功能模块设计

7.4系统数据管理设计

7.5系统界面设计7.1系统体系结构设计

7.1.1系统逻辑体系结构设计7.1.2系统物理体系结构设计7.1.1系统逻辑体系结构设计1．设计原则面向对象系统设计的第一步就是确定系统逻辑体系结构，它决定了各子系统如何组织以及如何协调工作。在面向对象系统设计过程中，利用系统分层技术将整个系统进行分层，每个层完成自身的功能，最后，所有的层整合起来构成一个完整的系统逻辑体系结构。

2.逻辑体系结构建模：包图设计

在UML中，一般采用包图对系统逻辑体系结构进行建模，一个包相当于一个子系统，一个包也可以向下划分为更小的包。根据设计原则和信息系统原理，将信息系统中比较关心的对象分层.用户界面层、业务处理层、数据访问层各层中的一些公共部分提出来：权限管理、异常处理。包图设计用户界面业务处理数据访问权限管理错误处理图7.2系统逻辑体系结构建模：包图1）用户界面包如图7.3(a)所示，用户界面层的职责是：(1)与用户的交互，接收用户的各种输入以及输出各种提示信息或处理结果。(2)对于输入的数据进行数据校验，过滤非法数据。(3)向业务处理对象发送处理请求。用户界面包含的类如图7.3(b)所示。用户界面输入、输出数据校验发送业务处理请求图7.3（a）用户界面包用户界面类输入输出元素业务处理对象数据校验（）业务处理（）输入界面输出界面图7.3（b）用户界面包含的类2）业务处理包如图7.4（a）所示，业务处理层的职责是：（1）实现各种业务处理逻辑或处理算法；（2）验证请求者的权限；（3）向数据访问对象发送数据持久化操作的请求；（4）向用户界面层返回处理结果。业务处理包含的类如图7.4(b)所示。业务处理实现各种业务逻辑实现各种处理算法权限管理图7.4(a)业务处理包业务处理类权限管理对象业务对象业务处理（）图7.4（b）业务处理包含的类业务类数据库连接对象数据库访问对象业务处理（）3）数据访问包如图7.5(a)所示，数据访问层的职责是：（1）实现数据的持久化操作；（2）实现事务处理。数据访问包含的类如图7.5(b)所示。

数据访问实现数据的持久化操作实现事务处理图7.5（a）数据访问包数据库访问类数据库连接对象读取（）写入（）图7.5（b）数据访问包含的类业务数据库连接类开始事务（）提交事务（）回滚事务（）Instance（）4)权限管理包如图7.6（a）所示，权限管理的主要职责是：（1）验证请求者的请求权限；（2）提供请求者的权限列表。权限管理包含的类如图7.6(b)所示。权限管理验证请求者的请求权限提供请求者的权限列表图7.6（a）数据访问包权限管理类操作员对象验证权限（）获取权限列表（）操作员类操作员代码操作员名称角色对象表权限列表登陆（）退出（）是否构建权限表（）构建权限列表（）角色类角色名构建权限列表图7.6（b）权限访问包含的类5)异常处理包如图7.7（a）所示，异常处理的主要是：（1）汇报运行时的详细异常信息；（2）记录异常处理日志。异常处理汇报运行时的详细异常信息记录异常处理日志图7.7（a）异常处理包异常处理包含的类如图7.7(b)所示异常处理类异常处理实现对象异常处理实现类异常处理实现类系统异常数据库异常业务逻辑异常系统异常实现数据库异常实现业务逻辑异常实现图7.7（b）异常处理包含的类包图设计举例

在图书管理系统逻辑体系设计中，其系统包图如图7.8所示，一共有3个包：“图书业务处理”包、“用户界面”包和“数据库”包。在“图书业务处理”包中包含了实现图书馆管理的所有类；在“用户界面”包中包含了该系统的全部界面类；在“数据库”包中包含了与实现数据库服务有关的全部类。用户界面图书业务处理数据库图7.8图书管理系统包图7.1.2系统物理体系结构设计系统物理体系结构设计，不仅包括:(1)不同的节点和这些节点之间的连接方式(2)表示了逻辑体系结构和物理结构的依赖关系。在UML中，一般采用构件图和部署图来对系统物理体系结构进行建模。构件图和部署图可以描述出系统中的类和对象涉及的具体程序或进程，并表明程序或进程使用的硬件设备及它们之间的相互连接。1.系统构件图构件是程序代码的实际物理模块，系统的构件图用来显示代码模块间的关系。在图书管理系统物理体系设计中，其系统构件图如图7.9所示。系统包含3个类包，即界面包、图书业务包和数据库包，以及1个图书管理系统包。

图书管理系统exe界面包图书业务包数据库图7.9图书管理系统构件图在图7.9所示图书管理系统构件图中，图书业务包包含5个构件部分，如图7.10所示。

人文书刊.java

借阅记录.java

借阅者信息.java

技术书刊.java

预定记录.java图7.10图书业务构件图2.系统部署图部署图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件。在图书管理系统物理体系设计中，图书管理系统的各个部分可以部署在不同的节点上，通过网络相互通信。图书管理系统是一个客户机/服务器结构的分布式系统，它的数据库放置在图书馆的数据库服务器上，图书馆服务器向用户提供了借书管理服务和信息管理服务，借阅者和图书管理员可以通过客户端借阅、预定、返还书籍并进行各种信息的维护。基于此，绘制图书管理系统部署图如图7.11所示。客户端图书馆服务器数据库服务器图7.11图书管理系统部署图7.2子系统耦合度与聚合度

1.子系统之间耦合度耦合度描述了两个子系统之间依赖关系的程度。耦合度越低，表明两个子系统之间的依赖关系越松散，它们之间相互独立性越强，那么当其中一个子系统发生变化时对另外一个子系统产生的影响很小。耦合度越高，表明两个子系统之间的依赖关系越紧密，那么当其中一个子系统发生变化时可能对另外一个子系统产生很大影响。2.子系统内部聚合度聚合度描述了子系统内部的依赖程度。如果某个子系统含有多个彼此相关的对象，并且它们执行类似的任务，它们的相关性就比较高，那么子系统内部聚合度就高。聚合度越高，子系统独立性越强，反之亦然。要坚持低耦合、高聚合的原则，从而保证子系统与功能模块的独立性。通常在聚合度和耦合度之间存在一个平衡，将系统不断分解成子系统可以提高系统的聚合度，但是，随着子系统之间接口数量的增加，也会提高耦合度。7.3子系统与功能模块设计在系统设计的过程中，系统设计人员将系统分解成能由单个团队实现的较小的子系统，又称为功能模块，这些子系统的设计要遵循“低耦合、高聚合、强独立”的原则，主要的设计活动包括服务与子系统接口设计、分层与分区等。7.3.1子系统分解与功能模块学籍管理系统6个子系统，即用户管理子系统、学生档案管理子系统、班级管理子系统、交费管理子系统、课程管理子系统和成绩管理子系统。交费管理子系统可以细分为如图7.12所示的包图。设置收费类型和收费标准:frmTuitionSet，收取学费、学费类型明细及查询、学生个人收费情况、学生收费明细、学生收费查询分别设计为frmTuitionCollect，frmTuitionSetBrow，frmTuitionStu，frmTuitionDetail，frmTuitionSetQry。＜＜MDIForm＞＞frmMain(from登陆及主控程序包)＜＜Form＞＞frmTuitionSet＜＜Form＞＞frmTuitionCollect＜＜Form＞＞frmTuitionDetail＜＜Form＞＞frmTuitionStu＜＜Form＞＞frmTuitionSetQry＜＜Form＞＞frmTuitionSetBrow交费管理包＜＜DataReport＞＞DataReportTuitionDetail(from报表包)学费Info(from系统实体类包)＜＜DataReport＞＞DataReportTuition(from报表包)图7.12学籍管理交费管理子系统分解

学费信息实体类分解

从图7.12可以看出，学籍管理交费子系统表示为UML包，该子系统的分解包括包的组成和其与主界面的构成关系，子系统虚线箭头说明子系统与其他子系统或类之间的依赖关系。其中，学费信息实体类可以进一步划分为学费类型和交费明细两部分，相当于数据库中的两个表，如图7.13所示。学费Info(from系统实体类包)学费类型（fromdbo）年级：STRING专业：STRING年制：STRING学期：STRING学费：MONEY交费明细（fromdbo）学号：STRING学期：STRING交费：MONEY日期：DATETIME操作员：STRING图7.13学费信息实体类分解7.3.2服务与子系统接口设计服务指的是一组有着共同目标的相关操作，就是通过为其他子系统提供服务来确定其特点的，从而形成子系统与子系统之间的接口，称为子系统接口。子系统接口也称为应用程序接口（ApplicationProgrammingInterface，API），包括操作的名称、参数、类型和返回值。子系统提供的服务在系统设计集中进行定义，包括列举操作、参数和它们的高层行为；子系统接口设计在对象集中进行定义，包括参数的类型和每个操作的返回值，也包括应用软件调用操作系统的函数接口。在学籍管理系统的服务与子系统接口设计中，系统公用模块就是为所有子系统提供服务的一个子系统，它主要提供访问数据层的接口，定义公用访问数据库的连接，定义全局性的变量和方法供各子系统使用，如图7.14所示。班级管理包（fromUseCaseView）课程管理包（fromUseCaseView）＜＜Module＞＞ModuleExecuteSQL()ConnString()ExecuteCheck()成绩管理包（fromUseCaseView）学生档案管理包（fromUseCaseView）交费管理包（fromUseCaseView）用户管理包（fromUseCaseView）图7.14学籍管理系统的服务与子系统接口设计

7.3.3子系统分解与确定

1.子系统分解子系统分解指得是利用分层与分区的方法，将系统循环地分解成可管理的较小的、简单的部分，直到能让一个人或者一个小组处理为止。系统地使用这个方法就可以得到结构化的分解，其中每个子系统或者每一层可以根据低层子系统提供的服务为其高层服务，每一层还可以访问其下一层。在面向对象的系统设计过程中，系统的分解可以分为3个层次：（1）顶层的登录管理和主控界面；（2）中间层为各业务处理子系统；（3）底层为实体类层和报表层。就学籍管理系统而言，其系统分解分为3个层次，如图7.15所示，顶层是登录及主控程序包；中间层是6个业务处理包，即用户管理包、学生档案管理包、班级管理包、交费管理包、课程管理包和成绩管理包；底层是系统实体类包和报表包。用户管理包学生档案管理包班级管理包交费管理包课程管理包登陆及主控程序包系统实体类包报表包成绩管理包顶层中间层底层图7.15学籍管理系统的分层设计2.子系统确定

最初的子系统分解来自功能性需求,随着这种需求的不断变化，子系统的分解也随之不断修改和完善：若干简单的子系统合并到一个子系统中，复杂的子系统分解成多个部分，为了实现新的功能而增加子系统等。确定子系统的方法就是将功能相关的对象放在一起，作为独立的功能或共享的模块，被多个子系统所共享；或者把复杂的子系统分解为较为简单的子系统。确定子系统的方法可归纳为以下几个方面：（1）将一个用例中确定的对象分配到同一个子系统中；（2）为两个以上子系统传递数据或提供服务的对象创建一个专用的子系统；（3）将子系统与子系统之间的关联关系降到最小；（4）同一个子系统内的所有对象必须功能相关，业务处理配合紧密。7.4系统数据管理设计

7.4.1数据模型数据模型是严格定义的一组概念的集合，这些概念精确地描述了系统的静态、动态特性和完整性约束条件。1．数据模型的组成要素

数据模型通常由数据结构、数据操作和完整性约束三部分组成，这三部分称为数据模型的三要素。1）数据结构是对系统静态特性的描述，它分为层状结构、网状结构和关系结构。数据结构是刻画数据模型性质最重要的方面，因此数据库系统中通常按照数据结构类型来命名数据模型，如层次模型、网状模型和关系模型。2）数据操作是对系统动态特性的描述，它主要包括对数据库的两大类操作：即检索和更新。检索是指对数据的筛选、统计和读取等操作；更新是指对数据的插入、删除和修改操作。3）数据的完整性约束条件是一组完整性规则的集合。完整性规则是给定数据模型中数据及其联系所具有的制约和依存规则，这些规则的作用是保证数据的正确、有效和相容性。比如，本科生年龄不大于30岁，研究生年龄不大于38岁，学生累计成绩不得有三门以上不及格，属于数据的完整性约束条件。2.常用的数据模型

数据库领域最常用的数据模型有四种：层次模型（HierarchicalModel）网状模型（NetworkModel）关系模型（RelationalModel）面向对象模型（ObjectOrientedModel）7.4.2关系数据模型1.关系表在用户看来，关系模型中数据结构就是一张二维表，如表7.1和表7.2所示。学号姓名性别年龄系号年级980104王小明女190198980206黄大鹏男200298980508张文斌女180598………………系号系名办公室主任电话01计算机教209张立558502102物理教501李可2334102……………05地质工程教301陈鹏5585206表7.1学生登记表

表7.2系信息表

2.关系数据模型中的一些术语1）关系（Relation）：一个关系对应通常所说的一张二维表；2）元组（Tuple）：表中的一行即为一个元组；3）属性（Attribute）：表中的一列即为一个属性，给每一个属性起一个名称即属性名。表7.1中有六列，对应六个属性（学号，姓名，性别，年龄，系号和年级）；4）域（Domain）：属性的取值范围，所以又称“值域”；5）分量：元组中的一个属性值；6）关系模式：对关系的描述，一般表示为：关系名（属性1，属性2，…，属性n）；7）关键字或码（Key）：表中用来唯一确定（标识）一个元组的某个属性或属性组合。如表中学号；关键字必须唯一，但它的唯一性不是只对关系的当前元组构成来确定的。还要考虑元组构成的将来可能性。3.关系数据模型的操纵

1）操作：查询、插入、删除、修改。前一种为检索，后三种为更新，2）关系数据操作的理论标准为关系代数或关系演算。其中，关系演算又分为元组关系演算和域关系演算两种。关系代数、元组关系演算和域关系演算三种抽象语言在表达能力上是完全等价的。3）介于关系代数和关系演算之间的实用的代表性的关系操纵语言是SQL（StructuredQueryLanguage）。4.数据的完整性约束条件包括：实体完整性、参照完整性、用户定义的完整性。1）实体完整性（EntityIntegrity）。若属性A是基本关系R的一个主属性，则任何元组在A上的分量都不能为空。实体完整性规定主码的任何属性都不能为空。这是因为：2）参照完整性（ReferentialIntegrity）。参照完整性是对关系间引用数据的一种限制。若属性组A是基本关系R1的外码，它与基本关系R2主码K相对应，则R1中每个元组在A上的值必须为以下两种情况之一.3）用户定义的完整性。实体完整性和参照完整性是关系模型必须满足的两个完整性约束条件，任何关系系统都必须自动维护之。5.关系数据模型的规范化

符合某一种级别的关系模式的集合称为范式。关系数据模型规范化的基本思想就是：逐步消除不合理的数据依赖，使范式中的各个关系模式达到某种程度的“分离”，这种规范化遵循如下三种范式：（1）第一范式：每个分量必须是不可分的数据项；（2）第二范式：每个非主属性完全依赖于主属性；（3）第三范式：任何一个非关键字数据项都不传递依赖于它的关键字。其中，第一范式到第二范式消除了非主属性对候选键的局部依赖；第二范式到第三范式消除了非主属性对候选键的传递依赖。7.4.3从UML映射到关系数据模型1．映射原则（1）基础类可以采用一类一表制或一类多表制的映射原则；（2）当类之间有一对多关系时，一个表也可以对应多个类；（3）存在继承关系的类可以映射为一个表，用属性来区别不同的子类，也可以是不同的子类分别映射一个表；（4）类属性映射为表字段，类之间的关联也用表字段来表示；（5）按关系数据模型规范化原则来调整表结构。2.映射实体类实体类到关系表的映射必须符合列是不可再分的。不过，在UML分析模型中的类属性（对立于类关系）已经是符合这个条件，这一点简化了这个映射。对于每个实体类来说，可以映射成一个表，类中的属性和表中的属性相同。在图书管理系统中，借阅者实体类映射实例如图7.16所示。Loan(userID,bookID,borrowdata,returndata,state)图7.16图书管理系统借阅者实体类映射3.映射关联

1）一对多关系。在一对多关联中，一个对象可以与多个对象相链接。一种方法是将关系的“1”端对象的关键字附加到“多”端的一个列（或多列）。另一种方法是用一个独立表来存储一对多关系，在图书管理系统中，一对多的映射实例如图7.17所示。Item(bookID,bookno,state…)图7.17图书管理系统中一对多的映射实例2）多对多关系。对于多对多关系，需要增加一个表，这个表由具有链接关系的表的关键字组成，在图书管理系统中，多对多的映射实例如图7.18所示。Reservation(userID,bookno,date…)图7.18图书管理系统中多对多的映射实例3）一对一关系。零或一对一关联，把“l”端的主键添加到“0或l”表。其他一对一关联，可以把一个对象的主键添加到另一个对象中，在图书管理系统中，多对多的映射实例如图7.19所示。Fine(userID,bookID,date,…)图7.19图书管理系统中一对一的映射实例4.映射聚集和组合对于一对一的组合，可以将子类与超类建立成一个表；对于一对多的情况，无论聚集还是组合，对子类必须建立一个独立的表，将父类主键属性加入子类的表中。例如，Office类和OfficeMember类之间存在着聚集关系，将该关系映射到关系数据库中，这种聚集的映射实例如图7.20所示。Office(officeID,…)OfficeMember(OfficeMemberID,officeID,…)图7.20聚集的映射实例5.映射泛化

泛化的映射策略有三种：（1）父类与子类可各自映射成表，将父类的主键属性加入子类中，建立外键关联。在关系数据模型中用外键参照关系来表示继承关系。（2）将子类表的属性添加到父类表的属性中，而不建立子类表。通过这种方式，可以使关系数据模型支持继承关系和多态。（3）不建立父类表，而只建立子类表。将子类继承的父类的属性加入子类中。在图书馆管理系统中，对于Book类来说，选择第二种方案，在Book表中添加书的类别属性，泛化的映射实例如图7.21所示。Book(bookID,…,t