Principles of Object-Oriented Software Development

1. Principles of Object-Oriented Software Development Software Engineering Perspectives

2. Software Engineering Perspectives Introduction Development methods Identifying objects Contracts Towards a formal approach Summary Q/A Literature

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

4. Development methods Subsections: Perspectives of modeling Requirements engineering -- Fusion Methods for analysis and design -- a comparative study

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

6. Unified Modeling Language • class diagrams, object interaction, packages, state and activity standard notation UML

7. Structured methods tools • structure chart • process specification • dataflow diagrams • hierarchy diagram • entity-relationship diagrams • data dictionary • state transition diagram

8. Perspectives of modeling

9. Modeling reality- vernacular • requirements -- use cases • analysis -- domain concepts • design -- system architecture • implementation – languagesupport Design model-- system oriented provides a justification of the architecture

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

11. Model criteria • unambiguous -- single meaning • abstract -- no unnecessary detail • consistent -- absence of conflict formal approach

12. Requirements engineering Fusion

13. Analysis Fusion • Object Model -- concepts and relations • LifeCycle Model -- sequences of operations • Operation Model -- semantics of system operations

14. Design data dictionary • Object Interaction Graph -- functional dependencies • Visibility Graphs -- communication structure • Class Descriptions -- attributes and methods • Inheritance Graphs -- subtype refinement

15. Implementation validation • System Lifecycle -- state machines • Class Descriptions -- coding, performance

16. Methods for analysis and design a comparative study

17. Objectory systematic process • requirements -- use cases, domain object model, user interface • analysis -- subsystems • design, implementation -- block model, interaction diagrams

18. OMT few rules for discovering inconsistencies • analysis -- object model, dynamic model, functional model • design, implementation -- heuristics to implement analysis models

19. Booch descriptive • diagrams -- class, object, timing, state, module, process

20. CRC • analysis, design -- class, responsibilities, collaborators exploratory

21. Formal methods • operations -- pre- and post-conditions

22. Comparison as a systematic approach Objectory OMT Booch CRC Fusion development + +- - x + maintenance + + + - + structure +- +- + + + management + +- +- - + tool support +- +- +- - +

23. Identifying objects Subsections: Modeling heuristics Assigning responsibilities Object roles

24. Object-Oriented Design -- decomposition into objects application/system/class oriented Identifying objects -- responsibilities data/procedure oriented Layers of abstraction components, subsystems, frameworks

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

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

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

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

29. Assigning responsibilities

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

31. Banking model ATM

32. Interaction classes ATM

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

34. analyze a little, design a little, implement a little, test a little...

35. Contracts Subsections: Specifying contractual obligations Refining a contract Runtime consistency checking

36. Contractual obligations client supplier pre-condition obligation benefit post-condition benefit obligation

37. Specifying contractual obligations

38. Assertions formal specification • require -- method call pre-condition • ensure, promise -- post-condition • invariant -- object invariance

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

40. 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!

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

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

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

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

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

46. Runtime consistency checking

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

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

49. Summary

50. 1 Development methods • Perspectives of modeling • Requirements engineering -- Fusion • Methods for analysis and design -- a comparative study