Integrating Object-Oriented Analysis and Formal Specification

Integrating Object-Oriented Analysis and Formal Specification

João Araújo Júnior

Universidade Nova de Lisboa,

Faculdade de Ciências e Tecnologia,

Departamento de Informática,

2825 Monte Caparica,

Portugal

( [e-mail] )

Pete Sawyer

Lacaster University,

Computing Department,

Lancaster LA1 4YR,

United Kingdom

( [e-mail] )

Abstract One of the main inhibitors to the widespread acceptance of formal specification methods is the difficulty of integrating formal specification with the development process. Integrated methods seek to mitigate this difficulty by integrating formal specification with widely used structured requirements analysis methods. Several structured and formal methods are object-oriented. This paper describes a prototype integrated method and support tool called Metamorphosis that exploits the object paradigm to integrate OMT and Object-Z. Metamorphosis is presented here to demonstrate how object-oriented analysis methods such as OMT may be augmented to provide the additional rigour of formal analysis.

Keywords: object-oriented analysis, model component, formal method, integrated method, formal framework.

1 Introduction

Despite growing evidence that formal specification methods offer cost and quality benefits [11, 13], effective strategies for their deployment continue to evade many organisations. The integration of formal specification with widely used structured¹ analysis methods is seen as one way of making them more easily exploitable [15].

There are several reasons for the poor industrial take-up of formal specification methods, including:

• They necessitate process change by skewing project resource requirements towards specification.

• They are perceived to be hard to understand by non-experts.

• They provide poor support for identifying appropriate abstractions [17].

Structured analysis methods, by contrast, are widely used and understood. A typical process employing structured methods is illustrated in Figure 1. This starts when the initial statement of need is considered, and then the elicitation of stakeholders requirements (through interviews, questionnaires, etc.) can be realised. This interacts with the conceptual modelling activity to generate the requirements specification document. This document also embodies the models generated by that activity. Structured methods use a variety of notations such as data-flow (DFDs) and state diagrams in order to build models of different system aspects and thus help the analyst understand the application. They also include guidance on how to identify and model the relevant system and domain entities. However, for certain critical applications, they are insufficiently rigorous, leading to the risk that, for example, important constraints may remain undiscovered. A specification written in natural language supplemented with structured analysis models will embody a degree of imprecision that may be unacceptable.

Figure 1:
Structured methods in the requirements process

Formal specification can provide additional rigour and precision and is often seen as a substitute for structured methods. This is a mistaken view since structured and formal methods complement each others' strengths. Formal specification is better applied following the development of application understanding through structured analysis (Figure 2). For many organisations that have invested heavily in structured methods, this is the only feasible way to apply formal specification.

Figure 2:
Integrating structured and formal methods in the requirements process

Semmens [24] reports applications where both structured and formal methods are integrated into an analysis and specification process. The REAIMS FRERE module [2] provides guidance on how this can be achieved systematically. However, such integration is difficult and requires a high degree of process maturity in order to be repeatedly applicable.

An alternative is to more tightly integrate structured analysis and formal specification at the method level. Here, the results of a structured analysis are systematically or automatically mapped onto the constructs employed by formal specification.

Such method integration has the effect of adding semantics to the structured model. Of course, a complete formal specification cannot generally be derived automatically from a model. However, formal models of system components, their types and relationships can be automatically generated and used as the skeleton of a formal specification. This does the work of identifying the main system components for the formal specifiers. These can then flesh the skeleton out with predicates to specify constraints, preconditions, etc.

Early integrated method developments include SAV-DM [20], where DFDs, Entity-Relationship (E-R) diagrams and control information are developed using SA/SD [10] and used to derive VDM [16] models that are eventually integrated into a detailed VDM specification. Similarly, Semmens [23] has defined a mapping from Yourdon [29] to Z [27].

While valuable, these approaches are handicapped by the lack of a coherent common framework to link the two specification paradigms. The formal specification may model a variety of system aspects, each modelled by a different notation in the structured method. Hence, there is overlap of expressiveness but little common structure. This is potentially problematic where evolving requirements force frequent change to the conceptual models.

However, this is less of a problem if the structured method used is object-oriented (e.g., OMT [22], Shlaer-Mellor [25], OOSE [Jacobson 92], Booch [3], Fusion [4] and UML [8]) because the object model imposes a structure on the various conceptual models. Facon et al. [7] describe a mapping from object-oriented analysis to B [1]. Here, a mapping from the object model to the B virtual machine structure has been defined where a separate B abstract machine is developed for each object class. Synthesis [21], which integrates OMT and Z, and Hammond [14] that integrates the Shlaer-Mellor method with Z adopt a similar approach to Facon. Hammond uses Hall's [12] recommendations for writing object-oriented specifications in Z. France et al. [9] presents an environment that supports the integration of Fusion and Z. Lano [19] uses OMT and Booch combined with two formal languages: VDM++ and Z++.

Table 1 shows the comparison of the Metamorphosis method with some of the integrated methods discussed above - the Hammond's, Facon's, Synthesis, France's and Lano's approaches. The criteria used for the comparison are the following: the object oriented model and the formal method adopted, the provision of tool support, and the existence of formal framework specification. These criteria abstract the main aspects of the integrated methods.

Table 1:
Comparison with other integrated methods

The adoption of OMT by the Lano's approach, Synthesis and Metamorphosis reflect the maturity of this method. Hammond and Synthesis are compromised by the Z notation - the representation of classes and inheritance, and the mappings of the behavioural properties become more complex. The same occurs with the Facon's and France's approaches. In each of these cases, the formal specification is constructed in a way that mirrors the object model imposed by the structured method. However, this often necessitates the adoption of awkward conventions in the use of the formal method. This can be mitigated if the formal method directly supports the main object-oriented features of the structured method. Recently, several object-oriented extensions have been defined for existing formal specification methods [18] such as Z (e.g., Z++, OOZE, MooZ, ZEST, Hyper-Z and Object-Z [28]) and VDM (e.g., VDM++ [6]). Both the Lano's and Metamorphosis approaches adopt some of these extensions. Most of the methods provide tool support.

The biggest advantage of Metamorphosis is that it is the only integrated method to generate an object-oriented formal framework. This gives more abstraction to formal specifications, which facilitates their global comprehension and readability.

We have exploited the points discussed for the development of our integrated method; Metamorphosis. The rest of this paper is concerned with describing Metamorphosis in more detail.

2 Overview of Metamorphosis

Metamorphosis integrates OMT with Object-Z [5]. It does this through a framework that allows the analyst to selectively generate partial Object-Z specifications from OMT conceptual models. This helps ensure that the formal specification is consistent with the informal models in terms of the model's structure and components.

OMT is a mature and widely used object-oriented analysis method, but this fact does not mean that other methods (e.g., Fusion and UML) could not be chosen instead. In fact, the choice of the object-oriented method is not the main part of this work, but the derivation to an Object-Z framework.

Metamorphosis, at this stage, uses a subset of the OMT model components to derive the Object-Z counterparts that can be found in the majority of the methods. Therefore, the derivation mechanisms can be generalised to other object-oriented methods with, of course, appropriate tuning to satisfy the particularities of each method.

Of the several object-oriented formal methods that share constructs with OMT, Object-Z has the closest correspondence. This allows us to preserve the coherence of the structured and formal models. Many of the aspects modelled by OMT can be directly modelled in Object-Z using the same abstractions. Where an exact correspondence is lacking, it is possible to define mappings fairly readily. Another advantage of Object-Z is that it augments the first-order logic used by Z with temporal logic. Potentially, this eases the formal modelling of some dynamic system aspects.

Metamorphosis is not proposed as a replacement for OMT or any other method. Rather, it is a prototype that demonstrates how object-oriented analysis methods can be augmented where the application would benefit from the additional rigour of formal analysis. It proposes how the gap between an object-oriented analysis and the traditionally problematic development of a formal specification may be bridged.

There are two phases to the application of Metamorphosis. These are:

• The requirements analysis and modelling phase.

This is essentially the same as the conventional OMT analysis process where complementary structured conceptual models are developed to clarify understanding of the system and its requirements. The essential results of the OMT analysis are an object model and a dynamic model. These represent the system's structural composition as a collection of inter-related objects and its response to and processing of external events. OMT also recommends the development of functional process models, but their notation is not mathematically precise. Because of that, Metamorphosis assigns the detailed modelling of functional processes to the formalisation phase.

• The formalisation phase.

Here, the results of the analysis and modelling phase are used to systematically generate a "skeleton" formal specification. This broadly consists of declarations of the top-level Object-Z constructs such as classes and relationships along with types, attributes and state and operation schema declarations. History invariants can also be generated, which act as finite-state models of object behaviour. With tool support, much of this is automated. This skeleton must then be manually refined by specifying behaviour and constraints that cannot be automatically inferred from the structured model.

The two phases are not strictly sequential but can be interleaved so that, for example, the object model can be formalised before the structured dynamic models have been fully developed. Similarly, there is no compulsion to formalise the entire system specification. Individual classes, relationships, etc. can be formalised in isolation from others for which semi-formal models are still incomplete.

Figure 3 illustrates the Metamorphosis architecture. The inputs to the method are the requirements elicited from the customers along with domain knowledge etc. An OMT analysis is then performed to develop the conceptual models that are used by the framework generator to generate the skeleton Object-Z framework. This is then manually refined to complete the Object-Z specification. If a specification error is detected the object-oriented model must be corrected and the respective Object-Z skeleton generated again. Moreover, if the requirements have been changed the object-oriented model must be updated and the corresponding Object-Z skeleton derived.

Figure 3:
The Metamorphosis architecture

Tool support provides the automatic framework generation and provides easy cross-reference between the different models.

Using the tool, the conceptual models are described by completing a structured collection of templates. These prompt the analyst to supply the information needed for the generation of the skeleton Object-Z specification. The generated formal specification is structured to mirror that of the main structured models. Hence, for example, an Object-Z class specification is generated for each class identified by the OMT analysis. This helps isolate changes and the maintenance of consistency between the structured and formal models.

The area where the mapping is most difficult is that of OMT's functional process models. In OMT, these are pictured using data-flows and functional descriptions to explicate the functionality of class operations. It is difficult to devise a systematic mapping from these relatively unstructured descriptions onto operation schemas in Object-Z. However, it is worth questioning whether, aside from informal natural language descriptions, these should be developed within OMT at all since this is one aspect where formal models offer real advantages. OMT recommends the use of declarative descriptions of functional processes because they provide expressiveness without being implementation dependent. Object-Z specifications are necessarily declarative. Hence, in Metamorphosis, operations are identified in the requirements analysis and modelling phase but detailed functional process models are developed in Object-Z as operation schemas and their subsequent refinements.

Metamorphosis employs two types of conceptual model; object models and dynamic models. The functional process model is absorbed within the object and dynamic models.

3 Example - an ATM system

To illustrate the use of Metamorphosis, we use a simplified version of the Automatic Teller Machine (ATM) System presented in [22]. The OMT object diagram (omitting attributes) for this is shown in Figure 4. Here Object classes are represented by rectangles labelled with their class names. Associations between classes are represented by arcs connecting classes. In our model, these are all many-to-one. The Consortium class is an aggregation of Bank that is an aggregation of Transaction processor and Card verifier. The bifurcating arc connecting Account with Savings Account and Cheque Account represents an inheritance relationship.

Figure 4:
The Metamorphosis structural model for the ATM System

3.1 Object Modelling

The object model described by the diagram specifies that a Customer owns Accounts (either Savings or Cheque) and a Cashcard. The Cashcard performs Remote Transactions on an ATM that permits Access to the Customer's Accounts. The ATM is owned by a Consortium of Banks, which hold Customer Accounts.

Such a diagram is the most abstract representation of the object model developed during a conventional OMT analysis. How the object classes and their relationships are identified is outside the scope of Metamorphosis. Metamorphosis takes the abstract model as its starting point, develops it to add details of class components, etc. and then generates the formal skeleton.

The object model is encoded in Metamorphosis using templates: Figure 5 illustrates the class SavingsAccount encoded using a class template in the Metamorphosis tool. This captures the name of the class and the name of the system of which it is a component. In addition it contains:

Figure 5:
SavingsAccount Class Template

• An informal description (a data dictionary entry)

• Links to other templates where properties of the class are defined:

  ·

  The superclasses templates (as well as certain inheritance constraints)

  ·

  The attributes template

  ·

  The operations templates

  ·

  Generic type parameters for the class

  ·

  Constraints on the class state

  ·

  Class views or abstract interfaces

• A toggle to indicate whether instances of the class are transient or persistent

• A toggle to indicate whether instances of the class are passive or have a concurrent thread of control.

Metamorphosis is not prescriptive about the order in which this information is provided or its completeness. Of course, the more complete the information provided by the template, the more complete the generated Object-Z class skeleton will be. However, we recognise that it will not always be necessary or helpful to formalise every class. Similarly, rather than being identifiable prior to formalisation, details such as the need for generic class parameters may only emerge at a later stage (e.g., during formal specification). Hence, enforcing a strict order of development and the use of detailed models is sometimes inappropriate.

In the SavingsAccount example, the class is defined as a derived class of Account from which it inherits the attributes number and balance and the methods GetBalance, Deposit and Withdraw. To these, SavingsAccount adds its own attributes period and interest, and methods CreditInterest (see Figure 6) and UpdateDate. Moreover, a minimum value is defined for balance using a constraint template. In addition, Metamorphosis allows the specification of the persistence and concurrency of the objects of the class as they are objects' properties and must be recorded at the specification level. The SavingsAccount class is defined to be persistent and passive. It is persistent because its objects can be stored and remain indefinitely in the system, and passive as its objects react only when an operation is requested. Nevertheless, persistence and concurrency are not discussed in depth as it is out of the scope of this paper.

Figure 6:
CreditInterest Operation Template

Figure 6 illustrates the template used to define the operation CreditInterest. This includes:

• An informal description of the operation.

• Toggles to indicate whether the operation is public or private and whether it changes the object's state or not.

• Lists of input and output parameters to help identify the data flows.

• The option to describe any pre- and post-condi-tions (described textually using templates).

The core of Metamorphosis is the definition of how an Object-Z framework specification is derived from a semiformal description using the object model. Table 2 summarises the mappings from the Metamorphosis modelling components to Object-Z. Some of these are selected to be described in more detail next.

Table 2:
Summary of the mapping of the modelling components into Object-Z

From the class and associated templates, the skeleton Object-Z schema for the class SavingsAccount can be automatically generated as shown in Figure 7² . This contains:

Figure 7:
Generated Schema for SavingsAccount Class

• A list of the public class properties (including those that are inherited).

• A list of properties inherited from Account but renamed. These are the private attributes used to model its persistence and passivity/activeness (concurrency) that the formal framework generator defines for every class. They are always renamed for derived classes by concatenating the class name with "Persistence" and "Concurrency".

• A given set

  PERIOD. This is inferred from an undefined type appearing in the template description of the

  period attribute of the class.

• A free type

  SavingsAccountErrorReport, the values of which are inferred from the names of exceptions associated with the pre- and post conditions that may be defined for operations (see

  Figure 6 above).

• A constant

  minBalance (set to 20 in the example) that is inferred from the name of a constraint defined for the class (see

  Figure 5 above).

• The state schema where the class attributes

  period and

  interest are declared (with types inferred from the their attribute templates) and where the predicates that must form part of the state invariant are introduced. In SavingsAccount, these define the values of the persistence and passivity/activeness private attributes and are simply inferred from the appropriate settings in the class template. The predicate

  MinimumBalance is the name of the constraint template where the minimum value of balance is defined. This serves as a marker to the specifier that the semantics of what is defined in the MinimumBalance template must be manually specified and AND-ed with the other predicates.

• An initial state schema for which no predicates can be inferred but simply contains the word "Initial" as a reminder to the specifier that the initial state remains to be specified manually.

• A link to the schemas specifying the operations defined in the operation templates for SavingsAccount:

  CreditInterest and

  UpdateDate. That for CreditInterest is shown in

  Figure 8.

Figure 8:
Generated Schema for the Credit Interest Operation

Figures 7 and 8 illustrate that the structure of formal class specifications can be automatically generated because of the straightforward correspondence between OMT and Object-Z classes. Many of the property declarations can be generated (including operation schema declaration parts), and certain predicates can be inferred.

Where there is insufficient information to infer the corresponding Object-Z (e.g., to generate predicates to formally specify the constraint MinimumBalance), Metamorphosis inserts "reminders" to help the specifier locate the informal descriptions of what must be specified. The specifier is required to develop further private attributes and predicates as necessary to complete the formal class specification.

3.2 Dynamic Models

Section 3.1 briefly described how Metamorphosis helps map an OMT object model onto Object-Z by concentrating on object classes. This section looks at the dynamic model that complements the structural aspects described by the object model by picturing how the system reacts to events.

In OMT, scenarios are used to explore the system's response to external events. For example, a valid scenario for the ATM system might be that of permitting a bank customer to perform a cash withdrawal. This would be used to discover how the system's reaction should be contingent on the customer entering the correct PIN number, the state of their balance, and what other services they might choose. Scenarios are often dependent on complex combinations of environmental and internal states. It is typically impractical, therefore, to thoroughly explore every possible scenario. Hence, the set of system responses revealed by scenarios cannot be guaranteed to be complete. Nevertheless, used skilfully, scenarios are a powerful aid to validating the user requirements and revealing new emergent requirements.

Figure 9 (adapted from [22]) illustrates part of an event trace used to identify the inter-object message passing identified for the cash withdrawal scenario. The columns represent classes while the arrows represent invocations of an operation on the receiving class by the sending class. The ordering of events is implied by their position on the y-axis, hence the event request card precedes every other event in this scenario.

Figure 9:
Event trace for cash withdrawal scenario

Templates are used to encode event traces, where each scenario consists of a set of 4-tuples:

<sender, message, receiver, number>

Each tuple represents a message from the sender to the receiver class. The number represents the message's relative order in the scenario. Hence, the message EnterPassword from Customer to ATM is the 4th event to occur in the scenario.

Development of scenarios is performed following identification of the classes and relationships within the object model. Because they reveal requirements for inter-object message-passing, operation descriptions (such as that in Figure 6) are typically developed concurrently with scenarios. Of course, scenarios need not be explicitly encoded within Metamorphosis. However, the tool can help develop complex scenarios by, for example, providing lists (and associated descriptions) of all the identified operations and by providing the means to quickly document new operations as they are identified by the scenario.

Scenarios and their associated event traces reveal the system's dynamic behaviour in terms of inter-object events. A complement to this is the intra-object dynamics of how objects react to the receipt of a message. Finite-state models are used by OMT to model an object's life-cycle as a set of states and transitions between states. Transitions are triggered by the receipt of a message (perhaps in conjunction with the holding of some condition). The development of finite-state models therefore follow from the identification of the messages that an object may receive. States are abstractions of the set of values that the attributes of an object may hold. An event is an individual stimulus that changes the state of an object. Hence, finite-state models complement both the system-wide dynamics represented by event-tra-ces /sce-narios and the static models of object state in the object model.

Finite-state model templates represent a class life-cycle as a state-transition table composed of 4-tuples: <state before, event, pre-condition, state after>.

In Metamorphosis, transitions are labelled with event names, together with the conditions under which a transition occurs. The transition takes the form event [condition] in the diagrams. Figure 10 illustrates a simple state transition diagram that models, at an abstract level, the life-cycle of the Transaction processor class. This is started by the message Process bank transaction sent by the Bank class after receiving it from the Consortium class. The initial state for processing a transaction is Waiting for the next transaction. When a transaction arrives, the event Process bank transaction happens and we have the transition to the state Updating account. Afterwards, the transition back to the initial state occurs, with the transaction succeeding or failing.

Figure 10:
State transition diagram for Transaction processor

Figure 11 shows the corresponding Metamorphosis template. Here, the table at the bottom of the template holds the 4-tuples. This is built up by selecting elements from the three scrollable lists above it. The states are defined by the analyst (via another template) as abstractions over the attribute values of the class as the finite-state model is developed. However, the event list is generated from the names of all the operations defined for the class. The pre-condition list holds the names of the pre-conditions defined for the currently selected operation (see Figure 8 above).

Figure 11:
State transition table for Transaction processor

The finite-state model can be integrated with the Object-Z model of the class using Object-Z's history invariant construct. The idea is to have the whole system specified using a common mathematical notation, making the specification more concise and homogeneous.

The history invariant uses temporal logic in order to specify dynamic properties such as liveness. It is used by Metamorphosis to specify the finite-state model as an invariant condition on the class. This can be generated automatically from the state transition template as follows:

• Each transition is mapped onto a temporal logic expression of the form:

state before Ù pre condition Ù event ® à state after

Which is read as state after eventually follows from state before when event occurs and when pre condition is satisfied. For example the transition from waiting for next transaction to Updating account is specified as:

Waiting for next transaction Ù Transaction arrived Ù Process bank transaction ® à Updating account

• Where more than one transition is possible from a state (e.g., from Updating account), the transition expressions are XOR-ed, e.g.:

((Updating account Ù Success Ù Bank transaction succeed ® à Waiting for next transaction) XOR

(Updating account Ù Failure Ù Bank transaction fail ® à Waiting for next transaction))

• All the transitions are AND-ed to form an invariant expression using the temporal logic "henceforth" operator (‚) such as that for the Transaction processor:

‚ ((Waiting for next transaction Ù Transaction arrived Ù Process bank transaction ® à Updating account)

Ù

((Updating account Ù Success Ù Bank transaction succeed ® à Waiting for next transaction) XOR

(Updating account Ù Failure Ù Bank transaction fail ® à Waiting for next transaction)))

• If the object behaviour is composed by two or more concurrent state transition subdiagrams, the temporal logic formulas generated from each of them are AND-ed to form the complete history invariant of the objects of the class.

This logically forms a constraint on the state of the class. In Metamorphosis, however, we model it as a subclass. This has the advantage of enforcing the separation of concerns between the object and dynamic models. In addition, the initial state of the finite state model can be defined as the initial state schema of the subclass without conflicting with, or adding additional complexity to, that of the class itself.

Figure 12 shows the generated class schema for Transaction processor's finite-state model. This is a subclass of Transaction processor. The set of states that the object can hold is abstracted using a variable (whose name, processingTransactionState, is automatically generated) whose type is generated as a free type. This is an enumeration of all the object states defined in the state transition template. In the Transaction processor example, this is defined as:

TransactionProcessorState ::= waitingForNextTransaction | updatingAccount

Figure 12
. Metamorphosis class schema for Transaction Processor Object Behaviour

The initial state schema is used simply to specify the start state. Finally, the history invariant is as illustrated above (Note that the symbol "[]" represents the temporal logic henceforth operator (‚) while "$" represents the eventually operator (à)).

A shortcoming of the translation of the object behaviour described above is the absence of an automatic mechanism to check if the history invariant of the parent class is consistent with that of the derived class. At the moment, this has to be done inspecting both informal and formal models.

Metamorphosis defines specific rules to derive an object-Z counterpart for scenarios. For space reasons, they are not presented here, but they can be found in [Ara96].

3.3 Other model components

The preceding sections have described the translation from OMT to Object-Z of object classes and their components. OMT is a rich method and includes concepts at the same level of granularity as classes, such as relationships, as well as more course-grained structuring concepts such as modules.

As with classes, each of the object model relationships (except inheritance relationships that are part of the class template) are modelled using templates. These can also be modelled in Object-Z although Object-Z lacks the notion of relationships. Metamorphosis does this by using the Object-Z class - a class for each relationship. The class attributes are used to model the participating classes and state invariant predicates can be derived that model the relationships' cardinality.

In addition to classes and relationships, Metamorphosis supports the OMT notion of modules to help manage system complexity at a courser level of granularity than that provided by classes. Modules in Metamorphosis are named and defined as sets of public and private classes. These too are modelled in Object-Z as compound classes whose attributes are sets of the module's member classes.

4 Conclusions

Metamorphosis has been developed to investigate how best to exploit the trend towards object-oriented analysis in order to help improve the industrial take-up of formal methods. Its main novel features are:

• The exploitation of the object-oriented paradigm to preserve the coherence between a structured analysis and formal specification by making the shared structural components explicit and by providing a common reference framework. Although other object-oriented integrated methods have been proposed, we have purposely chosen to integrate two (structured and formal) methods whose respective object models makes them closely compatible. This greatly eases the mapping from the structured to formal models and helps ensure that consistency between the models is verifiable.

• The exploitation of Object-Z's history invariant to formally model a system's dynamic behaviour. Most other integrated methods concentrate on formalising the structural and functional process models (encompassed by the object model in object-oriented methods). This is because, for the most part, the formal specification methods that they employ are based on first-order logic. They therefore cannot easily express systems' dynamic properties at the same level of abstraction as their structural and functional properties. By contrast, our choice of Object-Z enables us to exploit its use of temporal logic and hence widen the applicability of integrated methods to domains such as distributed system development. The real value of the ability to formally specify objects' dynamic behaviour within the framework provided by Object-Z's class construct is not so much to add rigour to the dynamic model as to help maintain consistency as the formal specification is subsequently refined.

The Metamorphosis toolset has been developed in Smalltalk (and specified using Metamorphosis). It serves to demonstrate the feasibility of the Metamorphosis method and the importance of tool support. Of particular importance is the provision of cross-references between the various models and components comprising a system analysis and specification. This permits the analyst to select from lists of existing models and components and to navigate, reuse and integrate these when developing conceptual models. Related models can be automatically checked for consistency and the automatic generation of the formal skeleton helps minimise errors by performing "routine" parts of the structured-to-formal mapping.

However, the toolset is a prototype and exhibits a number of shortcomings. The major shortcoming is the rudimentary change management facilities that it offers. At present care must be taken to ensure that, as the formal specification is refined, it remains consistent with the structured models. In cases where fundamental structural problems emerge (e.g., if the formal specification reveals an inappropriate partitioning of functionality across object classes) then these must be rectified in the structured models. These must then be used to regenerate the formal skeleton. Clearly, this inhibits the tool's usability. In order to rectify this shortcoming, the toolset will require a reverse mapping to detect inconsistencies as they emerge and to help the analyst re-establish consistency with minimal effort.

Besides, there is an aspect that Metamorphosis - and the other integrated methods - must consider. At present, Metamorphosis integrates object-oriented analysis with formal methods, but the integration is still unilateral: a mechanism to automatically generate an informal model from a revised formal framework must be developed, if we consider the intrinsic iterative nature of the object-oriented development life-cycle. This will result in the effective support to the co-evolution of informal and formal models, improving decisively the applicability of the method.

More globally, we do not expect that integrated methods will succeed if they depend solely upon stand-alone tools such as Metamorphosis. Integrated methods need tools that can be integrated with existing commercial CASE tools and formal specification type-checkers and theorem provers. Hence, in the same way that the method integrates two existing methods, the tool should simply deal with the translation between two existing tools rather than providing full support across the spectrum of analysis and formal specification.

With these points in mind, our future plans are to:

• Develop the tool to support change management.

• Investigate interfaces to other tools.

• Monitor the evolving maturity of Object-Z to ensure that the generated formal models provide a sound basis for subsequent reasoning and refinement.

Finally, despite their promise, we do not believe that integrated methods alone can push formal specification into the mainstream. Rather, methods such as Metamorphosis should be regarded as something that will help if other pragmatic issues such as training and making the costs and benefits more easily quantifiable are addressed in tandem. Recent work suggests that, in critical application domains at least, these pragmatic issues are being taken seriously. We are optimistic, therefore, that integrated methods will eventually start to help the take-up of formal specification by industry.

References

[1] J.-R. Abrial. The B-Book: Assigning Programs to Meanings, Cambridge University Press, Cambridge, England, 1996.

[2] R. Bloomfield, P. Froome, C. Jones. FRERE: Formal Reasoning in Requirements Engineering. Project Document REAIMS/ WP5/ AD/ W/92, REAIMS (Esprit Project Nº 8649), Adelard, 1996.

[3] G. Booch. Object Oriented Design with Applications. Second Edition, Benjamim-Cummings, Menlo Park, California, 1994.

[4] D. Coleman et al. Object-Oriented Development - The Fusion Method. Prentice-Hall, Englewood Cliffs, New Jersey, 1994.

[5] D. Duke, P. King, G. Rose, G. Smith. The Object-Z Specification Language Version 1. Technical Report 91-1, Department of Computer Science, University of Queensland, May 1991.

[6] E. Durr, A. Duursma, N. Plat (Eds.). VDM++ Language Reference Manual. AFRODITE Project Document AFRO/CG/ED/LRM/V9.1, CAP Gemini Innovation, 1994.

[7] P. Facon, R. Laleau, H. Nguyen. Mapping Object Diagrams into B Specifications. In Proceedings of the Methods Integration Workshop, Leeds, 1996.

[8] M. Fowler, K. Scott, I. Jacobson. UML Distilled: Applying the Standard Object Modeling Language. Addison-Wesley, Reading, Massachusetts, 1997.

[9] R. B. France, J.-M. Bruel, M. M. Larrondo-Petrie. An Integrated Object-Oriented and Formal Modeling Environment. JOOP, 10(7), 1997.

[10] C. Gane, T. Sarson. Structured Systems Analysis: Tools and Techniques. Prentice-Hall, Englewood Cliffs, New Jersey, 1977.

[11] S. Gerhart, R. Craigen, T. Ralston. Case Study: Paris Metro Signalling System. IEEE Software, 11 (1): 21-28, January 1994.

[12] A. Hall. Specifying and Interpreting Class Hierarchies in Z. In Proceedings of the 8th Z User Workshop, pages 120-138, Cambridge, 1994.

[13] A. Hall. Using Formal Methods to Develop an ATC Information System. IEEE Software, 13 (2): 66-76, March 1996.

[14] J. Hammond. Producing Z Specifications From Object-Oriented Analysis. In Proceedings of the 8th Z User Workshop, Cambridge, 1994.

[15] M. Hinchey. To Formalize or not to Formalize? IEEE Computer, 29 (4): 18-19, April 1996.

[16] C. Jones. Systematic Software Development Using VDM. Prentice-Hall, Englewood Cliffs, New Jersey, 1986.

[17] C. Jones. A Rigorous Approach to Formal Methods. IEEE Computer, 29 (4): 20-21, April 1996.

[18] K. Lano, H. Haughton. Object-Oriented Specification Case Studies. Prentice-Hall, Englewood Cliffs, New Jersey, 1994.

[19] K. Lano. FormalObject-Oriented Specification Development. Springer-Verlag, Heidelberg, Germany, 1995.

[20] P. Larsen, J. van Katwijk, N. Plat, K. Pronk, H. Toetenel. SAVDM: an Integrated Combination of SA and VDM. In Proceedings of the Methods Integration Workshop, Leeds, 1991.

[21] M. Rawson, P. Allen. Synthesis - an Integrated Object-Oriented Method and Tool for Requirements Specification in Z. In Proceedings of the Methods Integration Workshop, Leeds, 1996.

[22] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Object-Oriented Modelling and Design. Prentice-Hall, Englewood Cliffs, New Jersey, 1991.

[23] L. Semmens, P. Allen. Formalising Yourdon. In Proceedings of the Methods Integration Workshop, Leeds, 1991.

[24] L. Semmens, R. France, T. Docker. Integrated Structured Analysis and Formal Specification Techniques. The Computer Journal, 35 (6): 600-610, 1992.

[25] S. Shlaer, S. Mellor. Object Lifecycles: Modelling the World in States. Yourdon Press, Englewood Cliffs, New Jersey, 1992.

[26] I. Sommerville, P. Sawyer. Requirements Engineering: A Good Practice Guide. John Wiley & Sons, Harlow, England, 1997.

[27] J. Spivey. The Z Notation: A Reference Manual. Prentice-Hall, Englewood Cliffs, New Jersey, 1992.

[28] S. Stepney, R. Barden, D. Cooper (eds.). Object-Orientation in Z. Springer-Verlag, Heidelberg, Germany, 1992.

[29] E. Yourdon. Modern Structured Analysis. Prentice-Hall, Englewood Cliffs, New Jersey, 1989.

¹

For convenience we include both function-based (e.g., SA, SADT) and object-oriented (e.g., OMT, Booch) analysis methods in the blanket term "Structured methods" used in [26].

²

Since SavingsAccount is a derived class, it is necessary to have first generated all its superclasses.

Publication Dates

• Publication in this collection
  21 Dec 1998
• Date of issue
  July 1998