1 ATM Machine STATE ::= await_card | await_pin | await_2 nd _attempt | eject_card | await_amount | dispense_money EVENT ::= insert_card | enter_good_pin.

Slides:

Advertisements

Similar presentations

ATM SCAM At first glance it would appear as though this individual is simply performing a simple ATM transaction.

Advertisements

Use Case Diagrams Damian Gordon.

Use Case & Use Case Diagram

ATM Security Requirements & Specification Decomposition Team B: Martijn Christiaan Vasilis Benjamin.

The SATM system Winter SATM SATM: Simple Automatic Teller Machine. Will work with this example during the Integration and system testing part. Build.

Project management Project manager must;

USE CASE – ATM EXAMPLE Actors: ATM Customer ATM Operator Use Cases: The customer can withdraw funds from a checking or savings account query the balance.

SWE 214 (071) Use Case Diagrams Slide 1 Use Case Diagrams Examples.

SD3049 Formal Methods Module Leader Dr Aaron Kans Module website

Introduction to Software Testing Chapter 2.6 Graph Coverage for Use Cases Paul Ammann & Jeff Offutt

Lecture 8 Electronic Commerce Modelling Techniques

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.

ATM User Interface V3. I/O Devices Input: Keyboardfor input, option select Keyboardfor input, option select Or Touch screen Or Touch screenOutput: Screenfor.

Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor Formal Methods in Software Engineering1.

Sequence Diagrams. Introduction A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of methods in each object, and.

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.

Interaction Diagrams Activity Diagram State Machine Diagram

3/20/20091 More State Machines. Multiple processes.

1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 10 Requirements 4.

Object Interaction Models - Review The use case and its scenarios serve as a vehicle for organizing the object interactions that take place. Each scenario.

School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification

Aspect-Oriented Software Development (AOSD) Tutorial #9 Modular Verification of Aspects.

Aspect-Oriented Software Development (AOSD) Tutorial #9 Modular Verification of Aspects.

Events & Messages Paul Ard Ales v2.0. Generic Exceptions  HardwareFail – the device does not respond  HardwareMalfunction – some part of the device.

Electronic ATM Fraud. ATM Fraud is where you goto an ATM and you insert your card into a skimmer which is placed in the card slot and it will take all.

{ How to Use An ATM A simple tutorial to teach how to use ATM Machines.

INTERACTION DIAGRAMS Example Kingdom of Saudi Arabia Ministry of Higher Education Princess Noura bint Abdulrahman University College of Computer & Information.

Use Case Modeling. Use case diagram For each use case we develop  Object class diagram (with attributes only)  System sequence diagram (analysis) 

Dynamic Black-Box Testing Part 2

Use Cases 2 ENGR ♯10 Peter Andreae

Chapter 8: Modelling Interactions and Behaviour UML Activity Diagram

1 Statecharts by David Harel, 1987 State machines ⊆ statecharts A state machine consists of  Named states  Transitions between states  Events as labels.

WS-RM State Table December 15, Protocols as State Machines Protocols define the interaction of two or more finite state machines (FSM) Stable Protocols.

1 Object-Oriented Analysis Use Case Driven. 2 The outline method for OOA 1.Identify object classes within the problem domain 2.Define the behaviour of.

Use Case Diagram: Exercise 5 and 6 Yong Choi BPA CSUB.

Faculty of Computer & Information Software Engineering Third year

What state are we in?. What are the two main parts of a computer program? – Data – Algorithms We have previously emphasized – how real-world information.

Black Box Testing Techniques Chapter 7. Black Box Testing Techniques Prepared by: Kris C. Calpotura, CoE, MSME, MIT  Introduction Introduction  Equivalence.

Behavioral Modeling: Sequence and Communication Diagrams Copyright © 2009 John Wiley & Sons, Inc. Copyright © 2005 Pearson Education Copyright © 2009 Kannan.

Requirements Engineering Methods for Requirements Engineering Lecture-30.

Information Systems Engineering Interaction Diagrams: Sequence Diagram Collbortion Diagram.

Finite State Machines. What is "abstraction"? Abstraction unifies multiple and different objects into one concept  describes the common properties of.

Decision table testing

1 Kyung Hee University Statecharts Spring Kyung Hee University Specifying Objects’ Behaviour  Interaction diagrams show message-passing behaviour.

Basics of Computation Theory. What is "abstraction"? Abstraction unifies multiple and different objects into one concept  describes the common properties.

1 Graph Coverage (6). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section

Übungen zur Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS : Modellbasierter.

ATM Adv. SW Engineering

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.

System Testing Earlier we have stated the 2 views of testing:

© 2009 Pearson Education, Upper Saddle River, NJ All Rights ReservedFloyd, Digital Fundamentals, 10 th ed Digital Logic Design Dr. Oliver Faust.

Learning Intentions Explain what an ATM is and the facilities offered Identify the stages of withdrawing cash from an ATM List the advantages and disadvantages.

RTM (Robotic Teller Machine) By Jonathan Daudelin Construction Time : February – June 2006 Parts used : 2 RCX’s, 4 Motors, 4 Sensors, Hundreds of Legos.

Lecture Outline Monday 23 rd February (Week 4) 3 – 3:10pm Review of Requirements Eng. and use cases 3:10 – 3:40pm Exercise on Use Case 3:40-4:40 Class.

UC Diagram & Scenario RKPL C & D. Using Use Case Diagram Use case diagrams are used to visualize, specify, construct, and document the (intended) behavior.

1 Case Study and Use Cases for Case Study Lecture # 28.

From requirements to specification Specification is a refinement of requirements Can be included together as Software Requirements Specifications (SRS)

ATM SCAM At first glance it would appear as though this individual is simply performing a simple ATM transaction.

Dynamic Modeling of Banking System Case Study - I

Object-Oriented Static Modeling of the Banking System - I

Outline 1. Exercise on use case diagram

Chapter 8: Modelling Interactions and Behaviour UML Activity Diagram

ATM SCAM At first glance it would appear as though this individual is simply performing a simple ATM transaction.

Chapter 14 System Testing

Using Use Case Diagrams

Level 1 Module 2 Lesson 5 AXS Machines.

Real-Time Structured Analysis and Design Technique (RSTAD)

Test Design Techniques Software Testing: IN3240 / IN4240

Presentation transcript:

1 ATM Machine STATE ::= await_card | await_pin | await_2 nd _attempt | eject_card | await_amount | dispense_money EVENT ::= insert_card | enter_good_pin | enter_bad_pin | cancel | enter_amount | done FSM == (STATE X EVENT) ⇸ STATE no_change, control, transitions: FSM no_change = {s: STATE; e: EVENT (s, e) → s } control = no_change transitions Transitions = { (await_card, insert_card) → await_pin, (await_pin, enter_good_pin) → await_amount, (await_pin, enter_bad_pin) → await_2 nd _attempt, (await_pin, cancel) → await_card, (await_2 nd _attempt, enter_good_pin) → await_amount, (await_2 nd _attempt, enter_bad_pin) → eject_card, (eject_card, done) → await_card, (await_amount, cancel) → await_card, (await_amount, enter_amount) → dispense_money, (dispense_money, done) → await_card }

2 ATM – State diagram 1.Await card

3 ATM – State diagram 1.Await card 2. Await pin card

4 ATM – State diagram 1.Await card 3.Await 2 nd pin 2. Await pin card bad pin

5 ATM – State diagram 1.Await card 3.Await 2 nd pin 5.Await amount 2. Await pin card good pin bad pin

6 ATM – State diagram 1.Await card 4. Eject card 3.Await 2 nd pin 5.Await amount 2. Await pin card good pin bad pin

7 ATM – State diagram 1.Await card 4. Eject card 3.Await 2 nd pin 5.Await amount 2. Await pin done card good pin bad pin

8 ATM – State diagram 1.Await card 4. Eject card 3.Await 2 nd pin 6. Dispense money 5.Await amount 2. Await pin done card good pin bad pin good pin amount

9 ATM – State diagram 1.Await card 4. Eject card 3.Await 2 nd pin 6. Dispense money 5.Await amount 2. Await pin done card good pin bad pin good pin amount

10 ATM – State diagram 1.Await card 4. Eject card 3.Await 2 nd pin 6. Dispense money 5.Await amount 2. Await pin done card good pin bad pin good pin amount cancel

11 ATM – State diagram 1.Await card 4. Eject card 3.Await 2 nd pin 6. Dispense money 5.Await amount 2. Await pin done card good pin bad pin good pin amount cancel

12 ATM – State diagram 1.Await card 4. Eject card 3.Await 2 nd pin 6. Dispense money 5.Await amount 2. Await pin done card good pin bad pin good pin amount cancel

13 Insert card Enter good pin Enter bad pin cancelEnter amount Done 1. Await card 2. Await pin 3. Await 2 nd attempt 4. Eject card 5. Await amount 6. Dispense money State transition table

14 Insert card Enter good pin Enter bad pin cancelEnter amount Done 1. Await card 2 2. Await pin 3. Await 2 nd attempt 4. Eject card 5. Await amount 6. Dispense money State transition table

15 Insert card Enter good pin Enter bad pin cancelEnter amount Done 1. Await card 2 2. Await pin 5 3. Await 2 nd attempt 5 4. Eject card 5. Await amount 6. Dispense money State transition table

16 Insert card Enter good pin Enter bad pin cancelEnter amount Done 1. Await card 2 2. Await pin Await 2 nd attempt Eject card 5. Await amount 6. Dispense money State transition table

17 Insert card Enter good pin Enter bad pin cancelEnter amount Done 1. Await card 2 2. Await pin Await 2 nd attempt Eject card 5. Await amount 1 6. Dispense money State transition table

18 Insert card Enter good pin Enter bad pin cancelEnter amount Done 1. Await card 2 2. Await pin Await 2 nd attempt Eject card 5. Await amount Dispense money State transition table

19 Insert card Enter good pin Enter bad pin cancelEnter amount Done 1. Await card 2 2. Await pin Await 2 nd attempt Eject card 1 5. Await amount Dispense money 1 State transition table

20 ATM Machine STATE ::= await_card | await_pin | await_2 nd _attempt | eject_card | await_amount | dispense_money

21 ATM Machine STATE ::= await_card | await_pin | await_2 nd _attempt | eject_card | await_amount | dispense_money EVENT ::= insert_card | enter_good_pin | enter_bad_pin | cancel | enter_amount | done

22 ATM Machine STATE ::= await_card | await_pin | await_2 nd _attempt | eject_card | await_amount | dispense_money EVENT ::= insert_card | enter_good_pin | enter_bad_pin | cancel | enter_amount | done FSM == (STATE X EVENT) ⇸ STATE

23 ATM Machine STATE ::= await_card | await_pin | await_2 nd _attempt | eject_card | await_amount | dispense_money EVENT ::= insert_card | enter_good_pin | enter_bad_pin | cancel | enter_amount | done FSM == (STATE X EVENT) ⇸ STATE no_change, control, transitions: FSM

24 ATM Machine STATE ::= await_card | await_pin | await_2 nd _attempt | eject_card | await_amount | dispense_money EVENT ::= insert_card | enter_good_pin | enter_bad_pin | cancel | enter_amount | done FSM == (STATE X EVENT) ⇸ STATE no_change, control, transitions: FSM no_change = {s: STATE; e: EVENT (s, e) → s }

25 ATM Machine STATE ::= await_card | await_pin | await_2 nd _attempt | eject_card | await_amount | dispense_money EVENT ::= insert_card | enter_good_pin | enter_bad_pin | cancel | enter_amount | done FSM == (STATE X EVENT) ⇸ STATE no_change, control, transitions: FSM no_change = {s: STATE; e: EVENT (s, e) → s } control = no_change transitions

26 ATM Machine STATE ::= await_card | await_pin | await_2 nd _attempt | eject_card | await_amount | dispense_money EVENT ::= insert_card | enter_good_pin | enter_bad_pin | cancel | enter_amount | done FSM == (STATE X EVENT) ⇸ STATE no_change, control, transitions: FSM no_change = {s: STATE; e: EVENT (s, e) → s } control = no_change transitions transitions = { (await_card, insert_card) → await_pin, (await_pin, enter_good_pin) → await_amount, (await_pin, enter_bad_pin) → await_2 nd _attempt, (await_pin, cancel) → await_card,. …}

27 Last word for the formal methods 1.Not widely used in industry 2.Formal specifications can be examined mathematically 3.Informal specifications cannot be 4.A correct program can be shown to meet its specifications 5.Two specifications can be shown to be equivalent 6.Certain forms of incompleteness or inconsistencies can be detected automatically 7.Removes ambiguity 8.Encourages greater care in early stages 9.Focus is mainly on function and data aspects 10.A problem is that the timing, control, behavioural aspects are difficult to represent 11.Also, the methods are often difficult to learn