基于任务驱动模式的软件工程与ML建模技术项目九需求建模.ppt

项目九 需求建模 任务一 认识用例模型　　1992年由Jacobson提出的Use Case的概念及可视化的表示方法—Use Case图，受到了IT界的欢迎，被广泛应用到了面向对象的系统分析中。用例驱动的系统分析与设计方法已成为面向对象的系统分析与设计方法的主流。　　用例模型由Jacobson在开发AXE系统中首先使用，并加入由他所倡导的OOSE和Objectory方法中。用例方法引起了面向对象领域的极大关注。自1994年Ivar Jacobson的著作出版后，面向对象领域已广泛接纳了用例这一概念，并认为它是第二代面向对象技术的标志。 ? 操作一 用例模型概述　　用例模型是软件系统模型的核心。用例图用于描述系统的功能需求，在宏观上给出模型的总体轮廓。通过对典型用例的分析，开发者能够有效地了解用户的需求。用例就是从功能的角度来描述系统。通常情况下在系统需求分析阶段通过用例来描述参与者是如何使用系统的，因此用例建模通常也称为需求建模。 　　1．用例模型的功能　　用例模型是把应满足用户需求的基本功能(集)聚合起来表示的强大工具。　　对于正在构造的新系统，用例描述该系统应该做什么；对于已构造完毕的系统，用例则反映了系统能够完成什么样的功能。　　构建用例模型是通过系统开发者与系统的客户(或最终使用者)共同协商完成的，他们要反复讨论需求的规格说明,达成共识，明确系统的基本功能，为后续阶段的工作打下基础。 　　另外，系统开发过程中涉及的各种不同的人员都可以从用例模型中受益：客户使用用例模型，因为它详细说明了系统应有的功能且描述了系统的使用方法，这样当客户选择执行某个操作之前，就能知道模型工作起来是否与他的愿望相符合；开发者使用它，因为它帮助开发者理解系统应该完成些什么工作，为其将来的开发工作奠定基础；系统集成和测试人员使用它，因为它可用于验证被测试的实际系统与其用例图中说明的功能是否一致；其他人员包括市场、销售、技术支持和文档管理这些方面的人员也同样关心用例模型。 　　2．用例模型的基本组成　　用例模型的基本组成部件是用例、参与者和系统。用例用于描述系统的功能，也就是从外部用户的角度观察系统应具备哪些功能，帮助分析人员理解系统的行为，它是对系统功能的宏观描述。一个完整的系统中通常包含若干个用例，每个用例具体说明应完成的功能，它们代表系统的所有基本功能(集)。　　参与者是与系统进行交互的外部实体，它可以是系统用户，也可以是其它系统或硬件设备，总之，凡是需要与系统交互的东西都可以称做参与者。系统的边界线以内的区域(即用例的活动区域)则抽象表示系统能够实现的所有基本功能。 　　在用例模型中，系统仿佛是实现各种用例的“黑盒子”，我们只关心该系统实现了哪些功能，并不关心内部的具体实现细节。　　3．引用用例的目的　　(1) 确定系统应具备哪些功能，这些功能是否满足系统的需求(开发者与用户协商达成共识的东西)。　　(2) 为系统的功能提供清晰一致的描述，以便为后续的开发工作打下良好的交流基础，方便开发人员传递需求的功能。　　(3) 为系统验证工作打下基础。通过验证最终实现的系统能够执行的功能是否与最初需求的功能相一致，保证系统的实用性。 ? 操作二 用例图组成　　UML用例图是非常有用的一种图，在软件开发中的需求分析阶段，可以让人们从繁重的文档中解脱出来，并且促使人们在做需求时能够更加准确、直观地表达自己的意思。用例模型是用例图描述的，用例模型可以由若干个用例图组成。用例图中包含系统、参与者和用例三种模型元素。绘制用例图时既要画出三种模型元素，同时还要画出元素之间的各种关系。 　　1．参与者　　1) 什么是参与者　　参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称(见图9-1)： 　　 图9-1 参与者的表达方式 　　2) 识别参与者　　● 使用系统主要功能的人是谁(即主要角色)？　　● 需要借助于系统完成日常工作的人是谁？　　● 谁来维护和管理系统(次要角色)，保证系统正常工作？　　● 系统控制的硬件设备有哪些？　　● 系统需要与哪些其它系统交互？其它系统包括计算机系统，也包括该系统将要使用的计算机中的其它应用软件。其它系统也分成二类，一类是启动该系统的系统，另一类是该系统要使用的系统。　　● 对系统产生的结果感兴趣的人或事是哪些？ 　　在确定具体参与者时，可以通过以下一些常见的问题来帮助分析：谁使用这个系统，谁安装这个系统，谁启动这个系统，谁维护这个系统，谁关闭这个系统，谁也能使用这个系统，谁从这个系统获取信息，谁为这个系统提供信息，是否有事情