Embedding active concepts in object-oriented languages
Claudia Pons LIFIA, Universidad Nacional de La Plata, Argentina.
[email protected]
Abstract In this paper, the bases for an Object-Oriented Programming Language that allows to express an active behavior in a uniform way is defined. The active behavior is embedded in the general behavior of the system objects. In order to determine the scope of the rules, object encapsulation is respected and class hierarchy is taken advantage of. The system behavior is being defined along the execution, since each object - when displaying its behavior (execute a method) - can add or delete active messages of the system. That is, each object has the possibility of “ruling” (dictating or nullifying rules) upon the system. The language allows to express different forms of active behavior: general, special, persistent, and ephemeral. Key Words: object oriented programming, reactive systems, programming languages, formal semantics.
1 Introduction The software crisis that broke out in the last decades obliged the researchers to look for new working methodologies so as to increase the productivity of software. developers. Work was carried out on the basis that a good software development methodology should provide at least: modularity: mastering of the complexity of main systems by means of an adequate partitioning; reuse: a software part defined for a certain context can be reused in a different context; maintenance: changes in the system can be located and implemented in an easy and economic way. The object oriented paradigm that permits to design systems in terms of objects appeared within this context; this favors the production of more legible, reusable and maintainable programs. The new paradigm achieved a fast commercial application through languages such as Smalltalk, Eiffel y C++. Together with object oriented systems, those systems based on expert knowledge and systems also became important. A new programming style arose based on rules which finds its expression in languages such as Prolog y OPS5. At present, both object oriented programming and programming based on rules are popular paradigms, being equally accepted as well. It is not possible to determine which of the two paradigms is more adequate since this depends on the task to be codified. However, there are cases where it would be desirable to be able to use both paradigms in combination because neither of them in isolation would provide optimum applicability. Basically, there are two ways of integrating object oriented systems with systems based on rules. • One possibility is to allow the programmer to include calls to an object oriented program within a system based on reglas. However, with this solution, the major advantages of object oriented
programming are lost since the languages based on rules already existing do not usually provide for encapsulation and modularity. • The other alternative is to extend an object oriented language in order to support rules. This permits to preserve all the advantages of object oriented programming as well as to gain declarative mechanisms to specify restrictions and an event guided behavior (that is, active behavior), both locally regarding an object and globally with respect to a group of object. There are several propositions to integrate active concepts with object oriented concepts, for example, the CERS-rules system [Miranker93] that supports OPS5 production rules within a C++ environment; the TANGUY system [Eick93] proposes a C++ language extension to support the reactive production rules, which react to events occurring during a system execution such as the sending of messages or changes in special object data. The Opus system [Atkinson87] and its extension, the NéOpus system [Pachet95] allow to embed production rules within the language Smalltalk-80 language. The integration of the two paradigms has also received great attention in the database field [Gatziu91, Gehani91, Medeiros91, Kappel94, Bertino94] The existing solutions allow to integrate the two paradigms. The results an hybrid systems consisting of two different languages, one for the objects and the other for the rules. In these systems, paradigms are together, but do not unify. For example, in TANGUY, classes are defined in C++, while the active behavior is defined via rules for which a special syntax is provided. Designers must define the active behavior on an individual basis and not in an integrated manner with the system classes. In TriGS [Kappel94], active rules and events that make those rules trigger are part of the class hierarchy of the application. This leads to a modeling where an event is a first class object. However, an event is conceptually a change of state of an object and not an object in itself. NéOpus eliminates the impedance mismatch among languages thus permitting to express rules in terms of Smalltalk. Nevertheless, rules are not embedded within object behavior, but they themselves constitute a distinct object within the system they govern. Our proposal aims at unifying the paradigms so that the active behavior remains embedded within the general behavior of the system objects. We wish that system developers had a frame of integral work where they could express the complete object behavior, be it active or passive, within the same language and the same level. Therefore, we define a prototype of a unified language and give its formal semantics. In our language, the active behavior is modeled by different types of rules (or active messages) written in the same language. These rules have the same hierarchy than the system common messages and form part of the object behavior.
2 Messages in Object Oriented Systems Traditional object oriented systems are not adequate to represent an event-guided behavior; this is due to the fact that traditional objects only react when receiving a message, and they cannot automatically react before certain system state changes. That is, traditional objects only respond to commands, they do not possess any capacity to start any actions on their own decision. Consequently, in order to model an active behavior, it is necessary to add a new category of messages: Active Messages. An active messages do not have a sender object, they trigger themselves automatically in response to an event, that is, when the system reaches a particular state. The word rule will be used to refer to these active messages. A rule has the form < conditions Exp actions Com>, Exp being an expression representing the conditions that must be fulfilled for the event to occur. Com is a command representing the actions occurring in response to the event.
Active Message Classification Different rule categories are distinguished considering their scope regardings the objects they involve, and with respect to their life time.
a - According to the objects they involve: A rule may refer to a special group of objects, or it may refer to generic objects. Category a.1: General Rules they involve a generic set of individuals. For example, at a certain Bank, the financial policy is to close the accounts when their balance is below a minimum established balance. This may be represented by the following rule, valid to all instances c of the class Bank Account. Rule “Account with a debit balance”: conditions: account c is active, and c balance is below the minimum actions: close account c. Category a.2: Special Rules they involve a constant set of individuals. For example: Mr.Smith is a special Bank customer who is given automatic loans when his account balance go down beyond the minimum, then, in his case, the rule is defined as follows: Rule “Mr.Smith’s debit balance”: conditions Mr.Smith’s account is active, and its balance is below the minimum. actions deposit $10000 in Mr.Smith’s account. b - According to their life time Category b.1: Persistent Rules they can be executed many times (they model recurrent events). For example, the rules for “Debit Balance Accounts” and “Mr.Smith’s debit balances”. Category b.2: Temporary Rules they are executed only once and then disappear (they model an event that occurs only once). In section 5 an example including this kind of rules is described.
3 Object Semantic Domains In this section, the domains to interpret active objects are defined. These domains will provide the foundation to express the semantics of the programs that manipulate objects. • Object = (Bvalue x Behavior x List_Rule) , object domain. • Bvalue, primitive domain for basic values (e.g.: bool, nat). •Behavior=[Message → Method] object behavior domain. A behavior is a table that associates each message with the method the object will compute to answer the said message. • Message = String, primitive domain for message names. This domain is partitioned in Observer_Message and Mutator_Message.. • Method = Exp + Com, method domain. A method may be an expression (observed method) or a command (mutator method). • List_Rule, domain for rule lists. Fig. 3.a - Semantic Domains for Objects
The domain where the objects become significant is the set of records in a similar form to that proposed by Cardelli [Cardelli85]. More precisely, an active object is modeled as a group of three elements where the first component is the internal state, the second is the passive behavior (the set of all the methods that the object can execute (its own or inherited)), and the third are the particular rules that determine its active individual behavior. Let us consider that the set of methods of an object is partitioned in two subgroups: observers and mutators. An observer returns a result without altering the internal state of any of the objects. A mutator modifies one or more states of objects. Figure 3.a shows the Object semantic domain definition. In an object oriented system, each object has a unique identifier (generally called oid). However, these identifiers are not visible and the programs manipulate objects by means of symbolic names (or variables). In figure 3.b Env and Store the semantic domains are defined. An environment is a function that associates symbolic names with expressable values . An expressable value may be a basic value or an object identifier. These functions are not necessarily injective, thus permitting that two or more names refer to the same object in a program. A store is a function that associates oids with objects. These functions are injective and make sure that each object possesses a single oid. • Oids, primitive domain for identifying objects. •Vars, primitive domain for names of variables. • Evalue = Bvalue + Oids, domain for expressable values. • Env = [Vars → Evalue] domain for variable environment. An environment is a function that binds names of variables with expressable values. • Store = [Oids → Object ] domain for storing objects. A store is an injective function that binds object identifies with objects. Fig. 3.b - Semantic domains for Object Systems.
4 A reactive object oriented language In this section, we consider a simple programming language that provides the programming constructions to support object oriented programming (such as class definition and parallel sending of messages), and also permits to express active messages (rules) within a uniform frame with the remaining messages of the system. Syntax:
1- Syntactic Categories :
2. Definitions:
D::=Class s1 Methods list_meth Rules list_r Superclass s2 D in Declarations meth in Meth meth ::= obs_method o(x) e | mut_meth m(x) c o in Observer_Message m in Mutator_Message e::= bv | f(e1,..., ek) | x| state(x) | e1.o(e2) bv in Bvalue c ::= skip | update(x,e) | ch?x | ch!e | x:= e | x:=new(s) s in String ch in Channel e1.m(e2) | c1;c2 | c1||c2 | insRule(r) | delRule(s(x)) e in Exp r::= (name s(x) conditions e actions c) c in Com p in Prog list in List f in Fun p ::= Program list_D c r in Rule x in Vars Bold type was used to indicate the language terminal symbols (e.g. Class, Methods, skip). List_x is a generic abbreviation representing finite lists of type x elements, that is, list_x:: = x | x:list_x
A program in this language includes class and command declarations. Class declaration includes a name for the class and a sequence of methods (representing the traditional passive behavior of objects). Each method may be an observer or a mutator. The body of an observer method is an expression, while the body of a mutator method is a command. A class declaration also includes a list of general rules, applicable to all class instance. The special rules are not declared, instead, they are dynamically created in the execution time. Expressions involve: - basic values,- function terms, - variables (including the special variable self that represents the object itself), - the term state(x) that represents the hidden internal state of the object bound to variable x, - the term e1.o(e2) that represents the sending of an observer message with an e2 parameter to the object resulting from the evaluation of the expression e1. Commands include: - skip, the command that does not perform any action, - the command update(x,e) which represents the modification of the internal state of the object bound to variable x, being assigned the expression e (in syntactically correct programs, the only variable that may occur as a parameter of state and update is the special variable self) , - data input and output, - assignment, - new(s) representing the creation of a new class s object, - sending of a mutator message, - the operator ; indicating sequential composition of commands, - the operator || indicating parallel composition, - insRule(r) to add a new special rule particular to the systems, and delRule(s(x)) to eliminate a special rule.
General and Special Rules Language allows to structure rules in the following way: general rules associated with class declarations, and special rules encapsulated within the objects. The scope of the rules (individuals upon which each rule is potentially applicable) is determined by the system class hierarchy. A general rule is applicable to all class instances where it is defined, and also to all its subclass instances. The evaluation of a general rule condition has an O(n) time complexity, being n the quantity of objects in the class (including subclasses). Special rules refer to individual objects. The evaluation of a special rule condition has an O(1) time complexity. The system behavior is being defined during execution, since, when displaying its behavior (execute a method), each object can add or delete active messages of the system. That is, each object has the possibility of “ruling” the system (dictating or canceling rules).
Semantics: Concepts of the structural operational semantics formalism [Hennessy90] will be used. Variables δ, σ, bv, ev, obj and oid denote elements of the Env, Store, Bvalue, Evalue, Object and Oids sets respectively.
Semantics of the expressions : Expressions denote basic values or object identifiers (we refer to the semantic domain of the expressions as expressable values, Evalue,). We assume that it is of no interest to observe the computation process of the expression; therefore, we define a function directly associating each expression with the final value it denotes. Function ⇒e is defined by means of rules as follows: ⇒e :: < Exp , Env , Store > → Rule BR
Rule VarR
Rule StateR
(bv,δ,σ) ⇒e bv
(x,δ,σ) ⇒e δ(x)
(state(x),δ,σ) ⇒e Π1(σ (δ(x)))
Rule BR indicates the meaning of a basic value. Rule VarR refers to variable evaluation. According to rule StateR, state(x) denotes the internal state of the object that at the time of evaluation is bound to variable x. In our domain, objects are records of three elements . Π1 represents the first projection of the record, that is to say, the internal state of the object. FunR describes the primitive function evaluation (such as integer addition). ObsR describes the observer message evaluation. The expression e1 denotes the receiver object identifier of message o. We call B the behavior of this object. Then B(o) is the method that the object computes as a response to message o. To evaluate the method (which is an expression) the special variable self instances with the receiver object and the formal parameter x instances with the real parameter ev. Rule FunR (e1,δ,σ) ⇒e bv1 ........... (ek,δ,σ) ⇒e bvk
Rule ObsR (e1,δ,σ) ⇒e oid (e2,δ,σ) ⇒e ev (B(o), δ[oid/self] [ev/x],σ )⇒e ev’
(f(e1,.., ek),δ,σ) ⇒e Apply(f, bv1 , ..., bvk)
(e1.o(e2),δ,σ) ⇒e ev’ where, B = Π2(σ(oid)).
Semantics of the commands : We call Act the set of primitive actions, Act= { c?bv / c in Chan , bv in Bvalue } ∪ { c!bv / c in Chan , bv in Bvalue } ∪ { ε } This set consists of the data input and output actions and of the internal action ε. An internal action is an action that cannot be externally observed, for example the store modification or the internal communication of two commands running in parallel. , one for each action a, of the The computation semantics of our language is given by the relations type ::: → , where the sentence (c,δ, σ) (c’,δ', σ') means that command c can execute a primitive action a on environment δ and store σ transforming them in δ' and σ' respectively, remaining in c’ all that has not been executed yet of command c. Besides, to provide the meaning of the language, it is necessary to take into account the class declarations defined by the user; we are specifically going to define parametered relations on class declarations. Command rules use a termination predicate 9 (Figure 4.a), whose definition is classic [Hennessy90]. Due to space limitations, only some of the rules defining the command semantics are presented. Rule InR D |− (ch?x,δ,σ)
(skip, δ[bv/x] , σ)
Rule InR describes the meaning of command ch?x which allows to read channel ch and to put the read value within variable x. The object store is not modified.
Rule NewR denotes the creation of a new object. Function next_oid returns an unused . identifier to the store, be oid= next_oid(σ). D |− (x:= new(s),δ,σ) (skip, δ[oid/x] , σ[obj/oid] ) This identifier is bound to variable x in the where, there is in D a class declaration : environment. Function Sem builds a new Class s Methods m Rules r SuperClass s2 class instance from its declaration. Its type is Sem:: Declarations → Object. For a detailed description of the function (including the class definition treatment using inheritance) see [Pons95]. Be obj = Sem(Class s Methods m Rules r SuperClass s2) that new instance, obj is bound to the new identifier in the store. Rule NewR
Rule AssR (e,δ,σ) ⇒e ev D |− (x:= e,δ,σ)
According to rule AssR, the assignment command only modifies the environment binding variable x with the result of expression e evaluation. Object store is not modified.
(skip, δ[x/ev] , σ )
Rule UpdateR describes the meaning of the update command. Function modify modifies the object internal state and is defined as Rule UpdateR follows: modify :: (e,δ,σ) ⇒e bv (Object,Bvalue) → Object modify ( , bv’) = D |− (update(x,e),δ,σ) (skip, δ, σ[modify(σ(δ(x)),bv) / δ(x)] )
Rule MutR describes the evaluation of a mutator message. Expression e1 denotes the identifier of message m receiver object. We call B, the behavior of this object, that is B = Π2(σ(oid)). Then, B(m) is the method that the object computes as response to D |− (e1.m(e2),δ,σ) (c, δ[oid/ x1][ev/x], σ) message m. In the method text (which is a where c= B(m)[ replace self with x1] command) the special variable self is se replaced by x1 is a fresh variable, it means δ(x1)=unbound. a variable that does not occur in the system to avoid conflict with the shared variable self. This new variable is bound with the receiver object and the formal parameter x is instanced with the real ev parameter. Rule MutR (e1,δ,σ) ⇒e oid (e2,δ,σ) ⇒e ev
Rule OutR (e,δ,σ) ⇒e bv
The ch!e command allows to write the value of the expression e in channel ch. The environment and the object store are not modified. (skip, δ, σ)
D |− (ch!e,δ,σ) Rule Seq1R D |− (c1,δ,σ)
Rule Seq2R (c’,δ',σ')
(c1,δ,σ)9 D |−(c2,δ,σ)
D |−(c1;c2,δ,σ)
Rules Seq1R and Seq2R specify the command sequential composition behavior.
(c’,δ',σ')
(c’;c2,δ',σ') D |− (c1;c2,δ,σ)
(c’,δ',σ')
Rule Par2aR Rule Par1aR D |− (c1,δ,σ) D |− (c1|| c2,δ,σ)
(c’,δ',σ') (c’ || c2,δ',σ')
D |− (c1,δ,σ)
(c’1,δ',σ')
D |− (c2,δ,σ)
(c’2,δ,σ)
D |− (c1|| c2,δ,σ)
(c’1|| c’2, δ',σ')
Rules Par1aR, Par2aR (and their two symmetrical rules Par1bR y Par2bR) define the parallel composition semantics. Commands c and c’ go independently inserting their primitive actions. Rule Par2R permits the communication between commands. If c1 can receive a value from channel ch and c2
can send the same value to the same channel, then c1 and c2 can communicate with one another (communication handshake). This communication is an internal action. Rule InsR defines the creation of a new special rule. Rule r, being special, involves individual objects. Variables contained in r at the time of D |− (insRule(r),δ,σ) (skip, δ' , σ') the rule creation denote those individuals. Since where < r’, δ' > = const(r , δ) ; σ' = insert(σ, δ', r’) variables can be modified (by assignments after to the rule creation and before its execution), it is necessary to replace them by constants. This is performed by the const function. Function insert adds the constant rule in each of the objects it involves. Rule InsR
Rule delR D |−(delRule(s(x)),δ,σ) where σ' = delete(σ,δ, s(x))
. (skip, δ, σ')
Rule SkipRt (skip, δ,σ) 9
Rule delR indicates the meaning of the delRule command which eliminates a system special rule. Function delete eliminates rule which name is s(x) from the corresponding objects in store σ.
Rule ParRt (c1,δ,σ) 9
Rule ComRt (c1,δ,σ) 9
(c2,δ,σ) 9
(c2,δ,σ) 9
(c1||c2,δ,σ) 9
(c1;c2,δ,σ) 9
Fig.4.a: Termination Predicate
9
Semantics of the programs : The semantics of program computation is given by the relations, one for each sequence of primitive actions λ, with λ in Act*. These relations are defined in Figure 4.b by rule ProgramR. p1 p2 ...pn-1. Q Notation : P Q si λ = a1 a2...an y P Rule ProgramR indicates that the program begins executing the commands contained in the main from an initial store σ0 and an initial environment δ0. These commands will usually create the system objects, dictate some special rules, and send imperative messages to the objects so that they start displaying their activities. After executing the main, the system evolves in the same style as that of a production system. Each computation step involves a rule selection (general or special) and its execution. The program ends when no rule possesses a condition evaluating true. This is indicated by the “end” predicate (Figure 4.e). The relation represents a computation step. Each computation steps consists in selecting a rule and its complete execution (until reaching a state where the end predicate 9 is true). , parametered by the declarations, is defined in Figure 4.c. The relation choose (Figure The relation 4.d) returns a rule whose condition evaluates true, and presents a non- deterministic behavior since more than one rule can evaluate true. Choose also returns the environment containing a possible instantiation of the variables occurring in the rule and returns the modified store when the rule is temporary. When the selected rule is special, the environment is not modified since the rule does not contain variables, and when the selected rule is persistent, the store is not modified since the rule remains stored.
:: < Prog > →
Rule ProgramR D |- (c , δ0 , σ0)
Rule ForwardR (c’, δ, σ)
(c’, δ, σ) 9 D |- (δ, σ) D |-
:: < Env , Store > → < Env , Store >
(δ', σ')
D |-
(δ, σ) choose (r, δ’, σ')
D |-
(c, δ’, σ') (c’, δ'‘, σ'‘ 9
(δ', σ') end
(c’ , δ'‘, σ'‘)
D |- ( δ, σ)
(δ', σ')
where λ is the compound of λ1 y λ2
( δ'‘, σ'‘)
where r is (name s conditions e actions c) Figura 4.c.: the relation
Figura 4b : programms semantics
,
choose :: < Env, Store> → < Rule, Env, Store>
Rule pt_Choose
Rule pp_Choose
(rp, δ,σ) part_chs r
(rp, δ,σ) part_chs r
(rg,δ,σ) gen_chs (r, δ‘)
temporary(r)
persistent(r) . . D |- (δ,σ) choose (r,δ,σ)
. D |- (δ, σ)choose (r,δ‘,σ)
. D |- (δ, σ)choose(r, δ, σ')
Rule GenChoose
where σ‘=delete (σ,r) Rule part_chs1 (e, δ,σ) ⇒e True
Rule part_chs2 ( s1, δ,σ) part_chs r
. ({(e→c) },δ,σ) part_chs (e→c)
(s1Us2, δ,σ) part_chs r
Rule gen_chs1 ∃v : (e, δ[v],σ) ⇒e True . ({(e→c) },δ,σ) gen_chs ((e→c),δ[v])
Rule gen_chs2 ( s1, δ,σ) gen_chs (r, δ‘) (s1Us2, δ,σ) gen_chs (r, δ‘)
Rule part_chs3 ( s2, δ,σ) part_chs r . (s1Us2,δ,σ) part_chs r Rule gen_chs3 (s2,δ,σ)gen_chs (r, δ‘) . . . (s1Us2,δ,σ)gen_chs (r, δ‘)
Where rg=Rules(D) is the set composed by the general rules which are contained in the classes and rp=Rules(σ) is the set composed by the general rules which are contained in the objects. v is a valuation of the variables which are contained in the rule.
Fig 4.d: Relation choose
Rule End (rg, δ,σ) gen_end (rp, δ,σ) part_end . D |- (δ,σ) end Rule EmptyPRt ( {}, δ,σ) part_end
Rule EmptyGRt ( {}, δ,σ) gen_end
Rule UnitPRt (e, δ,σ) ⇒e False ({(e→c) } δ,σ) part_end
Rule UnitGRt ∀v: (e, δ[v],σ) ⇒e False ({(e→c) } δ,σ) gen_end
Rule JoinPRt ( s1, δ,σ) part_end ( s2, δ,σ) part_end . (s1 U s2, δ,σ) part_end Rule JoinGRt ( s1, δ,σ) gen_end ( s2, δ,σ) gen_end . (s1 U s2, δ,σ) gen_end
Fig.4.e: termination predicate end
5 Example When a Bank customer stands in a teller’s waiting queue, he decides (regarding his patience and spare time) how long he will remain in the queue. If he has not been helped, once that time is over, he will leave the queue. This example describes an event we will refer to as WaitingTimeLimit. This event triggers an active message that we will call becomeImpatient. The WaitingTimeLimit event occurs when the following condition becomes true: “The customer’s waiting time limit in the queue has gone by”. The active message becomeImpatient, whose receiver object is an instance of the Customer class, makes the object leave the Waiting Queue.
NéOpus Implementation The reactive behavior of our example can be modeled with the rule WaitingTimeLimit in Fig 5.a. NéOpus evaluates this rule for all instances of the customer class, either the be or not in the waiting queue; therefore, it is necessary to enter the condition that customer C belongs to queue Q in the rule.
Rule WaitingTimeLimit | Customer C. WaitingQueue Q | conditions Q belongs (C) C enteringQueueHour + C limitTime = Clock hour actions C becomeImpatient(Q) Figura 5.a: NéOpus Rule
Implementation in our unified language mut_meth standInQueue ( Q : WaitingQueue) When entering the bank, the customer received the Q.enterQueue (self); message Stand in the Queue. In response to this self.enteringQueueHour := Clock hour ; message, he will perform the following acts: a) stand insRule ( name WaitingTimeLimit(self) in the waiting queue, b) generate a temporary rule to conditions self enteringQueueHour + model the potential event that he decides to leave self limitTime = Clock hour the queue before being helped. The active message actions self becomeImpatient(Q ) ) becomeImpatient remains embedded in the method Stand in Queue, as it can be seen in Figure 5.b. mut_meth becomeImpatient(Q:WaitingQueue) Q leaveQueue(self); self leaveTheBank Figura 5.b.: some methods of the Customer Class.
If the customer is helped before his maximum waiting time in the queue expires, then mut_meth nextOnePlease (Y : Cajero) the previous rule should be discarded. ( self notEmpty ) This act remains embedded in the ifTrue method Next One Please (of the waiting C:= self leaveQueue; queue) as it can be seen in Figure 5.c. delRule ( WaitingTimeLimit(C ) ) ifFalse skip Figura5.c.: a method of the WaitingQueue Class. Difference Analysis •
In NéOpus, active rules are not part of the method, but they reside in an independent rule base. With our language, it is possible to define rules in an integrated way in the methods. • In NéOpus, there is a single general rule for all customers; in our model a special rule is created for each customer that stands in the waiting queue. Therefore, to evaluate if the event has occurred, only the customers included in the queue, not all the Bank customers, will be analyzed. For the same reasons, it is not necessary to enter the condition that C belongs to Q in the rule. • In NéOpus, rules are persistent, thus, the rule WaitingTimeLimit will continue being evaluated even if no customer were in the queues. In our model, the rule is ephemeral, after being executed, it disappears. This behavior is inadequate for when the customer leaves the queue, he can no longer become impatient. If the same customer decides to return to the Bank and stand again in the waiting queue, then the method Stand in Queue will generate a new rule allowing him to become impatient again.
6. Conclusions Programming based on rules is more adequate than object oriented programming for codifying reactive tasks. There are proposals that permit object oriented programmers to use the advantages of rulebased programming in an object oriented environment, the result is a product where the two paradigms live together (are integrated) but do not unify. We have defined the bases for an object oriented programming language that allows to express active behavior in a uniform way. Active behavior remains embedded in the general behavior of the system objects. The object encapsulation is respected, and class hierarchy is taken advantage of to determine the scope of the rules. The system behavior is being defined during the execution, since each object, when displaying its behavior (execute a method), can add or delete active messages of the system. That is, each object has the possibility of “ruling” (dictating or canceling rules.) on the system. Language permits to express different forms of active behavior: general, special, persistent, and ephemeral. This facilitates the development of certain applications, for example, the ephemeral rules
permit to model events in a natural form, thus, avoiding the need to resort to an elaborate design (where the events are treated as first class objects, as in [Haythorn94]). On the other hand, formal specification provides an accurate description of the language constructions, facilitating the development of reliable software, and giving the bases for testing its correctness.
References [Atkinson87] Atkinson,R and J. Laursen , “Opus: a Smalltalk production system”, SigPlan Notices 22, 1987. [Bertino94] E.Bertino, G.Guerrini and D Montesi, Deductive Object Databases, Proceedings ECOOP’94, July 1994, LNCS 821. [Cardelli85] Cardelli, L.,Wegner P. On Understanding Types, Data Abstraction and Polymorphism. Computing Surveys, 17(4). 1985. [Eick93] C. Eick and B. Czejdo, “Reactive Rules for C++ “, Journal Object Oriented Programming October 1993. [Gatziu91] S. Gatziu, A. Geppert, K.Dittrich, “Integrating Active concepts into an object-oriented database system”, Proceedings of the 3rd Workshop on database programming Languages, Nafplion 1991. [Gehani91] N. Gehani, H.Jagadish, “Ode as an active database: constraints and rules”, Proceedings of the 17th International Conference on VLDB, Barcelona 1991. [Haythorn94] Wayne Haythorn, “What is Object Oriented Design”, Journal O O P April. 1994. [Hennessy90] M.Hennessy, “The Semantics of Programming Languages: An elementary introduction using structural operational semantics” Copyright 1990 by J Wiley&Sons. England. Chapter six. [Kappel94] G. Kappel, Rausch-Schott, W.Retschitzegger and S. Vieweg, “TriGS: Making a passive object-oriented database system active”, Journal OO Programming, August 1994. [Medeiros91] C. Medeiros and P.Pfeffer, “Object integrity using rules”, Proceedings of ECOOP 1991, LNCS 512. [Miranker93] Miranker, D, Burke, Steele, et al. “The C++ embeddable rule system”, International Journal On Artificial Intelligence Tools, 2(1), 1993. [Pachet95] F.Pachet, On the embeddability of production rules in object-oriented languages, Journal Object Oriented Programming, August 1995. [Pons95] C.Pons, "Formal Semantics for Object-Oriented Systems" . Procs. of 7th International Conf. on Software Engineering and Knowledge Engineering (SEKE'95), may 1995, Maryland, USA
