Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: Paolo F Cantoni on May 16, 2006, 10:01:32 pm
-
I've installed the BPMN MDG add-in and I'm underwhelmed. :(
So, just to make sure it's not a case of user error (there seem to be some tricks to getting the BPMN add-in working properly) I thought I'd check if it's installed properly.
There are 2 new folders in the All perspective: BPMN Core and BPMN Types.
The BPMN Core folder contains:16 items
The BPMN Types folder contains:7 Items
Is this all I should see?
When I compare the EA contents with: BPMN Fundamentals (http://www.bpmn.org/Documents/BPMN%20Fundamentals.pdf)
There seems to be a lot lacking...
There I was, getting all excited about using BPMN and...
Paolo
-
Hello Paolo,
The presentation of the core types depends on tagged values.
For example: add a StartEvent to a diagram and modify the Trigger tag to Message, the presentation will change to the message marker.
HTH,
Ash
-
Hello Paolo,
The presentation of the core types depends on tagged values.
For example: add a StartEvent to a diagram and modify the Trigger tag to Message, the presentation will change to the message marker.
HTH,
Ash
Thanks for that Ash...
A polite way of saying user error through not reading the Help... :-[
Could there be a way of on initial load of the MDG add-in, the user could be heavily encouraged to read the Help file? Something along the lines of:
This MDG Add-in uses extended mechanisms to implement the BPMN elements. To save you time, energy and embarrassment downstream, it is strongly recommended you peruse the help.
However, why is the Intermediate Event default a Message?
Paolo
-
However, why is the Intermediate Event default a Message?
I think you'll have to ask the BPML people that one, as it sure appears as a message in most of their e_lit.
bruce
p.s. I also get the gist that intermediates aren't really a good thing to concentrate on BPML-wise. They appear IMO to be virtuals introduced to cope with BPML constraints rather than benefits.
-
Could there be a way of on initial load of the MDG add-in, the user could be heavily encouraged to read the Help file? Something along the lines of:
This MDG Add-in uses extended mechanisms to implement the BPMN elements. To save you time, energy and embarrassment downstream, it is strongly recommended you peruse the help.
Or maybe pop up a dialog on dropping an event to allow the user to pick which type of event is wanted? That is certainly do-able.
-
The Event Type appears to be in two places: The Stereotype (such as EndEvent) and in the Tagged Value (EventType:End)
If I change the Stereotype, the Tagged Value doesn't change. And I can't change the Tagged Value at all!
This is a defect isn't it?
Paolo
-
Or maybe pop up a dialog on dropping an event to allow the user to pick which type of event is wanted? That is certainly do-able.
Yes, KP that would be my preference, but I wasn't sure it was doable easily.
Nevertheless, I still think the installer should prompt to read the help.
Paolo
-
:) Sorry, hope my post didn't come across as patronising :X
I think a little message really is a good idea...
We'd love to make good initial impressions; feedback is welcome.
Ash
-
:) Sorry, hope my post didn't come across as patronising :X
'Course not... See how I cleverly gave myself the out by acknowledging the possiblity of user error... ;D
Paolo
-
:) Sorry, hope my post didn't come across as patronising :X
I think a little message really is a good idea...
We'd love to make good initial impressions; feedback is welcome.
Ash
I like what I see so far myself. The only issue I have is the text description for the start and end events do not obey my commands. (Infidels!) I can move/resize the text area to get it to look nice and my diagrams look great. But once, I close the diagram and reopen it, the text is back to the default formatting. This is especially annoying when I put in a fairly long description.
-
John,
My guess is that this is the result of the underlying Shape Script not resizing dynamically. Given that we still await complete and correct documentation of the scripting language, and that it may be extended by then (with EA 6.5 on the horizon), this is probably the best you can do for now.
I've been hoping that the "preferred" part of "preferredHeight" and "preferredWidth" indicated support for dynamic resizing in cases such as this. I don't think it does.
You could, at the risk of breaking things when you exchange models with outside users, do something like adding a tagged value for longer text. This might allow you to test for the tag and increase (or decrease) the size of the shape accordingly. Of course you'd have to test to see if this would work, and how far the script would let you take things. And of course you'd also have to report back to us...
David
-
John,
My guess is that this is the result of the underlying Shape Script not resizing dynamically. Given that we still await complete and correct documentation of the scripting language, and that it may be extended by then (with EA 6.5 on the horizon), this is probably the best you can do for now.
I've been hoping that the "preferred" part of "preferredHeight" and "preferredWidth" indicated support for dynamic resizing in cases such as this. I don't think it does.
You could, at the risk of breaking things when you exchange models with outside users, do something like adding a tagged value for longer text. This might allow you to test for the tag and increase (or decrease) the size of the shape accordingly. Of course you'd have to test to see if this would work, and how far the script would let you take things. And of course you'd also have to report back to us...
David
You are way ahead of me David. I am not editing any of the scripting myself. (Not sure if I know how to if I wanted to). My mouse is the only tool I use to move/resize the text.
-
You are way ahead of me David. I am not editing any of the scripting myself. (Not sure if I know how to if I wanted to). My mouse is the only tool I use to move/resize the text.
Ack. Artifacts have the same problem :(