软件方法（业务建模和分析）----阅读笔记3（UML图的选择使用）

 

 

 UML像一个工具箱，里面各种工具都有。您只需要从这个工具箱中选择适合您的项目类型的工具用上就可以，并不需要“完整地”使用UML。有一些建模工具自带的案例模型会造成误解，一个模型里把所有的UML图都给用上了，但这是工具厂商出于展示其工具建模能力的目的而提供的，不可当真。

 

 各工作流可以选用的UML元素以及推荐用法如图所示。

 

 

不少开发人员并不喜欢用UML，更喜欢在白板上画个自造的草图，似流程图非流程图，似类图非类图，然后说“来，我给大家讲讲”。这样的做法有一个巨大的“优点”——怎么画都是对的，关于这个草图的解释权归“我”所有，同事不好批评我，项目要依赖于“我”头脑中的隐式知识——要是“我”不“给大家讲讲”，大家就玩不转了。上面这种现象，在有一定资历、但又不对项目的成败承担首要责任的“高手”身上表现更明显。 但是，这样的做法更像是想通过形式上的丑陋来遮掩内容上的丑陋。动乱年代，数学家在牛棚中用马粪纸做数学推导，不代表就可以因为演算工具简陋而允许自己胡乱使用符号和概念；过去的作家没有电脑，不意味着作家可以随意写错别字和犯语法错误。开发人员故意选择简陋的形式为简陋的内容开脱，就如同作家故意选择不好的纸来掩盖自己文字功力不足的事实，并不是好现象。UML没有强调一定要用多么昂贵的工具来建模，但是，即使您在海边用手指在沙滩上建模，模型依然要概念清晰，而不是以此为理由遮掩脓包。

有的开发人员的“十年工作经验”实际上是“一年工作经验用了十年”，一直在热热闹闹的基础层次徘徊，没有积累和成长

现在好多同学包括我在内都认为UML很鸡肋，即使有作用也很小，不应该浪费大量时间去话UML图，有画图的时间不如去写点代码。所以说我编程的时候没有一个完整的思路，有一个大概思路就开始写代码，遇到问题就卡顿很长时间，相处一步就此写一步，磕磕绊绊写完还有不少的bug。UML图其实就是设计的过程，“代码就是设计”，那么反过来“设计也是代码”，绘画UML图的过程其实也是编程的一部分。