摘要

　　如今，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规范中说方法必须出现在实现类中，并不意味着它需要出现在模型中。
www.goodsgy.com

[1] [2] [3] [4] [5]  下一页