Taming the Octopus: Using Formal Models to Integrate the Octopus Object Oriented Analysis Models Robert B. France, J.-M. Bruel1, and G. Raghavan Department of Computer Science & Engineering Florida Atlantic University Boca Raton, FL-33431, USA
[email protected]
Phone: (407)-367-3857 Fax: (407)-367-2800 1 Laboratoire IRIT/SIERA, bat. 1R1 118, rte de Narbonne 31062 Toulouse Cedex, France
Abstract
The Octopus method packages a rich set of mostly graphical object-oriented (OO) modeling techniques that facilitate the creation of abstract, well-structured models of structure and behavior along a variety of modeling perspectives. The techniques provide good tools for managing the complexity in reactive, embedded systems. On the other hand, the lack of precise semantics for the modeling notations used diminishes the role it can play in the development of critical reactive systems. In this paper we describe an extension to the Octopus analysis techniques that provides support for precise speci cation and rigorous analysis. We use a formal notation, Z, to describe formally the concepts captured by Octopus analysis models. The formal notation enhances the applicability of Octopus models to critical, reactive systems.
1 Introduction The Octopus method [9] supports the creation of models that capture system properties along di erent perspectives. For example, at the subsystem analysis phase, requirements are captured in three models: an Object Model that describes a static structure for the subsystem, a Functional Model that describes the operations that can take place in the subsystem, and a Dynamic Model that describes the states, events, and state transitions of the subsystem. For each model, Octopus provides a set of techniques for building graphical representations. A problem with the use of these techniques for modeling and analyzing complex, critical systems, is that the models produced are not amenable to rigorous analysis. This is a result of the lack of a precise semantics for the notations used. This shortcoming limits Octopus in the following ways:
This work was partially funded by NSF grant CCR-9410396.
1
Models are not amenable to rigorous analysis. It is dicult to check the internal consistency of models, and to determine the properties implied by the models.
Models in a phase are not rigorously related to each other. It is dicult to check consistency across models created in a particular phase of development.
Poor support for rigorous veri cation. It is dicult to verify models created in a particular phase against models created in a previous phase. One approach to enhancing the applicability of Octopus is to integrate its modeling techniques with suitable formal speci cation techniques (FSTs). A FST consists of a formal speci cation notation and mechanisms for analyzing speci cations expressed in the notation. FSTs can provide the precision and analytical tools needed to support rigorous analysis of Octopus models. In addition, FSTs can provide the \glue" that ties together the di erent models produced by the Octopus modeling techniques. In this paper we describe our work on integrating a formal notation, Z [12], with the analysis modeling techniques of Octopus. We used Z because of its maturity, the availability of analysis tools, for example, type checkers (e.g., ZTC [8]), animators (e.g., ZANS [7]) and theorem proving environments (e.g., Z/EVES [11]). Z is also based on well-established and widely known mathematical concepts from predicate logic and set theory. The abstract nature of the mathematical concepts allows one to build formal counterparts of Octopus models without introducing extraneous details. The formalization is illustrated using the analysis models of a cruise control system given in [9]. In this paper we formalize only the software component of the system. Our technique can be applied to the hardware component as well because the graphical modeling techniques used to model the software component are used to create models of hardware structure and behavior. In section 2 we give an overview of the Octopus analysis techniques, and in section 3 we describe how the static analysis models of Octopus can be formalized in Z. In section 4 we describe the formalization of the dynamic models and indicate how the formalization can be used to check consistency across the models. We conclude in section 5 with a summary of the work described and an outline of our planned 2
work in this area.
2 The Octopus Method Octopus is an object-oriented technology for real-time systems that is based is based on OMT [10] and the Fusion method [3]. In Octopus software development process consists of ve phases:
System requirements phase System architecture phase Subsystem analysis phase Subsystem design phase Subsystem implementation phase During the system requirements phase the relevant requirements for the software are captured and organized using an extension of Jacobson's use cases [6], and context models. During the system architecture phase the system is divided into a number of smaller and more manageable subsystems. This reduces the software development time as each subsystem can be analyzed in parallel. The physical hardware is isolated from the software by introducing a layer (subsystem) called the hardware wrapper. The hardware wrapper provides all the services to the application subsystem. Each subsystem identi ed in the system architecture phases is then analyzed, designed and implemented. In this paper we focus on the formalization of subsystem analysis models. The subsystem analysis phase focuses on the problem domain of the subsystem. As in OMT, Octopus uses three models to describe the system:
Object Model: This graphical model captures the static structure imposed on the subsystem. It identi es objects, attributes and relationships between the objects in the system. A short textural description of every class in the model is recorded in a class description document. 3
Functional Model: This model describes the operations in the interface of the subsystem. Each operation is described in terms of pre- and post-conditions, inputs, outputs, and associated classes, in an Operation Sheet.
Dynamic Model: This model captures the state changes in the subsystem caused by system events and operations. It models the reactive nature of the system. In Octopus, the dynamic model is developed in four steps: 1. Identify, list, and brie y describe subsystem events. 2. Create statecharts describing the state-dependent behavior of the system. 3. Build a signi cance table showing the signi cance and importance of events against system states. 4. Validate the dynamic model by developing scenarios. Scenarios can be viewed as \test cases" for the dynamic model. Subsystem design is concerned with modeling an abstract solution for the subsystem, and subsystem implementation is concerned with implementing the design. For more information on the Octopus method see [9].
3 Formalizing Object Models An Object Model can be viewed as a description of the properties that valid states of a system must have. Here, a state is an instance structure, that is, a set of linked class instances (objects). A state is valid with respect to an Object Model if all the instances in the state belong to classes in the Object Model and the state exhibits the properties expressed in the Object Model. A valid state is called a con guration in this paper. Intuitively, a con guration is a state of the system at some point in time when there are no operations executing. In other words, the Object Model describes the properties that must hold immediately after initialization, and before and after operation executions. 4
Our formalization of an Object Model is a Z schema that characterizes the valid states of a system. In Z, a schema is a speci cation structure that consists of a declaration part and a predicate part. Variables are declared in the declaration part (with their types), and the relationships that must be maintained among the variables are expressed as a predicate (typically, as a list of conjuncts) in the predicate part. The Z schema obtained for an Object Model is called the system schema, and it characterizes the con gurations of the Object Model. The system schema for an Object Model is developed as follows:
Formalize individual classes. The resulting schemas are called class schemas, and they characterize the instances of classes in a con guration.
De ne generalization/specialization structures. The schemas produced in this step express properties of generalization structures, for example, they specify whether specializations (subclasses) overlap, or are disjoint.
Characterize the con gurations of the Object Model using the previously developed schemas. The result is a system schema, that de nes, among other things, the allowable links between objects, and constraints on the number of instances that can appear in a con guration. In this section we formalize the Object Model of a cruise control software subystem (henceforth referred to as the cruise application) taken from the book [9]. The Object Model of the cruise application is shown in Fig. 1. The hardware components of the system are modeled using the same techniques, making it straightforward to extend our formalization technique to the hardware subsystem. For lack of space, we do not formalize the hardware models in this paper.
3.1 Formalizing classes A class is a characterization of instances that share common properties (e.g., attributes and relationships). In our formalization, an instance has a unique identi er (its object identi er) and a state that consists 5
Command
RotationMeasure calibrates
cmdID
kilometercount
controls Distance
Throttle Control
Speed actual speed
supply
desired speed
value
Lifetime Distance
Relative Distance
Figure 1: Object Model for Cruise Application Subsystem of attribute values. The set of object identi ers for a class is de ned by a Z basic type (i.e., as a set of primitive elements). The attribute types are also modeled as Z basic types. The object identi ers and attribute types for the cruise control system are de ned below: [COMMAND ; ROTATIONMSR; THROTTLECTR] [ID ]
The sets (basic types) COMMAND , ROTATIONMSR, and THROTTLECTR consist solely of object identi ers for the classes Command , RotationMeasure and Throttle Control , respectively. ID is the type of the Command attribute cmdID . Given a con guration, the set of all instances of a class in the con guration must be a subset of the class's type space, where the type space of a class is the set of all possible instances for the class. In our formalization, a class in an Object Model denotes the set of class instances in a con guration. This formalization allows us to not only specify properties of classes, but also constraints on the number of instances that can appear in a con guration. The Z schema de ning a class is called a class schema. A class schema consists of two variables in its declaration part:
instances : the set of instances (object identi ers) in a con guration. 6
attribs : a function mapping instances to their attributes. The value space from which class instances draw their attribute values is de ned by a schema called the attribute schema of the class. The declaration part of an attribute schema consists of variables representing
class attributes. Any constraints on class attributes (expressed as annotations in the Object Model) are speci ed in the predicate part of the attribute schema. Below we give the attribute schemas for the cruise application classes (we assume the availability of a real number toolkit in the Z development environment): CommandAttrib cmdID : ID
TCAttribs desired speed : N [N is the set of natural nos.]
RMAttribs kilometer cnt ; calib cnt ; cnt : N
SpeedAttribs RMAttribs lastcnt : N actual speed ; actual accel [R is: the R set of real nos.]
The structure of a class schema is given by the following generic Z schema: Class [IDS ; ATTRIBS ] instances : P IDS attribs : IDS !7 ATTRIBS dom attribs = instances
The above schema is instantiated by passing in a set of object identi ers for IDS , and an attribute schema for ATTRIBS . The predicate part of the schema restricts the attribute mapping to instances de ned in a con guration (elements of instances ). The class schemas for the cruise application can be expressed as instantiations of the above generic Z schema, as is done below: Command =b Class [COMMAND ; CommandAttrib ] ThrottleControl =b Class [THROTTLECTR; TCAttribs ] RotationMeasure =b Class [ROTATIONMSR; RMAttribs ]
The Command schema is formed by replacing occurences of IDS and ATTRIBS in the generic schema Class by the COMMAND and CommandAttrib , respectively. ThrottleControl and RotationMeasure are
similarly formed. 7
Our formalization treats subclasses in a generalization hierarchy di erently. A generalization hierarchy is viewed as a subdivision of the type space of the root superclass. Subclasses are treated as subsets of the root's type space. Below we give the class schemas for the subclasses in the cruise application Object Model: Speed =b Class [ROTATIONMSR; SpeedAttribs ] Distance =b RotationMeasure LDistance =b Distance RelDistance =b Distance
The schemas Distance , LDistance and RelDistance do not de ne additional attributes, thus they have the same structure as RotationMeasure . Speed , on the other hand, introduces three attributes, lastcnt , actual speed , and actual accel as de ned in SpeedAttribs . Note that SpeedAttribs includes the attributes
of RotationMeasure (de ned in the schema RMAttribs ).
3.2 Formalizing the generalization structure The following are properties that must be considered when developing a precise characterization of generalization structures:
A superclass is said to be exhaustive if all instances of the superclass are instances of some de ned subclass. A superclass is non-exhaustive if there are instances of the superclass that are not instances any de ned subclass.
Subclasses of a superclass may be disjoint or may have instances that overlap. For the RotationMeasure specialization hierarchy, the subclasses partition the superclasses. This means that the superclasses RotationMeasure and Distance are exhaustive, and the subclasses are disjoint. The Z schema describing a generalization is built from the bottom-up. For the cruise application Object Model, the schema for the Distance structure is created rst and then used to de ne the RotationMeasure structure.
8
The Z schemas are given below: DistanceStruct dist : Distance ldist : LDistance rdist : relDistance hldist :instances ; rdist :instances i partition dist :instances
RotationMsrStruct DistanceStruct rm : RotationMeasure speed : Speed hdist :instances ; speed :instances i partition rm :instances
3.3 The cruise application system schema The class schemas and the schema de ning the generalization structure are used to create the system schema for the cruise control system. The system schema de nes the relationships that can exist among instances, constrains the number of instances that can be linked to each other (as expressed by the multiplicity constraints), and constrains the number of instances that can exist in a con guration. The system schema for the cruise control system is given below: CruiseSystem RotationMsrStruct c : Command tc : ThrottleControl caibrate : COMMAND 7 ROTATIONMSR controls : COMMAND 7 THROTTLECTR #ldist :instances = 1 #rdist :instances = 1 #speed :instances = 1 #tc :instances = 1 hdom calibrate ; dom controls i partition c :instances ran calibrate = rm :instances ran controls = tc :instances
[1-to-1 function] [1] [2] [3] [4] [5] [6] [7]
The rst four conjuncts state that there is one instance each of LongDistance , RelativeDistance , Speed and ThrottleControl in any con guration. The fth conjunct states that all commands are related to either
a rotation measure or a throttle control, but no command is linked to a RotationMeasure instance and a ThrottleControl instance at the same time. The sixth and seventh conjuncts state that commands are linked to RotationMeasure and ThrottleControl instances in the con guration.
9
3.4 Using the formalization of the Object Model The formalized Object Model (as embodied by the system schema) provides a precise notion of con gurations (system structure values) that can be used to express the dynamic behavior of systems. For example, operations in Octopus are speci ed in terms of before and after states, where a state consists of an operation mode and a con guration. The system schema provides a precise notation for referring to con guration elements in operation speci cations. The link between the Object Model and the dynamic models is more well-de ned when these models are formalized. As we will show in the next section, behavior can be de ned in terms of transitions on con gurations.
4 Formalizing Behavior In Octopus, behavior is described by the Functional and Dynamic Models. The Dynamic Model speci es the conditions under which the operations de ned in the Functional Model are called. In this section we formalize behavioral models, and show how the formalization ties the models together, enabling consistency checking across the models. The following steps are taken in the formalzation of system behavior: 1. Formally de ne states (operation modes). 2. Formally de ne responses to events. 3. Express the transitions de ned in the statecharts of the Dynamic Model in Z. 4. Formally de ne statechart actions and activities (including those activities described in Operation Sheets of the Functional Model) in Z. One can use the statechart reexpression in Z and the formalized actions and activities to build a speci cation of the responses to events. If this speci cation is logically equivalent to the speci cation 10
obtained in step 2 of the above process, then the models are consistent with each other (with respect to event-response speci cations). If not, then there is a discrepancy in the models. The following subsections illustrate the formalization steps for the cruise application.
4.1 Formalizing States and Events The cruise application has three types of operation modes (states): Cruise , Calibration , and Conversion . conversion states. The state values are de ned below as Z free types: Cruise State ::= inactive j suspended j maintain j accelerate Calib State ::= disabled j measure j ready Conv State ::= default j calibrated Abrog State ::= none j either j both Cruise states are de ned by Cruise State , in which four distinct cruise states are identi ed: inactive , suspended , maintain , and accelerate . Calib State and Conv State de ne distinct states for Calibration
and Conversion , respectively. We include the hardware operation mode Abrog State because it is needed to de ne the behavior of some aspects of the cruise application. This class of states models the states of the vehicle's brake and transmission systems. Further details about the abrogation class and its states can be found in Chapter 10 of [9]. At any point in time, the cruise system's mode consists of a value each for Cruise , Calibration , Conversion , and hardware operation modes (e.g., the abrogation state). The mode of the cruise system is
de ned by the schema CruiseSystemSC given below: CruiseSC cruise : Cruise State
CalibSC calib : Calib State
ConvSC conv : Conv State
AbrogSC abrog : Abrog State
CruiseSystemSC =b CruiseSC ^ CalibSC ^ ConvSC ^ AbrogSC ^ : : :
4.2 Specifying event-response requirements Once the states and events are identi ed in Octopus, Event Sheets describing events and their observable responses are created. These are formalized in Z in terms of changes to the operation mode (de ned by 11
CruiseSC ) and to the con guration (characterized by CruiseSystem ).
We use Z operation schemas to de ne the e ects of events on system mode and con guration. A Z operation schema de nes a relationship between the values of variables before and after some event or
operation. The before-values are declared as unprimed variables, and the after-values by primed variables (with the same names), in the declaration part of the schema. The predicate part of an operation schema relates the primed and unprimed variables. As an example of a formalization of an event-response speci cation, the Z operation schema for the activate cruising event is given below: Activate OK CruiseSystem [introduces primed and unprimed CruiseSystem variables] CruiseSC [introduces primed and unprimed CruiseSC variables] ConvSC [speci es that primed variables = unprimed variables] CalibSC : : : [other hardware states introduced by ] t ? : THROTTLECTR [the throttle control a ected by this event] s ? : ROTATIONMSR [the rotation measure a ected by this event] t ? 2 tc :instances [the throttle control a ected is in the con guration] s ? 2 speed :instances [the speed a ected is in the con guration] calib = disabled ^ cruise = inactive ^ abrog = none cruise = maintain tc :instances = tc :instances 9 ta : TCAttribs j ta :desired speed = (speed :attribs (s ?)):actual speed tc :attribs = tc :attribs ft ? 7! ta g rm = rm speed = speed ldist = ldist 0
0
0
0
0
0
The notation is used to introduce primed and unprimed variables of the schema that follows the symbol. The symbol introduces primed and unprimed variables of the schema that follows the symbol, and conjuncts that equate the prime and unprimed variables (e.g., calib = calib 0 ). The variables t ?, and s ? are inputs (as indicated by the `?' at the end of their names), and they are used to select the con guration instances that are utilized by the event. The predicate part states that when the system is in a mode in which cruise is inactive, calibration is disabled, and there is no abrogation (i.e., no braking, and transmission is in top gear), then the e ect is that the desired speed is set to the actual speed, cruise is in the maintain state, and everything else is 12
unchanged. When the conditions for the above speci ed response are not satis ed, then the event is ignored and the system con guration and mode are left unchanged. This is speci ed below: Activate Ignore CruiseSystem [speci es that the primed variables = unprimed variables] CruiseSC : (calib = disabled ^ cruise = inactive ^ abrog = none )
The e ect of the activate cruising event in any state of the system is de ned by the following schema: Activate Activate OK _ Activate Ignore ==
4.3 Formalizing statechart transitions In Octopus, statecharts are used describe the e ect of events in terms of mode transitions and activities/actions. The formalization of activities and actions will be described in the next subsection. In our formalization, transitions are treated as operations; they are de ned in terms of before and after states, where a state is an operation mode. The statecharts for the cruise application subsystem are given in Fig. 2. In our formalization, each transition in a statechart SC of the form,s 1 (Condition)T ?! s 2, where s 1 s 2 are before and after states, respectively, t is the transition label, and Condition is a predicate that must be true for the transition to take place, is de ned by a Z schema, of the form: ;
T SC Condition stateSC = s 1 stateSC = s 2
[introduces variables stateSC , stateSC ] 0
0
A Z schema characterizing a statechart transition is called a transition schema.
13
Cruise (in Abrogation.none) and Calibration.disabled) activate cruising inactive
active
Conversion
maintain start accelerating
stop accelerating
accelerate
deactivate cruising or enable calibration (in Abrogation.none) resume crusing suspended
(standby power lost)
(has been calibrated) C
default
brake depress or top gear shift out
calibrated
(out of limits) C
Calibration stop calibrating or exceed upper limit
disabled
stop calibrating (in Calibration.enabled.measure) enabled measure
disable calibration enable calibration
(in limits)
start calibrating ready
Figure 2: StateCharts for cruise system Below we give transition schemata for the Cruise statechart: Activate tran CruiseSC AbrogSC [transition depends on Abrogation mode ] CalibSC [transition depends on Calibration mode ] cruise = inactive abrog = none calib = disabled cruise = maintain
Deactivate tran CruiseSC (cruise = suspended _ cruise = maintain _ cruise = accelerate ) cruise = inactive 0
0
14
StartAccel tran CruiseSC cruise = maintain cruise = accelerate StopAccel tran CruiseSC cruise = accelerate cruise = maintain
BrakeDepress tran CruiseSC (cruise = maintain _ cruise = accelerate ) cruise = suspended Resume tran CruiseSC AbrogSC cruise = suspended abrog = none cruise = maintain
0
0
0
0
Transition schemas for the Conversion and Calibration statecharts are similarly de ned. The above transition schemas describe transitions at the local level (i.e., in terms of e ects on parts of the system's operation mode). The local e ects can be transformed to e ects on the system's global mode (as de ned by CruiseSystemSC ) by including primed and unprimed variables for the other state components, and conjuncts equating the before states (represented by unprimed variables) to after states (represented by primed variables). For example, the following schema is a promotion of Activate tran to the global level: Activate tran sys CruiseSC AbrogSC CalibSC ConvSC : : : [hardware states ] cruise = inactive abrog = none calib = disabled cruise = maintain 0
4.4 Formalizing Actions and Activities Activities and actions are essentially operations that act on con gurations. In Octopus, an action is an instantaneous operation, while an activity takes time. In our formalization we abstract out time, thus both actions and activities are treated equally as operations de ned in terms of their e ects on system state and mode. In Octopus, actions and activities are described in a table. The part of the table that describes the 15
actions and activities for the Cruise statechart is given below:
Elementary State Cruise.inactive
Event
Actions/Activities
(1) cruise indicator o (2) nullify throttle actuator exit (5) set desired speed = actual speed Cruise.active enter (3) cruise indicator on Cruise.active.maintain enter (6) perform operation O3 throttle update (6) perform operation O3 Cruise.active.accelerate enter (7) perform operation O4 throttle update (7) perform operation O4 exit (5) set desired speed = actual speed Cruise.suspended enter nullify throttle actuator ongoing (8) cruise indicator blink 2Hz
:::
:::
Operations O 3 and O 4 mentioned in the above table are described by Operation Sheets in the Functional Model. O 3 is the maintain desired speed operation, and O 4 is the auto-accelerate operation. Below, we give part of the Operation Sheet for O 3: Operation (O3) maintain desired speed Description Vary throttle opening from closed to fully open as speed varies from 0.84 m/sec above desired speed Associations Class Speed, class Throttle Control Preconditions Cruise control activated, calibration not ongoing, and neither brake depressed nor transmission out of top gear. Inputs Desired speed (SD), actual speed (SA) Modi es Throttle actuator (VTH) Outputs VTH = :::
Postconditions
:::
:::
Human e ort is required to transform the informal descriptions of actions and activities to Z operation schemas. Generally, actions and activities are de ned in terms of how the operations a ect con gurations (i.e., the elements characterized by the system schema CruiseSystem ). Below we give our formalizations of the cruise system actions 1, 2, 3, 5, and 8. IndicSetting ::= on j o
IndicOn to indic ! : IndicSetting [output to cruise indicator ] to indic ! = on
IndicO to indic ! : IndicSetting [output to cruise indicator ] to indic ! = o
16
CalibBlink 2 blink 2! : N [output to cruise indicator ] blink 2! = 2
NullifyThrottle to throttle ! : R [output to throttle actuator ] to throttle ! = 0
SetSpeed CruiseSystem t ? : THROTTLECTR s ? : ROTATIONMSR t ? 2 tc :instances s ? 2 speed :instances tc :instances = tc :instances 9 ta : TCAttribs j ta :desired speed = (speed :attribs (s ?)):actual speed tc :attribs = tc :attribs ft ? 7! ta g [desired speed set to actual speed ] rm = rm speed = speed ldist = ldist
[selected throttle] [selected speed]
0
0
0
0
0
Activities are expressed in terms of operations described by Operation Sheets. Below we give the formalization of activity 6. The formalization utilizes information found in the Operation Sheet O3 (the maintain desired speed operation). calcposn : R R ! R [calculates throttle position using desired speed and actual acceleration ] maxposn : R [maximum throttle open position ] :::
[Speci cation for throttle position calculations ] MaintainDesiredSpeed CruiseSystem CruiseSystemSC t ? : THROTTLECTR s ? : ROTATIONMSR vth ! : R (cruise = maintain _ cruise = accelerate ) t ? 2 tc :instances s ? 2 speed :instances vth ! = calcposn (((tc :attribs (t ?)):desired speed ; (speed :attribs (s ?)):actual accel ))
4.5 Consistency checking The Z schemas characterizing actions and activities, and the transition schemas can be used to derive Z schemas characterizing the e ects of events. For example, a Z schema characterizing the e ect of the 17
activate cruising event can be de ned as follows: Activate OK derived =b (Activate tran sys ^ SetSpeed ) o9 (IndicOn ^ MaintainDesiredSpeed )
the symbol o9 is the Z schema composition operator, and it is used to obtain a schema that describes the net e ect of rst doing the operation de ned by the schema on the left of the symbol, and then the operation de ned by the schema on thye right of the symbol. Intuitively, the above schema describes the net e ect of setting the desired speed and changing the Cruise mode from inactive to maintain (Activate Ptran ^ SetSpeed ), and then turning the cruise indicator on and setting the throttle position to maintain the desired speed (IndicOn ^ MaintainDesiredSpeed ). The above derivation makes possible consistency checks across models. Recall that in a step prior to the formalization of the statecharts, event-response sheets are formalized in Z (event schemas). The event formalizations derived from the statechart formalizations must be logically equivalent to the previously formalized event-response descriptions, for the statecharts to be consistent with event-response shhets. The following are other properties that can be checked in our formalization:
Precondition property: There exists a valid state in which an operation can start. E ectiveness property: An operation that starts in a valid state will terminate in a valid state, if behavior is as speci ed. Discharging of the above proof obligations increases con dence in the technical soundness of the models. Other application-speci c properties can be investigated using Z analysis tools, for example, the theorem-prover Z/EVES [11], and the Z animator ZANS [7]. Carrying out such analysis provides ample opportunities for uncovering defects in models at the analysis stage, where it costs less to remove them. If defects slip into later development stages, then the cost of removal can increase signi cantly.
5 Conclusions and Further Work In this paper we describe how Octopus analysis models can be formalized. Formalization enhances the application of Octopus in the following ways: 18
Rigorous consistency checking across analysis models is possible. A problem we found with the informal use of Octopus models is that the variety of analysis models makes it dicult to determine whether information is consistently represented across the models. The formal models provide a means to more closely tie the models together, by providing formal representations of items used across models, and mechanisms for determining consistent descriptions of behavior and structure.
The use of Z makes possible the use of automated analysis tools. Z typecheckers (e.g., ZTC ) can be used to ensure type consistency within and across models, Z animators (e.g., ZANS) can be used to dynamically analyze properties, and Z theorem-proving environments (e.g., Z/EVES) can be used to support static analysis of properties. Having such tools reduces the human e ort (and thus human errors!) needed to carry out rigorous analyses.
As discussed in our previous works, the integrated formal and informal modeling techniques complement each other (e.g., see [4, 1, 5]). The informal techniques facilitate the creation of graphical, highly structured models, but they are often not precise, and cannot adequately support rigorous analysis. The formal techniques facilitate the creation of analyzable, precise models, but the models produced are often dicult to read and understand, and the techniques often lack the rich structuring mechanisms of informal techniques. Some aspects of the formalization described in this paper are mechanizable. The derivation of the system schema requires no human input if Object Model constraints are expressed as predicates. Similarly, the transition schemas can be derived from statecharts with very little human input. A signi cant amount of human e ort is required to formalize the Operation Sheets of the Functional Model, and the actions and activities of statecharts, but the act of formalizing these models can provide insights that can lead to an improved understanding of behavior. We are currently developing extensions to a CASE tool we have developed for formalizing Object Models (e.g., see [2, 4]), that will provide support for formalizing the Functional and Dynamic Models of Octopus. The Z analysis tools will also be integrated in the CASE tool, providing an environment that supports modeling, formalization, and analysis of the models. 19
We have also started work on the formalization of Octopus's design models, with the intent of de ning a precise notion of re nement for Octopus models.
References [1] J.-M. Bruel, R. B. France, A. Benzekri, and Y. Raynaud. A Real-Time Speci cation Environment based on Z and Graphical Object-Oriented Modeling Techniques. In I. C. S. Press, editor, Proceedings of the IEEE High-Assurance Systems Engineering Workshop (HASE'96), Niagara-on-the-Lake, Canada, 21{22 Oct. 1996. [2] J.-M. Bruel, R. B. France, B. Chintapally, and G. K. Raghavan. A Tool for Rigorous Analysis of Object Models. In Proceedings of the 20th International Conference on Technology of Object-Oriented Languages and Systems (TOOLS'96), Santa Barbara, California, July 29{August 2 1996. [3] D. Coleman, P. Arnold, S. Bodo , C. Dollin, H. Gilchrist, F. Hayes, and P. Jeremaes. Object-Oriented Development: The Fusion Method. Prentice Hall, Englewood Cli s, NJ, Object-Oriented Series edition, 1994. [4] R. B. France, J.-M. Bruel, and M. M. Larrondo-Petrie. An Integrated Object-Oriented and Formal Modeling Environment. To appear in the Journal of Object-Oriented Programming (JOOP), 1997. [5] R. B. France and M. M. Larrondo-Petrie. A Two-Dimensional View of Integrated Formal and Informal Speci cation Techniques. In J. P. Bowen and M. G. Hinchey, editors, ZUM'95 { 9th International Conference of Z Users, Limerick 1995, Lecture Notes in Computer Science, pages 434{448. Springer-Verlag, 1995. [6] I. Jacobson. Object oriented software engineering. Addison-Wesley, 1992. [7] X. Jia. An Approach to Animating Z Speci cations. Division of Software Engineering, School of Computer Science, Telecommunication, and Information Systems, DePaul University, Chicago, IL 60604, USA, 1995. ZANS is a Z animator available on Internet via anonymous ftp at ise.cs.depaul.edu. [8] X. Jia. ZTC: A Z Type Checker, User's Guide, version 2.01. Division of Software Engineering, School of Computer Science, Telecommunication, and Information Systems, DePaul University, Chicago, IL 60604, USA, May 1995. The ZTC tool and documentation are available on Internet via anonymous ftp at ise.cs.depaul.edu. [9] J. Z. M. Awad, J. Kuusela. Object-Oriented Technology for Real-Time Systems: A Practical Approach Using OMT and Fusion. Prentice-Hall, 1996. [10] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1991. [11] M. Saaltink. Z and Eves. In J. E. Nicholls, editor, Z User Workshop, York 1991, Workshops in Computing, pages 223{242. Springer-Verlag, 1992. [12] J. M. Spivey. The Z Notation: A Reference Manual. Prentice Hall, Englewood Cli s, NJ, Second edition, 1992.
20
