As he wrote on his blog, Pat Helland’s last day at Microsoft is tomorrow. He’s busily cleaning out his office right now. 😦 He’s starts on Monday @ Amazon to help them implement a service oriented architecture. I heard their CTO was hiring.  Pat’s a big reason why I came to work for Architecture Strategy so I’m really sorry to see him go.

On the plus side, no one will quip “it’s been nice hanging out with you” in the men’s room anymore.

Seriously, Pat’s been through some seriously hard times this past twelve months, and I think the change is a great opportunity for him. I imagine I’ll see him often enough – he’s back on campus next week to present at an architecture forum. Plus, I offered to setup dasBlog on pathelland.com so he’ll keep blogging.

Ron from patterns & practices is not only blogging and webcasting but also podcasting. He’s got two podcasts up so far. The first is a discussion with Billy Hollis about smart client architectures. It’s pretty short – just enough to whet your appetite. (Quick plug – Billy is presenting with Rocky on Smart Client Architecture as part of the TechEd 2005 ARC track.) Ron’s second podcast is with Scott Densmore on EntLib’s ConfigurationContext. It’s cool stuff, but it’s alot harder to follow (for me anyway) topics related to code like this with just audio. Luckily, Scott blogged about this as well.

Javier got me thinking when he left a comment to my square peg model post. I’ll get to intended semantics of class diagrams in another post, but I wanted respond to the latter part of the following comment:

I suppose you are assuming that the Class Diagram is intended to be used for design purposes. Then, a class diagram could be considered simply as a code visualizer.

That’s a great point that ties into something I’ve been thinking about lately: the Class Designer in VS2005 is not a modeling tool, it’s a visualization tool. For me, the difference comes down to abstraction and transformation. In VS2005, the Class Designer is built on top of the same metamodel as the underlying language. This means there is no transformation and that the diagram and the text of the code itself are at exactly the same level of abstraction. To me, you’re not modeling unless you’ve raised the level of abstraction.

However, while I think VS2005′s class diagram is a visualization, I also believe that UML’s class diagram is a model. UML is not built on the same metamodel as the underlying language. It’s at a slightly higher level of abstraction. That’s why you can generate Java, C++, Ruby or C# from a given class model. That transformation step between diagram and code is what makes UML a model. Granted, the class model of UML is intentionally close in abstraction to the code, but it’s still an abstraction.

The only reason it matters IMO if a given diagram is a model or a visualization is to be explicit about the need for transformation. And even the need or lack of transformation is only important for usage purposes. Each method has its pros and cons. UML can’t model C# code as precisely as VS2005 can visualize it, but VS2005 can’t be used to generate code for non .NET languages.

Javier’s point cuts right to the idea that modeling classes “for design purposes” isn’t particularly valuable as classes are such a low level abstraction. I think that’s why so many people use UML’s class model as a general purpose “thing” designer. The question is, what was the class diagrams intended use?

As I pointed out in my last post, VS2005 includes a Class Designer that those familiar with the UML class model should feel right at home in. By happy coincidence, I found out today the Class Designer team is blogging. Additionally, two of the Class Designer team members – Ramesh and Rakesh - are blogging on their own. Apparently, the team blog will feature a new post every Thursday. This week’s post features an overview of the v1 Class Designer goals. Subscribed.

Robert Bauman left the following comment on my Separated at Birth post?

The nice thing about using a general purpose modeler is that you can house all of your requirements, use cases, etc. in the same model. Rational provides the 4+1 view, Sparx Systems Enterprise Architect provides several views out of the box that you can easily navigate around… It means that everyone is working off of the same set of rules.

As soon as you start putting those rules into Visual Studio, they change and deviate from the model. It’s true that the AndroMDA does require you to remember to use certain stereotypes, but that’s all part of the game anyhow.

That’s like saying, “well, the GoF patterns are nice, but then you have to remember what it means to have an Observer pattern”. Furthermore, UML tools let you customize the list of stereotypes that show in the dropdown, and even the picture that should be associated with those stereotypes. Why mess with some other modeling standard when you can do it all with a proper UML tool

The point I was making is that when you start using the class model to design something other than classes, you’re using a domain specific language – even if you’re using a general purpose modeling tool.  Take a look at this example from the AndroMDA website. Their example reads:

You tag a CustomerService class with a <<Service>> stereotype. AndroMDA sees this stereotype, looks into its internal dictionary of available code generation components (called “cartridges”) and finds the EJB cartridge. In the EJB cartridge, two templates correspond to the <<Service>> stereotype: SessionBean.vsl and SessionBeanImpl.vsl. AndroMDA uses the internal representation of CustomerService loaded from the model, calls the processing engine twice, and two output files are generated: CustomerServiceBean.java and CustomerServiceBeanImpl.java.

In this example, classes with the <<Service>> stereotype actually generate two code classes – the Bean and the BeanImpl. But if we were using the class diagram as it was intended, wouldn’t there be a one-to-one mapping between a class in the model and a class in the code? As soon as you break that one-to-one mapping, you’re no longer modeling classes. A <<Service>> is something at a higher level of abstraction than a class – otherwise it wouldn’t take two classes to implement it.

BTW, I’m not saying that there is anything wrong with this approach at all! I’m just pointing out the similarities between an approach that many people are using to achieve practical results with UML today and what you can do with the modeling tools that Microsoft is building.

The key difference comes down to tools. Yes, you can use the class diagram and stereotypes to model stuff at a higher level of abstraction like Services and Entities. But putting a square peg in a round hole like that has problems. Since you’re not using the tools as they were designed, you have to manually enforce rules that the tool doesn’t know about. Sure, you can add some semantics via stereotypes, but you can’t take anything away. How easy is it to build a valid class model that isn’t a valid service model? Pretty easy. For example, do services support inheritance? Classes do. My EJB is a little rusty, but I don’t think beans do. It certainly doesn’t make sense for a service to inherit from an entity or vis-versa. Yet, the class modeler will happily let you do this, even though it makes no sense in the domain you’re actually trying to model.

The value of domain specific languages is that have a tool that is specifically designed to model the domain you’re working in. If you’re designing classes, of course you’d want to use a class model. We have a great one coming in VS2005. But if you’re designing services or entities or page flows or whatever else, why wouldn’t you want a tool that’s specific to the problem at hand?