You can use MDriven Designer to turn an incomplete business model into a running prototype, test real user flows, and improve the model while the requirements are still changing.

Prototyping in MDriven uses the same model, ViewModels, and logical rules that you can continue to develop into an application. You model the information you know, create views for the work people must perform, expose the actions that move between those views, and run the result. Each prototype session shows missing data, missing navigation, and unclear requirements early.

For an introduction to the platform, see Training:What is MDriven.

What you build when you prototype

MDriven separates the concerns that are often mixed together in conventional application code:

Concern	What you define	Car-rental example
Information	The classes, attributes, and associations in the model.	Customer, Car, Brand, and RentalContract.
Perspective	A ViewModel, which defines the information and controls shown for a task.	A search screen for customers or an edit screen for a rental contract.
Behaviour and navigation	Actions that save, create, show, or navigate to a ViewModel.	An action that opens a customer search so the selected customer can be assigned to a rental contract.

This separation lets you change one concern without rebuilding the others. For example, when a rental worker needs to assign a customer, you can add a search-and-select action to the rental-contract ViewModel rather than redesigning the whole prototype.

A prototype is not a substitute for checking robustness and production requirements. Its purpose is to make the intended information handling and user flow executable early, so you can find incorrect assumptions before investing in implementation detail.

Prototype a car-rental service

This example starts with a small car-rental domain and expands it in response to what happens when you use the prototype.

1. Model what you know

Create the initial information model for the business. At a minimum, model these concepts:

• Customer, with information such as a name.
• Car.
• Brand, associated with a car.
• RentalContract, associated with the customer and car involved in the rental.

Do not wait until every rule is known. Model the facts that are clear now, then use the running prototype to reveal what must be added.

2. Turn requirements into user stories

Write the tasks that each user must be able to complete. For this example:

• As a customer, I want to see cars that are available to rent.
• As a customer, I want to see the daily price and the total rental cost.
• As a rental worker, I want to create rental contracts for customers to sign.
• As a rental worker, I want to find available cars.

Use each story as a test. If you cannot complete the story in the prototype, identify whether the missing part is model information, a ViewModel, an action, or test data.

3. Create ViewModels for the tasks

Create ViewModels that cover the user stories. During early prototyping, use the scaffolding user-interface hints to place controls on the screen surface based on the types of the ViewModel properties. This gives you an executable starting point that you can refine after you validate the flow.

For the car-rental example, create ViewModels such as:

• SearchForCar
• SearchForCustomer
• ViewAndEditCustomer
• ViewAndEditRentalContract

A search ViewModel normally does not require a root object: it can open with no selected customer or car and return a result list. An edit ViewModel such as ViewAndEditCustomer or ViewAndEditRentalContract is rooted: it needs a specific Customer or RentalContract object to display and edit.

For example, SearchForCustomer can contain search criteria and a result list. ViewAndEditCustomer can show the selected customer's name and save changes.

4. Generate and refine actions

Open the ActionsDefinition dialog and select Create/Init standard actions. This creates standard actions such as save, quit, undo, and redo. It also detects your ViewModels and creates applicable ViewModel actions.

Review the generated actions before running the prototype:

1. Keep actions that can open a ViewModel without additional context, such as a customer search.
2. Remove generated actions for rooted edit views when the action cannot supply their required root object. For example, remove the generated actions for ViewAndEditCustomer and ViewAndEditRentalContract if they would open without a customer or rental contract.
3. In SearchForCustomer, add a ViewModel action that creates a new Customer and opens ViewAndEditCustomer for that new object.
4. Add an action that creates a new RentalContract when the workflow requires it.
5. Add class actions for showing existing customers and rental contracts. A class action gives a user a way to open the appropriate edit ViewModel for an object already present in a result list.

Action placement and visibility affect whether a flow is usable. Learn how to opt actions in or out of particular ViewModel locations in Training:Available Actions.

5. Run the first prototype

In MDriven Designer, select the Play button to start prototyping. When prompted to choose prototype storage, select XML for this initial local prototype.

The prototype opens as a generated WPF application. Its main menu contains the global actions that are available in the model.

Test a complete small flow:

1. Open Search for customers.
2. Search for a customer.
3. If no customer exists, run the new customer action.
4. Enter a name in the customer edit view, save it, and go back.
5. Confirm that the search result now includes the new customer.

This test verifies more than data entry. It verifies that the search ViewModel, creation action, rooted edit ViewModel, save action, and return navigation work together.

Use prototype feedback to drive the next change

Treat each gap you find as a precise change request. For example, the first run of the car-rental prototype may reveal:

• A rental-contract search is missing.
• Assign customer does not yet select a customer.
• Assign car does not yet select a car.
• Cars and brands exist in the model but there is no user interface to enter test data.

Record the observation in terms of what the user attempted and what must happen next. For example: “Open customer search from Assign customer; after the user selects one customer and confirms, set that customer on the rental contract.” This statement identifies both the navigation and the required result.

Add test data in the debugger

When a full maintenance user interface is not yet needed, use the debugger to create test objects. For this example:

1. Create a Car object and a Brand object in the debugger.
2. Save the prototype data by switching to dirty objects and saving to the prototyping XML file.
3. Open the AutoForm for the Car object.
4. Drag the Brand object to the car's Brand field to establish the association.

This gives SearchForCar data to return without delaying the prototype to build car and brand administration screens.

Implement assign-customer and assign-car

Add a ViewModel action to ViewAndEditRentalContract for each assignment task.

For Assign customer:

1. Configure the action to bring up SearchForCustomer.
2. Make it a modal action. A modal action requires the user to finish or cancel the selection before returning to the rental contract.
3. Allow the user to confirm with OK after one customer is selected.
4. On OK, assign the selected customer to the current rental contract.
5. Connect the action to the Assign customer button in the rental-contract ViewModel.

Create the corresponding action for Assign car, using SearchForCar and assigning the selected car to the current rental contract.

When you run the flow again, the car search opened by the modal action presents OK and Cancel. Search for a car, select it, and select OK to return to the rental contract with that car assigned.

Add the rental-contract search

Create a SearchForRentalContracts ViewModel. When it is ready, use the shortcut action to create a global action that opens it. Run the prototype again and verify that the new search is available from the main menu.

Be deliberate about where object actions appear in a search ViewModel. A search ViewModel can contain both a root area and a result-list nesting of the same type. If the root is always empty, actions that require an object in that root area are not useful there. Use the Action Cross Reference or the Actions Editor to opt those actions out while keeping the action available on the result-list objects. See Training:Available Actions for the procedure.

Repeat the loop

Continue with this short cycle:

1. Model the information and rules you currently understand.
2. Create or amend the ViewModel that supports the user's task.
3. Add or adjust actions for creation, navigation, selection, and saving.
4. Run the prototype and perform the user story.
5. Add test data when needed.
6. Record what prevented the story from completing, then make the smallest model, ViewModel, or action change that resolves it.

For example, after car and customer assignment works, return to the remaining stories. You may need to extend the model for availability or pricing, amend the search and rental-contract ViewModels, and add the actions that expose the new behaviour. The prototype makes those dependencies visible while they are still easy to change.

Choose the right prototype target

The built-in MDriven Designer prototype is a generated WPF application. Use it when you want a fast local check of actions and general flow.

If you need to prototype the HTML5 application experience, use a local Turnkey prototype instead. Documentation:Faster prototyping with Turnkey explains how to configure Local TurnkeyPrototyper with IIS, Web Deploy, XML persistence, and a local model file. It also describes how an <YourModel>_AssetsTK folder is mirrored for local asset and styling changes.

Documentation:Mockotype includes class definitions, ViewModels, AutoForms, local Turnkey XML-persistence prototyping, and a debugger in a simplified MDriven Designer mode.

See also

• Training:Available Actions
• Documentation:Faster prototyping with Turnkey
• Documentation:Mockotype
• Documentation:MDriven Designer Overview Series
• Documentation:MDriven Server Introduction