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
Facts
[Bass, 2000]
Forecasts
Contents
[Bass, 2000]
Component-Based
Development Revenue
Component Management
Revenue
Contents
[Bass, 2000]
Contents
RC = RC0 + aiRPi, 0ai1
[Crnkovic, 2002]
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)
[Brereton, 2000]
 Demonstrating products to potential buyers
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. 3746.
[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 ComponentBased 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