随笔 - 24  文章 - 3 评论 - 36 trackbacks - 1
<2005年10月>
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345

天气太热,在家闭关……

与我联系

搜索

 

常用链接

留言簿

我参加的小组

我参与的团队

随笔分类(22)

随笔档案(23)

文章分类(2)

友情链接

积分与排名

  • 积分 - 31573
  • 排名 - 1908

最新评论

阅读排行榜

评论排行榜

1、主成功场景就是主执行者完成了目标,所有项目相关人员的利益都被满足了的场景。

2、主成功场景和所有场景扩展都包含的元素

 

主成功场景

扩展场景

场景执行的条件

前置条件加上触发事件

扩展条件

完成的目标

用例的名称

完成用例目标,或者是在处理扩展场景后重新进入主成功场景

执行步骤集

场景主体

结束条件

结束时完成的目标

作为场景片断的、可能的扩展集

用例模板中的扩展部分

可以嵌入到扩展体中,或者写在扩展体里面,或者就写在扩展体的后面

3、场景主体:每个场景或片段被描述为由不同执行者完成目标的活动序列

序列即无判断和循环,这是用例描述的基本特点。

这一节解释了第二章的一个疑问:

场景主题必须把这三步描述完成(括号里文字是例子):两个执行者之间的交互(“顾客输入地址”)——为了保护项目相关人员利益的确认过程(“系统确认PIN密码”)——满足项目相关人员利益的内部变化(“系统从余额中扣除一定数量的金额”)

4、执行步骤时对用例的补充,并且都有统一的语法形式,在一个简单活动中,执行者完成任务或向另外的执行者发送信息。

5、执行步骤的10大准则

1)使用简单的语法;

句子结构应该非常简单:主语……谓语动词……直接宾语……前置短语

例如                  系统……从帐户余额中扣除……一定数量……

2)明确地写出“谁控制球”;

作者举了踢足球的场景的例子,说明了不管步骤的执行者如何变化,都要遵循(1)描述的格式。

3)从俯视的角度来编写用例;

从用户的角度来写用例,而不是从系统内部来描述系统

4)显示过程向前推移;

可能是翻译的问题,意思应该是如果过程繁杂,超过了9步,那么考虑提高目标层次,即“向前推移”

5)显示执行者的意图而不是动作;

通过操纵系统的用户界面来描述用户的动作,这是在编写用例时常见的一种严重错误,它使得编写的目标处于一个很低的层次。我把它叫做“界面细节描述(interface detail description)”。在需求文档中,我们只关心界面所要达到的意图,总结在执行者之间传递的信息。可将这些低层次的步骤合并成一个步骤。

6)包含“合理”的活动集;

用例描述为了表现一个事务,分解成了四个步骤,而这些步骤各有其复杂度,书中给出了五种形式,一种比一种分步多,作者倾向于中间第三和第四种形式,不过他也提出要视具体步骤复杂度来确定采用什么形式

7)“确认”而不是“检查是否”

这是一个经常犯的错误,写用例不是写程序流程,不需要用选择语法,需要选择的时候,在扩展场景里体现。

8)可选择地提及时间限制;

9)习惯用语:“用户让系统A与系统B交互”;

要分开来写,用户与系统A怎么怎么样,然后系统A和系统B怎么怎么样,这样用户才能看的懂。

10)习惯用语:“循环执行步骤XY,直到条件满足”;

同(7),但如果需要重复的话,可直接在重复的步骤的前面和后面说明即可。

总之,这10大原则,目的就是为了让用例成为用户和开发人员沟通的桥梁,所以语言要简单易懂,而且要逻辑清晰。

6、步骤编号使步骤更清晰,并在扩展部分给出引用的位置。完整的用例格式需要编号。
posted on 2005-10-18 00:32 spgoal 阅读(1934) 评论(2)  编辑 收藏 网摘 所属分类: 软件工程

FeedBack:
1."序列即无判断和循环,这是用例描述的基本特点",对于您的这句话,我不太理解,可否举例子.
2."10习惯用语:“循环执行步骤X到Y,直到条件满足”;
同(7),但如果需要重复的话,可直接在重复的步骤的前面和后面说明即可。"
可否举一个具体的例子?
3."(4)显示过程向前推移;
可能是翻译的问题,意思应该是如果过程繁杂,超过了9步,那么考虑提高目标层次,即“向前推移”"
我认为应该没有翻译错,我的理解:每一个步骤(过程)都要朝用例目标前进.




  回复  引用    
Guideline 4: It shows the process moving distinctly forward
The amount of progress made in one step is related to how high or low the use case goal is. In a
summary or white use case, the step probably moves forward an entire user goal. In a subfunction
use case, it moves forward a much smaller amount. If we see the step "User hits the tab key", either we are looking at a deep indigo (or black) use case, or the writer has simply chosen too small of an
action to describe.
The mistake of choosing very small steps shows up in the length of the use case. If a use case has
13 or 17 steps, it is quite likely that the sentences are not moving the goal forward very much. The
use case is easier to read and clearer and contains the same essential information when we merge
those small steps to get one that moves the process distinctly forward. I rarely encounter a wellwritten
use case with more than 9 steps in the main success scenario.
To find the slightly higher-level goal for a step, ask, "Why is the actor doing that?" (as described
in “Merge steps, keep asking "why"” on page 76). The answer to that question is probably the goal
you need for the step, although you may have to ask the question several times to get the answer
you want. Here is an example of raising the goal level by asking:
User hits tab key.
Why is the user hitting the tab key? To get to the address field.
Why is she trying to get to the address field? Because she has to enter her name and
address before the system will do anything.
Oh! She wants to get the system to do something (probably the use case itself), and to get
it to do anything, she has to enter her name and address.
So the action sentence that moves the process distinctly forward is
User enters name and address

  回复  引用    



发表评论

昵称: [登录] [注册]

主页:

邮箱:(仅博主可见)

评论内容:

  登录  注册

[使用Ctrl+Enter键快速提交评论]

0 256815




相关文章:

相关链接: