1. Build Enterprise Information Systems

You can use MDriven to model an enterprise information system, test it with real data and users, and evolve the same model as business needs change.

An enterprise information system manages business information, the relationships between that information, the rules that govern change, and the user tasks that act on it. In MDriven, you express these concerns in a model rather than separately specifying them for multiple implementation teams.

This page describes a practical, iterative way to build such a system. For an introduction to the platform, see Training:What is MDriven. For a broader explanation of the model-driven approach, see Documentation:How does MDriven work.

1. 1. Start with the information the business needs to manage

Identify the business things that must be stored, found, changed, and reported on. Model each thing as a **class**: a description of a type of information and its properties.

For example, an order-handling system might start with these classes:

| Business thing | Class | Example attributes | |---|---|---| | A company that buys goods | `Customer` | `Name`, `CustomerNumber` | | A request to buy goods | `Order` | `OrderNumber`, `OrderDate` | | A line in an order | `OrderLine` | `Quantity` | | A good that can be ordered | `Product` | `Name`, `UnitPrice` |

Use the names that the business uses where possible. A shared vocabulary reduces ambiguity between domain experts and the people who build and maintain the system. If your organization needs to distinguish business catalog terms from implementation classes, see Enterprise Architecture Information.

1. 1. 1. Make the model precise enough to test

For each class, decide what information is required to support a real task. Do not begin by modeling every possible detail.

For example, a sales user may need an `Order` number and date before they can record an order. A future requirement for delivery instructions can be added when that need is confirmed. The model is designed to evolve; it is not a one-time document.

1. 1. Connect classes to describe business aggregates

Add **associations** between classes to describe how business things relate. An aggregate is a business whole made from related information.

In the order example:

- A `Customer` has orders. - An `Order` has order lines. - Each `OrderLine` refers to one `Product`.

These associations let the model answer questions such as:

- Which orders belong to customer `C-1024`? - Which products are included in order `O-1007`? - How many order lines does that order contain?

The association is part of the business description, not a detail to leave for a later database design. Model the relationship when you identify it, then test whether it reflects the way users describe their work.

1. 1. Model the rules for change

Information is not only stored; it changes under business rules. Model an object's lifecycle with a **state machine**. A state machine defines the allowed states of an object and the transitions between them.

For example, an `Order` may move through these states:

`Draft` → `Confirmed` → `Delivered`

A state machine makes an invalid change visible in the model. If an order must be confirmed before delivery, the model should not allow a direct transition from `Draft` to `Delivered`.

Use state machines for rules that depend on lifecycle state. Use **OCL (Object Constraint Language)** expressions for declarative rules, queries, and derived values. For example, an OCL expression can calculate an order total from its order lines, while the state machine controls whether the order may be confirmed.

Keep each rule close to the information it governs. This makes the model a readable description of both the data and the business behavior.

1. 1. Test the model with real examples

Create objects that conform to the classes, associations, and rules you modeled. An **object** is an individual instance of a class.

For the order example, create:

1. A `Customer` named `Northwind Retail`. 2. A `Product` named `Desk Lamp` with a unit price. 3. An `Order` for `Northwind Retail`. 4. An `OrderLine` for two desk lamps, connected to that order and product. 5. A transition from `Draft` to `Confirmed`.

Then ask users to perform the task they perform in their work. Can they enter the information? Can they find it again? Does the order total and lifecycle behave as expected? If a user cannot describe a needed fact using the current classes and relationships, refine the model before expanding the user interface.

Testing with concrete data exposes missing relationships and unclear rules earlier than reviewing diagrams alone.

1. 1. Build a ViewModel for each user task

A **ViewModel** is a model of a specific use case: the information, actions, and presentation needed for a task. It shapes the domain model for a user interaction without changing the underlying business classes to fit one screen.

For example, a `ConfirmOrder` ViewModel may show:

- The selected customer's name. - The order number and current state. - The order lines, products, quantities, and calculated total. - The action that confirms the order when its rules are satisfied.

This is different from using `Order` itself as a screen specification. The `Order` class represents the business concept; the `ConfirmOrder` ViewModel represents one task performed with that concept.

Create ViewModels around real workflows, such as creating an order, reviewing orders awaiting confirmation, or correcting an order line. Use OCL expressions in ViewModels for the data retrieval, calculations, and rules required by the use case.

MDriven can create customizable user interfaces from models through AutoForms and ViewModels. For details on ViewModels, OCL, AutoForms, and state machines, see Documentation:How does MDriven work.

1. 1. Choose how the system will run

After the model and key user tasks have been tested, choose the execution and deployment arrangement that fits the system. MDriven Designer is where you create and refine the model. MDrivenServer manages execution of deployed models and their data. MDriven supports systems deployed in the cloud or on your server, with web-based and rich-client application options.

Make this choice based on the needs you have established during modeling and testing. For example, if users need to access the order workflow through a web-based user interface, validate that workflow in that form before treating the solution as complete.

For an overview of MDriven Designer, see Documentation:Introduction to MDriven Designer.

1. 1. Iterate with users

Treat user feedback as model input. A request may reveal:

- A missing class, such as `DeliveryAddress`. - A missing association, such as an order's delivery address. - A new lifecycle rule, such as preventing changes after delivery. - A new ViewModel, such as a delivery work list.

Update the model, test the changed behavior with representative data, and review the affected ViewModels with users. Repeat this cycle throughout the life of the system.

The model remains the central description of the system as it changes. This avoids maintaining separate descriptions of business data, business rules, and user interactions that can drift apart.

1. 1. A practical delivery loop

Use this loop for a new system or a focused improvement to an existing one:

1. **Name the business information.** Create classes and attributes for the facts required by one business outcome. 2. **Describe the relationships.** Add associations that make the business aggregate navigable. 3. **Define change rules.** Use state machines for lifecycles and OCL for declarative rules, calculations, and queries. 4. **Create representative objects.** Enter realistic examples and verify that the model can represent them. 5. **Model one user task.** Create a ViewModel for a concrete workflow and review it with the people who perform that workflow. 6. **Run and deploy appropriately.** Use MDriven Designer to refine the model and MDrivenServer to execute deployed models and manage data. 7. **Incorporate feedback.** Change the classes, rules, associations, or ViewModels that feedback identifies, then test again.

Start with a small, useful slice rather than attempting to model the entire enterprise at once. For example, deliver order creation and confirmation before modeling every delivery and invoicing variation. Each completed slice gives users something concrete to validate and gives the team a firmer basis for the next decision.

1. 1. Why use one executable model?

In a hand-built approach, the business description, backend implementation, database design, and user interface are often produced in separate activities. Each handoff can introduce a different interpretation of the same requirement.

With MDriven, the classes, associations, state machines, OCL expressions, and ViewModels are part of the executable model. This lets you use the same model to discuss requirements, test realistic data, and build the application. The benefit is not that design work disappears; it is that you can validate the design as an operating system earlier and keep the description of the system close to its execution.

As scope grows, keep the model understandable and review it regularly with the people who know the business. See Managing Complexity in Enterprise Information Systems for guidance on managing growing complexity, and Reality and the Theoretical Best Model for guidance on balancing model quality with real delivery constraints.

1. 1. Related pages

- Training:What is MDriven - Documentation:How does MDriven work - Documentation:MDriven Developer's Guide: Model-Driven Development Simplified - Documentation:Introduction to MDriven Designer - Enterprise Architecture Information - Reality and the Theoretical Best Model - Managing Complexity in Enterprise Information Systems