Information Technology Reference
In-Depth Information
Visibility is denoted in UML by prefixing the symbol—for private, # for pro-
tected, + for public and * for package to the name of the attribute or operation.
8.2.3 Object Contracts: Invariants, Preconditions
and Postconditions
Contracts are constraints on a class that enable the caller and callee to share the
same assumptions about the class. Contracts include three types of constraints:
Invariant is a predicate that is always true for all instances of a class. Simply
speaking, this is to say the class is/has/will [any word here] is a predicate. This
simply allows for a description of contracts between classes.
Precondition is a predicate that must be true before an operation is invoked.
Preconditions are used to specify constraints that a caller must meet before calling
operation. An example of this would be check to make sure a number that will be
used to divide by is not zero, as in most instances this results in undesirable
behavior.
Postcondition is a predicate that must be true after an operation is invoked.
Postconditions are used to specify constraints that the object must ensure are
fulfilled after the invocation of operation (Bruegge and Dutiot
2000
).
8.3 Reuse Concepts: Objects and Design Patterns
8.3.1 Objects
Class diagrams are used to model application domain and solution domain.
Application objects also called ''domain objects'', as they represent concepts of
domain that are relevant to the system. They are identified by the application
domain specialist and domain specialists and end users. Solution objects represent
components that do not have a counterpart in the application domain, such as
persistent data stores, user interface objects or middleware. They are identified by
developers. An example of each is shown below (Bruegge and Dutoit
1999
). Most
of the entity objects identified in analysis process are application objects. They are
independent and specific to the system. During analysis the solution objects
identified are visible to the user such as forms, windows etc. During system design
we identify solution objects, and during object design we refine both application,
as well as solution objects needed to bridge the object design gap (Bruegge and
Dutiot
2004
) (Figs.
8.3
and
8.4
).
