UML include、generalization、extend、association

1、别人的说法

转自：http://www.cnblogs.com/shinings/archive/2009/04/21/1440765.html

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)

 

    包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的 关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。 

   包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。　

   例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

 

 

2、扩展(extend)

扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

 

对于一个扩展用例，可以在基用例上有几个扩展点。   

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

 

4、泛化(generalization)

 

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示： 

 

 

上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。

    *****************************************************************

    (1)系统整体用例图

 

按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!

转：UML中扩展和泛化的区别 

         泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：
          ●泛化侧重表示子用例间的互斥性；
          ●包含侧重表示被包含用例对Actor提供服务的间接性；
          ●扩展侧重表示扩展用例的触发不定性；详述如下：

        既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
         ⒈无条件发生：肯定发生的；
         ⒉有条件发生：未必发生，发生与否取决于系统状态；

         因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服 务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

         另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。

转自：http://publib.boulder.ibm.com/infocenter/rsmhelp/v7r0m0/index.jsp?topic=/com.ibm.xtools.modeler.doc/topics/cgeneral.html

1、Association relationships

In UML models, an association is a relationship between two classifiers, such as classes or use cases, that describes the reasons for the relationship and the rules that govern the relationship.

An association represents a structural relationship that connects two classifiers. Like attributes, associations record the properties of classifiers. For example, in relationships between classes, you can use associations to show the design decisions that you made about classes in your application that contain data, and to show which of those classes need to share data. You can use an association's navigability feature, to show how an object of one class gains access to an object of another class or, in a reflexive association, to an object of the same class.

The name of an association describes the nature of the relationship between two classifiers and should be a verb or phrase.

In the diagram editor, an association appears as a solid line between two classifiers.

Association ends

An association end specifies the role that the object at one end of a relationship performs. Each end of a relationship has properties that specify the role of the association end, its multiplicity, visibility, navigability, and constraints.

Example

In an e-commerce application, a customer class has a single association with an account class. The association shows that a customer instance owns one or more instances of the account class. If you have an account, you can locate the customer that owns the account. Given a particular customer, you can navigate to each of the customer’s accounts. The association between the customer class and the account class is important because it shows the structure between the two classifiers.

 

2、Generalization relationships

In UML modeling, a generalization relationship is a relationship in which one model element (the child) is based on another model element (the parent). Generalization relationships are used in class, component, deployment, and use-case diagrams to indicate that the child receives all of the attributes, operations, and relationships that are defined in the parent.

To comply with UML semantics, the model elements in a generalization relationship must be the same type. For example, a generalization relationship can be used between actors or between use cases; however, it cannot be used between an actor and a use case.

You can add generalization relationships to capture attributes, operations, and relationships in a parent model element and then reuse them in one or more child model elements. Because the child model elements in generalizations inherit the attributes, operations, and relationships of the parent, you must only define for the child the attributes, operations, or relationships that are distinct from the parent.

The parent model element can have one or more children, and any child model element can have one or more parents. It is more common to have a single parent model element and multiple child model elements.

Generalization relationships do not have names.

As the following figures illustrate, a generalization relationship is displayed in the diagram editor as a solid line with a hollow arrowhead that points from the child model element to the parent model element.

Single parent with a single child	Single parent with multiple children

Example

The following figure illustrates an e-commerce application for a Web site that sells a variety of merchandise. The application has an InventoryItem class that is a parent class (also called a superclass). This class contains the attributes, such as Price, and operations, such as setPrice, that all pieces of merchandise use.

After defining the parent class, a child class (also called a subclass) is created for each type of merchandise, such as books and DVDs. The book class uses the attributes and operations in the inventory class and then adds attributes such as author and operations such as setAuthor. A DVD class also uses the attributes and operations in the inventory class, but it adds attributes such as manufacturer and operations such as setManufacturer, which are different from those in the book class.

 

 

3、Include relationships

In UML modeling, an include relationship is a relationship in which one use case (the base use case) includes the functionality of another use case (the inclusion use case). The include relationship supports the reuse of functionality in a use-case model.

You can add include relationships to your model to show the following situations:

• The behavior of the inclusion use case is common to two or more use cases.
• The result of the behavior that the inclusion use case specifies, not the behavior itself, is important to the base use case.

Include relationships usually do not have names. If you name an include relationship, the name is displayed beside the include connector in the diagram.

As the following figure illustrates, an include relationship is displayed in the diagram editor as a dashed line with an open arrow pointing from the base use case to the inclusion use case. The keyword «include» is attached to the connector.

Example

The following figure illustrates an e-commerce application that provides customers with the option of checking the status of their orders. This behavior is modeled with a base use case called CheckOrderStatus that has an inclusion use case called LogIn. The LogIn use case is a separate inclusion use case because it contains behaviors that several other use cases in the system use. An include relationship points from the CheckOrderStatus use case to the LogIn use case to indicate that the CheckOrderStatus use case always includes the behaviors in the LogIn use case.

 

4、Extend relationships

In UML modeling, you can use an extend relationship to specify that one use case (extension) extends the behavior of another use case (base). This type of relationship reveals details about a system or application that are typically hidden in a use case.

The extend relationship specifies that the incorporation of the extension use case is dependent on what happens when the base use case executes. The extension use case owns the extend relationship. You can specify several extend relationships for a single base use case.

While the base use case is defined independently and is meaningful by itself, the extension use case is not meaningful on its own. The extension use case consists of one or several behavior sequences (segments) that describe additional behavior that can incrementally augment the behavior of the base use case. Each segment can be inserted into the base use case at a different point, called an extension point.

The extension use case can access and modify the attributes of the base use case; however, the base use case is not aware of the extension use case and, therefore, cannot access or modify the attributes and operations of the extension use case.

You can add extend relationships to a model to show the following situations:

• A part of a use case that is optional system behavior
• A subflow is executed only under certain conditions
• A set of behavior segments that may be inserted in a base use case

Extend relationships do not have names.

As the following figure illustrates, an extend relationship is displayed in the diagram editor as a dashed line with an open arrowhead pointing from the extension use case to the base use case. The arrow is labeled with the keyword «extend».

Example

You are developing an e-commerce system in which you have a base use case called Place Online Order that has an extending use case called Specify Shipping Instructions. An extend relationship points from the Specify Shipping Instructions use case to the Place Online Order use case to indicate that the behaviors in the Specify Shipping Instructions use case are optional and only occur in certain circumstances.

2、我的总结

 2.1 generalization

• 强调子用例间的互斥性；
• generalization类似于我们熟悉的继承；
• 所关联的两个 model elements 必须是 the same type；

2.2 extends

• 强调触发不定性；
• extension use case 必须依赖于 base use case 而存在，即只有 base use case 执行了，extension 才有可能发生。而base use case 可独立存在；
• extension 由一系列的 behaviour sequences 组成，这些 behaviour sequences 是对 base 的扩充，可以直接插入到 base 操作中；
• extension 有时是系统的 optional 行为操作，有时是 certain contain 下的subflow。

2.3 include

• 强调 inclusion use case 对 actor 提供服务的间接性；
• 强调功能重用（the reuse of functionality）；
• 或者是 inclusion use case 是对一些行为的封装，其他多个 use case 都有这些 behaviour；
• 或者说 inclusion use case 的 result 对 base use case 很重要。