软件工程思维导图
题目：
https://wenku.baidu.com/view/652c442dcd1755270722192e453610661ed95aaa.html
考试大纲:
-
软件工程的定义及分类(填空选择)
软件工程:
①将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护，即工程化应用到软件上；
②对①中所述方法的研究。
软件=程序+数据+文档
分类:系统软件、支撑软件、应用软件 -
软件工程产生的原因(选择)
1968 年北大西洋公约组织在前联邦德国开会提出软件工程的概念，要用工程化的思想解决软件危机。
软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题。
[单选] 软件工程学科出现的主要原因是（）。
A . 计算机的发展
B . 其他工程学科影响
C . 软件危机的出现
D . 程序设计方法学的影响 -
软件工程方法学三要素(填空选择)
过程：支持软件生命周期的所有活动,整个一系列的动作如何组织，动作之间的关系
方法：为软件开发过程提供“如何做”的技术
工具：为软件开发方法提供自动的或半自动的软件支撑环境,计算机辅助软件工程
软件工程方法学的三要素是（）。
①方法
②项目管理
③过程
④开发语言
⑤工具
A．①②③
B．①②⑤
C．②③④
D．①③⑤ -
软件生命周期划分及各阶段的主要任务(填空选择重点)
(1)软件生命周期软件定义、软件开发、和运行维护3个阶段组成
具体划分:问题的定义、可行性研究、软件需求分析、系统总体设计、详细设计、编码、测试和运行、维护
软件开发的瀑布模型，一般都将开发过程划分为：分析、设计、编码和测试等阶段，一般认为可能占用人员最多的阶段是( )
A.分析阶段 B.设计阶段
C.编码阶段 D.测试阶段
正确答案：C
问题定义：
（1）确定要开发软件系统的总目标和规模。
（2）从技术、经济和社会因素等方面的要求来论证完成该软件任务的可行性。
（3）估计可利用的资源(计算机硬件，软件，人力等)、成本、效益、开发进度。
（4）制定出完成开发任务的实施计划,连同可行性研究报告，提交管理部门审查。
需求开发：
（1）调查、分析、整理用户需求；
（2）建立需求分析模型；
（3）编写软件需求规格说明书，提交管理部门审查
软件设计：
（1）根据需求规格说明书，确定软件的体系结构；
（2）设计每个系统部件的实现算法、数据结构及接口等；
（3）编写软件设计说明书，并提交管理部门审查。
软件构造（编码）：
（1）根据软件设计说明书，进行程序设计；
（2）编写功能实现代码；
（3）编写测试代码。
软件测试：检测和验证所开发的系统是否满足需求，包括：
（1）单元测试；
（2）集成测试；
（3）确认测试；
（4）系统测试
软件维护：
对系统进行改进，以适应不断变化的需求 -
软件过程模型及特点(选择填空)
瀑布模型：特点：严格按照步骤，文档驱动型，从上到下
快速原型模型：思想：和客户交流能很快构造模型，通过模型讨论，完善功能
做UI界面，做一些简单的模拟展示
螺旋模型：有风险评估，每次迭代，都要风险评估，适合大型项目，投入大风险高 -
模块的独立性指标(填空选择)
内聚和耦合
内聚:模块里面的关系
耦合:模块之间联系的指标
内聚最高:功能内聚
内聚最低:巧合内聚
耦合最高:内容耦合
耦合最低:非直接耦合
内聚和耦合是主要描述模块内外联系的，所以我们了解内聚和耦合之前，我们先了解一下模块
模块：就是为了完成某一功能所需的一段程序或是子程序；或是能够编译程序、装配程序等处理的独立程序单位；或是指大型软件系统的一部分
模块化：能够把一个大而复杂的软件系统划分成易于理解的比较简单的模块结构。（按功能域划分
基本属性
1. 功能：描述该模块实现什么功能
2. 逻辑：描述模块内部
3. 状态：该模块使用时的环境和条件
模块的独立性：软件在系统中每个模块设计软件要求的具体的子功能
它的独立性的度量准则：模块间的耦合和内聚
好的模块：高内聚，低耦合（主要是面向对象的设计，看类的内聚度是否高，耦合度是否低)
高内聚，低耦合的好处：在系统的持续发展中，它会使系统有很好的重用性，维护性，扩展性，可以更高效的完成系统的维护开发，持续的支持业务发展！
内聚
内聚主要描述的是模块内功能的联系，高内聚就是模块内功能联系比较紧密，代码的相关性特别的强，程序设计的比较严谨！
内聚的分类
1 功能内聚（最理想的内聚）
一个模块中各个部分都是完成某一具体功能必不可少的组成部分，是不可分割的
功能内聚是最强的内聚，其最大的优点是它的功能明确。判断一个模块是否功能内聚，一般从模块名称就能看出。如果模块名称只有一个动词和一个特定的目标（单数名词），一般来说就是功能内聚，如：“计算水费”、“计算产值”等模块。功能内聚一般出现在软件结构图的较低层次上
功能内聚模块的一个重要特点是：他是一个“暗盒”，对于该模块的调用者来说，只需要知道这个模块能做什么，而不需要知道这个模块是如何做的
2 信息内聚
这个模块完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个唯一的入口点
3 通信内聚
如果一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据，则称之为通信内聚模型
4 过程内聚
使用流程作为工具设计程序时，把流程图中的某一个部分划分出组成模块，就得到过程内聚模块
5 时间内聚
时间内聚模块的各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行
6 逻辑内聚
这种模块把几种相关功能组合在一起
7 巧合内聚
各部分之间没有联系，或者即使有联系，这种联系也很松散。
耦合可以分为以下几种，它们之间的耦合度由高到低排列如下
（1） 内容耦合：如果发生下列情形，两个模块之间就发生了内容耦合
一个模块直接访问另一个模块的内部数据;
一个模块不通过正常入口转到另一模块内部;
两个模块有一部分程序代码重迭(只可能出现在汇编语言中);
一个模块有多个入口。
（2） 公共耦合：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
（3） 外部耦合： 一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。
（4） 控制耦合：如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
（5） 标记耦合：一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子结构，而不是简单变量。
（6） 数据耦合：一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的。
（7） 非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的
（8）顺序耦合：是静态耦合性的一种，为了保持正确性，两个元素(一般是函数或API)必须以特定的顺序出现。 -
软件结构的深度、宽度、扇入、扇出的定义？(填空选择)
结构图的深度指模块的层数
宽度指一层中最大的模块数
扇出指一个模块直接调用下属模块的个数
扇入指一个模块直接上属模块的个
下面软件结构图的深度、第二层的宽度、A模块的扇出和B模块的扇入分别为（A）
A．4、3、3、1
B．4、2、3、1
C．4、3、1、3
D．4、2、1、3．
-
数据流图的基本要素及画法(填空题)
数据流图（Data Flow Diagram,简称DFD）描绘系统的逻辑模型，是结构化系统分析的主要工具。数据流图(DFD)是描述软件系统中数据处理过程的一种有力的图形工具。
数据流图描述输入数据流到输出数据流的变换（加工），用于对系统的功能建模。
采用自顶向下逐层分解，描绘满足用户要求的软件模型。
基本要素
数据源点：产生数据的地方
数据终点：数据的最终消费者
数据处理：数据的加工过程
数据流：在系统中进行流动的数据。
数据存储：存储数据的地方
画分层DFD的指导原则:
父图-子图平衡:模型分解时必须保持父图的输入输出数据流和子图输入输出数据流相同。
局部数据存储:出现在加工之间的界面时，才画出来
编号:子图图号为分解的父图中的加工号，同级子图在最后数字以序号区别。
分解的程度:按功能情况定，一般设深度为3-5；同一层次超过5个加工，最好分解画，否则容易出错。
数据流图的分析步骤:
找出数据流图的四种组成要素。
源点和终点、数据处理、数据存储、数据流。
画出基本系统模型。
把软件系统看作一个整体单元，描述它与外部环境的数据交互关系。
画出功能模型。
把系统划分出几个主要的数据处理步骤，描述系统内部之间的数据流动关系。
数据流图细化。
对数据处理进行进一步细化，形成详细的数据流图。 -
ER图的基本要素及画(分析题)
实体：矩形
属性：椭圆
属性-实体 线条
实体-实体有关系 用菱形
映射基数 多对多 -
数据库逻辑设计内容及做法(同第九题一起出)
逻辑设计就是将ER图转为关系模式
考试第一步画ER图，第二部转换他的关系模
每一个实体他是可以转为一个关系模式，每一个关系也可以转为一个关系模式
关系里面根据映射的多少转换的方式也不一
还要注意：映射完后，主关键字能标注出来，画下划线
题目:
-
向数据流的设计方法(非分析题)
数据流->结构图就是面向数据流的设计方法
两种数据流 变换型，事物型
变换型：映射为哪三个部分：传入路径 变换中心 传出路径
变换型分析的设计步骤:
(1）确定DFD的变换中心、逻辑输入和逻辑输出
(2）设计软件结构的顶层和第一层:变换结构
(3）设计中、下层模块
(4）设计的优化
事物型：事务型结构由至少一条接受路径、一个事务中心与若干条动作路径组成。
事务分析的设计步骤：
⑴确定事务中心和加工路径
⑵设计顶层（事务机构）和第一层 顶层模块有两个功能：接收数据和根据事务类型调动相应处理模块。
⑶中下层模块的设计﹑优化工作与变换结构相同。
事务型软件结构包括两部分： 接收分支 发送分支
通常包括一调度模块，当事务类型不多时，可与主模块合并 -
面向对象思想(分数多,填空选择问答)
基本观点：
1）对象：客观世界由对象组成
2）类：对象可以归并为一个类
3）对象之间有继承关系
4）对象直接有联系，通过通信，成为消息
面向对象三大特征
封装继承多态
1）封装:将客观事物抽象成类，每个类对自身的数据和方法实行protection (private，protected,public)
2）继承:广义的继承有三种实现形式:实现继承(指使用基类的属性和方法而无需额外编码的能力)、可视继承(子窗体使用父窗体的外观和实现代码)、接口继承(仅使用属性和方法，实现滞后到子类实现)。前两种（类继承)和后一种（(对象组合=>接口继承以及纯虚函数）构成了功能复用的两种方式。
3）多态:是将父对象设置成为和一个或更多的与他的子对象相等的技术，赋值之活，父对象就可以根据当前赋值给它的子对象的特性以不同的方式运作。简单的说，就是一句话:允许将子类类型的指针赋值给父类类型的指针。 -
面向对象分析中领域建模任务(分析题)
识别出分析类
考大题，给一个业务描述，这里面识别出来几个类，类图怎么画
类的识别方法：分析类，边界类，控制类，实体类
题目: 汽车和自行车都是交通工具。一辆自行车只能归一个人拥有，但一辆汽车可归一个人或者两个人拥有。一个人可能没有自行车或汽车.也可能拥有多辆自行车或汽车。人分男人和女人两类，每个人都具有年龄和名字。在任何时候，一辆汽车上可能载有0个多个乘客。每辆汽车都有自己的颜色和商标。特别地，每辆汽车都只有两个前灯和一台发动机。请画出类图。
-
面向对象设计的七大原则(考一两个原则概念填空题)
开闭原则
里氏代换原则
最少知道原则
单一职责原则
接口隔离原则
依赖倒转原则
合成复用原则
(1) 单一职责原则(Single Responsibility Principle, SRP)
定义：
类的职责要单一，一个类只负责一项职责
分析：
一个类（或者大到模块，小到方法）承担的职责越多，它被复用的可能性越小，而且如果一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作
作用：
降低代码复杂度、系统解耦合、提高可读性
注意：
通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则。
(2) 接口隔离原则(Interface Segregation Principle, ISP)
定义：
客户端不应该依赖那些它不需要的接口。 一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可
分析:
接口隔离原则是指使用多个专门的接口，而不使用单一的总接口。每一个接口应该承担一种相对独立的角色，不多不少，不干不该干的事，该干的事都要干。
一个接口就只代表一个角色，每个角色都有它特定的一个接口，此时这个原则可以叫做“角色隔离原则”。
接口仅仅提供客户端需要的行为，即所需的方法，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。
使用接口隔离原则拆分接口时，首先必须满足单一职责原则，将一组相关的操作定义在一个接口中，且在满足高内聚的前提下，接口中的方法越少越好。
可以在进行系统设计时采用定制服务的方式，即为不同的客户端提供宽窄不同的接口，只提供用户需要的行为，而隐藏用户不需要的行为。
作用：
避免接口过于臃肿职责不单一。
(3) 依赖倒转原则(Dependency Inversion Principle, DIP)
定义：
高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
分析：
简单来说，依赖倒转原则就是指：代码要依赖于抽象的类，而不要依赖于具体的类；要针对接口或抽象类编程，而不是针对具体类编程。
通过面向接口编程，使用接口或者抽象类制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
作用：
避免需求变化导致过多的维护工作。
注意：
依赖注入，就是将一个类的对象传入另一个类，注入式应该尽量注入父类对象，而在程序运行时再通过子类对象来覆盖父类对象。
继承时遵循里氏替换原则。
(4) 里氏代换原则(Liskov Substitution Principle, LSP)
定义：
所有引用基类（父类）的地方必须能透明地使用其子类的对象。
分析:
子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法；
子类中可以增加自己特有的方法；
当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松；
当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
如果子类不能完整地实现父类的方法，或者父类的一些方法在子类中已经发生畸变，则建议断开继承关系，采用依赖，聚合，组合等关系代替继承。
里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。
作用：
避免系统继承体系被破坏。
(5) 开闭原则(Open-Closed Principle, OCP)
定义：
一个软件实体应当对扩展开放(对提供方)，对修改关闭(对使用方)。也就是说在设计一个模块的时候，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
分析：
设计模式前面6大原则以及23种设计模式遵循的好，开闭原则自然遵守的好。对需求的变更保持前瞻性和预见性，就可以使抽象具有更广泛适用性，设计出的软件架构就能相对稳定。软件需求中易变的细节，通过从抽象派生出实现类来扩展。
作用：
提高扩展性、便于维护。
(6) 迪米特法则(Law of Demeter, LoD)
定义:
又称为最少知识原则。
不要和“陌生人”说话。
只与你的直接朋友通信。
每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
分析:
一个对象应该对其他对象保持最少的了解。
类与类关系越密切，耦合度越大。
迪米特法则(DemeterPrinciple)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息。
迪米特法则还有个更简单的定义：只与直接的朋友通信。
直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。
耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变 量的形式出现在类的内部。
作用：
降低类与类之间的耦合。
注意：
迪米特法则的核心是降低类之间的耦合,但是，由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间(对象间)耦合关系， 并不是 要求完全没有依赖关系
(7) 合成复用原则(Composite Reuse Principle, CRP)
定义：
尽量使用对象组合，而不是继承来达到复用的目的。
分析:
合成复用原则就是指在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；
新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简言之：要尽量使用组合/聚合关系，少用继承。
在面向对象设计中，可以通过两种基本方法在不同的环境中复用已有的设计和实现，即通过组合/聚合关系或通过继承。
组合/聚合可以使系统更加灵活，类与类之间的耦合度降低，一个类的变化对其他类造成的影响相对较少，因此一般首选使用组合/聚合来实现复用；其次才考虑继承，在使用继承时，需要严格遵循里氏代换原则，有效使用继承会有助于对问题的理解，降低复杂度，而滥用继承反而会增加系统构建和维护的难度以及系统的复杂度，因此需要慎重使用继承复用。
目的：
防止类的体系庞大。 -
状态图的组成组成元素及画法(分析题)
一个业务里有哪些状态，初态 终态，状态（圆角矩形），转换（状态之间有外部干扰时会从一种状态转换为另一种状态
状态图的概念于1987年由Harel提出，采用状态、事件等图形符号来描述系统的行为。
题目:办公室复印机的工作过程大致如下，请画出复印机的状态转换图。
未接到复印命令时处于闲置状态，信息灯呈黄色，屏幕熄灭；
当接到复印命令则进入复印状态，信息灯呈绿色，屏幕点亮；
完成一个复印命令规定的工作后，10秒内没有收到复印命令又回到闲置状态，继续等待下一个复印命令；
执行复印命令时发现缺纸，则进入缺纸状态，发出警告声，等待装纸，装满纸后进入闲置状态，准备接受复印命令；
如果复印时发生卡纸故障，则进入卡纸状态，信号灯呈红色，发出警告声，等待维修人员排除故障，故障排除后回到闲置状态。
-
用例图组成元素及画法(分析题)
了解参与者期望什么，期望系统干什么，有意义的目标为用例
参与者用小人，用例用椭圆形表示，系统边界框起来
-
用例描述的几种方法(问答题分析题)
重点是描述用例，参与者是什么，前置条件是什么，操作流程是什么
文本和图形两种方式
图形描述用活动图，涉及到多个参与者泳道图
用例图只是简单地用图描述了一下系统，但对于每个用例，我们还需要有详细的说明，这样就可以让别人对这个系统有一个更加详细的了解，这时我们就需要写用例描述。
对于用例描述的内容，一般没有硬性规定的格式，但一些必须或者重要的内容还是必须要写进用例描述里面的。用例描述一般包括：简要描述（说明）、前置（前提）条件、基本事件流、其他事件流、异常事件流、后置（事后）条件等等。下面说说各个部分的意思：
简要描述：对用例的角色、目的的简要描述；
前置条件：执行用例之前系统必须要处于的状态，或者要满足的条件；
基本事件流：描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；
其他事件流：表示这个行为或流程是可选的或备选的，并不是总要总要执行它们；
异常事件流：表示发生了某些非正常的事情所要执行的流程；
后置条件：用例一旦执行后系统所处的状态；
题目：家教网站分为前台客户系统和后台管理系统
-
时序图的组成及画(同13类分析出题)
进一步识别类与类之间的交互关系，时序图描述，强调的是一个时间概念，类与类之间有一个时间的先后顺序，一种是横轴类，纵轴时间，从上之下递增，虚线是生命线，起始对象开始，从上至下，从左至右画消息，那个对象和哪个对象会发送消息，消息要编号
消息两种，正向的消息用实线，反馈的用虚线
-
构件图的基本元素及画法(填空选择)
组成元素:构件 依赖关系 需求接口 提供接口
1，组件图又称为构件图(Component Dlagram)。组件图中通常包括组件、接口，以及各种关系。组件图显示组件以及它们之间的依赖关系，它可以用来显示程序代码如何分解成模块或组件。一般来说，组件就是一个实际文件，可以有以下几种类型:
源代码组件:一个源代码文件或者与一个包对应的若干个源代码文件。
二进制组件:—个目标码文件，一个静态的或者动态的库文件。
可执行组件:在一台处理器上可运行的一个可执行的程序单位，即所谓可执行程序。
2，组件图可以用来显示编译、链接或执行时组件之间的依赖关系，以及组件的接口和调用关系。
3，组件间的关系有两种:泛化关系和依赖关系，如果两个不同组件中的类存在泛化关系或依赖关系，那么两个组件之间的关系就表示为泛化关系或依赖关系。
4，对于由多个组件组成的大系统来说，组件图非常重要。
- 软件测试的概念、白盒测试、黑盒测试的特点？(选择填空)
目的:采用行之有效的测试方案,找出迄今未被发现的,尽可能多的错误,并加以纠正
只能证明是错误的，不能证明是正确的
黑盒测试又叫功能测试，又叫数据驱动测试
白盒测试驱动测试
白盒测试：是通过程序的源代码进行测试而不使用用户界面。
※ 白盒测试的优点有： 1）帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。
※ 白盒测试的缺点有： 2）程序运行会有很多不同的路径，不可能测试所有的运行路径；测试基于代码，只能测试开发人 员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；系统庞大时，测试开销 会非常大。
黑盒测试：又被称为功能测试、数据驱动测试或基于规格说明的测试，是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。
※ 黑盒测试的优点有： 1）比较简单，不需要了解程序内部的代码及实现； 2）与软件的内部实现无关； 3）从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题； 4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能； 5）在做软件自动化测试时较为方便。
※ 黑盒测试的缺点有： 1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的 30%； 2）自动化测试的复用性较低。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
