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

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

Subsections:

Perspectives of modeling Requirements engineering -- Fusion Methods for analysis and design -- a comparative study

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

• class diagrams, object interaction, packages, state and activity

standard notation

UML

Structured methods

• structure chart

• process specification

• dataflow diagrams

• hierarchy diagram

• entity-relationship diagrams

• data dictionary

• state transition diagram

tools

Perspectives of modeling

Modeling reality

• requirements -- use cases

• analysis -- domain concepts

• design -- system architecture

• implementation -- language

• support

vernacular

Design model -- system oriented

provides a justification of the architecture

Dimensions of modeling

• object model -- decomposition into objects

• dynamic model -- intra-object state changes

• functional model -- object interaction (data-flow)

OMT

Model of control

procedure-driven, event-driven, concurrent

Model criteria

• unambiguous -- single meaning

• abstract -- no unnecessary detail

• consistent -- absence of conflict

formal approach

Requirements engineering

Fusion

Analysis

• Object Model -- concepts and relations

• LifeCycle Model -- sequences of operations

• Operation Model -- semantics of system operations

Fusion

Design

• Object Interaction Graph -- functional dependencies

• Visibility Graphs -- communication structure

• Class Descriptions -- attributes and methods

• Inheritance Graphs -- subtype refinement

data dictionary

Implementation

• System Lifecycle -- state machines

• Class Descriptions -- coding, performance

validation

Methods for analysis and design

a comparative study

Objectory

• requirements -- use cases, domain object model, user interface

• analysis -- subsystems

• design, implementation -- block model, interaction diagrams

systematic process

OMT

• analysis -- object model, dynamic model, functional model

• design, implementation -- heuristics to implement analysis models

few rules for discovering inconsistencies

Booch

• diagrams -- class, object, timing, state, module, process

descriptive

CRC

• analysis, design -- class, responsibilities, collaborators

exploratory

Formal methods

• operations -- pre- and post-conditions

Comparison as a systematic approach

Objectory OMT Booch CRC Fusion development + +- - x + maintenance + + + - + structure +- +- + + + management + +- +- - + tool support +- +- +- - +

Identifying objects

Subsections:

Modeling heuristics Assigning responsibilities Object roles

Object-Oriented Design -- decomposition into objects

application/system/class oriented

Identifying objects -- responsibilities

data/procedure oriented

Layers of abstraction

components, subsystems, frameworks

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

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

• 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

ATM

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

Assigning responsibilities

Object-Oriented Thinking

• Immerse the reader in the object-ness of the material

• Give up global knowledge of control.

• Rely on the local knowledge of objects.

CRC

OO-Design with CRC cards

Class, Responsibility, Collaborators.

Banking modelATM

Interaction classesATM

Object roles and interaction

• actor -- operates (suffers no operations)

• server -- suffers operations

• agent -- suffers and operates ( actor & server)

analyze a little,

design a little,

implement a little,

test a little...

Contracts

Subsections:

Specifying contractual obligations Refining a contract Runtime consistency checking

Contractual obligations

client supplier pre-condition obligation benefit post-condition benefit obligation

Specifying contractual obligations

Assertions

• require -- method call pre-condition

• ensure, promise -- post-condition

• invariant -- object invariance

formal specification

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

• violated pre-condition -- bug in client

• violated post-condition -- bug in supplier

A pre-condition limits the cases thata supplier must handle!

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() ); }

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

• invariance -- respect the invariants of the base class

• methods -- services may be added or refined

State responsibilities and obligations

Refining a method -- like improving a business contract

class C : public P { virtual void m(); }

pre( m_C ) >= pre(m_P) weaken pre-conditionpost( m_C ) <= post(m_P) strengthen post-condition

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() ); }

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(); } };

Runtime consistency checking

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

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

Summary

Development methods

• Perspectives of modeling

• Requirements engineering -- Fusion

• Methods for analysis and design -- a comparative study

1

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

2

Contracts

• types -- as an organizing principle

• contracts -- obligations and benefits

• subtyping -- the substitutability requirement

• partial types -- designed to have subtypes

3

Towards a formal approach

• contracts -- formal specification

• verification -- as a design methodology

• runtime consistency -- invariance

4

Questions1.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.

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].