• Maven/Tycho: to build your app
• Jacoco: to instrument your code in order to gather code coverage
• Sonar: to gather some metrics such as code coverage, it coverage, code conventions, complexity, and so on…
• Cloudbees Dev@cloud SAAS platform : for continuous integration and deployement

You can find the abstract of our incoming talk there : http://www.eclipsecon.org/2012/sessions/get-ready-fight-your-technical-debt-tycho-sonar-and-jacoco

So get ready to fight the technical debt and see you there!

For instance, have a look at maven : there’s a plugin for almost everything (Here, here, and here). And with the rise of Tycho, you can bring all the power of maven to build OSGI/Eclipse based projects.

Let’s see how to leverage the use of Sonar (a great open source quality analysis tool) to deal with the QA of your project.

Install the Jacoco plugin for Sonar

I assume you have a running instance of Sonar. (If not, have a look here : Install Sonar).

Since Eclipse convention is to separate plugin and test in two separate projects (in order to not pollute plugin dependencies with test dependencies), “traditional” code coverage tools (such as Cobertura) won’t be able instrument Eclipse plugin classes because test classes are not in their classpath.

Jacoco adopts “on the fly instrumentation” by the means of a JavaAgent (http://www.eclemma.org/jacoco/trunk/doc/implementation.html), this enables the ability to maintain plugin code and test code in separated project : that just what we need in our case! Great!

So to install Jacoco plugin just follow that guide : http://docs.codehaus.org/display/SONAR/JaCoCo+Plugin.

Now we are ready to configure our Tycho build.

Tycho build

I assume you have a running tycho build. So you just need to add the following section in the pluginManagement section of the parent pom :

<!-- Testing -->
<plugin>
   <groupId>org.eclipse.tycho</groupId>
   <artifactId>tycho-surefire-plugin</artifactId>
   <version>${tycho.version}</version>
   <configuration>
      <useUIHarness>false</useUIHarness>
      <includes>
         <include>**/*Test.java</include>
      </includes>
      <!-- Kill test JVM if tests take more than 10 minutes (600 seconds) to finish -->
      <forkedProcessTimeoutInSeconds>600</forkedProcessTimeoutInSeconds>
   </configuration>
</plugin>

And then provide the following profile :

<!-- This profile is used to gather code coverage for Sonar -->
<profile>
  <id>codeCoverage</id>
  <properties>
    <!-- Properties to enable jacoco code coverage analysis -->
    <sonar.core.codeCoveragePlugin>jacoco</sonar.core.codeCoveragePlugin>
    <sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
    <sonar.jacoco.reportPath>../org.demo.camp.nantes.parent/target/jacoco.exec</sonar.jacoco.reportPath>
  </properties>

  <build>
    <plugins>
      <!-- Enabling use of jacoco -->
      <plugin>
        <groupId>org.jacoco</groupId>
        <artifactId>jacoco-maven-plugin</artifactId>
        <version>0.5.3.201107060350</version>
        <executions>
          <execution>
            <goals>
              <goal>prepare-agent</goal>
            </goals>
            <configuration>
              <!-- Where to put jacoco coverage report -->
              <destFile>${sonar.jacoco.reportPath}</destFile>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</profile>

And that’s all for the parent pom configuration.

For unit testing you do not need to do more that providing the right packaging :

<packaging>eclipse-test-plugin</packaging>

But for UI testing with SWTBot, you need some more configuration.

Tycho configuration for UI testing project with SWTBot

In order to execute your UI tests, you need to specify which product/application you need to start. Basically, for an Eclipse plugin, you’ll need to run the following couple :

<product>org.eclipse.sdk.ide</product>
<application>org.eclipse.ui.ide.workbench</application>

So you just need to add the following section to your UI test plugin :

<build>
	<plugins>
		<plugin>
	        <groupId>org.eclipse.tycho</groupId>
	        <artifactId>tycho-surefire-plugin</artifactId>
	        <version>${tycho.version}</version>
	        <configuration>
	          <useUIHarness>true</useUIHarness>
	          <useUIThread>false</useUIThread>
	          <product>org.eclipse.sdk.ide</product>
	          <application>org.eclipse.ui.ide.workbench</application>
	        </configuration>
      	</plugin>
	</plugins>
</build>

Now your UI test can run through Tycho and being analyzed by Sonar. Great!

Limitations

Wokring on Mac has some advantages, and some drawbacks, here we are facing a drawback. Running SWT applications on Mac require the following JVM argument : -XstartOnFirstThread (http://www.eclipse.org/swt/macosx/).

So you need to configure the the tycho-surefire-plugin as below in the parent pom :

<plugin>
	<groupId>org.eclipse.tycho</groupId>
	<artifactId>tycho-surefire-plugin</artifactId>
	<version>${tycho.version}</version>
	<configuration>
		<useUIHarness>false</useUIHarness>
		<includes>
			<include>**/*Test.java</include>
		</includes>
		<!-- Kill test JVM if tests take more than 10 minutes (600 seconds) to finish -->
		<forkedProcessTimeoutInSeconds>600</forkedProcessTimeoutInSeconds>
		<argLine>-XstartOnFirstThread</argLine>
	</configuration>
</plugin>

But if you do that, the tycho-surefire-plugin argLine will overwrite the Jacoco instrumentation argLine.

But thanks to this following tycho-surefire-plugin configuration parameter : appArgLine you can add other arguments without overwriting the ones from the argLine configuration parameter. So you can define your MacOs profile as below :

<!-- MacOS specific vm arguments for UI testing -->
<profile>
	<id>osx</id>
	<activation>
		<property>
			<name>java.vendor.url</name>
			<value>http://www.apple.com/</value>
		</property>
	</activation>
	<build>
		<pluginManagement>
			<plugins>
				<plugin>
					<groupId>org.eclipse.tycho</groupId>
					<artifactId>tycho-surefire-plugin</artifactId>
					<version>${tycho.version}</version>
					<configuration>
						<appArgLine>-XstartOnFirstThread</appArgLine>
					</configuration>
				</plugin>
			</plugins>
		</pluginManagement>
	</build>
</profile>

You now can handle the execution of your UI tests seamlessly on any platform.

To be done

If you have a look at the Sonar analysis, you’ll see that code coverage is calculated from source code and test code (Sonar analysis).

So we need to use the sonar.exclusions pom property : http://docs.codehaus.org/display/SONAR/Advanced+parameters

Another thing to investigate is to differentiate Code coverage and IT coverage : http://www.sonarsource.org/measure-code-coverage-by-integration-tests-with-sonar/

Add continuous integration (Jenkins or Hudson) : here is a good explanation on how to run UI test on a headless server : http://blog.dahanne.net/2011/07/18/run-ui-tests-on-a-headless-jenkins-hudson-continuous-integration-server-running-ubuntu/ by @anthonydahanne

Resources

You can have a look to the source code of a small sample : https://github.com/xseignard/tycho-demo-camp

You can run mvn clean install -PcodeCoverage and then mvn sonar:sonar -PcodeCoverage from the parent project.

And check the sonar analysis here: http://ec2-79-125-43-108.eu-west-1.compute.amazonaws.com:8080/sonar/ It should work out of the box.

You can edit/remove the sonar connection settings in order to use your own Sonar instance.

Feel free to provide pull request in order to ameliorate the project and/or drop a comment.

You can find that feed here : http://feeds.feedburner.com/MdePipe

Feel free send me new bloggers, I’ll add them for sure!

Xavier Seignard (XS) – Hello Jordi Cabot. Maybe you can start by introducing yourself and your position in the MDE diploma?

Hello Xavier and thanks for giving me the chance to talk about the MDE Diploma (http://www.mines-nantes.fr/fr/Formations/Formation-specialisee/MDE). A few words about myself: I´m the leader of the AtlanMod team (http://www.emn.fr/x-info/atlanmod) an INRIA research group located at the École des Mines de Nantes. AtlanMod is one of the leading MDE research teams in the world and has created some of the most popular MDE technologies like the ATL model transformation  language. I’m also the creator of the Modeling Languages portal (http://modeling-languages.com) where I write about all kinds of software modeling and model-driven engineering topics.

XS –  Could you explain us the birth of this diploma, who took the initiative?
Jean Bézivin took the initiative of creating the diploma when he realized that there were many companies interested in starting new projects using MDE techniques but that the engineers with the “human skills” necessary to lead those MDE projects were not widely available (no specialized formation on these topics existed anywhere in the world!).

From there, he started, together with Frédéric Jouault and Serge Masserot, designing a formation that included not only technical MDE subjects but also case studies and MDE project management aspects to make sure students had a complete picture of the benefits but also complexities of MDE . The idea has always been to “create” MDE experts that can advice the companies about when and where use MDE techniques in their software engineering activities, not only technical experts that can implement these solutions (designing metamodels, model transformations,…) for them.

The students :

XS – How many people are following the diploma this first year?

We have six students.

XS – What is the profile of the students? What is the proportion working for a software editor, for a consulting company, big companies, institutional administrations?

There´s a little bit of everything, from a student working in a tool development company to a student that works in the informatics department of a big company and even one student that will be the key designer/developer of a new model-driven product for a start-up company.

XS – What is the background of the students? System engineering, embedded systems, information systems, …?

Most of them have a computer science background with a focus on the information systems area but the diploma covers the use of MDE on all the above mentioned areas.

XS – How international are the students?

All students live in France (not all of them are French though) and moved to Nantes to follow the diploma (only one of the students is originally from Nantes). During these months they have stayed in the student residence of the École des Mines.

XS – Last year, I met Gisela Bonnaud, Pedagogical Engineering Coordiantor of the diploma, she told me that some companies were willing to recruit people so they can follow the diploma. What was the motivation of the students to follow this diploma? They were sent by their companies? Is it a personal interest?

In the end for this edition we had 50/50. Three of the students were sent direclty by their companies and three other came on their own and managed to found a company to do the internship during this first semester of courses.

But in fact, we have indeed detected a growing interest of companies willing to hire MDE students so we are working in that direction for the new edition.The idea would be to bring companies to “sponsor” MDE students in exchange of getting the student working for them as interns and, possibly, as employees at the end of the diploma. We believe this is a very “low-risk / high-reward” way to hire an MDE expert for your company and with the option of “testing” that employee during the internship to make sure he/she integrates well with the company.

XS – The formation is quite expensive, how it is financed?

For the students already employed by a company, the company takes care of the cost of the diploma. The rest has benefitted from (partial) grants to help them cover the fees. However, I think all of them are happy with the “investment” they made since thanks to the diploma they have found a company in which they will probably continue working on MDE topics even after the internship finishes.

XS – The first semester (academic coursework) is finished, what is the feedback of the students?

They are very happy with the contents of the diploma and with what they have learnt so far but I´m afraid we have a been a bit too demanding. They have complained that the pace of the courses has been too high: on average they have had four full days of courses (24h) and one day of personal work per week to complete the MDE exercises and mini-projects given by the lecturers. A second complaint was regarding the difficulty of relating all the different concepts seen during the course, specially because the ordering of the courses did not always followed an exact sequence (maybe they were practicing one day a model transformation language and the next day seeing the application of MDE in the embedded systems domain) due to the constraints of our guest lecturers. We will work on these two aspects for the next edition of the diploma.

XS –  The internships are about to start, any buzzwords, privileged application fields?

We are very excited about the internship topics. I believe that we cover most of the main areas of MDE. Topics include new model-driven reverse engineering techniques to migrate legacy systems, code-generation tools, model-driven tool interoperability aspects to improve the business-IT alignment and putting in place a new model-driven development method in a company, defining the UML profiles /DSLs required in the company’s specific domain.

The diploma :

XS – How did you elaborate the program? With the help of partners such as companies and labs?

The program reflects our own vision of the MDE field and the aspects we believe are important  (including all the non-techincal ones) to become an MDE expert. After we sketched the first program version we went back to the community for feedback. We reached many of our colleagues and also presented the diploma in several events like the Educators’ Symposium in the MoDELS’09 conference.

XS – How international are the lecturers?

I think we can say we managed to have most of the the big names in software modeling in Europe teaching in the diploma!. And as a complement, the students were invited to attend the Jeudi des Modeles (http://www.emn.fr/z-info/jmodeles/) cycle of conferences where we have recently hosted notables like Ivar Jacobson or Ed Merks and we even had a “field-trip” and brought all the students to a modeling conference (ECMFA’10 in Paris) so that they could know about the latest developments in the area. All in all, I believe we can say that the quality of the lecturers has been oustanding and we are very grateful to all of them for accepting our invitation and for taking the time to prepare high-quality lectures for our students.

XS – What is the proportion of academic/industrial lecturers?

I´d say it was 50/50. We have tried to balance both perspectives. It is good that students know about the cutting-edge technologies that leading research groups are developing but at the same time they need to be familiar with the best practices and commercial tools currently in use in software companies.

XS – MDE is evolving a lot recently, how do you deal with that to stay at the cutting edge of these technologies in the program?

This is tough. Again, we need to find an equilibrium between the new hot topics and the core technologies. We decided to devote the first part of the courses to core MDE technologies that we wanted the students to master (metamodeling, model transofrmations,..) and then we organized the rest of the courses as one-day sessions on one specific aspect that could be either the application of MDE in a particular domain (e.g. web engineering, real-time systems,…) or an introduction to an advanced MDE topic (like MPS-Meta Programming System) that is getting some momentum but that right now it is difficult to guess if it will become more mainstream or not. In each edition, we will review all these advanced topics to see if any of them deserves to be moved to the “core” part and get more attention.

XS – What is the feedback of the lecturers?

The feedback has been very positive. All of them manifested that they were very impressed about the quality and, specially, the interest and participation of the students. No surprise here, the participation depended a lot on the topic of the day. More junior students were more interested  in the most technical subjects, instead the more senior ones were more participative during the discussion on  social and project management aspects of MDE projects since they have already experimented this kind of difficulties.

The MDE diploma team:

XS – It is always tricky to start a new diploma, what are the lessons learned with this first semester?

As I was saying before, I think we have tried to squeeze to much content in the diploma. We love all these topics so it was very difficult to us to discard some of them during the planning. Also, I think we understimated the complexity of the logistics required to bring all these external experts to teach in the diploma. This was almost a full-time job for a couple of months. We were lucky to have a person working as a pedagogic assistant for the diploma that could take care of this but I think this is one aspect that should be taken into account when trying to open an international diploma like this one. One last lesson learnt is about the need to oganized a weekly session with the students to help them relate the things they have learnt that week with past and future lectures. Seeing so many topics (taught by so many different teachers) is a very rich experience but comes with the danger of leaving them a little bit confused at times. It´s important to make sure they understand the relationships between all MDE concepts and I think that a weekly session to have an open discussion with the students to put things in perspective could be a good solution for this.

XS – Because we know MDE is often scary for companies, is this diploma can be an argument for the adoption of such technologies?

This is exactly one of the goals of the diploma. The diploma offers two main benefits to companies. First it provides them with a MDE expert that can advice the company about the best way to benefit from MDE (the goal of the MDE expert is not to change completely how the company does things but to identify the areas in which MDE can make a difference). Second, thanks to the internship program, companies can conduct a pilot project to test MDE and get convinced about the competitive advantage this may represent to them. We hope every edition more and more companies realize about this!

XS – With the help of the graduate school of engineering “Ecole des Mines de Nantes” and the research team “Atlanmod”, the MDE diploma seems to benefit of a great environment, what’s your feeling about that?

This is absolutely true!. I´m very happy to be leading the AtlanMod team. Jean Bézivin did a great job in creating a leading MDE research team in Nantes, supported by the École des Mines de Nantes and by INRIA. In fact, he didn´t just created a team but helped developing a complete modeling ecosystem in the Pays de la Loire region. Having great modeling companies around (like our close partners OBEO and MIA-Software) offers greats opportunities to all students and researchers interested in MDE.  Nantes may not be in the middle of the Silicon Valley but for sure we are in the center of the “Modeling Valley”.

XS – What are your plans for the next year of the diploma?

We are already preparing the next edition of the MDE diploma. It´s going to start in September 2011. Those interested in taking part in it can already contact me at jordi.cabot@mines-nantes.fr .

XS – Thanks Jordi, I wish you a lot of success to you and the MDE diploma team. To end this interview, do you have an anecdote to share?

Well, let´s say that I´ve discovered the usefulness of the images tab of google search. Since I didn´t know personally all the lecturers, more than once I had to quickly search google to find a picture of the lecturer of the day to see if the person wandering around the department not knowing where to go was indeed him/her (all lecturers were supposed to stop at the reception desk and ask for me but many arrived early and tried to find the classroom by themselves and believe me this is not easy in our École).

• http://5ise.quanxinquanyi.de/
• http://abstratt.com/blog
• http://actifsource.blogspot.com/
• http://activeknowledgemodeling.com/
• http://appgen.pbell.com/
• http://aspectize.com/blogs/corp/default.aspx
• http://blanglois.blogspot.com/
• http://blog.benois.fr/
• http://blog.efftinge.de/
• http://blogs.euranova.eu/
• http://eclipsemde.blogspot.com/
• http://ed-merks.blogspot.com/
• http://ekkescorner.wordpress.com/
• http://fmadiot.blogspot.com/
• http://freddyallilaire.blogspot.com/
• http://jomd.blogspot.com/
• http://kenn-hussey.blogspot.com/
• http://kthoms.wordpress.com/
• http://lsd.luminis.eu/category/technical/mdd-technical/
• http://mdwhatever.free.fr/
• http://www.metacase.com/blogs/jpt/blogView
• http://www.metacase.com/blogs/stevek/blogView
• http://metaplop.blogspot.com/
• http://model-driven-blogging.blogspot.com/
• http://modeldrivensoftware.ning.com/profiles/blog/list
• http://modeling-languages.com/blogs/jordi
• http://modelseverywhere.wordpress.com/
• http://pjmolina.com/metalevel
• http://skanderturki.wordpress.com/
• http://thegordian.blogspot.com/
• http://voelterblog.blogspot.com/
• http://www.ebpml.org/blog2/
• http://www.hulshout.nl/
• http://www.peterfriese.de/
• http://www.theenterprisearchitect.eu/

Create your MagicDraw user library

First of all you need to create a user library (Window>Preferences>Java>Build Path>User Libraries) in Eclipse containing every *.jar from the “<MagicDraw_Install_Dir>/lib” and its subfolders.

Create your debug project

Create a new Java Project, and then you need to reference your plugin project in the build path of your debug project : (Right click on the project>Configure build path)

Here I take the Eclipse project given in this post.

Then you need to create a main class which will init your plugin and launch MagicDraw :

package fr.free.mdwhatever.magicdrawDebug;

import com.nomagic.magicdraw.core.Application;
import com.nomagic.runtime.ApplicationExitedException;

import fr.free.mdwhatever.simplePlugin.SimplePlugin;
/**
 * This class allows you to debug your MagicDraw plugin
 *
 * @author Xavier Seignard
 */
public class Debug {
	/**
	 * @param args
	 */
	public static void main(String[] args) {
		try {
			SimplePlugin plugin = new SimplePlugin();
			Application app = Application.getInstance();
			// Start the application (visible, not silent,
			// don't try to load a project, the given args,
			// the StartUp participant)
			app.start(true, false, false, args, null);
			plugin.init();
		} catch (ApplicationExitedException e) {
			e.printStackTrace();
		}
	}
}

Then all you need to do is to right-click on this class and choose “Debug as” to launch MagicDraw within the Eclipse debugger and use all the functionalities it gives us!

Nota : Maybe you’ll need to tune up a bit more your debug configuration by adding “-Xmx1024m” as VM argument as shown below :

Hope this helps! See you!

M2M/M2T tools:

• actifsource (http://www.actifsource.com/)
• AndroMDA (http://www.andromda.org/)
• Eclipse ATL (http://www.eclipse.org/atl/) is a part of Eclipse Modeling project
• Eclipse QVTO (http://wiki.eclipse.org/M2M/QVTO) is a part of Eclipse Modeling project
• Itemis/Eclipse xpand/xtend (http://wiki.eclipse.org/Xpand) it was originaly a part of the no longer supported openArchitectureWare (http://oaw.itemis.com/ & http://www.openarchitectureware.org/) is now a part of Eclipse Modeling project
• Mia-Software Mia-Generation (http://www.mia-software.com/) is a part of Mia-Studio tool suite
• Mia-Software Mia-Transformation (http://www.mia-software.com/) is a part of Mia-Studio tool suite
• Obeo/Eclipse Acceleo (http://www.eclipse.org/acceleo/) is a M2T tool that has recently moved from the Obeo (http://www.obeo.fr/) company to Eclipse Modeling project

MDE application builders:

• Artisan Software Tools Artisan Studio (http://www.artisansoftwaretools.com/) for SysML
• Aspectize (http://aspectize.com/) for .NET target
• BluAge (http://www.bluage.com/)
• Jaxio Celerio (http://www.jaxio.com/)
• Jaxio SpringFuse (http://www.springfuse.com/) for Java Spring
• Mendix (http://www.mendix.com/)
• Outsystems Agile Platform (http://www.outsystems.com/agile-platform)
• SkyWay Software SkyWay Builder (http://www.skywayperspectives.org/) for Java Spring
• Sodius MDWorkbench (http://www.mdworkbench.com/ & http://www.sodius.com/)
• SoftFluent CodeFluent Entities (http://www.codefluententities.com/ & http://www.softfluent.com/) for .NET target
• SpringSource SpringRoo (http://www.springsource.org/roo) for Java Spring

Language workbenches:

• EMFText (http://www.emftext.org/)
• Itemis/Eclipse TMF Xtext (http://xtext.itemis.com/) is a part of Eclipse Modeling project (http://www.eclipse.org/Xtext/)
• Jetbrains MPS (http://www.jetbrains.com/mps/)
• Spoofax (http://strategoxt.org/Spoofax/WebHome)

DSM (Domain Specific Modeling) workbenches:

• Isomeris ABSE & Atomweaver (http://www.atomweaver.com/ , http://www.abse.info/ & http://www.isomeris.com/) quite intriguing tools that will be launched during Q3(July) 2010
• MetaCase MetaEdit+ (http://www.metacase.com/)
• Obeo Designer (http://www.obeo.fr/pages/obeo-designer/en)

MDE UI design tools:

• Eclipse E4/XWT (http://wiki.eclipse.org/E4/XWT)
• redView (http://redview.org/)
• wazaabi (http://wazaabi.org/)

Modernization tools:

• eclipse MoDisco (http://www.eclipse.org/MoDisco/) is a part of Eclipse Modeling project
• Mia-Sotware Mia-Modernization (http://www.mia-software.com/) is a part of Mia-Studio tool suite
• Obeo Agility (http://www.obeo.fr/pages/agility/en)

CASE tools with MDE capabilities:

• ModelioSoft Modelio (http://www.modeliosoft.com/)
• NoMagic MagicDraw (http://www.magicdraw.com/)
• Sparx System Enterprise Architect (http://www.sparxsystems.com/products/ea/)

XSLT based tool:

• Xomega (http://www.xomega.net/)

For the ones who don’t speak french, you  should watch at least the bibliography at the end of the pdf, since almost bibliography entries are in english.

The purpose of this paper is to have a french version of what is algebraïc graph transformations because there is almost nothing in french.

graphes.pdf

Regards.

• this is a mature tool,
• enterprise ready,
• and easy to use.

Then there’s a lot of great side functionalities like :

• reporting templates,
• dependency matrix,
• active validation
• and even more²!

But in a model driven environment, MagicDraw is great because of its open API which allows you to manipulate models and diagrams really easily.

So it’s time to introduce a simple plugin to get familiar with this open API!

Some resources to start

First of all, you’ll find javadoc and samples in the “<MagicDraw_Install_Dir>\openapi” directory and documentation in “<MagicDraw_Install_Dir>\manual\MagicDraw OpenAPI UserGuide.pdf“.

The documentation is really good, so I think you’ll find all what you need there.

How plugins are working?

Each time MagicDraw starts, it scans the “<MagicDraw_Install_Dir>\plugin” directory to find subdirectories containing two main things :

• A “plugin.xml” file which describes your plugin, the required libraries, and how to start it.
• A jar containing a class which extends the “com.nomagic.magicdraw.plugins.Plugin” and implements its “init()” method.

Plugin.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- The id must be unique, I generally put the class that extends the Plugin class as id. -->
<plugin
    <!-- The id must be unique, I generally put the class that extends the Plugin class as id. -->
    id="fr.free.mdwhatever.simplePlugin.magicDraw.SimplePlugin"
    name="SimplePlugin"

    <!-- Here I put project.version as version because Maven will filter it and put the same version you find in the pom.xml. -->
    version="${project.version}" 

    <!-- Who is providing this plugin (i.e. your company or whatever). -->
    provider-name="Xavier Seignard"

    <!-- The class which extends the com.nomagic.magicdraw.plugins.Plugin class
    in order to init your plugin within MagicDraw. -->
    class="fr.free.mdwhatever.simplePlugin.magicDraw.SimplePlugin">

    <!-- MagicDraw API version required by plug-in. Plug-ins and their requires versions required by plug-in. -->
    <requires>
        <api version="1.0" />
    </requires>

    <!-- The runtime libraries your plugin needs. -->
    <runtime>
        <library name="${artifactId}-${version}.${packaging}" />
    </runtime>
</plugin>

The SimplePlugin class

Here is the plugin entrance, take a look at the commented code.

package fr.free.mdwhatever.simplePlugin;

import com.nomagic.magicdraw.plugins.Plugin;
import com.nomagic.actions.ActionsCategory;
import com.nomagic.magicdraw.actions.ActionsConfiguratorsManager;
import com.nomagic.magicdraw.core.Application;

/**
 * This class allows you to load your plugin in MagicDraw
 *
 * @author Xavier Seignard
 */
public class SimplePlugin extends Plugin {

    // Methods
    /**
     * Plugin initialization and registration of the action in MagicDraw
     */
    public void init() {
        try {
            // We create a new actions category
            ActionsCategory category = new ActionsCategory(null, null);
            // We add our plugin action in this newly created category
            category.addAction(new SimplePluginAction());
            // We get the MagicDraw action manager
            ActionsConfiguratorsManager manager = ActionsConfiguratorsManager.getInstance();
            // We add our new configuration for our category in the MagicDraw action manager
            manager.addContainmentBrowserContextConfigurator(new BrowserContextConfigurator(category));
            // If everything is OK we log it to the MagicDraw GUI logger
            // Not really clever to put it there, but it's just to show how to log something in MagicDraw
            Application.getInstance().getGUILog().log("[Simple Plugin] Loading OK");
        }
        catch (Exception e) {
            // If something goes wrong we log it to the MagicDraw GUI logger
            Application.getInstance().getGUILog().log(
                    "[Simple Plugin] Could not instantiate plugin : " + e.toString());
        }
    }

    /**
     * The plugin is always supported, no matter the version of MagicDraw, or the perspective, or what you want.
     *
     * @return always true
     */
    public boolean isSupported() {
        return true;
    }

    /**
     * Return true always, because this plugin does not have any close specific actions.
     *
     * @return always true
     */
    public boolean close() {
        return true;
    }
}

This plugin has to do something!

How to trigger it?

Some plugin can just listen to some event, or it can be triggered by a contextual menu item or a button or whatever. In the case below we add a contextual menu item. (Have a look at the “com.nomagic.magicdraw.actions.ActionsConfiguratorsManager“)

package fr.free.mdwhatever.simplePlugin;

import com.nomagic.actions.ActionsManager;
import com.nomagic.magicdraw.actions.BrowserContextAMConfigurator;
import com.nomagic.magicdraw.ui.browser.Tree;
import com.nomagic.actions.ActionsCategory;
import com.nomagic.actions.NMAction;
import com.nomagic.magicdraw.actions.MDActionsCategory;
import com.nomagic.actions.AMConfigurator;

/**
 * This class allows you to add your plugin action (i.e. SimplePluginAction.java) in MagicDraw contextual menu.
 * @author Xavier Seignard
 */
public class BrowserContextConfigurator implements BrowserContextAMConfigurator {
    // Attributes

    // Here is the category of the contextual menu where you'll find you plugin
    public final static String SIMPLE_PLUGIN_MENU_CATEGORY = "Simple Plugin Menu Category";
    // Here is the ID of your category
    public final static String SIMPLE_PLUGIN_MENU_ID = "SimplePluginMenuID";
    // Plugin action
    private NMAction action;

    /**
     * Default constructor.
     *
     * @param nmAction the NMAction to set
     */
    public BrowserContextConfigurator(NMAction nmAction) {
        this.action = nmAction;
    }

    // Methods
    /**
     * Adds the plugin in the MagicDraw ui.
     *
     * @param mngr the action manager of MagicDraw to be configured
     * @param tree the containement tree of MagicDraw, where the plugin will be added
     */
    public void configure(ActionsManager mngr, Tree tree) {
        // We try to find the existing category
        ActionsCategory category = (ActionsCategory) mngr.getActionFor(SIMPLE_PLUGIN_MENU_ID);
        // If it doesn't exist we create it
        if (category == null) {
            category = new MDActionsCategory(SIMPLE_PLUGIN_MENU_ID, SIMPLE_PLUGIN_MENU_CATEGORY);
            category.setNested(true);
            mngr.addCategory(category);
        }
        // Then we add the action to the category
        category.addAction(action);
    }

    /**
     * Getter for priority.
     *
     * @return the priority int
     */
    public int getPriority() {
        return AMConfigurator.MEDIUM_PRIORITY;
    }
}

Set its behaviour

You have to extend the corresponding action, in this case : DefaultBrowserAction.

package fr.free.mdwhatever.simplePlugin;

import java.awt.event.ActionEvent;
import javax.swing.JOptionPane;
import com.nomagic.magicdraw.ui.browser.actions.DefaultBrowserAction;
import com.nomagic.uml2.ext.magicdraw.classes.mdkernel.Element;

/**
 * This class defines the behavior of the action in your plugin.
 *
 * @author Xavier Seignard
 */
public class SimplePluginAction extends DefaultBrowserAction {
    // Attributes
    // Serial version UID.
    private static final long serialVersionUID = 1L;
    // The name of the action which will be displayed in MagicDraw
    private static final String SIMPLE_PLUGIN_ACTION_NAME = "Simple Plugin Action";
    // The id of the action which will be displayed in MagicDraw
    private static final String SIMPLE_PLUGIN_ACTION_ID = "SimplePluginActionID";

    /**
     * Default constructor.
     *
     * @throws Exception if the super(...) call fails
     */
    public SimplePluginAction() throws Exception {
        super(SIMPLE_PLUGIN_ACTION_ID, SIMPLE_PLUGIN_ACTION_NAME, null, null);
    }

    // Methods
    /**
     * Here you define what does your action
     *
     * @param actionEvent the triggering event
     */
    public void actionPerformed(ActionEvent actionEvent) {
        SimplePluginBehavior simplePluginBehavior = new SimplePluginBehavior();
        CountingVisitor countingVisitor = simplePluginBehavior.getVisitor();
        // Clear the map for a clean count
        countingVisitor.getMap().clear();

        // Visit the children for counting elements of each type
        simplePluginBehavior.visitChildren((Element) getSelectedObject());
        // Display the counting results
        String result = simplePluginBehavior.returnResults(countingVisitor.getMap());
        JOptionPane.showMessageDialog(null, result);
    }

    /**
     * Defines when your action is available.
     */
    public void updateState() {
        // This action is only available when your click on an instance of Element in the containment tree
        if (this.getSelectedObject() != null) {
            if (this.getSelectedObject() instanceof Element) {
                setEnabled(true);
            }
            else {
                setEnabled(false);
            }
        }
        else {
            setEnabled(false);
        }
    }
}

This visitor pattern

The visitor pattern is well implemented in the Magicdraw open API, and it saves you a lot of efforts, so use it!

package fr.free.mdwhatever.simplePlugin;

import java.util.HashMap;
import com.nomagic.magicdraw.uml.BaseElement;
import com.nomagic.magicdraw.uml.ClassTypes;
import com.nomagic.magicdraw.uml.InheritanceVisitor;
import com.nomagic.uml2.ext.jmi.reflect.VisitorContext;
import com.nomagic.uml2.ext.magicdraw.classes.mdkernel.Element;

/**
 * This class extends InheritanceVisitor to count element through the visitor pattern.
 * @author Xavier Seignard
 *
 */
public class CountingVisitor extends InheritanceVisitor {

    // Map for counting results. Class type is a key, number is a value.
    private HashMap countMap = new HashMap();

    /**
     * The visitation of the element.
     *
     * @param element the element to visit.
     * @param context the context of the visitor.
     */
    public void visitElement(Element element, VisitorContext context) {
        super.visitElement(element, context);
        // Call the count
        countElements(element);
    }

    /**
     * Count elements of each type.
     *
     * @param element the element to count.
     */
    public void countElements(BaseElement element) {
        // We get the human readable name of the element
        String classType = ClassTypes.getShortName(element.getClassType());
        // Then we get the count of this type of elements
        Integer count = countMap.get(classType);
        // If it is the first element of this type we visit, we need to create a new value for the counting
        if (count == null) {
            count = Integer.valueOf(0);
        }
        // Finally we increase the count
        countMap.put(classType, Integer.valueOf(count.intValue() + 1));
    }

    /**
     * Getter for countMap.
     * @return the countMap
     */
    public HashMap getMap() {
        return countMap;
    }
}

The implementation of the behavior

Finally here is the implementation of the behaviour which allows you to calculate some metric like classes per package, or methods per classes :

package fr.free.mdwhatever.simplePlugin;

import java.util.HashMap;
import com.nomagic.magicdraw.core.Application;
import com.nomagic.uml2.ext.magicdraw.classes.mdkernel.Element;

/**
 * The behavior of our MagicDraw plugin
 *
 * @author Xavier Seignard
 */
public class SimplePluginBehavior {  

    // Our visitor to count the type of each element.
    private CountingVisitor visitor = new CountingVisitor();

    /**
     * Returns a string containing the counting results
     *
     * @param map the HashMap containing the counting results
     * @return string describing the counting results
     */
    public String returnResults(HashMap map)
    {
        // The string to return
        String textToReturn = "";
        textToReturn += "Number of elements for each types :\n";
        for (String key : map.keySet()) {
            textToReturn += "\t"  + key + " : " + (map.get(key)).intValue() + "\n";
        }

        // Calculation for some means (the real interesting part)
        Integer packages = map.get("Package");
        Integer classes = map.get("Class");
        Integer attributes = map.get("Property");
        Integer operations = map.get("Operation");

        if (packages != null && classes != null) {
            textToReturn += "Average classes per package : " + (classes.doubleValue()/packages.doubleValue()) + "\n";
        }

        if (classes!=null && operations!=null) {
            textToReturn += "Average operations per class : " + (operations.doubleValue()/classes.doubleValue()) + "\n";
        }

        if (classes!=null && attributes!=null)
            textToReturn += "Average attributes per class : " + (attributes.doubleValue()/classes.doubleValue()) + "\n";

        // if map was empty and no elements was found.
        if (textToReturn.length()==0)
        {
            textToReturn = "No elements found!";
        }

        return textToReturn;
    }

    /**
     * We parse all the children of the given root element.
     * For each element, we visit it to count the types of the elements
     *
     * @param rootElement the root element to start counting
     */
    public void visitChildren(Element rootElement)
    {
        try {
            rootElement.accept(visitor);
        }
        catch (Exception e) {
            // If something goes wrong we log it to the MagicDraw GUI logger
            Application.getInstance().getGUILog().log(
                    "[Simple Plugin] Exception occured : " + e.toString());
        }
        // We visit the children elements
        for (Element child : rootElement.getOwnedElement()) {
              visitChildren(child);
        }
    }

    /**
     * Getter for the visitor.
     * @return the visitor
     */
    public CountingVisitor getVisitor() {
        return visitor;
    }
}

Conclusion

You’re now familiar with the MagicDraw openAPI! So lets go and develop your own plugin!

You’ll find a packaged version of this Eclipse/Maven2 project there : magicdraw-simple-plugin.tar.gz
To set up your environement, you’ll have to upload some MagicDraw libs to your maven2 local repo. You’ll find them in the “<MagicDraw_Install_Dir>\lib\” directory. The list of the needed libs are described in the “dependencies” section in the “pom.xml” file.

You’ll also need to declare an environement variable “MDUML_HOME” which is the “<MagicDraw_Install_Dir>“.

Then if you execute a “mvn clean install” it will compile the plugin and install it on your MagicDraw installation. And you’ll just have to start MagicDraw to test the plugin.

In a next blog post we’ll see how to debug your plugins within Eclipse.

1 : Have a look here : http://www.magicdraw.com/main.php?ts=navig&=&cmd_show=1&menu=testimonials, you’ll find my testimonial!

2 : Here is the features list of MagicDraw: http://www.magicdraw.com/main.php?ts=navig&cmd_show=1&menu=feature_list

C’est ce que nous appliquons chez le client chez qui j’interviens.

Maven2 nous sert (entre autres) à :

• Exécuter un export vers XMI depuis MagicDraw ;
• Exécuter des fonctionalités particulières de MagicDraw sans pour autant lancer MagicDraw en mode graphique ;
• Exécuter nos propres plugins MagicDraw ;
• Valider nos modèles avec nos propres règles de validation codées avec l’API emf/uml2 d’eclipse ;
• Lancer nos transformations de modèle ;
• Et finalement de générer avec MIA-Generation.

Pour certaines des tâches ci-dessus il existe des plugins Maven2, pour les autres vous pouvez développer vos propres plugins Maven2.

Pas de panique, la courbe d’apprentissage est faible, et on obtient rapidement ce que l’on veut!

Malheureusement, il n’est pas toujours facile de trouver de la documentation sur la création de plugins pour Maven2.
Pour vous aider à débuter, voici quelques liens qui m’ont été très utiles :

• Maven Developer Centre
• API Maven 2.1.0 – Plugin
• API Maven 2.1.0 – Full
• Guide to Developing Java Plugins for Maven2
• Mojo Developer Cookbook
• Write your own report plugin
• Maven Properties Guide
• Create a Customized Build Process in Maven
• Creating an Ant Maven Plugin
• Créer un nouveau packaging Maven
• Maven DOCCK Plugin – Documentation Validation
• Maven – The Maven Embedder
• Tetedebois.org » Maven embarqué
• Re: Maven Embedder Example?
• How to resolve an artifact with maven embedder

Le rendez-vous est pris avec Maven3!