软件架构设计---基于鲁棒图进行设计
2015-08-12 11:36
441 查看
如何借助鲁棒图进行初步设计呢?
ADMEMS方法归纳了鲁棒图建模的10条经验要点,分别覆盖语法,思维,技巧,注意事项等4个方面。
鲁棒图建模的10条经验。
1.遵守建模规则。
通过以下4条语句,可以理解该图的本质:
1.1 参与者只能与边界对象交谈。
1.2 边界对象只能与控制对象和参与者交谈。
1.3 实体对象也只能与控制对象交谈。
1.4 控制对象既能与边界对象交谈,也能与控制对象交谈,但不能与参与者交谈。
2.简化建模语法
2.1 ADMEMS方法推荐鲁棒图建模的语法。在实践中,简化的鲁棒图语法将有利于集中精力进行初步设计,而不是关注细节。
3.遵循3种元素的发现思路
用例=N个场景。每个场景的实现都是一连串的职责进行协作的结果。所以,初步设计可以通过”研究用例执行的不同场景,发现场景背后应该有哪些不同的职责“
4.增量建模
举例说明:类似WinZip,WinRar这样的压缩工具大家都用过。为其中的”压缩“功能进行基于鲁棒图的初步设计。
首先,识别最明显的职责。对,就是你自己认为最明显的那几个职责--不要认为设计和建模有严格的标准答案。如果 ,你认为压缩就是把原文件变成压缩包的处理过程,于是识别出了3个职责:
接下来,开始考虑职责间的关系,并发现新职责。压缩器读取原文件,最终生成压缩包---这里可以将打包器独立出来,它是受了压缩器的委托而工作的。
继续同样的思维方式。下图的鲁棒图中间成果,又引入了压缩配置,它影响着压缩器的工作方式,例如加密压缩,分卷压缩或者其他。
最终的鲁棒图如8-13所示。压缩功能还要支持显示压缩进度,以及随时取消进行了一半的压缩工作。所以你又识别出了压缩行进界面和监听器等职责。
5.只对关键功能(用例)画鲁棒图
基于”关键需求决定架构“的理念,功能需求作为需求的一种类型,在设计架构时不必针对每个功能都画出鲁棒图。
6.每个鲁棒图有2-5个控制对象
既然是 初步设计,鲁棒图建模时,针对关键功能的每个鲁棒图中得控制对象不必太多太细,5个是常见的上限值。相反,若实现某功能的鲁棒图中只含一个控制对象,则是明显地”设计不足“--这个控制对象的名字必然和功能的名字相同,这意味着没有对职责进行真正的切分。例如,WInZip的压缩功能设计成8-14所示的鲁棒图,几乎没有任何意义。
7.勿关注细节:
初步设计不应该关注细节。例如,
1.对每个对象只标识对象名,都未识别其属性和方法。
2.”活期账户销户界面“,具体可能是对话框,WEB界面,字符终端界面,但鲁棒图中没有关心这些细节问题。
3.”客户资料“ 等实体对象须要持久化吗?不关心,更不关心用Table还是用File或其他方式持久化。
4.没有标识控制流的严格顺序。
8.勿过分关注UI,除非辅助或验证UI设计。
过分关心UI,会陷入诸如有几个窗口,是不是有一个专门的结果显示页面等诸多细节之中,初步设计就没法做了。
别忘记了,初步设计的目标是发现职责。初步设计无须展开架构设计细节,否则就背上了”包袱“,这是复杂系统架构设计起步时的大忌。
版权声明:本文为博主原创文章,未经博主允许不得转载。
ADMEMS方法归纳了鲁棒图建模的10条经验要点,分别覆盖语法,思维,技巧,注意事项等4个方面。
鲁棒图建模的10条经验。
1.遵守建模规则。
通过以下4条语句,可以理解该图的本质:
1.1 参与者只能与边界对象交谈。
1.2 边界对象只能与控制对象和参与者交谈。
1.3 实体对象也只能与控制对象交谈。
1.4 控制对象既能与边界对象交谈,也能与控制对象交谈,但不能与参与者交谈。
2.简化建模语法
2.1 ADMEMS方法推荐鲁棒图建模的语法。在实践中,简化的鲁棒图语法将有利于集中精力进行初步设计,而不是关注细节。
3.遵循3种元素的发现思路
用例=N个场景。每个场景的实现都是一连串的职责进行协作的结果。所以,初步设计可以通过”研究用例执行的不同场景,发现场景背后应该有哪些不同的职责“
4.增量建模
举例说明:类似WinZip,WinRar这样的压缩工具大家都用过。为其中的”压缩“功能进行基于鲁棒图的初步设计。
首先,识别最明显的职责。对,就是你自己认为最明显的那几个职责--不要认为设计和建模有严格的标准答案。如果 ,你认为压缩就是把原文件变成压缩包的处理过程,于是识别出了3个职责:
接下来,开始考虑职责间的关系,并发现新职责。压缩器读取原文件,最终生成压缩包---这里可以将打包器独立出来,它是受了压缩器的委托而工作的。
继续同样的思维方式。下图的鲁棒图中间成果,又引入了压缩配置,它影响着压缩器的工作方式,例如加密压缩,分卷压缩或者其他。
最终的鲁棒图如8-13所示。压缩功能还要支持显示压缩进度,以及随时取消进行了一半的压缩工作。所以你又识别出了压缩行进界面和监听器等职责。
5.只对关键功能(用例)画鲁棒图
基于”关键需求决定架构“的理念,功能需求作为需求的一种类型,在设计架构时不必针对每个功能都画出鲁棒图。
6.每个鲁棒图有2-5个控制对象
既然是 初步设计,鲁棒图建模时,针对关键功能的每个鲁棒图中得控制对象不必太多太细,5个是常见的上限值。相反,若实现某功能的鲁棒图中只含一个控制对象,则是明显地”设计不足“--这个控制对象的名字必然和功能的名字相同,这意味着没有对职责进行真正的切分。例如,WInZip的压缩功能设计成8-14所示的鲁棒图,几乎没有任何意义。
7.勿关注细节:
初步设计不应该关注细节。例如,
1.对每个对象只标识对象名,都未识别其属性和方法。
2.”活期账户销户界面“,具体可能是对话框,WEB界面,字符终端界面,但鲁棒图中没有关心这些细节问题。
3.”客户资料“ 等实体对象须要持久化吗?不关心,更不关心用Table还是用File或其他方式持久化。
4.没有标识控制流的严格顺序。
8.勿过分关注UI,除非辅助或验证UI设计。
过分关心UI,会陷入诸如有几个窗口,是不是有一个专门的结果显示页面等诸多细节之中,初步设计就没法做了。
别忘记了,初步设计的目标是发现职责。初步设计无须展开架构设计细节,否则就背上了”包袱“,这是复杂系统架构设计起步时的大忌。
版权声明:本文为博主原创文章,未经博主允许不得转载。
相关文章推荐
- 架构、框架和设计模式关系(转)
- android 集合架构三- ArrayList
- 如何告知用户以及蜘蛛网站正在维护?
- 游戏架构脚本该如何来写
- 如何给网站添加内部链接
- Web网站的性能测试工具
- VO(DTO)模式在架构设计中是否需要
- ALSA(高级Linux声音架构):一 简单例子
- DNSPod--国内最早提供免费智能DNS产品的网站,致力于为各类网站提供高质量的多线智能DNS免费解析
- iOS应用架构谈(一):架构设计的方法论
- 基金公司官方网站设计建设
- 一些好的技术博客知识和网站
- 伪静态网站分享到微信链接打不开的解决办法
- 高负载web架构(三)
- JavaScript实现网站访问次数统计代码
- 高负载web架构(二)
- 常见学习网站汇总
- 高负载web架构(一)
- 架构师速成-如何高效编程 for java
- JavaScript实现网站访问次数统计代码