Version: 1.3.1 (using KDE KDE 3.3.1) Installed from: Debian testing/unstable Packages OS: Linux It would be nice if an actor can be created and handled as a class. This makes it possible to modell a class for automated testing purposes. Also helpful if object lifetimes depend on the actor's actions.
Candidate for JJ (Junior Job.) Make a class with stereotype <<actor>>.
(In reply to comment #1) > Candidate for JJ (Junior Job.) Make a class with stereotype <<actor>>. I want to patch this bug but i dont understand what you want. Can you please explain it
I agree with Tumul. This is a 2005 candidate for junior job, but there is no clear description of what needs to be done or if this is even needed nowadays.
(In reply to comment #0) > > It would be nice if an actor can be created and handled as a class. This > makes it possible to model a class for automated testing purposes. Also > helpful if object lifetimes depend on the actor's actions. On second thought, it's not clear to me anymore what the intention was. My best guess would be: Dragging an Actor from the Use Case View to a sequence diagram, which has been implemented for years.
Created attachment 86289 [details] actor (class) instance on sequence diagram The rational I can imagine is that a dragged actor on a sequence diagram is handled like an object widget. The actor name becomes the class name and you can give it an object name. Also you can send messages to it (see the screenshot), but it is not listed in the tree view as a class, which is done on adding normal object widgets nor the message name could be set or selected.
(In reply to comment #5) > Created attachment 86289 [details] > actor (class) instance on sequence diagram > > The rational I can imagine is that a dragged actor on a sequence diagram is > handled like an object widget. The actor name becomes the class name and you > can give it an object name. Also you can send messages to it (see the > screenshot), but it is not listed in the tree view as a class, which is done > on adding normal object widgets nor the message name could be set or > selected. Thanks for your comment, Ralf. If it's imaginable then it's not a WONTFIX :)
(In reply to comment #1) > Candidate for JJ (Junior Job.) Make a class with stereotype <<actor>>. On the grounds of Ralf's interpretation (comment #5) I'm not so sure this qualifies as a Junior Job.
For the record I collected the callstack of both implementations: A. ObjectWidget creation from toolbar 0 ObjectWidget::ObjectWidget objectwidget.cpp 64 0x5acbcd 1 Widget_Factory::createWidget widget_factory.cpp 135 0x5bb246 2 UMLScene::slotObjectCreated umlscene.cpp 627 0x6376ab 3 UMLScene::qt_static_metacall moc_umlscene.cpp 109 0x441a48 4 QMetaObject::activate(QObject*, QMetaObject const*, int, void**) /usr/lib64/libQtCore.so.4 0x7ffff57f9d68 5 UMLDoc::sigObjectCreated umldoc.moc 166 0x60f2c0 6 UMLDoc::signalUMLObjectCreated umldoc.cpp 1649 0x60f2d5 7 Object_Factory::createNewUMLObject object_factory.cpp 149 0x5f1f13 8 Object_Factory::createUMLObject object_factory.cpp 229 0x5f2290 9 ToolBarStateOther::mouseReleaseEmpty toolbarstateother.cpp 84 0x5fe541 10 ToolBarState::mouseRelease toolbarstate.cpp 127 0x5faff6 11 QGraphicsScene::event(QEvent*) /usr/lib64/libQtGui.so.4 0x7ffff4f464e0 .... B: drag and drop Actor on sequence diagram 0 ObjectWidget::ObjectWidget objectwidget.cpp 64 0x5acbcd 1 Widget_Factory::createWidget widget_factory.cpp 76 0x5bb049 2 UMLScene::dropEvent umlscene.cpp 833 0x637a93 3 QGraphicsScene::event(QEvent*) /usr/lib64/libQtGui.so.4 0x7ffff4f465d0 ...
(In reply to comment #8) > For the record I collected the callstack of both implementations: > > A. ObjectWidget creation from toolbar > [...] > B: drag and drop Actor on sequence diagram > [...] Perhaps I misunderstood. Are you saying that this PR can be closed?
(In reply to comment #9) > (In reply to comment #8) > > For the record I collected the callstack of both implementations: > > > > A. ObjectWidget creation from toolbar > > [...] > > B: drag and drop Actor on sequence diagram > > [...] > > Perhaps I misunderstood. Are you saying that this PR can be closed? no, the mentioned backtrace should be a hint how the difference calls are be performed. Unfortunally the Actor exits already as UMLObject and recreating as "class" UMLObject results into a name clash because it will have the same id.