Cedric Brun (OBEO )
Making at Eclipse · Standard
Tuesday, 11:10, 20 minutes | Stevens Creek
Alice looking at some code: «Hey, why is this thing designed this way ? It looks way more twisted than necessary»
Bob : "Just check the design documents."
An application has its own lifetime and quickly after the first major release is done, design choices are vanishing with the team being re-affected.
Then most of the time spent on the software is dedicated to browsing through it, doing changes and testing those just to figure out the implications of the change.
Developers do write doc but it’s just too much of a burden to maintain those. Mylyn did start to off-load the developer brain by leveraging the - invisible at that time – Task concept.
With its recent re-structure, Mylyn scope has been broaden to the whole Application Life-cycle Domain, integrating Source Control Management, Continuous Integration and tooling support to practices like code reviews.
Documentation is a major aspect of life-cycle management : just like Tasks have been transformed into a useful construction to the developer now that they have an associated context, document can turn into a real support for sharing knowledge about some design if keeping this documentation in sync with the reality is a no-brainer.
Donald E. Knuth proposed a solution to this exact problem for software through the definition of "Literate Programming" : a language mixing documentation and code. Even if this approach looked appealing, it could not fit with the industry practices, adding too much burden, especially with code which is inherently operational.
That said, providing such an approach in a more flexible way on top of models (which are inherently declaratives) is a promising way to help developers to provide useful documentation and to keep it up-to-date. Furthermore, integrating it directly in the IDE lowers the barrier of the documentation update and will allow cross-references with development artifacts. That’s what the Intent project is about.
Let’s take an example : a developer documents the general architecture of his software, describing its OSGi modules, their id and dependencies and the reasons why the system has been designed this way. These instructions are part of the doc and are compared, when the doc gets validated, with the informations provided by the PDE in this regard. Any inconsistent state leads to problem markers with associated quick fixes to either update the doc or the bundles.
This talk is about introducing this technology to you through an example of usage : Alice is going to add a new feature into the software, and we’ll see how the tooling will complement her actions, helping her in designing this change while updating the corresponding documentations, and making all the decisions she had to take clear for her all team.
This technology – just like Mylyn task focused UI – relies a lot on the integration it can have with other projects. That’s why the second part of the talk will show – as a tutorial - the definition of a dedicated connector bridging some PDE artifacts with the documentation. This will demonstrate how Intent can avoid misunderstanding issues, especially with new members of your team.
Cedric leads the Modeling Amalgamation and EMF Compare components, is commiter on several Eclipse Modeling projects (Acceleo), and his both member of the Eclipse Architecture and Planning Councils. As a product architect at Obeo he is technical lead of Obeo Designer and works on software evolution, re-engineering and cartography of legacy systems; all through model driven processes. He has graduated both the Polytech engineering school and a research Master at the University of Nantes and specialized himself in software engineering and model driven engineering. Prior to his current jobs he has been an active contributor to open source and worked in Guangzhou on a global video conference solution for the Chinese Education and Research Network (CERNET).