AN OBJECT.;ORIENTED TECHNIQUE FOR MODELING COMPLEX...

AN OBJECT.;ORIENTED TECHNIQUE FOR MODELING COMPLEX BUSINESS MESSAGES

Dale L. Lunsford, Ph.D, Culverhouse School of Accountancy, 322 Alston Hall, University of Alabama, Tuscaloosa, AL

35487-0220Donna F. Davis, Ph.D, The University ofMississippi, College ofBusinessAdministration, Southern Station, Box 5178,

Hattiesburg, MS 39406Donald L. Davis, Ph.D, D3, Inc., P.O. Box 17618, Hattiesburg, MS 39404

ABSTRACT

One of the major challenges faced by the systems analyst inthe development of an information system is understandingthe functions of an existing organizational system.. Wepresent the Business Message Analysis Technique(BMA T), an object-oriented approach to modeling businessmessages that produces a derived-object model for eachbusiness message.

BUSINESS MESSAGES

Traditionally, business messages have been transmitted inwriting using a paper medium; however, today's businessmessages are transmitted using a variety of mediums

including graphical reports, multimedia presentations, andmachine-understandable data packets. Regardless of thechannel or medium used to transmit a business messagebetween or within organizations, the substance of thebusiness message remains unchanged. The businessmessage must carry the data and information necessary forthe receiver to respond to the business message. From the

organizational perspective, a particular instance of abusiness message is a derived object that brings togetherdata from one or more relevant problem-domain objects.The business message is a derived object because it iscomposed of data from other objects that exist in apersistent state within the organizational database. Toavoid redundancy, the business message should not exist ina persistent state. The information system derives thebusiness message, as needed, from the persistent objects.

INTRODUCnoN

The systems analyst in today's organization faces

significant challenges during the development of today'scomplex information systems. We contend that currenttechniques are inadequate for this task as they are notcapable of modeling the logical structure of business

messages.

During the systems analysis stage of an information

systems development project, the systems analyst producesan implementation-independent description of theinformation system requirements. This implementation-

independent description consists of (I) logical models ofthe business processes supported by the information system,(2) the business rules associated with each process, and (3)the data captured, retained, and produced by theinformation system. Because of the important roles thatbusiness messages play in the effective and efficientoperation of organizations, the logical structure of eachbusiness message must be fully specified during systems

analysis. Unfortunately, systems analysis methodsgenerally do not provide adequate techniques for modelingbusiness messages. As a solution to this problem, wepr~sent the Business Message Analysis Technique (BMA T)for modeling business messages during systems analysis.For each business message, BMA T produces a conceptualdata model, called a derived-object model, that describes aparticular type of business message. The derived-objectmodel is a logical model of the data and informationincluded in a business message, as well as the businessservices necessary to process the business message

Although the business messages received and produced byan organization represent critical inputs and outputs of theinformation system, existing object-oriented and structured

systems development methods provide little or no supportfor modeling the messages during systems analysis.Originators of object-oriented systems analysis methodspresent a number of techniques for identifying problem-domain objects; however , analysis of existing businessmessages is generally not discussed. Existing structuredsystems development methods describe the messages bydecomposing them to produce data dictionary entries or byrendering documents to produce page layout charts duringlogical design. Data dictionary entries depict businessmessages using mathematical expressions or logicaldatabase record structures. As a result, data dictionaryentries often use a confusing or unclear notation, are wordy,and significantly differ from the representation ,of theorganizational data model produced during systemsanalysis. Page layout charts depict messages using anillustration of the final, printed business document, and arephysical models, that significantly differ from the

742

representation of the database produced during systemsanalysis, and are often inadequate for representing the datacontent necessary to produce agraphic. Continuing our example, we group the attributes into

classes. As an example, the order form includes data aboutthe customer. As a result, we create a Customer class thatincludes as attributes the Customer ID, Customer Name,Address, etc. We also create an Order class, Order Itemclass, Clerk class, and Mailing class Figure 3 is the initialderived-object model with the initial classes identified.

rUser views are represented by relations and EntityRelationship Diagrams. The database analyst constructsuser-view Entity Relationship Diagrams and converts theuser-view these into relations. The database analyst thenintegrates the collection of relations to form theorganization's relational data model. Our approach differsfrom other authors [Hoffer , et al 1996, McFadden andHoffer, 1991] in two major ways. First, BMA T provides amechanism for identifying object-level and class-levelservices. The identification of services is a critical anddifficult step of object-oriented systems analysis methods.Second, BMA T yields a derived-object model for eachindividual business message. The derived-object model isan atomic, reusable specification of the business message.End-users may easily validate each derived-object model.Since a user view often includes elements of severalbusiness messages, the systems analyst can then integratethe validated derived-object models to produce the userview.

3. Identi~ structural relationships among the classes.The systems analyst identifies the association, aggregation,and generalization relationships that exist among. theclasses. The systems analyst may identi~ additional classesneeded to represent higher-level aggregate classes orgeneralization classes. Often, the systems analyst mustexamine several sample documents to determine the needfor generalization classes. Once again, the systems analystmeets with end-users and managers to determine therelevant relationships among problem-domain objects andincorporates these into the derived-object model. Thesystems analyst adds new classes and draws connectionsreflecting the relationships among the classes on thederived-object model.

THE BUSINESS MESSAGE ANAL YSIS TECHNIQUE4. Define the cardinality of each relationship. In additionto determining the type of relationships among class, thesystems analyst identifies the cardinality associated witheach association and aggregation. Three commoncardinalities are one-to-one, one-to-many, and many-to-many, reflecting the number of instances ofa class that mayparticipate in a particular relationship [Conger, 1994].

Using BMA T a significant departure from traditional datamodeling occurs during the last three steps of this processwhen object-level and class-level attributes are identified

r' and converted to services. The systems analyst generates a

derived-object model by performing the following steps.

t

I. Identify the relevant attributes contained in thebusiness message. The systems analyst identifies each ofthe variable data fields on the business message as anattribute by examining samples of the business message,locating all of the fields in the business message thatrepresent variable data, and selecting all of the variabledata fields captured or filled-in by the information system.

5. Identify object-level derived attributes and services.The systems analyst replaces each object-level derivedattribute with a service. The systems analyst should alsoproduce a specification of the business rules necessary tocompute the value of the derived attribute. The systemsanalyst may document business rules using a number oftools including Structured English, decision tables, decisiontrees, mathematical expressions, etc.Figure I is an illustration of a simple order form. Given

this order form, we identify several attributes included onthe order form. These include Customer Number,Customer Type, Mailing Number, Customer Name, etc.Figure 2 is a list of the initial set of attributes included onthe order form. Included in figure 2 is the number ofoccurrences of each attribute on the form.

Our example includes several object-level derived attributeswhich will become services in the completed model.(I)We compute the extended price of an order item bymultiplying the quantity times the price. As a result,Extended Price is an object-level derived attribute since it iscomputed using attributes from a single instance of theclass and related classes. We replace the Extended Priceattribute with the Compute Extended Price service.(2)Compute the total order amount by adding the ordersubtotal and shipping and handling; we replace the TotalOrder Amount attribute with the Compute Total OrderAmount service. (3)Compute the discount by multiplyingthe total order amount by the discount percentage (from the

2. Group the attributes into classes. The systems analyst

groups attributes into classes based on their relationship toproblem-domain objects. If the systems analyst has accessto existing organizational data models, the analyst may usethese data models as a guide when grouping attributes intoclasses. The systems analyst creates a derived-object model

template depicting the initial classes.1"*-"'

743

Customer class); we replace the Discount Amount attributewith the Compute Discount Amount service. (4)Computethe discounted order amount by subtracting the discountamount from the total order amount; we replace theDiscounted Order Amount attribute with the ComputeDiscounted Order Amount service.

BENEFITS AND COSTS OF THE BUSINESS

MESSSAGE ANAL YSIS TECHNIQUE

Because BMA T models business messages in a logical andgraphical form, the organization realizes several benefitsfrom using this technique. First, the systems analystproduces a graphical, logical model of the message whichdescribes the content of a message that may be presentedusing a variety of mediums (e.g., textual or graphical) or betransmitted across a variety of channels (e.g., printed orcomputer network). As a result, the logical specification isreusable. When prototyping interfaces and businessmessages, system designers may use the derived-objectmodel to ensure that all required attributes are availableand to design queries to retrieve the needed data. Second,the systems analyst, by carefully studying each message,may better understand the purpose of each businessmessage and its data or information. Third, the systemsanalyst describes the organizational data model andbusiness messages using the same modeling notation. Thisleads to easier and more complete understanding on thepart of the end-user, resulting in a more completevalidation of the input, output, and internal data flowrequirements of the information system. Also, this enablesthe systems analyst to ensure more easily that theorganizational data model includes all classes, attributes,relationships, and services necessary to support input andoutput requirements. Finally, the systems analysisidentifies the classes and services required by each businessprocess that uses or produces a business message. Since aparticular business process typically uses or produces aspecific business message, the derived-object model is auseful mechanism for identifying the data required by thebusiness process.

6. Identify class-level derived attributes and services.Class-level derived attributes occur with one-t()-manyrelationships. The systems analyst replaces the class-levelderived attribute with a service and produces a specificationof the business rules necessary to compute the value of thederived attribute.

7. In our example, as already discussed, an order iscomposed of order items. We compute the order subtotal bysumming the extended price for each of the order items thatmake up the order. From this, Subtotal is a class-levelderived attribute since it is computed using potentiallymultiple instances of the Order Item class. We replace theSubtotal attribute with the Compute Subtotal service in theOrder class. Figure 5 is our final derived-object model.

8. Construct a model of the object interactions necessaryto implement the services. The specification of servicelogic reveals a set of object interactions implemented asobject message connections; as a result, the systems analystmay use a scenario, fence diagram, event trace diagram,etc. to describe the object interactions related to thebusiness message..

In our example, various objects interact when computingthe order charges. We use an event trace diagram[Rumbaugh, et a1199l] to depict these interactions amongthe various objects. To illustrate, an Order asks a relatedOrder Item to compute its extended price. The Order Itemasks the related Product for the price of the item. TheProduct sends the price to the Order Item. The Order Itemcomputes the extended price and sends the extended priceto the Order .The Order also interacts with the Customer toget the Customer's discount percentage. Figure 6 is ourevent trace diagram for the order fonn.

As with any systems analysis technique, there are potentialcosts associated with BMA T .First, producing a derived-object model for each business message takes time.However, since most business messages used by anorganization include similar classes, attributes, andrelationships, as the systems analysis process progresses,the analyst should require less time to analyze eachadditional business message. Second, BMA Tis not asubstitute for other forms ofproblem-domain analysis. Thesystems analyst must still apply other techniques to producethe full organizational data model. However, BMA Tprovides a relatively simple method for identifying classes,attributes, relationships, and services; as a result, it is anefficient way to identify a large portion of an organization'sdata requirements.

Upon completion of the BMA T process the systems analysthas. produced a derived-object model for the businessmessage. The derived-object model provides a reusablespecification of the logical structure of the businessmessage (e.g., an order message). The model identifies theclasses needed to handle the business message, thestructural relationships among the classes, and the servicesassociated with the classes required to process the businessmessage. Once the end-user validates the model, thesystems analyst may use the model throughout the systemsanalysis and design processes.

REFERENCES

References and figures are available on request from Donna

F. Davis.

744