Model-driven development is often used to indicate a development process that revolves around building applications by using models of applications and data as specifications. Using a model-driven approach means a development process and platform that enables:

• Using abstraction to view structure at the important level of detail and hiding complexity until it is needed.
• Using models – or logical data types and relationships – as the core to the development experience.
• Implementing the model-aware components such that they follow the requirements of the modeled application or business process.
• Associating models and model instances at various development stages so that model-driven development can move back and forth in the development lifecycle and maintain those relationships.
• Automation of particular application environments and artifacts so that users can more easily make use of them in the preceding ways.

The preceding points describe a development approach in which the real feature is more robust support of efficient and manageable complex application development. It is this feature that the “Oslo” modeling platform aims at: The goal of code name “Oslo” is to reduce the gap between the intention of the developer and the software components that get developed, deployed, and executed inside of the complex, widely-distributed, database-driven applications. Modeling the application means moving more of the definition of an application into the world of data, where the platform (and you) can more easily make queries as to the developer’s original intent. Microsoft technologies have been moving in this direction for over a decade now; for example, things like COM type libraries, .NET metadata attributes, and XAML have all moved increasingly toward “writing things down” directly as data and away from encoding them into a lower-level form, such as x86 or .NET intermediate language (IL) instructions. The “Oslo” modeling platform continues this progression. In short, the “Oslo” modeling platform:

• Makes it easier for people to write things down in ways that make sense for the problem domain they are working in – a common term for this is modeling.
• Makes the things that people wrote down accessible to platform components during program execution.

The “Oslo” modeling platform makes this possible by providing:

• A visual design tool (Microsoft code name “Quadrant”) that enables people to:
  • Design business processes with well-understood, flowchart-like graphics.
  • Design applications and components that comply with the requirements of those processes
  • Flip from one view back and forth to observe the effect any changes either place have on the overall validity of the application or business process.
• A modeling language (Microsoft code name “M”) that makes it natural to extend system-provided models (such as Windows Communication Foundation (WCF) or Windows Workflow Foundation (WF) models) or create your own models for use on the “Oslo” modeling platform.

  “M”:

  The Microsoft code name “M” language is a declarative language for working with data and building domain models. “M” lets users write down how they want to structure and query their data using a textual syntax that is convenient to both author and reader. “M” does not mandate how data is stored or accessed, nor does it mandate a specific implementation technology. Rather, “M” is designed to allow users to write down what they want from their data without having to specify how those requirements are met by a specific technology or platform.

• A SQL Server database (the code name “Oslo” repository) that stores models as SQL Server schema objects and model instance data as rows in the tables that implement the schema. This data is available to “Quadrant” and any other tool or data-driven application that can make use of it (and that has the appropriate permissions to do so). Whether models or model instance data is created visually, using “M”, or using any SQL data access API (for example, ADO.NET, EDM, OLE-DB, and so on) creating models and storing them in the “Oslo” repository enables future applications to examine and manipulate not only data structures used by applications but – because applications are modeled – the applications themselves, as they run. If a data-driven application has enough detailed model information, applications can run without recourse to static compilation.

  “Oslo” Repository:

  The code name “Oslo” repository provides a robust, enterprise-hardened storage location for the data models. It takes advantage of the best features of SQL Server 2008 to deliver on critical areas such as scalability, security, and performance.

Whether you create or modify model data visually, textually, or using a SQL data access technology, all of the modeling information is available in a relational database (the code name “Oslo” repository) at runtime. Some platform components are part of the System-Provided Models, which enable you to write a service or an application by populating that database with the definition of that service or application. In addition, because that data is captured in the “Oslo” repository, it is available to all kinds of tools that specialize in structured data, whether these tools are design tools like “Quadrant” or third-party tools that can sift, search, and filter the information to make available information that is very difficult to understand using current tools.

This CTP has been refreshed on the 27th February. It changes three DLLs to resolve crashing problems with three-pane modes in Intellipad.