软件架构设计---基于鲁棒图进行设计

如何借助鲁棒图进行初步设计呢？

      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，会陷入诸若有几个窗口，是否是有一个专门的结果显示页面等诸多细节之中，初步设计就无法作了。

   别忘记了，初步设计的目标是发现职责。初步设计无须展开架构设计细节，不然就背上了”包袱“，这是复杂系统架构设计起步时的大忌。