Entering the final turn

Slowly approaching the end of SoCiS 2012, the final touches need to be done to the designer. In the remaining time, I will check for inconsistencies and issues within the developed odesign. A final check to see if the required tools for the mapped nodes are implemented. Of course, all the newly created elements should be accepted by Xtext and the example I worked on, Cruise Control, should be easily understandable.

With the checks and fixes done in this direction so far, it looks fine - tools are implemented and working, Xtext accepts all the newly created elements (and they are created at the right position in the private or public section for example) and after rearranging the representation, you get a better overview of the system.

Now, I start a new learning phase while preparing the update-site for the 1.0 release of the modeler. Tools like Tycho, maven and Hudson will be taken under the loop for the next days to get everything working.

One more week past

The focus for this week was to continue developing the odesign file. With the existing 3 Diagrams: Package, Declaration and Implementation Diagram, the last one is the one I have worked most on this week. I added creation tools for the System, Thread and Process implementation. This was a major progress in understanding the aadl2 model, as it required more than one property to be set during the element creation. More it is also a "cool" tool containing a selection wizard to display all the available systems/threads/processes for which an implementation can be created. This feature was personally an interesting achievement as the java service, required to return the correct elements to populate the wizard, worked almost out-of-the box (of course, there followed some re-factoring to accommodate the method for all the types, but it did the job good straight on).

I have added creation tools for all the components that can be created inside the System/Thread/Process implementation. It was not very difficult to develop this tools once an example was ready, but it quite took some time.... Element edition tools for label renaming and element deletion are also available.

Some work was done also for the PackageDiagram: I noticed the possibility to navigate from a package to one of the other available diagrams. I have added two new options to be able to create a Description or an Implementation Diagram for the existing package. Now in this Diagram the Public and the Private sections are viewed as separate elements.

Finally, the Declaration Diagram got some improvements for the DataPort available inside a system: The general Data Port (already available) was split into three nodes: Input, Output and InputOutput nodes. The initial creation tools where replaced by more complex ones with a selection wizard (thanks to the experience with the implementation creation tools) and looks quite nice. Still need to place the input/output ports at the correct place because they now can be mixed up.

All in all, it was a week with some difficult moments, like the one when I got stuck in getting an element property - thanks Melanie for the help :) - but the design file is getting more and more complex with some nice features :)

Work in progress

For some time now, the focus of the work is building up the design file. More and more elements can be observed and drawn in one of the three available diagrams: Package Diagram, Declaration Diagram and Implementation Diagram.

Having started with a very simple, basic example, now the working example is the Cruise Control code found here. The trace of the project, what and when was developed, can be observed in the git repo.

Now, going again to continue building the AADL design file...

Declaration Diagram view for the Cruise Control example

Preparing the AADL environment

In order to develop the SoCiS Architecture Analysis and Design Language, Obeodesigner together with some tools must be available before working with the example.

This post can also be downloaded as PDF from here.

1. Installing the required tools

1.1 Downloading and installing Obeo Designer

The graphical designer will be developed using Obeo Designer (Eclipse based). It can be downloaded here together with a trial license. This is the cornerstone tool for the next steps. After the download is finished, extract the archive and run obeodesigner to see that the tool is working fine.

1.2 Install Xtext 2.2.1

Start Obeo Designer and go to Help menu -> Install New Software -> Select Add. In the new dialog paste http://download.itemis.de/updates/releases/ into the URL field and give the install a name (eg. Xtext). Scroll among the available items and select Xtext 2.2.1.

In the next screen ("Install Details") select "Next", then accept the terms of license agreement and select "Finish". The install procedure should now start. Restart the environment in the end of the procedure.

1.3 Installing Git support

This step is required in order to import the Osate sources. Go to the Help menu of Obeo Designer and select Install New Software. In the dialog window that appears select Indigo - http://download.eclipse.org/releases/indigo and after the components list is loaded select from the Collaboration category Eclipse EGit. Click in the next two screens "Next". After accepting the license agreement click "Finish" and accept Obeo Designer's proposal to restart.

2. Importig the required projects

2.1 Import Osate 2 sources

In Obeo Designer select File -> Import. In the newly opened dialog select from the Git category "Projects from Git" click "Next". In the following screen select URI and click "Next". Here provide the github link for the Osate 2 sources, git://github.com/osate/osate2-core.git, and click "Next":

In the next dialog select only the develop branch and click "Next". The develop branch contains the most recent builds. Then select the destination folder for the files. If the path directs to your workspace, you can accept the default settings, otherwise change it to your workspace:

Click "Next" and after the complete project list is loaded, accept the default settings and click again "Next". In the next, last dialog, select - if they are not already selected - all the projects and click "Finish". The workspace should look like in the next screenshot - be sure to be in a perspective where the "PackageExplorer" window is visible (left side of the image):

2.2 Importing the AADL design

• Go to File -> Import
• select from the Git category Import projects from Git
• select URI and click "Next"
• provide the Git repository link, git://github.com/ObeoNetwork/AADL-Designer.git, in the URI field and click "Next"

• Select branch master (the only one available) and click "Next"
• In the following dialog provide the destination folder for the sources. If the folder is already a folder in the workspace, the default settings can be accepted, otherwise select a folder inside the workspace and click "Next"
• Wait for the list to be populated, and click "i"
• In the Import Projects dialog select only the org.obeonetwork.dsl.aadl.design and click "i". After this step, the project is imported into the workspace and visible within the PackageExplorer.

2.3 Launch a new Eclipse Application

To launch a new eclipse application click on Run -> Run Configurations. Double click on "Eclipse Application" (or right click on it and select "New") to create a "New_configuration". It be renamed by your desire, eg. "AADL_Example". Make sure that in the "Main" tab, in the "Program run" section, the fr.obeo.dsl.designer.architect.product is selected.

In the "Arguments" tab provide the VM arguments as follows:

-Xms256m -Xmx1024m -XX:MaxPermSize=256m

After the above set up is prepared, click "Run" to start the new eclipse instance.

2.4 Importing the AADL Example

This procedure is very similar to importing the AADL design. make sure to select a destination folder inside your workspace (eg. "aadl_example")The major difference is during the "Importing projects" step, when org.obeonetwork.dsl.aadl.control_processing.example  must be selected (instead of org.obeonetwork.dsl.aadl.design):

After the import procedure is finished, the workspace must look like this:

2.5 Browsing the org.obeonetwork.dsl.aadl.control_processing.example

Opening the "control_processing.aadl" will open the file containing the aadl code. It contains a package, a system together with a basic system implementation, two data type declarations and one process. It is a basic example in order to start the development of the AADL modeler.

The "instances" folder contains an Osate 2 instance of the AADL code example. An instance of the code is required in order to create a diagram. It can be easily done by right clicking inside the System Implementation definition - when the "control_processing.aadl" file is open - and then selecting Instantiate System.

In order to view the existing code with the defined AADL Designer, open the "representation.aird" file and navigate the tree until the final node, "test_diagram"

Double click on "test_diagram" will open the current representation. The nodes can be freely moved on the canvas:

Note: The status of the screenshots and examples is the date of publishing this post. Changes in the example or the designer can occur, as it is under development!

ADELE Example

Before specifying the requirements for the SOCIS AADL designer, I developed a simple demo using the existing TOPCASED AADL Designer, named ADELE. The example is very basic and is based on the specification presented in Table 4-2 of "AADL: An Introduction". The model is not complete but it gives an overview on how to work with the tool, how to create and connect elements. The final purpose is to have AADL code automaticaly generated.

The TOPCASED model files can be downloaded here. The archive contains 3 files:

• demo_control_processing.aadl contains the generated AADL Code
• demo_control_processing.adele is the XML model representation
• demo_control_processing.adeledi contains the graphical model

Summary of the example:

1. Goal: What does the model contain?
2. ADELE Project and Diagram set up
3. Data type declaration
4. Thread declaration
5. Thread implementation
6. Process declaration & implementation
7. AADL code generation
8. No .aadl file is generated

1. Goal: What does the model contain?

As in the AADL Introduction paper, a process type with the component type name "control_processing" will be defined. The features of the process are an in data port of type sensor_data and an out data port of type command_data.

For this example two thread types, "control_in" and "control_out", are declared. The implementation of the thread types is "control_in.input_processing_01" respectively "control_out.output_processing_01".

The above thread declarations and implementations are required for the "control_processing" process implementation. The example implementation will be named "speed_control" and contains two thread subcomponents which reference the previously defined thread implementations.

In order to achieve this, we will first define the data types. Next the two thread types will be declared and their implementations designed. Now we are ready to declare the process. Last step is to implement it. When we are so far, code generation is straight forward.

This is how the final model should look like. [Source Table 4-2: A Simplified Example of an AADL Specification]

2. ADELE Project and Diagram set up

Start Topcased in your preferred way: double click on the launcher or from terminal (if working under GNU/Linux). I prefer starting Topcased from terminal because in this way I can see any exceptions that occur.

Create a new "ADELE Project" via "File" -> "New" -> "Other" and then search for "ADELE Project". In the following window name the project "demo" and select "Finish". If the selected perspective is not the "ADELE Perspective" you will be prompted to enable it. Please do so.

You should see the following screen:

Now an ADELE Diagram needs to be created. Righ click on the "demo" inside the "Project Explorer". Select "New" and then "ADELE Diagram". In the following dialog provide the information as follows - be careful to select "Package" in the "Diagram" field:

Inside the "demo" project we previously created, a new folder "demo_ctrl_processing" and two files "demo_ctrl_processing" with the extensions .adele respectively .adeledi are created. Open the "demo_ctrl_processing.adeledi" (by double click on it) and we can move on.

3. Data type declaration

To declare the two data types we need, click on the "Data" component and then click somewhere in the available canvas. Please be careful, as drag-and-drop of the components on the canvas does not work! This will create a data declaration. Name it "sensor_data" and repeat the steps to declare another data type named "command_data". The created objects can be moved after declaration around the canvas by drag-and-drop.

4. Thread declaration

The process of declaring threads is very similar to the "Data type" declaration that we have done earlier. Now select the "Thread" tool inside the "Components" list and then click on a free are in the canvas to the right. Name the thread "control_in". Repeat the process and create the declaration of a second thread named "control_in". The canvas should look like this now (I have moved around the data type declarations):

5. Thread implementation

This step of defining the thread implementation is not as intuitive as the thread declaration and might take some time to figure it out. This is done the following way: the "Thread" component tool is selected (as in the previous step) and then click inside of a thread declaration (for the thread declaration we have clicked on some empty place on the canvas). The thread implementation instance appears inside the thread declaration and the thread declaration name (the string before the ".") is taken over from the thread declaration. Complete the implementation name with "input_processing_01" respectively "output_processing_01"

6. Process declaration & implementation

Process declaration

In this step we will define the process named "control_processing" containing 2 features input and output. They will be referencing the data types declared at step 3. input will reference "sensor_data" while output will reference "command_data".

To declare a process select the "Process" component tool and then click on a free space on the canvas. Name the newly created process "control_processing". Next we need to define the two data port futures for the process. For this inside the "Features" palette select the "In Data Port" and then click on the representation of the process. Name the feature "input". Now the feature is created, but it is not connected to the sensor_data type earlier defined. To do this, in the "ODS" section of the workspace (lower part by default) select "Classifier" and then click the button available in the right side named "Choose a classifier". This will open a dialog were you have the possibility to select the correct data type.

Step 1: define a "In Data Port" feature for the process.

Step 2: select in the ODS section the "Classifier" and
click in the right side on the "Choose a classifier"

Step 3: in the "Classifier explorator" dialog select the sensor_data type declaration

The same steps need to be repeated in order to create an "Out data port". If the out data port is not directly visible inside the Features  palette, then please right click on the small arrow left to the in data port. This will extend the node and the desired data port will become visible:

Process implementation

The implementation of the process is identical to the thread implementation described at step 5: Select the "Process" from the palette and clicked inside the declaration of the "control_processing" process. Name the implementation control_processing.speed_control:

Next, the two thread subcomponents need to be defined: "control_input" referencing the "control_in.input_processing_01" implementation and "control_output" referencing the "control_out.output_processing_01" implementation. This step is very simple once know the workflow of how to do it. It took me some time to figure this out, but afterwards everything went smoothly. By double clicking on the "control_processing.speed_control" implementation, the following dialog is presented:

The user can select either to "Create Behavior Annex Editor diagram" or "Create Process diagram". For this step, the "Create Process diagram" must be chosen. This will open a new canvas containing the in/out ports that are defined in the process declaration - our case "input" and "output". This is a new layer which is hierarchically one level below the declarations and implementations we previously defined. It can be imagined to be "inside" the process speed_control implementation. On the top margin of the canvas the current working level can be observed:

To navigate between these two layers the toolbar buttons to the right can be used. To go to the higher level use the "up arrow". To open the speed control implementation double click on it's block on the top level. A small green arrow in the top-right corner of the implementation box indicates the presence of a lower level:

Having the Process Diagram defined, we need to add the thread sub-components. In order to do this, we need to navigate inside the control_processing.speed_control implementation (double click). Here add two thread instances by selecting the Thread component and clicking on the canvas. Name one of them "control_input" and the other one "control_output". Next they need to be connected to the thread implementations control_in.input_processing_01 respectively to control_out.output_processing_01. To do this, click on one of the newly created threads. We will use for the example the control_output thread declaration. Select in the "ODS" section of the workspace (lower part by default) the Classifier node. In the right window then click on the button "Choose a classifier" and in the presented dialog choose the demo_ctrl_processing::control_out.output_processing_01 classifier. Your screen should look like this:

As a last step before generating code, repeat the process in order to connect the "control_input" thread to demo_ctrl_processing::control_in.input_processing_01. This will end the definition of our first AADL model. We can view the top level:

7. AADL code generation

Having the difficult jobs behind us, we can invoke the code generator. For this, right click on the "demo_ctrl_processing.adeledi" (or .adele) file in the Project Explorer and select "ADELE" and from the submenu click on "generate aadl code". You can keep in mind, that this is not the only way to start the code generation.

A new file named "demo_ctrl_processing.aadl" can be observed in the project explorer. If no file is generated, please look at section 8.

Having a look over the generated code (the file can be opened by double click), it can be noticed that it is similar to the one presented in Table4-2 (in our demo model the comments are missing):

8. No .aadl file is generated

In my situation, after invoking the code generator as described in step 7, no code was generated and I could observe the following error in the console where TOPCASED is started:

java.io.IOException: Cannot run program "/home/TOPCASED/Topcased-5.2.0/plugins/org.topcased.adele.admin_2.6.0.201204031215/usr/LMP/bin.pclinux/sbprolog" (in directory "/home/TOPCASED/Topcased-5.2.0/plugins/org.topcased.adele.admin_2.6.0.201204031215/usr/LMP/sbprolog"): error=13, Permission denied

at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)

at java.lang.Runtime.exec(Runtime.java:615)

at org.topcased.adele.tools.prolog.actions.PrologExtractionAction.launchAADLGeneration(PrologExtractionAction.java:1057)

at org.topcased.adele.tools.prolog.actions.PrologExtractionAction.createPrologFiles(PrologExtractionAction.java:315)

at org.topcased.adele.tools.prolog.actions.PrologExtractionAction.run(PrologExtractionAction.java:193)

at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

Caused by: java.io.IOException: error=13, Permission denied

at java.lang.UNIXProcess.forkAndExec(Native Method)

at java.lang.UNIXProcess.<init>(UNIXProcess.java:135)

at java.lang.ProcessImpl.start(ProcessImpl.java:130)

at java.lang.ProcessBuilder.start(ProcessBuilder.java:1021)

... 5 more

The text "error=13, Permission denied" made me look over the permission of the sbprolog program. I moved to the home/TOPCASED/Topcased-5.2.0/plugins/org.topcased.adele.admin_2.6.0.201204031215/usr/LMP/ folder and could observe, that sbprolog was not marked as executable. A simple chmod 777 sbprolog solved my issue. A new run of the code generator worked smoothly (777 rights are not necessary, just the x bit must be set).

Topcased AADL

While learning by doing I had an introduction into TOPCASED v.5.2.0, an Eclipse based IDE for development of complex safety critical real-time hard- and sofware systems in the area of aerospace and automotive. Installation ran smoothly after downloading the bundle from the project page. To get a first overview of the tool, I looked over the official presentations available here (short version) and here (long version) - don't worry, without someone talking besides the slides it won't take much time to read them. I found the article: "TOPCASED: System development using Open Source" very interesting and helpful to find the motivation of the project and place it into the industrial context.

In the context of SOCIS, the AADL Designer that comes with TOPCASED is of interest and should serve as an example of what an AADL modeler should incorporate. The first mystery to solve was, which one of the tools in TOPCASED is the AADL Designer? After long research among the available documentation I was totally confused and didn't find the answer. My mentor helped me forward here and told me the AADL Designer is named "ADELE"! This was a big step forward!

Having a path indicated and some presentations to begin with, I started learning about ADELE. My entry point was the project homepage for general information. Next, I have read the ADELE presentation and played with the tool. Just some basic stuff: creating a project, drawing some elements and interconnecting them. I had the same feeling as I had when playing with the Obeo Designer for the family demo.

This being said, the introduction to the technologies and tools I will be using has got to an end. Now it's time to work and in parallel study in more detail the tools and technologies.

First steps towards AADL

"[...] when you learn to read then you learn everything you didn't know before. But when you write you write only what you know already [...]" I think Umberto Eco's statement describes very good the situation I find myself in: by reading information available on the web I have the power to learn everything about AADLs, but writing on the blog is very difficult as my knowledge is just starting to shape up.

For others that are in a similar situation to mine, I think writing down my trace to learn AADL could be helpful. The first dilemma to solve is what does the acronym AADL stand for? Initially the acronym meant "Avionics Architecture Description Language", but AADL covers all the embedded real time systems. In 2004 the Society of Automotive Engineers released the standard named "Architecture Analysis & Design Language" which is the current meaning of AADL. According to the definition found here "the AADL is a modeling language that supports early and repeated analyses of a system's architecture with respect to performance-critical properties through an extendable notation, a tool framework, and precisely defined semantics."

At a first reading that definition didn't cleared much my understanding, so I had to dig more into the details. First I left the first 'A' in AADL out, and read shortly about Arhitecture Description Language and found out that AADL is the secondary candidate of being the best ADL. Having the term "ADL" cleared, I moved forward for a general introduction about AADL on wikipedia. The information found in the "The Architecture Analysis & Design Language (AADL): An Introduction" report by Peter H. Feiler, David P. Gluch, John J. Hudak is very detailed and might be just a little bit to much for a snooker. The sketchy description found here can be a much better starting point and then build up with the report previously mentioned.

Going through those lectures I can scarcely say I have a basic idea of what an AADL is. The road is long ahead and resources are plenty - next in line would be the AADL community page and I will move to "learning by doing". Creating a model with already existing AADL modelers will shortly follow on my learning path.

Week 4

and I am still learning and getting used to the tools, before starting the real work. As time goes by, the tools and technologies get more specific and custom tailored to solve a specific problem.

This week I had my introduction to the Obeo Designer. I started with small steps reading and trying to understand Viewpoint. For this purpose, the "Viewpoint Specifier Guide" is, in my opinion, a very detailed document - this compared to my zero knowledge on this topic. Further, it was very helpful and made much more sense when put together in a practical example: The Obeo Designer Tutorial.

I have faithfully followed all the steps in creating the basic family example. The Specifier Guide was during the training a very good reference point as I returned for detailed explanations very often to it. It was sometimes a bumpy road, as I didn't correctly understood some steps, or some tools just didn't wanted to work as expected. It was a great volume of information that I assimilated and still there are issues which I do not understand and do not work... A small break, patience, reading once more the documentation and talking to my mentor should fix this.

This week, I have created my first basic graphical modeler for a simple example. I found it very interesting, challenging to assimilate the new technology but also rewarding when elements did, what they were supposed to do!

Graphical Modelers

Continuing the learning process, previous week I have worked on finding out the theoretical backgrounds of graphical modelers. I have read, as suggested, about:

• Graphical Editing Framework
• Graphical Modeling Framework (eclipse.org) and on ibm.com, all to sum up in a nice presentation here.

The purpose of this lecture was to get a feeling of what is currently available to develop graphical modelers - and I did.

I have spent some extra time in following tutorials for Acceleo 3. After reading some randomly available information on the internet, performing the Quick Start and the Getting Started Guide put order in my thoughts. After these two exercises I have got a slight feeling about the code generator and it's syntax, but the road is still long ahead to feel confident with the tool...

The world of the Eclipse Modeling Framework

"The EMF project is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, along with a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor." [source] This text was my entry point to this world, quite interesting as EMF can sustain my work by automatic code generation.

A short walk through the EMF documentation got me familiar with the terminology required to work with the framework, but at a deeper look, I found the information there overwhelming. I choose to try out the "learn-by-doing" method and followed the tutorial "What every Eclipse Developer should know about EMF". This was a far better start to understand the framework and see what you can develop using it. I paid attention to all the details in the first part of the tutorial to better understand the ideas and concepts presented. This was very helpful, but getting to the 4th part of the tutorial, "EMF API" got me totally confused. I fought to get it over and succeeded, but with great gaps of knowledge. Reading about the EMF.Edit Framework here, following another tutorial available on www.vogella.com and having a good night sleep cleared up the things a lot. Reading the extra resources indicated during the tutorial also helped a lot clarifying things. I decided to run once more through the tutorial "What every Eclipse Developer should know about EMF" and it turned out to be a good decision mainly of two reasons:

1. the tutorial made much more sense. I could understand the connections between the elements and how they work together to build up an application
2. I now know how bowling league is structured ;)

The tutorial by Lars Vogel added new powers by introducing the Ecore Diagram (instead of directly using the Ecore model). For my personal understanding it was ok to first do this tutorial and then the one by Lars Vogel, but I figured out, that Lars Vogel's tutorial is a glimpse easier. Maybe it would have been a good idea to start with that one. It was especially helpful at the beginning by presenting the packages required to be installed before starting - this information lacked to my first read tutorial. 

I would say, the purpose of this 2nd week of SOCIS2012 to understand what an Ecore metamodel is, to define my own DSLs and how to generate basic editors for it, was achieved.

First three days of SOCIS2012

Since Wednesday things got moving, in the right direction I'll say. I had my first contact with my mentor and agreed upon the communication channel.

Walking through the Eclipse IDE tutorial was a nice starting point for accommodating to the technology, but things got more interesting with the Eclipse plug-in development tutorial. Only once in your geek life a new Eclipse application says "Hello world!" to you.

ESA Summer of Code in Space 2012 here we go!

The 1st of August was a special day: I got accepted for the ESA Summer of Code in Space 2012. The complete participants list can be found here. Coding starts in 3....2....1....