UML Use Case Diagram

Purpose:

The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition is too generic to describe the purpose. Use case diagrams are used to gather the requirements of a system including internal and external influences. These requirements are mostly design requirements. So when a system is analyzed to gather its functionalities use cases are prepared and actors are identified.

The purposes of use case diagrams can be as follows:

• Used to gather requirements of a system.
• Used to get an outside view of a system.
• Identify external and internal factors influencing the system.
• Show the interacting among the requirements are actors.

How to draw Use Case Diagram?
Use case diagrams are considered for high level requirement analysis of a system. So when the requirements of a system are analyzed the functionalities are captured in use cases. So we can say that uses cases are nothing but the system functionalities written in an organized manner. Now the second things which are relevant to the use cases are the actors. Actors can be defined as something that interacts with the system.

The actors can be human user, some internal applications or may be some external applications. So in a brief when we are planning to draw an use case diagram we should have the following items identified:

• Functionalities to be represented as an use case
• Actors
• Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system. So after identifying the above items we have to follow the following guidelines to draw an efficient use case diagram.

The name of a use case is very important. So the name should be chosen in such a way so that it can identify the functionality performed.

• Give a suitable name for actors.
• Show relationships and dependencies clearly in the diagram.
• Do not try to include all types of relationships. Because the main purpose of the diagram is to identify requirements.
• Use note when ever required to clarify some important points.

These diagrams are used at a very high level of design. Then this high level design is refined again and again to get a complete and practical picture of the system. A well structured use case also describes the pre condition, post condition, exceptions. And these extra elements are used to make test cases when performing the testing.

The following are the places where use case diagrams are used:

• Requirement analysis and high level design.
• Model the context of a system.
• Reverse engineering.
• Forward engineering.

For example an online reservation system use case diagram had been introduced with the system boundaries separated by rectangular box, including two actors: the primary actor which is Customer can make all those use cases (Search flight use case, Make a reservation use case, Purchase a ticket use case, Check flight status use case, Cancel flight use case), other actor which is system actor Payment Process use a Validate credit card use case. This diagram show an extend relationship between Reschedule flight use case which extends Cancel flight use case and the Select seat use case which extends Purchase a ticket use case. A dependency relationship between Purchase a ticket Invoking use case include a Validate credit card Included use case

The following topics describe the relationships that you can use in use case diagrams:

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.
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.
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.
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.

a good diagram i find while googling

Understanding Association, Aggregation, and Composition

In this article, we will try to understand three important concepts: association, aggregation, and composition. We will also try to understand in what kind of scenarios we need them. These three concepts have really confused a lot of developers and in this article.

For a little bit introduction on types of relationship visit this link

The UML Class diagram is used to visually describe the problem domain in terms of types of object (classes) related to each other in different ways. There are three primary inter-object relationships: association, aggregation, and composition. Using the right relationship line is important for placing implicit restrictions on the visibility and propagation of changes to the related classes, matter which play major role in reducing system complexity.

1. Association

The most abstract way to describe static relationship between classes(classifiers) is using the ‘Association’ link, which simply states that there is some kind of a link or a dependency between two classes or more.

An association defines a relationship between two or more classes. Binary associations are relationships between exactly two classes and a n-ary association is an association between three or more classes.

1.1. Weak Association

ClassA may be linked to ClassB in order to show that one of its methods includes parameter of ClassB instance, or returns instance of ClassB.

1.2. Strong Association

ClassA may also be linked to ClassB in order to show that it holds reference to ClassB instance.

2. Aggregation (Shared Association/Relation Aggregation)

Is a specialized association. It is specified by an aggregation association with a hollow diamond. A part in this type of aggregation can participate in several aggregates. In cases where there’s a part-of relationship between ClassA (whole) and ClassB (part), we can be more specific and use the aggregation link instead of the association link, taking special notice that ClassB can also be aggregated by other classes in the application.

Aggregation protects the integrity of an assembly of objects by defining a single point of control, called the aggregate, in the object that represents the assembly. Aggregation also uses the control object to decide how the assembled objects respond to changes or instructions that might affect the collection.

A part classifier can belong to more than one aggregate classifier and it can exist independently of the aggregate. For example, an Engine class can have an aggregation relationship with a Car class;at the same time an Engine class can have an aggregation relationship with an Order class which indicates that the engine is part of the Car and the Order. Aggregations are closely related to compositions.

3. Composition (Not-Shared Association/Real Aggregation)

Is a stronger form of aggregation where the parts cannot exist without the whole. The parts can only participate in one composite. In a composition association relationship, data usually flows in only one direction (that is, from the whole classifier to the part classifier). Composition is shown as an association with a filled solid diamond nearest the class constituting the whole.

In cases where in addition to the part-of relationship between class Person and booth class Hand and class Leg - there’s a strong life cycle dependency between those classes, meaning that when class Person deleted then booth class Hand and class Leg are also deleted as a result, we should be more specific and use the composition link instead of the aggregation link or the association link.

NB:

Unlike association and aggregation, in the composition relationship, the composed class cannot appear as a return type or parameter type of the composite class,  thus changes in the composed class cannot be propagated to the rest of the system. Consequently, usage of composition limits complexity growth as the system grows.

Aggregation v.s. Association:

The association link can replace the aggregation link in every situation, while aggregation cannot replace association in situations were there is only a ‘weak link’ between the classes.

Summarizing:

To avoid confusion henceforth for these three terms, I have put forward a table below which will help us compare them from three angles: owner, lifetime, and child object.

	Association	Aggregation	Composition
Owner	No owner	Single or Multiple owner	Single owner
Life time	Have their own lifetime		Owner's life time
Child object	Child objects all are independent	Child objects belong to a single/multiple parent	Child objects belong to a single parent

Step by step Association, Aggregation, and Composition decision making

References:

ibm ,tutorialspoint, codeproject, sintef9013