Abstract. The idea of a combined reference model- and view-based specification approach has been proposed recently in the software engi- neering community.
A View-Oriented Approach to System Modelling Based on Graph Transformation* Gregor Engelsl, Reiko Hecke12, Gabi Taentzer2, Hartmut Ehrig2 r Leiden University, Dept. of Computer Science, P.O. Box 9512, NL-2300 RA Leiden, ’ Technical
The Netherlands engelsQui.leidemmiv.nl University of Berlin, Dept. of Computer Science, Frankhnstrasse 28/29, D-10587 Berlin, Germany {ehrig, reiko, gabi}Qcs.tu-berlinde
Abstract. The idea of a combined reference model- and view-based specification approach has been proposed recently in the software engineering community. In this paper we present a specification technique based on graph transformations which supports such a development approach. The use of graphs and graph transformations supports an intuitive understanding and an integration of static and dynamic aspects on a well-defined semantical base. On this background, formal notions of view and view relation are developed and the behaviour of views is described by a loose semantics. We define a construction for automatic
view integration which assumes that the dependencies between different views are described by a reference model. The views and the reference model are kept consistent manuahy, which is the task of a model manager. AII concepts and results are illustrated at the weII-known example of a banking system.
keywords specification language, view, viewpoint, view integration, software process, graph transformation systems
1
Introduction
The most challenging issue of software engineering still is the question how to master the complexity of the development of large software systems. Currently, a variety of approaches try to solve certain aspects of this problem. One important approach is to reuse well-established pieces of specifications, documentations, and/or software, while developing a new system. While in the beginning the reuse idea was restricted to often needed classes, in the meantime it has become clear that reuse should be tackled on a much greater scale by specialising integrated networks of classes, so-called frameworks [LRP+96]. * Research partially supported by the German Research Council (DFG), the TMR network GETGRATS, and the ESPRIT Basic Research Working Group APPLIGRAPH
.
,(f----
v ,
..
_--
._
L
“I
*E a
_- _
I*L”
, ^
. .
.
.
.
- A name 20 of Go may change to 21 in Gr. In order to represent this relationship, a dictionary Ge feq Gr is used containing the entry zs &% ~1 (and CCm CCfor all unchanged names of Go). - Ge may be extended by Gi by introducing new types or rule names. An item is new in Gi if it is not listed in the dictionary ren. The new types and rules of Gr are not visible to Go, i.e., they do not belong to this view. - A rule T defined in Go may be extended in Gi. On the left- and/or righthand side of r new vertices and edges may be added, while the name of the rule might be the same. This means that the effects of applying P are extended (additional items are deleted and/or added) while the pre- and post-conditions are strengthened.
2
1
. ‘_..
I,
:. ‘(
h
_’
.-
I_
.( _‘,
:_ ,
;
-‘\.
_.
r
“,
1.
-
,’
Example. Figure 4 shows a view Printer of the customer’s view that shall become a view of the banking system by composition of view relations later on. It models the restricted view of a printer where customers can ask for the balances of their accounts. Such a printer does not know about key numbers and is not able to open new accounts or to order transactions. Hence, the corresponding types and rules are not visible in the printers view. A renaming is not needed. The printer’s view of the sample transition sequence in Figure 5 on the left is shown in the same figure on the right. Recall that, e.g., the step in the user sequence on the left - opening an account- is a derivation step. In the printer’s sequence on the right, however, it is seen as an e-transition. The first getBalancetransition in the printer’s view results from the parallel derivation step using doTmnsaction and getBalance in the customer’s view. The doY7kansaction rule is hidden in the printer’s view but its effects are still visible. A Hence, a view relation v : Go + Gi describes not only a projection of the state graphs of Gi to Go but also a more abstract view of the behaviour of Gi. Notice that derivation sequences (without unspecified effects) are not viewed as derivation sequences in general but as transition sequences, too: The view of a derivation sequence in Gi may be a transition sequence in Go.
5
In the previous section, view relations were introduced for describing the relationships between views, reference model, and system model. Now, we explain the main technical concept of our approach, the integration of views. All development starts with the reference model as domain-specific framework. The reference model of the banking system is shown in Figure 8. In the
,
6
Automatic Integration of Views
’ i.
. .
,
:.-
.
.,
> -
-
.._ --
:
-.
_ _ -_-
---
:
.-.
’
._
I
.
337
beginning it contains the basic object and relationship types of the banking system (Le., without the operation newAccount that shall be added later on as extension of the reference model). The views Customer and Clerk are derived independently of each other from the reference model. This results in a situation where the reference model itself forms a view on the two specifications Customer and Clerk, which are so-called design views on the complete system model. When integrating the design views to the system model, we have to know which items in the two views represent the same types and operations. Rather then relying on the names of these items, this correspondence is specified by the reference model, i.e., two items are assumed to represent the same concept if and only if they have a common origin. In fact, since view relations allow the renaming of items, this means that developers are free to choose the names in their view according to the preferences of the particular user group. A situation of two design views Gr and Gs based on a reference model Ge by view relations ur and 212is shown in Figure 6. The integration of Gr and G2 over Go will be done in two steps. First, we have to rename the design views so that the renamed views G{ and G’, share a name if and only if there is a common origin in the reference model Go. Then the construction of the integrated system view can be done by componentwise set-theoretical union of Gi and G’,. We assume that the names in the design views Gr and Gs are disjoint which can be ensured by qualification with the name of the view (like Gi,name). The view relations tli : Go + Gi are given by Gs P$ Gg E Gi in Figure 6. Renaming of Views. The system Gi and the renaming Gr !&= Gi are obtained by extending the renaming Gt B Go to Gr. More precisely, renl, agrees with renl on GA, i.e., reni& = renl, and is minimal in the sense that nothing else is renamed, i.e., the renaming is the identity on Ge \ G& The renamed system Gi becomes an extension of Go. In a similar way we obtain Gi with Go C Gi and G2 ?$ Gi by extending the renaming renz to Gs. This renaming L always possible and can be done automatically. Now; the integrated view G$ can be constructed as union of the renamed views G: and Gi in Figure 6.
Fig. 0. Integration of the design views G1 and GZ to the system model G3. Construction of Integrated View. The integrated view Gi = (SG;, IV&pi) is obtained by forming the union of the scheme graphs SC& = SG: U SG’, and of
L
.
Fig. 7. Synchronisation of the openAccount rules. the sets of rule names NA = N{ U Ni of G{ and G’,, respectively. E’or the rule pi(r’) associated with a rule name T’E Ni we distinguish three cases: - If T’E N: \ Ni then &(r’) = p{(r’), i.e., the rule of G: is inherited - If T’E N{ \ Ni then pi(#) = pi(#), i.e., the rule of G’, is inherited - If r’ E Ni n Ni then pi(d) = Li U L’, + Ri U Rb where L{ + R: is the rule associated with ri in Gi for i = 1;2. The new so-called synchronised rule obtained by componentwise union of left- and right-hand sides models the combined effect of applying these two rules simultaneously. Then, the integrated view Gi may be renamed to Gs via ren. The view relation
t
ui is obtained by composing the view relation Gi d G’, C GL with the renaming ren (which is a special view relation as well). In a similar way we obtain view relation VI. Example. The synchronised rule common.newAccount is constructed in Fig ure 7 as the union of the rules openAccount and makeAccount of the customer’s and the clerk’s view. It synchronises the activities that are necessary for creating a new account. The integrated system model Bank in Figure 8 also contains the other rules of the customer’s and the clerk’s view, which are not synchronised. Note that not only the customer’s view contains a rule doTmnsaction but also the clerk’s view. These two rules are not identified, however, since they have no common source in the reference model. The name conflict is resolved automatically by qualification of the local names with the names of the views. (The qualifications are skipped in the clerk’s and customer’s view in Figure 8.) On the other hand, the rules openAccount and makeAccount represent the same op-
339 Y
rcf-mcdd:ammoo C----------------r-------P
. , .
(I
. , $mcRedb)
i
i
-
.
system model:bankA c-----------------------, 1Qp-G I i I I
;
-i
i!
! kcimh)
r-------,--------‘--------~.
-------------------------‘----------,’
J
~--------------““-) IW=
t
I i I
Fig. 8. Integration
of the customer’s and the clerk’s view.
eration (despite their different names) since they both stem from the same rule common.newAccount. They are both renamed to common.newAccount in the renaming step of the construction. The rule clerk.doTmnsaction is not shown. It describes the execution of a transfer transaction. A More generally, we may have the following situations: - It may be the case that “semantically the same” concept is described in G1 and Gs using different names (like openAccount and makeAccount above). This relationship between Gr and Gs is only understood (and may be taken ,
.
‘a
-
r---’
340
into account by the integration) if both names have a common source in the common view Go (like newAccount). This has to be defined in the dictionaries renl and ren2. Then, the concept occurs only once in the inte grated model, under the name of the common view. If this relationship is not specified, the two concepts are considered as unrelated and are kept separately in the integrated model. This illustrates also the difference between a synchronised rule and the parallel application of two. rules. A parallel application of Customer.openAccount andClerk.makeAccount would create two distinct new Account nodes. The synchronised rule common.newAccount realizes that, as desired, only one new account node is created. - On the other hand, the same name may be used in Gi and G2 in order to describe “‘semantically different” concepts (e.g., doll-ansaction in the customer’s and the clerk’s view). This does not causes any problem in our approach since we assume that the names are qualified, i.e., Customer.doTmnsaction and Clerk.dolhnsaction. - In order to represent shared knowledge of Gi and Gs, which is not yet expressed by the reference model, it has to be extended. This should be done by the model manager. If the reference model is used by more than two views, however, this means that the extra information is also propagated to all other views as well. If this is not desired the reference model has to be kept unchanged and an abstmct view has to be introduced instead which is also based on the reference model and specifies the sharing between Gi and G2. The result is a hierarchy of views. Scenarios of more than two views are discussed in a subsequent paper. - A similar observation holds if a rule of Gs is extended in Gr and G7, with the same intended meaning. Also in this case, the model manager may suggest to lift this extension to the reference model, or in case of other views, to specify the extension by an abstract view instead.
I.
Example. Figure 9 shows a derivation sequence that models the same op erations of Figure 5 from the bank’s point of view. The common.newAccount operation is a synchronised action of a customer and the clerk. The parallel Customer.doTransaction and Customer.getBalance operation is performed, while the clerk has an idle step. The second Customer.dotinsaction and CUStomer.getBalance are complemented by two Clerk.doPansaction operations, that take over the formerly (in the customer’s view) unspecified effects. Hence, the transitions of the system model are obtained in a compositional way by A integrating the transitions of the two design views.
-._
:.-
T--T’.
-
-_-
-_
_-
--
--___-
.~.__~_
~.
..
-~
._
-
341
C_-_-_-_--_------------. : i I I i I I tlfr ? i I, w-w (AoooUN i I )f amrbr.Izw6 nmuta.6’4311 ; hlmp.lrn -=1X0
,-----------------------
sunmUr.dOT~OIl
(654321.4711.234567.5W)
+clafcQ’IrmwcliOa --------------------------, ----
i I
.___,_,,____,_,,---------------’ -.gm
(123456,0%5,50)
‘r
+cMxbTdm c-----------------------.
RI-.doTdon
f
(123456,0815,234567,59)
’ (634321,7411,1200) -I- cudan~.gan~rncc ------------------------, ,
--
,,
Fig. 9. Derivation sequence in the system view of the bank.
I
.
342
6
Conclusion
In this paper we have presented a view-oriented approach to concurrent system modelling with the following basic features: - Separate viewpoints of a system are represented by different views sharing a common reference model. - Each view is represented in an intuitive graphical way, which integrates static and dynamic aspects of the system, and has a sound theoretical base. - The views are kept consistent by a model manager by extending the reference model whenever new dependencies occur in the development process. - Using the reference model, consistent views can be integrated automatically. - In case of more than two views, additional abstract views may have to be introduced-leading to a hierarchy of views. - The specification approach is based on typed graph transformation systems with a rich mathematical theory. - In addition to the classical semantics of graph transformation systems based on derivation sequences, a new loose semantics is considered which is able to model an open behaviour of a view.
’1I
l
I ’
I
1
Despite the benefits mentioned above, our view-oriented approach has still to be fully exploited and systematically applied to examples of realistic size. Reference models for different application areas have to be developed. Moreover, views are usually more complex than flat graph transformation systems, i.e,, we have to extend our approach by horizontal structuring techniques as considered in FCELSG] and more powerful operations like rule-based transactions. Also, we have to consider different kinds of constraints, especially temporal logic formulas, in order to specify and verify important (e.g. safety critical) system properties (see [HEWC97]). Last but not least our view-oriented technique must be supported by a specification language based on typed graph transformation systems and corresponding tools. A good candidate for this is PROGRES [SchOl] where a related construction is already used for merging different versions of a document [WesSl]. The relationship of this construction and our approach to view integration has still to be investigated.
References M. Andries and G. Engels. A hybrid query language for the extended entity relationship model. Journal of Visual Languages and Computing, 7(3):321-
,.
352, 1996. Special Issue on Visual Query Systems. R. Balzer. Current state and future perspectives
of software process tcchnology. Keynote Speech, Software Process (SP 96), Brighton, 2-6 December
T?
-I,. ..
>--
>.-._ I,
1,
.
--...--
-
-I
343 [CEL+96]
A. Corradini, H. Ehrig, M. IXwe, U. Montanari, and J. Padberg. The category of typed graph grammars and their adjunction with categories of derivations. In 5th Int. Workshop on Gmph Grammars and their Application to Computer Science, Williamsburg ‘94, LNCS 1073, pages 56-74, 1996. [Dat79] C.J. Date. An Introduction to Database Systems. Addison-Wesley, 1979. FKNt92] A. Finkelstein, J. Kramer, B. Nuseibeh, M. Goedicke, and L. Finkelstein. Viewpoints: A framework for integrating multiple perspectives in system development. International Journal of Software Engineering and Knowledge Engineering, 2(1):31-58, March 1992. pCEL96] R. Heckel, A. Corradini, H. Ehrig, and M. Liiwe. Horizontal and vertical structuring of typed graph transformation systems. Math. Strut. in Comp. Science, 6(6):613-648, 1996. Also techn. report no 9622, TU Berlin. pEWC97] R. Heckel, H. Ehrig, U. Wolter, and A. Corradini. Integrating the specification techniques of graph transformation and temporal logic. In Proc. of MFCS97, Bra&lava, 1997. To appear. [Jac95] D. Jackson. Structuring Z specifications with views. ACM Transactions on Software Engineering and Methodology (TOSEM), 4(4):365389, October 1995. [LB931 M. L6we and M. Beyer. AGG - an implementation of algebraic graph rewriting. In Proc. Fifth Id. Conf. Rewriting Techniques and Applications, LNCS 690, pages 451-456. Springer Verlag, 1993. bRPt96] T. Lewis, L. Rosenstein, W. Pree, A. Weinand, E. Gamma, P. CaIdLr, G. Andert, J. VIissides, and K. Schmucker. Object-oriented Application Frameworks. Prentice-Ha& 1996. [Nag961 M. Nagl, editor. Building Tightly Integrated Software Development Environments: The IPSEN Approach. LNCS 1170, Springer, 1996. [Rib961 L. Ribeiro. Parallel Composition and Unfolding Semantics of Graph Grammars. PhD thesis, TU Berlin, 1996. [Roz97] G. Rozenberg, editor. Handbook of Graph Grammars and Computing by Graph Transformation, Volume I: Foundations. World Scientific, 1997. [Schsl] A. Schiirr. Progress: A &I-language based on graph grammars. In 4th Id. Workshop on Graph Grammars and their Application to Computer Science, LNCS 5%. Springer, 1991. [SWZ95] A. Schiirr, A.J. Winter, and A. Ziindorf. Graph grammar engineering with PROGRES. In W. SchXer and P. BoteIIa, editors, 5th European Software Engineering Conference (ESEC’95), Si@es, pages 219-234. Springer LNCS 989, September 1995. G, Taentzer. Modeling dynamic distributed object structures [Tae96] by graph transformation. Object Currents, 1(12), Dec. 1996. http://www.sigs.com/publications/docs/oc/9612/oc97Ol.f.taentzer.html. [Wag971 A. Wagner. A Formal Object SpeciJcation Technique Using Rule-Based Transformation of Partial Algebras. PhD thesis, TU Berlin, 1997. [Wea B. Westfechtel. Structure-oriented merging of revisions of software documents. In P. Feiler, editor, Proc. 3rd Int. Workshop on Software Conjiguration Management (SCMS) N ew York, pages 68-79. ACM Press, 1991. [Zam96] A. Zamperoni. GRIDS - graph-based integrated development of software: Integrating different perspectives of software engineering. In Proc. 18th International Conference on Software Engineering (ICSE), pages 48-59. IEEE CS Press, March 25-29 1996.
i
-, : .-.
-
_.
.:
:‘,
