1. November 27, 2001Domain Modeling1 Domain Modeling Chapters 10-12 Use-Case Modeling Chapters 9 and 13 Filling in some gaps about: Levels of abstraction Contrast to functional decomposition Pre and Post Conditions Invariants & Input-Output Assertions

2. November 27, 2001Domain Modeling2 Levels of abstraction Use-Case describes –How external actors interact with the sw system we want to create Isolate and illustrate operations that an external actor requests of a system Describes system behavior in context System Sequence Diagram –The system events that actors generate & their order –The system as a black box –Inter-system events –Emphasis: Events that cross the system boundary from actors to systems (may include parameters)

3. November 27, 2001Domain Modeling3 Lower level of abstraction At a more detailed level with a narrower scope, a use case is much like the older concept of pseudo- code Sequence diagrams (not at system level) show how internal components interact with each other

4. November 27, 2001Domain Modeling4 SSD Guideline summary Events expressed at level of intent (not physical input medium, not name of widget) Name of event is a verb (actors ACT) Noncommittal w.r.t. design choices Can have Use Case fragments on left margin to help explain Events can have parameters Shows data flow from external actors to public operations

5. November 27, 2001Domain Modeling5 Contrast to Data-Flow Diagram External actors are seen as data sources Parameters passed in to public operations are data on labeled arcs Public operations are actions that receive or produce external data –In SSDs, produced data are not shown unless delivered to external actor –Context diagram is a highest-level DFD (one bubble) Shows data coming in or being produced but does not distinguish which system events are associated with which data

6. November 27, 2001Domain Modeling6 SSD and Context DFD ;System ;Cashier makeNewSale() enterItem(ItemID, quantity) description, total endSale() total with taxes makePayment (amount) change due, receipt System Cashier Item ID, quantity description, total total with taxes amount

7. November 27, 2001Domain Modeling7 Cashier Item ID, quantity description, total change due, receipt amount enterItem makePayment Cashier Need a convention to show makeNewSale or endSale because no data flows from Cashier to action even though they are “event indicators”.

8. November 27, 2001Domain Modeling8 select action makeNewSale enterItem makePayment endSale Cashier ItemID, quantity description, total total with taxes amount change due, receipt Cashier action indicator format result Cashier Classic Transactional DFD

9. November 27, 2001Domain Modeling9 Example UML Context Diagrams

10. November 27, 2001Domain Modeling10 Another UML context diagram

11. November 27, 2001Domain Modeling11 One more UML context diagram

12. November 27, 2001Domain Modeling12 Domain Model Illustrate meaningful conceptual classes in a real- world problem domain –Identify conceptual classes or domain objects –Show associations between them –Indicate their attributes when appropriate Purposely incomplete; possibly a superset Visual dictionary –relevant vocabulary of the domain –important abstractions –information content

13. November 27, 2001Domain Modeling13 Sample Domain Model

14. November 27, 2001Domain Modeling14 another example

15. November 27, 2001Domain Modeling15 yet another example

16. November 27, 2001Domain Modeling16 Decomposition Axis In structured analysis –decompose by functions (bubbles in dfd, boxes in structure chart) –examples: dfd, Constantine structure chart, see handout from Fairley In object-oriented analysis –decompose by things, entities in the domain –primary task: identify different concepts in the domain and document them in the model –restricted to current scenarios (use-cases) under consideration

17. November 27, 2001Domain Modeling17 What to include? Regardless of the type of model, it’s a MODEL (see front cover of book – This is not a sailboat) Mapmaker analogy –Use local names, those of the domain –Omit what is irrelevant to the purpose Mapmaker doesn’t try to show details about cities, airports, terrain, rainfall, population density, agricultural crops, types of industry, etc., ALL on one map! Less is more. –Omit what is truly not there

18. November 27, 2001Domain Modeling18 Note the helpful discussions about finer points: Attributes are rare – more often, they should be separate concepts Report objects – derived information (omit), business rules role (include) Resolving similar conceptual classes Modeling the UNreal world – modeling requires high degree of abstraction Specification or description conceptual classes Descriptions of services necessary prior to sale of services

19. November 27, 2001Domain Modeling19 Advantages of a Domain Model Because the domain model uses real world vocabulary and models real-world relationships, –Reduces the representational gap between analysis and design – practical advantage “...can support the design of elegant, loosely-coupled systems that scale and extend easily” –Many of the suggestions given in the “helpful discussions” maintain the loose coupling

20. November 27, 2001Domain Modeling20 Loose coupling?? Content – A modifies local data values (or instructions!) in B Common – Modules bound together by global data structures Control – passing control flags between modules so that one controls the sequence of processing steps in another Stamp -- Global data shared selectively among routines that require it Data – use of parameter lists to pass data items between routines

21. November 27, 2001Domain Modeling21 p.s. They also support high cohesion The two strongest types of unit cohesion are –Functional cohesion –Informational cohesion Functional cohesion –All elements are related to the performance of a single function Informational cohesion –Unit contains a complex data structure and the routines to manipulate it –the concrete realization of data abstraction

22. November 27, 2001Domain Modeling22 A Good Model Somewhere between a minimal need-to- know model and one that illustrates every conceivable relationship Does it satisfy all the need-to-know requirements? Does it communicate an essential understanding of the important concepts in the problem domain?

23. November 27, 2001Domain Modeling23 Importance of domain expertise Adequate requirements Inadequate requirements Low domain expertise High domain expertise

24. November 27, 2001Domain Modeling24 Operation Contracts Help define system behavior Describe outcome of executing system operation in terms of state changes to domain objects Emphasis on result(s) of operation Considered a formal approach when used rigorously

25. November 27, 2001Domain Modeling25 Pre and Post Conditions Premise: “Once we have defined the correctness of a software element as the consistency of its implementation with its specification, we should take steps to include the specification, together with the implementation, in the software itself. For most of the software community, this is still a novel idea...” -- Bertrand Meyer

26. November 27, 2001Domain Modeling26 Assertions Express the “what” in the code, that is, the software’s purpose States a property certain entities may satisfy at certain stages of software execution –e.g. X > 0 ; Ptr is not void. History lies in the mathematics of predicate calculus – not as powerful as that Often boolean expressions

27. November 27, 2001Domain Modeling27 Used in Semantic Specification Specify what is the useful task performed by the operation Two assertions –Precondition – states the properties that MUST hold whenever the routine is called –Postcondition – states the properties the routine GUARANTEES when it returns Often involves making the implicit explicit For example, in a stack class, put must not be applied to a full stack. When applied, it increases the number of elements by one.

28. November 27, 2001Domain Modeling28 Preconditions of a routine Applies to ALL calls of the routine –from within the class –from clients Correct system will never execute a call in a state that does not satisfy the precondition of the called routine –burden is on the caller to be certain the required state is true; easier to do if stated explicitly in the called routine –the abstract data type including the routine in question must provide the means to verify the precondition; e.g. stack class containing put must also include NotFull

29. November 27, 2001Domain Modeling29 Postconditions of a routine Properties of the state resulting from the routine’s execution –After put, stack is not empty, top is the element just pushed, number of elements has increased by one Expresses a guarantee that the routine will yield a state satisfying certain properties... assuming the precondition was satisfied prior to the execution

30. November 27, 2001Domain Modeling30 Present StateInput or EventActionOutputNext State ST1. Idlecard insertedrequest for PINWaiting for PIN ST2. Waiting for PINPIN entereddisplay asterisksValidating PIN ST3. Waiting for PINcanceldisplay msgEjecting ST4. Validating PINindicates “valid”display choicesWaiting for customer transaction choice ST5. Validating PINindicates “stolen”display “stolen” confiscating ST6. Validating PINindicates “invalid”display “invalid” Waiting for PIN ST7. Waiting for customer transaction choice Canceldisplay “cancel” Ejecting ST8. Waiting for customer transaction choice Balance Query selectedProcessing query continued on next slide

31. November 27, 2001Domain Modeling31 ST9. Waiting for customer transaction choice Withdrawal selectedProcessing w/d ST10. confiscatingCard confiscatedterminating ST11. Processing queryRejected for this userdisplay “rejected” Ejecting ST12. Processing queryQuery OKdisplay printing printing ST13. Processing withdrawal ok amountdisplay ok msgdispensing ST14. Processing withdrawal not ok amountdisplay refusalEjecting ST15. Printingtransaction completeprint receiptejecting ST16. Dispensingsufficient cash in ATMcashprinting ST17. Dispensinginsufficient cash in ATMdisp “insufficient cash” ejecting ST18. Ejectingcard ejection starteddisplay msg to take cardterminating ST19. terminatingcard ejection completedisplay ending msg idle

32. November 27, 2001Domain Modeling32 State Transition Diagram - incomplete Idle card inserted/ waiting for PIN PIN inserted/ validating PIN ejecting “cancel” “invalid” “stolen” confis- cating “valid” waiting for cust xaction “cancel” terminat- ing card ej complete card confis’d

33. November 27, 2001Domain Modeling33 What if assertions fail? If assertions are treated as comments, a run- time assertion violation will remain undetected If assertions are used to check that all is well, then during execution –the software monitors that assertions hold when they should –if one does not, it triggers an exception what happens THEN depends on the exception handling design and code

34. November 27, 2001Domain Modeling34 Primary emphasis re assertions Primary emphasis is on using assertions as a conceptual tool for analysis, design, implementation, and documentation... to build software in which reliability is built- in, rather than achieved after the fact through debugging.

35. November 27, 2001Domain Modeling35 Rights and Obligations By associating pre and postconditions with an operation, you tell its clients: If you promise to call r with the precondition satisfied then I, in return, promise to deliver a final state in which the postcondition is satisfied. Clarifies the terms of the relationship Contract between the operation (the supplier of a certain service) and its callers (the clients of that service)

36. November 27, 2001Domain Modeling36 What about contracts on public operations? We are focusing this week on the domain model and its public (system) operations – those triggered by external actors. But I said the burden of meeting the precondition is on the caller – the caller of a public operation may be a human. What do you think about preconditions of public operations?

37. November 27, 2001Domain Modeling37 Preconditions on User Input? A precondition can’t correct user input and the user wouldn’t know about a precondition A precondition on a public operation is not a reliability technique, it’s wishful thinking. The operation must check for the conditions that must be true and handle the situation appropriately if they do not hold. Validate items obtained from the outside world close to the source using “filters”.

38. November 27, 2001Domain Modeling38 Filter modules External items Filters – input & output validation modules (only pass along when preconditions are met. Processing modules (have preconditions) System

39. November 27, 2001Domain Modeling39 Zen and the art of software reliability Guarantee more by checking less The precondition is a benefit for the supplier. –If the client’s part of the contract is not fulfilled, the operation is not bound by the postcondition and can do what it pleases. Simplifies programming style – when writing the body of the operation, you may assume the precondition is satisfied

40. November 27, 2001Domain Modeling40 Strong defense or Negotiated Peace Defensive programming –“One is never too careful dealing with strangers.” –“Checking that the precondition holds is redundant if the caller checked but... while a redundant check might not help, at least it will not hurt.” Design by Contract –Redundant checks can and indeed will hurt. –In a macroscopic view if entire architecture, simplicity becomes a crucial criterion. –Redundancy leads to performance penalty –To get more reliability, check less... explicitly

41. November 27, 2001Domain Modeling41 Simplicity Complexity is the enemy of quality Redundant checks add to complexity Contract –identifies the consistency conditions necessary to proper functioning of each client-supplier cooperation –specifies whose responsibility it is to enforce them, the client’s responsibility (preconditions) or the supplier’s (postconditions) If not in the precondition, the operation is obligated to check for it.

42. November 27, 2001Domain Modeling42 Difference from Hardware Redundant checking is standard in hardware Why? A correct state may later have its integrity destroyed beyond the control of the system itself – wear and tear, interference, baseball bat, etc. Therefore: it’s normal for a sender and receiver, for example, to check the integrity of a signal. Software doesn’t wear out. If you do have an analogous situation, then redundant checks make sense.

43. November 27, 2001Domain Modeling43 Assertions are not Control Structures Assertions are not techniques to handle special cases by switching to the exception handler for the “else-part”. Special cases should be handled directly in the code as if... then... else or similar conditional constructs. Assertions express correctness conditions. –A call to put on a full stack is not a special case; the call is a bug. –A run-time assertion violation indicates a bug in the software, either in the client (precondition violation) or in the supplier (postcondition violation).

44. November 27, 2001Domain Modeling44 Reviews and Testing In early stages, make certain the pre and postconditions are the right ones to have! Preconditions –Something to check for explicitly in reviews Does every call ensure the precondition prior to the call? –If possible, set up precondition violation Postconditions –Formal methods – given the precondition and the code, prove the postcondition is true. –Informal approach – convince the reviewers –System test: test for postconditions of public operations

45. November 27, 2001Domain Modeling45 Sound familiar? The demanding approach to precondition design –does not attempt to be all things to all clients –insists each routine do a well-defined job and do it well –specify clearly what cases it cannot handle –leads to more likely re-usable –is applicable if the preconditions remain reasonable

46. November 27, 2001Domain Modeling46 Reasonable Preconditions Appears in the supplier module’s documentation so the client authors can know. It is possible to justify the need for the precondition in terms of the specification alone. –“Stack is not empty” is reasonable for pop because there is nothing to pop –RealSqrt(X) with precondition X >= 0 is reasonable because negative real numbers do not have real square roots

47. November 27, 2001Domain Modeling47 Reasonable by reason of implementation... Consider “Stack not full” as precondition for put If the specification describes a bounded stack, not arbitrary stacks, then the precondition is reasonable even though it arises from the implementation choices.

48. November 27, 2001Domain Modeling48 Precondition availability Every feature appearing in the precondition of a routine must be available to every client to which the routine is available. You cannot require something that the client is unable to check.

49. November 27, 2001Domain Modeling49 Class Invariants Global properties of the instances of a class which must be preserved by all routines that make up that class. For example, in a stack class where the stack has a maximum capacity, the number of elements on the stack is always between 0 and capacity. Pre and postconditions characterize individual operations

50. November 27, 2001Domain Modeling50 Class Invariants, cont. A class invariant may also express the semantic relations between functions or between functions and attributes. A class invariant is an assertion. –If assertions are not implemented, but are at least documented in the module itself, the intent of the designer can be maintained when the class is modified.

51. November 27, 2001Domain Modeling51 Class Invariants vary... briefly The invariant need not be satisfied at all times. A procedure may destroy the invariant and then re-establish it before terminating its execution.

52. November 27, 2001Domain Modeling52 What is the role of a class invariant? Because invariants capture the fundamental semantic constraints of a class, they change far less often. When functions are added, removed, or modified, they should be done in such a way that the invariant remains true. If the invariant must change, it should be raised to the level of serious consideration –ensure existing functions that satisfy the old one can satisfy the new one –it is a significant change, not an accidental side effect

53. November 27, 2001Domain Modeling53 More on role of class invariant Affects every contract in the class –The precondition and the invariant hold prior to execution –The postcondition and the invariant hold after execution Your job as implementer is: –easier if invariants are stated because you may assume the initial state satisfies the invariant –harder if invariants are stated because you must ensure the final state satisfies not only the postcondition but also the invariant. Like the kindergarten rule – leave the play area the way you would like to find it the next time

54. November 27, 2001Domain Modeling54 What does Correct mean? Usually “consistent with the specification” More specifically, –the class is correct if and only if its implementation, as given by the bodies of the operations, is consistent with the preconditions, postconditions, and invariant.

55. November 27, 2001Domain Modeling55 Using Assertions Help in writing correct software –spelling out exact requirements on each operation and global properties helps developers produce software that is correct the first time. –make it reliable BEFORE putting it into operation Documentation aid –Pre and postconditions and class invariants provide potential clients with concise, essential information Support for testing, debugging, and QA –monitoring preconditions as a debugging tool Support for software fault tolerance –especially in reuse where assumptions are long forgotten

56. November 27, 2001Domain Modeling56 A brief history Alan Turing, June 1950, encouraged the programmer to make a number of definite assertions which can be checked individually and from which the correctness of the whole program easily follows. Pioneer work on assertions –Bob Floyd, 1967; Tony Hoare, 1969; Taken further by –Edsger Dijkstra, 1976; David Gries, 1981

57. November 27, 2001Domain Modeling57 Bibliography Applying UML and Patterns - text Software Engineering Concepts, Richard Fairley, McGraw-Hill Series in Software Engineering and Technology, 1985, 364 pages. (possibly out of print now) ISBN 0-07-019902-7 Nothing overtly on OO; excellent concise coverage of historical concepts now used in OO. Object-Oriented Software Construction, 2 nd Edition, Bertrand Meyer, Prentice Hall PTR, 1997, 1,254 pages. Includes CD, ISBN 0-13-629155-4 (Extremely well-written and literate. Encyclopedic in scope. For example, about 100 pages on Design by Contract.)