CS3773 Software Engineering Lecture 06 UML State Machines.

Slides:



Advertisements
Similar presentations
1 CIS224 Software Projects: Software Engineering and Research Methods Lecture 6 State Machine and Activity Diagrams (Based on Stevens and Pooley (2006,
Advertisements

Nested state diagrams:Problems with flat state diagram
Concepts & Notations. Acknowledgements  The material in this tutorial is based in part on: Concurrency: State Models & Java Programming, by Jeff Magee.
UML State chart/machine diagram State machine diagram is a behavior diagram which shows discrete behavior of a part of designed system through finite state.
Models of Concurrency Manna, Pnueli.
5/24/2015CPSC , CPSC , Lecture 71 Software Engineering, CPSC , CPSC , Lecture 7.
Software engineering Methods Software Engineering Methods State Diagrams Zvi Avidor Written By With additions by Zvika Gutterman and Adam Carmi.
1 CS 691z/791z Topics in Software Engineering Chapter 13: Activity Diagrams & Chapter 19: Basic Statecharts [Arlow and Neustadt, 2002] March 8, 2007.
State Diagram. What is State Diagram?  State diagram is used to show the state space of a given class, the events that cause a transition from one state.
State Machine Diagrams (State Chart in UML 1) Specifying Control (ref: Chapter 11 Bennett, Mc Robb and Farmer)
1 CS 691z/791z Topics in Software Engineering Chapter 20: Advanced Statechart Modeling [Arlow and Neustadt, 2002] March 8, 2007.
Chapter 11: Distributed Processing Parallel programming Principles of parallel programming languages Concurrent execution –Programming constructs –Guarded.
1 CS/CPE 426 Senior Projects Chapter 21: State Machines Chapter 22:Advanced State Machines [Arlow and Neustadt 2005] March 24, 2009.
THE OBJECT-ORIENTED DESIGN WORKFLOW Statechart Diagrams.
State Change Modelling. Aim: To introduce the concept and techniques for describing the changes in state that may occur to an object in its lifetime.
Advanced Behavioral Modeling
SE-565 Software System Requirements More UML Diagrams.
State and Sequence Diagrams Modelling dynamic information So far we have seen: Use Case Diagrams – requirements capture, interface.
State Machine Diagram Chapter 10. State Machine Diagram Used to describe system behavior.
Lecture 4 Finite State Machine CS6133 Software Specification and Verification.
CS3773 Software Engineering
Chapter 10 State Machine Diagrams
BPMN By Hosein Bitaraf Software Engineering. Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 8: Modelling Interactions and Behaviour.
מידול התנהגותי 1. Today’s Session Sequence Diagrams State Machines 2.
Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology Favoritenstraße 9-11/188-3, 1040 Vienna,
Fall 2010 CS4310 Requirements Engineering UML: Dynamic Modeling Dr. Guoqiang Hu Department of Computer Science UTEP 1.
Behavioral diagrams Lecture p4 T120B pavasario sem.
Object-Oriented Modeling Using UML CS 3331 Section 2.3 of Jia 2003.
1 Modeling interactions and behavior Lecturer Dr. Mai Fadel.
1 A Student Guide to Object- Oriented Development Chapter 7 State Diagrams.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
Information System Design IT60105
Software Engineering Design & Modeling Statechart Diagram.
1 Kyung Hee University Statecharts Spring Kyung Hee University Specifying Objects’ Behaviour  Interaction diagrams show message-passing behaviour.
CSCI-383 Object-Oriented Programming & Design Lecture 12.
State Modeling. Introduction A state model describes the sequences of operations that occur in response to external stimuli. As opposed to what the operations.
Object Oriented Analysis & Design & UML (Unified Modeling Language)1 Part VI: Design Continuous Activity Diagams State Diagrams.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 UML State Diagrams.
States.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 26. Review UML behavioral Diagrams – Sequence diagram.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 10: Statecharts.
MCS 270 Spring 2014 Object-Oriented Software Development.
Modeling Object Lifecycles and State-Dependent Behavior ©SoftMoore ConsultingSlide 1.
State Machine Diagram Chapter 5 Introduction Pages
2/25/2016COSC , Lecture 191 Real-Time Systems, COSC , Lecture 19 Stefan Andrei.
State Modeling. Introduction A state model describes the sequences of operations that occur in response to external stimuli. As opposed to what the operations.
® IBM Software Group © 2009 IBM Corporation Module 11: Creating State Machine Diagrams Essentials of Modeling with IBM Rational Software Architect V7.5.
1 Object Oriented Analysis System modeling = Functional modeling + Object modeling + Dynamic modeling Functional modeling = Use cases Object modeling =class.
UML Review: State Machines. Sept. 17, 2003Lecture 5: CS660 Fall Overview States Transitions Activities Modeling object lifeline Creating well-structured.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Advanced UML State Diagrams.
State Machine Model.
State Diagram – Advanced Concepts
State Machine Diagram.
State Machine Diagrams
Marlon Dumas Institute of Computer Science
Activity Diagram.
State Machine Diagrams
CS251 – Software Engineering Lectures 11 State Diagrams
UML Activity Diagrams & State Charts
States.
CS/CPE 426 Senior Projects
Advanced State Chart diagrams
Chapter 5 state Modeling
CS/CPE 426 Senior Projects
Marlon Dumas Institute of Computer Science
States.
CHAPTER 2 Object-Oriented Modeling Using UML (Continued)
CS 791Z State Machines & Advanced State Machines
UML State Diagrams.
Presentation transcript:

CS3773 Software Engineering Lecture 06 UML State Machines

UTSA CS State Diagram  Recall the delays in a sequence diagram, between when an object receives a message and when it outputs another message  State diagram shows what the object does in between the receiving and the sending of messages  Show the behavior of an object across several use cases  One state diagram per class to describes possible behavior for each instance of the class

UTSA CS State Diagram  State diagram shows how a system or an object's behavior changes over time depending on the input, rather than represent end-to-end behavior  Shows how a system or an object reacts to messages received – Which state the object shall go to – When it outputs messages to other objects – How an object changes the values of its attributes by assignments

UTSA CS State Diagram – An Example

UTSA CS State Diagram  Elements of a state diagram – State represents the mode of the system Always an initial state (starting state) Sometimes a final state – Transition describes a change in state due to the occurrence of an event From one state to another state

UTSA CS State  Partitions object behavior e.g., not being able to check out a borrowed book  Represents the history of inputs so far  Affects what input the object will react to e.g., ignoring most input in the state “lost”  Is an assignment to a collection of attributes

UTSA CS Transition  Elements of a transition – event(s) – [condition] – /activities  Each of these parts is optional  Form

UTSA CS Event  An event triggers the transition – A change in the environment e.g., offHook – A message from another object (operation call) – A change in a condition: going from “false” to “true” e.g., when(temperature > 100 degrees – An occurrence of a specific date/time or passage of time e.g., after (20 minutes)

UTSA CS Event  An event occurs instantaneously and it doesn’t persist  Events make an object change state  If the object is in a state and there is no outgoing transition triggered by an event, the event is ignored  Multiple events on a transition label are ORed together

UTSA CS Condition  A condition is a Boolean expression  The value of a condition persists until the variables involved in the condition change their values  The transition cannot fire unless the guard condition is “true”,  Examples – x > 10 – patronHasNoOverdueFine

UTSA CS Activity  An activity is what an object does in response to events  An activity is simple, fast, non-interruptible  Most common activities are – variable assignment – send a message to an object  Multiple activities on a transition are separated by “;” and executed sequentially

UTSA CS State Activities  A state can have activities associated with it  Two types of state activities can manipulate object attributes or other variables – Activity: simple, non-interruptible Associated with a transition or a state Performed on state entry or exit or event – Do activity: interruptible; may require much computation Associated with a state Interrupted by a transition

UTSA CS State Activities  States can be annotated with entry or exit activities, internal activities, and do activities:  entry/activity  event/activity (way to describe reactions to events that don't cause a state change -- internal transitions)  exit/activity  do/activity

UTSA CS State Activities  In a transition, the order of effects: – Exit activities of source – Transition activities – Entry activities of destination, and – State activities

UTSA CS Self-Transition  A self-transition will cause reactivation of exit and then entry events  If you want a self-transition that does not activate these events, you can use an internal transition, labeled with the event and the associated activity e.g., “req/reply” in state “S”

UTSA CS Self-Transition  Compared to an activity on a transition, one could achieve the same behavior – as activity in state – as activity in another, special state

UTSA CS More on Transition  If a transition has no event label, it can occur once any activity associated with the state is complete  Guards on transitions (triggered by the same event) leaving a state should be mutually exclusive

UTSA CS Summary on State and Transition

UTSA CS State Hierarchy  Composite state: a state can contain other states  Composite combines states and transitions that work together towards a common goal  If a transition leaves a composite state, this transition applies to all the sub-states  The sub-states “inherit” the transitions of the composite state  Basic state: a state do not contain other states

UTSA CS State Diagram Without Composite State

UTSA CS State Diagram with Composite State

UTSA CS Orthogonal Composite State  An orthogonal state captures two or more behaviors of the object that happen concurrently each with its own control thread  If there are many orthogonal states for one object, you should consider dividing the behavior between more objects

UTSA CS Orthogonal State – An Example

UTSA CS Types of Orthogonal States  Aggregation concurrency – State diagram for an aggregate object is a collection of state diagrams, each of which corresponds to a constituent object  Synchronization of concurrent activities within one object – Object performs two or more activities concurrently – Object completes both activities before it progress to anther state

UTSA CS History  History is a mechanism by which a re-entered composite state can continue executing from the sub-state that was current when control last transitioned out of the composite state  Deep history  Shallow history

UTSA CS History  History is a pseudostate whose meaning is to designate the immediate sub-states at this level in the hierarchy that system was in when the immediate parent state was last exited  History state can be the destination state of a transition  A transition leaving a history state indicates what sub- states to enter if the system has ever been in this state  Syntax H

UTSA CS Deep History  Apply history at all levels in the hierarchy below the history pseudostate  Enter the sub-states that an object was last in when the state was exited  Syntax H*

UTSA CS History State – An Example

UTSA CS Process for Making State Diagram  Decide what the states of an object are  Determine what transitions can move the system from states to states  Represent effect of the execution of a transition – Variable value changes – State changes – Messages sent

UTSA CS Validation of State Diagram  Consistency: multiple transitions leave same state under the same event should have mutually exclusive conditions Problem in hierarchical state machine  Completeness: all possible inputs should be considered  Compatibleness: state diagrams have the same behavior with the sequence diagrams

UTSA CS Reading Assignments  UML and The Unified Process – Chapter 21, “Basic state machines” – Chapter 22, “Advanced state machines”