the road ahead

Classes		Methods
Design Class Diagrams		Interaction (Collaboration) Diagrams
Conceptual Model		Contracts
		System Sequence Diagrams
		Expanded Use Cases

Example

dice game
throw two dice,
if total = 7 you win, else you lose

use case

description of a process in the domain

Use case	Play a game
Actors	Player
Description	Player picks up and rolls the dice. The player wins if the total is 7.

Conceptual model

Concepts - entities recognised in the external world

player

die

dice game

collaboration diagrams

show flow of messages between objects

class diagrams

software components, not external world concepts - but may model concepts

Reading

• Applying UML & Patterns
  part 1, browse
  chapters 4 and 5
• Object Oriented software Construction
  version 1, chapters 1-4 or
  version 2, chapters 1-5

public class Die {

    protected int faceValue;

    public int getFaceValue() {
        return faceValue();
    }

    public void roll() {
        faceValue = (int) (Math.random() * 5 + 1)
    }
}

public class Player {

    protected String name;

    public Player(String name) {
        this.name = name;
    }

    public void play(Die die1, Die die2) {
        die1.roll();
        die2.roll();
    }

    public String getName() {
        return name;
    }
}

public class DiceGame {

    protected Die die1, die2;
    protected Player player;

    public static void main(String[] argv) {
        game = new DiceGame();
        game.play();
        if (game.isWon()) {
            System.out.println("Won");
        } else {
            System.out.printl("Lost");
        }
    }

    public DiceGame(String name) {
        player = new Player(name);
        die1 = new Die();
        die2 = new Die();
    }

    public void play() {
        player.play(die1, die2);
    }

    public boolean isWon() {
        return (die1.getFaceValue() == die2.getFaceValue());
    }
}

Point of Sale Terminal

use cases

(chapter 6)

Narrative describing a sequence of events of an actor who uses a system to complete a process.

Not requirements, but illustrate and imply requirements.

Actors are external to the system

Use cases may be

• high level or expanded
• essential or real

High level use case

concise description of process

Use case	Buy Items
Actors	Customer, Cashier
Type	primary
Description	Customer arrives at checkout with items to purchase. Cashier records purchase items and collects payment. On completion, Customer leaves with items.

Expanded use case

• more details

• includes typical course of events

• may include alternatives

Use case	Buy Items with Cash
Actors	Customer (initiator), Cashier
Purpose	Capture a sale and its cash payment
Overview	Customer arrives at checkout with items to purchase. Cashier records purchase items and collects payment. On completion, Customer leaves with items.
Type	primary
Cross References

Typical course of events

types of use case

Primary

Major common processes
(buy items)

Secondary

Minor or rare processes
(stock new item)

Optional

May not be implemented.
(product recall)

use case diagrams

System boundaries

Use case interaction with system

Must know system boundary

If boundary was store:

use cases

• Actors are external to the system

• Use case is about a process (buy items), not a step (write receipt)

• Identifying use cases

  • Actor based

    1. identify actors

    2. for each actor, identify processes

  • Event based

    1. identify external events

    2. relate events to actors

Alternate opinion on use cases

(Meyer, OOSC pp 738-740)

• Use cases not appropriate for analysis in general, and finding classes in particular.

• They focus on process rather than data abstraction.

• They are appropriate as a validation tool - to inspect a proposed analysis model.

essential use case

Use cases expressed in a way that does not imply an implementation.

examples

Essential	Real
go to the shop	ride your bike to the shop
	hang the clothes on the line
wash the dishes
	send a letter to the customer saying that the goods have arrived

Essential use case

Real use case

development cycles

(chapter 7)

The first version of the software may not implement everything.

• whole system is too complex

• some parts less important

• may want to get something working quickly

So, several versions, each with its own development cycle.

What goes in the first version?

• Rank use cases
• First version implements higher ranking use cases

How to rank use cases

rank use cases higher if they

1. have significant impact on architecture
   (add many classes or extra layer such as persistence)

2. give significant insight into design with little effort

3. require risky, time-critical or complex functions

4. involve significant research or new and risky technology

5. represent core business

6. have impact on "bottom line"
   (more revenue, reduce costs)

Ranking POST use cases

Start up use case

Need at least a simplified version to get going.
eg create an empty store

Start up developed incrementally to satisfy other use cases as they are included.

Where we are