eyt*
August 10, 2004

Microsoft-based Modeling...

Patrick Meader has an interview with Keith Short, an architect for the Microsoft' Visual Studio Tools Group, concerning Microsoft's upcoming Modeling tools that I discussed here before. Model Apps More Effectively and Build Distributed Apps a New Way discuss some the tools, the reasons why Microsoft is adding modeling to the language, and why they are not using UML.

Keith Short states that many of the existing UML tools have failed because how the code is separate from the diagrams, and keeping them synchronized is not a simple task. The Microsoft approach is completely integrated, such that you can see your code or see a diagram that is based on your source, but this workflow is not required, and developers can continue to work as they do today.

Keith Short also states that the reason that they choose to use their own diagramming language is mainly because UML currently does not support notation for the SOA, and they viewed UML as not extensible, stating that they would have to support stereotypes and profiles. But also a large part of this is that they believe that UML presently has its own type system, and that you must map this type system to your implementation system. Microsoft plans to rectify this by making their modeling language tied to .NET's type system. But how is this different than our existing tools? I mean, tools are optimized for a particular language, and if you do not use that language, you will fall into this problem.

The notation to Microsoft's diagram language, however, is said to be intuitive to anyone who currently knows UML; I presume that piggy packs on how C# looks intuitive to anyone who knows C++ or Java. The UML tools themselves, Microsoft still insists, will come from the Modelers, who will build “on top of our framework,” supporting Keith's statement that their move is not anti-UML, but rather pro-modeling. Keith also mentions that UML supports a lot of diagrams that developers do not use, and while this is true, my question would be if there are any types of diagrams that are not used, and by this I mean that Collaboration Diagrams and Sequence Diagrams are very similar in nature, and picking between them can be more of a preference. As such, I can imagine that some developers never use Collaboration Diagrams, just like some developers never use Sequence Diagrams, not to fail to mention those that use neither or a mixture of them. The point being that this is flexibility, and not necessarily a problem.

I am not sure what Keith's means when he states that UML is “a standard that was not precisely specified.” As What UML is isn't states, UML is nothing more than a diagramming language, and as this, I believe it is well defined, but the process used with UML is not defined with the UML standard. Instead, processes are defined that use the UML notation, and these some of these processes are well defined, and others are not, but strict processes are difficult to implement, and this is where some flexibility can mold the process into an environment. Other than this interpretation, I am not sure what else he could have meant, as there are many UML-based tools on the market today that had no problem interpreting the standard (the only problem is that they have all implemented a portion of the standard, but that portion differs from product to product, similar to ISO Standard C++ support in compilers).

When asked the question about interoperability with J2EE, Keith Short's answer was rather vague, in the sense that he focused more on the interoperability question, and I would personally be quite surprised if Microsoft's tool could not model standard WSDL files, but what about modeling Java? I suppose the answer to this question is partially J#, a Java wanna-be for the .NET Framework. But even at this, how will its tool focus on the other languages in the standard Visual Studio package, not to fail to mention the other languages that now target CLR? I would imagine that they would use some reflection-based scheme to reverse engineer, but what about code generation? The interview focused primarily on C# and Visual Basic, but I would like to think that the other languages are also supported easily.

I think that Microsoft's solution is a partial step in the right direction to keep the code and diagrams together, but I am concerned on its modeling language, and some of the things that the tool can do sounds as if it will just be an extension of what we really already have today, but this will be hard to completely say until it is released though.


Posted 18 years, 1 month ago on August 10, 2004
The trackback url for this post is https://www.eyt.ca/blog/bblog/trackback.php/54/

Comments have now been turned off for this post. If you want to share something, please e-mail me.

Navigation

Recent Posts

eyt*