principles of object oriented software development n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Principles of Object-Oriented Software Development PowerPoint Presentation
Download Presentation
Principles of Object-Oriented Software Development

Loading in 2 Seconds...

play fullscreen
1 / 55

Principles of Object-Oriented Software Development - PowerPoint PPT Presentation


  • 130 Views
  • Uploaded on

Principles of Object-Oriented Software Development. Software Engineering Perspectives. Software Engineering Perspectives. Introduction Development methods Identifying objects Contracts Towards a formal approach Summary Q/A Literature.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Principles of Object-Oriented Software Development' - gaston


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
principles of object oriented software development

Principles of Object-Oriented Software Development

Software Engineering Perspectives

software engineering perspectives
Software Engineering Perspectives

Introduction

Development methods

Identifying objects

Contracts

Towards a formal approach

Summary

Q/A

Literature

software engineering perspectives1
Software Engineering Perspectives
  • methods of development
  • the identification of objects
  • contracts -- refinement
  • validation -- a formal approach

Additional keywords and phrases: requirements, analysis,

implementation, design as transition, CRC cards,

responsibilities, heuristics, contractual obligations, validation

development methods
Development methods

Subsections:

Perspectives of modeling

Requirements engineering -- Fusion

Methods for analysis and design -- a comparative study

methods
Methods
  • OOA/D -- incremental [CY91b]
  • Objectory -- use-case analysis [Jacobs92]
  • OOSA -- model-driven [Kurtz90]
  • OOSD -- structured [Wasserman89]
  • CRC -- cards [BC89]
  • RDD -- responsibility-driven [Wirfs89]
  • OMT -- object modeling [Rum91]
  • OOD -- development [Booch91]
  • Fusion -- lifecycle [Fusion]
unified modeling language
Unified Modeling Language
  • class diagrams, object interaction, packages, state and activity

standard notation

UML

structured methods
Structured methods

tools

  • structure chart
  • process specification
  • dataflow diagrams
  • hierarchy diagram
  • entity-relationship diagrams
  • data dictionary
  • state transition diagram
modeling reality
Modeling reality

vernacular

  • requirements -- use cases
  • analysis -- domain concepts
  • design -- system architecture
  • implementation -- language
  • support

Design model -- system oriented

provides a justification of the architecture

dimensions of modeling
Dimensions of modeling

OMT

  • object model -- decomposition into objects
  • dynamic model -- intra-object state changes
  • functional model -- object interaction (data-flow)

Model of control

procedure-driven, event-driven, concurrent

model criteria
Model criteria
  • unambiguous -- single meaning
  • abstract -- no unnecessary detail
  • consistent -- absence of conflict

formal approach

analysis
Analysis

Fusion

  • Object Model -- concepts and relations
  • LifeCycle Model -- sequences of operations
  • Operation Model -- semantics of system operations
design
Design

data dictionary

  • Object Interaction Graph -- functional dependencies
  • Visibility Graphs -- communication structure
  • Class Descriptions -- attributes and methods
  • Inheritance Graphs -- subtype refinement
implementation
Implementation

validation

  • System Lifecycle -- state machines
  • Class Descriptions -- coding, performance
objectory
Objectory

systematic process

  • requirements -- use cases, domain object model, user interface
  • analysis -- subsystems
  • design, implementation -- block model, interaction diagrams
slide18
OMT

few rules for discovering inconsistencies

  • analysis -- object model, dynamic model, functional model
  • design, implementation -- heuristics to implement analysis models
booch
Booch

descriptive

  • diagrams -- class, object, timing, state, module, process
slide20
CRC
  • analysis, design -- class, responsibilities, collaborators

exploratory

formal methods
Formal methods
  • operations -- pre- and post-conditions
comparison
Comparison

as a systematic approach

Objectory OMT Booch CRC Fusion

development + +- - x +

maintenance + + + - +

structure +- +- + + +

management + +- +- - +

tool support +- +- +- - +

identifying objects
Identifying objects

Subsections:

Modeling heuristics

Assigning responsibilities

Object roles

slide24

Object-Oriented Design -- decomposition into objects

application/system/class oriented

Identifying objects -- responsibilities

data/procedure oriented

Layers of abstraction

components, subsystems, frameworks

modeling heuristics
Modeling heuristics

Objects -- crisp entities

object = an entity that suffers and requires actions

The method:

[1] Identify the objects and their attributes

[2] Identify operations suffered and required

[3,4] Establish visibility/interface

slide26

Heuristics

model of reality -- balance nouns (objects) and verbs (operations)

Associations

directed action -- drives, instructs

communication -- talks-to, tells, instructs

ownership -- has, part-of

resemblance -- like, is-a

others -- works-for, married-to

candidate classes
Candidate classes

ATM

  • account -- customer's account in the banks database
  • atm -- performs financial services for a customer
  • cardreader -- reads and validates a customer's card
  • cashdispenser -- gives cash to the customer
  • screen -- presents text and visual information
  • keypad -- the keys a customer can press
  • pin -- the authorization code
  • transaction -- performs financial services and updates the database
eliminating spurious classes
Eliminating spurious classes
  • vague -- system, security-provision, record-keeping
  • attribute -- account-data, receipt, cash
  • redundant -- user
  • irrelevant -- cost
  • implementation -- transaction-log, communication

Good classes

our candidate classes

object oriented thinking
Object-Oriented Thinking

CRC

  • Immerse the reader in the object-ness of the material
  • Give up global knowledge of control.
  • Rely on the local knowledge of objects.

OO-Design with CRC cards

Class, Responsibility, Collaborators.

object roles and interaction
Object roles and interaction
  • actor -- operates (suffers no operations)
  • server -- suffers operations
  • agent -- suffers and operates ( actor & server)
slide34

analyze a little,

design a little,

implement a little,

test a little...

contracts
Contracts

Subsections:

Specifying contractual obligations

Refining a contract

Runtime consistency checking

contractual obligations
Contractual obligations

client supplier

pre-condition obligation benefit

post-condition benefit obligation

assertions
Assertions

formal specification

  • require -- method call pre-condition
  • ensure, promise -- post-condition
  • invariant -- object invariance
slide39

class account { account

public:

account();

// assert( invariant() );

virtual float balance() { return _balance; }

void deposit(float x); to deposit money

// require( x >= 0 );

// promise( balance() == old_balance + x && invariant() );

void withdraw(float x); to withdraw money

// require( x <= balance() );

// promise( balance() == old_balance - x && invariant() );

bool invariant() { return balance() >= 0; }

protected:

float _balance;

};

system development
System development
  • violated pre-condition -- bug in client
  • violated post-condition -- bug in supplier

A pre-condition limits the cases that

a supplier must handle!

slide41

class account { account

public:

account() { _balance = 0; assert(invariant()); }

virtual float balance() { return _balance; }

void deposit(float x) {

require( x >= 0 ); check precondition

hold(); to save the old state

_balance += x;

promise( balance() == old_balance + x );

promise( invariant() );

}

slide42

void withdraw(float x) {

require( x <= _balance ); check precondition

hold(); to save the old state

_balance -= x;

promise( balance() == old_balance - x );

promise( invariant() );

}

virtual bool invariant() { return balance() >= 0; }

protected:

float _balance;

float old_balance; additional variable

virtual void hold() { old_balance = _balance; }

};

refining a contract
Refining a contract

State responsibilities and obligations

  • invariance -- respect the invariants of the base class
  • methods -- services may be added or refined

Refining a method -- like improving a business contract

class C : public P {

virtual void m();

}

pre( m_C ) >= pre(m_P) weaken pre-condition

post( m_C ) <= post(m_P) strengthen post-condition

slide44

class credit_account : public account { credit_account

public:

credit_account(float x) { _maxcredit = x; _credit = 0; }

float balance() { return _balance + _credit; }

float credit(float x) {

require( x + _credit <= _maxcredit );

hold();

_credit += x;

promise( _credit = old_credit + x );

promise( _balance = old_balance);

promise( invariant() );

}

slide45

void reduce(float x) {

require( 0 <= x && x <= _credit );

hold();

_credit -= x;

promise( _credit = old_credit - x );

promise( _balance = old_balance );

promise( invariant() );

}

bool invariant() {

return _credit <= _maxcredit && account::invariant();

}

protected:

float _maxcredit, _credit;

float old_credit;

void hold() { old_credit = _credit; account::hold(); }

};

slide47

Assertions -- side-effect free contracts

require -- test on delivery

promise -- test during development

Object invariance -- exceptions

invariant -- verify when needed

Global properties -- requirements

interaction protocols -- formal specification

slide48

Formal specification -- contracts

type specification -- local properties

relational specification -- structural properties, type relations

functional specification -- requirements

Verification -- as a design methodology

reasoning about program specification/code

Runtime consistency -- invariance

behavioral types specify test cases

invariants and assertions monitor consistency

development methods1

1

Development methods
  • Perspectives of modeling
  • Requirements engineering -- Fusion
  • Methods for analysis and design -- a comparative study
identifying objects1

2

Identifying objects
  • object-oriented design -- decomposition into objects
  • object model -- objects suffer and require
  • heuristics -- balance between nouns and verbs
  • evaluation -- eliminating spurious classes
  • class design -- class, responsibilities and collaborations
contracts1

3

Contracts
  • types -- as an organizing principle
  • contracts -- obligations and benefits
  • subtyping -- the substitutability requirement
  • partial types -- designed to have subtypes
towards a formal approach

4

Towards a formal approach
  • contracts -- formal specification
  • verification -- as a design methodology
  • runtime consistency -- invariance
questions

1.Describe the Fusion method. How does Fusion compare with other methods of OO analysis and design?

2. How would you characterize the differences between functional and object-oriented development methods?

3. Give an outline of the steps required in object-oriented design. What heuristics can you think of for identifying objects?

4. What criteria may be used to eliminate spurious classes from an initial object model?

5. Explain the methods of CRC cards. Give an example.

6. Explain how you may characterize the behavior of an object by means of a contract.

7. What benefits may design by contract have for system developers? And for users?

8. Give a detailed account of the issues that arise in refining a contract.

9. How may contracts be employed to test object behavior.

10. Discuss how a formal approach may contribute to OO software development.

Questions
further reading
Further reading

[Fowler97] is not only a good introduction to UML, but contains also many useful insights on the process of object-oriented development. Additionally, [Fowler97a] may be read as a source on analysis patterns, which are reusable elements of analysis and design. For more information on Fusion, consult [Fusion]. As earlier references on object-oriented methods, I recommend [Booch94], [WWW90] and [Rum91]. Also worthwhile are [Henderson93] and [Champeaux93]. An overview and comparative study of design representation methods is given in [Webster]. [Meyer97] is the ultimate reference on contracts. A more comprehensive article on design by contract is [Meyer92].