软件工程---(上) 大工复习必考内容

第一章 软件工程概述

统一建模语言及其构成

统一建模语言（UML）提供了一整套对系统建模的基础设施，包括模型的表示及建模的方法等，可以适用不同的系统层次。
统一建模语言顾名思义它是一种语言，或者说是一种工具，而不是一种方法。
统一建模语言将软件开发中的语言表示与过程进行了分离，具有重要的功能：可视化（Visualization）、规格说明（Specification）、构造（Constructing）和文档化（Documenting）。

软件开发方法

软件工程三个要素：方法、工具和过程。

• 方法是完成软件开发各项任务的技术，回答“如何做”；
• 工具是为方法的运用提供自动或半自动软件支撑环境，回答“用什么做”；
• 过程是为获得高质量的软件要完成的一系列任务的框架，规定完成各项任务步骤，回答“如何控制、协调、保证质量”。
  软件工程开发方法从人们分析问题角度和方式的不同，可以笼统的分为传统的和面向对象的两种。

传统开发

传统开发方法又称为结构化方法，是一种静态的思想。

• 将软件开发过程划分成若干个阶段，并规定每个阶段必须完成的任务，各阶段之间具有某种顺序性；
• 体现出对于复杂问题“分而治之”的策略，但主要问题是缺少灵活性，缺少应对各种未预料变化的能力，这些变化却是在实际开发中无法避免的；
• 当软件规模比较大，尤其是开发的早期需求比较模糊或者经常变化的时候，这种方法往往会导致软件开发的不成功或维护困难。

特点：
• 生命周期模型
• 软件过程划分为若干个阶段
• 每个阶段有各自的任务
• 阶段之间有某种顺序性

面向对象方法

1. 对象作为融合数据及在数据之上的操作行为的统一的软件构件。
2. 把所有对象都划分成类(Class)。每个类都定义了一组数据和一组操作。
3. 按照父类(或称为基类)与子类(或称为派生类)的关系，把若干个相关类组成一个层次结构的系统(也称为类等级)。在类等级中，下层派生类自动拥有上层基类中定义的数据和操作，称为继承。
4. 对象彼此间仅能通过发送消息互相联系——封装性。

特点：
• 模拟人类思维
• 迭代开发
• 设计简单、容易理解
• 对象是相对独立的实体，容易在软件产品中重复使用，促进了软件重用。
• 对象与现实世界中的实体相对应，降低了复杂性，提高了可理解性，简化了软件的开发和维护工作。
• 面用对象方法特有的继承性，也进一步提高了面向对象软件的可重用性。

第二章 软件开发过程

软件开发各阶段活动及任务

软件的生命周期划分成软件定义、软件开发和运行维护三个主要的时期，每个时期再细分为具体的阶段，分别对应明确的任务。
过程：

1. 可行性分析与开发计划（技术可行性、经济可行性和社会可行性）
2. 需求分析（除了功能需求外还要对系统设计有影响的非功能性需求加以识别和分析）
3. 软件设计（尽可能保证系统设计结构在整体上的稳定性）
4. 程序编码
5. 软件测试（测试的环节可分为单元测试、集成测试及系统测试三个阶段。测试方法主要包括黑盒和白盒方法）
6. 软件维护（改正性维护、适应性维护、 完善性维护、预防性维护）

传统生命周期模型

生命周期模型分为瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型 、敏捷软件开发模型

瀑布模型

特点：

• 阶段间具有顺序性和依赖性，文档驱动
• 推迟实现，不急于编写代码
• 质量保证的观点
• 适合规模较大的系统或分布式开发模式

缺点：

• 不希望有“变化”，变化来的越晚，付出的代价越高。
• 设计阶段过多的假设，导致理想化、一厢情愿的东西过多。(用户只参与需求)
• “文档驱动”，静态

快速原型模型

特点：

• 快速原型模型对系统进行简单和快速的分析，快速构造一个软件原型
• 用户和开发者在试用或演示原型过程中进行沟通和反馈，在用户和开发者之间起到“桥梁”的作用，能获取到用户真正的需求
• 适合一个全新的系统开发，用户借助原型了解开发，使用户建立起对未来系统的认识和了解
• 可以尝试运用未来系统中需要的新技术，提前测试一些性能上的要求是否能够达到预期

缺点：

• 所选用的开发技术和工具不一定是实际项目的需要
• 快速建立起来的模型可能由于不符合各种开发规范，再加上不断的修改，质量一般都比较差，通常在实际开发过程中会完全抛弃之前建立起来的原型系统

增量模型和螺旋模型

增量模型：逐步增加系统功能
螺旋模型：尽量降低风险

喷泉模型

特点：

• 喷泉模型是典型的面向对象生命周期模型
• “喷泉” 体现了面向对象软件开发过程迭代和无缝的特性
• 为避免喷泉模型的过分无序，把一个线性过程作为总目标
  

敏捷软件开发模型

敏捷宣言：
• 个体和互动胜过流程和工具
• 工作的软件胜过详尽的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

特点：

• 迭代式开发（先实现必要性的用户用例）
• 增量交付
• 开发团队和用户反馈推动产品开发
• 高效的开发团队自我管理
• 适合规模中小、需求变化频繁的系统开发，并且强调团队的作用，所以更适合集中式的开发模式

常见的敏捷软件开发模型：极限编程XP、SCRUM（开发过程分为多个冲刺Sprint周期）、DevOps（自动化和可持续交付）、RUP、MFS
Scrum注重过程，XP注重实践。
SCRUM角色：
产品拥有者（Product Owner）：产品远景规划，平衡利益相关者利益，确定产品积压的优先级等。它是开发团队和客户间的联络点。
利益相关者（Stakeholder）：客户或最终用户代表，收集编写产品需求，审查项目成果等。
专家（Scrum Master）：指导进行Scrum开发与实践，是开发团队与产品拥有者间的联络点。
团队成员（Team Member）：项目开发人员

第三章 需求分析

用例图及其应用

想了解详细点这里

用例概述：

1. 参与者（涉众）——是与目标系统相关的一切人和物，他们对目标系统的构建会有一定的影响。用一个小人表示
   
2. 用例(Use Case)——用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示
   
3. 用例关系类型
4. 例子
   
   

数据流图及其应用（DFD）

数据流图的基本符号

加工中常见关系符号

数据流图画法

• 从基本系统模型高的抽象层次开始画数据流图
• 把基本系统模型细化，描绘系统主要功能
• 在图中给处理和数据存储加编号，便于引用和追踪
• 分层细化时保持信息连续性

举例：

第四章 软件架构的构建

软件架构的模型分为五种：结构模型、框架模型、动态模型、过程模型和功能模型

“4+1”视图模型：

逻辑视图：支持面向对象的分解。逻辑架构主要用来支持功能性需求——满足用户服务的系统功能
进程视图：进程的分解。进程架构考虑一些非功能性的需求，如性能和可用性
开发视图：子系统的分解
物理视图：软件至硬件的映射。

常见的架构： 正交软件架构、客户机/服务器架构（C/S架构）、浏览器/服务器架构（B/S架构）、MVC架构

mvc架构：

第五章 类的分析与设计

类的分类

类分为实体类（pojo）、控制类和边界类：
实体类： 对应需求中的实体，通常需要永久保存，一般使用数据库表或文件来记录，既包括存储和传递数据的类，还包括操作数据的类。
控制类： 用于体现应用程序的执行逻辑，提供相应的业务操作，抽象控制类可以降低界面和数据库之间的耦合度。控制类有时也称为管理类。
边界类： 边界类用于对外部用户与系统之间的交互对象进行抽象，主要包括界面类以及与外部系统的数据交换类(如同步、缓存等）

关联关系的基数

分析类图

转载链接

类

简要画法
第一格：类名称（如果是抽象类，名称标注为斜体字）
第二格：类属性名称
第三格：类操作名称
public用加号标注，private用减号标注，protected用#号标注，package用~号来标注

接口

简要画法
第一格：接口名称（名称前面要加入接口标注<>）
第二格：操作名称

泛化关系（继承关系）

简单介绍：类似is-a的关系，如：猫是一个动物
简要画法
实线+空心三角形
箭头方向说明：箭头方向由子类指向父类

接口实现关系

简单介绍：接口表达的是一种has-a的关系，即拥有这类接口的操作，如：猫可以实现爬树的接口
简要画法
虚线+空心三角形
箭头方向说明：箭头方向由类指向接口

依赖关系

简单介绍：依赖关系表达的是一种use-a的关系，即一个类临时引用另外一个类的方法实现功能
简要画法
虚线+箭头
箭头方向说明：箭头由类指向被依赖类

关联关系

简单介绍：关联关系表达的是一种强依赖关系，需要长期知道对方，使用对方，如企鹅需要总是知道气候的变化
简要画法
实线+箭头
箭头方向说明：箭头由类指向被关联类

聚合关系

简单介绍：聚合关系表达的是一种弱拥有关系，如电脑与很多外设的关系
简要画法
空心菱形+实线+箭头
箭头方向说明：箭头由整体指向部分

组合关系（合成关系）

简单介绍：合成关系表达的是一种强拥有关系，并且生命周期相同，不能单独存在
简要画法
实心菱形+实线+箭头
箭头方向说明：箭头由整体指向部分

举例

![在这里插入图片

第六章 代码生成

进程视图：可能的独立运行的进程或者线程以及关联的活动对象
开发视图：构件图能够描述多个构件的构成及它们之间的联系
物理视图：部署图描述哪些软件构件最终在哪些机器上运行的情况

第七章： 类的详细设计

结构化的程序

如果程序的代码块仅仅通过顺序、选择和循环三种控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的

图形设计工具

分类：程序流程图、盒图（NS）、问题分析图（PAD）

程序流程图

盒图

PAD图

表格设计工具

判定表是一种进行详细设计的表格工具，又称为决策表。
判定表是一种进行详细设计的表格工具，又称为决策表，判定表有4个部分构成，分别是条件列表、条件组合、动作列表及动作入口。

例如：某工厂机器维修的方式：对功率大于50马力的机器或已运行10年以上的机器，应送到专业的维修公司处理；否则如果功率小于20马力，并且有维修记录，则在车间维修；否则送到本厂的维修中心维修。

判定表的化简：使用“—”来表示对此条件的不关心或不适用任意两个条件组合之间不能有交集

判定树：判定树又称为决策树，是应用于数据分类的一种树结构。其中的每个内部结点代表对某个属性的一次测试，每条边代表一个测试结果，叶结点代表某个类或者类的分布。

状态图

应含有一个唯一的开始状态，可以有多个结束状态，开始状态和结束状态统称伪状态。
状态：
每个状态描述中除了状态名字以外，还可以包含以下三个预定义的事件的描述：

• Entry：给出当刚进入该状态时应该进行的“边界”动作（action）。
• Do：给出在保持该状态的过程中，对象应执行的活动。
• Exit：这个部分描述当离开该状态时应进行的“边界”动作（action）。

这三个部分的内容是可选的，根据需要进行取舍。

举一个例子：

活动图

状态图是用于确定某个类（或者说是对象）的各种状态转换，例如，冰、水、水蒸气三种表示了水的三种状态。
活动图是表示某个过程中步骤的先后顺序，比如冰加热变成水蒸气的过程，1.冰块融化成水；2.水蒸发变成水蒸气。
举例子：

顺序图（时序图）和协作图