首页 > 代码库 > uml系列(三)——用例图

uml系列(三)——用例图

        用例图是从用户的角度出发,描述系统功能的。在软件开发过程中,开发人员首先获知用户的需求,然后设计用例模型,在分析并设计系统来实现这些用例。在系统完成后,还要根据用例图来对系统进行验证。

              技术分享

 

         用例图主要介绍了一下部分:构成,描述和注意事项

         用例在需求分析阶段产生,那么,用例设计时地第一个问题就是这个软件的范围是什么,确定范围后,再去找出都有谁参与,都干些什么事。然后根据这些话出来用例图。

         首先是用例的构成:

                                                   技术分享                         

 

         用例图包括用例、角色两个部分。角色之间又有一些关系。这就是用例图需要表现的东西。

         用例图的参与者。它可以是一个人,也可以是电脑部件,或者是其他系统。他们拥有系统中的角色,通过对应的角色可以使用相应的权限。但他却不属于系统,而是处在正在建模的系统的外部。

         用例图的参与者的确定有以下原则:

              1.      谁是主要客户

               2.      谁用系统完成工作

               3.      谁维护管理系统

               4.      系统的硬件设置

               5.      系统需要与那些其他系统交互

               6.      系统从何处获取信息

          系统的参与者确定后,根据参与者使用系统的次数确定谁是主要参与者,谁是次要参与者。(不是根据权限哦)

确定了系统的参与者后,需要考虑的是这些参与者都做一些什么样的工作。也就是说这些对象都具有什么方法。它有两种表示方法:一种是一个椭圆,把用例的名称写在椭圆内部,另一种表示方式是把用例的名称写在椭圆的外部,但是通常是吧用例的名称写在椭圆的外部。

          首先,参与者要与用例进行通话,这就是他们的关联关系;接下来就是用例和用例之间的关系了:

                  1.扩展:假如说张三同学去图书馆借一本书,那么,就会有一个借书的时间长度的限制,如果过期没有还书,图书馆的管理老师就会请他去喝茶。在这个事件中,张三的“过期没有还书”的信息作为条件触发了“老师请张三去喝茶”的事件。

这就是用例的扩展,用例“老师请张三去喝茶”是用例还书是否超过规定时间的扩展用例。他们之间是依赖的关系。

                   2.包含:张三同学去借书时,他需要先看看有没有这本书,然后才确定能不能借书。

张三同学的“借书”用例中,包含有“验证是否该书以借出”的用例。这就是包含关系。他们之间也是依赖关系。

                   3.泛化:张三同学去还书,发现还书处增加了电子还书的功能。老师可以手动输入张三的借书证号码,也可以通过扫描仪器来扫描张三的借书证而得到借书证号。

张三的还书中,登记借书借书证号的用例分成了手动输入和电子录入两种,这两种用例被称为子用例而登记借书证号是父用例。子用例继承父用例,这就是泛化关系。

            用例构成说完了,接下来就是用例的描述了。

            如何描述用例图呢?

            还是老规矩,先来一张图:

                           技术分享

 

             用例也有标识,那就是用例的名称。张三每天给小丽打三个电话。

              在这个事件中,“打电话”用例需要先拨号,然后接通。这就是事物的流程,也就是事件流;在电话接通之前,会验证张三拨打的电话号码是否正确可以播出,这就是前置条件;电话接通后,双方处于可以通话的状态这就是后置条件;张三一天给小丽打三次电话中的“三次”就是使用频率。

              用例图使用的时候有一些注意事项:

                                  技术分享

 

             用例的粒度,用例图是不固定的,粒度可以设置的很大,也可以设置的很小,具体如何设计,还是要看设计人员的考虑。不过一般是从粗粒度到越来越细的去设置,当然粒度不是越细越好,而是合适就好。

            然后就是用例图的结构要合理。这包括用例内部的结构要合理和用例之间的结构设计要合理。

uml系列(三)——用例图