1. Matteo Bordin mbordin@studenti.math.unipd.it Component Development Component Based SW Engineering

2. 2 Summary of contents 1.Introduction 1.Why do we need a new approach? 2.Lifecycle process models 3.Basic activities 2.Component Development 1.Building from components 2.Develop new components 3.Language and environment 4.Theory meets practice 3.Conclusions

3. 3 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 1. Introduction  Long development time  Bigger systems + many stakeholders … …

4. 4 1. Introduction (2)  Smaller systems + time to market  Basic Activities  Requirement analysis & specification  System & software design  Implementation + unit testing  System integration  Verification & Validation  Maintenance  Disposal 1. Introduction  Evolutionary: iterative, spiral model  parallel activities

5. 5 2. Component development  CBSE challenges  Similar to those typical of software engineering  Known methods, principles, tools are still valid. But… 2. Component development  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. 6 Requirement System design AdaptTest System integr. System test Maintenance Select 2.1 Building FROM components  A new V model Find Evaluate  Simplistic! What if:  No components to select  Adaptation cost is too high  Malfunction during maintenance No unit design/ dev./testing 2.1 Building from components

7. 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 Inspect Component pool System design Inspect Implementation… Available components

8. 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 Select Test Adapt Component pool …Design Integration…

9. 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. 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 Select Test Adapt MaintenanceDeployment } V&V (again…)  Conclusions  Less effort on implementation  Greater costs of verification & testing …System test

11. 11 2.2 Building NEW components  Develop new components:  Follow an arbitrary (modified) process model  Not only functionality but also REUSE! 2.2 Building new components REUSE FlexibilityPortability Generality Additional functions Understanding More formal documentation Test different configurations … … Well trained team 3 rd party integration Adapters

12. 12 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 2.2.1 COP

13. 13 2.2.1 COP: Methodology and problems to face  Specification of provided/required interface(s)  Comprehensive of non functional requirements: interaction protocols, WCET, memory… 2.2.1 COP  Consistence during events propagation  Multithreading:  Avoid deadlock by transactional programming  Queue invocations and process it in a defined moment Queued invocations post request get request to fulfill CallerCalled

14. 14 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 2.2.1 COP 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 };

15. 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. 16 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. 17 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. 18 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 3. Conclusions

19. 19 Questions ?

20. 20 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.orgwww.swebok.org  The Catalysis method: www.catalysis.orgwww.catalysis.org Additional references