By 高焕堂 2010/11/01
Android_从需求分析到设计
孰悉Use Case叙述(Use Description)
1. Use Case图
兹以”播放 MP3音乐”为例来绘制其用例图，如下：
从这用例图里，可以看出来，目前含有两个用例：
- UC-001：播放(Play)音乐。
- UC-002：播放(Play)某首音乐。
从上图可以看到，用例之间有两种关系，分别是「包含」(include)和扩充(extend)关系。
「包含」(include)关系
两个用例之间可以有「包含」(include)关系，用以表示某一个用例的对话(Dialog)流程中，包含着另一个用例的对话流程。一旦出现数个用例都有部份相同的对话流程时，将相同的流程记录在另一个用例中，前者称为「基础用例」(Base Use Case)，后者称为「内含用例」(Inclusion Use Case)。如此，这些基础用例就可以共享内含用例，而且未来其它的用例只要建立包含关系，就可以立即享用已经在其它用例定义好的相同对话流程了。[歡迎光臨 高煥堂 網頁： http://www.cnblogs.com/myEIT/ ]
简而言之，<<include>>关系是来自于抽象的动作(Abstraction)，即从数个不同的用例之中，抽象出共同的部分，而成为可以重用的「内含用例」。「内含用例」是「基础用例」对话流程中的必备部分。例如，上图里的<UC：选取音乐>用例是<UC：播放(Play)某首音乐>用例对话流程中”不可或缺的”一部分。
扩充(extend)关系
两个用例之间可以有「扩充」(extend)关系，用以表示某一个用例的对话流程，可能会依条件而临时插入到另一个用例的对话流程中；前者称为「扩充用例」(Extension Use Case)，后者称为「基础用例」(Base Use Case)。有了扩充关系后，便可以将特定条件下才会引发的流程表述于扩充用例中。当执行基础用例时，可以单纯地执行基础用例的对话流程；但是在特定条件发生时，则会额外插入并执行扩充用例所表述的对话流程。例如，上图里的<UC：停止(Stop)>用例是<UC：播放(Play)某首音乐>的扩充用例，它是整个对话流程中”可选择性的”部分。
这<<extend>>关系来自于用例内执行活动的过程有分为主要过程(Main Course) 及替代过程(Alternative Course)。例如，<UC：播放(Play)某首音乐>的过程中，如果用户不想听时，会选择按下<Stop>按钮而结束播放该曲音乐。
所以<UC：播放(Play)音乐>描述着A 这项Scenario。而<UC：播放(Play)音乐>的用例叙述加上<UC：停止(Stop)>的用例叙述，共同描述B 这项Scenario。图中的A是个正常的情境(Normal Scenario)，而新附加的用例表达出特殊或替代情境(Alternative Scenario)。
2. 用例叙述
基于上述的用例模型概念，兹分别撰写其用例叙述，如下：
用例叙述(UC-001)
|
Use Case ID |
UC-001 |
|
|
Use Case名称： |
播放(Play)音乐 |
|
|
目的： |
用户听一首默认(Default)的MP3音乐 |
|
|
系统名称： |
“播放MP3音乐”系统 |
|
|
Client 种类 |
人 |
|
|
主要程序： |
||
|
user action |
system response |
|
|
1. 按下< Play>按钮 |
|
|
|
|
2. 播放默认的MP3音乐 |
|
|
3. 按下<Exit>按钮 |
|
|
|
|
4. 结束此用例 |
|
|
替代程序： |
||
|
2a. 播放时，如果User按下<Stop>按钮，就结束播放该首音乐 |
||
用例叙述(UC-002)
|
Use Case ID |
UC-002 |
|
|
Use Case名称： |
播放(Play)某首音乐 |
|
|
目的： |
用户选取一首MP3音乐，然后听该首音乐 |
|
|
系统名称： |
“播放MP3音乐”系统 |
|
|
Client 种类 |
人 |
|
|
主要程序： |
||
|
user action |
system response |
|
|
|
|
|
|
2. 播放该首MP3音乐 |
|
|
3. 按下<Exit>按钮 |
|
|
|
|
4. 结束此用例 |
|
|
替代程序： |
||
|
2a. 播放时，如果User按下<Stop>按钮，就结束播放该首音乐 |
||
☆
[Go Back]
