1 / 73

Software Reuse (Lecture 15)

Software Reuse (Lecture 15). Dr. R. Mall. Organization of this Lecture. Introduction Basic issues Domain analysis Reuse at organization level Summary. Introduction. Software is becoming very expensive: a possible way to reduce cost: reuse parts from previously made software.

Télécharger la présentation

Software Reuse (Lecture 15)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


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

More Related