An Examination of software reuse: Benefits, Methods and Challenges

1. COSC 612 An Examination of software reuse:Benefits, Methods and Challenges

2. Software Reuse Introduction

3. Introduction • Software Reuse: • The creation of software systems from pre-existing components rather than building them from scratch [11]. • Conceived by Douglas McIlroy in 1968 • Has long been thought as necessary for the expedient and cost effective production of software • This is particularly important in today’s industry

4. Introduction • Software Reuse: • Despite this awareness, software reuse is still not what experts imagine it would be • Today nearly all programs utilize reuse in some way • However, large scale systematic adoption remains elusive and still presents many challenges

5. Outline • Why Software Reuse? • Needs • Benefits • Software Reuse Explained • What Can be Reused? • How is Software Reused? • Promising Developments in Reuse • Challenges and Strategies • Conclusion

6. Why Software Reuse? Needs and Benefits

7. Needs • Ever increasing demands on designers and engineers [15] • Large scale, complex software • Rapid and demanding release schedules • More emphasis on usability and value • Higher quality and customizability [3] • Increased productivity

8. Benefits • Productivity Gains • Department of Defense Workforce Analysis [1] Increase in productivity by: • • Working faster: 8 percent • • Working smarter: 17 percent • • Work avoidance: 47 percent • Return on Investment • One study [9] reported values of 210% and 400% over 8 and 10 years. • Savings over new development • Cheaper by 40% to 80% [9] • Decrease in development effort per module • Lower Fault Rates by up to 40% [9]

9. Benefits • NASA actively advocates reuse. A study[16] of their projects demonstrates time benefits.

10. Benefits • Quality Benefits from NASA study[16]

11. Benefits • Cost Benefits from DoD study[1]

12. Software Reuse Explained What Can be Reused?

13. What Can be Reused? [6]

14. Reuse of Knowledge • Reuse has grown to include knowledge and documents as well as source code [5][6] • Knowledge: Reusing solutions to problems • Architecture Patterns • Design Patterns • Requirements Reuse • Has a much greater potential than reusing source code12.

15. Reuse of Artifacts • Documents • UML standardization has facilitated the reuse of requirement, planning and design documents [12] • User Stories • State Diagrams • Sequence Diagrams • Data Flow Diagrams • Test Cases • User Manuals • Interfaces

16. Reuse of Source Code • Source Code • Most common form of reuse • Code Libraries • Code Scavenging • Recent developments in component and framework technology have made reuse easier [10] • Provides standard code for common tasks • Programmers can focus on application code rather than interface code (back end rather than front end)

17. Reuse of Source Code • Examples of framework technology • CORBA (OMG) • Middleware to allow programs in multiple languages and platforms to communicate • .NET (Microsoft) • Provides a vast library • User Interfaces • Numeric Algorithms • Database Connectivity • Web Development • Allows for interoperability across multiple languages • Java EE

18. Software Reuse Explained How is Software Reused?

19. How are these things reused? [6]

20. Reuse Techniques • Compositional • System is created from the bottom up out of components • Components ideally remain unchanged • System can be seen as glued together from parts of a component repository • Wide scope • Requires • Proper documentation • Well defined retrieval protocols

21. Reuse Techniques • Generative • Reuse system designs to generate new software • The design process or architecture is general but specific to a domain of software • Narrow scope but powerful • Application Generators • Language Generators • Takes a specific problem and generates the implementation • Transformation Systems • Semantic behavior is described, then transformations are applied to create concrete code

22. Reuse Scope and Mode • Horizontal • Pulling in software components used in wide variety of applications • Includes use of: • Software libraries • Commercial-off-the-shelf (COTS) components • Compositional in nature • Horizontal is typicallyad-hoc, or opportunistic • Components are found and used as they are needed, if they are available [11] • Can be unreliable, inconsistent or risky for large application / application families

23. Reuse Scope and Mode • Vertical • Largely untapped by current industry, but has more potential than horizontal, ad-hoc reuse [14] • Involves the creation of a product line, or a family of products with similar functionality • Vertical Reuse is Systematic and Planned • Involves developing a set of vertical assets, targeted for a specific product domain • Requires large overhead and startup, but will allow for faster creation of products in the long run [11]

24. Recent Developments in Software Reuse Software Product Lines and Domain Engineering

25. Domain Engineering • A vertical systematic process which creates reusable assets and framework for a particular product family or domain • Assets can be architectural designs and patterns as well as components • The family of products engineered from this domain is called a Software Product Line. • Developed from a common set of core assets • Each is created in a manner prescribed by the domain

26. Domain Engineering • Current examples include: • Microsoft Office • Google family (Gmail, Google Voice, Google Documents) • Code and Design are drawn upon vertically instead of horizontally • Reuse has narrower scope, but greater potential for development efficiency and profitability

27. Software Reuse Challenges and Strategies

28. Challenges and Strategies • While there is widespread ad-hoc reuse, systematic reuse remains to be an industry standard • Some factors in this include: • Organizational issues • Must have strong management support • Must have a strong organizational foundation in place to support systematic reuse • Requires a coordinated planning effort • Need for reuse often arises after several variants of software have been made

29. Challenges and Strategies • Funding • Developing reusable assets requires up front investments • Component must be reused frequently to give a return on investment • Design Time • Planning for systematic reuse often requires more time due to generality and abstractions • This will pay off later, but may be difficult at first

30. Challenges and Strategies • Planning • Must have plan for product line evolution so you don’t risk obsolescence • An upfront analysis must be done (domain engineering) to ensure the proper scope and requirements for reuse • Adopt an incremental approach to design so that components may evolve with user requirements

31. Conclusion • Software reuse has become frequently used, however in a non-systematic, informal way through code libraries, etc. • The most promising method of reuse is systematic, vertical reuse such as is found in product line approaches. • There are great benefits to such reuse, however this has yet to become standard practice in development and remains an emerging branch of software engineering.

32. References • Barry Boehm, "Managing Software Productivity and Reuse," Computer, vol. 32, no. 9, pp. 111-113, Sept. 1999, doi:10.1109/2.789755 • SlawomirDuszynski, Jens Knodel, Martin Becker, "Analyzing the Source Code of Multiple Software Variants for Reuse Potential," wcre, pp.303-307, 2011 18th Working Conference on Reverse Engineering, 2011 • N. IlkerAltintas, Semih Cetin, Ali H. Dogru, HalitOguztuzun, "Modeling Product Line Software Assets Using Domain-Specific Kits," IEEE Transactions on Software Engineering, 28 Oct. 2011. IEEE computer Society Digital Library. IEEE Computer Society. • Jacky Estublier and German Vega. 2005. “Reuse and variability in large software applications”. In Proceedings of the 10th European software engineering conference held jointly with 13th ACM SIGSOFT international symposium on Foundations of software engineering (ESEC/FSE-13). ACM, New York, NY, USA, 316-325. DOI=10.1145/1081706.1081757 http://doi.acm.org/10.1145/1081706.1081757 • Marcus A. Rothenberger, Kevin J. Dooley, Uday R. Kulkarni, Nader Nada, "Strategies for Software Reuse: A Principal Component Analysis of Reuse Practices," IEEE Transactions on Software Engineering, pp. 825-837, September, 2003 • William B. Frakes, Kyo Kang, "Software Reuse Research: Status and Future," IEEE Transactions on Software Engineering, pp. 529-536, July, 2005 • Rubén Prieto-Díaz, "Status Report: Software Reusability," IEEE Software, vol. 10, no. 3, pp. 61-66, May-June 1993, doi:10.1109/52.210605 • McIlroy, Malcolm Douglas (January 1969). "Mass produced software components". Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7-11 Oct. 1968. Scientific Affairs Division, NATO. p. 79. • ParastooMohagheghi and ReidarConradi. 2007. Quality, productivity and economic benefits of software reuse: a review of industrial studies. Empirical Softw. Engg. 12, 5 (October 2007), 471-516. DOI=10.1007/s10664-007-9040-x http://dx.doi.org/10.1007/s10664-007-9040-x • B.Jalender, DrA.Govardhan, DrP.Premchand “A Pragmatic Approach To Software Reuse”, Journal of Theoretical and Applied Information Technology (JATIT) Vol 14 No 2 pp.87-96. JUNE 2010. • Charles W. Krueger Software Reuse “ACM Computing Surveys (CSUR) Volume 24, Issue 2 (June 1992) Pages: 131 - 183. • H. Gomaa, Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures. Addison-Wesley, 2004. • J. Samentinger, Software Engineering with Reusable Components, Springer Verlag, 1997. • Boehm, B., Some Future Trends and Implications for Systems and Software Engineering Processes, Systems Engineering, vol. 9, No. 1, 2006, pp 1-19. • Selby RW. Enabling reuse-based software development of large-scale systems. IEEE Transactions on Software Engineering 2005; 31(6):495–510..