cs 325: software engineering february 26, 2015 object-state modeling for event-driven systems...

7
CS 325: Software Engineering February 26, 2015 Object-State Modeling for Event- Driven Systems Event-Driven Systems UML State Machine Diagrams State Pattern

Upload: darren-carr

Post on 11-Jan-2016

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: CS 325: Software Engineering February 26, 2015 Object-State Modeling for Event-Driven Systems Event-Driven Systems UML State Machine Diagrams State Pattern

CS 325: Software Engineering

February 26, 2015

Object-State Modeling for Event-Driven Systems• Event-Driven Systems• UML State Machine Diagrams• State Pattern

Page 2: CS 325: Software Engineering February 26, 2015 Object-State Modeling for Event-Driven Systems Event-Driven Systems UML State Machine Diagrams State Pattern

CS 325February 26, 2015Page 2

Event-Driven SystemsSome software systems are dependent

on particular events occurring in order to set up the necessary conditions for specific processing to progress.Consider a digital watch system…

• The watch has four modes: display, set-alarm, stopwatch, and set-time-and-date.

• The watch has three buttons: mode (for going to the four modes), start-stop (for advancing values in the different modes), and light (for selection, lighting, and stopping the buzzer).

Essentially, the entire system can be viewed as a system of events that allow the system to transition between various states.

• Starting in display mode, pressing the mode button repeatedly takes the watch to set-alarm mode, to stopwatch mode, to set-time-and-date mode, and back to display mode, in that order.

• For each mode, the light button is used to step through the values that can be set (e.g., in set-time-and-date mode, set the hour, then the minute, then the second, then the month, then the day, and finally the day of the week).

Page 3: CS 325: Software Engineering February 26, 2015 Object-State Modeling for Event-Driven Systems Event-Driven Systems UML State Machine Diagrams State Pattern

CS 325February 26, 2015Page 3

UML State Machine DiagramsState Machine Diagrams show the states

of an object and the transitions that can cause a change in state.

This example models the login process for an on-line banking system.

Page 4: CS 325: Software Engineering February 26, 2015 Object-State Modeling for Event-Driven Systems Event-Driven Systems UML State Machine Diagrams State Pattern

CS 325February 26, 2015Page 4

UML State Machine DiagramsA state machine diagram for the digital

watch:

Page 5: CS 325: Software Engineering February 26, 2015 Object-State Modeling for Event-Driven Systems Event-Driven Systems UML State Machine Diagrams State Pattern

CS 325February 26, 2015Page 5

State PatternConventional means of implementing state machines have serious drawbacks…

Switch (mode){ Case Display: Switch (button): { Case Mode: Case StartStop: Case Light: } Case SetAlarm: Switch (button): { Case Mode: Case StartStop: Case Light: }

Case Stopwatch: Switch (button): { Case Mode: Case StartStop: Case Light: } Case SetTimeAndDate: Switch (button): { Case Mode: Case StartStop: Case Light: }}

For example, the nested-switch approach is difficult to comprehend, to test, to maintain, and especially to modify.

Page 6: CS 325: Software Engineering February 26, 2015 Object-State Modeling for Event-Driven Systems Event-Driven Systems UML State Machine Diagrams State Pattern

CS 325February 26, 2015Page 6

State PatternThe State Pattern is a design pattern to address the implementation of a state machine.

Page 7: CS 325: Software Engineering February 26, 2015 Object-State Modeling for Event-Driven Systems Event-Driven Systems UML State Machine Diagrams State Pattern

CS 325February 26, 2015Page 7

State Pattern• The State Pattern localizes state-specific

behavior in an individual class for each state, and puts all of the behavior for that state in a single object, eliminating the necessity for a set of long, look-alike conditional statements scattered through the program’s code.

• By aggregating state-specific behavior into state classes with intention-revealing names, it’s easier to find that specific logic, and it’s all in one place, improving cohesion.

• Extending the behavior is just a matter of defining additional state classes and modifying the linkages between the states.