A model is the structured description of the application you build in MDriven Designer, for developers and domain experts who need to define the application's data, relationships, and selected behavior before creating its user experience.
What a model represents
A model is an abstraction: it records the parts of a real-world domain that the application must understand, while leaving out irrelevant detail. In MDriven, the model is not only documentation; it is the structure you work from when building an application.
For example, a sales application may model:
- a
Customerclass; - an
Orderclass; - the relationship between a customer and that customer's orders; and
- an order state machine that describes the states an order can be in.
The model gives developers, architects, and users a shared vocabulary. If the business term is Customer, use that term consistently in the model rather than letting each part of the application use a different name.
What you model in MDriven
MDriven uses UML (Unified Modeling Language) representations for important parts of the model.
| Model element | What it describes | Example |
|---|---|---|
| Class diagram | Data structures, their relationships, and constraints. | Customer is related to Order; an order belongs to a customer.
|
| State machine | Behavior expressed as states and changes between states. | An Order moves from a created state to later states as its handling progresses.
|
| Package | A container for a section of the model. | Put the classes that belong to one application area in a package so the model remains organized. |
| Tag extensions | Additional information recorded on model elements. | Add model-specific information to a class or another model element when the standard model information is not enough. |
Data structure and relationships
The class diagram is the MDriven representation of the application's data model. Classes describe the concepts the application stores. Relationships describe how those concepts are connected.
For example, model Customer and Order as separate classes because they represent different concepts. Connect them with a relationship so the model records that a customer can have orders. This is more useful than treating an order number as unrelated text on a customer, because the relationship is explicit in the model.
Behavior
A state machine is a UML representation of behavior. It describes the states an object can occupy and how it responds as it moves between those states.
For example, model the lifecycle of an Order with states that correspond to the handling stages used by the business. The state machine makes those stages visible in the model instead of leaving them as an undocumented convention in application logic.
Why model first
Use the model to make the application understandable before and while you build it.
- Abstraction — Reduce a complex domain to the concepts and connections the application needs. For example, represent a customer by the information and relationships the application uses, not every detail known about that person.
- Analysis — Review classes, relationships, and behavior with stakeholders. For example, verify that an order can be connected to the correct customer before building views around it.
- Documentation — Preserve the design decisions in a structured form. A new developer can inspect the model to see the application's domain concepts and their connections.
- Visualization — Use diagrams to discuss structure and behavior. A class diagram shows the data structure; a state machine shows lifecycle behavior.
Organize a growing model
As the model grows, divide it into packages. A package is a container for a model section, and several packages make up a model. Packages can also be exported from or imported into models.
For example, keep customer-related classes together in one package and order-related classes in another when that reflects how the application is understood. Organize by meaningful domain area; do not create packages only to mirror technical layers when that makes the domain harder to find.
Use tag extensions when you need to capture additional information on a model element. Keep the core class and relationship structure clear; use tags for supplementary information rather than hiding fundamental domain meaning in annotations.
Start a new model
When you need a starting point for a new Turnkey project, use the Turnkey sample Empty start model. It contains an index page and the SysUser structure.
- Obtain the empty start model from its page.
- Open it as the starting model for the project.
- Add packages and classes for the application's domain.
- Define relationships between the classes.
- Add a state machine where the domain needs explicit lifecycle behavior.
The starting model is intentionally small. Add only the concepts that the application needs, and keep the names aligned with the terms used by the people who work in the domain.
Inspect and maintain the model
The MDriven model is itself an MDriven model. You can inspect and change it through the model debugger. In MDriven Designer, model-related contexts provide Extras options including Show autoform… and Open Model Debugger….
The model debugger lets you run OCL (Object Constraint Language) expressions against the model and manually alter model content. This is useful for maintenance work across a large model, such as locating model elements that meet a condition or updating tagged values consistently. Use it deliberately: changing the model changes the application's definition.
For an approach that exposes controlled model changes in a Turnkey application, see LiveUpdate. LiveUpdate is a merge model that holds information about requested model changes; a Turnkey web application can interpret that information and perform the changes on demand.
Model and deployment
Your model is also part of the application you run with MDriven Turnkey. For information specific to using a model with Turnkey on .NET Core, see MDriven Turnkey Core.