第5章面向对象方法-RUP.ppt
- 文档编号:18627885
- 上传时间:2023-08-21
- 格式:PPT
- 页数:220
- 大小:1.17MB
第5章面向对象方法-RUP.ppt
《第5章面向对象方法-RUP.ppt》由会员分享,可在线阅读,更多相关《第5章面向对象方法-RUP.ppt(220页珍藏版)》请在冰点文库上搜索。
第5章面向对象方法-RUP,掌握在创建系统/产品需求获取模型、需求分析模型和设计模型中的基本活动和任务;能应用RUP建立小型简单系统的用况模型、需求分析模型;了解RUP设计模型的基本结构,及在设计中如何处理共性的非功能需求。
本章内容及要求:
统一软件过程(RUP)1)概述
(1)UML是一种可视化的建模语言,而不是一种特定的软件开发方法学。
作为一种软件开发方法学,为了支持软件开发活动,例如软件设计,至少涉及三方面的内容:
一是应定义设计抽象层,即给出该层的一些术语,二是应给出该层的模型表达工具,三是应给出如何把需求层的模型映射为设计层的模型,即过程。
UML仅包括前两方面的内容,即给出了一些可用于定义软件开发各抽象层的术语(符号),给出了各层表达模型的工具。
(2)RUP的本质及特点本质:
是“一般的过程框架”.即:
-为软件开发,进行不同抽象层之间“映射”,安排其开发活动的次序,指定任务和需要开发的制品,提供了指导;-为对项目中的制品和活动进行监控与度量,提供了相应的准则。
换言之,RUP比较完整地定义了将用户需求转换成产品所需要的活动集,并提供了活动指南以及对产生相关文档的要求。
适用于:
大多数软件系统的开发,涉及-不同应用领域-不同类型的组织-不同的技能水平-不同的项目规模可见,RUP和UML是“统一”的方法学。
RUP的突出特点是一种以用况(UseCase)为驱动的、以体系结构为中心的、迭代、增量式开发。
以用况为驱动意指在系统的生存周期中,以用况作为基础,驱动有关人员对所要建立系统的功能需求进行交流,驱动系统分析、设计、实现和测试等活动,包括制定计划、分配任务、监控执行和进行测试等,并将它们有机地组合为一体,使各个阶段中都可以回溯到用户的实际需求。
USECASE,分析,输入,设计,实现,跟踪,输入,跟踪,输入,跟踪,输入,输入,测试,输入,跟踪,输入,从USECASE模型的视觉,从分析模型的视觉,从设计模型的视觉,从实现模型的视觉,从部署模型的视觉,给出,体系结构,描述,以体系结构为中心意指在系统的生存周期中,开发的任何阶段(RUP规定了四个阶段,即初始阶段、细化阶段、构造阶段和移交阶段)都要给出相关模型视角下的有关体系结构的描述,作为构思、构造、管理和改善系统的主要制品。
系统体系结构是对系统语义的概括表述,内含一些决策,主要涉及软件系统的组织(包括构成系统的结构元素、各元素的接口、由元素间的各种协作所描述的各元素行为、由结构元素和行为元素构成的子系统、相关的系统功能和性能、其他约束等)以及支持这种组织的体系结构风格。
系统体系结构对所有与项目有关人员来说都是能够理解的,因此便于用户和其他关注者对系统达到共识,以便建立和控制系统的开发、复用和演化。
因此,在系统体系结构描述中,应关注子系统、构件、接口、协作、关系和节点等重要模型元素,而忽略其他细节。
具体地说,体系结构描述应根据相关模型的视角:
展示对体系结构有意义上的用况、子系统(不涉及子系统的隐含成分和私有成分,及其变种)、接口、类(主要为主动类)、构件、节点和协作;展示对系统体系结构有意义的非功能需求,例如性能、安全、分布和并发等;简述相关的平台、遗产、所用的商业软件、框架和模板机制等;以及各种体系结构模式。
例如,为获得系统用况模型视角下的系统体系结构描述,应:
在一般性地了解系统用况之后,勾画与特定用况和平台无关的系统体系结构轮廓。
关注一些关键用况。
所谓关键用况,是指那些有助于降低最大风险的用况,对系统用户来说是最重要的用况,以及有助于实现所有重要的功能而不遗留任何重大问题的用况。
给出每一关键用况的描述。
其中应考虑软件需求、中间件、遗产系统和非功能性需求等,以便产生更加成熟的用况和更多的系统体系结构成分。
对以上三步进行迭代,得到一个文档化的体系结构基线。
并在此基础上,形成一个稳定的系统体系结构描述。
阶段,核心工作流,迭代、增量式开发意指通过开发活动的迭代,不断地产生相应的增量。
在RUP中,规定了四个开发阶段:
初始阶段(theinceptionphase)、精化阶段(theelaborationphase)、构造阶段(theconstructionphase)和移交阶段(thetransitionphase),每次迭代都要按照专门的计划和评估标准,通过一组明确的活动,产生一个内部的或外部的发布版本。
两次相邻迭代所得到的发布版本之差,称为一个增量,因此增量是系统中一个较小的、可管理的部分(一个或几个构造块)。
贯穿整个生存周期的迭代,形成了项目开发的一些里程碑。
-每一阶段的结束,是项目的一个主里程碑(共四个),产生系统的一个体系结构基线,即模型集合所处的当时状态。
-主里程碑是管理者与开发者的同步点,以决定是否继续进行项目,确定项目的进度、预算和需求等。
-在四个阶段中的每一次迭代的结束,是一个次里程碑,产生一个增量。
次里程碑是如何进行后续迭代的决策点。
-系统体系结构基线的建立,是精化阶段的一个目标,期间通过不断演化,到该阶段末得到这一基线,是系统的“骨架”.-该基线包括早期版本的用况模型、分析模型、设计模型、部署模型、实现模型和测试模型,但此时用况模型和分析模型较为成熟。
-在实践中,体系结构描述和体系结构基线往往同时开发,以便指导整个软件开发的生命周期。
期间,体系结构描述不断更新,以便反映体系结构基线的变化。
注:
该基线应该是坚实的,因为它是开发人员当时和将来进行开发时所要遵循的标准;并应与最终系统(对客户发布的产品)几乎具有同样的骨架。
但最后形成的体系结构基线是系统各种模型和各模型视角下体系结构描述的一个集合。
综上可知,RUP的迭代增量式开发,是演化模型的一个变体,即规定了“大”的迭代数目-四阶段,并规定了每次迭代的目标。
初始阶段的基本目标是:
获得与特定用况和平台无关的系统体系结构轮廓,以此建立产品功能范围;编制初始的业务实例,从业务角度指出该项目的价值,减少项目主要的错误风险。
简言之,其目标是:
建立该项目的生存周期目标(objectives),精化阶段的基本目标是:
通过捕获并描述系统的大部分需求(一些关键用况),建立系统体系结构基线的第一个版本,主要包括用况模型和分析模型,减少次要的错误风险.从而到该阶段末,就能够估算成本、进度,并能详细地规划构造阶段。
构造阶段的基本目标是:
通过演化,形成最终的系统体系结构基线(包括系统的各种模型和各模型视角下体系结构描述);开发了完整的系统,确保产品可以开始向客户交付,即具有初始操作能力。
交付阶段的基本目标是:
确保有一个实在的产品,发布给用户群。
期间,培训用户如何使用该软件。
需求,设计,编码,测试,集成,需求,设计,编码,测试,集成,开发,反馈,开发,反馈,.,核心系统开发,第二次迭代,注:
这4个阶段是演化模型的一个变体。
演化模型(Evolutionarymodel)-一种迭代风范是一种有弹性的过程模式,由一些小的开发步组成,每一步历经需求分析、设计、实现和验证,产生软件产品的一个增量。
通过这些迭代,完成最终软件产品的开发。
针对事先不能完整地定义需求针对用户的核心需求,开发核心系统根据用户的反馈,实施活动的迭代,演化模型还具有以下优点:
在需求不能予以规约时,可以使用这一演化模型。
用户可以通过运行系统的实践,对需求进行改进。
与瀑布模型相比,需要更多用户/获取方的参与。
缺点有:
演化模型的使用,需要有力的管理。
演化模型的使用很容易成为不编写需求或设计文档的借口,即使很好地理解了需求或设计。
用户/获取方不易理解演化模型的自然属性,因此当结果不够理想时,可能产生抱怨。
2)需求获取的目标及其基本途径需求获取面临的挑战问题空间理解人与人之间的交流需求的不断变化,需求获取技术特征,方便通讯(使用易于理解的语言)提供定义系统边界的方法提供划分、抽象、投影等方法允许采用多种可供选择的设计方法适应需求的变化支持使用问题空间的术语,思考问题和编制文档,
(1)需求获取的目标对大系统的开发来说,需求一般包括需求获取和需求分析需求获取的目标是:
客观问题(系统),系统需求获取模型,形成-涉及:
不同概念和不同处理逻辑,体系结构描述-USECASE模型,
(2)实现需求获取目标的基本途径实现实际问题到软件开发需求获取层的映射,即从软件开发的角度-实现第一次抽象。
其中至少涉及以下3个问题:
如何定义需求获取层,即给出该层的术语;如何确定模型表示工具;如何映射。
实际问题,需求获取层,模型表示工具,需求获取层的术语(概念)及表达模型的工具术语:
USECASEactor以及4个表达关系的概念:
关联、包含、扩展、泛化工具:
USECASE图,实际问题,模型表示工具-USECASE图,体系结构描述-USECASE模型,如何映射-需求工作流总体来说,需求工作流包括以下四步,但它们并非是严格分离的。
要做的工作产生的制品-列出候选的需求特征(Feature)列表-理解系统语境领域模型或业务模型-捕获功能需求Usecase模型-捕获非功能需求补充需求或针对一些特定需求的usecases,其中:
特征(Feature)列表特征:
一个新的项(item)及相关的简要描述(shrinks),称为特征(feature)。
应用系统,潜在的抽象层,例如:
按学科计算每一学生的期末考试平均成绩。
统计2科以上不及格的人数。
给出各分段(0-60,60-85,85-100)的人数分布情况。
feature,特征作为需求,被转换为其它制品:
应用系统,潜在的抽象层(特征层),一个抽象层(USECASE层),USECASE1,USECASE,USECASE2,USECASE3,制品:
USECASE模型,规约,规约,形成,Actor,关联,关于特征的几点说明:
-每一特征有一个简短的名字和简要的说明或定义。
-每一特征还有一组对规划有意义的信息,可以包括:
状态(Status),例如,提交,批准,确认是否是组成的等。
估算的实现成本。
(所需的资源类型和人/时)。
优先级(Priority)(e.g.,critical,important,orancillary)。
实现中相联的风险等级。
业务模型或领域模型领域模型作用:
领域模型捕获了系统语境中的一些重要对象类型。
其中领域对象表示系统工作环境中存在的事物或发生的事件一般来说,领域类以三种形态出现:
业务对象:
表示那些被业务所操纵(manipulate)的事物(thing),例如定单,帐目和合同等实在对象(Real-worldobjects)和概念:
例如飞机,火箭等事件(Events):
例如飞机到达,飞机起飞等一般来说,领域模型是以类图予以描述的。
Orderdateofsubmissiondeliveryaddress,Itemdescriptionpicturecost,Invoiceamountdateofsubmissionlastdateofpayment,Accountbalanceowner,1.*payable,1.*,buyer1,seller1,注:
领域模型中的一个类图,捕获了该系统语境中的一些重要的概念.,例如:
领域类Order,Invoice,Item,andAccount,业务模型业务模型可以分为以下2个层次:
业务usecase模型抽象一个特定业务.一般可用USECASE图来表达,其中以业务usecase来描述该业务的处理(businessprocesses),以业务actors来描述与该业务交互的客户(customers).例如:
取款,银行服务员,业务对象模型业务对象模型是一个业务的内部(interior)模型。
通过一组workers、businessentities、workunits来细化业务usecase模型中的每一个业务usecase。
其中,Businessentity:
表示某些事物(something),例如一张发票它们在一个业务usecase中被使用之。
workunit:
是这样实体的一个集合,对最终用户而言,形成了可认知的整体。
workers:
使用该业务usecase的工作人员.注:
Businessentities和workunit可作为领域类,用于表达领域中的概念,例如定单,栏目,发票等。
一般地,每一个业务usecase的细化可以通过交互图和活动图来表达。
Use-Case模型Use-Case模型用以表达客户认可的需求-系统必须满足的条件和能力。
Use-Case模型作为客户和开发人员之间的一种共识。
Use-Case模型是一个系统的一种模型,包括actors、usecases以及它们之间的关系。
Use-Casesystem,Use-Casemodel,Actor,Usecase,*,*,1,TheUse-Casesystemdenotesthetop-levelpackageofthemodel,Use-Case模型以及其内容,参与需求工作流的有关人员,SystemAnalysis,responsiblefor,Use-caseSpecifier,responsiblefor,User-interfacedesigner,responsiblefor,Architect,responsiblefor,usecasemodel,ActorGlossary,Usecase,Userinterfaceprototype,ArchitectureDescription,构造系统USECASE模型中的活动活动1:
发现并描述Actor和USECASE任务1:
发现Actor-当存在业务模型时,可直接发现一些候选的actors,即:
对于业务中的每一个worker,可以建议一个候选的actor对于每一个将要使用该信息系统的业务actor,即每一个业务客户,可建议一个候选的actor。
-当有或没有领域模型时分析人员就要与客户一起标识actor,并将所标识actor进行分类,形成一些候选的actors。
Note:
还要标识表示外部系统的actor和系统维护和运行所需要的actor。
针对候选的actors,可用以下2条准则来确定最终系统actors:
第一条准则:
至少要识别出一个用户,可以扮演候选的actor。
该准则将帮助我们仅发现那些相关的actors,避免actor仅是一些想象的“事物”。
第二条准则:
系统中不同actors实例之间,其角色的重叠应是最少的。
其中,如果2个或多个actors有着几乎相同的角色,那么就应该考虑:
是否将这些角色组合到一个actor的角色中,或是否需要发现另外一个“一般化”的actor,使之具有那些重叠的、公共的角色,并可以通过“泛化”,形成那些特定actor。
任务2:
Actors的命名与描述Actors的命名:
对actors的命名,可“传达”(convey)所期望的语义,因此给出恰当的名字是非常重要的。
Actors的描述:
对actor的描述,应包含其角色(责任)以及为了完成其责任所需要的条件。
例如:
theBuyer,SellerBuyerABuyerrepresentsapersonwhoisresponsibleforbuyinggoodsorservicesasdescribedinthebusinessusecaseSales:
fromOrdertoDelivery.Thispersonmaybeanindividualorsomeonewithinabusinessorganization.TheBuyerofgoodsandservicesneedtheBillingandPaymentSystemtosendorderandtopayinvoices.,SellerASellerrepresentsapersonwhosellsanddeliversgoodsorservices.TheSellerusesthesystemtolookfornewordersandtosendorderconfirmations,invoices,andpaymentreminders.,对usecase的理解在UML中,用况是系统向它的参与者提供结果(值)的功能块,表达参与者使用系统的方式,因此一个用况可用于规约系统可执行的、与参与者进行交互的一个动作序列,包括其中的可选动作序列,用况并有其自己的属性。
一个用况的实例,其行为表现为:
-首先,系统外部的一个参与者实例,直接启动该用况实例中的一条路径,并使之处于一个开始状态;-继之,执行这条路径中的动作序列,使该用况实例从一个状态转化为另一状态;其中,在执行该序列的每一动作中,包含内部计算、路径选择和向某一参与者发送消息;,任务3:
发现UseCase,-在一个新的状态中,等待actor发送另一外部消息,以此引发该状态下的动作之执行。
-如此继续,经历了许多状态,直到该用况实例被终止。
其中,由于我们把系统用况模型中的用况实例看作是原子的,因此只存在一类发生在参与者实例和用况实例之间的交互。
这意味着用况实例不能与其它用况实例发生交互,但每个用况的行为可以被其它用况所中断。
并且在大部分情况里,是一个参与者实例引发一个用况实例,但也有可能由一个事件所引发,例如由系统之外的定时时钟所引发。
-当已有一个业务模型时,可直接标识一些临时的用况,即为其中的一个“工作人员”或“业务参与者”的角色,对应地创建一个用况;继之,对这些暂时的用况进行细化和调整,并确定工作人员和业务参与者的哪些任务可由系统自动地予以实现,而后对确定的用况进行重新组织,以便更好地适应系统参与者的的要求。
-当没有业务模型时,就要与客户和/或用户一起来标识用况。
其中,需要一个一个地审阅参与者,为每一个参与者建议一些侯选的用况。
例如,研究一个参与者需要哪些用况,为什么需要这些用况,并研究参与者的创建、改变、跟踪、迁移等工作,通常需要哪些用况来支持之,研究业务用况中使用的业务对象,例如定单和帐目等。
不论采用什么方法,在发现候选用况中还需要进一步考虑一些问题,例如:
参与者是否还可能要通知系统一些外部事件,包括已经发生的一些事件,例如:
发票已经过期。
是否还可能存在一些其他的参与者,他们执行系统的启动、终止和维护。
是否存在一些侯选的用况,不宜作为系统最终的用况,而应把它们作为其他用况的组成部分。
创建的用况是否可以作为一个功能单元,容易修改、测试和管理之等。
对用户和系统之间的一个交互序列,是否在一个用况中予以规约,还是在多个用况中予以规约等。
在确定系统最终的用况当中,会涉及一个很难处理的问题,即用况范围大小的确定。
其中必须考虑:
它是否是完整的(complete),是否是另一用况的继续.下面给出两条确定用况大小的基本准则:
第一条准则:
用况应为它的参与者产生有值的结果(resultofvalue),特别地,用况应向一个特定的参与者交付了可见的结果(值).这一准则的目的是为了避免发现的用况太小。
第二条准则:
用况最好只有一个特定的参与者(particularactor)。
这条准则的目的是为了使所标识的用况都有一个真实用户,从而可以避免发现的用况太大。
注:
基于一些参与者而第一次发现的用况,常常需要予以重新组织,重新评估,使之更加“稳定”。
例如,假定已经有了一个体系结构描述,那么就要对新捕获的用况进行必要的调整,以便适应已有的体系结构。
任务4:
用况的描述对用况的描述程度,取决于是在什么时候。
一般或在发现时,或在需要精化时(参见4)任务3)。
在用况发现时,其描述一般应该:
首先给出该UAECASE的名字;继之,给出该用况的概要描述。
根据需要,概要描述一般可以采用两种形式,一种是简单地给出用况的功能,例如:
“PayInvoiceUseCases“TheusecasePayInvoiceisusedbyaBuyertoscheduleinvoicepayments.ThePayInvoiceusecasetheneffectsthepaymentontheduedate.”,第二种形式是首先概括其动作,而后一步一步地列出系统与其参与者交互时所要做的事情。
例如:
“Beforethisusecasecanbeinitiated,theBuyerhasalreadyreceivedaninvoice(deliveredbyanotherusecasecalledInvoiceBuyer)andhasalsoreceivedthegoodsorservicesordered.:
1.Thebuyerstudiestheinvoicetopayandchecksthatitisconsistentwiththeoriginalorder.2.TheBuyerschedulestheinvoiceforpaymentbythebank.3.Onthedaypaymentisdue,thesystemcheckstoseeifthereisenoughmoneyintheBuyersaccount.Ifenoughmoneyisavailable,thetransactionismade.”,通过以上活动1:
-形成了系统的粗略用况模型,记为用况模型概述。
-以这一用况模型概述为此基础上,进而可形成系统的一些非功能需求和相应的应用术语集。
活动2:
确定usecase的优先级(Priority)目标这一活动目标是,在活动1)和2)的基础上,确定哪些用况适宜在早期迭代中予以开发,哪些用况适宜在后期迭代中予以开发,并形成系统用况模型概述视觉下的体系结构描述。
输入与输出,Architect,UseCasemodeloutlined,SupplementaryRequirements,Glossary,ArchitectureDescriptionviewoftheusecasemodel,PrioritizedUseCases,实施-刻画在体系结构方面具有意义的用况,包括:
对某一重要、关键功能的用况的描述;包括对那些必须在软件生存周期早期予以开发的、某一重要的用况的描述。
作用-确定在规划的下一个迭代中,需要哪些开发活动和任务;-在这一规划中,当然还需要考虑其它非技术因素,例如系统开发的业务和经济方面的因素。
活动3:
UseCase精化目的详细地描述事件流,包括usecase是怎样开始的,是怎样结束的,是怎样与actors进行交互的。
输入与输出,UsecaseSpecifier,UseCasemodeloutlined,SupplementaryRequirements,Glossary,UseCasedetailed,DetailaUseCase,Theresultisadetaileddescriptionofaparticularusecaseintextanddiagram.,精化途径涉及:
如何描述一个usecase中所有可选的路径;在一个usecase的描述中包括的内容;如何在必要时形式化地给出usecase的描述。
有效技术:
事件流技术对用况的精化描述,可以用事件流(FlowofEvents)描述技术,规约当一个用况执行时,系统做了什么,以及系统如
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 面向 对象 方法 RUP