A stable and common visual design language that can be used to develop and build computer applications.

They're like blueprints for programmers and system engineers.

UML

Last century (1997) there was a need for a unifying language enabling IT professionals to model computer applications. At the beginning there were competing methods like OMT, OOSE, and Booch, but their authors eventually joined forces and brought about an open standard: UML.

It is programming-language independent, so it can be used with C++, Visual Basic, Java, Python: anything.

It provides several types of diagrams that make it easier to understand an application under development.

The most useful, standard UML diagrams are:

• use case diagram (UCD) (needed for the Software Development course) - this is a picture of functional requirements
• class diagram
• sequence diagram
• statechart diagram
• component diagram
• deployment diagram.
• activity diagram

In VCE SD, we only need to know about the UCD.

Use-case diagrams (UCD)

UCD is created during system analysis phase of Problem Solving Methodology to plan the system's functional requirements: what it should be capable of doing.

Use case diagrams describe what a system does from the standpoint of an external observer.

The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system.

The emphasis is on what a system does rather than how. How is worked out later in the design phase.

The Use Case Model is not intended to be an exhaustive definition of system functionality. It rather serves to scope the system's high-level functionality by defining what functions will or will not be performed by the system in sufficient detail that we can be sure we haven't missed anything important.

A use case (the oval shape shown below) illustrates a unit of functionality provided by the system.

Use case diagrams are helpful in:

• determining features (requirements). New use cases often generate new requirements as the system is analysed and the design takes shape.
• communicating with clients. Their simplicity makes use case diagrams a good way for developers to communicate with clients.

The main purpose of the UCD is to help development teams visualize the functional requirements of a system, including the relationship of actors to essential processes, as well as the relationships among different use cases.

ACTORS

Actors are drawn as stick figures. Cos stick figures are cool. Like ninjas, but without swords.

An actor is who or what initiates or participates in the events involved in that task.

Remember: an actor can be software or a company - it does not have to be a person!

An actor is always outside the system being modelled. Anything that is part of the system we are defining is not an actor. So don't put the 'database that stores customer information' as an actor on the UCD. It is part of the system and so cannot be an actor.

Primary actors are those that require assistance or service from the system. They initiate a use case.

Secondary actors are those from whom the system requires assistance. They respond to a use case.

USE CASES

To show a use case on a UCD, draw an oval in the middle of the diagram and put the name of the use case in or below the oval.

Draw a stick person to the left or right of your diagram. Use solid lines to depict associations between actors and use cases.

Association lines can have an optional arrowhead on one end of the line. The arrowhead is often used to indicate which actor invoked (initiated) the relationship. That actor is called the primary actor within the use case. 

Note: The arrowheads do not show data flow (like DFDs). They indicate the actor who initiates a use case.

So, use cases capture who (the actor) does what (the interaction) with the system, for what purpose (goal), without dealing with system internals.

A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required of the system. This defines the scope of the system.

Tip: You should be able to translate a case study into a UCD (needed for Unit 3 Outcome 1) and re-recreate a case study (tell the story of what can happen in the system) by reading the UCD.

Tip: You will find differences of opinion in how UCDs are to be drawn, especially when they get complex. There is no 100% agreed-on set of instructions of how to do them; a degree of personal style and craftsmanship is involved. Just try to make your UCDs as unambiguous and meaningful as possible.

Example 1 (source)

Here is a scenario for a medical clinic.

• A patient calls the clinic to make an appointment for a yearly checkup.
• The receptionist (scheduler) finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot.

Below is a UCD describing the processes used in the medical clinic's system.

• The Patient is an Actor.
• The connection between actor and use case is a communication association (or communication for short, or association for short).
• The stick figures are actors.
• The ovals are use cases.
• The lines or arrows between actors and use cases are associations (also called communications).

We've put Make Appointment as part of a diagram with four actors and four use cases.

Notice that a single use case can have multiple actors.

Reading this UCD

• the patient and scheduler are actors involved in making and cancelling appointments.
• the patient can request medication from the doctor
• the tasks associated with paying the bill happen between the patient and the clerk.

Notice how use case names always start with an active verb ('pay', 'make', 'request' etc)

Tip: As you do in DFDs, don't combine sentences with commas or 'and'. This implies that interactions have been combined.

Note: don't repeat actors or use cases on the same diagram! This can lead to a lot of artistic rearrangement of the UCD, which makes them a nightmare to draw by hand. Using the right software (like Dia, gliffy.com, a Google Docs Drawing or MS Visio) lets you drag around actors (for example) and have their attached associations move with them.

Note the lack of clarity in the UCD above:

• who initiates the bill payment use case - the patient or clerk? Such issues can be important, otherwise some use cases might never be triggered! The bills may never get paid!
• can a scheduler cancel an appointment? Is that what the client wants the system to allow?
• can a scheduler make an appointment? (e.g. the doctor might realise she needs to see the patient again after the previous visit's tests have come back)

Here's a variation of the UCD with more information provided:

This makes things clearer. Only the patient can make or cancel an appointment. It's the clerk who is responsible for getting bill payment procedures underway. By thinking through the use of arrows like this, it makes developers and clients really concentrate on the desired behaviour of the system. For example, having added arrows above, they might realise it's vital that the scheduler can cancel an appointment (e.g. an emergency case arrives so a scheduled appointment becomes impossible.)

In such a case, a new arrow is NOT added to the line from the scheduler's side! The existing arrowhead attached to the top use case must be removed.

You cannot have two or more associations with arrowheads leading to the same use case!

IMPORTANT TO KEEP IN MIND - Actors are roles, not people.

Mr Southerby as CEO needs access to management information.

Fred Smith as Order Entry Clerk needs to enter orders.

Sometimes Mr Southerby may need to enter an order when Fred isn't there.

NO! That doesn't mean that we draw an arrow between Mr Southerby and the Enter Order use case.

Entering orders is not the role of either Mr Southerby nor the CEO - it's the role of the clerk.

Mr Southerby may be CEO but when he enters an order, he's taken on the role of Clerk.

Notice above, only the clerk enters orders: whether it's Fred or Mr Southerby is not relevant.

When naming actors we need to think of the role that a person takes on rather than their name or job title.

Most job titles involve the putting on of a number of different hats in different situations.

So name the actor with the role rather than the job title if there is any confusion. Think hats!

(Thanks to http://www.cragsystems.co.uk for that tip)

Practice reading a UCD

Quiz

Answers (click and drag over the white space below to see the answers)

• The person acting as an order entry clerk may initiate an Order Entry and the cancellation of an order. The clerk is the primary actor in both use cases.
• The Accounts system is triggered into action by an order entry to be involved in that process. It is a passive actor in this use case.
• The arrow means that at some point in the use case the system will query the accounts system for customer account information and the accounts system will respond.
• The accounts system can also initiate (be the primary actor) in the process of getting of an address.
• On each arrow relationship, interaction still occurs in both directions between the actors and system as part of each use case.
• The arrow indicates only which party has started the potentially bi-directional interaction.
• One more time: An arrow does not indicate the sole direction of data flow!

Scenarios

A scenario represents a single path through the use case. Thus, one may construct a scenario for the main flow through the use case, and other scenarios for each possible variation of flow through the use case (e.g., triggered by options, error conditions, security breaches, etc.).

Includes and Extends

<<includes>>

denotes the inclusion of behaviour described by another use case.  Think of it like a subprogram. They are always called, unlike extends which are conditionally called.  Imagine it as bolting on another set of actions that have already been defined somewhere else – it saves repetition and wasted space.

In the UCD below, both the Manage Customer Details and Enter Order use cases include the Find Customer Record use case.

<<extends>>

Like a conditional <<include>>.A use case that extends another use case (the ‘base’ use case) when circumstances require it. 

When the extending use case’s activities are finished, the base use case’s activities continue.
The extending use case is really an alternate course of the base use case. It can be used to describe different actions to be taken dependent on current condition. 

In other words, it can indicate conditional branches in activities.

http://en.wikipedia.org/wiki/File:Use_case_restaurant_model.svg

Note: Solid lines or arrows between use cases are not allowed. The only way to link use cases is with includes or extends.

READING A UCD

Use-case diagrams generally show groups of use cases.

Reading the UCD above you can easily tell the functions that the system provides.

• This system lets the band manager view a sales statistics report and the Billboard report for the band's CDs.
• It also lets the record manager view a sales statistics report and the Billboard report for a particular CD.
• Our system fetches Billboard reports from an external system called Billboard Reporting Service.

In addition, the absence of use cases in this diagram shows what the system doesn't do.

For example, it does not provide a way for a band manager to listen to songs from the different albums on the Billboard — i.e. we see no reference to a use case called Listen to Songs from Billboard 200. This absence is not a trivial matter.

With clear and simple use-case descriptions provided on such a diagram, people can easily see if needed functionality is present or missing in the system.

(Thanks to IBM for that info)

Creating UCDs

There are different styles...

• Start by identifying as many actors as possible.
• Ask how the actors interact with the system to identify an initial set of use cases.
• Draw the actors and connect them with the use cases with which they are involved (i.e. the actor supplies information, initiates the use case, or receives any information as a result of the use case)

OR

• Start by identifying one actor and the use cases that they’re involved with.
• Develop the model from there.

Use case diagrams often start as text outlines of processes like this:

1. Clerk enters customer ID into system.
2. If ID exists, account management module is triggered.
3. Otherwise, New Account module is triggered.
4. Then, clerk enters a product IDs of customer's purchase.
5. If an item is not in stock, customer is advised of delay in delivery and the back-order process is triggered.
6. 4 to 5 may be repeated
7. Clerk then.... (etc)

This textual description can then be converted into a matching UCD...

System Boundaries

You can draw a rectangle – the system boundary - around use cases to indicate the scope of the system.  They are not often used. 

An example of their use is to mark off functional components that will be rolled out in different major releases of a system...

From http://www.agilemodeling.com/artifacts/useCaseDiagram.htm

Note: the arrow indicates that the actor starts the interaction between the actor and the use case

Example 2 (source)

Reading the example above, students are enrolling in courses with the potential help of registrars.

• Grade administrators input the marks students earn on assignments.
• Registrars authorise the distribution of transcripts (report cards) to students.
• For a student to drop a seminar, the Registrar needs to be involved.
• Students can also drop out or graduate - each being a use case having its own tasks to carry out.
• Students and the financial institution interact to obtain student grants or loads, reimburse course fees or pay fees.
• The post office distributes information to students, and may perhaps also distribute transcripts.
• The post office also may perhaps distribute fee schedules.

Notes

• The conditional 'may perhaps' actions are shown as <<extends>> - see below.
• Arrows with arrowheads do not indicate data flow: information is assumed to flow back and forth between the actor and the use case (the oval shapes).
• Tip: Information flow can be modeled using data flow diagrams.
• If there is no arrowhead on an association line, it is not clear how the interaction between the actor and the use case starts.
• See below to find out about the difference between "triangle" arrowheads arrows with "crow's feet" arrowheads.

Notes

• Note how for some use cases there is more than one actor involved.
• Actors are always involved with at least one use case
• Actors are always drawn on the outside edges of a use case diagram.

Example 4 (source)

• Above, the three main use cases are “customer uses machine”, “maintain machine” and “audit”
• The actors are “customer”, maintenance engineer“,”“local branch official” and “central computer”.
• The actors as stick people (even where they are machines).
• Lines (associations) connect use cases to the actors who are involved with them.
• A box around the use cases emphasizes the boundary between the system (defined by the use cases) and the actors who are external. Not everyone likes to use a box around the use cases. It is a matter of personal choice.
• Note how headed arrows show that the Local bank office initiates the ATM maintenance use case; the customer initiates the use of the ATM; the use of the ATM initiates interaction with the central computer.
• It's spooky but true that headed arrows are not an offical part of the UML gospel! They have grown out of the desires of common users! Viva La Revolución !

Example 5 (source) - more advanced

• Use Case "Take Order" can «include» sub-tasks such as Use Case "Serve Water".
• If the Extensions Points of Use Case "Prepare Order" apply, then Use Case "Prepare Order" can «extend» to Use Case "Restock".
• Generally use case "Deliver Order" can be substituted for use case "Serve Order" in particular situations.

MASTERCLASS

How much detail in a use case?

How big does a process need to be to get its own use case? It's a matter of judgement. Consider the following situation:

If another use case or actor must be involved in any of the three account tasks above, the tasks would want to be separate so they can be addressed individually.

However, if the three actions are never treated individually or triggered conditionally (with an extend), there's no reason not to package them up as a single use case.

If you want to sit on the fence, you could show the sub-tasks using includes.

Some revision examples

PRACTICE

Describe what this UCD is telling us. Answers are here.

And in their free time, ninja Use-case diagram actors go wild...

Drawing UCDs:

• Dia
• gliffy.com
• Google Docs Drawing
• MS Visio (free download offer)

A related UCD topic that is outside the scope of VCE Software Development assessment, but still useful, is generalisation.

Appendix - from VCAA Bulletin No. 85 November 2010 Supplement 2, page 5

6. What is the appropriate depth of treatment for use case diagrams?

In Unit 3, Software development, Area of Study 1, students are required to use tools and techniques for depicting the interfaces between solutions, users and networks. One mandated technique is use cases created through tools such as Unified Modelling Language (UML). Use cases diagrams identify the interactions between distinct business functions and business users within information systems to achieve a goal.

Students are not required to have a detailed knowledge of use cases diagrams [my italics], but to gain any real meaning from the technique they need to have knowledge of each of the following elements and how they are symbolically represented.

The elements include:

• actors – the role a business user plays, and the user may play many roles.
• use case – a business function or scenario, and a use case diagram is made up of a collection of use cases.
• associations/communications– lines showing the links between a use case and an actor/s. A use case can be carried out by many actors and an actor may carry out many use cases.
• includes – dotted lines with arrowheads and text with angle brackets <<includes>> showing the links between use cases. Usually it indicates that the functionality of a use case is used in another use case. Generally it is used to avoid repetition of scenarios in multiple use cases.
• extends – dotted lines, with arrowheads and text with angle brackets <<extends>> showing that the functionality of a use case contributes to (or enhances), the functionality of another use case.
• system boundaries – defines the limits of the system that the diagram is representing, which means it shows all of the use cases being represented in that system.