Software Reuse Lecture 15 Dr R Mall 1

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

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

Introduction z. Software is becoming very expensive: ya possible way to reduce cost: xreuse parts from previously made software. xassemble software from off-the-shelf components. 3

Introduction z. Advantages of reuse also include: yreduced number of defects: xstandard and well-tested components are reused. yreduced development time: xprovide early market access for products. 4

Software reuse z. Software development with reuse: ysimilar to an electronic engineer building an electronic circuit: xuses standard types of electronic ICs and other components. 5

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

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

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

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

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

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

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

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

Basic Issues z. Component creation: y. Identify reusable components z. Component indexing: yclassification of reusable components yso that they can be easily searched when we look for a component to reuse. 14

Basic Issues z. Search: ysearch for right components in a database of components yrequires a proper method to describe components 15

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

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

Basic Issues z. Repository maintenance: ycomponent entering ytracking faulty components ynew applications emerge xolder applications become obsolete xcomponents might need changes xobsolete components might have to be removed 18

A possible reuse approach z. Introduce building block approach into the production process. yidentify reusable components after development finishes y enhance reusability of the identified reusable components xcatalogue into a component library. 19

Domain analysis z. Aim: yidentify reusable components for a problem domain. xidentification of right kind of reusable information is a difficult problem. 20

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

Reuse Domain z. A domain is a shared understanding of some community: ytechnical knowledge of some problem area. ycharacterized by notations that show coherence yexamples of domains: xaccounting software xbanking software xbusiness presentation software 22

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

Domain analysis z. Domain analysis identifies: yobjects, operations and relationship among them. z. Consider airline reservation: yobjects are xseats, flights, airports, crew, meal orders y. Operations are xscheduling a flight, reserving a seat, assigning a crew to a flight, etc. 24

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

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

Domain analysis z. Ultimate result of domain analysis: y. Problem oriented languages (aka application generators) yapplication development standards z. During domain analysis: ya specific community of software developers get together xdiscuss community-wide solutions. 27

Domain analysis z. Analysis of an application domain: yto identify the reusable components y. Actual construction of reusable components for a domain xis called domain engineering. 28

Domain analysis z. Domains slowly develop. z. As a domain develops, we may distinguish various stages: y. Stage 1: xno clear set of notations xall software is written from scratch xexperience builds up from previous mistakes 29

Domain analysis z. Stage 2: ysimilar problems are solved in similar ways. yknowledge reuse z. Stage 3: ydomain is ripe for reuse yset of concepts has stabilized ystandard solutions for standard problems yknowledge and component reuse 30

Domain analysis z. Stage 4: ydomain has been fully explored ysoftware development for the domain can be largely automated ywe do not program in the traditional way any more: xuse a domain specific language xapplication generators 31

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

Classification z. At the lowest level: ydescription of components are given in several forms xnatural language description xlogic schema xtiming information z. Description must be at a higher level: ythan complete specification of program logic xambiguity is inherent in the descriptions. 33

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

Prieto-Diaz’s classification z. Object classification scheme: yactions they embody yobjects they manipulate ydata structures used ysystems they are part of, etc. 35

Faceted classification z. Classifying a component ychoosing an n-tuple that best fits that component. 36

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

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

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

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

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

Searching z. The search attributes represent ythe requirements of a product. z. Search support for: ydomain knowledge ymodels of existing systems ysoftware components 42

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

Searching z. Finding an acceptable solution ymay require several iterations of approximate search xfollowed by browsing ywith each iteration xdeveloper should have a better understanding of the available products and their differences. 44

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

Repository maintenance z. However as technology advances: ysome components still reusable, xdo not wholly address required functions z. On the other hand: yrestricting reuse to highly mature solution components yneglect greatest potential reuse opportunities. 46

Repository maintenance z. Entering products in reuse database: ydeciding about search attributes yrelating it with other products for approximate search z. Making a product available: ybefore it has been thoroughly assessed can be counter productive ynegative experiences tend to dissolve trust in the entire reuse framework 47

Reuse without modifications z. Once standard solutions emerge: yno modifications to program parts may be necessary ydirect plug-in parts 48

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

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

Defining variant and invariant parts z. Defining what is variant and what is invariant: ycorresponds to parameterizing a subroutine to make it reusable ya subroutine’s parameters are variants xprogrammers can specify them when calling the subroutine. yparts of the subroutine that are not parameterized cannot be changed. 51

Application generators vs. parameterized programs z. Application generators have significant advantages over simple parameterized programs: ycan represent variant information in an appropriate language xrather than being restricted to function parameters, named constants, or tables. 52

Advantages of application generators z. Application generators offer several advantages: yno need to bother about implementation details ydevelopment effort is substantially reduced yfewer errors yeasier to maintain 53

Shortcomings of simple application generators z. Application generators are handicapped yif it becomes necessary to support some new concepts or features ysome application generators overcome this handicap xthrough an escape mechanism xprogrammer can write code in some 3 GL through this mechanism 54

Application generators z. Application generators have been applied successfully to: ydata processing applications yuser interface development ycompiler development z. Application generators are less successful with yreal-time systems 55

Reuse at organization level z. Reusability should be a standard part in: yspecification, design, implementation, test, etc. z. Ideally there is a steady flow of reusable components: yin practice, things are not so simple. 56

Reuse at organization level z. Extracting reusable knowledge from past projects: ypresents difficulties not encountered in working with a current project ytypically original developers are no longer available for consultation. 57

Reuse at organization level z. Development of new systems leads to an assortment of products: yreusability ranges from immediate to highly improbable. z. Steps for reusable component creation: yassess product’s potential for reuse yrefine product for greater reusability yintegrate product with reuse repository 58

Assessing a product’s potential for reuse z. Questions can be devised to assess a component’s reusability: yis the component’s functionality required for future implementations? yhow common is the component’s function within the domain? yis there duplication of the function within the domain? 59

Assessing a product’s potential for reuse z. Is the component hardware dependent? z. Is the design of the components optimized enough? z. Is it possible to decompose a nonreusable component? yto yield a reusable component? z. Can we parameterize a non-reusable component? yso that it becomes reusable. 60

Refining products for greater reusability z. For a product to be reusable: yit must be relatively easy to adapt to different contexts. ymachine dependency must be abstracted out. xlocalized using data encapsulation techniques. 61

Refining products for greater reusability z. Name generalization: ynames should be general xrather than direct reflection of some specific application. z. Operation generalization: yadd operations to make it more general yremove operations specific to an application 62

Refining products for greater reusability z. Exception generalization: y. Involves checking each component to see which exceptions it might generate. y. For a general component: xseveral types of exceptions might have to be handled 63

Portability problems z. Machine architecture problems: yprogram makes some assumption xregarding information representation in the underlying machine xthese assumptions are not true for all machines 64

Operating system problems z. The program calls an operating system facility ythese are not available on all machines 65

Library problems z. Program uses some function libraries: ythese are not available on all host machines 66

Portability solution Application System Portability Interface Data References Operating System and I/O calls 67

Portability solution z. Rather than call O. S. and I/O procedures directly: yabstract versions of these are called by the application program yall platform-related features are routed through the portability interface z. The problem with this solution: ysignificant overhead 68

Current State of Reuse z. Many factors restricting reuse are non-technical: yneed for management commitment ydocumentation for supporting reusable components yadequate incentives to reward those who reuse yproviding access to and information about reusable components 69

Summary z. Basic issues in reuse: y. Component creation y. Component indexing y. Search y. Understanding y. Adaptation y. Repository maintenance 70

Summary z. Creation of highly reusable components is a very difficult problem ya promising approach is domain analysis z. Domain analysis: yaims to identify reusable components for a problem domain 71

Summary z. Application generators: ytranslate specifications into application programs. yfacilitate reuse ynot very flexible, if new concepts need to be supported. 72

Summary z. Reuse at organization level yassess product’s potential for reuse yrefine product for greater reusability yintegrate product with reuse repository 73