[读后感]《UML 精髓 3rd》-100多页的uml好教材

         UML，对于大部分开发者而言都再熟悉不过了。我对它的认识还是在大学课程《软件工程》，虽然在工作中也经常用到。在大型项目，尤其是采用RUP开发流程，UML是文档中的大头。在敏捷开发中，虽然不强制要求，但在架构设计，团队交流时候，还是发挥了不可替代的作用。最近，系统学习了Martin Fowler的经典UML著作《UML Distilled 3rd》（原版)，100多页，足以让我们一窥精华。“less is more”。UML已经越来越庞大冗杂，而我们常用到的还是其中的某些精华。什么时候用UML，用什么图，怎样用？Martin Fowler将自己的多年经验毫无保留分享给大家。

 

       使用UML的主流方式：as sketch，blueprint an program language

        sketch-开发者在设计系统的某个部分时采用UML来交流，这个时候，白板来画UML草图应该是最合适的

        blueprint-在RUP开发中参加，整个系统的开发设计文档都包含了详细了UML图

        program language-还是一种不太成熟的技术，理想是用某种辅助工具，在上面画UML图，然后直接生成我们想要的软件程序

 

       使用UML时，在“合乎规则”和“方便使用”取舍？

        大部分时候，我们使用UML都遵循规则，将它看成一个program language。然而，不要忘了，我们描绘UML并不是为了直接生成软件。更多的是为了交流。当UML阻碍你的设计时候，大胆采用你认为方便的方法，目的是让他人更好地明白你的idea

 

       UML图包括两部分：结构图和行为图

       结构图又细分为：

 

        Class Diagram:      是UML中最常用到的图。它是与code鸿沟最浅的图。如果设计的更详细，可以采用相关工具实现“图--代码”的转换。类图，主要是描述系统中某个具体类的properties 和 operations以及这个类与其他类的关系约束。类图使用的标记可以很多，这使得我们容易陷入一个误区：就是“尽一切可能使用每一个标记”。只关注重点，只描绘我们关注的类。无需面面俱到。

 

       Object Diagram: 对象，是类的实例。对象图关注的是运行时各个对象之间的交互。很多时候，我们描述一个系统的静态结构都用Class Diagram。当类图还是很难让人理解时，考虑用对象图来辅助。

 

       Package Diagram：包图，和程序语言中的“包”类似，它其实是对元素的包装组合。在大型系统设计中，常常设计到非常多的图，往往让人很难理解结构。这个时候，用包图来重新组织子图，在更抽象的层次理解系统。包图，不仅仅只对类图进行封装，还可以对与其他的结构图包装。当你感觉你的系统设计图过于庞大时，就该考虑它了。

 

       Deployment Diagram：当你的系统部署很复杂，用到了很多组件/中间件，硬件条件也很复杂，该考虑它了。它可以简单明了地展示，哪些程序运行在哪些设备上。

 

       还有 Component Diagram -描述组件间的关系；Composite Structure Diagram-类在运行时分解（当一个类很庞大，很复杂）

 

        行为图分为：

       

       Sequence Diagram：展示了一个Use Case的若干个对象间的交互协作。虽然它提供了很多的标记，可以描述各种复杂的行为，比如条件、行为、并发……但这些并不是它的强项，越复杂只能越让人难以理解

 

       Activity Diagram:可以描述业务逻辑，工作流……与流程图功能类似，它的独特之处在于支持并行行为。可以描述各种复杂的业务逻辑。如果业务逻辑太庞大负载，还可以将其分解成子图。

 

       State Machine Diagram: 描述一个对象横跨若干个Use Case的行为。它重点关注的是一个对象自身生命周期在不同场景的变化。在程序中实现状态图有3中常见的方式：条件语句（switch）、状态模式和表驱动；

 

       Use Case Diagram：关注的是系统的功能展示。描述了Actor与系统的交互。很多时候难点在于找到真正的Actor。用例图不要画得太复杂。更多详细的约束条件可以在相关的约束文档中体现。

 

       还有 Interaction Overview Diagram-系列图和活动图的mix版；Timing Diagram-描述对象的交互，关注的是时间

 

最后以一句我一直推崇的名言来结束关于UML的讨论

“最好的文档就是source code”

 

 

 

      

 

徐X福翻译那版就免了，超级烂，术语都不准确。建议直接看英文。

完全同意，这本英文书才110页，写的很通畅，没有任何阻塞之感，值得一看