软件工程-系统设计工程

Posted 2021-07-17 小毕超

一、系统建模过程

二、系统设计

1. 系统设计过程 - 概要设计包括

   总体设计

   总体布局设计

   网络拓扑结构设计

   资源配置设计

   模块化结构设计

   划分功能模块

   模块功能和职责

   模块间的调用关系

   模块间的信息传递

2. 系统设计过程 - 详细设计

   代码设计：是信息分类和编码的工作，是将系统中有某些共同属性或特征的信息归并在一起，并利用便于计算机和人识别和处理的符号来表示这些信息的设计工作。

   数据库设计：构建既能客观、准确地反映外部世界，又便于人类大脑认识的概念模型，并在此基础上对数据进行建模，转化为数据库管理系统所支持的数据模型；选择合适的存储结构和存储方法，最终完成数据库的设计工作。

   输入/输出设计：输入/输出设计主要是对以记录为单位的各种输入输出报表格式的描述。另外，对人机对话格式的设计和输入输出装置的选择也在这一步完成。

   用户界面设计：用户界面设计是指用户与系统之间架起一座桥梁，主要内容包括：定义界面形式、定义基本的交互控制形成、定义图形和符号、定义通用的功能键和组合键的含义及其操作内容、定义帮助策略等。

   处理过程设计：定义每个模块的内部执行过程，包括数据的组织、控制流、每一步的具体加工要求和实施细节。

三、人机界面设计⭐

用户界面设计是指用户与系统之间架起一座桥梁，主要内容包括：定义界面形式、定义基本的交互控制形成、定义图形和符号、定义通用的功能键和组合键的含义及其操作内容、定义帮助策略等。

四、结构化设计⭐

1. 特点

   抽象化、自顶而下、逐步求精、信息隐蔽、模块独立（高内聚、低耦合）

   结构化程序设计的三种基本控制结构就是：顺序、分支和循环。

2. 功能模块设计的原则

   模块大小适中：50~100 行，最多不超过 500 行。

   适宜的系统深度和宽度比例，尽可能减少调用的深度。

   适度控制模块的扇入扇出：扇出 3~4 一般不超过 7，扇入越大越好。

   单入口，单出口。

   模块的作用域应该在模块之内。

   功能应该是可预测的。

   高内聚低耦合。

   系统分解有层次。

   较小的数据冗余。

3. 模块独立性的度量

   （1）聚合：衡量模块内部各元素结合的紧密程度

   偶然聚合：模块完成的动作之间没有任何关系，或者仅仅是一种非常松散的关系。

   逻辑聚合：模块内部的各个组成在逻辑上具有相似的处理动作，但功能用途上彼此无关。

   时间聚合：模块内部的各个组成部分所包含的处理动作必须在同一时间内执行。

   过程聚合：模块内部各个组成部分所要完成的动作虽然没有关系，但必须按特定的次序执行。

   通信聚合：模块的各个组成部分所完成的动作都使用了同一个数据或产生同一输出数据。

   顺序聚合：模块内部的各个部分，前一部分处理动作的最后输出是后一部分处理动作的输入。

   功能聚合：模块内部各个部分全部属于一个整体，并执行同一功能，且各部分对实现该功能都比不可少

   （2）耦合：度量不同模块间互相依赖的程度

   非直接耦合：两个模块之间没有直接关系，它们的联系完全是通过主模块的控制和调用来实现的。

   数据耦合：两个模块彼此间通过数据参数交换信息。

   标记耦合：一组模块通过参数表传递记录信息，这个记录是某一个数据结构的子结构，而不是简单变量。

   控制耦合：两个模块彼此间传递的信息中有控制信息。

   外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息。

   公共耦合：两个模块之间通过一个公共的数据区域传递信息。

   内容耦合：一个模块需要涉及到另一个模块的内部信息。

五、面向对象设计⭐⭐⭐⭐⭐

1. 设计原则

   单一职责原则：设计目的单一的类

   开放-封闭原则：对扩展开放，对修改封闭

   李氏(Liskov)替换原则：子类可以替换父类

   依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程接口隔离原则：使用多个专门的接口比使用单一的总接口要好组合重用原则：要尽量使用组合，而不是继承关系达到重用目的

   迪米特(Demeter)原则(最少知识法则)：一个对象应当对其他对象有尽可能少的了解

六、面向对象设计 - 设计模式

1. 概念

   架构模式：软件设计中的高层决策，例如 C/S 结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策

   设计模式：主要关注软件系统的设计，与具体的实现语言无关

   惯用法：是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。例如引用-计数就是 C++语言中的一种惯用法。

2. 设计模式分类

   创建型模式：与对象的创建有关，抽象了实例化过程，它们帮助一个系统独立于如何创建、组合和表示它的那些对象。一个类创建型模式使用继承改变被实例化的类，而一个对象创建型模式将实例化委托给另一个对象。

   结构型模式：处理类或对象的组合，结构型设计模式涉及如何组合类和对象以获得更大的结构。结构型类模式采用继承机制来组合接口或实现。结构型对象模式不是对接口和实现进行组合，而是描述了如何对一些对象进行组合，从而实现新功能的一些方法。

   行为型模式：涉及算法和对象间职责的分配。行为模式不仅描述对象或类的模式，还描述它们之间的通信模式。行为型类模式使用继承机制在类间分配行为，这里包括模板类模式和解释器类模式。行为对象模式使用对象复合而不是继承。一些行为对象模式描述了一组对等的对象怎样相互协作以完成其中任一对象都无法单独完成的任务。
   
   创建型模式
   
   结构型模式
   
   行为型模式
   
   

实体类

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

控制类

控制类是用于控制用例工作的类，一般是由动宾结构的短语（“动词+名词”或“名词+动词”）转化来的名词，例如，用例“身份验证”可以对应于一个控制类“身份验证器”，它提供了与身份验证相关的所有操作。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象（控制类的实例）通常控制其他对象，因此，它们的行为具有协调性。
控制类将用例的特有行为进行封装，控制对象的行为与特定用例的实现密切相关，当系统执行用例的时候，就产生了一个控制对象，控制对象经常在其对应的用例执行完毕后消亡。通常情况下，控制类没有属性，但一定有方法。

边界类

边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。要寻找和定义边界类，可以检查用例模型，每个参与者和用例交互至少要有一个边界类，边界类使参与者能与系统交互。边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。常见的边界类有窗口、通信协议、打印机接口、传感器和终端等。实际上，在系统设计时，产生的报表都可以作为边界类来处理。
边界类用于系统接口与系统外部进行交互，边界对象将系统与其外部环境的变更（例如，与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分造成影响。通常情况下，边界类可以既有属性也有方法。

七、扩展

软件设计包括了四个即独立又相互联系的活动：高质量的数据设计将改善程序结构和模块划分，降低过程复杂度；软件结构设计的主要目标是开发一个模块化的程序结构，并表示出模块间的控制关系；人机界面设计描述了软件与用户之间的交互关系。