|
当今对象导向开发的世界中第二条大新闻是什么？那就是『统一模塑语言』(Unified Modeling Language; UML)其不仅获得对象管理小组(Object Management Group; OMG)所承认也将取代 BoochCoadJacobsonOdellRumbaughWirfsBrock 等分析及设计方法原先所使用的表示法成为全新唯一的表示法此举将终结软件开发人员究竟要使用那些方法这类令人生厌的争议我们将进入和睦友爱及提升生产力的新时期(就算那些旧架构的方法已经相当成熟了却从未达到这样的水平 对此也只能一笑置之) 假如你是 BS (before standardization 标准化之前)方法之一的方法迷(keen user)你钻研(bite the bullet)转换至 UML 时不免暗地抱怨没有看到你所喜爱方法中的 x 特性而你所不喜欢的 y 及 z 特性却充塞其中但是你是否真的冷静下来思考像 UML 这样的塑模表示法为何是有用的吗？ 询问一位方法论大师(methodologist 在我们业界指的是创造方法论的人)有关这方面的看法时会招致一顿软件质量如何如何的严厉训斥方法论大师会谈论到我们的产业遭受到怎样的危机缺乏软件质量所遭致的问题良好设计的重要性 等等这样也好(虽然我想软件产业在最近几十年已经做得很好了)但是如何确实地实施 UML 才是有帮助的？询问 CASE 工具厂商时你将会上一堂课是有关改善质量文件自动化及程序代码产生器的生产值然而我们大家都知道CASE 工具厂商接下来的动作会是什么 假如你是一位开发人员质疑所有方法的本质不过是另类的管理流行时尚你一想起会产生毫无用处的纸张就感到战栗然后 UML 恰好佯装成关怀这类问题而成为另一种表示法(notation)至少这是目前仅有的可是你也了解下次你必须更改系统时在你必须修护程序代码往后的几个版本这些 UML 图还是有所帮助的 我早在软件职业生涯中学会方法既使我具有工程的背景然而这些方法似乎成为一种天然的知识领域这般的吸引着我大多数的工程科系采用绘图来描述如何建构事物同时相当用心的 根据这份设计图来做这些事物我明白方法论的图型也具相同功效有段时间我学习类似的方式(the lie of that analogy)然而我仍旧发现这些方法是有用的尽管我对于某些开发人员不喜欢这些方法深表同情 接着下来我要说明为何我发现 UML 是有用的首先我快速的提醒各位 UML 『是一种塑模语言而非方法(或方法论)』同时以此作为下面论述的开始UML 订定了一些图型以及这些图型的意涵而方法则更进一步描述开发软件的步骤什么样的图型在什么顺序中产生由谁来做那些工作 等支持 UML 的方法是各自独立的过了明年或明后年我们将看到不同人士提供各种运用 UML 表示法的方法然而你不须要使用方法才会利用 UML在这篇文章里我不去假定任何特定的开发方法 因此如果我们除去所有方法的装饰除了少数你能够绘制的图型样式外被留下来的还有什么？这个问题从「UML 有什么用途？」变成了「这些图型有什么用？」 答案可以归结成一词『沟通』(译注英文是一字communication)这是一个重要的词汇软件如此地迷惘 以致于难以开发的原因主要就在于沟通我们知道假若我们只要在周末偷闲一下而程序代码就此消失事情将是如何简单困难的症结在于我们必须与多位开发人员沟通UML 之所以重要就是因为它有助于软件开发人员之间的沟通我们必须在某种程度上使用它以协助沟通而非阻碍沟通 图解 UML 图型用以展示 Java AWT Container 类别的 Container 图解 说明了 UML 如何协助沟通的范例此图型一开始是用来描述 Java 抽象窗口工具集(Javas Abstract Windowing Toolkit; AWT)的容器类别(Container class)透过阅读这个图型我能够了解一大堆东西我能够了解容器(Container)是组件(Component)的子型态(subtype)可以把组件制作成可视的(visible)或主动的(active)以及其它类型的组件这些组件包括卷标(labels)按钮(buttons)以及其它种种我可以询问一个容器有关它所包容的组件但是并非所有的组件都需要容器容器(Containers)包含组件(Components)容器(Containers)也可能包含其它容器(Containers)同时容器拥有一个布置管理者(layout manager)容器就如同组件般属于抽象类别(abstract class)其子型态包含画板(panels)及窗口(windows)窗口能够显示及处置窗口本身窗口也有框架(frame)及对话框(dialog)两种子类别(subclasses)两者皆有标题列同时能够设定其大小是否可以变更(resize)虽然窗口的两种子类别都可以做上述的事然而这些行为并非窗口本身的一部分可以将对话框(Dialogs)标示为模块式(modal)然而框架(frames)却不可以 你可能喜欢这个图型也有可能喜欢我前面那段论述这端赖你是否熟悉 UML以及你是喜欢可视化的叙述或者喜欢叙事式的陈述关于此我喜欢可视化然而有些人喜欢文字方式即使他们也懂得这些图型你可以给他们文字描述或者(或许会更好)给他们一段程序代码选集(如列表 所示)那一个是你愿意选择的？那一个是你的同僚所想要的？这些问题对于 UML 及类似语言的角色是至关紧要的我发现有些人喜欢文字的方式有些人喜欢图型的方式还有某些人在某些事物上选择图型同时在某些事物上选择文字最后图型仅有在可以强化沟通的情况下才值得去做 除了注意那些图型展示甚么之外你也该注意到那些图型不能够展示甚么类别整体描述有较图解 或列表 所标示的接口更大我未曾提到布置管理者(Layout Manager)是一个接口或者那个组件实作若干接口许多人可能会因此而责难图解 不够完整它是不完整但不完整是一种缺点吗？在图型里我决定去描写那些类别的特性并且慎重的决定那些不该显示出来事实上我所显示出来的某些特性就是我所要突显出来的特性 选择所要强调的信息是沟通很重要的一环在类别的任一群体中为了取得这些类别最初的理解去了解某些观点(aspects)是相当重要的假如你展示每件事你会失去引出那些特点同时你的读者会对于首要了解的事物以及往后才须专注的细枝末节毫无概念当我使用类别图我是为了最初的理解而利用它们以便于了解我想表达这些类别的关键观点我知道读者经常是从 Javadoc 档案中去取得这些接口完整的叙述 我鼓励你以这种有选择性的方式来使用类别图这样做不仅可以促进图型沟通的价值也可以使它们容易维护(keep up to date)你无须为了类别每一个小改变就变更图型既然难以维护这些各式各样的图型为重大的问题之一这种做法就有相当大的好处 就像鼓励有选择性一般我也鼓励人们去强调接口(interface)而非实作我在组件上显示一个 isEnabled 的属性(attribute)这不是说组件类别有一个数据域位(field)称为 isEnabled (我真的没有注意到因为它无关紧要)其所表达的意思是你可以假设这个类别有这样的属性然而你要从类别外部透过适当的操作(operations)来存取内部的数据理论下可能有这些操作的命名约定(在 Java 链接库的这些日子命名的方式为 isBooleanAttribute 及 setBooleanAttribute)我不显示类别的操作因为我发现属性的表示方式 更能适当地传达程序代码的意图属性也可延伸至结合关系(associations)我不知道容器(Container)及组件(Component)之间存在那些数据结构这些操作会使人联想到这些结合关系 许多人士以实作的观点来绘制类别图即是将属性(attributes)及结合关系(associations)反映至数据结构中这些数据结构之所以有用乃在于你期望表达甚么无论如何通常 这些接口那些是最重要的你该决定甚么是你所根据的观点甚么是你想要表达的 当讨论到某一件设计还有你可能如何去变更它时我发现图型也是有用的 假如你拥有一群设计师正致力于一项设计尝试在白板上绘制设计的草图描绘几个替代方案我发现我们在探讨有关事物时可视化是很有效的办法(CRC 卡是另外一种有效的技术) 这项技术有一点特别重要的变化是发生在当我正与领域专家合作尝试去了解我们所要建构的系统时在这种情况下我使用最少的表示法并且聚精会神于领域专家脑中所描述的概念而不是思考任何特定的软件情况我发现教导这种概念上的塑模风格对于没有软件背景的人士是相当容易的 接下来使用这些图型 我们能够共同地发展出一套定义正确的字汇用于讨论领域相关事项同时能够提出对于讨论及目的软件皆有益的抽象概念当我从事于如保健及金融贸易这类复杂的领域时这对我而言是一大恩惠 统一规格在此是有用的乃因其可加强沟通的质量当他们使用各种图型式样(diagramming styles)与人沟通时这种思想交流是困难的拥有一个单一的标准我们可以确认假使人们懂得少许图型式样的话他们一定懂得标准化的图型但是不要走过头了UML 包含许多表示法并且没有规定说你全部都必须用到尝试着运用这些表示法中适当地少量的部分不要使用进阶的概念除非它们确有必要虽然你应该尽你所能去忠于标准然我必须承认如果需要的话我并不害怕去篡改表示法我不这样做的原因通常是每次篡改表示法就需要对此作说明同时不是读者所熟悉的但是若这么做能加强沟通我就去做它 所以如果你是 UML 的新手根据你所需传达的想法去尝试使用它实验可以了解那些可以做以及那些不可以做 透过实作去学习表示法并且逐步地学习 |
