graphical aspect model editor (game) - diuf.unifr.ch · abstract about eight years ago, i.e. in the...

Graphical Aspect Model Editor (GAME)Development Tool to Graphically Depict Processes for the Order

Management of Swisscom Fixnet AG

Master Thesis

Marsha Rohrer

December 2007

Thesis supervisors:

Prof. Dr. Jacques Pasquier-Rochaand

Dr. Patrik FuhrerSoftware Engineering Group

Dominique GueniatSwisscom IT Services

Software Engineering GroupDepartment of Informatics

University of Fribourg (Switzerland)

Acknowledgements

At this point I would like to thank my supervisors Dr. Patrik Fuhrer and Prof. Dr.Jacques Pasquier-Rocha at the University of Fribourg for giving my the opportunity ofachieving my Master Thesis in the Software Engineering Group and for giving me preciousfeedback on this paper.Particular thanks at Swisscom IT Sevices go to Dominique Gueniat, Simon Räss andMarc Hofer for supporting and encouraging me throughout the elaboration of the MasterThesis.A special thank goes to all the persons who reviewed this paper and provided me withuseful advises and suggestions.Finally I want to thank my family and friends for their everyday support.

i

Abstract

About eight years ago, i.e. in the late 1990's Swisscom started the elaboration of a systemthat is capable to process customer orders of the �xnet retail business automatically. Thatsystem is called Order Management Swisscom (OMS). Within OMS process knowledge(this is the knowledge about the steps that have to be executed under given circumstancesand the knowledge about the sequence of the steps that have to be executed) is declaredusing rules. Those rules allow the OMS engine to dynamically evaluate an appropriateprocess for a concrete customer order.The experience of OMS shows, that it is very advantageous to de�ne processes declara-tively to be able to evaluate the speci�c process for a concrete order at runtime. Howeveronly parts of the rules depend on dynamic facts. The basic structure of the processescan be declared using a static process model. Therefore the idea came up to combinethe �exibility of the rules with the simplicity of a static process model (aspect model).The static model declares the process structure while the rules modify the structure atruntime. This �hybrid architecture� o�ers the following advantages:

• It keeps the high process �exibility but also reduces the complexity of process im-plementation.

• It enforces consistent documentation as the static process model provided by thegraphical editor implicitly documents the process structure (no need to documentthe processes with a separated drawing tool anymore).

• It makes process implementation less error prone and more productive.

The static process model (aspect model) can be depicted using a graphical editor andit was the goal of this Master Thesis to design, develop and document such a graphicaleditor to seamlessly integrate it with the existing OMS system and to facilitate the workof the developers at Swisscom IT Services. To achieve these goals, the editor is builton top of the Eclipse Rich Client Platform (RCP) and takes advantage of its GraphicalModeling Framework (GMF).

Keywords: business process modeling, graphical editor, Eclipse RCP, Eclipse GMF

ii

Table of Contents

1. Introduction 1

1.1. Aim of the Master Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Description of the Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3.1. Acquire Technical Knowledge . . . . . . . . . . . . . . . . . . . . 3

1.3.2. Implementation of the Graphical Aspect Model Editor . . . . . . 3

1.3.3. Worst Case Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4. Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4.1. University of Fribourg . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4.2. Swisscom IT Services . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.3. Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5. Hard- and Software Used . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.6. Notations and Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.7. Structure of this Paper . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2. Automation of Processes 8

2.1. Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Automation of Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1. Bene�ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3. Standards for Describing Business Processes . . . . . . . . . . . . . . . . 10

2.4. Rules and Rule Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3. Order Management Swisscom 13

3.1. Goals Set for OMS at Project Start . . . . . . . . . . . . . . . . . . . . . 14

3.2. Swisscom Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3. OMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4. OMS Process Engine (CLOM) . . . . . . . . . . . . . . . . . . . . . . . . 16

iii

Table of Contents iv

3.4.1. Declarative Process Description . . . . . . . . . . . . . . . . . . . 17

3.5. The CLOM Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.6. Informal Example: Sightseeing Tour . . . . . . . . . . . . . . . . . . . . . 21

3.7. Graphical Aspect Model Editor (GAME) . . . . . . . . . . . . . . . . . . 24

3.7.1. Changes in the OMS with GAME . . . . . . . . . . . . . . . . . . 24

3.7.2. Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4. Eclipse RCP 28

4.1. The OSGi Speci�cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1. Module Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1.2. Lifecycle Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.3. Service Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.4. Implementations of the OSGi Speci�cation . . . . . . . . . . . . . 32

4.2. Extensibility of Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1. Equinox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.2. Extension Registry . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.3. Extension and Extension Point . . . . . . . . . . . . . . . . . . . 34

4.3. UI-Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.1. Abstract Window Toolkit (AWT) . . . . . . . . . . . . . . . . . . 35

4.3.2. Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3.3. Standard Widget Toolkit (SWT) . . . . . . . . . . . . . . . . . . 36

4.3.4. JFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3.5. Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4. Plug-in Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.1. Target Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.2. Plug-in Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5. Graphical Modeling Framework (GMF) 43

5.1. Eclipse Modeling Framework (EMF) . . . . . . . . . . . . . . . . . . . . 44

5.2. Graphical Editing Framework (GEF) . . . . . . . . . . . . . . . . . . . . 45

5.3. Semantic vs. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.4. Model View Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.5. Con�guration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.5.1. Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.5.2. Graphical De�nition . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.5.3. Tooling De�nition . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.6. Mapping and Generator Models . . . . . . . . . . . . . . . . . . . . . . . 48

5.7. Extensibility and Customization . . . . . . . . . . . . . . . . . . . . . . . 49

6. Technological Study 50

6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Table of Contents v

6.1.1. Fundamental Requirements . . . . . . . . . . . . . . . . . . . . . 51

6.1.2. More Sophisticated Requirements . . . . . . . . . . . . . . . . . . 51

6.2. Requirements for the Figure Representation . . . . . . . . . . . . . . . . 52

6.2.1. BPMN Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2.2. Representation of Steps . . . . . . . . . . . . . . . . . . . . . . . 52

6.2.3. Representation of Predecessor Relations . . . . . . . . . . . . . . 54

6.3. Possible Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.3.1. Graphical Modeling Framework . . . . . . . . . . . . . . . . . . . 57

6.3.2. Other Possible Technologies . . . . . . . . . . . . . . . . . . . . . 57

6.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.4.1. Solutions for Fundamental Requirements . . . . . . . . . . . . . . 58

6.4.2. Solutions for Sophisticated Requirements . . . . . . . . . . . . . . 58

6.4.3. Final Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7. Architecture 60

7.1. GAME and OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.1.1. Architecture before GAME . . . . . . . . . . . . . . . . . . . . . . 60

7.1.2. Integration of GAME . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.1.3. Interfaces for GAME Integration . . . . . . . . . . . . . . . . . . 63

7.2. Base of the Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.3. Core Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.4. Edit and Editor Plug-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.5. Diagram Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.5.1. src Source Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.5.2. customsrc Source Folder . . . . . . . . . . . . . . . . . . . . . . . . 69

7.6. Output of GAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8. Implementation 73

8.1. Con�guration Files and Mapping Model . . . . . . . . . . . . . . . . . . 73

8.1.1. Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

8.1.2. Graphical De�nition . . . . . . . . . . . . . . . . . . . . . . . . . 75

8.1.3. Tooling De�nition . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.1.4. Mapping Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.2. Custom Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.2.1. Step Figure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.2.2. Step Body Figure . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.2.3. Step Property Figure . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.2.4. Invisible Compartment Figure . . . . . . . . . . . . . . . . . . . . 80

8.2.5. Integration with Generated Code . . . . . . . . . . . . . . . . . . 80

8.3. Linking with OMS Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . 88

8.3.1. Custom Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Table of Contents vi

8.4. Step Name used as ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.5. Remove Standard Helper Tools . . . . . . . . . . . . . . . . . . . . . . . 94

8.5.1. Remove Pop Up Bar . . . . . . . . . . . . . . . . . . . . . . . . . 94

8.5.2. Remove Connection Helpers . . . . . . . . . . . . . . . . . . . . . 95

8.6. Code Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

8.7. Embedding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

8.8. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

9. Using Game 100

9.1. Development Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

9.2. The Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

9.3. Modeling Sightseeing Tour . . . . . . . . . . . . . . . . . . . . . . . . . . 103

9.3.1. Meaning of Step Markers . . . . . . . . . . . . . . . . . . . . . . . 106

9.3.2. Customizable Predecessor Relation . . . . . . . . . . . . . . . . . 107

9.4. Usability of GAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

10.Conclusion 109

10.1. E�ective Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

10.2. Evaluation of GMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

10.3. Evaluation of GAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

10.3.1. Future Improvements . . . . . . . . . . . . . . . . . . . . . . . . . 110

10.4. General Feelings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

10.5. Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

A. Mindmap Example 114

A.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

A.2. Developing Code Base of the Editor . . . . . . . . . . . . . . . . . . . . . 114

A.3. Graphical and Tooling De�nition of the Editor . . . . . . . . . . . . . . . 117

A.4. Tooling De�nition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

A.5. Mapping Model and Editor Code Generation . . . . . . . . . . . . . . . . 120

A.6. Run the Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

A.7. The Graphical Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

B. Setup for GAME 127

B.1. Swisscom IT Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

B.1.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

B.1.2. Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

B.2. Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

B.2.1. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

B.2.2. Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

C. Source Code 130

Table of Contents vii

C.1. Core Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

C.2. Diagram Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

C.2.1. game.diagram.dialog Package . . . . . . . . . . . . . . . . . . . . . . 131

C.2.2. game.diagram.figures Package . . . . . . . . . . . . . . . . . . . . . 136

C.2.3. game.diagram.sheet Package . . . . . . . . . . . . . . . . . . . . . . 141

D. Common Acronyms 144

E. License of the Documentation 146

F. Website of the Project 147

G. CD-ROM 148

References 149

Referenced Web Resources 150

Index 152

List of Figures

1.1. Motivation for the development of a graphical editor . . . . . . . . . . . 3

1.2. Scope of the Master Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1. UML diagram showing the relation of Step, Activity, etc. . . . . . . . . . . 15

3.2. The OMS Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3. The two states of a Step . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.4. Predecessor Relations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5. Di�erence between imperative and declarative description . . . . . . . . . 19

3.6. The CLOM Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.7. A template process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.8. A �just in time� decision . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.9. Handling of variations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.10. Condition triggered process . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.11. Processes generated at runtime . . . . . . . . . . . . . . . . . . . . . . . 22

3.12. Imperative process de�nition . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.13. Process generation with GAME . . . . . . . . . . . . . . . . . . . . . . . 24

3.14. CLOM algorithm with new input . . . . . . . . . . . . . . . . . . . . . . 25

3.15. Integration of GAME with OMS . . . . . . . . . . . . . . . . . . . . . . . 26

3.16. Aspect model for the sightseeing tour depicted with GAME . . . . . . . 27

4.1. OSGi Layering (from [Kri07]) . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2. OSGi class sharing (from [All07]) . . . . . . . . . . . . . . . . . . . . . . 30

4.3. OSGi state diagram (from [Wal05]) . . . . . . . . . . . . . . . . . . . . . 31

4.4. Plug-in nesting (from [Wal05]) . . . . . . . . . . . . . . . . . . . . . . . . 34

4.5. Manifest Editor, Overview page . . . . . . . . . . . . . . . . . . . . . . . 35

4.6. Manifest Editor, Dependencies page . . . . . . . . . . . . . . . . . . . . . 36

4.7. Manifest Editor, Runtime page . . . . . . . . . . . . . . . . . . . . . . . 37

4.8. Manifest Editor, Extensions page . . . . . . . . . . . . . . . . . . . . . . 38

4.9. Manifest Editor, Extension Points page . . . . . . . . . . . . . . . . . . . 39

viii

List of Figures ix

4.10. Manifest Editor, Build page . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.11. Manifest Editor, MANIFEST.MF page . . . . . . . . . . . . . . . . . . . 41

4.12. Manifest Editor, plugin.xml page . . . . . . . . . . . . . . . . . . . . . . 42

4.13. Manifest Editor, build.properties page . . . . . . . . . . . . . . . . . . . 42

5.1. Ecore Editor provided with EMF . . . . . . . . . . . . . . . . . . . . . . 44

5.2. Model View Controller Architecture of GEF (from [4]) . . . . . . . . . . 45

5.3. Model View Controller Architecture of GMF (from [4]) . . . . . . . . . . 46

5.4. Relations between Models and Plug-ins in GMF . . . . . . . . . . . . . . 47

6.1. The �gure representing an Activity in GAME . . . . . . . . . . . . . . . . 53

6.2. The �gure representing a Flow in GAME . . . . . . . . . . . . . . . . . . 53

6.3. The default case: Single Instance Step . . . . . . . . . . . . . . . . . . . . . 54

6.4. The �gure representing a Conditional Step . . . . . . . . . . . . . . . . . . 54

6.5. Figure representing the Multi Instance Step . . . . . . . . . . . . . . . . . . 55

6.6. Figure representing the Compensation Step . . . . . . . . . . . . . . . . . . 55

6.7. Figure representing the Default Predecessor without simpli�cation . . . . . 56

6.8. Figure representing the Default Predecessor . . . . . . . . . . . . . . . . . . 57

7.1. OMS architecture before GAME . . . . . . . . . . . . . . . . . . . . . . . 61

7.2. Integration of GAME with OMS . . . . . . . . . . . . . . . . . . . . . . . 62

7.3. The domain model of GAME . . . . . . . . . . . . . . . . . . . . . . . . 64

7.4. UML class diagram of the game package . . . . . . . . . . . . . . . . . . 66

7.5. The dependencies between the four generated plug-ins . . . . . . . . . . . 67

7.6. Relations between con�guration �les, generator models and generated code 68

7.7. XMLSchema for the GAMEContext . . . . . . . . . . . . . . . . . . . . . 69

7.8. XMLSchema showing the Step . . . . . . . . . . . . . . . . . . . . . . . . 70

7.9. XMLSchema for the Predecessor Relation . . . . . . . . . . . . . . . . . . 71

7.10. XMLSchema showing the composition of the Default Predecessor . . . . 72

8.1. The domain model of GAME . . . . . . . . . . . . . . . . . . . . . . . . 74

8.2. Relation between Con�guration Files and Plug-ins . . . . . . . . . . . . . 75

8.3. Graphical De�nition of GAME part one: without showing the Figure

Gallery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.4. Tooling De�nition of GAME . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.5. Mapping Model of GAME . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.6. StepFigure with the StepBodyFigure and the StepPropertyFigure . . . . . . . . 79

8.7. De�nition of the StepFigure in the gmfgraph . . . . . . . . . . . . . . . . . 79

8.8. Properties View of the custom StepBodyFigure in the gmfgraph . . . . . . 80

8.9. Graphical de�nition and Properties View of the ActivityFigure . . . . . . 80

8.10. Dialog for referencing the activity whithin OMS . . . . . . . . . . . . . . 88

8.11. Dialog for referencing the �ow within OMS . . . . . . . . . . . . . . . . . 89

List of Figures x

8.12. Properties View of the StringWrapper EDataType . . . . . . . . . . . . . . . 93

8.13. Graphical De�nition of GAME part 2: showing only the Figure Gallery . 99

9.1. Graphical Aspect Model Editor . . . . . . . . . . . . . . . . . . . . . . . 101

9.2. Flow Descriptor Editor with integrated GAME . . . . . . . . . . . . . . . 102

9.3. Dialog that allows to open an existing *.game �le . . . . . . . . . . . . . . 103

9.4. The tools palette of GAME . . . . . . . . . . . . . . . . . . . . . . . . . 104

9.5. Properties View of the Castle Step . . . . . . . . . . . . . . . . . . . . . 104

9.6. Properties View for specifying implementation references . . . . . . . . . 105

9.7. Properties View of the Opera Step . . . . . . . . . . . . . . . . . . . . . 105

9.8. Step representation of GAME . . . . . . . . . . . . . . . . . . . . . . . . 106

9.9. Predecessor Relations in GAME . . . . . . . . . . . . . . . . . . . . . . . 106

10.1. Replacement of the rule �le on the left by a GAME aspect model . . . . 113

A.1. Wizard for creating a new GMF project . . . . . . . . . . . . . . . . . . 115

A.2. Wizard for creating a ecore diagram �le . . . . . . . . . . . . . . . . . . . 116

A.3. Wizard for creating a generator �le for the code base . . . . . . . . . . . 117

A.4. Wizard for creating a generator �le for the code base . . . . . . . . . . . 118

A.5. The ecore diagram of this little example . . . . . . . . . . . . . . . . . . 119

A.6. The mindmap.gmfgraph �le being created with the wizard . . . . . . . . . . 120

A.7. The mindmap.gmfgraph �le after customization . . . . . . . . . . . . . . . . 121

A.8. The mindmap.tool �le after creation with the wizard . . . . . . . . . . . . . 122

A.9. The mindmap.gmfmap �le after having it completed by hand . . . . . . . . 123

A.10.Package explorer showing all the models and plug-ins . . . . . . . . . . . 124

A.11.Eclipse application con�guration: Main tab . . . . . . . . . . . . . . . . . 124

A.12.Eclipse application con�guration: Arguments tab . . . . . . . . . . . . . 125

A.13.Eclipse application con�guration: Plug-in tab . . . . . . . . . . . . . . . 126

A.14.The editor that was created for this example . . . . . . . . . . . . . . . . 126

B.1. How accessing the Eclipse Update Site . . . . . . . . . . . . . . . . . . . 128

B.2. Wizard for creating a GMF diagram . . . . . . . . . . . . . . . . . . . . 129

List of Tables

6.1. Mapping between BPMN and OMS terms . . . . . . . . . . . . . . . . . 52

6.2. Supported predecessor relation conditions . . . . . . . . . . . . . . . . . . 56

xi

List of Code extracts

7.1. sightseeing.game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8.1. StepEditPart.java: StepFigure.createContents() method . . . . . . . . . . . . . 81

8.2. StepEditPart.java: StepFigure.paint() method . . . . . . . . . . . . . . . . . . 81

8.3. StepEditPart.java: StepFigure.paintSubFlowMarker() method . . . . . . . . . . . 82

8.4. StepPainter.java: paintSubFlow() method . . . . . . . . . . . . . . . . . . . . 83

8.5. StepPainter.java: paintMultiInstance() method . . . . . . . . . . . . . . . . . . 84

8.6. StepPainter.java: paintCompensation() method . . . . . . . . . . . . . . . . . 84

8.7. StepEditPart.java: paintConditional() method . . . . . . . . . . . . . . . . . . 85

8.8. StepEditPart.java: createLayoutEditPolicy() method . . . . . . . . . . . . . . . 86

8.9. StepEditPart.java: addBorderItem() method . . . . . . . . . . . . . . . . . . . 86

8.10. StepPainter.java: paintInstantiationConditionLabel() method . . . . . . . . . . . 87

8.11. GamePropertySection.java: getPropertySource() . . . . . . . . . . . . . . . . . 89

8.12. CustomizedPropertyDescriptor.java: createPropertyEditor() for Activity . . . . . . 90

8.13. ActivitySelectionDialog.java: PatternFilter . . . . . . . . . . . . . . . . . . . . . 90

8.14. ActivitySelectionDialog.java: createDialogArea() . . . . . . . . . . . . . . . . . . 91

8.15. FlowSectionDialog.java: FlowSectionDialog() . . . . . . . . . . . . . . . . . . . 92

8.16. StringWrapper.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.17. GameFactoryImpl.java: customized methods . . . . . . . . . . . . . . . . . . 93

8.18. GAMEContextEditPart.java: createDefaultEditPolicies() . . . . . . . . . . . . . . 94

8.19. StepEditPart.java: createDefaultEditPolicies() . . . . . . . . . . . . . . . . . . . 95

C.1. StringWrapper.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

C.2. ActivityFunctionLabelProvider.java . . . . . . . . . . . . . . . . . . . . . . . . 131

C.3. ActivityFunctionTreeContentProvider.java . . . . . . . . . . . . . . . . . . . . . 131

C.4. ActivityFunctionWrapper.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

C.5. ActivitySelectionDialog.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

C.6. FlowSelectionDialog.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

C.7. InvisibleCompartmentFigure.java . . . . . . . . . . . . . . . . . . . . . . . . . 136

xii

List of Code extracts xiii

C.8. PredecessorRelationBodyFigure.java . . . . . . . . . . . . . . . . . . . . . . . 137

C.9. StepBodyFigure.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

C.10.StepPainter.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

C.11.StepPropertyFigure.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

C.12.CustomizedPropertyDescriptor.java . . . . . . . . . . . . . . . . . . . . . . . . 141

C.13.CustomizedPropertySource.java . . . . . . . . . . . . . . . . . . . . . . . . . 143

1Introduction

1.1. Aim of the Master Thesis . . . . . . . . . . . . . . . . . . . . . 1

1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Description of the Task . . . . . . . . . . . . . . . . . . . . . . . 2

1.3.1. Acquire Technical Knowledge . . . . . . . . . . . . . . . . . . . 3

1.3.2. Implementation of the Graphical Aspect Model Editor . . . . . 3

1.3.3. Worst Case Scenario . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4. Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4.1. University of Fribourg . . . . . . . . . . . . . . . . . . . . . . . 4

1.4.2. Swisscom IT Services . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.3. Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5. Hard- and Software Used . . . . . . . . . . . . . . . . . . . . . . 6

1.5.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.6. Notations and Conventions . . . . . . . . . . . . . . . . . . . . . 6

1.7. Structure of this Paper . . . . . . . . . . . . . . . . . . . . . . . 7

This Master Thesis is a cooperation between the University of Fribourg and SwisscomIT Services in Ostermundigen (Bern). The goal is the elaboration of a graphical editorin order to facilitate the work of the developers. The following sections will explain thethesis in more detail.

1.1. Aim of the Master Thesis

About eight years ago, i.e. in the late 1990's Swisscom started the elaboration of a systemthat is capable to process customer requests automatically. That system is called OrderManagement Swisscom (OMS), and will be explained in more detail in Chapter 3, hereonly a quick overview is given for describing the aim of the Master Thesis.In order to be able to execute a process one basically needs to know three things, therebyit is not important whether the process is executed by a human or an engine:

1

1.2. Motivation 2

1. Which steps have to be executed and under which circumstances.

2. The sequence of the steps that have to be executed.

3. The data �ow towards and away from every step.

Within OMS this process knowledge is de�ned using rules. Those rules allow OMS toevaluate an appropriate process for a concrete customer request (order) dymanically atruntime. Refer to Chapter 3 for a more detailed explanation of how this works.The experience of OMS shows, that it is very advantageous to be able to calculate pro-cesses at runtime. However only parts of the processes depend on dynamic facts. Thebasic structure of the processes typically is static.Therefore the idea came up to combine the power of the dynamic process evaluation withthe simplicity of a static process model (template process). The static process modelcould be de�ned using a graphical editor. The rules will then modify the static processmodel at runtime to adapt to the concrete situation of each process instance.This �hybrid architecture� will lead to the following advantages:

• Keep the high process �exibility while reducing the complexity of process de�nition.

• Consistent documentation as the static process model provided by the graphicaleditor implicitly documents the process. (No need to document the processes withMicrosoft Visio any more).

• Higher productivity in the area of process de�nition.

• Less error prone.

The aim of the Master Thesis is to develop a graphical editor to depict the static processmodel to facilitate the work of the developers at Swisscom IT Services. Section 1.3describes the task in detail.

1.2. Motivation

This section describes why such a graphical editor is of great use. In the previous sectionwe mentioned, that the process de�nition is done with the help of rules. The rule extracton Figure 1.1 on the left shows a so called template rule. Find in Section 3.6 an examplethat illustrates the idea of a template rule. Here only a short illustration is sketched togive you a feeling about the bene�ts.Figure 1.1 shows on the left the template rule as it has been used up to now. On theright you can see the idea about how the static process de�nition could be modeled infuture.What is visible straight away is, that the template rule on the left requires further docu-mentation, whereas the model on the left is self-explaining.

1.3. Description of the Task

The main goal of the Thesis is the development of the just mentioned graphical editor,named Graphical Aspect Model Editor (GAME). That goal has been split up into twosubgoals.

1.3. Description of the Task 3

Figure 1.1.: Motivation for the development of a graphical editor

1.3.1. Acquire Technical Knowledge

The idea is to implement the editor as an Eclipse plug-in. Eclipse provides di�erentframeworks that facilitate the development of graphical editors. The Graphical ModelingFramework (GMF) should be studied particularly. During the technological study thefollowing questions should be answered to see if GMF is appropriate as a base for GAME:

• Is GMF easy to use?

• Is GMF �exible enough?

• Is GMF stable?

• What are the advantages of using GMF instead of using the underlying frameworksEclipse Modeling Framework (EMF) and Graphical Editing Framework (GEF)?

The study can lead to one of the following cases:

• GMF is quali�ed: A documentation has to be elaborated in order to help OMSdevelopers to get started and to be able to work easily with GMF.

• GMF is not quali�ed: Alternative technologies have to be studied (EMF and GEF,ILOG JViews, Microsoft Visio).

1.3.2. Implementation of the Graphical Aspect Model Editor

Building on the knowledge gained from the technical study the Graphical Aspect ModelEditor, which enables the editing of static process structures, will be developed. Theeditor should produce the following results:

• The data model of the process structure as an Extensible Markup Language (XML)document, which will be used as input for the process engine of Swisscom the CleanOrder Manager (CLOM).

• An image of the process structure, which can be displayed in a browser (Graph-ics Interchange Format (GIF), Portable Network Graphics (PNG), Scalable VectorGraphics (SVG)).

1.4. Organization 4

Figure 1.2.: Scope of the Master Thesis

The following tasks are not part of the Master Thesis and have to be elaborated bySwisscom IT Services (OMS):

• De�nition of the data model for the process structure.

• Adaption of the CLOM engine.

• Embedding of GAME in OMS.

1.3.3. Worst Case Scenario

In the worst case neither GMF nor GEF and EMF are apropriate. This implies that asolution without Eclipse has to be found. In this case alternative technologies (ILOGJViews [21], Microsoft Visio) have to be studied.In the unlikely case where this becomes true, it may be, that the second part has to beshortened or can not even be carried out.

1.4. Organization

As already mentioned before, this Master Thesis is a cooperation between the Universityof Fribourg and Swisscom IT Services, so there are some organizational points to beconsidered. The next subsections describe the role of each party.

1.4.1. University of Fribourg

The author is a student in computer science at the University of Fribourg. The SoftwareEngineering Group of the department for computer science at the University will superviseand review this Master Thesis.

1.4. Organization 5

1.4.2. Swisscom IT Services

The Master Thesis is elaborated within the scope of an internship at Swisscom IT Services.During this internship the Graphical Aspect Model Editor (GAME) will be elaborated.

1.4.3. Project Schedule

An appropriate time schedule is inevitable for every project. Find in this subsection howthe time is split up to achieve the expected 900 working hours representing 30 EuropeanCredit Transfer System (ECTS). This project schedule forms a guidline however and hasnot to be followed strictly.

Middle of July - end of August 2007 (about 250 working hours)

• Elaboration of technical basics (literature and tests)

� Eclipse RCP

� Rules, Process Engine

� OMS, CLOM and other products at Swisscom

• Technical analysis: GMF

September - November 2007 (about 500 working hours)

• Design and implementation of the application

• Testing, debugging, technical documentation (Javadoc, Uni�ed Modeling Language(UML) diagrams, ...)

• Elaboration of the documentation plan

December 2007 (about 150 working hours)

• Editing of the documentation

• Presentation at Swisscom IT Services

• Presentation for the reseach group, demonstration of the application

Milestones

• Monday, July 16th 2007

� Start of the internship at Swisscom IT Services.

� O�cial start of the Master Thesis.

• Monday, September 3rd 2007

� Presentation of the technical study at the University of Fribourg. Demonstra-tion of the tests that were carried out.

� Decision point: Will the application be developed with GMF.

• Monday, October 15th 2007

1.5. Hard- and Software Used 6

� Presentation of the application design at the University Fribourg.

� Presentation of a �rst version of the application at the University of Fribourg(demonstration that shows the feasibility of the project).

� Discuss encountered problems and for which ones a solution still has to befound.

• Monday, November 26th 2007

� End of implementation and tests.

� Demonstration of the Graphical Aspect Model Editor (GAME).

� Presentation, discussion of the detailed content of the documentation (Univer-sity of Fribourg).

• Wednesday, December 19th 2007

� Hand-in of the application and the documentation.

• Monday, January 28th 2008

� Ultimate deadline for the delivery of the Master Thesis.

1.5. Hard- and Software Used

Because in computer science problems with compatibility are well known, here a list ofthe hard- and software used for the elaboration of the Editor.

1.5.1. Hardware

• Desktop Computer: Dell Optiplex 745

• Notebook: Acer TravelMate 242LC

1.5.2. Software

• Eclipse Europa, Version 3.3.0

• Graphical Modeling Framework, Verison 2.0

• Java, Version 6.0

• LEd, build 0516200

• MikTex, Version 2.6

• Mozilla Firefox, Version 2.0.011

• UltraEdit, Version 10.20d

• Windows XP Professional, Version 2002 SP2

1.6. Notations and Conventions

This section describes the notations and conventions that are used throughout this paper.

• Formatting conventions:

1.7. Structure of this Paper 7

� Bold is used for emphasis and menus, menu items, tab and window names,etc.

� italic is used for highlighting terminology.

� SansSerif is used for web addresses.

� Code is used for all Java code and generally for anything that would be typedliterally.

• Figures, Tables and Code extracts are numbered inside a chapter. For example, areference to Figure j of Chapter i will be noted Figure i.j.

• Web resources are referenced like this [1].

• Standard bibliography like this [Hav05].

• Source code is displayed as follows:

1 i f ( c h i l d instanceof IBo rde r I t emEd i tPa r t ) {Bo rde r I t emSe lec t i onEd i tPo l i cy ep = new Borde r I t emSe lec t i onEd i tPo l i cy ( ) ;

3 ep . setDragAllowed ( fa lse ) ;return ep ;

5 }

1.7. Structure of this Paper

This paper is devided into ten chapters, which themselves are devided into sections. Asection may be further devided into subsections and paragraphs.The �rst chapter gives an overview on the goal of the Master Thesis and how everythingis organized between the di�erent parties involved in this Master Thesis. Chapter 2then gives a short overview of what is the automation of processes. In Chapter 3 youwill get an introduction to the Order Management Swisscom (OMS), which builds thebackground for this Master Thesis. The fourth chapter presents the Eclipse RCP, GMFwill be presented in Chapter 5. Chapter 6 describes the �rst part of the Master Thesis,which is the technological study. The generall architecture of the devlopment tool GAMEand how it is embedded into OMS is the topic of Chapter 7. Chapter 8 is very technicaland may be skipped at �rst reading. It describes the con�guration of GAME and thecustomizations that were added. Practical again is Chapter 9 which introduces the readerin using GAME. The conclusion in Chapter 10 evaluates the Master Thesis and givesperspectives towards the future.

Sans Serif

2Automation of Processes

2.1. Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2. Automation of Processes . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1. Bene�ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3. Standards for Describing Business Processes . . . . . . . . . . 10

2.4. Rules and Rule Engines . . . . . . . . . . . . . . . . . . . . . . . 11

The background of this Master Thesis is the automation of processes. This chapterprovides some terminology for avoiding misunderstandings. Then it lines out under whatcircumstances processes may be automated and some tools for modeling processes arepresented.

2.1. Business Processes

The word business process has become fancy in the last few years. The problem withcommonly used words is, that they often are used in wrong context, which may lead tomisunderstandings. This is why the term is clari�ed at this point.The term business process exists as long as businesses itself exist, and it existed longbefore the �rst computer was invented. So a business process as such has nothing to dowith Information Technology (IT). The following de�nition can be found in [26]:�A business process is a sequence of activities followed by individuals in a business toachieve some business goal. Often these are manual activities executed by employees,who play certain roles in the business in addition to others who are external to thebusiness: customers, business partners, etc.�.It is also in the nature of businesses and managers to re�ne the business processes in orderto gain an advantage over competitors. IT can be a solution for increasing e�ciency, i.e.by automating certain processes. This does nevertheless not change the fact, that abusiness process itself has nothing to do with technology. The next section describeswhich processes, and under what circumstances may be automated.

8

2.2. Automation of Processes 9

2.2. Automation of Processes

As mentioned in [JM06], �a process performs actions over some interval of time in orderto achieve, or to progress to, some objective�. If the logic of a process may be describedprecisely and unambiguously the process may also be executed by an engine instead of ahuman. Let us de�ne some terms before continuing [JM06]:

Process de�nition The basic algorithm or behavior of the process.

Process instance An occurrence of a process for speci�c input. Each instance of a travelreservation process, for example, is tied to a speci�c customer.

Process engine The process engine is the engine, that executes the process instancesautomatically following the rules in the process de�nition.

Activity or task A step in a process, e.g. manually sending a �ight request to an airline.

Automated activity or automated task A step in a process that is performed directlyby the process engine, no manual interaction. The �ight request is sent automati-cally.

Manual activity or manual task A step in a process that is meant to be performedby a human process participant a so called Human Intelligence Task (HIT), e.g.exception handling or where the customer has to take a decision.

If a process ful�lls the criterias of being precise and unambiguous it can be automated.Such processes are for example communication activities with external systems, or pro-grammatic logic activities as calculations for instance.The process of studying the design and execution of processes is called Business ProcessModeling (BPM). Nevertheless it does not imply the automation of all processes. BPMagain is a fashionable three-letter acronym which is often used in wrong context. Thereare processes that may not be executed by a machine, even if the process was modeled.This is, if either it can not be de�ned precisely or it is ambiguous or both.The input of a process engine is a request or order. This request can be executed by theprocess engine thanks to the process de�nition that is provided to the process engine.With the help of that de�nition, the engine is then able to execute instances of processesautonomously.

2.2.1. Bene�ts

Now we know under what circumstances a process may be executed by a machine. Butwhy are processes automated at all? The list below shows some bene�ts of automatingprocesses:

• The process engine needs a detailed and precise process de�nition. This impliesminutious understanding of the process, which may reveal improvement possibilities.

• The throughput time of the process as a whole is reduced. This implies that thecustomer has a shorter waiting time, from the order of the product until he gets it.

• The time between the tasks gets shorter, if for example the tasks are handed forwardby e-email rather than by a person.

• The cost for employees may be brought down. This has mainly two reasons:

2.3. Standards for Describing Business Processes 10

� Some processes are executed autonomously by the process engine. This impliesthat less employees are needed to get the same work load done.

� If most of a process is executed automatically, the employee needs to knowless about the whole process. This enables shorter entering times for newemployees and through that enables the hiring of temporary employees.

• Overall performance may be increased, which leads to a bigger customer satisfaction.

• Regulatory requirements may be implemented into the engine directly, this impliesthat they do not get forgotten and no penalty fees have to be payed.

• Less error prone in general.

2.3. Standards for Describing Business Processes

As the automation of processes became popular the race of publishing standards fordescribing them started. Here we introduce some of the most important ones. At thispoint only a short overview of that standards will be given. Refer to �Essential BusinessProcess Modeling� by Michael Havey [JM06] to have a detailed description.

Business Process Execution Language (BPEL) This standard was published by theOrganization for the Advancement of Structured Information Standards (OASIS) and wasoriginally called Business Process Execution Language for Web Services (BPEL4WS).Through the common usage under Business Process Execution Language (BPEL) it haslater been shortened to BPEL. Enterprises like IBM, Microsoft and Oracle stand behindthis standard. This is also the reason why it has the biggest chance to win the standardswar. Nowadays BPEL is the most common standard, but it is still not clear who is goingto win that war.With BPEL a process is described in XML-based manner as a web service. Thereby a webservice may be invoked by other web services or may itself invoke another web service.

Business Process Modeling Language (BPML) Provided by the Business ProcessModeling Initiative (BPMI) the Business Process Modeling Language (BPML) is also anXML-based language and quite similar to BPEL.

Business Process Model Notation (BPMN) The Business Process Modeling Notation(BPMN) is also provided by BPMI, this standard provides a sophisticated graphicalnotation. It is in the nature of the human to sketch things on paper or a white board forbetter understanding. BPMN includes a mapping to BPEL, the BPML-rival and as suchfacilitates the execution of BPMN designed processes on BPEL engines.

Web Service Choreography Description Language (WS-CDL) A standard recom-mended by the World Wide Web Consortium (W3C) is the Web Service ChoreographyDescription Language (WS-CDL). It provides a global view of how web services are ar-ranged in the control view of multiple participants. The web service choreography standsin contrast to the process orchestration of BPEL for example. BPEL designs a process

2.4. Rules and Rule Engines 11

for a single participant, whereas a choreography delivers an interaction model for a groupof participants.

Business Process Speci�cation System (BPSS) The Business Process Speci�cationSystem (BPSS) proposed by OASIS is similar to a choreography language but for business-to-business communication. The idea is to have a buyer-seller exchange with acknowl-edgments at each time a step is executed with success.

Exportable XML formats Unlike the standards mentioned before, the aim of theWork-�ow Management Coalition (WfMC) was not to de�ne a new standard for graphical nota-tion, but to provide an exportable XML format. This is how the XML Process De�nitionLanguage (XPDL) was born. Processes de�ned using that format may be run on a WfMCenactment engine.They also provide a Work�ow API (WAPI), which enables the integration with externalapplications, client integration and the ability to include human activity processing.

Meta Model and Runtime Interface The contribution of the Object ManagementGroup (OMG) was not to build a new process language or interface, but to build anabstract model conforming to its Model-Driven Architecture (MDA). So they provideproposals for a Business Process De�nition Meta Model (BPDM) and a Business ProcessRuntime Interface (BPRI).

Summary To wrap it up, we can consider that BPEL nowadays is the most popularlanguage for business process description. The other standards serve some speci�c tasksbut cannot provide an overall description. MDA helps to get, or to describe an abstractview of the process without having to bother about the exact BPEL syntax. It may becompared with the modeling language UML: with the help of UML one can describe aJava program in abstract manner to gain an overview without having to think about thecorrect syntax.WS-CDL is the leading choreography language. It solves a slightly di�erent problem thanBPEL and may therefore be viewed, like BPSS as well, as a complement to BPEL.BPMN provides the graphical notation from which BPEL de�nitions can be derived orgenerated directly.

2.4. Rules and Rule Engines

Rules describe the operations and constraints for achieving a goal. Each rule has acondition and an action part. Such a rule may state that customers who did not pay thebills cannot order new products. Rules are combined to rule sets.A Rule engine, mostly based on the RETE algorithm [25], is the software that exploitsa match-resolve-act cycle to support forward chaining and inferencing. It veri�es theconditions of all the rules existing in a rule set against the facts and executes the actionpart of a rule whose condition evaluates to true. That execution may change the facts.With the now changed facts base some rules whose condition were true before may becomefalse and the other way round. In a next iteration the rule engine again evaluates all the

2.4. Rules and Rule Engines 12

rules in a rule set against the �new� facts and executes an action part of a rule with aful�lled condition, and so on.Up to today there is no standard formalism for describing rules, every vendor of rulesoftware uses its own formalism.

3Order Management Swisscom

3.1. Goals Set for OMS at Project Start . . . . . . . . . . . . . . . 14

3.2. Swisscom Terminology . . . . . . . . . . . . . . . . . . . . . . . 14

3.3. OMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4. OMS Process Engine (CLOM) . . . . . . . . . . . . . . . . . . . 16

3.4.1. Declarative Process Description . . . . . . . . . . . . . . . . . . 17

3.5. The CLOM Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19

3.6. Informal Example: Sightseeing Tour . . . . . . . . . . . . . . . 21

3.7. Graphical Aspect Model Editor (GAME) . . . . . . . . . . . . 24

3.7.1. Changes in the OMS with GAME . . . . . . . . . . . . . . . . 24

3.7.2. Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Next to the University of Fribourg, Swisscom IT Services is a supervisor of this MasterThesis, which consists of elaborating a development tool for Swisscom IT Services. Thischapter gives an overview (high level of abstraction) on the background at Swisscom.Swisscom is the leading telephone company of Switzerland. It provides nation wide ser-vices for mobile, �xed line and Internet Protocol (IP)-based voice and data communica-tions. Swisscom IT Services is a division of Swisscom and one of the leading providers ofIT services in Switzerland. The core business is the integration and operation of complexIT applications and infrastructures [Ser].Swisscom has a system called Order Management Swisscom (OMS) that is able to executebusiness processes from the retail business completely autonomically. The agents in thecall center, or the customers themselves, can make a request and hand them over to theOrder Management Swisscom. OMS then controls all technical and administrative tasksin order to ful�ll the request. Typical processes for the OMS are:

• Installation, modi�cation, deletion of a �xed line connection

• Installation, modi�cation, deletion of IP-based broadband services (Internet, Voiceover Internet Protocol (VoIP) TV)

Today OMS comprises of about 100 processes and handles about 25.000 requests a day.

13

3.1. Goals Set for OMS at Project Start 14

3.1. Goals Set for OMS at Project Start

When Swisscom started the elaboration of OMS in the late 1990's the goal was that over60% of all the requests could be executed automatically. When speaking about processautomation in general a new task for the process engine is called request. At Swisscommostly the term order is used. In context with Swisscom a request is therefore synonymwith order.Nowadays1 over 95% of all the orders are handled automatically.Today following entry channels are common at Swisscom, as can be seen on Figure 3.2on page 16:

• Customer Care (CuC) In this case the order is entered by a Swisscom agentfrom the Call Center.

• WWW Here the customer enters the order by himself through an Internet form[14].

• Mail Inbound Center (MIC) This orders enter in the MIC in form of a talon thatcan be found in prospects or equivalent. In the MIC these talons are scanned andeither form an order for the process engine directly, or are distributed electronicallyto the Swisscom agents.

• Interactive Voice Response (IVR) It is also possible to enter orders to the OMSby phone through an IVR system.

3.2. Swisscom Terminology

This section describes the terminology used at Swisscom in the domain of process man-agement:

Process A de�nition of a process was already given in Section 2.2. Relative to Swisscomthis term has the same meaning. It represents the Steps that have to be executed inorder to achieve a certain goal, e.g. provide a �xed line connection to a customer.At Swisscom the term process is equivalent to Root Flow.

Step A process contains an arbitrary number of Steps. A Step ful�lls one task of theprocess, e.g. reserve a phone number for that �xed line connection. Generallyspeaking a Step de�nes what has to be done.

Step Implementation A Step Implementation knows how to perform a task. Each Stephas an implementation. A Step may be implemented either as a Flow, which maycontain other Steps again or as an Activity. These terms will be explained later inthis list.

Activity An Activity is the smallest unit in a OMS process that may be executed andrepresents the abstraction of a service call. Take the LetterService as an example,which is applied every time a letter needs to be written and sent to the customer.

Flow A Flow is a sequence of Steps. As a Root Flow it shares many properties with aprocess. A RootFlow is a Flow which has no parent. In the case where the Flow isreferenced from another Flow we talk of a Subflow. A Flow is de�ned by one or moreAspects.

1last measurement January 2007

3.3. OMS Architecture 15

Figure 3.1.: UML diagram showing the relation of Step, Activity, etc.

At Swisscom there exists a Root Flow called InternetNew for example, which executesthe sequence of Steps (Subflows and Activities) that are needed to get an Internetconnection.

Aspect An Aspect de�nes a reusable behavior of a process and may be attached to a Flow.An Aspect consists of an Aspect Model and Aspect Rules. An Aspect evaluates whichSteps have to be performed in order to achieve its task.Due to the declarative nature of the CLOM it is easy to merge multiple Aspectswithin one Flow. Therefore it is possible to reuse Aspects. If for example di�erentFlows have to provision partners we can de�ne one provisioning Aspect, which isadded to all Flows which need to care about provisioning.

Aspect Model The Aspect Model represents the static structure of an Aspect. It basi-cally declares all possible Steps and their Predecessor Relations. This model will bedeveloped with GAME in the future.

Aspect Rules The Aspect Rules de�ne the dynamics of a process, i.e. for each optionalStep they de�ne under which circumstances it must be performed.

Predecessor Relation A Predecessor Relation is a relation between two Steps. It is usedto declare the sequence of the Steps. A Step is allowed to be executed as soon as allof its Predecessor Relations are satis�ed.

The UML diagram depicted in Figure 3.1 gives an overview on the relationship between allthis terms. The rectangle that is colored in blue will be replaced by the model producedwith the Graphical Aspect Model Editor in the future.

3.3. OMS Architecture 16

Figure 3.2.: The OMS Layers

3.3. OMS Architecture

To explain the architecture of OMS we make use of an informal example. This example isan ordinary restaurant. Every restaurant has a kitchen. In the kitchen you �nd a cooker,pans, a fridge, a mixer and so on. Now let us say, that all these tools in the kitchenform the domain logic of that restaurant. If we go up one layer, we get to the processlogic. In the restaurant this is the cook with the menu card and the recipe for each meal.The last layer we need is the order entry, which is represented by the waitress in ourinformal example.If we come back to OMS now the mapping is, with the help of Figure 3.2, quite easy.The domain logic is represented by services, e.g the LetterService which is responsible forcomposing and sending letters. The cook, the menus and the recipes in the restaurantexample are replaced in OMS with the process engine and the process de�nitions. And�nally, the order entry is replaced with the call center, the Internet, IVR and MIC.Today OMS de�nes over 100 processes and handles about 25.000 orders a day, whichimplies 500.000 process steps. In addition the OMS service layer executes 2.000.000service calls a day.

3.4. OMS Process Engine (CLOM)

The CLOM (the brain on Figures 3.6 on page 20 and 3.11 on page 22) is an in-housedevelopment of Swisscom.Now the reader may ask himself why Swisscom developed the CLOM in-house, insteadof using a commercial order manager. This lies in the fact, that processes in the �xedline telecommunication business have certain characteristics, that make the automationmore di�cult than for other businesses:

• One of the main reasons why it is quite di�cult to automate �xed line telecom-munication processes, is that the processes typically change the con�guration of an

3.4. OMS Process Engine (CLOM) 17

existing access. The process to provide a service to a customer therefore alwaysdepends on the current con�guration of the customer's access. Changing the con-�guration of one service might involve changing a dependent service (e.g. changingthe con�guration of the broadband access might a�ect the IP TV service).

• Another important fact is, that those processes often are long running. The reasonfor this is that processes include long running Steps like sending hardware to thecustomer or even providing on-site support. Long running processes imply the riskthat the environment changes in the mean time.

Therefore the process must be able to adapt to changing conditions at runtime. Thosespeci�c characteristics of the �xed line telecommunication processes make them very com-plex.Analysis done before the project OMS was started showed, that it would not be possi-ble to automate those processes using conventional process engines - the process graphwould become too big and the engines are not �exible enough to adapt process instanceson changed circumstances.The idea of the CLOM is to implement processes declaratively to evaluate the concretepath of one process instance iteratively at runtime. Swisscom IT Services implementsrules, which declare under which circumstances a certain Step is required (process knowl-edge). Those rules are applied to the concrete situation of one process instance and�draw� the path for this process instance. The engine then checks what may be executedin that process instance, then a new iteration starts. This approach eliminates the hugeprocess graph covering all variations and allows to adapt to changed conditions at anytime. To have a vizualisation compare Figures 3.11 on page 22 and 3.12 on page 23.

3.4.1. Declarative Process Description

OMS describes its processes declaratively. This section describes the tools that are neededfor this declarative description.What is generally true, whether processes are described imperatively or declaratively, isthat the description of a process has to give an answer to the following questions:

1. Which Steps are in the process?

2. Which is the sequence of the Steps that characterizes the process?

3. Which is the data �ow between the Steps?

In the context treated for this Master Thesis, the data �ow is not relevant. So we do notgo further into that point.For a declarative description these questions are not asked for the process as a whole, butfor each Step. This gives us (with skipped third question because it is no relevant in thiscontext):

1. When is this Step needed?

2. When may this Step be started?

Answer the �rst question There are two possible answers to the �rst question. The�rst possibility is, that the Step is needed in all the process instances. The second possi-bility is, that the Step is only needed under certain conditions.To describe these two possibilities a Step can be in one of two states. In the �rst case,

3.4. OMS Process Engine (CLOM) 18

Figure 3.3.: The two states of a Step

Figure 3.4.: Predecessor Relations

where the Step is needed in all the process instances, the state of the Step is mandatory.In the second case, where the Step is only needed under certain circumstances, the stateof the step is optional. The condition under which this step is required is described onthe top right of the �gure in square brackets. Behind that condition in square bracketsstands a rule that veri�es at each iteration, if the condition is ful�lled or not. In the casewhere the condition is ful�lled, the Step is required by that rule, i.e. the rule draws thisstep into the process that was already drawn by other rules for that process instance.Figure 3.3 shows how this is represented graphically.

Answer the second question Also for the second question we have two possible an-swers. Firstly, there are Steps that can be started immediately. Secondly, there are Stepsthat may only be started after some other Steps completed.To depict the answer to this question the Predecessor Relation was brought in. A Step thatmay be started immediately is a Step which is not linked through a Predecessor Relationwith an other Step. In the case where other Steps have to be completed before a certainStep may be started, this is as follows:A Predecessor Relation always links two Steps. The Step that has to be executed �rst iscalled predecessor, the one that is executed after the �rst has completed is called succes-sor. In Figure 3.4 on the left, you can see the just mentioned visually. Since a successorcan have n predecessors, a successor may be started as soon as all its Predecessor Relationsare satis�ed.Now you may ask yourself, what happens if the Predecessor Relation is referencing an op-tional Step. Here comes the answer: A Predecessor Relation referencing an optional Step,which is not required (i.e. the rule does not draw that step to the generated runtimeprocess), is satis�ed as soon as the optional Step could be started. For the case visualized

3.5. The CLOM Algorithm 19

Figure 3.5.: Di�erence between imperative and declarative description

in Figure 3.4 on the right this means, if Step B is not required, p2 is satis�ed if p1 issatis�ed. Because as soon as p1 is satis�ed, B could be started.

Imperative versus declarative Figure 3.5 shows the di�erence between imperative anddeclarative process description. With imperative process description the arrows mean�control �ow�, this is also the reason why the condition is on the arrow itself. For acertain process instance, this path will only be passed, if the condition is true.With declarative description on the other hand, the arrows mean �predecessor relation�.The focus with declarative description lies on the Step (Step oriented) and not on thewhole process. The process that will be followed is only generated at runtime, and isreevaluated at each iteration.The world of imperative description is the world of the standard BPEL. Because theCLOM uses declarative description, that standard is not suitable for its process descrip-tion.

3.5. The CLOM Algorithm

This section describes the basic principles of the algorithm that the CLOM uses. Basicallythe CLOM algorithm uses the same principle a human uses. We have to achieve task X,so we think based on the facts what is to do. Once we found out what is the �rst thingto do, we act. This may change the facts, so again we think what we have to do nextand are like this able to react on changes. Based on what we found out we act again, andso on. Let us see now how this �human� algorithm is formulated in a bit more technicalterms. Figure 3.6 illustrates the points mentioned below:

• The requirements for the processes are described with rules.

• The needed facts from back end systems (external circumstances) or orders areprovided to the rule engine on-demand.

• With the help of the rules the process to be followed is evaluated.

3.5. The CLOM Algorithm 20

Figure 3.6.: The CLOM Algorithm

Figure 3.7.: A template process

• According to that evaluation the next Steps are executed, this leads to a change ofthe facts.

• The process to follow is reevaluated by means of the rules and the changed facts.

• This iteration goes on until either a rule requires the termination of the process oruntil there are no more rules to be evaluated.

• Facts may be:

� Information in the actual order itself

� Results from foregoing Steps

∗ States of databases, peripherals, other in parallel executing orders

∗ States from foregoing Steps

� Input of the user (exception handling, manual task)

� Events (timer, external, etc.)

Find in the next section an informal example to make things clearer.

3.6. Informal Example: Sightseeing Tour 21

Figure 3.8.: A �just in time� decision

Figure 3.9.: Handling of variations

3.6. Informal Example: Sightseeing Tour

Because the real processes that are treated with OMS are pretty complex let us clarifythe algorithm by means of an informal example. Everyone has already been visiting aforeign city. So imagine you are exploring a city. One day of your discovery tour youwant to book a sightseeing tour of that city at a travel agency.

Template Rule One sightseeing tour that the agency o�ers is illustrated in Figure 3.7.The tour comprises �rst to visit the Castle, then you will go to see the famous Bridge ofthe city. Next you go to the Market Hall, where you may eat something for lunch. Thenyou go to the Park to relax a bit. After relaxation the tourist guide will show you DownTown.Now what is really shown in Figure 3.7? What you can see in this �gure is the so calledtemplate rule. The condition for that template rule is always true. This is why thesequence of the �ve Steps described in the action part of that rule, will always be drawnin the process generated at runtime. The rule that you can see in Figure 3.7 has a highlevel of abstraction. The real template rule for the sightseeing tour is indicated at theend of this chapter in Figure 3.16 at the left2.

2Depicted with JRule (*.ilr), the rule language of ILOG [19]


Figure 3.10.: Condition triggered process

Figure 3.11.: Processes generated at runtime

�Just in Time� Decision Since processes are depicted declaratively and the runtimeprocess is reevaluated at each iteration, dynamics are possible. This means, that theprocess is reevaluated after each Step and thus external events may change the structureof the process instance during its lifetime.If we come back to our sightseeing example, it might, for instance, be that it is raining.Visiting a Park when it is pouring down with rain is not that funny and many touristswould like to cancel the sightseeing tour, if no alternative solution is provided.To take rain into account, a new dynamic rule is added as you can see in Figure 3.8.Every rule is evaluated at each iteration of the algorithm. Every time that the �rainingcondition� is true, the Step Park will be replaced with the Step Museum in the runtimeprocess.

Customer Options In addition to the simple sightseeing tour, you can book the �GoldOption�, which admits the tourist to visit the Opera and a Church. To let the CLOMknow about that �Gold Option� a new rule is implemented. That rule checks for eachtourist group if it has booked the �Gold Option� or not. If the tourist group did book the�Gold Option�, the two Steps Opera and Church are added to the runtime process, whichalready consists of the sequence of the �ve Steps that were drawn by the template rule.Important here is to point out, that rules have an additive character. The template rule


Figure 3.12.: Imperative process de�nition

draws its runtime process every time because its condition is always true. Each additionalrule which condition is also ful�lled, adds Steps to the runtime process.Be careful not mixing up the arrows in Figure 3.9 with the meaning �control �ow�, thearrows visible in that �gure, mean �predecessor relation� (Figure 3.5). So the Step MarketHall can be started, if all its Predecessor Relations are satis�ed. All the Predecessor Relationsof the Step Market Hall are satis�ed, if the tourist group has seen the Bridge and hasbeen in the Opera.Because of the high level of abstraction the de�nition of the Predecessor Relations for theSteps Opera and Church are missing in the rule of Figure 3.9. In a real rule this has tobe de�ned.

Emergency The process engine also is able to react on emergencies. Imagine somethinghappens and the process has to react immediately to that event. For our sightseeing touran example could be, that a tourist su�ers a heart attack. In that case the health care ofthat tourist has absolute priority.To handle such an emergency, again a new rule is needed. Figure 3.10 visualizes thatcase. This newly added rule draws the detached �high priority� process into the runtimeprocess, if the condition of an injured tourist becomes true. Once the incident is handled,in our example this is, if the tourist is on its way to hospital, the high priority processterminates. In the next iteration the CLOM checks what is to do next. It takes the ruleshe knows and the now changed situation and evaluates, if there is still work to be done.If there is a Step that may be executed, it gets executed. In this way the process, thatwas running before, may be relaunched if the external circumstances still allow it.

3.7. Graphical Aspect Model Editor (GAME) 24

Figure 3.13.: Process generation with GAME

Summary The sightseeing tour makes clear what is meant with declarative processesthat are evaluated dynamically at runtime. Figure 3.11 visualizes this fact.On this �gure the process engine is represented as a brain that takes into account the rulesthat were provided to it. That brain also takes into consideration external circumstances.With the help of this two inputs it generates the according runtime process. Every timethat a Step �nishes (i.e. at each iteration), e.g. the tourist has been in the Market Hall,the brain checks again its environment and generates a new, suitable process if needed.To wrap it up the brain needs four rules and the capability to react on its environmentand all the possible processes may be generated at runtime. If that process would bedepicted only statically this would result in the process structure shown in Figure 3.12,which is much more complex.

3.7. Graphical Aspect Model Editor (GAME)

Since what is visualized for the sightseeing tour, and what will be visualized with thedevelopment tool GAME is very similar, we will point out the di�erence in this section.We will also give a �rst idea, of how GAME is going to be integrated within OMS.

3.7.1. Changes in the OMS with GAME

With the implementation of GAME, things are going to change. This concerns both therule de�nition and the input into the process engine CLOM.

Rule de�nition For the rules standing behind dynamic facts, i.e. the condition is notalways ful�lled, nothing changes. They are still needed and de�ned in a similar way asbefore.The rule that is concerned when GAME is used is the template rule, this is the rule whichcondition is always true. With the new development tool GAME this template rule may


Figure 3.14.: CLOM algorithm with new input

be depicted graphically. This implies that the template rule is not needed anymore andis replaced by the model produces with GAME.Because this model depicted by GAME is also used for documentation, there is slightlymore information (like notes for example) in the model of GAME as in the replacedtemplate rule. Figure 3.16 at the end of this chapter illustrates that replacement.

CLOM engine The CLOM algorithm as such stays the same. The only thing thatchanges is the input to the process engine. If the template rule is replaced with theaspect model de�ned with GAME, the CLOM needs to be able to interpret that model.How this is done, is not mentioned in this paper however.Figure 3.13 shows the new input, which consists now on the aspect model depicted byGAME and the rules. With the rules the algorithm is still able to adapt the process tochanged facts at runtime.It is important not to mix up the model depicted with GAME with the runtime processthat is generated through the process engine. GAME de�nes the process, whereas theruntime process represents a solution for a speci�c process instance. Figure 3.14 visualizesthat fact.

3.7.2. Integration

The integration of GAME into the OMS system is out of the scope of this Thesis. Nev-ertheless a short description of how this is going to be done is given here.The developers at Swisscom IT Services will still follow the same routine as before. Firstthey de�ne the process in a so called Flow Descriptor Editor. In that editor they havethe possibility to specify the Flows and the attached Aspects that the process is going toconsist of. Before GAME this had to be coded with rules. Now they have the possibilityto open GAME and describe the process graphically.The output of GAME is an XML document, which will be read and interpreted by theCLOM.


Figure 3.15.: Integration of GAME with OMS

Figure 3.15 gives an overview of that architecture. Refer to Chapter 7 to get a detaileddescription.


Figure 3.16.: Aspect model for the sightseeing tour depicted with GAME

4Eclipse RCP

4.1. The OSGi Speci�cation . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1. Module Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1.2. Lifecycle Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.3. Service Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.4. Implementations of the OSGi Speci�cation . . . . . . . . . . . . 32

4.2. Extensibility of Eclipse . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1. Equinox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.2. Extension Registry . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.3. Extension and Extension Point . . . . . . . . . . . . . . . . . . 34

4.3. UI-Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.1. Abstract Window Toolkit (AWT) . . . . . . . . . . . . . . . . . 35

4.3.2. Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3.3. Standard Widget Toolkit (SWT) . . . . . . . . . . . . . . . . . 36

4.3.4. JFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3.5. Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4. Plug-in Development . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.1. Target Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.2. Plug-in Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Eclipse is an open source community whose projects focus an extensible development plat-form and application frameworks for building, deploying and managing software through-out the whole lifecycle.Most people know Eclipse as a Java Integrated Development Environment (IDE) but itis much more than that. Basically there are 7 branches of activity [11]:

1. Enterprise Development

2. Embedded and Device Development

3. Rich Client Platform (RCP)

4. Rich Internet Applications

28

4.1. The OSGi Speci�cation 29

Figure 4.1.: OSGi Layering (from [Kri07])

5. Application Frameworks

6. Application Lifecycle Management (ALM)

7. Service Oriented Architecture (SOA)

For this Master Thesis mainly point 1 and 5 are used. GMF is a framework provided byEclipse facilitating the development of graphical editors, thus an application of a frame-work like mentioned in point 5. Refer to Chapter 6 to learn more about the reasonswhy GMF was chosen. The fact that Swisscom IT Services uses Eclipse as developmentplatform implies that Eclipse is used for enterprise development, thus point 1.The community is supported by several IT service providers, start-ups and universities.They use the wide range of tools, frameworks and runtimes to make their job more easily.The Eclipse foundation hosts all the Eclipse projects and is responsible for the marketing,whereas the community develops Eclipse.The next section gives an overview of the Open Services Gateway Initiative (OSGi) Spec-i�cation. Section 4.2 shows then how Eclipse may be extended in functionallity. Thischapter concludes in the explication of some important User Interface (UI)-Toolkits andhow a plug-in is being developed.

4.1. The OSGi Speci�cation

The OSGi Speci�cation [All07] forms a framework. The main task of that framework isto link all the installed bundles so that they can interact and collaborate with each other.The manifest �le of each bundle describes who it is and on whom it does depend. Thuseach bundle is self-describing. For making the link to Eclipse there is no functionaldi�erence between a bundle in the OSGi speci�cation and a plug-in in Eclipse. Both arejust a mechanism for grouping, delivering and managing content.In Eclipse the OSGi framework is called Equinox and is described in Subsection 4.2.1.


Figure 4.2.: OSGi class sharing (from [All07])

Figure 4.1 shows the layering of the OSGi framework. The following three subsectionsdescribe some of those layers.

4.1.1. Module Layer

The main content of a bundle are class �les. The question now is how the OSGi frameworkshould treat classes from di�erent bundles. There are two possible solutions:

1. The �rst is that all classes are private to a bundle, this means only local accesswithin a bundle is possible. This would be the easiest way.

2. The second possibility is to share the classes with other bundles. This makes itpossible that some bundles may provide libraries to others, which is very interestingif we think about memory usage.

The second solution is the best one, but some problems may arise. These problems in-clude version incompatibilities and questions such as how dependencies to other bundlesshould be handled and how to handle the fact, that di�erent bundles may use the sameclass but di�erent versions of that one. All these problems may be solved by the import/ export principle that was brought in by the OSGi framework. Figure 4.2 illustratesthis principle.When a bundle is exporting a package it is made available to other bundles. A bundlemay export a unique version only. If a bundle is importing a package, this implies thatthis package needs to be available from other bundles. When importing a package onecan indicate a range of accepted versions. The framework then selects the appropriateversion for each bundle.If a bundle exports a Java package that is subsequently uninstalled, the OSGi frame-work ensures, that all the importers are getting restarted. This will bind a new packageexporter.


Figure 4.3.: OSGi state diagram (from [Wal05])

4.1.2. Lifecycle Layer

A bundle is stored as a Java Archive (JAR) �le. The manifest �le that is contained inevery bundle contains information about the JAR �le. To see an example of a manifest�le of the Eclipse implementation of the OSGi Speci�cation go to Section 4.4, Figure 4.11.That manifest �le de�nes the dependencies of that bundle to other bundles or the externalenvironment, i.e. Java packages. The archive also contains an install function. Thequestion that now arises is, how the install function within that archive is accessed.This problem is solved through an Application Programming Interface (API) of the OSGiframework that is de�ned in the BundleContext. The framework provides this context whenthe framework is getting started. This context contains the methods for installing newbundles and listing existing ones.There are six states in the lifecycle of a bundle, as Figure 4.3 the state diagram of theOSGi framework, shows:

1. Install As described before, the BundleContext contains the method that is used forinstalling a bundle.

2. Resolve Before a bundle may be used it has to be resolved. This means all itsdependencies have to be resolved. This process may be cyclic, because a bundlerequires another bundle which needs itself to be resolved �rst.

3. Start A bundle gets control through the instantiation of the class that implementsthe BundleActivator interface. This class then provides the start method. The startmethod needs to return quickly, so that other bundles may be started as well.

4. Active Once the start method returns a bundle is in the active state. While being in


this state many things happen. Other bundles may be started, stopped, installed,uninstalled or updated. This is not problematic since changes never a�ect a bun-dle directly and never at a random moment. Every bundle is stopped before anydependencies are changed.

5. Stop As said previously a bundle has to be stopped before its dependencies maybe updated. It also gets stopped before uninstalling.

6. Uninstall If a bundle is uninstalled, exported packages stay available if other re-solved bundles depend on them.

4.1.3. Service Layer

In contrast to the static Java environment the OSGi Service Platform has a dynamicnature. This has the impact, that the system is not only built up but it is also possibleto remove parts of the system.In that dynamic environment it is possible that a bundle, that is useful to others becomessuddenly active, so these bundles have to adapt to the new situation and collaborate.Since an active bundle can make use of all the Java functionality this could be handledby listeners, which tell the system what to do, if a new bundle is available. But whathappens if a bundle is removed? In that case the listeners would have to be aware ofthe dynamics of the system. To solve that problem the OSGi Service Registry wasinvented. It dynamically links bundles and tracks their state and dependencies. Withthe Service Registry one may:

• Register objects with the registry.

• Search the Service Registry for matching objects.

• Receive noti�cations when services get registered and unregistered.

Registered objects are called services. The framework automatically unregisters all ser-vices from stopped bundles and sends a noti�cation to the bundles depending on the justunregistered one.Through the component model the platform operator (developer) uses little componentsto extend the system for his needs. The Service Registry is the glue that holds all thecomponents together.

4.1.4. Implementations of the OSGi Speci�cation

Equinox is one implementation of the OSGi Speci�cation. Refer to Subsection 4.2.1 for acloser look at that implementation. But Equinox is not the only implementation of thatspeci�cation. Let us consider some others:

• Enterprise Solutions Although the OSGi Speci�cation was targeted for smalldevices, also enterprise solutions as for example the Java Enterprise Edition adoptedthe OSGi technology by coupling it with Spring (see Subsection 4.3.2 to learn moreabout Spring). This adoption of the OSGi Speci�cation has been noticed by theOSGi Alliance, which founded an Enterprise Expert Group in 2006.

• Next Generation Smart Phones Nowadays games and small applications forcell phones are very common. But the technologies used today are too limited forallowing compelling systems and business applications. To be able to make the next

4.2. Extensibility of Eclipse 33

step towards smart phones, mobile phone manufacturers need a scalable, �exibleand reliable platform that has a small footprint.The OSGi Speci�cation ful�lls all of these requirements. When all manufacturersadopt that speci�cation, it is for example possible that an IT Manager is able toinstall new applications to the cell phones of his employees independent of the cellphone model they are using.

• serve@home Siemens is developing household tools for home automation. Thecentral gateway that is going to be used implements the OSGi Speci�cation, in thisway new devices can easily be added or removed. This system will make it possibleto bake the croissants when still lying in bed on Sunday morning or to verify thatall devices are turned o� before leaving the house.

• BMW ConnectedDrive is an innovative concept of the BMW group. The idea is toconnect the system �automobile� with the outside world. This system will providethe user with the information he needs, tra�c information for example. For aninternational company like BMW it is essential to have an uniform platform on thewhole world. Only that uniform platform enables BMW to integrate services fromdi�erent vendors.

4.2. Extensibility of Eclipse

A plug-in is the unit of modularity in Eclipse. To extend Eclipse one an additional plug-inis installed. A new plug-in may be installed directly with the help of the update managerof Eclipse (have a look at Appendix B.2.1 to see how this works) or by downloading itsomewhere and adding them manually to your Eclipse installation folder. The WebpageEclipse Plugin Central [12] gives a good overview of available plug-ins.The base for that dynamic plug-in installation, removal and updating was the introductionof the OSGi-based runtime.More technically a plug-in (i.e. a bundle) is a collection of classes with a manifest whichdescribes the plug-in and its relationship to the rest of the world. Figure 4.11 on page 41shows an example of such a manifest �le.

4.2.1. Equinox

Equinox [15] is the implementation of the OSGi framework speci�cation for Eclipse. Sothis is what makes the easy extensibility of Eclipse possible. More generally speakingEquinox is responsible for holding up the vision of plug-ins in Eclipse.Equinox is also the community which develops and delivers the OSGi framework forEclipse. The next two subsections give a closer insight on how that extensibility isrealized for Eclipse.

4.2.2. Extension Registry

The Extension Registry is the Eclipse counter part to the OSGi Service Registry. Sothe Extension Registry enables Eclipse to be a dynamic system, where plug-ins may beinstalled and uninstalled.

4.2. Extensibility of Eclipse 34

Figure 4.4.: Plug-in nesting (from [Wal05])

This registry holds the master list of extensions and extension points and is in that waythe glue of Eclipse.

4.2.3. Extension and Extension Point

With the extension / extension point mechanism Eclipse realizes the component tech-nology. Through this mechanism it is possible to extend Eclipse at prede�ned locationswithout having to adapt the whole system.Plug-ins are nested together through extension points. Figure 4.4 shows how extensionand extension points work together. The architecture is incremental through the fact,that every plug-in may de�ne new extension points. In addition to that, multiple plug-insmay be hooked to one extension point.The extension points of each plug-in are described in the manifest �le. This enables lazyloading, i.e. a plug-in is only loaded into memory if its functionality is needed. Thedependencies at start up are read out of the manifest. This implies that a plug-in needsalmost no resources at the beginning, which enables loading almost unlimited plug-ins.Thanks to the Eclipse Registry plug-ins may be unloaded as well.The basis of the plug-in architecture is build by two plug-ins the org.eclipse.core.runtimeand the org.eclipse.osgi. Those two plug-ins are not based on any extension point butprovide extension points themselves.

4.3. UI-Toolkits 35

Figure 4.5.: Manifest Editor, Overview page

4.3. UI-Toolkits

User interfaces are used for enabling the communication between humans and the system.Eclipse provides an easy way to develop such graphical user interfaces. This sectiondescribes the main UI toolkits, compares them with other possibilities and lists someadvantages and drawbacks.

4.3.1. Abstract Window Toolkit (AWT)

The Abstract Window Toolkit (AWT) was the �rst UI toolkit for Java. It was providedby Sun and was delivered with Java 1.0. With AWT every UI component has a peer.A peer is a lightweight interface (i.e. little abstraction) around the native user interfacewidgets. Such a peer is provided for the set of components that are available on all theoperating systems supported by Java. This is why only a small range of widgets likebuttons, labels and lists are provided. Things like trees, tables and styled text availableon some operating systems are missing.

4.3. UI-Toolkits 36

Figure 4.6.: Manifest Editor, Dependencies page

With Java 1.1 also AWT was improved and it was possible to build lightweight customproperties.

4.3.2. Swing

Swing was released in March 1998 as part of the Java Foudation Classes (JFC) and wasdeveloped separated to the Java Devlopment Kit (JDK).Even though Swing is build on top of the core libraries of AWT, it does not reuse any ofits components. Because there is no platform speci�c code in Swing, its applications canbe deployed on any platform Java supports.A big advantage of Swing in comparison with AWT is that with Swing every widget isemulated in Java1. This provides the same look-and-feel on every platform.Swing has the reputation to perform poorly. With the release 1.4 of Java its performancewas improved however. Nowadays most performance problems have its source in wrongusage.

4.3.3. Standard Widget Toolkit (SWT)

The Standard Widget Toolkit (SWT) [28] is a low level graphics library for the Java plat-form which provides standard UI controls like lists, menus, fonts, colors, etc. Despitethe fact, that it is targeted for the Java platform it is not part of the Java StandardEdition nor the Java Enterprise Edition. It was originally developed by IBM and is nowmaintained by Eclipse. It builds the base for the entire Eclipse UI.SWT combined the best parts of AWT and Swing. This is, it builds a wrapper aroundthe native widgets. Like this it uses native widgets whenever they are available on theplatform like AWT and emulates them like Swing if the widget is not provided by the

1With the Java2D API, which is also part of the JFC

4.3. UI-Toolkits 37

Figure 4.7.: Manifest Editor, Runtime page

platform. Thus, a public API for all platforms is provided. Like this it takes the advan-tages of better performing native widgets and provides nevertheless platform portability.But like everything, also SWT has its drawback. Write once, runs everywhere is not truefor SWT. For every platform a speci�c implementation of the SWT library has to byprovided with the client.

4.3.4. JFace

JFace provides object oriented wrappers around the SWT widgets. It provides Label-, List-and TreeVierwers that enable the user to directly use the domain model objects instead ofhaving to decompose them into its basic strings, numbers and images. JFace is build ontop of the SWT library without hiding it.The combination of JFace and SWT is an alternative to Swing. The Java community issplit up into those using JFace/SWT and the others preferring Swing. The advantageof JFace/SWT is that it is closer to the native implementation, which implies a betterperformance. Swing however provides better platform portability, because it has a higherlevel of abstraction, which enables uniform behavior on all platforms. The interoperabilitybetween SWT and Swing, which was quite poor in the past, was improved with Eclipse3.0.

4.4. Plug-in Development 38

Figure 4.8.: Manifest Editor, Extensions page

4.3.5. Workbench

The previous subsection shows that JFace adds structure to SWT. The UI workbenchon its part adds presentation and coordination to JFace. The workbench provides viewsand editors with a certain layout to the user.Through the contribution-based extensibility additional UI elements can be addedeasily. As everything is plug-in in Eclipse, so is the workbench and through extensionpoints the UI can be adapted to the users needs.The workbench consists of three components: perspectives, views and editors. The per-spective serves as a container for views and editors.

4.4. Plug-in Development

Plug-ins and the development of plug-ins get continuously more complicated. In additionsystems are becoming bigger and more distributed over time. Like this it is possible thatthe same plug-in has to run on di�erent environments. It is also very probable, thatthe Eclipse installation of the developer of the plug-in is not the same as the Eclipseinstallation of the end user of the plug-in. If we wrap it up, there are two importantthings when developing a plug-in:

1. The plug-in needs to be portable.

2. We need to have the ability to focus on the environment where the plug-in is goingto be used.

To simplify this task, there is the need for tools providing help for plug-in development.Eclipse provides tools for both of them. Since Eclipse is based on Java it runs on everymachine providing a Java Virtual Machine, this faces the problem of portability.The second point is solved by providing the developer with a development platform that ishighly customizable. Among other things it is possible to de�ne the target environment,which is equal to the future execution environment. This enables the developer to con-


Figure 4.9.: Manifest Editor, Extension Points page

centrate on the application itself and to design the plug-in exactly for that environmentin which it is going to be used. The next subsection explains how this so called targetplatform is set up.

4.4.1. Target Platform

When developing a new application for Eclipse, it is a best practice to develop thatapplication against a target. The target is a set of plug-ins that form the core of thefuture application. With the target platform one ignores the fact that the applicationfor Eclipse is elaborated with the help of Eclipse, i.e. one develops towards the targetand not with the development environment. This allows to handle the plug-ins for thedevelopment environment independently of those in the target environment. Imagine forexample, that the developer is using Java 6.0 but the plug-in he is currently designing hasto run with Java 4.0. By de�ning the Java Runtime Environment (JRE) in the targetplatform as Java 4.0 this problem is solved. Now we know the bene�ts of developingtowards a target platform, let us see how this is done.First of all, to de�ne a target platform you need to install a second independent Eclipseplatform. One is used as the development environment the other one forms the targetplatform. You can use the same Software Development Kit (SDK) as you are usingfor development or choose another one meeting better the requirements of the futureapplication.The target platform is de�ned in the preferences of the Eclipse platform the developer isusing for the plug-in development. Go toWindow -> Preferences... and type �target�into the �lter �eld. Choose the Target Platform menu item and browse for the locationof your target Eclipse. On that same page you may also de�ne which plug-ins should beincluded within the target platform. This is done by checking or unchecking the speci�cplug-in in the Plug-in tab for instance.


Figure 4.10.: Manifest Editor, Build page

4.4.2. Plug-in Structure

Every plug-in has a META-INF/MANIFEST.MF �le and may have a plugin.xml �le and/or aJava class that describes the plug-in programmatically.Every plug-in has a plug-in ID (e.g. com.swisscom.oms.plugins.game) and a plug-in version.The plug-in name corresponds by convention with the plug-in ID.The manifest �le and the plugin.xml de�ne how that plug-in relates to all the others ina system. Thereby the manifest describes the runtime aspects, whereas the plugin.xmldescribes the extension aspects.When double-clicking the manifest or the plugin.xml �le, the manifest editor opens. Thiseditor provides the following pages with the listed content:

• The Overview page shows a summary of the plug-in manifest, describing generalinformation such as plug-in ID, version, name, etc. (Figure 4.5, page 35). Thisinformation may as well be edited in the source directly, i.e. the MANIFEST.MF page(Figure 4.11).

• In the Dependencies page you can see the reliance of that plug-in to the otherplug-ins in the system (Figure 4.6, page 36). This information corresponds with theRequire-Bundle paragraph of the META-INF/MANIFEST.MF �le. Any change a�ected to


Figure 4.11.: Manifest Editor, MANIFEST.MF page

that page will automatically be re�ected in the Java build path. The reverse is nottrue, so it is the better idea to change this page than the Java build path directly.

• The Runtime page (Figure 4.7, page 37) of the manifest editor contains all the li-braries that are delivered with the plug-in and used by that plug-in during executiontime. It corresponds to the Export Package in the manifest �le.

• What is edited in the Extensions page (Figure 4.8, page 38), corresponds to the<extension point="..."> of the plugin.xml �le (Figure 4.12). This page displays how thisplug-in augments the functionality that is already provided by an other plug-in inthe system .

• The Extension Points facilitates the creation of new extension points. With thehelp of those extension points, other plug-ins have the possibility to extend thefunctionality of this plug-in (Figure 4.9).

• Finally the Build page (Figure 4.10) de�nes which sources should be included forbuilding the plug-in. This information is also represented in build.properties page(Figure 4.13).


Figure 4.12.: Manifest Editor, plugin.xml page

Figure 4.13.: Manifest Editor, build.properties page

5Graphical Modeling Framework

(GMF)

5.1. Eclipse Modeling Framework (EMF) . . . . . . . . . . . . . . . 44

5.2. Graphical Editing Framework (GEF) . . . . . . . . . . . . . . . 45

5.3. Semantic vs. Notation . . . . . . . . . . . . . . . . . . . . . . . 46

5.4. Model View Controller . . . . . . . . . . . . . . . . . . . . . . . 46

5.5. Con�guration Files . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.5.1. Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.5.2. Graphical De�nition . . . . . . . . . . . . . . . . . . . . . . . . 48

5.5.3. Tooling De�nition . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.6. Mapping and Generator Models . . . . . . . . . . . . . . . . . . 48

5.7. Extensibility and Customization . . . . . . . . . . . . . . . . . 49

The aim of this chapter is to explain what the Graphical Modeling Framework is and howit is composed. Chapter 6 then describes the requirements that had to be ful�lled by thetechnology and why GMF was chosen.As the name anticipates GMF is a framework for designing graphical editors easily. It isbased on the Eclipse Modeling Framework (EMF) and the Graphical Editing Framework(GEF). These two frameworks will be explained in more detail in Sections 5.1 and 5.2.The main idea is that GMF provides a set of three con�guration �les (domain model,graphical de�nition, tooling de�nition on Figure 5.4, page 47 in green) with the help ofthose most of the functionality of the editor is generated automatically. This includesprinting, drag-and-drop, save to various image formats and many more. What comes outis a commercial plug-in with all its advantages.The framework allows the user to concentrate on the main business goal of the editorwithout bothering about fundamental questions common to all editors.The next sections will bring more light into the di�erent parts of GMF. Appendix Aprovides an example, where a mind mapping tool is elaborated, to clarify the thingsdescribed in this chapter.

43

5.1. Eclipse Modeling Framework (EMF) 44

Figure 5.1.: Ecore Editor provided with EMF

5.1. Eclipse Modeling Framework (EMF)

EMF [7] is a modeling and code generating facility. It helps to build tools and applica-tions based on a structured data model.The Eclipse Modeling Framework uses its own meta data called ecore model. One possi-bility to get that ecore model is to draw it from scratch using the editor that is providedwith the framework. Figure 5.1 shows what this editor looks like. But this is not the onlypossibility to get the ecore model. It can also be imported from other model de�nitions.These model de�nitions include annotated Java code, an XML document or UML models(Rational Rose or UML2). That ecore model builds the core, the so called domain modelthat has to be represented. Also for the graphical editor that is elaborated with the helpof GMF this model will build the core for representing that domain graphically.For generating the Java code a generator model is needed. Appendix A.2 explains indetail how you can get that generator model. Four our purposes here it is enough toknow that such a generator model is needed. From that so called Domain Gen Model(the blue rectangle with number 2 in Figure 5.4) the following may be generated:

• Model Code: The model code is representing the ecore model programmatically.It will be placed in the src folder of the project where the Domain Gen Modelcan be found.In our example (Appendix A) the project is org.swisscom.mindmap on Figure 5.4this is represented with the core plug-in. The four packages that are generatedfor representing the code base are visible in the example from the Appendix inFigure A.10.

• Edit Code: The edit code enables that the EClasses that can be found in thedomain model may be viewed and edited, i.e. in our mindmap example that thetopic may be set, that a topic may be linked with a subtopic, etc.The code that gets generated is situated in a new plug-in where the post�x .editis added to the code base plug-in name. (Edit plug-in on Figure 5.4).

• Editor Code: The editor code creates an ordinary EMF editor where the domainelements de�ned in the ecore model may be edited in a tree structure.

5.2. Graphical Editing Framework (GEF) 45

Figure 5.2.: Model View Controller Architecture of GEF (from [4])

Also this code is placed in a plug-in apart. The editor code plug-in gets the post�x.editor on Figure 5.4 this plug-in is called editor plug-in.

• Test Code: The test code is by far not complete. It gives rather an overview ofhow the JUnit test can be done.The plug-in that is generated for the testing gets the post�x .tests and is visualizedas test plug-in in Figure 5.4.

All the plug-ins and packages that may be generated are visible in the package explorerrepresenting our mindmap example from the Appendix in Figure A.10.The Eclipse Modeling Framework supports automatic validation for model constraints.This is for example an attribute that is set to be unique. Within the Graphical ModelingFramework EMF is responsible for the generation of the domain model and its accordingclasses and builds as such the core of the graphical editor.

5.2. Graphical Editing Framework (GEF)

GEF [8] is the framework representing the graphical component in the Graphical ModelingFramework. The Graphical Editing Framework requires the org.eclipse.draw2d plug-in.This plug-in provides the layout and rendering toolkit for the graphics.The framework follows the Model View Controller (MVC) architecture and is applicationneutral. Figure 5.2 shows that architecture with reference to how it is represented inJava. Section 5.4 explains that architecture pattern that is also adopted by GMF.

5.3. Semantic vs. Notation 46

Figure 5.3.: Model View Controller Architecture of GMF (from [4])

5.3. Semantic vs. Notation

For a graphical editor to be useful the semantic data needs to be separated from thenotational data. Implicitly both aspects are always contained in a graphical editor. Butlet us explain what exactly is meant with those two terms.The notation is the set of shapes and connections that are used on the canvas to representthe domain graphically. The semantic is the meaning of what is being edited with theeditor. From the graphical point of view notation and semantic is the same thing butbehind the scenes the di�erence is quite important.So it is possible to represent semantic data in di�erent ways (di�erent notation) but themeaning (semantic) of all representations is exactly the same. Or in some cases the sameinformation has to be displayed in di�erent ways with respect to the context. This is thereason why the semantic data should not contain any information on how it has to berepresented.

5.4. Model View Controller

GMF adapts the Model View Controller (MVC) architecture pattern. It is used forseparating the data (model) from the user interface (view). This has several advantages:One may for example change the implementation of the data or the underlying databasewithout having to change the interface. Of course the same is true for the inverse case,where the user interface is changed. Thereby important is that the user interface may bechanged without e�ect for the model.The MVC pattern contains three layers, the presentation (UI), the domain logic and thedata access, more precisely these are:

Model The model is the domain speci�c representation. In some cases it may also knowwhere and how the data is stored.

5.5. Con�guration Files 47

Figure 5.4.: Relations between Models and Plug-ins in GMF

View The view is the suitable view for interacting with the data, often represented as auser interface.

Controller The controller is the instance between the model and the view. It processesand responds to events and invokes changes in the model if necessary.

Figure 5.3 shows the architecture of the MVC pattern for GMF.On the left you can see the model which is represented by the di�erent views which aregenerated through the factories that may be found in the game.diagram.view.factories pack-age and the commands that are situated in game.diagram.edit.commands.The controller is in the middle of the Figure. In GMF the controller is mainly representedby the EditParts that exist for every element, which are all implementing the IGraphicalEd-itPart interface. The editpolicies de�ne the default appearance of the �gures at creationtime. It is visible in the �gure that the controller is the center and processes all events(commands and requests).The view is represented with the �gures. There are several helpers to render a �gure aslayouts, handlers and routers. The layouts are used as the name says for de�ning how thedi�erent elements in the �gure are laid out. The handlers are in �rst place responsiblefor handling the noti�cations, i.e. the name of an attribute or the placement of the �gurechanged. Then they also de�ne when a �gure may be moved, resized, etc. and when not.Finally the routers are used for placing the connections and �gures on the canvas withoutoverlaps.

5.5. Con�guration Files

Earlier in this chapter it was said that the editor is de�ned mainly through three con-�guration �les. Let us now have a closer look at these. In Figure 5.4 you can see those

5.6. Mapping and Generator Models 48

three �les graphically in green. From this �gure you can also see how these con�guration�les and the ones generated from those relate to each other.

5.5.1. Domain Model

The domain model has the number 1 in Figure 5.4. The domain model is the startingpoint for the editor and is supported by EMF. Here all the domain objects and theirrelations are modeled. The �le extension of that model is *.ecore. Based on that *.ecore�le the *.genmodel �le will be generated. In Figure 5.4 this is visualized with the arrowthat goes from the green rectangle to the blue one which has the number 2. With thehelp of the Domain Gen Model the four plug-ins shown underneath can then be generated.Section 5.1 explains these plug-ins.Figure A.5 shows the ecore model of the mindmap example that can be found in AppendixA, Figure 7.3 on page 64 illustrates the domain model of the Graphical Aspect ModelEditor.

5.5.2. Graphical De�nition

In the graphical de�nition it is de�ned which �gures should be used to represent whichEclass in the domain model. In Figure 5.4 you can �nd the model on top of the �gurewith the number 3a, the arrow towards the ecore model shows the dependency betweenthose two models. There is no need for de�ning one �gure per node in the domain model.It is possible that nodes in the domain model do not appear in the graph at all.The �le extension of the graphical de�nition is *.gmfgraph. There is a wizard, which makesthe creation of the graphical de�nition easy. But changes can also be done directly in the�le, with the help of the EMF editor.Figure A.6 in the Appendix shows the graphical de�nition of the mindmap example beforeand Figure A.7 after customization. Appendix A describes the creation and customizationof that con�guration �le.

5.5.3. Tooling De�nition

The tooling de�nition has the number 3b in Figure 5.4. This model de�nes the toolsavailable in the editors palette. It is trivial that only tools for de�ned �gures in thegraphical de�nition may be de�ned. Also here the arrow towards the ecore model showsthe relation between those �les.The extension of the tooling de�nition is *.gmftool. As for the graphical de�nition a wizardis available for the creation of the tooling de�nition and again changes can be done directlyin the �le (with the EMF editor). In the Appendix Figure A.8 shows the tooling de�nition�le of the mindmap example.

5.6. Mapping and Generator Models

With the three con�guration �les we set up our editor. However, code cannot be generatedfrom multiple con�guration �les. We need a so called generator model to be able to

5.7. Extensibility and Customization 49

generate Java code. In Figure 5.4 the two generator models of GMF are colored in blue.In Subsection 5.5.1 we saw already such a generator model. Its extension is *.genmodeland it is used for generating the core, the edit, the editor and the test plug-in. The sourceof that generator model is one �le, i.e. the ecore model.For the generator model of the graphical editor this is more complicated. It depends noton a single con�guration �le, but on three. These are the domain model, the graphicaland the tooling de�nition �les. This three �les have to be combined in order to let thegraphical editor know which �gure represents which element in the domain model andwith which tool it may be created.This is where the mapping model comes up (number 4 on Figure 5.4). This modeltells GMF how all of these three con�guration �les �t together. The extension of themapping model is *.gmfmap. In the Appendix Figure A.9 shows the mapping model forthe mindmap example. Based on that �le the code generator model can now be created.The �le extension of the generator model is *.gmfgen. In Figure 5.4 this model has thenumber 5. This �le then generates the Java code for the graphical editor.

5.7. Extensibility and Customization

Through the principle of plug-in extension points that are naturally for Eclipse productsthe editors that are created using the Graphical Modeling Framework are highly extensi-ble. The extension / extension point principle is explained in more detail in Chapter 4,i.e. Section 4.2. In addition to the extension points there are a lot of features that can beincluded or inherited easily. There are also hooks available for including customizations.Chapter 8 describes among other implementation details the customizations that wereincluded for the Graphical Aspect Model Editor. This chapter is very technical howeverand can be skipped at �rst reading. Here it has to be said that customizations can getannoying quite quickly, because it implies digging in the generated code. What makesthis task even more di�cult is that not much documentation is available. Find in theAppendix A the mindmap example that helps for a better understanding of GMF.

6Technological Study

6.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.1.1. Fundamental Requirements . . . . . . . . . . . . . . . . . . . . 51

6.1.2. More Sophisticated Requirements . . . . . . . . . . . . . . . . . 51

6.2. Requirements for the Figure Representation . . . . . . . . . . 52

6.2.1. BPMN Standard . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2.2. Representation of Steps . . . . . . . . . . . . . . . . . . . . . . 52

6.2.3. Representation of Predecessor Relations . . . . . . . . . . . . . 54

6.3. Possible Technologies . . . . . . . . . . . . . . . . . . . . . . . . 56

6.3.1. Graphical Modeling Framework . . . . . . . . . . . . . . . . . . 57

6.3.2. Other Possible Technologies . . . . . . . . . . . . . . . . . . . . 57

6.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.4.1. Solutions for Fundamental Requirements . . . . . . . . . . . . . 58

6.4.2. Solutions for Sophisticated Requirements . . . . . . . . . . . . 58

6.4.3. Final Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Before the implementation of GAME can be started, a technological study has to becarried out. This chapter presents the result of that study which is the �rst part of thedevelopment phase of this Master Thesis. Before we point out the results of the study,the requirements are made clearer.

6.1. Requirements

This requirements are lied out for a solution within the scope of Eclipse. Technologiesoutside of Eclipse are only going to be investigated in the worst-case-scenario, where noEclipse framework is suitable.Still also the technologies outside Eclipse have to ful�ll these requirements, but it maybe that some of therequirements are targeted to an Eclipse framework and can thereforenot be met by other technologies.The requirements, which this section describes, are divided into fundamental and moresophisticated ones.

50

6.1. Requirements 51

6.1.1. Fundamental Requirements

The requirements described in this section decide whether a technology may be chosen ornot. In other words if a technology does not ful�ll one of these requirements, that tech-nology is not suitable for the Graphical Aspect Model Editor. The following requirementswere identi�ed as fundamental:

• Layout and data stored separatelyThis point is important for the daily business. It is necessary to know if only thelayout or the content of a diagram has changed.

• Stable applicationIn order to let developers use the editor it needs to be stable.

• Changes in the generated code stay persistentIf the used technology generates code automatically and the generated code for thegraphical editor needs to be customized, these customizations need to stay persistenteven if the code is regenerated.

• Output of the editor reusableThe data produced by the editor needs to be easily reusable for other applications.

6.1.2. More Sophisticated Requirements

The idea is to keep the possibility to future extensions open, this is the reason why thesemore sophisticated points were investigated:

• Properties of model elements change the shapeThis is used to show the properties of the �gure also visually, for example a dashedborder line for optional Steps.

• Additional Tabs, Views, Wizards, etc.With these features of an ordinary plug-in, the editor is highly customizable.

• Read data from OMS artifactsSome data for the �gures in the editor need to be fetched from an other plug-inthat is part of the existing system.

• Standard tools removableGMF provides standard helper tools which enable the user to quickly add an elementor draw a connection. Since we do not know yet whether these tools are helpful tous they need to be removable. We have the presentiment that they overwhelm thegraphical editor.

• Multiple editors for the same domain modelIn the future the editor will be extended. There needs to be the possibility to addeditors to the existing one. The idea here is that all editors share the same domainmodel.

• Image generation It has to be easily possible to generate an ordinary image �le(SVG, PNG, GIF, etc.) from the model that is drawn with the graphical editor.This is needed for documentation, which will be displayed through a browser.

6.2. Requirements for the Figure Representation 52

BPMN OMS / CLOM CommentsActivity Step Generic term for a process

step.Task Activity (more precisely:

the function of an activity)Atomic process step.

Sub�ow Sub�ow Composed process step.Sequence �ow Predecessor Relation Connector between process

steps. The semantic mean-ing cannot be compared!

Table 6.1.: Mapping between BPMN and OMS terms

6.2. Requirements for the Figure Representation

The graphical representation of the �gures for the graphical editor should follow theBPMN standard. This section explains how this is done and how the �gures in GAMEare going to look like.

6.2.1. BPMN Standard

The OMS process engine (CLOM) di�ers considerably from conventional process en-gines. The major di�erence is that with the CLOM processes are described declaratively,whereas traditional process engines describe them procedurally.BPMN is a standard notation that was elaborated for describing processes imperatively(see Section 2.3). This leads to the fact, that this notation is not suitable for describingdeclarative processes in principle. Nevertheless, BPMN de�nes a lot of symbols that alsocan be used for declarative description. But we have to be careful and think about thefact, that the semantic behind that description may not be the same.This confronts Swisscom IT Services with the dilemma of either to use already knownBPMN symbols by sometimes violating the semantic rules or to de�ne a new notation.The decision that was made is to use the BPMN symbols whenever possible and if nec-essary to adapt them. The next few subsections explain the usage of BPMN symbolswithin GAME in more detail.Table 6.1 shows the mapping between BPMN and OMS terminology.

6.2.2. Representation of Steps

This section describes all the di�erent characteristics and shapes of a Step by staying asBPMN conform as possible. The �gures presented at this point are the vision of how theseshapes will look like. In Chapter 9 the e�ectively used �gures are shown (see Figure 9.8on page 106). The Predecessor Relations between those Steps are the topic of the nextSubsection.

Activity A Step that executes an Activity (Step.implementation instanceof Activity) is repre-sented by Figure 6.1. On the left the standard template is shown, on the right a speci�cexample is given. The labeling of this �gure is as follows:


Figure 6.1.: The �gure representing an Activity in GAME

Figure 6.2.: The �gure representing a Flow in GAME

• Written in bold, represents the name of the Step. (Step.name)

• The name of the Activity that is to be executed (Activity.name)

• The function of the Activity that has to be executed. (Activity.function.name, Activ-ity.function.version)

Sub�ow A Step which executes a Subflow (Step.implementation instanceof Flow) di�ers in anadditional add-symbol from the �gure of an Activity. Also the labels are slightly di�erentas can be seen in Figure 6.2:

• Written in bold, represents the name of the Step. (Step.name)

• The name and the version of the Flow to be executed. (Flow.name, Flow.version)

Con�guration of the Steps

The con�guration of the Steps is shown on the diagram with additional symbols. Theseare the plus, pause and rewind symbol. This is used for documenting the behavior of theStep. The combination of several symbols is possible.

Single Instance Step In the default case there are no symbols added. This representsa single instance Step. Figure 6.3 shows such a default Step. On the left you can see aStep with Activity implementation and on the right implemented as a Flow. In the datamodel this property is represented by Step.minInstances == Step.maxInstances == 1.

Conditional Step If a Step is executed only under certain circumstances this is shownwith the help of a condition. That condition is evaluated dynamically by a rule. Fig-ure 6.4 shows how this will be represented graphically.A conditional Step is executed whenever a rule recognizes that the instantiationCondition isful�lled.In the data model a conditional Step has the property Step.minInstances == 0. The instanti-ationCondition on the �gure represents Step.instantiationCondition, which may not be empty.


Figure 6.3.: The default case: Single Instance Step

Figure 6.4.: The �gure representing a Conditional Step

Multi Instance Step For a multi instance Step several instances may be launched. Forexample a Step may be carried out for every phone number.This Step is a special case of the conditional Step. The instantiationCondition for the casementioned above would be [for each PhoneNumber].How such a Step is displayed is shown in Figure 6.5. 0 to n instances of a multi in-stance Step will be executed. In the data model this is represented with the propertyStep.instantiationCondition, which cannot be null.

Compensation Step If a Step is only used for compensation this is shown by the rewindsymbol. A compensation Step is a Step that only gets executed if the process is canceled(rollback). Figure 6.6 shows the representation of that �gure.

6.2.3. Representation of Predecessor Relations

Thanks to the previous subsection we know how Steps are going to be represented, whatremains is the representation of the Predecessor Relation.The purpose of a Predecessor Relation is to tell when a Step may be started. A PredecessorRelation possesses four properties:

1. Predecessor: The Step which has to ful�ll the condition so that the PredecessorRelation is valid.

2. Successor: The Step that may be executed as soon as all its Predecessor Relationsare satis�ed.

3. Operation: Each Predecessor Relation is associated with an operation. Only Prede-cessor Relations for the operation treated are signi�cant. All the others are ignored.

4. Condition: The condition de�nes a requirement that needs to be ful�lled by thepredecessor for the Predecessor Relation to be satis�ed.

In addition to the four properties the following holds:

• There may be 0 to n Predecessor Relations de�ned between two given Steps.

• A Step may have 0 to n Predecessor Relations to other Steps, i.e. a Step may have 0to n predecessors.


Figure 6.5.: Figure representing the Multi Instance Step

Figure 6.6.: Figure representing the Compensation Step

• A Step must not have a Predecessor Relation to itself.

Graphical Representation The Predecessor Relation will be represented with arrows.The arrowhead is showing on the successor. With that arrow two of the four propertiesof a Predecessor Relation are de�ned, i.e the predecessor and the successor. What remains isthe operation for which the condition has to be ful�lled and the condition itself. These twoproperties are set in brackets on the arrow. Figure 6.7 shows these two properties, therebythe operation for these arrows are �ful�ll� and �cancel� respectively and the condition iscomplete in both cases.The most frequent Predecessor Relation is of the form shown in Figure 6.7. This is in theoperation �ful�ll�, i.e. in the forward motion, the predecessor must have completed all itswork before the successor may begin. In the case of a rollback, i.e. operation �cancel� thesuccessor needs to have rolled back all its e�ects before the predecessor may begin withhis rollback. This speci�cation is used in 98% of the cases. This is why we decided tosimplify that representation to one single arrow, and to talk about a Default PredecessorRelation. Figure 6.8 shows that simpli�ed representation of the Default Predecessor Relation.Table 6.2 shows the conditions that are supported in the not default cases. The operationsthat are supported are:

• Ful�ll This PredecessorRelation has to be taken into account if the process is inforward motion.

• Cancel If the operation is cancel, this PredecessorRelation has to be taken intoaccount in backward motion.

• Abort The abort operation de�nes PredecessorRelations that have to be taken intoconsideration if the process is aborted.

• Nop This PredecessorRelation has to be taken into account if no of the other opera-tion holds.

6.3. Possible Technologies 56

Figure 6.7.: Figure representing the Default Predecessor without simpli�cation

Condition Displayed in Diagram CommentsComplete Default predecessor, is dis-

played explicitlyCompleteOrFailed [completeOrFailed]CompleteOrNonRelevantFailure

[completeOrNonRelevantFailure]

Started [started]Failed [failed]Error [error]Exception [exception]HasResult result name has to be typed

in as a Stringcondition with parameter

Table 6.2.: Supported predecessor relation conditions

6.3. Possible Technologies

This section gives an overview on possible technologies and explains why an �Eclipsesolution� is favored.Swisscom IT Services uses Eclipse as development platform and many plug-ins for custompurposes have already been implemented. This is why the preferred technology for theelaboration of GAME is GMF, a framework which is part of Eclipse. The next subsectionwill give a quick overview of GMF. Refer to Chapter 4 to get an overview of the EclipseRCP and to Chapter 5 for a detailed description of GMF. Subsection 6.3.2 enumerateswhich other technologies we could think of, if GMF does not meet the requirements.

6.3. Possible Technologies 57

Figure 6.8.: Figure representing the Default Predecessor

6.3.1. Graphical Modeling Framework

GMF is a framework that facilitates the development of graphical editors. It is based onEMF and GEF. Its main principle is that with the help of only three con�guration �leswe are able to de�ne a graphical editor. Once the developer has de�ned those three �lesmost of the functionality (i.e. drag-and-drop, save to image, zoom, etc.) is generatedautomatically. The result are most commonly four commercial plug-ins.In addition to the facility of easily creating graphical editors, GMF also provides hooksfor customization.

6.3.2. Other Possible Technologies

Prior to the technological study, GMF seems already to be the best candidate for thedevelopment of GAME. The reason for this is that Swisscom IT Services uses alreadyEclipse as development platform. If GAME is elaborated with an Eclipse framework itcan easily be integrated with the existing platform. This integration is certainly moredi�cult with a technology not integrated into Eclipse itself.Nevertheless other possible technologies had to be found in cases, where GMF is notappropriate. These technologies will be explored in the worst-case-scenario:

• EMF and GEF used directly

• ILOG JViews [21]

• Microsoft Visio

6.4. Conclusion 58

6.4. Conclusion

Because an �Eclipse solution� is favored the �rst technology that was investigated wasGMF. The �rst touch with this technology is not easy since it o�ers many possibilities.After some trials however, it proved to be quite straight forward to handle.Surprisingly further investigations showed that almost all requirements could be achievedquite easily. Find in the next subsection how the requirements can be met using GMF.

6.4.1. Solutions for Fundamental Requirements

The �rst investigations that were carried out, showed that most of the requirements set upin Section 6.1 are just some small changes in one of the three con�guration �les (domainmodel, graphical de�nition, tool de�nition visible in green on Figure 5.4 on page 47) ofthe Graphical Modeling Framework. The list below explains shortly the solutions for eachrequirement:

• Layout and data stored separatelyThe layout and the data of the diagram are by default stored in distinct �les.

• Stable applicationDuring the test phase the application was perceived as stable.

• Changes in generated code stay persistentBy setting the annotation @generated NOT customized code stays persistent evenwhen the code is being regenerated. It is obvious that the �le cannot be deletedand regenerated, because with deletion also the annotations get lost.Drawback here: if the Diagram Editor Gen Model (*.gmfgen) is customized,which gets generated as well, not all the changes stay persistent. But this is aknown bug and there is hope that it will be �xed with later releases of GMF. Forour needs we will over go this problem by not customizing that �le.

• Output of the editor reusableThe output of an editor developed with GMF is an XML-based �le, the �le sharingdocument nowadays. So any application that knows the underlying structure ofthat �le will be able to interpret it. Section 7.6 gives a detailed overview of theoutput �le.

6.4.2. Solutions for Sophisticated Requirements

The more sophisticated requirements are not all that easy to ful�ll. Find in the followinglist the solutions that were found:

• Properties of model elements change the shapeThis requirement was not that easy to achieve, customizing of the generated Javacode is needed.In order to change the shape of a �gure depending on the values set for its propertiestwo methods in the XXXEditPart class of the �gure that should show the changes, needto be overridden. The �rst method is the ShapeNodeEditPart#handleNotificationEventmethod, that treats the noti�cation if the according property changed. Then theFigure#paint method needs to be overridden to paint the �gure with respect to theproperties set. Section 8.2 explains in more detail how this is done.

6.4. Conclusion 59

• Additional Tabs, Views, Wizards, etc.What is generated with GMF is a plug-in, this implies that it takes advantage ofthe extension / extension point principle of plug-ins. In addition to that, there arehooks in the generated code of GMF that allows customization, for example theusage of a custom dialog. Refer to Section 8.3 for the explanation how the customdialog was added.

• Read data from OMS artifactsThis point is strongly related with the previous one. If it is possible to hook cus-tomized plug-ins or in our case a dialog within the generated plug-in, then all thedata provided by the system (i.e. by other plug-ins) may be read. The section 8.3explains how the OMS artifacts are included in GAME.

• Standard tools removableGMF provides by default a pop-up bar to add new �gures and a connection handlerto add connections. They may easily be removed with one additional line of code.Section 8.5 shows how this can be done.

• Multiple editors for the same domain modelThis is the most tricky requirement to meet and up to the deadline of the technicalstudy no working solution could be found. A lot of references telling that it workswere found on the Internet, but the way how to exactly achieve this could not befound. The links found while researching nevertheless show, that this requirementis common and maybe with later releases of GMF it will be easier to achieve.In addition to that it has to be said, that through the output �le that is easilyportable one could also imagine to elaborate a second editor that takes the outputXML of the �rst editor as input.

• Image generationEvery model that is depicted with a graphical editor based on GMF may be savedas several image �les, as for example *.svg, *.png, *.jpg. Thus this is one of thefunctionalities that is automatically provided by the framework.

6.4.3. Final Decision

Based on the technical study that was accomplished for this Master Thesis SwisscomIT Services decided to stay with their �rst intension and elaborate the Graphical AspectModel Editor (GAME) with the Graphical Modeling Framework.As we could see in the last section GMF ful�lls all of the fundamental requirements andmost of the more sophisticated ones can be achieved in some way. Since GMF is quite anew technology that is still evolving it is quite possible that some of the requirements aregetting easier to ful�ll in the future. In addition to that there is no other technology insight, where we can get the same modularity and which �ts as well in the already existingdevelopment platform at Swisscom IT Services.The usage of EMF and GEF without using GMF is not necessary since the new technologyGMF proved to be stable.Another point in favor of the Graphical Modeling Framework is, that the GMF communityis quite active and the newsgroup for GMF provided by Eclipse [23] was helpful manytimes. A new release of GMF, this is 2.1, is planned for June 2008.

7Architecture

7.1. GAME and OMS . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.1.1. Architecture before GAME . . . . . . . . . . . . . . . . . . . . 60

7.1.2. Integration of GAME . . . . . . . . . . . . . . . . . . . . . . . 61

7.1.3. Interfaces for GAME Integration . . . . . . . . . . . . . . . . . 63

7.2. Base of the Editor . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.3. Core Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.4. Edit and Editor Plug-ins . . . . . . . . . . . . . . . . . . . . . . 66

7.5. Diagram Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.5.1. src Source Folder . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.5.2. customsrc Source Folder . . . . . . . . . . . . . . . . . . . . . . 69

7.6. Output of GAME . . . . . . . . . . . . . . . . . . . . . . . . . . 70

This chapter describes the architecture and the output of the Graphical Aspect ModelEditor. It also shows how it was linked with existing OMS components and how it wasintegrated.

7.1. GAME and OMS

Since GAME will be added to the existing OMS architecture this chapter describes howthis is done. This work was not done by the author however, since the integration isout of the scope of the Master Thesis elaborated by the author. Before we explain theintegration as such, we will present the existing architecture in the next subsection.

7.1.1. Architecture before GAME

Figure 7.1 shows a simpli�ed architecture of OMS before GAME. Let us have a look onhow processes are developed before.The entry point for the developer is the Flow Descriptor Editor. With that editor thedeveloper kind of sets up the �recipe� for the Flow he is going to de�ne. With the helpof the Flow Descriptor Editor, he tells the system that he needs sugar, �our, butter, etc.

60

7.1. GAME and OMS 61

Figure 7.1.: OMS architecture before GAME

That �recipe� is the output of the Flow Descriptor Editor and is stored in the flow.xml �le.It tells the system which ingredients are needed to build that Flow that is being de�ned.How the single ingredients are composed itself is not said in the flow.xml however. Eachingredient or group of ingredients are described with the help of the rule �les (*.ilr1).Now there are two possibilities: either the needed ingredient has already been de�nedand the developer just references it in the flow.xml �le, or the ingredient has to be de�ned.In the second case the developer can open a new *.ilr �le and de�ne its ingredient.Said with the OMS terminology the flow.xml de�nes which other Flows are included in thatprocess and which Aspects are attached to them. Remember that in Chapter 3 we pointedout, that a Flow shares many properties with a process, and that a Root Flow is identicalto a Process, this fact is also visualized in Figure 3.1 on page 15.The process de�nition as such is given in the rule �le (*.ilr), both static and dynamicparts. These two �les, the rule �le and the �ow descriptor, are then read by the CLOMwhich builds a runtime process with that knowledge.The processes are documented with the help of Microsoft Visio. So the developer isnot only responsible to implement the process de�nition, but also to depict the processwith Microsoft Visio. In a second step an image (*.png) of that Microsoft Visio model isgenerated. This image is then referenced through a link out of the Wiki, which documentsall the processes. Also the flow.xml �le is, with the help of an Extensible Stylesheet LanguageTransformations (XSLT) transformation, visible in the Wiki.

7.1.2. Integration of GAME

Now we have a big picture of how the simpli�ed OMS architecture was before. So we areable to have a look at the integration of GAME within the OMS in a next step.The integration of GAME resulted in the three following changes:

1*.ilr is a format proper of ILOG [19]

7.1. GAME and OMS 62

Figure 7.2.: Integration of GAME with OMS

• The Flow Descriptor Editor needs to be able to open a new *.game �le if a newprocess needs to be de�ned. In that case a generator, provides an empty *.game �le.

• The Flow Descriptor Editor needs to be able to open an existing *.game �le.

• OMS needs to be able to interpret the aspect model resulting from GAME.

Figure 7.2 shows the simpli�ed CLOM architecture embedding GAME. The developmentcycle stays almost the same. As before the developer starts its implementation by de�n-ing the Flows and Aspects that are needed for his process. This is still done with the FlowDescriptor Editor.What is new in the Flow Descriptor Editor, is that GAME can be directly opened to de-pict the static structure of the process in question. In case where a new model is createda generator is responsible to generate an empty *.game �le. If the �le already exists it isjust opened.So with GAME the developer may not only describe his ingredients with rule �les butalso with a GAME model. The static parts will newly be described with a model and thedynamic parts will as before be described with rules.GAME provides two XML-based �les as output. One of those two is the *.game_diagram�le, which represents the model graphically. This �le is responsible for the layout and isas such not interesting for the CLOM. The other one is the *.game �le. The structure(XMLSchema) of that �le is explained in more detail in Section 7.6. This �le representsthe static aspect model and replaces the template rule which condition is always ful�lled.The rule �les (*.ilr) now only de�ne the dynamic parts of a process, i.e. the conditiondepends on the actual situation.

7.2. Base of the Editor 63

What is read by the CLOM in the end are the flow.xml and the *.ilr �les as before, but nowit has to read a third �le as well which is the static aspect model provided by GAME(*.game).Maybe you have already recognized that Microsoft Visio is not present anymore on Fig-ure 7.2. The reason is, that GAME already provides the graphical documentation. It ispossible to save that graphical model as image (*.svg or *.png for instance) which can bereferenced through the Wiki. As before the flow.xml is visualized with an XSLT transfor-mation in the Wiki as well.

7.1.3. Interfaces for GAME Integration

As described in Section 6.1 where the requirements were lined out, the aspect modelproduced by GAME has to reference some OMS artifacts, which are:

• The Activity name and function

• The Flow name

To collect those OMS artifacts two interfaces were de�ned, that may be used by GAME.Within GAME the user then can fetch those artifacts with the help of a dialog. Theimplementation of that dialog is the topic of Section 8.3.

7.2. Base of the Editor

Subsection 5.5.1 introduced already that every GMF editor has a so called domain model,which builds the base of each editor. This chapter will show the domain model that isused for GAME in a general manner. For a detailed description see Subsection 8.1.1.Figure 7.3 shows the graphical ecore model that was designed for GAME. The GAME-Context EClass2 is the anchor of the model, there are no visual representations of thatelement in the editor because this element represents the canvas on which the elementsmay be drawn. But it is not possible to draw non-restrictively on that canvas. Only thoseelements that are directly linked with the GAMEContext can. In the case of GAME thereare three kind of elements that can be put on the canvas directly. These elements are aStep, a DefaultPredecessorRelation and a PredecessorRelation, as you can see on Figure 7.3.All the others are either represented implicitly, i.e. as a kind of placeholder, or have tobe placed within or starting from another element.To have a better idea of the representation of this domain model the list below introduceshow each EClass of the ecore model is represented in the editor in the end:

• GAMEContext As already said this EClass is not really visible in the editor. It repre-sents the canvas on which the other elements can be represented.

• DefaultPredecessorRelation The DefaultPredecessorRelation is represented as an arrowthat goes from the predecessor to the successor. As explained in Subsection 6.2.3this arrow represents two arrows in reality. For a more precise explanation go backto Subsection 6.2.3.

• PredecessorRelation The DefaultPredecessorRelation is used most of the time, i.e. over98%. Still there is the need for a PredecessorRelation that can be customized. Prede-

2An EClass in an ecore model is equivalent to a Class in an UML Class Diagram

7.2. Base of the Editor 64

Figure 7.3.: The domain model of GAME

cessorRelation is such a customizable element. It is represented as a rectangle in theeditor and has to be linked with its predecessor and its successor. Customization ofthat rectangle is done by de�ning the PredecessorCondition. The next point explainshow this is done.

• PredecessorCondition This element is not itself visualized on the editor. The Prede-cessorContition is implicitly set by drawing either a SimplePredecessorCondition or aHasResultPredecessorCondition within the PredecessorRelation rectangle.

• SimplePredecessorCondition The SimplePredecessorCondition is one possible characteris-tic of the PredecessorCondition and is represented as a �gure with invisible bordersthat can be placed within the PredecessorRelation rectangle.

• HasResultPredecessorCondition This is the other characteristic of the PredecessorCon-dition. As the SimplePredecessorCondition it is represented as a �gure with invisibleborders that can be placed within the PredecessorRelation rectangle.

• Step The Step is one of the elements that can be put directly on the canvas. It isrepresented as a rounded rectangle.

• StepImplementation This is again an element that is not visible on the canvas. It hastwo implementations which are the EClasses Activity and Flow.

• Activity This element is represented by a �gure with invisible borders and can onlybe placed within a Step �gure.

7.3. Core Plug-in 65

• Flow Next to the Activity this is the second characteristic of the StepImplementation.Just like the Activity a Flow is represented as a �gure with invisible borders and itcan be placed only within a Step �gure.

The EEnum enumerations (SimpleCondition, PredecessorConditionOperation, AutoAbortBehaviour,AutoCancelBehaviour, MinInstances and MaxInstances) can be used as description type for EAt-tributes of the EClasses. As an example the enumeration MinInstances de�nes the EAttributeminInstances of the Step EClass. In the Properties View of the graphical editor thiswill generate a selection list. With the help of that list the according property may bede�ned.The EDataType StringWrapper forms a new data type for the model. Find in Section 8.4,the explanation why this data type is needed.With the help of this ecore model the base for the editor can be generated. What thegenerated code contains and how it is arranged is the topic of the next sections.Refer Chapter 9 to learn how each �gure can be created and which tools are available forits creation.

7.3. Core Plug-in

The core plug-in (org.swisscom.oms.plugins.game see Figure 7.6, page 68) sets up the basisfor the editor. This can also be seen in Figure 7.5, every other plug-in depends on thecore plug-in. This plug-in contains all the con�guration �les described in Chapter 5.As we de�ned a custom EDataType in the ecore model, we had to put the underlyingclass somewhere in this plug-in. In order to distinguish the generated code from the onewritten by the author we created a customsrc folder in that plug-in that contains thatStringWrapper class.The Java code that is generated for this plug-in is arranged in four packages:

game Package This package contains the interfaces for all the elements described inthe model. When talking about elements here EClasses and EEnums of the ecore modelare meant. Communication always goes through these interfaces. Figure 7.4 shows theUML diagram of all EClasses in the model with its inheritances and dependencies.It can easily be seen that the central class is the GameFactory. Everything is createdstarting from here.Noteworthy is that the generalizations in the ecore model in Figure 7.3 are also presentin the generated interfaces that are represented in Figure 7.4.

game.impl Package The game.impl package contains, as the name says, the implemen-tations of the interfaces mentioned in the paragraph before. What attracts someone'sattention here, is that not all the interfaces are implemented.The enumerations that were de�ned in the ecore model are not present in that implemen-tation package. The implementation of that enumerations is so trivial that it is done inthe game package directly. They are situated in the game package with all the interfaces,because communication goes through the game package by default.The GameFactoryImpl class of that package had to be customized, so that the customStringWrapper class is used. See in Section 8.4 what exactly had to be done.

7.4. Edit and Editor Plug-ins 66

Figure 7.4.: UML class diagram of the game package

game.util Package In the game.util package two essential and tightly coupled helpers aresituated. The �rst of these classes is responsible for creating adapters for each type inthe domain model. It does so by creating a so called GameSwitch, the second class of thatpackage. This switch is responsible for representing the hierarchy of the domain model.

game.validation Package The game.validation Package contains interfaces that show howvalidation of the types of the model may be done.Since these interfaces were not implemented for the Master Thesis this validation doesnot take place.

7.4. Edit and Editor Plug-ins

Both of these plug-ins are being generated through the game.genmodel which is based inEMF. Because non of them were customized only a short description of what they areresponsible for is given here. Have a look at Eclipse Modeling Framework: A Developer'sGuide [FB03] if you are interested in more detail.The com.swisscom.oms.plugins.game.edit plug-in contains classes responsible for adapting themodel objects in such a way that they can be viewed and edited. Those classes determinehow each type of object will be displayed and how it will respond to editing commands.The code that can be found in the org.swisscom.oms.plugins.game.editor plug-in sets up theEMF editor. This is a tree view of the aspect model. This plug-in also supports validation,

7.5. Diagram Plug-in 67

Figure 7.5.: The dependencies between the four generated plug-ins

to check if the domain model de�ned is respected.The dependencies to the other plug-ins is visible in Figure 7.5.

7.5. Diagram Plug-in

In the diagram plug-in (org.swisscom.oms.plugins.game.diagram see Figure 7.6) the graphicaleditor is de�ned, i.e all the �gures and its constraints are de�ned here. This plug-independs on the org.swisscom.oms.plugins.game.edit and the core plug-in, as may be seen inFigure 7.5.A particularity of this plug-in is that it contains two source folders, as the core plug-in.One is called src as probably expected. The other source folder is called customsrc andholds all the classes that are used for the customization of the generated graphical editor.We will have a look at one folder with its containing packages at a time.

7.5.1. src Source Folder

As already mentioned before this folder contains the classes that were generated throughGMF. There are three classes that were customized. These classes (StepEditPart, StepIn-stantiationConditionEditPart and GamePropertySection) will be described in more detail, whenthe package concerned is described.Only those packages that were studied in more detail are described here. The Javadocthat can be found on the CD-ROM provided with this paper, gives an insight on thewhole architecture of the diagram plug-in.

game.diagram.edit.commands Package Here you can �nd the commands for creatingeach element of the editor. For each �gure that can be drawn there is a CreateElement-Command. For the connections there exists an EditElementCommand in addition to theCreateElementCommand which de�nes how reorientation of the connection is handled.


Figure 7.6.: Relations between con�guration �les, generator models and generated code

game.diagram.edit.parts Package In this package the so called edit parts for each elementthat appear on the editor canvas may be found. Among other things this edit parts containa constructor for creating the �gure on the canvas. Also elements that are not visibleon the canvas have such an edit part, the only di�erence is that the constructor for the�gure representing it on the canvas is missing.The edit parts know all the children of the corresponding �gure and de�ne how they maybe added and removed. In addition to that, they de�ne the layout and the policies of the�gure.The Step �gure is the most customized �gure within GAME. These customizations alsoa�ected the StepEditPart and the StepInstantiationConditionEditPart. What exactly had to bechanged and customized is the topic of Section 8.2.

game.diagram.providers Package This package contains a listing of all known types ofGAME, i.e. everything that is de�ned in the ecore model. In this package you can also�nd the rules that tell the editor which element may be created on the canvas for example,or if an element may only be created as a child of a speci�c other one.

game.diagram.sheet Package The classes that may be found in this package are respon-sible for the set up of the property sheet, with the help of which, the �gures on thediagram may be con�gured. If you use GAME you know this property sheet as so calledProperties View.The property sheet was customized as well. The GamePropertySelection class was adaptedfor the needs of GAME, more detail about the changes may be found in Section 8.3.


Figure 7.7.: XMLSchema for the GAMEContext

7.5.2. customsrc Source Folder

The classes that can be found in this source folder are all written by the author andcannot be generated. They are used for customizing the graphical editor. To do so theyare linked in some way or another to the generated classes. Find in Appendix C thesource code of all these classes.

game.diagram.figures Package As the name of the package suggests the custom �guresmay be found here. In order to let GMF know about these customizations these �gureshave to be integrated within the generated code. Section 8.2 explains how this linking isdone.

game.diagram.sheet Package This package is not as self-explaining as the one before.The classes that can be found here customize the property sheet that is used for editing theActivity or the Flow. Section 8.3 describes what has do be changed in the GamePropertySectionclass, in order that the dialogs described in the paragraph open.

game.diagram.dialog Package In this package you can �nd the classes that de�ne thedialog that links GAME with the existing OMS artifacts. This dialog allows the user toset the references of the Activity or Flow in the graphical model with the one in OMS. Havea look at Subsection 8.3.1 to see in detail how this is done.

7.6. Output of GAME 70

Figure 7.8.: XMLSchema showing the Step

7.6. Output of GAME

The output of game are two XML-based �les. One representing the layout of the diagramwith the extension *.game_diagram and one representing the content of the diagram withthe extension *.game.The graphical representation, i.e the layout is not of interest for the CLOM. The �le thatactually represents the static aspect model is the *.game �le. So let us have a closer lookat the structure of that �le. The *.game �le for the sightseeing tour modeled in Section9.3 looks as follows:

1 <?xml vers ion=" 1.0 " encoding="UTF−8"?><game : GAMEContext xmi : vers ion=" 2.0 " xmlns : xmi= " h t t p : / / www.omg. org / XMI " xmlns : x s i = " h t t p : / / www.

w3 . org /2001/XMLSchema−i ns tance " xmlns : game=" h t t p : / / www. swisscom .com/oms / game">3 <step name=" Cast le ">

<implementat ion x s i : type="game : A c t i v i t y " re ference=" V i s i t a t i o n A c t i v i t y : Cast le " / >5 </ step >

<step name=" Br idge ">7 <implementat ion x s i : type="game : A c t i v i t y " re ference=" V i s i t a t i o n A c t i v i t y : Br idge " / >

</ step >9 <step name=" Opera " minInstances=" zero " i n s t a n t i a t i o n C o n d i t i o n =" Gold Option ">


Figure 7.9.: XMLSchema for the Predecessor Relation

<implementat ion x s i : type="game : A c t i v i t y " re ference=" V i s i t a t i o n A c t i v i t y : Opera " / >11 </ step >

<step name=" Market . Ha l l ">13 <implementat ion x s i : type="game : A c t i v i t y " re ference=" V i s i t a t i o n A c t i v i t y : MarketHal l " / >

</ step >15 <step name=" Church " minInstances=" zero " i n s t a n t i a t i o n C o n d i t i o n =" Gold Option ">

<implementat ion x s i : type="game : A c t i v i t y " re ference=" V i s i t a t i o n A c t i v i t y : Church " / >17 </ step >

<step name=" Emergency " minInstances=" zero " i n s t a n t i a t i o n C o n d i t i o n =" f o r each i n j u r e d t o u r i s t ">

19 <implementat ion x s i : type="game : Flow " re ference=" Emergency :1 " / ></ step >

21 <defau l tPredecessorRe la t ion predecessor= " Cast le " successor= " Br idge " / ><defau l tPredecessorRe la t ion predecessor= " Br idge " successor= " Opera " / >

23 <defau l tPredecessorRe la t ion predecessor= " Opera " successor= " Market . Ha l l " / ><defau l tPredecessorRe la t ion predecessor= " Market . Ha l l " / >

25 <defau l tPredecessorRe la t ion successor= " Church " / ><defau l tPredecessorRe la t ion predecessor= " Market . Ha l l " successor= " Church " / >

27 </game : GAMEContext>

Code extract 7.1: sightseeing.game

The Steps in line 9 and 15 are only executed if the rule (*.ilr) that stands behind thoseconditional Steps requires them. The rule requires those Steps, if the tourist group hasbooked the �Gold Option�.The same holds for the Emergency Step in line 19. The rule standing behind requiresthat step if there is a injured tourist.Figures 7.7, 7.8, 7.9 and 7.10 show the syntactic structure, i.e. the graphical XMLSchema,of each *.game �le. The root is always the GAMEContext. That context has a sequence ofinde�nitely many children of the type Step, PredecessorRelation and DefaultPredecessorRela-tion (Figure 7.7).The Step is then further decomposed into a single StepImplementation, which can either beof the type Activity or Flow. Figure 7.8 in addition shows the attributes that may be set


Figure 7.10.: XMLSchema showing the composition of the Default Predecessor

for a Step.The attributes for the PredecessorRelation are visible in Figure 7.9. A PredecessorRelationhas a single child which is the PredecessorCondition. That PredecessorCondition can be of thetype SimpleCondition or HasResultCondition, have a look at Figure 7.9 to see the attributesof the SimpleCondition and the HasResultCondition respectively.The DefautlPredecessorRelation is a terminal element, i.e. it does not have any children.Figure 7.10 shows the attributes that must be set for the DefautlPredecessorRelation.With the information contained in the *.game �le and the rule �les which decide whetherSteps having an instantiationCondition are required or not, the CLOM is able to dynamicallycreate a process instance at runtime.

8Implementation

8.1. Con�guration Files and Mapping Model . . . . . . . . . . . . . 73

8.1.1. Domain Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

8.1.2. Graphical De�nition . . . . . . . . . . . . . . . . . . . . . . . . 75

8.1.3. Tooling De�nition . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.1.4. Mapping Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.2. Custom Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.2.1. Step Figure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.2.2. Step Body Figure . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.2.3. Step Property Figure . . . . . . . . . . . . . . . . . . . . . . . . 79

8.2.4. Invisible Compartment Figure . . . . . . . . . . . . . . . . . . . 80

8.2.5. Integration with Generated Code . . . . . . . . . . . . . . . . . 80

8.3. Linking with OMS Artifacts . . . . . . . . . . . . . . . . . . . . 88

8.3.1. Custom Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

8.4. Step Name used as ID . . . . . . . . . . . . . . . . . . . . . . . 92

8.5. Remove Standard Helper Tools . . . . . . . . . . . . . . . . . . 94

8.5.1. Remove Pop Up Bar . . . . . . . . . . . . . . . . . . . . . . . . 94

8.5.2. Remove Connection Helpers . . . . . . . . . . . . . . . . . . . . 95

8.6. Code Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

8.7. Embedding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

8.8. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

First this chapter shows how GAME was con�gured. Then it gives a detailed view at thecustomizations that were added. Because this chapter is very technical it may be skippedat �rst reading.

8.1. Con�guration Files and Mapping Model

This section describes how the three con�guration �les (green on Figure 8.2) were set upfor generating the Graphical Aspect Model Editor in the end.

73

8.1. Con�guration Files and Mapping Model 74

Figure 8.1.: The domain model of GAME

8.1.1. Domain Model

In Figure 8.2 this model has the number 1. Figure 8.1 shows the domain model thatbuilds the base of GAME. The GAMEContext builds the root of the model, and the canvasfor the graphical editor. Because the diagram of the ecore model is very close to an UMLclass diagram it is quite self-explanatory. But still we will describe the model with somewords.The root class GAMEContext just mentioned is then composed of Steps, DefaultPredecessor-Relations and PredecessorRelations. The DefaultPredecessorRelation is a terminal class andis not further split up. The Step has exactly one StepImplementation, which is a gener-alization for the Activity and the Flow. The PredecessorRelation consists of exactly onePredecessorCondition which is a generalization for the SimplePredecessorCondition and theHasResultPredecessorCondition.In addition to that EClasses1 in the ecore model some enumerations are de�ned. The Sim-pleCondition enumerates all the conditions that are de�ned for a SimplePredecessorCondition.The PredecessorConditionOperation lists all operations for which the PredecessorRelation con-dition may react, go back to Subsection 6.2.3 to see a listing of all possible operations.StringWrapper is a custom data type, that is used to wrap the java.lang.String class for re-placing all the space characters with point characters. Find a detailed description inSection 8.4.Also for the Step useful enumerations were de�ned, these are:

1An EClass in an ecore model is equivalent to a Class in an UML Class Diagram


Figure 8.2.: Relation between Con�guration Files and Plug-ins

• The AutoAbortBehaviour contains a list that de�nes, how the �ow behaves in case thatthe step aborts itself.

• The AutoCancelBehaviour contains exactly the same choices only that it handles thecase where the step cancels itself.

• MinInstances de�nes if a Step is conditional or not, i.e. zero or one.

• MaxInstances de�nes if a Step can be a multi instance Step or not, i.e. one or n.

8.1.2. Graphical De�nition

The graphical de�nition of GAME is the number 3a of the green rectangles in Figure 8.2.The graphical de�nition itself is illustrated in Figures 8.3 and 8.13 on page 99. It had tobe split up into two �gures since it is too big to be illustrated in one. This already showshow much information is stored in this single �le.Figure 8.3 shows the graphical de�nition without the �gure gallery. Here all the nodes,connections, compartments and labels that will be visible on the graphical editor arede�ned. Each of these elements is linked with a one-to-one relationship with an elementfrom the ecore model. Typically nodes, connections and compartments are linked withEClasses, whereas labels are linked with the EAttributes of the EClasses.The graphical gallery is shown in Figure 8.13 at the end of this chapter. These tree viewsof the con�guration �les are quite straightforward to understand. So we will not explainevery �gure in detail. Section 8.2 explains the construction of the custom �gures. Onceyou have read this section the other �gure con�gurations are easy to understand.


Figure 8.3.: Graphical De�nition of GAME part one: without showing the Figure Gallery

8.1.3. Tooling De�nition

Compared to the other two con�guration �les the tooling de�nition, numbered 3b inFigure 8.2, is quite short. All in all nine tools are de�ned (Figure 8.4). The con�guration�le links the tools to the corresponding �gure descriptor of the �gure that should becreated using this tool.In addition the images that are visible on the tools palette may be speci�ed here. Thisis done by adding an icons folder to the core plug-in, placing the icons in that folderand referencing them in the Properties View. You can see this in Figure 8.4. Section 9.2explains every tool and how it is used.

8.1.4. Mapping Model

Figure 8.5 shows the mapping model of GAME, in the overview in Figure 8.2 this �le iscolored in orange. The two Top Node References show the two elements that can directlybe drawn on the canvas (Step and PredecessorRelation). Bellow this two root nodes thefurther composition of these �gures is de�ned.In addition to the nodes also the connections have to be de�ned. This is done withthe Link Mapping nodes. The �rst Link Mapping refers to the third element that may bedirectly drawn on the canvas, the DefaultPredecessorRelation. The two Link Mappings that

8.2. Custom Figures 77

Figure 8.4.: Tooling De�nition of GAME

follow are special cases, because the root object of the domain model does not knowthem directly. We are talking about the connections which link the PredecessorRelationwith its predecessor and successor. If you compare it with the Link Mapping de�ned forthe DefaultPredecessorRelation you will notice that they are much shorter. The reason forthat is, that these are so called phantom links. These phantom elements are used torepresent something directly on the canvas even if the root element of the ecore modeldoes not know them directly. The trick with these phantom links is that only their targetis de�ned explicitly. The source is implicitly given through the Associations �predecessor�and �successor� in the ecore model (Figure 8.1). The Properties View on Figure 8.5shows the con�guration of such a phantom link.

8.2. Custom Figures

As mentioned earlier in this documentation some �gures had to be customized in orderto cover the needs of GAME. As a pattern for how �gures can be customized the BPMNEditor [27] provided by Eclipse was used as an example.The four �gures that were de�ned by the author may be found in the customsrc folder ofthe com.swisscom.game.diagram plug-in (refer to Appendix C to see the implementations).The subsections that follow explain the purpose of each of the custom �gures and howthey are linked with the classes generated by GMF.


Figure 8.5.: Mapping Model of GAME

8.2.1. Step Figure

The �gure that is visible on the editors canvas is the StepFigure. This �gure is a standard�gure that is provided in the graphical de�nition of GMF, i.e. not a custom �gure itself.It is de�ned as a RoundedRectangle that is provided by the draw2d plug-in.The reason why this �gure is nevertheless mentioned here, is the particularity that itcontains two other �gures that are custom �gures. They are the StepBodyFigure (blue inFigure 8.6) and the StepPropertyFigure (gray in Figure 8.6).Figure 8.7 shows, how these custom �gures contained within the step �gure are integratedin GMF. In the code that will be generated these �gures will be created each time aStepFigure is created. With the help of the Child Access nodes that are visible in Figure 8.7the StepFigure knows how to access these children.

8.2.2. Step Body Figure

The StepBodyFigure is a custom �gure. This implies that the class that represents this�gure has to be provided by the author. This custom class that was written extends the


Figure 8.6.: StepFigure with the StepBodyFigure and the StepPropertyFigure

Figure 8.7.: De�nition of the StepFigure in the gmfgraph

RectangleFigure provided by draw2d and overrides the paintFigure method in order to havea transparent �gure border.In addition to that the minimum size of the StepBodyFigure is de�ned in such a way thatthe child that is going to be placed within the StepBodyFigure (StepCompartment) is alwaysfully visible.Figure 8.8 shows the Properties View of the Custom Figure StepBodyFigure node of Fig-ure 8.7, here you can see how the custom �gure in the *.gmfgraph is linked with thecustomized implementation.

8.2.3. Step Property Figure

The last �gure that is used to represent a Step is the StepPropertyFigure. Like the StepBody-Figure this is a custom �gure. As the name suggests already this �gure is connected withsome properties of the Step. The rewind, pause and plus symbol will be displayed in that�gure. For more information about the signi�cance of that symbols refer to Subsection6.2.2.This self-implemented �gure also extends the RectangleFigure provided by the draw2d plug-in and overrides the paintFigure method to be represented as transparent �gure. In additionto that the minimum and the maximum size are ruled. Like this the PropertyStepFigurestays the same size even if the parent's �gure (StepFigure) size varies.The linking of the custom �gure in the *.gmfgraph with the actual implementation is the


Figure 8.8.: Properties View of the custom StepBodyFigure in the gmfgraph

Figure 8.9.: Graphical de�nition and Properties View of the ActivityFigure

same as shown in Figure 8.8. The only di�erence is that the StepBodyFigure is replacedwith StepPropertyFigure for the Quali�ed Class Name �eld.

8.2.4. Invisible Compartment Figure

As the name states this �gure is used for the �gures that appear in a so called compart-ment. The StepFigure as well as the PredecessorRelationFigure are de�ned as compartments.This means that these �gures may hold other �gures inside themselves.The InvisibleCompartmentFigure is needed to hide the fact that there is another �gure in theparent �gures. To do so the borders of the child �gures are set invisible. We achieve thisby overriding the paintFigure method as for the �gures before.The child �gures themselves are then declared as custom �gures with the InvisibleCom-partmentFigure as Quali�ed Class Name. Figure 8.9 clari�es how this is done. In thegenerated code ActivityFigure then extends the InvisibleCompartmentFigure which creates thelink between GMF and the self de�ned �gure.

8.2.5. Integration with Generated Code

Up to a certain point customization can be integrated without touching the generatedcode. Unfortunately this does not work all the time. This section describes the class thathad to be altered in order to get the customized StepFigure.


In section 7.5 it was already mentioned that the StepEditPart and the StepInstantiation-ConditionEditPart classes that can be found in the game.diagram.edit.parts package of thecom.swisscom.game.diagram plug-in had to be customized.If one looks at the changes made to the generated source code, one notices two majorproperties. First the annotation @generated is changed into @generated NOT and the cus-tomized section is marked with a comment.The next few paragraphs describe the changes that have been necessary for integratingthe customizations.

Creation of the StepFigure

Since we added two custom child �gures to the StepFigure we have to adapt the createCon-tents method of the inner class StepFigure of the StepEditPart class.Code extract 8.1 shows the changes that had to be e�ected. The problem with the gener-ated code is that it expects a constructor without argument. Line 18 shows the code thatwas generated. The custom �gure that was elaborated by the author provides only con-structors with arguments. So the initialization of the StepPropertyFigure has to be adapted,as in line 19, to the custom implementation of the �gure.

1 /∗ ∗∗ @generated NOT

3 ∗ /private void createContents ( ) {

5

fFigureStepNameFigure = new WrapLabel ( ) ;7 fFigureStepNameFigure . setText ( "<StepName>" ) ;

9 fFigureStepNameFigure . setFont (FFIGURESTEPNAMEFIGURE_FONT) ;

11 th is . add ( fFigureStepNameFigure ) ;

13 fF igureStepBodyFigure = new StepBodyFigure ( ) ;

15 th is . add ( fFigureStepBodyFigure ) ;

17 / / cus tomiza t ion/ / fF igureStepProper tyF igure = new StepProper tyF igure ( ) ;

19 fF igureStepProper tyF igure = new StepProper tyF igure ( StepEd i tPar t . th is . getMapMode ( ) ) ;/ / cus tomiza t ion end

21 th is . add ( fF igureStepProper tyF igure ) ;

23 }

Code extract 8.1: StepEditPart.java: StepFigure.createContents() method

Properties Visualized in StepFigure

A requirement for the StepFigure was that certain property settings can be visualized inthe �gure directly. This requirement caused some changes in the StepEditPart class thatwill be explained in this paragraph.First of all, we had to override the paint method of the org.eclipse.draw2d.Figure class, thismethod was not present in the code before. Code extract 8.2 shows the implementation.

/∗ ∗2 ∗ Draws the StepFigure and the decora t ions according to the p r o p e r t i e s set f o r t h i s step

∗4 ∗ @generated NOT

∗ /6 @Override


/ / template f o r cus tomiza t ion : bpmn example8 / / t h i s method cannot be found i n the generated code

/ / remark : the i n s t a n t i a t i o n c o n d i t i o n l a b e l i s drawn i n the S t e p I n s t a n t i a t i o n C o n d i t i o nEd i t Par t

10 public void pa in t ( Graphics graphics ) {super . pa i n t ( graph ics ) ;

12 / / Step model = ( Step ) ( ( View ) getModel ( ) ) . getElement ( ) ;/ / decorate f i g u r e according to a t t r i b u t e s

14 StepEd i tPar t . th is . paintSubFlowMarker ( graph ics ) ;S tepEd i tPar t . th is . pa in tMu l t i I ns tanceMarke r ( graph ics ) ;

16 StepEd i tPar t . th is . paintCompensationMarker ( graph ics ) ;S tepEd i tPar t . th is . paintDashedLine ( graph ics ) ;

18 }

Code extract 8.2: StepEditPart.java: StepFigure.paint() method

First we need to paint the �gure as such, this is achieved with the code on line 11. Thenwe have to check for each property which we want to visualize on the �gure if the propertyvalue needs to be visualized or not. This is done with the lines 14 to 17.Now let us have a look at those four paint methods that will in the end bring the symbolon the StepFigure. We will begin with the paintSubFlowMarker method from line 14. Thismethod paints the plus symbol if the implementation of the Step is a Flow. In other wordsthe plus symbol is added to the StepFigure if the �gure that is contained in the StepFigureis a FlowFigure. Code extract 8.3 shows the code that will make the symbol appear.First of all we get the Step object from the model and check if it is a Flow object ornot (lines 10, 11). If it is a Flow object we start painting the plus symbol. To draw thesymbol we need to set up a little rectangle that holds the symbol. The idea is that therectangle �ts exactly the height of the StepPropertyFigure this is done in line 17. The littlesquare to hold the symbol is then constructed with reference to the StepFigure (line 20- 25). Finally the StepPainter.paintSubFlow method is called which actually will draw theplus symbol. Code extract 8.4 shows how this is done.

/∗ ∗2 ∗ Cal led dur ing the p a i n t i n g o f the step f i g u r e . Checks i f the

∗ step has a f low implementat ion and pa in t the p lus symbol i n t h a t case .4 ∗

∗ @generated NOT6 ∗ /

/ / template f o r cus tomiza t ion : bpmn example8 / / t h i s method cannot be found i n the generated code

private void paintSubFlowMarker ( Graphics graphics ) {10 Step step = ( Step ) ( ( View ) getModel ( ) ) . getElement ( ) ;

i f ( step . get Implementat ion ( ) instanceof Flow ) {12 /∗

∗ def ine the s ize o f the symbol rec tang le as high as the14 ∗ StepProper tyF igure

∗ /16 StepFigure f i g = th is . getPrimaryShape ( ) ;

i n t s ize = StepProper tyF igure . getFixedHeightDP ( f i g ) ;18 Rectangle bounds = f i g . getBounds ( ) ;

20 / / setup the rec tang le to hold the plus symbolRectangle rewRect = new Rectangle ( ) ;

22 rewRect . x = bounds . x + bounds . width / 2 ;rewRect . y = bounds . y + bounds . he igh t − s ize ;

24 rewRect . he igh t = s ize ;rewRect . width = s ize ;

26

/ / / / f o r debugging28 / / g raphics . setForegroundColor ( ColorConstants . b lack ) ;

/ / graphics . drawRectangle ( rewRect ) ;30

/ / pa i n t the SubFlow symbol32 StepPain ter . paintSubFlow ( graphics , rewRect ) ;

}


34 }

Code extract 8.3: StepEditPart.java: StepFigure.paintSubFlowMarker() method

The paintSubFlow method is quite simple. It evaluates the middle points of the heightand the width of the rectangle that will hold the symbol in the end. Then the �gure isconstructed by drawing a line between the middle points de�ned above (line 12 - 21). Alittle particularity of that symbol is that the rectangle holding the symbol is outlined aswell.The methods pushState and popState of the graphic help to keep the rest of the �gureconsistent. When pushState (line 10) is called the actual state of the �gure is stored on astack, then we can add our symbol. Once the changes on the �gure are �nished we callthe method popState (line 31) and the current state is restored to the previously poppedone.

/∗ ∗2 ∗ Pain ts the plus symbol f o r v i s u a l i z i n g a SubFlow

∗4 ∗ @param Graphics

∗ The Graphics ob jec t used f o r p a i n t i n g6 ∗ @param Rectangle

∗ symbol bounds8 ∗ /

public s t a t i c void paintSubFlow ( Graphics graphics , Rectangle f i gRec t ) {10 graphics . pushState ( ) ;

12 i n t middleX = f i gRec t . width / 2 ;i n t middleY = f i gRec t . he igh t / 2 ;

14

/ / h o r i z o n t a l l i n e16 Poin t p1 = new Poin t ( f i gRec t . x , f i gRec t . y + middleY ) ;

Po in t p2 = new Poin t ( f i gRec t . x + f i gRec t . width , f i gRec t . y + middleY ) ;18

/ / v e r t i c a l l i n e20 Poin t p3 = new Poin t ( f i gRec t . x + middleX , f i gRec t . y ) ;

Po in t p4 = new Poin t ( f i gRec t . x + middleX , f i gRec t . y + f i gRec t . he igh t ) ;22

graphics . setForegroundColor ( ColorConstants . b lack ) ;24 graphics . drawRectangle ( f i gRec t ) ;

26 graphics . setL ineWidth ( 2 ) ;

28 graphics . drawLine ( p1 , p2 ) ;graphics . drawLine ( p3 , p4 ) ;

30

graphics . popState ( ) ;32 }

Code extract 8.4: StepPainter.java: paintSubFlow() method

The methods paintMultiInstanceMarker, paintCompensationMarker and paintDashedLine are quitethe same as the one for the Subflow in Code extract 8.3. Get the Step from the modeland check if the according property is set. If so, paint the symbol that visualizes thatproperty on the StepFigure, so here only the implementation of the actual symbols will beshown.Code extract 8.5 shows how the pause symbol that represents multi instance Steps iscreated. Also here the state of the actual �gure is pushed on a stack. For the creation ofthe pause symbol some local variables rule the space between the two bars (line 13), thewidth of the bar in line 14 and the middle of the rectangle to hold the symbol in the linethat follows. The two rectangles for the pause symbol are then de�ned and drawn on thegraphic. In the end the popped state is again added to the current one.


/∗ ∗2 ∗ Pain ts the pause symbol f o r v i s u a l i z i n g a m u l t i ins tance step




public s t a t i c void p a i n t M u l t i I n s t a n c e ( Graphics graphics , Rectangle f i gRec t ) {10

graphics . pushState ( ) ;12

i n t spacing = 2;14 i n t barSize = 3;

i n t middleX = f i gRec t . width / 2 ;16

/ / f i r s t rec tang le o f pause symbol18 Rectangle rec t1 = new Rectangle ( ) ;

rec t1 . x = f i gRec t . x + middleX − spacing − barSize ;20 rec t1 . y = f i gRec t . y ;

rec t1 . width = barSize ;22 rec t1 . he igh t = f i gRec t . he igh t ;

24 / / second rec tang le o f pause symbolRectangle rec t2 = new Rectangle ( ) ;

26 rec t2 . x = f i gRec t . x +middleX + spacing ;rec t2 . y = f i gRec t . y ;

28 rec t2 . width = barSize ;rec t2 . he igh t = f i gRec t . he igh t ;

30

graphics . setForegroundColor ( ColorConstants . b lack ) ;32 graphics . setBackgroundColor ( ColorConstants . b lack ) ;

34 graphics . drawRectangle ( rec t1 ) ;graphics . drawRectangle ( rec t2 ) ;

36

graphics . f i l l R e c t a n g l e ( rec t1 ) ;38 graphics . f i l l R e c t a n g l e ( rec t2 ) ;

40 graphics . popState ( ) ;}

Code extract 8.5: StepPainter.java: paintMultiInstance() method

The last �gure that has to be implemented for visualizing a property is the rewind symbol.It indicates if a Step is a compensation Step or not. In Code extract 8.6 you can see thatthe implementation is very similar to the two others. The methods pushState and popStateprovided by the Graphics object of the draw2d plug-in add to join the decorating symbolto the already existing �gure.As for the other �gures, again some local variables have to be de�ned in lines 13 to15. The two middle variables de�ne, as the name suggests the middle of the heightand the width. The two triangles for representing the rewind symbol are constructedindependently. Once everything is added to the graphic it looks like one.

/∗ ∗2 ∗ Pain ts the rewind symbol f o r v i s u a l i z i n g compensation steps




public s t a t i c void paintCompensation ( Graphics graphics , Rectangle rewRect ) {10


i n t middleX = rewRect . x + rewRect . he igh t / 2 ;14 i n t middleY = rewRect . y + rewRect . width / 2 ;


i n t s ize = rewRect . he igh t ;16

/ / f i r s t t r i a n g l e o f rewind symbol18 P o i n t L i s t po in ts1 = new P o i n t L i s t ( ) ;

po in ts1 . addPoint ( rewRect . x , middleY ) ;20 po in ts1 . addPoint ( middleX , middleY + s ize / 2) ;

po in ts1 . addPoint ( middleX , middleY − s ize / 2) ;22

/ / second t r i a n g l e o f rewind symbol24 P o i n t L i s t po in ts2 = new P o i n t L i s t ( ) ;

po in ts2 . addPoint ( middleX , middleY ) ;26 po in ts2 . addPoint ( rewRect . x + rewRect . width , middleY + s ize / 2) ;

po in ts2 . addPoint ( rewRect . x + rewRect . width , middleY − s ize / 2) ;28


32 graphics . drawPolygon ( po in ts1 ) ;graphics . drawPolygon ( po in ts2 ) ;

34

graphics . f i l l P o l y g o n ( po in ts1 ) ;36 graphics . f i l l P o l y g o n ( po in ts2 ) ;


Code extract 8.6: StepPainter.java: paintCompensation() method

Also a conditional Step is visualized. The code to do that is very simple compared to theother properties being visualized. The only thing we need to do is to check whether theMinInstance property is set to �zero�, i.e. the Step is conditional or to �one�, i.e. the Step isnot conditional. In the Code extract 8.7 this is done in the lines 11 and 13. In the casewhere the Step is conditional the line of the StepFigure is represented dashed, whereas theline for mandatory steps is solid.

/∗ ∗2 ∗ Cal led dur ing the p a i n t i n g o f the step f i g u r e . Checks i f the

∗ step i s a c o n d i t i o n a l step and makes the step dashed .4 ∗

∗ @param graphics6 ∗ @generated NOT

∗ /8 private void paintDashedLine ( Graphics graphics ) {

Step step = ( Step ) ( ( View ) getModel ( ) ) . getElement ( ) ;10 StepFigure f i g = th is . getPrimaryShape ( ) ;

i f ( step . getMinInstances ( ) . g e t L i t e r a l ( ) . equals ( " zero " ) ) {12 f i g . se tL ineS ty l e (SWT. LINE_DASH) ;

} else i f ( step . getMinInstances ( ) . g e t L i t e r a l ( ) . equals ( " one " ) ) {14 f i g . se tL ineS ty l e (SWT. LINE_SOLID ) ;

}16 }

Code extract 8.7: StepEditPart.java: paintConditional() method

External Label instantiationCondition The instantiationCondition that is displayed at thetop right of the StepFigure is graphically de�ned as an external label. A default propertyof the external label is, that it can be freely moved around the �gure. For GAME it hasto be �x at the top right of the StepFigure.To achieve that the method createLayoutEditPolicy of the StepEditPart class has to be cus-tomized. Code extract 8.9 shows that method. An external label in the graphical de�ni-tion is represented as a border item for the �gure concerned. So we have to disable thepossibility to drag that border item (line 13). Of course this has only to be done for aninstance of IBorderItem, as can be seen in line 9.



3 ∗ /protected Layou tEd i tPo l i cy c rea teLayou tEd i tPo l i cy ( ) {

5 Layou tEd i tPo l i cy lep = new Layou tEd i tPo l i cy ( ) {

7 protected E d i t P o l i c y c r e a t e C h i l d E d i t P o l i c y ( Ed i tPa r t c h i l d ) {/ / cus tomiza t ion

9 i f ( c h i l d instanceof IBo rde r I t emEd i tPa r t ) {/ / r e t u r n new Borde r I t emSe lec t i onEd i tPo l i cy ( ) ;

11 / / d i sab le t h a t the l a b e l can be movedBorde r I t emSe lec t i onEd i tPo l i cy ep = new Borde r I t emSe lec t i onEd i tPo l i cy ( ) ;

13 ep . setDragAllowed ( fa lse ) ;return ep ;

15 }/ / cus tomiza t ion end

17 E d i t P o l i c y r e s u l t = c h i l d. g e t E d i t P o l i c y ( E d i t P o l i c y .PRIMARY_DRAG_ROLE) ;

19 i f ( r e s u l t == nul l ) {r e s u l t = new NonResizableEdi tPo l icy ( ) ;

21 }return r e s u l t ;

23 }

25 protected Command getMoveChildrenCommand ( Request request ) {return nul l ;

27 }

29 protected Command getCreateCommand ( CreateRequest request ) {return nul l ;

31 }} ;

33 return lep ;}

Code extract 8.8: StepEditPart.java: createLayoutEditPolicy() method

In a next step the placement of that BorderItem has to be set. This is done with thecustomized addBorderItem �gure, that is also situated in the StepEditPart. Code extract 8.9shows that method. The placement of the border item is only ruled, if it is an instanceof StepInstantiationConditionEditPart this is checked in line 10. To set the placement we needa BorderItemLocator instance, for which we override the relocate method in such a way thatthe border item is placed where we want (lines 16 to 27).With these changes we placed the external label at the top right of the StepFigure and itcannot be moved from there anymore. What remains is to set the square brackets aroundthe label text.


3 ∗ //∗

5 ∗ Method t h a t de f ines the placement o f the border i tem i n our case the∗ ex te rna l l a b e l f o r ho ld ing the step i n s t a n t i a t i o n c o nd i t i on

7 ∗ /protected void addBorderItem ( IF igu re borderI temContainer ,

9 IBo rde r I t emEd i tPa r t bo rder I temEd i tPar t ) {i f ( bo rder I temEd i tPar t instanceof S t e p I n s t a n t i a t i o n C o n d i t i o n E d i t P a r t ) {

11 / / cus tomiza t ion/ / l o c a t o r . se tBorder I temOf fse t (new Dimension(−20, −20) ) ;

13

Border I temLocator l o c a t o r = new Border I temLocator ( getMainFigure ( ) ) {15

@Override17 public void r e l oca te ( IF i gu re borderI tem ) {

Rectangle bounds = getParentF igure ( ) . getBounds ( ) ;19

Poin t pos = new Poin t ( ) ;21


pos . x = bounds . x + bounds . width / 2 + 5;23 pos . y = bounds . y − 25;

25 borderI tem . setBounds (new Rectangle ( pos , border I tem. ge tPre fe r redS ize ( ) ) ) ;

27 }} ;

29 / / end cus tomiza t ionborder I temConta iner . add ( border I temEd i tPar t . ge tF igure ( ) , l o c a t o r ) ;

31 } else {super . addBorderItem ( borderI temContainer , bo rder I temEd i tPar t ) ;

33 }}

Code extract 8.9: StepEditPart.java: addBorderItem() method

The square brackets are set in the StepInstantiationConditionEditPart in a similar way asthe symbols were set in the StepEditPart. As in the StepEditPart we have to override theGraphics.paint method for the StepInstantiationConditionLabelFigure. In that method �rst theparent is painted and then the paintInstantiationCondition is called. The paintInstantiationCon-dition method checks whether the instantiationCondition is set and if it is set, it calls theStepPainter.paintInstantiationConditionLabel method. Refer to Appendix C to see how this isdone exactly. Code extract 8.10 only shows the StepPainter.paintInstantiationConditionLabelmethod.As for the other �gures that were customized �rst the current state of the �gure is pushedon a stack (line 11). Once the square brackets were added, the state before is popped ofthe stack and is restored with the added brackets.In lines 12 to 18 some local variables are set, for instance for de�ning the padding betweenthe text and the brackets. Next the color for the brackets is de�ned to be black. Theopening bracket is then constructed from lines 30 to 36 and the closing bracket in thelines 45 to 51. This is already all that has to be done for adding the squared brackets tothe label.

/∗ ∗2 ∗ Pain ts the squared brackets arround the i n s t a n t i a t i o n c o nd i t i on l a b e l




public s t a t i c void p a i n t I n s t a n t i a t i o n C o n d i t i o n L a b e l ( Graphics graphics , Rectangle r e c t ) {10

graphics . pushState ( ) ;12 i n t paddingX = 1;

i n t paddingY = 2;14 i n t x = r e c t . x + paddingX ;

i n t y = r e c t . y + paddingY ;16 i n t he igh t = r e c t . he igh t − 2∗paddingY ;

i n t width = r e c t . width − 2∗paddingX ;18 i n t wSize = 7;

20 graphics . setForegroundColor ( ColorConstants . b lack ) ;graphics . setBackgroundColor ( ColorConstants . b lack ) ;

22

/∗ l e f t square bracket24 ∗ p2 p1

∗ |−−−−−−26 ∗ |

∗ |−−−−−−28 ∗ p3 p4

∗ /30 Poin t p1 = new Poin t ( x + wSize , y ) ;

Po in t p2 = new Poin t ( x , y ) ;

8.3. Linking with OMS Artifacts 88

Figure 8.10.: Dialog for referencing the activity whithin OMS

32 Poin t p3 = new Poin t ( x , y + he igh t ) ;Po in t p4 = new Poin t ( x + wSize , y + he igh t ) ;


36 graphics . drawLine ( p3 , p4 ) ;

38 /∗ r i gh t squa re bracket∗ p5 p6

40 ∗ −−−−−−|∗ |

42 ∗ −−−−−−|∗ p8 p7

44 ∗ /Po in t p5 = new Poin t ( x + width − wSize , y ) ;

46 Poin t p6 = new Poin t ( x + width , y ) ;Po in t p7 = new Poin t ( x + width , y + he igh t ) ;

48 Poin t p8 = new Poin t ( x + width − wSize , y + he igh t ) ;graphics . drawLine ( p5 , p6 ) ;


52


}

Code extract 8.10: StepPainter.java: paintInstantiationConditionLabel() method

8.3. Linking with OMS Artifacts

As mentioned in Chapter 3 the Steps are implemented with either an Activity or a Flow.Also these have to be de�ned somewhere in the system. So GAME needs to be able toreference that implementations. This is done with a dialog that pops up. This sectionexplains how we achieve that these dialogs pop up in the right moment.

8.3.1. Custom Dialogs

GAME had to be linked with the artifacts that are already present in OMS. This is donewith the help of two custom dialogs. One fetches the reference of the Activity function that


Figure 8.11.: Dialog for referencing the �ow within OMS

has to be executed, the other one references the Flow to execute. Figures 8.10 and 8.11show the Activity- and the FlowSelectionDialog respectively.

Embedding Both dialogs are embedded in the same way. Each property of an elementhas a so called PropertyDescriptor which de�nes how that property is represented in theProperties View of the graphical editor. That PropertyDescriptor had to be customizedin such a way, that a dialog pops up in order to edit that property. That CustomizedProp-ertyDescriptor extends PropertyDescriptor. In order that this customized property descriptoris called, a CustomizedPropertySource has to be provided as well. This class is not veryinteresting however, since all it does is call the CustomizedPropertyDescriptor. Refer to Ap-pendix C to see all the custom classes.To build the link to the generated code, you have to customize the GamePropertySectionclass that can be found in the game.diagram.sheet package of the diagram plug-in. All youhave to do is return your CustomizedPropertySource as you can see in Code extract 8.11 inline 15.

/∗ ∗2 ∗ @generated NOT

∗ /4 public IProper tySource getPropertySource ( Object ob jec t ) {

i f ( ob jec t instanceof IProper tySource ) {6 return ( IProper tySource ) ob jec t ;

}8 AdapterFactory a f = getAdapterFactory ( ob jec t ) ;

i f ( a f != nul l ) {10 I I temProper tySource ips = ( I I temProper tySource ) a f . adapt ( ob jec t ,

I I temProper tySource . class ) ;12 i f ( i ps != nul l ) {

/ / cus tomiza t ion14 / / r e t u r n new PropertySource ( ob jec t , i ps ) ;

return new CustomizedPropertySource ( ob jec t , i ps ) ;16 / / cus tomiza t ion end

}18 }

i f ( ob jec t instanceof IAdaptable ) {20 return ( IProper tySource ) ( ( IAdaptable ) ob jec t )

. getAdapter ( IProper tySource . class ) ;22 }

return nul l ;


24 }

Code extract 8.11: GamePropertySection.java: getPropertySource()

ActivitySelectionDialog More interesting is the customized property source which isvisible in Code extract 8.12. This code extract shows how this property descriptor setsup the dialog if the treated property is an Activity.

1 i f ( ob jec t instanceof A c t i v i t y ) {i f ( eType instanceof EDataType ) {

3 EDataType eDataType = ( EDataType ) eType ;i f ( eDataType . get Ins tanceClass ( ) == S t r i n g . class ) {

5 r e s u l t = new ExtendedDia logCel lEd i to r ( composite ,ge tEd i tLabe lP rov ide r ( ) ) {

7 protected Object openDialogBox ( Cont ro l ce l lEd i torWindow ) {/ / c reate an new a c t i v i t y d ia log ins tance

9 A c t i v i t y S e l e c t i o n D i a l o g d ia log = new A c t i v i t y S e l e c t i o n D i a l o g (ce l lEd i torWindow . ge tShe l l ( ) ,

11 ce l lEd i torWindow . getParent ( ) ) ;

13 d ia log . c reate ( ) ;

15 i f ( d ia log . open ( ) == Window .OK) {Object d ia logResu l t = d ia log . getResu l t ( ) [ 0 ] ;

17 i f ( d ia logResu l t instanceof Act iv i t yFunc t ionWrapper ) {Ac t i v i t yFunc t ionWrapper wrap = ( Ac t i v i t yFunc t ionWrapper ) d ia logResu l t ;

19 S t r i n g res = wrap . g e t A c t i v i t y ( ). getAct iv i tyName ( )

21 + " : "+ wrap . getFunct ion ( )

23 . getFunctionName ( ) ;return res ;

25 }return nul l ;

27 }return nul l ;

29 }} ;

31 }}

33 }

Code extract 8.12: CustomizedPropertyDescriptor.java: createPropertyEditor() for Activity

So in the �rst line of that code extract we check whether the treated object is an Activity.The dialog for choosing the Activity function is set up in the lines 5 to 13. The next linesuntil line 27 check whether the result returned by the dialog is of the expected type andrender it for output.Code extract 8.13 and 8.14 show code extracts for the ActivitySelectionDialog.For the ActivitySelectionDialog the SelectionDialog was extended. What is special about thateditor is the �lter. This �lter was added using a FilteredTree with a customized PatternFiterthat allows �ltering for Activity names and functions. Code extract 8.13 shows how this isachieved. The dialog is then easy to set up. The constructor of the ActivitySelectionDialogcalls the method createDialogArea which is visible in Code extract 8.14.

P a t t e r n F i l t e r p a t t e r n F i l t e r = new P a t t e r n F i l t e r ( ) {2

@Override4 public boolean i sE lemen tV i s ib l e ( Viewer viewer , Object element ) {

return matchesObjectName ( element ) ;6 }

8 private boolean matchesObjectName ( Object element ) {i f ( element instanceof Ac t i v i t yRe fe rence ) {


10 Ac t i v i t yRe fe rence a c t i v i t y = ( Ac t i v i t yRe fe rence ) element ;return wordMatches ( a c t i v i t y . getAct iv i tyName ( ) )

12 | | funct ionMatches ( a c t i v i t y ) ;}

14 else i f ( element instanceof Act iv i t yFunc t ionWrapper ) {Ac t i v i t yFunc t ionWrapper wrap = ( Ac t i v i t yFunc t ionWrapper ) element ;

16 return wordMatches ( wrap . getFunct ion ( ) . getFunctionName ( ) )| | wordMatches ( wrap . g e t A c t i v i t y ( ) . getAct iv i tyName ( ) ) ;

18 }return fa lse ;

20 }

22 / / r e tu rns t rue i f one the a c t i v i t i e s f u n c t i o n s matchprivate boolean funct ionMatches ( Ac t i v i t yRe fe rence a c t i v i t y ) {

24 for ( Ac t i v i t yFunc t i onRe fe rence f u n c t i o n : a c t i v i t y . g e t A c t i v i t y F u n c t i o n s ( ) ) {i f ( wordMatches ( f u n c t i o n . getFunctionName ( ) ) ) {

26 return true ;}

28 }return fa lse ;

30 }} ;

32 p a t t e r n F i l t e r . se t Inc ludeLeadingWi ldcard ( true ) ;

34 F i l t e re dT re e f i l t e r e d T r e e = new F i l t e re dT re e ( parent , s t y l e B i t s , p a t t e r n F i l t e r ) ;

36 / / setup the t ree viewerTreeViewer t reeViewer = f i l t e r e d T r e e . getViewer ( ) ;

38 t reeViewer . se tLabe lProv ider (new A c t i v i t y F u n c t i o n L a b e l P r o v i d e r ( ) ) ;t reeViewer . se tContentProv ider (new Ac t i v i t yFunc t i onTreeCon ten tP rov ide r ( ) ) ;

40 t reeViewer . se tSo r te r (new ViewerSor ter ( ) ) ;

Code extract 8.13: ActivitySelectionDialog.java: PatternFilter

In line 11 of Code extract 8.14 the dialog area for the parent SelectionDialog is created,then the method createFilteredTreeViewer is called in line 13. Code extract 8.13 is actuallyan extract from that createFilteredTreeViewer method. Form lines 34 to 40 you can see howthat �ltered tree is composed, with the customized pattern �lter that may be found inthe lines 1 to 32 in that extract. If you want to see exactly how the ActivitySectionDialogwas implemented go to Appendix C, which shows the whole code of all the classes thatwere written by the author.

/∗ ∗2 ∗ Creates and re tu rns the contents o f the upper pa r t o f t h i s d ia log ( above

∗ the but ton bar ) .4 ∗

∗ @param parent6 ∗ the parent composite to conta in the d ia log area

∗ @return the d ia log area c o n t r o l8 ∗ /

@Override10 protected Cont ro l createDia logArea ( Composite parent ) {

Composite composite = ( Composite ) super . c reateDia logArea ( parent ) ;12

c rea teF i l t e redTreeV iewer ( composite ) ;14

return composite ;16 }

Code extract 8.14: ActivitySelectionDialog.java: createDialogArea()

FlowSelectionDialog The FlowSelectionDialog is much simpler since is has no tree struc-ture. This makes it possible that ElementListSelectionDialog can be extended which itselfprovides already all the functionality. Code extract 8.15 shows the FlowSelectionDialog.

8.4. Step Name used as ID 92

Because there are lot of Flows and Activities de�ned in OMS a so called ProgressMonitor wasadded to both dialogs. This progress monitor shows the state of loading the references.In Code extract 8.15 you can see from line 26 to 34 how this is done. In line 32 all thede�ned �ow references are fetched. These are then set into the dialog in line 16. Themethod configureShell sets the size for the dialog and we are already done.

1 public class FlowSelec t ionDia log extends ElementL is tSe lec t ionD ia log implementsIRunnableWithProgress {

3 private L i s t _f lows ;

5 public FlowSelec t ionDia log ( She l l parent ) {super ( parent , new ClomCoreLabelProvider ( ) ) ;

7

/ / Get Flows9 t ry {

P la t fo rmUI . getWorkbench ( ) . getProgressServ ice ( ) . run ( true , true , th is ) ;11 } catch ( Invoca t ionTarge tExcept ion e ) {

/ / No Er ro r Handl ing here13 } catch ( I n te r rup tedExcep t i on e ) {

/ / No Er ro r Handl ing here15 }

th is . setElements ( _f lows . toAr ray ( ) ) ;17 }

19 @Overrideprotected void con f i gu reShe l l ( She l l s h e l l ) {

21 super . con f i gu reShe l l ( s h e l l ) ;s h e l l . se tS ize (300 , 400) ;

23 }

25 @Overridepublic void run ( IProgressMoni tor moni tor ) throws Invocat ionTargetExcept ion ,

27 I n te r rup tedExcep t i on {

29 / / Se lec t f lows :moni tor . beginTask ( "Read f low d e s c r i p t o r s . . . " , 1000) ;

31 F lowCo l lec to r f l o w C o l l e c t o r = S t e p I n f o C o l l e c t o r . ge t Ins tance ( ) . ge tF lowCo l lec to r ( ) ;_ f lows = f l o w C o l l e c t o r . getFlows ( moni tor ) ;

33 moni tor . done ( ) ;}

35 }

Code extract 8.15: FlowSectionDialog.java: FlowSectionDialog()

8.4. Step Name used as ID

Within OMS the unique name of a Step is at the same time used as its identi�er. For thegraphical editor this was di�cult since step names normally have spaces and GMF couldnot handle those spaces.So a way had to be found to get rid of that spaces. What we have done is, de�ning aStringWrapper which wraps, as the name already says, the string class and replaces everyspace character with a point character. In that way the Step name �A Step� is stored as�A.Step� in the XML model. Like this, this problem may be avoided.Code extract 8.16 shows the StringWrapper, that can be found in the customsrc folder ofthe com.swisscom.oms.plugins.game plug-in. You can see that it is a very simple class thatremoves every space character on construction, and adds them again when the String isprinted out, i.e. the method toString is called.

1 public class Str ingWrapper {

8.4. Step Name used as ID 93

Figure 8.12.: Properties View of the StringWrapper EDataType

3 private S t r i n g i d S t r i n g = "<Step Name>" ;

5 public Str ingWrapper ( S t r i n g s t r ) {th is . i d S t r i n g = s t r . rep lace ( " " , " . " ) ;

7 }

9 /∗ ∗∗ Returns the s t r i n g t h a t may be used as i d e n d i f i e r ( w i thou t spaces )

11 ∗∗ @return S t r i n g

13 ∗ /public S t r i n g g e t I d S t r i n g ( ) {

15 return i d S t r i n g ;}

17

@Override19 /∗ ∗

∗ Returns the o rd ina ry s t r i n g21 ∗ /

public S t r i n g t o S t r i n g ( ) {23 return i d S t r i n g . rep lace ( " . " , " " ) ;

}25

}

Code extract 8.16: StringWrapper.java

To be able to have that StringWrapper that is, for setting the label in the diagram repre-sented as a java.lang.String and behind the scenes as that StringWrapper object we had to doa little trick. In the ecore model we de�ned a new EDataType with the name StringWrapper.Then we de�ned that this new type is derived from the java.lang.Object. Like this we havethe �exibility to handle it as that object as we need in the speci�c context. Figure 8.12shows how this is done in the Properties View.The methods createStringWrapperFromString and convertStringWrapperToString of the Game-FactoryImpl have in a second step to be adapted in order to return the newly de�nedStringWrapper instead of an ordinary object. Code extract 8.17 shows how this is done.

1 /∗ ∗∗ <!−− begin−user−doc −−>

3 ∗ <!−− end−user−doc −−>∗ @generated NOT

5 ∗ // / p u b l i c Object createStr ingWrapperFromStr ing ( EDataType eDataType , S t r i n g i n i t i a l V a l u e ) {

7 / / r e t u r n super . createFromStr ing ( eDataType , i n i t i a l V a l u e ) ;/ / }

9 / / cus tomiza t ion : r e t u r n a Str ingWrapper ob jec tpublic Str ingWrapper createStr ingWrapperFromStr ing ( EDataType eDataType , S t r i n g i n i t i a l V a l u e )

{11 return new Str ingWrapper ( i n i t i a l V a l u e ) ;

8.5. Remove Standard Helper Tools 94

}13 / / cus tomiza t ion end

15 /∗ ∗∗ <!−− begin−user−doc −−>

17 ∗ <!−− end−user−doc −−>∗ @generated NOT

19 ∗ /public S t r i n g conver tSt r ingWrapperToStr ing ( EDataType eDataType , Object instanceValue ) {

21 / / r e t u r n super . conver tToSt r ing ( eDataType , instanceValue ) ;/ / cus tomiza t ion

23 S t r i n g s t r = nul l ;i f ( eDataType . getName ( ) . equals ( " Str ingWrapper " ) ) {

25 /∗ when the step i s newly created we f i r s t have to create the Str ingWrapper ob jec t∗ wi th the provided S t r i n g and then we can r e t u r n the i d S t r i n g

27 ∗ /i f ( instanceValue instanceof S t r i n g ) {

29 Str ingWrapper s t r 4 i d = createStr ingWrapperFromStr ing ( eDataType , ( S t r i n g ) instanceValue) ;

s t r = s t r 4 i d . g e t I d S t r i n g ( ) ;31 }

/∗ when the diagram i s closed and reopened we al ready have the S t r i n g f o r ID33 ∗ ob jec t and j u s t have to r e t u r n the i d S t r i n g

∗ /35 i f ( instanceValue instanceof Str ingWrapper ) {

s t r = ( ( Str ingWrapper ) instanceValue ) . g e t I d S t r i n g ( ) ;37 }

}39 return s t r ;

/ / cus tomiza t ion end41 }

Code extract 8.17: GameFactoryImpl.java: customized methods

8.5. Remove Standard Helper Tools

GMF provides by default helper tools that should help the developer. While testingGAME these helpers were perceived as bothersome. This is why they were removed.This section describes how this is done.

8.5.1. Remove Pop Up Bar

One of that helper tools is a pop up bar, which appears on the canvas and within �guresthat may contain child �gures. With the help of the pop up bar elements that can bedrawn directly on the canvas may be added. At Swisscom IT Services however we hadthe feeling that they pop up quite randomly, so we decided to remove them. This is doneas follows:Add the line of code in Code extract 8.18 at line 12 to the createDefaultEditPolicies methodof the GAMEContextEditPart and the StepEditPart classes. But as you can see in the codeextract it is highly probable that the speci�c line of code is already present and you justhave to uncomment it.

/∗ ∗2 ∗ @generated NOT

∗ /4 protected void c r e a t e D e f a u l t E d i t P o l i c i e s ( ) {

super . c r e a t e D e f a u l t E d i t P o l i c i e s ( ) ;6 i n s t a l l E d i t P o l i c y ( Ed i tPo l i cyRo les .SEMANTIC_ROLE,

new GAMEContextItemSemanticEditPolicy ( ) ) ;8 i n s t a l l E d i t P o l i c y ( Ed i tPo l i cyRo les .CANONICAL_ROLE,

8.6. Code Generation 95

new GAMEContextCanonicalEditPolicy ( ) ) ;10 / / cus tomiza t ion : uncomment the f o l l o w i n g l i n e

/ / removeEdi tPol icy ( org . ec l i pse . gmf . runt ime . diagram . u i . e d i t p o l i c i e s . Ed i tPo l i cyRo les .POPUPBAR_ROLE) ;

12 removeEdi tPol icy ( org . ec l i pse . gmf . runt ime . diagram . u i . e d i t p o l i c i e s . Ed i tPo l i cyRo les .POPUPBAR_ROLE) ;

/ / cus tomiza t ion end14 }

16 }

Code extract 8.18: GAMEContextEditPart.java: createDefaultEditPolicies()

8.5.2. Remove Connection Helpers

With a connection helper elements that may linked with the concerned �gure can directlybe added. As for GAME every Step may be linked with an other, these helpers appearall the time, which is not very pleasant. To remove that tool add the line of code thatcan be seen in Code extract 8.19 in line 3 to the createDefaultEditPolicies method of thefollowing classes:

• ActivityEditPart

• FlowEditPart

• HasResultPredecessorConditionEditPart

• PredecessorRelationPart

• SimplePredecessorConditionEditPart

• StepEditPart

Also for the connection helpers it is very probable that this line of code is already presentbut commented, so just uncomment it.

1 / / cus tomiza t ion : uncomment the f o l l o w i n g l i n e/ / removeEdi tPol icy ( org . ec l i pse . gmf . runt ime . diagram . u i . e d i t p o l i c i e s . Ed i tPo l i cyRo les .

CONNECTION_HANDLES_ROLE) ;3 removeEdi tPol icy ( org . ec l i pse . gmf . runt ime . diagram . u i . e d i t p o l i c i e s . Ed i tPo l i cyRo les .

CONNECTION_HANDLES_ROLE) ;/ / cus tomiza t ion end

Code extract 8.19: StepEditPart.java: createDefaultEditPolicies()

8.6. Code Generation

Because most of the code can be generated automatically this section describes how thecode for GAME may be generated using only the con�guration �les. The CD-ROMdelivered with this paper (see Appendix G) contains a generation/model folder containingall the con�guration and generation �les. Follow the steps below to get the four plug-insthat are needed for running GAME:

• Create a new GMF Project (New -> Other... -> GMF Project) and name itcom.swisscom.oms.plugins.game

• Replace the model folder in the project with the provided one

• Generate Code

8.7. Embedding 96

� Open game.genmodel, right-click the root element and chooseGenerate ModelCode, Generate Edit Code and Generate Editor Code

� Right-click the structure.gmfgen �le and choose Generate diagram code

• Add custom sources (provided in the generation/sources folder)

� Add the folder customsrc (found in the generation/sources/game.diagram folder)to the game.diagram plug-in and specify it as a second source folder (Plug-inproperties -> Java Build Path -> Source tab -> Add folder button)

� Add the folder customsrc (found in the generation/sources/game folder) to thegame plug-in and specify it as a second source folder (Plug-in properties ->Java Build Path -> Source tab -> Add folder button)

� Replace the generated �le with the custom �les StepEditPart.java and StepInstan-tiationConditionEditPart.java in the game.edit.parts package of the diagram plug-in(the �les can be found in the game.diagram/customized files folder)

� Replace the generated �le in the game.sheet package of the diagram plug-inwith the custom �le GamePropertySection.java that can be found in the samefolder than be others before

� Replace the generated �le in the game.impl package with the custom �le Game-FactoryImpl.java that can be found in the game/customized files folder

• To be sure that the generated parts are still up to date regenerate the code (thecustomizations are now persistent because of the @generated NOT annotations in thecustom classes)

� Go to the model folder within the core plug-in and open the game.genmodel �le,then right-click the root node and Generate Model Code and GenerateEdit Code

� Right-click the structure.gmfgen that can be found in the same folder and Gen-erate diagram code

� Follow the instructions in Section 8.5, these customization are done quicklyand therefore have to be done by the user

• Unzip the dummy.zip plug-in to your Eclipse installation folder add the com.swisscom.oms.plugins.clom.coreplug-in to the dependencies (plugin.xml) of the game.diagram plug-in

Now you have generated all the code that is necessary for GAME.

8.7. Embedding

The embedding of GAME with the existing system was out of scope for this MasterThesis. Nevertheless we will shortly explain the plug-ins that are used for embeddingGAME.

OMS Clom Core Plug-in This plug-in provides access to the list of Activities and Flows.It de�nes an extension point that allows other plug-ins to contribute Activity and Flow ref-erences. Additionally this plug-in contains dialogs to select Step implementations (Activityfunction or Flow version).

8.8. Challenges 97

OMS Step Info Dummy This plug-in contributes a list of dummy Activities and Flowsto the before mentioned extension point. It is useful for demonstration purposes, if thereis no OMS workspace available. OMS developers will have another plug-in that buildsthe list of Activities and Flows from the Eclipse workspace.

8.8. Challenges

This chapter lists in a few paragraphs the major challenges that we were confronted withduring the elaboration of GAME.

Understanding GMF is a powerful framework, with all the advantages and disadvan-tages powerful framework have. Already the con�guration �les are very powerful toolso�ering a lot of possibilities, so it took quite a while to understand what can be con�guredin which way.Once the con�guration �les understood, code gets generated and again one is confrontedwith a huge mountain of new stu�. Now exploration starts by changing a little thingin the con�guration �les and analyzing what e�ect these changes have on the Java codethat gets generated.To wrap it up we can say, that it takes quite a long time to see how the graphical editormay be con�gured and to understand the code that gets generated.

Find Hooks Once the con�guration �les and the generated code are understood, verysoon comes the wish of customizing certain things. The GMF community thought of thatwish and provided hooks to add such customization.Because the generated code is structured and sophisticated it would be silly to spoil thatby just hacking the customizations somewhere into the code. But the problem is thatthese hooks �rst have to be found. Since almost no documentation is available, one spendsa lot of time with searching in the code and on the Internet for a solution.

Modeling of the Predecessor Relation The modeling of the process structure as suchwas no problem. Only with the decision to introduce the DefaultPredecessorRelation, inorder to simplify the model, things started to be a bit more complicated.The problem was how to model those two characteristics of a PredecessorRelation, this isthe customizable one and the default one. We �rst tried to model it as two EClasses,which both are sub class of a general PredecessorRelation. But like this it could not bedrawn on the canvas anymore.It took quite a while to �nd out that, if we want that both the DefaultPredecessorRelationand the customizable one can be drawn on the canvas, both need to be known by thecanvas, i.e. the GAMEContext. Once this insight gained the implementation afterwardswas easy.

Step Name used as ID A major challenge was also that within OMS the Step nameis at the same time used as its identi�er. As such this is no problem. The problem cameup, when we realized, that GMF does not allow space characters for identi�ers. The

8.8. Challenges 98

step names however have spaces. So we had to �nd a solution how to over go this issue.Section 8.4 shows which measures were taken.

8.8. Challenges 99

Figure 8.13.: Graphical De�nition of GAME part 2: showing only the Figure Gallery

9Using Game

9.1. Development Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 100

9.2. The Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

9.3. Modeling Sightseeing Tour . . . . . . . . . . . . . . . . . . . . . 103

9.3.1. Meaning of Step Markers . . . . . . . . . . . . . . . . . . . . . 106

9.3.2. Customizable Predecessor Relation . . . . . . . . . . . . . . . . 107

9.4. Usability of GAME . . . . . . . . . . . . . . . . . . . . . . . . . 107

This chapter introduces the reader into the usage of GAME. Refer to Appendix B tosee the set up to follow for using GAME. First we have a look at the development cycleat Swisscom. Then the tools that are available in the palette of the editor visible at theright in Figure 9.1 are described.Once we know all the tools, we will introduce the usage of GAME by modeling thesightseeing tour from Section 3.6. This chapter concludes with an overview of the usabilityof GAME.

9.1. Development Cycle

At �rst sight the developer will not remark GAME. The development routine stays almostthe same. The �ow developer opens the Flow Descriptor (flow.xml), de�nes Aspects, andcombines Aspects to Flows. However, when de�ning Aspects it is now possible to attach anaspect model, as you can see in the Flow Descriptor Editor in Figure 9.2 in the red box.From here the developer can also generate a new *.game �le. The attached aspect model�le can be opened from within the Flow Descriptor editor with the help of the dialogvisible in Figure 9.3 on page 103. The dynamic part of the process is still de�ned using arule �le (*.ilr). Underneath the GAME part in that Flow Descriptor Editor you can see howthese rules can be referenced.

9.2. The Tools

This section describes the tools that are provided to the user in the palette and explainshow they work with each other.

100

9.2. The Tools 101

Figure 9.1.: Graphical Aspect Model Editor

Figure 9.4 on page 104 shows the palette that is available in GAME. The following listexplains each tool:

• Step With this tool a Step is created. It can be placed directly on the canvas.Figure 9.8 on page 106 shows some Steps that were described in Subsection 6.2.1with the GAME representation. The name of the Step may be speci�ed throughthe Properties View or directly at creation or by clicking on the name.The Step named Fourth Step in Figure 9.8 is a conditional Step, this is why itsoutline is dashed and the condition is visible at the top right in square brackets.

• Activity This tool de�nes that the implementation of the Step is an Activity. It mayonly be placed in the blue part of the StepFigure, see Figure 8.6 on page 79. InFigure 9.8 the First and the Third Step represent an Activity. The Third Step is inaddition to having an Activity implementation, a multi instance Step (pause symbol)and a compensation Step (rewind symbol).The reference of an Activity may only be speci�ed through the dialog that can byopened in the Properties View.

• Flow Creates a Flow implementation, as for the Activity tool the creation of a Flowimplementation is only possible within the bottom part of a Step (blue part in

9.2. The Tools 102

Figure 9.2.: Flow Descriptor Editor with integrated GAME

Figure 8.6). The Second and the Fourth Step in Figure 9.8 show how Flows arevisualized in GAME. You can see that the plus symbol at the bottom distinctsa Flow form an Activity. Similar to the Activity, the reference of a Flow may only bespeci�ed through the dialog that pops up from the Properties View.

• Default Predecessor Relation This tool creates a simple arrow from the pre-decessor to the successor, such a DefaultPredecessorRelation is visible in Figure 9.9on page 106 on the left. As described in section 6.2.3 this DefaultPredecessorRelationrepresents the case illustrated in Figure 6.7 on page 56. This is, if the process isbeing executed in �forward motion� First Step on Figure 9.9 needs to have com-pleted all its work before Second Step can begin. And in the case where the processneeds to be canceled �backward motion� Second Step needs to have rolled back allits e�ected tasks before the First Step, can begin to roll back its e�ected tasks. Theonly properties that may be set for a DefaultPredecessorRelation is its source and itstarget, i.e its predecessor and its successor.

• Predecessor Relation This tool creates the rectangle visible on Figure 9.9 on theright, within that rectangle the PredecessorCondition may be placed. The propertiesof this rectangle tell which are its predecessor and successor.

• Link Predecessor As the name suggests this tool links the PredecessorRelationrectangle with the predecessor of the relation. This linker has no properties.

• Link Successor This tool links the PredecessorRelation with the successor of therelation. This linker has no properties.

9.3. Modeling Sightseeing Tour 103

Figure 9.3.: Dialog that allows to open an existing *.game �le

• Simple Predecessor Condition The SimplePredecessorCondition de�nes the condi-tion for a customized PredecessorRelation. In the Properties View one can specifythe operation and the condition that has to be ful�lled, with the help of selec-tion lists. Figure 9.9 shows at the right such a SimplePredecessorCondition for theoperation �ful�ll� and the condition �failed�.

• Has Result Predecessor Condition This tool de�nes a has result condition fora customized PredecessorRelation. In the Properties View one can specify theoperation and the result name. The operation is also provided through a selectionlist, the result name is a simple string.

9.3. Modeling Sightseeing Tour

The previous section introduced all the tools. This section now shows how the sightseeingtour from Section 3.6 is modeled using GAME. We will not model the whole sightseeingtour however, the tour that is modeled here contains the Castle, the Bridge, the Opera inthe case where the tourist group booked the �Gold Option�, the Market Hall and �nallythe Church under the condition that the tourist group booked the �Gold Option� again.What is going to be drawn is shown in Figure 9.1.

Create Mandatory Steps We will begin by de�ning all the Steps that are present inthe sightseeing tour. The �rst Step that we are going to de�ne is the Step Castle. Goto the palette and click on the Step tool. Now come back to the canvas and draw arectangle. You can see a blue StepFigure appear. Name that Step Castle. You can do soby either directly entering the name after creation or with the help of the Properties


Figure 9.4.: The tools palette of GAME

Figure 9.5.: Properties View of the Castle Step

View. Figure 9.5 shows the properties set for that Step.What remains to do now for that Step is to de�ne its implementation. So go to thepalette again an choose the Activity tool. Place it within the Castle Step. To set thereference go down to the Properties View and click on the botton that appears if clickinto the reference �eld. A Dialog pops up. Developers at Swisscom can now choose theVisitationActivity for the Castle. If you only have the test environment, just chooseone of the dummy functions.Now we have de�ned the �rst Step. Do now the same thing for the Steps Bridge andMarket Hall.

Create Optional Steps For de�ning an optional Step almost everything stays the same.Again you choose the Step tool in the palette and draw the Step. Then you set the nameas you have done before. To make the Step optional go down to the Properties Viewand set MinInstances to zero instead of the default value one. You will notice that theStep will get a dashed outline. Then go up to the InstantiationCondition �eld andwrite �Gold Option�. The Properties View should now look like the one in Figure 9.7.To set the implementation the procedure is the same as before. Go to the palette choosethe Activity tool and place it within the Step. With the help of the dialog set either theaccording Activity form the OMS workspace or choose a dummy implementation if you are


Figure 9.6.: Properties View for specifying implementation references

Figure 9.7.: Properties View of the Opera Step

working with the test environment. Do exactly the same for the Church Step.For the Emergency Step the procedure is almost the same. Here the only di�erence is,that its implementation is a Flow so instead of choosing an Activity tool from the palettechoose the Flow tool and place it within the Step as you did before with the Activity.Again you can set the reference with the dialog that pops up from the reference �eld inthe Properties View. Choose a dummy Flow if you are using the test environment orthe Emergency Flow Version 1 if you have the Swisscom environment available.

De�ne Sequence of Steps With the previous two paragraphs we de�ned the Steps andunder which condition they are needed. The rules that tell whether an optional Step isrequired or not are not described here. The aim of this chapter is to show how to useGAME.Let us now de�ne the sequence of these Steps with the help of the Predecessor Relationtool. As the Castle is the �rst monument we want to see, this Step has no predecessorand can be started immediately. After the Castle we want to see the Bridge. This iswhy, we need a PredecessorRelation between the Castle and the Bridge, where Castle is thepredecessor and Bridge is the successor. To draw this go to the palette and choose thePredecessor Relation tool. Then go with the arrow of the mouse to the bottom of theCastle Step. As soon as the empty set symbol disappears, click into the Castle. Step anddrag a line to the Bridge Step. You have de�ned your �rst PredecessorRelation. Do nowthe same thing for all the other Steps, in the end it should look like the model displayedin the editor on Figure 9.1 on page 101.The Emergency Step has no predecessor relations. The rule that stands behind thatoptional Step de�nes its relationship to all the others.


Figure 9.8.: Step representation of GAME

Figure 9.9.: Predecessor Relations in GAME

9.3.1. Meaning of Step Markers

Although the markers that decorate the Steps for visualizing its properties were alreadyexplained, let us give an example for each in correspondence with the sightseeing tour.This may help to understand the meaning better.If we have a look at the First Step in Figure 9.8, we consider that there is no specialmarker. This Step represents a Step that is executed for every process instance. It has anActivity implementation and thus is an abstraction of a service call.The Second Step represents a Flow implementation, i.e. this Step executes a Subflow. Inthe sightseeing example the Emergency Step is such an example. If the Step Emergencyis executed a Subflow is started, which consists in calling in the Step Call Ambulance andthen waiting in the Step Wait until the ambulance arrives. Figure 3.10 on page 22 showsthat Subflow in the sightseeing example. What you can see in GAME is the reference tothat Subflow.The Third Step is a multi instance and compensation Step. The instantiationCondition tellshow many of these Steps are needed. For the sightseeing tour an example is the following:give each tourist its money back in the case where the sightseeing tour does not takeplace.The Fourth Step represents a conditional Step. It is only executed if the rule that stands

9.4. Usability of GAME 107

behind requires this Step. In the sightseeing tour the Steps Opera and Church are suchconditional Steps, which are only executed, if the tourist group has booked the �GoldOption�.

9.3.2. Customizable Predecessor Relation

Figure 6.7 on page 56 shows the DefaultPredecessorRelation without simpli�cation. TheDefaultPredecessorRelation represents the case where the predecessor has to have completedbefore the successor may start in forward motion, and the successor has to have rolledback all of its work before the predecessor may start in backward motion.As mentioned earlier, it is also possible to customize the PredecessorRelation. Figure 9.9shows a customized one. The meaning of this PredecessorRelation is the following:The Fourth Step is only executed in forward motion if the Third Step fails. Table 6.2 onpage 56 shows which other conditions are possible. The operations that are supportedare:

• Ful�ll This PredecessorRelation has to be taken into account if the process is inforward motion.

• Cancel If the operation is cancel, this PredecessorRelation has to be taken intoaccount in backward motion.

• Abort The abort operation de�nes PredecessorRelations that have to be taken intoconsideration if the process is aborted.

• Nop This PredecessorRelation has to be taken into account if no of the other opera-tion holds.

9.4. Usability of GAME

Now we know how the tools of GAME have to be used. This section investigates theusability of that development tool.The graphical editors that are elaborated with the help of GMF look quite similar toother graphical editors. Like for almost every graphical editor a palette is provided,that contains all the tools for drawing on the canvas. This resemblance to other graphicaleditors makes the �rst touch with GAME quite straightforward. With some little changesto the default settings the usability can even be increased. In addition to that, a lot offunctionality is provided that makes GAME easy to use as well:

• One of these functionalities is a zoom, so even if a lot of Steps have to be de�ned,the developer may always zoom out, to get the big picture. Another handy thingin relation to that is the Overview View, that is provided. This view shows thedeveloper where in the painting he is situated at the moment.

• Because GAME is going to be used for documentation as well, we have to mention,that a handy noticing tool is included by default as well. With this tool one caneasily add notices and attach them to certain Steps. In Figure 10.1 on page 113,such notes can be seen in the GAME model at the right of the �gure.

• A third functionality that is very convenient is theAuto Arrange button. Imaginethe Steps de�ned by the developer are in a mess and not aligned accordingly. All the

9.4. Usability of GAME 108

developer has to do is click the just mentioned button and everything is arrangedfor him. So developers do not have to care about the layout themselves.

• When speaking of the layout another important point concerning usability has tobe mentioned. With GAME the layout and the content of the aspect model arestored in distinct �les. This is very important for the daily business at Swisscom.A developer needs to be able to compare di�erent versions of the same model easily.As the content of the model is saved apart, this is easy. The XML-based documentrepresenting the content is structured in a manner that is readable by a humanwithout di�culty. If the layout was stored in the same �le this would have twomajor drawbacks:

1. The information about the layout would spoil the simplicity of the XML-document.

2. The comparison gets much more complicated, since a lot of irrelevant infor-mation has to be �ltered out �rst.

To conclude this section we can say, that GAME is a highly usable tool already now. Ifin the future some details are improved, this will even increase the usability and makeGAME very intuitive to use.

10Conclusion

10.1. E�ective Workload . . . . . . . . . . . . . . . . . . . . . . . . . . 109

10.2. Evaluation of GMF . . . . . . . . . . . . . . . . . . . . . . . . . 110

10.3. Evaluation of GAME . . . . . . . . . . . . . . . . . . . . . . . . 110

10.3.1. Future Improvements . . . . . . . . . . . . . . . . . . . . . . . . 110

10.4. General Feelings . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

10.5. Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

This chapter evaluates the Master Thesis as a whole and gives an overview on the e�ec-tive workload. It evaluates GMF as technology and GAME as development tool. Alsoperspectives and future improvements of GAME are mentioned. In the end the authorgives a statement about his feelings throughout the elaboration of this Master Thesis.

10.1. E�ective Workload

For a Master Thesis the student is supposed to work about 900 hours, this is the equivalentto 30 ECTS. In Chapter 1 an overview of how these hours were split up is given. At theend of the Thesis we can consider, that we could follow the planing in great lines andthat the milestones could be kept with some little changes.The biggest variances in comparison with the planing can be found in the time spent forthe technological study and the writing of this paper. The time that was scheduled for thetechnical study, was enough to see if GMF was an adequate technology for implementingthe graphical editor, but it was not enough time to really understand the technology.This led to the fact that some customizations took quite a long time. This is why we cansay that a longer period of studying GMF would not have done any harm. What madethe task of customization even more di�cult, is that the author took care to add thecustomizations at hooks provided by the GMF developers, to keep up with the design ofthe framework. Looking for those hooks was in some cases very time consuming.The second point that was underestimated is the writing of this paper. Although thispaper was written in parallel with the development the �nishing took quite a long time.All the other points mentioned in the planing could be kept without any problems.

109

10.2. Evaluation of GMF 110

10.2. Evaluation of GMF

As already mentioned in the previous section, customizing GMF is quite hard work. Themain reason for that is, that almost no documentation for GMF is available. This is whyall the information has to be searched in forums or on the Internet, which is very timeconsuming. As pointed out before, the fact that the author wanted to preserve the designof GMF made customizations even more di�cult.What has to be said here in favor of GMF is, that the community of GMF is quite active.Many solutions, or ideas for the customizations for GAME were found on the News Portalof Eclipse [23] or by asking questions by the author himself.Under consideration that GMF is a new technology and the active community, we stillhave the opinion that GMF was the best choice for the elaboration of GAME. Thedrawback of poor documentation has no weight compared to the highly customizableplug-in we get and that it may be integrated seamlessly with the existing developmentenvironment. In addition to that the GMF community announced release 2.1 of GMFfor the end of June 2008. Among other things they plan to improve the documentationof GMF 2.0 and the added features for 2.1. So with that documentation even the lastdrawback of using GMF disappears.

10.3. Evaluation of GAME

Section 9.4 pointed out, that the usability of GAME is ensured already at this point. Thenext subsection points out some improvements that will be added in the future, to evenincrease the usability.The fact that GAME could be elaborated with GMF which is an Eclipse frameworkfacilitated the task a lot. Swisscom IT Services uses Eclipse as development platform thisis why the integration of the new development tool is easy and was already done by theend of this Thesis. Another advantage that GMF could be used is, that GAME consists ofseveral plug-ins. One of the advantages of a plug-in is that they are highly extensible andcustomizable through the extension / extension point principle (see Subsection 4.2.3). Sothere is no obstacle for future extensions of that development tool.As mentioned before, the embedding of GAME within the existing development platformalready took place. The developers at Swisscom IT Services will use GAME for theirdaily work by the end of Spring 2008. Up to then many of the improvements mentionedin the next subsection will be implemented, so we can expect, that the developers willwillingly use the new tool.

10.3.1. Future Improvements

During the elaboration of the graphical editor many possible extensions or improvementswere encountered. Let us have a look at these ideas in more detail.

Predecessor Relation If someone needs to draw a customizable PredecessorRelation thisincludes four di�erent tools. First one has to draw the PredecessorRelation which will holdthe speci�c condition in the end. Then that PredecessorRelation needs to be linked withthe successor and the predecessor. And �nally the characteristic of the condition may be

10.3. Evaluation of GAME 111

placed within the PredecessorRelation rectangle.It would be much more handy if the PredecessorRelation had already those two linkers. Soall the developer has to do is to link the connection with the Steps he wants and specifythe PredecessorCondition.

Image Generation At Swisscom IT Services most of the documentation is done withthe help of a Wiki. This is why the editor needs to be able to generate an image thatmay be vizualised in an ordinary web browser.This is why in Chapter 6 we pointed out that the possibility to save the diagram made byGAME as an image �le was important. Experience shows that many people �forget� tosave the diagram as image, as people �forget� to document their code. So the improvementhere would be, that the diagram is automatically saved as image �le as well, every timethe developer saves the diagram. Like this, the image �le is available in the browserwithout the developer having to bother about that.

Validation Up to now validation of the diagram may only be done through the EMFeditor and there is no visualization of that validation on the diagram itself. It is possiblealthough to automate the validation and to make that validation visible on the diagramdirectly. This is, make a red cross marker appear if a Step or PredecessorRelation is not asexpected. To do so we have two possibilities:

• Tell GMF to do the validation automatically, and show the errors with markers onthe canvas directly.

• Extend the existing OMS builder for building the processes. This extension willalso validate the static aspect model. Also here errors may be reported directlywith markers on the canvas.

Because OMS already provides a builder it is very likely, that this builder will be extendedfor validating the GAME model as well.

Dialog For setting the reference of a StepImplementation, i.e. a Flow or Activity one has�rst to open the Properties View (if it is not already open), then one has to click intothe Reference �eld which makes the dialog button appear. With a click on that buttonthe dialog appears.From the point of view of usability this is not optimal. For usability it would be great ifthe dialog appears with a double-click into the Activity or Flow.

Implementation Reference It is visible in Figure 9.8 on page 106, that up to now thereference to the implementation of a Step is visualized using a simple string. In practicethis references may be very long, which implies that the Steps get very long too. Thisspoils the image for documentation.This is why we have to think of another possibility to visualize this reference.

Sub�ow In Section 9.3 we saw how the Emergency Step is implemented as a Subflow. Interms of usability, it would be very convenient if the aspect model of that Subflow wouldopen directly by double-clicking into the Flow. Up to know this is not possible.

10.4. General Feelings 112

Summary We pointed out before, that GAME is already in the actual stadium straight-forward to use. The previous paragraphs show however, that there are lot of little thingsthat can be improved to even increase usability. Since GAME consists of several plug-ins,it should be possible to implement all of this improvements.

10.4. General Feelings

This section points out the personal feelings of the author throughout the elaboration ofthat Master Thesis and will be written from the authors point of view.When I started my internship at Swisscom IT Services I was highly motivated to workon this Master Thesis. First I got an introduction into the background at Swisscom ITServices and then I started with the technical study. The people I met at Swisscom ITServices are very amiable and cooperative.What was sometimes a bit demotivating was the hugeness of GMF. With some clicks you�nd yourself in front of hundreds of lines of generated code, that have to be understood.There were periods of time, where I thought that I will never �nd a solution to a speci�cproblem. Of course the fact that almost no documentation is available even enforced thatfeeling. The sensation after having found a solution however was then so much the better.In general I really appreciated to work on this Master Thesis. The background at Swiss-com IT Services is very interesting and I had the opportunity to learn a lot about thedaily business of the developers here.The supervision from both parties the University of Fribourg and Swisscom IT Serviceswas great. I found a competent person for all of my questions.A point that I appreciate very much, is that the development tool, that I developedthroughout this Master Thesis is going to be used in Spring 2008 already.To conclude this section I want to thank my supervisors for their support and all thepersons that reviewed this paper for their feedback.

10.5. Final Thoughts

In previous chapters the bene�ts of GAME were already pointed out. Let us neverthelessat the end of this paper point out the main bene�ts of GAME again.With the new development tool GAME Swisscom now follows a hybrid development cycle.The static parts of a process, the so called Aspect Model is now depicted with GAME. Thisleads to the following advantages:

• The high �exibility of de�ning processes through declarative description at Swiss-com can be kept. But with GAME the complexity of that de�nition is reduced.

• The model drawn with the help of GAME can at the same time be used for docu-mentation. This has the advantage that the work has only to be done once, i.e. noneed anymore to document the process with a separate drawing tool. In additionto that, what is very important for the daily business, the documentation is alwaysconsistent.

• Through the fact, that the developers need to depict a process only once theirproductivity may be increased.

10.5. Final Thoughts 113

Figure 10.1.: Replacement of the rule �le on the left by a GAME aspect model

• The last major advantage is that drawing is easier than coding and much less errorprone. Also this leads to a more e�ective development routine.

This shows, that GAME really is an improvement for the de�nition of processes at Swiss-com. In addition to that bene�ts for the development itself, we have to point out as well,that with GAME the communication between the developers and the business can beimproved.In conclusion we can say, that all expectations could be met. The goals set up at the be-ginning of this Thesis by the University and Swisscom IT Services could be achieved andthe author has appreciated to elaborate GAME and gained valuable working experiences.

AMindmap Example

This example is based on the tutorial [17] that is provided by the GMF community andwhose goal is to develop a simple mind mapping tool. This example is by far not asdetailed as the tutorial itself. The aim is not to rewrite the tutorial but to make thingsexplained in Chapter 5 clearer.

A.1. Setup

The example was written using Eclipse Europa (Version 3.3) [6] and GMF 2.0. An easyway to get the Graphical Modeling Framework is by using the update site of Eclipse.Select �Graphical Modeling Framework (Europa Edition)� from the �Models and ModelDevelopment� category and click the �Select Required� button to have all the plug-insdownloaded that GMF depends on. Appendix B.1.1 explains how this is done exactly.Before we can start with developing our example a GMF project has to be created.Choose File -> New... -> Other..., type �gmf� to the �lter and choose New GMFProject, Figure A.1 shows a screenshot of the wizard.Now all the prerequisites for starting the example are ful�lled. The next section showshow the code base is elaborated.

A.2. Developing Code Base of the Editor

As mentioned in Subsection 5.5.1 the domain model and the core plug-in that is generatedfrom it, build the code base of the editor.Figure A.5 shows the domain model that is used for this example. One can see from themodel that our mindmap will have topics and subtopics.

Creation of the Ecore Open the project you created in section A.1, right-click onthe model folder and select New... -> Other.... Type �ecore� in the �lter and choosethe Ecore Model. Click next and name the �le mindmap.ecore, ensure that the parentfolder is the model folder of your GMF project, then click �nish. The ecore �le opensautomatically.It is possible to elaborate the model with the Ecore Model Editor it is easier howeverto initialize an ecore_diagram �le. This is done by right-clicking on the mindmap.ecore �le

114

A.2. Developing Code Base of the Editor 115

Figure A.1.: Wizard for creating a new GMF project

and choosing Initialize ecore diagram_diagram �le. A wizard (Figure A.2) opensit should not be needed to do any changes. Nevertheless check that the �le is namedmindmap.ecore diagram and click �nish. Again the �le is opened automatically.On the right you can now see the palette for creating an ecore model. Our model is verysimple and can be created with the following steps (Figure 5.1). In the end your ecorediagram should look like the one in Figure A.5.

1. Right-click in the canvas of the editor and select theOpen Properties View menuitem.

a) Set the Name property to "mindmap"

b) Type "tbd" in the Ns Pre�x property

c) "www.swisscom.org" will be used for the Ns URI property

2. Create the two EClasses of our model and name one of those MapContext and theother one Topic. Refer to Figure A.5 to see how it should be in the end.

3. Insert an EAttribute to the Topic class

a) Name the attribute "name"

b) Set the EType property to EString

4. Draw an Aggregation from the MapContext class to the Topic class.

a) Set the Name property to "rootTopic"

b) To set the Upper Bound to in�te type -1 which stands for the in�ty symbol

5. Make an association from the Topic class to itself

a) Name the association "subTopic"

b) Set the Upper Bound to in�ty again

A.2. Developing Code Base of the Editor 116

Figure A.2.: Wizard for creating a ecore diagram �le

Code Base Generation With the ecore model we now have de�ned the domain model(number 1 on Figure 5.4 on page 47) of our graphical editor. What remains to be donenow is to generate the Java code that represents the code base created with the model(core plug-in).To be able to generate the code we need a generator model (2 on Figure 5.4) �rst. Tocreate that right-click on the mindmap.ecore �le and choose New -> Other... type �emf�in the �lter and choose EMF Model, click next. The parent folder should again be themodel folder of your project and the �le is named mindmap.genmodel, if this is true clicknext. The model importer that has to be used on the next page is Ecore Model, clicknext. Load the mindmap.ecore �le (Figure A.3) and choose mindmap as root package onthe next page of the wizard (Figure A.4), click �nish. The new �le will be opened in theEclipse editor.Now we can generate the code. Right-click on the root node of the *.genmodel whichis called Mindmap. Choose the Generate Model Code to generate the code whichrepresents the model (core plug-in). The code will appear in the src folder of your project.For being able to edit our mindmap, generate also the editing code by right-clicking againon the root element, this time you choose Generate Edit Code. This code will appearin a new plug-in, called org.swisscom.mindmap.edit the edit plug-in.There are four plug-ins that may be generated with the help of the genmodel �le:

A.3. Graphical and Tooling De�nition of the Editor 117

Figure A.3.: Wizard for creating a generator �le for the code base

• Core Plug-in (org.swisscom.mindmap): represents the domain model of each graph-ical editor. This plug-ins does not depend on any of the others that may be gener-ated.

• Edit Plug-in (org.swisscom.mindmap.edit): contains the code that makes editing ofthe elements represented by the editor possible. For this plug-in to run it needs theorg.swisscom.mindmap plug-in, which is trivial.

• Editor Plug-in (org.swisscom.mindmap.editor): builds an ordinary EMF tree editorfor editing the model. The editor plug-in depends on the edit plug-in. Only withthat dependency the editor may know, how properties and placements may bechanged.

• Test Plug-in (org.swisscom.mindmap.tests): contains sample classes of how a JUnittest could be implemented. There is nothing really implemented at generation.Which other generated plug-ins are required by this one, depends on the tests thatare done. At generation it depends only on the org.swisscom.mindmap plug-in.

The reason why multiple plug-ins are generated is to clearly separate functionality. Thedependencies between the plug-ins is de�ned in the plug.xml. It is in the philosophy ofEclipse that only those plug-ins are integrated with the system that are needed. For ourmindmap example for instance it is enough to generate the code base and the edit plug-in.You may in a second step generate the editor code to see the di�erence.The next step is now to de�ne the graphical editor itself. On the CD-ROM deliveredwith this paper you can �nd the source code generated for the mindmap example.

A.3. Graphical and Tooling De�nition of the Editor

The graphical and the tooling de�nition of an editor were described in the Subsections5.5.2 and 5.5.3. With the help of the mindmap example things will get clearer why andhow these two de�nitions are used.

A.3. Graphical and Tooling De�nition of the Editor 118

Figure A.4.: Wizard for creating a generator �le for the code base

Graphical De�nition Generally speaking the graphical de�nition (3a on Figure 5.4)links the domain model with the editor. Here we de�ne what �gures represent whichclasses of the domain model. In the mindmap editor there will be rounded rectanglesthat represent the topics and an arrow which shows the subtopics.We will use the wizard that is provided to de�ne the graph. You can �nd the wizard byright-clicking on the model folder and choosing New -> Other.... Type �graph� in the�lter and choose Simple Graphical De�nition Model and click next. Name the modelmindmap.gmfgraph and choose the already known model folder as parent folder. On the nextpage select MapContext as DomainElement from the mindmap.ecore domain model.The next page de�nes how the elements from the domain model are represented. TheTopic class will be represented as �gure (�rst row), the name of the Topic is an attribute ofthe Topic �gure (third row) and the subtopic is represented by a connection (second row).When you click �nish, the newly created �le is directly opened in the editor. Figure A.6shows how this �le should look like.The next paragraph explains how this �le can now be customized.

Customize Graphical De�nition In Figure A.6 you can see, that a rectangle �gurewas de�ned as Topic �gure. What we want is a rounded rectangle so let us change that.

1. Right-click on the Figure Gallery Default node and select New Child -> FigureDescriptor. A new �gure descriptor appears in the tree.

A.4. Tooling De�nition 119

Figure A.5.: The ecore diagram of this little example

2. Name the new �gure descriptor �TopicFigure�.

3. Right-click the newly created �gure descriptor and selectNew Child -> RoundedRectangle.

4. Name the new rounded rectangle �TopicFigure�.

5. Select the Flow Layout false child of the Rectangle TopicFigure node and drag it to thenewly created rounded rectangle �gure.

6. Do the same with the Label TopicNameFigure node.

7. Select the Child Access getFigureTopicNameFigure child of the old Figure Descriptor Topic-Figure and drag it to the new TopicFigure �gure descriptor.

8. Now the old Figure Descriptor TopicFigure should have only the Rectangle TopicFigure leftas child. If so, delete the old Figure Descriptor TopicFigure. If not move all the subnodes to the new �gure descriptor and delete it afterwards.

9. Because the old �gure descriptor was deleted we have to update the references tothe new one:

a) Select the Node Topic node. Set the Figure property to the new (and now only)Figure Descriptor TopicFigure.

b) Now select the Diagram Label TopicName node and set the Figure property tothe new (and now only) Figure Descriptor TopicFigure as well.

Now your graph �le should look like the one in Figure A.7. If you right-click on the Canvasmindmap node you can check whether your graphical de�nition is valid by choosing theValidate... menu item. In the next paragraph you will learn how to create the toolingde�nition.

A.4. Tooling De�nition

As for the graphical de�nition a wizard is also provided for the tooling de�nition (3b onFigure 5.4). You �nd it by right-clicking on the model folder again and choosing New

A.5. Mapping Model and Editor Code Generation 120

Figure A.6.: The mindmap.gmfgraph �le being created with the wizard

-> Other.... Type �tool� in the �lter, choose Simple Tooling De�nition Model andclick next. Name the �le mindmap.gmftool and choose our model folder as parent folder,move on to the next page. As for the graphical de�nition choose the mindmap.ecore asdomain model and the MapContext as Domain Element. On the next page you cansee that creation tool for a �gure is created for the Topic node and a link creation tool forindicating the subtopics. Click �nish and the �le is opened.Your �le should now look like in Figure A.8. For the tooling de�nition we do not haveto do any customization. See how to create the mapping model and how to generate thecode for the editor itself in the next subsection.

A.5. Mapping Model and Editor Code Generation

A description of what the mapping model is and what models are the basis to generatethe editor code was already given in section 5.6 and may be seen in Figure 5.4 on page 47with the numbers 4 and 5. Here you will learn how to create those �les for our mindmapexample.

Mapping Model Creation As described in section 5.6 the mapping model links thethree con�guration �les. To create it, click on the model folder and go to New ->Other.... Type �map� to the �lter and choose Guide Mapping Model Creation.Set the �le name to mindmap.gmfmap and select our model folder as parent folder on thenext page, then click next. Select the MapContext class out of the mindmap package of themindmap.ecore domain model, click next. Select the mindmap.gmftool as diagram palette andgo to the next page. For the diagram canvas choose the mindmap.gmfgraph �le that youcreated in section A.3. On the last page you should not have to change anything. The

A.5. Mapping Model and Editor Code Generation 121

Figure A.7.: The mindmap.gmfgraph �le after customization

Topic is de�ned as node and the subTopic as a link, click �nish to create the mindmap.gmfmap�le.

Completion of Mapping Model The wizard is not able to generate everything that isneeded for the mapping. So there are some changes that have to be added by hand.

1. Extend all the nodes of the platform:/resource/.../mindmap.gmfmap node.

2. Select the Feature Label mapping false node and show the properties view. Set theDiagram Label property to Diagram Label TopicName.

3. Select the Node Mapping node and check that the following is true. In case where itis not as expected, set it to the indicated value.

a) The Diagram Node property has the value Node Topic (Topic Figure).

b) The Tool property is set to Creation Tool Topic.

4. Now select the Top Node Reference node and verify that:

a) The Child node is set to the Node Mapping node which is graphically the childof the Top Node Reference node.

b) The Containment Feature property has the value rootTopic:Topic.

5. Select the Link Mapping node and check the following points (if it is not like indicatedchange it accordingly):

a) subTopic:Topic is the value of the Target Feature property.

b) The Diagram Link property is set to Connection TopicSupTopic.

c) The Tool property has the value Creation Tool TopicSubTopic.

d) Here also you can right-click the Mapping node and choose the Validate menuitem to see if your mapping model is valid.

A.6. Run the Example 122

Figure A.8.: The mindmap.tool �le after creation with the wizard

After being through all these steps your mindmap.gmfmap �le should be similar to the onein �gure A.9.

Generator Model Creation The purpose of this �le was described in the section 5.6.Here we focus on how it is created and you will see that this is very easy.Right-click on the mindmap.gmfmap �le and select the Create generator model... menuitem, again a wizard opens. On the �rst page everything should be entered for youalready. The �le is called mindmap.gmfgen and the parent folder is again our model folder.Load the mindmap.gmfmap �le on the next page and click next. The page that followsmakes the link to the code base that was generated in Appendix A.2, load the genmodelthat was created there. On the last page check the two boxes IMapMode1 and Utilizeenhanced features of gmf runtime and click �nish. The model will be opened in theeditor.

Editor Code Generation This part is the easiest one of all. To generate the editor codeyou just have to right-click on the newly created mindmap.gmfgen �le from the previousparagraph and choose the Generate diagram code menu item. The code then appearsin a new plug-in, named org.swisscom.mindmap.diagram the diagram plug-in.Now you have everything that is needed to run the mindmap example. The next sectionexplains how this is done. To be sure you have everything that is needed you can compareyour package explorer with the one shown in Figure A.10.

A.6. Run the Example

Now you have all the code that is needed to run the application. Let us now see how thisis done.Eclipse provides the possibility of starting a new application directly out of Eclipse the

1IMapMode is used for converting back and forth between measuring units (inches, centimeters, pixels).

A.6. Run the Example 123

Figure A.9.: The mindmap.gmfmap �le after having it completed by hand

following paragraph describes how this is done:Firstly we have to de�ne the target platform. Subsection 4.4.1 describes why and howthis is done. Here we describe how the Eclipse application has to be de�ned for runningthe example.

Create Eclipse Application Con�guration To con�gure the Eclipse application selectthe Open Run Dialog... menu item of the Run menu. Choose Eclipse Applicationand press the New button. A child called New_con�guration is added to the EclipseApplication node. Make the following changes to the con�guration.

1. Change the Name to �GMF_con�guration�.

2. In the Main tab change the Location of the Workspace Data to�$workspace_loc/../runtime-GMF_configuration� (Figure A.12).

3. Add the argument �-consoleLog� to the Program arguments of the Arguments(Figure A.11) tab2.

4. Go to the plug-ins tab (Figure A.13).

a) Select Launch with �plug-ins selected below only�.

b) Press the Deselect All button.

c) Check the org.swisscom.mindmap, the org.swisscom.mindmap.diagram and theorg.swisscom.mindmap.edit plug-in.

d) Press the Add Required plug-ins button.

5. Press the Apply button.

You now terminated the con�guration and can run the application.

Run the Application Once the application is con�gured you can run it. There aredi�erent possibilities to do this. You certainly noticed the Run button underneath the

2With the help of this parameter the log is written directly to the console of Eclipse

A.7. The Graphical Editor 124

Figure A.10.: Package explorer showing all the models and plug-ins

Figure A.11.: Eclipse application con�guration: Main tab

Apply button mentioned in the previous paragraph.But you have also the possibility to run the Eclipse application in the same way as anordinary Java application by clicking the run symbol or over the menu Run -> Run.A new Eclipse is launched containing all the plug-ins you selected previously in the plug-ins tab of the application con�guration. Finally the next chapter describes the mostimportant parts of the editor.

A.7. The Graphical Editor

The editor we created is a plug-in for Eclipse. So to use the editor you need to installthe plug-in. To do so you have two possibilities. The �rst one is you unzip the providedmindmap_example.zip in the mindmap example folder, on the provided CD-ROM, to yourEclipse installation folder.The second is to export all the plug-ins directly to your Eclipse installation by right-clicking one of them and choosing Export.... On the wizard that appears choose all themindmap plug-ins and export them to your eclipse installation directory. If you do notwant to install the plug-ins you may run a new Eclipse application as described in theprevious subsection.Then you need a project as container for the editor �les. So create such a project (File


Figure A.12.: Eclipse application con�guration: Arguments tab

-> New -> Project). Once you have the project right-click on the project and chooseNew -> Other.... Type �mindmap� to the �lter �eld and chooseMindmap Diagram.Go to the next page an name the diagram you are going to make as you want, then click�nish. The newly created �le opens in the editor and on the right you can see the paletteappear.

Topics and Subtopics To create topics click on the Topic in the palette, then go tothe canvas and draw a rectangle. A new topic appears on the canvas. There are twodi�erent ways to name this topic. For the �rst way, you just enter the name in the �gure,if the cursor is not active any more you can activate it by double clicking the �gure.The second possibility is through the Properties View. The Properties View can beopened by right-clicking on the �gure and choosing the Show Properties View menuitem.If you have more than two topics you can de�ne a subtopic relation. To do so theprocedure is almost the same. Click on the Sub Topic creation tool in the palette. Thengo to the parent topic and drag the link to the subtopic of that topic. An arrow appearsto show that relation.Figure A.14 shows how this could look like.


Figure A.13.: Eclipse application con�guration: Plug-in tab

Figure A.14.: The editor that was created for this example

BSetup for GAME

This appendix describes what has to be done before being able to use GAME. It is dividedinto two parts, the �rst describes how developers at Swisscom IT Services have to use theeditor. The second part describes how people only having the provided CD-Rom have toproceed.

B.1. Swisscom IT Services

This section describes the installation process for developers working at Swisscom ITServices and thus having access to the whole development and production environment.

B.1.1. Prerequisites

The developers working at Swisscom IT Services do not have to bother themselves forthe setup. All they have to do is to use the Eclipse Platform that is provided to them.

B.1.2. Getting Started

Developers in OMS use a more or less standardized Eclipse installation. This Eclipseinstallation contains all necessary plug-ins that are needed to run GAME. An Eclipseupdate site exists on which all existing OMS plug-ins are deployed. Thus to installGAME the developer will have to use the standard Eclipse update mechanism.

B.2. Test Environment

If you only have the CD-ROM this section describes what you have to do in order to runGAME. Of course you will only have part of the functionality, since the CLOM and thewhole background at Swisscom are missing.

127

B.2. Test Environment 128

Figure B.1.: How accessing the Eclipse Update Site

B.2.1. Prerequisites

For the development of GAME, GMF 2.0 was used. In order to run the GAME plug-insproperly check the following three points:

• Install Eclipse Europa (Version 3.3) if you do not have it already. You may downloadthe classic edition from the web site of Eclipse [6].

• Install the GMF plug-in, using the Europa Discovery update site. The next fewpoints explain how this can be done.

� Choose the menu Help, choose the menu item Software Updates -> Findand Install... as shown in Figure B.1.

� Chose Search for new features to install on the wizard that pops up andclick next.

� Check Europa Discovery Site and click �nish.

� Choose a mirror.

� Expand the Models and Model Development node and check GraphicalModeling Framework (Europa Edition). Then click on the button SelectRequired. The warnings should disappear now, click next.

� Accept the license agreement and click next.

� The last page shows you what is going to be installed. Click �nish and theplug-in installation starts.

� It may be that a Feature Veri�cation pops up, choose Install All in thatcase.

� Relaunch Eclipse once the installation is �nished.

• Make sure that you have installed Java 6.0. If you have not you may download itfrom the SUN web site [20].

Now all the prerequisites for running GAME are ful�lled. What remains is to install theGAME plug-ins themselves.As described in Chapter 4 the installation of plug-ins is quite easy.

B.2. Test Environment 129

Figure B.2.: Wizard for creating a GMF diagram

• Unzip the game.zip archive that can be found in the test environment folder into yourEclipse installation folder.

• Unzip dummy.zip in the same folder, these plug-ins provide a dummy Swisscom back-ground and enables you to see all the functionalities.

Now your are able to work with GAME.

B.2.2. Getting started

Once Eclipse is set up for GAME you may test it. The �rst thing you need to do iscreating a project for holding the GAME �les. Go to the File menu and choose theNew -> Project... menu item. In the wizard that opens choose Project and name theproject as you want.Right-click on the newly created project and choose New -> Other..., in the wizardthat appears type �game� into the �lter and choose Game Diagram, Figure B.2 showsthe wizard. Your previous created project folder should be the parent folder of the �lesto be created.Now you are able to use GAME. Refer to Chapter 9 to learn more about the using ofGAME.

CSource Code

Here all the classes added by the author may be found. Non of these classes was generatedthrough GMF. On the CD-Rom, these classes may be found in the customsrc folders ofthe core and the diagram plug-in.Refer to the Javadoc or the source code provided on the CD-Rom to get more informationabout the classes that were generated through GMF.

C.1. Core Plug-in

In this plug-in only one custom class was added. It is responsible for wrapping thejava.lang.String object, by replacing every space character with a point character. Codeextract C.1 shows this class.

1 package game . diagram . datatype ;

3 /∗ ∗∗ Wraps an ord ina ry s t r i n g by rep lac ing every space charac te r w i th a po in t

5 ∗ charac te r∗

7 ∗ @author tgdromau∗

9 ∗ /public class Str ingWrapper {

11

private S t r i n g i d S t r i n g = "<Step Name>" ;13

public Str ingWrapper ( S t r i n g s t r ) {15 th is . i d S t r i n g = s t r . rep lace ( " " , " . " ) ;

}17

/∗ ∗19 ∗ Returns the s t r i n g t h a t may be used as i d e n d i f i e r ( w i thou t spaces )

∗21 ∗ @return S t r i n g

∗ /23 public S t r i n g g e t I d S t r i n g ( ) {

return i d S t r i n g ;25 }

27 @Override/∗ ∗

29 ∗ Returns the o rd ina ry s t r i n g∗ /

31 public S t r i n g t o S t r i n g ( ) {return i d S t r i n g . rep lace ( " . " , " " ) ;

33 }

130

C.2. Diagram Plug-in 131

35 }

Code extract C.1: StringWrapper.java

C.2. Diagram Plug-in

For the diagram plug-in the author added three custom packages holding the classes thathad to be added for customization. Find in the next subsections the three packages withits classes.

C.2.1. game.diagram.dialog Package

This package contains the classes that had to be added for setting the reference to theOMS artifacts. They will be presented in alphabetical order here.The ActivityFunctionLabelProvider provides the labels with the icons that will be visible inthe Dialog, this class is visible in Code extract C.2.

1 package game . diagram . d ia log ;

3 import org . ec l i pse . swt . graphics . Image ;

5 import com. swisscom .oms . p lug ins . clom . core . he lpers . ClomCoreLabelProvider ;import com. swisscom .oms . p lug ins . clom . core . he lpers . ImageHelper ;

7 import com. swisscom .oms . p lug ins . clom . core . model . Ac t i v i t yFunc t ionRe fe rence ;

9 public class A c t i v i t y F u n c t i o n L a b e l P r o v i d e r extends ClomCoreLabelProvider {

11 @Overridepublic S t r i n g getText ( Object element ) {

13

i f ( element instanceof Act i v i t yFunc t ionWrapper ) {15 Act iv i t yFunc t ionWrapper refWrap = ( Ac t i v i t yFunc t ionWrapper ) element ;

Ac t i v i t yFunc t ionRe fe rence r e f = refWrap . getFunct ion ( ) ;17 return r e f . getFunctionName ( ) + " ( Version : "

+ r e f . getFunct ionVers ion ( ) + " ) " ;19 }

return super . getText ( element ) ;21 }

23 public Image getImage ( Object ob j ) {

25 i f ( ob j instanceof Act iv i t yFunc t ionWrapper ) {return ImageHelper . getImage ( ImageHelper . ICON_ACTIVITY_FUNCTION) ;

27 }

29 return super . getImage ( ob j ) ;}

31 }

Code extract C.2: ActivityFunctionLabelProvider.java

The class visible in Code extract C.3, sets up the tree structure. Here we de�ne how toaccess the parent and its elements etc.


3 import java . u t i l . A r r a y L i s t ;import java . u t i l . I t e r a t o r ;

5 import java . u t i l . L i s t ;

7 import org . ec l i pse . j f a c e . v iewers . ITreeContentProv ider ;


import org . ec l i pse . j f a c e . v iewers . Viewer ;9

import com. swisscom .oms . p lug ins . clom . core . model . Ac t i v i t yFunc t ionRe fe rence ;11 import com. swisscom .oms . p lug ins . clom . core . model . Ac t i v i t yRe fe rence ;

13 public class Ac t i v i t yFunc t i onTreeCon ten tP rov ide r implementsITreeContentProv ider {

15

@Override17 public Object [ ] ge tCh i ld ren ( Object parentElement ) {

19 i f ( parentElement instanceof Ac t i v i t yRe fe rence ) {L i s t <Act iv i tyFunct ionWrapper > r e s u l t = new Ar rayL i s t <Act iv i tyFunct ionWrapper > ( ) ;

21 I t e r a t o r i t = ( ( Ac t i v i t yRe fe rence ) parentElement ) . g e t A c t i v i t y F u n c t i o n s ( ) . i t e r a t o r ( ) ;while ( i t . hasNext ( ) ) {

23 Act iv i t yFunc t ionWrapper cu r ren t = new Act i v i t yFunc t ionWrapper ( ) ;cu r ren t . s e t A c t i v i t y ( ( Ac t i v i t yRe fe rence ) parentElement ) ;

25 cu r ren t . se tFunct ion ( ( Ac t i v i t yFunc t ionRe fe rence ) i t . next ( ) ) ;r e s u l t . add ( cu r ren t ) ;

27 }return r e s u l t . toAr ray ( ) ;

29 }return nul l ;

31 }

33 @Overridepublic Object getParent ( Object element ) {

35 i f ( element instanceof Act iv i t yFunc t ionWrapper ) {return ( ( Ac t i v i t yFunc t ionWrapper ) element ) . g e t A c t i v i t y ( ) ;

37 }return nul l ;

39 }

41 @Overridepublic boolean hasChi ldren ( Object element ) {

43

i f ( element instanceof Ac t i v i t yRe fe rence ) {45 L i s t f u nc t i o ns = ( ( Ac t i v i t yRe fe rence ) element )

. g e t A c t i v i t y F u n c t i o n s ( ) ;47

i f ( f u n c t i o n s != nul l && fu n c t i o n s . s ize ( ) != 0) {49 return true ;

}51 }

53 return fa lse ;}

55

@Override57 public Object [ ] getElements ( Object inputElement ) {

59 i f ( inputElement instanceof L i s t ) {return ( ( L i s t ) inputElement ) . toAr ray ( ) ;

61 }

63 return nul l ;}

65

@Override67 public void dispose ( ) {

}69

@Override71 public void inputChanged ( Viewer viewer , Object o ld Inpu t , Object newInput ) {

}73 }

Code extract C.3: ActivityFunctionTreeContentProvider.java

The ActivityFunctionWrapper is needed for knowing the Activity and the function that is ex-ecuted. Without this wrapper, we would know which function is executed but not from


which Activity this function comes from.


3 import com. swisscom .oms . p lug ins . clom . core . model . Ac t i v i t yFunc t ionRe fe rence ;import com. swisscom .oms . p lug ins . clom . core . model . Ac t i v i t yRe fe rence ;

5

public class Act iv i t yFunc t ionWrapper {7 private Ac t i v i t yRe fe rence a c t i v i t y ;

private Ac t i v i t yFunc t ionRe fe rence f un c t i on s ;9

public Ac t i v i t yRe fe rence g e t A c t i v i t y ( ) {11 return a c t i v i t y ;

}13 public void s e t A c t i v i t y ( Ac t i v i t yRe fe rence a c t i v i t y ) {

th is . a c t i v i t y = a c t i v i t y ;15 }

public Ac t i v i t yFunc t ionRe fe rence getFunct ion ( ) {17 return f u nc t i o ns ;

}19 public void setFunct ion ( Ac t i v i t yFunc t ionRe fe rence f un c t i on s ) {

th is . f un c t i on s = f u nc t i o ns ;21 }

23

}

Code extract C.4: ActivityFunctionWrapper.java

Up to here we only saw helper classes that render the output of the Activity dialog in someway. Let us now see how the ActivitySelectionDialog is set up itself. You can see the codein Code extract C.5.

package game . diagram . d ia log ;2

4

import java . lang . r e f l e c t . Invoca t ionTarge tExcept ion ;6 import java . u t i l . L i s t ;

8 import org . ec l i pse . core . runt ime . IProgressMoni tor ;import org . ec l i pse . j f a c e . opera t ion . IRunnableWithProgress ;

10 import org . ec l i pse . j f a c e . v iewers . ISe lec t ionChangedLis tener ;import org . ec l i pse . j f a c e . v iewers . I S t r u c t u r e d S e l e c t i o n ;

12 import org . ec l i pse . j f a c e . v iewers . SelectionChangedEvent ;import org . ec l i pse . j f a c e . v iewers . TreeViewer ;

14 import org . ec l i pse . j f a c e . v iewers . Viewer ;import org . ec l i pse . j f a c e . v iewers . ViewerSor ter ;

16 import org . ec l i pse . swt .SWT;import org . ec l i pse . swt . widgets . Composite ;

18 import org . ec l i pse . swt . widgets . Cont ro l ;import org . ec l i pse . swt . widgets . She l l ;

20 import org . ec l i pse . u i . P la t fo rmUI ;import org . ec l i pse . u i . d ia logs . F i l t e red T ree ;

22 import org . ec l i pse . u i . d ia logs . P a t t e r n F i l t e r ;import org . ec l i pse . u i . d ia logs . Se lec t ionD ia log ;

24

import com. swisscom .oms . p lug ins . clom . core . model . A c t i v i t y C o l l e c t o r ;26 import com. swisscom .oms . p lug ins . clom . core . model . Ac t i v i t yFunc t ionRe fe rence ;

import com. swisscom .oms . p lug ins . clom . core . model . Ac t i v i t yRe fe rence ;28 import com. swisscom .oms . p lug ins . clom . core . model . S t e p I n f o C o l l e c t o r ;

30 /∗ ∗∗ Returns the d ia log t h a t a l lows the user to choose the a c t i v i t y f u n c t i o n t h a t has to be

executed32 ∗ @author tgdromau

∗34 ∗ /

public class A c t i v i t y S e l e c t i o n D i a l o g extends Se lec t ionD ia log implements IRunnableWithProgress{

36


private L i s t _ a c t i v i t i e s ;38

/∗ ∗40 ∗ @param paren tShe l l

∗ @param composite42 ∗ /

public A c t i v i t y S e l e c t i o n D i a l o g ( She l l parentShe l l , Composite composite ) {44 super ( pa ren tShe l l ) ;

th is . c reateDia logArea ( composite ) ;46 }

48 /∗ ∗∗ Create a new f i l t e r e d t ree viewer i n the parent .

50 ∗∗ @param parent

52 ∗ the parent <code>Composite </ code >.∗ /

54 private void c rea teF i l t e redTreeV iewer ( Composite parent ) {

56 i n t s t y l e B i t s = SWT. SINGLE | SWT.H_SCROLL | SWT.V_SCROLL | SWT.BORDER;/∗ customize the pa t t e rn F i l t e r :

58 ∗ I t i s poss ib le to f i l t e r f o r a c t i v i t y names and f u n c t i o n s ∗ /P a t t e r n F i l t e r p a t t e r n F i l t e r = new P a t t e r n F i l t e r ( ) {

60

@Override62 public boolean i sE lemen tV i s ib l e ( Viewer viewer , Object element ) {

return matchesObjectName ( element ) ;64 }

66 private boolean matchesObjectName ( Object element ) {i f ( element instanceof Ac t i v i t yRe fe rence ) {

68 Ac t i v i t yRe fe rence a c t i v i t y = ( Ac t i v i t yRe fe rence ) element ;return wordMatches ( a c t i v i t y . getAct iv i tyName ( ) )

70 | | funct ionMatches ( a c t i v i t y ) ;}

72 else i f ( element instanceof Act iv i t yFunc t ionWrapper ) {Ac t i v i t yFunc t ionWrapper wrap = ( Ac t i v i t yFunc t ionWrapper ) element ;

74 return wordMatches ( wrap . getFunct ion ( ) . getFunctionName ( ) )| | wordMatches ( wrap . g e t A c t i v i t y ( ) . getAct iv i tyName ( ) ) ;

76 }return fa lse ;

78 }

80 / / r e tu rns t rue i f one the a c t i v i t i e s f u n c t i o n s matchprivate boolean funct ionMatches ( Ac t i v i t yRe fe rence a c t i v i t y ) {

82 for ( Ac t i v i t yFunc t i onRe fe rence f u n c t i o n : a c t i v i t y . g e t A c t i v i t y F u n c t i o n s ( ) ) {i f ( wordMatches ( f u n c t i o n . getFunctionName ( ) ) ) {

84 return true ;}

86 }return fa lse ;

88 }} ;

90 p a t t e r n F i l t e r . se t Inc ludeLeadingWi ldcard ( true ) ;

92 F i l t e re dT re e f i l t e r e d T r e e = new F i l t e re dT re e ( parent , s t y l e B i t s , p a t t e r n F i l t e r ) ;

94 / / setup the t ree viewerTreeViewer t reeViewer = f i l t e r e d T r e e . getViewer ( ) ;

96 t reeViewer . se tLabe lProv ider (new A c t i v i t y F u n c t i o n L a b e l P r o v i d e r ( ) ) ;t reeViewer . se tContentProv ider (new Ac t i v i t yFunc t i onTreeCon ten tP rov ide r ( ) ) ;

98 t reeViewer . se tSo r te r (new ViewerSor ter ( ) ) ;

100 / / Get a c t i v i t i e st ry {

102 Plat fo rmUI . getWorkbench ( ) . getProgressServ ice ( ) . run ( true , true , th is ) ;} catch ( Invoca t ionTarge tExcept ion e ) {

104 / / No Er ro r Handl ing here} catch ( I n te r rup tedExcep t i on e ) {

106 / / No Er ro r Handl ing here}

108

t reeViewer . se t I npu t ( _ a c t i v i t i e s ) ;


110

/∗ add a s e l e c t i o n l i s t e n e r t h a t s to res the cu r ren t s e l e c t i o n to r e s u l t a r ray112 ∗ of the Se lec t i onD ia log

∗ OK but ton can only by pressed i f an A c t i v i t y f u n c t i o n i s se lec ted114 ∗ /

t reeViewer . addSelect ionChangedListener (new ISe lec t ionChangedLis tener ( ) {116 public void select ionChanged ( SelectionChangedEvent event ) {

se tResu l t ( ( ( I S t r u c t u r e d S e l e c t i o n ) event . ge tSe lec t i on ( ) )118 . t o L i s t ( ) ) ;

getOkButton ( ) . setEnabled ( ( ( I S t r u c t u r e d S e l e c t i o n ) event . ge tSe lec t i on ( ) ) . ge tF i rs tE lement( ) instanceof Act iv i t yFunc t ionWrapper ) ;

120 }} ) ;

122 }

124 /∗ ∗∗ Creates and re tu rns the contents o f the upper pa r t o f t h i s d ia log ( above

126 ∗ the but ton bar ) .∗

128 ∗ @param parent∗ the parent composite to conta in the d ia log area

130 ∗ @return the d ia log area c o n t r o l∗ /

132 @Overrideprotected Cont ro l createDia logArea ( Composite parent ) {

134 Composite composite = ( Composite ) super . c reateDia logArea ( parent ) ;

136 c rea teF i l t e redTreeV iewer ( composite ) ;

138 return composite ;}

140

@Override142 protected void con f i gu reShe l l ( She l l s h e l l ) {

super . con f i gu reShe l l ( s h e l l ) ;144 s h e l l . se tS ize (300 , 400) ;

}146

@Override148 public void run ( IProgressMoni tor moni tor ) throws Invocat ionTargetExcept ion ,

In te r rup tedExcep t i on {

150 / / Get A c t i v i t i e s :A c t i v i t y C o l l e c t o r a c t i v i t y C o l l e c t o r = S t e p I n f o C o l l e c t o r . ge t Ins tance ( ) .

g e t A c t i v i t y F u n c t i o n C o l l e c t o r ( ) ;152 moni tor . beginTask ( " Loading A c t i v i t y Desc r ip to r . . . " , 1000) ;

_ a c t i v i t i e s = a c t i v i t y C o l l e c t o r . g e t A c t i v i t i e s ( moni tor ) ;154 moni tor . done ( ) ;

}156 }

Code extract C.5: ActivitySelectionDialog.java

As already mentioned in Chapter 8 the ActivitySelectionDialog is quite complex to set up,this is due to the fact, that the construct Activity is more complex than the construct Flow.See in Code extract C.6 how easy it is, to set up the FlowSelectionDialog.

package game . diagram . d ia log ;2

import java . lang . r e f l e c t . Invoca t ionTarge tExcept ion ;4 import java . u t i l . L i s t ;

6 import org . ec l i pse . core . runt ime . IProgressMoni tor ;import org . ec l i pse . j f a c e . opera t ion . IRunnableWithProgress ;

8 import org . ec l i pse . swt . widgets . She l l ;import org . ec l i pse . u i . P la t fo rmUI ;

10 import org . ec l i pse . u i . d ia logs . E lementL is tSe lec t ionD ia log ;

12 import com. swisscom .oms . p lug ins . clom . core . he lpers . ClomCoreLabelProvider ;import com. swisscom .oms . p lug ins . clom . core . model . F lowCol lec to r ;

14 import com. swisscom .oms . p lug ins . clom . core . model . S t e p I n f o C o l l e c t o r ;


16 /∗ ∗∗ Returns the d ia log t h a t a l lows the user to choose the f low t h a t has to be executed

18 ∗ @author tgdromau∗

20 ∗ /public class FlowSelec t ionDia log extends ElementL is tSe lec t ionD ia log implements

IRunnableWithProgress {22

private L i s t _f lows ;24

public FlowSelec t ionDia log ( She l l parent ) {26 super ( parent , new ClomCoreLabelProvider ( ) ) ;

28 / / Get Flowst ry {

30 Plat fo rmUI . getWorkbench ( ) . getProgressServ ice ( ) . run ( true , true , th is ) ;} catch ( Invoca t ionTarge tExcept ion e ) {

32 / / No Er ro r Handl ing here} catch ( I n te r rup tedExcep t i on e ) {

34 / / No Er ro r Handl ing here}

36 th is . setElements ( _f lows . toAr ray ( ) ) ;}

38

@Override40 protected void con f i gu reShe l l ( She l l s h e l l ) {

super . con f i gu reShe l l ( s h e l l ) ;42 s h e l l . se tS ize (300 , 400) ;

}44

@Override46 public void run ( IProgressMoni tor moni tor ) throws Invocat ionTargetExcept ion ,

In te r rup tedExcep t i on {48

/ / Se lec t f lows :50 moni tor . beginTask ( "Read f low d e s c r i p t o r s . . . " , 1000) ;

F lowCo l lec to r f l o w C o l l e c t o r = S t e p I n f o C o l l e c t o r . ge t Ins tance ( ) . ge tF lowCo l lec to r ( ) ;52 _f lows = f l o w C o l l e c t o r . getFlows ( moni tor ) ;

moni tor . done ( ) ;54 }

}

Code extract C.6: FlowSelectionDialog.java

C.2.2. game.diagram.figures Package

Because we wanted to follow the BPMN standards, we had to customize some �gures.All the classes that had to be added by the author for that purpose may be found in thispackage. Again the classes are listed alphabetically.The InvisibleCompartmentFigure renders all the �gures that extend it transparent. This isused for the Activity and the Flow that are placed within a Step, and for the SimplePrede-cessorCondition and the HasResultPredecessorCondition that are placed within the Predeces-sorRelation rectangle. Code extract C.7 shows that InvisibleCompartmentFigure.

1 package game . diagram . f i g u r e s ;

3 import org . ec l i pse . draw2d . Graphics ;import org . ec l i pse . draw2d . RectangleFigure ;

5

public class Inv is ib leCompar tmentF igure extends RectangleFigure {7

public Inv is ib leCompar tmentF igure ( ) {9

}11


@Override13 public void pa in tF igu re ( Graphics graphics ) {

/ / t ransparen t15 }

}

Code extract C.7: InvisibleCompartmentFigure.java

The PredecessorRelationBodyFigure is the child �gure of the PredecessorRelationFigure it isused for holding the SimplePredecessorCondition or the HasResultPredecessorCondition respec-tivly. Code extract C.8 shows that body �gure.

package game . diagram . f i g u r e s ;2

import org . ec l i pse . draw2d . Graphics ;4 import org . ec l i pse . draw2d . RectangleFigure ;

import org . ec l i pse . draw2d . geometry . Dimension ;6

public class PredecessorRelat ionBodyFigure extends RectangleFigure {8

public PredecessorRelat ionBodyFigure ( ) {10

}12

14 @Overridepublic void pa in tF igu re ( Graphics graphics ) {

16 / / t ransparen t}

18

/∗ ∗20 ∗ getMinimumSize w i l l r e t u r n the dimension so t h a t the c h i l d i n the

∗ PredecessorRelat ionBodyFigure ( StepCompartment ) i s always v i s i b l e .22 ∗ /

@Override24 public Dimension getMinimumSize ( i n t wHint , i n t hHint ) {

Dimension dim = th is . getLayoutManager ( ) . ge tPre fe r redS ize ( this , wHint ,26 hHint ) ;

return new Dimension ( dim . width , dim . he igh t ) ;28 }

30 }

Code extract C.8: PredecessorRelationBodyFigure.java

Also the StepFigure may contain two other �gures which are the ActivityFigure and theFlowFigure, as before we have a body �gure that will hold the �gures that may be placedwithin the StepFigure. Code extract C.9 shows the StepBodyFigure.

package game . diagram . f i g u r e s ;2

import org . ec l i pse . draw2d . Graphics ;4 import org . ec l i pse . draw2d . RectangleFigure ;

import org . ec l i pse . draw2d . geometry . Dimension ;6

public class StepBodyFigure extends RectangleFigure {8

public StepBodyFigure ( ) {10

}12

@Override14 public void pa in tF igu re ( Graphics graphics ) {

/ / noth ing : t ransparen t16 }

18 /∗ ∗∗ getMinimumSize w i l l r e t u r n the dimension so t h a t the c h i l d i n the

20 ∗ StepBodyFigure ( StepCompartment ) i s always v i s i b l e .


∗ /22 @Override

public Dimension getMinimumSize ( i n t wHint , i n t hHint ) {24 Dimension dim = th is . getLayoutManager ( ) . ge tPre fe r redS ize ( this , wHint ,

hHint ) ;26 return new Dimension ( dim . width , dim . he igh t ) ;

}28

}

Code extract C.9: StepBodyFigure.java

We mentioned in the requirements (Section 6.1) that the properties of a Step have tobe visualized on the diagram. The class that is responsible for painting the accordingsymbols is the StepPainter, it is visible in Code extract C.10.

1 package game . diagram . f i g u r e s ;

3 import org . ec l i pse . draw2d . ColorConstants ;import org . ec l i pse . draw2d . Graphics ;

5 import org . ec l i pse . draw2d . geometry . Po in t ;import org . ec l i pse . draw2d . geometry . P o i n t L i s t ;

7 import org . ec l i pse . draw2d . geometry . Prec is ionRectang le ;import org . ec l i pse . draw2d . geometry . Rectangle ;

9

/∗11 ∗ Implementat ion based on BPMN example

∗ /13 public class StepPain ter {

15 /∗ ∗∗ Pain ts the plus symbol f o r v i s u a l i z i n g a SubFlow

17 ∗∗ @param Graphics

19 ∗ The Graphics ob jec t used f o r p a i n t i n g∗ @param Rectangle

21 ∗ symbol bounds∗ /

23 public s t a t i c void paintSubFlow ( Graphics graphics , Rectangle f i gRec t ) {graphics . pushState ( ) ;

25

i n t middleX = f i gRec t . width / 2 ;27 i n t middleY = f i gRec t . he igh t / 2 ;

29 / / h o r i z o n t a l l i n ePo in t p1 = new Poin t ( f i gRec t . x , f i gRec t . y + middleY ) ;

31 Poin t p2 = new Poin t ( f i gRec t . x + f i gRec t . width , f i gRec t . y + middleY ) ;

33 / / v e r t i c a l l i n ePo in t p3 = new Poin t ( f i gRec t . x + middleX , f i gRec t . y ) ;

35 Poin t p4 = new Poin t ( f i gRec t . x + middleX , f i gRec t . y + f i gRec t . he igh t ) ;

37 graphics . setForegroundColor ( ColorConstants . b lack ) ;graphics . drawRectangle ( f i gRec t ) ;

39

graphics . setL ineWidth ( 2 ) ;41

graphics . drawLine ( p1 , p2 ) ;43 graphics . drawLine ( p3 , p4 ) ;


47

/∗ ∗49 ∗ Pain ts the pause symbol f o r v i s u a l i z i n g a m u l t i ins tance step





public s t a t i c void p a i n t M u l t i I n s t a n c e ( Graphics graphics , Rectangle f i gRec t ) {57


i n t spacing = 2;61 i n t barSize = 3;

i n t middleX = f i gRec t . width / 2 ;63

/ / f i r s t rec tang le o f pause symbol65 Rectangle rec t1 = new Rectangle ( ) ;

rec t1 . x = f i gRec t . x + middleX − spacing − barSize ;67 rec t1 . y = f i gRec t . y ;

rec t1 . width = barSize ;69 rec t1 . he igh t = f i gRec t . he igh t ;

71 / / second rec tang le o f pause symbolRectangle rec t2 = new Rectangle ( ) ;

73 rec t2 . x = f i gRec t . x +middleX + spacing ;rec t2 . y = f i gRec t . y ;

75 rec t2 . width = barSize ;rec t2 . he igh t = f i gRec t . he igh t ;

77


81 graphics . drawRectangle ( rec t1 ) ;graphics . drawRectangle ( rec t2 ) ;

83

graphics . f i l l R e c t a n g l e ( rec t1 ) ;85 graphics . f i l l R e c t a n g l e ( rec t2 ) ;


89

/∗ ∗91 ∗ Pain ts the rewind symbol f o r v i s u a l i z i n g compensation steps




public s t a t i c void paintCompensation ( Graphics graphics , Rectangle rewRect ) {99


i n t middleX = rewRect . x + rewRect . he igh t / 2 ;103 i n t middleY = rewRect . y + rewRect . width / 2 ;

i n t s ize = rewRect . he igh t ;105

/ / f i r s t t r i a n g l e o f rewind symbol107 P o i n t L i s t po in ts1 = new P o i n t L i s t ( ) ;

po in ts1 . addPoint ( rewRect . x , middleY ) ;109 po in ts1 . addPoint ( middleX , middleY + s ize / 2) ;

po in ts1 . addPoint ( middleX , middleY − s ize / 2) ;111

/ / second t r i a n g l e o f rewind symbol113 P o i n t L i s t po in ts2 = new P o i n t L i s t ( ) ;

po in ts2 . addPoint ( middleX , middleY ) ;115 po in ts2 . addPoint ( rewRect . x + rewRect . width , middleY + s ize / 2) ;

po in ts2 . addPoint ( rewRect . x + rewRect . width , middleY − s ize / 2) ;117


121 graphics . drawPolygon ( po in ts1 ) ;graphics . drawPolygon ( po in ts2 ) ;

123

graphics . f i l l P o l y g o n ( po in ts1 ) ;125 graphics . f i l l P o l y g o n ( po in ts2 ) ;



129

/∗ ∗131 ∗ Pain ts the squared brackets arround the i n s t a n t i a t i o n c o nd i t i on l a b e l




public s t a t i c void p a i n t I n s t a n t i a t i o n C o n d i t i o n L a b e l ( Graphics graphics , Rectangle r e c t ) {139

graphics . pushState ( ) ;141 i n t paddingX = 1;

i n t paddingY = 2;143 i n t x = r e c t . x + paddingX ;

i n t y = r e c t . y + paddingY ;145 i n t he igh t = r e c t . he igh t − 2∗paddingY ;

i n t width = r e c t . width − 2∗paddingX ;147 i n t wSize = 7;

149 graphics . setForegroundColor ( ColorConstants . b lack ) ;graphics . setBackgroundColor ( ColorConstants . b lack ) ;

151

/∗ l e f t square bracket153 ∗ p2 p1

∗ |−−−−−−155 ∗ |

∗ |−−−−−−157 ∗ p3 p4

∗ /159 Poin t p1 = new Poin t ( x + wSize , y ) ;

Po in t p2 = new Poin t ( x , y ) ;161 Poin t p3 = new Poin t ( x , y + he igh t ) ;

Po in t p4 = new Poin t ( x + wSize , y + he igh t ) ;163 graphics . drawLine ( p1 , p2 ) ;

graphics . drawLine ( p2 , p3 ) ;165 graphics . drawLine ( p3 , p4 ) ;

167 /∗ r i gh t squa re bracket∗ p5 p6

169 ∗ −−−−−−|∗ |

171 ∗ −−−−−−|∗ p8 p7

173 ∗ /Po in t p5 = new Poin t ( x + width − wSize , y ) ;

175 Poin t p6 = new Poin t ( x + width , y ) ;Po in t p7 = new Poin t ( x + width , y + he igh t ) ;

177 Poin t p8 = new Poin t ( x + width − wSize , y + he igh t ) ;graphics . drawLine ( p5 , p6 ) ;


181


}

Code extract C.10: StepPainter.java

This symbols for representing the properties of a Step may not by placed anywhere welike. The StepPropertyFigure, visible in Code extract C.11, will hold all the symbols.package game . diagram . f i g u r e s ;

2

import org . ec l i pse . draw2d . ColorConstants ;4 import org . ec l i pse . draw2d . Graphics ;

import org . ec l i pse . draw2d . IF igu re ;6 import org . ec l i pse . draw2d . RectangleFigure ;

import org . ec l i pse . draw2d . geometry . Dimension ;8 import org . ec l i pse . gmf . runt ime . draw2d . u i .mapmode . IMapMode ;

import org . ec l i pse . gmf . runt ime . draw2d . u i .mapmode . MapModeUtil ;10 /∗


∗ Implementat ion based on BPMN example12 ∗ /

public class StepProper tyF igure extends RectangleFigure {14

/ / should be an even number . . . makes c a l c u l a t i o n s eas ie r16 private s t a t i c i n t f i xedHe igh t = 12;

18 public s t a t i c f i n a l i n t getFixedHeightDP ( IF igu re f i g ) {return MapModeUtil . getMapMode ( f i g ) . LPtoDP ( f i xedHe igh t ) ;

20 }

22 public s t a t i c f i n a l i n t getFixedHeightDP ( IMapMode mapmode) {return mapmode . LPtoDP ( f i xedHe igh t ) ;

24 }

26 public StepProper tyF igure ( IMapMode mapmode) {Dimension dim = new Dimension ( getFixedHeightDP (mapmode) ,

28 getFixedHeightDP (mapmode) ) ;super . se tPre fe r redS ize ( dim ) ;

30 th is . setOpaque ( true ) ;th is . setBackgroundColor ( ColorConstants . b lack ) ;

32 }

34 @Overridepublic Dimension getMaximumSize ( ) {

36 return new Dimension ( super . getMaximumSize ( ) . width ,getFixedHeightDP ( th is ) ) ;

38 }

40 @Overridepublic Dimension getMinimumSize ( i n t wHint , i n t hHint ) {

42 return new Dimension ( super . getMinimumSize ( wHint , hHint ) . width ,getFixedHeightDP ( th is ) ) ;

44 }

46 @Overridepublic void pa in tF igu re ( Graphics graphics ) {

48 / / no th ing : t ransparen t}

50

}

Code extract C.11: StepPropertyFigure.java

C.2.3. game.diagram.sheet Package

This package holds the two classes that are needed to make the ActivitySectionDialog andthe FlowSelectionDialog appear.The CustomizedPropertyDescriptor checks if the instance treated is an Activity or a Flow andbuilds up the speci�c dialog. Code extract C.12 shows in detail how this is done.

1 package game . diagram . sheet ;

3 import game . A c t i v i t y ;import game . Flow ;

5 import game . diagram . d ia log . Ac t i v i t yFunc t ionWrapper ;import game . diagram . d ia log . A c t i v i t y S e l e c t i o n D i a l o g ;

7 import game . diagram . d ia log . F lowSelec t ionDia log ;

9 import org . ec l i pse . emf .common. u i . c e l l e d i t o r . Ex tendedDia logCel lEd i to r ;import org . ec l i pse . emf . ecore . E C l a s s i f i e r ;

11 import org . ec l i pse . emf . ecore . EDataType ;import org . ec l i pse . emf . ecore . ESt ruc tu ra lFea tu re ;

13 import org . ec l i pse . emf . e d i t . p rov ide r . I I t emPrope r t yDesc r i p to r ;import org . ec l i pse . emf . e d i t . u i . p rov ide r . P roper t yDesc r ip to r ;

15 import org . ec l i pse . j f a c e . v iewers . C e l l E d i t o r ;import org . ec l i pse . j f a c e . window . Window ;

17 import org . ec l i pse . swt . widgets . Composite ;


import org . ec l i pse . swt . widgets . Cont ro l ;19

import com. swisscom .oms . p lug ins . clom . core . model . FlowReference ;21 /∗ ∗

∗ Returns the customized proper ty d e s c r i p t o r f o r re fe renc ing the f low or23 ∗ the a c t i v i t y i n OMS a r t i f a c t s

∗ @author tgdromau25 ∗

∗ /27 public class CustomizedProper tyDescr ip tor extends Proper t yDesc r ip to r {

29 public CustomizedProper tyDescr ip tor ( Object ob jec t ,I I t emPrope r t yDesc r i p to r i t emProper t yDesc r ip to r ) {

31 super ( ob jec t , i t emProper t yDesc r ip to r ) ;}

33

/∗ ∗35 ∗ Returns the c e l l e d i t o r t h a t i s used to e d i t the proper ty which t h i s

∗ proper ty d e s c r i p t o r descr ibes37 ∗ @return C e l l E d i t o r

∗ @param Composite39 ∗ /

public C e l l E d i t o r c rea tePrope r t yEd i t o r ( Composite composite ) {41 C e l l E d i t o r r e s u l t = super . c rea tePrope r t yEd i t o r ( composite ) ;

i f ( r e s u l t == nul l )43 return r e s u l t ;

E C l a s s i f i e r eType = ( ( ESt ruc tu ra lFea tu re ) i t emProper t yDesc r ip to r45 . getFeature ( ob jec t ) ) . getEType ( ) ;

i f ( ob jec t instanceof A c t i v i t y ) {47 i f ( eType instanceof EDataType ) {

EDataType eDataType = ( EDataType ) eType ;49 i f ( eDataType . get Ins tanceClass ( ) == S t r i n g . class ) {

r e s u l t = new ExtendedDia logCel lEd i to r ( composite ,51 ge tEd i tLabe lP rov ide r ( ) ) {

protected Object openDialogBox ( Cont ro l ce l lEd i torWindow ) {53 / / c rea te an new a c t i v i t y d ia log ins tance

A c t i v i t y S e l e c t i o n D i a l o g d ia log = new A c t i v i t y S e l e c t i o n D i a l o g (55 ce l lEd i torWindow . ge tShe l l ( ) ,

ce l lEd i torWindow . getParent ( ) ) ;57

d ia log . c reate ( ) ;59

i f ( d ia log . open ( ) == Window .OK) {61 Object d ia logResu l t = d ia log . getResu l t ( ) [ 0 ] ;

i f ( d ia logResu l t instanceof Act iv i t yFunc t ionWrapper ) {63 Act iv i t yFunc t ionWrapper wrap = ( Ac t i v i t yFunc t ionWrapper ) d ia logResu l t ;

S t r i n g res = wrap . g e t A c t i v i t y ( )65 . getAct iv i tyName ( )

+ " : "67 + wrap . getFunct ion ( )

. getFunctionName ( ) ;69 return res ;

}71 return nul l ;

}73 return nul l ;

}75 } ;

}77 }

}79 i f ( ob jec t instanceof Flow ) {

i f ( eType instanceof EDataType ) {81 EDataType eDataType = ( EDataType ) eType ;

i f ( eDataType . get Ins tanceClass ( ) == S t r i n g . class ) {83 r e s u l t = new ExtendedDia logCel lEd i to r ( composite ,

ge tEd i tLabe lP rov ide r ( ) ) {85 protected Object openDialogBox ( Cont ro l ce l lEd i torWindow ) {

/ / c reate a f low d ia log ins tance87 FlowSelec t ionDia log d ia log = new FlowSelec t ionDia log (

ce l lEd i torWindow . ge tShe l l ( ) ) ;89

d ia log . c reate ( ) ;


91

i f ( d ia log . open ( ) == Window .OK) {93 Object d ia logResu l t = d ia log . getResu l t ( ) [ 0 ] ;

i f ( d ia logResu l t instanceof FlowReference ) {95 FlowReference f low = ( FlowReference ) d ia logResu l t ;

S t r i n g res = f low . getFlowName ( ) + " : "97 + f low . getVers ion ( ) ;

return res ;99 }

return nul l ;101 }

return nul l ;103 }

} ;105 }

}107 }

return r e s u l t ;109 }

}

Code extract C.12: CustomizedPropertyDescriptor.java

In order that the CustomizedPropertyDescriptor gets called we need to provide a Customized-PropertySource that returns our CustomizedPropertyDescriptor, as you can see in Code ex-tract C.13.

package game . diagram . sheet ;2

import org . ec l i pse . emf . e d i t . p rov ide r . I I t emPrope r t yDesc r i p to r ;4 import org . ec l i pse . emf . e d i t . p rov ide r . I I temProper tySource ;

import org . ec l i pse . emf . e d i t . u i . p rov ide r . PropertySource ;6 import org . ec l i pse . u i . views . p r o p e r t i e s . IP rop e r t yDe sc r i p t o r ;

8 public class CustomizedPropertySource extends PropertySource {

10 public CustomizedPropertySource ( Object ob jec t ,I I temProper tySource i temPropertySource ) {

12 super ( ob jec t , i temPropertySource ) ;}

14

protected IP rop e r t yD esc r i p t o r c rea teProper t yDesc r ip to r (16 I I t emPrope r t yDesc r i p to r i t emProper t yDesc r ip to r ) {

return new CustomizedProper tyDescr ip tor ( ob jec t , i t emProper t yDesc r ip to r ) ;18 }

20

}

Code extract C.13: CustomizedPropertySource.java

DCommon Acronyms

ADSL Asymmetric Digital Subscriber Line

API Application Programming Interface

AWT Abstract Window Toolkit

BPDM Business Process De�nition Meta Model

BPEL Business Process Execution Language

BPEL4WS Business Process Execution Language for Web Services

BPM Business Process Modeling

BPMI Business Process Modeling Initiative

BPML Business Process Modeling Language

BPMN Business Process Modeling Notation

BPRI Business Process Runtime Interface

BPSS Business Process Speci�cation System

BRMS Business Rule Management System

CLOM Clean Order Manager

CuC Customer Care

CVS Concurrent Versions System

ECTS European Credit Transfer System

EMF Eclipse Modeling Framework

GAME Graphical Aspect Model Editor

GEF Graphical Editing Framework

GIF Graphics Interchange Format

GMF Graphical Modeling Framework

HIT Human Intelligence Task

IDE Integrated Development Environment

144

145

IP Internet Protocol

IT Information Technology

IVR Interactive Voice Response

JAR Java Archive

JDK Java Devlopment Kit

JFC Java Foudation Classes

JRE Java Runtime Environment

KPI Key Performance Indicators

MDA Model-Driven Architecture

MIC Mail Inbound Center

MVC Model View Controller

OASIS Organization for the Advancement of Structured Information Standards

OMG Object Management Group

OMS Order Management Swisscom

OSGi Open Services Gateway Initiative

PDF Portable Document Format

PNG Portable Network Graphics

RCP Rich Client Platform

SDK Software Development Kit

SVG Scalable Vector Graphics

SWT Standard Widget Toolkit

UI User Interface

UML Uni�ed Modeling Language

VoIP Voice over Internet Protocol

WAPI Work�ow API

WfMC Work�ow Management Coalition

WS-CDL Web Service Choreography Description Language

W3C World Wide Web Consortium

XML Extensible Markup Language

XPDL XML Process De�nition Language

XSLT Extensible Stylesheet Language Transformations

ELicense of the Documentation

Copyright (c) 2007 Marsha Rohrer.

Permission is granted to copy, distribute and/or modify this document under the termsof the GNU Free Documentation License, Version 1.2 or any later version published bythe Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and noBack-Cover Texts.

The GNU Free Documentation Licence can be read from [16].

146

FWebsite of the Project

The Software Engineering Group of the University of Fribourg created a web site for thisMaster Thesis: http://diuf.unifr.ch/softeng/student-projects/completed/rohrer/index.html.

On this page you will �nd:

• This paper as a Portable Document Format (PDF).

• A short presentation as PDF slides.

• The Javadoc for the Graphical Aspect Model Editor (GAME).

• The test environment (GAME plug-in, dummy plug-in).

• The source code of GAME.

147

GCD-ROM

On the CD-ROM of the project you �nd:

• The speci�cation of this Master Thesis in the specification folder.

• The source code of GAME in the src folder.

• The Javadoc for GAME in the javadoc folder.

• The code and the PDF of that paper in the documentation folder.

• The �nal presentation of the Master Thesis.

• A test environment containing of the GAME plug-in and a dummy plug-in providinga miniature OMS environment in the test environment folder.

• Everything that is needed to generate the code by yourself in the generation folder.

• The mindmap example mentioned in this paper in the mindmap example folder.

• Various documents that proved to be of great help for this Master Thesis in theuseful stuff folder.

148

References

[All07] OSGi Alliance. About the OSGi Service Platform. Technical report, OSGiAlliance, June 2007. [Retrieved July 18, 2007, from http://www.osgi.org/

documents/collateral/OSGiTechnicalWhitePaper.pdf].

[FB03] Ed Merks Raymond Ellersick Timothy J. Grose Frank Budinsky, David Stein-berg. Eclipse Modeling Framework: A Developer's Guide. Addison Wesley,2003.

[Hav05] Michael Havey. Essential Business Process Modeling. O'Reilly, 2005.

[JM06] Jean-Michel Lemieux Je� McA�er. Eclipse Rich Client Platform. Addison Wes-ley, 2006.

[Kri07] Peter Kriens. Osgi best practices!, 2007. [Retrieved November 15, 2007, fromhttp://developers.sun.com/learning/javaoneonline/2007/pdf/TS-1419.pdf].

[Mad07] Rajkumar C Madhuram. Dynamic wizard modeling with GMF. Eclipse Maga-zine [online], 6, 2007. [Retrieved August 3, 2007, from http://www.eclipsemag.

net/eclipse_magazine/psecom,id,6,language,,.html].

[ML06] Philipp Rettberg Matthias Lau. Magische momente mit GMF. Eclipse Magazin[online], 8, 2006. [Retrieved August 2, 2007, from http://eclipse-magazin.de/

itr/online_artikel/psecom,id,841,nodeid,230.html].

[Ric07] Je� Richley. Gmf: Beyond the wizards. ONJava.com, July 2007. [RetrievedAugust 10, 2007, from http://www.onjava.com/pub/a/onjava/2007/07/11/

gmf-beyond-the-wizards.html?CMP=OTC-FP2116136014&ATT=GMF+Beyond+the+

Wizards].

[Ser] Swisscom IT Services. Brief portrait. [Retrieved Septem-ber 25, 2007, from http://www.swisscom.com/NR-IT/NR/rdonlyres/

E18CE556-FB85-4A3F-90AF-68D0936E4A8C/0/070511_Enterpriseshortportrait_

EN.pdf].

[vM06] Marco van Meegen. Diagramme selbst gemalt. Eclipse Magazin Ausgabe [online],4.2005, 2006. [Retrieved August 2, 2007, from http://entwickler.com/itr/

online_artikel/show.php3?nodeid=97&id=756].

[Wal05] Tilman Walther. Architektur und konzepte von eclipse 3, 2005. [RetrievedNovember 21, 2007, from http://www.tilman.de/uni/Eclipse3.pdf].

149

http://www.osgi.org/documents/collateral/OSGiTechnicalWhitePaper.pdf

http://www.osgi.org/documents/collateral/OSGiTechnicalWhitePaper.pdf

http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-1419.pdf

http://www.eclipsemag.net/eclipse_magazine/psecom,id,6,language,,.html

http://www.eclipsemag.net/eclipse_magazine/psecom,id,6,language,,.html

http://eclipse-magazin.de/itr/online_artikel/psecom,id,841,nodeid,230.html

http://eclipse-magazin.de/itr/online_artikel/psecom,id,841,nodeid,230.html

http://www.onjava.com/pub/a/onjava/2007/07/11/gmf-beyond-the-wizards.html?CMP=OTC-FP2116136014&ATT=GMF+Beyond+the+Wizards



http://www.swisscom.com/NR-IT/NR/rdonlyres/E18CE556-FB85-4A3F-90AF-68D0936E4A8C/0/070511_Enterpriseshortportrait_EN.pdf



http://entwickler.com/itr/online_artikel/show.php3?nodeid=97&id=756

http://entwickler.com/itr/online_artikel/show.php3?nodeid=97&id=756

http://www.tilman.de/uni/Eclipse3.pdf

Referenced Web Resources

[1] Business Process Modeling Notation (BPMN) Information. http://www.bpmn.org/(accessed July 20, 2007).

[2] Business process. http://en.wikipedia.org/wiki/Business_process (accessedOctober 15, 2007).

[3] GEF Programmer's Guide. http://help.eclipse.org/help32/index.jsp?

topic=/org.eclipse.gef.doc.isv/guide/guide.html (accessed October 4,2007).

[4] Developer Guide to the GMF Runtime Framework. http://help.eclipse.org/

help32/index.jsp?topic=/org.eclipse.gmf.doc/prog-guide/runtime/index.

html (accessed October 4, 2007).

[5] Eclipse STP BPMN Presentation. http://wiki.eclipse.org/STP_BPMN_

Presentation (accessed August 7, 2007).

[6] Eclipse Download Site. http://www.eclipse.org/downloads/ (accessed November15, 2007).

[7] Eclipse Modeling Framework (EMF). http://www.eclipse.org/modeling/emf/

(accessed July 20, 2007).

[8] Graphical Editing Framework (GEF). http://www.eclipse.org/gef/ (accessedJuly 20, 2007).

[9] Eclipse Graphical Modeling Framework. http://www.eclipse.org/gmf/ (accessedJuly 20, 2007).

[10] Eclipse Wiki. http://wiki.eclipse.org/Main_Page (accessed July 20, 2007).

[11] Eclipse Newcomers FAQ. http://www.eclipse.org/home/newcomers.php (ac-cessed July 22, 2007).

[12] Eclipse Plugin Central. http://www.eclipseplugincentral.com/ (accessedNovember 21, 2007).

[13] Eclipse Modeling Framework (EMF). http://www.devx.com/Java/Article/29093(accessed July 20, 2007).

[14] EOrders, Swisscom. www.swisscom.com/eorders (accessed December 12, 2007).

[15] Eclipse Equinox. http://www.eclipse.org/equinox/ (accessed July 20, 2007).

[16] Free Documentation Licence (GNU FDL). http://www.gnu.org/licenses/fdl.

txt (accessed July 30, 2007).

150

http://www.bpmn.org/

http://en.wikipedia.org/wiki/Business_process

http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.gef.doc.isv/guide/guide.html

http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.gef.doc.isv/guide/guide.html

http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.gmf.doc/prog-guide/runtime/index.html



http://wiki.eclipse.org/STP_BPMN_Presentation

http://wiki.eclipse.org/STP_BPMN_Presentation

http://www.eclipse.org/downloads/

http://www.eclipse.org/modeling/emf/

http://www.eclipse.org/gef/

http://www.eclipse.org/gmf/

http://wiki.eclipse.org/Main_Page

http://www.eclipse.org/home/newcomers.php

http://www.eclipseplugincentral.com/

http://www.devx.com/Java/Article/29093

www.swisscom.com/eorders

http://www.eclipse.org/equinox/

http://www.gnu.org/licenses/fdl.txt

http://www.gnu.org/licenses/fdl.txt

Referenced Web Resources 151

[17] GMF Tutorial. http://wiki.eclipse.org/index.php/GMF_Tutorial (accessedJuly 20, 2007).

[18] GMF Project Plan. http://wiki.eclipse.org/index.php/GMF_Project_Plan

(accessed December 3, 2007).

[19] ILOG: Business rule management, rules engine, optimization and visualization soft-ware components. http://www.ilog.com (accessed July 20, 2007).

[20] Java Download Site. http://java.sun.com/javase/downloads/index.jsp (ac-cessed November 15, 2007).

[21] ILOG JViews Visualization Products. http://www.ilog.com/products/jviews/

(accessed September 7, 2007).

[22] Model View Controller. http://en.wikipedia.org/wiki/

Model-view-controller (accessed November 2, 2007).

[23] Eclipse NewsPortal - eclipse.modeling.gmf. http://www.eclipse.org/newsportal/thread.php?group=eclipse.modeling.gmf (accessed November 27, 2007).

[24] Prozessmanagement. http://de.wikipedia.org/wiki/Prozessmanagement (ac-cessed October 15, 2007).

[25] Rete Algorithm. http://en.wikipedia.org/wiki/Rete_algorithm (accessed De-cember 12, 2007).

[26] Alexander Ryan. What is a Business Process. http://www.visualocity.net/

articles/whatIsABusinessProcess.jsp (accessed November 27, 2007).

[27] STP BPMN Modeler Overview. http://www.eclipse.org/stp/bpmn/ (accessedAugust 8, 2007).

[28] SWT: The Standard Widget Toolkit. http://www.eclipse.org/swt/ (accessedOctober 10, 2007).

http://wiki.eclipse.org/index.php/GMF_Tutorial

http://wiki.eclipse.org/index.php/GMF_Project_Plan

http://www.ilog.com

http://java.sun.com/javase/downloads/index.jsp

http://www.ilog.com/products/jviews/

http://en.wikipedia.org/wiki/Model-view-controller

http://en.wikipedia.org/wiki/Model-view-controller

http://www.eclipse.org/newsportal/thread.php?group=eclipse.modeling.gmf

http://www.eclipse.org/newsportal/thread.php?group=eclipse.modeling.gmf

http://de.wikipedia.org/wiki/Prozessmanagement

http://en.wikipedia.org/wiki/Rete_algorithm

http://www.visualocity.net/articles/whatIsABusinessProcess.jsp

http://www.visualocity.net/articles/whatIsABusinessProcess.jsp

http://www.eclipse.org/stp/bpmn/

http://www.eclipse.org/swt/

Index

A

Abstract Window Toolkit . . . . . . . . . . . . . . . 35

Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . .60

Before GAME. . . . . . . . . . . . . . . . . . . . . . .60

With GAME. . . . . . . . . . . . . . . . . . . . . . . . 61

AWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

B

BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

BPML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10, 52

BPSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Business Process . . . . . . . . . . . . . . . . . . . . . . . . . 8

C

Clean Order Manager . . . . . . . . . . . . . . . . . . . 16

CLOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16, 19

Code Generation . . . . . . . . . . . . . . . . . . . . . . . . 95

Con�guration Files . . . . . . . . . . . . . . . . . . 47, 73

Domain Model . . . . . . . . . . . . . . . . . . . . . . 74

Graphical De�nition . . . . . . . . . . . . . 48, 75

Tooling De�nition . . . . . . . . . . . . . . . 48, 76

Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Core Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Custom Figures . . . . . . . . . . . . . . . . . . . . . . . . . 77

Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Invisible . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Step Body Figure . . . . . . . . . . . . . . . . . . . 78

Step Figure . . . . . . . . . . . . . . . . . . . . . . . . . 78

Step Property Figure. . . . . . . . . . . . . . . .79

Customization . . . . . . . . . . . . . . . . . . . . . . . . . . 49

D

Declarative . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 19

Development Cycle . . . . . . . . . . . . . . . . . . . . .100

Development Tool

Requirements . . . . . . . . . . . . . . . . . . . . . . . 50

Technology . . . . . . . . . . . . . . . . . . . . . . 50, 56

Diagram Plug-in . . . . . . . . . . . . . . . . . . . . . . . . 67

Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Domain Model. . . . . . . . . . . . . . . . . . . . . . .63, 74

E

Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

EMF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Equinox. . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 33

Extension points . . . . . . . . . . . . . . . . . . . . 34

Extension Registry . . . . . . . . . . . . . . . . . . 33

Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 34

GEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

GMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

JFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Plug-in. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

RCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

SWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Target platform . . . . . . . . . . . . . . . . . . . . . 39

UI-Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . 35

Workbench. . . . . . . . . . . . . . . . . . . . . . . . . .38

Ecore Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Editor Plug-in. . . . . . . . . . . . . . . . . . . . . . . . . . .66

EMF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Domain Model . . . . . . . . . . . . . . . . . . . . . . 48

Ecore Model . . . . . . . . . . . . . . . . . . . . . . . . 48

Edit Code. . . . . . . . . . . . . . . . . . . . . . . . . . .44

Editor Code. . . . . . . . . . . . . . . . . . . . . . . . .44

Model Code . . . . . . . . . . . . . . . . . . . . . . . . . 44

Test Code. . . . . . . . . . . . . . . . . . . . . . . . . . .44

Equinox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Etid Plug-in. . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

Exportable XML formats . . . . . . . . . . . . . . . .11

Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Extension, Extension Point . . . . . . . . . . . . . . 34

Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

F

Forward Chaining . . . . . . . . . . . . . . . . . . . . . . . 11

152

Index 153

G

GAME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

*.game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Code Generation . . . . . . . . . . . . . . . . . . . . 95

Core Plug-in . . . . . . . . . . . . . . . . . . . . . . . . 65

Create Mandatory Steps . . . . . . . . . . . 103

Create Optional Steps . . . . . . . . . . . . . 104

Custom Figures . . . . . . . . . . . . . . . . . . . . . 77

Diagram Plug-in . . . . . . . . . . . . . . . . . . . . 67

Domain Model . . . . . . . . . . . . . . . . . . 63, 74

Ecore Model . . . . . . . . . . . . . . . . . . . . . . . . 74

Edit Plug-in . . . . . . . . . . . . . . . . . . . . . . . . 66

Editor Plug-in . . . . . . . . . . . . . . . . . . . . . . 66

Embedding . . . . . . . . . . . . . . . . . . . . . . . . . 96

Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 110

Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 110

Graphical De�nition . . . . . . . . . . . . . . . . 75

Improvements . . . . . . . . . . . . . . . . . . . . . .110

Integration . . . . . . . . . . . . . . . 25, 61, 63, 96

Mapping Model . . . . . . . . . . . . . . . . . . . . . 76

Model Sightseeing Tour . . . . . . . . . . . . 103

Name as ID . . . . . . . . . . . . . . . . . . . . . . . . . 92

OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24, 88

Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Predecessor Relation . . . . . . . . . . . . . . . 107

Remove Tools . . . . . . . . . . . . . . . . . . . . . . . 94

Sequence of Steps . . . . . . . . . . . . . . . . . . 105

Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Step Markers . . . . . . . . . . . . . . . . . . . . . . 106

Tooling De�nition . . . . . . . . . . . . . . . . . . . 76

Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Using . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

GEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

GMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43, 57

Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Con�guration Files . . . . . . . . . . . . . . . . . . 47

Customization . . . . . . . . . . . . . . . . . . . . . . 49

Domain Model . . . . . . . . . . . . . . . . . . . . . . 48

Ecore Model . . . . . . . . . . . . . . . . . . . . . . . . 48

EMF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 110

Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 49

GEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Generator Model . . . . . . . . . . . . . . . . . . . . 48

gmfgen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

gmfgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

gmfmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

gmftool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Graphical De�nition . . . . . . . . . . . . . . . . 48

Mapping Model . . . . . . . . . . . . . . . . . . . . . 48

Mindmap Example. . . . . . . . . . . . . . . . .114

Model View Controller . . . . . . . . . . . . . . 46

Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Semantic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Tooling De�nition . . . . . . . . . . . . . . . . . . . 48

Graphical De�nition . . . . . . . . . . . . . . . . . 48, 75

Graphical Modeling Framework . . . . . . 43, 57

H

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

I

Imperative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 73

Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Image Generation . . . . . . . . . . . . . . . . . . 111

Predecessor Relation . . . . . . . . . . . . . . . 110

Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Sub�ow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Validation . . . . . . . . . . . . . . . . . . . . . . . . . 111

Integration . . . . . . . . . . . . . . . . . . . . . . . . . . 25, 61

Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

J

Java

AWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

JFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

M

Mapping Model. . . . . . . . . . . . . . . . . . . . . .48, 76

Master Thesis

Aim. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Organization . . . . . . . . . . . . . . . . . . . . . . . . . 4

Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Task description. . . . . . . . . . . . . . . . . . . . . .2

Workload . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Worst-case-scenario . . . . . . . . . . . . . . . . . . 4

Meta Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Mindmap Example . . . . . . . . . . . . . . . . . . . . . 114

Model View Controller . . . . . . . . . . . . . . . . . . 46

N

Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6, 46

O

OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13, 60

Architecture . . . . . . . . . . . . . . . . . . . . . . . . 16

Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

CLOM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Index 154

CLOM Algorithm . . . . . . . . . . . . . . . . . . . 19

Declarative Description . . . . . . . . . . . . . 17

Domain Logic . . . . . . . . . . . . . . . . . . . . . . . 16

Entry Channels . . . . . . . . . . . . . . . . . 14, 16

GAME . . . . . . . . . . . . . . . . . . . . . . . . . . 24, 88

Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Order Entry . . . . . . . . . . . . . . . . . . . . . . . . 16

Process Engine . . . . . . . . . . . . . . . . . . . . . . 16

Process Logic . . . . . . . . . . . . . . . . . . . . . . . 16

Sightseeing Tour . . . . . . . . . . . . . . . . . . . . 21

Terminology . . . . . . . . . . . . . . . . . . . . . . . . 14

Order Management Swisscom . . . . . . . . . . . 13

OSGi Speci�cation . . . . . . . . . . . . . . . . . . . . . . 29

Equinox. . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Implementations . . . . . . . . . . . . . . . . . . . . 32

Lifecycle Layer . . . . . . . . . . . . . . . . . . . . . . 31

Module Layer . . . . . . . . . . . . . . . . . . . . . . . 30

Service Layer . . . . . . . . . . . . . . . . . . . . . . . 32

Service Registry . . . . . . . . . . . . . . . . . . . . .32

Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70

P

Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . . 33, 38, 40

Development . . . . . . . . . . . . . . . . . . . . . . . . 38

Extension points . . . . . . . . . . . . . . . . . . . . 34

Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

plugin.xml . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Process

Automation . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Business Process . . . . . . . . . . . . . . . . . . . . . 8

Teminology . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Process Automation

Bene�ts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Process Description

Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Process Engine . . . . . . . . . . . . . . . . . . . . . . . . . . 16

R

Representation

Predecessor Relation . . . . . . . . . . . . . . . . 54

Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Figure Representation . . . . . . . . . . . . . . . 52

Fundamental . . . . . . . . . . . . . . . . . . . . . . . . 51

Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

Sophisticated . . . . . . . . . . . . . . . . . . . . . . . 51

RETE Algorithm. . . . . . . . . . . . . . . . . . . . . . . .11

Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Rule Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

S

Semantic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Sightseeing Tour . . . . . . . . . . . . . . . . . . . . . . . . 21

Emergency . . . . . . . . . . . . . . . . . . . . . . . . . . 23

GAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Just in time decision . . . . . . . . . . . . . . . . 22

Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Template Rule . . . . . . . . . . . . . . . . . . . . . . 21

Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Standard Widget Toolkit . . . . . . . . . . . . . . . . 36

Standards

BPEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

BPML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

BPMN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

BPSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Exportable XML formats . . . . . . . . . . . 11

Meta Model . . . . . . . . . . . . . . . . . . . . . . . . . 11

Runtime Interface . . . . . . . . . . . . . . . . . . . 11

WS-CDL. . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Swisscom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

OMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Swisscom IT Services . . . . . . . . . . . . . . . . . 5, 13

Short Overview . . . . . . . . . . . . . . . . . . . . . . 1

Teminology . . . . . . . . . . . . . . . . . . . . . . . . . 14

SWT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

T

Target Platform . . . . . . . . . . . . . . . . . . . . . . . . . 39

Technological Study . . . . . . . . . . . . . . . . . . . . . 50

Tooling De�nition . . . . . . . . . . . . . . . . . . . 48, 76

U

UI-Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

AWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

JFace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

SWT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Using . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Create Mandatory Steps . . . . . . . . . . . 103

Create Optional Steps . . . . . . . . . . . . . 104

Sequence of Steps . . . . . . . . . . . . . . . . . . 105

Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

W

Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

WS-CDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

graphical aspect model editor (game) - diuf.unifr.ch · abstract about eight years ago, i.e. in the...

Documents