MDriven Designer is the visual modeling environment for developers, business analysts, and system architects who want to define an application's information, rules, behavior, and user interaction in an executable MDriven model.

What you do in MDriven Designer

You use MDriven Designer to create and maintain the model that describes your application. A model can document the information your organization works with and provide the basis for running and evolving the application.

For example, for an order-handling application, you can model:

• An Order class and an OrderLine class.
• An association between an order and its lines.
• Rules that calculate an order total or control when an order can change state.
• A ViewModel that lets a user view an order, edit its lines, and run an action such as Submit.

The model is not limited to a class diagram. It can bring together information, processes, applications, actors, and the classes that implement the information. This gives you one place to describe both the system and the relationships around it.

Core concepts

Concept	What it means in Designer	Example
Class diagram	A visual diagram of classes and their relationships. Use it to define the structure of the information in your system.	Model Customer and Order, with an association showing that a customer has orders.
Class	A definition of an information type, including attributes and associations.	An Order class can have an order number, date, and total.
Association	A relationship between classes.	An Order is related to one or more OrderLine objects.
OCL	Object Constraint Language (OCL) is used to express derivations, constraints, and logic against the model.	Derive an order total from the amounts on its order lines.
State machine	A diagram that defines an object's lifecycle and the transitions between states.	An order can move from Draft to Submitted when the required information is present.
ViewModel	A model of a user interaction. A ViewModel defines what data a user sees and which actions are available.	Present an order with its lines and a Submit action.
Action	An operation that performs business behavior, often from a ViewModel.	The Submit action changes an order's state after its rules allow the transition.

A first modeling session

Create a small model before you begin a full application. The following example uses an order and its lines so that you can practice the main parts of Designer.

1. Start MDriven Designer and create a new model. The initial overview shows the diagrams in the model and the repository tree.
2. In the repository tree, add a class diagram by choosing Add Class diagram.
3. Select the new diagram. Use its properties to give it a meaningful name, such as Order management. The name updates in the overview and repository tree.
4. Open the diagram by double-clicking it.
5. Add the classes Order and OrderLine.
6. Add the attributes that the example needs. For example, give Order an order number and date, and give OrderLine an amount.
7. Add an association between Order and OrderLine to represent the lines belonging to an order.
8. Add a derived value or constraint with OCL. For example, derive the order total from its related lines; learn the OCL syntax and modeling rules in the detailed Designer documentation.
9. Create a ViewModel for working with an order. Include the order data, its lines, and an action such as Submit.
10. If the order has a defined lifecycle, add a state machine and model the allowed state transitions.

Use clear diagram and model element names. Diagrams can also be categorized in the repository when you need to organize a larger model; for example, categorize a diagram as Important to distinguish it from supporting diagrams.

Model behavior and user interaction

A class diagram establishes the structure of the model. Add the following elements when the application requires them:

• Use OCL for derivations and constraints. A derivation calculates a value from the model; a constraint defines a condition the model must satisfy.
• Use state machines when an object's valid states and transitions matter. This is appropriate for concepts such as orders, cases, approvals, or requests.
• Use ViewModels to design the interactions users perform against the model.
• Use actions to place business operations in the user flow.

Keep each concern explicit in the model. For example, the association between Order and OrderLine describes structure; the total derivation describes a calculation; a Submit action describes an operation; and a state transition describes lifecycle behavior.

From model to application work

MDriven Designer supports the work around a model as well as the model itself. The Designer documentation covers modeling, persistence, UI modeling, testing, integrations, security, performance, and refactoring.

If you need to...	Continue with...
Learn the modeling foundations, associations, constraints, derivations, and enumerations	Documentation:Designer
Set up your environment and learn the platform vocabulary	Documentation:GettingStarted
Follow a guided introduction intended to make the main concepts less intimidating	Documentation:Start Introduction
Build a ViewModel, use actions, and follow a broader Designer walkthrough	HowTos:MDriven Designer Overview Series
Understand MDrivenServer's role in an MDriven solution	Documentation:What is MDriven Server?

Learn by extending the example

After creating the order model, extend it one concern at a time:

1. Add a Customer class and associate it with Order.
2. Add a rule that derives the total from the order lines.
3. Add states such as Draft and Submitted to Order.
4. Create a ViewModel that presents the order, customer, and lines together.
5. Add a Submit action and make its behavior consistent with the order's state machine.

This progression lets you see how structure, business rules, lifecycle, and user interaction refer to the same model instead of being maintained as unrelated definitions.

Next steps

Use Documentation:Designer as the topic index for detailed guidance. For a video-led walkthrough of the Designer interface and application modeling, use HowTos:MDriven Designer Overview Series. The first overview session demonstrates starting a new model, working from the overview and repository tree, adding a class diagram, opening it, and editing its properties.

See also

• Documentation:Designer
• Documentation:GettingStarted
• Documentation:Start Introduction
• HowTos:MDriven Designer Overview Series
• Documentation:What is MDriven Server?

Introduction to MDriven Designer

MDriven Designer is a visual model-driven development tool. It uses dynamic diagrams to define classes, business rules, and interactions between system components.

MDriven Designer is intended to help developers, business analysts, and system architects focus on functionality while the tool converts designs into working software.

Key capabilities

• Visual modeling: Define classes, attributes, relationships, and behaviors with visual tools. Class diagrams support entities and their relationships, including inheritance, associations, and derived attributes.
• State modeling: Use state-machine diagrams to describe an entity lifecycle and transitions triggered by events.
• Executable models: Models can serve as executable code.
• Business logic: Use OCL and declarative rules to place business logic in models.
• User interfaces: Create customizable user interfaces with Autoforms and interactive ViewModels.
• Data persistence and integration: MDriven Designer can generate SQL database schemas and supports integration with legacy systems.
• Model evolution: Update models as business needs change and regenerate the system from those changes.

Continue learning

• Getting Started with MDriven covers installation and environment setup, core concepts, and an overview of MDriven products.
• MDriven Designer documentation provides links to modeling basics, associations, constraints, state machines, ViewModels, actions, persistence, diagrams, testing, integration, performance, security, and refactoring.
• MDriven Designer Overview Series provides guided sessions on creating and operating an MDriven Designer application. The series includes sessions on the OCL Editor, ViewModels, actions and navigation, database searching, reports, link objects, MDriven Turnkey, and access groups.

See also

• MDriven Designer documentation
• Getting Started with MDriven
• MDriven Designer Overview Series

How executable applications work

Your UML model defines the application. When you deploy the model to MDriven Server, the server generates the database schema, APIs, and UI logic from the model and hosts the application for web access. MDriven also supports exposing ViewModels as REST endpoints and generating user interfaces from model and ViewModel information.

From business model to working forms

MDriven Designer uses standard UML to describe business data, rules, and workflows in a visual model. Its AutoForms feature can turn that model into a functional web application interface, helping teams inspect and test an application idea without first hand-coding every interface.

A UML diagram is a visual way to describe the information a business handles and how that information is connected. For example, a model may include classes such as Order, Customer, and OrderLine. The model can define the data structures and relationships needed to represent an order and the customer connected to it. This gives developers, architects, and business stakeholders a shared blueprint for the system.

AutoForms uses the current UML model to generate an initial interface. MDriven describes this as transforming UML diagrams into a functional web application; the generated interface reflects the model in the browser. AutoForms can therefore provide a quick way to see and work with the data represented by the model.

Example: order processing

An order-processing model could contain an Order class, an OrderNumber value, an OrderDate value, and connections to Customer and OrderLine. AutoForms can provide an initial interface based on that model, allowing the team to review whether the modeled information supports the intended order-processing work.

From generated interface to use-case design

AutoForms provides an initial, model-based interface. A production interface may require additional design for the specific work a person or another system needs to perform. In MDriven terminology, a ViewModel is a collection of expressions compiled to address a specific use case: it defines how the information in the model is handled from a particular perspective.

Use the generated interface to validate the model early, then refine the application around the tasks, rules, and interactions required by its users.

See also

• Documentation:Introduction to MDriven Designer
• Documentation:How does MDriven work
• Documentation:Class diagrams
• Documentation:What is UML
• Documentation:AutoForms–get more with less faster

Model-driven development for beginners

You can use MDriven Designer to describe an application as a model before building its database, business logic, and user interface.

Model-driven development (MDD) is an approach where the model is the core definition of the application. Instead of treating a diagram as documentation that can become outdated, you define the application's information and rules in the model, then use that model to create the application artifacts.

For example, a team task planner can have the classes Team, Project, Task, and Member. You add attributes such as Project.Name : String and Task.IsCompleted : Boolean, then create associations: a Team has Projects, a Project has Tasks, and a Task can be assigned to a Member. This model defines the application's information structure.

In MDriven, you then add the behavior and presentation that the application needs:

Model element	What you define	Example
Class and association	The information classes and their relationships.	A Project has many Task objects.
OCL	Object Constraint Language expressions for queries and business rules.	An expression can calculate a value from related objects.
ViewModel	How data is shaped for a specific user interaction or user interface.	A task view can show a task's title, completion state, and assigned member.
State machine	The lifecycle states and transitions for an entity.	A task can move through the states defined for its workflow.

When the model changes, make the change in the model first. MDriven can use the model to generate database schemas and user interfaces, while ViewModels define how users work with the modeled data. MDrivenServer manages and deploys the application model and its data.

You do not need to know every concept before you start. Begin by modeling a small set of classes and their associations, then add rules and ViewModels as the use case requires.

See also

• Getting Started with MDriven
• How does MDriven work
• MDriven Developer's Guide: Model-Driven Development Simplified
• MDriven Designer Documentation