聚焦UML实践第一步

 
  •  

           我独不解中国人何以于旧状况那么心平气和;于较新的机运就这么疾首蹙额;于已成之局那么委曲求全;于初兴之事就这么求全责备?

                                                                                                                                                                                 ----鲁迅

    引子

           前段时间和一个朋友在MSN上聊到UML,他一声叹息:“知道UML是好东西但是用不起来。尝试过,结果领导要求文档中要充分使用UML,事无巨细皆UML,结果本来很简单的一份设计文档加了一堆图。评审的时候团队还有牛人指出UML图中这里的菱形应该是实心的,那里的要用半个箭头… …结果开会大部分时间都在炒图怎么画。领导觉得这也没带来什么好处,同事们乐得摆脱,后来就不了了之了”

         然后顺便抱怨了我一下: “你给我推荐的《UML Distilled》也不怎么样… …

         这个抱怨让我很恼火,断定他看得是中文版,果然!我毅然用货到付款的方式为他定了一本英文影印版《UML Distilled.问题还要解决故有此文.

         

    1. 为什么要用UML
    2. 定位:怎么用UML
    3. UML规范=束缚?
    4. UML第一步

      

    为什么要用UML

            1970年以前,软件开发人员把软件开发工作比作探险活动,但是由于系统日趋复杂,个人英雄主义的时代在软件危机的爆发中宣告终结。危机引出了工程化方法,并催生了各种图形符号工具。面向对象理论出现之后,相关设计方法层出不穷,存在多种设计格式。

            多种设计格式带来交流的不便,沟通的障碍,一个统一的建模语言需求已经是迫在眉睫。所以可以这样讲,UML的意义不在于它提供的内容而在于它的规范性和统一性。为了得到更好的设计我们需要更好的沟通,更好的沟通需要基于共同的语言进行,方便沟通这是创建UML的初衷,也是应该是使用UML最佳理由。后面的论述中希望你不要忘记了我们最初是为什么而出发的.

          

           UML还继承了图形建模语言(graphical modeling language )的优良传统:高屋建瓴的抽象能力。而普通的编程语言恰恰缺乏这种描述设计思想的能力:"The fundamental driver behind them all is that programming languages are not at a high enough level of abstraction to facilitate discussions about design."抽象化主要是为了使复杂度降低,以得到论域中较简单的概念,好让人们能够控制其过程或以综观的角度来了解许多特定的事态。抽象过程必然包含舍弃的细枝末节,是一个裁剪的过程。抽象的结果,决定于从什么角度上来抽象抽象的角度取决于分析问题的目的。

          关于视角,UML Distilled》有一段精彩的三层视角的论述,这段文字被无数设计模式、领域建模的书引了又引,比如《Design Patterns Explained》。《视角的力量--再说OO设计原则 》一文中我曾经探讨过下面的三个问题:1.为什么我们过早的纠缠于细节?问题的本质是什么?2.救命稻草--Martin Fowler的三层视角理论3.三层视角--回头再说OO设计原则文中的最后我完整引用了作者三层视角的论述,我是把它作为走出思维泥沼的明灯来看的。这里不再赘述,详情请查看:源文档 <http://www.cnblogs.com/me-sa/archive/2008/04/15/ooview.html>在第三版中,作者对视角的观点做了修正:规约视角和实现视角之间的界限是很难划分清楚的.实践过程中发现也没有做这种界限的划分的必要.

     

    定位:怎么使用UML

            "黑夜给了我黑色的眼睛,我却用它寻找光明."同样一件东西怎么用确是不一定的,对于UML怎么使用也要有一个定位。Martin Fowler先生给出了三种使用使用UML的方式:蓝图blueprints 骨架 sketches,编程语言。

            三种使用方式比较容易区分出来的是:作为编程语言使用.ExecutedUML对工具的要求是非常高的-需要处理代码和图的同步问题等等.这里不做展开讨论,大家可以到国家文献中心找到更多相关资料:

    源文档 <http://s.wanfangdata.com.cn/paper.aspx?q=executed%20UML&n=10&f=top> UML作为编程语言,典型应用时MDA.UMLMDA的事实标准,占领了90%的市场份额.MDA 的愿景是定义一种描述和创建系统的新的途径。MDA 使得UML 的用途走得更远,而不仅仅是美丽的图画。很多专家预言MDA 有可能会带领我们进入软件开发的另一个黄金时代"

    Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.

    源文档 <http://en.wikipedia.org/wiki/Model-driven_architecture>

     

    Executable UML,often abbreviated to xtUML or xUML , is the evolution of the Shlaer-Mellor method[3] to UML. Executable UML graphically specifies a system using a profile of the UML. The models are testable, and can be compiled into a less abstract programming language to target a specific implementation.Executable UML supports MDA through specification of platform-independent models, and the compilation of the platform-independent models into platform-specific models. 

    源文档 <http://en.wikipedia.org/wiki/Executable_UML>

     

           难以区分的是蓝图blueprints 骨架 sketches,从中文说文解字的角度我们无法获得一个满意的答案.按照Martin Fowler先生的论述我将二者的区别通过表格的形式列了出来,通过比较还是能看出各中端倪的:

     

        Mode

    Essence

    Forward engineering

    Reverse engineering

    Tools

    Practice

    Sketch

    selectivity

    communicate ideas and alternatives

     

     

    explain how some part of a system works

    lightweight drawing tools

    To help communicate some aspects of a system.

    Do it quickly and collaboratively, so a common medium is a whiteboard.

    Blueprint

    completeness

    detailed design for a programmer to code up

    convey detailed information about the code

    CASE Tools

    (much more sophisticated )

    Reducing programming to a simple and fairly mechanical activity

     

    从上面的比较中可以看出sketches勾勒重点,蓝图blueprints注重完整性,无微不至.前者是一种探索性的explorative,后者是定义性的definitive。对于后者,一旦蓝图确定,编码工作基本上就没有什么创造性了.

     

    UML规范=束缚?

          谈到UML就不难以避开UML规范的话题.多年来学习编程语言的习惯,语言规格说明是必经之路,金科玉律一般.但是UML规范怎么在实践中怎么就成为了束缚了呢?

    1. UML 规范和c#语言规范不同的是:混乱的c#代码可能直接无法通过编译,但是不符合的UML规范的应用却没有那样显示的错误提示
    2. UML1.02.0版本之间就有差异,在新版本中很多规范都是指导性的。”指导性“反而让我们难以抉择。
    3. 有时候你按照规范来做了,但是却大家却不习惯

        大师们是怎么给我们建议的呢?

    1. 习惯用法优于规范
    2. 为了更好的表达你的意图,时刻准备着违反规范
    3. 只要合适,可以引入非UML图表,不要犹豫

         Okay,甩掉包袱,我们可以轻装上阵了.  

     

    UML第一步,怎么开始?从哪里开始?

           怎么走出UML应用的第一步呢?像我的朋友遇到的情况先把UML规格说明熟读么?然后发誓把UML各种图表能用的全用上么?

        请注意这里有如下事实:

    • 你已经忘记了目的地,使用UML的目的是更好的沟通,而不是充分使用UML的各种图
    •  即使是UML的发明者们也不能熟练使用UML所有的图,人们需要的往往是一个很小的集合
    • 人们买来电器之后第一件事是全面学习使用手册么?不是,基本规则会了就先用起来,不会的时候再去找,这个就是行动思维

         我们就释然了,没有必要使用所有的图,更没有必要熟悉所有的UML规格说明,不应成为负担。归根究底,成为负担的是对我们没用的东西,铭记奥卡姆剃刀原则Occam's Razor:如无必要,勿增实体,大胆的舍弃对自己没有的东西!

          从哪里开始?Martin先生给出的建议是从类图和序列图开始,这两种图是基本的,常用的,最有用的图形。掌握了这两种图之后,可以尝试其它图,如果新的图没有给你带来什么帮助,大胆的舍弃它!

     

    然后呢?Ok,我们行动吧!

        

     

     

参考书目:

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值