A Top-Down Approach to Identifying and Defining Words for Lyee Using Condition Data Flow Diagrams

Transcription

1 A Top-Down Approach to Identifying and Defining Words for Lyee Using Condition Data Flow Diagrams Shaoying LIU Department of Computer Science Faculty of Computer and Information Sciences Hosei University, Tokyo, Japan URL: Abstract. We present a top-down approach to identifying and defining words for the Lyee system using the visual formalism known as Condition Data Flow Diagram used in the SOFL (Structured Object-Oriented Formal Language) formal engineering method. The proposed technique can assist the analyst to identify effectively the necessary words as outputs of operations in a structured manner and to represent the relations among words in a visual formalism. 1 Introduction The most important concern in writing a program for the Lyee (GovernmentaL MethodologY for SoftwarE ProvidencE) System is centered on the definitions of words. A word represents a data element and is usually defined in terms of other words or constants (concrete values of certain types) [1]. From the Lyee s point of view, a software is an operation producing an output word based on input words or constants. Once all the necessary words are defined precisely and necessary inputs for the definitions are given, regardless of the order in which the definitions of words are organized, the Lyee system can automatically work out the concrete value for the output word. It is claimed that an advantage of the Lyee paradigm of programming over the traditional programming paradigms (e.g., imperative programming) is to allow the programer or analyst to concentrate on the definitions of data elements (words in Lyee) without the need of considering how they are organized [1]. However, several problems need to be addressed before a correct Lyee program, a collection of definitions of words, can be constructed. The first one is how to know what words for a specific system need to be defined; whether the identified words are complete; and whether those definitions are consistent. The second problem is how to represent the definitions so that they will be easily understood by both the customer and the analyst. This point is important especially when dealing with large-scale systems. Another problem is how to find out appropriate expressions for defining the words. For example, suppose we know that word a 1 is defined in terms of words a 2 and a 3, represented formally as a 1 = E(a 2,a 3 )

2 but have no idea of how a 2 and a 3 can be used to define a 1 at the moment. The details of E is actually expected to be clarified as the analysis of the user requirements proceeds. To address these problems, a systematic method and comprehensible notation are helpful. In this paper we adopt the visual formalism known as Condition Data Flow Diagram, or CDFD for short, as a method and notation for identifying and defining words in a top-down and modular manner. As the brief introduction to this visual formalism in section 2 reveals, CDFD is a formalization of traditional Data Flow Diagram by integrating it with Petri nets and pre-postcondition notation. It allows one to describe comprehensibly all the related definitions of a word and to decompose an abstract definition of a word into detailed definition given in terms of other lower level words. Since the entire architecture of the word definitions can be organized as a hierarchy of CDFDs, the modularity of the entire word definitions can be achieved, which will help verification and evolution of the definitions. To make necessary distinction between CDFD representations and Lyee style definitions of words, we call the word definitions in CDFDs specification while the original Lyee style word definitions program. The rest of the paper is organized as follows. Section 2 gives a brief introduction to CDFDs while section 3 explains how they can be used to define words in a hierarchical manner. In section 4 I elaborate how data abstraction can help achieve high levels of functional abstraction before the system is implemented in Lyee, and section 5 gives an example to show the application of CDFDs leading to Lyee programs. Finally, in section 6 I give conclusions and outline the future research. 2 Brief Introduction to CDFD CDFD is a graphical notation for modeling system functions by defining data flows among processes. It is part of the SOFL (S tructured Object-Oriented F ormal Language) specification language, usually used for describing the architecture of specification. It was designed initially by integrating Data Flow Diagrams (DFD), Petri nets, and the formal specification language VDM-SL (Vienna Development Method - Specification Language) in 1992 as the result of my doctoral research project, and extended later to include Object-Oriented features based on my research efforts in collaboration with many international researchers over last ten years. SOFL has been applied to system modeling and design in both industrial and research projects [2][3]. A CDFD is usually composed of three kinds of components: processes, data flows, and data stores, as depicted by Figure 1. A process, represented graphically by a box, models a transformation from its input to output. For example, process P transforms input data flows a and b and generates two output data flows c and d, while process Q takes data flow c and produces either f or g but not both (this exclusive-or relationship between f and g is indicated by the short horizontal line between them). A data flow indicates that a data element moving from one process to another. For example, data flow c shows that a data element bound to c moves from process P to Q while d represents a data flow from P to W. A data store represents data depository (like a file or database), which can be accessed or updated by processes during their executions. For instance, data store s1, numbered 1, is updated by process P, indicated by the directed line from P to s1, whereas store s2 is read by both process Q and W, denoted by the directed lines from s2 to both Q and W. A CDFD is different from a traditional DFD like Yourdon s [4] in several ways. Firstly, A CDFD has an operational semantics [5] like Petri nets [6] whereas a DFD has

3 c Q f g a b P d e W h r Figure 1: An example of CDFD none. Take the CDFD in Figure 1 as an example. When both data flows a and b are available, process P is enabled and will be executed once its output data flows become unavailable. The execution will result in the generation of data flows c and d, which move to process Q and W, respectively. Then process Q executes and either f or g is produced. In the meanwhile, process W may also execute to generate both h and r. The executions of process Q and W can be performed in parallel. Secondly, the functionality of each process is defined with a pair of pre and postconditions, describing the condition that must be met by input data flows before the execution of the process and the condition that must be met by output data flows after the execution, respectively, whereas there is the lack of such a formal definition in DFDs. For example, we can define process P in an abstract form as follows: P (a, b; c, d; s1):[a>0 b>0, c= a + b d>a b s1 = s1 +a b] Where a>0 b>0 is the precondition; c = a + b d>a b s1 = s1 +a b is the postcondition of process P; and s1 denotes the intial value of variable s1 before the execution of P. Note that the output data flows c and d as well as store s1 are defined based on the input data flows a and b in the postcondition, but not necessarily in a deterministic manner. For example, data flow c is defined in a deterministic manner as c = a + b (c is equal to the sum of a and b) whereas data flow d is defined in a non-deterministic manner as d>a b (d is greater than the product of a and b). Finally, the relationships between either input data flows or output data flows of a process are precisely defined in CDFDs (e.g., data flows a and b are both required for execution of process P whereas only one of data flows d and e is necessary for execution of process W ), but such relationships in DFDs are ambiguous at the diagram level. Processes in a CDFD can be decomposed into the next lower level CDFDs if it is necessary to describe in detail how the inputs of the processes are transformed into their outputs. For example, assume that defining the functionality of process Q needs some intermediate data flows to bridge its input data flow c and output data flow f or g. In this case, it is reasonable to decompose Q into a lower level CDFD, as shown in Figure 2. To ensure the structural consistency between the decomposition and process Q, the input data flow to and the output data flows from the entire decomposed CDFD must be the same as those of process Q, respectively. Semantically, the decomposition of process Q refines the specification of Q given in the form of pre and postconditions.

4 f Q2 x y c Q1 Q3 g Figure 2: A decomposition of process Q That is, eventually process Q can be replaced by its decomposition in the CDFD of Figure 1. Since the aim of this paper is to adopt CDFDs for defining words in Lyee programs, I do not introduce the other constructs associated with CDFDs in the SOFL specification language. Readers who are interested in the detail of SOFL can refer to our previous publications on SOFL [7][8][9][10]. 3 Defining words using CDFDs To help identify and define necessary words for a specific software system, I suggest that top-down approach be taken based on CDFDs. Since programming using Lyee starts with identifying and defining the output words of the entire system (sometimes it may be a subsystem of a large one) in terms of other words, it is natural to use a process for the abstraction of such a definition whose output data flows denote the desired output words and input data flows represent the other necessary words in the definition. If the relation between the output words and input words cannot be defined deterministically for some reason (e.g., lacking necessary details), the process can be decomposed into a lower level CDFD so that the output words can be defined based on its input words through some intermediate words. This way will give the analyst opportunities to identify and define additional words necessary to the system, such as the intermediate words involved in the decompositions of high level processes. 3.1 Liner definitions By a liner definition of a word I mean that the word is defined based on other words without involving choices and recursive definitions. A simple example may help us explain how such a definition can be represented by a CDFD. Suppose we define words a, b, c, d, andf as follows: a = E 1 (b, c) (1) b = E 2 (d, f ) c = E 3 (4, 10) d =20 f =50 and we do not know exactly how E 1, E 2,andE 3 should be defined at the moment. These definitions are represented by the CDFD in Figure 3. The processes involved in this CDFD are defined as follows:

5 20 D d B 50 F f b A a 4 10 C c Figure 3: A CDFD representing the definitions of the words A(b, c; a;) : [true, a = E 1 (b, c)] B(d, f ; b;) : [true, b = E 2 (d, f )] C(4, 10; c;) : [true, c = E 3 (4, 10)] D(20; d;) : [true, d = 20] F (50; f ;) : [true, f = 50] The precondition of each process, such as A, means that there is no specific constraint on its input data flows (words in this particular case). Since we may not be able to build some expressions for defining the output words, such as E 1 and E 2,weneed to decompose them into the next lower level CDFDs, respectively, to figure out how the expressions can be defined in terms of some other lower level words. For example, suppose process A is decomposed into the CDFD in Figure 4. Thus, the definition of word a given previously will become: a = E1 1 (q3) q3 =E 2 1 (q1,q2) q1 =E 3 1 (b) q2 =E1 4 (c) Where E i 1(i =1..4) denote expressions. By replacing the definition of word a in (1), we update the definitions of the words to produce the following list: a = E1(q3) 1 q3=e1(q1,q2) 2 q1=e1(b) 3 q2=e1(c) 4 b = E 2 (d, f) c = E 3 (4,10) d =20 f =50 Of course, the decomposition of high level processes defining words can continue, if necessary, until all the words are defined in a deterministic manner. Note that the diagram of CDFD gives a two dimension representation of the words; it clearly shows which words are used to define which other words, while the formal definition of the related processes using pre and postconditions gives a precise formula for defining words.

6 b W1 q1 W3 c W2 q2 q3 W4 a Figure 4: The decomposition of process A Figure 5: A graphical representation of choice construct Therefore, the diagram and the process specifications are complementary in defining words. 3.2 Choice A choice of executing different statements for different results is a common construct in many programming languages, but in Lyee such a choice is reflected when the same word is defined using different other words and expressions (computation formula). It seems that unlike normal programming languages, the condition for deciding which definition of the same word will be used to compute its value is not given clearly; instead, the decision will be made based on the availability of the constituent words of the word in its definition. For example, suppose word w is defined as a choice as follows: (1) w = a x + c (2) w = b x + d In (1) w is defined in terms of the words: a, x, and c; but in (2) w is defined using: b, x, andd. Such definitions can be represented graphically as the process in Figure 5. Originally this process means that when either a, c, andx or d, b, andx are available, process A will execute and will generate w. In other words, which group of the data flows are used to generate w will depend on the availability of all the data flows in that group. This semantics is just well-suited for representing the definition of w as a choice. The formal textual specification of process A is: A(a, c, x x, b, d; w; ): [true, w = a x + c w = b x + d]

7 w a e Q c x P w a a 10 R f Figure 6: A CDFD for the recursive definition 3.3 Recursion Another possible structure in Lyee programs is recursive definitions of words. Consider the definition of word w below as an example. w = a x + c x = e + f f = a w f = a +10 Word w is defined using a, x, and c; x is defined in terms of e and f; and f is defined as a choice: either using a and w or a and 10. Thus, w is possibly defined recursively, that is, within the definition of w, w is used to define another word. Such a recursive definition is described by the CDFD in Figure 6. 4 Data abstraction In the SOFL specification language that uses CDFDs for descriptions of specification architecture, not only are data items of basic types, such as integers, real numbers, and characters, but several compound data types can also be used to define data flows. Thus, it enables us to achieve high levels of abstraction. In this section I give several examples to explain how the compound data types available in SOFL can be used to model complicated words. Suppose a word is expected to represent a collection of elements or values, it does not seem to have an easy way to express it in Lyee. But this can be done easily using a value of a set type in SOFL. Assume word w is used to hold such a compound data item. Then we declare it as: w : set of int; Thus, w may take the following values, each being a set of integers. (1) w = {3, 6, 9, 12} (2) w = {5, 15, 25} (3) w = {10, 20, 30, 40, 50}

8 If duplication of elements is allowed in a word of set type or the order of the occurrences of elements is significant in determining the feature of the word, we can use another type, known as sequence, to define the word, for example, w : seq of int; Thus, w may take the following values: (1) w =[3, 6, 9, 6, 12, 9] (2) w =[5, 15, 25, 35] (3) w = [10, 20, 20, 10, 30] If word w is expected to describe a composite value that has several fields, then we declare it as: w : composed of f 1 : TY 1 f 2 : TY 2... f n : TY n end; With this declaration the fields f 1, f 2,..., f n of word w will be accessed or updated, depending on the operations applied to them. For example, w can take the following composite value: w.f 1 =10 w.f 2 =20 w.f 3 =30 Where n =3. In addition to set, sequence, and composite types, there are also other types in SOFL, such as map types and union types. But since they are too complicated for abstraction of Lyee programs, I do not elaborate them here. The details of these types are given in our previous publications [7][11]. 5 Example I give an example to show the process of first using CDFDs to model the user requirements and then transforming it into Lyee-like word definitions. The system we deal withisacash Dispenser. 5.1 System description Suppose the cash dispenser is required to have the following functions: (1) Provide the buttons for showing the balance of, and withdraw money from, the account. (2) Insert a cashcard and supply a password. (3) If showing the balance is selected, the current balance is displayed. (4) If withdraw is selected, the requested amount of the money is withdrawn.

9 1 card_id amount account1 Withdraw e_msg cash Receive_ Command sel pr_meg pass account2 Show_ Balance balance Figure 7: The CDFD modeling a simplifed cash dispenser To model this system, we draw the CDFD in Figure 7. The overall output data flow, representing a word in Lyee s term, of the system is either withdrawn cash or displayed account balance. In addition to these two outputs, error messages, as a kind of output, may also be possible, such as e_meg and pr_meg given in the CDFD. The diagram conveys the user functional requirements and the dependency relations between the functions represented by the processes in the diagram. The selection of balance, denoting the command of showing the balance or w_draw, denoting the command of withdraw, is handled by the process Receive_Command. This process then generates a data flow sel to indicate which command has actually been selected, and passes this information to the process Check_P assword. When the requested cash card card_id and password pass are provided, this process will check whether the provided account exists in the system account database account_file, and if so, whether the password pass is the same as that of the account. If these pieces of information are confirmed, the process Check_P assword will pass the account information, denoted by account1 or account2, to either the process W ithdraw or Show_Balance, depending upon the value of data flow sel. If these pieces of information are, however, not be confirmed, an error message pr_meg will be issued. The process W ithdraw updates the account_file by reducing the amount from the current balance of the account1 if the requested amount of money is less or equal to the current balance. However, if this is not the case, the process will generate an error message to show that the amount requested is invalid. The process Show_Balance takes the confirmed account denoted by account2, which is the same as account1 in contents, and displays the current balance of the account, which is represented by the data flow balance. In contrast with the informal functional specification given at the beginning of this section, the functional abstraction expressed by the CDFD is obviously more precise and comprehensible in modeling the dependency relations between processes. To completely define the CDFD, all the processes, data flows, and stores must be defined precisely in a proper manner. To achieve this goal, we adopt the module structure in SOFL to provide a formal specification of the CDFD. The module for the cash dispenser is given as follows: module SYSTEM_Cash_Dispenser /* This module is the top level module.*/ type

10 Account = composed of account_no: nat password: nat balance: real end var ext #account_file: set of Account; /* the account_file is an external store that exists independently of the cash dispenser. */ inv forall[x: Account] 1000 <= x.password <= 9999; /* The password of every account must be a natural number with four digits. */ behav CDFD_1; /* Assume the cash dispenser CDFD is numbered 1. */ process Init() ext account_file post account_file = ~account_file end_process; /* The initialization process does nothing in updating the local store because there is no local store in the CDFD to initialize. */ process Receive_Command(balance: sign w_draw: sign) sel: bool post balance <> nil and sel = true or w_draw <> nil and sel = false comment This process recognizes the input command: show balance or withdraw cash. The output data flow sel is set to true if the command is showing balance; otherwise if the command is withdrawing cash, sel is set to false. end_process; process Check_P assword(card_id: nat, sel: bool, pass: nat) account1: Account pr_meg: string account2: Account ext rd account_file /*The type of this variable is omitted because this external variable has been declared in the var section. */ post sel = false and (exists![x: account_file] x.account_no = card_id and x.password = pass and account1 = x) or sel = true and (exists![x: account_file] x.account_no = card_id and

11 x.password = pass and account2 = x) or not (exists![x: account_file] x.account_no = card_id and x.password = pass) and pr_meg = Reenter your password or insert the correct card comment If sel is false and the input card_id and pass are correct with respect to the exiting information in account_file, the account information is passed to the output account1. If sel is true and the input card_id and pass are correct, the account information is passed to the output account2. However, if neither the card_id nor pass is correct, a prompt message pr_meg is given. end_process; process W ithdraw(amount: real, account1: Account) e_msg: string cash: real ext rw account_file pre account1 inset account_file /*input account1 must exist in the account_file*/ post (exists[x: account_file] x = account1 and x.balance >= amount and cash = amount) and account_file = union(diff(~account_file, {account1}), {modify(account1, balance -> account1.balance - amount)}) or not exists[x: account_file] x = account1 and x.balance >= amount and e_meg = The amount is too big ) comment The required precondition is that input account1 must belong to the account_file. If the request amount to withdraw is smaller than the balance of the account, the cash will be withdrawn. On the other hand, if the request amount is bigger than the balance of the account, an error message The amount is too big will be issued. end_process; process Show_Balance(account2: Account) balance: real post balance = account2.balance; end_process; end_module; Since there is no local store in the CDFD of this module, the initialization process Init does nothing in updating the local stores of the CDFD, as indicated by the postcondition of Init. Some relatively complicated process specifications are explained informally in the comment parts, such as processes Receive_Command, Check_P assword, and W ithdraw, but for the simple process like Show_Balance no comment is provided.

12 Notice that several operators defined in set types and composite types are used, such as union(), diff(), modify(), etc. Briefly speaking, the operation union(x, y) is the union of the two sets x and y; diff (x, y) yields the set whose elements belong to x but not y; andmodify(x, f >v1) yields a new composite object from the given composite object x by replacing the value of its field f with v Transformation Suppose this specification is verified and validated to meet the user requirements. We then need to transform it into a Lyee program for possible execution by the Lyee system. Two issues given below need to be addressed for the transformation. Derivation of the structure of word definitions in terms of the word relations based on the CDFD. Generation of the computation formulas used in the definitions of words based on the formal specification of the processes involved in the CDFD. These two issues are actually related closely with each other. If the specification of process is described implicitly, meaning that the relation between the input data flows and output data flows are written in a predicate, it is difficult to give a general rule for the derivation of the structure of word definitions and the associated computation formula. However, if the relation is described explicitly, meaning that the output data flows are defined with an expression, the structure of word definitions and the computation formula can be derived easily. Since most processes in the Cash Dispenser example are given in an implicit manner, their transformation into word definitions requires additional efforts from the programer. Since there is no sufficient knowledge about how to deal with this kind of problem in Lyee, I would like to leave this topic for discussion at the workshop. 6 Conclusions and future research I have presented a top-down approach to identifying and defining words for the Lyee system using the visual formalism known as Condition Data Flow Diagram used in the SOFL (Structured Object-Oriented Formal Language) formal engineering method. The proposed technique allows the analyst to identify effectively the necessary words as outputs of operations (processes) in a structured manner and to represent the relations among words in a visual formalism. Also, due to the availability of abstract data types in SOFL, such as set, sequence, and composite types, the functions of processes defining words can be expressed with a high level of abstraction, which allows the analyst to focus on the functions of the system before undertaking its implementation. To make the proposed technique really useful in supporting Lyee programming, we need to provide effective techniques and tool support for transforming a CDFD into a set of word definitions. I am interested in the investigation of this issue in the future. 7 Acknowledgement I would like to thank Prof. Hamid Fujita for his support and encouragement for this research.

13 References [1] The Institute of Computer Based Software Methodology and Technology, Introduction to Lyee - Revolution by Automatic Software Development, Distributed booklet, [2] Shaoying Liu, Masashi Asuka, Kiyotoshi Komaya, and Yasuaki Nakamura, Applying SOFL to Specify A Railway Crossing Controller for Industry, in Proceedings of 1998 IEEE Workshop on Industrial-strength Formal Specification Techniques (WIFT 98), Boca Raton, Florida USA, October , IEEE Computer Society Press. [3] Shaoying Liu, Masaomi Shibata, and Ryuichi Sat, Applying SOFL to Develop a Univeristy Information System, in Proceedings of 1999 Asia-Pacific Software Engineering Conference (APSEC 99), Takamatsu, Japan, December , pp , IEEE Computer Society Press. [4] Edward Yourdon, Modern Structured Analysis, Prentice Hall International, Inc., [5] Chris Ho-Stuart and Shaoying Liu, A Formal Operational Semantics for SOFL, in Proceedings of the 1997 Asia-Pacific Software Engineering Conference, Hong Kong, December 1997, pp , IEEE Computer Society Press. [6] Wilfried Brauer, Grzegorz Rozenberg, and Arto Salomaa, Petri Nets - An Introduction, Springer-Verlag, Berlin Heidelberg, [7] Shaoying Liu, A. Jeff Offutt, Chris Ho-Stuart, Yong Sun, and Mitsuru Ohba, SOFL: A Formal Engineering Methodology for Industrial Applications, IEEE Transactions on Software Engineering, vol. 24, no. 1, pp , January 1998, Special Issue on Formal Methods. [8] Shaoying Liu, Masashi Asuka, Kiyotoshi Komaya, and Yasuaki Nakamura, An Approach to Specifying and Verifying Safety-Critical Systems with Practical Formal Method SOFL, in Proceedings of Fourth IEEE International Conference on Engineering of Complex Computer Systems (ICECCS 98), Monterey, California, USA, August , pp , IEEE Computer Society Press. [9] Shaoying Liu, An Evolution Approach for Software Development Using SOFL Methodology, in Proceedings of International Workshop on Principles of Software Evolution (submitted), [10] Shaoying Liu, Formal Engineering Methods for Information Systems Development, in Proceedings of 2nd International Conference on Information (INFORMATION2002), July. [11] Shaoying Liu, Verifying Consistency and Validity of Formal Specifications by Testing, in Proceedings of World Congress on Formal Methods in the Development of Computing Systems, Jeannette M. Wing, Jim Woodcock, and Jim Davies, Eds., Toulouse, France, September 1999, Lecture Notes in Computer Science, pp , Springer-Verlag.