Keith posted a couple of screenshots of the Whidbey class designer a few weeks ago. Two things about this designer leapt out at me. First, it’s not a UML class designer (though it borrows heavily from UML’s graphical syntax). Second, it doesn’t provide much abstraction over the raw code. This lead me to think about the role of class modeling in the analysis and design process. How similar are the analysis and design models? UML doesn’t have an analysis model syntax, so typically the analysis phase uses the class diagram as well, but with less details. Are design models just analysis models with more details? Or is there a need / opportunity for higher-abstraction analysis modeling separate from (but transformable to) design models?

(Note, much of my thinking expressed in this post comes from a discussion with my father. If you read Pat’s blog, you know that Dad’s an architect for the FAA. Not that he agrees with me – actually, just the opposite. I also discussed this at length with an ex-teammate Tim Mallalieu. I’m hoping they’ll both respond in the comments since neither has their own blog…yet.)

I’m a big fan of Ivar Jacobson’s book Object Oriented Software Engineering – it’s one of the few on my office bookshelf. However, like many OO methodologies, dealing with the relational database is mostly left as an exercise for the user. In a 500+ page book, Jacobson dedicates a scant 15 pages on the topic of persisting objects in a relational database. Fowler acknowledges this in PoEAA when he points out that the database is often treated like the “crazy aunt who’s shut up in an attic and whom nobody wants to talk about” in OO design. However, in almost all enterprise development today, the database is a reality and a process that doesn’t formally deal with databases is fundamentally incomplete. That also means that the database needs to be included in the model.

From my experience, you typically start including the database in the model during the design phase. In the analysis phase, I want to work at a higher level of abstraction. Jacobson writes about Entity, Boundary and Control objects. Entity objects are used to model long-lived information – i.e. information that is stored in the database. Entities share a lot of similarities with classes – they have names, methods, and associated state – but are built at a higher level of abstraction. By ignoring implementation details (like database persistence strategy) you can focus better at the problem at hand. When you move from analysis to design, entities get mapped to both code design elements (classes, interfaces, enumerations, etc) and database design elements (tables, procs, views, etc).

This mapping from analysis to design is influenced by several decisions. Fowler details three domain logic patterns in PoEAA: Domain Model, Transaction Script and Table Module. Your pattern choice has profound implication on your design model. Only when you use the domain model pattern is there a one-to-one mapping between entity analysis objects and class design objects. If you use the other patterns, that one-to-one mapping doesn’t exist. Transaction scripts don’t keep any state across method invocations and table modules are built as collections rather than distinct objects. To me, this implies that analysis and design models are fundamentally different and differentiated by more than the level of detail.

Furthermore, the analysis to design mapping is influenced by the kind of data represented by your entities. The Information & Application Architecture talk from the Architecture Strategy Series discusses four types of data: Request/Response (i.e. messages), Activity-Oriented, Resource-Oriented and Reference. Each has different usage and representation semantics. Reference and message data is read-only and almost always represented in XML. Reference data is also version-stamped. Activity and resource oriented data are private to the service and almost always stored in relational tables. However, resource-oriented data is usually highly concurrent while activity-oriented data is not. These differences in data semantics implies different design models for my entities. For example, O/R mapping works great for read-only and low concurrent data but not well for highly concurrent data. Again, the lack of one-to-one mapping implies a true difference between analysis and design models.

Personally, I’d like an analysis-domain-specific language to build my entities in (as well as my controls and boundaries). I’d also like to indicate what type of data each entity represents. When I map that model into the design model, I’d like to choose my domain logic strategy. The output of this mapping process would be both a class design model and a database design model based on the analysis model, the kinds of data in the analysis model as the persistence strategy chosen. In a perfect world, the design would be generated from the analysis model auto-magically.  However, since I believe in Platt’s Second Law, I’m not sure generating the design model is particularly feasible. I guess when I get my hands on the Whidbey modeling engine, I’ll get a chance to find out.

I’m way behind on blog reading as well as writing, so maybe other have covered these, but I feel compelled to mention them anyway.

Microsoft XNA is an odd name (we sure have a fascination with the letter ‘X’) for a very interesting looking game development platform. You can check out the videos to see some idea of the capabilities, but trust me they’re pretty impressive (of course, they are pre-rendered – I wanna see them render in real-time on my machine). In addition to the graphics capabilities, they’re bringing Xbox Live to Windows. And the FAQ implies that the XNA will be part of the DirectX SDK & Xbox XDK, meaning that there won’t be any additional cost for it. I wonder how this toolkit will impact the non-industry programmer. i.e. can I use it to make 3D games?

I’ve blogged before about my interest in machinima – which is frankly why I’m interested in XNA. Now, Lionhead studios and Activision is coming out with The Movies, a simulation game where you get to manage a movie studio. What’s cool is that you can actually make little movies (according to the FAQ, average length is between 30 seconds and three minutes, but you can make full-length movies if you have the patience) Horror movies and westerns have screenshots, but you can make sci-fi, action, comedy, romance, thriller and romance movies as well. I don’t get much game time these days (I’ve gone back to work my way thru the original Splinter Cell before buying Pandora Tomorrow) but I know this is one I’ll get as soon as it comes out.

Yesterday, Pat did at keynote at VSLive San Fransicso. He talked about Metropolis (of course). Good to see architectural content making it’s way into mainstream developer events. It even got picked up by InfoWorld. I’m not sure how architect == “Microsoft exec”, but it’s great coverage none the less.

Pat will be speaking at TechEd in May. In addition to his Metropolis overview, he has two session drilling further into the parallels between applications and buildings as well as between manufactured goods and structured data.

You can see a slightly older version of Pat’s Metropolis overview on Architecture Center. Downloadable versions are coming soon.

It sure has been quiet around here. I spent last week on the road in Washington DC and Orlando at the federal and eastern region architect forums. Since my parents live in DC, Julie and Patrick came too. Nine days on the road with the family is hard, but it was worth it. Lots of fun, including Patrick’s first hockey game (even though the officiating was awful).

I spent a lot of time with customers talking about SOA and architecture frameworks. The frameworks talks were most interesting given Microsoft’s view on modeling languages in general, Whidbey’s design tools and our work on domain-specific models for distributed applications. To me, the most interesting thing is not the modeling tools shipping in the box with Whidbey, rather the modeling infrastructure. Accepting the idea of domain specific modeling means accepting that there are a vast number of different modeling languages – more than Microsoft could ever create on our own. In his solution architecture strategy series presentation, Keith Short talked about the need for a designer infrastructure and tool extensibility. He also confirmed that the Whidbey modeling tools are themselves built on a general modeling engine and framework. This modeling infrastructure enables the definition of new meta-models, extensions to existing meta-models and transforms between meta-models. It also has a synchronization engine for keeping artifacts at different levels of abstraction in sync (e.g. updating the model updates the code and visa versa). I’m not sure how much of this infrastructure will surface publicly in Whidbey, but Keith specifically said the modeling engine is a “piece of work that, over time, we hope to be able to offer both to our partners and customers so that you can build [modeling] tools yourself.”

This idea of building domain-specific modeling languages and tools feels pretty powerful to me. Besides the ones included in Whidbey (and the the previously discussed service-oriented language) what other languages would you like to see / use / design?

My parents (avid Caps fans and season ticket holders – at least for now) pointed me to the “Owner’s Corner” on the official Washington Capitals homepage where the owner attempts to explain without “spin” the moves that he has taken over the past month. It may not be obvious from my original post on the subject, but I agree with most of his deals. Jagr wasn’t worth the money, Lang and Nylander were recent free agents and I hear Gonchar wanted to leave. Most of all, they just weren’t getting it done. I agree with Ted when he writes that he’s “not committed to … a $50-million payroll for a team that is last in its division.” Especially when the division in question is the worst in the league. Tampa Bay might be good, but the reason are in the race for the President’s Trophy is because they get to play the other four teams in this wretched division the most. (Of the six teams under .500 in the Eastern Conference, four are from the Southwest Conference. That’s every team except Tampa Bay)

However, he glosses over so many ugly details but I can’t help but see spin.

• He refers to Kolzig, Halpern, Witt and Zubrus as “a strong core of veteran leaders”. However, Kolzig and Halpern sat out the last game before the trading deadline – a pretty sure sign they were being shopped around as trade bait. Zubrus has been injured off-and-on. So they are more like “a strong core of veteran players we couldn’t trade”.
• He explains that Konowalchuk was traded since he would have been an unrestricted free agent at the end of the year. That’s a great reason to trade a player – even the captain. I can see trading the captain as part of a fire sale at the end of a losing season. However, that’s not what happened to Kono – he was traded back in October when the season wasn’t even a month old. He wasn’t traded because he was going to be a free agent. I’m not sure why he was traded, but the rumor mill is that he and then-coach Cassidy didn’t get along. Which brings me to…
• How come there’s no mention of the utter failure the Bruce Cassidy head coaching experiment was? Cassidy lasted all of a year and a half – getting fired in December of this year. Word is the players didn’t like him (see bullet above). Leonsis has thrown his support behind now-head-coach Hanlon, but he did that before firing Ron Wilson a few years ago (Ron’s now leading the San Jose Sharks to the Pacific Division championship). In the end, all of this talent wasting comes down to be the coach’s fault – and the hiring of that coach is the GM and owner’s fault.
• Finally, he totally glosses over any explanation of the Bondra trade. For all the other traded players, he detailed the hot young prospects or high draft picks we got in return. For Bondra, he writes of “ensuring” Bondra was “comfortable” on a team with “a legitimate opportunity to win the Cup this year”. The truth is that Bondra was “comfortable” where he was and had no interest in leaving, even for a “legitimate opportunity to win the Cup this year”. Also, while Leonsis is technically correct when he writes that Bondra was in the last year of his contract, the fact is that Bondra’s contract had a team option for another year. Given that his contract wasn’t really ending and that Leonsis acknowledged that they didn’t save a significant amount by trading him (the Caps had paid 70% of his salary already), why would you trade “Mr. Capital”?
• Even if he couldn’t produce (which he could – he still leads the team in power play goals), Bondra was the perfect mentor for Alexander Semin. Semin is a gifted 19 year old Russian who the Caps picked up in last year’s draft. He’s a little undersized for the NHL at this point, but he sure can skate and shoot. He had a gorgeous rebound goal against Atlanta the other night. The announcer even said something to the effect of “I’ve called his name so much that I thought he’d had 10-15 minutes of ice time so far. Turns out he’s only had seven”. Semin’s story is very similar to Bondra’s, who came over from Slovakia as a 19 year old. Who better to learn about America and the NHL from than a five-time all-star who started out exactly like you did?

Sorry Ted, we can all see you spin. The most depressing part of the Owner’s Corner for me is that you are still the owner and that doesn’t look like it’s changing anytime soon.