- Email: [email protected]
PROOFS: Application engineering based on formal methods
Microprocessing and Microprogramming35 (1992)29-36 North-Holland
29
PROOFS: Application Engineering Based on Formal Methods Kees van Hee", Theodor Hildebrand" and Sergio CopelJi"" Technical University of Eindhoven, The Netherlands SLIGOS, Paris, France PRISMA, Florence, Italy
The objective of the PROOFS project is to show that formal methods, are useful for.the development of distributed industrial applications. Several application areas have bean te,ken into account. A common feature of the selected applications is that they are heterogeneous, distributed systems. Since different aspects of a system have to be deecrihnd and analyzed, different formalisms should be used. Instead of defining a new integrated formalism that covers all the aspects, in PROOFS guidelines are developed to integrate in a coherent way several existing formalisms. As a consequence 'linking' of formalisms and related methods and tools will be attempted instead of 'merging' them. In this paper we give an overview of the project as a whole, of the applications we have chosen to test formal techniques and of the problems of linking formalisms, methods and supporting tools. 1.
SYNOPSIS OF PROOFS
We strongly believe that we reached the borders of the domain of applications that can be developed using only intuitive or informal methods. Complex applications, such as distributed systems for teleshopping, banking or logistic control systems fall outside this domain. If we still try to develop these systems using only informal or exclusively semiinformal methods we may expect to get systems that are unreliable, badly maintainable and that will not fulfill the system requirements of the customers. Formal methods have been proposed to support the development of complex applications. However, so far formal methods have been used only for case studies of reduced size and only in application areas well.suited for the chosen technique. 1.1.
Selection of formal methods
tf we start looking for formal methods that may help to develop complex applications, we discover that there are no methods that cover the whole development cycle of an application, and even for the specification phase there is no method covering all the system aspects. Therefore it has been decided in the PROOFS project to choose several methods that cover different aspects of system specification and to link them.
This is not at all an easy task, because the formalisms are based on different para,digms o! a system. In fact these paradigms consider different aspects of systems. A formalism consists of a mathematical model and a language, the semantics of which is expressed in terms of the model. Examples of formalisms are data models like the relational model. Petri nets and process algebra. In this sense methods are procedures and heuristics to use formalisms, although we use the term 'method' also as a generic term for formalisms and methods. So the first task in linking methods is to unify different formalisms. This means that we have to map concepts of one formalism to concepts of another or we have to introduce new concepts in an existing formalism. After linking formalisms one can link the methods based on these formalisms. Nowadays many methods are supported by software tools. Some experts claim that methods without supporting tools are useless in practice. So alter linking of methods the next step is linking of tools (el. section 3). 1.2. Use of formal methods In the PROOFS project we focus on formal specification techniques (FST). The reason for this choice is two-fold. Firstly we have to restrict us, because the whole development cycle is too large to be covered in this pro ect and secondly we believe that the specification phase is one of the
30
K. van Hoe et a/.
most critical phases, since errors made in this phase are costly to repair and most failures in existing applications are due to specification errors (cf. Boehm 81). To test the integrated formalisms, methods and tools, we have chosen several complex applications. For these applications we will develop formal specifications. To check if these specifications are 'good' we have to vedfy them on internal consistency and we have to validate them with respect to the user requirements. As the objective of PROOFS is not so ambitious to produce a new 'super-method', but only to suggest a reasonable integrated usage of existing FST's, verification of a system description will only be partial and related to the analysis techniques belonging to the underlying FST. However, in the PROOFS project we a r e more interested in the exploitation of descriptive power of FST's than of their analytical power. On the other hand, validation of user requirements remains a main issue for the exploitation of FST's, It is impossible to validate a specification formally and therefore it is important to generate a prototype for a specification. Such a prototype can be understood easily and will be extremely helpful for the user to validate specifications. For the designer a prototype is also very useful because it helps in finding errors, Therefore executability of specifications becomes a main requirement for the PROOFS methodology. 1.3.
Domain specific libraries
In addition to the linking activities the PROOFS project has another challenge: the development of domain specific libraries of reusable or generic components. Such components may also be considered as reference models for an application domain. The FST's are i . general application domain irdc#endent which is on the one hand an advantage because they can be applied everywhere. On the other hand this is a disadvantage because the formalisms bare no application domain characteristics which means that the designer has to describe these characteristics for each specific application again. Therefore we will try to build on top of these formalisms libraries of reusable components. An even stronger tuning of the formalisms to application domains is the introduction of domain dependent language components in a specification languages. We will start with the first alternative. The chosen applic~ion domains will be also the test domains for these reusable components. 1.4.
Organization of the project
The workplan of the project which has been scheduled over 4 years, distinguishes tour work packages (in addition to the project management).
The first one is devoted to the linking, and if necessary extending of formalisms and methods. The second one concerns the linking ot tools. Work package three, the largest one, is devoted to the formal specification of several distributed applications and the set up of libraries per application domain. The last work package is called Training and concerns the transfer of knowledge between the partners and from the project to the 'outside' world. Internal training means the transfer of knowledge of formalisms, methods and tools to ti~e application area. The PROOFS project is building on results of other EO and national projects like GRASPIN (EP 125), EXSPECT (Taste, ct. Aalst 89) and IRENA (EU 389) and links to projects like ATMOSPHERE (EP 3565) and DEMON (EP 3148) and some other are being established. At the time this paper was wdtten the project was running for about 18 months. We conclude this section with a list of participants: PRISMA - Italy (coordinating contractor), SLIGOS France, TELESYSTEMES - France, MASI University Paris 6 - France, ERITEL - Spain, TNO (IPL and IT1 institutes) - The Netherlands, Eindhoven University of Technology - The Netherlands. 2.
APPLICATIONS
Here below we give informal descriptions of some applications that have been chosen by the project partners. The interaction between the application developers on the one hand and the method and tool designers on the other hand, are particularly strong within PROOFS. The applications a r e selected according to the following criteria: they must be of economical interest for the companies involved, they must have sufficient features of heterogeneity and distribution, they must have a reasonable degree of independence from business-oriented constraints, such as delivery times and development standards. The initial specifications of the applications a r e informal (which nowadays is almost the standard in the chosen application areas), even though some 'semi-formal' techniques, already proposed in PROOFS, have been used (channel/agency nets). This however cannot be considered an initial attempt to use FST, but only an effort for standardization of both the content and the structure of these initial specifications. The applications selected so far are briefly described below. 2.1.
Credit Management System
31
PROOFS
The CMS is developed by the PROOFS partner PRISMA. It concerns the re-design and development of a pre-existing software package which supports the managementof any sort of credit with a predeflned repayment plan (according to the Italian law). The package will be able to monitor the status of each file during each phase of a loan procedure, from the moment when the client presents a loan application at a bank office to the completion of the repayment. The application will have both distribution and heterogeneity features. The package will have a distributed architecture: its functionalities will be distributed among the central site and the branches of a given bank. Flexibility will be one of the main requirements, to allow the package to be easily integrated in the information system of any small or medium size bank. To improve its flexibility, the package will have a modular architecture, in which interface modules will abstract the core of the package (the functional modules) from any possible environment (Operating System, DBMS, Communications). In addition, the package will support the direct (telematic) connection, where possible, with external information systems, such as City Halls, notary offices, insurance agencies, bank sell- services equipment, post officas. 2.2.
LoansAuthorization System
The LAP (Loans Authorization Prototype) is developed by the PROOFS partner ERITEL. This application can be considered a decision support system, as its aim is to allow a bank or a financial enterprise to perform a fast and homogeneous assessment of the risk related to a client that apply for a loan. The loan granting policy of an institution is based both on the general financial policy of the institution and on the results of previous loans (the percentage of successfully ended loans, divided in categories related to the type of client and the dimension of the loan), To allow a quick adjustment and improvement of the loan granting policy, the LAP application is based on an expert system: the loan policy is implemented through the inference rules of the system. The LAP system has a distributed architecture, with a central 'LAP manager' and several 'LAP agents' which interlace the users of the system. This application can be considered complementary to the previous one (the Credit Management System developed by PRISMA). In fact, the LAP system can be considered as part of the pre-existing bank environment that the CMS application has to interface when managing a loan, 2.3.
Integrated Back Office Demonstrator
The IBOD application is developed by the PROOFS partner SLIGOS. The selected application area is telashopping. During the recant years, more and more proposals for electronic shopping have been launched. The four basic categories of systems currently in operation are: point of sale systems, point of service systems, which are used to have information on products, catalogue based home shopping, whiCh allow to order goods or services from home, name based shopping supported by TV. Looking at electronic shopping as a whole there is a remarkable lack of integration at the technical level for the different types of functionality listed below: information exchange, order entry, payment, after sales support. The role of IBOD in the distributed amhitocfure of a teleshopping system is to connect the end user interface systems to the central server. Usually in a real teleshopping network there are several IBOD nodes, and (in case heterogeneous services are provided) also several servem. A teleshopping system can provide to the end user the following services: consulting, booking, ordering, and paying. The user can both be an 'in home' user or an 'out of home' user. In particular, the system functionalities supported by IBOD are security (access key management, user authentication, data enciphering), protocol adaptation (the end user interface system and the server usually have different communication protocols), routing of information (in a real network the communication between an end user system and a server may require a chain of IBODs), teleloading (i.e. both the down-loading of software at the start up of the system and the down-loading of new software while the system is in service) and telemaintenanca (both network level management and high-level management). 2.4.
DocumentConferencing Application
The DCA system is developed by the PROOFS partner TELESYSTEMES. The application area of interest is office automation. The aim of the application is to allow the concurrent production of different chapters of the same document by several (geographically distributed) authors. The production of a new document is managed by an 'editor in chief' who can create and then destroy the 'conference' related to the document. All the
32
K. van Nee et aL
other authors are connected to the common 'document table' through a 'desk' from where they can send their contribution. Chapters are then integrated by the editor in chief in its private area in the document table, 'Bibliography' is the only area of the document table which can be concurrently updated by the aL'thors. 2.5.
Tool For Operational Management Training
The TOMT application is developed by PROOFS partner IPL-TNO. The application area of interest is logistics. The applic~ion concerns the construction of a too[ with which one can create, for a large variety of logistic situations an interactive simulation system_ With such a simulation system operational managers can be trained to control logistic systems. However it is ve,y expensive to design a simulation system for a specific logistic system and therefore there is a need for a tool that can make these simulation systems relatively quickly. This means that only the specification of the logistic situation, the management rules and the criteria to evaluate the effects of comrol on the logistic system have to be given and that the tool creates a simulation system from these specifications. The distribution aspects of this applicotion relate to the experimental side of a simulation system. It is important that several operational managers can work together in one simulation system. Each manager has its own tasks but these tasks interfere, In this application the idea of reusable components is very important because the tool will crnate specific simulation system using predefined components from a library. 3.
LtNKING OF METHODS
In the context of the application mentioned above, formalisms, methods and tools will be analysed. In this section we consider formalisms first and then we pay some attention to methods. There exist several formalisms to describe aspects of distributed systems. Only recently some integrated frameworks are developed; these frameworks combine several formalisms in a consistent way to be able to describe more aspects of a system in a coherent way. Examples ar.~ LOTUS (DP 8807, 88), Stalemate (Hater 87), Dasign/CPN (Albrecht 88) and ExSpect (Van Hoe 89). Instead of combining we speak of linking formalisms. 3.1.
System Specification
A distributed system has, in our view, three main aspects:
a network of communicating components a state space a set of operations There are two paradigms to consider the relationship between these components. In the 'message passing' paradigm the components have private state variables and they communicate by sending messages to each other. The readiilg and writing of messages as well as the change of their state variables is conducted by the operations of the component. In the 'shared variables' paradigm the components have private and shared state variables. Together we call them the local state variables of the component, Two components communicate by changing their shared state variables. Again this is conducted by the operations of the components. The state space of a system is determined by all the state variables in the system. The two paradigms can be unified if the mail boxes for messages are considered to be shared variables. The 'message passing' paradigm corresponds to the objectoriented paradigm. 3.2.
Formalisms
So it all these aspects are described we have a full specification of a system. We consider the following sets of well-established formalisms to describe the different aspects. To describe networks of communicating components we have: High level Fetri nets and their hierarchical extensions, such as coloured Petri nets (Jensen 87) and ExSpect-model (Van Hee 89), Process algebras such as CCS (Milner 80], CSP (Hoare 85) and ACP (Bergstra 88), Actor models such as the model of Hewitt and Agha (Agha 86). The Petri nets may be considered as a stateoriented approach because the markings of nets are states, while the process algebras are in fact behaviour-oriented since they describe components just Ioy their observable behaviour and they do not consider internal states explicitely. To describe a state space, in particular a ~arge state space we have data models at our disposal. Besides the most spread relational data model from Codd (ct. Utlman 88) we have the entity relationship model of Chen (Chen 76) and several binary data models such as the functional data models (Shipman 8t), (Aerts 90) and the binary model of NIAM (Nijssen 76). However these data models do not have a formal approach to di~;~ribute data over components and their capabilities to describe general operations is poor.
PROOFS To describe operations there are again several different approaches. First of all there are imperative languages but they are considered to be too low level. Operations can be specified in declarative languages such as functional and logical languages in a sufficiently abstract way, although these languages are in tact modern programming languages instead of specification languages. Languages that are typically suited for specification of operations are state-oriented, also called modeloriented, languages like Z (cf. Spivey 89) and VOM (cf. Jones 90) and behaviour-ori~nted, also called algebraic languages such as SEGRAS (cf. GRASPIN) and Act one/two (Ehrig 85i89). In PROOFS we have chosen some of these formalisms to integrate into one framework. For networking these formalisms are: (timed) coloured Petri nets (CPN), as in ExSpect (cf. Van Hee 89). However, we have decided to put an informal but semantically close technique on top of CPN: channel/agency nets (CAN). As a matter of fact, specification and validation of a system can be made easier if the user is directly involved in these activities. However, we cannot expect that an user can easily handle specifications using a formal specification technique. This directly calls for the use of a semi-formal technique such as CAN, perhaps extended with an informal technique such as Object Oriented Design (Booch 86, 91). Extended CAN can both be easily understood by the end user when producing the system specification and be easily refined in CPN to complete the description of the system and to allow formal verification of some properties of the modelled system. Coloured Petri nets belong to the class of high level Petri nets and the channel/agency net formalism is at the moment just a language of graphs and some transformation rules to refine these graphs. However one of the linking activities is to give channel/agency nets a formal semantics in terms of high level Petri nets. In ExSpect there is also a syntax to refine nets and these two ways of refinement will be unified. For state space modelling we have chosen binary data models such as the model in NIAM and functional data models. Because these data models do not differ much from the entity- relationship model, it is easy to translate linking results to this data model too. For the description of operations we have chosen for declarative languages (functional and logical languages) and state-oriented specification languages (Z and VDM). Z and VDM are very close so linking results for one formalism can be translated easily to the other. So we have not chosen for algebraic or behaviour-oriented
33
formalisms for networking and operations. The arguments for our choices are as follows: the formalisms are all state-oriented, i.e. the concept of a state is modelled explicitely. the state-oriented approach seems to be very adequate for data-intensive applications (while the behaviour-oriented approach seems to be typically suited for communication networks). the PROOFS participants are familiar with the chosen formalisms which saves time. The linking activities may be compared to the unification of several mathematical models in physics. However it seems to be more easy than unification in physics because we chose common basic semantics. At the moment we have done several linking experiments and they look promising. First of all we have to remark that the CPN-formalism integrates already network structure, operations and. in a primitive form, state spaces. ExSpect and Oesign/CPN are examples of CPN for which equally named tools are developed. In ExSpect (Van Hoe 89) and Design/CPN (Albrecht 88) there is a typed functional language integrated that allows us to specify types of state variables using a type system and operations using lambda calculus. CPN supports beth paradigms of systems (cf, 3,1). So CPH seems to be a good basis to start from. We distinguish five i;nking activities at the moment. Firstly the linking ( CAN and CPN. The first step is to define the syntax and refinement rules for CAN. The variant of CAN with refinement rules is called RCAN. The next step is to map these RCAN to CPN to give a semantics of RCAN. Secondly the linking of CPN with Z and VDM languages has to be considered, A first step is the replacement of the functional languages of ExSpect and CPWDesign by Z. This gives more freedom to specify cf. (Hee 91b). A next step is to transform Z or VDM operations into the functional languages. Thirdly the linking of the languages Z and VDM with data models has to be done. At this moment some case studies using NIAM and VDI~ are performed (cf. van Bruchem., 91). The fourth linking activity is between CPN and binary data models. A proposal in the form of a twolevel data model is made (Van Hee., 91a), The first level is a binary data model and the second level introduces the concept of a complex entity which is in fact a structured set of entities of a binary data model. Each token in a net will be structured as a complex entity. The fifth linking activity concerns unifying RCAN. and later CPN, with the object-oriented paradigm. Although a network component in RCAN and CPN
34
K. van Hee et al.
can be viewed as an object, the object-oriented paradigm allows networks with a dynamical recontiguration which is not yet possible in the Petri net formalisms. However the refinement rules of RCAN can be adapted to support some objectoriented features (cf. Di Giovanni 90, 91). 3.3.
Methods
Unkin9 of methcds is another topic. There are many different kinds of methods. Well-known are the project phasing methods, also called w a t e r f a l l m e t h o d s . Every software company has its own variant. In PROOFS we try to use s-CaRT that is used by PROOFS partner SLIGOS to develop and maintain large payment authorisation applications (Hildebrand 90). This method seems to be suited for distributed applications if a Petri net type of modelling is used. s-CaRT has been used to test the GRASPIN tools and is also a basis to the approach chosen in the IRENA project. Of course the method can be adapted to better insights during the course of the project, For data modelling we consider the information analysis approach of NIAM (cf. Nijssen 76) as a starting point. The Petri net formalisms support strongly a process modelling approach which is totally different from a data modelling approach. In the process modelling approach one starts to decompose a system into a network of communicating components, each of which can be relined until one reaches the primitive level that can be further specified by adding types to tokens and operations to transitions. So the state space is described in a late stage in an implicit way. The data modelling approach is to start with a global state space description which will be distributed in a still later stage. It is one of the challenges of the PROOFS project to link these two approaches. 4.
TOOLING AND TRAINING
Although the development time of tools is easily underestimated, it is our believe that formalisms and methods without supporting tools will not be used in practice. Therefore we need tools, even bin the project, to do the applications. Fortunately we do not have to develop tools tram scratch because we have some tools available. For CPN there are at least two tools: Design/CPN and ExSpect, the last one is developed by one of the PROOFS partners (TUE). Another PROOFS partner (MASI) made a Petri net tool for analysis of (colourad) nets, and it is our intention to integrate these tools together. For data modelling we also try to build a facility on top of a
CPN tool, At the moment we restrict us to the UNIX environments and will migrate to PCTE in the future. Tooling is laborious and we have not much capacity in the project to do this. So we cannot afford to make several prototypes which means that we have to be quite certain of the links between the formalisms and methods before we start linking the tools. Training will concern all aspects of the project: training in formalisms, methods and the use of tools. In the first phase training focuses on internal training, i,e. the training of participants of PROOFS in the selected formalisms, methods and existing tools. Later the training activity will be more concentrated on transfer of knowledge to the outside world. 5.
CONCLUSIONS AND WORK TO BE DONE
The linking activities so far showed that integration of formalisms is feasible. For methods we do not have this information yet, but this is not considered as a high risk factor today. Integration of tools, which includes linking and extending tools ;s laborious and should not take too much of our time. In consequence the PROOFS toolkit prototype will probably require re-engineering. The applicability of our formalisms, methods and tools to the chosen industrial applications and the added value of their use is the real critical success factor of the PROOFS project, The measurement of the effect of our approach to the applications is planned. A real experiment, in which the same application software is developed by different but equally skilled designers, one team with our approach and the other one with conventional informal methods is not planned within the project. And even such an experiment gives too few information for a statistical analysis, Therefore we have to look for other measurements. An initial set of requirements for a PROOFS methodology could be: understandability: the methods should De understandable by persons not familiar with FST, usability: which not only relates to FST and methods but also to the supporting environment, quantitative results: both, in terms of reduced development time and increased software quality. Another critical success factor is the library of reusable components. Although we have some experience in similar projects (TASTE, cf. Aalst 89)
PROOFS on this point it is too early to determine a set of components of reasonable size that can be used. ACKNOWLEDGEMENT The authors are grateful to several persons in the PROOFS project for their valuable comments on earlier drafts of this paper, in particularly to R. Di Giovanni and N. Tn~ves. REFERENCES [Aalst. 89]
[Aerts.. 90]
[Agha 86]
[Aguulmine 91]
[Albrecht.. 88]
[Bergstra., 84]
[Bergstra.,86]
W.P.M. van der Aalst, M. Voorhoeve, A. Waltmans The Taste project Proceedings of the 10th International Conference on Applications and Theory of Petri Nets, Bonn, 1989. A.T,M. Aerts, P,M,E, De Bra, K.M. van Hee Combining the functional and relational mode/ Proceeding of Computing Science in the Netherlands, SMC, Amsterdam, 1990. G.A. Agha Actors. a model of concurrent computation in distributed systems MIT Press, Cambridge Massachusetts, 1986. M. Agoulmine Channel/Agency Nets PROOFS: SLI-tr-0010-WP1-V2,1 K. Albrecht, K. Jansen, R.M. Shapiro CPN Palette Meta Software Corporation, Cambridge Massachusetts, 1983. J.A, Bergstra, J.W. Klop The algebra of recur~ively defined processes and the algebra of regular processes In: J. Paredaens (el), Proceedings 11th ICALP, LCNS 172, Springer, Berlin, pp 82-94, 1984. J,A. B6rgstra, J.W. Klop Algebra of communicating processes In: Proc. CWI. Symposium
35
Mathematics and Computer Science, North Holland, 1986. [Boehm 81] B.W. Boehm Software Engineering Economics Englewood Cl~ffs, Prentice Hall, 1981. [Booch 86] G. Booch Object-Oriented Development IEEE Transactions on Software Engineering, VoL 12, No. 2, February 1986. [Booch 91] G, Booch Object-Oriented Design (with applications) Benjamin Cummings, 1991. [Brauer 80] W. Brauer (ed) Net theory and applications Lecture Notes in Computer Science vol. 84. Springer. Berlin, t 980. [Bruchem.. 91J M. van Bruchem, K.J.G.J. Kok, N.E. van Oosterom Initial ideas about linking PROOFS: ITI-ME-0001-vl.0w1,1. [Chert 76] P,P. Chen ACM Trans. on Database Systems t, lop 9-36, 1976. [Di Giovanni.. 90] R, Di Giovanni, P.L. lachini HOOD and Z for the development of complex software systems In: VDM'90. VDM-Z-Forrnal methods in software development, LNCS 428, Springer, 1990. [Di Giovanni,. 91] R. Di Giovanni Software engineering concepts and C/A Nets PROOFS: PRI-TR-OOO7-WP1 [DP 8807 rev 88] LOTOS:afonnaldesoription technique based on temporal ordering of observational behaviour ISO, Geneva. 1988. [Ehrig.. 85,89] H. Ehrig, 13. Mahr Fundamentals of algebraic specification 1 & 2 EATCS monographs on theoretical computer science. Springer 1985. 1989.
36
[C-.-.-.-n~rich.. 81] [GRASPIN] [Hee.. 89]
[Hee.. 91a]
K. van Hee et el.
H.J. Gendch, K. Lautenbach Theor. Comp. ScL 13, pp 109136, 1981. Esprit project GRASPIN P125. K.M. van Hee, L.J. S~mers, M. Voorhoeve Executable specifications for distributed information systems In: Information System Concepts: an in-depth analysis, NorthHolland, 1989.
K.M. van Hee, P.A.C. Verkoulen Integration of a data mode; and high-level Petri netu Proceedings 12th International Conference on Applications and Theory of Petri Nets, 1991. [Hee.. 91b] K.M, van Hee, L.J. Somers. M. Voorhoeve Z and high level Petri nets PROOFS: "l-t..IE-tr-0005-v1,0-wpl [Hildebrand 85] 1". Hi~ebrand Design and programming of interfaces for monetic applications using Petri nets In: Advances in Petri nets 84, LNCS vol. 188, G. Rozenberg (ed), Springer, Berlin, pp 198-214, 1985. [Hildebrand.. 90] 1-. Hildebrand, N, Tr S-CORT: A method for the development of electronic payment systems In: Advances in Petd nets 89, LNCS vol. 424, G. Rozenberg (ed), Springer, Berlin, pp 262280 1990. [Hoare 85] C.AR, Hoare Communicating sequential processes Prentice Hall, London, 1985. [Jensen 87] K. Jensen Coloured Petd nets in: G. Rosenberg (ed), Petri nets: central models and their properties, LCNS 188, Springer, Berlin, pp 248-299, 1987. [Jones 90] C.B. Jones Systematic software development using VDM (2e ed), Prentice Hall, 1990.
[MUner 80]
[Nijssen 76]
[Oberquelle 80]
[Pel~ 80]
[Reisig 87]
[Ross.. 77]
[SADT 82] [Shipman 81]
[Spivey 89] [UIIman 88]
R. Milner A calculus of communicating systems LNCS 92, Springer, Berlin, 1990. G,M. Nijssen (ed) Modelling in database management systems North Holland, 1976. H. Oberquel[e Nets as tool in teaching and in terminology work In: [Brauer 80], pp 481-506, 1980. C.A. Petri Introduction to general net theory In: W. Brauer (ed), Net theory and applicalions, LCNS 84, Springer, Berlin, pp 1-20, 1980, W. Reisig Petri nets in software engineering In: Petri nets: applications and relationships avec lee rs6eaux C/A Internal report DRDT/ALN89/023, SLIGOS, Direction Technique, Puteaux, 1989. B.T. Ross, K.E. Schoman Structured Analysis for Requirements Definition IEEE Transactions on Software Engineering SE 3(1), pp 6-15, 1977. Institut de Gnie Logiciel SADT: Guide d'auteur Document SADT, 1962. D. Shipman The functional datamodel and the data language DAPLEX ACM Transitions on Database Systems 6:1, 1981 J.M. Spivey The Z notation Prentice Hall, 1989. J.D, UIIman Principles of database and knowledge-base systems Computer Science Press, Rockville Md. 1988.
29
PROOFS: Application Engineering Based on Formal Methods Kees van Hee", Theodor Hildebrand" and Sergio CopelJi"" Technical University of Eindhoven, The Netherlands SLIGOS, Paris, France PRISMA, Florence, Italy
The objective of the PROOFS project is to show that formal methods, are useful for.the development of distributed industrial applications. Several application areas have bean te,ken into account. A common feature of the selected applications is that they are heterogeneous, distributed systems. Since different aspects of a system have to be deecrihnd and analyzed, different formalisms should be used. Instead of defining a new integrated formalism that covers all the aspects, in PROOFS guidelines are developed to integrate in a coherent way several existing formalisms. As a consequence 'linking' of formalisms and related methods and tools will be attempted instead of 'merging' them. In this paper we give an overview of the project as a whole, of the applications we have chosen to test formal techniques and of the problems of linking formalisms, methods and supporting tools. 1.
SYNOPSIS OF PROOFS
We strongly believe that we reached the borders of the domain of applications that can be developed using only intuitive or informal methods. Complex applications, such as distributed systems for teleshopping, banking or logistic control systems fall outside this domain. If we still try to develop these systems using only informal or exclusively semiinformal methods we may expect to get systems that are unreliable, badly maintainable and that will not fulfill the system requirements of the customers. Formal methods have been proposed to support the development of complex applications. However, so far formal methods have been used only for case studies of reduced size and only in application areas well.suited for the chosen technique. 1.1.
Selection of formal methods
tf we start looking for formal methods that may help to develop complex applications, we discover that there are no methods that cover the whole development cycle of an application, and even for the specification phase there is no method covering all the system aspects. Therefore it has been decided in the PROOFS project to choose several methods that cover different aspects of system specification and to link them.
This is not at all an easy task, because the formalisms are based on different para,digms o! a system. In fact these paradigms consider different aspects of systems. A formalism consists of a mathematical model and a language, the semantics of which is expressed in terms of the model. Examples of formalisms are data models like the relational model. Petri nets and process algebra. In this sense methods are procedures and heuristics to use formalisms, although we use the term 'method' also as a generic term for formalisms and methods. So the first task in linking methods is to unify different formalisms. This means that we have to map concepts of one formalism to concepts of another or we have to introduce new concepts in an existing formalism. After linking formalisms one can link the methods based on these formalisms. Nowadays many methods are supported by software tools. Some experts claim that methods without supporting tools are useless in practice. So alter linking of methods the next step is linking of tools (el. section 3). 1.2. Use of formal methods In the PROOFS project we focus on formal specification techniques (FST). The reason for this choice is two-fold. Firstly we have to restrict us, because the whole development cycle is too large to be covered in this pro ect and secondly we believe that the specification phase is one of the
30
K. van Hoe et a/.
most critical phases, since errors made in this phase are costly to repair and most failures in existing applications are due to specification errors (cf. Boehm 81). To test the integrated formalisms, methods and tools, we have chosen several complex applications. For these applications we will develop formal specifications. To check if these specifications are 'good' we have to vedfy them on internal consistency and we have to validate them with respect to the user requirements. As the objective of PROOFS is not so ambitious to produce a new 'super-method', but only to suggest a reasonable integrated usage of existing FST's, verification of a system description will only be partial and related to the analysis techniques belonging to the underlying FST. However, in the PROOFS project we a r e more interested in the exploitation of descriptive power of FST's than of their analytical power. On the other hand, validation of user requirements remains a main issue for the exploitation of FST's, It is impossible to validate a specification formally and therefore it is important to generate a prototype for a specification. Such a prototype can be understood easily and will be extremely helpful for the user to validate specifications. For the designer a prototype is also very useful because it helps in finding errors, Therefore executability of specifications becomes a main requirement for the PROOFS methodology. 1.3.
Domain specific libraries
In addition to the linking activities the PROOFS project has another challenge: the development of domain specific libraries of reusable or generic components. Such components may also be considered as reference models for an application domain. The FST's are i . general application domain irdc#endent which is on the one hand an advantage because they can be applied everywhere. On the other hand this is a disadvantage because the formalisms bare no application domain characteristics which means that the designer has to describe these characteristics for each specific application again. Therefore we will try to build on top of these formalisms libraries of reusable components. An even stronger tuning of the formalisms to application domains is the introduction of domain dependent language components in a specification languages. We will start with the first alternative. The chosen applic~ion domains will be also the test domains for these reusable components. 1.4.
Organization of the project
The workplan of the project which has been scheduled over 4 years, distinguishes tour work packages (in addition to the project management).
The first one is devoted to the linking, and if necessary extending of formalisms and methods. The second one concerns the linking ot tools. Work package three, the largest one, is devoted to the formal specification of several distributed applications and the set up of libraries per application domain. The last work package is called Training and concerns the transfer of knowledge between the partners and from the project to the 'outside' world. Internal training means the transfer of knowledge of formalisms, methods and tools to ti~e application area. The PROOFS project is building on results of other EO and national projects like GRASPIN (EP 125), EXSPECT (Taste, ct. Aalst 89) and IRENA (EU 389) and links to projects like ATMOSPHERE (EP 3565) and DEMON (EP 3148) and some other are being established. At the time this paper was wdtten the project was running for about 18 months. We conclude this section with a list of participants: PRISMA - Italy (coordinating contractor), SLIGOS France, TELESYSTEMES - France, MASI University Paris 6 - France, ERITEL - Spain, TNO (IPL and IT1 institutes) - The Netherlands, Eindhoven University of Technology - The Netherlands. 2.
APPLICATIONS
Here below we give informal descriptions of some applications that have been chosen by the project partners. The interaction between the application developers on the one hand and the method and tool designers on the other hand, are particularly strong within PROOFS. The applications a r e selected according to the following criteria: they must be of economical interest for the companies involved, they must have sufficient features of heterogeneity and distribution, they must have a reasonable degree of independence from business-oriented constraints, such as delivery times and development standards. The initial specifications of the applications a r e informal (which nowadays is almost the standard in the chosen application areas), even though some 'semi-formal' techniques, already proposed in PROOFS, have been used (channel/agency nets). This however cannot be considered an initial attempt to use FST, but only an effort for standardization of both the content and the structure of these initial specifications. The applications selected so far are briefly described below. 2.1.
Credit Management System
31
PROOFS
The CMS is developed by the PROOFS partner PRISMA. It concerns the re-design and development of a pre-existing software package which supports the managementof any sort of credit with a predeflned repayment plan (according to the Italian law). The package will be able to monitor the status of each file during each phase of a loan procedure, from the moment when the client presents a loan application at a bank office to the completion of the repayment. The application will have both distribution and heterogeneity features. The package will have a distributed architecture: its functionalities will be distributed among the central site and the branches of a given bank. Flexibility will be one of the main requirements, to allow the package to be easily integrated in the information system of any small or medium size bank. To improve its flexibility, the package will have a modular architecture, in which interface modules will abstract the core of the package (the functional modules) from any possible environment (Operating System, DBMS, Communications). In addition, the package will support the direct (telematic) connection, where possible, with external information systems, such as City Halls, notary offices, insurance agencies, bank sell- services equipment, post officas. 2.2.
LoansAuthorization System
The LAP (Loans Authorization Prototype) is developed by the PROOFS partner ERITEL. This application can be considered a decision support system, as its aim is to allow a bank or a financial enterprise to perform a fast and homogeneous assessment of the risk related to a client that apply for a loan. The loan granting policy of an institution is based both on the general financial policy of the institution and on the results of previous loans (the percentage of successfully ended loans, divided in categories related to the type of client and the dimension of the loan), To allow a quick adjustment and improvement of the loan granting policy, the LAP application is based on an expert system: the loan policy is implemented through the inference rules of the system. The LAP system has a distributed architecture, with a central 'LAP manager' and several 'LAP agents' which interlace the users of the system. This application can be considered complementary to the previous one (the Credit Management System developed by PRISMA). In fact, the LAP system can be considered as part of the pre-existing bank environment that the CMS application has to interface when managing a loan, 2.3.
Integrated Back Office Demonstrator
The IBOD application is developed by the PROOFS partner SLIGOS. The selected application area is telashopping. During the recant years, more and more proposals for electronic shopping have been launched. The four basic categories of systems currently in operation are: point of sale systems, point of service systems, which are used to have information on products, catalogue based home shopping, whiCh allow to order goods or services from home, name based shopping supported by TV. Looking at electronic shopping as a whole there is a remarkable lack of integration at the technical level for the different types of functionality listed below: information exchange, order entry, payment, after sales support. The role of IBOD in the distributed amhitocfure of a teleshopping system is to connect the end user interface systems to the central server. Usually in a real teleshopping network there are several IBOD nodes, and (in case heterogeneous services are provided) also several servem. A teleshopping system can provide to the end user the following services: consulting, booking, ordering, and paying. The user can both be an 'in home' user or an 'out of home' user. In particular, the system functionalities supported by IBOD are security (access key management, user authentication, data enciphering), protocol adaptation (the end user interface system and the server usually have different communication protocols), routing of information (in a real network the communication between an end user system and a server may require a chain of IBODs), teleloading (i.e. both the down-loading of software at the start up of the system and the down-loading of new software while the system is in service) and telemaintenanca (both network level management and high-level management). 2.4.
DocumentConferencing Application
The DCA system is developed by the PROOFS partner TELESYSTEMES. The application area of interest is office automation. The aim of the application is to allow the concurrent production of different chapters of the same document by several (geographically distributed) authors. The production of a new document is managed by an 'editor in chief' who can create and then destroy the 'conference' related to the document. All the
32
K. van Nee et aL
other authors are connected to the common 'document table' through a 'desk' from where they can send their contribution. Chapters are then integrated by the editor in chief in its private area in the document table, 'Bibliography' is the only area of the document table which can be concurrently updated by the aL'thors. 2.5.
Tool For Operational Management Training
The TOMT application is developed by PROOFS partner IPL-TNO. The application area of interest is logistics. The applic~ion concerns the construction of a too[ with which one can create, for a large variety of logistic situations an interactive simulation system_ With such a simulation system operational managers can be trained to control logistic systems. However it is ve,y expensive to design a simulation system for a specific logistic system and therefore there is a need for a tool that can make these simulation systems relatively quickly. This means that only the specification of the logistic situation, the management rules and the criteria to evaluate the effects of comrol on the logistic system have to be given and that the tool creates a simulation system from these specifications. The distribution aspects of this applicotion relate to the experimental side of a simulation system. It is important that several operational managers can work together in one simulation system. Each manager has its own tasks but these tasks interfere, In this application the idea of reusable components is very important because the tool will crnate specific simulation system using predefined components from a library. 3.
LtNKING OF METHODS
In the context of the application mentioned above, formalisms, methods and tools will be analysed. In this section we consider formalisms first and then we pay some attention to methods. There exist several formalisms to describe aspects of distributed systems. Only recently some integrated frameworks are developed; these frameworks combine several formalisms in a consistent way to be able to describe more aspects of a system in a coherent way. Examples ar.~ LOTUS (DP 8807, 88), Stalemate (Hater 87), Dasign/CPN (Albrecht 88) and ExSpect (Van Hoe 89). Instead of combining we speak of linking formalisms. 3.1.
System Specification
A distributed system has, in our view, three main aspects:
a network of communicating components a state space a set of operations There are two paradigms to consider the relationship between these components. In the 'message passing' paradigm the components have private state variables and they communicate by sending messages to each other. The readiilg and writing of messages as well as the change of their state variables is conducted by the operations of the component. In the 'shared variables' paradigm the components have private and shared state variables. Together we call them the local state variables of the component, Two components communicate by changing their shared state variables. Again this is conducted by the operations of the components. The state space of a system is determined by all the state variables in the system. The two paradigms can be unified if the mail boxes for messages are considered to be shared variables. The 'message passing' paradigm corresponds to the objectoriented paradigm. 3.2.
Formalisms
So it all these aspects are described we have a full specification of a system. We consider the following sets of well-established formalisms to describe the different aspects. To describe networks of communicating components we have: High level Fetri nets and their hierarchical extensions, such as coloured Petri nets (Jensen 87) and ExSpect-model (Van Hee 89), Process algebras such as CCS (Milner 80], CSP (Hoare 85) and ACP (Bergstra 88), Actor models such as the model of Hewitt and Agha (Agha 86). The Petri nets may be considered as a stateoriented approach because the markings of nets are states, while the process algebras are in fact behaviour-oriented since they describe components just Ioy their observable behaviour and they do not consider internal states explicitely. To describe a state space, in particular a ~arge state space we have data models at our disposal. Besides the most spread relational data model from Codd (ct. Utlman 88) we have the entity relationship model of Chen (Chen 76) and several binary data models such as the functional data models (Shipman 8t), (Aerts 90) and the binary model of NIAM (Nijssen 76). However these data models do not have a formal approach to di~;~ribute data over components and their capabilities to describe general operations is poor.
PROOFS To describe operations there are again several different approaches. First of all there are imperative languages but they are considered to be too low level. Operations can be specified in declarative languages such as functional and logical languages in a sufficiently abstract way, although these languages are in tact modern programming languages instead of specification languages. Languages that are typically suited for specification of operations are state-oriented, also called modeloriented, languages like Z (cf. Spivey 89) and VOM (cf. Jones 90) and behaviour-ori~nted, also called algebraic languages such as SEGRAS (cf. GRASPIN) and Act one/two (Ehrig 85i89). In PROOFS we have chosen some of these formalisms to integrate into one framework. For networking these formalisms are: (timed) coloured Petri nets (CPN), as in ExSpect (cf. Van Hee 89). However, we have decided to put an informal but semantically close technique on top of CPN: channel/agency nets (CAN). As a matter of fact, specification and validation of a system can be made easier if the user is directly involved in these activities. However, we cannot expect that an user can easily handle specifications using a formal specification technique. This directly calls for the use of a semi-formal technique such as CAN, perhaps extended with an informal technique such as Object Oriented Design (Booch 86, 91). Extended CAN can both be easily understood by the end user when producing the system specification and be easily refined in CPN to complete the description of the system and to allow formal verification of some properties of the modelled system. Coloured Petri nets belong to the class of high level Petri nets and the channel/agency net formalism is at the moment just a language of graphs and some transformation rules to refine these graphs. However one of the linking activities is to give channel/agency nets a formal semantics in terms of high level Petri nets. In ExSpect there is also a syntax to refine nets and these two ways of refinement will be unified. For state space modelling we have chosen binary data models such as the model in NIAM and functional data models. Because these data models do not differ much from the entity- relationship model, it is easy to translate linking results to this data model too. For the description of operations we have chosen for declarative languages (functional and logical languages) and state-oriented specification languages (Z and VDM). Z and VDM are very close so linking results for one formalism can be translated easily to the other. So we have not chosen for algebraic or behaviour-oriented
33
formalisms for networking and operations. The arguments for our choices are as follows: the formalisms are all state-oriented, i.e. the concept of a state is modelled explicitely. the state-oriented approach seems to be very adequate for data-intensive applications (while the behaviour-oriented approach seems to be typically suited for communication networks). the PROOFS participants are familiar with the chosen formalisms which saves time. The linking activities may be compared to the unification of several mathematical models in physics. However it seems to be more easy than unification in physics because we chose common basic semantics. At the moment we have done several linking experiments and they look promising. First of all we have to remark that the CPN-formalism integrates already network structure, operations and. in a primitive form, state spaces. ExSpect and Oesign/CPN are examples of CPN for which equally named tools are developed. In ExSpect (Van Hoe 89) and Design/CPN (Albrecht 88) there is a typed functional language integrated that allows us to specify types of state variables using a type system and operations using lambda calculus. CPN supports beth paradigms of systems (cf, 3,1). So CPH seems to be a good basis to start from. We distinguish five i;nking activities at the moment. Firstly the linking ( CAN and CPN. The first step is to define the syntax and refinement rules for CAN. The variant of CAN with refinement rules is called RCAN. The next step is to map these RCAN to CPN to give a semantics of RCAN. Secondly the linking of CPN with Z and VDM languages has to be considered, A first step is the replacement of the functional languages of ExSpect and CPWDesign by Z. This gives more freedom to specify cf. (Hee 91b). A next step is to transform Z or VDM operations into the functional languages. Thirdly the linking of the languages Z and VDM with data models has to be done. At this moment some case studies using NIAM and VDI~ are performed (cf. van Bruchem., 91). The fourth linking activity is between CPN and binary data models. A proposal in the form of a twolevel data model is made (Van Hee., 91a), The first level is a binary data model and the second level introduces the concept of a complex entity which is in fact a structured set of entities of a binary data model. Each token in a net will be structured as a complex entity. The fifth linking activity concerns unifying RCAN. and later CPN, with the object-oriented paradigm. Although a network component in RCAN and CPN
34
K. van Hee et al.
can be viewed as an object, the object-oriented paradigm allows networks with a dynamical recontiguration which is not yet possible in the Petri net formalisms. However the refinement rules of RCAN can be adapted to support some objectoriented features (cf. Di Giovanni 90, 91). 3.3.
Methods
Unkin9 of methcds is another topic. There are many different kinds of methods. Well-known are the project phasing methods, also called w a t e r f a l l m e t h o d s . Every software company has its own variant. In PROOFS we try to use s-CaRT that is used by PROOFS partner SLIGOS to develop and maintain large payment authorisation applications (Hildebrand 90). This method seems to be suited for distributed applications if a Petri net type of modelling is used. s-CaRT has been used to test the GRASPIN tools and is also a basis to the approach chosen in the IRENA project. Of course the method can be adapted to better insights during the course of the project, For data modelling we consider the information analysis approach of NIAM (cf. Nijssen 76) as a starting point. The Petri net formalisms support strongly a process modelling approach which is totally different from a data modelling approach. In the process modelling approach one starts to decompose a system into a network of communicating components, each of which can be relined until one reaches the primitive level that can be further specified by adding types to tokens and operations to transitions. So the state space is described in a late stage in an implicit way. The data modelling approach is to start with a global state space description which will be distributed in a still later stage. It is one of the challenges of the PROOFS project to link these two approaches. 4.
TOOLING AND TRAINING
Although the development time of tools is easily underestimated, it is our believe that formalisms and methods without supporting tools will not be used in practice. Therefore we need tools, even bin the project, to do the applications. Fortunately we do not have to develop tools tram scratch because we have some tools available. For CPN there are at least two tools: Design/CPN and ExSpect, the last one is developed by one of the PROOFS partners (TUE). Another PROOFS partner (MASI) made a Petri net tool for analysis of (colourad) nets, and it is our intention to integrate these tools together. For data modelling we also try to build a facility on top of a
CPN tool, At the moment we restrict us to the UNIX environments and will migrate to PCTE in the future. Tooling is laborious and we have not much capacity in the project to do this. So we cannot afford to make several prototypes which means that we have to be quite certain of the links between the formalisms and methods before we start linking the tools. Training will concern all aspects of the project: training in formalisms, methods and the use of tools. In the first phase training focuses on internal training, i,e. the training of participants of PROOFS in the selected formalisms, methods and existing tools. Later the training activity will be more concentrated on transfer of knowledge to the outside world. 5.
CONCLUSIONS AND WORK TO BE DONE
The linking activities so far showed that integration of formalisms is feasible. For methods we do not have this information yet, but this is not considered as a high risk factor today. Integration of tools, which includes linking and extending tools ;s laborious and should not take too much of our time. In consequence the PROOFS toolkit prototype will probably require re-engineering. The applicability of our formalisms, methods and tools to the chosen industrial applications and the added value of their use is the real critical success factor of the PROOFS project, The measurement of the effect of our approach to the applications is planned. A real experiment, in which the same application software is developed by different but equally skilled designers, one team with our approach and the other one with conventional informal methods is not planned within the project. And even such an experiment gives too few information for a statistical analysis, Therefore we have to look for other measurements. An initial set of requirements for a PROOFS methodology could be: understandability: the methods should De understandable by persons not familiar with FST, usability: which not only relates to FST and methods but also to the supporting environment, quantitative results: both, in terms of reduced development time and increased software quality. Another critical success factor is the library of reusable components. Although we have some experience in similar projects (TASTE, cf. Aalst 89)
PROOFS on this point it is too early to determine a set of components of reasonable size that can be used. ACKNOWLEDGEMENT The authors are grateful to several persons in the PROOFS project for their valuable comments on earlier drafts of this paper, in particularly to R. Di Giovanni and N. Tn~ves. REFERENCES [Aalst. 89]
[Aerts.. 90]
[Agha 86]
[Aguulmine 91]
[Albrecht.. 88]
[Bergstra., 84]
[Bergstra.,86]
W.P.M. van der Aalst, M. Voorhoeve, A. Waltmans The Taste project Proceedings of the 10th International Conference on Applications and Theory of Petri Nets, Bonn, 1989. A.T,M. Aerts, P,M,E, De Bra, K.M. van Hee Combining the functional and relational mode/ Proceeding of Computing Science in the Netherlands, SMC, Amsterdam, 1990. G.A. Agha Actors. a model of concurrent computation in distributed systems MIT Press, Cambridge Massachusetts, 1986. M. Agoulmine Channel/Agency Nets PROOFS: SLI-tr-0010-WP1-V2,1 K. Albrecht, K. Jansen, R.M. Shapiro CPN Palette Meta Software Corporation, Cambridge Massachusetts, 1983. J.A, Bergstra, J.W. Klop The algebra of recur~ively defined processes and the algebra of regular processes In: J. Paredaens (el), Proceedings 11th ICALP, LCNS 172, Springer, Berlin, pp 82-94, 1984. J,A. B6rgstra, J.W. Klop Algebra of communicating processes In: Proc. CWI. Symposium
35
Mathematics and Computer Science, North Holland, 1986. [Boehm 81] B.W. Boehm Software Engineering Economics Englewood Cl~ffs, Prentice Hall, 1981. [Booch 86] G. Booch Object-Oriented Development IEEE Transactions on Software Engineering, VoL 12, No. 2, February 1986. [Booch 91] G, Booch Object-Oriented Design (with applications) Benjamin Cummings, 1991. [Brauer 80] W. Brauer (ed) Net theory and applications Lecture Notes in Computer Science vol. 84. Springer. Berlin, t 980. [Bruchem.. 91J M. van Bruchem, K.J.G.J. Kok, N.E. van Oosterom Initial ideas about linking PROOFS: ITI-ME-0001-vl.0w1,1. [Chert 76] P,P. Chen ACM Trans. on Database Systems t, lop 9-36, 1976. [Di Giovanni.. 90] R, Di Giovanni, P.L. lachini HOOD and Z for the development of complex software systems In: VDM'90. VDM-Z-Forrnal methods in software development, LNCS 428, Springer, 1990. [Di Giovanni,. 91] R. Di Giovanni Software engineering concepts and C/A Nets PROOFS: PRI-TR-OOO7-WP1 [DP 8807 rev 88] LOTOS:afonnaldesoription technique based on temporal ordering of observational behaviour ISO, Geneva. 1988. [Ehrig.. 85,89] H. Ehrig, 13. Mahr Fundamentals of algebraic specification 1 & 2 EATCS monographs on theoretical computer science. Springer 1985. 1989.
36
[C-.-.-.-n~rich.. 81] [GRASPIN] [Hee.. 89]
[Hee.. 91a]
K. van Hee et el.
H.J. Gendch, K. Lautenbach Theor. Comp. ScL 13, pp 109136, 1981. Esprit project GRASPIN P125. K.M. van Hee, L.J. S~mers, M. Voorhoeve Executable specifications for distributed information systems In: Information System Concepts: an in-depth analysis, NorthHolland, 1989.
K.M. van Hee, P.A.C. Verkoulen Integration of a data mode; and high-level Petri netu Proceedings 12th International Conference on Applications and Theory of Petri Nets, 1991. [Hee.. 91b] K.M, van Hee, L.J. Somers. M. Voorhoeve Z and high level Petri nets PROOFS: "l-t..IE-tr-0005-v1,0-wpl [Hildebrand 85] 1". Hi~ebrand Design and programming of interfaces for monetic applications using Petri nets In: Advances in Petri nets 84, LNCS vol. 188, G. Rozenberg (ed), Springer, Berlin, pp 198-214, 1985. [Hildebrand.. 90] 1-. Hildebrand, N, Tr S-CORT: A method for the development of electronic payment systems In: Advances in Petd nets 89, LNCS vol. 424, G. Rozenberg (ed), Springer, Berlin, pp 262280 1990. [Hoare 85] C.AR, Hoare Communicating sequential processes Prentice Hall, London, 1985. [Jensen 87] K. Jensen Coloured Petd nets in: G. Rosenberg (ed), Petri nets: central models and their properties, LCNS 188, Springer, Berlin, pp 248-299, 1987. [Jones 90] C.B. Jones Systematic software development using VDM (2e ed), Prentice Hall, 1990.
[MUner 80]
[Nijssen 76]
[Oberquelle 80]
[Pel~ 80]
[Reisig 87]
[Ross.. 77]
[SADT 82] [Shipman 81]
[Spivey 89] [UIIman 88]
R. Milner A calculus of communicating systems LNCS 92, Springer, Berlin, 1990. G,M. Nijssen (ed) Modelling in database management systems North Holland, 1976. H. Oberquel[e Nets as tool in teaching and in terminology work In: [Brauer 80], pp 481-506, 1980. C.A. Petri Introduction to general net theory In: W. Brauer (ed), Net theory and applicalions, LCNS 84, Springer, Berlin, pp 1-20, 1980, W. Reisig Petri nets in software engineering In: Petri nets: applications and relationships avec lee rs6eaux C/A Internal report DRDT/ALN89/023, SLIGOS, Direction Technique, Puteaux, 1989. B.T. Ross, K.E. Schoman Structured Analysis for Requirements Definition IEEE Transactions on Software Engineering SE 3(1), pp 6-15, 1977. Institut de Gnie Logiciel SADT: Guide d'auteur Document SADT, 1962. D. Shipman The functional datamodel and the data language DAPLEX ACM Transitions on Database Systems 6:1, 1981 J.M. Spivey The Z notation Prentice Hall, 1989. J.D, UIIman Principles of database and knowledge-base systems Computer Science Press, Rockville Md. 1988.