质量属性

• 性能
• 可用性
• 安全性
• 可修改行

性能

可用性

正常运行的时间比例

安全性

可修改性

较高性价比的对系统进行变更

简单评测：修改需要花多少时间

易用性、可测试性

评估

• 敏感点：影响某一个质量属性
• 权衡点：多个质量属性的敏感点
• 风险点：架构设计中的隐患
• 非风险点： 可接受的功能或业务

方法

场景

场景构成

可修改性

性能

可测试性

易用性

安全性

论文写作技巧

摘要(300)

1. 项目背景
2. 点题
3. 体现分论点
4. 总结

   背景(400)

5. 系统的背景、发起单位、目的、开发周期、交付的产品等
6. 你的主要岗位职责等，我的角色和单人的主要工作
7. 系统功能模块划分，主要功能介绍

理论(300-400)

可以有个开头，介绍一下对主题的理解，然后再继续写
优先准确反应，其次至少部分准确放映，少量涉及响应

过度(100)

承上启下，引入主题内容（核心论点）

项目(1200-1500)

建议 三个分论点
1、某种特定风格的3个阶段、3个维度
2、3种架构分别展开SS
3、按3种子系统

分论点

• 总起句
• 编号+标题

结论(400)

先分析项目运行效果

再总结项目不足，针对不足提出解决方案或思路(最好是解决的，不是我的问题)

展望未来

基于架构的软件开发方法(ABSD)

开发过程

• 架构需求
• 架构设计
• 架构文档化
• 架构复审
• 架构实现
• 架构演化

软件架构风格

数据流风格

区别

• 批处理：整体处理，没有用户交互
• 管道-过滤器：流式处理，少量用户交互

调用/返回风格

• 面向过程
• 面向对象
• 分层架构
  

独立构件风格

虚拟机风格

• 解释器，自定义规则
  

• 规则为中心（再解释器的基础上，增加了经验规则），专家系统
  

以数据为中心

区别

闭环控制架构（过程控制）

经典应用

• 空调温控
• 定速巡航

模型驱动架构（MDA Model Driven Architecture）

软件架构复用

角度1

• 机会复用（只要发现可复用的资源）
• 系统复用（规划进行复用）

角度2

• 横向复用（通用的）
• 垂直复用（垂类、行业相关）

特定领域架构（DSSA）

聚焦某个行业

• 水平：不同领域，平移
• 垂直：相同领域，深入

参与人员

有领域经验的人员

• 领域专家
• 领域分析人员
• 领域设计人员
• 领域实现人员

三层次模型

软件产品线

结构化需求分析

数据流图

四要素

• 数据流：数据流向，没有控制信息
• 加工：功能块
• 数据存储：数据库、数据表
• 外部实体：使用这个系统的实体

数据平衡

• 父子平衡
• 没有输入有输出
• 没有输出有输入
• 输入输入不对版

面向对象分析 UML

用例图

• 参与者（使用者，外部实体）
• 用例（加工，功能块）

• 流程

• 识别参与者
• 合并需求获得用例
• 细化用例描述(需要细节才知道做什么)
• 调整用例模型（包含、扩展、泛化关系优化）

用例关系

• 包含（使用关系）：多个功能的共性抽取出来，都涉及到公共用例，必然
• 扩展关系: 有时要用到某种职能，可选
• 泛化：提高通用性，父子关系，如果没有父子关系就是包含

类图和对象图

• 类名
• 多重度
• 关系

关系

语义强度（两者之间关系的稳定度），从弱到强

• 依赖关系：一个事物影响到另外一个事物
• 关联关系：描述了一组链，链是对象之间的连接
• • 聚合关系：部分与整体生命周期不同
• • 组合关系：部分和整体生命周期相同
• 实现关系：接口和类的关系，父类改成给你了接口（抽象类，实现类的关系）
• 泛化关系：特殊（子类）和一般（父类）关系

菱形，箭头部分是整体，另外一遍是部分

软件工程

系统运行与软件维护

遗留系统演化策略

方向

• 技术水平
• 业务价值

四个象限

• 淘汰：低水平、低价值
• 集成：高水平、低价值，针对信息孤岛
• 继承：低水平、高价值，意味着完全兼容遗留的功能模型、数据模型。集成的是模型，不是系统
• 改造：高水平、高价值，增强现有系统

转换策略

• 直接转换策略：停掉老的，开始新的，风险高
• 并行转换策略：有一段时间，两个系统并行运行，新系统稳定后，关闭老系统，成本高
• 分段转换策略：一段一段进行转换，或者分试点

影响可软件维护的因素

一组

• 可理解性：源码与相关文档是否容易理解
• 可修改性：修改的难易程度
• 可测试性：验证软件程序的难易程度

二组

• 可靠性
• 可移植性

软件维护类型

• 正确性维护：修 BUG
• 适应性维护：应变，适应环境变化
• 完善性维护：新需求，扩展功能，改善性能
• 预防性维护：针对未来，专用改通用

架构描述语言 ADL

三要素

• 构件：用来实现功能的单元
• 连接件：连接构件的部件
• 架构配置：描述体系结构的构建与连接件的连接图

4+1 视图

• 逻辑视图：最终用户、主要表示功能（类与对象）
• 开发视图：开发软院、软件管理（源代码结构，软件之间的配合、组装）
• 进程视图（过程视图）：继承人员、性能
• 物理视图：系统工程人员(安装、拓扑、通信)

基于架构的软件开发方法

• ABSD 方法是架构驱动，即去强调

嵌入式技术

层级

• 应用层
• 中间件层
• 操作系统层
• 抽象层
• 硬件层

初始化过程

• 片级初始化
• 版级初始化
• 系统初始化

系统部件

• 嵌入式微处理器
• 存储器
• 内外总线逻辑
• 定时计数器
• 看门狗电路
• IO 接口
• 外部设备
• 其他部件

典型架构

层次化模式架构

层次化模式，
调用方式分两种

封闭型，智能调用同层、下一层，封装，移植性好。

快放型，可以调用任意一层，性能好

递归模式架构

• 自顶向下，没有便宜用例中规定的需求
• 自底向上，最终开发者会达到子系统级的抽象

发展历程

• 单片微型计算机
• 微控制器
• 片上系统
• 以 Internet 为基础的嵌入式系统
• 智能化、云技术推动下的嵌入式系统

微处理器

• 微处理器 MPU
• 微控制器 单片机 MCU
• 信号处理器 DSP
• 图形处理器 GPU
• 片上系统 SOC

嵌入式操作系统定义及特点

时间敏感程度

• 嵌入式非实时系统
• 嵌入式实时操作系统

安全性

• 非安全攸关系统
• 安全攸关系统

特点

• 微型化
• 代码质量高
• 实时性强
• 专业化
• 实时性强
• 可裁剪、可配置（可定制）

操作系统内核架构

宏内核

内核实现的功能复杂度高，用户空间只放应用程序

运行效率高，占用资源多，不易裁剪，稳定性安全性相对差

微内核

内核实现的功能简洁，大部分服务放在用户空间，服务使用C/S架构

结构清晰，有利于协作开发，方便裁剪移植，可靠性安全性高，适用于分布式系统(C/S架构)，性能相对差

嵌入式数据库分类

• 内存方式
• 文件方式
• 网络方式

嵌入式软件开发

系统设计

界面设计

• 置于用户控制之下（典型反例：各种广告）
• 减少用户的记忆负担（默认的一些图标，X是关闭，之类）
• 保持界面的一致性（）

结构化设计

自顶向下，逐步分解求精

• 概要设计（分解模块，模块之间的关系）
• 详细设计（具体任务选择合适的处理办法）

  原则

• 模块独立性原则;高内聚(只做一件事)，低耦合()
• 模块保持的大小适中
• 多扇入，少扇出(自己本身是高度复用，少调用别人)
• 深度和宽度均不宜过高

内聚程度（从高到低）

• 功能内聚（单一功能）
• 顺序内聚（顺序执行）
• 通信内聚（一个数据结构）
• 过程内聚(特定次序执行，不可以调整)
• 时间内聚（数据初始化，在同一段时间内完成）
• 逻辑内聚（一组任务）
• 偶然内聚

低耦合（从低到高）

• 非直接耦合 (与其他模块没有直接关系)
• 数据耦合（传递简单参数）
• 标记耦合(传递结构体)
• 控制耦合(传递控制流程信息，比如 传递了5，但是5是用来做判断流程)
• 外部耦合（全局变量）
• 公共耦合（公共数据区域）
• 内容耦合 （访问另一模块的内部数据）

面向对象设计

类的分类

• 边界类（interface）
• 控制类（应用逻辑、业务逻辑、数据库访问逻辑）
• 实体类（用户类）

  原则

  

软件测试

白盒测试与黑盒测试

• 白盒测试（结构测试）
• • 路径覆盖
• • 逻辑覆盖
• 黑盒测试（功能测试）
• • 等价类划分（不同类的问题）
• • 边界值分析

执行方式

• 人工
• 自动化
• • 先写脚本-> 自动化执行
• • 不适合项目周期短，需求变动频繁
• • 单元自动化测试、接口自动化测试、UI 自动化测试

软件测试阶段

• 单元测试(详细设计,内部模块的测试)
• 集成测试(概要设计，模块之间的测试)
• 系统测试(需求分档，功能测试、性能测试、验收测试、压力测试等)
• 确认测试（需求文档，新版教程移除）

集成测试

• 一次性组装(风险高)
• • 自顶向下(可能需要加桩模块)
• • 自底向下(模拟数据)
• 增量式组装(测试全面)

系统测试

• 功能测试
• 性能测试
• • 负载测试（各种工作负载性能）
• • 压力测试(测上线，极值，系统瓶颈)
• • 强度测试(测下线，极值，资源特别低情况运行)
• • 容量测试（并发测试）
• • 可靠性测试(MTTF之类的参数)
• 健壮性测试
• 用户界面测试
• 安全性测试
• 安装与反安装测试

需求工程

阶段

• 需求获取
• 需求分析
• 形成需求规格
• 需求确认与验证(形成需求基线)
• 需求管理(对基线的管理)

需求获取

方法

• 用户面谈（成本高，需要专业领域知识支撑）
• 联合需求计划（高度组织的群体会议，消除分歧，做好交互）
• 问卷调查(用户多，成本低)
• 现场观察（针对较为复杂的流程和操作）
• 原型化方法（解决早期需求不确定问题）
• 头脑风暴法(发散思维，产生新的观点)

需求分析

• 功能模型（数据流图 DFD）
• 数据模型（关系模型ER）
• 行为模型(状态转换图)
  通过数据字典进行联系

UML

事务

• 结构事务（静态部分）
• 行为事务（时间和空间上的动作）
• 分组事务（文件夹）
• 注释事务

图

需要熟记

• 静态图
• 行为图

需求跟踪

跟踪矩阵

需求变更管理

• 问题分析和变更描述
• 变更分析和成本计算
• 变更实现

软件工程

开发过程模型

瀑布模型

• 需求分析
• 软件设计
• 程序设计
• 编码实现
• 单元测试
• 集成测试
• 系统测试
• 运行维护

特点

严格区分阶段，只适合需求明确的项目

缺点

• 正确性难以确定
• 串行化，很长才能看到结果
• 每个阶段完全解决这个阶段的问题（不现实）

原型模型

• 需求分析（主要针对该项）
• 软件涉及
• 程序设计

两个阶段

• 原型开发阶段
• 目标软件开发阶段

原型分类

• 抛弃型原型
• 演化型原型

V 模型

测试贯穿于始终

测试分阶段，测试计划提前

W 模型

测试和开发进行

迭代和增量

增量

一块一块做增量

迭代

逐步进化

螺旋模型

以快速原型模型为基础+瀑布模型

考虑了风险问题

构建组装模型

示例：方舱医院、积木

优点：易扩展、易重用、降低成本、安排任务更灵活

缺点：需要经验丰富的架构师、设计不好的构建难重用、强调重用牺牲其他指标、第三方构建质量难控制

基于构建的软件工程（CBSE）

• 购买而不是重新构造（不要重新造轮子 ）
  

组装

• 顺序组装
• 层次组装（必须分层，层次之间接口兼容）
• 叠加组装（多个合并新的构建、对外提供接口，不需明确顺序）

  不兼容

• 参数不兼容(操作有相同的名字，但是参数类型和参数个数不相同)
• 操作不兼容(操作名有不同)
• 操作不完备(有些操作无法完成)

快速应用开发模型（RAD）

• SDLC 瀑布
• CBSD 基于构建

统一过程（UP）

核心

• 用例驱动
• 以架构为中心
• 迭代和增量

  阶段

• 初始（需求）
• 细化（设计确定系统架构）
• 构造（构建的开发、构建）
• 移交

核心工作流

• 业务建模
• 需求
• 分析与设计
• 实现
• 测试
• 部署
• 配置与变更管理
• 项目管理
• 环境

敏捷方法

敏捷方法-XP

价值观

• 沟通（加强面对面沟通）
• 简单（不过度设计）
• 反馈（及时反馈）
• 勇气（接受变更的勇气）

敏捷方法（SCRUM）

逆向工程

• 实现级（语法树）
• 结构级（程序分量之间相互联系关系）
• 功能级（程序段）
• 领域级（应用领域概念之间对应关系）

概念

• 重构（同一抽象级别，例如算法重写，输入输出不变）
• 设计恢复（借助工具抽象出有关数据设计）
• 逆向工程（设计的恢复过程）
• 正向工程（改变重构，改善整体质量）
• 再工程（）

净室软件工程