MDriven Designer is a standalone Windows application for developers, architects, and business analysts who want to define an information system as a UML model and use that model to prototype and build an application.
What you do in MDriven Designer
You use MDriven Designer to capture the structure and behavior of a system in a model. The model can include:
- Classes that represent the things the system handles.
- Attributes that describe those things.
- Associations that describe how things relate to each other.
- Business rules and constraints written with OCL (Object Constraint Language).
- State machines that describe an object's lifecycle and permitted state changes.
- ViewModels, which define the data and actions presented to a user interface.
For example, an order-management model might contain an Order class, an OrderLine class, and a Product class. An association can express that an order has order lines and that each order line refers to a product. You can then add rules for the model and define how an order moves through its lifecycle.
MDriven Designer uses UML (Unified Modeling Language) for its visual models and OCL for declarative rules. The model is not only documentation: it is used when you prototype, generate application behavior, and evolve the system.
From model to application
A typical MDriven workflow is:
- Create a model in MDriven Designer that defines the domain, rules, and workflows.
- Run the model with the built-in prototyper to test the idea while you model.
- Define ViewModels when you need to control what data and actions a user interface exposes.
- Use the model with other MDriven products to run and deliver the application.
When the model changes, MDriven Designer can apply those changes to the existing information structure while preserving data where possible. This makes the model the maintained specification for the system rather than a diagram that becomes detached from implementation.
What MDriven Designer is not
MDriven Designer is the modeling and design application. It is not the same component as the products that host or present an application.
| Component | Role | Example |
|---|---|---|
| MDriven Designer | Creates and maintains the UML model, rules, diagrams, state machines, and ViewModels. | You add Order, OrderLine, and the association between them.
|
| MDrivenServer | Runs and hosts model-driven applications. | You deploy the order model so users and connected systems can use it. |
| MDriven Turnkey | Provides a model-driven application front end that uses the possibilities in Designer and Server. | You make the order workflow available through a web-based user interface. |
See Documentation:MDriven Product Line for the wider product lineup, including Mockotype, MDriven Designer, MDrivenServer, and MDriven Turnkey.
Main modeling capabilities
Model the domain
Use class diagrams to describe the system's information. A class represents a type of object, an attribute represents a value on that object, and an association represents a relationship between objects.
For example, model a customer and its orders as two classes, Customer and Order. Connect them with an association to state that a customer can have orders. This gives the system a shared definition of the information it must handle.
Express rules and behavior
Use OCL and declarative rules to put business logic in the model. Use state machine diagrams when an object has a defined lifecycle.
For example, an Order can have states such as new, approved, and completed. A state machine makes the allowed transitions explicit; a rule can ensure that the model stays consistent when data changes. Learn the available modeling areas in Documentation:Designer.
Design the user-facing model
A ViewModel describes data and actions for a user interface. MDriven Designer can create ViewModels for the classes you define, and you can refine them to match a user task.
For example, an order-entry ViewModel can expose the current order, its lines, and actions relevant to processing that order, instead of presenting every class in the model at once.
Prototype and evolve
Use the built-in prototyper to test a model before deployment. As requirements change, update the model and test the changed behavior again.
For example, if orders must record a delivery date, add that information to Order, review the affected ViewModels and rules, then prototype the revised flow. The model remains the place where that change is defined.
Start modeling
Follow these steps to create your first diagram:
- Install and start MDriven Designer as described in Documentation:MDriven designer overview Part 1.
- In the overview screen, inspect the existing diagrams and the repository tree.
- Create a class diagram with Add Class diagram.
- Select the new diagram and set its Name in the Object Inspector.
- Open the diagram by double-clicking it.
- Right-click in the diagram and choose Add a class.
- Add classes and associations for a small domain, such as
CustomerandOrder.
Categories in the repository tree can help you organize diagrams. For example, assign customer-related diagrams to a category named Customer management and reporting diagrams to Reporting.
For a guided introduction, continue with Documentation:MDriven designer overview Part 1 or the Documentation:MDriven Designer Overview Series.
Who should use it
MDriven Designer is intended for people who need to create or refine software systems through a shared model:
- Developers who want to define domain structure and business behavior with models.
- Software architects who need to communicate and maintain a system specification.
- Business analysts who need to describe information, rules, and workflows with the delivery team.
You do not need to start by defining an entire system. Begin with one bounded task, such as recording customers and their orders, prototype it, and extend the model as the requirements become clear.