British Computer Society CASE-based Rigorous Object-Oriented Modeling

The use of a rigorous development environment is needed when developing a complex system, such as real-time and critical systems. Preventing industry from embracing formal method techniques is the lack of industrial strength tools to support formalization and analysis. We are developing an approach and a tool environment for the development of complex systems that integrates a graphical object-oriented technique (Fusion) and a formal method (Z) with analysis tools. The tool, called FuZE (Fusion/Z Environment), has been used successfully to specify and analyze non-trivial systems. This paper describes the specification transformation rules and the extension of the environment to include transformation of design documents such as Object Interaction Graphs.


Introduction
Despite their strengths, object-oriented methods (OOMs) suer from a lack of rm semantic bases, which makes it dicult to precisely express and rigorously reason about requirements and designs.In particular, these limitations severely hamper the use of OOMs in the development of critical and distributed systems.Formal methods give the capability to conduct rigorous analysis but their mathematical notation is cumbersome to read and the lack o f a v ailable industrial strength tools prevent them from being more prevalent i n industry.
In previous papers (e.g., see [1,6]) we described our work on formalizing the Fusion [4] object-oriented analysis modeling techniques to make the models produced more amenable to formal analysis.We c hose the Fusion method because it incorporates some of the best object-oriented modeling concepts from previous OOMs, and the formal notation Z [10] because of its maturity, expressiveness, the availability of analysis tools, and its apparent compatibility with Fusion analysis modeling concepts.
In our approach, formal rules are used to transform Object Model structures into Z specications, and guidelines are given for formalizing operation schemas.We h a v e implemented the transformation rules for the Object Model in a tool that we are currently developing called FuZE (Fusion/Z Environment) [2] which also provides automated support for rigorous analysis of Fusion analysis models.
In this paper we present an improved version of the Fusion/Z transformation rules and discuss their implementation i n F uZE.We also discuss our ongoing work on formalizing Fusion design models, and present a formalization of Object Interaction Graphs.
There have been several Z-based object-oriented languages proposed, such a s F OOM [11].However, in our approach w e c hoose not to use any of these extensions, instead we use the Z notation as recommended by the people working around the Open Distributed P r o c essing [8].This allows us to benet of the support This work was partially funded by NSF grant CCR-9410396.Figure 1: An integration model of Z in terms of tools, and avoid the introduction at the analysis level of design choices, as would be the case if we used techniques such as Object-Z [5], where operations have to be attached to a particular class at the requirements stage.
In section 2 we present the improved transformation rules.Section 3 gives an overview of FuZE.Section 4 and 5 propose rules for formalizing object interaction graphs.Section 6 summarizes the results and future work.

Formalizing Fusion Object Models
In this section we present the improved versions of the rules.The improvements concern the formalization of generalization/specialization hierarchies and the manner in which the Z formalization of the Fusion Object Model is incrementally developed.

Representing classes in Z
In our approach, a class structure is represented by Z state schemas.The attributes of a class and object identiers of a class (implicitlydened in the Object Model) are represented by state variables.Any i n v ariants associated with the class (expressed in the form of annotations in the Object Model) are expressed formally in the predicate part of the schema representation.The type name associated with an attribute of a class in the Object Model is used to dene the attribute in the Z schema for the class (the type must also be dened in Z, for example, as a basic type, or a schema).If an attribute is not associated with a type in the Object Model, the capitalized name of the attribute is used as a type name and declared as a Z basic type.The resulting schema is called a class schema.
Instances of classes are represented as bindings of values to variables declared in Z schemas representing the classes.The identier of an instance is the value bound to the identier variable declared in the corresponding Z schema of the instance class.
Consider for example a Customer class with attributes name, ss number, ph number, address and date of birth, as shown in Fig. 2.
The corresponding Z schema for the customer class , automatically generated by F uZE, is: In this formal model, the capitalized name of the attributes (for example, NAME, SS NUMBER) are declared as basic Z type and used within Z schema as type names.The object class Customer is identied by the object identier ident, which i s o f t ype Customer ID.

Representing relationships in Z
In Fusion, a relationship is a tuple of objects, for example, hCustomer; Accounti.In a binary relationship only two object classes are involved.In general, depending on the type of relationship, any n umber of object classes may b e i n v olved.A relationship is used to model the idea of association or correspondence between the objects belonging to classes.The relationship between classes expresses only the possibility o f a relationship between the objects of the classes involved.The number of separate objects that participate in the relationship determines the arity of the relationship.In a ternary relationship, three separate objects relate to each other.Relationships involving more than three objects are referred to as n-ary relationships.Ternary relationships are dicult to implement and are usually avoided.There are work-arounds to convert the ternary relationships to binary relationship, which are easy to handle.As a part of the formalization tool, FuZE, we h a v e a mathematical toolkit.The mathematical toolkit provides Z denitions of the common types of binary relationship (for example, one-to-one, one-to-many, many-to-many) that can exist between objects in a Fusion Object model.Each relationship is represented by a Z t ype (for example, onetone, onetomany), which is dened by parameterized Z schemas.Graphical symbols are used to make the relationships clear.Fig. 3 is an extract from the mathematical toolkit, which shows a parameterized Z schema, Z types and graphical symbols to represent the relationship.
A binary relationship between a Customer class and Account class is shown by a F usion Object Model in Fig. 4.
A customer can maintain one or more accounts in a bank and an account is allotted to only one customer.This binary relationship between Customer and Account class is captured well and represented explicitly in the Init schema:  has : Customer $ Account 8 i; j : account (i:ident = j :ident , i = j ) 8 i; j : customer (i:ident = j :ident , i = j ) has 2 1 -[customer; account] Other binary relationships, like one-to-one, one-to-many, many-to-many, can be similarly represented.

Representing aggregation structures
Aggregation is a mechanism for structuring the object model.It is used to represent the \part-whole" or \a-part-of" relationship.Aggregation is similar to relationship and can be formed by taking tuples of class instances.Aggregation is transitive and antisymmetric (An example of transitivity: if A is a part of B and B is a part of C , then A is part of C .An example of antisymmetry: if A is part of B then B is not part of A).In most cases, the existence of a component object depends on the existence of the aggregate object, of which it is a part.Fig. 5 shows an aggregate structure in Fusion, with Consortium as an aggregate class and Bank as a component class.
In Z, aggregate structures are represented by declaring the components as sets in a schema representing the aggregate object class.Any cardinality constraints are formally expressed in the predicate part.Our current formalization of aggregation makes clear the component nature of aggregates: a component instance BCS-FACS Northern Formal Methods Workshop, 1996 holds : Bank $ Customer has : Customer $ Account 8 i; j : account (i:ident = j :ident , i = j ) 8 i; j : customer (i:ident = j :ident , i = j ) 8 i; j : consortium (i:ident = j :ident , i = j ) holds 2 1 -1[fx : Bank j 9 y : c onsortium x 2 y:bankg; customer] has 2 1 -[customer; account] 2.4 Representing generalization hierarchies Generalization is a powerful tool for abstraction.It captures the similarities and dierences among classes.It is used to represent the \is-a" relationship between classes.It provides a relationship between a class and BCS-FACS Northern Formal Methods Workshop, 1996 one or more rened versions of it.The rened class is called subclass and the class being rened is called superclass.A subclass inherits all the data and operations from the superclass.Fig. 6 shows a generalization relationship in which the ATM and CashierStation is generalized as an EntryStation.For multiple specializations it may be the case that some of the superclasses have identically named attributes.It may then be necessary to rename the variables before including them in the subclass schema.Renaming is not necessary when the superclasses inherit the identically named attributes from a common ancestor (in this case, only single copies of the common attributes are included; this can be achieved in Z by hiding the other copies before inclusion).Renaming is necessary when the identically named attributes originate from dierent ancestors.A Z specication for the generalization structure is shown below: [TYPE; : : : ]  (9 sub : cashierstation sub:entrystation = sup)) 8 sub1 : atm; sub2 : c ashierstation sub1:entrystation 6 = sub2:entrystation 8 sub : atm sub:entrystation 2 entrystation 8 i; j : consortium (i:ident = j :ident , i = j ) 8 i; j : atm (i:ident = j :ident , i = j ) 8 sub : cashierstation sub:entrystation 2 entrystation 8 i; j : cashierstation (i:ident = j :ident , i = j ) 8 i; j : account (i:ident = j :ident , i = j ) 8 i; j : customer (i:ident = j :ident , i = j ) 8 i; j : entrystation (i:ident = j :ident , i = j ) owns 1 2 1 -1[atm; consortium] owns 2 2 1 -1[cashierctation; fx : Bank j 9 y : c onsortium x 2 y:bankg] holds 2 1 -1[fx : Bank j 9 y : c onsortium x 2 y:bankg; customer] has 2 1 -[customer; account]

Putting it all together
Once the parts of the Object Model are dened they are collected in one schema that is a representation of the model.Invariants involving parts that were separately dened are expressed in the predicate part of this schema.Some restructuring of the schemas and/or redenition of the parts may be needed to reduce the complexity of the specication produced by the rules.
A complete object model of an ATM example is shown in Fig. 7.
We do not provide the corresponding Z specication because of lack of space but it can be found in [3].

CASE tool support: an Overview of FuZE
We h a v e implemented the rules previously described in a tool, called FuZE, built on top of the Paradigm Plus object-oriented modeling CASE tool [9].Paradigm Plus supports a powerful script language which can be used to customize the behavior of the tool, methods checking, code generation, etc.The script language has complete access to the back end repository.W e used the script constructs to query the object repository for necessary information.
The script language is BASIC-like and has the logical and arithmetic power of any higher programming languages.It has the semantics and control of a structured language and has access to the operating system shell.Its extensive function library, and ecient le input/output facilitates its use.We used the script language to build FuZE on top of Paradigm Plus.The script denes the mappings from Fusion Object Diagram to the Z language.The initial Object Diagram will be converted to a Z s p ecication le (.out) b y F uZE. ZTC is run on the Z specication to generate a printable type checked Formal Z specication (.zed) le.We also built a mathematical tool kit with all the necessary mathematical denitions and cardinality mappings used by ZTC.L a T E X is launched to generate a postscript version of the formal Z specication.
BCS-FACS Northern Formal Methods Workshop, 1996 The above simple contruct declares an attribute type, if there are no duplicates and if no type is declared.It uses the attribute name in upper case to declare the type.
Information which are not available through script queries on object repository are acquired by querying the prelled information arrays of FuZE.For example, the information regarding the parent class should be known while constrcuting a schema for the subclasses, such information is not avaliable before handusing the sequential query access of the object repository.Prelled arrays equipped FuZE with power to handle cardinality, aggregation upto four levels deeper and ternary associations, etc.More details about automatic translation results can be found in our FuZE technical report [2].To go further with our environment, we are extending FuZE to cover the design phase and to provide support for creating formal executable models of behavior.This will allow developers to not only analyze their designs, but also determine how compliant their designs are with respect to the formalized analysis models.

BCS-FACS Northern Formal Methods Workshop, 1996
In this paper we present the extensions we are going to make to the tool to support the formalization o f F usion design models, specically the Object Interaction Graph (OIG).Fig. 9 illustrates the links between the dierent F usion models that we consider.
An OIG is a collection of boxes, which represent design objects, that are linked by arrows representing message passing (see Fig. 10).

Design objects
The main components of the OIG are design objects, which w e will simply refer to as objects throughout this paper.Each object is an instance of a class that may h a v e been dened in the analysis model (i.e., new classes can appear in the design).
In the following we illustrate the transformation rules by considering the following le system, composed of Directory and File objects (we only give here the generated Z specication):

Message passing
The only connection between objects in the OIG is the labeled arrow representing message passing from a sender (or client) to a receiver (or server).The message represents the invocation of a method in the receiver interface.A description of the method is given (informally in Fusion) in the data dictionary.The message passing between a \sender" and a \receiver" is formalized by t w o operations linked together a .message B : : : [operation] Promote message A B : : : [link between a and b] Op 1 == 9 B message ^Promote message a We use here the promotion technique, which is used in Z when a global operation is dened in terms of a local operation upon an indexed component [12, p. 193].
The aim of this paper is not to detail the Z part of the formalization, but we c hose this representation of message passing, in a rst attempt, to separate the Z operations in the same way they are split in the OIG, while keeping the formal link betwe e n Z s c hemas.

Message passing to collections
For messages passed to collections, the description of the operation follows rule 3 described in the previous subsection for message passing to one object.The dierence is in the way the operation aects the system.

Message sequencing
The message sequencing involves labeling the messages with Dewey Decimal numbers (for example 1, 1.1, 1.1.1,1.2, 2) that represent the order in which the messages are sent.In the Fusion OIG, the sequencing is not mandatory, it is a simple annotation.This leads sometimes to ambiguities, as arrows with no sequences take place at any time, i.e., the messages can be generated at any time.For example in Fig. 11, does rep occur after req1 or after req3?There are situations where this information may be needed (especially at a high-level design, where one could delay making a decision as to when certain operations can take place) so we do not make the sequencing mandatory.The sequencing labels allow us to dene formally in which order the messages are sent.If there is no label, no explicit sequencing is generated in the formal part.For a complete example of message sequencing formalization, see section 5.
BCS-FACS Northern Formal Methods Workshop, 1996  The OIG sequencing is used to generate the sequencing of Z operation, dened using the corresponding schema operator ( o 9 ).The \leaves" operations are rst dened formally, then composed and linked with the \root" operations.
Op We illustrate in this section, how the formal model of the OIG is useful, by reconsidering the role of the OIG in the Fusion development lifecycle.The denition of the OIG aims to give a rst \implementation", at a high level of abstraction, of the requirements captured at the analysis phase.Note that the two models are complementary, and that, unlike our transformation rules dened for the analysis level, the Z specication does not capture all the information of the Fusion OIG, although it describe formally the operations involved (for example the controller of an operation is not described in the formal model).
We give in the following a complete example of the formalization of an OIG taken from [4].In [1], we have illustrated the formalization of the analysis model of a gas delivery station.The enable pump operation, dened at the analysis model is detailed in the design phase by an OIG.
We will demonstrate that the Z enable pump 2 operation, derived from the OIG (Fig. 13), is a renement of the enable pump operation dened at the analysis model (and derived from the Fusion operation model of the operation illustrated in Fig. 12).
We give here an extract of a more complete specication [1].The analysis models (Object Diagram and Operation Model) of a pump and an operation enable pump are shown in Fig. 12  8 i; j : terminal (i:ident = j :ident , i = j ) 8 i; j : pump (i:ident = j :ident , i = j )  In the following, we give the Z model of the OIG given in Fig. 13.As mentioned in Transformation 6, we rst describe the \leaf" operation Op 11 (labeled 1.1 in Fig. 13).We describe the \receiver" part of the operation (see Transformation 4): reset Display grade 0 = 0 volume 0 = 0 c ost 0 = 0 BCS-FACS Northern Formal Methods Workshop, 1996 Note that we don't detail the specication of the class Display.W e'll do the same for other classes, when the formal denition is not relevant.
We then describe the \sender" part of the operation: In order to prove that enable pump 2 is a correct renement of what we had at the analysis level (enable pump), we h a v e to establish that both the following statements are theorems: 8 System; id? : PUMP ID; input?: T erminal; n? : Pump pre enable pump ) pre enable pump 2 (1) 8 System; id? : PUMP ID; input?: T erminal; n? : Pump pre enable pump ^enable pump 2 ) (9 System 0 enable pump) Eq. 1 expresses that we weaken the preconditions of the initial operation, by taking into account more possibilities.Eq. 2 expresses that we strengthen the operation.
The proof, though not given in this paper, is not dicult.The help of a tool such as ZANS [7] t o calculate the preconditions and to expand the schema denitions is valuable.

Conclusion and future works
In our experiments with FuZE, we found that formalizing the Fusion models helped identify problems with the Object Model, for example, inconsistent use of attribute names, undened variables, and missing operation arguments.More generally, formalization revealed ambiguities in the semantics of Fusion, gaps in our knowledge of the system being modeled, and inconsistent requirements.The feedback from the translation activity can be used to improve the Fusion models.
The primary objectives of integrating Fusion and Z is to create analyzable Fusion models and facilitate generating Z specications.The integration allows one to use Z type checkers (e.g., ZTC and f uzz) and Z animation tools, such as ZANS, to analyze models.In our experiments, we used ZTC, f uzz and ZANS and found that doing such analyses can reveal additional problems with the Fusion models (as well as with the formalization of the problem).
Presently the scripts are written to handle Fusion analysis models.Since Paradigm Plus has metainformation about the types of methods supported, the scripts could be generalized to handle all the OOMs supported by P aradigm Plus (e.g., Fusion, Rumbaugh, Coad Yourdon, Shlaer Mellor).Depending on the type of OOM used, the script can be written to handle the variation in notation between methods.
The improved transformation rules and expansion of FuZE support to include the design phase will enable consistency checks and incremental development using an integrated formal/informal development environment, moving the state of the art towards providing the tool supports industry requires to take advantage of the rigorous analysis capabilities available when using formal methods for formalizing objectoriented models.In the future we plan to exercise FuZE with larger, more complex models.BCS-FACS Northern Formal Methods Workshop, 1996

Figure 3 :
Figure 3: An extract of the Mathematical Toolkit

Figure 4 :
Figure 4: Customer class structure diagram

Figure 5 :
Figure 5: Object Model showing aggregation structure

Figure 6 :
Figure 6: An object model showing generalization hierarchy

Figure 7 :
Figure 7: Fusion Object Model of an ATM

[Figure 9 :Figure 10 :[
Figure 9: From the Analysis phase to the Design phase

Transformation 3 [
Message passing d: Directory Description: operation Directory: secure(fn: Filename) of the method //description in natural language secure(fn: Filename) A message passing (labeled arrow) is represented in Z as an operation schema.The label of the arrow is used as a name for the function, and the parameters are translated as inputs of the operation schema a .The described operation modify the receiver object.a Note that this transformation needs human intervention, a s w e h a v e not yet found a way to translate a description in natural language into Z!If we consider the specication described in section 4.1, we get the following Z operation schema: Formal description of the operation] BCS-FACS Northern Formal Methods Workshop, 1996 CASE-based Rigorous Object-Oriented Modeling We treat bidirectional dataows and multiple arrows in the subsection 4.4, concerning the sequencing.Transformation 4 Link between sender and receiver message a: A b: B

Transformation 5
Message passing to collections Description: change_accessmode(newval:Mode) files: File method File: change_accessmode(newval: Mode) Change access mode to newval les [For all the les] : : : [description of the operation]

A
new object is represented in Z as an output binding of the state schema corresponding to its class: create d? : Data i! : Item i!:data = d? 5 Strength of the formalization

Figure 12 :STATUS
Figure 12: The enable pump Fusion Analysis models
We can then dene the rst step of enable, which is the operationOp11: Op 11 == 9 Display reset ^Promote reset We do the same for the Op 12 and Op 13: Op 13 == 9 Motor start ^Promote start Now w e can describe the sequence of the 3 operations, dening a new operation enable 1 : enable == Op 11 o 9 Op 12 o 9 Op 13 The operation enable is now seen as a \local" operation.So we dene the promotion for it: And then we dene the corresponding operation Op 1: Op 1 == 9 Pump enable ^Promote enable The op 1 operation itself is seen as a \local" operation, related to enable pump.S o w e dene rst its promotion schema: Finally, w e can formally dene the operation enable pump 2 (n) as: enable pump 2 == 9 Terminal Op 1 ^Promote Op1