“Modeling” in Code

(Continued from Part 1) Now there are four very important facets of the code structure that have to do with modeling.

(1) First is the inherent disconnect in how these buttons are classified: there are four appearance classifications but only two behavioral classifications, the latter being implicit in the assignment of the Click event hander assignment, which is why I call it an “informal” classification. To tighten up these relationships, we should really have event handlers for each conceptual button type: digit, memory, operator, and function. At the same time, we don’t want to combine the visual and behavioral classifications: each button should have a visual classification that only affects appearance (for the purpose of visual design) and a behavior classification that only affects function (irrespective of a button’s color, for instance).

(2) Second, the OnWindowKeyDown event handler expresses all the keyboard mappings in code such that they cannot be changed unless program is recompiled. To support a class of applications in a runtime, this has to be converted to a data-driven implementation that can accommodate arbitrary mappings.

(3) Third, the two sets of variables clearly separate those that are external—that is, those that have meaning to a user of a calculator—and those that are strictly internal implementation details. I did this intentionally when rewriting the code because the conceptual behavior of any button can be expressed in terms of these few external variables (Accumulator, Stack, Op, Mem, and AllowRepeatEquals). The internal/state variables, on the other hand, are necessary to create the behavior of specific kinds of buttons, such as digits, operators, or =.

I reworking this code, it took considerable tweaking to get a few behaviors working correctly, such as the repeat = key, overwriting the display value at the appropriate times, and suppressing an operation when an operator key was pressed. The problem was that the original code sample overloads the semantics of its EraseDisplay variable with all of these behavioral implications. It’s used not only in the same capacity as our new OverwriteAccumulator, which has a similar meaning obviously, but is also used to decide whether to suppress computation when an operator key is pressed. It’s also used to ignore a repeated = keypress. As a result, it really complicated my effort to clone the repeat = behavior of the Windows Vista Calculator.

More...

As Microsoft's program manager in charge of the "Oslo" Developer Center on MSDN (since merged with the Data Developer Center http://msdn.microsoft.com/data), you'd naturally have every reason to expect that I wholly "get" what all this "Oslo" stuff is about. After all, I acquire, publish, and manage the DevCenter content that's intended to tell the "Oslo" story. [It's now called SQL Server Modeling, by the way, as we've retired the "Oslo" name.]

I must confess that this is actually not the case, at least not yet. Frankly, I still ask myself—quite often, in fact—just what's it's all for and what, in fact, someone really does with it--with the whole of it. Like many people, I can see how certain pieces like the "M" toolchain are useful in and of themselves (writing nifty languages and such), but when you start talking CLR and UML domains or "middle-tier" applications, I'll listen politely while trying to pretend my eyes aren't going glassy.

To my credit, this state of affairs is actually by design, which gives me a perfect opportunity to bore you with the backstory of how, after a hiatus of around 12 years, I found myself back at Microsoft and eventually working on "Oslo." People are going to ask about this anyway, so…well, OK, originally I wrote that whole section right here, conveniently forcing you to indulge my penchant for storytelling. But charity won out in the end and I moved it into its own piece.

So like I was saying, this present state of affairs is intentional. Since the beginning of February, when I officially began this role and could at least differentiate between Microsoft code name "Oslo" and a city in Norway, much of my time has been consumed in just getting my bearings on the project while keeping the DevCenter reasonably fresh. Combined with the demands of the "Oslo" May CTP and my wife's recovery from abdominal surgery, it was only in late summer that I was able to delve into a serious learning project of my own.

My hope is that this effort will lift me out of the slums of ignorance, so to speak, and in the process lay a path for other developers (and mind you, this particular post is just a start, not the complete story). For as much as being embedded in a team that eats middle-tier for breakfast (and effortlessly speaks of app servers, repositories, and domain-specific languages with every breath) makes me at times feel quite alone, it's certain that I'm not. Many developers are surely wanting to slake their thirst for understanding, even while they skillfully feign competence. (But that's OK. We're friends and I promise I won't rat on you.)

More...

A Short Introductory Guide to the Microsoft code name “M” Modeling Language (Part 2 of 2) [Complete article available in Word Format (196K) for nice printing]

Compiling "M"

Of course, having a bunch of "M" code sitting around is well and good, but to make all those types, extents, and functions useful they must be turned into actual database constructs.

This basically means compiling the "M" code and generating output that can be used to populate a database. For this there are two options:

• Compile "M" from the command-line using the m.exe tool (generally found within Program Files\Microsoft Oslo\1.0\bin)
• Compile "M" from within Visual Studio using the "MCompile" element in a project file. (This option is installed automatically with the "Oslo" SDK. This option instructs MSBuild.exe to invoke m.exe automatically.

Note: it is also possible to dynamically parse and compile "M" programmatically, but that's beyond the scope of this article.

The "M" compiler, as shown in the diagram below, simply parses the "M" and generates some kind of output that can be used to create a database. Typically this is an "M" image (or MX) file that can then be fed to the image loading utility, mx.exe, for deployment into a database. (At which point it becomes accessible to applications or runtimes that make use of that database. Note that "Repository" is shown in this diagram but can be any SQL Server 2008 database.)

Alternately, you can use the "M" compiler to generate SQL statements that can then be deployed using the sqlcmd.exe command-line tool. Let’s look at these different compilation methods in turn. We’ll come back to the matter of installation/deployment later.

More...