Version: (using KDE Devel) Compiler: gcc 2.95 OS: Linux Operations should have stereotypes (as classes etc do).
This is now possible in CVS for operations, attributes and templates.
Hello Jonathan, On attempting to fix bug 71969, I notice that we now seem to have two competing schemes in Umbrello for handling stereotypes: The UMLObject has a member QString m_stereotype, and then there is class UMLStereotype. Could you please clarify the difference? Thanks.
>On attempting to fix bug 71969, I notice that we now seem to have two >competing schemes in Umbrello for handling stereotypes: The UMLObject > has a member QString m_stereotype, and then there is class UMLStereotype. My understanding at the time from the UML specs was that class items (attiributes, operations etc) were not individually stereotyped but were stereotyped by groups, hence why you can insert stereotypes into classes in much the same way as you can insert an attribute/operation etc. That was probably wrong, I'm happy for the UMLStereotype stuff to be taken out and each attribute or operation have a stereotype displayed alongside.
> I'm happy for the UMLStereotype stuff to be taken out and each attribute or operation > have a stereotype displayed alongside. Thanks for clarifying. IMHO this boils down to the question of whether to collect all stereotypes into a globally available list (for example in a drop-down menu), or whether to require the user re-type the stereotype at each desired usage. Even if we decide in favour of the global list, I think a simple QStringList should do - the class UMLStereotype is probably overkill for this application.
Oops, I need to correct myself. The XMI standard calls for the <UML:Stereotype> element. The stereotype attribute given at other elements is only a reference to the xmi.id of the UML:Stereotype. For an example, see http://www.jdev.de/html/projects/uml2daml/mapping/uml2daml_mapping.html : <UML:Model xmi.id = 'S.1' name = 'Project' visibility = 'public'> <UML:Namespace.ownedElement> <UML:Package xmi.id = 'S.3' name = 'PackeWithEmptyClass' visibility = 'package' isSpecification = 'false' isAbstract = 'false'> <UML:Namespace.ownedElement> <UML:Class xmi.id = 'S.8' name = 'EmptyClass' visibility = 'public' isSpecification = 'false' isAbstract = 'false' isActive = 'false' stereotype = 'XX.1'> </UML:Class> </UML:Namespace.ownedElement> </UML:Package> <!--==================== DAMLClass [Stereotype] ====================--> <UML:Stereotype xmi.id = 'XX.1' name = 'DAMLClass' visibility = 'public' isSpecification = 'false' icon = ''> <UML:Stereotype.baseClass> Class </UML:Stereotype.baseClass> </UML:Stereotype> </UML:Namespace.ownedElement> </UML:Model>
After looking at the code, in particular cvs diff -r1.8 -r1.9 classifier.cpp, I'm afraid the fix is not right yet. Stereotypes are not UMLClassifierListItems as they have no right-of-existence as standalone items. Instead, I have changed the handling so that each UMLAttribute/ UMLOperation/etc. has its optional UMLStereotype. The commit of this change depends on whether we are allowed to move i18n strings between files.
as long as it's in the same catalogue, there is no problem
The stereotype is now a property of each individual operation/attribute/template. However, the one and only _owner_ of UMLStereotype instances is UMLDoc. UMLStereotypes are now reference counted - it is usually the case that more than one model item uses the same stereotype.