You can use this page to understand the core MDriven terms you meet when you model, prototype, and build a business application.

Start with the model

MDriven is a model-driven development environment for defining an information system from a UML model and using that definition throughout the application.

Your model is the central description of the domain: its classes, attributes, associations, rules, and behavior. In a model-driven workflow, you change this definition first and then update the artifacts derived from it, such as code and database schema.

For example, a sales model may define the classes Customer and Order, where one customer can have many orders. That relationship is part of the model; it is not only a convention in application code or a database foreign key.

For the underlying approach and its relationship to Model Driven Architecture (MDA), Model Driven Development (MDD), and Domain Driven Design (DDD), see Model Driven.

Core concepts at a glance

Term	Meaning	Example
UML model	The structured definition of the domain and its behavior, expressed using UML.	Order has an order date and is associated with a Customer.
MDriven Designer	The graphical editor used to create and maintain MDriven model files.	You add the Order class, its attributes, and its association to Customer.
Persistence Mapper	The part that transfers model objects between memory and persistent storage.	An order is read from a database into an in-memory Order object, or a changed order is stored back in the database.
ViewModel	A declarative transformation that presents a selected part of the model for a particular user interface use case.	An order-entry ViewModel shows an order, its customer, and its order lines rather than every available property in the model.
UI hints	Presentation information attached to ViewModel transformations that helps a UI render the result.	A property in an order-entry ViewModel can be presented as an editable field while a calculated total is presented as read-only.
Action	A declared operation available to the user in a relevant context.	A Submit order action is available from an order document form.
OCL	Object Constraint Language expressions used to state rules and transformations over the model.	A rule can express that an order total is derived from its order lines.
EAL	ActionLanguage used for behavior that changes model state or carries out an action.	A submit action can set an order's state when its conditions are met.
MDriven Turnkey	The model-and-execute environment that uses declarative ViewModels, UI hints, and actions to run an application.	You execute an order-entry ViewModel and use its declared actions in the resulting application.

MDriven and persistence

MDriven helps a .NET runtime work with the objects defined by your model. A Persistence Mapper handles the transfer between in-memory objects and persistent storage, such as a database.

This transfer is often described using two directions:

• Hydrate an object graph: read stored information and create or populate the corresponding in-memory objects.
• De-hydrate an object graph: take in-memory objects and store their information in persistent storage.

For example, when a user opens order number 1024, the runtime can hydrate the order, its customer, and the order lines needed for that use case. When the user changes a line quantity and saves, the changed object information can be de-hydrated to storage.

ORM: Object Relational Mapping

Object Relational Mapping (ORM) is the general technique of mapping object-oriented application structures to relational database structures. It translates create, read, update, and delete operations on objects into database operations.

In the earlier example, Order and Customer are object-oriented concepts in the model. A relational database persists corresponding records and their relationships. The mapping layer keeps the application focused on model objects rather than requiring each use case to manually manage SQL and database connections.

MDriven Designer

MDriven Designer is the graphical editor for creating and evolving MDriven models. You use it to capture the domain structure and the declarations that build on that structure.

A typical modeling sequence is:

1. Create classes that use the domain's own vocabulary, such as Customer, Order, and OrderLine.
2. Add attributes, such as OrderDate and Quantity.
3. Add associations, such as the relationship from an order to its customer and order lines.
4. Add rules and derived information where the model needs to express business meaning.
5. Create ViewModels and actions for the application use cases that work with the model.

For an introduction to UML modeling concepts, see Documentation:UML School. For a starting workflow, see Documentation:GettingStarted.

ViewModels: define a use-case view

A ViewModel is a series of transformation expressions that turns part of the model into a view of that model. The view can select, arrange, and transform information for a specific use case.

A ViewModel is not the domain model itself. The domain model defines what an order is and how it relates to other domain concepts. The ViewModel defines what a user needs to see and do in a particular situation.

For example, an order-entry ViewModel can include:

• The selected order's number and date.
• The associated customer's name.
• A list of order lines with product, quantity, and amount.
• A calculated order total.
• An action that submits the order.

The same Order class can be used in another ViewModel for an order-search use case. That search ViewModel may show only order number, customer, date, and status. Keeping these views separate prevents one screen's presentation needs from redefining the domain model.

UI hints and declarative UI

ViewModels can capture UI hints for each transformation. Together with the transformation result, these hints enable a user interface to be derived declaratively.

For example, the order-entry ViewModel can declare editable order-line quantities and a read-only total. A UI based on that ViewModel uses the declared structure and hints rather than requiring the domain model to be manually reshaped for each screen.

MDriven can apply ViewModels to UI architectures including WPF, ASP.NET, and Angular. MDriven Turnkey uses the ViewModel, its UI hints, and declared actions to execute a thin-client application.

Actions and application forms

Actions express what a user can do in a model-defined application. An action can act on an object, within a current form or use case, globally, or as part of a structured menu.

For example:

• A class action can act on a selected Order.
• A ViewModel action can act in the order-entry context.
• A global action can open an order search from the main menu.

Actions can be enabled or disabled according to the current context or state. An order's Submit action, for example, can be unavailable when the order does not meet its required business conditions.

MDriven applications commonly use seek, document, and report forms. A seek form finds objects in persistent storage; a document form supports a use case from a root object and its associations; and a report form is non-interactive and paginated. For the complete form and action pattern, see Getting to the bottom of the Line of Business Application.

OCL and EAL

OCL (Object Constraint Language) expresses queries, constraints, derived values, and transformations over model objects. OCL describes what value, relationship, or condition applies.

For example, an order total can be defined as a derived value based on the amounts of its order lines. A validation can state a condition that must hold before an order may proceed.

EAL (ActionLanguage) expresses behavior for actions. Use it when an action must change state or perform work in the application context.

Keep these roles distinct:

Use	Choose	Example
Calculate or select information from model objects	OCL	Derive an order total from the order lines.
State a rule that must hold	OCL	Require an order to have the information needed by the business rule.
Carry out a user-initiated behavior	EAL	Implement the behavior of a Submit order action.

Enterprise architecture information

EA-Information captures cross-referenced information about the business beyond the application classes alone. It can describe processes, actors, applications, information, and infrastructure so that people can understand how the business operates and how its supporting systems relate.

For example, you can connect an order-handling process to the actor who performs it, the information it uses, and the application that supports it. Capture this information early and keep it current as the model and the business evolve.

How the concepts work together

A typical MDriven workflow connects the concepts in this order:

1. Define the domain in a UML model in MDriven Designer.
2. Express derived information, constraints, and transformations with OCL.
3. Define ViewModels for specific user tasks, such as finding an order or entering order lines.
4. Add UI hints and actions for the required interaction.
5. Execute the declarative application through MDriven Turnkey, or use the model as the source for derived application artifacts.
6. Persist the resulting model objects through the Persistence Mapper.

The model remains the shared definition. The persistence mapping handles storage, while ViewModels and actions define how users work with the relevant part of that model.

See also

• Documentation:GettingStarted
• Documentation:UML School
• Documentation:Learn OCL
• Model Driven
• Education:TheIndex