实验三 1 考勤卡应用程序用例分析.docx
《实验三 1 考勤卡应用程序用例分析.docx》由会员分享，可在线阅读，更多相关《实验三 1 考勤卡应用程序用例分析.docx（22页珍藏版）》请在冰点文库上搜索。
实验三1考勤卡应用程序用例分析
考勤卡应用程序用例分析实践
实践目的
通过例子过一遍分析的全过程
背景
目前已经为考勤卡系统收集了需求。
接下来就是分析这些需求，将其转化为开发人员可以理解的语言。
总体操作步骤
从用例分级开始，寻找候选对象及其交互，最后详细地描述这些类。
详细操作说明
用例分级
对每一个用例根据其风险、对用户和架构的重要性、对团队是否有能力开发进行分级。
然后确定一个最重要的用例子集，在第一次系统迭代中实现。
建立分级系统
将风险、重要性、对开发团队合适性分成1~5个级别，级别越高，表示用例越适合在第一个或下一个迭代中实现。
风险
应该尽可能在开发周期的初期攻克系统有风险的部分。
先列出风险清单，经考虑界面比较简单，用户可能对时间要求较突出，另外增加系统的规模和特性也可能碰到。
头脑风暴得出的风险有：
无法接受的系统性能
无法接受的用户界面
不确定的进度及开发周期
无法应付新的需求
经整理，得出如下关注的风险排序：
1.无法接受的系统性能
2.无法应付新的需求
3.不确定的进度及开发周期
4.无法接受的用户界面
风险评估值的获得
通过向开发人员询问：
是否有把握在第一次尝试解决某个问题，然后看答案的选择：
1）当然可以，我们项目团队以前做过
2）没问题，以前我们机构里面解决过这个问题
3）可以采用第三方产品、培训、书等，但我们内部没有任何经验
4）可能吧，听过类似的可以解决的问题
5）我希望可以，但得做一些开创性的工作
重要性及其指标值的获取
一个重要的用例应该能体现系统的特性和目标，其他用例只是扮演支持的角色。
如没有AddEmployee就不能使用系统，但RecordTime和ExportTimeEntries则反映了系统的目的。
用如下问题：
如果这个用例在本次迭代中忽略掉，或者用其他用例取代，用户将会怎样反应？
1.他们几乎不会注意到用例不存在，不用它系统也没什么影响。
2.他们会注意到这个用例不在了，但是稍加想象系统仍然可以很好的使用。
3.系统大部分可以独立于这个用例。
4.系统的一部分可以独立于这个用例。
5.没有它，就不可能使用这个系统。
合适性及其指标值的获取
如果项目组需要很少的培训和短时的学习就可以开始开发某个用例，则这个用例比较适合团队。
要求开发人员描述他们对方法和技术的把握有多高：
1.这个团队绝对需要一段培训时间来开发这个用例
2.对于这个用例，团队可能有了足够的能力，但一次迭代后，团队能力需要有本质的提高。
3.团队可能有了足够的能力，但一次次跌代后这个能力不需怎么提高。
4.不需要很多的培训。
要么团队能力有余，要么这个用例相当简单。
5.不需要很多培训。
团队有了足够的经验，用例也很简单。
手到就擒。
创建上述的风险项目及获取方法后，下一步就是得出具体的风险项与评估值。
操作方法是对每个用例进行评估，看看其风险因素和可能性及影响。
在需求收集过程中得到的需求模型如下，下面针对用例逐个评估。
评估ExportTimeEntries用例
让管理员用户导出指定时间段的条目到格式化的XML文件中。
1.风险：
性能稍有风险。
必须可扩展。
2级
2.重要性：
非常重要的用例。
5级（没有它，系统不能用）
3.合适性：
相对简单。
4级
结论：
考虑重要性，有助于同用户建立信任，并提供重要的构架信息，需要在第一次迭代中开发。
评估CreateChargeCode用例
让管理员用户增加新的收费项目代码，用户输入要用到。
1.风险：
性能没有风险。
扩展性低，界面/用例简单2级
2.重要性：
很重要的用例，更像是支撑的用例，早期用户不会注意到是模拟的还是输入的。
1级（不会注意到没有它，没有它也没有什么影响）
3.合适性：
5级不需要很多培训
结论：
没有必要在第一次迭代中开发
评估ChangePassword用例
让用户更改密码。
1.风险：
没有性能风险，很少改动，扩展性低，界面/用例简单1级
2.重要性：
也是支撑的用例，1级（不会注意到没有它，没有它也没有什么影响）
3.合适性：
5级不需要很多培训
结论：
可以在第一次迭代中开发忽略它，当然对系统很重要，推迟实现对评估系统和设计系统不会有影响。
评估Login用例
验证用户身份，作为执行其他用例的先决条件。
1.风险：
有性能风险，但比较低，界面/用例简单1级
2.重要性：
没有这个用例，系统就无法接受，但用户可以在没有此用例下评估系统，第一次迭代中即使不包含，也要考虑其构架支持，2级（会注意到没有它，稍加想象可以使用）
3.合适性：
4级不需要很多培训
结论：
尽管在构架上很重要，可以在第一次迭代中开发忽略它
评估RecordTime用例
让用户在当前时间段中输入它们的工时。
1.风险：
性能风险明显。
可扩展性风险低，用例容易理解，复杂性和性能很复杂，界面很复杂。
3级（可第三方获得帮助）
2.重要性：
非常重要的用例，体现考勤卡系统的意图。
5级（没有它，系统不能用）
3.合适性：
复杂性和风险使得必须第一次迭代中开发。
2级（团队有了能力，迭代后要有本质的提高）
结论：
诸多因素使得需要在第一次迭代中开发，然而由于复杂性，可以在几次迭代中分几次实现。
评估CreateEmployee用例
运行管理员用户在系统中添加一个雇员。
1.风险：
没有性能风险，界面/用例简单1级（当然可以）
2.重要性：
最终的系统中很重要，但是更多的是支撑用例，用户不会注意到是模拟的用户还是创建的用户，1级（不会注意到没有它，没有它也可以方便使用）
3.合适性：
5级不需要很多培训
结论：
可以在第一次迭代中开发忽略它
最终综合各个用例评估结果，选择第一次迭代开发用例：
在风险和重要性的基础上，选择RecordTime和ExportTimeentries作为第一次迭代的用例。
CreateEmployee,CreateChargeCode,ChangePassword可以推迟实现，Login可以推迟，但加入第一次迭代中。
一旦决定了首次迭代中开发的用例，下一步操作为：
从用例分级开始，寻找候选对象及其交互，最后详细地描述这些类。
寻找候选对象
划分：
实体、边界、控制、生命周期。
限制每一个对象的职责！
清楚的命名！
寻找实体对象
对每个用例，搜索每一个事件流，寻找名词、数据和行为。
分析RecordTime用例
正常事件流雇员记录时间
i）雇员查看当前时间段之前的输入数据。
ii）雇员从已有的支付号码中选择一个，这些收费项目代码是按客户和项目组织的。
iii）雇员从当前的时间段选择一个日期。
iv）雇员输入以正整数表示的工时。
v）在视图中显示这个数据，并在以后的视图中都可以看到这个数据。
可选事件流雇员更改他的时间。
i）雇员查看当前时间段之前的输入的数据。
ii）雇员选择一个已有的条目。
iii）雇员改变工时和/或支付号码。
iv）在视图中更新这个信息，并在以后的视图中都可以看到这个更新。
可选事件流雇员提交考勤卡作为结束
i）雇员查看当前时间段之前输入的数据。
ii）雇员选择提交考勤卡。
iii）要求雇员确认他的选择，并提醒他不能再更改他的条目信息。
iv）考勤卡被提交，并再也无法被更改。
剩余事件流没有引入新信息，列出名词字母表
列出名词字母表，逐个判断。
剔除不需要的和重复的实体对象。
识别不适合作为独立的对象、应该是其他对象属性的名词。
1
收费项目代码
2
支付号码
1.2同义，保留1
3
客户
是实体
4
日期
像是对象中的数据
5
雇员
独立的实体
6
已有的条目
姑且认为是实体
7
时间数
8
工时
7.8同义，留8
9
以前输入的数据
与6重复
10
项目
实体
11
考勤卡
实体
12
时间段
考勤卡的数据
13
视图
边界，拒绝它
最终分析得到的实体对象有：
收费项目代码、客户、雇员、已有的条目、工时、项目、考勤卡
分析ExportTimeEntries用例
正常事件流管理员用户导出数据。
i）管理员用户选择一段日期。
ii）管理员用户选择一些或者所有的客户。
iii）管理员用户选择一些或者所有的雇员。
iv）管理员用户选择目标文件。
v）数据以XML格式导出到文件中。
过程结束后通知管理员用户。
列出名词字母表，逐个判断。
剔除不需要的和重复的实体对象。
识别不适合作为独立的对象、应该是其他对象属性的名词。
1
管理员用户
实体
2
客户
已经识别为实体
3
XML格式
更像是输出文件描述，不是实体
4
数据
指考勤卡的一组条目，已经实体
5
雇员
已经实体
6
一段日期
是在另一个对象中的数据，增加一个新的实体对象–输出请求
7
目标文件
作为输出请求的一个数据
最终分析得到的实体对象有：
管理员用户、输出请求
分析Login用例
正常事件流管理员用户或雇员的姓名和密码是有效的。
i）管理员用户或雇员输入用户名和密码。
ii）验证用户是管理员用户还是雇员。
用户登录系统没有选择身份，系统根据用户名确定。
列出名词字母表，逐个判断。
剔除不需要的和重复的实体对象。
识别不适合作为独立的对象、应该是其他对象属性的名词。
1
管理员用户
已经实体
2
雇员
已经识别为实体
3
密码
对象的数据，不是实体
4
用户
应该是管理员或雇员更通用的类别
5
用户名
应该是管理员用户或雇员的对象的数据
Login用例没有新概念。
最终得到的所有实体类包括：
管理员用户收费项目代码客户雇员已有的条目
工时项目考勤卡输出请求用户
合并实体对象，考虑将管理员和雇员合并为User实体类，暂不作区分。
将这些关键抽象建模到系统中，展开LogicalView，新建>>类图，命名为KeyAbstraction。
将下面实体用工具栏中的实体类建立到关键抽象中。
（需要定制工具栏：
右击工具栏定制，选择三种分析类到工具栏上，
）
创建边界类
每一对参与者/用例对应一个边界类。
对ExportTimeEntries用例，有一个管理员用户和系统的接口的边界对象。
对RecordTime有管理员和系统的接口，还有普通用户和系统的接口。
边界由外部如何使用系统决定，而不是由在系统中如何表示决定。
所以虽然有User类，但还是区分管理员和雇员的边界类。
对Login一个是管理员和系统接口，一个是雇员和系统的接口。
创建控制类
每个用例分配一类控制对象。
每个控制对象为一个用例封装工作流。
一般在用例名后加Workflow就可以了。
最终得到的分析类建模大致如下：
前面分析类确定后，下一步：
从用例分级开始，寻找候选对象及其交互，最后详细地描述这些类。
描述对象交互，每个重要的事件流都要建立一个顺序图来建模，每个用例要建立一个VOPC类图。
顺序图中的所有对象，在类图中要定义它们的类。
首先为每一个类确定一些初步行为，有助于整理顺序图。
为Login添加假设行为
在用户界面类中增加displayForm方法。
输入完用户名和密码，考虑增加submitNameAndPassword方法。
关于验证的职责分配给LoginWorkflow对象，在其中赠加validateLogin方法。
但真正的验证在User自己，所以User类中增加validateLogin方法。
为让LoginWorkflow找到正确的User对象，需要UserLoactor类及其findByName方法。
登录成功后显示欢迎界面，所以在边界类中增加displayWelcome方法。
为Login构建顺序图
创建用例实现（在LogicalView中创建包Use-CaseRealizations，在此包中创建一个用例图命名为Traceabilities，在其中拖入UsedCaseView中的Login用例，并创建一个新的用例实现（
，需定制工具栏）命名为Login，同时创建一个子包命名为Use-CaseRealization–Login，将Login用例实现拖入此包，创建序列图命名为Login–BasicFlow，交互图中的内容参考下图，创建好序列图后按F5，自动生成协作图。
再创建序列图命名为Login–InvalidPasswordFlow和Login–InvalidUserFlow，其他操作类似。
下面几个用例实现同样操作）。
这里作为练习，对每个事件流都画出其交互图，实际开发中可能仅仅建模重要的事件流。
具体的交互关系可以参考如下建模。
验证Login序列
创建序列图时从事件流的流程来寻找行为，现在，对每个序列的相反方向进行验证。
每一步，确定对象是否拥有响应请求所需的信息。
主要问题集中在如何查找定位操作对象以及对象的创建时机等是否合理。
如Login交互中的UserLocator的引入就是为了解决LoginWorkflow控制类对象查找定位User对象而引入，否则LoginWorkflow如何能定位到合适的用户User是不合理的。
下面生成交互图对应的协作图
打开需要创建协作图的交互图，按下F5键，系统自动生成协作图。
ExportTimeEntries和RecordTime顺序图的创建方法类似于Login用例。
具体建模消息交互参考如下的图。
其他可选事件流参考文字说明部分。
前面的交互做好之后，下一步：
从用例分级开始，寻找候选对象及其交互，最后详细地描述这些类。
首先在用例实现包中建立VOPC类图，同一个用例的几个顺序图将共享这一个类图。
Login中的操作：
在Use-CaseRealization–Login包的Login用例实现下，创建类图命名为Login–VOPC，将用到的分析类拖入此类图，此处包含EmployeeLoginUI，LoginWorkflow，User，UserLocator。
分析阶段，可以完全确定实体类之间的关系，其他的关系只是简单的判断。
对象之间的关系（复习）
面向对象系统中充满着各种不同的对象，他们相互协作完成各种不同的任务。
每一个对象都有一个精确定义的责任集，必须一起合作来完成共同的目标。
类控制着对象拥有的状态、提供的行为、以及和它有关系的其他对象。
依赖（Dependency）聚合（Aggregation）
关联（Association）组合（Composition）
基于交互图将对象间交互职责映射到分析类
打开交互图，一般分析阶段消息以//开始，表示说明性信息，还不是最终系统使用的设计中的操作方法，因此消息基本上是说明性文字，也可以用类似于操作方法的消息说明。
右击某交互消息，将其关联到类中的职责，或选择创建新的操作（newoperation）。
寻找Login中类关系
EmployeeLoginUI对象调用LoginWorkflow对象中validateLogin方法。
从LoginWorkflow类到User类和UserLocator类也有关系。
Login中EmployeeLoginUI中允许多次登录尝试，因此需要保存LoginWorkflow的引用。
确定是关联。
LoginWorkflow对象不需要User对象的引用，因为LoginWorkflow对象每次重找User对象，确定是依赖关系。
因此Login中的类关系如下：
创建下面的关系。
寻找ExportTimeEntries中类关系，创建VOPC类图：
EmportEntriesUI对象用到ClientLocator和UserLocator对象，以及ExportTimeEntriesWorkflow，workflow对象用到EntryLocator对象、BillingSystemInterface对象以及大量的Entry对象。
但是没有重用，所以可以当作依赖关系。
寻找RecordTime中类关系
RecordTimeUI对象使用RecordTimeWorkflow对象，后者使用User对象以及Timecard对象。
RecordTimeUI对象保存对RecordTimeWorkflow对象的引用，利用它新建条目，是关联。
RecordTimeWorkflow对象保存User对象的引用，提交考勤卡后要新建新的考勤卡给User对象，所以是关联，而设置条目时又用到Timecard对象，所以也是关联。
已经做了寻找实体对象、控制对象、边界对象，用顺序图描述对象间关系，然后找出类之间的关系。
下一步，寻找系统解决方案，包括系统架构设计与系统详细设计。
做完Login用例分析得到的信息。
请将RecordTime和ExportTimeEntry用例的用例分析部分实现出来。
升级会员 