（企业管理专业论文）准确、快速地使用J2EE技术创建管理信息系统.pdf

独创性声明 本人声明所里交的学位论文是本人在导师指导下进行的研究工作和取得的研究 成果，除了文中特别加以标注和致谢之处外，论文中不包含其他人已经发表或撰写过 的研究成果。也不包含为获得玉盗至些太堂或其他教育机构的学位或证书而傻用过 的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说 明并袭示了谢意。 学位论文作者签名：p 承国签字日期：弘。年月 日 学位论文版权使用授权书 本学位论文作者完全了解悉洼王些盔堂有关保留、使用学位论文的规定。特 授权丞挂至些太堂可以将学位论文的全部或部分内容编入有关数据库进行检索， 并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校向国家 有关部门或机构送交论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 学位论文作者签名：象雷 签字日嫡：沙。丫年 月j 甲日费纠冽坪 准确、快速地使用j 2 旺技术u 建管理信息系统 1 引言 本论文论述如何准确、快速地使用j 2 e e 架构来开发管理信息系统。j z e e 企 业平台采用多层设计模式要比旧式的两层架构更有效率和更灵活的多，此外， j 2 e e 还有“编写一次、随处运行”的特性，方便存取数据库的j d b ca p i 、c o r b a 技术以及能够在i n t e r n e t 应用中保护数据的安全模式等等。同时它还提供了对 e j b ( e n t e r p r i s ej a v a b e a n s ) 、j a v as e r v l e t sa p i 、j s p ( j a v as e r v e rp a g e s ) 以及x m l 技术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短 投放市场时间的体系结构。那又如何才能准确、快速地开发出基于j 2 e e 的管理 信息系统昵? 在此，本论文根据开发宜航咨询运输管理信息系统的过程，总结了 一套切实可行的开发方法，希望能为准确、快速地应用j 2 e e 开发企业管理信息 系统提供一些成功的思路。现归纳比较成功的开发思路如下： l + 在分析系统时，摒弃老式的注重数据流的分析，而是采用面向对象的思想， 使用u m l 建模对企业基本信息和业务流程进行分析，保证业务逻辑的完整和正 确为分析人员与客户j 分析人员与设计人员、分析人员与开发人员的交流打下 良好的基础。 2 在系统设计时，摒弃死板的功能说明书的设计方式，而是用r o s e 工具进行 可视化建模，大大加快了设计的速度。并且，使业务流程和数据流向 目了然。 逻辑视图的设计使编码人员在编码过程中清楚地知道所设计的每个类的功能和 所需提供的服务接口，并利用r o s e 工具自动生成程序代码的优点，大大降低了 编码阶段工作量，加快了项目的整个开发进程。 3 在开发系统时，摒弃老式的流水式开发，实行循环往复的r u p 迭代式开发方 法，使可能出现的问题都能在小范围内得到有效的控制和解决，保证了系统的准 确性，降低了系统开发的风险，同时也提高了开发的效率，缩短了开发的时间。 准确、快速地使用j 2 旺技术u 建管理信息系统 2j 2 e e 核心技术及实例系统介绍 分层模型和分布服务模型是j 2 e e 技术的核心技术。分层模型实现了代码的 分离，分布服务模型实现了分布式信息处理，这都使得系统的架构更清晰，信息处 理速度大大加快。在实例系统中，就充分利用了分层模型和分布服务模型的优点， 这两个模型也构成了我们实例系统的架构基础。所以下面给出了这两个模型的介 绍，以便于大家理解实例系统的架构。 2 1j 2 e e 四层模型 j 2 e e 使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用 组件根据他们所在的层分布在不同的机器上。事实上，s u n 设计j 2 e b 的初衷正 是为了解决两层模式( c l i e n t s e r v e r ) 的弊端，在传统模式中，客户端担当了过 多的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级 或改进，可伸展性也不理想，而且经常基于某种专有的协议，通常是某种数据库 协议。它使得重用业务逻辑和界面逻辑非常困难。现在j 2 e e 的多层企业级应用 模型将两层化模型中盼不同层面切分成许多层1 1 。一个多层化应用能够为不同的 每种服务提供一个独立的层，以下是j 2 e e 典型的四层结构： ( 1 ) 运行在客户端机器上的客户层组件： ( 2 ) 运行在j 2 e e 服务器上的w e b 层组件； ( 3 ) 运行在j 2 e e 服务器上的业务逻辑层组件； ( 4 ) 运行在e i s 服务器上的企业信息系统层； j 苫e 眭 斑；a l 镪1 j 2 e e 燕娜艘序2 厂荔f ”飞 i i t i l 。舆鼯i t r _ 。t - ”，“一 厂磊一磊一飞 i ，= = 一。篡 厂蔬蔷蕊r 飞 l ，。，：鬈曼， i l 鲐瑶 驾潆 # e b 船 擞务醢l b i s 鼹l 。一 ( 图2 1j 2 e e 典型的四层结构) j 2 8 h 姒务器 欹瓣簿 璀努措 隧 陵圈 准确、快速地使用j 2 e e 技术u 建管理信息系统 2 1 1j 2 e e 应用程序组件 j 2 e b 应用程序是由组件构成的j 2 e e 组件是具有独立功能的软件单元，它们 通过相关的类和文件组装成j 2 e e 应用程序，并与其他组件交互。j 2 e e 说明书中 定义了以下的j 2 e e 组件： ( 1 ) 应用客户端程序和a p p l e t s 是客户层组件； ( 2 ) j a v as e r v l e t 和j a v a s e r v e rp a g e s ( j s p ) 是w e b 层组件； ( 3 ) e n t e r p r i s ej a v a s e a n s ( e j b ) 是业务层组件： 2 1 2 客户层组件 j 2 e e 应用程序可以是基于w e b 方式的。也可以是基于传统方式的 w e b 层组件。j 2 e ew e b 层组件可以是j s p 页面或s e r v l e t s 。按照j 2 e e 规范， 静态的h t m l 页面和a p p l e t s 不算是w e b 层组件。正如下图所示的客户层那样， w e b 层可能包含某些j a v a b e a n 对象来处理用户输入，并把输入发送给运行在业 务层上的e n t e r p r is eb e a n 来进行处理。 # 曲堪 ( 图2 2j 2 e ew e b 层组件) j 2 腿胜务器 2 1 3 业务屡组件 业务层代码的逻辑用来满足特殊业务领域的需要由运行在业务层上的 e n t e r p r i s eb e a n 进行处理。下图表明了一个e n t e r p r i s eb e a n 是如何从客户 端程序接收数据，进行处理( 如果必要的话) ，并发送到e i s 层储存的，这个过 程也可以逆向进行。有三种企业级的b e a n ：会话( s e s s i o n ) b e a n s 、实体( e n t i t y ) b e a n s 和消息驱动( m e s s a g e d r i y e n ) b e a n s 。会话b e a n 表示与客户端程序的临 时交互。当客户端程序执行完后，会话b e a n 和相关数据就会消失。相反，实体 b e a n 表示数据库的表中一行永久的记录。当客户端程序中止或服务器关闭时， 准确、快速地使用j 2 e e 技术创建管理信息系统 就会有潜在的服务保证实体b e a n 的数据得以保存。消息驱动b e a n 结合了会话 b e a n 和j m s 的消息监听器的特性，允许个业务层组件异步接收j m s 消息。 j 2 燃激务器 ( 图2 3e j b 的工作流程) 2 1 4 企业信息系统层 企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资 源计划( e r p ) 。大型机事务处理，数据库系统，和其它的遗留信息系统例如， j 2 e e 应用组件可能为了数据库连接需要访问企业信息系统。 2 2 分布服务实例模型 2 2 1 概念定义 服务( s e r v i c e ) ：满足客户一组内聚性高的业务用例的集合。简单地说就是 我们的一个软件产品为满足客户的需求所提供的服务。 服务实例( s e r v i c ei n s t a n c e ) ：是对服务实例化的结果。有点像业务网点， 每个业务网点均有自己独立的服务软件和硬件( 也可是逻辑上的) 。 业务组件( b u s i n e s sc o m p o n e n t ) ：实现服务的软件的零配件，从功能划分 的意义上，来说也是结构化设计中的模块【2 】。 2 2 2 模型要点 分布服务的实现，一个关键性的问题是业务数据的交换。对于此问题有多种 多样的解决方式。大体可分为两类：纯数据交换和含有业务语义的业务数据交换 ( 简称业务数据教化) 。纯数据交换试图找到一种通用交换的方法( 如数据库同 步等技术) ，但现实业务操作中是不可能的或者是不合适的。故此，所有各服务 数据交换均要求通过个s e r v i c e 提供的服务接口( s e r v i c ei n t e r f a c e ) 直接进 行数据交换，s e r v i c ei n t e r f a c e 必须懂得如何解释数据和检验数据的业务完整 性，也懂得如何操作这些业务数据，以业务代理( b u s i n e s sd e l e g a t e ) 身份操 准确、快速地使用j 2 e e 技术u 建管理信息系统 作数据。 2 3 实例系统介绍 ( 图2 4 分布服务模型) 运输管理信息系统需要处理大量的即时信息，还要维护和更新大量的数据， 同时管理者还要根据这些信息和资料安排任务和作业。运输管理信息系统的这些 特点决定了使用新的j 2 e e 企业框架要比旧式的两层架构要更有效率和更灵活的 多，而且分布式计算大大加快了信息处理的速度。宣航咨询运输管理信息系统是 我校和宣航咨询公司共同开发的一套运输管理软件。其中我校完成了该软件的需 求分析、系统设计及表现层和逻辑层的编码工作，我有幸参加了该课题的工作， 并以此项目为工程实证完成了该篇论文。 该项目适用于进行航运集装箱运输的基础业务的管理，并能核算整个过程中 的费用成本与利润。本软件的调研和使用客户是天津港荣公司，主营业务是负责 天津港的集装箱装运和运输，所以每天都会产生大批量的车辆调度、运输业务、 ：一 准确、快速地使用j 2 旺技术u 建管理信息系统 车队维护、成本利润分析等的刘时信息。该软件就是为了实现对这些信息的快速 便捷的管理。 此系统是基于j 2 e e 三层体系结构设计的。参见下图： ( 图2 5 三层体系结构设计) l_ck奠y-j皇暑nk_-廿 准确、快速地使用j 2 e e 技术u 建管理信息系统 3 使用u m l 可视化建模准确地进行基于j 2 e e 平台的管理信 息系统的系统分析及工程实证 3 1 面向对象的技术与u m l 语言 面向列象技术车h 州引过棵技术足软件开发领域的犬飞跃。盯n 蚓_ 对 豫技术的封装 ! ! | = 特点，使得d ：i q ：企j j k 同部的j 眦务信息流程的变化丽进行模删修改 榭对容勃，偿程序员。! 作局削在较小范嘲内，小雏j 二影响糙个系统，从而帮助保 征系统的勃于修改性。l i f 于嘶向剥琢技术的继承性特点，、1 企娩发艇或j i k 务流删 发生较大改变时，通过对已有晌炎的继承和重用，能快速完成信息系绒i 拘升级改 逑。 与传统的结构化软件开发技术不同，面向对象技术提出了对象的封装、继承、 多态性、对象的覆盖等方法雨传统的程序表示方法( 如：框图、n s 圈等) ，无 法对面向对象这些新的特性加以描述表达。因此，面向对象技术的表达、面向对 象技术的方法论也是面形对象技术必不可少的研究内容之一。 面向对象方法论从1 9 8 6 年b o o c h 率先提出后，至今已有5 0 种以上的方法论 出现，常见的有r u m b a u g h 的对象模型技术o m t 、b o o c h 以及y o u r d o n 的面向对象 分析与设计( o o a 佃d ) 、j a c o b s o n 的面向对象软件工程( o o s e ) 、( m a r t i n o d e l l ) 的面向对象分析与设计( o o a d ) 、( s h l a e rm e l l o r ) 的面向对象系统分析( o o s a ) 、 b r o c k 的责任导向设计r d d 等等，各有其特色，但是不同分析设计方法缺乏统一 的标准”。 为了整合面向对象方法论，1 9 9 5 年由r u m b a u g h 、b o o c h 、f a c o b s o n 三位面向对 象大师提出与最重要的、具有划时代统一建模语言( u n i f ym o d e l i n gl a n g u a g e ， 简称u m l ) 。1 9 9 7 年后，u m l 成为现今国际软件工业的标准。事实上，近年来u m l 在世界范围，已经逐渐成为是面向对象技术领域内占主导地位的标准建模语言。 统一建模语言是一种用于描述、构造软件系统以及商业建模的语言，综合了 在大型、复杂系统的建模领域得到认可的优秀的软件工程方法。u m l 是大多数公 司采用的标准，是a n s i 和o m g 等部门采用的标准。 u m l 的产生有三方面的原因：首先，不同的砸向对象方法有着许多相似之处， 通过这项工作，消除可能会给使用者造成混淆的不必要的差异是非常有意义的； 其次，语义和表示法的统一，可以稳定面向对象技术的市场，使工程开发可以采 用- i l 成熟的建模语言，c a s e 工具的设计者也可以集中精力设计出更优秀的系 统；第三，这种统一能使现有的方法继续向前发展，积累已有的经验，解决以前 没有解决好的问题。u m l 为软件系统建模提供了以下四个方面的支持： 准确、快速地使用j 2 旺技术u 建管理信息系统 ( 1 ) 用例模型( u s ec a s e ) ：定义系统的使用事件( u s ec a s e ) 、角色( a c t o r ) 及 角色与事件之间的交互行为( a s s o c i a t i o n ) 。 ( 2 ) 逻辑模型：定义类、对象及相互之间的关系。 ( 3 ) 组件模型：组件是组成应用程序的可执行单元，类被分配到组件中，以提 供可重复使用的应用程序结构部件。组件为即插即用的应用程序结构奠定 了基础。u m l 对可重用性的支持，在设计的前期体现在支持可重复使用的 类和结构，后期则体现在组件装配。 ( 4 ) 分布处理模型：将软件系统映射到分布处理结构中。u m l 能够描述网络拓 扑结构的节点，这些节点相互的连接方式以及软件系统在网络中的分布情 况。 3 2 用例模型与需求分析 长期以来，在面向对象开发和传统的软件开发中人们根据典型的使用情景 来了解需求。但是。这些使用情景是非正式的，虽然经常使用，却难以建立正式文 档。用例模型由i v a rj a c o b s o n 在开发a x e 系统中首先使用，并加入由他所侣导 的0 0 s e 和o b j e c t o r y 方法中h 。用例方法引起了面向对象领域的极大关注。自 1 9 9 4 年i v a rj a c o b s o n 的著作出版后，面向对象领域已广泛接纳了用例这一概念 并认为它是第二代面向对象技术的标志。用例模型描述的是外部执行者( a c t o r ) 所理解的系统功能。用例模型用于需求分析阶段，它的建立是系统开发者和用户 反复讨论的结果，表明了开发者和用户对需求规格达成的共识。首先它描述了待 开发系统的功能需求：其次它将系统看作黑盒，从外部执行者的角度来理解系统 第三。它驱动了需求分析之后各阶段的开发工作。不仅在开发过程中保证了系统 所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的 各个阶段和u m l 的各个模型。在u m l 中，一个用例模型由若干个用例图描述，用 例图主要元素是用例和执行者。 3 2 1 用例 从本质上讲，一个用例是用户与计算机之间的一次典型交互作用。以字处理 软件为例，“将某些正文置为黑体”和“创建个索引”便是硒个典型的用例。 在b m l 中。用例被定义成系统执行的+ 系列动作，动作执行的结果能被指定执行 者察觉到。 准确、快速地使用j 2 旺技术u 建管理信息系统 ( 图3 1 用例图) 在u m l 中，用例表示为一个椭圆。图3 - 2 1 显示了一个金融贸易系统的用例 图。其中，“风险分析”，“交易估价”，“进行交易”，“设置边界”，“超越边 界的交易”，“评价贸易”，“更新帐目”等都是用例的实例。概括地说，用例有 以下特点： 用例捕获某些用户可见的需求，实现一个具体的用户目标。 用例由执行者激活，并提供确切的值给执行者。 用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。 3 2 2 执行者( a c t o r ) 执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。图 3 2 一l 中有四个执行者：贸易经理、营销人员、售货员和记帐系统。在某些组织 中很可能有许多营销人员。但就该系统而言，他们均起着同种作用，扮演着相同 的角色，所以用一个执行者表示。一个用户也可以扮演多种角色( 执行者) 。例如， 一个高级营销人员既可以是贸易经理，也可以是普通的营销人员：一个营销人员 也可以是售货员。在处理执行者时，应考虑其作用，而不是人或工作名称，这一点 是很重要的。图3 2 一l 中，不带箭头的线段将执行者与用例连接n - 起表示两者 之间交换信息，称之为通信联系。执行者触发用例，并与用例进行信息交换。单个 执行者可与多个用例联系；反过来，一个用例可与多个执行者联系。对同一个用 例而言，不同执行者有着不同的作用：他们可以从用例中取值，也可以参与到用例 中。需要注意的是，尽管执行者在用例图中是用类似人的图形来表示的，但执行者 未必是人。例如。执行者也可以是一个外界系统，该外界系统可能需要从当前系统 中获取信息。与当前系统有进行交互。在图3 2 一l 中，我们可以看到，记帐系统是 一个外界系统，它需要更新帐目。通过实践，我们发现执行者对提供用例是非常有 准确、快速地使用j 2 旺技术u 建管理信息系统 用的。面对一个大系统，要列出用例清单常常是十分困难。这时可先列出执行者 清单再对每个执行者列出它的用例，问题就会变得容易很多。 3 2 3 使用和扩展( u s ea n de x t e n d ) 图3 - 2 一l 中除了包含执行者与用例之间的连接外，还有另外两种类型的连接 用以表示用例之间的使用和扩展关系。使用和扩展是两种不同形式的继承关系。 当一个用例与另一个用例相似，但所做的动作多一些，就可以用到扩展关系。例如 图3 2 一l 中基本的用例是“进行交易”。 交易中可能切都进行得很顺利，但 也可能存在扰乱顺利进行交易的因素。其中之一便是超出某些边界值的情况。例 如，贸易组织会对某个特定客户规定最大贸易量这列不能执行给定用例提供的 常规动作而要做些改动。我们可在“进行交易”用例中做改动。但是，这将把该 用例与大堆特殊的判断和逻辑混杂在一起，使正常的流程晦涩4 i 堪。图3 2 一l 中将常规的动作放在“进行交易”用例中，而将非常规的动作放置于“超越边界 的交易”用例中，这便是扩展关系的实质。当有一大块相似的动作存在于几个用 例。又不想重复描述该动作时，就可以用到使用关系。例如，现实中风险分析和交 易估价都需要评价贸易，为此可单独定义一个用例，即“评价贸易”，而“风险分 析”和“交易估价”用例将使用它。请注意扩展与使用之间的相似点和不同点。 它们两个都意味着从几个用例中抽取那些公共的行为，再放入一个单独用例中， 而这个用例被其他几个用例使用或扩展。但使用和扩展的目的是不同的。 3 2 4 用例模型的获取 在面向对象技术中，用例用来获取需求，规划和控制项目。用例的获取是需求 分析阶段的主要任务之一，而且是首先要做的工作。大部分用例将在项目的需求 分析阶段产生，并且随着工作的深入会发现更多的用例，这些都应及时增添到已 有的用例集中。用例集中的每个用例都是一个潜在的需求。在获取用例模型时， 可以采用以下步骤： ( 1 ) 获取执行者： 获取用例首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执 行者。以下问题可供参考： 谁使用系统的主要功能( 主要使用者) 。 谁需要系统支持他们的日常工作。 谁来维护、管理使系统正常工作( 辅助使用者) 。 系统需要操纵哪些硬件。 系统需要与哪些其它系统交互，包含其它计算机系统和其它应用程序。 准确、快速地使用j 2 旺技术憷管理信息系统 对系统产生的结果感兴趣的人或事物。 ( 2 ) 获取用例： 一旦获取了执行者，就可以对每个执行者提出问题以获取用例。以下问题可供参 考： 执行者要求系统提供哪些功能( 执行者需要做什么) ? 执行者需要读、产生、删除、修改或存储的信息有哪些类型。 必须提醒执行者的系统事件有哪些? 或者执行者必须提醒系统的事件有哪些? 怎样把这些事件表示成用例中的功能? 为了完整地描述用例，还需要知道执行者的某些典型功能能否被系统自动实 现? 还有一些不针对具体执行者问题( 即针对整个系统的问题) ： 系统需要何种输入输出? 输入从何处来? 输出到何处? 当前运行系统( 也许是一些手工操作而不是计算机系统) 的主要问题? 需要注意，最后两个问题并不是指没有执行者也可以有用例，只是获取用例时尚 不知道执行者是什么。一个用例必须至少与一个执行者关联。还需要注意：不同 的设计者对用例的利用程度也不同。例如，i v a rj a c o b s o n 说，对一个十人年阿项 目，他需要二十个用例。而在一个相同规模的项目，hm a r t i nf o w l e r 则用了一百 多个用例。我们认为：任何合适的用例都可使用确定用例的过程是对获取的用例 进行提炼和归纳的过程，对一个十人年的项目来说，二十个用例似乎太少，百多 个用例则嫌太多需要保持二者间的相对均衡。 3 3 工程实证 需求阶段对m i s 和e r p 软件的开发都有着至关重要的作用，需求分析是一一个 项目的开端，也是项目建设的基石。在以往失败的项目中，7 0 是由于需求分析 的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握 程度。而项目的整体风险往往表现在需求分析不明确、业务流程不台理。为了能 够保证在系统分析中的准确性，我们在系统分析中使用用例模型来进行需求的分 析，尤其对于中闻逻辑层的分析，充分考虑到和j 2 e e 技术的结合，以利于将来在 设计中方便对e j b 功能边界的界定l 。 3 3 1 宜航咨询运输管理信息系统的特征和模式 本系统综合了与平台无关、面向对象、分布式的信息处理等一系列的优点， 它具有以下一些特征： 本管理信息系统要处理大量的资料信息和即时信息，其信息度量单位不再是 准确、快速地使崩j 2 e e 技术刨建管理信息系统 k b 、船，而是g b 。 各种信息间并不是孤立的，而是相互关联的、动态的。必须能够通过一定的 相关关系，由特定的存取方法来查找、访问和修改这些信息资源。 该系统必须为用户提供统一的访问手段，能够让用户透明方便地获取所需的 信息而不必关心这些信息的具体位置。对信息资源的检索应该是智能化、交 互式的。 该系统建立在异构平台上，具有分布、开放的信息结构，高速、可靠的网络 环境是其运行的基础。它突破了时间、空间的限制，让用户可以在任何地方、 任何时间获取自己所需的信息。在此基础上提供的导航式和个性化的服务， 使服务内容更多样、服务模式更广泛，这是对传统运输管理信息系统服务功 能的突破。 本系统的模式，可以用图3 3 1 简单说明，通过图3 3 1 也反映出系统的基 本特征。用户通过网络和通信系统，连接到宜航咨询运输管理信息系统，通过这 个统一一的访问界面，用户可以透明地获取信息资源，但用户是分组和分角色的， 不同组的用户所拥有的权限不同从而能够看到的信息内容也不同。 鱼， 用户 ( 图3 2 系统模型) 3 3 2 系统需求层次的划分 我们把本系统的需求分为四个不同的层次一业务需求、用户需求、功能需求 和非功能需求。业务需求( b u s i n e s sr e q u i r e m e n t ) 反映了组织机构或辑户对系 统的目标要求。用户需求( u s e rr e q u i r e m e n t ) 文档描述了用户使用产品必须要 完成的任务，这在使用用例( u s ec a s e ) 予以说明。功能需求( f u n c t i o n a l r e q u i r e m e n t ) 定义了开发人员必须实现的软件功能，使得用户能完成他们的任 务，从而满足了业务需求。软件需求各组成部分之间的关系如图所示： 准确、快速地使片ij 2 e f 投水口u 建管理信息系统 ( 图3 3 系统需求分层模型) 四层中重心是用户需求，即确定角色和角色的用例。需求分析是很难的，因 为很多需求是隐性的，很难获取。更难保证需求完整，而需求又是易变的。一般 来说，作需求分析的常规方法是阅读企业的文件，但是企业的文件往往有局限性， 例如落后于当前的业务，不够明确，依赖于管理水平的高低所以我们在获取需 求的时候。除了阅读必要的文件外，大量增加了对客户的访谈会( i n t e r v i e w ) 。 功能需求依赖于用户需求，可以说是用户需求在系统上的一个映射 ( m a p p i n g ) 。在这个层次上，我们为用户做出了一个软件原型。因为，需求分析 阶段用户对软件还是没有一个实实在在的概念，如果你给用户一个原型，用户就 会说“哦，我的x x 系统原来就是这样的”。这就避免了用户在软件开发完成后 才看到软件所带来的一些风险。是否有必要采用快速原型开发法和原型应开发到 何种地步取决于具体的项目。但这种方法可以有效地加强开发人员与客户的沟 通。 3 3 3 系统功能划分 在用户需求分析中，我们采用化整为零的思想，把整个系统分成不同的功能 模块，整理出各个模块的功能描述，并确定每个模块的输入、输出数据。完成这项 工作后，汇总成系统功能列表( 请参考附录) 。 系统功能列表主要是给设计人员和开发人员看的，对用户来说，这太抽象了。 为了更直观、更形象地表达系统功能的组成，让用户也t i - 目了然，我们就用到 用例图了。用户通常并不关心系统是如何实现的，对他们来说，更重要的是要达 到他的目的。相反的，大部分的程序员的工作习惯就是考虑计算机应该如何实现 用户的要求。所幸的是，用例方法能够调和双方的矛盾，因为虽然用例是来源于 用户，服务于用户，但是它同样可以用于开发的流程。当系统的开发过程都是基 准确、快速地使用j 2 旺技术u 建管理信息系统 于用例的，通过用例获取需求，用用例设计，用用例编码，用用例测试的时候。 这个开发过程就是用例驱动的。我们的开发过程中贯彻了用例驱动的思想。 在具体的需求过程。p ，有大的用例，也有小的用例。主要是由于用例的范围 决定的。用例像是一个黑盒，它没有包括任何和实现有关或是内部的一一些信息。 它很容易就被用户( 也包括开发者) 所理解。我们根据这个思想我们设计出了以 下功能结构用例总图： f 寻一1 i 一。一一j ( 图3 4 功能结构用例总图) 总图中每个功能模缺还是很大的，为了让客户能够了解到每个模块的具体功 能大致有哪些我们还要将其展开。现在以基础资料管理系统为例： 朗凹 圈圈 ( 图3 5 基础资料管理用例图) 客户从图中可直观看出该系统模块中又被划分成四个小的子模块，每个小模 块负责一种类型的基础资料的管理。当然这样的用例不足以表达足够的信息来支 持系统的开发，为了开发，就有必要把用例黑盒打开，审视其内部的结构找出 黑盒内部的a c t o r 和u s ec a s e 。就这样通过不断的打开黑盒，分析黑盒，再打 开新的黑盒。直到整个系统可以被清晰的了解为止。我们以司机管理和车辆管理 两个小模块的展开为例： 准确、快速地使用 2 e e 技术刨建管理信息系统 遣还_ 茛用的田 帆申请朗 口帆 ( 图3 6 司机管理用例图) 车相馨皇瑚 r 理 ( 图3 7 车辆管理用例圈) 3 3 4 业务建模 需求是技术无关( t e c h n o l o g yi n d e p e n d e n t ) 的。在需求阶段讨论技术是没 有任何意义的。那只会让你的注意力分散。技术的实现细节是在后面的分析、设 计阶段才需要考虑的事情。而在业务建模阶段，不但要保证需求的技术无关性， 还要保证你的需求不要深入细节。因为在业务建模阶段，最重要的事情就是要了 解业务的全貌，深入细节会浪费时间和精力。要知道，讨论一个企业里的业务细 节，就算给你一个月的时间也未必能够结束。 业务用例模型是说明业务预期功能的模型。作为一个核心需求模型，业务用 例模型用于确定组织的各个角色和所完成的业务工作。从业务用例模型的定义可 以看出，它是对企业的最核心，最概括的业务说明。它主要是由业务用例和业务 准确、快速地使用j 2 e e 技术创建管理信息系统 主角构成的，其主要目的是说明客户和合作伙伴是如何开展业务的，它描述业务 的主要方式是通过业务用例的方式。我们把宜航咨询运输管理信息系统的总业务 流程分割成了三个相互联系的模块： 臣匹 _ _ ； 自 ( 图3 8 总业务流程用例图) 在建立了基本的业务用例模型之后，对此模型进行精化是非常有必要的，这 样就会后续的设计和开发业务流程打下了良好的基础。下面绪出了运输业务管理 的详细业务用例图： 翻i 化“业萑舟一-“确定十捷目t 任势时问窗口 qh一 ，、 、 o 、 一。凛。 调整业舟时氟蛙续宥另外任井完成 谰捌出舟对蕞 弟十任劳 ( 图3 9 详细的运输业务用例图) 准确、抉速地使用j 2 e e 技术创建管理信息系统 4 使用r o s e 工具快速地进行基于j 2 e e 平台的管理信息系统 的系统设计及工程实证 4 1 可视化建模与r a ti o n air o s e 建模工具 提起建模，每一位软件开发人员都不会陌生，但我们还是要给它个明确的 定义：建模是人类对客观世界和抽象事物之间联系的具体描述。计算机技术的飞 速发展创造了人类历史上新的奇迹，但是，随着现代软件工程的复杂程度不断提 高，项且失败的可能性也相应的增加了。信息系统的开发人员发现当他们面对越 来越多的源代码的时候，脑海中系统模型及其内部的联系也越发混沌和模糊了。 面对现代社会庞大而繁杂的信息事务，开发人员渴望使信息变得简单易懂。 正是因为感到无法对整个复杂的系统全面地把握，所以我们需要建模。人对 复杂性的认识是有局限性的，对程序员来说，仅仅几行源代码是不能对整个开发 项目提供一个全面认识的，而模型则可以使设计者从全局上把握系统及其内部的 联系，而不至于陷入每个模块的细节之中。建模的意义重大“分而治之”，这 是一个古老而有效的概念。可以想象，当我们把特别复杂而困难的问题细化分解 之后，一次只是设法解决其中一个的时候，事情就容易解决多了。模型的作用就 是使复杂的信息关联简单易懂，它使我们容易洞察复杂堆砌而成的原始数据背后 的规律，并能有效地使我们将系统需求映射到软件结构上去。 建模是我们逐层深入解决问题的方法。确认应用系统的功能需求，并为事务 处理原则建模。对抽象的对象映射需求，辨认和提供设计模板，并创建惯用的模 板分辨、设计对象或划分三层模型的服务。对软件的组成部分i 畎射成对象，并设 计组件在网络上如何分布。建模允许处理发生变化，通过建立抽象概念，设计者 就可以有效地处理大型工程和复杂结构。建模建立起应用程序的客户和编程人员 之间生动的联系【5 l 。 利用手工建模，既耗费了大量的时间和精力又无法对整个复杂系统全面准确 的描述，以至于直接影响应用系统的开发质量和速度。建模工具是帮助设计者实 现任何复杂的工程项目的有力工具，在软件工程中，它能够把模型与实际应用紧 密地联系起来。通过模型与代码之间的映射可以直接为不同的程序开发环境生 成系统结构的框架，通过建立模型和代码间的映射，可以确保代码改进时模型也 随之更新了，而且通过模型与代码间的自动连接，建模工具可以确保良好的没计 实施。 但是如果没有一个被普遍认可的国际标准，事情就会陷入混乱之中。 r a t i o n a lr o s e 提供对工业标准标记的独家支持，其中包括一体化建模语言 准确、快速地使用j 2 旺技术u 建管理信息系统 ( 嘣l ) ，这一即将在工业界成为标准的面向对象建模语言。体化建模语言( u l ) 正是为了适应企业级的复杂开发中对重用、结构和扩展能力的严格要求而设计的 建模语言。一体化建模语言( u m l ) 是早期面对对象研究和设计方法的进 步扩 展，由世界级面向对象技术知名专家g r a d y b o o c h ，i v a rj a c o b s o n 和j i mr u m b a u g h 对b o o c h 标记、o o s e 拍；记和o m t 标记理论的研究基础上提出冉勺，为可视化建模 软件奠定了坚实的理论基础l 。 r a t i o n a lr o s e 产品为大型软件工程提供了可甥性和柔韧性极强的解决力 案：强有力的浏览器，用于查看模型和查找可重用的组件：可定制的目标库或编 码指南的代码生成机制；既支持目标语言中的标准类型又支持用户自定义的数据 类型；保证模型与代码之间转化的一致性；通过o l e 连接，r a t i o n a l r o s e 图表 可动态连接到m i c r o s o f tw o r d 中；能够与r a t i o n a l v is u a t e s t 、s q as u i t e 和s o d a 文档工具无缝集成，完成软件生命周期中的全部辅助软件工程工作：强 有力的正反向建模丁作；缩短开发周期：降低维护成本等等”】。 我们在项目设计使用r e t i o n a lr o s e 进行可视化建模，充分发挥出r o s e 和 j a v a 技术的紧密结合的优势。r o s e 可以产生系统的框架代码，这样可以大大节 省编码的时间，因为编写这些代码是很繁琐的。产生框架代码后，开发人员就只 需关注项目的特定业务方面。设计是一个系统的总图纸，是系统的灵魂所在。是编 码的依托。我们在设计时，从纵向界定出了表现层和巾问逻辑层的功能边界划分， 从横向则按功能模块细化设计了模块的具体实现。为将来实现面向对象的编码和 代码的重用打下了良好的基础。其中在逻辑建模中实现了业务层e j b 的设计，这 也是建模的核心所在。 4 2r a t i o n a i r o s eu m l 柔性开发模型 r a ti o n a lr o s eu m l 柔性软件开发模型，是指在软件开发过程中，根据需求 工程的牵引，首先建立软件系统的顶层模型，并对其进行模拟、分析和调整。然 后。将顶层模型自顶向下地进行分解，建立该系统各个子系统的模型，对这些子 模型进行模拟、分析和调整。将子模型的模拟结果，逐次代入上层，再对该上层 模型进一步进行模拟、分析和调整，如有不适，则进行修改。因此整个建模过程 是个“自顶向下建模，由底向上修改”的反复迭代的过程脚。简言之，柔性软 件开发过程是一个在需求牵引下自顶向下分层细化地建模，然后按照“t 型技 术”，通过对模型的虚拟执行，由下向上地逐层上移修改，直至各层的模拟结果 都满足需求为止。 准确、快速地使用口e e 技术刨建管理信息系统 j ”二。w# m、 篁i 0 i 。：二一 一 q ：i 磊 m i # ”p ”# ：。；j 。一。 。、托亳譬拳一。： l 电 。 ， ( 图4 1 柔性软件开发模型) 代码的生成建立在模型正确性的基础上同时考虑到刑需求修改的灵活性和 快速响应能力，实施能够反馈修改的“闭环开发”。即不仪能支持从模型到代码 的自动生成，将新的模型转换为代码，还能支持从代码到模型的逆向变换，将原 有的代码转化成模型，进行再次分析、修改和调整以及新一轮的开发，从而为增 景式开发提供支持。这样不仅能做到分阶段提交产品，也提高了对用户需求变化 的响应速度和应燮能力，以满足用户4 i 断变化的新的谢水。r a t i o n a lr o s e 烂 个能支持系统建模、系统模拟和系统生成的“闭环式开发”的集成化支持环境。 。y j 一一+口龋“t m $ 一一、， 。鬻蒜譬麓：一“、 0 ，一蠹；? o 。 气一， “。3 ，4 ”$ l + k 蠛3 口t ( 图4 2 基于r a t i o n a lr o s e 的u m l 开发模型用例图) 4 3 逻辑视图 r o s e 模型的四个视图是u s ec a s e 视图 d e p o y m e n t 视图。每个视图针对小同对象， 开发人员可以构造系统的详细设计。 、l o g i c a l 视图、c o m p o n e n t 视图和 具有不同用途。利用l o g i c a l 视图 准确、快速地使用j 2 e e 技术创建管理信息系统 ( 图4 3 逻辑视图整体结构) 在r o s e 建模中，我l r j , u 用模型和视图处理软件系统的复杂性。在这里，模 型是指视图的集合或者视图可以看作模型的一个方面( 或视点) 。i e e e 标准将视 图归结于“提出一个或多个系统利益关联( t a k e h o l d e r ) 的利害关系”【9 】。对于利 益关联者，我们定义为分享系统注意或兴趣个体或组( 例如，开发者用户消 费者等等) 。应用于我们的语境，视图是模型的片段，它也要细小到我们能够理 解，但是也包含关于特定关系的关联信息。在r o s e 建模巾，视图本质上是图形 的，且往往通过框图来实现。视图( 例如类或序列圈) 服务于下列意图： 抽象并简化模型； 使得不同的利益关联者协调工作； 为不同解释进行补充( 不同观众利益相关者) ； 提取关于特定关联的相关信息； 因此将会用到什么类型的视图以及什么时候用到它们是强烈依赖于唰个人 正在使用和需要完成的相关任务。在系统设计主要强调的是充分表达出设计者的 设计思想和能够有效地指导开发者实现编码，所以，逻辑视图就成了殴计阶段的 重中之重。 逻辑视图关注系统如何实现用例图中提出的功能。它提供系统的详细图形， 描述组件间如何关联。除了其他内容外，逻辑视图还包括需要的特定类，利用这 些细节元素，开发人员可以构造系统的详细设计。逻辑视图关注的焦点是系统的 逻辑结构。在这个视图中，要标识系统组件检查系统的信息和功能，检查组件 之间的关系。这里重复使用是一个主要目的。通过认真指出类的信息和行为，组 合类，以及检查类和包之间的关系，就可以确定重复使用的类和包。完成多个项 目后，你就可以将新类和包加进重复使用库中。今后的项目可以组装现有的类和 包，而不必一切从头开始”“。几乎所有的开发人员都会用到逻辑视图中的信息， 准确、快速地使用j 2 旺技术u 建管理信息系统 分析人员利用它确定代码会实现哪些业务要求，生成了什么类，每个类所包含的 信息和功能。质量保证人员通过类、包和c l a s s 框图看到系统中的模块、组件有 哪些，哪些需要测试。项目管理员通过类和框图确定系统构造是否合理，并估计 系统的复杂程度。架构师更关心系统的总体结构，因为架构师要负责保证系统结 构稳定，考虑重复使用，使系统能灵活地适应需求变化。 皓_ t l - 晒哪p r “l h r ( 图4 4 逻辑视图示例) 4 4 使用r o s e 进行系统设计的过程 在创建和革新一个软件系统之前，为它开发个模型同为一幢大厦描绘副 设计图纸一样重要。好的模型对于工程项目组之间交流是非常重要的，它能保证 体系结构的健壮性。随着系统复杂度的增加，好的建模技术也变得越发重要。 利用r o s e 建模进行系统设计，要经历以下几个过程： 识别应用程序的需求，规划事物进程i 把需求影射到抽象的事物对象，识别和应用设计范本，创建使用图例； 识别和设计事物对象，或者把业务分布到三层( t h r e e t i e r e d ) 业务模型上。 从以上的过程中我们可以归纳出：利用r o s e 模型进行详细的可指导开发的 系统设计，核心步骤有两个。第步是通过总结详细的业务蚬则和丁作流棵分析， 实现对业务场景的描述：第= _ i 步是在业务场景描述的基础上做出逻辑视图。其一 一 第一步是和用例模型密切市目关的在用例模型中有业务建模，而业务建模就是进 行业务场景描述的指导模型。虽然用例模型可以为你解决问题提供个基础，小 过离实现还是很远。在设计期间，你必须考虑到所采用的技术带来的额外限制和 准确、快速地使用j 2 e e 挫术创建管理信息系统 需求，并且尝试映射解决方案到最优化的实现。在第二步开发逻辑视图的过程q t ， 要考虑到逻辑模型的作用是作为一个出发点，在做各种关系和实体的敬计中，处 处考虑到这些元素向e j b 的映射】。例如， 类可以很好地映射 到s e s s i o nb e a n s 。在这个方面大家可以参阅s u n 公司的 j 2 e b 层的实现模型和 s u n 的“m o d e l2 ”参考体系对应关系。 在逻辑视图中，对于内部元素是如何交互来满足系统的功能需求，以及它 们是如何相关，要提供了一个初始的、高级别的定义。逻辑视图是比较抽象，但 在系统开发阶段中，它是一个有用的工具。 在e j b 方面，除了可为e j b 2 0 中的全部三种e j b 产生代码外( 以及符合 e j b l 1 的e j b ) ，r a t i o n a lr o s e 还提供了一些特性以简化e j b 的开发。例如， 在开发e j b 时其中一