A Formal Object-Oriented CASE Tool for the Development ... - CiteSeerX

A Formal Object-Oriented CASE Tool for the Development of Complex Systems Jean-Michel Bruel and Robert B. France Department of Computer Science & Engineering Florida Atlantic University Boca Raton, FL-33431, USA. Email: fbruel,[email protected] Marsh 15, 1996y

Abstract

An increasing number of CASE tools based on object-oriented methods (OOMs) are appearing in the marketplace. Despite their good qualities, OOMs produce models that are not amenable to rigorous semantic analysis. This problem can be attributed to the lack of rm semantic basis for the modeling notations and concepts such as those found in formal methods. Formal and graphical informal analysis techniques complement each other when they are integrated appropriately. Formal techniques facilitate rigorous reasoning about modeled behavior, while graphical informal techniques facilitate the creation of models that are concise, and easier to understand. In this paper we describe the current status of our work on developing an environment for the speci cation and the analysis of complex systems. This environment, called FuZE, supports the integration of Fusion analysis techniques and the more formal Z speci cation language. This new CASE tool is one example of the successful integration of two dierent speci cation approaches into a rigorous development environment.

1 Introduction Most popular object-oriented analysis (OOA) methods provide good support for creating understandable models of system behavior and structure. The lack of rm semantic bases for most of these methods makes it dicult to rigorously reason about modeled behavior, and to check the compliance of implementations against them. In this paper we describe our CASE tool, an automated support environment for formalizing the Fusion object-oriented analysis modeling techniques [6]. The objective of the formalization is to make the Fusion models more amenable to formal semantic analysis. The environment, called FuZE (Fusion/Z Environment), is based on an integration of Fusion and the Z speci cation language [23]. FuZE is built on top of the Paradigm Plusr object-oriented modeling CASE tool [18]. The extensions to the tool we have made thus far allow modelers to generate Z speci cations from Fusion object models. From Paradigm Plusr , Z analysis tools, e.g., typecheckers and animators, can be called to analyze the generated speci cations. In Section 2 we motivate our use of integrated formal speci cation techniques (FSTs) and graphical object oriented methods (OOMs) in requirements engineering. We also give an overview of the existing approaches in this area. Section 3 describes our FuZE tool. In Section 4 we give our conclusions and outline our plans to further develop FuZE. To be published in the proceedings of the 7th European Workshop on Next Generation of Case Tools (NGCT'96), Crete, Greece, May 20{21, 1996.  This work was partially funded by NSF grant CCR-9410396. y

1

2 Rigorous requirements modeling The application of informal object-oriented methods (OOMs) can be made more rigorous by integrating them with suitable formal speci cation techniques (FSTs). The integration of an OOM and a FST is an instance of a class of speci cation techniques that we call integrated formal/informal speci cation techniques (FISTs) [8, 9, 10]. FuZE is based on a Fusion/Z FIST described in [1]. We chose Fusion because it incorporates some of the best object-oriented modeling ideas from previous OOMs in a single coherent method. The Fusion analysis models are formalized by re-expressing some behavioral and structural aspects in the Z notation [23]. We chose Z because of its maturity, expressiveness and the availability of analysis tools (e.g., CADiZ [24], f uzz [22], ProofPower [14], or ZTC [13]). Most developers view FSTs as radical alternatives to the more popular non-formal OOMs. It is often felt that the adoption of FSTs requires a total overhaul of the current development process, resulting in the throwing out of investments and experiences in currently used modeling techniques. Research on FISTs indicates that FSTs can be used in the context of currently popular modeling techniques (e.g., see [9, 10, 17, 20]). Integrating FSTs with less formal modeling techniques can enhance the application of the less formal techniques. FSTs can be used to develop more formal notions of semantic aspects and provide mechanisms for rigorously analyzing the resulting models. In this way, FSTs can be used to reinforce con dence in, or uncover problems with models expressed in the notation of the less formal modeling technique. OOMs can also be used to enhance the application of FSTs. The models produced by FSTs, while abstract, can be dicult to understand because of the eort needed to relate abstract formal concepts to \real-world" problem concepts. One of the factors behind the popularity of graphical OOMs is their ability to capture \real-world" concepts in a concise and clear manner. The models produced by OOMs can be used to reexpress concepts described in formal speci cations to support presentations and to aid understanding of formally modeled concepts. FISTs can also ease the creation of formal speci cations, reducing the eort required. In some cases, complete automation of the informal object-oriented model to formal speci cation transformation is not possible because the informal object-oriented models do not provide information needed to generate complete formal speci cations. In the cases where enough information is provided to generate complete formal speci cations, human interaction is often needed during the transformations to at least simplify generated formal speci cations. In FuZE, the Fusion object model can provide enough information to generate a complete Z speci cation of an application's static structure. Other OOMs have been integrated in a formal environment. For OMT [19], Hartrum and Bailor [11] give a Z formalization of parts of the notations. Bourdeau and Cheng [3] have developed a method for deriving modular algebraic speci cations from OMT object model diagrams.

3 FuZE: A Fusion/Z FIST Environment Paradigm Plusr (Release 2.01) [18] is an object-oriented analysis and design tool that supports Enterprise Component Modeling (ECM), code generation, and reverse engineering. It provides support for modeling based on OMT [19], Fusion [6], Booch [2] and others, and automatically generates C, C++, Smalltalk or Ada code from the models. A powerful script language allows custom reporting, checking, and code generation. We used the script language to build FuZE on top of Paradigm Plusr . Fig. 1 gives an overview of the process that allows one to formally analyze a Fusion model in FuZE. Beginning with an Object Diagram in Fusion, 2

Fusion Model

Formal Analysis

Paradigm+

.ps

dvips .out Formal ZTC

.zed

LaTeX

Specification

.dvi

Z

.zsl Toolkit .tex

Figure 1: From a Fusion Object Model to a type-checked Z speci cation the formalization process generates a .out le of the corresponding Z speci cation1 . ZTC [13] is then launched by running a script, to type-check the speci cation and produce a printable .zed le. A .tex le can also be generated by a script to allow the use of LaTEX [16] to generate a Postscript version of the speci cation. The .zed le can also be analyzed by a Z animator such as ZANS (this tool has not been integrated into FuZE as yet). In the following subsections we outline the transformation rules between Fusion and Z. We also describe how to analyze the output results of our transformation and what bene ts one can expect from this analysis.

3.1 The rules

We give here an overview of the translation from a Fusion model to a Z speci cation. Our aim in this paper is not to present the rules that have been de ned, but to give an overview of the implementation of these rules. For more details about the rules themselves, see [1]. In Fig. 2 we summarize the Fusion models covered by our rules and by the tool.  

   1

In formalizing the Object Model FuZE rst normalizes the names of entities. Objects are represented by Z state schemas. An object's attributes are declared as state variables, and any invariants associated with the object, expressed in the form of object annotations in the Object Model, are expressed formally in the predicate part of the schema representation. The type associated with an attribute is used as the type in the Z schema. Each object instance has a unique identi er that is explicitly de ned as a value bound to a variable in the object's Z schema. We created a mathematical toolkit that includes Z de nitions of the dierent types of general binary relationships that can exist between objects in an Object Model that involve cardinalities

The format chosen for the Z speci cation is discussed in section 3.2.

3

Implementation

Design covered by FuZE Class Attributes

Operation Model Life-Cycle Model

Generalization Relationship

Analysis

covered by the rules

Aggregation

and being implemented

Structuring System Object Model

OBJECT MODEL

INTERFACE MODEL

Figure 2: Coverage of our formalization 1-to-many, many-to-1, 1-to-1, and many-to-many. Relationship attributes are handled by declaring the attributes as variables in the relationship schema. Feedback Object Oriented

Z

Translation

Specification

Fusion

Feedback Z Tools

Feedback

Formal Validation Animation

Figure 3: Illustration of the translation of a simple Fusion object diagram     

Ternary and higher relationships are handled by modeling the relationship as a variable with an n-tuple type, where each class in the relation is a component of the type. Cardinality are expressed in the predicate part of the relationship schema. The aggregation relationship is represented cleanly in Z by including the schema (or other) representations of the parts of the aggregate structure in the schema representing the parent class. A generalization hierarchy is represented in Z by including superclass schemas in subclass schemas. For multiple specializations it may be the case that some of the super-classes have identically named attributes.

4



Once the parts of the Object Model are de ned they are collected in a schema that is a representation of the model. Invariants involving parts that were separately de ned are expressed in the predicate part of this schema. Our guidelines support a compositional approach to formalizing an Object Model.

We formalize only the Operation Model of the Fusion Interface Model. The Fusion Life-Cycle Model is rigorous and analyzable; re-expression of this model in Z is not necessary. Fusion Operation Models are translated to Z operation schemas in the following manner:  The Operation name is used as the schema name.  The informal Description is used to document the Z operation schema.  Variables mentioned in the Reads section are declared as input variables in the Z schema.  If variables are mentioned in the Changes section then the state is declared in the Z operation schema preceded by the
symbol (indicating that the operation causes a change in the state). Equations for variables not changed by the operations (i.e., not mentioned in the Changes section) are generated. For example, if state variable x is not mentioned in the Changes section then the equation x 0 = x is generated; if no variable in the state schema, S , in which x is declared is mentioned in the Changes section then the equation S 0 = S is generated.  Variables mentioned in the Sends section are declared as output variables in the Z operation schema.  The condition in the Assumes section, when formalized, is the precondition of the operation.  The formalized content of the Result section is given in the predicate part of the operation schema. Here is an example of the Fusion description of an operation and its corresponding formalization in Z: Operation: enable pump Description: Enables the pump ready to dispense petrol. enable pump

Reads: supplied n Changes: Pump with pump :pump id = n Sends: Assumes: Result: if pump is enabled or out of service


System id ? : PUMP ID 9 p p : pump j p pump id = id ? ^ p pump id = id ?  (p status = Enabled _ p status = Out of Service ) ) p status = p status ^ p status = Disable ) p status = Enabled ^ pump = pump n fp g [ fp g ;

0

0

:

:

:

0

then no eect otherwise: Status of pump is enabled.

:

:

:

0

:

0

5

0

:

3.2 Transforming Object Models in FuZE

Paradigm Plusr can be customized by its powerful, full-featured script language. The script language supports methods checking, reports and code generation. The script language syntax is similar to the syntax of BASIC-like languages. Familiarity with higher level languages makes writing scripts in Paradigm Plusr [18] easier. To translate a Fusion model into a Z speci cation, one selects in the menu the option to run a script (cf. Fig. 4). The input format used by mainly all the available tools for Z is based on style les like the

Figure 4: Selection of a transformation rule [15] or zed [21] packages, developed for typesetting Z in LaTEX [16]. In the rst version of our tool, we have chosen another format: ZSL which is an ASCII version of the Z notation provided with the ZTC tool [13]. It is easier to use by people who are not familiar with LaTEX. We have made the translation scripts easy to modify in order to integrate later the LaTEX format, and the Z Interchangeable Format (ZIF) proposed by the Z Standard Committee [4, appendix D]. ZIF is a portable representation of Z de ned in the ISO Standard Generalized Markup Language (SGML) [7] that should be readable by the next generation of HyperText Markup Language (HTML+) making the speci cation readable by World Wide Web browsers. More details about the results of automatic translations in FuZE can be found in the draft FuZE technical report [5]. oz

3.3 The formal analysis of the translation result

As illustrated by Fig. 1, we use ZTC not only to perform translation between ZSL and LaTEX but also to type-check the speci cation. The Paradigm Plusr script language allows one to access the operating system shell. We use this feature to invoke ZTC with the script output and the mathematical toolkit as its inputs. Fig. 5 shows 6

the selection of the script corresponding to the analysis part. After the output result of the translation rules, ZTC is launched to type check the generated Z speci cation and to generate (if the speci cation is correct) the corresponding LaTEX output.

Figure 5: Analysis of the corresponding Z speci cation We also include in the output speci cation some comments used by the ZANS [12] animation tool that allows one to animate the speci cation by de ning very simple operation that manipulate the objects in the model.

3.4 Bene ts of FuZE

We chose Fusion because it is considered a second generation method, incorporating some of the best object-oriented modeling ideas. Presently the scripts are written to handle Fusion model. Since Paradigm Plusr has meta-information about the type of method being used, the scripts can be generalized to handle all the OOMs supported by Paradigm Plusr (e.g., Fusion, Rumbaugh, Coad Yourdon, Shlaer Mellor). Based on the type of OOM used, the script can be written to handle the variation in notation between methods. To illustrate the kind of bene ts associated with the Fusion/Z FIST, we consider the following \bad" Fusion speci cation (see Fig. 6). The corresponding Z speci cation is2 :

7

A

*

*

B

Operation: Description:

Gets_B

Reads: Changes: Sends: Assumes: Result:

supplied i (identifier of A)

Gives the corresponding B of an A

if i is a correct identifier, gives the corresponding B

Figure 6: A \bad" Fusion model [ID ]

Init a : PA b : PB Gets B : nomanytonomany [A; B ] a ? : A; b ! : B dom Gets B  a ran Gets B  b 8 i ; j : a  i :id = j :id , i = j 8 i ; j : b  i :id = j :id , i = j b ! = Gets B (a ?)

A id : ID B id : ID

If we try to animate the above Z speci cation with ZANS [12], we get the result: >>> Init is not because the animator cannot de ne the value of the output result b ! of the Init operation. The bene ts of our approach are also related to the writing of a Z speci cation itself. We illustrate using a speci cation based on Spivey's BirthdayBook speci cation [23, p. 3]. The speci cation of a function birthday which, when applied to certain names, gives the associated birthdays, is given below:

explicit.,

[Name Date ]

FindBirthday

;

BirthdayBook name ? : Name date ! : Date name ? 2 known date ! = birthday (name ?)

BirthdayBook names : PName birthday : Name $ Date

This speci cation of BirthdayBook is incorrect. First, the domain of birthday should be related with names in the predicate part of BirthdayBook (names = dom birthday ). Secondly, in this speci cation a name can have multiple dates. If one try to build an operation to get the date from a name with the FindBirthday operation, there is a problem due to the fact that the operation is not well-de ned. Not only is date ! not unique, but name ? may not be in the domain of birthday . Now let's consider object model of the problem and its generated Z speci cation (see Fig. 7): 1 relationships: Considering the formal de nition of  

2

-

The operation schema is obtained manually using relevant translation rules.

8

[Name Date ] ;

BirthdayBook Name

*

1

BirthdayBook names : PName dates : PDate birthday : nomanytonone [names ; dates ]

Date

birthday

:::

Figure 7: The Birthday book example [X Y ] ;

 

-

1 : P(X

! 7 Y)

birthday is now a partial function (a name has only one date if any) and its domain is related to the set on names3 . One can argue that the user can also make similar mistakes in the Object Model. While this is true, the visual nature of the Object Model makes such mistakes more obvious and thus more likely to be caught when creating the model.

4 Conclusion and future works The use of OOMs in the development of complex systems can be inhibited by their lack of formal semantic bases. In this paper we discuss how a particular object-oriented analysis method, Fusion, has been integrated with a FST, Z, to produce analyzable object-oriented analysis models. The formalization discussed in this paper is not the only one possible. We are currently working on other ways of formalizing Fusion analysis models and carrying out experimentations to assess the relative merits of the approaches we identify. We are also working on formalizing Fusion design models. The objective of this aspect of our work is to provide a formal basis for justifying object-oriented implementations against requirements. The primary objective of integrating Fusion and Z is to create analyzable Fusion models. The integration allows one to use Z typecheckers and Z animation tools to analyze models.

Acknowledgments This work was supported in part by NSF grant CCR-9410396. The authors wish to thank Brian Bates and Maria Petrie for their participation in this project. We are also grateful to Bharat Chintapally and Gopal Raghavan for implementing the rules into FuZE. Paradigm Plusr [18] is a registered trademark of Protosoft Inc. ZTC [13] is available via anonymous ftp at ise.cs.depaul.edu. Information on LaTEX [16] is available at http://www.loria.fr:80/tex/english/index.html.

References [1] B. W. Bates, J.-M. Bruel, R. B. France, and M. M. Larrondo-Petrie. 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, 4{6 Mar. 1996. 3

This is automatically inherited from the de nition of birthday .

9

[2] G. Booch. Object-oriented analysis and design with applications. Benjamin/Cummings, 1994. [3] 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. [4] S. M. Brien and J. E. Nicholls. Z base standard. Technical Monograph PRG-107, Oxford University Computing Laboratory, Wolfson Building, Parks Road, Oxford, UK, Nov. 1992. Accepted for standardization under ISO/IEC JTC1/SC22. [5] J.-M. Bruel, B. Chintapally, R. B. France, and G. Raghavan. FuZE{Draft of the User's Guide. FAU Technical Report TR-CSE-96-9, Department of Computer Science & Engineering, Florida Atlantic University, Boca Raton, FL{33431, USA, Feb. 1996. [6] D. Coleman, P. Arnold, S. Bodo, C. Dollin, H. Gilchrist, F. Hayes, and P. Jeremaes. Object-Oriented Development: The Fusion Method. Prentice Hall, 1994. [7] I. I. O. for Standardization). Information Processing { Text and Oce systems { Standard Generalized Markup Language (SGML). ISO 8879{1986 (E), Geneva: ISO, 1986. [8] R. B. France and M. M. Larrondo-Petrie. From structured analysis to formal speci cations: State of the theory. In Proceedings of the 1994 ACM Computer Science Conference. ACM, 1994. [9] R. B. France and M. M. Larrondo-Petrie. A Two-Dimensional View of Integrated Formal and Informal Speci cation Techniques. Lecture Notes in Computer Science, pages 434{448. Springer-Verlag, 1995. [10] R. B. France and M. M. Larrondo-Petrie. Understanding the role of formal speci cation techniques in requirements engineering. In Proceedings of The 8th SEI Conference on Software Engineering Education, Lecture Notes in Computer Science 895, pages 207{222. Springer-Verlag, 1995. [11] T. C. Hartrum and P. D. Bailor. Teaching formal extensions of informal-based object-oriented analysis methodologies. In Proc. Computer Science Education, pages 389{409, 1994. [12] X. Jia. An Approach to Animating Z Speci cations. Division of Software Engineering, School of Computer Science, Telecommunication, and Information Systems, DePaul University, Chicago, IL 60604, USA, 1995. [13] X. Jia. ZTC: A Z Type Checker, User's Guide, version 2.01. Division of Software Engineering, School of Computer Science, Telecommunication, and Information Systems, DePaul University, Chicago, IL 60604, USA, May 1995. The ZTC tool and documentation are available on Internet via anonymous ftp at ise.cs.depaul.edu. [14] R. B. Jones. ICL ProofPower. BCS FACS FACTS, Series III, 1(1):10{13, Winter 1992. [15] P. King. Printing Z and Object-Z LaTEX documents. Department of Computer Science, University of Queensland, May 1990. [16] L. Lamport. LaTEX User's Guide & Reference Manual. Addison-Wesley Publishing Company, Reading, Massachusetts, USA, 1986. Online information on TEX and LaTEX is available at http://www.loria.fr:80/tex/english/index.html. [17] K. C. Mander and F. Polack. Rigorous speci cation using structured systems analysis and Z. Information and Software Technology, 37(5):285{291, May 1995. [18] Protosoft, Inc. Paradigm Plus { Release 2.0. Protosoft Technical Support, Houston, Texas, USA, Jan. 1994. [19] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall, Englewood Clis, N.J., 1991. [20] L. T. Semmens and P. M. Allen. Using Yourdon and Z: An approach to formal speci cation. In J. E. Nicholls, editor, Z User Workshop, Oxford 1990, Workshops in Computing, pages 228{253. Springer-Verlag, 1991. [21] J. M. Spivey. A guide to the zed style option. Oxford University Computing Laboratory, Dec. 1990. [22] J. M. Spivey. The f uzz Manual. Computing Science Consultancy, 34 Westlands Grove, Stockton Lane, York YO3 0EF, UK, 2nd edition, July 1992.

10

[23] J. M. Spivey. The Z Notation: A Reference Manual. Prentice Hall International Series in Computer Science, 2nd edition, 1992. [24] I. Toyn. CADiZ Quick Reference Guide. York Software Engineering Ltd, University of York, York YO1 5DD, UK, 1990.

11