用例模型UseCase Model.docx
《用例模型UseCase Model.docx》由会员分享，可在线阅读，更多相关《用例模型UseCase Model.docx（15页珍藏版）》请在冰点文库上搜索。
用例模型UseCaseModel
用例模型（Use-CaseModel）
⒈内容概述
用例模型是以专门术语描述实际系统功能需求的原型。
在用例模型中，一个实际系统功能需求被表示为一个到多个系统行为（SystemBehavior）。
为便于描述系统行为的动态过程，在用例模型中还使用活动图（ActivityDiagram）来描述系统内部状态的变化过程（还配套状态图和事件流图）。
激发一个系统行为的第一信息来源和目标被称为角色（Actor），而当系统行为发生后会对第一信息来源产生反应。
角色只能在系统边界以外，用例模型实际上表现了系统内外的作用与反作用的信息交流过程。
UML中的用例模型分别用表示实际系统功能和与其相关的环境的图形符号体系所构成。
角色是与系统信息交互的源点与终点。
用例是系统与角色交互的一个系统行为的总和，与其他系统行为不同的是用例要特别描述出与其相关的角色、作用约束、响应性能等重要的系统数据。
在用例模型中用带有简要文字说明的箭头将用例和角色连接到一起。
可视化建模语言UML由五类模型视图和九种图所组成。
⒉步骤
转DEV475_02_Requirements.PDF文档。
⒊问题的陈述
①陈述的主要内容
·问题的范围；
·分别陈述要求解的必须部分的问题内容和可选择部分的问题内容；
·叙述应用的背景情况；
要注意下述问题：
–不要涉及系统内部的内容；
–阐明系统应用背景的各种假设前提；
–阐明系统应用的性能要求；
②设计与实现文档的编制规范
·总体叙述；
·算法；
·数据结构；
·系统体系结构；
·系统优化设想；
③归纳出需求
由于问题的陈述不一定能反映用户的真实需求或者陈述所反映出的用户需求可能是不现实的、甚至是相互矛盾的，因此必须对陈述所反映出的用户需求进行归纳。
在归纳的过程中不要遗失任何信息。
要有需求就是挑战的观念。
Rumbaugh曾经说过：
“即便你把用户所提出的问题总结的再好，但设计出来的结果却不能满足用户的实际需要，你如何面对你的客户”。
⒊建立用例模型的概念与步骤
1内容与目的
依据问题的陈述而描述出现实世界中的对象类极其相互间的关系。
2建立用例模型所需的必要信息材料
·问题的陈述；
·应用领域内的专业经验和知识；
·对现实生活的广泛了解和多门类的经验；
·多多的交流；
3建立用例模型的步骤
·标记对象与类；
·制作数据字典；
·标记对象间的关联关系和包容关系；
·标记对象的属性和连接；
·提取对象间的继承关系；
·测试对象间的访问路径；
·反复审核用例模型并归纳同类对象；
·在模型中使用类组；
上述步骤可由下图体现：
⒋标记对象与类
这一步由下述步骤组成：
·从问题陈述中抽取名词；
·生成静态系统交互图；
·用静态系统交互图修改初始化表；
·依据应用领域内的专业经验和知识可能提交扩展的问题陈述；
·标记附加的对象；
在本步的应用中应注意下面两点：
⑴生成静态系统交互图（ContextDiagrams）
静态系统交互图（在UML中称为用例图）用来描绘系统的范围。
该图由表示系统边界的圆和位于系统边界以外的角色构成。
如下图所示：
⑵筛选正确的类
问题陈述中名词并不一定是系统中的对象，必须对其进行筛选。
筛选的原则如下：
·滤除在问题陈述中出现的多余的、不相干的名词；
·滤除在问题陈述中出现，但却属于系统中某些类的属性、方法、作用名或是实现中的结构的名词；
·对含混的名词务必要澄清；
这样上述步骤极其反馈可由下图表示：
例：
酒店酬金支出系统
Payrollsystemproblemstatement
Createapayrollsystemforrestaurantsandhotels.Makecertainthattheusualdeductionsaretakenintoconsideration.Thepayrollmustaccommodatebothsalariedandhourlyemployees.Thewaitersaresalariedemployees,butthebusboysarehourlyemployees.Thepayrollsystemmustprintchecksweekly.Thesystemwillproduceapayrollregisterwhichwillbeturnovertoauditorsmonthly.IncomeandtaxreportsincludingW-2smustbepreparedaccordingtolegalrequirements.Reportsconcerningvoluntarydeductionswillbepreparedforvariousagenciesonaquarterlybasis.
解：
⑴绘制出静态系统交互图
⑵从问题陈述中抽取名词构成初步的对象
·该表称为初始化表，可能含有系统外面的对象（在未来的分析中将被删除）；
·在初始化表中可能会疏忽某些十分重要的接口对象，应设法加入；
·将初始化表中的角色和终端取消并代之一外部数据流；
⑶扩展问题陈述
Thepayrollmusttreatpart-timeemployeesashourlyemployees.Full-timeemployeesandsalariedemployeesmaytakeadvantagesofthevariouscompanybenefits,part-timeemployeesmaynot.Restaurantemployeeswillbeabletoeatmealsattheirrestaurantbutwillhavethecostofthemealsdeductedformtheirpaycheck.Hotelemployeeswillhaveroomcostsdeductediftheyliveinthehotel.Therearevoluntarydeductionsandmandatorygovernmentdeductionsthatmustbetakenintoaccount.
⑷由此陈述再向初始化表中插入新的对象名
（见附图）
⑸标记附加的对象
在本例中如雇员要按一定的工种组成一个部门、抽税计算用的税率表等。
⒌筛选对象类
①取消冗余的类
鉴别的原则：
·能提供相同信息的类；
·含有更丰富的描述内容；
如在PayrollSystem中Paycheck的描述多于Check。
②取消不相干的类
鉴别的原则：
·在问题陈述中及少出现、甚至无事可做。
如在PayrollSystem中的Basis和Consideration。
·涉及到判断的；
·一个场景中的重要对象而在另一个场景中可能无事可做的（如PayrollSystem中的Costofmeals、RoomCost）；
4取消本身是属性的类
鉴别的原则：
·属于另外一个对象内、且其状态可以量化的名词；
例：
设某问题陈述的片段为：
“雇员姓名、地址和工资号都应呈现在其个人的帐单上。
”
则：
雇员姓名、雇员地址和雇员的工资号都是雇员的属性。
5取消属于动作的类
例：
设某问题陈述的片段为：
“认可（submission）成本餐费和客房成本应输入到计时卡（Timecard）中。
”
则：
认可（submission）是Timecard的一个动作。
6取消属于作用名的类
可用在一个关联关系的终端充当作用名。
如PayrollSystem中的Waiters和Busboys。
7取消将在实现时才会用到的结构名
鉴别的原则：
·不属于现实世界的一部分；
·仅是作为在实现中的一种技术手段；
·数据表或数据结构；
例：
CPU、子程序、算法就都不是PayrollSystem中的对象。
8澄清含混的名词
·试探着改名子；
·在更广阔的领域内寻找同类；
如PayrollSystem中的Companybenefits就是需要更具体的阐述。
经过上述的筛选过程，PayrollSystem中的对象被取消的情况如下图所述：
⒍构造数据字典
步骤如下：
·数据字典涉及所有的模型内的项；
·类一经确定便需要构造相应的数据字典；
·定义标准的工程模板；
·数据字典的主要成份如下：
-类所在的问题空间的范围（作用域）；
-假设条件与禁止条件；
-关联与属性；
-重要的动作；
-作用；
⒎标记关联关系
在标记了对象之后，便必须仔细的分析对象间的相互作用关系。
1区分关联关系和包容关系
在对象关系中最突出的便是关联关系和包容关系，而这两者往往并不好分辨出来。
主要区别如下：
·关联关系的独立性强；
·包容关系则突出对象间物理的组成和所有权关系；
·两者在初始化时有着明显的区别；
2列出关联关系
列出关联关系可以从两个方面入手：
⑴显性关联关系
显性关联关系可直接从问题陈述中获得。
如PayrollSystem中的的显性关联关系可以列表如下：
·Payrollsystemaccommodatessalariedandhourlyemployees（satisfaction）.
·Systemprintschecks（directedaction）.
·Systemproducesapayrollregister（directedaction）.
·Reportspreparedforagencies（communication）.
·Full-timeandsalariedemployeesreceivecompanybenefits（directedaction）.
·Restaurantemployeeseatmeals（directedaction）.
·Costofmealsisdeductedfrompaycheck（directedaction）.
·Costofroomisdeductedfrompaycheck（directedaction）.
⑵隐性关联关系
隐性关联关系则要通过对问题陈述的归纳、分析或行业的经验中得到。
例：
EmployeereceivesaW-2formannually.
经过归纳和依据行业的经验，PayrollSystem中的隐性关联关系可列表如下：
·Employeesreceivepaychecks.
·Employeessubmittimecard.
·Hoursworkedaddstothepaycheck.
·Voluntaryandmandatorydeductionsaretakenfrompaychecks.
·TaxdeductionscontributetotheamountprintedintheW-2form.
·Payrollregisterreflectstheinformationprintedinthepaychecks.
·Companyconsistsofhotelsandrestaurants.
·Companyemployeesworkinrestaurantsand/orhotels.
⑶关联关系的筛选
与列出对象的思路一样，所列出的关联关系无论是显性的还是隐性的都不一定是最终的关联关系，也必须经过一系列的筛选和分析才能得到满足要求的关联关系。
同时关联关系的许多要素也只有在经过这一步骤之后才能描述清楚。
·类关联（Classassociation）
在一个系统中若一个类仅有一个关联与另一个类相联系，则称此种关联为类关联。
推论：
一旦仅含有类关联的类消失，则类关联也就不复存在了。
例：
人吃饭。
·不相干关联（Irrelevantassociation）
在一个系统中若一个关联的存在与否对问题求解无关重要，则称此种关联为不相干关联。
通常应尽量剔除系统内的不相干关联。
较为简单的判断关联是否为相干，主要是看该关联是否对系统内其它对象的状态、输入/输出等有影响。
例：
在PayrollSystem中的“餐馆雇员吃饭”对该系统的问题求解并无什么重要性。
但若换成“餐馆雇员每天可以享受规定货币限额的一次正餐”则对该系统的问题求解显得非常重要了。
·冗余关联（Redundantassociation）
在一个系统中若一个关联可以被另一个关联包含或替代，则称此关联为冗余关联。
通常应尽量剔除系统内的冗余关联。
例：
在PayrollSystem中的“餐馆雇员的餐费将从其个人的帐单中扣减”和“两周内餐馆雇员的餐费将从其酬金中予以扣减”就是冗余关联。
3确定关联的数量关系
在每一个关联关系的终端都必须标明数量值。
对于较灵活的关联关系最好在每一个终端都定义作用名（有时会非常困难）以便于确定数量值。
·若一个关联关系的一端是可选的，则可以使用数量0；
·若一个关联关系的一端仅有一个实例的连接，则可以使用数量1；
·若一个关联关系的一端同时可有多个实例的连接，则可以使用数量“多”；
4对关联更深层的理解
·关联不是一个动作，而是代表两个对象类间作用与被作用的关系；
·两个对象类间的多个动作只需要一个关联描述；
例：
在一个打印系统内，每台打印机控制器都与一个打印队列相联系。
则该关联可以被描述为：
打印机控制器被连接到打印队列。
打印机控制器与打印队列可以有如下的动作：
-打印机控制器可以修改打印队列中打印任务的顺序；
-打印机控制器可以删除打印队列中的打印任务；
-打印机控制器可以变更打印队列中的访问权限；
·插入作用名有助于提高关联的灵活性
例：
PersonmanagersPersonshouldbebossmanagersworker.
·减少关联中的元数
大多数三元以上的关联都可以转化为二元关联。
如一个三元的关联可以分解成一个二元关联和一个连接属性或者分解成三个二元关联。
例：
·减少关联中的数量
在一对一的关联中可以减少用以标识关联的属性。
若是一对多的关联中则可以将关联中的数量转换成连接属性或限定连接。
例：
经过上述的讨论和分析可以将初步的PayrollSystem的用例模型展示如下：
（见附图）
5标记属性
步骤如下：
⑴选定初步的属性
·问题空间；
·其它资源；
⑵优化属性
·派生得到属性；
·连接属性；
·限定性属性；
⑶筛选属性
·内部标识；
·内部状态；
6提取派生关系
⑴自底向上
·通过搜索提取各类中的共性属性、关联和动作；
·将各类中的共性属性、关联和动作置于一个公共的Supclass之中；
例：
-Hourlyandsalariedemployeescanbegeneralizedasemployee.
-Commonattributesincludename,addressandsocialsecuritynumber.
-Commonoperationsincludehire,assigntodepartment,andpromote.
⑵自顶向下
·遍历已存在的派生类（Subclasses）；
·寻找派生类的不同的关联和代名；
例：
Mandatorydeduction可以定义为下述类名：
-联邦税（Federaltax）
-州税（Statetax）
-地方税（Localtax）
7测试访问路径
·当上述步骤完成之后，观察模型是否能产生预期结果；
·提出一个已知的问题，从模型测试求解路径；
·若有问题立刻修改模型；
上述几步需要多次重复。
8类组的使用
·一个模型可能太大，可以分解为几个层次的逻辑子集表述以方便阅读、印制等目的；
·顶层模型要尽量简明，逐层扩展；
·关联不要跨层；
升级会员 