From DaVinci

Contents 1 Sprint 1 Implementation Report 1.1 Introduction 1.2 Duration 1.3 Tool Installation 1.4 Approach 1.5 Developer’s Guide 1.6 Current Plug-in Implementation 1.7 ATL Investigation 1.8 Problems Encountered 1.9 Reflections and Conclusions 1.10 Suggestions to Team 1.11 Suggestions to Customer

Sprint 1 Implementation Report

Introduction

This report is a compilation of thoughts, recommendations and experiences regarding using OSATE, the AADL meta-model, ATL and various other Eclipse plug-ins. It could be used as a starting point for other members in team DaVinci when starting implementation tasks, but also as for feedback to the customer.

Duration

Sprint 1 started 11/14/05 and ended 12/2/05 and the implementation team consisted of two team members; Harry Gunnarsson and Carl Wang.

Tool Installation

In the beginning of Sprint 1, OSATE 1.0 (Eclipse 3.0.2) was the latest released version, but during the course of the sprint, version 1.1 (Eclipse 3.1) was released by SEI. Instructions as how to install the complete toolset and version information are available on the team Wiki page; [1]

Approach

The backlog created during the initial sprint meeting, essentially identified the following tasks for the implementation team

• Learn AADL Ports and Connections
• Ecore/EMF learning
• Implementation of port identification algorithm

Early on in the sprint, the implementation team realized that it would not make any sense not to implement the algorithm in the context of a plug-in. And after some interactions with the customer, it was also determined that it would be worthwhile to start an investigation regarding the feasibility of ATL for transformation attempts. Therefore the task list for the implementation team expanded with the following items

• OSATE plug-in learning
• ATL Investigations

Developer’s Guide

Anyone who has the intent of learning OSATE development, is recommended to follow the below list of learning steps

• Install the complete tool set, as described above.
• Connect to the SEI CVS server and checkout the DaVinci branch
• Run through the EMF tutorial. It will give a nice overview on EMF and its capabilities, which are important to understand since OSATE depends on Ecore and EMF. http://www.eclipse.org/articles/Article-Using%20EMF/using-emf.html
• Run through the OSATE plug-in demo, which is available in the AADL course material. The demo will give an exercise as how to include a new plug-in into the OSATE tool. (svn_repository\DaVinci\trunk\Training\SEI_AADL_Course_CD\Distributions\developer edition\plug_in_development_example)
• Read the OSATE developer’s guide.
• If interested in ATL, read through the Eclipse help ’basic tutorial’ on ATL, browse to [2], and explore some of the ATL examples available.
• Familiarize yourself with the OSATE code base by browsing through the CVS code.
• Familiarize yourself with the AADL meta-model and use the Omondo UML tool to browse the .ecore files.

It is estimated that the above steps will take 7-10 hours to complete.

Current Plug-in Implementation

The initial Sprint implementation task is defined to identify port candidates in a model and possibly collapse them into port groups. It was quickly determined that this is too much to implement given the time constraints in Sprint 1. Compared to the original sprint backlog, the current plug-in implementation has the following limitations

• The algorithm will only identify possible candidates for port collapsing.
• The port search will only occur on the system level.
• Only data and event connections are considered in the algorithm

ATL Investigation

See the team Wiki page: [3]

Problems Encountered

The implementation team encountered the following problems during the sprint.

• CVS. The CVS connectivity to the SEI server was a problem, until it was realized that the DaVinci branch could only be retrieved if Eclipse 3.1 was used. After switching to 3.1, there were no CVS problems.
• Omondo and AADL meta-model. The AADL meta-model cannot be browsed using OSATE 1.0 and Omondo. OSATE 1.1 version must be used on the DaVinci branch when looking at the .ecore files.

Reflections and Conclusions

Based on the experiences from the implementation team, the following findings are worth mentioning

• Eclipse plug-in abundance. There is a boat-load of Eclipse plug-ins that has to be mastered by the developer before efficient coding work can commence. Assuming the developer is proficient in Java and Eclipse, there are still EMF/Ecore, OSATE and Omondo to learn at a minimum, not to mention ATL.
• AADL Meta-model. Any model transformation attempt requires an almost complete understanding of the AADL meta-model. This knowledge is required regardless which implementation strategy is preferred; ATL or hand-crafted Java. Learning the meta-model inevitably takes a lot of time and should be accounted for in future sprint backlogs. Ideal approach to development is to understand the architecture and framework involve before dealing with implementation detail.
• Implementation attempts. Due to the dependencies to the Eclipse plug-ins, all implementation attempts are likely to run as OSATE plug-ins. The initial sprint backlog suggested implementing the port identification algorithm as a standalone, command-line Java application. After some investigations, it was determined that the easiest way to get something running is to follow the path set by the OSATE plug-in exercise, i.e. add the new functionality as a new menu choice. By running the code as a OSATE plug-in, there are some immediate benefits
  • Model access. By opening an AADL project, the OSATE tool provides access to the model. A command-line app would need to explicitly parse the AADL source into Ecore format before traversing the model.
  • Development Infrastructure. All necessary plug-in and development tools are conveniently integrated into a package for easy installation.
  • Output. OSATE provides easy I/O output to existing widgets.

Suggestions to Team

Below follow a list of suggestions to team DaVinci regarding future implementation efforts.

• Meta-model importance. It is essential for any kind of implementation attempt to have a very good understanding of the AADL meta-model before any efficient and useful development can take place.
• Eclipse and plug-ins. There is a lot to learn about Eclipse framework and its plug-ins, upon which OSATE is integrated. The quickest way to learn about them is via tutorials and examples, but when more complete transformation implementation attempts start, greater knowledge about EMF/Ecore etc is likely required.
• ATL vs. Java. For almost all transformation tasks, ATL is probably a feasible implementation method, see above. Also, for all tasks, hand-crafted Java is the competing solution. Depending on the nature of the transformation, the implementation choice might differ. It is also necessary to realize the extra learning burden when dealing with ATL, which might pay off in the long run.

Suggestions to Customer

This section provides feedback and suggestions to the customer regarding OSATE and the current feature list

• The customer’s ultimate goal is to promote OSATE, expand the AADL user community and enable developers to implement custom model transformations. During the course of learning the toolset and implementing a simple model algorithm, the implementation team has the following to say
  • The OSATE plug-in exercise is very useful, but it only goes so far.
  • There is no documentation that explains how the AADL language relates to the AADL meta-model. This makes it very hard to grasp the meta-model and use it during implementation. There might be need of some additional documentation, such as ’AADL meta-model reference for developers’.
• Peter Feiler provided some examples showing the input and expected output AADL system to a port optimization/collapsing utility. This is very helpful when understanding what the algorithm is supposed to do. The customers should be encouraged to provide such examples for other transformation plug-ins the team attempts to implement.