【UML九种图系列】之用例图

 

用例图：

    由参与者（Actor）、用例（UseCase）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。用例图描述了系统提供的一个功能单元.用例图的主要目的是帮助开发团队以一种图形化的方式理解系统的功能需求。

 

问：什么时候画用例图？如何画？

答：一般在需求分析阶段确定需求的时候画用例图。首先，确定参与者、用例（分析各个角色有何功能）、关系。

 

问：用例图中的关系：

答：主要分为3类：

参与者与参与者之间：泛化

参与者与用例之间：关联关系Association

用例与用例之间：包含（include）、扩展（extends）、泛化

 

   1、包含关系：

     

    强调“必须”。大用例包含小用例，小用例是大用例的一部分，如果没有小用例的话，大用例是不完整的。生命周期相同，大用例消亡时，小用例也消亡。

解析：如果想完成上机这项功能的话，包含验证卡号、检查上机状态、检查余额这三项功能。上机对于机房收费系统来说是大用例，而验证卡号、检查上机状态、检查余额是小用例。如果没有验证卡号、检查上机状态、检查余额这些小用例的话，则上机这项大用例是不完整的。而且，当上机这项功能消亡的话，其小用例也会随即消失。

 

2、扩展关系：

             

强调“扩展/可选”。主用例扩展辅助用例，对于主用例来讲是系统的主要功能，辅助用例只是一个很小的功能。辅助功能的实现对于主用例来讲是可有可无的。生命周期不相同，先有的主用例，后有的辅助用例。

       

解析：查询上机记录用例（主用例）扩展为导出Excel表格用例（辅助用例）。对于机房收费系统来说，查询上机记录是主要的功能，可以导出为Excel，也可以不导出，对于系统来说，这项功能是可有可无的。而且，只有在查询上机记录后，才可以导出为Excel，存在先后的关系。

 

3、泛化关系：

           

强调“由一般到特殊”。子用例表示父用例的特殊形式，子用例继承了父用例的行为和属性，也可以增加新的行为和属性或覆盖父用例中的行为。

        

解析：父用例为查询上机记录是一项需求/功能，但是并没有定义查询的方式，你可以选择按照卡号进行查询，或按照学号进行查询，或按照上机日期进行查询。