Source: Model Driven Solutions ( Ed Willink)
Consider the example in Fig 11.37 that is supported by the OCL navigation aBank.Person[accountNo].
The nested Property is novel but avoids any bias as to whether the keys are actually part of e.g. a HashMap in Bank, or a linear search in Person. Seems good, but...
How does aPerson discover their accountNo? Oops need to do a total content search of the Bank. Or provide duplicate Person::accountNo state with all the hazards that duplicate state entails.
How can two qualified associations share the same qualifier? Can't it's Composed. Need yet more state duplication.
If instead, Property::qualifier was not Composed, many qualified associations can refer to a Property that can be a regular unnested Property that can be navigated as aPerson.accountNo. Although the now regular Property appears hosted by the target, there is no prohibition on an implementation using a HashMap and locating it in the source, iff all required forms of access are supported.
Reported: UML 2.5 — Wed, 13 Apr 2016 21:37 GMT
Updated: Thu, 14 Apr 2016 19:31 GMT