初学感悟-2-用例杂记

两年前培训时候写的总结,最近发现用例这又出现很多问题,重新看这段文字又有所感,所以原文不动搬过来,对于现在也是有所帮助.(PS:现在英语确实比那时候强­了一点点o_o!hehe)

这两天开始了JBlogs的项目，整整开了两天的会，不过收获还是很大的，起码亲身经历了这么一个项目开始的过程，总结一下：
1。接到一个项目，首先要确定系统的范围，也就是确定系统的边界，找出"角色"。建立"词汇表"也就是我们常说的术语表，因为这个时候项目已经开始，首先应该有­项目的名称，比如本项目中的"JBlogs"，为了项目组人员在一起能够准确的，统一的交流，应该从项目一开始就建立这么一个词汇表，随时记录在项目需求分析或­以后进程中遇到的新的专业词汇，并准确定义每个词汇所表达的意思，以免在交流中发生歧异。（在最后生成概念模型的时候，应该所有的概念模型名称都在术语表中能找­到相应的名称说明，否则就是词汇表还不够完善，），确定词汇时要多考虑考虑，这时候有时已经联系到概念模型，比如blogger还是user的问题，也许以后J­Bloges要加入到一个更大的系统时，用blogger就可以直接继承大的系统中的user，这样就可以实现JBloger与其他例如论坛系统一起采用一个用­户管理登陆系统，这样系统的扩展性会大很多。措词要准确，比如Profile表示的是个人信息和概要信息，因为在注册时不仅要填写自己的个人信息，还要填写比如­所感兴趣的模块一类的概要信息，所以在此用INF**（信息，单词不记得了）就不太准确了
2。此时已经总结出主要的"角色"，也许还不够完善，不过没关系，我们会在接下来的分析中发现新的角色，到时候再添加进去。我们要考虑这些主要角色所要达到的目­标是什么（如果问这些角色要做什么，不如问这些角色的目标是什么），画出"执行者-目标"列表，这是一个需求调研的过程，也是一个找出用例的方法，了解到用户到­底要的是什么，而不是要知道用户要怎样做，这样能更清楚用户所想要的到底是什么。这也是确定范围，不过与1中的确定系统范围不同，这是在确定功能范围。
3。确定目标的层次，这一步是很重要也是很困难的，目标的层次分为概要目标，用户目标，子功能目标，我们所关心的也是最重要的目标就是用户目标，也是今后主要要­写出的用例，怎么才能确定一个目标是不是一个用户目标呢，我自己觉的，就是按照实际情况，看能不能从一开始一步一步的走下来，就是角色与系统发生交互，最后系统­产生结果，比如像创建一个BLOG就属于一个用户目标，它可以一步步的在头脑中模拟出来：注册->登陆->激活->系统提示激活已经成功，告之个人的blog地­址。这是一个可以想象出的过程，所以创建blog就是一个用户目标层次上的目标。反之，像管理POST就不能像创建blog一样能够模拟出来，只是一个概要层次­上的目标，所以还要用到"HOW/WHY"原则找出用户级别的目标，拿管理POST为例，因为它是概要层次的目标，所以要用HOW原则来分解降低它的层次，HO­W
TO
管理POST，我们就会想到比如添加POST啊，删除POST啊，编辑POST啊，这些都是用户层次上的目标。如果有必要的话，可以给目标划分优先级。
3。根据总结出来的角色和目标，确定用例，一个建议的写法就是将所有的角色写在左边，利用头脑风暴将所有能够想到的用例写在右边的方框里，然后再将角色与用例连­线。用例可以根据角色要达到的目标归纳出，用动词加宾语的格式写出，动词是角色要进行的操作，宾语是角色要操作的对象（注：这个宾语与角色一般都是概念模型中的­类，所以一定要分清楚要操作的对象是谁，比如是blog还是post，这个宾语与角色也一定要在词汇表中明确定义，以免在归纳概念模型中发生混淆），这样就得到­了一个初步的用例图，然后将这个用例图整理一下，以便使思路更清楚，层次更明确，更易于理解，并还能在整理中发现被忽略的用例。根据生成的用例图完善词汇表，看­看角色与用例中的宾语是不是已经在词汇表中定义，如果没有的话就添加进去。补充："用例就是需求；从根本上说，用例是功能性需求，因为它表明了系统会怎样工作。­按照FURPS+需求类型来分，用例强调了"F"（功能性或行为性），但也可以用在其他类型上，特别是与某个用例紧密相关的那些类型上。"摘自《UML和模式应­用》第二版33页，其中的FURPS+代表着"F"：功能性需求；"U"：可用性需求；"R"：系统需求；
P？？（还不知道，书上没写上。。。）"S"：支持性需求
4这个时候已经有了一个初步的用例图了，接下来就进入了第一次迭代，从中选出比较关键的功能性的用例做为第一次迭代要完成的功能。比如在这个JBloge项目中­，visiter和admin的所对应的用例都不是主要的，一个blog系统主要实现的是blogger所对应用例要实现的功能，否则就不是一个blog系统，­所以自然的在第一次迭代中主要要考虑blogger角色所对应的用例。补充：1view功能一般不作为用例2一个好的设计，从安全角度admin不具备普通用户­权限。
补充：在画用例图中，include代表可重用，ex
**（又忘了怎么拼了）代表分支扩展。
5较详细的写出blogger所对用的所有功能性用例。写出概要级用例
 比如：1 用例名：Login
         主要参与者：User
         概述：用户提供用户名密码登录系统
         。。。。。。
         。。。。。。
         。。。。。。
       9 用例名：Edit a Post
         主要参与者：Blogger
         概述：blogger在自己的一个blog上编辑一个post

这就是blogger的初步总结出的所有用例的一个概要级描述
6。从这9个用例中总结出四个关键的功能性用标准的格式写出详细的用例说明，作为第一次迭代要实现的具体功能。补充：用例的详细描述分为四个阶段1概要的2假设­都是成功的3考虑失败的4写出建议的解决方案（明天上午要做的）
7。关于概念模型，在写出用例图的时候，已经可以引入了，角色和各个宾语，这些角色和宾语，比如blogger，blog，post都是概念模型，这时就可以引­入概念模型，画出类图，并发觉概念之间的关系，可以更为准确，深入的理解各个概念之间的关系，可以更为准确的描述系统及用例，并能为以后的设计提供更为明确的思­路。用例和概念模型以及词汇表的更新是相辅相成的，是并行的，相互协调的。补充：1概念模型的三要素是：概要，关联，和属性。2概念模型一般具有前瞻性，保证路­线正确，超前一到两个版本，也不能太多。

 

(PS:下面是当时公司的一个师父给做的补充,觉得挺有用的一起拷过来)

发件人：		James - 查看个人资料
电子邮件：		"James" j...@arcturus.com.cn

借花献佛：

摘录自Carig Larman的《UML和模式应用》第二版 第29页。希望对大家有所助益。

在统一过程（不仅仅是RUP）中，需求可以按照FURPS+模式进行分类，每个字母的含义
如下：
Functional（功能性）：特性、能力、安全性
Usability（可用性）：人性化因素、帮助、文档
Reliability（可靠性）：故障周期、可恢复性、可预测性
Performance（性能）：响应时间、吞吐量、准确性、有效性、资源利用率
Supportability（可支持性）：适应性、可维护性、国际化、可配置性

“+”是指一些辅助性的和次要的因素：
Implementation（实现）：资源限制、语言和工具、硬件等等
Interface（接口）：为外部系统接口所加的约束
Operations（操作）：系统操作环境中的管理
Packaging(包装)：提供什么样的部署、移交“介质”和形式等
Legal（授权）：法律许可、授权或其他有关法律上的约束。