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 ... 399
Uml Process / Re: Properties, Attributes and Slots
« on: September 28, 2005, 04:44:43 am »
No, Jim...

From the Infrastructure document:

A property is a typed element that represents an attribute of a class.

The Superstructure document has similar statements.

So, the first clause of your statement is incorrect.

However, Attribute is to Class as Slot is to Object.


Uml Process / Re: Associating UML Elements across diagrams
« on: September 24, 2005, 04:37:46 pm »
Hi Paolo, interesting responses. And they prompted me to do more research (and as you suggested) think about what I wanted to do.
WARNING! According to Dijkstra, the more you think, the less you have to do!  8)
And so I think that the Nested Classifier is the right way to go for what I'm trying to do.
Hi Paul,
If nesting is one approach you intend to use, you might want to look at: [size=13]Collections, Containers, Composites & Nests[/size] for some thoughts on Nests.  It would be good for you to provide feedback on the new nesting link, in the light of your experiences - especially with the behavioural Classifiers.  So far I've concentrated on Structural ones as I'm trying to emit existing code - without yet refactoring.


Uml Process / Re: Associating UML Elements across diagrams
« on: September 23, 2005, 07:21:20 pm »
I want to be to do the following:

1. Link a State (from the State Chart) to the Class for which it applies.

2. Link an Action (from an Activity Diagram) to the State Transition it causes.

3. Link a Component (in the Component Diagram) to the Classes it encapsulates.

There doesn't appear to be a default/formal way to do this (happy to hear about it if I'm wrong).

So the alternative I'm looking at is to create Links for each of these cases, either using a custom Stereotype or one of the existing ones (with a note).

Embedding in some note field is not good because it's not visible on the diagram and I'd like to be able to report and transform based on reliable meta-data.

If anyone out there wants to share their thoughts/approaches on this I'd welcome them.

Much appreciated.

- Paul
Notes should be avoided, if at all possible.

One of EA's nicest features is the Feature Linked Note which just manifests the information in the Element.

Paul, you need firstly to decide what is the nature of the relationship between the two elements in each of your three cases.


One could argue that a State is Nested in the Class to which it applies.

Similarly an Action Realizes the StateTransition.

Lastly, UML sates that an Artifact «manifest» elements.   It also states that a Component is a Classifier (and therefore not an instance) [size=13]Classifiers vs Instances[/size] addresses this.  That is not to say there isn't a relationship between the Component and Classes, it's just, in my view, a derived one.  In my models, the relationship goes from Component to ComponentInstance to ArtifactInstance to Artifact to Class.


Uml Process / Re: External File Situation --- HELP!
« on: September 22, 2005, 07:10:52 am »

Why can't you make several projects in one repository?  Or have I misunderstood your starting position?

You should be able to use XMI to export each project from it's repository and import it into the common repository.


Uml Process / Re: Classifiers vs Instances
« on: September 21, 2005, 02:01:21 pm »
Well, now I understand your diagram even better.  ;D

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
Given your last comments, it probably is not necessary.  I was using it to re-enforce  ;) the notion that the decedents from it were Artifacts and artifactInstances, thus freeing up the Stereotype area for other uses.

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.
I understand this in the context of artifacts, but not in the case of components.  In my diagram, in the <<project>> object, when I select the option to 'Set instance classifier', I'm finding the components, but not artifacts,  listed and usable.  Can you explain further?
To paraphrase a famous (and recently deceased) comedian here in OZ... "It's a bug Joyce..."  (They ought to be there.  I fixed it by jamming the database)
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.)
Wow!  Yes, please do!  I'd be very interested in that.  I've been concerned about this UML deficiency.

You'll find it at [size=13]Collections, Containers, Composites & Nests[/size]
I think I need to see your take on the definition of manifest and manifesting process.  The UML Superstructure is a bit too abstract for me.  Coming from a RUP methodology background, my understanding is that an Artifact is a product (document, Source code file, etc.) that specifies something in the problem's solution domain.  They are the deliverable products of Analysis & Design.  Artifacts don't Do things, they just constrain other down-stream processes.  (is 'constrain' an action verb?  :-/ ) To me, the verb manifest is similar to specify or constrain an activity by describing the nature of product the activity is produce.  Thus, in my view, a process that instantiates an object and the object's behavior itself are manifestly dependent upon the artifact(s) that define it.
Manifest: to make evident or certain by showing or displaying.  We thus manifest the Class by placing a rendering of it into the Artifact.  To me it's about the relationship between the supplier (Class) and the client (Artifact).  Technically, it could be argued that the ArtifactInstance is a composite that contains Class rendition ArtifactInstances, but I've suppressed that for this level of detail.
But then again, your diagram is a static one that does not show processes.  It shows the structural relationship of elements that came into existence by off-diagram processes.  So is it the process or the process product that is dependent upon the manifesting artifact??!!  Gosh!  this stuff is smoky!  Can you clear the air?
Hopefully, the previous segment should have clarified it.


Uml Process / Re: Classifiers vs Instances
« on: September 21, 2005, 04:58:01 am »
Well, as we go along I may have a few more  :P
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... ;D
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 ;D)
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 ;D

Uml Process / Re: Classifiers vs Instances
« on: September 20, 2005, 12:40:25 pm »
OK, I'm back after a good night's sleep.  :)

I think reading your model is best done in the context of your product which, if I understand correctly, emits a source code file given a UML model in the EA Repository.  One of my mistakes last night, being an application developer, was to treat the *.cs file as a starting point rather than an end point in your process.
Yes, I also get confused from time to time.  Normally I work purely in the world of CIM - creating models that describe the world and its rules.  But in this case, I have to get closer to the road.  :)
Shouldn't there be a level of Specialization between the components and their instances to account for emitting various languages?

I have a slightly different notational preference, but my audiences are different than yours.  You are re-enforcing points with Stereotype names, where I prefer to use graphical reenforcement.
Yes, there probably should.  I think you mean that there should be a subtype of the (platform independent) Component that is the C# view of the Component (from which I suppose one would deduce the transformational metadata to create the C# ComponentInstance.  I've left that out for now as I'm trying to actually emit some code.  :-)  Once I've got code coming out, I'll refactor to include that I guess.  In addition, since that transformation is actually taking place downstream of the model there's not much point in specifying that in detail as the link between the model and the code generation is currently pretty much hard coded.  All I'm trying to do here is to tell the generator what artifacts to generate where (in which components) using which model elements (classes, interfaces, namespaces etc).
Otherwise, your model makes sense to me.  :)
Does that mean I don't need to explain it any more? :)
However, since I've just implemented the code to traverse it, I'll mention it, in case you can find any improvements or corrections.

I emit the model as a whole.  I tell the generator to generate a particular component.  The generator searches the model for the component, follows the «instance» Realization link to the ComponentInstance. Then for each «include»d ArtifactInstance, follows the «instance» Realization link back up to the Artifact (there didn't seem much point in repeating the same metadata at the Instance level so I transitively apply it to the Instance from the Classifier).  For each Artifact, I follow the «manifest» Realization links to the Classes and Interfaces involved and emit them (in the appropriate language object) into (nest) the ArtifactInstance specified previously.  In addition, I follow any «using» or «alias» Dependencies between the Artifact and any other linked Classifiers to create any

"using namespace_or_type;" and any "using alias = type_in_namespace" directives (as required.

I haven't quite got the last bit working yet...  But the basic traversal is working.


BTW, since you now follow my model, would you care to show me your version in your notation?  I always like to "compare and contrast"

Uml Process / Re: Classifiers vs Instances
« on: September 20, 2005, 02:24:41 am »
Your diagram almost makes sense, it is not too far from what I diagrammed.

I'm having trouble with your use of <<Instance>> associations.  I thought, in another thread topic, it was agreed that instantiation of a class was a realization of that class..??  My version of EA provides predefinitions of <<Instantiate>> and <<InstanceOf>>.  
From the Superstructure 10.3.10:
I'm just now becoming aware of the manifesting relationship.  Wish I could internalize its definition better.  However, from the same section:
I'm not sure I understand your stereotyping on the associations...But, it is after mid-night my time and I'm not thinking clearly at the moment.
I'm leaving work, so I'll be quick for now...  

Jim, they're NOT Associations with the «instance» stereotype, they're Realizations!  But since it was late at night for you, you're forgiven... ;D

Also, these «instance» are a graphical representation of the fact that the object is an instance of the classifier.  They're an adornment to my models.  They are the graphical equivalent of the Object:Class textual adornment.  I think it's important (if the modeller so desires) to show more emphatically than just Object:Class that this Object is of that Class.
Can you provide a textual walk-through of your diagram?  

I'm off to bed...will be back in the morning with a sharper mind.

G'nite mates!

Uml Process / Re: Classifiers vs Instances
« on: September 19, 2005, 08:56:50 pm »
The real question is whether a classifier can be an instance of itself.  IOW to you I put the following - can your emitter emit itself?
I've been diverted to another project, but the first thing my emitter will emit IS itself!

I'll reverse engineer the working emitter.  Add the additional metadata and then re-emit itself and rebuild...

Wish me luck!


Uml Process / Re: Classifiers vs Instances
« on: September 19, 2005, 08:52:41 pm »
This is going to be pedantry so ignore it if you will.
In fact each and every classifer in a model is an instance of the meta-classifier "classifier" (or UML would not work!).
I stand erected! ;D


Uml Process / Re: Classifiers vs Instances
« on: September 19, 2005, 07:04:45 pm »
OK Jim,

I'll see your diagram and raise...  ;D

Seriously though, I hope this makes sense because this is how I'm implementing it and traversing the model to emit the code...

As a consequence of the source file manifesting the class, the C# instance must create an instance of the class and nest it.  So, if I open my VS 2003 Solution, I'll find a EAUPXMLEmitter Project inside which I'll find a CEAUPXMLEmitter.cs file with the CEAUPXMLEmitter class within it.


FWIW:  The three classifers on the left are examples of a PIM (Platform Independent Model).  The three instances on the right are PSM (Platform Specific Model) instances.

Uml Process / Classifiers vs Instances
« on: September 19, 2005, 04:11:07 pm »
The UML 2 Superstructure Specification (abridged) states that:
7.3.8 Classifier (from Kernel, Dependencies, PowerTypes)
A classifier is a classification of instances — it describes a set of instances that have features in common.

So, a Classifier can't be an Instance.

An Object is the Instance of a Class.
A Component is a Classifier - so the instance is a ComponentInstance?
An Artifact is a Classifier - so the instance is an ArtifactInstance?

What do these mean?

I've rationalised it as:  I have a Component called "EA Model Emitter".  I have a ComponentInstance called that "EA Model Emitter in C#".
I have an artifact called "CEAUPXMLEmitter" which is one of the source files that make up the artifact.  I have an Artifact Instance called "CEAUPXMLEmitter.cs" which is CEAUPXMLEmitter in C#.

Does this make sense?

Assuming you think it does, how do I represent these instances in the EA diagram?

I've resorted to stereotyping Objects with the appropriate names «componentInstance» and «artifactInstance»

Any better ideas?


Uml Process / Re: Manifestation as Realization
« on: September 20, 2005, 02:05:57 am »
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.  ;D
That's a relief! ;D
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 1 (at a point in time) of the facts/information held within the system.
...or thats what I think anyway...
Aye and good and welcome thoughts they are too!

Keep 'em coming...


1Or possible a manifest snapshot!  ;)

Uml Process / Re: Manifestation as Realization
« on: September 19, 2005, 10:11:04 pm »
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.

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 ;D) then what are they?


Uml Process / Re: Manifestation as Realization
« on: September 19, 2005, 08:50:10 pm »
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


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).


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