You can run your model locally in a browser with MDrivenStart Prototyper to test the application experience, create test data, and identify what your model still needs.
Contents
Before you start
Your model must be executable before you start the Prototyper.
- Define the information, ViewModels, and user interactions you want to test.
- Save the model and use Verify to confirm that it has no validation errors. Validation also runs when you save.
- Resolve all errors before starting. For example, two classes with the same name prevent the model from being executable.
A ViewModel is the perspective of model information that MDriven uses for a user interface. If you have created classes but no suitable ViewModel or entry path, users may have no way to view or create the objects in the prototype.
Start the local prototype
The Prototyper starts a local mini web server, MDrivenTurnkeyCore, that executes your model on your computer.
- In MDrivenStart, proceed to the Prototyper step after verification.
- Choose the local persistence option offered by the Prototyper. Persistence is where runtime data is stored.
- Complete the persistence configuration when the selected option requires it.
- In Step 3, download or update MDrivenTurnkeyCore when prompted. Download it again when you want the newest server version.
- Start the system.
- In Step 4, open the application in your default browser.
Close the prototyper-start window after the browser has started the web server. The browser continues to run the local application, and your system is automatically updated when you change the model.
Understand prototype data
The local mini server uses a file to store information created while you prototype. This gives you a place to create and retain test data on your machine while you evaluate the model.
Prototype file storage is not the production data-storage arrangement. When you deploy an application, its data is stored in a database. See MDriven Architecture for the wider runtime architecture.
| Environment | Data purpose | Storage described here |
|---|---|---|
| Local Prototyper | Test the model and user experience on your computer | A local file used by MDrivenTurnkeyCore |
| Production deployment | Run the application for its users | A database |
Prototype by following a user task
Use the running application as a user would. Work through one concrete task at a time, then return to MDriven Designer when the task reveals a gap.
For example, suppose a user must create a rental contract and assign both a customer and a car:
- Open the rental-contract ViewModel in the browser.
- Try to create a contract and assign a customer.
- If there is no way to select a customer, add a ViewModel action that opens a customer search, lets the user choose one customer, and assigns the selected customer when the modal action is confirmed.
- Repeat the task for assigning a car.
- If no cars or brands exist to select, create test data first, then save it to the prototype data file.
- Add a ViewModel for searching rental contracts if users need to find existing contracts.
- Save and validate the changed model, then continue testing in the browser.
This loop makes missing behavior visible in context. Typical findings include:
- A class has no ViewModel for entering or viewing its objects.
- A user can open a document but cannot search for the object that should be associated with it.
- Test data is missing for a relationship, such as cars and brands.
- A button exists in a ViewModel but has no action that completes the intended task.
- A rule, state transition, or guard prevents an action that the user expects to perform.
For the complete rental-contract example and further prototyping workflow, see Training:Prototyping.
Test model behavior with the debugger
The System Prototyper can also start a debugger for executing expressions against the running model. Use it when you need to inspect objects, create test data, or test model logic directly rather than through a browser ViewModel.
For example, an OCL expression such as House.allinstances returns the instances of House. OCL does not make changes to data; use Action Language when an expression needs side effects such as creating an object or invoking an action. The debugger accepts prefixes including ocl: and action: to select the expression language.
Read OCL Editor, system prototyper and ViewModel for the debugger workflow, expression execution, and the distinction between OCL and Action Language.
Work iteratively
A productive prototype cycle is:
- Change the model, ViewModels, or actions in MDriven Designer.
- Save and validate the model.
- Exercise the affected user task in the local browser application.
- Record what the task could not do or what was unclear.
- Add the missing model element, ViewModel, action, or test data.
- Repeat until the task works as intended.
Use the Prototyper to evaluate what users see, not only whether individual classes and expressions exist. A class can be correctly defined while its intended task remains impossible because the application has no view, search path, action, or data to support it.