面向对象系统设计.ppt

1、5.2 面向对象系统设计面向对象系统设计 5.2 面向对象系统设计面向对象系统设计n5.2.1 系统体系结构设计系统体系结构设计 n5.2.2 子系统耦合度与聚合度子系统耦合度与聚合度n5.2.3 子系统与功能模块设计子系统与功能模块设计 n5.2.4 系统数据管理设计系统数据管理设计 n5.2.5系统界面设计系统界面设计5.2.1 系统体系结构设计系统体系结构设计 n5.2.1.1 系统逻辑体系结构设计 n5.2.1.2 系统物理体系结构设计 5.2.1.1 系统逻辑体系结构设计1设计原则设计原则n面向对象系统设计的第一步就是确定系统逻辑体系结构，它决定了各子系统如何组织以及如何协调工作。在

2、面向对象系统设计过程中，利用系统分层技术将整个系统进行分层，每个层完成自身的功能，最后，所有的层整合起来构成一个完整的系统逻辑体系结构。2.逻辑体系结构建模：包图设计逻辑体系结构建模：包图设计n在 UML中，一般采用包图对系统逻辑体系结构进行建模，一个包相当于一个子系统，一个包也可以向下划分为更小的包。根据设计原则和信息系统原理，将信息系统中比较关心的对象分层.n用户界面层、业务处理层、数据访问层n各层中的一些公共部分提出来：权限管理、异常处理。包图设计包图设计用户界面业务处理数据访问权限管理错误处理图图5.2.25.2.2 系系统统逻逻辑辑体体系系结结构建模：包图构建模：包图1）用户界面包如

3、图5.2.3(a)所示，用户界面层的职责是：n(1)与用户的交互，接收用户的各种输入以及输出各种提示信息或处理结果。n(2)对于输入的数据进行数据校验，过滤非法数据。n(3)向业务处理对象发送处理请求。用户界面包含的类如图5.2.3(b)所示。用户界面输入、输出数据校验发送业务处理请求图图5.2.35.2.3（a a）用用户户界界面包面包用户界面类输入输出元素业务处理对象数据校验（）业务处理（）输入界面输出界面图图5.2.35.2.3（b b）用户界面包含的类用户界面包含的类2）业务处理包如图5.2.4（a）所示，业务处理层的职责是：n（1）实现各种业务处理逻辑或处理算法；n（2）验证请求者的

4、权限；n（3）向数据访问对象发送数据持久化操作的请求；n（4）向用户界面层返回处理结果。业务处理包含的类如图5.2.4(b)所示。业务处理实现各种业务逻辑实现各种处理算法权限管理图图5.2.4(a5.2.4(a)业务处理包业务处理包业务处理类权限管理对象业务对象业务处理（）图图5.2.45.2.4（b b）业业务务处处理理包包含含的的类类业务类数据库连接对象数据库访问对象业务处理（）3）数据访问包如图5.2.5(a)所示，数据访问层的职责是：n（1）实现数据的持久化操作；n（2）实现事务处理。数据访问包含的类如图5.2.5(b)所示。数据访问实现数据的持久化操作实现事务处理图图5.2.55.2

5、5（a a）数数据据访访问包问包数据库访问类数据库连接对象读取（）写入（）图图5.2.55.2.5（b b）数数据据访访问问包包含含的的类类业务数据库连接类开始事务（）提交事务（）回滚事务（）Instance（）4)权限管理包如图7.6（a）所示，权限管理的主要职责是：n（1）验证请求者的请求权限；n（2）提供请求者的权限列表。权限管理包含的类如图7.6(b)所示。权限管理验证请求者的请求权限提供请求者的权限列表图图7.67.6（a a）数数据据访访问问包包权限管理类操作员对象验证权限（）获取权限列表（）操作员类操作员代码操作员名称角色对象表权限列表登陆（）退出（）是否构建权限表（）构建权限

6、列表（）角色类角色名构建权限列表图图7.67.6（b b）权限访问包含的类权限访问包含的类5)异常处理包如图7.7（a）所示，异常处理的主要是：n（1）汇报运行时的详细异常信息；n（2）记录异常处理日志。异常处理汇报运行时的详细异常信息记录异常处理日志图图7.77.7（a a）异常处理包异常处理包异常处理包含的类如图7.7(b)所示异常处理类异常处理实现对象异常处理实现类异常处理实现类系统异常数据库异常业务逻辑异常系统异常实现数据库异常实现业务逻辑异常实现图图7.77.7（b b）异异常常处处理理包包含含的类的类包图设计举例n 在图书管理系统逻辑体系设计中，其系统包图如图7.8所示，一共有3个

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

8、备及它们之间的相互连接。1.系统构件图系统构件图n构件是程序代码的实际物理模块，系统的构件图用来显示代码模块间的关系。n在图书管理系统物理体系设计中，其系统构件图如图7.9所示。系统包含3个类包，即界面包、图书业务包和数据库包，以及1个图书管理系统包。图书管理系统exe界面包图书业务包数据库图图7.97.9图书管理系统构件图图书管理系统构件图 在图7.9所示图书管理系统构件图中，图书业务包包含5个构件部分，如图5.2.10所示。人文书刊.java 借阅记录.java 借 阅 者 信 息.java 技术书刊.java 预定记录.java图图5.2.105.2.10 图图书书业业务务构构件件图图2

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

10、1.子系统之间耦合度子系统之间耦合度 耦合度描述了两个子系统之间依赖关系的程度。耦合度越低，表明两个子系统之间的依赖关系越松散，它们之间相互独立性越强，那么当其中一个子系统发生变化时对另外一个子系统产生的影响很小。耦合度越高，表明两个子系统之间的依赖关系越紧密，那么当其中一个子系统发生变化时可能对另外一个子系统产生很大影响。n2.子系统内部聚合度子系统内部聚合度n聚合度描述了子系统内部的依赖程度。如果某个子系统含有多个彼此相关的对象，并且它们执行类似的任务，它们的相关性就比较高，那么子系统内部聚合度就高。聚合度越高，子系统独立性越强，反之亦然。n要坚持低耦合、高聚合的原则，从而保证子系统与功能

11、模块的独立性。n通常在聚合度和耦合度之间存在一个平衡，将系统不断分解成子系统可以提高系统的聚合度，但是，随着子系统之间接口数量的增加，也会提高耦合度。5.2.3 子系统与功能模块设计子系统与功能模块设计n在系统设计的过程中，系统设计人员将系统分解成能由单个团队实现的较小的子系统，又称为功能模块，这些子系统的设计要遵循“低耦合、高聚合、强独立”的原则，主要的设计活动包括服务与子系统接口设计、分层与分区等。5.2.3.1 子系统分解与功能模块 学籍管理系统6个子系统，即用户管理子系统、学生档案管理子系统、班级管理子系统、交费管理子系统、课程管理子系统和成绩管理子系统。交费管理子系统可以细分为如图5

12、2.12所示的包图。设置收费类型和收费标准:frmTuitionSet，收取学费、学费类型明细及查询、学生个人收费情况、学生收费明细、学生收费查询分别设计为frmTuitionCollect，frmTuitionSetBrow，frmTuitionStu，frmTuitionDetail，frmTuitionSetQry。MDI FormfrmMain(from 登陆及主控程序包)FormfrmTuitionSetFormfrmTuitionCollectFormfrmTuitionDetailFormfrmTuitionStuFormfrmTuitionSetQryFormfrmTuiti

13、onSetBrow交费管理包DataReportDataReportTuitionDetail(from报表包)学费Info(from系统实体类包)DataReportDataReportTuition(from报表包)图图5.2.12 学籍管理交费管理子系统分解学籍管理交费管理子系统分解 学费信息实体类分解学费信息实体类分解 n从图5.2.12可以看出，学籍管理交费子系统表示为UML包，该子系统的分解包括包的组成和其与主界面的构成关系，子系统虚线箭头说明子系统与其他子系统或类之间的依赖关系。其中，学费信息实体类可以进一步划分为学费类型和交费明细两部分，相当于数据库中的两个表，如图5.2.13

14、所示。学费Info(from系统实体类包)学费类型（from dbo）年级：STRING专业：STRING年制：STRING学期：STRING学费：MONEY交费明细（from dbo）学号：STRING学期：STRING交费：MONEY日期：DATETIME操作员：STRING图图5.2.13 学费信息实体类分解学费信息实体类分解5.2.3.2 服务与子系统接口设计n服务指的是一组有着共同目标的相关操作，就是通过为其他子系统提供服务来确定其特点的，从而形成子系统与子系统之间的接口，称为子系统接口。子系统接口也称为应用程序接口（Application Programming Interface

15、API），包括操作的名称、参数、类型和返回值。n子系统提供的服务在系统设计集中进行定义，包括列举操作、参数和它们的高层行为；n子系统接口设计在对象集中进行定义，包括参数的类型和每个操作的返回值，也包括应用软件调用操作系统的函数接口。在学籍管理系统的服务与子系统接口设计中，系统公用模块就是为所有子系统提供服务的一个子系统，它主要提供访问数据层的接口，定义公用访问数据库的连接，定义全局性的变量和方法供各子系统使用，如图5.2.14所示。班级管理包（from Use Case View）课程管理包（from Use Case View）ModuleModuleExecuteSQL()ConnStr

16、ing()ExecuteCheck()成绩管理包（from Use Case View）学生档案管理包（from Use Case View）交费管理包（from Use Case View）用户管理包（from Use Case View）图图5.2.145.2.14学籍管理系统的服务与子系统接口设计学籍管理系统的服务与子系统接口设计5.2.3.3 子系统分解与确定1.子系统分解子系统分解n子系统分解指得是利用分层与分区的方法，将系统循环地分解成可管理的较小的、简单的部分，直到能让一个人或者一个小组处理为止。系统地使用这个方法就可以得到结构化的分解，其中每个子系统或者每一层可以根据低层子系统

17、提供的服务为其高层服务，每一层还可以访问其下一层。在面向对象的系统设计过程中，系统的分解可以分为3个层次：n（1）顶层的登录管理和主控界面；n（2）中间层为各业务处理子系统；n（3）底层为实体类层和报表层。就学籍管理系统而言，其系统分解分为3个层次，如图5.2.15所示，顶层是登录及主控程序包；中间层是6个业务处理包，即用户管理包、学生档案管理包、班级管理包、交费管理包、课程管理包和成绩管理包；底层是系统实体类包和报表包。用户管理包学生档案管理包班级管理包交费管理包课程管理包登陆及主控程序包系统实体类包报表包成绩管理包顶 层中间层底 层图图5.2.155.2.15 学学籍籍管管理理系系统统的的

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

19、对象必须功能相关，业务处理配合紧密。5.2.4 系统数据管理设计系统数据管理设计 5.2.4.1数据模型n 数据模型是严格定义的一组概念的集合，这些概念精确地描述了系统的静态、动态特性和完整性约束条件。1 数据模型的组成要素数据模型的组成要素n数据模型通常由数据结构、数据操作和完整性约束三部分组成，这三部分称为数据模型的三要素。n1）数据结构是对系统静态特性静态特性的描述，它分为层状结构、网状结构和关系结构。数据结构是刻画数据模型性质最重要的方面，因此数据库系统中通常按照数据结构类型来命名数据模型，如层次模型、网状模型和关系模型。n2）数据操作是对系统动态特性动态特性的描述，它主要包括对数据库

20、的两大类操作：即检索和更新。检索是指对数据的筛选、统计和读取等操作；更新是指对数据的插入、删除和修改操作。n3）数据的完整性约束条件是一组完整性规则的集合。完整性规则是给定数据模型中数据及其联系所具有的制约和依存规则，这些规则的作用是保证数据的正确、有效和相容性。比如，本科生年龄不大于30岁，研究生年龄不大于38岁，学生累计成绩不得有三门以上不及格，属于数据的完整性约束条件。2.常用的数据模型常用的数据模型n数据库领域最常用的数据模型有四种：n层次模型（Hierarchical Model）n网状模型（Network Model）n关系模型（Relational Model）n面向对象模型（O

21、bject Oriented Model）5.2.4.2 关系数据模型1.关系表关系表n在用户看来，关系模型中数据结构就是一张二维表，如表5.2.1和表5.2.2所示。学号姓名性别年龄系号年级980104王小明女190198980206黄大鹏男200298980508张文斌女180598系号系名办公室主任电话01计算机教209张立558502102物理教501李可233410205地质工程教301陈鹏5585206表表5.2.1 学生登记表学生登记表 表表5.2.2 系信息表系信息表 2.关系数据模型中的一些术语关系数据模型中的一些术语n1）关系（Relation）：一个关系对应通常所说的一张

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

23、关系数据模型的操作n1）操作：查询、插入、删除、修改。前一种为检索，后三种为更新，n2）关系数据操作的理论标准为关系代数或关系演算。其中，关系演算又分为元组关系演算和域关系演算两种。关系代数、元组关系演算和域关系演算三种抽象语言在表达能力上是完全等价的。n3）介于关系代数和关系演算之间的实用的代表性的关系操纵语言是SQL（Structured Query Language）。4.数据的完整性约束条件数据的完整性约束条件n包括：实体完整性、参照完整性、用户定义的完整性。n1）实体完整性（Entity Integrity）。若属性A是基本关系R的一个主属性，则任何元组在A上的分量都不能为空。实体完

24、整性规定主码的任何属性都不能为空。n2）参照完整性（Referential Integrity）。参照完整性是对关系间引用数据的一种限制。n3）用户定义的完整性。5.关系数据模型的规范化关系数据模型的规范化 符合某一种级别的关系模式的集合称为范式。关系数据模型规范化的基本思想就是：逐步消除不合理的数据依赖，使范式中的各个关系模式达到某种程度的“分离”，这种规范化遵循如下三种范式：n（1）第一范式：每个分量必须是不可分的数据项；n（2）第二范式：每个非主属性完全依赖于主属性；n（3）第三范式：任何一个非关键字数据项都不传递依赖于它的关键字。其中，第一范式到第二范式消除了非主属性对候选键的局部依赖

25、第二范式到第三范式消除了非主属性对候选键的传递依赖。5.2.4.3 从UML映射到关系数据模型1映射原则映射原则n（1）基础类可以采用一类一表制或一类多表制的映射原则；n（2）当类之间有一对多关系时，一个表也可以对应多个类；n（3）存在继承关系的类可以映射为一个表，用属性来区别不同的子类，也可以是不同的子类分别映射一个表；n（4）类属性映射为表字段，类之间的关联也用表字段来表示；n（5）按关系数据模型规范化原则来调整表结构。2.映射实体类映射实体类n实体类到关系表的映射必须符合列是不可再分的。不过，在UML分析模型中的类属性（对立于类关系）已经是符合这个条件，这一点简化了这个映射。对于每个实

26、体类来说，可以映射成一个表，类中的属性和表中的属性相同。在图书管理系统中，借阅者实体类映射实例如图5.2.16所示。Loan(userID,bookID,borrowdata,returndata,state)图图5.2.16图书管理系统借阅者实体类映射图书管理系统借阅者实体类映射3.映射关联 n1）一对多关系。在一对多关联中，一个对象可以与多个对象相链接。一种方法是将关系的“1”端对象的关键字附加到“多”端的一个列（或多列）。另一种方法是用一个独立表来存储一对多关系，在图书管理系统中，一对多的映射实例如图5.2.17所示。Item(bookID,bookno,state)图图5.2.17 图

27、书管理系统中一对多的映射实例图书管理系统中一对多的映射实例2）多对多关系。n对于多对多关系，需要增加一个表，这个表由具有链接关系的表的关键字组成，在图书管理系统中，多对多的映射实例如图5.2.18所示。Reservation(userID,bookno,date)图图5.2.18 图书管理系统中多对多的图书管理系统中多对多的映射实例映射实例3）一对一关系。零或一对一关联，把“l”端的主键添加到“0或l”表。其他一对一关联，可以把一个对象的主键添加到另一个对象中，在图书管理系统中，多对多的映射实例如图5.2.19所示。Fine(userID,bookID,date,)图图5.2.19 图书管理系

28、统中一对一的映射实例图书管理系统中一对一的映射实例4.映射聚集和组合 对于一对一的组合，可以将子类与超类建立成一个表；对于一对多的情况，无论聚集还是组合，对子类必须建立一个独立的表，将父类主键属性加入子类的表中。例如，Office类和Office Member 类之间存在着聚集关系，将该关系映射到关系数据库中，这种聚集的映射实例如图5.2.20所示。Office(officeID,)OfficeMember(OfficeMemberID,officeID,)图图5.2.20 聚集的映射实例聚集的映射实例5.映射泛化泛化的映射策略有三种：n（1）父类与子类可各自映射成表，将父类的主键属性加入子类

29、中，建立外键关联。在关系数据模型中用外键参照关系来表示继承关系。n（2）将子类表的属性添加到父类表的属性中，而不建立子类表。通过这种方式，可以使关系数据模型支持继承关系和多态。n（3）不建立父类表，而只建立子类表。将子类继承的父类的属性加入子类中。n在图书馆管理系统中，对于Book类来说，选择第二种方案，在Book表中添加书的类别属性，泛化的映射实例如图5.2.21所示。Book(bookID,typeofbook,)图图5.2.21 泛化的映射实例泛化的映射实例5.2.5 系统界面设计系统界面设计 系统界面是用户与系统交互的一个窗口，系统界面设计不仅影响到它本身外观的可观赏性，而且对系统的可

30、操作性也有很重要的影响，它是用户评价系统的一个很重要的指标。一个优秀的系统设计人员在进行界面设计时，总是时时从用户角度出发，以方便用户的使用为目标。用户第一次接触信息系统就是从界面开始的，用户界面的友好程度直接影响管理信息系统的使用效果和生命力。因此，如何设计信息系统的界面有重要的意义。5.2.5.1 界面设计原则1.基于用户需求，适合系统功能2.重视可读性和可理解性3.合理利用颜色、图像来达成内容与形式的统一动画效果。4.加强易用性和容错性5.2.5.2 界面设计内容n1.系统界面框架设计系统界面框架设计n2.系统界面元素设计系统界面元素设计n3.系统信息显示设计系统信息显示设计n4.系统为

31、用户提供较为详尽的帮助系统为用户提供较为详尽的帮助 5.2.5.3 基于UML技术的用户界面设计 1.从用例到用户界面从用例到用户界面 以餐馆管理信息系统为例，我们考察服务员包中的用例，并看看这些用以餐馆管理信息系统为例，我们考察服务员包中的用例，并看看这些用例如何映射到例如何映射到windows用户界面。下面将这些用例列出：用户界面。下面将这些用例列出：（1）输入定单；）输入定单；（2）将定单发送到厨房；）将定单发送到厨房；（3）修改定单；）修改定单；（4）接收来自厨房的通知；）接收来自厨房的通知；（5）跟踪定单状态；）跟踪定单状态；（6）结算账单；）结算账单；（7）打印账单；）打印账单；（

32、8）招来一名助手；）招来一名助手；（9）招来一名清洁师；）招来一名清洁师；（10）输入饮料定单；）输入饮料定单；（11）将饮料定单发送到休息室；）将饮料定单发送到休息室；（12）接收对方传来的确认应答；）接收对方传来的确认应答；（13）接收来自休息室的通知；）接收来自休息室的通知；5.2.5.3 基于UML技术的用户界面设计2.用于用户界面设计的用于用户界面设计的UML图图可以用状态图来描述用户界面的切换流程。图5.2.23显示了服务员界面中的高层屏幕之间如何联系。服务员主屏幕定单处理账单处理发送和接收信息图图5.2.23 服务员界面中高层屏幕的切换流程服务员界面中高层屏幕的切换流程因为一个特定的屏幕是由许多构件组成，说明类之间的组成关系类图也适用于对屏幕界面建立模型，图5.2.24显示了对应于图5.2.23的界面构件类的组成关系图。服务员屏幕定单屏幕账单屏幕信息屏幕定单按钮账单按钮信息按钮定单框输入按钮修改按钮跟踪按钮饮料按钮OK按钮图图5.2.24 对应于图对应于图5.2.23的界面构件类的组成关系图的界面构件类的组成关系图