Transparencies on CBSD - PowerPoint PPT Presentation

1 / 46
About This Presentation
Title:

Transparencies on CBSD

Description:

It provides semantics to the operations (without showing implementation) ... Evolution vs Immutability. Can a contract evolve, or must it remain immutable? ... – PowerPoint PPT presentation

Number of Views:79
Avg rating:3.0/5.0
Slides: 47
Provided by: juancarl
Category:

less

Transcript and Presenter's Notes

Title: Transparencies on CBSD


1
Transparencies on CBSD
  • Component-Based Software Development
  • Juan Carlos Guzmán
  • SPSU

2
Interfaces
  • Set of named operations that can be invoked by
    clients
  • It provides semantics to the operations (without
    showing implementation)
  • Can be considered as a specification of what
  • the implementation must adhere to
  • the client can expect
  • It is a contract

3
Interface as a Contract
  • Establishes pre and postconditions for each
    operation
  • Preconditions
  • established by the client
  • demanded by the interface
  • required by the provider
  • Postconditions
  • established by the provider
  • guaranteed by the interface
  • expected by the client

4
Polymorphism
  • The ability of a context to accept elements of
    different properties without distinction

5
Types, subtypes, and type checking
  • Arbitrary pre and postcondition contract checking
    is not feasible
  • Typing and subtyping is feasible
  • A simplified contract
  • can be checked

6
Subtyping
  • Follows the contravariance rule
  • implementations can always be stronger than the
    contract
  • clients requests can always be weaker than the
    contract

7
Independent Extensibility
  • A system is independently extensible if
  • it is extensible
  • its extensions can be combined
  • the extensions are components
  • Modern O/S are extensible
  • microkernel
  • bunch of components

8
Problem
  • Each component has its own context
  • Cross-context calls are expensive
  • The system must ensure that
  • the call is authorized
  • context switch is handled
  • parameters are passed caller to callee
  • Cross-context returns are also expensive

9
Solution
  • Create safe components
  • compile away, or strongly simplify authorization
  • certify good components
  • Just how safe can the components be?

10
Evolution vs Immutability
  • Can a contract evolve, or must it remain
    immutable?
  • How can you change a public contract?
  • Syntactic vs semantic changes
  • Two ways out
  • expiration
  • overriding law

11
Inheritance
  • One kind of inheritance?
  • No, Three kinds
  • subclassing (implementation)
  • subtyping (contract/interface)
  • substitutability
  • What about multiple inheritance?
  • mixins

12
Fragile Base Class Problem
  • When I modify a base class
  • do I have to recompile its derived classes?
  • do I have to modify them?

13
Syntactic FBC Problem
  • Are derived classes compatible with newer
    releases of super classes, where appropriate
    interface (and semantics) have not changed, but
    the interface has been rearranged?
  • Trivial changes to the interface
  • new methods or properties
  • new classes have been incorporated to the
    hierarchy
  • methods have been moved to other places within
    the inheritance path (still visible)

14
Semantic FBC Problem
  • Changes in appropriate interface or semantics
  • change of parameter order/number/etc of a method
  • change of semantics of a method

15
Issues with Inheritance
  • Method override
  • Methods calling subclasses methods
  • Abstraction layers may be broken
  • Class interfaces
  • Client interface
  • public
  • Specialization interface
  • protected

16
Object Composition
  • Also reuses code
  • the reuse has to be made explicit via
    forwarding
  • Lack of a common self
  • has-a vs is-a
  • Can introduce delegation

17
Granularity
  • Partitioning into components
  • Modularization of the system

18
Dividing the System in Units
  • Abstraction
  • Accounting
  • Analysis
  • Compilation
  • Delivery
  • Deployment
  • Dispute
  • Extension
  • Fault containment
  • Instantiation
  • Installation
  • Loading
  • Locality
  • Maintenance
  • System management

19
Design Level Reuse
  • Design Reuse attempt to share certain aspects of
    an approach across projects
  • To Share
  • consistency
  • concrete solution fragments
  • contracts
  • indiv. interaction fragments
  • interaction architectures
  • subsystem architectures
  • overall structure
  • Use
  • programming languages
  • libraries
  • interfaces
  • messages protocols
  • patterns
  • frameworks
  • system architectures

20
Programming Languages
  • Encode dogmas of how things should be done
  • Enforce static safety properties
  • Cannot verify the program against its specs

21
Libraries
  • Hold the proven functionality for a domain

22
Interfaces
  • Smallest contractual units in a system
  • Minimal basis for interaction between client and
    provider
  • These characterize the end points

23
Messages and Protocols
  • Messages communication between endpoints
  • Protocols valid sequences of messages between
    endpoints

24
Patterns
  • A set of ideas that can be applied in many
    situations
  • Microarchitectures
  • describe abstract interaction between objects
    collaborating to solve a particular problem

25
Frameworks
  • Sets of cooperating classes (some may be
    abstract) that make a up a reusable design for a
    specific class of software

26
System Architecture
  • Layering
  • Extensibility
  • High-level design

27
Programming
  • Paradigm shift
  • from
  • composition of procedural abstractions
  • caller driven
  • interfaces are entry points
  • to
  • connection oriented
  • binding caller/callee
  • incomming interfaces
  • outgoing interfaces

28
Connection-Oriented Prog.
  • Connections to glue components
  • Pull vs. push way of programming
  • direct calls
  • calls resulting from events
  • Notification (event propagation)
  • Usual procedure calls pull model
  • Being notified calls push model

29
Connection-Oriented Prog.
  • Incoming interfaces
  • aka provided interfaces
  • events and messages received by the component
  • Outgoing interfaces
  • aka required interfaces
  • events and messages the component may emit

30
Connection-Oriented Prog.
  • Incoming interface
  • the call through the interface originated from
    outside the component
  • Outgoing interface
  • the call through the interface originated from
    inside the component
  • The communication can be either way (or both
    ways) through these interfaces

31
Connection-Oriented Prog.
  • Channels (or groups)
  • Abstractions through which callers (sources)
    communicate to callees (sinks)
  • Channels allow multiple sources and multiple
    sinks, and allow endpoints to be dynamically
    added and deleted
  • They may also provide additional services

32
Communication
  • 1.- Create a message object
  • initialize its fields
  • 2.- Send the message
  • to the sinks
  • (or to the channel)

33
Problems with Message Objects
  • First class event objects can be expensive
  • Event objects of the wrong type can be passed
  • Not properly initialized event objects can be
    passed

34
Difference Between Messages and Objects
  • Objects encapsulate state and behavior
  • Messages package data
  • no reference to other messages
  • usually no behavior
  • if object reference is needed, use indirection
  • So messages are simpler

35
Ordering of Events
  • Causalty
  • Relative order of events being fired and received
  • Races
  • when two events can arrive at a target in
    different relative ordering
  • Glitches
  • temporary state inconsistency

36
Metaprogramming
  • Programming oneself
  • Using the information about the system to program
    the system itself
  • some of this can be useful
  • extending the kind of messages that a component
    can handle
  • not all
  • Need very late binding

37
Wiring Standards
  • What is wiring
  • Why we need standards for it
  • What are the standards

38
Interprocess Communication
  • Communicating Information
  • Files
  • Pipes
  • Sockets
  • Shared Memory
  • All in binary format

39
Remote Procedure Calls
  • Caller callee on different computers
  • From the callers point of view, the callee is
    local
  • From the callees point of view, the caller is
    local
  • RPC will handle the communication, back and forth
  • Arguments, and result, need to be transmitted
    through the network

40
How Much Does It Cost?
  • In-process calls
  • Interprocess calls
  • Intermachine calls

41
On Interfaces
  • Type signatures?
  • How to translate data from the caller to the
    callee, and back?
  • Universally unique identifiers UUID

42
How About Objects?
  • When sending a message, the method executed can
    be dependent on the actual object to which this
    message is sent
  • The object always knows its self
  • But O/Ss work on processes, not objects
  • Need a way to generate method calls

43
XML
  • Extensible Markup Language
  • Useful to represent structured data
  • General enough to be extensible
  • Specific enough to be usable
  • A document is a tree, in textual form
  • These trees can be characterized -- use schemas

44
SOAP
  • Remote object invocation
  • Uses XML to transmit messages

45
XML Web Services
  • Services geared towards automated clients
  • How to describe them
  • Need description capabilities (metalevel)

46
Web Service Discovery
  • A web service that discovers other services and
    keeps them in a directory
  • UDDI
Write a Comment
User Comments (0)
About PowerShow.com