Introduction

This is one a part of a set of notes on the Unified Modelling language -- [ uml.html ]

Scenarios and UseCases

Scenarios and Use-Cases are an ideal place to start a project. They must be expressed in terms that the user and client understands and can (and should) avoid all technical jargon. The set of usecases answer the questions:

---

1. Who wants to use this software?
2. What do they want to do with it?

---

A scenario describes a particular user getting something useful done. A usecase is a set of similar scenarios all with the same type of user and all ending when the user finds out that the process is complete. The user must begin a usecase and must know when it is complete. The user must be active entity - an actor - and communicates with the system to achieve the goal of the usecase.

A usecase is written out in a natural language like English. UML provides a notation for naming and classifying both actors and usecases. Here is a UML diagram that shows three usecases: "add class", "drop class", "get roster", and "submit work" and two actors: "Student" and "Teacher".



Notice the use of a "stick figure" to indicate a class of actors. The usecase is indicated by an oval. Communication is modeled as a simple link between an actor and an usecase.

It is also possible to use the UML generalization relationship between classes of actors: For example a Graduate Student might be a special kind of Student and so could share the Add Class Scenario. The generalisation link is also used between Usecases to indicate that one usecase is a special case of another one, or that one usecase makes use of another one.

Interaction Diagrams

These allow you to work out how your classes can help the user solve problems. Sequence diagrams make the timing of various operations clear. Collaboration diagrams are better for modelling a complex interaction or algorithm. There is no reason why you shouldn't draw both.

Sequence Diagrams

Historically, Charles Babbage was the first person to draw a diagram were each part of a machine was shown as a vertical line, time flows down the page, and connections between the parts flow across the page. This idea has been reinvented several times in the last 10 years.



The above diagram indicates the following sequence of events (inside our program):

---

1. JoDoe asks to drop a class, the request is handled by Jo's Student object -- -- --(jd)
   
2. jd asks the Section --(s) to drop jd.
3. s (the section) passes the message to an Enrollment --(e) which self-destructs.
4. s reports success to jd.
5. jd reports success to Joe.

---

Each vertical line indicates an existing object. When it is active it the line becomes a rectangle. Connections can show flow and whether it is synchronous(----->) or asynchronous(with only half an arrowhead!). Normally the steps are described on the left hand side of the diagram.

Collaboration Diagrams

A collaboration diagram shows how a collection of objects and classes work together (Latin: co - labor = work together) to fulfill a use-case. Each step in the process is numbered and follows a link from one object to another. Here is an example - a first sketch of how the system helps a student add a section:



The diagram above describes the following:

---

1. Jo Doe, a student asks to add a class by giving Jo's student id -- -- --(sid)
   and a section id--(sd).
2. The student class uses the sid to get Jo's object -- (jd) The jd object is passed to the section.
3. The Section class uses the find operation to find the asked for Section object -- -- --(s)
   
4. s finds out which course it is and passes s and jd into the Enrollment class which
5. constructs a new added enrollment linking jd to s.

---

Exercise. There are some obvious errors and ommissions in the above diagram -- fix them!

. . . . . . . . . ( end of section Interaction Diagrams) <<Contents | End>>

State Transition Diagrams

State transition diagrams have been a part of computer science and computer programming since the 1940's. David Harel in the middle 1980's reinvented the state transition diagram in a form that has become popular in many different notations and methods. UML incorporates Harel's StateCharts as a way to work out, document and verify the gross patterns of behavior of an object in a class.

The basic rules are easy to state.

• Draw only one object's chart at a time.
• A state is drawn as a box with rounded corners.
• Each state models a set of possible object values that have similar behavior - but possibly different attribute values.
• A state is in a different box if objects in these states behave differently.
• From each state draw an arrow to another state if the object can change from one to the other in one step.
• Label the arrow with the event that causes it.
• Show the initial state by drawing an arrow from a black blob to the initial state.
• Show the destruction of the object (if there is one) as an arrow going from a state to a blob inside a circle.

Here are a pair of examples showing the life of an idealized Student.



You will notice that in the above pair of diagrams the bottom one has the name of a state in the upper diagram. This means that the the state has been refined. It is also possible to redraw the two diagrams as a single diagram with the refinement replacing the unrefined state.

. . . . . . . . . ( end of section Dynamic Models) <<Contents | End>>

Glossary

 		defined_term::=what_the_term_means.