Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

Software Components

Prof. Cesare Pautasso
http://www.pautasso.info
cesare.pautasso@usi.ch
@pautasso

What is a Software Component?

Hardware Component

Software Component

Black Box

  1. Encapsulation
    • Clearly separate the content from the rest of the system
  2. Abstraction
    • Hide implementation details behind the interface contract
  3. Modularity
    • Reusable unit of assembly/deployment
  4. Composability
    • Components are meant to be interconnected
    • Components are made out of components

Transparent Boxes

Different Degrees of Reusability

  1. Black Box
    • Components only accessible through its interface.
      Implementation is kept hidden.
  2. Glass Box
    • Implementation can be inspected, but not modified.
  3. Grey Box
    • Implementation can be inspected, but only limited modification is allowed
  4. White Box
    • Implementation can be inspected and modified completely (e.g., open source)

Recursive Components

Design vs. Run-time

Why Components? REUSE

Example of Components

Where to find components?

Distributed Components

Component Roles

John Reekie, Rohan McAdam

Abstraction levels

Components vs. Objects

  • Encapsulate state and functionality
  • Coarse-grained
  • Reusable unit of composition
  • Well-defined (documented, standardized) interface contract with explicit dependencies
  • Architecture Element: Implementation not important (Black Box)
  • High Quality
  • Encapsulate state and functionality
  • Fine-grained
  • Identifiable unit of instantiation
  • Public interface optional
  • Hard to reuse by itself (lots of dependencies to other objects)
  • Object-Oriented Programming Language Typing Construct
  • At run-time can "move" between components

Components vs. Modules

  • Component Types are a unit of design encapsulation (structure of the architecture)
  • Components are instantiated at run time
  • Component have explicit interface dependencies
  • Modules are a unit of design encapsulation (package the code)
  • Modules rarely exist at run time
  • Modules may require other modules to compile

Example

Components vs. Services

Map Drawing Component

//lat, lng - any GPS coordinate on Earth
//zoom - show details up to 1m resolution
Map getMap(lat, lng, zoom)

Example

Components vs. Services

Business model: how to sell

Components vs. Services

  • Component developers charge on a per-deployment basis: whenever a new client downloads the component.
  • Component upgrades may be sold separately to generate a revenue stream
  • Components can be licensed to be redistributed within larger systems and developers can demand royalties from the revenue of the final product
  • Service providers can charge on a per-call basis: each time an existing client interacts with a service by exchanging a new message.
  • Service providers can charge a monthly/yearly flat access fee
  • Services can be made available for free and providers can support them with advertising revenue

Technology: how to use

Components vs. Services

  • Component need to be packaged to be deployed as part of some larger application system
  • Components need to be downloaded and installed, assuming they are compatible with the existing framework used to develop the system
  • Problem: There are (too) many component frameworks (J2EE, DCOM, .NET, CORBA)
  • Services need to be published on the Web by advertising their location to potential clients
  • Services are invoked using standard protocols based on XML
  • Problem: Services are distributed, remote components outside your control. Beware if they become unavailable!

Component Interoperability

It is not always possible or easy to build a system using heterogeneous components

Where to find services?

References

Use a spacebar or arrow keys to navigate