Engineering Software Design Processes to Guide Process Execution.
AbstracttUsing systematic development processes is an important characteristic of any mature engineering discipline. In current software practice, Software Design Methodologies (SDMs) are intended to be used to help design software more systematically. This paper shows, however, that one well-known example of such an SDM, Booch Object-Oriented Design (BOOD), as described in the literature is too imprecise and incomplete to be considered as a fully systematic process for specific projects. To provide more effective and appropriate guidance and control in software design processes, we applied the process programming concept to the design process. Given two different sets of plausible design process requirements, we elaborated two more detailed and precise design processes that are responsive to these requirements. We have also implemented, experimented with, and evaluated a prototype (called Debus-Booch) that supports the execution of these detailed processes.
Introduction
If software engineering is to make solid progress
towards becoming a mature discipline, then it must
move in the direction of establishing standardized, disciplined
methods and processes that can be used systematically
by practitioners in carrying out their routine
software development tasks. We note that such
standardized methods and processes should not be totally
inflexible, but indeed must be tailorable and flexible
to enable different practitioners to respond to what
This research is supported by the Advanced Research
Projects Agency, through ARPA Order #6100, Program Code
7E20, which was funded through grant #CCR-8705162 from the
National Science Foundation. This work is also sponsored by
the Advanced Research Projects Agency under Grant Number
MDA972-91-J-1012.
is known to be a very wide range of software development
situations in correspondingly different ways.
Regardless of this, however, the basis of a mature discipline
of software engineering seems to us to entail
being able to systematically execute a clearly defined
process in carrying out these tasks. In this paper we
refer to a process as being "systematic" if it provides
precise and specific guidance for software practitioners
to rationally carry out the routine parts of their work.
As design is perhaps the most crucial task in software
development, it seems particularly crucial that
software design processes be clearly defined in such a
way as to be more systematic. Humphrey [Hum93]
says that "one of the great misconceptions about creative
work is that it is all creative. Even the most
advanced research and development involves a lot of
routine. The role of a process is to make the routine
aspects of a job truly routine." We agree with
this, and believe that design as a creative activity still
contains a lot of routine which can be systematized.
For example, making each design decision is probably
creative (e.g, deciding if an entity should be a class
when using an object oriented design method). How-
ever, the order of making each of these related design
decisions can be relatively more systematic (e.g.,
identify each class first and then define its semantics
and relations). We also anticipate that with progress
in design communities, design methodologies will provide
more routine which can be systematized. This
will help adapt SDMs into practice more easily and
thus improve productivity and software quality.
This paper describes our work that is aimed at this
goal-namely to make SDM processes more systematic
and thus more effective in guiding designers. This
work begins with the assumption that the large diversity
of Software Design Methodologies (SDM's) provides
at least a starting point in efforts to provide
the software engineering community with such well-defined
and systematic design processes. This paper
concentrates on the Booch Object Oriented Design
Methodology (BOOD) [Boo91] in order to provide
specificity and focus. The paper shows, however,
that BOOD, as described and defined in the litera-
ture, is far too vague to provide specific guidance to
designers, and is too imprecise and incomplete to be
considered a very systematic process for the needs of
specific projects. On the other hand, we did find that
BOOD could be considered to be a methodological
framework for a family of such processes.
Our work builds upon the basic ideas of process programming
[Ost87], which suggest that software processes
should be thought of as software themselves,
and that software processes should be designed, coded,
and executed. That being the case, we found that
BOOD, as described in the literature, is far closer to
the architecture, or high-level design, of a design process
than to the code of such a process. As such,
BOOD is seen to be amenable to a variety of detailed
designs and encodings, each representing an elaboration
of the BOOD architecture, and each sufficiently
detailed and specific that it can be systematic in a way
that is consistent with superior engineering practice in
older, more established engineering disciplines.
In the remainder of this paper we indicate how and
why we believe that BOOD should be considered a
software design process architecture. We then suggest
two significantly different detailed designs that can be
elaborated from BOOD, each of which can be viewed
as a more detailed elaboration upon the basic BOOD
architecture. We show that these elaborations can be
defined very precisely through the use of such accepted
software design representations as OMT [RBP
and through the use of process coding languages such
as APPL/A. Indeed, this paper shows that the use
of such formalisms is exactly what is needed in order
to render these elaborations sufficiently complete and
precise that they can be considered to be systematic.
Thus, the paper indicates a path that needs to be
traveled in order to take the work of software design
methodologists and render it the adequate basis for a
software engineering discipline.
First (in Section 2), we define the process architecture
provided by BOOD, and then describe two
processes elaborated from the architecture. Second
(in Section 3), we describe a prototype that supports
designers in carrying out the execution of these pro-
cesses, illustrating how these differently elaborated
processes support different execution requirements.
Third (in Section 4), we describe our experience of
using the prototype and summarize some of the main
issues that have arisen in our efforts to take the design
process architectures that are described in the
literature to the level of encoded, systematic design
processes.
2 The BOOD Architecture and Two
Elaborations
2.1 Overview of BOOD
We decided to experiment with BOOD because
BOOD is widely used, and provides a few application
examples that are very useful in helping us to identify
the key issues in elaborating BOOD to the level of ex-
ecutable, systematic processes. A detailed description
of BOOD can be found in [Boo91]. In this section, we
present only a brief description of the architecture of
the BOOD process. We believe that it can be summarized
as consisting of the following steps:
1. Classes/Objects: Designers must
first analyze the application requirements specification
to identify the most basic classes and
objects, which could be entities in the problem
domain or mechanisms needed to support the re-
quirement. This step produces a set of candidate
classes and objects.
2. Determine Semantics of Classes/Objects:
Designers must next determine which of the candidate
classes should actually be defined in the
design specification. If a class is to be defined,
designers will determine its semantics, specifying
its fields and operations.
3. Define Relations among Classes: This step
is an extension of step 2. Designers must now
define the relationships among classes, which include
use, inheritance, instantiation and meta re-
lationships. Steps 2 and 3 produce a set of class
and object diagrams and templates, which might
be grouped into class categories.
4. Implement Classes: Designers must finally select
and then use certain mechanisms or programming
constructs to implement the classes/objects.
This step produces a set of modules, which might
be grouped into subsystems.
BOOD provides more hints and guidelines on how
to carry out these steps. However, BOOD provides
no further explicit elaboration on the details of these
steps. Thus designers are left to fill in important details
of how these complex, major activities are to be
done. As a result, there is a considerable range of variation
and success in carrying out BOOD. Further, the
process carried out by those who are relatively more
successful is not documented, defined or described in
a way that helps them to repeat it effectively, or for
them to pass on so that others can reuse it. We believe
that this is the sense in which BOOD, as described in
the literature, is a process architecture. It provides
the broad features and outlines of how to produce a
design. It supplies elements that can be thought of
and used as building blocks for specific approaches to
design creation. On the other hand, it provides no specific
guidance, details or procedures. These are to be
filled in by others who, we claim, then become design
process designers (e.g., the authors of [HKK93]) and
implementors when the method is applied to specific
projects or organizations.
2.2 Process Definition Formalism
Earlier experiences [KH88, CKO92] have shown
that the State-Charts formalism [HLN + 90] is a powerful
vehicle for modeling software processes. Thus,
we use a variant of State-Charts [HLN + 90], the dynamic
modeling notation of the Object Modeling
Technique 91], to model the processes
that we will elaborate from BOOD. As shown later,
we believe these dynamic models of BOOD processes
are sufficient to demonstrate our point
Generally, our approach is to use the notion of a
state (denoted as a labeled rounded box) to represent a
step of a BOOD process, the notion of an activity (the
text inside a rounded box and after "Do:") to represent
a step which does not contain any other steps. According
to OMT, the order for performing these activities
can be sequential, parallel or some other forms. We
use the order in which the activities is listed to recommend
a plausible order for performing those activities.
A transition (denoted as a solid arc) denotes moving
from one design step to another. The text labels on
a transition denote the events which cause the transi-
tion. The text within brackets indicates guarding conditions
for this transition. The text within parentheses
denotes attributes passed along with the transition. A
state could have sub-states, each of which denotes a
sub-step of the step.
Indeed, a modelling formalism is generally inadequate
for characterizing certain details of processes.
We found that sometimes it was necessary to specify
these details in order to render the process we were attempting
to specify sufficiently precisely that it could
realistically be considered to be systematic. For ex-
ample, OMT does not provide a capability for specifying
the sequencing of two events which are sent
by the same transition. Specification of this order
might well be the basis for important guidance to a
designer about which design issues ought to be considered
before which others. Thus, we found it necessary
to supplement OMT, by using a process coding
language called APPL/A [SHO90b] to model such
details. APPL/A is a superset of Ada that supports
many features that we found to be useful. Some examples
of APPL/A code are also provided in subsequent
sections of this paper.
Note that the goal of this work is to use these process
models and codes to demonstrate the diversity
and details of the processes that can be elaborated
from an SDM. As shown later, these dynamic models
of BOOD processes are sufficient to demonstrate this
point. Thus, we did not develop OMT's object models
and function models for BOOD processes.
2.3 Modeling the BOOD Architecture
Fig. 1 represents an OMT model of the original
BOOD process architecture, as described in [Boo91].
In this architecture, we merged step 2 and 3 of
the original BOOD process because our experience
shows that it is hard to separate those steps in practice
(Booch himself also considers that step 3 is an
extension of step 2 [Boo91]). We believe that this
model is considerably more precise than the informal
description originally provided. It is still quite vague
and imprecise on many important issues, however.
Booch [Boo91] claims that this vagueness is necessary
in order to assure that users will be able to tailor and
modify it as dictated by the specifics of particular design
situations. For example, step 2 of Fig. 1 does not
define the order for editing various BOOD diagrams
and templates. It does not define clearly which of the
diagrams or templates must be specified in order to
move from step 2 to step 3. Booch claims that different
designers might have important and legitimate needs
to elaborate these details in different ways (Chapters
8-12 of [Boo91] provide a few examples).
We found that there are indeed many ways in which
these details might be elaborated precisely and that
many of these different variants might offer better
guidance. The differences might well arise from differences
in application, differences in organization, differences
in personnel expertise, and differences in the
nature of specific project constraints. Once these differences
have been understood and analyzed, however,
the design process to be carried out should be defined
with suitable precision. Such precise definitions are
needed in order to support adequate improvements of
the efforts of novices. In addition, we believe that
there are expert designers who have internalized very
3. Implement Classes and Objects
Do: Browse Class/Object Diagrams
(Requirements)
(The change list) User initiates the transition
[No inconsistency is found]
(Proposed modification)
(Requirements exist)
User initiates the transition
Edit Object Diagram
Edit State Transition Diagram
Edit Module Diagram
Edit Process Diagram
Edit Moduel Template
Edit Process Template
[Candidate Classes/Objects are defined]
User initiates the transition
(The change list)
Changes to candidates
(List of candidates)
Edit Class Template
Edit Timing Diagram
Do: Browse Candidate Classes/Objects
2. Identify the Semantics of Classes/Objects
Edit Object Template
Edit Class Diagram
List candidate classes/objects
Nouns
1.
Do: Read requirements
Edit Data Flow Diagram
User initiates the transition
(Class/object, and some other diagram/templates)
[Class/Object diagram/template defined]
Changes to the class/object diagram/templates
Find inconsistency in class/object diagrams/templates
(Proposed modification)
User initiates the transition
User initiates the transition
(Proposed modification)

Figure

1: A Process Architecture of BOOD
specific and very effective elaborations of the BOOD
architecture and that the more these are defined pre-
cisely, the more important design expertise may be
understood, reused, automated, and improved.
In order to make the above remarks specific, we
now discuss two possible elaborations of the BOOD
architecture. In addition, using these examples we can
show the need for, and power of, both design and code
representations as vehicles for making design processes
clear and thereby providing more effective guidance.
2.4 Two Examples of BOOD Process Refinement

2.4.1 Examples of Software Project Types
First, we characterize two different types of projects
for which we will elaborate variants of design pro-
cesses, within the outlines of the BOOD architecture
(see Project Properties columns in Table 1). The parameters
of these characterizations are 1) implementation
language, documentation requirements,
project schedule, designer skill, 5) software operation
domain, software domain, and 7) maturity of
the software domain.
Based upon our experiences, we identified these two
project types as representatives of projects commonly
encounted in software engineering practice (see Table
1). For example, an instance of project type 1
could be a defense-related or a medical systems project
while an instance of project type 2 could be a civilian
project. We expected that elaborating processes
to fit the requirements of these two different types of
projects would help us understand the range of processes
that could be elaborated from BOOD.
The seven characterization parameters were chosen
because our earlier work indicated that these parameters
are likely to have major and interesting effects
upon design process elaboration. For example, when
consulting with Siemens medical companies, we found
that the U.S. Food and Drug Administration (FDA).
has specific documentation requirements, and requires
control and monitoring of corrective actions on the
product design. [FDA89] says that "when corrective
action is required, the action should be appropriately
monitored. Schedule should be established for completing
corrective action. Quick fixes should be pro-
hibited." This certainly affects how an SDM should be
applied to a specific project.
The application examples described in [Boo91] also
provide us with some details that seemed likely to be
useful in employing these parameters to help us to derive
these BOOD-based design processes. For exam-
ple, one of Booch's examples indicates that if C++ is
to be the eventual application coding language, then
class/object diagrams would not need to be translated
into module diagrams. In addition, Booch's problem
report application example [Boo91] helps us to understand
the process requirements for developing an information
processing system. For instance, that example
shows that the method must be tailored to support the
design of database schemas. His traffic control example
helps us to understand the process requirements
for developing a large scale, device-embedded system.
2.4.2 The Processes Elaborated from BOOD
In this section we present portions of the OMT diagrams
used to define details of each of these two
elaborations on the basic BOOD architecture. We
then further refine parts of them down to the level
of executable code. Each of these processes is clearly
a "Booch Design Process", each represents what we
consider to be a completely plausible design process,
and each is quite completely and precisely defined-to
the point of being systematic for the specific kinds of
projects. These two processes demonstrate the point
that there is a great deal of imprecision in the current
definition of "Booch Object-Oriented Design." They
also indicate how BOOD can be elaborated, and what
the range of elaboration might be when it is applied
to specific projects.
We will refer to our first elaborated process as
the Template Oriented Process (TOP). It emphasizes
defining various BOOD templates (e.g., the class tem-
plate) as it hypothesizes the importance of carrying
1. A Template Oriented Example 2. A Diagram Oriented Example
Project Properties Process Requirements Project Properties Process Requirements
Must be coded in Ada Specify Module Diagram Must be coded in C++ Guide designers not to specify Module
Diagram since it is not needed in this case.
Must incorporate very Requires specification of Only minimum documentation No need to enforce
complete documentation all templates required specifying all templates
Long-term Allow full documentation Short-term Encourage use of existing code
Skilled design team Less process guidance Inexperienced design team More process guidance
More process flexibility Less process flexibility
Safety-critical More change control needed Non safety-critical Less change control needed
(e.g., Medical Systems) to satisfy FDA's requirements
Large scale, Use structured analysis Information processing system Single, familiar domain.
device-embedded system Support partitioning domain Need to support schema design
State of the art project Need to support prototyping Well-understood No support for prototyping needed.
Need to support code reuse

Table

1: Project Characteristics and Process Requirements
out a design activity that delivers very complete doc-
umentation. The TOP's emphasis on complete documentation
can be seen by noting that we have refined
steps 2 and 3 of Fig 1 into the more detailed model
defined in Fig. 2.
We further hypothesized in designing the TOP that
the software to be developed is to be safety-critical,
and that, therefore, the TOP should enforce more control
over design change as this is often required by
government agencies to ensure product quality. Accordingly
note that the high level design of the TOP
incorporates an approval cycle for all changes to previously
defined artifacts.
On the other hand, we hypothesized that the TOP
is to be executed by skilled and experienced designers.
Because of this, we did not refine the detailed design
activities into lower level steps. Our expectation here
is that such designers would insist upon freedom and
flexibility that this would be given them. This also
illustrates that it is possible to define a design process
precisely, yet still provide considerable freedom and
flexibility to practitioners. In addition we designed
the TOP to allow for a certain degree of flexibility
in making transitions from one step to another. We
have also included the possibility of incorporating a
prototyping subprocess into this process.
We refer to our second elaborated process as the
Diagram Oriented Process (DOP), as it emphasizes
specifying BOOD diagrams. We derived this process
from Booch's Home Heating System example [Boo91].
In the DOP we hypothesized that there are only weak
requirements in the area of documentation, and we,
therefore, do not design in the need for designers to
specify BOOD's templates (see Figures 4). We also
hypothesized that the product being designed will be
coded in a language that provides direct support for
programming classes and objects. For this reason, the
DOP omits step 3 of the general model shown in Fig. 1
as part of its elaboration, leaving the model defined in
Fig. 4. Note that this elaboration incorporates fewer
top-level steps than the general BOOD model does.
We also hypothesized that the DOP is aimed at
supporting novice designers, and so the DOP provides
detailed guidelines for identifying classes/objects (see

Figures

5, 6, and 7). In addition, the DOP assumes
that a great deal of importance is placed upon reuse.
In response, the DOP incorporates steps that guide
designers to reuse existing software components (see
Fig. 7).
The job of creating more specific and detailed elaborations
of BOOD is not limited solely to modification
of the processing steps of BOOD. It also entails specifying
the flow of control between these steps and their
substeps. A good example of the importance of these
specifications can be seen by examining how change
management is handled in these design processes.
We use the term forward change management to
denote a transition used to maintain consistency between
a changed artifact and its dependent artifacts,
that are normally specified at a later stage of the pro-
cess. For example, a designer may add a class to a
candidate class list (in step 1 of Fig. 2) . This results
in forcing designers to redo step 2 to consider adding
a corresponding class to the class diagram. There is
virtually no guidance in BOOD about precisely how
this is to be done, or how the critical and tricky issues
of consistency management are to be addressed. Thus
there is a clear need for more detailed guidance on
automatic change control. One way this can be done
is to refine this high-level transition further as shown
in Fig. 8. In Fig. 8, a dotted line from a transition
to a class represents an event sent by the transition.
For example, the transition from Selected Class A to
Rejected Class A, which is caused by updating candidate
class A's field Needed to FALSE (i.e. class A
is no longer needed), sends event Delete Class A to
class Class. Clearly this refinement is simply one of a
very large assortment of possible refinements. We do
not claim that it is the only one or the "right" one.
We do claim, however, that supplying details such as
these provide specific guidance that is important for
designers-especially for novice designers and for large
design teams. Should it turn out that such a specifically
designed process is shown to be particularly useful
and desirable, then the detailed specification will
also render it more amendable to computer support.
We should also note that we did not stop at the level
of design diagrams in refining the meaning of forward
change management, but that we went further and defined
it as actual executable process code. Our code
was written in the APPL/A process coding language.
Fig. 9 shows the APPL/A code for the process defined
in Fig. 8. Note that this code provides even more de-
tails. For example, note that this code specifies that
changing a candidate class to a candidate object will
cause an ordered sequence of events: 1) the insertion
of an object template, 2) the removal of the class template
and 3) the forwarding of that template to step
3 for editing of the object template. Again, we stress
that these specific details are not to be considered the
only feasible elaboration of BOOD-only one possible
elaboration. We do believe, however, that in specifying
the design process to this level of detail deeper
understandings result, and the process becomes more
systematic. In addition, by reducing the process to
executable APPL/A code, it becomes possible to use
the computer to provide a great deal of automated
support (e.g., some types of automatic updating and
consistency maintenance) to human designers.
Another kind of control flow in BOOD is backward
change management, which is aimed at maintaining
consistency between a specified artifact and all the
artifacts upon which the specified artifact should de-
pend. These artifacts are normally defined at earlier
stages of the process. For example, in step 2 of Fig. 2,
designers may need to define a class in a class diagram
and find that this class does not correspond to
any candidate class because of an incomplete or faulty
analysis of the application requirements. Thus, designers
have to go back to earlier steps, reviewing the
requirements and possibly redoing step 1 to add this
class to the candidate class list. This transition can
be refined and coded in a manner similar to what was
described in the case of forward change management.
Do: Browse Requirement
Browse Candidate Classes/Objects
Edit Class Diagram
Edit State Transition Diagram
Edit Object Diagram
Do: Browse Class Diagram
Browse Object Diagram
Edit Class Templates
Edit Class Utility Templates
Edit Object Templates
Do: Browse Object Diagram
Browse Class Diagram
Edit Module Diagram
Edit Process Diagram
Edit Device Template
Edit Process Template
Edit Module Template
Do: Browse Module Diagram
Determine Semantics of Class
Step 3 Specify Class/Object Templates
Develop Module Diagram
Specify Module Template
Step
[No inconsistency is found]
[Requirements exist]
User initates the transition
Class/Object
Find inconsistencies in Candidate Class/Object Diagrams
(List of Candidate Class/Objects)
[Candidate Classes/Objects are defined and reviewed]
User initiates the transition
User initiates the transition (Class/Object diargam)
User initiates the transition
Step
(Requirements)
Changes to candidates
(Changed List)
[The changes are approved]
Diagrams
Changes on
(Changed diagrams)
[Class/Object diagrams are reviewed]
[The changes are approved]
(Changed List)
Changes to candidates
[The changes are approved]
Find inconsistencies in
class/object templates
[Modification is approved]
[Modification is approved]
class/object diagrams
Find inconsistencies in
[Modification is approved]
Find inconsistencies in Class Diagram
Changes to
class/object templates
(Class/Object Templates)
[The changes are approved]
User initiates the transition
(Class/Object Diagrams)
(Class/Object Templates)
[Class/Object Templates are reviewed]
Find inconsistencies in
module diagram
[Modification is approved]
User initiates the transition
(Module diagrams)
[Module diagrams are being defined]
Changes to
module diagram
(Changed module diagram)

Figure

2: Top-level Process Definition of the Template
Oriented Process
These process definitions, including both main flow
and change management transitions, explicitly and
clearly demonstrate how the published Booch Object
Oriented Design description can be elaborated into
a precisely defined process to provide more effective
guidance for specific projects. Our research indicates
that this observation is quite generally applicable to
the range of SDM's that are currently being espoused
widely in the community. There are a number of reasons
for this imprecision. We have already noted that
the imprecision is there intentionally to permit wide
variation in design processes to match similarly wide
design process contexts and requirements. While we
neither doubt nor dispute this need, we believe that
our work has shown that it can be met more effectively
through tailoring SDMs for specific needs of projects.
These processes resulting from the tailoring, and supported
by the appropriate tools, provide more effective
guidance and help implement various recommended
practices (e.g, those recommended by FDA [FDA89]).
In the next sections, we discuss how to support the execution
of the elaborations of the BOOD architecture
that we have just described.
Do: Browse Requirement
Do: Browse Requirements
Edit Data Flow Diagram
Do: Edit Object Diagram
Edit Class Diagram
User initiates the transition
Inappropriate Problem Definition
Step 1.1
Step 1.2
Problem Boundary
Structured Analysis Step 1.4 Prototyping
User initiates the transition
Problem
(Proposed new definition)
(Problem
User initiates the transition
[Definition is approved]
(Problem
User initiates the transition
Domain Analysis
Step 1.3
Do: Browse Requirements
Edit Candidate Class/Objects
User initiates the transition(Data Flow Diagrams)
(Problem
[Definition is approved]
(Candidate class/object)
[Candidate Class/Objects exist]
Step 1. Identify Candidate Class/Object

Figure

3: Second-level Process Definition of Template
Oriented Process: Refinement of Step 1
2. Identify the Semantics of Classes/Objects
(Requirements)
(The change list)
(Requirements exist)
User initiates the transition
(Design specification)
[No inconsistency is found]
1.
Change to
Candidates
User initiates the transition
(List of candidates)
[Candidate Classes/Objects are defined]
Do: Browse Candidate Classes/Objects
Edit Class Diagram
Edit Object Diagram
Edit State Transition Diagram
Edit Timing Diagram
User initiates the transition
Find inconsistency between candidates and
class/object diagrams
(Proposed modification)

Figure

4: Top-level Process Definition of Diagram Oriented
Process
Do: Browse Requirement
Problem Definition
Inappropriate Problem Definition
Step 1.1 Define Problem Boundary
(Proposed definition)
Domain Analysis
Step 1.2
1.3 Reuse-based Design
User initiates the transition and
(Candidate Classes/Objects)
User initiates the transition and
[Problem is defined]
(Candidate Abstract Class)
User initiates the transition and
Step 1. Identify Candidate Class/Object

Figure

5: Second-level Process Definition of Diagram
Oriented Process
Search for Noun
Search for Verb
Search for Adjective
Key Abstractions
Do: Browse Requirement
Candidate Classes/Objects
Do: Identify Classes from Nouns
Decide Operations from Verbs
Objects from Nouns
(Identified nouns, verbs, adjectives)
User initiates the transition (Change List)
Nouns/Verbs/Adjective
Changes on
Domain Analysis
Step 1.2
Step 1.2.1
Step 1.2.2

Figure

Third-level Process Definition of Diagram
Oriented Process : Refinement of Domain Analysis
Reusable Components
Develop Object Diagram for the
Edit the Concrete Classes
Concrete Classes
Instantiate the Abstract Class to
User initiates the transition
User initiates the transition
User initiates the transition
(Concrete Class)
User initiates the transition
Abstract Class
Change on reusable
components
Change on semantics
of the abstract class
1.3. Reuse-based Design
Change on the object diagram
(New components)
(New object diagram)
(Completed concrete classes)
(Abstract classes)
(Abstract classes)
Class

Abstract

Classes, Reusable Components)
(Reusable Components, Candidate Classes)
User initiates the transition
(Object Diagram, Candidate Classes)
Find new sharable objects
(Description of the objects)

Figure

7: Third-level Process Definition of the Diagram
Oriented Process : Refinement of Reuse-based
Design, which is based on Booch's Home Heating System
example
3 Support for Executing BOOD Pro-
To experiment with our ideas and demonstrate how
these processes should be supported appropriately, we
have developed a research prototype, called Debus-
Booch, to support the execution of design processes
of the sort that have just been described. Execution of
such processes is possible as a result of their encoding
in APPL/A, a superset of Ada that can be translated
into Ada, and then compiled into executable code.
We note that BOOD addresses only issues concerned
with supporting single users working on a single
design project. As most designers must work in teams,
and are often engaged in multiple projects simultane-
ously, a practical system for support of such users must
do more than simply execute straightforward encodings
of BOOD elaborations. Our Debus-Booch prototype
adapts an architecture used in a previous research
prototype (Rebus [SHDH 91]). The architecture lets
developers post (to be done) and submit (finished)
tasks to a whiteboard to coordinate their task assign-
ments. Since this work has been published and is not
directly related to the topic of this paper, we will not
describe it here.
Selected Class A
Insert
Rejected Class A
Update
Rejected Class B
Update
Update
Update
[No existing class has name A]
[No existing class has name A]
Insert
Selected Class B Terminated
Update
Delete
Selected Object A
Update
Rejected Object A
Class
Object
Insert the Class
Update
Delete Class A
Delete Class A
Delete Class A
Insert Class A
Insert Object A

Figure

8: A Refinement of Forward Change Man-
agement: illustrates more precisely how a change
in the candidate list might affect the class dia-
gram/templates. A candidate is recorded with three
fields: name, needed (indicating if it is selected as an
candidate), and kind (indicating that it is a class or
In addition, there are a variety of difficult user interface
issues to be faced in implementing a system
such as this. Exhaustive treatment of all of these issues
is well beyond the scope and limitations of this
paper. An indication of our approaches to these and
related problems can be seen from the following brief
implementation discussion.
3.1 System Overview
Debus-Booch provides four levels of process guidance
and support to its end-users (see Fig. 11 for their
user interface representations):
1. Process Selection (Accessed through a
This enables users to select
any of a range of elaborations of the BOOD ar-
chitecture, or any non-atomic step of any such
elaboration (as shown in Fig. 10). This is done
by selecting a driver to perform a constrained sequence
of steps at a certain level of the selected
process step hierarchy. Debus-Booch helps users
with this selection by furnishing users with access
to information about the nature of these various
processes and steps.
with candidate-rel, class-template;
trigger maintain-candidate;
- maintain the product of step 1
trigger body maintain-candidate is
begin
loop
trigger select
upon candidate-rel.update
needed
new-name
update-needed
new-needed
new-kind
completion do
change management is necessary only when
- candidate is selected or being updated.
case kind is
when class =?
- the candidate is no longer needed
class-template.delete(name =? name);
else
- the candidate becomes needed
class-template.insert (name =? name, .);
query (pname, plen, sname, slen);
define-class-proc(pname,plen,sname, slen);
class-template.update (name =? name,
update-name =? TRUE,
new-name =? new-name);
or (new-needed = TRUE and
case new-kind is
when object =?
object-rel.insert (name =? name);
class-template.delete (name);
when operation =? .
when abstract-class =? .
case
upon
or
select

Figure

9: APPL/A code for defining Forward Change
Management between candidate class list and class di-
agram/template definitions
Process 1 . Process N
Step 1.1 Step 1.2 Step N.1 Step N.M
Step 1.1.1
Step 1.1.1.1
Process 2
Console
Driver 1.1 Driver 1.2 Driver N.1 Driver N.M
Driver 1.1.1
Panel 1.1.1.1
Tool-Button 1 Tool-Button 2
Support
Initiate
Exclusive Unspecified Order
Constrained Order
Debus-Booch System Interface Architecture
An SDM Model
Criteria Guidline Display Display

Figure

10: An SDM definition and support model
2. Process Step Execution (Accessed through
a Panel): The user can obtain support for the
sequencing and coordination of the driver activities
to be performed in an elaborated design pro-
cess. These activities can be divided into two cat-
egories: required and optional activities. For ex-
ample, in the step used to determine the semantics
of classes, designers must use Class Diagram
Editor, which therefore supports a required activ-
ity; in the same step, designers may use a requirements
browser, which therefore supports an optional
activity. Designers can invoke all the tools
that support the required activities by clicking
on the Set Environment button. In using this access
method, we help designers to set up a design
environment more easily. Note that different processes
may have different required activities. For
example, in the template oriented process (TOP),
editing the class template is a required activity.
However, in contrast, using the diagram oriented
process (DOP), the user cannot even access this
editor.
3. Atomic activity/support (Ac-
cessed through a Tool-Button): The user can
obtain support for a specific activity in an atomic
step. For example, the user can request access to
a Class Diagram Editor in order to obtain support
for defining a class diagram, which is an activity
performed in determining the semantics of
classes.
4. Documenation and Help Support (Ac-
cessed through Displays): This support can
be obtained in conjunction with the use of tools
that support atomic activities. The displays that
are made available convey a variety of informa-
tion, such as the criteria, guidelines, examples,
and measures [SO92] to be used to help designers
understand how to carry out the activity.
Debus-Booch provides the flexibility that is needed
for experienced designers. Designers can use a console
display to access all of the supports listed above. For
example, a designer can click on the Console's Steps
button to execute any step of any elaborated BOOD
process (as long as the guarding condition for this step
is satisfied, otherwise, the invocation will be rejected).

Figure

shows how these four types of support
are made available to the designers who use Debus-
Booch. In particular the figure indicates the degrees
of interactions that are allowed among the supports
for processes, steps, and activities. In particular, note
that support for process execution will be provided on
an exclusive basis only, as we believe it is reasonable to
use only one process at a time to design any given sys-
tem, or any major part of a system. Similarly, there
are constraints on furnishing support for the simultaneous
execution of process steps. This is because
there are often data dependencies between steps. On
the other hand, support for simultaneous execution of
activities is unconstrained as many design process activities
must often be highly cooperative in practice.
Some sets of activities must indeed be carried out in
constrained orders. In this case it is necessary to group
them into composite steps. The decisions about allowable
degrees of concurrency were made based on our
observations of the nature and structure of the process
models defined in Section 2.4.2.
3.2 Scenario for Use of Debus-Booch
Here is a general scenario, which indicates how designers
might use Debus-Booch (see Fig. 11):
1. Designers select a specific elaborated BOOD process
from the menu popped up after pressing the
Process button. They may select Process Selector
to retrieve information about these processes.
For each process, the Process Selector describes
the most appropriate situations (e.g., the documentation
requirements, project deadline) under
which the process should be used.
2. Upon clicking on the menu item (i.e. a selected
process), the corresponding driver will be initi-
ated. Then, designers must enter the name of the
subsystem to be designed. This subsystem can be
assigned to them from a management process or
a high-level system decomposition process (e.g.,
in our case, it is on the whiteboard [SHDH
3. When the subsystem name has been entered, the
driver will check what design steps have been performed
on this subsystem, and then automatically
set the current sub-step in order to continue
with the design of this subsystem. (This is tantamount
to the process of restarting a suspended
execution of the process from a previously stored
checkpoint.) Then, the designer can click the Run
button to invoke the corresponding sub-driver or
atomic step support.
4. If a sub-driver is initiated, step 3 will be repeated
except designers will not need to enter the sub-system
name again.
5. If atomic step support is invoked, a panel appears
and designers can click on its tool-buttons
to invoke the tools to support the activities that
should be carried out in this atomic step.
6. Having finished this step, designers can click on
the next step using the Steps buttons of the driver
to move the process forward. If the guarding condition
(e.g., see Fig. 2) for the next step is true,
the move will succeed, otherwise, the move will
be rejected. After finishing the final step in the
elaborated process, the designer may go back to
the first step to start another iteration on the
same subsystem, reviewing and revising the artifacts
produced in the previous iteration. Thus,
Debus-Booch also provides supports for process
iteration.
As this scenario illustrates, Debus-Booch provides
different supports for users who are using different process
elaborations. For example, using the template oriented
process, the user will be guided by the driver,
(with enforcement provided by the guarding condi-
tion), to specify the module diagram as is useful when
Ada is used as the implementation language. In con-
trast, using the diagram oriented process, the user will
be directed to not define the module diagram as it is
not considered to be of value when an object-oriented
language is used.
4 Experience and Evaluation
In the past year, we have carried out two experiments
and one evaluation with Debus-Booch. In the

Figure

11: A Stack of Debus-Booch Windows Supporting the Booch Method
first experiment, we used the prototype to develop a
design example: an elevator control system. This is a
real-time system that controls the moving of elevators
in response to requests of users [RC92]. It was used as
an example for demonstrating how the Arcadia consortium
supports the whole software development life-
cycle. The system requires full documentation, and is
to be implemented in Ada. It is safety-critical and
device-embedded. The design team was to include
the lead author and students who had finished the
software design course. Thus, this project has most of
the characteristics described in the Template Oriented
Example (see Table 1).
Our experience with this experiment shows that the
Template Oriented Process (TOP) supported our design
development quite effectively. The process represented
through the drivers and panels guided us
to define the BOOD templates and the module di-
agrams. For example, the designers were guided to
define the problem boundary first and then identify
candidate classes such as Controller, Button, Floor,
and Door. In this experiment, we found that the Set-
Environment button was most frequently used and
was effective in guiding designers to define those required
diagrams and templates. The flexibility offered
by the process allowed the designers to modify some
intermediate design specifications. For example, the
designers often moved back to Step 1 from Step 2 (i.e.,
the Determine Semantics of Class step of Fig. 2) to
modify the candidate classes. However, to ensure system
safety, this process enforced stricter control over
the other backward changes which directly affect the
actual design documentation. For example, the transition
from Step 3 to Step 2 of Fig. 2 was more strictly
monitored. In using the prototype, we found the current
implementation to be too restrictive. Thus, we
think that Debus-Booch needs to provide a number
of, rather than one, methods that can be selected for
controlling the transition. Examples may include: 1)
The modification triggers revision history recording,
2) The modication triggers change notification mech-
anism, and 3) the modication triggers a change approval
process. These example methods support different
degrees of the control over the design process.
In the second experiment we used Debus-Booch to
develop a design for the problem reporting system as
described in [Boo91]. This project fits five characteristics
of the Diagram Oriented Example (See Table 1).
The system is to be coded in C++, has minimum document
requirements, and is not safety-critical. It is an
information processing system and well-understood.
The design team, including the lead author and a software
engineer, however, is more experienced than that
described in the Diagram Oriented Example.
In this experiment our experience were similar to
those in the first experiment. One additional, interesting
experience is that for this well-understood domain
(e.g., design of a relational database schema),
the process (the Diagram Oriented Process (DOP))
could have been designed to be even more specific and
therefore to provide more effective guidance. For ex-
ample, Steps 1.2.2 and 2 should provide guidance to
the normalization of the classes. This seems to indicate
that for building a large system, an SDM might
need to be tailored into a set of different processes,
each of which is most effective for designing certain
kinds of components of the system. For example, a
large system might contain both an embedded system
and a data processing system. That being the case,
both DOP and TOP processes might need to be applied
to developing this system.
We have installed a version of Debus-Booch at
Siemens Corporate Research (SCR). Some technologists
there have used the prototype and evaluated it.
These technologists are specialized and experienced in
evaluating CASE tools and making recommendations
to Siemens operating companies. During their evalu-
ation, the technologists executed the tool and examined
all its important features. Based upon their ex-
perience, the technologists believe that Debus-Booch
should be particularly useful for novice designers because
the tool explicitly supports BOOD's concepts
and processes. Their experience tells us that novice
designers are much more interested in using a well de-
fined, detailed process to guide their design. A tool,
such as Debus-Booch, that explicitly supports an SDM
process should help them to learn the SDM quickly.
Some experiences coming out of these experiments
and evaluation are:
1. Process execution hierarchy (the tree of drivers
and panels in Fig. 10) cannot be too deep: There
are two main reasons for having this sugges-
tion: 1) A deep execution hierarchy needs too
much effort in tracking the detailed process states.
This problem is similar to the "getting lost in
hyperspace" problem found in hypertext system
[Con87]. 2) Need to minimize the time overhead
from transiting between various tools that
support various design steps.
These suggestions clearly reinforce our observations
about the problem of mental and resource
overhead [SO93]. Novice designers are more willing
to accept the overhead to trade for more guidance
while skilled designers are not. However,
the evaluation seems to indicate that even for the
novice designers, the process execution tree cannot
be too deep. The evaluation suggested that
three levels seem to be maximal.
2. Designers had difficulty in selecting processes:
Users need stronger support for selecting pro-
cesses. The textual help message associated with
each process seems to be not sufficient. A more
readable and illustrative method must be developed
to help users to understand the process requirements
quickly, and thereby help users to select
appropriate processes.
3. Support the coordination of designers working at
different steps: Our model focuses on supporting
designers to work in parallel in designing different
software components, or supporting an individual
designer to work in parallel on multiple software
components. However, the current model
is weak in coordinating two designers working on
the same software component at different process
steps. For example, we found that a finished class
diagram might need to be passed to another designer
for defining its module diagram. This often
helps in utilizing the different skills of designers.
4. Need to have stronger support for tracking and
coordinating processes: This suggestion is closely
related to the first suggestion. The evaluation
indicates that the process tracking mechanism is
even more important when the process guides designers
at the relatively low levels of the process.
The process tracking must emphasize indicating
the current state of the process and help designers
understand the rationales and goal for performing
the step.

Summary

Our work in developing elaborations of the BOOD
architecture into more precise design process designs
and code has brought a number of technical issues into
sharpened focus. Generally, we have found that it is
quite feasible and rewarding to develop design processes
down to the level of executable code. Doing so
raises a number of key issues that are all too easily
swept under the rug by process architectures and process
models. Many of these issues have tended to be
resolved informally and in ad hoc ways in the past.
This has stood in the way of putting into widespread
practice superior software design processes. The following
summarizes some of the more important and
interesting findings of this work.
5.1 The Advantages of Detail in Process
Definition
Process modelers often struggle to choose between
general process definitions and specific process defini-
tions. Processes that are too general are often criticized
for providing no useful guidelines. Processes
that are too specific are often criticized as leaving no
freedom to designers. We found that starting with
a specific SDM such as BOOD, and then elaborating
it and making it more specific to the needs of a particular
situation represents a good blending of these
two strategies. Doing this serves to make the resulting
process sharper and more deterministic, and thus
helps to make it more systematic and susceptible to
computerized support. It seems worthwhile to note
that taking this approach is tantamount to pursuing
the process of developing a software design process as
a piece of software, guided by a set of process requirements
and an assumed architectural specification (in
this case the BOOD architecture)
We are therefore convinced of the importance of
dealing with the details when elaborating design process
architectures into designs and code. Here we summarize
these process design issues, and describe how
we addressed them in using our
1. Step selection: An SDM often describes many
"you could do" activities in its process descrip-
tion. In our work we turned many of them
into "you should/must do" or "you should not
do" activities in order to provide more effective
guidance. For example, BOOD suggests specifying
module diagrams. However, when using an
implementation language that directly supports
programming classes and objects, Debus-Booch
guides designers to not specify these diagrams
because they are useless in this specific application
(see Fig. 4).
With our process programming approach to the
elaboration of specific processes we also found it
straightforward to specify how to incorporate various
other related processes (e.g., reuse, proto-
typing) into the design process (see figures 3, 5
and 7 for example).
2. Refinement selection: An SDM generally provides
its guidance as a set of high-level steps.
Each high-level step has a set of guidelines. Designers
are often left free to follow the guidelines
closely or rely more upon their experience. Novice
would tend to follow guidelines while skilled designers
would rely more on their experience with
some support from the guidelines. With our ap-
proach, we provide both supports to novice and
skilled designers. Novices can use the detailed
process support to guide their design activities,
while more skilled designers use only high-level
process support.
3. Control condition selection: An SDM usually
does not specify strictly how design changes
should be managed. It usually does not specify
precisely the conditions under which a step can
be considered to be finished. With our approach
of tailoring SDMs for specific projects, we can define
the conditions quite precisely. For example,
for a medical system which is often safety-critical
and regulated by FDA, we decide to provide more
strict control (see Fig. 2) to ensure system consistency
and reliability. However, our experience in
using Debus-Booch shows that such control mechanism
should not be enabled until the specifications
(e.g., class diagrams) are stable and have
been used by other software components.
4. Control flow selection: An SDM usually does
not specify all the possible transitions between
steps, instead, it only specifies those that are
likely to be done most frequently. Transitions
that are the most crucial ones may also be the
most difficult to explain, and thus not specified
sufficiently precisely. Our approach makes it far
easier to add precision to the specification of tran-
sitions. For example, Fig. 8 shows the various
transitions needed for modifying classes.
5. Concurrency specification: As noted earlier,
most SDM's are intended only to specify how to
support the efforts of a single designer working
on one project at a time. It is clearly unrealistic
to assume that this is the mode in which most
designers work, and that, therefore, support for
this mode of work is sufficient. In our work we
adapted an architecture [SHDH + 91] that is capable
of supporting group development. The activities
which can be performed at each step allow
individual designers to work on the same design
in parallel.
5.2 Related Work
We have not seen any work that is similar to our approach
of developing design processes as software, then
analyzing and contrasting the elaborated processes,
and illustrating explicitly why currently existing SDM
descriptions cannot be taken directly as a completely
systematic process for specific projects. Our work is
unique in that it indicates how one might use the process
programming approach to modeling and coding
an SDM into a family of more systematic processes
used for a corresponding family of projects.
It demonstrates how SDM processes can be defined
more precisely. A more precisely defined SDM process
is more likely to be effectively supported and
thus provides more effective guidance. This experiment
encourages us to be more confident in using
the project-domain-specific process programming
approach to solving many problems in sharpening
and supporting software processes. Some work (e.g.,
studied mechanisms for supporting generic
software processes. However, without studying specific
generic and instantiated processes as we did in
this work, the value of these mechanisms is hard to
evaluate.
This work is related to other projects aimed at
developing a process-centered software environment,
like those reported in [MS92, KF87, MR88, Phi89,
ACM90, FO91, MGDS90, DG90]. The most significant
difference between these efforts and our work is
that our work, targeted at specific process require-
ments, provides very specific strategies for supporting
specific processes that emerge from the work of
other acknowledged experts (in this case, these experts
are in the domain of software design). For ex-
ample, we provide very specific interface architecture
and tool access methods for supporting SDMs and
their various users. In contrast, most work in developing
process-centered environments is aimed at developing
general-purpose software development envi-
ronments. For instance, [MR88] supports specifying
any software development rules. Marvel [KF87] is a
general purpose programming environment. It does
not describe specifically how to provide effective guidance
for using specific development method on specific
kinds of projects. Another difference is that our
work focuses on evaluating varied external behaviors
of the system while other work focuses on the study
of implementation mechanisms and process representation
formalisms (e.g., [FO91]). The study of these
mechanisms and formalisms is not the focus of our pa-
per. Comparisons of our formalisms (e.g., APPL/A)
to others can be found in [SHDH
6 Status and Future Work
The current prototype version of Debus-Booch
is implemented using C++, Guide (a user interface
development tool), and APPL/A. It incorporates
StP [AWM89] and Arcadia prototypes. The whole
prototype consists of about 34 UNIX processes. Each
of them supports a console, driver, panel, and other
tools. It was also demonstrated at the tools fair of the
Fifth International Conference on Software Development
Environments 1 . At present, this prototype is
being enhanced by the conversion of more of its code
to APPL/A and by the incorporation of new features,
new design process steps, and new design processes.
We plan to carry out the following future work:
1. Focusing on more specific project domains, to
elaborate still more specific process models and
support environments. This should help deepen
our understanding of the project domain's influences
on process requirements and SDM elaborations

2. Collecting data about how these elaborated processes
are used. Based on the analysis of these
data, we would be able to adjust the processes
more scientifically.
3. Developing a project-domain-specific process gen-
erator. With the specification of project proper-
ties, the corresponding process definitions and its
support environment might eventually be automatically
generated, at least in part.

Acknowledgments

We thank the members of the Arcadia software environment
research consortium for their comments,
particularly Stanley M. Sutton and Mark Maybee for
their useful comments on the APPL/A code.
We also thank those SCR researchers, particularly
Wenpao Liao, who experimented with and evaluated
our prototype. We are also very grateful to Tom Murphy
and Dan Paulish for supporting us to continue
this work at SCR. We thank Bill Sherman and Wen-
pao Liao for reviewing the final version of this paper.



--R

Software process enactment in Oikos.
Wasserman and R.
Mechanisms for generic process support.

The booch method: Process and pragmatics.
Process modeling.
An introduction and sur- vey
Managing software processes in the environment melmac.
Preproduction quality assurance planning: Recommendations for medical device manufacturers.
Integration needs in process enacted environments.
Formalizing specification modeling in ooa.
Statemate: a working environment for the development of complex reactive sys- tems
Using the personal software pro- cess

A formalization of a design process.
An architecture for intelligent assistence in software development.
Software process modeling.

Software development environment for law-governed systems
Process integration in CASE environments.
Software processes are software too.
State change architecture: A prototype for executable process models.
Object Oriented Modeling and Design.
Rebus requirements on elevator control system.
Object behavior analysis.



Real time recursive design.

Debus: a software design process program.
Towards objective
Challenges in executing design process.
--TR

--CTR
Stanley Y. P. Chien, An object pattern for computer user interface systems, Information processing and technology, Nova Science Publishers, Inc., Commack, NY, 2001
software design process;design methodology;design methods