Hi all, On 2012-08-27 12:08, Florido Paganelli wrote:
Hi Stephen,
On 2012-08-25 12:12, stephen.burke@stfc.ac.uk wrote:
Florido Paganelli [mailto:florido.paganelli@hep.lu.se] said:
What would you propose to do with Share, Resource and Manager?
Same approach. As I said, this depends if we want to override the associations or not. This cannot be represented in UML, but makes sense in realizations.
And what about the relations between them? And the same for the storage classes? I think this would be quite a big change which would need a significant advantage to be worthwhile, and so far I don't think you've given one.
There is no changes. As I said, UML cannot express inheritance so well as implementation is straightforward.
But we have the opportunity to fix it in the realization documents that are not final yet.
I just wanted to notify everybody that I was wrong on the above. Carefully re-reading GFD1.47, I found out that ComputingService actually explicitly redefines the <- exposes -> association. It's not done in the UML schema, but on page 24, reading the table representing ComputingService, it says that the ComputingEndpoint.ID association *redefines* Endpoint.ID. Stephen was right, we have that ComputingService that can only host ComputingEndpoints. I think this is bad design, but I guess it's too late to change it now. The reasons for this restrictive behaviour are hard for me to understand... but that's what we have. Cheers, -- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project