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 ... 353 354 [355] 356 357 ... 391
Uml Process / Re: Associations vs Dependencies vs Attributes
« on: April 09, 2005, 10:40:40 pm »
Hi all,

The issue is further compounded by the fact that the UML2
Infrastructure document specifically states (correctly) that a
navigable association with a role IS an attribute.  (Geoffrey,
did you see this?)

At our site, which currently uses another tool, we have created
our own generators.  We have created composite associations
(with stereotype: <<attributive>>)for each attribute that
references another class (as opposed to a simple datatype).  
Multiplicity is set appropriately at both ends.

Further, to aid visualization and to cross check the model, we
create a dependency (stereotype: <<attributive>>) between the
dependent (home) class and the independent (referenced) class.
We set the multiplicity of the dependency to the number of
attributes that reference the class, and the name of the
dependency (not normally used) to the list of names of the
attributes implying this dependency.

By automating this process and then automatically creating
automata that traversed the model and drew diagrams under our
control we were able to "see" the model in new ways.

Once we started doing this, anomalies in the model suddenly
started to be "in your face"!


Uml Process / Re: Standardising Classifier adornments
« on: May 09, 2005, 07:25:40 am »
I would like a caveat though - I, as the boss honcho
around here want the ability to constrain the monkeys down the
tree from using "pretty" but non-compliant replacement icons,
replacement boxes and TRHC icons unless I SAY IT'S OK both at
the project and diagram level!


I think this is a straight forward security issue.  You should
probably start a separate thread.  Although I suspect there
could be a general pattern that could be pretty universally
applied to EA elements.

You point about "down the tree" is well taken.  It seems to me
there ought to be the equivalent of Cascading Style Sheets for
element adornments. As you specialise stereotypes you could
maintain some degree of adornment consistency - something like
the way MS Word manages style hierarchies.


Uml Process / Re: Standardising Classifier adornments
« on: May 09, 2005, 03:15:51 am »
p.s. Paolo - have you seen a spell checker for Firefox?

I believe GNU ASpell can be made to work, but I don't know that for sure...  Look on the site.  If you find one, let us all know as I'm seriously thinking of Firefox.

(I'll reply to the rest in a separate post)


Uml Process / Standardising Classifier adornments
« on: May 09, 2005, 12:54:12 am »
Bruce (Sargasso), in a private message, concerning another post of mine,
made the following comment (which he has permitted me to quote):

I spend, I reckon, at least a day on each project telling
modellers not to use their own ideas of what's beautiful and
meaningful - and then hacking into the EAP repository to cut out
their beautiful pictures when they ignore me and do it

Bruce, here, is talking about the ability to replace the entire
model element (typically a shape only - why?) with an image.
Thus for the actor stereotype we replace the box with a "stick

One of the functions of the model is to communicate, and from
time to time in the past I've used this technique to better
communicate some concept or other to the "punters" - the
stakeholders, users, management, development teams etc.

However, if you observe the UML specifications carefully, you'll
see that "all boxes are equal - but some are more equal than
others".  Some boxes are lucky enough to have icons in their top
right hand corner - Component for example.  I can't quickly see
other examples - and I can't use EA as it isn't always UML
compliant here.

It seems to me that all classifiers should have the ability to
be adorned with icons in the top right hand corner.  Thus, for
example, a boundary entity should have a number of rendering
modes:  Plain "box", Plain box with icon in top right, Icon
replaces box.

We can then extend this to the application of stereotypes, we
can then get:

Standard or icon adorned box with «stereotype» added as text,
Standard or icon adorned box with «stereotype» images added as
icons in top right (or perhaps top left), principal «stereotype»
image replacing box with subordinate «stereotype» text
adornment, principal «stereotype» image replacing box with
subordinate «stereotype» images added as icons (as above).

In this way, we can (possibly) better communicate the
application of multiple stereotypes to a model element.  I
believe multiple stereotypes will become increasingly more
useful as people discover they are possible (compared to single
stereotype UML 1.x)

Thoughts anyone?


Uml Process / Re: EA Help file on Choices / Junctions
« on: May 08, 2005, 07:04:01 pm »
Presumably you, CJ, didn't get where you are today without using Zicom Mentor ;-)


Where are you Reginald Perrin, when we need you? ;D


Uml Process / Re: UML 2 MetaModel (Diagrams)
« on: April 29, 2005, 12:26:46 am »
:D I'm working on UML 2.0 Infrastructure Library model for last four days...

Hi Mr Wolf,

Are you intending to include all the elements mentioned in the infrastructure document?  That would be a great service to the modelling community. 8) 8) :)

Could I ask what is motivating you to do this?


Uml Process / Re: UML 2 MetaModel (Diagrams)
« on: April 29, 2005, 12:24:08 am »
Strike me lucky - I thought trying to understand the d*mn things was bad enough - Paolo wants to work with them???


See, not just me...  :P


Uml Process / UML 2 MetaModel (Diagrams)
« on: April 27, 2005, 08:03:35 pm »
Has any kind soul created the UML 2 metamodel diagrams (or knows where they might be found)?

Even a partial implementation would be useful...


Uml Process / Re: Modeling web applications with UML
« on: May 03, 2005, 11:42:46 pm »

In that specific example, no. This is because the nested elements would be instances not the TCP/IP classifier.  So each node would have its own object nested beneath.  Why you would want to have that on a model is oos!

In the case of nested classifiers, I cant think of an example where you would want to have the classifier nested in two places.


More thoughts...

Agree my specific example is incorrect.  (Slip of the mind :D)

It seems to me now, that if one element is nested within another element, then you can't refer to it without the pathing information via the containing element.


Uml Process / Re: Modeling web applications with UML
« on: April 25, 2005, 09:27:15 pm »
I dont know whether this is the real reason, but I have found the following syntactical use for nesting links in any diagram between (sort of) any element pair.


IOW, I see the nesting link as a visual highlighter, yes representing "physical containment"  but adding no other implied relationship.



Sounds good to me, Bruce, and would be consistent  :D with Thomas's points.

So, if I understand you correctly, syntactically, "nesting" would only apply to those elements that are able to contain (collections of) other elements?

Back to my observation that some tools will automatically alter the browser when you "nest" one element inside another.  In your example, fruit would appear "under" tree and not be visible, until you "opened" tree.  Does that fit in with your ideas?

If so, do you see any problems with multiple containment (such as the TCP/IP stack in multiple nodes).  Would each node become a branch with a stack elements "underneath" (within) it?


Uml Process / Re: Modeling web applications with UML
« on: April 25, 2005, 06:33:40 pm »
OTOH it might raise the question why OMG introduced a new kind of relation. I suppose the eggheads found a hole somewhere that had to be filled with a nesting relation. Blame me, I can't see that hole ;)

Hi Thomas,

Like you, I was surprised to see it there...  But on the whole I've found the eggheads on UML2 to be pretty good so far.  What about a Sparxian throwing in their view?  They've implemented it, what was their understanding?


Uml Process / Re: Modeling web applications with UML
« on: April 23, 2005, 03:13:09 am »
To me it seems that nesting is a relation that should be used more along with packages. Most "official" diagrams I've seen used the nesting relation only in connection with packages. Maybe to allow representing some sort of tree structure?

Yes, Thomas, I agree that the UML specs only show this relation in the context of packages, but they don't (as far as I can tell) exclude it's use elsewhere, presumably so long as it is semantically valid to be used at that point.

In addition, a number of tools (including EA) allow it's use fairly universally.

As you say, it appears to be about structural containment.  So what's the difference between structural containment and composite aggregation?

I think I can use (and am using) nesting for Requirements decomposition.  I'd like to use it in other places, but first I have to understand its applicability.  To understand its applicability I need to understand its nature...  Hence my questions.


Uml Process / Re: Modeling web applications with UML
« on: April 20, 2005, 11:58:47 pm »

I, too, have been struggling with the conceptual difference between nesting (containment) and composite aggregation.

Does anybody have a definitive answer?

My view is: it has to do with a form of visibility...  If you can't see the contained item without opening the container first, you have containment (nesting).  Else you have composition.

In other posts, I've noted that some other products will actually nest the nested element below the container in the browser! 8)

What they do with multiple containment, I don't know.  It would seem that IS allowed.



Uml Process / Re: Enumerations
« on: May 03, 2005, 06:36:41 pm »
A quick reply - no time.

All OMG documents are called drafts.

FTF is what happens after a doc is "finalled"  i.e it is the task force that takes over that draft as the basis for the next set of promotions of the doc to final status.  See the explanation at the top of the OMG Documents page.


Thanks for that , Bruce.  I followed your point and went to the OMG site...

This link: describes the process...  (Interestingly, the notion of a Revised Final Adopted anything isn't on the list!)  ???

This link: says that the Revised Final Adopted (04-10-02.pdf) is the latest v2.0 document. 8)

I've formally asked the Sparxians for comment.

If we can all agree on what OMG is saying, then it should be pretty obvious which version we should be standardising on... ;)


Uml Process / Re: Enumerations
« on: May 02, 2005, 09:07:23 pm »
Well Bruce,

Since I have both - it seems to be that the "OMG Adopted specification" 03-08-02.pdf is actually a "work in progress".  If you look at the comments it says "the FTF must do this; the FTF needs to do that..."  04-10-02.pdf on the other hand says:  "We changed this, we did that..."

Both (in their footers) claim to be Drafts...

"There's no such thing as an inconsistently correct system..." ;D

What is most important here is consistency.  My vote is to standardise on the later document, but I won't insist on it if everyone else wants to use the earlier...

Can one of the Sparxian (who ARE members of OMG) shed any light?


Pages: 1 ... 353 354 [355] 356 357 ... 391