领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
建模语言应该是什么样子？UML又处于何种位置？
作者 Sadek Drobi 译者 王丽娟 发布于 2008年11月13日
根据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并不能提升抽象的层次”。
我一直认为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?
译者 王丽娟 王丽娟，04年大学毕业后持续从事Java EE中间件产品的开发，现在主要关注Java技术及中间件产品在云计算环境中的发展趋势和应用。
没错
发表人
源头 西水
发表于
Re: 没错
发表人
徐 绪雄
发表于
Re: 没错
发表人
Guo Xiaogang
发表于
Re: 没错
发表人
徐 绪雄
发表于
交流用吧
发表人
lei zhao
发表于
-
没错，UML不能被编译、执行或解释，那它就“只剩文档编制的作用”，而且“对项目来说，除了作为详尽的代码注释外别无他用”
-
不同意楼上的观点。UML本身就不是为他编译、执行而生，它旨在一个更高层次的交流和沟通，使参与各方都能答成普遍的共识，已降低在实施过程所固有的风险，以提成功的机率。
徐绪雄
Blog: www.vudauk.com
WebSite: www.albrac.com
MSN: xu2xiong@hotmail.com
Email: xu2xiong@gmail.com -
不用UML建模也可以
更高层次的交流和沟通，使参与各方都能达成普遍的共识，以降低在实施过程所固有的风险，以提成功的机率
作为一种不能执行的Spec，从需求转成UML，再从UML转成代码，无端多了两个处理步骤，用精益的话来说，就是多了两个inventory，浪费得很。 -
从需求直接到代码好象是很顺理成章的事情，多个两个inventory也好象是的确是有些浪费。
现在我们再回到需求，是对其类型化，还是特例化，完成取决于设计人员对其抽象的程度，好了，现在我们用UML对其建模，得到结果也会有本质上的区别（是思想交流的利器，还是只是代码的注释：思想可以在不同项目、团队中发扬光大，注释仅限于代码）。
徐绪雄
Blog: www.vudauk.com
MSN: xu2xiong@hotmail.com
Email: xu2xiong@gmail.com -
交流用吧
5 条回复
关注此讨论 回复