软件工程复习

1.结构化程序设计的基本方法

目的：提高程序可读性和易维护性、可调性和可扩充性
只允许三种基本程序结构形式：顺序结构、分支结构和循环结构（只允许一 个流动入口和一个出口）
自顶向下：先整体后细节，先全局后局部，从最上层总目标开始设计，逐步具体化
模块化设计：把个复杂问题分成多个简单问题，把每么小目标作为个模块
特点：不会出现死循环，在程序的静态形式与动态执行流程之间具有良好的对应关系

2.白盒测试技术的覆盖标准 P216

if(a^b)
    c=a-b;
else
    c=a+b;

白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。
其中逻辑覆盖包含以下， 覆盖强度由弱到强的顺序依次是：

• 语句覆盖
  语句覆盖就是每个语句至少被执行一次。

• 判定覆盖
  每个判断的分支取真分支和取假分支至少经历一次，每个分支执行一次。比如if、else分支

• 条件逻辑覆盖
  使得判定的每个条件都需要至少满足一次，关注条件真假。

• 判断逻辑条件覆盖
  使得每个判断取到可能的结果，并且判断中的每个条件也要取到可能的结果。判断和条件都必须满足
  即if/else两个判断都要执行到，if中的条件a取false和true，b取false和b取true。同时满足判定覆盖与条件覆盖。

• 条件组合覆盖
  即每个判定中条件的各种取值组合至少出现一次
  比如上面的if为真的条件中;

a为真，b为真
a为真，b为假
a为假，b为真
a为假，b为假

• 路径覆盖
  执行所有可能执行的路径

3.软件工程三要素

方法，工具，过程

软件工程方法为软件开发提供了“如何做”的技术。它包括了多方面的任务，如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等。

软件工具为软件工程方法提供了自动的或半自动的软件支撑环境。目前，已经推出了许多软件工具，这些软件工具集成起来，建立起称之为计算机辅助软件工程(CASE)的软件开发支撑系统。CASE将各种软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环境。

软件工程的过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需要的管理、及软件开发各个阶段完成的里程碑。

4.内聚耦合

内聚与耦合分别为对模块内部与模块之间关联度的衡量

• 内聚衡量模块内部各元素之间的相互依赖的紧密程度
• 耦合衡量不同模块彼此间互相依赖的紧密程度

内聚

内聚按强度从低到高有以下几种类型：

偶然内聚

如果一个模块的各成分之间毫无关系，则称为偶然内聚，也就是说模块完成一组任务，这些任务之间的关系松散，实际上没有什么联系。

逻辑内聚

几个逻辑上相关的功能被放在同一模块中，则称为逻辑内聚。

如一个模块读取各种不同类型外设的输入。尽管逻辑内聚比偶然内聚合理一些，但逻辑内聚的模块各成分在功能上并无关系，即使局部功能的修改有时也会影响全局，因此这类模块的修改也比较困难。

时间内聚

如果一个模块完成的功能必须在同一时间内执行（如系统初始化），但这些功能只是因为时间因素关联在一起，则称为时间内聚。

通信内聚

如果一个模块的所有成分都操作同一数据集或生成同一数据集，则称为通信内聚。

过程内聚

构件或者操作的组合方式是，允许在调用前面的构件或操作之后，马上调用后面的构件或操作，即使两者之间没有数据进行传递。
模块完成多个需要按一定的步骤一次完成的功能。（过程相关—控制耦合）。

例如：在用程序流程图设计模块时，若将程序流程图中的一部分划出各自组成模块，便形成过程内聚。

这里的完成次序可以是用户自定义的特殊顺序（这个顺序不一定是必要的）

信息内聚

模块完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个唯一的入口点。这个模块将根据不同的要求，确定该模块执行哪一个功能。
由于这个模块的所有功能都是基于同一个数据结构（符号表），因此，它是一个信息内聚的模块。

顺序内聚

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

功能内聚

模块的所有成分对于完成单一的功能都是必须的，则称为功能内聚。

耦合

一般模块之间可能的连接方式有七种，构成耦合性的七种类型。它们之间的关系为（独立性由强到弱）

非直接耦合(Nondirect Coupling)

如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，这就是非直接耦合。这种耦合的模块独立性最强。

数据耦合(Data Coupling)

传递的仅能是数据
如果一个模块访问另一个模块时，彼此之间是通过数据参数(不是控制参数、公共数据结构或外部变量)来交换输入、输出信息的，则称这种耦合为数据耦合。

由于限制了只通过参数表传递数据，按数据耦合开发的程序界面简单、安全可靠。因此，数据耦合是松散的耦合，模块之间的独立性比较强。在软件程序结构中至少必须有这类耦合。

印记耦合(Stamp Coupling)

如果一组模块通过参数表传递记录信息，就是标记耦合。

事实上，这组模块共享了这个记录，它是某一数据结构的子结构，而不是简单变量。这要求这些模块都必须清楚该记录的结构，并按结构要求对此记录进行操作。在设计中应尽量避免这种耦合，它使在数据结构上的操作复杂化了。如果采取“信息隐蔽”的方法，把在数据结构上的操作全部集中。

控制耦合(Control Coupling)

如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。

这种耦合的实质是在单一接口上选择多功能模块中的某项功能。因此，对所控制模块的任何修改，都会影响控制模块。另外，控制耦合也意味着控制模块必须知道所控制模块内部的一些逻辑关系，这些都会降低模块的独立性。

外部耦合(External Coupling)

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

例如C语言程序中各个模块都访问被说明为extern类型的外部变量。外部耦合引起的问题类似于公共耦合，区别在于在外部耦合中不存在依赖于一个数据结构内部各项的物理安排。

特征耦合

整个数据结构作为参数传递而被使用的仅是其中的一部分数据元素

公共耦合(Common Coupling)

若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。
公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
这种耦合会引起下列问题：

所有公共耦合模块都与某一个公共数据环境内部各项的物理安排有关，若修改某个数据的大小，将会影响到所有的模块。
无法控制各个模块对公共数据的存取，严重影响软件模块的可靠性和适应性。
公共数据名的使用，明显降低了程序的可读性。
公共耦合的复杂程度随耦合模块的个数增加而显著增加。
若只是两个模块之间有公共数据环境，则公共耦合有两种情况。

若一个模块只是往公共数据环境里传送数据，而另一个模块只是从公共数据环境中取数据，则这种公共耦合叫做松散公共耦合。（一传一取）
若两个模块都从公共数据环境中取数据，又都向公共数据环境里送数据，则这种公共耦合叫做紧密公共耦合。（双向传取）
只有在模块之间共享的数据很多，且通过参数表传递不方便时，才使用公共耦合。否则，还是使用模块独立性比较高的数据耦合好些。

内容耦合(Content Coupling)
如果发生下列情形，两个模块之间就发生了内容耦合。

一个模块直接访问另一个模块的内部数据；
一个模块不通过正常入口转到另一模块内部；
两个模块有一部分程序代码重叠(只可能出现在汇编语言中)；
一个模块有多个入口。
在内容耦合的情形，所访问模块的任何变更，或者用不同的编译器对它再编译，都会造成程序出错。好在大多数高级程序设计语言已经设计成不允许出现内容耦合。它一般出现在汇编语言程序中。这种耦合是模块独立性最弱的耦合。

5.瀑布模型 增量模型 演化模型 并发模型 统一软件过程，螺旋模型

并发模型

统一软件过程

RUP（Rational Unified Process），统一软件开发过程，统一软件过程是一个面向对象且基于网络的程序开发方法论。

RUP是风险驱动的、基于Use Case技术的、以架构为中心的、迭代的、可配置的软件开发流程。

RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程（也被称作厚方法学），因此特别适用于大型软件团队开发大型项目

基本的概念，大概了解 RUP 究竟是个什么东西

核心概念
RUP中定义的核心概念主要有角色、活动和工作

（1）角色：RUP预先定义了许多角色，角色描述了在项目开发中，一个人或者一个开发团队的工作职能与任务。

（2）活动：它是一个有明确功能的独立模块，反映了系统的某个功能。

（3）工件：是在活动进行过程中产生、创建或修改的一段信息，同时也是项目开发的文档资料

RUP 开发中会用到的专业名词，看解释可以明白其代表的含义

开发过程
RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段、细化阶段、构造阶段和交付阶段。每个阶段结束于一个主要的里程碑。每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

这是使用 RUP 开发的基本过程，遵循该过程的每一个阶段进行对应的工作，每个阶段必须交出满意答卷才能进行下一阶段

初始阶段

（1）对需求有大概了解，确定系统中大多数角色和用例。

（2）划分主要子系统，给出系统的体系结构概貌

（3）分析整个项目进行中的业务和需求方面的主要风险，评价项目可行性。

（4）考虑时间、经费、技术、项目规模和效益等因素

（5）制定开发计划

（6）初始阶段结束时是第一个重要的里程碑：生命周期目标里程碑。生命周期目标里程碑评价项目基本的生存能力

细化阶段

（1）进行需求风险分析。考虑项目目标是否偏离用户需求

（2）进行技术风险分析。通过建立原型等方法，考虑所选技术方案可行性

（3）进行技能风险分析。考虑实施项目人员素质能否胜任项目要求

（4）进行政策风险分析。考虑政策性因素对项目的影响

（5）进行高层分析和设计，并作出结构性决策。

（6）产生简要体系结构，包括用例列表、领域概念模型和技术平台等

（7）为构造制定计划

（8）同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。

（9）细化阶段结束时第二个重要的里程碑：生命周期结构里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案

构造阶段

（1）构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量，迭代增量的开发一个完整的软件系统。

（2）在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。

（3）构建阶段结束时是第三个重要的里程碑：初始功能里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版

交付阶段

（1）交付阶段的重点是确保软件对最终用户是可用的。

（2）交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。

（3）在交付阶段的终点是第四个里程碑：产品发布里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合

瀑布模型

工作流程

需求分析—软件需求—分析—程序设计—编码—测试—运行
每个阶段都需要进行审核和文档输出（文档驱动）

模型作用

为软件开发和维护提供了有效的管理模式。在软件开发早期，在消除非结构化软件、降低软件复杂度、促进软件开发工程化方面起着显著的作用。

每个开发活动的特征：

·本活动依赖于上一项活动的输出作为工作对象，这些输出一般是代表某活动结束的里程碑式文档。
·根据本阶段的活动规程执行相应的任务。
·本阶段活动的最终产出——软件工件，将会作为下一活动的输入。
·对本阶段活动执行情况进行评审。

优点：

降低复杂度、提高透明性和可管理性、强调需求分析和设计、阶段审核和文档输出保证了阶段之间的正确衔接，能够及时发现问题。

缺点：

缺乏灵活性、不适用于需求不明的开发情况、风险控制能力较低、文档驱动增加了系统的工作量、只依赖于文档来评估进度，可能会得出错误结论、成功周期较长

适用场景：

需求明确、较大型系统、开发周期不紧张

演化模型

工作流程：

在瀑布模型的基础上，一次性开发难以成功，因此，演化模型提倡进行“两次开发”，分别是试验开发和产品开发。每个开发阶段按照瀑布模型进行具体开发活动。

适用场景：

需求不清、开发周期短的中小型系统。

优点：

明确用户需求、提高系统质量、降低开发风险

缺点：

管理难度提高、开发结构化较差、可能抛弃文档驱动、可能导致产品结构化较差

增量模型

模型概述：

结合瀑布模型和演化模型的优点，在需求不清时，对最核心或最清晰的需求，利用瀑布模型实现。再对后续需求进行重复开发（可能按照需求的优先级逐个进行），从而逐步建成一个完整的软件系统。

优点：

保障核心功能实现、开发风险较低、保障最高优先级的功能的可靠实现、提高系统稳定性和可维护性。

缺点：

增量粒度难以合理选择、确定所有的需求服务较困难

螺旋模型

模型概述：

将开发过程分为四个类型：风险分析、制定计划、实施工程、客户评估。每次评估之后确定是否进行螺旋线的下一个回路。

适用对象：

风险较高、开发周期较长的大型软件项目

优点和缺点：

降低风险，但是开发周期长。

6.测试的关键问题

7.er图，特别是基数，形态，建立er图

8.集成测试，单元测试 确认测试 P224-228

单元测试（Unit Testing）

单元测试又称模块测试，是针对软件设计的最小单位（模块）进行正确性检验的测试，检查每个程序模块是否实现了规定的功能，保证其能正常工作。

测试重点：

（1）系统的模块，子程序的正确性验证等

（2）白盒测试

集成测试（Integrated Testing）

集成测试是把已测试过的模块组装起来，对与设计相关的软件体系结构进行测试。

测试重点：

（1）把各个模块连接起来，模块接口的数据是否会丢失

（2）单独一个子模块的功能是否会对另一个模块的功能产生不利的影响

（3）各个子模块功能组合起来，能否达到预期的要求

（4）全局数据结构是否有问题

（5）单个模块的误差积累起来，是否会被放大从而达到不能接受的程度

（6）白盒测试+黑盒测试

确认测试（Confirm Testing）

确认测试是检验所开发的软件是否满足SRD(System Requirement Document)中定义的需求、性能要求，以及软件配置是否完全正确。

系统测试（System Testing）

系统测试是把通过确认测试的软件作为系统的一个元素，接入系统的实际运行环境中，与系统的其他部分（硬件、系统、数据库、第三方数据等）结合起来进行测试。

测试重点：

（1）整个系统运行的稳定性

（2）整个系统的兼容性

（3）是否符合“需求规格说明书”

（4）黑盒测试

验收测试（Acceptance Testing）

验收测试是检验软件产品的最后一关，在这个环节，测试主要从用户的角度着手。是一个确定产品能否满足合同/用户需求的测试。

9.软件生命周期

规划阶段

确定这个软件的开发目标及其可行性

设计阶段

完成说明书，确定开发阶段产品开发阶段

稳定阶段

测试和调试

发布阶段

10.cocomo2模型，计算项目NOP，工作量成本估算

COCOMOII模型中使用三个螺旋式的过程模型：应用组装模型，早期设计模型和后体系结构模型。

应用组装模型(Application Composition)

应用组装模型是基于对象点的度量模型，它通过计算屏幕、报表、第三代语言(3GL)模块等对象点的数量来确定基本的规模，每个对象点都有权重，由一个三级的复杂性因子表示，将各个对象点的权值累加起来得到一个总体规模，然后再针对复用进行调整。

早期设计模型(early design)

在项目开始后的一个阶段或者螺旋周期通常包括探索体系结构的可供选择方案或增量开放测量。为支持这一活动，COCOMOII提出了一个早期设计模型，这一模型使用功能点和等价代码行估算规模。

后体系结构模型(post architecture)

一旦项目进入开放阶段，就必然确定一个具体的生命周期体系结构，此时项目就能够为估算提供更多更准确的信息。

COCOMOII模型估算方法

在利用COCOMOII模型进行软件成本估算过程中，首先采用软件规模估算方法对项目的规模进行估算。再应用五个比例因子，通过相关计算，将规模转化为工作量，并通过十七个成本驱动因子对工作量进行调整。最后，采用进度计算公式，计算出开发该项目所需要的进度以及人数。

工程点:$FP=总计数\ast [0.65+0.01\ast \sum F_i]$

$E=B+0.01\ast \sum _{j=1}^{5}E{M}_j$

工作量：$PM=A\ast Siz{e}^E\ast \prod _i^{n}E{M}_i$

产量：$PROD=\frac{NOP}{人月}$(单位：$\frac{NOP}{人月}$)

工作量：$PM=\frac{NOP}{PROD}$(单位：$人月$)

$NOP=对象点数目\ast \frac{100-REUSE\%}{100}$

11.决策树法

决策表（决策树）

定义

决策树(Decision Tree）是在已知各种情况发生概率的基础上，通过构成决策树来求取净现值的期望值大于等于零的概率，评价项目风险，判断其可行性的决策分析方法，是直观运用概率分析的一种图解法。由于这种决策分支画成图形很像一棵树的枝干，故称决策树。
决策树是一种树形结构，其中每个内部节点表示一个属性上的测试，每个分支代表一个测试输出，每个叶节点代表一种类别。
决策树是一种十分常用的分类方法。
决策点，是对几种可能方案的选择，即最后选择的最佳方案。如果决策属于多级决策，则决策树的中间可以有多个决策点，以决策树根部的决策点为最终决策方案。
状态节点，代表备选方案的经济效果（期望值），通过各状态节点的经济效果的对比，按照一定的决策标准就可以选出最佳方案。由状态节点引出的分支称为概率枝，概率枝的数目表示可能出现的自然状态数目每个分枝上要注明该状态出现的概率。
结果节点，将每个方案在各种自然状态下取得的损益值标注于结果节点的右端。

优点

决策树易于理解和实现，人们在学习过程中不需要使用者了解很多的背景知识，这同时是它的能够直接体现数据的特点，只要通过解释后都有能力去理解决策树所表达的意义。
对于决策树，数据的准备往往是简单或者是不必要的，而且能够同时处理数据型和常规型属性，在相对短的时间内能够对大型数据源做出可行且效果良好的结果。
易于通过静态测试来对模型进行评测，可以测定模型可信度；如果给定一个观察的模型，那么根据所产生的决策树很容易推出相应的逻辑表达式。

缺点

1)对连续性的字段比较难预测。
2)对有时间顺序的数据，需要很多预处理的工作。
3)当类别太多时，错误可能就会增加的比较快。
4)一般的算法分类的时候，只是根据一个字段来分类。

12.BCWS BCWP BAC ACWP P109

BCWS: Budgeted Cost Work Scheduled ,计划完成工作的预算成本

ACWP: Actual Cost Work Performed,已完成工作的实际成本

BCWP: Budgeted Cost Work Performed,已完成工作的预算成本

SV: Schedule Variance, 进度差异

CV: Cost Variance, 费用差异

SPI: $=\frac{BCWP}{ACWP}$ Schedule Performance Index, 进度效能指标

BAC: Budgeted At Completion 工作完成的预算成本

EAC: =$\frac{BAC}{CPI}$ Estimate At Completion

VAC: =$BAC-EAC$ Variance At Completion

举例：某土方工程总挖方量为 4000立方米，计划用10天完成，每天400立方米，预算单价为45元/立方米，该挖方工程预算总费用为180000元。 开工后第7天早晨刚上班时业主项目管理人员前去测量，取得了两个数据：已完成挖方2000立方米，支付给承包单位的工程进度款累计已达120000元。

1、计算BCWP（实际完成工作的预算成本）

BCWP =45元/立方米 ×2000立方米=90000元

从这里可以看出，实际完成工作预算成本（BCWP）与项目进度没有直接关心，并不关系项目实际进度到了什么程度，只关系实际完成的工作量

2、计算BCWS（计划工作预算成本）

开工后第6天结束时，承包单位应得到的工程进度款累计额为BCWS=108000元。

3、计算ACWP（完成工作的实际成本）

本案例的ACWP很明显，直接给出了，ACWP=120000

进一步计算得：

4、费用偏差，也叫成本偏差：CV = BCWP- ACWP=90000-120000=-30000元，表明承包单位已经超支。

5、进度偏差：SV = BCWP- BCWS=90000-108000=-18000元，表明承包单位进度已经拖延。表示项目进度落后，较预算还有相当于18000元的工作量没有做。18000元/（400×45）=1天的工作量，所以承包单位的进度已经落后1天。

另外，还可以使用费用实施指数CPI和进度实施指数SPI测量工作是否按照计划进行。

CPI= BCWP/ACWP = 90000/120000=0.75.

SPI= BCWP/BCWS = 90000/108000=0.83.

CPI和SPI都小于1，给该项目亮了黄牌。

从上面可以看出，CV和CPI是一组指标，SV和SPI是一组指标。

注意：有的时候提到挣值EV，这个EV实际上就是BCWP

记忆方法：

1、 BCWS、BCWP、ACWP是基础的术语，这个一定要记住（B：预算；C：成本 S：计划 P：执行）

2、 BCWS（计划预算）：是说在某个时刻，计划应该完成的工作的预算成本，只有这个指标与项目进度有关

3、 BCWP（执行预算）：是说已经完成的工作，所对应的预算成本，很明显这个指标关心的是已经完成的工

作的预算，至于这个工作是否超时、超支，并不关心

4、 ACWP（执行成本）：就是说已经完成的工作，所已经花费的成本，很明显这个指标关心的是已经完成

工作的成本，至于时候超时、超支，并不关心

5、 在实际工作中，我们要关心项目是否超时，这必然要与进度有关，所以与BCWS、BCWP有关

SV = BCWP – BCWS SPI = BCWP / BCWS

6、 在实际工作中，我们要关心项目是否超支，这与进度无关，所以与BCWS无关，只与BCWP、ACWP有关

CV = BCWP－ACWP CPI=BCWP／ACWP

7、在公式5和6中，被减数（被除数）都是BCWP

13.模块独立性的标准及其定义

内聚和耦合
模块的独立程度可以由两个定性标准衡量，这两个标准分别是内聚和耦合。
耦合衡量不同模块彼此间互相依赖（连接）的紧密程度；内聚衡量一个模块内部各个元素彼此结合的紧密程度。

• 耦合：

  • 定义：
    是对一个软件结构内不同模块之间互连程度的度量。耦合强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。
  • 分类：
    （1）数据耦合：两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据。
    （2）控制耦合：如果传递的信息中有控制信息（尽管有时这种控制信息以数据形式出现）
    （3）特征耦合：当把整个数据结构作为参数传递而被调用的模块只使用其中一部分数据元素时
    （4）公共环境耦合：当两个或多个模块通过一个公共数据环境相互作用时
    （5）内容耦合：最高程度的耦合；如果出现以下情况之一，两个模块就发生了内容耦合：
    a. 一个模块访问另一个模块的内部数据
    b. 一个模块不通过正常入口而转到另一个模块的内部

  c. 两个模块有一部分代码重叠（只可能出现在汇编语言）
  d. 一个模块有多个入口（意味着一个模块有几种功能）
  耦合设计原则：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。

• 内聚

• 定义：
  标志着一个模块内哥哥元素彼此解和的紧密程度，它是信息隐藏和局部化概念的自然扩展。简单的说，理想内聚只做一件事情。（内聚和耦合是密切相关的，模块内的高内聚往往意味着模块间的低耦合，内聚和耦合都是进行模块化设计的有利工具，但是内聚更重要）

• 分类：
  A． 高内聚：
  （1） 顺序内聚：如果一个模块内的处理元素和同一功能密切相关，而且这些处理必须顺序执行（9分）
  （2） 功能内聚：如果模块内所有处理元素属于一个整体，完成一个单一的功能（10分）
  B． 中内聚：
  （1） 过程内聚：如果一个模块内的处理元素是相关的，而且必须经过特定的次序执行（5分）
  （2） 通信内聚：如果模块中所有元素都使用同一输入数据和（或）产生统一输出数据（7分）
  C． 低内聚：
  （1） 偶然内聚：如果一个模块完成一组任务，这些任务彼此间即使有关系，关系也是很松散的。（0分）
  （2） 逻辑内聚：如果一个模块完成的任务在逻辑上属于相同或相似的一类。（1分）
  （3） 时间内聚：如果一个模块包含的任务必须在同一时间内执行（3分）

14.体系结构的深度，宽度， 扇入扇出 p252课后习题 3 4 7 8

深度即高度，最长路径

宽度即同行最多个数

扇入即最大入度

扇出即最大出度

15.MIF

见20

16.软件结构图

17.程序流程图表示算法，对应的流图，流图的区域，计算环形复杂度，设计路径覆盖的测试用例

流图

把框换成圆形，标上$1，2，3，4....$

环形复杂度

• 环形复杂度$V(G)=流图中的区域数$
• 流图G的环形复杂度$V(G)=E-N+2$
  其中，E是流图中边的条数，N是结点数
• 流图G的环形复杂度$V(G)=P+1$
  其中，P是流图中判定结点的数目

例如

• $V(G)=E-N+2=13-11+2=4$
• $V[G]=P+1=3+1=4$
• $V[G]=3+1$（把11连到1）

18.LOC

Length of Code

软件生产率$P_l=\frac{L}{E}$(LOC/PM)

每千行代码的错误数$ER{Q}_l=\frac{Ne}{L}$(个/KLOC)

每千行代码的缺陷数$=\frac{Nd}{L}$(个/KLOC)

每千行代码的成本$=\frac{S}{L}$(个/KLOC)

每千行代码的文档页数$=\frac{Pd}{L}$(页/KLOC)

LOC估算= NLOC avy+ [ (Sa/Sh-1)+ (Pa/Ph-1)]*LOC adjust
N:用例数目
LOC avy:同类型的子系统中，每个用例的历史平均LOC值
Sa:用例包含的实际场景数
Sh:在该类型的子系统中，每个用例包含的平均用例场景数
Pa:用例实际的页数
Ph:在该类型的子系统中，每个用例包含的平均用例页数

19.需求分析的定义

20.面向对象程序设计的特性

WMC,DIT,NOC,NOA,MIF,PF,CF

$WMC=\sum _{j=1}^{m}WM{C}_j$ ，单位：方法/类
Weighted Methods per class ,每个类的加权方法,即各个方法的圈复杂度之总和

DIT:
Depth of the Inheritance Tree，继承树深度，即树的深度-1

NOC:
Number of Children,子女数量,即直接子类数量

NOA:
Number of Operating Added by subclass,由子类增加的操作数量

耦合的度量
边数*2？

RPC
Responce For a Class,对类的响应
（自身方法数+1）+sum（引用方法数+1）

MIF:
Method Inheritance Factor,方法集成因子
$MIF=\frac{\sum _{i=1}{M}_i(C_i)}{\sum _{i=1}{M}_a(C_i)}=\frac{\sum _{i=1}{M}_i(C_i)}{\sum _{i=1}(M_d(C_i)+M_i(C_i))}$

$M_d(C_i),C_i$ 声明的方法数量(declare)
$M_i(C_i),C_i$ 继承的方法数量(无覆盖,inherit)
$M_a(C_i),C_i$ 所有的方法数量(all)

PF:
Polymorphism Factor 多态因子

$PF=\frac{\sum _{i=1}{M}_o(C_i)}{\sum _{i=1}[M_n(C_i)\ast DC(C_i)]}$
$M_n(C_i)$, 新方法的数量(new)
$M_o(C_i)$, 覆盖方法的数量(overlap)
$DC(C_i)$, 某基类后代类数量的计数
显然：$M_d(C_i)=M_n(C_i)+M_o(C_i)$

CF:
$CF=\frac{2\ast \sum _{i=1}^n\sum _{j=i+1}^{n}is\_cilent(C_i,C_j)}{n(n-1)}$

21.软件的可维护性

软件可维护性的定义：

维护人员理解、改正、改动或改进这个软件的难易程度。

决定软件可维护性的因素：
{ 可 理 解 性 { 定 义 ： 表 现 为 外 来 读 者 理 解 软 件 的 结 构 、 功 能 、 接 口 和 内 部 处 理 过 程 的 难 易 程 度 提 高 可 理 解 性 { 模 块 化 结 构 （ 高 内 聚 、 低 耦 合 ） 详 细 的 设 计 文 档 可 测 试 性 : 模 块 的 环 形 复 杂 度 越 大 ， 可 执 行 的 路 径 就 越 多 ， 全 面 测 试 的 难 度 就 越 高 可 修 改 性 ( 影 响 因 素 ) { 耦 合 内 聚 信 息 隐 藏 局 部 化 作 用 域 的 关 系 可 移 植 性 : 衡 量 的 方 法 ： 因 环 境 变 化 ， 而 必 须 修 改 的 程 序 局 限 在 少 数 程 序 模 块 中 ， 从 而 降 低 修 改 的 难 度 。 可 重 用 性 { 定 义 ： 同 一 事 物 ， 不 做 修 改 或 稍 加 改 动 ， 就 可 以 在 不 同 的 环 境 中 多 次 重 复 使 用 可 重 用 性 软 件 的 特 点 { 经 过 了 很 严 格 的 测 试 可 靠 性 比 较 高 软 件 中 使 用 的 可 重 用 构 建 越 多 ， 软 件 的 可 靠 性 越 高 \left\{\begin{aligned} &可理解性\left\{\begin{aligned} &定义：表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度\\ &提高可理解性\left\{\begin{aligned} &模块化结构（高内聚、低耦合）\\ &详细的设计文档\\ \end{aligned}\right.\\ \end{aligned}\right.\\ &可测试性:模块的环形复杂度越大，可执行的路径就越多，全面测试的难度就越高\\ &可修改性(影响因素)\left\{\begin{aligned} &耦合\\ &内聚\\ &信息隐藏\\ &局部化\\ &作用域的关系\\ \end{aligned}\right.\\ &可移植性:衡量的方法：因环境变化，而必须修改的程序局限在少数程序模块中，从而降低修改的难度。\\ &可重用性\left\{\begin{aligned} &定义：同一事物，不做修改或稍加改动，就可以在不同的环境中多次重复使用\\ &可重用性软件的特点\left\{\begin{aligned} &经过了很严格的测试\\ &可靠性比较高\\ &软件中使用的可重用构建越多，软件的可靠性越高\\ \end{aligned}\right.\\ \end{aligned}\right.\\ \end{aligned}\right. ⎩⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎪⎧​​可理解性⎩⎪⎪⎨⎪⎪⎧​​定义：表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度提高可理解性{​模块化结构（高内聚、低耦合）详细的设计文档​​可测试性:模块的环形复杂度越大，可执行的路径就越多，全面测试的难度就越高可修改性(影响因素)⎩⎪⎪⎪⎪⎪⎪⎨⎪⎪⎪⎪⎪⎪⎧​​耦合内聚信息隐藏局部化作用域的关系​可移植性:衡量的方法：因环境变化，而必须修改的程序局限在少数程序模块中，从而降低修改的难度。可重用性⎩⎪⎪⎪⎪⎨⎪⎪⎪⎪⎧​​定义：同一事物，不做修改或稍加改动，就可以在不同的环境中多次重复使用可重用性软件的特点⎩⎪⎨⎪⎧​​经过了很严格的测试可靠性比较高软件中使用的可重用构建越多，软件的可靠性越高​​​

22.绘制某应用系统的用例图

23.分析UML类及建立相应类图

前言

       copy自老师的PPT，不只有知识点，还有一些相关内容的介绍顺便复制进来了。 如有问题请多指教

1 类图的概念

1、类图

类图是描述类、协作(类或对象间的协作)、接口及其关系的图。
类图是逻辑视图的重要组成部分，用于对系统的静态结构建模，涉及到具体的实现细节。

• 在系统分析阶段，类图主要用于显示角色和提供系统行为的实体的职责；
• 在系统设计阶段，类图主要用于捕捉组成系统体系结构的类结构；
• 在系统编码阶段，根据类图中的类及它们之间的关系实现系统的功能。

2、类图的作用

类图常用来描述业务或软件系统的组成、结构和关系。

3、类图的组成元素

• 类
• 接口
• 协作
• 关系
• 注释
• 约束
• 包

2 UML中的类

类的表示

（１）类的定义

类是具有相似结构、行为和关系的一组对象的抽象。

（２）类的表示

（３）类的命名

由字符、数字、下划线组成的惟一的字符串；
采用CamelCase格式（大写字母开头，混合大小写，每个单词一大写开始，避免使用特殊符号）
类名的两种表示方法

• 简单名 Order
• 路径名　java::awt::Rectanget、businessRule::Order

（４）类的属性

属性描述了类的静态特征；
属性名一般第一个字母小写；
属性的定义格式
[可见性] 属性名 [:类型] [ ‘[’多重性[次序]‘]’] [=初始值] [{特性}]
说明：可见性包括+、-、#
例：#visibility:Boolean=false
       colors:Color[3]
       points: Point[2…* ordered]
       name:String[0…1]

（５）类的操作

• 操作名的命名规范习惯采用和属性名相同的命名规则。
• 类的操作的定义格式
  　[可见性] 操作名 [(参数列表)] [:返回类型] [{特性}]
• 例： +hide():Boolean
         #create()
         -attachXWindow(xwin:XwindowPtr)

（６）类的职责

职责指类承担的责任和义务。在矩形框中最后一栏中写明类的职责。

（７）类的约束

约束指定了类所要满足的一个或多个规则。 在UML中，约束是用花括号括起来的自由文本。

3 类图中的关系

• 一般意义上的关联关系
• 细化后关系的性质分为4种：

1. 包含
2. 泛化
3. 依赖
4. 实现

关联（association）

关联是模型元素间的一种语义联系，当类之间在概念上有连接关系时，类之间的连接叫做关联。
队员和球队之间的关联，可以用短语“队员为篮球队效力”来刻画，
图形表示为：

关联有名称、角色、多重性和导航性等语法。

（1）关联名

• 描述关联的作用；
• 通常使用动词或动词短语；
  

（2）角色

• 关联两端的类可以某种角色参与关联；
• 通常使用名词或名词短语；
  

（3）多重性

• 某个类有多少个对象可以和另一个类的单个对象关联；
  
  
  在UML中，常用的关联的多重性表示格式如下：

0..1          0或1 
1             1
0..*（0..n）  0或多个
*             0或多个
1..* （1..n） 1或多个 
8             8 
5，7..10      5或7~10

  
  

  
  
1
2
3
4
5
6
7

（4）导航性

• 用箭头显示导航性；
• 描述源对象通过链接访问目标对象；
• A类有一个成员变量保存的是B类的一个引用，也就是说由A类可以找到B类，可以画成下图所示
  

包含

一辆汽车有4个轮子，我们可以这样表示

你可能觉得这样表示还不太合适，汽车应该包含4个轮子，或者说轮子本来就属于汽车的一部分，那怎样画能更加贴切表示这样的关系呢？我们可以这样画：

聚合

• 类之间的一种整体与部分的关系
• 体现了一种层次结构，整体类位于部分类的上层，多个部分类处于并列的层次
  

组合

• 是一种特殊形式的聚合（强聚合），聚合中的每个部分只能属于一个整体；
• 表示类之间整体和部分的关系。
• 整体与部分具有相同的生存期。
  

关于聚合与组合

• “弱”包含表示如果部门没有了，员工也可以继续存在；
  “强”包含表示如果部门没有了，员工也不再存在。
• 在做软件需求时，往往会将所有的包含关系画成“弱”包含，后面发现某些关系可以表示为“强”包含时，才转为实心菱形。
  

泛化

• 表示两个类元间“一般”与“特殊”的关系。
• 对应面向对象编程语言中类与类之间的继承关系。
• “is a kind of”关系，XX是一种XX
  

实现

• 表达一种说明元素与实现元素之间的关系；
• 类和接口之间的关系是实现关系，表示类实现接口提供的操作
• 显示一个类引用另一个类
  

依赖

• 显示一个类引用另一个类
  • 你很爱你老婆，没有你老婆你活不下去，可以这样表示
    
  • 如果一个烟鬼嗜烟如命，用类图可以这样表示：
    
• 软件开发中，往往会设计一些公用类，供别的类调用，如果这些公用类出问题了，那调用这些公用类的类都会因此而出问题。
• 依赖指的是类之间的调用关系，表现为成员变量、方法的参数或者对静态方法的调用。
  

关于依赖

假设你正在设计一个能显示公司全体成员的制表系统，公司的员工可以填写这个系统中的电子表格。员工要选择菜单来填写表格。在你的设计中，有一个Syetem（系统）类和一个Form（表格）类。System类的众多操作中有一个displayForm（f:Form），系统所要显示的表格取决于用户选择的表格。
这种设计的UML表示法可以画成如下

例

神州飞船

根据以下描述，画出相应的UML类图

• 神舟六号飞船是神州飞船系列的一种，它由轨道舱、返回舱、推进舱和逃逸救生塔等组成。
• 航天员可以在返回舱内驾驶飞船，轨道舱是航天员工作和休息的场所。在紧急的情况下，可以利用逃逸救生塔逃生。
• 在飞船两侧有多个太阳能电池翼，可以为飞船提供电能
  

运算类

简易画图软件

小李打妖怪

老张开车去东北

4 阅读类图

阅读顺序应遵循的原则

• 先看清有哪些类；
• 然后看看类之间存在的关系；
• 结合多重性来理解类图的结构特点以及各个属性和方法的含义
  

电子商务网站的静态模型

读图过程

• 读出类：
• 读出关系：从图中关系最复杂（也就是线最密集）的类开始阅读，本图中最复杂的就是Order类。
  1. OrderItem和Order之间是组合关系，根据箭头的方向可知Order包含了OrderItem。
  2. Order类和Customer、Consignee、DeliverOrder是关联关系。也就是说，一个订单和客户、收货人、送货单是相关的。

多重性：用来说明关联的两个类之间的数量关系

• Order类，有两个方法：dispatch()和close()，从名字中可以猜出它们分别实现“分拆订单生成送货单”和“完成订单”。而在DeliveOrder()类中则有一个Close()方法，同理它应该表示“完成送货”。而在OrderItem中有一个stateChange()方法和deliverState，不难猜出它就是用来改变其“是否交给收货人”标志位的
• 先调用Order的dispatch()方法，它将根据其包含的OrderItem中产品信息，来按供应商户分拆成若干个DeliverOrder。商户登录系统后就可以获取其DeliverOrder，并在执行完后调用close()方法。这时，就将调用OrderItem的stateChange()方法来改为其状态。同时再调用Order的close()方法，判断该Order的所有的OrderItem是否都已经送到了，如果是就将其真正close()
  

增强的辅助建模元素

• 导航箭头：类的实例之间只能沿着导航箭头的方向传递 ，在Order中可以获取其相应的Consignee，而从Consignee中是无法了解与其相关的Order的
• 角色名称：Customer端有一个“+Owner”字符串 ，这表示Customer扮演的角色是Owner，也能对关联进行命名
  
• 导出属性：是指可以根据其他值计算出来的特性，这种属性应在其名称前加上一个“/”符号。
• 限定符：在Order和OrderItem之间的组合关系中，OrderItem这端多了一个方框，里面写着“ProductId”。它在UML中称为限定符，存在限定符的关联称为受限关联。它用来表示某种限定关系。在本例中，它的用途是说明：对于一张订单，每一种产品只能用一个订单项
• 约束：用来说明规则，{xor}…
• 职责：在类的属性栏中添加注释行表示，或增加了一个新的分栏

5 如何建立类图

1、类图的抽象层次

• 概念类
  描述应用领域中的概念，仅包含类名，不考虑细节。
• 分析类
  分析不针对具体语言，包含一些类的细节特性。
• 设计类
  针对具体的语言，考虑类的实现细节。
  

2、建立类图的步骤

1. 分析问题域，确定需求；
2. 寻找类，确定类的含义和职责；
3. 定义类的属性和操作；
4. 确定类之间的关系；
5. 精化类和类间的关系；
6. 绘制类图。

3、寻找类的方法

使用名词/动词寻找类：

1. 收集相关信息

• 补充的需求规格说明
• 用例
• 项目说明文档
• 其他文档

2. 分析信息

• 名词、名词短语       类或属性
• 动词、动词短语       操作

使用CRC分析法寻找类：

C-class（类）
R-responsibility（职责）
C-collaboration（协作）
CRC分析法是根据类所要扮演的职责来确定类。

根据边界类、控制类、实体类帮助分析系统中的类：

UML中类有三种主要的版型：边界类、控制类和实体类。

• 边界类：位于系统与外界的交界处。如：窗体、对话框、报表、以及表示通讯协议的类、直接与外部设备交互的类。
• 实体类：保存要放进持久存储体的信息。持久存储体就是数据库、文件等可以永久存储数据的介质。通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库表中的字段。
• 控制类：是控制其他类工作的类。

例

需求描述

李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。

发现类

李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。

筛选备选类

• “李小平”、“人”、“家里”很明显是系统外的概念，无须对其建模；
• 而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；
• 很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。
• “基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模；
• “功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉；
• “计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；
• “外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”—借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；
• “购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类—书籍列表，也就是执行统计的主体。

得到候选类

书籍         计算机类书籍       非计算机类书籍        书籍列表
借阅记录     借阅记录列表

  
  

  
  
1
2

在使用“名词动词法”寻找类的时候，很多团队会在此耗费大量的时间，特别是对于中大型项目，这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解，无需太过咬文嚼字 。

职责分析

• 书籍类：从需求描述中，可找到书名、类别、作者、出版社；同时从统计的需要中，可得知“定价”也是一个关键的成员变量。
• 书籍列表类：书籍列表就是全部的藏书列表，其主要的成员方法是新增、修改、查询（按关键字查询）、统计（按特定时限统计册数与金额）。
• 借阅记录类：借阅人（朋友）、借阅时间。
• 借阅记录列表类：主要职责就是添加记录（借出）、删除记录（归还）以及打印借阅记录

限定与修改

• 导航性分析：Book与BookList之间、BorrowRecord和BorrowList之间是组合关系均无需添加方向描述，而Book与BorrowRecord之间则是双方关联，也无需添加。
• 约束：Book对象创建后就不能够被删除只能被修改，因此在Book类边上加上用自由文本写的约束 ；一本书要么属于计算机类，要么属于非计算机类，因此在ItBook和OtherBook间加了 “{Xor}”约束。
• 限定符：一本书只有一册，因此只能够被借一次，因此对于一本Book而言只能有一个RecordId与其对应。

补充

递归关系

如果面试的人说懂类图，公司100%会问这样一个问题Windows操作系统中有文件夹和文件，请用类图表达出文件夹和文件的关系。

接着又会被问到：

• 文件夹里也可以有文件夹呀，这个怎样表示？
• 里面的文件夹里面也可能有文件夹，咋办？
  
• 这个包含关系可以指向自己，可以“自包含”，这个无穷递归问题就解决了。
• 这种“递归”结构一旦展开就会形成一个树形结构，需求分析时，如果发现树形的业务结构，可以考虑使用“自包含”或者“自关联”来分析。

三角关系

公司和雇员的关系，要求列出公司和雇员至少3个关键属性
思考如下问题

1. 薪金是雇员的关键属性吗？合同期、职位呢？
2. 公司和雇员，这两者的关系在法律上是如何确立的

公司与雇员要签署劳动合同，劳动合同上会有薪金、合同期、职位这些重要的内容，那么薪金、合同期、职位算是雇员的属性吗？

在表示公司与雇员的关系的直线上，拉出一条虚线，虚线另一端连接劳动合同类，这样的类叫做关联类，关联类是对两个类的关系的进一步约束。
最开始你可能会认为薪金、职位、合同期似乎应该是雇员的属性，但现在应该认识到，这三个关键内容应该体现在公司和雇员的关系上，这些内容应该体现在劳动合同上。
公司、雇员、劳动合同的关系，还可以画成这样

       这个图最能体现“三角”关系了，关联类也可以表达成这样的方式。但实际工作还是以关联类的方式来表达，关联类的表达方式更加贴切和专业一点。
       在需求分析时，发现三个类形成了类似的“三角”关系，可以思考其中一个类是不是可能为关联类，但并不是所有的“三角”关系就一定会有关联类
       将薪金、职位、合同期这些信息直接当成雇员的属性也不是不可以的，这跟我们做系统的目标有关系，如果只是做简单的员工信息管理，可能就没有必要将合同提炼出来，如果要做一个人事管理系统，就需要我们将业务模型分析的更加透彻。
       关联类这样复杂的东西，客户是不大可能直接告诉你的，在需求分析中发现和提炼出关联类，这对需求的理解以及项目后期的设计将会有很大的帮助。

识别关联类

关于画类图

• 直线、几对几的关系、角色、箭头可以搭配使用，只要能准确反映出业务关系就可以了。
• 做软件需求分析时，如果觉得两个业务概念之间有联系，但暂时不能确定具体是怎样的，那么就先画一条线将两者连起来再说，随着你对业务的理解，这条线会进一步具体化，你可以为这条线添加更多的元素。

24.顺序图描述法

    顺序图是强调消息时间的交互图。其描述了对象之间传送消息的时间顺序，用来表示用例中的行为顺序。在该二维图中，对象由左至右排列，消息则沿着纵轴由时间顺序排列。在构筑该图时，应布局简洁。

一、顺序图示例（购买小车简图）

二、顺序图的组成要素：

对象、生命线、消息、激活。下面依次来说

1）对象：

    表示方法：

 

    说明：

     （1）将对象置于顺序图的顶部意味着在交互开始的时候对象就已经存在了，如果对象的位置不在顶部，那么表示对象是在交互的过程中被创建的。

     （2）活动者和对象从左自右排列。活动者一般为两个。

     （3）其余对象从左自右按重要性或者消息按先后排列（常用）。

     （4）命名方式有三种，对象名+类名，类名（匿名对象），对象名（不关心类）

2）生命线：

    表示方式：

 

     说明：

        （1）每个对象都有自己的生命线，用来表 示在该用例中一个对象在一段时间内的存在

        （2）生命线使用垂直的虚线表示

        （3）如果对象生命期结束，则用注销符号表示

3）激活：

    表示方式：

 

    说明：

        （1）激活表示该对象被占用以完成某个任务，去激活指的则是对象处于空闲状态、在等待消息

        （2）在UML中，为了表示对象是激活的，可以将该对象的生命线拓宽成为矩形。其中的矩形称为激活条(期)或控制期，对象就是在激活条的顶部被激活的，对象在完成自己的工作后被去激活。

4）消息：

        表示方式：

  

    说明：

        （1）消息是用来说明顺序图中不同活动对象之间的通信。因此，消息可以激发某个操作、 创建或撤销某个对象

        （2）在顺序图中，消息是由从一个对象的生命线指向另一个对象的生命线的直线箭头来 表示的，箭头上面还可以表明要发送的消息名及序号

       （3）消息可分为▪ 简单消息（Simple Message） ▪ 同步消息（Synchronous Message） ▪ 异步消息（Asynchronous Message） ▪ 反身消息（Message to Self） ▪ 返回消息（Return Message）

三、顺序图建模：

    对系统动态行为建模的过程中，当强调按时间展开信息的传送时，一般使用顺序图建模技术。一个单独的顺序图只能显示一个控制流。一般情况下，一个完整的控制流是非常复杂的，要描述它需要创建很多交互图（包 括顺序图和协作图），一些图是主要的，另一些图用来描述可选择的路径和一些例 外，再用一个包对它们进行统一的管理。

建模步骤：

        确定交互的范围->识别参与交互的对象和活动者->设置对象生命线开始和结束->设置消息->细化消息

四、简单的顺序图练习：

请画出表示以下过程的顺序图： 

(1) 借阅者希望通过图书管理员借阅某本图书； 

(2) 借阅者将图书证和图书交给图书管理员； 

(3) 图书管理员将读者图书证编号和图书编号录入借阅图书界面LendBookWindow； 

(4) 借阅图书界面LendBookWindow根据图书编号向Book类对象请求加载图书信息； 

(5) Book类对象返回图书信息给借阅图书界面LendBookWindow；

(6) 借阅图书界面LendBookWindow请求将图书信息和借阅者编号添加到Loan类对象中；

(7) Loan类对象添加借阅信息，返回借阅成功给借阅图书界面LendBookWindow； 

(8) 借阅图书界面LendBookWindow显示借阅完成；

(9) 图书管理员将图书证和图书归还给借阅者

答案：

25.年金现值

$P=A\ast \frac{1-(1+i{)}^{-n}}{i}$

26.Halstead

Halstead 复杂度度量

• 设 n1 表示程序中不同的操作符个数，n2 表示程序中不同的操作数个数，N1 表示程序中出现的操作符总数，N2表示程序中出现的操作数总数。
• Halstead 程序词汇表长度 Program vocabulary: n = n1 + n2 .
• Halstead 程序长度 Program length: $N=n_1{\log }_2{n}_1+n_2{\log }_2{n}_2$
• 程序体积或容量 Volume: $V=N{\log }_2(n_1+n_2)$，表明了程序在词汇上的复杂性。

程序级别 Level: L^ = (2/n1) × (n2 /N2)，表明了一个程序的最紧凑形式的程序量与实际程序量之比，反映了程序的效率。
程序难度 Difficulty: D = 1/L^，表明了实现算法的困难程度。
编程工作量 Effort: E = V × D = V/L^ .
语言级别: Lʹ = L^ × L^ × V .
编程时间 (hours): T^ = E/(S × f)，这里 S = 60 × 60, f = 18 .
平均语句大小: N/语句数。
程序中的错误数预测值: B = V/3000 = Nlog2 (n)/3000 .