- 1 - Component Based Development R&D SDM 1 2009 Theo Schouten.
-
date post
21-Dec-2015 -
Category
Documents
-
view
217 -
download
1
Transcript of - 1 - Component Based Development R&D SDM 1 2009 Theo Schouten.
- 1 -
Component Based Development
R&D SDM 1
2009Theo 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, don’t 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, 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 -
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
ContainerContainer
Component
Implementation
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 1Definition
Phase 1Definition
Phase 2Design
Phase 2Design
Phase 3Realize
Phase 3Realize
Phase 4Implement
Phase 4Implement
Ph
ase
sS
tep
sD
ocu
men
ts
VaststellenSysteem Behoeften
Definitie studie
Requirements Analysis
FunctioneelOntwerp
Functionele Specificatie
Haalbaarheids-studie
HaalbaarheidsRapport
Technisch Ontwerp
Technische Specificatie
No
Yes Component Based Development
Questions:- Is COTS available to fulfill the requirements ?- Are internally developed modules suitable?- Are the interfaces of the components compatiblewith the architecture?
- 10 -
Engineering of CBS
Make a formal difference between maintaining the ‘standard’ components and the implemented components. For updates the standard components are leading!
• 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
- 11 -
Domain Engineering
Domain Analysis
Domain Analysis
SoftwareArchitectureDevelopment
SoftwareArchitectureDevelopment
ReUsableComponent
Development
ReUsableComponent
Development
DomainModel
DomainModel
StructuralModel
StructuralModel
Component
LibraryRepositoryReUsable
Components
Component Based Development
AnalysisAnalysis Architecture Design
Architecture Design
ComponentComposition
ComponentComposition
ComponentUpdate
ComponentUpdate
ComponentAdaptation
ComponentAdaptation
ComponentQualification
ComponentQualification
ComponentEngineering
ComponentEngineering
TestingTesting
ApplicationSoftware
Component
Implementatio
n
CBSEAnalysis 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
Product/Technology- Requirements Stability- Concurrent Software- Memory Constraints- Application Size- User Interface Complexity- Programming Languages- Safety/Reliability- Lifetime Requirements- Product Quality- Product Reliability
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
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
People- Motivation- Education- Experience/Training
- Application domain- Process- Platform- Language
- Development Team- Productivity
• Library of components
• characterization for possible reuse
• looking to various aspects for it
- 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 macro’s 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
Make maximal use of package for
realization vision of future
(business driven, limited by
technology)
Start from the current situation,
only change when required
(technology driven)
Realization vision without limitation
(business driven, real innovation, changes
thinking and action of people)
1 on 1reengineeringobv package innovation
Implementation speed
BPR
Difference
Quality Management, Risk Management, Project Management, Human Factors, etc.
What stays
- 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.