The basic idea of activity diagrams is to show what activities happen and
in what order, where choices are made, and when things happen in parallel.
They're most often used for modelling high-level processes, e.g. how the
overall flow of a use case works, but can be used e.g. to show how an
object reacts to a message if that's ever useful.
Key thing to check: that you're clear about the meaning of fork and join
bars, and of decision and merge diamonds, and are not confusing the two.
I discussed briefly in a lecture the question of whether it was OK for two
arrows to come into or go out of the same activity in an activity diagram,
and if so, what it meant. Brief advice: don't do that!
Why? Because, although it's technically allowed by UML specification,
the spec is somewhat ambiguous about what it means. (When two arrows come
out of an activity, with no conditions on them, are both arrows followed,
or only one?) If you are tempted to have:
- Two arrows coming into an activity and you mean both arrows should be
followed, before the activity can start: use a join bar instead.
- Two arrows coming into an activity and you mean either one can cause the
activity can start: use a merge diamond instead.
- Two arrows going out of an activity and you mean both arrows should be
followed: use a fork bar instead.
- Two arrows going out of an activity and you mean one or the other will
be followed: use a decision diamond instead.
Q1)
There are actually lots of correct answers for this one. You
should have activities called things like select items and calculate price,
etc. One point of interest: should you have one activity called pay, or two
for the two methods of paying? It's really up to you. Check that you can
use a decision diamond with conditions such as [customer chooses Paypal] on
the arrows to use two. If you have two activities, use a merge diamond to
bring the flows back together afterwards, like this:
Q2)
Assemble order and check payment can probably go in parallel, at
least. What about update stock control system?
Q3)
Use a dotted line to separate what the customer does from what
the staff do, and label the regions appropriately. They don't have to be
columns strictly: anything clear will do.
Q4)
straightforward, but with lots of scope for making different
choices and being more or less ambitious about what to show. The main
source text is that in the Week 4 tutorial sheet, of course. Points I would
expect might come up:
- how do we show an activity that represents cooperation between two things
that have their own swimlane, e.g. discussion between an employee of the
company and the customer? UML doesn't have a really good answer to this.
Swimlanes can (in UML2) be hierarchical (e.g., you can have a swimlane for
the computer system which is split into two subswimlanes for different
subsystems) and/or multidimensional, but neither of these mechanisms helps
much. See e.g. p368 of the UML pdf. In practice, people using UML will
often do the obvious thing and put an activity straddling the line between
two swimlanes. This isn't strictly legal, but it's one of those things
that's so useful that I wouldn't suggest they avoid doing it, and wouldn't
mark them down for it in an exam. Strictly speaking, I think you have to
assign one swimlane overall responsibility for the activity and put it
there. (Or, of course, decide that in the circumstances swimlanes are not
very useful.)
- how do we show the quotes being revised? We could show the quotes
themselves as objects in the activity diagram, but objects in activity
diagrams are among the things I am leaving out in the SEOC treatment of
activity diagrams. (Look it up in the spec if you really want to
know (and then you'll see why I'm leaving it out!).) You could just do a
loop in the diagram, making appropriate use of decision diamonds
(conditions like [quote satisfactory]) and merge diamonds.
This page is maintained by
Perdita Stevens (
perdita@inf.ed.ac.uk)
