ECA-Rule Visual Programming for Ubiquitous and ... - Springer Link

ECA-Rule Visual Programming for Ubiquitous and Nomadic Computing Jos´e Oscar Olmedo-Aguirre1, M´ onica Rivera de la Rosa2 , and Guillermo Morales-Luna3, 1

2

Electrical Engineering, CINVESTAV-IPN, Mexico City, Mexico [email protected] Escuela Superior de C´ omputo, ESCOM-IPN, Mexico City, Mexico 3 Computer Science, CINVESTAV-IPN, Mexico City, Mexico [email protected]

Abstract. System modeling, analysis and visualization are becoming a common practice for the design of distributed intelligent systems since the wide adoption of the Unified Modeling Language (UML). However, UML cannot describe important behavioral properties such as context awareness as required for ubiquitous computing. In this paper, we present Context Aware UML Sequence diagrams (CA UML-S), an experimental visual programming language that extends UML sequence diagrams with data/ object spaces to represent computational context awareness. The programming language provides the means to describe the event-condition-action (ECA) rules that govern complex nomadic user behavior and to visualize their effect. The ECA rules are compiled into common concurrent programming abstractions by introducing structuring notions of object creation, synchronization, and communication, along with sequential and selective composition of simpler rules. The contribution of this work is in providing programming abstractions that facilitate the design of context-aware applications for ubiquitous and nomadic computing.

1

Introduction

Mark Weiser introduced the term ubiquitous computing [1] to describe an environment where a fixed computational and communication infrastructure will help nomadic users to conduct their activities unconscious of the infrastructure. However, the design and construction of context-aware applications in the highly dynamic setting of ubiquitous computing has been recognized as a difficult undertaking. In this respect, rule-based programming is proposed to improve our understanding of complex program behavior. Rule-based specifications are used in reactive systems that are monitored for the occurrence of events that may signal critical conditions. In rule-based systems, once an event is detected, if the event parameters satisfy certain condition, a specified action is performed to handle 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 arise from the fact that a distributed system is a system whose behavior is driven by the events of receiving messages and by the actions of sending messages. ECArules can be adopted as the basis for data representation, message exchange, and coordination specification in distributed applications [2]. Rule-based systems may as well evolve into complete programming languages aimed to coordinate software agents with proactive, rational and social behavior. ECA-rules constitute a powerful programming paradigm, though their interactions are very often difficult to understand because they are generally not designed to be applied in a structured or hierarchical manner. With the purpose to make rule interactions easier to understand, we propose to use UML sequence diagrams to visualize rule definition, selection and execution. We believe that rule definition can be easily understood by means of a short UML sequence diagram that exposes the event-condition-action structure of the rule. Furthermore, rule selection and instantiation becomes more coherent as the collection of sequence diagrams are identified by the events they handle. Rule execution may become more understandable because rules are grouped around objects in a sequential or parallel manner. Unfortunately, the programming environments that have adopted UML diagramming as the basis for its design methodology are used at best for the generation of program skeletons in programming languages as Java and C++ just because UML diagrams cannot be directly executed. Although replacing the textual representation of a programming model for a visual one represents a substantial step in abstracting algorithm design from program coding, program behavior still cannot be visualized directly from UML diagrams as the program execution is not integrated into the environment. We propose the construction of a visual programming language that addresses the afore-mentioned problems. By integrating visualization in the program specification and execution, the programming language offers a number of outstanding advantages 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 with some related work in the areas of program visualization and formal methods used. In section 3, fundamental concepts of Context Aware UML-S are presented and illustrated with an example of user guiding from nomadic computing. The visual specification and execution of ECA rules is discussed and analyzed in section 4. The programming model in the structured operational semantics style is 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 of sequential 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 synchronization. The misunderstanding of concurrent programs behavior may result in unexpected interactions and non-deterministic executions. However, some visualization tools have been realized to overcome these issues. In the Gthreads library [3] a program graph is built as threads are forked and functions are called. The vertices of the graph represent program entities and events, while the edges represent temporal orderings among vertices. Message passing views are supported by the Conch system [4] where processes appear outside of a ring and messages are exchanged among them by traversing the ring. In this way, undelivered messages can be detected as they remain within the ring. The Hence system [3] offers animated views of the program graph obtained from execution of PVM programs. None of them use standard UML diagrams to describe process interactions. Programming and visualization of sequential programs using an UML-like visual programming language has been explored in Moon [5], which is the base of the current prototype implementation of CA UML-S diagrams. Recently formal models based on Petri nets have been applied to ubiquitous computing due to their intuitive graphical representation and well established theoretical foundation. An Elementary Object System (EOS) [6] is a two-level net description consisting of a system net marked by high-level structured tokens representing object nets. Object nets can change their marking but not their structure, following the principles of object-oriented modeling. EOS has been used to model mobile user behavior. Further refinement of EOS are Nested Petri Nets (NPN) [7] which are multi-level net descriptions to model hierarchical multiagent dynamics. In NPN, object nets have their own structure and behavior, being able to appear, to evolve or to disappear during lifetime, and their number is unlimited. An NPN has four steps: transfer, object-autonomy, horizontal synchronization and vertical synchronization steps. A transfer step can move, generate or remove objects with no change of their inner states. An object-autonomy step can change the inner state of one object. horizontal synchronization conveys simultaneous firing of two object nets situated in the same place of a system net. vertical synchronization means simultaneous firing of the system net with one of the object nets involved in the firing. Ubiquitous Nets (UN) [8] allows modeling both devices (processor nets) and software components located at processors (process nets). In the model, processes change their 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 developed by the interaction of the participants. These diagrams contain objects (classes) that exchange messages arranged in a time sequence. They are defined according to class roles, lifelines, activations and messages [9]. Illustrative examples of these diagrams are shown in [10]. Class roles, denoted by rectangles surrounding the role-name and the class-name, specify the type of objects that may participate with interactions and collaborations. Lifelines, denoted by vertical dashed lines,

928

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

represent the existence of class roles over a period of time, since the object creation until its destruction. They may split into concurrent lifelines to show concurrency or conditionality, each corresponding to a thread or a conditional branch and they may merge together at some subsequent point. Activations, denoted by thin vertical rectangles arranged along lifelines, represent the time during which a class role is performing an action (operation) or when it is active and has focus of control. Finally, messages, denoted by labeled horizontal arrows between lifelines, define the information content of a communication that is exchanged in interactions and collaborations. The message instance has a sender, a receiver and possibly other information according to the characteristics of the request. Messages may be either synchronous (solid arrow heads), with explicit or 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 and context awareness, in order to define Context Aware UML-S or CA UML-S visual programming language. Explicit program states (configurations) are represented by graphic elements similar to those used for class roles except that they appear along the timeline possibly with a note containing an assertion about the program state. Explicit program states are useful because they can simplify the rendering of visual programming constructions to reflect the change of the object configuration. Data spaces contain heterogeneous collections of pieces of information that are stored in a single or a networked cluster of computational devices. Object spaces contain data communication enabled objects that can be detected if they are within the scope of a short range local area network, and can be identified by the physical coordinates of the communication base of the network. Data/object spaces can be seen, in abstract terms, as partitions of the entire data collection and the objects found in the environment. Data/object spaces are identified by unique global identifiers. In CA UML-S, a space is represented by a rounded box labeled by the space name. Computational context is the entire computation, communication and coordination infrastructure conformed by sensors, actuators, computational, and communication devices that the environment offers to enable users and agents to interact with them and with the environment. Thus, the computational context enables ordinary objects to have a presence in this form of extended reality. Context awareness of a mobile user or agent is the ability to perceive this extended reality by identifying the spaces and the objects that populate them. The entities located in a space are identifiable and shared resources that can be accessed by users and agents that are aware of the existence of such a space. Users and agents are aware of spaces if they know the name that identified them. As proposed in this work, CA UML-S for ubiquitous computing extends the class role notation to accommodate the name of the space to which a class instance interacts. Such a space name can be avoided in the diagram by drawing an arrow pointing to the current space to which the object is aware. Note that space variables describe the local topology of the object neighborhood and can change their values to reflect the local space context awareness.

ECA-Rule Visual Programming for Ubiquitous and Nomadic Computing

(a)

929

(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 problem 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 guide maintains with the local communication infrastructure. Assuming the entire region is partitioned into a grid of addressable physical locations, each of such locations comprises a data/object space that contains information about the local topology of its neighbor locations (i.e. north, east, south, etc.). The interaction begins when, either the guide sends to the current location a message telling which neighbor location to move on next or the visitor sends a subscription 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 suggesting to 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-ordering restrictions, 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 double headed arrow as illustrated in Figure 1(b). It is properly defined because forwarding a message from the space to the subscriber can only happen when both the message and the subscription were received before at the space. This simplification can be used only when the message sender is not needed to be known in the rule description. This is a reasonable assumption because data/object spaces were conceived to decouple the interaction among the participants. Besides, the notation emphasizes the more relevant aspects of specifying what data/object is required and from which location should be taken. Using the Dijkstra’s algorithm to find a minimal path between two connected points in a map, the locations lying in the minimal path can be determined. Then the guide places a notification addressed to the visitor in all the locations along the path. The notification indicates in what direction the visitor must move on next to get closer to its destination. The visitor is aware of the data/object space of the current location and places a subscription on it to receive the notification of where to move on. When both, the subscription and the notification become

930

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

available, the local space forwards the notification to the visitor, who then determines 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 nomadic computing in mind. Therefore the fundamental concept of locality is not represented in the diagrams, and in consequence this interaction cannot be modeled in UML. Though a partial solution can be devised by using UML stereotypes to define a new entity, this approach neglects the fundamental knowledge representation problem that poses human or process mobility. In our approach, UMLS for ubiquitous computing extends the class role notation to accommodate the name of the location to which a class instance interacts. Such a location name can be avoided by using instead an arrow that points to the current location. Although simple, this solution proves to be expressive enough to model complex interactions in nomadic computing that cannot be represented otherwise in UML.

4

ECA Rule Programming in CA UML-S

The CA UML-S synchronization bar constitutes the fundamental visual construction to define ECA rules in the programming language, because they comprise events, conditions and actions. Events, denoted by incoming message arrows with no time-ordering restrictions, are notifications of the execution of observable actions. Conditions, denoted by logical expressions written in notes, are constraints defined upon the contents of the events and the object configurations to select those that satify the contranints. Actions, denoted by either outgoing message arrows or explicit object configurations, are operations that modify the object state and its awareness of the local context. Figure 2 shows two rules depicted in the CA UML-S visual language using the synchronization bar. Each rule renders two possible scenarios that arise from the conditions that may occur. Even with the few elements presented here, it can be shown that very complex and interesting behaviors can be visually described. Among the experiments we have conducted so far, hypermedia architectures, simple workflow systems, collaborative systems and Turing machines are among the most notorious. Hill Climbing and other search space techniques used in Artificial Intelligence are currently being investigated. The Hill Climbing problem consists of finding a location containing data or object attributes that maximizes a function. The solution to this problem consists on evaluating the function on the neighbor locations and selecting the location that increases the value of the function. This evaluation, selection and movement process is repeated until a (local) maximum is reached. Figure 2 shows two visual rules that are part of the solution of a bi-dimensional version of the Hill Climbing problem. As the figure shows, the visitor is aware of the current location in which he/she stands up, and the one on the left and the one on the right of the current location. This is depicted by the outgoing arrows from the visitor instance box to the corresponding space instance boxes in the upper

ECA-Rule Visual Programming for Ubiquitous and Nomadic Computing

(a)

931

(b)

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

part of the drawing. The visitor moves when its current location is changed by any of its two neighbor locations. The selection is taken for the location that contains the greater value obtained from sensor reading of the location height and from object property h that keeps the currently known local maximum. The synchronization bar on the visitor object receives message height from both locations to be able to make the selection. The restriction note at the right of the 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 a change in its context awareness. Fig. 2(a) and 2(b), respectively, shows that the user 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 to the classic structural operational semantics due to Hennessy and Plotkin [11] by defining object configurations and a transition relation over them. An object configuration is a triplet a : (A, σ, ς) comprising responsive action A, program state σ, and context awareness set ς of data/object spaces. The transition relation states that whenever the object a behaves according to action A at state σ and awareness set ς, then the execution leads to either an object configuration with action A to perform at state σ  and awareness set ς  or a terminating configuration with state σ  and awareness set ς  . a : (A, σ, ς)  a : (A , σ  , ς  )

,

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

The transition relation is naturally extended to collections of objects by structural congruence. An object in the collection develops its behavior concurrently and independently from any other, beginning by executing its constructor: O  O a : (A , σ , ς)  a : (A , σ  , ς  ) a : (A , σ , ς) , O  a : (A , σ  , ς  ) , O a : (A , σ , ς) , O  a : (A , σ , ς) , O

932

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

Object behavior evolution is captured in the extended transition relation by including its reflexive and transitive closure. In the description of the SOS semantics, we always refer to the extension of the transition relation which can be seen as a rewriting relation defined upon multisets of object configurations. Under this interpretation, the congruence relation rewrites either a single object configuration or the remaining collection of object configurations. The abstract syntax of deterministic programs is generated from the following grammar rules of the Java subset considered here, consisting of statements among assignments on simple variables, selective instructions, sequential composition, 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, integer variables, and compound expressions formed by composition of arithmetic expressions with usual arithmetic operators. The class of Boolean expressions B consists of Boolean constants, simple Boolean expressions formed by comparison of arithmetic expressions, and composition of Boolean expressions with the logical 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 defined by extending the introduced transition relation. The evaluation terminates when an 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: σ(x) = c a : (x , σ , ς)  c a : (E1 , σ , ς)  c1 a : (E2 , σ , ς)  c2 a : (E1 + E2 , σ , ς)  c1 + c2 a : (E1 ≤ E2 , σ , ς)  c1 ≤ c2 a : (true , σ , ς)  true a : (false , σ , ς)  false a : (B1 , σ , ς)  true a : (B1 , σ , ς)  false a : (B2 , σ , ς)  a : (b2 , σ , ς) a : (B1 && B2 , σ , ς)  a : (b2 , σ , ς) a : (B1 && B2 , σ , ς)  false a : (c , σ , ς)  c

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

ECA-Rule Visual Programming for Ubiquitous and Nomadic Computing

933

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 : true a : (if (B) A1 else A2 , σ , ς)  a : (A1 , σ , ς) a : (B , σ , ς)  a : false a : (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

934

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

x = E; into a simple variable evaluates expression E at the right-hand side and binds 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 σ and upon its completion continues executing command A. Conditional execution if ( B ) A1 else A2 selects the execution of either action A1 or action A2 , as condition B is evaluated true or false, respectively. A data/object space, created by operator new upon generic container class Space, behaves according to the publish/subscribe pattern. In a data space, a subscription occurs when an object request is received to get any data available by calling method subscribe, whereas a publication occurs when an object posts data in the space by calling method send. However, regardless of the order of their occurrence, having received in the space a subscription and a publication for the same data type, the space forwards the message published to the object registered in the subscription. Then the subscriber receives such a message by calling method receive. Like data spaces, object spaces interact through the same basic methods subscribe, send and receive, leading to similar behaviors. However, object space methods are more elaborated in the message structure and content to pass not only simple data but also space names. Methods send and receive 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 of such a space. A data/object space mainly consists of two associative lists, called subscription and collection. The subscription list is a table containing all the objects that have subscribed for a specific type of data/object when it became available in the space. The collection list stores all the data/objects available in the space organized by their type. Basic operations on associative lists are create, that creates an empty space, put that inserts a key-value pair into the list and get that retrieves the value associated to a key. When more than one value is associated to the same key, all the values are organized by the order of their arrival. The programming model provides the means not only to specify and visualize user 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 properties can be established and demonstrated. For example, provided that there are appropriate contextual data for the Hill Climbing problem, then it can be shown that 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 may also proof procedural completeness, but this exposition is outside the scope of this paper.

6

Conclusions

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

ECA-Rule Visual Programming for Ubiquitous and Nomadic Computing

935

and execution, in a platform neutral manner are among the most important, as system designers have to deal with the complexities involved in mobile users and agents. From the system designer perspective, instead of introducing context awareness in UML by means of the stereotype mechanism, a Context Aware UML-Sequence visual programming language has been proposed. CA UML-S is being designed to deal with the fundamental problem of human and process mobility 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-V´ azquez, K., Alor-Hern´ andez, G., Morales-Luna, G.: ADM: An active deductive XML database system. In: Monroy, R., ArroyoFigueroa, 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-based concurrent supercomputing. In: Supercomputing 1991: Proceedings of the 1991 ACM/IEEE conference on Supercomputing, pp. 435–444. ACM, New York (1991) 4. Topol, B., Stasko, J.T., Sunderam, V.S.: Integrating visualization support into distributed computing systems. In: ICDCS, pp. 19–26 (1995) 5. Rivera-de-la-Rosa, M., Olmedo-Aguirre, J.O.: A visual programming environment for eca rules. Advances in Artificial Intelligence and Computer Science. Research on 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 Petri nets. In: Gervasi, O., Gavrilova, M.L., Kumar, V., Lagan´ a, 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 programming language. In: Becv´ ar, J. (ed.) MFCS. LNCS, vol. 74, pp. 108–120. Springer, Heidelberg (1979)