1 / 39

4.3 Interfaces

4.3 Interfaces. Interfaces. Define the component’s access points Will normally have multiple interfaces Standard naming schemes needed to reference interfaces Standardisation of message formats also needed. Interfaces (2). Two types of interfaces Provided interfaces Required interfaces.

ccronin
Télécharger la présentation

4.3 Interfaces

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 4.3 Interfaces

  2. Interfaces • Define the component’s access points • Will normally have multiple interfaces • Standard naming schemes needed to reference interfaces • Standardisation of message formats also needed

  3. Interfaces (2) • Two types of interfaces • Provided interfaces • Required interfaces

  4. Interfaces (3) Print service Required Interfaces Provided Interfaces Print GetPDFile GetQueue Remove PrinterInt Transfer Register Unregister

  5. Interfaces (4) • Are the means by which components connect • Is a set of named operations that can be invoked by clients

  6. Interfaces (5) • Dual role of the interface specification • Providers implementing the interface • Clients using the interface

  7. Interfaces (6) • Component specification • A component can be specified separate from their interfaces • A component specification includes • All the interfaces that the component should support • Component-specific properties • Multiple component implementation can conform to such specification

  8. Interfaces (7) • Versions • Immutable interfaces • Multiple versions are supported by multiple interfaces • Constrained changes • Rules define the kind of changes that are valid to retain backward compatibility

  9. Interfaces (8) • Contracts • Interface specifications can be viewed as contracts between clients and providers • Contract state • what the client needs to do to use the interface • What the provider has to implement to meet the services define in the interface

  10. Interfaces (9) • A popular contractual specification method • The client meets a precondition before calling the operation • The provider meets a postcondition before returning to the client

  11. Interfaces (10) • When implementation is changed • Contracts should be maintained • At most, the provider most required less and provide more

  12. Interfaces (11) • Non-functional requirements • A contract should include all essential functional and non-functional aspects • Specifying complexity bounds • Might include platform specific performance figures

  13. Abstraction levels • Meyer identifies 5 abstraction levels: • Functional abstraction • Casual abstraction • Data abstraction • Cluster abstraction • System abstraction

  14. Some more terms • Component model [Szyperski] • Defines the rules of composition

  15. Some more terms (2) • Component Model [Wallnau] • “Is the set of component types, their interfaces, and, additionally, a specification of the allowable patterns of interaction among component types”

  16. Some more terms (3) • Component framework • “Is a set of interfaces and rules of interaction that govern the interaction of components ‘plugged into’ them.” • Is a reusable architectural design targeting a specific domain whereby desired architectural properties and invariants are enforced

  17. 4.4 Callbacks and contracts

  18. Callbacks and contracts • A callback is a procedure that is passed to a library at one point Other party Library Client Client installs callback Third party calls library Library invokes callback Callback queries library Callback returns Library returns

  19. Callbacks and contracts (2) • Common feature in procedural libraries that have to handle asynchronous events • Windowing libraries use a callback to notify a particular window’s client code when the user resized the window

  20. Callbacks and contracts (3) • A library can make part of its state observable by exporting variables or inspection functions • The relative order in which callbacks are performed can be observed • However, such ordering is not specified by normal pre- and postconditions

  21. 4.5 Polymorphism

  22. Polymorphism • Polymorphism is • The ability of something to appear in multiple forms, depending on the context

  23. Polymorphism • Same interface • Used by large numbers of different clients • Supported by a large number of different providers • Keep balance of what is required from providers and clients

  24. Polymorphism • If an interface requires too little from providers • it is useless • If an interface requires too much from providers or clients • it is difficult to implement

  25. Polymorphism • A carefully crafted interface requires no more than is essential • Clients and providers are always free to overfulfill their contract

  26. Polymorphism • Pre- and post conditions are usually specified using predicates • Which define • The permitted input and output values • The permitted values of an internal variable • Operations that should be executed • Example: • len<max and 0<=position<=max

  27. Polymorphism • When is it legal to substitute one service provider for another? • When a provider satisfies the contract

  28. Polymorphism • Ideally, contracts should be explicitly specified as part of an interface spec • It would be desirable to have a compiler to check contract compatibility • In reality, it is far from attainable: • Formalising contracts is difficult and expensive • Automatic checking still part of research

  29. Polymorphism • Checking can be done at: • compiling-time • Load-time • Run-time better

  30. Polymorphism • Type • Group of values of related semantics • Basic types, such as INTEGER and REAL, can be understood as sets of values • In case of objects and interfaces, type is a set of objects implementing a certain interface

  31. Polymorphism • Types as simplified contracts • The types of the in-out parameters form part of: • an operation’s preconditions • An operation’s postconditions • However, other part of the pre and postconditions are not part of a type • Successful type checking does not ensure contracts are not violated

  32. Polymorphism • Subtyping • Named subtyping (interface inheritance) • Base interfaces are named • Structural subtyping • Base interface are not named • Operations are repeated • Is a superset of operations defined by another type

  33. Polymorphism • There is polymorphism • When a variable can refer to objects of multiple subtypes • Example: • The variable of type View can refer to objects of type View, TextView, GraphicsView, etc

  34. Architecture not enough to achieve qualities

  35. Quality scenarios: Examples

  36. Quality scenarios: Examples

  37. Open Distributed Processing • Openness required to overcome the problems of • Complexity • Heterogeneity • ODP’s main function: • distributed services transparently located and accessed • regardless of the underlying platform

  38. Open Distributed Processing • An open system [Coulouris]: • is one that can be extended and implemented in different ways; • for this the key interfaces must be made public

  39. We require: • To standardise well-defined interfaces • ODP can achieve: • Interoperability • Portability • Middleware is an effort to meet ODP’s principles

More Related