湖科大 2022大三上 软件工程复习资料

前言

1. 湖科大 2022大三上 软件工程复习资料
2. 推荐参考 ffj笔记
3. 主要内容来源于老师画的重点和ppt；由于ppt知识点不详细，部分内容参考了《软件设计师教程》
4. 由于老师划重点不详细，笔记总体来说只是猜测哪些会考
5. ★超级重点；※补充内容，不一定重要；▲之前卷子出过题
6. 不要忽视了小标题，内容之间的关系也可能会出题（如：XX包括哪些？两个知识点之间的关系？）
7. 软工没怎么学通透，总结的不太清晰；有些知识点是东拼西凑加上个人理解而成

题型

1. 简答题，30分（名词要写定义解释）
2. 分析设计题，70分

考试范围

1-11章

第一部分 软件工程概述

软件★★

定义★▲

软件是能够完成预定功能和性能，并对相应数据进行加工的程序和描述数据及其操作的文档。

组成★▲

1. 程序

   指令的集合

2. 文本

   软件描述信息

3. 数据

   数据结构

特点★

与硬件相比的特性

抽象性

功能和性能需要通过运行才能体现。

无明显的制造过程

软件是设计开发的，不是制造的，大多数软件还是用户定制的。

不存在重复生产的产品质量差异；重复生产的成本较低。

无备件特征

不存在机械磨损、元件老化而需更换备件的现象。但会软件退化。

程序※

程序 = 算法 + 数据结构

软件工程★★

定义

软件工程(Software Engineering)是指导计算机软件开发和维护的工程学科。它将系统化的、规范的、可量化的⽅法应⽤于软件的开发、运⾏和维护，即将⼯程化⽅法应⽤于软件。

出现原因※

软件危机的出现

目的※▲

1. 克服软件危机
2. 用工程化的方法和规范来进行软件的开发，以提高软件开发的成功率
3. 作好软件开发的培训工作
4. 以较低的成本开发出高质量的软件

研究范围/内容

主要是技术方法、管理方法和开发工具。

基本原理

1. 用分阶段的生命周期计划严格管理

   统计发现，不成动的软件项目，有一半左右是由于计划不周造成的

2. 坚持阶段评审

   软件质量保证工作不能等到编码阶段结束之后再进行，必须坚持阶段评审

3. 实行严格的产品控制
   基本思路:软件修改建议必须经过严格规范评审,获得批准后才能实施,不能随意进行。

4. 采用现代程序设计技术
   如：结构程序设计技术，面向对象技术等。

5. 结果应能清楚地审查
   软件产品是逻辑产品，开发过程可见性差，难以评价和管理。

6. 开发小组人员应该少而精，开发人员素质要高，人数宜少。

7. 承认不断改进软件工程实践的必要性

软件工程方法学

通常把软件生命周期过程中使用的一整套技术的集合称为软件工程方法学(Methodology)，也称为范型(Paradigm)。

组成（三要素）▲

方法(如何做)、工具(支撑平台)和过程(工作步骤)。

计算机系统的四个发展阶段

早期阶段

六十年代中期以前，硬件应用很普遍，软件为每个具体应用而编写；软件就是规模很小的程序，没有系统化的方法和管理技术。

第二代计算机系统

六十年代中期到七十年代中期，多用户系统、实时系统等概念出现。重要特点是出现了“软件作坊”，软件数量剧增，没有技术规范，仅仅强调个人智慧，个体化特征明显。

第三代计算机系统

七十年代中期以后十年，计算机网络、通信的发展，对软件提出了更高的要求，微处理器的出现，使计算机成为了大众化的商品。

第四代计算机系统

八十年代中期以后至今。不再强调单台计算机程序，注重硬件和软件的综合效果，软件的开发强调使用工程化的方法，专家系统和人工智能得到广泛应用等等。

软件危机

定义★

软件危机(Software Crisis)是指是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

表现▲

1. 软件开发成本和进度难于估计
2. 用户对“已完成”的软件不满意
3. 软件质量不可靠
4. 软件的可维护性差
5. 软件文档资料不足
6. 软件成本在系统总成本中所占的比例逐年上升
7. 软件开发生产率提高的速度跟不上经济发展的速度和计算机应用迅速普及的速度

内容

1. 如何开发软件以满足日益增长的需要。
2. 如何维护不断膨胀的已有软件。

产生原因

既与软件本身的特点有关，也和软件开发和维护的方法不正确有关。

• 软件是逻辑产品而不是物理产品，进度和质量难于评价，开发过程难于管理和控制；
• 软件规模过于庞大，程序的复杂性随程序规模的增长而呈指数增长；
• 开发过程中或多或少地采用了错误的技术和方法(如忽视需求分析、认为开发软件就是写程序、轻视软件维护等)。

软件生命周期★★

定义

软件的生命周期(Software Life cycle Model)：软件的产生直到报废或停止使用的生命周期。

• 软件定义
  • 问题定义
  • 可行性分析
  • 需求分析
• 软件开发
  • 软件设计
    • 概要设计
    • 详细设计
  • 编码和单元测试
  • 综合测试
• 软件运行维护

问题定义阶段

确定要解决的问题。

可行性分析阶段

目的

用最小的代价在尽可能短的时间内判断上述问题是否有行得通的解决办法

实质

进行一次简化、压缩了的需求分析和设计过程，要在较高层次上以较抽象的方式进行需求分析和设计过程。

分类※

1. 技术可行性
2. 经济可行性
3. 操作可行性
4. 社会可行性

步骤▲

1. 复查系统规模和目标
2. 进一步定义问题
3. 研究正在使用的系统
4. 建立新系统的高层逻辑模型
5. 导出和评价各种方案
6. 推荐可行方案
7. 编写可行性研究报告

需求分析▲

目的

1. 确定用户需求
2. 确定目标系统的功能。
3. 确定完整准确的系统逻辑模型。
4. 防止和克服急于着手进行具体设计的倾向。

准则

1. 必须理解并描述问题的信息域
2. 必须定义软件的功能域
3. 必须描述软件的行为
4. 用层次的方法展示各种模型的细节

概要(总体)设计

任务

概括地提出解决问题的大体方案。一般应该考虑多种可行的解决方案

基本原理※

模块化★★

• 定义：把程序划分成独立命名且可独立访问的模块，降低模块的复杂度。
• 原因
  1. 模块化是软件的单一属性，它使程序能被智能化地管理
  2. 人难以理解和掌握单独模块构成的大型程序。
  3. 降低软件成本

抽象

• 定义：抽出事物的本质特性而不考虑实现细节。
• 分类：数据、过程、控制

逐步求精

在软件开发过程中，为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。

信息隐藏与局部化★

• 定义：设计和确定模块时，使得模块内包含的信息对于不需要这些信息的模块来说，是不能访问的。

  • 信息隐藏：将模块中的软件设计决策信息封装起来的技术，使外界只知道它的功能以及对外的接口，而不知它的内部细节。

• 原因

  1. 降低“副作用”的可能性；
  2. 减少局部设计决定对全局的影响；
  3. 突出控制接口处通信；
  4. 阻止全局数据使用；
  5. 促进封装——高质量设计的属性之一；
  6. 形成高质量软件；

模块独立性

每个模块完成一个相对独立的特定子功能，并且和其他模块之间的关系很简单。

详细设计

任务

1. 把总体设计方案具体化(即怎样具体地实现该系统/设计各个模块)。（PPT）
2. 确定每个模块的算法和使用的数据结构。（习题）

编码和单元测试

用一种适当的高级程序设计语言写出各模块的编码并对模块进行单元测试。

综合测试

任务

通过各类测试和相应的调试使软件达到预期要求。

组成

集成测试和验收测试。

软件维护（成本最高）

定义

在软件已经交付使用之后，通过各种维护活动使系统持久地满足用户要求。

目的

提高软件的可靠性、可用性、延长软件的寿命，使软件持久地满足用户的需要。

种类

改进性维护

诊断和改正软件错误；

适应性维护

修改软件以适应环境的变化；

完善性维护

根据用户要求改进或扩充软件/增加功能；（占维护活动工作量比例最高）▲

预防性维护

进一步改善软件的可靠性和易维护性，修改软件为将来的维护活动预先做准备。

可维护性※

定义

软件可维护性指的是维护人员对该软件进行维护的难易程度，具体包括理解、改正、改动和改进该软件的难易程度。

决定软件可维护性的因素

• 可理解性：软件可理解性表现为外来读者理解软件的结构、接口、功能和内部过程的难易程度。（是软件最重要的质量标准之一）
• 可测试性：诊断和测试的难易程度主要取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的。
• 可修改性：软件容易修改的程度设计原理和规则直接有关。耦合、内聚、局部化，控制域与作用域的关系等等，都影响软件的可修改性。
• 可移植性：一个程序被移植到一个新的计算环境的可能性的大小，或表明程序可以容易地、有效地在各种各样的计算环境中运行的程度。
• 可重用性：重用指同一事物不作修改或稍加改动就在不同环境中多次重复使用。大量使用可重用的软件构件来开发软件，可以明显提高软件可维护性。

副作用※

指由于维护或在维护过程中其他一些不期望的行为引入的错误

软件工程生命周期各个阶段对应的岗位※▲

自己写的答案，不一定对

1. 问题定义阶段、可行性分析阶段：产品经理
2. 需求分析：需求分析师
3. 概要(总体)设计、详细设计：系统分析师、软件设计师
4. 编码和单元测试、综合测试：开发工程师（程序员）、测试工程师
5. 软件维护：维护工程师

软件工程过程

概念

软件（工程）过程(Software Engineering Process)：软件开发中所遵循的路线图。

在开发产品或构建系统时，遵循一系列可预测的步骤（即路线图）是非常重要的，它有助于及时交付高质量的产品。

重要性

软件过程提高了软件工程活动的稳定性、可控性和有组织性

通用过程模型的五种框架活动

沟通、策划、建模、构建、部署

惯用过程模型★

★★简答题：常⽤的过程模型有：瀑布模型、原型模型、螺旋模型、增量过程模型、统⼀过程模型

瀑布模型

定义

瀑布模型/经典生命周期：将软件生存周期的各项活动规定为依固定顺序连接（瀑布般）的若干阶段工作。

即从用户需求规格说明开始，顺序地通过策划、建模、构建和部署过程，最终提供完整软件和持续技术支持。

应用

适用于功能、性能明确、完整、无重大变化的软件系统的开发。

例如操作系统、 编译系统、数据库管理系统等系统软件的开发。应用有一定的局限性。

前提

需求必须是准确定义和相对稳定的。

步骤

沟通：项目启动、需求获取
策划：项目估算、进度计划、项目跟踪
建模：分析、设计
构建：编码、测试
部署：交付、支持、反馈

优点

1. 容易理解
2. 管理成本低
3. 强调开发的阶段性早期计划及需求调查和产品测试

缺点

1. 在开发早期，用户难以清楚地确定所有需求
2. 开发人员与用户之间缺乏有效的沟通，难以快速响应用户需求变更
3. 需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算
4. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

V模型

是瀑布模型的改进，在开发的同时引入测试。

演化过程模型

迭代的过程模型，每次迭代产生软件的一个更完整的版本。

原型开发过程模型

原型

原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。

应用

适合于用户需求不清、需求经常变化、系统规模不是很大也不太复杂的情况。

优点

1. 变更需求对后续设计影响较小
2. 客户很早并频繁地参与其中
3. 对小型项目来说效果好
4. 产品失败的可能性降低

缺点

1. 客户的参与可能造成进度延误
2. “提交“一个原型，可能造成初步完成的假象
3. 若原型被抛弃导致工作白费
4. 很难计划和管理
5. 对软件设计和开发人员要求高

螺旋模型

定义

演进式，风险驱动的软件开发模型。结合了原型开发的迭代性质和瀑布模型的可控性和系统性特点。螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。

应用

适用于庞大、复杂并且具有高风险的系统。

优点

1. 设计上的灵活性,可以在项目的各个阶段进行变更
2. 以小的分段来构建大型系统,使成本计算变得简单容易
3. 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性
4. 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互
5. 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品

缺点

1. 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失
2. 过多的迭代次数会增加开发成本，延迟提交时间
3. 很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求

增量过程模型

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可运行的“增量”。早期的增量可以看做是最终产品的片段版本。

优点

1. 容易理解，管理成本低。

2. 强调开发的阶段性早期计划及需求调查和产品测试。

   增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点。

3. 第一个可交付版本所需要的成本和时间很少。

4. 开发由增量表示的小系统所承担的风险不大。

5. 减少用户需求的变更。

6. 运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。

缺点

1. 如果没有对用户的变更需求进行规划，那么产生的初始增量可能会造成后来增量的不稳定。
2. 如果需求不想早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布。
3. 管理发生的成本、进度和配置的复杂性可能会超出组织的能力。

统一过程模型★

统⼀过程（RUP/UP，Rational Unified Process）

特点★★

以用例和风险驱动，以架构为核心，迭代并且增量；由UML⽅法和⼯具⽀持，⼴泛应⽤于各类⾯向对象项⽬。

阶段★★

1. UP的起始阶段包括客户端沟通和策划活动。
2. 细化阶段包括沟通和通⽤过程模型的建模活动。
3. 构建阶段与通⽤软件过程中的构建活动相同。
4. 转换阶段包括通⽤构建活动的后期阶段以及通⽤部署活动的第⼀部分。
5. ⽣产阶段与通⽤过程的部署活动⼀致。

优点

1. 重视质量文档
2. 有持续不断的客户参与
3. 适合需求编程的情况
4. 对维护项目非常有效

缺点

1. 用例并不总是精确的
2. 具有复杂的软件增量集成
3. 阶段的重叠可能会带来问题
4. 需要一个专家开发团队

举例※

软件类型与需求	适合的开发过程
客户不太清楚待开发的系统需要提供什么服务	原型
开发团队了解待开发软件的相关领域知识,尽管此系统庞夫，但其较己经开发的系统差异并不大。	瀑布
软件的功能是把读入的浮点致开平方，所得到的结果应该精确到小数点后4位。	瀑布
开发一个已发布软件的新版本，公司规定了严格的完成期限，并对外公布。	增量
汽车防抱死刹车控制系统	螺旋
大学记账系统，准备替换一个已存在的系统	瀑布
一个位于火车站的交互式火车车次查询系统	原型

敏捷开发

定义★★

是一种软件开发方法论，可以应对客户快速变更的需求。它强调以人为核心，采用迭代的方式，循序渐进的开发软件。

敏捷开发宣言★

1. 个体与交互胜过过程与工具
2. 可用的软件胜过完备的文档
3. 客户协作胜过合同谈判
4. 响应变化胜过遵循计划

敏捷过程中“人”的因素

敏捷过程特别看重个人。要求团队成员以及团队本身必须具备以下一些特点：

1. 必要的基本能力：个人内在才能、特定的软件相关技能…
2. 共同目标：大家要认同这个目标，并为之奋斗精诚合作，互相交流
3. 决策能力：在技术和项目管理问题上的自主决策权，充分需要和充分享受模糊问题解决能力
4. 相互信任和尊重：主要指要包容自我组织的能力。如何分配，如何适应，如何安排进度精诚合作
5. 模糊问题解决能力：充分需要和充分享受模糊问题解决能力
6. 自我组织：组织自身以完成工作、适应当前环境、适应进度安排

敏捷开发适用的项目类型★

1. 由用户所需的应用场景驱动
2. 认识到计划时间很短
3. 使用增量式开发策略
4. 交付多个软件增量版本
5. 能做出适应性变更

典型的敏捷开发过程模型★

Scrum方法★

定义

并列争求法使用迭代的方法，按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。

冲刺

工作任务在相对较短的时间盒的期限内完成（每30天迭代一次），冲刺中进行的工作适应当前的问题，由Scrum团队规定并进行实时修改。

极限编程（eXtreme Programming，XP）

使用得最为广泛的敏捷过程

定义

XP是一种轻量级（敏捷)、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。

4大价值观

沟通、简单性、反馈和勇气。

5个原则

快速反馈、简单性假设、逐步修改、提倡更改和优质工作。

特点

1. 是一些相互关联的准则和惯例的集合
2. 追求变更曲线平坦化
3. 适合于小团队、高风险的项目

动态系统开发方法（Dynamic System Development Method，DSDM）

它倡导以业务为核心，快速而有效地进行系统开发。

敏捷建模

敏捷统一过程（Agile Unified Process，AUP）

定义

敏捷统一过程采用在“大型上连续”以及在“小型上迭代”的原理来构建软件系统，采用经典的UP性阶段活动（初始、精华、构建和转换），提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。在每个活动里，一个团队使用一个敏捷，并将有意义的软件增量尽可能快的交付给用户。

步骤

1. 建模。建立对商业和问题域的模型描述，这些模型”足够好“即可，以便团队继续更近。
2. 实现。将模型翻译成源代码。
3. 测试。像XP一样，团队设计和执行一系列的测试来发现错误以保证源代码满足需求。
4. 部署。对软件增量的交付以及获取最终用户的反馈。
5. 配置及项目管理。着眼于变更管理、风险管理以及对团队的任一制品的控制。项目管理追踪和控制开发团队的工作进展并协调团队活动。
6. 环境管理。协调标准、工具以及使用于开发团队的支持技术等过程基础设施。

自适应软件开发（Adaptive Software Development，ASD）

强调开发方法的适应性，这一思想来源于复杂系统的混沌理论。ASD不像其他方法那样有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。

水晶法(Crystal)

水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论，认为人对软件质量有重要的影响，因此随着项目质量和开发人员素质的提高，项目和过程的质量也随之提高。通过更好地交流和经常性的交付，软件生产力得到提高。

特征驱动开发(FDD)

是一套针对中小型软件开发项目的开发模式，它强调简化、实用、易于被开发团队接受，适用于需求经常变动的项目。

精益软件开发(LSD)

在创造价值的目标下，通过改良流程不断地消除浪费。

第二部分 建模

需求工程

考点：某个自己开发过的软件系统/网站，需要考虑到哪些利益相关者并说明理由；描述需求

确认利益相关者★

管理学意义上的利益相关者（stakeholder）是组织外部环境中受组织决策和行动影响的任何相关者。

步骤

1. 根据利益相关者制定访谈计划
2. 实施并记录访谈内容
3. 分析并进一步需求诱导
4. 利用Axure等原型工具开发原型，进行需求迭代与确认

需求建模

组成※

面向数据流的分析方法（dataflow-oriented analysis method）

• 举例
  • 结构化分析与设计方法，它以数据流为中心构建软件的分析模型和设计模型。
    • 强调程序易读性
    • 组成
      • 结构化分析(Structured Analysis，SA)
        • 工具：数据流图
      • 结构化设计(Structured Design，SD）
      • 结构化程序设计(Structured Programming Design，SPD)

面向数据（过程）的分析方法

面向对象的分析方法（object-oriented analysis method）。

需求分析

1. 产生软件工作特征的规格说明
2. 指明软件和其他系统元素的接口
3. 规定软件必须满足的约束

数据流图★★

定义

数据流图也称数据流程图（Data Flow Diagram，DFD），它是一种便于用户理解、分析系统数据流程的图形工具。它摆脱了系统的物理内容，精确地在逻辑上描述系统的功能、输入、输出和数据存储等，是系统逻辑模型的重要组成部分。

图形元素

符号

外部实体（外部主体)

定义

外部实体是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地（源）和系统所产生的数据的归宿地（宿)。

举例

对于一个考务处理系统而言，考生向系统提供报名单(输入数据流)，所以考生是考务处理系统的一个源；而考务处理系统要将考试成绩的统计分析表（输出数据流）传递给考试中心，所以考试中心是该系统的一个宿。

加工

定义

加工描述了输入数据流到输出数据流之间的变换，也就是输入数据流经过什么处理后变成了输出数据流。每个加工都有一个名字和编号。编号能反映出该加工位于分层DFD 中的哪个层次和哪张图中，也能够看出它是哪个加工分解出来的子加工。

格式要求

一个加工可以有多个输入数据流和多个输出数据流，但至少有一个输入数据流和一个输出数据流。

数据存储

定义

数据存储用来存储数据。通常，一个流入加工的数据流经过加工处理后就消失了，而它的某些数据（或全部数据）可能被加工成输出数据流，流向其他加工或外部实体。除此之外，在软件系统中还常常要把某些信息保存下来以供以后使用，这时可以使用数据存储。

举例

在考务处理系统中，报名时产生的考生名册要随着报名的过程不断补充，在统计成绩和制作考生通知书时还要使用考生名册的相关信息。因此，考生名册可以作为数据存储存在，以保存相关的考生信息。

数据流

定义

数据流由一组固定成分的数据组成，表示数据的流向。

数据流的流向

1. 从一个加工流向另一个加工；
2. 从加工流向数据存储（写）；
3. 从数据存储流向加工（读）；
4. 从外部实体流向加工（输入）；
5. 从加工流向外部实体（输出）。

要求

DFD中的每个数据流用一个定义明确的名字表示。除了流向数据存储或从数据存储流出的数据流不必命名外，每个数据流都必须有一个合适的名字，以反映该数据流的含义。

常见错误

黑洞

加工有输入无输出

白洞

加工有输出无输入

灰洞

加工的输入不足以产生输出

举例

例题

某医院打算开发一个以计算机为中心的患者监护系统，医院对患者监护系统的基本要求是随时接收每个病人的生理信号〈脉搏、体温、血压、心电图等)，定时记录病人情况以形成患者日志，当某个病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息，此外，护士在需要时还可以要求系统印出某个指定病人的病情报告。请用数据流图描绘本系统的功能。

分层数据流图的画法

例题

下面以某考务处理系统为例介绍分层数据流图的画法。

考务处理系统的功能需求如下。

1. 对考生送来的报名单进行检查。
2. 对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站。
3. 对阅卷站送来的成绩清单进行检查，并根据考试中心指定的合格标准审定合格者。
4. 制作考生通知单（内含成绩合格/不合格标志）送给考生。
5. 按地区、年龄、文化程度、职业和考试级别等进行成绩分类统计和试题难度分析，产生统计分析表。

部分数据流的组成如下。

1. 报名单=地区＋序号＋姓名＋文化程度＋职业＋考试级别＋通信地址
2. 正式报名单=准考证号＋报名单
3. 准考证=地区＋序号＋姓名＋准考证号＋考试级别＋考场
4. 考生名单={准考证号＋考试级别} （其中，{w}表示w重复多次）
5. 考生名册=正式报名单
6. 统计分析表=分类统计表＋难度分析表
7. 考生通知单=准考证号＋姓名＋通信地址＋考试级别＋考试成绩＋合格标志

步骤

1）画系统的输入和输出

系统的输入和输出用顶层图来描述，即描述系统从哪些外部实体接收数据流，以及系统发送数据流到哪些外部实体。

顶层图只有一个加工，即待开发的软件系统。顶层图中的数据流就是系统的输入/输出信息。顶层图中通常没有数据存储。

---

考务处理系统的顶层图

顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据

---

2）画系统的内部

将顶层图的加工分解成若干个加工，并用数据流将这些加工连接起来，使得顶层图中的输入数据经过若干个加工处理后变换成顶层图的输出数据流，这张图称为0层图。从一个加工画出一张数据流图的过程实际上就是对这个加工的分解。

(1）确定加工。

这里的加工指的是父图中某加工分解而成的子加工，可以采用下面两种方法来确定加工。

1. 根据功能分解来确定加工。

   一个加工实际上反映了系统的一种功能，根据功能分解的原理，可以将一个复杂的功能分解成若干个较小的功能，每个较小的功能就是分解后的子加工。这种方法多应用于高层 DFD中加工的分解。

2. 根据业务处理流程确定加工。

   分析父图中待分解的加工的业务处理流程，流程中的每一步都可能是一个子加工。特别要注意在业务流程中数据流发生变化或数据流的值发生变化的地方，应该存在一个加工，该加工将原数据流（作为该加工的输入数据流〉处理成变化后的数据流（作为该加工的输出数据流)。该方法较多应用于低层 DFD中加工的分解，它能描述父加工中输入数据流到输出数据流之间的加工细节。

(2）确定数据流。

当用户把若干个数据看作一个整体来处理（这些数据一起到达，一起加工）时，可以把这些数据看成一个数据流。通常，实际工作环境中的表单就是一种数据流。

在父图中某加工分解而成的子图中，父图中相应加工的输入/输出数据流就是子图边界上的输入/输出数据流。另外，在分解后的子加工之间应增添一些新的数据流，这些数据流是加工过程中的中间数据（对某子加工输入数据流的改变)，它们与所有的子加工一起完成了父图中相应加工的输入数据流到输出数据流的变换。如果某些中间数据需要保存，以备使用，那么可以表示为流向数据存储的数据流。

同一个源或加工可以有多个数据流流向另一个加工，如果它们不是一起到达和一起加工的，那么可以将它们分成多个数据流。同样，同一个加工也可以有多个数据流流向另一个加工或宿。

(3）确定数据存储。

在由父图中某加工分解而成的子图中，如果父图中该加工存在流向数据存储的数据流（写操作)，或者存在从数据存储流向该加工的数据流（读操作)，则这种数据存储和相关的数据流都画在子图中。

在分解的子图中，如果需要保存某些中间数据，以备以后使用，那么可以将这些数据组成一个新的文件。在自顶向下画分层数据流图时，新数据存储（首次出现的）至少应有一个加工为其写入记录，同时至少存在另一个加工读取该数据存储的记录。

注意，对于从父图中继承下来的数据存储，在子图中可能只对其读记录，或者写记录。

(4）确定源和宿。

通常在0层图和其他子图中不必画出源和宿，有时为了提供可读性，可以将顶层图中的源和宿画在0层图中。

当同一个外部实体（人或组织）既是系统的源，又是系统的宿时，可以用同一个图形符号来表示。为了画图的方便，避免图中线的交叉，同一个源或宿可以重复画在DFD的不同位置，以增加可读性，但它们仍代表同一个实体。

---

考务处理系统的0层图

在考务处理系统的0层图中，采用功能分解方法来确定加工。分析系统的需求说明，可知系统的功能主要分为考试报名及统计成绩两大部分，其中，报名工作在考试前进行，统计成绩工作在考试后进行。

为此，定义两个加工：登记报名表和统计成绩。0层图中的数据流，除了继承顶层图中的输入/输出数据流外，还应定义这两个加工之间的数据流。由于这两个加工分别在考试前后进行，并不存在直接关系，因此，“登记报名表”所产生的结果“考生名册”应作为数据存储，以便考试后由“统计成绩”读取。

---

3）画加工的内部

当DFD中存在某个比较复杂的加工时，可以将它分解成一张DFD子图。分解的方法是将该加工看作一个小系统，该加工的输入/输出数据流就是这个假设的小系统的输入/输出数据流，然后采用画0层图的方法画出该加工的子图。

---

1. 考务处理系统0层图中加工1的分解是根据业务处理流程来确定的。分析考务处理系统的功能需求和0层图，将加工1分解成3个子加工：检查报名表、编准考证号和登记考生。加工1分解而成的子图如图（c）所示。

   

2. 采用同样的方法画出加工2分解的DFD子图，如图（d）所示。

   

3. 重复第3）步的分解，直到图中尚未分解的加工都足够简单（也就是说，这种加工不必再分解)。

   这里假设图 ©、(d)中的每个加工都已经足够简单，不需要再分解，该考务处理系统的分层DFD绘制工作结束。

---

例题※

1. 用SA方法画出下列问题的顶层和0层数据流图。某运动会管理系统接受来自运动员的报名单、裁判的比赛项目及项目成绩，产生运动员号码单发送给运动员，项目参加者发送给裁判，单项名次、团体名次发送给发布台。 该系统有两部分功能：

   1. 登记报名单：接受报名单、比赛项目，产生运动员号码单、项目参加者，形成运动员名单及团体成绩表两种数据存储。
   2. 统计成绩：接受项目成绩，查询运动员名单，产生单项名次，填写团体成绩，最后产生团体名次。

   

2. 某培训中心要研制一个计算机管理系统。它的业务是：

   将学员发来的信件收集分类后，按几种不同的情况处理。

   1. 如果是报名的，则将报名数据送给负责报名事务的职员，他们将查阅课程文件，检查该课程是否额满，然后在学生文件、课程文件上登记，并开出报告单交财务部门，财务人员开出发票给学生。
   2. 如果是想注销原来巳选修的课程，则由注销人员在课程文件、学生文件和帐目文件上做相应的修改，并给学生注销单。
   3. 如果是付款的，则由财务人员在帐目文件上登记，也给学生一张收费收据。

   要求:

   1. 对以上问题画出数据流图。

      

   2. 画出该培训管理的软件结构图。

      

数据字典▲

定义

数据字典（Data dictionary）对数据的数据项、数据结构、数据流、数据存储、处理逻辑等进行定义和描述，是对系统中使用的所有数据元素的定义的集合。

条目

数据流、数据项、数据存储、基本加工

符号※

例题

某旅馆的电话服务如下：可以拨分机号和外线号码。分机号是从7201至7299。外线号码先拨9，然后是市话号码或长话号码。长话号码是以区号和市话号码组成。区号是从100到300中任意的数字串。市话号码是以局号和分局号组成。局号可以是455，466，888，552中任意一个号码。分局号是任意长度为4的数字串。
写出在数据字典中，电话号码的数据条目的定义(即组成)。

电话号码=[分机号|外线号码]
分机号=7201…7299
外线号码=9 +[市话号码|长话号码]
长话号码=区号+市话号码
区号=100…300
市话号码=局号+分局号
局号=[455|466|888|552]
分局号=4{0…9}4

分类（UML）★★

1. 场景模型

   出自各种系统“参与者”观点的需求

2. 数据模型

   描述问题信息域的模型

3. 面向类的模型

   表示面向对象类（属性和操作）的模型

4. 面向流程的模型

   描述功能元素在系统中运行时怎样进行数据变换

5. 行为模型

   描述如何将软件行为看作是外部“事件”的后续

必须掌握★，注意格式不要弄错

类图★

组成

类名、属性、方法、类间关系

类间关系

依赖

• 定义

  依赖是一种使用（暂时）的关系，即一个类的实现需要另一个类的协助。

• 格式

  UML中使用带箭头的虚线表示依赖关系，通常是单向的。

• 特点

  依赖具有偶然性、临时性，是非常弱的关系。简单理解就是类A使用到了类B，使用完毕后关系解除。

• 代码表现

  方法参数、局部变量、静态方法的调用。

关联

• 定义

  关联是一种拥有（一段时间）的关系，它使一个类知道另一个类的属性和方法，是一种长期性、相对平等的关系

• 格式

  关联可以有双向(实线)和导航(单向箭头)，关联的两端可以标注重数(基数)，表示类之间的数量对比关系

• 代码表现：成员变量

  

• 关联类

  和类一样，关联也可以有自己的属性和操作。此时，这个关联实际上是个关联类（association class）

  

聚合（aggregation）

• 定义

  聚合是表示整体的类和表示部分的类之间的“整体–部分”关系，是一种强类型的关联。

  在聚合关系中，把作为“整体”的类称为聚集（aggregate），作为“部分”的类称为成分

• 格式

  聚合关系中的整体和部分之间用带空心菱形箭头的连线连接，箭头指向整体。

组合（composition）

• 定义

  组合是更强类型的聚合，要求部分的生存周期取决于整体的生存周期，部分不能脱离整体而单独存在，每个部分只能属于一个整体

• 格式

  除了菱形是实心之外，组合和聚合的表示法相同

  

继承（generalization）

• 定义

  继承也称泛化，是面向对象描述类之间相似性的一种重要机制

• 格式

  父类与子类的泛化（generalization）关系图示为一个带空心三角形的直线，空心三角形紧挨着父类。

实现（Realization）

• 定义

  在类图中就是接口和实现的关系。

• 格式

  在类图中使用带三角箭头的虚线表示，箭头从实现类指向接口。

类关系由弱到强次序及表示

基于类建模

1. 分析类表现为如下方式之一
   1. 外部实体（例如，其他系统、设备、人员），产生或使用基于计算机系统的信息。
   2. 事物（例如，报告、显示、字母、信号），问题信息域的一部分。
   3. 偶发事件或事件（例如，所有权转移或完成机器人的一组移动动作），在系统操作环境内发生。
   4. 角色（例如：经理、工程师、销售人员），由和系统交互的人员扮演。
   5. 组织单元（例如，部门、组、团队），和某个应用系统相关。
   6. 场地（例如：制造车间或码头），建立问题的环境和系统的整体功能。
   7. 结构（例如：传感器、四轮交通工具、计算机），定义了对象的类或与对象相关的类。
2. 潜在类的特征
   1. 保留信息。只有记录潜在类的信息才能保证系统正常工作，在这种分析过程中的潜在类是有用的。
   2. 所需服务。潜在类必须具有一组可确认的操作，这组操作能用某种方式改变类的属性值。
   3. 多个属性。在需求分析过程中，焦点应在于“主”信息；事实上，只有一个属性的类可能在设计中有用，但是在分析活动阶段，最好把它作为另一个类的某个属性。
   4. 公共属性。可以为潜在类定义一组属性，这些属性适用于类的所有实例。
   5. 公共操作。可以为潜在类定义一组操作，这些操作适用于类的所有实例。
   6. 必要需求。在问题空间中出现的外部实体，和任何系统解决方案运行时所必需的生产或消费信息，几乎都被定义为需求模型中的类。

例题

1. 一家图书馆藏有书籍、杂志、小册子、电影录像带、音乐CD、录音图书磁带和报纸等出版物，供读者借阅。这些出版物有出版物名、出版者、获得日期、目录编号、书架位置、借出状态和借出限制等属性，并有借出、收回等公共服务。此外这些出版物还存在特有属性，如：书籍有作者属性、杂志有日期属性、小册子有作者属性、电影录像带有电影名属性、音乐CD有演员名属性、录音图书磁带有作者属性，报纸有日期属性。请为图书馆馆藏出版物建立对象模型。

   

2. UML关系包括关联、聚合、泛化、实现、依赖等5种类型，请将合适的关系填写在下列描述的（ ）中。

   1. 在学校中，一个导师可以指导多个研究生，一个研究生可以由多个导师指导，那么导师和研究生之间是（关联）关系。

   2. 交通工具与卡车之间是（泛化）关系。

   3. 公司与部门之间是（组合）关系。

      网上答案是聚合，但是我感觉部门不能脱离公司存在，感觉更像组合

   4. 图形与矩形之间是（泛化）关系。

   5. 参数类及其实例类之间是（实现）关系。

对象图(Object Diagram)

对象图是类图的实例，几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例，而不是实际的类

用例图★

考点：给一个系统，识别出参与者有哪些，参与者对应的用例有哪些，给出用例描述（基本事件流、异常流、分支流）并绘制用例图

定义

从用户角度描述系统功能， 是用户所能观察到的系统功能的模型图，用例是系统中的一个功能单元

用例（Use Case）★

识别用例，用例设计和描述

用例是描述参与者如何使用系统来达到目标的一组成功场景和失败场景的集合。通过用户和系统的交互，用例向用户提供有价值的结果值。

参与者（Actor）

参与者是人员或设备在特定的环境内所扮演的角色。用户可在给定场景中扮演多个角色。

用例描述

基本事件流

基本流表示最主要、最频繁使用的、默认的业务流程分支。

异常流

异常流表示非正常的、不是业务目标期待的、容错性的、处理意外情况的业务流程分支。

分支流

分支流是进行判断后走进的业务流程分支。

关系

关联关系（Association）

包含关系（include）

箭头出发的用例为基用例；

特点

• 包含用例（客户用例）执行，则被包含用例（提供者用例）必须执行

扩展关系（extend）

箭头指向的用例为基础用例；

特点

• 没有基础用例，扩展用例也是完整的用例
• 基础用例被执行时，一般不会涉及扩展用例，只有特定的条件发生，扩展用例才可能被执行，这是与包含关系的差别

泛化关系（Generalization）

举例

• 科技处合同审批系统

  • 目前学校有企业项目，教师跟对方拟定合同后需要所在学院科研副院长签字，然后请学校的法律顾问进行审查无误进行签字。如果金额小于500万元，直接科技处领导审批，然后双方盖章后生效。如果大于500万元需要科技处审核后，主管校领导审批。
  • 项目发起人将上述线下流程转为线上进行。

• 用例图

  

• 用例描述

  • 用例

  • 主参与者

  • 情景目标

  • 前提条件

  • 触发器

  • 基本事件流

  • 异常流

    教师撤销合同就是一个异常。

  • 分支流

  • 场景

    

    

• 航空售票的用例图

  

  ²参与者(actor)：clerk，监督员，信用卡服务商，信息亭

  ²用例(use case)： Buy tickets， Buy Subscription， Make charges， Survey sales

  ²参与者Clerk参与(或称发起)Buy tickets和Buy Subscription 两个用例(关联关系)。这两个用例的事件流都包含Make

  charges用例(包含关系)。

  ²系统由：Buy tickets， Buy Subscription， Make charges， Survey sales组成。

  ²该系统主要包含：Buy tickets， Buy Subscription， Make charges， Survey sales这几个功能。

  ²该系统主要面向的用户(参与者)：clerk，监督员，信用卡服务商，信息亭。

状态图★

考点：列举某个类某个对象所有的状态，状态之间转换的事件/条件，绘制状态图

定义

状态图是一个类对象所可能经历的所有历程的模型图。

状态转换图三要素

事件(event)

• 引发 object 状态改变的控制信息（瞬时）。
• 状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。

状态(status)

• 即 object 的 attributes 所处的情形（可持续）。
• 事件是某个特定时刻发生的事情，它是引起系统做动作或状态转换的控制信息。
• 经常使用3种标准事件：entry、exit和do

行为(action)

Object 要达到某种 status 所做的操作（耗时）。

格式

• 初态(一个)、终态(0至多个)、中间状态
• 表示系统循环运行过程：不关心循环是怎样启动的
• 表示系统单程生命期：要标明初态和终态

举例

1. 复印机工作的状态转换图★

   办公室复印机的工作过程大致如下:未收到复印命令时处于闲置状态,一旦接收到复印命令则进入复印状态,完成一个复印命令规定的工作后又回到闲置状态,等待下一个复印命令。如果执行复印命令时发现缺纸,则进入缺纸状态,发出警告,等待装纸,装满纸后进入闲置状态,准备接收复印命令;如果复印时发生卡纸故障,则进入卡纸状态,发出警告,等待维修人员来排除故障,故障排除后回到闲置状态。请用状态转换图描绘复印机的行为。

   

2. ControlPanel类的状态图（某个系统中针对某个类画出其状态转换图）

   

考点：给出顺序图，描述处理流程

顺序图★

²顺序图用来表示用例中的行为顺序。当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或状态机中引起转换的事件。

²顺序图展示对象之间的交互，这些交互是指在场景或用例的事件流中发生的。 顺序图属于动态建模。

²顺序图的重点在消息序列上，也就是说，描述消息是如何在对象间发送和接收的。表示了对象之间传送消息的时间顺序。

²浏览顺序图的方法是：从上到下查看对象间交换的消息。

序列图根据时间序列展示对象如何进行协作。它展示了在用例的特定场景中，对象如何与其他对象交互。

元素

举例

活动图★

举例

​ 本活动图描述一个处理订单的用例执行过

(1)执行setup order

(2)根据order的类型是执行不同的分支：

​ single order：执行assign seat、charge credit card

​ subscription：同时执行assignseats、debit account或

​ award bonus

​ single order与subscription两步可同时进行

(3) 最后mail packet。

本例为一个按活动职责(带泳道)组织的处理订单用例的活动图(模型中的活动按职责组织)。活动被按职责分配到用线分开的不同区域(泳道)：

Customer

Sales

Stockroom

(1)顾客要求服务，Sales负责接收定

​ 单，并提交到Stockroom

(2) Stockroom处理定单，与此同时，

​ Customer付款，并由Sales处

​ Deliverorder至Customer。

泳道图

定义

活动图(Activity Diagram)是描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。活动图在本质上是一种流程图。

活动图是描述系统为完成某项功能而执行的操作序列，操作序列可以并发和同步。它描述活动的顺序，展现从一个活动到另一个活动的控制流。

活动图中包含控制流和信息流。控制流表示一个操作完成后对其后续操作的触发，信息流则刻画操作之间的信息交换。

元素

名称	解释	图
初始节点	标记业务流程的开始，有且只有一个初始状态，用实心的圆点表示
终止节点	表示业务流程的终止，可以有一个或多个用一个实心圆外加一个圆圈表示
活动	业务流程中的执行单元
判断/合并	根据某个条件进行决策，执行不同的流程分支。合并指的是两个或多个控制路径在此汇合的情况。合并和判断常常成对使用。在任何执行中每次直走一条，不同路径间互斥
分叉	分叉用于表示将一个控制流分成两个或者多个并发运行的分支；
结合	结合用来表示并行分支在此得到同步，先完成的控制流需要再次等待，只有当所有的控制流都到达结合点，控制才能继续向下进行
转换/迁移	当一个活动结束时，控制流会马上传递给下一个活动节点，在活动图中称之为”转换“，用一条带箭头的直线来表示
泳道	代表了一个特定的类、人、部分、层次等等对象的职责区，每个泳道代表特定含义的状态职责的部分。在活动图中，每个活动只能明确的属于一个泳道，泳道明确的表示了哪些活动是由哪些对象进行的。

协作图(Collaboration Diagram)

actor发送Print消息给Computer，Computer发送Print消息给PrintServer，如果打印机空闲，PrintServer发送Print消息给printer

※协作图描述对象间的协作关系，协作图跟顺序图 相似，显示对象间的动态合作关系。除显示信息交换外，协作图还显示对象以及它们之间的关系.

※协作图的一个用途是表示一个类操作的实现

构件图/组件图(Component Diagram)

举例

图中的构件名称是Dictionary字典。

该构件向外提供两个接口，即两个服务Spell-check拼写检查、Synonyms同义词。

图中“Planner计划者”构件向外提供一个“update更新”接口服务。

同时，该构件要求外部接口提供一个“Reservations预定”服务。

※构件图为系统的构件建模型—构件即构造应用的软件单元—还包括各构件之间的依赖关系，以便通过这些依赖关系来估计对系统构件的修改给系统可能带来的影响

事物

关系

部署图(Deployment Diagram)

部署视图描述位于节点实例上的运行构件实例的安排。节点是一组运行资源，如计算机、设备或存储器。这个视图允许评估分配结果和资源分配

各UML图的关系

软件工程设计

内容

1. 数据/类设计——将分析类模型变换为软件实现类模型及数据结构
2. 体系结构设计——描述软件主要构造元素之间的关系
3. 接口设计——描述软件元素、硬件元素和终端用户间如何通信
4. 构件级设计——将软件体系结构的构造元素变换为对软件构件的过程性描述

基本概念

体系结构★★

• 软件的整体结构
• 是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件

模式

传递已验证设计方案的精髓

关注点分离

任何复杂问题在被分解为若干块后将更易处理

功能独立

单一功能和低耦合

衡量指标

内聚性和耦合性

内聚和耦合是密切相关的，模块内的高内聚往往意味着模块间的松耦合。实践表明内聚更重要，应该把更多注意力集中到提高模块的内聚程度上。

内聚性★

• 定义★★

  • 标志一个模块内各个元素彼此结合的紧密程度。

    它是信息隐藏和局部化概念的自然扩展。简单地说，理想内聚的模块只做一件事情。

  • 传统观点：构件的专⼀性

  • ⾯向对象的观点：内聚性意味着构件或类只封装那些相互关联密切，以及与构件或类⾃身有密切关系的属性和操作。

• 分类★★

  偶然/巧合性内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、
  顺序/信息内聚、功能内聚

• 对于内聚，禁止使用偶然性和逻辑性内聚，限制使用时间性内聚，少用过程性内聚和通信性内聚，提倡使用顺序内聚和功能内聚

偶然/巧合性内聚(coincidental cohesion)

• 定义

  如果一个模块完成一组任务，这些任务彼此间即使有关系，关系也是很松散的，就叫做偶然内聚。

• 评价

  • 模块内各元素之间没有实质性联系，很可能在一种应用场合需要修改这个模块，在另一种应用场合又不允许这种修改，从而陷入困境；
  • 可理解性差，可维护性产生退化；
  • 模块是不可重用的。

• 解决方案

  将模块分成更小的模块，每个小模块执行一个操作。

逻辑内聚(logical cohesion)

• 定义

  如果一个模块完成的任务在逻辑上属于相同或相似的一类，则称为逻辑内聚。

• 评价

  • 接口难以理解，造成整体上不易理解；
  • 完成多个操作的代码互相纠缠在一起，即使局部功能的修改有时也会影响全局，导致严重的维护问题；
  • 难以重用。

• 解决方案

  模块分解。

时间内聚(temporal cohesion)

• 定义

  如果一个模块包含的任务必须在同一段时间内执行，就叫时间内聚。

• 评价

  • 时间关系在一定程度上反映了程序某些实质，所以时间内聚比逻辑内聚好一些。
  • 模块内操作之间的关系很弱，与其他模块的操作却有很强的关联。
  • 时间内聚的模块不太可能重用。

过程内聚(procedural cohesion)

• 定义

  如果一个模块内的处理元素是相关的，而且必须以特定次序执行，即使两者之间没有数据进行传递，则称为过程内聚。

  使用程序流程图作为工具设计软件时，常常通过研究流程图确定模块的划分，这样得到的往往是过程内聚的模块。

• 评价

  • 比时间内聚好，至少操作之间是过程关联的。
  • 仍是弱连接，不太可能重用模块。

• 解决方案

  分割为单独的模块，每个模块执行一个操作。

通信内聚(communicational cohesion)

• 定义

  模块中所有元素都使用同一个输入数据和（或）产生同一个输出数据。即在同一个数据结构上操作。

• 评价

  • 模块中各操作紧密相连，比过程内聚更好。
  • 不能重用。

• 解决方案

  分成多个模块，每个模块执行一个操作。

顺序/信息内聚(sequential cohesion)

• 定义

  如果一个模块内的各个成分和同一个功能密切相关，而且这些处理必须顺序执行，一个成分的输出作为另一个成分的输入，则称为顺序内聚。

• 评价

  根据数据流图划分模块时，通常得到顺序内聚的模块，这种模块彼此间的连接往往比较简单。

功能内聚(functional cohesion)

• 定义

  如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚。功能内聚是最高程度的内聚。

• 评价

  • 模块可重用，应尽可能重用；
  • 可隔离错误，维护更容易；
  • 扩充产品功能时更容易。

耦合性★

• 定义★★

  耦合性是程序结构中各个模块之间相互依赖的度量，它取决于各个模块之间接口的复杂程度、调用模块的方式以及哪些信息通过接口。

• 分类★★

  非直接耦合/完全独立、数据耦合、控制耦合、公共环境耦合、内容耦合

• 对于耦合，尽量使用非直接耦合、数据耦合和特征耦合，少用控制耦合和外部耦合限制使用公共耦合，完全不用内容耦合

非直接耦合/完全独立(no direct coupling)

• 定义

  如果两个模块中的每一个都能独立地工作而不需要另一个模块的存在，那么它们完全独立。

• 评价

  在一个软件系统中不可能所有模块之间都没有任何连接。

数据耦合(data coupling)

类似于高级语言中的值传递

• 定义

  如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据，那么这种耦合称为数据耦合。

• 标记耦合/数据结构耦合/特征耦合（stamp coupling）

  • 定义

    • 几个模块间数据结构作为参数进行传递，共享数据结构，就称为印记耦合。印记耦合是数据耦合的一个变种。
    • 当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时，就出现了特征耦合。

    类似于高级语言中的引用传递，其实传递的是这个数据结构的地址

  • 评价

    • 被调用的模块可使用的数据多于它确实需要的数据，这将导致对数据的访问失去控制，从而给计算机犯罪提供了机会。
    • 无论何时把指针作为参数进行传递，都应该仔细检查该耦合。

• 评价

  • 系统中至少必须存在这种耦合。一般说来，一个系统内可以只包含数据耦合。

  • 数据耦合是理想的目标。维护更容易，对一个模块的修改不会是另一个模块产生退化错误。

控制耦合(control coupling)

• 定义

  如果两个模块彼此间传递的信息中有控制信息，这种耦合称为控制耦合。

• 评价

  • 控制耦合往往是多余的，把模块适当分解之后通常可以用数据耦合代替它。
  • 被调用的模块需知道调用模块的内部结构和逻辑，降低了重用的可能性 。

公共环境耦合(common coupling)

• 定义

  当两个或多个模块通过一个公共数据环境相互作用时，它们之间的耦合称为公共环境耦合。公共环境可以是全程变量、共享的通信区、内存的公共覆盖区、任何存储介质上的文件、物理设备（也有将共享外部设备分类为外部耦合）等等。

• 类型

  

  • 一个模块往公共环境送数据，另一个模块从公共环境取数据。数据耦合的一种形式，是比较松散的耦合。
  • 两个模块都既往公共环境送数据又从里面取数据，这种耦合比较紧密，介于数据耦合和控制耦合之间。

• 评价

  • 与结构化编程矛盾，生成的代码完全不可读。
  • 一旦公共数据有变化，与之有关的模块都应随之而修改,增加了维护的工作量及难度
  • 如果在一个模块中对一个全局变量的声明进行修改，必须修改能够访问该全局变量的每一个模块。
  • 公共环境耦合的模块难于重用，必须提供一个全局变量的清单。
  • 即使模块本身不改变，它和产品中其他模块之间公共环境耦合的实例数也会变化非常大。
  • 潜在危险很大。模块暴露出必需要更多的数据，难以控制数据存取，而且会导致计算机犯罪。
  • 有些情况下公共环境耦合更好。

内容耦合(content coupling)

• 定义

  最高程度的耦合是内容耦合。

• 如果出现下列情况之一，两个模块间就发生了内容耦合

  • 一个模块访问另一个模块的内部数据；
  • 一个模块不通过正常入口转到另一个模块的内部；
  • 两个模块有一部分程序代码重叠；（只可能出现在汇编语言中）
  • 一个模块有多个入口。

求精

细化所有抽象的细节

方面

理解全局需求如何影响设计的机制

重构

简化设计的重组技术

设计类

提供设计细节以实现分析类

实体类

分析类在设计中会被精化为实体类

边界类

在设计中被用于创建用户在实用软件时所观看并交互的接口（例如交互窗口或打印机接口等）

控制类

用于管理

• 实体对象的创建或更新；
• 从实体对象获得信息后的边界对象实例化;
• 各对象间的复杂交流；
• 对象间或用户与应用间数据交流的确定性

特征

完整性

封装所有必要的属性和方法

充分性

只包含那些“对实现这个类的目的足够”的方法

原始性

一个设计类相关的方法集中实现某一 个服务

高内聚性

小型，集中，专一类

低耦合性

类聚合保持最小范围

分析模型与设计模型关系

体系结构设计

定义★★

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

类型（genre）

隐含了在整个软件领域中的一个特定类别。

体系结构风格

定义

每种风格描述一种系统类别，包括：

1. 完成系统需要的某种功能的一组构件（例如，数据库、计算模块）；
2. 能使构件间实现“通信、合作和协调”的一组连接件；
3. 定义构件如何集成为系统的约束；
4. 语义模型，能使设计者通过分析系统组成成分的已知属性来理解系统的整体性质 。

举例

1. 以数据为中心的体系结构
2. 数据流体系结构
3. 调用和返回体系结构
4. 面向对象体系结构
5. 层次体系结构

构件级设计

构件★★

• 构件是计算机软件中的一个模块化的构造块。
• 构件存在于软件体系结构中，因而构件在完成所建系统的需求和目标的过程中起着重要作用。

设计基于类的构件

基本设计原则（7个）

开闭原则（The Open-Closed Principle ，OCP）

软件实体（模块，类，方法，构件等）应该对扩展开放，对修改关闭。

• 扩展开放：某模块的功能可扩展。软件系统的功能上的可扩展性要求模块是扩展开放的。
• 修改关闭：被其他模块调用的模块的源代码不允许修改。软件系统的功能上的稳定性，持续性要求模块是修改关闭的。

Liskov(里氏)替换原则（Liskov Substitution Principle ，LSP）

• 定义

  子类可以替换他们的基类。

  即：子类可以扩展父类的功能，但不能改变父类原有的功能。

• 要求

  1. 不应该在代码中出现if/else之类对派生类类型进行判断的条件。
  2. 派生类应当可以替换基类并出现在基类能够出现的任何地方，或者说如果我们把代码中使用基类的地方用它的派生类所代替，代码还能正常工作。

依赖倒置原则（Dependency Inversion Principle ，DIP）

• 定义

  依赖抽象，而非具体实现

• 要求

  1. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
  2. 抽象不应该依赖于细节，细节应该依赖于抽象
  3. 针对接口编程，不要针对实现编程。

High Level Classes（高层模块） --> Abstraction Layer（抽象接口层） --> Low Level Classes（低层模块）

接口分离原则（Interface Segregation Principle ，ISP）

• 定义

  使用多个专门的接口比使用单一的总接口总要好。

  即：不能强迫用户去依赖那些他们不使用的接口。

• 要求

  1. 一个类对一个类的依赖应该建立在最小的接口上
  2. 建立单一接口，不要建立庞大臃肿的接口
  3. 尽量细化接口，接口中的方法尽量少

发布/复用等价性原则（Release/Reuse Equivalency Principle，REP）

• 定义

  重用的粒度就是发布的粒度

• 要求

  1. 重用的单位和发布的单位等价
  2. 可以重用的包中不能包含不可重用的类。

• 举例

  两个组件A、B，如果其他组件总是一起使用组件A、B，而且这两个组件总是一起发布，那么这两个组件应该合为一个组件。组件中的类与模块必须是彼此紧密相关的

共同封装原则（Common Closure Principle，CCP）

一同变更的类应该放在一起，类应该根据其内聚性打包。

共同复用原则（Common Reuse Principle，CRP）

• 定义

  不能一起复用的类不能被分在同一组。

  即 不要强迫一个组件依赖他们不需要的东西。

• 要求

  1. 经常共同复用的类和模块放在同一个组件中
  2. 不是紧密相连的类不应该放在同一个组件中。

• CRP原则是面向对象设计原则中接口分离原则的普适版本

内聚性

内聚性意味着构件或类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。

耦合性

耦合是类之间彼此联系程度的一种定性度量。

用户体验设计

考点：给定一个系统，设计其UI，绘制功能页面，设计交互项

步骤

确定任务、屏幕布局、开发原型、结果评估

黄金规则★★

1. 把控制权交给用户
2. 减轻用户的记忆负担
3. 保持界面一致

界面分析

包括用户分析、任务分析和建模、显示内容分析、工作环境分析

界面设计原则（了解？）

1. 预测—对应用系统进行设计，使其能够预测出用户的下一个步骤。
2. 传达—界面应该能够传达由用户启动的任何活动的状态。
3. 一致—导航控制、菜单、图标和美学风格（例如，颜色、形状和布局）的使用应该在整个应用系统中保持一致。
4. 自律—界面应该辅助用户在整个应用系统中移动，但是应该坚持使用已经为应用系统建立起来的导航习惯，以这样的方式来辅助用户。
5. 效率—应用系统的设计和界面应该优化用户的工作效率，而不是优化设计与构造WebApp的Web 工程师的效率， 也不是优化运行系统的客户/ 服务器环境的效率。
6. 关注点—界面（及界面表示的内容）应该关注在用户正在完成的任务上。
7. Fitt规则—“到达目标所用的时间是到达目标的距离和目标规模的函数。”
8. 人机界面对象—对于Web和移动应用系统，已经开发了大量可复用的人机界面对象库。
9. 缩短等待时间—Web和移动应用系统应该采用多任务处理方式，从而使用户继续他的处理工作，看起来就像前面的操作已经完成一样。
10. 学习能力—应该设计应用系统的界面，将学习时间减到最少，并且一旦已经学习过了，当再次访问此应用系统时，将所需要的再学习时间减到最少。
11. 保持工作产品的完整性—一个工作产品必须自动保存,这样如果出现错误才不会丢失。
12. 易读性—界面展示的所有信息对于老人和年轻人都应该是易读的。
13. 跟踪状态—在合适的时候，应该跟踪和保存用户状态，使得用户能够退出系统，稍后返回系统时又能回到退出的地方。
14. 可见的导航—设计合理的界面提供了这样的设想，“即用户呆在同一个地方，工作被带到他们面前”

例题（摘自试卷）

下列关于软件设计准则的描述，错误的是(A )。

A.使模块的作用域在该模块的控制域外
B.体现统一的风格
C.采用逐步求精的思想
D.提高模块的独立性

程序描述语言PDL是软件开发过程中用于©阶段的描述工具

A.需求分析B.概要设计C.详细设计D.编程

过程设计语言(PDL)是一种用于描述模块算法设计和处理细节的语言。

从四个方面验证软件需求的正确性

1. 一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾
2. 完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能
3. 现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的
4. 有效性：必须证明需正确有效的，确实能解决用户面对的问题

软件开发启发式原则

1. 改进软件结构提高模块独立性

2. 模块规模应该适中

3. 深度、宽度、扇出和扇入都应适当

   模块的扇出：一个模块拥有的直属下级模块的个数；

   模块的扇入：一个模块的直接上级模块的个数。

4. 模块的作用域应该在控制域之内

5. 力争降低模块接口的复杂程度

6. 设计单入口单出口的模块

7. 模块功能应该可以预测

在软件开发过程中，为了达到软件开发目标，必须遵循哪些原则？

抽象、模块化、信息隐藏、局部化、一致性、完全性、可验证性