Manifestation as Realization

[Paolo F Cantoni]

This one is a bit heavy...  I think the UML 2 Superstructure Specification is self inconsistent.

In 7.3.45 is states: Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc

In 10.3.10 Manifestation (from Artifacts) A manifestation is notated in the same way as an abstraction dependency.

This would imply it is denoted as (or similar to a Realization).

The specification then goes on to say... i.e. as a general dashed line with an open arrow-head
labelled with the keyword «manifest».

I would have thought it would be more appropriate to show it as a Realization with stereotype «manifest».

What do others think?

EA follows the specification.

Paolo

[sargasso]

I too struggled with the manifestation link in UML 2.0 for, oh, minutes I guess.  

Actually, I did finally guess that it has something more to do  with poltergeists than realizations.  IOW rather than the forward looking realization, "This begat that begat the_other", it is more to do with "this left that behind".

Anyway, it all became too ethereal for me at that point so I forgot all about them.  Loking forward to more viewpoiints though.


bruce

[Paolo F Cantoni]

I too struggled with the manifestation link in UML 2.0 for, oh, minutes I guess.  

Me too, that's the problem!  When the rubber hit the road, it slipped!

Actually, I did finally guess that it has something more to do  with poltergeists than realizations.  IOW rather than the forward looking realization, "This begat that begat the_other", it is more to do with "this left that behind".

Now that's interesting!  I view both Generalization and Realization as backward looking... "I came from there..."  Which, I think, is in line with Client to Supplier direction...

Anyway, it all became too ethereal for me at that point so I forgot all about them.  Looking forward to more viewpoints though.

bruce

I now have the problem of formally emitting code that represents classes.  If I make the manifestation a Realization then I can narratively say:  "This ComponentInstance includes this ArtifactInstance which manifests this realization of that Class."

If I make it a dependency, the equivalent verbalisation doesn't make sense...

Cheerz,
Paolo

[sargasso]

I thought it was "the code in file 'xyz' manifests the model element 'class abc' "

cf object 'Mike' realises class 'person'

then "the code representing classes Ahab, Bhab and Chab are realised in the (deployable) component 'pf_magic' which is manifested on Win as pf_magic.dll and on Lin as pfmagic.so




bruce

[Paolo F Cantoni]

I thought it was "the code in file 'xyz' manifests the model element 'class abc' "

cf object 'Mike' realises class 'person'

then "the code representing classes Ahab, Bhab and Chab are realised in the (deployable) component 'pf_magic' which is manifested on Win as pf_magic.dll and on Lin as pfmagic.so


 

bruce

Yes, this is true for physical components (dlls, assemblies, SOs), but I'm talking about logical (source) components.

Or perhaps source components don't exit?  (Serious question).

Paolo

[sargasso]

Hmm,  bruce definition of component is something deployable.  IOW on my planet the only components are Not Source.

Seriously (dont call me Shirley) I have never considered the deployable source before  - but in your (MDG) case, I suppose it is!  

This opens up a new world of mind bending possiblilities.  Is UML capable?  Never mind, as long as the intent and message of the model is correct, bugger the grammar.

bruce

[Paolo F Cantoni]

Hmm,  bruce definition of component is something deployable.  IOW on my planet the only components are Not Source.

Seriously (don't call me Shirley) I have never considered the deployable source before  - but in your (MDG) case, I suppose it is!  

This opens up a new world of mind bending possibilities.  Is UML capable?  Never mind, as long as the intent and message of the model is correct, bugger the grammar.

bruce

I agree that components should be deployable, but as you concede, that doesn't restrict them to physical components.  I may deploy a configuration directory, etc etc...  If they aren't Components (using the Bjelke-Petersen Duck Test ) then what are they?

Paolo

[sargasso]

OK, having had good listen to a whole pile of code files this afternoon, I have not heard a single peep let alone a quack, so I can only surmise that files containing source code are not ducks.  

One thing that's not clear is, in your system model, where does the system boundary lie?  Is the generated source code   - and I mean the code informa not the code-in-ascii-in-a-file - inside the system or is it beyond the boundary.

If the latter then I feel the problem may rather be simpler than complex.  Anything (read any information) that ends up in an external containerthingy (an artifact) is a manifestation of the information available to the system as input or within the system.  One can treat your actualisation of the containerthingy and its contents as manifestation.

Realization on the other hand, is within the model, as in "this model element is a realization of the informa content of that model element".

To be more traditional, a system exethingy does not "realise" its output (say a report) but said report is a manifestation of the information manipultaed by the system.


...or thats what I think anyway...
bruce

[Paolo F Cantoni]

OK, having had good listen to a whole pile of code files this afternoon, I have not heard a single peep let alone a quack, so I can only surmise that files containing source code are not ducks.  

That's a relief!

One thing that's not clear is, in your system model, where does the system boundary lie?  Is the generated source code   - and I mean the code informa not the code-in-ascii-in-a-file - inside the system or is it beyond the boundary.

Good question Gunga-Din!  I suspect I'm a special case; as my system (at this point) is a system to generate source code!  Therefore, it follows that all this stuff is within the system!

If the latter then I feel the problem may rather be simpler than complex.  Anything (read any information) that ends up in an external containerthingy (an artifact) is a manifestation of the information available to the system as input or within the system.  One can treat your actualisation of the containerthingy and its contents as manifestation.

I agree with this viewpoint, but sadly think it doesn't apply here due to above.

Realization on the other hand, is within the model, as in "this model element is a realization of the informa content of that model element".

Yes, I also agree here...

To be more traditional, a system exethingy does not "realise" its output (say a report) but said report is a manifestation of the information manipulated by the system.

Specifically, a report is a snapshot manifest ¹ (at a point in time) of the facts/information held within the system.

...or thats what I think anyway...
bruce

Aye and good and welcome thoughts they are too!

Keep 'em coming...

Paolo

¹Or possible a manifest snapshot!