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

Presentation on theme: "The SATM system Winter 2007. SATM SATM: Simple Automatic Teller Machine. Will work with this example during the Integration and system testing part. Build."— 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 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

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

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

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

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

Similar presentations