Please enable JavaScript.
Coggle requires JavaScript to display documents.
COMPONENT-BASED SOFTWARE ENGINEERING - Coggle Diagram
COMPONENT-BASED SOFTWARE ENGINEERING
LEGO analogy
Set of building blocks different shapes and colors
Can be combined in different ways
Composition through small stubs in one and corresponding holes in another building block
Why CBSE?
increase quality, especially evolvability and maintainability
increase productivity
Shortens development time
Components Model
Defines the types of building block, and the recipe for putting them together
more precisely, a component model defines standard for properties individual component must satisfy, methods and mechanism for composing component
Consequently, a component has to conform to some component model
A software component
implements some functionality
has explicit dependencies through provides and required interfaces
communicate through its interfaces only
Has structure and behavior that conforms to component model
A component technology
the implementation of a component model by mean of standard and guideline for the implementation and execution of software components
Examples: EJB, COM+, NET, CORBA
Component forms
components goes through different stages: development, packaging, distribution, deployment, execution
across these stages, components are represented in different forms
Example:
During development
: UML,
When packaging
: in zip file,
In execution stage
: blocks of code and data
Characteristic of components forms
Component Meta-data
describe information about the component
Component packaging
: bundle : information about the component
Component interfaces
: defines actions for interacting run-time
Component specification
: specifies functional & extra-functional properties
Component Implementations
: Implementation of the specification
Component instance
: Instance of the implementation in a device
Component specification vs Component interface
Specifications
describe properties to be realized: realization contract while
interface
describe how component interacts: usage contract
Different scope as well :
specification
is about the component as a whole, while
interface
might be about part of a component only
Hiding of components internals
Black box: only specification is known
Glass box: internals may be inspected, but not changes
Grey box: part of the internals may be inspected, limited modification is allowed
white box: component is open to inspection and modification
Managing quality in CBSE
Who manages the quality: the component, or the execution platform
Scope of management: per-collaboration, or system-wide
Common features of components models
Infrastructure mechanism, for binding, execution, etc
Instantiation
Binding
Mechanism for communication between components
Discovery of components
Announcement of component capabilities (interfaces)
Language independence
Platform independence
Analysis support
Support for upgrading and extension
Support for quality properties
Development process in CBSE
Two separate development processes:
-Development of components
-Development of systems out of components
Separate process to assess components
CBSE system development process
Requirements: also considers availability of components (like in COTS)
Analysis and design: very similar to what we normally do
Implementation: less coding, focus on selection of components, provision of glue code
Integration: largely automated
Testing: verification of components is necessary
Release: as in classical approaches
Maintenance: replace components
Component assessment
Find component
Verify Component
Store components in repository
Component development process
Components are intended for reuse
Managing requirements is more difficult
More effort required to develop reusable components
More effort in documentation for consumers
Component development process
Implementation: largely determined by component technology
Testing: extensive (no assumptions of usage!), and well-documented
Analysis and design: generality is an issue, assumptions about system (use) must be made
Release: not only executables, also metadata
Requirements: combination of top-down (from system) and bottom-up (generality)
Architecture and CBSE
Product line: family of similar products, with 1 architecture
COTS-based: bottom-up, architecture is secondary to components found
Architecture-driven: top-down: components are identified as part of an architectural design
Summary
To enable composition, components must be compatible: achieved by component model
Separation of development process for components from that of assembling systems out of components
Architectural plan organizes how components fit together and meet quality requirements