Jam 07 - Exercise 3: State Diagrams

--- title: "Jam 07 - Exercise 3: State Diagrams" tags: - 2 📝 in writing - 3 🧪 in testing - 4 🥳 done - inheritance - interfaces - polymorphism - uml - abstract-classes - junit ---   {%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 :::