A coffee with Javier Muñoz (MOSkitt – Eclipse Modeling Platform)

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

MOSkitt is a free CASE tool, built on top of the Eclipse Modeling technologies and developed by the Valencian Regional Ministry of Infraestructure and Transport (VRMIT).

A couple of weeks ago I started the a coffee with … series interviewing Javier Muñoz , technical leader of the MOSkitt development team, to know more about this modeling platform (why creating the tool?, how is the tool developed?, what are its main features?, what kind of models are supported?,…).

This is the result of the interview (once transcribed, translated and edited to shorten some of the questions/answers), hope you enjoy it!

Jordi Cabot (JC) – Javier, to begin with, can you explain yourself what MOSkitt is?
Javier Muñoz (JM) – First of all, thanks for inviting us to this first interview. Regarding MOSkitt, the final goal is to provide good tool support to the development process internally used in the VRMIT. However, from the beginning the idea was to build MOSkitt such that it could be useful to other organizations. Its design and architecture was done thinking in providing a platform and a set of technologies that any organization could adapt to suit its own development method.

JC – Maybe surprisingly, you’ve NOT used the term modeling tool TO DESCRIBE MOSkitt. I guess you think IS much MORE than just a modeling tool
JM – Yes, MOSkitt has modeling tools (FOR UML2, FOR database design, FOR business process modeling,…) but also includes code-generation (e.g. SQL) AND model-transformation facilities,… The modeling part IS there TO cover a specific step IN the development process but other phases require other kinds OF tool support that we also try TO provide.

JC – What ARE the main benefits OF MOSkitt? Maybe this “process dimension” AND NOT just being a modeling tool?
JM – Exactly. What distinguishes us FROM other tools IN the OPEN source DOMAIN IS the support MOSkitt gives TO the execution OF development processes. Users can now AT ALL times what tasks can be done AT that given stage OF the process, what tools within MOSkitt can be used TO perform those activities, what information IS needed,…

JC – Can’t this be found in other Eclipse Modeling tools (e.g. Papyrus)?
JM – Not that we are aware of. Papyrus tries to be the best modeling editor for UML2. In fact, MOSkitt contributes to the Papyrus project and in a mid-term, we hope to use Papyrus as a modeling editor for MOSkitt.

JC – What’s the architecture OF MOSkitt?
MOSkitt IS based ON Eclipse. ALL tools IN MOSkitt ARE developed AS Eclispe plug-ins extending other Eclipse technologies (EMF, GMF, Eclipse UML2…) OR WHEN NO base project was available, we also developed our own infrastructure. FOR instance, 1 – a transformation manager that registers ALL available transformations (M2M AND M2T) IN the project AND offers a wizard TO assist IN their execution IN an homogeneous way AND 2 – A form editor that automatically takes care OF updating underlying EMF models AND 3 – several other extensions, e.g. TO GMF (WITH extended model browsers, integration OF different editors,…).

JC – Could MOSkitt exist without Eclispe? Would you have started it?
JM – NO. WITH the resources AND budget we have it would have been completely impossible without reusing ALL free technologies available IN Eclipse. AS an example, we have registered our FULL source code IN OHLOH (a web page that computes metrics FOR OPEN source software) TO see how much it would have cost TO WRITE everything FROM scratch AND the resulting NUMBER OF man-years required IS huge (JC – the exact NUMBER 439 person-YEAR was given IN Vicente Pelechano’s presentation ). Only when most of those lines of code are, in fact, reused from Eclipse, a project like this becomes feasible.

JC – What about the bugs or limitations of Eclipse you’ve FOUND WHEN developing MOSkitt?
JM – We always try TO contribute WITH patches TO the original project AND if needed, we modify ourselves the code (AND OF course, ALL the source code can be freely downloaded FROM the PUBLIC project repositories)

JC – Can everybody contribute TO MOSkitt?
JM – There IS a GROUP OF committers WITH permission TO UPDATE the code but everybody can perform a checkout USING this URL updated almost IN REAL-TIME .

JC – ARE there contributors outside the main development GROUP?
JM – We have several Valencian companies that ARE contributing TO the project AND, MORE recently, also the company OPEN Canarias IS helping WITH the subproject FOR form-based editors. We hope MORE collaborators JOIN us IN a near future

JC – Another surprising thing about MOSkitt IS that it IS free FOR the users but IN fact its development IS paid by the Valencian Regional Government. What do they gain WITH the existence OF MOSkitt TO justify the investment?
JM – MOSkitt IS part OF a larger project gvPontis that pretends TO migrate ALL the technological infrastructure OF the VMRIT TO OPEN-source software (FROM the databases TO the desktop tools AND even the geographic information systems WITH the project gvSIG). WITH MOSkitt, they realized it was cheaper TO develop an Eclipse-based tool TO support the development process internally used IN VRMIT than paying the licenses FOR the proprietary software they were USING until THEN. AND, AS an additional benefit, VRMIT believes that initiating this project will favour LOCAL software development companies that will be able TO reuse AND extend this effort

JC – How big IS the development team?
JM – Around 10 people including developers funded by private companies that believe IN the project AND plan TO use it IN their own development projects.

JC – IS this a long-term project?
JM – Yes, VRMIT always says that its role IS TO kick-off the project but that LOCAL companies need TO realize its benefits AND contribute TO its support IN the future.

JC – IS MOSkitt built USING model-driven techniques itself?
JM – Absolutely yes. We use the same development process gvMetrica that MOSkitt aims TO support, TO develop MOSkitt itself, which help us TO GET feedback that can be used TO improve the tool. Moreover, the own Eclipse technology we ARE USING (EMF, GMF,…) follows this same paradigm (e.g. you must define FIRST the metamodel TO be able TO automatically generate the modeling environment) so, WHEN USING it, you have TO follow the same process.

JC – Can you clarify what IS exactly the development process used within the VRMIT?
JM – VRMIT uses gvMetrica, an adaptation OF Metrica, the standard development process that ALL PUBLIC Spanish administrations must follow. Metrica IS a very generic process so VRMIT adapted it TO its specific needs.

JC – IS gvMetrica the main source OF requirements FOR MOSkitt?
JM – We follow an iterative development process (iterations OF 4 months). IN each iteration the users test the tool TO detect bugs but also TO detect new functionalities AND usability improvements. THEN, they ARE prioritized AND implemented ASAP. The USER feedback has shaped a lot MOSkitt

JC – So far, has the feedback been positive? Do users say MOSkitt improves their productivity?
JM – Yes, because WITH previous tools users had TO adapt the tool but MOSkitt adapts TO the users, TO the way they WORK. That’s why they are happy with the tool.

JC – What kinds of models are supported by MOSkitt? Do you support all UML2 diagrams?
JM – We focus on those we believe are most used and necessary in VRMIT: class diagrams, use cases, sequence, activity and state machines.

JC – Can this models be automatically transformed? Can you go from the initial BPMN diagram to a first sketch of the UML model? And then from the UML models to code?
JM – We can derive a user interface model, which can be manually complemented to indicate what information each page should show, what operations must the page offer,… We can also generate database schemas and a prototype of the (web) application, in particular in PHP using the framework gvHidra (another project developed in the VRMIT). We are now working on the generation of fully-functional applications

JC – But it seems that the automatic code-generation is not the most important goal of MOSkitt just another aspect of the tool
JM – The goal is to support the development process but we’d also LIKE that this process ends up WITH the automatic code-generation OF the application.

Do you really believe IN generating the 100% OF the application code?

JM – If we RESTRICT the possible domains FOR the applications TO be generated

JC – AND do you think the modeling effort (TO achieve the FULL-code generation) pays off?
JM – We try TO cover ALL common situations AND, FOR the rest, generate the code such that it can be easily modified TO adapt it TO specific customer requirements

JC – Do you keep traceability information BETWEEN the models AND the code?
JM – RIGHT now we have traceability BETWEEN the models. We ARE studying how TO extend this TO include traceability BETWEEN models AND code AS well

JC – What about the quality OF the models? IS there ANY kind OF validation/verification process included IN MOSkitt?
JM – The modeling editors include syntactic checkings. There IS NO general PROCEDURE TO verify MORE semantic correctness properties. We manually integrate those checks that users request. An important aspect IS that new validation rules can be added IN a non-intrusive way (i.e. without modifying the editor’s code).

JC – Is there any OCL support?
JM – We just have the same support that Eclipse includes by default, i.e. there is no code-generation from OCL expressions although this will become necessary once we advance in our new code-generation project.

JC – For this code-generation goal, you also need to describe the behavior in detail. For that the OMG is proposing an Action language (as part of the future “executable UML” standard). What are your plans on this?
JM – We plan to complement existing models (e.g. state, sequence) with some kind of textual language. Action Semantics could be the basis of this textual language

JC – What is your position wrt textual modeling languages?
JM – Our users (that have more an analyst profile than a programmer one) have not expressed so far their interest in textual modeling editors. We believe that both kinds of languages have their place in the development process.

JC – And the relationship between MOSkitt and DSLs?
JM – In fact, MOSkitt has created some DSLs for some specific tasks in the development process (e.g. for the user interface models) and uses other DSL technologies (as XText) when necessary. We are completely open to them.

JC – What has the major challenge been in the development of MOSkitt
JM – The need to educate all new developers joining the team since the technologies we use in MOSkitt are not taught at the university (at least here). Also, the lack of maturity of these technologies, specially when we start developing MOSkitt (three years ago). This includes the lack of documentation. This situation has been improving over time. We are happy with the evolution of the model-driven tool ecosystem

JC – What lies in the future?
JM – The first aspect is integrating the modeling of user interfaces. We believe there are not yet (good) standards for this. A second aspect is extending our code-generation capabilities. Also, we want to keep improving the tool support to the gvMetrica development process.
Another very important aspect for us is growing the community of users (and companies)

JC – Yes because so far my feeling is that MOSkitt has decided to keep a low-profile so far, maybe because you were waiting till having a more mature tool
JM – We’ve been attending several Eclipse conferences TO showcase our tool AND MOSkitt IS now been used IN several european research projects IN which SOME OF the companies that contribute TO MOSkitt ARE participating. It’s true though that increasing our international presence requires time and resources (support to users, better documentation, in several languages) and until now we were more focused in the development of the product but we do feel that now it is the right time to go out there and start promoting more our product.

JC – How do you see the evolution of the modeling tools marked in the future? Will we see more and more tools heading to Eclipse (e.g. Poseidon did this move not so long ago)?
JM – Eclipse facilitates the interoperability between the different tools required in every development process, solving many of the problems we face when developing several stand-alone tools. Moreover, Eclipse is free but at the same time allows commercial extensions. This facilitates that vendors create their own tools but that at the same time these same tools can be easily integrated with others within the Eclipse environment and this is very important for potential customers.

And regarding the modeling tools, to be really useful they must be part of a development process and somehow they’ll need TO improve their integration capabilities so that they can be easily combined IN a single development process.

JC – IS there something ELSE you want TO ADD?
JM – Just let me thank our excellent development team, very enthusiastic AND always eager TO learn new things AND do their best FOR the benefit OF the project. It IS also important the fact even though the team has different backgrounds (university, PUBLIC administration, private companies) we still manage TO coordinate well AND have fun!.

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
Comments
  1. Anonymous
  2. orlando

Reply

Your email address will not be published. Required fields are marked *