UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. Object Management Group (OMG) created UML and UML 1.0 specification draft was proposed to the OMG in January 1997. UML can be described as a general-purpose visual modeling language to visualize, specify, construct and document software systems. Although UML is generally used to model software systems it is not limited within this boundary. It is also used to model non-software systems as well like process flow in a manufacturing unit etc. UML is not a programming language but tools can be used to generate code in various languages using UML diagrams.
- UML is a general-purpose modeling language. It was initially started to capture the behavior of complex software and non-software system and now it has become an OMG standard.
- UML provides elements and components to support the requirement of complex systems. UML follows the object-oriented concepts and methodology. So object-oriented systems are generally modeled using the pictorial language.
- UML diagrams are drawn from different perspectives like design, implementation, deployment, etc. At the conclusion, UML can be defined as a modeling language to capture the architectural, behavioral and structural aspects of a system.
- Objects are the key to this object-oriented world. The basic requirement of object-oriented analysis and design is to identify the object efficiently. After that, the responsibilities are assigned to the objects. Once this task is complete the design is done using the input from the analysis.
- The UML has an important role in this OO analysis and design; The UML diagrams are used to model the design. So the UML has an important role to play.
Purpose of UML
A picture is worth a thousand words, this absolutely fits while discussing UML. Object-oriented concepts were introduced much earlier than UML. So at that time, there were no standard methodologies to organize and consolidate the object-oriented development. At that point in time UML came into the picture. There are a number of goals for developing UML but the most important is:
- To define some general-purpose modeling language, which all modelers can use, and also it needs to be made simple to understand and use.
- Made for developers but also for business users, common people and anybody interested to understand the system.
- The system can be software or non-software.
- It must be clear that UML is not a development method rather it accompanies processes to make a successful system.
At the conclusion, the goal of UML can be defined as a simple modeling mechanism to model all possible practical systems in today’s complex environment.
Modeling Architecture Views using UML
Different users use any real-world system. The users can be developers, testers, business people, analysts and many more. So before designing a system the architecture is made with different perspectives in mind. The most important part is to visualize the system from different viewers’ perspective. The better we understand the better we make the system. This set of views is known as the 4+1 Views of Software Architecture. UML plays an important role in defining different perspectives of a system. These perspectives are:
+ 4 Architecture views
And the center is the Use Case view which connects all these four. A Use case represents the functionality of the system. So the other perspectives are connected with the use case.
- Use-case view: Describes the functionality of the system, its external interfaces, and its principal users. The use-case view contains the Use-Case Model. This view is mandatory when using the 4+1 Views because all elements of the architecture should be derived from requirements.
- Logical view: Describes how the system is structured in terms of units of implementation. The elements are packages, classes, and interfaces. The relationship between elements shows dependencies, interface realizations, part-whole relationships, and so forth. Note: This view is mandatory when using the 4+1 Views of Software Architecture.
- Implementation view: Describes how development artifacts are organized in the file system. The elements are files and directories (any configuration items). This includes the development of artifacts and deployment artifacts. This view is optional when using the 4+1 Views.
- Process view: Describes how the run-time system is structured as a set of elements that have run-time behavior and interactions. Run-time structure often bears little resemblance to the code structure. It consists of rapidly changing networks of communication objects. The elements are components that have a run-time presence (processes, threads, Enterprise JavaBeans™ (EJB™), servlets, DLLs, and so on), data stores, and complex connectors, such as queues. Interaction between elements varies, based on technology. This view is useful for thinking about run-time system quality attributes, such as performance and reliability. This view is optional when using the 4+1 Views.
- Deployment views: Describe how the system is mapped to the hardware. This view is optional when using the 4+1 Views.
In addition, you may wish to represent the following:
- Data view: A specialization of the logical view. Use this view if persistence is a significant aspect of the system, and the translation from the design model to the data model is not done automatically by the persistence mechanism.
14 Type of Diagrams in UML 2
Diagrams are the heart of UML. These diagrams are broadly categorized as structural and behavioral diagrams.
- Structural diagrams are consists of static diagrams like class diagram, objects diagram, etc.
- Behavioral diagrams are consists of dynamic diagrams like sequence diagram, collaboration diagram, etc.
Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. The elements in a structure diagram represent the meaningful concepts of a system and may include abstract, real-world and implementation concepts, there are seven types of structure diagram as follows:
- Classes diagrams
- Objects diagrams
- Deployment diagrams
- Package diagrams
- Composite structure diagram
- Component diagram
- Profile Diagram
Behavior diagrams show the dynamic behavior of the objects in a system, which can be described as a series of changes to the system over time, there are seven types of behavior diagrams as follows:
- Use Case Diagram
- Activity Diagram
- State Machine Diagram
- Sequence Diagram
- Communication Diagram
- Interaction Overview Diagram
- Timing Diagram
Class diagrams are the most popular UML diagrams used by the object-oriented community. It describes the objects in a system and their relationships. A class diagram consists of attributes and functions.
A single class diagram describes a specific aspect of the system and the collection of class diagrams represents the whole system. Basically the class diagram represents the static view of a system.
Class diagrams are the only UML diagrams, which can be mapped directly with object-oriented languages. So it is widely used by the developer community.
Class Diagram Example
The following Class Diagram example represents two classes – User and Attachment. A user can upload multiple attachments so the two classes are connected with an association, with 0..* as multiplicity on the Attachment side.
An object diagram is an instance of a class diagram. So the basic elements are similar to a class diagram. Object diagrams are consist of objects and links. It captures the instance of the system at a particular moment.
A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The difference is that a class diagram represents an abstract model consisting of classes and their relationships. However, an object diagram represents an instance at a particular moment, which is concrete in nature. The use of object diagrams is fairly limited, namely to show examples of data structure.
Object Diagram Example
The following Object Diagram example shows you how the object instances of User and Attachment class “look like” at the moment Peter (i.e. the user) is trying to upload two attachments. So there are two Instance Specifications for the two attachment objects to be uploaded.
Component diagrams are a special kind of UML diagram to describe the static implementation view of a system. Component diagrams consist of physical components like libraries, files, folders, etc.
This diagram is used from an implementation perspective. More than one component diagrams are used to represent the entire system. Forward and reverse engineering techniques are used to make executables from component diagrams.
Component Diagram Example
Component diagrams are used to describe the static deployment view of a system. System engineers mainly use these diagrams.
Deployment diagrams are consist of nodes and their relationships. An efficient deployment diagram is an integral part of software application development.
Deployment Diagram Example
The package diagram is a UML structure diagram that shows packages and dependencies between the packages. Model diagrams allow showing different views of a system, for example, as multi-layered (aka multi-tiered) application – multi-layered application model.
Package Diagram Example
Composite Structure Diagram
Composite Structure Diagram is one of the new artifacts added to UML 2.0. A composite structure diagram is similar to a class diagram and is a kind of component diagram mainly used in modeling a system at a micro point-of-view, but it depicts individual parts instead of whole classes. It is a type of static structure diagram that shows the internal structure of a class and the collaborations that this structure makes possible.
This diagram can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration.
Composite Structure Diagram Example
A profile diagram enables you to create a domain and platform-specific stereotypes and define the relationships between them. You can create stereotypes by drawing stereotype shapes and relate them with composition or generalization through the resource-centric interface. You can also define and visualize the tagged values of stereotypes.
Profile Diagram Example
Use Case Diagram
Because it is a very powerful planning instrument, the use-case model is generally used in all phases of the development cycle by all team members.
Use Case Diagram Example
State Machine Diagram
A State Machine diagram (also known as statechart, state diagram or state transition diagram), developed by David Harel, is one of the seven diagrams used for modeling the dynamic nature of a system.
These diagrams are used to model the entire life cycle of an object. The activity diagram is a special kind of Statechart diagram.
The state of an object is defined as the condition where an object resides for a particular time and the object again moves to other states when some events occur. Statechart diagrams are also used for forward and reverse engineering.
State Machine Diagram Example
The activity diagram is another important diagram to describe dynamic behavior. The activity diagram consists of activities, links, relationships, etc. It models all types of flows like parallel, single, concurrent, etc. The activity diagram describes the flow control from one activity to another without any messages. These diagrams are used to model a high-level view of business requirements. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e. workflows).
Activity Diagram Example
The Sequence Diagram models the collaboration of objects based on a time sequence. It shows how the objects interact with others in a particular scenario of a use case. With the advanced visual modeling capability, you can create a complex sequence diagram in a few clicks. Besides, some modeling tool such as Visual Paradigm can generate sequence diagram from the flow of events which you have defined in the use case description.
Sequence Diagram Example
Similar to the Sequence Diagram, the Communication Diagram is also used to model the dynamic behavior of the use case. When compared to the Sequence Diagram, the Communication Diagram is more focused on showing the collaboration of objects rather than the time sequence. They are actually semantically equivalent, so some of the modeling tools such as Visual Paradigm allows you to generate it from one to the other.
Communication Diagram Example
Interaction Overview Diagram
The Interaction Overview Diagram focuses on the overview of the flow of control of the interactions. It is a variant of the Activity Diagram where the nodes are the interactions or interaction occurrences. The Interaction Overview Diagram describes the interactions where messages and lifelines are hidden. You can link up the “real” diagrams and achieve high degree navigability between diagrams inside the Interaction Overview Diagram.
Interaction Overview Diagram Example
Timing Diagram shows the behavior of the object(s) in a given period of time. A timing diagram is a special form of a sequence diagram. The differences between the timing diagram and sequence diagram are the axes are reversed so that the time is an increase from left to right and the lifelines are shown in separate compartments arranged vertically.
Timing Diagram Example
- The UML is non- proprietary and open to all. It addresses the needs of the user and scientific communities, as established by experience with the underlying methods on which it is based.
- Many methodologists, organizations, and tool vendors have committed to using it. Since the UML builds upon similar semantics and notation from Booch, OMT, OOSE, and other leading methods and has incorporated input from the UML partners and feedback from the general public, widespread adoption of the UML should be straightforward.
There are two aspects of “unified” that the UML achieves:
- First, it effectively ends many of the differences, often inconsequential, between the modeling languages of previous methods.
- Secondly, and perhaps more importantly, it unifies the perspectives among many different kinds of systems (business versus software), development phases (requirements analysis, design, and implementation), and internal concepts.