• 大话UML


    作者:

    张传波

    软件知识原创基地 首席专家

    www.umlonline.cn

     

    UML的信任危机

    有一次我在做这个课程培训时,有位同学跟我说,他曾经听过不少UML培训,以为UML培训就是这个样子,没想到我的课程让他大开眼界,重新认识了UML!他对课程的赞美让我非常高兴,但目前业内UML面临着比较普遍的信任危机,批评UML、认为UML用处不大的文章随处可见,这让我十分担忧。

    我读书时从来没有听说过UML这回事,仅是在工作后才开始学习。很多书籍将UML讲得过于复杂、过于理论化,其实完全没有必要,学以致用才是学习的最终目的。在实际工作中我不断地体会UML的魅力,逐步形成了自己的一套理解,我在大量的项目中使用UML了,并且将我的经验传授给同事。UML在很多公司没有能用好,在业内有严重的信任危机,我觉得是以下的原因导致的:

    原因一:合适的UML学习资料不多。
    市面上的资料、书籍主要是两类,一类是国外骨灰级高手写的,一类是国内的UML理论家写的。
    国外高手的书籍,很多写得过于高深抽象,又加上翻译后影响了原意,这些书籍一般都难以让我们理解。
    国内理论家写的书籍,内容确实很丰富,部分书让人读了还会觉得很兴奋,问题是没有能处于“学以致用”的目标来编写,我甚至怀疑有些作者基本上没有实际在项目中使用UML的经验。
    UML大师 Martin Fowler 编著的《UML Distilled》(中文译名:UML精炼),我觉得是难得的一本UML好书,推荐大家阅读。

    原因二:有实战经验的UML讲师太少。
    不少UML讲师是来自某某大学、学院或者是研究所的,很少见到来自企业的。如果不能处于实战的角度讲授UML,UML的威力就会大打折扣,这样的培训训练出来的学生,实战水平不会得到很大提升。

    原因三:对学习UML普遍存在严重误解。
    我觉得学习UML最难的应该是转变思维习惯、提升思维水平,而不是UML的语法。UML中的每种符号,都有很特定的含义,你需要在实际案例中去体会,而不是只听理论讲解。不要指望学习了UML你就会马上提高了一个档次,如果你的思维方法不得到提升,你只是UML理论家,你可能不学UML会更好,这些UML理论反而会在实际工作中限制你的发挥。

    UML知识超级扫盲

    UML这三个字母的全称乃Unified Modeling Language,直接翻译就是统一建模语言,简单地说就是一种有特殊用途的语言。你可能会说,语什么言,一堆图形,还说是语言?此言差矣,咱们的文字还不是从图形(象形文字)开始的嘛,语言是包括文字和图形的。其实有很多内容文字是无法表达的,你见过建筑设计图纸吗?里面还不是很多图形,光用文字能表达清楚建筑设计吗?在建筑界,有一套标准来描述设计,同样道理,在软件开发界,我们也需要一套标准来帮助我们做好软件开发的工作。UML就是其中的一种标准,注意这可不是唯一标准,只是UML是大家比较推崇的一种标准而已,说不定以后有一个更好的标准可能会取代她呢!UML并不是官方的标准,也没有法律规定你在软件开发中一定要用UML,不能用其它的,我们的目标就是善用包括UML在内的各种标准,来提高我们软件开发的水平。

    UML由1.0版发展到1.1、1.2、...,到现在的2.0、2.x,本论坛将会以2.0版本为基础开展讨论。网络上、书籍、还有各种UML工具软件,各自基于的UML版本可能会不一样,大家在学习过程中可能会有一些困惑,不过没关系,本课程在某些关键地方会描述1.x与2.0的差异的。

    UML有很多种图,大体可以分为两类:
    1.结构型的图(Structure Diagram)
    类图(Class Diagram)
    对象图(Object Diagram)
    组件图(Component Diagram)
    部署图(Deployment Diagram)
    包图(Package Diagram)
    2.行为型的图(Behavior Diagram)
    活动图(Activity Diagram)
    用例图(Use Case Diagram)
    状态机图(State Machine Diagram)
    序列图(Sequence Diagram)
    协作图(Communication Diagram)
    时序图(Timing Diagram)

    注:UML图的中文名字,因为翻译的原因可能会有所不一样,大家要留意看英文名字噢!

    在我们软件设计时,我们需要考虑需要那些类、哪些组件、系统最后怎样部署等,这些内容可以看成是“静态”的,我们可以利用UML的结构型的图来设计。
    同时,我们也需要考虑软件如何和用户交互,类、组件、模块之间如何联系等“动态”内容,我们可以利用行为型的图来设计。
    当然所谓“静态”和“动态”不是绝对的,对UML还不是很熟悉的朋友,先大致这样了解便可。

    下面谈谈一些UML的常见认识误区:

    1)UML只适合用来做软件设计?
    UML可以用来做软件设计,这是大家的普遍认识,实际上不仅如此,UML还可以用来做需求开发(或者叫需求分析)。不仅是用例图可以用来描述需求,类图、活动图、序列图、状态机图等都可以用来深入发掘和整理需求。

    2)UML的语法很多很繁杂?
    UML的全部语法确实很多很繁杂,但实际上经常用到的内容不多,也很容易记忆。

    3)掌握了UML语法,就是OO高手了?
    要成为OO高手哪有这么容易啊!OO理论家就很多,真正实战高手其实没几个。我未懂UML之前,还自认为自己OO水平还不错,学习UML后发现自己是如何之渺小。通过实际工作不断地应用UML,不断地思考总结,才能不断地提高自己的OO水平。
    如果不懂UML,有可能是OO高手吗?我一直也有思考这个问题,我觉得不懂UML的不太可能是OO高手,因为确实只有用好UML(特别是类图)才能真正体会到什么是OO!

    4)光用UML就足够了吗?
    UML可以表达软件设计的所有情况吗?用了UML就不需要用文字来表达设计吗?
    非也非也!UML在表达界面设计、用户体验设计、数据库设计等方面,能力还是很弱的,不要只用UML,应该善用一切可以利用的东西,包括文字。

    UML的秘密

    很多资料将UML说得太复杂了,事实上我们需要经常用到的部分并不复杂。很多资料会将大家误导到不常用的那部分,浪费大家宝贵时间,我们应该集中火力去学好那常用部分。

    学UML之难,不在于学习语法,关键是要改变思维习惯。UML是一种新的工具,但同时也是代表了一种新的先进的思考方法,如果不能掌握这样的方法,只能学到了UML的形,而没有掌握其神髓。要真正能用好UML,你需要:
    1.头脑要清晰(如果你精神不好,就先休息一下,养足精神再来。)
    2.抽象能力要强(这句话说得太好了,但太抽象了,呵呵!没关系,后面课程会有很多例子让你体会什么是抽象能力。)
    3.归纳总结能力要强(下面马上就有一个挑战你的归纳总结能力的测试。)
    4.需要有“面向对象”的思维习惯(类图将特别强调这点,后面课程你将体会到什么是“面向对象”。)

    如果你的思维习惯没有被“革新”,那么学习UML是失败的,能力切实的提高往往不只是你学到了哪些知识,而是你的思考方式的提升,这才是真正的质的改变!

    对于UML学习,你必须先端正一些认识:
    1.UML只是一种武器,能不能用好UML不是看武器本身,而是看用的人的功力!
    2.不用UML也能写好需求和设计的人,如果掌握了UML,他写出来的文档质量将更高!
    3.用UML写不出好文档的人,就算不用UML也很难写出好文档!

    ---全文完---

  • 相关阅读:
    hibernate理解
    struts理解
    网上书城项目
    编码过程中遇到的问题
    JS回调函数
    requirejs 一个拆分js项目的类库
    jq插件开发总结
    转载-- 魔兽哈希算法封装和测试
    转载--C# PLINQ 内存列表查询优化历程
    Oracle删除死锁进程的方法
  • 原文地址:https://www.cnblogs.com/umlonline/p/1686589.html
Copyright © 2020-2023  润新知