人人都是领域专家-用例图

/**

*  转载请注明作者longdick    http://longdick.iteye.com

*

*/

 

相关帖子：

1、人人都是领域专家-用例图

2、人人都是领域专家-活动图

3、人人都是领域专家-类图

4、人人都是领域专家-顺序图

5、人人都是领域专家-类图关系化

6、人人都是领域专家-类图关系说明

 

一个好的设计能使开发事半功倍，好的设计来源于好的需求。这就需要需求分析师帮我们开发人员提供精炼，清晰，准确的需求报告。需分将采集来的需求用UML（Unified Modeling Language ）描述出来，我称之为需求建模。

需求阶段建模的过程中涉及到的有用例图（usecase diagram）和活动图（activity diagram）。

下面就对网上购物的应用进行用例建模，以此举例用例建模的过程。

当然任何事情都不能一蹴而就，用例建模也是一样。用例建模的过程可能分好几次迭代进行，一开始粒度可能较粗，随着迭代进行而逐渐精化。所以不需要一开始就妄想考虑的面面俱到。

 

1、网上购物的需求描述非常简单：无非就是用户在一个购物网站上购买商品。用用例图描述如下，有一个参与者和一个用例。非常简单，目标明确。

 2、然后自评一下，觉得购买商品这个用例粒度太粗了，还有细化分解的可能。于是就将该用例分解。这个过程需要和客户更好的沟通。

 3、用例分解以后，新的用例粒度更细，权责也更明确了。但是客户反映有些用例是购买商品的必选步骤，有些则不是。这时如何在用例图上体现这个关系呢？

我们可以利用include和extend概念来描述，include描述的是主用例和次用例之间的包含关系即必选关系，extend描述的是可选关系。include关系箭头是主用例指向次用例，extend关系箭头是次用例指向主用例。

4、随着迭代的推进，发现有些用例可以有多种实现方式，不同的实现方式可能有不同的活动图和顺序图。故在用例图上使用泛化关系描述之。泛化关系使用一个空心的箭头，可以把它想象成继承关系。

5、用例精化的差不多了，还有别的参与者吗？用户提醒我们说，除了普通会员可以购买商品以外，还有一类Vip会员可以以折扣价购买一些特价商品。so，用例需要添加新的参与者和新的用例。

6、从上图可以看出，Vip会员就是特殊化的普通会员。然后，我们也可以对参与者泛化。但是参与者泛化会带来一些理解上的复杂性。可以的话，一般不推荐使用。

 7、在重新审视需求，和客户充分沟通以后，本着简单，清晰有效，且不引起歧义的宗旨，我们重新修订整个用例，得到结果如下。当然这可能还没完，可能还有进一步挖掘需求和用例精化的空间。可以在保证进度前提下继续迭代建模。在建模的世界里，没有最好，只有更好。