Component Based Development

1
Component Based Development

• RD SDM 1
• 2009
• Theo Schouten

2
Content

• Component Based Development, what is it
• Engineering of Component Based Software
  Development
• Domain Engineering
• Component Based Development
• Standard Software packages
• book
• chapter 30 Component-Based Software Engineering

3
Elements of CBD

• ReUse of software components
• Buy, dont develop
• Commercial off-the-shelf (COTS)
• Shift of attention
• From programming to composing
• From design to selection
• Speed of development
• Cost efficient

4
Definitions
Component Based Software Engineering (CBSE) is
changing the way software systems are developed.
CBSE embodies the buy, dont build philosophy
CBSE shifts the emphasis from programming
software to composing software systems. Implementa
tion 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
Origin

• Component-based software engineering (CBSE) is an
  approach to software development to improve
  software reuse.
• It emerged from the failure of object-oriented
  development to support effective reuse. Single
  object classes are too detailed and specific.
• Components are more abstract than object classes
  and can be considered to be stand-alone service
  providers.

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

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)
• Corba Component Model
• The component model specifies how interfaces
  should be defined and the elements that should be
  included in an interface definition.

9
Decision place
Phase 1 Definition
Phase 2 Design
Phase 3 Realize
Phase 4 Implement
Phases

• Questions
• Is COTS available to fulfill the requirements ?
• Are internally developed modules suitable?
• Are the interfaces of the components
  compatiblewith the architecture?

Steps
Documents
10
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

Make a formal difference between maintaining the
standard components and the implemented
components. For updates the standard components
are leading!
11
CBSE
Analysis Construction
Dissemination
12
Domain Engineering

• identify, construct, catalog and disseminate a
  set of software components
• that can be applied to existing and future
  software for a particular domain
• Most important functions
• Analysis, Construction and Dissemination

13
Domain Engineering Analysis

• Define the domain to be investigated
• Representative sample of applications in the
  domain
• Develop a model for the domain

14
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

15
Domain Engineering Dissemination

• Library of components
• characterization for possible reuse
• looking to various aspects for it

• Product/Technology
• Requirements Stability
• Concurrent Software
• Memory Constraints
• Application Size
• User Interface Complexity
• Programming Languages
• Safety/Reliability
• Lifetime Requirements
• Product Quality
• Product Reliability

• Process
• Process Model
• Process Conformance
• Project Environment
• Schedule Constraints
• Budget Constraints
• Productivity

• People
• Motivation
• Education
• Experience/Training
• Application domain
• Process
• Platform
• Language
• Development Team
• Productivity

16
Component Based Development

• Analysis of the particular application
• referring to the domain model
• Architectural design
• referring to the structural model
• Component qualification, adaption, composition
• possible engineer another component
• testing

17
Component qualification

• can a selected component effectively be reused?
• its interface
• development and integration tools required
• runtime requirements resources, speed, network
  protocol
• services requirements like OS interfaces and
  support of other components
• security features like access control and
  authentication protocols

18
Component adaption

• Assure that the component integrates easily in
  the architecture
• consistent methods for resource management for
  all components
• common activities for e.g. data management for
  all components
• interfaces between components and the outside
  world have been developed in a consistent way.
• use component wrapping or custom component?

19
Component composition

• assembling of qualified, adapted or engineered
  components
• Common architecture environment, elements
• Data Exchange model human-to-software, between
  components, among system resources
• Automation, tools macros and scripts
• Structured Storage, accessing heterogeneous data
  in a single data structure
• Underlying Object Model, assures interoperability

20
What are standard packages?

• developed for specific business processes
• Maintainability and scale advantages
• 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.

21
System development versus package implementation
Measure of reengineering / business value
Difference
1 on 1
reengineering obv package
innovation
Make maximal use of package for realization
vision of future (business driven, limited by
technology)
Realization vision without limitation (business
driven, real innovation, changes thinking and
action of people)
Start from the current situation, only change
when required (technology driven)
Implementation speed
BPR
What stays
Quality Management, Risk Management, Project
Management, Human Factors, etc.
22
Final remarks

• CBSE and standard packages change an
  implementation from programming to composing
  and from design to select
• Integration of modules in existing architectures
  becomes more and more important interfaces
• Custom made around the standard applications cq.
  modules becomes complex and has to be integrated
• Aspects with relation to what is leading, my
  requirement or the package become important
  issues
• Management and human factors stay the most
  important aspects for the success of a
  implementation.