Well, as we go along I may have a few more 
Sounds like you've enumerated explicit Stereotype names to support your internal decision making activities; and that's why they appear on your diagrams...?
No, not quite. The stereotype names such as «componentInstance» and «artifactInstance» are there to get around the fact that EA DOESN'T provide the instances of Component and Artifact. This is to enable my emitter to emit the correct element type.
The «instance» stereotype is (as I previously explained) to allow a graphical rendition of the Object:Classifier syntax (and associated semantics). Just as a named, navigable AssociationEnd IS an Attribute, for me, an «instance» Realization is the assignment of the Classifier to the Instance. (My emitter will need to follow the defined Classifier for an Instance even if the Realization link isn't present.
The «include» stereotype is there to correctly handle meronymy of the whole-part relationship. Following on from our discussion re
Composite vs Component, I extended those definitions and assigned particular "patterns" to the various forms of meronymy I need to model. The «include» stereotype with the open diamond tells me I have a
collection. (I can post/update the previous posting with my current thoughts if you like.)
I'm still not convinced that the «manifest» link is a Dependency. But the Realization serves the same purpose.
So although these stereotypes have declarative purpose, as I previously described, I DO use them in my processing...
OK, Here is my shot #2 at the Diagram...
Using Stereotype names to re-enforce what the diagram graphics are saying is recognisably redundant so they make me wonder "What is special about this situation?". It had the effect of confusion rather than reenforcement.
I'd submit they aren't recognisably redundant...
Showing the full parentage of the Artifacts eliminated the need for <<artifactInstance>> and freed the stereotype field for more descriptive information. Not sure my descriptions are correct, but I put in my best guess to demonstrate my meaning here.
Assuming you grant my stereotypes as necessary to get around EA's lack of instance types. Then because I wanted to automatically colour my Classifiers and Instances I had to make them the primary stereotype. Since EA STILL doesn't show the additional stereotypes, you can't see the extra ones that do the same job as yours...
One point however, I didn't make any stereotypes that were language specific (as you appear to have done). This is for two reasons: 1) Language specification is already available as an attribute. 2) Stereotypes typically imply (require) behavioural differences - from the unstereotyped Classifier. I'm not currently expecting any.
I'm also not sure what the point of the Generalization from the unnamed artifact is. Can you elaborate on that? To me it seems unnecessary.
I used a manifest dependency instead of a manifesting realization in the hope that this is more correct. I think I may have the direction reversed though. I'm note sure...
I think the direction is fine. The Artifact manifests the Class. My feeling is that Dependency is not strong enough to represent the manifestation process or its outcome. I'm happy that a call to a Class in the Operation body of another Class can best be represented as a Dependency. Manifestation seems stronger than that to me. But we can agree to differ on this (and you DO have the benefit of conforming to the current standard
)
I changed the 'include' stereotypes to Aggregation names. This is more in line with the practice of designating derived associations during specalizations.
I used to do likewise, but in line with the notion that stereotypes imply behaviour, I've put them there. I could put just the derivation "/" in the name, but my emitter looks for it in both places...
An idea floating around in my mind is the applicability of the Composite Structure Diagram to model this stuff. I think an artifact can play a part in an internal composition... But then again, this may put the information you need for your emitter logic out of reach in the XML file.
Yes, it might well do. And no, it wouldn't be out of reach in the XML file.
By the way, is it an XML file or an XMI file?
Yes, it is a bespoke XML file with an accompanying XSD. I opted to avoid the XMI output as I wanted to communicate specific MEANING to the downstream processes. XMI is principally about content and rendering - which is fine for the job it does. I just need more
semantic grunt than XMI can supply. Besides, in line with decoupling the modelling from the generation, I'd still have to derive meaning from the XMI. Since this is (to my mind) a modelling related task, architecturally it sits better on the modelling side of the fence. So far it's working very well.
Your thoughts?
See above
