Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Paolo F Cantoni

Pages: 1 ... 350 351 [352] 353 354 ... 422
Uml Process / Re: Linking use case scenario objects on a diagram
« on: October 16, 2008, 04:56:27 pm »
In UML, an activity diagram IS an activity object.  Taking bioform's suggestions, you can create a single object that this the activity diagram representing both the main, alternate and exception flows.  This represents the consolidated view of the Use Case.

You can make this the instantiated object.

Then you can create separate activity diagram underneath the consolidated activity and designate them scenarios.  You can copy and paste the diagram from the consolidated views and remove the elements not required for the specific scenario.  If you then Lock these scenario diagrams, you can make them "views" of the consolidated one.  You can then make changes in the consolidated diagram - with all the relevant information to hand.  The scenario views will be updated.

The scenario view diagrams are implicit instantiations of (part of) the use case.

If you REALLY aren't interested in the activity details, leave them diagrams empty.  The structure above still works.

Does that help?

Uml Process / Indicators for AssociationClass
« on: September 02, 2008, 11:49:20 am »
Elsewhere ( I have put forward the proposition that the Association "lozenge" should be regarded as a specific rendering of the Association Class (where the current binary AssociationClass is merely a specific form of the n-ary Association element).

Now, I'm not sure when this functionality came into EA, but as of at least v7.1, when you convert an ordinary class into an AssociationClass, the attached Association also becomes an "AssociationClass" when you open it's properties.

Now this causes confusion for shape scripting - since if I create a shape script, am I attempting to apply it to the vertex or the edge?  However, that's not what I'm discussing here.

It seems to me that when you convert an "ordinary" Class into an AssociationClass - there should be some indication that this has occurred.  Similarly with the linked edge (which appears to have transitioned from Association to AssociationClass).  Now some might argue that this latter transition is a bug, but I'm not so sure.

If the edge and the vertex are both on the same diagram, then EA follows the UML requirement to link them with a Notelink.  However, when both the edge AND the vertex are NOT on the same diagram, it would be useful to have a visual signal that the other (linked) element exists.

Trying to be consistent with my previous pronouncements, it seems to me that the addition of a small lozenge glyph in the top right of the Class and the addition of a small lozenge glyph in the centre of the Association would be sufficient to provide such an indication.  These indicators would mean: "There is another part of the construct that is not shown on this diagram".

What do others think?

Uml Process / Re: what is the definition of Actor?
« on: July 28, 2008, 12:17:36 am »
There was some recent discussion in the forum on this topic.  Have a search within the last month - it should turn up.  You can then extend that.

Interestingly, I've come to the view that "being an Actor" is an aspect (or role) of any arbitrary item in a model.  One could view "being an Actor" as a "rendering" of the item.  So just as in EA we often have a "native" form and "rectangular" form of rendering, we might include "actor" form and "partition" (separate concept) form.

My AU$0.05

Uml Process / Re: Composite state with concurrent regions
« on: May 23, 2008, 01:55:11 pm »
So if you're going to be buried outside of Minnesota, will that involve taking the intestate interstate?
Yes, but if you're pronouncing in American, you might have been saying the "innerstate innerstate" so we wouldn't understand you anyway...

But it WAS good!


Uml Process / Re: Association Roles vs Attribute Name
« on: May 05, 2008, 05:37:18 pm »
But associations give you a clearer picture of how classes relate to each other. Taking them out in PSM would not be of much help, I think.
I agree...

IF they were just two renderings of the same fact, you could render them at will... [  ] Show Attributes only,  [  ] Show Associations only,  [  ] Show both Attributes and Associations

It could get more flexible than that - but that would be a start...

Uml Process / Re: Association Roles vs Attribute Name
« on: April 18, 2008, 02:06:04 pm »
I meanwhile reached the surface to look over this. I have a quite simple problem here. Why should one declare an Attribute AND create an Association named with that Attribute? Isn't it that naming the end role of an association makes this an attribute per se? If so (and it seems logical to me) then why am I offered attribute names in the end role drop down? What would be the reason to do that?
Yes you are correct.

Since the original posting, I've come to the view that we need to see the attribute and the association as two renderings of the same "fact".  Consequently, the user should be able to decide (on an attribute specific basis) whether to show the attribute, the association or both.  Changing one should change the other!


Uml Process / Re: Association Roles vs Attribute Name
« on: May 29, 2006, 10:08:34 pm »
Interesting - I don't think this is wrong.  Consider a type hierarchy - you may want to model the association at various  levels of the hierarchy for some arcane purpose.

I do that by creating derived Associations (again, not directly supported by EA).  The attributes are therefore also derived.

However, that isn't the case here.  They are to different Classes altogether.

Uml Process / Re: Association Roles vs Attribute Name
« on: May 29, 2006, 08:06:17 pm »
[glb]WARNING WARNING WARNING - Will Robinson![/glb]

I've just discovered that you can have multiple Associations mapping to the SAME Attribute!

This surely is WRONG?

Needs to be fixed!


Uml Process / Association Roles vs Attribute Name
« on: May 29, 2006, 02:32:01 am »
It seems to me that there is some functionality missing from EA regarding the mapping of Association Roles to Attributes and vice versa.

In another post, I've noted a BUG wherein the Features are not spell checked.  Consequently, even if the Association Role was originally synchronised with the Attribute, it can get out of synchronisation due to this bug.

However, when I tried to get around the problem by resetting the Attribute name manually, the "linked" Target Role did not change!

How do I know it's linked?  Well, EA provided me with a drop-down for this purpose.

Now, I know I can override this name with my own, but if I don't, aren't I implicitly requesting the link?

What EA didn't do was to formalise that linkage.

UML specifically states that a named, navigable, Association role IS an Attribute.  So, notwithstanding that EA doesn't directly implement this, it should still maintain the name linkage.



Uml Process / Re: Circle notation for interfaces
« on: February 21, 2008, 01:42:28 am »
So the lollipop is actually a representation of a derived association between the component and an interface realized by itself or its parts.
In my opinion that should not be a separate element. I even think that the list of interfaces for which you can make a "mini-lollipop" should be limited to the interfaces that are actually realized by the component.

Hope this makes some sense :-/

I think we may be in violent agreement (at least that the "exposed" interface is not an element in and of itself...)

From your OMG quote, the reason why the edge changes from dashed to solid is that it is a derived association... Hence visualizing as a Lollipop.


Uml Process / Re: Circle notation for interfaces
« on: February 20, 2008, 09:41:11 pm »
Resuming ...

OK so far?

If so, then on the browser, I should get a "link" to the interface - not a new element which isn't an interface, and if I really want the realization, I use the relationships window.

EA has a related and similar problem with the (IMO) incorrect implementation of the "Assembly" between required and provided interfaces.

The diagram may look OK, but the underlying model is flawed and "(from which it is a pain in the b... to navigate to the actual interface)"



Uml Process / Re: Circle notation for interfaces
« on: February 20, 2008, 09:40:36 pm »
I'm sorry Paolo, but I'd have to agree with Roy. According to my interpretation the circle/solid line is a valid representation of a class realizing an interface.
As far as I can see EA handles this correctly.
Yes Geert, I'm no longer disagreeing with that.  My point is now more related to the "Strangeness" of the Exposed Interfaces you mention below...
I do agree that there is something strange with the "exposed interfaces". They seem to have the same representation on the diagram (albeit smaller) but for a "provided" interface there is an element added to the model tree. (from which it is a pain in the b... to navigate to the actual interface) Maybe I should dig a little deeper in the OMG specs to find out the specifics of these "exposed interfaces"
By all means check the OMG specs, but I'm arguing from "first principles".  If you have an interface and its instantiating class on a diagram and the realization edge between them, then (if rectangular notation is used) you get a dotted realization and if circle notation is used the realization becomes solid - producing a "Super-sized lollipop".  My point is that this supersedes any "mini" lollipop's for that interface on the diagram.

If you agree thus far, then it follows that if I get properties on the circle, I get the Interface properties and if I get properties on the line I get the realization.  Consequently it should follow that if I delete the interface from the diagram, I should get a mini lollipop on the class.

If I get the mini-lollipop on the class, I should be able to get the properties of the interface and realization by selecting the appropriate parts of the lollipop.

OK so far?

Break for 2000 Charactrers!  SHEESH!

Uml Process / Re: Circle notation for interfaces
« on: February 13, 2008, 09:34:34 pm »
No, I'm sorry Paolo, but Figure 7.55 distinctly shows the interface ISensor (ball) attached to the Classifier ProximitySensor (rectangle). On page 88 (in my copy of the spec, probably 90 in yours; I have the 2007/02/05 edition) there are illustrations of the alternative notation of the interface ISensor, i.e rectangular notation (figure 7.57) with your expected dotted-line realization.

I accept what you say - and in the intervening time have updated the post a couple of posts back.  See Edit 1 and Edit 2.

But... Since "pieces of paper" don't have behaviours of themselves, it's not clear whether the "balls" represent an actual element or are merely in "loco elementis" (in place of).  

If they are the actual element, then EA's rendering is flawed since one can't select the "lollipop" and observe the referred interface's properties.  If they are merely graphical representations, then there should be no additional representation if the thing represented is already present on the diagram.

This is why consistency is SO important - it is NOT possible to argue correctness about an inconsistency!


Uml Process / Re: Circle notation for interfaces
« on: February 13, 2008, 09:16:35 pm »
As to the specification, there are two versions: with and without change bars. The page numbers differ. Perhaps that is the alignment issue.
Yes, probably - mine has change bars -maybe we should use section numbers...


Uml Process / Re: Circle notation for interfaces
« on: February 13, 2008, 08:54:11 pm »

And another quote from page 87 of the UML Superstructure Specification (2.1.1):

"The interface realization dependency from a classifier to an interface is shown by representing the interface by a circle or ball, labeled with the name of the interface, attached by a solid line to the classifier that realizes this interface.
Well, my copy of 07-02-03 2.1.1 Superstructure has that quote on page 89 (simple typo?). BUT more importantly relates to the use of the ball notation for the realizing classifier - not the interface itself.  It specifically refers to Figure 7.55 - which illustrates this and was left off your quote - no criticism, just observation.  EA does this correctly (as far as I can tell).

That is NOT the behaviour I'm referring to.  Create and interface (Rectangular notation, add a Realize relationship from a Class and then change the rendering of the Interface to circle.  That's what I'm referring to!

Again, I state that as far as I can (easily) see, there is NO reference to representing an Interface element itself as a Circle (using Circle notation - as described in EA's Help) within the UML 2.1.1 specification.

If you argue (and as far as I can see this is a valid argument) that the solid line is to simulate the effect of Figure 7.55 with separate elements, then the "mini" ball notation should be removed from the realizing classifier if the realized interface is on the same diagram - which EA currently does not do.  So something's crook (inconsistent) in the state of Denmark.

I'll settle for the solid line if the mini-lollipop is removed when the actual interface element is on the diagram!
[Edit 1: BTW - the same applied to the required interface socket!  Don't show if the actual interface element is on the diagram.]
[Edit 2: Oh and while we're at it... if the ball and the socket of the interface relationship are BOTH on the same diagram, the connecting dependency should also be rendered (by default) - I can remove it later if I want, but is should be there initially.]
[Edit 3 (David, the safety valve is starting to vibrate!)  What gives with the Expose Interface functionality?  It adds yet another element (for an existing interface) when it should clearly just reuse the existing one!  If you define a new interface then EA should create the interface element and the corresponding Realization or Dependency!]

Paolo [Edit 3 - going for a walk to settle the ranting function...]

Pages: 1 ... 350 351 [352] 353 354 ... 422