ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr6/proceedings/ascii/wentzel.ascii

Text File | 1993-10-19 | 18KB | 285 lines

Wentzel - 1


Domain Specific Kits - A More Effective Approach
to Software Reuse


Kevin D. Wentzel

Hewlett Packard Laboratories
1501 Page Mill Road, Palo Alto, CA 94303
Tel: [phone]
Email: [e-mail]
Fax: [phone]


Abstract
Organizations just getting started in software reuse often view large, broad
coverage, corporate level reuse libraries as the goal of a reuse project.  We
believe that this is the wrong approach to software reuse and will often
lead to frustration and failure of pilot programs.  We are researching the
concept and application of "Domain Specific Kits", including software
components, application architectures, skeleton applications,
documentation, and tools for building applications in particular domains, as
a better route to success in reuse.
Keywords: software reuse, reuse libraries, software kits, domain specific
kits
Workshop Goals: Exchange ideas on how to design, build and use domain
specific kits.
Working Groups: domain specific kits, domain engineering, kit
engineering, reuse technology, reuse process.

1  Background
Kevin Wentzel has been involved in software reuse research as part of Hewlett
Packard Labs' Software Reuse Department (SRD)  since the department's
research direction was proposed two years ago.  SRD is a multidisciplinary
group researching several facets of software reuse including both the technical
and organizational sides of the discipline.  Kevin manages the technical
research including experimentally prototyping domain specific kits, developing
supporting technology for domain specific kits (generation technology,
component integration technology)  and working with HP divisions to validate
and spread the results.  Prior to his work in HP Labs, Kevin was a software
developer in HP product divisions. His first experience in software reuse was in
1980 as the developer of a software subsystem for indexed file access which was
developed for one product and reused in four other HP products.  Kevin helped
to organize WISR-5 (Palo Alto, CA, 1992), and participated in the domain
analysis working group.
2  Position
Organizations just getting started in software reuse often view large, broad
coverage, corporate level reuse libraries as the goal of a reuse project.  We
believe that this is the wrong approach to software reuse and will often lead to
frustration and failure of pilot programs.  We are researching the concept and
application of "Domain Specific Kits", including software components,
application architectures, skeleton applications, documentation, and tools for
building applications in a particular domain, as a better route to success in
reuse.
2.1  Libraries Aren't Enough
Many times when we present information about our program on software
reuse, we are asked "Where is your corporate software library"?  We are not
building one!  Our studies of several library efforts inside HP and stories we've
heard from others building libraries tell us that large centralized libraries are
not the best approach to institutionalizing software reuse in an organization.
There are strong standards issues with libraries.  These include interface
standards, environment standards (i.e.: other functions, globals, memory
management etc.), quality and testing standards, and evolution standards.  A
loosely run library will be unable to enforce standards on it's contents and will
run into version control issues among its suppliers and users.  A carefully run
library requires a large enough overhead that many organizations are unable
or unwilling to devote the resources needed to build the library and keep it
running.  Frequently, when money gets tight, library management is one of the
first areas to be trimmed.
It is often difficult to find needed functionality in a large library.  Searches
(keyword, plain text etc.) may or may not be successful and often result in too
many matches.  Even when matches are found, careful evaluation must be
made to verify suitability.  If strict library standards are not in place, further
tests may be required to access component reliability, functionality,  and
performance.  This often results in the "it's easier to do it myself" attitude
among developers.
Except for certain well known libraries (i.e.: standard C library etc.) library
searches are usually done during coding when a developer realizes that a
particular set of functionality may be needed.  This is the wrong phase of
development for taking advantage of reuse.  The most benefit will come from a
reuse lifecycle that starts at the design phase.  By the time components are
sought in coding phase, there will often be environmental constraints, in place
design decisions, and other decisions already made which cause otherwise
reusable components to be rejected or require rework before they can be used.
Library systems are often built up from contributed components.  Sometimes
rewards are offered for contributions to the library.  Even when contributions
are controlled for documentation and quality, this frequently results in large
collections of "potentially" reusable subsystems but little incentive to actually
use what is there.
Our first research in software reuse was based on the idea that if library
searching and browsing was easier, people would be more likely to use the
libraries.  We developed a hypertext system [3] for cataloging components in a
library.  Unfortunately, we found that library users within HP did not see a
system like ours as their biggest need in reuse technology.
2.2  Domain Specific Kits - A Better Approach
The successful applications of reuse that we've seen in HP and in other
companies [4,7,8,11] have been situations where carefully constructed (or
reengineered) and tuned reusable components are used in a restricted domain
to construct similar applications either in a product line or as specials for
particular customers.  As a way to strengthen and institutionalize  this domain
specific reuse, we are developing a concept of "Domain Specific Kits" as a better
approach to providing a software reuse solution to application developers.
Our vision of "Domain Specific Kits" is that "Applications will be constructed
from integrated, domain specific kits composed of: architectural frameworks,
software components, software "glue", kit use tools, domain specific languages,
generators, builders, generic applications, usage instructions, and tests."
As the above vision states, a kit is much more than just a library of code
modules.  It should provide a significant portion of the needed components to
construct applications in the domain.  By providing an application
architecture and framework, it can define how applications will be designed.
Application builders can use generic (example) applications as a starting point
for building their applications thus beginning with and building on a working
application.  A kit enforces a "design with reuse" style to application
construction because when working from the kit, reuse is built in to
development from the start.
2.3  Kit Construction
Kits are developed in via a two path process.  It is critically important that the
kit be appropriate for the application domain it will be applied to, but it is
just as important that it be appropriate for the application developers who
will use it to build software within the domain.  Therefore, we have developed
a kit building process in which includes both domain engineering and "kit
engineering".

Domain Engineering is analysis, design and construction of software
requirements in the domain with the goal of understanding, designing and
building domain specific components, a domain specific architecture, possibly
a domain specific language, an application framework, and generic
application(s).  It is a three stage process:
Domain Analysis [10] is the process of gathering, organizing, representing, and
clarifying the requirements for applications in the target domain of a given kit.
The needed representation is not merely a collection of requirements
representations for individual applications, but one that explicitly represents
the common features and the variations among the applications the target
domain.
Domain Design is the process of developing representations of the architectures
and designs for all the applications in the target domain.  As in the case of
domain analysis, what is needed is a systematic way of representing both the
common features and the variations among the applications in question.
Domain Implementation is the process of implementing those kit components
that will be incorporated and/or instantiated more or less directly into the
applications to be constructed with a given kit.
Kit Engineering is analysis of kit user (application developer) needs and
preferred development style with the goal of developing appropriate tools,
generators, builders, development environment, documentation, etc. to
optimize developer comfort and productivity with the kit.  It also is a three
stage process:
Kit Analysis is the process of developing the requirements for a given software
construction kit, based (among other things) on an explicit characterization of
the intended users of the kit.  It is important to distinguish between the
requirements for applications to be built using the kit (developed in domain
analysis) from the requirements for the kit itself (developed in kit analysis).
Kit Design is the process of developing the architecture and design of a given
software construction kit.  One important aspect of kit design is designing for
openness.  While we aim for high levels of reuse in application development,
we don't expect to achieve 100% reuse in most applications, so kits must be
designed with the expectation that kit users will need to add (and integrate)
application specific functionality.
Kit Implementation is the process of implementing a kit design to build a
particular software construction kit.
An underlying collection of kit support technology will aid in kit construction.
This supporting technology could include more generic kits (such as user
interface kits or language (generator) kits), component interconnection
technology (such as a software bus [1], remote procedure call or distributed
object system),  and development support technology (such as source code
control and configuration management tools).
While these steps can be described separately and each will have its own
deliverables, they usually are not done independently.  Domain analysis and
Kit analysis can be done with little interaction however the results of these
steps will drive the next steps in both paths.  For example if kit analysis finds
that developers will prefer a domain specific language as their application
building style, domain design must be oriented toward developing a language
and an application architecture which is appropriate for using a language,
while kit design will develop a language based kit architecture and find (or
develop) appropriate tools for a language based kit.  Kit and domain
implementation overlap significantly, however there will still be separate
tracks of work for example, kit implementation may be involved with
developing the kit use infrastructure (i.e.: configuration management etc.)
while domain implementation will develop domain functionality.
We believe that if domain engineering and kit engineering are carefully defined
with the right resulting work products, it should be possible to retool a domain
by developing a different kit for it without repeating the domain analysis or all
of the domain design and implementation.  We should also be able to (re)use
the results of kit engineering for a particular domain in a kit for another
domain.
2.4  Kit Use
Application developers will use a kit by performing an application needs
analysis for the particular application their users need.  Their analysis should
be in the context of the kit, rather than starting from zero ("design with
reuse").  Application construction will use the kit for overall application
architecture and all functionality which is covered by the kit.  Application
specific functionality will have to be designed and developed for user needs
not covered by the kit or for areas (i.e.: hardware interface) not planned to be
covered by the kit.  Developers may combine more than one kit to develop
applications thus common architectures and base technology is important.
2.5  Kit Support and Evolution
A kit is not expected to be a static entity.  Kits must go through a continuous
evolution process to stay viable.  Feedback to kit developers will come from kit
users (application developers) and from application users (perhaps via
application developers).   Feedback should include information on both
domain needs (domain engineering track) and on developer style changes (kit
engineering track).  This feedback will allow the kit to be modified to keep it
up-to-date and usable over time.
Kits need particular kinds of support.  Different sets of kit users may want
conflicting changes so decisions need to be made and moderated on how the
kit will evolve.  Version control and configuration management need to be
carefully overseen.

3  Our Research
Hewlett Packard Laboratories, Software Reuse Department (SRD) has developed
a research plan involving research in "Domain Specific Kits" and in the
environment in which they are developed and used, the "Flexible Software
Factory"  [5,6].
Our research in Domain Specific Kits is a two part project.  We are working in
an internal kit prototype effort to develop our knowledge and technology in
kit design, development and use, and on pilot projects with HP product
divisons.
So far, we have developed a simple prototype kit for the domain of "To-Do List
Management".  This kit is composed of components for display of a To-Do list,
display and editing of To-Do items, storage of To-Do item, time calculations,
and user notification.  In most cases, the kit has a selection of components for
doing each task in different ways.  Some components are optional in the kit for
example if the application doesn't need notification of due items, the time and
notification components can be left out of the application.  These components
all communicate via a software bus.  The application is built by specifying in a
simple language (lisp expressions) the data layout of a To-Do item, default
values, and which components to include.  This language is run through a
generator to build configuration files, make files, and parameterization files for
the components and the overall application.  Our initial kit users found the
generative approach valuable.  They were able to get several applications built
very quickly.  Feedback stressed the importance of openness in a kit to allow
application builders to add their own components.  It also pointed out the
need for excellent documentation since the kit user is a level of abstraction
above normal programming environments and has more difficulty deciphering
problems. Finally, it reinforced the need for careful kit management since
changes to the early kit often made applications unbuildable.
To keep this work based in real world problems, we are working with HP
divisional (product line) development teams to understand their issues and
problems in software reuse and domain specific kits.  We are now preparing to
apply our kit research in a divisional domain and context with the dual goals
of furthering the research and helping the divisional development team build
its own reuse environment.

References
[1]    Brian Beach, Martin Griss, Kevin Wentzel, "Bus-Based Kits for Reusable
Software", In proceedings, 2nd Irvine Software Symposium, University of
California, Irvine, Irvine CA., March 1992.
[2]    Gianluigi Caldiera and Victor R. Basili, "Identifying and Qualifying
Reusable Software Components", IEEE Computer, February 1991.
[3]    [Michael Creech, Dennis Freeze, Martin Griss, "Using Hypertext in Selecting
Reusable Software Components", In proceedings, Hypertext'91, pages 25-
38.
[4]    Michael A. Cusumano, Japan's Software Factories, Oxford University Press,
1991
[5]    Martin Griss, "A Multi-Disciplinary Software Reuse Research Program", In
proceedings, 5th Annual Workshop on Institutionalizing Software Reuse,
October, 1992.
[6]    Martin Griss, "Software Reuse from Libraries to Factories", IBM Systems
Journal, To be published, Vol 32 no 4, November 1993.
[7]    Guillermo Mayobre, " Using code reusability analysis to identify reusable
components for the software related to an application domain",  In
proceedings, 4th  Annual Workshop on Institutionalizing Software Reuse,
November, 1991
[8]    Alvina Nishimoto, " Program of reuse at manufacturing productivity
division", In proceedings, 4th  Annual Workshop on Institutionalizing
Software Reuse, November, 1991
[9]    Ruben Prieto-Diaz, "Making Software Reuse Work: An Implementation
Model", ACM SIGSOFT Software Engineering Notes, Vol 16 no 3, July 1991.
[10    Ruben Prieto-Diaz, Guillermo Arango, "Domain Analysis and Software
Systems Modeling", IEEE Computer Soceity Press, 1991.
[11]    Malcom Rix, "Case Study of a Successful Firmware Reuse Program", In
proceedings, 5th Annual Workshop on Institutionalizing Software Reuse,
October, 1992.

4  Biography
Kevin Wentzel is a project manager in the Software Reuse Department of HP
Labs' Software Technology Lab.  Together with Martin Griss, he has proposed
and built a multi-disciplinary team oriented toward experimental research in
software engineering and reuse.  Kevin has been with Hewlett Packard for 16
years, prior to joining HP Labs, Kevin worked in various engineering and
management roles in several HP divisions developing software products.  Kevin
has BS and MS degrees in Computer Science from the University of Wisconsin.