- Email: [email protected]
A process algebra to formalize the Lyee methodology
Knowledge-Based Systems 17 (2004) 263–281 www.elsevier.com/locate/knosys
A process algebra to formalize the Lyee methodology Hamido Fujitaa,*, Mohamed Mejrib, Be´chir Ktarib a b
Faculty of Software and Information Science, Iwate Prefectural University, 152-52 Sugo, Takizawa, Iwate, 020-0193, Japan Faculty of Software and Information Science, Department of Computer Science and Software Engineering, Laval University, Que´bec, G1K 7P4, Canada Received 21 June 2004; accepted 9 July 2004 Available online 18 October 2004
Abstract Over the last years, various methodologies and techniques have been elaborated and proposed to improve one or many aspects related to the software development life cycle. However, despite the great effort in this research field, the production of clearly understood and modifiable systems still an ambitious goal and far from reached. This is due, on one hand, to the complexity and the subtlety of software themselves and, on the other hand, to the limitations of the current methodologies. Recently, a new and very promising methodology, called Lyee, has been proposed. Intended to deal efficiently with a wide range of software problems related to different field, Lyee allows the development of software by simply defining their requirements. Nevertheless, since both the semantics of Lyee generated software together with the process of automatic generation of software from requirements are described using informal language, difficulties and confusions may arise when trying to understand and study this methodology. The main purpose of this paper is to formalize, using a process algebra, the process of automatic generation of softwares together with the semantics of Lyee generated softwares. Actually, process algebra naturally supports many concepts of the Lyee methodology and consequently formalize them simply and elegantly. It offers to the Lyee methodology an abstract machine more suitable than the VonNewman one. In fact, this new abstract machine consider a program as chemical solution when molecules (different vectors of the lyee methodology) interact together to reach a collective goal. q 2004 Elsevier B.V. All rights reserved. Keywords: Lyee methodology; Process algebra; Operational semantics; Bisimulation
1. Introduction Producing easily and quickly software with high quality is the basic concern of the software development research field. Over the last years, various methodologies and techniques have been elaborated and proposed to improve one or many aspects related to the software development life cycle. However, despite the great effort in this research field, the production of clearly understood and modifiable systems still an ambitious goal and far from reached. This is due, on one hand, to the complexity and the subtlety of software themselves and, on the other hand, to the limitations of the current methodologies. In fact, almost all of the proposed
* Corresponding author. E-mail address: [email protected] (H. Fujita). 0950-7051/$ - see front matter q 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.knosys.2004.07.006
methodologies fail to produce clearly understood and modifiable systems and their use is still considered to be an activity accessible only to specialists with a large array of competencies, skills, and knowledge. This, in turn, leads to highly paid personal, high maintenance costs, and extensive checks needing to be performed on the software. For these reasons, companies are likely to welcome any new methodology promising demonstrable improvement in the software development cycle. Recently, a new and very promising methodology, called Lyee [10,11] (governmentaL methodologY for softwarE providencE), has been proposed. Intended to deal efficiently with a wide range of software problems related to different fields, Lyee allows the development of software by simply defining its requirements. More precisely, a developer has only to provide words, calculation formulae, calculation conditions (preconditions) and layout of screens and printouts, and then
264
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
leaves in the hands of the computer all subsequent troublesome programming process (e.g. control logic aspects). Despite its recency, the results of the use of Lyee have shown tremendous potential. In fact, compared to conventional methodologies, development time, maintenance time and documentation volume can be considerably reduced by using Lyee. In [7], we proposed some classical static analysis techniques in order to improve many aspects of this methodology, in particular Lyee requirements. Nevertheless, since both the semantics of Lyee generated software together with the process of automatic generation of software from requirements are described using informal language, difficulties and confusions may arise when trying to understand and study this methodology. In addition, the ideas behind this methodology are described using a sequential language which is not appropriate to support them. In fact, a Lyee generated software is basically made of small components (called vectors in Lyee terminology), where each one has an atomic goal, that collaborate together by interaction in order to produce the desired results (global goal). It is, however, commonly known that a process algebra which naturally supports concurrency and communication is the appropriate language to specify concurrent components and therefore it will provides a formal and worthy foundation to support the Lyee methodology concepts. Among other beneficial consequences of using process algebra with the Lyee methodology, many components (complete vectors or parts of vectors) of the actual version of Lyee, which their presence was forced by the sequential language used to describe it, will no longer be necessary since they are naturally supported by process algebra. Actually, synchronization vector, most of the routing vectors, command vector, etc. are no longer needed. Thus, we obtain a formal description of Lyee that is simple and that produce program shorter and consuming less time and memory. Besides, this formal description will be an inevitable start point for many interesting analysis of diverse aspects of this methodology. For instance, to optimize the Lyee generated software or the software generation processes, we need a formal proof that the optimized program is equivalent to its original version. Formal equivalence checking or more generally model checking can be elegantly achieved when using process algebra. In this paper, we first define a formal process algebra, called Lyee-calculus, that easily and naturally supports the basic concepts of the Lyee methodology. In fact, this calculus can be seen as an abstract machine which is more suitable to support the Lyee methodology concepts than the Von Newman one. This machine considers a program as a set of molecules that interact together to produce a final result. Second, we show how this calculus can formalize and simplify both the Lyee vectors together with the whole software generation process. Actually, we have formalized the whole process of the automatic generation of Lyee software generation.
The remainder of this paper is organized as follows. In Section 2, we define the syntax and the semantics of the Lyee-calculus. In Section 3, we give a short and technical introduction to the Lyee methodology and an overview of its formalization using the Lyee-calculus. In Section 4, we propose a detailed and complete formalization of the Lyee methodology using our calculus. In Section 5, we present one case study that concretely shows both how a program is automatically generated from simple requirement together with a step-by-step description of the execution of the generated program. Finally, Section 6 provides concluding remarks on this work, and discusses some future work.
2. Lyee-calculus Process algebra is a formal description technique for complex computer systems, especially those involving communication and concurrent components [1–3,6,8]. Process algebra is generally referred as calculus in the literature since it involves a variety of mathematical and logic concepts (concurrency theory, operational semantics, complexity theory, logic, etc.) that goes beyond the process algebra field. In this section, we give the syntax and the semantics of a new calculus, called Lyee-calculus, that we have specially defined to formalize the Lyee methodology. 2.1. Syntax Lyee-calculus programs are systems composed of independent and parallel processes that communicate using hand-shake technique on named channels. The channel can be restricted so that only some process can communicate on them. A process can send a value v through a channel ı by doing the action ½ı!e (v corresponds to the valuation of e). Similarly, a process can receive a value from a channel by doing the action ½ı?e. A process can also perform a silent action t. This special action, intended to represent internal behavior of a system such as synchronization between processes, is also useful to capture indeterminism within process evolution. The syntax of processes is presented in Table 1. The intuitive meaning of each syntactic construction is as follows: † Sequence: [K]$P, where K is a set of actions, is a process that has to perform all the action in K and then behaves as the process P. The order in which the actions in K have to be executed is not important. Notice that for the sake of simplicity we write [k1,.,kn] instead of [{k1,.,kn}]. † Parallel composition: PjQ behaves as processes P and Q running in parallel. Each one of them may interact with the other on channels known to both, or with the outside word (environment or the end-user) independently from the other. When two processes synchronise on the same
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
265
Table 1 Syntax of process algebra P, Q
TZ j[K]$P jPjQ jPCQ P8Q jP/L def ~ ÞZ § jAðX jnil TZ j{k} jK1 g K2 TZ jY jfıg jL1 g L2 TZ jı!e jı?e jt
K, K1, K2
L, L1, L2
k
ı; Œ e
(Processes) (Sequence) (Parallel composition) (Choice) (Guarded choice) (Restriction) (Definition) (nil process) (Set of actions) (Single action) (Set union) (Set of channels) (Empty set) (Single channel) (Set union) (Action) (Send) (Receive) (Silent action) (Channel) (Arithmetic expression)
channel, the whole process will perform an action t and behaves as the remaining process. For instance, let us take the following process: § Z §1j§2 with P1 and P2 defined as follows: def
§1 Z½ı!4:§1 0 def
§2 Z½ı?x:§2 0 Then, process P performs a silent action t, indicating a synchronization between processes P1 and P2 which actually consist in the transmission of the value 4 from P1 to P2, and behaves as the remain process P 0 1jP 0 2. Semantically, we will note this transition as follows:
Fig. 1. Cell formalized as a process.
† nil process: nil is the process that cannot perform any action. 2.2. Example In this section, we show how to model a cell of memory as a process that interacts with its environment through its communication channels. As shown by Fig. 1, we consider that the cell has two ports (channels) of communication, in and out. The basic task of this cell is to infinitely wait for a value on channel in and to make it available on channel out. The same value may be output as much as necessary until a new value is imputed. We write the process cell Cx(v), meaning that the memory cell x holds the value v, as follows: def
C x ðvÞ Z½inx ?y:C x ðyÞ C ½outx !v:C x ðvÞ By capturing a memory cell as a process, we can add intelligence to it. For instance, we can write a cell that it does not allow the access to its content until it will be initialized. This smart cell can be defined as follows: def
CellðxÞ Z½inx ?y:C x ðyÞ Now, giving two processes defined as follows: def
§1 Z½inx !5:nil def
§2 Z½outx ?y:nil It is easy to write a program where these two processes communicate through a cell x:
t
§ / §1 0 j§2 0 k
§1jCellðxÞj§2
The relation / will be formally defined later within this section.
Fig. 2 shows the interaction between all the involved processes. Here are the different steps of that program execution:
† Choice: PCQ behaves as P or as Q. The choice is deterministically (made by the environment) if both P and Q do not begin with a silent action, otherwise the choice is not deterministically. † Guarded choice: P"Q is the process that behaves as P until process Q is activated. Whenever the latter is activated, the former is stopped and cleared from memory. † Restriction: P/L is the process that behaves as P except that it can communicate with the environment using channels given in L only. ~ def § is a defining equation where A is † Definition: AðXÞZ ~ are variables (parameters), and P a process identifier, X may recursively involve A.
§1jCellðxÞj§2 Z ½inx !5:nilj½inx ?y:C x ðyÞj½outx ?y:nil t
/ C x ð5Þj½outx ?y:nil Z ð½inx ?y:C x ðyÞ t
/ C x ð5Þ C ½outx !5:C x ð5ÞÞj½outx ?y:nil To sum up, during the execution of this program, the process P1 has sent the value 5 to the process P2 via
Fig. 2. Example of interacting processes.
266
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
the process Cell(x) and then finished. The memory cell, specified by the process Cell(x), holds the value 5 and is still ready to communicate it to any other process.
Table 3 Lyee requirements Word
Definition
Condition
2.3. Semantics
a c b e
bCc
« b*eO2
2*cC5
cO0
Hereafter, we give the formal semantics of the Lyeecalculus. This semantics is defined by the interaction k k relation / , where § / Q means that there is a reaction amongst the subprocesses of P such that the whole can execute the atomic action k and becomes Q. The interaction relation is inspired by the Chemical Abstract Machine [4,5]. In this model, a process is considered as a chemical solution of molecules waiting to interact. To k formally introduce the relation / , we need to define the following notions: † I is a relation that simplify processes by eliminating the nil process as follows: ð§jnilÞI §
ðnil C §ÞI §
ðnil . §ÞI §
ðnilj§ÞI §
ð§ C nilÞI §
ð§ . nilÞI §
† We denote by [[e]] the set of values containing the result of the evaluation of the expression e. If e is a variable, its evaluation will be its domain (int, real, etc.). For the sake of simplicity, we consider that all variables belong to the real set. † kX is the name of the channel used by the action k, i.e.: tX Z Y ðı!eÞX Z ðı?eÞX Z fıg k Now, we let the interaction reaction / be the least relation that satisfies the rules given by Table 2. Table 2 Semantics of Lyee-calculus k
ðR! Þ
§ / Q0 Q0 I Q k § / Q v 2EeF
ðR? Þ
ı!v ½ı!e$§ / §
v 2EeF
ðRt Þ
ı?v ½ı?e$§ / §½v=e
, t ½t$§ / §
k
ðR½ Þ
½K1 $§ / §0 K2 sY k ½K1gK2 $§ / ½K2 § 0
k / §0 l § ðRC Þ §CQ / k § 0 ı?v
0
ı!v
Q / Q0 k / Q0 §CQ 0
k
0
3. Lyee methodology This section presents an overview of how the Lyee methodology generates software from simple user requirements. Besides, through this overview we progressively introduce how one can simply and efficiently formalize this methodology using the Lyee-calculus. The complete formalization of the process of software generation of the lyee methodology will be given in Section 4.
Within the Lyee methodology, requirements are given in a declarative way as a set of statements containing words together with their definitions, their calculation conditions and their attributes (input/output, types, security attributes, etc.). Table 3 gives an example of Lyee requirements. The requirements given in that table correspond intuitively, in a traditional programming language, to the code given in Table 4. Within the Lyee methodology, the user does not need to specify the order (control logic) in which these definitions will be executed. As shown in Table 4, despite the fact that the definition of word a uses word b, statement sb is listed after the statement sa. As explained in the sequel, from these requirements, and independent of the order of statements, Lyee is able to generate code that computes all the defined words. This simple idea has, as shown in [9,10,11], multiple beneficial consequences on the different steps of software development. In fact, it allows us to begin developing software even with incomplete requirements. Moreover, the user does not need to deal with control logic as with more classical methodologies. The control logic part
§ / § .Q
Q / Q0 k §jQ / §jQ 0
sc sb
if b*eO2 then adbCc; output(a); endif input(c); if cO2 then bd2*cC5; output(b); endif input(e);
ðRZÞ
~ §½Y~ =X / §0 / §0 ~ ÞZ § ðR= Þ § k kX 2L AðX k 0 / § / §=L AðY~ Þ §=L k
«
sa
§ / § 0 Q / Q0 t §jQ / § 0 jQ 0
k / §0 §.Q
/ Q ðRr. Þ Q k / Q0 §.Q
k
ðRlj Þ
secret public public public
Code
ðRtj Þ
ı!v
int float float float
Statement
§ / § Q / Q t / Q0 §.Q ı?v
OF IS OS IS
0
k
ðRt. Þ
ðRl. Þ
Security
Table 4 Statement code
k
r ðRC Þ
Type
3.1. Lyee requirements
ðnil=LÞI nil
ðRIÞ
IO
§ / §0 k §jQ / § 0 jQ
k
ðRrj Þ
k
se
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
267
3.2. Pallets and scenario function
of the software will be, within the Lyee methodology, automatically generated reducing consequent programming errors and time. Flexibility is also a major benefit of the Lyee methodology since the maintenance task can be reduced to a simple modification of requirements (add, remove and/or modify words’ definitions). Consequently, Lyee systems can be viewed as collections of independent components (statement) that interact together in order to produce the desired result. The concepts of our process algebra sticks very well with this view since the Lyee-calculus considers a program as a chemical solution of molecules (processes) that interact together to reach the final goal. So, at a first glance, one can view a Lyee requirement LR composed of a set of statements {s1,.,sn} as a concurrent processes of the Lyee-calculus, i.e.:
From the requirements in Table 3, we can automatically generate a program that computes the values of a and b and outputs them. This program will simply repeat the execution of these instructions until a fixed point is reached, i.e. any other iteration will not change the value of any word as shown in Fig. 3. Let us be more precise about the structure and the content of the program that will be automatically generated by Lyee from requirements. Within the Lyee methodology, the execution of a set of statements, such as the ones given in Table 3, is accomplished in a particular manner. In fact, Lyee distributes the code associated with statements over three spaces, called Pallets (W02, W03 and W04) in the Lyee terminology, as shown in Fig. 4. Pallet W02 deals with the input words. Pallet W03 computes the calculation conditions of the words and saves the results in boolean variables. For instance, the condition ‘b*eO2’ used within the definition of the word ‘a’ is calculated in W03 and the true/false result is saved in another variable ‘a_cond’. Finally, pallet W04 deals with the calculation of the words according to their definition given within the requirements. It also outputs the values of the computed words. More precisely, the lyee pallets contains a simple program with a fixed structure (called a Predicate Vector in the Lyee terminology) that makes the structure of generated code uniform and independent of the requirement content. The global program will be simple calls of predicate vectors. The structure of a predicate vector is as shown in Fig. 5.
LR Z s1 j /jsn
† The L4 vector deals with the computation of a given word (variable). Each word in the specification has its own
Fig. 3. Requirement execution.
Fig. 4. Lyee pallets.
268
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
† The O2 vector deals with input from the outside (screen, file networks, etc.) of the program. The imputed values will be stored in a temporary area and then will be transferred to their final memory area by L2. There is only one O2 vector for all the input words. † The L3 vector deals with the computation of the condition associated to a given word (variable). Each word in the specification has its own L3 vector. Fig. 7 shows the L3 vectors associated with the calculation of the word ‘a’ and the word ‘b’. † Fig. 8 sketch the role of each vector. † Follows that the content of each pallet will be as shown by Fig. 9. † Finally, the Lyee program associated with the requirements given in Table 3 is as shown in Table 5. † Notice that the whole process (W04/W02/W03) will repeat until a situation of overall stability is reached. The three pallets (W04,W03,W02) linked together are called Scenario Function in the Lyee terminology.
Fig. 5. Predicate Vector.
L4 vector. Fig. 6 shows the L4 vectors associated with the calculation of the word ‘a’ and the word ‘b’. † The O4 vector deals with output. Once the computation of a given output word has finished, this vector will output the value of this word in the appropriate place (screen, file, networks, etc.). There is only one O4 vector for all the output words. † The L2 vector transfers the value of an input word to the appropriate memory area. Each input word in the specification has its own L2 vector.
As we can see in Table 5, besides the basic vectors (L4,L3,L2,O4,I2,S4), the Lyee methodology adds new vectors (R2,R3,R4, etc.), supplementary memories (finish and restart flags in the basic structure) and other treatments to resolve the following problems: † In which order the vectors will be computed? † What to do if we try to compute a vector that cannot be computed due to some missing values? † When the fixed point is reached ? (fixed point control) The presence of the additional introduced treatment was forced by the use a sequential language to implement a Lyee requirement. A more appropriate language for
Fig. 6. The predicate vectors of L4,a and L4,b.
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
269
Fig. 7. The predicate vectors of L3,a and L3,b.
Fig. 8. Relation between statements and vectors.
the Lyee-methodology is the one who is able, without giving it any supplementary instruction, to stop when a fixed point is reached and to run the appropriate vector in the appropriate time, i.e.:
† Knows the vectors that are ready to produce their results and executes one of them. † Puts the vectors that have some missing arguments in a standby state.
Fig. 9. Relation between pallets and vectors.
270
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
Table 5 Lyee generated program Pallet
Program
Comments
W04
Call S4 Do Call L4_a Call L4_b while a fixed point is not reached Call O4 Call R4 Do Call L2_e Call L2_c while a fixed point is not reached Call I2 Call R2 Do Call L3_a Call L3_b while a fixed point is not reached Call R3
Initialize memory
W02
W03
Calculate a Calculate b Output the result Go to W02
Input results Go to W03
managed by our abstract machine. Consequently, a Scenario Function could be formalized as follows: SF Z W04 jW03 jW02 Stop when a fixed point is reached. From our process algebra view point, the notion of ‘reaching of a fixed point’ is naturally implemented within the semantics. In fact, the processes (molecules) interact together until a state of no possible evolution (fix point) is reached. Within the memory cell example (page 5), the reaction between molecules is as following: † Initially, we have a chemical solution containing the following processes:
Calculate a_cond Calculate b_cond Go to W04
Hereafter, we give some arguments that show how our processes algebra is suitable to support the concepts of the Lyee-methodology. Select the appropriate vector in the appropriate time. Using our process algebra, we can simplify the Lyee generated program by eliminating the additional introduced treatments. In fact, within this process algebra, all the arguments of a vector will be received on named channel using synchronous communication. Therefore, all the vectors that miss some arguments in order to be computed will be automatically butted in a standby state. Besides, if there are many vectors which are ready to be computed, then the process algebra will arbitrarily choose one of them and run it. Consequently, the program associated to the following statements
† The first reaction will be between the process P1 and the process Cell according to the rule: ı?v
ðRtj Þ
ı!v
§ / § 0 Q / Q0 t
§jQ / § 0 jQ 0
will look as following
Therefore, using the Lyee-calculus, we do not need any more to specify the order according to which the pallets will be executed, the order according to which the vectors of each pallet will be executed, how and when to pass control from one pallet to another, etc. All this detail will be naturally
† The result of the first reaction is the following chemical solution: niljC x ð5Þj§2
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
271
† The previous chemical solution has reached a fixed point since no rule can makes it to move to another different solution. Now, using the Lyee-calculus, W04, W03 and W02 can be specified as follows: W04 Z S4jL4_ajL4_bjO4 W03 Z L3_ajL3_b W02 Z L2_ejL2_cjI2 The formal definition of the different vectors (L2, L3, L4, S4, etc.) will be given in Section 4. † The second interaction is between the process P2 and the process Cell according to the rule: ı?v
ðRtj Þ
ı!v
3.3. Process route diagrams
§ / § 0 Q / Q0 t
§jQ / § 0 jQ 0
† The result of the second reaction is the following chemical solution: niljCx ð5Þjnil
The Scenario Function presented in Section 3.2 can be a complete program for a simple case of given requirements, particularly when all the input and output words belong to the same screen and there is no use of any database. However, if we need to input and output words that belong to databases or to different screens interconnected together, then the situation will be more complicated. For the sake of simplicity, we deal, in the sequel, only with the case when we have many screens. Suppose for instance that we have three interconnected screens, as shown in Fig. 10, allowing a user to navigate from one to another. Suppose in each one of them the user can input, compute and output some words. Therefore, in the specification, the user must specify how these screens are interconnected. Furthermore, it is not convenient to define only one scenario function in which we compute all the words defined in all the screens. In fact, some screens may not be visited for a given execution of the program and then the computation of the value of their words will be lost. For that reason, Lyee associates with each screen its owner scenario function that will be executed only if this screen is visited. The scenario functions associated with screens are connected together showing the move from one of them to another. In the Lyee terminology, many scenario functions connected together make up a Process Route Diagram as shown in Fig. 11. Using the Lyee-calculus, we can formalize a screen sk as a process F(sk) that control the execution of the process SF(sk). Actually, the process SF(sk) will be executed until it corresponding screen is reactivated (receiving a signal on the channel ısk associated to the screen sk) and then will be killed to create a new fresh instance of SF(sk). This is formalized as follows: Fðsk Þ Z SFðsk Þ . ½ısk ?1:Fðsk Þ Notice that a concrete example will be given later in this paper to show how the function F(sk) works.
272
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
Fig. 10. Screen interactions.
The function J is defined as follows:
3.4. Lyee program To summarize, according to the Lyee methodology, a Lyee program contains several processes route diagrams (PRD). Each of them is a set of interconnected scenario functions (SF). Each scenario function contains three interconnected pallets W02, W03 and W04. Finally, pallets contain atomic vectors (signification vectors and action vectors). Using the Lyee-calculus, a Lyee program § containing the screens s1,.,sk, is formalized as follows: §ðs1 ; .; sk Þ Z Jðs1 ; .; sk Þ=Lðs1 ; .; sk Þ where Lðs1 ; .; sk Þ is the set of input and output channels. This restricts Jðs1 ; .; sk Þ to communicate with the environment only on channels in Lðs1 ; .; sk Þ.
Jðs1 ; .; sk Þ Z ðjs2fs1 ;.;sk g ½ıs ?1:FðsÞÞ . ½ıs0 ?1:nil This function activates the SF of a screen sk(F(sk)) whenever a true value is received on the corresponding channel ısk , which formalizes a button or a menu item that a user may use to activate the corresponding screen, and kill all the processes when it receives a true value on channel ıs0 , which formalizes the Exit button (or a corresponding menu item). Consequently, a Lyee system can be viewed as a collection of independent concurrent processes that communicate with each other to compute the desired output words. In contrast with conventional sequential view of Lyee methodology, there are no need for various action vectors and control functions, no need of working memory
Fig. 11. Processes route diagram.
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
areas, etc. More details about the function Jðs1 ; .; sk Þ together with concrete examples will be given in the sequel. Section 4 gives a more detailed and complete formalization of the Lyee methodology.
nil Output vector O4(x)Z ½ıx4 ?x: [dx!x].
4. Formalization of the Lyee methodology Let Use(e) denote the set of words used in the expression e. For instance, Use(a*bC1)Z{a,b}. Also, let FðSÞ be the following function:
Fðfxgg AÞ Z fıx4 ?xgg FðAÞ Now let us see how to automatically generate software from simple user requirement using the Lyee-calculus. Suppose that the user requirement contains k screens {s1,.,sk}. Suppose also that each screen contains a set of statements where each one of them has the following form: (w, e, c, InOut, type) where w is a word, e its definition, c its condition, InOut to specify if it is an input, an output both or neither input nor output (the value i is used to specify an input word, o to specify an output, io to specify both input and output and empty filed to specify for neither input nor output) and type is its type (the type B is reserved for button). To define the program §ðs1 ; .; sk Þ associated with this requirement, we need to formalize the following vectors (processes): Significant vectors L4(x, e)Z ½ıx3 ?1: ½FðUseðeÞÞ: ½Œ x4 !e: nil L3(x, c)Z ½FðUseðcÞÞ: ½ıx3 !c: nil L2(x)Z ½ıx2 ?x: ½Œ x4 !x: nil
½ıx2 !x:
Routing vector R3(b, e, s)Z [db?click]. ½FðUseðeÞÞ: ½ıs !e: nil
Finish Comments Wait to receive the value of x from the memory Send the value of x on the channel dx Finish Comments Wait to receive any value (initialization) and then behave as Sx4 ðyÞ If you receive z behaves as Sx4 ðzÞ (change the content of the cell x) If you send y behave as Sx4 ðyÞ (do not change the content of the cell x) Comments Wait until the button b be pushed Evaluate the condition of the button Send the result to the screen s (i.e. activate s if eZ1) Finish
Pallet. The three pallets W02, W03 and W04 of a given screen s are formalized as follows: W02 ðsÞ Z jðw; * ; * ;ı;BÞ2s I2 ðwÞjðw; * ; * ;ı;BÞ2s L2 ðwÞ L3 ðw; cÞjðw;e;c;ı; * ;BÞ2s R3 ðw; c; eÞ W03 ðsÞ Z jðw; * ;c; * ;BÞ2s W04 ðsÞ Z jðw; * ; * ; * ;BÞ2s S4 ðwÞjðw;e; * ; * ;BÞ2s
Comments
!L4 ðw; eÞÞjðw; * ; * ;o; * ; * Þ2s O4 ðwÞ ıx3
wait to receive the value true (1) on the channel (from L3) wait to receive the value of all the Use of e from the memory evaluate e and put the result in the memory cell of x finish
where B denotes any type except B (complementary of B) and * denotes anything. Scenario Function. The scenario function, it SF(s), attached to the screen s is formalized as follows:
wait to receive the value of all the Use of c from the memory evaluate c and send the result of the channel ıx3 (to L4) finish
Control Function. The control function attached to a screen s, is formalized as follows:
wait to receive the value x on the channel ıx2 (from the input vector) save the value of x in the memory cell of x finish
The control function attached to a set of screens is formalized as follows:
Action vectors Input vector I2(x)Z [dx?x].
Sx4 ðyÞZ ½Œ x4 ?z$Sx4 ðzÞC ½ıx4 !y:Sx4 ðyÞ
FðYÞ Z Y
Vector
nil Memory (structural vector) S4 ðxÞZ ½Œ x4 ?y$Sx4 ðyÞ
273
Comments Wait to receive the value on the channel dx Send the value of x on the channel ıx2 (to L2)
SFðsÞ Z W04 ðsÞjW03 ðsÞjW02 ðsÞ
FðsÞ Z SFðsÞ . ½ısk ?1:FðsÞ
Jðs1 ; .; sk Þ Z ðjs2fs1 ;.;sk g ½ıs ?1:FðsÞÞ . ½ıs0 ?1:nil We suppose that s0 is the screen that we find when we exit the program (exit screen that does not belongs to the screens of the program itself). Lyee Program. Finally, the Lyee program §ðs1 ; .; sk Þ associated with the requirement containing the screens s1,.,sk is as follows §ðs1 ; .; sk Þ Z Jðs1 ; .; sk Þ=Lðs1 ; .; sk Þ
274
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
where the set Lðs1 ; .; sk Þ contains all the input and output channels and it is defined as follows: Lðs1 ; .; sk Þ Z g fdw g g fıs1 g ðw; * ; * ;ı=o; * Þ2sk
The meaning of i/o is that this field has to contains the value i, o or io. We suppose also that s1 is the first screen that appears when the user runs this program. Fig. 12. Case study-one screen.
5. Case study In this section, we give some concrete examples and we describe step by step how a Lyee program progress in order to compute words within our Lyee-calculus.
W03(s1)ZL3(b, aO0)jR3(B0, click, s0) L3 ðb; aO 0ÞZ ½ıa4 ?a: ½ıb3 !ðaO 0Þ: nil
R3(B0, click, s0)Z[dB0?click]. ½ıs0 !1: nil
5.1. One-screen example W04(s1)ZS4(a)jS4(b)jL4(b, 2*a)jO4(b)
The example that we present hereafter contains only one screen. As shown by the requirement given in Table 6, a user can input a word a, waits for the value of b and then exit the screen by pushing the button B0. Fig. 12 illustrates such a screen. This screen s1 is composed from three statements:
S4 ðaÞZ ½Œ a4 ?a: Sa4 ðaÞ S4 ðbÞZ ½Œ b4 ?b: Sb4 ðbÞ
L4 ðb; 2 aÞZ ½ıb3 ?1: ½ıa4 ?a: ½Œ b4 !ð2 aÞ: nil
O4 ðbÞZ ½ıb4 ?b: [db!b] nil
According to the definition of a generic Lyee program given in Section 3, the Lyee program associated to the requirement given by Table 6 is as follows:
Suppose now, that the end-user (environment) of this program wants to perform the following sequence of actions: runs the program (activates the screen s1), gives the value 7 to the word a, waits for the value of the word b and then exits the program by pushing the button B0. This comportement can be captured by the following process E:
SFðs1 Þ Z W04 ðs1 ÞjW03 ðs1 ÞjW02 ðs1 Þ
Process
s1 Z fða; ; ; i; realÞ; ðb; 2 * a; aO 0; o; realÞ; ðB0 ; s0 ; Click; BÞg
s1
EZ ½ı !1$E1 E1 Z ½da !7$E2 E2 Z ½db ?x$E3 E3 Z ½dB0 !click:nil
Fðs1 Þ Z SFðs1 Þ . ½ıs1 ?1:Fðs1 Þ Jðs1 Þ Z ð½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nil Lðs1 Þ Z fda ; db ; dB0 ; ıs1 g §ðs1 Þ Z Jðs1 Þ=Lðs1 Þ where W02(s1), W03(s1) and W04(s1) are as shown hereafter: W02(s1)ZL2(a)jI2(a) L2 ðaÞZ ½ıa2 ?a: ½Œ a4 !a: nil
I2(a)Z[da?a]. ½ıa2 ?a: nil
Table 6 Lyee requirements: screen I Word
Definition
Condition
a b B0
2*a s0
aO0 iClick
IO
Type
I o
real real B
Comments activate the program (screen s1) give the value 7 to the word a give the value of the word b click the button B0 to exit
Let us see now how the program interact with this environment to reach the desire goal. In other words, we want to have a trace of the program progress when executed in parallel with the program E that implements the end-user actions, i.e. we look for the behaviors of §ðs1 ÞjE. The steps of this trace is as shown hereafter: §ðs1 ÞjE Z hBy definition of § and Ei Jðs1 Þ=Lðs1 Þj½ıs1 !1:E1 Z hBy definition of Ji ðð½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 Þj½ıs1 !1:E1 t / hSynchronization—End-user activates the program by running the screen s1i ðFðs1 Þ . ½ıs0 ?1:nilÞ=Lðs1 ÞjE1 Z hBy definition of F and E1 i ððSFðs1 Þ . j½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 Þj½da !7:E2 Z hBy definition of SFi ðððW04 ðs1 ÞjW02 ðs1 ÞjW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ = Lðs1 Þj½da !7:E2
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
Z hBy definition of W02 and consequently I2i ðððW04 ðs1 ÞjL2 ðaÞjð½da ?a:½ıa2 !a:nilÞjW03 ðs1 ÞÞ . /Þ . /Þ= Lðs1 Þj½da !7:E2 t / hSynchronization—Through I2 end-user gives the value 7 to the word ai ðððW04 ðs1 ÞjL2 ðaÞjð½ıa2 !7:nilÞjW03 ðs1 ÞÞ . /Þ . /Þ=Lðs1 ÞjE2 Z hBy definition of L2i ðððW04 ðs1 Þjð ½ıa2 ?a:½Œ a4 !a:nilÞjð½ıa2 !7:nilÞjW03 ðs1 ÞÞ . /Þ . /Þ= Lðs1 ÞjE2 t / hSynchronization—The value of a is communicated to L2(a)i ðððW04 ðs1 Þj𽌠a4 !7:nilÞjW03 ðs1 ÞÞ . /Þ . /Þ=Lðs1 ÞjE2 Z hBy definition of W04i ððS4 ðaÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞj𽌠a4 !7:nilÞjW03 ðs1 ÞÞ ./Þ=Lðs1 ÞjE2 Z hBy definition of S4(a)i ðð𽌠a4 ?a:Sa4 ðaÞÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞj𽌠a4 !7:nilÞ jW03 ðs1 ÞÞ . / t / hSynchronization—The value of a is stored in the memoryi ððSa4 ð7ÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞjW03 ðs1 ÞÞ . / Z hBy definition of Sa4 ð7Þ and W03i ðð𽌠a4 ?z:Sa4 ðzÞC ½ıa4 !7:Sa4 ð7ÞÞj /jðL3 ðb; aO 0Þ jR3 ðB0 ; click; s0 ÞÞÞ . / Z hBy definition of L3i ðð𽌠a4 ?z:Sa4 ðzÞC ½ıa4 !7:Sa4 ð7ÞÞj /jðð½ıa4 ?a: ½ıb3 !ðaO 0Þ:nilÞj/ t / hSynchronization—The value of a is communicated to L3(b) to compute the b conditioni ððSa4 ð7ÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞjð½ıb3 !ð7O 0Þ:nilÞj/ Z hBy definition of L4 and evaluation of (7O0)i ððSa4 ð7ÞjS4 ðbÞjð½ıb3 ?1:½ıa4 ?a:½Œ b4 !ð2 * aÞ:nilÞjO4 ðbÞj ð½ıb3 !1:nilÞj/ t
/ hSynchronization—The b condition is evaluated and communicated to L4(b) to activate the computation of bi ððSa4 ð7ÞjS4 ðbÞjð½ıa4 ?a:½Œ b4 !ð2 * aÞ:nilÞjO4 ðbÞj/ Z hBy definition of Sa4 ð7Þi ðð𽌠a4 ?z:Sa4 ðzÞC ½ıa4 !7:Sa4 ð7ÞÞjS4 ðbÞjð½ıa4 ?a:½Œ b4 !ð2 * aÞ:nilÞ jO4 ðbÞj / t
/ hSynchronization—The value of a is communicated to L4i ððSa4 ð7ÞjS4 ðbÞj𽌠b4 !ð2 * 7Þ:nilÞjO4 ðbÞjR3 ðB0 ; click; s0 ÞÞ . / Z hBy definition of S4(b) and evaluation of (2*7)i ððSa4 ð7Þj𽌠b4 ?b:Sb4 ðbÞÞj𽌠b4 !ð14Þ:nilÞjO4 ðbÞj R3 ðB0 ; click; s0 ÞÞ . / t / hSynchronization—The value of b (14) is stored in the memoryi ððSa4 ð7ÞjSb4 ð14ÞjO4 ðbÞjR3 ðB0 ; click; s0 ÞÞ . / Z hBy definition of Sb4 and O4(b)i ððSa4 ð7Þj𽌠b4 ?z:Sb4 ðzÞC ½ıb4 !14:Sb4 ð14ÞÞjð½ıb4 ?b:½db !b:nilÞj R3 ðB0 ; click; s0 ÞÞ . / t / hSynchronization—The b value is communicated to O4i
275
ððSa4 ð7ÞjSb4 ð14Þjð½db !14:nilÞjR3 ðB0 ; click; s0 ÞÞ . /Þ= Lðs1 ÞjE2 Z hBy definition of E2 i ððSa4 ð7ÞjSb4 ð14Þjð½db !14:nilÞjR3 ðB0 ; click; s0 ÞÞ . /Þ= Lðs1 Þj½db ?x:E3 t / hSynchronization—The b value, stored in O4, is communicated to the environmenti ððSa4 ð7ÞjSb4 ð14ÞjR3 ðB0 ; click; s0 ÞÞ . /Þ=Lðs1 ÞjE3 Z hBy definition of R3 and E3 i ððSa4 ð7ÞjSb4 ð14Þjð½dB0 ?click:½ıs0 !1:nilÞÞ . .Þ=Lðs1 Þ j½dB0 !click:nil t / hSynchronization—The end-user push button B0 to exiti ððSa4 ð7ÞjSb4 ð14Þjð½ıs0 !1:nilÞÞ . ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ= Lðs1 Þ t / hSynchronization—The system ends its executioni nil To summarize, here are the main steps of the program progress: 1. End-user activates the program by running the screen s1. ðð½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 Þj½ıs1 !1:E1 2. Through I2(a), end-user gives the value 7 to the word a. ðððW04 ðs1 ÞjL2 ðaÞjð½da ?a:½ıa2 !a:nilÞjW03 ðs1 ÞÞ . /Þ . /Þ= Lðs1 Þj½da !7:E2 3. The value of a is communicated to L2(a). ðððW04 ðs1 Þjð½ıa2 ?a:½Œ a4 !a:nilÞjð½ıa2 !7:nilÞj W03 ðs1 ÞÞ./Þ./Þ=Lðs1 ÞjE2 4. The value of a is stored in the memory, i.e. in S4(a). ðð𽌠a4 ?a:Sa4 ðaÞÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞj𽌠a4 !7:nilÞj W03 ðs1 ÞÞ . / 5. The value of a is communicated to L3(b) to compute the b condition. ðð𽌠a4 ?z:Sa4 ðzÞC½ıa4 !7:Sa4 ð7ÞÞj/j ðð½ıa4 ?a:½ıb3 !ðaO0Þ:nilÞj/ 6. The b condition is evaluated and communicated to L4(b). ððSa4 ð7ÞjS4 ðbÞjð½ıb3 ?1:½ıa4 ?a:½Œ b4 !ð2 * aÞ:nilÞjO4 ðbÞj ð½ıb3 !1:nilÞj/ 7. The value of a is communicated, from memory, to L4(b). ðð𽌠a4 ?z:Sa4 ðzÞ C ½ıa4 !7:Sa4 ð7ÞÞjS4 ðbÞjð½ıa4 ?a: ½Œ b4 !ð2 * aÞ:nilÞjO4 ðbÞj/
276
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281 Table 7 Lyee requirements: screen I Word
Definition
Condition
a b B2
2*a s2
aO0 click
IO
/
IS
/ / /
where §1 ðs1 Þ Z ðFðs1 Þ . ½ıs0 ?1:nilÞ=Lðs1 Þ is justified by the following proof:
Fig. 13. Interaction between processes.
8. The value of b is stored in the memory, i.e. in S4(b). ððSa4 ð7Þj𽌠b4 ?b:Sb4 ðbÞÞj𽌠b4 !ð14Þ:nilÞjO4 ðbÞj R3 ðB0 ; click; s0 ÞÞ . / 9. The b value is communicated to the output vector O4(b). ððSa4 ð7Þj𽌠b4 ?z:Sb4 ðzÞ C ½ıb4 !14:Sb4 ð14ÞÞjð½ıb4 ?b:½db !b:nilÞj R3 ðB0 ; click; s0 ÞÞ . / 10. The b value, stored in O4, is communicated to the environment. ððSa4 ð7ÞjSb4 ð14Þjð½db !14:nilÞjR3 ðB0 ; click; s0 ÞÞ . /Þ= Lðs1 Þj½db ?x:E3 11. The end-user push button B0 to exit. ððSa4 ð7ÞjSb4 ð14Þjð½dB0 ?click:½ıs0 !1:nilÞÞ . /Þ= Lðs1 Þj½dB0 !click:nil Fig. 13 illustrates each of these steps. Furthermore, each transition could be validated by a proof. For instance, the transition
In Appendix, we report more proofs related to the program execution. 5.2. Two screen example The idea behind this example is to show the interaction between many screens (Fig. 14). According to the definition of a generic Lyee program given in Section 4, the Lyee program associated to the requirement given by Tables 7 and 8 is as follows: SFðs1 Þ Z W04 ðs1 ÞjW03 ðs1 ÞjW02 ðs1 Þ SFðs2 Þ Z W04 ðs1 ÞjW03 ðs1 Þ Notice that there is no W02 for the screen s2 since it does not contain input words other than buttons Fðs1 Þ Z SFðs1 Þ . ½ıs1 ?1:Fðs1 Þ Fðs2 Þ Z SFðs2 Þ . ½ıs2 ?1:Fðs2 Þ Jðs1 ; s2 Þ Z ð½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nil Lðs1 ; s2 Þ Z fda ; db ; de ; dB0 ; dB2 g §ðs1 ; s2 Þ Z Jðs1 ; s2 Þ=Lðs1 ; s2 Þ
t
ð§ðs1 ÞjEÞ / ð§1 ðs1 ÞjE1 Þ
where W02(s1)ZL2(a)jI2(a) L2 ðaÞZ ½ıa2 ?a: ½ıa4 !a: nil
I2(a)Z[da?a]. ½ıa2 !a: nil
Table 8 Lyee requirements: screen II
Fig. 14. Case study—two screen.
Word
Definition
Condition
IO
/
e B0
1Cb s0
bO0 Click
OS
/ /
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
W03(s1)ZL3(b, aO0)jR3(B2, click, s2) L3 ðb; aO 0ÞZ ½ıa4 ?a: ½ıb3 !ðaO 0Þ: nil W03(s2)ZL3(e, bO0)jR3(B0, click, s0) L3 ðe; bO 0ÞZ ½ıb4 ?b: ½ıe3 !ðbO 0Þ: nil
R3 ðB2 ; click; s2 ÞZ ½dB2 ?click: ½ıs2 !1: nil R3 ðB0 ; click; s0 ÞZ ½dB0 ?click: ½ıs0 !1: nil
W04(s1)ZS4(a)jS4(b)jL4(b, 2*a)jO4(b) S4 ðaÞZ ½Œ a4 ?a: L4 ðb; 2 aÞZ ½ıb3 !1: Sa4 ðyÞ ½ıa4 ?a: b S4 ðbÞZ ½Œ 4 ?b: ½Œ b4 !ð2 aÞ: b nil S4 ðyÞ W04(s2)ZS4(e)jL4(e, 1Cb)jO4(e) L4 ðe; 1C bÞZ ½ıe3 !1: e S4 ðeÞZ ½Œ 4 ?e: ½ıb4 ?b: Se4 ðyÞ ½Œ e4 !ð1C bÞ: nil
277
in two steps. First the value of a is communicated to L2(a) and second L2(a) will communicate this value to the memory. The first step is as follows: t
§2 ðs1 ; s2 ÞjE2 / §3 ðs1 ; s2 ÞjE2 where §3 ðs1 ; s2 Þ Z ðððW04 ðs1 Þj½Œ a4 !7:niljW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ
O4 ðbÞZ ½ıb4 ?b: [db!b]. nil
. ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ In the second, the value of a will be stored in the memory of W04 t
O4 ðeÞZ ½ıe4 ?e: [db!e]. nil
s1 Z fða; ; ; i; sÞ; ðb; 2 a; aO 0; o; sÞg Suppose now, that the end-user (environment) of this program wants to perform the following sequence of actions: runs the program (activates the screen s1), gives the value 7 to the word a, waits for the value of the word b, pushes the button B2 to go to the screen s2, waits for the value e and then exits the program by pushing the button B0. This comportement can be captured by the following process E:
§3 ðs1 ; s2 ÞjE2 / §4 ðs1 ; s2 ÞjE2 where §4 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞjW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 4. The value of a is communicated to L3(b) to compute the b condition: t
End-user action
Comments
EZ ½ıs1 !1:E1 E1 Z ½da !7:E2 E2 Z ½db ?b:E3 E3 Z ½ıB2 !click:E4 E4 Z ½de ?e:E5 E5 Z ½ıB0 !click:nil
Activate the program Give the value 7 to a word a Wait for the value of the word b Pushes the button B2 to go screen 2 Wait for the value of the word e Push the button B0 to exit
/ §5 ðs1 ; s2 ÞjE2 §4 ðs1 ; s2 ÞjE2 where §5 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞj !½ıb3 !ð7O 0Þ:niljR3 ðB2 ; s2 ; clickÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ
1. End-user activates the program by running the screen s1: t
/ §1 ðs1 ; s2 ÞjE1 §ðs1 ; s2 ÞjE where §1 ðs1 ; s2 Þ Z ðFðs1 Þj½ıs2 ?1:Fðs2 Þ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 2. The end-user gives the value 7 to the word a. t
§1 ðs1 ; s2 ÞjE1 / §2 ðs1 ; s2 ÞjE2 where §2 ðs1 ; s2 Þ Z ððððW04 ðs1 Þj½ıa2 !7:niljL2 ðaÞjW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 3. The value of a is stored in the memory: this will be done
5. The b condition is evaluated and communicated to L4(b) to activate the computation of b: t
§5 ðs1 ; s2 ÞjE2 / §6 ðs1 ; s2 ÞjE2 where §6 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjS4 ðbÞj½Œ a4 !ð2 * aÞ:nilj O4 ðbÞjR3 ðB2 ; s2 ; clickÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 6. The b value is computed and communicated to S4(b), the memory area of b: t
§6 ðs1 ; s2 ÞjE2 / §7 ðs1 ; s2 ÞjE2
278
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
where
where
§7 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞjO4 ðbÞÞ
§12 ðs1 ;s2 ÞZðððSa4 ð7ÞjSb4 ð14ÞÞ
. ½ıs1 ?1:niljR3 ðB2 ; s2 ; clickÞÞ
.½ıs1 ?1:Fðs1 ÞjðSe4 ð15ÞjO4 ðeÞ
. ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ
!jR3 ðB0 ;s0 ;clickÞÞ
. ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ
.½ıs1 ?1:Fðs1 ÞÞ.½ıs0 ?1:nilÞ=Lðs1 ;s2 Þ 12. Output the value of e:
7. The b value is outputted, i.e. communicated to the environment (end-user): t
§7 ðs1 ; s2 ÞjE2 / §8 ðs1 ; s2 ÞjE3
t
/ §12 ðs1 ; s2 ÞjE5 §11 ðs1 ; s2 ÞjE3 where §12 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞÞ
where
. ½ıs1 ?1:Fðs1 ÞjðSe4 ð15ÞjR3 ðB0 ; s0 ; clickÞÞ
§8 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞjR3 ðB2 ; s2 ; clickÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 8. The end-user push B2 to go to screen 2: t
/ §9 ðs1 ; s2 ÞjE4 §8 ðs1 ; s2 ÞjE3
. ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 13. The end-user pushes B0 to exit the program: t
§12 ðs1 ; s2 ÞjE5 / ðððSa4 ð7ÞjSb4 ð14ÞÞ . ½ıs1 ?1:Fðs1 ÞjðSe4 ð15Þj½ıs0 ?1:nilÞ . ½ıs1 ?1:Fðs1 ÞÞ t
/ nil . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ
where §9 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞÞj½ıs1 ?1:Fðs1 ÞjFðs2 ÞÞj !½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 9. Get the value of b from the memory to compute the condition of e: t
§9 ðs1 ; s2 ÞjE3 / §10 ðs1 ; s2 ÞjE4 where §10 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞÞ . ½ıs1 ?1:Fðs1 ÞjðW04 ðs2 Þj !½ıe3 ð14O 0Þ:niljR3 ðB0 ; s0 ; clickÞÞ . ½ıs1 ?1:Fðs1 ÞÞj½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 10. Compute the value of e: t
§10 ðs1 ; s2 ÞjE3 / §11 ðs1 ; s2 ÞjE4 where §11 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞÞ . ½ıs1 ?1:Fðs1 ÞjðS4 ðeÞj !½Œ e4 ð1 C 14Þ:niljO4 ðeÞjR3 ðB0 ; s0 ; clickÞÞj !½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 11. Store the value of e in the memory t
§11 ðs1 ; s2 ÞjE3 / §12 ðs1 ; s2 ÞjE4
6. Conclusion In this paper, we have first defined a formal process algebra, called Lyee-calculus, that easily and naturally supports the basic concepts of the Lyee methodology. In fact, this calculus can be seen as an abstract machine which is more suitable to support the Lyee methodology concepts than the Von Newman one. This machine considers a program as a set of molecules that interact together to produce a final result. Secondly, we have shown how this calculus can formalize and simplify both the lyee vectors together with the whole software generation process. Actually, synchronization vector, most of the routing vectors, command vector, etc. are no longer needed. We have also formalized the whole process of the automatic generation of Lyee software generation. This formalization offers to this methodology a formal semantics that allows one to clearly understand the concepts behind this methodology. Besides, this formal description will be an inevitable start point for many interesting analysis on diverse aspects of this methodology. For instance, to optimize the Lyee generated software or the software generation processes, we need a formal proof that the optimized program is equivalent to its original version. Formal equivalence checking or more generally model checking can be elegantly achieved when using process algebra. As future work, we want to investigate more the semantics of Lyee methodology in order to make it more simple and to generate, from requirements, more reliable and optimized
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
code. For the optimization end, we intend to define a congruence relation between processes of Lyee-calculus and then using it to prove the correctness of all the eventual optimizations.
279
where §2 ðs1 Þ Z ðððW04 ðs1 Þj½ıa2 !7:niljL2 ðaÞjW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ |fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} §12 ðs1 Þ
. ½ıs0 ?1:nilÞ=Lðs1 Þ Proof. §11 ðs1 Þ zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl}|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{ §1 ðs1 Þ Z ðFðs1 Þ . ½ıs0 ?1:nilÞ=Lðs1 Þ Z ðððW04 ðs1 Þ j ½da ?a:½ıa2 !a:nil j L2 ðaÞ j W03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ |fflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflffl} I2 ðaÞ
. ½ıs0 ?1:nilÞ=Lðs1 Þ First let us prove that:
Appendix Hereafter, we give more proof concerning the requirement
§2 ðs1 Þ
da ?7
/
§3 ðs1 Þ
Now, we deduce that:
given by Table 6 (page 20). 1. End-user activates the program by running the screen s1: t
3. The value of a is stored in the memory: this will be done in two steps. First the value of a is communicated to L2(a) and second L2(a) will communicate this value to the memory. The first step is as follows:
/ ð§1 ðs1 ÞjE1 Þ ð§ðs1 ÞjEÞ
t
§2 ðs1 ÞjE2 / §3 ðs1 ÞjE2
where §1 ðs1 Þ Z ðFðs1 Þ . ½ıs0 ?1:nilÞ=Lðs1 Þ
where
Proof.
§3 ðs1 Þ ZðððW04 ðs1 Þj½Œ a4 !7:niljW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ |fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} 12½½1 ıs1 ?1 s 1 ½ı ?1:Fðs1 Þ / Fðs1 Þ l R. : ıs1 ?1 Jðs1 Þ / Fðs1 Þ . ½ıs0 ?1:nil R! : 12½½1 ıs1 ?1 ıs1 !1 E §ðs1 Þ / §1 ðs1 Þ / E1 t ð§ðs1 ÞjEÞ / ð§1 ðs1 ÞjE1 Þ R? :
R= : Rtj
:
§13 ðs1 Þ
. ½ıs0 ?1:nilÞ=Lðs1 Þ Proof. We have: §2 ðs1 ÞZððððW04 ðs1 Þj½ıa2 !7:niljL2 ðaÞjW03 ðs1 ÞÞ.½ıs1 ?1:Fðs1 ÞÞ |fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} §12 ðs1 Þ
2. The end-user gives the value 7 to the word a. t
ð§1 ðs1 ÞjE1 Þ / ð§2 ðs1 ÞjE2 Þ
.½ıs0 ?1:nilÞ=Lðs1 Þ
280
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
Then:
It follows that
Second, let us show how the value of a will be stored in the memory of W04. In other words, we want to prove that:
5. The b condition is evaluated and communicated to L4(b) to activate the computation of b:
t
§3 ðs1 ÞjE2 / §4 ðs1 ÞjE2
t
§5 ðs1 ÞjE2 / §6 ðs1 ÞjE2
where
where
§4 ðs1 ÞZðððSa4 ð7ÞjS4 ðbÞjL4 ðb;2*aÞjO4 ðbÞjW03 ðs1 ÞÞ.½ıs1 ?1:Fðs1 ÞÞ
|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl}
§6 ðs1 Þ Z ðððSa4 ð7ÞjS4 ðbÞj½Œ a4 !ð2 * aÞ:niljO4 ðbÞ
§14 ðs1 Þ
!jR3 ðB0 ; click; s0 ÞÞ
.½ıs0 ?1:nilÞ=Lðs1 Þ
. ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 Þ
We have:
It follows that:
4. The value of a is communicated to L3(b) to compute the b condition:
6. The b value is computed and communicated to S4(b), the memory area of b: t
t
§4 ðs1 ÞjE2 / §5 ðs1 ÞjE2
§6 ðs1 ÞjE2 / §7 ðs1 ÞjE2 where
where §5 ðs1 Þ Z ðððSa4 ð7ÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞj !½ıb3 !ð7O 0Þ:nilÞjR3 ðB0 ; click; s0 Þ
§7 ðs1 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞjO4 ðbÞjR3 ðB0 ; click; s0 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 Þ
. ½ıs1 ?1:Fðs1 ÞÞ
7. The b value is outputted, i.e. communicated to the environment:
. ½ıs0 ?1:nilÞ=Lðs1 Þ
/ §8 ðs1 ÞjE3 §7 ðs1 ÞjE2
t
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
where §8 ðs1 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞjR3 ðB0 ; click; s0 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ [4]
. ½ıs0 ?1:nilÞ=Lðs1 Þ 8. The end-user pushes B to exist: §8 ðs1 ÞjE3 t/ðððSa4 ð7ÞjSb4 ð14Þj½ıs0 ?1:nilÞ . ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ÞjE3 t/nil
[5] [6]
[7]
References [8] [1] J.C.M. Baeten, J.A. Bergstra, Real time process algebra with infinitesimals in: A. Ponse, C. Verhoef, S.F.M. van Vlijmen (Eds.),, Algebra of Communicating Processes: Proceedings of the First Workshop on the Algebra of Communicating Processes (ACP-94), Springer, Berlin, 1995, pp. 148–187. [2] J.A. Bergstra, J.W. Klop, Algebra of communicating processes with abstraction, Theoretical Computer Science 37 (1) (1985) 77–121. [3] J.A. Bergstra, J.W. Klop, The algebra of recursively defined processes and the algebra of regular processes in: A. Ponse, C. Verhoef,
[9] [10]
[11]
281
S.F.M. van Vlijmen (Eds.),, Algebra of Communicating Processes: Proceedings of the First Workshop on the Algebra of Communicating Processes (ACP-94), Springer, Berlin, 1995, pp. 1–25. G. Berry, G. Boudol, The chemical abstract machine, in: Proceedings of the 17th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, POPL’90, San Francisco, CA, USA, 1990. G. Boudol, Some chemical abstract machines, Lecture Notes in Computer Science (LNCS) 803 (1994) 92–123. C.A.R. Hoare, Communicating Sequential Processes, Prentice Hall International Series in Computer Science, Prentice Hall, Englewood Cliffs, NJ, 1985. M. Mejri, B. Ktari, M. Erhioui, Static analysis on lyee-oriented software in: H. Fujita, P. Johannesson (Eds.),, New Trends in Software Methodologies, Tools and Techniques, Proceedings of First International Workshop on Lyee Methodology, Paris, IOS Press, 2002, pp. 375–394. R. Milner, A Calculus of Communicating Systems, Lecture Notes in Computer Science 92, Springer, Berlin, 1980. F. Negoro, Principle of Lyee software, in: The International Conference on Information Society in 21st Century (IS2000), 2000, pp. 121–189. F. Negoro, Principle of Lyee software, in: The 2000 International Conference on Information Society in 21st Century (IS2000), Aizu, Fukushima, Japan, November 2000, pp. 121–189. F. Negoro, I. Hamid, A proposal for intention engineering, in: The Fifth East-European Conference Advances in Databases and Information System (ADBIS’2001), Vilnius, Lithuania, September 2000.
A process algebra to formalize the Lyee methodology Hamido Fujitaa,*, Mohamed Mejrib, Be´chir Ktarib a b
Faculty of Software and Information Science, Iwate Prefectural University, 152-52 Sugo, Takizawa, Iwate, 020-0193, Japan Faculty of Software and Information Science, Department of Computer Science and Software Engineering, Laval University, Que´bec, G1K 7P4, Canada Received 21 June 2004; accepted 9 July 2004 Available online 18 October 2004
Abstract Over the last years, various methodologies and techniques have been elaborated and proposed to improve one or many aspects related to the software development life cycle. However, despite the great effort in this research field, the production of clearly understood and modifiable systems still an ambitious goal and far from reached. This is due, on one hand, to the complexity and the subtlety of software themselves and, on the other hand, to the limitations of the current methodologies. Recently, a new and very promising methodology, called Lyee, has been proposed. Intended to deal efficiently with a wide range of software problems related to different field, Lyee allows the development of software by simply defining their requirements. Nevertheless, since both the semantics of Lyee generated software together with the process of automatic generation of software from requirements are described using informal language, difficulties and confusions may arise when trying to understand and study this methodology. The main purpose of this paper is to formalize, using a process algebra, the process of automatic generation of softwares together with the semantics of Lyee generated softwares. Actually, process algebra naturally supports many concepts of the Lyee methodology and consequently formalize them simply and elegantly. It offers to the Lyee methodology an abstract machine more suitable than the VonNewman one. In fact, this new abstract machine consider a program as chemical solution when molecules (different vectors of the lyee methodology) interact together to reach a collective goal. q 2004 Elsevier B.V. All rights reserved. Keywords: Lyee methodology; Process algebra; Operational semantics; Bisimulation
1. Introduction Producing easily and quickly software with high quality is the basic concern of the software development research field. Over the last years, various methodologies and techniques have been elaborated and proposed to improve one or many aspects related to the software development life cycle. However, despite the great effort in this research field, the production of clearly understood and modifiable systems still an ambitious goal and far from reached. This is due, on one hand, to the complexity and the subtlety of software themselves and, on the other hand, to the limitations of the current methodologies. In fact, almost all of the proposed
* Corresponding author. E-mail address: [email protected] (H. Fujita). 0950-7051/$ - see front matter q 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.knosys.2004.07.006
methodologies fail to produce clearly understood and modifiable systems and their use is still considered to be an activity accessible only to specialists with a large array of competencies, skills, and knowledge. This, in turn, leads to highly paid personal, high maintenance costs, and extensive checks needing to be performed on the software. For these reasons, companies are likely to welcome any new methodology promising demonstrable improvement in the software development cycle. Recently, a new and very promising methodology, called Lyee [10,11] (governmentaL methodologY for softwarE providencE), has been proposed. Intended to deal efficiently with a wide range of software problems related to different fields, Lyee allows the development of software by simply defining its requirements. More precisely, a developer has only to provide words, calculation formulae, calculation conditions (preconditions) and layout of screens and printouts, and then
264
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
leaves in the hands of the computer all subsequent troublesome programming process (e.g. control logic aspects). Despite its recency, the results of the use of Lyee have shown tremendous potential. In fact, compared to conventional methodologies, development time, maintenance time and documentation volume can be considerably reduced by using Lyee. In [7], we proposed some classical static analysis techniques in order to improve many aspects of this methodology, in particular Lyee requirements. Nevertheless, since both the semantics of Lyee generated software together with the process of automatic generation of software from requirements are described using informal language, difficulties and confusions may arise when trying to understand and study this methodology. In addition, the ideas behind this methodology are described using a sequential language which is not appropriate to support them. In fact, a Lyee generated software is basically made of small components (called vectors in Lyee terminology), where each one has an atomic goal, that collaborate together by interaction in order to produce the desired results (global goal). It is, however, commonly known that a process algebra which naturally supports concurrency and communication is the appropriate language to specify concurrent components and therefore it will provides a formal and worthy foundation to support the Lyee methodology concepts. Among other beneficial consequences of using process algebra with the Lyee methodology, many components (complete vectors or parts of vectors) of the actual version of Lyee, which their presence was forced by the sequential language used to describe it, will no longer be necessary since they are naturally supported by process algebra. Actually, synchronization vector, most of the routing vectors, command vector, etc. are no longer needed. Thus, we obtain a formal description of Lyee that is simple and that produce program shorter and consuming less time and memory. Besides, this formal description will be an inevitable start point for many interesting analysis of diverse aspects of this methodology. For instance, to optimize the Lyee generated software or the software generation processes, we need a formal proof that the optimized program is equivalent to its original version. Formal equivalence checking or more generally model checking can be elegantly achieved when using process algebra. In this paper, we first define a formal process algebra, called Lyee-calculus, that easily and naturally supports the basic concepts of the Lyee methodology. In fact, this calculus can be seen as an abstract machine which is more suitable to support the Lyee methodology concepts than the Von Newman one. This machine considers a program as a set of molecules that interact together to produce a final result. Second, we show how this calculus can formalize and simplify both the Lyee vectors together with the whole software generation process. Actually, we have formalized the whole process of the automatic generation of Lyee software generation.
The remainder of this paper is organized as follows. In Section 2, we define the syntax and the semantics of the Lyee-calculus. In Section 3, we give a short and technical introduction to the Lyee methodology and an overview of its formalization using the Lyee-calculus. In Section 4, we propose a detailed and complete formalization of the Lyee methodology using our calculus. In Section 5, we present one case study that concretely shows both how a program is automatically generated from simple requirement together with a step-by-step description of the execution of the generated program. Finally, Section 6 provides concluding remarks on this work, and discusses some future work.
2. Lyee-calculus Process algebra is a formal description technique for complex computer systems, especially those involving communication and concurrent components [1–3,6,8]. Process algebra is generally referred as calculus in the literature since it involves a variety of mathematical and logic concepts (concurrency theory, operational semantics, complexity theory, logic, etc.) that goes beyond the process algebra field. In this section, we give the syntax and the semantics of a new calculus, called Lyee-calculus, that we have specially defined to formalize the Lyee methodology. 2.1. Syntax Lyee-calculus programs are systems composed of independent and parallel processes that communicate using hand-shake technique on named channels. The channel can be restricted so that only some process can communicate on them. A process can send a value v through a channel ı by doing the action ½ı!e (v corresponds to the valuation of e). Similarly, a process can receive a value from a channel by doing the action ½ı?e. A process can also perform a silent action t. This special action, intended to represent internal behavior of a system such as synchronization between processes, is also useful to capture indeterminism within process evolution. The syntax of processes is presented in Table 1. The intuitive meaning of each syntactic construction is as follows: † Sequence: [K]$P, where K is a set of actions, is a process that has to perform all the action in K and then behaves as the process P. The order in which the actions in K have to be executed is not important. Notice that for the sake of simplicity we write [k1,.,kn] instead of [{k1,.,kn}]. † Parallel composition: PjQ behaves as processes P and Q running in parallel. Each one of them may interact with the other on channels known to both, or with the outside word (environment or the end-user) independently from the other. When two processes synchronise on the same
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
265
Table 1 Syntax of process algebra P, Q
TZ j[K]$P jPjQ jPCQ P8Q jP/L def ~ ÞZ § jAðX jnil TZ j{k} jK1 g K2 TZ jY jfıg jL1 g L2 TZ jı!e jı?e jt
K, K1, K2
L, L1, L2
k
ı; Œ e
(Processes) (Sequence) (Parallel composition) (Choice) (Guarded choice) (Restriction) (Definition) (nil process) (Set of actions) (Single action) (Set union) (Set of channels) (Empty set) (Single channel) (Set union) (Action) (Send) (Receive) (Silent action) (Channel) (Arithmetic expression)
channel, the whole process will perform an action t and behaves as the remaining process. For instance, let us take the following process: § Z §1j§2 with P1 and P2 defined as follows: def
§1 Z½ı!4:§1 0 def
§2 Z½ı?x:§2 0 Then, process P performs a silent action t, indicating a synchronization between processes P1 and P2 which actually consist in the transmission of the value 4 from P1 to P2, and behaves as the remain process P 0 1jP 0 2. Semantically, we will note this transition as follows:
Fig. 1. Cell formalized as a process.
† nil process: nil is the process that cannot perform any action. 2.2. Example In this section, we show how to model a cell of memory as a process that interacts with its environment through its communication channels. As shown by Fig. 1, we consider that the cell has two ports (channels) of communication, in and out. The basic task of this cell is to infinitely wait for a value on channel in and to make it available on channel out. The same value may be output as much as necessary until a new value is imputed. We write the process cell Cx(v), meaning that the memory cell x holds the value v, as follows: def
C x ðvÞ Z½inx ?y:C x ðyÞ C ½outx !v:C x ðvÞ By capturing a memory cell as a process, we can add intelligence to it. For instance, we can write a cell that it does not allow the access to its content until it will be initialized. This smart cell can be defined as follows: def
CellðxÞ Z½inx ?y:C x ðyÞ Now, giving two processes defined as follows: def
§1 Z½inx !5:nil def
§2 Z½outx ?y:nil It is easy to write a program where these two processes communicate through a cell x:
t
§ / §1 0 j§2 0 k
§1jCellðxÞj§2
The relation / will be formally defined later within this section.
Fig. 2 shows the interaction between all the involved processes. Here are the different steps of that program execution:
† Choice: PCQ behaves as P or as Q. The choice is deterministically (made by the environment) if both P and Q do not begin with a silent action, otherwise the choice is not deterministically. † Guarded choice: P"Q is the process that behaves as P until process Q is activated. Whenever the latter is activated, the former is stopped and cleared from memory. † Restriction: P/L is the process that behaves as P except that it can communicate with the environment using channels given in L only. ~ def § is a defining equation where A is † Definition: AðXÞZ ~ are variables (parameters), and P a process identifier, X may recursively involve A.
§1jCellðxÞj§2 Z ½inx !5:nilj½inx ?y:C x ðyÞj½outx ?y:nil t
/ C x ð5Þj½outx ?y:nil Z ð½inx ?y:C x ðyÞ t
/ C x ð5Þ C ½outx !5:C x ð5ÞÞj½outx ?y:nil To sum up, during the execution of this program, the process P1 has sent the value 5 to the process P2 via
Fig. 2. Example of interacting processes.
266
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
the process Cell(x) and then finished. The memory cell, specified by the process Cell(x), holds the value 5 and is still ready to communicate it to any other process.
Table 3 Lyee requirements Word
Definition
Condition
2.3. Semantics
a c b e
bCc
« b*eO2
2*cC5
cO0
Hereafter, we give the formal semantics of the Lyeecalculus. This semantics is defined by the interaction k k relation / , where § / Q means that there is a reaction amongst the subprocesses of P such that the whole can execute the atomic action k and becomes Q. The interaction relation is inspired by the Chemical Abstract Machine [4,5]. In this model, a process is considered as a chemical solution of molecules waiting to interact. To k formally introduce the relation / , we need to define the following notions: † I is a relation that simplify processes by eliminating the nil process as follows: ð§jnilÞI §
ðnil C §ÞI §
ðnil . §ÞI §
ðnilj§ÞI §
ð§ C nilÞI §
ð§ . nilÞI §
† We denote by [[e]] the set of values containing the result of the evaluation of the expression e. If e is a variable, its evaluation will be its domain (int, real, etc.). For the sake of simplicity, we consider that all variables belong to the real set. † kX is the name of the channel used by the action k, i.e.: tX Z Y ðı!eÞX Z ðı?eÞX Z fıg k Now, we let the interaction reaction / be the least relation that satisfies the rules given by Table 2. Table 2 Semantics of Lyee-calculus k
ðR! Þ
§ / Q0 Q0 I Q k § / Q v 2EeF
ðR? Þ
ı!v ½ı!e$§ / §
v 2EeF
ðRt Þ
ı?v ½ı?e$§ / §½v=e
, t ½t$§ / §
k
ðR½ Þ
½K1 $§ / §0 K2 sY k ½K1gK2 $§ / ½K2 § 0
k / §0 l § ðRC Þ §CQ / k § 0 ı?v
0
ı!v
Q / Q0 k / Q0 §CQ 0
k
0
3. Lyee methodology This section presents an overview of how the Lyee methodology generates software from simple user requirements. Besides, through this overview we progressively introduce how one can simply and efficiently formalize this methodology using the Lyee-calculus. The complete formalization of the process of software generation of the lyee methodology will be given in Section 4.
Within the Lyee methodology, requirements are given in a declarative way as a set of statements containing words together with their definitions, their calculation conditions and their attributes (input/output, types, security attributes, etc.). Table 3 gives an example of Lyee requirements. The requirements given in that table correspond intuitively, in a traditional programming language, to the code given in Table 4. Within the Lyee methodology, the user does not need to specify the order (control logic) in which these definitions will be executed. As shown in Table 4, despite the fact that the definition of word a uses word b, statement sb is listed after the statement sa. As explained in the sequel, from these requirements, and independent of the order of statements, Lyee is able to generate code that computes all the defined words. This simple idea has, as shown in [9,10,11], multiple beneficial consequences on the different steps of software development. In fact, it allows us to begin developing software even with incomplete requirements. Moreover, the user does not need to deal with control logic as with more classical methodologies. The control logic part
§ / § .Q
Q / Q0 k §jQ / §jQ 0
sc sb
if b*eO2 then adbCc; output(a); endif input(c); if cO2 then bd2*cC5; output(b); endif input(e);
ðRZÞ
~ §½Y~ =X / §0 / §0 ~ ÞZ § ðR= Þ § k kX 2L AðX k 0 / § / §=L AðY~ Þ §=L k
«
sa
§ / § 0 Q / Q0 t §jQ / § 0 jQ 0
k / §0 §.Q
/ Q ðRr. Þ Q k / Q0 §.Q
k
ðRlj Þ
secret public public public
Code
ðRtj Þ
ı!v
int float float float
Statement
§ / § Q / Q t / Q0 §.Q ı?v
OF IS OS IS
0
k
ðRt. Þ
ðRl. Þ
Security
Table 4 Statement code
k
r ðRC Þ
Type
3.1. Lyee requirements
ðnil=LÞI nil
ðRIÞ
IO
§ / §0 k §jQ / § 0 jQ
k
ðRrj Þ
k
se
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
267
3.2. Pallets and scenario function
of the software will be, within the Lyee methodology, automatically generated reducing consequent programming errors and time. Flexibility is also a major benefit of the Lyee methodology since the maintenance task can be reduced to a simple modification of requirements (add, remove and/or modify words’ definitions). Consequently, Lyee systems can be viewed as collections of independent components (statement) that interact together in order to produce the desired result. The concepts of our process algebra sticks very well with this view since the Lyee-calculus considers a program as a chemical solution of molecules (processes) that interact together to reach the final goal. So, at a first glance, one can view a Lyee requirement LR composed of a set of statements {s1,.,sn} as a concurrent processes of the Lyee-calculus, i.e.:
From the requirements in Table 3, we can automatically generate a program that computes the values of a and b and outputs them. This program will simply repeat the execution of these instructions until a fixed point is reached, i.e. any other iteration will not change the value of any word as shown in Fig. 3. Let us be more precise about the structure and the content of the program that will be automatically generated by Lyee from requirements. Within the Lyee methodology, the execution of a set of statements, such as the ones given in Table 3, is accomplished in a particular manner. In fact, Lyee distributes the code associated with statements over three spaces, called Pallets (W02, W03 and W04) in the Lyee terminology, as shown in Fig. 4. Pallet W02 deals with the input words. Pallet W03 computes the calculation conditions of the words and saves the results in boolean variables. For instance, the condition ‘b*eO2’ used within the definition of the word ‘a’ is calculated in W03 and the true/false result is saved in another variable ‘a_cond’. Finally, pallet W04 deals with the calculation of the words according to their definition given within the requirements. It also outputs the values of the computed words. More precisely, the lyee pallets contains a simple program with a fixed structure (called a Predicate Vector in the Lyee terminology) that makes the structure of generated code uniform and independent of the requirement content. The global program will be simple calls of predicate vectors. The structure of a predicate vector is as shown in Fig. 5.
LR Z s1 j /jsn
† The L4 vector deals with the computation of a given word (variable). Each word in the specification has its own
Fig. 3. Requirement execution.
Fig. 4. Lyee pallets.
268
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
† The O2 vector deals with input from the outside (screen, file networks, etc.) of the program. The imputed values will be stored in a temporary area and then will be transferred to their final memory area by L2. There is only one O2 vector for all the input words. † The L3 vector deals with the computation of the condition associated to a given word (variable). Each word in the specification has its own L3 vector. Fig. 7 shows the L3 vectors associated with the calculation of the word ‘a’ and the word ‘b’. † Fig. 8 sketch the role of each vector. † Follows that the content of each pallet will be as shown by Fig. 9. † Finally, the Lyee program associated with the requirements given in Table 3 is as shown in Table 5. † Notice that the whole process (W04/W02/W03) will repeat until a situation of overall stability is reached. The three pallets (W04,W03,W02) linked together are called Scenario Function in the Lyee terminology.
Fig. 5. Predicate Vector.
L4 vector. Fig. 6 shows the L4 vectors associated with the calculation of the word ‘a’ and the word ‘b’. † The O4 vector deals with output. Once the computation of a given output word has finished, this vector will output the value of this word in the appropriate place (screen, file, networks, etc.). There is only one O4 vector for all the output words. † The L2 vector transfers the value of an input word to the appropriate memory area. Each input word in the specification has its own L2 vector.
As we can see in Table 5, besides the basic vectors (L4,L3,L2,O4,I2,S4), the Lyee methodology adds new vectors (R2,R3,R4, etc.), supplementary memories (finish and restart flags in the basic structure) and other treatments to resolve the following problems: † In which order the vectors will be computed? † What to do if we try to compute a vector that cannot be computed due to some missing values? † When the fixed point is reached ? (fixed point control) The presence of the additional introduced treatment was forced by the use a sequential language to implement a Lyee requirement. A more appropriate language for
Fig. 6. The predicate vectors of L4,a and L4,b.
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
269
Fig. 7. The predicate vectors of L3,a and L3,b.
Fig. 8. Relation between statements and vectors.
the Lyee-methodology is the one who is able, without giving it any supplementary instruction, to stop when a fixed point is reached and to run the appropriate vector in the appropriate time, i.e.:
† Knows the vectors that are ready to produce their results and executes one of them. † Puts the vectors that have some missing arguments in a standby state.
Fig. 9. Relation between pallets and vectors.
270
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
Table 5 Lyee generated program Pallet
Program
Comments
W04
Call S4 Do Call L4_a Call L4_b while a fixed point is not reached Call O4 Call R4 Do Call L2_e Call L2_c while a fixed point is not reached Call I2 Call R2 Do Call L3_a Call L3_b while a fixed point is not reached Call R3
Initialize memory
W02
W03
Calculate a Calculate b Output the result Go to W02
Input results Go to W03
managed by our abstract machine. Consequently, a Scenario Function could be formalized as follows: SF Z W04 jW03 jW02 Stop when a fixed point is reached. From our process algebra view point, the notion of ‘reaching of a fixed point’ is naturally implemented within the semantics. In fact, the processes (molecules) interact together until a state of no possible evolution (fix point) is reached. Within the memory cell example (page 5), the reaction between molecules is as following: † Initially, we have a chemical solution containing the following processes:
Calculate a_cond Calculate b_cond Go to W04
Hereafter, we give some arguments that show how our processes algebra is suitable to support the concepts of the Lyee-methodology. Select the appropriate vector in the appropriate time. Using our process algebra, we can simplify the Lyee generated program by eliminating the additional introduced treatments. In fact, within this process algebra, all the arguments of a vector will be received on named channel using synchronous communication. Therefore, all the vectors that miss some arguments in order to be computed will be automatically butted in a standby state. Besides, if there are many vectors which are ready to be computed, then the process algebra will arbitrarily choose one of them and run it. Consequently, the program associated to the following statements
† The first reaction will be between the process P1 and the process Cell according to the rule: ı?v
ðRtj Þ
ı!v
§ / § 0 Q / Q0 t
§jQ / § 0 jQ 0
will look as following
Therefore, using the Lyee-calculus, we do not need any more to specify the order according to which the pallets will be executed, the order according to which the vectors of each pallet will be executed, how and when to pass control from one pallet to another, etc. All this detail will be naturally
† The result of the first reaction is the following chemical solution: niljC x ð5Þj§2
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
271
† The previous chemical solution has reached a fixed point since no rule can makes it to move to another different solution. Now, using the Lyee-calculus, W04, W03 and W02 can be specified as follows: W04 Z S4jL4_ajL4_bjO4 W03 Z L3_ajL3_b W02 Z L2_ejL2_cjI2 The formal definition of the different vectors (L2, L3, L4, S4, etc.) will be given in Section 4. † The second interaction is between the process P2 and the process Cell according to the rule: ı?v
ðRtj Þ
ı!v
3.3. Process route diagrams
§ / § 0 Q / Q0 t
§jQ / § 0 jQ 0
† The result of the second reaction is the following chemical solution: niljCx ð5Þjnil
The Scenario Function presented in Section 3.2 can be a complete program for a simple case of given requirements, particularly when all the input and output words belong to the same screen and there is no use of any database. However, if we need to input and output words that belong to databases or to different screens interconnected together, then the situation will be more complicated. For the sake of simplicity, we deal, in the sequel, only with the case when we have many screens. Suppose for instance that we have three interconnected screens, as shown in Fig. 10, allowing a user to navigate from one to another. Suppose in each one of them the user can input, compute and output some words. Therefore, in the specification, the user must specify how these screens are interconnected. Furthermore, it is not convenient to define only one scenario function in which we compute all the words defined in all the screens. In fact, some screens may not be visited for a given execution of the program and then the computation of the value of their words will be lost. For that reason, Lyee associates with each screen its owner scenario function that will be executed only if this screen is visited. The scenario functions associated with screens are connected together showing the move from one of them to another. In the Lyee terminology, many scenario functions connected together make up a Process Route Diagram as shown in Fig. 11. Using the Lyee-calculus, we can formalize a screen sk as a process F(sk) that control the execution of the process SF(sk). Actually, the process SF(sk) will be executed until it corresponding screen is reactivated (receiving a signal on the channel ısk associated to the screen sk) and then will be killed to create a new fresh instance of SF(sk). This is formalized as follows: Fðsk Þ Z SFðsk Þ . ½ısk ?1:Fðsk Þ Notice that a concrete example will be given later in this paper to show how the function F(sk) works.
272
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
Fig. 10. Screen interactions.
The function J is defined as follows:
3.4. Lyee program To summarize, according to the Lyee methodology, a Lyee program contains several processes route diagrams (PRD). Each of them is a set of interconnected scenario functions (SF). Each scenario function contains three interconnected pallets W02, W03 and W04. Finally, pallets contain atomic vectors (signification vectors and action vectors). Using the Lyee-calculus, a Lyee program § containing the screens s1,.,sk, is formalized as follows: §ðs1 ; .; sk Þ Z Jðs1 ; .; sk Þ=Lðs1 ; .; sk Þ where Lðs1 ; .; sk Þ is the set of input and output channels. This restricts Jðs1 ; .; sk Þ to communicate with the environment only on channels in Lðs1 ; .; sk Þ.
Jðs1 ; .; sk Þ Z ðjs2fs1 ;.;sk g ½ıs ?1:FðsÞÞ . ½ıs0 ?1:nil This function activates the SF of a screen sk(F(sk)) whenever a true value is received on the corresponding channel ısk , which formalizes a button or a menu item that a user may use to activate the corresponding screen, and kill all the processes when it receives a true value on channel ıs0 , which formalizes the Exit button (or a corresponding menu item). Consequently, a Lyee system can be viewed as a collection of independent concurrent processes that communicate with each other to compute the desired output words. In contrast with conventional sequential view of Lyee methodology, there are no need for various action vectors and control functions, no need of working memory
Fig. 11. Processes route diagram.
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
areas, etc. More details about the function Jðs1 ; .; sk Þ together with concrete examples will be given in the sequel. Section 4 gives a more detailed and complete formalization of the Lyee methodology.
nil Output vector O4(x)Z ½ıx4 ?x: [dx!x].
4. Formalization of the Lyee methodology Let Use(e) denote the set of words used in the expression e. For instance, Use(a*bC1)Z{a,b}. Also, let FðSÞ be the following function:
Fðfxgg AÞ Z fıx4 ?xgg FðAÞ Now let us see how to automatically generate software from simple user requirement using the Lyee-calculus. Suppose that the user requirement contains k screens {s1,.,sk}. Suppose also that each screen contains a set of statements where each one of them has the following form: (w, e, c, InOut, type) where w is a word, e its definition, c its condition, InOut to specify if it is an input, an output both or neither input nor output (the value i is used to specify an input word, o to specify an output, io to specify both input and output and empty filed to specify for neither input nor output) and type is its type (the type B is reserved for button). To define the program §ðs1 ; .; sk Þ associated with this requirement, we need to formalize the following vectors (processes): Significant vectors L4(x, e)Z ½ıx3 ?1: ½FðUseðeÞÞ: ½Œ x4 !e: nil L3(x, c)Z ½FðUseðcÞÞ: ½ıx3 !c: nil L2(x)Z ½ıx2 ?x: ½Œ x4 !x: nil
½ıx2 !x:
Routing vector R3(b, e, s)Z [db?click]. ½FðUseðeÞÞ: ½ıs !e: nil
Finish Comments Wait to receive the value of x from the memory Send the value of x on the channel dx Finish Comments Wait to receive any value (initialization) and then behave as Sx4 ðyÞ If you receive z behaves as Sx4 ðzÞ (change the content of the cell x) If you send y behave as Sx4 ðyÞ (do not change the content of the cell x) Comments Wait until the button b be pushed Evaluate the condition of the button Send the result to the screen s (i.e. activate s if eZ1) Finish
Pallet. The three pallets W02, W03 and W04 of a given screen s are formalized as follows: W02 ðsÞ Z jðw; * ; * ;ı;BÞ2s I2 ðwÞjðw; * ; * ;ı;BÞ2s L2 ðwÞ L3 ðw; cÞjðw;e;c;ı; * ;BÞ2s R3 ðw; c; eÞ W03 ðsÞ Z jðw; * ;c; * ;BÞ2s W04 ðsÞ Z jðw; * ; * ; * ;BÞ2s S4 ðwÞjðw;e; * ; * ;BÞ2s
Comments
!L4 ðw; eÞÞjðw; * ; * ;o; * ; * Þ2s O4 ðwÞ ıx3
wait to receive the value true (1) on the channel (from L3) wait to receive the value of all the Use of e from the memory evaluate e and put the result in the memory cell of x finish
where B denotes any type except B (complementary of B) and * denotes anything. Scenario Function. The scenario function, it SF(s), attached to the screen s is formalized as follows:
wait to receive the value of all the Use of c from the memory evaluate c and send the result of the channel ıx3 (to L4) finish
Control Function. The control function attached to a screen s, is formalized as follows:
wait to receive the value x on the channel ıx2 (from the input vector) save the value of x in the memory cell of x finish
The control function attached to a set of screens is formalized as follows:
Action vectors Input vector I2(x)Z [dx?x].
Sx4 ðyÞZ ½Œ x4 ?z$Sx4 ðzÞC ½ıx4 !y:Sx4 ðyÞ
FðYÞ Z Y
Vector
nil Memory (structural vector) S4 ðxÞZ ½Œ x4 ?y$Sx4 ðyÞ
273
Comments Wait to receive the value on the channel dx Send the value of x on the channel ıx2 (to L2)
SFðsÞ Z W04 ðsÞjW03 ðsÞjW02 ðsÞ
FðsÞ Z SFðsÞ . ½ısk ?1:FðsÞ
Jðs1 ; .; sk Þ Z ðjs2fs1 ;.;sk g ½ıs ?1:FðsÞÞ . ½ıs0 ?1:nil We suppose that s0 is the screen that we find when we exit the program (exit screen that does not belongs to the screens of the program itself). Lyee Program. Finally, the Lyee program §ðs1 ; .; sk Þ associated with the requirement containing the screens s1,.,sk is as follows §ðs1 ; .; sk Þ Z Jðs1 ; .; sk Þ=Lðs1 ; .; sk Þ
274
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
where the set Lðs1 ; .; sk Þ contains all the input and output channels and it is defined as follows: Lðs1 ; .; sk Þ Z g fdw g g fıs1 g ðw; * ; * ;ı=o; * Þ2sk
The meaning of i/o is that this field has to contains the value i, o or io. We suppose also that s1 is the first screen that appears when the user runs this program. Fig. 12. Case study-one screen.
5. Case study In this section, we give some concrete examples and we describe step by step how a Lyee program progress in order to compute words within our Lyee-calculus.
W03(s1)ZL3(b, aO0)jR3(B0, click, s0) L3 ðb; aO 0ÞZ ½ıa4 ?a: ½ıb3 !ðaO 0Þ: nil
R3(B0, click, s0)Z[dB0?click]. ½ıs0 !1: nil
5.1. One-screen example W04(s1)ZS4(a)jS4(b)jL4(b, 2*a)jO4(b)
The example that we present hereafter contains only one screen. As shown by the requirement given in Table 6, a user can input a word a, waits for the value of b and then exit the screen by pushing the button B0. Fig. 12 illustrates such a screen. This screen s1 is composed from three statements:
S4 ðaÞZ ½Œ a4 ?a: Sa4 ðaÞ S4 ðbÞZ ½Œ b4 ?b: Sb4 ðbÞ
L4 ðb; 2 aÞZ ½ıb3 ?1: ½ıa4 ?a: ½Œ b4 !ð2 aÞ: nil
O4 ðbÞZ ½ıb4 ?b: [db!b] nil
According to the definition of a generic Lyee program given in Section 3, the Lyee program associated to the requirement given by Table 6 is as follows:
Suppose now, that the end-user (environment) of this program wants to perform the following sequence of actions: runs the program (activates the screen s1), gives the value 7 to the word a, waits for the value of the word b and then exits the program by pushing the button B0. This comportement can be captured by the following process E:
SFðs1 Þ Z W04 ðs1 ÞjW03 ðs1 ÞjW02 ðs1 Þ
Process
s1 Z fða; ; ; i; realÞ; ðb; 2 * a; aO 0; o; realÞ; ðB0 ; s0 ; Click; BÞg
s1
EZ ½ı !1$E1 E1 Z ½da !7$E2 E2 Z ½db ?x$E3 E3 Z ½dB0 !click:nil
Fðs1 Þ Z SFðs1 Þ . ½ıs1 ?1:Fðs1 Þ Jðs1 Þ Z ð½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nil Lðs1 Þ Z fda ; db ; dB0 ; ıs1 g §ðs1 Þ Z Jðs1 Þ=Lðs1 Þ where W02(s1), W03(s1) and W04(s1) are as shown hereafter: W02(s1)ZL2(a)jI2(a) L2 ðaÞZ ½ıa2 ?a: ½Œ a4 !a: nil
I2(a)Z[da?a]. ½ıa2 ?a: nil
Table 6 Lyee requirements: screen I Word
Definition
Condition
a b B0
2*a s0
aO0 iClick
IO
Type
I o
real real B
Comments activate the program (screen s1) give the value 7 to the word a give the value of the word b click the button B0 to exit
Let us see now how the program interact with this environment to reach the desire goal. In other words, we want to have a trace of the program progress when executed in parallel with the program E that implements the end-user actions, i.e. we look for the behaviors of §ðs1 ÞjE. The steps of this trace is as shown hereafter: §ðs1 ÞjE Z hBy definition of § and Ei Jðs1 Þ=Lðs1 Þj½ıs1 !1:E1 Z hBy definition of Ji ðð½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 Þj½ıs1 !1:E1 t / hSynchronization—End-user activates the program by running the screen s1i ðFðs1 Þ . ½ıs0 ?1:nilÞ=Lðs1 ÞjE1 Z hBy definition of F and E1 i ððSFðs1 Þ . j½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 Þj½da !7:E2 Z hBy definition of SFi ðððW04 ðs1 ÞjW02 ðs1 ÞjW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ = Lðs1 Þj½da !7:E2
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
Z hBy definition of W02 and consequently I2i ðððW04 ðs1 ÞjL2 ðaÞjð½da ?a:½ıa2 !a:nilÞjW03 ðs1 ÞÞ . /Þ . /Þ= Lðs1 Þj½da !7:E2 t / hSynchronization—Through I2 end-user gives the value 7 to the word ai ðððW04 ðs1 ÞjL2 ðaÞjð½ıa2 !7:nilÞjW03 ðs1 ÞÞ . /Þ . /Þ=Lðs1 ÞjE2 Z hBy definition of L2i ðððW04 ðs1 Þjð ½ıa2 ?a:½Œ a4 !a:nilÞjð½ıa2 !7:nilÞjW03 ðs1 ÞÞ . /Þ . /Þ= Lðs1 ÞjE2 t / hSynchronization—The value of a is communicated to L2(a)i ðððW04 ðs1 Þj𽌠a4 !7:nilÞjW03 ðs1 ÞÞ . /Þ . /Þ=Lðs1 ÞjE2 Z hBy definition of W04i ððS4 ðaÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞj𽌠a4 !7:nilÞjW03 ðs1 ÞÞ ./Þ=Lðs1 ÞjE2 Z hBy definition of S4(a)i ðð𽌠a4 ?a:Sa4 ðaÞÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞj𽌠a4 !7:nilÞ jW03 ðs1 ÞÞ . / t / hSynchronization—The value of a is stored in the memoryi ððSa4 ð7ÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞjW03 ðs1 ÞÞ . / Z hBy definition of Sa4 ð7Þ and W03i ðð𽌠a4 ?z:Sa4 ðzÞC ½ıa4 !7:Sa4 ð7ÞÞj /jðL3 ðb; aO 0Þ jR3 ðB0 ; click; s0 ÞÞÞ . / Z hBy definition of L3i ðð𽌠a4 ?z:Sa4 ðzÞC ½ıa4 !7:Sa4 ð7ÞÞj /jðð½ıa4 ?a: ½ıb3 !ðaO 0Þ:nilÞj/ t / hSynchronization—The value of a is communicated to L3(b) to compute the b conditioni ððSa4 ð7ÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞjð½ıb3 !ð7O 0Þ:nilÞj/ Z hBy definition of L4 and evaluation of (7O0)i ððSa4 ð7ÞjS4 ðbÞjð½ıb3 ?1:½ıa4 ?a:½Œ b4 !ð2 * aÞ:nilÞjO4 ðbÞj ð½ıb3 !1:nilÞj/ t
/ hSynchronization—The b condition is evaluated and communicated to L4(b) to activate the computation of bi ððSa4 ð7ÞjS4 ðbÞjð½ıa4 ?a:½Œ b4 !ð2 * aÞ:nilÞjO4 ðbÞj/ Z hBy definition of Sa4 ð7Þi ðð𽌠a4 ?z:Sa4 ðzÞC ½ıa4 !7:Sa4 ð7ÞÞjS4 ðbÞjð½ıa4 ?a:½Œ b4 !ð2 * aÞ:nilÞ jO4 ðbÞj / t
/ hSynchronization—The value of a is communicated to L4i ððSa4 ð7ÞjS4 ðbÞj𽌠b4 !ð2 * 7Þ:nilÞjO4 ðbÞjR3 ðB0 ; click; s0 ÞÞ . / Z hBy definition of S4(b) and evaluation of (2*7)i ððSa4 ð7Þj𽌠b4 ?b:Sb4 ðbÞÞj𽌠b4 !ð14Þ:nilÞjO4 ðbÞj R3 ðB0 ; click; s0 ÞÞ . / t / hSynchronization—The value of b (14) is stored in the memoryi ððSa4 ð7ÞjSb4 ð14ÞjO4 ðbÞjR3 ðB0 ; click; s0 ÞÞ . / Z hBy definition of Sb4 and O4(b)i ððSa4 ð7Þj𽌠b4 ?z:Sb4 ðzÞC ½ıb4 !14:Sb4 ð14ÞÞjð½ıb4 ?b:½db !b:nilÞj R3 ðB0 ; click; s0 ÞÞ . / t / hSynchronization—The b value is communicated to O4i
275
ððSa4 ð7ÞjSb4 ð14Þjð½db !14:nilÞjR3 ðB0 ; click; s0 ÞÞ . /Þ= Lðs1 ÞjE2 Z hBy definition of E2 i ððSa4 ð7ÞjSb4 ð14Þjð½db !14:nilÞjR3 ðB0 ; click; s0 ÞÞ . /Þ= Lðs1 Þj½db ?x:E3 t / hSynchronization—The b value, stored in O4, is communicated to the environmenti ððSa4 ð7ÞjSb4 ð14ÞjR3 ðB0 ; click; s0 ÞÞ . /Þ=Lðs1 ÞjE3 Z hBy definition of R3 and E3 i ððSa4 ð7ÞjSb4 ð14Þjð½dB0 ?click:½ıs0 !1:nilÞÞ . .Þ=Lðs1 Þ j½dB0 !click:nil t / hSynchronization—The end-user push button B0 to exiti ððSa4 ð7ÞjSb4 ð14Þjð½ıs0 !1:nilÞÞ . ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ= Lðs1 Þ t / hSynchronization—The system ends its executioni nil To summarize, here are the main steps of the program progress: 1. End-user activates the program by running the screen s1. ðð½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 Þj½ıs1 !1:E1 2. Through I2(a), end-user gives the value 7 to the word a. ðððW04 ðs1 ÞjL2 ðaÞjð½da ?a:½ıa2 !a:nilÞjW03 ðs1 ÞÞ . /Þ . /Þ= Lðs1 Þj½da !7:E2 3. The value of a is communicated to L2(a). ðððW04 ðs1 Þjð½ıa2 ?a:½Œ a4 !a:nilÞjð½ıa2 !7:nilÞj W03 ðs1 ÞÞ./Þ./Þ=Lðs1 ÞjE2 4. The value of a is stored in the memory, i.e. in S4(a). ðð𽌠a4 ?a:Sa4 ðaÞÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞj𽌠a4 !7:nilÞj W03 ðs1 ÞÞ . / 5. The value of a is communicated to L3(b) to compute the b condition. ðð𽌠a4 ?z:Sa4 ðzÞC½ıa4 !7:Sa4 ð7ÞÞj/j ðð½ıa4 ?a:½ıb3 !ðaO0Þ:nilÞj/ 6. The b condition is evaluated and communicated to L4(b). ððSa4 ð7ÞjS4 ðbÞjð½ıb3 ?1:½ıa4 ?a:½Œ b4 !ð2 * aÞ:nilÞjO4 ðbÞj ð½ıb3 !1:nilÞj/ 7. The value of a is communicated, from memory, to L4(b). ðð𽌠a4 ?z:Sa4 ðzÞ C ½ıa4 !7:Sa4 ð7ÞÞjS4 ðbÞjð½ıa4 ?a: ½Œ b4 !ð2 * aÞ:nilÞjO4 ðbÞj/
276
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281 Table 7 Lyee requirements: screen I Word
Definition
Condition
a b B2
2*a s2
aO0 click
IO
/
IS
/ / /
where §1 ðs1 Þ Z ðFðs1 Þ . ½ıs0 ?1:nilÞ=Lðs1 Þ is justified by the following proof:
Fig. 13. Interaction between processes.
8. The value of b is stored in the memory, i.e. in S4(b). ððSa4 ð7Þj𽌠b4 ?b:Sb4 ðbÞÞj𽌠b4 !ð14Þ:nilÞjO4 ðbÞj R3 ðB0 ; click; s0 ÞÞ . / 9. The b value is communicated to the output vector O4(b). ððSa4 ð7Þj𽌠b4 ?z:Sb4 ðzÞ C ½ıb4 !14:Sb4 ð14ÞÞjð½ıb4 ?b:½db !b:nilÞj R3 ðB0 ; click; s0 ÞÞ . / 10. The b value, stored in O4, is communicated to the environment. ððSa4 ð7ÞjSb4 ð14Þjð½db !14:nilÞjR3 ðB0 ; click; s0 ÞÞ . /Þ= Lðs1 Þj½db ?x:E3 11. The end-user push button B0 to exit. ððSa4 ð7ÞjSb4 ð14Þjð½dB0 ?click:½ıs0 !1:nilÞÞ . /Þ= Lðs1 Þj½dB0 !click:nil Fig. 13 illustrates each of these steps. Furthermore, each transition could be validated by a proof. For instance, the transition
In Appendix, we report more proofs related to the program execution. 5.2. Two screen example The idea behind this example is to show the interaction between many screens (Fig. 14). According to the definition of a generic Lyee program given in Section 4, the Lyee program associated to the requirement given by Tables 7 and 8 is as follows: SFðs1 Þ Z W04 ðs1 ÞjW03 ðs1 ÞjW02 ðs1 Þ SFðs2 Þ Z W04 ðs1 ÞjW03 ðs1 Þ Notice that there is no W02 for the screen s2 since it does not contain input words other than buttons Fðs1 Þ Z SFðs1 Þ . ½ıs1 ?1:Fðs1 Þ Fðs2 Þ Z SFðs2 Þ . ½ıs2 ?1:Fðs2 Þ Jðs1 ; s2 Þ Z ð½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nil Lðs1 ; s2 Þ Z fda ; db ; de ; dB0 ; dB2 g §ðs1 ; s2 Þ Z Jðs1 ; s2 Þ=Lðs1 ; s2 Þ
t
ð§ðs1 ÞjEÞ / ð§1 ðs1 ÞjE1 Þ
where W02(s1)ZL2(a)jI2(a) L2 ðaÞZ ½ıa2 ?a: ½ıa4 !a: nil
I2(a)Z[da?a]. ½ıa2 !a: nil
Table 8 Lyee requirements: screen II
Fig. 14. Case study—two screen.
Word
Definition
Condition
IO
/
e B0
1Cb s0
bO0 Click
OS
/ /
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
W03(s1)ZL3(b, aO0)jR3(B2, click, s2) L3 ðb; aO 0ÞZ ½ıa4 ?a: ½ıb3 !ðaO 0Þ: nil W03(s2)ZL3(e, bO0)jR3(B0, click, s0) L3 ðe; bO 0ÞZ ½ıb4 ?b: ½ıe3 !ðbO 0Þ: nil
R3 ðB2 ; click; s2 ÞZ ½dB2 ?click: ½ıs2 !1: nil R3 ðB0 ; click; s0 ÞZ ½dB0 ?click: ½ıs0 !1: nil
W04(s1)ZS4(a)jS4(b)jL4(b, 2*a)jO4(b) S4 ðaÞZ ½Œ a4 ?a: L4 ðb; 2 aÞZ ½ıb3 !1: Sa4 ðyÞ ½ıa4 ?a: b S4 ðbÞZ ½Œ 4 ?b: ½Œ b4 !ð2 aÞ: b nil S4 ðyÞ W04(s2)ZS4(e)jL4(e, 1Cb)jO4(e) L4 ðe; 1C bÞZ ½ıe3 !1: e S4 ðeÞZ ½Œ 4 ?e: ½ıb4 ?b: Se4 ðyÞ ½Œ e4 !ð1C bÞ: nil
277
in two steps. First the value of a is communicated to L2(a) and second L2(a) will communicate this value to the memory. The first step is as follows: t
§2 ðs1 ; s2 ÞjE2 / §3 ðs1 ; s2 ÞjE2 where §3 ðs1 ; s2 Þ Z ðððW04 ðs1 Þj½Œ a4 !7:niljW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ
O4 ðbÞZ ½ıb4 ?b: [db!b]. nil
. ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ In the second, the value of a will be stored in the memory of W04 t
O4 ðeÞZ ½ıe4 ?e: [db!e]. nil
s1 Z fða; ; ; i; sÞ; ðb; 2 a; aO 0; o; sÞg Suppose now, that the end-user (environment) of this program wants to perform the following sequence of actions: runs the program (activates the screen s1), gives the value 7 to the word a, waits for the value of the word b, pushes the button B2 to go to the screen s2, waits for the value e and then exits the program by pushing the button B0. This comportement can be captured by the following process E:
§3 ðs1 ; s2 ÞjE2 / §4 ðs1 ; s2 ÞjE2 where §4 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞjW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 4. The value of a is communicated to L3(b) to compute the b condition: t
End-user action
Comments
EZ ½ıs1 !1:E1 E1 Z ½da !7:E2 E2 Z ½db ?b:E3 E3 Z ½ıB2 !click:E4 E4 Z ½de ?e:E5 E5 Z ½ıB0 !click:nil
Activate the program Give the value 7 to a word a Wait for the value of the word b Pushes the button B2 to go screen 2 Wait for the value of the word e Push the button B0 to exit
/ §5 ðs1 ; s2 ÞjE2 §4 ðs1 ; s2 ÞjE2 where §5 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞj !½ıb3 !ð7O 0Þ:niljR3 ðB2 ; s2 ; clickÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ
1. End-user activates the program by running the screen s1: t
/ §1 ðs1 ; s2 ÞjE1 §ðs1 ; s2 ÞjE where §1 ðs1 ; s2 Þ Z ðFðs1 Þj½ıs2 ?1:Fðs2 Þ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 2. The end-user gives the value 7 to the word a. t
§1 ðs1 ; s2 ÞjE1 / §2 ðs1 ; s2 ÞjE2 where §2 ðs1 ; s2 Þ Z ððððW04 ðs1 Þj½ıa2 !7:niljL2 ðaÞjW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 3. The value of a is stored in the memory: this will be done
5. The b condition is evaluated and communicated to L4(b) to activate the computation of b: t
§5 ðs1 ; s2 ÞjE2 / §6 ðs1 ; s2 ÞjE2 where §6 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjS4 ðbÞj½Œ a4 !ð2 * aÞ:nilj O4 ðbÞjR3 ðB2 ; s2 ; clickÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 6. The b value is computed and communicated to S4(b), the memory area of b: t
§6 ðs1 ; s2 ÞjE2 / §7 ðs1 ; s2 ÞjE2
278
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
where
where
§7 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞjO4 ðbÞÞ
§12 ðs1 ;s2 ÞZðððSa4 ð7ÞjSb4 ð14ÞÞ
. ½ıs1 ?1:niljR3 ðB2 ; s2 ; clickÞÞ
.½ıs1 ?1:Fðs1 ÞjðSe4 ð15ÞjO4 ðeÞ
. ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ
!jR3 ðB0 ;s0 ;clickÞÞ
. ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ
.½ıs1 ?1:Fðs1 ÞÞ.½ıs0 ?1:nilÞ=Lðs1 ;s2 Þ 12. Output the value of e:
7. The b value is outputted, i.e. communicated to the environment (end-user): t
§7 ðs1 ; s2 ÞjE2 / §8 ðs1 ; s2 ÞjE3
t
/ §12 ðs1 ; s2 ÞjE5 §11 ðs1 ; s2 ÞjE3 where §12 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞÞ
where
. ½ıs1 ?1:Fðs1 ÞjðSe4 ð15ÞjR3 ðB0 ; s0 ; clickÞÞ
§8 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞjR3 ðB2 ; s2 ; clickÞÞ . ½ıs1 ?1:Fðs1 Þj½ıs2 ?1:Fðs2 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 8. The end-user push B2 to go to screen 2: t
/ §9 ðs1 ; s2 ÞjE4 §8 ðs1 ; s2 ÞjE3
. ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 13. The end-user pushes B0 to exit the program: t
§12 ðs1 ; s2 ÞjE5 / ðððSa4 ð7ÞjSb4 ð14ÞÞ . ½ıs1 ?1:Fðs1 ÞjðSe4 ð15Þj½ıs0 ?1:nilÞ . ½ıs1 ?1:Fðs1 ÞÞ t
/ nil . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ
where §9 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞÞj½ıs1 ?1:Fðs1 ÞjFðs2 ÞÞj !½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 9. Get the value of b from the memory to compute the condition of e: t
§9 ðs1 ; s2 ÞjE3 / §10 ðs1 ; s2 ÞjE4 where §10 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞÞ . ½ıs1 ?1:Fðs1 ÞjðW04 ðs2 Þj !½ıe3 ð14O 0Þ:niljR3 ðB0 ; s0 ; clickÞÞ . ½ıs1 ?1:Fðs1 ÞÞj½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 10. Compute the value of e: t
§10 ðs1 ; s2 ÞjE3 / §11 ðs1 ; s2 ÞjE4 where §11 ðs1 ; s2 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞÞ . ½ıs1 ?1:Fðs1 ÞjðS4 ðeÞj !½Œ e4 ð1 C 14Þ:niljO4 ðeÞjR3 ðB0 ; s0 ; clickÞÞj !½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ; s2 Þ 11. Store the value of e in the memory t
§11 ðs1 ; s2 ÞjE3 / §12 ðs1 ; s2 ÞjE4
6. Conclusion In this paper, we have first defined a formal process algebra, called Lyee-calculus, that easily and naturally supports the basic concepts of the Lyee methodology. In fact, this calculus can be seen as an abstract machine which is more suitable to support the Lyee methodology concepts than the Von Newman one. This machine considers a program as a set of molecules that interact together to produce a final result. Secondly, we have shown how this calculus can formalize and simplify both the lyee vectors together with the whole software generation process. Actually, synchronization vector, most of the routing vectors, command vector, etc. are no longer needed. We have also formalized the whole process of the automatic generation of Lyee software generation. This formalization offers to this methodology a formal semantics that allows one to clearly understand the concepts behind this methodology. Besides, this formal description will be an inevitable start point for many interesting analysis on diverse aspects of this methodology. For instance, to optimize the Lyee generated software or the software generation processes, we need a formal proof that the optimized program is equivalent to its original version. Formal equivalence checking or more generally model checking can be elegantly achieved when using process algebra. As future work, we want to investigate more the semantics of Lyee methodology in order to make it more simple and to generate, from requirements, more reliable and optimized
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
code. For the optimization end, we intend to define a congruence relation between processes of Lyee-calculus and then using it to prove the correctness of all the eventual optimizations.
279
where §2 ðs1 Þ Z ðððW04 ðs1 Þj½ıa2 !7:niljL2 ðaÞjW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ |fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} §12 ðs1 Þ
. ½ıs0 ?1:nilÞ=Lðs1 Þ Proof. §11 ðs1 Þ zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl}|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{ §1 ðs1 Þ Z ðFðs1 Þ . ½ıs0 ?1:nilÞ=Lðs1 Þ Z ðððW04 ðs1 Þ j ½da ?a:½ıa2 !a:nil j L2 ðaÞ j W03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ |fflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflffl} I2 ðaÞ
. ½ıs0 ?1:nilÞ=Lðs1 Þ First let us prove that:
Appendix Hereafter, we give more proof concerning the requirement
§2 ðs1 Þ
da ?7
/
§3 ðs1 Þ
Now, we deduce that:
given by Table 6 (page 20). 1. End-user activates the program by running the screen s1: t
3. The value of a is stored in the memory: this will be done in two steps. First the value of a is communicated to L2(a) and second L2(a) will communicate this value to the memory. The first step is as follows:
/ ð§1 ðs1 ÞjE1 Þ ð§ðs1 ÞjEÞ
t
§2 ðs1 ÞjE2 / §3 ðs1 ÞjE2
where §1 ðs1 Þ Z ðFðs1 Þ . ½ıs0 ?1:nilÞ=Lðs1 Þ
where
Proof.
§3 ðs1 Þ ZðððW04 ðs1 Þj½Œ a4 !7:niljW03 ðs1 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ |fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} 12½½1 ıs1 ?1 s 1 ½ı ?1:Fðs1 Þ / Fðs1 Þ l R. : ıs1 ?1 Jðs1 Þ / Fðs1 Þ . ½ıs0 ?1:nil R! : 12½½1 ıs1 ?1 ıs1 !1 E §ðs1 Þ / §1 ðs1 Þ / E1 t ð§ðs1 ÞjEÞ / ð§1 ðs1 ÞjE1 Þ R? :
R= : Rtj
:
§13 ðs1 Þ
. ½ıs0 ?1:nilÞ=Lðs1 Þ Proof. We have: §2 ðs1 ÞZððððW04 ðs1 Þj½ıa2 !7:niljL2 ðaÞjW03 ðs1 ÞÞ.½ıs1 ?1:Fðs1 ÞÞ |fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} §12 ðs1 Þ
2. The end-user gives the value 7 to the word a. t
ð§1 ðs1 ÞjE1 Þ / ð§2 ðs1 ÞjE2 Þ
.½ıs0 ?1:nilÞ=Lðs1 Þ
280
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
Then:
It follows that
Second, let us show how the value of a will be stored in the memory of W04. In other words, we want to prove that:
5. The b condition is evaluated and communicated to L4(b) to activate the computation of b:
t
§3 ðs1 ÞjE2 / §4 ðs1 ÞjE2
t
§5 ðs1 ÞjE2 / §6 ðs1 ÞjE2
where
where
§4 ðs1 ÞZðððSa4 ð7ÞjS4 ðbÞjL4 ðb;2*aÞjO4 ðbÞjW03 ðs1 ÞÞ.½ıs1 ?1:Fðs1 ÞÞ
|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl}
§6 ðs1 Þ Z ðððSa4 ð7ÞjS4 ðbÞj½Œ a4 !ð2 * aÞ:niljO4 ðbÞ
§14 ðs1 Þ
!jR3 ðB0 ; click; s0 ÞÞ
.½ıs0 ?1:nilÞ=Lðs1 Þ
. ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 Þ
We have:
It follows that:
4. The value of a is communicated to L3(b) to compute the b condition:
6. The b value is computed and communicated to S4(b), the memory area of b: t
t
§4 ðs1 ÞjE2 / §5 ðs1 ÞjE2
§6 ðs1 ÞjE2 / §7 ðs1 ÞjE2 where
where §5 ðs1 Þ Z ðððSa4 ð7ÞjS4 ðbÞjL4 ðb; 2 * aÞjO4 ðbÞj !½ıb3 !ð7O 0Þ:nilÞjR3 ðB0 ; click; s0 Þ
§7 ðs1 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞjO4 ðbÞjR3 ðB0 ; click; s0 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 Þ
. ½ıs1 ?1:Fðs1 ÞÞ
7. The b value is outputted, i.e. communicated to the environment:
. ½ıs0 ?1:nilÞ=Lðs1 Þ
/ §8 ðs1 ÞjE3 §7 ðs1 ÞjE2
t
H. Fujita et al. / Knowledge-Based Systems 17 (2004) 263–281
where §8 ðs1 Þ Z ðððSa4 ð7ÞjSb4 ð14ÞjR3 ðB0 ; click; s0 ÞÞ . ½ıs1 ?1:Fðs1 ÞÞ [4]
. ½ıs0 ?1:nilÞ=Lðs1 Þ 8. The end-user pushes B to exist: §8 ðs1 ÞjE3 t/ðððSa4 ð7ÞjSb4 ð14Þj½ıs0 ?1:nilÞ . ½ıs1 ?1:Fðs1 ÞÞ . ½ıs0 ?1:nilÞ=Lðs1 ÞjE3 t/nil
[5] [6]
[7]
References [8] [1] J.C.M. Baeten, J.A. Bergstra, Real time process algebra with infinitesimals in: A. Ponse, C. Verhoef, S.F.M. van Vlijmen (Eds.),, Algebra of Communicating Processes: Proceedings of the First Workshop on the Algebra of Communicating Processes (ACP-94), Springer, Berlin, 1995, pp. 148–187. [2] J.A. Bergstra, J.W. Klop, Algebra of communicating processes with abstraction, Theoretical Computer Science 37 (1) (1985) 77–121. [3] J.A. Bergstra, J.W. Klop, The algebra of recursively defined processes and the algebra of regular processes in: A. Ponse, C. Verhoef,
[9] [10]
[11]
281
S.F.M. van Vlijmen (Eds.),, Algebra of Communicating Processes: Proceedings of the First Workshop on the Algebra of Communicating Processes (ACP-94), Springer, Berlin, 1995, pp. 1–25. G. Berry, G. Boudol, The chemical abstract machine, in: Proceedings of the 17th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, POPL’90, San Francisco, CA, USA, 1990. G. Boudol, Some chemical abstract machines, Lecture Notes in Computer Science (LNCS) 803 (1994) 92–123. C.A.R. Hoare, Communicating Sequential Processes, Prentice Hall International Series in Computer Science, Prentice Hall, Englewood Cliffs, NJ, 1985. M. Mejri, B. Ktari, M. Erhioui, Static analysis on lyee-oriented software in: H. Fujita, P. Johannesson (Eds.),, New Trends in Software Methodologies, Tools and Techniques, Proceedings of First International Workshop on Lyee Methodology, Paris, IOS Press, 2002, pp. 375–394. R. Milner, A Calculus of Communicating Systems, Lecture Notes in Computer Science 92, Springer, Berlin, 1980. F. Negoro, Principle of Lyee software, in: The International Conference on Information Society in 21st Century (IS2000), 2000, pp. 121–189. F. Negoro, Principle of Lyee software, in: The 2000 International Conference on Information Society in 21st Century (IS2000), Aizu, Fukushima, Japan, November 2000, pp. 121–189. F. Negoro, I. Hamid, A proposal for intention engineering, in: The Fifth East-European Conference Advances in Databases and Information System (ADBIS’2001), Vilnius, Lithuania, September 2000.