You can use the Model Debugger in MDriven Designer to inspect and update the model's own metadata when a repeated manual model change would be difficult; this page is for model designers who need to find or correct model elements at scale.
What you can change
MDriven Designer represents the model itself as an MDriven model. When you open the Model Debugger for the Designer model, its objects are model-definition objects rather than the business objects in your application.
This lets you query and change model content such as:
- Classes, attributes, and association ends.
- ViewModel definitions, spans, span variables, and columns.
- Actions and their expressions.
- Tagged values on model elements.
For example, after renaming a class manually, you can use an expression to locate association-end names, action expressions, and ViewModel expressions that still contain the old class name. See Rename a class in your model using the Model Debugger.
Open the Model Debugger for the Designer model
- In the model design window, right-click the diagram background or another available Designer location.
- Select Extras.
- Select Open Model Debugger....
In many Designer locations, Extras also provides Show autoform.... The autoform gives you an object-oriented view of the Designer model objects. Use it to inspect the object that an expression returns and to follow its links.
The debugger opens against the model-definition context. This is different from debugging your application's runtime data: here you work with terms such as Class, Attribute, AssociationEnd, Span, and TaggedValue.
Use OCL to find model elements
OCL is a query language. Use it first to locate and inspect model elements. OCL does not make side effects, so it is the right starting point before you alter anything.
For example, this query finds ViewModels that have an MVC tagged value:
Span.allInstances->select(s | s.TaggedValue->select(tv | tv.Tag.toUpper='MVC')->notEmpty)
Run a narrow query first. Inspect the result in the debugger or open returned objects in the object editor. Follow links to understand where an element is used before changing it.
For details about evaluating expressions and inspecting results, see Documentation:OCL Debugger.
Use EAL to change model elements
EAL (Enterprise Action Language) is the action language used when an expression must change data. In the Model Debugger, EAL can assign a property, create a model object, or remove a model object.
A typical mass-update follows this pattern:
- Use OCL to select only the intended model elements.
- Inspect the returned objects and confirm that the selection is correct.
- Switch to EAL and make one focused change.
- Inspect the changed objects and the dirty list.
- Use Undo if the result is not correct.
- Run model validation before proceeding to the next change.
For example, a tag-creation expression selects association ends that do not already have the requested tag, creates a TaggedValue for each selected end, and connects the new tag to that end. The complete expression and tag-removal guidance are in Adding or removing tagged values in your model using the Model Debugger.
Work in small, validated steps
A model-wide update can affect classes, links, action expressions, and ViewModel definitions. Do not treat a search-and-replace operation as complete because one expression ran without an error.
Use this workflow:
- Make the primary manual change in Designer when appropriate. For example, rename the class itself before locating remaining references.
- Click the green check mark at the top of the model design window to run model validation.
- Read the validation errors to identify the next kind of reference that needs attention.
- Run one OCL query or EAL update for that kind of reference.
- Validate again.
- Continue until the model validates and the remaining references have been reviewed.
The class-renaming procedure demonstrates this approach for association ends, attributes, actions, and ViewModel content. It intentionally uses separate expressions so that you can validate and review the model between each step: Rename a class in your model using the Model Debugger.
Inspect, test, and undo changes
The debugger can hold selected result objects in memory variables such as m1. You can then use the variable as the starting point for another expression. For example, when m1 contains a collection, evaluate m1 to review that collection, or navigate from it to linked objects before writing an EAL update.
After an EAL expression changes objects, inspect the dirty list to see exactly what changed. If the update is not correct, use the debugger's Undo feature, revise the expression, and test again. This is particularly useful for one-time corrections and for proving that a selection targets only the intended objects.
Diagnose invalid or damaged model content
Use the Model Debugger when model validation reports an error that is difficult to locate in the model files, including errors introduced by a repository merge. Open the object editor to investigate the offending model object, or use EAL to remove an offending object when that is the appropriate correction.
For the diagnostic procedure, see Check model error.
When you are prototyping a ViewModel, the debugger can be opened with the same context as the prototype. You can inspect the ViewModel definition and its data, copy the relevant expression into the debugger, and evaluate it there. You can also clone ViewModel variables to examine the values designed for the ViewModel context.
Use this capability to understand an expression before changing model metadata that contains it. For broader guidance on the OCL editor, prototyper, and ViewModel context, see OCL Editor, system prototyper and ViewModel.
When to use this technique
Use the Model Debugger to change the model itself when you need to:
- Find all occurrences of a term across model metadata.
- Apply a consistent tagged value to selected model elements.
- Correct a repeated expression or configuration value after reviewing the selected objects.
- Investigate a validation error that cannot be located efficiently in the Designer surface.
Use focused queries and incremental EAL changes. The debugger gives direct access to model metadata, so an overly broad selection can change more of the model than intended.