reuse: an overview suddenly, the reuse and the component met each other

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]

RC = RC0 + aiRPi, 0ai1

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

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

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.

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