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 ... 391
Uml Process / Re: Attributive Associations & Associative Att
« on: June 09, 2005, 05:57:37 am »
Hi Paolo,

I'm curious why you would duplicate associations into attributes and vice versa. What are you trying to gain from that? Conceptually this is incorrect, so there must be a lot to gain from this would I ever considering doing this.

I don't WANT to duplicate attributes and associations.  UML 2 explicitly (and for that matter UML 1.x - implicitly - if anybody read it correctly) defines that an association end owned by a class IS an attribute.   8)

The problem is EA doesn't support this!   ::)

When EA (and other tools - so I'm not just singling EA out) say they support UML 2 what they mean is: "we support UML 2 to the absolute minimum we can get away with".
What limitations do you experience when you just model the association without the corresponding attribute(s)? Do analysts experience limitations in their comprehension of the model? Or are you having problems generating other models or code from this?

As I said in my original post, you can't inherit associations under UML.  I'm sure OMG would argue - there's no need to the - equivalent attributes are inherited.  This is true, but NOT if your tool doesn't render associations as attributes!

SO... I'm in a catch 22!

One problem with all tools that started off life as a code generator is that they tend to be limited to the semantics and syntax of programming languages.  If that's all you want to do, and not do any more serious modelling then you aren't affected since you are working at the "physical' level.

I'm working at the conceptual level, I have generalizations nesting commonly up to 5 levels deep and often much deeper.  With attribute inheritance I can see the effect at the deeper levels, without association inheritance (via attributes) I can't!

In my Rose model, I had a whole raft of cross-checks that would ensure model validity.  I don't have that yet in EA,  I need to port the checker code (in Summit Basic - YUK!).

So.. Until EA correctly supports association<->attribute, I am manually making this happen.  Believe me, the effort involved (as you indicated) is such that I wouldn't do it unless there was a direct benefit to me!  I hope to automate this soon, that's why I raised the question so what I build may be more generally useful or better built as a result of suggestions from the user community.


Uml Process / Attributive Associations & Associative Attribu
« on: June 08, 2005, 08:12:46 pm »
The UML 2 specification (correctly) defines:
... because an association end owned by a class is also an attribute. (ptc-04-10-02.pdf:7.3.3 Association (from Kernel))

EA (like most - probably all - supposedly UML 2 compliant tools) does not formally support this yet.

For the conceptual models I'm creating, I'm putting in both the associations and the attributes.  Actually, I'm eventually going to get my automatic model checker (not yet ported from Rose) to sort this out.

I intend to mark those associations that I have formally linked to specific attributes as «attributive» and ensure that the target role name is the same as the attribute name.  I also intend to mark the referenced attribute as «associative» once I've created the appropriate association.  I can then formally (eventually via the automated checker) ensure that the multiplicity of the association and attribute are the same and that other properties are consistent.

Eventually, I would expect any UML 2 compliant tool to have only one (UML) element that can be rendered in either form as per the UML 2 specification.  I could create the element either by drawing the association or by adding the attribute.  If I added the attribute and the target class was on the current diagram, I would expect the association to be automatically rendered (under option control) onto the diagram.

Note: the UML 2 specification does not (as far as I can tell) formally require that associations be "inherited" via Generalization relationships - whereas it does require attributes and operations.  In this way, I can get (at least certain) associations inherited...

Thoughts anyone?


Uml Process / Re: Domain Model to Design Model
« on: May 31, 2005, 11:45:13 am »
In your book “Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development”, Craig Larman say:  

“This is a key idea in OO: Use software class names in the domain layer inspired from names in the domain model, with objects having domain-familiar information and responsibilities.” … “This supports a low representational gap between our mental and software models.”

I have a domain model with several conceptual classes, and I want to copy one conceptual class to software class in domain layer (or design model). How can I make this in Enterprise Architect?


I believe this is what the new Transformation Templates are there for (under Configuration menus).  I've had a "play" with them and they seem to be what you are after.  Perhaps others who've more experience with them can add their thoughts.


Uml Process / Re: How to structure a project when using packages
« on: June 02, 2005, 04:20:43 am »
Question 1: Isn't this definition contrary to the definition of a view in the  RUP?

Hi phaase,

Can you post the definition of view in RUP that you are using?

And if the version of RUP you are using isn't the latest, can you check if the latest definition is any different.

That way, we can comment better.


Uml Process / Re: WARNING: Use Link versus a «use» Dependency Li
« on: June 01, 2005, 08:21:25 am »
<<use>> has been removed from UML 2.0--only <<extends>> and <<includes>> are valid in that version.

<<includes>> is the closest in meaning, as it indicates that the included use case is treated as a part of the calling use case.

Thanks Kevin,

I'd surmised as much.

However, the Use link in the Help is shown between the Actor and the Use Case - so it shouldn't be a dependency anyway.  In UML 2 (and other products) it's ans Association.


Uml Process / Re: WARNING: Use Link versus a «use» Dependency Li
« on: June 01, 2005, 12:56:56 am »
My view is that one should use the Use link for a usage, in preference to a «use» Dependency.  Thoughts anyone?

I've now checked the UML 2 specification.  There doesn't seem to be a mention of the Use(Case) link implemented by EA. ???  So I'll stick with the explicitly defined Usage Dependency - a Dependency with «use» Stereotype.


Uml Process / WARNING: Use Link versus a «use» Dependency Link
« on: June 01, 2005, 12:36:45 am »
Contrary to the Help file (see under topic Use), a Use Link (incorrectly denoted UseCase Link in the product itself) is NOT the same as a Dependency link with the «use» stereotype.  Two different renderings result and the properties are designated differently.

Took me a fair while to figure out why one was on the Relationship Matrix and the other wasn't!

My view is that one should use the Use link for a usage, in preference to a «use» Dependency.  Thoughts anyone?

Consistency, consistency, consistency!(TM)


Uml Process / Re: How deep do (we) analysts model ?
« on: May 30, 2005, 06:14:31 pm »
AFA I am concerned and anywhere I have control - never.  The model is an asset of the organisation and is of equal value to the delivered code/system.

Absolutely!!!  (but you already knew I would agree with you on this one bruce! ;D)

In my experience, about 2pm.   :)  Seriously,  and in the light of the above, development per se "begins" IMO when the first coder starts the first prototyping exercise to solve the first realisation problem encountered.  AFA I am concerned and anywhere I have control even these go under config management. They have on many occasions proven their value later in the project or life of the system as prompters as to "what the hell were we thinking".


Again I can only agree...  ;D  The biggest missing factor in design documents and code is WHY???  Don't bother documenting what the code already says it does - anyone can read the code.  Say WHY it is doing it...


Uml Process / Re: Is an object more than a instance of a class?
« on: May 30, 2005, 07:17:53 am »

Object is considered as an instance of a class. But can we consider an object as a child of a parent class (sort of an inheritance)?

Well, an object IS an instance of a class.  Thus the concept of inheritance (Generalization) in the UML sense is NOT applicable, since they are two different kinds of classifiers.  Inheritance is the process by which the more specialised classifier is granted access to the features of the more specialised classifier.

If you look at the way in which EA renders that idea (by creating two classes, adding a Generalization link between them and then making sure all inherited features are made visible Ctrl+Shift+Y) it should become clearer.    Add some features to one or other class and watch the rendering change.  

When you've got the hang of that.  Add an object to the diagram.  Make all features visible (Ctrl+Shift+Y).  See nothing is visible!  Now,  set the instance classifier using Ctrl+L - to the more specialized class.  See the object automatically takes on the detail of the class you referenced.  Do it again, change to another class.  That class's features now are visible - all without having to add the Generalization link!

Does that clarify matters?  If not, ask for further clarification.  We're all here to help.


Uml Process / Re: All Stereotypes are created equal...
« on: May 30, 2005, 02:47:23 am »
The behaviour you describe is as designed: stereotypes are not inherited but are copied from parent to child on applying a generalization connector. Remove the generalization and the stereotypes stay copied: if they'd been inherited they would've been removed. You can use EA's behaviour to choose whether you want to apply stereotypes singly or all down the hierarchy, simply by changing the order you apply stereotype and generalization.

Surely you jest!?! :o  How can I, over time, have 'a priori' decidability over how the model will develop?  The model develops as the model will - as a result of analysis and design!  The rules around copying of stereotypes have to be declarative, not procedural!

Once again, I'm no longer the modeller, EA is...  IT, NOT ME, decides when it will copy the stereotype, based upon some serendipitous set of circumstances! :'(

At a minimum, EA should ask whether it wants me to copy the stereotype.   Both at the time the generalization link is created and if I change the stereotype of the Generalized class and a Generalization link exists!  (Recursively please! 8))

In my view, however, the fact that EA does copy the stereotype by default on the inital generalization is yet another indication supporting the generalized notion of inheritability of stereotypes! ;D

That's not good: it works for me. Is your metaclass stereotype in a profile or did you define it in "Configuration | UML | Stereotypes"? What is the file format of the metaclass file? What is the name you've given the stereotype?

I don't know where it came from.  In any case, from your foregoing, the name of the stereotype should not be relevant!  You said, it will copy the stereotype on initial generalization (giving me the choice - see highlight in read above).  Certainly, if I do it with one of my own stereotypes - added as you describe, it doesn't work!


Consistency, Consistency, Consistency!

Uml Process / All Stereotypes are created equal...
« on: May 29, 2005, 11:04:18 pm »
I'm going to climb off the fence and say "don't inherit".


Well, KP, I'm glad you think so... Because EA doesn't...  ???

Create a class, create a second class.  Change the first class to a boundary stereotype - the class changes shape.  NOW, add a Generalization link from the second class to the first!  Presto - stereotype is inherited, second class changes shape! :-/

For the "coup de gras" - create a third class, and a fourth class.  Connect four to three via Generalization.  Change three to a boundary.  Voila! Three's shape changes, four's doesn't... ::)

Create a fifth class, create a sixth class.  Change the fifth class to a metaclass stereotype.  Add a Generalization link from the sixth class to the fifth!  Presto - nothing happens! >:(

More secret handshakes? :o


Uml Process / Re: Inheritability of stereotypes
« on: May 23, 2005, 08:18:08 pm »
Thought I'd resurrect this topic.

From my perspective, I haven't seen a convincing argument as to why stereotypes shouldn't be inheritable...


Uml Process / Re: Inheritability of stereotypes
« on: May 12, 2005, 05:31:45 am »
Of course, apologies, feature is indeed le mot juste. It was on the tip of my tongue, honest!

Never doubted it...  ;D  (Truly!)  It's just I like to be precise.

I hope they never are. If stereotypes aren't inherited, you can choose to apply them wherever you wish; if they are inherited, you can no longer choose not to apply them.

Indeed, Evil, this is the essential issue.  But suppose we had concepts simlar to Java's "final" or Eiffel's suppression of inheritable features, then might we not have our cake and eat it too? 8)  
[size=10](I don't have my copy of OOSC2 - here at home, so I can't be absolutely precise about Eiffel but I believe it to be correct)[/size] :)


Uml Process / Re: Inheritability of stereotypes
« on: May 11, 2005, 06:02:14 am »
This might be a very dumb question, but how do you plan to inherit a class from another if not by the use of 'generalize'?

My point was Generalization in UML is the method by which attributes and operations (features) get passed down.  I didn't explain myself well enough, sorry...

Don't worry about 'bash Alexander day', my girlfriend established it as a permanent festivity long ago  ;)

Say no more!


Uml Process / Re: Inheritability of stereotypes
« on: May 11, 2005, 05:20:43 am »
Perhaps you could be generating a custom language and the syntax of root nodes is different to other nodes - the stereotype is used to modify the code generation templates.  I think that's a perfectly valid use for stereotypes.

Using stereotypes to modify code generation IS indeed a valid use for stereotypes.  I'm not sure if it's explicitly stated in the UML 2 specifications, but it's certainly implied.
Nevertheless, I still suspect your usage is novel...

You could also do it with a tagged value, but applying tagged values to elements is another valid use for stereotypes.

It's actually a required UML 2 functionality which EA isn't yet implmenting... ;)

Either way, stereotypes aren't "properties", so they aren't inherited.

The actual term used in the UML 2 is "feature".  Your point is taken for strict UML 2.  My question is "beyond" current UML.  I guess I'm proposing that stereotypes (and any associated characteristics like adornment and tagged values) be treated as "features"


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