INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker.

Slides:



Advertisements
Similar presentations
®® Microsoft Windows 7 for Power Users Tutorial 7 Enhancing Your Computers Security.
Advertisements

Requirements Diagrams With UML Models
Behavioral Modeling: State Diagrams CIS 4800 Kannan Mohan Department of CIS Zicklin School of Business, Baruch College Copyright © 2009 John Wiley & Sons,
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.
ESE Einführung in Software Engineering 7. Modeling Behaviour Prof. O. Nierstrasz.
Object-Oriented Analysis and Design
Objectives Detailed Object-Oriented Requirements Definitions
Guide to Oracle10G1 Introduction To Forms Builder Chapter 5.
Embedded Systems Details. Object Model: Four main system objects or classes Controller object might be made up of several controllers is the brains of.
A Guide to Oracle9i1 Introduction To Forms Builder Chapter 5.
THE OBJECT-ORIENTED DESIGN WORKFLOW Statechart Diagrams.
7. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Detailed Object-Oriented Requirements Definitions  System Processes—A Use.
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Modeling.
Detailed Object-Oriented Requirements Definitions
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.
SE-565 Software System Requirements More UML Diagrams.
Systems Analysis I Data Flow Diagrams
Sequence Diagram Tutorial
INFO 620Lecture #51 Information Systems Analysis and Design Sequence and Collaboration Diagrams INFO 620 Glenn Booker.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
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.
State Diagrams / System Sequence Diagrams (SSDs)
Chapter 7 Structuring System Process Requirements
מידול התנהגותי 1. Today’s Session Sequence Diagrams State Machines 2.
1 Object-Oriented Modeling Using UML (2) CS 3331 Fall 2009.
Objectives Detailed Object-Oriented Requirements Definitions
The Object-Oriented Approach to Requirements
4 2009/10 Object Oriented Technology 1 Topic 4: The Object-Oriented Approach to Requirements Adopted from: Ch.7 The Object-Oriented Approach to Requirements.
Systems Analysis and Design in a Changing World, Fifth Edition
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
Systems Analysis and Design in a Changing World, 6th Edition
Guide to State Transition Diagram. 2 Contents  What is state transition diagram?  When is state transition diagram used?  What are state transition.
Use Cases 7/09. lnot part of the system lrepresents roles a user can play lrepresents a human, a machine or another system lactively exchanges information.
1 Modeling interactions and behavior Lecturer Dr. Mai Fadel.
7 Systems Analysis and Design in a Changing World, Fifth Edition.
A Use Case Primer 1. The Benefits of Use Cases  Compared to traditional methods, use cases are easy to write and to read.  Use cases force the developers.
1 Structuring Systems Requirements Use Case Description and Diagrams.
Copyright © 2013 Curt Hill UML Unified Modeling Language.
Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements.
Use Case Driven Analysis Requirements Use Case Use Case Description System Sequence Diagram Chapter 5.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Use cases.
1 Kyung Hee University Statecharts Spring Kyung Hee University Specifying Objects’ Behaviour  Interaction diagrams show message-passing behaviour.
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 5 INTRODUCTION TO SYSTEMS ANALYSIS AND DESIGN: AN AGILE, ITERATIVE APPROACH CHAPTER.
7. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Detailed Object-Oriented Requirements Definitions  System Processes—A Use.
Systems Analysis and Design in a Changing World, Fourth Edition
States.
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.
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.
Chapter 3: Introducing the UML
Modeling Object Lifecycles and State-Dependent Behavior ©SoftMoore ConsultingSlide 1.
Use Case Model Use case description.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th Edition Copyright © 2015 John Wiley & Sons, Inc. All rights.
1 7 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 7 The Object-Oriented Approach to Requirements.
George Wang, Ph.D. COMP 380/L Lesson 2. Use Case Use cases are a way to capture system functionalities (i.e., functional requirements) Based on use case.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Systems Analysis and Design in a Changing World, Fourth Edition
Business Process and Functional Modeling
Systems Analysis and Design in a Changing World, 6th Edition
State Machine Diagram.
State Machine Diagrams
State Machine Diagrams
States.
Systems Analysis and Design in a Changing World, 6th Edition
Object Oriented Analysis and Design
BPMN - Business Process Modeling Notations
Use Case Model Use case diagram – Part 2.
States.
Presentation transcript:

INFO 355Week #81 Systems Analysis II Extending the requirements models INFO 355 Glenn Booker

Requirements?  This is to refine our initial development of system requirements New uses for the activity diagram State diagram INFO 355Week #82

Use Case descriptions  Recall that we defined ‘casual’ and ‘detailed’ use case documentation  The text has ‘brief’ and ‘fully developed’ use case descriptions Example of the latter on p. 123 Text’s ‘flow of activities’ is the main success scenario ‘Exception conditions’ are alternate scenarios or extensions INFO 355Week #83

Use Case descriptions  The text also adds Related use cases Stakeholders Preconditions Postconditions  Recall that Aleister Cockburn has many more characteristics that can be added to use case documentation INFO 355Week #84

Activity diagrams for use cases  We saw the activity diagram in week 1  It can also be used to document use cases, where the swimlanes (or partitions) are the primary actor and the System (and possibly lanes for external systems) INFO 355Week #85

System Sequence Diagram  As noted earlier in the course, we aren’t using the SSD  It is a high level sequence diagram which shows no details inside the :System object  The Loop, Alt, and Opt boxes are called ‘frames’ in the text INFO 355Week #86

INFO 355Week #77 State Machine Diagram  The “state diagram” is also known as Statechart diagram (Visio) State Machine diagram State Transition diagram  These all refer to the same thing

INFO 355Week #78 State Diagrams  A state diagram is used to capture the details of a use case which involves some sort of processing where the system can change state  A state refers to a mode of operation or setting which will affect how the system responds to inputs

INFO 355Week #79 State Diagrams  State diagrams are good for describing a single object’s behavior throughout several use cases If you have several objects interacting, an interaction diagram is better  Real-time systems use state diagrams extensively

INFO 355Week #710 Examples of State-based Systems  A telephone operates in two main states, “on hook” and “off hook” Within the latter, there are many possible states, such as making a local call, making a long distance call, making an international call, making a 3-way call, etc. The commands entered (via dialing) control which state the phone is in

INFO 355Week #711 Examples of State-based Systems  A cruise control has basic states of on or off While on, it could be in states of maintaining speed, accelerating, resuming previous speed, etc. Various buttons control changes between states

INFO 355Week #712 Examples of State-based Systems  Even Microsoft Word is somewhat state-based If I type a letter, normally it would appear where the cursor is on a document But if I press the Alt key first, for example, the interpretation of the next keystroke is quite different  Alt-f display the File menu  The Esc key sends it back to normal state

INFO 355Week #713 State Diagrams  So we want to use a state diagram if the interpretation of user actions depends on the history of previous actions Often a state corresponds to the status or condition of an object  Events occur which can change the state of an object through a transition

INFO 355Week #714 State Diagrams  The state diagram only has four main elements The starting point, shown by a big dot The ending point, a big dot inside a circle States, shown by boxes Transitions between states, shown by lines with arrows between the boxes  A transition goes from an “origin state” to a “destination state”

INFO 355Week #715 Figure 10.1 The Safe Example Starting point Ending point A state A transition Elements for state diagrams appear on the Activity Diagram shape menu in Visio

INFO 355Week #716 The Safe Example  The labels on each line indicate an Event (trigger name), and if that occurs, the Action (action- expression) and state change occur Event [Guard] / Action is the syntax The Event is optional for each transition (the state change might happen automatically, which is rare) The Guard and Action are also optional

INFO 355Week #717 The Safe Example  The syntax Event [Guard] / Action is Visio’s terminology  The text uses trigger-name[guard-condition] / action-expression for the same thing

Visio sample transition INFO 355Week #818

INFO 355Week #719 The Safe Example  If no Action is specified, then just the state change occurs when that Event takes place (as is the case for “safe closed” between Open and Wait states) “When the safe is closed (the Event), change to the Wait state”

INFO 355Week #720 The Safe Example  An Event can have conditional statements, called a Guard, such as the [door closed] condition  So the transition from Wait to Lock means: “If the door is closed, and someone removes the candle, then reveal the lock and change to the Lock state”

INFO 355Week #721 The Safe Example  If using a Guard condition, it generally makes sense to have mutually exclusive possible conditions [candle in] [candle out]  If there is no Guard condition, any given Event must have only one possible path out of a state

INFO 355Week #722 The Safe Example  From the Lock state, “If the candle is in, and the key is turned, open the safe and change to the Open state”  The alternative transition is “If the candle is out, and the key is turned, exit and release the killer rabbit”

INFO 355Week #723 Internal Activities  Sometimes events can happen in a state which results in some action, but not a change of state  These are internal activities (internal transitions in Visio)  The same Event / Action syntax is used, but these don’t have a change of state associated with them

INFO 355Week #724 Internal Activities  The meaning is the same – when Event occurs, do Action  Events of ‘entry’ or ‘exit’ occur automatically when entering or exiting that state, but do not occur when other internal activities are triggered; e.g. for a text field: Entry / highlight all Exit / update field

INFO 355Week #725 Activity States  It’s possible to have ongoing activity while in a state  This is shown by the activity state There’s an Action State in Visio, but no way to show the activity except by using the Text Tool on the state name

INFO 355Week #726 Activity States  The activity which takes place during this state is preceded by “do/” It’s assumed that the activity takes a noticeable amount of time  When the activity is successful or completed, then any transition which doesn’t have an Event is followed

Concurrent States  Some devices can have more than one state at a time, e.g. a printer can be On and Waiting This is concurrency  Can show it as an activity diagram with separate paths for multiple states, or use a composite state INFO 355Week #827

INFO 355Week #728 Concurrent States  Sometimes sets of states can be changing independently of each other, at the same time These are concurrent states  Separate concurrent states with a solid line (p. 137)  Concurrent states have no interaction with each other

Composite States  Show composite states by nesting states  For example, a printer that is On might change from Idle to Working (p. 136) INFO 355Week #829

INFO 355Week #730 History Pseudostate  We had pseudostates for the start and finish of a state diagram  Now add a History pseudostate A simple history pseudostate records the last value of some state A deep history pseudostate records many entries of history for a state

Developing state diagrams  Identify use cases that have multiple status conditions  For each class affected, list the status conditions  Identify what transitions occur between states  Connect transitions into larger scale structures as possible INFO 355Week #831

Developing state diagrams  Look for independent concurrent paths and composite paths  Look for additional transitions  Define event, guard, action for each transition  Review and test the diagram INFO 355Week #832

Integrate diagrams  The state diagram can help refine requirements for complex use cases  We now have many tools to understand our system from different points of view Use case diagram and documentation Activity and state diagrams Domain model (conceptual class diagram) INFO 355Week #833