University Homepage School Homepage School Contacts School Search

Brief notes: Tuesday Week 4 exercise class

Introduction: UML as a whole

I started off by summarising the UML diagrams you've seen so far and what each is for. (Static/dynamic; within dynamic, inter-object, intra-object, process-oriented.) Really good exercise: check your understanding of this.

We discussed the fact that there's just one underlying model, of which all these diagrams are part, and the (related) fact that in the end there will be one software system, about which all these diagrams have to be telling true stories.

Students volunteered various different ways in which a set of diagrams could be individually correct, but not consistent as a collection, i.e., such that it would be impossible to develop a system that was correctly modelled by them all. For example, a sequence diagram might involve an object receiving a message even though the object's class didn't have an operation of that name according to the class diagram. Exercise: think of some more.

Activity diagrams

Some people were a bit confused about the basic idea of activity diagrams. (Seems as though the videos didn't start simple enough, particularly for people who haven't seen related diagram types like flowcharts before. Sorry about that; I'll fix it for next year, if not before. If anyone is still confused, let your tutor or me know.) The basic idea 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.

I discussed the 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.

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.)

We didn't this year, but might have, 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 (see here) 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)