You can generate a diagram of the classes and expressions used by a ViewModel to understand its model scope and investigate unexpected dependencies.
Analyze a ViewModel
Use Analyze expressions when you need to see which model classes and relations a ViewModel reaches through its ViewModel-class and column expressions. This is especially useful before changing a complex view, when checking why an expression depends on a class, or when reviewing how much of the domain model one view uses.
- Open the ViewModel in the ViewModel Editor in MDriven Designer.
- Click Analyze expressions in the upper-right corner of the editor.
- Review the generated UML diagram.
- Select the relevant ViewModel class or expression in the editor and trace the corresponding model classes and relations in the diagram.
- Use the result to return to the expression that introduced an unexpected dependency, then save and run the normal model checks.
The analysis is a maintenance aid: it shows the static model scope that expressions reach. It does not replace testing the view with representative data.
What the diagram tells you
A ViewModel unfolds part of the UML model for a particular purpose. A rooted ViewModel starts from a specific model object; an unrooted ViewModel finds objects without such a starting object. Its ViewModel classes and columns use expressions to navigate associations, read attributes, calculate values, or find objects.
The analysis diagram brings those expression dependencies together. It can reveal that a view which appears small in the user interface actually reaches many classes through several relation paths.
For example, a view may show a project, a list of its articles, a selected article's packaging components, and related logistics information. Although the screen may contain only a few grids, the expressions can navigate through several associations. The diagram helps you identify that full dependency path before you change a column or nesting expression.
Read the result effectively
Review the diagram with a concrete question. Start with the ViewModel class or column that owns the expression, then follow its model dependencies outward.
| Question | What to look for | Next action |
|---|---|---|
| Which model area does this ViewModel use? | The classes and relations reached by its expressions. | Confirm that each dependency belongs to the view's purpose. |
| Why did a column become dependent on an unexpected class? | The relation path from the column's context to that class. | Inspect the column expression and the nesting expressions that establish its context. |
| Is a view becoming difficult to maintain? | A large number of classes or many interconnected relations. | Split responsibilities where the view design allows it, or document the intended dependency before making changes. |
| Which expression should I inspect after a model change? | The ViewModel class whose scope includes the changed class, attribute, or relation. | Use the editor to locate and revise the relevant expression, then validate the model. |
Understand expression scope
An expression is evaluated in the context of its ViewModel class. In a rooted ViewModel, the root context is the model object represented by self. A nested ViewModel class commonly receives a collection by navigating from that context.
For example, if a root represents a modeled Thing, a nested class can use an expression that follows the Thing-to-details association. The nested class then has Detail objects as its context and can expose their attributes. The analysis shows the involved Thing and Detail classes and their relation.
Search expressions can also broaden the scope. In a seeker, an expression such as:
Person.allinstances->select(p|p.Age>=vSeekIntValue)uses Person.allinstances and a ViewModel variable. Search expressions are used with persistent storage through OCL-PS in the seeker scenario. See Training:Bootcamp:Chapter 4 for the seeker example and OCL for expression language guidance.
Use the analysis during maintenance
Use this workflow when you modify an existing ViewModel:
- Run Analyze expressions before the change and note the classes and relations that the view is expected to use.
- Make the expression or nesting change.
- Run the analysis again and compare the scope. Investigate any newly reached class or relation that you did not intend to add.
- Check the model for expression errors. MDriven's model checking covers ViewModel columns as well as constraints, derived attributes, and associations.
- Test the view with data that exercises the changed path, including empty collections and the selected-object cases used by seekers.
When you need to find where a class, attribute, or association is used elsewhere in the model, use the CrossReference menu. It works on model elements and can help you find ViewModel usage beyond the ViewModel currently open.
Analysis is not a QueryPlan trace
The expression diagram shows the static classes and relations that a ViewModel expression can use. It is not a record of data fetched for one execution.
To inspect how MDriven prepares data for a view, use QueryPlan. You can right-click the ViewModel main class and select Extras and then QueryPlan to place a static QueryPlan report on the clipboard. For runtime investigation, QueryPlan logging is available through the debugger's Logging tab by enabling PMapper.
Keep these two questions separate:
| If you need to answer... | Use... |
|---|---|
| "Which classes and relations do my expressions reach?" | Analyze expressions |
| "What data does the ViewModel need and how is it fetched?" | QueryPlan |