You use MDriven to describe an information system as a model, test that model in MDriven Designer, and run it through a chosen application delivery path such as Turnkey, MDrivenServer, or MDriven Framework.

The model is the application description

MDriven uses model-driven development: you define the business concepts, their relationships, rules, and user interaction in a model rather than starting with handwritten implementation code. The model is both a working description of the system and a basis for execution.

For example, a delivery-tracking system can start with these concepts:

• A Customer has a name.
• An Order belongs to one customer.
• An Order contains one or more order lines.
• An order moves through defined states, such as new, confirmed, and delivered.

In a class diagram, you model Customer, Order, and OrderLine as classes and connect them with associations. This makes the information structure explicit: an order is connected to its customer and order lines, rather than that meaning being hidden across database tables, application code, and separate documents.

The model can also document more than data. MDriven Designer supports diagrams for the modeled system, including how information is used in processes and by actors. Keeping this information with the model helps the description evolve with the system.

Model the main parts of the system

Part	What you define	Example
Information model	Classes, attributes, associations, enumerations, and constraints.	Order has an OrderDate and is associated with one Customer.
Business rules	Derived values, constraints, actions, and state changes expressed in the model.	The order total is derived from its order lines; delivery is allowed only after confirmation.
User interaction	ViewModels, which define the information and actions presented to a user.	An order ViewModel shows the customer, lines, total, and a Confirm action.
Persistence	How modeled information is stored in a relational database, including object-relational mapping decisions when needed.	The modeled Order information is persisted in a database; see OR Mapping.

ViewModels define the user-facing view

A ViewModel is a model of a user interaction. It selects and organizes information from the domain model for a specific task, and it can expose actions that the user can perform.

For example, the domain model may contain all order-related information. An Order overview ViewModel can present a list of orders and an action to open one order. An Order edit ViewModel can present the selected order, its lines, and the actions available for that order. This separates the business information from the way a particular user task displays it.

MDriven can generate forms from the modeled structure. Generated forms provide a starting point for working with modeled information; you can refine the ViewModel and its presentation when the task needs a more specific interaction. See MDriven Designer documentation for ViewModel and UI-modeling topics.

OCL expresses model logic

OCL (Object Constraint Language) is used to express queries, derived values, conditions, and other model logic. It lets you state logic in terms of the modeled classes and associations.

For the order example, an OCL expression can calculate an order total by navigating from an order to its order lines and their amounts. A condition can determine whether the Confirm action is available. The expression is attached to the relevant modeled element, so the rule stays close to the information it concerns.

State machines model permitted changes

A state machine defines the allowed states of an object and the transitions between them. Use one when the validity of an action depends on where an object is in its lifecycle.

For example, an Order may move from New to Confirmed, then to Delivered. Modeling these transitions makes the workflow explicit and gives actions a defined place in the model. For details, see State Machines and Workflows in MDriven Designer.

Work in MDriven Designer

MDriven Designer is where you create and maintain the model. You can use it to model classes and associations, add derivations and constraints, create ViewModels and actions, work with diagrams, and test the model.

A typical early workflow is:

1. Create the business classes and associations. Start with the information the system must retain.
2. Add attributes, enumerations, and constraints that make the information valid.
3. Add derived information and business actions. Use OCL where the logic navigates or calculates from the model.
4. Create ViewModels for the user tasks you need to test.
5. Run the model in the prototyper, inspect the generated interaction, and revise the model.
6. Repeat with users and stakeholders until the modeled information, rules, and tasks match the intended system.

This approach lets you validate an advanced information-handling idea without first writing Java or C#. Developers can also use the same model as the basis for a finished system. For an introduction to this way of working, see What is MDriven.

Run and deliver the model

The model is independent from a single UI technology or delivery approach. Choose the path that fits the application you are building.

Path	Use it when	What it provides
Turnkey	You want to run a model through MDriven's application delivery path.	An execution option that works with MDriven Designer and MDrivenServer.
MDrivenServer	You need backend persistence and deployment infrastructure for an application built with Turnkey or MDriven Framework.	It hosts the application backend and database-related model evolution. In MDriven Designer's prototyper settings, select MDriven Server and use Start System to connect to a server instance and evolve the database from the model.
MDriven Framework	You need an application project with explicit C# model classes and want to work in Visual Studio.	A Visual Studio-based route for bringing a model into an application project. You can continue opening the model in MDriven Designer.

For example, after testing the order model in the prototyper, you can select MDriven Server in the prototyper settings and start the system to use server-backed persistence. As the model changes, MDrivenServer calculates and applies the required database schema changes for modeled classes and attributes.

If you instead need explicit C# classes in a Visual Studio application, move the model to MDriven Framework. The framework uses the multi-file, uncompressed ecomdl model format, which is intended to work well with diff tools and source-control systems such as Git and SVN. Follow Moving your work from MDriven Designer to MDriven Framework for the required project setup and code-generation steps.

Keep the model as the stable description

The important asset is the model: the information structure, rules, workflows, and user tasks that describe the business problem. Execution technology can change without requiring that description to be rewritten as a collection of unrelated implementation artifacts.

Treat the model as a maintained part of the system. When the business changes—for example, when an order gains a new state or a customer requires a new attribute—update the class, association, rule, ViewModel, and workflow that describe that change. This keeps the system description aligned with its behavior.

Next steps

1. Start with MDriven Designer to learn the modeling workspace and core modeling concepts.
2. Learn OCL before adding non-trivial derivations, queries, and conditions.
3. Create a small ViewModel and test it in the prototyper.
4. Choose a delivery route: MDrivenServer, Turnkey, or MDriven Framework.
5. If MDriven Designer does not start because of assemblies left by an older installation, follow Exception starting.

See also

• Training:What is MDriven
• Documentation:Designer
• Documentation:MDriven Developer's Guide: Model-Driven Development Simplified
• Documentation:OR Mapping
• Documentation:Blazor
• Documentation:Moving your work from MDriven Designer to MDriven Framework

What no-code means in MDriven

MDriven describes its approach as visual modeling rather than manually building every application layer. You capture business rules, workflows, and data in a shared visual model that acts as the system's blueprint.

MDriven states that it can use this model to generate a full-stack application, including synchronized SQL schemas, responsive web user interfaces, and REST endpoints. As requirements change, the model can be updated and the application redeployed.

In this sense, no-code means reducing the need to manually write the surrounding application code by defining the business process and data model visually. MDriven also states that applications can be deployed on-premise, in the cloud, or with Docker.

See also

• MDriven website
• MDriven video: Traditional VS MDriven NoCode