UNIFIED MODELLING LANGUAGE (UML)
Introduction
Unified
Modeling Language (UML) is a standardized general purpose modeling language in
the field of software engineering.UML includes a set of graphical notation
techniques to create visual models of software intensive systems. The unified
modeling language is used to specify, visualize, modify, construct and document
the artifacts of object oriented software intensive system under development.
UML
offers a standard way to visualize a system’s architectural blueprints,
including elements such as actors, business processes, logical components,
activities, programming language statements, database schemas and reusable
software components.
Object
oriented languages (modeling) appeared sometime between the mid 1970s and the
late 1980s as methodologists, faced with a new genre of object oriented
programming languages and increasingly complex applications, began to
experiment with alternative approaches to analysis and design.
The
team James Rumbaugh (OMT - Object Modeling Techniques) which was better for
object oriented analysis and Grady Booch’s (Booch method) which was better for
object oriented design. Together Rumbaugh and Booch attempted to reconcile
their two approaches and stated work on a unified method. They are soon
assisted in their efforts by Ivar Jacobson, the creator of the object oriented
software engineering (OOSE) method.
Under
the technical leadership of the three amigos, an international consortium
called UML partners was organized in1996 to complete the Unified Modeling
Language (UML) specification. Those partners contributing to the UML 1.0
definition including digital equipment corporation, HP, Ilogix, intellicorp,
IBM, Microsoft, Oracle, rational, Texaus Instruments, and Unisys. This
collaboration resulted in the UML 1.0, a modeling language that was well defined,
expressive, powerful and applicable to a wide spectrum of problem domain.UML
1.0 was offered for standardization to the object management group (OMG) in
January 1997, standardized in November 1997 by OMG.
UML
is an international standard language.UML has matured significantly since UML
1.1 several minor revisions (UML 1.3, 1.4, 1.5) fixed short comings and bugs
with the first version of UML, followed by the UML 2.0 major revision that was
adopted by the OMG in August 2005. The current versions of these standards
follow: UML super structure version 2.2, UML infrastructure version 2.2, and
UML diagram interchange version 1.0. The UML is appropriate for modeling
systems ranging from enterprise information systems to distributed web based
applications and even to hard real time embedded systems. The UML is a language
for visualization, specifying, constructing, and documenting the artifacts of a
software intensive system.
The
UML is intended primarily for software intensive systems. It has been used
effectively for such domains as
·
Enterprise Information system
·
Banking and financial services
·
Retail
·
Telecommunications
·
Transportation
·
Defense/aerospace
·
Medical electronics
·
Scientific
·
Distributed web -based services
We
create models for the different type of intensive systems by using UML.
Depending on the nature of the system, some models may be more important than
others. They are data intensive systems, GUI intensive systems, hard real time
systems and distributed system (web based applications).
RATIONAL ROSE SOFTWARE
Rational
rose is a powerful tool to aid in the analysis and design of object oriented
software systems. Rational rose provides support for two essentials elements of
two modern software component based development and controlled iterative
development. These concepts are conceptually independent. Their usage is
combination in both natural and beneficial. Rational rose model diagram
architecture facilitates use of unified modeling language, component object
based modeling techniques (COM), and object modeling techniques (OMT).Using
semantic information ensures correctness by construction and maintaining
consistency.
Visual Modeling
Visual
modeling is the mapping of real world process of a system to a graphical representation.
Models are useful for understanding problems communicating with everyone
involved with project customers, domain system experts, analysts, designers
etc, modeling complex systems, preparing documentation, and designing programs
and data bases. Modeling promotes better understanding of requirements clear
designs and more maintainable systems. As software systems becomes more complex
we cannot understand them in their entirely to effectively build a complex
system. The developer begins by looking at the big picture without getting
caught up in the details.
Visual
modeling also defines architecture by providing capabilities to capture the
logical software architecture independent of the software language. This method
provides flexibility to our system design since the logical architecture can
always be mapped to a different software language.
Finally
with visual modeling we can reuse parts of a system or an application by
creating components of our design. These components can then be shared and
reused by different members of a team allowing changes to be easily
incorporated into already existing development software.
Rational
rose is the visual modeling software solution that lets us create, analyze,
design, view, modify and manipulate components. We can graphically depict an
overview of the behavior of our system with the use case diagram. It shows
object interactions organized around objects and their links to one another.
The state chart diagrams provide additional analysis techniques for classes
with significant dynamic behavior. A state chart causes a transition from one
state to another and actions the result from a state change. Activity diagrams
provide a way to model a class operation or the work floe of business process.
Rational rose provides the notation needed to specify and document the system
architecture.
The
logical architecture is captured in the class diagrams that contain the classes
and relationships that represent the key abstractions of the system under
development. The component architecture in component diagrams that focus on the
actual software module organization within the development environment. The
development architecture is captured in the deployment diagrams that maps
software to process nodes showing the configuration of runtime processing
elements and then the software process.
Rational rose software Application
Rational
rose is a powerful tool to aid the analysis and design of object oriented
software system. Rose is a tool meant to be used by the entire project team. It
is a responsibility of scope and design environment information and each team
member can be used to get the information they need.Rose will help developers
by generating Skelton code. Rose can be reverse engineer the code and creates a
model based on an existing based system. When a change occurs to the model rose
can modify the code to incorporate the change.
Different versions
Rose Modeler It allows us to create a model for a system
but will not support code generation or reverse engineering.
Rose Professional It
allows us to generate code in c++, java, visual basic and oracle.
Views of Rational Rose Model
Ø Use case view
The
use case view includes all of the use cases, actors, and usage diagrams in the
system. The use case view also includes Use case documentation, which explains
the flow through the use case, including error handling. Interaction diagrams
which display the objects or classes involved in one flow through a use case.
Packages which are groups or use case or actors. A package is a UML mechanism
that helps us to group similar items together.
Ø Logical view
Logical
view provides detailed picture of the pieces of the system and describes how
the pieces interrelated. The logical view also includes Classes which contains
the information of a system attributes. Class diagrams, which are used to view
the classes in the system. Interaction diagram, which are used to display the
classes that participate which shows dynamic behavior of an object.State
transition diagrams which shows dynamic behavior of an object. Packages which
are groups of related classes. The flow of logical view is on the logical
structure of the system. In this view
we can identify the process of the system, examine the information and
behavior of the system and examine relationship between pieces.
Ø Component View
A
component view contains information about the code libraries, executable files,
run time libraries, and other components in the model. In rational rose
components and component diagrams displayed in the component view. The
component view of the system allows us to see the relationships between models
of the code. Component diagrams show the components and their relationships to
each other. Packages which are groups of related components.
Ø Deployment view
Deployment
view concerned with the physical view in concern with physical deployment of
the system, which may differs from the local architecture of the system. The
deployment may be two tired. The interface may be placed on one machine while
the business or database logic are located on another machine. Other issues
such as network band width, fault tolerance, response time and disaster
recovery are handled using deployment view.
CONCEPTUAL
MODEL OF UML
The conceptual model of
language UML requires three major elements to understand.
1.
The UML basic building blocks.
2.
The rules that dictate how these
building blocks put together.
3.
Some common mechanisms.
Building
Blocks of UML
1.
Things
2.
Relationships
3.
Diagrams
Things
in UML
1. Structural things
1.1 Classes
1.2 Interfaces
1.3 Collaborations
1.4 Use Cases
1.5 Active
Classes
1.6 Components
1.7 Nodes
2. Behavioral things
2.1 Interactions
2.2 State
machines
3. Grouping things
3.1
Packages
4. Annotational things
4.1 Notes
Relationships in UML
1.
Dependency
2.
Association
3.
Generalization
4.
Realization
Diagrams in UML
1.
Class Diagram
2.
Object Diagram
3.
Use case Diagram
4.
Sequence Diagram
5.
Collaboration Diagram
6.
State chart Diagram
7.
Activity Diagram
8.
Component Diagram
9.
Deployment Diagram
Things
in UML
Structural Things
Structural things are nouns of the
UML models. These are mostly static parts of a model representing elements that
are either conceptual or physical.
There are 7 kinds of structural
things.
Class
A
class is a set of description of set of objects that share the same attributes,
operations, relationships, and semantics. A class implements one or more
interfaces. Graphically a class is
rendered as a rectangle usually including its name, attributes and operations.
Interface
An
interface is a collection of operations that specifies a service of a class or
a component. An interface describes the externally visible behavior of that
element. An interface might represent the complete behavior of a class or
components or only a part of that behavior.
An
interface defines a set of operations implementations. Graphically an interface is rendered as a
circle together with its name. An interface rarely stand alone, rather it is
typically attached to a class or components.
Collaboration
Collaboration
defines an interaction with roles and other elements to provide some behavior.
Collaborations will have structural and behavioral aspects. Collaboration will
be represented by an ellipse with dashed lines, usually including its name.
Use Case
A
use case is a description of set of sequence of actions that a system performs.
A use case is used to structure the behavioral things on a model .A use case is
realized by a collaboration. Graphically a use case is rendered as an ellipse
with solid lines, usually including its name.
Active Class
An
active class is a class whose objects own one or more processes or threads. An
active class is just represented like a class with heavy lines with its name,
attributes, and operations.
Component
A
component is a physical and replaceable part of a system. Components are
artifacts of the development process. A component typically represents the
physical packaging of logical elements such as classes, interfaces, and collaborations,
graphically rendered as a rectangle with tabs usually including only its name.
Node
A
node is a physical element that exists at runtime and represents a
computational resource. A set of components may reside on abode and migrate
from one node to another. Graphically a node is rendered as a cube usually
including only its name.
Behavioral
Things
Behavioral things are dynamic parts
of UML models. These are the verbs of a model, representing behavior overtime
and space. There are two primary kinds of behavioral things.
Interaction
An interaction is a behavior that
comprises a set of messages among a set of objects with in a particular context
to accomplish to specific purpose. An interaction includes messages, action
sequences and links. Graphically a message is rendered as a direct line,
including its name and operations.
State Machine
A state machine is a behavior that
specifies sequence of states of an object or an interaction goes through during
its life time in response to events together with its response to those events.
The behavioral of a individual class or a collaboration of classes may be
specified with a state machine. A state machine involves a number of other
elements including states, transitions, and events, activities. Graphically it
is rendered as a rounded rectangle usually including its name and its sub
states.
Grouping
things:
Grouping things are the
organizational parts of the UML model into which a model can be decomposed.
There is one primary key of grouping things namely packages.
Packages
A package is a general purpose
mechanism for organizing elements into groups. Structural things, behavioral
things, or even other grouping things may be placed in a package. Graphically
it is rendered as a tabbed folder, usually including its name and its content.
Annotational
Things:
Annotational things are the
explanatory parts of UML models. These are the comments use to describe,
illuminate about any element in a mode.
Note
A
note is a notational thing which is simply a symbol for rendering constraints,
and comments attached to the element or a collection of elements. Graphically a
note is rendered as a rectangle with a dog eared corner, together with textual
or graphical comments.
Relationships
There are four kinds of
relationships in the UML.
·
Dependency
·
Association
·
Generalization
·
Realization
Association
Association is a structural
relationship that specifies that objects of one class or thing are connected to
objects to the other thing or class association is a structural relationship
between two classes and is modelled by a line connecting the two classes. There
are four adornments that apply to Association relationship. They are
·
Name
·
Role
·
Direction of Name
·
Multiplicity
Name
An Association can have a name
and use that name to describe the nature of the relationship. We can also give
the direction to the name by providing a direction triangle those points in the
direction we intend to read the name.
Role
When a class participates in an
association, it has a specific role that it plays in that relationship. A role
is just the face the class at the end of the association presents to the class
at the other end of the association
Multiplicity
Multiplicity shows the how many
objects or roles participating in an Association It can be written as an
expression that evaluates to a range of values or an explicit value as in
below.
·
Zero to One 0....1
·
Zero to Many
0....*
·
Zero to Many
0....*
·
Specific Number
n
For example An Association with
these adornments can be show in below fig.
Aggregation
A plain association between two classes represents a
structural relationship between peers, meaning the both classes are
conceptually at the same level no more important than the other. This kind of
relationship is called aggregation which represents a “has-a “ relationship
meaning that an object of the whole has objects of the part. It is a special
kind of association and specified by adorning a plain association with open
diamond at the whole end. Aggregations indicate whole part-of
relationship.
It is rendered as 
Composition
Composition is a strong type of
association relationship. This type of relationship can be placed between the
whole and part classes if we delete one class the other class also get
destroyed.
Composition
relationship means the class is a member of another class. It can be rendered
as association
 |
Generalization
Generalization is relationship between the general
thing (super or parent class) and more specific kind of that thing (Subclass or
Child class). Sometimes it is called as “ is-a-kind-of” relationship. A child
inherits the properties of its parent class especially attributes and
operations. Graphically, Generalization can be rendered as a solid directed
line with large open arrowhead as shown in below
 |
|||
 |
|||
