## Chapter 25 - The Unified Modeling Language

## Chapter Goals

- To continue the exploration of the UML
- To understand the creation and application of cases
- To learn how to create and use the various diagram types in the UML
- To understand how sequence diagrams help document the dynamic relationships between classes

## 25.1 Graphical Notation

- Convey design information
- Relationship information easily extracted
- The following scale better than flowcharts:
  - Object diagrams (chptr. 10)
  - Class diagrams (chptr. 11)
  - CRC cards (chptr. 13)
- To follow: wider variety of class, sequence, and state diagrams, and use cases

## 25.2 Use Cases

- Describe how a system should work
- Each case:
  - Focuses on a specific scenario
  - Describes steps to completion
- Each step represents an interaction between an outside entity (actor) and the system
- Use case must complete to a point that is of some value

## 25.2 Use Cases

E.g., a voice mail system:

- "Leave a message" - steps a caller (the actor) must take
  - Value: actor deposits a message
- "Retrieve messages" - steps the mailbox owner must take
  - Value: actor retrieves his messages

## 25.2 Use Cases

- A use case should have:
  - Descriptive name
  - Main sequence of actions
  - Variants
    - Description of possible failures
- Can be made simple or formal

## 25.2 Use Cases - E.g.

### Leave a Message:

1. Caller dials mail system
2. System prompts for mailbox:
   `Enter mailbox #`
3. Caller enters recipient's extension
4. System prompts for message:
   `Leave message for xxx`
5. Caller speaks message
6. Caller hangs up
7. System stores message in recipient's mailbox

## 25.2 Use Cases - E.g. (cont.)

#### Variation #1:

1.1 | User enters invalid extension (Step 3)
1.2 | System responds `Invalid mailbox #`
| 1.3 | Continue with Step 2

#### Variation #2:

2.1 | Caller doesn't leave a message (after Step 4)
2.2 | System discards empty message

## 25.3 UML Class Diagrams

- Static
- Describe class relationships
- Classes drawn as boxes
- Appropriate attributes and methods in additional compartments:

## 25.3 UML Class Diagrams (cont.)

- Important attributes and methods are listed
- Type of attributes and parameters can be specified attribute : Type

  > `text : string`

- Similarly for return type of methods:

  > `get_message(index : int) : Message`

- Types often omitted for attributes, parameters, and return values

## 25.3 UML Class Diagrams (cont.)

Links (connectors) for class diagrams: |

## 25.3 UML Class Diagrams (cont.)

- Denote multiplicity at the endpts. of the aggregation connector
- Common notations:

  `*` | zero or more
  `1..*` | one or more
  `0..1` | zero or one
  `1` | exactly one

## 25.3 UML Class Diagrams (cont.)

- Enclosing class contains arrow tip
- A queue may have 0 or more messages
- A message will be on exactly one queue

## 25.3 UML Class Diagrams (cont.)

- Composition - stronger form of aggregation
- Contained objects do not exist independently
- A solid diamond is used
- A message queue is permanently contained in a mailbox:
- But messages are not specific to a given queue

## 25.3 UML Class Diagrams (cont.)

- An association is a more general relationship
- Used early in the design
- Solid line w/no diamond
- Roles can be written at the ends of the lines:
- Students register for courses, courses have students
- Bidirectional

## 25.3 UML Class Diagrams (cont.)

- Associations are often directed
- E.g., messages know nothing about the containing queue:
- Use open arrow
- Try to minimize dependencies

## 25.4 Sequence Diagrams

- Show dynamics of a scenario
- Describe communications among objects
- Most commonly illustrates the behavior of a single method

## 25.4 Sequence Diagrams (cont.)

- E.g., adding a message to a mailbox. The mailbox adds it to its new-message queue:

  > `new_messages.add(...)`

## 25.4 Sequence Diagrams (cont.)

- Objects are boxes w/underlined text
- Text might be:
  - `object_name : ClassName`
  - `object_name`
  - `: ClassName`
- Dashed vertical line is the lifeline

- Used to sequence events

- Rectangles are activation bars

- Object is executing a method (or waiting)

- Arguments are not listed

## 25.4 Sequence Diagrams (cont.)

A method called on the same object: |

## 25.4 Sequence Diagrams (cont.)

- Use `<<create>>` to denote the creation of a heap object:

## 25.4 Sequence Diagrams (cont.)

- Omit a large amount of detail
- Generally omit branches and loops (though notation is defined)
- Just show the principal objects and order of calls
- Can document complex interactions

- Common when a limited object collaborates w/several others

## 25.5 State Diagrams

Describe a discrete set of states that affect behavior Lists the transitions (some event) between the states E.g., to retrieve recent messages, user must Enter mailbox # Enter passcode Enter menu command |

## 25.6 Case Study: A Voice Mail System

- Simulation of a simple voice mail system
- 3 events:
  - Press a button - a single numeric character ('`#`' denotes end of sequence)
  - Hang up - '`H`' by itself
  - Speak - any other input
- Analysis phase: first formal step

- Define behavior of system through use cases
- Not a full spec (limitations, performance, etc.)

## 25.6.1 Use Cases for the Voice Mail System

### Reach an Extension

1. The caller dials main # of system
2. System speaks prompt:
   `Enter mailbox number followed by #`
3. Caller enters number of recipient
4. System speaks:
   `You have reached mailbox xxxx. Please leave message.`

## 25.6.1 Use Cases for the Voice Mail System (cont.)

### Leave a Message

1. Caller Reaches an Extension
2. Caller speaks msg
3. Caller hangs up
4. System places msg in recipient's mailbox

## 25.6.1 Use Cases for the Voice Mail System (cont.)

### Log in

1. Mailbox owner Reaches an Extension
2. Owner enters the passcode, followed by # key. (Default passcode same as mailbox number. Owner may Change the Passcode)
3. System plays mailbox menu:
   `Enter 1 to retrieve your msgs
   Enter 2 to change your passcode Enter 3 to change your greeting`

## 25.6.1 Use Cases for the Voice Mail System (cont.)

### Retrieve Messages

1. Owner Logs in
2. Owner selects "`retrieve msgs`" option
3. System speaks msg menu:
   `Enter 1 to listen to current msg
   Enter 2 to save current msg Enter 3 to delete current msg Enter 4 to return to mailbox menu`

## 25.6.1 Use Cases for the Voice Mail System (cont.)

### Retrieve Messages (cont.)

4. Owner selects "`listen to current msg`" option
5. System plays current new msg; if none exists, plays current old msg. Neither queue is changed
6. System speaks msg menu
7. Owner selects "`delete current msg`" option. Msg permanently removed
8. Go back to Step 3

## 25.6.1 Use Cases for the Voice Mail System (cont.)

#### Variation #I. Saving a message

1.1 | Start at Step 6
1.2 | Owner selects "`save current msg`". Msg is removed from its queue, added to queue of old msgs.
1.3 | Go back to Step 3

## 25.6.1 Use Cases for the Voice Mail System (cont.)

### Change the Greeting

1. Owner Logs in
2. Owner selects "`change your greeting`" option
3. Owner speaks the greeting
4. Owner presses the `#` key
5. System sets the new greeting

## 25.6.1 Use Cases for the Voice Mail System (cont.)

#### Variation #I. Hang up before confirmation

1.1 | Start at Step 3
1.2 | Owner hangs up (disconnects)
1.3 | System keeps old greeting

## 25.6.1 Use Cases for the Voice Mail System (cont.)

### Change the Passcode

1. Owner Logs in
2. Owner selects "`change your passcode`" option
3. Owner types new passcode
4. Owner presses the `#` key
5. System sets the new passcode

## 25.6.1 Use Cases for the Voice Mail System (cont.)

#### Variation #I. Hang up before confirmation

1.1 | Start at Step 3
1.2 | Owner hangs up (disconnects)
1.3 | System keeps old passcode

## 25.6.2 CRC Cards for the Voice Mail System

- Discover classes
- Nouns from the functional specification:
  - Mailbox
  - Message
  - MailSystem

## 25.6.2 CRC Cards for the Voice Mail System (cont.)

### `Mailbox`

- Keeps messages
- Track new vs. saved msgs
- Messages can be
  - Deposited in mailbox
  - Retrieved
  - Saved
  - Deleted
- Need FIFO - use queues
- New vs. saved - use 2 queues
- CRCs, so far:

## 25.6.2 CRC Cards for the Voice Mail System (cont.)

### `MailSystem`

Need a class to manage mailboxes: |

## 25.6.2 CRC Cards for the Voice Mail System (cont.)

### `Telephone` (simulation)

Take user input Play (display) output on speaker |

## 25.6.2 CRC Cards for the Voice Mail System (cont.)

### `Connection`

Multiple phones connected to system Each connection keeps track of current state Create a separate class, to avoid bogging down system Driver responsible for creation of `Telephone`, `MailSystem`, and `Connection` |

## 25.6.2 CRC Cards for the Voice Mail System (cont.)

### Leave a Msg use case - simple scenario walkthrough

1. User types an extension:
   - `Telephone` sends number to `Connection`
   - `Connection` collaborator of `Telephone`
   - Place the 2 cards adjacent)
2. `Connection` asks `MailSystem` to find appropriate `MailBox` object
   - Vaguely included in the "manage mailboxes" responsibility
   - Keep `MailSystem` and `Mailbox` cards close to `Connection` card
3. `Connection` asks `Mailbox` for its greeting
   - Add "manage greeting" to `Mailbox` responsibilities
   - add `Mailbox` as a collaborator of `Connection`

(cont.)

## 25.6.2 CRC Cards for the Voice Mail System (cont.)

### Leave a Msg use case (cont.)

4. `Connection` asks `Telephone` to play greeting
5. User speaks the msg:
   - `Telephone` asks Connection to record it
   - Add "record voice input" responsibility to `Connection`
6. User hangs up:
   - `Telephone` notifies `Connection`
7. `Connection` wraps the msg in a `Message` object
   - Add `Message` as a collaborator of `Connection`
   - Make a `Message` card with responsibility "manage msg contents"
8. The `Connection` adds the `Message` object to `MailBox`

## 25.6.2 CRC Cards for the Voice Mail System (cont.)

### Retrieve Messages use case

First few steps same as preceding.

1. User types passcode
   - `Telephone` notifies `Connection`
2. `Connection` asks `Mailbox` to check passcode
   - Add "manage passcode" responsibility to `Mailbox`
3. If passcode valid:
   - `Connection` sets the `Mailbox` as current
   - asks `Telephone` to speak mailbox menu

## 25.6.2 CRC Cards for the Voice Mail System (cont.)

### Retrieve Messages use case (cont.)

4. User chooses "retrieve msgs" option
   - `Telephone` passes it on to `Connection`
5. `Connection` asks `Telephone` to speak msg menu
6. User types in the "listen to current message" option
   - `Telephone` passes it on to the `Connection`
7. `Connection` gets first `Message` from current `Mailbox`
   - sends its contents to the `Telephone`
   - Add "retrieve messages" responsibility to Mailbox)

## 25.6.2 CRC Cards for the Voice Mail System (cont.)

### Retrieve Messages use case (cont.)

8. `Connection` asks the `Telephone` to speak the message menu
9. User types in "save current message" option

- The `Telephone` passes it on to the `Connection`

10. `Connection` tells the `Mailbox` to save current msg
    - Modify the responsibilities of `Mailbox` to retrieve, save, delete messages)
11. The `Connection` asks the `Telephone` to speak the message menu

## 25.6.2 CRC Cards for the Voice Mail System (cont.)

The updated `Mailbox` CRC: Remaining use cases do not add new information, hence, omitted |

## 25.6.2 CRC Cards for the Voice Mail System (cont.)

- High level reasoning is difficult
- Easily-implemented operations vs. those that appear easy
- Practice
- Many false starts and detours
- Redesign until system works
- CRC cards are meant to fail early, often, and inexpensively
- Plan to trash your first design
- Practice

## 25.6.3 UML Class Diagrams for the Voice Mail System

- Collaboration parts of the CRC cards show dependencies:
  - `Mailbox` depends on `MessageQueue`
  - `MailSystem` depends on `Mailbox`
  - `Connection` depends on `Telephone`, `MailSystem`, `Message`, and `Mailbox`
  - `Telephone` depends on `Connection`

## 25.6.3 UML Class Diagrams for the Voice Mail System

- Aggregation:
  - System has mailboxes
  - Mailbox has 2 msg queues
  - Queue has msgs (maybe)
  - A `Connection` has a current mailbox; also references to the `MailSystem` and `Telephone` objects
- No inheritance
- Note: aggregation implies dependency

## 25.6.3 UML Class Diagrams for the Voice Mail System

## 25.6.4 UML Sequence and State Diagrams

- Understand complex control flow w/multiple objects
- `Telephone` reads input
- Passes it to `Connection`
- Postulate 3 functions for `Connection`:
  - `dial` - passes on button press
  - `record` - passes on speech
  - `hangup` - tells connection telephone has hung up

## 25.6.4 UML Sequence and State Diagrams (cont.)

### Leave a Message sequence diagram

## 25.6.4 UML Sequence and State Diagrams (cont.)

### Leave a Message sequence diagram

1. Caller keys in extension (shown as single call to `dial`)
2. `Connection` calls system's `find_mailbox`
3. The `Mailbox` object on the right is returned
4. Connection invokes `get_greeting`
   (greeting is passive; doesn't appear on diagram)
5. Connection plays appropriate greeting
6. Telephone reads msg from user, passes it to connection
7. Telephone reads hangup, passes it to connection
8. Connection constructs `Message`, adds it to mailbox

## 25.6.4 UML Sequence and State Diagrams (cont.)

### Retrieve a Message sequence diagram

## 25.6.4 UML Sequence and State Diagrams (cont.)

- System is not in control of input
- Telephone notifies connection of any input event
- E.g., connection is called 3 times during Leave a Msg
- The connection must keep track of states, to determine proper action on given input
- Next slide is the state diagram for the system

## 25.6.4 UML Sequence and State Diagrams (cont.)

## 25.6.5 Implementation

- Following files can be downloaded and run
- Enter `Q` to quit
- Look at the classes
- Compare documentation to the CRC cards and UML diagrams
- Trace functions calls, compare to the sequence diagrams
- Find the state transitions for `Connection`
- Only modify `Telephone` and `MailSystemTest` to add a GUI (chptr 27)

## 25.6.5 Implementation (`message.h`)

## 25.6.5 Implementation (`mailbox.h`)

## 25.6.5 Implementation (`mailbox.cpp`)

## 25.6.5 Implementation (`mailsystem.h`)

## 25.6.5 Implementation (`mailsystem.cpp`)

## 25.6.5 Implementation (`telephone.h`)

## 25.6.5 Implementation (`telephone.cpp`)

## 25.6.5 Implementation (`connection.h`)

## 25.6.5 Implementation (`connection.cpp`)

## 25.6.5 Implementation (`mailsystemtest.cpp`)

## Chapter Summary

1. Graphical notations help convey design information
2. Use cases provide concrete scenarios from which general action can be abstracted
3. Class diagrams record various relationships, including use, dependency, and inheritance
4. Sequence diagrams record the dynamic interaction between objects
5. State diagrams are useful for documenting objects that change their behavior during the course of execution according to their current state