November 27, 2001Domain Modeling1 Domain Modeling Chapters 10-12 Use-Case Modeling Chapters 9 and 13...
-
date post
21-Dec-2015 -
Category
Documents
-
view
218 -
download
1
Transcript of November 27, 2001Domain Modeling1 Domain Modeling Chapters 10-12 Use-Case Modeling Chapters 9 and 13...
November 27, 2001 Domain Modeling 1
Domain ModelingChapters 10-12
Use-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
November 27, 2001 Domain Modeling 2
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)
November 27, 2001 Domain Modeling 3
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
November 27, 2001 Domain Modeling 4
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
November 27, 2001 Domain Modeling 5
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
November 27, 2001 Domain Modeling 6
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, q
uant
ity
desc
ript
ion,
tota
l
tota
l with
taxe
samou
nt
November 27, 2001 Domain Modeling 7
Cashier
Item
ID, q
uant
ityde
scri
ptio
n, to
tal
chan
ge d
ue, r
ecei
pt
amou
nt
enterItem
makePayment
CashierNeed a convention to show makeNewSale or endSale because no data flows from Cashier to action even though they are “event indicators”.
November 27, 2001 Domain Modeling 8
select action
makeNewSale
enterItem
makePayment
endSale
Cashier
ItemID, quantitydescription, total
total with taxes
amount
change due, r
eceipt
Cashier
action indicator
<ack>
<ack>
format result
Cashier
Classic Transactional DFD
November 27, 2001 Domain Modeling 9
Example UML Context Diagrams
November 27, 2001 Domain Modeling 10
Another UML context
diagram
November 27, 2001 Domain Modeling 11
One more UML context diagram
November 27, 2001 Domain Modeling 12
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
November 27, 2001 Domain Modeling 13
Sam
ple Dom
ain Model
November 27, 2001 Domain Modeling 14
another example
November 27, 2001 Domain Modeling 15
yet another example
November 27, 2001 Domain Modeling 16
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
November 27, 2001 Domain Modeling 17
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
November 27, 2001 Domain Modeling 18
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
November 27, 2001 Domain Modeling 19
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
November 27, 2001 Domain Modeling 20
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
November 27, 2001 Domain Modeling 21
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
November 27, 2001 Domain Modeling 22
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?
November 27, 2001 Domain Modeling 23
Importance of domain expertise
Adequate requirements
Inadequate requirements
Low domain expertise
High domain expertise
November 27, 2001 Domain Modeling 24
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
November 27, 2001 Domain Modeling 25
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
November 27, 2001 Domain Modeling 26
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
November 27, 2001 Domain Modeling 27
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.
November 27, 2001 Domain Modeling 28
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
November 27, 2001 Domain Modeling 29
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
November 27, 2001 Domain Modeling 30
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
November 27, 2001 Domain Modeling 31
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
November 27, 2001 Domain Modeling 32
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
November 27, 2001 Domain Modeling 33
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
November 27, 2001 Domain Modeling 34
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.
November 27, 2001 Domain Modeling 35
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)
November 27, 2001 Domain Modeling 36
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?
November 27, 2001 Domain Modeling 37
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”.
November 27, 2001 Domain Modeling 38
Filter modules
External items
Filters – input & output validation modules (only pass along when preconditions are met.
Processing modules (have preconditions)
System
November 27, 2001 Domain Modeling 39
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
November 27, 2001 Domain Modeling 40
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
November 27, 2001 Domain Modeling 41
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.
November 27, 2001 Domain Modeling 42
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.
November 27, 2001 Domain Modeling 43
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).
November 27, 2001 Domain Modeling 44
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
November 27, 2001 Domain Modeling 45
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
November 27, 2001 Domain Modeling 46
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
November 27, 2001 Domain Modeling 47
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.
November 27, 2001 Domain Modeling 48
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.
November 27, 2001 Domain Modeling 49
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
November 27, 2001 Domain Modeling 50
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.
November 27, 2001 Domain Modeling 51
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.
November 27, 2001 Domain Modeling 52
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
November 27, 2001 Domain Modeling 53
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
November 27, 2001 Domain Modeling 54
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.
November 27, 2001 Domain Modeling 55
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
November 27, 2001 Domain Modeling 56
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
November 27, 2001 Domain Modeling 57
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, 2nd 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.)