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.

Value in Modeling

First, model-driven development is not new. If you’ve done HTML development, you’ve done model-driven development.

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.

Source: “Microsoft PDC 2008—A Lap Around Olso”

Figure 1: Oslo Architecture

  • “M”, a language for composing models
  • The Repository a SQL Server database designed for storing models
  • Quadrant, a tool for editing and viewing model data

Currently, Quadrant is only available to PDC attendees. M and the Repository come with the Oslo SDK available on the Oslo Developer Center site http://msdn.microsoft.com/en-us/oslo/default.aspx.

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.

Model Conventions

There are some conventions in the Oslo SDK documentation and in the sample models. As with relational database table development, Types usually have an identity primary key. For security and versioning, models are stored in Folders. Rather than adding common fields to each Type, the sample models extend a common Type. All models in the Sample.Model Module extend the Item Type. The Item Type is below.

type Item
{
   // Surrogate primary key.
   Id : Integer64 = AutoNumber();

   // The folder that contains this stuff.
   Folder : Integer32 = 500;

} where identity Id;

Also, all Types in Sample.Model are part of an Application. So, all Extents have a foreign key constraint with the MyApplications Extent. MyApplications is based on the MyApplication Type. The MyApplication Type appears below.

type MyApplication : Item
{
   ApplicationName : Text;
}

Now, look at each Type by the Role it supports.

The Analyst Role

The Requirement Type appears below.

type Requirement : Item
{
   Description : Text?;
   ApplicationId : Integer64;
}

As I said earlier, Analysts collect requirements. Requirement Type is simple; it’s just some text describing the requirement and the Application related to the requirement. As I’ll explain shortly, requirements are linked to other models.

The Developer Role

ApplicationUI stores the markup for the application. As I stated earlier, a Runtime is needed to leverage the model. I envisioned a Runtime reading and executing the UImarkup. ApplicationUI appears below.

type ApplicationUI : Item
{
   RelatedRequirement : Integer64;
   UIMarkup : Text;
}

Normally, an application has a lot more moving parts than just the markup. Perusing the models shipping with the Oslo SDK reveals that models can be quite detailed. For example, if you’ve ever worked with Windows Workflow, the System.Workflow Module appears to be capable of storing a complete Workflow.

The Operations role is next.

More by Author

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Must Read