Building Microsoft Oslo Models

Models and Modeling were on display everywhere at the latest Microsoft Professional Developer's conference. In fact, my guess is that the modeling lifestyle is here to stay. Before you embark on your own modeling career, an Oslo modeling primer might be helpful.

In my prior article, I explained how models are stored in the Repository, but glazed over many of the modeling details. In this article, I'm going use tools from the Oslo CTP SDK to explore model building.

Before exploring modeling, I want to explain why building models are important.

As you may have observed, half of the value in modeling is that it creates a new level of abstraction. Higher levels of abstraction mean less code does more. Using the HTML example, HTML user interface functionality requires less code than equivalent functionality implemented in assembly language.

Moreover, in model-driven development, the application consists of data and a runtime, and that's it. Essentially, the model is the application. Assuming the runtime has all the building blocks, there are no assemblies to compile. The application becomes a pile of data. Changing the data changes the application. So, applications can be more dynamic and tools to generate the code can have greater variability. Typically, a small amount of performance is sacrificed for flexibility. In the HTML example, the user interface changes when the HTML changes and there is a tremendous variety of HTML development tools for various development roles, skill levels, and purposes.

Finally, runtimes in model driven development do more than interpret generated code. A runtime also handles scaling, automatically adjusting without additional programming.

The value of models and model driven development is clear. Now, I'm going to talk about how Oslo fits into the picture.

Oslo Overview

Oslo is a platform for managing and developing models. Oslo is composed of the following components displayed in Figure 1.

Oslo's goal is to deliver a foundation for building and storing models of all types. Separate Microsoft initiatives aim to build runtimes and tooling into applications such as Visual Studio that are Oslo model aware. Then, by using a common modeling technique and format across all roles in the development process, information gathered by Analysts can, for example, be linked to parts of the application constructed by the developer.

Putting all these ideas and the Olso SDK to work, I'm going to show you what Olso model construction currently looks like.

Model Example

My model example doesn't just illustrate modeling, It's also intended to give you an idea of how different roles can leverage different models and then how the models can be linked.

Most of my software projects are staffed by people in the following roles:

Analyst or business person who defines requirements and more or less owns the application

Developer who builds the application based on the requirements

Operation or IT Professional who deploys the application and maintains the servers the application runs on

As I mentioned before, one of the goals of Oslo is to link these roles in a more streamlined way using a common Repository and modeling language to describe parts of an application. My sample model contains multiple Types each with an Extent. Each Type is targeted to capture information for one of the Roles I described above.

Requirement Type is for Analyst requirement data

ApplicationInstrumentation and ApplicationUI Type are for developer application storage

ServerConfiguration Type stores deployment information for the IT Professional.

In Oslo, Extents get translated into SQL Server Tables and Views. Building Models in M feels a lot like building Relational database tables. In fact, Relational database tables are what get loaded when the model is added to the Repository.

Before you examine each of the Types I described above, I'm going to start with basic conventions shared by all of the Types.