UNIVERSITÄT PADERBORN. ComponentTools

Transcription

1 UNIVERSITÄT PADERBORN ComponentTools Component Library Concept Project Group ComponentTools Alexander Gepting, Joel Greenyer, Andreas Maas, Sebastian Munkelt, Csaba Pales, Thorsten Pivl, Oliver Rohe, Markus Sanders, Andreas Scholand, and Christian Wagner Paderborn, October 7, 2005

2 Contents 1 Introduction The Library - Describing a Type of Component Based System 3 3 Formal Models and Specications The Project - Modelling a System Advanced Library and Project Model Details Compound Components Parameter Concept Assuring the Semantic Correctness of the Model Views Views and Editors Views in the Library/Project Model Working on a Project in dierent Views Tasks Summary and Outlook ii

3 List of Figures 1 Simple Library Model Extended Library Model ComponentType with Underlying Petri Net Model Including Models in the Library Including Model and Specications in the Library A project based on a Library Extended diagram of the Project and Library model Conceptual Compound Component Two ComponentTypes: Atomic- and CompoundComponent- Type Details of the CompoundComponentType Design Abstraction of Library and Project Elements ParameterDelcaration and ParameterValue Classes Project- and Geo-Editor working on the same project A View based on a Library Details of the View Design of the Library Dening View Parameters with the Library Editor Dening a Task in a Library iii

4 1 Introduction As ComponentTools is tool infrastructure that allows to model virtually any type of component based system, we need, as a basis, an application model that is generic and exible enough to describe component based systems in general. This application model will be presented in this paper. The model that will be described in this paper can be roughly devided in two conceptual parts. Firstly, there is the component library that will be introduced in section 2. The library describes a certain type of system by dening the types of components and connections that can exist in a system. Along with the component type denitions, the component library also includes formal models (see section 3) that will be used by ComponentTools later on. Secondly, when editors are used to design a specic system based on a library, a so called project is created that consists of the placed instances of the components the instances of the connections between them. The project will be introduced in section 4. The component library does not only declare a list of component and connection types that appear in a certain type of system. Furthermore, a component library can dene so called views that specify how system components will be graphically displayed in an editor. And, at last, a component library also denes tasks that describe which further actions can be performed on a designed component system model. For example, a task might invoke a model transformation and the starting of a simulation software based on the current project. Before, ComponentTools was referred to as a basis for tools. While the ComponentTools infrastructure can be seen as a generic application with a number of integrated editor- and task-plugins, the component library is actually the place where it is determined which kind of tool ComponentTools will be. So, the component library is rather a tool denition that denes which kind of system will be modelled, which kinds of editors will be displayed and which kinds of tasks will be available to perform. Technically, as ComponentTools is based on Eclipse ([3]), the library/project model were designed as EMF models (Editor Modelling Framework). EMF oers, among other things, the automated generation of viable Java code 1

5 from class diagrams. The class diagrams shown in this paper are thus EMF class diagrams drawn with the Omondo EMF class diagram editor The diagram that is the actual basis for the comonent library can be found in the plug-in de.upb.swt.componenttools.editor.core, in the package de.upb.swt.componenttools.editor.core.model. 2

6 2 The Library - Describing a Type of Component Based System As said in the introduction, the main purpose of the component library is to describe a certain type of component based system. A type of system could be our toy train system that we use as an example throughout this documentation ([6]). In a system, there are a number of dierent component types which can be connected in a certain way. Therefore, a starting point for a generic component library model could be the following class diagram (Fig. 1). Figure 1: Simple Library Model The main class in this diagram is the Library itself that can contain 0..n ComponentTypes and 0..n possible ConnectionTypes between them. But, for example, looking at the toy train system or any other complex component based system, there are a few more details that have to be considered. Component types dier from each other in the way they can be interconnected. Thinking about, for example, a switch component, there are a number of dierent connection points that can be identied. Firstly, there are the connection points where other tracks can be attached. A switch component, for example, has one incoming and two outgoing tracks and therefore specic corresponding incoming and outgoing connection points. Furthermore, to control a switch, maybe by electrical signals, it is necessary to consider connection points for signals of a controller component. So, a certain arrangement of connection points or ports, as we will call them, can be seen as the typical interface of a component type. The following class diagram (Fig. 2) shows how we introduced the PortType 3

7 class to the library model. Due to this, every port that appears in the interface of a ComponentType, a ComponentPortType, references a certain PortType. So, the ComponentPortType could be seen as an instance of a PortType that makes up the ComponentType's interface. Figure 2: Extended Library Model Furthermore, to be able to correctly connect the existing PortTypes that can appear in the ComponentType's interfaces, it is also necessary to specify the ConnectionTypes in more detail. There are only certain combinations of port types that can be connected. For example, it should not be possible to connect a signal port to a port representing an incoming track. To express these specics for a ConnectionType, each ConnectionType references ConnectablePortTypePairs. One ConnectablePortTypePair represents a possible directed connection between one source PortType and one target PortType. The class diagrams explained so far did not show how it is possbile to describe further attributes of elements like the ComponentType or ConnectionType. It is possible to do this with generic parameters. Detailed explaination of this parameter concept will be given in section 5. The following section (section 3) will explain how to include formal models in the component library. 4

8 3 Formal Models and Specications So far, we are able to describe a type of component based system by dening the component types, their interfaces and possible connections between them. But, the library does not yet allow to include formal models to the component type's description. This is illustrated in Figure 3. Figure 3: ComponentType with Underlying Petri Net Model In a library, it should be possible to include one or more kinds of formal models to the component type denition. Therefore, as the following class diagram (Fig. 4) shows, the Library denes a number of ModelTypes that can exist and the ComponentTypes can have 0..n Models corresponding to a dened ModelType. Figure 4: Including Models in the Library Now, the way that a Model is included in a ComponentType denition is very abstract. To this point, there is not even information about what exactly the model is. In fact, the way a model is technically included is left open for now. 5

9 For example, a Model object might contain a reference to a le containing a formal model in some notation. Actually, the detailed methods to include such models is still subject of further research, because the mechanism of how these models will be retrieved and transformed later on, inuences the way that models need to be stored. For example, in the scope of the ComponentTools project so far, we want to transform models like Petri nets with a transformer that interprets rules of Triple Graph Grammars (see [4] for further details). In order to use an underlying Petri net of a component type, it would be necessary to store the model along with mappings between the places and transitions on one hand and the component and its ports on the other hand. In addition to models, we also introduce specications to the library model. These specications can be included to the component types in the same way that models can be included. The conceptual dierence between models and specications is, thought, that a model is rather a formal model describing the entire component and that a specication can be used to express additional properties or contraints that apply to the component. For example, in further analysis tasks like modelchecking, the task could utilize the underlying model for modelchecking and apply contraints from the underlying specications. The following gure show the extended class diagram (Fig. 5). Figure 5: Including Model and Specications in the Library 6

10 Also, the methods to technically include specications are left open. 7

11 4 The Project - Modelling a System So far, the introduced models allow us to describe a type of system in a component library. But now, an application that uses this library information to design a specic system needs ways to store this system. A specic system in ComponentTools is called a project, which primarily stores instances of components and connections that have been dened in the library. The following gure (Fig. 6) shows basically how a Project is based on one Library and how ComponentInstances and ConnectionInstances in this Project correspond to a certain Component- and ConnectionType in the Library. Figure 6: A project based on a Library Also, this is a slightly simplied diagram that leaves out the details of how ConnectionInstances are connecting the ComponentInstances. This is shown in the next diagram (Fig. 7) which introduces the ports on both the Library and the Project level. As shown in this diagram, to describe the ComponentInstance's interface, the ComponentInstance furthermore has a number of ComponentPortInstances that correspond to the ComponentPortTypes in the Library. This model design might give the impression that the information about the component 8

12 Figure 7: Extended diagram of the Project and Library model instances' interface is modelled redundantly. Why should the information about the component's interface be copied from the type-level of the library into the instance-level in the project? Firstly, this design oers a nice way for the ConnectionInstances to just reference the ComponentPortInstances. So the ComponentType does not have to be accessed to retrieve the ports in the interface. And, secondly, the ports in the interface of the ComponentInstance might have additional parameters. For example, a signal port might be congurable to a certain electrical current. 9

13 5 Advanced Library and Project Model Details In addition to the library and project model concepts introduced so far, there are two more design details that we will present in this section. This is, rstly, the concept of compound components and, secondly, the way that arbitrary parameters can be saved along with almost all library and project classes. 5.1 Compound Components In many tools that support the design component based systems, it is possible to group a typical arrangement of components to one new unit that can be handled like one single component. In the toy train example, it might be a common practice to place a signal component in front of a switch and therefore it would be nice to group these two components into a new - compound - component. The idea is to have a component type like shown in gure 8. Figure 8: Conceptual Compound Component In the ComponentTools library, it is possbile to dene a CompoundComponentType, as the following class diagram shows (Fig. 9). What was left out for simplication in the previous sections is that there are two classes that inherit from the ComponentType class. One is the AtomicComponent- Type that is actually the class for a single component, as introduced so far. For example, the AtomicComponentType holds the formal models and specications. The other class inheriting from ComponentType is the CompoundComponentType. 10

14 Figure 9: Two ComponentTypes: Atomic- and CompoundComponentType But now, what is a CompoundComponentType compound of? It should be compound of something like a subsystem formed by instances of components and connections. So, the approach in the ComponentTools library model is to say that a CompoundComponentType consists of a project. This project would then contain the inner component and connection instances. The corresponding class diagram is shown below in gure 10. Figure 10: Details of the CompoundComponentType Design Furthermore, as the CompoundComponentType inherits the association to 11

15 the ComponentPortTypes from the general ComponentType superclass, it also denes an interface. And now, the inside ComponentInstances, or rather empty ComponentPortInstances get connected to the outside by dening a mapping: The CompoundComponentType denes a number of PortMappings that can map ComponentPortInstances of the inside ComponentInstances to its own ComponentPortTypes. These mappings are actually the dotted lines to the outside ports in gure Parameter Concept Before explaining the way that generic parameters are realized in our model, it is important to understand that, in the philosophy of the Component- Tools model, we mainly distinguish library elements and project elements. The library declares types of components, connections and ports whereas we nd instances of these declared types in a project. This philosophy is now abstracted in the superclasses as shown in the following class diagram (Fig. 11). Figure 11: Abstraction of Library and Project Elements Now, all the elements in the library as well as the Library class itself inherit from the abstract class AbstractParameterDeclarationElement. In the same way all elements in the project and the Project class inherit from the abstract class AbstractParameterValueElement. Note that these superclasses are now in charge to express the type/instance relation between library and project elements with the typeelement association. This means that the prior, more specic type/instance associations, for example, between the ComponentInstance and ComponentType or ConnectionInstance and ConnectionType (as shown in Fig. 6) are now absolete 12

16 because they are expressed by the associations between their superclasses. The following section (section 5.3) points out how these ways of modelling make it more complicated to maintain the semantic correctness of the model. With this type/instance philiosophy, the idea of parameters is such that type elements declare parameters and instance elements ll these declarations with a value. The naming of the superclasses in gure 11 already hints to this idea. For example, a toy train track component can have a variable length. Then, the component type Track declares a parameter length and each instance of a Track must provide a value for this parameter declaration. The following class diagram shows how the parameter declarations and values are modelled (Fig. 12). Figure 12: ParameterDelcaration and ParameterValue Classes This class diagram needs a little more explanation. Firstly, the Parameter- Declaration and ParameterValue classes also inherit from AbstractParameterDeclarationElement and AbstractParameterValueElement. This means on one hand, that the declaration/value relation is also expressed by the typeelement association of the superclasses (see Fig. 11). And, on the other hand, this means that each ParameterDeclaration class can have further ParameterDeclarations and every ParameterValue can have further Parameter- 13

17 Values. This is how parameters can have nested subparameters and so on. Secondly, the ParameterDeclaration class denes three attributes, the defaultvalue and two boolean attributes changeable and required. The idea of how this model is to be interpreted and, especially, how the Component- Tools software then deals with these attributes is the following: The required attribute expresses if a AbstractParameterValueElement must supply a ParameterValue for this ParameterDeclaration. Then, if a ParameterDeclaration has a defaultvalue and some AbstractParameterValueElement is created in the project, for example an instance of a track component, the Parameter- Values are initialized with the defaultvalue in the corresponding Parameter- Declaration. If the changeable attribute is set to false, it means that the instance element cannot have a parametervalue dierent from the default- Value. Especially this conguration of a ParameterDeclaration, to have an unchangeable default value, is used to express parameters that are declared and dened in the same time on the type (library) level. For example, a toy train track component might declare two parameters: A width and a length. Then, if the width is xed, the width parameter declaration is set to an unchangeable default value, whereas a variable length would be set to a changeable value. At last, the class diagram shows a StringToParameterValueMapEntry class that is located between the AbstractParameterValueElement and the ParameterValue. Behind this lies a little EMF modelling trick that allows to model qualied associations, so that ParameterValues can be retrieved by a key, instead of having to run through the whole parameter list in a while-loop every time. 5.3 Assuring the Semantic Correctness of the Model In the preceeding sections and subsections, the ComponentTools model and the corresponding conceptual ideas were introduced. The main concern when deciding between one way and another to design the model, is to keep the model as simple, general and extendable as possible. But then, in the one or other part of the model, this makes it hard to assure its semantic correctness, because some of the conceptual principles simply cannot be expressed by the EMF class diagram. 14

18 What this means and how ComponentTools faces this problem will be explained in this section with a list of examples: As explained in section 2, the ComponentTypes dene their interface by referencing a number of ComponentPortTypes. Then, on creation of a ComponentInstance object, the model does not express that the set of ComponentPortInstances has to be a congruent copy of the set of ComponentPortTypes in the type denition (see Fig. 2). Another problem is that the connection paradigm in the library expresses which types of ports may be connected with a certain type of connection. If this connection paradigm is regarded correctly has to be assured by the project editor application. The type/instance relation betweeen library and project elements is expressed on the level of the superclasses AbstractParameterDeclarationElement and AbstractParameterValueElement. They dene the typeelement association which results in a more exible way to assign type/instance relations. This was pointed out before in section 5.2. Now, according to the EMF model, it would be possible to have a ComponentType as a typeelement for a ConnectionInstance. Also, the project editor will have to take care of this. The parameter concept as explained in section 5.2 also needs extra care to be kept semantically correct. Firstly, there is the concept of having ParameterDeclarations with a default value that can be either changeable or unchangeable. Then, secondly, there can be a conguration of nested ParameterDeclarations. To these declarations, the corresponding ParameterValues need to be created accordingly by the project editor application. These are just some examples that explain why the applications working on this model need to take extra care of its semantic correctness. The paper [3] explains the architecture of the ComponentTools project editor core components that also implement a ProjectController. This controller component is used whenever an editor needs to perform operation in the model that could result in a semantic inconsistency. Also, a library editor, which has not been thoroughly implemented in the scope of the project so far, would need to implement something like a LibraryController to ensure semantically correct component libraries. 15

19 6 Views The preceeding sections presented the core concepts of the Component- Tools application model, the library and the project. Editors were mentioned at places which can use the type declarations in the library to design a certain system, a project. But, the library is so generic that we can virtually describe any component based system, we might describe a production system, a toy train system, electric circuits or even other types of systems. The question now is, how can we achieve to have specic editors for a specic type of component system? We need editors that have an adequate graphical representation of a system and editors that can support all the required editing features. For example, for electric circuits, it might be sucient to just place and connect the electrial components somewhere on a virtual canvas. But, for production systems in a factory, it would be necessary to place components on an exact physical position, so that also the oor plan of the factory can be considered. 6.1 Views and Editors So, how can we achieve to have editors with a system specic graphical representation and editing behavior? Can we describe all this in the library? Or should we implement specic editors where we can integrate exactly the editing behaviour that we need? The answer in ComponentTools is that there's a exible way to describe the graphical represenation of components, connections and ports as well as editing behavior. These views will be presented in this section. But, furthermore, ComponentTools comes with an editor framework that allows to implement and integrate other project editors (see [3] for architecture details). In fact, every editor works together with a specic view on the library/project. In the scope of our work so far, we have implemented two editors. One is a basic schematic editor, the other is a more specialized editor that allows to physically place and snap components in a certain position (see Fig 13). There are already a lot of possibilities to adapt the library, actually the views, to achieve the right editing behaviour and look with the two existing editors. If this will not be sucient, another editor can be integrated to work on yet another type of view. 16

20 Figure 13: Project- and Geo-Editor working on the same project When saying to have an editor working on a view, this means that a view will maintain the specic information needed for the graphical representation and editing behaviour in arbitrary parameters. Thus, an editor for this view will need to interpret and put to use these parameters in a right way. The rest of this section will now show how views are designed in the library/project model and how a library can dene several views so that actually several editors can work on the same project alongside. 6.2 Views in the Library/Project Model The general idea is that the Library can declare 0..n Views that represent dierent graphical views on the library elements. Furthermore, on the project level, there is a ProjectView that holds the view information for project (instance) elements. So, every project has a ProjectView for each View declared in the library. When having a closer look at the view design of the library, as illustrated in Figure 15, it can be seen that a View contains 0..n ComponentTypeView as well as ConnectionTypeView elements which both reference their equivalent 17

21 Figure 14: A View based on a Library model types, namely ComponentType and ConnectionType. A view also contains a PortTypeView which references the model type PortType, but again it has been left out due to simplication. A project primarily stores instances of components and connections that have been dened in the library. As an extension of that, a project also stores the view related information of each ComponentInstance and ConnectionInstance. ComponentInstanceView and ConnectionInstanceView itself reference a certain Component- and ConnectionTypeView in the library. Figure 15: Details of the View Design of the Library It is important to note that in a view, there does not have to be a view type element for every element in the library. They can be left out, if there's no need to see this component type, connection type or port type in this view. In the toy train example, we have a schematic view that allows to see and 18

22 edit everything, but in the Geo-View, for example, signal connections and signal ports are not important, so they can be left out in the declaration of Geo-View elements. To dene the graphical appearance of components, port and connections within a view, we make use of the formerly introduced Parameter Concept (see section 5.2). Since this concept has been implemented very generically any kind of parameter can be added. Furthermore, it is even possible to create a nested structure. In Figure 16 this has been used to dene the shape of the selected track component. Figure 16: Dening View Parameters with the Library Editor The Figure shows the library tree editor where currently the Component- TypeView object in the Geo-View for the Track-50 component type is edited (see the nodes highlighted in red). This ComponentTypeView holds a ParameterDeclaration called Polygon in which further nested ParameterDeclarations exist that have integer coordinates as defaultvalues. This is an example of how the graphical representation of a Component in the Geo- View is stored. The polygon represents the gure as that the component is painted in the editor. In the left part of Figure 16, the grey polygon of a switch component is displayed. 19

23 A more detailed introduction on how to customize components, ports, and connections of a view for dierent editors is given in [5]. 6.3 Working on a Project in dierent Views Now, we have presented the concepts to describe library and project elements and also how certain views on these elements can be dened. One question that arises from this is how dierent editors for dierent views can work on the same project simultaneously without causing inconsistencies. For example, the implemented Geo-Editor places components on an exact positions and other components can be snapped on them. But, in the schematic Project-Editor, the alignment of the components is not so obvious - what happens if components are moved or rotated in the schematic editor? Will this aect the positions in the Geo-Editor? We have seen, that elements in the views make use of the generic parameters as well as the core library elements. Therefore, we can separate parameters into core parameters and view parameters. In our concepts so far, we need to put all information needed for the designed project in the core parameters. This is all the information that futher applications like simulators, verier, modelcheckers and other analysis tools need to perform their task on the designed project. The view parameters will then only contain the information needed for the view itself. Thus, in the above example the position of the components in the Geo-Editor is something that will need to be stored in the core parameters. Because this is, for example, the relevant position information needed in a visual simulation of the system. On the contrary, the position in the schematic project editor, is only relevant inside the view and will be stored in the view parameters. Nevertheless, there are use cases where one parameter might imply the value of another. Maybe, we would like to let the physical position of the components in the Geo-View inuence the position of the components in the schematic Project-View, but not the other way around. This could be solved by introducing dependencies or implications between parameters. But, this is subject to further research. For now, the editor applications working on 20

24 the views will need to take care of implying their view parameter values based on core parameters values if needed. 21

25 7 Tasks We have mentioned ComponentTools to be a basis for tools to design component based systems. Actually it is the component library that tells the whole ComponentTools infrastructure what kind of tool it should be. The library rstly denes the type of system being worked on by dening component, port and connection types. Then it denes views on this system and, thus, which integrated editors should be opened on a project. So, the library holds more that just a list of component types, it is actually a tool description. And now, we also want the component library to specify which kind of analysis tasks can be performed on a designed system - on a project. The following class diagram (Fig. 17) shows how a Library can have 0..n Tasks. Figure 17: Dening a Task in a Library In the editor infrastructure, there can be applications integrated as Task- Plugins [3]. So, like editors correspond to views, Task-Plugins correspond to Tasks dened in the library. As a Task is actually an AbstractParameterDeclarationElement (see section 5.2), it can thus declare parameters and furtherly describe what the task should do when it is carried out. During the work of our project group we implemented two dierent example tasks. One task starts a transformation process where the model created in the project is being transformed into a Petri net using the concept of triple graph grammars (see [4] for more details). The second task provides a visual 3D simulation of the created model (see [1] for more details). These tasks that we implemented still have the most application logic in the Task-Plugin class itself and there was little use made of the possibility to describe the task behaviour in the library. This is actually still subject to further research and development. The goal would be to congure everything a task should do in the library. For example, if there's an analysis to be 22

26 carried out on a project, the following information should be in the library task denition: 1. Into which model does the project need to be transformed? 2. Which transformation mechanism should be used? 3. Based on which rules should the transformation be carried out? 4. What should be done with the transformation output? Held in the memory, written to a le? 5. Which kind of analysis tool should be stared on the output model? 6. What needs to be done to transform analysis results back to the project? A detailed description on how to create and add new tasks to your library model can be found in [5] and [2]. 23

27 8 Summary and Outlook In this paper, the generic and extendable ComponentTools application model was introduced. We have shown how a type of component based system can be described in a component library by dening the component types and possible connections between their ports. Furthermore, we have seen that the component library does more than just describe a type of system. The library is rather a tool denition that, when loaded, tells ComponentTools with which dierent editors, in which views the user can work on a component system and which futher tasks can be performed on the system model. But still, there are some open topics in the library model where further research is needed. Primarily, it has to be investigated in which way formal models can be included in the component type denition in regard to support model transformation based on Triple Graph Grammar rule interpretation [4], [7]. 24

28 Bibliography [1] Ekkart Kindler and Csaba Páles. 3D-visualization of Petri net models : Concept and realization. In Application an Theory of Petri Nets 2004, 25 th International Conference, volume 3099 of LNCS, J. Cortadella and W. Reisig, Eds., pages , June [2] A. Gepting, J. Greenyer, A. Maas, S. Munkelt, C. Páles, T. Pivl, O. Rohe, M. Sanders, A. Scholand, and C. Wagner. ComponentTools - Component Editor User Guide, [3] A. Gepting, J. Greenyer, A. Maas, S. Munkelt, C. Páles, T. Pivl, O. Rohe, M. Sanders, A. Scholand, and C. Wagner. ComponentTools - Component Project Editor Architecture, , 5.3, 6.1, 7 [4] A. Gepting, J. Greenyer, A. Maas, S. Munkelt, C. Páles, T. Pivl, O. Rohe, M. Sanders, A. Scholand, and C. Wagner. ComponentTools - Concept of Graph Transformation using Triple Graph Grammars TGG, , 7, 8 [5] A. Gepting, J. Greenyer, A. Maas, S. Munkelt, C. Páles, T. Pivl, O. Rohe, M. Sanders, A. Scholand, and C. Wagner. ComponentTools - Create your own Component Tool using the ComponentTools Infrastructure, , 7 [6] A. Gepting, J. Greenyer, A. Maas, S. Munkelt, C. Páles, T. Pivl, O. Rohe, M. Sanders, A. Scholand, and C. Wagner. ComponentTools - Project Group ComponentTools - Main Paper, [7] A. Gepting, J. Greenyer, A. Maas, S. Munkelt, C. Páles, T. Pivl, O. Rohe, M. Sanders, A. Scholand, and C. Wagner. ComponentTools - Triple Graph Grammar Interpreter Architecture,