1. Reuse: An Overview Suddenly, The Reuse and The Component met each other

2. Contents  A bit of history  The market  Forecasts  Issues arose  Problems and directions

3. A bit of history

4. At the beginning...  NATO Conference in 1968 [McIlroy, 1968] Mass produced software components by MCILROY Software components as routines Software should be produced in a industrialized way Software should be produced according to certain criteria Waste of software writing techniques

5. Some time ago...  Software industry continues to achieve effective reuse  Workshop on CBSE held in conjunction with the 20th International Conference on Software Engineering [Brown, 1998] Discussion ranged from theory to market Divergent perspectives at times threatened to blur CBSE´s conceptual outlines

6. Some time ago...  “CBSE is a coherent engineering practice, but we still haven´t fully identified just what it is” [Brown, 1998]  During 80s, early 90s many approaches tried to address improvements in quality, flexibility, and maintainability of application systems

7. Late 90s  Components became a tremendous topic of interest [Meyer, 1999] Software development was in trouble The kind of breakthrough needed could only be achieved from reusing other´s people creation  To improve productivity reuse appears to be the solution, reuse of software component has obvious appeal

8. From late 90s to nowadays  There are many attempts to define component  Many papers include some of the terms below in their definitions "A software component is a unit of composition with contextually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition." (Clemens Szyperski)

9. From late 90s to nowadays  Why components now? To address some development problems as reduce time-to-market, improve productivity Because now underlying technologies have matured

10. The market

11. Facts  Reuse of components had became a very popular matter  Along the later years the software industry/market and academy had shared a common interest in component  Components technologies such as ActiveX, VBX, Corba, EJB, and JavaBeans had dominated new applications development

12. Facts  IT becomes more critical to business performance  Demand for more and better quality software becomes more pronounced  Software frequently becomes the limiting factor in corporate competitiveness [Bass, 2000]

13. Facts  ERPs have taken much of the world of management information systems. But they have been complained about their price, heaviness, monolithic nature, and so forth  Only through components can the ERPs systems of the future continue to compete  ERPs give components a chance to affect the vary heart of business systems

14. Facts  Most of the interest in software component technology is linked to the perception that it can meet the demands below: Improve programmer productivity and reduce time-to-market Produce systems that are flexible enough to withstand technology and business changes Produce systems that deliver excellent performance and are scalable, secure, and robust

15. Facts [Bass, 2000]

16. Forecasts

17. Contents [Bass, 2000]

18. Contents [Bass, 2000] Component-Based Development Revenue Component Management Revenue

19. Contents [Crnkovic, 2002] R C = R C0 +  a i R Pi, 0  a i  1

20. Contents [Crnkovic, 2002]

21. Issues arose

22. Software Product Issues Viewed from the perspectives of:  Component providers Granularity Portability  Component Integrators Component selection(evaluate against requirements) Interoperability (architecture mismatch, functional deficiencies, quality maintenance) Combining quality attributes Maintenance over distributed components [Brereton, 2000]

23. Software Product Issues  Commmon needs Predicting limits (i.e. 32 bits problem) Component description to locate, understand and evaluate  Integrated systems customers (Should supply well specified requirements) [Brereton, 2000]

24. Software Development Process Issues can affect one or all viewpoints.  Component providers Internationalization Testing practices (make dependencies explicit)  Component Integrators Requirements and component capabilities trade-offs. Tool support for component evaluation Demands for change (from both customers and providers)  Commmon needs Long term support Responsibility chain [Brereton, 2000]

25. Business Issues  Component providers Internationalization (on global market- encryption, advertising reg. etc) Responsibility for quality (limit level of responsibility) Horizontal versus vertical market Marketability  Component Integrators New business opportunities (cheap, well supported products) Managing a range of contractual styles (different national regulations) Demonstrating products to potential buyers [Brereton, 2000]

26. Business Issues  Component Integrators Trade-offs (accept an existing component or build an ideal one) Measuring productivity (new productivity models needed)  Commmon needs Component redundancy Payment Distributed execution Security and certification  Integrated systems customers (reliable and well maintained products) [Brereton, 2000]

27. Business Issues [Brereton, 2000]

28. Problems and directions

29. Contents

30. Concern About System Quality Attribute

31. Inhibitors  Lack of Available Components  Lack of Stable Component Technology Standards  Lack of Certified Components  Lack of Component-Based Engineering Methods

32. People in Software Development Viewed from the perspectives of:  Component providers  Component Integrators Evaluators Management  Commmon needs  Integrated systems customers [Vitharana, 2003], [Brereton, 2000]

33. Directions

34.  COTS  Horizontal X Vertical Domains  Certification  Prediction of system properties  Need of specific software engineering methods and processes

35. Conclusion  Several themes require further research Evaluation Maintenance Interaction and integration of commercial and technical factors Aggregation rules Quality Assurance

36. Any question?

37. References [McIlroy, 1968] M. D. McIlroy, Mass Produced Software Components, NATO Software Engineering Conference Report, Garmisch, Germany, October, 1968, pp. 79-85. [Brown, 1998] A. L. Brown, K. C. Wallnau, The Current State of CBSE, IEEE Software, Vol. 15, No. 05, September, 1998, pp. 37- 46. [Meyer, 1999] B. Meyer, On To Components, IEEE Computer, Vol. 32, No. 01, January, 1999, pp. 139-143. [Meyer, 1999] B. Meyer, C. Mingins, Component-Based Development: From Buzz to Spark, IEEE Computer, Vol. 32, No. 07, July, 1999, pp. 35-37.

38. References [Bass, 2000] L. Bass, C. Buhman, S. C. Dorda, F. Long, J. Robert, R. Seacord, K. Wallnau, Market Assessment of Component- Based Software Engineering, Technical Report, Software Engineering Institute (SEI), May, 2000, pp. 41. [Brereton, 2000] P. Brereton, D. Budgen, Component-Based Systems: A Classification of Issues, IEEE Computer, Vol. 33, No. 11, November, 2000, pp. 54-62. [Bachmann, 2000] F. Bachmann, L. Bass, C. Buhman, S. C. Dorda, F. Long, J. Robert, R. Seacord, K. Wallnau, Volume II: Technical Concepts of Component-Based Software Engineering, Technical Report, Software Engineering Institute (SEI), May, 2000, pp. 65.

39. References [Long, 2001] J. Long, Software Reuse Antipatterns, Software Engineering Notes, Vol. 26, No. 04, July, 2001, pp. 68-76. [Crnkovic, 2002] I. Crnkovic, M. Larssom, Challenges of component-based development, Journal of Systems and Software, Vol. 61, No. 03, April, 2002, pp. 201-212. [Vitharana, 2003] P. Vitharana, Risks and Challenges of Component-Based Software Development, Communications of the ACM, Vol. 46, No. 08, August, 2003, pp. 67-72. [Almeida,2004] E. S. Almeida, et al., Key Developments in the field of software reuse, 2004