Characterization and Comparison of Formal Refinement and Development Relations for Software Modeling Techniques

Volltext

(1)Characterization and Comparison of Formal Refinement and Development Relations for Software Modeling Techniques. PhD-Thesis of Gunnar Schröter TU-Berlin.

(2)

(3) Characterization and Comparison of Formal Refinement and Development Relations for Software Modeling Techniques vorgelegt von Diplom-Informatiker Gunnar Schröter aus Berlin an der Fakultät IV – Elektrotechnik und Informatik der Technischen Universität Berlin zur Erlangung des akademischen Grades Doktor der Ingenieurwissenschaften – Dr.-Ing. – genehmigte Dissertation Promotionsausschuss: Vorsitzender:. Prof. Dr. B. Mahr. Berichter:. Privatdozent Dr. M. Große-Rhode. Berichter:. Prof. Dr. H. Reichel (TU-Dresden). Berichter:. Prof. Dr. H. Ehrig. Tag der wissenschaftlichen Aussprache: 19. November 2004. Berlin 2004 D 83.

(4) Abstract Refinement is a cornerstones of formal approaches for software modeling. Thus refinement and formal development relations have been developed for several specification techniques and for different kinds of semantics. The aim of this phd-thesis is to classify, characterize and compare propertybased refinement and development relations from different backgrounds in a systematical and formal manner. The thesis pays special attention to • Program-Refinement, Data-Refinement, L-Simulation and L−1 -Simulation from the area of state-oriented models, • Trace-Refinement, Trace-Equivalence, Reduction, Extension, Test-Equivalence and Strong and Weak Bisimulation from the area of behaviororiented modeling concepts and • Reynold’s Method from the area of imperative programming, The classification is based on a unifying abstract framework for development relations. Here a development relation is defined as a relation over a class of models that preserve a specific class of properties. In the case of refinement a special subclass of properties is interpreted as observable from the context of the models. A refinement relation can be classified as • a preserving refinement if it preserves the class of observable properties, • a reflecting refinement if it reflects the class of observable properties, i.e. if it preserves the class of negations of observable properties, or as • a refinement equivalence if it preserves and reflects the class of observable properties. Beside a development relation a development concept can provide a rulebased characterization of the development relation. A rule-based characterization is a set of development rules which is sound and complete with respect to the characterized development relation. To be able to compare the different development relations in a complete and formal manner each development relation is characterized in the transformation system framework, i.e. the development relation is embedded into transformation systems and the embedded relation is characterized by development rules for transformation systems..

(5) Acknowledgment My work has been supported by many persons to whom I want to express my gratitude. First to private lecturer Martin Große-Rhode, who has supervised this thesis from the beginning to the end and who has aided my work in many ways. He allways was (and still is) a reliable source for helpful suggestion and constructive criticism and, when needed, also for encouragement. To professor Uwe Wolter, who gave me the possibility to escape from my normal responsibilities and to stay at the university of Bergen Norway for a half year. During that time he was never too tired for a long and intense scientific disputation. Without that extremely productive period of time this thesis would not exist. I want to express my thanks to professor Hartmut Ehrig in whose research group at the Technical University Berlin I could write my thesis. Here I got to know Martin and Uwe who were at that time scientific assistants in Hartmund’s group. The critical discussions especially at the final stage of my thesis were very instructive. I want to thank professor Reichel for his work as a referee in my viva-voce and professor Mahr for his work as the chair of the examination board. Both gave me very helpful suggestions and indications for my future work on this research area. And last but not least, I want to thank my wife for backing me up in every way she could..

(6) Contents 1 Introduction 1.1 The analyzed development and refinement relations 1.2 Classification . . . . . . . . . . . . . . . . . . . . . 1.3 Characterization . . . . . . . . . . . . . . . . . . . 1.4 Comparison . . . . . . . . . . . . . . . . . . . . . . 1.5 Structure of the work . . . . . . . . . . . . . . . . .. I. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. Structure preserving Development Relations. 5 6 9 12 13 15. 17. 2 General Frameworks 2.1 Unifying abstract Framework . . . . . . . . . . . . . . . . 2.1.1 Concepts of Formal Development . . . . . . . . . . 2.1.2 Concept of Refinement . . . . . . . . . . . . . . . . 2.1.3 Formal Characterization of Development Relations 2.2 Transformation System Framework . . . . . . . . . . . . . 2.2.1 Models (Transformation Systems) . . . . . . . . . . 2.2.2 Development rules . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. 18 18 20 24 30 32 33 36. 3 Data Refinement 3.1 Program Refinement . . . . . . . . . . . . . . . . 3.1.1 Introduction and Definition . . . . . . . . 3.1.2 Characterization within the TS-framework 3.2 Data Refinement . . . . . . . . . . . . . . . . . . 3.2.1 Introduction and Definition . . . . . . . . 3.2.2 Characterization within the TS-framework 3.3 Simulation . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Introduction and Definition . . . . . . . . 3.3.2 Characterization within the TS-framework. . . . . . . . . .. . . . . . . . . .. 41 42 42 46 59 60 67 75 75 79. 1. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . ..

(7) 4 CCS, CSP and LOTOS Development Relations 4.1 Labeled Transition Systems and the Reconstruction of LTS . 4.2 Trace Refinement and Trace Equivalence . . . . . . . . . . . 4.2.1 Introduction and Definition . . . . . . . . . . . . . . 4.2.2 Development Rules for Trace Refinement and Trace Equivalence . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Completeness for Trace Refinement and Trace Equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Trace-Refusal-based Development Relations . . . . . . . . . 4.3.1 Testable systems . . . . . . . . . . . . . . . . . . . . 4.3.2 Test Equivalence . . . . . . . . . . . . . . . . . . . . Introduction and Definition . . . . . . . . . . . . . . Development Rules for Test Equivalence . . . . . . . Completeness for Test Equivalence . . . . . . . . . . 4.3.3 Reduction . . . . . . . . . . . . . . . . . . . . . . . . Introduction and Definition . . . . . . . . . . . . . . Development Rules for Reduction . . . . . . . . . . . Completeness for Reduction . . . . . . . . . . . . . . 4.3.4 Extension . . . . . . . . . . . . . . . . . . . . . . . . Introduction and Definition . . . . . . . . . . . . . . Development Rules for Extension . . . . . . . . . . . Completeness for Extension . . . . . . . . . . . . . . 4.4 Bisimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Strong Bisimulation . . . . . . . . . . . . . . . . . . . Introduction and Definition . . . . . . . . . . . . . . Development Rules for Strong Bisimulation . . . . . Completeness for Strong Bisimulation . . . . . . . . . 4.4.2 Weak Bisimulation . . . . . . . . . . . . . . . . . . . Introduction and Definition . . . . . . . . . . . . . . Development Rules for weak Bisimulation . . . . . . Completeness for Weak Bisimulation . . . . . . . . .. 88 . 88 . 92 . 92 . 94 . . . . . . . . . . . . . . . . . . . . . . . .. 101 112 112 120 120 125 125 130 133 134 134 135 139 141 146 148 149 149 153 154 157 158 162 164. 5 Formal Comparison 166 5.1 Data Refinement and LOTOS development relations . . . . . 170 5.2 Simulation and LOTOS development relations . . . . . . . . . 173. II. Structure refining Development Relations. 181. 6 General Frameworks 182 6.1 Unifying abstract Framework . . . . . . . . . . . . . . . . . . 182 2.

(8) 6.2. Transformation System Framework . . . . . 6.2.1 Structural algebraic State Refinement 6.2.2 Structural Transition Refinement . . Parallel Transition Refinement . . . . Sequential Transition Refinement . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 7 Algebraic Refinement. 209. 8 Reynold’s Method 8.1 Introduction and Definition . . . . . . . . . . . . . . . 8.1.1 Model of a data type . . . . . . . . . . . . . . . 8.1.2 Imperative sequential programs over a data type 8.1.3 Modeling and Formalization . . . . . . . . . . . Steps one and five . . . . . . . . . . . . . . . . . Step two . . . . . . . . . . . . . . . . . . . . . . Steps three and four . . . . . . . . . . . . . . . 8.2 Characterization within the TS-Framework . . . . . . . 8.2.1 The simple case of convergent Refinement . . . 8.2.2 The general case of divergent Refinement . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. 216 . 217 . 217 . 222 . 226 . 227 . 227 . 228 . 233 . 234 . 241. 9 Formal Comparison. III. 251. Conclusion. 253. 10 Conclusion 10.1 Summary . . . . . . . . . . . . . . . . . . . . 10.2 Future Work . . . . . . . . . . . . . . . . . . . 10.3 Related Work . . . . . . . . . . . . . . . . . . 10.3.1 Data Refinement . . . . . . . . . . . . 10.3.2 Behavioral Subtyping Relations . . . . 10.3.3 Z Refinement Methods . . . . . . . . . 10.3.4 CSP-OZ . . . . . . . . . . . . . . . . . 10.3.5 Typed Graph Transformation Systems. IV. 188 188 198 199 202. Appendix. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 254 254 260 263 263 263 265 265 266. 274. A Generalization of Data Refinement 275 A.1 General Program Refinement in the TS-Framework . . . . . . 275 A.2 General Data Refinement in the TS-Framework . . . . . . . . 281 A.2.1 Observable Transformation Systems . . . . . . . . . . . 282 3.

(9) A.2.2 Transformation Systems with unobservable Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 General Simulation in the TS-Framework . . . . . . . . . . . . A.3.1 Observable Transformation Systems . . . . . . . . . . . A.3.2 Transformation Systems with internal Transformations B Generalization of process-algebraic development B.1 General Trace Semantic in the TS-Framework . . B.1.1 Strong Trace Semantic . . . . . . . . . . . B.1.2 Weak Trace Semantic . . . . . . . . . . . . B.2 General Trace-Refusal-Semantics (Remark) . . . . B.3 General Bisimulation in the TS-Framework . . . .. concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .. 288 291 292 297 299 303 303 305 307 307. C Generalization of Renold’s Method within the TS-Framework310 D Extension of Data Refinement. 4. 316.

(10) Chapter 1 Introduction The main problem in software development is to handle the complexity of current software systems. The main approaches to solve this problem are viewpoint orientation, horizontal structuring, including component-based concepts as the most advanced technique, and vertical structuring. A viewpoint oriented modelling technique allows to specify different views on a system in seperated viewpoint models, thereby reducing the number of aspects to be modeled in one of these viewpoint models. Horizontal structuring enables the decomposition of larger systems into smaller sub-systems and vice versa the composition of smaller sub-systems or components to larger systems. In this approach the composed system and the corresponding sub-systems are on the same level of abstraction. Vertical structuring, i.e. devlopment and refinement relations, permits different levels of abstraction during a development process. It allows to begin the development process with an abstract, less complex model which is then stepwise developed/refined into more concrete models and finally into an implementation. On the one hand, each development step adds via design decisions new aspects and properties to the abstract model and, on the other hand, development steps preserve on the some of the aspects and properties of the abstract model. To get the most advantages out of these concepts in a development process they must interact in a compatible way. One of the main purposes, and probably the most important one, of using formal methods is to enable a formal analysis and verification of the model before the model is finally implemented, i.e. at certain stages of an iterative development process the model will be verified against a set of formal requirements. Depending on the result of this verification the model is developed further in such a way that the new model shall meet all those requirements, which are already met by the old model, and in addition to this hopefully 5.

(11) some futhermore. But as long as it cannot be ensured that the new model meets at least all those requirements, which are already met by the old model, one is forced to check if the new model does meet them. The difficulties of such a development arise not only from the fact that this check may fail, but also from the fact that the verification becomes more and more difficult according to the increasing complexity of the model. The aim of formal development relations is to solve this problem. They ensure that a certain set of properties is preserved during a development step, i.e. formal development relations allow to check a certain set of requirements against an abstract model instead of verifying them against the final concrete implementation model, which is usally larger and much more detailed and therefore much more difficult to analyze. A further advantage from the analysis of abstract models instead of more concret implementation models is the possibility to detect development failures earlier in the development process when it is less expensive to correct them as when they would be detected later on or, in the worse case, at the end of the development process. So refinement becomes ’one of the cornerstones of a formal approach to software engineering.’ ([14], page vii) and various refinement and formal development concepts have been developed for several formal, semiformal and informal specification techniques and for different kinds of semantics. The relation between these different definitions and concepts is mostly unclear. The aim of this phd thesis is to classify, characterize and compare refinement and development concepts from different backgrounds in a formal manner.. 1.1. The analyzed development and refinement relations. As we have pointed out already there is a large number of different development and refinement relations so we can pay attention only to a selection of these relations. For a higher reliability of the generality of the concepts, which we will develop and present in this work, we have selected development relations from very different backgrounds. Modeling techniques for behavior-based software systems, i.e. software systems with states and state changing transitions, range from strong state-. 6.

(12) oriented to strong behavior-oriented. In state-oriented modeling approaches it is assumed that the behavior of a model is completely determined by the value of the attributes and variables of the current state. In contrast to this in behavior-oriented modeling approaches it is assumed that the further behavior of a system only depend on its behavioral history, i.e. behavior-oriented approaches concentrate on the modal dependencies between the execution of the different actions of a model. The most important refinement concept in the area of state-oriented modelling approaches is data refinement with L-simulation and L−1 -simulation as the corresponding development rules. Data Refinement and the corresponding simulation techniques are classical and very well-known refinement concepts. In [13] data refinement is described as an ’important and highly applicable method’ (abstract of [13]). Moreover, the authors claim that several other refinement methods, such as VDM (Vienna Development Method; [37]), Reynold’s Method ([55]), Hehner’s Method ([31]) and Refinement Methods due to Abadi and Lamport ([2]), ’are only variations on one central theme’ and they ’either imply or are equivalent to L-simulation or a combination of L- with L−1 -simulation’.1 Furthermore Data Refinement was introduced into many different stateoriented specification techniques, like Z ([14]) or the B Method ([3]) for instance. The most well-known behavior-oriented specification techniques that provide formal development relations are CCS [46], CSP [33] and LOTOS [8]. Therefore the second group of development relations is taken from this processalgebraic background, namely • trace-refinement and trace-equivalence, • reduction, extension and test-equivalence and • strong and weak bisimulation. These two groups of development concepts have originally a theoretical background. So the last development concept should be more applicationoriented. We choose Reynold’s Method from [55] which is a development method for the stepwise refinement of imperative programs. Even if this method has an old and long history, ’Reynold’s Method is still alive and 1. In chapter 8 we will analyze Reynold’s Method in our setting. This will later on enables us to show in chapter 9 that Reynold’s Method is closer related to bisimulation than to L-simulation.. 7.

(13) kicking is testified by the fact that it has been used as the bases for formulating a technique for proving refinement in the setting of temporal logic in volume III of Zohar Manna and Amir Pnueli’s magnum opus The Temporal Logic of Reactive and Concurrent Systems [41],[42],[43].’ ([13], page 287). Furthermore, we will see in the second part of this thesis that Reynold’s Method successfully integrated a new aspect into the idea of development relations, that is the idea of refining the structure of the models. Beside this fact, the formal classification, characterization of Reynold’s Method and the comparison of it with the other development concepts may also be seen as a good test case of our approach. In [13] Reynold’s Method is analyzed and classified as an ’instance of L-simulation’ (page 286). We will see that we are able to provide a much more precise and complete analyzation of the relation between Reynold’s Method and L-simulation. A second class of software systems is the class of functional software. Most of the modeling techniques for this class of software are based on algebraic data structures as defined in [17] and [18] for total algebras or [10] and [54] for partial algebras. Refinement for algebraic specification techniques is based on signature morphisms and forgetful functors which allow, in contrast to data refinement and the process-oriented development relations, the refinement of the structure of the models. Due to the different nature of algebraic data structures, this refinement concept is only classified and not compared with the other refinement and development relations. All these development relations have in common that they are propertybased, i.e. the defining idea behind these relations is to preserve a special class of model properties. This enables to verify this properties against an abstract model at an earlier development phase instead of verifying them against the final complex implementation model. A second class of development relations is the class of rule-based development relations (see for instance [51] and [50] in the area of petri nets, [12] in the area of graph grammars or [56] in the area of object-oriented systems). The question of interest in this area is: How can a development relation be defined and represented by syntactical development rules? If an equivalent property-based characterization is missing, then it is unclear if and how these relations support the verification aspect of a development process. The area of rule-based development relations is huge and not to overlook. Therefore, we want to restrict ourselves in this work to property-based development relations.. 8.

(14) 1.2. Classification. A necessary requirement for the classification of development relations from such heterogenous backgrounds is a clear and unified understanding of the common abstract idea and the common abstract concepts behind the different definitions. Our idea of development concepts is summarized in the unifying abstract framework for development relations. This framework is separated into two parts. In part one, which is presented in section 2.1, we define define the concepts of: • development relation, • refinement relation, • development rules, • soundness of development rules and • completeness of sets of development rules, for structure preserving development concepts, i.e. for development concepts where abstract and concrete models have the same structure. The common abstract idea behind development relations is to preserve properties of the models. The crucial point is therefore to decide which class of properties shall be preserved at a certain phase of the development process. We want to understand development relations as property preserving relations between models, i.e. development relations that relates abstract models to concrete models such that a specific class of properties is preserved. Or, more formally, for a given abstract model area M= (IM, IP, |=), containing a class IM of models, a class IP of properties and a corresponding satisfaction relation |=⊆ IM × IP, each sub-class P ⊆ IP induces a development relation IDP ⊆ IM × IM with (M, N ) ∈ IDP iff ∀p ∈ P : M |= p ⇒ N |= p In other words, whenever a property p ∈ P is satisfied by an abstract model, then it has to be satisfied by all admissible concrete models. As we have pointed out earlier, the aim of this idea is to enable the formal analyzsis of abstract models, i.e., if a property from the class of preserved properties can be verified for an abstract model, then the application of the corresponding formal development relation ensures the preservation of this property. 9.

(15) A disadvantage of this approach is that the definition of development relations as property preserving relations over models is less constructive, i.e. it does not support the construction of a concrete model from a given abstract model. On the contrary, it is an obligation of the developer to prove that a concrete model is an admissible development of the given abstract model. But, as we have prveriously mentioned, the aim of formal development relations is to support and simplify the analysis and verification during a development process and not to replace one verification problem with another. Therefore, a constructive solution is needed to ensure that the concrete model is indeed an admissible development of the abstract model. As an answer to this problem a development concept usually provides, beside the definition of the development relation, a corresponding rule-based characterization. A rule-based characterization of a development relation is a set of development rules r ⊆ IM×IM which are more constructive, i.e. support the construction of a concrete model from a given abstract model, and which is sound and and complete with respect to the characterized development relation. I.e. the final goal is to find for each development relation IDP a corresponding set R of development rules r such that • R is sound with respect to IDP , i.e. r ⊆ IDP for all rules r ∈ R and • R is complete with respect to IDP , i.e. IDP ⊆ R∗ . Based on the soundness of the rules the developer is no longer forced to prove that the constructed concrete model is an admissible development of the given abstract model. The completeness of our set of rules ensure that the developer can restrict himself to the application of the development rules without restricting the corresponding development relation. Usually, a formal development process extends the class of preserved properties during the process, i.e. different development relations are involved. This is different in the more special case of refinement relations. The main idea here is that a special class Obs ⊆ IP of properties can be observed from the context of the models and an abstract model can be refined by a concrete models only if it is possible to replace the abstract model by the concrete model without observable effects. Based on different formalizations of observable effect we can distinguish between • reflecting refinement, • preserving refinement and 10.

(16) refl. ref.. pres. ref. ref. equi.. data refinement. X. –. –. trace refinement. X. –. –. trace equivalence. –. –. X. reduction. X. –. –. extension. –. –. –. test equivalence. –. –. X. bisimulation (weak/strong). –. –. X. surjective homomorphisms. –. X. –. isomorphisms. –. –. X. Table 1.1: Classification of refinement relations. • refinement equivalences. The distinction between observable and unobservable properties is based on the idea that the modeled artifacts are used in a special context. This context can interact with the modeled artifact and can observe its reactions, i.e. the class of observable properties is defined by the context in which the modeled artifact will be used. All classification results of part one are listed in table 1.1. Besides the possibility of classification, the unifying abstract framework will enable us a unified presentation of the different development relations. The second part of our unifying abstract framework is presented in 6.1. Here we integrate the idea of structural refinement, based on the algebraic idea of signature morphisms and forgetful functors, into the framework, i.e. we define the concepts of: • structure refining development relation, • structural refinement relation, • structure refining development rules, • soundness of structure refining development rules and • completeness of sets of structure refining development rules. 11.

(17) refl. str. ref.. pres. str. ref.. str. ref. equi.. generalized surjective homomorphisms. –. X. –. generalized phisms. –. –. X. X. –. –. isomor-. Reynold’s Method. Table 1.2: Classification of structural refinement relations. Analogous to the first part, we distinguish between reflecting and preserving structural refinement relations and structural refinement equivalences. The classification results of the second part can be seen in table 1.2.. 1.3. Characterization. One aim of this work is the formal and complete comparison of the different development relations. This work can be done mainly in two different ways. First, by embedding and characterizing one development relation within the semantical bases of the second development relation, i.e., for each pair of development concepts one characterization has to be developed. If we want to analyze the relations of more than two development concepts this can become a very extensive work. Second, by embedding and characterizing all development concepts within one semantical framework. The advantage of this idea is that each development concept has to be embedded/characterized only once in the common semantical framework. The difficulty of this approach is to find a semantical framework powerful enough to enable to embed and to characterize all refinement concepts of interest (or at least most of them). We will see that the transformation system framework of M. Große-Rhode is such a powerful semantical framework. In [28] M. Große-Rhode developed a special kind of transformation systems as a semantical reference model for the integration of heterogeneous formal specifications. A transformation system is a two layer structure containing a (transition) graph, called control graph, as the representation of the control flow, a (transition) graph, called data space, as the space of all possible labels and a (transition) graph morphism, as the labeling morphism from the control 12.

(18) graph into the data space. I.e. transformation systems are extended labeled transition systems. Analogous to labeled transition systems the transitions of the control graph are labeled by actions, i.e. the transitions of the data space, but moreover the state are labeled by data structures, i.e. the states of the data space. In this framework he introduce the following six kinds of development rules for transformation systems: restriction and view, with their specializations exclusion and hiding, extension and reduction and refinement and implementation. A short introduction into the transformation system framework of [28] can be found at section 2.2. Based on these predefined development rules we will characterize our development concepts in the transformation system framework, i.e. each development relations IDP ⊆ IM × IM is characterized by using the following methodology: 1. Define an embedding trans : IM → IMT S of the models IM of the considered technique into the class IMT S of transformation systems and prove that it is a real embedding, i.e. that trans does not abstract from any important details of the models or more formally we prove that trans is injective, 2. select and/or construct an appropriate set R of development rules r ⊆ IMT S × IMT S for transformation systems, 3. prove the soundness and completeness of the rule set R with respect to trans(IDP ). The result of each characterization is a complete set of sound development rules for each characterized development relation. As we have already pointed out, such a rule-based characterization supports the development process only if the corresponding development rules have a constructive character. The way in which development rules of the transformation system framework meet this requirement is presented in remark 2.2.2.2 in section 2.2.2.. 1.4. Comparison. Based on the characterizations of the development relation in the transformation system framework, we are able to clarify and analyze in this framework: 1. how a model of one technique can be understood as a model of a second technique, i.e., which abstractions or transformations had to be made, and 13.

(19) 2. if there is a formal relation between the different development relation and refinement relations respectively and of which kind this relation is. The overall results are depicted in figure 1.1. An arrow in this figure with an attached ( from a development relation rel1 to development relation rel2 means that rel1 preserves more properties than rel2 and it is therefore stronger, i.e. if a pair of models is in relation rel1 then it is also in relation rel2 . The attached ( shall illustrate that this relation holds only in the direction of the arrow and not the other way around. The double arrow with the attached 6⊆ between trace equivalence and double L-simulation illustrates that neither trace equivalence follows from double L-simulation nor double L-simulation follows from trace equivalence. The new results can be found in chapter 5 and 9. A proof of the known relation between L-simulation and data-refinement can be found in [13] or earlier in [48]. Proofs of the known relations between process-oriented development relations can be found in [6]. (str.) obisimulation QQ. QQQ ooo QQQ ooo QQQ o o QQQ( ( ooo QQQ ( oo o QQQ o o QQQ o oo QQQ o o o QQQ o 6⊆ ( ( woo o o / trace equivalence APPP double L-simulation L-Simulation l l 6⊇ l y A PPP llly y l A PPP l ll y PPP ( A ( llll PPP A l y ( l P A PPP ll y lll A PPP y l l PPP A ll y P' vllll A y y A y ( ( A trace refinement y A y A y A y A ( y A y A A |y y. data refinement. _ _ _(_ _ _/ (. /. known relations new results. Figure 1.1: Relationships between development relations During the characterizations we will pay attention to the following two guidelines, to enable easier comparison: 14.

(20) • Try to find minimal characterization, i.e., each real subset of the characterizing set of rules is incomplete.2 • Try to introduce new rules as less as possible, i.e., introduce new rules only if necessary. These will lead to the following effects: • We gain maximal overlappings between the characterizing set of rules for different development relations. • Each development rule represents an aspect of development relations which cannot be covered by the other rules. As you will see the first effect leads to very easy comparisons between the different development relations. In [71], Winskel and Nielsen unify composition operations from different semantical areas for concurrency. Based on the second effect, we can interprete the development rules in [28] together with the specializations we have developed during the characterizations as the foundation of a set of unified development rules analogous to the unified composition operations in [71]. But in contrast to [71], we do not assume that this set of rules is complete and covers all aspects of all development relations. On the contrary, we assume that such a set does not exists. But by the characterization of further development concepts it will be possible to identify the new aspects of this concept, if there are any, and which other ’old’ aspects are combined by this concept.. 1.5. Structure of the work. This thesis is organized in two parts. In the first part we concentrate on structure preserving development concepts. In the second part we give attention to development concepts which allows to change and refine the structure of the models. Part One starts with the presentation of the unifying abstract framework for development relations (section 2.1) followed by a presentation of the development rules of the transformation system framework (section 2.2). The concepts of data refinement are characterized in chapter 3, the processalgebraic concepts in chapter 4. Both chapters start with a short introduction to the concepts followed by the characterization in the transformation system framework. The introductions include the classical definition as well as a 2. In fact all characterizations that we will present are minimal. But we will not formally prove this property.. 15.

(21) reformulation and classification of these concepts in the sense of the unifying abstract framework. Part One concludes with a formal comparison of the development concepts that have been characterized so far (chapter 5). Part Two is structured in a simular manner. It is introduced by an extension of the unifying abstract framework for development relations of part one which integrates the concepts of signature morphisms and forgetful functors into the framework (section 6.1). This section is followed by the definition of signature morphisms and forgetful functors for transformation systems (section 6.2). Reynold‘s Method is characterized in chapter 8. Analogous to part one, this chapter starts with a short introduction to Reynold‘s Method, including the classical definition and a reformulation and classification of the definition in the sense of the unifying abstract framework, followed by the characterization in the transformation system framework. Part Two concludes with a formal comparison of Reynold‘s Method with the refinement concepts analyzed in part one (chapter 9). Finally, in chapter 10we give a short summary of the results of our work, discuss how these results are related to other approaches in the area of development and refinement concepts and what could be further perspectives of this work. Transformation systems are a very general framework and the embedding of a model class into this class of model usually leads to the detection of concepts which are defined for transformation system but not for the embedded model class such as internal actions, parameterization of actions or parallel execution of actions. This offers a lot of different possibilities to extend and generalize the embedded frameworks. Due to the comprehensiveness of this work these ideas have been outsourced and can be found in the appendix. In appendix A the concepts of the data refinement framework are are defined for an extended class of transformation systems allowing non-injective labeling morphisms and internal actions. In appendix B the concept of processes is extended by allowing the parallel execution of actions. For this extension trace refinement and bisimulation have been redefined. Further the concept of internal actions is introduced into trace refinement by distinguishing between strong and weak trace refinement. In appendix C Reynold’s Method is generalized analogous to the extension of data refinement made in A. Appendix D integrates a concept of structural refinement into the data refinement framework. The resulting concept is closely related to algorithmic refinement in the B Method ([3]).. 16.

(22) Part I Structure preserving Development Relations. 17.

(23) Chapter 2 General Frameworks In this chapter we want to define the formal basis of this work. We start this chapter with the introduction and definition of a unifying abstract framework for development and refinement concepts. We call this framework unifying because it defines a unified terminology which allows us to represent all the different refinement and development concepts in a uniform way. We call it abstract because it defines all these concepts independent from a concrete semantical area of models. Beside the unified representation this framework will enable us a first abstract classification of refinement relations as reflecting, preserving or equivalence. But this framework does not help us either to compare the different development and refinement concepts nor to analyze the formal relationship between this concepts. To answer this question we need a powerful (concrete) semantical area where we can reconstruct all the development concepts in an adequate way. As already pointed out we will use the framework of transformation systems for this purpose. Within the second part of this chapter we will give a short introduction into the basics of the transformation system framework.. 2.1. Unifying abstract Framework. The design and development of large and complex systems usually starts with an abstract model of the intended system which is gradually transformed into concreter models and finally into an implementation. Refinement is a formal possibility for transforming an abstract model into a concreter model. The application of a formal refinement relation ensures that it is possible to replace the abstract model by the concrete model without 18.

(24) effects which are observable form possible contexts, i.e., the concrete model preserves the (from the context) observable properties of the abstract model. The set of all properties of a model which are observable form the possible contexts is often called ’observable behavior’ of the model. If the observable behavior of the intended system is large and complex the early models may not model the hole observable behavior, i.e., they model only parts or abstractions of it. At this point of the process we want to design and develop the observable behavior, i.e., we want, depending on the development process, to extend or reduce the observable behavior and to preserve only parts and not the whole observable behavior even if this changes can be observed form the context. Nevertheless the concrete and the abstract model should be related in some form, so that some properties of the abstract model are preserved by the concrete one’s. In this case the refinement is too restrictive. Later within the development process the case may be also the other way around, i.e., we not only want to preserve the observable behavior by further development steps but additionally further properties. In this case refinement is too weak. I.e., within each phase of a development process a set of properties is chosen as the set of properties which shall be preserved. Usually this set is enriched during the ongoing development process. Since refinement concepts refer to a fixed set of so called observable properties, which is defined by the context, it correspond only to a special phase of a development process. So the more general concept of development relations were introduced. As we have already pointed out formal development and refinement concepts have been developed for many different semantical areas. The aim of this section is to define an abstract model-based formal concept of formal developments with refinement as a specialization which is independent from a concrete area of models, i.e., we extract the common idea behind different kinds of formal developments and refinements respectively for different semantical areas. In this unifying abstract framework for development and refinement concepts we define: • model area, • formal development relations, • development rules, • soundness and completeness of development rules and 19.

(25) • refinements (reflecting, preserving, equivalence) as special development relations. All these concepts are defined in an abstract way, i.e. independent from a concrete semantical area of models. This allows us a unified representation of all the different development concepts, i.e., beside the classical definition we also represent a reformulated definition in the style of the abstract framework. In case that both definition are not obviously equal we will prove their equivalence. Within this first part of the unifying abstract framework the abstract structure of the models is unchanged, i.e., preserved, during the development process. Within section 6 we will extend these concepts in order to enable us to change and develop the structure of the models. We close this section with a formalization of the characterization of an development relation of one model area in an other model area. I.e. we define the requirements for a formal and complete reconstruction of a development relation in a different model area.. 2.1.1. Concepts of Formal Development. Formal development relations relate abstract models with concrete models, i.e., the development relation defines which concrete model is an allowed development of an abstract model. During a development process a lot of design decisions are made. These decisions define the properties of the concerned model. A model of this process is a model that satisfies all these properties. By adding further design decisions this more abstract model is developed into a more concrete model which also satisfy these additional properties, i.e., it satisfy especially the properties induced by former design decisions. This abstract view on a development process leads to the following definition of development relations. Definition 2.1.1.1 ((Property induced) formal development relation) A model area M A = (IM, IP, |=) is given by a class IM of models, a class IP of properties and a satisfaction relation |=⊆ IM × IP . For a given model area M A = (IM, IP, |=) each subclass P ⊆ IP induces a formal development relation IDP ⊆ IM × IM with (M1 , M2 ) ∈ IDP iff ∀p ∈ P : M1 |= p ⇒ M2 |= p which preserves the satisfaction of properties p ∈ P .. 20.

(26) Remark 2.1.1.2 We will see that the formal definition of a model area requires abstract knowledge about the structure of the models. In the case of data refinement we will define the class of models as the class of all relational data types over a fixed signature, in the case of LOTOS development relations as the class of all processes over a fixed set of actions. This knowledge about the structure of the models enables us to define the class of properties, for example, only for given signature we are able to define process expressions for relational data types and only for a given set of actions we are able to define the sets of possible traces or refusals. I.e., the definition of a model area M AΣ = (IMΣ , IPΣ , |=Σ ) is parameterized over the abstract structure Σ of the models. The conceptual extension to structure changing development concepts is done within in section 6. Proposition 2.1.1.3 (Property induced formal development relations) Formal development relations are reflexive and transitive, i.e., they are preorders over the class of models. I.e., IM and IDP define a category IMP with • IM as the class of objects,   {∗} | (A, C) ∈ ID P • morA,C =def  ∅ | otherwise as the set of morphism from A ∈ IM to C ∈ IM, • ∗A,B ◦ ∗B,C =def ∗A,C as the composition of morphisms with ∗A,B ∈ morA,B , ∗B,C ∈ morB,C and ∗A,C ∈ morA,C and • idA =def ∗A,A with ∗A,A ∈ morA,A as the identity of A ∈ IM. With ongoing success of a development process it is necessary to enrich the set of properties which should be preserved during the ongoing process. Proposition 2.1.1.4 (Union of sets of properties) Let IDP1 and IDP2 be property induced formal development relations. Then IDP1 ∪P2 = IDP1 ∩ IDP2 Since development relations have been defined as being induced by a set of properties it can be difficult to prove that a concreter model is an allowed development of an abstract model. Moreover it is wishful to support the construction of a concrete model from a given abstract model. As we have already pointed out in chapter 1 the concept of development rules is introduced to solve this problem. 21.

(27) Definition 2.1.1.5 (Development Rules and Development Steps) A development rule r ⊆ IM×IM is a relation over models. A pair (M1 , M2 ) ∈ r is called an application of r or an r-development step and it is also denoted as M1 `r M2 . Iff model M2 is the result of a finite sequence of applications of rules from a set R of development rules to a model M1 , we may also write M1 `∗R M2 . Remark 2.1.1.6 Rules are often defined using syntactical pattern. The corresponding (semantical) rule in sense of definition 2.1.1.5 is then the set of all possible instances or applications of this syntactical rule. Rules offer an additional possibility to define development relations. Definition 2.1.1.7 (Rule based formal development relations) Let R = {ri |i ∈ I} of rules ri ⊆ IM × IM with i ∈ I. Then we define the rule based formal development relation IDR ⊆ IM × IM as follows IDR =def {(M1 , M2 )|M1 `∗R M2 } or, i.e. IDR = R∗ , with1 • R0 =def idIM , S • R1 =def ri , i∈I. • Rn+1 =def Rn ; R1 for all n ∈ IN and S • R∗ =def Rn . n∈IN. Proposition 2.1.1.8 Rule based formal development relations are reflexive and transitive. Rules are only then useful in a formal development process if they are sound with respect to a property induced formal development relation. Definition 2.1.1.9 (Soundness of Rules) A development rule r is sound with respect to a property induced formal development relation IDP , denoted as r |= P , iff r ⊆ IDP , i.e., M1 `r M2 ⇒ (M1 , M2 ) ∈ IDP 1. Note, that Rn ⊆ IM × IM with n ∈ IN denotes a relation and not a set of rules, i.e., Rn ; R1 is the sequential composition of the relations Rn and R1 .. 22.

(28) Let R = {ri |i ∈ I} be a set of rules ri with i ∈ I. Then R is sound with respect to a property induced formal development relation IDP , denoted as R |= P , iff ∀i ∈ I : M1 `ri M2 ⇒ (M1 , M2 ) ∈ IDP , i.e., iff all rules are sound. Proposition 2.1.1.10 (Restriction of Rules) Let r0 be be a restriction of a development rule r, i.e., r0 ⊆ r. Then r |= P ⇒ r0 |= P Proposition 2.1.1.11 (Extension of Properties) Let P 0 ⊆ P ⊆ IP. Then IDP ⊆ IDP 0 and for all development rules r r |= P ⇒ r |= P 0 Proposition 2.1.1.12 (Sequential Composition of Rules) Let r1 and r2 be development rules and r1 ; r2 the sequential composition of r1 and r2 . Then r1 |= P and r2 |= P ⇒ r1 ; r2 |= P Proposition 2.1.1.13 (Soundness of Rules) Let R be a set of rules which are sound with respect to a property induced formal development relation IDP . Then M1 `∗R M2 ⇒ (M1 , M2 ) ∈ IDP or, i.e., IDR ⊆ IDP If we only want to allow the application of (sound) rules instead of formal development relations it is frequently wishful that this has no semantical effect on the development process, i.e., that the set of rules is complete with respect to the property induced development relation. Definition 2.1.1.14 (Completeness of Rules) A set R = {ri |i ∈ I} of rules ri with i ∈ I is complete with respect to a property induced formal development relation IDP iff 23.

(29) IDP ⊆ IDR Proposition 2.1.1.15 If a set R of rules is sound and complete with respect to a property induced formal development IDP then IDR = IDP Remark 2.1.1.16 (Rule based development relations) In principle the introduction of formal development relations to an area IM of models can begin by defining a set of rules, i.e., IDR =def R∗ and then continue with the search for a characterizing set P ⊆ IP of preserved properties, i.e. a set P of properties such that IDP = IDR . But in the sense of the guide line ’Semantics first.’ the opposite direction should be preferred.. 2.1.2. Concept of Refinement. Now we want to show how refinement concepts fit into this framework. As already pointed out refinement should offer a formal possibility of transforming a more abstract model into a more concrete model without form the context observable effects of this changing. The main idea is that some properties are interpreted as observable properties.2 Let Obs ⊆ IP be the special subclass of properties that contains all from the context observable properties, i.e., the set Obs is given by the context of the models. A property p ∈ IP is called an observable property iff p ∈ Obs. Now we have to define the formal meaning of ’an observable effect’ of changing. We will see that three different possibilities for this definition exist. Which of these definition is sensible depends on the area of applications. The first definition is based on the idea of preserving safety, i.e., if a (bad) property is not observable from the abstract model M then it should be also not observable from the concrete model N . Or the other way around all observable properties of the concrete model N has to be properties of the abstract model M . 2. Depending on the concrete area of models and on the concrete area of application it is quite clear which properties are observable from the context.. 24.

(30) A possible application area, where this definition is sensible, is the modeling of external requirements. This means that the observable properties are interpreted as requirements on the context and that they can not be influenced in any way by the context, i.e., the context can only observe the requirements which it has to fulfill and has no possibility to refuse any requirement. In this case it is safe to reduce the observable behavior, because each context that fulfills the full requirements of the abstract model will also fulfill the reduced requirements of the concrete model, but the introduction of additional requirements is unsafe. Definition 2.1.2.1 (Reflecting Refinement) A model area with context M AC = (IM, IP, |=, Obs) is given by a model area (IM, IP, |=) and a subclass Obs ⊆ IP of observable properties. For a given model area with context M AC = (IM, IP, |=, Obs) the reflecting refinement ref r ⊆ IM × IM is defined as (M, N ) ∈ ref r iff ∀o ∈ Obs : N |= o ⇒ M |= o Remark 2.1.2.2 (Examples of Reflecting Refinement) Trace refinement is an example for reflecting refinement. Here the models are labeled transition systems. In the case of trace refinement it is defined that the performed (observable) actions of a system can (sequentially) be observed, form the context, i.e., only the traces of a system are observable. If a sequence of actions is not a trace of the system can not be observed. Trace refinement allows the restriction of the trace of the models, i.e., the traces are reflected by trace refinement. A further example is the classical data refinement. The models for data refinement are relational data types. These data types are used to build relational input/output-programs. It is observable from the context if a special program over the relational data type can return a special output value for a given input value, but it is not possible to observe, if the system can not return nondeterministically further output value, different from the observed ones, i.e., the nondeterminism of a program can not be influenced from the context. Further in the classical case, i.e., in the partial correctness approach, it is not possible to observe nontermination and deadlocks of a program.. 25.

(31) Data refinement allows the restriction of the input/output behavior of programs, i.e., the pairs of input/ output value of programs are reflected by data refinement. Remark 2.1.2.3 The definition of reflecting refinement correspond to the (informal) definition of semantic implementation correctness in [23]: Given two programs, one called the concrete and the other called abstract, the concrete program implements (or refines) the abstract program correctly whenever the use of the concrete program does not lead to an observation which is not also an observation of the abstract program. Proposition 2.1.2.4 (Reflecting refinement is a formal development relation) Let IP be closed under negation, i.e., a total function ¬ : IP → IP exists with A 6|= p iff A |= ¬p for all A ∈ IM, let P =def {¬p|p ∈ P } for all P ⊆ IP and let Obs ⊆ IP be the subclass of all observable properties. Then ref r is the formal development relation induced by Obs, i.e., ref r = IDObs Remark 2.1.2.5 (Negation and Development Relations) Let IP be closed under negation. Then IDP = ID−1 P for each P ⊆ IP. Remark 2.1.2.6 (Negation of Properties) Each class IP of properties can be extended to IPn =def IP ∪ IP with A 6|= p iff A |= ¬p for all A ∈ IM. From now we want to assume that for each model area the corresponding class IP is closed under negation.. 26.

(32) The idea behind this definition of refinement is to preserve liveness, i.e., if a (good) property is observable from the abstract model M then it should be also observable from the concrete model N . This definition is sensible within application areas where the observable properties are interpreted as services, which are provided to the context. In this case it is usually assumed that the context can decide which services are used, i.e., the context can control the observable behavior of the model. In this case it is quite enough if the concrete model N behaves in the same manner as the abstract model M when it is handled from the context in the same way it is handling M . Definition 2.1.2.7 (Preserving Refinement) For a given model area with context M AC = (IM, IP, |=, Obs) the preserving refinement ref p ⊆ IM × IM is defined as (M, N ) ∈ ref p iff ∀o ∈ Obs : M |= o ⇒ N |= o Proposition 2.1.2.8 (Preserving refinement is a formal development relation) ref p is the formal development relation induced by Obs, i.e., ref p = IDObs Remark 2.1.2.9 (Example of Preserving Refinement) Upwards compatible updates of software are examples of preserving refinement. Let us take the update of of a compiler for an example, i.e., the models are compilers of a programming language, and let us think over compilers as partial functions from syntactical program expressions to executable programs. Let us assume that for each program expression inside the domain of the compiler we can observe the corresponding executable program, but reasoned by the unobservable possibility of nontermination it is not possible to observe if a special program-expression is outside of the domain. Let us further assume that outside of the domain of the function the compiling process may not terminate, i.e., we assume that for each program expression inside the domain of the compiler we can observe the corresponding executable program, but it is not possible to observe if a special programexpression is outside of the domain. Then a new version of a compiler is then compatible to the old version if the domain of the new ones contain at least the domain of the old ones and of 27.

(33) all program expressions inside the domain of the old version the new version behaves like the old ones, i.e., the new and the old version translate these program expressions into the same executable programs, i.e., if it preserve the pairs of program expression and corresponding executable program. The new version may offer interpretations for new programming concepts, i.e. it may show new observable properties, but if the new version is just handled as the old version has been used to handle, i.e. we do not use these new programming concepts, it shows the old observable properties. The distinction between reflecting and preserving refinement is only a methodological distinction which depends wholly on the choice or definition of Obs (which in turn depends on the area of application). Each reflecting refinement ref of a set Obs of observable events can theoretically also be interpreted as a preserving refinement of Obs. But, depending on the area of application usually only one set, i.e., only Obs or Obs, can be sensible interpreted as the set of all observable properties. The idea behind the third definition is that the interpretation of the observable properties as good or as bad events, i.e., as properties which should be reflected or preserved during the development process, is not the same in all possible contexts of the model. Definition 2.1.2.10 (Refinement Equivalence) For a given model area with context M AC = (IM, IP, |=, Obs) the refinement equivalence ref e ⊆ IM × IM is defined as (M, N ) ∈ ref e iff ∀o ∈ Obs : N |= o ⇔ M |= o Proposition 2.1.2.11 (Refinement Equivalence is a formal Development) Let IP be closed under negation. Then ref e is the formal development induced by Ref =def Obs ∪ Obs, i.e., ref e = IDRef In contrast to preserving and reflecting refinement refinement equivalences do not allow changes, extension or reduction, of the observable behavior of the models during the refinement process. It allows only to change the realization of the fixed observable behavior. ref r and ref p are only the limits of a possible range of refinement relations which combines pieces of both ideas and ref e is only one possibility of 28.

(34) combining both ideas. Which subset of Obs ∪ Obs shall be preserved during a development process depends on the possible contexts of the models. I.e., the possible contexts define which properties are observable and which of this observable properties shall be preserved and/or reflected. Remark 2.1.2.12 If Obs = Obs, i.e., Obs is closed under negation, then ref r = ref p = ref Remark 2.1.2.13 (Examples of refinement equivalences) Trace equivalence is an example for a refinement equivalence. Just as in the case of trace refinement the models are labeled transition systems and the traces are observable. A further example for a refinement equivalence is test equivalence, where beside traces also the refusals of the labeled transition systems can be observed. The strongest refinement equivalence for labeled transition systems is bisimulation were complex modal dependencies between the actions can be observed. Proposition 2.1.2.14 (Refinement Equivalence) Refinement equivalences are equivalences over IM, i.e., they are symmetric formal development relations. Finally we come to the following conclusion: Proposition 2.1.2.15 (Refinement) A formal development relation IDP is a • preserving refinement iff the class P ⊆ IP is interpreted as the subclass of all observable properties. • reflecting refinement iff the class P ⊆ IP is interpreted as the subclass of all observable properties. • refinement equivalence iff a subclass P 0 ⊆ P ⊆ IP with P = P 0 ∪ P 0 is interpreted as the subclass of all observable properties. Remark 2.1.2.16 The distinction between preserving refinement, reflecting refinement and refinement equivalence is usually not made within the literature. The reason being is that within one area of applications. 29.

(35) • there is usually only one set P ⊆ IP which can be interpreted sensibly as the set of observable properties and • there is only one kind of refinement (preserving, reflecting or equivalence) existing, that would make sense. So a distinction is not necessary. But, on the other hand, as we already pointed out for each kind of refinement we can find relevant and well known examples within the literature. Remark 2.1.2.17 Sometimes the term ’refinement rule’ is used. We interpret a refinement rule as a development rule which is sound with respect to a refinement relation.. 2.1.3. Formal Characterization of Development Relations. Based on the abstract but formal definition of development relations we are able to formalize the method for reconstructions of development concepts as it has already been pointed out within the introduction. I.e. in this subsection we define how a development relation of one model area can be characterized in an other model area. Definition 2.1.3.1 (Embedding of Models) Let M A1 = (IM1 , IP1 , |=1 ) and M A2 = (IM2 , IP2 , |=2 ) be two model areas. Then we call a total function trans : IM1 → IM2 an embedding of IM1 within IM2 iff a (partial) function trans−1 : IM2 → IM1 exists, so that for all M ∈ IM1 trans−1 (trans (M )) = M . Definition 2.1.3.2 (Characterization of Development Relations) Let IM1 and IM2 be different classes of models and trans : IM1 → IM2 an adequate reconstruction of IM1 within IM2 . Furthermore, let IP1 and IP2 be classes of properties and |=1 ⊆ IM1 × IP1 and |=2 ⊆ IM2 × IP2 be corresponding satisfaction relations. Then we call a set P2 ⊆ IP2 in combination with an adequate reconstruction trans : IM1 → IM2 a property based characterization of a formal development relation IDP1 ⊆ IM1 × IM1 with P1 ⊆ IP1 iff (M, N ) ∈ IDP1 ⇔ (trans(M ), trans(N )) ∈ IDP2. 30.

(36) We call a set R2 of rules r2 ⊆ IM2 × IM2 in combination with an embedding trans a rule based characterization of a formal development relation IDP ⊆ IM1 × IM1 with P ⊆ IP1 iff (M, N ) ∈ IDP1 ⇔ (trans(M ), trans(N )) ∈ (R2 |trans(IM1 ) )∗ i.e., trans(IDP ) = (R|trans(IM1 ) )∗ with R2 |trans(IM1 ) =def {r2 |trans(IM1 )×trans(IM1 ) |r2 ∈ R2 }. Remark 2.1.3.3 Note, that only a property bases characterization of a development relation requires as a class IP2 of properties of models of IM2 . A rule based characterization of a development relation requires instead of properties a set R2 of development rules. Remark 2.1.3.4 Let R|trans(IM1 ) =def {r|trans(IM)×trans(IM) |r ∈ R}. Then the following statements are equal: trans(IDP ) = (R|trans(IM1 ) )∗ ⇔ IDP = trans−1 (R|trans(IM1 ) )∗ ⇔ ∗ −1 IDP = trans (R|trans(IM1 ) ) ⇔ −1 trans (R|trans(IM1 ) ) is sound and complete with respect to IDP . Based on Definition 2.1.3.2 we will determine the structure of rule based characterizations of development relations within the following remark. This unified structure define a guideline through the sections of the chapters 3 and 4. We will often refer to this remark within theses sections to give an orientation to the reader. Remark 2.1.3.5 (Rule based characterization) Based on definition 2.1.3.2 a rule based characterization of a development relation IDP ⊆ IM1 × IM1 is structured as follows: • the definition of an embedding trans : IM1 → IM2 of models • the definition of a set R of rules r ⊆ M2 × M2 • the proof of the soundness of trans−1 (R|trans(IM1 ) ) and 31.

(37) • the proof of the completeness of trans−1 (R|trans(IM1 ) ) As already pointed out we will characterize the development concepts within the semantical framework of transformation systems. This framework contains a set of six powerful development rules, i.e., restriction and view (with their uniform specializations exclusion and hiding), extension and reduction and refinement and implementation. We will use this rules for characterizing the development concepts in a rule based manner. Remark 2.1.3.6 Of course it would be very nice if the set of rules that characterize a development relation is a subset of the development rules of the transformation system framework. Usually this is not the case because the development concepts of the transformation systems are to general. So in most cases it is necessary to specialize the given rules in an useful way or to combine these to create new rules.3. 2.2. Transformation System Framework. The abstract framework enables a unified representation of development and refinement concepts. It defines a uniform terminology for development and refinement concepts. Furthermore it allows us to classify refinement concepts. But it does not help us to analyze the relationships between different development concepts. If we want to analyze the relationships between different development concepts in a formal way, then we have to reconstruct/characterize these concepts within one model area. Only with these characterizations within one semantical framework we will have a possibility of formally analyzing the relationship between these development concepts. If we were interested only in analyzing the relationship between two development concepts it would be reasonably to reconstruct one development concept within the semantical area of the other development concept. But since we want to analyze the relationship between more then two development concepts it is simpler to reconstruct all development concepts within the same model area. The advantage of this idea is that for each development concept we need only one characterization in order to analyze all relationships between this concept and all the other concepts. Moreover this method offers the possibility to relate an additional concept with all so far reconstructed concepts by only one reconstruction, i.e., the reconstruction of this concept within the same model area. 3. Note that r1 ; r2 |= P does not imply r1 |= P or r2 |= P .. 32.

(38) The crucial point is to find a model area which enables us to reconstruct all these different concepts in an adequate way. The decision for the model area of transformation systems in sense of Martin Große-Rhode ([28]) is based on the following background of his framework. In a software system development process a variety of heterogeneous viewpoint models of the system are constructed for the abstract specification of its functionality and behavior. These have to be integrated in order to achieve a coherent and consistent global system specification. For a formal modelbased integration of such heterogeneous viewpoint models a common semantical framework is necessary, where all viewpoint models can be embedded. The framework of transformation systems was designed and developed to be such a powerful semantical framework. It is already well-known, from many successful case studies, that transformation systems the embedding of models of very different heterogeneous viewpoints (see beside [28] also [25], [65], [64], [53], [36]). The transformation system framework contains, amongst other concepts, a set of six powerful development rules. For the characterization of development concepts within the transformation system framework we will use these predefined development rules, i.e., our reconstructions are rule based in sense of section 2.1.3. Based on these reconstructions we will be able to analyze the formal relationships between the characterized development concepts. Since we restricted ourselfs to rule based characterizations we do not need properties for transformation systems and therefor we will in difference to definition 2.1.1.1 not introduce properties for the model area of transformation systems. The interested reader is referred to chapter three of [28].. 2.2.1. Models (Transformation Systems). A transformation system is a two layer structure with a transition graph, called control graph, as the representation of the control flow, a transition graph, called data space, as the space of all possible labels and a labeling morphism from the control graph into the data space. Definition 2.2.1.1 (transition graph) A transition graph T G = (CS, T, in, id) includes the following parts: • a set CS of (control) states, • a family T = (T (c, d))c,d∈CS of sets of transitions from an arbitrary (control) state c to an arbitrary (control) state d, 33.

(39) • a special initialization (respectively finalization) state in ∈ CS and • a function id : CS → T that assigns an idle transition id(c) ∈ T (c, c) for each (control) state c ∈ CS. Definition 2.2.1.2 (data space) A data space is a transition graph which is induced by a data space signature. A data space signature DΣ contains an algebraic signature Σ = (S, OP ), with a set S of symbols s ∈ S for sorts and a set OP of symbols op : w → s for operations or functions, and a set AC of symbols ac : w; w0 for actions. Let DΣ = (Σ, AC) be a data space signature. Then the inducted data space IDDΣ is defined as follows: • The set |P Alg(Σ)| of partial Σ-algebras is used as the set of states. • The set.

(40)  

(41) 0  

(42) ac : w, w ∈ AC and  T (Al, Al0 ) = P  ac(in; out)

(43)

(44) 

(45) in ∈ Al(w)and out ∈ Al0 (w0 )  as set of transitions from the Σ-algebra Al to the Σ-algebra, Al0 , where w ∈ S ∗ is instantiated with input value out of Al and w0 ∈ S ∗ with output value out of Al0 .. • the fully undefined algebra ⊥∈ |P Alg(Σ)| as initialization state and • the ∅ ∈ T (Al, Al) as idle transitions for all Al ∈ |P Alg(Σ)|. A labeling morphism m : CG → IDDΣ is a transition graph morphism. Definition 2.2.1.3 (transition graph morphism) Let T G1 = (CS1 , T1 , in1 , id1 ) and T G2 = (CS2 , T2 , in2 , id2 ) transition graphs. Then a transition graph morphism m : T G1 → T G2 contains • a mapping mCS : CS1 → CS2 and • a family mT = mT (c,d) c,d∈CS1 of mappings mT (c,d) : T (c, d) → T (mCS (c), mCS (d)) and fulfills the following properties • mT (c,c) (id1 (c)) = id2 (mCS (c)) and • mCS (in1 ) = in2 . In the special case of a labeling function m : CG → IDDΣ from a control graph CG into a data space IDDΣ this specifically means that m contains: 34.

(46) • a mapping mCS : CS → |P Alg(Σ)| which labels each state of the control graph with a partial Σ-algebra and • a family mT = mT (c,d) c,d∈CS of mappings mT (c,d) : T (c, d) → T (mCS (c), mCS (d)) which labels each transition with a set of instances of actions and fulfills the following properties • mT (c,c) (id(c)) = ∅, and • mCS (in) =⊥. Definition 2.2.1.4 (Transformation System) A transformation system T S = (DΣ, CG, m) contains: • a data space signature DΣ • a transition graph CG called the control graph • a transition graph morphism m : CG → IDDΣ called the labeling morphism. Let IMT S define the class of all transformation systems. Let DΣ be a data space signature. Then we call a pair T S = (CG, m) with a transition graph CG and a labeling morphism m : CG → IDDΣ a DΣtransformation system, i.e., T S = (CG, m) is DΣ-transformation system iff T S = (DΣ, CG, m) is a transformation system. S Let IMTDΣ define the class of all DΣ-transformation systems. Let DΣ = ((S, OP ), AC) and let S I/O =def {s ∈ S|∃ac : w, v ∈ AC : w = w1 sw2 or v = v1 sv2 }. Then we S want to assume that for each T S = ((CS, T, in, id), m) ∈ IMTDΣ the following statement holds: ∀cs, cs0 ∈ CS \ {in}, s ∈ S I/O : m(cs)(s) = m(cs0 )(s), i.e., the interpretation of sort-symbols for the input or output of actions is fixed within one transformation system T S. We denote this fixed inI/O I/O terpretation by AT S , i.e., cs ∈ CS \ {in} : Vσ (m(cs)(s) = AT S (s) if σ : (S I/O , ∅) → (S, OP ) is the corresponding inclusion. Remark 2.2.1.5 Our assumption of definition 2.2.1.4 that the interpretation of S I/O has to be fixed within a single transformation system is a simplification of the original definition within [28]. Within [28] the problem of identifying input-value or output-value is solved via trekking relations. But this solution is (technically) more complicate and for our purpose not necessary. 35.

(47) TS TG . m. IDDΣ. 2.2.2. Development rules. In this section we will present the development rules of the transformation system framework which are predefined in [28]. This development rules define the bases for our rule based characterizations of development relations. As we will see in the following chapters in the most cases a complete characterization of a development relation usually requires some specializations of these rules. This will be introduced and defined in the corresponding chapters. Definition 2.2.2.1 (Development rules for transformation systems) Let IMT S be the class of all transformation systems. Let further T S = (T G, m) be a DΣ-transformation system with DΣ = (Σ, AC) and T S 0 = (T G0 , m0 ) be a DΣ0 -transformation system. Then we define the following development rules over IMT S • (T S, T S 0 ) ∈ restriction iff DΣ = DΣ0 and a transition graph morphism g : T G0 → T G exist such that m0 = m ◦ g. We call the DΣtransformation system res(T S, g) =def (T G0 , m ◦ g) = T S 0 a restriction of T S via g. TS0. TS T GFo. g. FF FF m FFF #. T G0. w. {w. w w m◦g. IDDΣ. Figure 2.1: Restriction. 36.

(48) unif orm − restriction is a sub-rule of restriction, i.e., unif orm − restriction ⊆ restriction. (T S, T S 0 ) ∈ unif orm − restriction iff (T S, T S 0 ) ∈ restriction, T G0 ⊆ T G and T G0 contains all those edges of T G which are labeled by a set of instances of a fixed subset AC 00 ⊂ AC of action-symbols, i.e., T G0 excludes all those edges of T G which are labeled by a set of instances which contains at least one instance of an action from AC \ AC 00 . In this case the uniform restriction can also be written as res(T S, AC 00 ).4 • (T S, T S 0 ) ∈ view iff T G = T G0 and a transition graph morphism V : IDDΣ → IDDΣ0 exist such that m0 = V ◦ m. We call the DΣ0 transformation system view(T S, V ) =def (T G, m ◦ V ) = T S 0 a view of T S via V . TS0. TS. xx {x x. IDDΣ. T GG. x. m xxx. V. G. GV ◦m G G# / IDDΣ0. Figure 2.2: View. unif orm − view is a sub-rule of view, i.e., unif orm − view ⊆ view. (T S, T S 0 ) ∈ unif orm−view iff (T S, T S 0 ) ∈ view and V is the forgetful functor of a data signature morphism5 dσ : DΣ0 → DΣ. • extension =def (restriction; view)−1 (= (view; restriction)−1 ), i.e. (T S, T S 0 ) ∈ extension iff a transition graph morphisms g : T G → T G0 and V : IDDΣ0 → IDDΣ exists such that m = V ◦ m0 ◦ g. We call T S 0 an extension of T S via (g, V ). unif orm − extension =def (restriction; unif orm − view)−1 . 4 5. In [28] the exculsion of actions is defined by exc(T S, AC 00 ) =def res(T S, AC \ AC 00 ) Iff dσ is an inclusion it is also called hiding.. 37.