第9章详细设计 本章导读 信息系统体系结构设计之后,需要着手详细设计。详细设计包括业务对象模型设计、 功能逻辑设计、数据库设计和界面设计等工作。详细设计是系统实现的依据,需要考虑所 有的设计细节,必须仔细认真。 主要知识点 ■业务对象模型设计 ■功能逻辑设计 ■数据库设计 ■界面设计
9.1业务对象模型设计 业务对象是从业务领域中提取的业务实体,这些业务对象将作为信息系统中的基本构 成元素,并作为信息系统中公用的实体类。业务对象模型设计是从整个信息系统考虑,不 局限于某一个或某几个子系统,业务对象将作为各子系统中功能逻辑设计和数据库设计的 基础。业务对象模型设计包括提取业务对象、对象属性设计、对象基本操作设计、关系设 计、优化类和建立业务对象模型等工作。 911提取业务对象 业务对象来源于业务领域中的业务实体。业务实体是组织中存在的各种事物,是组织 的基本资源。业务对象是信息系统的基本构成元素。业务对象虽然来源于业务领域中的业 务实体,但并不是所有的业务实体都会成为业务对象,从业务领域中提取那些在信息系统 范围内的业务实体作为业务对象。例如,图书、职工、会员、工资、奖金、架存图书、售 书单等是书店中的业务实体,如果要开发书店书务管理系统,只需要把图书、职工、会员、 架存图书、售书单定业务实体提取作为业务对象,而工资和奖金两个业务实体就不需要提 取为业务对象,因为书务系统不管理书店职工的工资和奖金。 用类的简化形式把提取的业务对象描述出来。图9.1是为开发书店书务系统,从书店 业务中提取的部分业务对象。 图91书店业务中提取的部分业务对象 912对象的属性设计 在面向对象方法中,属性用来表示对象的静态特性。构成对象静态特性的项目称为属 性项。每一个属性项中的具体值称为属性值。对“人”这个对象来说,姓名、性别、出
生年月、家庭住址、电话、体重、身高、血型、性格、爱好、职业、毕业院校、所学专业 都是该对象的属性。姓名,性别等项目称为对象“人”的属性项。赵晓,男,196610.12, 西安宇航电子公司11楼103号,8216381,63公斤等则是属性值 在平常应用中,并不明确区分属性和属性项两个概念。可以把一个对象所有静态特性 称之为对象的属性,也可能把对象的某一个属性项称为对象的属性。例如,我们说对象“人” 的“姓名”属性,而不说成对象“人”的“姓名”属性项。但严格讲,“姓名”是对象“人” 的属性项。 1.属性命名 给属性命名时,一般使用名词或带定语的名词。像“姓名”,“学生姓名”,“型号”,“产 品型号”,“商品条形码”等。尽量使用业务领域中规范、通用的词语,避免使用没有明确 含义或自定义的词语 2.属性分析 需要认真分析业务领域中的业务对象的性质,确定出合适的业务对象的属性。属性分 析的一般方法有: 从常理上看,业务对象所表示的事物有哪些静态特性 绝大部分业务对象,尤其是实体型业务对象是用来直接反映业务领域中具体事物的, 分析人员首先可以从常理上理解该业务对象所反映的事物应该有哪些静态特征,以便确定 业务对象的属性。例如,学生的静态特性有学生的身份证号、姓名、性别、住址、邮政编 码、电话、所学课程平均成绩、爱好、体重、身高、健康状况等。事物的静态特性可以作 为业务对象的侯选属性,但不能不加分析就直接作为对象的属性,因为信息系统也许并不 需要某些特性。 (2)在具体领域中业务对象所具有的属性 同一事物在不同的业务领域中,要求和突出事物的静态特性是不同的。例如,同一个 人,在学校中作为学生时考虑其静态特征时,除了姓名、性别、出生年月、住址、电话等 般特性之外,还要考虑与学习有关的特性,如所修课程、各科成绩等。但在医院中作为 病人时,其特性除一般特性之外,还要反映病人的身体状况和病情状况,例如,血压、脉 搏、体温、体重等。 (3)信息系统要求业务对象应具有的属性 业务对象的属性只有通过系统需求才能确定是否真正需要。从常理上所提出的属性和 业务领域的属性只能作为确定业务对象属性的参考,只有通过需求分析,才能确定业务对 象所需要的属性。 (4)业务对象需要记录和保存的信息 业务对象需要记录和保存的信息应该作为业务对象的属性。例如,产品的生产量是需要 记录和保存的产品信息,就可以把产品生产量作为产品对象的一个属性。学生所修课程的 成绩是需要保存的信息,学生所修课程成绩航可以作为学生对象的属性 图91中的几个业务对象确定的属性见图92
图92书务系统部分业务对象的属性 3.属性设计 属性设计是对属性分析的深入和细化,与属性分析相比较,属性设计应该着重强调下 面几个方面:第一,补充属性分析时没有考虑到的属性。属性分析主要反映类的重要属性 般不考虑涉及实现细节的有关属性,到属性设计时把这些属性补充全面。第二,确定属 性的全部内容。包括属性名、可视性、范围、类型、初始值等。第三,尽量用软件开发所 釆用程序设计语言的语法规范来描述属性。 图93是对图92中“图书”、“图书类别”和“出版社”三个业务对象的属性设计 图93书务系统部分业务对象的属性设计
91.3基本操作设计 属性是业务对象的静态性质,操作则是业务对象的动态性质。业务对象的完整操作需 要在全面考虑了业务对象在信息系统中完成的功能、对象之间的相互联系、系统的性能实 现等多种设计因素之后,才能完全确定。也就是说,业务对象的有些操作需要到功能逻辑 设计中才能够确定,在此只能确定业务对象的一些基本操作 此时确定的业务对象的操作主要从业务对象本身考虑,应该具有哪些基本操作,能够 保证这个业务对象的基本需要。图94是为书务系统的部分业务对象确定的操作。业务对 象的操作也需要进行设计,其设计工作是在分析的基础上,对每一个操作的算法、流程和 处理的数据进行设计。 图94书务系统部分业务对象的操作 914关系设计 不同的面向对象程序设计语言对关系的支持程度是不一样的,比如,C++支持多重继 承,而Java航不支持多重继承。本节主要讨论在不过多地考虑程序设计语言的情况下实现 对象关系的一般方法 1.关联关系
)二元关联 元关联存在一对一、一对多、多对多三种形式,其关联的设计方法也有差异。 1)一对一的二元关联 ①单向导航:要实现一对一关联的单向导航,只在导航源的类中增加另一个类的主键 属性。例如:图9.5(a)描述“系”和“系主任”两个类是一对一的关联关系,单向从“系” 导航到“系主任”类。在“系”中增加“主任编号”属性就实现了两个类之间的单向导航 一般建模工具会自动对单向关联关系的源类一方,建立相关联的另外一个类的关健属性作 为自己的一个附加属性。图9.5(b)是 Rational rose建立模型时,在单向导航的一对一的 元关联,在“系”类中附加的属性。 图95一对一关联单向导航的实现 ②双向导航:一对一关联的双向导航需要关联的两个类中分别增加对方的关键属性。 例如,图9.6(b)是对(a)中双向导航的实现。 图96一对一关联双向导航的实现 6
2)一对多的二元关联 两个存在一对多关联关系的类,其导航方向肯定是由多重性为多的类导航到多重性为 的类,而不会相反。在多重性为多的一方类中增加另一个类的关键属性就实现了关联的 导航关系。例如,图9.7(b)是对(a)中一对多单向导航的实现 图97一对多关联单向导航的实现 图98多对多关联的实现
3)多对多的二元关联 多对多二元关联的实现需要在两个类之间增加一个新类,用另外两个类中的关键属性 作为这个类的属性。例如,图9.8(a)“课程”和“教师”两个类之间存在多对多的关联关 系。为了实现这两个类之间的双向关联,需要在它们之间增加一个“授课”类,并把“课 程”和“教师”两个类的关键属性“课程编号”和“教师编号”,作为“授课”类的属性, 这样把两个多对多的二元关联就转化成为三个类中两两之间的一对多的关联,其导航关系 分别是从“授课”类到另外两个类。见图9.8(b)和图9.8(c) 2)三元关联的设计 假定讨论的三元关联中存在关联类,介绍维持法的设计方法。 维持三元关联关系不变,三个存在关联关系的类保持不变,给关联类中增加其它三个 类的关键属性。例如,图9.9(a)中,“教师”、“班级”、“课程”存在“授课”的三元关联 (b)是对(a)中这种关系的设计,(c)是几个类的属性 教师 生日期 狂级编 果程编号 级名 程名 授 课形式 教学效果 (a) 图99维持法实现三元关联 2.组成关系设计 般面向对象程序设计语言都直接提供对组成关系的支持。在定义整体类时,把其部 分对象作为整体类的成员,这样就构成和整体与部分的组成关系。所以组成关系的设计十
分简单 3.泛化关系设计 所有面向对象程序设计语言都提供继承支持,因此泛化关系本身就被面向对象程序设 计语言支持。但有些语言仅支持单继承,不支持多继承,因此,对设计模型中的多继承要 进行必要处理。一种方法是把多继承转化成为单继承,第二种方法是用接口来实现多继承 下面我们介绍用接口实现多继承的方法。 图910是一个多继承的例子。“汽车”继承了“陆上交通工具”和“水上交通工具” 两个类。为了让“汽车”能够具有“陆上交通工具”和“水上交通工具”的特性,首先定 义“陆上交通工具”和“水上交通工具”的接口,然后在“汽车”类中实现这两个接口, 这样就让“汽车”类拥有了“陆上交通工具”和“水上交通工具”的操作。 陆上交通工具机动交通工具 陆上父通工具机动交通工具 《 Interface》 《 interface》 陆上交通工具机动交通工具 汽车 图910接口实现多继承 汽车 91.5类的优化 对从业务领域中提取有些复杂的类需要进一步优化。对类进行优化的原则是使类能够 明确的表示事物实体,并具有相对独立性、一致性和适中的规模。类优化方法很多,在此 我们引用数据库设计中的规范化理论来对类进行优化。在数据库设计中,一般根据规范原 则检査关系的优劣,如果一个关系符合范式规约,可以说该关系是规范的。否则就需要对 该关系进行优化处理,通过对关系的分解使其满足范式要求。实体类具有属性,关系也具 有属性,因此,我们可以通过引用规范化方法,来对实体类进行优化。规范化理论和方法 读者可以参考有关数据库书籍,在此,我们将以“图书订单”类的规范过程为例,讨论对 实体类的优化过程。规范的类将满足三级规范要求。一级规范要求在类中所有属性是不可 再分的基本属性项,二级规范是在满足一级规范的基础上,类中不存在对主键属性部分依 赖的属性。三级规范则要求在满足二级规范的基础上,在类中不存在传递依赖关系。下面 我们分四步对由图911“图书订单”所产生的“图书订单”类(图9.12)进行优化 首先,不加分析地建立一个图912的“图书订单”类,这个类完全是根据订单中包含 的项目提取出该类的属性
图911书务系统的图书订单 图913一级规范后的“图书订单”类 图912初步的“图书订单”类 10