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.
See the notes
here.
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)
