Anda di halaman 1dari 31

Object- Oriented Concepts and Principles

How People Understand Technology

What is OOP?
Object oriented program is a programming approach in which a problem domain is characterized as a set of objects that have a specific attributes and behavior. The objects are manipulated with a collection of functions called method or services. The objects are categorized into classes and subclasses

What is an Object?
An object has state, behavior, and identity; the structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable An object is defined via its class, which determines everything about an object. Objects are individual instances of a class

What is a Class?
A class is a specification of structure (instance variables), behavior (methods), and inheritance (parents, or recursive structure and behavior) for objects.

Objects in a class are said to be its instances

Features of OOP
Data Encapsulation Inheritance

Data Abstraction

Data Encapsulation
Encapsulation is the process of hiding all of the details of an object that do not contribute to its essential characteristics

Inheritance is the mechanism which allows a class A to inherit properties of a class B. We say ``A inherits from B''. Objects of class A thus have access to attributes and methods of class B without the need to redefine them

Polymorphism is a characteristic that greatly reduces the effort required to extend an existing
OO system

Data Abstraction
A class A is called abstract class if it is only used as a superclass for other classes. Class A only specifies properties. It is not used to create objects. Derived classes must define the properties of A

Commonly used OOP language

C++ Small Talk



Object Oriented Analysis

Object-oriented analysis (OOA) is concerned with developing software engineering requirements and specifications that expressed as a system's object model (which is composed of a population of interacting objects), as opposed to the traditional data or functional views of systems.

Conventional Vs OO Approaches
Modeling Dimensions that may be used to compare various conventional and ObjectOriented analysis methods: Identification/ Classification of entities
General to specific and whole to part entity relationships Other entity relationships Contd..

Description of attributes of entities

Large scale Model Partition States and transitions between states Detailed specification for functions Top down decomposition End to end processing sequences Identification of exclusive services Entity Communication

Widely used methods in OOA

The Booch Method The Rumbaugh Method

The Jacobson Method

The Coud and Yourdon Method

The wrifs-Brock method

Benefits of OOA
Maintainability: The ease with which a software system or component can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment

Reusability: The degree to which a software module or other work product can be used in more than one computing program or software system Productivity:The quality or state of being productive

Object Oriented Design

The goal of the design phase is to generate a description of how to synthesize software objects that behave in accord with analysis models and meet all other system requirements.

The layers of OO design

The Subsystem Layer
The Class and Object Layer The Message Layer The Responsibilities Layer

Conventional Vs OO Approaches
Fichman and Kemerer suggest ten design modeling components that may be used to compare various conventional and OO design methods
Representation of hierarchy of modules Specification of data definitions Specification of procedural logic Contd.

Indication of end to end processsing sequences

Definition of classes
Assignment of operations to classes

Specification of Message connection

Identication of Exclusive services

Representation of object states and transition

Widely used methods in OOD

The Booch Method
The Rumbaugh Method The Jacobson Method The Coud and Yourdon Method The wrifs-Brock method

Object Oriented Testing

The architecture of OO software results in a series of layered subsystems that encapsulated collaborating classes. It is necessary to test an OO system at different levels in an effort to uncover that may occur as classes collaborate with one another

The Impact on OO Programming on Testing

Some Types of faults become plausible Some Types of faults become more plausible

Some new types of faults appear

Perceptions About Testing Objects


Testing is unnecessary
Testing gets in the way

Human error is as likely as ever

Testing can be a complementary, integral part of development

Testing is structured/waterfall idea

Testing can be incremental and iterative Contd...

Perceptions About Testing Objects

MYTH Testing is trivial Automated GUI testing is sufficient REALITY

Hunches about testing completeness are notoriously optimistic

GUI-based tests may be little more than automated testing-bypoking-around Many bugs only surface during integration Contd...

If programmers were more careful, testing would be unnecessary

Perceptions About Testing Objects


Testing is inconsistent with a commitment to quality Testing is the same Conventional testing is useless for objects

Reliable software cannot be obtained without testing OO code structure matters

Conventional testing techniques can be adapted

Perceptions About Testing Objects

MYTH Black box testing is sufficient REALITY

OO structure matters

Test methods applicable in Class Level

Random testing for OO classes Partition Testing at the Class Level

Interclass test Case design

Multiple Class Testing Testing Derived from Behavior Models