Use case 案例分析
UseCase阐述的例子
1.系统显示合同可付款明细和付款明细状态。
2.根据合同的类型,用户可能进行下面两种操作:
(1)非零星购置类合同,用户将输入付款信息,并确认操作。
(2)零星购置类合同,用户将在付款列表中选中一条付款信息,并确认付款。
(3)用户不做选择,则系统返回基本流步骤6。
3.系统自动将本期合同付款金额数按照每条明细单项工程的应付金额在该合同的所有明细项目的金额总和中所占的比例进行分配。
1.2事件流
1.2.1基本流
操作者希望进行合同付款管理时启动此用例:
1.操作者选择合同付款选项。
2.系统显示操作者可以进行付款的合同列表。
3.操作者选择要付款的合同。
4.系统显示其基本信息及付款信息,并根据需要提示该合同的其他明细信息。
5.根据用户的选择执行如下相应的操作:
(1)用户选择付款操作,系统执行合同付款子流。
(2)用户选择添加付款明细操作,系统执行合同付款明细添加子流。
(3)用户选择修改付款明细操作,系统执行合同付款明细修改子流。
(4)用户选择删除付款明细操作,系统执行合同付款明细删除子流。
6.当用户选择其他操作时,系统结束此用例。
1.2.1.1合同付款子流
1.如果新建付款失败,系统提示用户合同付款失败,请用户与管理状态。
1.2.2.2备选流二
1.如果付款信息已经通过审核,用户再试图编辑或者删除该付款信息时,系统提示用户该付款信息已经通过审核,用户不能进行修改或者删除操作。
2.用户确认后退出用例流程。
1.3特殊需求
1.3.1第一特殊需求
付款金额只能输入数字和小数点,不允许输入其他字符。
1.4前置条件
第4章Use_Case图
•使用案例的正常(主)流程
•其他事件流 •错误流
•使用案例如何结束
2013年2月28日
12 3
例如:客户用常客卡买票,客户信用卡无效或请求的航班没有。这些情形 是系统能够处理的合法情形,而不是系统中发生错误。最后,错误流表示 错误条件。例如,系统无法验证信用卡或航班有没有。(错误流表示系统本 身的问题。) 主事件流: 主事件流的步骤如下: 1、客户选择浏览航班信息的选项时,用例开始。 2、系统提示输入出发站和到达站,出发时间和返回时间。 3、用户输入出发站和到达站,出发时间和返回时间。 4、系统显示航班清单及票价。 A1:没有这个航班 5、用户选择要打的航班。
A5:没有常客免费票
5、票价设置为0美元。 2013年2月28日 15 3
6、返回主事件流第8步。 A3:常客卡号无效 (描述的是其他事件流的A3)
1、系统显示常客卡号无效的消息。
2、用户重输卡号或选择取消常客免费请求。 3、如果用户重输卡号则流转入其他事件流A2第1步。
4、如果选择取消常客户免费票请求,则流返回主事件流第6步。
2013年2月28日
14 3
其他事件流 A1:没有这个航班
1、系统显示消息,没有所输入出发站和到达站以及出发时间和返回时间的航班。
2、用户确认消息。 3、返回主事件流第2步。 A2:用户用常客卡选择免费机票 1、系统提示输入常客卡号。 2、用户输入常客卡号。 3、系统确认卡号有效。 A3:常客卡号无效 4、系统确认里程数足够兑换免费机票。 A4:里程数不够兑换免费机票
评价贸易
* **
交易估价
* * **
营销人员
*
进行交易
<<extends>>
用例框图(UseCase Diagram)简介
用例框圖(UseCase Diagram)簡介用例框圖顯示系統中的用例與角色及其相互關係。
用例是系統提供的高級功能塊,角色是與所建系統交互的物件。
下圖是個用例框圖的例子:用例(UseCase)用例是系統提供的功能塊。
換句話說,用例演示了人們如何使用系統。
下圖表示一個"登錄"的用例:用例之間一般有兩種關係:擴展關係,包含關係。
屬性∙General:常規屬性o a bstract:抽象。
是否是抽象類o c lassifier behavior:類元行為。
指定定義類行為的活動、交互、狀態機。
這些行為詳細定義了類的行為特徵。
o e xtends:繼承。
類的父類。
直接繼承的父類。
o f inal:是否可繼承。
final類不可被繼承。
o f ull name:全名。
包含路徑的全名,如java.util.zip。
o g uid:元素唯一ID。
o m etaclass:元類。
模型元素的元類。
o n ame:名字。
o p rovided interface:提供介面。
即實現的介面。
o r equired interface:需求介面。
即類使用到(Usage依賴)的介面。
o s tereotype:構造型。
可選擇,也可自行輸入。
o s ubject:主題。
選擇用例表達主題。
o v isiblity:可見性。
∙Custom:自定義o t agged value:標記值。
如"query=true"∙Description:描述o d escription:元素的描述資訊∙View:顯示屬性o3D look:是否顯示陰影o a uto resize:是否自動改變元素尺寸。
o b ackground:背景色o f ont:字體o f oreground:前景色o v iew as class:顯示類樣式。
模型導航區快顯功能表∙new:新建:以當前包為命名空間,創建以下元素:o E xtension Point:擴展點∙new diagram:新建框圖。
Use case 案例
Design:
Design to Implement the Use Cases
Test:
Test that the Use Cases are Fulfilled
Two Simple Core Constructs
Actors Use Cases
An Actor
Bank Customer
An Automated Teller Machine (ATM)
Features of an Example System
Space Shuttle Cockpit Avionics Upgrade M Provide features comparable to existing system M Existing system allows Flight Controllers (ground) and Crew Members to monitor and control avionics of the vehicle and payloads M New system needs to provide better root cause analysis of failures M New system needs to provide faster and more concise summary of information M New system will be embedded in new hardware which is yet to be designed/procured
Glossary Actors Use Cases
...
Supplementary Specification Use-Case Specifications
用例(UseCase)
⽤例(UseCase)1. 基本概念⼀个⽤例就是与参与者(actor)交互的,并且给参与者提供可观测的有意义的结果的⼀系列活动的集合。
所谓的⽤例就是⼀件事情,要完成这件事情需要做⼀系列的活动;⽽做⼀件事情可以有很多不同的办法和步骤,也可能会遇到各种各样的意外情况,因此这件事情是由很多不同情况的集合构成的,在UML中称之为⽤例场景,⼀个场景就是⼀个⽤例的实例。
要启动⽤例是有条件的,这是启动⽤例的前提(前置条件);⽤例执⾏完了会有⼀个结果,成为后置条件。
综上所述,⼀个完整的⽤例由参与者、前置条件、场景、后置条件构成。
2. ⽤例的特征⽤例之间是相互独⽴的⽤例的执⾏结果对参与者来说是可观测且有意义的不存在没有参与者的⽤例,参与者启动⽤例(⽤例不应该⾃动启动,也不应该主动启动另⼀个⽤例)⽤例必然是以动宾短语形式出现的(构成⼀个完整的事件,例如喝⽔⽽不是喝)⼀个⽤例就是⼀个需求单元、分析单元、设计单元、开发单元、测试单元,甚⾄部署单元3. ⽤例的粒度(如何细分/尺度的确定)业务建模阶段:⼀个⽤例可以描述⼀项完整的业务流程(这有助于明确需求范围)概念建模阶段:⼀个⽤例能描述⼀个完整的事件流(⼀项完整业务中的⼀个步骤)系统建模阶段:⼀个⽤例能描述操作者与计算机的⼀次交互总结:粒度选择问题本质上由边界的认定不同⽽产⽣,原则是在同⼀个需求阶段,所有⽤例的粒度应该是同⼀个量级的。
4. ⽤例的获得⽤例的定义就是:由参与者(actor)驱动的,并给其提供可观测的有意义的结果的⼀系列活动的集合。
所以⽤例的来源就是:参与者(actor)对系统的期望。
所以发现⽤例的前提条件就是:发现参与者;⽽确定参与者的同时就确定了系统边界。
接下来通过以下问题引导业务代表,并从访谈结果中找出⽤例:您对系统有什么期望?(⼀件可以做的事,⽽不仅仅是⼀个主观愿望)您打算在这个系统⾥做些什么事情?您做这件事的⽬的是什么?您做完这件事希望有⼀个什么样的结果?应当确保:⼀个明确的有效⽬标才是⼀个⽤例的来源⼀个真实的⽬标应当完备地表达主⾓的期望⼀个有效的⽬标应当在系统边界内,由主⾓发动,并具有明确的后果如果发现有些业务总是说不清,应当考虑重新进⾏访谈,并考虑以下策略:调整系统边界和主⾓扩⼤或缩⼩系统边界变更主⾓然后重新开始5. ⽤例的实现完整叫法是系统⽤例的实现,不过系统⼆字可以省略。
科大国创use-casedescriptionexample
科大国创use-casedescriptionexample【引言】科大国创,作为一家致力于创新和技术研发的企业,始终保持着对行业前沿的敏锐洞察力。
USE-CASE DESCRIPTION EXAMPLE则是科大国创为解决现实问题而提出的一种创新解决方案。
接下来,我们将详细介绍USE-CASE DESCRIPTION EXAMPLE的用途、应用场景以及科大国创的成功案例。
【主体部分】USE-CASE DESCRIPTION EXAMPLE,简称UCDE,是一种以实例描述为基础的需求分析方法。
它旨在通过详细描述实际应用场景,帮助企业更好地理解用户需求,从而优化产品设计。
UCDE在以下几个方面具有显著优势:1.提高产品需求分析的准确性:通过对应用场景的详细描述,可以帮助企业更准确地把握用户需求,降低产品开发过程中的不确定性。
2.提高开发效率:UCDE可以将需求描述得更加具体清晰,有助于开发团队迅速理解需求,缩短开发周期。
3.降低沟通成本:UCDE以实例为基础,有助于各方之间的沟通,减少因误解而产生的沟通成本。
4.有利于产品优化和创新:通过对应用场景的深入分析,企业可以不断优化产品,提高用户体验,进而实现产品创新。
【案例分享】科大国创在电子、通信、金融、医疗等多个领域成功应用了USE-CASE DESCRIPTION EXAMPLE。
以下列举几个典型案例:1.某知名智能手机企业在开发新款手机时,通过科大国创提供的UCDE方法,对用户需求进行了详细分析。
结果表明,用户对手机拍照功能的需求日益增长,尤其是在低光环境下拍摄效果的提升。
据此,企业在新款手机的相机功能上进行了优化,最终获得了良好的市场反响。
2.某金融机构在推出一款线上理财产品时,运用UCDE方法对用户投资需求进行了分析。
了解到用户对投资风险和收益的权衡取舍,企业针对性地设计了多种投资策略,满足了不同风险承受能力的用户需求,提升了产品竞争力。
3.某医疗机构通过科大国创实施的UCDE方法,对患者就诊流程进行了优化。
UML中的用例(Use Case)概念分析及实例
UML中的用例(Use Case)概念分析及实例文/登峰2005-02-25在UML中use case似乎最簡單的,用例建模的最主要功能就是用来表达系统的功能性需求或行为,依我的理解用例建模可分为用例图和用例描述。
用例图由参与者(Actor)、用例(Use Case)、系统边界、箭头组成,用画图的方法来完成。
用例描述用来详细描述用例图中每个用例,用文本文档来完成,以及由箭头所组成的各种关系,包括泛化,包含,扩展等。
本文准备向大家介绍以下内容,所有图示均用PowerDesigner所画.◆用况◆参与者◆泛化◆<<use>>◆<<include>>◆<<extend>>◆用例描述1.用况(use case)图1用况图是对一组动作序列(其中包括它的变体)的描述,系统执行该动作为执行此动作的参与者产生一个可观察的结果值。
比如你使用计算器,这里可以把计算器看作为用况,参与者是登峰,登峰按了3+3(用况执行的序列),计算机器返回一个结果6。
2.参与者(Actor)参与者不是特指人,是指系统以外的,在使用系统或与系统交互中所扮演的角色。
因此参与者可以是人,可以是事物,也可以是时间或其他系统等等。
还有一点要注意的是,参与者不是指人或事物本身,而是表示人或事物当时所扮演的角色。
比如小明是图书馆的管理员,他参与图书馆管理系统的交互,这时他既可以作为管理员这个角色参与管理,也可以作为借书者向图书馆借书,在这里小明扮演了两个角色,是两个不同的参与者。
参与者在画图中用简笔人物画来表示,人物下面附上参与者的名称。
3.泛化泛化和类中的泛化概念是一样的,子用况继承父用况的行为和含义,还可以增加或覆盖父用况的行为;子用况可以出现在任何父用况出现的位置(父和子均有具体的实例)。
下面给出两种图示来说明泛化的概念和含义图2含义继承图3行为继承4.<<user>><<use>>: 其关系非常象一个函数调用或一个子过程以这种方式使用的用例称为抽象用例因为它不能单独存在而必须被其它用例使用,请看下图图4使用<<use>>示例5.<<include>>怎么解释这个定义呢?还是说明一下它的功能吧,<<include>>可以把几个用例的公共步骤分离出来成为一个单独的被包含用例。
UseCase
23/25
6.2 ATM取款案例2
Use Case:取款 Actor:储户 主事件流: 1、Байду номын сангаасTM系统获得ATM卡和密码; 2、设置事物类型为取款; 3、ATM系统获取要提取的现金数目; 4、验证帐户上是否有足够储蓄金额; 5、输出现金、数据和ATM卡; 6、系统复位。
1025三用例描述的内容其他需要描述的内容1125四书写用例文档路径交互步骤的描述只书写可观测的说人话使用主动语句句子必须以执行者或系统作为主语每一句都要朝目标迈进分支和循环不要涉及界面细节1225四书写用例文档1325四书写用例文档1425四书写用例文档1525四书写用例文档1625四书写用例文档1725四书写用例文档1825四书写用例文档1925四书写用例文档2025四书写用例文档2125五常见错误描述过于冗长222561atm取款案例1usecase
问题:只描述了ATM系统的行为,而没有描述参与者的行为
七、修改后的描述
24/25
Use Case:取款 Actor:储户 主事件流: 1、通过读卡机,储户插入ATM卡; 2、ATM系统从卡上读取银行ID、帐号、加密密码、并用主银行系统 验证银行ID和帐号; 3、储户输入密码,ATM系统根据上面读出的卡上加密密码,对密码 进行验证; 4、储户按“快速取款”按钮,并键入取款数量,取款数量应该是 100的倍数; 5、ATM系统通知主银行系统,传递储户帐号和取款数量,并接收返 回的确认信息和储户帐户余额; 6、ATM系统输出现金、ATM卡和显示帐户余额的收据; 7、ATM系统记录事务到日志文件;
1.1 用例的基本定义
2/25
一、识别用例
1.2 用例要点
用Use Case 表达架构观点之二
把 Woklw当作外部 系统 .明显表 外 , ro f 需要有相对应的措施处理 。 将许 多必
者。 观察设计 团队A与B 所画出的用例 图。 达 H R系统不需实做流程签核功能。可以 要 的例 外情况记录在 用例 叙述 的替代及
设计 团队A与设计 团队B 的系统设计 是其它外购产品 (1 l s 、 pn or 例 外处理 的流程字段 上。可 以想的到而  ̄1 t : i )O eS u e U mu c
系统 当黑盒子 , 描述参 与者与系统之 间的 标准 的接 口沟通规格 。即使你是 二包的
: ■ ]
早
一
歧, 耗 太 不 要 精力 时间 对 而 费 多 必 的 与 。
系统 全貌有 了共识 ,再 由需求分析师针
(dpnet ow r Vno) I eedn Sf a e r 承接到一 n t e d 个项 目, 需要为某公司既有的 H (u a R Hm n Rsu e 系统新增电子签核的功能。最 e r) oc
J —●
团 队B
系利用 则 利用 e / U法则 ,先利用散文 、 … 一 uZ 尢利用 x
,
程完全是计算机化 自动化。 这也是 属于 流程签核 的责任 。亦 即 ,未来 H R系统 的 简洁 易读 的文笔来书写用例叙述 ,专心 业务流 程再造 的范 畴 ,可 以减轻人事部 实做可能需要实做 流程签核的功能。
维普资讯
既
莹疆圈 薯 Ma a e e t Pr cie n g m n & a t s c
需求分析 >>>
用 Us e 表达架构观点之二 Ca e s
口 文 /王克 明 从用倒图观察设计者的意图
MI部 门 的开 发 人 员 ,也 可 能 是 IV S S
软件项目管理_FP度量分析_UseCase度量分析例子
度量管理练习以员工管理系统为范例,在添加一个员工资料时会使用到员工的一般信息、员工的教育情况、工作经历和家属信息。
员工又会隶属于某个部门,在本系统中会有一个对部门进行维护的功能。
员工的工资是由另外一个财务系统提供的。
因此其用例图如下所示:图员工管理系统用例图假设员工基本信息如下所示:员工ID(标签控件)员工名称性别生日婚否所属部门ID(标签控件)所属部门名称受教育的时间学校名称所学专业工作单位工作时间工作部门工作职务亲属的姓名之间关系亲属年龄亲属工作单位假设部门信息如下所示:部门ID(标签控件)部门名称假设工资表信息如下所示:员工ID(标签控件)员工姓名金额单位FP分析法解答:1. 首先列出各种估算的标准:ILF和ELF的复杂度评估方法如下表所示:EI/EO/EQ的复杂度评估方法如下表所示:TFP数的估算方法如下:ILF内部逻辑文件RET数量DET数量复杂度DFP(DataFunctionPoint)数量员工信息文件4个(包括员工基本信息、教育信息、工作单位信息、亲属关系信息)17个(员工信息一共有18个字段,但是其中的部门ID为外键,计算DET时主外键只能计算一个,故为17个。
)低7部门信息文件1个(部门信息2个低7由以上两表分析可以得到DFP的个数为:7+7+5=19个。
3.寻找该系统TFP的数量由于EI是外部输入型事务处理,EI事务从系统外部输入数据到系统内部,因此对于本例员工管理系统来说,EI就包括:增、删、改员工信息,增、删、改部门信息。
(在计算EI 的DET时,只有用户在界面上直接输入的信息才能算作DET。
)由于EQ代表外部查询,从外部输入一些条件,系统返回一定的输出。
那么在该员工管理系统中,EQ 就包括:查询员工信息、查询部门信息。
由于EO是输出型事务处理,如报表输出、画面初始化的输出。
EO 从系统内部输出数据到系统外部。
EO 输出的数据或者来自ILF 或EIF ,或者组合ILF/EIF 的字段而来的新数据,或者通过算法计算而来的数据。
UseCase事件流编写实例分析
用例名称:登记课程事件流:1.显示一张空白的课程表。
2.显示所有课程的列表,方式如下:左端窗口按字母顺序列出系统中的所有课程;底部窗口显示突出课程的上课时间;第3个窗口显示当前课程表中的所有课程。
3.选择课程。
4.学生单击某一课程。
5.更新底部窗口。
显示该课程的上课时间。
6.学生单击该课程某一时间,然后单击“添加课程”按钮。
7.检查学生是否学习了必需的前导课程,以及该课程是否没有限制。
8.如果该课程没有限制,而且学生也学习了必需的前导课程,则把该学生加入到该课程中。
显示更新的课程表,这里应该出现新添加的课程。
如果上述检查结果为否,则显示一条消息:“你还没有学习前导课程,请选择其他课程。
”9.在课程表中该课程标记为“已登记”。
10.学生单击“保存课程表”,课程选择结束。
11.保存课程表,返回主选择屏幕。
用例名称:登记课程事件流:1.显示一张空白的课程表。
1.学生请求提供一张新课程表。
2.显示所有课程的列表,方式如下:左端窗口按字母顺序列出系统中的所有课程;底部窗口显示突出课程的上课时间;第3个窗口显示当前课程表中的所有课程。
2.系统准备好空白的课程表表格,从“课程分类系统”中抽取已开设的和可选的课程列表。
3.选择课程。
4.学生单击某一课程。
5.更新底部窗口。
显示该课程的上课时间。
6.学生单击该课程某一时间,然后单击“添加课程”按钮。
3.学生从系统提供的上述课程中选择主修课程和选修课程。
7.检查学生是否学习了必需的前导课程,以及该课程是否没有限制。
8.如果该课程没有限制,而且学生也学习了必需的前导课程,则把该学生加入到该课程中。
显示更新的课程表,这里应该出现新添加的课程。
如果上述检查结果为否,则显示一条消息:“你还没有学习前导课程,请选择其他课程。
”9.在课程表中该课程标记为“已登记”。
4.对选中的每门课程,系统确认学生已经学习了必需的前导课程,然后把学生添加至该课程中,并在课程表中标记学生“已登记”该课程。
aeb use case diagram 举例
aeb (Agricultural Extension for Bundled Services) Use Case Diagram 举例随着科技的不断发展,农业领域也迎来了新的变革。
aeb (Agricultural Extension for Bundled Services) 是一种农业扩展服务的模式,通过整合各种资源和服务为农民提供全方位的支持和帮助。
本文将通过use case diagram的方式,来举例说明aeb模式在农业领域的应用场景和效果。
1. 场景一:农业信息服务1.1 农民使用aeb评台查询天气预报和气象数据,以便合理安排农事活动。
1.2 农民通过aeb评台获取农作物种植、管理和病虫害防治等方面的专业知识和技术支持。
2. 场景二:农业金融服务2.1 农民通过aeb评台了解贷款政策和贷款流程,实现便捷的农业贷款服务。
2.2 农民通过aeb评台进行农产品销售和物流配送,实现农产品的快速上市和销售。
3. 场景三:农业培训服务3.1 农民通过aeb评台参与农业培训课程,学习现代农业生产技术和管理经验。
3.2 农民通过aeb评台进行农业技能考核和证书颁发,提升农业从业人员的综合素质和竞争力。
4. 场景四:农业保险服务4.1 农民通过aeb评台了解农业保险政策和保险产品,为农业生产风险提供保障。
4.2 农民通过aeb评台进行农业损失的定损和理赔,实现快速、便捷的保险理赔服务。
通过以上的举例,我们可以清晰地看到aeb模式在农业领域的广泛应用和丰富效果。
它不仅为农民提供了丰富的信息资源和专业的技术支持,还为农业生产和经营提供了全方位的服务保障。
未来,随着科技的不断进步和农业现代化的推进,aeb模式必将在农业领域发挥越来越重要的作用,为农民的生产生活带来更多的便利和利益。
随着科技的迅速发展和农业现代化的推进,aeb (Agricultural Extension for Bundled Services) 模式在农业领域的应用日益广泛,为农民提供了更加全面和便捷的支持和帮助。
usecase规则
usecase规则Use Case规则的重要性Use Case规则是软件开发过程中非常重要的一部分,它定义了系统或软件的功能需求,是开发者和用户之间进行沟通的重要工具。
遵循Use Case规则的开发过程能够确保软件系统的功能和需求被准确地理解和实现,从而提高软件的质量和用户满意度。
一、Use Case规则的定义和作用Use Case规则是一种描述系统功能需求的方法,它以用户的角度来描述系统的行为和交互。
一个Use Case是一个完整的场景,描述了一个或多个参与者如何使用系统来完成某个特定的目标。
Use Case规则的作用主要有以下几个方面:1. 用于沟通和协调:Use Case规则能够帮助开发者和用户之间建立共同的语言和理解,从而提高沟通和协作的效率。
2. 用于需求分析:通过Use Case规则,开发者能够深入理解用户的需求,从而准确地分析和定义系统的功能和需求。
3. 用于验证和测试:Use Case规则可以作为验证和测试的依据,通过对Use Case的执行和测试,验证系统是否满足用户的需求。
4. 用于文档编写:Use Case规则可以作为编写用户手册和系统文档的基础,帮助用户理解和使用系统。
二、遵循Use Case规则的原则和要求遵循Use Case规则需要注意以下原则和要求:1. 清晰和精准:Use Case规则应该以简洁明了的方式描述系统功能和用户需求,避免歧义和模糊性。
2. 客观和中立:Use Case规则应该从用户的角度出发,客观地描述用户的需求和期望,而不是开发者的个人意见。
3. 可测试和可验证:Use Case规则应该具备可测试性和可验证性,能够通过执行和测试来验证系统的功能和需求是否被满足。
4. 可扩展和可维护:Use Case规则应该具备可扩展性和可维护性,能够适应系统的变化和演化。
5. 可理解和可接受:Use Case规则应该以用户可以理解和接受的方式描述系统的功能和需求,避免使用过于技术性的术语和表达方式。
会议管理系统-N
MeetingRoom
Meeting Capacity BuildingCode DoorCode Status AssignMeetingInstance () SetInvalidate() Release() 图5 MeetingRoom类图 首页 上页 下页 末页 退出
MeetingInstance
用例9:会议维护(Meeting Room Maintenance) 加入一个会议室(用例15) 标记一个会议室不可用(用例16) 查询会议室预定情况(用例17)
用例10:设置预定时限制(Set Reservation Tome Limit) 设置时间限
用例11:发会议通知(Inform of Meeting) 从会议人员管理获得参加人员的投递地址 填写通知(会议召开时间、会议室号码) 发送通知 用例12:申请拒绝(Request Rejection) 作废当前的一切输入 中字止用户当前的操作 用例13:选择会议参加人员组(Select Group Attendee) 浏览会议组成员 选择参加组 用例14:会议取消通知(Inform of Cancellation) 从会议人员管理处获取参加人员地址 填写通知 发送通知
⑵
与会议申请者相关的用例: 申请会议召开(Request Meeting Instance ) 更改申请(Chang Request ) 取消申请(Cancel Request ) 定义参加人员(Add Attendee ) 归还会议室(Release Room )
首页
上页
下页
末页
首页
上页
下页
末页
退出
用例15:增加会议室(Add Meeting Room) 输入会议室号码
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
1、角色识别及描述
• 谁使用该定货中心系统的主要功能?
– 管理者、发货人员、客户和收款人员
• 谁需要改系统的支持以完成其日常工作?
– 管理者、发货人员、收款人员
• 由谁来负责维护、管理并保持系统正常运行?
– 管理者
• 系统需要使用哪些硬件设备?
– 信用卡
• 该系统需要和哪些系统交互? • 谁对该系统运行结果感兴趣?
超市信息管理系统
• 统计分析管理包括查询商品信息、查询销售信 统计分析管理包括查询商品信息、 查询供应商信息、查询缺货信息、 息、查询供应商信息、查询缺货信息、查询报 表信息和查询特殊商品信息,并制作报表。 表信息和查询特殊商品信息,并制作报表。统 计分析员使用系统的统计分析功能了解商品信 销售信息、供应商信息、 息、销售信息、供应商信息、库存信息和特殊 商品信息,以便能够制定出合理的销售计划。 商品信息,以便能够制定出合理的销售计划。 • 系统管理包括维护员工信息、维护会员信息和 系统管理包括维护员工信息、 系统维护。 系统维护。系统管理员通过系统管理功能能够 了解公司员工信息、会员信息, 了解公司员工信息、会员信息,还能够对系统 进行维护工作。 进行维护工作。
超市信息管理系统
• 库存管理包括商品入库管理、处理盘点信息、处理报 库存管理包括商品入库管理、处理盘点信息、 销商品信息和管理设置信息。 销商品信息和管理设置信息。这些设置信息包括供应 商信息、商品信息和特色商品信息。 商信息、商品信息和特色商品信息。库存管理员每天 对商品进行一次盘点,当发现库存商品有损坏时, 对商品进行一次盘点,当发现库存商品有损坏时,及 时处理损坏信息。当商品到货时, 时处理损坏信息。当商品到货时,库存管理员检查商 品是否合格后将合格的商品入库。当商品进入卖场时, 品是否合格后将合格的商品入库。当商品进入卖场时, 商品进行出库处理。 商品进行出库处理。 • 订货管理是对超市所缺货物进行的订货处理,包括统 订货管理是对超市所缺货物进行的订货处理, 计订货商品和制作订单等步骤。 计订货商品和制作订单等步骤。当订货员发现库存商 品低于库存下限时,根据系统供应商信息制作订单, 品低于库存下限时,根据系统供应商信息制作订单, 进行商品订货处理。 进行商品订货处理。
2、用例识别及描述
6. 针对系统
– – 系统需要什么样的输入、输出?输入来自 哪里?输出去往哪里? 该系统的当前状况存在哪些问题?
2、用例识别及描述
• • • • • • • • • • • • 用例1:增加定单 用例2:计算定单价钱 用例3:发货 用例4:付款处理 用例5:信用卡付款 用例6:评价商务结果 用例7:退货服务 用例8:处理客户退货 用例9:查询定单情况 用例10:维护 用例11:物品信息维护 用例12:税务信息维护
2、用例识别及描述
2. 从发货者识别
– – – – 发货者者要求系统为他提供什么功能?发 货者需要做哪些工作? 发货者需要阅读创建、销毁、更新或存储 系统的某些信息吗? 系统中的事件一定要告知发货者吗? 由于系统中新功能的识别,发货者的工作 效率提高了吗?
2、用例识别及描述
3. 从收费者识别
– – – – 收费者要求系统为他提供什么功能?收费 者需要做哪些工作? 收费者需要阅读创建、销毁、更新或存储 系统的某些信息吗? 系统中的事件一定要告知收费者吗? 由于系统中新功能的识别,收费者的工作 效率提高了吗?
– 客户、管理者
1、角色识别及描述
• • • • • • • • • • 角色名:管理者 角色职责:接受定货,计算价钱,选择仓库发货 角色名:发货者 角色职责:根据定单发货给顾客,填写定单 角色名:收款人员 角色职责:根据定单签收顾客的定货款,顾客退还 商品时退款 角色名:客户 角色职责:定货、退还货、查询定单 角色名:信用卡 角色职责:电子付定货款
• 根据各个参与者所执行的具体职责,可 以
–
管理者需要做:
• •
2、用例识别及描述
1. 从管理者识别
– 管理者需要阅读创建、销毁、更新或存储 系统的某些信息吗?
• 定单;职员(仓库人员、收费人员)信息;顾 客信息;物品条目及价格信息;仓库信息;税 务信息
2、用例识别及描述
1. 从管理者识别
– 系统中的事件一定要告知管理者吗?
• • • 仓库有关物品短缺以至无法满足某定单 定单数据出现错误 顾客超过期限未付款
超市信息管理系统
• 能够支持售货员的日常售货功能。每一个售货员通过 能够支持售货员的日常售货功能。 自己的用户名和密码登录到售货系统中, 自己的用户名和密码登录到售货系统中,为顾客提供 服务。在售货员为顾客提供售货服务时, 服务。在售货员为顾客提供售货服务时,顾客购买商 售货员根据系统的定价计算出商品的总价, 品,售货员根据系统的定价计算出商品的总价,顾客 付款并接受售货员打印的货物清单, 付款并接受售货员打印的货物清单,系统自动保存顾 客购买的商品记录。 客购买的商品记录。 • 查能够为超市的管理者提供管理功能。超市的管理包 查能够为超市的管理者提供管理功能。 括库存管理、订货管理、报表管理、 括库存管理、订货管理、报表管理、售货人员管理和 系统维护等。库存管理员负责超市的库存管理; 系统维护等。库存管理员负责超市的库存管理;订货 员负责超市的订货管理; 员负责超市的订货管理;统计分析员负责超市的统计 分析管理; 分析管理;系统管理员负责超市的售货人员管理和系 统维护。 统维护。每种管理者都通过自己的用户名和密码登录 到各自的管理系统中。 到各自的管理系统中。
2、用例识别及描述
4. 从顾客识别
– – – – 顾客要求系统为他提供什么功能?顾客需 要做哪些工作? 顾客需要阅读创建、销毁、更新或存储系 统的某些信息吗? 系统中的事件一定要告知顾客吗? 由于系统中新功能的识别,顾客的工作效 率提高了吗?
2、用例识别及描述
5. 从信用卡识别
– – – – 信用卡要求系统为他提供什么功能?信用 卡需要做哪些工作? 信用卡需要阅读创建、销毁、更新或存储 系统的某些信息吗? 系统中的事件一定要告知信用卡吗? 由于系统中新功能的识别,信用卡的工作 效率提高了吗?Use Fra bibliotekase 案例分析
定货中心
• 有这样一个定货中心,它接受客户的电话、传真、电子邮件、信 件和web主页表单形式的定货请求,形成货物定单,并告知客户 定单的价钱。根据客户要求的发货目标地点的信息,定货中心的 经理以最经济的方式确定一家仓库来负责向客户发货。仓库人员 收到定单后按一定的策略处理定单,发出货物,并在定单上填写 所发货物的数量信息,后把定单返回给定货中心,定货中心确认 后把定单交给收费部门,由该部门负责管理客户收到货物后的付 费。 • 客户在收到货物之前可以向定货中心查询他的定货处理情况,收 到定货后,如果出现质量问题或者物品错送问题(即送的货物不 是客户想要的货物),客户有权利向定货中心退货,定货中心必 须接受退货,并退还用户所付款(如果用户已付款)。仓库在处 理定单时由于受到库存货物有限这一现实情况的约束,因此采取 一定的策略来保证那些优先级较高的定单先得到发货。 • 在定货中心的人工系统中,交流主要通过电话、传真等。在引入 计算机管理后,定货中心、仓库、收费部门之间可以共享客户、 定单信息,不仅省去了电话、传真的成本,同时重要的是提高了 定货中心的运作效率。
参与者
• • • • • • 售货员:售货员为顾客提供售货服务 顾客:购买超市商品的人员 库存管理员:负责超市的库存管理活动 订货员:负责超市的订货管理 统计分析员:负责超市的统计分析管理 系统管理员:负责超市的员工信息管理、会员信息管 理以及系统维护等。 • 售货员、库存管理员、订货员、统计分析员和系统管 理员都是超市的员工,其中库存管理员、订货员、统 计分析员和系统管理员都是超市的管理者。
2、用例识别及描述
1.
–
从管理者识别
管理者要求系统为他提供什么功能?管理者需要做哪些工作?
• • • • • • • • • 接受顾客定货请求并创建定单 计算定单价钱 根据定单信息选择仓库,并将定单发送给该仓库 查询定单货物发送情况 查询客户定单付款情况 评价商务结果 顾客退货处理 把从仓库返回的定单发送到收费处 商品价格更新 生成定单 查询输入定单号