- Project tools
- Nightly builds of docs
- The ArgoUML Project
- Using ArgoUML
- How do I...
|Over 500 more tools...
3.2. UML Based Processes for OOA&D
It is important to understand that UML is a notation for OOA&D.
It does not prescribe any particular process.
Whatever process is adopted, it must take the system
being constructed through a number of phases.
Requirements Capture. This is where we identify the
requirements for the system, using the language of the
problem domain. In other words we
describe the problem in the “customer's”
Analysis. We take the requirements and start to
recast them in the language of a putative solution—the
solution domain. At this stage,
although thinking in terms of a solution, we ensure we keep
things at a high level, away from concrete details of a
specific solution—what is known as
Design. We take the specification from the Analysis
phase and construct the solution in full detail. We are
moving from abstraction of the problem
to its realization in concrete
Build Phase. We take the actual design and write it
in a real programming language. This includes not just the
programming, but the testing that the program meets the
requirements (verification), testing
that the program actually solves the customer's
problem (validation) and writing all
In this section we look at the two main types of
process in use for software engineering. There are others,
but they are less widely used.
In recent years there has also been a move to reduce
the effort required in developing software. This has led to
the development of a number of lightweight variants of
processes (often known as agile
computing or extreme
programming) that are suited to small teams
22.214.171.124. The Waterfall Process
In this process, each stage of the
process—requirements, analysis, design and build (code and
test) is completed before the next one starts. This is
illustrated in Figure 3.1, “The Waterfall Process”.
Figure 3.1. The Waterfall Process
This is a very satisfactory process where
requirements are well designed and not expected to change,
for example automating a well proven manual system.
The weaknesses of this approach show with less well
defined problems. Invariably some of the uncertainties in
the requirements will not be clarified until well into the
analysis and design, or even code phases, requiring
backtracking to redo work.
The worst aspect of this, is that working code does
not become available until near the end of the project, and
very often it is only at this stage that problems with the
original requirements (for example with the user interface)
This is exacerbated, by each successive stage
requiring more effort, than the previous, so that the costs
of late problem discovery are hugely expensive. This is
illustrated by the pyramid in
Figure 3.2, “Effort Involved in the Steps of the Waterfall
Figure 3.2. Effort Involved in the Steps of the Waterfall
The waterfall process is still probably the dominant
design process. However because of its limitations it is
increasingly replaced by iterative
processes, particularly for projects where the requirements
are not well defined.
126.96.36.199. Iterative Development Processes
In recent years a new approach has been used, which
aims to get at least part of the code up and running as
quickly as possible, to bring discovery of problems forward
in the development cycle.
These processes use a series of
“mini-waterfalls”, defining a few requirements
(the most important) first, taking them through analysis,
design and build to get an early version of the product,
with limited functionality, related to the most important
requirements. Feedback from this can then be used to refine
the requirements, spot problems etc before more work is
The process is then repeated for further requirements
to construct a product with a step up in functionality.
Again further feedback can be applied to the
The process is repeated, until eventually all
requirements have been implemented and the product is
It is this iteration that
gives these processes their name.
Figure 3.3, “Effort Involved in the Steps of an Iterative
Process” shows how this process
compares to the pyramid structure of the Waterfall
Figure 3.3. Effort Involved in the Steps of an Iterative
The growth in popularity of iterative processes is
closely tied to the growth of OOA&D. It is the clean
encapsulation of objects that allows a part of a system to
be built with stubs for the remaining code clearly
188.8.131.52.1. The Rational Unified Process
Perhaps the best known Iterative Process is the
Rational Unified Process (RUP) from Rational Software (
This process recognizes that our pyramid view of
even slices of the waterfall is not realistic. In
practice the early iterations tend to be heavy on the
requirements end of things (you need to define a
reasonable amount even to get started), while the later
iterations have more of their effort in the design and
RUP recognizes that iterations can be grouped into
a number of phases according to
their stage in the overall project. Each phase may have
one or more iterations.
In the inception phase
iterations tend to be heavy on the
requirements/analysis end, while any build activity
may be limited to emulation of the design within a
In the elaboration phase
iterations tend to be completing the specification of
the requirements, and starting to focus on the
analysis and design, and possibly the first real
In the construction phase
iterations the requirements and analysis are more or
less completed, and the effort is mostly in design
Finally, in the deployment
phase iterations are largely about build
activity, and in particular the testing of the
It should be clear that testing is an integral
part of all phases. Even in the early phases the
requirements and design should be tested, and this is
facilitated by a good CASE tool.
We shall use an iterative process in this manual,
that is loosely based on the RUP.
184.108.40.206.2. Iteration Size
A good rule of thumb is that an iteration should take
between six and ten weeks for typical commercial projects.
Any longer and you have probably bitten off too many
requirements to do in one go. You also lose focus on
getting the next working iteration completed.
Any shorter and you probably haven't got enough
requirements to make a significant advance.
In this case the additional overhead associated with an
interation will become a problem.
The total number of iterations depends on the size of project.
Take the estimated time (working out/guessing that is a
whole subject on its own), and divide it into 8 week chunks.
Experience seems to suggest that the iterations will
divide in the ratio of around 1:2:3:3 into RUP style
inception, elaboration, construction and deployment
phases. A project that has great vagueness in its
specification (some advanced research projects for
example) will tend to be heavier on the early
When building a product to contract for a customer
the end point is well defined. However when developing a
new product for the market place, a strategy that can be
used is to decide the product launch date, and hence the
end date for completion of engineering (some time
before). The time is then divided into iterations, and as
much of the product as can be built in that time
developed. The iterative process is very effective where
time to market is more important than the exact
220.127.116.11. Recursive Development Processes
Very few software systems are conceived as monolithic
artifacts. They are broken down into subsystems, modules
Software processes are the same, with early parts of
the process defining a top level structure, and the process
reapplying to parts of the structure in turn to define ever
For example the initial design of a telephone system
might identify objects to i) handle the phone lines, ii)
process the calls, iii) manage the system and iv) bill the
customer. The software process can then be reapplied to
each of these four components to identify their
OOA&D with its clean boundaries to objects,
naturally supports this approach. Such OOA&D with
recursive development is sometimes abbreviated as
Recursive development can be applied equally well to
waterfall or iterative processes. It is not an alternative
3.2.2. A Development Process for This Tutorial
For the purpose of this tutorial we will use a stripped
down iterative process with recursive development, loosely
akin to RUP. The case study will take us through the first
iteration, although at the end of the tutorial section of the
manual we will look at how the project will develop to
Within that first iteration, we will tackle each of the
requirements capture, analysis, design and build activities
in turn. Not all parts of the process are based on UML or
ArgoUML. We will look at what other material is needed
Within this process we will have an opportunity to see
the various UML diagrams in use. The full range of UML
diagrams and how they are supported is described in the
reference manual (see Section 16.8, “Diagram”
18.104.22.168. Requirements Capture
Our requirements capture will use the UML concept of
Use Cases. Starting with a
Vision Document we will see how Use
Cases can be developed to describe all aspects of the
system's behavior in the problem domain.
During the analysis stage, we will introduce the UML
concept of classes to allow us to
build a top level view of the objects that will make up the
solution—sometimes known as a concept
We will introduce the UML sequence
diagram and statechart
diagram to capture requirements for the overall
behavior of the system.
Finally we will take the Use Cases from the
requirements capture stage, and recast them in the language
of the solution domain. This will illustrate the UML ideas
of stereotyping and
We use the UML package diagram
to organize the components of the project. We then revisit
the class diagram, sequence diagram and statechart diagram,
to show how they can be used recursively to design the
During this part of the process, we need to develop
our system architecture, to define how all the components
will fit together and operate.
Although not strictly part of our process, we'll
look at how the UML collaboration
diagram can be used as an alternative to, or to
complement the sequence diagram.
Similarly we will look at the UML activity
diagram as an alternative or complement to the
Finally we shall use the UML deployment
diagram to specify how the system will actually
UML is not really concerned with code writing.
However at this stage we will show how ArgoUML can be used
for code generation.
We will also look at how the UML Use Case Diagram and
Use Case Specification are invaluable tools for a test