J2EE结构中绘制用例图的策略

　　 
　　作者：J_Hospital@163.net



　

很多人在用Java语言开发网站或B/S结构的程序时，往往早已知道了整个系统的各个功能，却不知如何表述自己的观点。尽管对UML的各种表示方法比较熟悉，但用起来总是上不了手。尤其是在绘制用例图的时候，不得不用活动图来辅助说明，并且还是没有描述清楚。
　　尽管用例图描述的是一个静态的功能实现，但我们应该从纵向的流程去理解，否则我们在需求描述的时候将大量依赖活动图和笔记，使问题复杂化。从J2EE体系的这个角度来观察用例的实现机制，就能给相对容易地建造这个基于应用的J2EE构架。其秘诀在于用以下四个层次来剖析我们的用例图：
　　1. 视图（Presentation View）
　　2. 陈述逻辑（Presentation Logic）
　　　　需调用商业逻辑并返回视图的代码
　　3. 商业逻辑（Business Logic）
　　　　需执行实际用例功能并操作数据模型的代码
　　4. 数据模型（Data Model）
　　　　模拟真实世界商业抽象模型的持久对象
　　用例能够贯穿着四个层次的是它的消息（事件）。在网站中最常用的事件就是消息提交（Post Message），任何一个令人满意的商业应用必须允许消息交互。在需求分析阶段，我们必须详细描述每个用例的消息交互方是（请求/回答）。用手头上的这个用例所描述的商业需求，我们才能够为J2EE API´s做下一步的工作。
　　"消息提交"用例剖析：
　　1. 陈述视图
　　在J2EE中，Java Server Pages（JSP）被用于表达你的视图结构。这个用例需要一组"消息提交形式"的JSP。比如一个登陆前的JSP和一个登陆后的JSP页面。当然，我们也可以用servlet来实现完全相同的功能，只是不及JSP方便。
　　2. 陈述逻辑
　　Servlets/Java beans 是描述陈述逻辑最好的方式。消息提交用例需要一些servlet或java bean形式的java代码。这些servlet或java bean是J2EE蓝图的陈述组件，它们知道怎样执行商业逻辑，如何转移用户请求，并知道用何种视图把样格式化输出结果并表达出来。
　　3. 商业逻辑
　　Session bean是实现用例的商业逻辑的容器。如果用一个不是很标准的说法，就是我们所设计的用例都主要是由Session bean来实现的。某一条消息提交实际上将通过session bean的一个方法来实现。
　　4. 数据模型
　　J2EE还为我们的数据模型提供了一个非常有用的抽象，叫做entity bean。通过检查"消息提交"用例，我们能够推断我们需要构造消息的抽象模型。从而能够用entity bean去构造一条消息在真实世界的数据概念。
前面的分析，从本质上说，只是把用例的描述应该包括的几个方面（1、用例的目标；2、用例如何被启动；3、角色和用例之间的消息流； 4、用例的多种执行方案；5、用例怎样才算完成并把值传给了角色）用系统开发过程中所蕴含的内部体系来加以说明。实际运用的时候，需求分析和系统构造之间，应该有一种建立在软件体系上的工作默契（标准）。很多时候，没有必要用动态图等其他方式来画蛇添足，使问题复杂化；对于一些没有辅助说明的用例，只需从系统体系的角度去理解就可以了。这种描绘用例的方式非常简单却非常有用，在设计企业应用的时候可以避免很多猜测性的工作，并减少挫折。在国外，这种方式已广泛用于网站构建上，并获得了巨大的成功。
　　前面的分析主要是针对J2EE体系结构，我们完全可以结合MVC来进行描述。

原文转自：http://www.ltesting.net