The Consistency Workbench: A Tool for Consistency Management in ...

2 downloads 0 Views 111KB Size Report
several restrictions that shall be overcome in the future: First, CSP is the only ... Finally, it shall be noted that a considerable amount of the effort in develop-.
The Consistency Workbench: A Tool for Consistency Management in UML-Based Development Gregor Engels, Reiko Heckel, and Jochen M. K¨ uster Dept. of Computer Science University of Paderborn, Germany engels,reiko,[email protected]

Abstract. With the Unified Modeling Language becoming applied in diverse contexts, the ability of defining and checking customized consistency conditions is gaining increasing importance. In this paper, we introduce the Consistency Workbench for defining and establishing consistency in a UML-based development process.

1

Introduction

With the Unified Modeling Language [6] becoming applied in diverse contexts (given by application domain, methodology, and platform) the ability of defining and checking customized consistency conditions is gaining increasing importance. Besides well-formedness rules in OCL as part of user-defined UML profiles, little support is available for customized specification and checking of consistency conditions. In particular, no support is provided to the developer to specify behavioral consistency conditions. If the UML is to be used successfully in different contexts, method and tool support are required to specify and check consistency conditions both at the syntactic and the semantic level. In [2,1] we have developed a methodology for consistency management in UML-based development. Our approach to defining consistency concepts is by means of partial translations of models into a formal method that provides a language and tool support to formulate and verify semantic consistency conditions. The translation is specified by means of graph transformation rules at the level of the meta model [1]. Depending on the development process and application domain, different translations into different semantic domains may be defined. Consistency checks are specified by translating one or more submodels and checking the specified consistency conditions. The result of the check may then be translated back into UML notation or simply expressed in a message to the modeller. In order to make our approach applicable in practice, tool support is required both for the definition of translations and consistency checks and for their automated execution. 

Research supported by the EU Research Training Network SegraVis (on Syntactic and Semantic Integration of Visual Modelling Techniques, see www.segravis.org)

P. Stevens et al. (Eds.): UML 2003, LNCS 2863, pp. 356–359, 2003. c Springer-Verlag Berlin Heidelberg 2003 

The Consistency Workbench: A Tool for Consistency Management

357

This includes 1. 2. 3. 4.

the definition of (types of) consistency problems as part of a catalogue; the definition of transformations from UML models into a semantic domain; the definition of consisteny checks based on previously defined translations; the execution of consistency checks by analysis tools of the semantic domains.

In addition, a generic consistency management tool is subject to non-functional requirements: It must easily be adaptable to new versions of UML and MOF, and it should be independent of a specific development process or method.

Fig. 1. Defining a Transformation Unit

2

The Consistency Workbench

In this paper, we present a prototype which implements the functional requirements described above. 1. Definition of Consistency Problem Catalogue. Using a template that contains a name, classification, and informal description of the problem, a meta model pattern to localize potential occurrences, and an example, the Consistency Workbench allows the software engineer to define a catalogue of problem types that may be reused in different development processes. 2. Definition of Transformations. By means of a transformation unit, a set of graph transformation rule with a simple control structure, the software engineer can define translations of models into a semantic domain [5]. Each such transformation rule consists of two parts, a source and a target transformation rule (see Figure 1), coupled by the use of common variables. The source transformation rule is specified by providing a UML meta model extract, represented by an XMI description. Rather than producing XMI manually, we currently use UML CASE tools for designing the meta model extract. The generated XMI code is then used with slight modifications. The target transformation rule is a

358

G. Engels, R. Heckel, and J.M. K¨ uster /send_AB_itsA_e1

e3 TLA_Red

TLB_Red

S5 TLA_e5

e2/send_AB_itsB_e5

S4 e4/send_AB_itsA_e2

e1/send_AB_itsB_e4 TLB_e1

TLA_Green TLB_e1 S1



LightControlA

+itsA

S2

TLB_e2

TLA_e4

e6

S3





+itsB

AB

TLA:LightControlA

+itsA

AB

e5/send_AB_itsA_e1 TLB_Green

+itsB

LightControlB

TLB:LightControlB

Fig. 2. A sample input model.

production of a context-free grammar for generating code in a textual language, like CSP [4]. Here, additional iteration constructs are provided for looping over multi-objects matched at the UML side. 3. Definition of Consistency Checks. Based on previously defined transformation units, the software engineer can define consistency checks for a problem type in the catalogue. They are specified by activity diagrams consisting of activities for the localization of potential problems based on pattern defined in 1., the translation defined in 2., the generation of a consistency condition in the target language defined by a similar transformation, and its verification by an external tool (e.g., a model checker). 4. Execution of Consistency Checks. Consistency checks can then be executed on a concrete UML model following the workflows defined in the activity diagrams.

3

Application

As a case study we have defined a behavioral consistency concept involving a class diagram, a specification-level collaboration diagram, statecharts for all classes and protocol statecharts modeling the interaction of objects along certain connectors (cf. Fig. 2). Information from all these diagrams is needed to define a translation into the process algebra CSP. The translation of statecharts to CSP covers sequential and concurrent composite states, inter-level transitions, but no history states. Of the about 60 graph transformation rules in the corresponding transformation unit, the majority are responsible for event queues and declarations of actions needed by CSP. About 20 rules implement the actual behavior of the statechart. Based on the transformation, we have specified conditions formalizing the consistency of the connectors’ protocol statecharts with the statecharts describing the objects’ reactive behavior. These consistency conditions are generated by another transformation unit, which also contains rules for constructing an overall CSP process representing the behavior of all objects used in the collaboration diagram. The latter is achieved by suitable parallel composition of statechart processes.

The Consistency Workbench: A Tool for Consistency Management

359

The overall process is checked for refinement relations with the protocol statecharts by feeding it into the FDR model checker [3]. The result is reported back as a textual comment or error trace.

4

Conclusion

In this paper, we have introduced the Consistency Workbench, a tool for consistency management in UML-based development. The current prototype has several restrictions that shall be overcome in the future: First, CSP is the only semantic domain that is supported. Second, support for reporting the results of a check back to the modeler is limited to forwarding the output of the model checker. Here, the use of UML diagrams (like sequence diagrams for visualizing error traces) is investigated. Third, the definition of UML transformations is still done at the XMI level. We plan to support visual definitions of transformations directly in the workbench, by developing an editor for such purposes. Finally, it shall be noted that a considerable amount of the effort in developing the present prototype went into working around problems with the improper use of the UML meta model and the XMI export of several case tools. We hope that the use of emerging framework solutions for MOF/XMI/Java binding, like the NetBeans Meta Data Repository (MDR) or the Eclipse Modeling Framework (EMF) will improve CASE tool quality in the future. Acknowledgement. The authors wish to thank the members of the students group who took part in the development of the consistency workbench: Nils Bandener, Baris Gueldali, Isabell Jahnich, Christian Koepke, Michael Weking.

References 1. G. Engels, R. Heckel, and J. M. K¨ uster. Rule-Based Specification of Behavioral Consistency Based on the UML Meta-model. In M. Gogolla and C. Kobryn, editors, UML 2001 - The Unified Modeling Language. Modeling Languages, Concepts, and Tools., 4th International Conference, Toronto, Canada, October 1–5, 2001, Proceedings, volume 2185 of LNCS, pages 272–287. Springer, 2001. 2. G. Engels, J. M. K¨ uster, L. Groenewegen, and R. Heckel. A Methodology for Specifying and Analyzing Consistency of Object-Oriented Behavioral Models. In Volker Gruhn, editor, Proceedings of the 8th European Software Engineering Conference (ESEC), pages 186–195. ACM Press, 2001. 3. Formal Systems Europe (Ltd). Failures-Divergence-Refinement: FDR2 User Manual, 1997. 4. C. A. R. Hoare. Communicating Sequential Processes. Prentice Hall, 1985. 5. J. K¨ uster and R. Heckel. Defining and validating transformations of UML models. In IEEE Symposium on Visual Languages and Formal Methods (VLFM 2003), Symposia on Human Centric Computing, Languages, and Environments (HCC 2003), Auckland, New Zealand, October 2003. To appear. 6. Object Management Group. Unified Modeling Language Specification, version 1.4, September 2001.