目录

前言：系统集成项目管理工程师专业，现分享一些教材知识点。觉得文章还不错的喜欢点赞收藏的同时帮忙点点关注。 

  5.3软件设计

5.3.1结构化设计

1.模块结构

2.系统结构图

5.3.2面向对象设计

1.实体类

2.控制类

3.边界类

5.3.3统一建模语言

1.UML中的事物

2.UML中的关系

3.UML2.0中的图

4.UML视图

5.3.4设计模式

  5.3软件设计

      软件设计的目标是根据软件分析的结果，完成软件构建的过程。其主要目的是绘制软件的蓝 图，权衡和比较各种技术和实施方法的利弊，合理分配各种资源，构建新的详细设计方案和相关模 型，指导软件实施工作的顺利开展。

      软件设计是需求的延伸与拓展。需求阶段解决“做什么 ”的问题，而软件设计阶段解决“怎么 做 ”的问题。同时，它也是系统实施的基础，为系统实施工作做好铺垫。合理的软件设计方案既可 以保证软件的质量，也可以提高开发效率，确保软件实施工作的顺利进行。从方法上来说，软件设 计分为结构化设计与面向对象设计。

5.3.1结构化设计

      结构化设计（Structured Design ，SD）是一种面向数据流的方法，其目的在于确定软件结构。 它以SRS和SA阶段所产生的DFD和数据字典等文档为基础，是一个自顶向下、逐层分解、逐步求精 和模块化的过程。SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结 构。从管理角度讲，其分为概要设计和详细设计两个阶段。其中，概要设计又称为总体结构设计， 它是开发过程中很关键的一步，其主要任务是确定软件系统的结构，将系统的功能需求进行模块划 分，确定每个模块的功能、接口和模块之间的调用关系，形成软件的模块结构图，即系统结构图。 在概要设计中，将系统开发的总任务分解成许多个基本的、具体的任务，而为每个具体任务选择适 当的技术手段和处理方法的过程称为详细设计。详细设计的主要任务是为每个模块设计实现的细 节，根据任务的不同，详细设计又可分为多种，例如，输入/输出设计、处理流程设计、数据存储设计、用户界面设计、安全性和可靠性设计等。（ 中23下）

1.模块结构

      系统是一个整体，它具有整体性的目标和功能，但这些目标和功能的实现又是由相互联系的各 个组成部分共同工作的结果。人们在解决复杂问题时使用的一个很重要的原则，就是将它分解成多 个小问题分别处理，在处理过程中，需要根据系统总体要求，协调各业务部门的关系。在SD中， 这种功能分解就是将系统划分为模块，模块是组成系统的基本单位，它的特点是可以自由组合、分 解和变换，系统中任何一个处理功能都可以看成一个模块。

（1）信息隐藏与抽象。信息隐藏原则要求采用封装技术，将程序模块的实现细节（过程或数据 等）隐藏起来，对于不需要这些信息的其他模块来说是不能访问的，使模块接口尽量简单。按照信 息隐藏的原则，系统中的模块应设计成“黑盒 ”，模块外部只能使用模块接口说明中给出的信息， 如操作和数据类型等。模块之间相对独立，既易于实现，也易于理解和维护。抽象原则要求抽取事 物最基本的特性和行为，参见本章5.2.4小节中关于抽象的说明。

（2）模块化。在SD方法中，模块是实现功能的基本单位，它一般具有功能、逻辑和状态3个基 本属性。其中，功能是指该模块“做什么 ”，逻辑是描述模块内部“怎么做 ”，状态是该模块使用 时的环境和条件。在描述一个模块时，必须按模块的外部特性与内部特性分别描述。模块的外部特 性是指模块的模块名、参数表和给程序乃至整个系统造成的影响；模块的内部特性则是指完成其功 能的程序代码和仅供该模块内部使用的数据。对于模块的外部环境（例如，需要调用这个模块的上 级模块）来说，只需要了解这个模块的外部特性就足够了，不必了解它的内部特性。而软件设计阶 段，通常是先确定模块的外部特性，然后再确定它的内部特性。

（3）耦合。耦合表示模块之间联系的程度。紧密耦合表示模块之间联系非常强，松散耦合表示 模块之间联系比较弱，非直接耦合则表示模块之间无任何直接联系。模块的耦合类型通常分为7 种，根据耦合度从低到高排序如表5-1所示。

表5-1:模块的耦合类型

      对于模块之间耦合的强度，主要依赖于一个模块对另一个模块的调用、一个模块向另一个模块 传递的数据量、一个模块施加到另一个模块的控制的多少， 以及模块之间接口的复杂程度等。

（4） 内聚。 内聚表示模块内部各代码成分之间联系的紧密程度，是从功能角度来度量模块内的 联系，一个好的内聚模块应当恰好做目标单一的一件事情。模块的内聚类型通常也可以分为7种， 根据内聚度从高到低排序如表5-2所示。

表5-2:模块的内聚类型

      一般来说，系统中各模块的内聚越高，则模块间的耦合就越低，但这种关系并不是绝对的。耦 合低使得模块间尽可能相对独立，各模块可以单独开发和维护； 内聚高使得模块的可理解性和维护 性大大增强。因此，在模块的分解中应尽量减少模块的耦合，力求增加模块的内聚，遵循“高内 聚、低耦合 ”的设计原则。

2.系统结构图

      系统结构图（Structure Chart ，SC）又称为模块结构图，它是软件概要设计阶段的工具，反映 系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反映了系统的总体结 构。在系统分析阶段，系统分析师可以采用SA方法获取由DFD 、数据字典和加工说明等组成的系 统的逻辑模型；在系统设计阶段，系统设计师可根据一些规则，从DFD中导出系统初始的SC。

●分析并确定输入/输出数据的逻辑结构；

●找出输入数据结构和输出数据结构中有对应关系的数据单元；

●按一定的规则由输入、输出的数据结构导出程序结构；

●列出基本操作与条件，并把它们分配到程序结构图的适当位置；

●用伪码写出程序。

详细设计的表示工具有图形工具、表格工具和语言工具。

（1）图形工具。利用图形工具可以把过程的细节用图形描述出来。具体的图形有业务流程图、 程序流程图、问题分析图（Problem Analysis  Diagram ，PAD）、NS流程图（由Nassi和Shneiderman 开发，简称NS）等。

●业务流程图：是一种描述管理系统内各单位、人员之间的业务关系、作业顺序和管理信息流  向的图表。业务流程图的绘制是按照业务的实际处理步骤和过程进行的，它用一些规定的符号及连 线表示某个具体业务的处理过程，帮助分析人员找出业务流中的不合理流向。

●程序流程图：又称为程序框图，是使用最广泛的一种描述程序逻辑结构的工具。它用方框表 示一个处理步骤，用菱形表示一个逻辑条件，用箭头表示控制流向。其优点是结构清晰，易于理  解，易于修改；缺点是只能描述执行过程而不能描述有关的数据。

●NS流程图：也称为盒图或方框图，是一种强制使用结构化构造的图示工具。其具有以下特

点：功能域明确，不可能任意转移控制，很容易确定局部和全局数据的作用域，很容易表示嵌套关 系及模板的层次关系。

●PAD图：是一种改进的图形描述方式，可以用来取代程序流程图，比程序流程图更直观，结 构更清晰。最大的优点是能够反映和描述自顶向下的历史和过程。PAD提供了5种基本控制结构的 图示，并允许递归使用。

（2）表格工具。可以用一张表来描述过程的细节，在这张表中列出了各种可能的操作和相应的 条件。

（3）语言工具。用某种高级语言来描述过程的细节，例如伪码或PDL（Program DesignLanguage）等。PDL也可称为伪码或结构化语言，它用于描述模块内部的具体算法，以便开发人员之间比较精确地进行交流。语法是开放式的，其外层语法是确定的，而内层语法则不确定。外层语 法描述控制结构，它用类似于一般编程语言控制结构的关键字表示，所以是确定的。内层语法描述 具体操作，考虑到不同软件系统的实际操作种类繁多， 内层语法因而不确定，它可以按系统的具体 情况和不同的设计层次灵活选用。

●PDL的优点：可以作为注释直接插在源程序中；可以使用普通的文本编辑工具或文字处理工 具产生和管理； 已经有自动处理程序存在，而且可以自动由PDL生成程序代码。

●PDL的不足：不如图形工具形象直观，描述复杂的条件组合与动作间的对应关系时不如判定 树清晰简单。

5.3.2面向对象设计

      面向对象设计（Object-Oriented Design ，OOD）是OOA方法的延续，其基本思想包括抽象、封 装和可扩展性，其中可扩展性主要通过继承和多态来实现。在OOD中，数据结构和在数据结构上 定义的操作算法封装在一个对象之中 。 由于现实世界中的事物都可以抽象出对象的集合，所以 OOD方法是一种更接近现实世界、更自然的软件设计方法。

      OOD的主要任务是对类和对象进行设计，这是OOD中最重要的组成部分，也是最复杂和最耗 时的部分。其主要包括类的属性、方法， 以及类与类之间的关系。OOD的结果就是设计模型。对 于OOD而言，在支持可维护性的同时，提高软件的可复用性是一个至关重要的问题，如何同时提 高软件的可维护性和可复用性，是OOD需要解决的核心问题之一。在OOD中，可维护性的复用是 以设计原则为基础的。

常用的OOD原则包括：

●单职原则：一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。

●开闭原则：对扩展开放，对修改封闭。当应用的需求改变时，在不修改软件实体的源代码或 者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

●里氏替换原则：子类可以替换父类，即子类可以扩展父类的功能，但不能改变父类原有的功 能。

●依赖倒置原则：要依赖于抽象，而不是具体实现；要针对接口编程，不要针对实现编程。

●接口隔离原则：使用多个专门的接口比使用单一的总接口要好。

●组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。

●迪米特原则（ 最少知识法则）：一个对象应当对其他对象有尽可能少的了解。其目的是降低 类之间的耦合度，提高模块的相对独立性。（ 高23上）

在OOD中，类可以分为3种类型：实体类、控制类和边界类。

1.实体类

      实体类映射需求中的每个实体，是指实体类保存需要存储在永久存储体中的信息。例如，在线 教育平台系统可以提取出学员类和课程类，它们都属于实体类。实体类通常都是永久性的，它们所 具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。实体类对用户来说是最有 意义的类，通常采用业务领域术语命名，一般来说是一个名词，在用例模型向领域模型的转换中， 一个参与者一般对应于实体类。通常可以从SRS中的那些与数据库表（需要持久存储）对应的名词 着手来找寻实体类。通常情况下，实体类一定有属性，但不一定有操作。

2.控制类

      控制类是用于控制用例工作的类，一般是由动宾结构的短语（ “动词+ 名词 ”或“名词+动 词 ”）转化来的名词。例如，用例“身份验证 ”可以对应于一个控制类“身份验证器 ”，它提供了 与身份验证相关的所有操作。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象 （控制类的实例）通常控制其他对象，因此，它们的行为具有协调性。

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

3.边界类

      边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所 有窗体、报表、打印机和扫描仪等硬件的接口， 以及与其他系统的接口。要寻找和定义边界类，可 以检查用例模型，每个参与者和用例交互至少要有一个边界类，边界类使参与者能与系统交互。边 界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。常见的边界类有窗口、通 信协议、打印机接口、传感器和终端等。实际上，在系统设计时，产生的报表都可以作为边界类来 处理。

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

5.3.3统一建模语言

      统一建模语言（Unified Modeling Language ，UML）是一种定义良好、易于表达、功能强大且 普遍适用的建模语言（ 中23下2次、23上） 。它融入了软件工程领域的新思想、新方法和新技术， 它的作用域不仅支持OOA（面向对象分析法）和OOD（面向对象设计） ，还支持从需求分析开始 的软件开发的全过程（ 高18上）。从总体上来看，UML的结构包括构造块、规则和公共机制3个部分，如表5-3所示。

表5-3：UML的结构

1.UML中的事物

       UML中的事物也称为建模元素，包括结构事物（Structural Things） 、行为事物（Behavioral Things ，也称动作事物）、分组事物（Grouping Things）和注释事物（Annotational Things ，也称注 解事物）。这些事物是UML模型中最基本的OO（面向对象）构造块，如表5-4所示。

表5-4：UML中的事物

2.UML中的关系

       UML用关系把事物结合在一起，主要有4种关系：依赖、关联、泛化和实现。

（1）依赖（Dependency） 。依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另 一个事物的语义。

（2）关联（Association）。关联是指一种对象和另一种对象有联系。

（3）泛化（Generalization）。泛化是一般元素和特殊元素之间的分类关系，描述特殊元素的对 象可替换一般元素的对象。

（4）实现（Realization）。实现将不同的模型元素（例如，类）连接起来，其中的一个类指定 了由另一个类保证执行的契约。

3.UML2.0中的图

       UML2.0包括14种图，如表5-5所示。

表5-5：UML2.0中的图

4.UML视图

       UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分， 以及它们的关联性、 交互机制和指导原则等提供系统设计的信息。具体来说，就是指逻辑视图、进程视图、实现视图、 部署视图和用例视图这5个系统视图。

（1）逻辑视图。逻辑视图也称为设计视图，它用系统静态结构和动态行为来展示系统内部的功 能是如何实现的，其侧重点在于如何得到功能。它表示了设计模型中在架构方面具有重要意义的部 分，即类、子系统、包和用例实现的子集。

（2）进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实 例，描述了并发与同步结构。

（3）实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。

（4）部署视图。部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构：

（5）用例视图。用例视图是最基本的需求分析模型。它从外部角色的视角来展示系统功能。 另外，UML还允许在一定的阶段隐藏模型的某些元素、遗漏某些元素， 以及不保证模型的完

整性，但模型要逐步地达到完整和一致。

5.3.4设计模式

       设计模式是前人经验的总结，它使人们可以方便地复用成功的软件设计。当人们在特定的环境 下遇到特定类型的问题，采用他人已使用过的一些成功的解决方案，一方面可以降低分析、设计和 实现的难度，另一方面可以使系统具有更好的可复用性和灵活性。设计模式包含模式名称、问题、 目的、解决方案、效果、实例代码和相关设计模式等基本要素。

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

       根据目的和用途不同，设计模式可分为创建型（Creational）模式、结构型（Structural）模式 和行为型（Behavioral）模式3种。创建型模式主要用于创建对象，包括工厂方法模式、抽象工厂模 式、原型模式、单例模式和建造者模式等；结构型模式主要用于处理类或对象的组合，包括适配器 模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等；行为型模式主要用于描述类或对象的交互以及职责的分配，包括职责链模式、命令模式、解释器模式、迭代器模式、中 介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等。