UML in MDriven explains how you use the Unified Modeling Language (UML) in MDriven Designer to describe a system's domain structure and behavior for developers, architects, and business analysts.
UML (Unified Modeling Language) is a standard language for visualizing a software system's design, architecture, structure, behavior, and relationships. In MDriven, UML diagrams are more than documentation: they form the model that MDriven uses as the basis for application execution, database synchronization, and generated user interfaces.
For example, a sales application can use classes named Customer, Order, and OrderLine. The model shows that a customer places orders and that an order contains order lines. This describes the business domain in terms that both domain experts and developers can discuss.
Model the system gist
The system gist is the domain-specific description of the ideas and actions that produce value in a system, without tying that description to a particular technology or fashion. UML lets you express this gist using the language of the domain.
For example, a fund-management system may model Fund, Investor, and Holding. These names describe the business rather than database tables, web pages, or framework classes. Keeping the model at this level makes it easier to maintain and evolve when the implementation technology changes.
Use class diagrams for structure
Class diagrams show the static structure of your model. A class is a blueprint for objects; an object is an instance of a class. A class diagram shows classes, their attributes, methods, and relationships.
A class is drawn as a box with these compartments:
- Class name â for example,
Order. - Attributes â data held by each order, such as
OrderDateandOrderNumber. - Methods â behavior available on an order, such as calculating a total.
An association is a relationship between classes. For example, an association between Customer and Order records that a customer can have orders. An association between Order and OrderLine records that an order has lines.
MDriven uses this structure as part of the running application model. The model can drive a normalized SQL database, and MDriven's Autoforms can use the model to create a functional web application.
Use inheritance for specialization
UML inheritance represents generalization and specialization. A superclass defines common attributes and associations. A subclass inherits them and adds details that apply only to that specialization.
For example, Fruit can be a superclass with a Name attribute. Apple and Orange are subclasses. Both inherit Name; Apple can add an attribute such as Variety.
In MDriven, a generalization association updates the class's superclass in the object inspector. A class can have one superclass or none; do not model multiple inheritance where the target object-oriented implementation does not support it.
Add rules and workflows to the model
A class diagram describes structure. You can add business rules with OCL (Object Constraint Language) and model lifecycle behavior with state machines.
For example, an Order can have a derived total calculated from its order lines. An OCL expression can define this calculation instead of duplicating the value manually. A workflow can represent states such as Draft, Submitted, and Approved.
Use a ViewModel when a use case needs data shaped for a particular user interaction or behind-the-scenes operation without changing the domain model. For example, an order-entry ViewModel can present a customer, an editable order, and available products together while Customer, Order, and Product remain separate domain classes.
UML as a living model
In MDriven, the UML model is the central description of the application rather than a diagram that becomes outdated after implementation. When you change the model, MDriven can synchronize the database through MDrivenServer and update the Turnkey user interface.
For example, if you add DeliveryDate to Order, that attribute becomes part of the model used for persistence and UI generation. Review the effect of model changes before deployment, especially when changing existing persisted data structures.