Issue 6259: UML2 Super / Primitive Types / implementation issue (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: In the UML 2, a primitive type cannot be stored directly in a Property. Instead, the Property has an association inherited from TypedElement with an end called type. This association is not composite so a Property cannot contain its own type. In the case of a complex type such as a classifier, it makes sense that the type is external to the property. But, in the case of a primitive type, it becomes impractical because for each primitive type encountered, we are forced to create a new PrimitiveType object and store the object in some package in the model. There could be an explosion of PrimitiveType objects in a model as new objects are created for "const char", "const char**", "const char **", etc. It would be unclear what model elements, if any, are using these objects. As a proposed solution to this problem, which is inherent to Operation and Parameter as well as Property, an additional composition could be made to PrimitiveType in TypedElement. It could be an optional [0..1] unidirectional composition for this case with a primitive type so that each Property, Operation and Parameter could have access to their primitive type information. Management of these primitive types would be alot easier because they are owned by the element that is making use of them. There is another solution that I have thought of while looking at this problem. All of the necessary primitive types could be referenced from a C++ or Java language model. All of the rest of the modifiers for the primitive type could simply be made available through the use of stereotypes from a C++ or Java profile so that the user could take "int" and add "*" and/or "const" modifiers to the primitive type. But, with this approach, there would have to be common C++ and Java models and profiles so that everyone's model could still be somewhat portable between implementations of UML 2. Resolution: Revised Text: Actions taken: September 19, 2003: received issue March 9, 2005: closed issue Discussion: This short note sketches out two possible solutions to the TypeExpressio ns problem. The latter is the issue of modeling standard C++ declarations that involve pointers and references such as: 1. int * pi 2. int & ri 3. int * * ppi 4. Myclass * pm 5. Myclass * & arpm[5] Before discussing solutions, it is important to note that in a situation where C++ is being modeled for needs such as round-trip engineering, which requires an unambiguous mapping between models and code, a special C++ profile must be defined. The profile is also needed to constrain the general UML semantics to C++ semantics. Hence, both proposed solutions assume that such a profile exists. In addition, both solutions are based on the view that a pointer or a reference to some type is a separate type that is distinct from the type that it is referencing. Thus, a pointer to the type MyClass is a separate type from MyClass. Possible Solution 1 This solution defines a special stereotype of Association for each useful combination of pointer and reference types. For example, the following stereotypes of Association could be defined: «ptr» for * «ref» for & «ptr-ptr» for * * «ptr-ref» for * & etc. In that case, the examples above would be modeled as follows2: «cpp-function» main «primitive» int 1 «ptr» pi 1 «ref» ri 1 «ptr-ref» rpi «cpp-class» MyClass 1 «ptr» pm 5 «ptr-ref» arpm In addition, an alternative text-based notational form (e.g., to be used in list boxes) might be defined for these stereotypes, such as: arpm : «ptr-ref» MyClass [5] which could be expanded to the graphical form shown above. The major drawback with this solution is that it requires a separate stereotype for each possible combination of references and pointers. In most real- world applications, of course, only a relatively small number of such combinations are used implying that only 2 Note the use of the «cpp-function» stereotype to model C++ functions, including the “main” program. This is a stereotype of the abstract metaclass Behavior, which is a subtype of Class. a small number of stereotypes need to be defined. However, there is always the possibility that a given application may use some combination that has not been defined. Another potential problem is the handling of cases of pointers or references to constant types, such as: const int * cpi This could be solved with additional stereotypes such as «const-ptr», although that would increase the number of stereotypes needed. This sub- issue probably warrants further study. Possible Solution 2 This solution is more flexible, but leads to more complex models. It requires the explicit definition of the appropriate pointer or reference types using two stereotypes of the Type concept in UML, «reference» and «pointer»3, and an associated Dependency stereotype «target». The two Type stereotypes would each require exactly one «target» dependency to the appropriate target type. For example, the following two type declarations would be required in a model4: «pointer» *int «primitive» int «target» «pointer» *MyClass «primitive» MyClass «target» «reference» *&MyClass «target» These types would then be used for the following declarations in a model: pi : *int rpm : *&MyClass [5] Given that these solutions exist to the problem, this resolution proposes that this part of the spec remain unchanged. Disposition: Closed, no change End of Annotations:===== ubject: UML2 Super / Primitive Types / implementation issue X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 19 Sep 2003 18:36:53 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 09/19/2003 18:36:56, Serialize complete at 09/19/2003 18:36:56 In the UML 2, a primitive type cannot be stored directly in a Property. Instead, the Property has an association inherited from TypedElement with an end called type. This association is not composite so a Property cannot contain its own type. In the case of a complex type such as a classifier, it makes sense that the type is external to the property. But, in the case of a primitive type, it becomes impractical because for each primitive type encountered, we are forced to create a new PrimitiveType object and store the object in some package in the model. There could be an explosion of PrimitiveType objects in a model as new objects are created for "const char", "const char**", "const char **", etc. It would be unclear what model elements, if any, are using these objects. As a proposed solution to this problem, which is inherent to Operation and Parameter as well as Property, an additional composition could be made to PrimitiveType in TypedElement. It could be an optional [0..1] unidirectional composition for this case with a primitive type so that each Property, Operation and Parameter could have access to their primitive type information. Management of these primitive types would be alot easier because they are owned by the element that is making use of them. There is another solution that I have thought of while looking at this problem. All of the necessary primitive types could be referenced from a C++ or Java language model. All of the rest of the modifiers for the primitive type could simply be made available through the use of stereotypes from a C++ or Java profile so that the user could take "int" and add "*" and/or "const" modifiers to the primitive type. But, with this approach, there would have to be common C++ and Java models and profiles so that everyone's model could still be somewhat portable between implementations of UML 2. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com