Scott Swigart recently sat down with Richard Hundhausen to talk about how Visual Studio 2005 Team System is being used in the real world. As a principal of Accentient (www.accentient.com), Richard has provided extensive consulting and training to companies seeking to implement Team System. Richard is also one of the few Microsoft Team System MVPs, and author of Working with Microsoft Visual Studio 2005 Team System (Microsoft Press, 2005).
DDJ: Richard, I'd like to start off by talking about some of the modeling features in Visual Studio 2005 Team System, and how you're seeing those being put into practice. Then I'd like to expand the conversation to talk about Team System at a higher level, and what features across the Team Suite software shops are latching on to, or panning. To get started, clarify a term for me: When I hear people talk about "domain-specific languages," what does that mean?
RH: Let me contrast that question with UML, the Unified Modeling Language. The industry loves it, and it's been around for a long time, but it's very generic at describing software interaction and flow. It's not specific to .NET. Some people would argue that it's getting more specific to Java, but I digress. "Domain specific" means that you pick a domain, and for you and [me] we're talking about .NET, and then you come up with a language that precisely describes that domain. It's still a modeling language, you're still dragging and dropping shapes and connecting them, and you can print it out and hang it on the wall, and feel all proud about it. But at the end of the day, it has domain-specific functionality—meaning it can generate .NET code. Or, it can generate SQL Server DDL script, or something like that.
DDJ: In other words, it might know about attributes, which are a .NET Framework-specific thing.
RH: Right, or something like "delegates" [www.sellsbrothers.com/writing/default.aspx?content=delegates.htm]. That's exactly it. UML's great, but have you ever used it to precisely define something that should be implemented in code as a delegate?
DDJ: So doing round-tripping, where you go from your diagram, to your code, and back to your diagram, that's much easier with domain-specific languages?
RH: Exactly. There's a DSL toolkit that lets you build your own domain-specific language. The example I use is, "Let's say you're Subway Sandwiches. You have Visual Studio, which is just a shell. Inside of Visual Studio you could create a DSL that would let you drag-and-drop meat, cheese, and so on, from the toolbox onto a sort of virtual sandwich designer. When you're done, you right-click and say, 'Go,' or, 'Run,' or whatever. It cranks out calories, a receipt, assembly instructions, and the like."
DDJ: Things like cost of goods.
RH: Right, inventory, anything. It's a language for designing deli sandwiches. That's what DSL stands for—"Deli Sandwich Language."
DDJ: (laughs) Obviously, when they built Visual Studio Team System, they built it for the express purpose of building .NET applications. Are the tools generic enough that anyone would actually use it for making a "Deli Sandwich Language?"
RH: Think of it this way: Visual Studio Team System is a domain-specific language for doing precise .NET development. By Team System, I'm talking about the "Visual Studio 2005 Team Edition for Software Architects." It's those codename Whitehorse modelers we've been playing with for a while now. Those are DSLs for doing precise .NET development, precise datacenter development, precise deployment diagrams, and the like. DSLs also have the ability to validate against rules. The other side of this is the whole SDM, or System Definition Models [msdn2.microsoft.com/en-us/library/ms181772.aspx]. When you're building these models, they're actually saved in an intelligent format, with an XSD describing what is and what isn't allowed in the files. You can take it to the next level and actually validate SDMs against other SDMs.
