Brief notes: Activity diagrams exercise class

I discussed the latter two multiple choice questions on the videos page, which were both about 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: two students had sent email about this and this was good judgement on their part, because it is confused!

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.

Example

Then students worked on drawing an activity diagram for the following situation:

A course proposal has to be written, reviewed, and then either accepted and published, or rejected and the notice of rejection distributed.

Now suppose there's an option to decide to modify it instead of straight accepting/rejecting. (We change ``write proposal'' to ``modify proposal'' at this point.)

Now suppose we have to announce it when modifications are going to be made. (We discussed that the stop marker kills the whole activity, not just that flow. We could leave the activity with no successor, or we could use a flow final marker - the latter, however, are not examinable.)

Now suppose we want to show that one person does the writing/modifying, someone else the reviewing, yet someone else the publication. (Swimlanes.)

Finally we discussed reentrance: what happens if a transition goes into an activity that is already going on? (NB can't be because it previously finished! Can happen, for example, if two things that happen in parallel cause the same activity...) Reentrance defaults to false, in which case the token would be ``queued''.

Take home message: LOOPS ARE QUITE TRICKY. Probably avoid when you write diagrams! Often it's possible to choose what exactly you're diagramming so that loops are unnecessary, e.g., show how to process one customer, not all customers.

Examples from the standard

From the UML2.4.1 Superstructure document we looked at a few examples.

p338 of the spec for simple activity language: you can show details of what an activity is inside the box, if you choose.

p346 for use of decisions and merges

similarly, p349

Reminder: UML contains a lot of stuff we're not talking about.

This page is maintained by Perdita Stevens (perdita@inf.ed.ac.uk)

Home : Teaching : Courses : Seoc : 2012_2013 : Schedule