Unified Modeling Language in Software Engineering

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

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

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

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

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

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

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

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

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

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

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

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

18. Use Case Diagram for Travel Agency 

19. Use Case Diagram

20. Thank You