NotManagedCause requirements

Submitted by Fabrizio.Paoletti on Monday, 11 February, 2013 - 17:18
Issue ID
UML General
Bug report
Datex stakeholder

we have a need for NotManagedCause to be used to specify any kind of SituationRecord that is not managed directly by a TCC ( which manage its only road competence and may refere to situation record outside competence that could be not available in the TCC system )

causeType is already referring to many situation, but not to all.. so it should be better to model allowing for NotManaged Cause any "SituationRecordClass"Type that has been provided for any different other Classes.

e.g. for needs not covered by current causeType in Italy we adopted such extension no to duplicate "causeType" with other literals and definition already present in other *Type enumeration ( see figure provided )

but probably it should be much better so extend such management to all *"Type" information

besides the previous requirement we need to add extra literals that are not managed by current "ClassType" 

causeTypeEnum add literal

  • hydraulicAdjustment : definition "the adjustment of water in sewer cause of flooding"
  • wearAndTear : definition "the wear and tear of road infrastracture"








Found Version
{"changeLogs":[{"date":1528371989597,"componentOLD":"- Select a value -","component":"UML General","categoryOLD":"- Select a value -","category":"Bug report","priorityOLD":"- None -","priority":"Normal","assignedOLD":"","assigned":"iancornwell (42)","statusOLD":"- None -","status":"Fixed"},{"date":1537269255143}]}

Posted by iancornwell on June 25, 2022 Permalink

The TG discussed on 2 calls and by email. The initial decision was to use a new DetailedCauseType which has an optional attribute for each type enum of a SituationRecord subclass (except the most abstract ones). A 2nd call when checking the result had a minor preference for a set of single attribute specialisations rather than a set of optional attributes in one class. However, further correspondence in the TG reversed that 2nd decision and reverted to the first solution.

So NonManagedCause now has an optional DetailedCauseType which has 27 optional attributes copied from SituationRecord subtypes.

The causeType in NonManagedCause is retained, but has literals removed where those can be expressed by DetailedCauseType values (either with identical literals or literals that clearly map). It also has a bunch of new literals since it previously only matched 2 of the 27 SituationRecord types that can be further detailed in DetailedCauseType, so 25 new literals added, like "roadMaintenance".