BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

建模语言应该是什么样子?UML又处于何种位置?

| 作者 Sadek Drobi 关注 0 他的粉丝 ,译者 王丽娟 关注 0 他的粉丝 发布于 2008年11月14日. 估计阅读时间: 4 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

根据Steven Kelly和Juha-Pekka Tolvanen所著的《Domain Specific Modeling》一书,Learning Lisp博客的作者Lispy提出了一些对“建模语言应该是什么样子”的想法:

1) 它应该映射到领域问题的概念,而非实现细节。

2) 它必须形式化,不仅要有利于与领域专家之间的沟通,还要能够从模型生成可执行代码、文档和某些测试类,免除实现其它一些测试的需要,并为维护人员提升代码的抽象层次。

3) 它需要有单独的工具支持,能让领域专家“在模型能‘编译’为完全的功能代码的方式下组织框架和库”,而又不需要他们从代码的角度去考虑。为了说明这一点,Lispy拿将C编译为机器代码作为类比,C在某种程度上“对机器代码来说就是一种建模语言”,C程序员不必修改由编译器编译的机器代码,而编译器则由机器语言专家来创建。

因此,要获得真正有用的建模语言,你必须从问题的两个方面来同时考虑“领域特定”:建模语言必须直接映射到问题领域,而生成的代码则必须映射到目标环 境。[……]如果代码生成过程过于复杂,你在框架级别可能需要更好的抽象。如果代码生成过程不可行,那么建模语言可能并没有提供足够详细的需求描述。如果模型中出现太多重复,那就需要扩展建模语言以覆盖更多的概念。

考虑到这些观点,那UML又处于什么位置呢?据作者所说,UML并不是适用于模型驱动开发的工具。UML不能被编译、执行或解释,那它就“只剩文档编制的作用”,而且“对项目来说,除了作为详尽的代码注释外别无他用”。根据Lispy的观点,UML的抽象应用在了“错误的一方”,UML“是设计用来映射到代码架构的——因此UML并不能提升抽象的层次”。

Seven Kelly最近也表达了类似的观点

我一直认为UML对实现的选择约束得更加具体[……]——比如限定在面向对象语言,比如在模型中直接指定了实现中的个别类、属性和方法。[……]UML中能算是高层次抽象的部分只有用例图,而这是在完全失却精确性的情况下。

然而,Franco Civello在他的帖子中对此做出了回应,他认为倘若一个人只使用“UML适用于精准阐释的那些部分”,仍然有可能在模型驱动开发中成功使用UML“在高层次的抽象上表达精准的模型”:

我将给出一个例子来证明我的观点,这个例子使用UML编写精准的模型,而没有实现细节。

[……]产出非正式的用例来阐明需求,以及领域模型来获得对主题范围的初步认识,分析师用UML生成一个精确的规格说明模型,其中要开发的系统被表示为对象,并属于某个类型(注意,不是一个类,因为系统是用来定义可见行为的抽象,而不是用某种语言(比如Java)直接实现的软件实体)。

用例流程中的步骤接着形式化为基于系统类型的操作,并附带有对行为的声明性说明,行为则基于功能契约的概念,而且这些步骤会在底层模型之上(系统类型模型,从领域模型驱动)写成前置条件和后置条件。

Lispy觉得这种做法很有意思,他认为这不一定就与Kelly和Tolvanen在其书中建议的相矛盾。UML用来映射到领域问题,而不用来描述代码架 构,它一定程度上是形式化的,而且正如Franco Civello强调的那样,“UML有一个可执行子集——xUML,并且已经具备了一些工具支持”。

查看英文原文:How a Modeling Language Should Look Like and where UML Stands with Regard to this?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

没错 by 源头 西水

没错,UML不能被编译、执行或解释,那它就“只剩文档编制的作用”,而且“对项目来说,除了作为详尽的代码注释外别无他用”

Re: 没错 by 徐 绪雄

不同意楼上的观点。UML本身就不是为他编译、执行而生,它旨在一个更高层次的交流和沟通,使参与各方都能答成普遍的共识,已降低在实施过程所固有的风险,以提成功的机率。

徐绪雄
Blog: www.vudauk.com
WebSite: www.albrac.com
MSN: xu2xiong@hotmail.com
Email: xu2xiong@gmail.com

Re: 没错 by Guo Xiaogang

不用UML建模也可以

更高层次的交流和沟通,使参与各方都能达成普遍的共识,以降低在实施过程所固有的风险,以提成功的机率

作为一种不能执行的Spec,从需求转成UML,再从UML转成代码,无端多了两个处理步骤,用精益的话来说,就是多了两个inventory,浪费得很。

Re: 没错 by 徐 绪雄

从需求直接到代码好象是很顺理成章的事情,多个两个inventory也好象是的确是有些浪费。
现在我们再回到需求,是对其类型化,还是特例化,完成取决于设计人员对其抽象的程度,好了,现在我们用UML对其建模,得到结果也会有本质上的区别(是思想交流的利器,还是只是代码的注释:思想可以在不同项目、团队中发扬光大,注释仅限于代码)。

徐绪雄
Blog: www.vudauk.com
MSN: xu2xiong@hotmail.com
Email: xu2xiong@gmail.com

交流用吧 by lei zhao

交流用吧

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

5 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT