软件工程
文章目录
题型分布
选择1x15（学堂在线选择题）
填空1x15
简答6x5
应用3-40
考试重点
p12：软件危机产生的原因
p15：软件工程的一些原则（抽象，隐藏等…)
p18~19：瀑布模型的特征：文档驱动，上一阶段导入到下一阶段，中间评审，紧密连接，优点缺点。
p29：什么是敏捷，敏捷的原则，精神，怎么体现的(不考简答)
p57：uml图：用例视图，行为视图，结构视图，构件视图
p69：需求概念，需求用处，影响，是否需求的判断。需求和设计的区别。软件需求的分类
p84-85：用例的概念，用例和需求的关系，用例图（画），用例图不用体现太多流程的内容，用例的主要描述方法(p88)【目标，交互过程…】，用例之间的关系(p87)【包含，扩展，继承】
p91：类之间的关系，类图，类和类之间的关联关系（继承，聚合，依赖，组合），多重性，
p136：需求分析的步骤（扩展稍微讲一下），用例分析，为什么构建快速模型
p146：顺序图的画法（主动执行者左边，临界类，控制类，边界类，执行类…）
p147：需求牵引的观点
p155：需求归约
p163：抽象，抽象的定义(了解)
p167：模块化，内聚的概念，耦合的概念，为什么强内聚，松耦合(167,168,169)
p178：软件体系结构的五个视图（逻辑，物理，开发…)【选填】
p199：如何精化软件体系结构
p220：界面元素。如：静态元素，动态元素，命令元素等
p254：软件的设计，类之间关系。类和类之间传递信息的手段
p291：数据流图的概念和绘画
测试是重点，题目很多
p323：测试的概念，目的
p325：黑盒测试（功能），白盒测试(结构)
p327：测试的步骤
p335：测试的三种方法（p337）
p350：软件维护的概念（维护这一张比较少）
p368：持续集成的定义，持续集成的原因，持续集成的价值（回答了为什么）
p386：软件度量的几种方法，各自用于什么过程
p452：软件的进度管理，软件进度的图形【网络图，甘特图…识别】
p464：基线技术考
重点整理
第一章——软件与软件工程
软件危机的原因
记忆：讨论的是用户，开发人员与用户，开发人员和管理人员，开发人员与大型软件，开发人员方法论，真理性这几个方面展开
- 用户对软件需求的描述经常出现二义性、不确定性、遗漏或错误
- 软件开发人员对用户需求的理解与用户本来的愿望有差异
- 大型软件项目需要组织一定的人力共同完成，多数管理人员缺乏开发大型软件系统的经验，而多数软件人员又缺乏管理经验
- 软件项目开发人员不能有效，独立自主地处理大型软件的全部关系和各个分支
- 缺乏有力的方法学和工具支持，过分地依靠程序设计人员在软件开发过程中地技巧和创造性，加剧软件产品的个性化
- 软件产品的特殊性和人类智力的局限性，使人们处理”复杂问题“困难重重
软件工程的原则
- 抽象
- 抽取事物最基本的特性和行为，忽略非基本的细节。采用分层次抽象的办法可以控制软件开发过程的复杂性，有利于软件的可理解性和开发过程的管理
- 信息隐藏
- 将模块中的软件设计决策封装起来，模块接口应尽量简洁，不要罗列可有可无的内部操作和对象
- 模块化
- 模块是程序逻辑上相对独立的成分，它是一个独立的编程单位，应有良好的接口定义，如过程语言中的函数、子程序、面向对象语言中的包、类等。
- 模块化有助于信息隐藏和抽象，有助于表示复杂的软件系统
- 局部化
- 要求在一个物理模块内集中逻辑上相互关联的计算资源
- 一致性
- 整个软件系统的各个模块均应使用一致的概念、符号和术语等
- 一致性原则支持系统的正确性和可靠性
- 完全性
- 软件系统完全实现系统所需功能，不遗漏任何重要成分的程度
- 完全性要求开发必要且充分的模块
- 为了保证软件系统的完全性，软件在开发和运行过程中需要软件管理工具的支持
- 可验证性
- 开发大型软件系统需要对系统进行分解，然后”分而治之“。系统分解应遵循系统可验证的原则，即容易检查，测试，评审，以便保证系统的正确性
使用一致性，完全性，可验证性的原则可以帮助人们实现一个正确的系统
瀑布模型（软件生存周期模型）
特征
- 思路简洁、明确
- 上一阶段的开发结果是下一阶段开发的输入
- 相邻两个阶段具有因果关系，紧密联系
- 每一阶段完成后都必须对阶段性制品进行评审
- 文档驱动
优点
- 有利于软件的体系结构设计
- 规范了软件开发活动
- 有利于开发人员的组织、管理
- 对于规模较小、软件需求比较稳定的项目或子系统，采用瀑布系统能显著提高软件开发的质量和效率
缺点
- 必须要求客户和系统分析员确定软件需求后才能进行后续的软件开发工作
- 需求确定后，用户和软件项目负责人要等相当长的时间才能得到一份软件的最初版本。若用户有修改意见成本就会很大。
- 开发人员在瀑布模型”上游”出现“过失”会为软件制品带来“缺陷”，并潜伏在软件制品中。
敏捷软件开发原则和应用（不考简答）
敏捷软件的解释
- 中小型事务处理软件开发
敏捷的原则
- p29
敏捷的精神
- 强调只开发有用制品，聚焦可执行的软件
- 反对“以文档为中心”，不做无用功
- 提倡交流，沟通，团结，合作
- 提倡用户参与软件开发的全过程有利于对软件需求的理解
- 有利于杜绝和减少软件开发过程中的缺陷和错误
第二章——UML和RUP的统一过程
uml
用例视图
- 用例图
- 从外部用户的角度描述系统功能，并指出功能的参与者
结构视图
- 结构视图包括包图，类图，对象图。
- 包图描述系统的分解结构，表示包和包之间的关系
- 类图描述系统的静态结构，类图的边表示类之间的联系，包括继承，聚合，关联和依赖等
- 对象图是类图的一个实例，它描述在某种状态下，或者在某一时间段内系统中活跃的对象及其关系
行为视图
- 行为视图包括交互图、状态图、活动图
- 交互图描述对象之间通过消息传递进行的交互与协作。又可以分为顺序图和通信图两种。
- 顺序图强调对象之间消息发送的时间序
- 通信图更强调对象间的动态写作关系
- 状态图描述类的对象的动态行为，包含对象所有可能的状态、在每个状态下能够响应的事件以及事件发生时的状态迁移与相应动作
- 活动图中包含控制流和信息流。
- 控制流表示一个操作完成后对其后续操作的触发。
- 信息流则刻画操作之间的信息交换。
- 交互图描述对象之间通过消息传递进行的交互与协作。又可以分为顺序图和通信图两种。
构件视图
- 构件视图包括构件图，它描述软件系统中各组成构件、构件的内部结构以及构件之间的依赖关系。
部署视图
- 部署视图包括部署图，它描述软件系统中的各类工件在物理运行环境中的分布情况
第三章——需求工程的概论
软件需求
概念
软件需求是利益相关方对目标软件系统在功能、质量等方面的期望，以及对目标软件系统在运行环境、资源消耗等方面的要求和约束。
分类
功能需求、质量需求、约束性需求（后两者为非功能需求）。个人认为需求的判断是选择题的考点，就是学堂在线里面的选择题。
- 功能需求：利益相关方要求目标软件系统应该具有的功能
- 具有的功能以及完成这些功能的必须遵循的约定或限制
- 质量需求：利益相关方对目标软件系统的质量要求
- 跟性能及可靠性有关
- 约束性需求：利益相关方对目标软件系统在项目预算，完成时期，技术选型，必须遵循的标准与规范等方面提出的要求，以及由预期的开发、运行环境的特征而导致的针对目标软件系统的约束
- 预算，时间，技术选型，运行环境等
需求工程的用处
良好的需求工程活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量
第四章——需求获取
用例
用例的概念
-
定义：从外部用户的视角看，一个用例是执行者与目标软件系统之间的一次典型的交互作用；从软件系统内部的视角出发，一个用例代表着系统执行的一系列动作，动作的执行结果能够被外部的执行者所察觉
-
两项特征：相对独立性和完整性
-
用例和需求之间关系
- 用例是功能性软件需求的主体部分
- 用例不是软件需求的全部，甚至也不是功能性软件需求的全部
- 全局性的业务规则、大部分非功能性的软件需求并不适于在用例中描述
用例图
-
节点有执行者和用例两者
-
用例图的边表示执行者与用例之间、两个用例之间、两个执行者之间的关系。
-
执行者与用例之间的关系：两者之间的关系在用例图中表示为它们之间的连接边，其意义为执行者触发用例的执行，向用例提供信息或者从用例获取信息。【执行者和用例为无向实线】
-
用例之间的关系(注意由于mermaid不够熟悉，书上的用例是椭圆的，三角为空心三角)
-
包含
-
-
包含关系经常被用来将多个用例中公共的子功能项提取出来，以避免重复和冗余
-
-
扩展
-
-
扩展关系经常用来区分正常的业务处理功能和带有例外处理的功能，这样可以避免例外处理逻辑搅乱或湮灭正常处理逻辑
-
-
继承
-
-
用例之间继承和扩展的取舍
- 如果能够指出明确的扩展点，则采用扩展关系
- 如果希望区分正常的业务处理功能和带有例外处理的功能，采用扩展
- 如果不仅插入新动作，还要修改原动作，采用继承（类似虚函数的多态）
-
-
-
-
执行者之间的关系
- 执行者之间的关系只有继承关系一种，其意义与面向对象中的基本继承关系相似
用例的表示（用例的主要描述方法）
- 用例名称
- 用例的功能或其业务目标
- 与用例有关的执行者
- 基本交互动作过程
- 用例的触发条件（可选）
- 用例执行的前置条件（可选）
- 扩展交互动作过程（可选）
- 用例执行完毕时的后置条件（可选）
- 业务规则（可选）
- 非功能需求（可选）
类图
类图：类图描述面向对象软件系统的静态结构
类之间的关系
- 关联
- 聚合
- 组合
- 依赖
- 实现
- 继承
类图的记忆方法
- 组合和聚合：这两个比继承和实现对象更多，体积更大，所以是菱形，本身都已经存在了，所以是实线。对于组合来说，比如商品条目、配送地址信息、付款信息组成订单，如果订单消失了，付款信息也消失了（生存周期一致），是强依赖关系，所以用
实心的菱形。而由人聚集合成起来的团队，如果团队没了但人还在，是弱依赖，所以是空心的菱形 - 继承和实现：没有组合和聚合那么多对象，所以是不胖的三角形。实现从无到有比较虚，所以是
虚线，继承原来已经有了就没那么怕，所以是实线 - 关联和依赖。依赖别人是不稳定的，靠自已有实力才能和别人合作。所以依赖是
虚线，关联是实现。同时两个只剩下最后的箭头了。（双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。）
类的多重性
多重性说明位于关联端的类可以有多少个实例对象与另一端的类的单个实例对象相联系，它表示参与关联的两个类的对象之间的数量对应关系。UML的多重性表示符号有：1,0…1,0… ∗ * ∗,1… ∗ * ∗, ∗ * ∗,m…n,n… ∗ * ∗等关系。[左边为起始数量，右边为终止数量]
第五章——需求分析和验证
需求分析的步骤
-
需求优先级分析
- 需求分析的主要任务是为每项需求确定优先级。在需求工程阶段引入优先级分析，是为了在需求分析，软件设计，构造及测试的过程中对重要的、紧迫的软件需求给予更多关注，为其分配更多的开发资源，确保其优先实现，并确保其实现质量
-
用例分析：将用例模型中关于用例的自然语言描述转化为更接近于软件设计的分析模型，开启从软件需求迈向软件设计的征程
- 精化领域概念模型
- 设置分析类
- 分析类指直接服务于软件的功能性需求的概念层次的类
- 用例的业务逻辑处理功能主要由边界类、控制类和实体类3种分析类协同完成
- 构思分析类之间的协作关系
- 将用例模型中的用例描述转化成UML交互图
- 导出分析类图
- 将消息的响应对应到类的职责，从而推动分析模型的建立和精化，持续迈向软件设计和编程实现
-
分析模型评审
- 工程师、利益相关方代表及业务专家一起正式地审查迄今为止需求分析阶段地所有工作成果
-
构建快速原型
- 澄清应用领域和软件需求的某些疑难问题，并方便利益相关方对需求分析的工作成果进行评价、纠错和确认
为什么构建快速模型
- 更加精确地理解问题域
- 确定用户需求并发掘潜在地用户需求
- 澄清应用领域和软件需求地某些疑难问题，并方便利益相关方对需求分析地工作成果进行评价、纠错和确认
顺序图的画法
横轴的摆放顺序：主动执行者左边，紧邻其右的类是作为用户界面或外部接口的边界类，再往右是控制类。控制类的右边放置实体类，它们的右侧是作为外部接口和环境隔离层的边界类，最右侧是位于目标软件系统的边界之外的被动执行者。
简单来说就是主动执行者-输入型边界类-控制类-实体类-输出型边界类
边界类：负责目标软件系统与外部执行者之间的交互，包括界面控制，外部接口，环境隔离。
控制类：负责协调，控制其他类共同完成的用例规定的功能或行为。
实体类：负责保存目标软件系统中具有持久意义的信息项并向其他类提供信息访问的操作。
1. 角色(Actor)
系统角色，可以是人或者其他系统和子系统。以一个小人图标表示。
2. 对象(Object)
对象位于时序图的顶部,以一个矩形表示。对象的命名方式一般有三种：
- 对象名和类名。例如：华为手机:手机、loginServiceObject:LoginService；
- 只显示类名，不显示对象，即为一个匿名类。例如：:手机、:LoginSservice。
- 只显示对象名，不显示类名。例如：华为手机:、loginServiceObject:。
3. 生命线(LifeLine)
时序图中每个对象和底部中心都有一条垂直的虚线，这就是对象的生命线(对象的时间线)。以一条垂直的虚线表。
4. 控制焦点(Activation)
控制焦点代表时序图中在对象时间线上某段时期执行的操作。以一个很窄的矩形表示。
5. 消息(Message)
表示对象之间发送的信息。消息分为三种类型。
-
同步消息(Synchronous Message)
消息的发送者把控制传递给消息的接收者，然后停止活动，等待消息的接收者放弃或者返回控制。用来表示同步的意义。以一条实线和实心箭头表示。 -
异步消息(Asynchronous Message)
消息发送者通过消息把信号传递给消息的接收者，然后继续自己的活动，不等待接受者返回消息或者控制。异步消息的接收者和发送者是并发工作的。以一条实线和大于号表示。
-
返回消息(Return Message)
返回消息表示从过程调用返回。以小于号和虚线表示。
6. 自关联消息
表示方法的自身调用或者一个对象内的一个方法调用另外一个方法。以一个半闭合的长方形+下方实心剪头表示。
需求牵引的观点
- 分析类的职责源于其必须响应、处理的消息（即对消息的响应构成作为消息接收者的分析类对象的职责）
- 这种职责在后续的设计活动中将被确立为“设计元素“的功能或方法
需求规约
概念：经需求工程师经需求获取的分析后形成的软件文档
需求规约目标：
- 便于利益相关方，需求工程师和软件设计人员进行理解和交流
- 支持目标软件系统的确认
- 控制系统进化过程
需求规约的主要内容：
- 系统概述
- 文档概述
- 术语定义
- 系统概述
- 目标软件系统概述
- 用户特征
- 假设和依赖
- 参考文献
- 功能性需求
- 质量需求
- 约束性需求
- 需求优先级
- 接口定义
- 需求验收标准
- 需求来源表
第六章——软件设计概论
抽象与逐步求精
软件设计一般要自顶向下地经历一系列抽象级别从高到低的设计阶段。
后续阶段会在前一阶段的基础上引进更接近于软件实现的设计元素，这一过程又被称为"逐步求精"。
模块化
模块分解
将软件系统划分为若干个相对独立的部件（称为模块），所有模块组装后可获得满足问题需要的软件解
内聚
内聚的概念：表示一个模块内部各成分彼此关联的紧密程度
耦合
耦合的概念：软件结构中多个模块之间的关联程度。
耦合的强度取决于模块间接口的复杂性，通过接口传递的数据量大小及复杂性等。
为什么强内聚松耦合(必然重点)
考虑强内聚，松耦合，合起来结构简单化清晰化，加强简单性，还支持并行开发
- 强内聚有利于软件模块的可复用性，因为模块的功能越单纯，其复用潜力往往越大
- 松耦合有利于软件系统的可修改性和可维护性，因为模块之间的依赖关系简单，传播范围缩小，有利于传播范围的分析，简化修改的复杂性
- 强内聚、松耦合有利于促进软件系统的结构化简单、清晰化，从而强化软件设计模型的简单性
- 强内聚和松耦合还能够更好地支持模块的并行开发，因为前者保证每个模块的功能相对单纯，后者在编码，调试，测试阶段可以减少模块之间相互制约的情况
还有信息隐藏和关注点分离两个原则
第七章——软件体系结构设计
体系结构的五个视图（选填）
- 逻辑视图
- 体系结构中各软件模块的逻辑功能划分
- 例子就是197页的图，分成各个层
- 开发视图
- 软件源代码的程序分包及目录结构，采用的类库，中间件或框架
- 其实就是java的左边的工作区
- 物理视图
- 安装部署的物理机器及其网络连接
- 简单来说物理视图涉及到网络和服务器
- 运行视图
- 软件运行时进程、线程的划分，它们之间的并发与同步，瞬时快照
- 比较类似活动图
- 数据视图
- 持久数据的存储方案，数据传递、备份、恢复、同步方案，与物理视图之间的映射关系
- 估计是数据库底层的玩意
如何精化逻辑体系结构
- 搜索并选取可用的设计资产
- 在当前项目中直接可供复用或借鉴的设计资产，包括现成的软件系统或子系统或类库中间件框架等
- 设计技术支撑设施
- 比如数据持久存储服务，安全控制服务等支撑应用功能的服务
- 确立设计元素
- 设计元素包括子系统、构件和设计类
- 整合设计元素
- 整合提供服务的软件元素与使用这些服务的软件元素
第八章——人机交互设计
用户界面设计模型的表示
静态元素：与软件系统的运行状态无关，在任何情况下均没有变化的文本、图标、图形、图像等。
动态元素：由软件系统根据业务逻辑自动呈现于屏幕中，且不允许用户修改的内容，包括不可编辑的文本、表格、图标、图形、图像等。
用户输入元素：只要一个界面元素在某些情况下可供用户修改或选择，就应将其归入用户输入元素类，而非动态元素类
用户命令元素：用户点击此类元素后，位于界面后端的逻辑处理或界面刷新动作将被触发，其典型代表是按钮，菜单，超链接等。
第九章——软件详细设计
确定类间连接关系[传递信息的四种手段，重要]
假如有对象obj1和对象obj2之间实现消息传递，提供以下四种手段：
- 引用全局对象。obj1直接引用作为全局对象的obj2
- 通过参数传递。ojb2作为obj1的某项操作中的实际参数
- 引用局部对象。在obj1的某项操作的函数体中创建或获取obj2
- 通过类的成员变量。obj2作为obj1所属类的属性的取值
第十一章——结构化软件开发
数据流图的概念
数据流图就是用来刻画数据流和转换的信息系统建模技术，任何软件系统都可以用数据流图表示。
数据流图的绘画
看p306的图11.21和最后一次实验
主控模块——>成输入流控制模块，变换流控制模块，输出流控制模块
第十二章——软件测试（重点，题目很多）
测试的概念
使用人工或自动手段运行软件系统的过程
测试的目的
测试的目的在于检验系统是否满足规定的需求，或确定预期结果与实际结果之间的差异
黑盒测试
黑盒测试不考虑程序的内部结构和处理过程，只通过程序的运行验证测试数据的处理结果是否与期望的一致，即程序是否能够实现测试用例的场景
- 三种方法
- 等价分类法
- 把程序的输入数据集合按输入条件划分为若干个等价类，每一等价类相对于输入条件表示为一组有效或无效的输入
- 边界值分析法
- 引入边界值分析（BVA),旨在选择测试用例，强迫程序在边界值上执行
- 对比测试法
- 关键软件即使在最后交付时只要求一个版本，开发时也另外产生一个独立版本供测试使用
- 等价分类法
白盒测试
白盒测试密切关注程序的运行细节，针对程序的每一条逻辑路径分别设计测试用例，检查分支与循环的执行情况
测试的步骤(p326)[重点]
- 单元测试,它测试程序的每一模块。目的是保证每个模块单独运行正确,多采用白盒测试法
- 集成测试(或称综合测试)，它测试软件总体结构,建立在模块的接口上，多为黑盒测试
- 确认（验收）测试，测试软件是否满足需求
- 系统测试，检查软件与系统中其他元素是否协调
第十三章——软件维护
软件维护的概念
软件维护是软件交付后保障软件生产的活动，发挥软件社会和经济效益的关键。软件交付并投入运行后，任何针对系统变更所做的工作都是软件维护
第十四章——持续集成
持续继承的概念
持续集成是当前一种广为采纳的软件开发实践，它鼓励团队中的开发者尽早将自己的阶段性成果集成至目标软件产品的某个版本，以便尽早地暴露项目中存在的缺陷
持续继承的价值（目的）
- 降低风险
- 降低项目成本
- 提高开发效率
- 敏捷响应变化
- 避免与环境相关的错误
- 提高项目的可视化程度
第十五章——软件度量与估算
软件度量方法
- 代码行度量
- 用软件项目的代码行表示软件项目的规模时十分自然和直观的
- 适用一般的高级程序设计语言
- 功能点度量
- 最初根据事务信息处理程序的基本功能定义，后来进行了扩充
- 使用功能点度量在软件系统概要设计阶段或软件体系结构设计阶段就能够估算出软件的规模
- 适用一般的事务处理系统的软件规模度量
- 对象点度量
- 对象点度量软件的要素是面向对象系统的实体（如类，操作，屏幕）个数；元素链的长度；交付给客户的系统功能
- 可用于软件开发的初始阶段
- 软件复用的度量
- 考虑被复用的软件制品的实际情况和用于待开发系统软件制品的修改工作量
- 复用程度分为逐字复用，少量修改，大量修改，全新
- 适用现代软件
第十六章——软件项目管理与过程改进
软件进度图形
网络图，甘特图…识别
基线技术
基线标志软件开发过程的各个里程碑，通过复审的软件配置项，是构成基线的重要内容，它标志开发过程中一个阶段的结束
设置基线技术的理由：在软件开发过程中，由于各种原因，需要变更需求、预算、进度和设计方案等，尽管这些变更请求中绝大部分是合理的，但在不同的时机做不同的变更其难易程度和造成的影响差别甚大，为了有效地控制变更，引入基线地概念。
1252
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
