Component
Development
Component Based SW Engineering
Matteo Bordin
[email protected]
Summary of contents
1. Introduction
1. Why do we need a new approach?
2. Lifecycle process models
3. Basic activities
2. Component Development
1.
2.
3.
4.
Building from components
Develop new components
Language and environment
Theory meets practice
3. Conclusions
2
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
3
1. Introduction
1. Introduction (2)
 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
4
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
5
2.1 Building from components
2.1 Building FROM components
 A new V model
Requirement
Maintenance
System design
Select
Evaluate
Find
System test
No unit design/
dev./testing
System integr.
Adapt
Test
 Simplistic! What if:
 No components to select
 Adaptation cost is too high
 Malfunction during maintenance
6
2.1 Building from components
2.1 Building FROM components (2)
 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
Implementation…
Inspect
Inspect
Component pool
Available components
7
2.1 Building from components
2.1 Building FROM components (3)
 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
8
2.1 Building from components
2.1 Building FROM components (4)
 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
9
2.1 Building from components
2.1 Building FROM components (4)
 Support & maintenance
}
 A new component can be deployed
 Newer versions must be tested and integrated
 Change glue code
Maintenance
Deployment
Select
Test
V&V (again…)
…System test
Adapt
 Conclusions
 Less effort on implementation
 Greater costs of verification & testing
10
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
REUSE
Well trained team
Test different
configurations
Flexibility
Portability
Understanding
More formal
documentation
3rd party
integration
Adapters
…
…
11
2.2.1 COP
2.2.1 Component oriented
programming (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
12
2.2.1 COP
2.2.1 COP: Methodology and
problems to face
 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
post
request
get request
to fulfill
Called
Queued
invocations
13
2.2.1 COP
2.2.1 COP: Problems to face (2)
 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();
//forward each method m() to c.m()
};
class MyClass extends Nutshell{
//override only methods of interest
};
14
2.2.1 COP
2.2.1 COP: Problems to face (3)
 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!
15
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…
16
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)
17
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
18
Questions
19
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
20
Descargar

Component Developement