Type and inheritance theory for model management

Type and inheritance theory for model management

D0mm Supp0rt ...... I( ELSEVIER Decision Support Systems 19 (1997) 53-60 Type and inheritance theory for model management Jian Ma * Department ...

541KB Sizes 0 Downloads 52 Views

D0mm Supp0rt ......

I(

ELSEVIER

Decision Support Systems 19 (1997) 53-60

Type and inheritance theory for model management Jian

Ma

*

Department of lnfi~rmation Systems, City University of Hong Kong, 83 Tat Chee Avenue, Kowloon, Hong Kong

Received 21 August 1995; revised 22 June 1996; accepted 22 August 1996

Abstract

Model management is one of the important research areas in decision support systems (DSS). Similar to that in data management, the research activities in model management should include the representation of model base structures and design of model base systems. Object-oriented methods have been used for the representation of model base structures. Based on a proposed object-oriented framework, this paper presents the use of type rules and inheritance theory for the design of model base systems. Examples are used to illustrate that the proposed design theory can help to reduce redundancy and avoid inconsistency for the design of model base systems. Keywords: Decision support systems; Model management;Model base systems; Object-oriented specification and design; Type; Inheritance

theory

1. Introduction

By definition, a DSS is a software system designed to support semistructured or unstructured decisions in order to improve the effectiveness of decision making [5]. One of the most commonly accepted frameworks for DSS [16] is to classify it as comprising three sets of capabilities: data management capability, model management capability, and the management capability for an interface between users and the system. Data management is thought of as a well established research area because of the maturing technology in database modeling, database design and database management systems. However, model management is a relatively new field of research. Three important topics in model management

* Fax: (852) 27888694; E-mail: [email protected]

include representation of model base structures, design of model base systems and the organizational environment of model management systems [1,2]. Several approaches have been proposed for the representation of model base structures. The relational approach [2] views a decision model as a virtual relation between input and output domains. The entity-relationship approach [6] treats a decision model as an entity comprising a number of attributes and an interface among entities as a relationship. These two approaches make use of the existing methods, but fail to wholly support the reuse of decision models. Whereas the model abstraction approach [7] adopts the concept of data abstraction in modern programming languages and encapsulates data objects, procedures and assertions within a model abstraction. It separates the function specifications from their implementations in a decision model, but the relationships among decision models are not well specified. The structured modeling approach [8]

0167-9236/97/$17.00 Copyright © 1997 Elsevier Science B.V. All rights reserved. PII S0 167-9236(96)00052- 8

54

J. Ma / Decision Support Systems 19 (1997) 53-60

employs a hierarchically organized, partitioned and attributed acyclic graph to represent relationships in decision models. One of the hot research topics in DSS today is the application of object-oriented methodology to model management. Current objectoriented approaches [10,15] view a decision model as a collection of objects which perform the various model management functions by receiving and responding to messages. These methods make use of the concepts in object-oriented programming 'languages. However, they emphasize the implementation details and lack a design theory to discover the inheritance relationship for the reuse of decision models. The emphasis of this paper is on the design of model base systems. Thus the static properties or structures of decision models and the relationships among them will be studied. One of the current trends for the design of model base systems is the object-oriented approach. Burslal and Lamson [3] applied an algebraic approach to represent the concepts of data abstraction and information hiding. By definition, an algebra is formally a mathematical entity composed of sets of values and operations on these values. Signature is a method to define an algebra, which is a declaration of the types, constants and operations of interest. The main restriction of the algebraic approach is that it is first order; that is, functions are not first class values and can not be passed as inputs to other functions, returned from functions, or stored within data structures. In order to provide 'a greatly enhanced degree of expressive power, a form of second order A-calculus was introduced. Mitchell and Plotkin [14] used an extended version of the second order A-calculus, called SOL, to represent data abstraction. Cardelli and Wegner [4] extended the second order A-calculus by introducing universal qualifications and information hiding (packaging) to model abstract data types and bounded qualifications to model subtypes and type inheritance. As a result, a language called FUN has been designed. The second order typed A-calculus supports the specification of data abstraction and information hiding, but it lacks the ability to specify inheritance relationships between two classes. In model management, a decision model is an abstract simple representation of a decision making process, which consists of a set of variables and

functions specifying the relationship among these variables [9]. In the proposed object-oriented model base structure [12,18], a class is a conceptual schema specifying a decision model. Based on a set of common data structures, it groups functions together in a fixed set. Class is the realization of data abstraction and information hiding concepts, within which functions are specified using typed h-calculus. Inheritance is then a mechanism to allow a new class to be defined by inheriting function properties from existing ones. Based on the proposed object-oriented framework, this paper proposes the type inheritance rules and inheritance theory for the design of model base systems.

2. Object-oriented framework for model base structures A type is a set of values with certain properties. A function is then a mapping from one type into another. In the notation f : t r ~ r, the expression " t r z " is called the type of function f, which denotes the set of all functions from type tr to type r. Typed A-calculus is used as a formal language to specify functions in the proposed object-oriented framework [11,12]. A class is a conceptual schema which groups relevant typed A-expressions together to specify a decision model. It is formally defined as: C = { e I , e 2 . . . . . en}, where C is the global name of the class and each e i (1 _< i _< n) is an expression local to C. Inheritance is a mechanism to allow a new class to be defined by inheriting function properties from existing ones. Let C' be a new class which makes use of the expressions from existing classes CI, C:, . . . . C n in a model base system, then it can be denoted by: !

C' = { e'l , e 2 . . . . . e ' } inherit from C l , C 2 . . . . . Cn, where each e'i (1 _< i _< m) is either an incremental modification of the corresponding expression in class C~ (1 _< i _< n) or an expression which never appears in its superclasses.

J. Ma / Decision Support Systems 19 (1997) 53-60

In the proposed object-oriented framework, every expression is defined to be local to a class. Therefore the same expression name may appear in more than one class. In order to avoid this ambiguity in the inheritance case, the expression name should be explicitly distinguished by concatenating class name with " . " and the expression (e.g.C.e) when necessary. Example 1. Inventory plays a vital role in the operation of an enterprise. It should be efficiently managed so that the total cost could be reduced. In the following inventory control model [16], we assume that the demand is known and steady. The notations used are: Let

Q

=

lot size per order, Q* = optimal lot size per order, R = units required (demand) per unit time, Co = cost of ordering or setup per order placed, Ch = cost of holding a unit of inventory per unit time, C(Q) = total relevant cost (ordering + holding) per unit time for lot size Q. For a simplest optimal lot size model, the total relevant cost is decided by: R c(o)

=

Q

+

7.

Then the optimal lot size and the optimal relevant cost are determined by: Q* =

¢ 2RCO

C( Q* ) = 2~-C--ooCh = ChQ* . Thus the simplest optimal lot size model can be specified in class INVS: INVS = { C O: REAL; C h : REAL; Q * : REAL ~ REAL; Q* = AR.SQRT((2* R* Co)/Ch), CQ * : REAL ~ REAL; CQ* = AR.SQRT(2 *R* C O C h)

}. Where SQRT is a built-in function, Q* is the function to compute the cost of holding a unit of

55

inventory per unit time and CQ" is the function to compute the total relevant cost per unit time for lot size Q. In reality, the inventory history should be considered. As a result, the problem refers to the optimal lot size model with uniform replenishment. Example 2. Let R' = maximum production possible per unit time ( R ' > R), and v = 1 - R / R ' , the solution then becomes:

/ Q* = 1[

V

2RC o Ch U

'

C( Q* ) = ¢2RCoCh v = ChVQ* The improved inventory control model can inherit properties from class INVS and is then specified in class INVUR:

INVUR = {

Q* : (REAL --* REAL) × REAL REAL; Q* = AINVS.Q*, Av.(INVS.Q*/SQRT(v)), CQ* : (REAL ~ REAL) × REAL REAL; CQ* = AINVS.CQ*, Av.(v* INVS.CQ * ) } inherit from INVS.

Where INVUR.Q* and INVUR.CQ* are improved functions from the incremental modification of INVS.Q * and INVS.CQ* with the consideration of uniform replenishment. Reuse is encouraged because it helps to reduce the redundancy and avoid the inconsistency in an object-oriented design of model base systems. However there are exceptions that a new class can be defined from scratch in order to achieve the best performance. Inheritance provides a mechanism to specify the relationship for reuse of classes in a model base system. However there is still a need to develop a formal theory for the conceptual design of model base systems. For this purpose, Section 3 and Section 4 present the type rules and inheritance theory respectively.

J. Ma / Decision Support Systems 19 (1997) 53-60

56

3. Type rules for discovery of inheritance relationships between classes In the proposed framework, class is a basic unit for specifying a decision model. Within a class, most of the expressions are typed functions with the form: f : p ~ ~-, for x: p and e ( x ) : ~-. Thus the type rules for functions can be derived. Rule 1. If there exist types p D p' and the function f : p ~ ~-, then f : p' ~ r is a specialized function of f : p ~ ~'. In mathematics, a function is defined to be a mapping from a type to a new type, then for any value x ~ p ' C p, there exists f ( x ) ~ T. Thus the specialized function f : p' ~ ~- shares the same function implementation with f : p ~ T. Example 3. In the simplest optimal lot size inventory model of Example 1, R is an integer, denoting the units required per unit time. Hence the optimal lot size function becomes: Q * : I N T E G E R ~ REAL; Q* = A R . S Q R T ( ( 2 *R* C o ) / C h ) . Since I N T E G E R c REAL, Q* : I N T E G E R R E A L is a specialized function of Q* : R E A L R E A L in class INVS. Rule 2. If there exist types ~-D ~-' and the function f : p ~ ~', such that f : p ~ z' is meaningful, then f : p ~ r ' is a specialized function of f : p ~ r. The condition that f : p ~ r ' is meaningful means that for any value x ~ p, there exists f ( x ) E r ' . Then the mathematical explanation of the definition can be stated as: given any value x ~ p, there exists f ( x ) ~ r ' c r. Thus f : p ~ z' shares the same function implementation with f : p ~ r. Rule 3. If there exist types r D r ' , p D p' and the function f : p ~ r, such that f : p' ~ r' is meaningful, then f : p ' ~ r ' is a specialized function of f:p---~r. This rule is in fact the combination of Rules 1 and 2. As a result, f : p' ~ ~-' shares the same function implementation with f : p ~ r. Example 4. Given two integer constants a and b, if we let the production volume x be an integer, the total production cost f is determined by: f : I N T E G E R ~ INTEGER;

f ( x) = Ax.( a + b ' x ) ,

which denotes a mapping, I N T E G E R ~ INTEGER, and is a specialized function of f : REAL ~ REAL. The inheritance relationship between two classes can be derived from the type inheritance rules for specialized functions. Therefore we have the following definition.

Definition 1. For a given class C = {e 1, e 2 . . . . . en}, m < n. and a new class C' = { e'1, e '2 . . . era}, . . where . If expression e'i (for some i in ( l _ < i _ < n ) ) is a specialized function of the corresponding expression e i in class C, C' is then a subclass of C, which inherits functions from its super-class C. Formally, we write t

C' = { e}, •

.*.,

e;k }

inherit from C. where ejit (1
Example 5. In the integer programming (IP) model, I P G O A L is an incremental modification of G O A L in class LP [17]. Hence, IP is a subclass of LP, which can be specified by inheriting function properties from LP. I P = {IPGOAL: (( R." X R . X R. ~ R . ) ~ I R n ) REAL} inherit from LP. where I P G O A L is a composite function which extends the function G O A L in the class LP to generate integer optimal results. An inheritance rule checking system (IRCS) has been developed for the object-oriented design of model base systems [13]. The IRCS is to check the correctness of the model class specification and to discover the inheritance relationship between two classes.

4. Inheritance theory for design of model base systems In the proposed object-oriented framework, class and inheritance are used to specify decision models and their relationships respectively. Classes and inheritance relationships are the most important com-

J. Ma / Decision Support Systems 19 (1997) 53-60

ponents in a model base system. We introduce the following concepts to help understand the relationships among classes. • Elements: classes; • Inheritance assertions: ordered pairs of elements; • Inheritance paths: sequences of elements with length greater than two. Elements are derived from real world classes. They can be distinguished by signs such as positive ( + ) , negative ( - ) or neutral ( # ) respectively. For example, + L P refers to the class of a linear programming model, and + MOLP to the class of a multiobjective linear programming model. We introduce ~ to denote the set of all classes with three signs (e.g. + , - , # ) referred to in a model base system. Then the inheritance assertions are elements of @, i.e. they are ordered pairs of elements. In the design of model base systems, there are three kinds of well formed ordered pairs. Thus the set of ordered pairs can be represented as fixed labels and a directed graph called an inheritance graph. The well-formed ordered pairs can be represented by three kinds of links, called IS-A, IS-NOT-A and NO-CONCLUSION links. If we let the variables x and y represent the elements of q~, then the correspondence between ordered pairs and inheritance graph links is shown in Fig. 1. For example, the assertion " I P is a subclass of L P " is represented by < +IP, + L P > , and the negative assertion " M O L P is not a subclass of IP" is represented by < + MOLP, - IP > . Note that the first element of an inheritance assertion is always positive, while the second element may be either positive, negative or neutral. The three kinds of ordered pairs listed in Fig. 1 are the only ones to be used in the conceptual design of model base systems, because they represent the complex relationships among model classes in a model base system. The Ordered Pair

Inheritance Graph Link

Intuitive Meaning

<+x. - y >

x IS-A y

x is a subclass o f y

<+x. -y>

x IS-NOT-A y

x is not a subclass o f y

<+ x. #y>

x NO-CONCLUSION y

no conclusion whether x is a subclass o f y

Fig. 1. Ordered pairs and inheritance graph links in a model base system.

57

7

I! IS-A

©

IS-NOT-A

NO-C'ONCI,USt~~N

Fig. 2. The three kinds of links in an inheritance graph.

three kinds of ordered pairs can be represented as different links in an inheritance graph as shown in Fig. 2. In Fig. 2, each IS-A link in the inheritance graph is drawn as an arrow with a closed head. Each IS-NOT-A link arrow has railroad tracks and each NO-CONCLUSION link is an arrow drawn with a double dashed line. Example 6. Let class LA represent the linear algebra model for addition and multiplication operations on a matrix, LP is then a subclass of LA. Taking the consideration of previous classes in management science or operations research (MS/OR), an inheritance path is formed as shown in Fig. 3. The sequences of length greater than two describe the path through the inheritance graph. In general, a sequence < y~. . . . . y, > can be treated as chains of nonmonotonic inferences. For example, let + TP be the class of the transportation programming model, the sequence < + TP, + IP, + LP > may be read as " T P which is a subclass of IP is therefore a subclass of LP". Design of classes is the main concern for building model base systems. Now let I = < c~ . . . . . c n > denote an inheritance path in a model base system q~, it means that the pairs < +c~, + c 2 > . . . . . < + c , _ ~ , + c n > are all in qb. The " + " sign is often omitted when the meaning is clear.

LA ( ~ I

LP y i

Fig. 3. Description of an inheritance path in OR/MS.

58

J. Ma / Decision Support Systems 19 (1997) 53-60

Definition 2. The conclusion set of a model base system qb, written as C ( ~ ) , is the set o f all pairs < c ~ , c : > such that a sequence < c i . . . . . c:> appears in ~ . The conclusion set C(@) helps to find the inheritance relationship between two classes in the sequences of a model base system q~. E x a m p l e 7. If a model base system @ contains the sequence < TP, IP, LP > , then its conclusion set C(qb) contains the sequence < TP, LP > .

Definition 3. A model base system • contradicts the sequence

< Cl,

. . . ,

-c i> ~C(~)forsome

Cn > if and only if i in l < i < n .

< c~,

The notion of contradiction can be used to prevent any new sequence from appearing in a model base system • that would conflict with what is already in E x a m p l e 8. T h e sequences < TP, LP > and < + TP, - LP > are mutually contradictory. If a model base system • contains < TP, LP > , the sequence < + T P , - L P > will contradict the one that already exists in • and thus should be eliminated.

Definition 4. A sequence 1 = < c t . . . . . c, > is inheritable in a model base system qb if and only if n > 2, • contains both < cl, . . . , c , _ l > and < c 2, . . . , c , > , and ~ does not contradict the sequence l. E x a m p l e 9. If a model base system qb contains two sequences < TP, IP, L P > and < IP, LP, L A > , then < TP, IP, LP, L A > is inheritable in ~ , as shown in Fig. 4. Inheritance allows us to form a new class by modifying functions from existing classes. This can bring exceptions to the inheritance paths. Hence simple concatenation of sequences < c~ . . . . . c, > and < c i . . . . . c n > can not guarantee to be inheritable in qb.

LP

~

LP

LP

Fig. 4. An inheritable sequence of classes in MS/OR.

The redundancy among model classes can be reduced if every sequence in the model base system is inheritable.

Theorem 1. I f a m o d e l base system c19 is closed under inheritance and contains the s e q u e n c e < cl, . . . . c , > , then it also contains all contiguous subsequences < c i . . . . . c j > f o r l < i < j < n.

Proof. For n = 2, qb contains a sequence < cj, c 2 > (1 ~ i < n). Now, for all sequences of length equal to n (n > 2), • contains < c~ . . . . . c , > . By definition, q~ contains < c ~ , . . . , c , _ l > and < c 2 . . . . . c, > . Thus, by the inductive hypothesis, • also contains < c i . . . . . c j > for 1 < i < j < n , aswasto be shown. 12. E x a m p l e 10. In Example 9, every sequence is inheritable in a designed model base system ~ , therefore • is closed under inheritance. Since contains the sequence < LA, LP, IP, TP > , it also contains the sequence < LP, IP > . Inconsistency can be caused by contradiction of the class inheritance sequences in a model base system. Hence consistency can be defined as an absence o f contradiction.

C5 C4

C3

C2

Definition 5. A model base system • under inheritance if and only if • sequence inheritable in ~ .

is closed contains every

CI

Fig. 5. • is inconsistent.

J. Ma / Decision Support Systems 19 (1997) 53-60 LA

LP

FDM

59

the classes and their inheritance relationships can be depicted as shown in Fig. 7. In Fig. 7, every class is in its simple form, and there is no sequence which contradicts the others. Thus ~ is consistent and can be treated as the final design for building the model base system.

MI )l,P

Fig. 6. • is consistent.

Definition 6. A model base system • is consistent if all the sequences in it contradict none of their elements.

Example 11. If a model base system • contains the sequence , and < c l , - c 3 > E C(q~), then q0 contradicts the sequence < c~, - c 3 > and is inconsistent. This is shown in Fig. 5. Example 12. In designing a model base system for decision models in M S / O R , • contains sequences < M O L P , L P > , < M O L P , F D M > and < LP, LA > , where FDM refers to the fuzzy Delphi model. In its practical semantics, there exists a sequence < FDM, - L A > which does not contradict any existing sequences, thus qO is consistent. This is shown in Fig. 6. Two of the main objectives in the design of model base systems are to reduce redundancy and avoid inconsistency. If every class in • is in its simple form and qb is closed under inheritance, then • is the resultant model base system. Example 13. If we are to build a model base system for the subset of decision models in O R / M S ,

5. Summary Based on a proposed object-oriented framework for the representation of model base systems, this paper proposes the type rules and inheritance theory for the design of model base systems. Type rules are first used to discover the specialized functions between classes. Inheritance theory is then designed to define formally the relationships among classes in a model base system. They are illustrated with the examples in M S / O R . The proposed object-oriented design method emphasizes the concepts of data abstraction and inheritance, it is to reduce redundancy and avoid inconsistency when designing model base systems.

Acknowledgements This research was supported by the 1994 Strategic Research Grant of the City University of Hong Kong (project no. 700-392), 1996 Hong Kong Earmarked Grant for Research (project no. 9040232) and the 1996 Hong Kong Industrial Support Fund (project no. A F / 7 / 9 6 ) .

References

!

IP

)LP

Fig. 7. A subset of decision models in OR/MS in a model base system.

[1] R.W. Blanning, Model Management Systems: An Overview, Decision Support Systems 9, pp. 9-18 (1993). [2] R.W. Blanning, Model Management Systems, in: R.H. Sprague, Jr. and H.J. Watson, Eds., Decision Support Systems: Putting Theory into Practice, pp. 156-169 (PrenticeHall, 1989). [3] R. Burslal and B. Lamson, A Kernel Language for ADTs and Modules, in: G. Kahn, Ed., Semantics of Data Types (Springer-Verlag, 1984). [4] L. Cardelli and P. Wegner, Understanding Types, Data Abstraction and Polymorphism, Computing Survey 17, No. 4, pp. 471-522 (December 1985).

60

J. Ma / Decision Support Systems 19 (1997) 53-60

[5] A. Chang, C.W. Holsapple and A.B. Whinston, Model Management Issues and Directions, Decision Support Systems 9, pp. 19-37 (1993). [6] Y.S. Chen, An Entity-Relationship Approach to Decision Support and Export Systems, Decision Support Systems 4, pp. 225-234 (1988). [7] D.R. Dolk and B. Konsynski, Knowledge Representation for Model Management Systems, IEEE Transactions on Software Engineering 10, No. 6, pp. 619-628 (1994). [8] D.R. Dolk, Model Management and Structured Modeling: The Role of an Information Resource Dictionary System, Communication of the ACM 31, No. 6, pp. 704-718 (1988). [9] S.I. Gass, Decision Making, Models and Algorithms (John Wiley and Sons, Inc., 1985). [10] M.L. Lenard, An Object-Oriented Approach to Model Management, Decision Support Systems 9, pp. 67-73 (1993). [ 1! ] A. Lloyd, A Practical Introduction to Denotational Semantics (Cambridge University Press, 1986). [12] J. Ma, An Object-Oriented Framework for Model Management, Decision Support Systems 13, pp. 133-139 (1995). [13] J. Ma, IRCS: An Inheritance Rule Checking System for Model Management, in: DSS, Journal of Computer and Information Systems 1, No. 1, Special Issues: Proceedings of the 6th International Conference on Computing and Information, pp. 1141-1159 (1994). [14] J. Mitchell and G. Plotkin, Abstract Types have Existential Type, Proceedings of 12th Annual ACM Symposium on Principles of Programming Languages, New York (1985).

[15] W.A. Muhauna, An Object-Oriented Framework for Model Management and DSS Development, Decision Support Systems 9, pp. 217-229 (1993). [16] R.H. Sprague, Jr., A Framework for the Development of Decision Support Systems, in: R.H. Sprague, Jr. and H.J. Watson, Eds., Decision Support Systems: Putting Theory into Practice, pp. 7-31 (Prentice-Hall, 1989). [17] R.E. Trueman, Quantitative Methods for Decision Making in Business (CBC College Publishing, 1981). [18] V. Wuwongse and J. Ma, An Object-Oriented Approach to Model Management, Advanced Information Systems Engineering, pp. 525-539 (Springer-Verlag, 1991).

Jian Ma is an Assistant Professor in the Department of Information Systems at the City University of Hong Kong. He received his Doctor of Engineering degree in Computer Science from the Asian Institute of Technology in 1991. His current research interests are in the areas of group decision support systems, object-oriented systems and development methodologies for data and model management, and assessment of problem-based learning in engineering and business education. His past research has appeared in Decision Support Systems, Computers and Education and IEEE Transactions on Education.