The ORM Foundation

What integration does (or will soon) NORMA provide to other parts of Visual Studio?  I'm thinking of the following:

• Team Foundation Server Source Library
• Visual differences between versions stored in TFS source library
• Identification of individual ORM objects from the rest of Visual Studio
• Link to ORM role or object from a Visual Studio work item
• Click between linked ORM objects and linked work items (e.g. test case, user story, dev. task)

and a separate question desire:

• Separate models that can be worked on (simultaneously by separate modelers) yet linked together and with selected objects visible and usable from one another.

Hi Jim,

At this point we have not done any work to integrate NORMA with Team Foundation Server. Honestly, I haven't even researched it, and I don't own either the TFS software or the higher-end client boxes.

To be brutally honest here, the cost/benefit ratio of the larger VS boxes may be worth it for medium-to-large shops, but I can't come close to justifying the cost of the enterprise (now Premium and Ultimate in VS2010) Visual Studio boxes. The higher end boxes are way beyond the affordability bar of most small shops, including mine.

[Short rant following, skip if you like] Frankly, the VS Pro cost for 2010 is at the point where putting a standalone version of NORMA together will get higher priority. I did not mind asking users to absorb the VS Standard costs for VS2005/VS2008 (street costs around $150, although the costs to European users was much higher than in the US), but a VS2010 Pro list price of $799 (the lowest SKU I could find on microsoft.com) is well beyond what I can reasonably ask NORMA users who do not already have VS 2010 to pony up. I'm left shaking my head wondering what happened to the original MS Developer Division mission of supporting the platform by attracting developers to the platform--not pricing Joe developer out of even considering it. The extremely high price point for getting the VEA tools in the 2003 and 2005 products was a major driver in killing the product line. [end of rant]

We did some initial research on diff engines for .ORM files that would do a better job at the XML level, but have not taken this past the research stage. I have not looked at visual diffs at this point. The issue with Visual Diffs is that not all elements have visually represented differences, so reaching a full visually representable diff will take quite a bit of specification work.

As for separated .orm files, we've been doing some real-world investigations in these areas with the LogicBlox teams that have allowed multiple large models to be merged together (2-4MB files merged into 10-15MB files). The utility we have isn't ready for public consumption at this point (not all extensions are handled, and element matching is pattern based (not id based) so changes in one file require changes in the other before reimport). The approach we've settled on has been to use groups to import numbers of .orm elements from one file into another, and then update the limited number of elements in the consuming file with a reimport. This keeps the models relatively small, while allowing componentized models with a public (relatively static) face. If you're interested, we can talk more on this topic off line.

Sorry for lack of better answers here (and the price rant), I'm just giving you an honest assessment of where we are. The TFS bits are low priority at this point, but the multi-model work is something we are actively working on and will be touching more in the next few months. Model splitting and merging are high-priority scenarios moving forwards.

-Matt

The US online store has a VS standard => Pro upgrade for  $299 at http://store.microsoft.com/microsoft/Visual-Studio-2010-Professional-Upgrade-for-Visual-Studio-Standard-Users/product/BE303EE9.

Additionally, would an isolated shell approach be cheaper for end users? (If DSL designers can be hosted in an isolated shell... I tried looking but didn't find anything quickly.)

 Bill

Hi Bill,

The isolated shell would certainly be cheaper for end users, and DSL designers can be hosted there. Apart from reanchoring artifact generation (which uses the IVsSingleFileGenerator-related services from the C#/VB project system), the problem is a licensing issue, not a technical issue.

Very earlier iterations of the NORMA tool tried to use more of the DSL-provided services such as the DSL-native Model Browser. However, the scaling on the DSL-provided browser at the time was pathetic (half second slow downs on any operation when the model was ~200 primary elements), so I jumped in to build my own system. The replacement choice of platform was the VirtualTreeGrid control that installs with Visual Studio. Although this control was not publicly documented, when I left Microsoft in 2004 there were plans in place to do that, and it was already in heavy use internally (the Class View used it, as well as several clients (profiler, etc) in the Team Foundation pieces). I was also quite familiar with the control (it was my brainchild, and I wrote the vast majority of the code). So, I felt confident in using it. Also, a replacement was prohibitive (the control has about 10,000 lines of code in the 'ITree' data engine, and about twice that much in the UI portion, so it is not a small project).

The following history was not so favorable: the documentation was not completed, minimal additional changes were made for 2008 and (?)2010, and (most relevant here) the control did not ship with the VS shell editions (MS would not pre-release a file list of what was shipping and what was not prior to the final shell release). We've tried various channels to get it either included or opened up as a community project, but to no avail.

The control is used because it is scaleable (performance is based on the number of branches, not the number of items, so population with n*10,000 items is instant), virtual (the control retrieves all data through the IBranch interface), and flexible (custom inline editors, expandable subtrees within a cell, multiple glyph sources). We use this control for the model browser (scalability required, along with glyphs and other inputs provided by multiple packages), reading editor (note the use of the inline richedit control, which you can't do in a normal tree), sample population editor (complex cell expansions supported for compound identified items and subtype instances), transaction viewer (one of the debug items, uses complex cells, inline expansions, etc), and most of the other list and tree-based dropdowns.

Of course, after several years of inactivity, the control is obviously long in the tooth, and occasional bugs have caused some problems. I'd also like more flexibility in display (variable item height, custom formatting within a line, etc), so I've been thinking about an engine rewrite and a rework of the control on WPF for a while. I think WPF will be a much better match for the virtual system than WinForms was, so I should be able to do the work with significantly less code. I just have to balance this work with other project requirements (including the model-integration area Jim also mentioned in this thread).

So, yes, I would love to have a standalone version in the VS shell host, but I can't legally ship it without writing a replacement for a component that is integral to the NORMA tool.

-Matt

Ah yes... The Virtual Tree Grid control. Some of the TFS Version Control UI in VS2k8 used that control.  I used the control to modify an internal visual diff tool to support TFS. (no, not windiff... :) )

An WPF improved version would be pretty cool if you ever get around to it. Don't you hate it when you're "around to it" list is decades long? Ugh. :)

Bill