From Formal Requirements to Implementation: a

From Formal Requirements to Implementation: a Java Targeted Development Method Eva Coscia

Advisor: Prof. Gianna Reggio

Thesis Proposal Dottorato in Infomatica Dipartimento di Informatica e Scienze dell'Informazione Universita degli Studi di Genova, Italy

Abstract

The aim of this thesis is to provide a speci cation methodology for reactive and concurrent systems that covers the whole process of designing a system. Starting from a high-level (very abstract) description we want to give the formal tools and guidelines to develop several steps in the re nement process of the speci cation. We would like to reach, as the nal step of that process, an implementation in a "real" programming language as Java.

Contents

1 Introduction 2 Main Objectives 2.1 2.2 2.3 2.4 2.5 2.6

Java Analysis : : : : : : : : : : : : : : : Requirement elicitation and speci cation Design speci cation : : : : : : : : : : : : Correctness and veri cation : : : : : : : Code Generation : : : : : : : : : : : : : Software Evolution : : : : : : : : : : : :

2 6

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

3 Related Work

3.1 State of the Art : : : : : : : : : : : : : : : : : : 3.1.1 Languages and Methods for Speci cation 3.1.2 Correctness and Veri cation : : : : : : : 3.1.3 Java Language : : : : : : : : : : : : : : 3.2 Starting Points : : : : : : : : : : : : : : : : : :

4 Research Plan

6 7 9 10 11 11

12 : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

12 12 16 17 18

20

1

1 Introduction The main problem of formal methods (shortly f.m. from here on) is to gain acceptance in the industrial world, to bridge the gap between academia, where their relevance seem to be widely emphasized and demonstrated, and the industrial world. There are some reasons, perhaps mistakes that make f.m. refused (see e.g. [45]) for practical use:  most of them are only formal; it is not taken into account the environment (the kind of user) by which they should be used. In [27]: \Formal notations are alien to most programmers who have little training and skill in mathematics...." Conversely, \Some advocates of f.m. take a very dogmatic position, that absolutely everything must be proved, to the highest possible degree of mathematical rigor"  formalisms cannot be used by their own, they must be tightly coupled with methods that clarify the result to obtain and the way of achieving it. Not enough emphasis has been put on them till now [17].  System developers are concerned with error elimination, so the need of rigorous development makes the application of techniques based on formal methods necessary. But their relevance in industrial application can also be measured by the automation degree they introduce in the development process. They must be equipped with tools that help and fully (or, at least, partially) automate veri cation and code generation (industrial world requests has been analyzed, for example, in [1]).  most f.m. focus just on a part of the development process, but industry requires methods that cover all the software life-cycle, from requirements to code testing. A \partial" method cannot be well accepted, since developers seem to be willing to spend time for an initial training period and to change their approach to software development, if the new method helps them to actually implement the system. But the use of f.m. is more urgent now, when the failure of large applications can be related to complexity increase and bad requirement analysis. 2

The challenge is to make f.m. recognized as a viable technology for system development process. It is not realistic to work out a method completely formal for the whole development process: it is necessary to integrate f.m. with existing wellaccepted development practices, but it is not possible to equate f.m. and software engineering. So, we want to understand how to use f.m. in the context of development of software systems that is a very complex activity. By development we mean the process that, starting from an informal description of a system that a customer gives to an implementor, performs some kinds of activity that make transformations on this description till a coding in a programming language is produced. Many other activities are also involved, as maintenance (see sec.2), which is often ignored but which consumes most of the costs. A new aspect that we would like to introduce in our method is system evolution (see sec.2): every phase of the development process is dynamic and must be developed in a way that makes easy to introduce changes and modi cations. Since we are interested in non-toy systems (using the terminology of Berard [7], \toy" applications are opposed to \real" ones), the main problem we have to solve is how to treat the complexity of such systems following a formal approach: abstraction and decomposition seem to be the correct solutions. So, we want a method that develops several phases to describe the system at dierent decreasing levels of abstraction and decompose them in more simple subcomponents. Every phase is a step forward to the implementation of the system and the coding in a programming language. As explained in sec.3.2 we have chosen Java as target language. The choice of the target language deeply in uences the whole development process; we cannot simply take an existing development process and introduce a coding phase that uses Java, but the whole method should be aected by this new target (e.g. if the target language is OO, it is sensible to use an OO speci cation style). Also, the kind of applications for which the method is tailored determines the kind of abstract properties that have to formalized and the design to describe; this has an immediate impact on various phases and on the de nition of the speci cation language. The choice of the implementation language, on the contrary, heavily impacts on the design speci cation language, that must be adequate to (abstractly) describe implementation choices that must be coded into Java. A speci cation method must describe the system features very precisely, but system features vary widely, so that a method is suitable just for a particular class of systems. We are not looking for a general-purpose method, 3

that ts well any kind of problems. However, we would like to give the user expressive speci cation languages and useful examples so that the method can be adjusted and applied in the correct way to each speci c case, in the context of a well-established class of systems. Below we summarize the main features that this method should have (not necessarily everything will be developed in this thesis):  a \user oriented" method that gives tools, guidelines and hints for a generic user on how to proceed to use it; furthermore, it is necessary to give a friendly presentation, by avoiding an exoteric notation for speci cations and accompaning them with natural language and graphical notation.  a sound method i.e.equipped with expressive and adequate formalisms and with supporting tools for the various phases; it will result in a semiformal method, where not everything is formal, in a pure mathematical meaning, even if we describe a methodical and precise way to develop every phase of the process;  a method covering a substantial part of the software life cycle, that has a real-language implementation as the nal goal. It would be interesting also to study how to introduce evolutionary aspects of software development process (see sec.2) in the steps of the method. We want to help the user in the development process by oering an homogeneous method that is used in most of the phases till reaching a complete and \running" product;  a \specialized" method that is focused on the class of software systems that could be described by adjectives like: concurrent, reactive, interactive, distributed, networking. In the development of this kind of systems, questions of requirements, design, correctness, implementation are more important then for sequential programs. Distribution and reactivity make systems more dicult to be designed and understood, so a proper method is needed. The speci cation languages to be developed for the requirement and for the design speci cations, as well as the programming target language around which develop the method are strongly addressed to this kind of systems.  a method that is built on some well established concepts and techniques, that is developed also by taking into account the \state of the art" for 4



what concerns f.m. , formal speci cation languages, software engineering and so on. We are not planning to start these complex work from scratch. Our research group at the University of Genova has worked over the last years on (algebraic) formalisms for the speci cation of reactive-concurrent-distributed systems, at dierent levels of abstraction, with a formal concept of implementation correctness. It has been investigated also how to equip them with a friendly notation for speci cation combining formal syntax with natural language descriptions [18], techniques for decomposing speci cations of complex systems, guidelines for producing speci cations, a graphical (non textual) notation for design speci cations [31] (see sec.3.2). In giving a semantics to Java, we plan to refer to a similar work on semantics of Ada [16]. The focus of this thesis is mainly in studying (researching) how to enrich this pre-existing work with other parts, in order to develop and tailoring a method with the above characteristics. This means we focus our attention on the study of: { method concerning requirements elicitation (see sec.3.1.1) and speci cation; { (semi)-automatic veri cation of correctness; { code generation for particular applications, with a semi-automatic translation of a design speci cation into Java code; a \Java targeted" method aimed to a Java implementation. We chose an OO language because it naturally implements some features like modularization, encapsulation, information hiding, data abstraction. Moreover, a great relevance is put on reusability of code, a primary demand from developers. Particularly, Java is a truly OO language, that is widely accepted for its simplicity and, at the same time, for its richness. It is considered a language for the net, for its portability, but also a language for concurrency and distribution. Part of our work (already started) is the analysis of the language features. The constructs implementing distribution, concurrency, migration of objects and threads must be carefully analyzed so that we can nd the speci cation languages that correctly take into account these features. Besides, when writing speci cations is important to think about the language used for the system nal implementation (coding). We expect 5

to nd out which are the requirements or the design choices that cannot be realized into Java.

2 Main Objectives In this section we summarize the main objectives of the thesis, that is the main parts that we need in order to have a method as previously described, namely:  Java analysis;  requirements elicitation and speci cation;  design speci cation;  correctness and veri cation;  code generation.

2.1 Java Analysis

Even if the implementation of the software system is the end point of the development process, it is important to have a clear and precise idea of the target language features of Java in any phase of the development. We have to choose a sublanguage expressive enough to cover every kind of architectural implementation choice (for example, related to distribution of the system) or behavioral property we could specify in the requirement and design phases. So, the choice of the sublanguage is heavily related to the class of systems for which the method will be developed. An objective of this thesis is to analyse these issues and to give a formal semantics of the sublanguage. For example we still have to understand how distribution is realized, if there could be any problem when passing object names from a process to another one. Moreover, migration of code is also possible in Java and an implementation of agents has been developed [2]; this is another aspect we are starting to investigate. A complete and formal semantics of Java (or, better, of a sublanguage) would be very helpful essentially for two reasons:  in order to have a clear perception of language expressive power and of some issues, like concurrency and so on; this has a large impact on the construction of requirements and design speci cation languages, since 6

when specifying a system we have in mind which are the features that it is possible to use in the nal implementation.  Furthermore, we would like to give a semantics to Java in the context of a speci cation method, so we are looking for a formal but also simple model that could be useful to model Java programs. We also need to have a notion of equality program that is to be used when proving the correctness of an implementation w.r.t. to a speci cation; it is important to establish which are the \observable" dierences between two programs. From this point of view, probably we can use an \abstract" semantics for Java, i.e.a semantics in which some Java aspects are not considered; we are currently investigating a semantics that abstract from real-time and from priorities management, since they seem to be signi cant only for single computations or when particular choices on the Java implementations have been made. Obviously, if we are able to prove that we can abstract from real-time, this has an impact on the method and the speci cation languages can ignore real-time issues. Nowadays, no formal semantics has been given to Java; the only work that has been published is the one by Drossopolou and Eisenbach ([41]) that is mainly concerned on Java type system, even if it is also given a run-time semantics for a very small sublanguage. A work in progress, mainly focused on concurrency aspects of Java, has been presented in the WADT workshop in Tarquinia, by Cenciarelli, Wirsing last June. So one of the rst direction of our work would be:  to establish a Java sublanguage powerful enough for the kind of applications we are interested in;  to look for aspects of the language that are not relevant (in the sense described above), consequently, which the semantics can abstract from;  to give it a formal operational (abstract) semantics and nd out a reasonable notion of equality between programs, that makes possible to establish when two programs are equal up to some non-relevant implementation details.

2.2 Requirement elicitation and speci cation

What is a method? Shortly: it is a way to do something. In this particular case we want to develop a formal method that describes one possible approach 7

to the development of complex (reactive, concurrent..) systems starting from a description that could be informal (in natural language). The aims of this part of the work are: to give a method for requirements elicitation, to develop the corresponding formal speci cation languages and to give guidelines for their use. The method should also address the problem of system maintenance and evolution: systems should be designed and implemented so that evolution problems are minimized.

Requirements elicitation Goguen (as reported in [8]) has observed that

it is not accurate to say that requirements are in the minds of the client; it would be more accurate to say that they are in the social system of the client organization; they have to be invented, not captured, and this invention is the result of a cooperation among the client, the user and the developer. Investigating requirements is one the rst point to consider in our work, in order to give guidelines that support the method user in giving an adequate description of the system, avoiding to omit properties, to develop inconsistent speci cations by giving con icting requirements, to overspecify the system. Since we are focused on particular systems, we can try to investigate which are the most common properties related to concurrent or reactive systems, some informal ideas on how to check if each kind of properties has been carefully taken into consideration. It is also important to clarify what we have to specify and which is the speci cation domain, that is the part of the system to include in the speci cation. In [34], Jackson says that, for a system that controls trac lights a full description of the environment can be necessary for the problem analysis, but it is unnecessary to be modeled in the implemented system, while it is necessary for a system that construct a simulation of the real world. In the example of trac lights, we need to determine and formalize requirements of the whole system, as the button that is pushed by pedestrians, even if it will be codi ed just the algorithm for changing lights, because, in order to validate the nal product we need to know which is the complete environment in which the software operates and which are the assumed properties about this domain.

A (formal) speci cation language Requirements identi ed in the pre-

vious phase need to be formally expressed. A formal speci cation requires: formal models, that is mathematical structures representing the system, formal languages to describe models and validity notions that establish conformity of formal models to formal descriptions. 8

In our group, many languages for requirement speci cation have been considered. Essentially, they are extension of rst order logic with temporal operators [20], deontic operators [19] or abstract events [38] in order to express abstract properties of non-deterministic, reactive and concurrent systems. In this phase, we have to investigate which one (or which combination) of these languages or which sublanguages could be a good choice.

2.3 Design speci cation

A Java targeted design speci cation During the development of spe-

ci cation languages for the method, the notion of which is the nal step of our method, that is coding into Java, must be always present in our minds. The intermediate level between requirements speci cation and Java coding are design speci cations. Probably, we need more the one design level to allow a codi cation. Requirement properties must be re ned by introducing implementation choice; system architecture is decomposed into subcomponents, that are speci ed independently and then the whole system activities are described in terms of subcomponents activities (by using cooperations notion, for example, as described in [31]). But if we want to translate all this stu into Java code, we have to eliminate any local non-determinism, to establish which components are purely concurrent (and will be coded into Java threads, for example), to give a precise representation and characterization of distribution and so on. When examining which could be the intermediate phases among requirements description and nal coding, we also want to consider how to give a support to software evolution [45], that is an analysis about how to minimize the impact of changes occurring at any level on the whole method.

A user friendly notation It is important not to forget who are the users of this method that is to be used in real application by non-academic people. Typical users may be customers as well as implementors, even if in some intermediate phase also other people could become involved in the process. Obviously, we do not want to lose the value of a formal approach so it is necessary to nd a middle way that settle these two aspects. Formal speci cation languages need to have a friendly syntax. From the analysis of OO methodologies ([11], [12]) and of the reasons of the success of other (semi) formal method, but also from our personal experience in the utilization of graphical support to design speci cation, developed at Genova ([31]), emerged the usefulness of a compact, understandable, clear graphical presentation of speci cations. There is a new growing interest in graphical (visual) 9

representations of methods ( e.g.Visual '98: an International workshop on Visualization Issues on Formal Methods will take place in Lisbon (Portugal) next March). Presentations of speci cation should also be manageable, since size of drawings could become too large to be already readable and should allow to give dierent views of the system, focusing on dierent aspects of the system (static and dynamic descriptions of a component, decomposition of a system into subcomponents..) of the speci cation. Moreover, we need a graphical presentation adequate for dierent phases of the development process. Some ideas for requirements graphical notation can be taken from OO methodologies and (for what concerns requirements speci cation) from works on graphical languages that capture requirements and represent temporal properties ([29]).

2.4 Correctness and veri cation

Correctness When using a formal method it is possible to have a precise notion of implementation and a mathematical approach to the problems of correctness-preservation of development steps. Formal notions have been given by our group for dealing with implementation correctness between requirements and design speci cations. We need to understand how they can be adapted to the new requirement and design speci cations, while the notion of correctness of a Java program w.r.t. a design speci cation is completely new. Veri cation Tools Since speci cations, models and re nement have a pre-

cise mathematical foundation, we can use automatic or interactive veri cation tools. Another important point to be considered is if it is possible and useful to verify correctness of the implementation only between the coding and the requirements speci cation. From a certain point of view, if the development process follows the method where some hints are given to informally check, for example, if every requirements is satis ed in a design phase (the graphical presentation could be helpful too), then one could be reasonably sure to operate correctly and postpone the use of mathematical tools to the nal step. On the contrary, to nd out errors and inconsistencies at a very late stage makes more dicult to eliminate them and this can justify the burden of veri cation at several moments. Moreover, it could be dicult to understand which part of the code implements a given requirement, so the proof could be very dicult. 10

For what concern the choice of the tools of the veri cation, it is not realistic to adopt something that requires a strong logical background or needs a long training period. Moreover, we do not want to develop a new product from scratch, but to analyse existing veri cation tools in order to discover which are the most intensively used and how they can be integrated within our method. We must investigate which is the power of the tool (for which kind of logics are more well suited) and if the tool can be adapted to our speci cation languages: it is necessary to have a higher order logic because we need to represent temporal properties on potentially in nite behaviors. Moreover, we have to understand which are the class of properties most common for the systems of interest and which are the strategies to prove them. We would like to reduce the time a user have to spend before correctly and successfully use it.

2.5 Code Generation

We try to do this in the most automatic way rst of all to make the method really useful for software development, but also to make more easy the proof of correctness: we can prove that some translation schemata from design speci cation to Java code are correct and automatically use them to produce code. Currently used code generators for OO languages from OO methodologies suer from the gap between this two parts: OO languages do not oer native support for relations like association, aggregation or generalization or speci cation. Many decision are left to the user. Our aim is to investigate which is the level of implementation details for a design speci cation to allow a translation as much automatic as possible. In this phase we just want to give a possible coding of a speci cation into Java; perhaps we will consider if it could be useful to have just a prototype of the speci cation, i.e.a very rough Java program. Obviously, a quasi-automatic coding phase cannot optimize the code.

2.6 Software Evolution

There is a growing interest on software evolution, a new approach that focuses on the dynamic changes that can occur at any phase of the development process. This new paradigm focuses on traceability problem, that is the problem of relating implementation decisions or parts of code to the requirement that 11

has to be satis ed by them, and on dependencies, the problem of calculating propagation of changes into a network of dependencies relation among modules and other objects of the software development process. A method for concurrent, reactive, distribute systems cannot simply follow a water-fall paradigm, even if the development process is still made up of a number of stages such as requirement speci cations, design speci cations, implementation and so on. So we would like to incorporate some aspects described in the evolutionary paradigm inside our formal method; a possible approach that we would like to analyse is the featured oriented paradigm: a new paradigm based on behavioral abstraction and that can be supported by an extension of Java (see sec. 3.1.3)

3 Related Work In the rst part of this section we give a short description of the state of the art w.r.t. speci cation methods and languages, veri cation tools as well as a brief introduction to Java language and code generation. Nowadays, there is a great deal of formal, semi-formal and informal languages and methods for the speci cation of software systems. Some of them have a great relevance from a formal point of view, but a very little usage in real applications (for the reasons we explained in sec.1). Others are largely used in industrial applications but are not very interesting, from our point of view, since are well suited for non-reactive and non-concurrent systems and/or lack of formal foundations.

3.1 State of the Art

3.1.1 Languages and Methods for Speci cation A look at Software Engineering Formal methods cannot substitute Soft-

ware Engineering in the development process, without giving up hope to be acceptable in industrial applications. Several paradigms for software system developments have been proposed in literature ([43], [40]) e.g. the water-fall model, exploratory programming, prototyping, formal transformation. New approaches try to overcome limitations of some of these paradigms; an example is the interest for use of formal methods for software evolution: evolution is not just another name for maintenance, since it occurs in every phase of the development process and comprehends every activity 12

that changes the system, as changes in the requirement, in the design, check of errors and inconsistencies (see [45]). Maintenance, instead, occurs only after an initial development phase, so it does not concern changes in the requirements, for example.

Requirements and design speci cations The development of our method is based on some well accepted concepts. The approach to system speci cations starts with the determination of the so-called problem context or problem frame ([25]). Furthermore, many times this domain is informal and it is described in a very abstract way. So, how to capture requirements is a very delicate point, on which both people working on formal methods ([27],[25], [26]) and people working on s.e. (also using the word requirement engineering [8]) are debating. In [26] (Functional) requirements are located in the environment, which is distinguished from the machine to be built. A requirement is a condition over phenomena of the environment. A speci cation is a restricted kind of requirement, providing enough information for the implementer to build the machine without further environment knowledge. The basic task is to identify which are events, interactions and states of the system and of the environment, that can be described precisely, de ne them and then use a suitable formal language to describe more complex concepts. The method in this phase must also give guidelines and examples that can be helpful in the identi cation of these requirements and for a rst check that all the important aspects have been described. A successful formal veri cation of a software system proves that the program corresponds to the formal requirements. It does not prove in any case that the requirements are adequate for what concerns the application. In this thesis we will not consider the validation phase. Once the problem context has been individuated, another crucial point is complexity: it is necessary to have tools for the abstraction and decomposition of the problem. Obviously, formalization is necessary in order to reason with problem decomposition in a reliable way. Another approach that can be useful to face system complexity is modularity that is the separation of the system speci cation into parts that can be understood and developed separately. In our method, whose starting point is LTL (see sec.3.2) we try to decompose a system and describe the whole 13

behavior by, primarily, describing subcomponents behavior and, then, how they can be combined together. In the design phase, the architecture of the system is developed and the formal descriptions are more constructive, re ecting the design ideas of the intended implementation.

Formal Methods and Languages In the following we classify some of the

speci cation formalisms that seem to have success in academic or in industrial world. We try to identify the features that makes them so agreeable for customers and implementors.  Graphical formalism like Petri Nets, SDL and statecharts have been developed for the treatment of distributed-concurrent systems; they are very popular since they give some overview of the system but also try to provide a precise, formal model and semantic de nition.

{ Statecharts([15]) generalize state-transition diagrams. They are

used to specify the design of reactive systems, i.e. by describing the response of a system to input stimuli. While also addressing aspects like concurrency and real-time behavior, statecharts retain the visual and intuitive appeal inherent to ordinary state diagrams. { SDL (Speci cation and Description Language) (see [4])is a graphical, formal speci cation language for real-time systems. It is commonly used within telecommunication systems. It supports formalization of synchronous communication only. Both a textual and a graphical presentation are given. { Petri Nets (see [39]) is a formal and graphical appealing notation which is appropriate for modeling systems with concurrency. The language is a generalization of automata theory such that the concept of concurrently occurring events can be expressed. It is particularly well-suited to represent causal dependencies and independence relation, concurrency relation among events. Net representation makes possible to verify system properties.



Other methods seem to be appreciated from developers but lack speci cation languages to describe the system at an abstract level. ASM: the Abstract State Machines, formerly known as Evolving Algebras, started by Yuri Gurevich (see [22]), seem to have success in applications both for hardware and software speci cations because of the 14



simplicity of the formalism, but they just support a not (very) abstract notation for the description of algorithm and lack a precise description of language syntax; moreover, it is not clear how to express concurrency in a system. Finally, there is a family of formal methods and languages that have a great success and are continuously equipped with new features and useful tools. even if combinations of these languages with other methods have been also proposed, they cannot be used in a natural and simple way for the speci cation of reactive and concurrent systems. B ([5]) is a formal method for the development of program code from a speci cation in the Abstract Machine Notation. It includes tool support (for example: a proof obligation veri cation tool, a translator into current programming language, a graphical interface) and has been used in signi cant industrial applications. Quite similar to B are Z (see [28]) and VDM languages (and their extensions) that are employed in industrial applications but they can be devised only for sequential systems and implementations with imperative languages.

OO Methodologies OO methodologies are informal approaches to soft-

ware development that, however, have been used for the develpment of many industrial applications. An overall object oriented approach to software engineering (see [7], [10]) is justi ed by some reasons: OO strongly promotes reusability, forces the introduction and makes more easy the use of concepts like encapsulation, data abstraction and information hiding. New items related to OO technology, that are introduced in software engineering are: object-oriented analysis (OOA), object-oriented design (OOD), object-oriented requirement analysis (OORA), object oriented programming (OOP). The OOA [11] is the study of a problem domain and leads to the identi cation of objects and classes, de nes attributes and "services" (functionalities of objects and classes, and connections among them. The model produced by OOA is presented in several layers by using graphical notations. The OOD [12] identi es and de nes additional classes and objects that are the implementation of requirements and relations given in the OOA model. While OOA is programming language independent, detailed OOD is largely programming language dependent. All OO methodologies are completely informal, lack in the description of very abstract requirements and give no support for the veri cation phase; 15

however, they can give very helpful hints for a graphical presentation of design speci cation and for low-level design speci cations that must be coded into an OO programming language.

3.1.2 Correctness and Veri cation Even if many times the two terms veri cation and validation are used interchangeably, this is not the case. Bohem in [9] describes the dierence by these sentences: Veri cation: "are we building the product right?" Validation:"are we building the right product?" From our point of view, we can reformulate the above de nitions by saying that Veri cation of a speci cation try to establish its conformity and correctness w.r.t. another (more abstract) one, while Validation of the speci cation try to establish if the speci cation correctly describes the system at a given level of abstraction, if, for example, some interesting properties can be proved to be true. Growing interest in veri cation yielded to the development of many supporting tools, that can be grouped into two classes, representing two orthogonal approaches: model checkers and theorem provers. In the theorem proving approach to veri cation, a system and its properties are described by means of logical formulae and the system is shown to entail the desired properties by means of logical proofs; though automated theorem proving tools has been successfully employed, they have inherent limits in eciency when try to mechanize expressive logics. Since it is very complex to implement completely automated procedures, interactive theorem provers combine a limited form of automated deduction with user guidance. On the other side, model checking provides a fully automatic technique for deciding wether many classes of properties hold over a model. Validity of formulas (also temporal logic formulas) is determined by analysing a model that is a nite automata (or an abstraction of a class of models). The main advantages are that the checking procedure is completely automatic and the algorithm always terminates, either by saying the the property is satis ed or by returning a counterexample. Model checking is remarkably eective for automatically verifying nite automata with relatively small state spaces, but is inadequate when the state spaces are either too large or unbounded. For these reasons, the current trend in system veri cation seems to be the research of a intermediate way, a new approach that suitably combine model checking and theorem provers. The more promising tools, not only 16

in in our opinion [24], [30], integrate model checking inside theorem provers (like Step[46] and PVS(see sec.3.2)).

3.1.3 Java Language Many appealing features have favored the increasing popularity of Java in the industrial world. Also the academic world seems to be interested in it, but, nowadays, no formal semantics has been given to Java. Drossopolou and Eisenbach in [41] proof correctness of Java type system, also giving a semantics to a small sublanguage of Java. A semantics more focused on multi-threading programming in Java is currently investigated by Cenciarelli and al. and has been presented at the WADT workshop in Tarquinia, last summer. At the same time, no method or speci cation technique (formal or informal) have been proposed for the development of systems to be coded into Java, so this seems to be a completely new and promising eld to be explored. The interest for Java, for the moment, is more concentrated on improvements and extensions of the language. Some ideas from academic have been incorporated in superlanguage of Java, Pizza ([32]), that describes how parametric polymorphism, higher order function and algebraic data types can be translated into Java. Moreover, Java can be extended to support feature oriented programming [37],[13]: a new paradigm based on abstraction on system behavior that seems to be promising to make easier both modi cations and enhancements of programs.

Java in the Real World The Gilder Technology Report (as reported by

Sun at [3]), released in October 1996, estimated that more than 200,000 professional programmers were using Java, including one-third of all the enterprise developers at companies with more than 5000 employees. Colleges and universities are adopting Java as a teaching language, including courses on operating systems design and client/server applications development. The most of Java programs developed by enterprises are applets for accessing and retrieving information from the corporate database or for the electronic commerce. American Information System, considering the issues of cross-platform compatibility, intuitive graphical user interface and real-time interactivity selected Java to produce a state-of-the-art conferencing system. Telecommunication industry has created a forum for discussing the use of Java as a distributed object oriented language and started collaborations with academic world: Technical University of Berlin is currently involved in 17

the \Java Based Intelligent Agents for Telecommunication Applications" that uses Java distribution features for a large real application.

3.2 Starting Points

Speci cation languages and method Algebraic speci cation languages as [6] and methodological approaches and ideas for requirements and design speci cations as developed over past years at the University of Genova seem to be a good starting point for our work. We are planning to follow the idea that a reactive or concurrent system can be modeled by a labeled transition tree, whose nodes are decorated by states and arcs are decorated by labels. States represent intermediate interesting situations of the system, arcs in the tree represent transitions, that is capabilities of passing from a state to another, where the label of the arcs describe the interactions with the external environment that determine (or are consequence of) the transition. Many aspects of this approach seem to be adequate for a method that leads to a codi cation of a system into Java code. By decomposition of speci cations, complex systems are decomposed into more simple subcomponents, furthermore there is a distinction among \active" and \passive" components, Representation of communication among components by means of interactions seems to be more adequate then other techniques (like streams and so on). For what concerns speci cation languages, since conditional rst-order axioms are not powerful enough to express requirements on concurrent-reactive systems, other logics (as temporal branching-time logics [20], logics with deontic operators [19]) are used. We have to investigate which could be a good choice for requirements and design languages for speci cations that will be implemented by Java. Friendly presentation In [31] it is presented a graphical notation that is the graphical counterpart to textual speci cation developed using an algebraic speci cation language. This notation associates with a speci cation several views corresponding to activities required by guidelines of the speci cation method. For example, it is possible to give a drawing for the view that represents static data types, another one for hierarchical relations among basic data, or for visualize intermediate states and interactions of a component. This notation has big advantages as readability, compactness, understandability and is very useful to have an informal check for the textual presenta18

tion. By examining drawings, it is possible to detect mistakes and omission made in the speci cation. At the moment, a graphical notation has been presented only for supporting the design phase; we would like to support every phase of the method with a graphical presentation and with the use of natural language too.

PVS Since our systems are potentially very complex, like reactive systems

exchanging informations with the outside environment, the nite state limitation of model checking forces us to prefer a theorem proving approach. Moreover, we need to use a tool supporting a very expressive and rich logic for specifying complex properties as liveness and reactivity ones. PVS stands for "Prototype Veri cation System", an environment for speci cation and automated veri cation based on higher-order logic, developed at SRI ([14]). Primarily it consists of a speci cation language ([44]) and a theorem prover([42]) that is founded on a sequent calculus system. In order to make proofs easier, it provides a collection of powerful proof commands, that can also be combined into proof strategies or tacticals. Model checking capabilities are used for automatically verifying simple properties involving nite data types: the automation takes care of the details and frees the user to concentrate on more complex steps. From our point of view, it is really a great bene t that PVS also include parameterized theories and mechanism for de ning abstract data-types. It can be used both for validation and for veri cation activities. We chose PVS for some reasons, namely:  it is based on higher-order logic; this is very promising to be used for proving temporal properties; we need to have a higher order logic in which translate temporal properties on system behavior;  proof commands are very powerful and can be used to de ne \ad hoc" strategies (tacticals); we would like to associate tacticals with the most common properties in system speci cations or, at least, to describe proof strategies successfully for certain kind of formulas;  new types, also subtypes or data type constructors can be declared and then axioms about them postulated; this makes very easy to translate abstract data type speci cations of our method into PVS syntax.  there are constructors for parameterized theories as well as operations to compose, enrich and hide (parts of) theories. 19

Compared with HOL ([35],[21]),and Isabel ([36]), PVS seems to be much simpler to be used; this is a very important point, since we want to use PVS in a complex method for users that cannot spent to much time in learning a very complex tool. PVS speci cation language has declaration, module constructors, while HOL theories are created by applying ML functions. Isabelle is a generic prover intended to provide an environment to create theorem proving support for arbitrary logics. It's a very powerful tool, but perhaps its generality makes it much more complex to be used. PVS has been used for veri cation of hardware systems [33], secure systems, distributed algorithms, for validation of requirement speci cation, in the veri cation of formal solution to case studies [23]. It is important to remark that in all these applications, both the speci cation and the proof are \ad hoc" for each particular case. It has not been considered, till now, the importance of giving general guidelines to the users explaining how to use the speci cation language and the rules or prede ned tacticals.

4 Research Plan In this section we want to illustrate the research tasks we are planning to explore in this thesis. In g.1 are summarized the main one. Arrows describe an information exchange between two phases. For each tasks we give the activities in which it can be decomposed. They are not ordered.

Java   

To analyse Java language features (especially w.r.t. concurrency and distribution); to choose a sublanguage adequate to the kind of applications we are interested in; to give an abstract operational semantics to the sublanguage; there is no reference to other authors works (except for [41]), since no Java semantics, covering features we are interested in, has been presented till now. In this phase we also plan to investigate which Java features we can abstract from.

20

Java analysis semantics

Requirements spec. language method description friendly notation Correctness correctness design spec w.r.t. requirement spec. use of verification tool Design spec. language method description friendly notation

Case Studies finding case studies development Coding correctness w.r.t. design spec. code generation

is a causality relation when a task requires some result of another task is a weak relation, when a task can be influenced by another one used to describe that the case studies are developped in parallel with other tasks and can have a feedback on them

Figure 1: Research Phases Schema

Requirements   

To develop guidelines to determinate the relevant requirements (w.r.t. the class of target applications to be speci ed); to give a requirements speci cation language adequate for the properties of the systems; to investigate a user friendly notation for such language; we would also develop a non-textual notation;

Design 21

    

To investigate the impact of Java on the method in the design speci cation phase; to check if the design speci cation is adequate w.r.t.the requirements; to nd out which choices at design step cannot be done since cannot be implemented into Java; to give a design speci cation language; to investigate a user friendly syntax for the design language; we would like also to develop a non-textual notation; notations (textual and graphical) should be homogeneous to the ones produced in Requirements.

Correctness   

To give notions of correctness of the design speci cation w.r.t. the requirements one (provided following the method); to give guidelines for proving correctness; to analyse the PVS to support veri cation, focusing on: { a translation of our speci cation languages into the PVS speci cation language; { how to use PVS to support the veri cation of speci cations; we plan to investigate what rules and prede ned tacticals can be more useful for the proof of properties found in the requirements speci cation. Probably, it would be helpful to de ne \ad hoc" tacticals for the kind applications we consider.

Coding  



To nd out a notion of correctness-preserving implementation of design speci cation into a Java program; to investigate how to translate a design speci cation into Java code. We plan to nd out some \coding schemas" relating design architectural choices and design axioms into to Java implementations. to proof the correctness of the automatic encoding, so that it is not necessary to proof the correctness of each Java program developed using the method. 22

Case Studies

In this phase we plan to individuate at least one meaningful case study that could be helpful:  to prove the usability of the method on a \non toy" examples;  to have a feedback in every phase of our work;  to show the user how to apply every step of the method and how to use the tools and guidelines on a real case.

References [1] Workshop on Formal Design of Safety Critical Embedded System. April 1997. Munich, Germany. [2] IBM's Research's Aglets Workbench Home Page http://www.trl.ibm.co.jp/aglets. [3] Sun Home Page : http: //java.sun.com/realworld.html. [4] Z.100 ITU: Speci cation and Design Language SDL. Technical report, ITU, Geneva, 1993. [5] J.R. Abrial. Assigning Programs to Meanings. Cambridge University Press, 1993. [6] E. Astesiano and G.Reggio. Labelled transition logic: an outline. Technical Report DISI-TR-96-20, DISI, Universita di Genova, 1996. [7] E. Berard. Essays on Object-Oriented Software Engineeering, volume 1. Prentice Hall, 1993. [8] Daniel M. Berry. Whither Formal Methods? In 1994 Monterey Workshop: Increasing the Pratical Impact of Formal Methods for Computer Aided Software Development, 1994. [9] B. Boehm. Software Engineering Economics. Prentice Hall, 1981. [10] G. Booch. Object Oriented Analysis and Design. Benjamin Cummings, Santa Clara, California, second edition, 1994. [11] P. Coad and E. Yourdon. Object-Oriented Analysis. Yourdon Press computing series. Prentice Hall, 1991. 23

[12] P. Coad and E. Yourdon. Object-Oriented Design. Yourdon Press computing series. Prentice Hall, 1991. [13] C.Prehofer. Feature-Oriented Programming: a Fresh Look at Objects. In Proceedings of ECOOP'97. Springer Verlag-LNCS, 1997. [14] Judy Crow, Sam Owre, John Rushby, N.Shankar, and M.Srivas. A Tutorial Introduction to PVS. Computer Science Laboratory-SRI Intrenational, April 1995. [15] D.Harel. Statecharts: a visual formalism for complex systems. Science of Computer Programming, (8), 1987. [16] F.Mazzanti G.Reggio E. Astesiano, A. Giovini and E.Zucca. The Ada Challenge for New Formal Semantic Techniques. In Ada: Managing the Transitions, Proc. of the Ada-Europe International Conference, pages 239{248. Cambridge University Press, Edinburgh, 1986. [17] G. Reggio E. Astesiano. Formalism and Method. In M.Duchet M. Bidoit, editor, Proc. TAPSOFT'97, pages 93{114, Berlin, 1997. Springer Verlag. [18] E.Astesiano and G.Reggio. Formally-driven friendly speci cation of concurrent systems: a two-rail approach. Technical Report DISI-TR-94-20, DISI- Universita di Genova, Italy, 1994. Presented at ICSE'17-Workshop on Formal methods,1995. [19] E.Coscia and G.Reggio. Deontic concepts in the algebraic speci cation of dynamic systems: the permission case. In M. Haveraaen, O.Owe, and O-J. Dahl, editors, Recent Trends in Data Type Speci cations, pages 161{181, Oslo, Norway, September 1995. Springer Verlag. [20] G.Costa and G.Reggio. Speci cation of abstract dynamic data types: a temporal logic approach. TCS, (173), 1987. to appear. [21] Mike Gordon. Notes on pvs from a hol perspective. August 1995. [22] Yuri Gurevich. Evolving Algebras 1993: Lipari Guide, chapter Speci cation and Validation Methods, pages 9{36. Oxford University Press, 1995. [23] J. Hooman. Using pvs for an assertional veri cation of the rpc-memory speci cation problem. In K. Spies M. Broy, S. Merz, editor, Formal System Speci cation: the RPC-Mmeory Speci cation Case Study, pages 275{304. Springer Verlag, 1996. 24

[24] Hardi Hungar. Combining model checking and theorem proving to verify parallel processes. In Costas Courcoubetis, editor, Computer Aided Veri cation, pages 154{165, Elounda, Greece, June/July 1993. LNCS 697. [25] M. Jackson. Software Requirements Speci cations. ACM Press Books. Addison Wesley, 1995. [26] Michael Jackson. The meaning of requirements. 1996. [27] J.Goguen and Luqi. Formal methods and social context in software development. In M.I.Schwartzbach P.D. Mosses, M. Nielsen, editor, Proc. of TAPSOFT '95, pages 62{81, Berlin, 1995. LNCS 915, Springer Verlag. [28] J.M.Spivey. Understanding Z: a Speci cation Language and its Formal Semantics. Cambridge University Press, 1988. [29] S. Kleuker. Formalizing requirements for distributed systems with trace diagrams. In C.B. Jones J.Fitzgerald and P.Lucas, editors, Proc FME '97, pages 102{121, Berlin, September 1997. LNCS 1313, Springer Verlag. [30] R. P. Kurshan and L.Lamport. Veri cation of a multiplier: 64 bits and beyond. In Costas Courcoubetis, editor, Computer Aided Veri cation '93, page 165.. LNCS 697, June/July 1993. [31] G. Reggio M. Larosa. A graphic notation for formal speci cations of dynamic systems. In Cli B. Jones J.Fitzgerald and P.Lucas, editors, FME '97: Industrial applications and Strenghtned Foundations of Formal Methods, Graz, Austria, September 1997. 4th. International Symposium of Formal Methods Europe, Springer Verlag. [32] P. Wadler M. Odersky. Pizza into java: Traslating theory into practice. In 24th ACM Symposium on Principles of Programming Languages, Paris, France, January 1997. [33] S. P. Miller and M. Srivas. Formal veri cation of the aamp5 microprocessor: A case study in the industrial use of formal methods. In WIFT '95: Workshop on Industrial-Strength Formal Speci cation Techniques, Boca Raton, Florida USA., April 1995. [34] M.Jackson. Problem complexity. In Proceedings Third IEEE Conference on Engineering of Complex Systems, pages 239{248, Como, Italy, September 8-12 1997. 25

[35] T.F.Melham M.J.C. Gordon, editor. Introduction to HOL: a Theorem Proving Environment for Higher-Order Logic. Cambridge University Press, Cambridge,UK, 1993. [36] Lawrence C. Paulson. Introduction to Isabelle. Computer LaboratoryUniversity of Cambridge, 1996. [37] Christian Prehofer. An object-oriented approach to feature interaction. In P.Dini, editor, Fourth IEEE Workshop on Feature Interactions in Telecommunications Networks and Distributed Systems. IOS-Press, 1997. [38] G. Reggio. Event logic for specifying abstract dynamic data types. In M.Bidoit and C. Choppy, editors, Recent Trends in Data Types Speci cation, pages 292{309, Berlin, 1993. LNCS 655, Springer Verlag. [39] Wolfgang Reisig. Petri Nets : an introduction. EATCS Monographs on Thoretical Computer Science. Springer Verlag, 1982. [40] Roger s. Pressman. Software Engineering: a practitioner's approach. MGraw Hill, third edition, 1994. [41] S. Eisenbach S.Drossopoulou. Java is type safe- probably. 11th European Conference on Object Oriented Programming, June 1997. to be published. [42] N. Shankar, Sam Owre, and John Rushby. The PVS Proof Checker: A Reference Manual (Beta Release). Computer Science Laboratory-SRI International, March 1993. [43] Ian Sommerville. Software Engineering. Addison-Wesley Publishing Company, third edition edition, 1989. [44] S.Owre, N.Shankar, and J.M.Rushby. The PVS Speci cation Language (Beta Release). Computer Science Laboratory- SRI Intrenational, April 1993. [45] U.S. Naval Postgraduate School, Monterey, California. 1994 Monterrey Workshop: Increasing the Pratical Impact of Formal Methods for Computer-Aied Software Development: Software Evolution., September 1994. [46] N. Bjorner A. Browne Z. Manna, A. Anuchitanukul. Step: the stanford temporal prover. Technical report, Department of Computer Science, Stanford University, June 1994. 26