Reuse: An Overview

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. Component Management Revenue Component-Based Development Revenue Contents [Bass, 2000]

19. Contents RC = RC0 + aiRPi, 0ai1 [Crnkovic, 2002]

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. Directions • 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