用例模型UseCase ModelWord格式.docx

用例模型UseCase ModelWord格式.docx

《用例模型UseCase ModelWord格式.docx》由会员分享，可在线阅读，更多相关《用例模型UseCase ModelWord格式.docx（15页珍藏版）》请在冰点文库上搜索。

–阐明系统应用的性能要求；

②设计与实现文档的编制规范

总体叙述；

算法；

数据结构；

系统体系结构；

系统优化设想；

③归纳出需求

由于问题的陈述不一定能反映用户的真实需求或者陈述所反映出的用户需求可能是不现实的、甚至是相互矛盾的，因此必须对陈述所反映出的用户需求进行归纳。

在归纳的过程中不要遗失任何信息。

要有需求就是挑战的观念。

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类组的使用

一个模型可能太大，可以分解为几个层次的逻辑子集表述以方便阅读、印制等目的；

顶层模型要尽量简明，逐层扩展；

关联不要跨层；