200

Information Systems Management, 25: 200–210Copyright © Taylor & Francis Group, LLCISSN: 1058-0530 print/1934-8703 onlineDOI: 10.1080/10580530802151103UISM

The READY Model: Patterns of Dynamic Behaviorin REA-Based Accounting Applications

The READY Model Dinesh Batra and Thant SinFlorida International University, College of Business Administration, Miami, FL

Abstract The Resource-Event-Agent (REA) model has gained considerable attention in accounting lit-erature. While REA denotes a data model, which represents only the static aspect of a system, the dynamicaspect has now been introduced as the scenario concept in a recently proposed REA ontology. Using theUnified Modeling Language (UML) sequence diagram—a popular method of showing interactions amongobjects—and building on the REA framework and the scenario notion, the paper presents the READYmodel to illustrate patterns of dynamic behavior in accounting scenarios.

Keywords Resource-Event-Agent model, Unified Modeling Language (UML), and analysispatterns

The last four decades have yielded significant develop-ments in the field of Information Systems (IS) in generaland Accounting Information Systems (AIS) in particular.Some of these developments have caused a significantshift in the way we conceptualize and represent business,information systems, and accounting phenomena. Twokey developments in the area of business, and informa-tion systems data modeling are the introduction of therelational model (Codd, 1970) for representing andmanipulating business data, and the entity relationship(ER) model (Chen, 1976) for conceptualizing data thatcan be implemented using the relational model.

In this domain, accounting researchers have made akey contribution. The Resource-Event-Agent (REA) model(McCarthy, 1979, 1982) is not only an innovative way ofstudying AIS, it also provides fresh lenses with which toview and understand business systems. The REA model isbased on a frequently occurring pattern of transactions(economic events) wherein agents inside and people out-side of an enterprise (economic agents) exchange thingsof value (economic resources). McCarthy (2003) reviewshow the REA model was assimilated into and included inthe AIS pedagogy as a useful framework for understand-ing. However, one can make an argument that the REAapproach, which essentially links business events with ISanalysis and design, can even be employed in core MIS

courses such as database applications, and systems analy-sis and design to enhance their usability.

The REA model has gained considerable attention inaccounting literature. In 2007, a symposium was dedi-cated specifically to celebrating 25 years of REA. Severaltextbooks in AIS (e.g., Murthy & Groomer, 2003) haveemployed the REA approach as a foundation for teachingaccounting topics. The REA approach is not only an intui-tive way to render AIS concepts, it can also encapsulatethe double-entry bookkeeping approach and hide itsunappealing and, at times, myopic features. There is,indeed, empirical support (Dunn & Grabski, 2000) thatthe REA approach leads to higher task accuracy and isperceived as more expressive when compared to the dou-ble-entry approach. Accounting software packages alsoseem easier to understand when one takes the REAapproach. Whether it is a smaller package like Quick-Books (Ivens, 2008) or a large enterprise package like SAP,whose reference models are exemplified by Scheer(1998), it seems that the REA approach is well suited tothe understanding of accounting processes and models.The REA model is also found to enhance user comprehen-sion of conceptual models (Poels, 2003).

However, the REA approach denotes only a datamodel, which is the static aspect of a system. What isnot included is how the data is processed. For example,a sale not only represents data, it includes both how thesale actually takes place and the key activities involved.Ostensibly, the dynamic piece—how the data isprocessed—is missing from the REA model. To fill thisvoid, this paper proposes READY (DYnamic REA), an

Address correspondence to Dinesh Batra, Florida InternationalUniversity, College of Business Administration, 11200 SW 8th Street,Miami, FL 33199, USA. E-mail: Dinesh.Batra@business.fiu.edu

The READY Model 201

extension of the REA model that incorporates dynamicmodeling. Given that the REA framework itself is a pat-tern, READY employs a similar analysis patternsapproach to reveal the typical interaction scenarios inaccounting applications.

The motivation for our paper stems from the initialwork by Murthy and Wiggins (2004) who proposedObject-Oriented REA (OOREA) to extend the REA frame-work beyond the confines of data modeling. Theyadopted an object-oriented approach, but did not employa standard object-oriented language like the UML toshow interactions among accounting objects. For exam-ple, OOREA lacks the means to show actors (e.g., custom-ers, vendors, and other agents), forms through which theinteraction takes place (e.g., order form), and the control-ler objects that embed various business rules and enforcedouble entry bookkeeping. We employ the UML sequencediagram, the most popular method of showing interac-tions among objects, to propose an REA-based approachfor modeling dynamic behavior of AIS. Our coverage ismore detailed and comprehensive than OOREA, and isbased on the extended REA ontology reported in Geertsand McCarthy (2002). The use of UML makes the dia-grams amenable for implementation.

The REA Ontology

Geerts and McCarthy (2000) contend that the REA modelprovides an ontology of enterprise information systemsin general, and accounting information systems in par-ticular. They have extended the original REA model(McCarthy, 1982) to build the ontological foundation forrepresenting an AIS (Geerts & McCarthy, 2000, 2002).Figure 1 provides a summary of the REA ontology. Not allof the elements may be relevant in a given system. Keyelements are briefly described below.

■ Resource: something of value. For example, a prod-uct or a service is a resource.

■ Event: an economic transaction. For example, invoic-ing is an event that involves the sale of products orservices.

■ Agent: an economic representative such as a cus-tomer or an employee.

■ Commitment: an obligation with a certain degree ofenforceability. For example, an order is a commit-ment; it subsequently results in events such as ship-ments and corresponding invoices.

■ Duality: the condition resulting from one eventrequiring a complementary event (the dual) to com-plete a transaction. For example, an invoice leads toone or more collections.

■ Linkage: a relationship between a product (or service)and its components such as the bill of materials.This relationship may not be required in an eventscenario.

■ Reciprocal: a complementary relationship whereinone commitment leads to another commitment. Forexample, an order will eventually lead to a purchase.

■ Association: a relationship between one agent andanother, usually between an external and aninternal agent. For example, a salesperson may beassigned to a customer. This relationship may notbe required in an event scenario.

■ Reserved: a commitment to provide a list of prod-ucts or services, usually modeled as line items fora commitment.

■ Stock-Flow: the list of products or services in a trans-action, usually modeled as line items for an event.

■ Executes: the materialization of a commitment intoan event. For example, an order leads to shipments/invoices.

The relationships accountability and involvement areboth self-explanatory and implicit in a transaction. Therelationship custody is not a required element for anevent scenario, but may be relevant in some housekeep-ing situations. For example, a laptop computer may bechecked out to an employee for use during travel.

In addition to these elements, the extended REA ontol-ogy also introduces the notion of scenarios, which areabstract representations that describe an enterprise’sstrategies or its policies on activities involved in businessprocesses. In object-oriented systems analysis terminol-ogy, this is usually described in a use case, one of themost important UML artifacts.

The REA ontology is expressed as a data model. How-ever, its elements are not merely static. An event, forinstance, also represents the activities required to com-plete the transaction. In other words, an event alsodenotes a scenario. This is better understood by taking anexample from the REA ontology.Figure 1. Components of the REA ontology.

Association

Resource Event

AgentCommitment

Custody

Linkage Duality

Reciprocal

Stock-Flow

Involvement

AccountabilityReserved

Executes

202 Batra and Sin

In Figure 2, the REA ontology is instantiated into anorder commitment scenario. A sales order placed by acustomer and taken by a salesperson may consist of oneor more products, which are recorded in sales order lineitems. Then the order is filled and products are shippedout to complete the sales order, and the customer isinvoiced for the shipment. Each invoice will have a list ofproducts included in invoice line items. Since an order isrealized in several shipments, one order may lead to oneor more invoices. The product may need to be assembledor manufactured from standalone components or rawmaterials resulting in a bill of materials relationship.

However, a sales order and a sales invoice also repre-sent scenarios. A sales order scenario may involve staticelements such as the SalesOrder, Customer/Employee,Involvement, Product, and SalesOrderLineItem. Simi-larly, the sales invoice scenario will involve a number ofelements. Key scenarios, in general, are likely to involveboth event and commitment elements.

The interactions among these elements are not cap-tured in the REA ontology, which is expressed at anabstract level. It would be useful to reveal the nature ofthe scenarios especially if there are underlying patterns,that is, if we can find interaction configurations thattend to repeat so that learning an interaction in oneaccounting scenario can help one understand an interac-tion in another scenario.

In Figure 3, we depict an example, adapted from thetextbook by Murthy and Groomer (2003), showing thekey data modeling aspects of the revenue side of anenterprise. The dark or shaded side of the relationshiprepresents the ‘many’ cardinality, while the clear siderepresents the ‘one’ cardinality. The static modeldepicted using the ER model is, otherwise, self-explana-tory and resembles the REA model in Figure 2. However,the model does not depict the dynamic aspects. In otherwords, the scenarios that describe how the static ele-ments interact are not reflected in the data model. The

ER model is not geared to representing the interactions,although some researchers use the class diagram anddraw arrows to show the messages among the objects.The most popular method of representing interactions isthe UML sequence diagram (Dobing & Parsons, 2006).

On UML, Sequence Diagrams, and Analysis Patterns

Typical scenarios in accounting can be determined byexamining the revenue cycle, conversion cycle, andexpenditure or acquisition cycle, following the businessprocess and enterprise value chain frameworks (McCarthy,2003). In IS development, a scenario is shown by a usecase, which is one of the most popular UML artifacts. Ause case shows behavior or functionality under variousconditions as the system responds to requests from users(George, Batra, Valacich, & Hoffer, 2007). However, a usecase only lists the activities that occur in a scenario, itdoes not show how objects actually interact to carry outthe activities of the scenario; this job is done by anotherUML artifact called the sequence diagram. The use caseand its sequence diagram together show high- and low-level behavior and interaction involved in a businessprocess.

UML is the standard object modeling language spon-sored by an open consortium of companies, called theObject Management Group (OMG) (Kobryn, 1999; OMG,2005). It has been widely used by software developers inobject-oriented (OO) software development projects andadopted in many information systems (IS), informationtechnology (IT), and computer science (CS) curriculaaround the world (Batra & Satzinger, 2006). In a recentstudy, the class diagram, the use case diagram, and thesequence diagram were found to be those most com-monly used by practitioners (Dobing & Parsons, 2008).

Figure 2. Instantiation of the REA ontology.

Association

Product/Material SalesInvoice

Customer/EmployeeSalesOrder

Custody

BillOfMaterial Collection

Purchase

SalesInvoiceLineItem

Involvement

AccountabilitySalesOrderLineItem Executes

Figure 3. Data model for revenue business process(adapted from Murthy and Groomer, 2003).

Customer

Salesperson Sales Order

Shipment

Collection Cashier

Shipper

WH Clerk

Inventory

Cash

The READY Model 203

The use case diagram is often developed in requirementsor use case modeling, while the class and the sequencediagrams are modeled in static and dynamic modeling,respectively (Bolloju & Leung, 2006).

A sequence diagram captures behavior in a scenarioby showing the interactions among objects. It is the link-age between the functional requirements captured inwritten use cases and the analysis classes depicted inclass diagram (Ambler, 2004; George et al., 2007). Theoperations of object classes are identified from responsi-bilities modeled in sequence diagrams, whereasattributes are derived from domain data models.

Requirements of an IS are defined and organized intoanalysis models by systems analysts. This is often consid-ered one of the most critical systems development activi-ties because the quality of analysis models oftendetermines the quality of the resulting IS (Bolloju &Leung, 2006). Analysis patterns are designed to facilitatethe analysis modeling by enabling the reuse of templatesolutions that have proven to be useful in relevant con-texts. By using template solutions for typical problems,analysis patterns help define software requirements. ISresearchers have introduced a number of analysis pat-terns (Batra, 2005; Coad, 1992; Coad, North, & Mayfield,1997; Fowler, 1997; Hay, 2006; Scheer, 1998). In AIS,McCarthy (1982) introduced the Resource-Event-Agent(REA) model that can be employed in building enterprisedata models for an AIS by following the prescribed pat-tern of economic transactions.

According to Kodaganallur and Shim’s (2006) taxon-omy of analysis patterns, the REA model is classified asan abstract building block that can be specialized andassembled into conceptual models. The REA model’sability to provide an abstract conceptualization of abusiness enterprise based on a pattern of an economicevent is invaluable in prescribing typical structures andrelationships found in an accounting application(Geerts & McCarthy, 2000). An enterprise data model isdeveloped by replacing these structural building blockswith domain-specific items such as product, order, andcustomer.

The REA model is suitable for developing enterpriseinformation architecture, which specifies the staticstructure of an AIS; however, it is not suitable for specify-ing processes that manipulate the data. IS researchershave taken steps to extend the REA model beyond thestructural modeling to the dynamic or behavioral model-ing, as in Murthy and Wiggins’s (2004) object-orientedREA (OOREA) model. One problem with existing solu-tions such as the OOREA model however, is the sparsecoverage of accounting scenarios. Another problem is theuse of an ad hoc-style notation, which can create abarrier to widespread adoption. Therefore, there is aneed for analysis patterns that can facilitate dynamicmodeling using the well-established UML conventions.

The Generic READY Pattern

In this paper, we develop and present an importantextension of the REA model, an extension designed fordynamic modeling, which has been termed READY(DYnamic REA). The READY model provides a pattern thatcan be used to model commitments and transactions inUML sequence diagrams. Standard UML notations areused in the READY model. We first provide the genericrepresentation of the READY model, which is laterinstantiated into key scenarios of the revenue, expendi-ture, and conversion cycles of a business enterprise.

The REA model has a generic representation depictinga data model among the resource, event, and agentobjects. In the same spirit, an abstract READY model,which includes key interactions in a transaction scenario,is presented in Figure 4. Key elements of the diagram are:

■ the actor who initiates the scenario (the actor isusually one of the economic agents);

■ the interface object, usually a form, through whichthe actor interacts with the system;

■ the control object, which controls the messageexchanges including the posting of entries to theaccounts and which embeds the logic of businesspolicies (e.g., tax or discount calculation), or out-sources this logic to the transaction object or otherobjects; and

■ the entity objects for resource, event/commitment,and agent, as well as for line item if a transactioncontains more than one resource.

Each transaction follows a predictable pattern of mes-sages. The actor interacts with the interface, and the inter-face communicates with the control object, which acts asa director managing the exchange of messages and data.The scenario generally starts with a search for informationfor a resource or an agent. Required information mayneed to be obtained from one or more entity objects. Onceinformation is displayed via the interface object, the actormay request that a transaction object be created. Thetransaction object may be required to manage the cre-ation or update of data in the line item object. Generally,more than one line item will be added. Once line items areadded, the detailed information of the transaction, includ-ing line item details and all related information (e.g., fees,discounts, taxes, etc.) can be assembled to allow the actorto review the transaction. In the final step, the transactionis confirmed and committed to by posting any updates torelevant objects. This process is usually performed by thecontrol or the transaction object and concluded with aconfirmation of the completed transaction. Overall, theprocess usually follows a pattern that follows thissequence: search, select, create transaction, add line items,review transaction, and confirm transaction.

204 Batra and Sin

READY Scenarios for Revenue Cycle

The static model of the revenue cycle is shown in Figure 3.The starting point in the revenue cycle is the sales order,which is a commitment to provide the customer with anumber of products or services. This commitment canthen be realized in one or more shipments/invoices. Theissuance of an invoice increases the receivables. A dualprocess—collection—results in both a reduction of receiv-ables and an increase in cash. Products may need to bemanufactured from raw materials converted into work-in-process, using resources such as machine operationsand workers, in the conversion cycle.

The READY Model of Commitment: Sales Order

The sequence diagram shown in Figure 5 provides anexample of a high-level interaction view of the salesorder process. We assume that the customer initiates thecommitment (e.g., in a web- or phone-based purchase),although an employee (e.g., sales representative) may ini-tiate the commitment on behalf of the customer. Thefirst activity is a search for and perusal of products.When the customer is ready to purchase, the sales orderobject is created. Messages here do not explicitly indicatewhat data is being input. For example, for the commit-ment, a sales order number will be generated, and the

Figure 4. The generic READY model.

:EventForm

//create transaction()

:Actor :EventControl :AgentObject :EventObject :LineItemObject :ResourceObject

//create transaction() //create transaction()

//create lineitem()

//review transaction() //review

transaction() //get transaction details()

//get lineitem info()

//get resource info()

//calc fees, charges, ordiscounts()//calc tax()//calc total()

//display transactiondetails()//confirm

transaction() //confirm transaction() //save transaction()

//display confirmation()

//search()//search()

//get info()

//displayinfo()

//save lineitem()

//get agent info()

//add lineitem()

//add lineitem()

The READY Model 205

sales date will be recorded. Line items are then added forproducts selected by the customer.

When line items have been added and the order iscomplete, the customer is ready to review the order. Inaddition to sales order and line items, information suchas taxes, fees, shipping charges, discounts, and estimatedshipping date will also be displayed. The determinationof these figures can involve tedious logic. The sales orderobject may be responsible for calculating the figures, orthe control object may ask an entity object such as salesorder and discount tables (not shown in the figure) toprovide the figures. Although order and line item detailsare saved into respective database entities, the confirma-tion of the order will not lead to the update of inventoryor receivable. When the sales order is confirmed, thechanges are committed to the respected entity objects,

and the customer is sent a copy of the sales order. Thesales order transaction has the search, create transaction,create line items, review, and commit activities.

The READY Model of Event: Sales Invoice/Shipment

The sales order, therefore, does not usually result in amonetary exchange, although in simple situations, suchas retail stores that charge the customer when the itemsare checked out, there is an immediate monetaryexchange since there is no difference between an orderand an invoice. In general, however, a sales order leads toshipments of products, which then results in invoices.Since backordering is usually allowed, one sales ordercan result in multiple sales invoices. The customer is gen-

Figure 5. Sequence diagram for sales order scenario.

:SalesOrderForm

//add item()

:Customer :SalesOrderControl :Customer :SalesOrder :SalesOrderItem :Product

//add item()//create order()

//create lineitem()

//review order() //review

order() //get order info()

//get lineitem()

//get product info()

//calcdiscount()//calc tax()//calc total()

//displayorderdetails()//confirm

order() //confirmorder() //save order

info()

//display orderconfirmation()

//browse catalog() //browse

catalog() //get product info()

//display product list()

//save lineitem()

//display confirmation()

//get customer info()

206 Batra and Sin

erally not invoiced until a shipment is made, so invoiceand shipment are similar events. Figure 6 shows thesequence diagram for the invoice/shipment scenario.

The invoice/shipment process starts with the searchfor an open order to be filled. The order information isobtained so that ordered line items can be viewed. Thenan invoice is opened by creating the invoice object. Lineitems are filled, and the quantity on hand for products isadjusted. When the invoice is completed, it can bereviewed by obtaining the data from the invoice, lineitem, and product objects. At this stage, additional

information such as a discount, taxes, and shipmentcharges are calculated based on information in the salesorder and according to company policies. The commit-ment to the transaction updates various entity objects.Specifically, the customer balance is updated to reflectan increase in receivables.

The quantities in the invoice line item may not matchthose in the order line item because of the shortage ofinventory. This will invoke backordering, which has notbeen included in this sequence diagram. The backorder-ing process can be considered a separate revenue sce-

Figure 6. Sequence diagram for invoice scenario.

:InvForm

//select order()

:WHClerk :InvControl :Customer :Invoice :InvoiceItem :SalesOrder

//select order() //get order

info() //get lineitem

info()//create invoice() //create

invoice() //create new invoice()

//calc discount()//calc tax()//calc total()//display

invoice details()

//search order() //search

order()

//get open orders()//display

open orders()

//display order details()

//get customer

info()

:SalesOrderItem :Product

//fill invoice() //fill

invoice() //fill invoice()

//create lineitem()

//review invoice() //review

invoice() //get invoice details()

//get line item() //get product info()

//update balance()

//confirm invoice() //confirm

invoice() //save invoice()

//save lineitem()

//get customer

info()

//update inventory()

//save invoice info()

//adjust inventory()

The READY Model 207

nario. The backordering scenario is straightforward sincethe quantity backordered is a calculated entry.

The READY Model of Duality: Collections

Payments received from a customer are collections, whichdecrease the amount of accounts receivables for the cus-tomer and increase cash amounts for the company. Thecollection process is the dual of the sales invoice, whichincreases the accounts receivables and decreases theinventory. In general, a collection can be applied to one ormore invoices. Conversely, an invoice can be settled usingone or more collections. In a sense, the line item concept

can be extended to the collection scenario to record howmuch of a given collection is apportioned to a giveninvoice. Queries and programs can ensure that a collec-tion is applied to the oldest invoices first. The companymay have other collection policies such as incentives forpaying early in the form of discounts, and disincentivesfor paying late in the form of penalties. Beyond that, thecollection scenario is routine. Using the customer identifi-cation, open invoices can be listed chronologically, andthe customer payment applied to one or more invoices.Then, the collection transaction is reviewed and con-firmed. The sequence diagram in Figure 7 illustrates thecollection scenario, which has the search, create transac-tion, update line items, review, and commit activities.

Figure 7. Sequence diagram for collection scenario.

:CollectForm:BillingClerk :CollectControl :Customer :Collection :CollectionItem :Invoice

//create collection() //create

collection() //create new collection()

//calc discount()//calc charges()//calc total()

//display collection details()

//search customer() //search

customer()

//get invoice info()//display

invoices()

//get customer

info()

:Cash

//enter collection() //enter

collection() //enter collection()

//create lineitem()

//review collection() //review

collection() //get collection details()

//get lineitem()

//inform customer()

//update balance()

//confirm collection() //confirm

collection() //save collection()

//save lineitem()

//get customer

info()

:Customer

//update status()

//increase cash()

208 Batra and Sin

The collections scenario can become quite simple inthe case of a cash sale because the exchange of products/services and payment occurs simultaneously. In fact, aseparate scenario is not required because the collectionoperations can be included in the invoice since there isno waiting period as in the case of account receivables.

READY Scenarios for Conversion Cycle

For a business enterprise that manufactures or assemblesthe products it sells, the conversion of raw materials orcomponents into finished products usually involveswork-in-process inventory. A finished good may be assem-bled from components, or manufactured from raw mate-rials, using machine operations and/or workers. Thelabor input eventually leads to payments in the forms ofwages and salaries. A product can alternatively be pur-chased and then resold, as is the case with several retailproducts, in which case, the expenditure cycle addressesthe procurement of the goods.

The READY Model of Work-in-Process Inventory

When a finished good is assembled or manufactured,two main costs need to be tracked. The costs of compo-nents or raw materials are the material cost. The costsincurred because of the operations to be completedresult in employee wages. Each company may have itsown algorithm for estimating and measuring these costs.

Product specifications need to be retrieved to deter-mine raw material, labor, and machine time require-ments of a product. Availability and information ofdifferent types of machine operations and classes oflabors are also recorded in separate objects. A detailedschedule of machine time and workers may be added ifrequired. Figure 8 shows the sequence diagram for theproduction or conversion scenario.

READY Scenarios for Expenditure Cycle

The expenditure cycle is almost a mirror image of therevenue cycle discussed above. Sales order, invoice/ship-ment, and collection from customer in the revenue cyclehave respective counterparts in the expenditure cycle.For example, the complement of sales order from therevenue cycle is purchase order from the expenditurecycle, the complement of sales invoice is receipts, andthe complement of collections is payments. Since the rev-enue cycle has been illustrated in a fair amount ofdetails, the expenditure cycle is exemplified by just onescenario. The purchase order scenario is demonstrated inthe following section.

The READY Model of Commitment: Purchase Order

Just as a sales order constitutes a commitment from acustomer, a purchase order embodies a commitment bythe company to purchase products or services from oneof its vendors or suppliers. The purchase order scenariostarts with searching for goods, components, or rawmaterials that need to be replenished from respectivevendors. A purchase order is then created, and line itemsare added. After all items have been added, the purchaseorder is reviewed, and confirmed. The confirmation savesthe purchase order transaction and the line item details.Accounts payable and inventory level are updated uponreceipt of a vendor’s invoice or shipment. The purchaseorder scenario will lead to the receipts (or purchaseinvoice) scenario when the goods are received. In turn,this will lead to the payment scenario. To avoid redun-dancy, we do not provide sequence diagrams of expendi-ture-related scenarios.

Conclusion

Some other accounting scenarios can also be modeledusing a similar approach. Returns and exchanges can bemodeled as extensions of regular invoice transactions.One can also include the purchase of fixed assets andtheir depreciation. The purchase of a fixed asset is likeany purchase transaction. Depreciation is a straightfor-ward adjustment that employs an algorithm, which caneasily be programmed into relevant control objects.Another accounting scenario is payroll. Each payrollremittance can be considered as a transaction involving anumber of line items such as the various kinds of deduc-tions, which may include overtime, FICA, Medicare, taxwithholdings, pension plan deductions, and medical andother insurance deductions.

Some transactions are straightforward enough so asnot to warrant inclusion. For example, a transfer offunds from one bank account to another is a simple sce-nario when expressed as a sequence diagram. Similarly,maintaining time sheets for employees or creating a bud-get are also simple scenarios.

The paper has shown a number of sequence diagram-ming patterns; other scenarios such as fixed assets andpayroll are expected to follow similar structures. Thesestructures have been shown at a high level of abstractionto allow specialization and assembly into useful analysismodels. Thus, there may be certain omissions, which canbe clarified if the diagrams are detailed. For example, thesales as well as purchase transactions can be extended toinclude the role of employees.

The READY model has predictable activities: search,select, create transaction, add line items, review transac-tion, and commit transaction. This underlying pattern can

The READY Model 209

be found in the key revenue, expenditure, and conversionaccounting cycles. By providing patterns of dynamic behav-ior of accounting scenarios, the READY model has beenshown to be a valid and useful extension of the REA model.

Author Bios

Dinesh Batra is a Knight-Ridder Research Professor of MISin the College of Business Administration at the Flor-ida International University. He is a co-author of thebook Object-Oriented Systems Analysis and Design publishedby Pearson Prentice-Hall. His publications haveappeared in Management Science, Journal of MIS, Communi-

cations of the ACM, European Journal of Information Systems,Communications of the AIS, International Journal of HumanComputer Studies, Computers and Operations Research, DataBase, Information and Management, Journal of Database Man-agement, Decision Support Systems, Requirements EngineeringJournal, and others. He has served as the President ofthe AIS SIG on Systems Analysis and Design (SIGSAND).He is an associate editor for three journals.

Thant Sin is a doctoral student in the MIS program at theFlorida International University. He completed hisMBA with IT concentration from the International Uni-versity of Japan in 2004. He has presented at variousconferences such as ICIS SIG-ISCoRE 2006, AIS SIGSAND2007, and AMCIS 2006 and 2007.

Figure 8. Sequence diagram for work-in-process scenario.

:WIPForm:ProdClerk :WIPControl :Product :WIP :ProductSpec :RawMaterial

//create new WIP()

//display WIP details()

//search product() //search

product()

//display products()

//get product info()

:Operation :Worker

//review WIP() //review

WIP() //get WIP details()

//confirm WIP() //confirm

WIP() //save WIP()

//get product info()

//update balance()

//get raw material checkout()

//get operation assignment()

//get worker assignment()

//save raw material checkout()

//save operation assignment()

//update worker assignment()

//select product() //select

product()

//get product spec()

//get lineitem()

//checkout raw material()

//assign operation()//assign worker()

210 Batra and Sin

References

Ambler, S. W. (2004). The Object Primer: Agile Model-Driven DevelopmentUML 2.0 (3rd ed.). Cambridge, UK: Cambridge University Press.

Batra, D. (2005). Conceptual Data Modeling Patterns. Journal ofDatabase Management, 16(2), 84–106.

Batra, D., & Satzinger, J. W. (2006). Contemporary Approachesand Techniques for the Systems Analyst. Journal of InformationSystems Education, 17(3), 257–266.

Bolloju, N., & Leung, F. S. K. (2006). Assisting Novice Analysts inDeveloping Quality Conceptual Models with UML. Communica-tions of the ACM, 49 (7), 108–112.

Chen, P. (1976). The Entity-Relationship Model-Toward a UnifiedView of Data. ACM Transactions on Database Systems, 1(1), 9–36.

Coad, P. (1992). Object-Oriented Patterns. Communications of theACM, 35(9), 152–159.

Coad, P., North, D., & Mayfield, M. (1997). Object Models: Strategies,Patterns, and Applications (2nd ed.). Upper Saddle River, N.J.:Yourdon Press.

Codd, E. F. (1970). A Relational Model of Data for Large SharedData Banks. Communications of the ACM, 13(6), 377–387.

Dobing, B., & Parsons, J. (2006). How UML is Used. Communica-tions of the ACM, 49(5), 109–113.

Dobing, B., & Parsons, J. (2008). Dimensions of UML DiagramUse: A Survey of Practitioners. Journal of Database Management,19(1), 1–18.

Dunn, C. L., & Grabski, S. V. (2000). Perceived Semantic Expres-siveness of Accounting Systems and Task Accuracy Effects. Inter-national Journal of Accounting Information Systems, 1(2), 79–87.

Fowler, M. (1997). Analysis Patterns: Reusable Object Models. MenloPark, CA: Addison Wesley.

Geerts, G. L., & McCarthy, W. E. (2000). The Ontological Founda-tion of REA Enterprise Information Systems. Paper presentedat the American Accounting Association Conference, Phila-delphia, PA; August 13–16, 2000.

Geerts, G. L., & McCarthy, W. E. (2002). An OntologicalAnalysis of the Economic Primitives of the Extended-REA

Enterprise Information Architecture. Information Systems, 3,1–16.

George, J. F., Batra, D., Valacich, J. S., & Hoffer, J. A. (2007). Object-Oriented Systems Analysis and Design (2nd ed.). Upper SaddleRiver, NJ: Prentice Hall.

Hay, D. C. (2006). Data Model Patterns: A Metadata Map. Amster-dam; Boston: Elsevier Morgan Kaufmann.

Ivens, K. (2008). QuickBooks 2008: The Official Guide. New York:McGraw-Hill.

Kobryn, C. (1999). UML 2001: A Standardization Odyssey. Commu-nications of the ACM, 42(10), 29–37.

Kodaganallur, V. & Shim, S. (2006). Analysis Patterns: A Taxon-omy and its Implications. Information Systems Management,23(3), 56–61.

McCarthy, W. E. (1979). An Entity-Relationship View of Account-ing Models. The Accounting Review, 54 (4), 667–686.

McCarthy, W. E. (1982). The REA Accounting Model: A General-ized Framework for Accounting Systems in a Shared DataEnvironment. Accounting Review, 57(3), 554–578.

McCarthy, W. E. (2003). The REA Modeling Approach to Teach-ing Accounting Information Systems. Issues in Accounting Edu-cation, 18(4), 427–442.

Murthy, U. S., & Groomer, S. M. (2003). Accounting Information Sys-tems: A Database Approach. Bloomington, IN: Cybertext Publishing.

Murthy, U. S., & Wiggins, C. E. (2004). OOREA: An Object-OrientedResources, Events, Agents Model for Enterprise Systems Design.Paper presented at the 25th International Conference on Infor-mation Systems, Washington, DC; December 12–15, 2004.

OMG. (2005). Introduction to OMG’s Unified Modeling Language(UML). Retrieved May 24, 2007 from http://www.omg.org/gettingstarted/what_is_uml.htm

Poels, G. (2003). Conceptual Modeling of Accounting Informa-tion Systems: A Comparative Study of REA and ER Diagrams.Paper presented at the Conceptual Modeling for Novel Appli-cation Domains: ER 2003, Chicago, IL; October 13–16, 2003.

Scheer, A. -W. (1998). ARIS—Business Process Frameworks (2nd ed.).Berlin; New York: Springer.