LECTURE NO 15

SYSTEM INTERFACE SPECIFICATION(PART1)

Prepared by:
Ms.Sundas Shujah
Lecturer CS, COMSATS Abbottabad
 QUICK REVISION
• The analysis object model describes the entity, boundary, and control objects that are
visible to the user. The analysis object model includes attributes and operations for each
object.
• Subsystem decomposition describes how these objects are partitioned into cohesive
pieces that are realized by different teams of developers. Each subsystem includes
highlevel service descriptions that indicate which functionality it provides to the others.
• Hardware/software mapping identifies the components that make up the virtual
machine on which we build solution objects. This may include classes and APIs defined by
existing components.
• Boundary use cases describe, from the user’s point of view, administrative and
exceptional cases that the system handles.
• Design patterns selected during object design reuse describe partial object design
models addressing specific design issues.

Fall2019
 SYSTEM INTERFACE
• All previous models reflect only a partial view of the system.

• The goal of object design is to produce an object design model that

integrates all of the above information into a coherent and precise whole.

• The goal of interface specification, the focus of this chapter, is to describe

the interface of each object precisely enough so that objects realized by
individual developers fit together with minimal integration issues.

Fall2019
 INTERFACE SPECIFICATION CONCEPTS

• Class Implementor, Class Extender, and Class User

• Types, Signatures, and Visibility
• Contracts: Invariants, Preconditions, and Postconditions
• Object Constraint Language
• OCL Collections: Sets, Bags, and Sequences
• OCL Qualifiers: forAll and exists

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
CLASS IMPLEMENTOR, CLASS EXTENDER, AND CLASS USER
Types of Developers
is responsible for realizing the class under consideration. Class
implementors design the internal data structures and implement the
code for each
Implementor public operation. For them, the interface specification is a work
assignment.

invokes the operations provided by the class under consideration

during the realization of another class, called the client class. For
Class User class users, the interface specification discloses the boundary of the
class in terms of the services it provides and the assumptions it makes
about the client class.

the class extenders focus on specialized versions of the same services.

Class Extender For them, the interface specification both a specifies the current
behavior of the class and any constraints on the services provided by
the specialized class.

Fall2019
Fall2019
 INTERFACE SPECIFICATION CONCEPTS
TYPES, SIGNATURES, AND VISIBILITY
• During object design, we refine the analysis and system design models by
completing type and visibility information.

• The type of an attribute specifies the range of values the attribute can take
and the operations that can be applied to the attribute.
For example,
consider the attribute maxNumPlayers of the Tournament class.
Its type is int, denoting that it is an integer number.
• The type of the maxNumPlayers attribute also defines the operations that
can be applied to this attribute: we can compare, add, subtract, or multiply
other integers to maxNumPlayers

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
TYPES, SIGNATURES, AND VISIBILITY
Signature
• Given an operation, the tuple made out of the types of its parameters and the type
of the return value is called the signature.
• For example,
1) the acceptPlayer() operation of Tournament takes one parameter of type Player
and does not have a return value. The signature for acceptPlayer() is then
acceptPlayer(Player):void.
2) Similarly, the getMaxNumPlayers() operation of Tournament
• takes no parameters and returns an int. The signature of getMaxNumPlayers() is then
getMaxNumPlayers(void):int.

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
TYPES, SIGNATURES, AND VISIBILITY
• Visibility
• The visibility of an attribute or an operation is a mechanism for specifying
whether the attribute or operation can be used by other classes or not.
private attribute protected attribute
can be accessed only by the class in which it can be accessed by the class in which it is
is defined. Similarly, a private operation can defined and by any descendant of that
be invoked only by the class in which it is class.
defined.
Protected operations and attributes cannot
Private attributes and operations cannot be be accessed by any other class.
accessed by subclasses or calling classes.
Protected operations and attributes are
Private operations and attributes are intended for the
intended for the class implementor only. class extender.

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
TYPES, SIGNATURES, AND VISIBILITY
public attribute Package visibility (default)
A or operation can be accessed by any class. The An attribute or an operation with visibility package
set of public operations and attributes constitute the can be accessed by any class in the
public interface of the class and is intended for nearest enclosing package.
the class user. This visibility enables a set of related classes (for
example, forming a subsystem) to share a set of
attributes or operations without having to make
them public to the entire system.

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
TYPES, SIGNATURES, AND VISIBILITY
• Visibility
• It is denoted in UML
by prefixing the name
of the attribute or the
operation with a
character symbol:
• – for private,
• # for protected,
• + for public,
• ~ for package.

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
CONTRACTS: INVARIANTS, PRECONDITIONS,
AND POSTCONDITIONS
contract
• specifies constraints that the class user must meet before using the class as
well as constraints that are ensured by the class implementor and the class
extender when used.
• Contracts include three types of constraints:
1. An invariant is a predicate that is always true for all instances of a class.
Invariants are constraints associated with classes or interfaces.
Invariants are used to specify consistency constraints among class attributes.

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
CONTRACTS:
2) A precondition is a predicate that must be true before an operation is
invoked.
• Preconditions are associated with a specific operation. Preconditions are
used to specify constraints that a class user must meet before calling the
operation.

3) A postcondition is a predicate that must be true after an operation is

invoked.
• Postconditions are associated with a specific operation. Postconditions are
used to specify constraints that the class implementor.

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
CONTRACTS:
• For example, consider the Java interface for the Tournament.
• This class provides:
an acceptPlayer() method to add a Player in the Tournament,
a removePlayer() method to withdraw a Player from the Tournament (e.g., because
the player cancelled his application),
a getMaxNumPlayers() method to get the maximum number of Players who
can participate in this Tournament.
• An example of an invariant for the Tournament class is that the maximum number of
Players in the Tournament should be positive. If a Tournament is created with a
maxNumPlayers that is zero, the acceptPlayer() method will always violate its
contract and the Tournament will never start. Using a boolean expression, in which t is
a Tournament, we can express this invariant as
• t.getMaxNumPlayers() > 0
Fall2019
 INTERFACE SPECIFICATION CONCEPTS
CONTRACTS:
• An example of a precondition for the acceptPlayer() method is that the
Player to be added has not yet already been accepted in the Tournament
and that the Tournament has not yet reached its maximum number of
Players.
• Using a boolean expression, in which t is a Tournament and p is a Player, we
express this invariant as
!t.isPlayerAccepted(p) and t.getNumPlayers() < t.getMaxNumPlayers()

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
CONTRACTS
• An example of a postcondition for the acceptPlayer() method is that the
current number of Players must be exactly one more than the number of
Players before the invocation of acceptPlayer().
• We can express this postcondition as
t.getNumPlayers_afterAccept = t.getNumPlayers_beforeAccept + 1
• where numPlayers_afterAccept and numPlayers_afterAccept are the
current and number of Players before and after acceptPlayer(), respectively.

Fall2019
 INTERFACE SPECIFICATION CONCEPTS
CONTRACTS
• Why Contracts??
• We use invariants, preconditions, and postconditions to specify special or
exceptional cases unambiguously. It is also possible to use constraints to
completely specify the behavior of an operation. Such a use of constraints,
called “constraint-based specification,”

Fall2019