UML是一扇窗,打开了它,你就能看见更多东西。
当你感叹UML是集计算机专家思想大成之作时,你肯定体会到了这些图的精妙之处。
首先来联想几个常见的场景。
北京奥运会,中国长卷气势恢宏,精彩场景万众瞩目。从张艺谋到控制烟花的操作手,每一个环节都不容差错,如何快速沟通?
年末贺岁大片大战,从《阿凡达》、《十月围城》到《让子弹飞》,片场情节纷繁复杂,每一个环节都会体现不同的设计思想。如何选择一个合适的方式,让演员和片场工作人员都充分领会导演的意图?
在 让子弹飞的同时,也让思路回归到软件设计。在这个设计过程中,用户会提出复杂的需求,每次的每个业务都可能不一样。而程序员则有自己所擅长的技术,轻松套 用一个框架当然最好了。可是,最后很容易出现程序所表达的核心功能和客户的核心业务不一致,很多软件作坊也在不知不觉中走进了修修补补的误区。
1 .UML有多大的价值?
到底谁服从谁呢?毫无疑问,我们要尊重客户的需求。
对 于程序员而言,框架、技术、设计技巧是死的,分析业务是最难的。如果没有好的方法学去分析业务,那么,设计出来的模型肯定不太能客观反应现实。然后,即使 有再好的框架、技术、分层架构、ORM、缓存,都没用了。由此,我们会引申出一个话题:怎么选择一种最合适的表达方式,让大家的沟通更顺畅?
或许有人会说,我觉得大部分UML不需要使用工具画出来。很多时候用白板画一下,大家都理解了,然后就可以擦掉了。
或许还有人说,我们公司做电子商务的,我们一般用到状态图,其他的不怎么用到。
再或者,其实很多公司是为了写UML文档而写UML,UML的作用到底有多大,很多人都持怀疑态度?难道,大家就只是迷恋工具,因为别人UML,所以我也UML?由此认为,一个工具就能搞定所有的疑惑。
这就是撰写本书的初衷,我们需要重新解读UML。也许,需求与UML没有直接关系,但是UML可以专业的表述需求。细细品读一下,为了能够更清新的把握务求,UML其实发挥着十分重要的作用。比如,沟通、记录、启发、存档;理解客户需求,最终形成开发文档。
每 个人对需求的理解方式都不一样。归纳起来,UML只是把大家的理解统一了一种表达形式,有助于相互之间的沟通,便于团队成员之间传递一致的需求,从而达到 需求概念的一致性:需求分析人员使用UML模型与客户沟通,直接明了,同时通过UML模型传递客户需求给设计人员;设计人员使用UML模型描述客户需求, 传递给开发人员;开发人员使用统一的概念和语义理解UML模型,最终使团队各个角色在需求上达到一致的理解。
2 .解决学习UML的困惑
在日常交流中,我们发现,很多程序员有这样的第一感觉:看不懂UML。或者,很多程序员做UML的时候,明明脑子里有一个路线图,可是不知道该用什么图来表达自己的设计意图。还有人会直截了当的提出:有必要把整个系统用UML表达出来吗?
当然,许多项目经理也有自己的困惑。比如,明明自己心里很清楚,可是,当他面对一个新人的时候,却不知道怎么解释系统模型、流程。无形之中,形成了一种交流上的沟壑。
当 我们讨论这些话题的时候,很自然的会延伸到许多概念。比如,模型驱动设计,领域驱动设计。概念越来越多,而我们的脑袋却越来越晕。试想,项目一旦复杂后 UML类图就会复杂化,让人看不懂。一个大型项目里面的类和关系都会很复杂,UML类图会膨胀,有的时候程序需要改动了,UML也要及时更新了。于是,有 人又提出了类似领域边界的概念。如此反复,更多的人也许就会被弄晕了!
其实,UML很简单,就是不要把UML当回事。我们可以尝试以下思路:
l 画UML就像做数学题打草稿,是帮助我们尝试观点,弄清题意的。
l 在表述UML结构时,先从大的概念上进行模块划分,然后再从局部详细处理。
l 把注意力集中到业务上来。这就是说,我们要解决的是问题,但大家总是把注意力集中到解决问题的工具上。当问题被解决后,大家心里有数了,进而可以告之,换个工具可能更好,有什么优点。
在 这样的思路指引下,如果把问题分析清楚,用文字描述也好,用图描述也罢,问题是清楚的。师傅教时,老师教时,课本上讲时,肯定更多的集中在工具如何使用 上,如何用工具来解决问题。当我们达到一个运用自如的境界后,这时我们需要关注的是,我如何如这个工具来解决类似的问题。
按照这个思路,进而去讨论UML,那就是十三种图,常用的几种与不常用的几种,知道各怎么用,表达什么意思也就游刃有余了。
3. UML 中常用的视图
UML 是Unified Modeling Language(统一建模语言)的简称,如果给其一个权威的定义的话,Booche在其经典著作《The Unified Modeling Language User Guide》中这样描述:UML是对软件密集型系统中的制品进行可视化、详述、构造和文档化的语言。此处的制品主要是指软件开发过程中各个阶段的产物,比 如需求用例、源代码、测试用例等。
UML建模机制可以分为静态建模机制和动态建模机制,静态建模机制所建立的模型都是静态的,包括用例 图、类图(包含包)、对象图、组件图和配置图等五个图形;动态建模机制所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活 动图、顺序图和协作图等四个图形。那建立这些图能够起到什么作用,达到什么目的呢?
l 使用模型可以更容易理解问题
l 使用模型可以更好地加强人员之间的沟通
l 使用模型可以更早地发现和纠正错误,甚至规避错误
l 使用模型可以得到需求结果和设计结果
l 使用模型可以使团队新成员更快地融入项目中
l 使用模型可以为源代码留下原型
4.补充一点
UML 本身是个整体,尤其要明白,为什么要有这些图,为什么不是其他图,这些图就够了吗?时序图缺少了哪些信息?而状态机缺少了哪些信息?为什么这些图有机结合 在一起就能很好的刻画一个系统。例如状态机视图是可以有一个完全严格的实现的,相对严格,而时序图则不行。来自一位熟悉的朋友的建议:
(1)状态机的变迁,即最早的状态迁移图,mealy装调剂,more状态机,以及后来的安全状态机等等。为什么会有这些变迁,以及这些不同状态机的差异,和主要应用领域。尤其是清楚状态机应该应用的什么场合。言外之意,就是什么地方不适合状态机。
(2)UML状态机自身的缺陷,然后用面向对象给出一个状态机模式的实现,分析不同实现方法的优缺点。它本身是和面向对象思想是紧密联系的,对比辨析一下,状态机思想和面向对象思想的差异和联系。
(3)状态机的特点是可以有效的降低一个复杂系统的复杂度。很少人能体会到状态机的强大之处,要解释一下状态机为什么会很好的降低问题的复杂度,他对程序架构有和帮助。