《系统设计》PPT课件

第7章 系统设计,7.1 概述 7.2 系统平台设计 7.3 拓扑结构和计算模式设计 7.4 软件结构设计 7.5 详细设计 7.6 数据库设计,7.1 概 述,7.1.1 系统设计的任务和特点 在信息系统开发中，突出信息系统特征的业务、管理、决策等因素已经在前续阶段中被消融和解决，到了系统设计阶段，信息系统的设计与一般软件系统的设计已经没有太大的区别，软件工程对软件设计的思想、方法、技术和过程完全适应于信息系统的设计。因此，信息系统的设计也就基本等同于软件系统的设计。,系统设计的任务是，为实现信息系统需求模型所规定的功能和性能要求，考虑信息系统实现环境，通过对信息系统分析模型的综合分析和细化，确定出信息系统的设计模型。,与系统分析相比，系统设计具有以下特点： (1)设计性。设计不同于分析，设计是根据系统的要求，得出实现系统的方案。所以，系统设计是根据需求确定系统方案的过程。 (2) 具体化。相对于系统分析的概念性而言，系统设计不能停留在概念层次上，必须具体化、细致化。 (3)复杂性。系统设计涉及到具体细节，工作量大、头绪繁多，一般要比系统分析多出近乎5倍的工作量，因此，设计人员必须认真对待。 (4)往复性。一个成熟的设计方案并不是一次完成的，而需要经过多次的迭代反复才能够完成。,7.1.2 系统设计的主要工作 1平台设计 2结构设计 3详细设计 4界面设计 5数据库设计,主要工作简介 1平台设计 信息系统平台是信息系统开发和运行的环境，包括网络、计算机、相关设备、支撑软件和系统软件等。平台设计需要根据信息系统设计要求，通过对技术和市场的综合分析，确定出网络结构、设备选型和软件平台方案。,2结构设计 在设计工作中，需要确定信息系统的拓扑结构、计算模式和软件结构。 3详细设计 详细设计是对软件结构中确定出的各个子系统内部的设计，需要分析和确定每一个子系统中的用例设计、设计类和接口。 4界面设计 界面设计是对人和外部系统与信息系统之间交互界面的设计。它包括输入界面、输出界面和混合界面的设计。,5数据库设计 数据库是信息系统存储和管理数据的主要技术手段，数据库设计的任务是根据给定的信息系统应用需求和系统环境，设计出合理的数据库结构。数据库设计需要经过概念设计、逻辑设计和物理设计等步骤。,7.1.3 信息系统设计模型和软件模型 信息系统设计模型是对信息系统设计方案的抽象描述，它要完整描述信息系统设计的内容，并具有简明、抽象、概括和规范等特点。 信息系统设计模型包括平台模型、拓扑计算模型（拓扑结构和计算模式）、软件模型、界面模型和数据库模型等内容(见图7.1)。,图7.1 信息系统设计模型,软件模型的构成见图7.2。软件系统是软件模型的顶层视图，它由子系统、设计类、用例设计和接口构成。系统中的绝大部分设计类和用例设计均处在子系统中，但对系统具有重要意义的少数用例设计和设计类也可能不包括在子系统中，而直接属于软件系统。,图7.2 软件模型,图7.3 用例设计到用例分析和用例的跟踪,用例设计包括用例的设计类图和交互图。 设计类图反映一个用例中的设计类所呈现的静态结构。与分析类图相比较，设计类图更详细、更具体。设计类图所反映的设计类之间的关系应该能够被所采用的程序设计语言所支持。 通过交互图，可描述在实现一个用例过程中各个设计类之间的消息联系过程,接口是设计类或子系统对外所能够提供的操作。接口并不涉及到对设计类或子系统操作的实现。接口也是设计类或子系统对外所提供的操作视图，其它设计类或子系统通过接口来与提供接口的设计类发生关系。接口的实现如图7.4所示。 (你所知道的软件接口有哪些?),图7.4 接口的实现,7.2 系统平台设计,7.2.1 网络设计 信息系统一般都是集成式、综合性系统，网络把系统的各个部分连接到一起以形成一体化系统，网络在系统设计中占有很重要的地位。,网络设计主要包括网络需求分析、网络结构设计和网络详细设计三部分内容。 1. 网络需求分析 网络需求分析是通过对所开发的信息系统的规模、系统所覆盖业务的地域分布、计算机设备、网络服务等方面需求的分析，为确定网络总体结构、网络详细设计提供依据。网络需求分析需要调查和分析以下6方面的内容。,1)信息系统的特征对网络的需求：办公自动化系统和CIMS系统对网络的结构和布局有不同的要求。 2)信息系统拓扑结构和计算模式对网络的需求 3)信息系统业务所覆盖的地理分布 4)网络服务需求：数据库访问方式和数据存储分布模式；文件传输和存取需求；电子邮件和远程通信需求；企业网与社会网、因特网的互连需求等。 5)信息类型和信息量 6)性能需求：系统对网络的效率、速度、可靠性、安全性等性能要求。,2. 网络结构设计 网络结构设计的主要任务是根据网络需求分析的结果，设计出能够满足信息系统需要、结构合理、易于扩充、性能价格比高的系统网络总体结构。系统网络总体结构可以采用单级、二级和多级结构。,1) 单级结构 对于规模较小、地域相对集中的小型系统，可以采用单级网络结构。单级结构一般采用一个小型局域网，各部分之间可以采用集线器、网桥连接，如果在局域网中还有异构网络，可以采用网关。 2) 二级结构 对于分布地域范围较广、管理复杂的中型系统，可以采用二级网络结构。二级网络结构一般由高速主干网和多个局域网构成。主干网可以选择FDDI、交换网、ATM或快速以太网等技术。,3) 多级结构 对于跨地区、跨省、跨国的大型或超大型系统，则需要采用多级网络结构。在多级网络结构中，一般顶层采用社会公用网或专用广域网，二级和三级则为骨干网和主干网，最下一级为局域网。,3. 网络详细设计 网络详细设计包括网络节点设计、网络设备选型、网络布线设计、网络操作系统选择、网络管理设计等内容。 1) 网络节点设计 网络节点设计指通过网络需求分析，详细确定每一个网络节点的具体位置、设备类型和连网设备，并绘制出网络节点分布图，以便根据网络节点分布图进行设备选型和网络布线设计。,2) 网络设备确定及选择 需要详细确定整个网络系统所需要的服务器、路由器、集线器、网关、网桥、网卡、网线等网络设备。还需要根据网络的功能和性能需求，确定各个网络设备的性能指标。例如，服务器需要多大存储容量、多高速度；根据系统的安全性、可靠性要求确定是选择双服务器系统、磁盘镜像技术，还是采用单服务器。,3) 网络布线设计 根据网络节点设计的结果和具体地理分布，要进行细致的网络布线设计。目前网络布线一般对网络系统、电话系统、监控系统采用统一布线方式，这种布线方式叫做结构化布线。结构化布线设计需要由低层向高层逐层进行布线设计。首先在办公室确定网络设备位置和插座位置；再确定每个楼层的水平布线；然后确定楼层的垂直布线；最后确定主干网线的布线。,4) 网络操作系统选择 网络操作系统是网络的核心软件。一般在大型网络系统中并不一定只选择一个统一的网络操作系统。有时可能会采用多个网络操作系统。目前可供选择的网络操作系统有UNIX、Windows NT、NetWare、OS2等，可根据系统需要进行选择。 5) 网络管理设计 对网络系统需要进行有效管理。一般大型网络系统采用一个网络管理中心、多个网管分中心的方式。网络管理设计需要确定网络管理结构、网络管理软件、网络管理职责和人员等。,7.2.2 物理设备设计 除了网络系统之外，信息系统还包括大量的计算机和相关信息设备等物理设备，根据需要正确地选择物理设备也是平台设计的一个主要内容。 1. 物理设备的基本类型 信息系统的物理设备一般包括以下类型： 1) 计算机系统 计算机系统有多种形式。按规模和性能分有巨型机、大型机、中型机、小型机、工作站和微型机；按用途分有通用机和专用机。,2) 相关I/O设备 每一个计算机系统都有各自的I/O(输入/输出)设备，除了计算机系统所配置的I/O设备之外，根据需要，不同类型的信息系统还需要配置一些特殊的I/O设备。相关的I/O设备有共享打印机、扫描仪、绘图仪、条码阅读器、IC卡读写器、磁卡读写机、数字照相机、投影仪、专用键盘、声光传感器等。 3) 多媒体设备 多媒体设备有触摸屏、图像摄取仪、声/视卡、图像处理卡、音箱、功率放大器、摄像机、录像机、解压卡等。,4) 办公设备 办公信息系统还要配置大量的办公自动化设备。一般办公自动化设备有会议系统、复印机、碎纸机等。 5) 电源系统 电源系统有不间断电源、稳压器等。 6) 机房设备 机房设备有电力系统、布线系统、安全系统、消防系统、照明设备、制冷设备、清洁设备等。,2. 物理设备设计 物理设备设计是根据信息系统的设计要求，确定信息系统物理设备方案。所设计的物理设备方案在能够充分满足信息系统功能需要的前提下，还应该满足系统的效率、可靠性、安全性和适应性等性能要求，并具有较高的性价比。,7.2.3 软件平台设计 软件平台是信息系统开发和运行所需的集成软件系统。设计和选择高效、实用、方便、功能齐全的软件平台，对信息系统开发有着十分重要的意义。目前，可供选择的软件平台很多，软件平台设计就需要系统分析员根据实际开发的需要，充分考虑各种软件平台的性能和适应范围，并结合开发队伍对软件平台的使用经验，选择出有效的软件平台。,1. 操作系统 操作系统是计算机系统中最重要的系统软件。目前主要的大型操作系统有UNIX、Windows NT、OS/2、Macintosh等；在微机上运行的桌面操作系统有Windows 95、Windows 98、Windows ME、Windows XP等。这些操作系统各有其适应面和优缺点，应根据需要进行选择。,2. 支撑软件 支撑软件是协助人们开发和维护软件的工具和环境软件。编辑程序、数据库系统、集成开发环境等都属于支撑型软件，如Visual Basic、Delphi、PowerBuilder、Oracle、Java等。支撑软件主要包括以下几方面软件： 1) 数据库管理系统DBMS 在数据库服务器上的DBMS对数据库实施集中管理，可以并发地处理多个客户机发来的数据处理请求。常见的数据库管理系统有SQL-Server、Oralce、Sybase、Informix、DB2等，系统分析员可以根据自己的需要进行选择。,2) 客户端开发软件 客户端开发软件十分丰富，系统开发人员可以根据设计需要进行选择，选择客户端开发软件要考虑继承性。常见的客户端开发软件有PowerBuilder、Visual Basic、Visual C+、Delphi、Visual Foxpro、Java等。 3) 中间件协议和软件 在网络设计中已经确定了网络操作系统和网络传输协议中间件。还要进一步确定的中间件有： (1) 数据库中间件。通过数据库中间件，可允许客户在异构数据库上调用基于SQL的服务。数据库中间件有ODBC、DRDA、IDAPI、RDA、ORACLE-GLUE等。,(2) 事务处理中间件。通过事务处理中间件，可允许客户在多个事务服务器上调用服务。事务处理监视器允许不同的服务器控制其本地资源，并在需要访问本地资源时与其它事务处理监视器进行合作。事务处理监视器保证服务器内和服务器之间的所有活动的完整性。这方面的标准包括TUXEDO的ATMI、ENCINA的RPC和X/Open的TXRPC等。 (3) 群件中间件。通过群件中间件，客户可以在多个群件服务器上调用服务。目前群件中间件有电子邮件方面的PAPI及Lotus Notes API等。,3. CASE平台 采用CASE开发环境可以保证信息系统开发质量，提高开发效率，保证文档的一致性，减轻开发人员的工作负担。CASE平台与所支持的系统开发方法有直接联系，有支持结构化方法的CASE、支持原型化方法的CASE、支持OO方法的CASE和支持多种方法的综合CASE环境。开发小组应该根据所采用的开发方法来选择合适的CASE环境。,7.3 拓扑结构和计算模式设计,7.3.1 信息系统拓扑结构设计 拓扑结构设计需要确定信息系统的节点和节点的结构。节点是信息系统中一个在逻辑分布上相对独立的处理实体，一个节点一般要包括一台独立的计算机和外围设备。节点可以是人机交互的客户机，也可以是业务管理、数据库管理、Web管理的服务器。,在考虑所要设置的节点时，同时就要一并考虑该节点的作用和类型。节点的类型一般需要根据采用的计算模式而定。 例如，采用客户机/服务器模式中的节点就有客户机和服务器两种类型，而采用应用服务器模式的系统中，节点可以分为客户机、应用服务器和数据库服务器这几种形式。,下面给出书店信息系统分布结构设计实例。 书店信息系统是一个中小规模的信息系统，业务比较简单，总店分布区域也不大。经过分析，该系统的计算模式采用客户机/服务器模式；整个系统设置七个节点：计划采购节点、书库节点、销售节点、结算节点、事务处理节点、系统管理节点和数据库服务器节点。数据库服务器是中心节点，所以书店信息系统的拓扑结构呈星型结构(见图7.5)。,图7.5 书店信息系统拓扑结构,7.3.2 信息系统计算模式设计 选择哪一种计算模式应该根据应用需要而定，不能盲目追求先进和时新。例如，客户机/服务器模式可以满足要求，就不一定要采用应用服务器模式。另外，对于复杂的大型系统，采用某一种计算模式可能并不能满足应用要求，有时需要多种计算模式并存。书店信息系统的计算模式采用客户机/服务器模式(见图7.6)。,图7.6 书店信息系统计算模式,7.4 软件结构设计,7.4.1 概述 信息系统的软件结构是由信息系统软件的各子系统按照确定的关系构成的结构框架。子系统是对软件分解的一种中间形式，也是组织和描述软件的一种方法。由多个子系统构成信息系统软件，每一个子系统又包括多个用例设计、设计类和接口。,软件结构设计是把软件分解成为多个子系统，并确定出由各子系统及其接口构成的软件结构。软件结构一般呈现出层次结构模式，而且常见为四层结构(见图7.7)。,图7.7 软件系统的四层结构模式,应用层是信息系统软件所在的层次，它的作用是直接服务于信息系统的应用领域。应用层又分为专用应用层和通用应用层。专用应用层中的子系统直接面向具体应用；通用应用层中的子系统可以被专用应用层的多个子系统所引用，具有通用性。在应用层中的子系统被称为应用子系统。 中间件层放置支撑系统运行的有关中间件，像通信工具、数据库引擎、分布对象机制等。 系统软件层则放置操作系统、低层协议等系统软件。在中间件和系统软件层中的子系统被称为系统子系统。,7.4.2 应用子系统设计 1识别应用子系统 识别应用子系统的原型是信息系统逻辑结构中的分析包。可以把逻辑结构中每一个分析包作为一个初步的应用子系统，在此基础上，再对各子系统进行分析和优化，以确定应用子系统。 例如，图6.13中的“入库”和图6.14中的“售书处理”两个分析包可以作为被识别的两个初步应用子系统，见图7.8。,图7.8 设计模型可以跟踪到分析模型,2优化应用子系统 通过分析包识别出的初步应用子系统并不能作为最终确定的应用子系统，还需要进行优化处理。从设计角度看，进行优化的理由有三： 首先，分析包没有考虑系统的效率、安全性、可靠性、适应性等非功能性需求，也没有考虑系统的实现环境以及系统的拓扑结构和计算模式。 第二，应用子系统应该具有合适的规模。如果初步应用子系统规模过大，就需要进行分解。相反，对规模过小的初步应用子系统又要进行合并，使最后所确定的应用子系统都具有合适的规模。,第三，应用子系统应该具有高内聚、低偶合的特性，即子系统内部的要素之间的联系应该尽量地密切，而子系统之间的联系尽可能小。 优化的具体步骤： 第一，规模分析。 第二，应用分析。 第三，节点分布分析。,下面我们以图6.13的“入库”分析包识别为初步的“入库”应用子系统和图6.14的“售书处理”分析包识别为初步的“售书处理”应用子系统为例，进行分析优化。,首先分析“入库”应用子系统。 第一，规模分析。从图5.7(a)可以看出，“入库”分析包可以跟踪到“编辑入库信息”、“查询入库信息”和“输出入库信息”三个用例，它要完成对应的三项功能。这样“入库”作为一个应用子系统规模过大，应该对其进行分解。我们把它分解成为对应上述三个功能的“编辑入库信息”、“查询入库信息”和“输出入库信息”三个应用子系统。 第二，应用分析。“编辑入库信息”、“查询入库信息”和“输出入库信息”三个应用子系统都属于专用子系统，,它们都要访问数据库服务器上的“入库图书”数据表，应该设置“入库管理”通用子系统来对数据库进行专门管理。 第三，节点分布分析。设计中确定的子系统应该在一个节点上，如果一个子系统可能跨几个节点，就需要对该子系统进行分解。“编辑入库信息”、“查询入库信息”和“输出入库信息”三个专用子系统处在书库节点上，而“入库管理”通用子系统处在数据库服务器节点上。对“入库”子系统优化的结果如图7.9所示。,图7.9 优化的“入库”子系统,图7.10 优化的“售书处理”子系统,7.4.3 系统子系统设计 软件结构设计的第二步工作是确定中间件。中间件设计与系统的应用要求和系统环境有关。例如，如果系统采用浏览器模式，就需要选择Web浏览器作为中间件；如果系统具有分布处理要求，就需要选择DCOM、CORBA或Java.rmi等具有分布对象处理能力的中间件。另外，还需要根据数据处理的要求，选择合适的数据库系统。,软件结构设计的第三项工作是确定系统软件层所采用的软件系统，一般包括操作系统、网络协议等。例如操作系统采用Windows NT，网络协议采用TCP/IP等。 现在我们讨论书店图书管理系统中售书处理部分的软件结构设计(见图7.11)。 在专用层设置“售书处理”的顶层子系统，接下来又分出“开书单”、“出售图书”、“收书款”三个子系统，这三个子系统都处在专用应用层。,图7.11 书店信息系统中“售书处理”的软件结构,7.4.4 确定子系统间的接口 当子系统之间存在依赖关系时，子系统之间就存在确定接口。子系统接口定义了外部子系统对本子系统可进行的访问操作集。这些操作由子系统内部的类来提供，或着由子系统中的其它子系统提供。 可以通过子系统之间存在的关系来发现子系统之间的接口。如果子系统A依赖子系统B，则子系统B应该向子系统A提供接口(见图7.12)。图7.11售书处理的软件结构中专用应用层和通用应用层几个子系统之间的接口描述见图7.13。,图7.12 根据依赖关系确定接口,图7.13 图书销售子系统之间的接口,7.5 详细设计,详细设计是对软件结构中已经确定的各个子系统内部的设计。详细设计需进行三个主要设计： 用例设计、设计类的设计和关系设计。,7.5.1 用例设计 1概述 子系统可以跟踪到分析包，分析包可以跟踪到用例。图7.14反映了子系统、分析包和用例的跟踪关系。因为一个子系统能够完成它所跟踪的用例的功能，所以详细设计的第一项工作便是对子系统所跟踪的用例进行设计。 用例设计包括两个含义：一是用例设计的工作，二是描述用例设计的结果。,图7.14 子系统、分析包和用例的对应关系,2用例设计的工作 1) 确定设计类 用例设计的第一项工作是确定该用例所涉及到的所有设计类。由用例设计可以追踪到用例分析，在对用例分析时，分析员已经确定了用例所涉及到的所有概念类。因此，可以把用例分析确定的概念类作为初步设计类。然后根据设计的需要，再对初步设计类进行分解和调整，成为最终的设计类。,2) 设计类图 在确定了用例的设计类之后，接下来应该通过类图反映所提取的各个设计类之间的相互关系。因为还没有对每一个设计类进行详细分析，所以现在所确定的设计类图是简化的设计类图。 3) 绘制顺序图 为了完成赋予用例的功能，用例的一次交互处理要通过用例中的各个类中的对象操作的相互配合来完成。可以通过顺序图来反映各个对象之间的消息交互过程。,3用例设计过程 1) 确定子系统和设计类 2) 分析用例设计类图 3) 绘制顺序图,下面我们以“售书处理”为例，讨论用例设计过程。 1) 确定子系统和设计类 “售书处理”是一个用例，但该用例被分解成为图7.10所示的处在三个节点上的八个子系统，即售书节点上的“售书处理”、“开书单”和“出售图书”三个子系统，结算节点上的“收书款”子系统，在数据库服务器上的“书目管理”、“架存图书管理”、“售出图书管理”和“职工管理”四个子系统。,在第6.4节对“售书处理”用例所提取的八个概念类的基础上，可以确定各个子系统的设计类。“售书处理”子系统中有“售书界面”、“产生待售图书”和“待售图书”三个设计类。“开书单”子系统的设计是“开书单”和“打印进程”。“收书款”子系统的设计类是“收款界面”和“收书款”。“出售图书”子系统中有“出售图书界面”、“出售图书”和“一致性检查”三个设计类。除此之外，在数据库服务器节点中，“书目”属于“书目管理”子系统，“架存图书”属于“架存图书管理”子系统，“售出图书”属于“售出图书管理”子系统，“职工”属于“职工管理”子系统。,2) 分析用例设计类图 通过以上分析，绘制出图7.15所示的“售书处理”用例设计类图。在“售书处理”子系统中，“售书界面”类与“产生待售图书”控制类之间存在关联关系。当“售书界面”类接收一个要出售图书的书号和册数时，就给“产生待售图书”类发送一个消息，启动“产生待售图书”类的“产生待售图书对象”操作，产生一个待售图书对象，记入“待售图书”类中。,图7.15 “售书处理”用例设计类图,书单打印出来后，售书员把书单交给读者，读者持书单到收款台交款。收款员启动“收款界面”输入书单上的书单号，“收款界面”把书单号通过消息发给“收书款”类，该类从“待售图书”类中取出该书单的图书信息，并在界面上显示书款金额，收款员接收读者书款，并在“待售图书”类的对应对象中把“交款标记”设为“T”。,付款之后，读者又把书单拿回到售书员面前，“售书界面”类又进入“出售图书”子系统中的“出售图书界面”类，由该界面给售书员提供一个出售图书信息界面。售书员输入所出售图书的书单号，然后启动“出售图书”类，由该类在“售出图书”类中建立已售出图书的对象，而从“待售图书”类中把对应的对象删除掉。 “书目”类与“架存图书”和“售出图书”之间是泛化关系。,3) 绘制顺序图 由于“售书处理”涉及到四个子系统，其彼此控制也具有相对独立性，因此，下面我们分别绘制“产生待售图书”、“开书单”、“收书款”和“出售图书”四个子系统的顺序图。 (1) “产生待售图书”的顺序图(见图7.16)。“售书界面”接收售书员输入的读者所要购买图书的书号和册数，同时给该读者产生一个书单号。,图7.16 产生待售图书顺序图,(2) “开书单”的顺序图(见图7.17)。售书员按售书界面上的“开书单”功能按钮启动开书单功能。“售书界面”对象给“开书单”子系统的“开书单”类的对象发送“打印书单”消息，同时把所要打印书单的“书单号”也一并发送过去。“开书单”对象接收到这个消息后，给“售书处理”子系统的“待售图书”对象发送“取待售图书信息”消息，取出对应书单号的所有待售图书信息。“开书单”对象根据取到的信息生成书单，并启动“打印进程”打印出书单。售书员把打印出来的三联书单交给读者，让读者上收款台交书款。,(3) “收书款”的顺序图（见图7.18）。收款员接收到读者拿来的书单，按书单号交给“收款界面”对象，该对象接着给“收书款”对象发送“收书款”的消息。“收书款”对象接收到这个消息后，给“售书处理”子系统中的“待售图书”对象发送消息，取出这个书单号的待售图书信息，并把“待售图书”对象中的交款标记设为“T”。付完款之后，收款员自己留存一联书单，给另外两联书单上盖章并交给读者，收书款结束。,图7.17 “开书单”顺序图,图7.18 收书款顺序图,(4) “出售图书”的顺序图(见图7.19)。“出售图书界面”对象接收售书员扫描进的书单号，给 “出售图书”对象发送“出售图书”消息。“出售图书”对象接收到这个消息后，从“待售图书”类中取出该“书单号”的所有对象，并把这些对象从“待售图书”类中删除掉。然后给“架存图书管理”子系统发送消息，修改架存图书数量。最后通过“售出图书管理”子系统在售出图书数据表中记录所售出的图书数据。,图7.19 “出售图书”顺序图,(5) 一致性检查。“一致性检查”的作用是检查“待售图书”类中所有无用的对象，并将其删除掉。“一致性检查”的顺序图见图7.20。,图7.20 “一致性检查”顺序图,7.5.2 设计类的设计 用例设计中识别出了大量的设计类，接下来要详细地设计所识别出来的每一个设计类。系统分析得出的概念类是设计类的基础，但设计类不完全等同于概念类。原因有三：,其一，设计类是概念类的细化和分解。在系统分析中确定的一个概念类到系统设计时，可能对应着一个设计类，也可能被分解成为了多个设计类。 其二，由于在设计中要考虑系统的非功能性需求，因此，在设计时可能会产生出许多为了满足系统的非功能性需求的新的设计类，这些类根本没有对应的概念类。 其三，设计着眼于实现。,所以对设计类的设计必须考虑所有实现细节。设计类的设计工作包括属性设计、操作设计、方法设计和状态设计。,1不同类型设计类的设计 1) 边界类的设计 边界类承担信息的输入和输出以及信息的界面组织等任务。边界类是用户界面设计在系统中的实体性体现，用户界面设计涉及到人机工程、审美和操作方便性等方面的知识和要求(第8章将介绍界面设计)。边界类设计依赖于信息系统所采用的实现环境和设计语言。边界类在可视化的设计语言中一般表现为框架Form、窗口Windows和控件Controls等形式。,2) 实体类的设计 实体类的信息一般要在系统中长久存放，因此，实体类的设计要与数据库技术或文件技术联系起来。应用型软件几乎全部采用数据库技术，仅有效率要求极高的系统软件可能采用文件技术。信息系统属于应用型系统，一般对实体类采用数据库技术。数据库有关系数据库、对象数据库和对象关系数据库等形式。最直接的方式是采用面向对象数据库，但面向对象数据库目前还不够成熟。,3) 控制类的设计 控制类为系统的处理逻辑而设计，具有动态性。一般根据以下需要来设置控制类： 第一，事务处理。信息系统存在大量的事务处理，一个用例就是对一个事务的处理。在处理具体事务过程中，涉及到边界类和实体类，而在处理的关键环节和交汇点上就应该设置控制类。例如，在“售书处理”中的“产生待售图书”、“开书单”、“收书款”和“出售图书”等控制类都是在事务处理的关键环节上设置的。,第二，性能要求。为了实现系统的效率、可靠性、安全性和适应性的要求，需要设置控制类。例如，“一致性检查”就是为了正确性要求而设置的控制类。 第三，分布处理。当处理被分布到不同的网络节点上时，在各个节点上就需要设置单独的控制类来实施处理。,2属性设计 属性设计是对属性分析的深入和细化，与属性分析相比较，属性设计应该着重强调以下几个方面： 第一，补充属性分析时没有考虑到的属性。属性分析主要反映类的重要属性，一般不考虑涉及实现细节的有关属性，到属性设计时就要把这些属性补充全面。 第二，确定属性的全部内容，其中包括属性名、可视性、范围、类型、初始值等。 第三，尽量采用信息系统所采用的程序设计语言的语法规范来描述。,图7.15的“产生待售图书”、“开书单”等控制类没有属性，因此，我们仅设计“书目”、“架存图书”、“待售图书”和“售出图书”这几个类的属性。在分析时，已经确定的属性见图7.21。其中，“书目”类的属性有书号、书名、作者、出版社编号、单价、出版日期和图书类别；“架存图书”的属性有架位和架存册数；“待售图书”的属性有书单号、销售册数、折扣率、交款标记和售书员；“售出图书”的属性有售出册数、折扣率、售出日期和售书员。对这些类的属性进行设计的结果见图7.22。,图7.21 “书目”等类在分析时确定的属性,图7.22 “书目”等类的属性设计,3操作设计 操作设计的任务是确定各个类应该提供的操作。确定类操作的根据有以下四个方面： (1) 概念类的职责。概念类职责定义了该类应该具有的功能，类的这些功能就需要分解到各个操作中来实现。 (2) 概念类的非功能性需求。系统的效率、可靠性、安全性等非功能性需求，常常要落实到类的一些操作上来，通过设置某些操作来实现这些需求。,(3) 设计类的接口。设计类的接口是设计类对外提供的操作功能，这些功能均需要通过设计类所提供的操作来实现。 (4) 类所参与的用例设计。一个类可能要参与多个用例设计，在每一个用例设计中，该类都起着确定的作用，承担着确定的角色，这些作用最终都要落实到类的操作上。这就需要逐一分析类在每一个用例设计中所承担的角色。,对操作的描述应该注意以下两个方面： (1) 详尽全面。应该反映操作名、输入参数、返回参数以及可视性。 (2) 尽可能采用所用的编程语言的语法格式来描述，这样到实现时就无须再进行格式转换。 下面我们讨论“售书处理”用例中类的操作设计。 1) 实体类的操作设计 “书目”是一个实体类，应该设置write(bookNo, bookInformation)操作给书目对象中写内容，read(bookNo) :bookInformation从给定书号的书目对象中读书目信息。,图7.23 “书目”等实体类的操作设计,图7.24 “书目”等实体类的操作设计,2) 控制类的操作设计 “售书处理”用例共涉及到“产生待售图书”、“开书单”、“收书款”、“出售图书”和“一致性检查”等五个控制类，这些控制类全部没有属性，仅有操作，下面我们确定这几个类的操作。,图7.25 “售书处理” 用例的控制类操作设计,4方法设计 由于操作设计只确定各个操作的名称和参数，因此，操作设计仅是操作的外部特征设计。每一个操作都需要采用一定的数据结构、算法和流程，并采用一段程序代码来实现。确定操作的内部数据结构、算法和流程的设计被称为方法设计。 方法设计包括数据结构设计、算法设计和流程设计。方法设计需要立足于采用的程序设计语言。数据结构设计应该采用所选用的程序设计语言能够提供的数据结构；算法设计要根据操作所实现的功能而定；流程设计的结果可以用程序流程图或活动图来描述。,图7.26 产生待售图书流程图,5状态设计 对象在其生命周期中，会存在多种状态，认识和识别对象在生命周期中所处的各种状态，以及状态之间的切换条件，是全面把握对象的关键。一般用状态图来描述类中对象的状态。图7.27所示是书店图书类所处的几种状态。,图7.27 书店图书类状态图,7.5.3 关系设计 不同的面向对象程序设计语言对关系的支持程度是不一样的。 例如，C+支持多重继承，而Java就不支持多重继承。有些程序设计语言支持关联，有些不支持关联。本节主要讨论在不过多地考虑程序设计语言的情况下实现对象关系的一般方法。,1关联关系设计 1) 二元关联的实现 二元关联存在一对一、一对多、多对多三种形式，其关联的实现方法也有差异。,(1) 一对一二元关联。一对一二元关联可通过单向导航和双向导航来实现。 单向导航。要实现一对一关联的单向导航，可以只在导航源的类中增加另一个类的关键属性。例如，图7.28(a)描述“系”和“系主任”两个类是一对一的关联关系，单向从“系”导航到“系主任”类。在“系”中增加“主任编号”就实现了两个类之间的单向导航(见图7.28(b)。 双向导航。一对一关联的双向导航需要关联的两个类中分别增加对方的关键属性。例如，图7.29(b)是对图(a)中双向导航的实现。,图7.28 一对一关联单向导航的实现,图7.29 一对一关联双向导航的实现,(2) 一对多二元关联。两个存在一对多关联关系的类，其导航方向肯定是由多重性为多的类导航到多重性为一的类，而不会相反。在多重性为多的一方类中增加另一个类的关键属性就实现了关联的导航关系。例如，图7.30(b)是对图(a)中一对多单向导航的实现。,图7.30 一对多关联单向导航的实现,(3) 多对多二元关联。多对多二元关联的实现需要在两个类之间增加一个新类，用另外两个类中的关键属性作为这个类的属性。例如，图7.31(a)中,“课程”和“教师”两个类之间存在多对多的关联关系。为了实现这两个类之间的双向关联，需要在它们之间增加一个“授课”类，并把“课程”和“教师”两个类的关键属性“课程编号”和“教师编号”作为“授课”类的属性。这样把两个多对多的二元关联就转化成为三个类中两两之间的一对多的关联，其导航关系分别是从“授课”类到另外两个类(见图7.31(b)。,图7.31 多对多关联的实现,(4) 关联类的二元关联。存在关联类的二元关联可以分下面几种情况分别处理。 多对多关联。存在关联类多对多的二元关联，需要转化成为两个类分别与所关联类的一对多的关联，在关联类除了保留原有属性之外，再增加另外两个类的关键属性。图7.32(a)中，“书店”和“出版社”两个类之间存在多对多关联，它们的关联类是“订书”。把这个关联分成为图(b)的两个一对多的二元关联，在“订书”类中增加“书店编号”和“出版社编号”两个属性。,图7.32 关联类二元多对多关联的实现, 一对多关联。带有关联类的一对多二元关联实现有如下两种方法。第一种方法是按照一对多无关联类的方法，先实现两个类的关联。然后，再建立关联类与多方类的关联。图7.33(a)中，“系”和“教师”之间存在一对多关联，“考核”是关联类。先在“教师”类中增加“系名”属性，实现“系”和“教师”两个类的单向关联关系。再在关联类“考核”中增加“教师编号”属性，与“教师”类建立起一对一的单向关联(见图7.33(b)。第二种方法是取消关联类，把关联类中的属性增加到多重性为多的类中。通过这种方法从图7.33(a)可以得出图7.33(c)。把“考核”类中的“考核时间”和“考核结果”两个属性增加到“教师”类中。,图7.33 关联类二元一对多关联的实现, 一对一关联。实现一对一的有关联类的关联有如下三种方法。 第一种方法是仍然保持这三个类。如果是单向关联，则在导航源类中增加导航目标类的关键属性，在关联类中增加导航源的关键属性。例如，图7.34(a)中，“系主任”与“系”两个类之间是一对一的单向导航关联。实现时，在“系主任”类中增加“系”类的关键属性“系名”，在关联类“管理”类中增加“系主任”类的关键属性“主任编号”(见图7.34(b)。如果是双向导航，在两方都增加对方的关键属性，在关联类中增加其它两个类任意一个的关键属性。,第二种办法是把关联类合并到其中任意一个类中，成为二元无关联类的关联，见图7.34(c)。 第三种办法是把三个类合成为一个类，见图7.34(d)。,图7.34 关联类二元一对一关联的实现,2) 三元关联的实现 我们假定存在关联类，然后讨论三元关联的实现，这有以下三种方法。 (1) 维持法。该方法是维持三元关联关系不变，三个存在关联关系的类保持不变，给关联类中增加其它三个类的关键属性。例如，图7.35(a)中，“教师”、“班级”和“课程”存在“授课”的三元关联，图(b)是对图(a)中这种关系的实现。,图7.35 维持法实现三元关联,(2) 降元法。降元法是把三元关联首先转化为三个有关联关系的类并分别与关联类的二元关联，再按二元关联的方法实现其关联关系。例如，可以把图7.35(a)的三元关联转化为图7.36的三个二元关联，然后按二元关联的方法实现关联。 (3) 简并法。在三元关联中，如果其中一个类的多重性为1，其它两个为多，则可以用简并法让这个类与关联类形成二元关联，关联性不变。例如，图7.37(b)是用简并法对图7.37(a)的三元关联的实现。,图7.36 降元法实现三元关联,图7.37 简并法实现三元关联,2组成关系设计 一般面向对象程序设计语言都直接提供对组成关系的支持。在定义整体类时，把其部分对象作为整体类的成员，这样就构成了整体与部分的组成关系。因此组成关系的设计十分简单。 3泛化关系设计 所有面向对象程序设计语言都提供继承支持，因此泛化关系本身就被面向对象程序设计语言所支持。但有些语言仅支持单继承，不支持多继承，因此，对设计模型中的多继承要进行必要处理。一种方法是把多继承转化成为单继承，另一种方法是用接口来实现多继承。下面我们介绍用接口来实现多继承的方法。,图7.38是一个多继承的例子。“汽车”继承了“陆上交通工具”和“机动交通工具”两个类(见图7.38(a)。为了让“汽车”能够具有“陆上交通工具”和“机动交通工具”的特性，首先定义“陆上交通工具”和“机动交通工具”的接口，然后在“汽车”类中实现这两个接口，这样就让“汽车”类拥有了“陆上交通工具”和“机动交通工具”的操作(见图7.38(b)。,图7.38 接口实现多继承,7.5.4 类的优化 通过分析和设计所确定的类还需要进一步地进行优化。对类进行优化的原则是使类能够明确地表示事物实体，并具有相对独立性、一致性和适中的规模。在数据库设计中，一般根据规范原则检查关系的优劣，如果一个关系符合范式规约，就可以说该关系是规范的。否则就需要对该关系进行优化处理，通过对关系的分解使其满足范式要求。,规范的类将满足三级规范要求。 一级规范要求在类中不存在重复的属性项； 二级规范是在满足一级规范的基础上，类中不存在对主键属性部分依赖的属性； 三级规范则要求在满足二级规范的基础上，在类中不存在传递依赖关系。 下面我们分三步对由图7.39“图书订单”所产生的“图书订单”类（见图7.40）进行优化。,图7.39 书店信息系统的图书订单,1一级规范 一级规范要求在类中不存在重复的属性。在类中如果存在重复的属性，则需要把所有重复的属性从类中抽取出来，构成一个新类。在图7.40“图书订单”类中，从“计划单序号”到“实际到货日期”8个属性都是重复的。为了符合一级规范的要求，需要把这些属性从“图书订单”类中提取出来，形成新的“订单图书”类(见图7.41)。订单图书是本订单所订购的图书，它是图书订单的有机构成部分，因此，“订单图书”类与“图书订单”类是组成关系。在一个订单中最多可以有20种图书，多重性标为1.20。,图7.40 初步的“图书订单”类,图7.41 一级规范后的“图书订单”类,2二级规范 二级规范要求在类中不存在部分依赖关系的属性，要把不完全依赖关键属性的非关键属性从类中提取出来。在图7.41中，“订单图书”类的关键属性是“订单号”和“书号”，但是“书名”、“作者”、“单价”三个属性则仅依赖“书号”关键属性，存在部分依赖关系，所以需要进行优化。二级规范后的“图书订单”类见图7.42。,图7.42 二级规范后的“图书订单”类,3三级规范 三级规范要求消除在类的属性中存在的传递依赖关系。在“图书订单”类中，“出版社编号”依赖“订单号”，但是从“出版社名称”到“账号”6个属性仅依赖“出版社编号”，并不直接依赖“订单号”，这是典型的传递依赖关系，需要消除。三级规范之后的“图书订单”类见图7.43。,图7.43 三级规范后的“图书订单”类,4进一步优化 图7.43中“图书订单”的属性仍然偏多，并且“合计”和“总计”两个属性属于派生属性，可以去掉。可以把几个费用属性独立出来形成一个新的“订单费用”类，作为“图书订单”类的部分类。这样优化之后的类图见图7.44。,图7.44 “图书订单”优化类图,7.6 数据库设计,7.6.1 概述 数据库设计是指根据业务需求、信息需求和处理需求，确定信息系统中的数据库结构、数据操作和数据一致性约束的过程。 数据库结构分外模式、模式和内模式三级结构。外模式也称用户模式或子模式，是用户所看到的数据视图。模式是综合所有外模式得出的一致的公共数据视图。内模式描述数据的物理结构和存储方式，是数据在数据库系统中的内部表示。,数据库设计的基本过程可分为需求分析、概念设计、逻辑设计和物理设计四个步骤，见图7.45。 需求分析的主要工作是调查和分析用户的业务活动、信息和处理的需求，以及各种约束条件，形成数据库设计的需求说明。在信息系统开发中，一般并不就数据库设计专门进行需求分析，而是在业务分析（见第4章）和需求分析（见第5章）中进行考虑。,图7.45 数据库设计的基本过程,数据库设计的方法与信息系统所采用的开发方法存在着密切的关系，同时还与所采用的数据库模型（包括层次模型、网状模型、关系模型、对象模型等）有关。由于本教材主要介绍采用面向对象方法开发信息系统，同时考虑到关系模型是迄今最为成熟的数据库模型，因此，我们主要讨论采用面向对象方法和关系模型的数据库设计工作。,7.6.2 概念设计 数据库的概念设计是针对现实世界，通过对其中信息实体的收集、分类、聚集和概括，建立数据库概念结构的过程。 概念结构也叫概念数据模型(Conceptual Data Model)，它应该反映现实世界中组织的业务模式、信息结构、信息间的相互制约关系，以及对信息存储、查询和加工的处理要求等。概念数据模型是对数据的抽象描述，它应该独立于具体的数据处理的细节和数据库管理系统。,概念设计一般分为局部视图设计和全局视图集成两个步骤。首先从各部门或用户的角度设计出反映局部实体联系的局部视图(外模式)，然后把各局部视图集成为能够反映组织全貌的全局视图(模式)。 传统方法通常采用实体联系图（ER图）作为概念设计的工具，同时用ER图描述概念数据模型。如果采用UML建模，则可以直接用系统分析和系统设计得到的类图作为概念数据模型。,下面我们分别介绍采用这两种方法所进行的概念设计。 1ER概念设计 1) 局部视图设计 局部视图设计也被称为外模式设计，其任务是从用户角度设计出能反映局部现实空间数据关系的局部概念结构。 局部视图设计的第一步工作是划分局部视图的范围。局部视图范围通常是根据部门、用户或用户所处的角度来进行自然划分。,局部视图设计的第二步工作是识别实体. 局部视图设计的第三步工作是实体分析。实体分析包括实体属性分析和实体关系分析，并用ER图描述实体-关系分析的结果。 在图7.46中，我们给出书店图书销售管理中读者选书的局部视图。由读者从书架的架存图书中上把自己所需要的图书选出来，作为待售图书。架存图书和待售图书与书目存在多对一的关联关系。,图7.46 读者选书的ER图,2) 全局视图设计 全局视图也被称为全局概念结构，它是完整表示一个信息系统的合理、一致的数据库概念结构。全局视图设计需要逐一地把各个局部视图综合成为最终的全局视图。在综合过程中，需要进一步对实体和关系是否作为最终数据存储进行确认，并消除各局部视图之间存在的冲突，得出合理、一致的全局视图。,消除冲突之后的全局视图是概念上不存在矛盾的概念数据库结构， 但它并不一定是合理的概念数据库结构。一个好的全局视图，除了能够准确、全面反映用户的功能需求外，还应该满足实体个数尽可能少、实体的属性尽可能少、实体间的联系无冗余等条件。为了保证其合理性，还需要对全局视图进行优化。图7.47给出了书店图书销售的全局概念结构。,图7.47 书店图书销售全局概念数据库结构(ER),2UML概念设计 UML与ER有本质区别。UML比ER使用范围要宽广得多，它是一种标准的建模语言，可被用来进行软件和信息系统开发的全过程建模，而ER模型仅用在数据库的概念设计阶段。UML与ER都可以用来建立数据库概念模型，但两者的机理完全不同。,由于UML基于面向对象方法，要保持方法的一致性，最好选择面向对象数据库。但是，面向对象数据库目前并没有成熟的产品，即便是采用面向对象方法和环境开发信息系统，仍然需要采用关系型数据库来存储和管理数据。在此，我们主要讨论采用UML建模，用关系型数据库的数据库概念设计，我们简称为UML概念设计。,UML概念设计的基本工作是从系统分析和系统设计建立的各种类图中抽取持久型类，确定持久型类之间的关系，并用类图描述这种关系，把类图作为数据库概念设计的结果。,1) 抽取持久型类 持久型类是指类的完整信息要在数据库中存储的类。类可以分为界面类、实体类和控制类三种类型。界面类和控制类的信息一般不需要长久存储，持久型类只可能是实体类。但并不是所有实体类信息都要长久存储，持久型类只需要从那些信息需要长久存储的实体类中抽取。,2) 确定类关系 在系统分析和设计中，并没有建立立足于整个信息系统的整体类图，而只是建立了一个个针对具体用例的类图。也就是说所提取的持久型类被分散在各个用例类图之中了。接下来需要对提出的持久型类进行分析，以确定它们相互之间的关系，建立起反映这些类关系的类图。根据分析，最终确定出书店销售部分的持久型类关系，如图7.48所示。,图7.48 书店图书销售全局概念数据库结构(UML),7.6.3 逻辑设计 逻辑设计是将现实世界的概念数据模型设计成为适应于特定数据库管理系统的逻辑数据模式。 逻辑数据模式也被简称为逻辑模型或数据模式，关系数据库的数据模式是关系模式。如果数据库采用关系数据库，则需要把ER图或类图描述的概念数据模型转换为等价的关系模式及其约束。 数据库逻辑设计的结果是一组关联的规范关系，一系列经过结构化的业务规则，以及数据库存取的安全性设计。,逻辑设计的基本工作包括： 由概念数据模型导出关系模式； 规范化关系模式； 结构化业务规则； 数据库存取安全性设计。 1由概念数据模型导出关系模式 关系模式的基本内容是一组关联的关系。概念数据模型具有ER图和类图两种形式，下面我们分别介绍这两种形式向关系模式的转换。,1) ER图转换为关系模式 对于用ER图描述的概念数据模型，再转换为关系模式时，需要把ER图中每一个实体或关系转换为关系模式中的一个关系。 例如，可把图7.47书店图书销售的ER图转换为图7.49所示的关系模式。,图7.49 书店图书销售的关系模式(由ER图转换而来),图书销售的ER图中有“书目”、“上架图书”、“架存图书”、“待售图书”、“售出图书”和“职工”六个实体，把它们转换成为关系模式中的六个同名的关系，这六个实体的属性也转换成为关系模式中的同名关系的属性。其中，“上架图书”、“架存图书”、“待售图书”和“售出图书”中的“书号”属性是这几个关系的关键属性，同时又可通过这个属性与“书目”建立起关联关系。“上架图书”、“待售图书”和“售出图书”中的“职工编号”属性与“职工”建立了关联的单向导航关系。,2) 类图转换为关系模式 如果用类图描述概念数据模型，则需要把类图中的每一个类转换为一个关系，类的属性作为关系的属性，在转换时还需要在关系模式中反映类与类之间的关系。 (1) 关联关系的转换。 (2) 组成关系的转换。 (3) 泛化关系的转换。,例如，可把图7.50(a)所示的类图转换成为图(b)所示的关系模式。下面我们分几种情况讨论类之间存在不同关系时，向关系模式转换的方法。,图7.50 一对一关联单向导航转换的关系模式,(1) 关联关系的转换。在7.5.3节的“关联关系设计”中，详细讨论了对类之间关联关系的设计方法。通过关联关系设计之后的类图，所转换而成的关系模式完全能够反映类之间所存在的关联关系。例如，图7.50(b)的两个关系