UML is a standardized notation used for object oriented analysis and design. The graphical notation was derived from the specifications of three primary authors – Jim Rumbaugh, Ivar Jacobson and Grady Booch. Each of them originally created their own standard method (Object Modeling Technique, Use Case methodology and Entity-Relationships using Object Oriented Design respectively). Eventually, they collaborated and developed an open standard combining their individual methods.
An object oriented model facilitates breaking up of a huge complex system into simple, manageable pieces that can be individually analyzed. UML is universal and does not depend upon any specific development technology, language or platform. Using UML, one can create a model or blue print of the intended application and specify the structure, behavior and architecture of the system. UML diagrams serve as templates to design the system. The system is visualized as 5 different views. A view is the perception of the system from the perspective of each step in the software life cycle. Each view has a set of diagrams that capture specific aspects of the system.
- Use Case View – Captures the system requirements by defining the interaction between the system and external entities. It is represented using Use Case Diagrams.
- Design View – Defines the structural components of the system. It is represented using Class Diagrams and Object Diagrams.
- Process View – Specifies the dynamic behavior of the system, its processes and sub-processes / threads. It is represented using State Diagram, Activity Diagram, Sequence Diagram, and Collaboration Diagram.
- Implementation View (or) Component View – Addresses the implementation of the various modules in the system using Component Diagrams.
- Deployment View – For modeling the physical architecture of the system, Deployment Diagrams are used.
A suitable UML tool is selected to create these model diagrams. There are 14 types of UML diagrams categorized as either structural or behavioral.
- Class Diagram
- Component Diagram
- Deployment Diagram
- Object Diagram
- Package Diagram
- Profile Diagram
- Composite Structure Diagram
- Use Case Diagram
- Activity Diagram
- State Machine Diagram
- Sequence Diagram
- Communication Diagram
- Interaction Overview Diagram
- Timing Diagram
Diagrams 1-7 listed above define the structure of the system and 8-14 define the behavior of the system.
Here is an introduction to the most commonly used modeling diagrams.
Modeling the static characteristics of the System:
Use Case Diagram
The use case diagram identifies the primary entities and tasks of the system. The external entities are called ‘actors’ and the tasks are called ‘use cases’. The diagram depicts the interaction and dependencies between the actors and the use cases. A list of system use cases is essentially a list of functionalities/features available to users of the system.
The class diagram depicts the objects in the system, their individual attributes and the functions that can be performed on those objects. Once may also specify the relationships between classes. The relationship may be aggregation (Entity A “has a” Entity B as in Car Model A has Engine Model B) or composition (Entity A “owns a” Entity B as in Car owns a Carburetor) or generalization (Entity A “is a” Entity B as in elephant is a mammal).
Modeling the dynamic characteristics of the System:
An object being an instance of a class shows the state of that class at a given moment at run-time. The object diagram shows the various states of classes (defined by their attributes) in the system and their associations with other classes at a given time for each event in the system.
State Chart Diagram
An object’s state changes based on the functions invoked on the object during its lifetime in the system. The state diagram shows the transition of objects from one state to another and the triggering events for such a transition. The valid initial, final and intermediate states of an object are defined in this diagram.
An activity diagram shows transfer of control between objects during an activity, system state transitions and guard conditions for a flow of events.
Sequence diagrams show the flow for a specific task. They depict the function / method calls between different objects in the system and their order of occurrence. The vertical dimension of a sequence diagram shows the time order in which the function invocations occur and the horizontal dimension shows the invoking and invoked object instances. The sequence of interactions between objects is time-ordered step by step and the interactions occur in the form of “messages” passed between the objects.
Interaction Overview Diagram (Collaboration Diagram)
Interactions between objects are numbered to show sequence and are grouped together.
Modeling the implementation of the System:
The component diagram shows how the various software components are wired to form a module or system. Connectors between components define the interfaces and dependencies between the components.
The deployment diagram depicts the physical hardware deployment of the system. It shows the environment where the components will physically run, how they interact with each other and the run-time aspects of the system.
UML diagrams provide for a good understanding of the different components of a system and because UML modeling has the advantage of being system and platform independent, it is likely to remain popular for many years to come.