连载:面向对象葵花宝典:思想、技巧与实践(21) - SSD

用例图是用来描述系统的,而SSD(系统序列图)又是来描述用例的,oh my god,这不是在玩我们么?抓狂


System Sequence Diagram,缩写为SSD(注意不要与SSD硬盘混淆),中文翻译为“系统顺序图”,主要用于描述某个用例的某个分支场景下,外部参与者与系统的交互过程。简单来说:SSD就是用例的可视化描述

 

细心的朋友可能会发现,前面我们在介绍“用例方法”的时候说不需要画图,这里又说SSD是用来描述用例的,这不是互相冲突了么?

 

事实上并不冲突,原因在于:用例方法分析需求的时候,确实不需要图;但用例方法分析完成后得到的用例,我们可以使用SSD让用例更直观一些

 

SSD有几点需要特别注意:

1)SSD不是标准的UML图形:UML只有顺序图、用例图,但是没有一个专门的“系统顺序图”;之所以叫做“系统”顺序图,是因为这个顺序图中只有两类对象:系统、与系统交互的对象;

2)SSD是用来描述某个用例的某个分支,而不是描述系统的结构;

3)画SSD的时候,整个系统被当做一个黑盒,不涉及系统的分解

4)不需要为每个用例每个分支都画一个SSD,挑出关键的用例和分支即可;

 

有的朋友可能会有疑问:如何知道哪些用例的哪些分支是关键的呢

 

我的答案是:你认为是关键的你就画,你认为不是关键的你就不画;如果你认为所有的用例都很关键,那么所有的用例你都画即可,只要你不怕麻烦或者工作量太大;如果你认为所有的用例都很简单,那么一个都不画也可以。至于你的判断是否正确,主要靠经验积累,当经验不够的时候,也可以求助有经验的人。

 

以POS机为例,假如我们认为POS机的正常处理流程是关键分支,则对应的SSD如下:

 用例ssd

仔细对照SSD和POS机的用例,我们会发现SSD和用例基本上是对应的,但并不完全对应,例如:

Ø 用例中第1步是“顾客携带选择好的商品到收银台”,但SSD中第1步是开始交易;

Ø 用例中“顾客将钱交给收银员”,但SSD中并没有对应的步骤;

Ø 用例中最后一步是“买单完成,顾客携带商品和小票离开”,但SSD中最后一步是“交易结束”;

 

为什么会出现这种不对应的情况呢?

主要原因在于:用例是整个业务的流程,而SSD是站在系统的角度来描述系统与外部对象的交互,这就需要我们在画SSD的时候做一些技巧性的处理:

Ø 删除系统无关的业务步骤

例如上述的“顾客将钱交给收银员”,这个步骤和POS机没有关系,因此无需体现,再说了,就算你想体现,你也体现不了;

Ø 将业务语言转换为系统语言

例如用例中是描述“顾客携带选择好的商品到收银台”,但对应系统来说,这就意味了“交易开始”;同样,“买单完成,顾客携带商品和小票离开”意味着“交易结束”。

 

有的朋友可能会认为,应该在用例分析的时候就应该详细写清楚。例如,“买单完成,顾客携带商品和小票离开,收银员告诉POS机交易结束”。

这种想法本身没错,但问题在于,理想和现实总是有差距的,用例不可能那么完善,甚至有的时候用例可能都存在错误,如果我们自己没有一定的分析和理解能力,完全依赖原始的用例,这样做是不可能设计出优秀的系统的,甚至连合格的系统都可能做不到。

 

综合上面的分析,我们可以看到,SSD虽然来源于用例,但还需要在用例的基础上稍微加工一下,使得SSD能够更加聚焦于“系统”这个主角。

 

最后小小吐槽一下:用例图是用来描述系统的,而SSD又是来描述用例的,oh my god,这不是在玩我们么?

================================================ 
转载请注明出处:http://blog.csdn.net/yunhua_lee/article/details/21728601
================================================ 


UML和模式应用(原书第3版) 原书名: Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) 原出版社: Prentice Hall PTR 作者: (美)Craig Larman [作译者介绍] 译者: 李洋[同译者作品] 郑龑 出版社:机械工业出版社 目录 第一部分 绪 论 第1章 面向对象分析和设计 1.1 本书的主要内容 1.2 最重要的学习目标 1.3 什么是分析和设计 1.4 什么是面向对象分析和设计 1.5 简短示例 1.6 什么是UML 1.7 可视建模的优点 1.8 历史 1.9 参考资料 第2章 迭代、进化和敏捷 2.1 什么是UP?其他方法能否对其进行补充 2.2 什么是迭代和进化式开发 2.3 什么是瀑布生命周期 2.4 如何进行迭代和进化式分析和设计 2.5 什么是风险驱动和客户驱动的迭代计划 2.6 什么是敏捷方法及其观点 2.7 什么是敏捷建模 2.8 什么是敏捷UP .2.9 UP的其他关键实践 2.10 什么是UP的阶段 2.11 什么是UP科目 2.12 如何定制过程和UP开发案例 2.13 判断你是否理解迭代开发或UP 2.14 历史 2.15 参考资料 第3章 案例研究 3.1 案例研究涵盖的内容 3.2 案例研究策略:迭代开发+迭代学习 3.3 案例一:NextGen POS系统 3.4 案例二:Monopoly游戏系统 第二部分 初 始 阶 段 第4章 初始不是需求阶段 4.1 什么是初始 4.2 初始阶段的持续时间 4.3 初始阶段会创建的制品 4.4 何时知道自己并不了解初始阶段 4.5 初始阶段有多少UML 第5章 进化式需求 5.1 定义:需求 5.2 进化式需求与瀑布式需求 5.3 寻找需求可以采用的方法 5.4 需求的类型和种类 5.5 UP制品如何组织需求 5.6 本书是否包含这些制品的示例 5.7 参考资料 第6章 用例 6.1 示例 6.2 定义:参与者、场景和用例 6.3 用例和用例模型 6.4 动机:为什么使用用例 6.5 定义:用例是功能性需求吗 6.6 定义:参与者的三种类型 6.7 表示法:用例的三种常用形式 6.8 示例:详述风格的处理销售 6.9 各小节的含义 6.10 表示法:有其他格式吗?两栏变体 6.11 准则:以无用户界面约束的本质风格编写用例 6.12 准则:编写简洁的用例 6.13 准则:编写黑盒用例 6.14 准则:持有参与者和参与者目标的视点 6.15 准则:如何发现用例 6.16 准则:什么样的测试有助于发现有用的用例 6.17 应用UML:用例图 6.18 应用UML:活动图 6.19 动机:用例还有其他益处吗?语境的需求 6.20 示例:Monopoly游戏 6.21 过程:在迭代方法如何使用用例 6.22 历史 6.23 参考资料 第7章 其他需求 7.1 如何完成这些示例 7.2 准则:初始阶段是否应该对此彻底地进行分析 7.3 准则:这些制品是否应该放在项目Web站点上 7.4 NextGen示例:(部分)补充性规格说明 7.5 注解:补充性规格说明 7.6 NextGen示例:(部分)设想 7.7 注解:设想 7.8 NextGen示例:(部分)词汇表 7.9 注解:词汇表(数据字典) 7.10 NextGen示例:业务规则(领域规则) 7.11 注解:领域规则 7.12 过程:迭代方法的进化式需求 7.13 参考资料 第三部分 细化迭代1—基础 第8章 迭代1—基础 8.1 迭代1的需求和重点:OOA/D技术的核心 8.2 过程:初始和细化 8.3 过程:计划下一个迭代 第9章 领域模型 9.1 示例 9.2 什么是领域模型 9.3 动机:为什么要创建领域模型 9.4 准则:如何创建领域模型 9.5 准则:如何找到概念类 9.6 示例:寻找和描绘概念类 9.7 准则:敏捷建模—类图的草呼 9.8 准则:敏捷建模—是否要使用工具维护模型 9.9 准则:报表对象—模型是否要包括“票据” 9.10 准则:像地图绘制者一样思考;使用领域术语 9.11 准则:如何对非现实世界建模 9.12 准则:属性与类的常见错误 9.13 准则:何时使用“描述”类建模 9.14 关联 9.15 示例:领域模型的关联 9.16 属性 9.17 示例:领域模型的属性 9.18 结论:领域模型是否正确 9.19 过程:迭代和进化式领域建模 9.20 参考资料 第10章 系统顺序图 10.1 示例:NextGen SSD 10.2 什么是系统顺序图 10.3 动机:为什么绘制SSD 10.4 应用UML:顺序图 10.5 SSD和用例之间的关系 10.6 如何为系统事件和操作命名 10.7 如何为涉及其他外部系统的SSD建模 10.8 SSD的哪些信息要放入词汇表 10.9 示例:Monopoly SSD 10.10 过程:迭代和进化式SSD 10.11 历史和参考资料 第11章 操作契约 11.1 示例 11.2 定义:契约有哪些部分 11.3 定义:什么是系统操作 11.4 定义:后置条件 11.5 示例:enterItem后置条件 11.6 准则:是否应该更新领域模型 11.7 准则:契约在何时有效 11.8 准则:如何创建和编写契约 11.9 示例:NextGen POS契约 11.10 示例:Monopoly契约 11.11 应用UML:操作、契约和OCL 11.12 过程:UP的操作契约 11.13 历史 11.14 参考资料 第12章 迭代地从需求到设计 12.1 以迭代方式做正确的事,正确地做事 12.2 尽早引发变更 12.3 完成所有分析和建模工作是否需要几个星期 第13章 逻辑架构和UML包图 13.1 示例 13.2 什么是逻辑架构和层 13.3 案例研究应该关注的层 13.4 什么是软件架构 13.5 应用UML:包图 13.6 准则:使用层进行设计 13.7 准则:模型-视图分离原则 13.8 SSD、系统操作和层之间的联系 13.9 示例:NextGen的逻辑架构和包图 13.10 示例:Monopoly逻辑架构 13.11 参考资源 第14章 迈向对象设计 14.1 敏捷建模和轻量级UML图形 14.2 UML CASE工具 14.3 编码前绘制UML需要花费多少时间 14.4 设计对象:什么是静态和动态建模 14.5 基于UML表示法技术的对象设计技术的重要性 14.6 其他对象设计技术:CRC卡 第15章 UML交互图 15.1 顺序图和通信图 15.2 UML建模初学者没有重视交互图 15.3 常用的UML交互图表示法 15.4 顺序图的基本表示法 15.5 通信图的基本表示法 第16章 UML类图 16.1 应用UML:常用类图表示法 16.2 定义:设计类图 16.3 定义:类元 16.4 表示UML属性的方式:属性文本和关联线 16.5 注解符号:注解、注释、约束和方法体 16.6 操作和方法 16.7 关键字 16.8 构造型、简档和标记 16.9 UML特性和特性字符串 16.10 泛化、抽象类、抽象操作 16.11 依赖 16.12 接口 16.13 组合优于聚合 16.14 约束 16.15 限定关联 16.16 关联类 16.17 单实例类 16.18 模板类和接口 16.19 用户自定义的分栏 16.20 主动类 16.21 交互图和类图之间的关系 第17章 GRASP:基于职责设计对象 17.1 UML与设计原则 17.2 对象设计:输入、活动和输出的示例 17.3 职责和职责驱动设计 17.4 GRASP:基本OO设计的系统方法 17.5 职责、GRASP和UML图之间的联系 17.6 什么是模式 17.7 现在我们所处的位置 17.8 使用GRASP进行对象设计的简短示例 17.9 在对象设计应用GRASP 17.10 创建者 17.11 信息专家(或专家) 17.12 低耦合 17.13 控制器 17.14 高内聚 17.15 参考资料 第18章 使用GRASP的对象设计示例 18.1 什么是用例实现 18.2 制品注释 18.3 下一步工作 18.4 NextGen迭代的用例实现 18.5 Monopoly迭代的用例实现 18.6 过程:迭代和进化式对象设计 18.7 总结 第19章 对可见性进行设计 19.1 对象之间的可见性 19.2 什么是可见性 第20章 将设计映射为代码 20.1 编程和迭代、进化式开发 20.2 将设计映射到代码的 20.3 由DCD创建类的定义 20.4 从交互图创建方法 20.5 代码的集合类 20.6 异常和错误处理 20.7 定义Sale.makeLineItem方法 20.8 实现的顺序 20.9 测试驱动或测试优先的开发 20.10 将设计映射为代码的总结 20.11 NextGen POS程序简介 20.12 Monopoly程序简介 第21章 测试驱动开发和重构 21.1 测试驱动开发 21.2 重构 21.3 参考资料 第四部分 细化迭代2—更多模式 第22章 UML工具与视UML为蓝图 22.1 前向、逆向和双向工程 22.2 什么是有价值特性的常见报告 22.3 对工具有哪些期待 22.4 如果绘制了UML草图,如何在编码后更新该图形 22.5 参考资料 第23章 快速地更新分析 23.1 案例研究:NextGen POS 23.2 案例研究:Monopoly 第24章 迭代2:更多模式 24.1 从迭代1到迭代2 24.2 迭代2的需求和重点:对象设计和模式 第25章 GRASP:其他对象职责 25.1 多态 25.2 纯虚构 25.3 间接性 25.4 防止变异 第26章 应用GoF设计模式 26.1 适配器(GoF) 26.2 一些GRASP原则是对其他设计模式的归纳 26.3 设计发现的“分析”:领域模型 26.4 工厂(Factory) 26.5 单实例类(GoF) 26.6 具有不同接口的外部服务问题的结论 26.7 策略(GoF) 26.8 组合(GoF)和其他设计原则 26.9 外观(Facade,GoF) 26.10 观察者/发布-订阅/委派事件模型(GoF) 26.11 结论 26.12 参考资料 第五部分 细化迭代3—级主题 第27章 迭代3:级主题 27.1 NextGen POS案例 27.2 Monopoly案例 第28章 UML活动图及其建模 28.1 示例 28.2 如何应用活动图 28.3 其他UML活动图表示法 28.4 准则 28.5 示例:NextGen的活动图 28.6 过程:“统一过程”的活动图 28.7 背景 第29章 UML状态机图和建模 29.1 示例 29.2 定义:事件、状态和转换 29.3 如何应用状态图 29.4 更多UML状态机图表示法 29.5 示例:使用状态机进行UI导航建模 29.6 示例:NextGen用例的状态机图 29.7 过程:UP的状态机图 29.8 推荐资源 第30章 用例关联 30.1 包含关系 30.2 术语:具体用例、抽象用例、基础用例和附加用例 30.3 扩展关系 30.4 泛化关系 30.5 用例图 第31章 更多的SSD和契约 第32章 精化领域模型的精化 32.1 NextGen领域模型的新概念 32.2 泛化 32.3 定义概念超类和子类 32.4 何时定义概念子类 32.5 何时定义概念超类 32.6 NextGen POS案例的概念类层次结构 32.7 抽象概念类 32.8 对变化的状态建模 32.9 软件的类层次结构和继承关系 32.10 关联类 32.11 聚合关系和组合关系 32.12 时间间隔和产品价格—解决迭代1阶段的“错误” 32.13 关联角色名称 32.14 作为概念的角色与关联的角色 32.15 导出元素 32.16 受限关联 32.17 自反关联 32.18 使用包来组织领域模型 32.19 示例:Monopoly领域模型的精化 第33章 架构分析 33.1 过程:何时开始架构分析 33.2 定义:变化点和进化点 33.3 架构分析 33.4 架构分析的常用步骤 33.5 科学:架构因素的识别和分析 33.6 示例:NextGen POS的部分架构因素表 33.7 艺术:架构性因素的解决 33.8 架构分析主题的总结 33.9 过程:UP的迭代架构 33.10 参考资料 第34章 逻辑架构精化 34.1 示例:NextGen的逻辑架构 34.2 使用层模式的协作 34.3 有关层模式的其他问题 34.4 模型-视图分离和“向上”通信 34.5 参考资料 第35章 使用GoF模式完成更多对象设计 35.1 示例:NextGen POS 35.2 本地服务容错;使用本地缓存提高性能 35.3 处理故障 35.4 通过代理(PGoF)使用本地服务进行容错 35.5 对非功能性或质量需求的设计 35.6 使用适配器访问外部物理设备 35.7 对一组相关的对象使用抽象工厂模式 35.8 使用多态性和“Do It Myself”模式处理支付 35.9 示例:Monopoly案例 35.10 结论 第36章 包的设计 36.1 组织包结构的准则 36.2 参考资料 第37章 UML部署图和构件图 37.1 部署图 37.2 构件图 第38章 使用模式设计持久性框架 38.1 问题:持久性对象 32.2 解决方案:持久性框架提供的持久性服务 38.3 框架 38.4 持久性服务和框架的需求 38.5 关键思想 38.6 模式:将对象表示为表 38.7 UML数据建模简档 38.8 模式:对象标识符 38.9 通过外观访问持久服务 38.10 映射对象:数据库映射器或数据库代理模式 38.11 使用模板方法模式进行框架设计 38.12 使用模板方法模式的具体化 38.13 使用MapperFactory配置Mapper 38.14 模式:缓存管理 38.15 在类合并和隐藏SQL语句 38.16 事务状态和状态模式 38.17 使用命令模式设计事务 38.18 使用虚代理实现滞后具体化 38.19 如何在表表示关系 38.20 PersistentObject和关注分离 38.21 未决问题 第39章 架构的文档化:UML和N+1视图模型 39.1 SAD和架构视图 39.2 表示法:SAD的结构 39.3 示例:NextGen POS的SAD 39.4 示例:Jakarta Struts 的SAD 39.5 过程:迭代式架构文档 39.6 参考资料 第六部分 其 他 主 题 第40章 迭代式开发和敏捷项目管理的进一步讨论 40.1 如何计划一次迭代 40.2 适应性计划与预测性计划 40.3 阶段计划和迭代计划 40.4 如何使用用例和场景来计划迭代 40.5 早期预算的有效性(无效性) 40.6 将项目制品组织起来 40.7 何时你会发现自己并没有理解迭代计划 40.8 参考资料 参考文献
评论 10
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值