The Safety View That Finds Zero Elements
A project applies a «SafetyCritical» profile to its model. The stereotype owns a property dalLevel : String with no default value. Twelve blocks are stereotyped «SafetyCritical». Nine leave dalLevel empty. Three blocks do carry 'A' or 'B' - but the values were entered on the instance specifications used for the deployment configuration, not on the blocks themselves. A «view» element named SafetyView is specified against a viewpoint whose stakeholder concern is 'identify all safety-critical elements requiring independent review'; the viewpoint's query selects stereotyped blocks whose dalLevel is A or B. Executing SafetyView returns zero elements, and the team reads that as 'no safety-critical items in this increment'.
1. Diagnose the zero result. Why is an empty query result itself suspect here?
Read the worked answer
The query is asking the right question of the wrong population. It selects blocks, and at block level all twelve have an empty dalLevel: the three A/B values were typed onto instance specifications, which are separate model elements. A query over classifiers cannot see them. Zero results is therefore the correct answer to a badly scoped query.
An empty result should always be cross-checked against a completeness count before it is believed. The model says twelve elements are stereotyped «SafetyCritical»; a safety view that returns none of twelve is not a finding, it is a broken query. The rule of thumb: run the query with the property filter removed first. If that still returns twelve, the scope is right and the filter is the problem; if it returns zero, the stereotype application is the problem.
A second, quieter defect: dalLevel has no default and is unset on nine elements. Any downstream analysis that treats 'unset' as 'not safety-critical' will silently under-report. Either give it a default that means 'unassessed' and make that visible, or make it mandatory.
2. Where should dalLevel live - on the block or on the instance specification?
Read the worked answer
It depends on whether the safety level is a property of the type or of the configuration, and the model must pick one.
- If every flight of this design has the same DAL allocation, it is a property of the block. Put it there; the viewpoint query over blocks then works unchanged.
- If the allocation varies by configuration (a redundant variant, a different mission kit), it belongs on the instance specification, and the viewpoint must query instance specifications instead - and the stakeholder concern should be restated as being about configurations, not types.
The failure mode here is mixed: three elements carry the value at instance level and the view asks at type level. Pick the level, migrate the outliers, and state the choice in the viewpoint's rationale so the next modeller does not repeat it. Do not populate both levels 'for safety' - you then have two sources of truth that will drift.
3. Is a «view» conforming to a viewpoint enough to make SafetyView trustworthy evidence for an independent review?
Read the worked answer
No. A view is a mechanism for selecting and presenting model content against a stated concern; it carries no guarantee that the content it selects is complete or correct. What a reviewer needs in addition:
- A stated selection rule that can be audited, including what happens to elements where
dalLevelis unset. 'Unassessed' must be a visible category, not an excluded one. - Coverage evidence: the count of stereotyped elements versus the count the view returns, so a shrinking view is distinguishable from a shrinking problem.
- The concern traced through: if independent review is the concern, the view should show the reviewer and the rationale that justifies the DAL, not only the letter.
- Configuration control: views over instance specifications are only meaningful when the underlying instance specification is baselined, otherwise results move for reasons unrelated to safety.