章节说明

65%为新增内容, 预计选择题考5分，案例和论文不考；本章与第三版教材一样的内容以楷体字进行标注!

1 软件工程

1.1 架构设计

1、软件架构设计的一个核心问题是能否达到架构级的软件复用。

2、通用软件架构：数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。

风格类型	解释说明
数据流风格	批处理整修构风格和管道/过滤器两种风格【批管】（21下9）
调用/返回风格	主程序/子程序、数据抽象和面向对象，以及层次结构【主子抽象层面】（19上7）
独立构件风格	进程通信和事件驱动的系统【进程办事】（18上7）
虚拟机风格	解释器和基于规则的系统【解释规则】
仓库风格	数据库系统、，黑板系统、超文本系统【库黑超】

3、在架构评估过程中，评估人员所关注的是系统的质量属性。（17下7）

4、敏感点是一个或多个构件（和/或构件之间的关系）的特性，权衡点是影响多个质量属
性的特性，是多个质量属性的敏感点。

5、基于场景的方式主要包括：架构权衡分析法（ATAM）、软件架构分析法（SAAM）和成本 效益分析法（CBAM）中。在架构评估中，一般采用刺激、环境和响应三方面来对场景进行描述。 刺邀是场景中解释或描述项目干系人怎样引发与系统的交互部分，环境描述的是刺激发生时的情况，响应是指系统是如何通过架构对刺激作出反应的。

6、基于场景的方式分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。

1.2 需求分析

1、需求层次包括业务需求、用户需求和系统需求。（18下7）

需求类型	解释说明
业务需求	反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门
用户需求	描述的是用户的具体目标,或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么（19上10）
系统需求	从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束

2、质量功能部署（QFD）是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。（21上9）
（1）常规需求：用户认为系统应该做到的功能或性能，实现越多用户会越满意。
（2）期望需求：用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要
得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
（3）意外需求：也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员
很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

3、需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。

过程	具体内容
需求获取	求获取只有与用户的有效合作才能成功。常见的需求获取方法包括用户访谈、 问卷调查、采样、情节串联板、联合需求计划等。
需求分析	1.一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就悬霜条分析的工作。 2.需求分析对已经获取到的需求进行提炼、分析和审查，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。 3.面向对象的分析98k模型包括用例模型和分析模型
需求规格说明书的编制	**软件需求规格则书（SRS）**是需求开发活动的产物，编制该文档的目的是使项目干系人与立团队对系统的初始规定有一个共同的理解。
需求验证与确认	一般通过需求评审和需求测试工作来对需求进行验证。 👉需求评审:对SRS进行技术评审:二义性的或不确定性的需求,为项目干系人提供在需求问题上达成共识的方法。 👉需求测试:及早发现问题，从而在需求开发阶段以较低的代价解决这些问题。

4、使用SA方法进行需求分析，其建立的模型的核心是数据字典,围绕这个核心，有三个
层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。（22上9）

模型	表示图形	表示图形的作用
数据模型	实体联系图（E-R图）	描述实体、属性，以及实体之间的关系 【实数】
功能模型	数据流图（DFD）	从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况， 来说明系统所完成的功能 【能流】：（19下7） （20下8）
行为模型	状态转换图（STD）	通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作 【形状】

4、UML的结构包括构造块、规则和公共机制三个部分

5、UML中的事物也称为建模元素，包括结构事物、行为事物（也称动作事物）、分组事物和注释事物（也称注解事物）。

6、UML中的关系
（1）依赖：是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
（2）关联:描述一组对象之间连接的结构关系。分为组合和聚合，都是部分和整体的关系， 其中组合事物之间关：系更强，部分和整体之间有共同的生命周期。
（3）泛化：一般/特殊的关系，子类和父类之间的关系。继承关系是泛化关系的反关系， 也就是说，子类继承了父类，而父类则是子类的泛化
（4）实现：是类之间的语义关系，一个类元指定了另一个类元保证执行的契约。

7、UML14 种图（18 上 27）

图形	描述
用例图	描述一组用例、参与者及它们之间的关系。
类图	展现了一组对象、接口、协作和它们之间的关系。是最常见的图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图
对象图	描述一组对象及它们之间的关系。描述了在类图中所建立的事物实例的静态快照。
构件图	描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构
组合结构图	描述结构化类（例如，构件或类）的内部结构，包括结构化类与系统其余部分的交互点。用于画出结构化类的内部内容
顺序图（序列图）	一种交互图,交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图
通信图（协作图）	一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图强调的是时序， 通信图强调的是对象之间的组织结构
定时图（计时图）	一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序（17下26）
状态图	描述一个状态机，它由状态、转移、事件和活动组成。给出了对象的动态视图（18下27）
活动图	将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统敖力法视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程
部署图	描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图
制品图	描述计算机中一个系统的物理结构
包图	描述由模型本身分解而成的组织单元，以及它们之间的依赖关系
交互概览图	是活动图和顺序图的混合物。

8、UML5个系统视图：【记忆口诀：裸线不用进】

序	UML系统视图	解释说明
1	逻辑视图	也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分， 即类、子系统、自和用例实现的子集(17下27)
2	实现视图	对组成基于系统的物理代码的文件和构件进行建模
3	部署视图	把构件部署到一组物理节点上,表示软件到硬件的映射和分布结构
4	用例视图	是最基本的需求分析模型
5	进程视图	是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例， 描述了并发与同步结构

9、面向对象分析阶段的核心工作是建立系统的用例模型与分析模型。

10、在00A方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必须的。

11、用例之间关系
（1）包含关系:当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。
（2）扩展关系:是如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰
（3）泛化关系:当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。父子关系、一般和特殊关系。

12、类之间关系有关联、依赖、泛化、聚合、组合和实现

关系	解释说明
关联	提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。 现的是对象实例之间的关系，而不表示两个类之间的关系。(19上23)
依赖	两个类A和B,如果B的变化可能会引起A的变化，则称类A依赖于类B
泛化	描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。 继承关系是泛化关系的反关系，子类继承了父类，而父类则是子类的泛化
共享聚集	简称为聚合关系，它表示类之间的整体与部分的关系,其含义是"部分”可能同时属于多个“整体“部分"与"整体”的生命周期可以不相同。例如，汽车和车轮就是聚合关系，车子坏了，车轮还可以用；车轮坏了，可以再换一个新的。
组合聚集	简称为组合关系，它也是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分Ng杷属于一个“整体”，“部分”与“整体”的生命周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。例：一个公司包含多个部门， 它们之间的关系就是组合关系。公司一旦倒闭，也就没有部门了。
实现关系	将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。 一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。