4从用例到分析、设计.pptVIP

从用例到分析、设计 需求是分析的源头 有好的材料 才能炒出好菜 从用例到分析、设计 文档研究 问卷调查 访谈 观察 示范 集中会议 研究类似组织 从用例到分析、设计 从用例到分析、设计 详细的解题流程和方法 从用例到分析 从用例到类（分析类）-静态建模 如果说用例（需求）描述了系统的“外观”，类图（分析）则描述了系统的机理！ 从用例到类 步骤： 识别类及其属性 审查属性 识别类之间的泛化 审查泛化 识别类之间的聚合/组合 审查聚合/组合 识别类之间的连接 从用例到类 首先是识别类及其属性。 方法：阅读用例文档，抽取对应于业务实体或事件的词汇，将这些词汇分类，抽取出合适的类和属性。然后再一一研究，审查类和属性的关系 从用例到类 然后识别类之间的关系，包括泛化和关联---这是两种不同方式的复用手段。 代码可能都会写，但要真正从业务上理解并不容易。 图书销售系统-类图 分析-动态建模 交互模式 顺序图描述了系统中各种对象如何协作起来，完成一个又一个用例 从用例--类--顺序图 顺序图 画顺序图的关键是责任分配。合理的责任分配能给系统带来“高内聚低耦合”的结构 背黑锅（责任）我来，送死（责任）你去，拼全力为众生（价值---用例） 从用例--类--顺序图 责任分配原则 ??原则1. 专家（ Expert ）原则 根据资源分配责任 有足够信息去完成该责任的类 ??原则2. 老板（Boss）原则 通过老板统领小弟 聚合/组合结构的消息传递 ??原则3：可视（Visibility）原则 不要和陌生人说话 两个对象之间有消息传递，则相应类必有关联 责任分配原则 老板原则： 责任分配原则 原则4. 控制者（Controller）原则 原则5. 多态（Polymorphism）原则 原则6：中介者（Indirection）原则 原则7：纯虚构（Pure Fabrication)原则 总原则1：高内聚（High Cohesion） 总原则2：低耦合（Low Coupling） 图书销售系统-顺序图 最后：编制术语表 术语表是一种关于模型的字典，其中罗列了系统模型中所有需要澄清的术语。 促进项目组成员之间的交流。 分析模型 分析类：实体类、边界类、控制类 用例实现：将用例的实现（执行）表示为分析类（对象）之间的交互 分析包：以分块的方式组织分析模型的工件 强内聚、弱耦合 完整性、正确性、一致性和易读性 ATM取款 类图 ATM取款 序列图 ATM取款 序列图 实例 下一步：系统架构分析 架构使软件易于理解、实现和管理 提高复用性 项目组协作的基础 架构 – Sun WAF 设计模型 – J2EE应用 MVC架构模式 Web MVC 框架序列图 考虑系统的分析/设计机制 持久性 通讯/消息/路由 分布性 事务 进程控制和同步 安全性 信息交换/格式转换 可用性/冗余性 遗留应用集成 差错检测/处理 日志/报告 …… 架构分析结果----架构图 最后一步：面向对象设计 得到分析类图和顺序图后，结合实现的平台和架构精化，并根据现实折衷，就得到设计了。 面向对象的设计的步骤 细化和重组类 细化和实现类间关系，明确其可见性 增加遗漏的属性，指定属性的类型和可见性 分配职责，定义执行每个职责的方法 对消息驱动的系统，明确消息传递方式 利用设计模式进行局部设计 画出详细的顺序图或协作图 面向对象设计的结果 详细内容见OOA/OOD专题 问题？ * * 导出技术 用例思维 指导 这就是需求！ 面向对象 分析设计 面向过程 分析设计 其他方法 自己的土 方法 系统 通过写用例文档来探索需求的过程就像出题。接下来就是要解题--分析设计. 我选择用面 向对象对象 的方法来 解题！ 得到类图之后，接下来的任务就是要描述出各个类如何一起合作来完成用例---把用例文档中的各种责任分解，并分配到各个类中形成操作。 * *