eca-rule visual programming for ubiquitous and nomadic computing

ECA-Rule Visual Programming for Ubiquitousand Nomadic Computing

Jose Oscar Olmedo-Aguirre1, Monica Rivera de la Rosa2,and Guillermo Morales-Luna3,�

1 Electrical Engineering, CINVESTAV-IPN, Mexico City, [email protected]

2 Escuela Superior de Computo, ESCOM-IPN, Mexico City, Mexico3 Computer Science, CINVESTAV-IPN, Mexico City, Mexico

[email protected]

Abstract. System modeling, analysis and visualization are becoming acommon practice for the design of distributed intelligent systems since thewide adoption of the Unified Modeling Language (UML). However, UMLcannot describe important behavioral properties such as context aware-ness as required for ubiquitous computing. In this paper, we present Con-text Aware UML Sequence diagrams (CA UML-S), an experimental visualprogramming language that extends UML sequence diagrams with data/object spaces to represent computational context awareness.Theprogram-ming language provides the means to describe the event-condition-action(ECA) rules that govern complex nomadic user behavior and to visualizetheir effect.TheECArules are compiled into common concurrent program-ming abstractions by introducing structuring notions of object creation,synchronization, and communication, along with sequential and selectivecomposition of simpler rules. The contribution of this work is in provid-ing programming abstractions that facilitate the design of context-awareapplications for ubiquitous and nomadic computing.

1 Introduction

Mark Weiser introduced the term ubiquitous computing [1] to describe an en-vironment where a fixed computational and communication infrastructure willhelp nomadic users to conduct their activities unconscious of the infrastructure.However, the design and construction of context-aware applications in the highlydynamic setting of ubiquitous computing has been recognized as a difficult un-dertaking. In this respect, rule-based programming is proposed to improve ourunderstanding of complex program behavior. Rule-based specifications are usedin reactive systems that are monitored for the occurrence of events that maysignal critical conditions. In rule-based systems, once an event is detected, ifthe event parameters satisfy certain condition, a specified action is performed tohandle the situation. The language construct that corresponds to this model of

� Olmedo and Morales acknowledge the partial support of Mexican Conacyt.

A. Gelbukh and E.F. Morales (Eds.): MICAI 2008, LNAI 5317, pp. 925–935, 2008.c© Springer-Verlag Berlin Heidelberg 2008

926 J.O. Olmedo-Aguirre, M. Rivera de la Rosa, and G. Morales-Luna

interaction is called ECA-rule (Event-Condition-Action–rule). Such rules arisefrom the fact that a distributed system is a system whose behavior is driven bythe events of receiving messages and by the actions of sending messages. ECA-rules can be adopted as the basis for data representation, message exchange,and coordination specification in distributed applications [2]. Rule-based systemsmay as well evolve into complete programming languages aimed to coordinatesoftware agents with proactive, rational and social behavior. ECA-rules consti-tute a powerful programming paradigm, though their interactions are very oftendifficult to understand because they are generally not designed to be applied ina structured or hierarchical manner.

With the purpose to make rule interactions easier to understand, we propose touse UML sequence diagrams to visualize rule definition, selection and execution.We believe that rule definition can be easily understood by means of a shortUML sequence diagram that exposes the event-condition-action structure of therule. Furthermore, rule selection and instantiation becomes more coherent as thecollection of sequence diagrams are identified by the events they handle. Ruleexecution may become more understandable because rules are grouped aroundobjects in a sequential or parallel manner.

Unfortunately, the programming environments that have adopted UML di-agramming as the basis for its design methodology are used at best for thegeneration of program skeletons in programming languages as Java and C++just because UML diagrams cannot be directly executed. Although replacingthe textual representation of a programming model for a visual one represents asubstantial step in abstracting algorithm design from program coding, programbehavior still cannot be visualized directly from UML diagrams as the programexecution is not integrated into the environment.

We propose the construction of a visual programming language that addressesthe afore-mentioned problems. By integrating visualization in the program speci-fication and execution, the programming language offers a number of outstandingadvantages from previous work:

– Priming algorithmic design over program coding– Abstracting algorithms from programming languages and platforms– Specifying and visualizing program behavior with UML sequence diagrams

We outline the content of this paper. In section 2, we compare our proposal withsome related work in the areas of program visualization and formal methodsused. In section 3, fundamental concepts of Context Aware UML-S are presentedand illustrated with an example of user guiding from nomadic computing. Thevisual specification and execution of ECA rules is discussed and analyzed insection 4. The programming model in the structured operational semantics styleis presented in section 5. Finally, in section 6, we present our concluding remarks.

2 Related Work

Visualization of concurrent programs is more complicated than visualization ofsequential programs, due to the presence of multiple communicating threads,

ECA-Rule Visual Programming for Ubiquitous and Nomadic Computing 927

establishing a competition for resources, and requiring periodical synchroniza-tion. The misunderstanding of concurrent programs behavior may result inunexpected interactions and non-deterministic executions. However, some vi-sualization tools have been realized to overcome these issues. In the Gthreadslibrary [3] a program graph is built as threads are forked and functions arecalled. The vertices of the graph represent program entities and events, whilethe edges represent temporal orderings among vertices. Message passing viewsare supported by the Conch system [4] where processes appear outside of a ringand messages are exchanged among them by traversing the ring. In this way, un-delivered messages can be detected as they remain within the ring. The Hencesystem [3] offers animated views of the program graph obtained from executionof PVM programs. None of them use standard UML diagrams to describe pro-cess interactions. Programming and visualization of sequential programs usingan UML-like visual programming language has been explored in Moon [5], whichis the base of the current prototype implementation of CA UML-S diagrams.

Recently formal models based on Petri nets have been applied to ubiquitouscomputing due to their intuitive graphical representation and well establishedtheoretical foundation. An Elementary Object System (EOS) [6] is a two-levelnet description consisting of a system net marked by high-level structured tokensrepresenting object nets. Object nets can change their marking but not theirstructure, following the principles of object-oriented modeling. EOS has beenused to model mobile user behavior. Further refinement of EOS are Nested PetriNets (NPN) [7] which are multi-level net descriptions to model hierarchical multi-agent dynamics. In NPN, object nets have their own structure and behavior, be-ing able to appear, to evolve or to disappear during lifetime, and their numberis unlimited. An NPN has four steps: transfer, object-autonomy, horizontalsynchronization and vertical synchronization steps. A transfer step canmove, generate or remove objects with no change of their inner states. Anobject-autonomy step can change the inner state of one object. horizontalsynchronization conveys simultaneous firing of two object nets situated in thesame place of a system net. vertical synchronization means simultaneousfiring of the system net with one of the object nets involved in the firing. Ubiq-uitous Nets (UN) [8] allows modeling both devices (processor nets) and softwarecomponents located at processors (process nets). In the model, processes changetheir location due to the firing of special movement transitions.

3 CA UML-Sequence Visual Programming Language

UML-sequence (UML-S) diagrams describe the behavior of a system developedby the interaction of the participants. These diagrams contain objects (classes)that exchange messages arranged in a time sequence. They are defined accordingto class roles, lifelines, activations and messages [9]. Illustrative examples of thesediagrams are shown in [10]. Class roles, denoted by rectangles surrounding therole-name and the class-name, specify the type of objects that may participatewith interactions and collaborations. Lifelines, denoted by vertical dashed lines,


represent the existence of class roles over a period of time, since the objectcreation until its destruction. They may split into concurrent lifelines to showconcurrency or conditionality, each corresponding to a thread or a conditionalbranch and they may merge together at some subsequent point. Activations,denoted by thin vertical rectangles arranged along lifelines, represent the timeduring which a class role is performing an action (operation) or when it is activeand has focus of control. Finally, messages, denoted by labeled horizontal arrowsbetween lifelines, define the information content of a communication that isexchanged in interactions and collaborations. The message instance has a sender,a receiver and possibly other information according to the characteristics of therequest. Messages may be either synchronous (solid arrow heads), with explicitor implied return (stick arrow heads), or asynchronous (half stick arrow heads).

Upon standard UML-S diagrams, new diagrammatic elements are introduced,among explicit program states, data/object spaces, computational context andcontext awareness, in order to define Context Aware UML-S or CA UML-S visualprogramming language. Explicit program states (configurations) are representedby graphic elements similar to those used for class roles except that they ap-pear along the timeline possibly with a note containing an assertion about theprogram state. Explicit program states are useful because they can simplify therendering of visual programming constructions to reflect the change of the ob-ject configuration. Data spaces contain heterogeneous collections of pieces ofinformation that are stored in a single or a networked cluster of computationaldevices. Object spaces contain data communication enabled objects that can bedetected if they are within the scope of a short range local area network, andcan be identified by the physical coordinates of the communication base of thenetwork. Data/object spaces can be seen, in abstract terms, as partitions of theentire data collection and the objects found in the environment. Data/objectspaces are identified by unique global identifiers. In CA UML-S, a space is rep-resented by a rounded box labeled by the space name. Computational contextis the entire computation, communication and coordination infrastructure con-formed by sensors, actuators, computational, and communication devices thatthe environment offers to enable users and agents to interact with them and withthe environment. Thus, the computational context enables ordinary objects tohave a presence in this form of extended reality. Context awareness of a mobileuser or agent is the ability to perceive this extended reality by identifying thespaces and the objects that populate them. The entities located in a space areidentifiable and shared resources that can be accessed by users and agents thatare aware of the existence of such a space.

Users and agents are aware of spaces if they know the name that identifiedthem. As proposed in this work, CA UML-S for ubiquitous computing extendsthe class role notation to accommodate the name of the space to which a classinstance interacts. Such a space name can be avoided in the diagram by drawingan arrow pointing to the current space to which the object is aware. Note thatspace variables describe the local topology of the object neighborhood and canchange their values to reflect the local space context awareness.


(a) (b)

Fig. 1. Guide telling to the locations along a path where the visitor should move on

CA UMLS diagram composition is exemplified with a recurrent mobility prob-lem in nomadic computing about how to guide a visitor to his/her destination.Figure 1 shows a CA UML-S diagram displaying the interaction that the guidemaintains with the local communication infrastructure. Assuming the entire re-gion is partitioned into a grid of addressable physical locations, each of suchlocations comprises a data/object space that contains information about thelocal topology of its neighbor locations (i.e. north, east, south, etc.). The in-teraction begins when, either the guide sends to the current location a messagetelling which neighbor location to move on next or the visitor sends a subscrip-tion to the current location to receive the messages from the guide. In particular,in Figure 1(a) the guide sends the message to the visitor local space suggestingto move on to the north and this message is forwarded later on to the visitor.The CA UML-S synchronization (dark gray) bar specifies, with no time-orderingrestrictions, all the messages that are expected to be received (incoming arrows)before some responsive actions may take place (outgoing arrows).

The recurrent pattern shown in Figure 1(a) is concisely represented by a dou-ble headed arrow as illustrated in Figure 1(b). It is properly defined because for-warding a message from the space to the subscriber can only happen when boththe message and the subscription were received before at the space. This simpli-fication can be used only when the message sender is not needed to be known inthe rule description. This is a reasonable assumption because data/object spaceswere conceived to decouple the interaction among the participants. Besides, thenotation emphasizes the more relevant aspects of specifying what data/object isrequired and from which location should be taken.

Using the Dijkstra’s algorithm to find a minimal path between two connectedpoints in a map, the locations lying in the minimal path can be determined. Thenthe guide places a notification addressed to the visitor in all the locations alongthe path. The notification indicates in what direction the visitor must move onnext to get closer to its destination. The visitor is aware of the data/object spaceof the current location and places a subscription on it to receive the notificationof where to move on. When both, the subscription and the notification become


available, the local space forwards the notification to the visitor, who then de-termines the physical address of the next location. By repeating this process,the locations lying in the path take the visitor to its destination.

Unfortunately UML-S diagrams were conceived having no applications to no-madic computing in mind. Therefore the fundamental concept of locality is notrepresented in the diagrams, and in consequence this interaction cannot be mod-eled in UML. Though a partial solution can be devised by using UML stereotypesto define a new entity, this approach neglects the fundamental knowledge repre-sentation problem that poses human or process mobility. In our approach, UML-S for ubiquitous computing extends the class role notation to accommodate thename of the location to which a class instance interacts. Such a location namecan be avoided by using instead an arrow that points to the current location.Although simple, this solution proves to be expressive enough to model com-plex interactions in nomadic computing that cannot be represented otherwisein UML.

4 ECA Rule Programming in CA UML-S

The CA UML-S synchronization bar constitutes the fundamental visual con-struction to define ECA rules in the programming language, because theycomprise events, conditions and actions. Events, denoted by incoming messagearrows with no time-ordering restrictions, are notifications of the execution ofobservable actions. Conditions, denoted by logical expressions written in notes,are constraints defined upon the contents of the events and the object config-urations to select those that satify the contranints. Actions, denoted by eitheroutgoing message arrows or explicit object configurations, are operations thatmodify the object state and its awareness of the local context. Figure 2 showstwo rules depicted in the CA UML-S visual language using the synchronizationbar. Each rule renders two possible scenarios that arise from the conditions thatmay occur. Even with the few elements presented here, it can be shown thatvery complex and interesting behaviors can be visually described. Among theexperiments we have conducted so far, hypermedia architectures, simple work-flow systems, collaborative systems and Turing machines are among the mostnotorious. Hill Climbing and other search space techniques used in ArtificialIntelligence are currently being investigated.

The Hill Climbing problem consists of finding a location containing data or ob-ject attributes that maximizes a function. The solution to this problem consistson evaluating the function on the neighbor locations and selecting the locationthat increases the value of the function. This evaluation, selection and move-ment process is repeated until a (local) maximum is reached. Figure 2 showstwo visual rules that are part of the solution of a bi-dimensional version of theHill Climbing problem. As the figure shows, the visitor is aware of the currentlocation in which he/she stands up, and the one on the left and the one onthe right of the current location. This is depicted by the outgoing arrows fromthe visitor instance box to the corresponding space instance boxes in the upper


(a) (b)

Fig. 2. A bi-dimensional Hill Climbing program description

part of the drawing. The visitor moves when its current location is changed byany of its two neighbor locations. The selection is taken for the location thatcontains the greater value obtained from sensor reading of the location heightand from object property h that keeps the currently known local maximum. Thesynchronization bar on the visitor object receives message height from bothlocations to be able to make the selection. The restriction note at the right ofthe synchronization bar describes the selection criteria for each case. As a result,the actions consist in updating the values of the object properties that reflect achange in its context awareness. Fig. 2(a) and 2(b), respectively, shows that theuser moves to the left or to the right of the current location.

5 Operational Semantics of CA UML Sequence Diagrams

Formal interpretation of CA UML-S diagrams can be established according tothe classic structural operational semantics due to Hennessy and Plotkin [11]by defining object configurations and a transition relation over them. An objectconfiguration is a triplet a : (A, σ, ς) comprising responsive action A, programstate σ, and context awareness set ς of data/object spaces. The transition relationstates that whenever the object a behaves according to action A at state σand awareness set ς, then the execution leads to either an object configurationwith action A′ to perform at state σ′ and awareness set ς ′ or a terminatingconfiguration with state σ′ and awareness set ς ′.

a : (A, σ, ς) � a′ : (A′, σ′, ς ′) , a : (A, σ, ς) � a′ : (σ′, ς ′).

The transition relation is naturally extended to collections of objects by struc-tural congruence. An object in the collection develops its behavior concurrentlyand independently from any other, beginning by executing its constructor:

a : (A , σ , ς) � a′ : (A′ , σ′ , ς ′)a : (A , σ , ς) , O � a′ : (A′ , σ′ , ς ′) , O

O � O′

a : (A , σ , ς) , O � a : (A , σ , ς) , O′


Object behavior evolution is captured in the extended transition relation byincluding its reflexive and transitive closure. In the description of the SOS se-mantics, we always refer to the extension of the transition relation which canbe seen as a rewriting relation defined upon multisets of object configurations.Under this interpretation, the congruence relation rewrites either a single objectconfiguration or the remaining collection of object configurations.

The abstract syntax of deterministic programs is generated from the follow-ing grammar rules of the Java subset considered here, consisting of statementsamong assignments on simple variables, selective instructions, sequential com-position, and object method invocations:

A ::= stop; | skip; | x = E; | if(B)A1 else A2 | A1 A2 | o.m(E1, . . . , En);

The class of arithmetic expressions E consists of integer constants, integervariables, and compound expressions formed by composition of arithmetic ex-pressions with usual arithmetic operators. The class of Boolean expressions Bconsists of Boolean constants, simple Boolean expressions formed by compari-son of arithmetic expressions, and composition of Boolean expressions with thelogical connectives of negation, conjunction, and disjunction:

E ::= c | v | E + E | · · ·B ::= true | false | E==E | E ≤ E | !B | B && B | B || B

When an arithmetic or Boolean expression is evaluated, the result can be definedby extending the introduced transition relation. The evaluation terminates whenan arithmetic or Boolean constant is reached, with no changes in the state:

a : (E, σ, ς) � a′ : (E′, σ, ς) , a : (E, σ, ς) � E.

The value is defined inductively on the syntactic structure of the expression:

a : (c , σ , ς) � cσ(x) = c

a : (x , σ , ς) � ca : (E1 , σ , ς) � c1 a : (E2 , σ , ς) � c2

a : (E1 + E2 , σ , ς) � c1 + c2a : (E1 ≤ E2 , σ , ς) � c1 ≤ c2

a : (true , σ , ς) � true a : (false , σ , ς) � false

a : (B1 , σ , ς) � truea : (B2 , σ , ς) � a : (b2 , σ , ς)

a : (B1 && B2 , σ , ς) � a : (b2 , σ , ς)a : (B1 , σ , ς) � false

a : (B1 && B2 , σ , ς) � false

The structured operational semantics of CA UML-S diagrams given inTable 1 is discussed next. Objects of declared class B are created and initializedby operator new, binding the object instance of the class to a variable of thesame type and starting its behavior according to the actions given in the classconstructor B(). Null command skip; does nothing, maintaining program stateunchanged. Termination command stop; ceases object activity. An assignment


Table 1. Structured operational semantics of UML-S diagrams

a : (Space s = newSpace() ; A , σ , ς) � a : (A , σ , ς {s �→ create(Space)})

a : (B b = newB() ; A , σ , ς) � a : (A , σ {b �→ create(B)} , ς) b : (B(), ∅, ∅)

a : (E , σ , ς) � c

a : (x = E ; A , σ , ς) � a : (A , σ {x �→ c} , ς)

a : (skip; A , σ , ς) � a : (A , σ , ς)

a : (stop; , σ , ς) � a : (σ , ς)

a : (A1 , σ , ς) � a : (A2 , σ′ , ς ′)a : (A1 A , σ , ς) � a : (A2; A , σ′ , ς)

a : (A1 , σ , ς) � a : (σ′ , ς ′)a : (A1 A , σ , ς) � a : (A , σ′ , ς ′)

a : (B , σ , ς) � a : truea : (if (B) A1 else A2 , σ , ς) � a : (A1 , σ , ς)

a : (B , σ , ς) � a : falsea : (if (B) A1 else A2 , σ , ς) � a : (A2 , σ , ς)

S′ = S . subscription.put(typeof(x), a)a : (s . subscribe(typeof(x));A , σ , ς {s �→ S}) � a : (A , σ , ς {s �→ S′})

S′ = S . collection.put(typeof(E), Eσ)a : (s . send(E);A , σ , ς {s �→ S}) � a : (A , σ , ς {s �→ S′})

S′ = S . collection.put(typeof(M(E, S)), M(E, S) σ ς)a : (s . send(M(E, S)); A , σ , ς {s �→ S}) � a : (A , σ , ς {s �→ S′})

T = typeof(x)a ∈ S . subscription.get(T ) (E, S′) = S . collection.get(T )

a : (s . receive(x);A , σ , ς {s �→ S}) � a : (A , σ {x �→ E} , ς {s �→ S′})

T = typeof(M(x, z))a ∈ S . subscription.get(T ) (M(E, S)), S′) = S . collection.get(T )

a : (s . receive(M(x, z)); A , σ , ς {s �→ S}) � a :(A , σ

{x �→ E

}, ς

{s �→ S′, z �→ S

})


x = E; into a simple variable evaluates expression E at the right-hand side andbinds this value to variable x at the left-hand side, updating program state σ toσ {x �→ Eσ}. Sequence of commands A1; A starts executing A1 at state σ andupon its completion continues executing command A. Conditional execution if( B ) A1 else A2 selects the execution of either action A1 or action A2 , ascondition B is evaluated true or false, respectively.

A data/object space, created by operator new upon generic container classSpace, behaves according to the publish/subscribe pattern. In a data space, asubscription occurs when an object request is received to get any data availableby calling method subscribe, whereas a publication occurs when an object postsdata in the space by calling method send. However, regardless of the order oftheir occurrence, having received in the space a subscription and a publicationfor the same data type, the space forwards the message published to the objectregistered in the subscription. Then the subscriber receives such a message bycalling method receive. Like data spaces, object spaces interact through thesame basic methods subscribe, send and receive, leading to similar behaviors.However, object space methods are more elaborated in the message structure andcontent to pass not only simple data but also space names. Methods send andreceive must agree in the number and type of the values passed and received,respectively. In this way, passing a space name enables the receiver to be aware ofsuch a space. A data/object space mainly consists of two associative lists, calledsubscription and collection. The subscription list is a table containingall the objects that have subscribed for a specific type of data/object when itbecame available in the space. The collection list stores all the data/objectsavailable in the space organized by their type. Basic operations on associativelists are create, that creates an empty space, put that inserts a key-value pairinto the list and get that retrieves the value associated to a key. When morethan one value is associated to the same key, all the values are organized by theorder of their arrival.

The programming model provides the means not only to specify and visualizeuser and agent interactions in a computational context for ubiquitous computing,but also it provides the means to define their formal properties. Among them,reachability and deadlock-free analysis, and other liveness and safeness proper-ties can be established and demonstrated. For example, provided that there areappropriate contextual data for the Hill Climbing problem, then it can be shownthat the sketched program in preceding section will find the local maximum.The operational semantics described allows the proof of program correctness.Within specific protocols of nomadic computing, the operational semantics mayalso proof procedural completeness, but this exposition is outside the scope ofthis paper.

6 Conclusions

Ubiquitous and nomadic computing open new problems in distributed systemdesign and construction. Among them, visualization of program specification


and execution, in a platform neutral manner are among the most important,as system designers have to deal with the complexities involved in mobile usersand agents. From the system designer perspective, instead of introducing con-text awareness in UML by means of the stereotype mechanism, a Context AwareUML-Sequence visual programming language has been proposed. CA UML-S isbeing designed to deal with the fundamental problem of human and process mo-bility in computational contexts that cannot be described with UML diagrams.

References

1. Weiser, M.: Some computer science issues in ubiquitous computing. Commun.ACM 36, 75–84 (1993)

2. Olmedo-Aguirre, J.O., Escobar-Vazquez, K., Alor-Hernandez, G., Morales-Luna,G.: ADM: An active deductive XML database system. In: Monroy, R., Arroyo-Figueroa, G., Sucar, L.E., Sossa, H. (eds.) MICAI 2004. LNCS (LNAI), vol. 2972,pp. 139–148. Springer, Heidelberg (2004)

3. Beguelin, A., Dongarra, J.J.: Graphical development tools for network-basedconcurrent supercomputing. In: Supercomputing 1991: Proceedings of the 1991ACM/IEEE conference on Supercomputing, pp. 435–444. ACM, New York (1991)

4. Topol, B., Stasko, J.T., Sunderam, V.S.: Integrating visualization support intodistributed computing systems. In: ICDCS, pp. 19–26 (1995)

5. Rivera-de-la-Rosa, M., Olmedo-Aguirre, J.O.: A visual programming environmentfor eca rules. Advances in Artificial Intelligence and Computer Science. Researchon Computing Science 14, 253–264 (2005)

6. Valk, R.: Petri nets as token objects: An introduction to elementary object nets.In: Desel, J., Silva, M. (eds.) ICATPN 1998. LNCS, vol. 1420, pp. 1–25. Springer,Heidelberg (1998)

7. Lomazova, I.A.: Nested Petri nets: Multi-level and recursive systems. Fundam.Inf. 47, 283–293 (2001)

8. de Frutos-Escrig, D., Alonso, O.M., Velardo, F.R.: Ubiquitous systems and Petrinets. In: Gervasi, O., Gavrilova, M.L., Kumar, V., Lagana, A., Lee, H.P., Mun,Y., Taniar, D., Tan, C.J.K. (eds.) ICCSA 2005. LNCS, vol. 3481, pp. 1156–1166.Springer, Heidelberg (2005)

9. Alhir, S.S.: UML in a nutshell: a desktop quick reference. O’Reilly & Associates,Inc., Sebastopol (1998)

10. Bell, D.: UML’s sequence diagram (2004),http://www.ibm.com/developerworks/rational/library/3101.html

11. Hennessy, M., Plotkin, G.D.: Full abstraction for a simple parallel programminglanguage. In: Becvar, J. (ed.) MFCS. LNCS, vol. 74, pp. 108–120. Springer, Hei-delberg (1979)

http://www.ibm.com/developerworks/rational/library/3101.html

eca-rule visual programming for ubiquitous and nomadic computing

Documents