ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr5/proceedings/ascii/garg.ascii

Text File | 1993-05-28 | 17KB | 359 lines

Process Modeling of Software Reuse

Pankaj K. Garg

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


                       Abstract

Explicit models of software processes benefit organizations by making the
process visible for organization design; providing a basis for continuous
process improvement; providing a basis for selecting an infrastructure
(technology support) for the process; etc. Not surprisingly, these benefits can
accrue for the process of software reuse as well. However, it is easy to
underestimate the importance of process modeling for software reuse.

In this position paper we claim that unless a successful strategy and
methodology for process modeling is developed, software reuse strategies will
not be successful. We outline an approach, based on macro and micro process
modeling, which represents a process modeling strategy for software reuse. The
approach is illustrated using concepts from the Matisse process-oriented
programming environment.

Keywords:  Software Reuse, Software Process Modeling, Organization design.

Workshop Goals:  Understand the intersection of software process modeling
         research and software reuse research; contribute understanding
                 of software process research to the reuse community.

Working Groups:  Reuse process models, Reuse maturity models, Reuse management,
                 Organization and economics, Domain analysis/engineering.


1  Background

I have been involved in software engineering research for the past seven years.
The basic hypothesis of my work has been that programmer productivity can be
improved by (semi-automatically) explicating appropriate and timely information
regarding the state of a software project.  Towards this end I have previously
proposed a hypertext model to manage software life-cycle information
[Gar88, GS90]. This work was subsequently extended to include more automation of
the software process within the hypertext framework [GS89] and to include better
team-work support [GPB+92].

More recently I have been looking at the issue of making software processes
explicitly available as information objects to be manipulated within a software
team information environment [Ost87, GB92].  Within this context, I would like
to explore the possibilities of applying software process modeling to software
reuse and vice versa.


2  Position

My position is that in order to achieve its full potential, software reuse
requires explicit software process modeling.  In the first part of this section,
I argue for this position. In the latter part, I present the first steps towards
process modeling of software reuse.


2.1  Benefits of Reuse Process Modeling

2.1.1  Process Modeling

A software process model consists of a description of the activities in the
process (with associated resource descriptions) in a textual or graphical form.
In addition,  within a process-oriented programming environment, there is an
enactment engine which maintains (and helps maintain) the state of the process
in a dynamic, continuous manner.

Explicit models of software processes within programming environments
accomplish several functions:

  * Provide analysis capabilities for process descriptions;

  * Suggest sequence of actions to be carried out by an agent (human or
    artificial) at a given stage in the project;

  * Track the activities carried out in the project such that a sufficient
    corporate memory of the project is captured;

  * Establish constraints on what can be done by an agent at a given stage in
    the project.


2.1.2  Macro Process Models

Several proposals for software process management, such as the Waterfall
[Roy88] or Spiral [Boe88] life-cycle models, describe (and prescribe) in a very
general sense the activities of a software project. For example, the Waterfall
life-cycle model suggests that the system requirements should be understood
before developing the functional specifications. The Spiral life-cycle model
suggests that at specific intervals the team should understand (estimate) the
project risks and minimize the risks by developing prototypes of high risk
components. These models serve a useful purpose: they help in designing the
organization within which the software should be developed and maintained .
Because of the level at which activities are described in such models, we have
termed this class of models as macro process models .

Lurking behind James Neighbors' following remark is the desire for designing
macro software reuse process models:

    The basic motivation is the frustrating feeling that most of the system you
    are currently building is the same as the last few systems you have built,
    but that once again you are building everything from scratch. The current
    system development is behind schedule and you have no time to figure out
    what this similarity means [Nei91][pp.39].


Accordingly, a major component of Neighbors' DRACO approach is the specification
of a particular reuse process model.  The primary reason to develop a macro
process model for reuse, therefore, is that the benefits of producing a reusable
component might not be obvious to the producers unless they can identify the
`bigger picture'. There are, of course, secondary reasons like the need to blend
together the "producer" and "consumer" processes for effective reuse of
components [Ost87].


2.1.3  Micro Process Models

At a high level of generality, it seems that macro models should be able to meet
the needs of describing and prescribing software processes. However, if we
address the issue of embedding process models in a process-oriented programming
environment, we have to detail out the finer activities which comprise the
general activities described in such models [GS89]. For example, the high level
activity of "Understand Requirements" can be decomposed into several finer
grained activities such as read requirements document, develop annotations for
the requirements document, collate the annotations, etc. These finer grained
activities, in turn, may be composed of several primitive actions which are the
commands available to the environment user. Models of such activities are quite
useful to the humans working on the projects -- they serve to automate the
routine aspects of the work such that the humans in the process can concentrate
on the more creative and challenging aspects.  We define these types of process
models as being micro process models .

As discussed before [Nei91, Kru89], effective reuse requires extra activity on
the part of the `producer', `consumer', `librarian', etc., of reusable software
components. Therefore, it behooves us to find ways of reducing (or eliminating)
these extra burdensome activities through the use of micro models embedded
within the appropriate programming environments.

In summary, there are two layers at which reuse process modeling needs to be
carried out: (1) the macro layer, and (2) the micro layer. The macro process
models help in designing organizations, major work flows, etc.  The micro
process models help in developing the support environment for programmers,
designers, etc.  In the rest of this section we describe a particular
instantiation of this layered approach, embedded within a process-oriented
programming environment, Matisse.


2.2  A Layered approach to Reuse Process Modeling

We have built an experimental process-oriented programming environment, Matisse,
which can support both the layers described above [GPB+92]. The heart of the
system is a forward chaining rule engine which provides the enactment engine for
process models.  A powerful combination of object-oriented and rule-based
concepts provides the the necessary representational power for both the macro
and micro level process models. The rule engine is also connected to a shared,
persistent repository of information which provides the requisite team work
support.

We use modeling constructs originally suggested by Bob Balzer's group [BDMN83]
and later refined by Geoff Clemm [Cle88]. The modeling language used is SE-KRL
(for Software Engineering Knowledge Representation Language). SE-KRL uses a
rule-based, object-oriented approach to software process modeling.  It allows
the user to define: classes of objects, relations (attributes) on objects,
operations on objects, and rules which govern the behavior of property
modifications in the environment. Both change propagation and consistency
maintenance rules are easily defined in SE-KRL.


2.2.1  Macro Process Model

For illustration purpose, we use IDEF constructs for the macro process model.
Rather than go into the details of IDEF, we highlight the approach by encoding
aspects of a modified butterfly model of reuse [aW91].

At the top level, there are four main activities in this model: Manage Reuse,
Produce Components, Support Components, and Use Components.  These are modeled
within Matisse by creating an IDEF-Activity-Class:

    (DEFCLASS IDEF-Activity-Class
      :name "IDEF-Activity-Class"
      :superclass Job-Class
      :attributes (user-object))


This SE-KRL construct defines the class IDEF-Activity-Class as a sub-class of
the (pre-defined) job-class in Matisse. The attribute User-Object suggests (to
Matisse) that users can create instances for this class of objects.  Once this
class is defined, users can use a graphical editor to create the four top level
activities.

Subsequently, relationships between activities and their inputs; activities and
their constraints; etc., can be modeled. For example, relationships between
activities and their inputs can be defined as:

    (DEFSLOT IDEF-activity-input
      :name "IDEF-activity-input"
      :domain PO-Class
      :range IDEF-Activity-Class
      :attributes (Can-Change)
      :inverse IDEF-input-of)


This definition states that IDEF-Activity-Input is a relationship which exists
between IDEF-Activities and objects of the PO-Class. (PO-Class is a generic
class which is used in Matisse to represent workproducts of the process.)

Matisse helps in the development of such Macro models in several ways: (1) It
maintains the model in a team-shared repository such that the model can be built
by team consensus, (2) It provides the infrastructure to check for various
consistency requirements for the model, (3) It can automate aspects of the
process of developing the macro model  through change propagation, and (4)
Various forms of analysis can be performed on the model.  For example, the
following analysis operation, Workproduct-fan-out, can be used to determine the
number of activities in which a particular workproduct is used:

    (DEFOPERATION Output-Fan-Out (Idef-Output)
      :name "Output Fan Out"
      :domain PO-Class
      :lisp-test (wdb-get Idef-Output 'idef-output-of)
      :lisp-apply-test NIL
      :lisp-body (format t "Output  A is used in  A activities
                   (wdb-get idef-output 'has-name)
                   (length (wdb-get-all idef-output 'idef-input-of))))


2.2.2   Micro Process Model

In micro modeling, it is important that the process-oriented environment provide
automation support for the burdensome aspects of the process. If we assume a
component-based reuse strategy, one of the micro process which teams would like
to do is to enforce some naming convention for the components produced [Kru89].
Typically, such conventions involve pre-pending the name of the library package
to which the component would ultimately belong, with the name of the produced
component. This is a burdensome activity for the producer.  With Matisse, one
can easily automate this activity, through a change propagation rule:

    (DEFCOORDINATION prepend-package-name-to-components
      :test (and (rel ?object has-name ?name)
                 (rel ?object component-in-package ?package))
      :body (unless (string= ?name (wdb-get ?package 'has-name)
                            :start1 0
                            :end1 (length (wdb-get ?package 'has-name)))
                (assert (action assert =?object has-name
                =(strcat (wdb-get ?package 'has-name) ":" ?name)))))


With this rule, anytime a user changes (or creates) the name of a component,
Matisse will make sure that the name is pre-pended with the name of the package
which the user is currently working with.


2.2.3   Summary

To summarize, it is our claim that explicit process modeling will be an
essential component of any reuse strategy. Our claim is based on observations
made in the literature about shortcomings of unsuccessful reuse strategies.  On
the basis of this hypothesis, we have developed an approach to process modeling
of software reuse, the first steps of which have been presented in this paper.
The approach is promising specially because of the automation support we can
provide through the Matisse process-oriented programming environment.


3  Comparisons

Several people have expressed the necessity of modeling the software reuse
process model, including Neighbors [Nei91], University of Maryland's component
factory approach [BCC92], etc. The main contribution of our approach is the
ability to: (1) automate the routine aspects of reuse processes, and (2)
explicate process models in a manner suitable for ready analysis.

Other people such as Prieto Diaz, Martin Griss, Walt Scacchi, and Mark Simos
have expressed the need for solving some of the non-technical barriers of
software reuse.  Clearly, having a well-defined reuse process model is a
pre-requisite for such solutions.  The approach presented in this paper can
provide a basis for solving the problem of software reuse process modeling.


4  Acknowledgments

I would like to thank Patricia Collins for her patient explanation of the
Butterfly process model. I would also like to thank Patricia Collins, Martin
Griss, and Thuan Pham for their comments on earlier versions of the paper.


5  Biography

Pankaj Garg is a Project Leader at Hewlett Packard Laboratories, Software
Technology Labs. He got his Ph.D in Computer Science from the University of
Southern California, in February 1989.  His research interests are in
artificial intelligence, hypertext systems, and software engineering.  Pankaj
was an All-University-Pre-Doctoral-Merit fellow of the graduate school, USC,
for the years 1984 through 1987. He was a research associate in the Computer
Science Department, USC, from 1987 through February 1989.  He got his Bachelor
of Technology degree in Computer Science, from Indian Institute of Technology,
Kanpur (INDIA), 1984.


References

[aW91]   Reuse Process Working Group at WISR-4.  Reuse Process Working Group
     Results.  Technical report, November 1991.

[BCC92]  V. R. Basili, G. Caldiera, and G. Cantone.  A Reference Architecture
     for the Component Factory.  ACM Transactions on Software Engineering
     and Methodology, 1(1):53--80, January 1992.

[BDMN83] R. Balzer, D. Dyer, M. Morgenstern, and R. Neeches.  Specifications
     Based Computing Environments.  In Proc. National Conf. on AI, AAAI-83,
     1983.

[Boe88]  Barry W. Boehm. A Spiral Model of Software Development and Enhancement.
         In Richard H. Thayer, editor, IEEE Tutorial: Software Engineering
     Project Management, pages 128--142. IEEE Computer Society Press, 1988.

[Cle88]  G. M. Clemm.  The Workshop System: A Practical Knowledge-Based Software
         Environment.  In Proceedings of the 3rd ACM software engineering
     environments conference, pages 55--64, December 1988.

[Gar88]  P. K. Garg.  Abstraction  Mechanisms in  Hypertext.  Communications of
         the ACM, 31(7), July 1988.

[GB92]   P. K. Garg and S. Bhansali.  Process Programming by Hindsight.  In
     Proceedings of the International Conference on Software Engineering,
     May 1992.

[GPB+92] P. K. Garg, T. Pham, B. Beach, A. Deshpande, A. Ishizaki, W. Fong, and
         K. Wentzel.  Matisse: A Knowledge-based Team Programming Environment.
     In Preparation., 1992.

[GS89]   P. K. Garg and Walt Scacchi.  ISHYS: Designing an Intelligent Software
         Hypertext System.  IEEE Expert, pages 52--63, Fall 1989.

[GS90]   P. K. Garg and W. Scacchi.  A  Hypertext System to Manage Software
         Life Cycle Documents.  IEEE Software, pages 90--98, May 1990.

[Kru89]  Charles W. Krueger.  Models of Reuse in Software Engineering.
     Technical Report CMU-CS-89-188, School of Computer Science, Carnegie
         Mellon University, Pittsburgh, PA 15213, December 1989.

[Nei91]  James M. Neighbors.  Draco: A Method for Engineering Reusable Software
         Systems.  In Ruben Prieto-Diaz and Guillermo Arango, editors, IEEE
         Tutorial: Domain Analysis and Software Systems Modeling , pages 34--52.
     IEEE Computer Society Press, 1991.  Original article appeared in 1989.

[Ost87]  Leon Osterweil.  Software Processes are Software too. In Proceedings of
         the International Conference on Software Engineering, pages 2--13,
     April 1987.

[Roy88]  Winston W. Royce.  Managing the Development of Large Software Systems.
         In Richard H. Thayer, editor, IEEE Tutorial: Software Engineering
     Project Management , pages 118--127. IEEE Computer Society Press, 1988.
         Original article was published in 1970.