|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
因为能用到多少功能就用多少,不能用就不用!总的来说:要简单要性能好,可以不用框架。你说java复杂,就是因为你把java(j2ee)与这些框架混在了一起。j2ee|项目|转换第3部分:转换到体系模子
StevenFranklin
软件计划师和历程专家
2004年3月
本文将持续经由过程这个周全的使用RUP和其他Rational工具的样例项目来先容创立项目标RationalRose模子,本文中我们将入手下手创立代表“今朝”营业情形的体系模子,并将此营业模子转换成为“未来”的体系模子。
这个第3部分文章重点的先容了在RationalRose中完成的初期建模举动。起首我们来对ASDI现有的(“asis”)体系举行建模,经由过程营业用例和营业对象能够显现以后事变是怎样事情的。我们将从这个反应现有体系的模子创立出切合ASDI新的需求的体系模子,而且将这个体系模子作为创建软件的基本。
陪伴着这本文有2个演讲稿(来自于Rational用户年夜会2000)这里会商了以下主题:YvesHolvoet的“保护剖析模子与多个计划模子的同步”和RobertBretall的“布局化你的RationalRose模子”。后一个演讲稿附带一个Rose模子。
第3部分快照
第3部分所利用的工具和手艺:
Rational一致历程(RUP)―引导软件开辟历程,对项目标每一个阶段供应倡议的历程和事情产品
RationalRose企业版―为了创立“今朝的”营业模子(利用一致建模言语(UML))并在剖析线索的基本上入手下手创立“未来的”体系模子
被创立的大概被更新的事情产品:
营业用例模子(RationalRose)―被创立用来代表体系“今朝的”营业功效
营业对象模子(RationalRose)―被创立用来捕捉体系“今朝的”营业功效是怎样被实行的:实体之间的合作、实体之间的交互和相干的历程和产品
用例模子(RationalRose)―不克不及完整的暗示营业用例模子;被创立用来猎取具体的体系“未来的”实行功效(它作为构建软件的基本)
捕捉“今朝的”体系
有太多新的和被改善了的IT体系在已有体系被懂得之前被启动。乃至是当已有体系还缺少IT组件的时分,有需要在可选的和改善的计划被倡议之前对以后的营业举动情形举行剖析。但是人们老是跳过大概草草的完成这一步,可是这做会招致以下的成绩:
对客户的需求的了解不敷充实,减慢接上去的剖析
对需求的不准确的注释
不克不及正确的估量新计划所带来的影响,招致当软件被托付给客户利用时对客户的事情发生伟大的震惊和请求客户完整改动现有的事情流程
纷歧致的术语和观点,招致与客户之间发生交换上的曲解和凌乱
创立一个营业模子以捕捉“今朝的”体系的情形能够长短常疾速的义务并可以发生有效的剖析线索,这些线索将简化对“未来的”体系的界说。在创立这个模子中可以对我们有匡助的一件事变是事情形态(SOW)。固然SOW次要用来形貌“未来的”体系的需求,可是它也供应了ASDI确当前营业流程的有效的背景信息。
在Rational一致历程(RUP)初始阶段部分存在一系列的用于营业建模的办法(也是就在我们项目标第1阶段)。与ASDI一同创立一个IT体系,我们必要一个“今朝的”模子以捕捉文件的流转和他们确当前体系的交互举动。我们在RationalRose中创立了以下RUP事情产品作为营业建模事情的部分:
营业用例模子,建模“今朝的”营业功效。
营业对象模子(偶然也称作范畴模子),对实行营业功效的对象和这些对象之间的干系举行建模。一个营业对象模子大概会显现一个发票是怎样被天生并怎样在体系中举行流转,大概显现了一个购置哀求的入手下手到停止的历程。
注重在之前的一些项目中,我们跳过了营业建模的步骤,由于我们是创建一个全新的体系,大概是由于我们已十分好的懂得了已有的营业模子。可是由于我们对ASDI的营业是生疏的,因而我们以为这一步是非常主要的。
我们也思索到开辟一个营业术语表(利用RUP供应的事情产品模板),可是我们发明我们的术语中的年夜多半是相称尺度和明白的,并且这些术语在我们的营业对象模子中被充实的捕捉了。加倍庞大大概严厉的项目将会从创立营业术语表中获益以确保在一切产品中的分歧性。
当我们利用RationalRose创立我们的模子时,我们感应仅仅复杂的创立图是不敷的。我们发明仅仅经由过程图的体例表达模子对图的创立者是简单了解的,但对图的浏览者来讲倒是很难读懂的,因而我们为每个图附加了文档(经由过程在图上点击并在文档窗口输出文本)。我们也为图中的每项供应了文档―用例、营业对象、用户大概其他项―用一到两行的笔墨来形貌每项的目标。
创立模子
我们从一个入手下手点来创立我们的新模子文件(ASDI.mdl),我们利用切合RUP中界说的布局的Rose模板(见)。由于我们在RUP中完成大批的事情,这将使我们事情的很好。RUP的模子模板是能够在启动Rose时看到的,我们能够经由过程导游来会见的几个模板之一,大概你也能够在Rose使用程序的Frameworks目次中找到他们。
:RUP模子模板
我们对模板的布局做了一些修改以切合我们的必要和选择。比方,我们间接做了一下的修正:
取代跟踪被包含的与其他用例分别的用例,我们将这些用例构造到逻辑上包括他们的功效的包中。我们以为能够将原型和RationalSODA的呈报才能分离起来,如许当有需要时能够同意我们简单的辨认被包括的用例。
我们删除在逻辑视图(LogicalView)下的剖析模子。你能够浏览YvesHolvoet的演讲稿来懂得剖析框架重用和剖析/计划用例的正反概念的会商。我们决意一个分层的剖析模子是没有需要的,由于我们其实不希冀ADSI体系中的多半营业模子能够在未来的项目中被重用。相反,我们同意用例在全部项目标过程当中失掉退化。
我们起首经由过程营业组件对计划模子举行了分别,然后再对他们举行条理的分别(这两个义务一般是分歧的),而不是一入手下手就对模子举行条理分别。
接上去我们必需增加一个企图(schema)地区到模子中以使数据库架构师能够跟踪数据建模的事情。
办理模子
将Rose模子依照分歧团队成员的义务分摊到包中一般是必要消费必定的工夫的。包的布局应当被创立的使在团队成员之间共享职责绝对的复杂一些,这能够经由过程分别体系成为分歧的部分来完成:剖析(好比,贯串用例和营业对象),系统架构和计划。
我们的团队固然不是很年夜,但我们仍是要思索到在模子之上的合作成绩。我有几个RationalRose的浮动的允许证,这充足我们一切的人同时会见模子,可是我们也必要使我们可以并发的会见模子的某一部分。因而我们利用Rose的“单位把持”的特征以对模子举行得当的分化。
在我们的团队的构造布局中的脚色(如在第2部分被形貌的)这些脚色所具有的对模子各部分的输出和更新的求全谴责被显现在表1中。因而,团队中的其他成员,好比低级的开辟职员和项目工程师将只具有对模子举行会见的权限以完成他们的开辟事情。
脚色输出/更新职责
组长/初级剖析职员打保证理
用例模子(营业和体系)
营业对象模子
系统架构
计划
初级开辟职员系统架构
计划
数据库架构师系统架构
企图(Schema)计划
表1:模子输出/更新职责
我们对模子举行了分化,如中显现的Rose图。此时这个模子的布局服务于我们必要,由于我们有3团体间接的保护这个模子。未来,当团队和项目渐渐扩展时,这个模子布局能够被简单的分化为更多的*.cat文件。
:模子分化
关于分化Rose模子的分外信息能够在RobertBretall的演讲稿中找到。这里只指出来自于它的模子布局会商中的几个有代价的事变:
最好不要将内容放在模子的顶层。(在我们的案例中,一切的信息都被放到了被把持的*.cat文件中。)
假如你企图在未来的项目中重用你的体系模子的某些部分,思索对剖析模子举行分层。(你也能够在YvesHolvoet演讲稿中找到更多相干的信息。)
假如模子的布局是依据RUP的引导创立的,Rational的工具(SoDA,REI剧本等)将加倍无效的与模子举行交互。
利用RationalRose分化模子成为分别的*.cat文件是很简单的。如所示,我们复杂的右键点击我们想在独自的文件中把持的包;然后在高低文菜单当选择Units>ControlUse-CaseModel,这使我们能够把持这个包和这个包中的一切子子项。稍后在项目中,我们将重组一些*.cat文件成为几个更小的被把持的包以进一步的公布建模的事情产品。
:在Rose中创立分别的*.cat文件
建模用户和接口
一个脚色(actor)是与体系交互的外界的人大概事物;这既能够是利用体系的人,也能够是其他的接口范例。建模体系的用户和接口和他们之间的依附长短常有效的;它不单单能够给你一个体系的完全实体,并且也能够供应给你关于未来的平安性和脚色建模事情的优秀信息。
显现了我们怎样在Rose中将脚色容进我们的营业模子傍边―特别是,在一个与客户服务相干的用例图中,这个用例图摘自我们的营业用例模子。两个特别的原型类被利用:营业脚色和营业用例。Rose能够基于原型分派自界说的图标,而且我们选择这个办法为用例和脚色分派表面略有分歧的图标―加了一条斜线―由于我们以为区分用于构建软件的体系模子与营业模子是主要的。
:客户服务的用例模子摘录
当我们将营业用例模子充分起来时,关于营业对象模子来讲将会呈现一系列好的候选对象。固然创立一个“今朝的”体系的营业模子看起来要消费大批的事情(次要的事情量是天生图),可是我们以为它是值得的。在我们已往的“今朝的”模子中,已包括了大批的在实行室事情簿中的正文和正式的手艺正文。为了失掉已有营业流程的加倍明晰和完全的视图,应当在消费一些工夫在Rose中捕捉这个信息。
了解体系交互
偶然人们会将重点都放到了体系的某个独自的部分上,但实践上体系各部分之间的交互也长短常主要的。充实的思索全部体系部分的交互将使体系各部分之间集成的个性和大概性加倍分明。这是为何我们厥后利用交互图的缘故原由之一(显现体系各部分间的交互)以考证我们的计划;这对在剖析和计划中辨认流程和固有的缺口长短常关头的。
在项目标初期我们存眷的交互:
营业用例对脚色(甚么样的个别和接口会见到我们辨认出来的各类营业义务)
营业对象对营业对象(各个营业对象之间是怎样相互交互的,和他们共享信息的品种)
用例对用例(义务相互之间的依附,和被必定的历程共享的公用义务)
我们消费了一些工夫在Rose中捕捉我们对以后营业构造和历程的了解,了局是天生了关于我们了解现有体系十分有效的营业对象模子。在对象模子中的图(在中显现的是个中的一个)相似于尺度的类图、除他们利用了特别的原型类:营业实体、营业把持和营业脚色。营业实体暗示主动的范畴对象好比发票大概呈报,而营业把持是实行功效的对象,能够暗示报警大概机器的感化。(营业脚色在之前已被会商了。)
:营业对象模子摘录
我们在营业用例建模以后很快入手下手营业对象建模。营业用例的申明笔墨断定了一系列符合的营业对象。假如是超过多个用例的对象,好比“购置哀求”和“产物”、“产物行列”和“运输行列”是被辨认的营业范畴的关头对象。偶然假如我们意想到它是分歧适的大概已被其他对象掩盖到了,我们将删除这个营业对象。经由过程这类办法,能够疾速的在义务(用例)和事物(营业对象)中选择与ASDI营业相干的营业对象。
在某些情形下,营业对象模子将演变成体系类。这关于实体对象来讲基础上是准确的,实体对象一般被映照为容器类大概是数据库表。在其他一些情形下,营业对象模子复杂的作为一个为了解客户范畴的援用的分离点来利用。我们确认客户已完整了解了图形化的标记和每一个图的内容,由于他们的反省和同意是关头的。
总而言之,我们消费了大批的工夫在营业建模的事情上。这其实不必定是一流的大概是完整的,可是关于我们来讲应当是可以对以后的营业流程有一个充足的熟悉。在项目标第一个大概两个月后,我们将很少的说起营业模子,可是我们以为它是值得消费工夫的,由于它是构成“将来的”体系的体系模子的一个需要的步骤。当一个新成员到场到我们的团队时,我们能够经由过程扫瞄营业模子来匡助他们来了解新的范畴;但是,一旦对它熟习了,营业模子将很少再被检察,除非是分析术语。
将SOW转换成用例
企图“未来的”体系,我们必要将已用笔墨情势暗示的SOW需求(在第2部分中被会商的)转换成为经由深图远虑的用例。换句话说,经由过程对“今朝的”体系的营业用例的创立(就像早些时分所会商的),我们筹办为“未来的”体系细化这些用例。这将不是一个疾速的步骤,可是它履历凌驾两周的工夫。(在RUP的术语中,这个转换反应了一个从初始阶段到细化阶段的慢慢转化历程。)我们在营业建模上所作的事情,取得了以后体系的履历并将它的功效分别进了营业用例,这对我十分有匡助。(RUP的文档显现了从营业用例模子到营业对象模子和体系用例模子的演进;我们发明这长短常准确和有匡助的。)
我们其实不忧虑映照SOW需求到“今朝的”体系营业用例的缘故原由是SOW需求中的很多在以后的体系中是不存在的。我们初期所创立的营业模子只不外是一个一时的产品,它用于我们确保我们的团队了解ASDI确当前体系。
用例对笔墨申明
一系列的事情簿和事情产品(包含那些前面被列的“援用和其他资本”)注释了用例建模和了解需求的优点。我们发明很多被说起的优点是实在的,固然界说用例的内容不是噜苏的义务。与优秀的笔墨申明比拟,假如用例没有被优秀的计划,关于你来讲他们固然没有效的。
这里是一些入手下手创立用例时的曲解:
用例被创立的太年夜大概太小
用例在超过团队的情形下纷歧致
没有对用例分组的包举行优秀的企图
分歧理的对模子的会见举行把持,招致在团队剖析合作的过程当中产生抵触
过于仔细的界说用例,在用例进进原型、计划和开辟义务之前就界说每件事变
界说用例时过于复杂,使需求被工程团队能够有浩瀚的注释
了局,我们决意用例建模尺度和指南必要被组长界说。这些包含上面的指南:
用例典范的猎取10到20天的开辟和单位测试。这不是RUP的划定规矩,可是关于我们来讲这是一个好的划定规矩。假如我们发明用例比这个尺度过年夜大概太小,我们将消费分外的工夫反省他们以包管他们有符合的局限。
工程团队必需在初期对包的布局告竣分歧。这个布局大概会变更,可是变更应当起首与团队举行会商。
当决意甚么应当包含在我们的用例中时,我们应当服从在文章中指出的指南FineTuningRosetoComplementYourProcess:
标识―称号、独一的ID、原型、可跟踪需乞降简介
形貌―入手下手形态、停止形态支流程形貌和变动
正文―一时的“便签簿”正文
从“今朝的”到“未来的”演进
当我们从“今朝的”转移到“未来的”时,我们的很多营业脚色被演变成了体系中实在的用户和接口,固然成心义的重构是需要的。这是天然的,由于当从头界说其他脚色时新的IT计划一致了原本的一些脚色。一些营业实体作为笼统的观点消散了,而其他的一些经由过程企图(schema)大概具体的计划被映照成了类。
在到中显现了我们初期事情发生的关于“未来的”体系的用例模子的一部分。经由过程图形、合作图和时序图和进一步的具体剖析的匡助,它将跟着工夫推移而成熟。
:初期的脚色模子
:中心的客户服务用例
:客户订单用例
:体系办理用例
就像RUP的形貌,“用例建模的最主要的目标是与客户大概终极用户相同体系的举动。”但是,增添庞大性能够招致我们的客户大概感到不恬逸的风险,我们发明当我们充分用例时,在用例中引进更初级的包括和扩大干系是很有代价的。在具体的反省我们的用例模子时,被包括和扩大的用例频仍的呈现。我们发明乃至在我们了解了体系的(包含用户)外界接口视图,经由过程包括和扩大用例来分组功效发生在主要的企图、架构和测试中的优点。但是,在我们看到客户对反省这些初级的干系没有信念时,我们偶然会将被包含和扩大的用例从反省的包中拿失落。
总结
我们如今已有了一个形貌了ASDI营业中已有历程和实体的画面,而且在对将被构建体系的义务和脚色的体系建模上有一个优秀的入手下手。固然另有一些在团队内的关于跳过营业建模事情的会商,可是我们以为我们的事情将收到报答。其他的优点是,它使客户简单的以一种恬逸的和绝对非手艺的级别进进用例。
分歧项目之间的用例建模有着明显的分歧;用例的界说、用例的干系、具体的水平等等都是常常被争辩的。最初我们发明当我们向客户展现我们的用例模子时,分歧的并频仍的反省是乐成的关头。
企图将来
我们必要失掉手艺上的微弱停顿。客户正向我们讨取比我们如今能够供应的更多的有关用户界面、代码原型和工具选择的信息。我们必需入手下手供应屏幕的摹拟并入手下手思索得当手艺的选择;如今主要的是入手下手利用加倍实践的、手艺的产品和购置工具(特别是假如我们必要更多的培训)。
固然我们还没有入手下手进进系统架构阶段,可是我们晓得体系必需是基于Web的而且是跨平台的,同时从原型到企业级计划都如果可扩大的。我们已进修了J2EE,而且ASDI招聘的IT司理也首选这个手艺平台。因而,我们以为入手下手探究J2EE的本钱和才能是明智的。我们的团队在这个范畴不必要太多的培训,这是别的一个要素。数据的存储应当被更多的思索,但是,由于IT司理尽力的推许面向对象的数据库(OODB)计划。由于我们对干系型数据库加倍外行,这对我们来讲是一个困难的旅程,可是我们仍是批准了考查OODB的计划。
我们非正式的与我们的客户检察了我们的一切事情产品,可是是时分举行正式的反省了。在接上去的几周中,我们将创建我们的RationalSoDA模板以便我们供应我们的第一个正式的托付:具体的软件需求。我们批准这个文档应当包含用例和非功效需求(牢靠性、可用性等等)。
我们的用例入手下手不乱了,入手下手指明在对SOW符合的可跟踪的地址。我们必要用RationalRequisitePro来确保保护SOW与我们的用例之间的映照。
我们接上去的偏向,应当是:
手艺上的停顿,特别是工具和手艺的选择
创建需要的RationalSoDA模板以天生我们的第一个正式的文档
简练我们的用例以增加可跟踪性到SOW
次要风险
我们仍旧以为工夫长短常紧的,而且存在着工夫进度大概预算的一些收支―而且我们的风险列表还在增加,乃至我们还没有入手下手任何的仔细的手艺探究。个中有以下新的风险:
过量的涉众合作,偶然在体系的功效上会有矛度的定见。我们必要与客户廓清以为的历程。
假设我们选择OODB计划,我们必需扩大我们的深度,因而这会发生强制的培训和对工程团队的工夫进度发生不断定性。
客户心急的请求第一阶段的主要的正式的和具体的事情产品,而我们假想的是这只是个观点性的证明。我们仍旧与客户针对RUP举行相同,并全力在RUP中的事情产品和标记中增添他们恬逸感觉。
再举这样一个例子:如果你想对一个数字取绝对值,你会怎么做呢?java的做法是intc=Math.abs(-166);而ruby的做法是:c=-166.abs。呵呵,这就看出了java与ruby的区别。 |
|