软件工程复习（三）

栩xx

已于 2022-07-04 16:29:24 修改

阅读量1k

点赞数 2

文章标签：软件工程

于 2022-07-02 17:13:01 首次发布

本文链接：https://blog.csdn.net/qq_45767764/article/details/125514209

版权

第7章理解需求

7.1 需求工程

对期望的软件行为的表达
分为功能需求、非功能需求：
- 功能需求——描述系统预期提供的功能或服务
  - 系统应提供的服务
  - 系统如何对输入做出反应
  - 系统在特定条件下的行为
  - 系统不应该做什么
  - 数据
- 非功能需求：不直接与系统具体功能相关的需求
  - 产品需求：产品行为的需求包括性能需求、可靠性需求和可用性需求等
  - 机构需求：客户和开发者所在机构中的政策和规定要求，如过程标准、实现要求、交付需求
  - 外部需求：所有的系统外部因素要求，如互操作需求、道德需求

需求工程是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通活动并持续建模活动。
需求工程在设计和构建之间建立起联系的桥梁：

由软件团队检查将要进行的软件工作的内容
必须提交设计和构建的特定要求
完成指导工作顺序的优先级定义
会影响随后设计的信息、功能和行为

两种需求过程

瀑布式需求
- 项目早期完全确定需求
进化式需求
- 结合迭代开发，持续地寻找、记录、组织和跟踪不断变更的需求

两种需求文档
1.需求定义：客户要求的完整列表（对外）
通常由客户和需求分析师一起编写，是开发人员对系统功能的一个合同，主要给客户阅读
2.需求规格说明：要构建系统的规格化说明（对内）
由需求分析师编写，并由其他软件开发人员使用

软件需求规格说明（SRS）
详细描述软件各个方面的文档
规格说明模板
在这里插入图片描述

7.2 建立根基

启动需求工程的步骤

确认利益相关者
- 利益相关者：定义为直接或间接地从正在开发的系统中获益的人
识别多重观点
- 因为存在很多不同的利益相关者，所以系统需求调研也将从很多不同的视角开展
协同工作
- 需求工程师的工作是标识公共区域（即所有利益相关者都同意的需求）和矛盾区域或不一致区域（即某个利益相关者提出的需求和其他利益相关者的需求相矛盾）
首次提问

7.3 获取需求

需求获取（又称需求收集）将问题求解、细化、协商和规格说明等方面的元素结合在一起。

协作收集需求
在这里插入图片描述
目的是识别问题，确定初步方案

质量功能部署
质量功能部署（Quality Function Deployment,QFD）是一种将客户要求转化成软件技术需求的质量管理技术
QFD目的是最大限度地让客户从软件工程过程中感到满意
QFD确认了三类需求
- 正常需求
这些需求反映了在和客户开会时确定的针对某产品或系统的目标。如果实现了这些需求，将满足客户。
如特定的系统功能以及已定义的性能级别
- 期望需求
这些需求隐含在产品或系统中，并且可能是非常基础的以至于客户没有显式地说明，但是缺少这些将导致客户非常不满
例如：人机交互的易用性、整体的运行正确性和可靠性以及软件安装的简易性
- 令人兴奋的需求
这些需求反映了客户期望之外的特点，但是如果实现这些特点的话将会使客户非常满意
例如多重触控技术的触摸屏，可视语音邮箱
用户场景
开发人员和用户可以创建一系列的场景
场景：通常称为用例，它提供了将如何使用系统的描述（类似于举例）
获取工作产品
对于大多数系统而言，需求导出的工作产品包括：
1. 要求和可行性陈述
2. 系统或产品范围的界限说明
3. 参与需求获取的客户、用户和其他利益相关者的名单
4. 系统技术环境的说明
5. 需求列表（最好按照功能加以组织）以及每个需求适用的领域限制
6. 一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用
7. 任何能够更好地定义需求的原型
所有参与需求导出的人员需要评审以上的每一个工作产品
敏捷需求获取
在敏捷过程中，通过向所有利益相关者询问，生成用户故事以获取需求。
面向服务的方法
面向服务的开发将系统看作一套服务的集合。面向服务开发的需求获取关注由应用系统所定义的服务。

7.4 开发用例

用例从最终用户的角度描述软件或系统。
撰写用例的第一步是确定故事中所包含的“参与者”：

参与者是在功能和行为环境内使用系统或产品的各类人员（或设备）。参与者代表了系统运行时人（或设备）所扮演的角色。
参与者和最终用户并非一回事。用户可能在使用系统时扮演了许多不同的角色，而参与者表示一类外部实体（经常是人员，但并不总是如此），在用例中他们仅扮演一种角色
需求导出是一个逐步演化的活动，因此在第一次迭代中并不能确认所有的参与者。在第一次迭代中有可能识别主要的参与者，而对系统了解更多之后，才能识别出次要的参与者:
- 主要参与者：直接使用软件、获取所需的系统功能，并从系统得到预期收益
- 次要参与者：支持系统，以便主要参与者能够完成他们的工作

7.5 构建分析模型

需求模型=分析模型
分析模型的作用是基于计算机的系统提供必要的信息、功能和行为域的说明。

分析模型的元素

基于场景的元素：可以用用户的视角描述系统
基于类的元素
行为元素
面向数据流的元素

分析模式
任何有一些软件项目需求工程经验的人都开始注意到，在特定的应用领域内某些事情在所有的项目中重复发生。这些分析模式在特定应用领域内提供了一些解决方案(如类、功能、行为)。在为许多应用项目建模时可重复使用。

协商需求
在一个理想的需求工程情境中，起始、导出和精化能确保得到足够详细的客户需求，以开展后续的软件工程步骤。但遗憾的是，这几乎不可能发生。
在这里插入图片描述

确认需求
当需求模型的每个元素都已创建时，需要检查一致性、是否有遗漏以及歧义性。

7.6 避免常见错误

在这里插入图片描述

第8章需求建模：基于场景的方法

8.1 需求分析

需求建模动作产生以下一种或多种模型类型：

场景模型：出自各种系统“参与者”观点的需求
数据模型：描述问题信息域的模型
面向类的模型：表示面向对象类（属性和操作）的模型，其方式为通过类的协作获得系统需求
面向流程的模型：表示系统的功能元素并且描述功能元素在系统中运行时怎样进行数据变换的模型
行为模型：显示软件如何对外部事件或激励做出相应

在整个需求建模过程中，软件工程师的主要关注点集中在“做什么”而不是“怎么做”方面。

需求模型的三个主要目标：

描述客户需要什么，分析正确性
为软件设计奠定基础
定义在软件完成后可以被确认的一组需求

分析的经验原则
模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些
需求模型的每个元素都应该能增加对软件需求的整体理解，并提供对信息域、功能和系统行为的深入了解
关于基础结构和其他非功能的模型应推延到设计阶段再考虑
最小化整个系统内的关联
确认需求模型为所有利益相关者都带来价值
尽可能保持模型简洁
域分析

8.2 基于场景的建模

模板
在这里插入图片描述

图形化用户场景
在这里插入图片描述

8.3 补充用例的UML模型

活动图
在这里插入图片描述
泳道图

数据建模概念
数据建模：定义在系统内处理的所有数据对象、数据对象之间的关系以及其它与这些相关的信息
数据对象：

任何必须被软件理解的复合信息的表示
复合信息：指具有一系列不同性质或属性的事物，仅有单个值的事物（例如，宽度）不是数据对象，但“维度”（包括宽度、高度和深度）可以被定义为一个对象
数据对象可能是外部实体，事物，偶发事件或事件，角色，组织单位，地点或结构

数据属性：
数据属性定义了数据对象的性质，可用于：

命名数据对象的实例（命名属性）
描述某个实例（描述属性）
建立对另一个表中的另一个实例的引用（引用属性）

标识符的值是唯一的，但不是必须的
可以把一个或多个属性定义为标识符
在这里插入图片描述

数据建模概念
关系——数据对象之间的关系
数据对象可以以多种不同的方式与另一个数据对象连接
箭头方向可以减少歧义和误解
在这里插入图片描述

第9章需求建模：基于类的方法

属于面向对象分析
元素包括：类和对象、属性、操作、类的职责协作者（CRC）模型、协作图和包

建模过程：

通过检查问题描述来识别类
分离潜在类
识别类的所有属性
定义操作

9.1 识别分析类

通过检查问题描述进行
从名词中筛选：
- 外部实体（其他系统、设备、人员）
- 事物（报告、显示、字母、信号）
- 偶发事件或事件
- 角色（经理、工程师、销售人员）
- 组织单元（部门、组、团队）
- 场地（制造车间或码头）
- 结构（传感器、四轮交通工具、计算机）
统称信息（过于宽泛）、基本属性（过于简单）、纯操作不宜选作类

语法分析
举例
在这里插入图片描述
名词分析

潜在类的选择
在这里插入图片描述

上述并不全面，必须添加其他类使模型更加完整
某些被拒绝的潜在类可能将成为被接受类的属性
对问题的不同陈述可能导致作出“接受或拒绝”两个完全不同的决定

9.2 描述属性

属性：“属于”类的东西
属性描述已经被选择包含在分析模型中的对象

属性定义了对象——阐明了在问题空间中对象意味着什么

9.3 定义操作

操作：“属于”类的行为
四种类型的操作：

以某种方式操作数据（例如：添加、删除、重新格式化、选择）
执行计算的操作
获取某个对象状态的操作
监视某个对象发生某个控制事件的操作

9.4 类-职责-协作者建模

类-职责-协作者CRC建模：提供了一个简单方法，用于识别和组织与系统或产品需求相关的类
CRC模型是表示类的标准索引卡片的集合，分为三部分：
顶部：写类名
主体左侧：列出类的职责

职责：和类相关的属性和操作，即“类所知道或能做的任何事”

主体右侧：列出类的协作者

协作者：完成某个职责需要的其它类，即信息请求或动作请求

在这里插入图片描述
类
类的分类可通过三种分类方式进行扩展

实体类
也称模型或业务类，是从问题说明中直接提取出来的
边界类
用于创建用户可见的和在使用软件时交互的接口（如交互屏幕或打印的报表）
控制类
用于管理“工作单元”。控制类可以管理
1.实体类的创建或更新
2.边界类获取信息后的实例化
3.对象集合简单的复杂通信
4.对象间或用户和应用系统间交换数据的确认

职责的5个指导原则

智能系统应分布在所有类中以求最佳地满足问题的需求
每个职责的说明应尽可能具有普遍性
信息和与之相关的行为应放在同一个类中
某个事物的信息应局限于一个类中而不要分布在多个类中
职责应由相关类共享

协作
类有两种方法实现其职责：

类可以使用其自身的操作控制各自属性，从而实现特定的职责；（可自主完成）
一个类可以和其他类协作

类间的三种通用关系

is-part-if（是…的一部分）
has-knowledge-of（有关于…的知识）
depends-upon（依赖…）

9.5 关联和依赖

关联
两个分析类以某种方式相互联系着，这些联系被称作关联
多样性：
在这里插入图片描述
依赖

9.6 分析包

在这里插入图片描述

第10章需求建模：行为和模式

面向流程建模

描述了数据对象在系统中的变换过程
采用数据流图（DFD）、状态迁移图等
DFD采取了系统的输入-处理-输出观点，即流入软件的数据对象，经由处理元素变换，最后结果以数据对象的形式流出软件
在这里插入图片描述
数据流图基本流程

数据流图分层表示

在这里插入图片描述
如何将第0层DFD扩展到第一层数据流模型

对描述环境层泡泡的用例叙述采用“语法解析”的方法
即将第一次需求收集会议获得的SafeHome处理叙述中的所有名词（名词短语）与动词（动词短语）分离开来

例子：
在这里插入图片描述

持续地进行DFD的求精，直到每个泡泡都执行了某个单一的功能，也就是或，直到每个泡泡所代表的处理都执行一个功能，并且该功能可以很容易地成为一个程序构件
切记：DFD之间的数据流必须要连续

判定表
在这里插入图片描述
结构化分析
数据字典：

管理各种关系模型中的信息，具体信息包括：
- 一般信息：名字、别名、描述等
- 定义信息：数据类型、长度、结构
- 使用特点：值的范围、使用频率、使用方式
- 控制信息：来源、使用它的程序
- 分组信息：父结构、从属结构、物理位置等

数据元素组成数据对象的方式：

顺序：两个或多个分量以确定次序进行连接
选择：从两个或多个可能的元素中选取一个
重复：把指定的分量重复零次或多次
符号：
= 等价于
+ 和
[] 或（选择一个，用|隔开分量）
- 字母或数字 = [字母字符 | 数字字符]
{} 重复，（左右的数字分别为重复次数的上、下界）
- 字母数字串 = 0{字母或数字}7 （可重复0-7次）
() 可选（即从括号中任选一项，也可一项不选）

在这里插入图片描述

10.1 生成行为模型

行为模式描述了系统如何响应外部事件或激励
生成步骤：

评估所有的用例，以保证完全理解系统内的交互顺序
识别驱动交互顺序的事件，并理解这些事件如何与特定的对象相互关联
为每个用例生成序列
创建系统动态图
评审行为模式已验证准确性和一致性

10.2 识别用例事件

只要系统和参与者之间交互了信息就发生事件
一旦确定了所有的事件，这些事件将被分配到所涉及的对象
- 对象负责生成事件
- 或识别已经在其他地方发生的事件

10.3 状态表达

类的状态有被动和主动两种特征：

被动状态——某个对象所有属性的当前状态：
- 前后状态对被动状态影响不大。比如，位置与方向信息等
主动状态——对象进行持续变换和处理时的当前状态
- 必然存在前后不同状态。比如，移动、休息、受伤、疗伤、被捕、失踪等
- 必然发生事件（有时被称为触发器）才能迫使对象做出一个主动状态到另一个主动状态的转移

状态图
在这里插入图片描述
顺序图

例子：

10.4 需求建模的模式

需求模式由各种元素组成：

基于场景（用例）、基于数据（数据模型）、基于类、基于流和行为
其中，每个元素都是从不同的视角检查问题，并且每一个都提供一种发现模式的机会

第11章设计概念

11.1 软件工程中的设计

软件的设计是将需求转变为软件陈述（表达）的过程。系统通过逐步求精，使得设计陈述逐渐接近源代码：

初步设计，关注于怎么将需求转换成数据和软件框架
详细设计，关注于将框架逐步精细化为具体的数据结构和软件的算法表达。

在这里插入图片描述
需求模型提供了创建四种设计模型所需信息：

数据/类设计：将类模型转化为设计类以及目标软件的结构
体系结构设计：定义了软件的主要构造元素间的联系
接口设计：描述了软件和协作系统之间、软件和使用人员之间的通信
构件级设计：将软件体系结构的构造元素变换为对软件构件的过程性描述

设计任务

11.2 设计过程

软件设计是一个迭代的过程

质量指导原则

设计应展示出这样一种结构：
a. 使用可识别的体系结构风格或模式创建
b.由展示出良好设计特征的构件构成
c.能够以演化的方式实现，便于实现和测试
模块化：
将软件逻辑地划分为元素或子系统
设计应该包含体系结构、接口和构件的清晰表示
导出合适的数据结构：
数据结构适用于要实现的类，并从可识别的数据模式提取
设计应导出显示独立功能特征的构件
设计应导出接口：
这些接口应该是由需求信息驱动
采用有效的表示法：
使用能够有效传达意义的表示法来表达设计

质量属性

功能性
易用性
可靠性
性能
可支持性

通用任务设计任务集

检查信息域模型，并为数据对象及其属性设计恰当的数据结构
使用分析模型，选择一种适用于软件的体系结构风格
将分析模型分割为若干个子系统，并在体系结构内分配这些子系统
创建一系列的设计类或构件
设计外部系统或设备所需要的所有接口
设计用户接口
进行构件级设计
开发部署模型

11.3 设计概念

抽象
软件开发过程的每一步都是对较高一级抽象的解作一次具体化的描述
两种不同的抽象：

数据抽象：描述数据对象的数据集合
定义数据类型和施加于该类型对象的操作
过程抽象：具有明确和有限功能的指令序列
过程抽象的命名暗示了功能，但是隐藏了具体的细节
这些功能实际上是由一系列更低级的功能或代码来实现的
==过程抽象“开”将利用数据抽象“门”==的属性中所包含的信息

数据抽象	过程抽象

体系结构
软件体系结构意指“软件的整体结构和这种结构为系统提供概念完整性的方式”
简单来说，体系结构是程序构件（模块）的结构和组织、这些构件交互的形式以及这些构件所用数据的结构
软件设计的目标之一是导出系统的体系结构示意图，该示意图作为一个框架，将指导更详细的设计活动

软件体系结构设计的一组属性

结构特性

定义了系统的构件( 如模块、对象、过滤器)、构件被封装的方式以及构件之间相互作用的方式。

外部功能特性

应当指出设计体系结构如何满足需求，这些需求包括：性能需求、能力需求、可靠性需求、安全性需求、可适应性需求以及其他系统特征需求

相关系统族

体系结构应当能抽取出在一类相似系统开发中经常遇到的重复性模式。本质上，设计应当能够重用体系结构构件。

模式
设计模式是经过验证的，用于解决在特定环境下、重复出现的、特定问题的解决方案

关注点分离
关注点分离表明任何复杂问题如果被分解为可以独立解决或优化的若干块，该复杂问题能够更容易地被处理。

模块化
模块化是关注点分离最常见的表现。
模块化就是把程序划分成独立命名且可直接访问的模块，各个模块完成一个子功能，这些模块集成起来构成一个整体，完成指定功能
例如：类、过程、函数、子程序、宏等。
在这里插入图片描述
模块化的优点

使开发工作更易于规划
可以定义和交付软件增量
更容易实施变更
能够更有效地展开测试和调试
可以进行长期维护而没有严重的副作用

信息屏蔽
在这里插入图片描述
信息屏蔽优点

对外隐蔽，减少副作用的可能性
强调通过控制接口进行通信
不鼓励适用全局数据
使用封装——高质量的设计的一个属性
使得产生高质量软件

功能独立
在这里插入图片描述

功能独立性的指标

内聚：一个模块内部各个元素彼此结合的紧密程度

尽量高！

耦合：模块之间相互关联的程度

尽量低！

内聚度的七个层次
在这里插入图片描述
耦合度的七个层次

求精
对各种抽象的细化
在这里插入图片描述
重构
是一种重新组织的技术，可以简化构件的设计（或代码）而无需改变其功能或行为
定义：不改变代码（设计）的外部行为而是改变其内部结构

面向对象的设计概念
面向对象设计模式解决的是“类与相互通信的对象之间的组织关系，包括它们的角色、职责、协作方式几个方面”
设计思路：应对变化，提高复用

设计类
在这里插入图片描述
组织良好的设计类的四个特征：

完整性与充分性

设计类应完整封装所有合理预见的类中的属性和方法

原始性

应该关注于实现类的某一个服务

高内聚性

一个内聚的设计类具有小的、集中的职责集合

低耦合性

在设计模型内，设计类之间相互协作是必然的。但是，协作应该保持在一个可以接受的最小范围内

依赖倒装
高层模块（类）不应当（直接）依赖于低层模块，两者都应当依赖于抽象。抽象不应当依赖于细节，细节应当依赖于抽象。

测试设计
测试要快，失败要快，调整要快

11.4 设计模型

在这里插入图片描述
过程维度：表示设计模型的演化，设计任务作为软件过程的一部分被执行
抽象维度：表示详细级别，分析模型的每个元素转化为一个等价的设计，然后迭代求精

数据设计元素
数据体系结构创建了在高抽象级上（以客户或用户的数据观点）表示的数据模型和信息模型
软件体系结构设计元素

在这里插入图片描述

接口设计元素
软件接口设计元素描述了信息如何流入和流出系统以及被定义为体系结构一部分的构件之间是如何通信的
接口设计的3个元素：
- 用户界面
- 和其他系统、设备、网络或其他的信息生产者或使用者的外部接口
- 各种设计构件之间的内部接口

UI设计（越来越多地被称作可用性设计）

美学元素
布局、颜色、图形、交互机制
人机工程元素
信息布局、隐喻、UI导航
技术元素
UI模件、可复用构件

接口设计元素
在这里插入图片描述

构件级设计元素
在这里插入图片描述

UML构件图
在这里插入图片描述

部署级设计元素

在这里插入图片描述

第12章体系结构设计

12.1 软件体系结构

也称架构，它是系统的一个或多个结构

结构中包括：构件，构件的外部可见属性以及它们之间的相互关系

软件体系结构的作用：

对设计在满足规定需求方面的有效性进行分析
在设计变更相对容易的阶段，考虑体系结构可能选择方案
降低与软件构造相关联的风险

在这里插入图片描述

不同的利益相关者会从不同的角度理解体系结构，这个角度是由不同的关注点驱动的

体系结构决策描述模板

12.2 体系结构类型

体系结构发展过程
单主机结构——>CS(Client/Server)结构——>B/S(Browser/Server)结构

体系结构类型
人工智能商业和非盈利的通信内容创作
设备娱乐与运动金融游戏
行政管理工业法律医疗军事操作系统平台
科学工具运输实用程序

12.3 体系结构风格

以数据为中心的体系结构

优点：
开放：数据对所有使用者开放，客户软件可以直接决定存取方式
可集成性：现有构件可以被修改，新的客户构件可以加入到体系结构中，而无需考虑其他客户

问题：
客户软件难以协作
中心数据的格式必须为所有客户软件所接受

数据流体系结构
- 管道——过滤器模式
  
  优点：
  易理解
  容易并行运行

问题：
适用于批处理，不易交互
流的协作需要考虑

调用和返回体系结构
- 主程序/子程序体系结构
  将功能分解为一个控制层次结构，其中的“主”程序调用一组程序构件，这些程序构件又去调用别的程序构件（此时，对于被调者来说，这些主调者就是主程序）
- 远程过程调用体系结构
  构件分步在网络的多个计算机上
面向对象体系结构
系统的构件封装了数据和应用到该数据上的操作
构件间通过消息传递进行通信与合作
层次体系结构
定义了不同的层次，各个层次完成各自操作

优点：明确的抽象层次、易于增减或修改层次
问题：系统并不是总能分层

体系结构框架

一个特定应用领域问题的体系模式
一个待实例化的完整系统

例如：MFC、Struts、专家系统外壳：行业应用框架、.NET

12.4 体系结构考虑要素

经济性
易见性
隔离性
对称性
应急性

12.5 体系结构决策

决策模型记录了所需要的体系结构决策、在过往的项目中实际做出的决策以及支持这些决策的理由

12.6 体系结构设计

系统环境的表示
在这里插入图片描述
构件的来源：

应用领域
基础设施域
界面领域

在这里插入图片描述

12.7 评估候选的体系结构设计

体系结构评审是一种特定的技术性评审，它提供了一种评估方法，该方法可以评估软件体系结构满足系统质量需求（如可扩展性或性能）的能力以及识别任何潜在风险的能力。

往往只涉及软件工程团队成员，并辅以独立的专家

常用评审技术：

基于经验的推理
原型评估
情境评审
检查单的使用

体系结构描述语言——ADL

12.8 经验学习

决策分析和解决方案——DAR

原因链法
石川鱼骨法
思维导图或蜘蛛图

12.9 基于模式的体系结构评审

基于模式的体系结构评审——PBAR
一种用来平衡体系结构模式与软件质量属性之间关系的评估方法
是一种轻量的评估方法，非常适用于小规模敏捷团队，只需要相对较少的额外项目时间和精力
在这里插入图片描述

12.10 体系结构一致性检查

静态体系结构一致性分析（SACA）可以评估已完成的软件系统是否与它的体系结构模型相符合

12.11 敏捷性与体系结构

数据流映射
使用数据流进行体系结构映射
两种信息流类型：变换型、事务型

大型软件系统通常是变换型结构和事务型结构的混合
通常采用以变换分析为主，事务分析为辅的方式进行软件结构设计

事务映射

变换映射

变换型与事务型的区别

变换型是线性的处理（一般是一个输出）
事务型是分类处理（选择某一条路径作为输出）

体系结构步骤

步骤1：评审基本系统模型
步骤2：评审和精化软件的数据流图
步骤3：确定DFD是否含有变换流或事物流特征
步骤4：通过确定输入和输出流的边界，分离出变换中心
步骤5：完成“第一级分解”
步骤6：完成“第二级分解”
步骤7：使用提高软件质量的设计启发式方法，精化第一次迭代得到的体系结构

第13章构件级设计

13.1 什么是构件

正式定义：系统中模块化的、可部署的和可替换的部件，该部件封装实现并暴露一组接口

通俗地讲，构件是一段程序，该程序能够完成一段相对独立的功能，并有一定的通用性

构件驻留于软件体系结构的内部，它们必须与其他的构件和存在于软件边界以外的实体（例如其他系统、设备和人员）进行通信和合作

针对不同的系统设计体系，构件指的对象不一样

面向对象的观点
在面向对象软件工程环境中，构件包括一个协作类集合。
传统观点
在传统软件工程环境中，一个构件就是程序的一个功能要素，程序由处理逻辑与实现所需的内部数据结构以及能够保证构件被调用和实现的接口构成
传统构件也成称为模块
过程相关的观点

13.2 设计基于类的构件

在这里插入图片描述

开闭原则 OCP
里氏替换 LSP
依赖倒装 DIP
接口分离 ISP
发布复用等价性 REP
共同封装 CCP
共同复用 CRP

构件级设计指导方针

内聚性
描述为构件的专一性
内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作
类型：

功能内聚
主要通过操作来体现，当一个模块中的各个部分只完成某一组特定操作并返回结果时，就称此模块是功能内聚的。（最好的内聚）
分层内聚
由包、构件和类来体现。高层能够访问低层的服务，但低层不能访问高层的服务。
通信内聚
访问相同数据的所有操作被定义为在一个类中。一般来说，这些类只着眼于数据的查询、访问和存储。
顺序内聚
模块中各个处理元素密切相关，必须顺序执行，前一功能的输出就是下一功能元素的输入
时间内聚
模块各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行。
逻辑内聚
模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能
实用内聚
逻辑上不能纳入其他内聚类型的相关实用程序放在一起，形成实用内聚（巧合内聚）

耦合性
构件之间彼此联系紧密程度的一种定性度量
面向对象：类间联系的紧密程度
目标：低耦合
类型：
内容耦合
共用耦合
控制耦合
标记耦合
数据耦合
其他耦合
- 例程调用耦合
- 类型使用耦合
- 包含或者导入耦合
- 外部耦合

在这里插入图片描述

13.3 实施构件级设计

步骤

1.标识出所有与问题域对应的设计类
2.确定所有与基础设施对应的设计类
3.细化所有不能作为复用构件的设计类
- a.在类或构件的协作时说明消息的细节
- b.为每一个构件确定适当的接口
- c.细化属性，定义相应的数据类型和数据结构
- d.详细描述每个操作中的处理流
4.说明持久数据源（数据库和文件）并确定管理数据源所需要的类
5.开发并且细化类或构件的行为表示（可用状态图）
6.细化部署图以提供额外的实现细节
7.考虑每一个构件级设计表示，并且时刻考虑其他可选方案

13.4 WebApp的构件级设计

WebApp构件是

为最终用户处理内容，或提供计算或数据处理
提供最终用户所需的功能

通常包括内容设计元素和功能设计元素

13.5 设计传统构件

图形化设计表示
在这里插入图片描述
表格式设计表示

决策表的表格式设计表示

13.6 基于构件的开发

基于构件的开发——CBSE
是一种强调使用可复用的软件构件来设计与构造计算机系统的过程

领域工程
在这里插入图片描述
构件合格性检验

构件适应性修改

复用的分析和设计
关键问题：

标准数据
标准接口协议
程序模板

第14章用户界面设计

14.1 黄金规则

把控制权交给用户
- 不强迫用户进入不必要或不希望的交互模式
- 提供灵活的交互
- 允许用户被中断和撤销
- 当技能级别增长时可以使交互流线化并允许定制交互
- 使用户与内部技术细节隔离
- 设计应允许用户与出现在屏幕上的对象直接交互
减少用户的记忆负担
- 减少对短期记忆的要求
- 建立有意义的缺省
- 定义直观的快捷方式
- 界面视觉布局应该基于真实世界的象征
- 以不断进展的方式揭示信息
保持界面一致
- 允许用户将当前任务放入有意义的环境中
- 在应用系统家族内保持一致性
- 如果已经建立起用户期望，轻易不要改变它