利用用例图描述用户需求.pptVIP

利用用例图描述用户需求(用例建模) 在本讲您能了解如下知识点 口UML中的用例 口用例之间的关系 日用例图的组成部件 口UM中的用例图及项目实例 Dl  UM中的用例及用例图 1、用例及用例建模技术产生的背景概述 (1)M之前对系统的需求描述方法 般是采用自然语言(如中文)来描述对系统的需求,这 样的方法有几个致命的缺陷 □缺乏描述的形式化,随意性较大,常常产生理解上的含混 及不确定性一—自然语言的描述容易产生歧义 没有统一的格式,不能自动化地验证 口不能保证文档与程序同步 (2)那我们怎么描述?一形式和内容是什么! 因为我们在系统开发时必须要了解并准确描述用户的各 个方面的需求,这包括功能、非功能以及环境的约束等方面 需求。同时,我们所采用的方法能否避免常规的方法所带来 的问题? Dl  (3)我们可以采用UM中的用例模型方法! □项目开始时, Use Case视图的主要使用者是客户、分析人 员和项目管理员。 这些人利用使用案例、 Use Case框图和使用文档来确定系 统的高层视图 POS 销过 还 支付授权服务 牧银员 和量过程 货款加入 指苫活动擁 全计 系管理员 理枢限  2、用例模型中的基本组成部件 1)用例( UseCase) 2)系统 (3)参与者 餐馆定座系统用例图 服务生 查询信用 ext中nds 户关系系统 统计定情况 堂经理 打印机 V  3、用例模型的参与者 (1)参与者:参与者表示系统用户所扮演的各个角色(role) (2)参与者可能有 设备调试系统 大类 因此,参与者不 系统用户完全都是“ 数据采集器 使用者或 看设备状态 者操作员) 口与所建系统 交互的其他 设备调试员 定时器 系统 口其它设备  (3)某项目中的各个参与者示例说明 在“网上书店”项目中的参与者主要有用户(又可以细分注册和非注册等子类型)和系统统管理员 而管理员使用控制面板对系统和用户管理,也就是进行系统设置,管理用户、用户组、限,查看系统访 问日志及用户使用情况等的统计信息。 在前面的学校课程管理系統中的示例中则有三个参与者在不同的应用中互动。 参与者分别是学 生,讲师以及系統管理者。而学 生参与者使用了系統中浏览课程以注册课程的功能, 而系就管者参与者则是负智Q理注删的学员编排课程以及确认课程讲师则是主导 课程的参与者,他可以浏览,开 办以及移除课程({当然,必须是这个讲师自己的课程 (4)参与者之间的主要关系一泛化关系 特化或者继 承 修改开发部员工资料 修改员工资料 个人登记客户 电话登记客 角色之间的通用化关系示例 工程师 程师  (5)所要注意的问题 ●参与者主要是指角色而非具体的个人 Actor is Not a specific ●用户与参与者之间的关系 a role Person 一个用户可以抽象为多个参与者,如张三即可以是 网上书店的读者,也可以是管理员4 一个参与者可以包含多个用户,如:网上书店的读者 可以是张三和李四 ●发现参与者对提供用例是非常有用的,通过实 践,我们发现参与者对提供用例是非常有用的 因为面对一个大系统要列出用例清单常常是十Bank 分困难。+ Customer 这时可先列出参与者清单,再对每个参与者列出它的用例,问题就会变得容易很多。 Dl  (6)如何获得系统中的参与者 获取用例首先要找出系统的参与者。严格的识出参与者这是不可能的,在需求研讨会上,我们可以 通过“头脑风暴”来获得主要参与者。 或者可以通过根据用户回答的一些可题答累嘉来识别参与者。以下问题可供参考: 谁使用系统的主要功能(王要使用者)。 隹需要系统支持他们的日常工作。4 诓来维护、管理使系統正常工作辅助使用者)。来进用户管理和安全管埕? 系统需要操纵哪些硬件。 系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序 系统产生的结果感兴趣的入或事物 用例的确定只是与 是否存在一个监控系统,在系统清误的计能解充启系統(。用户交流的目的, 用例模型中的用例( Use Case 而不是交流的救 (1)用例及其定义一某种特定的功能 ●它摧述了活动者绐系统特定的刺激时系统的活动,是活动者通过系统完成一个过程时出现的一组 事件,最终以实现一种功能。 邐常,用例侧重于功能,仨不重点描述该功能的实顼細节;同时用例的大小划分一燬以事件流在 10个步骤左右为好。 ●所有的用例必须始于参与者(Atar),而且有些用也结束于参与者。  (2)用例的分类 业务用例:如报表数据汇总计算