What Is a Model?
[This is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders.]
In its most common usage, a model is an abstract representation of an item or a concept—a car, a plane, or a building—or a part of something, such as a tire, a wing, or a room. Models are created in order to view, manipulate, or test the thing they represent without having to build the real thing. People use models and modeling every day to improve their work and their world.
For example, an architect draws a model of a building on paper to begin the design process without having to pick up a hammer or a nail. If the building is complex, the architect builds a small physical model of the building to judge its appearance and aesthetics; just as importantly, the model allows many others to see the architect’s conception, and to collaborate in improving it. Again, this is much less expensive than to actually construct the building. In the end, when actual construction occurs, there is a higher degree of confidence that the building can be built on time, within budget, and will work the way the designer predicted. As in the example of buildings, models provide a way to perfect a design in advance, fast and cheaply. In short, models reduce the gap between the intentions of the designer and the actual results. Using models, it is possible to build things better and more efficiently.
In code name “Oslo” modeling technologies, a model is used in the same way—to design, view, manipulate, and test representations of software components and software systems, including many other concepts involved in software design, such as the identity of software users or processes or its environment. However, code name “Oslo” modeling technologies also provides a platform to build run-time environments that consume and execute models directly. For more information about the models in the code name “Oslo” repository, see "Oslo"-Provided Domains.
Models Are Everywhere
Modeling as a technique is not new, either to the non-software world or to software products and platforms. Previous modeling approaches in software design and development were, for a number of reasons, less successful than anticipated. Some more recent modeling approaches have had more success, such as the Unified Modeling Language™, but are sufficiently platform-agnostic that they cannot take advantage of specific platforms and their possible optimizations or address very specialized fields of knowledge.
Specialized knowledge fields (also called problem domains) or specific platforms have been more successfully addressed by tools and languages (called domain-specific languages or DSLs) designed precisely for those subjects. In many areas, as a matter of fact, Microsoft users and developers already use models and modeling techniques in a number of products and platforms.
For example, the Extensible Application Markup Language (XAML) is used to build a model of a user-interface application that the model-aware Windows Presentation Foundation runtime consumes to produce WPF applications. This is a richer data model than the various .NET application configuration files provide, but both are model-driven approaches in which runtimes consume model data and execute it.
Models Connect Each Stage of the Application Lifecycle
In the preceding example, the model information is contained in a XAML file; in the “Oslo” modeling technologies, this model data is located in the “Oslo” repository, a SQL Server database that anyone with sufficient permissions can examine and use. Tools that understand the underlying data structures can provide a wide array of features at each stage of a distributed application development lifecycle.
People who are not developers but who understand business needs and processes very well can display those needs and processes quickly using a graphical tool such as Microsoft code name “Quadrant”, but it can immediately be understood with more precision when the underlying data structures are viewed by an architect.
System and application architects can examine the business process, and use a different visual tool to design a system from the same data the business process created.
Developers will have much higher-level constructs that enable much more to be accomplished prior to writing code, which reduces coding time and therefore increases developer productivity.
Information professionals can examine the structure of the entire system and understand the precise operational requirements of an application because those requirements are part of the application itself.
Debuggers and maintainers can examine and understand the entire structure of an application more quickly and can compare the running application against the requirements of the application model to quickly locate problem issues.
Tool developers can build custom tools to analyze data at any stage of design, development, or deployment, and these tools can be used by other tools to build yet richer and more highly refined productivity.
Those models, then, can be used by tools to quickly improve the design, implementation, and management experience of complex distributed applications.
Visual tools like “Quadrant” enable people who understand business processes to design a business process graphically, without having to understand and interact with the underlying models that describe their processes.
When they are finished designing that process, software architects can use a different view of the same model of the business process to design the application implementation that eventually makes the business process come to life. Some visual tools, such as the Workflow, Service Contract, and Data Contract designers, are hosted in Visual Studio and enable developers to visually design tasks that previously involved many lines of code, reducing actual coding to those areas that specifically require dynamic behavior. At each stage, the designers manipulate the underlying models that are represented visually in the tools.
Models in “Oslo”
The “Oslo” modeling technologies ships with many pre-existing models that describe business processes, the structure of composite applications, workflows, service and data contracts, and so on. The entire “Oslo” application platform is built upon these models, but each level of the system represents models in ways appropriate to the tool or platform, because each model is really a set of data structures, relationships, and constraints in serialized form. The “Oslo” modeling technologies applications expose these data in the form most easily understood and used by the people who understand the problem domains.
The code name “Oslo” repository is a SQL Server database designed to store model data structures, relationships, and constraints in a secure, robust, and scalable manner. As such, the shapes viewed in “Quadrant”, whether model template shapes or model instances on a workspace, are stored as tables and row data in SQL. Because in this form there is no obvious visual representation of the data, SQL-based terminology is typically used. For example, a visual shape template in “Quadrant” is a SQL schema object in the “Oslo” repository that describes what an instance of that item can be. And adding a shape instance in “Quadrant” creates SQL schema instance data in table rows in the “Oslo” repository. When describing models in the “Oslo” repository, the words schema and instance are often used. This terminology makes sense if you are building tools to examine, modify, or represent model data that resides in the “Oslo” repository database, but does not necessarily clarify the visual experience of a design tool like “Quadrant”.
For more information about models and the code name “Oslo” repository, see "Oslo" Repository Overview.
How Models are Represented in “Quadrant”
For example, in “Quadrant” a model is represented by visual shapes in the left-hand pane that can be dragged and dropped onto a workspace and associated with other shapes into a larger design. Prior to dropping the shapes—for example, a workflow or activity—onto a workspace, a shape represents a template, a model of what that item can be when used. A workflow or activity can have a name, can be a particular kind, can have certain relationships with other items, and so on. (These templates are also called model schemas or simply schemas.)
After a shape has been dragged into a workspace, it becomes a model instance (or simply instance), meaning that it is a specifically configured version of one of the template shapes. As specific data is assigned to the shape properties (such as names or relationships to other shapes), “Quadrant” compares these values to the possible range of values specified by the template for that shape to determine whether the current design is valid. If not, “Quadrant” visually informs the designer what steps must be taken to complete the design in a valid manner.
For more information about models in “Quadrant”, see Modeling Language Editor.
Models in Visual Studio and the .NET Framework
Many of the system-provided models that come with the “Oslo” modeling technologies are also available in the .NET Framework in the form of XAML; the most useful areas are Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF).