1 / 29

The SATM system

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.

audrey-hoffman
Download Presentation

The SATM system

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The SATM system Winter 2007

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

  3. Screens for the SATM

  4. 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.

  5. SATM terminal

  6. 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.

  7. Context diagram of the SATM

  8. Level 1 data flow diagram

  9. 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 • …

  10. Entity/Relationship diagram

  11. 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.

  12. 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.

  13. Upper level SATM finite state machine

  14. PIN entry finite state machine

  15. 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)

  16. Functional decomposition

  17. 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)

  18. 1 SATM 1.1 Device Sense & control 1.1.1 Door sense and control 1.1.1.1 Get door status 1.1.1.2 Control door 1.1.1.3 Dispense cash 1.1.2 Slot sense and control 1.1.2.1 Watchcardslot 1.1.2.2 Get deposit slot status 1.1.2.3 Control Card Roller 1.1.2.4 Control Envelope roller 1.1.2.5 Read card strip

  19. 1.2 Central bank Comm 1.2.1 Get PIN for PAN 1.2.2 Get account status 1.2.3 Post daily transactions 1.3 Terminal sense and control 1.3.1 Screen driver 1.3.2 Key sensor 1.4 Manage session 1.4.1 Validate card 1.4.2 Validate PIN 1.4.3 Close session

  20. 1.4.3.1 New transaction request 1.4.3.2 Print receipt 1.4.3.3 Post transaction local 1.4.4 Manage transaction 1.4.4.1 Get transaction type 1.4.4.2 Get account type 1.4.4.3 Report balance 1.4.4.4 Process deposit 1.4.4.5 Process withdrawal

  21. 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.

  22. 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

  23. 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)

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

  25. 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

  26. 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)

  27. 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.

  28. 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’) Else CancelHit=true endif endwhile End (procedure GetPIN)

  29. If we follow the pseudo code of the three modules, we can identify the uses relationship among the modules in the functional decomposition. • MODULEUSES Modules SATM Main WatchCardSlot ControlCardRoller Screen Driver ValidateCard Validate PIN Manage Transaction New Transaction request ValidatePIN GetPINforPAN GetPIN Screen Driver GetPIN keySensor Screen Driver

More Related