软件工程用例图 题目

1、用例图练习，一个售票系统，参与者包括售票员，主管和公用电话亭。公共电话亭是另一个接收顾客预订请求的系统。顾客不直接与售票系统互动。使用案例包括通过公共电话亭或售票员购买车票、购买预订车票(仅通过售票员)和售票主管(应主管的要求)。买票和订票包括一个共同的部分，那就是用信用卡支付。有三个联系和区别，包括，扩展和一般化，以及http:/代码通用性：它们都从现有用例中提取公共信息作为单个用例，然后以不同的方式重用这个公共用例，以减少模型维护的工作量。1。包含关系：使用一个包含用例来封装一组跨越多个用例的相似动作(行为片段)，这样就可以重用多个基本用例。基本用例控制所包含用例之间的关系，以及所包含用例

2、的事件流是否将被插入到基本用例的事件流中。基本用例可以依赖于包含的用例的执行结果，但是任何一方都不能访问另一方的属性。包含关系的典型应用是重用，即定义中提到的场景。但是有时当一个用例的事件流过于复杂时，为了简化用例的描述，我们也可以将某个事件流抽象成一个包含的用例；相反，当用例的划分过于精细时，可以抽象出一个基本用例来包含这些细粒度的用例。这种情况类似于用过程设计语言将程序的某个算法打包成一个子过程，然后从主程序调用这个子过程。例如，在商业中，总是有维护某些信息的功能。如果它被用作用例，新的创建、编辑和修改必须在用例细节中描述，这太复杂了；如果划分成新的用例、编辑用例和删除用例，这种划分就太精

3、细了。此时，包含关系可用于阐明关系。2，扩展扩展关系：用一个扩展用例在基本用例中封装一个相对独立和可选的动作，然后从基本用例中声明的扩展点进行扩展，从而使基本用例更加简洁和集中。扩展用例向基本用例添加新的行为。扩展用例可以访问基本用例的属性，因此它可以根据基本用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对于基本用例是不可见的。对于扩展用例，在基本用例上可以有几个扩展点。例如，系统允许用户导出和打印查询结果。对于查询，是否可以导出或打印是一样的，导出和打印是不可见的。导入、打印和查询相对独立，新的行为被添加到查询中。因此，扩展关系可以用来描述：3泛化泛化泛化关系：子用例与父用例相似，但

4、表现出更特殊的行为；子用例继承父用例的所有结构、行为和关系。子用例可以使用父用例的一部分行为或者重载它。父用例通常是抽象的。泛化关系很少在实际应用中使用，子用例中的特殊行为可以作为父用例中的可选流而存在。例如，在业务中可能有很多事情需要部门领导的批准，但是领导的批准过程非常相似。这时，它可以表示为一般化的关系：2个网上购物系统，(1)整个系统用例图、在uml中的扩展和一般化的区别，而一般化的表达式类似于oo术语“继承”或“多态”。uml中用例的泛化过程是将不同用例之间的合并部分抽象成独立的父用例，并将非合并部分分离成它们自己的子用例。包含和扩展的过程类似于一般化的过程，但是它们对优化用例关系的强调是不同的。具体如下：(1)概括侧重于子用例之间的互斥；包含侧重于被包含的用例向参与者提供的服务的间接性；扩展关注扩展用例的触发不确定性；具体如下：由于用例是系统提供的服务的统一建模语言表达，服务的过程在所有用例场景中都是不可避免的，但是根据发生的条件，发生可以分为以下两种情况：无条件发生：确定发生；条件发生：它可能不会发生，它是否发生取决于系统状态；因此，考虑到用例和系统状态的三种关系，泛化和包含用例属于无条件用例，而扩展属于条件用例。此外，用例的存在是为了给actor提供服务，但是用例提供服务的方式可以分为间接的和直接的。据此，一般化的子用例提供直接服务，而包含的用例提供间接