Model-Driven Development in "Oslo"

[This is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders.]

The “Oslo” models address each major stage in the development of a solution. “Oslo” enables a project team to proceed efficiently from the initial concept of a solution to its implementation. Models make communication between the different roles on a project team as effective as possible. Models are designed to maintain solution data in a structured, accessible, and recoverable state, which makes solutions transparent and enables declarative, data-driven development.

The Basics of Model-Driven Development

Model-driven development is an effective problem-solving technique because you can first characterize a solution in its most basic form, and then build in the complexity. This is true even if the solution requires a complex system composed of parts that are themselves complex. When you use a model, you can always keep the full context of a problem or process in mind as you create the solution by scaling up or down the resolution on your view of the models.

In the most general sense, a model is a representation or a simulation of some real-world entity. You can model a physical entity, such as a building, a vehicle, a computer system, or a virtual entity, such as a problem space or a business process. This is why the “Oslo” modeling technologies can be used with many different runtimes. In each case, using a model in the planning process enables you to envision the entity before you take action on it. You can visualize a physical entity before you actually build it. You can define a problem before you attempt to solve it. You can conceptualize a business process before you implement it.

Every “Oslo” model functions at least as a basic model that you can use as an aid in high-level design. Some do much more, but all serve that fundamental role. An “Oslo” model enables you to formulate the system from its highest level parts, without having to worry about how each part implements its functionality. As a result, you can abstract a solution from its implementation details. A model enables you to see a business process or workflow in its entirety, defining how the parts of the process or workflow work together. You can define how a workflow activity functions with other activities, and the roles that each have in the overall workflow, without dealing with details about the code behind each activity. This can greatly simplify the process of project development.

The “Oslo” modeling technologies provide a general-purpose modeling system that you can use to generate high-level (as well as more refined) models of many types of entities, including business processes, messaging systems, workflows, .NET applications, database systems, and so on. Even after a complex solution has been deployed, an “Oslo” model retains its basic, high-level overview of the solution, in addition to the details associated with its low-level design and implementation. This makes it easier to revisit and change a design after the initial development phase.

An “Oslo” model is not limited to abstractions, however its ultimate purpose is to solve a problem or implement a process, not just to characterize it. You can use an “Oslo” model not only to define the business process in an abstract sense, but also to define how to execute that process. After you create a high-level model of a solution, you can drill down into each activity of your workflow, defining how each of these activities work. A high-level activity can itself be a model, a complex business process or a simple business process. Using an “Oslo” model, you can see the whole and then focus on each of the parts. You can then focus on the parts of the parts. The modeling platform enables you to control the scope of your efforts. In addition to the basic high-level overviews that they provide, “Oslo” models are also powerful tools that make it much easier to understand the complex implementation details of a system.

The Model at Deployment and Run Time

“Oslo” models remain relevant throughout the project lifecycle. At the highest level, an “Oslo” model can be rendered as a graphical representation of a system design. At a lower level, model data includes the schema for system data. A model describes the data structure of a system. When you use the model to create a solution, “Oslo” creates a model instance that includes the data that describes the specific solution. As a result, an “Oslo” model serves an integral role in the implementation of a system, in addition to its design.

Deploying and managing a solution is much easier when you can model the entire solution, including how the implementations are deployed. A model enables you to conceptualize the solution, even though it may require multiple components on multiple computers. It is much easier to deploy and manage a complex solution that is modeled, rather trying to deploy and manage a collection of components that are built and deployed separately.

The use of modeling extends to the runtime, as well; a model can be more than just a static visual representation of the system. A model-aware application – a database-driven application, in other words – can understand models at runtime and execute them if they have the capability. The model can be updated dynamically at each stage of the design, development, deployment, and execution of the solution. The model can ensure that there is no loss of data from one stage to another stage of the project lifecycle. In the “Oslo” modeling tools, anyone (with the appropriate permissions) can review the business requirements, implementation, and production status of the application by examining model data. You can determine exactly what is happening with the solution at each stage of the project lifecycle, including production.

See Also

Fill out a survey about this topic for Microsoft.