You are on page 1of 18

SREE VISVESVARAYA INSTITUTE OF TECHNOLOGY AND SCIENCE

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

RECENT TRENDS IN

OOAD

THROUGH

UML

SUBMITTED

BY:

V.RAGHUVEER,

  • III B.TECH, CSE,

SVITS.

CONTACT ME AT:

E-MAIL ID : VEER_13 @ YAHOO.CO.IN,

H.NO:16-82,

OPP : OLD BUS BUSTAND, WANAPARTY.

ABSTRACT:

The subject “OBJECT ORIENTED ANALYSIS AND DESIGN THROUGH UML” is basically designed to model the object oriented applications in real world. UML provides basic elements to design the elements ,which is implemented by the developer, where the programmer save the time.

In this paper it briefly described the concepts of OOA and OOD separately and combinely as OOAD ,then a brief history of UML evolution, and how it supported the concepts of OOAD which are used in wide range now a day.

And in this it also mentioned what that TOOLS OF UML at are used in OOAD to make it effective and efficient, it is also mentioned how that tools of UML served to OOAD are with a brief concept and with appropriate figures which makes us to understand easily. So in tour of over all paper it shows you how the UML had became A TERND SETTER OF OOAD.

INTRODUCTION :

Software development involves developing a complete software system. This does not mean just coding or programming. The software system being developed should cover all possible problem domains. It should also cover all levels of complexity. The main aim of software development is to engineer the illusion of simplicity. The complexity of a system indicates a hierarchy where in the system is decomposed into a collection of subsystems. The system represents the highest levels in hierarchy in a given context. These complex system usually evolve from stable intermediate forms, complex systems may either observed as by focusing on things or processes. It becomes necessary to decompose complex systems during design into smaller independent parts using the algorithmic or object oriented techniques. The object model contains OOA and OOD which are the object oriented decomposition. The elements of this model are abstraction, encapsulation modularity, hierarchy, typing, concurrency and persistence.

OBJECT DESIGN

ORINTED

ANALYSIS

&

For better understanding and analysis, we may split and these words separately and may define it as follows:

OBJECT ORIENTED ANALYSIS (OOA) :

Object Oriented Analysis is a method of analysis that examine the requirements from perspective of the class and objects found in vocabulary of problem domain, as a part of domain analysis done by domain expert.

Analysis is the process of extracting the needs of a system and must do to satisfy the clients requirements. The aim of OOA is to first understand the problem domain and systems responsibilities by understanding how the user use or will use the system.

OBJECT ORIENTED DESIGN(OOD) :

It leads to Object Oriented Decomposition and uses different notations to express models of LOGICAL (class & object structure) and PHYSICAL (module or process architecture) in addition to static and dynamic models of system under design.

The aim of OOD is to design classes identified during analysis phase and user interaction. Additional classes and objects are identified in OOD to support implementation of requirements.

INTODUCTION OF OBJECT ORIENTED CONCEPTS IN LANGUAGES:

Many different languages of FOURTH GENERATION like Ada, Smalltalk, Close, C++, Eiffel, etc are invented but only OBJECT- BASED and OBJECT-ORIENTED languages were best supported like C++, Java etc.

  • 1. The physical building block in object based and object oriented languages is a modules which represents collection of classes and objects instead of subprogram

  • 2. There is little or no global data, instead data and operations are united in such a way that the Basic Building Blocks are CLASSES and OBJECTS not algorithms.

In STRUCTURED DESIGN methods the complex systems are build using ALGORITHMS as fundamental blocks. Since in OBJECT ORIENTED DESIGN methods objects and classes are used as basic building blocks to construct a complex system. Object oriented programming has mainly influenced object model.

Object Model:

As the bulding of models is very necessary for the construction of complex systems, object oriented development

offers various sets of models as shown in the figure. The models of object oriented analysis & design shows the importance of capturing the class & object hierarchies of the system being designed in an explicitly manner. They cover the range of the important design steps to considered the develop complex system.

“Object oriented technology is built upon engineering foundations, whose elements are collectively called Object model. The object model shows static relationship between objects and encircles the principles of abstraction, encapsulation, modularity, hierarchy, typing, concurrency and persistence”

INTRODUCTION TO UML :

The unified modeling language (UML) is a standard language for specifying, visualizing, construction and documenting the software system and its components. It is a graphical language which provides a vocabulary and set of semantics and rules. The UML focuses on the conceptual and physical representation of the system. It captures the decisions and understandings about systems that must be constructed. It is used to understand, design, configure, maintain and control information about systems. Even though UML is not a programming language its tools can provide code generators from UML into various OO programming languages .

NEED OF MODEL IN UML :

Provide structure for problem solving Experiment to explore multiple solutions Furnish abstractions to manage complexity Reduce time-to-market for business problem solutions Decrease development costs Manage the risk of mistakes

NEED OF UML :

So we already observed the need of modeling in software design

Basically there are two approaches:

  • 1. Algorithmic approach

  • 2. Object oriented approach

In algorithmic approach where the main building block of all software is procedure or function. This focuses on issue of control & decomposition of larger algorithms into smaller once. But in this view as requirements changes it becomes hard to maintain. But in Object Oriented approach the main building block of all software systems is the object or class. Object is athing and class is a description of a set of common objects. Every object has an identity or name, state and behavior.

“ So here comes the need of UML in software design in object oriented approach , so called Object Oriented Analysis & Design through UML.”

WHY UML ?

Here our intention is to highlight the usage of UML in contrast with other languages. Before UML was introduced there is not a perfect way efficient way to design software , such that a particular design of software was unable to meet the clients(user) expectations, since it had become very difficult task to both client & designer to communicate each other to produce a good software design. So by using the tools of UML by adopting to any recent platforms of UML like RATIONAL ROSE or by VISUAL PARADIGM, ‘ we can best depict the software intensive system by using different diagrams available in UML. Generally software design will be done by dividing problem domain in modules since each module will be handeled by some part of software development teams, as apart it is very important to communicate among them, since it had become very easy to them to communicate by using simple diagrams in UML, which will be documented in a simple language understandable for software designers I different modules and even for common user, since the diagrams with documentation, user is now in a stage to understand the design of software, but with out UML it is not possible.

GOALS OF UML:

The Unified Modeling Language (UML) aims to:

Provide developers with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models

Provide extensibility and specialisation mechanisms to extend the core concepts

Provide extensibility and specialisation mechanisms to extend the core concepts

Be independent of particular programming languages and development processes

SCOPE OF UML:

o

Fuses concepts of Booch, OOSE/Jacobson and

o

OMT/Rumbaugh (the ‘three amigos’) Development began in October 1994 at Rational Software

o

Corporation, by Booch and Rumbaugh Jacobson (and his Objectory company) joined Rational in

o

October 1995 First releases of UML in 1996

Many companies then joined forces, e.g. Rational Software, HP, Microsoft, Oracle, Unisys, etc.

UML (UNIFIED MODELING LANGUGE)

An emerging open standard for modeling object-oriented software. Resulted from the convergence of notations from three leading object-oriented methods (James Rumbaugh), OOSE (Ivar Jacobson), Booch (Grady Booch) Supports the entire software development lifecycle Supports diverse applications areas Supported by several case tools e.g. Rational ROSE, Together/j

Building Blocks of UML

BIULDING BLOCKS OF

UML

1.Things

  • - structural thing

  • - behavioral things

  • - grouping things

-annotational things 2. Relationships

  • - dependency

  • - generalization

  • - association -realization 3.Diagrams ( 9 types of diagrams)

    • - class diagrams

    • - object diagrams

    • - component diagrams

    • - deployment diagrams (to view static parts of the system)

    • - use case diagram

    • - Sequence diagrams

    • - collaboration diagrams

    • - state chart diagrams

    • - activity diagrams

Structural things are the nouns of Uml models. These are static parts of model, which might be either conceptual or physical. Since there are seven types of structural things. Behavioral things are dynamic part of UML model. These are verbs of a model, representing behavior time and space, since these are two types. Grouping things are the organizational part of the UML. These are boxes into which a model can be decomposed (eg: package). Annotational things are explanatory parts of UML models. These are comments to describe about any element is a model.

BELOW FIGURE DEPICTS ALL THE INFORMATION

UML Concepts and Notation

UML

Things Relationships Diagrams Dependency Association Structural Generalization Use case Class Annotational Grouping Active Class Note Behavioral
Things
Relationships
Diagrams
Dependency
Association
Structural
Generalization
Use case
Class
Annotational
Grouping
Active Class
Note
Behavioral
Package
Interface
Model
Component
Subsystem
Use case
Class
Sequence
Collaboration
Statechart
Activity
Component
Deployment
Collaboratin
.
Framework
Node

STRUCTURAL MODELING:CORE ELEMENTS

Construct

Description

Syntax

class

a description of a set of objects that share the same attributes, operations, methods, relationships and semantics.

 

interface

a named set of operations that characterize the behavior of an element.

 

component

a modula r, replaceable and significant part of a system that packages implementation and exposes a set of interfaces.

 

node

a run -time physical object that represents a computational resource.

 

STRUCTURAL MODELING:CORE RELATIONSHIP

Construct

Description

Syntax

association

a relationship between two or more classifiers that involves connections among their instances.

association a relationship between two or more classifiers that involves connections among their instances.

aggregation

A special form of association that specifies a whole-part relationship between the aggregate (whole) and the component part.

aggregation A special form of association that specifies a whole-part relationship between the aggregate (whole) and

generalization

a taxonomic relationship between a more general and a more specific element.

 

dependency

a relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).

dependency a relationship between two modeling elements, in which a change to one modeling element (the

There is another relation called ‘realisation’ which may be defined as ‘A relationship between specification and its implementaion.

And it is denoted by “----------------->”

USE CASE MODELING :

CORE ELEMENTS

Construct

Description

Syntax

 

use case

A sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system.

 

actor

A coherent set of roles that users of use cases play when interacting with these use cases.

 
actor A coherent set of roles that users of use cases play when interacting with these
 

A

c

t

o

r

N

system

Represents the boundary between

system Represents the boundary between
 

boundary

the physical system and the actors who interact with the physical system.

In the above tabular column it is specified the use case model of UML which is a very important task in modeling the software ,in this type model it particularly specifies Use Case, Actor, System boundaries as its constructs ,since its description is mention briefly with appropriate diagrams.

UML Concepts and Notation

 

Name

 

Attributes

(private)

Operations

(public)

 

Respon-

 

sibilities

(public)

 

Use case

Action
Action

Name(Active class)

 

Attributes

 

(private)

Operations

(public)

Respon-

 

sibilities

(public)

Actor

Analysis Entity Class
Analysis
Entity Class

Component

UML Concepts and Notation Name Attributes (private) Operations (public) Respon- sibilities (public) Use case Action Name(Active

Package

Name

   

Analysis

Boundary Class

Analysis Control Class

Note Textual content
Note
Textual
content
Sequence Diagram ∑ Used during requirements analysis ∑ To refine use case descriptions ∑ to find

Sequence Diagram

Used during requirements analysis To refine use case descriptions to find additional objects (participating objects) Used during system design o refine subsystem interfaces Classes are represented by columns Messages are represented by arrows

Activations are represented by narrow rectangles to sent the message, and is as long as all nested activations Lifelines are represented by dashed lines

Captures dynamic behavior (time-oriented) in terms of interaction

Model flow of control Illustrate typical scenarios Complement the class diagrams which represent structure.

Statechart Diagram

Captures dynamic behavior (event-oriented) Purpose Model object lifecycle Model reactive objects (user interfaces, devices, etc.)

Activity Diagrams

A

special

case

of

a

state chart diagram in

which states are

activities (“functions”) Model business workflows, flow control within a system, and operations,Captures dynamic behavior (activity-oriented)

.

A COMPONENTE DIAGRAM:

shows the organizations and dependencies among a set of components. address the static implementation view of a system.

are related to class diagrams in that a component typically maps to one or more classes, interfaces, or collaborations.

A DEPLOYMENT DIAGRAM:

Captures the topology of a systems hardware

Built as part of architectural specification

Purpose -Specify the distribution of components -Identify performance bottlenecks Developed by architects, networking engineers, engineers

and system

SEQUENCE DIAGRAM :

Mainly emphasizes on time ordering of messages between object Used during requirements analysis To refine use case descriptions Purpose

of

-Captures dynamic behavior (time-oriented) in terms interaction.

Illustrate typical scenarios Complement the class diagrams which represent structure

COLLABORATION DIAGRAM :

Mainly emphasizes on structural organization of messages between objects

Captures dynamic behavior (message-oriented) Purpose

-Model flow of control -Illustrate coordination of object structure and

control

Diagrams

Class Diagrams Use Case Diagrams Object Sequence Diagrams Diagrams Collaboration Component Diagrams Models Diagrams Deployment Statechart
Class
Diagrams
Use Case
Diagrams
Object
Sequence
Diagrams
Diagrams
Collaboration
Component
Diagrams
Models
Diagrams
Deployment
Statechart
Diagrams
Diagrams
Activity
Diagrams

How all diagrams are useful in a software project development?

CONCLUSION:

Since UML had best supported Object Oriented Analysis and Design concepts with its nine diagrams by which we can best design the software graphically which is a very easy and effective medium to communicate, even for ordinary user (client) with designer since then it considerably decreased the lack of communication between client and designer and between software teams which work by dividing the software as separate modules.

In all the above papers it is mentioned that recent trends following in OOAD with the help of UML i.e, “RECENT TRENDS IN OOAD THROUGH UML”, since we can perfectly say that object oriented concepts are used widely now a days for various applications because of involvement of UML in OOAD concepts. Since we can conclude by saying that

“UML IS STEPPING STONE OF SUCCESS OF OBJECT ORIENTED CONCEPTS”.

BIBLOGRAPHY:

LIST OF BOOKS REFERED:

  • 1. The Unified Modeling Language user guide by Grady Booch, James Rambaugh and Ivar Jackbson.

  • 2. OOAD with Applications by Gady Booch.

  • 3. Mastering UML with Rational Rose.

LIST OF WEBSITES:

  • 1. www. rational.com/rose

  • 2. www. tigris.r/servelt

  • 3. www. sunjava.com