Modeling Guide
Knowledge Guides /How to Validate Removal, Unlinking, and Deletion in a Model Editor
Last updated: · New Horizon Digital Outsourcing Team
Removing a diagram symbol, clearing a property reference, and deleting a model element are different operations. Define the affected objects first, then inspect the model tree, other views, relationships, and the reopened project. Button labels or disappearing graphics alone do not establish correct deletion semantics.
Distinguish Representations from Model Elements
- Create a generic example element with a tree entry, diagram representation, and property reference, recording their shared stable identifier. Names may match or change; follow element identity so a recreated element with the same name is not mistaken for the original.
- Define expected effects separately for removing a representation, unlinking a reference, deleting an element, and deleting an owned child. Model ownership and relationship semantics should determine the effects; a shared minus icon does not make these operations equivalent.
Check Selection Scope and Editing Rights
- An element selector should accept only objects that satisfy type, ownership, and cardinality constraints. A parent node used to display hierarchy is not necessarily selectable, and multiple selection should not silently include all children unless that behavior is specified.
- Enforce read-only restrictions where editing commands execute and check consistency across entry points. Define outcomes for clearing an already empty value, deleting with no valid selection, and cross-project references rather than relying on incidental disabled controls.
Follow One Change Across Views
- After removing a representation, check that the element and other views remain as specified. After unlinking, confirm that the referenced element still exists. When deleting an element, inspect the handling of incoming references, owned children, and related views.
- Then undo, redo, save, and reopen, checking element identifiers and relationships for consistency. Checking only the current canvas misses persistence issues and problems in other views; cover the entry points that read the same model state.
Include Failure Handling in Handover
- Use a copy to check behavior with dependencies, interrupted operations, and unsaved changes. Specify when to reject an operation, request confirmation, and restore state. Hiding broken references does not establish successful deletion.
- Deliver operation semantics, a minimal example, and expected-state comparisons, then have the recipient complete an entire editing sequence. These checks establish compliance of editor data handling with the agreement; they do not replace engineering review of the model content.