Hi,
A number of problems with the lack of proper API access to Default Values defined as UML Types (table t_propertytypes) needs a proper API.
The problems involved is described in detail in this post (from the fifth post in the thread) :
http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1448991338/3Although not describing here all the problem involved, there's an absolute need for adding two attributes to TaggedValue with the following functionality:
[size=11]
TaggedValue.Value()TaggedValue.DefaultValue()
TaggedValue.GlobalDefaultValue()[/size]
- DefaultValue() would retrieve what we could call "overridden" Default Values, if any, from the table corresponding to its parents type ( "
t_<element type>
tag"). This value is the value defined as "initial value" of the TaggedValue names when entered as attribute members to Stereotypes in Profile models.
- If no value is present, it returns the Default Value as defined in the table
[size=12]t_propertytypes[/size], or better, from the property
GlobalDefaultValue(). The logical flow would be as follows :
[size=12]
''' TaggedValue.DefaultValue()
Function DefaultValue()
DefaultValue = ""
If ContainsStr(Notes, "Default:") Then
DefaultValue = '// The value to the right of "Default:"
Else
DefaultValue = GlobalDefaultValue()
End If
End Function[/size][size=12]''' TaggedValue.GlobalDefaultValue()
Function GlobalDefaultValue()
GlobalDefaultValue = '// Retrieve from the table "t_propertytypes"
End Function[/size]Now the existing Value() property could have the following implementation:
[size=12]''' TaggedValue.Value()
Function Value()
''' The pseudo property "_Value" here represents the internal storage
if _Value <> "" Then
Value = _Value
ElseIf DefaultValue() <> "" then
Value = DefaultValue()
ElseIf GlobalDefaultValue() <> "" Then
Value = GlobalDefaultValue()
Else
Value = ""
End If
End Function[/size]"Polymorhism"One could think of the approach as TaggedValues a sort of "polyphormism" for DefaultValues, sorts of, which in my case has proven being very very useful. This is when the same UML Types/TaggedValues are used in different contexts, i.e. in different Stereotypes.
Again, see a more detailed description of this workaround/feature in the linked post.
Hide complexityThe above functionality would hide the extra complexity due to TaggedValues having different ways of storing its info for different model element types, for example AssociationEnds, which needs to have the same support as any other group for TaggedValues (in my framework solutions the Role TVs are the most important, but they have the least support in EA).
Model MaintenanceThe complexity of dealing with TaggedValues as EA API works today is a real problem, and when models or UML Types changes, updating the TaggedValues is, well a nightmare. I have no solution for that though, given how the values are stored today, which is an indicator of how this actually can become a showstopper for MDA Framework projects, which I'm into.
PerformanceIn my current (application Framework) model I have over 80 thousand Tagged Values to deal with (from Class, Attributes, Operations, Connections and ConnectionEnds). See the linked post for screenshots of the numbers involved.
Huge models, in turn, indicates that any solutions also needs to regard performance, since code generation from such a model is at risk of taking too long (maximum 1-2 minutes for a 250 classes model).
[edit]
+Code Generation TemplateMoreover, implementing this logic behind the Value() property would also bring the Code Generation Template system back to life, since it would suddenly start give access to the (default) values in TaggedValue system (given that the values of the
[size=12]<element kind>Tag[/size]'s[/color] are actually read from the Value() property)[/edit]
Best regards,
// Rolf Lampa
