UNIFIED MODELING LANGUAGE

In the field of software engineering, the Unified Modeling Language (UML) is a standardized
specification language for object modeling. UML is a general-purpose modeling language that
includes a graphical notation used to create an abstract model of a system. UML is officially
defined at the Object Management Group (OMG) by the UML Meta model. UML was designed
to specify, visualize, construct, and document software-intensive systems.
UML is for visual modeling:

SPECIFYING
 Building models that are: Precise, Unambiguous, and Complete.
 UML symbols are based on well-defined syntax and semantics.
 UML addresses the specification of all important analysis, design, and implementation
decisions.

CONSTRUCTING
 Models are related to OO programming languages.
 Round-trip engineering requires tool and human intervention to avoid information loss.
 Forward engineering ---- direct mapping of a UML model into code.
 Reverse engineering ---- reconstruction of a UML model from an implementation.

DOCUMENTING
 Architecture, Requirements, Tests, Activities (Project planning, Release management.

THREE BASIC BUILDING BLOCKS of UML:

THINGS
 Important modeling concepts (individual ones as the primitive kinds).
RELATIONSHIPS
 Typing individual things (i.e. their concepts).
DIAGRAMS
 Grouping interrelated collections of things and relationships.
THINGS
 Structural ---- nouns of UML models.
 Behavioral ---- dynamic (verbal) parts of UML models.
 Grouping ---- Organizational parts of UML models.
 Annotational ---- Explanatory parts of UML models.

RELATIONSHIPS
 Dependency
 Associations
 Generalization
 Realization

DIAGRAMS
Graphical representation of a set of elements.

 Use case Diagram

 Activity Diagram
 Sequence Diagram
 Collaboration Diagram
 State chart Diagram
 Class Diagram, Object Diagram.
 Component Diagram
 Deployment Diagram
1. USE CASE DIAGRAM:

A use case is a set of scenarios that describing an interaction between a user and a system. A use
case diagram displays the relationship among actors and use cases. The two main components of
a use case diagram are use cases and actors.

There are three key things we need to know to describe a use case:
1. The actor or actors involved. An actor is a type of user (for example, customer)
That interacts with the system.
2. The system being used.
3. The functional goal that the actor achieves using the system.

ACTOR GENERALIZATION:
The only relationship allowed between actors is generalization. The notation is a solid line
ending in a hollow triangle drawn from the specialized to the more general actor.
USE CASE RELATIONSHIPS:

Three relationships among use cases are supported by the UML standard, which describes
graphical notation for these relationships.

 Include
 Extend
 Generalization
2. ACTIVITY DIAGRAM:

In the Unified Modeling Language, an activity diagram represents the business and
operational step-by-step workflows of components in a system. An activity diagram shows the
overall flow of control.

Element and its description Symbol

Initial Activity: This shows the starting point or first activity of

the flow. Denoted by a solid circle. This is similar to the
notation used for Initial State.

Activity: Represented by a rectangle with rounded (almost

oval) edges.

Decisions: Similar to flowcharts, a logic where a decision is to

be made is depicted by a diamond, with the options written on
either side of the arrows emerging from the diamond, within
box brackets.

Signal: When an activity sends or receives a message, that

activity is called a signal. Signals are of two types: Input signal
(Message receiving activity) shown by a concave polygon and
Output signal (Message sending activity) shown by a convex
polygon.

Concurrent Activities: Some activities occur simultaneously

or in parallel. Such activities are called concurrent activities.

Final Activity: The end of the Activity diagram is shown by a

bull’s eye symbol, also called as a final activity.
3. SEQUENCE DIAGRAM:

The main purpose of a sequence diagram is to define event sequences that result in some desired
outcome.
LIFE LINES:
When drawing a sequence diagram, lifeline notation elements are placed across the top of the
diagram.

The UML standard for naming a lifeline follows the format of

Instance Name: Class Name

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 then the previous message.
4. COLLABORATION DIAGRAM:

A Communication diagram models the interactions between objects or parts in terms of

sequenced messages. Communication diagrams represent a combination of information taken
from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic
behavior of a system.
5. STATE CHART DIAGRAM:

The Unified Modeling Language (UML) state diagram is essentially a standardized notation,
which can describe a lot of things, in the form of states. The following are the basic notational
elements that can be used to make up a diagram:

 Filled circle, pointing to the initial state.

 Hollow circle containing a smaller filled circle, indicating the final state.
 Rounded rectangle, denoting a state. Top of the rectangle contains a name of the state.
Can contain a horizontal line in the middle, below which the activities that are done in
that state are indicated.
 Arrow, denoting transition. The name of the event (if any) causing this transition labels
the arrow body.
6. CLASS & OBJECT DIAGRAMS:
Classes are depicted as boxes with three sections, the top one indicates the name of the class, the
middle one lists the attributes of the class, and the third one lists the methods.
An object is any person, place, thing, concept, event, screen, or report applicable to your system.
Objects both know things (they have attributes) and they do things (they have methods). A class
is a representation of an object and, in many ways; it is simply a template from which objects are
created.

Example for Course class diagram

ASSOCIATIONS:
Objects are often associated with, or related to, other objects. Associations are modeled as lines
connecting the two classes whose instances (objects) are involved in the relationship. When we
model associations in UML class diagrams, we show them as a thin line connecting two classes.

Relationship Symbol Line Arrow Tip

Style
Inheritance Solid Triangle

Interface Dotted Triangle

Implementation
Aggregation Solid Diamond

Dependency otted Open

7. COMPONENT DIAGRAM:

Component diagrams represent the implementation perspective of a system. Hence, components

in a Component diagram reflect grouping of the different design elements of a system, for
example, classes of the system.

In the Unified Modeling Language, a component diagram depicts how a software system is split
up into physical components and shows the dependencies among these components. Physical
components could be, for example, files, headers, link libraries, modules, executables, or
packages. Component diagrams can be used to model and document any system’s architecture.

Component
8. DEPLOYMENT DIAGRAM:

In the UML, a deployment diagram serves to model the hardware used in system
implementations, the components deployed on the hardware, and the associations between those
components. The elements used in deployment diagrams are nodes (shown as a cube),
components (shown as a rectangular box, with two rectangles protruding from the left side) and
associations.

Element and its description Symbol

Node: The element that provides the execution

environment for the components of a system.
Depicted by a cube with the name of the object in it,
preceded by a colon, and underlined.

Connection: Similar to the relation/association used

in class diagrams to define the interconnection
between nodes.
 RATIONAL ROSE
Rational Rose is the visual modeling ware solution that lets you create, analyze, design, view,
modify and manipulate components. You can graphically depict on overview of the behavior
your system with a use case diagram .Rational Rose provides the collaboration diagram as an
alternative to a use case diagram .It shows object interactions organized around objects and their
links to one another. The state chart diagram provides additional analysis techniques for classes
with significant dynamic behavior .Activity diagrams provide a way to model a class operation
or the work flow of a business process.

Rational Rose provides the notation needed to specify and document the system architecture .The
logical architecture is captured in class diagrams that contain the classes and relationships that
represent the key abstractions of the system under development .The component architecture is
captured in component diagrams that focus
on the actual software module organization with in the development environment .The
deployment architecture is captured in deployment diagrams that map software to processing
nodes showing the configuration of the run time processing elements and their software
processes .

FEATURES
Rational Rose provides the following features facilitates the analysis, design and iterative
construction of your application
 Use-Case Analysis
 Object –Oriented Modeling
 User-configurable Support for UML ,COM ,OMT and Booch’93
 Semantic Checking
 Support for Controlled Iterative Development
 Round-Trip Engineering
 Parallel Multi- user Development.
 Integration with Data Modeling tools
  Document generation
 Rational Rose scripting for integration and Extensibility
 OLE Linking
 OLE Automation
 Multi Platform Availability

EXTENDING RATIONAL ROSE

The add-in feature allows you to quickly and accurately customize your Rational Rose
environment depending on your development needs. Using the add-in tool, you can install
language and non language tools while in Rational Rose.
When an add-in is installed, it is automatically in an activated state. Add-ins can install
 Menus(.mnu files)
 Help files(.hlp files)
 Contents tab files(.cnt files)
 Properties (.pty files)
 Executables (.exe)
 Script files(.ebs script source file and .ebx compiled script file)
 OLE servers(.dll files)
Additionally, an add-in can define fundamental types, predefined stereotypes, and metafiles.
Note that an add-in is not to be considered strictly a one-to one association with a round-trip
engineering integration.