UML Guide v2.1

Introduction
The Unified Modeling Language is a standard design specification that is overseen by the Object Management Group (OMG). UML came about from standard practice in the software industry, it's origin came from the unification of the OMT(Object Model Technique) and Booch method. UML provides a nice framework for designing and analyzing process, structure and their relationships. UML is a collection of the best technical modeling specifications and practices is use today. It is mainly used in developing software requiring Object Oriented Analysis (OOA) and Object Oriented Design (OOD).

UML provides the blueprint elements for software architecture. It has become the defacto standard with which computer scientist communicate, analyse and design software. The Current Official Version of UML is 2.1.1, the basic diagrams can be grouped into two main categories, structural and behavioral.

Object Oriented Software
In the 90s object-oriented concepts started to take root and in a few years it become mainstream with the proliferation of object-oriented Languages like C++. Software design practice transitioned from structured development to object-oriented development. OOD/OOA as it has become known was embraced because it encapsulated data and processing logic within a structure called an object. An object in the object-oriented sence is am modeling element that is used to represent entities having the following properties: 1) an identity, 2) state information, and 3) behaviour.

In UML an object is a "specific" instance of a class element as depicted by the following UML class diagram.

There can be many instances for a given class, using the Student class as a example, we can have several Student objects named Shivaji, Tammy and Vijay. It is their name that given the object it's identity, which is not to be confused with the name of the class Student. The following diagram illustrates how an object with the name "Shivaji" belonging to the class Student is depicted.

The only restriction is that no two objects can have the same name, but an object can have an alias, in C++ this is implemented either using a pointer or a reference to an object. As we will learn more complex structures can be depicted and created using classes or objects through different relationships and interactions.

In general UML elements like classes and objects interact by sending and acting on messages and changing state. A message can be a simple command to perform a certain action or a command with data. The key objective throughout the object oriented design process is to try and maintain weak-coupling so that the architecture is easy to modify and maintain. This lends to code reuse since each object has well defined roles.

Substitution Principle
A weak-coupled architecture has more focus on process and less focus on implementation details. When this type of object-oriented software design is achieved, one should be able to replace a class, module or component having one implementation with another having a different implementation. As long as the interface used to interact with objects remains the same then this goal can be more easily achieved.

The "Substitution Principle" comes from the study of behavioural sub-typing by Barbra Liskov and Jeannette Wing, both who are prominent computer scientists. The specific meaning will make more sense when we discuss classes and subclassing, but the principle simply states:

"If a class S is a subtype of class T, then a class T in a software design can be substituted with a class S without altering any of the desirable properties and behaviour of that software design."

Structural Modeling Diagrams
Structural diagrams describe the elements that make up a architect or parts of it. The diagram depicts how each of the UML elements in the model are related using relationship semantics.

Diagrams	Description
Class	Shows the building blocks and their basic structural relationship.
Component	Define complex structures made of classes that provide well defined interfaces.
Composite	Shows the inner details and relationship of a model.
Deployment	Shows the physical layout of a system using nodes to depict various hardware.
Object	Class instance diagrams that show various relationship.
Package	Groups logical models and show how they interact.

Table 1 - Structural Diagrams

Behavioral Modeling Diagrams
Behavioral diagrams describe the way in which the model functions. A diagram denotes action, event, message and state to depict how UML elements in the model interact.

Diagrams	Description
Activity	Shows execution state by a sequence of actions.
Collaboration	Shows how objects come together to form a network, that implements a Use Case. In the simplest sense, a collaboration shows how elements from a structural diagram interact with each other.
State Machine	Describes a state machine and the possible transitions from each state.
Sequence	Shows the interaction of objects with respect to time and the order of control flow.
Use Case	Display various activities performed by a User.

Table 2 - Behavioral Diagrams

Previous

Next

Copyright © 2007 Rajinder Yadav, All rights reserved

UML logo are trademarks or registered trademarks of the Object Management Group, Inc. in the United States and other countries