UML UNIFIED MODELING LANGUAGE

WHAT IS UML?

The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.

The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.

GOALS OF UML
The primary goals in the design of the UML were: 1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. 2. Provide extensibility and specialization mechanisms to extend the core concepts. 3. Be independent of particular programming languages and development processes. 4. Provide a formal basis for understanding the modeling language. 5. Encourage the growth of the OO tools market. 6. Support higher-level development concepts such as collaborations, frameworks, patterns and components. 7. Integrate best practices.

WHY USE UML?

As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs.

BASIC BUILDING BLOCKS OF UML

As UML describes the real time systems it is very important to make a conceptual model and then proceed gradually. 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

UML BUILDING BLOCKS

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 includes the following :

Class diagram Object diagram Use case diagram Sequence diagram Collaboration diagram Activity diagram Statechart diagram Deployment diagram Component diagram

CLASS DIAGRAM
Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams describe three different perspectives when designing a system, conceptual, specification, and implementation.

Classes are composed of three things: a name, attributes, and operations.

AN EXAMPLE OF AN ASSOCIATIVE RELATIONSHIP:

ANOTHER COMMON RELATIONSHIP IN CLASS DIAGRAMS IS A GENERALIZATION.

A generalization is used when two classes are similar, but have some differences.

WHEN TO USE: CLASS DIAGRAMS

Class diagrams are used in nearly all Object Oriented software designs. Use them to describe the Classes of the system and their relationships to each other.

HOW TO DRAW: CLASS DIAGRAMS

When designing classes consider what attributes and operations it will have. Then try to determine how instances of the classes will interact with each other. These are the very first steps of many in developing a class diagram. However, using just these basic techniques one can develop a complete view of the software system.

EXAMPLE

OBJECT DIAGRAM
Object diagrams are derived from class diagrams so object diagrams are dependent upon class diagrams. Object diagrams represent an instance of a class diagram. The basic concepts are similar for class diagrams and object diagrams. Object diagrams also represent the static view of a system but this static view is a snapshot of the system at a particular moment. Object diagrams are used to render a set of objects and their relationships as an instance.

PURPOSE:
Forward and reverse engineering. Object relationships of a system Static view of an interaction. Understand object behaviour and their relationship from practical perspective

HOW TO DRAW OBJECT DIAGRAM?

In class diagram elements are in abstract form to represent the blue print and in object diagram the elements are in concrete form to represent the real world object. To capture a particular system, numbers of class diagrams are limited. But if we consider object diagrams then we can have unlimited number of instances. So only those instances are considered which are having impact on the system.

A single object diagram cannot capture all the necessary instances or rather cannot specify all objects of a system. So the solution is: First, analyze the system and decide which instances are having important data and association. Second, consider only those instances which will cover the functionality. Third, make some optimization as the numbers of instances are unlimited.

EXAMPLE
The customer object (C) is associated with three order objects (O1, O2 and O3). These order objects are associated with special order and normal order objects (S1, S2 and N1). The customer is having the following three orders with different numbers (12, 32 and 40) for the particular time considered. Now the customer can increase number of orders in future and in that scenario the object diagram will reflect that. If order, special order and normal order objects are observed then we you will find that they are having some values.

For orders the values are 12, 32, and 40 which implies that the objects are having these values for the particular moment (here the particular time when the purchase is made is considered as the moment) when the instance is captured. The same is for special order and normal order objects which are having number of orders as 20, 30 and 60. If a different time of purchase is considered then these values will change accordingly.

WHERE TO USE OBJECT DIAGRAMS?

Object diagrams can be imagined as the snapshot of a running system at a particular moment. Object diagrams are used for:

Making the prototype of a system. Reverse engineering. Modeling complex data structures. Understanding the system from practical perspective.

SEQUENCE DIAGRAM
UML sequence diagrams are used to show how objects interact in a given situation. An important characteristic of a sequence diagram is that time passes from top to bottom : the interaction starts near the top of the diagram and ends at the bottom. A popular use for them is to document the dynamics in an object-oriented system. For each key collaboration, diagrams are created that show how objects interact in various representative scenarios for that collaboration.

UML sequence diagrams are used to represent or model the flow of messages, events and actions between the objects or components of a system. Time is represented in the vertical direction showing the sequence of interactions of the header elements, which are displayed horizontally at the top of the diagram. Sequence Diagrams are used primarily to design, document and validate the architecture, interfaces and logic of the system by describing the sequence of actions that need to be performed to complete a task or scenario.

UML sequence diagrams are useful design tools because they provide a dynamic view of the system behavior which can be difficult to extract from static diagrams or specifications. Although UML sequence diagrams are typically used to describe object-oriented software systems, they are also extremely useful as system engineering tools to design system architectures, in business process engineering as process flow diagrams, as message sequence charts and call flows for telecom/wireless system design, and for protocol stack design and analysis.