软件工程
大家好呀！我是小笙，本章我主要分享系统架构设计师 - 软件工程(1)知识，希望内容对你有所帮助！！
软件工程（13-22分）非常重要
软件开发方法
原型法【需求阶段】
- 按功能分：水平原型（界面）、垂直原型（复杂算法）
- 按最终结果分：抛弃式原型、演化式原型
结构化法
- 自顶向下，逐步分解求精严格分阶段，阶段产出标准化，但是应变能力差
面向对象方法
- 自底向上，阶段界限不明，更好应变、更好复用，符合人们的思维习惯
面向服务的方法
- 粗粒度、松耦合以及标准化和构件化
- 抽象级别：操作【低】=> 服务【中】=> 业务流程【高】
其他软件开发方法
- 形式化方法：净室软件工程【受控污染级别的环境】，数学模型化，所有东西均可证明/验证，而不是测试
- 统一过程方法
- 敏捷方法
- 基于架构的开发方法【ABSD】
例题
1、软件方法学是以软件开发方法为研究对象的学科。其中，自顶向下开发方法 是先对最高层次中的问题进行定义、设计、编程和测试，而将其中未解决的问题作为一个子任务放到下一层次中去解决。自底向上开发方法 是根据系统功能要求，从具体的器件、逻辑部件或者相似系统开始，通过对其进行相互连接、修改和扩大，构成所要求的系统。形式化开发方法 是建立在严格数学基础上的软件开发方法
- A 面向对象开发方法 B 形式化开发方法 C 非形式化开发方法 D 自顶向下开发方法
- A 自底向上开发方法 B 形式化开发方法 C 非形式化开发方法 D 原型开发方法
- A 自底向上开发方法 B 形式化开发方法 C 非形式化开发方法 D 自顶向下开发方法
软件开发模型
瀑布模型 SDLC
应用于需求比较明确的
增量与迭代
- 增量：一个模块一个模块增加
- 迭代：先画出整体框架，迭代优化整体
螺旋模型
V 模型 和喷泉模型
-
V 模型：测试贯穿始终
-
喷泉模型：早期的面向对象模型
构件组装模型 CBSD
模块化、组件化
统一过程 UP
核心：用例驱动 以架构为中心 迭代和增量
- 初始：定义最终产品视图和业务模型 ；确定系统范围
- 细化：设计及确定系统架构 ； 制定工作计划以及资源要求
- 构建：构造产品并继续演进需求、架构、计划直至产品提交
- 交付：把产品提交给用户使用
敏捷方法
- 无软件开发方法：无序，不可控
- 传统软件开发方法：预设性的、以开发过程为本、整体分阶段
- 敏捷方法：适应性的、以人为本、增量迭代，小步快跑、适合小型项目
4 大价值观
- 沟通：【加强面对面沟通】
- 简单【不过度设计】
- 反馈【及时反馈】
- 勇气【接受变更的勇气】
12 条过程实践规则
- 简单设计
- 测试驱动
- 代码重构
- 结对编程
- 持续集成
- 现场客户
- 发行版本小型化
- 系统隐喻
- 代码集体所有制
- 规划策略
- 规范代码
- 40小时工作机制
具体模型
- 极限编程(XP)：一些对费用控制严格的公司中的使用，非常有效
- 水晶方法：探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡
- 开放式源码：程序开发人员在地域上分布很广【其他方法强调集中办公】
- SCRUM：明确定义了的可重复的方法过程
- 功用驱动开发方法(FDD)：编程开发人员分成两类：首席程序员和"类"程序员
- ASD方法：其核心是三个非线性的、重叠的开发阶段：猜测、合作与学习
例题
1、螺旋模型 把整个软件开发流程分成多个阶段，每一个阶段都由目标设定、风险分析、开发和有效性验证以及评审构成
- 原型模型
- 瀑布模型
- 螺旋模型
- V模型
2、下列关于敏捷方法的叙述中，错误的是 敏捷方法尤其适合于开发团队比较庞大的项目
- 与传统方法相比，敏捷方法比较适合需求变化大或者开发前期对需求不是很清晰的项目
- 敏捷方法尤其适合于开发团队比较庞大的项目
- 敏捷方法的思想是适应性，而不是预设性
- 敏捷方法以原型开发思想为基础，采用迭代式增量开发
3、开放式源码开发方法 适用于程序开发人员在地域上分布很广的开发团队。功用驱动开发方法(FDD) 中，编程开发人员分成首席程序员和"类"程序员
- 水晶系列(Crystal)开发方法 开放式源码开发方法 SCRUM开发方法 功用驱动开发方法(FDD)
- 自适应软件开发(ASD) 极限编程(XP)开发方法 开放统一过程开发方法(Open UP) 功用驱动开发方法(FDD)
逆向工程
逆向工程是设计的恢复过程（结果反推过程）
- 实现级：包括程序的抽象语法树、符号表、过程的设计表示
- 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构
- 功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型
- 领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如实体关系模型
例题
软件逆向工程就是分析已有的程序，寻求比源代码更高级的抽象表现形式。在逆向工程导出信息的四个抽象层次中，结构级 包括反映程序各部分之间相互依赖关系的信息；功能级 包括反映程序段功能及程序段之间关系的信息
- A 实现级 B 结构级 C 功能级 D 领域级
- A 实现级 B 结构级 C 功能级 D 领域级
需求工程
软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望
需求开发【技术维度】
- 需求定义
- 需求获取
- 需求分析
- 需求验证
需求管理【管理维度】
- 变更控制
- 版本控制
- 需求跟踪
- 需求状态跟踪
需求定义
严格定义法
- 所有需求都能够被预先定义
- 开发人员与用户之间能够准确而清晰地交流
- 采用图形文字可以充分体现最终系统
原型法
- 并非所有的需求都能在开发前被准确的说明
- 项目参加者之间通常都存在交流上的困难
- 需要实际的、可供用户参与的系统模型
- 有合适的系统开发环境
- 反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法
例题
1、通常有两种常用的需求定义方法：严格定义方法和原型方法。下述的各种假设条件中，需求不能在系统开发前被完全准确地说明 不适合使用严格定义方法进行需求定义
- 所有需求都能够被预先定义
- 开发人员与用户之间能够准确而清晰地交流
- 需求不能在系统开发前被完全准确地说明
- 采用图形（或文字）充分体现最终系统
需求获取 ★ ★ ★
需求分析 ★ ★ ★
例题
在结构化分析方法中，用 DFD 表示功能模型，用 状态转换图 表示行为模型
- ER图 用例图 DFD（数据流图） 对象图
- 通信图 顺序图 活动图 状态转换图
需求验证
需求规格说明书 SRS
需求变更
- 识别出问题
- 问题分析和变更描述
- 变更分析和成本计算
- 变更实现（CCB 决定是否要实现）
- 修改后的实现
例题
1、需求变更管理是需求管理的重要内容。需求变更管理的过程主要包括问题分析和变更描述、变更分析和成本计算 、变更实现。具体来说，在关于需求变更管理的描述中，需求变更对软件项目开发有利无弊 是不正确的
- A 变更调研 B 变更判定 C 变更定义 D 变更分析和成本计算
- A 需求变更要进行控制，严格防止因失控而导致项目混乱，出现重大风险
- B 需求变更对软件项目开发有利无弊
- C 需求变更通常按特定的流程进行
- D 在需求变更中，变更审批由CCB负责审批
UML 基本概念
构造块
- 事物
- 结构事物：最静态的部分，包括：类、接口、协作、用例、活动类、构件和节点
- 行为事物：代表时间和空间上的动作。包括：消息、动作次序、连接
- 分组事物：看成是个盒子，如：包、构件
- 注释事物：UML模型的解释部分。描述、说明和标注模型的元素
- 关系
- 图
规则
- 范围：给一个名字以特定含义的语境
- 可见性：怎样使用或看见名字
- 完整性：事物如何正确、一致地相互联系
- 执行：运行或模拟动态模型的含义是什么
公共机制
- 规格说明：事物语义的细节描述，它是模型真正的核心
- 修饰：通过修饰来表达更多的信息
- 公共分类：类与对象、接口与实现
- 扩展机制：允许添加新的规则
UML4+1视图 ★ ★ ★ ★
UML图 ★ ★ ★ ★★
静态图（结构图）
- 类图：一组类、接口、协作和它们之间的关系
- 对象图：一组对象及它们之间的关系
- 构件图：一个封装的类和它的接口
- 部署图：软硬件之间映射
- 制品图：系统的物理结构
- 包图：由模型本身分解而成的组织单元，以及它们之间的依赖关系
- 组合结构图
动态图（行为图）
- 用例图：系统与外部参与者的交互
- 顺序图：强调按时间顺序
- 通信图（协作图）
- 状态图：状态转换变迁
- 活动图：类以程序流程图，并行行为
- 定时图：强调实际时间
- 交互概览图
UML关系 ★ ★ ★ ★
用例模型
- 识别参与者
- 合并需求获得用例
- 细化用例描述
- 用例名称
- 简要说明
- 事件流
- 非功能需求
- 前置条件
- 后置条件
- 扩展点
- 优先级
- 调整用例模型
- 包含关系
- 扩展关系
- 泛化关系
分析模型
- 定义概念类
- 识别类之间的关系
- 依赖关系
- 关联关系
- 聚合关系
- 组合关系
- 泛化关系
- 实现关系
- 为类添加职责
- 建立交互图