View
221
Download
2
Category
Preview:
Citation preview
2
Organization of this Lecture
Introduction Basic issuesDomain analysisReuse at organization levelSummary
3
IntroductionSoftware is becoming very
expensive: a possible way to reduce cost:
reuse parts from previously made software.
assemble software from off-the-shelf components.
4
IntroductionAdvantages 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 reuseSoftware development with reuse: similar to an electronic engineer building an electronic circuit:uses standard types of electronic ICs and other components.
7
Reuse of KnowledgeMore 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 componentsNo 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 componentsStandard 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 creationComponent indexingSearchUnderstandingAdaptationRepository maintenance
14
Basic IssuesComponent creation:
Identify reusable componentsComponent indexing:
classification of reusable components
so that they can be easily searched when we look for a component to reuse.
15
Basic IssuesSearch:
search for right components in a database of components
requires a proper method to describe components
16
Basic IssuesUnderstanding:
to decide whether we can use some componentwe need a precise and sufficiently complete understanding of what the component does.
17
Basic IssuesAdaptation:
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 IssuesRepository maintenance:
component entering tracking faulty components new applications emerge
older applications become obsolete
components might need changesobsolete 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 componentscatalogue 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 softwarebanking softwarebusiness presentation software
23
Reuse DomainJust 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 analysisDomain analysis identifies:
objects, operations and relationship among them.
Consider airline reservation: objects are
seats, flights, airports, crew, meal orders
Operations arescheduling 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 analysisDomain 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 analysisUltimate 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 analysisDomains slowly develop.As a domain develops, we
may distinguish various stages: Stage 1:
no clear set of notationsall software is written from scratch
experience builds up from previous mistakes
30
Domain analysisStage 2:
similar problems are solved in similar ways.
knowledge reuseStage 3:
domain is ripe for reuse set of concepts has stabilized standard solutions for standard
problems knowledge and component reuse
31
Domain analysisStage 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 languageapplication generators
32
ClassificationIf we look at hardware
components for clue: hardware components are classified in a multilevel hierarchy
Naming conventions are standardized.
33
ClassificationAt the lowest level:
description of components are given in several formsnatural language descriptionlogic schematiming information
Description must be at a higher level: than complete specification of
program logicambiguity 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
SearchingA 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
SearchingA 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
SearchingApproximate 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
SearchingThe 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
SearchingFinding an acceptable solution
may require several iterations of approximate searchfollowed by browsing
with each iterationdeveloper 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 maintenanceEntering products in reuse
database: deciding about search attributes relating it with other products for
approximate searchMaking 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
51
Defining variant and invariant partsDefining what is variant and
what is invariant: corresponds to parameterizing a
subroutine to make it reusable a subroutine’s parameters are
variants programmers can specify them
when calling the subroutine. parts of the subroutine that are
not parameterized cannot be changed.
52
Application generators vs. parameterized programs
Application generators have significant advantages over simple parameterized programs: can represent variant information in
an appropriate languagerather than being restricted to
function parameters, named constants, or tables.
53
Advantages of application generators
Application generators offer several advantages: no need to bother about
implementation details development effort is
substantially reduced fewer errors easier to maintain
54
Shortcomings of simple application generators
Application generators are handicapped if it becomes necessary to support
some new concepts or features some application generators overcome
this handicapthrough an escape mechanismprogrammer can write code in some 3GL
through this mechanism
55
Application generators
Application generators have been applied successfully to: data processing applications user interface development compiler development
Application generators are less successful with real-time systems
56
Reuse at organization level
Reusability should be a standard part in: specification, design,
implementation, test, etc.Ideally there is a steady flow of
reusable components: in practice, things are not so
simple.
57
Reuse at organization level
Extracting reusable knowledge from past projects: presents difficulties not encountered in working with a current project
typically original developers are no longer available for consultation.
58
Reuse at organization level
Development of new systems leads to an assortment of products: reusability ranges from immediate to
highly improbable.Steps for reusable component
creation: assess product’s potential for reuse refine product for greater reusability integrate product with reuse
repository
59
Assessing a product’s potential for reuseQuestions can be devised to
assess a component’s reusability: is the component’s functionality
required for future implementations? how common is the component’s
function within the domain? is there duplication of the function
within the domain?
60
Assessing a product’s potential for reuse
Is the component hardware dependent?
Is the design of the components optimized enough?
Is it possible to decompose a non-reusable component? to yield a reusable component?
Can we parameterize a non-reusable component? so that it becomes reusable.
61
Refining products for greater reusabilityFor a product to be reusable:
it must be relatively easy to adapt to different contexts.
machine dependency must be abstracted out.localized using data encapsulation
techniques.
62
Refining products for greater reusability
Name generalization: names should be general
rather than direct reflection of some specific application.
Operation generalization: add operations to make it more
general remove operations specific to an
application
63
Refining products for greater reusability
Exception generalization: Involves checking each
component to see which exceptions it might generate.
For a general component: several types of exceptions might
have to be handled
64
Portability problems
Machine architecture problems: program makes some assumption
regarding information representation in the underlying machine
these assumptions are not true for all machines
65
Operating system problems
The program calls an operating system facility these are not available on all machines
66
Library problems
Program uses some function libraries: these are not available on all host machines
67
Portability solution
Application System
Portability Interface
Data ReferencesOperating System
and I/O calls
68
Portability solutionRather than call O.S. and I/O
procedures directly: abstract versions of these are called
by the application program all platform-related features are
routed through the portability interface
The problem with this solution: significant overhead
69
Current State of Reuse
Many factors restricting reuse are non-technical: need for management
commitment documentation for supporting
reusable components adequate incentives to reward
those who reuse providing access to and
information about reusable components
70
SummaryBasic issues in reuse:
Component creation Component indexing Search Understanding Adaptation Repository maintenance
71
SummaryCreation of highly reusable
components is a very difficult problem a promising approach is domain
analysisDomain analysis:
aims to identify reusable components for a problem domain
72
SummaryApplication generators:
translate specifications into application programs.
facilitate reuse not very flexible, if new concepts need to be supported.
Recommended