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
standard notation
• class diagrams, object interaction,
packages, state and activity
UML
Structured methods
tools
•
•
•
•
•
•
•
structure chart
process specification
dataflow diagrams
hierarchy diagram
entity-relationship diagrams
data dictionary
state transition diagram
Perspectives of modeling
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
OMT
• object model -- decomposition into objects
• dynamic model -- intra-object state changes
• functional model -- object interaction (dataflow)
Model of control
procedure-driven, event-driven, concurrent
Model criteria
formal approach
• unambiguous -- single meaning
• abstract -- no unnecessary detail
• consistent -- absence of conflict
Requirements engineering
Fusion
Analysis
Fusion
• Object Model -- concepts and relations
• LifeCycle Model -- sequences of operations
• Operation Model -- semantics of system operations
Design
data dictionary
• Object Interaction Graph -- functional
dependencies
• Visibility Graphs -- communication structure
• Class Descriptions -- attributes and methods
• Inheritance Graphs -- subtype refinement
Implementation
validation
• System Lifecycle -- state machines
• Class Descriptions -- coding, performance
Methods for analysis and design
a comparative study
Objectory
systematic process
• requirements -- use cases, domain object
model, user interface
• analysis -- subsystems
• design, implementation -- block model,
interaction diagrams
OMT
few rules for discovering inconsistencies
• analysis -- object model, dynamic model,
functional model
• design, implementation -- heuristics to
implement analysis models
Booch
descriptive
• diagrams -- class, object, timing, state,
module, process
CRC
exploratory
• analysis, design -- class, responsibilities,
collaborators
Formal methods
• operations -- pre- and post-conditions
Comparison
as a systematic approach
development
maintenance
structure
management
tool support
Objectory
OMT
+
+
++
+-
++
+++-
Booch
CRC
+
+
++-
x
+
-
Fusion
+
+
+
+
+
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
•
•
•
•
•
•
•
•
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
•
•
•
•
•
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
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.
Banking model
ATM
Interaction classes
ATM
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
pre-condition
post-condition
client
supplier
obligation
benefit
benefit
obligation
Specifying contractual obligations
Assertions
formal specification
• require -- method call pre-condition
• ensure, promise -- post-condition
• invariant -- object invariance
class account {
public:
account();
// assert( invariant() );
account
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 that
a supplier must handle!
class account {
public:
account() { _balance = 0; assert(invariant()); }
virtual float balance() { return _balance; }
account
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 );
hold();
_balance -= x;
promise( balance() == old_balance - x );
promise( invariant() );
}
check precondition
to save the old state
virtual bool invariant() { return balance() >= 0; }
protected:
float _balance;
float old_balance;
additional variable
virtual void hold() { old_balance = _balance; }
};
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)
post( m_C ) <= post(m_P)
weaken pre-condition
strengthen post-condition
class credit_account : public 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() );
}
credit_account
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
1
Development methods
• Perspectives of modeling
• Requirements engineering -- Fusion
• Methods for analysis and design -- a
comparative study
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
3
Contracts
•
•
•
•
types -- as an organizing principle
contracts -- obligations and benefits
subtyping -- the substitutability requirement
partial types -- designed to have subtypes
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.
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].