1. Different types of bugs

You can use this guide to classify problems in an MDriven application and choose the right way to prevent, detect, and correct them.

A **bug** is a result that differs from what you expected. Classifying the problem matters because different bug types require different responses. Some problems are caught before you run the application; others require tests or validation; and some reveal that the business rule itself must change.

1. 1. The three bug types

| Bug type | What it means | Example | Primary response | |---|---|---|---| | **Typing bug** | The implementation does not say what you meant to enter. | You intended to use an existing class name but create a second class with the same name. | Use model validation and tools that check the model before execution. | | **Code bug** | The implementation is syntactically valid but does not produce the intended behavior. | An action is valid, but its OCL (Object Constraint Language) expression selects the wrong set of objects. | State expected behavior as executable expressions and test the result. | | **Think bug** | The application behaves as declared, but the declared requirement is not what users need. | A workflow permits an order to be approved without the information that users later decide is required. | Review the result with users, change the model or rule, and iterate. |

These categories can overlap. For example, a model can be valid, an OCL expression can execute as written, and the resulting workflow can still be wrong for the business. In that case, the immediate issue is a Think bug, not a validation failure.

1. 1. 1. Typing bugs: the model does not express what you intended

A Typing bug occurs when what you entered differs from your intention. In MDriven, validation catches model problems that prevent the model from making sense as an executable model.

For example, using the same class name twice is a common model mistake. The model must be clean before you start it in the prototyper or deploy it to the server.

1. 1. 1. Prevent and find Typing bugs

1. Build and edit the model in **MDriven Designer**. 2. Click **Validation** to validate the model manually. 3. Save the model. Validation also runs automatically when you save. 4. Correct every reported error. 5. Start the model in the prototyper or deploy it only when validation reports no errors.

See MDrivenStart:MDrivenStart Verify for the validation requirement and Documentation:Designer for MDriven Designer documentation.

1. 1. 1. What validation does not prove

A clean validation result means the model is executable. It does not prove that the business rule is correct.

For example, a `Customer` class, an `Order` class, and an association between them can be valid even if the association multiplicity does not match the business rule. If users later clarify that an order must always have one customer, you need to change the model. That is a Think bug discovered through use and review.

1. 1. 2. Code bugs: the declared behavior is not the behavior you intended

A Code bug occurs when the implementation is well-formed but its behavior is wrong. In model-driven development, much business behavior is declared in the model rather than implemented as scattered imperative code. This reduces translation steps between the requirement and the executable behavior, but you must still verify that each declaration expresses the intended rule.

For example, suppose an action should find orders that are ready to ship. If its OCL expression selects all orders instead of only orders in the required state, the expression can be valid while the result is incorrect. The correction is to revise the expression and verify the result against representative model data.

1. 1. 1. Prevent and find Code bugs

1. State the expected business behavior in concrete terms.

  - Example: “Show only orders that are approved and not yet shipped.”

2. Express the rule in the model, such as an OCL constraint, derivation, action, or ViewModel behavior.

  - A **ViewModel** defines the information and behavior presented for a user interface.

3. Test the rule with representative examples.

  - Example data: one approved unshipped order, one draft order, and one shipped order.
  - Expected result: only the approved unshipped order appears.

4. Review unexpected results by checking both the expression and the model data. 5. Keep the model valid after every change.

Use the model as the maintained description of the business behavior. When requirements are expressed declaratively in the model, the declared rule is also the rule you can inspect, execute, and verify. This does not eliminate mistakes in the rule; it makes the rule visible and easier to revise.

For broader modeling guidance, see Model-Driven Architecture and Documentation:Designer.

1. 1. 3. Think bugs: the requirement must change

A Think bug occurs when the application does what the team declared, but the declaration turns out not to solve the real domain problem. These bugs are discovered through feedback from the people who use or own the business process.

For example, a team may define an approval workflow that requires a manager’s approval for every purchase. After using the workflow, users may find that low-value purchases should be approved automatically. The original workflow may have been implemented correctly; the requirement needs to change.

Think bugs are expected in business software because understanding improves as users see working behavior. The practical response is short feedback cycles:

1. Model the current understanding of the requirement. 2. Validate the model and verify the behavior with realistic examples. 3. Let domain users review the working result. 4. Record what the result teaches you about the requirement. 5. Update the model, OCL, actions, or ViewModel behavior. 6. Repeat until the behavior supports the business process.

The goal is not to avoid every changed requirement through a long upfront analysis phase. The goal is to make changes while the model remains the maintained description of the business.

1. 1. Do not misclassify data consistency problems

Some failures are neither ordinary Typing bugs nor Think bugs. A database can contain inconsistent data, which can cause loading or runtime problems even when the current model is valid.

For example, link classes with incorrect link information are especially problematic because a link object requires both connected objects to exist. An inconsistent link can prevent the object graph from loading correctly.

Use the appropriate checks before treating such a problem as an application-rule defect:

- In **MDrivenServer**, go to **Settings -> Admin** and run the available database validation checks. - Review the error report and generated SQL statement to locate the problematic data. - Do not delete rows directly without considering references to those rows. The documented approach is to remove the problematic link value and then use the OCL debugger to delete the now-disconnected object, so related aggregate objects and links are handled correctly. - For database corruption investigation and model-generated SQL, use the model debugger as described in the dedicated documentation.

See Documentation:Validate data in the database for the MDrivenServer checks and Documentation:Database corruption for investigation and correction guidance.

1. 1. A practical triage sequence

When you find unexpected behavior, work through these questions in order:

1. **Is the model valid?**

  - Run **Validation** in MDriven Designer.
  - If there are errors, correct them first. This is a Typing-bug class of problem.

2. **Does the declared rule return the expected result for known example data?**

  - Inspect the relevant OCL, action, derivation, or ViewModel behavior.
  - If the expression or behavior is wrong, correct and recheck it. This is a Code bug.

3. **Is the declared rule still the rule the business wants?**

  - Review the working result with domain users.
  - If the rule must change, update the model. This is a Think bug.

4. **Could inconsistent persisted data be causing the result?**

  - Run the MDrivenServer database checks and follow the database-correction guidance.

1. 1. Related guidance

- Documentation:Designer — MDriven Designer concepts and modeling documentation. - MDrivenStart:MDrivenStart Verify — validate the model before starting or deploying it. - Documentation:Validate data in the database — database consistency checks in MDrivenServer. - Documentation:Database corruption — diagnose and correct database corruption. - Practical Expressions for Model Content Insights — practical expressions for examining model content. - Discovering Business Requirements — starting guidance for new MDriven users. - Model-Driven Architecture — model-driven development guidance.