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

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

A bit of history

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

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

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

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

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)

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

The market

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

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]

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

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

Facts [Bass, 2000]

Forecasts

Contents [Bass, 2000]

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

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

Contents [Crnkovic, 2002]

Issues arose

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]

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]

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]

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]

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]

Business Issues [Brereton, 2000]

Problems and directions

Contents

Concern About System Quality Attribute

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

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

Directions

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

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

Any question?

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

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 [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.

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