UML用例图实例解析

《UML用例图实例解析》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、UML用例图实例解析本文和大家重点讨论-下UML用例图实例的应用，UML用例图包含了用例和参与者，用例Z间用关联来连接以求把系统的整个结构和功能反映给非技术人员(通常是软件的用户),对应的是软件的结构和功能分解。UML用例图用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成•定功能的动作，通俗地理解用例就是软件的功能模块，所以是设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块Z间的调用关系，UML用例图包含了用例和参与者，用例Z间用关联来连接以求把系统的整个结构和功能反映给非技术人员(通常是软件

2、的用户)，对应的是软件的结构和功能分解。用例是从系统外部可见的行为，是系统为某一个或几个参与者(Actor)提供的一段完整的服务。从原则上来讲，用例之间都是独立、并列的，它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)儿种关系。共性：都是从现有的用例屮抽取出公共的那部分信息，作为•个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。1、包含(include)包含关系：使用包含(Inclusion)用例来封装…组跨越多个用例的相

3、似动作(行为片断)，以便多个基(Base)用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。UML用例图屮包含关系对典型的应用就是复用，也就是定义屮说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言小，将程序的菜一段算法封装成•个了过程，然后再从主程序中调用这一子过程。例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个

4、用例，那新建、编辑以及修改都要在用例详述中描述，过于复朵；如果分成新建用例、编辑用例和删除用例,则划分太细。这时包含关系可以用来理清关系。ArtorHim51CT0.com技术成就梦想2、扩展(extend)扩展关系：将基用例屮一段相对独立并且AT选的动作，用扩展(Extension)用例加以封装，再让它从基用例中声明的扩展点(ExtensionPoint)上进行扩展，从而使基用例彳亍为更简练和FI标更集屮。UHL用例图中扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例屮扩展点的当前状态来判断是否执行白己。但是扩展用例对基用例不可见。对于一个扩展用例，可以在基用

5、例上有儿个扩展点。例如，系统中允许用户对查询的结果进行导出、打印。对丁渣询而言，能不能导出、打印杳询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而H为查询添加了新行为。因此可以采用扩展关系来描述：员工导出査询结果打印査诲结果技术成就梦想3、泛化(generalization)UHL用例图中泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。了用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。例如，业务中町能存在许多需耍部门领导审批的事情，但是

6、领导审批的流程是很相似的,这时可以做成泛化关系表示：工资调整审批请假审批i1CT0.com技术成就梦想上血是我参考的篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目（在线购物系统）的用例做了敕体的描绘。