A. Proposed Business Transaction Processing System (BTPS) Definition:

In order to determine the scope of the object models associated with BTPS, I propose the following operational definition for BTPS:

"A system that records and tracks the scheduling, assignment and execution of the flow of goods/services and money to satisfy a specific business objective."

BTPS includes the scheduling, assignment and execution activities of procurement, inbound and outbound logistics, order processing, sales, delivery, billing and collection. A business transaction represents the recording of a specific activity showing the movement of goods/services or money by a specific person at a specific time (or a period of time). Accounts are set up to track the business transactions. Based on this definition, BTPS is useful in all firms and industries because BTPS captures the business transaction at the execution level.

BTPS does not include the activities that includes planning, forecasting, statistical analysis, trending, and profile analysis. Other non-business transactions include document-based communication of a firm.

B. Overview of a Particular BTPS

In the OOPSLA 97 Workshop, I will present a sample BTPS system (Route Distribution) to demonstrate the characteristics of a BTPS. The sample system will also be used as a reference to the proposed object model patterns defined in this paper. I believe that I can add value to the workshop by showing a partial worked example to serve as a point of discussion.

System Name: Route Distribution for Consumer Packaged Industry

Route Distribution system is the core application that runs the scheduling, assignment and execution of a consumer packaged industry (beverage, beer, snack foods, dairy, bakery, etc.). Most of these firms sell and deliver their products to thousands (sometimes hundreds of thousands) of customers via multiple selling methods and with varying frequency, often daily or within 24 hours. Some orders are pre-sold, either by a salesperson, a delivery person or over the telephone, some orders are called-in and some are actually sold right off the back of a truck. Sales and deliveries are made either manually or using mobile (or "handheld") computers. The relationship between the people who sell products to the people who deliver these products are often multi-threaded, go across locations and divisions and can change from day-to-day. Deliveries are often pre-scheduled (or "routed") but sometimes they are delivered on demand. In this environment, all "route sales persons" (or delivery persons) are "settled" (or reconciled) at the end of the day. This process involves comparing the truck inventories at the beginning of the day to the truck inventories, invoices, cash, checks, allowable route expenses, damaged and returned goods submitted by the route sales persons at the end of the day, or possibly at a later date. These companies commonly generate hundreds of thousands (and sometimes millions) of invoice transactions each month.

C. Partial OO Design of the Route Distribution System

BTPS Modules: Order Processing and Load Processing

Using the OMT notation, the basic conceptual model for the Route Distribution is shown in Figure 1. A sample worked example for State Transition Diagram for Trip Request is shown in Figure 2. The detailed description of these models will be discussed in the OOPSLA workshop (if required).

Figure 1: Route Distribution - Overview (Class Diagram: OMT Notation)

Figure 2: Trip Request (State Transition Diagram: OMT Notation)

D. Characteristics of a BTPS

This section attempts to describe the characteristics of BTPS based on the work experience of the author. Where possible, the examples are drawn from Section C: Partial OO Design of the Route Distribution System (i.e., Figure 1 and 2). Each of these characteristics may or may not be universal to BTPS. The characteristics described in this section is not meant to be exhaustive. It only serves as a point of further discussion.

Characteristics of a BTPS	Example(s)
1. High degree of details	Route Trip details include: date out/in, time out/in, mileage out/in, etc.
2. Transactions have complex life-cycles	Trip Request has several states as shown in a State Transition Diagram (Figure 2)
3. Complex business rules	Multiple Load Generation Method which includes recurring load, load request, customer orders, or a combination.
4. Complex assignments/ associations between business transactions	Many to many associations: one order is fulfilled by many trips; one trip fulfills many orders
5. Recurring schedules	Recurring order, recurring trip based on Service Frequency (e.g., every Monday of the week, or first day of the Month)
6. Audit trails required to provide evidence on the history of a specific account.	Original orders are not deleted or re-created to track the actual requirements of the customer.
7. Business transactions has many sources of input	Trip Request can be generated based on Recurring Trip or direct data entry; Input sources for orders can be from direct entry, handheld, EDI, IVR, 3rd party services, etc.

A transaction in a BTPS is usually represented as a component in a business process. It fits the work flow concept that each component (i.e., business transaction) is self-sufficient and can be re-designed (for Business Process Reengineering /Business Process Improvement). Rapid changes in business rules and functionality due to changes in Corporate/ functional strategy can also lead to changes in the application and/or process logic. Developing OO models that are robust (due to changes) and extensible (due to enhancements) serves is a challenge to software development.

The scheduling, assignment, and execution of business transactions is emphasized in this section. Although the "account" and "entry" transactions are important to BTPS, I believe that these will be covered by other participants of the OOPSLA workshop.

E. Proposed Pattern(s):

1. Transaction Request and Transaction Execution Pattern

Summary

This structure is common in business systems. A request for the transaction typically occurs before the actual transaction is executed. This allows the demand/requirement to be measured based on the transaction request. Satisfying the demand based on request is more cost-effective than no transaction request at all. Transaction Request can be maintained on-line/real-time (e.g., vendor replenishment with interface to Point-of-sale systems).

System Feature

Execution of a business transaction is facilitated by showing the referenced transaction request detail(s). For example: auto-sell feature when issuing an invoice.

Example(s):

Application Module	Transaction Request	Transaction Execution
a. Order Processing	Customer Order	Invoice
b. Load Processing	Trip Request	Trip Sheet
c. Purchasing	Purchase Request	Purchase Order
d. Warehouse Management	Transfer Request	Stock Transfer

2. Recurring Transaction, Transaction Request, and Transaction Execution Pattern

Summary	Recurring transaction is common in business transactions that follow a regular service/consumption pattern. Introducing a Service Frequency allows recurring transactions to be defined as a schedule. This patterns is an extension of the Transaction Request/Execution pattern.
System Feature	Scheduling using a time triggered service object to generate transaction request (i.e., Pull Concept). The generated transaction request can be updated (override), as appropriate.

Example(s):

Application Module	Recurring Transaction	Transaction Request	Transaction Execution
a. Order Processing	Recurring Order	Customer Order	Invoice
b. Load Processing	Recurring Trip	Trip Request	Trip Sheet
c. Purchasing	Recurring Purchase	Purchase Request	Purchase Order
d. Warehouse Management	Recurring Transfer	Transfer Request	Stock Transfer

Note: Detailed worked examples will be available in the OOPSLA workshop (if required).

F. Conceptual Modeling Problems using BTPS examples

In line with the objectives of the OOPSLA workshop, I would like to raise the following issues/ problems:

1. Clarity/Expressiveness of the Conceptual Model: At what level of detail do we stop the analysis of business transactions?
   • In the sample Object Model (Figure 1) shows that one order can be assigned to many trip requests and a trip request can have many orders. What the model does not show is the fact that Orders can be assigned to multiple trips at the order line item (i.e., product) level. What are the alternative ways of showing the detailed relationship in the OO model?
   • In the sample State Transition Diagram (Figure 2), the states and transitions are designed at the order header level (i.e., aggregate of all order line items/products). If an Order can be assigned to many Trip Requests, then we need to design our STD at the order line item level. This could lead to more complex processing and state transitions considering that two levels needs to be tracked (i.e., order header and order line item levels). My problem is to understand the alternatives for modeling header level and detail level design with many to many relationships and to know the trade-off (advantages and disadvantages).
2. Impact of Changes to the Conceptual Model: When should we emphasize separate entities (or classes) and how can we emphasize the importance of maintaining a separate entity (or class) in the Conceptual Model?
   • In the sample Object Model (Figure 1) shows that one Trip Request can be satisfied / fulfilled by zero or one Route Trip. In the Implementation phase of OO Development, the developer may decide to create one entity (or table) for both Trip Request and Route Trip. This may lead to re-design and re-work at the implementation phase should the association's multiplicity (or cardinality) change. How can we build software that are flexible and still efficient?
3. Conceptual Modeling vs. Implementation Modeling. Are there standards (or checklist) on how to differentiate one from the other? What are the principles in Implementation modeling that does not fit very well with Conceptual Modeling principles?
4. Based on recent experience with Object Modeling, the Conceptual Model does not directly map to the Implementation Model. The Conceptual Model seems to be most useful in the thinking process (analysis) and will indirectly benefit the developers (i.e., software engineers) when a question or issue is raised. What are the experience(s) of the other participants of the OOPSLA workshop? Will the BTPS workshop increase the usefulness of the Conceptual Models (maybe by showing a transition path to Implementation Model)?

The problems / issues presented in this section are meant to facilitate the discussion of problems encountered in object modeling for a BTPS. Some of these problems may be common to BTPS. I believe that discussions on how developers solve each of these type of problems can lead to a smoother transition path from Conceptual Modeling to Implementation Modeling for BTPS.

G. Descartes Systems OO Development Methodology

Most of the OO Development (using client/server architecture) efforts that I have encountered requires the developer to design and develop a BTPS (a specific application) for a particular firm in a particular environment (may be multiple platform). The complexity of the design increases dramatically when are developing a software application that will be used by various firms in various environments.

This section summarizes the OO Development approach and OO Tools that Descartes Systems is currently using, to build a suite of applications for the Supply Chain Operations. Details on the development methodology, tools, and the Descartes experience will be discussed in the OOPSLA (if required).

Methodology Reference:

1. SCRUM product development methodology (modified)
2. SELECT Perspective: Rumbaugh/ Jacobson/ Unified (modified)
3. Information Technology Project Management

Major Tools:

1. SELECT Enterprise/ Forte Generator (Business Process Modeling, Use Case Modeling, Object Modeling)
2. Forte Transaction Object Oriented Language (OO, 4GL, GUI, multi-platform, multi-tier client/server architecture)
3. Forte Express (Business Model and Application Model: TOOL Code Generator)
4. Forte Conductor (Work Flow Process Engine: separates the application domain vs. process domain)

H. Biography

Meyer Tanuan is currently the Lead Systems Analyst of the Research and Development Department of Descartes Systems. His key responsibilities include Object Modeling for the OO Supply Chain Execution Software of The Descartes Systems Group, Inc. He has 11 years of systems planning, development and implementation experience in the following medium to large scale (50-300 users) BTPS systems: Order Processing, Warehouse Management, Inventory Management, Route Distribution, Accounting Transaction Reporting, Accounts Receivable, General Ledger.

Academic Background:

• MBA (Information Systems and Computer Applications), De La Salle University (March, 1995)
• Bachelor (Honours) in Computer Science, University of the Philippines (April, 1987)

Personal Objectives for the Workshop:

1. to positively contribute to the overall goals of the workshop (i.e., define and characterize BTPS, propose solutions for BTPS problems raised in the workshop, etc.)
2. to validate and reinforce the object models to be presented by other participants
3. to propose BTPS object model(s) or pattern(s) for potential reuse by any firm or industry; to validate these models based on the combined expertise of the participants
4. to meet and exchange ideas with IT professionals and consultants actively involved in the OO Development in the BTPS
5. and more importantly, to have fun…

Note: Any comments or feedback would be highly appreciated. Attachment converted: dixie:Img00011.gif (GIFf/JVWR) (0000B9DA) Attachment converted: dixie:Img00012.gif (GIFf/JVWR) (0000B9DB)