Note: the following is adapted from notes I sent the tutors. If, after the
tutorial and reading this, you are in doubt about something, one thing you
could do would be to ask about it on the
Forum, where
hopefully another student can help, or if not, I'll follow up myself.
There's actually not a lot I can say about either of these, but here are a
few notes. As always, let me know if anything's unclear or if any problems
arise.
Please make sure they [students!] are clear about the meaning of fork and join bars,
and of decision and merge diamonds, and are not confusing the two. Please
reinforce the notes given here (and linked from the schedule):
http://www.inf.ed.ac.uk/teaching/courses/seoc/2012_2013/schedule/activity.html
Q1)
- answers are on the web page, in effect.
Q2)
straightforward, but with lots of scope for them 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. They can look it up in the spec if they really want to
know (and then they'll see why I'm leaving it out). They could just do a
loop in their diagram, making appropriate use of decision diamonds
(conditions like [quote satisfactory]) and merge diamonds.
The more challenging questions given opportunities for discussion; let me
know if anything problematic turns up.
This page is maintained by
Perdita Stevens (
perdita@inf.ed.ac.uk)
