Community
Participate
Working Groups
The request is based on some experience with extended profiles. I'll describe the following: 1. The need for "extensible enumeration types", which we call lookup tables. 2. The need for core support as opposed to extended profile (sterotypes) 3. Description of the proposed facility 4. A temporary workaround that would allow us to live until full support is implemented 1. Extensible enumeration We have seen our users require the ability to bind literals/values to enumerations later than expected. That is: some enumerations are bound to literals or values only when the designed system is in production. For example, an event handling application that is based on an events/alarm model uses a notion of "event type". By nature this is an enumeration type. In different deployment/production environment the population of event types differs greatly. It is, then, desired to allow the loading of literals and values into the enum type when a system is deployed (and not as static enum type in the model). Such feature would allow validation of assigned literals, values as if they were entries of a legitimate enumeration. This is the desired behavior. 2. In our implementation we defined a stereotype <<Lookup>> that can be applied to enumeration types. When such artifact is encountered by the code generator, the latter knows to NOT generate a native enum (such as a Java artifact) but to use a dedicated implementation that support the type. This works fine and answers most of the requirement... BUT: If an entity contains an attribute that has a <<Lookup>> datatype it cannot be fully supported on an instance diagram. Because the core primitive is still enumeration type, it is so handled by the instance diagram. Because no literals are defined (they are not bound yet!) there is no way to illustrate usage of this attribute in an instance diagram. Note that this cannot be helped by enhancing the generators because they are not at all involved in this phase -- instance diagram is a core feature and does not depend on artifacts generated from the model. 3. Proposal We wish to add a core primitive type to implement the extensible enumeration behavior as described above. Let's call this LookupEnum. When a LookupEnum is added, a new native type is created. The instance diagram support should allow two things: first, an actual lookup table should be creatable. Similarly to how datatype instances are created, I should be allowed to drag an instance of LookupEnum onto the diagram and define literals and values. Now, in the instance of the owning entity I should see a drop-down that contains the definitions for this type. 4. Brute force temporary hack Given that the design and development of this feature is expected to be tricky we at least request that an enhancement is made that allows typing into attributes of enumeration types strings. This will, at least, allow us to create meaningful instance diagrams even without the full support as described above. Cheers! *Yoram
