<s5>Æliens</s5> -- slide(s)

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

slide: Software engineering perspectives

subsections:

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

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

UML

class diagrams, object interaction, packages, state and activity

slide: Software development methods

Structured methods

tools

structure chart
process specification
dataflow diagrams
hierarchy diagram
entity-relationship diagrams
data dictionary
state transition diagram

slide: Tools for a structured approach

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

slide: Perspectives 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

slide: The OMT method

Model criteria -- formal approach

unambiguous -- single meaning
abstract -- no unnecessary detail
consistent -- absence of conflict

slide: Coherent models -- criteria

Analysis -- Fusion

Fusion

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

Design -- data dictionary

data dictionary

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

Implementation -- validation

validation

System Lifecycle -- state machines
Class Descriptions -- coding, performance

slide: The Fusion method

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

slide: Comparison of methods (1)

Booch

class diagram/template
object diagram/template -- dynamics
module diagram/template
process diagram/template -- physical design
state transition diagram
timing diagram

slide: Diagrams for design

Object-oriented design -- decomposition into objects

application/system/class oriented

Identifying objects -- responsibilities

data/procedure oriented

Layers of abstraction

components, subsystems, frameworks

slide: Object-oriented design

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

slide: The Booch method

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

slide: Heuristics for modeling

Candidate classes

ATM

account -- represents the customer's account in the banks database
atm -- performs financial services for a customer
cardreader -- reads and validates a customer's bankcard
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

slide: The ATM example (1)

Eliminating spurious classes

vague -- system, security-provision, record-keeping
attribute -- account-data, receipt, cash
redundant -- user
irrelevant -- cost
implementation -- transaction-log, access, communication

Good classes

our candidate classes

slide: Eliminating spurious classes

Object-oriented thinking

CRC

Immerse the reader in the {\em 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

slide: The CRC method

Object roles

actor -- operates (suffers no operations)
server -- suffers operations
agent -- suffers and operates ( actor & server)

slide: Object roles

analyze a little,
design a little,
implement a little,

test a little ...

slide: The Model-View-Controller paradigm

subsections:

Specifying contractual obligations
Refining a contract
Runtime consistency checking

Assertions -- formal specification

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

slide: Formal specification of contracts

computation is sending messages
if B is a subtype of A then B may be used wherever A is used
code sharing (storage representation + operations)

slide: The substitutability requirement


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

slide: The $account$ contract

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!

slide: System development with contracts


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

slide: The realization of the $account$ 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$ )

post( $m_C$ ) $<=$ post( $m_P$ )

slide: Contracts and inheritance


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

slide: Refining the account contract

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

slide: Runtime consistency checking

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

slide: Formal specification and verification

Development methods

perspectives of modeling
requirements engineering -- Fusion
methods for analysis and design -- a comparative study

slide: Section 3.1: Development methods

Identifying objects

{\em 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

slide: Section 3.2: Identifying objects

Contracts

types -- as an organizing principle
contracts -- obligations and benefits
subtyping -- the substitutability requirement
partial types -- designed to have subtypes

slide: Section 3.3: Contracts

Towards a formal approach

contracts -- formal specification
verification -- as a design methodology
runtime consistency -- invariance

slide: Section 3.4: Towards a formal approach

Describe the Fusion method. How does Fusion compare with other methods of OO analysis and design?
Give an outline of the steps required in object-oriented design. What heuristics can you think of for identifying objects?
What criteria may be used to eliminate spurious classes from an initial object model?
Explain the methods of CRC cards. Give an example.
Explain how you may characterize the behavior of an object by means of a contract.
What benefits may design by contract have for system developers? And for users?
Give a detailed account of the issues that arise in refining a contract.
How may contracts be employed to test object behavior?
Discuss how a formal approach may contribute to OO software development.

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

Æliens

2009

Software engineering perspectives

subsections:

Unified Modeling Language -- standard notation

Structured methods

Modeling reality -- vernacular

Design model -- system oriented

Dimensions of modeling -- OMT

Model of control

Model criteria -- formal approach

Analysis -- Fusion

Design -- data dictionary

Implementation -- validation

Objectory -- systematic process

OMT -- few rules for discovering inconsistencies

Booch -- descriptive

CRC -- exploratory

Formal methods

subsections:

Object-oriented design -- decomposition into objects

Identifying objects -- responsibilities

Layers of abstraction

Objects -- crisp entities

The method:

Heuristics

Associations

Candidate classes

Eliminating spurious classes

Good classes

Object-oriented thinking

OO design with CRC cards

Object roles

subsections:

Assertions -- formal specification

account

to deposit money

to withdraw money

System development

account

Refining a contract -- state responsibilities and obligations

Refining a method -- like improving a business contract

credit_account

Assertions -- side-effect free

Object invariance -- exceptions

Global properties -- requirements

Formal specification -- contracts

Verification -- as a design methodology

Runtime consistency -- invariance

Development methods

Identifying objects

Contracts

Towards a formal approach