From visual specifications to executable code - CiteSeerX

3 downloads 57739 Views 9KB Size Report
ject-oriented visual specification of software and its automatic synthe- sis. ... in the implementation of such languages, i.e. in developing tools which enable us to ... graduate education, and applicable in simulation and network management.
From visual specifications to executable code Enn Tyugu Department of Teleinformatics, KTH Electrum 204, 16440, Kista, Sweden e-mail: [email protected] This presentation is based on a particular application that includes object-oriented visual specification of software and its automatic synthesis. The questions discussed here are: extending classes with extra information for program synthesis, a formalism for representing this information and building visual (object-oriented) ontologies. 1 Introduction Conceptual analysis in many domains uses visual representation of objects and relationships. This is obviously true for engineering domains where graphics is often a part of design documentation. It is true for software engineering as well, where we have well-established graphical representation of various software artifacts. Attempts are made to formalize the semantics of visual representations, in particular, the UML is intended to be a language with quite clear semantics [1]. However, the difficulty lies in the implementation of such languages, i.e. in developing tools which enable us to use the languages with high degree of automation. In the present paper we give an example of automatic usage of visual specifications. To be able to automate software processes, we should have efficiently usable formal methods for the processes. Developments in logic programming, functional programming and software verification show that automatically usable formal methods have reached sufficient maturity to be used in software practice. We demonstrate the usage of a program synthesis method which relies on a restricted logic of intuitionistic propositional calculus, but has high performance and is applicable to large specifications. We describe a layered software development environment which provides visual tools for domain analysis. Result of the domain analysis is a visual specification language directly implementable by means of the visual tools. 2 About the NUT system A software development environment NUT considered here is a Unix/Linux based tool for experimental programming and prototyping used in undergraduate as well as graduate education, and applicable in simulation and network management. The present version (version 3.0) of NUT is free software available via ftp. It supports development of large distributed programs in the object-oriented style, and enables the user to specify classes graphically by drawing their schemes. It is compatible with C language, runs under X Windows System on Solaris and Linux. It combines objectoriented programming, visual programming, and automatic program construction par-

adigms. Besides the ordinary usage, classes in NUT serve as specifications which can be used for constructing programs automatically [2]. In particular, a method compute is available by default in every user-defined class, and it can be sent to any object x as a request to compute some of its components, let us say, y. The expression x.compute(y) produces a value of y if the class of x contains information for computing this value. A special form of deductive program synthesis is used for constructing programs for answering the compute messages. Although automatic synthesis of programs from computability knowledge has been the intention from the very beginning of development of our system, its program synthesis part has become useful only gradually, with growing experience of usage and after introduction of visual programming tools. This has helped us to find applications in the areas like discrete event simulation and control of safety-critical systems [3]. This has also added a flavor of generality to our tools. NUT has a scheme editor for specifying classes graphically, by drawing their schemes. This can be done, whenever problems are of such a nature that they can be specified in terms of classes developed for a particular problem domain in advance. The (automatic) way from a graphical specification to expected results is the following: graphical scheme -> textual specification -> constraint network -> synthesized algorithm -> results of computation. In many cases, the intermediate steps are completely hidden from a user. Using the scheme editor, a user can develop its own graphical language and use it for specifying programs in his problem domain. The NUT system together with its documentation is available from http://www.it.kth.se/labs/se/nut.html. 3 Program synthesis NUT programs include statements which describe computational problems, i.e. goals for computations without explicitly given algorithms. A computational problem in an abstract form is represented as c |- x1,...,xm -> y1,...,yn which means “compute y1,...,yn from x1,...,xm knowing c”. More precisely, c is a class name, x-s and y-s are components of this class and “knowing” means having axioms about the class. In order to solve the problem, first, the implication x1&...&xm -> y1&...&yn, where xi, yj are propositions denoting the computability of xi, yj respectively, will be derived in the theory about c, thereafter a program is composed from the realizations of the axioms used - this is the synthesized program. Finally, this program is executed and the values of y1,...,yn are computed from the given values of x1,...,xm. This is a special scheme of deductive program synthesis called structural synthesis of programs (SSP). It has been thoroughly described in literature [5]. The SSP has a pleasant property of decidability: one can decide for each computational problem whether the problem is solvable or not (i.e. whether the implication x1,...,xm -> y1,...,yn can be derived), and in the case of solvability, a program for solving it can be built from the solvability proof. Theoretically, building the solvability proof may require quite long search, but in practical cases the search time is quite small. Practically, we handle thousands of axioms in less than a second. The logical language of SSP is the implicative fragment of intuitionistic propositional calculus. Inference rules of this

logic are natural deduction rules (introduction and elimination) for conjunction and disjunction. Program extraction is a straightforward process, because we use a constructive logic. 4 Visual tools supporting deep semantic of schemes The basis of visual tools of NUT is a general-purpose scheme editor [5]. The program synthesis plays an important role in it, bridging the semantic gap between high-level visual languages and computer programs. The scheme editor supports usage of schemes as specifications of classes. A meaning of a scheme can be always considered to be a data structure representing a graph. We call this shallow meaning of a scheme. However a scheme has another, a deeper, meaning to a user. This meaning can be explained verbally and, to a certain degree, represented in a computer by the programs which can manipulate schemes. We define that deep meaning of a scheme is a set of computations (actions) automatically derivable from the scheme, using semantic definitions of the scheme language. Here we consider the architecture of a semantic processor of schemes. At the topmost level we have a drawing representing a scheme. This is the normal user interaction level for working with an application. The shallow semantics of a scheme is initially represented in the specification language of NUT. Creating and editing schemes is supported by the scheme editor which compiles a scheme into the specification language of NUT. Thereafter the specification is compiled into the internal language which includes a logical language and an algorithmic language for representing preprogrammed functions. As the last step, parts of programs are synthesized for goals specified in by means of the compute method. References 1. G. Booch, I. Jacobson, J. Rumbaugh (1997). Unified modeling language reference manual. Addison Wesley. 2. E. Tyugu. (1994). “Using classes as specifications for automatic construction of programs in the NUT system”. Journal of Automated Software Engineering, v. 1, 315 - 334. 3. M. Addibpour, E. Tyugu. (1996). Structural synthesis of programs from refined user requirements. (Programming boiler control in NUT.) J-R Abrial et al. (eds.) Formal Methods for Industrial Applications. LNCS 1165, Springer, 13 - 34. 4. G. Mints. (1991). Propositional Logic Programming. In: J. Hayes, D. Michie, E. Tyugu (eds.) Machine Intelligence 12. Clarendon Press. Oxford, 17 - 37. 6. E. Tyugu, R. Valt. (1997). Visual programming in NUT. Journal of Visual Languages and Computing, v. 8, 523 - 544.