Software Components
Prof. Cesare Pautasso
http://www.pautasso.info
[email protected]
@pautasso
What is a Software Component?
Hardware Component
- Reusable Unit of Composition
Software Component
- Locus of computation and state in a system
Black Box
- Encapsulation
- Clearly separate the content from the rest of the system
- Abstraction
- Hide implementation details behind the interface contract
- Modularity
- Reusable unit of assembly/deployment
- Composability
- Components are meant to be interconnected
- Components are made out of components
Transparent Boxes
Different Degrees of Reusability
- Black Box
- Components only accessible through its interface.
Implementation is kept hidden.
- Components only accessible through its interface.
- Glass Box
- Implementation can be inspected, but not modified.
- Grey Box
- Implementation can be inspected, but only limited modification is allowed
- White Box
- Implementation can be inspected and modified completely (e.g., open source)
Recursive Components
- Components are meant to be composed into larger ones
- Components (inside the black box) are made of components
- Software Architecture is Fractal (up to a certain magnification point)
- Design Decision: When to split a component? When to stop the recursion?
Design vs. Run-time
Why Components? REUSE
- Increase Productivity
- Development effort dedicated to component selection and adaptation vs. new component development
- Reduce Development Time
- Effort invested in component development is saved whenever existing components are reused
- Improve Quality
- Assuming the quality of the components can be trusted
Example of Components
- Application-specific
- Directly involved in implementing the functionality of the system
- May be difficult to reuse for other application domains
- Infrastructure
- Independent of a specific application domain, address the needs of multiple classes of applications
- Reusable, but may provide much more than what is necessary in one specific application
Where to find components?
Distributed Components
- Components can be deployed on the same physical host
- Components can be distributed over multiple physical hosts
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)- What is the "size" of this component?
- How to deliver the component to customers so that it can be included in their own applications?
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
- Doug Mc Ilroy, MASS PRODUCED SOFTWARE COMPONENTS, NATO Conference on Software Engineering, Garmisch, Germany, 7-11. October 1968
- Clemens Szyperski, Component Software : Beyond Object- Oriented Programming, 2nd Edition, Addison-Wesley, 2002 (See Chapter 11 for more definitions on components)
- George T. Heineman, William T. Councill Component-Based Software Engineering: Putting the Pieces Together, ACM Press, 2001
- David Parnas, On the Criteria to Be Used in Decomposing Systems into Modules, CACM 15(12): 1053-1058 (1972)
Use a spacebar or arrow keys to navigate