1、别人的说法
转自:http://www.cnblogs.com/shinings/archive/2009/04/21/1440765.html
共性:都是从现有的用例中抽取出公共的那部分信息,作为一个单独的用例,然后通后过不同的方法来重用这个公共的用例,以减少模型维护的工作量。
包含关系:使用包含(Inclusion)用例来封装一组跨越多个用例的相似动作(行为片断),以便多个基(Base)用例复用。基用例控制与包含用例的 关系,以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果,但是双方都不能访问对方的属性。 例如:业务中,总是存在着维护某某信息的功能,如果将它作为一个用例,那新建、编辑以及修改都要在用例详述中描述,过于复杂;如果分成新建用例、编辑用例和删除用例,则划分太细。这时包含关系可以用来理清关系。
2、扩展(extend) 扩展关系:将基用例中一段相对独立并且可选的动作,用扩展(Extension)用例加以封装,再让它从基用例中声明的扩展点(Extension Point)上进行扩展,从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性,因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。 对于一个扩展用例,可以在基用例上有几个扩展点。 4、泛化(generalization)
泛化关系:子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。 例如,业务中可能存在许多需要部门领导审批的事情,但是领导审批的流程是很相似的,这时可以做成泛化关系表示:
上面是我参考的一篇文章,觉得将三种关系的区别讲得很清晰,在此基础上结合自己的系统,对项目(在线购物系统)的用例做了整体的描绘。
按照先整体用例,后子系统用例来进行描绘的,欢迎大家提出好的建议!
因此,针对用例的三种关系结合系统状态考虑,泛化与包含用例属于无条件发生的用例,而扩展属于有条件发生的用例。进一步,用例的存在是为Actor提供服 务,但用例提供服务的方式可分为间接和直接两种,依据于此,泛化中的子用例提供的是直接服务,而包含中的被包含用例提供的是间接服务。同样,扩展用例提供的也是直接服务,但扩展用例的发生是有条件的。 另外一点需要提及的是:泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。 |
1、Association relationshipsIn 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 endsAn 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. ExampleIn 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 relationshipsIn 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.
ExampleThe 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 relationshipsIn 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:
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. ExampleThe 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 relationshipsIn 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:
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». ExampleYou 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
2.2 extends
2.3 include
|