J2EE 应用程序开发：专业设计师的心得

　　OTN: 什么是 EAM 软件？
　　Aaron：企业资产管理是相当复杂的。它涉及的内容正像我们在 Ventureforth 所做的，是与工作管理相关的一些事务。我们的典型客户就是那些使用我们的应用程序来管理工作定单、订货和关键性能指示器的工厂或电力供应公司。举一个简单的例子，如果工厂某个区域的一个电灯泡灭了，最简单不过的方法就是找个人来替换这个灯泡。您必须发出一个工作命令，从存货中取出一个灯泡，等等。我已经设计好的产品之一名为 accuVista，该产品是一个关键性能的指示器，它使人们能够从数据库中挖掘出有用的数据，来分析哪些区域可能会出现问题以及在日常工作事务的处理过程中哪些环节还可以变得更为有效。这些指示器对于那些必须管理大量实物资产（就像可以在某个工厂周围所看到的那种）的制造业客户尤为重要。
　　　
　　图 1：accuVista 体系结构
　　该图表突出了该门户要实现各功能所需基本的硬件、软件和数据库组件。　
　　
　　OTN: 在设计 J2EE 应用程序过程中遇到过哪些大的挑战？
　　Aaron： 最大的挑战之一就是要拿出这样一个产品，该产品是可扩展的并允许不同客户按照他们自己所希望的来配置运行方式。归根结底，就是要使得应用程序可定制。 “最大的挑战之一就是要拿出这样一个产品，该产品要是可扩展的并允许不同客户来配置软件按照他们自己所希望的来配置运行方式。”　
　　
　　我们之所以严格遵守 J2EE 标准的原因就是，因为在构建可定制应用程序时，对于将应用程序逻辑从用户界面中分离出来以及在哪里存储数据等问题特别的重要。我们可以顺利完成软件开发的整个生命周期，而且如果我们坚持遵循像 J2EE 和 XML这样的标准，我们就能够自信地说，这些产品可以运行在各种不同的情况下，因为这些标准使组件得以合理地分离并被广泛地使用。
　　
　　作为一个设计师，同样重要地就是要确保从第一天起就要使用正确的方法。例如，数据库必须是安全的。它必须是一个高效的数据库。它必须能以有效的方式恢复数据。它必须能够身兼数据储存器和商务组件二职，而用户界面必须能以用户喜闻乐见的方式呈现数据和信息并同时完成相应的工作。重要的一件事就是要将商务逻辑和用户界面进行清晰的分离。这样一来，就不用将商务逻辑的编程嵌入到用户界面，每时每刻都要检测那些数据对后台数据库来说是不正确的。这些都必须在置入到数据库之前在服务器端进行。软件的中间部件可以在使用数据库资源之前对数据进行验证。设计师要确保遵循这些正确的构建方法。
　　
　　另一大挑战就是我们几乎在每个项目中都能见到的，而我也认为这确实存在于几乎所有的软件开发工作中—那就是，协作的问题。协作就意味着要将每个人都集合在一起，必须与从销售人员到真正构建产品的每个开发人员进行沟通。它还意味着要贯穿收集需求的全过程，并花费一定时间用于软件和数据库的建模。要想确保开发团队始终保持协作并不是件容易的事。之前我也曾经作过开发，可以说坐在电脑前开发代码是件容易的事，但是如果没有协作就无法拓宽眼界。
　　
　　OTN: 这就是一个设计师得出的结论—需要进行协作？
　　Aaron： 确实如此。作为一个设计师就意味着你要成为构建者和软件需求者—客户或终端用户之间的一个桥梁。设计师是进行实际商务操作的执行者、提出需求的客户和将要真正构建程序代码的程序员之间的桥梁。打比方我们来建造一个房子。在真正建造房子之前，设计蓝图非常重要。设计师（建筑师）要与高层人员、真正需要应用程序（或房子）的人员和进行构建（建筑）工作的人员进行交流。
　　
　　OTN:在您开始实际编码之前都采用了哪些主要的设计技术？
　　Aaron：非常重要的一个就是事例图—顾名思义，“这将说明如何使用该应用程序。用户将要这样做。其他人也将要那样做。”你必须要能看懂用来描述事件是如何在系统中推进的流程图。之后，确定问题就非常重要，一旦我完成了事例，就确定了系统如何运转。现在，我必须问自己，我将如何对此进行建模？非常重要的是，要从数据建模到确保数据的完整性，必须在建模的时候将全部问题都考虑在内，建模必须遵循规范，要保证建模方案日后的可用性，这一点对软件组件也很适用。重要的不仅仅是在构建之前首先决定你将要构建什么，相互间的协作也非常重要，只有这样整个软件开发团队才会对数据模型达成一致：“这就是数据和软件运行的方式。”而进行商务组件和 Java 开发的 J2EE 开发人员看到后，也会欣然赞同：“好的，这就是我们要做的软件。这就是它的运行方式。现在，我可以开始着手构建软件了。”
　　
　　这好象是电影中的情景。他们将某个东西称作故事板，该图板在实际拍摄之前将展现影片的样子。我认为，建模结构（电影或某个软件部件的研发方式），对于在构建之前能够将其可视化来说非常重要。这是 J2EE 应用程序开发的重要一课，因为你想要保持商务逻辑代码和用户界面的分离。在实际构建已经进行到一定深度之前，使用事例图和建模将帮助你及早发现潜在的问题。
　　　
　　图 2：事例图
　　事例图提供了关于 accuVista 门户应用程序是如何被使用的高层视图。开发人员、产品经理或工厂管理人员都会对产品是如何运转有个大致的了解。
　　
　　OTN:Oracle 的 BC4J 对这种框架对开发的帮助您怎么看待？
　　Aaron：BC4J 是中间件的一个杰出部件，它有很多优点，很难说它最棒的优点是什么，因为它优秀的特性实在太多了。但是，最主要的一点就是 BC4J 将用户界面从数据库中分离出来，这是从用户验证到数据更新都能用到的、中间件的一个大型重要部件。因此，如果你想将进入数据库的所有信息都转化成大写，你可以在中间层使用 BC4J 来强制实现。
　　
　　此外，当前非常重要的一点就是资源的使用。BC4J 允许中间层验证，这就是说除非通过该层否则数据不会直接放入到数据库中，而且由于我们有几个应用程序必须协同工作而且集成于中间层，所以使我们获益非浅。我们可以在将任何数据推入到数据库中之前设定一些认证规则。
　　
　　BC4J 还存储有关组件的元数据，标签等 UI 类型的控件等。我们还可以快速创建大型的 BC4J 组件，因为我们希望我们软件中的报表功能是动态的。例如，如果我们打算推入一个表单以恢复某个报表，我们希望能够从一个选择下拉框或单选按纽中列出的不同数据中进行选择，因为可能会有一些敏感数据，所以这些数据可能要根据登录的用户从数据库中选出，。
　　
　　OTN:您提到应用程序可定制的重要性。BC4J 是怎样帮助您确保应用程序的灵活性呢？
　　Aaron： 在 BC4J 框架下，底层的商务组件可以脱离元数据独立运行，宿怨才能使用户或客户定制应用程序。在软件开发中，这是一个飞跃。因此，如果用户说：“好的，我不想从消费者中选择；我更愿意从客户中选择。”那么我们就可以将此作为元数据存储到数据库中，而 BC4J 作为一个框架可以获得这一元数据并使用它。这就象是拥有了动态的商务逻辑，而这一点在 BC4J 出现之前是很难作到的。
　　
　　BC4J 可以使我们保持灵活性的另一个特性就是我们不再需要低级的大量的 SQL 语句，这确实是一件繁重的工作。为此，我们不必经常书写 SQL 查询语句，而且 BC4J 允许使用与对象之间存在父子关系的框架。例如，我设计的软件 accuVista，是一个门户，因此一切都得基于用户。一旦用户登录，我们就会根据我们所拥有的数据模型来运行，该模型可以通过 BC4J 框架轻松地访问到所有的用户对象。
　　
　　OTN: Oracle JDeveloper 是如何在应用程序元数据管理方面给予您帮助的？
　　Aaron：Jdeveloper，通过视图对象在这些对象中存储属性。多数 BC4J 对象可以设置属性，这样你就可以将一条 select 语句放在那里，该语句将对数据库进行操作并动态创建一列对该视图有所帮助的属性。这有助于定制应用程序，而且真的对使用我们产品的用户有所帮助。更为杰出的一点是安装的用户还可以进行更新，这样可以动态更改他们的应用程序。BC4J 框架使得我们能够作到这一点。
　　　
　　图 3：UML 报表模型
　　此外 Jdeveloper 的最佳特性之一就是可根据模型设计进行代码生成的 UML 工具。这将有助于协作，因为你还可以通过 UML 建模工具提交 Java 文档，并生成一段代码和所有的 Java 文档注释。就协作来讲，这对于我们是一个很棒的特性。很直率地讲，从 UML 可以清晰地看到软件是如何操作的，而且你也不必是一个 J2EE 开发人员。你可以是一位 COO 或是一位 CEO，只需看一看这些组件是如何相互作用的，这是一个非常大的优点。
　　　
　　图 4：实体关系 UML 模型
　　实体关系UML模型可以提供 Java 和数据库开发人员之间的协作并能够轻松地使软件和数据完整性问题得到可视化的描述。　
　　
　　OTN: 您能否就您的产品给我们一个体系结构上的概要描述？
　　Aaron： 没问题。该项目被称为 accuVista。其体系结构也是非常直观的。在后台，我们有一个企业资产管理数据库，该数据库通常运行在 Oracle 上。此产品称作 EMPAC 或 Maximo，也是一个工作管理软件。实际上是存储所有应用程序数据的地方，以及 accuVista 运行所需的所有工作定单类型的信息、所有资产信息和购买定单类型数据也都存放在这里。
　　
　　然后我们有一个 accuVista 报表库，该库存在于各自的数据库中。这就是存放报表相关元数据用于装载门户的地方，这样用户就可以登录进来查