Download
software reuse lecture 15 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Software Reuse (Lecture 15) PowerPoint Presentation
Download Presentation
Software Reuse (Lecture 15)

Software Reuse (Lecture 15)

5 Vues Download Presentation
Télécharger la présentation

Software Reuse (Lecture 15)

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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