Component Based Development
Component Based Development
Component Based Development
-1-
Elements of CBD
-2-
History
• functions (subroutine) in first “high level” programming
languages, provided reuse in libraries
– LINPACK, EISPACK (1970’s), LAPACK (1992-now)
• Object Oriented languages
– reuse of classes and sets thereof
• 1968 Douglas McIlroy “Mass Produced Software Components”
– leaded to pipes and filters in Unix
• 1986 Brad Cox Objective-C
– strict superset of C with Smalltalk-style messaging
– Steve Job, NEXT, Mac OS X, Cocoa API
– became very popular last year (see TIOBE)
-3-
Origin CBD (or CBSE)
-4-
Definitions
‘Component Based Software Engineering (CBSE) is
changing the way software systems are developed. CBSE
embodies the ‘buy, don’t build’ philosophy……
CBSE shifts the emphasis from programming software to
composing software systems.
Implementation has given way to integration as the focus.
At its foundation is the assumption that there is sufficient
commonality in many large software systems to justify
developing reusable components to exploit and satisfy that
commonality’
Clements 1995
-5-
What is a Component?
• OMG Unified Modeling Language Specification [OMG01]
defines a component as
– “… a modular, deployable, and replaceable part of a
system that encapsulates implementation and exposes a
set of interfaces.””
• OO view: a component contains a set of collaborating
classes
• Conventional view: a component contains processing logic,
the internal data structures that are required to implement
the processing logic, and an interface that enables the
component to be invoked and data to be passed to it.
-6-
CBSE essentials
• Independent components specified by their interfaces.
• Component standards to facilitate component integration.
• Middleware that provides support for component
interoperability.
• A development process that is geared to reuse.
-7-
Design principles
• Components are independent, no interference
• Component implementations are hidden
• Communication is through well-defined interfaces
• Container: service provider for locating and getting
component interface
Implementation
Interface
Component
Container
-8-
Component models
• A component model is a definition of standards for
component implementation, documentation and
deployment.
• Examples of component models
– EJB model (Enterprise Java Beans)
– COM+ model (.NET model)
– OMG Corba Component Model
• The component model specifies how interfaces should be
defined and the elements that should be included in an
interface definition.
-9-
OMG/ CORBA
• The Object Management Group has published a common object
request broker architecture (OMG/CORBA).
• An object request broker (ORB) provides services that enable
reusable components (objects) to communicate with other
components, regardless of their location within a system.
• Integration of CORBA components (without modification)
within a system is assured if an interface definition language
(IDL) interface is created for every component.
• Objects within the client application request one or more
services from the ORB server. Requests are made via an IDL or
dynamically at run time.
• An interface repository contains all necessary information about
the service’s request and response formats.
- 10 -
Sun JavaBeans
• The JavaBeans component system is a portable, platform
independent CBSE infrastructure developed using Java
• It encompasses a set of tools, called the Bean Development
Kit (BDK), that allows developers to
– analyze how existing Beans (components) work
– customize their behavior and appearance
– establish mechanisms for coordination and communication
– develop custom Beans for use in a specific application
– test and evaluate Bean behavior.
- 11 -
Microsoft COM
• The component object model (COM) provides a
specification for using components produced by various
vendors within a single application running under the
Windows operating system.
• COM encompasses two elements:
– COM interfaces (implemented as COM objects)
– a set of mechanisms for registering and passing
messages between COM interfaces.
- 12 -
Engineering of CBS
• This should fill in the following aspects:
– Identifying the components which are candidates for
implementation
– Qualifying the interfaces of the components
– Adapting of the components to the architecture
– Updating of the components due to changes in the requirements.
• CBSE Process:
– Domain Engineering: Library Function
– Component Based Development: Implementation Function
- 14 -
Domain Engineering Analysis
- 15 -
Domain Engineering Construction
• Selection of function or object
• Reuse?:
– Is the functionality needed for future implementations?
– What is the degree of reusability (commonality)?
– Is there a duplication of the functions in the domain?
– Is the component hardware dependent?
– Is the design optimal for future implementations?
– Can a non-reusable component be re-parameterized such that it
becomes reusable?
– Is it useful to decompose or re-parameterize a component for
reuse?
• construct a structural model
- 16 -
Domain Engineering: Dissemination
• Library of components
• characterization for possible reuse
• looking to various aspects for it
Product/Technology
Product/Technology Process People
People
- Requirements Stability Process - Motivation
- Requirements Stability - Process Model - Motivation
- Process Model
- -Concurrent
ConcurrentSoftware
Software - -Process - -Education
Education
- -Memory Constraints ProcessConformance
Conformance - -Experience/Training
Memory Constraints - -Project Environment
Project Environment Experience/Training
- -Application
ApplicationSize
Size - -Schedule - -Application
Applicationdomain
domain
- -User ScheduleConstraints
Constraints - -Process
User InterfaceComplexity
Interface Complexity - -Budget
BudgetConstraints
Constraints Process
- -Programming
ProgrammingLanguages
Languages - -Productivity - -Platform
Platform
- -Safety/Reliability Productivity - -Language
Safety/Reliability Language
- -Lifetime
LifetimeRequirements
Requirements - -Development
DevelopmentTeam
Team
- -Product Quality
Product Quality - -Productivity
Productivity
- -Product
ProductReliability
Reliability
- 17 -
Component Based Development
- 18 -
Component qualification
- 19 -
Component adaption
- 20 -
Component composition
- 21 -
CBSE problems
• Component trustworthiness - how can a component with no
available source code be trusted?
• Component certification - who will certify the quality of
components?
• Emergent property prediction - how can the emergent
properties of component compositions be predicted?
• Requirements trade-offs - how do we do trade-off analysis
between the features of one component and another?
- 22 -
Ariane launcher failure
• In 1996, the 1st test flight of the Ariane 5 rocket ended in
disaster when the launcher went out of control 37 seconds
after take off.
• The problem was due to a reused component from a
previous version of the launcher (the Inertial Navigation
System) that failed because assumptions made when that
component was developed did not hold for Ariane 5.
• The functionality that failed in this component was not
required in Ariane 5.
- 23 -
Standard packages
• SAP, Oracle, Peoplesoft, etc.
• developed for specific business processes;
• Strong development in the last years (shift from custom
made to standard packages);
• ‘Enabler’ of working in a process way (BPR);
• ‘Best practice’ business processes build in;
• Started in the ERP environment (‘Enterprise Resource
Planning’) = primary business processes, extended to many
other environments
• large changes in methodology for implementation of
software systems.
- 24 -