Model-driven application examples
You can use these examples to map a business process into a UML model and identify what MDriven can generate or execute from that model.
Example: inventory movement
An inventory application can model a product, a stock movement, and the reason for the movement. The inventory-management example describes an operator selecting a product, entering a quantity, choosing either SALE or ADJUSTMENT OUT, and saving the movement.
In the model, the business rule is that a stock movement records its product, quantity, reason, and movement date. The application then presents fields and actions for that use case. This makes the process visible for review: a stakeholder can verify that a damaged item is recorded as an adjustment rather than a sale.
| Model concern | Concrete inventory example |
|---|---|
| Data | Product, quantity, movement reason, notes, and movement date |
| Process | An operator records stock leaving the warehouse |
| User interaction | Select a product, enter a quantity, choose a reason, then use SAVE, CANCEL, or OK |
| Result to review | The recorded movement and its associated metadata |
Example: extending a legacy ERP system
You can place existing data behind a model and add new features without replacing the existing system. For example, an organization with an ERP system can model the data it needs to expose, then add new features while leaving the existing system in place. This is the legacy-modernization scenario described for MDriven: wrap existing data in a modern model, add features, and avoid a rip-and-replace approach.
Where an application uses OpenID Connect, OpenID configuration describes configuration settings such as OpenID_ClientId and OpenID_Authority. This separates the business model from the identity-provider configuration while keeping the application login process explicit.
Example: a model at production scale
A published customer statement describes using UML to organize complex data structures and relationships, using OCL for methods and derivations, and using ViewModels to encapsulate use cases for data manipulation or user interaction.
A separate published customer statement describes a model with 677 modeled classes, with about 50% using MDriven persistence and 25% versioned. The same statement reports an application of about 850,000 lines of code used in the management of assets of about 130 billion EUR in funds. These figures describe that customer's application and are not a general sizing or delivery estimate.
What these examples demonstrate
The examples show the practical boundary of the model-driven approach:
- Model data, rules, and workflows as the shared description of the system.
- Run and test executable models through MDriven Designer and MDriven Turnkey.
- Evolve the model when the process changes.
- Extend an application through REST endpoints or custom C# when the surrounding system requires it.
For the feature-level description, see MDriven features and benefits.