Dogen v1.0.18, "Estação dos Comboios"
The new CFM (Caminhos de Ferro de Moçamedes, or Moçamedes Railway) train station, next to the old. Moçamedes, Namibe, Angola. (C) 2018 Armando Chicoa (VOA).
Introduction
At about three quarters of the planned commitment, this sprint was slightly shorter than usual. Nonetheless, it is still packed with intense work and exciting progress: the "meta-model all things" theme continues in full flow, and we just about reached the next great refactoring battlefront - the fabric namespaces in the C# and C++ generation models. Predictably, there are not many user facing stories, as the refactoring continues to gather steam towards the ultimate V2 goal.
User visible changes
This section normally covers stories that affect end users, with the video providing a quick demonstration of the new features. As this sprint had only a very peripheral user visible change (discussed below), we took the opportunity to demo a couple of existing features instead.
Data directory clean up
For the last few sprints we have been chasing an elusive target: the removal of the assortment of non-model JSON files that have long lived in our data directory. If nothing else, anything with a name like "data" triggers immediately the "code smells" part of any developer's brain. With this sprint, we have finally achieved this milestone: the text templates that we use in the C++ and C# models have now been moved into the models themselves, with the addition of the text templates meta-modeling elements.
The change gave us the opportunity to rethink the approach from first principles. As a result, the data directory is no longer, and instead we now have only the library directory under the Dogen shared folder. It too will one day cease to exist, when we implement proper support for the PDMs (Platform Description Models) - but for the next three or four sprints it will continue to house the simplified version of the PDMs as they are currently implemented.
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.
Significant Internal Stories
There were four very significant stories this sprint, which we cover briefly below.
Use generated static configurations in transforms
First and foremost, consuming the majority of the sprint's resourcing, was the move towards using code generated static configurations. We started this work when we moved feature templates into the meta-model; it seemed only logical to start code-generating the C++ types to represent the dynamic configurations, as well as the "deserialisation" code that converted dynamic configurations to static configurations.
With this release we removed the majority of the hand-crafted uses of static configurations, making the code more readable. As an added bonus, It also means it's much easier to add new features to the code generator now: simply create a new instance of a masd::variability::feature_bundle modeling element, and add the required feature templates. While we were at it, we also cleaned up the way bundles were modeled, meaning we now have less boilerplate to add features and bundles are now more logically consistent.
As an example of how feature bundles are used, here's how we declare the generalisation feature bundle:
{
"name": "features::generalization",
"documentation": "Features related to the generalization relationship.\n",
"stereotypes": [
"masd::variability::feature_bundle"
],
"tagged_values": {
"masd.variability.default_binding_point": "element",
"masd.variability.archetype_location.kernel": "masd",
"masd.variability.template_kind": "instance"
},
"attributes": [
{
"name": "masd.generalization.is_final",
"type": "masd::variability::boolean",
"documentation": "Whether to mark a type as final or not.\n",
"tagged_values": {
"masd.variability.qualified_name": "masd.generalization.is_final",
"masd.variability.is_optional": "true"
}
},
{
"name": "masd.generalization.parent",
"type": "masd::variability::text",
"documentation": "Name of the parent of the current element.\n",
"tagged_values": {
"masd.variability.qualified_name": "masd.generalization.parent",
"masd.variability.is_optional": "true"
}
}
]
},
Users then make use of these features in their diagrams:
#DOGEN masd.generalization.is_final=true
#DOGEN masd.generalization.parent=some_package::some_type
We've already noticed how much quicker the development of new features has been since this new functionality has been added, so this is a great win.
Make wale templates meta-model elements
As explained above, we have been chasing the "meta-modelisation" of all configuration files that lived in the data directory for a long time. Wale text templates were one of the most annoying cases, because they really did not belong in the data directory; after all, text templates are internal to the model that uses them, rather than visible to all users of the code generator.
With this release, we've finished adding support for a logic-less text template meta-modeling element, which represents the text template. We then moved the templates into their respective models, under the new templates directory. The name logic-less was chosen to be close to the domain terminology but it perhaps yet another example of "domain overfitting": it seems it's more a source of confusion rather than enlightenment, as many users (and even domain experts!) are not familiar with the term. We will probably rename it to just "text templates".
Interestingly, in theory, this change should have made possible for users to create their own text templates. However, in practice, it is of extremely limited value because:
- we do not yet have a stable API for the meta-modeling elements;
- nor do we expose these properly to the templates;
- nor do we have a proper logic-less templating engine such as one of the mustache-like clones that exist in C++.
However, it lays an important foundation for the work to come in this space and, though long in coming, the end goal in the area is now very well defined.
Rename the coding model
Ever since we renamed our core model to coding we've been wondering if this was the right name. We've spent a fair bit of time wading through the literature in search of a fitting name, which would simultaneously reflect the domain terminology of MDE, as well as clarifying our intent. We've finally settled on assets, after reading the most enlightening review article by JM Jézéquel: "Model-driven engineering for software product lines".
The new name is also consistent with the fact that we intend to model both products and components within this meta-model, so hopefully the rename is future-proof, and - gasp - final. We have gone through some four or five names since Dogen's inception, so take that with a grain of salt.
Start of Fabric clean-up
One of the most anticipated tasks has been moving the fabric meta-model elements from the C++ and C# generation models into the assets model (as it is now known). This sprint fired the starting shot in this race: we have addressed the modeling of forward declarations in C++'s fabric. These have now been made consistent with the modeling ideas in Fabric. Sadly, many more items remain: some 15 or so elements need to be re-thought and re-modeled, moved into assets and then all of the associated formatting code needs to be updated.
Resourcing
As explained on the introduction, we've had around three quarters of the usual resourcing for this sprint, which was not ideal. On the plus side, over 77% of the sprint's total ask was spent on stories directly related to the sprint's mission, and just shy of 18% on process related work - with the release notes and demo consuming over 12% of that. Finally, we spent the remaining ~4% on spikes, mainly related to investigating the (many) test failures we're experiencing on Windows. Sadly no easy answers were to be found, so the investigation continues.
Planning
The project plan has suffered a couple of major setbacks this sprint. First, predictably, the fabric clean up was not completed this sprint. In addition, it is now clear it will be much harder than what we had estimated, so its now set to cost us the entirety of the next sprint. In addition, the PDM work is significant and it had not yet been added to the project plan.
The updated plan is now as follows.
Next Sprint
We shall focus on the Fabric clean-up for the entirety of the next sprint. It is likely that there will be some overrun, but we remain optimistic.
Binaries
You can download binaries from Bintray for OSX, Linux and Windows (all 64-bit):
Note 1: we've made some slight improvements to the build duration, but in truth we're still desperately close to our 50 minutes allocation on Travis, and as such we're getting many red builds. This is not ideal, so next sprint we will probably need to start disabling some of the generated tests to lower the build times.
Note 2: The OSX and Linux binaries are not stripped at present and so are larger than they should be. We have an outstanding story to address this issue, but sadly CMake does not make this trivial.
For all other architectures and/or operative systems, you will need to build Dogen from source. Source downloads are available below.
Happy Modeling!