第3章用例和用例图.ppt
《第3章用例和用例图.ppt》由会员分享,可在线阅读,更多相关《第3章用例和用例图.ppt(66页珍藏版)》请在三一文库上搜索。
1、第3章 用例和用例图,3.1 用例, 用例(use case) Ivar Jacobson于20世纪60-70年代在爱立信公司开发AKE、AXE系列系统时发明的。 定义1:对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列。 定义2:用例是系统、子系统或类和外部的参与者(actor)交互的动作序列的说明,包括可选的动作序列和会出现异常的动作序列。,3.1 用例, 在UML中,用例是用一个椭圆表示,用例名往往用动宾结构或主谓结构命名(如果是英文命名,则往往是动宾结构)。 【例3.1】,3.1 用例,【例3.2】在一个银行业务系统中,可能会有以下一些用例: 浏览账户余
2、额 列出交易内容 划拨资金 支付账款 登录 退出系统 编辑配置文件 买进证券 卖出证券,3.1 用例, 使用用例进行需求分析的特点: 从使用者的角度描述系统中的信息 站在系统外部看系统 描述了用户提出的一些可见需求 对应一个具体的用户目标 对系统行为的动态描述 属于UML的动态建模部分,3.1 用例,UML建模: 静态建模 动态建模 静态建模:类图、对象图、构件图和部署图 动态建模:用例图、顺序图、协作图、状态图和活动图。,3.1 用例, 理论上可以把一个软件系统的所有用例都画出来,但实际开发过程中,进行用例分析时只需把那些重要的、交互过程复杂的用例找出来。 用例描述的是系统的功能性需求,3.
3、1 用例, 用例的需求大纲 系统的目的和范围 系统中的术语表 用例 系统采用的技术 开发过程中的参加人员、业务规则、系统运行所依赖的条件、安全要求、文档要求等各种其它需求 法律、政治、组织机构等方面的问题,3.1 用例, 用例这种技术很容易使用,但也很容易误用。正确使用用例分析来做好领域建模(domain modeling),以确保定义正确的需求(right requirements),然后开发出正确的系统(right system),是保证OO软件开发成功的基础。对于初学者来说,掌握用例的概念并不难,但要在具体的项目中灵活地使用用例来捕获用户的需求,并不是一件容易的事情,往往需要用户的经验、
4、沟通能力、丰富的领域知识等。,3.1 用例, 本质上,用例分析是一种功能分解(functional decomposition)的技术,并未使用到面向对象思想。因而有人认为用例分析只是面向对象分析与设计(Object-Oriented Analysis/Object-Oriented Design,OOA/OOD)的先导性工作,并非OOA/OOD过程的一部分,但也有人视其为OOA/OOD的一环。,3.1 用例, 用例是与实现无关(implementation independent)的关于系统功能的描述。在UML中,可以用协作(collaboration)来说明对用例的实现。,图3.3 用例及
5、其实现,3.1 用例, 在UML中,协作用虚线椭圆表示。在图3.3中,对用例Login共有两个实现,一个是简单的实现,另一个是带有安全验证功能的实现,这里没有显示协作的内容结构和行为方面的内容。协作的内部由两部分组成:一是结构部分,如类、接口及其他一些建模元素等;另一部分是说明类、接口以及其他建模元素如何协同工作的行为部分,如协作图(collaboration diagram)、顺序图(sequence diagram)、类图(class diagram)等。,3.2 参与者, 参与者(actor)是指系统以外的,需要使用系统或与系统交互的东西,包括人、设备、外部系统等。,3.2 参与者,【例
6、3.3】在一个银行业务系统中,可能会有以下参与者: 客户:从系统获取信息并执行金融交易。 管理人员:开办系统的用户。获取并更新信息。 厂商:接受作为转帐支付结果的资金。 mail系统。,3.2 参与者, 参与者的3种表示形式,3.2 参与者, 参与者之间可以存在泛化关系,3.3 脚本, 脚本(scenario)也被翻译为情景、场景、情节、剧本等。在UML中,脚本指贯穿用例的一条单一路径,用来显示用例中的某种特殊情况。 脚本是用例的实例(instance),如果与类和对象之间的关系作比较,则脚本与用例的关系相当于对象与类的关系。,3.3 脚本,【例3.4】:在“订货”这个用例中,包含着几个相关的
7、脚本。 一个是订货进行顺利的脚本;一个是相关货源不足的脚本;一个是涉及购物者的信用卡被拒的脚本,等等。这些脚本的组合构成了一个用例。 一个脚本使用具体的文字描述来表示。,3.4 用例间的关系, 用例之间的关系包括: 泛化关系(generalization) 包含关系(include) 扩展关系(extend),3.4.1 泛化关系, 泛化(generalization)代表一般与特殊的关系。 在泛化关系中,子用例继承了父用例的行为和含义,子用例也可以增加新的行为和含义或父用例中的行为和含义。,3.4.2 包含关系,包含(include)关系指的是两个用例之间的关系,其中一个用例(称作基本用例,
8、base use case)的行为包含了另一个用例(称作包含用例,inclusion case)的行为。,3.4.3 扩展关系, 扩展(extend)关系的基本含义与泛化关系类似。但在扩展关系中,对于扩展用例(extension use case)有更多的规则限制, 即基本用例必须声明若干“扩展点”(extension point),而扩展用例只能在这些扩展点上增加新的行为和含义。,3.4.3 扩展关系, 包含用例和扩展用例,3.4.4 用例的泛化、包含、扩展关系, 泛化关系和扩展关系 表示的是用例之间的“is a”关系 泛化关系 扩展关系 比泛化关系多了扩展点 包含关系 表示的是用例之间的“
9、has a”关系,3.4.4 用例的泛化、包含、扩展关系, 在扩展关系中,基本用例一定是一个well formed的用例,即是可以独立存在的用例。一个基本用例执行时,可以执行,也可以不执行扩展部分。 在包含关系中,基本用例可能是、也可能不是well formed。在执行基本用例时,一定会执行包含用例(inclusion use case)部分。, 使用条件, 如果需要重复处理两个或多个用例时,可以考虑使用包含关系,实现一个基本用例对另一个用例的引用。 当处理正常行为的变型而且只是偶尔描述时,可以考虑只用泛化关系。 当描述正常行为的变型而且希望采用更多的控制方式时,可以在基本用例中设置扩展点,使
10、用扩展关系。,参与者、用例间的关系类型, 下表是参与者、用例之间关系(relationship)的总结,3.4 用例间的关系, 关系 模型元素之间的语义联系 关联 两个或多个类元之间的关系 描述了类元的实例之间的联系 泛化关系 两个类元之间的关系 特殊和一般的关系 依赖关系 两个元素或元素集之间的一种关系 目标元素: 被依赖的元素 改变 源 元素: 依赖元素 相应的改变,3.5 用例图, 用例图:是显示一组用例、参与者以及他们之间关系的图。在UML中,一个用例模型由若干个用例图描述。,3.5 用例图,3.6 用例的描述, UML初学者 缺少用例的描述或用例的描述不完整 用例是一个“文字描述序列
11、” 用例是“动作序列的说明” 用例的描述才是用例的主要部分 是后续的交互图分析和类图分析必不可少的部分。,3.6 用例的描述, 用例的描述应该包含哪些内容,并没有一个统一的标准,不同的开发机构可能会有不同的要求,但一般应包括以下内容: 用例的目标 用例是怎么启动的 参与者和用例之间的消息是如何传送的 用例中除了主路径外,其他路径是什么 用例结束后的系统状态 其他需要描述的内容,3.6 用例的描述, 描述用例的原则是尽可能写得“充分”,而不是追求写得形式化、完整或漂亮。 作为OOA文档的一个组成部分,用例的描述应该有一定的规范格式,但目前并没有一个统一的标准。在统一的标准出现之前,人们可以采纳适
12、合于自己的用例描述格式,但不管怎样,在一个开发机构内部应该采用统一的格式。,3.6 用例的描述,3.6 用例的描述,3.6 用例的描述,3.6 用例的描述, 表3.3 是对“处理订单”这个用例的描述。 具体内容见书P31.,3.6 用例的描述, UML初学者易犯的错误 只描述系统的行为,没有描述参与者的行为 只描述参与者的行为,没有描述系统的行为 在用例描述中就设定对用户界面的设计的要求 描述过于冗长,3.6 用例的描述,ACockburn在Coc00中给出了很多错误的用例描述的例子。下面给出几个典型的例子。(为了说明问题,在给出描述时并没有完全按照表3.2中用例描述模板的格式,只给出了操作流
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 章用例 用例图
链接地址:https://www.31doc.com/p-2254903.html