An information model helps you describe the business information your system must handle, and is for anyone defining an MDriven application before designing processes or user interfaces.
An information model is a structured, abstract description of real-world information: the things the business works with, their properties, and their relationships. In MDriven, you normally express this model with UML class diagrams in MDriven Designer.
For example, a fruit seller may need to handle apples, customers, and orders. The information model can define an Apple class with a Comment attribute, an Order class, and an association showing which apples belong to an order. This tells you what information the system can store and relate; it does not yet decide which screen a user sees first.
Start with information
Model the information that has value to the business before you model its current process steps. When you know what information exists and how it changes, you can determine which work must create, update, or use that information.
For example, a process step called Approve order should change valuable information, such as an order status or approval date. If a step does not create or change information in a valuable way, investigate whether the step is needed.
This approach also gives stakeholders a concrete subject to review. They can confirm whether the system needs customers, orders, campaigns, or products before you decide how users navigate between screens.
What the model contains
In MDriven, the classes, attributes, and associations in the class diagram define the information the system can handle.
| Model element | Definition | Example |
|---|---|---|
| Class | A type of business information. | Customer, Order, and Apple are classes.
|
| Attribute | A named value held by an instance of a class. | An Order has an OrderDate; an Apple has a Comment.
|
| Association | A relationship between instances of classes. | A Customer places orders; an Order contains apples.
|
The model is an abstraction: include the information and relationships needed for the business, and leave out implementation details that do not describe the business domain.
From information model to information system
The information model is the foundation for a runnable MDriven system. MDriven can create and evolve an SQL database from the model. You then use OCL expressions to access, filter, and transform information defined by the model.
A ViewModel is a collection of expressions compiled to solve a specific use case. It provides a view or perspective of the information in your system. If the information model defines what the system can handle, ViewModels define how a user or another system handles that information.
For example:
- The model defines
Customer,Order, and their association. - An OCL expression selects a customer's orders.
- A ViewModel presents the customer and selected orders together for the use case Review customer orders.
Every interaction with the system is a use case, whether the actor is a human user or another system. A ViewModel can therefore render a user interface or define an interface for system-to-system communication.
Use AutoForms to inspect the model
AutoForms create mechanical ViewModels from the classes, attributes, and associations available in your model. Use them to verify that the information can be created, shown, and edited.
For example, after you add OrderDate to Order, recreate AutoForms to obtain an automatically generated ViewModel that includes the new attribute.
AutoForms produce a functional, data-driven system. They do not replace use-case design: users may still need to move between screens or assemble related information themselves. Adopt an AutoForm when it is a useful starting point, then adapt it into a ViewModel for the actual task. Recreating AutoForms does not replace adopted forms, but manual changes to an unadopted AutoForm are discarded when it is recreated.
Evolve the model with feedback
Treat the first information model and its ViewModels as a working hypothesis. Let users work with the system, collect feedback about the information they need together, and revise the model and ViewModels in iterations.
For example, users reviewing orders may repeatedly need the customer's delivery address on the same screen. Add or use the relevant association in the information model, then change the ViewModel to present the address with the order. Do not solve this by asking users to copy the address between screens.
Keep the model understandable
Use class diagrams as communication tools as well as technical definitions. Group related classes where this helps readers understand the domain. A large model can have several diagrams, each showing a useful perspective of the same underlying classes and associations.
You can also cross-reference ViewModels with process work items. For example, a process step named Create campaign can identify the ViewModel that users need for that work. This helps new team members find the tools associated with a business task.