Upload
osborn
View
28
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Reuse: An Overview. Suddenly, The Reuse and The Component met each other. Contents. A bit of history The market Forecasts Issues ar ose Problems and directions. A bit of history. At the beginning. NATO Conference in 1968 [McIlroy, 1968] Mass produced software components by MCILROY - PowerPoint PPT Presentation
Citation preview
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