UI-First design lets you create a ViewModel from a proposed screen in MDriven Designer, for teams that want to capture requirements through a working UI before the information model is complete.

UI-First and information-first

MDriven traditionally supports information-first design: you define classes, attributes, and associations in the model, then build a declarative ViewModel from that information.

UI-First design reverses the starting point. You sketch the screen that the user needs, then connect each UI element to existing model information or create the missing information while you work.

For example, a user may describe an invoice screen with an invoice number, a list of invoice rows, and an Add invoice row button. You can create that screen first, then create the Invoice class, its Number attribute, the InvoiceRow class, and the association between them as the UI requires them.

Both approaches remain available in MDriven Designer. UI-First does not replace information-first design.

Build a ViewModel from a screen

Use the UI tools in the ViewModel Editor to place controls before all model properties exist.

1. Create a new ViewModel and set its context type. For an invoice screen, create or select the Invoice class as the context.
2. Select a UI tool and drag it onto the ViewModel design surface.
3. Add a field for the invoice number and a grid for invoice rows.
4. Add a button where the user needs to add a row.
5. Run the prototype to discuss and test the proposed UI.

At this stage, the screen can communicate the requirement even when its fields and collections are not yet connected to model information.

Connect a control to model information

Each UI widget has a target control. Select the widget and use its target control to define what the widget displays or edits.

For a string field, the target dialog shows the ViewModel context and the current expression. If the Invoice class has no attributes, there may be no suggested expression.

To create the invoice number field:

1. Select the field on the ViewModel surface.
2. Open its target settings.
3. Create an attribute named Number on Invoice.
4. Select the suggested OCL expression self.Number.
5. Use the suggested field name Number, or give the field another UI label if the requirement calls for it.

The field now reads and writes the Invoice.Number attribute through its OCL expression.

Create collections and associations from a grid

A grid must have a type of objects and a collection expression. When the required class or association does not exist, create it from the grid target settings.

For an invoice row grid:

1. Select the grid and open its target settings.
2. Set the grid object type to InvoiceRow. Create the class if it does not exist.
3. Create an association from Invoice to InvoiceRow.
4. Select the many-valued association end, for example Rows, as the grid collection.

Do not leave a business grid connected to all instances unless that is the intended requirement. A collection such as all InvoiceRow instances does not identify which rows belong to the current invoice. The association gives the grid the required ownership and navigation path.

Add fields in nested contexts

Controls inside a grid use the grid row type as their context. For example, a column that shows an invoice type name has the InvoiceType context when it represents an invoice type.

If no suitable expression is available:

1. Select the column or other nested control.
2. Open its target settings.
3. Create the required attribute, for example Name on InvoiceType.
4. Select the resulting OCL expression and suggested name.

This keeps the UI requirement and its model definition connected at the point where you identify the requirement.

Prototype early

Run the prototype as soon as the screen represents the discussion. You can use it to validate the screen flow, the required fields, and the relationships between objects.

For example, after adding InvoiceType.Name, create a few invoice types such as A, B, and C in the prototype. Then create an invoice and set its invoice type. This tests whether the UI exposes the intended value and whether the model has the required association.

Prototype data is not persistent unless persistence is enabled. If you restart the prototype without persistence, objects that you created during the test are gone.

When to use UI-First

Use UI-First when a screen sketch is the clearest way to establish what users need. It is useful when you need to turn a conversation into an executable prototype while the model is still emerging.

Use information-first when the domain structure is already clear and you want to derive the UI from established classes, attributes, and associations.

Starting point	Typical work order	Example
UI-First	Place UI controls, then create or connect model information.	Sketch an invoice screen, then add Invoice.Number and Invoice.Rows.
Information-first	Define model information, then build the ViewModel.	Define Invoice, InvoiceRow, and their association before adding a grid.

See also

• Documentation:UI First–or information first
• Documentation:Learn OCL
• MDriven Designer
• MDriven Turnkey

Watch the UI-First walkthrough