Transcript Shop presentation - Institute for Computing and

Component Based Development
R&D SDM 1
2009
Theo Schouten
-1-
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
-2-
Elements of CBD
• ReUse of software components
• Buy, don’t develop
– ‘Commercial off-the-shelf’ (COTS)
• Shift of attention:
– From programming to composing
– From design to selection
• Speed of development
• Cost efficient
-3-
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
-4-
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.
-5-
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.
-6-
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
-7-
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.
-8-
Documents
Steps
Phases
Decision place
Phase 1
Definition
Phase 2
Design
Phase 3
Realize
Phase 4
Implement
Questions:
- Is COTS available to fulfill the requirements ?
- Are internally developed modules suitable?
- Are the interfaces of the components compatible
with the architecture?
Vaststellen
Systeem
Behoeften
Definitie studie
Haalbaarheidsstudie
Haalbaarheids
Rapport
Functioneel
Ontwerp
No
Functionele
Specificatie
Requirements
Analysis
Technisch
Ontwerp
Technische
Specificatie
Yes
Component Based Development
-9-
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!
- 10 -
CBSE
Analysis
Construction
Dissemination
Domain Engineering
Software
Architecture
Development
Domain
Analysis
Domain
Model
ReUsable
Component
Development
Repository
ReUsable
Components
Structural
Model
Component Based Development
Component
Qualification
Analysis
Architecture
Design
Component
Update
Component
Adaptation
Component
Engineering
Application
Software
Component
Composition
Testing
- 11 -
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
- 12 -
Domain Engineering Analysis
• Define the domain to be investigated
• Representative sample of applications in the domain
• Develop a model for the domain
- 13 -
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
- 14 -
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
- 15 -
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
- 16 -
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
- 17 -
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?
- 18 -
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 macro’s and scripts
– Structured Storage, accessing heterogeneous data in a
single data structure
– Underlying Object Model, assures interoperability
- 19 -
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.
- 20 -
System development versus package
implementation
Measure of reengineering / business value
1 on 1
reengineering
obv package
innovation
Start from the
current situation,
only change when
required
(technology
driven)
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)
Implementation speed
BPR
Quality Management, Risk Management, Project Management,
Human Factors, etc.
- 21 -
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.
- 22 -