OLC Arch Application: Checking Account Example

1
OLC Arch Application Checking Account Example

• This example includes three active classes (ACs)
• 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
ET01CUfirst
ET03OPpass or ET04OPfail
OPerator Class
ET03CUlast
ET08CAclose
ChkgAcct Class
ET05CAopen
ET04CAdep ET09CAwdw ET10CAchk
ET02CUestab is internal to CU class
LCP Life Cycle Prototyping
3
OPerator Responsibilities

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

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)
gtacctNogt
FindBal(acctNo)
ltbalancelt
CA ChkgAcct
Withdraw(user, acctNo,amt)
CAid CUid acctNo balance CAstate
Close(user, acct)
Function prototypes show method parameters,
replacing Shlaer-Mellors OLC wok symbols on
method call arrows.
6
Event Types (Table ET)

• 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?

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 (oidCU000000) is trapped in
state CUS0 on request it creates a new CU
instance CU00xxxx, sets its state to CUS1 and
generates ET CUestab)
ET01CUfirst (from OPerator)
1
CUS1 new
ET02CUestab (from CUS0constructor)
2
CUS2 current
ET03CUlast (From CheckingAccount)
3
CUS3 former
8
OPerator State Diagram
(Constructor State OPS0 not shown)
OPE5Done
OPS3Pass Request Succeeded...

OPE3 Pass

• OPS2DoTr DoTransaction Switch on
  RequestType Interpret Parameters
  Generate Event Instance CUE or CAE
  return

OPE5
OPS1Next Receive next Customer Request
OPE2 DoTr
OPE4 Fail
OPS4Fail Request Failed ...
OPE5 Done
i
j
9
ChkgAcct State Diagram
ET05CAopen (from OPerator)
CAS0 Acct Constructor State (CAid CA000000?)
(A new account is created as a side effect of
CAopen )
ET08CAclose (from OPerator)
CAS3 Good Standing
CAS7 Closed Account
CAS1 New Account
ET10CAchk
ET06CAok
ET09CAwdw
ET06CAok
ET04 CAdep
ET06CAok
ET04CAdep
CAS5 Considering CashingCheck
CAS2Taking Deposit
CAS4 Considering Withdrawal
ET07CAover
ET07CAover
ET04CAdep
ET09CAwdw
CAS6 Overdrawn
CAS8 Reject Request
ET10CAchk
ET07CAover
Note bold outline, l arge print gt stable
states others are transient.
10
ChkgAcct Runtime Data Model
(Revised 94/5/17 more fields)
State Model View (see other
figure)
AC ActiveClass ACid 1 / pkey / SMid 1 /
parent SM /
11
SM
11
01
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 /
0N
ET
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 /

• 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 /

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 /
11
0N
( the event label is at EIcurr-gtETid_pp-gtLabel )
( Meta-attribute cols 2 and 3 have been omitted
for brevity do NOT omit when preparing a schema
for input to chgen!))
11
OLCStateModelArch (su93olc.sch)

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
/
Active Instance
AC
11
01
Active Class
AI
cstate
Runtime Relationships
Application Objects ( Sys. Services)
(AI and ApplObjs are in 11 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/

• 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 /

Note Event Label is stored in the ET-parent of
each generated EventInstance EI (at
EI.ETid_pp-gtLabel)
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
Build Test Data Flow Diagram

• 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

ChkgAcctOLC.sch
chgen -ansi -nobp
ChkgAcctOLC.h
pr_.c utilities
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
Thread Processing Example
(Two OPerators access the same account OP2's
Withdrawal try precedes OP1's Deposit)
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
ET02OP2DoTr
ET09CAwdw

OPS2 Process Request
ET02OP2DoTr
ET12OP4fail
CAS4 Considering Withdrawal
ET06CAok
CAS3 Good Standing
ET04CAdep

OPS2 Process Request
OPS4 Request Failed
ET11OP3Pass
ET13OP5done
CAS2 Taking Deposit
ET06CAok
OPS3 Request Succeeded
ET13OP5Done
OPS1 Get Next Request
CAS3 Good Standing
OPS1 Get Next Request
15
Thread Processing Problem
What happens when OP1's deposit precedes OP2's
Withdrawal?
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
Thread Processing Solution
(For the case where the deposit precedes the
Withdrawal)
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
ET02OP2DoTr
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