Domain Model

1
Domain Model

• Use Case Model
• text
• diagram
• SSD
• System operation contracts

Design Model
Figure 13.3
2
Contracts

• A technique for describing system operations in
  terms of state changes to objects in a Domain
  Model
• major proponent - Bertrand Meyer
• based on concept of assertion
• a statement, a declaration, that must be true
• a false value indicates a bug
• UML has OCL - very formal syntax which we will
  ignore

3
Contracts

• Consider the execution of a routine
• The called routine provides a service - it is the
  supplier
• The caller is the client requesting the service.
• A contract will spells out precisely the
  obligations of the caller (client) and the
  callee (supplier).
• The contract serves as an interface specification
  for the routine.
• Example consider a routine that merges two
  sorted sequences. The merge routine is the
  supplier of the service the calling routine is
  the caller. A contract will spell out the
  responsibilities of each party.

4
Responsibilities

• Client Ensure that the both of the sequences to
  be merged are each already sorted
• Supplier Efficiently merge the two sorted
  sequences into one sorted sequence
• Software contract
• The responsibilities of the client will be called
  pre-conditions
• The responsibilities of the supplier will be
  called post-conditions

5

• During analysis developers must first understand
  the problem domain and identify domain objects,
  their relationships with other domain objects,
  and their constraints.
• If a contract is defined in terms of domain
  objects the constraints can be clear and
  explicit, easily understood
• Everyone understands the business contracting
  metaphor.
• Business rules (constraints) can become an
  integral part of the software from the very
  beginning.
• Example consider a withdraw method for an
  ACCOUNT class withdraw (amount_to_withdraw
  MONEY)

6

• Example consider a withdraw method for an
  ACCOUNT class
• withdraw (amount_to_withdraw MONEY)
• Pre-conditions
• positive_amount amount_to_withdraw gt 0
• sufficient_balance balance gt amount_to_withdraw
  
• Post-conditions
• correct_balance balance old balance -
  amount_to_withdraw end

7
Contracts

• Contract Components (Ch 13)
• Operation - name and parameters
• Cross References - where operation used
• Preconditions - assumptions about the state of
  the system or Domain Model objects
• Postconditions - state of objects after the
  operation completes
• objectsany new ones? any attributes modified?
• associations any new or modified associations?
• Larmans version is very informal

8
SSD for a samplePOS Use Case Figure 13.1
Input Events invoke a system operation of the
same name same idea as in object-oriented
programming when we say a message foo invokes the
method foo
Referred to as the enterItem system operation
9
The part of the Domain Model relevant to
enterItem( )
1
Described by

1..
Contained in
1
10
Contracts
Example Operation enterItem (itemID ItemID,
quantity integer) Cross References Use Case
Process Sale Preconditions There is a sale
underway Postconditions - a SalesLineItem
instance was created - an association between the
sale and the sales line item was created - an
attribute, quantity, was modified - an
association between the product specification and
the sales line item was created
11
OCL

• Object Constraint Language
• UML has a formal language for specifying
  constraints on object-oriented models

context Salesperson sell ( item Thing )
Real pre self.sellableItems -gt includes
(item) post not self.sellableItems -gt includes
(item) and resultitem.price
12
Design By Contract (DBC) provides the basis for
documenting software interfaces Reusers of a
software component need to understand what the
software provides them and what they must do to
obtain these benefits. This is the contract. DBC
is perhaps a best non-practice. Example of a new
contracting tool iContract Design by Contract
in Java http//www.javaworld.com/javaworld/jw-02-
2001/jw-0216-cooltools.html