Abstract%20Data%20Types%20Operation%20contracts

1
Abstract Data Types Operation contracts

• CSE432

2
Abstract Data Types

• What does abstract mean?
• From Latin to pull outthe essentials
• To defer or hide the details
• Abstraction emphasizes essentials and defers the
  details, making engineering artifacts easier to
  use
• I dont need a mechanics understanding of whats
  under a cars hood in order to drive it
• Whats the cars interface?
• Whats the implementation?

3
Floating point numbers as ADTs

• You don't need to know how much about floating
  point arithmetic works to use float
• Indeed, the details can vary depending on
  processor, even virtual coprocessor
• But the compiler hides all the details from
  you--some numeric ADTs are built-in
• All you need to know is the syntax and meaning of
  operators, , -, , /, etc.
• See multimedia ADT for digits (properties)

4
ADT properties operations

• An ADT describes a set of objects sharing the
  same properties and behaviors
• The properties of an ADT are its data
  (representing the internal state of each object
• double d -- bits representing exponent
  mantissa are its data or state
• The behaviors of an ADT are its operations or
  functions (operations on each instance)
• sqrt(d) / 2 //operators functions are its
  behaviors
• Thus, an ADT couples its data and operations
• OOP emphasizes data abstraction

5
Design by contract

• ADT is a formal description, not code
• Independent of any programming language
• Why is code independence a good idea?
• Promotes design by contract
• Suppler/client responsibilities specified
  explicitly
• So they can be enforced, if necessary
• E.g., a contract for writing a book
• Contract specifies the book that the author will
  write
• Also specifies the royalties the publisher will
  pay, etc.

6
Generic Queue ADT

• An ADT specification has six parts
• First 3 deal with syntax NAME, SETS and
  SIGNATURES
• NAME QueueltIgt
• SETS
• I set of all items (generic type)
• Q set of all Queues
• B set of Boolean (elements T and F)
• N set of natural numbers, including 0
• NAME specifies an identifier for the type
• Generic parameter, ltIgt, may specify elements of
  collections
• SETS specifies types of all parameters in
  SIGNATURES

7
SIGNATURES section (see umprobsoyou are
adding)

• SIGNATURES
• Queue() -gt Q front(Q) -/-gt I
• isEmpty(Q) -gt B enqueue(Q, I) -gt Q
• length(Q) -gt N dequeue(Q) -/-gt Q
• SIGNATURES specifies the operations or services
  provided by ADT
• Notation of mathematical functions, with one or
  more inputs and producing one result
• isEmpty(Q) -gt B Given a Queue (domain), produces
  a Boolean (range)
• Functions have no side effects at all
• front(Q) given a Q, returns an item (no change)
• enqueue(Q, I) returns a NEW Queue
• dequeue(Q) returns another Queue
• Functional approach may seem inefficient, but
  facilitates semantics
• Implementation should preserve the abstract
  behavior of ADT
• Syntax is relatively easy to specify semantics
  is a bit harder.

8
Full vs. partial functions

• SIGNATURES
• Queue() -gt Q front(Q) -/-gt I
• isEmpty(Q) -gt B enqueue(Q, I) -gt Q
• length(Q) -gt N dequeue(Q) -/-gt Q
• -gt denotes a full function over the set Q
• Always produces the specified output
• -/-gt denotes a partial function over the set Q
• May not always produce the specified output
• Instead, its result may be undefined
• When is front undefined? When is enQueue
  undefined?
• Answering these questions about partial functions
  is semantics
• Specifically, the preconditions
• A partial function is undefined if any of its
  preconditions do not hold

9
Exercise Stack ADT syntax

• Define the NAME, SETS and SIGNATURES of an ADT
  for stacks (assume unlimited size)
• NAME Stackltigt
• SETS
• I set of all items
• S set of all Stacks
• B set of Boolean
• SIGNATURES
• Stack() -gt S push(S) --gt I
• isEmpty(S) -gt B pop(S) -/gt Q
• top(S) -/-gt I

10
Semantics of ADTs

• 3 more sections for semantics of ADTs
  variables, preconditions, and postconditions
• VARIABLES
• iI q, rQ nN bB
• PRECONDITIONS
• front(q) -gt isEmpty (q) false
• dequeue(q) -gt isEmpty (q) false
• VARIABLES -- declares instances of SETS, needed
  in PRE- and POST-CONDITIONS
• How are the variables used in PRECONDITIONS?
• What is the scope of these variables?

11
Preconditions

• Specify constraints on any partial functions,
  indicating when they fail
• front(q) -gt isEmpty (q) false //What does this
  constraint tell you?
• PRECONDITIONs very explicit about the when a
  partial function fails
• Formalizes design by contract analogous to
  written business contracts
• Inspires confidence between clients and suppliers
  of products
• ADT specifies a contract between the supplier and
  client of an ADT
• Supplier warrants that ADT will produce the
  specified behavior
• so long as client provides the expected inputs
• so long as client doesnt violate the
  pre-conditions, behaviors will work
• if the client violates the contract (any
  pre-condition), the behavior fails
• Yet even the failure is predictable and can be
  handled predictably
• Thus PRECONDITIONS also set up exception handling
• Note no need to include trivial preconditions,
  e.g., isEmpty(q) -gt true.

12
Exercise Stack ADT preconditions

• Define preconditions (and variables) for Stack
  ADT
• NAME Stackltigt
• SETS
• I set of all items
• S set of all Stacks
• B set of Boolean
• SIGNATURES
• Stack() -gt S push(I,S) --gt S
• isEmpty(S) -gt B pop(S) -/gt S
• top(S) -/-gt I
• VARIABLES
• sStack iItem
• PRECONDITONS
• top(s) -gt isEmpty(s) false
• pop(s) -gt isEmpty(s) false

13
Postconditions

• Define effects of functions, i.e., what they
  accomplish
• POSTCONDITIONS
• Queue() (qList List())
• isEmpty(q) null(qList)
• length(q) length(qList)
• front(q) head(qList)
• enqueue(q,i) (qList append(qList, i))
• dequeue(q,i) (qList tail(qList, i))
• What are we assuming already exists in these
  postconditions?
• List ADT has already been defined
• Why is constructive semantics a good fit for OOP?
• Reusing List implies a constructive semantics,
  building from other ADTs, already defined
• What does first postcondition tell you?
• What does second postcondition tell you?

14
Axiomatic semantics

• Defines relations between operations strictly in
  terms of universal axioms (self-evident truths)
• Axioms define an ADT independently of other ADTs
• Constructive approach builds new ADTs based on
  knowledge of existing ones
• The buck has to stop somewhere e.g., the List
  ADT uses an axiomatic semantics

15
List postconditions (axioms)

• null(List()) true //How is this self-evident?
• null(prepend(list1,i)) null(append(list1,i))
  false //Explain?
• length(List()) 0
• length(append(list1, i)) length(list1)1
• tail(append(list1,i)) if null(list1) then
• else append(tail(list1),i))

16
Constructive semantics(See umprobso, Queue of
football)

• Explain rest of Queues postconditions
• front(q) head(qList)
• enqueue(q,i) (qList append(qList, i))
• dequeue(q,i) (qList tail(qList, i))
• Why would this be harder with axioms?
• (See umprobso, axiomatic)

17
Exercise Stack ADT postconditions

• Define postconditions for Stack ADT
• NAME Stackltigt
• SETS
• I set of all items
• S set of all Stacks
• B set of Boolean
• SIGNATURES
• Stack() -gt S push(S) --gt I
• isEmpty(S) -gt B pop(S) -/gt S
• top(S) -/-gt I
• VARIABLES
• sStack iItem
• POSTCONDITIONS
• Stack() (sList List())
• isEmpty(s) null(sList)
• top(s) head(sList)
• pop(s) (sList front(sList))
• push(s,i) (sList prepend(sList, i))

18
Inheritance and ADTs

• See Employee example
• How does inheritance affect name section?
• NAME Employee SUPERTYPES Person
• How does inheritance affect other sections?
• Employee inherits functions for name, address,
  etc, from Person
• Inherits both syntax (SIGNATURES) and semantics
• Only redefine functions in Employee if they do
  something different
• Employee just supplies new constructor,
  GROSS_PAY, TAX_DUE
• Semantics can benefit further from reuse implied
  by inheritance
• Constructor for Employee invokes constructor for
  Person
• Could add notation abstract to specify abstract
  functions

19
Why define ADTs?

• Makes contract between designer and programmers
  explicit
• Eliminates vagueness about what functions
  (operations or methods) do
• Eiffel provides assertions to support programming
  by contract
• Assertions have been added to Java
• Sets up unit testing

20
Domain Model and Operation Contracts

• A Domain Model is a visual representation of
  conceptual classes in a domain of interest.
• Operation Contracts describe detailed system
  behavior of operations
• In terms of state changes to objects in the
  Domain Model, after a system event has executed

21
Example Operation Contract from Larman enterItem
Contract CO2 enterItem

• Operation enterItem(itemID
  ItemID, quantity integer)
• Cross References Use Cases Process Sale
• Preconditions There is a Sale Underway.
• Postconditions -A SalesLineItem instance sli
  was created (instance creation) -sli was
  associated with the current Sale (association
  formed) -sli.quantity became quantity
  (attribute modification) -sli was associated
  with a ProductSpecification, based on
  itemID match (association formed)

How does it differ from an ADT spec?
22
Postconditions

• Describe changes in the state of objects in the
  Domain Model
• Include instances created, associations formed or
  broken, and attributes changed
• Postconditions are not actions to perform
• Rather, they are declarations about Domain Model
  objects that are true when the operation has
  finished

23
Writing Postconditions Past Tense

• Express postconditions in the past tense, to
  emphasize they are declarations about a state
  change in the past.
• (better) A SalesLineItem was created.
• (worse) Create a SalesLineItem.
• Why?

24
The Spirit of Postconditions The Stage and
Curtain

• System and its objects are presented on a
  theatre stage
• Before the operation, snapshot of the stage.
• Close the curtains on the stage, and apply the
  system operation
• Open curtains and take a second picture
• Compare the before and after pictures, and
  express as postconditions the changes in the
  state of the stage
• (A SalesLineItem was created).

25
Writing Contracts Leads to Domain Model Updates

• New conceptual classes, attributes, or
  associations in the Domain Model are often
  discovered during contract writing
• Enhance the Domain Model as you make new
  discoveries while thinking through the operation
  contracts

26
Guidelines Contracts

• To make contracts
• Identify system operations from SSDs
• For system operations that are complex and
  perhaps subtle in their own results, or which
  are not clear in the use case, construct a
  contract
• To describe the postconditions, use - instance
  creation and deletion - attribute
  modification - associations formed and broken

27
System Sequence Diagram and ADT assignment

• Your assignment (on Blackboard)
• Improve your domain analysis
• Per my comments
• Develop a System Sequence Diagram for the ATM
  problem
• Develop ADT design/Operation contracts for the
  Fruit problem
• Extra credit design user interface ADTs for
  either
• loosely coupled to problem domain ADT
• Due September 30