May 93 - Solution-Based Modeling: A Methodology for the Rest of Us
Solution-Based Modeling: A Methodology for the Rest of Us
Jeff Alger and Neal Goldstein
This article is the second of two parts, much of which is excerpted from a forthcoming
book by Jeff Alger and Neal Goldstein. Copyright © 1993 by Jeff Alger and Neal
Goldstein. All rights reserved. The first part appeared in the March issue of
Frameworks.
Review From Part I
Solution-Based Modeling and its companion notational system, the Visual Design
Language, were developed to map well to the way creative people work best while still
allowing management to estimate, schedule and maintain control. The objectives are to
improve communications, decision-making and, as a consequence, the success rate of
projects, chiefly through improving communications and decision-making.
There are three basic components of SBM.
• An architecture that structures analysis, design and programming
information into a series of well-defined models.
• A notation, VDL, that can be used to define and express the models with
minimal loss and distortion of information.
• A process for overall development that pays attention to the needs of all
parties to the project, from end users to management to engineering to quality
assurance and documentation. This includes modeling technology that helps
teach people how to build robust, complete models, alone or in work groups,
and continuous quality assurance structures: algorithms and metrics that
make quality software a consequence of the overall process, rather than the
result of a separate step.
The architecture and notation were discussed in the first part of this article in the
March issue of Frameworks. This part focuses on the process and briefly discusses a
fourth component, tools, currently under development by SBM International and
others. Extensions to the method are also discussed. Before proceeding, let us review
briefly the overall architecture and notation discussed in the first part.
Architecture
There is growing acceptance in the software engineering community today of the
so-called "multiple models" approach: dealing with a single subject by building many
overlapping models. In SBM, we create a series of models of the following kinds.
• Business models describe the business system that surrounds the
computer system or program.
• Conceptual models are idealized, or deliberately simplified, models of the
content and interface of the program.
• Run-time models describe the running program and ignore
implementation details about how the source code is structured.
• Implementation models collectively are the implementation, expressed as
a combination of source code and design diagrams.
We call these four kinds of models planes and name them the Business, Technology,
Execution and Implementation planes, respectively. Within each plane, we use the
term region to describe one model of that kind.
Notation
The Visual Design Language (VDL) was designed in conjunction with graphics design
experts and tested to enhance comprehension and retention of information in software
projects. VDL emphasizes the use of small, self-contained diagrams called scenarios.
An SBM project uses scenarios as the way to capture, communicate and validate
business, conceptual design, software architecture, and programming informations.
Scenarios typically overlap heavily in content and subject matter. Within any scenario
there are elements and relationships among those elements. Provision is made for both
static scenarios, in which time is not a factor, and dynamic scenarios that show a flow
of action of state over time.
There are four basic activities in a SBM project:
• Creating new scenarios,
• Validating scenarios,
• Programming, and
• Managing the project and library.
Creating New Scenarios
Participants in the team draft a series of simple scenarios, each of which concentrates
on a single topic. The overall "model" is, in a sense, simply the collection of valid
scenarios gathered during the project. SBM encourages and supports exploration of
problems at or near the basic level, rather than using a top-down approach. However,
to abandon top-down approaches without a substitute process in place would be foolish,
since one still needs defined starting points and controlled, incremental expansion. To
address this problem, SBM relies on centrality. Let's revisit the jigsaw puzzle
analogy. Once the border is in place, what do you do next? Most people would pick some
interesting topic, perhaps a building or a flower, and work on that pattern for awhile.
When work on that topic bogs down, one shifts to some other central topic. Eventually,
one works out toward the periphery perhaps connecting topics to each other or to the
border. Finally, when there is nothing left but blue sky, the final, hard work begins.
This so-called center-periphery strategy is precisely the exploratory process used in
SBM. It is such a natural process that it doesn't need to be formally taught; you already
use it every day. In fact, even when people are asked to work in other ways, such as
top-down, they end up using center-periphery strategies and make it look otherwise.
SBM merely provides an environment in which it is safe and politically acceptable to
run entire projects this way.
1. Start with a central topic.
2. Blanket that topic with small, overlapping scenarios in several regions of
the overall four-plane model.
3. When that bogs down, pick another central topic and iterate.
4. As the model fills out, spend more and more time on the periphery.
5. When the overall structure of the project is well-established, do the fine
detail work.
Notice that this not only does not require a top-down process, it also does not force a
linear approach. That is, one is free to shift focus from plane to plane and region to
region at any time, rather than having to finish one region before starting on the next.
This, too, is simply the way people work whether you want them to or not. In SBM, we
recognize that fact and design project management strategies around it. This is the
essence of the multiple models approach: rather than viewing a problem from one
direction only, we continually turn it around in our hand, considering it from multiple
perspectives in order to gain a more complete understanding.
VDL and the scenario paradigm are useful in many different contexts, from a software
engineer scribbling at a white board to interviews with people outside the central
project team to a focus group of typical end users being asked to provide critical
feedback to product marketing to briefings for management on the state and objectives
of the project. This is not random chance: VDL was specifically designed to appeal to a
broad cross-section of team participants and "level the playing field" of
communications.
Validating
The process described above releases the creative juices. People are free to follow
their creative flow in the most productive way, unencumbered by an artificial
process. However, eventually one must return to hard reality: the scenarios and
models must be formally validated. To that end, SBM uses a series of validation
strategies collectively called calibration.
• Synthesis is used to ensure that scenarios are mutually consistent.
• Correlation assures that multiple models are consistent with one another
and each is complete in terms of the other.
• Synchronization tests for completeness and consistency of the final
architecture within itself.
Synthesis is a term borrowed from data modeling. Gather a set of scenarios, then
compare them pairwise to remove any contradictions that may exist, such as synonyms
and homonyms. These and other synthesis problems are really just common sense and
most people have no problem recognizing them when two scenarios are laid
side-by-side. With a small batch, one can simply spread them on a table and compare
them pairwise visually. This quickly breaks down as the number of scenarios grows,
so larger sets require the use of a cross-reference index that quickly answers
requests such as "tell me all the scenarios in which object X occurs." The database
support for this sort of query is surprisingly simple; in our book we describe a
simple Hypercard-like database that has been used by a number of project teams to
good effect. However, there is no substitute for a good automated tool here and this is a
major focus of our own efforts today.
Correlation has already been described briefly: matching up one model with another
through the correlation relationships Implements, Replaces and Same As. All, or a
clearly defined subset (e.g., the program element of the Solution Model), of one model
must be completely accounted for in the other model; in turn, each element of the other
model must support some aspect of the original.
Synchronization is a series of five separate tests, all applied rigorously in the
Execution Plane to validate the completeness of the run-time model. The
synchronization tests are
• Creation, validating that objects and data structures are created before
use,
• Destruction, validating that objects and data have not been destroyed prior
to use,
• Object Knowledge, that is, demonstrating how an object obtains the
address of another prior to sending it a message,
• Connectedness, validating that each method is called in response to some
user or operating system event, and
• Protocol, making sure that the calling protocol for methods is consistent
throughout the model.
The first three of these are closely related and apply to all collaborations, both for the
objects at each end and the inputs and outputs that make up the calling protocol of the
method: For each, demonstrate that it was created in time, hasn't been destroyed, and
the originating object has the required object knowledge. These tests apply equally to
primitive data structures.
In a procedural program, where the branching logic is hierarchical, it is easy to tell
when a subroutine cannot possibly be reached. In an event-driven world of graphical
user interfaces, it is not quite so simple to tell what is and is not reachable. Enter the
connectedness test. A method is connected if it is called in response to some event.
Events can include user activities like mouse clicks, operating system events such as
timer interrupts, or higher-level events such as messages from collaborative
applications. The basic algorithm works as follows.
1. Enumerate all sources of events.
2. For each one, mark the method or methods called directly in response by
the operating system or class library.
3. For each marked method, mark its collaborators; that is, the other
methods it calls. Apply this step recursively until no more methods can be
marked.
4. Find all unmarked methods. These are unconnected.
Unconnected methods may indicate any of several underlying problems: synonyms,
vestigal code, missing collaborations, or methods put in place to support future
expansion.
The protocol test is also quite simple: is any given method always called with the same
formal argument types? This is commonly handled as part of synthesis; if not, it must
be a separate step as part of synchronization.
The combination of these five tests, applied to the Execution Plane, is designed to
uncover the problems that occur in the worst nightmares of project managers and
architects. It has been estimated that 50% of a C++ programmer's time is spent
tracking down memory leaks and dangling pointers, the subject of the first three of the
synchronization tests. Our own surveys show that these tests address problems
typically associated with 30%-40% of the programming phase of a project, and that
when they occur there seems to be an unwritten rule that they occur at the eleventh
hour and cause maximal damage to class hierarchies, QA test suites, and team morale.
What SBM does is take these out of the domain of programming and deal with them as
design issues.
We can now complete the center-periphery process described earlier by taking into
account the three forms of calibration. The result is that of Figure 4, with frequent
iterations at all steps.
A wealth of detail already attended to, programming in SBM projects is considerably
easier than in many other approaches. There are two aspects to programming:
designing class hierarchies and writing the code that implements methods. In SBM,
classes are designed to optimize the implementation; they are not required to have any
intrinsic "meaning." Hierarchies are designed to maximize reuse within the project
while also maximizing modularity and independence. The process is basically
bottom-up in designing interfaces and both bottom-up and top-down in designing
implementations of methods.
1. Group run-time objects of the Execution Plane into concrete types. All
members of a concrete type share identical attributes, methods, interfaces and
collaborators.
2. For each type, create a concrete class in the Implementation Plane.
3. Look for patterns of similarity among the concrete classes. Where such
patterns exist, abstract classes are often formed to maximize sharing of
properties across concrete classes.
4. As methods are implemented, differences in behavior, thought not
protocol, emerge that lead in the opposite direction: derivation of subclasses
that differ in method implementation but not interface.
In managing SBM projects, everyone on the team should understand at least the
following basic subjects:
• Goal-directed phases,
• Prototyping,
• Estimation and the SHP formula,
• Library management, and
• Team management.
Goal-Directed Phases
In classical software project management, a phase is considered complete when some
activity is complete. Thus, an analysis phase is complete when one is through doing
analysis activities. This is in direct opposition to one of the basic principles of SBM,
non-linear workflow. Fortunately, other fields have long used more sophisticated
strategies in which phases of project plans are orthogonal to the activities that take
place within those phases; we adapt those to the world of software development. For
example, when a construction firm builds a bridge, it may go through several phases:
site preparation, falsework (the temporary frame prior to pouring concrete), and so
on through final cleanup. In each phase, there may be planning, design, construction,