基于UML的Blog系统分析与设计之三------用例建模

如何进行用例建模呢，这里主要分解为三步：

1.识别参与者(ACTOR)

参与者作为同系统交互的所有事物，它可以是人也可以是其它系统或硬件等。它不是系统的组成部分，是独立于系统而客观存在的。

在确定参与者时可以采用提问的方式来找出来，如谁是系统的主要用户？谁从系统获得信息等等。

 

Blog参与者：游客与管理员

2.确定用例。

确定用例的一个最重要的原则是必须从用户(参与者)角度来分析和设计系统”。识别用例也可以采用提问方式，如每个参与者的任务？

Blog用例[采用动词(短语)-名词(短语)形式]：

游客：浏览文章，发表评论，发表留言，搜索文章，

管理员：登陆系统,发表文章,编辑文章,删除文章,浏览评论,删除评论,浏览留言,删除留言,添加链接,编辑链接,删除链接,添加文章类型，编辑文章类型，删除文章类型。

 

3.画出用例图.

游客用例图：

 

 

 

管理员用例图：

 

 

有三种"用例关系"的定义需要在这里简短介绍一下：
 include（包含）:

指一个用例的行为包含了另外一个用例的行为，这是一种特殊的依赖关系。也就是"has a"的关 系。见上图中的（管理文章和编辑以及删除文章的关系）

generation（泛化）:

指一个用例（子用例）继承另外一个用例（父用例）的行为和含义，而该用例在继承了另外一个用例的行为和含义的基本上，还可以增加新的行为和含义以覆盖原有用例的行为和含义。比如 “按标题进行搜索文章”和“按内容进行搜索文章”与搜索文章之间”的关系。这种关系可以用"is a"来表示。

extend（扩展）:

如一个用例明显地混合了两种或以上的不同情况，即有可能发生多种事情也有可能不发生多种事情。而我们可以断定将这个用例分为一个主用例和一个或多个辅用例。比如图书馆管理系统中有一个还书的时候（还书用例），这个用例发生时，在超期的时候会发生罚款(罚款用例)情况，在没有超期的时候也有可能不发生。那么” 还书”与”罚款”之间是一种扩展关系。