我的UML用例图

我的用例图

2012-03-06

背景感言：在大学混日子的时候，打酱油的选修课却在实际工作中，不经意就给我一个突然袭击，悔不当初啊……

 

背景知识准备：

1.UML：Unified Modeling Language 的简称，为面向对象软件设计提供的统一的、标准的、可视化的建模语言。适用于描述以用例为驱动，以体系结构为中心的软件设计的全过程。

总的来说，UML给开发团队提供了一种简洁明了的沟通工具，和设计模式一样，给开发者一个统一的，没有二义性的沟通，尤其在需求不清晰的时候，可以给每个人明确的概念，减少大家扯皮的机会。

2.用例是UML事物中的构件事物（UML模型的静态部分，描述概念或物理元素）的一种，代表一个系统或系统的一部分行为，是一组动作序列的集合。

总的来时，用例就是一个独立的功能模块

3.主要UML图之间的关系

我的用例要点理解：

用例图：被称为参与者（actor）的外部用户所能观察到的系统功能的模型图。（参与者发起用例（系统外部可见的一个系统功能单元））。

用处：多用在静态建模阶段，业务建模和需求建模。

尤其是在需求建模的时候，用例图让产品设计者和开发者理解产品是个什么样子，具体有功能点的明确意义，避免大家在探讨需求时偏离了主题，通俗的讲就是驴头不对马嘴。

 

用例图的关系：

角色（Actor）之间的关系，泛化（is A），可以通俗的理解成继承关系。

特殊方B继承了一般方A，并增加了新特性。

角色（Actor）用例间关系：关联。

用例间关系

1）包含（has A）

MSDN: An including use case calls or invokes the included one. Inclusion is used to show how a use case breaks into smaller steps. The included use case is at the arrowhead end.

箭头指向的用例为被包含的用例，成为包含用例；出发方为基用例。包含用例必选，是基用例的一部分，必须被执行，不改变基用例的行为。

 

包含用例，总是抽象的，基本用例关心的是包含用例的结果，而不关心如何获得的。基本用例和包含用例的用例实体是不能互相访问属性的。

 

使用场景：1）从基本用例中分解出这种行为，它对于了解基本用例的主要目的不重要，只有它的结果才比较重要。

2） 分解出两个或多个用例所共有的行为（封装）

3）扩展

MSDN: An extending use case adds goals and steps to the extended use case. The extensions operate only under certain conditions. The extended use case is at the arrowhead end.

箭头指向的用例是被扩展的用例，基本用例；箭头出发的用例是扩展用例。扩展用例可选，没有扩展用例，基用例也是完整的。扩展用例在一定条件下才会执行，并且会改变基用例的行为。

基本用例自身应该是完整的，即基本用例应该是可理解并且有意义的，而不必引用任何扩展用例。但是基本用例并不独立于扩展用例，因为如果无法遵循扩展用例，就不能执行基本用例。

基本用例必须声明扩展点，而扩展用例只能在扩展点上为基本用例增加新的行为和含义。在扩展关系中，箭头的方向是从扩展用例到基本用例的，这与包含关系不同。

扩展用例是隐含插入，并不在基本用例中显示。

 

使用场景：1）说明用例的某一部分是可选的系统行为。把模型中可选和必选分开。

2）只有在特定条件下或异常情况下才执行的分支流，如触发告警。

3）表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。所插入的行为段和插入的顺序取决于基本用例与主角进行的交互。