1. COSC 612

2. Software Reuse

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 I. Why Software Reuse? a. Needs b. Benefits II. Software Reuse Explained I. What Can be Reused? II. How is Software Reused? III. Promising Developments in Reuse IV. Challenges and Strategies V. Conclusion

6. Why Software Reuse?

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

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

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

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 typically ad-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

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

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 1. Barry Boehm, "Managing Software Productivity and Reuse," Computer, vol. 32, no. 9, pp. 111-113, Sept. 1999, doi:10.1109/2.789755 2. Slawomir Duszynski, 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 3. N. Ilker Altintas, Semih Cetin, Ali H. Dogru, Halit Oguztuzun, "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. 4. 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 5. 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 6. William B. Frakes, Kyo Kang, "Software Reuse Research: Status and Future," IEEE Transactions on Software Engineering, pp. 529-536, July, 2005 7. 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 8. 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. 9. Parastoo Mohagheghi and Reidar Conradi. 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 10. 11. B.Jalender, Dr A.Govardhan, Dr P.Premchand “A Pragmatic Approach To Software Reuse”, Journal of Theoretical and Applied Information Technology (JATIT) Vol 14 No 2 pp.87-96. JUNE 2010. 12. Charles W. Krueger Software Reuse “ACM Computing Surveys (CSUR) Volume 24, Issue 2 (June 1992) Pages: 131 - 183. 13. H. Gomaa, Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures. Addison-Wesley, 2004. 14. J. Samentinger, Software Engineering with Reusable Components, Springer Verlag, 1997. 15. Boehm, B., Some Future Trends and Implications for Systems and Software Engineering Processes, Systems Engineering, vol. 9, No. 1, 2006, pp 1-19. 16. Selby RW. Enabling reuse-based software development of large-scale systems. IEEE Transactions on Software Engineering 2005; 31(6):495–510..