Bug 53381 - No stereotype on operations
Summary: No stereotype on operations
Status: RESOLVED FIXED
Alias: None
Product: umbrello
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Umbrello Development Group
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-01-24 19:52 UTC by Jonathan Riddell
Modified: 2015-08-21 19:33 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 3.3.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Riddell 2003-01-24 19:52:53 UTC
Version:            (using KDE Devel)
Compiler:          gcc 2.95 
OS:          Linux

Operations should have stereotypes (as classes etc do).
Comment 1 Jonathan Riddell 2003-08-31 20:49:10 UTC
This is now possible in CVS for operations, attributes and templates. 
Comment 2 Oliver Kellogg 2004-07-26 08:11:37 UTC
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.
Comment 3 Jonathan Riddell 2004-07-26 23:40:19 UTC
>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.
Comment 4 Oliver Kellogg 2004-07-27 20:10:43 UTC
> 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.
Comment 5 Oliver Kellogg 2004-07-28 06:45:33 UTC
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>
Comment 6 Oliver Kellogg 2004-07-30 18:27:54 UTC
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.
Comment 7 Stephan Kulow 2004-07-30 20:27:44 UTC
as long as it's in the same catalogue, there is no problem
Comment 8 Oliver Kellogg 2004-07-31 15:45:06 UTC
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.