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 ... 351 352 [353] 354 355 ... 422
Uml Process / Circle notation for interfaces
« on: February 13, 2008, 07:27:27 pm »
The EA Help says:

"Interfaces are drawn in a similar way to a Class, with operations specified, as shown below. They can also be drawn as a circle with no explicit operations detailed. Use the right-click context menu option Use Circle Notation to switch between styles. Realization links to an Interface drawn as a circle are drawn without target arrows."

In a(n admittedly quick) search of the [size=13]UML 2.1.1 Superstructure (formal)[/size] Specification, I couldn't actually find any reference to "Circle" notation for Interfaces.  I think it predates UML.

Anyway, my question relates to the second part of the quotation above: "Realization links to an Interface drawn as a circle are drawn without target arrows"

What it DOESN'T say is that the actual Realization edge is also drawn as a solid rather than dotted line.  This makes it look like an Association.

On that statement, I would have expected the edge to remain dotted.

So, is it an inconsistency in the help or the product?


Uml Process / Re: Feature Question - Display Inherited Use Case
« on: December 17, 2007, 10:01:25 am »
Hi Paolo,

Not sure that I follow.

Are you saying that it's possible to include on a use case diagram the links (between actor and use case) that are purely inherited ?

If so how ?

Thanks and regards,
Unfortunately, by manual labour... (or an add-in, or by direct DB injection).  Unfortunately it's not namtive...

If generalized actor is a distraction, "you pays your money, you takes your choice".

Sorry couldn't be more help...

Uml Process / Re: Feature Question - Display Inherited Use Case
« on: December 17, 2007, 04:35:15 am »
I would like to show the use case links for a given specialized actor. These links are both explicit links and inherited links.
Hi Dave,

We do this by using the derived property.  The inherited links are shown as derived by inheritance (stereotyped «inherited»).

Via bruce's point, it would be good if EA showed the parents for actors as It does for classes.  you might find that Rectangular notation for the actors may actually show them.


Uml Process / Re: members in class diagrams
« on: December 11, 2007, 01:31:51 pm »
Firstly Aggregation & Composition are generalisations of Associations.
Hi Martin,

Aren't they Specializations of Association?


Uml Process / Re: Non-unique indexes
« on: November 30, 2007, 03:08:13 pm »
OIC!  Thanks Paolo.

Humm...I don't even like the way concatenated indexes appear on a diagram.  You get the data types of the columns, but not their names.   UI to set this up is not very intuitive either. EA's help file is silent on all of this too. ::)

Another opportunity for Sparks to excel! :)
Use the diagram properties to change the display to name only.  I've already suggested to Sparx this should be the default for Data Model diagrams.


Uml Process / Re: Non-unique indexes
« on: November 29, 2007, 08:32:57 pm »
What am I not understanding?  Are we going for something that the code generator will understand?


What's currently missing is the ability to create a concatenated index where each column can be individually set as ascending or descending.

Termination_Index(TerminationDate (desc), SurrogateKey (asc))

At present you can only apply ascending/descending to the entire concatenated key.


Uml Process / Re: Non-unique indexes
« on: November 09, 2007, 06:50:38 pm »
Also, in OpenEdge databases each index component can be flagged as ascending/descending and Abbreviate (allows for partial field matches without LIKE -- a deprecated feature), but I don't see any way to flag these in the parameters dialog unless it would be via a stereotype.  Is that what you would do?

this is one aspect of DB indexes that EA does NOT support (as of {818})


Uml Process / Re: Requirement->Use Case->Activity Diagram
« on: November 14, 2007, 02:50:42 am »
You've hit the nail on the head, Tony!

From the activity if you can't transitively locate the exact set of requirements you implement, then you have to do it directly (in addition to the n:1:m mapping).

You could create a small automaton that could follow the links back, provide you with the set of requirements it found from your n::1:m mapping and then create the ones you selected for you...


Uml Process / Re: Requirements model
« on: November 06, 2007, 08:26:00 pm »
Hi Jim,

that's our understanding here...

Following some further discussion, we've concluded that:

You can view  EA Constraints (that which I, alone, must uphold) as Requirements specific to an element and  EA "Internal Requirements" aka Responsibilities as Features (that which I, alone, do) specific to an element.


Uml Process / Re: Package Structure
« on: November 05, 2007, 11:39:14 pm »
[size=13]Packages, Namespaces & groupings[/size] has additional, related information.


Uml Process / Re: Package Structure
« on: August 23, 2007, 02:40:21 pm »
You're correct, it won't work for forward synchronization and the 'Package Per Namespace' option in the Directory import will move it.
Then... Could we have a proper fix please?

We already have higher level packages that AREN'T namespaces.  We just need lower level ones also!

Since EA now indicates the namespace root, it could be extended to indicate those packages that aren't namespaces also - whether by stereotype (or preferably by property).

The default value would be (*) Participates in Namespace (  ) Container/Grouping only

[size=0]©2007 Paolo Cantoni, -Semantica-[/size]

Uml Process / Re: Package Structure
« on: June 25, 2007, 04:00:38 pm »

What type of physical container?
Take your pick from anything in tObject - that is, an Element.  Diagrams exist in tDiagram and are not elements, packages exist in tPackage and have an equivalent tObject.  Anything in tPackage can only have a tPackage as a parent.  Anything in tObject (but not also in tPackage) can have another tObject as a parent (so long as it's not a (t)Package).

We typically use Components and Artifacts (depending on need) - but that's purely a convention (with some grounding in reality).  For pure grouping purposes we use node elements (merely because it "sounds" reasonable).  As I mentioned previously, they aren't "physical" but just group elements under them - so we stereotype them accordingly.

Does that help?

Uml Process / Re: Package Structure
« on: June 25, 2007, 01:38:32 pm »
Reading the specifications seems like the long road to enlightenment!
Or madness!

However, as I see it you have two problems:
1) The conceptual problem of how UML allows you to group things together.
2) The practical problem of how EA allows you to group things together

As you suggest, diagrams are an implicit way of grouping things - Diagrams don't actually exist in the UML specification.

We found we had to play with a number of combinations then came to the conclusions we did.  For our purposes it's the lesser of a number of evils - but doesn't provide us with what we really need.  It really does depend upon your specific needs.

The problem is compounded somewhat because EA doesn't allow classifier features (such as operations and attributes) to be first-class citizens on diagrams.  In addition, you can't see the items in a diagram in the browser - only on the diagram itself.


Uml Process / Re: Package Structure
« on: June 25, 2007, 12:32:39 pm »
For starters, I will admit that I am still a bit fuzzy on when to use Package and when to use component, as both seem to have the same properties.
Join the club Thomas!  However, our reading of the [size=13]UML 2.1.1 Superstructure (formal)[/size] Specification is that packages are essentially namespaces and as consequence are containers.  Elsewhere we've (not the "Royal" we -  but a number of us) argued for grouping packages that don't generate namespaces (but below the namespace root).  At present we use a stereotyped "node" for this purpose - since you can't place a package under a non-package (in EA).

If we have a physical container of some kind (such as the output of a compilation unit), we use more "physical" elements than packages as the container.  There seems to be a conflation of concepts in the UML "Package".  This may be because of historical accident.


Uml Process / Re: Multiple inputs on a provided interface
« on: October 23, 2007, 05:16:01 am »
How does one represent several components using a single provided interface on another component? Just multiple arrows to the ball?
Yes, that's how we normally do it...

If you look at the [size=13]UML 2.1.1 Superstructure (formal)[/size] Specification, you'll see you should also be able to do it via Assemblies, but EA doesn't yet support this.


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