UML 用例的粒度

来自“太初有产”

 

一个用例到底因该多大呢？这个问题恐怕很难说得清楚。按照我们对用例的定义来说，用例就是用户(外部系统)和系统的一次典型交互。但是有可能这个交互特别复杂。我们来看GIS系统中的一个很普通的交互：添加图层。对于添加图层这个用例用户的要求显然是系统能够记住这个图层并在系统中其它地方使用，还有一个直观的要求就是图层要被显示出来。

      下面是和这个用例有关的系统需求的原始文字描述:

      系统需要支持添加图层的功能。图层的数据源要求支持Shapefile,ArcSDE FeatureClass，ArcGIS Personal Geodatabase FeatureClass,CAD DWG文件,JPEG影像文件，TIFF影像文件。添加图层后要求立即在当前屏幕范围内显示图层。添加图层后系统其它地方可以使用这个图层来做相关的操作。

    这段需求一共有四句话，第一句说明这个需求的功能，第二句规定需要支持的格式，第三、四句说明要达到的效果。

    下面我们使用前面的方法来表达这个用例:

    用例编号: U-carto-001(表示和制图有关的第001号用例)

    用例名称：添加图层

    相关需求: R-carto-001(表示和制图有关的第001号需求)

    语境目标: 添加新图层到系统中。

    前提条件：1.系统处于正常运行模式

                        2.用户所指定的数据源有效

    成功结束状态:  图层添加到系统中，并向用户显示出来

      失败结束状态:  添加图层的要求被拒绝。

    主要参与者:      用户

      次要参与者:

    触发器:          用户要求添加新图层 

    包含案例:    U-datasource-001(检查数据有效性),U-carto-002(显示数据)

      主要流程:    步骤      动作

                            1.      用户要求添加新图层

                            2.      用户选择数据源类型

                            3.   系统检查数据有效性(执行U-datasource-001）

                            4.      系统构造图层并添加到图层列表中

                            5.   系统将当前显示区域设定为图层的数据范围，

                     并刷新(执行U-carto-002)

                            6.      用例结束

      扩展步骤:      2.1    用户取消了操作(由于没有找到它所期望的类型，例如MapInfo的TAB文件格式) 

                              2.2  用例结束 

                            3.1 数据源无效(例如 ArcSDE 服务连接不上，Shapefile已经被破坏)

                              3.2  提示用户数据源不可用

                            3.3 用例结束 

 

      通过这种描述方式，尤其在熟悉了其中的包含用例和主要流程之后，我们可以很快发现这个一个粗粒度的用例。因为它包括了其它的用例。更因为熟悉GIS系统的人知道，它所包含的 数据有效性检查和 显示数据 这两个用例本身就都是很庞大的。它们自身就还包含有非常多的更小的用例。

      那么，通过这个例子。我们能够学习到什么呢？

      实际上，在我开始使用用例的时候，用例的粒度问题就一直在困扰着我。因为我一直以为用例都是比较简短的和明确的。这样就导致一直问题，我一开始就把系统分解的过细，到了最后系统各个用例之间一片混乱。因为我可能每天都在变化我的想法。

      在仔细研究后，我几乎可以得出这样的结论。那就是用例是有层次性的。这种层次性由用例的《include》和《extend》关系来表达。而且通过用例的层次关系，也可以更好的对系统建模。使得用例图更加有利于用来在系统架构这个过程中作为参考依据。