Tonight I went to the monthly meeting of the local chapter of IASA. I should have also blogged this before the meeting, but I forgot. Sorry about that if you live near the Microsoft campus and wanted to go. Next meeting is on 3/30, so mark your calendars.

Anyway, tonight’s topic was an MDA workshop featuring AndroMDA. AndroMDA is an open source tool for generating primarily J2EE code for *nix boxes using UML and MDA. (To be fair, the speaker – local chapter president Chris Sterling – demonstrated generating C# code as well. Of course, he ran it under Mono on a Linux box.) This provided a great launching point for a general modeling discussion that helped me get a few things straight in my head. Typically, the UML vs. DSL discussion turns religious pretty quickly. However, I believe that people – like those a the meeting tonight – who are achieving practical success with MDA in the real world are doing so by using a Software Factories style approach.

First off, if you look at how most people use UML for MDA, the class diagram appears to be the most dominant model used. When I say “UML for MDA”, what I mean is people using UML as a blueprint or as a programming language. While UML has 12 different model types, class diagrams make up the bulk of the modeling effort. (The bulk of AndroMDA code generation works off the UML class diagram, though the BPM4Struts cartridge uses Use Case & State models as well) The other 11 diagrams are primarily used for sketching purposes. That means you’re only blueprinting the structural aspect of your system – which in turn means that all the system’s behavior has to be implemented by hand. Now, this is not to say that factories suggests you should only model the structural aspect of your system. However, I think this indicates that most pragmatic users have realized MDA doesn’t live up to the hype.

Secondly, the class diagram that are used have to be heavily adorned with custom metadata – typically in the form of stereotypes – in order to be useful for code generation (i.e. blueprint) purposes. AndroMDA has a set of “cartridges” (essentially, target code generators) such as EJB, Hibernate and POJOs. Each of these cartridges has a supported set of stereotypes. While there is some overlap (for example, EJB and Hibernate cartridges both define the Entity stereotype). These stereotypes assign brand new semantics to the elements being modeled. In short, they turn the the generic class modeler into a domain specific modeler!

It appears to me that the pragmatic MDA crowd is using the class diagram as a generic “ball and stick” editor. Model elements that aren’t needed are ignored and elements that are needed are added via stereotypes. For example, you can use a class diagram to model a database. Certain elements of the model are ignored (Can a column have protected visibility? Can one table inherit from another?) while other elements specific to the domain being modeled are added (primary and foreign keys, indexes, etc). The problem with this approach is that all of the knowledge of how to build a valid model is in the user’s head, rather than the tool. Typically, that means a lot of training as well as a lot of in depth understanding of the framework underlying the model in order to capture the right amount of information. Since all that domain specific information is trapped in the users head, they have to do a ton of menial drudge work. It’s different drudge work from things like writing tons of data access code, but it’s drudgery nonetheless.

If you’re going to need a tool specifically designed for your problem domain, why use a generic tool and a bunch of handwritten rules, when you can codify those rules into a domain specific language of your own? (I mean, other than the obvious “because the DSL Toolkit hasn’t shipped yet”)

BTW, if you haven’t seen Steve’s entry on Isomorphism, go read it right now. He nails this whole services as contracts vs. services as code debate right on the head. The spot on nature of this post reminds me when he nailed the modeling problem on the head – another must read post if you haven’t already.

Last week, I had a great discussion with the Product Unit Manager (or PUM) of VSTA. She wanted my perspective on a few things related to Software Factories and I figured I’d share some of them here.

First off, while I appreciate the vision of factories, I’m also focused on the short term gains of automating software construction. Today, most of that automation is in terms of code generation. For example, John asked the other day if I thought Yacc is a software factory. It certainly is a domain specific language! However, I’m not sure I’d go so far as to say it’s a factory. But on the other hand, I’m not sure it matters that much if it’s a factory or not. When the other John on my team blogged his thoughts on SOA, he included one I wrote: “Eventually we’ll stop talking about SOA and go back to talking about Architecture”. I feel sort of the same way about factories. As long as we’re talking about it as if it is something different from what we’re already doing, we’re not there yet. But if we keep taking steps in the right direction, eventually we’ll get to the point where the process of building software doesn’t look the way it does today. Sorta the same way that building software today doesn’t look like it did pre-.NET, pre-VB, pre-Windows or pre-C++ (I could keep going, but I think you get the point). That’s the thing about visions, you never really get there, it just provides a way to keep you going in the right direction.

Secondly, I think that one aspect of Software Factories that at least I haven’t focused on is reusable frameworks. The book is called “Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools” but I think the focus has been mostly on models and tools. This is partially because of the whole DSL vs. UML flack (quick side note – how about we have both?) and partially because the DSL toolkit is the first factory-esque thing that we’re shipping. However, DSLs big value, IMO, is to automate the construction of applications built on top of well designed reusable frameworks. For example, the OOPSLA keynote demo was a DSL that would sit on top of a UI process framework such as the p&p UIP block. But if there is not a good framework, there’s little point in having a language. I’ve pointed out in the past that the big gap to cross for organizations to start using DSLs is the leap from building abstractions to building languages that automate that abstractions. However, that’s not really true. The really big gap is the leap from building one-off abstractions to building reusable frameworks of abstractions. Once you have the reusable framework, building the DSL is an easier step IMO.

Even though I didn’t figure out the framework / factory connection until last week, it must have been there in the back of my mind when I was working on the ARC track for TechEd. We’re having a session on “Design Considerations for Enterprise Application Frameworks” with Steve Maine as the speaker.

I think TechEd 2005 is shaping up to be awesome again this year. They just posted the list of sessions (well, most of the sessions anyway). I can’t link directly to the architecture sessions, but you can filter the list to show just one track at a time if you want to. We haven’t got speakers or abstracts posted yet, but I can tell you that we’ve got some good speakers lined up like Scott, Ted, Roger, Rocky, and Steve.

Of the ARC track sessions, I think I’m most looking forward to “Building and Using a Software Factory”. I jokingly call this session “Here’s the Beef, Chris Sells”. Chris blogged that he wanted a concrete example of a software factory. It turns out that we’ve been working on a concrete example since before OOPSLA. In the TechEd session, we’ll see how far Michael, Jack and Keith have gotten since October.

About fourteen months ago, David Trowbridge of patterns & practices introduced me to a guy working in their testing group named Larry Brader. David is one of the primary authors of p&p’s Enterprise Solution Patterns and Integration Patterns books. I wanted to talk to David about building a pattern repository and he handed me off to Larry. Little did I know that Larry is an information theorist and was one of the key authors of Testing Software Patterns. Frankly, when Larry gets rolling on info theory, I only understood a fraction of what he’s saying. But the parts I do understand about how patterns relate to each other blows my mind.

Then p&p hired this guy…what’s his name?…Oh yeah, Ward Cunningham. I hear he knows a bit about pattern repositories. 😄

Anyway, around this time last year I was having regular meetings with Larry and Ward to talk about this repository stuff. Then stuff got crazy on my end – primarily being the acting marketing director for my team as well as the ARC track owner for last years TechEd. The regular meetings became more irregular and then stopped altogether. That is to say, my involvement stopped – Ward, Larry et.al. kept forging ahead. I heard about how things were going from time to time, but that was the extent of my involvement.

Last summer, Larry, Ward and David (plus others I’ve never met) published an article called Describing the Enterprise Architectural Space. (They also did a webcast on the topic.) In it, they laid out a way of thinking about how patterns relate to each other and they introduced the Enterprise Architectural Space Organizing Table (EASOT for short). That was just the first step. PatternShare is next one.

PatternShare is a community site that brings together the patterns from popular authors – Fowler, Evans, Hohpe & Wolfe, GoF, POSA and p&p - into a single repository. Furthermore, it provides a dynamically generated EASOT showing all the patterns in the repository and how they relate to each other. Finally, it provides a way to add new patterns to the repository so that they show up in the EASOT.

Major congrats to Ward, Larry, David and the rest of the p&p folks for pulling this off. I can’t wait to see where the site goes from here.