UseCase—案例学习.ppt

上传人:文库蛋蛋多 文档编号:2421340 上传时间:2023-02-18 格式:PPT 页数:41 大小:214.51KB
返回 下载 相关 举报
UseCase—案例学习.ppt_第1页
第1页 / 共41页
UseCase—案例学习.ppt_第2页
第2页 / 共41页
UseCase—案例学习.ppt_第3页
第3页 / 共41页
UseCase—案例学习.ppt_第4页
第4页 / 共41页
UseCase—案例学习.ppt_第5页
第5页 / 共41页
点击查看更多>>
资源描述

《UseCase—案例学习.ppt》由会员分享,可在线阅读,更多相关《UseCase—案例学习.ppt(41页珍藏版)》请在三一办公上搜索。

1、案例学习,Rational Software Architect Workshop,实验二和实验三导入的项目(ACMEPayrollModel),主要内容,开始一个项目用例模型分析模型设计模型实现模型,开始一个项目,ESU背景,为老师们指定课程和学生们注册课程的过程在老师们决定了这一学期将要讲授的课程之后,教务处将这些信息输入到计算机系统中,然后打印出一批报表,告诉老师他们将教哪些课程。还要打印出一个课程目录,分发给学生接着,学生们就要填写一些(多个部分、多种颜色的)注册表格,表明他们选择了哪些课程,然后将填完的表格交还给教务处。通常,一个学生要上4门课,ESU背景(续),然后,教务处的工作人

2、员将学生的表格录入到大型计算机系统中。一旦录人完学生在本学期的课程,就整夜运行一个批处理任务来将学生分配到课程上通常,学生能够得到他们的第一选择;然而,对于那些有冲突的课程,教务处会与每个学生谈话,以让学生做其他选择。在将所有的学生成功地指定到课程上之后,就发给学生一个时间表,供他们确认。大多数学生注册在一周内就处理完了,但有些例外的情况需要花两周时间才能解决在最初的注册期结束以后,老师会收到他计划要教的每门课的学生花名册,ESU课程注册问题的陈述,在每个学期开始时,学生们会申请一个课程目录。目录中列出了本学期提供的课程,其中还包含了每门课程的相关信息,比如老师、系、之前必修的课程,这些能够帮

3、助学生在了解的情况下做出决定新系统将允许学生为即将到来的学期选择4门课程。另外,每个学生还要指明两个替代选择,以便所提供的课程满员或被取消的情况下进行调整。所提供的课程的学生数不能超过10名或少于3名。少于3名学生的课程将被取消。一个学生的注册过程完成后,注册系统就会将信息发送给计费系统,这样这名学生就可以为这个学期付费了老师必须能够访问这个联机系统,他们需要通过系统指出他们将教哪些课程以及查看哪些学生注册了他们所提供的课程对于每个学期,都有一段时间允许学生修改他们的课程表,学生可以在这段时间里访问系统来增加或删除课程,用例模型,用例模型,待开发系统的功能需求记载在该模型中该模型演示了设想的系

4、统功能(用例)它的外界环境(参与者)用例与参与者之间的关系(用例图)了解一个用例中所表现出的不用应用场景(Scenario)之间的控制流和数据流使用活动图来直观地记录一个用例中的不同流,System BehaviorActorsUse CasesUse Case DiagramsActivity DiagramsSummary,System Behavior,用例模型所起的最重要的作用是通信为客户或最终用户与开发人员讨论系统的功能和行为提供了一个载体用例模型开始于初始阶段,标明了系统的参与者和一些首要的用例在细化阶段,在已标明的用例上增加更详细的信息,并根据需要又增加一些额外的用例,用例模板,

5、创建用例模型模板Overviews包Use-Case Building Blocks包$functional.area$use.caseVersatile Actors包创建功能区域包,Actors,Actor不是系统的一部分,它们代表了必须与系统进行交互的任何人或任何事物一个参与者可以只向系统输入信息只从系统接收信息既向系统输人信息,又从系统接收信息,可以在问题陈述中发现这些参与者或通过与客户和领域专家交谈发现参与者可以使用下列这些问题来帮助确定系统的参与者:谁对某个需求感兴趣?系统用在组织的什么地方?谁会从系统的使用中受益?谁将为系统提供这一信息,谁使用这一信息,谁删除这一信息?谁将支持和

6、维护这一系统?系统使用外部资源吗?一个人会扮演几个不同的角色吗?几个人会扮演同一个角色吗?系统会与过去遗留的系统交互吗?,ESU课程注册系统中的参与者,对于前面的问题,回答如下学生想浏览课程目录并注册课程老师想选择课程来教和请求一个课程的花名册登记员必须创建课程并为本学期生成一个目录登记员必须维护所有关于课程、老师和学生的信息计费系统必须收到来自此系统的计费信息,Student,Instructor,Registrar,Billing SystemCourse Registration packageStudent、Billing SystemSystem Maintenance packag

7、eRegistrarVersatile Actors packageInstructor创建参与者,撰写参与者的文档,在模型中,应当加入对每个参与者的简要描述。这一描述应当能标识出这个参与者在与系统交互时所扮演的角色ESU课程注册系统的参与者的描述如下:Student一个注册在大学中要选课程的人Instructor一个有资格在大学中教课的人Registrar负责维护ESU课程注册系统的人Billing System负责学生计费的外部系统撰写参与者的文档,用例,用例所建模的是参与者与系统之间的对话,代表的是系统所提供的功能系统的用例集合组成了使用系统的所有已定义方式正式定义一个用例是系统所执行的

8、一系列的事务,它为一个特定参与者产生了一组值的可度量结果,可以使用下面这些问题来帮助标识出系统的用例:每个参与者的任务是什么?参与者会创建、存储、修改、删除或读取系统中的信息吗?哪些用例会创建、存储、修改、删除或读取这一信息?当突然发生外部变更时,是否需要有某个参与者来通知系统?在系统中发生某些事情时,是否需要通知某个参与者?应有哪些用例对系统进行支持和维护?所有功能性需求都被用例完成了吗?,如何确定一个“好的”用例,一个问题发现用例的详细级别,即用例应当有多大(或)多小经验规则一个用例通常代表一个从头到尾的完整的主要功能用例必须对参与者交付一些价值例如,在ESU课程注册系统中,一个学期学生必

9、须选择一些课程,必须将学生添加到所提供的课程中,还有就是必须对学生计费。那么这应该是3个用例,还是1个用例?,另一个问题如何将不同的但看起来属于一类的功能捆扎在一起例如,登记员必须增加课程、删除课程和修改课程,这些是3个用例还是1个用例?同样,还是应该将它当做一个用例:维护课程因为这一功能由同一个参与者(登记员)启动,并且处理的是系统中的同一个实体(课程)。,为了避免陷入功能分解,应按下面的方式来对待用例确定用例是否代表了一些显示了从头到尾的功能的东西,并且这一功能又是启动此用例的参与者所需要避免“小”用例,即提供一部分功能的用例避免“过多”的用例。即便是非常复杂的系统通常也只有最多50个用例

10、避免那些名字本身就暗示着功能的一部分的用例。例如,输入老师编号就不是本系统中的一个好用例,ESU课程注册系统中的用例,下面是系统必须解决的需求:学生需要使用系统来浏览课程目录并注册课程在课程选择过程完毕之后,必须向计费系统提供计费信息老师这一参与者需要使用系统来选择一个学期中要教的课程,并且必须能从系统收到一个课程花名册登记员负责生成某个学期的课程目录,还负责维护系统所需要的所有关于课程、学生和老师的信息,基于这些需要,标识出下面这些用例:Register for coursesBrowse course catalogRequest course rosterSelect courses t

11、o teachMaintain course informationMaintain professor informationMaintain student informationCreate course catalog创建用例,用例规格说明,用例规格说明应当包括下面这些内容:该用例的简要说明,即用几句话来陈述该用例的目的该用例什么时候、怎样开始和结束该用例与参与者有哪些交互该用例需要哪些数据该用例生成了哪些数据以系统应该做什么(而不是系统如何做到)的方式来书写事件流该用例的事件的正常序列,即事件的基本流其他替代流或异常流的描述用例的前置条件(在用例启动之前必须发生什么)用例的后置条件(

12、用例结束之后会发生什么)扩展点(那些可以使用可选行为对基本用例进行扩展的用例),template from Rational Unified Processuse case specification:Browse Course CatalogIBM Rational RequisitePro与RSA集成创建RequisitePro项目链接到RequisitePro项目创建Use Case Specification创建需求、子需求,用例图,用例图用于对用例与参与者之间的关系和用例与其它用例之间的关系进行可视化应当创建下列这些用例图:Main use case diagram showing

13、the functional use case packagesA diagram showing the most important use casesA main diagram for each functional area showing the use cases in that functional area,参与者用例之间的关系,参与者与用例之间的通信用关联(association)来显示,通常被称为通信关联无论在参与者与用例之间传递了多少消息,在参与者与用例之间都只有一个通信关联,课程注册系统的用例图概览图所有用例课程注册用例系统维护用例,用例间的关系,在用例之间可能存在两

14、种关系:包含和扩展多个用例可以共享相同的功能可以将这个功能放入到一个单独的用例中,而不用在每个需要它的用例中进行记录在这个新用例和任何“使用”其功能的其他用例之间创建了一种包含关系For example,each use case in the ESU Course Registration System starts with the verification of the user.This functionality can be captured in a User Verification use case,which is then used by other use cases

15、as needed包含关系被画成一个依赖关系,从基础用例指向被使用的用例,扩展关系用来显示可选行为仅在某些条件下才会发生的行为,比如触发一个警告根据参与者的选择而可能运行的几种不同的流For example,if a current selection is not available during the Register for Courses use cases,the student may want to see what other courses are available.Thus,the Browse Course Catalog use case may be an ext

16、ension of the Register for Courses use case.扩展关系被画成一个依赖关系,从扩展用例指向基础用例Organize use cases in course registration use case diagram,Activity Diagrams,在生命周期的这一阶段中,应当创建活动图(activity diagram)来显示用例中的控制流和数据流活动(activity)是一些容器节点,它包含了action和actions之间的控制流及数据流图中显示了action序列、控制流、合并和决策点(判定),Actions,一个action代表的是执行工作流中

17、的某些行为可以通过检查用例规格说明和确定用例的步骤中需要执行哪些行为来确定action,Control Flows and Object Flows,Control Flows在活动图中,一旦一个action结束,控制会传递给下一个action控制流显示了控制按顺序从一个action传递到下一个actionObject Flows很多时候,会想与控制流一起显示数据流也就是说在action之间流动的数据对象流表示了从一个action到数据的流动或者从数据到一个action的流动,Decision Points,当为一个系统的工作流建模时,通常要使用决策点来显示控制流在哪里进行分支开始于决策点的控

18、制流包含一个guard condition,用来决定采用决策点之后的哪一条路径,Forking and Joining Flows of Control,在工作流中,通常有一些可以并行执行的操作fork节点能够指定哪些活动能够并发完成join节点可以用来显示工作流的汇合,也就是说,在继续处理之前,必须完成哪些操作因此fork节点有一个流入的控制流,有多个流出的控制流join节点有多个流入的控制流,有一个流出的控制流,Activity Partitions(swimlane),在活动图中可以使用活动分区(activity partition)将action按照某些公共的东西进行分组这样做通常能显

19、示出是哪些人或组织来负责包含在一个分区中的活动,Initial and Final Nodes,有一些特殊的符号用来显示工作流中的开始节点和结束节点开始节点使用一个实心圆来表示,结束节点使用牛眼(实心圆外面加一个圆环)来表示对于一个活动,有一个开始节点,但可以有多个结束节点(活动中的每个备选流有一个结束节点)Create activity diagram for the Browse Course Catalog use case,Summary,系统行为记录在用例模型中,用例模型显示了系统的预期功能(用例)、功能的环境(参与者)以及用例与参与者之间的关系(用例图)用例模型的最重要的作用是与客

20、户或最终用户交流系统的功能和行为参与者不是系统的一部分,它们代表了必须与待开发的系统进行交互的任何人或物用例代表了系统所提供的功能,它们所建模的是参与者与系统之间的对话每个用例都包含了一个事件流,事件流描述了完成这个用例功能所需要的事件。编写事件流时,采用的是系统应当“做什么”的方式,而不是系统“如何做”的方式,用例图是系统的部分或全部参与者、用例以及它们交互的一个图形化表示用例之间的关系主要有两种:包含和扩展包含关系显示的是被几个用例共享的功能扩展关系描述的是一个用例的可选行为活动图表示的是系统的动态行为,它们是一些流图,用于显示系统的工作流在生命周期的当前点中,可以创建活动图来表示一个用例

21、中的流,DeveloperWorks Links,A.3.1Gottesdeiner,E.Use case best practices.IBM developerWorks,November 2003:http:/A.3.2Pan-Wei Ng.Adopting use cases.developerWorks,November 2003:http:/A.3.3Ericcson,M.Activity diagrams:What they are and how to use them.developerWorks,April 2004:http:/T.3.1Two-part use case modeling Web-based course(fee-based):Principles of use case modeling with UML.developerWorks,January 2005.Part One begins at http:/,

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 建筑/施工/环境 > 项目建议


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号