浅论阴阳太极和UML建模.docVIP

浅论阴阳太极和UML建模 　　UML抽象、简洁、高于Java、C++ 诸等高级程序设计语言之上的形象表达，可以让我们真切领略到蕴藏于软件那纷繁芜杂的细节表面之后的一份简单、和谐之美。 　　 　　软件究竟是什么？有很多比喻可以形容。静态的软件就像一座虚拟的建筑（Architecture），而运动时的软件有时就像一部开动的虚拟机器，或多条柔性的工厂流水线（进程与线程），有时又像一种虚拟的生物，可以肆意的复制和生长（比如软件病毒）。 　　过去有一种说法认为:程序 = 算法 + 数据结构，如今看来这种旧结构化时代的观点是不准确、不全面的，在新结构化时代我们至少可以得出这样大致的公式:程序 = 算法 + 软件结构 + 数据结构，在这里我们强调软件结构不同于数据结构，软件是操纵数据的程序，而软件结构（包括架构和设计模式）的质量对软件的质量同样具有决定性的影响。 　　过去这15年无疑是面向对象（OO）软件的天下，世界软件开发早已进入了OO时代。 　　人们知道，高质量的好软件是设计出来的，而软件的设计目前依然主要依赖于人们大脑的思考和判断，人类大脑的思考过程恰是一个对现实世界以及虚拟世界建模的过程。 　　而作为OO建模技术的事实上工业标准，统一建模语言（UML）正好为我们提供了一个运用OO思维进行软件建模和设计的工具。 　　UML 1.4.2成为正式国际标准ISO/IEC 19501是软件设计史上的一个重要事件，UML标准成熟之后的研发进展也比较顺利，当前最新版本为2.1。 　　UML有什么用？作为一种建模“语言”，促进沟通是一项基本功能，然而很多人忽视了UML独立于传统具象编程语言、擅长表达抽象OO概念的一大特点。 　　事实上，熟练掌握UML能够帮助我们的大脑学会快速、敏捷地运用OO方式进行思考。UML标准及其相关技术不但是近10年来各工程领域OO软件设计与建模的利器，还是当前表达软件设计模式最形象和最有效的工具。 　　在我看来，学会运用UML思考，抽象地用UML表达软件架构和设计方案，从而能透过现象看本质，是当今任何一名软件架构师乃至普通OO程序员都应该尽快掌握的基本功。所以，这几年世界各地的大专院校纷纷把OOAD/UML列为一门软件工程专业的必修课也在情理之中了。 　　建模（modeling）并不是软件行业所特有的做法，建模几乎是几千年来人类所有工程行业所共有的一项最佳实践。为什么我们要对软件建模？因为软件太复杂，难以理解和掌握，我们需要一种能够简单而深刻地反映软件设计本质的方法和工具。如何建模？就像对待建筑模型、机械模型一样，软件也是一个多面体（虚拟的），我们也需要选择视点、视角和视图，对模型做投影、做切片。Kruchten 博士提出的著名的 4+1 视图（逻辑视图、实现视图、构件视图和进程视图，再加上用例视图）为我们利用UML对复杂软件的结构和行为建模提供了很好的指导。 　　软件设计和UML建模既然那么重要，有什么简单易学、提纲携领的好方法、好原则吗？我曾经编写了一首建模口诀，多次在讲课咨询时与客户、学员们分享交流，取得了很好的效果。 　　这首太极建模诗（或叫十六字OO建模口诀）受到了Larman（《UML和模式应用》）、Cockburn（《编写有效用例》）、3 Amigos（《UML用户指南》）等世界级专家们睿智大作的启发，也凝结了我10多年来从事OO设计和编程的一点小小感悟。 　　我发现“外与内，高与低，静与动，粗与细”等基本二元辩证关系，不但适用于软件用例需求的建模，也适用于软件架构的OOAD/UML 建模。 　　 　　当然，软件设计中的二元关系还远不止这些。充满了二元辩证、平衡之道的现代软件工程，竟然与两千年前中国古典哲学《阴阳太极》中的黑、白对立统一相暗合，这真的是历史的巧合，还是科学的必然？ 　　 　　由外而内 　　外与内，即软件系统本身与其外部环境的关系，大概是软件开发中最根本的一对关系。在软件开发之初需求调研时，我们通常视整个软件系统为一个黑盒子，我们划地为界，从系统外部来观察软件提供给其各个用户的功能，以及它与外部环境的各种动态关系（包括彼此之间的行为交互和信息数据的交换）。这种方法可以用UML用例图表示如下: 　　以银行证券帐户管理系统（类似于“银证通”）为例，图中用例“打印帐户报告!”的需求简述是: 　　主用角:用户 　　辅用角:外汇交易中心、证券交易所 　　范围:证券账户管理系统 　　层次:用户目标层 　　后置条件:系统打印客户帐号下已购买的所有币种的证券清单，包括每支证券的单价、份数、余额以及该客户账户下的资产总额（转换成用户指定的币种，缺省情况下为美元）。 　　前置条件:用户已登录，客户的账户、帐号已知。 　　触发事件:用户选择打印账户报告（证券余