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 ... 350 351 [352] 353 354 ... 395
5266
Uml Process / Re: About association
« on: September 01, 2005, 02:07:54 pm »
Quote
Paolo;
I'm not familiar with your project.  What is the input to your process?
Hi Jim,

The output I produced above was the untransformed output from an EA Model via the UMLPlus Interface I've developed.  It's not the final product, but an other proof of concept to the final goal:  To produce artifacts (in various languages and in various formats) from a single source with as high a level of abstraction as possible.

One of the hardest things to produce would be source code.  So, in line with Agile approaches, that's the one I did first.

I have developed a set of modelling technologies that, I believe, allow me to create quite reasonable models of the world - which in Model Driven Architecture (MDA) terms are closest to Computationally Independent Models (CIMs).

We MDAers assert (and so far so good) we can follow the MDA chain and generate Platform Specific Models (like the output above).

As I mentioned I decided I couldn't wait for EA to catch up, and to be fair, I wanted to generate much more than code - a verbalisation of the model in English narrative, test instructions, other documentary artifacts which EA couldn't provide.  

Also, since my modelling technology is richer than just code generation, I needed to impart this metadata to the generators.  So I split the process in two:

  • Modeling  - using a suitable Modeling tool (EA), emitting the model onto a defined two way interface (in this case in XML - which allowed me to create a formal XSD which checks that the XML interface output is structurally and syntactically valid)

  • Generation - using a suitable set of generation technologies (CodeSmith + CodeDOM).

    This particular project started when I moved my CIM from Rose to EA.  I needed the verbaliser I had created in Rose to allow non-modelling Domain Experts to validate the business rules encoded in the CIM by reading the English narrative the verbaliser produces.

    Rather than embed the verbaliser as an Add-In (which I will do down stream) I decided it would be better to generate it off-line via the interface.  I then realised I could generate all sorts of stuff off the same interface if I made it a bit richer...

    Some colleagues couldn't get their heads around the concept so they challenged me to generate some code...

    Thus here we are...

    Now, since we are in a Supply chain, from CIM to PSM, the source model I'm currently outputting from is closer to a PSM than anything else.  When I sort out how to get a PSM across the UMLPlus interface, I'll look at getting a Platform Independent Model (PIM) across the same interface and performing the PIM to PSM transformation on the generation side of the interface.

    Since MDAers assert that you can take a CIM an via a repeated set of transforms create PIMs and PSMs, I should eventually be able to take a CIM (and transformation rules) across the UMLPlus interface and generate PSMs on the downstream side...

    Here's hoping...

    Paolo

5267
Uml Process / Re: About association
« on: September 01, 2005, 01:28:42 pm »
Quote
At what frequency do you emit new code? ;D

Good luck! Looks like a lot of fun waiting for you :)
Maybe as often as Microsoft?  ;D

Well, I went to bed a happy chappy...

Woke up early, a quick Google... 5 minutes of refactoring and:

Code: [Select]
//------------------------------------------------------------------------------
// <autogenerated>
//     This code was generated by a tool.
//     Runtime Version: 1.1.4322.2032
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </autogenerated>
//------------------------------------------------------------------------------

namespace Artifact1 {
   
   
   public class Class5 {
       
       private Enumeration Mary;
       
       public class Class4 {
           
           private Character Fred;
           
           private DateOnly Bill;
           
           private void Mary;
           
           private @void cxvzxcvzxcvx2() {
           }
       }
   }
}

8)




But wait... There's more!  8)  8)

A quick cut and paste, call a different provider and:

Code: [Select]
'------------------------------------------------------------------------------
' <autogenerated>
'     This code was generated by a tool.
'     Runtime Version: 1.1.4322.2032
'
'     Changes to this file may cause incorrect behavior and will be lost if
'     the code is regenerated.
' </autogenerated>
'------------------------------------------------------------------------------

Option Strict Off
Option Explicit On


Namespace Artifact1
   
   Public Class Class5
       
       Private Mary As Enumeration
       
       Public Class Class4
           
           Private Fred As Character
           
           Private Bill As DateOnly
           
           Private Mary As System.Void
           
           Private Function cxvzxcvzxcvx2() As void
           End Function
       End Class
   End Class
End Namespace


35 secs to add a new output language!

How cool is that?   8) 8) 8)

Now to actually make things work....

Uber Wrappt!
Paolo

5268
Uml Process / Re: About association
« on: September 01, 2005, 07:42:59 am »
Quote
The MODEL rules!

I just remember the way this is done in Rose. They put a lot of UIDs in the generated code, hoping to find a grip when climbing back. Unfortunately all this UID comments make the code hard to read and maintain.

Are you going to make a product of your emitter, Paolo?
The model RULES!

This evening, I started to create the portion of my process that actually emits code from the emitted interface.

An hour later, I was generating a C# artifact containing the manifestation of two classes in the model.  
Code: [Select]

//------------------------------------------------------------------------------
// <autogenerated>
//     This code was generated by a tool.
//     Runtime Version: 1.1.4322.2032
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </autogenerated>
//------------------------------------------------------------------------------

namespace Artifact1 {
   
   
   public class Class5 {
       
       private Enumeration Mary;
   }
   
   public class Class4 {
       
       private Character Fred;
       
       private DateOnly Bill;
       
       private void Mary;
       
       private void cxvzxcvzxcvx2() {
       }
   }
}


Unfortunately it's not correct, since Class4 is supposed to be nested inside Class5 but what do you expect for a (literally) first attempt!  This is the first output after the first clean compile.

Rapturously!
Paolo

5269
Uml Process / Re: About association
« on: August 31, 2005, 08:46:10 pm »
Quote
Paolo;
That did it.  I just needed to move the association lines.

Now, I'm exploring the mysteries of the code generator's reactions to all this stuff I've just learnt.  I'm getting a few surprises, but as I dwell upon them, I see a machine working logically behind the scenes.  I'm always surprised at the creativity of logic machines.

Now, I'm going to see if I can reconcile the machine's logic to the UML 2.0 spec.   ;D Might even get into the code generation templates too.  Wish me luck.  

Cheers
Luck doesn't enter into it.  It won't work... :-X  You may make some local gains, but eventually it will break.

I went through the same processes as you.  Fortunately I tested the CGT to destruction before I invested too much in its functionality.  The CGT is not sufficiently functional to emit code of sufficient richness.  AND it's NOT even used in reverse engineering!

NOTE: This problem is NOT unique to EA.  I believe it to be a general fallacy that round-trip-engineering from a model to pure code is possible.

I've taken the route of generation only, BUT through a decoupling interface.  So far so good...  Watch this space...

Paolo

5270
Uml Process / Re: About association
« on: August 31, 2005, 03:59:00 pm »
Quote
Paolo:

I thought a light bulb went on in my head as you explained that the three associations between Association and Property might not be redundant as they expressed different kinds of constraints on the relationship.  So, my discovery is that "more than one association line can be used to define a complex relationship"!  What a concept!  None of the UML books ever told me that.  Its kinda like association decomposition...(
At last, in UML 2, you can actually use Generalization between Associations, and set management also!  Now if EA would just support this... :(
Quote
In another thread, you mentioned that you have multiple class drawings,  each articulating a different aspect of the class.  Again, wow!  The books never mentioned that either!  This is good stuff!
In courses I've given (in Data Modelling), that has often been the feedback- they never taught any of this at University!  Gratifying certainly, and thank you for your feedback...  Like bruce, I've been threatening to write that book...
Quote
So I developed a model with two classes "A" and "B" such that A owned B.  Then I tried to add another association between them, but EA would not put it on the drawing!  It disappeared right after I released the 'clickndrag' button on my rodent???

How come??  :'(
Ah, grasshopper, consider this experience an exercise in how not to defined a unique user interface!  EA's strikes again...   ::)
Point 1:  You , as a user, have no direct access to connectors - so you can't tell if you actually created it or not.  That is, they don't appear on the browser (like in many/most other products)
Point 2:  If you don't move the first Association, the second will be created right on top of it.  So (visually), you "lose" the newly created Association.

If you can, re-layout the diagram.  EA will show you the two Associations.  If you can't layout the diagram (for aesthetic or other reasons), create a new diagram, drag both classes onto that and layout that diagram.

They should both be there!  If not, then you didn't actually create the second Association.  On the diagram, move the original Association first, then create the other.

HTH,
Paolo

5271
Uml Process / Re: About association
« on: August 31, 2005, 07:26:04 am »
Quote
Paolo;
I love your allegories here.
Thanks Jim, I try to figure out simple rules that allows me to make better models.  Making "industrial strength" models is not trivial (but it 's also not rocket science).
Quote
So, in an association between two classes, the black diamond identifies the class which owns the association (including the end properties), but says nothing about who owns the associated class?  If true, I think this is good.  I'm thinking that Ownership, Nesting, Containment, and Collection are Structural issues then, not associative issues.

I can see then, that when a class which owns an association is immolated, it has an option to destroy the association link, but then again, it may not.  This seems to set up some referential integrity issues for me in that the objects being referenced no longer exist, but the link between them does?  Or worse yet, one object still remains with the association, but the other end is unconnected?  In Figure 12, the cardinality of the association between Class and Property seem to allow this, or am I reading this incorrectly?
No,  I haven't made myself clear enough.  Both Classes determine the existence of the Association (as a concept).  If either is removed from the model, then the Association must be removed.  The filled in diamond DOES determine whether the instance of the Class at the diamond end CAN destroy the instance(s) of the Class at the other end.

Quote
In Figure 12 again, I'm also bemused by the fact that both the association and the associated class may own a given End Property (as well ad the association itself) as both of them have black diamond ends on their links to Property.
Alles ist in ordnung here... (apologies Thomas :)).  Remember, the Property is both the AssociationEnd and the Attribute.  If I delete the Attribute, I'm deleting the Property and thus I'm deleting the AssociationEnd and therefore the Association.  On the other hand, if I delete the Association, I delete the AssociationEnd which deletes the Property which deletes the Attribute!  This is in line with my assertion (elsewhere in the forum) that an AssociationEnd and an Attribute are just different renderings of the same Property.  I said it in words, Figure 12 says it graphically.

Quote
All of this is making me wonder just what a Property Class represents?  The model says it is a specialized StructuralFeature, but does it exist in code somewhere or is it simply a concept that controls the generation of the code?  Are the terms End Property and Association End synonymous?
See preceding...

Quote
Who would have thought that a simple line on a diagram could be so complex?  ;D  Try explaining all of this to a first year college student!  ::)
That's the power of modelling.  With apparently simple symbols and rules we are able to construct models of suitable complexity to take a meaningful stab at describing the world.  What's known in MDA terms as the CIM - Computationally Independent Model.

Quote
I'm beginning to think we need to fork this thread into several sub-threads...
I'll leave it up to you to create the forks...

Quote
Here's hoping my questions are worthy of your attention.  ;)
As I said before...  Besides, for me, having to explain it means I'm forced to make sure I have a decent stab at having Consistency, Consistency, Consistency! TM in my understanding...

HTH,
Paolo


5272
Uml Process / Re: About association
« on: August 30, 2005, 05:00:29 pm »
Quote
Thanks Paolo.  Your comments help, but I'm not there yet...  I'm (1) zeroing in on ownership; and, (2) wishing I could understand Figure 12, as well as the other metaclass diagrams,  better.

It is becoming clear to me that containment of an element does not imply ownership of it, nor does access to it.  So ownership of an element simply provides rights to exert control over its accessibility by others, and the element's creation and destruction?
Yes Jim,  essentially I believe you're right.
In various discussions on meronymy associate connectors when reverse engineering I believe we need to clearly distinguish between:
1) Ownership: I control you (including who can access you and who create and destroy you)
2) Nesting: You cannot be accessed, except through me
3) Containment: I hold you within me - but you are not of me
4) Collection: You are in a group

Quote
Can you help me to read Figure 12 better?

In Figure 12, considering the link between Property and Association, the ownedEnd of the link is attached to that which is owned (Property), and the owningAssociation end is attached to that which has ownership rights (Association).  But the question is "What is being owned here?", for when the Association is destroyed, something else is destroyed too.  Does the Association own the link between itself and Property, or is the link notation saying that Association owns a Property?  I guess the circular definition is confusing for a link is an association.

The associationEnd (the Property) is what is being owned (by the owningAssociation).  The link is automatically destroyed (by a sort of garbage collection) when either end is destroyed.
Quote
To my imperfect mind, of the three links between Property and association, the first is navigable in both directions, the second is also (but adds aggregation to the mix) and the third is only navigable from Association to Property.  These three links seem both redundant and contradictory to me.
Ah, now you've touched on what I believe is a deficiency in the UML specification with regard to rendering.  There is no visible difference between the rendering of "navigable in both directions" and "navigable in neither direction".  I'll leave it as a exercise for the reader to determine what navigable in neither direction could mean...  ;D
However, since the Association has both ends named, in this instance it is navigable in both directions as you suggest.  Similarly, for the second one.  I have written elsewhere, that in my view, the "composition" indicator in a UML model actually merely describes whether the end with the indicator (the whole) can destroy the other end (the part).  The third is navigable only from the Association to the Property.

Now to the meat of your question.  You are right to suspect redundancy, but it is at the instance level.  The way to "read" the relationships between the Association and the Property is (in my view):
An Association is both a Relationship and a Classifier.
An Association has at least two members (which are Properties)
Some (possibly none) of those members can be owned by the Association
Some (possibly none) of these owned members are navigable.

So you see, the semantics of each of the Associations becomes progressively more restrictive, although any given link could participate in more then one Association.

Quote
And, looking below the Association, why is the type classifier not associated with the end property?  or, is that what the association element is doing, or is that what "+/endType {ordered}" means?  ???
Each Association has a manifold, derived, Attribute called endType.  It's not connected to the property because it isn't the type of the Property, it's the type of the Classifier at the end of the assocationEnd (I think).
Quote
I have more to ask, but I must deal with an unowned element called work.   ;D  Later.....
There's no such thing as a stupid question... ;D

HTH,
Paolo

5273
Uml Process / Re: About association
« on: August 30, 2005, 04:51:03 am »
Quote
[size=13][SNIP][/size]
if association ends don't have property in the associated class, then this is non-navigable association, is what you want to say, Paolo?
Yes,
just remember, the property is in the class at the client end (opposite the arrow!).

BTW, In order to ensure that the model correctly understands this, you need to "DRAW" (not render) the association from the client to supplier.  There was quite some discussion in the forums about 4-6 months back regarding differences in drawing philosophy amongst various tools, and users!

HTH,
Paolo

5274
Uml Process / Re: About association
« on: August 29, 2005, 06:59:00 pm »
Jim,

Get a hold of: the UML 2 Superstructure Specification.  This is the latest and greatest.

On page 29 (47 of the PDF) you find: Figure 12 - The Classes diagram of the Kernel package

This helps explain what's going on...

7.3.3 Association (from Kernel)

[size=13][SNIP][/size]

Description
An association specifies a semantic relationship that can occur between typed instances.

Figure 12 shows that the Association is both a Relationship AND a Classifier.

It has at least two ends represented by properties, each of which is connected to the type of the end.

In UML, Properties are what Attributes are made of.  They are also what member ends of an Association are made of.  This is why UML can say, a "A navigable, named association end IS an attribute."  Thus the list of members is the list of columns in the tuple.

More than one end of the association may have the same type.

This just says you can have Associations between instances of the same Class.

An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.

If, when you delete the association, you also delete the nominated attribute then you have an ownedEnd.  The end is owned by the owningAssociation. The equivalent ownedAttribute is owned by the Class, but it disappears none the less.
Some of these Attributes are navigable (essentially By Reference) others aren't (By Value).

Does that help?

Paolo

5275
Uml Process / Re: Diagramming Artifacts
« on: August 31, 2005, 03:38:55 pm »
Quote
The workflow description was just information to help understand the diagram but the diagram is not suppose to show a workflow - its only suppose to show dependencies between files.

What I am trying to do is to document the physical files involved in the process so that later when I need to change something, I know what files need to be changed.

But, if I only put in the files and exclude the database tables that are within the database file then I will not have enough information in the diagram to understand that table "ClientTermSC" needs to be referenced by the word document "ForIndexing - Term Letter...."

That is why I showed the tables in the diagram even though they are not actual files.
Bill,
As it happens, this last week I've been playing with artifacts and components and model elements.  In order to generate (in this case source) Components, I need to know which Classes are in which Artifacts for which Components.   For a Source Component (Folder), there are typically many Artifacts (files) composed of many Classes.
UML provides a Manifest relationship to say that a Classifier is manifest in a specific Artifact.  However, conceptual analysis suggests this is a ternary and not a binary relation.  Thus I use an (N-ary) Association lozenge to relate a specific Class, to a specific Artifact for a specific Component, using 3 AssociationEnds (I simulate AssociationEnds by creating an Association from the Association(Class) to the Class (or Component or Artifact) but placing the filled in compositional filled-in diamond on the end opposite the Association(Class).  The AssociationEnds are (currently) stereotyped end, and the Association(Class) stereotyped manifestation.

This would seem to be analogous to your requirement where you want to document which Tables are in which Databases for which Process.  You could stereotype your Association(Class) involvement.

HTH,
Paolo

5276
Uml Process / AssociationClass & Operations?
« on: August 29, 2005, 07:51:34 pm »
Following on from Jim Shaw's question about Associations, it got me wondering...

Can an AssociationClass have Operations (methods)?

I've never really thought about it much, but from memory, all the ones I've created had only Attributes (or at most Setters and Getters for equivalent Properties).

Thoughts anyone?

Paolo

5277
Uml Process / Re: Diagram Stereotypes
« on: August 29, 2005, 02:25:16 am »
Quote
I'd just populate the diagrams according the rules, call AutoLayout and do the rest manually.
Sorry, Thomas, I didn't explain myself well enough.  I might have a number of Class (Structure) diagrams - each one show some specific aspect of a class (or classes).  They are all the same type of diagram, bu they have different content (almost behaviour) - hence the stereotype.

Typically for each class I have a number of standard diagrams:
classDefinition
classSubtypes
classPolicies

(I won't enumerate the different rules that apply to these three).

I'm after the "extra" rules people use within the confines of the diagram type (that I think) you were meaning.

Cheerz,
Paolo

5278
Uml Process / Diagram Stereotypes
« on: August 29, 2005, 12:33:58 am »
I'm starting to Stereotype my diagrams.  For example, I have a diagram that shows how all the classes in a namespace interact.  I've stereotyped this as «namespace».  
For diagrams with «namespace» stereotype, the following rules apply:
  • Show ONLY classes in the namespace
  • Classes expose public features ONLY!

    Another is «classDefinition» (typically created when you make the class "composite"):
  • Central class has "everything" showing.
  • Show all elements within one level of relation to the central class, these show no elements, unless useful for this class.

    The idea is that an automaton would investigate the stereotype and apply the defined rules.  Initially, the automaton would be ME! ;D  (No jokes please!)

    Do you have a favourite diagram layout (or algorithm) you use?  Please describe it in your reply and assign a stereotype.

    Cheerz,
    Paolo

5279
Uml Process / Stereotype name casing - suggestions?
« on: August 29, 2005, 12:15:11 am »
Hi,

I'm trying to standardise the casing on my Stereotype names.  Consistency, Consistency, Consistency! TM
The UML 2 Superstructure Specification requires no specific casing, but it seems they imply camel casing (first letter lowercase, subsequent words title cased).

EA, as usual, is self-inconsistent.

My tendency is toward camel casing for Stereotype names.  What do others think (and why)?

Cheerz,
Paolo

5280
Uml Process / Re: Default multiplicity
« on: August 26, 2005, 05:58:55 am »
Quote
What default multiplicity is in the UML2?
I though, that it's 1, but today in UML2 infrastructure (8.2.2 section) found this statement:

When directed associations are specified in lieu of attributes, the multiplicity on the undirected end is assumed to be ‘*’
(default in UML) and the role name should not be used.
SF,

It means what it says.  The association should be drawn from the client class to the supplier class.  The directed end is the navigable end - which is the supplier (or in EA terms, the target end)  The undirected end is therefore the client (or source) end.  The default multiplicity on the client end is "*".

If the association is bidirectional there is NO undirected end and thus the statement doesn't apply.

HTH,
Paolo

Pages: 1 ... 350 351 [352] 353 354 ... 395