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 ... 391
Uml Process / Re: Is Specification - should it inherit?
« on: June 15, 2005, 07:14:38 pm »
(Conceptually) I wouldn't expect it to.  Is Specification and other thingos like it seem to me to be an aspect/feature/characteristic of the class not an attribute as they are "commonly" understood in OO.

In my model, which I imported from Rose, I had stereotype «specification» for those classes that are specifications (=> Is Specification = True).  I set the bit at a top node and wrote a query that says: "find me those classes where stereotype «specification» and IsSpec (the DB field) are inconsistent" ;)
I then wrote a query to propagate the bit settings.  After I got it working properly, I discovered a couple of conceptual errors in my model! 8) 8)  So I think it is conceptually valid!

This, to me reinforces the idea of inheriting stereotypes.  I'll implement queries to do that once I figure out  how to get around the arcane implementation of multiple stereotypes within the EA DB.



Uml Process / Is Specification - should it inherit?
« on: June 15, 2005, 05:30:27 am »
You can define a class as a specification by setting the Is Specification checkbox in the Class|General|Advanced dialog.

If you inherit from such a class, should (conceptually) the Is Specification value also inherit?


Uml Process / Re: I need other opinions, please
« on: July 01, 2005, 03:30:10 am »
Hi Paolo;

Yes I have to make a prior audit (internal) to my client before to deliver the product to the end user, which will make another formal (and definitive) audit.

I've made an overview audit but I want to contrast with your opinion (people of this forum) about it.

I forgot to ask:
What s the UML competence level of:
1) your client
2) the end user
3) and you? ;)

And a clarification - are you independent of your client?That is, you are in a contractor or consultant role with respect to them for this specific assignment only (at this time).

Are you able to provide some indication of your findings in the overview audit?

As you've already pointed out, and we've confirmed, there doesn't seem to be much semantic relevance to what you've been provided.  Apart from meeting the requirements (who decided them - do you know?) what rationale have you been provided for the use of the package diagram?  For example, what did your client mean by the association multiplicities between the packages?


Uml Process / Re: I need other opinions, please
« on: June 30, 2005, 06:35:56 am »

Some clarifications perhaps?
I am collaborating auditing internally some design models made by a company with EA and the end user is very formal with the model reviews.
The company is your client,  not the end user?
My client made the software system partition with a package diagram and not with a deployment diagram for abstraction purposes. Also, before this work my client and the end user agreed a general scope document in which this product would be made using a package diagram.
So your client appears to have met the, agreed, requirements?
The diagram shows packages and associations with multiplicity between them.  No dependencies. I understand that there is no semantic arguments to make this and that the only formal allowed connections between packages are dependencies and nesting relationship.
Your role is to perform an internal audit for your client prior to delivery of the model to the end user?

Or have I misunderstood everything?


Uml Process / UML 2 Templates
« on: June 20, 2005, 12:51:18 pm »
Searching the forums, a number of postings have discussed C++ Parameterized Classes, notably:;action=display;num=1050317385;start=4#4
My question relates to UML 2 templates which are an extension on this.

From what I saw in the postings, support for Parameterized Classes is haphazard at best (especially in earlier versions).  In addition, formal support for UML 2 templates (ptc-04-10-02:17.5 Templates) appears almost non-existent. :'(  Somebody correct me if this isn't the case.

So how best to model this in the interim (conceptually) until EA catches up?

Looking at what is available, I decided to create the template using the Parameterized Class functionality.  I propose to create the template by setting the stereotype to «template» and setting the Detail|Templates type to Parameterised and adding the parameters as appropriate.

I will create the bound class by setting the template to «bound» and setting Detail|Templates type to Instantiated.  Rather than use the arguments list, which does not allow formal binding of the bound values to the formal parameters, I thought I would create a new constraint type called "binding"  add the bindings as binding constraints of the form formalParameter -> boundValue and then display the constraints compartment for the class.  This mimics the UML 2 binding syntax.

I would then join the bound class to the template using a Generalization link stereotyped as «bind» (it has been noted elsewhere, that EA doesn't support a binding Realization), so I can get the visual feedback of the (some of ) the effect of binding in the bound class.

The net effect is that the bound class shows up as the inherited features of the template with a constraint compartment at the bottom telling me how to bind the template.

I'm pretty sure I can traverse such structures with automation and I think I can process them satisfactorily with code generation templates.

Thoughts anyone?

Remember, for my needs, I don't have to round-trip.  I just need to be able to emit sufficient metadata to allow a downstream process to generate the code.


Uml Process / Re: regarding definition use in the use case model
« on: June 16, 2005, 11:47:01 pm »
Just to make it clear, when Bruce says "football" he means an Aussie Rules football or rugby ball, not a soccer ball. Other than that, he's pretty much nailed it.  ;D

For more information, click here
And he strictly and precisely does NOT mean an American Grid-Iron football. ;D


Uml Process / Re: Aggregation and Containment
« on: June 16, 2005, 01:25:21 am »
Maybe. It doesn't contain the word you mentioned, so I just don't know what you are talking about. 8)


Uml Process / Re: Aggregation and Containment
« on: June 15, 2005, 01:50:17 am »
Not an answer but it is metonymy, not meronymy (I had to use my dictionary).


n : substituting the name of an attribute or feature for the name of the thing itself (as in `they counted heads') ???

Perhaps you used the wrong dictionary? ;D


Uml Process / Aggregation and Containment
« on: June 14, 2005, 06:28:10 pm »

the UML 2 specification does not grok (is silent on) containment.

However, by general consensus we know (agree) that shared aggregation can only be containment of the target by reference and that containment of the target by value can only be a composition.

In many tools (Rose for example) containment an aggregation are intimately linked (as indicated above).  In EA they are separated; which, in my opinion, is no bad thing. 8)

(Aggregation is a form of meronymy - the relationship of part to the whole.  UML 2 only provides for some of the 6 (generally accepted) forms of meronymy)  BTW: sometimes meronymy is spelt meronomy (incorrectly in my view)

Anyway, the crux of my post is: in those tools where aggregation and containment are linked, the containment control is in the opposite end to the role.  Thus if Class A aggregates Class B, and the aggregation item is on the A end, when you look at the A end role there is a subcontrol marked "Containment of B" - where you can indicate "By Reference, By Value or Unspecified" - and the form of aggregation changes appropriately?.

In EA, the containment appears to be related to the role itself.  Thus if I want to indicate the above example, I would go to the A role, mark the aggregation as shared, go to the B role and mark the containment as "By Reference"

Have I got this right?


Uml Process / Re: Multiplicity expressions
« on: June 13, 2005, 10:06:20 pm »
No, no, no.  I'm not saying your instance is anonymous.

I'm saying that the UML does not specify or imply an implementation of this "multiplicity" bezerker at the attribute level.  They say an attribute can have a multiplicity - and OK, OK natural numbers only. What they don't say is how this multiplicity is to be interpreted or implemented. You chose a vector,  EA provides for up to three explicit stand by implementations of these collections (default, ordered and qualified).  As someone said before (you?)  multiplicity of an object ain't the same thing as cardinality of a set.  All I'm saying is that UML is - yet again - silent on  the things they cant groke.  In this case, what they really mean by the multiplicity of an attribute in a classifier.


edit:  but to use that good old engineering expression "I suppose its good enough for practical purposes"  :)
bruce,  I meant vector in the mathematical sense :)  Conceptually, it may be thought of as a one-dimensional array.  How it is actually implemented is, as you say, another issue.

Multiplicity is a cardinality wot can be zero...

I suspect we are now in violent agreement! ;D

And as a trained engineer I applaud your last statement!


BTW I thought it was grok... (slip of the fingers?)

Also: yipb?

Uml Process / Re: Multiplicity expressions
« on: June 13, 2005, 09:12:58 pm »
I thought the constant expression had the opposite meaning, i.e. an expression whose value is constant.  However, I could be getting confused with C#.
Yeah, we discussed that here and figured that UML was ambiguous here - hence my clarification.
But to get back to your... I have no problemo's at all with the cardinality of a vector being a computed value, many modern [sic] languages provide such a feature.  In fact at implementation the vector size could be constant, variable or even random  (many examples of software around seem to use the latter  ;) ;)   ).

But finally, I've got to ask the question, what the heck is multiplicity of an attribute?  This class contains between 0 and n attributes of this name?
That's the way I read it.  This attribute is a vector.  See my posting on Attributive Associations vs Associative Attributes.
If as I understand it, at instantiation of the parent class say "autobus" as an object, say "3:15pm Peppermint Grove" that instance has a value of 67.3 set for its maximumDoorCount attribute then I can create up to 67.3 owned :door objects and stick them in some anonymous collection within the 3:15 Peppermint Grove object somehow.  How one can then reference these beasts seems not to be addressed by UML and is left to the language implementers.
The vector is not anonymous...  (Sorry for not being more explicit)  comprisedDoors [1..maximumDoorCount].  maximumDoorCount is of type NonNegativeInteger thus 67.3 is invalid (it's invalid by definition since multiplicities are defined as lower bound integer, upper bound natural numbers) ;D
Yes, the how is left to the implementation, I'm concerned here with the what.  For example: -/ comprisedDoorCount Count = comprisedDoors.Count
(I have a concept comprisedDoorCount (private) which is of datatype Count and which I formally define (derive) as the count attribute of the comprisedDoors collection)
To get back to your... (again)  the only question of ambiguity arising from your proposition is the constraining of using a varying value for a bound to only owned elements of the defining object. IOW the maximumDoorCount of the 3:15 Peppermint Grove  cannot and should not be used or usable as a bound on the doors in the 769 Dee Why West instance.
As you implicitly assert, the run-time value is instance specific.


Uml Process / Multiplicity expressions
« on: June 13, 2005, 08:09:18 pm »
In standard UML, you can express multiplicities in non-literal terms:
[4] If a non-literal ValueSpecification is used for the lower or upper bound, then evaluating that specification must not have side effects.
[5] If a non-literal ValueSpecification is used for the lower or upper bound, then that specification must be a constant expression.
(from: ptc-04-10-02: 7.3.32 MultiplicityElement (from Kernel))
8) 8)

It seems to me this allows one to specify the multiplicity of one attribute in terms of the value of another attribute.  For example, I may define an autobus to have a maximumDoorCount.  I may define a vector of Doors whose cardinality is [1..maximumDoorCount].  This would make the (conceptual) model more expressive.  BTW: EA appears to accept this input with no problem.

Should I use this feature in my conceptual models?

NOTE: I'm not, primarily, concerned with code generation (or synchronisation) here.  For my environment, that's a problem left to a downstream process that takes output emitted from the EA conceptual model.

Anyone suggest why I shouldn't do this?


BTW: I have taken constant expression to mean that the expression itself is a constant not that it references a constant value.  (In C++ terms a const pointer not a pointer to a const) ;)

Uml Process / Re: Multiple Inheritance and feature override
« on: June 13, 2005, 08:19:57 pm »


You have much, much , much to much time on your hands.

 ;D (At least I go out occassionally and go and watch some paint dry.)

Hey,  I read them over 8 years ago!  Before I met Betrand (name dropper!) - turns out he studied under the same guy that started me on conceptual modelling in 1978! (Jean Raymond Abrial - virtually unknown outside of France)


Uml Process / Multiple Inheritance and feature override
« on: June 13, 2005, 07:40:34 pm »
EA allows the explicit overriding of an operation when you inherit via a generalization.

Unfortunately, it doesn't (orthogonally) extend this to attributes in a formal fashion.  It does it by implication.  If you inherit an attribute x from class A it will appear on the inherited display as:

If you declare a local attribute x, EA implicitly assumes that you are overriding the inherited x  and removes it from the inherited list.  This is (I guess) OK for single inheritance (although why does EA explicitly ask about operation override), but it is not OK for multiple inheritance.

EA appears to make no provision for one of the issues involved in multiple inheritance: Renaming
Where a feature with the same name is inherited from two different ancestors, a decision needs to be made:
1)    Is it a special case of repeated inheritance (common ancestor) and therefore we can say all the instances are the same thing.  There is only one feature with one name.
2)    Even though it is a case of repeated inheritance or not the semantics of the same named feature are not the same at this point.  They are therefore not the same thing.  There are two features that require two names.

It seems to me that more formal support is needed in EA for these types of issues:
1)    The ability to formally denote redefinition (override) to stop me accidentally mistyping the name of a local feature and thus implicitly overriding the inherited one.
2)    The ability to formally denote the renaming of an inherited feature.

Thoughts anyone?

Incidentally, I thoroughly recommend Chapters 14 & 15 of Object-Oriented Software Construction by Bertrand Meyer for an excellent exposition of the issues involved in inheritance (particularly multiple).


Uml Process / Re: Attributive Associations & Associative Att
« on: June 09, 2005, 08:03:24 am »
Hi Pascal,

thanks for your prompt replies...
Hey Paolo,

Glad we iteratively came to a common understanding of your point!  ;)
Yes! 8)  But I'm not sure I agree with the consequences you discuss below...
I think in this case we would have to distinguish between the implementation of EA´s metamodel and the view on that model. Theoretically, an association can still be implemented as an attribute on metamodel level (thus complying to the OMG standards), but in the view layer they could have made the choice to make a clear distinction between attributes and associations. I don´t find anything wrong with this, because in most cases you would want associations to be rendered differently than attributes for readability sake.
In principle, I think you are correct, however there is an added complication.  Not all associations are "attributive" (to use my language), nor all attributes "associative".  I might not wholly agree with the UML 2 specification here, but it is explicit on this point!  Only SOME associations ARE attributes and only some attributes ARE associations.  Those features MUST be rendered in BOTH forms (because they are the same thing)!
BUT... I completely agree that in some parts of this view layer,  an attribute-like representation of associations would be very welcome, like in the example.
See above...
So to basically summarize my thoughts: I don´t think we can simply conclude here that the way EA handles some views on attributes and associations contradicts with OMG´s specifications, as long as EA's underlying metamodel can easily be opened to render associations like attributes in every way.
If the underlying metamodel is expressed in the database design, then you should have a look (using the appropriate RDBMS) and draw your own conclusions... ;)


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