UNIFIED MODELING LANGUAGE (UML)

UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. UML was created by Object Management Group (OMG) and UML 1.0 specification draft was proposed to the OMG in January 1997. OMG is continuously putting effort to make a truly industry standard.

UML stands for Unified Modeling Language. UML is different from the other common programming languages like C++, Java, COBOL etc. UML is a pictorial language used to make software blue prints.

So UML can be described as a general purpose visual modeling language to visualize, specify, construct and document software system. Although UML is generally used to model software systems but 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 has a direct relation with object oriented analysis and design. After some standardization UML is become an OMG (Object Management Group) standard. UML describes the real time systems. It is used to make a conceptual model. Conceptual model of UML can be mastered by learning the following three major elements:

UML building blocks Rules to connect the building blocks Common mechanisms of UML

The building blocks of UML can be defined as:

Things Relationships Diagrams

(1) Things:
Things are the most important building blocks of UML. Things can be:

Structural Behavioral Grouping Annotational

Structural things:
The Structural things define the static part of the model. They represent physical and conceptual elements. Following are the brief descriptions of the structural things.

Class:
Class represents set of objects having similar responsibilities.

Interface:
Interface defines a set of operations which specify the responsibility of a class.

Collaboration:
Collaboration defines interaction between elements.

Use case:
Use case represents a set of actions performed by a system for a specific goal.

Component:
Component describes physical part of a system.

Node:
A node can be defined as a physical element that exists at run time.

Behavioral things:
A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things:
Interaction: Interaction is defined as a behavior that consists of a group of messages exchanged
among elements to accomplish a specific task.

State machine:
State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.

Grouping things:
Grouping things can be defined as a mechanism to group elements of a UML model together. There is only one grouping thing available:

Package:
Package is the only one grouping thing available for gathering structural and behavioral things.

Annotational things:
Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements. Note is the only one Annotational thing available.

Note:
A note is used to render comments, constraints etc of an UML element.

(2) Relationship:
Relationship is another most important building block of UML. It shows how elements are associated with each other and this association describes the functionality of an application. There are four kinds of relationships available.

Dependency:
Dependency is a relationship between two things in which change in one element also affects the other one.

Association:
Association is basically a set of links that connects elements of an UML model. It also describes how many objects are taking part in that relationship.

Generalization:
Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes inheritance relationship in the world of objects.

Realization:
Realization can be defined as a relationship in which two elements are connected. One element describes some responsibility which is not implemented and the other one implements them. This relationship exists in case of interfaces.

(3) UML Diagrams:

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are used to make a complete UML diagram and the diagram represents a system. The visual effect of the UML diagram is the most important part of the entire process. All the other elements are used to make it a complete one. UML includes the following nine diagrams and the details are described in the following chapters. 1. 2. 3. 4. 5. 6. 7. 8. 9. Class diagram Object diagram Use case diagram Sequence diagram Collaboration diagram Activity diagram Statechart diagram Deployment diagram Component diagram

There are three classifications of UML diagrams: Behavior diagrams. A type of diagram that depicts behavioral features of a system or business process. This includes activity, state machine, and use case diagrams as well as the four interaction diagrams. Interaction diagrams. A subset of behavior diagrams which emphasize object interactions. This includes communication, interaction overview, sequence, and timing diagrams.

Structure diagrams. A type of diagram that depicts the elements of a specification that are irrespective of time. This includes class, composite structure, component, deployment, object, and package diagrams.

Table summarizes the thirteen, up from nine in UML 1.x, diagram types of UML 2.x. In the diagram column the links will take you to description pages for the artifact. The learning priority column indicates how important it is for a business application developer to learn the artifact (IMHO). The diagrams of UML

Diagram
Activity Diagram

Description

Learning Priority

Depicts high-level business processes, including data flow, or to High model the logic of complex logic within a system. Class Diagram Shows a collection of static model elements such as classes and types, High their contents, and their relationships. Communication Shows instances of classes, their interrelationships, and the message Low Diagram flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages. Formerly called a Collaboration Diagram. Component Depicts the components that compose an application, system, or Medium Diagram enterprise. The components, their interrelationships, interactions, and their public interfaces are depicted. . Composite Depicts the internal structure of a classifier (such as a class, Low Structure Diagram component, or use case), including the interaction points of the classifier to other parts of the system. Deployment Shows the execution architecture of systems. This includes nodes, Medium Diagram either hardware or software execution environments, as well as the middleware connecting them. Interaction A variant of an activity diagram which overviews the control flow Low Overview Diagram within a system or business process. Each node/activity within the diagram can represent another interaction diagram. Object Diagram Depicts objects and their relationships at a point in time, typically a Low special case of either a class diagram or a communication diagram. Package Diagram Shows how model elements are organized into packages as well as theLow dependencies between packages. Sequence Diagram Models the sequential logic, in effect the time ordering of messages High between classifiers. State Machine Describes the states an object or interaction may be in, as well as the Medium Diagram transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram. Timing Diagram Depicts the change in state or condition of a classifier instance or role Low over time. Typically used to show the change in state of an object over time in response to external events. Use Case Diagram Shows use cases, actors, and their interrelationships. Medium

CLASS DIAGRAMS To create and evolve a conceptual class diagram, you need to iteratively model:
Classes Responsibilities Associations Inheritance relationships Composition associations Vocabularies

To create and evolve a design class diagram, you need to iteratively model:
Classes Responsibilities Associations Inheritance relationships Composition associations

Interfaces

Associations
Objects are often associated with, or related to, other objects. For example, Students are ON WAITING LIST for seminars, professors INSTRUCT seminars, seminars are an OFFERING OF courses, a professor LIVES AT an address, and so on. Associations are modeled as lines connecting the two classes whose instances (objects) are involved in the relationship. When you model associations in UML class diagrams, you show them as a thin line connecting two classes. Associations can become quite complex; consequently, you can depict some things about them on your diagrams. The label, which is optional, although highly recommended, is typically one or two words describing the association. For example, professors instruct seminars.

Notation for associations.

USE CASE DIAGRAMS

Use case diagrams depict:

Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse. Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures. Associations. Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within the use case. The arrowheads are typically confused with data flow and as a result I avoid their use. System boundary boxes (optional). You can draw a rectangle around the use cases, called the system boundary box, to indicate the scope of your system. Anything within the box represents functionality that is in scope and anything outside the box is not.

Using System boundary boxes to indicate releases.

Applying packages to simplify use case diagrams.

Use case reuse.

SEQUENCE DIAGRAM
he main purpose of a sequence diagram is to define event sequences that result in some desired outcome. The focus is less on messages themselves and more on the order in which messages occur; nevertheless, most sequence diagrams will communicate what messages are sent between a system's objects as well as the order in which they occur. The diagram conveys this information along the horizontal and vertical dimensions: the vertical dimension shows, top down, the time sequence of messages/calls as they occur, and the horizontal dimension shows, left to right, the object instances that the messages are sent to.

Lifelines
When drawing a sequence diagram, lifeline notation elements are placed across the top of the diagram. Lifelines represent either roles or object instances that participate in the sequence being modeled. [Note: In fully modeled systems the objects (instances of classes) will also be modeled on a system's class diagram.] Lifelines are drawn as a box with a dashed line descending from the center of the bottom edge (Figure 3). The lifeline's name is placed inside the box.

Messages
The first message of a sequence diagram always starts at the top and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower than the previous message. To show an object (i.e., lifeline) sending a message to another object, you draw a line to the receiving object with a solid arrowhead (if a synchronous call operation) or with a stick arrowhead (if an asynchronous signal). The message/method name is placed above the arrowed line. The message that is being sent to the receiving object represents an operation/method that the receiving object's class implements.

COLLABORATION DIAGRAM
Collaboration diagrams belong to a group of UML diagrams called Interaction Diagrams. Collaboration diagrams, like Sequence Diagrams, show how objects interact over the course of time. However, instead of showing the sequence of events by the layout on the diagram, collaboration diagrams show the sequence by numbering the messages on the diagram. This makes it easier to show how the objects are linked together, but harder to see the sequence at a glance.

Instance:
An instance of a class shows a sample configuration of an object. On the sequence diagram, each instance has a lifeline box underneath it showing it's existence over a period of time.

Lollipop Interface:
A lollipop interface is shorthand syntax for an interface. It shows the interface name without displaying the operations.

Message:
The message indicates communication between objects. The order of messages from top to bottom on your diagram should be the order in which the messages occur.

COMPONENT DIAGRAM
The component diagram's main purpose is to show the structural relationships between the components of a system. Components are larger design units that represent things that will typically be implemented using replaceable" modules. In component-based development (CBD), component diagrams offer architects a natural format to begin modeling a solution. Component diagrams allow an architect to verify that a

system's required functionality is being implemented by components, thus ensuring that the eventual system will be acceptable. In addition, component diagrams are useful communication tools for various groups. The diagrams can be presented to key project stakeholders and implementation staff. While component diagrams are generally geared towards a system's implementation staff, component diagrams can generally put stakeholders at ease because the diagram presents an early understanding of the overall system that is being built.

The notation
The component diagram notation set now makes it one of the easiest UML diagrams to draw. The example shows a relationship between two components: an Order System component that uses the Inventory System component. As you can see, a component is drawn as a rectangle with two smaller rectangles protruding from its left side.

ACTIVITY DIAGRAM
Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control. Activity diagrams are typically used for business process modeling, for modeling the logic captured by a single use case or usage scenario, or for modeling the detailed logic of a business rule. The basic notation:

Initial node. The filled in circle is the starting point of the diagram. An initial node isnt required although it does make it significantly easier to read the diagram. Activity final node. The filled circle with a border is the ending point. An activity diagram can have zero or more activity final nodes. Activity. The rounded rectangles represent activities that occur. An activity may be physical, such as Inspect Forms, or electronic, such as Display Create Student Screen. Flow/edge. The arrows on the diagram. Although there is a subtle difference between flows and edges I have never seen a practical purpose for the difference although I have no doubt one exists. Ill use the term flow. Fork. A black bar with one flow going into it and several leaving it. This denotes the beginning of parallel activity.

Join. A black bar with several flows entering it and one leaving it. All flows going into the join must reach it before processing may continue. This denotes the end of parallel processing.

Activity diagram for a guided brainstorming process

DEPLOYMENT DIAGRAM
The deployment diagram shows how the components of the completed system are physically related (i.e. what hardware will the system be running on and how will it all be connected).

Each node represents a computational unit such as a piece of hardware.

The connections between the nodes show the system interaction paths.

STATE CHART DIAGRAM

The name of the diagram itself clarifies the purpose of the diagram and other details. It describes different states of a component in a system. The states are specific to a component/object of a system. A State chart diagram describes a state machine. A state machine can be defined as a machine which defines different states of an object and these states are controlled by external or internal events. Activity diagram is a special kind of a State chart diagram. As State chart diagram defines states it is used to model lifetime of an object.

Purpose:
State chart diagram is one of the five UML diagrams used to model dynamic nature of a system. They define different states of an object during its lifetime. And these states are changed by events. So State chart diagrams are useful to model reactive systems. Reactive systems can be defined as a system that responds to external or internal events. Statechart diagram describes the flow of control from one state to another state. States are defined as a condition in which an object exists and it changes when some event is triggered. So the most important purpose of Statechart diagram is to model life time of an object from creation to termination. Statechart diagrams are also used for forward and reverse engineering of a system. But the main purpose is to model reactive system. Following are the main purposes of using Statechart diagrams:

To model dynamic aspect of a system. To model life time of a reactive system. To describe different states of an object during its life time. Define a state machine to model states of an object.