Domain Modeling Chapters 10-12 Use-Case Modeling Chapters 9 and 13

Domain ModelingChapters 10-12Use-Case ModelingChapters 9 and 13 Filling in some gaps about: Levels of abstraction Contrast to functional decomposition Pre and Post Conditions Invariants & Input-Output Assertions Domain Modeling

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) Domain Modeling

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

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

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

SSD and Context DFD ;Cashier ;System makeNewSale() enterItem(ItemID, quantity) description, total System endSale() total with taxes amount makePayment (amount) Item ID, quantity description, total total with taxes change due, receipt Cashier Domain Modeling

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

Classic Transactional DFD <ack> makeNewSale Cashier <ack> action indicator enterItem ItemID, quantity Cashier select action format result description, total Cashier amount makePayment change due, receipt endSale total with taxes Domain Modeling

Example UML Context Diagrams Domain Modeling

Another UML context diagram Domain Modeling

One more UML context diagram Domain Modeling

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

Sample Domain Model Domain Modeling

another example Domain Modeling

yet another example Domain Modeling

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

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

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

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

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

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

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? Domain Modeling

Adequate requirements Low domain expertise High domain expertise Inadequate requirements Importance of domain expertise Domain Modeling

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

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

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

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

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

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

Present State Input or Event Action Output Next State ST1. Idle card inserted request for PIN Waiting for PIN ST2. Waiting for PINPIN entered display asterisks Validating PIN ST3. Waiting for PINcancel display msg Ejecting ST4. Validating PINindicates “valid” display choices Waiting 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 Cancel display “cancel” Ejecting ST8. Waiting for customer transaction choice Balance Query selected Processing query continued on next slide Domain Modeling

ST9. Waiting for customer transaction choice Withdrawal selected Processing w/d ST10. confiscating Card confiscated terminating ST11. Processing query Rejected for this user display “rejected” Ejecting ST12. Processing query Query OK display printing printing ST13. Processing withdrawal ok amount display ok msg dispensing ST14. Processing withdrawal not ok amount display refusal Ejecting ST15. Printing transaction complete print receipt ejecting ST16. Dispensing sufficient cash in ATM cash printing ST17. Dispensing insufficient cash in ATM disp “insufficient cash” ejecting ST18. Ejecting card ejection started display msg to take card terminating ST19. terminating card ejection complete display ending msg idle Domain Modeling

State Transition Diagram - incomplete card inserted/ PIN inserted/ waiting for PIN Idle validating PIN “invalid” card ej complete “cancel” “stolen” ejecting “valid” terminat-ing confis-cating waiting for cust xaction card confis’d “cancel” Domain Modeling

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

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

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) Domain Modeling

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? Domain Modeling

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”. Domain Modeling

Filter modules System Filters – input & output validation modules (only pass along when preconditions are met. External items Processing modules (have preconditions) Domain Modeling

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

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

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

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

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). Domain Modeling

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

Sound familiar? • The demandingapproach 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 Domain Modeling

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

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

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

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

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

Domain Modeling Chapters 10-12 Use-Case Modeling Chapters 9 and 13