One of the issues with object orientation is the very fact that
it is relatively new to us. Because of its newness we are almost constantly encountering
problems that require a good deal of thought to surmount. This paper is designed to expose
one of the many aspects of object-oriented development, analysis and design, and to help
us to find a path through that jungle.
The method of analysis and design that we will examine is called
the Iterative Approach. It gets this name because the entire development process is
accomplished through a series of iterations each encompassing the entire process from
analysis through testing. During each of these iterations we are able to feed back
information to the earlier phases of the project.
When to use an iterative approach
Martin Fowler, in his book "UML Distilled" (available
at www.amazon.com), says "You should use
iterative development only on those projects that you want to succeed." He is not
exaggerating. There is no one who can assuredly complete any phase of the development
cycle in a single pass. There are simply too many details to address at each stage of
development. A methodology must be used that not only allows revisiting earlier
stages, but that encourages it.
The iterative methodology does just this. It requires that large
projects be broken up into smaller pieces and that each piece be developed through an
iterative process of analysis, design, implementation, and testing.
Why do iterations?
Iterations allow us to focus on a subset of the complete project
as we work out the details. We will often discover new problems and requirements during
the process of building one of the subsystems. These new discoveries can be easily
incorporated into a later iteration without requiring that the current work be discarded.
This process allows us to test each subsystem independently and
assure its proper functionality. This means that when we reach the final stages of
development, integration of the subsystems into a whole, we can focus the testing on the
integration knowing that each subsystem has been fully tested already.
By working on the high-risk aspects of the project earlier we are
able to reduce the influence of those risks on the overall project timetable.
During the implementation of the subsystems new use cases may be
discovered. These new situations can easily be scheduled into a later iteration.
What is the Iterative Approach
The iterative approach is not something new and revolutionary.
Many of us have been building systems this way for a long time. Martin Fowler classifies
the phases of an iterative project as Inception, Elaboration, Construction, and
Transition. Each of these phases constitutes a different point on the continuum to
The project begins in the Inception phase. During this phase,
which we will discuss in more detail later, we spend some time figuring out what the
project is and whether doing it is a good idea at all. At the end of the inception phase
we should have a fairly good idea of the scope of the project. The details have not yet
been elicited, but the general vision of the system is there.
At this point we can make our first break up of the project into
pieces. These pieces should be encapsulated enough to allow them to be built
independently. Each of these pieces satisfies a subset of the complete system
A major advantage to this approach is that we can identify the
risk involved with the project and apportion those risks in a managed fashion. This helps
us to avoid, that so well known situation, having all of the things that could go wrong
wait until the eleventh hour to begin failing. These risks can be spread across the
project and dealt with independently.
The risks that we face on a development project can be divided
into four categories. Those categories are requirement risks, technological risks, skill
risks, and political risks. Any project of a reasonable scope will have some risks
associated with each of these categories. Ignoring or denying the presence of these risks
is project suicide. These risks can only overcome the project if they are not managed.
Managing risk requires knowing what the risk is and having a plan for dealing with it.
Lets look at the risk categories.
The requirement category of risks includes those things that can
jeopardize the early process of discovering the system requirements. We may build the best
software system that anyone has ever seen for handling the logistics of toilet tissue for
the armed forces of the USA, but if the need was for managing the membership of the local
officers club our project would be a dismal failure.
Make sure we are building the right project, that is the main
goal of managing the requirement risks. While this set of risks appears early in the
process, it has the potential of eliciting the highest cost. Just imagine the amount of
work (and cost) if we find out about the officers club on the day we were going to
install the logistics application.
Use cases are invaluable in managing the requirement risks. Use
cases will tell you the behaviors that system must accomplish. They will give a clear
vision of how the system and the users will interact.
Develop a conceptual domain model of the business. The domain
model should give you a clear understanding of what things with which the business
interacts. A general concept of how the business works.
Then you can combine the use cases with the domain model to
produce a design model.
By taking the time to identify the information needed to produce
these models you will elicit detailed information from the users and business experts
about the project. You will, thereby, reduce the requirement risks considerably.
The first technological risk that comes to mind is related to
object orientation. Is OO a new paradigm for you or your staff? If it is then there is a
fairly large technological risk here. How will you deal with that risk? Will you budget
for training for yourself and your staff? Will you allow for the retention of a mentor or
consultant to be available for questions, meetings, and periodic system reviews?
What about the problem of new technologies? This new project
requires that the reports all be published on a web site. That web site must allow for
dynamic criteria for the reports. Hey, this web stuff will be fun, huh?
Yeah, lots of fun until you start trying to select the software
and hardware you will use to meet the requirements. As you assess the quality of the
various technologies you will need to incorporate into the project you will rapidly find
that this is the next major risk.
What happens if you select the best web server software and the
best remote database management software only to find out that they dont work well
together. You can be assured that any new technology you will use will cause you problems.
Those problems will eat time on the project.
The solutions for these technical risks are similar to the
requirement risks, training, mentoring, consultants with specific skills in those
Another method for minimizing the technological risks on the
project is to build prototypes. Build many prototypes, especially for those aspects of the
system that are using the most advanced and least understood technologies.
Does your staff have the skills to accomplish this project? What
will you do if the only person you have for the web stuff gets offered a job at ten times
the salary you are paying him two weeks before the web part of the project begins?
What resources exist in the immediate area for outside help? You
may need it at different points in the development.
Using a mentor can impact on these skill problems. Training is
another item to consider. Again, periodic system reviews done by a recognized expert can
be invaluable. Finally read as much as you can about the new technologies and provide an
abundance of reading material to your staff in those areas as well.
Whether you want to believe it or not, every project is fraught
with political risks. If you have no experience in dealing with these types of problems
then get someone that does on board fast.
Political risks have the potential of completely destroying a
project. Any company is full of people who have their own agendas and work very hard to
realize them. Political risks can show up in any form from simple battles over the budget
to downright sabotage.
You should be aware of the political environment in which the
project will be carried out. Know your friends and enemies. Be aware of those folks who
you can depend on to champion the project and those people who will, for whatever reasons,
likely work against your efforts.
A very good book for learning a lot more about managing political
risks is "Death March" by Edward Yourdan. The book is published by Prentice-Hall
and has an ISBN number of 0-13-748310-4 (available at www.amazon.com).
Lets now work through the phases of an iterative project
development cycle. You will recall that these phases are inception, elaboration,
construction, and transition. We will discuss each of these in some detail. Keep in mind
through the discussion that any one of these phases can be revisited at any point during
the projects development.
The first phase of inception will identify a set of subprojects
to be built. Each of these subprojects will proceed through its own elaboration and
construction phases. Finally the transition phase is where all of the subprojects are
Inception is the beginning of the project. This phase can take on
any of a number of different forms. It can be comprised of anything from an informal
conversation over coffee to a series of well-structured meetings with a large number of
The purpose of this phase is to work out the rough overview of
the project. Martin Fowler says, "Inception should be a few days work to
consider if it is worth doing a few months work of deeper investigation during
The goals of inception should be to get a good idea of the
business case for the project. How much will this project improve the bottom line? Another
goal is to get a feel for the scope of the project. How much will this project cost?
At the end of the inception phase the projects sponsor has
committed to no more than taking a serious look at the project.
Depending on the size of the project you may find yourself doing
some degree of analysis in an effort to get a sense of the scope of the project during
this phase. Inception can be anything from a brief conversation to a full-fledged
feasibility analysis taking many months of work.
Once you have to go ahead to start the project you enter the
elaboration phase. At this point you only have a very general idea of what the project is
to be. Perhaps you can say;
"We will build a software application that will manage the
activities of a bowling alley including the scheduling of lanes and leagues, the printing
of league schedules, the scheduling of employees, the record keeping of cash collections,
and the management of equipment maintenance."
Your requirements documentation may have a lot more text in it
but it does not likely say very much more at this point.
The questions to be answered in this phase are, What are you
actually going to build?, How are you going to build it?, and What technologies will you
be using to build this?
The major focus during this phase should be on the risks that you
will face. What are the things that could derail your project and how are you going to
handle those? You should be identifying these risks according to how much of a potential
problem they are. The bigger the risk the more attention you should pay to it.
These risks can be categorized into the groups described in the
previous section. In order to find the risks you need to begin to do a detailed analysis
and design of the complete system. The first place to start is with the domain model for
the system. Once you have the domain model in place, then move onto to the use cases for
the system, and finally combine the domain model and the use cases into a design model.
The Domain Model
The domain model is a very general picture of how the business
operates. This model describes the world in which the system will exist. We need a
conceptual image of the overall business, what it deals with, what things it does, how it
does these things, and how all of this fits together. The domain model will show us this.
The domain model contains a minimal amount of detail. There may
be many unconnected diagrams and these diagrams may be combined with freeform notes and
comments. The domain model will lay the foundation for the more detailed models that
follow. Figure 1 is an example of a domain model for a fictitious system.
Figure 1 The domain model for a bowling alley management
Notice, in figure 1, that there is no detail inside of the
identified objects. These objects are simply named and parts of their relationships are
described. This model shows us a very general overview of the business and how it works.
The goal of taking this approach to development is that we will
get a "big picture" of the system up front. By having this concept of the total
package right from the start we can plan for the impact of each piece of the system on the
When the domain model is in place we can proceed to identifying
the use cases.
Martin Fowler describes use cases as "A typical interaction
that a user has with the system in order to achieve some goal". Use cases provide a
number of benefits to the developer. Use cases are stated as interactions that a typical
user will have with the system, as such they are easily understood by the users and
therefore provide for effective feed back from that group.
Use cases are the foundation for a functional specification, as
they describe the things the system has to do from the perspective of the users. A use
case may be a paragraph or two describing a specific activity the user will engage in with
the system. Examples of use cases for a word processor might be, "make text
bold", "italicize text", "copy text frorm one place to another",
or "create an index to a document". These examples show that a use case can be a
very small action or it can encompass a quite large and complex process.
Example of use cases for our bowling alley system might be,
"The user needs to be able to schedule alleys for the leagues. There can be only one
league for an alley at a given time. The time slot of a league game is 2 hours. Each
league will have a number of alleys that it requires for one set of league
games", and "The user needs to print the schedules for each league". Again
you can see that the range of complexity for these use cases varies greatly.
The text for a use case should be specific enough for the users
to understand the idea of the case and for the developers to have an idea of what is
involved in implementing the functionality.
Use cases are also diagrammed as can be seen in figure 2.
Figure 2 A use case diagram.
In figure 2 you can see that the use case is represented by an
oval with the name of the use case inside. The stick figure is called an actor and it
represents the person or thing the uses the functionality. The actor may be a user or it
may be another computer system or even a machine in a factory.
The use case diagram lets us see the overall picture of the use
cases and how they fit together. Once we have the domain model in place and we have
identified the use cases we can proceed to the design model.
The Design Model
The domain model identifies the objects that the system will
encompass and the use cases are the activities the system will automate. The design model
is the combination of these other two. This design model is also an abstract model in that
it does not involve a high level of detail. The detailed diagrams will be produced later
in the development cycle.
The purpose of this design model is to describe the combination
of the information in the domain model and the behaviors of the use cases in a fashion
that shows us how these things fit together. The design model also provides a reusable
architecture that allows for future extensions of the system.
Figure 3 is an example of a design model for our bowling alley
system. The model in figure 3 is far from complete; it is only intended to demonstrate the
idea of combining the domain model with the use cases.
Figure 3 A design model.
Notice that figure 3 has added the behaviors of the use cases to
the objects of the domain model. This diagram will be expanded into actual class diagrams
at a later time. Here we are trying to get a more complete overview of the entire system.
How far to go with diagrams?
When we read about system analysis and design we are constantly
seeing different diagrams. There are diagrams for this and diagrams for that and what not.
How many diagrams are enough and how many are too much? What else should we use besides
these diagrams for communication?
Diagrams should be used when they add to the understanding of the
system and they should be avoided when they cause confusion. Ward Cunningham said,
"Carefully selected and well-written memos can easily substitute for traditional
comprehensive design documentation. The latter rarely shines except in isolated spots.
Elevate those spots
and forget about the rest".
What does this quote mean? Does it mean we should not draw
diagrams? No, it means that the diagrams we do use should enhance our understanding of the
system. If there is a diagram that does not enhance our understanding then we should do
away with it. Most of the time a well-written memo can better and more clearly describe
our point than a confusingly complex diagram. In those situations get rid of the diagram
and write the memo.
When is the elaboration phase complete?
The elaboration phase of the project is finished when all of the
risks associated with the project have been identified and plans for handling them exist.
Along with all of the technologies having been identified and the models exist for domain,
use case, and design. Also, the developers are comfortable in providing estimates for
building each use case.
Each of the use cases will become one of the subprojects in the
construction phase. This is where the iterations come into play. During construction we
will build each use case separately and allow the experience of building each one
influence the design of the others.
Once elaboration is complete we enter the phase of construction.
In construction each use case will be handled as a project in itself being built through
an analysis, design, coding, testing, and integration process. An iteration ends with a
demo to the users of the completed subsystem.
During the construction of a use case we often will discover
changes that are required to our preliminary design of other use cases. These discoveries
are fed back into the respective use case designs. We may also discover new use cases that
were never realized during the elaboration phase. These can be added to the project and
scheduled for later construction.
As we complete the construction of each use case we will
integrate it with the previously built use cases to work towards the fully integrated
system. We may reenter the construction of previously completed use cases as the need
arises. It is this process that gives this approach the name iterative development, as the
complete system is built through a series of iterations on each subsystem.
Transition is the final phase of the iterative development
approach. Transition handles those issues that were not addressed during construction.
Perhaps there is some final integration to be done after all subsystems are built. A good
example of a problem that would be addressed during transition is optimization for
Optimization usually sacrifices clarity and ease of integration
infavor of increased performance. This is not something that we want to do early in a
projects development as it will increase the difficulty in building the project.
Instead we would leave optimization to the transition phase when all of the subsystems
have been built and tested.
Optimization is also an elusive goal. Often we, as developers,
perceive a performance problem where users will never notice it. We will also overlook a
problem in performance that users will readily recognize. If we start optimizing a system
before the users can tell us where it's slow we will be spending time and effort in the
Transition can be thought of as that period of time between the
release of the beta version and the final version of a project. There will likely be
"bug fixes", functional enhancements, performance optimization, and other things
done during this phase. Sometimes we may discover an entirely new use case that needs to
be built. The iterative development approach allows us to easily process this new use case
and then reenter the transition phase.
Object oriented analysis and design is often seen a huge package
of complex diagrams that mean little or nothing to the users of a system. It is sometimes
seen as a process that involves a large amount of theory and abstract conceptual models
that really add very little to a project.
It does not have to be this way. Object oriented analysis and
design can be a very pragmatic approach to system development. It does not have to be
discrete phases that are never revisited. Using the iterative approach, this process can
be a living and breathing aspect of system development. It can enhance our ability to meet
the needs of the users and to control the risks associated with a project. When used
effectively, the iterative approach can actually reduce the time required for building a