rases: a database supported framework for structured model...

SIMULATION PRACTICE % THEORY

ELSEVIER Simulation Practice and Theory 5 (1997) 289-313

RASES: A database supported framework for structured model base management’

Hyu Chan Park, Wan Bok Lee, Tag Gon Kim *

Department of Electrical Engineering, Korea Advanced Institute of Science and Technology (KAIST), 373-I Kusong-Dong,

Yusong-Ku, Taejon 305701. South Korea

Received 24 April 1995; revised 1 March 1996

Abstract

Structured management of model base has placed demands on some kind of computer based frameworks with highly structured formalisms. This paper proposes a new framework, called the relational algebraic system entity structure (RASES), which is based on the system entity structure (SES) formalism and the relational algebra (RA) formalism. These formalisms provide a conceptual basis for the structured model base management. Within the framework, structural knowledge of a system is represented in a hierarchical structure and saved in a database. Furthermore, several operations can be formulated in terms of relational algebra which can be coded in a standard query language such as the SQL. The framework can be easily implemented on, and fully utilize the functionality of, relational database management system (RDBMS). With the help of the implemented framework, simulation models can be systematically synthesized from the models in the model base through the following processes. First, a family of hierarchical structures of a system is organized in the form of entity structure by the entity structuring process. Then, candidate models of the system which meet design objectives are synthesized from the entity structure through the pruning process. Finally, designers can conduct appropriate experiment with the models for design verification and performance measure. 0 1997 Elsevier Science B.V.

Keywords: Model base management; System entity structure; Relational database

1. Introduction

Systems of real world have such information as components, interconnections among components, attributes characterizing component, and relationships among components. The fact that the information is related in a complex manner makes

* Corresponding author. Email: [email protected].

’ A preliminary version of this paper was presented at the 1994 Winter Simulation Conference, FL. 1994

0928-4869/97/$17.00 0 1997 Elsevier Science B.V. All rights reserved

PII SO928-4869(96)00012-2

290 H. Chan Park et al. ! Simulation Practice and Theory 5 (1997) 289-313

the modelling problem very complex. To control the complexity, hierarchical management of the information is desirable. In the hierarchical approach, a complex model can be constructed just by interconnecting input/output ports of component models if they are in modular form [ 151. The complex model may itself be employed

as a component of yet more complex, hierarchical models. This paper focuses on the problem of model base management which concerns

how to manage models in a library of models, how to organize structural information of systems, and how to construct new models of the systems. To cope with the complexity of the problem, we must devise some kind of computer based frameworks with highly structured formalisms. This paper proposes a new framework, called the relational algebraic system entity structure (RASES). It is based on the system entity structure (SES) formalism [6,7,14,15,17] and the relational algebra (RA) formalism [2,3]. The SES formalism provides a conceptual basis to organize a family

of systems in a hierarchical structure. The hierarchical structure is represented in the form of entity structure [ 151. The entity structure itself, in turn, can be formulated in terms of relational tables based on the RA formalism. The tables can be saved in and retrieved from a relational database. Furthermore, several operations on the entity structure can be defined in the relational algebra.

RASES may provide an integrated approach within which one may systematically construct simulation models. Because such models are, to a great extent, constructed logically, designers are relieved from the burden of writing and debugging the details of the models. RASES also provides the designers with many features such as consistencies among design components. These features help in creating correct models, before committing them to the simulator. Therefore RASES may be a robust method for model base management.

RASES can exploit the power of relational database. Relational database has been applied successfully to several applications and accepted as a method to overcome limits of traditional approaches [ 111. It has been an effective method for managing large amounts of data, sharing data among users, and fast queries. The well-defined query languages such as the SQL [4] can be used to access the databases. In the model base management problem, there may be a large number of entity structures which must be stored to provide sharable repository for many designers. This problem can be alleviated by the database approach because relational database management system (RDBMS) provides rich facilities to efficiently manage large amounts of data. Furthermore, many model base management functions, such as create, delete, and update are equivalent to the database management functions. As a consequence, RDBMS is an attractive platform to implement the RASES framework for the model base management.

In the work described here, the RASES framework with a powerful graphical user interface has been implemented on a general purpose RDBMS, INFORMIX. Within the framework, all the hierarchical structures of a system are organized in the form of entity structure through the entity structuring process. Models of design candidates which meet design objectives are synthesized from the entity structure by using the pruning operation [ 151. Finally designers can conduct appropriate experiment on the models for design verification and performance measure. Furthermore,

H. Chan Park et al. / Simulation Practice avd Theory 5 ( 1997) X9-313 2c)I

the framework is sufficiently general enough to be extended to manage the knowledge of other domains, and to serve somewhat different needs of users.

The remainder of this paper is organized as follows. Section 2 discusses the concepts of the model base management, and briefly reviews the system entity structure and the relational algebra. In Section 3, we propose a relational formalization of SES, called RASES, with an algorithm for the pruning operation. Section 4

describes the implementation of the RASES framework. Section 5 presents some

experimental results with a simple example. Finally, concluding remarks are in Section 6. A preliminary version of this work appeared in [ 121.

2. Preliminaries

This section first discusses the concept of model base management, and then reviews system entity structure and relational algebra.

2. I. Model base managemenl

Models may be classified into atomic and coupled ones. A basic model called an atomic model has specification for the behavior of a component as opposed to decomposing it in terms of other components. It is primitive in the sense that it is not decomposed into other components. The second form of the model, called a coupled model, is to specify what its components are and how the components are

connected to each other. It specifies the hierarchical relationships among the components of a given system. Therefore the hierarchy of the coupled model can be represented as a tree, called composition tree [ 151. At the leaves of the tree, the atomic models of the lowest-level components are specified. The coupled model can itself be employed as a component in a larger coupled model, thus giving rise to the construction of complex models in a hierarchical fashion. Detailed descriptions for

the definitions of the atomic and coupled model can be found in [ 151. We need approaches to effectively use such models to reduce the complexity of system design. Model base may be a possible approach. Model base, an organized library of models. contains a set of models that may be either atomic or coupled one. Models can be saved in. and saved models can be retrieved from, the model base. Models so retrieved may be reused to create more complex models. This approach will improve the productivity of modelling task by reusing the models effectively.

Fig. 1 shows an approach for the model base management relied on the concept of SES. A simple example is also shown in Fig. 2. The behavior of each primitive component of a real world system is specified as an atomic model and saved in the model base (Fig. 2(a)). The structural knowledge of the system is represented as an entity structure (Fig. 2(b)) by means of an operation called entity structuring. The entity structure, here, serves as a compact representation for organizing all possible hierarchical structures of the system. This separation of the structures from the behavior may reduce the modelling complexity of real world systems. Moreover. such separation allows designers to easily construct candidate models with different

292 H. Chan Park et al. 1 Simulation Practice and Theory 5 (1997) 289-313

1 1

Model El synthesis

1

I______________ Simulation 0 Simulation model

_______________*

El engine

Fig. 1. Model base management flow

structures while using the same components. To construct a certain simulation model which meets design objectives, the pruning operation is used to reduce the entity structure to a so-called pruned entity structure (Fig. 2(c)). This pruned entity structure can be transformed into a composition tree (Fig. 2(d)), and eventually synthesized into a simulation model (Fig. 2(e)) by combining with models in the model base. These simulation models are evaluated via simulation studies to determine superior solutions to the modelling problem.

2.2. System entity structure

We review some fundamental concepts of SES that are discussed in greater detail elsewhere [ 151. The SES formalism, proposed by Zeigler, is a structural knowledge representation scheme which systematically organizes a family of possible structures of a system. Such a family characterizes decomposition, coupling, and taxonomic relationships among entities. The entity represents a real world object. The decomposition concerns how an entity may be broken down into sub-entities, and the concept of coupling is to specify how these sub-entities may be combined to reconstitute the entity. The taxonomic relationship concerns admissible variants of an entity.

H. Chan Park et al. / Simulation Practice and Theory 5 (1997) 289-313 293

MODEL BAS

(8)

EF_PEL

I ((EF.out, PEL.in), ef~“;‘-dec (PEL.out, EF.in))

EF PEL ((PEL.in, BUFFA), 1 (BUFF.out, PROCin),

pel-&c (PROC.done, BUFF.ready), 1 (PROCout, PEL.out))

BUFF PROC II

bufispec

FIFO LIFO

(b)

EF_PEL

I ((EF.out, PEL.in), efg’-dec (PEL.out, EF.in))

EF_PEL

EF A

PEL ((PEL.in, FIFOht), 1 (FIFO.out, PROCh),

p&&c (PROCdone, FIFO.ready), 1 (PROC.out, PEL.out))

I FIFO PROC

A A GENR -~RANSD FIFO PROC

(e) (d)

- EF_PEL

(4

Fig. 2. Example of model base management: (a) model base, f b) entity structure, (c) pruned entity structure, (d) composition tree, (e) synthesized model.

294 H. Chun Park et al. /Simulation Practice and Theory 5 (1997) 289-313

As shown in Fig. 3, an entity structure is represented as a labeled tree with attached attributes which satisfies the following axioms: uniformity, strict hierarchy, alternating mode, valid brother, and attached variables. Details of the axioms can be found in [ 151. There are three types of nodes in the tree. Entity node, like A in Fig. 3, represents a real world object. There are two types of entity, namely composite

entity and atomic entity. Composite entity is defined in terms of other entities (which may be either atomic or composite), while atomic entity cannot broken down into sub-entities. Each entity may be attached with, and characterized by, variables. It may have several aspects and/or specializations. Aspect node, like A-dec in Fig. 3,

is connected by a single vertical line from an entity. It represents one decomposition of the entity. The children of the aspect are entities, distinct components of the decomposition. Associated with each aspect is coupling specifications. Specialization node, like B-spec in Fig. 3, is connected by a double vertical line from an entity. It defines the taxonomy of the entity, and represents the way in which the entity can be categorized into specialized entities. Selection rules may be associated with each specialization, and guide the way in which a specialized entity is selected in the pruning process. Selection constraint, depicted as dotted arrow from an entity to other entities in Fig. 3, means that not all entities may be selected independently

[ 161. Once a specialized entity is chosen from a specialization, some specialized entities in other specializations associated with the specialization are also selected. The dotted arrows from Bl to Dl and Gl in Fig. 3 means the following selection constraints: “if entity Bl is selected from specialization B-spec then select entity

Dl from specialization D-spec and entity Gl from specialization G-spec.”

A (-VI)

A_;ecy%$2) (B.out, Amt) (Cmt, A.&))

B (~2, -v3} c (94)

& Win, D.in) ((C.in, Bin) {(C.in, H.in)

E-spec (“2+ _, 82)) B-dec @out, E.in) C_dec- (B.out, G.in) C-de& (H.ouf Lin) , ,, , , , I‘““, B.out)} , , , (G.out, Gout)} , , , (Lout, Gout)}

Bl B2 D {-~7) E

D-spec

B G l-v81 H I {-VlO)

G-spec

* G1 {-*I {-VI 1)

,. G2

#’ 8’ (-v12) ,I (-VlO)

I____________.__________~___----__________, *’

Fig. 3. Example of entity structure.

H. Clzun Park et al. i Simuhtion Prucricc and Theory 5 ( 1997) 289-313

2.3. Previous works on SES

Since Zeigler proposed the concepts of SES, a considerable amount of work on SES have been performed, They may be classified into two categories. The first is

to make SES more concrete knowledge representation scheme, and the second is to

accept SES as a conceptual basis for several applications. Zhang and Zeigler [ 171 presented a set-theoretic formalization of SES which

allows to rigorously characterize its important features. They showed that although

SES had been visually represented as a treelike structure, it can be coded into other

forms which can coherently convey the information it bears. Kim et al. [6,7]

presented a realization of SES in Scheme (a Lisp dialect) called ESP-Scheme with

two examples of application. The representation of SES and the main operations

on SES were presented, and then facilities provided by ESP-Scheme were also

described. Rozenblit et al. [13] augmented SES into an integrated, entity-oriented

knowledge representation scheme, termed the frame and rule-associated system entity structure (FRASES). The FRASES is a scheme that combines concepts of SES.

frame, and production rules. Zeigler et al. [ 161 dealt with the management of model bases using SES. They proposed the System Entity Structure/Model Base (SES/MB)

framework as a workable foundation for model base management in advanced

simulation environments and workbenches. They also proposed some advanced concepts such as reusability of models and model base coherence and evolvability

to support multifacetted systems design. Sevinc and Zeigler [ 141 illustrated an application of SES to the design of local

area network. The flexibility of SES for generating alternative designs helped to

investigate efficiently a large number of possibilities in finding improved LAN

architecture with particular characteristics. Kim [S] employed SES to specify the environmental schedules in a hierarchical fashion for an intelligent environmental

control system. He developed a system entity structure called TAL (Time Action

Language) to organize a family of all possible long-/mid-/short-term schedules from

which a specific schedule can be pruned. Higa et al. [5] presented a generalizable

methodology for presenting structural knowledge to form an integrated knowledge

base/database system. They proposed Structured Object Model (SOM ). derived from SES, which is an object-oriented graphical model developed for database and

knowledge base design.

2.4. Relation und relational ulgebra

The Cartesian product of domains D,,. . ., D,, written D, x ... x D,, is a set of tt- tuples (rr,...,v,) such that v1 is in D,, v2 is in D,, and so on. Relation is any subset

of the Cartesian product of one or more domains, and each element of the relation

is called tuple. Relation can be represented as a table where each row is tuple and each column has a distinct name called attribute. Each attribute has an associated

domain. A relation R with a set of attributes A = {A,,...& is denoted by RI.41 or R[A,...A,,]. Let t be a tuple in R[A]. Then the part of t corresponding to a set of

296 H. Chan Park et al. / Simulation Practice and Theory 5 (1997) 289-313

attributes XGA is denoted by t[X]. We also use the relation name itself, for example t[R], to indicate ail attributes of the relation.

There is a family of operations usually associated with relations. They can be coded by using algebraic notations, called relational algebra. Fundamental operations in relational algebra are union (u), difference (-), Cartesian product (x ), projection (rc), and selection (cr). In addition to the five fundamental operations, there are some other useful operations that can be defined in terms of the operations above. They are intersection (n), natural join (w), and theta join (we). Details of such operations can be found in [2] and [3 J.

In addition to the above operations, we defined a new operation called replacement (0) which will be used intensively for a pruning algorithm. Replacement (02Z2) operation is defined as follows.

Let R[X], S[Y], and R’[X] be relations, and attributes A1,AZ E X and B1,B2 E Y. Then each tuple r’ E R’ for R’= R @2Zg S is obtained as follows.

For each tuple r E R, if there exists a tuple s E S such that r[A II = s[B,]

then r’[X-A,] =+%-A,] and +[A,] = s[&] else r’=r.

That is, a replacement operation of R OA1 = B, A2eB2 S means that each value of attribute A2 is replaced with the value of attribute B, if the condition A, =B, is satisfied as shown in the following example.

R[A B C]: S[D E]: * R O;Z; S

A B C D E A B C a 1 x U 1 U 1 x b 2 y v 2 2 Y b 3 y w 4 : 3 y

The replacement operation can also be coded by using other operations as follows.

Here, bAZCB2 means that attribute name B, is changed into A,.

R @=:r% S=&,+B,(%,,X-A,(R Da~,=B, WJ(R-Q@ w~l =B, s))

3. RASES for model base management

This section first proposes a formal definition of SES, and then proposes RASES, a relational formalization of SES, with a pruning algorithm and model synthesis.

3.1. SES: system entity structure

SES can be formalized by items, relationships among them, attributes attached to them, and selection constraints as follows.

H. Chan Park et al. / Simulation Practice and Theory 5 (1997) 289-313 29-l

Definition 1. A system entity structure (SES) is defined by a 4-tuple

SES= (ITEM, REL, ATT, Gsel),

where ITEM= EvAuS: set of items, l E: set of entities, l A: set of aspects, l S: set of specializations; REL = AspuSpec: set of relationships among items, l Asp c E x A x 2E: aspect relationship, l Spec c E x S x 2? specialization relationship; ATT= EvaruAcoupuSsel: set of attributes attached to items, l Evar : E+2V: variables attached to entities, . Acoup : A_,~WO~E.W: couplings attached to aspects, l Ssef : S-+2R: selection rules attached to specializations; Gsel : (S x E)+2@’ E): global selection constraints.

where V represents a set of variables, IO represents a set of input/output ports of respective entities, R is a set of selection rules in the form of (cond-+E);

Items (ITEM) are depicted as nodes in the treelike representation. It is composed of entities (E), aspects (A), and specializations (S). Relationships (REL) among items define how each item is related with each others, and are depicted as edges in the treelike representation. Aspect relationship (Asp) relates each entity with sub-entities through an aspect, and specialization relationship (Spec) relates each entity with specialized entities through a specialization. Each item may be augmented by attached attributes (ATT). Variables (Evar) are attached to, and characterize each entity. Couplings (Acoup) are attached to each aspect, and can be described in terms of entities with their input/output ports. Selection rules (Ssel) are also attached to each specialization, and help the selection process of the pruning. We also consider global selection constraints (Gsel) among specializations and their specialized entities. For example, the entity structure in Fig. 3 is defined as follows:

E= {A,B,C,Bl,B2,D,E,G,H,Z,D1,02,Gl,G2},

A = {A-dec,B-dec,C-decl,C-dec2},

S= {B-spec,D-spec,G-spec},

Asp= {(A,A-dec,{B,C}),(B,B-dec,{D,E)),(C,C-decl,{B,G)),(C,C-dec2,{H,I})},

Spec = {(B,B-spec,{B1,B2}),(D,D-spec,{D1,D2}),(G,G-spec,{G1,G2})},

298 H. Chan Park et al. /Simulation Practice and Theory 5 (1997) 289-313

3.2. RASES: relational algebraic system entity structure

Although SES has been visually represented as a treelike structure, it can be transformed into other forms which can coherently convey the information it bears [ 171. In this section, we present a relational formalization of SES, called RASES, in which the constituents of SES are represented as relations, and the operations on them are defined by relational algebra. Each relation is defined in terms of relation name, attribute names, and some kind of constraints on them. The definition of the relational algebraic system entity structure is as follows.

Definition 2. A relational algebraic system entity structure (RASES) is defined by a 6-tuple

RASES= (ASP, SPEC, EVAR, ACOUP, SSEL, GSEL),

where: l ASP[ent,asp,subent]: contains aspect relationships among entities. ent is an entity,

asp is an aspect, and subent is a sub-entity of the entity ent. This means that the subent is a sub-entity of ent under the aspect asp.

l SPEC[ent,spec,specent]: contains specialization relationships among entities. ent is an entity, spec is a specialization, and specent is a specialized entity of the entity ent. This means that specent is a specialized entity of the parent entity ent under the specialization spec.

l EVAR[ent,variable,value]: contains variables attached to entities. ent is an entity to which the variable is attached, and vnlue is the value of the variable. This means that variable, whose value is value, is attached to the entity ent.

l ACOUP[asp,entl,portl,ent2,port2]: contains couplings attached to aspects. asp is an aspect, entl is an entity, port1 is a port of the entity entl, ent2 is another entity, and port2 is a port of the entity ent2. This means that port1 of the entity entl is connected to port2 of the entity ent2 for the aspect asp.

l SSEL[spec,cond,specent]: contains selection rules attached to specializations. spec is a specialization, cond is a condition, and specent is a specialized entity. This means that if the condition cond is satisfied then specent is selected for the specialization spec.

H. Chan Park et al. / Simulation Prtrctice and Theory 5 ( 1947) 289-313 ‘99

l GSEL[specl,specentl,spec2,specent2]: contains the globai selection constraints. specl and spec2 are specializations, specentl is a specialized entity of specl, and specent2 is a specialized entity of spec2. This means that if specentl is selected for the specialization specl then specent2 must be selected for the specialization

spec2.

All of the relations are independent of a specific entity structure to be represented. Thus, creating an entity structure is a matter of entering data into predefined

relations rather than a matter of defining new relations. This choice of having all relations predefined has advantages. Since the database structure is known prior, an

implementation of RASES framework is easier. Furthermore, since all the entity structures built in this framework look alike, they are easier to understand, to combine, and to interchange. Fig. 4 shows the relational tables for the example entity structure depicted in Fig. 3.

A set of primitive operations has been defined on RASES. These operations allow users and application programs to add new items to the relational tables, delete

existing items, create and remove relationships among items, and retrieve both the items and relationships. These operations may be defined in the relational algebra. The relational algebra, in turn, can be easily coded in a standard query language such as the SQL. To clarify the simplicity of relational operations, only two of them

(one for predefined operations and the other for user coded query) are presented here. (1) subent_of: The operation subent_of(x) returns sub-entities of the given entity

x from aspect relation (ASP). It is coded as the following relational algebra:

iSP - ent

x- A B B C C C C -

asp subent

A-dec B A-dec C B-dec D I B-dec E C-decl B C-decl G C-dec2 H C-dec2 I

SPE - em

B B D D G G - I---

SSEL :

XA - ent

A B B C Bl B2 D G H Dl D2 Gl G2 -

variable

VI

v2 v3 V4

V5

V6

v7 V8

VI0 V9

VII VI2 VI0

asp A-dec A-dec A-dec A-dec B-dec B-dec B-dec C-dec 1 C-dec 1 C-dec 1 C-dec2 C-dec2 C-dec2

- ?tlntl

%-- A B C B D E C B G C H I -

oortl

in in out out in out out in out out in out out

- ent;

B C A A D E B B G C H 1 C -

port2

in in out out in in out in in out in in out

Fig. 4. Relational tables representation


(2) user coded SQL query: Although users may retrieve much structural information on an entity structure by using the predefined operations, they can also use the SQL for their own purpose without the help of predefined operations. For example, the list of entities which have v7 or v10 as their attached variables can be obtained by the following SQL query.

SELECT ent FROM EVAR WHERE variable = ‘~7’ OR variable = ‘~10’;

3.3. Relational algebraic pruning

An operation called pruning, which extracts a sub-structure from an entity structure, will be discussed. And we will propose a pruning algorithm on RASES by using relational algebra. An entity structure specifies a family of system structures, in which every entity is organized by aspects and specializations. The pruning process is to extract a pruned entity structure, also called pure entity structure, from an original entity structure. Pruned entity structure (PES) is an entity structure which has the following restrictions: every non-leaf entity has single aspect, every leaf entity has no aspect, and every entity has no specialization. The aspect of non-leaf entity represents the unique decomposition of the entity. Pruning process is mainly composed of two parts. First, one aspect and/or one specialized entity are selected from the alternatives hanging from each entity. This selection may be guided by the design objectives [ 151. Next, each specialized entity inherits all (sub-structures, variables, couplings) of its parent entity.

We propose a relational algebraic algorithm of the pruning as follows:

Algorithm 1. Relational algebraic pruning algorithm.

Algorithm: Prune Input: ES (ASP,SPEC,EVAR,ACOUP) Output: PES (ASPpruned,EVARpruned,ACOUPpruned)

begin Step 1 Prune_Select( ES); Step 2 ASPprunedt(ASPse1 @$$f~~::cent SPECsel) @$Z~~~t SPECsel; Step 3 ACOUPsel+z AcoUP@ CO Upwasp = .&SPsel); ACOUPprunedc(ACOUPse1 @$Zz$y”‘t SPECsel) O~~:~Z~~:tecen’ SPECsel; Step 4 E VARselc nEYAR(E VARw mt= ent v ent =su~entASPsel)~J=,v,,(EVARRw,m = ent v ent =specent SPECsel); E VARprunedt E VARsel @:~:Z~~~’ SPECsel;

end

H. Chan Park et al. j Simulation Practice and Theory 5 (1997) 289-313 301

Step 1 selects only one aspect and/or one specialized entity from the alternatives hanging from each nonleaf entity (details are in Algorithm Prune_Select). Note that an entity may have several aspects and/or specialized entities. In Step 2, each specialized entity, which is selected in Step 1, replaces its parent entity from the aspect table. In this way, the specialized entity inherits the sub-structure of its parent entity. In Step 3, coupling specifications of each aspect is appropriately modified by replacing each entity in the couplings with its corresponding specialized entity. In Step 4, each entity attached with variables is also replaced with its specialized entity. In this way, the specialized entity inherits the variables of its parent entity.

In the algorithm, the replacement (0) operations are used for each specialized entity to inherit all the information of its parent entity. As an example, the inheritance of variables in Step 4, EVARprunedc EVARsel O~$f~f~ent SPECsel, is presented in Fig. 5(a). Its operational effect is same as, but its complexity is lower than, the inheritance on the tree of Fig. 5(b). - .,

Algorithm 2 is to select one aspect and/or one specialized entity for each entity:

EVARsel : - ?N

A B B Bl C D Dl G Gl -

variabh d

vl v2 v3 V5 v4 V?

v9 V8

v12

SPECsel :

ent spec specen t

-t--H B B-spec Bl D D-spec Dl G G-spec Gl

EVA EVARsel ‘3:::::y’ SPECsel -

L !nt

A (~1)

I A-dec

I I

I B ~2.~3) c W4)

I II 1 I

B-spec B-dec C-decl

I I Bl

I--+ +l

k-v51 D (97) E B G (-~8) II II

D-spec I I Dl (-Vs)

G-spec II Gl (42)

-

wuned :

gan’able

A {-VI]

A-dec I

I 1 Bl {--v2,v3,vS) c I-v41

I I B-dec C-decl

I---+ I-+ Dl E Bl Gl

(-v7,v9) (-vS,vl2)

Fig. 5. Inheritance of variables: (a) inheritance on tables, (b) inheritance on tree.


Algorithm 2. Selection algorithm.

Algorithm: Prune_Select

Input: ES (ASP,SPEC)

Output: Selection (ASPsel,SPECsel)

begin NEXT+ {root( ES)};

do until NEXT= 0

Ncnext(NEXT);

Step 1

As+ ~&gent = .WP)); At select(As); ASPa+-a,,,= ,v/rasp=~(ASP); ASPsel+- ASPselv A Spa; Step 2 Ss+n spece&ent = ,(SPW); St select(Ss);

SPECS + cent = Nq,ecen~=s(SPEC); SPECselcSPECselvSPECs;

Step 3 NEXT+ NEXTu~,,,,,.,(ASPa)vn,,,,,,,(SPECs) - (N);

end do end

Step 1 selects one aspect from the alternatives hanging from a given entity. Step 2

is to select one specialized entity from the alternatives hanging from the entity. If there is only one item to be selected then it is selected automatically. In Step 3, the

selection process proceeds into the next entity in a breadth-first traverse. The selection rules and global selection constraints can also be incorporated into this selection

process with some additional work. An example clarifies the operations of the pruning algorithm described above.

Fig. 6(a) depicts one possible pruned entity structure pruned from the example entity

structure in Fig. 3. In the pruning process, the first item from the alternatives is selected and the global selection constraints are also considered. Fig. 6(b) shows relational tables representation of the pruned entity structure.

3.4. Model synthesis

A pruned entity structure can be synthesized into a simulation model, by combining it with models in the model base through the following synthesis process. First, the pruned entity structure is transformed into a composition tree. If an entity of the pruned entity structure has a corresponding coupled model in the model base, then the entity is replaced with the hierarchical structure of the coupled model. This transformation proceeds until every leaf entity has corresponding atomic model in

H. Chun Park et ul. i Simuldon Pructice and Theory 5 ( 3947) 28%.?I3 303

A I-v11

( “A.i:;, “d,;;;

A-dec (B 1 .out, A out) 1 co”Lw , ,

Bl {-v2,-v3,-~5) c k-v4)

1 {(Blh, Dl.in) {(Gin, Bl.in) B_dec (Dl .a& E.in) c_&-] (Bl.out,Gl.in)

, (E.qut, BLout)) , , , (G;.out,c.out)~

Dl E Bl (-v7,-ti}

ASPpruned : ACOUPpnmed : EVARpruned :

Fig. 6. Pruned entity structure: (a) tree representation, (b) relational tables representation

the model base. Next, this composition tree is synthesized into a simulation model. For every leaf entity of the composition tree, the corresponding atomic model is retrieved from the model base. Higher level entities are synthesized into coupled models by coupling sub-entities according to the coupling information. Other information. such as variable, is also transformed into appropriate descriptions of the model.

This section presented an objectives-driven, relational database approach to the model base management problem. The conceptual basis of the approach is SES. a unified representation scheme. SES supports the description of a family of system structures, which allows the problem to be partitioned in a well-defined manner, and supports fast modelling cycle for users.

In spite of its success. the relational database has some limitations on its data types, relationships among objects, and manipulation of them. Object-oriented databases, by virtue of recent developments, have some features such as arbitrary data types. inheritance, method, and encapsulation. An object-oriented database

304 H. Chan Park et al. 1 Simulation Practice and Theory 5 (1997) 289-313

implementation of SES and its comparisons with the relational database implementation may be a future research.

4. Implementation of RASES framework

We have implemented the RASES framework as shown in Fig. 7 with a graphical user interface in Fig. 8. A decision was made to implement the framework on INFORMIX, a relational database management system, because of its proven reliability, efficiency, and the potential for a rapid implementation. It provides rich facilities that can be used to implement applications including the RASES framework. The implementation relies on the ESQL/C, in which the query language SQL is embedded into the host programming language C. The ESQL/C provides all the functionalities of the SQL and C. It allows one to perform computations, by using the C language, on the results of SQL queries. The framework may provide a supporting tool to systematically organize a family of system structures in the form of entity structure according to the principles of RASES. It also provides a guiding tool to extract a specific structure from the entity structure by the pruning process. Accordingly, designers who have partial knowledge of the system can synthesize complete simulation models which meet their design objectives.

Users Applications

, ‘,‘.‘.‘.‘.~.~,‘.‘.‘.‘.‘.‘.’ ‘.‘.~.-.‘.~.‘.~.~.’ ‘. :: :::.:.:, ‘,:.:,User interface / Functional interface,:.:.:.:.:.:.:,:.:.: :.‘.: :. ::: ‘.‘.‘.‘.‘.’ ‘.‘. .,.,. .‘.‘.‘.‘.‘.‘.‘.‘,‘,‘.‘.‘.‘. .‘.‘.~.‘.‘.‘.‘.‘.‘.~.‘,‘.‘,‘.‘.~.’.’,’,~.’.’.’.‘,‘.‘.‘.‘.’.’. ,‘,‘.~,‘.‘.~,‘.‘.‘,‘.‘. ::;::: ” ‘.‘.‘_‘.‘.‘.‘,’

I

I entity StlUCtllre I

: : ‘.‘.‘. ,,.::. ::,‘,‘.:.:::

: : ‘.‘.‘,‘. :, .:.:::. .SQL (ESQL/C)l:l:I:l:l:l:1:1:1:1:1:1::.::~:~:::~: ‘.‘.’ ‘.‘.‘.‘.‘. ::::::.

:::::::::i::::i:::::::j::::::::jj:::::::~RDBMS (INFORMI~~:::::::::::::::::::::::::~:~:::::~:::::::~::~ .

5!!tg I models

structure

Fig. 7. RASES framework.

H. Chan Park et al. / Simulation Practice and Theory 5 (1997) 289-313 305

Coupllngt

~0

Selected Coupling

TF'S.cut -> EF.in I

Message Operation : Edk Couplings

b

Fig. 8. Graphic user interface.

The framework’s core is the database components. Their responsibility is to provide an efficient interface to stored data. There are three databases. SES Base and PES Base contains entity structures and pruned entity structures, respectively. Model Base contains a set of models, each of which may be atomic or coupled model. Several management modules are built on top of the database components. They are responsible for managing entity structures, pruned entity structures, and models supported by the database components. SES Manager module provides several facilities such as construction and modification of entity structures. Pruner module is an implementation of the pruning algorithm. Model Synthesizer module is to synthesize simulation model by combining pruned entity structure with models in the model base.

There are two ways to access the database at the view of users and application programs. The SQL is a conventional way to directly access the database and exploit the power of database. But the interface provided by the framework is a quite convenient way to access the database. The main goal of the RASES implementation was to produce operational databases with an interface for the model base management. The interface takes requests from users and application programs, and translates them into database operations on the databases. The following list includes


a part of the operations. It is by no means a complete specification, but intended only to give a flavor of the repertoire of operations. ( 1) databases management l CREATE_DATABASE(database) l DELETE_DATABASE(database) (2) entity structures management l CREATE_ENTSTR(entstr) l DELETE_ENTSTR(entstr) l MERGE_ENTSTR(entstr_l,entstr_2) l CUT_ENTSTR(entstr,entity) (3) items management l ADD_ITEM(item,type) l DELETE_ITEM(item)

5. Experimental results

We have conducted some experiments on the RASES framework with an example. Although the experiments are relatively simple they are to show that the value of the RASES is the ability to generate and compare alternatives easily. The basic activities for the model base management are building an entity structure, pruning the entity structure, and synthesizing a simulation model. Assume that a model base has been in place although we can add more models to the model base during the design phase. Then, a family of possible hierarchical structures of a system that can be configured by composing the models is represented in the form of entity structure. By the pruning process, a specific structure of the system which satisfies design objectives can be pruned from the entity structure. The resulting structure is synthesized into a simulation model through the synthesis process. The synthesized model is evaluated via appropriate experiments by using a simulator. This section describes the experimental results.

5.1. An example: Transaction processing system

We used a transaction processing system, as an example, whose overview is shown in Fig. 9. It is mainly composed of two parts: EF (experimental frame) and TPS (transaction processing system). GENR (generator) is a model to generate transactions. It can control the size and the generation rate of transactions. TRANSD (transducer) is a model to accept outputs from the transactions and then generate summaries. GENR and TRANSD both are components for constructing the experimental frame. TM (transaction manager) assigns and loads the transactions generated by GENR to transaction processes. TP (transaction process) is a model to process a transaction. It is assigned with a transaction and then process the transaction until the transaction is completed or aborted. CPU and DISKS are resources that can be used when the transactions are executed. CPU actually executes the operations of transactions, and DISKS is to store databases. CC (concurrency

H. Chan Park et al. 1 Simulation Practice and Theory 5 ( 1997) 289-313 307

Fig. 9. TPS overview

control) is to share the resources among the transaction processes. There are three kinds of concurrency control strategy. In the two-phase locking, if a lock request on objects is denied then the requesting transaction is blocked and a victim in the deadlock cycle is restarted. In the immediate-restart, if a lock request is denied then the requesting transaction is aborted and restarted. In the optimistic, transactions are allowed to execute unhindered and are validated only after they have reached

their commit points [ 11.

5.2. Experiment overview

Fig. 10 shows the overview of the TPS experiments. It is mainly composed of two parts, modelling environment and experimental frame. The modelling environment. based on the RASES framework, is to synthesize simulation models of the TPS. The experimental frame is to experiment the synthesized models via simulation

study. It consists of transaction generator and transducer. In the experiments, design objective initiates all the works of experiments. From the design objective, pruning specification can be derived. The pruning specification specifies the structural specification of a mode1 to be synthesized, and guides the pruning process. We employed,

H. Chan Park et al. j Simulation Practice and Theory 5 (1997) 289-313

Design objectives

- TPS EXPERIMENT

. . . . . . . . . . . . . . . . . . . . . . . . . Experimental frame i

1...........................................: L.............. . . . . . . ...’

-- Summaries

Fig. 10. Experiment overview.

for the simulation environment, the DEVSim + + [9, lo] which is a realization of the DEW formalism [ 151 in C + + .

5.3. Entity structure

An entity structure of the TPS is shown in Fig. 11. In the figure, we assume that the primitive models of the TPS are already coded and stored in the model base. From these models, a configuration expert can construct the entity structure which organizes possible structures of the TPS. The root entity TPS_EXP is top level entity to evaluate the TPS. It is mainly composed of transaction processing system (TPS) and experimental frame (EF). TPS is composed of TM for transaction manager, TP for transaction processes, CC for concurrency control, CPU, and DISKS. The CC can be implemented with the two-phase locking (Lock), the immediate-restart (Restart), or the optimistic (Optimistic) algorithm [l]. CPU is actually composed of Bufl which stores the operations of transactions and Proc which actually executes the operations. The Bufl may be classified into two specialized types (FIFO, LIFO) under the specialization bufispec. And the Proc is also classified into high performance processor (Hproc) and low performance one (Lproc). The TP can be composed of several transaction processes from one (TPl) to 16 (TP16). The DISKS may be configured with either one disk (disks-decl) or two disks (disks- dec2). Each disk also has a buffer. There are several attributes, such as variables and couplings, attached to entities and aspects.

H. Chan Park et al. /Simulation Practice and Theory 5 (1997) 289-313 309

,~~_~~der [email protected], I (TPSmt, EF.in))

I EF

{(EF.h TRANSDsolved ef_-dec (TRANSD.out, GENR.nop)

A

(GENR.out, EF.out))

I I GENR TRANSD TM TP

-1 PS ((TPS.in. TM.wns) (TM.out, TP.in)

(TP.hansd. TPS.out) (TP.tm, TM.in)

fps-dec (TP.cc, CC.in) (TP.cpu. CPIJ.in) cTP.disk, DISKSin) (CC.wt, TP.ccack) (CPU.out, TPcpwck) @tSKS.out, TP.diskack))

I I cc CPU ((CPUh, ButTin)

(Buffout, Pmc.in)

HGENR LGENR Lock Restart Optimistic

TP2 TP8

DISKS

I FIFO LIFO HP~OC Lproc

((D1SKS.i~ ButTA) di&,y_&l @M?htt, DiskA)

dish-dec2

(Diskdone, Buff.rcady) , I

I (Diskout, DISKSOUI)) D&&r Disk&

I Disks1

Buff Disk I I disksO-dec dir!&-dec

Buff0 Disk0 BufFI Disk1

Fig. 11. TPS entity structure.

5.4. Pruning and model synthesis

Once the TPS entity structure has been constructed, the RASES framework may help users create simulation models. Even if users have no detailed knowledge of the TPS, they can prune the entity structure and create simulation models which meet their own design objectives. There exist many alternatives that may be extracted from the entity structure. Among the alternatives, most interesting ones are the CC and TP specializations. Consider the following design objective as an example:

“Create simulation models and experimental frames to examine the performance of the transaction processing system (TPS) according to the concurrency control algo- rithms (CC) and the number of transaction processes (TP).”

The design objective specifies to construct several kind of simulation models: each with different algorithm for concurrency control and with different number of transaction processes. The number of transaction processes means a limit to the number of transactions allowed to be active at any time [ 11. Table 1 shows an example of the pruning specification derived from the design objective. It specifies to select the TP8 for the TP specialization, the Lock for the CC specialization, and so on.

A configuration expert constructed the TPS entity structure may also provide some facilities to help users to generate the specification. According to the pruning


Table 1

Pruning specification

Entity Selection Input

TP

cc

Proc

Buff

DISKS

GENR

tp-spec?

cc-spec?

proc-spec?

buff-spec?

aspect?

genr-spec?

TP8

Lock

Hproc

FIFO

disks-decl

HGENR

specification, the RASES framework extracts a pruned entity structure which in turn can be synthesized into a simulation model. If there is no specification of which alternative must be selected, the RASES framework asks users to select one from alternatives. Fig. 12 shows an example of such pruned entity structures whose block diagram representation is depicted in Fig. 13. The pruned entity structure can be synthesized into a simulation model, by combining with the models in the model base through the synthesis process.

5.5. DEVSim + + simulations and results

Several experiments were conducted on the synthesized simulation models under the constructed experimental frames. We collected some summaries from the simulation outputs. Fig. 14 shows the performance curves according to the concurrency control strategy when the number of transaction processes is increased. Here every transaction has 10 operations, i.e., the size of transaction is 10. The performance indices include transaction throughput rate, response time, blocking ratio, and restart ratio [ 11. Fig. 14(a) is the throughput rate, which is the number of transactions

TPS_EXP

tps_~p_&c (W.out, TPS.in) I CTPSout, EF.in))

I I EF TPS {(TPS.in, TM.tram) (TM.out, TPi3.h)

{(EF.in, TRANSD.solved (TPB.transd, TPS.out) (TPB.tm, ‘I’Min) $_dec (TRANSD.out, HGENR.stop) tps_dec (TPS.cc, Lockh) (TPLXcpu, CPU.in)

rJl

(HGENRmt. EF.out)) (TPB.disk, DISKSin) (Lockmt, TPfhxck) (CPU.W TPB.cpuack) (DISKS.out, TPE.diskack))

I I I I HGENR TRANSD TM TP8 Lock CPU

{(CPU.in, FIF0.h) D&S

I (FIFO.out, Hpmcin) I ((DISKSin, FIFO.in)

cf’u-dec (Hprocdone, FIFO.ready) (FIFO.out, Disk.in)

(Hproc.out, CPUmt)) diSkS-decl (Disk.done, FIFOready)

(Diskmt, DISKhut))

FIFO Hproc FIFO Disk

Fig. 12. TPS pruned entity structure.

-1 -PS_EXP

H. Chan Park et al. i Simulation Pructicr ahd Theory 5 (IYY7) 289-313

-CPU-I I TPS rDISKS

Fig. 13. Block diagram representation.

I I I I I 2 4

TP 8

09

31 I

2 4 8 TP

CC)

Fig. 14. Simulation results: (a) throughput, (b) response time. (c) restart

completed per 10 000 time units. Fig. 14(b) is the response time, expressed in 100 time units, which is measured as the difference between the submitted time and the completed time of a transaction. Fig. 14(c) is the restart ratio, which is the number of times that a transaction to restart. We can observe that the TPS thrashes: as the number of transaction processes (TP) increases, the performance first increase, then decrease. This is because of resource and/or data contention. The results of our

experiments agree with the results from other works [ 11. This section presented an application of the RASES framework to the model base

management by using the TPS as an example. Within the RASES framework, simulation models are synthesized systematically, and then the models can be con-


ducted appropriate experiment for design verification and performance measure. Because models, for the most part, can be generated logically with the help of the RASES framework, designers are relieved from the details of models. Furthermore the framework help designers construct experimental frames to evaluate the models. Therefore the experiments shows that the RASES framework can be applicable and a robust method to the model base management. Although the experiments concen- trated only on the CC and the TP specializations, it also shows that the value of the SES is the ability to generate and compare alternatives easily.

6. Conclusions

This paper has described an approach for applying database techniques to the problem of model base management. To cope with the complexity of the problem, a relational algebraic framework, called RASES, has been proposed by adapting system entity structure (SES) and relational algebra (RA) as conceptual bases. Built on top is a model base management framework for organizing modular models in a relational database and supporting the hierarchical construction of alternative models. The RASES described here is an effort to provide computer-based support for the design of complex systems.

The RASES framework has been implemented on the INFORMIX database management system. It is intended to support the work of managing large amounts of models by providing flexible and rapid access to the database. An application founded upon the framework has been described with the transaction processing system. The framework provides a powerful environment that supports the structured management of models. We are currently experimenting with more complex systems, and gradually adding features to the framework as needed.

Although this paper focused more on the model base management, the framework, with further research, can be applied to other domains if the knowledge can be represented in the form of entity structure.

References

[l] R. Agrawal, M.J. Carey and M. Livny, Concurrency control performance modeling: Alternatives and implications, ACM Trans. Database Systems 12 (4) (1987) 609-654.

[2] E.F. Codd, A relational model of data for large shared data banks, Comm. ACM 13 (6) (1970) 317-387.

[3] E.F. Codd, Extending the database relational model to capture more meaning, ACM Trans. Database Systems 4 (4) (1979) 397-434.

[4] C.J. Date, A Guide to The SQL Standard (Addison-Wesley, Reading, MA, 1989). [5] K. Higa, M. Morrison, J. Morrsion and O.R.L. Sheng, An objected-oriented methodology for

knowledge base/database coupling, Comm. ACM 35 (6) (1992) 99-l 13. [6] T.G. Kim, A knowledge-base environment for hierarchical modelling and simulation, Ph.D.

Dissertation, University of Arizona, Tucson, AZ, 1988. [7] T.G. Kim, C. Lee, E.R. Christensen and B.P. Zeigler, System entity structuring and model base

management, IEEE Trans. Systems, Man, and Cybernetics 20 (5) (1990) 1013-1024.

H. Chan Park et al. /Simulation Practice and Theory 5 (1997) 289-313 313

[8] T.G. Kim, Hierarchical scheduling in an intelligent environmental control system, J. Intelligent Robotic Systems 3 (1990) 183-193.

[9] T.G. Kim and S.B. Park, The DEVS formalism: Hierarchical modular systems specification in C + + ,

in: Proceedings of the 1992 European Simulation Multiconference (1992) 152-156. [lo] T.G. Kim and MS. Ahn, DEVSim+ + user’s manual, Tech. Rept., TR-CORE-94-l

(ftp://sim.kaist.ac.kr:/pub), EE, KAIST, 1994. [ 111 T.T. Lee and M.Y. Lai, A relational algebraic approach to protocol verification, IEEE Trans.

Software Engineering 14 (2) (1988) 184-193.

[ 121 H.C. Park, W.B. Lee and T.G. Kim, A relational algebraic framework for models management, in: Proceedings of the 1994 Winter Simulation Conference, Lake Buena Vista, FL (1994) 649-656.

[ 131 J.W. Rozenblit, J. Hu, T.G. Kim and B.P. Zeigler, Knowledge-based design and simulation environment (KBDSE): Foundational concepts and implementation, J. Oper. Rex Sot. 41 (6) (1990) 415-489.

[14] S. Sevinc and B.P. Zeigler, Entity structure based design methodology: A LAN protocol example, IEEE Trans. Software Engineering 14 (3) (1988) 604611.

[ 151 B.P. Zeigler, Multifacetted Modelling and Discrete Event Simulation (Academic Press, London, 1984). [ 161 B.P. Zeigler, C.J. Luh and T.G. Kim, Model base management for multifacetted systems, ACM

Trans. Modeling Computer Simulation 1 (3) (1991) 195-218.

[ 171 G. Zhang and B.P. Zeigler, The System Entity Structure: Knowledge representation for simulation modeling and design, in: L.E. Widman, K.A. Loparo and N.R. Nielsen, eds., ArtiJicial Intelligence,

Simulation and Modeling (John Wiley and Sons, New York, 1989) 47-73.

rases: a database supported framework for structured model...

Documents