Reply To: Class number

homepage Forums BridgePoint/xtUML Usage and Training Class number Reply To: Class number

#5813
micke.x
Member

The inconistency in merged models does not only happen for classes, it exists also for all other auto-numbered properties:
• Class Number
• Association Number
• State Number
• Event Number
It also affects the property “State Machine Event Derived Label”, since this is partly defined by the property “Event Number”, as well as the “Association Name”, since this is based on the Association Number.

The result after Merge is a model with a lot of problem reports such as:
“Found another state under the same state machine with the same state number. InstanceStateMachine.xtuml /MicrowaveOven/models/MicrowaveOven/components/MicrowaveOven/Microwave Oven/Door/InstanceStateMachine MicrowaveOven::components::MicrowaveOven::Microwave Oven::Door::Instance State Machine::new state Problem”

These properties are clearly not designed with parallel development in mind.

If it was up to me, I would have removed all these autonumbered/named properties altogether and changed the action syntax for referring to some of these, such as referring to event name only rather than event derived label – it is a fragile language construct.
I realize that this is not likely to happen…

A more reasonable approach is: the Merge feature (BridgePoint code) has to consider this and renumber clashing numbered properties while Merging, to avoid the inconsistencies and have a smoother Merge.