[toc]

系统分析师笔记13_系统设计

该笔记内容来自《系统分析师教程》第2版。

系统设计概述

系统设计是系统分析的延伸与拓展。系统分析阶段解决“做什么”的问题，而系统设计阶段解决“怎么做”的问题。同时，它也是系统实施的基础，为系统实施工作做好铺垫。合理的系统设计方案既可以保证系统的质量，也可以提高开发效率，确保系统实施工作的顺利进行。

系统设计的主要内容包括概要设计和详细设计。

• 概要设计又称为系统总体结构设计，它是系统开发过程中很关键的一步，其主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。在概要设计中，将系统开发的总任务分解成许多个基本的、具体的任务。
• 而为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计。根据任务的不同，详细设计又可分为多种，例如，网络设计、代码设计、输入/输出设计、处理流程设计、数据存储设计、用户界面设计、安全性和可靠性设计等

处理流程设计

处理流程设计的任务是设计出系统所有模块以及它们之间的相互关系，并具体设计出每个模块内部的功能和处理过程，为开发人员提供详细的技术资料。每个信息系统都包含了一系列核心处理流程。

例如，OA系统的考勤流程、在线教育平台系统的组卷和考试流程、网上购物系统的购物和支付流程、航空订票系统的订票和退票流程等，对这些处理流程的理解和实现将直接影响系统的功能和性能。因此，系统设计人员需要认真面对处理流程的设计，深入理解系统的核心处理流程，通过对业务流程的设计来对现实世界进行建模，及时完善和调整系统分析和设计过程中的遗漏和不合理之处。

流程设计概述

系统处理流程对应于现实世界中的真实业务过程，通过对业务流程的设计，可以对其进行建模，以便使用信息系统来取代传统的手工处理，提高业务处理的效率和准确性，降低业务处理成本。

工作流管理系统（WFMS）

工作流管理系统(WorkFlow Management System，WFMS)通过软件义、创建工作流，并管理其执行。

它运行在一个或多个工作流引擎上，这些引擎解释对过程的定义，并与工作流的参与者相互作用，根据需要调用其他IT工具或应用。例如，将考勤管理、内部信息交流、工作日报或周报处理等工作流管理模块集成在一个软件中，即可得到WFMS系统。

WFMS的基本功能体现在以下几个方面

• (1)对工作流进行建模:即定义工作流，包括具体的活动和规则等，所创建的模型是同时可以被人和计算机所“理解”的，工作流对应现实世界的业务处理过程，不能改变真实业务的处理逻辑。
• (2)工作流执行:遵循工作流模型来创建和执行实际的工作流，即通过WFMS可以执行多个工作项。
• (3)业务过程的管理和分析:监控和管理执行中的业务(工作流)，例如，进度完成情况和数据所处状态、工作分配与均衡情况等。

WFMS的组成

工作流参考模型(Workflow Reference Model，WRM)包含6个基本模块，分别是工作流执行服务、工作流引擎、流程定义工具、客户端应用、调用应用和管理监控工具。

这6个模块被认为是WFMS最基本的组成部分。

流程设计工具

在处理流程设计过程中，为了更清晰地表达过程规则说明，陆续出现了一些用于表示处理流程的工具，这些工具包括三类:图形工具、表格工具和语言工具。

其中常见的图形工具包括程序流程图(Program Flow Diagram，PFD)、IPO图、N-S图(盒图)、问题分析图、判定树，表格工具包括判定表，语言工具包括过程设计语言等。

程序流程图(PFD)

程序流程图用一些图框表示各种操作，它独立于任何一种程序设计语言，比较直观、清晰，易于学习掌握。

流程图中只能包括如图所示的5种基本控制结构，任何复杂的程序流程图都应由这5种基本控制结构组合或嵌套而成。

IPO图

IPO图是由IBM公司发起并逐步完善的一种流程描述工具。

IPO图是系统设计中重要的文档资料之一，其主体是处理过程说明，可以采用流程图、判定树、判定表、盒图、问题分析图或过程设计语言来进行描述。IPO图中的输入、输出与功能模块、文件及系统外部项都需要通过数据字典来描述，同时需要为其中的某些元素添加注释。

IPO基本结构图的示例如图13-3所示。

N-S图(盒图)

在N-S图中也包括5种基本控制结构，分别是顺序型、选择型、当型循环(WHILE循环型)、直到型循环(UNTIL循环型)和多分支选择型。

在N-S图中，过程的作用域明确，N-S图没有箭头，不能随意转移控制，而且容易表示嵌套关系和层次关系，并具有强烈的结构化特征。但是当问题很复杂时，N-S图可能很大。

如图13-4所示，任何一个N-S图都是这5种基本控制结构相互组合与嵌套的结果。

问题分析图(PAD)

问题分析图(PAD)是一种描述详细设计的工具，它由日立公司于1979年提出，也是一种支持结构化程序设计的图形工具。

PAD也包含5种基本控制结构，并允许递归使用，如图13-5所示。

过程设计语言(PDL,结构化语言,伪代码)

过程设计语言(Process Design Language，PDL)也称为结构化语言或伪代码(pseudocode)，它是一种混合语言，采用自然语言的词汇和结构化程序设计语言的语法，用于描述处理过程，类似于编程语言。

过程设计语言用于描述模块中算法和加工逻辑的具体细节，以便在开发人员之间比较精确地进行交流。

判定表

判定树

结构化设计

模块结构

人们在解决复杂问题时使用的一个很重要的原则，就是将它分解成多个小问题分别处理。在处理过程中，需要根据系统总体要求，协调各业务部门的关系。

这种功能分解就是将系统划分为模块，模块是组成系统的基本单位，它的特点是可以自由组合、分解和变换，系统中任何一个处理功能都可以看成一个模块。

耦合

内聚

系统结构图

系统结构图也称为模块结构图，它是软件概要设计阶段的工具，反映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反映了系统的总体结构。

面向对象设计

OOD是O0A方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。在OOD中，数据结构和在数据结构上定义的操作算法封装在一个对象之中。

由于现实世界中的事物都可以抽象成对象的集合，所以OOD方法是一种更接近现实世界、更自然的系统设计方法。

设计软件类

类封装了信息和行为，是面向对象的重要组成部分，它是具有相同属性、方法和关系的对象集合的总称。

在系统中，每个类都具有一定的职责，职责是指类所担任的任务。一个类可以有多种职责，设计得好的类一般至少有一种职责。在定义类时，将类的职责分解为类的属性和方法，其中属性用于封装数据，方法用于封装行为。设

在系统设计过程中，类可以分为三种类型:实体类、控制类和边界类。

实体类

实体类映射需求中的每个实体。实体类保存需要存储在永久存储体中的信息，例如，在线教育平台系统可以提取出学员类和课程类，它们都属于实体类。

实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。

实体类是对用户来说最有意义的类，通常采用业务领域术语命名，一般来说是一个名词。通常情况下，实体类一定有属性，但不一定有操作。

控制类

控制类是用于控制用例工作的类，一般是由动宾结构的短语(“动词+名词”或“名词+动词”)转化来的名词，例如，用例“身份验证”可以对应于一个控制类“身份验证器”，它提供了与身份验证相关的所有操作。

控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象(控制类的实例)通常控制其他对象，因此，它们的行为具有协调性。

控制类将用例的特有行为进行封装，控制对象的行为与特定用例的实现密切相关，当系统执行用例的时候，就产生了一个控制对象，控制对象经常在其对应的用例执行完毕后消亡。通常情况下，控制类没有属性，但一定有方法。

边界类

边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。

边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。常见的边界类有窗口、通信协议、打印机接口、传感器和终端等。实际上，在系统设计时，产生的报表都可以作为边界类来处理。

边界类用于系统接口与系统外部进行交互，边界对象将系统与其外部环境的变更(例如，与其他系统的接口的变更、用户需求的变更等)分隔开，使这些变更不会对系统的其他部分造成影响。通常情况下，边界类可以既有属性也有方法。

对象持久化与数据库

在面向对象开发方法中，对象只能存在于内存中，而内存不能永久保存数据，如果要永久保存对象的状态，需要进行对象的持久化(persistence)，对象持久化是把内存中的对象保存到数据库或可永久保存的存储设备中。

目前，关系数据库是使用最为广泛的数据库，如DB2、Oracle、SQL Server等。关系数据库中存放的是关系数据，即用二维表格表示的数据，它是非面向对象的。

因此，将对象持久化到关系数据库中，需要进行对象/关系的映射(ObjectRelationMapping，ORM)，这是一项非常重要且烦琐耗时的工作。频繁地访问数据库，会对应用的性能造成很大影响，为了降低访问数据库的频率，可以将需要经常被访问的业务数据存放在缓存中，并且通过特定的机制来保证缓存中的数据与数据库中的数据同步。

数据持久化技术封装了数据访问细节，为大部分业务逻辑提供面向对象的API。通过持久化技术，可以减少访问数据库数据的次数，增加应用程序执行速度;其代码重用性高，能够完成大部分数据库操作;松散耦合，使持久化不依赖于底层数据库和上层业务逻辑实现，更换数据库时只需修改配置文件而不用修改代码。

随着对象持久化技术的发展，诞生了越来越多的持久化框架，目前，主流的持久化技术框架包括CMP、Hibernate、iBatis和JDO等。

面向对象设计的原则

常用的面向对象设计原则包括开闭原则、里氏替换原则、依赖倒置原则、组合/聚合复用原则、接口隔离原则和最少知识原则等。

这些设计原则都是面向复用的原则，遵循这些设计原则可以有效地提高系统的复用性，同时提高系统的可维护性。

开闭原则

开闭原则是指软件实体应对扩展开放，而对修改关闭，即尽量在不修改原有代码的情况下进行扩展。此处的“实体”可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。

应用开闭原则可扩展已有的系统，并为之提供新的行为，以满足对软件的新需求，使变化中的系统具有一定的适应性和灵活性。对于已有的软件模块，特别是最重要的抽象层模块不能再修改，这就使变化中的系统有一定的稳定性和延续性，这样的系统同时满足了可复用性与可维护性。

在OOD中，开闭原则一般通过在原有模块中添加抽象层(例如，接口或抽象类)来实现，它也是其他OOD原则的基础，而其他原则是实现开闭原则的具体措施。

里氏替换原则

里氏替换原则其基本思想是，一个软件实体如果使用的是一个基类对象，那么一定适用于其子类对象，而且觉察不出基类对象和子类对象的区别，即把基类都替换成它的子类，程序的行为没有变化。反过来则不一定成立，如果一个软件实体使用的是一个子类对象，那么它不一定适用于基类对象。

在运用里氏替换原则时，尽量将一些需要扩展的类或者存在变化的类设计为抽象类或者接口，并将其作为基类，在程序中尽量使用基类对象进行编程。由于子类继承基类并实现其中的方法，程序运行时，子类对象可以替换基类对象，如果需要对类的行为进行修改，可以扩展基类，增加新的子类，而无须修改调用该基类对象的代码。

依赖倒置原则

依赖倒置原则是指抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。在程序代码中传递参数时或在组合(或聚合)关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明和方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。

为了确保该原则的应用，一个具体类应当只实现接口和抽象类中声明过的方法，而不要给出多余的方法，否则，将无法调用到在子类中增加的新方法。实现开闭原则的关键是抽象化，并且从抽象化导出具体化实现，如果说开闭原则是OOD的目标的话，那么依赖倒置原则就是OOD的主要机制。

有了抽象层，可以使系统具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样，如果系统行为发生变化，则只需要扩展抽象层，并修改配置文件，而无须修改原有系统的源代码，在不修改的情况下来扩展系统功能，满足开闭原则的要求。

依赖倒置原则是COM、CORBA、EJB、Spring等技术和框架背后的基本原则之一。

组合/聚合复用原则

组合/聚合复用原则又称为合成复用原则，是在一个新的对象中通过组合关系或聚合关系来使用一些已有的对象，使之成为新对象的一部分，新对象通过委派调用己有对象的方法达到复用其已有功能的目的。简单地说，就是要尽量使用组合/聚合关系，少用继承。

在OOD中，可以通过两种基本方法在不同的环境中复用已有的设计和实现，即通过组合/聚合关系或通过继承。但首先应该考虑使用组合/聚合，组合/聚合可以使系统更加灵活，类与类之间的耦合度降低，一个类的变化对其他类造成的影响相对较少;其次才考虑继承，在使用继承时，需要严格遵循里氏替换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度，以及系统的复杂度。

通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实现细节暴露给子类，由于基类的内部细节通常对子类来说是透明的，所以这种复用是透明的复用，又称为白盒复用。如果基类发生改变，那么子类的实现也不得不发生改变;从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性;而且继承只能在有限的环境中使用(例如，如果类没有声明就不能被继承)。

由于组合或聚合关系可以将已有的对象(也可称为成员对象)纳入到新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，这样做可以使得成员对象的内部实现细节对于新对象是不可见的，因此，这种复用又称为黑盒复用。相对继承关系而言，其耦合度较低，成员对象的变化对新对象的影响不大，可以在新对象中根据实际需要有选择性地调用成员对象的操作。

组合/聚合复用可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。一般而言，如果两个类之间是Has-A的关系，则应使用组合或聚合;如果是Is-A关系，则可使用继承。

Is-A是严格的分类学意义上的定义，意思是一个类是另一个类的“一种”。而Has-A则不同，它表示某一个角色具有某一项责任。

接口隔离原则

接口隔离原则是指使用多个专门的接口，而不使用单一的总接口。每个接口应该承担一种相对独立的角色，不多不少，不干不该干的事，该干的事都要干。

这里的“接口”通常有两种不同的含义:一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象;另一种是指某种语言具体的接口定义，有严格的定义和结构，例如，Java语言中的interface。对于这两种不同的含义，接口隔离原则的表达方式和含义都有所不同。

如果将“接口”理解成一个类型所提供的所有方法的特征集合，这就是一种逻辑上的概念，接口的划分将直接带来类型的划分。在这种情况下，可以将接口理解成角色，一个接口就只是代表一个角色，每个角色都有它特定的一个接口，此时，接口隔离原则可以称为角色隔离原则。

如果将“接口”理解成狭义的特定语言的接口，接口隔离原则表达的意思则是指接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。

在面向对象编程语言中，如果需要实现一个接口，就需要实现该接口中定义的所有方法。因此，大的总接口使用起来不一定方便，为了使接口的职责单一，需要将大接口中的方法根据其职责不同，分别放在不同的小接口中，以确保每个接口使用起来都较为方便，并都承担单一角色。

最少知识原则

最少知识原则也称为迪米特法则(Law of Demeter)，是指一个软件实体应当尽可能少地与其他实体发生相互作用。这样，当一个模块被修改时，就会尽量少地影响其他的模块，扩展会相对容易。这是对软件实体之间通信的限制，它要求限制软件实体之间通信的宽度和深度。

最少知识原则可分为狭义原则和广义原则。

• 在狭义原则中，如果两个类之间不必彼此直接通信，那么这两个类就不应当发生直接的相互作用;如果其中的一个类需要调用另一个类的某一个方法，可以通过第三者转发这个调用。狭义原则可以降低类之间的耦合，但是会在系统中增加大量的小方法并散落在系统的各个角落。它可以使一个系统的局部设计简化，因为每个局部都不会和远距离的对象有直接的关联，但是也会造成系统的不同模块之间的通信效率降低，使得系统的不同模块之间不容易协调。

• 广义原则是指对对象之间的信息流量、流向和信息的影响的控制，主要是对信息隐藏的控制。信息的隐藏可以使各个子系统之间解耦，从而允许它们独立地被开发、优化、使用和修改，同时可以促进软件的复用。由于每个模块都不依赖于其他模块而存在，因此，每个模块都可以独立地在其他的地方使用。系统的规模越大，信息的隐藏就越重要，而信息隐藏的重要性也就越明显。

最少知识原则的主要用途在于控制信息的过载。在将最少知识原则运用到系统设计中时，要注意以下几点:

• (1)在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用。一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波动。
• (2)在类的结构设计上，每个类都应当尽量降低其属性和方法的访问权限。
• (3)在类的设计上，只要有可能，一个类型应当设计成不变类。
• (4)在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

设计模式

设计模型概述

设计模式是前人经验的总结，它使人们可以方便地复用成功的设计和架构。当人们在特定的环境下遇到特定类型的问题，采用他人已使用过的一些成功的解决方案，一方面可以降低分析、设计和实现的难度，另一方面可以使系统具有更好的可复用性和灵活性。

随着面向对象技术的发展和广泛应用，设计模式不再是一个新兴名词，它已逐步成为系统架构设计师、系统分析师、软件设计师和程序员所需掌握的基本技能之一。设计模式已广泛应用于面向对象系统的设计和开发，成为面向对象领域的一个重要组成部分。

设计模式分类

根据目的和用途不同，设计模式可分为创建型(Creational)模式、结构型(Structural)模式和行为型(Behavioral)模式三种。创建型模式主要用于创建对象，结构型模式主要用于处理类或对象的组合，行为型模式主要用于描述类或对象的交互以及职责的分配。

根据处理范围不同，设计模式可分为类模式和对象模式。类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，属于静态关系。对象模式处理对象之间的关系，这些关系在运行时刻变化，更具动态性。

创建型设计模式

结构型设计模式

行为型设计模式

输入/输出原型设计

系统输入/输出设计可以帮助开发人员更好地理解系统的需求和功能，从而确保系统的正确性和稳定性;可以使系统的代码更加清晰和易于维护，从而降低维护成本和风险;使系统更加灵活和可扩展，从而满足不同用户的需求和变化的市场需求;使系统更加易于使用和友好，从而提高用户的满意度和忠诚度;可以使开发人员更加高效地开发系统，从而降低开发成本和时间。

输入设计

在设计系统输入时，应当遵循以下7种设计原则:

• 确定输入数据的类型和格式
• 确定输入数据的来源
• 设计良好的输入界面
• 设计系统输入验证机制
• 设计输入处理流程
• 设计输入存储方案
• 设计输入安全机制

输出设计

系统的输出设计主要关注如何向用户传达数据和信息，所以在针对系统输出设计方面要遵循下面7条原则。

• 简洁性原则
• 一致性原则
• 可用性原则
• 可访问性原则
• 可维护性原则
• 安全性原则
• 可扩展性原则

人机交互设计

系统人机交互设计是指设计人员将人类使用系统的方式、需求、认知特点等因素考虑在内，开发出易于理解、易于使用、易于操作的用户界面和交互方式。

在系统设计中，人机交互设计是一个非常重要的环节。良好的人机交互设计可以提高用户满意度，减少培训和支持成本，提高系统的可用性和易用性，提高系统的生产力和效率，提高系统的竞争力。

设计目标

具体来说，系统人机交互设计的目标包括:

• (1)切实满足用户的需求，功能有用、内容齐全，对用户有帮助。在任何场景中，都要先确保产品的有用性，这是用户体验的基础。
• (2)产品容易上手和使用，用户用起来易操作、易理解、易学习。易用性即“用户使用成本”，用户使用任何产品都是需要学习、精力、时间等成本的，易用性就是要降低“用户成本”。
• (3)降低用户的错误率和学习成本，使用户能够更容易地掌握系统的使用方法。例如像市场上的商业BI类软件很多系统需要非常专业的知识水平才能使用，无法通过改善优化人机交互的设计从而降低系统的使用门槛。

用户体验五层模型

用户体验是用户在接触和使用产品过程中所建立的感受，感受是主观的，因此用户的体验也是主观的。

用户体验的五层模型由杰西·詹姆斯·加勒特(Jesse James Garrett)在《用户体验要素》里提出。他认为用户体验包含五个要素，可以用五层模型来体现，包括表现层、框架层、结构层、范围层和战略层，如图所示。

如何设计良好的人机交互

• 了解用户需求
• 设计交互界面
• 提供即时反馈机制
• 提供辅助功能
• 用户测试
• 迭代优化设计
• 多语言支持
• 与实际应用场景相结合
• 适当地使用动画效果
• 适当地使用新理念和新技术