View
231
Download
4
Tags:
Embed Size (px)
Citation preview
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
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
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
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
Comparison as a systematic approach
Objectory OMT Booch CRC Fusion development + +- - x + maintenance + + + - + structure +- +- + + + management + +- +- - + tool support +- +- +- - +
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
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.
Object roles and interaction
• actor -- operates (suffers no operations)
• server -- suffers operations
• agent -- suffers and operates ( actor & server)
Contracts
Subsections:
Specifying contractual obligations Refining a contract Runtime consistency checking
Contractual obligations
client supplier pre-condition obligation benefit post-condition benefit obligation
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(); } };
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
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].