软件工程-自考_2.2.1设计与创建系统的用户类与实体类根据基本的需求描述,用户类与实体类至少要包

第1章 绪论

1. 软件工程的概念的提出与发展

软件工程概念的提出，其目的是倡导以工程的原理、原则和方法进行软件开发，以期解决出现的“软件危机”。

20世纪60年代末到80年代初，瀑布模型、过程式语言和开发方法。
20世纪80年代以来，软件生存周期过程、CASE产品、面向对象语言。

2. 软件开发的本质

计算机软件一般是指计算机系统中的程序及其文档。其中，程序是计算机任务的处理对象和处理规则的描述；文档是为了理解程序所需的阐述性资料。

软件开发的本质可以概况为：不同抽象层术语之间的“映射”，以及不同抽象层处理逻辑之间的“映射”。

所谓系统建模，是指运用所掌握的知识，通过抽象，给出给系统的一个结构——系统模型。因此，模型是一个抽象。

在软件开发领域，系统模型分为两大类，一类称为概念模型，描述了系统是什么；另一类统称为软件模型，描述了实现概念模型的软件解决方案。软件模型又可进一步分为设计模型、实现模型和部署模型等。

第2章 软件需求与软件需求规约

1. 需求与需求获取

1. 需求定义

一个需求是有关“要予构造”的陈述，描述了待开发产品/系统（或项）功能上的能力、性能参数或其他性质。

对于单一一个需求，必须具有如下5个性质：

• 必要的，该需求是用户所要求的。
• 无歧义的，该需求只能用一种方式解释。
• 可测的，该需求是可进行测试的。
• 可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段。
• 可测量的，该需求是可测量的。

2. 需求分类

功能需求
非功能需求：性能、外部接口、设计约束、质量属性

3. 需求发现技术

自悟、交谈、观察、小组会、提炼

2. 需求规约

1. 需求规约定义

需求规约是一个软件/产品/系统所有需求陈述的正式文档，它表达了一个软件/产品/系统的概念模型。

需求规约的基本性质:

• 重要性和稳定性程度：按需求的重要性和稳定性，对需求进行分级。
• 可修改的 ：在不过多地影响其它需求的前提下， 可以容易地修改一个单一需求。
• 完整的：没有被遗漏的需求。
• 一致的：不存在互斥的需求。

2. 需求规约（草案）格式

3. 需求规约（规格说明书）的表达：

• 非形式化的需求规约
• 半形式化的需求规约
• 形式化的需求规约

4. 需求规约的作用

• 需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。
• 对于项目的其余大多数工作，需求规约是一个管理控制点。
• 对于产品/系统的而设计，需求规约是一个正式的、受控的起始点。
• 需求规约是创建产品验收计划和用户指南的基础。

第3章 结构化方法

1. 结构化需求分析

1.1 基本术语

1. 数据流，数据的流动。
2. 加工，数据的变换单元
3. 数据存储，数据的静态结构
4. 数据源和数据潭，数据源是数据流的起点，数据潭是数据流的归宿地。

1.2 系统功能模型表示

需求分析的首要任务是建立系统功能模型，为此结构化分析方法给出了一种表达功能模型的工具，即数据流图（Dataflow Diagram），简称DFD图。
简单地说，DFD图是一种描述数据变换的图形化工具。

1.3 建模过程

1. 建立系统环境图，确定系统语境。
2. 自顶向下，逐步求精，建立系统的层次数据流图。
3. 定义数据字典。
4. 描述加工，结构化自然语言、判定表、判定树。

1.4 应用中注意的问题

1. 模型平衡问题。
2. 信息组织复杂性控制问题。

1.5 需求验证

一般来说，需求验证应验证需求规格说明书中的每一单需求是否满足5个性质，即必要性、无歧义性、可测性、可跟踪性，可测量性；验证需求规格说明是否满足4个性质，即重要性和稳定性程度、可修改性、完整性和一致性。

2. 结构化设计

2.1 总体设计

1. 总体设计的目标及其表示

总体设计阶段的基本任务是把系统的功能需求分配到一个特定的软件体系结构中，建立系统的模块结构。
表达这一软件体系结构的工具主要有：

1. 模块结构图：一种描述软件“宏观”结构的图形化工具。
2. 层次图：主要用于描绘软件的层次结构。
3. HIPO图：HIPO图是美国IBM公司提出的，其中HIPO是“层次图 + 输入/处理/输出”的英文缩写。

2. 总体设计步骤

如何将需求分析得到的系统DFD图映射为设计层面的模块及模块调用。在DFD的基础上，基于自顶向下、功能分解的设计原则，定义了两种不同的“映射”，即变换设计和事务设计。
其基本步骤是，首先将系统的DFD图转换为初始的模块结构图，再基于“高内聚低耦合”这一软件原理，通过模块化，将初始的模块结构图转换为最终的、可详细设计使用的模块结构图（MSD）。

变换型数据流图。具有较明显的输入部分和变换（或称主加工）部分之间的界面、变换部分和输出部分之间界面的数据流图。

事务型数据流图。当数据流图具有与图3-26类似的形状时，即数据到达一个加工T，该加工T根据输入数据的值，在其后的若干动作序列（称为一个事务）中选出一个来执行，这类数据流图称为事务型数据流图。
处理T称为事务中心，它完成下述任务：

1. 接收输入数据。
2. 分析并确定对应的事务。
3. 选取与该事务对应的一条活动路径。

变换设计。变换设计是在需求规约的基础上，经过一系列设计步骤，将变化型数据流图转换为系统的模块结构图。
基本步骤：

1. 设计准备，复审并精化系统模型
2. 确定输入、变换、输出这三部分的边界
3. 设计系统模型结构图顶图和第一层
4. 自顶向下，逐步求精

事务设计。当数据流图具有明显的事务型特征时，也就是有一个明显的事务处理中心时，则比较适宜采用事务设计。

1. 设计准备，复审并精化系统模型
2. 确定事务处理中心
3. 设计系统模型结构图顶图和第一层
4. 自顶向下，逐步求精

3. 模块化及启发式规则

模块是执行一个特殊任务的一个过程以及相关的数据结构。模块通常由两部分组成：接口和模块体。
结构化软件设计是一种典型的模块化方法，即把一个待开发的软件分解成若干个简单的、具有高内聚低耦合的模块，这一过程称为模块化。

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

1. 内容耦合：一个模块直接修改或操作另一个模块的数据。
2. 公共耦合：两个或两个以上的模块共同引用一个全局数据项。
3. 控制耦合：一个模块向另一模块传递一个控制信号，接受信号的模块将依据该信号值进行必要的活动。
4. 标记耦合：若一个模块A通过接口向两个模块B和C传递一个公共参数，那么称模块B和模块C之间存在一个标记耦合。
5. 数据耦合：模块间通过参数传递基本类型的数据。

原则是：尽量用数据耦合，少用控制耦合，限制公共耦合的范围，避免使用内容耦合。

内聚：一个模块内部各成分之间相互依赖程度的度量

1. 偶然内聚：一个模块的各成分之间不存在任何关系。
2. 逻辑内聚：几个逻辑上相关的功能放在同一模块中。
3. 时间内聚：一个模块完成的功能必须在同一时间内完成，而这些功能只是因为时间因素关联在一起。
4. 过程内聚：一个模块内部的处理成分是相关的，而且这些处理成分必须以特定的次序执行。
5. 通信内聚：一个模块的所有成分都操作在同一数据集或生成同一数据集。
6. 顺序内聚：一个模块的各成分与一个功能相关，且一个成分的输出作为另一成分的输入。
7. 功能内聚：模块的所有成分对完成单一功能都是最基本的。

启发式规则：

1. 改进软件结构，提高软件独立性。
2. 力求模块规模适中。
3. 力求深度、宽度、扇出、扇入适中。
   深度：表示其控制的层数。
   宽度：同一层次上模块总数的最大值。
   扇出：一个模块直接控制的下级模块的数目。
   扇入：有多少个上级模块直接调用它。
4. 尽量使模块的作用域在其控制域之内。
   模块的控制域：这个模块本身以及所有直接或间接从属它的模块的集合；
   模块的作用域：受该模块内一个判断所影响的所有模块的集合。
5. 尽力降低模块接口的复杂度。
6. 力求模块功能可以预测。

2.2 详细设计

详细设计的任务是具体描述模块结构图中的每一个模块，即给出实现模块功能的实施机制，包括一组例程和数据结构，从而精确地定义了满足需求所规约的结构。
详细设计的目标是将总体设计阶段所产生的系统高层结构映射为以这些术语所表达的低层结构，也是系统的最终结构。

详细设计工具:

1. 程序流程图
2. 盒图（N-S图）
3. PAD图
4. 类程序设计语言

程序流程图的优缺点
优点：对控制流程的描绘很直观，便于初学者掌握
缺点：

1. 不是一种逐步求精的工具
2. 所表达的控制流，往往不受任何约束可随意转移，从而会影响甚至破坏好的系统结构设计
3. 不易表示数据结构

第4章 面向对象方法——UML

在面向对象技术的发展中，一个重要的里程牌是UML（Unified Modeling Language）。

1. UML术语表

1.1 表达客观事物的术语

1. 类与对象

类是一组具有相同属性、操作、关系和语义的对象的描述。
对象是类的一个实例。

1. 类的属性

• 可见性：可见性指明该属性是否可以被其他类所使用。
• 属性名
• 类型
• 多重性
• 初始值
• 性质串

2. 类的操作

• 可见性
• 操作名
• 参数表
• 性质串

2. 接口（Interface）

接口是操作的一个集合，其中每个操作描述了类、构件或子系统的一个服务。
接口表示通常由两种形式：

1. 采用具有分栏和关键字《interface》的矩形符号来表示。如图所示，《interface》是接口标记；IWindow是接口名；Open()、Close()和Display()等是接口中的操作。
2. 采用小圆圈和半圆圈来表示，如图所示，左边的圈表示由类提供的接口，简称供接口；右边的半圈表示类需要的接口，简称需接口。

3. 协作（Collaboration）

协作是一个交互，涉及交互的三要素：交互各方、交互方式以及交互内容。
在UML中，协作表示为虚线椭圆。
在系统/产品建模中，可以通过协作来刻画一种由一种特定元素参与的、具有特定行为的结构。其中，这组特定元素可以是给定的类或对象，因此，协作可以表现系统/产品实现的一种构成模式。

4. 用况（Use Case）

用况是对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果。
在UML中，用况表示为实线椭圆。
在系统/产品建模中，用况一般用于模型化系统中的功能行为。

5. 主动类（Active Class）

主动类是一种至少具有一个进程或线程的类。由此可见，主动类能够启动系统的控制活动，并且，其对象的行为通常与其它元素行为并发的。
在UML中，主动类的表示与类的表示形式相似，只是多了两条竖线。
在系统/产品建模中，主动类一般用于模型化系统中的并发行为。

6. 构件（Component）

构件是系统设计的一种模块化部件，通过外部接口隐藏了它的内部实现。

7. 制品（Artifact）

制品是系统中包含物理信息的、可代替的物理部件。

8. 节点（Node）

节点是在运行时存在的物理元素，通常表示一种具有记忆能力和处理能力的计算机资源。

1.2 表达关系的术语

1. 关联（Association）

关联是类目之间的一种结构关系，是对一组具有相同结构、相同链的描述。链是对象之间具有特定语义关系的抽象，实现之后的链通常称之为对象之间的连接（connection）。

与类相比，类是一组具有相同属性、操作、关系和语义的对象的描述；而关联是一组具有相同结构和语义的链的描述。

为了表达关联的语义，UML采用了以下途径：

1. 关联名（Name）。
2. 导航。对于一个给定的类目，可以找到与之关联的另一个类目。
3. 角色（Role）。角色是关联一端的类目对另一端的类目的一种呈现。
4. 可见性。
5. 多重性（Multiplicity）。类（类目）中对象参与一个关联的数目。
6. 限定符（Qualifier）。
7. 聚合（Aggregation）。通过“一个类是另一个类的一部分”这一性质。表达的是一种“整体/部分”关系。
8. 组合（Compositon）。
9. 关联类。关联类是一种具有关联和类特性的模型元素。
10. 约束

2. 泛化（Generalization）

泛化是一般类目（称为超类或父类）和它较为特殊性类目（称为子类）之间的一种关系。
在UML中，把泛化表示成从子类到父类的一条带空心三角形的线段，其中空心三角形在父类端。

3. 细化（Realization）

细化是类目之间的语义关系，其中一个类目规约了保证另一类目执行的契约。
在UML中，把细化表示为一个带空心三角形的虚线段。

4. 依赖

依赖是一种使用关系，用于描述一个类目使用另一个类目的信息和服务。
关联、泛化和细化都是一类特定的依赖。

1.3 表达组合信息的术语——包

包是模型元素的一个分组，一个包本身可以被嵌套在其它包中，并且可以含有子包和其它类型的模型元素。
为了模型化包之间的关系，UML给出了两种依赖，即访问和引入，用于描述一个包可以访问和引入其他包。

2. UML的模型表达格式

UML的图形工具分为两类，一类是结构图，用于表达系统或系统成分的静态结构模式， 给出系统或系统成分的一些说明性信息；一类是行为图，用于表达系统或系统成分的动态结构模型，给出系统或系统成分的一些行为信息。

2.1 类图（Class Diagram）

类图是可视化的表达系统静态结构模型的工具，通常包含类、接口、关联、泛化和依赖关系等。
类图可用于创建系统的结构模型，表达构成系统各成分之间的静态关系，给出有关系统的一些说明性信息。

2.2 用况图（Use Case Diagram）

用况图是一种表达系统功能模型的图形化工具。
用况图可用于创建有关系统的功能模型，表达系统的功能结构，给出有关系统在功能需求方面的信息。
其中，一个用况图通常包含6个模型元素，它们是主题、用况、参与者、关联、泛化、依赖。

1. 主题（Subject）。主题是有一组用况所描述的一个类，通常是一个系统或子系统。
2. 用况（Use Case）。
3. 参与者（Actor）。
4. 关联、泛化和依赖。

2.3 状态图

状态图是显示一个状态机的图，其中强调了从一个状态到另一个状态的控制流。一个状态机是一种行为，规约了一个对象在其生存期间因响应事件并作出响应而经历的状态。
状态图可用于创建有关系统的行为生存周期模型，表达有关系统的一种动态结构，给出有关系统在生存周期可有那些阶段、每个阶段可从事的活动以及对外呈现的特征等方面的信息。

2.4 顺序图

顺序图是一种交互图，即由一组对象以及按时序组织的对象之间的关系组成，其中还包含这些对象之间所发送的消息。
顺序图可用于创建有关系统的交互模型，表达系统中有关对象之间的交互结构，给出系统中的一些对象如何协作的信息。

作为一种软件开发方法学，为了支持软件开发活动，至少包括3各方面的内容：一是给出定义不同抽象层的术语；二是应给出各抽象层的模型表达工具；三是应给出把各层模型映射为下一个抽象层的模型，即过程指导。UML仅包括前两方面的内容，因此，UML是一个可视化的建模语言，而不是一种特定的软件开发方法学。

第5章 面对对象方法——RUP

一种软件开发方法至少由3部分组成：用于表达基本信息的的术语、用于组织基本信息的表达格式、用于在不同抽象层之间进行映射的过程指导；
UML仅包括前两方面的内容， 因为它只是一种可视化的面向对象的建模语言。RUP给出的是一种基于UML的过程指导， 满足软件开发方法学的第三项内容， 因此RUP要与UML一起才称得上是一种面向对象开发的方法学。
统一软件开发过程（Rational Unified Process），是基于UML的一种过程框架。

1. RUP的特点

RUP的突出特点是，它是一种以用况为驱动的，以体系结构为中心的迭代、增量式开发。

1.1 以用况为驱动

以用况为驱动是指在系统的生存周期中，以用况作为基础，驱动系统有关人员对所要建立系统的功能需求进行交流，驱动系统分析、设计、实现和测试等活动，包括制订计划、分配任务、监控执行和进行测试等，并将它们有机地组合为一体，使各个阶段中都可以回溯到用户的实际需求，如图5-2所示。

1.2 以体系结构为中心

以体系结构为中心是指在系统的生存周期中， 开发的任何阶段（RUP规定了4个阶段，即初始阶段、细化阶段、构造阶段和移交阶段）都要给出相关模型视角下有关体系结构的描述，作为构思、构造、管理和改善系统的主要制品，如图5-3所示。

1.3 迭代、增量式开发

迭代、增量式开发是指通过开发活动的迭代， 不断地产生相应的增量。
在RUP中， 规定了四个开发阶段：

1. 初始阶段
2. 精化阶段
3. 构造阶段
4. 移交阶段

2. 核心工作流

在RUP的每次迭代中都要经历一个核心工作流，即需求获取、分析、设计、实现和测试。

2.1 需求获取

RUP采用 Use Case 技术来获取需求。其目标：使用UML中的用况、参与者以及依赖等术语来抽象客观实际问题，形成系统的需求获取模型——一种特定的系统/产品模型，并产生该模型视角下的体系结构描述。

1. 列出候选需求

从客户、用户、计划者、开发者的想法和意愿中搜取特征（Feature），形成特征表。

2. 理解系统语境

需要创建领域模型或业务模型。

3. 捕获系统功能需求

创建系统用况模型，用以表达客户认可的需求——系统必须满足的条件和能力，作为客户和开发人员之间的一种共识。
为了创建系统的用况模型，应进行一下活动。

1. 活动1：发现并描述参与者（Actor）。
2. 活动2：发现并描述用况。
3. 活动3：确定用况的优先级（Priority）。
4. 活动4：精化用况。
5. 活动5：构造用户界面原型。
6. 活动6：用况模型的结构化。

2.2 需求分析

RUP的需求分析目标是：在系统用况模型的基础上，创建系统分析模型以及在该分析模型视角下地体系结构描述。

1. 基本术语
   分析类、用况细化、分析包

(1) 分析类（Analysis Class）

1. 边界类（Boundary Classes）：边界类用于规约系统与其参与者之间的交互，该交互涉及向用户/外部系统发出请求和从他们那里接受信息。
2. 实体类（Enitty Classes）：实体类用于规约那些需要长期驻留在系统中的模型化对象以及与行为相关的某些现象。
3. 控制类（Control Classes）：控制类用于规约基本动作和控制流的处理与协调，涉及向其他对象委派工作。
   综上可见：

• 分析类是概念层面上的“大粒度”术语。其中，边界类封装了一些重要的通信接口和用户界面机制；实体类封装了问题域中的一个重要现象；控制类封装了一些重要的定序。
• 用况模型中的用况与分析模型中的分析类之间存在确定的依赖关系。

(2) 用况细化（Use Case Realization）
用况细化 [分析] 是一个协作。
(3) 分析包（Analysis Package）
分析包是一种控制信息组织复杂性的机制，提供了分析制品的一种组织手段，形成了一些可管理的部分。

2. 分析模型的表达

分析模型由“分析体统”定义，分析系统包含一组具有层次结构的包，每一个包中可包含一些分析类和用况细化 ；并且一些分析类和用况细化还可单独地出现在分析模型中，以凸显它们在系统体系结构方面的作用。

3. 分析的主要活动

创建系统的分析模型，一般应进行体系结构分析、用况分析、类的分析以及包的分析4项工作。

2.3 设计

RUP的设计目标是，定义满足系统/产品分析模型所规约需求的软件结构。
RUP为设计层提供了4个术语：设计类、用况细化、设计子系统和接口，用于表达软件结构中的基本元素。而且从两个角度来描述软件结构，一是系统设计模型；二是表达物理分布的系统部署模型；并给出如何从分析模型“映射”到设计模型的指导。

1. 设计层的术语

1. 设计类（Design Class），一个设计类是对系统实现中一个类或类似构造的一个无缝抽象。
2. 用况细化 [设计]。
3. 设计子系统
4. 接口

2. 设计模型、部署模型以及相关视角下地体系结构描述

3. 设计的主要活动

1. 活动1：体系结构设计。该活动的目标是创建设计模型和部署模型，以及它们视角下地体系结构描述。
2. 活动2：用况的设计。
3. 活动3：类的设计。该活动的目标是，完成用况细化中每一类的角色设计，并完成有关每一类的非功能需求的设计。
4. 活动4：子系统的设计。

2.4 RUP的实现和测试

1. RUP的实现
   RUP实现的目标是：基于设计类和子系统生成构件； 对构件进行单元测试， 进行集成和连接；把可执行的构件映射到部署模型。

2. RUP的测试
   RUP的测试包括内部测试、中间测试和最终测试。