可视化建模1[图]

为了成功地开发一个项目，你需要正确的过程、工具和符号（注释）。在本文中作者解释了UML是如何为你提供符号、Rational统一流程（Unified Process）是如何为你提供正确的流程，以及Rational Rose是如何为你提供使项目成功的工具的。

　　什么是可视化建模？

　　可视化建模（VISUAL MODELING）是利用围绕现实想法组织模型的一种思考问题的方法。模型对于了解问题、与项目相关的每个人（客户、行业专家、分析师、设计者等）沟通、模仿企业流程、准备文档、设计程序和数据库来说都是有用的。建模促进了对需求的更好的理解、更清晰的设计、更加容易维护的系统。

　　模型通过过虑非本质的细节信息，成为描述复杂的问题或结构的本质的抽象（abstraction），她使问题更容易理解了。抽象是一种允许我们处理复杂问题的基本能力。千百年以来，工程师、艺术家和工匠一直在实施某项工程之前，先建立模型提炼出它的设计方案。软件系统的开发也并不例外。为了建立复杂的系统，开发者必须抽象出系统的不同的视图，使用精确的符号建立模型，验证这些模型是否满足系统的需求，并逐渐添加细节信息把这些模型转变为实现（implementation）。

　　我们建立复杂系统的模型是因为我们没法理解整个系统。人类理解复杂性的能力是有限的。这个观念可以在世界上的建筑中看到。如果你希望在后院中建立小屋，你可以立即开始建造；如果你希望建立新房子，你就可能需要一张蓝图了；如果你要建立摩天大楼，你就绝对需要一张蓝图。在软件的世界中这也是一样的。由源代码行或Visual Basic中设计的窗体担任主角为程序员提供的开发项目的全局视图是很微不足道的。构造模型允许设计师集中考虑项目中的组成部分如何交互的全局情况，而不会陷入每个组成部分的具体细节信息的泥沼中。

　　高度竞争的和不断改变的业务环境导致了复杂性不断增加，这为系统开发者带来了独特的挑战。模型帮助我们组织、形象化、理解和建立复杂的事物。它们在目前和未来都会帮助我们解决开发软件遭遇的各种挑战。

　　成功三角形

　　我经常使用图1所示的成功三角形来解释成功的项目所需要的组成部分。你需要所有的三个方面——符号、过程和工具。你可以学习一种符号，但是如果不知道如何利用它（过程），你可能会失败。你可能拥有强大的过程，但是如果不能沟通这些过程（符号），你也可能失败。最后，如果你不能记载自己的工作文档（工具），你也可能失败。


图1.成功三角形

　　符号的角色

　　符号在任何模型中都扮演着重要的部分——它是把过程连接在一起的“粘合剂”。符号有三种角色：

　　· 它作为传达决定的语言服务的，它不能明显地或者不能从代码自身中推理得到。

　　· 它提供的语义学对于捕捉所有重要的战略和战术决定都是足够丰富的。

　　· 它提供了一种具体的形式，足以供人们来思考和工具来操作。

　　统一的建模语言（UML）提供了非常健全的符号，它从分析的范围发展到了设计的范围了。一定的符号元素（例如类、联系、集合体、继承）都是在分析中引入的。其它的符号元素（例如保留实现的标识和属性）都是在设计中引入的。

　UML的历史

　　在九十年代很多不同的方法学和它们的符号集都被引入市场中。其中最流行的三个是OMT（Rumbaugh）、Booch和OOSE (Jacobson)。每种方法都有自己的价值和重点。OMT在分析方面强大，但是在设计方面比较弱。Booch 1991在设计方面强大但是在分析方面比较弱。Jacobson在行为分析方面强大，但是在其它方面比较弱。

　　随着时间的推移，Booch写了他的第二本书，除了别的内容以外，他还采用了大量的Rumbaugh和 Jacobson提倡的好的分析技术。Rumbaugh出版了一系列文章，形成了我们所知道的OMT-2，它采用了Booch的大量的好的设计技术。这三种技术开始聚合在一起，但是各自仍然有自己独特的符号。由于符号对不同的人的意味着不同的事物，所以不同的符号的使用给市场带来了混乱。例如满圆形（filled circle）在OMT中是多样性标志，在Booch中却是集合标志。你可能听到过用术语“方法的战争”来描述这段时间——类到底是云形还是长方形的？哪个更好？

　　当符号都采用了统一的建模语言（UML）的时候“方法的战争”才结束了。“UML是一种用于具体说明、形象化、并记载开发中的面向对象系统的工作的语言。它表现了Booch、OMT和对象符号，以及大量的其它方法学（图2）的最佳观念的统一。通过统一这些面向对象方法使用的符号，统一的建模语言为基于广泛的用户经验基础形成的面向对象分析和设计领域中的事实上的标准提供了基础。”

　　UML试图标准化分析和设计的工作：语义模型（semantic models）、语法符号（syntactic notation）和图表（diagrams）。它的第一份公共草案（0.8版本）是在1995年10月引入的。公众和Ivar Jacobson的反馈都在后面的两个版本（1996年7月的0.9版本和1996年10月的0.91版本）中包括了。在1997年7月1.0版本被提供给对象管理工作组（OMG）以供标准化。额外的一些增强被集成到UML 1.1版本中，它在1997年9月被提交给OMG。在1997年11月，UML被OMG采用作为标准的建模语言。UML目前的版本是UML 1.4，并且正在朝UML 2.0的方向进展。你可以查看OMG的Web站点www.omg.org找到更多关于UML的信息。

　　过程的角色

　　成功地开发的项目满足或超过了客户的期望，它是用及时并节约的方式开发的，并且对于改变和适应是有弹性的。开发的生命周期必须促进创造和革新，同时开发过程必须被控制和衡量，以确保项目真正地完成了。“创造性对于所有良好构建的面向对象架构的技巧是基本的，但是允许开发者完全无限制地创造会使项目趋向于永远不会结束。同样地，当组织开发小组共同工作的时候纪律是必要的，但是太多的纪律将产生官僚作风，这会毁掉各种创新的尝试”。良好地组织的迭代和增加的生命周期在不影响创造性的情况下提供了必要的控制。
　什么是迭代和增加的开发

　　在迭代和增加的生命周期中（图3），开发的进行就是一系列迭代，它们形成最终的系统。每种迭代包括下面的过程组成部分中的一个或多个：业务建模、需求、分析、设计、实现、测试和部署。在生命周期的开始，开发者不能假设所有的需求都是已知的；在所有的阶段中必然的改变都是预料中的。

　　这种类型的生命周期是一种减轻风险的过程。在生命周期的早期评估并区分了技术风险的优先次序，在每个阶段的开发中都会调整技术风险。风险被附加到每个阶段上，这样每个阶段的成功完成都会减轻附加到它上面的风险。其版本是按计划预定的，以确保最高的风险被最先处理。采用这种方式建立系统在生命周期的早期就暴露并减轻了系统的风险。这种生命周期方法的结果是风险更少，相关的投资更小。

 
 

　Rational Unified Process

　　通过使用Rational Unified Process可以支持对迭代和增加的生命周期的控制。它是解决那些集中于需求分析和设计的软件开发的技术方面和组织方面的问题的指导方针的扩展集合。

　　Rational Unified Process是沿着这两个方向构建的：

　　· 时间——把生命周期分割为阶段和迭代

　　· 过程组成部分——良好地定义的活动的特定工作集合的产品。

　　一个项目要获得成功的话，这两个方面都必须重视。

　　沿着时间维度构建项目包含了采用下面的基于时间的阶段：

　　· 初始——指定项目的版本

　　· 详尽细节——计划必要的活动和需要的资源；指明特征和设计架构

　　· 构建——用一系列增加的迭代建立产品

　　· 转换——为用户团体提供产品（制造、交付和训练）

　　沿着过程组成部分维度构建项目包含下面的活动：

　　· 业务建模——希望得到的系统能力和用户需求的认识

　　· 需求——拥有一组功能或非功能的需求的系统景象的叙述

　　· 分析和设计——在实现阶段系统如何被了解的描述

　　· 实现——结果将是可执行的系统的代码产品

　　· 测试——整个系统的验证

　　· 部署——系统的交付和对客户的用户训练

图4.过程组成步骤如何应用于某个基于时间的阶段