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.
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.
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.
Generalization relationships
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.
Include relationships
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.
Extend relationships
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.
No comments:
Post a Comment