---
# System prepended metadata

title: 'Jam 07 - Exercise 3: State Diagrams'
tags: [polymorphism, "2 \U0001F4DD in writing", inheritance, uml, interfaces, junit, abstract-classes, "3 \U0001F9EA in testing", "4 \U0001F973 done"]

---

---
title: "Jam 07 - Exercise 3: State Diagrams"
tags: 
  - 2 📝 in writing
  - 3 🧪 in testing
  - 4 🥳 done
  - inheritance
  - interfaces
  - polymorphism
  - uml
  - abstract-classes
  - junit
---
<!-- markdownlint-disable line-length single-h1 no-inline-html -->
<!-- markdownlint-configure-file { "ul-indent": { "indent": 4 }, "link-fragments": {"ignore_case": true} } -->

{%hackmd dJZ5TulxSDKme-3fSY4Lbw %}

# Exercise 3 - Understanding Register States

## Overview - Exercise 3

In this exercise, you'll learn about UML state diagrams and how they can be used to model the behavior of complex systems. You'll create a state diagram for the Register class that documents its various states and transitions. This will help you understand how the register behaves in different scenarios and prepare you for implementing this behavior in future exercises.

:::info
🔑 **Key Concepts**

- UML state diagrams and their components
- State transitions and guard conditions
- Composite states and nested behaviors
- Error handling and validation
- State-based behavior modeling

:::

## Understanding State Diagrams

A UML state diagram shows how an object changes state in response to events. Key components include:

- **States**: Represent different conditions or modes of operation
- **Transitions**: Show how the object moves between states
- **Events**: Trigger state transitions
- **Guard Conditions**: Control when transitions can occur
- **Actions**: Activities that occur during transitions
- **Composite States**: Group related states together

### Example: Microwave Oven

Let's look at a simpler example to understand these concepts. Consider a microwave oven:

```plantuml
@startuml
hide empty description

[*] --> IDLE

state IDLE {
    [*] --> DOOR_CLOSED
    DOOR_CLOSED --> DOOR_OPEN : openDoor()
    DOOR_OPEN --> DOOR_CLOSED : closeDoor()
}

state COOKING {
    [*] --> RUNNING
    RUNNING --> PAUSED : pause()
    PAUSED --> RUNNING : resume()
}

IDLE : state DOOR_CLOSED
IDLE --> COOKING : startCooking() [state == DOOR_CLOSED]
COOKING --> IDLE : complete()\nor cancel()

note right of IDLE
  Ready to cook
  Must have door closed to start cooking
end note

note right of COOKING
  Timer running
  Can be paused or running
end note
@enduml
```

This diagram shows:

1. **Main States**
   - IDLE: Microwave is ready but not cooking
   - COOKING: Microwave is actively cooking

2. **Nested States**
   - IDLE contains door states (open/closed)
   - COOKING contains timer states (running/paused)

3. **Transitions**
   - Between main states (IDLE ↔ COOKING)
   - Between nested states (DOOR_OPEN ↔ DOOR_CLOSED)
   - With guard conditions ([if doorClosed])

4. **Documentation**
   - Notes explaining each state
   - Include user/permission requirements
   - Make guard conditions clear and specific
   - Think about what information another developer would need

Remember: A register can't process transactions without a logged-in user, and certain operations require specific permissions!

:::

## The Problem - Exercise 3

Our cash register system needs to handle various states and transitions throughout its operation. We need to:

1. Document all possible states of the register
2. Define valid transitions between states
3. Specify guard conditions for transitions
4. Handle error conditions appropriately
5. Model the complete state behavior

This is a perfect opportunity to use UML state diagrams to model the register's behavior before we implement it.

### Creating Your State Diagram

To create your state diagram, you'll use draw.io. For detailed instructions on using draw.io to create UML state diagrams, please refer to the [draw.io documentation](https://drawio.com/blog/uml-state-diagrams/).

:::info
🎯 **State Diagram Requirements**

Your diagram should model:

1. Two main composite states:
   - IDLE: No active transaction
     - Think about user authentication states
     - Consider what states a register can be in before a transaction starts
   - IN_USE: Transaction in progress
     - Consider the different phases of a transaction
     - Think about what happens between starting and completing a sale

2. State transitions with permissions:
   - Authentication: How does an employee start using the register?
   - Transaction flow: What are the steps in processing a transaction?
   - Payment workflow: How does the system handle payment steps?
   - Think about what permissions are needed for each action

3. Transitions between states with:
   - Method-style event names (include parentheses)
   - Guard conditions checking employee permissions
   - Alternative paths for cancellation or error handling
   - Consider what happens if something goes wrong

4. Documentation:
   - Notes should explain what's possible in each state
   - Include user/permission requirements
   - Make guard conditions clear and specific
   - Think about what information another developer would need

Remember: A register can't process transactions without a logged-in user, and certain operations require specific permissions!

:::

## Save Your Work - Exercise 3

**Export your state diagram**:

1. Select File -> Export as -> PNG
2. In the export dialog:
   - In the "Include a copy of my digram" section, select "Current Page". This is to ensure you don't end up with the example diagram in your export.
   - Click Export
3. In the Save As dialog:
   - Save the file as `RegisterStateDiagram.pdf` in your `jam07` folder
   - In the "Where" box, select "Download"
   - Click OK
4. The file will be in your downloads folder. Move it to your `src/main/java/jam07` folder.

**Verify what files are uncommitted**:

```bash
git status
```

**Stage your changes**:

```bash
git add src/main/java/jam07/RegisterStateDiagram.pdf
```

**Commit your work**:

```bash
git commit -m "jam07: Add Register state diagram"
```

:::success
🔑 **Key Takeaways**

- State diagrams help model complex behavior
- Guard conditions enforce business rules
- Composite states organize related behaviors
- Clear documentation is essential
- State modeling precedes implementation

:::
