ComponentBased Software Engineering

1
Component-Based Software Engineering

• Nien L. Hsueh
• 2004

2
Outline

• Basic concept
• CBSE process
• Domain engineering
• Component-based development
• Component model
• Classifying and retrieving components
• Economics of CBSE
• Challenges of CBSE

3
Reference

• Component Based Software Engineering Putting
  the pieces together, by G.T. heineman and W.T.
  Councill, 2001
• Reuse-based Software Engineering Techniques,
  Organization, and Controls, by H. Mili, A. Mili,
  S. Yacoub and E. Addy, 2002

4
It seems clear that in the future most
softwareapplications will be assembled from
components than being constructed from scratch

• Paul Allen and Struart Frost

5
1. Basic concept

• Component-based systems are easier to assemble
  and therefore less costly to build than systems
  constructed from discrete parts
• Composition is better than construction
• Are COTS available?
• Are reusable components available?
• Are the interface (for the available components)
  compatible within the architecture of the system
  to be build?
• buy gtgt reuse gtgt build

6
What is component?

• An encapsulated, distributable software package
  with well-defined interface
• Encapsulated self-containment, providing some
  considerable functionality
• A software component is a unit of composition
  with contractually specified interfaces and whose
  context dependencies are all explicited
• contractual interface, composition
• Software components are self-contained, clearly
  identifiable pieces that describe and/or perform
  specific functions, have clear interfaces,
  appropriate documentation, and a defined reuse
  status

Different definitions have different focus
7
Conti.

• A component is a coherent package of software
  implementation that
• Can be independently developed and delivered
• Has explicit and well-specified interfaces for
  the services it provides
• Has explicit and well-specified interfaces for
  the services space it expects from others
• Can be composed with other components, perhaps
  customizing some of their properties, without
  modifying the components themselves

8
Types of component

• Component
• A non-trial, nearly independent, and replaceable
  part of a system that fulfills a clear function
  in the context of a well-defined architecture
• Run-time software component
• A dynamic bindable package of one or more
  programs managed as a unit and accessed through
  documented interfaces that can be discovered in
  run time
• Business component
• The software implements an autonomous business
  concept or business process

9
Component and Object

• If a class were packaged together with the
  explicitly defined interfaces that it requires
  and implements, then this class would be a
  component
• Components have more extensive set of
  intercommunication mechanisms than objects
• Components are often larger units of granularity
  than objects

explicitly defined interface
class
class
component
10
Interfaces of components

• An interface of a component can be defined as a
  specification of its access point
• An interface offers no implementation
• Replace the implementation part without changing
  the interface, and in this way improve system
  performance without rebuilding the system
• Add new interfaces without changing the existing
  implementation, and in this way improve the
  component adaptability
• Interfaces can express functional properties
• Components can export and import interfaces to
  and from environments that may include other
  components

client
interface implementation
ltltusegtgt
ltltrealizegtgt
11
Contracts of components

• Interfaces such as IDL are only concerned with
  the signature part
• Fail to address the overall behavior of the
  component
• A more accurate specification of a components
  behavior can be achieved through contracts
• A contract lists the global constraints that the
  component will maintain (invariant)
• For each operation within the component, a
  contract also lists the constraints that need to
  be met by the client (the precondition) and those
  the component promises to establish in return
  (the post-condition)
• Contract language

12
Pattern and component

• A pattern defines a recurring solution to a
  recurring problem
• A component, as a reusable entity, can be seen as
  an implementation of some design patterns
• Design patterns
• can be employed in the design and documentation
  of a component
• can be used to describe the low-level
  implementation details of the behavior and
  structure of the component,
• can be used to described the relationships
  between the components in the context of a
  particular programming language
• makes it easier to recognize reusable parts

JButton
ActionListener
Applying observer design pattern
13
Developing an object-oriented system is not
easy, developing a reusable object-oriented
system is much more difficult
E. Gamma, 1994
14
Framework and component

• A component models defines a set of standards and
  conventions used by the component developer,
  whereas a framework is a support infrastructure
  for the component model
• Visual basic development environment can be seen
  as a framework
• A framework can be seen as a circuit board in
  which empty position are waiting for the
  insertion of components
• Types of framework
• Technical framework MVC
• Industrial framework for a certain business area
  (accounting, GIS,)
• Application framework for a certain application
  domain (database, embedded system)

Component model
15
Interface that satisfies contract
Component-type specific interface
Component implementation
Component model
Component framework
Coordination services (transactions, persistence.)
The concept of a component-based system
16
What makes a good component?

• Well-documented
• Cohesive
• Independent (low-coupling)
• Useful
• Certified
• Composable
• Well-defined interface
• Conforming to a component model
• Secure

17
Component engineering

• To meet requirements by engineered components
• If requirements can be engineered with available
  components, we should do the activities
• Component qualification
• Does it fit to satisfy our requirements?
• Component adaptation
• Adapt the component to fit our architecture
• Component composition
• Compose the component based on the arch. style

18
2. The CBSE process
Domain Engineering
Reusable
Software
Domain
Artifact
Architecture
Analysis
Development
Development
Repository
Reusable
Domain
Structural
Artifacts/
Model
model
Components
Software Engineering
Specification
System
Construction

Analysis
Design
User
Requirements
Analysis
Application
System
Design
Software
Spec
Models
19
3. Domain Engineering

• To identify, construct, catalog, and disseminate
  a set of software components that have
  applicability to existing and future software in
  a particular application domain
• Domain engineering is about finding commonalities
  among systems to identify components that can be
  applied to many systems, and to identify program
  families that are positioned to take fullest
  advantage of those components

Domain commonalities
Application-1
Application-i
Application-2
20
Process of domain engineering

• Define the domain to be investigated
• Categorize the items extracted from the domain
• Collect a representative sample of applications
  in the domain
• Analyze each application in the sample
• Develop an analysis model for the objects

21
Are your components candidate for reuse?

• Is component functionality required on future
  implementations
• How common is the components function within the
  domain
• Is the component hardware dependent?
• Can we parameterize a non-reusable component so
  that it becomes reusable?

22
4. Component-based development

• Once the architecture has been established, it
  must be populated by components that are
• available from reuse lib
• components are qualified and adapted
• engineered to meet customers needs
• components are engineered
• Domain engineering provides the library of
  reusable components that are required for
  component-based software engineering (component
  engineering)
• The existence of reusable components does not
  guarantee that these components can be integrated
  easily or effectively into the architecture
  chosen for a new application

23
Component Qualification

• Ensure that a candidate component will perform
  the function required, will properly fit into the
  architectural style specified for the system, and
  will exhibit the quality characteristics (e.g.,
  performance, reliability, usability) that are
  required for the application
• What factors are considered during component
  qualification?
• Application programming interface (API)
• Run-time requirements, including resource usage
• Service requirements, including OS interface and
  support from other components
• Security features
• Exception handling

24
Component Adaptation

• Conflicts arise when integrating components with
  architecture
• Inconsistent methods for data management
• Inconsistent interface with arch.
• Component adaptation component wrapping
• White wrapping
• Code-level modifications to remove conflicts
• Black wrapping
• Introducing pre- and/or post-processing at the
  component interface to remove or mask conflicts
• Refer to Adapter design pattern

25
Component integrators need to discover the
function and form software components

• Alan Brown and Kurt Wallnau

26
Component Composition

• Assemble components to populate the architecture
  established for an application
• An infrastructure must be established to bind the
  components into an operational system
• The infrastructure provides a model for the
  coordination of components and specific services
  that enable components to coordinate with one
  another

27
Ingredients of component composition

• Data exchange model
• Mechanisms that enable users and applications to
  interact and transfer data should be defined for
  all reusable components
• e.g., cut and paste
• Underlying object model
• The object model ensures that components
  developed in different programming languages that
  reside on different platforms can be
  interoperable
• Object (component) must be capable of
  communicating across a network

28
5. Component (Object) Model

• An architectural style can be characterized as
• Component type
• Connector
• Communication pattern
• Semantic constraints
• A component model is an architectural style in
  nature

29
Conti.

• A component model specifies one or several
  component types and define the contracts that
  components of these types need to satisfy to
  offer their services to other components to, and
  use the services of, other components of the
  systems architected using this style

30
Control
Input
Output
Store
Shift
Sort
output
output
Architecture style
31
Things that component models should address

• Data representation
• Two components should agree on the representation
  of the data they exchange
• Data transfer
• For example, push or pull data transfer mode
• Transfer protocol
• How the data are transferred between components
• Direct invocation or event-driven interaction

32
Conti.

• State persistence
• State-less or stateful component
• Failure
• The techniques to report component failures
• Exception events or global error number
• Connection establishment
• Object reference or something else

33
Examples of component models

• CORBA
• Microsoft COM
• Sun JavaBean

34
CORBA

• CORBA Common Object Request Broker Architecture
• an architecture and specification for creating,
  distributing, and managing distributed program
  objects in a network.
• was developed by a consortium of vendors through
  the Object Management Group (OMG), which
  currently includes over 500 member companies.
• The essential concept in CORBA is the Object
  Request Broker (ORB).
• ORB provides a variety on services that enable
  reusable components to communicate with other
  components, regardless of their location within a
  system
• Both International Organization for
  Standardization (ISO) and X/Open have sanctioned
  CORBA as the standard architecture for
  distributed objects

35
Microsoft COM

• COM Component Object Model
• A component object model that provides a
  specification for using components produced by
  various vendors within a single application
  running under the Windows operation system
• Two elements
• COM interface
• A set of mechanism for registering and passing
  messages b/ COM interface
• The focus is not on how implemented, only on the
  fact that the object has an interface that it
  registers with the system, and that it uses the
  component system to communicate with other COM
  objects

36
Sun JavaBean

• JavaBean
• A portable, platform independent CBSE
  infrastructure developed using the Java
  programming
• The goal of JavaBean APIs is to define a software
  component model for Java, so that third party
  ISVs can create and ship Java components that can
  be composed together into application by end
  users
• Visual assembly or composition of existing
  components is at the origin of JavaBean component
  model

37
The next best thing to knowing something, is
knowing where to find it

• Samuel Johnson

38
6. Classifying and retrieving components

• How does a software engineer find the one she
  needs?
• How do we describe software needs?
• How do we describe software components in
  unambiguous, classifiable terms?
• Describing reusable components
• Concept
• What does a component do
• Interfaces are described
• Semantics are represented as pre-post condition
  contract
• Content
• How the concept is realized
• Hidden from users
• Context
• Specify domain of applicability

39
Classification Scheme

• Three classification scheme
• Library and information science method
• artificial intelligence
• hypertext system

40
Reuse Environment

• Component reuse must be supported by an
  environment that encompasses the following
  elements
• A component database (library)
• A library management system that provides access
  to the database
• A software component retrieval system (e.g., an
  object request broker) that enables a client
  application to retrieve components and services
  from the library
• CBSE tools that support the integration of reused
  components into a new design or implementation

41
7. Economics of CBSE

• In theory, CBSE can provide a software
  organization with advantages in quality and
  timeliness, and achieve cost saving
• Quality
• In an ideal setting, a software component that is
  developed for reuse would be verified to be
  correct and would contain no defects
• Productivity
• When reusable components are applied throughout
  the software process, less time is spent creating
  the plans, models, documents, code, and data that
  are required to create a deliverable system
• Cost

Quality
Quality
Productivity
42
8. Challenges of CBSE

• Component specification
• Component models
• Component-based software life cycle
• Composition predictability
• Trusted components and component certification
• Component configurations
• Tool support
• Dependable system and CBSE