1 State Modeling  Events  States  Transitions and Conditions  State Diagrams  State Diagram Behavior  Practical Tips.

Slides:



Advertisements
Similar presentations
Concepts & Notations. Acknowledgements  The material in this tutorial is based in part on: Concurrency: State Models & Java Programming, by Jeff Magee.
Advertisements

ESE Einführung in Software Engineering 7. Modeling Behaviour Prof. O. Nierstrasz.
Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent.
State Diagrams A state diagram is a graph whose nodes are states and whose directed arcs are transitions between states. A state diagram specifies the.
State Transition Diagrams
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.
FUNCTIONS AND MODELS Chapter 1. Preparation for calculus :  The basic ideas concerning functions  Their graphs  Ways of transforming and combining.
More on Dynamic Models - Page L14-1 Full 2002M.E. Fayad Lesson 14: More about Dynamic Models Object- Oriented Modeling & Applications.
1 © Wolfgang Pelz UML2 UML Part Two. 2 © Wolfgang Pelz UML2 Chapters Four & Twelve Interaction Diagrams.
© 2005 Prentice Hall4-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
THE OBJECT-ORIENTED DESIGN WORKFLOW Statechart Diagrams.
SE-565 Software System Requirements More UML Diagrams.
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
Unified Modeling Language(UML) BY
State and Sequence Diagrams Modelling dynamic information So far we have seen: Use Case Diagrams – requirements capture, interface.
Computer Science 1000 Spreadsheets II Permission to redistribute these slides is strictly prohibited without permission.
INFO 620Lecture #51 Information Systems Analysis and Design Sequence and Collaboration Diagrams INFO 620 Glenn Booker.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 8: Modelling Interactions and Behaviour.
State Diagrams / System Sequence Diagrams (SSDs)
מידול התנהגותי 1. Today’s Session Sequence Diagrams State Machines 2.
1 Object-Oriented Modeling Using UML (2) CS 3331 Fall 2009.
NJIT Modeling Behavior in State Chart Diagrams Chapter 29 Rafael Mello.
E. Kraemer CSE 335: Software Design Software Architecture and Larger System Design Issues Lecture 5: Finite state modeling and analysis Topics: –Using.
Fall 2010 CS4310 Requirements Engineering UML: Dynamic Modeling Dr. Guoqiang Hu Department of Computer Science UTEP 1.
State Modeling.
1 Software Engineering Dr. K. T. Tsang Lecture 8 State modeling
CS3320::CH111 OBJECT-ORIENTED ANALYSIS Chapter 11.
CSE 251 Dr. Charles B. Owen Programming in C1 States and State Machines.
 2000 Deitel & Associates, Inc. All rights reserved. Optional Case Study - Chapter 3 Outline 3.1 Introduction 3.2 Class Attributes 3.3 Statechart Diagrams.
Object-Oriented Modeling Using UML CS 3331 Section 2.3 of Jia 2003.
1 Modeling interactions and behavior Lecturer Dr. Mai Fadel.
Session 22 Modeling the Extended Features of the Statechart Written by Thomas A. Pender Published by Wiley Publishing, Inc. October 27, 2011 Presented.
9-1 © Prentice Hall, 2007 Chapter 9: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
Course Instructor: Kashif Ihsan 1. Chapter # 3 2.
Information System Design IT60105
SWT - Diagrammatics Lecture 4/4 - Diagramming in OO Software Development - partB 4-May-2000.
CSCI-383 Object-Oriented Programming & Design Lecture 12.
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.
STATE MODELING | Website for Students | VTU - Notes - Question Papers | RESULTS | NEWS.
CS212: Object Oriented Analysis and Design Lecture 34: UML Activity and Collaboration diagram.
State Modeling. Events An event is an occurrence at a point in time, such as user depresses left button or.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 UML State Diagrams.
Dynamic Models Sequence Diagrams Collaboration Diagrams Activity Diagrams.
CS3773 Software Engineering Lecture 06 UML State Machines.
Interaction Diagram An interaction diagram is a graphical representation of interactions between objects. Sequence diagram: shows the sequence in which.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 26. Review UML behavioral Diagrams – Sequence diagram.
7-1 © Prentice Hall, 2007 Topic 7: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
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.
Dynamic Models - Page L M.E. Fayad Lesson 30: Dynamic Models Object- Oriented Modeling & Application s.
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.
Communication Diagrams Lecture 8. Introduction  Interaction Diagrams are used to model system dynamics  How do objects change state?  How do objects.
1 Kyung Hee University Interaction Diagrams Spring 2001.
Module 2 OOMD.
State Modeling. Introduction A state model describes the sequences of operations that occur in response to external stimuli. As opposed to what the operations.
1 Object Oriented Analysis System modeling = Functional modeling + Object modeling + Dynamic modeling Functional modeling = Use cases Object modeling =class.
Visual Basic.NET Windows Programming
Systems Analysis and Design in a Changing World, Fourth Edition
Analysis Classes Unit 5.
State Machine Model.
Marlon Dumas Institute of Computer Science
Chapter 11: Collaboration Diagram - PART1
Activity and State Transition Diagram
Object Oriented Modeling and Design
Chapter 5 state Modeling
Marlon Dumas Institute of Computer Science
UML State Diagrams (Ch. 29)
Presentation transcript:

1 State Modeling  Events  States  Transitions and Conditions  State Diagrams  State Diagram Behavior  Practical Tips

2 Events  Event: occurrence at a point in time, such as user depresses left button.  Events often correspond to verbs in the past tense or the onset of some condition, and represent points in time.  One event may logically precede or follow another, or the two events may be unrelated.  Two events that are causally unrelated are said to be concurrent; they have no effect on each other.  If the communication delay between two locations exceeds the difference in event times, then the events must be concurrent because they can’t influence each other.  In modeling a system we do not try to establish an ordering between concurrent events because they can occur in any order.  Events include error conditions as well as normal occurrences. For example, motor jammed, transactions aborted and timeout are typical error events.

3 Signal Event  A signal is an explicit one-way transmission of information from one object to another. It is different from a subroutine call that returns a value. An object sending a signal to another object may expect a reply, but the reply is a separate signal under the control of the second object, which may or may not choose to send it.  Signal event is the event of sending or receiving a signal.  The difference between signal and signal event, a signal is a message between objects while a signal event is an occurrence in time.  Every signal transmission is a unique occurrence, but they are grouped into signal classes and give each signal class a name to indicate common structure and behavior.  The UML notation is the keyword signal in («») above the signal class name in the top section of a box. The second section lists the signal attributes.

4 «signal» FlightDeparture Airline flightNumber City date «signal» MouseButtonPushed Button location «signal» StringEntered text «signal» ReceiverLifted «signal» DigitDialed digit Signal classes and attributes

5 Change Event  A change event is an event that is cause by the satisfaction of a boolean expression. The intent of a change event is that the expression is continually tested. Whenever the expression changes from false to true, the events happens.  The UML notation for a change event is the keyword when followed by a parenthesized boolean expression. The next figure shows several examples of change events.  when (room temperature < heating set point)  when (room temperature > cooling set point)  when (battery power < lower limit)  when (tire pressure < minimum pressure)

6 Time Event  A time event is an event cause by the occurrence of an absolute time or the elapse of a time interval.  The UML notation for an absolute time is the keyword when followed by a parenthesized expression involving time. The notation for a time interval is the keyword after followed by a parenthesized expression that evaluates to a time duration. The next figure shows an example of time events.  when (date=January 1, 2000)  after (10 seconds)

7 States  State: abstraction of values/links of an object, and represent intervals of time  Sets of values and links are grouped together into a state according to the gross behavior of objects.  States often correspond to verbs with a suffix of “ing” or the duration of some condition  The next figure shows the UML notation for a state- a rounded box containing an optional state name. SolventInsolventWaitingDialingPowered

8 State (cont.)  In defining states, we ignore attributes that do not affect the behavior of the object,  The purpose of modeling is to focus on qualities that are relevant to the solution of an application problem and abstract away those that are irrelevant.  The three UML models (class, state, and interaction) presents different views of a system for which the particular choice of attributes and values are not equally important.  The objects in a class have a finite number of possible states-one or possibly some larger number. Each object can only be in one state at a time.

9 State (cont.) Events vs. state  There is a certain symmetry between events and states as the next figure illustrates.  Events represent points in time; states represent intervals of time.  A state corresponds to the interval between two events received by an object.  The state of an object depends on past events, which in most cases are eventually hidden by subsequent events. For example, events that happened before the phone is hung up do not affect future behavior; the Idle state forgets events received prior to the receipt of the hang up signal. time power turned on power turned off power turned on Powered Not powered

10 Various Characterizations of a state State: AlarmRinging Description: alarm on watch is ringing to indicate target time Event sequence that produces the state: setAlarm (targetTime) any sequence not including clearAlarm When (currentTime = targetTime) Condition that characterizes the state: alarm= on, alarm set to targetTime, targetTime≤ currentTime ≤ targetTime + 20 seconds, and no buttons has been pushed since targetTime Events accepted in the state: event response next state when (currentTime = targetTime + 20) resetAlarm normal buttonPushed (any button) resetAlarm normal

11 Transitions and Conditions  A transitions is an instantaneous change from one state to another.  The transition is said to fire upon the change from the source state to the target state.  The origin and target of a transition usually are different states, but may be the same.  A transition fires when its event occurs  The choice of next state depends on both the original state and the event received.  An object may cause multiple objects to transition; from a conceptual point of view such transitions occur concurrently.  A guard condition is a boolean expression that must be true in order for a transition to occur.  A guard transition fires when its event occurs, but only if the guard condition is true.  For example, when you go out in the morning (event), if the temperature is below freezing (condition), then put on your gloves (next state)  A guard condition is checked only once, at the time the event occurs, and the transition fires if the condition is true.

12 Guarded transitions  The UML notation for a transition is a line from the origin state to the target state  An arrowhead points to the target state. The line may consist of several line segments.  An event may label the transition and be followed by an optional guard condition in square brackets.

13 North /south May go straight North/ south May turn left East/ west May turn left East/ west May go straight timeout[ cars in N/S left lanes] timeout timeout [care in E/W left lanes] timeout Timeout [no cars in E/ W left lanes] Timeout [no cars in N /S left lanes]