UML Use Case Diagrams

Use Case Diagram

UML Use Case Diagrams can be used to describe the functionality of a system in a horizontal way. That is, rather than merely representing the details of individual features of your system, UCDs can be used to show all of its available functionality. It is important to note, though, that UCDs are fundamentally different from sequence diagrams or flow charts because they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed. There are a number of graphical examples in this FAQ; you might want to look over them to familiarize yourself with the look of them.

UCDs have only 4 major elements: The actors that the system you are describing interacts with, the system itself, the use cases, or services, that the system knows how to perform, and the lines that represent relationships between these elements. 

For exp : A Web site on which customers can order meals from local restaurants.

An actor (1) is a class of person, organization, device, or external software component that interacts with your system. Example actors are Customer, Restaurant, Temperature Sensor, Credit Card Authorizer.

A use case (2) represents the actions that are performed by one or more actors in the pursuit of a particular goal. Example use cases are Order Meal, Update Menu, Process Payment.

On a use case diagram, use cases are associated (3) with the actors that perform them.

Your system (4) is whatever you are developing. It might be a small software component, whose actors are just other software components; or it might be a complete application; or it might be a large distributed suite of applications deployed over many computers and devices. 

A use case diagram can show which use cases are supported by your system or its subsystems.

<<extends>>

When one use case adds behaviour to a base case
– used to model a part of a use case that the user may see as
optional system behavior;
– also models a separate sub-case which is executed conditionally.

<<uses>>

One use case invokes another (like a procedure call);

– used to avoid describing the same flow of events several times

– puts the common behavior in a use case of its own.

<< include >>

Use an Include relation to show that one use case describes some of the detail of another. In the illustration, Order a Meal includes Pay, Choose Menu, and Choose Menu Item. Each of the included, more detailed use cases is a step that the actor or actors might have to perform to achieve the overall goal of the including use case. The arrow should point at the more detailed, included use case.

The goal and scenarios of an included use case should make sense independently so that it can be included in use cases that are designed later.

Separating use cases into including and included parts is useful to achieve the following goals:

• Structure your use case descriptions into different layers of detail.
• Avoid repeating shared scenarios in different use cases.

UML Class Diagrams

• Widely used to describe the types of objects in a system and their relationships
• Model class structure and contents using design elements such as classes, packages and objects
• Describe three different perspectives when designing a system; conceptual, specification, and implementation

• Classes  are composed of three components :

Visibility

Use visibility markers to signify who can access the information contained within a class. Private visibility hides information from anything outside the class partition. Public visibility allows all other classes to view the marked information. Protected visibility allows child classes to access information they inherited from a parent

Multiplicity

Place multiplicity notations near the ends of an association. These symbols indicate the number of instances of one class linked to one instance of the other class.

 For example, one company will have one or more employees, but each employee works for one company only.

RelationShip (Dependency, Association, Aggregration and Composition)

Generalization

A generalisation is a relationship between a more general element and a more specific element. Generalisation is a mechanism for structuring sets of classes with similar properties into general and specialised classes, as shown below in figure ;

Possible classification of Access Points according to logging and blocking functionality

Some of Class Diagram Examples 

Now the following diagram is an example of an Order System of an application. So it describes a particular aspect of the entire application.

• First of all Order and Customer are identified as the two elements of the system and they have a one to many relationship because a customer can have multiple orders.
• We would keep Order class is an abstract class and it has two concrete classes (inheritance relationship) SpecialOrder and NormalOrder.
• The two inherited classes have all the properties as the Order class. In addition they have additional functions like dispatch () and receive ().

So the following class diagram has been drawn considering all the points mentioned above:

Types of UML Diagrams

UML have several different types of diagrams that can be used to describe a model from different point of views. 

There are two broad caetgories of diagrams and then are again divided into sub-categories:

• Structural Diagrams
• Behavioral Diagrams

Structural Diagrams:

The structural diagrams represent the static aspect of the system. These static aspects represent those parts of a diagram which forms the main structure and therefore stable.

These static parts are represents by classes, interfaces, objects, components and nodes. The four structural diagrams are:

• Class diagram
• Object diagram
• Component diagram
• Deployment diagram

Class Diagram:

Class diagrams are the most common diagrams used in UML. Class diagram consists of classes, interfaces, associations and collaboration.

Class diagrams basically represent the object oriented view of a system which is static in nature.

Active class is used in a class diagram to represent the concurrency of the system.

Class diagram represents the object orientation of a system. So it is generally used for development purpose. This is the most widely used diagram at the time of system construction.

Object Diagram:

Object diagrams can be described as an instance of class diagram. So these diagrams are more close to real life scenarios where we implement a system.

Object diagrams are a set of objects and their relationships just like class diagrams and also represent the static view of the system.

The usage of object diagrams is similar to class diagrams but they are used to build prototype of a system from practical perspective.

Component Diagram:

Component diagrams represent a set of components and their relationships. These components consist of classes, interfaces or collaborations.

So Component diagrams represent the implementation view of a system.

During design phase software artifacts (classes, interfaces etc) of a system are arranged in different groups depending upon their relationship. Now these groups are known as components.

Finally, component diagrams are used to visualize the implementation.

Deployment Diagram:

Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities where the components are deployed.

Deployment diagrams are used for visualizing deployment view of a system. This is generally used by the deployment team.

Note: If the above descriptions and usages are observed carefully then it is very clear that all the diagrams are having some relationship with one another. Component diagrams are dependent upon the classes, interfaces etc which are part of class/object diagram. Again the deployment diagram is dependent upon the components which are used to make a component diagrams.

Behavioral Diagrams:

Any system can have two aspects, static and dynamic. So a model is considered as complete when both the aspects are covered fully.

Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be further described as the changing/moving parts of a system.

UML has the following five types of behavioral diagrams:

• Use case diagram
• Sequence diagram
• Collaboration diagram
• Statechart diagram
• Activity diagram

Use case Diagram:

Use case diagrams are a set of use cases, actors and their relationships. They represent the use case view of a system.

A use case represents a particular functionality of a system.

So use case diagram is used to describe the relationships among the functionalities and their internal/external controllers. These controllers are known as actors.

Sequence Diagram:

A sequence diagram is an interaction diagram. From the name it is clear that the diagram deals with some sequences, which are the sequence of messages flowing from one object to another.

Interaction among the components of a system is very important from implementation and execution perspective.

So Sequence diagram is used to visualize the sequence of calls in a system to perform a specific functionality.

Collaboration Diagram:

Collaboration diagram is another form of interaction diagram. It represents the structural organization of a system and the messages sent/received. Structural organization consists of objects and links.

The purpose of collaboration diagram is similar to sequence diagram. But the specific purpose of collaboration diagram is to visualize the organization of objects and their interaction.

Statechart Diagram:

Any real time system is expected to be reacted by some kind of internal/external events. These events are responsible for state change of the system.

Statechart diagram is used to represent the event driven state change of a system. It basically describes the state change of a class, interface etc.

State chart diagram is used to visualize the reaction of a system by internal/external factors.

Activity Diagram:

Activity diagram describes the flow of control in a system. So it consists of activities and links. The flow can be sequential, concurrent or branched.

Activities are nothing but the functions of a system. Numbers of activity diagrams are prepared to capture the entire flow in a system.

Activity diagrams are used to visualize the flow of controls in a system. This is prepared to have an idea of how the system will work when executed.

Overview of UML

The Unified Modeling Language™ (UML®) is a standard visual modeling language intended to be used for

• modeling business and similar processes,
• analysis, design, and implementation of software-based systems

UML is a common language for business analysts, software architects and developers used to describe, specify, design, and document existing or new business processes, structure and behavior of artifacts of software systems.

UML can be applied to diverse application domains (e.g., banking, finance, internet, aerospace, healthcare, etc.) It can be used with all major object and component software development methods and for various implementation platforms.

Benefits of UML

• You know exactly what you are getting
• You will have lower development costs
• Your software will behave as you expect it to. Fewer surprises
• The right decisions are made before you are given poorly written code. Less overall costs
• We can develop more memory and processor efficient systems
• System maintenance costs will be lower. Less relearning takes place
• Working with a new developer will be easier.
• Communication with programmers and outside contractors will be more efficient.