| 为了提高生产效率并获得成功，开发团队的成员需要拥有通用过程，通用的术语表和相应的支持工具。这篇文章讨论了UML如何能够帮助你达到这个目标。 在现代的软件开发中存在这一种基本上相互矛盾的论点。一方面组织面对着更加快速的响应市场的要求；另一方面，在相同的组织中还面临着以更低的成本交付高质量系统的压力。在这两者之间维持一个平衡是非常难的：匆忙的将软件系统推向市场，系统的质量勿庸置疑的会受到指责；而仅仅考虑质量问题，你也可能因为花费了过长的时间交付系统给用户而导致失败。 随着软件开发的本质发生的改变，融合这对相互矛盾的论点也成为了现实。从历史的观点来看，许多信息系统从体系架构上是非常简单的：应用被建立在中间层的基础上，中间层典型的封装了商业规则和数据访问，并且中间层被建立在永久存储之上，通常使用关系型的数据库系统。关系型数据库（或者数据库）本质上是系统的中心，它获取系统问题领域的词汇表并作为系统状态的存储服务。客户端/服务器架构的出现帮助了划分3层分离的结构，对于组织来说可以以一种可控的方式来应对系统相应的变化。尤其是，应用要能被快速的创建和修改，同时还要保存系统的状态，新的业务规则应该能够被引入而不会使系统受到影响，并且数据应该可以随着时间的流逝以一种新的或未预期的方式被挖掘。已被证明的且稳定的体系架构指引着很多组织以相应的方式构建他们的团队：分析人员与领域专家一起工作将用户的需要装化成需求，数据建模人员构建满足这些客户功能需求的领域模型，应用开发人员通过快速的构建和分解来建立满足系统行为需求的的新系统。 然而，随着Web的出现，软件开发的世界发生的翻天覆地的变化。在传统的客户端/服务器形式的系统中，一个系统典型的拥有可控数量的用户，通常用户的数量在几百到几千人之间；而在Web系统的情况下，一个系统也许会有几百万的用户，这些用户中的很多都是不在软件开发组织的控制之下的。在传统的客户端/服务器的系统中，从应用到数据的概念性的距离是非常小的；而在Web环境下，多数系统是由成千上万的移动的部分组成，这些移动部分通常是一些脚本的和一些编译过的代码，通过使用这些机制，使得应用和关系型的存储在距离上是相当远的。在传统的客户机/服务器系统中，变化是不可避免的，但变化可以被适当的管理，而在Web环境下，变化是连续的，并且变化发生在系统体系架构和实现技术的每一个层面上。在传统的客户机/服务器系统中，成功的开发并发布系统的涉众数量相对来说是比较少的；而在Web环境下，有很多新的涉众参与到了系统的开发当中，从内容的创建者到信息架构到网络设计，所有这些人都必须与传统的软件开发团队共同工作以克服软件开发中的矛盾。 成功的处理软件开发中的矛盾的组织与哪些在这方面失败的组织在组织运作的方法上存在着本质的不同。特别的，高生产效率的组织将软件开发看作为一项团队运动，在这样的组织中很多不同的对系统的开发和部署作出贡献的涉众通过使用通用的过程，通用的表达语言并使用支持和鼓励与过程和语言相关的最佳实践的工具来实现统一。 Rational统一过程（RUP）是一种已经被证明对大多数面临着软件开发中的矛盾的组织来说是非常有用的。RUP是一种鼓励以增量和迭代的方式交付系统的可执行版本的过程。RUP是风险和用例驱动的，这就意味着RUP倾向尽早的识别和处理防碍系统成功的风险，并且它的迭代是被来自于系统不同涉众透视图的用例指导的。此外，RUP是一种架构先行的过程，无论在哪里，系统的架构都是在早期就被稳定下来的，这样便可以建立和验证策略性的设计决定，然后在每一个新的迭代中进行不断的细化。 在传统的情况下，许多大数据系统在他们的实现上是使用Cobol这样的在当时具有统治地位的语言编写的。但随着Web的出现，一切都发生了变化，甚至一些遗留系统也已经被移植到了Web之上。在Web环境中，一个大数据的系统可以使用Cobol，C++ 或Java来编写服务器端的程序，使用教本语言（如Perl, VBScript, JavaScript），第四代编程语言（如：Delphi ）和经典的语言（如：Visual Basic 和 Java）来实现客户端的程序。象XML语言在这里很好的扮演了这样一个角色：XML是一种在Web上表示数据结构的通用语言。除了面临着一些编程语言的选择，企业开发团队也必须在各式各样的技术中作出正确的选择，如Microsoft WinDNA and Sun的 EJB，而这些技术呈现给开发人员不同的编程模型。 对于成功的组织，使企业开发团队的成员使用相同的声音进行交流是最基本的：不同的涉众针对系统的设计和实现有不同的视图，并且如果他们不使用同一种通用的词汇表和表达语言，统一团队的活动是不可能的。 这是统一建模语言（UML）的角色之一，UML是对象管理组织（OMG）的一项标准。UML是一种可视化的详细的构建并文档化软件系统工作产物的图形化语言。 对于一个建筑项目，你不能仅用蓝图中的单一一页来呈现，详细描述，构建和文档化一个高大建筑。软件也是如此：为了获得所有的策略性的系统设计决策，你需要几个不同的系统体系架构的视图，每一个视图针对者团队中的不同涉众。见图1所示，对于下面描述的软件系统来说，存在着五个非常重要的视图。
图1：用例视图 系统的用例视图是面向指定的最终用户的，这个视图获取了系统需要拥有的功能。这个视图对测试人员也是同样重要的。对于测试人员来说用例形成了对每一个个执行版本回归测试的基础。 系统的逻辑视图是分析人员和设计人员最感兴趣的，逻辑视图与实现了来自于第一个视图的用例的架构上的重要机制一起的描述了系统的问题领域的词汇表。在这个视图中，你将找到描述问题领域的应用，数据和业务模型，它逻辑视图与类，包，子系统和协作一起实现了系统的用例。 系统的过程视图描述了系统对过程和任务的分解，并且描述了并发元素的通讯和同步。这个视图对于从事整个系统的性能可测量性的系统集成人员来说是最重要的。系统的实现视图捕获了被系统的编程人员产生的工作产物，这个视图用于建模可执行组件和相应的源文件以及形成可执行部分的内容。这个视图位于项目配置管理实践的中心，以及描述了那些在每一个迭代中被组装成为可执行版本的组件。 系统的部署视图是项目的系统和网络工程师最关心的视图，系统和网络工程师负责系统硬件拓扑以及交付和安装搭建系统。这个视图描述了系统的物理网络配置。 所有的这些视图都是用UML来表示的。例如，类图可以被用来显示逻辑视图的静态部分，组件图可以被应用到组件视图。每一个视图的动态元素可以通过使用UML的行为图中的任何一种来获取，象交互图和状态表图。此外，通过UML的扩展机制，对语言进行相应的调整以使它可以表达特定领域的需求是可能的。比如，Jim Conallen创建的Web应用扩展就是针对以Web应用系统为中心的UML的扩展应用。通过使用这个蓝图的通用语言，不同的涉众可以贡献他在特定领域的专家建议，同时使用UML可以与其他的涉众进行良好的交流。 使开发团队使用同一种声音的价值对于哪些大数据应用来说格外的明显。无论在哪，数据库的设计人员都必须与系统分析人员和应用的开发人员一起工作以构建系统。传统的情况下，系统的数据中心部分使用实体－关系（ER）技术来进行建模。ER方法对开发团体的服务非常的好，但是，开发世界已经发生了显著的变化，以至ER方法已经能很难作为数据库设计人员与其他涉众进行交流的工具，并且它也很难再来表达目前大数据系统的语义。正如Dorsey 和 Hudicka所说的那样，"有一种强制的需要应用如此灵活的，有活力的并且是面向对象的UML来代替当前业界标准的ER建模"。事实上，这也是被Rational Software开发的UML在数据侧面扩展（data profile extension）方面的真正意图。 UML在语义上比传统的ER技术更加具有表达力。使用UML你不但可以建模与ER方法相同的元素，你可以建模其他种类的比如行为特征的关系（比如关联）。虽然UML的符号比传统的ER符号有所不同，但是对于使用ER建模的老手来说，转到UML上并不是非常的困难。见图2。
图2：从ER符号转换到UML符号 为了详细说明一个数据模型，你可以简单的使用UML类图。为了进一步获取数据库的逻辑设计，你可以使用UML类图中的作为表的类原型。对于每一个表，你可以对它的列（作为属性，包括作为主键和索引的属性）和触发器（作为操作）进行建模。为了获取数据库的物理元素，你可以使用UML组建图中的数据库原型组件。无论是在逻辑视图还是物理视图中，你当然具有UML对建模关系（如，关联和继承）和行为（如，通过交互图或状态表图）的全部的表达能力。 以这种方式，你就可以将你的系统数据模型和需求放到完成的项目中，跨职能的统一团队的成员形成了一种协作的力量。通过使用象Rational Rose Data Modeler这样的工具支持这些模型，之前数据团队中分离的成员现在可以非常容易的访问整个项目需求上下文中对数据的需求，并且可以在应用模型和与系统相关的需求文本和属性的用例模型之间对数据模型进行跟踪。相似的，分析人员与应用的开发人员可以更好的与数据小组进行交流，因为他们使用同一种公用的表达语言。因为UML的语义是非常丰富的，它可以在系统中被用来呈现和说明集成点。这也使得跟踪象模型向关系数据模型的移植变得可能。在支持数据库逆向工程的工具出现时，对于用户来说基于数据库结构通过正向工程来创建数据模型或者基于数据模型通过逆向工程来创建数据库将成为可能。所有与数据小组相关的语义－表，列，约束，索引，触发器以及更多－都能通过这样的转换被保存。 在协调软件开发中矛盾的方式下构建一个企业级的软件系统是非常难的，你必须在快速的开发压力与高质量之间进行权衡。使用UML对系统的工作产物进行可视化，描述和文档化可以使开发组织中的工作在一个团队中的涉众人员使用同一种语言和工具完成工作。 |
