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

Slides:



Advertisements
Similar presentations
GCSE ICT By the end of this session, you will be able to: Explain main features of ATM machines Identify features of credit cards, debit cards, smart cards.
Advertisements

Chapter 4: Requirements Engineering
Use Case Diagrams Damian Gordon.
BIS 360 – Lecture Seven Process Modeling (Chapter 8)
ATM Security Requirements & Specification Decomposition Team B: Martijn Christiaan Vasilis Benjamin.
1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 7 – More on use cases and activity diagrams.
Introduction to Software Testing Chapter 2.6 Graph Coverage for Use Cases Paul Ammann & Jeff Offutt
Use Case Modeling SJTU. Unified Modeling Language (UML) l Standardized notation for object-oriented development l Needs to be used with an analysis and.
SWE 214 (071) Use Case Diagrams Slide 1 Use Case Diagrams Examples.
Sample Problems for Testing For “Program” Level Testing: –Triangle –Next Date –Sales Commission For “System” Level Testing: –ATM system –Currency conversion.
CPSC 333: Foundations of Software EngineeringJ. Denzinger Small Test: Bank account manager System has to run on an automated teller machine. User must.
Introduction to Software Testing Chapter 2.6 Graph Coverage for Use Cases Paul Ammann & Jeff Offutt
Requirements and Design
Lecture 8 Electronic Commerce Modelling Techniques
ATM User Interface V3. I/O Devices Input: Keyboardfor input, option select Keyboardfor input, option select Or Touch screen Or Touch screenOutput: Screenfor.
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 Classes. 2 Finding classes w Choosing classes is first step in defining essence of problem w If you can recognize an abstraction, you’ve found a candidate.
Chapter 12 ATM Case Study, Part 1: Object-Oriented Design with the UML
ATM User Interface Design. Requirements A bank customer is able to access his or her account using an automatic teller machine. To be able to use an ATM.
Elisati Hulu. Definition  “a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project.
January Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Elaboration Iteration 1: a simple cash-only success scenario of.
Chapter 9 Describing Process Specifications and Structured Decisions
CS /31 Illinois Institute of Technology CS487 Software Engineering Midterm Review David Lash.
Data Flow Diagram Notations
Events & Messages Paul Ard Ales v2.0. Generic Exceptions  HardwareFail – the device does not respond  HardwareMalfunction – some part of the device.
1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 6 - Use cases and activity diagrams Dr.
{ How to Use An ATM A simple tutorial to teach how to use ATM Machines.
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.
Use Case Modeling. Use case diagram For each use case we develop  Object class diagram (with attributes only)  System sequence diagram (analysis) 
Merijn Benjamin Christina
Chapter 14 System Testing.
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.
Faculty of Computer & Information Software Engineering Third year
SFWR ENG 3KO4 Software Development Fall 2009 Instructor: Dr. Kamran Sartipi Software Requirement Specification (SRS) for the Automated Banking Machine.
Sample Problems for Testing
SFWR ENG 3KO4 Software Development for Computer/Electrical Engineering Fall 2009 Instructor: Dr. Kamran Sartipi Software Requirement Specification (SRS)
Understanding Networked Applications: A First Course Ideas and examples (Chapter 6) by David G. Messerschmitt.
January Ron McFadyen1 January 2004 Assignment 1 Due: Friday Jan 23, Implement the ProductSpecification and Payment classes in any OO.
System Testing Beyond unit testing. 2 System Testing Of the three levels of testing, system level testing is closest to everyday experience We evaluate.
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
Introduction to Business Analytics & Business Intelligence Information Systems Functions i-Clicker Demo IS vs IT IPO Model Note Taking.
System Testing Earlier we have stated the 2 views of testing:
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.
1 LAB What is Collaboration diagram? 4 Collaboration diagrams illustrate the interaction between the objects, using static spatial structure. 4.
1 Requirements Engineering From System Goals to UML Models to Software Specifications Axel Van Lamsweerde.
UC Diagram & Scenario RKPL C & D. Using Use Case Diagram Use case diagrams are used to visualize, specify, construct, and document the (intended) behavior.
Requirements Document for the Banking System
1 Object-Oriented Static Modeling of the Banking System - III Lecture # 33.
1 Object-Oriented Static Modeling of the Banking System - II Lecture # 32.
Inf 43: Introduction to Software Engineering May 7, 2016.
1 Case Study and Use Cases for Case Study Lecture # 28.
Introduction What would our society be like now if we did not have ATm’s? Not able to access money when we urgently want it. You will have to go to the.
Paul Ammann & Jeff Offutt
Output “Funds not available”
Structured Analysis and Design Technique
ATM OO Design and Implementation Case Study
Dynamic Modeling of Banking System Case Study - I
SECURITY FEATURES OF ATM
Object-Oriented Static Modeling of the Banking System - I
Outline 1. Exercise on use case diagram
Structured Analysis and Dataflow Diagrams
How An ATM Work's Prepaid by, kakani Dinesh.
Ch. 14 System Testing (with new slides 4/18)
Chapter 14 System Testing
Paul Ammann & Jeff Offutt
Ch. 14 System Testing Earlier we have stated the 2 views of testing:
Integration Testing.
Real-Time Structured Analysis and Design Technique (RSTAD)
Presentation transcript:

The SATM system Winter 2007

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

Screens for the SATM

SATM Greatly reduced system. Commercial ones have hundreds of screens and timeouts. Sketch of the SATM terminal: –Display screen –Function buttons B1, B2 and B3. –Digit keypad with cancel key. –Slots for printer receipts and ATM cards. –Doors for deposits and cash withdrawals.

SATM terminal

Structured analysis approach The technique is based on three complementary models: –Functional model: we use dataflow diagrams –Data model: we use E/R model –Control model: finite state machine Examples: –Context diagram of the SATM –Level 1 data flow diagram of the SATM.

Context diagram of the SATM

Level 1 data flow diagram

Deft CASE tool from Sybase Inc. Elements of the functional decomposition are identified with number (1.4 for manage session). The open and filled arrows: –Open: compound flows –Filled: simple flow. Example: compound flow screen: –Screen 1 welcome –Screen 2 enter PIN –Screen 3 wrong PIN –Screen 4 PIN failed, card retained –Screen 5 select trans type –…

Entity/Relationship diagram

Incomplete E/R diagram of the major data structures in the SATM system: customers, accounts, terminals and transactions. Single and double arrowheads signify the singularity or the plurality of the relationships: –Many transactions may occur at a terminal but one transaction can never occurs at multiple terminals. –One customer may have several accounts and may conduct none or several transactions.

Finite state machine Data flow and E/R contain information that are primarily structural. For testing, we need behaviour not sturcture Control model represent the point at which structure and behaviour intersect. Finite state machines can be hierarchically decomposed.

Upper level SATM finite state machine

PIN entry finite state machine

In both figures, state transitions are caused either by events at the ATM terminal (such as a keystroke)or by data conditions (such as the recognition that a PIN is correct). When a transition occurs, a corresponding action may also occur (we use screen displays as such actions)

Functional decomposition

A partial functional decomposition. But here we miss the fact that some functions (typically lower level) are used in more than one place: –the ScreenDriver function is used by several other module but only appears once in the functional decomposition. Solution: Call Graph is a much better for integration test case identification. Here is the functional decomposition carried further in outline form (the numbering scheme preserves the levels of the components –see the decomposition tree)

1 SATM 1.1 Device Sense & control Door sense and control Get door status Control door Dispense cash Slot sense and control Watchcardslot Get deposit slot status Control Card Roller Control Envelope roller Read card strip

1.2 Central bank Comm Get PIN for PAN Get account status Post daily transactions 1.3 Terminal sense and control Screen driver Key sensor 1.4 Manage session Validate card Validate PIN Close session

New transaction request Print receipt Post transaction local Manage transaction Get transaction type Get account type Report balance Process deposit Process withdrawal

As part of the specification and design process, each functional component is normally expanded to show its inputs, outputs, and mechanism. We do this with pseudocode for the three modules. The main program description follows the finite state machine description. States in that diagram are implemented with a case statement.

Main Program State = Awaitcard Case State Case 1: Awaitcard ScreenDriver(1,null) WatchCardSlot(CardSlotStatus) Do while CardSlotStatus is Idle WatchCardSlot(CardSlotStatus) End while ControlCardRoller(accept) ValidateCard(CardOK,PAN) if CardOK then State=AwaitPIN Else ControlCardRoller(eject) Endif State=AwaitCard Case 2: AwaitPIN ValidatePIN(PINok,PAN) if PINok then ScreenDriver(2,null) State=AwaitTrans else ScreenDriver(4,null) Endif State=AwaitCard

Case 3: AwaitTrans ManageTransaction State= Closesession Case 4: Closesession if NewTransactionRequest Then State=AwaitTrans Else PrintReceipt End if PostTransactionLocal CloseSession ControlCardRoller(eject) State=AwaitCard End Case (State) End. (Main program SATM)

The validatePIN procedure is based on the finite state machine in which states refer to the number of PIN entry attempts.

Procedure ValidatePIN(PINok,PAN) GetPINforPAN(PAN, ExpectedPIN) Try=first Case try of case 1: First ScreenDriver(2,null) GetPIN(EnteredPIN) If EnteredPIN = expectedPIN then PINok=true else ScreenDriver(3,null) endif Try=second case 2: Second ScreenDriver(2,null) GetPIN(EnteredPIN) If EnteredPIN = expectedPIN then PINok=true else ScreenDriver(3,null) endif Try=third

case 3: Third ScreenDriver(2,null) GetPIN(EnteredPIN) If EnteredPIN = expectedPIN then PINok=true else ScreenDriver(4,null) PINok=false endif Try=second EndCase(try) End. (Procedure ValidatePIN)

The GetPIN procedure is based on another finite state machine in which states refer to the number of digits received; and in any state, either another digit key can be touched or the cancel key can be touched. Instead of another CASE statement implementation, the “states” are collapsed into iterations of a while-loop.

Procedure GetPIN(EnteredPIN, CancelHit) Local Data: DigitKeys ={0,1,2,3,4,5,6,7,8,9} CancelHit= False EnteredPIN= null string DigitRcvd=0 Do While not(DigitRcvd=4 or CancelHit) keySensor(keyHit) if keyHit IN DigitKeys then EnteredPIN=EnteredPIN+keyhit INCREMENT(DigitRcvd) if DigitRcvd=1 then ScreenDriver(2,’X---’) if DigitRcvd=2 then ScreenDriver(2,’XX--’) if DigitRcvd=3 then ScreenDriver(2,’XXX-’) if DigitRcvd=1 then ScreenDriver(2,’XXXX’) ElseCancelHit=true endif endwhile End (procedure GetPIN)

If we follow the pseudo code of the three modules, we can identify the uses relationship among the modules in the functional decomposition. MODULE USES Modules SATM Main WatchCardSlot ControlCardRoller Screen Driver ValidateCard Validate PIN Manage Transaction New Transaction request ValidatePINGetPINforPAN GetPIN Screen Driver GetPINkeySensor Screen Driver