Software Reuse (Lecture 15)

1. Software Reuse (Lecture 15) Dr. R. Mall

2. Organization of this Lecture • Introduction • Basic issues • Domain analysis • Reuse at organization level • Summary

3. Introduction • Software is becoming very expensive: • a possible way to reduce cost: • reuse parts from previously made software. • assemble software from off-the-shelf components.

4. Introduction • Advantages of reuse also include: • reduced number of defects: • standard and well-tested components are reused. • reduced development time: • provide early market access for products.

5. Software reuse • Software development with reuse: • similar to an electronic engineer building an electronic circuit: • uses standard types of electronic ICs and other components.

6. What can be reused? • Specification • Design • Code • Test cases • At the most abstract level: • knowledge

7. Reuse of Knowledge • More difficult compared to day-to-day reuse of knowledge: • developers vary over time and over projects • difficult to remember details of potentially reusable development knowledge.

8. Why almost no software reuse so far? • Engineers working in industry often have a frustrated feeling: • current system is similar to last few systems they have already built • everything is being built from scratch • current system is behind schedule: • no one has time to figure out what this similarity really means.

9. A major problem • Creation of components reusable in different applications: • other than the application for which these were originally designed. • Very difficult to identify right kind of reusable information: • and to make them available to the user.

10. Another complaint • In spite of having software components available for reuse: • programmers have preferred to create their own, because: • available components are difficult to understand • difficult to adapt to new application

11. Libraries of software components • No one in his right mind: • would think of writing a routine to compute sine or cosine. • By investigating the question: • why reuse of mathematical functions is so easy? • several interesting aspects emerge

12. Libraries of software components • Standard terminology and concepts: • cosine means same to all • what arguments it takes, what it does. • Small interface: • exactly one number needed to compute cosine • Standardized data format

13. Basic Issues in Software Reuse • Component creation • Component indexing • Search • Understanding • Adaptation • Repository maintenance

14. Basic Issues • Component creation: • Identify reusable components • Component indexing: • classification of reusable components • so that they can be easily searched when we look for a component to reuse.

15. Basic Issues • Search: • search for right components in a database of components • requires a proper method to describe components

16. Basic Issues • Understanding: • to decide whether we can use some component • we need a precise and sufficiently complete understanding of what the component does.

17. Basic Issues • Adaptation: • A selected component may not exactly fit the problem at hand • Tinkering with the code is not satisfactory: • in any case justified only if thoroughly understood

18. Basic Issues • Repository maintenance: • component entering • tracking faulty components • new applications emerge • older applications become obsolete • components might need changes • obsolete components might have to be removed

19. A possible reuse approach • Introduce building block approach into the production process. • identify reusable components after development finishes • enhance reusability of the identified reusable components • catalogue into a component library.

20. Domain analysis • Aim: • identify reusable components for a problem domain. • identification of right kind of reusable information is a difficult problem.

21. Reuse Domain • A body of information • considered to be a problem domain for reuse if: • a deep and comprehensive relationship exists among information items : • characterized by patterns of similarity among software products.

22. Reuse Domain • A domain is a shared understanding of some community: • technical knowledge of some problem area. • characterized by notations that show coherence • examples of domains: • accounting software • banking software • business presentation software

23. Reuse Domain • Just to become familiar with the vocabulary of a domain: • requires months of interaction with experts • often one needs to be familiar with a network of related domains

24. Domain analysis • Domain analysis identifies: • objects, operations and relationship among them. • Consider airline reservation: • objects are • seats, flights, airports, crew, meal orders • Operations are • scheduling a flight, reserving a seat, assigning a crew to a flight, etc.

25. Domain analysis • Generalizes an application domain: • a domain model transcends specific applications. • Common characteristics of similar systems are generalized.

26. Domain analysis • Domain analysis is a more difficult problem: • compared to structured analysis. • If we succeed in creating domain components: • we can define a domain specific language.

27. Domain analysis • Ultimate result of domain analysis: • Problem oriented languages (aka application generators) • application development standards • During domain analysis: • a specific community of software developers get together • discuss community-wide solutions.

28. Domain analysis • Analysis of an application domain: • to identify the reusable components • Actual construction of reusable components for a domain • is called domain engineering.

29. Domain analysis • Domains slowly develop. • As a domain develops, we may distinguish various stages: • Stage 1: • no clear set of notations • all software is written from scratch • experience builds up from previous mistakes

30. Domain analysis • Stage 2: • similar problems are solved in similar ways. • knowledge reuse • Stage 3: • domain is ripe for reuse • set of concepts has stabilized • standard solutions for standard problems • knowledge and component reuse

31. Domain analysis • Stage 4: • domain has been fully explored • software development for the domain can be largely automated • we do not program in the traditional way any more: • use a domain specific language • application generators

32. Classification • If we look at hardware components for clue: • hardware components are classified in a multilevel hierarchy • Naming conventions are standardized.

33. Classification • At the lowest level: • description of components are given in several forms • natural language description • logic schema • timing information • Description must be at a higher level: • than complete specification of program logic • ambiguity is inherent in the descriptions.

34. Classification • Prieto-Diaz’s classification scheme: • each component described using a number of different characteristics (or facets)

35. Prieto-Diaz’s classification • Object classification scheme: • actions they embody • objects they manipulate • data structures used • systems they are part of, etc.

36. Faceted classification • Classifying a component • choosing an n-tuple that best fits that component.

37. Faceted classification • Faceted classification has advantages over enumerative classification: • strictly enumerative schemes use a predefined hierarchy • force you to search for a node that best fits the component to be classified • though cross reference to other nodes can be included: • the resulting network becomes complicated.

38. Faceted classification • Offers the possibility to expand questions: • by considering components that are close to the one sought • closeness can be determined by appropriate measures of distance between facets

39. Searching • A domain repository may contain thousands of reuse items • How can we locate the specific items we are looking for? • A popular search approach: • provide web interface to the repository.

40. Searching • A possible search approach with web interface: • Approximate automated search: • search using key words • Browsing: • use links from items found during approximate search to look up related items

41. Searching • Approximate automated search: • locate products that appear to fulfill some of the specified requirements • Browsing: • Use keyword-to-keyword, keyword-to-product, and product-to-product links • locate additional products and compare their detailed attributes.

42. Searching • The search attributes represent • the requirements of a product. • Search support for: • domain knowledge • models of existing systems • software components

43. Searching • The products located through approximate search: • serve as a starting point for browsing the repository • the developer may follow links to other products • until a sufficiently good match is found

44. Searching • Finding an acceptable solution • may require several iterations of approximate search • followed by browsing • with each iteration • developer should have a better understanding of the available products and their differences.

45. Repository maintenance • Software industry is always trying to • implement something that has not been quite done before. • As patterns of requirements emerge: • reusable solutions also emerge • eventually these solutions become more or less standard.

46. Repository maintenance • However as technology advances: • some components still reusable, • do not wholly address required functions • On the other hand: • restricting reuse to highly mature solution components • neglect greatest potential reuse opportunities.

47. Repository maintenance • Entering products in reuse database: • deciding about search attributes • relating it with other products for approximate search • Making a product available: • before it has been thoroughly assessed can be counter productive • negative experiences tend to dissolve trust in the entire reuse framework

48. Reuse without modifications • Once standard solutions emerge: • no modifications to program parts may be necessary • direct plug-in parts

49. Reuse without modifications • Reuse without modifications is extremely successful: • classical program libraries • supported by compilers through linkage to run-time support routines (Application generators)

50. Application Generators • Application generators translate specifications into application programs. • The specification usually is written in a language called 4GL: • or, the specification might appear in a visual form • the programmer creates a graphical drawing using some standard available symbols