北京火龙果软件工程技术中心 |
摘要 如今，UML用于对软件系统进行建模已有多年时间。然而，我极少看到有关对现代软件系统建模和技术的详细讨论或实例。例如，对应用程序及其部署建模需要开发各类原型系统，并需要使用有组织的方法来设计图的作用范围和布局，使其真正发挥作用。在复杂的环境中，建模显得尤为重要，它不仅能为编写代码的软件工程师带来好处，而且负责正确配置和部署软件系统的软件配置管理团队和生产服务团队也能从中获益良多。本文演示了对现代软件建模的几种方法，这些方法可用于精确而简明地交流架构方面的细节。 简介 不久以前，有用的企业应用程序还是由少数实体bean、较多的会话bean和一些JSP构建而成。EJB被打包在JAR文件中，而JSP则被简单地存储在Web服务器的类路径中。如果软件业还能有什么让您所称道的，那就是软件在大小、功能和复杂性方面呈几何指数增长。软件大小已经增长到每个企业应用程序的各个部分都被存储在压缩格式的WAR和EAR文件中的程度。软件系统的复杂性需要高效的建模，以便帮助管理设计和相互关系。软件功能现在已经处于这样一个级别：需要定义一个完整的新范型——即服务，才能对其进行管理。 必须对软件复杂性进行管理，因为它对企业的影响很大。这种管理可以同时采取规划和通信的形式。现在，可以使用UML来帮助规划软件的架构、设计和部署。还可以使用它把这些规划发送到企业中必须创建、安装和维护企业软件的各个部门中。 如果是对代码进行建模，UML 1 X就已经很不错了。而当对软件系统的打包和部署进行建模时，它就显得不够了。随着UML 2.0的出现，UML对核心软件系统建模的能力大为增强。然而，UML 2.0真正耀眼的地方是在对软件打包和部署建模时。 本文的目的是演示对现代软件系统进行建模的几种有效方法，这些方法可用于把架构、设计和部署方面的细节精确而简明地传达给企业中的相关负责部门。我并没有声明这是建模现代软件的惟一方法。UML的建模语言相当丰富。然而，如果您不确定如何使用UML.2.0进行快速建模，尤其是对特定于BEA WebLogic Platform建模的信息，本文将会为您提供帮助。 建模难题——少就是多 我喜欢更加敏捷的建模方法。对软件系统进行建模不会使公司直接获益，但可执行软件却可从中受益。然而，建模是一种有效的通信工具，有助于让整个公司就如何构建、部署和操作软件达成一致的认识。 在对软件建模时，其实少就是多。代码随着时间而增多，而模型则是静止的，它是某个时刻设计思想的快照。因此，对软件系统的每一个细节都建模并没有太大用处。软件系统的细节是在有机变化的。最佳方法是对软件的核心部分进行建模。这些模型往往能够在相当长的时间内发挥作用。 对代码进行建模 我将从一个特定于代码的模型开始，然后再逐渐转到软件打包和部署图上。在此过程中，我认为您可以很好地理解什么样的细节级别适合于您的企业。有一点很重要，即，您要不断地询问自己，“这个图可以帮助大家理解设计吗？”。 首先，让我们看一看我称之为“over-modeling”的建模方式。图1给出了一个使用了bean托管持久性的实体bean的UML图。在这个图中，您可以看到3个主接口和它们的根接口，以及实现类。
图1. 对一个EJB进行Over-modeling（单击图像查看大图） 乍一看，图中的内容似乎很多。其实，这个模型不过是较为详细而已，实际上内容很少。该图实际上显示了一个实体bean的基本结构。稍微了解一点EJB知识的工程师就会发现这个图其实很简单。如果您提供一个充满了这种“没有价值的东西”的完整设计文档，工程师们很快就会感到厌烦，并拒绝接受这种“无用的”设计文档。 提示！——对系统的重要部分而不是无关紧要的部分进行建模。 让我们看一看同一个图经过修改后的版本。它删除了无价值的内容，并将重点放在重要的内容上。样板代码和构件几乎从不需要建模，除非它们能给图带来特别的好处（比如提供上下文）。例如，表示一个像ejbActivate()这样的函数不能为图增加清晰度或内容，因此也就无需对其进行建模。EJB规范中说方法必须出现在实现类中，并不意味着它需要出现在模型中。
图2. 一个简明的EJB模型 除了在建模上显而易见的区别之外，两张图之间还有一处基本的区别：stereotype的自由使用。Stereotype是一种传达有关任意模型元素的不相关信息的强大方式。使用stereotype的另一个有利之处是，定义的信息是由对象而不是图来传达的。在图1中，JNDI信息表示在图中的一条注释中。这可以使JNDI信息特定于图。在图2中，我为捕捉JNDI信息的<<EntityBean>> stereotype定义了两个标记值。标记定义是stereotype的属性。通过为stereotype定义标记定义，实现了下面两个目标：为架构师和设计师提供一些有关每个stereotype中应该包含何种信息的提示，并为企业引入了一些建模标准。通过使用stereotype并填充相关的标记定义值，可以让包含该元素的每个图都能使用这些信息。大多数UML工具都允许有选择性地隐藏stereotype及其标记定义，您可以定制化每个图，同时无需修改任何重要的模型数据。在本文后面，我将提供一个示例的stereotype类别。 提示！——使用stereotype对不相关信息进行建模。 对可部署代码进行建模 现在，我将使用功能代码，并对应该如何把它打包到一个可部署模块中进行建模。在软件建模项目中，这通常是会被彻底忽视的重要一步。然而，在这个领域中，误解也是很常见的，而这些误解通常会增加公司的成本，因为它会导致项目出现延期并重新编码以纠正问题。 J2EE项目通常被打包为一个EAR或WAR文件。JAR文件仍然在使用，但是现在通常作为EAR或WAR文件的元素而存在。在UML中，文件被表示为Artifact。Artifact用于对节点上的内容进行建模。（节点通常表示一种设备，通常为计算机，但是它也可以表示一种虚拟设备。）例如，在UML中，文档、文件、可执行文件和库都被建模为Artifact。可部署的软件也在这种定义的范围之内，所以也可以把它建模为Artifact。 在整个领域内，这些类型的图相当少见。我仅看见过两家公司能够实现这种级别的建模。创建这些模型的人通常会掉入到对可部署模块的“定义”建模的陷阱中去。看看图3您就会明白我的意思了。
图3. 常见的可部署建模（单击图像查看大图） 这个图的第一个错误之处就是“对显而易见的内容进行建模”。“App-Inf”、“webapp”和“meta-inf”目录没有为图增加任何价值。类似地，对“自定义属性”文件的建模也很值得商榷。这只是图中的无用信息。图3的第二个错误之处是，它仅对模块的“定义”进行了建模。它仍然以软件为重点，展示了位于com.bea.customer Java包结构中的Customer EJB。对包结构建模可以增加价值，这取决于企业的需要，但是这个图确实还有疏漏之处。它应该包含比软件工程师需要的还多的信息，还应该包括对于软件配置管理团队来说重要的信息。这些“缺失的”信息就是部署模块的“上下文”。必须运行软件的团队需要知道如何部署它，因此上下文对于他们来说很重要。 提示！——部署模型需要说明“定义”和“上下文”。 看一看图4就很清楚了。这个图既说明了部署模块的定义，也说明了模块必须存在于其中的上下文。上下文提供了模块正确发挥功用所需的资源。这就告诉了SCM和生产团队要确保提供这些资源，否则软件就不会运行。
图4. 较好的可部署模块图（单击图像查看大图） 现在，对于任何必须为应用程序创建可执行环境的人，这个图都可以派上用场。现在，他们知道需要在环境中配置一个JMS队列和一个JDBC驱动程序，因为这是应用程序的需要。有关JMS队列和JDBC驱动程序的关键信息也包含在内。虽然我在这里没有对每一个细节都进行建模，但是通过对环境依赖性进行建模，我为SCM团队提供了询问其他问题的机会。此外，数据库管理员可能会喜欢看到这个图。他们很可能会提出有关客户数据库、索引、键之类的一些问题。 一个优秀的模型不只回答问题，它还会让人们思考和询问其他的问题。一开始，当您想建模来回答问题和记录决策时，这似乎有些奇怪。这没错，但是UML的设计目的不是对一切内容进行建模。某些内容，比如数据库设计，最好使用更加专业的工具进行建模。某些信息最好以纯文本格式进行定义。一个优秀的模型可作为企业其他部门进行具体思考和设计的出发点。 提示！——优秀的模型可以回答一些问题并提出一些其他的问题。 您可能已经注意到了，这些图中有些内容是相同的。每个图都有其特定的目的，并包含针对特定受众的消息。不能为了图本身而创建图，创建图是为了与预定的受众进行交流。每个图都应该包含一条有针对性的消息。这条消息可能是“下面是这个[概念|类|对象|节点]与其直接邻居的关系”，也可能是“下面是方法的行为”。就像所有的交流形式一样，如果没有特定的消息要传达，很可能是该消息的接收方根本无法理解您的消息。 提示！——每个图都应该有其特定的用途。 还要注意，在图4中，我避免对JMS队列和JDBC驱动程序的详细细节进行建模。JMS队列可以有另外的标记值，表示缓存大小、分页目录、启动时暂停的插入，等等。通常不会对这些数据建模，因为这类内容是随环境不同（也就是说，当把软件从测试环境转移到生产环境时）而不同的，而且这些值在应用程序调优过程中也会变化。提前指定它们的值通常不会带来什么好处。不过有一个例外：如果您的公司有这样一个策略——在进行性能调优之后采用最后的生产配置值（即，应用程序配置值），那么我将在模型中包含这些值。 部署图 出于某种原因，在大多数UML书籍中，部署图通常会受到轻视。在很多书中，有关部署图的章节只不过2到6页内容，而且只给出最简单的示例图。而我认为，这些图恰恰是UML中最重要的部分。这些图允许您表达一个软件系统或者甚至是整个IT部门的架构，而且在找出生产环境中性能问题的根源时，它们可能是一个关键因素。 一家典型的公司有很多环境：开发环境（至少一个）、测试环境（可能多于一个）、性能环境、登台环境，当然还有生产环境。许多企业还需要维护一个灾难恢复环境，以防自然或人为的灾难。但是，没有必要为所有这些环境维护部署图。开发、测试和性能环境通常变化得太快，以至于无法为部署在这些环境中的软件进行认真的建模。登台、生产和灾难恢复环境在本质上是（或者说应该是）类似的，因此只对生产环境建模通常就足以捕捉到部署空间的本质。 这正是UML 2.0真正的用武之地。从UML 2.0中的变化来看，显然很多人都觉得部署图相当重要。在项目的早期阶段，我建议在逻辑级别上对部署进行建模。我还建议在项目的最早期创建这些图。部署是项目规划的一个关键部分，而不是事后考虑。 我所看到的该领域中的部署图大多数止于逻辑模型。重要的是对所有系统部署进行建模，而不是单独对每个软件系统进行建模。筒仓应用程序大行其道的时代已经一去不复返了。我们现在生活在一个互连系统的世界，而这些互连需要进行规划和映射。 事实是，优秀的实用部署图能帮助您找出生产中的问题。系统是否是在投入到生产中时还运转良好，而现在却出了问题呢？有时候，显示征兆的系统并不是问题的根源所在。相反，有可能是上游或下游的系统没有按照期望运行，而性能问题表现在系统的完全不同的部分中了。 有一个古老的寓言是这么说的，有一个国王要求3个天生的盲人通过触摸大象的一个部分来描述大象的样子。摸到大象耳朵的盲人认为大象像一个簸箕，摸到大象尾巴的盲人认为大象像一把刷子，抱着大象腿的盲人认为大象像一棵树。生产环境就像这头大象一样，由许多部分组成。如果您无法窥见全貌，那么就很可能像寓言中的盲人一样看法片面。您对任何问题真正本质的看法都可能是错误的。然而，对一个大型系统进行建模不是一件简单的事情。如果试图在一幅图中表示过多的生态系统，那么结果很可能是在墙上贴满了许多无用的图。 因此，我推荐使用层次结构来组织具体的部署图。该层次结构的顶部是整个软件生态系统的全貌。由于这类图的本质，它将包含很少的具体部署细节，而将重点放在大型系统的逻辑关系上。 图5是一个生产环境的简单视图。从这幅简单的图中，可以看到整个架构是中心辐射型的。还可以看到，整个企业在逻辑上被划分为7个不同的组，还可以从中心节点的名称“服务基础架构”（Service Infrastructure）上猜到这些逻辑、功能性区域是通过一个服务层连接起来的。从这个图出发可以深入研究获得更多的细节。让我们来仔细看一下客户关系管理(Customer Relations Management，CRM)系统。
图5.部署概览图 在图6中，我修改了图的范围，以便聚焦于CRM系统。在这个图中，您可以看到子系统中包含的3个商业应用程序：Siebel、Salesforce.com和ACTI。Salesforce.com实际上就是一个基于Web的应用程序，驻留在Salesforce.com服务器上，但是从企业的角度来看，它被认为是企业的一部分。
图6. CRM域 从上图中您还可以看到，有2个自主开发的子系统。第一个子系统允许客户查看他们的帐户状态，定购产品，并使用Siebel系统提供的其他“自助”活动。第二个是CSR Command Center，它是一个自定义的应用程序，允许公司的客户服务代表代表客户执行任何功能。此外，它为客户提供通常不可用的功能，比如在联系人成为客户之前跟踪他们的前导信息。 接下来，我将聚焦于客户自助（Customer Self Service，CSS）子系统，以便更加详细地了解这个系统。
图7. CSS物理部署细节（单击图像查看大图） 图7给出了一幅非常详细的实际部署图。事实上，这个图已经是密密麻麻的了。注意Domain实例中的嵌套元素（图中心的大方框）。一般来说，我发现嵌套的最大深度是3层。如果超过3层，图就开始超出其消息的范围。这个图说明了如下内容：
在这幅图中，我提供了大量对开发、SCM和生产服务团队有用的信息。 提示！——三层的嵌套通常就够用了。 然而，还需要另一幅聚焦特定于WebLogic Server的细节的图。这幅图主要面向开发人员和SCM团队。图8就是一个例子。
图8. 聚焦WebLogic Server的图（单击图像查看大图） 下面，我将展示另一些特定于WebLogic Server的配置信息。您可以看到集群地址、多播地址和多播端口。您还可以看到创建了一个名为customerDS的数据源，其目标是BackEnd集群，这意味着该集群中的2台服务器都可以访问这个数据源。我可以使用类似的结构对JMS主题和队列、持久性存储等建模。 此外，您还可以看到，这里还显示了前面图中定义的可部署模块，以及它们如何关联到WebLogic集群。BackEnd集群（及其所有服务器）上都部署了customer.ear文件。类似地，WebPortal集群及其服务器上也部署了customer.ear文件。通过引用可部署模块图，可以快速关闭对这些信息的循环。 WebLogic Platform Stereotype分类 正如早先提到的那样，UML stereotype是一种功能强大的注释工具，它允许捕捉关于模型中元素的附加信息。在大多数建模工具中，都对J2EE、Web services和其他技术有着不同的UML分类。如果您的工具没有提供这些预定义的分类，或者如果预定义的分类不能满足您的特定要求，您可以快速创建自己的分类。图9说明了本文中使用的分类。您可以对这个例子进行定制化，来满足您的特定要求。
图9. WebLogic Platform模型的一种Stereotype分类（单击图像查看大图） 对于Stereotype，您要记住的重要一点就是，要以一致的方式使用它们。模型必须经过一个复审过程，以确保它们满足您所在公司所设立的标准。这可以帮助您创建标准化的模型，从而有助于让IT部门之间和子团队实现清楚的交流。独立地（即，在它自己的模型中）维护stereotype模型，然后把stereotype导入到项目模型中。这将为您节省时间，并确保您在当前项目中使用的是最新的stereotype分类。 结束语 在本文中，我涵盖了大量的细节。尽管进行高效的建模需要学习的东西肯定比我在这里讲的要多，本文应该可以帮助您创建更好的模型和图，改进IT部门的不同团队之间对于这些细节的交流，并提供一些标准和方法来帮助您更加有效地管理软件系统。记住，建模只是一种辅助性工作，真正重要的还是可以执行的软件系统。 原文出处:http://dev2dev.bea.com/pub/a/2006/05/modeling-enterprise.html |
版权所有：UML软件工程组织