1. SECTION 4: OO METHODOLOGIES
B. “Guidelines for Formalizing Fusion Object-oriented Analysis Models”, Bates, Bruel, France & Larrondo-Petrie
CA B. Bates et al

2. 4.B Fusion & Z
The paper by Bates et al (12 pages in all) is sub-divided as follows:
1. Introduction (1page)
2. Integrating formal and informal specification techniques (3.5 pages)
2.1 Overview of Fusion
2.2 The Z notation
3. Fusion to Z translation guidelines (5.5 pages)
3.1 Object model
Representing objects in Z (Rules 1-4)
Representing relationships in Z (Rules 5-7)
Representing aggregation structures (Rule 8)
Representing generalization hierarchies
3.2 Formalizing the Interface model (operation models only)
Representing operation models (Rule 9)
4. Conclusion (1 page)
References (1 page) - Not required for CA422
CA B. Bates et al

3. For details consult the paper by Bates et al.
But, as a start, it may help to note the following summary points:
- (Abstract) “Our approach involves integrating the Z formal specification style with the Fusion method. The result is an OOM that produces semantically analyzable Fusion models of behaviour at the requirements level.” [my underlining]
- (Page 2) “In an interpretive FIST [integrated formal/informal specification technique], the formal model provides a more precise description of behaviour captured by the informal model”
- (Pages 2 & 3) “In this paper, we describe an interpretive FIST that integrates Fusion analysis models with the Z specification style. Transformation rules are defined for some aspects of the formalization, some of which can be mechanized.”
- (Page 3) “In Fusion’s analysis phase the required behaviour of the system is described by
- an Object Model … static structure …three types of association
- an Interface Model…externally observable behaviour …
Operation Model …
Life-Cycle Model [not addressed in the paper] …”
- (Page 5) “… the Fusion Object Model has three major classes of constructs: objects (classes), relations, and annotations (invariants). In the following subsections we give rules guiding the translation of instances of these constructs to Z specifications.”
- (Page 9) “Once the parts of the object model are defined they are collected in a schema that is a representation of the model. Invariants involving parts that were separately defined are expressed in the predicate part of this schema.”
CA B. Bates et al

4. In the paper by Bates et al, some elements of Z are used that we have not emphasised to date.
- Schemas as types: A schema can be used where we require a composite type, that is one with a variety of different components. For example, the schema
__SchemaOne___________________________
| a:
| c:
_____________________________________________________________
Corresponds to a composite tye with two components: an integer called a, and a set of integers called c.
We may introduce elements of this type in the usual way. For example
S: SchemaOne
Introduces an object of schema type SchemaOne.
- Binding: There is a special notation in Z (not supported by PowerPoint unfortunately) to allow one to list the components of an object of schema type and the values to which they bound. For example, we might wish to have (for the previous example)
S.a = 2 and S.c = {1,3,3}
We can see that the schema type SchemaOne is the set of all bindings in which a and c are bound to an integer and a set of integers, respectively.
- Schemas as declarations: For illustration, introduce
__SchemaTwo___________________________
|ac  c  
which describes a subset of the bindings described by SchemaOne.
The following set consists of those sets of integers c that contain the integer 0:
{SchemaTwo|a=0•c} (or, alternatively, {s:SchemaTwo|s.a=0•s.c}
CA B. Bates et al

5. - Characteristic binding (): If a set comprehension has no term part, then the type of objects in the set depends upon the characteristic tuple of the declaration.
For example, in the set {a:; c: | ac  a=0} the characteristic tuple is the pair (a,c) and the type of objects in the set is X. The set consists of every pair (a, c) that meets the stated constraint.
On the other hand, since in a schema the order in which components are declared is unimportant, the characteristic tuple of {SchemaTwo|a=0} is quite different from (a, c). A typical element of this set is a binding associating a with 0 and c with some set containing 0; the characteristic tuple has one component. The characteristic binding is defined (a bit confusingly) as the binding where each component of a schema is bound to a value of the same name and is written using , for example SchemaTwo. Whenever SchemaTwo is used, variables a and c must already have been declared and their type must match those given in the declaration part of SchemaTwo. [See “real-time” lecture notes for the actual Z notation].
CA B. Bates et al