《利用Enterprise Architect画用例图心得》由会员分享，可在线阅读，更多相关《利用Enterprise Architect画用例图心得（8页珍藏版）》请在金锄头文库上搜索。
1、利用利用 EnterpriseEnterprise ArchitectArchitect 画用例图画用例图在画用例图的时候，理清用例之间的关系是重点。用例的关系有泛化(generalization)、扩展(extend)和包含(include)。其中 include 和 extend最易混淆。下面我们结合实例彻底理清三者的关系。 1.1. 基本概念基本概念用例图（Use Case Diagram）:用例图显示谁是相关的用户，用户希望系统提供什么服务（用例） ，以及用例之间的关系图。用例图主要的作用是获取需求、指导测试。 用例图的 4 个基本组件：参与者(Actor)、用例(Use Case)、
2、关系(Relationship)和系统。 泛化(generalization)：泛化关系是一种继承关系，子用例将继承基用例的所有行为，关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例。 扩展(extend)： extend 关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。extend 的基用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。 extend 关系在用例图中使用带箭头的虚线表示(在线上标注)，箭头从子用例指向基用例。包含(include)：
3、include 为包含关系，当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include 关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include 关系在用例图中使用带箭头的虚线表示(在线上标注)，箭头从基用例指向子用例。 2.2. 用例模型用例模型用例模型用来记录系统的需求，它提供系统与用户及其他参与者的一种通信手段。2.12.1 执行者执行者用例图显示了系统和系统外实体之间的交互。这些实体被引用为执行者。执行者代表角色，可以包括：用户，外部硬件和其他系统。执
4、行者往往被画成简笔画小人。也可以用带actor关键字的类矩形表示。 在下图中，执行者可以详细的泛化其他执行者:2.22.2 用例用例用例是有意义的单独工作单元。它向系统外部的人或事提供一个易于观察的高层次行为视图。 用例的标注符号是一个椭圆。使用用例的符号是带可选择箭头的连接线，箭头显示控制的方向。下图说明执行者 “Customer“使用 “Withdraw“用例。用途连接器（uses connector）可以有选择性的在每一个端点有多重性值，如下图，显示客户一次可能只执行一次取款交易。但是银行可以同时执行许多取款交易。2.32.3 用例定义用例定义一个典型的用例包括:名称和描述需求约束情形情
5、形图附加信息。名称和描述名称和描述用例通常用一个动词词组定义，而且有一个简短的文字说明。需求需求需求定义了一个用例必须提供给终端用户的正式功能性需求。它们符合构造方法建立的功能性规范。一个需求是用例将执行一个动作或提供多个值给系统的约定或承诺。约束约束一个约束是一个用例运行的条件或限制。它包括：前置条件，后置条件和不变化条件 。前置条件指明了用例在发生之前需要符合的条件。后置条件用来说明在用例执行之后一些条件必须为“真“。不变化条件说明用例整个执行过程中该条件始终为“真“。情形情形情形是用例的实例在执行过程中，事件发生流程的形式描述。它定义了系统和外部执行者之间的事件指定顺序。 通常用文本方式
6、来表示，并对应顺序图中的文字描述。包含用例包含用例用例可能包含其他用例的功能来作为它正常处理的一部分。通常它假设，任何被包含的用例在基本程序运行时每一次都会被调用。下面例子：用例“卡的确认” 在运行时，被用例“取钱”当作一个子部分。用例可以被一个或多个用例包含。通过提炼通用的行为，将它变成可以多次重复使用的用例。有助于降低功能重复级别。扩展用例扩展用例一个用例可以被用来扩展另一个用例的行为，通常使用在特别情况下。例如：假设在修改一个特别类型的客户订单之前，用户必须得到某种更高级别的许可，然后“获得许可”用例将有选择的扩展常规的“修改订单”用例。扩展点扩展点扩展用例的加入点被定义为扩展点。系统边
7、界系统边界它用来显示用例在系统内部，执行者在系统的外部。3.3. 实例需求场景实例需求场景联通客户响应 OSS。系统有故障单、业务开通、资源核查、割接、业务重保、网络品质性能等功能模块。现在我们抽出部分需求做为例子讲解。 需求 1：客户响应用户和国际客服可以进行割接通知查询，在页面上有骨干割接查询、省间割接查询、省级割接查询的 Tab。 分析：可以很容易看出割接查询和不同的割接子查询 Tab 之间是继承的关系，所以此处用泛化。用户和客户响应、国际客服也是继承的 Actor 关系。需求 2：客户响应用户和国际客服可以查看某条割接通知信息，可以在页面上导出割接信息 Excel 格式，可以查询和该条
8、割接相关联的故障单信息。 分析：因为导出割接和查看相关联的故障单信息都是可选的，就是说我查看割接的时候，也可以不进行这些操作，所以这里用 extend 关系。也就是导出割接和查看故障单信息扩展了查看割接信息。 需求 3：客户响应用户可以以网管系统为来源创建割接通知，在创建割接通知时可以保存为草稿，也可以直接发布割接通知。 分析：由于创建割接通知时，发布割接通知可以同时进行，也可以先存为草稿，所以发布割接是可选的，用 extend 就比较合适。也就是发布割接扩展了创建割接通知。 需求 4：用户在进行业务开通、发布割接通知、发布重保通知及相关跨省的业务时需要进行数据分发。 分析：由于业务开通、重保
9、、割接及其它跨省的业务都需要用到数据分发用例，我们可以将数据分发用例单独抽出来，供各业务使用，这里用 include就比较合适。实际的系统中数据分发也是单独抽出来用 jms 和 webservice 实现的接口服务。 其它需求：可以看到删除割接通知和查看割接明细也可以做为割接通知查询用例的扩展，因查询列表时，一般可以选择继续查看明细或者删除操作。但在实际化图中，这两个 extend 可以不画，这里只是为了让大家理解概念。 用例图：大家可以参照着图，好好理解。 4.4. 加深理解加深理解 我们再用另外一个场景的用例说明一下 include 和 extend,因为就这两个玩意比较容易搞混。 销户：因为销户必需先进行账户结算，所以这里用 include 停机提醒：有两个可选项，短信提醒和邮件提醒，所以用 extend. 5.5. 总结总结经过以上的分析，相信大家对三种关系已经有比较好的理解了。大家有什么其它想法或好的见解，欢迎拍砖。 PS：以上用例图用 Enterprise Architect 7.5 所画，在此推荐一下 EA,非常不错。
