 |
Flowcharts are a modeling technique
introduced in the 1940/50s and popularized for
structured development in the 1970s (Gane
and Sarson 1979) as well as business modeling.
Figure 1
depicts a flowchart for the
Enroll in University use case. There are
three basic symbols on this flowchart: Squares
which represent activities or tasks, diamonds which
represent decision points, and arrows which represent flow of
control. Flowcharts support other types of symbols,
such as off page connectors (for when your diagrams get
too big) and input/output symbols to represent printed
reports and data storage options. I typically don’t use
off page connectors as I prefer small flowcharts
although I will occasionally model reports (a four sided
shape with a curvy bottom edge) and databases (as a
cylinder). |
|
Figure 1. Enrolling in the
University.
Notice the differences between the
flowchart and the
data flow diagram (DFD) which also models this use
case. Unlike DFDs which are used to
describe data flow within a system, flow charts are
typically used to describe the detailed logic of a
business process or business rule. In the past it was
quite common to use flow charts to model the logic of
large software modules, such as a 30,000 line COBOL
program. However, because object methods are much
smaller (a 30 line method would be considered quite
large) flowcharts have dropped out of favor with
programmers in recent years. That’s okay, they’re still
useful for process modeling. It is important to note
that although the flowchart is much more detailed than
the DFD I could just as easily gone to the same level of
detail in both diagrams.
To create this diagram I simply
worked through the business logic a step at a time. I
started at the top left corner of the board, you can see
the arrow coming from nowhere into the side of the
Distribute Forms to Student step. It’s interesting
to note that the use case doesn’t specifically call this
out as the first step, but it does seem to be implied
and this step is required if the registrar determines
that the forms aren’t valid.
Each time a decision is made I
introduced diamond. In this example all the decision
points were yes/no questions but that doesn’t always
have to be the case. I could just as easily ask a
question such as “What is the day of the week?” and had
seven arrows leaving the diamond, one for each day.
Each arrowhead leaving a decision should be labeled with
the appropriate condition but as you can see I forgot to
label the yes arrow coming out of the Valid
diamond – remember, agile models just need to be
just barely good enough.
It’s interesting that by drawing
this flow chart I seem to have picked up some logic
errors in my use case. First, the box with a question
mark in it indicates that I still need to think through
an alternate course in the use case, no big deal. The
real logic problem is that I check to see whether the
person exists in the database before I check to see if
they’re on the list of expected applicants. This
doesn’t feel right to me so this is something I should
discuss with my stakeholders, pointing out the value of
AM’s
Active Stakeholder Participation practice – if
the stakeholder is working with me on this model we can
resolve this issue right away, if not then I have to
either wait for them to be available to discuss the
issue or simply make something up on the spot and risk
having to fix it later on.
The best way to stay agile when
working with flow charts is to keep things simple.
Sketch them on whiteboards with your stakeholders to
discuss important business logic, take a digital photo
if you want to save it, or simply erase it once you’re
through. The value often isn’t in the models that you
create but instead it is in the act of modeling because
it helps you to think things through. For example, the
flow chart of Figure 1 has helped
my team to identify a potential problem with our use
case, but once we’ve fixed that problem the flowchart
isn’t going to be of much value any more.
I don’t use flowcharts much any
more because I prefer to use
UML activity diagrams instead, and in fact activity
diagrams are arguably sophisticated flow charts (there’s
more to them than this though). Regardless, I it’s
important to be aware of flow charts because you will
still see them used by experienced IT professionals from
time to time.
This artifact description is excerpted from Chapter 9 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
 |
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.
 
|
