OLC Arch Application: Checking Account Example

1. OLC Arch Application: Checking Account Example • This example includes three active classes (AC’s) • OPerator • CUstomer • CheckingAccount • and illustrates six OOAD/OLC diagram types: • Object Communication Diagram (among OP, CU,CA) • Class Specification Diagrams (CU and CA) • State Transition Diagrams (OP, CU and CA) • Data Structure Diagram (SM and Runtime Objects) • Data Flow Diagram (build and test process) • Event Trace/Object Interaction Diagram (Two OPs) References: [1] Shlaer & Mellor: Object-Oriented System Analysis: Modeling the World in Data, Appendix D, Prentice-Hall 1988? [2] Shlaer & Mellor: Object Life Cycles: Modeling the World in States,Prentice-Hall 1992?

2. Object Communication Diagram (OCD) An OCD shows event communication paths among Active Classes, which have instances and State Models in the LCP Architecture* Customer Class** ET01:CUfirst ET03:OPpass or ET04:OPfail OPerator Class ET03:CUlast ET08:CAclose ChkgAcct Class ET05:CAopen ET04:CAdep ET09:CAwdw ET10:CAchk **ET02:CUestab is internal to CU class * LCP = Life Cycle Prototyping

3. Functions: Accept customer requests to: Open an account or close an account; Deposit funds into an account; Transfer funds from one account to another Withdraw cash from the account iff balance permits. Honor checks on an account unless already overdrawn. Send events to CUstomer or ChkgAcct State Machines to accomplish legitimate transactions. Inform customer when CUstomer or ChkgAcct State Machines deny the requested transaction. Manually accept or disburse funds when permitted. Keep a log of all transactions, with OPid and date- time stamp. OPerator Responsibilities

4. CUstomer Class Diagram Shows data and operation (method) components CUSTOMER CLASS Create CUstomer(username, userdata) CU CUstomer * LastAcct() CUid CUstate ** username userdata Significance of left/right/internal placement of components: Left-side: Methods which have a server object-id argument; Right-side: Methods which do not have an input oid argument; Internal: Private (hidden) data and/or method components.

5. ChkgAcct Class Diagram CHKG ACCT CLASS Open(user, amt)* Deposit( acct, amt)* >acctNo> FindBal(acctNo) <balance< CA ChkgAcct Withdraw(user, acctNo,amt)* CAid CUid acctNo balance CAstate Close(user, acct)* * Function prototypes show method parameters, replacing Shlaer-Mellor’s OLC ‘wok’ symbols on method call arrows.

6. ETid EvLabel Source Dest ETint1,2 ETflt1,2 ETstr1 ET01 CUfirst OPerator CUstomer n/a n/a username ET02 CUestab CUstomer CUstomer n/a n/a n/a ET03 CUlast ChkgAcct CUstomer n/a n/a username ET04 CAdep OPerator ChkgAcct n/a amt acctNo ET05 CAopen OPerator ChkgAcct n/a amt username ET06 CAok ChkgAcct ChkgAcct n/a n/a n/a ET07 CAover ChkgAcct ChkgAcct n/a n/a n/a ET08 CAclose OPerator ChkgAcct n/a n/a acctNo ET09 CAwdw OPerator CUstomer n/a amt acctNo ET10 CAchk OPerator CUstomer n/a amt acctNo ET11 OPpass CU or CA OPerator n/a n/a errMsg? ET12 OPfail CU or CA OPerator n/a n/a errMsg? Event Types (Table ET)

7. CUstomer State Diagram (revised 94/4/26: Added CUS0 as one way to model the class instance constructor as a generic 1-state SM. CUS0: Constructor (this ‘default constructor’’ CU (oid=CU000000) is ‘trapped’ in state CUS0; on request it creates a new CU instance CU00xxxx, sets its state to CUS1 and generates ET = CUestab) ET01:CUfirst (from OPerator) 1 CUS1: new ET02:CUestab (from CUS0:constructor) 2 CUS2: current ET03:CUlast (From CheckingAccount) 3 CUS3: former

8. OPS2:DoTr DoTransaction: {Switch on RequestType: {Interpret Parameters; Generate Event Instance CUE or CAE } return;} OPerator State Diagram (Constructor State OPS0 not shown) OPE5:Done OPS3:Pass Request Succeeded:... OPE3: Pass OPE5 OPS1:Next Receive next Customer Request OPE2: DoTr OPE4: Fail OPS4:Fail Request Failed: ... OPE5: Done i j

9. ChkgAcct State Diagram ET05:CAopen (from OPerator) CAS0: Acct Constructor State (CAid = CA000000?) (A new account is created as a side effect of CAopen ) ET08:CAclose (from OPerator) CAS3: Good Standing CAS7: Closed Account CAS1: New Account ET10:CAchk ET06:CAok ET09:CAwdw ET06:CAok ET04: CAdep ET06:CAok ET04:CAdep CAS5: Considering CashingCheck CAS2:Taking Deposit CAS4: Considering Withdrawal ET07:CAover ET07:CAover ET04:CAdep CAS6: Overdrawn ET09:CAwdw CAS8: Reject Request ET10:CAchk ET07:CAover Note: bold outline, l arge print => stable states; others are transient.

10. EI EventInstance * EIid 1 /* pkey of EI */ AIid1 1 /* 'from' this AI */ AIid2 1 /* 'to' this AI */ ETid 1 /* EType w/ label */ int1 0 /* int, arg1 */ int2 0 /* int, arg2 */ flt1 0 /* float, arg3 */ flt2 0 /* float, arg 4 */ string 0 /* string, arg5 */ State Model View: (see other figure) (Revised 94/5/17: more fields) ChkgAcct: Runtime Data Model AC ActiveClass ACid 1 /* pkey */ SMid 1 /* parent SM */ 1:1 SM 1:1 0:1 ST AI ActiveInstance AIid 1 /* pkey of this instance */ ACid 1 /* fkey to AC and SM */ State 0 /* For SM of this Instance */ Name 0 /* Optional ApplicObj id */ ET 0:N TR EN Application + Service Objects: OP OPerator OPid 1 /* pkey */AIid s /* fkey */ user 0 /* customer */ acnt 0 /* accnt . no. */ amt 0 /* amt of trans*/ trtype 0 /* trans. type */ CA ChkgAcct CAid 1 /* pkey */ AIid s /* SuperClass */CUid 1 /* Owner id */ bal 0 /* Accnt balance*/ CU CUstomer CUid 1 /* pkey */ AIid s /* SuperClass */ user 0 /* customer id */ 1:1 0:N *( the event label is at EIcurr->ETid_pp->Label ) ( Meta-attribute cols 2 and 3 have been omitted for brevity; do NOT omit when preparing a schema for input to chgen!))

11. ST State /*Behavior of this state */ STid NA c8 1 /* pkey of this ST instance */ SMid NA c8 1 /* fkey of parent State Model */ ActName NA c8 0 /* Action Routine Name/Service */ ActFunc NA c8 0 /* Address of Routine to be called */ Name NA t80 0 /* Full Name or Description of ST */ Active Instance SM StateModel /* Model for all AI's of AC of SM */ SMid NA c8 1 /* pkey of this SM instance */ Abbrev NA c4 0 /* short name - e.g. SM01 */ Name NA t80 0 /* Full Name or Description of SM */ OLCStateModelArch (su93olc.sch) AC 1:1 0:1 Active Class AI cstate Runtime Relationships Application Objects (& Sys. Services) (AI and ApplObjs are in 1:1 corresp. ET EventType /*EventType table*/ ETid NA c8 1 /* pkey */ SMid NA c8 1 /* Receiving SM */ Label NA c32 0 /* Event label */ Descrip NA t80 0 /*describes ET*/ Note: Event Label is stored in the ET-parent of each generated EventInstance EI (at EI.ETid_pp->Label) EI TR Transition /* Transition: STid1 to STid2 */ TRid NA c8 1 /* pkey of this TR instance */ STid1 NA c8 1 /* Source or 'From' State */ STid2 NA c8 1 /* Destination or 'To' STate */ Event Instance EN EventEnable /* ET__TR relation */ ENid NA c8 1 /* pkey of ENable row */ ETid NA c8 1 /* fkey of enabling ET */ TRid NA c8 1 /* fkey of enabled TR */ (revised 94/4/26: added Note)

12. ChkgAcct Deliverables (for a spring 1995 project) 1. SM.dat file (content of SM, ST, TR, ET, EN) , and/or ST/TR/EV Array declarations for OLCArch 2. ActionRoutine*.c (for each ST of OP, CU, CA) 3. Script file printout and calculated results 4. Transaction log and pr_dump from test run Build &Test Data Flow Diagram ChkgAcctOLC.sch chgen -ansi -nobp pr_*.c utilities ChkgAcctOLC.h ChkgAcct.c ViewDefs.vdf gcc -DDEBUG gcc Script pr_*.o ChkgAcct.o ld(link) ChkgAcct.exe ChkgAcct.exe Logs and Tables

13. Operator Class Evolution? • The generic OPerator subclass of AC might be split into two parts: a user-interface (UI subclass) and a simulator interface (SI subclass), with a single event stream between them. • Rationale: • UI and SI might be generalized independently of each other. • The interface between UI and SI might be abstracted in terms of generic events that define UI and SI transition pairs. • This might achieve an application-independent or generic SI and an application-dependent UI. • The user and script file inputs might be serializable at the UI -SI interface into a single event instance stream or external event queue. • The history of events crossing the UI-SI interface might become a reproducible record for regression testing independently of the GUI type.

14. (Two OPerators access the same account; OP2's Withdrawal try precedes OP1's Deposit) Thread Processing Example First Operator OP1: CA of Mr/Mrs Jones: Second Operator OP2: (OP1 lags behind OP2) OPS1: Get Next Request CAS3: Good Standing OPS1: Get Next Request ET02:OP2DoTr ET09:CAwdw OPS2: Process Request ET02:OP2DoTr ET12:OP4fail CAS4: Considering Withdrawal ET06:CAok CAS3: Good Standing ET04:CAdep OPS2: Process Request OPS4: Request Failed ET11:OP3Pass ET13:OP5done CAS2: Taking Deposit ET06:CAok OPS3: Request Succeeded ET13:OP5Done OPS1: Get Next Request CAS3: Good Standing OPS1: Get Next Request

15. What happens when OP1's deposit precedes OP2's Withdrawal? Thread Processing Problem First Operator OP1: CA of Mr/Mrs Jones: Second Operator OP2: (Request is Deposit) (Request is Withdrawal) OPS1: Get Next Request CAS3: Good Standing OPS1: Get Next Request OPS1: Get Next Requestx CAS3: Good Standing OPS1: Get Next Request

16. (For the case where the deposit precedes the Withdrawal) Thread Processing Solution First Operator OP1: CA of Mr/Mrs Jones: Second Operator OP2: (Request is Deposit) (Request is Withdrawal) OPS1: Get Next Request CAS3: Good Standing OPS1: Get Next Request ET02:OP2DoTr CAdep OPE2 OPS2: Process Request CAS2: Taking Deposit OPE3 CAok CAS3: Good Standing OPS2: Process Request OPS3: Request Succeeded CAwdw OPE5 OPE3 CAS4: Considering Withdrawal CAok OPS3: Request Succeeded OPE5 OPS1: Get Next Request CAS3: Good Standing OPS1: Get Next Request