系统的总体设计课件

第六章系统的总体设计6.1系统设计概述6.2软件体系架构6.3子系统设计和访问控制设计6.4总体设计报告第六章系统的总体设计6.1系统设计概述6.1系统设计概述系统设计包括总体设计和详细设计两部分。系统设计是把分析模型转变成系统设计模型的过程。1．系统设计的目标系统设计的任务是依据系统的逻辑模型，结合实际情况，设计出一个能在计算机系统上实现的具体设计方案，即新系统的物理模型。系统设计的目标应从以下几个方面进行考虑。(1)．系统的可靠性(2)．系统的可维护性(3)．系统的用户友好性(4)．系统的工作效率(5)．系统的合法性下一页返回6.1系统设计概述系统设计包括总体设计和详细设计两部分。系统6.1系统设计概述(6)．系统的经济性2．系统设计的内容系统设计的内容可分为总体设计和详细设计两部分。具体包括如下内容：(1)．系统配置设计设计人员根据系统分析报告中所确定的系统目标、功能、性能、环境与制约条件，确定合适的计算机处理方式及体系结构，确定合适的计算机系统具体配置。(2)．子系统和功能模块设计根据系统分析阶段得到的数据流程图和数据词典，设计出子系统和功能模块结构图，明确它们之间的相互关系。上一页下一页返回6.1系统设计概述(6)．系统的经济性上一页下一页返回6.1系统设计概述(3)．对象设计根据系统分析报告设计出管理信息系统中用到的各种对象，确定对象类型、属性、操作、服务及方法等，并形成对象设计文档。如产品、往来客户、职工及业务处理等各类对象的设计。(4)．数据库设计根据系统分析报告与系统的硬件、软件配置，进行数据库的概念设计、逻辑设计、物理设计，设计出系统有关的数据库文件、数据库结构、存取路径、存取方式等。(5)．输入/输出设计根据系统的目标、用户的使用习惯及使用的方便，确定系统输入的内容、输入格式、输入方式与输入校验;完成系统输出的内容、输出格式及输出方式等内容的具体设计。上一页下一页返回6.1系统设计概述(3)．对象设计根据系统分析报告设计出管理6.1系统设计概述(6)．业务逻辑处理设计对系统中每一业务事项的详细处理过程进行描述，编写业务流程图、处理方法和处理顺序等，作为设计开发详细设计和实现主要依据。(7)．编写系统设计报告根据系统设计阶段所完成的总体设计及详细设计内容，以书面的形式编写符合要求的系统设计报告。系统设计报告既是系统设计阶段的主要成果，经过审查批准后又是系统实施阶段的主要技术依据。以上内容的设计在系统设计阶段是按照一定的先后次序进行的，一般是先进行系统配置设计或系统架构设计，形成系统设计报告。再进行详细设计包括细化对象设计、数据库设计、输入设计、输出设计、模块处理过程设计等具体内容，最后再编写详细设计文档。上一页返回6.1系统设计概述(6)．业务逻辑处理设计对系统中每一业务事6.2软件体系架构随着系统复杂度的增加，系统分解的说明就变得相当关键。一旦开始进行开发，就很难修改或者纠正一个不好的分解，因为这样大多数子系统的接口就必须改动。为了认识到这个问题的重要性，出现了软件体系结构的概念。软件体系结构包括系统分解、全局控制流、错误处理策略和子系统间的通信协议。本节介绍一些典型的不同的体系结构，并简要介绍不同软件体系结构的设计思路。具有代表性的软件体系结构包括仓库体系结构、MVC体系结构、客户/服务器体系结构、B/S结构、对等体系结构和管道过滤器结构等。下一页返回6.2软件体系架构随着系统复杂度的增加，系统分解的说明就变得6.2软件体系架构6.2.1仓库体系结构(RepositoryArchitecture)在仓库体系结构(如图6-1所示)中，子系统通过一个称为中心仓库的单一数据结构访问并修改数据。子系统相对独立而且只通过中心数据结构相互作用。或者通过中心仓库(例如数据中的触发器调用外设)或者通过子系统(例如，通过仓库的锁来实现控制流的独立和同步)来命令控制流。每个子系统只依赖于仓库中心数据结构。而仓库并不清楚其他子系统。对于像工资系统、学籍管理系统和银行系统这样的数据库管理系统来说，仓库体系结构是比较典型的。以数据为中心易于处理子系统间的并发和完整性问题。仓库子系上一页下一页返回6.2软件体系架构6.2.1仓库体系结构(Repositor6.2软件体系架构

统可以实现全局控制流。用户可以调用其中的每个界面，仓库体系结构也适用于处理任务不断改变的复杂的应用系统。但是仓库子系统的主要缺点是子系统与仓库之间耦合度很高，对仓库数据结构的修改必然会影响到子系统。6.6.2模型／视图／控制器体系结构（ModelViewControl--MVCArchitecture）在模型／视图／控制器(MVC)体系结构(见图6-2)中，子系统分为三种不同的类型：模型子系统负责维护系统的数据结构和数据信息；视图子系统负责把系统数据信息显示给用上一页下一页返回6.2软件体系架构 统可以实现全局控制流。用户可以调用其中的6.2软件体系架构

户；控制器子系统负责管理与用户交互的顺序。模型子系统发展成完全不依赖于任何视图或控制器子系统。它们状态的变化通过订阅／通知(subscription／notification)协议传输给视图子系统。MVC体系结构是仓库体系结构的特例，模型实现了中心数据结构，控制对象指挥着控制流。这种体系结构经常用于WEB服务器系统设计。控制器收集来自用户的输入并发消息给模型。模型保持中心数据结构。视图显示模型，每当模型发生变化时得到通知(通过签署／通知协议)。MVC体系结构将交互式应用程序分为三个区域：输入、处理和输出。模型组件封装了内核数据和功能。模型独立于特定输出表示法或输入方式。上一页下一页返回6.2软件体系架构 户；控制器子系统负责管理与用户交互的顺序6.2软件体系架构视图组件子系统向用户显示信息。视图从模型获得数据。可能有模型的多个视图。每个视图都有一个相关的控制器组件。控制器接受输入，通常作为将鼠标移动、鼠标按钮的活动或键盘输入编码的事件。事件被翻译成模型或视图的服务器请求。用户仅仅通过控制器与系统交互。模型与视图和控制器组件的分离将允许同一个模型的多个视图。如果用户通过一个视图的控制器改变了模型，所有依赖于该数据的其他视图应该反映出这种变化。因此一旦模型的数据发生了变化，模型要通报所有视图。视图反过来从模型恢复新数据并更新所显示的信息。这种变更-传播机制相当于订阅—发行。上一页下一页返回6.2软件体系架构视图组件子系统向用户显示信息。视图从模型获6.2软件体系架构模型、视图和控制器之间分离的基本原理在于用户接口(如视图和控制器)要比数据处理(如模型)更加易于变化。因此人机交互从核心功能中分离出来。在分析应用程序结构时，将核心功能从设想的输入和输出行为中分离出来。设计你的应用程序的模型组件来封装内核所需的数据和功能。提供访问中需要显示数据的功能。确定模型功能的哪一部分应该通过控制器向用户展示，并给模型添加相应的接口，这将更便于子系统设计和软件开发分工。MVC技术也适用于交互式系统，尤其是需要同一个模型的多个视图时。MVC可以用来保持分布式数据的一致性；然而，与其他仓库体系结构类似，它也带来了同样的性能瓶颈问题。上一页下一页返回6.2软件体系架构模型、视图和控制器之间分离的基本原理在于用6.2软件体系架构6.2.3客户/服务器体系结构（Client/ServerArchitecture）在客户／服务器体系结构(见图6-3)中，一个子系统即服务器，为其他称为客户的子系统的实例提供服务，客户端系统负责与用户的交互。通常由某个远程程序调用机制或公共对象代理(例如CORBA或JavaRMI)完成请求的服务。除了同步管理请求或者接收结果的时候，客户和服务器中的控制流都是相互独立的。上一页下一页返回6.2软件体系架构6.2.3客户/服务器体系结构（Clien6.2软件体系架构客户向一个或多个服务器请求获得服务。服务器不知道客户。客户／服务器技术是仓库体系结构的一般化，带有中心数据库的信息系统是客户／服务器体系结构的例子。客户负责接收来自用户的输入、检查范围，一旦所有必需的数据齐全，便初始化数据库事务。服务器负责执行事务，保证数据的完整性。在这种情况下，客户／服务器体系结构是仓库体系结构的特例，它由程管理中心数据结构。但是，客户／服务器系统并不限于单个服务器。在Internet网中，单个客户可以访问数千个不同服务器的数据。客户／服务器体系结构非常适用于需要管理大量数据的分布式系统。上一页下一页返回6.2软件体系架构客户向一个或多个服务器请求获得服务。服务器6.2软件体系架构优点：1．结构简单，系统中不同类型的任务分别由客户和服务器承担，有利于发挥不同机器平台的优势；2．支持分布式、并发环境，特别是当客户和服务器之间的关系是多对多时，可以有效地提高资源的利用率和共享程度；3．服务器集中管理资源，有利于权限控制和系统安全。缺点：在大多数client/server风格的系统中，构件之间的连接通过（远程）过程调用，接近于代码一级，表达能力较弱。三层客户／服务器软件体系结构客户／服务器软件体系结构，是基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术，客户上一页下一页返回6.2软件体系架构优点：1．结构简单，系统中不同类型的任务分6.2软件体系架构

／服务器结构将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。客户／服务器体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。但随着企业规模的日益扩大，软件的复杂程度不断提高，传统的二层客户／服务器结构存在以下几个局限：1．二层客户／服务器结构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet；2．软、硬件的组合及集成能力有限；3．客户机的负荷太重，难以管理大量的客户机，系统的性能容易变坏；上一页下一页返回6.2软件体系架构 ／服务器结构将应用一分为二，服务器（后台6.2软件体系架构4．数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。正是因为二层客户／服务器有这么多缺点，所以三层客户／服务器结构应运而生。三层客户／服务器结构是将整个系统的应用功能分成表示层、功能层和数据层三个层次结构，如下图6-4所示。表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，显示应用输出的数据。为使用户能直观地进行操作，一般要使用图形用户接口，操作简单、易学易用。在变更用户接口时，只需上一页下一页返回6.2软件体系架构4．数据安全性不好。因为客户端程序可以直接6.2软件体系架构

改写显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。例如，在制作订购合同时要计算合同金额，按照定好的格式配置数据、打印订购合同，而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。例如，用户检索数据时，要设法将有关检索要求的信息一次性地传送给功能层，而由功能层处理过的检索结果数据也一次性地传送给表示层。数据层就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。上一页下一页返回6.2软件体系架构 改写显示控制和数据检查程序，而不影响其他6.2软件体系架构

因此，一般从功能层传送到数据层的要求大都使用SQL语言。三层客户／服务器的解决方案是：对这三层进行明确分割，并在逻辑上使其独立。原来的数据层作为数据库管理系统已经独立出来，所以，关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。一般情况是只将表示层配置在客户机中，如果连功能层也放在客户机中，与二层客户／服务器结构相比，其程序的可维护性要好得多，但是其他问题并未得到解决。客户机的负荷太重，其业务处理所需的数据要从服务器传给客户机，所以系统的性能容易变坏。上一页下一页返回6.2软件体系架构 因此，一般从功能层传送到数据层的要求大都6.2软件体系架构如果将功能层和数据层分别放在不同的服务器中，则服务器和服务器之间也要进行数据传送。但是，由于在这种形态中三层是分别放在各自不同的硬件系统上的，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。例如，在追加新业务处理时，可以相应增加装载功能层的服务器。因此，系统规模越大这种形态的优点就越显著。与传统的二层结构相比，三层客户／服务器结构具有以下优点：1．允许合理地划分三层结构的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性。2．允许更灵活有效地选用相应的平台和硬件系统，使之在上一页下一页返回6.2软件体系架构如果将功能层和数据层分别放在不同的服务器中6.2软件体系架构逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性。2．允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。例如，最初用一台Unix工作站作为服务器，将数据层和功能层都配置在这台服务器上。随着业务的发展，用户数和数据量逐渐增加，这时，就可以将Unix工作站作为功能层的专用服务器，另外追加一台专用于数据层的服务器。若业务进一步扩大，用户数进一步增加，则可以继续增加功能层的服务器数目，用以分割数据库。清晰、合理地分割三层上一页下一页返回6.2软件体系架构逻辑上保持相对独立性，从而使整个系统的逻辑6.2软件体系架构

结构并使其独立，可以使系统构成的变更非常简单。因此，被分成三层的应用基本上不需要修正。3．三层客户／服务器结构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发，达到较高的性能价格比；对每一层的处理逻辑的开发和维护也会更容易些。4．允许充分利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础；整个系统的管理层次也更加合理和可控制。上一页下一页返回6.2软件体系架构 结构并使其独立，可以使系统构成的变更非常6.2软件体系架构6.2.4B/S结构，即浏览器/服务器(Browser/Server)结构B/S结构，即Browser/Server(浏览器/服务器)结构，是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构（如图6-5所示）。在这种结构下，用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现。B/S结构，主要是利用了不断成熟的WWW浏览器技术，结合浏览器的多种Script语言(VBScript、JavaScript…)和ActiveX技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术，这种结构更成为当今应用软件的首选体系结构。显然B/S结构应用程序相对于传统的C/S结构应用程序将是巨大的进步。上一页下一页返回6.2软件体系架构6.2.4B/S结构，即浏览器/服务器6.2软件体系架构B/S结构采用星形拓扑结构建立企业内部通信网络或利用Internet虚拟专网（VPN）。前者的特点是安全、快捷、准确。后者则具有节省投资、跨地域广的优点。须视企业规模和地理分布确定。企业内部通过防火墙接入Internet，整个网络采用TCP/IP协议。B/S结构开发工作主要是针对于服务器的，并且软件主要的组成全都布署在服务器一方，客户通过浏览访问服务器，并下载或利用一些组件实现客户端的交互访问功能。当前基于Java技术的J2EE和基于DCOM的.NET是开发B/S结构的主流。C/S与B/S区别：上一页下一页返回6.2软件体系架构B/S结构采用星形拓扑结构建立企业内部通信6.2软件体系架构Client/Server是建立在局域网的基础上的，Browser/Server是建立在广域网的基础上的。１．硬件环境不同：C/S一般建立在专用的网络上，小范围里的网络环境，局域网之间再通过专门服务器提供连接和数据交换服务.B/S建立在广域网之上的，不必是专门的网络硬件环境，例与电话上网，租用设备.信息自己管理.有比C/S更强的适应范围，一般只要有操作系统和浏览器就行２．对安全要求不同：C/S一般面向相对固定的用户群，对信息安全的控制能力很强.一般高度机密的信息系统采用C/S结构适宜.可以通过B/S发布部分可公开信息.B/S建立在广域网之上，对安全的控制能力相对弱，面向是不可知的用户群.上一页下一页返回6.2软件体系架构Client/Server是建立在局域网的6.2软件体系架构３．对程序架构不同：C/S程序可以更加注重流程，可以对权限多层次校验，对系统运行速度可以较少考虑.B/S对安全以及访问速度的多重的考虑，建立在需要更加优化的基础之上.比C/S有更高的要求B/S结构的程序架构是发展的趋势，从MS的.Net系列的BizTalk2000Exchange2000等，全面支持网络的构件搭建的系统.SUN和IBM推的JavaBean构件技术等，使B/S更加成熟.４．软件重用不同：C/S程序可以不可避免的整体性考虑，构件的重用性不如在B/S要求下的构件的重用性好.B/S对的多重结构，要求构件相对独立的功能.能够相对较好的重用.就入买来的餐桌可以再利用，而不是做在墙上的石头桌子上一页下一页返回6.2软件体系架构３．对程序架构不同：C/S程序可以更加注重6.2软件体系架构５．系统维护不同：系统维护是软件生存周期中，开销最大，也是极为重要的。C/S程序由于具有整体性，必须整体考察，处理出现的问题以及系统升级应当谨慎，有时系统升级相当于是再做一个全新的系统。B/S构件组成，方面构件个别的更换，实现系统的无缝升级，系统维护开销减到最小，用户从网上自己下载安装就可以实现升级。6.2.5对等体系结构（Peer-to-PeerArchitecture）对等体系结构是客户／服务器体系结构的一般化，其中子系统既可以作为客户也可以作为服务器，即每个子系统既可以请求服务也可以提供服务(如图6-6所示)。每个子系统中的控制流除了在同步请求的时候，都是独立于其他子系统的。上一页下一页返回6.2软件体系架构５．系统维护不同：系统维护是软件生存周期中6.2软件体系架构图6-6是对等体系结构(UML类图)。对等体可以向其他对等体请求服务也可以向它们提供服务。对等体系结构的一个例子是双向通信软件，各系统之间的连接基于对等结构，它一方面接收来自一个系统的请求，另一方面，自己也可以向其他系统要求连通。另一个例子就基于P2P(点对点协议)的应用软件如网络音乐点播软件。对等系统比客户／服务器系统要难设计，它们有可能发生死锁，并且使控制流更复杂了。6.2.6管道过滤器结构（PipeandFilterArchitecture）在管道和过滤器体系结构中，子系统处理输入的一组数据，上一页下一页返回6.2软件体系架构图6-6是对等体系结构(UML类图)。对等6.2软件体系架构

并通过一组输出将结果发送给其他子系统(如图6-7所示)。子系统称为过滤器，子系统之间的联系称为管道。每个过滤器只知道来自输入管道的数据的内容和格式，并不知道生成这些数据的过滤器。每个过滤器并发执行并且通过管道进行同步。管道和过滤器技术是可改动的：一个过滤器可以由其他过滤器替代，或者重新配置以达到不同的目的。一个过滤器可以有多个输入和输出。一个管道将某个过滤器的输出和另外一个过滤器的输入连接起来管道和过滤器体系结构最有名的例子是UNLX的shell。大多数过滤器写成可以通过标准管道进行输入输出的读写。这就允许UNIX用户以许多不同的方式连接过滤器。上一页下一页返回6.2软件体系架构 并通过一组输出将结果发送给其他子系统(如6.2软件体系架构管道和过滤器体系结构适用于实现数据流的变换而不需要用户干涉的系统。不适合组件间的交互作用比较复杂的系统，比如信息管理系统或者交互式系统。管道/过滤器体系结构具有许多很好的特点：1．使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；2．允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；3．支持软件重用。重要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；上一页下一页返回6.2软件体系架构管道和过滤器体系结构适用于实现数据流的变换6.2软件体系架构4．系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；5．允许对一些如吞吐量、死锁等属性的分析；6．支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。但是，这样的系统也存在着不足方面：1．通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。2．不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重。上一页下一页返回6.2软件体系架构4．系统维护和增强系统性能简单。新的过滤器6.2软件体系架构3．因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。以上介绍6个的常见软件体系结构，它们各有不同的特点。在一个复杂的系统开发中，可以借鉴各种多种软件体系结构，如B/S结构也可以结合C/S结构来构建软件系统，灵活运用好体系结构，从而使用软件开发过程更加快捷和高效上一页返回6.2软件体系架构3．因为在数据传输上没有通用的标准，每个过6.3子系统设计和访问控制设计系统设计是把分析模型转变成系统设计模型。在系统设计的过程中，系统设计人员定义项目的设计目标，并且将系统分解成能由单个团队实现的较小的子系统。系统设计人员也要选择构造系统的策略，比如系统运行的硬件／软件平台、持续数据管理策略、全局控制流、访问控制方法以及边界条件的处理。系统设计的结果是得到一个模型，包括上述各个策略的清晰描述、子系统的分解以及表示系统硬件／软件映射的UML配置图。系统设计不是设计算法，然而研究人员已经开发出了一些固定的模式或方案来解决常见的问题，而且定义了符号来表达软件结构，UML就是目前最流行的设计语言之一。在本节下一页返回6.3子系统设计和访问控制设计系统设计是把分析模型转变成系统6.3子系统设计和访问控制设计

中，我们首先提出这些构造模块，然后讨论对这些模块产生影响的设计活动。具体地说，系统设计包括：1．定义设计目标；2．分解系统为子系统或功能模块；3．分析或选择已开发组件和标准组件4．子系统映射到软/硬件平台；5．数据库设计；6．定义访问策略；7．设计系统流程。上一页下一页返回6.3子系统设计和访问控制设计 中，我们首先提出这些构造模块6.3子系统设计和访问控制设计分析模型从执行者的角度完整地描述了系统，并且充当用户和系统分析设计人员之间的交流基础，其分析过程如图6-8所示。但是，分析模型不包括系统的内部结构信息，或者更一般地说，它的硬件配置不包括系统是如何实现的。系统设计是从内部架构整个系统的第一步。6.3.1定义系统设计目标系统设计应该得到如下结果：构建整个软件系统的体系结构，建立一系列反映系统设计人员实现整个系统的设计目标。根据子系统的任务、子系统间相关性、子系统与软/硬件平台的映射和主要策略决定(如控制流、访问控制和数据存储)来描述子系统的分解，这也就是系统设计目标。上一页下一页返回6.3子系统设计和访问控制设计分析模型从执行者的角度完整地描6.3子系统设计和访问控制设计系统设计目标还包括非功能性需求，尤其是需要权衡非功能性需求和系统功能需求的时候，设计目标可以帮助系统设计人员作出决定和取舍。系统设计的大部分内容是子系统分解，即搭建整个系统的框架。为了处理复杂性，系统设计人员把系统分解成易于管理的任务段，把每个子系统分配给一个小组来独立实现。但是为了使这些成为可能，系统设计人员在分解系统时需要面对整个系统范围的问题。设计人员在系统设计中应特别注意解决以下问题：1．应用系统开发的软／硬件平台环境。2．数据库设计3．定义访问策略4．设计系统流程上一页下一页返回6.3子系统设计和访问控制设计系统设计目标还包括非功能性需求6.3子系统设计和访问控制设计图6-8描述了系统设计活动。每个活动解决上面描述过的一个问题。解决任何一个上述问题都会引起子系统分解中的变化并产生新的问题。系统设计是多次反复的活动，常会导致新的子系统的定义、已有子系统的改变以及影响所有子系统系统范围的修改。6.3.2定义子系统和功能模块为了减少应用系统的复杂性，我们把更小的部分定义为类并且把它们封装成包。类似地，为了减少求解域的复杂性，我们将系统分解成为子系统，形成多个较小的组成部分，子系统就是由许多求解域的类组成的。对于复杂的子系统，我们不断地使用这个原理，将子系统分解成更为简单的子系统。上一页下一页返回6.3子系统设计和访问控制设计图6-8描述了系统设计活动。每6.3子系统设计和访问控制设计在RationalRose中子系统要以用包或类来表示。学籍管理系统从需求分析可知整个应用系统分为六个子系统。其中交费管理子系统（如图6-9所示)又可以继续进行细分，因为交费管理主要是用来管理学费的交纳情况，学费可以根据年级、年制、专业、学期不同来设置收费类型和收费标准，所以在收费之前应先设置收费类型和收费标准，在VB中设置收费类型和收费标准可以做为一个单独窗体类来设计，因此可命名为frmTuitionSet，同样收取学费，学费类型明细及查询，学生收费明细，学生个人收费情况，学生收费查询分别设计为frmTuitionCollect、frmTuitionSetBrow、frmTuitionSetQry、frmTuitionDetail、上一页下一页返回6.3子系统设计和访问控制设计在RationalRose中6.3子系统设计和访问控制设计 frmTuitionStu等，由于系统需求中涉及收费打印，因此还要增加学生收费类型设置、学生收费明细报表来满足收费打印的需要。图6-9学籍管理交费子系统(UML类图)的子系统分解包括包的组成和与主界面的构成关系。子系统表示为UML包，虚线箭头说明子系统与其他子系统或类之间的依赖关系。同时为了提高查询效率，快速存取收费信息，也应对收费信息实体类进行设计划分为收费类型和收费明细两部分，相当于数据库中的两个表。如图6-10所示,示学费实体类可以继续分解为数据表，即学费类型表示某年制某专业某年级某学期的收费标准，交费信息表示某学生某学期的交费额和欠费客，以及交费日期和收费人。上一页下一页返回6.3子系统设计和访问控制设计 frmTuitionStu等6.3子系统设计和访问控制设计许多编程语言(比如Java和Modula-2)为子系统的建模(Java中的包，Modula-2中的模块)提供了构造方法。在其他语言中，比如C或者C++，没有明确的建模子系统，在这种情况下，系统设计人员按照习惯，对类进行分组(比如，一个子系统可以表示成包含实现子系统的所有文件的目录)。由于子系统通常是由不同的开发小组实现的，所以不管编程语言中是否明确表示了子系统，系统设计人员都需要仔细地记录子系统分解的文档。1．服务和子系统接口根据一个子系统是通过为其他子系统提供的服务来确定其特点的。一个服务是一组有着共同目标的相关操作。比如，某子系统提供数据访问服务，它可以定义访问数据连接、直接上一页下一页返回6.3子系统设计和访问控制设计许多编程语言(比如Java和M6.3子系统设计和访问控制设计

访问数据表服务，检查用户权限等。学籍管理系统的公用模块就是一个登录管理子系统的一个类似的模块，它为所有的子系统服务的一个子系统，它主要是提供一个访问数据层的接口，定义公用访问数据库的连接，定义全局性的变量和方法供各子系统使用（如图6-11所示）。某子系统提供给其他子系统用的一组操作形成子系统接口。子系统接口也称为应用程序接口(API，ApplicationProgrammingInterface)，包括操作的名称、参数、类型和返回值。系统设计集中定义每个子系统提供的服务，即列举操作、参数和它们的高层行为。对象设计集中定义子系统的接口，即参数的类型和每个操作的返回值。这里也包括应用软件调用操作系统的函数接口。上一页下一页返回6.3子系统设计和访问控制设计 访问数据表服务，检查用户权限6.3子系统设计和访问控制设计以调用Windows系统API的SetWindowPos为例，函数功能：该函数改变一个子窗口，弹出式窗口式顶层窗口的尺寸，位置和Z序。子窗口，弹出式窗口，及顶层窗口根据它们在屏幕上出现的顺序排序、顶层窗口设置的级别最高，并且被设置为Z序的第一个窗口。函数原型：PrivateDeclareFunctionSetWindowPosLib"user32"(ByValhwndAsLong，ByValhWndInsertAfterAsLong，ByValXAsLong，ByValYAsLong，ByValcxAsLong，ByValcyAsLong，ByValwFlagsAsLong)AsLong--上一页下一页返回6.3子系统设计和访问控制设计以调用Windows系统API6.3子系统设计和访问控制设计这样我们就可以方便的实现一个简单的系统功能，因此根据子系统提供的服务来对它进行定义，有助于我们把注意力集中在接口上而不是实现上。一个好的子系统接口应提供尽可能少的实现信息，这就使得修改子系统的实现时产生的影响最小。更一般地来说，我们希望通过减少子系统之间的依赖性来降低变化时的影响。2．子系统耦合度与相关性耦合度是两个子系统之间依赖关系的强度。如果两个子系统是松散耦合的，它们相互独立，那么当其中一个发生变化的时候对另外一个产生的影响就很小。如果两个子系统是紧密耦合的，其中一个发生的变化就可能对另外一个产生较大影响。子系统分解想要达到的一个目标就是子系统间要尽可能地松散耦合，这就使得错误或潜在变化对系统的正确操作产生的影响达到最小。上一页下一页返回6.3子系统设计和访问控制设计这样我们就可以方便的实现一个简6.3子系统设计和访问控制设计例如交费管理子系统和学生档案管理子系统，如果学生入学时既录入学生信息又收取学费则两个子系统的耦合性将增加（如图6-12所示）。相关性是子系统内部的依赖程序。如果某个子系统含有多个彼此相关的对象，并且它们执行类似的任务，它的相关性就比较高。整个系统被化分为更小的系统如学籍管理系统，划分六个子系统为学生档案管理，成绩管理、学费管理、课程管理、班级管理和用户管理等子系统，同时根据系统需求，我们还可以将数据管理抽象到两个子系统中即系统实体子系统和，这样得到的子系统要比原有子系统小：降低了复杂度。子系统之间的耦合度相对较低，因为两个子系统之间上一页下一页返回6.3子系统设计和访问控制设计例如交费管理子系统和学生档案管6.3子系统设计和访问控制设计

只有一个关系。共享大量数据的一种有效的方法就是允许两个子系统通过属性来互相访问。通常在相关性和耦合度之间存在一个平衡。我们可以通过将系统不断分解成子系统来增加系统的相关性。但是，随着接口数量的增加，也会提高耦合度。一般情况下系统设计人员可以处理72个概念。如果给定任一抽象层具有超过9个概念或者有一个子系统提供超过9种服务，则你应该考虑改动子系统的分解。出于同样的原因，层次的数量也不能超出72。事实上，许多好的系统设计只用三层就完成了。3．分层和分区上一页下一页返回6.3子系统设计和访问控制设计 只有一个关系。共享大量数据的6.3子系统设计和访问控制设计系统设计的目标是通过将系统分解成可管理的较小的部分来处理复杂度。这可以通过分而治之的方法解决，即我们循环地将各部分分解得非常简单，直到能让一个人或者一个小组处理为止。系统地使用这个方法就可以得到结构化的分解，其中每个子系统或者每一层根据低层子系统提供的服务为高层服务，每一层还可以向下一层访问。学籍管理系统可以分别为三个层次（如图6-13所示）：（1）．上层的登录管理和主控界面。（2）．中间层为各业务处理子系统。（3）．底层为实体类层和报表层。上一页下一页返回6.3子系统设计和访问控制设计系统设计的目标是通过将系统分解6.3子系统设计和访问控制设计

系统设计是把分析模型转变成设计模型，该模型考虑在问题描述和需求分析文档中描述的非功能性需求和约束。前面主要考虑了子系统的分解和它们的属性。本节描述子系统分解时必要的活动，以确保子系统分解能针对所有的非功能性需求并着手考虑实现阶段的所有限制条件。6.3.3确定系统设计目标前面讲了许多关于系统设计的概念和一般方法，而定义设计目标是系统设计的第一步，那些概念和方法都是为定义设计目标服务。设计目标给出了系统应该重点考虑的质量要求。许多设计目标可以从非功能性需求或者应用域推断出来，上一页下一页返回6.3子系统设计和访问控制设计 系统设计是把分析模型转变成设6.3子系统设计和访问控制设计

其他的设计目标必须从用户那里得到。然而，必须明确说明设计目标，根据同一套标准使作出的每个重要的设计决定，并保持一致性。比如，根据需求描述中的的非功能性需求，我们应把可靠性和连接丢失，容错能力也作为设计目标。然后再将安全性标识为设计目标，因为有很多操作人员利用软件系统读取和存储学生的有关信息。一般而言，我们可以从一系列非常想要达到的质量要求中选择设计目标。通常把系统设计目标分为五类：功能、性能、可靠性、费用和维护目标。一般从需求中推断出系统的功能、性能、可靠性。费用和维护目标则由最终用户（软件系统购买者）和软件供应商（拟采购组件或软件平台供应者）指定。上一页下一页返回6.3子系统设计和访问控制设计 其他的设计目标必须从用户那里6.3子系统设计和访问控制设计性能标准包括对系统的速度和空间需求。系统应该是快速响应的还是实现最多数量的任务？存储器空间是用于速度优化还是应该节约使用？管理目标可以用技术目标平衡(比如，交付时间与功能性的平衡)。一旦我们对设计目标有了清晰的认识，就可以着手设计初始子系统的分解。下表（表6-1）就是针对学籍管理系统的设计目标的一个定义。6.3.4确定子系统在系统设计的时候得到子系统与在分析的时候得到对象有很多相似之处：它是一项不断摸索变化的活动。需求分析上的用例和角色识别技术适用于确定子系统。而且，无论什么时候提出了新的问题，都会导致子系统分解的修改；若干简单上一页下一页返回6.3子系统设计和访问控制设计性能标准包括对系统的速度和空间6.3子系统设计和访问控制设计

的子系统合并到一个子系统中，复杂的子系统分解成多个部分，或为了实现新的功能而增加了子系统。确定子系统的分解要避免引起急剧的变化，并在设计之初就解决好这些问题。最初的子系统分解应该来自功能性需求。比如，在学籍管理系统中，我们定义了学生档案管理、学生成绩管理、收费管理等子系统都是来自需求分析的用例即功能性需求。另外确定子系统的方法就是将功能相关的对象放在一起，作为独立的功能或共享的模块，被多个子系统所共享。再有就是把复杂的子系统分解为较为简单的子系统。确定子系统的方法可归纳为以下几个方面将一个用例中确定的对象，分配到同一个子系统中。上一页下一页返回6.3子系统设计和访问控制设计 的子系统合并到一个子系统中，6.3子系统设计和访问控制设计为两个以上子系统传递数据或提供服务的对象，要创建一个专用的子系统。将子系统与子系统之间的关联关系降到最小。同一个子系统内的所有对象必须功能相关，业务处理配合紧密。6.3.5数据管理设计系统数据管理也是一个复杂的任务，数据管理设计就要处理系统中连续的，需要保存的各种数据。比如，某个作者使用字处理软件将他的工作存入某个文件，以供重新打开文件使用。类似地，与学生相关的信息，他们的姓名、年龄、学费缴纳情况、入学时间和在学期间课程成绩等都存放在数据库上一页下一页返回6.3子系统设计和访问控制设计为两个以上子系统传递数据或提供6.3子系统设计和访问控制设计

管理系统中。这就允许所有使用学生信息数据的程序可以一致地运行。而且，将数据存储在数据库中能让系统在大量数据集合(比如几千个学生的记录)中执行比较复杂的查询。当前的数据存储管理方式可以分为三种类型：1．普通文件2．关系型数据库3．面向对象数据库数据存放的地点以及如何存放会对系统的分解产生影响。比如在有些情况下，学籍管理系统中的某个子系统专门用来建立数据库连接和访问数据。特定的数据库管理系统的选择也蕴含了总的控制策略和并发管理。以学籍管理系统为例，实体类的存储采用关系型数据库如下图6-14所示上一页下一页返回6.3子系统设计和访问控制设计 管理系统中。这就允许所有使用6.3子系统设计和访问控制设计6.3.6定义访问控制在多用户系统中，不同的操作者需要访问不同的功能和数据。比如，每个操作者只能访问他创建的数据，但是系统管理员可以没有限制地访问系统数据和其他用户的数据。分析时，通过将不同的用例与不同的操作者相联系来为这些区别建模。在系统设计时，通过检查对象模型，定义操作者共享哪些对象以及定义操作者如何控制访问来为访问建模。根据系统的安全性需求，还可以定义系统如何鉴别操作者(比如操作人员怎样向系统证明他是谁)及如何为系统中选定的数据加密。比如在学籍管理系统中采用按用户名和密码验证方式登录软件系统，软件系统根据用户的已分配权限，控制其可以使用的上一页下一页返回6.3子系统设计和访问控制设计6.3.6定义访问控制上一页下6.3子系统设计和访问控制设计

功能和操作，用户对系统的功能使用有着各种类型的权限划分，既形成了不同的角色如表6-2所示，系统管理员是整个系统中管理权限最全的角色，它可以使用系统提供的各种功能。而一般人员只能实现对系统中查询功能的使用。6.3.7设计全局控制流控制流是系统中操作和系统行为的先后次序。在面向对象的系统中，活动的先后次序包括决定执行哪些操作，以及按怎样的次序执行。这些决定基于由操作者或者随着按时间顺序所产生的外部事件。控制流是一个设计问题，在分析过程中，控制流程还不是主要问题，但在设计时应考虑整个系统的控制流程。一般控制流程有三种方式包括过程驱动控制、事件驱动控制和线程实现控制。上一页下一页返回6.3子系统设计和访问控制设计 功能和操作，用户对系统的功能6.3子系统设计和访问控制设计过程驱动的控制流程。系统设计是基于过程化语言设计的，或者系统设计是基于程序控制的，用户没有选择的余地，只能按程序控制的步骤来实现各种操作。如Ms-Dos下命令行执行模式中的应用软件程序，再如Windows中添加/删除硬件向导，就是采用过程驱动的方式（如图6-15所示）。事件驱动的控制流。系统设计基于等待与执行的轮循的方式，最常用的Microsoft公司的Word和Excel应用软件，在实际操作中先后次序不明显，而是由用户事件到达次序来选择。即用户选择什么操作，软件做什么回应和处理。以学籍管理系统为例，主控制界面类设计就是典型的事件驱动控制（如图6-16所示）。上一页下一页返回6.3子系统设计和访问控制设计过程驱动的控制流程。系统设计是6.3子系统设计和访问控制设计线程驱动的控制流。系统设计是基于并发运行机制的软件系统，系统可以创建多个线程，每个线程可以处理不同的事件或共同完成一个任务，如Flashget，Netants等许多网络下载软件都采用线程驱动方式。过程驱动控制流方式设计速度快，实现相对简单，测试比较容易，但对用户来说操作不便利，开发与最终用户相关的软件系统应避免采用这种方式；事件驱动的控制流方式便于用户使用，设计较复杂，但有成熟的开发工具，是当前主流的系统控制设计方式；线程实现控制流方式能更好地体现多用户和多任务处理机制，但是在系统实现和系统测试方面则是相当复杂，同时在开发工具和硬件选用上需要仔细斟酌。上一页下一页返回6.3子系统设计和访问控制设计线程驱动的控制流。系统设计是基6.3子系统设计和访问控制设计6.3.8确定系统的功能范围前面讲述了子系统设计和对系统的分解，还需要检查系统的系统功能范围，也就是说，决定系统什么时候启动、初始化和关闭，还要定义如何处理主要故障，比如由软件错误或是由断电引起的数据崩溃，因此还要增加系统管理用例，系统管理用例指定了系统在启动和关闭阶段的行为。通常的情况在分析阶段不指定系统管理用例或者把它们单独处理。一方面，许多系统管理功能可以从日常用户需求(比如注册和删除用户、管理访问控制)中推断出来；另一方面，许多功能是由设计决定的(比如高速缓存的大小、数据库服务器上一页下一页返回6.3子系统设计和访问控制设计6.3.8确定系统的功能范围上6.3子系统设计和访问控制设计

的位置、备份服务器的位置)而不是由需求决定的。如学籍管理管理中应增加重新登录，修改密码及用户名密码长度限制等系统功能。检查系统功能范围时，我们也应该调查一下异常情况。异常就是在系统运行过程中发生的意料外事件或错误。产生异常的原因是下列三种情况之一：1．用户错误。用户错误地或者故意地输入超出边界的数据。比如，如果系统不检查错误的话，学生的年龄、成绩等出现无法预料的错误。2．硬件错误。硬件老化并且发生故障。比如，网络连接故障随时可能会断开系统两个节点之间的联系。硬盘崩溃可能会导致数据的永久性丢失。上一页下一页返回6.3子系统设计和访问控制设计 的位置、备份服务器的位置)而6.3子系统设计和访问控制设计3．软件故障。如果系统或者系统的任何一个组件存在设计错误，则运行中都可能出错。尽管编写无错误的软件非常困难，但是单个子系统能够预料来自其他子系统的错误并加以防护。异常处理就是系统如何处置异常情况的机制。用户发生错误时，系统应该向用户显示意义明确的错误信息，软件系统可以纠正错误的输入。如果是网络连接有问题，需要保存临时状态以便当网络恢复正常时，系统能够回复到原来的状态。因此在系统设计阶段要综合考虑这些因素如在学籍管理系统中增加系统的自动备份功能，软件访问数据的错误处理（OnErrorGotoLineMark<行号或行标签>或OnErrorResumeNext等）机制。上一页下一页返回6.3子系统设计和访问控制设计3．软件故障。如果系统或者系统6.3子系统设计和访问控制设计6.3.9系统配置设计与映射到软/硬件平台1．选择硬件配置和平台许多系统运行在多台计算机上，并且组成局域网Intranet或连接互联网Internet。使用多台计算机提出了对连接的高性能要求，以及如何组织连接多个分散的用户。因此，需要仔细检查计算机子系统的位置并且认真设计支持子系统间通信的基本设施。UML配置图中把这些计算机建模成节点。节点可以表示一个特定的实例(比如计算机A、计算机B、服务器H)，也可以表示一类计算机或设备(比如文件服务器、远程客户机、打印机等)。由于硬件映射活动会对系统的性能和复杂度产生巨大的影响，故我们一般在系统设计的早期进行这项活动。上一页下一页返回6.3子系统设计和访问控制设计6.3.9系统配置设计与映射到6.3子系统设计和访问控制设计选择硬件配置还包括选择将系统建造在怎样的虚拟机上。虚拟机包括操作系统和所有必要的软件组件，比如数据库管理系统和通信包。虚拟设备的选择缩小了系统和系统运行的硬件平台之间的距离。组件提供的功能越多，则涉及的工作越少。但是虚拟设备的选择要受限于项目启动前拥有硬件的顾客。虚拟设备的选择可能还要考虑费用：在有些情况下，很难估计构造一个组件的费用是否比购买一个组件的费用要高。在学籍管理系统中，我们从需求中推断出必备的硬件设备（如图6-17所示），包括教师专用计算机N台、数据库服务器、打印服务器及打印机等。其中学籍管理系统部署在教师专用计算机上，数据库部署在专用的服务器上，打印服务器则不需要上一页下一页返回6.3子系统设计和访问控制设计选择硬件配置还包括选择将系统建6.3子系统设计和访问控制设计

设计开发专用的应用软件，操作系统为Windows系列操作系统，其中服务器要求是WindowsNTServer4.0SP6或最近发布升级的服务器操作系统。2．将对象和子系统分配给节点一旦定义了硬件配置，选定了虚拟机，对象和子系统就被分配给节点。为了在节点间传送数据，经常会定义新的对象和子系统。一般来说，将子系统分配给硬件节点使得我们能够将功能和处理能力分布到最需要它们的地方。但同样也引起了与子系统间存储、传送、复制和同步数据相关的问题。因此，系统设计人员也选择适用的组件和合理的组合关系，用来开发软件系统。上一页下一页返回6.3子系统设计和访问控制设计 设计开发专用的应用软件，操作系统的总体设计课件6.3子系统设计和访问控制设计UML配置图用来描述运行时组件和硬件节点间的关系。组件是为其他组件或执行者提供服务的独立实体。比如，学籍管理系统的组件图根据需求分析，我们以VisualBasic为开发工具，其组件图可设计如下（如图6-18所示），这些为用户提供服务的组件，组成了整个应用软件系统。在UML配置图中，ADO是一组独立的数据访问组件，是微软公司开发可以自由进行发布的。微软公司的ActiveXDataObjects(ADO)使您能够编写通过OLEDB提供者对在数据库服务器中的数据进行访问和操作的应用程序。其主要优点是易于使用、高速度、低内存支出和占用磁盘空间较少。ADO支持用于建立基于客户端/服务器和Web的应用程序的主要功能。另外ADO同时具有远程数据服务上一页下一页返回6.3子系统设计和访问控制设计UML配置图用来描述运行时组件6.3子系统设计和访问控制设计 (RemoteDataService–RDS)功能，通过RDS可以在一次往返过程中实现将数据从服务器移动到客户端应用程序或Web页、在客户端对数据进行处理然后将更新结果返回服务器的操作，以便简化客户端数据的远程操作。VB运行支持库组件是应用程序为在安装后能正确运行而必备的文件。VisualBasic应用程序所用的VB运行支持库包括：Msvbvm60.dll，Stdole2.tlb，Oleaut32.dll，Olepro32.dll，Comcat.dll，Asycfilt.dll，Ctl3d32.dll。打印机驱动程序则由硬件供应厂商来提供，无需另行开发或设计，直接在软件发布期间进行安装调试。上一页下一页返回6.3子系统设计和访问控制设计 (RemoteData6.3子系统设计和访问控制设计图6-19描述了教师专用机节点的组件的位置和组件间依赖关系。教师专用机节点包含了学籍管理系统中的主要组件如主程序、VB运行支持库、ADO组件以及打印机驱动程序等。图6-20描述数据库服务器部署了Access数据库文件，打印服务器部署了打印机驱动程序。硬件节点之间的关系参见图6-17所示。随着系统复杂度的增加和推上市场时间的缩短，开发人员非常愿意复用代码并依靠供应商提供的组件。比如，交互式系统很少从零做起，而宁愿使用那些提供很多对话框、窗口、按钮或其他标准接口对象的用户接口工具包。其他项目只上一页下一页返回6.3子系统设计和访问控制设计图6-19描述了教师专用机节点6.3子系统设计和访问控制设计侧重于重做现有系统的一部分。比如团体信息系统，设计和构建的代价很高，需要升级新的用户硬件。通常只将系统的客户端用新技术升级而系统的后端不动，不管是处理现行组件还是处理遗留下来的代码，开发人员都需要处理现已有的代码，而这些代码他们即无法修改，也无法集成进他们的系统。我们可以通过封装现有组件(如代码)来处理它们。这个方法的优点将系统从封装代码中分离出来，以此减小现有软件对设计的影响。当封装代码与新系统的代码用同一种语言编写时，可以用适配器模式来完成。进程间的通信协议(比如管道和套接字)常常是由操作系统提供的，因此与编程语言无关。对于使用分布式组件和进程上一页下一页返回6.3子系统设计和访问控制设计侧重于重做现有系统的一部分。比6.3子系统设计和访问控制设计

通信的情况，调用服务的开销要比在同一个进程中发送消息的开销高得多。当选定响应时间和其他性能设计目标后，需要仔细评价采购和使用现有组件对整个系统性能所产生的影响。上一页返回6.3子系统设计和访问控制设计 通信的情况，调用服务的开销要6.4总体设计报告系统设计的管理主要挑战在于维护一致性，同时利用尽可能多的资源，系统设计报告(SoftwareDesignedDocument–SDD)就是完整、一致地详细记录系统设计的最新成果，在系统设计的最后阶段，系统设计报告将软件体系结构和系统接口描述成为开发人员能够理解的一个完整而且一致的系统。形成完整的系统设计报告，首先要有记录系统结果的文件模板，其次记录系统设计中的任务分配和系统设计中的各方成果，最后按照一定的结构形成系统设计报告。系统设计报告在初始系统分解时就应该开始编写，而不是在所有的系统设计确定之后才进行编写，设计决策变更或发现问题都要修改系统设计报告，系统设计报告也应有相应的版本控制，记录修改的简要描述、修改的作者、修改的日期等。下一页返回6.4总体设计报告系统设计的管理主要挑战在于维护一致性，同时6.4总体设计报告6.4.1系统设计报告内容系统设计记录在系统设计报告中，它通过项目、子系统分解、硬件／软件映射、数据管理、访问控制、全局控制流机制、功能范围和设计标准等来描述系统设计目标。系统设计报告还用于定义开发小组间的接口，并作为需要重新评价体系结构层次的决策时的参考。系统设计报告的读者包括项目经理、系统设计人员(比如参与系统设计的开发人员)和设计实现每个子系统的开发人员。系统设计报告的具体内容参看附录。6.4.2系统设计报告的不断优化上一页下一页返回6.4总体设计报告6.4.1系统设计报告内容上一页下一页返回6.4总体设计报告与需求阶段一样，系统设计在不断的反复和变化中进行。但是应该控制变化，以避免混乱，尤其是在有多个参与者的复杂项目中。系统设计报告要完整记录系统设计的架构思路、保证体现系统设计的最新版本。由于每个系统设计活动可能同时被启动，系统设计早期的主要决策且会影响子系统的分解，当评估原型用于评估特定问题时，子系统的接口将会发生变化，后期发现的错误和疏漏会引起子系统接口的变化，有时会改变系统分解自身，因此要保证设计报告的不断优化和更新。系统设计报告的优化应注意以下几个方面的问题。1．设计人员掌握整个系统是一个过程，各种定义和模型仍然不断变化，必须以形式或过程为代价最大限度地进行交流。上一页下一页返回6.4总体设计报告与需求阶段一样，系统设计在不断的反复和变化6.4总体设计报告在基于小组的项目中，最初的系统分解通常在完成分析是时就设计好了。分解系统就可以将不同子系统的任务分配给不同的小组，因此系统设计报告优化是一个不断整合的过程，系统报告应能够适应设计的变化，避免将来在详细设计和实现时出现理解上的不一致。2．系统设计报告对于需要解决的困难和关注的问题要进行细致描述和变化跟踪，比如特定供应商的软件产品或技术的选择，子系统是否稳定，特定的包或组件是否适于系统。在此期间，设计人员还应该对关键用例测试其分解的适当性。系统设计报告还可以帮助设计人员尽可能早地发现控制流中的问题并加以解决。上一页下一页返回6.4总体设计报告在基于小组的项目中，最初的系统分解通常在完6.4总体设计报告3．编写系统设计报告也要追踪需求变化，从而减少在开发实现中可能出现的反复纠正。记录设计过程的详细变化，要认真与需求分析人员、开发人员进行交流，修正系统设计中瑕疵，避免在开发过程中出现反复，特别是对子系统记录要保持一定的独立性，避免设计报告中出现混乱。上一页返回6.4总体设计报告3．编写系统设计报告也要追踪需求变化，从而图6-1仓库体系结构的软件系统(UML类图)

返回图6-1仓库体系结构的软件系统(UML类图)返回图6-2模型／视图／控制器体系结构返回图6-2模型／视图／控制器体系结构返回图6-3客户／服务器体系结构返回图6-3客户／服务器体系结构返回图6-4三层C/S结构示意图返回图6-4三层C/S结构示意图返回图6-5B/S结构示意图返回图6-5B/S结构示意图返回图6-6对等体系结构示意图返回图6-6对等体系结构示意图返回图6-7管道和过滤器体系结构(UML类图)

返回子系统3子系统1子系统2过滤器过滤器过滤器管道管道输入输出输入输出图6-7管道和过滤器体系结构(UML类图)返回子系统3子系图6-8系统总体设计活动图返回图6-8系统总体设计活动图返回图6-9学籍管理交费子系统分解返回图6-9学籍管理交费子系统分解返回图6-10学费信息分解示意图返回图6-10学费信息分解示意图返回图6-11服务与子系统接口示意图返回图6-11服务与子系统接口示意图返回图6-12学生交费子系统与学生档案管理子系统示意图返回图6-12学生交费子系统与学生档案管理子系统示意图返回图6-13学籍管理系统的分层设计返回图6-13学籍管理系统的分层设计返回图6-14利用ADO组件进行数据访问存取示意图返回图6-14利用ADO组件进行数据访问存取示意图返回图6-15过程驱动的设计返回图6-15过程驱动的设计返回图6-16学籍管理系统的事件驱动设计示例返回下一页图6-16学籍管理系统的事件驱动设计示例返回下一页图6-16学籍管理系统的事件驱动设计示例返回上一页图6-16学籍管理系统的事件驱动设计示例返回上一页图6-17学籍管理系统硬件配置图返回图6-17学籍管理系统硬件配置图返回图6-18学籍管理系统组件图返回图6-18学籍管理系统组件图返回图6-19含有组件的节点配置图返回图6-19含有组件的节点配置图返回图6-20含有组件的节点配置图返回图6-20含有组件的节点配置图返回表6-1学籍管理系统设计目标明细表返回下一页表6-1学籍管理系统设计目标明细表返回下一页表6-1学籍管理系统设计目标明细表返回上一页表6-1学籍管理系统设计目标明细表返回上一页表6-2学籍管理系统用户访问控制权限明细表返回√:为指定栏目内的全部功能表6-2学籍管理系统用户访问控制权限明细表返回√:为指第六章系统的总体设计6.1系统设计概述6.2软件体系架构6.3子系统设计和访问控制设计6.4总体设计报告第六章系统的总体设计6.1系统设计概述6.1系统设计概述系统设计包括总体设计和详细设计两部分。系统设计是把分析模型转变成系统设计模型的过程。1．系统设计的目标系统设计的任务是依据系统的逻辑模型，结合实际情况，设计出一个能在计算机系统上实现的具体设计方案，即新系统的物理模型。系统设计的目标应从以下几个方面进行考虑。(1)．系统的可靠性(2)．系统的可维护性(3)．系统的用户友好性(4)．系统的工作效率(5)．系统的合法性下一页返回6.1系统设计概述系统设计包括总体设计和详细设计两部分。系统6.1系统设计概述(6)．系统的经济性2．系统设计的内容系统设计的内容可分为总体设计和详细设计两部分。具体包括如下内容：(1)．系统配置设计设计人员根据系统分析报告中所确定的系统目标、功能、性能、环境与制约条件，确定合适的计算机处理方式及体系结构，确定合适的计算机系统具体配置。(2)．子系统和功能模块设计根据系统分析阶段得到的数据流程图和数据词典，设计出子系统和功能模块结构图，明确它们之间的相互关系。上一页下一页返回6.1系统设计概述(6)．系统的经济性上一页下一页返回6.1系统设计概述(3)．对象设计根据系统分析报告设计出管理信息系统中用到的各种对象，确定对象类型、属性、操作、服务及方法等，并形成对象设计文档。如产品、往来客户、职工及业务处理等各类对象的设计。(4)．数据库设计根据系统分析报告与系统的硬件、软件配置，进行数据库的概念设计、逻辑设计、物理设计，设计出系统有关的数据库文件、数据库结构、存取路径、存取方式等。(5)．输入/输出设计根据系统的目标、用户的使用习惯及使用的方便，确定系统输入的内容、输入格式、输入方式与输入校验;完成系统输出的内容、输出格式及输出方式等内容的具体设计。上一页下一页返回6.1系统设计概述(3)．对象设计根据系统分析报告设计出管理6.1系统设计概述(6)．业务逻辑处理设计对系统中每一业务事项的详细处理过程进行描述，编写业务流程图、处理方法和处理顺序等，作为设计开发详细设计和实现主要依据。(7)．编写系统设计报告根据系统设计阶段所完成的总体设计及详细设计内容，以书面的形式编写符合要求的系统设计报告。系统设计报告既是系统设计阶段的主要成果，经过审查批准后又是系统实施阶段的主要技术依据。以上内容的设计在系统设计阶段是按照一定的先后次序进行的，一般是先进行系统配置设计或系统架构设计，形成系统设计报告。再进行详细设计包括细化对象设计、数据库设计、输入设计、输出设计、模块处理过程设计等具体内容，最后再编写详细设计文档。上一页返回6.1系统设计概述(6)．业务逻辑处理设计对系统中每一业务事6.2软件体系架构随着系统复杂度的增加，系统分解的说明就变得相当关键。一旦开始进行开发，就很难修改或者纠正一个不好的分解，因为这样大多数子系统的接口就必须改动。为了认识到这个问题的重要性，出现了软件体系结构的概念。软件体系结构包括系统分解、全局控制流、错误处理策略和子系统间的通信协议。本节介绍一些典型的不同的体系结构，并简要介绍不同软件体系结构的设计思路。具有代表性的软件体系结构包括仓库体系结构、MVC体系结构、客户/服务器体系结构、B/S结构、对等体系结构和管道过滤器结构等。下一页返回6.2软件体系架构随着系统复杂度的增加，系统分解的说明就变得6.2软件体系架构6.2.1仓库体系结构(RepositoryArchitecture)在仓库体系结构(如图6-1所示)中，子系统通过一个称为中心仓库的单一数据结构访问并修改数据。子系统相对独立而且只通过中心数据结构相互作用。或者通过中心仓库(例如数据中的触发器调用外设)或者通过子系统(例如，通过仓库的锁来实现控制流的独立和同步)来命令控制流。每个子系统只依赖于仓库中心数据结构。而仓库并不清楚其他子系统。对于像工资系统、学籍管理系统和银行系统这样的数据库管理系统来说，仓库体系结构是比较典型的。以数据为中心易于处理子系统间的并发和完整性问题。仓库子系上一页下一页返回6.2软件体系架构6.2.1仓库体系结构(Repositor6.2软件体系架构

统可以实现全局控制流。用户可以调用其中的每个界面，仓库体系结构也适用于处理任务不断改变的复杂的应用系统。但是仓库子系统的主要缺点是子系统与仓库之间耦合度很高，对仓库数据结构的修改必然会影响到子系统。6.6.2模型／视图／控制器体系结构（ModelViewControl--MVCArchitecture）在模型／视图／控制器(MVC)体系结构(见图6-2)中，子系统分为三种不同的类型：模型子系统负责维护系统的数据结构和数据信息；视图子系统负责把系统数据信息显示给用上一页下一页返回6.2软件体系架构 统可以实现全局控制流。用户可以调用其中的6.2软件体系架构

户；控制器子系统负责管理与用户交互的顺序。模型子系统发展成完全不依赖于任何视图或控制器子系统。它们状态的变化通过订阅／通知(subscription／notification)协议传输给视图子系统。MVC体系结构是仓库体系结构的特例，模型实现了中心数据结构，控制对象指挥着控制流。这种体系结构经常用于WEB服务器系统设计。控制器收集来自用户的输入并发消息给模型。模型保持中心数据结构。视图显示模型，每当模型发生变化时得到通知(通过签署／通知协议)。MVC体系结构将交互式应用程序分为三个区域：输入、处理和输出。模型组件封装了内核数据和功能。模型独立于特定输出表示法或输入方式。上一页下一页返回6.2软件体系架构 户；控制器子系统负责管理与用户交互的顺序6.2软件体系架构视图组件子系统向用户显示信息。视图从模型获得数据。可能有模型的多个视图。每个视图都有一个相关的控制器组件。控制器接受输入，通常作为将鼠标移动、鼠标按钮的活动或键盘输入编码的事件。事件被翻译成模型或视图的服务器请求。用户仅仅通过控制器与系统交互。模型与视图和控制器组件的分离将允许同一个模型的多个视图。如果用户通过一个视图的控制器改变了模型，所有依赖于该数据的其他视图应该反映出这种变化。因此一旦模型的数据发生了变化，模型要通报所有视图。视图反过来从模型恢复新数据并更新所显示的信息。这种变更-传播机制相当于订阅—发行。上一页下一页返回6.2软件体系架构视图组件子系统向