Towards Rigorous Analysis of Fusion Models : The MIRG Experiences

Most popular graphical object-oriented methods (OOMs) provide good mechanisms for handling complexity and constructs that facilitate the creation of abstract, highly-structured models of systems. These qualities make the use of OOMs in the development of complex systems attractive. On the other hand, the models produced by these methods are not amenable to rigorous semantic analysis. Research carried out by the Methods Integration Research Group (MIRG) at Florida Atlantic University on integrating formal speci cation techniques (FSTs) with less-formal, but richly-structured, graphical OOMs is concerned primarily with developing precise and analyzable counterparts of the models produced by the OOMs. In this paper we give an overview of the current MIRG work on using FSTs to support rigorous analysis of OO models. Speci cally, we outline our approach to formalizing Fusion's design and analysis models, and indicate how the formal models can be used to support semantic analysis across requirements and design development stages.


Introduction
In most mature graphical object-oriented methods OOMs, the syntax of the modeling constructs is wellde ned, but the underlying semantics are loosely described using a mixture of natural language and diagrams.The lack of modeling precision can often lead to disagreements within a software development team over appropriate use of the modeling constructs, and limit their ability to rigorously analyze the models.
The loose interpretations provided by textbooks on methods are often intentional: their intended purpose is to guide the use of the notation and not to prescribe how they will be used and interpreted.This allows the developer to tailor the interpretations of the notation within the loose constraints provided by the guidelines to his her usage.If the models are to be used as a basis for further development, or as a communication medium in a team environment, it is essential that there be a means for determining the precise meaning of the models.
One approach to making OOMs more precise and amenable to rigorous analysis is to provide modelers with mechanisms that allow them to express modeled concepts in a precise and analyzable manner.Work on integrated formal and informal speci cation techniques have as their goal the development o f s u c h mechanisms.Here, integration means providing a bridge from the informal modeling constructs to the formal notation e.g., see 6 .Over the last year, the Methods Integration Research Group MIRG 1 at Florida Atlantic University has worked primarily on formalizing OO modeling techniques, in particular, the Fusion method 5 e.g., see 1, 6 , and, more recently, the Uni ed Modeling Language UML 2 e.g., see 9 .We used the formal notation Z 10 in our work because of its maturity, expressiveness, the availabilityof good analysis tools, and its apparent compatibility with OO analysis modeling concepts.
Our previous work focused on the formalization and analysis of OO analysis models, in particular, the formalization of class diagrams.This work resulted in a prototype tool, called FuZE Fusion Z Environment 3 , that generates Z speci cations from Fusion Object Models.In this paper we present our most recent w ork on re ning and extending the core concepts underlying FuZE.Our re nements have resulted in new Object Model transformation rules based on an extensional view of classes i.e., a class is viewed as a collection of instances.The extensional semantics makes it unnecessary to model object identi ers explicitly as in our previous approach.This simpli ed the modeling of the more dynamic design models by removing the need to explicitly maintain the uniqueness of object identi ers, especially when objects are created and destroyed.We h a v e also developed a more stable formalization technique for Fusion design models that is an improvement o v er the technique described in 4 .We also describe our planned extensions to the FuZE prototype tool.
In section 2 we outline the new rules for formalizing Fusion analysis models.In section 3 we illustrate our approach to formalizing Fusion design models, and outline how the formalizations can be used to establish the consistency of design models against the analysis models.In section 4 we outline our planned extensions to the FuZE prototype, and in section 5 we conclude with an outline of our plans to extend the work described in the paper.

Formalization of Fusion Analysis Models
In Fusion, the structural aspect of a problem is modeled by an Object Model, and the required behavior of a system is modeled by an Operation Model that consists of operation schemata and a lifecycle model.A Fusion operation schema describes the required behavior of a system operation in terms of the conditions under which the operation can be executed and the externally observable e ect of the operation.A lifecycle model de nes restrictions on the relative ordering of operation invocations.
In this section we illustrate the formalization of Fusion's Object and Operation Models.To illustrate our approach w e formalize the Object Model and an operation schema for a system that keeps track of depots that store environmentally damaging chemicals taken from 5 .We will refer to this system as the ECO system.The ECO system consists of depots, each h a ving a loading bay for o oading drums of chemicals and a set of storage facilities called store buildings.The system is required to generate reports on the status of each depot, and allocation lists that list drums allocated to, and stored in store buildings.

Formalization of the Fusion Object Models
The approach to formalizing the Object Model described here di ers from our earlier work in that the formalization is not based on an intensional model of a class.The intensional model we used required the explicit modeling of object identi ers, which meant that constraints expressing the uniqueness of identi ers had to be explicitly stated.The problem is exasperated at the design level, where management of object identi ers accounts for a disproportionately large number of conjuncts.This problem led us to consider an extensional semantics for classes.In this paper, classes are extensionally de ned as sets of instances drawn from a Z basic type.Instances are related to their attributes and or components via Z functions.
Below w e outline the rules for formalizing Object Model constructs, and give examples of their application.The Object Model in Fig. 1 will be used to illustrate the rules.Other constraints provided b y s p e ci er Note that a relationship in an aggregate instance must be a subrelation of the larger relationship between the classes concerned.Also, the range restriction for a function mapping aggregates to a particular class of components e.g., agg comp 1 can be strengthened by making the range equal to rather than a subset of the set of instances of the function's target class.
Below w e apply Rule 3 to the formalization of the Depot aggregate class.In our approach, a specialization hierarchy represents a subdivisioning of the root superclass object space, where a root superclass is a class that is not a subclass of another class.Subclasses can partition their superclass's object space, or there could be superclass instances that are not subclass instances.
Below w e outline the rule for formalizing specialization hierarchies.
Towards Rigorous Analysis of Fusion Models: The MIRG Experiences Rule 4 Formalizing Specialization Hierarchies A subclass, SubClass, in a hierarchy with a root superclass whose objects are r epresented by the set, SUPERCLASS, is speci ed as follows: SubClass subclassobjects : P SUPERCLASS subclass attribs : SUPERCLASS 7! SubClass Attributes dom subclass attribs = subclassobjects Other constraints provided b y s p e ci er The schema SubClass Attributes de nes the attributes that are p articular to the subclass.Given a specialization hierarchy with a root superclass de ned by a schema, Superclass, and subclasses de ned by schemata Sub 1, : : : , Sub n, the following Z schema de nes the properties of the hierarchy: SuperClassStruct SuperClass Sub 1; : : : ; Sub n Constraints on hierarchy Some of the constraints that are generated for specialization hierarchies are given below: If the subclasses Sub p, : : : , Sub q partition their superclass, then the following constraint m ust be present: hsub p objects; : : : ; sub q objectsi partition super objects If the subclasses Sub p, : : : , Sub q are disjoint then the following constraint m ust be present: disjoint hsub p objects; : : : ; sub q objectsi Below w e give the formalization of the Building specialization hierarchy in the ECO system Object Model: Once the parts of the Object Model are speci ed, a Z schema for the model is obtained by including schemata de ning the specialization hierarchies, aggegates, relationships, and classes in a con guration schema.A con guration schema can be viewed as a characterization of the valid states of a system.The con guration schema for the ECO system is given below:

Result
: A status report of the stores in the depot and the loading bay has been sent to the manager.From the above it can be seen that Fusion's operation schemata are expressed mostly in natural language.Automatic generation of formal speci cations from such models is not conceivable given current technology, but the structured form permits generation of partial formal speci cations.We developed the following guidelines for formalizing Fusion's operation schemata: 1.The operation name is used as the name of the Z operation schema.
2. If the Changes section is non-empty, then the declaration SystemCon g, where SystemCon g is the con guration schema for the Object Model, is made in the Z operation schema.This declaration indicates that a change in the con guration state is possible.More precisely, i t i n troduces unprimed variables representing con guration elements before the operation's execution, and primed variables representing con guration elements after execution, and a predicate expressing invariant properties on before-and after-con gurations.If the Changes section is empty, then the declaration SystemCon g, that introduces a predicate equating the before-and after-con gurations, is made.
3. In the Reads section, supplied elements are inputs to the operation, and the other elements are elements in the before-con guration.For each supplied element an input variable with a name ending in `?' is declared in the Z schema.For each of the other elements in this section a variable representing the element is declared, and a conjunct stating that the element is in the set of instances for the class in the before-state must be stated in the predicate part.
4. In the Changes section, each c hanged element is represented by a v ariable.Other variables representing components and or attributes of these elements can also be added if they make the predicate part easier to construct.The new elements are instances created by the operation.For each new element a conjunct stating that the element is in the after-state, but not in the before-state is required.For all other elements, conjuncts stating that the elements are in the before-, and after-states are needed.
5. The data declared in the Sends section are declared as output variables in the Z schema.6.The description in the Assumes section is reexpressed as a conjunct in the predicate part of the Z schema.The conjunct is the precondition for the operation.
7. The description in the Result section is reexpressed as a conjunct describing the e ect of the operation in the predicate part of the Z schema.
2nd BCS-FACS Northern Formal Methods Workshop Towards Rigorous Analysis of Fusion Models: The MIRG Experiences Because of the natural language used, the formalization of the Assumes and Result sections requires signi cant h uman input.However, some of the above guidelines identify conjuncts that must be present i n the Z schemata.We used the above guidelines to develop the following Z schema for the depot status operation: The following models are produced during design in Fusion: Object interaction Graphs depict the object interactions that take place when system operations are invoked.
Visibility Graphs model access restrictions and lifetime bindings of objects.The Inheritance G r aph de nes the inheritance structure of the solution.A Class Description is produced for each class in the design.In 4 w e presented our early attempt at formalizing Fusion's Object Interaction Graph.That approach used the Z promotion mechanism to promote the e ect of messages on individual objects to the system level.We found that this approach o ered few opportunities for automated support, and, furthermore, the Z analysis tools e.g., the animation tool could not handle analysis of schemata that explicitly used schema bindings.
This led us to the approach outlined in this section.In our current approach, the formalization is based on information in all four of the Fusion design models.The result is a more complete and precise design model that can be veri ed against analysis models.Key to our current approach is the Design Object Model DOM, a design model that brings together descriptions of the static aspects of a design found in Fusion models.The DOM allows us to specify functionality in the same manner analysis-level functionality i s de ned, that is, as transformations on design-level con gurations.The e ect of OIGs is formalized in terms of transitions on the con gurations states de ned by the DOM.Veri cation of design-level functionality involves establishing a relationship between the analysis Object Model and the DOM, and checking that the e ects of OIGs are consistent with the e ects speci ed for the system operations at the analysis level.
2nd BCS-FACS Northern Formal Methods Workshop

Formalization of Design Object Models
Descriptions of static features of a solution found in Fusion design models are brought together in a DOM.Speci cally, Class Descriptions and the analysis Object Model provide most of the information needed to build a DOM.The development of a DOM is guided in our approach b y few rules, for example, an object, O1, that is bound to another object O2, is modeled as an object attribute of the O2 class.If an object, O1, is declared as shared but not bound to O2 in a Class Description, then a reference depicted as a directed arrow from the O1 class to the O2 class is present in the DOM.Cardinality constraints for references are obtained from the analysis Object Model.These rules are all that are needed to obtain a DOM for the ECO system.
Part of the DOM without annotations for the ECO system is given in Fig. 2. We do not show the subclasses of Allocation List and Report because they are the same as in the analysis class model see Fig. 1.The missing DOM annotations express additional constraints on object structure.The formalization of DOMs is no di erent than the formalization of analysis models.Below w e give some of the schemata resulting from the formalization of the ECO system DOM.The design-level con guration schema, characterizing the valid design object structures for the ECO system, states the following constraints: 1 : E v ery store building is part of a depot in a con guration.
2 : E v ery loading bay is part of a depot in a con guration.3 : The drums in a con guration are exactly those drums in store buildings and drums on loading bays.4 : A drum on a loading bay cannot be in a store building.5 : The store buildings associated with a loading bay are precisely those storing building in the loading bay's depot.

:
The neighbours of a store building in a depot is a subset of the depot's store buildings.7 : Monitors are unique across depots and loading bays.8 : In a con guration, the depot referred to by a report is a depot in the con guration.9 : The drums associated with a store building in an allocation list are a subset of the drums in the store building.
10 : The drums associated with a store building in a status allocation list are precisely those drums stored in the store building.
11 : The store buildings in a status report are store buildings of the depot associated with the report.
Part of the con guration schema for the ECO system DOM is given below:

Formalization of an OIG
The e ect of messages on objects are de ned in method speci cations found in Class Descriptions.We use these informal descriptions to formalize the e ects of OIGs.The use of natural language to specify methods severely limits the automated support possible for the formalization of the OIG.We are developing an intermediate notation that can help bridge the gap between the natural language descriptions and Z speci cations.
2nd BCS-FACS Northern Formal Methods Workshop  We h a v e developed a technique that human speci ers can use to systematically formalize an OIG.In this section we illustrate the technique by formalizing the OIG for the depot status operation shown in Fig. 3 adapted from 5 .
The narrative accompanying the OIG is given below: operation Depot:depot_status Create a new allocation list. 1 For all s in the stores collection put details of the store contents into the allocation list. 2 Retrieve details of the contents of the loading bay.
3 Create a new status report initialized with the loading bay contents and the allocation list.4 Notify the depot monitor of the status report . 5 In this paper a parent message is one that spawns other messages called child messages.For example, depot status is a parent message with respect to the messages labeled 2, 3, 4, and 5.A leaf message is one that does not spawn other messages.Formalization of an OIG starts by de ning the e ects of leaf messages, then de ning the e ects of parent messages in terms of the e ects of their child messages.
The formalization of the leaf message 1 create list is given below: create list ECO DesignState al : ALLOCATIONLIST al 6 2 allocations statusallocations 0 = statusallocations f alg When formalizing messages to collections, the e ect on a message on a single object in the store is speci ed rst.The resulting schema is then used to specify the collective e ect of the messages.For 2nd BCS-FACS Northern Formal Methods Workshop example, formalization of the e ects of store content messages results in the following: E ect on a single store object: The other leaf messages are similarly de ned.In general, the e ect of a leaf message is described by a schema of the form: : pre1 _ pre2 _ : : : objects = objects 0 objects; objects 0 ; are sets of OBJECTCLASS in the before and after states respectively In the above s c hema pre1; pre2 : : : are the conditions called preconditions that must be true for the message to have the de ned e ects on the object represented by object.In our formalization, if none of the preconditions hold, then the state i.e., the set of object instances is unchanged.
Below w e give the declarations for operation schemata of the remaining leaf messages these declarations will be used to illustrate the formalization of parent messages: In general, the formalization of the e ect of a parent message, associated with child messages Child 1, : : : , Child n, results in a schema of the following form: Where Intp p is an integer speci es the e ect of an internal action taking place before the interaction described by the following schema, Child p, takes place.The interactions that take place can vary from invocation to invocation of a particular parent operation e.g., the particular behavior exhibited may depend on the inputs to the operation.Each disjunct represents an alternative behavior.Before composition, the inputs and outputs declared in the schemata describing the e ects of child messages are renamed to re ect passing of data from one object to another, and to remove the symbols `!' and `?'.
T h e Z s c hema for the depot status operation is de ned as follows: depot status b = create list o 9 store content coll s outs=s outs! ^put in loope ect s outs=contents?; al=a o 9 ldcontents lddrums=lddrums!o 9 create report lddrums=drums?; al=list?o 9 notify status report=report?

Towards rigorous consistency checking
At the design level, the formalization of the Object Interaction Graph produces a model that can be formally veri ed against the formalized Operation Model.Our formalization approach allows us to base consistency checking on classical Z re nement proofs 10 .We use the following approach t o v erify OIG formalizations against formalized Operation Models: De ne a schema linking the design state as characterized by the con guration schema of the DOM and the analysis state as characterized by the con guration schema of the analysis Object Model.
Prove the applicability and correctness theorems for the operation.The applicability theorem essentially states that if the analysis level operation can start in a state, then the design level operation must be able to start in the corresponding state.The correctness theorem states that the e ects de ned at the two levels must be consistent with each other.The proof obligations can be stated as follows: Let Aop and Cop be respectively the abstract operation from the Operation Model and the concrete operation from the OIG, and let Abstraction beaschema relating the concrete state space including inputs and outputs to the abstract state space.Building FuZE on top of a commercial CASE tool has the advantage of providing an industrial-strength environment, but it also has the disadvantage that most researchers do not have free access to the tool.MIRG is currently working on extending and broadening the scope of the FuZE prototype, so that it can be used with a variety of CASE tools, OO models, and formal notations.
Our current focus is on extending the tool to other graphical OOMs, and making it independent o f particular CASE tool representations and meta-models.To facilitate portability of the new environment, we will develop a common representation of OO models, and base the transformations to a formal notation on this representation.This will make the OO model-to-formal model transformation independent o f a particular tool vendor's internal meta-model and representation.Users of particular CASE tools will have to create scripts that translate from the internal representation of the tool to the common representation in order to use our formalization tool.
The Common Data Interchange Format CDIF3 is one means of representing the models so that it is accessible to all CDIF compliant CASE tools.Though CDIF provides a good interface format, importing data is di cult.An alternative means of representing the meta-information is to de ne SGML tags for the various OO modeling constructs.SGML tags are easy to read and use.Furthermore, there are many public domain programs that are available on the internet to parse convert SGML documents.SGML tags also facilitate manual input of data.Once the meta-information has been captured and represented in a well de ned format, it becomes easy to dynamically parse the data and process it.Algorithms similar to the ones used in FuZE can then be used to formalize, typecheck, and animate the models.A context level model of the proposed extension to FuZE is shown in Fig. 5.In this paper we describe the results of our most recent w ork on formalizing Fusion analysis and design models.Our previous work on formalizing Fusion analysis models resulted in a prototype tool that generates Z speci cations from Object Models.The prototype was used by students on class projects, and by members of the Methods Integration Research Group MIRG 4 on case studies.This use showed clearly the bene t of automated support.In our experimentations with FuZE we used ZTC 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.Another bene t of the formalization is that it uncovers de ciencies in the modeling technique.When such de ciencies are addressed, a well-de ned notion of well-formed models can be formulated and used to drive the analyses of the models in CASE tools.Our attempts to extend the formalization to the design stages revealed some problems with our former formalization technique.This led to the formalization approach described in this paper.

Towards Rigorous Analysis of Fusion
We are currently developing a design notation for describing object operations and interactions that will facilitate the automatic generation of Z speci cations from analysis operation schemata and from Object Interaction Graphs.This intermediate notation will help bridge the gap between the informal Fusion descriptions and the more precise Z notation.We are also working on developing support for rigorous renement o f F usion design models, and extending our formalization technique to cover inheritance structures involving rede nition and polymorphism.The objective of our research is to create a development method that exploits the complementary nature of informal structured and formal development techniques.

Figure 1 :
Figure 1: The ECO System Object Model

Figure 2 :
Figure 2: The ECO System Design Object Model

Figure 3 :
Figure 3: The ECO System Object Interaction Graph

Figure 5 :
Figure 5: Context level model of the proposed extension to FuZE An aggregate class is a class that contains class components that may be related.In Fusion, an aggregate does not imply lifetime binding of components and the aggregate.An aggregate allows one to treat an Object Model substructure as a class.Below w e give the form of Z schemata de ning aggregate objects.2ndBCS-FACS Northern Formal Methods Workshop Rule 3 Formalizing Aggregate Classes An aggregate class, AggClass, with attributes de ned by an attribute schema, Agg Attributes, component classes de ned by schemata Comp 1, : : : , and relationships rel1 between CLASS1 1 and CLASS2 1, : : : , is formalized by a schema that has the following form: a : aggobjects agg rel1a rel1 ^: : : An operation schema describes a system operation in terms of data read by the operation, items changed by the operation, events sent to other objects, conditions that must hold for the operation to execute, and the e ect of the operation.An example of an operation schema is given below: De nitions of SR drums and depot holdings status drums 0 = status drums f status report 7 !SR drumsg status alloclist 0 = status alloclist f status report 7 !alloc listg statusallocations 0 = statusallocations f alloc listg allocation holds 0 = allocation holds f alloc list 7 !depot holdingsg monitors 0 = monitors f depot 7 !status reportg : : : : : : A ll other variables are unchanged 3 Formalization of Fusion Design version of the Fusion to Z rules were implemented in a prototype tool, called FuZE Fusion Z Environment, built on top of the Paradigm-Plus OO modeling CASE tool Release 2.01 8 .Within FuZE one can invoke Z tools to analyze the Z speci cations produced by the transformation subsystem.In the current v ersion of FuZE one can call the typechecker ZTC, and the animator ZANS from within the tool.A context level model of FuZE is shown in Fig.4.Using a Fusion Object Diagram as input, the FuZE Context level model of FuZE formalization process generates a le that is readable by the Z analysis tools.The ZTC typechecking tool 7 is launched by running a script, and it produces a type-checked Z speci cation in a readable ASCII format.A Latex le can be produced from the ZTC produced le by calling another script.LaTeX can be launched within FuZE to produce a Latex'd Z speci cation.The Z animator, ZANS, can also be launched within FuZE to formally analyze the Z speci cations.The FuZE user manual is available on the Web 2 , and students in the graduate software engineering courses have used it on modeling projects. early