Tartan: Interweaving objects with rules in information systems development

TarTan: Interweaving Objects with Rules in Information Systems Development

Danny C. C. Poo and Shwu-Yi Lee Department of Information Systems and Computer Science, Faculty of Science, National University of Singapore, Lower Kent Ridge Road, Singapore 0511

This article recognizes the benefits of using an

object-oriented framework to modeling information

systems. It also recognizes two. limitations in the pre-

sent application of the technique which are not ade-

quately addressed in the current development meth-

ods. They include the lack of an unambiguous and

systematic approach to object identification and the

insufficiency of the object-oriented approach to pro-

vide for changes in domain policies in information

systems specification. This article aims to address

these two limitations. The approach we discuss is

based on an object-oriented framework for structuring

information systems and a rule-based representa-

tional scheme for representing domain policies. The

benefits of this marriage of objects and rules are also

discussed in this paper.

1. INTRODUCTION

The benefits of an object-oriented structure to build- ing systems have been recognized and generally ac- cepted. These include maintainability, reusability, and improved software structure (Meyer, 1988; Booth, 1991; Jacobson, 1992). However, the present application of the object-oriented technique still suffers from two limitations:

1) the lack of an unambiguous and systematic approach to object identification,

2) the insufficiency of the approach to provide for changes in domain policies.

Object identification is perhaps the most impor- tant activity of the object-oriented approach to de-

Address correspondence to Dr. Danny C. C. Poe, Department of Information Systems and Computer Science, National Uniuersi~ of Singapore, Lower Kent Ridge Road, Singapore 051 I

veloping information systems. Objects are the funda- mental elements that form the framework of an application system developed using the object-oriented approach. The identification and selection of inappropriate objects in the analysis phase would lead to a system architecture that reflects the poor decisions made, and this could have an adverse impact on the maintainability of the system. It is thus imperative for any good object-oriented method to provide an unambiguous and systematic approach to object identification.

Traditionally, domain policies are embedded within the definition of processes or data in the form of low-level programming code. This approach of “hard-coding” the policies suffers from a number of drawbacks (see vanAssche et al., 1988; Tsalgatidou and Loucopoulos 1991). Firstly, because the order of the procedural statements forms the logic of the program, programs become complex and unmanage- able. Secondly, it is difficult to check the correctness of the program as few people with the knowledge of the domain policies will be able to understand the implementation. Thirdly, if domain policies are represented as procedural statements, the order of execution of the policies has to be pre-determined. Finally, since the program uses procedures to carry out these policies rather than containing the semantics of the policies as well as how and when they will be activated, maintenance of programs could be difficult. Any changes to the domain policies would thus require alteration of the program logic, and this could be costly.

With user requirements on information systems becoming more and more sophisticated, the need to provide more for domain policies representation be- comes more and more essential. Other researchers

J. SYSTEMS SOFTWARE 1996; 33:3~14 0 1996 by Elsevier Science Inc. 655 Avenue of the Americas, New York, NY 10010

0164-1212/96/$15.00 SSDI 0164-1212(95)00119-L

4 J. SYSTEMS SOFTWARE 1996; 33:3-14

and practitioners (vanAssche, 1988; Loucopoulos, 1989; Tsalgatidou, 1991; Sanders, 1992) have also indicated such a need.

This paper will discuss an object-oriented structure used in the modeling of information systems. Structural provision for modeling domain policies will also be discussed. Finally, it will show the interweaving of objects with rules (the representational scheme for domain policies). This paper will also highlight how domain policies could be interwoven with objects to provide for a more flexible environ- ment for software changes. This paper is organized in the following manner:

Section 2 discusses the object-oriented structure.

Section 3 discusses domain policies.

Section 4 discusses the benefits of using a rule- based representational scheme for specifying domain policies. It will also discuss how rules (which are representations of domain policies) could be interwoven with objects.

Section 5 concludes the discussion.

2. THE TARTAN OBJECT-ORIENTED STRUCTURE

In this section, we will discuss the various types of objects that formed the object-oriented structure in TarTan’.

Altogether, there are five types of objects under consideration: the domain objects, the supporting objects, the agent objects, the port objects, and the interface objects. The object identification approach in TarTan begins with the identification of events and the functions that a system is required to support. We do this by drawing an augmented context diagram. Events and functions are identified by indi- cating the event triggers and functional requests in the context diagram. An event is an actiuity that occurs in the real world. The occurrence of the event is reflected in the system via an event trigger. The completion of an event causes a change in the state of the system (Poe and Lee, 1994). For each event trigger, an event script is described. For each functional request, data values/outputs would be derived. Ful- filling a functional request does not change the state

’ TarTan is a woolen cloth with stripes of various colors cross- ing at right angles. It is as though these colors are intemouen with one another. The name TarTan is not an acronym of some other words but is a representation of the interweaving concept in- herent in this kind of fabric pattern. TarTan here suggests an intenveaving of objecrs and rules for structuring information systems.

of the system. Similarly, a function script is described for each functional request. Based on these scripts, three types of objects are identified, i.e.,

Poo et al.

domain objects, supporting objects, and agent objects. While event and function scripts will help a developer to appreciate what a system is, use scenarios will define how a system will be used. Through use scenarios, further objects will be identified; they include port objects. Object interactions are defined through use scenarios. The objects identified through event, functions, and use scenarios thus form the framework of the application system. A thorough discussion on how these five types of objects are derived is beyond the scope of this paper (see Poo and Lee, 1994 for more details).

2.1 Domain Objects

Domain objects are those objects in the domain whose states collectively form the state of the system. In other words, they are the objects whose state changes are of concern to the system. A state of a system describes how far the system has come into execution, as well as the potential future execution, similar to what Jacobson refers to as computational state (Jacobson, 1992). A system is built up incre- mentally in the TarTan approach. Objects are incre- mentally identified and defined.

Let us consider an Order-Processing application domain, used as an example application domain in this paper. The chief task of the Order-Processing System is to assist in the order processing of products that a company carries. It keeps track of the products that are available for sales as well as the sales records of the staff of the company. The system will permit the acceptance of purchase orders made to the vendors of the company, generating the hard copy of the purchase orders. It will keep track of the inventory of the products that are available in the company. It will also keep record of the sales perfor- mance of the sales staff in the company. This is to enable the monthly computation of the commission due to the staff. On top of this, the system enables on-line, point-of-sales to be made by the customers at the shop floor. It will generate the sales receipt of the sales transaction made by the customers, and at the same time, update the stock level of the products. Furthermore, the system has to assist top man- agement in decision-making. This is done through the generation of the various reports based on the information within the system.

Figure 1 shows the definition template for a domain object called Product in the Order-Processing

Interweaving Objects With Rules

Object Claw Product hberits From: Iabcrits By Attributes: pmduct number product description quantity on hand EOQ ROP unit price selling price

Type: Domain object

Action: (xderItwn(quaaW m~l~quantity) ~vc(quandty) Refund(quandty) ~chwJe(qww Wlild)ff(qtIatttity) Sell(quatttity)

quaotity on m-da tmduct hme Class Service: I _.

Link Attributes: vendorid ( sales UansactlOn numba )’

Domain Policies:

Figure 1. Object Template for Domain Object Product.

System. The template contains the following information:

* the domain object name

= the object type, i.e., domain object, supporting object, agent object, or port object

l the attributes of the object

l the link attributes of the object

l the actions of the object

l the class services of the object

l the instance services of the object

l the domain policies attached to the object.

Identification of domain objects are based on the participating objects in the events that a system supports. A participant of an event is one that causes a change in the state of a system. The participating objects are the domain objects of the system. We capture the participation of a domain object in an event as its action. An action is an operation of an object that causes a change in the state of the object if it is successfully executed. For instance, in the event Staff sells Product in the Order-Processing System, the action identified is Sell. It involves the participation of the domain objects Staff and Product. In other words, both these objects will have its corre- sponding definition of the action Sell.

The attributes of a domain object are also identified based on the events and functions of a system. Consider again the event, Staff sells Product. This event requires product number, quantity sold, and selling price which are information associated with the Product object. This information thus represents

J. SYSTEMS SOFTWARE 5 1996; 33:3-14

the data attributes of the Product object. Product number is included to identify the specific instance of Product. Quantity sold and selling price of product are the data required for the event to be carried out.

Besides identifying the attributes of an object, we also identify the relationships among the objects. For each event or function, an object-relationship diagram is constructed. Constructing the object-relationship diagram in this manner allows the analysts to focus on a smaller subset of objects in an application domain. For each relationship, we identify link attributes to connect the objects in the relationship. A link attribute is the key that uniquely identifies the other object connected with the relationship. In this example, the link attribute for Product is sales transaction number. Figure 2 shows the object relationship diagram based on the event Staff sells Product.

For each domain object identified, a state-transition diagram is also constructed. This diagram shows the local dynamic behavior of domain objects. A state-transition relates the present state of a domain object to its possible future states. By considering the state-transitions, we would more accurately define a domain object since a domain object does not conduct its activities in a random manner in the real world. Take, for instance, a Product object and a Staff object in the Order-Processing System. A Prod- uct must be ordered before it can be received at the warehouse. Similarly, a Staff must join the company before she can carry out the sell action. Figure 3A shows the state-transition diagram of the domain object Product in the Order-Processing System. It shows the set of states that Product can take, and the actions that would bring it to a particular state given its present state. Any action that does not conform to any of the state-transitions is considered invalid. A valid state-transition for Product is (ORDERED, Received, RECEIVED); that is, if a Product object is in the state ORDERED and the action is Receive, then the object will proceed to the RECEIVED state upon the successful completion of the action.

Figure 2. Object-Relationship Diagram for the Event Staff Sells Product.


Poo et al.

Refucd~ End v

START ORLXRED REcEmEu PRODUCT REWNDED FaD

I ACTiONS I

I 4

Figure 3. (a) State-Transition Diagram for the Domain Object Product.

ckenl slate Action Nexl Sate

START order ORDERFXI

ORDERED Receive RF.cElvED

RECEIVED ROdUCf-ACthI PRODUCT-ACTION

*PRODUCT-ACTION ROdUCt-ACthl PRODUCT-ACIION

PRODUCI-ACTION R&d REFUNDED

RE&iJNDED M EM)

Figure 3. (b) State-Transition Table for the Domain Ob- ject Product.

Each state-transition diagram can be re-defined in a tabular form such as that in Figure 3B. Besides actions, a domain object has other operations; these operations do not update the state of the object and are known as services. Services can be distinguished as class services or instance services. A class service is an operation that belongs to a class but not the instances of the class. Generally, a class service defines an operation that acts on instances of the class. An instance service, on the other hand, is an operation that is applicable only to the instance. For the event StafSsells Product, we identify ProductEx- ists(product number) as a class service of Product. This service determines if a product object having a particular product number exists in the system. An instance service for a Product object might be Get- SellingPrice or GetProductDescriptionO. These services will return the selling price and product description of a particular product, respectively.

An operation of a domain object can thus be distinguished as an action, a class service, or an instance service in TarTan. Distinguishing operations as actions or services has a number of advantages:

1. Better abstraction Actions and services are abstraction of operations. By way of their definitions, they will help a developer in identifying the appropriate operations for an object, a task often neglected by most development approaches (see Yourdon, 1979;

Coad, 1989; Coad, 1991; Rumbaugh, 1991; Jacob- son, 1992.) Enhance changes to operations With actions and services, it is possible to associate a requirement change to an operation. A change connected with a functional requirement will be linked to a change in service, whereas a change that is associated with the state of a system will affect a change in an action. Enable the definition of domain policies on objects Domain policies are associated with events, and since actions are representative of events, domain policies would therefore be defined on actions.

2.2 Supporting Objects

Supporting objects, as the name implies, play a sup- portive role in the domain. Their presence in the system does not change the state of the system. They are specified and defined to support the processing of a system. For instance, in the event Staff sells Product, there is a need to keep the information of the sales transactions that a staff is responsible for (to compute the commission due to the staff at the end of the month). Thus, a new object called Sales Transaction is introduced in the event (see Figure 5). This object keeps information of the sales transactions of a customer that the staff is serving. Changes made to the attributes of this object are for administrative purposes only, and thus do not affect the state of the system. Figure 4 shows the relationships between Sales Transaction and the domain objects Staff and Product. Figure 4 shows the definitional description of the supporting object Sales Transaction.

The definitional description of supporting objects is similar to that of domain objects except that a supporting object does not have actions and thus, does not have domain policies attached to it. The definition process proceeds by examining the static

Figure 4. Object-Relationship Diagram for the Event Staff sells Product.

Interweaving Objects With Rules

Object Class: Sales Transaction Inherits From: Inherits By : Attributes: sales mmaction number sates date total selling price

Link Attributes: { pmductnumber

quantity sold I’ mffc&

Type: SUPPOtinR Obiect

I

Class service: SalesTransactionExists(poduct number) CkckStaffSai~Trtion(staff code) CheckSalesTransrrtion(date~ CheckSalesTransaction@Biod)

SeWiCe: -tSo ComputeTotal ComputeLineTotalO t%CkFWdUCtLill~) ROdUCeRBQiPtO

Figure 5. Definition of Supporting Object Sales Trans- action.

information that a supporting object contributes to the execution of an event or a function.

Supporting objects do not have actions since their operations do not cause any change in the state of a system. Supporting objects are distinguished from domain objects to provide analysts a level of abstraction for identifying objects. In this way, there are some means by which analysts could identify appropriate objects from a given domain description- something that is lacking in most contemporary development methods.

2.3 Agent Objects

In the assignment of responsibility for the manage- ment of functions, a function that pertains to one object type is assigned to that object type. For example, the functional request production of sales receipt. The output data flow connected with this functional request is made up of information such as line-item for each item sold, the date of sales, the staff that close this sales transaction, etc. This request is directly connected with Sales Transaction object. Since this function can be satisfied directly in Sales Trans- action, we shall specify it within the definition of Sales Transaction. We do so by defining a service as part of the Sales Transaction’s set of operations.

However, for a functional request that involves more than one object type, another object-possibly of a different type-is introduced to handle the execution of the function. We called this type of object an agent object. An agent object is an object that renders services on behalf of other objects. It acts as a controller responsible for the collection of information. For example, the functional request production of weekly sales report in the Order-Processing System involves the Product object as well as the Sales Transaction object. Thus, an agent object, Weekly Sales Report, is introduced to handle the function. It is responsible for the collection of infor-

J. SYSTEMS SOFTWARE 7 1996; 33:3-14

mation pertaining to the sales of all the products for the week. It also computes information such as total sales, profit, total quantity sold for each product types, etc., and generates this information in a for- mat required by the user. To achieve these, the Weekly Sales Report agent object has to interact with the Product object as well as the Sales Transac- tion object.

2.4 Port Objects

A port object is an object that connects a user to a system. It is an interface between the real world and the system. It receives inputs from the users, calls on the respective objects with the inputs and channels for whatever outputs the system may have for its user to the user. Port objects are introduced in order not to let changes in the interface of a system affect the definition and design of domain, supporting, or agent objects. This is necessary because changes to a system interface are common and should typically affect only the port objects (Jacobson, 1992).

A port object may be decomposed into its constituent objects known as interface objects in Tar- Tan. In order not to complicate the interaction diagram, only interactions between port objects and domain and supporting or agent objects are shown in the diagram. The leveling concept of the data flow diagramming technique (Yourdon, 1979) is used to depict the composition of port objects. In the leveled diagram, interface objects and their interactions will be depicted. For example, the port object Sales Window is decomposed into a set of interface objects such as a Display Box object, a Data-Entry object, a Selection List object, etc.

The decomposition of the port object begins with an initial screen design. This is done through interactions with the users of the system. Figure 6 shows an example of a screen design. Using the screen design, port objects such as Sales Window are decomposed into their constituent interface objects. Figure 7 shows the result of the decomposition process for Sales Window. Port objects are introduced in use scenarios to handle the interface that the system presents to the users of the use scenarios. The interaction of objects involved in a use scenario is illustrated using an interaction diagram (see Fig- ure 8 for an example of an object-interaction diagram) which is a graphical representation of the communications among the objects of a system. In this way, designers can, in principle, validate the structure of the use scenario (Jacobson, 1992). In Figure 8, Sales Window is a port object. Figure 9

8 J. SYSTEMS SOFTWARE Poo et al. 1996; 33:3-14

StaRNumber: I-1

Da&z I J

Figure 6. Initial Screen Design of Sales Window.

shows the leveled object-interaction diagram for the port object Sales Window.

In summary, the TarTan structure comprises of five object types, namely domain objects, supporting objects, agent objects, port objects, and interface objects.

3. THE TARTAN RULE-BASED STRUCTURE

Domain policies in TarTan are defined in terms of rules. In this section, we will discuss how domain policies are interwoven within the object-oriented structure.

3.1 Domain Policies

In addition to data and processes, an information system specification also includes the definition of domain policies (or business rules). To a large ex- tent, domain policies determine the behavior of an information system. Domain policies may be classi- fied into three categories: Control, Constraint, or Derivative.

Control policies. A control policy is one that defines a system’s flow of control upon the completion of an event. For example, a sales transaction in an Order-Processing System is an event with two partic- ipants, namely a staff and the products sold. The control policy associated with this sales transaction

Figure 7. Decomposition of Sales Window Port Object into its Interface Objects.

event might be: Upon completion of a sales transaction, add the line-item to the sales transaction. This policy specifies a service to be performed, i.e., adding the line-item information of the product sold when the sales transaction completes; this policy applies to the Staff object. A control policy therefore specifies a service (or an operation) to be performed when an event completes successfully.

A control policy could alternatively specify a trigger to another event upon the successful completion of the current event. Consider the staff termination event to illustrate this point. A control policy that is associated with this event might be: when staff leaves the company, and if the staff has outstanding commission due, pay commission due to him. This control policy on the event ‘when a staff leaves the company’ is associated with a condition ‘if the staff has outstanding commission due’ and an event ‘pay commission due’. Thus, the event staff leaves company may trigger another event, namely pay commission due, via a control policy.

In general, the successful completion of an event could trigger either a service or another event, and these could be specified within a control policy.

Constraint policies. Besides determining the flow of control, domain policies also impose constraints upon the integrity of a system. Such policies are known as constraint policies. Constraint policies could impact an entity definition in two ways. Firstly, since entities in the real world participate in events in a set pattern as their definition dictates, similar behavior of entities must be maintained in the system. This is achieved in the definition of constraint policies. The state of the system would thus be

Interweaving Objects With Rules J. SYSTEMS SOFIW’ARE 1996; 33:3-14

LEGEND:

Figure 8. Object Interaction Diagram for the Use Scenario Sales Transaction.

consistent with that of the real world. For instance, a product must be ordered before it can be received at the warehouse; a product must be received before it can be sold; a staff can only sell after he has joined the company. These conditions are ensured by the use of constraint policies. Any action imposed on a domain object that does not conform to the pattern is considered as a violation of the constraint and

should not be allowed to take place. This would ensure the robustness of domain objects (Poe, Au- gust 1993).

Secondly, in defining the state of a system, constraints are also enforced upon the execution of events. Such constraints further ensure that only appropriate events can take place. Consider for instance the following: Before a Product can be sold,


Poo et al.

Shff

Figure 9. Levelled Object-Interaction Diagram of Sales Window Port Object.

ensures that there is sufficient quantity to meet the sale. A constraint is therefore enforced on the Staff sell Product event. The product can only be sold provided there is sufficient quantity to meet the sale.

Derivative policies. A policy may also derive new information from other information. The new information could be derived in two ways: 1) via a computation, or 2) inferred from other known facts. The former type of policies is known as computational policies. The latter are inferencing policies.

An example of a computational policy is given below: Commission = Staff Commission Rate

* Chargeable Commission Rate

* Staff.SalesAmount * (1 - Bonus Rate) This computational policy specifies the derivation of commission for a staff based on several factors, namely Staff Commission Rate, Chargeable Com- mission Rate and Staff.SalesAmount. These factors can either be derived from object attributes, or they could be derived from yet another computational policy. For instance, Staff.SalesAmount can be derived from the SalesAmount in a Staff object. On

the other hand, Bonus Rate is derived from another computational policy defined as follows:

Bonus Rate = (O.O05*Total Sales)/

(Total number of staff)

We notice that computational policies derive new information from known information (constants or data values); the derived information may in turn be used to derive further information and so on. Thus, there exists a chain that connects all relevant data attributes or computational policies in the derivation process.

In addition to computing values, derivative policies may also infer new facts from known facts. This type of policies is known as inferencing policies. An example of a inferencing policy belonging to Prod- uct:

ProductIsUnderStock IF QuantityOnHand

< ReorderPoint

ProductIsUnderStock is inferred from QuantityOn- Hand and ReorderPoint. ReorderPoint is derived from a separate computational policy. ProductIs- Understock is true if QuantityOnHand (a Product

Interweaving Objects With Rules J. SYSTEMS SOFTWARE 11 1996; 33:3-14

object’s attribute) is less than the derived value ReorderPoint. This example suggests that an inferencing policy may be chained to other computational policies.

Computational policies may also be attached with conditions such as:

BonusEarnings = Total Bonus/

(number of eligible staff) IF

StaffSalesAmount > TargetSalesAmount

BonusEarnings = 0 IF Staff.SalesAmount

= TargetSalesAmount

The computation for BonusEarnings depends on the condition as specified in the IF part of these joint derivative policies.

3.2 Specification of Domain Policies in an

Object-Oriented Framework

The behavior of domain objects characterizes the state of a problem domain (Poe, November 1993a). Thus, domain policies are associated with domain objects. The other three types of objects do not have domain policies, as they do not characterize the behaviour of the system.

The three categories of policies discussed above are applicable on the three components of the domain objects, namely, the data, actions, and services. Let us now look at how each category of policy is related to the domain objects.

Constraint policies. As mentioned in Section 3.1, there are two types of constraint policies. They con- strain the actions of a domain object. The first type of policy ensures the integrity of a domain object by insisting on the sequence by which its action can be executed. This kind of policy is known as Object Integrity Policy. Object integrity policy of a domain object is modeled using the state-transition diagram (see Figure 3A).

The second type of constraint policy are constraints that a domain object must satisfy before its action can be executed. This ensures that the object behaves in a manner consistent with its definition. It is related to the conditions before an action of a domain object can execute. We call this type of constraint policy the Pre-Action Conditional Policy. Pre-action conditional policy is modeled in the interaction diagram (see Figure 8) as a service to be performed (if any) before an action can execute. The message, represented by an empty arrowhead, shows the activation of the service prior to the execution of the action. The activated service is connected with

a pre-action conditional policy. With this type of message, we can express the fact that the action can only take place when the condition (realized through a service) is satisfied.

Control policies. Control policies specify the services to be performed when an action completes. The service may further trigger other events or services. Since this type of policies triggers services after the completion of an action, it is thus known as Post-Action Triggering Policy. Post-action triggering policy is modeled in the interaction diagram as a service to be performed (if any) after the completion of an action. The message AddItem(product number, quantity) (see Figure 81, represented by a dark- ened arrowhead, is an example of a post-action triggering policy. It shows the activation of the service AddItem(product number, quantity) after the successful completion of an action.

Derivative policies. Derivative policies derive new facts from known facts. The known facts are based on the state of objects. In other words, a fact is derived from data values of objects. A derivative policy would derive either a numerical or boolean fact depending on the way the information is derived. A computational policy would derive a numerical fact while an inferencing policy would derive a boolean fact (i.e., taking either a true or false value). Computational and inferencing policies could be defined within actions or services of objects. In other words, derivative policies are modeled during the design of the domain objects and their operations.

An object has an identity, and it is because of this identity that domain policies can be specified and represented. An object identity provides us a focal point by which domain policies can be associated. There are altogether five types of policies within the three major categories of Constraint, Control and Derivative Policies: 1) Object Integrity Policy, 2) Pre-Action Conditional Policy, 3) Post-Action Trig- ger Policy, 4) Computational Policy, and 51 Inferenc- ing Policy.

3.3 Implementation of Domain Policies

Domain policies can be implemented in terms of rules and interwoven within the TarTan object-oriented framework of a system. Representing policies in terms of rules has three advantages:

1) Rules are modular. A rule can be viewed as a modular segment of information about a system (Davis, 1977). The meaning of a policy will thus be described by the


Poo et al.

rule. Hence, changes to policies would be con- fined to the relevant rules.

2) Policies are declarative. The abstraction provided by rules encourages developers to think of the actual specification of policies rather than on how policies are realized in programming operations. That is, it would be up to the circumstance to choose the policies/rules to fire. Therefore, how policies are to execute need not be predetermined during program-development time. The fact that policies are declarative means that they can be described in isolation on their own (Sanders, 1992).

3) It is a more natural way of defining policies. It is more natural to specify policies in terms of rules since users view policies in a declarative manner (vanAssche, 1988; Loucopoulos, 1989).

In the proposed approach, each type of policy is correspondingly represented by a type of rule. This is necessary as the semantic of each policy type is different. There are altogether five types of rule divided into three categories:

1. Derivative Rules a. Inferencing Rules (IR) b. Computational Rules (CR)

2. Constraint Rules a. Pre-Action Conditional Rules (PACR) b. Object-Integrity Rules (OIR)

3. Control Rules a. Post-Action Triggering Rules

Since policies are defined on data, actions, and services, we define rules on data, actions, or services in the implementation too. Rules are thus fired at strategic points in an object definition.

Object integrity rules and pre-action conditional rules. Object Integrity Rules(OIRs) govern the sequence by which actions of a domain object are executed. They are thus fired prior to the execution of an action. If an action satisfies the condition as stipulated by the set of OIRs, the action can be executed. An action will be executed if the other constraint rules, namely Pre-Action Conditional Rules(PACRs), are satisfied. In this way, we define for a domain object the necessary conditions for which the object must satisfy before an action can be performed. In other words, to update the state of a domain object, the client of the object has to comply with the conditions as defined by these rules. These rules maintain the integrity of the domain objects,

An Object Integrity Rule has the following structure:

FROM (current state) WHEN (action) TO (new state)

Figure 3B shows an example of a set of OIRs for the domain object Product.

For each action, there may be one or more Pre- Action Conditional Rules. A PACR takes the following form:

BEFORE (action) CONDITION (conditionlist)

where conditionlist is a list of expressions concate- nated with the logical AND. An expression is either a conditional expression or an operation that returns a boolean result.

An example of a PACR for the Product object is:

BEFORE Sell CONDITION QuantityOnHand

> ReorderPoint

The condition as specified in this PACR states that the product level of the object Product must not fall below its reorder point. This conditional expression will return a boolean result.

Post-action triggering rule. While OIRs and PACRs specify the constraints by which an object must satisfy for an action to be performed, the Post-Action Triggering Rules(PATRs) specify the services to be triggered when an action successfully completes.

A PATR takes the following form:

AFTER (action) (IF (conditionlist))THEN (expression)

The IF part is optional. A PATR of a Staff is:

AFTER Sell THEN AddItem(product number, quantity)

AddItem(product number, quantity) is a service of the Staff object. In this case, the service defines the task for adding the information of the product sold by the staff to the sales transaction object.

This rule brings together the necessary components involved with the trigger, thereby making them more visible in their definition.

Computational rule and inferencing rule. Compu- tational and inferencing rules are defined and triggered from within an action or service of the domain object. An Inferencing Rule(IR) takes the following form:

(consequence) IF (antecedence)

and a Computational Rule(CR) has the following structure:

(result) = (arithmetic expression) (IF (expression))

An IR may chain other IRS or CRs.

Interweaving Objects With Rules J. SYSTEMS SOFIWARE 13 1996; 33:3-14

4. DISCUSSION

In this section, we will evaluate the object-oriented, rule-based structure used in TarTan. We will also examine the benefits of using rules to represent domain policies.

4.1 Benefits of Using Rules to Represent Domain Policies

By representing policies in terms of rules, we raise the level of representation of domain policies. This makes policies more visible than if they had been defined in terms of programming code. This mode of representation enables one to focus on the definition of policy rather than on how a policy is achieved. Another advantage of representing policies in terms of rules is the flexibility in making changes to policies, and since policies are volatile, the advantage could be significant. Furthermore, any change to the domain policies/rules will not involve recompilation of the system since the rules are fired dynamically at runtime.

4.2 Structural Provision for the Interweaving of Objects with Rules

The object-oriented structure used in TarTan en- forces a systematic way whereby the analysts will be guided in the identification of objects relevant to the application domain. It also provides guidelines in the identification of domain policies relevant to the domain objects concerned. Section 3.2 shows how each type of domain policies are modeled and represented in the object-oriented structure.

Having different types of object instead of only one type of object enables an analyst to get a structure that is more adaptable to changes (Jacobson, 1992). The assumption is that all systems will change. Therefore, stability will occur in the sense that all changes will be local, that is, the change will affect (preferably) only one object in the system (Jacobson, 1992). For instance, if the users want to make changes to the type of information in a report, changes are needed in the characteristics of the object(s) that is responsible for the report (this object is likely to be the agent object for the function that generates the report). Thus, there is locality of changes in the system developed with different object types.

The different object types also enables one to associate the domain policies directly to their related entities, i.e., the domain objects. A developer is also able to define a system that maps closely to the description of the domain in the real world.

5. CONCLUSION

On the outset of the paper, we mentioned that there is a lack of an unambiguous and systematic approach to object identification. Also, the traditional object-oriented approach is insufficient for representing domain policies and providing for changes in their definitions. This paper discussed the TarTan approach to system structuring that looks to behavior as the first and principle guide to successful object identification. The approach is based on events and functions as the information sources to eliciting objects from a problem domain. Five types of objects were also discussed in this paper: 1) domain objects, 2) supporting objects, 3) agent object, 4) port objects, and 5) interface objects.

The paper also suggested a rule-based representational scheme for domain policies and discusses how they might be interwoven within the object-oriented structure. Domain policies are interrelated to objects via the definitional semantics of data, actions, and services. The benefits of the TarTan approach to systems development were also discussed.

ACKNOWLEDGMENT

The authors would like to acknowledge the financial support granted by the National University of Singapore (grant RP910689). They are grateful to the university in granting them the opportunity to carry out the work as described in this paper.

REFERENCES

Booth, G., Object-Oriented Design, The Benjamin/Cum- mings Publishing Co., 1991.

Coad, P., and Yourdon, E., Object-Oriented Analysis, Pren- tice-Hall, 1989.

Coad, P., and Yourdon, E., Object-Oriented Design, Pren- tice-Hall, 1991.

Davis, R., and Buchanan, B., Production Rules as a Rep- resentation for a Knowledge-Base Consultation, Artifi- cial Intelligence 8, 15-45 (1977).

Jacobson, I., Object-Oriented Software Engineering, Addi- son-Wesley, 1992.

Loucopoulos. P., The RUBRIC project-Integrating E-R, Object and Rule-Based Paradigms, in Workshop session on Design Paradigms, European Conference on Object- Oriented Programming (ECOOP), Nottingham, UK, July 10-13, 1989.

Meyer, B., Object-Oriented Software Construction, Prentice-Hall International, 1988.

Poo, D., Object-Oriented Rule-Based Software Engineer- ing, in Proceedings of the Joint Conference on Software


Poo et al.

Engineering, Fukuoka (Japan) November 1993a, pp. 31-44.

Poo, D., Implementing an Evolutionary Structural Soft- ware Model, Journal on Systems and Software, Vol. 22, No. 2, 81-90, August 1993.

Poo, D., and Lee, S. Y., TarTan: An Object-Oriented Information System Development Method, Department of Information Systems and Computer Science, Faculty of Science, National University of Singapore, Lower Kent Ridge Road, Singapore 0511, 1994.

Rumbaugh, J., Blaka, M., Premarlani, W., Eddy, F., and Lorensen, W., “Object-Oriented Modeling and Design,” Prentice-Hall, 1991.

Sanders, P., and Short, K., Declarative Analysis in Infor- mation Engineering, in CASE: Current Practice, Future

Prospects, (K. Spurr and P. Layzel, eds.), Wiley Profes- sional Computing, 1992, pp. 183-204.

Tsalgatidou, A., and Loucopoulos, P., An Object-Oriented Rule-Based Approach to the Dynamic Modeling of In- formation Systems, in Dynamic Modeling of Information Systems, (H. G. Sol and K. M. vanHee, eds.), Elsevier Science Publishers B.V. (North Holland), 1991.

vanAssche, F., Layzell, P. J., Loucopoulos, P., Speltincx, G., Information Systems Development: A Rule-Based Approach, Journal of Knowledge-Based Systems, 227-234 (September 1988).

Yourdon, E., and Constantine, L., Structured Design: Fun- damentals of a Discipline of a Computer Program and Systems Design, Yourdon Press, 1979.

Documents

Tartan: Interweaving objects with rules in information systems development