Dogen v1.0.14, "Deserto do Namibe"
Dunes in the Namib Desert, Namibe Province, Angola. (C) 2012 João P. Baptista.
Introduction
This sprint was yet again an extremely busy affair. However, for a change, work was mainly focused on the task at hand rather than on distractions such as testing. As a result, we have finally delivered the first of a number of core meta-model changes that aim to regularise our approach to the modeling of elements across the solution space. In other words, it may appear like a small release to the untrained eye, but it feels like a giant leap to the development team.
As you will not fail to notice, the release notes have been tweaked yet again in response to feedback: we now start with the user visible changes, and proceed to discuss internal matters afterwards.
User visible changes
This section covers stories that affect end users. The sprint demo provides a quick demonstration on the user visible changes, whereas the below sections provide more detail.
Decorative elements are now in meta-model
Before delving into the details of the feature, it is worth providing some context. Up to now we have separated configuration from modeling proper. As a result, there are a number of little configuration files, each declared and consumed by user models via its own ad-hoc mechanisms. As MDE theory became better understood, and as the MASD approach cemented itself, it became clear that these configuration units are indeed worthy of modeling just like any other higher level concept present in a product. This release sees the start of a long process that, when completed, will finally move the architecture to its desired state. Sadly, it will require quite a large engineering effort to get there.
As for the feature itself: this release places the management of modelines, licences, location strings (known in Dogen speak as "generation markers") and other decorative elements into the meta-model. This means that instead of an assortment set of data files of varying formats, these are now contained in a "regular" model and can be extended and/or overridden by users as required.
The masd model defines a number of these which can be readily used:
In order to make use of these new model elements, you need to first define a reference to masd (assuming a Dia model):
#DOGEN masd.injection.reference=masd
And then you can set up the meta-data as required:
#DOGEN masd.generation.decoration.enabled=true
#DOGEN masd.generation.decoration.licence_name=masd.gpl_v3
#DOGEN masd.generation.decoration.modeline_group_name=masd.emacs
#DOGEN masd.generation.decoration.copyright_notice=Copyright (C) 2012-2015 Marco Craveiro <marco.craveiro@gmail.com>
Please note that these keys were previously available with different names, so this is a breaking change. The fields have been updated from:
masd.decoration.enabled
masd.decoration.licence_name
masd.decoration.copyright_notice
masd.decoration.modeline_group_name
to:
masd.generation.decoration.enabled
masd.generation.decoration.licence_name
masd.generation.decoration.copyright_notice
masd.generation.decoration.modeline_group_name
As you can see, from a usage perspective these are very similar to the previous approach (modulus the field name changes). However, the advantage is that you can now define you own modeling elements (licences, etc), on either the target model or a model shared by a number of target models - as in the masd model example above.
Language rename
Sadly, this is not the only breaking change in this release. The "language rename" is explained in more detail below on the internal section, but from a end user perspective, it is a breaking change. The following fields have been renamed:
#DOGEN masd.injection.input_language=cpp
#DOGEN masd.extraction.output_language=cpp
They must be updated to:
#DOGEN masd.injection.input_technical_space=cpp
#DOGEN masd.extraction.output_technical_space=cpp
Development Matters
In this section we cover topics that are mainly of interest if you follow Dogen development, such as details on internal stories that consumed significant resources, important events, etc. As usual, for all the gory details of the work carried out this sprint, see the sprint log.
Milestones
With this release, we have made the 8888th commit to Dogen! I guess a celebration blog post is in order, though it's always difficult to justify taking more time away from coding.
Significant Internal Stories
Several very important clean-ups were achieved this sprint:
- Move from "languages" to "technical spaces". This is somewhat difficult to explain without getting into the details (which my thesis will explain properly), but with this release we have started a move from mere programming languages towards technical spaces as MDE understands them. This will in time provide a much cleaner conceptual model.
- Simpler qualified name representation. In the past we had relied on maps, and associated qualified names directly with programming languages. With this release we now have a cleaner representation for these.
- Clean-up of the extraction model. This story is related to the user visible feature above, but from an internal perspective. We have now moved all code in the extraction model which didn't belong there. There is only one outstanding task to finish the clean-up of this model, but it already looks in a much better shape.
Resourcing
Most of the sprint's time was spent towards moving extraction model entities into the coding metamodel (~45%). Around 18% of the total time was dedicated to process, with the bulk of it taken by backlog grooming (9.5%), project planning (just below 3%) and the editing of release notes and the creation of the demo for the previous sprint (~2% and ~4% respectively). We also had a couple of spikes.
The first spike had a cost of around 4%, and is related to integrating Report-CI; this is the latest project by Klemens Morgenstern, the amazing coder behind Boost.Process and other core libraries. As always, we are happy to help fellow travellers on their road to product building. In addition, integration was fairly trivial (mainly reviewing Klemens' PRs) and we've already started to see some of the benefits as we start to make use of the reports the tool produces.
The second spike cost circa 3.3% and was related to fixes to the emacs setup. Improvements in the development environment are always welcome, and tend to have a very positive impact, though in ways that are somewhat difficult to measure.
The complete story breakdown is as follows:
Planning
Sprint 14 introduces a project plan. Given Dogen is on the critical path of my PhD, it seemed like a good idea to create some kind of road map that gives an inkling as to when I can start to think of completing it. It has the grandiose name of "project plan", but alas, it is nothing like a project plan for a real industry project. In truth, I've never been a great believer in the estimation process; the objective here is just to have some kind of projection, regardless of how crude, of what is left to do in order to release the fabled v2 release.
At the end of sprint 14, the plan looks like this:
We will keep it updated with each release.
Next Sprint
As per the project plan above, we are expecting to continue the meta-modeling work in the next sprint by tackling a very thorny issue: moving profiles into the meta-model. This is a feature of pivotal importance to make Dogen usable because it will finally mean users can define profiles such as serializable and the like on their own diagrams, associate them with user defined configuration, and ultimately apply them to element types. Profiles are key to unlocking Dogen functionality, so we are extremely excited to finally get to work on this feature.
Binaries
You can download binaries from Bintray for OSX, Linux and Windows (all 64-bit):
For all other architectures and/or operative systems, you will need to build Dogen from source. Source downloads are available below.
Happy Modeling!