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 ... 352 353 [354] 355 356 ... 394
Uml Process / Re: Generalization vs Realization
« on: July 05, 2005, 07:12:13 am »
OK, so the methods you select when generalizing are the ones you want to override and EA helps you by copying the method firm so you can override the behaviour?
I finally found the option to make the inherited features show in the diagram, it was in the class's feature visibility option.
Yes, you need to manually override the attributes. :(
I think it is important to discuss the difference between inherit and copy, the problem is that inheritance is usually implemented by copying the parent's features into the son. But i see why u separate them and complain when EA does that to inherit stereotypes.
I think that is a language dependent issue.  Not all languages require that.  I will leave that up to the language experts.
Perhaps we should discuss if copying the stereotypes and tags is really the best way to implement these features inheritance. I have always found disappointing the way EA allows you to select types and stereotypes by 'name' instead of by reference, not helping you to centralize types and  stereotypes definitions.
Yes and no, the problem is that UML does not require references, just names.  Also when you import you may encounter previously unknown stereotypes.  As a Data Management person, I can provide patterns that can automatically accommodate these new stereotypes, but they require a small amount of work to set up.
The same politic seems to be all over the place, when selecting operations in the comunication's messages, when selecting roles in an association, and so on... I fail to see the advantage of this 'relaxation' of references.
Since EA is based upon a repository (one of its great strengths) as I said before it's a little bit (but only a little bit) more difficult to retain referential integrity, but provide the flexibility of accommodating new values.  In my experience, most programmers have little or no idea about DB design.  (No particular reflection on the Sparxians - how much time did your lecturers spend on DB design?)
Even though EA has defined relationships (open the .EAP file with MS Access  and look at the Relationships screen) - Referential Integrity is not enforced.
I will try to make some round trip tests and see how 'realization' is implemented in different languages.
That should prove interesting, please let us know what you find.


Uml Process / Re: Generalization vs Realization
« on: July 04, 2005, 06:40:18 pm »
The specification states that a generalization should inherit all the 'features' of the father into the son.

My first question is, should attributes be considered features? I have been unable to make EA inherit attributes unless they where specified as properties in which case only the setter and getter methods where inherited.
Alexander, your problem may be in the use of the word inherit.  Inherit does not mean copy, it means make available.  Thus if you show the inherited attributes and operations on the Diagram, you will see how EA makes them "visible" in the descendant class.  If you don't see this at the Diagram level, then that's your first problem.  We need to solve that first.
You are able to override both the attributes and operations.
If your question is directed at the language code generation, then that's a separate issue.  As I mentioned I don't have a lot of experience with EA code generation (and particularly with Round-trip-engineering) but I didn't notice any problems in this regard (apart from that which I mentioned).  Perhaps others could comment
My second question is, should it be possible to inherit only some of the features of the parent without an explicit overwrite? EA allows to select the methods to be inherited enabling only part of the features to be in the child class.

Yes, I too am of that view - you can only perform part of the inheritance services mentioned by Bertrand.  
Realizations have the same issue, but i find it useful since some times i want to specify an interface that is realized by several concrete classes and i don't want to design a delegator between to map each of the methods to the class that implements it.

I haven't been able to give a scope to what 'features' of a classifier could mean, i will try again tomorrow to search through the documentation for some insight into.


Uml Process / Generalization vs Realization
« on: July 04, 2005, 07:05:50 am »
...Or what should/gets inherited/transferred/made available when we Generalize a Class (from descendant to ancestor) or Realize a Interface/Class(from specification to instance - although the link is drawn from instance to specification).

As a result of a request from Alexander, I'm opening a thread to discuss these topics.

The starting point is the agreement that Alexander and I have that normal "inheritance" should be modelled as Generalization and that the instantiation of a specification should be modelled by a Realization.

When we use the Generalization relation, EA conveniently provides a number of (optional) services to us, the modellers:
You can view the names of the immediate parents of the Class (if they are off diagram - but you can't as yet list the entire ancestry)
You can view the inherited Features, attributes and operations, (with some, though not complete indication of Feature override).

These services appear to work pretty well for multiple inheritance but do not allow you to handle the full range of issues concerned with multiple inheritance (such as those identified in Chapters 14 & 15 of Object-Oriented Software Construction by Bertrand Meyer).

When you actually attach the Generalization, EA will copy (not inherit) the stereotype of (one of) the multiple immediate parents.

I haven't done a lot of round-trip engineering with EA (since I've taken an alternate path and my principle concern at present is the generation of conceptual models) however, I did to enough to discern that if you create a Realization link, and forward engineer and then reverse engineer, then EA will remove the Realization link on import and replace it with a Generalization link.

The reason is that on forward engineer, EA creates what appears to be an inheritance and, naturally, on import can't distinguish between them.

So that's enough to kick off the discussion...

Some questions to consider:
What is the essential difference between the Generalization and Realization relationships?  I think, but it's not a well formed thought as yet, that there are many similarities and some distinct differences between the two relationships.
Assuming we can come to agreement on these similarities/differences, what should EA display (provide via API) when we make that kind of linkage between two classes.
In addition to the "inheritance" of Features, should other properties of the ancestor Class (IsSpecification, Stereotypes, Tagged Values etc) should also be made available (in one way or another) to the descendant class.

Finally, what is the relationship between a Parameterized Class (the closest EA currently gets to a full UML 2 Template) and the instantiated (bound) Class therefrom.

For the purposes of this discussion, I'd recommend using the UML 2 Superstructure Specification as the normative reference.

Let the games begin...


Uml Process / Re: Parameterized Interfaces
« on: July 08, 2005, 08:53:30 am »
Hi Paolo,
just to be sure I understood your question. Do you want to model something like "templates" in C++ ?

Regards Martin
Yes, Martin more or less...  I really want to create UML 2 templates, but the closest EA comes to them at present is Parameterized Classes.

The problem is compounded by the fact that C++ doesn't actually have Interfaces (say like Java and C# do).  We simulate an Interface by using a pure virtual Class.

Anyway, I want to be able to template Interfaces...


Uml Process / Parameterized Interfaces
« on: July 08, 2005, 01:24:36 am »
Today,  I had occasion to want to create a Parameterized Interface.

My reasoning was:  I use Parameterized Classes to enable me to define a set of Classes with identical characteristics but different instantiations.  Parameterised Interfaces would allow me to do the analogous thing...

EA won't let me create a Parameterized Interface, because it doesn't allow you access to the Detail tab of the Classifier.  That's no problem, says I, I'll just change the element to a Class, pop in the parameters and switch it back to an Interface - just like I have to do if I want to add a linked diagram or add a feature (by the scenic route). ::)

Imagine my frustration when, having added the parameters, the the parameters disappeared when I switched the element back to an Interface! :'(

Before I submit a formal bug report to Sparx, is there any reason why I shouldn't be able to create Parameterized Interfaces?


Uml Process / Re: Altering Default Views in an EA project
« on: July 06, 2005, 04:26:26 pm »

I have arbitrarily named View packages within multiple Project packages in a .EAP repository.

My environment is therefore not the same as yours,but so far I haven't experienced any problems...

I've generated code sing my own code generation templates, but I haven't used XMI since I reorganised.

Do you have specific issues with XMI?


Uml Process / Re: Own defined attribute types
« on: July 03, 2005, 08:57:52 pm »
I've just had a look at the UML 2 Superstructure specification and it seems to me that the current EA rendering of an «Extension» association is incorrect.  The open arrow should be a closed, blocked in, arrow.


Uml Process / Re: Own defined attribute types
« on: July 03, 2005, 07:50:51 pm »
Hey Martin,

I defined my attribute stereotypes by creating my own UML modelling profile (see the "Create a UML profile" topic in the help file).


Hi Pascal,

I haven't got into Profiles as yet - for the present they don't seem to give me very much I can use at the current stage I'm at with my models.  [Not a criticism of EA, just an observation of where I am in relation to the questions I'm about to ask]

Do I understand correctly, that a profile gives you the ability to predefine a stereotyped element with preexisting tagged values (derived from attributes tab in the original extending stereotype) and constraints (derived from the constraints tab of the extending stereotype)?

You can merge a new definition of the stereotype with existing definitions.

Since I'm not yet using tagged values, this doesn't seem to give me much over simply stereotyping the original element.  Or have I missed something?

Also, does this work with multiple stereotypes?  Have you confirmed it does?  (Particularly if the profiled stereotype is not the primary one?)

If I correctly stereotype my elements and later create profiles, can I use the merge mechanism to add the profilable features to my existing elements using the profile merging mechanism?

Do you have any idea what the <Redefinitions/> clause is used for in the actual profile XML?


Uml Process / Re: Is Specification - should it inherit?
« on: July 02, 2005, 06:30:54 am »
I agree with Paolo, specification should be inherited, but only if u are trying to create a new specification, it instead u are trying to create a class that is built to that specification u should use 'realize' (which doesn't inherit the stereotype). For that purpose, the 'IsSpecification' property should also be inherited.
Alexander, I'm not clear on what you are saying here.  Your words seem a bit self-contradictory.

Are you saying that for normal inheritance (Generalization), IsSpecification should inherit, and for Realization (the creation of a client according to the supplied specification), IsSpecification shouldn't inherit?  If you are, then I agree.
I remember that discussion about stereotype inheritance, i would like to know if u (Paolo) have been working to build something to implement this in EA and the problems you've discovered. If there is a topic where u have continue discussing this, can u point me to it?

The discussion on inheritability of stereotypes is found here:;action=display;num=1115649626
Additional discussions on multiple inheritance are found here:;action=display;num=1118716834;start=0#0
I have been working on some things, which may or may not be of interest to you.

The issue is compounded by EA's (self-)inconsistent behaviour when creating Generalization links.  Thomas Kilian was the first to raise the question as to whether EA has been built using OO principles, but he only beat me to it by a couple of days.
The way in which EA implements multiple stereotypes also doesn't help...

As it happens, based on my experiences over the last few weeks I was about to publish some thoughts on the questions of Generalization, Realization, Parameterized Classes, UML 2 Templates and so on.

If you are interested I can start a new thread on these.


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


Pages: 1 ... 352 353 [354] 355 356 ... 394