Unified Modeling Language (UML) is a general-purpose modeling language. The main aim of UML is to define a standard way to visualize the way a system has been designed. It is quite similar to blueprints used in other fields of engineering. UML is not a programming language, it is rather a visual language. We use UML diagrams to portray the behavior and structure of a system. UML helps software engineers, businessmen, and system architects with modeling, design, and analysis. The Object Management Group (OMG) adopted Unified Modelling Language as a standard in 1997. It’s been managed by OMG ever since. The International Organization for Standardization (ISO) published UML as an approved standard in 2005. UML has been revised over the years and is reviewed periodically.

1. UML
Simmi S
Department of Computer Science(UG)
Kristu Jayanti College , Bangalore

2. UML
UML is a visual language that provides a way for software engineers
and developers to construct, document and visualize software systems.
While UML is not a programming language , it can provide visual
representations that help software developers better understand
potential outcomes or errors in programs.

3. Goals of UML
Since it is a general-purpose modeling language, it can be utilized by all the modelers.
UML came into existence after the introduction of object-oriented concepts to systemize and
consolidate the object-oriented development, due to the absence of standard methods at that time.
The UML diagrams are made for business users, developers, ordinary people, or anyone who is
looking forward to understand the system, such that the system can be software or non-software.
Thus it can be concluded that the UML is a simple modelling approach that is used to model all the
practical systems

4. Characteristics of UML
The UML has the following features:
It is a generalized modeling language.
It is distinct from other programming languages like C++, Python, etc.
It is interrelated to object-oriented analysis and design.
It is used to visualize the workflow of the system.
It is a pictorial language, used to generate powerful modelling artifacts.

5. Structure diagrams show the things in the modeled system. In a more
technical term, they show different objects in a system.
Behavioural diagrams show what should happen in a system. They describe
how the objects interact with each other to create a functioning system.

6. Class Diagram
Class diagrams are the main building block of any object-oriented solution.
It shows the classes in a system, attributes, and operations of each class and
the relationship between each class.
In most modeling tools, a class has three parts. Name at the top, attributes in
the middle and operations or methods at the bottom

8. Use Case Diagram
As the most known diagram type of the behaviuoral UML types, Use case diagrams give
a graphic overview of the actors involved in a system, different functions needed by those
actors and how these different functions interact.
Use Case Diagram objects
Actor
Use case
System
Package

9. Use Case Diagram
Actor in a use case diagram is any entity that performs a role in one given system. This
could be a person, organization or an external system and usually drawn like skeleton
shown below.
A use case represents a function or an action within the system. It’s drawn as an oval and
named with the function.

10. The system is used to define the scope of the use case and drawn as a
rectangle.
This an optional element but useful when you’re visualizing large
systems. For example, you can create all the use cases and then use the
system object to define the scope covered by your project. Or you can
even use it to show the different areas covered in different releases.

11. Use Case Diagram
The package is another optional element that is extremely useful in
complex diagrams. Similar to class diagrams, packages are used to
group together use cases. They are drawn like the image shown below.

12. Relationships in Use Case Diagrams
There are five types of relationships in a use case diagram. They are
Association between an actor and a use case
Generalization of an actor
Extend relationship between two use cases
Include relationship
Generalization of a use case

13. How to Create a Use Case Diagram
Identifying Actors
Identifying Use Cases
Look for Common Functionality to Reuse
Is it Possible to Generalize Actors and Use Cases
Optional Functions or Additional Functions
Validate and Refine the Diagram

14. Identifying Actors
Actors are external entities that interact with your system. It can be a
person, another system or an organization. In a banking system,
the most obvious actor is the customer

15. Identifying Use Cases
A good way to do this is to identify what the actors need from the
system. In a banking system, a customer will need to open accounts,
deposit and withdraw funds, request check books and similar
functions. So all of these can be considered as use cases.

16. Look for Common Functionality to Use
‘Include’
Look for common functionality that can be reused across the system.
If you find two or more use cases that share common functionality you can
extract the common functions and add it to a separate use case.
Then you can connect it via the include relationship to show that it’s always
called when the original use case is executed. ( see the diagram for an
example ).

17. Is it Possible to Generalize Actors and Use
Cases
There may be instances where actors are associated with similar use cases
while triggering a few use cases unique only to them. In such instances, you
can generalize the actor to show the inheritance of functions. You can do a
similar thing for use case as well.
One of the best examples of this is “Make Payment” use case in a payment
system. You can further generalize it to “Pay by Credit Card”, “Pay by
Cash”, “Pay by Check” etc. All of them have the attributes and the
functionality of payment with special scenarios unique to them.

18. Optional Functions or Additional
Functions
There are some functions that are triggered optionally. In such cases,
you can use the extend relationship and attach an extension rule to it.
 In the below banking system example “Calculate Bonus” is optional
and only triggers when a certain condition is matched.
Extend doesn’t always mean it’s optional.

19. Use Case Diagram for Travel Agency

20. Use Case Diagram

21. Thank You