UML学习2 - 用例图

由上一篇文章可知在程序设计中最基础的就是用例图(use case diagram), 因为他描述了系统的功能,也就是对应于系统需求, 整个程序也就是为了满足这些需求而实现的. 如果用例图描述错误, 将直接导致整个系统不满足需求, 也就是说整个系统是无用的.

用例图也就是对需求的抽象, 描述, 将需求从文字转变成图形, 在整个转变过程中使不明确的需求变的明确. 用例图只关心需求, 也就是系统需要具有哪些功能, 而不关心如何实现这些功能, 更不关心系统非功能部分,比如性能, 使用的开发语言, 技术等.

如何来画用例图呢? 由于用例对应于需求, 因此也就是说如何来用图形的方式描述一个需求呢.

首先应该是搞清楚 参与者(actor), 也就是与你的系统进行交互的东西(人或物), 严格来说, 参与者需要满足两个要求: (1) 与系统进行交互; (2)不是系统的一部分. 参与者并不一定都是人, 也可能是第三方系统等, 可以将其想象成一个黑盒子, 首先我们不能改变他, 而且也不关心参与者本身是如何实现的, 其次他需要与我们的系统进行相互.

比如我们在设计开发一个博客内容管理系统(weblog content management system, 以下简称CMS), 他有如下需求:

Requirement A.1

CMS系统允许管理员去创建新的博客账号, 该账号对应的个人详细信息作者认证数据库来确认.

针对上面的A.1需求, 最容易发现的参与者就是管理员, 他与系统进行交互(创建新的账号), 并且他不属于系统的一部分. 在用例图中, 参与者可以有两种表示方式: (1)火柴人(stick man); (2)元数据框(stereotyped box), 如下所示:

也可以通过以下的问题来找出参与者:

用例图的另一个组成部分就是用例(use case), 或者说任务(job), 也就是该需求到底要做什么事, 可能只是简单的登录, 也可能是复杂的多个全球数据库之间的分布式事务. 比如上面的需求A.1, 就是创建新的博客账号. 在用例图中, 用例用一个椭圆形框来表示, 如下所示:

最后就是将参与者与用例联系起来, 因为参与者就是要与系统发生交互的, 然后完成用例所示的功能或任务, 在用例图中使用 通信线(communication lines)来连接参与者与用例, 如下所示:

另外, 为了表明参与者不属于系统的一部分,可以使用 系统边界(system boundary)来表示, 如下所示:

到这里, 一个简单完整的用例图就画好了, 总结下来, 用例图主要包括2个组成部分:参与者和用例, 然后使用通信线将参与者(一个或多个)分别与用例连接起来, 最后可以使用系统边界来显式的指明系统内的部分(用例)和系统外的部分(参与者).

图形的一个好处就是简洁明了, 但这也恰恰是他的不足, 也就是不够详细充分, 比如如果有多个参与者, 那么哪个参与者是最重要的? 用例包含哪些步骤等等? 所以我们可以使用 用例描述(use case description)来对用例图加以补充描述. 在UML中用例描述一般包含以下内容, 但并没有严格的要求, 可以自行增删:

用例描述内容	解释和用途	解释和用途原文
相关需求(Related Requirements)	该用例图所描述的需求	Some indication as to which requirements this use case partially or completely fulfills.
目标背景(Goal in Context)	该用例在系统中的位置和重要性	The use case's place within the system and why this use case is important.
先决条件(Preconditions)	用例实现(发生)的前提	What needs to happen before the use case can be executed.
成功末端条件(Successful End Condition)	成功后系统的状态	What the system's condition should be if the use case executes successfully.
失败末端条件(Failed End Condition)	失败后系统的状态	What the system's condition should be if the use case fails to execute successfully.
主要参与者(Primary Actors)	用例的主要参与者	The main actors that participate in the use case. Often includes the actors that trigger or directly receive information from a use case's execution.
次要参与者(Secondary Actors)	用例的其他参与者	Actors that participate but are not the main players in a use case's execution.
触发条件(Trigger)	触发用例发生的事件	The event triggered by an actor that causes the use case to execute.
主要流程(Main Flow)	描述用例主要的正常流程	The place to describe each of the important steps in a use case's normal execution.
扩展流程(Extensions)	除主流程之外的其他情况	A description of any alternative steps from the ones described in the Main Flow.

下面就是针对需求A.1的用例描述: