Components, interfaces, and re-entrance

1
Components, interfaces, and re-entrance

• Taciana Amorim Vanderlei
• tav_at_cin.ufpe.br

2
Contents

• Components and interfaces
• Direct and indirect interfaces
• Versions
• Interfaces as contract
• What belongs to a contract?
• Dress code fomal or informal?
• Callbacks and contracts
• Example of callbacks and contracts
• From callbacks to objects
• Object re-entrance

3
Components and interfaces

• Interfaces are the means by which components
  connect. Technically, an interface is a set of
  named operations that can be invoked by clients.
• Each operations semantics is specified, and this
  specification plays a dual role as it serves both
  providers implementing the interface and clients
  using the interface.

4
Components and interfaces

• A component may either directly provide an
  interface or implement objects that, if made
  available to clients, provide interfaces.
• Interfaces directly provided by a component
  correspond to procedural interfaces of
  tradicional libraries. Such indirectly
  implemented interfaces correspond to object
  interfaces.

5
Direct and indirect interfaces

• A procedural (direct) interface to a component is
  modeled as an object interface of a static object
  within the component.
• An object (indirect) interface introduces an
  indirection called method dispatch or, sometimes,
  dynamic method lookup.

6
Versions

• Tradicional version management assumes that the
  versions of a component envolve at a single
  source. In a free market, the evolution of
  versions is more complex and management of
  version numbers can become a problem in its own
  right.
• With direct interfaces it suffices to ckeck
  versions at bind time, which is when a service is
  first requested. In indirect interfaces couple
  arbitrary third party. In a versioned system,
  care must be taken to avoid indirect coupling of
  parties that are of incompatible versions. The
  goal is to ensure that older and newer components
  are either compatible or clearly detected as
  incompatible.

7
Interfaces as contract

• The contract states what the client needs to do
  to use the interfaces and what the provider has
  to implement to meet the services promised by the
  interface.
• A contract is an appropriate approach, with pre-
  and post-conditions attached to every operation
  in the library.

8
What belongs to a contract?

• Safety and progress
• Progress condition often rely on some form of
  temporal logic. They complement the safety
  conditions that can be expressed using
  invariants.
• Extra-functional requirements
• The practice of including extra-functional
  specifications into a contract is not popular in
  the present, causing problems as performance and
  consume of resources.
• Specifying time and space requirements

9
Dress code fomal or informal?

• None of the real-world laws are formal. New
  interpretations are found every day and tested
  in court.
• Different parts of a system can be specified
  using different degrees of formality the
  preciseness of the specification have to be
  balanced against the critically of the target
  part.

10
Callbacks and contracts

• Callbacks are a common feature in procedural
  libraries that have to handle asynchronous
  events.
• A callback usually reverses the direction of the
  flow of controls, so a lower layer calls a
  procedure in a higher layer.
• The resulting contract are far less manageable
  than simple pre- and post-conditions.
• Validity of the library state is specified as
  part of a contract.

11
Callbacks and contracts
Critical part
The intermediate library state at the point of
calling the callback may be reveled to clients.
12
Example of callbacks and contracts A directory
service

• DEFINITION Directory
• IMPORT Files ( details of no importance for
  this example )
• TYPE
• Name ARRAY OF CHAR
• Notifier PROCEDURE(IN name Name) (
  callback )
• PROCEDURE ThisFile(n Name)Files.File
• ( pre n ! )
• ( post result file named n or (result
  NIL and no such file) )
• PROCEDURE AddEntry(n Name f Files.File)
• ( pre n ! and f ! NIL )
• ( post ThisFile(n) f )
• PROCEDURE RemoveEntry(n Name)
• ( pre n ! )
• ( post ThisFile(n) NIL )
• PROCEDURE RegisterNotifier(n Notifier)
• ( pre n ! NIL )
• ( post n registered, will be called on
  AddEntry and RemoveEntry )
• PROCEDURE UnregisterNotifier(n Notifier)
• ( pre n ! NIL )

13
Example of callbacks and contracts A client of
the directory service

• MODULE DirectoryDisplay ( most details deleted
  )
• IMPORT Directory
• PROCEDURE Notifier(IN n Directory.Name)
• BEGIN
• IF Directory.ThisFile(n) NIL THEN
• ( entry under name n has been removed
  delete n in display )
• ELSE
• ( entry has been added under name n
  include n in display )
• END
• END Notifier
• BEGIN
• Directory.RegisterNotifier(Notifier)
• END DirectoryDisplay.

14
From callbacks to objects

• Object references introduce linkage across
  arbitrary abstraction domains. It is certainly
  not as natural as with procedural abstraction.
• With object reference there is no need for
  explicit callback constructs as every method
  invocation is potencially a callback.

15
From callbacks to objects
16
Object re-entrance

• The object re-entrance is the situation in which
  an objects method is invoked while another
  method is still executing.
• The real problem is observation of an object
  undergoing a state transition with inconsistent
  intermediate states becoming visible. Considering
  object re-entrance, the problem is when an
  objects method is invoked while another method
  is still executing.
• Recursion and re-entrances become even more
  pressing problem when crossing the boundaries of
  components.

17
Object re-entrance
18
Components, interfaces, and re-entrance

• Questions?