UNIT-I

Introduction of Object Oriented Modeling

- Prasad Mahale

Object Oriented Modeling and Design

Reference Books:

1. Grady Booch, James Rumbaugh, Ivar Jacobson “UnifiedModeling Language User Guide”, Addison-

Wesley

2.Rambaugh, “Object Oriented Modeling and Designing”. PHI

3. Bouch. “Object Oriented Analysis and Design withApplications”. Addison Wesley.

4. Dan Pilone, Neil Pitman “UML 2.0 in a Nutshell”, O'Reilly

5. Schah, “Introduction to OOAD with UML and Unified Process”,TMH

a. What is object-oriented?

The term “Object Oriented” means that we organize softwareas collection of discrete objects that incorporate both datastructure and behavior.

Characteristic of object

IdentityData is quantized into discrete, distinguishable entity calledobject

ClassificationA collection of objects with the same data structure(attributes, state variables) and behavior(function/code/operations) grouped into class.

Polymorphism:-

Same operation may behave differently on different classes

The ability to hide many different implementations behind a single interface

Operation is an action or transfer that an object perform

Specific implementation of an operation by a certain class is called method

Inheritance :-

Sharing of attribute & operation among classes based on hierarchicalrelationship

Automatic duplication of super class attribute and behavior definitions in subclass.

Sharing of attribute & operation among classes based on hierarchical relationship

Lawrence Chung CS6359.OT1: Module 1 6

Class Car

AttributesModel Location

Operations Start Accelerate

What is Object-Orientation- Example of Abstraction and Encapsulation

Modeling Concept, Not Implementation

Object – Oriented Methodology

Methodology consist building a model of an application domain & thenadding implementation detail to it during design of a system, it’s knownas object – modeling technique (OMT) Steps:-

1. Analysis

• build a model of real-world situation sowing it’s important properties

• Understand the problem statement

• Object in model is application domain concept, not computerimplementation

b. What is Object oriented development?

2. System design

• make higher level decision about overall architecture

• Target system is organized into subsystem based on analysis structure &proposed architecture

3.Object design

• Build design model based on analysis model but containimplementation detail

• Focus on data structure & algorithm needed to implement eachclass

4. Implementation

• Object classes & relationships of object design are translated into aparticular programming language, d/b & h/w implementation

b. What is Object oriented development?

Three Models

OMT methodology uses three kinds of models to describea system:

1. Object model - describes the objects in the system and theirrelationships;

2. Dynamic model - describes the interactions among objects in thesystem; and

3. Functional model - describes the data transformations of thesystem.

c. Object oriented themes Abstraction

Abstraction consist of focusing on the essential, inherentaspects of an entity and ignoring its accidental properties.

Encapsulation

Encapsulation ( information hiding) consists of separatingthe external aspects of an object, which are accessible toother objects, from the internal implementation details ofthe object, which are hidden from other objects.

Combing Data and Behavior

objects, not developers, decide how to carry out operations

Sharing

The sharing of code using inheritance is one of the mainadvantage of OO language.

Emphasis on Object Structure, Not Procedure Structure

OOT stresses specifying what an object is , rather than how itis used.

Synergy

Identity, classification, polymorphism and inheritancecharacterize mainstream OO language. Each of these conceptscan be used in isolation, but together they complement eachother synergy.

Why We Model ?

Itntroduction to UML, page 14

Modeling

• When you make a model you are making a mapping from theproblem domain to a representation of the system you aremodeling.

• When you work object-oriented the model tends to be close to thesystem modeled, and a program execution can be regarded as asimulation of the behavior of the system.

Reality

System

Itntroduction to UML, page 16

Why Do We Model?• Models give us a template that guides us in constructing a

system.

• If you want to make a building you first make a blueprint of thebuilding to make, in the same way you should make a model of thesystem you want to make. As the complexity of systems increases, sodoes the importance of good modeling techniques.

• Models help us visualize a system at different levels of abstraction,this makes it easier to manage complexity and to understand thesystem.

• We build models so that we can better understand the system we aredeveloping.

• A model is an abstraction, before building any system a prototype maybe developed.

• For example car, airplane, blueprints of machine parts, Plan for houseconstruction etc., Models serve many purposes

• Model consist of building abstraction of reality.

• Modeling achieves four aims. Modeling: –

1. Helps us to visualize a system as we want it to be.

2. Permits us to specify the structure or behavior of a system.

3. Gives us a template that guides us in constructing a system.

4. Documents the decisions we have made.

• We build models of complex systems because we cannot comprehend such a system in its entirety.

The Importance of Modeling

• A model is a simplification of reality.

• A model provides the blueprints of a system. Models may encompassdetailed plans, as well as more general plans that give a 30,000-foot view ofthe system under consideration.

• A good model includes those elements that have broad effect and omitsthose minor elements that are not relevant to the given level of abstraction.Every system may be described from different aspects using differentmodels, and each model is therefore a semantically closed abstraction ofthe system.

• A model may be structural, emphasizing the organization of the system, orit may be behavioral, emphasizing the dynamics of the system.

1. Models help us to visualize a system as it is or as we want it to be.

2. Models permit us to specify the structure or behavior of a system.

3. Models give us a template that guides us in constructing a system.

4. Models document the decisions we have made.

• We build models of complex systems because we cannot cover such a system in its entirety.

Principles of Modeling

1. The choice of what models to create has a profound influence on how aproblem is attacked and how a solution is shaped. Choose your modelswell.

2. Every model may be expressed at different levels of precision.

3. The best models are connected to reality.

4. No single model is sufficient. Every nontrivial system is best approachedthrough

5. A small set of nearly independent models.

1. The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. Choose your models

well.

2. Every model may be expressed at different levels of precision.

3. The best models are connected to reality.

4. No single model is sufficient. Every nontrivial system is best approached through

5. A small set of nearly independent models.

f. Object-Oriented Modeling

• In software, there are several ways to approach a model. The two mostcommon ways are from an algorithmic perspective and from anobject-oriented perspective.

• The traditional view of software development takes an algorithmicperspective. In this approach, the main building block of all software isthe procedure or function. This view leads developers to focus onissues of control and the decomposition of larger algorithms intosmaller ones

• The contemporary view of software development takes an object-orientedperspective.

• In this approach, the main building block of all software systems is theobject or class. Simply put, an object is a thing, generally drawn from thevocabulary of the problem space or the solution space;

• A class is a description of a set of common objects. Every object hasidentity (you can name it or otherwise distinguish it from other objects),state (there's generally some data associated with it), and behavior (youcan do things to the object, and it can do things to other objects, as well).

Architecture of UML (4+1 view)

• software-intensive system demands that the system be viewed from anumber of perspectives.

• Different stakeholders end users, analysts, developers, systemintegrators, testers, technical writers, and project managers eachbring different agendas to a project, and each looks at that system indifferent ways at different times over the project's life.

• A view model in system engg or s/w engg is framework

• A view is a representation of whole system for the perspective of arelated set of concern.

• Different stakeholders always have different interest in s/w system.

• View are used to describe the system from the viewpoint ofdifferent stakeholders, such as end user, developers & projectmanagers.

• System's architecture artifact that can be used to manage thesedifferent viewpoints and so control the iterative and incrementaldevelopment of a system throughout its life cycle.

• The architecture of a software-intensive system can best bedescribed by five interlocking views.

• Each view is a projection into the organization and structure of thesystem, focused on a particular aspect of that system.

• Use case view

- It encompasses the use cases that describe the behavior of the system asseen by its end users, analysts, and testers.

- Validation & illustration to show the design is complete.

- This view doesn't really specify the organization of a software system

- the static aspects of this view are captured in use case diagrams

- the dynamic aspects of this view are captured in interaction diagrams,state chart diagrams and activity diagrams.

• Design view

- It encompasses the classes, interfaces, and collaborations that formthe vocabulary of the problem and its solution.

- This view primarily supports the functional requirements of thesystem, meaning the services that the system should provide to itsend users.

- With the UML, the static aspects of this view are captured in classdiagrams and object diagrams

- the dynamic aspects of this view are captured in interactiondiagrams, state chart diagrams, and activity diagrams.

• Process view

- It shows the processes/workflows rules of a system & how thoseprocesses communication with each other.

- This view primarily addresses the performance, scalability, andthroughput of the system.

- With the UML, the static and dynamic aspects of this view are capturedin the same kinds of diagrams as for the design view.

- Active classes that represent these threads and processes.

• Implementation view

- It encompasses the components and files that are used to assembleand release the physical system.

- This view addresses the configuration management of the system'sreleases, made up of somewhat independent components and filesthat can be assembled in various ways to produce a running system.

- With the UML the static aspects of this view are captured incomponent diagrams

- the dynamic aspects of this view are captured in interactiondiagrams, state chart diagrams, and activity diagrams

• Deployment view

- It encompasses the nodes that form the system's hardware topologyon which the system executes.

- This view addresses the distribution, delivery, and installation of theparts that make up the physical system.

- the static aspects of this view are captured in deployment diagrams

- the dynamic aspects of this view are captured in interactiondiagrams, state chart diagrams, and activity diagrams.

RUP (Software Development Life Cycle)

• What is RUP ?

• A software development approach that is iterative, architecture-centricand use-case driven

• RUP is process independent meaning that it is not tied to any particularsoftware development life cycle.

1. Use case driven

2. Architecture-centric

3. Iterative and incremental

• Use case driven means that use cases are used as a primary artifact forestablishing the desired behavior of the system, for verifying andvalidating the system's architecture, for testing, and for communicatingamong the stakeholders of the project.

• Architecture-centric means that a system's architecture is used as aprimary artifact for conceptualizing, constructing, managing, andevolving the system under development.

• Iterative process is one that involves managing a stream of executablereleases , each new release is focused on attacking and reducing the mostsignificant risks to the success of the project.

• Iterative Development Phases:

Inception: Understand what to build• Vision, high-level requirements, business case• Not detailed requirements

Elaboration: Understand how to build it• Baseline architecture, most requirements• detailed• Not detailed design

Construction:• Build the product• Working product, system test complete

Transition:• Validate solution• Stakeholder acceptance

As An Effective Process, the RUP:

• Provides guidelines for efficient development of quality software

– Provides suggested flows of activities and assignment of roles to artifacts

• Reduces risk and increases predictability

– Through iteration planning, risks aggressively attacked up front

• Captures and presents best practices – very detailed.– Learn from other’s experiences– The RUP is huge! Configurable to the project;. – Contains disciplines – addressing all stakeholder concerns

• Provides roadmap for applying tools – it is NOT just a theory– Suggests activity sequences; – Adaptable for large and small projects.

• The RUP is a use-case driven, architecture-centric, iterative development process!

CONTENT

STRUCTURE

T I M E

Inception: Know What to Build

• Prepare vision document and initial business case

– Include risk assessment and resource estimate

• Develop high-level project requirements

– Initial use-case and domain models (10-20% complete)

• Manage project scope

– Reduce risk by identifying all key requirements

– Acknowledge that requirements will change

• Manage change, use iterative process

Elaboration: Know How to Build It

• Detail requirements as necessary (~80% complete)

– Less essential requirements may not be fleshed out

• Produce an executable and stable architecture

– Define, implement and test interfaces of major components

– Identify dependencies on external components and systems. Integrate shells/proxies of them.

– Some key components will be partially implemented

– Roughly 10% of code is implemented.

• Drive architecture with key use cases

– 20% of use cases drive 80% of the architecture

– Design, implement and test key scenarios for use cases

• Verify architectural qualities

– Reliability: Stress test

– Scalability and Performance: Load test

• Continuously assess business case, risk profile and development plan

Construction: Build The Product

• Complete requirements and design model

• Design, implement and test each component

– Prototype system and involve end users

– Incrementally evolve executable architecture tocomplete system

• Build daily or weekly with automated build process

• Test each build

– Automate regression testing

– Load and stress test to ensure architectural integrity

• Deliver fully functional software (beta release)

– Includes training material, user and deployment documentation

• Produce release descriptions

Transition: Deploy to End Users

• Produce incremental ‘bug-fix’ releases

• Update user manuals and deployment documentation

• Update release descriptions

• Execute cut-over

• Conduct “post-mortem” project analysis

Artifacts

1. Business model Establishes an abstraction of the organization

2. Domain model Establishes the context of the system

3. Use case model Establishes the system's functional requirements

4. Analysis model (optional) Establishes an idea design

5. Design model Establishes the vocabulary of the problem and its solution

6. Process model (optional) Establishes the system's concurrency andsynchronization mechanisms

7. Deployment model Establishes the hardware topology on which the systemis executed

8. Implementation model Establishes the parts used to assemble and releasethe physical system

9. Test model Establishes the paths by which the system is validated andverified

Other Artifacts

1. Requirements set describes what the system must do

2. Design set describes how the system is to be constructed

3. Implementation set describes the assembly of developed softwarecomponents

4. Deployment set provides all the data for the deliverableconfiguration

Process Workflows

The Rational Unified Process consists of nine process workflows.

1. Business modeling Describes the structure and dynamics of theorganization

2. Requirements Describes the use case based method for elicitingrequirements

3. Analysis and design Describes the multiple architectural views

4. Implementation Takes into account software development, unit test, andintegration

Process Workflows5. Test Describes test cases, procedures, and defect-tracking metrics

6. Deployment Covers the deliverable system configuration

7. Configuration management Controls changes to and maintains theintegrity of a project‘s artifacts

8. Project Management Describes various strategies of working with aniterative process

9. Environment Covers the necessary infrastructure required to develop asystem