赞
踩
在系统开发的分析阶段,用户对系统的使用方式直接决定了系统的设计方式与构建方式。所以从用户观点出发,对帮助分析人员理解用户需求,建立可用、有用的系统是十分关键的。从用户的观点出发对系统建立模型是用例模型要完成的任务,因此用例建模通常也称为需求建模。本章在全书知识体系中位置如图所示。
在 UML 中,一个用例模型由若干个用例图(Use Case Diagram)描述。用例图是显示一组参与者、用例以及它们之间关系的图。
系统边界指一个软件系统能够处理的整个问题空间的范围。一个软件系统不可能处理所有问题,开发人员必须得给系统定义问题空间的范围。哪些是这个软件可以处理的,哪些则是这个软件不能处理的,也就是项目管理中所说的项目范围。在 UML 中,系统边界用方框表示,或者省略不做表示。
参与者指的是存在于系统之外,透过系统边界与系统进行有意义交互的任何事物。参与者可以是一个人,一个其他的系统或一部机器,甚至可以是时间,如图 3.2 所示。举例来说,比如在“自动售货系统”中,系统有售货、供货、提取销售款等功能,其中启动售货功能的是人,那么人就是参与者;又如“图书管理系统”可能需要和其他应用系统发生联系,比方说可能通过“学生管理系统”验证读者是否为在校学生,那么这里的“学生管理系统”就是一个参与者,只不过该参与者不是具体的一个人,而是另外的一个系统;与一个系统进行交互的人或其他的系统可以是参与者,与系统进行通信的硬件设备也可以是参与者,例如在“自动售货系统”中,顾客购买货品时,最终是货品分配器将货品传送至出货口以便用户提取,此时货品分配器作为硬件设备也就成为了该系统的参与者之一;再如“图书管理系统”中如果读者到期没有归还图
书,则读者进入系统时会有“未还书提示”功能,此处时间也就成为参与者,也就是说当经过一定时间后系统中的“未还书提示”事件就会发生。
从参与者在系统中的地位来看,可以将其分成两类,即主要参与者(Primary Actor)和次要参与者(Secondary Actor)。主要参与者指的是执行系统主要功能的参与者,例如在“图书管理系统”中主要参与者是进行借阅管理的图书管理员;次要参与者指的是使用系统次要功能的参与者,次要功能一般指系统维护功能(如管理数据库、备份和通信等),例如在“图书管理系统”中,能够检索该系统中一些基本统计数据的系统管理员属于次要参与者。将参与者分类的主要目的是,保证把系统所有功能表示出来,而主要功能是系统最关心的部分。
从参与者对用例的作用来看,可以将其分为主动参与者和被动参与者。主动参与者可以初始化用例、启动用例;而被动参与者则不能,它需要使用用例结果或为用例执行提供数据,被动参与者仅仅参与一个或多个用例,在某个时刻与用例通信。
在 UML 中,参与者表示为一个小人的图形(Stick Man 符号),在小人图形的下方书写参与者的名字,如图 3.3 所示;也可以用类符号(类的具体内容详见第 4 章)来表示参与者,如图 3.4 所示。
怎样确定系统的参与者呢?开发人员可以从如下几个方面来考虑。
从交互识别:
(1)谁使用系统的主要功能?
(2)谁改变系统的数据?
(3)谁从系统获得信息?
(4)谁需要系统的支持以完成日常工作任务?
(5)谁(或什么)对系统运行产生的结果感兴趣?
从维护、管理识别:
(6)谁负责维护、管理并保持系统正常运行?
从设备或外部条件识别:
(7)系统需要应付(处理)哪些硬件设备?
(8)系统需要和哪些外部系统交互?
(9)时间、气温等条件是否对系统产生影响?
例如,在“基于 Web 的零件销售系统”中,顾客可以通过 Internet 进行购买。要求顾客先预付一定金额存入内部账户中成为会员,然后才能购买零件。顾客可以根据自己所知道的零件的形状、大小、零件编号等指标,搜索出所需要的零件。结账使用内部账户支付。系统根据会员提供的送货地址和订购数量,从库存中搜索出离送货地址最近的供应商,通知供应商发货。另外,内部工作人员不定期地根据供应商方面的价格变动,对某些零件的销售价格进行更新。每个星期,各个供应商会把记录自己最新库存情况的 Excel 文件寄来,系统根据这些文件更新库存信息。因简化的需要,以下因素略去不考虑:折扣,延迟交货……
以该系统为例,针对前述问题进行回答便可以确定系统的参与者。
(1)潜在会员,会员使用系统的主要功能。
(2)会员,货管员,经理改变系统的数据。
(3)潜在会员,会员,经理,货管员从系统获得信息。
(4)经理,货管员需要系统的支持以完成日常工作任务。
(5)会员,经理对系统运行产生的结果感兴趣。
(6)系统管理员负责维护、管理并保持系统正常运行。
(7)系统无需应付(处理)特殊硬件设备。
(8)系统可能与供应商的系统交互。
(9)忽略时间、气温等条件对系统产生的影响。
综上回答,确定出“基于 Web 的零件销售系统”的参与者有:潜在会员、会员、经理、货管员、系统管理员、供应商系统。
需要注意的是,在识别参与者时,不能将参与者的名字表示成参与者的某个实例,比如“张三”是“基于 Web 的零件销售系统”中的会员,但“张三”作为参与者的实例不能作为参与者的名字;也不能将参与者表示成参与者所需完成的功能,比如“售货”就是所需完成的功能,同样不能作为参与者的名字。
用例是系统执行的一系列动作,这些动作生成特定参与者可观测的、有价值的结果值。一个用例定义一组用例实例。
用例是参与者要求系统提供的服务,是参与者使用系统期望达到的目标.,是从用户角度描述的系统行为。通俗地说,用例侧重于目标,而不是内部处理。用例没有表示任何关于系统内部的东西,只是表示系统将达到什么样的目标及由哪些参与者操作、负责。
用例具有以下特征:
(1)每个用例都有相应的信息输入,而输入信息一般由参与者提供;
(2)每个用例都有相应的信息输出,而输出信息一般被参与者接收;
(3)每个用例都是对一项系统功能的完整表述 ,对应具体的用户目标。
在 UML 中,用例被表示为一个椭圆图形,该椭圆的底部或内部书写用例名称,如图 3.17 所示。
对于用户来讲,用例可以帮助他们明确未来怎样使用系统;而对于开发者来讲,就需要在不关注细节的情况下,快速搜集系统需求,识别出系统用例。识别用例是系统开发中的重要组成部分,一个新的系统在研发前首先要进行系统的功能分析,弄清楚业务流程,这样才能更好地为系统服务,借助用例进行描述便可以解决上述问题。
怎样确定系统的用例呢?识别用例最好的方法是从参与者着手,考虑每个参与者是怎样使用系统的。应用这种策略可能还会找出一些新的参与者,这对完善整个系统用例模型大有益处。用例建模的过程就是反复迭代和逐步精化的过程。在此过程中,通过回答如下几个问题可以帮助识别用例。
(1)参与者要为系统提供哪些功能和信息?
(2)参与者需要系统提供哪些功能和信息?
(3)系统在哪些方面存在问题,在哪些方面亟待完善?
进而,确定用例的一般步骤为:
(1)确定哪些参与者为系统提供输入信息;
(2)确定哪些参与者需要从系统获取输出信息;
(3)确定输入信息与输出信息之间的映射关系,即用例。
例如,在“仓库管理系统”中,通过与系统用户沟通,分析人员可以识别出系统主要参与者有:
操作员、管理员、供应商、商品领料人、商品退料人。针对以上参与者,识别出系统用例有:仓库进货、仓库退货、仓库领料、仓库退料、商品调拨、仓库盘点、库存查询、业务分析、仓库历史记录查询、供应商信息维护、仓库信息维护、用户管理等。
用例阐述文档是针对每个用例,描述该用例各个场景(Scenario)的文档。所谓场景是指参与者和系统之间的一系列特定的活动和交互。每个用例是一组场景的集合,而每个场景又是一组步骤序列的集合。具体应用时,可采用如下用例阐述的模板。
模板1:
模板2:
案例:
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。