Part 1 – Build the Workshop Layout Notation

In this section we build the visual notation for a domain focusing on the physical layout of workstations inside a workshop and how they are connected with each others.

Step 1 – First Minimal Notation

Step 1.1: Within the download package, go to the environment/workbenches directory. In this directory, create the Layout.view file. The .view extension is used to know that this file contains the specification of a notation (a view).

Step 1.2: Open this new Layout.view file with a text editor. In order to use the syntax highlighting profiles given in the package you will need Notepad++. Notepad++ recognizes the .view file extension and should automatically select the GMI View language profile when a .view file is opened.

Step 1.3: Type in or copy the following text into the file:

view "Workshop Layout" {
  rules {
  toolboxes {

This code represents the structure of a view definition for xOWL. We define a new view called "Workshop Layout". The notational elements will be defined with grammar rules to be put in the rules block. The toolboxes block will contain the definition of the toolboxes accessible to the experts.

Step 1.4: Grammar rules are written as

Head -> <body> ;

In this pattern Head is called a variable. It represents a notational element (or part of), defined by the rule’s body. Within this body, we can reuse other variables in order to compose parts of notational elements for the purpose of building bigger ones. We can also use predefined basic drawing elements, such as rectangles, text fields, etc. These are called terminals. All, these elements are organized in a rule’s body and composed using operators.

Type in or copy the following rule in the “rules” block:

AssemblyWorkstation -> [[] 139*64 |#E8B3E7|] ;

With this rule we define a new notational element called AssemblyWorkstation that is defined as a simple rectangle. This rectangle is filled with the color described by the hexadecimal RGB code and will have no border. In this high-level language, shapes are noted with the [ ... ] constructs. The inner [] indicates this is a rectangle, () would indicate an ellipse. Then the size of the shape is noted as width * height. The color code being between two pipes, it represents the color used to fill the shape.

Step 1.5: We now have to specify a rule that will be used as the grammar axiom, i.e. the top-level rule. Type in or copy the following rule in the “rules” block:

Workshop -> AssemblyWorkstation * : free ;

With this rule, we define the Workshop notation element. It is composed of other AssemblyWorkstation elements. The “*” operator means there may be zero or more of them (the user can add more). In order to specify how the inner AssemblyWorkstation elements are organized, the “: free” construct is used here. “free” means the elements are freely organized by the user on a canvas. Doing so we defined the Workshop as a graph of AssemblyWorkstations. Later in this tutorial we will see other ways to organize the components.

Step 1.6: Modify the “rules” block as follow to specify that the Workshop rule will be used as the grammar axiom, that is to say the top-level notational element:

view "Workshop Layout" {
  rules => Workshop {
  toolboxes { }

Step 1.7: Add a new toolbox. Type in or copy the following code into the “toolboxes” block.

toolboxes {
  toolbox "Workstations" {
    element AssemblyWorkstation "Assembly"

This defines a new toolbox named “Workstations” with a single AssemblyWorkstation element that will be displayed as “Assembly”. This enables the experts to create new AssemblyWorkstation elements. We now have a minimal valid definition of a view.

At this point the complete view definition should look like this:

view "Workshop Layout" {
  rules => Workshop {
    Workshop -> AssemblyWorkstation* : free ;
    AssemblyWorkstation -> [[] 139*64 |#E8B3E7|] ;
  toolboxes {
    toolbox "Workstations" {
      element AssemblyWorkstation "Assembly"

Step 2 – Test in the environment

Step 2.1: Compile the view definition with the following command line:

> XOWLGMICompiler tutorial Layout.view

The executable is located in the compiler directory of the package. The first argument “tutorial” specifies the name of the workbench being compiled. It will be used for some output files. The second argument is the file containing the notation definition.

The compiler outputs the following files:

  • tutorial.owl, the default metamodel implementing the visual notation.
  • Layout.view.owl, the notation specification translated to OWL2.
  • Layout.transform, the transformation rules between the visual elements we defined and the model elements conforming to the metamodel in tutorial.owl in a human readable format.
  •, OWL implementation of the transformation of visual elements to model elements.
  •, OWL implementation of the transformation of model elements to visual elements.
  • Layout.transform.vv.owl, OWL implementation of additional rules applying to visual elements.

Step 2.2: Now we need to configure the environment to use the workbench we just defined. Add the following to the config.ini file in the environment directory:

# tutorial workbench
tutorial.metamodel = workbenches/tutorial.owl
tutorial.view = layout = Workshop Layout
layout.view = workbenches/Layout.view.owl = workbenches/ = workbenches/
layout.vv = workbenches/Layout.transform.vv.owl

# select workbench
workbench = tutorial

The first block in the configuration defines the tutorial workbench. A workbench is a set of views available to users.

Step 2.3: Launch the environment, either by double-clicking on the XOWLGMIEnvironment.jar file in the environment directory, or by the following command line:

> java –jar XOWLGMIEnvironment.jar

Step 2.4: Create a new project by clicking on the menu File>New Project ... Enter any name and validate.

Step 2.5: Create a new diagram in this project by clicking on the menu File>New Diagram ... or right-click on the project. Enter any name and validate. Note that the New Diagram window will let you select the view for the new diagram. In this case, only the Workshop Layout view should be available.

Step 2.6: the diagram is now open. You can drag the Assembly element from the toolboxes on the right and drop it in the diagram area in order to create a new Assembly Workstation, represented by a colored rectangle.

Step 2.7: Exit the environment without saving.

Step 3 – Completing the Assembly Workstation element

From this, we will now improve the Assembly Workstation element to make it look like what is expected by our client.

Step 3.1: In the Layout.view file, type in or copy the following code in the “rules” block:

WorkstationContent -> {
  <s "ID" 50*20>
  [[] 125*5]
  <s "Name" 125*20>
}:vertical ;

In this rule, the “<s ... >” constructs represent data placeholder will be able to type in some information. These will be simple string, as denoted by the “s”. Other available types are “i” for integer and “f” for floats. The two strings indicate the name of their respective placeholders. We also have a new rectangle that will be invisible because we did not define its color. Finally, we have to specify how these 3 elements will be visually organized. The “{ … }” construct is used to put together the three elements. The “: vertical” constructs specifies they will be displayed as a column, with the elements centered by the middle (respectively use “left” and “right” for left-aligned and right-aligned columns).

Step 3.2: Modify the AssemblyWorkshop rule as follow:

AssemblyWorkstation -> {
  [[] 125*50 |#E8B3E7|]
  [[] 129*54 |#FFFFFF|]
  [[] 139*64 |#E8B3E7|]
}:stack ;

The previous WorkstationContent element is reused. The “stack” alignment option is used. It means the aligned elements will be positioned on top of each other, and centered.

Step 3.3: Test in the environment by redoing Step 2 (compile and launch the environment). The following result should be obtained:

Step 4 – More generic elements

The notation specification language supports the use of template rules in order to avoid repetitive rules. In this step we will abstract our current AssemblyWorkstation to a more generic Workstation.

Step 4.1: Modify the AssemblyWorkstation rule as follow:

Workstation($color) -> {
  [[] 125*50 |$color|]
  [[] 129*54 |#FFFFFF|]
  [[] 139*64 |$color|]
}:stack ;

This way, we created a new rule with a parameter name “color”. This parameter is then used in the definition of the notation elements.

Step 4.2: Now we can easily define new kind of workstations. Add the following to rules:

AssemblyWorkstation -> Workstation(#E8B3E7) ;
WeldingWorkstation -> Workstation(#97A9FB) ;

In this way we leverage the generic Workstation rule and pass it values that suit our needs. When writing template rules, you can use parameter anywhere a number, a color or a string (for labels) is expected.

Step 4.3: Now we need to specify that WeldingWorkstation can be added to the Workshop. Modify the Workshop rule as follow:

Workshop -> {AssemblyWorkstation | WeldingWorkstation}* : free ;

The “{ ... | ... }” construct is the union, meaning both AssemblyWorkstation and WeldingWorkstation can be accepted.

Step 4.4: Add a new toolbox element for our new WeldingWorkstation widget:

toolbox "Workstations" {
  element AssemblyWorkstation "Assembly"
  element WeldingWorkstation "Welding"

Step 4.5: Recompile and try out in the environment.

Step 5 – Adding connectors

Now we want to be able to connect the workstations.

Step5.1: Modify the Workshop rule as follow:

Workshop -> {
  AssemblyWorkstation | WeldingWorkstation
  | <Conveyor #000000:1
    {@AssemblyWorkstation, WeldingWorkstation simple}
    {@"[a-zA-Z]+Workstation" arrow}>

}* : free ;

We introduce a new element in our union, a connector. The “< ... >” construct is used to define a connector. First, we have its name, then its color and thickness. Then, we have two “{ ... }” constructs that define its property at its origin and target. The “@” is used to specify which kind of symbol can be at this end. The names of the symbol can be listed with the comma used as a separator. However, a special construction can also be used: a string containing a regular expression matching the name of the symbols that will be accepted. Here the two possibilities are demonstrated. They are equivalent in this case. The “simple” and “arrow” keywords describe how the corresponding connector’s end will look like.

Step 5.2: Add a new toolbox with the connector as follow:

toolbox "Connectors" {
  element Conveyor "Conveyor"

Step 5.3: Recompile and try out in the environment. You should be able to draw this:

Last edited May 11, 2012 at 9:07 AM by lwouters, version 6


No comments yet.