用例图的组成要素 用例图

什么是用例图,什么是e-r图ER图是实体-关系图,包括一些对象和对象的联系,还有对象的属性
用例图是指由参与者(Actor)、用例(Use Case)以及它们之间的关系构成的用于描述系统功能的视图
在软件工程中“用例”和“用例图”有什么区别是什么?【用例图的组成要素 用例图】一、主体不同
1、用例:是软件工程或系统工程中对系统如何反应外界请求的描述
2、用例图:是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果 。
二、特点不同
1、用例:一个用例代表了系统的一个单一的目标 。
2、用例图:由参与者(Actor)、用例(Use Case)、系统边界、箭头组成,用画图的方法来完成 。
三、作用不同
1、用例:用例将系统的功能范围分解成许多小的系统功能陈述 。
2、用例图:主要的作用有三个:获取需求;指导测试;还可在整个过程中的其它工作流起到指导作用 。
参考资料来源:百度百科-用例
参考资料来源:百度百科-用例图
用例图的作用用例图主要的作用有三个:(1)获取需求;(2)指导测试;(3)还可在整个过程中的其它工作流起到指导作用 。
元素之间的关系用例图中包含的元素除了系统边界、角色和用例,另外就是关系 。关系包括用例之间的关系,角色之间的关系,用例和角色之间的关系 。
角色之间的关系
角色之间的关系 。由于角色实质上也是类,所以它拥有与类相同的关系描述,即角色之间存在泛化关系,泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为 。
用例之间的关系:
包含关系:基本用例的行为包含了另一个用例的行为 。基本用例描述在多个用例中都有的公共行为 。包含关系本质上是比较特殊的依赖关系 。它比一般的依赖关系多了一些语义 。在包含关系中箭头的方向是从基本用例到包含用例 。在UML1.1中用例之间是使用和扩展这两种关系,这两种关系都是泛化关系的版型 。在UML1.3以后的版本中用例之间是包含和扩展这两种关系 。
泛化关系:代表一般与特殊的关系 。它的意思和面向对象程序设计中的继承的概念是类似的 。不同的是继承使用在实施阶段,泛化使用在分析、设计阶段 。在泛化关系中子用例继承了父用例的行为和含义,子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义 。
扩展关系的基本含义和泛化关系类似,但在扩展关系中,对于扩展用例有更多的规则限制,基本用例必须声明扩展点,而扩展用例只能在扩展点上增加新的行为和含义 。与包含关系一样,扩展关系也是依赖关系的版型 。在扩展关系中,箭头的方向是从扩展用例到基本用例,这与包含关系是不同的 。
用例的泛化、包含、扩展关系的比较 。一般来说可以使用“is a”和“has a”来判断使用那种关系 。泛化和扩展关系表示用例之间是“is a”关系,包含关系表示用例之间是“has a”关系 。扩展与泛化相比多了扩展点,扩展用例只能在基本用例的扩展点上进行扩展 。在扩展关系中基本用例是独立存在 。在包含关系中在执行基本用例的时候一定会执行包含用例 。如果需要重复处理两个或多个用例时可以考虑使用包含关系,实现一个基本用例对另一个的引用 。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系 。当描述正常行为的变形希望采用更多的控制方式时,可以在基本用例中设置扩展点,使用扩展关系 。扩展关系比较难理解,如果把扩展关系看作是带有更多规则限制的泛化关系,可以帮助理解 。通常先获得基本用例,针对这个用例中的每一个行为提问:该步骤会出什么差错?该步骤有不同的情况工作怎样以不同的方式进行等,把所有的变化情况都标识为扩展 。通常基本用例很容易构造,而扩展用例需要反复分析、验证 。当我们发现已经存在的两个用例间具有某种相似性时,可以把相似的部分从两个用例中抽象出来单独作为一个用例,该用例被这两个用例同时使用,这个抽象出的用例和另外两个用例形成包含关系 。
用例之间的关系举例
包含:业务中,总是存在着维护某某信息的功能,如果将它作为一个用例,那新建、编辑以及修改都要在用例详述中描述,过于复杂;如果分成新建用例、编辑用例和删除用例,则划分太细 。这时包含关系可以用来理清关系 。
扩展:系统中允许用户对查询的结果进行导出、打印 。对于查询而言,能不能导出、打印查询都是一样的,导出、打印是不可见的 。导出、打印和查询相对独立,而且为查询添加了新行为 。

秒懂生活扩展阅读