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


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)


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


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


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


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


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


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


Example UML Context Diagrams


Another UML context

diagram


One more UML context diagram


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


Sam

ple Dom

ain Model


another example


yet another example


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


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


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


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


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


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


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?


Importance of domain expertise

Adequate requirements

Inadequate requirements

Low domain expertise

High domain expertise


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


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


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


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.


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


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


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


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


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


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


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.


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)


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?


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


Filter modules

External items

Filters – input & output validation modules (only pass along when preconditions are met.

Processing modules (have preconditions)

System


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


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


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.


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.


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


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


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


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


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.


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.


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


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.


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.


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


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


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.


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


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


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

Date post:	21-Dec-2015
Category:	Documents
View:	216 times
Download:	1 times

November 27, 2001Domain Modeling1 Domain Modeling Chapters 10-12 Use-Case Modeling Chapters 9 and 13...

Documents