Integrating Formal and Informal Specification ...

Integrating Formal and Informal Specification Techniques. Why? How? Jean-Michel Bruel, Panel Chair UFR Sciences – Dpt. d' Informatique Universit de Pau et des Pays de l' Adour F-64000 Pau, France [email protected]

Abstract This paper is an overview of the panel session on integrating specification techniques that was held in the International Workshop on Industrial-strength Formal Techniques in October 22nd 1998. Betty Cheng, from Michigan State University, Steve Easterbrook, from NASA, Robert B. France, from Colorado State University, and Bernhard Rumpe from Munich University of Technology were the panelists of this session.

1. Introduction In the day to day activity of developing systems, integrated environments are used frequently. Like object orientation few years ago, it seems that if a tool vendor wants to propose a cutting edge tool, it has to use an integrated approach in some way. But what does integration means? What is the difference between integration, translation, derivation, and other similar terms? One can tell that integration implies the use, in a given development process, of more than one notation, model, or method. But is a method that utilizes a number of modeling views also an integrated technique? It is often the case that in a particular method several notations are used. It is even recommended by some methodologists (in support of the separation of views principle). To quote Anthony Hall in his invited talk at WIFT' 98: “Different aspects need different languages.” To tackle this question of integration, and to give an overview of the existing integrated approaches, it was decided to hold a panel session on the topic. The practical orientation of the workshop, mainly dedicated to industry, was a good context to discuss what is often viewed as an academic endeavor that is disconnected from industrial needs. The remainder of this paper is organized as follows. In section 2, we will define integration, and discuss the different ways to achieve it. In section 3, we give an overview

Panelists: Betty Cheng, Michigan State University Steve Easterbrook, NASA Robert France, Colorado State University Bernhard Rumpe, Techincal University of Munich

of the panelists' contributions (which are detailed in the appendices). In section 4 we present the main points that were discussed during the session, between panelists and attendees, and in section 5 we state the conclusions of the session.

2. What is integration? According to the Webster dictionary, to integrate is “to make into a whole”. When developing systems, integration occurs whenever two different models, notation, or even methods are used in the same development process as part of a unified approach to development. It is often the case that in one particular method several diagrams are used (e.g., OMT). How are inconsistencies across models in such methods handled? Often such inconsistencies can be detected using guidelines provided by the method, or, for syntactic-based inconsistencies, they can be flagged as errors in tools supporting the application of the method. But when it comes to the use of different diagrams, notations, methods, from different communities, how can inconsistencies across them be detected? Who provides the rules for detecting such inconsistencies? Due to the workshop interests, the session mainly focused on integration between informal and formal specification techniques. It might be pointed out that true integration is only between formal methods or between informal methods but not between informal and formal methods. This last type of integration can be viewed either as a translation from graphical to formal or as a way of obtaining graphical models from formal models. Nevertheless, there are a number of reasons why one would want to integrate formal methods with informal methods. We can mention [1]:

 to enhance application of informal methods (they can also enhance the application of formal techniques),  to provide an evolutionary path to the use of more formal approaches to software development,

 to support the specification of behavior and structure at varying levels of rigor. This kind of integration between informal methods and more rigorous methods is called FISTs (integrated Formal/Informal Specification Techniques) [9]. The use of FISTs can be beneficial in the following respects:

 FISTs enable an evolutionary approach to the use of formal techniques in industry by allowing an organization to preserve, and even enhance, its investment while taking advantage of formal-related benefits.  Formal and graphical techniques can complement each other, merging the relatively simple and graphical nature of informal specifications with the firm semantic bases of formal techniques.  A FIST can provide basis for structuring the analysis process which usually involves transforming vague notions of required behavior to precise statements of need. The manner in which formal and informal techniques are integrated in a FIST is usually based on one or more of the following considerations:

 Preservation of the intuitive interpretation of the informal specification: the integration should be such that the formal specifications provide interpretations of the informal specifications that are consistent with intuitively-held interpretations of the informal specifications. The interpretation provided by a formalization should reinforce the informal interpretation.  Level of automated support for moving between formal and informal specifications: Developing formal specifications can be a very arduous task. Well-defined relationships between formal techniques and informal techniques constructs and concepts can provide the basis for mechanical generation of some parts of the formal specification. In the other direction, it is often possible, given a well-defined relationship between formal and informal specification elements, to mechanically generate informal specifications from formal specifications that have a certain form.  Degree of integration: In some cases it may not be worthwhile to formally interpret all aspects of an informal specification. It may be sufficient to formalize only those parts that can benefit from more rigorous specification and analysis. The following section is an overview of the panelists' contributions.

3. Panel session contributions Integrated methods for V&V Steve Easterbrook is working on the earlier stage of the development process, where the requirements need to be analyzed before going further. He has found the “lightweight” formal methods very useful in this respect [5]. To answer Steve Easterbrook is senior research associate at the NASA Independent Verification and Validation (IV&V) facility (Fairmont, West Virginia). His research interests include the management of inconsistency in requirements specifications, and the use of formal methods for requirements modeling and validation. E-mail: [email protected] the question on whether integration was really needed or not, Steve proposed to answer first the question: why we would need to integrate. His main points were that we need it only if it gets us somewhere and only if it is free (see appendix C for more details). Among the several ways of integrating, he has rejected the one that consists of the use of extensions. Extension is often an attempt to use a core technique for something it was not built for. The use of hand-translation approaches is not good either because it is error-prone. A point-topoint translation could get attention, but he concluded that what he recommends is the use of generic frameworks (using viewpoints, categories, . . . ) that take into account both the industrial habits and the analysis needs.

Perceived Problems with Integrated Formal and Informal Techniques Robert France has worked around the formalization of informal models [7, 8, 9]. He is strongly involved in the pUML group which is working on developing a precise semantics for the UML [11]. While at Florida Atlantic UniRobert France is working at the Computer Science Department of the Colorado State University (Fort Collins, Colorado). His major research activities include formalizing object oriented modeling concepts and methods integration. E-mail: [email protected] versity, he formed the Methods Integration Research Group (MIRG) that focused primarily on formalizing OO modeling techniques. His work on integrated methods focuses on providing a formalization that can be used to directly support validation and verification activities.

Current approaches to integrating formal and informal techniques suffer from significant problems. The defined transformations are based on an underlying interpretation of the informal constructs. This interpretation is often not clearly stated in descriptions of the integrated techniques and the justification for choosing a particular interpretation is often not stated. Under such circumstances it is difficult to determine whether a transformation from informal to formal models captures the intended interpretation. These problems also make it difficult to relate the results of rigorous analysis of the formal models to problems in the corresponding informal models. See Appendix B for details.

Formal Diagrammatic Methods Bernhard Rumpe detailed the work he is doing in the SysLab project1 . In his opinion, the benefits of diagramBernhard Rumpe is working in the Department of Computer Science of the Munich University of Technology (Munich, Germany) around the formal methods area. His Ph.D. thesis involved an integrated formalization of objectoriented modeling techniques. He is involved in several object oriented conferences. E-mail: [email protected] matic methods like UML [10], e.g., their more intuitive understanding, and their widespread acceptance, can be combined with the formality of textual formalisms into formal diagram-based methods. See appendix A for more details.

Integrating vs. ReCreating Betty Cheng presented the main benefits of the formalization and integration process. The powerful image that she used was a bridge between informal and formal specifications. In order to give a definition of integration, one can focus on the answer to the question of how the bridge is chosen (size, position, . . . ) and how it is built. The main argument for the use of integrated approaches was expressed in terms of their cost-benefits. Developers in industry often do not have the time or money to try all the different methods that are available. Betty Cheng' s research is focused on the definition of formalization rules 2 [2]. From the object model, algebraic specifications are derived, from the dynamic model, process algebras are produced, and from the functional model, predicate and algebraic specifications are derived. See appendix D for more details. 1 Project funded by the DFG under the Leibnizpreis program and by Siemens. 2 This work is supported in part by NSF grant CCR-9633391 and DARPA grant administered by Air Force's Rome Laboratory F30602-961-0298.

Betty Cheng is working in the Software Engineering & Network Systems Laboratory at Michigan State University (East Lansing, Michigan). Her research interests include formal methods for software engineering, software development environments and object-oriented analysis and design. E-mail: [email protected]

4. Discussions A formal semantic base for the notation allows one to rigorously reason about the models being built. A significant problem in informal methods is that they rely on informally defined semantics. This can lead to situations where models are interpreted differently because of differing viewpoints on what the semantics are. This is more likely to occur when complex structures are involved. Some of the attendees pointed out that providing a formal semantic to informal models was not integration, but translation. Another suggestion that was raised during the discussion was that integration can occur between multiple formal (or informal) techniques. The experience and knowledge of the practitioner is very important in the definition and in the choice of the mappings between informal and formal notations. Complete automation of the informal to formal specification transformation is unlikely, given that informal specifications are inherently incomplete. Human interaction is needed during generative transformations to at least simplify generated formal specifications. Most generative informal to formal specification transformations generate a formal specification skeleton using information available from the informal specifications. This then requires that the specifier provide additional details to complete the formal model.

5. Conclusion There is a strong demand from industry for rigor and formality. Academic research and tools vendors are asked to provide useful, powerful, cost-effective methods. Application of mathematically-based formal techniques requires much effort and skill on the part of the developer, and not many are willing to invest to acquire such skills. A technique that allows developers to reap the benefits of rigorous analysis while using notations they are familiar with is more likely to be used in practice. The main objectives of integrated formal/informal approaches is to make formal methods easier to apply and to make informal methods more rigorous. If integrated techniques are to be used in industry they must be tool supported, tested on real case studies, and must be consistent with industrial best practices. It is true that there is very little empirical evidence of the benefits of use of integrated

techniques, but this is also true of the use of object-oriented techniques.

Acknowledgements I would like to thank all the panelists for their contributions and help and more especially Robert France for helping organize this panel session and for his comments on preliminary versions of this paper. Jean-Michel Bruel is working at the computer science department of the University of Pau (France). His research interests include formal methods, distributed and real-time systems, and object-oriented computing. E-mail: [email protected]

References [1] B. W. Bates, J.-M. Bruel, R. B. France, and M. M. LarrondoPetrie. Formalizing Fusion Object-Oriented Analysis Models. In E. Najm and J.-B. Stephani, editors, Proceedings of the First IFIP International Workshop on Formal Methods for Open Object-based Distributed Systems, Paris, France. Chapman & Hall, London, UK, 4–6 Mar. 1996. [2] R. H. Bourdeau and B. H. Cheng. A formal semantics for object model diagrams. IEEE Transactions on Software Engineering, 21(10):799–821, Oct. 1995. [3] R. Breu, R. Grosu, F. Huber, B. Rumpe, and W. Schwerin. Towards a Precise Semantics for Object-Oriented Modeling Techniques. In Proceedings ECOOP' 97 Workshop on Precise Semantics for Object-Oriented Modeling Techniques. TUM-I9725 Technische Universit¨at M¨unchen, 1997. [4] R. Breu, U. Hinkel, C. Hofmann, C. Klein, B. Paech, B. Rumpe, and V. Thurner. Towards a Formalization of the Unified Modeling Language. In S. M. Mehmet Aksit, editor, ECOOP' 97 Proceedings, volume 1241 of Lecture Notes in Computer Science. Springer-Verlag, New York, 1997. [5] S. Easterbrook, R. Lutz, R. Covington, J. Kelly, Y. Ampo, and D. Hamilton. Experiences Using Lightweight Formal Methods for Requirements Modeling. IEEE Transactions on Software Engineering, 24(1), Jan. 1998. [6] R. France, A. Evans, K. Lano, and B. Rumpe. The UML as a Formal Modeling Notation. Computer Standards & Interfaces, to appear, 1998. [7] R. B. France. Semantically Extended Data Flow Diagrams: a Formal Specification Tool. IEEE Transactions on Software Engineering, 18(4):329+, Apr. 1992. [8] R. B. France and J.-M. Bruel. The Role of Integrated Specification Techniques in Complex System Modeling and Analysis. In J. Zalewski, editor, Proceedings of the Workshop on Real-Time Systems Education (RTSE' 96), Daytona Beach, Florida, pages 111–119. IEEE Computer Society Press, 20 Apr. 1996.

[9] R. B. France and M. M. Larrondo-Petrie. A TwoDimensional View of Integrated Formal and Informal Specification Techniques. In J. P. Bowen and M. G. Hinchey, editors, Proceedings ZUM' 95: The Z Formal Specification Notation – 9th International Conference of Z Users, Limerick, Ireland, volume 967 of Lecture Notes in Computer Science, pages 434–448. Springer-Verlag, New York, Sept. 1995. [10] T. O. M. Group. Unified Modeling Language. Version 1.1, Rational Software Corporation, Santa Clara, CA-95051, USA, 1 Sept. 1997. [11] Jean-Michel Bruel and Robert B. France. Transforming UML Models to Formal Specifications. In Proceedings of the Int. Conf. on Object Oriented Programming Systems Language and Applications (OOPSLA' 98) Vancouver, Canada, 18–22 Oct. 1998. [12] B. Rumpe. A Note on Semantics (with an Emphasis on UML). In H. Kilov and B. Rumpe, editors, Second ECOOP Workshop on Precise Behavioral Semantics. Technische Universit¨at M¨unchen, TUM-I9813, 1998.

Appendices A. Formal Diagrammatic Method?! The following is the position paper from Bernhard Rumpe.

Position paper Formal methods are not necessarily text based, they can use diagrams as their underlying notations as well. An important aspect for a well understood and applicable specification notation is its possibility to describe important views of a system, let it be behavior, interaction patterns or structure, in a comfortable and intuitive way. Of course rigorous context conditions that ensure well-formed specifications are needed. But most important is a convenient treatment of the specification that allows us to handle a specification in order to gain some benefits from the investment in having developed the diagrams. This includes techniques for

 refining a specification document by adding details,  generating code from executable diagrams, like State Transition Diagrams and Class Diagrams,  translating a document into another notation, like deriving State Transition Diagrams from MSCs,  deriving views from a given (very detailed) document, like extracting abstract overviews,  testing a specification according to test scenarios,  generating code from specifications,

and more. For a typical formal method at least some of these techniques exist. On the one hand, the notations of text based formal methods today are hardly intuitive and therefore not very appealing to use. On the other hand, the diagramatic OO notations, and especially UML, lack almost all of the above described manipulation techniques. So both worlds could greatly benefit from each other and found an integrated method which combines the advantages of both approaches. This does not mean that a formal notation, say Z, and a diagrammatic one, say UML, need to be integrated. But instead of the already mentioned syntactic integration, it seems preferable to use a semantic integration: The existing manipulation techniques for a formal method should be transported to a diagrammatical method in such a way that their application allows correctness-preserving refinements, derivations, etc. Examples for this are:

 splitting of states in State Diagrams,  removal of a transition when an alternative exists,  introduction of a new superclass for a refactoring of common features of several subclasses,  strengthening of multiplicities in associations, and much more. For the UML first approaches are beeing developed (e.g. [6]), but it will take a lot of time and effort until a commonly accepted, comprehensible set of such manipulation techniques will have been established. Today it is not even quite clear that this is the best approach for gaining the benefits of bridging the gap between formal methods and diagrammatic notations. Furthermore, it is to be expected that tool vendors will come up with more sophisticated manipulation tools, all working on the same UML meta-model, but all allowing different manipulations because they are based on different intuitive understanding (semantics). Therefore, a well defined, precise semantics for a notation is an essential prerequisite for a definition of well suited manipulation techniques for the notation. A semantics definition in general is a mapping of a new notation (usually called syntax) into a well-known notation (called semantic domain). A semantics definition, as e.g. given for UML in [4] is of help for the developer of the notation and its manipulation techniques, but not for the user of the new notation, as he may not be willing or capable to understand the semantic domain. See [12] for a detailed discussion. Therefore, the user must not be exposed to any formal semantics definition, but to the notation and its manipulation techniques only. The semantics is hard-wired in the tools that allow only the manipulation of documents in a correct manner. Then tools become more than just mere diagram editors.

Please note that a meta-model of a notation captures its abstract syntax quite like the BNF-notation and graphgrammars could, but tells nothing about the meaning of a notation. Or could you understand the meaning of C++ by examining its BNF-grammar? The advantage of diagrams is their intuitive representation of certain aspects of a system. However, in contrast to most of the text based formal methods, diagrams are usually limited in expressiveness or some properties may be extremely tedious to represent. Therefore, it is a natural idea to integrate a textual and a diagrammatical notation into a sound method. In this case it is important that the text is supplemental to the diagram, e.g. used in pre- and postconditions of transitions, state invariants, etc. Never shall the diagrams be translated into text, as the generated text is much too complex for reading and looses much of the diagrams structure, even though it represents essentially the same information. Therefore, manipulation techniques need to be defined that deal with both aspects, text and diagram, in a smoothly integrated way. The SysLab project [3] currently takes a first important step in this direction, by developing a set of such manipulation techniques for the core notations of UML, using a slightly enhanced version of the OCL as textual supplement. Cooperations with companies like Siemens and BMW on notations like StateCharts, SDL and MSC have shown that this is the best approach to make formal methods more amenable for practicioners.

B. Integrated Techniques: The Way Ahead Research on integrated formal and informal techniques can trace its roots to the work of T.H. Tse in the mideighties. Tse' s objective was to develop a precise formalism of core structured modeling concepts that would enable translation among a variety of graphical structured techniques (e.g., data flow diagrams and structure charts). Tse used algebraic specification techniques to express the core concepts across these techniques. Tse' s work motivated the work of France on Docker on developing a precise semantics for data flow diagrams in the late eighties. In the early nineties, European researchers developed rules for transforming variants of structured analysis models to formal models expressed in mature formal notations. The nineties also saw a shift in focus in this work: works on generating formal models from graphical objectoriented models appeared in the mid-nineties. A number of papers have been published on transforming OO models to formal models. While they are superficial differences between these works (e.g., variances in the notations used) they take the same fundamental approach to integration: rules are defined for mapping graphical constructs to constructs in the formal modeling notation. Most

works also claim the following benefits of integration:

 Enable rigorous analysis of informal models.  Enhance reviews of informal models.  Enable rigorous consistency checks across different views of a system.  Provide a means for structuring large formal specifications.  Provide an evolutionary approach to the use of formal techniques Our analysis of these works resulted in the identification of the following problems:

 The interpretations underlying the transformation rules are seldom explicitly given. This makes it difficult to determine whether the formal model that results from the transformation captures the intent behind the informal model.  Often the focus is on formalizing basic constructs, not structures. In some cases, the interpretation of a basic construct can vary with its use in a model. For example, in an interpretation of generalization structures that we developed, an association that appears at a subclass level has an additional constraint if the association also appears at the superclass level: the subclass association must be a subset of the superclass association.  Very little work has gone into relating the results of rigorous analysis of the generated formal models to elements of the corresponding informal models. Our experience with developing and using integrated techniques raised the following issues:

 Is it reasonable to expect developers to use both formal and informal modeling notations in their work?  Are we really providing useful semantics for the informal notations? That is, do the formalizations lead to a better understanding of the informal modeling concepts? Can the formalization provide insights that can help a developer choose among a selection of applicable informal constructs? Based on the above observations we propose that the following needs have to be addressed if integrated techniques are to be viable in industry:

 Generation of formal models from informal models should not be the ultimate goal. The formal models

must play a significant role in development if integrated techniques. In certain environments direct manipulation of formal models can be ineffective (because engineers lack the skills needed to manipulate the models to gain effective use). In such cases, it is necessary to provide a more usable interface to the formal models; one that enables the benefits of rigorous analysis without direct manipulation of the raw formal notation.

 Use of formal techniques to gain deeper insights into informal modeling concepts should be an objective. Expressing concepts formally enables one to analyze the concepts more thoroughly, leading to a deeper understanding of the concepts. Such understanding can lead to more precise natural language descriptions of the semantics underlying the notations that represent these concepts, which, in turn, can lead to more effective use of the ”informal” notations.  There is a need to analyze industrial usage of modeling concepts. This can lead to the development of semantics that are consistent with industrial good practices. In developing formalizations of informal techniques we need to (1) develop a formal foundation that supports multiple modeling views, (2) develop analysis techniques that do not require direct manipulation of raw formal notations, and (3) understand the forces that determine the adequacy of particular interpretations in particular cases.

C. Should we integrate Formal Techniques? The following is the main points from Steve Easterbrook' slides. Some context

 Formal methods for V&V (early in the lifecycle) – “Throw away” models – Domain descriptions and system specifications – Using whatever tool is most appropriate (SCR, Spin, PVS, Trio, . . . ) – Aim is to find errors, not to prove correctness – Model the most critical components only; validate the most critical properties only.

 Lightweight formal methods – Actually lightweight use of formal methods – Partial analysis of partial specifications

– No commitment to developing and baselining complete, consistent formal specifications

D. Integrate Don't ReCreate

– Application of the methods is driven by the needs of the project

Position: Integrate Don't ReCreate

– Used to answer questions that arise during verification and validation.

This appendix draws the main titles of the slide presentation made by Betty Cheng. Bridging the Gap

So, why integrate methods? 1. Why multiple methods?

 V&V goals cannot be achieved in one notation (functional properties, safety & liveness properties, timing properties, deterministic and nondeterministic models, etc.)  Intermediate representations are very useful  Need different viewpoints for modeling 2. Do we need to integrate methods?

 Only if it gets us somewhere (need to understand the process)  Only if it comes for free 3. How should we integrate methods?

 Language extensions (embedding)?: no thanks!

 Automated formalization and integration of the informal models can help properly bridge the two sides.  Informal specifications, such as graphical models, are easy for humans to formulate, but can be inconsistent and incomplete.  We want formal specifications and executable code that can be verified for correctness and completeness. Integration Objectives

 Leverage existing technology  Leverage existing experience  Gain benefits from the integrated techniques  Expand user community The sum of the whole is greater than the sum of the individual parts.

 Hand translation?: error prone

Formalization Rules

 Point-to-point translators?: maybe

Proposed Formalization rules:

 Generic frameworks: yes please! Modularity in Software Engineering

 Reasons for wanting modularization

 from Object Model to Algebraic specifications  from Dynamic Model to Process algebras  from Functional Model to Predicate and Algebraic specifications

– Splitting the workload into workpieces – Splitting the system into system pieces – Splitting the problem domain into separate concerns

 Resulting benefits – Information hiding – Compositional verification – Compositional refinement

 Generalizable approaches: – Semi-formal – Viewpoints framework – Formal – Category Theory

Multi-Dimension Integration

 Informal and Formal techniques – OMT – Formal specifications: LOTOS and Larch

 Formal techniques: – Algebraic specifications (Larch LSL, ACT ONE) – Process algebras (LOTOS) – Predicate specifications (Larch LIL)

 Tools: – Larch tools (LP, syntax checkers, browsers) – LOTOS tools (LOLA, TOPO, etc.)

Benefits of the Formalization and Integration

 Easy to use formal methods  Intra- and inter- model consistency checking  Specification verification and validation  Stepwise design refinement  System behavior simulation  Fast prototype development  Code generation General Benefits

 Facilitates customer/developer interaction regarding requirements (Graphical models easier to understand, Simulation/prototyping capabilities)  Specifications enable requirements traceability  Formal specifications and analysis reduces burden on testing (Use automated techniques to analyze critical properties, Test case generation capabilities facilitate testing efforts)  Enables more rigorous (and automated) development process Summary

 Exists demand for bringing FM into industry  Lots of FM techniques (look at Oxford' s FM webpage)  Make FMs usable  Need for synthesis and experimental research Integrate and demonstrate, don't recreate!