State Machine Model. C-S 5462 State Machine View describes the dynamic behavior of objects over time –each object is treated in isolation –the view describes.

Slides:



Advertisements
Similar presentations
Use Case Diagrams Damian Gordon.
Advertisements

State Charts Mehran Najafi. Reactive Systems A reactive, event-driven, object is one whose behavior is best characterized by its response to events dispatched.
Nested state diagrams:Problems with flat state diagram
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.
Use Case & Use Case Diagram
Use Case Model. C-S 5462 Use case model describes what the user expects the system to do –functional requirements may describe only the functionalities.
1 Chapter 4 Dynamic Modeling and Analysis (Part I) Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis H.K. Tsang, Clarence.
1 Chapter 4 Dynamic Modeling and Analysis (Part I) Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis H.K. Tsang, Clarence.
Use Case Diagram © copyright 2001 SNU OOPSLA Lab..
THE OBJECT-ORIENTED DESIGN WORKFLOW Statechart Diagrams.
UML Sequence Diagrams Eileen Kraemer CSE 335 Michigan State University.
UML Notations Activity diagrams State diagrams Class diagrams Use-case diagrams.
Advanced Behavioral Modeling
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.
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
Sharif University of Technology Session # 7.  Contents  Systems Analysis and Design  Planning the approach  Asking questions and collecting data 
1 Lab Beginning Analysis and Design 4 Completion of first version of use case diagram initiates the processes of analysis and design. 4 UML provides.
State and Sequence Diagrams Modelling dynamic information So far we have seen: Use Case Diagrams – requirements capture, interface.
CS451 Introduction to Software Engineering Behavioral Modeling.
Lecture 4 Finite State Machine CS6133 Software Specification and Verification.
Chapter 10 State Machine Diagrams
מידול התנהגותי 1. Today’s Session Sequence Diagrams State Machines 2.
UML Notations in CommonKADS Activity diagrams State diagrams Class diagrams Use-case diagrams.
1 Object-Oriented Modeling Using UML (2) CS 3331 Fall 2009.
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.
Behavioral Modeling Chapter 8.
UML Notations in CommonKADS Activity diagrams State diagrams Class diagrams Use-case diagrams.
1 A Student Guide to Object- Oriented Development Chapter 7 State Diagrams.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
1 Kyung Hee University Statecharts Spring Kyung Hee University Specifying Objects’ Behaviour  Interaction diagrams show message-passing behaviour.
Dynamic Models. Outline Dynamic Models Statecharts –States –Transitions –Composite states Interaction Diagrams –Sequence Diagrams The time order of interactions.
State Modeling. Introduction A state model describes the sequences of operations that occur in response to external stimuli. As opposed to what the operations.
CS212: Object Oriented Analysis and Design Lecture 34: UML Activity and Collaboration diagram.
CS212: Object Oriented Analysis and Design Lecture 32: Use case and Class diagrams.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 UML State Diagrams.
Dynamic Models Sequence Diagrams Collaboration Diagrams Activity Diagrams.
States.
CS3773 Software Engineering Lecture 06 UML State Machines.
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.
Modeling Object Lifecycles and State-Dependent Behavior ©SoftMoore ConsultingSlide 1.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 6: Restaurant.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th Edition Copyright © 2015 John Wiley & Sons, Inc. All rights.
Chapter 3: Software Design –Use case Diagram Nouf Alghanmi.
UC Diagram & Scenario RKPL C & D. Using Use Case Diagram Use case diagrams are used to visualize, specify, construct, and document the (intended) behavior.
York University Department of Computer Science © Castro, Mylopoulos and Easterbrook Lecture 11: Modelling “State”  What is State?  statespace.
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.
Activity Diagram.
State transition modeling
Using Use Case Diagrams
Chapter 4: Business Process and Functional Modeling, continued
State Machine Model.
State Diagram – Advanced Concepts
State Machine Diagram.
State Machine Diagrams
Interaction View.
Dynamic Modeling of Banking System Case Study - I
Static and Dynamic Modeling Using UML
State Machine Diagrams
UML Activity Diagrams & State Charts
States.
Object Oriented System Design
SAD ::: Spring 2018 Sabbir Muhammad Saleh
CIS 375 Bruce R. Maxim UM-Dearborn
Using Use Case Diagrams
States.
Software Engineering System Modeling Chapter 5 (Part 1) Dr.Doaa Sami
Presentation transcript:

State Machine Model

C-S 5462 State Machine View describes the dynamic behavior of objects over time –each object is treated in isolation –the view describes the events and operations that manipulate the object the state view of the entire system is described by a collection of state diagrams, one corresponding to each class in the system

C-S 5463 About State Diagram one state diagram per class in the class diagram one logical state diagram may be spread out into one or more physical diagrams for space considerations enrichment of the finite state machine model based on David Harel’s State charts, tailored towards object-orientation

C-S 5464 Main components of a state diagram a collection of states of the object under consideration a collection of actions while entering a state, existing a state or within a state a collection of transitions between the states of the object a collection of events that trigger transitions a collection of conditions (optional) that might constrain the triggering of events, or implementations of transitions

C-S 5465 State diagram – basic syntax initial final State name Unnamed states entry/ … exit/ … do/ event (params) [guard] / action (params) actions event (params)

C-S 5466 State diagram - semantics there must be exactly one initial state and one or more final states a transition between states is represented by the event that triggers the transition (a more concrete definition given later) transitions may have guards or conditions under which the transitions fire the actions associated with a transition will be executed as soon as the transition fires

C-S 5467 State diagram – semantics (continued) a state may optionally have a label every state may have –an entry action – executed as soon as the state is entered –an exit action – executed just before leaving the state –a “do” action – executed while the object is in this state; may be ongoing until the object leaves the state

C-S 5468 State – a formal definition is a condition during the life of an object during which the object performs an action or waits for some event is represented by the collection of attributes and their corresponding values an object after being created must be at one particular state at any instant –unless otherwise mentioned, an object remains in a state for a finite time –UML allows modeling of transient states (states that exist only for a very short and insignificant duration)

C-S 5469 State – a formal definition (continued) (directly or indirectly) includes links (instances of associations) connected with the object at that instant may be decomposed into concurrent substates (AND relationship) may be composed using mutually exclusive disjoint substates (OR relationship)

C-S Event – a formal definition a noteworthy occurrence –UML manual something that happens within the system or interacting with the system at an instant something that has a significant impact on the system examples –sending a signal or data –receiving a signal or data –making a request for execution –a Boolean condition becoming true –a timeout condition becoming true –…–…

C-S Four types of events in UML signal event –occurs when an object sends a signal to another object call event –occurs when a method or operation in an object is invoked change event –occurs when a Boolean condition is changed time event –occurs when a time limit has reached

C-S Representation of events events are represented by unique labels in the diagram sometimes the transitions that are fired by the occurrence of the event is also represented by the same label change event labels are preceded by the keyword “when” time event labels are preceded by the keyword “after”

C-S Generating an Event an event is generated by the runtime system –asking for inputs –producing outputs –execution of a method –transfer control of execution from one object to another (sending messages or receiving messages) –abnormal termination –error handling, exceptions

C-S Temporal properties of Events an event is considered to be instantaneous –occurrence of an event causes negligible time –this time is not included in the modeling events may have precedence relationships among them –“opening an account” precedes “depositing into account” –“graduation” occurs only after “finishing all requirements” and “clearing pending dues”

C-S Transition represents the change of states of an object –switch from “Joined University” to “Registered for Fall” is an abstraction of an operation –registering for a course has finite and significant duration –time taken to complete registration of one course

C-S Transition (continued) may have parameters – a transition corresponding to the registration process may have “course name” and “prerequisites” as parameters. is triggered/invoked/fired by the occurrence of an event –change of semester from “Summer” to “Fall” may initiate the registration process –request by administration or department may initiate the registration process

C-S Transition (continued) may have a guard/condition –transition for registration may require that the student must have his/her ID validated –transition for graduation may require previous library dues to be paid off –transition to admit new students may require that the students can register only after officially admitted into the program an event may cause several transitions to fire –completion of registration process may cause the course object to update its enrolment and at the same time, the account object to update the tuition fees to be paid

C-S Transition (continued) is normally identified by the same label as the event that fires the transition –“register”, “withdraw”, … may be associated with an action –different from actions associated with the states –“register” may have an action to check the validity of parameters, to check that no previous registration has been done for the same set of parameters etc.

C-S Example 1 – State of a “Student” Student name : String id : Integer courses : set of CourseID Class definition : Student name = “John” id = courses = {CS546, CS742} The state of a student object : Student name = “John” id = courses = {CS546, CS742, CS551} Another state of the student object

C-S Example 1 – simplified representation Student courses : set of CourseID : Student courses = {CS546,CS742} : Student courses = {CS546, CS742, CS551} Indicate only those attributes that define change of state

C-S Example 1 – state diagram for Student class Initial continuing completed register[#courses < minRequired] / updateCourses() register [#courses >= minRequired] / updateCourses() graduated entry/ initializeCourses()

C-S Example 1 - Exercise The given state diagram for the student class is incomplete. Complete the diagram to include all the transitions and also include transitions that correspond to withdrawing from a course

C-S Example 2 – State diagram for Account class in ATM initial Normal Overdraft deposit / deposit() withdraw [amt = balance] / withdraw() deposit/ deposit() withdrawNormal [amt < balance] / withdraw() withdrawInitial / withdraw() open/ open() close/ close() closeAC [amt=-balance] / deposit() depositOP [amt=-balance]/ deposit() depositOP [amt < - balance] / deposit() withdrawOP / withdraw()

C-S Example 2 - Exercise Complete the state diagram for the Account class in ATM, by including any missing transitions. The diagram assumes that there is no limit on overdraft protection. Make changes to the diagram assuming that there is an overdraft limit of $N.

C-S Communications between objects Objects communicate by sending messages to each other. A message is realized as an event/transition in a state diagram. The object that sends the message is said to generate an event. –Modeled by the action associated with the transition The object that receives the message is said to realize / accept that event.

C-S Example – A user object in ATM Deposit / deposit_User() Withdraw / withdraw_User () Using Machine

C-S Documentation State: Using Machine –This is the only state for this object and hence no need to enumerate the variables by which this state is defined Transitions –Event : Deposit Parameters : amount Conditions : None Action: deposit_User (amount) Events generated: deposit OR depositOP Communicating objects : Account –Event : Withdraw Parameters : amount Conditions : None Action: withdraw_User (amount) Events generated : withdraw OR withdrawOP OR withdrawInitial or withdrawNormal Communicating objects : Account

C-S Documentation – alternate style State: Using Machine –This is the only state for this object and hence no need to enumerate the variables by which this state is defined Transitions –Deposit (amount) / deposit_User (amount); Account.deposit (amount) OR Account.depositOP (amount) –Withdraw (amount) / withdraw_User (amount); Account.withdraw (amount) OR Account.withdrawOP (amount) Account.withdrawNormal (amount) Account.withdrawInitial (amount)

C-S Simple and composite states A state is composite, in contrast to a simple state, if it has a graphical decomposition –UML Manual version 1.5 A diagram for a composite state has two or more sub-diagrams connected by simple and/or concurrent transitions –Example: concurrent states The word “superstate” is used sometimes to refer to a composite state

C-S Composite State – basic syntax Simple State

C-S Composite State – Transparent Transitions Simple State

C-S Composite State - Example CD drawer closed CD drawer open No CD Loaded CD loaded CD playing CD paused CD stopped Power ON [no CD] Power ON [CD in] Power OFF Eject Eject [no CD] Eject Eject [CD in] Pause Pause or Play Stop Play Stop

C-S Observations The state diagram for the CD player example indicates a composite state that includes two MUTUALLY EXCLUSIVE states –The player will be in only one of these two substates at any time, but not in both at the same time The guard condition on the initial state chooses the appropriate substate upon Power ON There is only one terminal state that is common to both the substates

C-S Abstract view of the CD player No CD loaded CD loaded Power OFF Power ON [no CD] Power ON [CD in] Eject [CD in] Eject

C-S Composite State with Concurrent Transitions Composite State Concurrent transition

C-S Concurrent States - example Incomplete passed failed Lab 1Lab 2 Project Final exam Lab done Project done pass fail Student attending a course

C-S Observations If a composite state has concurrent substates, –an entry point to the composite state represents a concurrent transition, even if it is not represented –an exit point from the composite state represents a concurrent transition, even if it is not represented –all concurrent substates start at the same time –the composite state terminates only when all the concurrent substates terminate

C-S Observations (continued) –if there is a transition from any one of the substates that lead to a state outside the composite state, then all the other concurrent substates terminate prematurely the transition “fail” in the third substate illustrates this situation

C-S Composite State - Exercise Draw a composite state diagram for the following problem: –Show the state of 3 phones when all of them are in use in a conference call Hint: First identify the various values for the status of a phone

C-S State diagrams and specialization Inheritance mechanism allows to redefine only behaviors of a superclass and not the structure of the superclass  The structure of a subclass must be the same or a superset of the structure of the superclass  Every state of a superclass object is also a valid state of the subclass object  The state diagram of a superclass can be inherited into the state diagram of a subclass