Tuesday, June 08, 2004
« CSLA workshop at VS Live Orlando | Main | SOA, CSLA .NET and trust boundaries »
.NET Rocks! show spurs UML discussion

My recent .NET Rocks! interview was fun and covered a lot of ground. One technology that we discussed was the Whitehorse designers - the SOA designer and Class Designer - that are slated for Visual Studio 2005. In fact, Brian Randell and I co-authored an article on these designers that will come out in the July issue of MSDN Magazine.

Since the Class Designer is an extension of the UML static class diagram concept, the conversation looped briefly through a discussion of the value and history of UML. At least one blog discussion was spurred by this brief interlude.

I use UML on a regular basis, primarily in Visio. I use it as a design tool and for documentation. I don't use it for code-generation at all, because I have yet to find a UML tool that generates code I consider to be acceptable. I think UML is a decent high level modeling tool for software, and I strongly recommend that anyone doing object-oriented design or programming use UML to design and document their system. Having a decent OO diagram is totally comparable to having an ER diagram for your database. You shouldn't be caught without either one!

At the same time, I think UML has become rather dated. There are concepts in both Java and .NET that just can't be expressed in UML diagrams in a reasonable manner. For instance, component-level scoping (Friend in VB, internal in C#) just isn't there. Nor is the concept of a property as opposed to a field. Nor can you really express events or delegates.

If you are going to even try to do code-gen from a diagram, the diagram must include all the concepts of your platform/language. Otherwise you'll never be able to generate the kind of code that a programmer would actually write. In other words, you can use UML to provide abstract concept diagrams for .NET programs, but you can't use UML to express the details because UML simply doesn't have what it takes.

Recognizing this, Microsoft has created this new Class Designer tool for Visual Studio 2005. It is very comparable to a static class diagram. It uses the same symbology and notation as UML. However, it extends UML to include the concepts of field vs property, events, component-level scoping and more. In short, the Class Diagram tool allows us to create UML static class diagrams that can express all the details of a VB or C# program in .NET.

If you are familiar with UML static class diagrams and with .NET, learning the Class Designer notation will take you all of 10 seconds or less. Seriously - it is just UML with a handful of concepts we've all been wishing for over the past several years.

But the real benefit is the real-time code synchronization. The Class Designer is in your project and is directly generated from your code. It is not generated from meta-data, but instead is generated from your VB or C# (or J#) code directly. This means that changes to the diagram are changes to your code. Changes to your code are changes to the diagram. The two are totally linked, because the source for the diagram is the code.

This is not reverse-engineering like we have today with Visio or other tools, this is directly using the VB/C# code as the 'meta-data' for the diagram.

(To be fair, there is an XML file for the diagram as well. This file contains layout information about how you've positioned the graphical elements of the diagram, but it doesn't include anything about your types, methods, properties, fields, etc. - that all comes from the code.)

My only reservation about the Class Designer is that I've mostly moved beyond doing such simple code-gen. Since coming out with my CSLA .NET">VB.NET and C# Business Objects books, I've really started to appreciate the power of code generators that generate complete business classes, including basic validation logic, data access logic and more. Readers of my books have created CodeSmith templates for my CSLA .NET framework, Kathleen Dollard wrote an XSL-based generator in her code-gen book and Magenic has a really powerful one we use when building software for our clients.

While the Class Designer is nice for simple situations, for enterprise development the reality is that you'll want to code-gen a lot more than the basic class skeleton...

Tuesday, June 08, 2004 9:16:04 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [4]  | 

Wednesday, June 09, 2004 7:39:25 AM (Central Standard Time, UTC-06:00)
> In short, the Class Diagram tool allows us to create UML static
> class diagrams that can express all the details of a VB or C#
> program in .NET.

I am not sure expressing all the details of a VB.NET or C# program in a diagram is a good thing. The point of modeling is to provide a simplified view of the program, not to duplicate it.

Yet, I guess I'll need to wait and actually use the new feature to make a fair judgement.
HectorCorrea
Wednesday, June 09, 2004 9:30:10 AM (Central Standard Time, UTC-06:00)
And yet for a database we insist on having models that directly match the database schema. Why the double standard? If we design a real OO system, than our class model is at least as important as any underlying data model.

I agree that at _some_ level, we need an abstract, logical model that is simplified as compared to the physical design of the system. At the same time, we also need a _real_ physical model that is human comprehensible and that also directly matches our code.

DBAs typically have a higher level abstract data model and the physical model. The physical model either generates the data schema or is generated from the data schema. Likewise, in the OO space we need high level abstract models, but we also need (and haven't had) physical models that directly match the code.

Personally I always end up creating (at least) two class diagrams in Visio. A high level abstract one, and a detailed one.

At the high level I don't mess with collection classes (for instance), since you can represent a containment relationship between parent and child objects directly. In a physical model however, you need to represent that collection because it is a real code artifact required by implementation. The same with many fields and properties and methods. At a high level you only care about the business-focused stuff, but at a physical level you care about the little methods and properties and fields that connect everything together behind the scenes.

Rocky
Rockford Lhotka
Thursday, June 10, 2004 7:10:21 AM (Central Standard Time, UTC-06:00)
> And yet for a database we insist on having models
> that directly match the database schema. Why the
> double standard?
Who is "we"? :)


> If we design a real OO system, than our class
> model is at least as important as any underlying
> data model.
That's right. Yet, I usually see people looking and the actual database (not to an ERD) to find information about the database. People might create ERDs along the way (on paper or via tools) but that's usually because the _process of modeling_ helps them understand the database, the _model_ is pretty much disposable after that.

I've walked many times into rooms where people have beautiful posters of their database. Then, I have hardly ever seen anyone actually use them.

In any case, I see your point about at least having the capability to create models of code at any level of detail (logical/physical) that we may need. Whether we use that feature or not is up to the developer and the problem at hand. But having the feature available would be a good thing.
HectorCorrea
Thursday, June 24, 2004 2:08:48 PM (Central Standard Time, UTC-06:00)
>If you are going to even try to do code-gen from a diagram,
>the diagram must include all the concepts of your platform/language.
>Otherwise you'll never be able to generate the kind of code that a programmer would actually write.
>In other words, you can use UML to provide abstract concept diagrams for .NET programs,
>but you can't use UML to express the details because UML simply doesn't have what it takes.

I agree that for 'us programmers', using UML to develop with is like doing caligrophy with crayons.
However, in the UML world, code generation is steering towards Model Driven Architecture(MDA), also known as Executable UML.
The idea is that a 'high level' class-diagram/state-diagram/sequence-diagram representation of a system (called a PIM for platform independant model), represented in a standard XML format, is "translated" into a PSM, or Platform Specific Model. The translation software would be 'smart enough' to know, based on hints in the UML, and best practices for the resultant language, to know how to represent the model within a given language/environment.

So a C# PIM->PSM translator would contain the logic such as what visibility or representation attributes (property vs. attribute) should have. It might makes sense to generate a collection in .NET, but an array in Java.

The biggest weakness I've seen so far with MDA is it works great if you have all the components and just need to glue them together (Kind of like SoftWire), but actually defining method level code in a generic way is still in it's infancy. IBM has done some work in this area (think SQL like syntax), but there are others competing too.

There are several vendors with Java tools doing MDA now. There's still quite a dearth of them in the .NET world. Connector() ( http://www.constructor4.net ) is one.
Steven Dzilvelis
Comments are closed.