- 为给定的描述
- 建⽴⽤例图
- 建⽴分析类图(概念类图)
- 只有属性, 没有⽅法
- 建⽴系统顺序图
- 建⽴状态图
结构化分析
数据流图(DFD)
表明系统的输入, 处理, 存储和输出, 数据的动态流程
基本元素: 外部实体, 过程, 数据流, 数据存储.
语法规则:
- 过程必须同时具有输入和输出, 并且二者存在差异
- 数据流必须和过程关联, 要么是过程的输入要么是过程的输出
分层结构:
- 上下文图: 最高抽象, 整个系统封装为一个过程, 只体现系统与外部实体之间的数据流交互, 描述环境
- 0层图: 对上下文图的第一次分解, 概括系统的所有功能, 作为整个系统的功能概图
- N层图: 对0层图和N-1层图进行分解得到, 直至得到原始DFD(不可分解)
平衡原则: 分解后子图的输入流, 输出流和父过程保持一致.
实体关系图(E-R图)
描述系统需要存储的数据信息, 数据的静态设计
基本元素: 实体, 属性, 关系
最大基数, 最小基数
面向对象分析
主要模型技术: 统一建模语言(UML)
为给定的系统描述建立用例图, 概念类图, 系统顺序图, 状态图
用例图
四要素(参与者, 关系, 用例, 系统边界)
用例: 用户与某一个目标相关的成功和失败场景的集合, 包含不同的交互行为序列
人话: 用例就是处理同一个业务时可能出现的不同交互流程的集合, 包括成功流程和失败流程等
用例图的基本元素:
- 参与者 → 发起后参与用例的外部用户或其他软件系统
- 关系 → 参与者与用户的连线
- 用例
- 系统边界 → 系统成分和系统外事物的分界线
细化用例原则:
- 不要将用例细化为单个操作(保持集合性质)
- 不要将同一个业务目标细化到不同用例
- 不要将没有业务价值的内容作为用例
概念类图(用例的对象角度)
- 只有属性, 没有方法, 类型和可见性
- 需要标出类之间的关系
基本元素:
- 对象 → 对具体问题域事物的抽象, 拥有标识符, 状态和行为
- 类 → 具有相同属性和行为的对象的集合, 提供统一描述. 概念类只描述重要属性(没有类型约束), 不标记行为(即方法)
- 链接 → 对象之间的协作关系(物理或业务联系), 可以是单向或者双向
- 关联(聚合) → 类之间的关联(语义联系), 是链接的抽象. 关联具有一个名称和多个终端, 每个终端包含角色和基数特征. 特殊关联: 聚合, 组合(组合: 整体除了包含部分之外还有完全的管理职责, 部分无法单独存在)
- 继承 → 子类具有父类的全部属性和服务
建立步骤:
- 对每个用例文本描述, 尤其是场景描述, 建立局部概念类图
- 识别候选类 → 名词分析
- 筛选候选类, 确定概念类 → 该类的对象实例的行为和状态是否都必要
- 识别关联 → 发现写作关系和语义联系, 去掉冗余关联
- 识别重要属性 → 协作时必要的信息, 是协作的条件, 输入, 结果或过程记录
- 合并为整体概念类图
系统顺序图(用例的行为角度)
- 顺序图: 描述特定上下文环境(单个典型用例场景)中一组对象的交互行为
- 系统顺序图: 将整个系统看做一个对象, 描述外部参与者和系统的交互行为
建立步骤:
- 确定上下文环境(选择一个用例)
- 找到外部交互对象
- 按照用例描述中的流程顺序添加消息
状态图
- 主体+状态迁移
- 认准状态图的主体, 再识别转移, 动作和条件
基本元素: 状态, 开始状态, 结束状态, 事件, 监护条件, 活动, 转换
建立步骤:
- 确定上下文环境, 搞清楚状态的主体(如类, 用例, 多个用例和整个系统)
- 识别状态, 标记初始和结束状态集
- 根据描述的系统行为建立状态转换
- 补充详细信息, 如添加触发事件, 转换行为和监护条件等信息
