Component Development

1
Component Development

• Component Based SW Engineering

2
Summary of contents

1. Introduction
2. Why do we need a new approach?
3. Lifecycle process models
4. Basic activities
5. Component Development
6. Building from components
7. Develop new components
8. Language and environment
9. Theory meets practice
10. Conclusions

3
1. Introduction
1. Introduction

• Why do we need a new approach?
• Technology is not enough
• Need to change the development life cycle
• Lifecycle process models
• Sequential waterfall, V model Þ sequential
  activities

• Long development time
• Bigger systems many stakeholders

4
1. Introduction (2)
1. Introduction

• Evolutionary iterative, spiral model Þ parallel
  activities

• Smaller systems time to market
• Basic Activities
• Requirement analysis specification
• System software design
• Implementation unit testing
• System integration
• Verification Validation
• Maintenance
• Disposal

5
2. Component development
2. Component development

• CBSE challenges
• Similar to those typical of software engineering
• Known methods, principles, tools are still valid.
  But

• 2 different processes
• Building a system from existing components
• Develop new and reusable components

• Building a system FROM components
• The main idea behind CBSE!
• FOCUS find evaluate components
• No classic unit design/development/testing
• Effort on locating adapting components

6
2.1 Building FROM components
2.1 Building from components

• A new V model

Maintenance
Requirement
System test
No unit design/ dev./testing
System design
System integr.
Adapt
Test
Select

• Simplistic! What if
• No components to select
• Adaptation cost is too high
• Malfunction during maintenance

Evaluate
Find
7
2.1 Building FROM components (2)
2.1 Building from components

• Component approach affects the entire life cycle!
• Requirements if not fulfilled by existing
  components
• Plan to develop new component or
• (Re)Negotiate requirements
• System design driven by chosen component
  model/technology

Requirements
System design
Inspect
Implementation
Inspect
Component pool
Available components
8
2.1 Building FROM components (3)
2.1 Building from components

• Implementation
• Select components
• Connect components implement new functions
  glue code
• Connected components a new concept of unit
• (Unit) Testing
• Existing component already tested in isolation
• Test connected components Þ testing glue code

Integration
Design
Select
Test
Adapt
Component pool
9
2.1 Building FROM components (4)
2.1 Building from components

• System integration
• Deploy the component in existing framework
• Download register new component
• Verification and validation
• Standard techniques but
• Locate errors exhibited by black-box components
• Errors lie in other components Þ check
  contractual interfaces
• 3 different phases of verification
• Component in isolation
• Component in an assembly
• System with deployed components

10
2.1 Building FROM components (4)
2.1 Building from components

• Support maintenance
• A new component can be deployed
• Newer versions must be tested and integrated
• Change glue code

VV (again)
Maintenance
Deployment
System test
Select
Test
Adapt

• Conclusions
• Less effort on implementation
• Greater costs of verification testing

11
2.2 Building NEW components
2.2 Building new components

• Develop new components
• Follow an arbitrary (modified) process model
• Not only functionality but also REUSE!

Additional functions
Generality
Test different configurations
REUSE
Flexibility
Portability
More formal documentation
Understanding
Well trained team
3rd party integration
Adapters


12
2.2.1 Component oriented programming (COP)
2.2.1 COP

• A new methodology, not fully addressed
• Support of
• Polymorphism
• Modular encapsulation
• Late binding loading
• Type/module safety
• Works within a single component
• Interactions between components not covered
• Connection oriented programming

13
2.2.1 COP Methodology and problems to face
2.2.1 COP

• Specification of provided/required interface(s)
• Comprehensive of non functional requirements
  interaction protocols, WCET, memory

• Consistence during events propagation

• Multithreading
• Avoid deadlock by transactional programming
• Queue invocations and process it in a defined
  moment

Caller
Called
post request
get request to fulfill
Queued invocations
14
2.2.1 COP Problems to face (2)
2.2.1 COP

• Limits of (most) available languages
• Avoid implementation inheritance clumsy if minor
  adaptation is needed
• Group method in many little interfaces
• (Automatically generated) forwarder class
• Template (compile-time code generation)
• Proxy classes and reflection (Java, C)
• Provide nutshell class impl. inheritance of
  whitebox classes

abstract class Nutshell implements
I ClassToForward c new ClassToForward() //fo
rward each method m() to c.m() class MyClass
extends Nutshell //override only methods of
interest
15
2.2.1 COP Problems to face (3)
2.2.1 COP

• Accessibility of provided interface
• No languages distinguish pure outgoing and
  ingoing interfaces (apart Component Pascal)
• Dangerous to call methods from outside a
  protected domain
• package java.lang
• class MyClass
• void m(AnotherClass obj)
• obj.finalize()

This should be done by the gc only!
16
2.3 Language and environment
2.3 Language and environment

• Programming language
• Need for polymorphism, late binding,
  encapsulation, safety (COP) Þ use OO languages
  (at the moment)
• C, C, Cobol, Eiffel, Smalltalk lack something
• Java, C, Ada 95(2005) are reasonable choice
• Java too weak package system
• C events, connection, module access protection
  (assembly)

• Environment choose a framework carefully
• Divorce is almost impossible
• Difficult to combine different frameworks
• Migration is even harder

17
2.4 Theory meets practice
2.4 Theory meets practice

• Develop a new system
• Pure top-down not meet existing component
• Pure bottom-up not meet requirements
• Use existing develop new components
• Separate system and components dev. across teams
• Synchronize teams
• Late discovery of errors insufficient
  documentation
• Which component should satisfy a requirement?
• Difficult to perform processes independently
• Need for a structured organization focusing on
• Architectural issues
• Non productive processes (testing, quality)

18
3. Conclusions
3. Conclusions

• Technology is not enough
• Change the development and life cycle process
• 2 distinct processes
• Building from components
• Focus on selecting existing components and
  testing
• A new V model
• Building new components
• Focus on reuse (generality, flexibility,
  quality)
• Component oriented programming
• Real project component reuse development
• Effort on verification and quality assurance
• Structured organization

19
Questions
?
20
Additional references
Additional references

• Component Development for the Java platform by
  Stuart Dabbs Halloway, ed. Addison Wesley
• Software Engineering Body Of Knowledge
  (SWEBOK), available at www.swebok.org
• The Catalysis method www.catalysis.org