Stevie: A dynamic, between-instructor collaborative Internet tool for learning cardinalities.
Keywords: cardinalities; collaborative design; data modeling; Internet; REA accounting.
Data Availability: Contact the first author for access to Stevie.
In recent years, the data modeling approach to accounting information systems (AIS) has become increasingly popular among AIS educators (Hollander et al. 2000; Romney and Steinbart 2000). Data modeling methodologies are used to create conceptual schemas. Conceptual schemas have a dual role (Eriksson and Penker 2000): (1) the description of the phenomena to be captured in the information system such as the economic activities of a company, and (2) the definition of the database structure. Typical concepts supported by most data modeling methodologies include entities, relationships, attributes, generalization, aggregation, and cardinalities. In accounting contexts, these concepts are often conveyed by AIS instructors using McCarthy's (1982) Resource-Event-Agent (REA) model as a framework. The REA model, which is grounded in economic and accounting theory, is a template that helps structure conceptual schemas in an accounting context and provides consistency in modeling enterprise phenomena across the value cha in.
Relationship cardinalities are one of several data modeling conventions commonly used to express business practices. Cardinalities in a data model indicate how entities participate in relationships. In an accounting context they are helpful for expressing the existence of phenomena such as down payments, prepayments, and open orders. Concepts of data modeling in general and relationship cardinalities in particular are recognized as being difficult to learn (Jarvenpaa and Machesky 1989; Batra et al. 1990; Batra and Davis 1992; Hollander et al. 2000). The instructional tool discussed in this paper, nicknamed "Stevie," is aimed at enhancing students' understanding of cardinalities.
Stevie is an online, between-instructor, collaborative learning tool that provides students with the opportunity to work through exercises on cardinalities outside of class. A previous version of Stevie has been described in the AIS literature. (1) The current paper describes an enhanced version of Stevie where instructors become content providers in a collaborative environment. There are two main categories of users for Stevie: students who learn cardinalities and instructors who design the content of the learning tool. For students, Stevie is an interactive learning tool, allowing them to solve cardinality exercises, submit their answers, and receive feedback. Using the Internet as the delivery mechanism, Stevie provides easy access for students at any time. For instructors, Stevie enables active participation in a collaborative environment. Instructors use their own specific expertise to contribute to the creation of exercises, share exercises with other instructors, manage student accounts, and create ass ignments adapted to specific learning objectives and learning strategies.
The remainder of the paper is organized as follows. The first section explains the cardinality concept. Then, the design goals for Stevie as a collaborative Internet tool are described. Next, we depict Stevie as an interactive Internet tool for learning cardinalities, for the creation of cardinality exercises and customized assignments, and for the sharing of cardinality exercises among instructors. Finally, we discuss the use of Stevie in the AIS course in more detail. The concluding section summarizes the paper and discusses possibilities for future research involving Stevie including its use by students, its use by instructors, the sharing of content in a collaborative environment, and the collection of data utilizing dynamic Internet technology.
Figure 1 illustrates an Entity-Relationship diagram that expresses a relationship (prefers) between two entities: customer and product. The relationship describes a customer's favorite product. We use the Batini et al. (1992) notation for cardinalities. Cardinalities express constraints that apply to the participation of the instances of an entity in a relationship. There are two different types of cardinalities: minimal cardinality and maximal cardinality.
A minimal cardinality denotes whether the participation of an occurrence in the relationship is mandatory (1) or optional (0). For the example in Figure 1, the participation of products in the "prefers" relationship is mandatory. This implies that a product occurrence will be considered only when it participates in the relationship. Stated differently, products are recorded only when they are the favorite product of at least one customer. The participation of a customer in the same relationship is "0" or optional. This implies that customer instances do not have to participate in the relationship. Stated differently, customers can be recorded without knowing their favorite product.
A maximal cardinality restricts the number of times an instance can participate in a relationship. A maximal cardinality of one (1) expresses that an instance can participate only once in the relationship. This is true for a customer in the customer-product relationship. The company records, at most, one favorite product for a customer. A maximal cardinality of many (N) is used when there is no restriction. This is true for the participation of product in the product-customer relationship. The same product can be the favorite of many customers.
Since there are minimal and maximal cardinalities at both sides of the relationship (as shown in Figure 1) and each minimal and maximal cardinality has two possible values (minimal "0" or "1" and maximal "1" or "N"), the result is 16 possible patterns for each relationship. This is because there are four cardinalities in each relationship (two minimums and two maximums), each with two alternatives, yielding 16 possible patterns. Being an interactive tool, Stevie must provide advice, i.e., feedback to users, for all 16 patterns for each of the exercises.
Differences exist in symbols used as well as the placement of cardinalities among modeling notations. For example, Chen (1976) uses an "M" instead of an "N," Unified Modeling Language (UML) (Booch et al. 1999) uses an asterisk (*) for the same purpose, and other notations use a graphic symbol such as a crow's foot (Martin and Odell 1992) or a double arrow (Shlaer and Mellor 1992). For a number of cases, UML uses one symbol to express both minimal and maximal cardinalities. Also, some notations, including UML, allow more precise definitions of cardinalities such as exactly two occurrences participate in the relationship (2,2) or between 2 and 5 occurrences participate in the relationship (2,5). Further, the placement of the cardinalities is different between notations. For the notation used in Figure 1 and throughout this paper, the cardinalities that are used to restrict the participation of an entity in a relationship are put at the side of that entity (Batini et al.1992). However, other notations (Chen 1976 ; Booch et al. 1999) put the same restrictions at the opposite side of the relationship.
As we explain in Section IV, Stevie is able to dynamically adapt the symbols used on the answer sheet to the notation chosen by the instructor. However, the following restrictions exist: Stevie limits itself to two values for both cardinalities, always uses different symbols for minimal and maximal cardinalities, and does not support graphic representations of cardinalities such as a crow's foot or a double arrow.
III. DESIGN GOALS FOR STEVIE AS A COLLABORATIVE INTERNET TOOL
A unique feature of Stevie is the active participation of instructors as content providers in a collaborative environment. Stevie allows instructors to manage student accounts, add exercises, and define assignments. The ability to create exercises makes instructors content providers. They define exercises that represent their expertise and that are adapted to the level of complexity in their courses. The dynamic creation of assignments allows instructors to use Stevie in support of their learning objectives and learning strategies. It is important to note that instructors do not need Internet programming skills to become content providers for Stevie.
The design of cardinality exercises, in particular those that represent accounting practices, is a time-intensive and demanding task. Therefore, Stevie is designed as a collaborative environment supporting the sharing of exercises. Stevie's collaborative nature should increase both the quantity and the diversity of the exercises available. Stevie allows instructors with different backgrounds and strengths who teach at both the undergraduate and graduate levels to add exercises in their. specialty areas. These exercises should help students, and perhaps AIS instructors, understand difficult data modeling concepts.
To increase the number of users of Stevie, barriers that might limit its usefulness should be eliminated to the extent possible. One such barrier is differences in the cardinality notation used by instructors. Stevie allows instructors to choose from different notations when defining exercises and assignments for their students. Additionally, to help instructors build assignments that meet their specific learning objectives, exercises are categorized along accounting-specific criteria such as business processes or REA relationship types. Such categorization helps instructors obtain an overview of all exercises regarding a specific topic. Ultimately, collaboration between instructors should result in a diversified set of exercises, a better understanding by instructors of the modeling of accounting-specific phenomena, and an improved learning experience for students.
IV. USE OF STEVIE BY STUDENTS AND INSTRUCTORS
There are two categories of users for Stevie: students who learn cardinalities and content providers. Students' use of Stevie is limited to solving cardinality exercises. There are two types of content providers: instructors and administrators. Instructors use Stevie to create exercise definitions, assignments, and student accounts. Assignments are a combination of exercises. Definitions of exercises can be shared among instructors. Some of Stevie's content can be accessed only by administrators. This includes items such as universities, instructor accounts, data modeling methodologies, PEA relationship types, and business processes. If instructors would like to make changes to these content items, then they need to contact one of the administrators. (2) In this section, we discuss the use of Stevie from two different perspectives: as a tool for solving cardinality exercises (students) and as a collaborative tool for content design and the creation of dynamic assignments (instructors).
Solving Cardinality Exercises
Figure 2 illustrates a student completing a cardinality assignment. Stevie's interface, as seen by students, has the following parts: exercises, graphical exercise description (optional), textual exercise description, answer sheet, and advice.
The exercises section shows a student's assignment. This section is dynamic and can be easily updated by the instructor. Students can select exercises in any order and can solve the same exercise more than once.
An exercise description is shown when a student selects a specific exercise. There is a textual description for each exercise called Exercise Description (Narrative). For the example in Figure 2, the student is asked to translate accounting concepts such as accounts receivable, installments, and prepayment in terms of cardinalities for the relationship between sale and cash receipt.
The graphical description is shown at the center top of Figure 2 and is called Exercise Description (Picture). It includes the picture and the rectangles representing the sale and cash receipt entities. This graphical description is optional on the part of the instructor who created the exercise. There are advantages and disadvantages of the graphical description. The graphical description helps to determine the left-side entity and the right-side entity of the diagram for students. However, the graphical description must be created by the instructor and stored on his or her server. This proves to be difficult if a faculty member does not have access to a server. In addition, students who have modem Internet access may experience delays in loading graphical descriptions.
The answer sheet shown in Figure 2 allows a student to submit a solution. The symbols used in the answer sheet will differ depending on the data modeling methodology chosen by the instructor. For the exercise in Figure 2, the student has defined a minimal cardinality of "O" and a maximal cardinality of "N" for the participation of sale (left) in the sale-cash receipt relationship, and a minimal cardinality of "0" and a maximal cardinality of "1" for the participation of cash receipt (right) in the sale-cash receipt relationship. After submitting an answer, the system will generate feedback for the student, as shown on the bottom right in Figure 2. If the answer is incorrect, then Stevie explains the error to the student and the student can submit a new answer. For the example in Figure 2, Stevie explains to the student that the maximal cardinality of "N" for the participation of sale in the relationship with cash receipt is incorrect since no installments are allowed. If the student submits the correct answe r of 0 (left min), 1 (left max), 0 (right min) and 1 (right max), then Stevie will congratulate the student.
Creating Cardinality Exercises, Assignments, and Student Accounts and Sharing Exercises
Stevie provides instructors with an interface that allows them to define exercises, define assignments, manage student accounts, and share exercises with other instructors. The instructor interface is illustrated in Figure 3. Next, we discuss each of these four instructor-specific functions in more detail.
To define a new exercise, the instructor completes the form shown in Figure 4. Stevie generates the exercise in Figure 2 from the data entered by the instructor in Figure 4. Instructors need to specify three types of data: exercise overview, classification criteria, and advice.
The exercise overview encompasses the following three items: exercise name (Sale-CashReceipt), exercise description, and URL picture. The graphic description as seen by a student is dynamically generated from a URL specified as part of the exercise definition. This implies that the instructor has to create the picture and put it on a server. As mentioned previously, the graphical description is optional. The exercise description is the textual description of the exercise as seen by the student. Instructors can add HTML code to the exercise description for extra formatting. For the exercise shown in Figure 2, extra HTML code (<LI> tags) was used to present the exercise description as a list of items preceded by bullet points.
Currently, there are five classification criteria: data modeling methodology, REA relationship type, business process, domain specificity, and other categories. The data modeling methodology is the only required category. The data modeling methodology selected determines the cardinality symbols shown in the student interface. The instructor has selected E-R (Batini) notation for the example in Figure 4. The "Change Methodology" button allows changing the notation used in the "Define Exercise" screen. The other four classifications are discussed in detail in the Domain-Specificity and Topic-Specific subsections of Section V.
Sixteen different cardinality patterns exist for each binary relationship. Instructors are asked to specify the correct value for each of the four cardinalities and the advice to be shown to the student when the value for the cardinality is wrong. Advice specifications need to be adapted to the placement of the cardinalities in the notation chosen. Correct answer and advice specifications are illustrated at the bottom of Figure 4. An instructor is asked what the correct value is for the left minimal cardinality and what advice is to be shown when a student submits an incorrect value. For the example in Figure 4, the correct left minimal cardinality is "0." The advice box explains why a minimal cardinality of "1" is incorrect. This is the explanation that will be given when a student selects the incorrect cardinality in the answer sheet. The advice boxes for the three other cardinalities (left maximal, right minimal, and right maximal) are not shown in Figure 4. Stevie generates the 16 advice patterns based o n the specifications for each of the four cardinalities.
Instructors are able to modify exercise descriptions. Two options exist for changing the advice specifications. First, instructors can change the advice patterns defined for each of the four cardinalities. Second, instructors can access the actual HTML code generated by Stevie for each of the 16 cardinality patterns. This functionality is useful if an instructor would like to modify the default formatting used by Stevie.
Stevie supports the creation of dynamic assignments. Figure 5 illustrates the screen that helps instructors create assignments. To create an assignment, instructors simply add exercises to the assignment. The left column shows all the exercises available and the right column shows all the exercises currently in the assignment. When instructors press the "view exercise" button, Stevie provides information about the instructor who created the exercise and the instructors currently using the exercise. An extensive list of current users might indicate the usefulness of the exercise. Further, instructors are able to try out the exercise to verify its correctness and to determine whether it meets the instructional objectives.
To help instructors create more specialized assignments, they can search the exercise database based on a number of predefined criteria. The latter are shown at the bottom of Figure 5. The instructor can select any number of criteria. For example, instructors can ask Stevie to list all exercises created by a specific instructor for a specific REA relationship type (e.g., duality), or for all semantic exercise definitions in the conversion cycle. Stevie will then list all exercises that meet these criteria in the left column. Stevie's search feature should help instructors define topic-oriented assignments.
Instructors are able to define, modify, and delete student accounts as needed. Figure 6 illustrates the "Insert New User" screen. The following information needs to be entered for a user: username, password, and assignment. Instructors can switch to new assignments by simply replacing the current assignment number with a new assignment number. Users created by instructors get no administrative privileges and are only able to solve the exercises assigned to them. The instructor's institution is automatically assigned to the student. However, instructors can change the institution if necessary, for example if the instructor moves or teaches at more than one institution.
A unique feature of Stevie is the ability to share exercises between instructors. Extra tools are provided to support such collaboration. The sharing screen in Figure 7 divides the exercises created by an instructor into three categories: exercises used by other instructors, exercises made available for sharing but currently not used by any other instructor, and exercises not made available for sharing. For the first category, Stevie is able to generate statistics such as the number of instructors who have included the exercise in their assignments and the number of students who have used the exercise. If an exercise is made available for sharing and is then used by another instructor (moving it from the middle category to the first category), the instructor who created the exercise can no longer hide it from sharing. This is important because if other instructors have an assignment often exercises, and the instructor who created the exercise was able to remove an exercise that was being used, the other inst ructors would suddenly have an assignment with nine exercises instead often. Therefore, the instructor who created the exercise should keep it in the third category, not available for sharing, until it is perfected and ready to be used by others. When the exercise is ready to be shared it should be moved into the middle category, available for sharing but not currently used by any other instructor.
V. USE OF STEVIE IN THE AIS CLASS
Stevie can be used in any data modeling class. However, its current content has been created by AIS instructors for use in an AIS class. Stevie's flexibility in creating assignments allows it to support different learning objectives. In this section we look at two different strategies in learning cardinalities: increased domain-specificity of cardinality exercises and topic-specific cardinality assignments. Both strategies will further illustrate the usefulness of the REA model in learning cardinalities and how Stevie facilitates the process.
Domain-Specificity of Cardinality Exercises: Syntactic, Semantic, and Heuristic
It is common to use a three-step learning strategy for cardinalities in a REA-structured AIS class. First, students learn the syntactic meaning of cardinalities. This is accomplished by giving students exercises where the meaning of each of the cardinalities is explicitly defined. The domain-specificity of the exercises is less important and both accounting and nonaccounting exercises are useful. Next, students learn to interpret accounting phenomena in terms of cardinality patterns. To solve such semantic exercise descriptions, a good understanding of accounting phenomena is needed. Finally, students learn to specify stereotypical patterns or heuristics for accounting-specific relationships. For heuristics, students need an in-depth understanding of the accounting-specific relationship across business processes. Syntactic, semantic, and heuristic exercise descriptions represent a difference in domain-specific knowledge needed to solve an exercise. Obviously, a single exercise could combine all three types of descriptions.
The exercise in Figure 2 illustrates a semantic description. For a semantic description, students need a good understanding of the accounting phenomena being represented to be able to derive the corresponding cardinalities. In contrast to a semantic exercise description, a syntactic exercise description explicitly defines the cardinalities. For example, a syntactic description for the exercise in Figure 2 is: "There is at most one cash receipt for a sale. There can be a payment for which there is no sale. There can be only one sale for a payment." No domain-specific knowledge is required to discern the cardinalities.
Stereotypical cardinality patterns or heuristics can often be defined for REA relationships (Hollander et al. 2000; Geerts and Waddington 2000). Figure 8 illustrates a heuristic description for a control relationship between an economic event and an agent. Economic agents commonly participate in more than one event, and the recording of an agent typically takes place before the agent participates in the economic event. Further, only one agent is typically involved in an event. This pattern holds across business processes. For example, vendors are typically involved in many purchases while customers are typically involved in many sales. Heuristic exercise descriptions are typically limited to a graphic representation of an REA relationship (e.g., control) and students have to decide what generic cardinality values apply to the relationship. Heuristic cardinality patterns are an important part of the learning process that provides students with generic knowledge they can apply in different situations.
Stevie allows instructors to create assignments that fit with such a three-step learning strategy. Students are successively exposed to a set of syntactic, semantic, and heuristic exercise descriptions requiring an increasing amount of accounting-specific knowledge.
One of Stevie's features is that instructors are able to classify exercises in terms of specific AIS-related categories including REA relationship types, business processes, and other topics. The first two are categories commonly used by instructors as a guideline for teaching AIS concepts. Categorization helps instructors create assignments tailored to specific AIS topics. In this section we discuss topic-specific assignments and the use of Stevie to support such assignments. We differentiate between the following three types of assignments: REA relationship types, business processes, and others topics such as time dependency.
REA Relationship Types
The REA-relationship-type category contains the relationships defined in McCarthy (1982) and extended by Hollander et al. (2000) and Geerts and McCarthy (2000), including duality, stock-flow, control, responsibility, location, executes, participation, reciprocal, reserves, association, and linkage. Instructors can build assignments that focus on one specific relationship. Such assignments help students look at accounting phenomena that apply across cycles or study specific accounting phenomena. This process helps to emphasize that cardinalities define business practices of an entity. For example, one business entity may accept deposits or prepayments and another may not. Next, we discuss two relationships in more detail: duality and association.
A duality relationship represents the mirror-image nature of exchanges: an outflow of resources (give) should be compensated by an inflow of resources (take) and vice versa. Cardinality patterns are used to express business practices that apply to exchanges such as acceptability of installment payments and creation of liabilities from the inflow of resources. The business practices expressed by a specific cardinality pattern typically reach across all accounting cycles or business processes, as they are referred to in this paper. For discussion purposes, we will use one common cardinality pattern for duality relationships that reaches across business processes, (0,N) (1,N). The relationships between sale-cash receipt, purchase-cash disbursement, and labor service-cash disbursement relate to three different business processes, but are similar in nature--they all describe exchanges. For the sale-cash receipt relationship, we read the (0,N) (1,N) pattern as follows: there can be a sale without a cash receipt, b ut a sale can have many cash receipts. A cash receipt must relate to an existing sale, but could relate to many existing sales. This pattern holds for all the business processes. The meaning of each cardinality is similar across cycles. The "0" in the cardinality pattern refers to accounts receivable in the revenue cycle, accounts payable in the acquisition cycle, and wages payable in the payroll cycle. Likewise, the first "N" maximal cardinality indicates installment payments are allowed in any cycle. For example, a sale relating to many (N) cash receipts means customers can make installment payments. Going in the opposite direction, the "1" indicates that a sale must be present for a cash receipt to occur or no deposits are accepted. In the two expenditure-related cycles, acquisition and payroll, this cardinality represents a control. Specifically, it means that purchases or labor service cannot be paid for until received. Companies could have a "0" cardinality here, but they then run the risk of not receiv ing something they paid for in advance. Finally, the second "N" indicates that many sales, purchases, or labor services can be paid for at the same time. Showing the similarities across business cycles helps students better understand not only the duality relationship as a description of exchanges and the different types of business practices that apply to exchanges, but also the similarity among business processes in accounting.
An association relationship between internal agents in the REA model is useful for representing differences in organizational structures (Geerts and McCarthy 2000). For example, a 1-N maximal cardinality relationship between internal agents, such as employee and management or department, would indicate a hierarchical organizational structure in which each employee is assigned to only one manager or department. Similarly, an N-N maximal cardinality relationship between employee and management or department would indicate a matrix structure where each employee is assigned to many managers or departments.
A common approach to teaching AIS is to focus on one business process at a time. We follow Hollander et al. (2000) to replace the term "accounting cycle" by the more generic term "business process." However, in line with the traditional and generally accepted accounting cycles, we retain finance, acquisition, conversion, payroll, and revenue as the primary business processes in an AIS course. A common teaching strategy in a REA-structured AIS class is to present a stereotypical template for each of the main business processes. With Stevie, instructors are able to create assignments that group the relationships into a specific accounting cycle (business process). Students will learn to use cardinalities to express a series of accounting phenomena and accounting practices related to that business process.
We now illustrate this teaching strategy in the context of a stereotypical template for the revenue cycle, shown in Figure 9. Seven relationships are inherent in this template and different practices might exist for each relationship. For example, two different practices may exist for the stock-flow relationship between sale and inventory. If the inventory items are tracked individually, then the cardinalities by inventory are (0,1). The "1" maximal cardinality indicates that an item can only be sold once. If inventory items are not tracked individually, as in mass merchandising, then the cardinality pattern by inventory is (0,N). The "N" maximal cardinality indicates that the same inventory item can be sold many times. Further, students could be given syntactic or semantic descriptions for each of these practices.
A number of data modeling issues exist that are especially relevant for a specific set of REA relationships. A good example of such an issue is time dependencies. Instructors can use Stevie to build such issue-related assignments. We explain time dependencies in more detail next.
An example of a time dependency issue is given in Figure 10. In the acquisition cycle, the typical sequence of events is order, then purchase, and finally cash disbursement. In the relationship between order and purchase, the purchase (an economic event) executes the order (a commitment). Therefore, a "0" minimal cardinality is placed by order, indicating that it happens first and an open order can exist. Likewise, the minimal cardinality by purchase is "1," indicating that a purchase can occur only after an order has been placed.
Furthermore, there are time dependency issues in the duality relationship between purchase and cash disbursement. Typically, a purchase occurs before the cash disbursement, so a "0" minimal cardinality is placed by purchase and an account payable could be recorded in accrual accounting. Likewise, cash cannot be disbursed without a valid purchase, so a "1" minimal cardinality is placed by cash disbursement. However, if the timing is changed and advance payments are allowed, then there would be a "0" minimal cardinality by cash disbursement and a prepaid asset could exist in accrual accounting. This exercise teaches students how the business rules relating to the timing of events in the organization affects both the accrual accounting entries required and the cardinality pattern that must be depicted in the data model.
VI. CONCLUSIONS AND EXTENSIONS
Stevie is a dynamic Internet tool that is designed to help students learn how a key aspect of business rules, i.e., cardinalities, is represented in the data model for a business process. Stevie also facilitates collaboration between AIS instructors for creating and sharing cardinality exercises. Allowing exercises to be created and shared by different instructors results in more diverse exercises to choose from when designing assignments for the AIS class. Furthermore, instructors can choose between different domain specifics such as syntactic, semantic, and heuristic, and different topic specifics such as REA relationship types, business processes, and other topics such as time dependencies to target assignments at specific course objectives.
As a learning tool, Stevie could benefit from further categorization. New accounting-related categories need to be considered while further classification in terms of application domains such as business or engineering might be beneficial as well. For example, Stevie could be expanded to handle different business applications, such as marketing, finance, or human resources. Furthermore, the technology used for Stevie could be expanded to other areas, such as auditing, where students may have trouble learning topics such as audit objectives, types of evidence, and types of tests. Like cardinalities, some students grasp audit objectives right away while others might require extra practice. As an example of an exercise that could be built using Stevie's technology, students could be given several specific audit objectives and could then be asked to indicate (1) the correct general audit objective, (2) the type of audit evidence required, and (3) the type of audit test they would perform. With feedback from the t ool, student learning of audit objectives, types of evidence, and types of tests could be enhanced.
The current paper explores Stevie as a between-instructor, collaborative Internet learning tool where the content can be adapted to specific learning objectives. Future research could study Stevie as both a collaborative environment and as a learning tool. As a growing virtual community, Stevie provides data that could help us better understand issues such as the willingness of instructors to share knowledge, the nature of the expertise shared by instructors, and the range of learning strategies implemented by instructors. Other important aspects that could be addressed are Stevie's effectiveness as a learning tool and whether an increase in the number and diversity of exercises results in enhanced understanding of cardinalities.
We acknowledge the helpful comments of the editors and three anonymous reviewers, as well as the advice and help of Randy Brown, Robin Poston, and Arline Savage in the construction and testing of the tool.
Accepted for publication by Uday Murthy and Casper Wiggins.
(1.) Geerts and Waddington (2000) demonstrate the use of the Internet as an alternative mechanism for delivering AIS tools, using Stevie as an example. Geerts and Waddington (2002) explore the use of Stevie for data collection. Specifically, Geerts and Waddington (2002) discuss how Stevie can be used to track information such as the browser used by students, the time students need to complete an assignment, the answers submitted by students, etc. Both of these studies use a noncollaborative version of Stevie.
(2.) The first author is the current administrator for Stevie.
Batini, C., S. Ceri, and S. B. Navathe. 1992. Conceptual Database Design. An Entity-Relationship Approach. Redwood City, CA: Benjamin/Cummings.
Batra, D., J. A. Hoffer, and R. P. Bostrom. 1990. Comparing representations with relational and EER models. Communications of the ACM 33 (2): 126-139.
-----, and J. G. Davis. 1992. Conceptual modeling in database design: Similarities and differences between expert and novice designers. International Journal of Man-Machine Studies 37: 83-101.
Booch, G., J. Rumbaugh, and I. Jacobson. 1999. The Unified Modeling Language User Guide. Reading, MA: Addison-Wesley.
Chen, P. P. 1976. The entity-relationship model--Toward a unified view of data. ACM Transactions on Database Systems (March): 9-36.
Eriksson, H-E., and M. Penker. 2000. Business Modeling with UML. New York, NY: John Wiley & Sons.
Geerts, G. L., and W. E. McCarthy. 2000. The ontological foundation of REA enterprise information systems. Paper presented at the Annual Meeting of the American Accounting Association, Philadelphia, PA.
-----, and B. A. Waddington. 2000. The delivery of accounting information systems study tools through the Internet. Review of Accounting Information Systems 4(1): 37-46.
-----, and -----. 2002. Design and evaluation of an Internet study tool as a data collection device. Review of Business Information Systems 6(1): 7-16.
Hollander, A. S., E. L. Denna, and J. O. Cherrington. 2000. Accounting, Information Technology, and Business Solutions. Second edition. Burr Ridge, IL: Irwin/McGraw-Hill.
Jarvenpaa, S. L., and J. J. Machesky. 1989. Data analysis and learning: An experimental study of data modeling tools. International Journal of Man-Machine Studies 31: 367-391.
Martin, J., and J. J. Odell. 1992. Object-Oriented Analysis & Design. Englewood Cliffs, NJ: Prentice Hall.
McCarthy, W. E. 1982. The REA accounting model: A generalized framework for accounting systems in a shared data environment. The Accounting Review (July): 554-578.
Romney, M. B., and P. J. Steinbart. 2000. Accounting Information Systems. Eighth edition. Upper Saddle, NJ: Prentice Hall.
Shlaer, S., and S.J. Mellor. 1992. Object Lifecycles. Modeling the World in States. Englewood Cliffs, NJ: Prentice Hall.
|Printer friendly Cite/link Email Feedback|
|Author:||Geerts, Guido L.; Waddington, Barbara A.; White, Clinton E.|
|Publication:||Journal of Information Systems|
|Date:||Mar 22, 2002|
|Previous Article:||Determinants of consulting service quality for accounting and nonaccounting service providers.|
|Next Article:||Editor's Report.|