1.参与者
UML将参与者定义为与系统交互的外部事物或人,主要分为三个不同的阵营:
- 用户
- 管理员
- 外部程序和设备
参与者有两个共同的特点
- 对于应用程序来说它是外部的
- 它会主动、积极地与我们的系统交互
通过组织参与者的用法描述,可以促使软件责任面向每个参与者。最终我们将利用到这些用法描述并以我们想要保留的系统属性为指导。在这个阶段,为了开发单一的面向对象模型,我们需要的是更高层次的描述,而不是一个包含大量细节、意图和含义的对象模型。对象模型只能为问题提供一个解决方案,且并不包括用户的隐含需求、意图和日常关注。
2.用例
用例非常适合用来刻画软件的外部用户视角。通常使用三种形式的用例
- 简单文本叙述(narratives)
- 由有序的步骤组合的情景(scenarios)
- 强调用户和系统之间对话的会话(conversations)
根据用户的不同意图,用例能在不同细节层次上进行表达。我们可以先写出高层次的概要,然后向它添加细节以及用户与程序间交互顺序和行为顺序。形式的选择取决于表达的内容。
若用户需要,一个用例可以用多种的形式表达。通常,我们从撰写叙述性的高级概要着手,待合适的时候在撰写一些情景或会话来丰富其内容。
3.情景
用例叙述的是用户能够执行哪些任务,而情景描述的是执行一项任务的特定步骤。同一用例可以有多种执行方式。
如果需要更具体地描述任务的执行过程,那么我们就会撰写情景来描述特定场合的具体行为和信息。如果用例需要更多的细节,并且我们也强调用户与系统之间的互动,则需要将情景叙述扩展为会话。
4.会话
以对话的形式描述用户和系统间的互动即为会话。会话的意图是清晰两方面的责任
- 触发对话的用户责任
- 监控并回应用户行为的软件责任
更加细节性的会话清晰地展示了应用软件对用户行为做出的响应。
每个会话都会有两个相互独立的部分:用户行为和输入以及软件的相应响应。这些响应是软件行为的初级列表,在设计系统,分配对象责任和行为时,设计人员将参考这些陈述性文字。
5.细节
在大部分设计者能构建一个工作系统和大部分测试者能撰写测试用例之间,会话和场景会需要更多的细节信息。例如:处理错误的惯例是什么?默认的参数怎样设定?
以下是相关描述:
- 需要用户输入的信息,当缺少用户输入时,则采用缺省值
- 在关键系统行为执行前,必须检查约束限制
- 用户可能改变执行流程的决定点
- 关键算法的细节
- 任何重要反馈信息的内容和时机
- 相关规范说明的参考