hide all comments

DSM-tech

Oslo Quadrant reviews

June 12, 2009 19:17:12 +0300 (EEST)

The May 26th CTP of Oslo includes the first public version of Quadrant, Microsoft's visual model editor. I've had my head down on other topics, so haven't had a chance to play with it yet, but here are some reviews from others.

Charles Young, Initial experiments

Microsoft is publically committed to providing strong UML and XMI support in 'Oslo' and this is our first glimpse of what they intend. ... My initial experiments with LoadUML suggest that the tool is not yet fully functional. For example, it fell over the use of the xmi:type attribute on the uml:Model element. It failed to handle a type element of an ownedAttribute, and it didn't recognise the packageImport element. The error messages were not always very helpful and the tool is slow...
Initial experiments with LoadAssembly went a little more smoothly. Again, the tool is very slow, and can take several minutes to complete imports...
This early version of Quadrant has big problems with big models. It could, in some cases, take several minutes of 100% CPU usage to display the contents of a folder. Memory usage can also grow to monumental proportions...
All in all, don’t expect Quadrant or the new loaders to behave very well. This is very early preview code.

Charles did manage to get an XMI file and .NET assembly imported after some messing around, so it wasn't all bad. But those speed and memory problems aren't going to go away just by optimising code: scalability is something that must be architected in from the start.

Frank Lillehagen, Quadrant - First Impressions (I had the pleasure of meeting Frank in May 2001, when he was VP at Computas and responsible for the Metis modeling tool - first released in 1991!)

Quadrant's user interface is novel, uniform, and functional, but a bit cumbersome, and as an early preview it exposes a lot of the underlying wiring, nuts and bolts. Some functionality is well supported, such as customizing views and interacting with large models in multiple workpads. On the other hand, services for e.g. relationship modeling are poor. ... Visualization is the focus, more than modeling.
The layout of diagrams is partially automated, however when you close and reopen a diagram, it will revert to an automatic layout, not keeping the location changes you made manually the last time.
The support for key visual modeling concepts like relationships is not native, and limited. Quadrant does not recognize many-to-many relationships from entities, leading to diagrams ... where [half] the shapes are really relationships that ... should be shown as links.

From the pictures Frank posted, the existing models in Oslo break many principles of good modeling design. Having automatic layout that loses your manual layout changes pretty much rules out the chance of getting to know your way around your models, for any diagram more complex than a simple tree. And having no n-ary relationships is going to mean unwelcome hacking for both metamodelers and modelers: many relationships are binary, but certainly not all.

I'll continue to follow the progress of Quadrant with interest, but there seems little point getting my hands dirty with it yet. It's a shame that it seems to be back to square one for modeling at Microsoft - this is like the early versions of DSL Tools, and you'd think they'd have moved on in the 5 years since we first saw that. When we did a complete rewrite of MetaEdit (released 1993) to get the first version of MetaEdit+ (1995), there was rather a lot more that worked, and the scalability was already in place. The UI wasn't pretty, so we'll give Quadrant the thumbs up on that score, but the real worth of an application like this lies between the UI and the database. If Quadrant only works for binary relationships, autolayout, and small models, there's some major rework needed before it becomes a serious contender. Let's hope their bosses give them chance to do it!

Comments

An update on relationships and view customisation

[Håvard Jørgensen] June 13, 2009 14:39:54 +0300 (EEST)

Good of you to refer to our blog (though you got the author wrong). I've made a minor revision in one of the sections you quote, based on a closer examination of the mechanisms for tailoring views. No surprising, there is more under the hood than Microsoft has documented publicly so far.

Thanks for the update

[Steven Kelly] June 14, 2009 11:57:00 +0300 (EEST)

Sorry to have got the wrong author, Håvard: I knew the two of you wrote for that blog, but thought Frank was responsible for this entry - I'd read another entry of his and mixed the two up in my head.

The question of where to store information about what is graphically or semantically a relationship and what is an object is an interesting one. For Oslo and Quadrant, where the idea seems to be more the ability to visualize data in many ways, it maybe makes sense to store this as "hints" outside the original (abstract) metamodel. However, if the intention is to make a graphical modeling tool, in particular for DSM, where each abstract metamodel will only have one concrete syntax, then this extra indirection just makes life hard for the metamodeler. That's one of the main problems with EMF + GMF, and why they need five different tools to cobble together a basic graphical editor.

MetaEdit+ was built to support polymorphism of metatypes: an object type in one metamodel could be a relationship type in another metamodel. In practice nobody used this - NIAM is about the only language for which it is the natural implementation - so we removed that possibility, making the tool easier to understand and use. We've found that having n-ary relationships, letting objects and relationships directly reference each other via properties, and allowing a relationship to have a subgraph, is easily sufficiently powerful. After all, the results have to be understandable not just to metametamodelers, but metamodelers and their modelers too!