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

Text File | 1993-06-02 | 8KB | 140 lines

Process-Driven Environments as Reusable Application Development Frameworks

Walt Scacchi

Decision Systems Dept.
School of Business Admininstration
University of Southern California
Los Angeles, CA 90089-1421
[phone] [phone] (fax)
email: [e-mail]


                           Abstract

For the past few years, we at the USC System Factory Project have been
developing a process-driven knowledge-based environment for modeling,
analyzing, simulating, and enacting software development processes.  In this
position paper, I describe some highlights, concepts, and opinions regarding
our approach to constructing a variety of domain-specific development
environments and applications.

Keywords:  process reuse, reuse process models, process-driven tools and
       environments, domain-specific application frameworks

Workshop Goals:  Learning; networking; advance state of process-driven
         environment frameworks as a reuse strategy

Working Groups:  reuse process models, reuse environments.


1  Background

For the past few years, we at the USC System Factory Project have been
developing a process-centered knowledge-based environment for modeling,
analyzing, simulating, and enacting software development processes.  This
environment has been employed to both synthetic and real industrial software
processes for developing large software applications. This environment serves
as a framework that provides object-oriented interfaces for data, control
(tool), and process integration through a graphic user interface.


2  Position

Software development frameworks, both in commercial form (e.g., HP Softbench,
Atherton Software Backplane (CIS), SUN ToolTalk, DEC Cohesion) and in advanced
research form, are becoming increasingly recognized as a viable reusable
solution to the problem of constructing software engineering environments or
domain-specific applications. These frameworks provide a skeletal solution for
how to integrate new/existing tools or utilities as reusable environment
building blocks. Also, there is quite a bit of variation in the coverage and
facilities that the framework provides, as well as the level of effort required
to use the framework in environment construction.

In our view, framework-based approaches have the potential to be extended in
ways that can enable the semi-automated generation of engineering environments
or domain-specific applications through the composition and integration of
large - or very large - grain software components for an interesting variety of
industrial application domains.  We refer to this approach as "environment
generation" using a "meta-environment."

We have developed  employed a declarative specification for describing how
different component tools are bound to different developer tasks, roles, and
product elements.  The specification notation establishes the relationships
among the different components. Both the product elements and tool components
must be previously encapsulated in an object-oriented format (although not
necessarily implemented in an object-oriented way) that is common to the
integration scheme employed in the framework. Component tools which make the
fewest assumptions about their run-time environment are the easiest to
encapuslate, while those which come embedded within closed systems are the most
difficult to accomodate.  As such, we can either prototype or compose a
domain-specific environment in a manner somewhat analogous to the use of an
application generator.  In this way, the specification notation serves as the
input to the environment generator, which then constructs the necessary
bindings to interconnect inter-component data and control flow. Thus, we use a
domain-independent environment generator to construct a domain-specific
development environment.

What makes the resulting development environment domain-specific is the
specification of the different components that are specific to the application
domain. In this way, if our development goal is to prototype and then construct,
for example, a concurrent engineering environment for electronic design
automation, then we could proceed as follows: First, we must identify the tasks,
agents, provided and required product elements, and development tools (in this
situation, EDA tools such as schematic layout editors, netlist database, and a
VHDL silicon compiler) then specify their relations (e.g., task decomposition,
sub-task precedences, tool to sub-task bindings) using the input notation.
Since the specification notation conforms to the environment meta-model, and
each encapuslated component conforms to the semantics (class definitions and
inheritance relations) of the meta-model, then any well-formed environment
specification will lead to the instantiation of an application-specific
environment that conforms to the specification. This means we can first
prototype the concurrent engineering environment for EDA, using only component
place-holders, in order to assess the viability of different user-environment
interaction scenarios.  Then, when the encapsulated components become
available, they can be bound into an environment instance by re-evaluating
the specification.

In the course of engineering and refining our approach to the semi-automated
construction of domain-specific environments, we have built a handful of
application environments for domains such as medical clinic information
systems, CAD-CAM, computer music composition, payroll and personel, as well as
a number of software engineering environments. Most of these experiments were
just that, meaning the resulting environments we throw-aways,  although is
most cases the volume of source code composed into the target environment was
well over a 100K LOC.  Using the current meta-environment, together with a set
of pre-encapsulated components, putting an operational domain-specific
environment primarily boils down to the effort to construct the specification
of the target environment and its domain-specific tasks, product elements,
agents, and tools, as well as the relations between. While this is a dramatic
simplification of the effort required, it does in our view demonstrate the
basic viability of this approach to the reuse of process-driven environment
frameworks as the basis for rapidly constructing domain-specific development
environments and applications.


3  Biography

Walt Scacchi received a B.A. in Mathematics, a B.S. in Computer Science in 1974
at California State University, Fullerton, and a Ph.D. in Information and
Computer Science at University of California, Irvine in 1981. He is currently
an associate research professor in the Decision Systems Dept. at USC.  Since
joining the faculty at USC in 1981, he created and continues to direct the USC
System Factory Project.  This was the first software factory research project
in a U.S. university. Dr. Scacchi's research interests include very large scale
software production,  knowledge-based systems for modeling and simulating
organizational processes and operations, CASE technologies for developing large
heterogeneous information systems, hypertext/media environments for everything,
software technology transfer and transition, and organizational analysis of
system development projects. Dr. Scacchi is a member of ACM, IEEE, AAAI,
Computing Professionals for Social Responsibility (CPSR), and Society for the
History of Technology (SHOT).  He is an active researcher with more than 70
research publications, and numerous consulting and visiting scientist postions
with firms including AT&T Bell Laboratories, Microelectronics and Computer
Technology Corporation (MCC), Software Engineering Institute at Carnegie-Mellon
University, SUN Microsystems, Perceptronics, and Hewlett-Packard.  Otherwise,
he also attended the previous software reuse workshop in 1991, and his other
interests in the practice of software reuse are described in his position paper
for that workshop.