20181024面向对象系统分析与设计
系统分析：状态图 顺序图 协作图 活动图
当需求模型趋于稳定时，它们就被结构化为一个系统生命周期内健壮和可持续的形式
一个理想的实现环境不考虑：硬件 数据库管理系统 编程语言等可能改变系统生态的因素
我们对所有逻辑类进行详细说明（如何联系与分组等）
我们将行为活动分配给分析模型的类中的用例模型和领域模型（活动由哪些对象来承担）
系统分析的重要性 产出一个更清晰和完整的需求说明 用开发人员语言描述 - 编程人员友好 结构需求的描述更易懂 first cut at design
系统分析过程： 1 架构分析 分析包 分析明显的类 分析通用的特殊需求（安全性等） 2 用例分析 辨别分析类 给对象分配活动 说明分析对象之间的交互 捕获特殊需求（非功能性） 3 类分析 辨别和持久化分析类的职责、属性及其关系 描述重要的类活动 捕获特殊需求（非功能性） 4 包分析 建模中的package是用来组织建模中元素的概念 独立性 可持续性
分析类（analysis classes） 代表系统中一个或多个类的一个抽象 主要为了处理功能需求
类描述是概念性的 不是面向实现的 属性：类型是概念的 不是编程语言的变量类型 行为活动：使用文字描述来定义 关系：概念的 不是面向实现的
分析类的分类： 边界类：对系统与角色之间交互的建模（如交互的内容）（图标为一个圆圈朝外画出一个接口） 说明交互的任务 而不是交互细节 如何辨别边界类：从角色开始 通常在用例描述中找到 如：显示信息 输入输出等 对每个人类角色至少应该有一个中心边界类（如主界面窗口） 对外部系统角色至少应该有一个中心边界类 中心边界类可以是多个子边界类的聚合
实体类：对永久存在且经常出现信息的建模（图标为一个圆圈下面一条横线） 代表独立物体、实时对象或活动等概念 来源一般为领域模型 可能以数据库的形式实现 封装和隔离信息变化（业务改变时，实体类改变即可，不必改动数据 类比数据库视图）
控制类：对一个或多个类中的控制行为建模（图标为圆圈内加尖角） 负责把参与用例的对象关联起来 对每个用例至少应有一个控制类 封装业务流程逻辑 隔离逻辑业务变化
交互图（scenarios）：捕获用例需要实施活动所用到的对象和交互 分类：协作图（collaboration diagrams） 顺序图（sequence diagrams）
分析类交互：最佳实践 1 角色只能和边界类交互 2 边界类只能和控制类和实体类交互 3 实体类只能和控制类和边界类交互 4 控制类可以和边界、实体和其他控制类交互
协作图 展示对象之间的参与与信息流 那张图 要点：为了便于理解 文字应该简短 事件流分析 特殊的对象设计描述：创建 销毁 短暂存在
顺序图 展示基于时序的对象间交互 强调活动的顺序 那张图 活动时间代表对象在该时间内在内存中存在 同步 异步反馈
对于任务很多的类 分解为多个类
类的分析 辨别每个分析类的职责 辨别每个属性：边界类 实体类 控制类 辨别联系 聚合与泛化
状态图 表示单个对象的状态 表示一个对象能接收和发送的消息 展示了一个对象在生命周期内可能经历的所有状态 状态可以从顺序图中发现 状态在业务上有明确意义
当事件发生而没有触发任何迁移，则该事件没有太大意义
action与activity的关系：action是原子的（不能打断） activity是由一系列action组成的（可以打断）
那张图
子状态与并行状态 图
活动图 展示一个用例中多个对象之间的工作流或一个操作的一系列流程（控制流） 图 图中横线代表并行执行 没有互相干扰