※ 引述《huggie (huggie)》之铭言： : ※ 引述《tinlans ( )》之铭言： : : 9. Lack of model clarity : : Pictures are interpretable. I heard this kind of complaints from programmers : : trying to understand the design of a system from UML diagrams: you need to : : read the code to understand what the diagrams mean. : : 会有这种现象一般是人为疏失， : 先声明我不懂 UML， : 我想原作者想要强调的是，并不见得是 UML 本身有很大的技术问题， : 而是 UML 有一定的复杂度，然後它的功能常常被误会。 不是， 是描述得不够精确的话会发生一张图可以有多种解读方式， 譬如 class diagram 里 B 和 C 被 aggregate 到 A， 然後 B 跟 C 之间有一条 association 关系， 那麽假设 runtime 有物件 A1 B1 C1 和 A2 B2 C2， A1 aggregate B1 和 C1， B2 aggregate B2 和 C2， 这时 B 跟 C 之间的 association 关系就至少有两种解读方式， 譬如 B1 associate 到 C2、C1 associate 到 B2， 可是 designer 想表达的却是 B1 associate 到 C1， 以及 B2 associate 到 C2； 如果只有绘制 class diagram， 那麽它在实作或被当文件来了解软体系统时， 就会有类似的岐义现象发生， 这时就需要使用 constraint 或 note， 或是 attach 其它的图， 如合成结构图 (composite structure diagram) 来进一步说明， 因为 class diagram 对描述被包含在内的物件之间的关联性很弱， 所以需要搭配其它的图来加以辅助。 : 这就好像说 SGML 是相好东西，但是太过复杂了所以设计初 XML : XML 还是有人嫌对一般工作太复杂所以有 json， : 并不代表 XML 有 technical 问题.. 这要说明一下了， UML 是以 MOF 为基底， MOF 是所谓的 metametamodel (位於 M3 抽象层)， UML 是所谓的 metamodel (位於 M2 抽象层)， 一般使用 UML 做出来的 model (或 spec) 则是位於 M1 抽象层， application 成品则是 M0 层， 真要拿 SGML 比较的话， MOF 比较接近 SGML 的层级。 比较进阶的 UML 使用者会在 M2 层撰写 profile 扩充 UML， 也就是跟 UML 平行的那一层， 事实上衍生自 MOF 的除了 UML 还有 SysML 跟 SPEM 等等， SPEM 跟 UML 有部分交集， 但图的表示法跟意义会和 UML 有些差异， 它是 Rational 拿来做 business modeling 用的。 : 把程式设计师当成使用产品的顾客，原作者强调的是 UML 不是个好产品， : 而你强调的是 technically 他是个好产品。即使 technically superior : 如果离实际面差太多，大多programmer 心里不愿意花时间来达到应有的程度 : 那就可能有问题。 : 可能角度要从没有不对的顾客来思考。再来思考如何让顾客接受。 UML 被定位在 metamodel， 所以基本上并不会是一个「产品」， 原作者一直认为 UML 一定要搭配昂贵的 tool 使用， 而且几乎认定 UML 就是被设计来做 code gen 用的， 所以可以确定原作者对 UML 的认识并不深。 回到前段， 岐义的问题以 Unified Process (UP) 为例， 它在 Design Model 下就应该被完全消除， 因为在相关技术资料上就记载着： Design model must define enough of the system so it can be implemented unambiguously. 在 UP 规范的 Design Model 里活动的主要 workers (在 RUP 称 roles)， 有 Architect、Use-case engineer 和 Component engineer 三种， 这几种人基本上都不是很 junior 的 engineers， 结果原作者却又说了： 4. Departure from what programmers perceived as the initial goal ... I think most programmers still use only the class diagram and maybe occasionally when they write a document the sequence diagram. ... 只能说他可能完全不知道 UML 实际上必须搭配一套软体工程方法论运行， 而且还把 object modeling 的工作当成一人游戏在玩， 从他整体的言论来看， 他对 UML 的认知可能还只到 UML 1.x， 然而 UML 跟其它 language 一样也是会进化的， 现在用 UML 的人如果只会 class diagram 和 sequence diagram， UML 2.1 里 13 种图只会用 2 种， 如果是很 senior 的 engineers 那实在也太逊了； 当然每个人都曾经逊过是一定的， 但原作者显然对相关方法论的分工方式完全没有涉猎。 我要说的是， 很 senior 的 engineers 如果会犯到他在 9 列出来的错误， 那应该早就被开除了， 如果采用物件导向方法来开发软体的公司， 会让很 junior 的 engineers 去参与 design model 的制订， 那这种公司也早就该倒一倒了。 -- Ling-hua Tseng ([email protected]) Department of Computer Science, National Tsing-Hua University Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: https://it.muds.net/~uranus --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.230.218.232 ※ 编辑: tinlans 来自: 61.230.218.232 (06/05 14:33)