对企业级Java操纵程序及其安置举行建模[Java编程]

择要

目前,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层,图就开始超越其消息的范围.这个图阐明了以下内容:

这个布置中总共有4台物理机械:2台是Sun Fire v40z机械,别的2台数据库服务器是Dell PowerEdge 6850.显示了PowerEdge的IP地址,但是SunFire机械的IP地址则没有显示.这是因为SunFire机械支持虚拟服务器.对这个图来说,重要的是虚拟服务器的IP地址,而不是物理主机的IP.

总共在SunFire机械中成立了7台虚拟机械.这些虚拟机械与Java VM无关.它们是功效完好的机械,具有自己的IP地址.Java VM可以运行在这些虚拟机械中.

一个WebLogic Platform域包含了一台管理服务器和两个集群.

WebPortal集群包含4台服务器.还可以看到将每台服务器衔接到虚拟机械的布置线.这使得SCM若何成立集群的历程变得很清楚（至少是在构造化的级别上）.

名为BackEnd的第二个集群,它包含2台WebLogic服务器,还可看到这两台服务器布置到虚拟机械上的位置.

一个包含客户情势的Oracle数据库,运行在Dell PowerEdge 6850机械上.

一个硬件负载均衡器,它把URL“customer.bea.com”转换为WebLogic Portal服务器所利用的呼应IP地址.

最后,我在底部为实际布置映射定义了一个图例,它会供应有关已布置的实例范例的附加细节.

在这幅图中,我供应了大量对开辟、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部门的差别团队之间关于这些细节的交流,并供应一些尺度和办法来帮忙您越发有效地管理软件系统.记着,建模只是一种帮助性工作,真正重要的还是可以履行的软件系统.