对于成功的组织，使企业开发团队的成员使用相同的声音进行交流是最基本的：不同的涉众针对系统的设计和实现有不同的视图，并且如果他们不使用同一种通用的词汇表和表达语言，统一团队的活动是不可能的。
这是统一建模语言（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）方面的真正意图。
文章来源于领测软件测试网 https://www.ltesting.net/
