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

2. 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 structure chart process specification dataflow diagrams hierarchy diagram entity-relationship diagrams data dictionary state transition diagram tools

8. Perspectives of modeling

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

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

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

12. Requirements engineering Fusion

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

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

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

16. Methods for analysis and design a comparative study

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

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

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

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

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

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 require -- method call pre-condition ensure, promise -- post-condition invariant -- object invariance formal specification

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 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-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. Development methods Perspectives of modeling Requirements engineering -- Fusion Methods for analysis and design -- a comparative study 1

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

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

53. Towards a formal approach contracts -- formal specification verification -- as a design methodology runtime consistency -- invariance 4

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

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