Tuesday, September 6, 2011

Mylyn + Modeling = Love

It's been a while since I've posted anything here. Been busy doing real work -- you know, the kind that other people pay you to do. Specifically, I'm delighted to be working with the team at Tasktop, where I've been focussing on taking all of the Cool Stuff™ that Mylyn does and making it work with Eclipse modeling tools.

This looks like a match made in heaven. Eclipse is a great IDE, but if one were just looking for an IDE, there are many alternatives. But I think I can safely say that the Eclipse ecosytem has no real competition. What makes Eclipse truly great is not the bundled Java development tools, but the powerful and highly adaptable platform design, and most importantly of all, the open, transparent, and quality-focussed community structure that the Eclipse Foundation has worked so hard to build. That allows anyone with a good idea -- and the resources to make it a reality -- to play in the same sandbox as everyone else. For me, there are two exemplars for the potential of the ecosystem to be much more than the sum of its parts.

  1. The Eclipse Modeling Tools, including EMF and related tools, are what brought me to Eclipse platform in the first place. If you want to do real-world Model Driven Software Development, it would be hard to make a case for anything else.
  2. Mylyn demonstrates the kind of practical invention that is possible when a platform is really open. It provides a unique task-focussed approach to development. Admission time: It takes a bit of up-front investment to really grok Mylyn, and I didn't take the time needed to really integrate it with my day-to-day development effort until I started working with Tasktop. Working on my own and setting my own tasks, I just never really thought I needed it. But now that I'm back working with a team of developers on a regular basis, with dozens of tasks to keep track of, I'd be seriously annoyed not to have it.

In many ways, the match was remarkably -- sometimes ridiculously -- easy. It is a really cool experience when you work with completely different technologies that have been designed for adaptation to arbitrary uses, and those designs actually work! In some cases, such as making the Ecore Tools project manager integration work with the modeling context bridge, the actual implementation (minus all of the project packaging, .xml bits, etc..) was only a few lines of code.

Still, the connection didn't seem quite so natural when the two got together for a first date. David Green had put together something similar a couple of years ago, so I knew it was possible. But would sparks fly? Text and tree editors are naturally places for approaches that constrain and contextualize data selections. Graph structures are even better. The problem is that most diagramming artifacts aren't really graph structures -- they're actually pretty (or let's be honest, usually not so pretty..) pictures of graph structures.

The typical approach to software model diagrams is to take a snapshot of entities and their relationships and stick them on the wall. And people get really attached to where different elements are on that wall. In fact, I think one of the greatest anti-patterns for graphical modeling tools is to treat the pictures as the most important artifact of all...but I'm getting off-topic. The important point is that for the common types of diagrams such as UML class diagrams and Ecore we can't really move things around. Or we can, but then they wouldn't be the same artifact anymore. Again, that's because with many diagram tools the layout and location of various entities have semantic meaning, or at least people treat them like they do. And in practice, GMF doesn't provide a facility for changing any aspect of the actual diagram without affecting the persisted model. That seems like a no-no for a tool like Mylyn which is intended to be assisting developers, not modifying artifacts.

So clearly a good dose of gentle persuasion and hand-holding was called for. And I discovered that what GMF does have is support for decorators. Decorators essentially allow you to annotate a model without affecting the artifact itself. Rather than mucking about with the layout, could something workable be accomplished with creative decorations? The idea that made the most sense to me was to mask out the parts that aren't interesting, unmask or highlight pieces that are, and then sort of "ghost in" the other bits as people navigate the structure. I think it worked out pretty well, but I'm anxious to hear what you think. Does this approach make a decent trade-off between hiding the information you don't want to see and making it easy to discover the information that you do?

Those who have worked with the GMF Runtime may not be surprised to hear me say that the mechanism for doing all of this didn't seem exactly straightforward. You know how some frameworks seem never to have met an abstraction that they didn't like? There are probably great reasons for every one of the levels of generalization provided by the decoration and related mechanisms, but taken together there were a lot of pieces to grok. Thankfully, the EMF Compare team had just done a similar integration so I was able to learn a lot from that. But with a few false starts and uncomfortable moments, I can happily report that the couple is doing quite well, and I'm happy to have played a small role in this little bit of bliss.

It's not quite "official" yet, but there should be a contribution to Eclipse quite soon. In the meantime, it's reasonably stable and works with Ecore Diagrams and Papyrus UML Class diagrams. Details are here and we'd appreciate your bug reports and especially ideas for improvements.

Oh, ok... while I was at it, I grabbed a video of the two in action. Was that wrong of me?


  1. Great demo, Miles, this may possibly address my main grudge against graphical views of models (a.k.a. diagrams): that the representation does not scale well to handle big models with lots of details.

  2. Miles, the demo really rocks. Looking forward to the other great extensions for mylyn+modeling...

  3. Great stuff Miles. I *really* like how you implemented navigating items that are not yet in the context(ie, the Alt+click equivalent). Very slick.

    Dr. Mik Kersten
    Tasktop CEO, Mylyn Lead, http://twitter.com/mik_kersten

  4. Fantastic man, that's some groundbreaking stuff there in my opinion.

  5. Thanks all, I have to say that I'm pretty happy with how it came out too. :) It really is credit to the architecture of the mylyn and modeling tools that the basic implementation came together so easily. The fun part is what to do with the contextualized information once you can collect it, and now that we have the basic architecture there is a lot of room to explore.

    @Rafael That's exactly right. We have to work with the artifacts and approaches that we have and I think this approach does solve some of the issues with large models. So it is good to have the vision of companies like Ericsson and Tasktop that are dealing with real-world large models supporting it.

    It's still far from what one could imagine... the screenshot shows object collaborations that are already close together. If they were spread out, it wouldn't have made nearly as nice a demo. :) Still in most cases object collaborations are going to be composed of clusters of similar objects. And there are a lot more tricks we can play here. For example, we could have "signposts" that gave hints about what objects were off screen, perhaps local decorations that mirrored offscreen collaboration, and the mouse navigation could be enriched so that you could quickly move to semantically adjacent objects/clusters.

    I think the deeper issue is that current diagram approaches -- not to mention almost all of the APIs, with the notable exception of Zest -- are based on building static artifacts. That's the wrong approach! They need to be dynamic and I've explored some different approaches to that in the past, but needless to say that is a much more ambitious effort.

  6. @Mik The interesting thing is that it actually "feels" better than it demos, because the shadowing continuously responds to mouse movements. So it's a really nice affordance that IMO works much better than the simpler approaches I tried, but it meant a _lot_ of fiddling to get it right. (BTW, I think there is an interesting challenge for agile-development buried in there that I might blog about. :))

    The good side of using a visual representation that is relatively information sparse -- as Rafael points out that is generally experienced as a limitation -- is that there is a lot of room to maneuver. We can use all of that extra space to create a more seamless transition between contexts, which is what I think you need in order to allow people to explore the surrounding "semantic territory" more naturally. And there are even better ways to do it with dynamic tree layouts. In dense representations like trees and text, it's obviously much more difficult to provide this sense of context exploration, but it would be a fascinating thing to experiment with.

  7. Miles, looks amazing. Love the visual feedback when revealing items that weren't previously in the context.

  8. I should have mentioned: really great that the context filtering doesn't mess with the diagram layout. Context helps to make relevant things more visible, but things are still where you expect to find them.

    I'm not sure how this would apply for very large diagrams - could be that there would be a lot of whitespace. It could be that most diagrams have related things in relatively close proximity to each other, so whitespace may be a non-issue.

  9. @David thanks. :) Yes, I think the issue of having object collaborations far apart is the major potential challenge for this approach. See the discussion above about signposts, and I've created a Wiki entry to discuss this.. http://wiki.eclipse.org/Mylyn/Context/Modeling_Bridge#Show_Focussed_Collaborations


Popular Posts

Recent Tweets

    follow me on Twitter