Messages

1

General Board / Re: Language Datatypes, Common Type, CONVERT_TYPE

« on: June 08, 2006, 09:25:44 pm »

Eventually, when the forum posted nothing, I filed a support request and here's what Simon replied (@ Sept, 9 2005)

You are correct that the common type is intended to correspond to a generic UML datatype.  However, as you correctly note, there is no validation of these types, and some of the ones included in EA don't seem to fit that description.  Currently, these common types are only accessible to users through the datatypes dialog, and only used in the CONVERT_TYPE macro.
 
With the language set to <none>, it is true that you don't get any primitive types listed at all.  However, you are able to enter the types in free text.  The CONVERT_TYPE macro only becomes useful when you are transforming your model to two different languages.  In this situation, it allows you to use correct datatypes for both languages.  Because language datatypes do not have a 1 to 1 mapping with common types, you may also need to modify the built in datatypes.  Either by modifying the common type, or introducing a duplicate type, and giving it a different common type.
 
We recognise that there are some problems to the way types are currently handled in EA, and have plans to improve many of them.

No further comment since... maybe you could persue?

cheers,
-olaf

2

General Board / Language Datatypes, Common Type, CONVERT_TYPE

« on: August 18, 2005, 10:05:20 pm »

When specifying new a language / product type --- and specifying its datatypes, I have a choice to add the "Common Type" as part of the datatype's specification. For example, for the Java language, and the pre-given 'byte' datatype, we find a Common Type of 'Byte'. Here's what the help page says:

The common type is the generic name of the datatype , for example the Java boolean datatype has a common datatype Boolean.

But, sorry, I don't quite get it. In Java, both are legal datatypes. Neither is any more common than the other. Then I thought, well, we might be talking about some common, "UML" datatypes --- common to all (implementation) languages; i.e. a platform independent type (see also below). But then amongst the C++ types I find a common type of "Uint" for the C++ type 'unsigned int' (and I am tempted to think that Uint can hardly by a generic, UML datatype).

Where does the tool list such common types? Where else can I find them? And, then, should I not be mapping common types to Java types; i.e. choose a common type, and specify to what I'd like that mapped to (rather than specifying the Java type and - optionally - entering a free-text common type)?

Lastly, let me talk about the CONVERT_TYPE model transform macro; here's the help file:

 CONVERT_NAME(<destinationLanguage>, <originalType>)  
  Will convert <originalType>, to the corresponding type in <destinationLanguage> using the datatypes and common types defined in the model.  
  Where:  
  · <originalType> is assumed to be a platform independent common type.  

This seems clear enough - and point to the interpretation that a common type is language-independent etc.; except...

When modeling (say) a class, one specifies a "language" for that class (why specify a language in a PIM?). Choosing <none> as the language gives me no primitive datatypes at all --- can't even specify an integer attribute (the only type choices are other classes).

Choosing a class language of (say) Java, gives me the complete set of Java language datatypes as expected. Of course, I am then modeling a PIM using Java datatypes. Further, what does the CONVERT_TYPE macro achieve? Converting my Java type to the specified free-text "common type", then converting from the common type to the respective target language type?

Could somebody please shed some light on this? Any comments greatly appreciated...

cheers,
olaf.

3

General Board / Re: Dependencies from operations to classes

« on: June 08, 2006, 06:45:01 pm »

Thanks guys, indeed quite helpful. More than anything, it gets the creative mind going... Something I didn't quite mention is that I am feeding the (exported) model into the AndroMDA generator tool... so there's a few other issues to consider.

What I ended up doing is taking up Paolo's idea, but I am also adding a stereotype of <<Throws>> to the dependency (which is picked up in AndroMDA).

In short, both suggestions most welcome...

cheers,
-olaf

4

General Board / Dependencies from operations to classes

« on: June 07, 2006, 03:33:56 am »

Hi all.

I have a need to model dependencies from (class) operations to other classes. Say, for example, an operation on a class might throw exceptions of sorts and thus is dependent on the exception classes. I would want to explicit represent this dependency in the model...

Is there any way to establish such dependency associations from operations? (Even better if they'd then be treated like any old dependency: stereotypes, etc.)

cheers,
-olaf

5

General Board / Re: Specialization of stereotypes in profile

« on: February 16, 2006, 01:47:40 pm »

except I forgot to give you a link... check this post http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1139897710;start=0#3 where Neil's (aka KP) post contains a link to the MDG Technology stuff...

6

General Board / Re: Specialization of stereotypes in profile

« on: February 16, 2006, 03:37:38 am »

Hi Jos,

well, don't be too rash in chucking away the idea of profiles. After all, the UML folks have come up with the idea for good reason... I have used it fairly frequently and can't really say that I've had any trouble...

But first to your original question: really, to re-phrase... the bug/problem seems to be a lack of inheritance across a stereotype class hierarchy... I cannot believe this to be a feature, I'd file a bug report with Sparx. Although I can see a use for it, I haven't used it myself. However, I would wonder that having that many tagged values that you worry about "tagged value sharing" through inheritance, there's something a little odd happening... after all, these are "extension" mechanisms to the intrinsic UML constructs, supplementation if you like, and not a mechanism to define a new language in its own right.

Now, back to your comment of not using profiles... Consider however, that when using a profile, your modeler can easily drag and drop stereotypes onto model elements --- and pick up any (pre-defined) tagged values (with their own enum values, defaults, etc.), color schemes, icons, etc. Further, it let's one person in the organisation define such properties --- and have it enforced across the entire group. Profiles are exportable, and can be re-imported into other models. Yes, I have found the 'sync' feature rather spurious (although generally not a huge issue).

Secondly, and this is something that I've learned only recently, I now package everything as a "MDG Technology". These are bundles that not only package profiles, but "global" tagged values, images, code and model transformation templates, data types into one convenient whole. "Technologies" can be exported and re-imported into other modelers' repositories.

In the most basic example, it lets you work on your modeling standards (your profile, or your MDGTechnology) in a "sandpit" model, refine it ad lib. and then simply distribute it to all modelers and their respective models.

cheers,
-olaf.

7

General Board / OCL constraints on operations

« on: February 15, 2006, 11:16:40 pm »

Hi all.

I am somewhat bamboozled by the entire OCL support offered by EA...

1. In all of the examples that I could find, it seems that its intended use is for model validation --- but I would've liked to express my own constraints through OCL. That is, express constraints on my own, real-life object instance populating the model.

2. Now, not being all too familiar with OCL, my first feeble attempts ended up looking like this:

Code: [Select]

body: self.allInstances()->select( i | i.number > number )
(in an operation, as a pre-condition; where number is both a class attribute as well as the name of the operation's input parameter; largely non-sensical and immaterial w.r.t. my question)

This generated "Invalid OCL" errors. Hmm... simple one would've thought. However, experimentation showed that

Code: [Select]

body: self.allInstances()->select( i.number > number )
worked just fine. What is happening here? Am I looking at the EA variant of OCL or is my understanding of OCL syntax incorrect?

3. Seeing that the syntax might be dubious, how about exporting such constraints to XMI? For instance, we are feeding EA models into AndroMDA - which translates constraints on operations into appropriate db queries. Can I attach a constraint to an operation without it being either a pre- or post-condition?

Comments, experiences anybody?

cheers,
-olaf

8

General Board / Re: Predefined Tagged Values for Profile

« on: February 14, 2006, 07:28:04 pm »

Neil,

excellent suggestion... In addition to the actual profile, I also have model transformations and code generation templates that should all go into one such technology "bundle". So, now I have a AndroMDA Technology packaging everything rather nicely.

Thanks again.
Cheers.

9

General Board / Predefined Tagged Values for Profile

« on: February 13, 2006, 10:15:10 pm »

Hi all.

I am trying to define tagged values - but make them specific to a profile. That is, the (pre-)defined tagged values will be available (only) when importing the profile.

First, during the definition of a tagged value, how do I designate it to belong to a profile?
Second, the profile package export, and the subsequent import as a profile, must import that correctly...

Or, alternatively, I could try adding Tag Definitions in (Settings -> UML) but how can I export / re-import those? Is this possible?

Any help mucho appreciated...

cheers,
-olaf

10

General Board / Model Transformation Problems

« on: January 03, 2006, 09:44:40 pm »

Hi all.

I am having a number of issues with model transformations; maybe somebody could venture comments / help?


The transformation auto-generates a diagram - which is re-generated / re-layout during each and every subsequent diagram. As the layout is more than atrocious (I don't think it could do any better), it makes the diagram kind-a useless.

But I'd like to further develop the resulting diagram - i.e. adding additional classes etc. - and have it not destroyed on every subsequent transformation.

Now, creating an additional diagram (using a different name but in the same package) seemed like an idea. But wasn't as any diagram in the transformation target package is re-layout along with the "primary" one.

So, here's the question: Can I prevent such auto-layout on transformation or, even at all times? Can this be found in the transformation templates?


When an association (of multiplicity > 1) is ordered, such ordering constraint does not appear in the transformed model. However, it transforms with the following intermediate code - showing, correctly, the ordering constraint:

Code: [Select]


     Target
     {
     XRef{namespace="DesignModel" name="Class" source="{FCBB24B1-BA78-4a1a-8642-F30F76B08147}"}
     access="Public"
     ordered="1"
     role="servicePath"
     multiplicity="2..*"
     aggregation="0"
     notes=""
     containment="Unspecified"
     scope=""
     }

Has anybody seen this? Is this a bug? Is this dependent on anything else (all I have spec'ed at present is: one-directional, cardinality on both ends, composite aggregation on the non-ordered / other end...)?


It seems that association classes aren't transformed correctly... Or, more precisely, the association class morphs into a stand-alone class, the association itself turns into a plain-vanilla association. Anybody can confirm this? Is this a bug?


Any help appreciated... cheers.
-olaf

11

General Board / Mapping Use Cases to Activity Diagrams

« on: December 15, 2005, 06:07:51 pm »

Hi there.

The EA online documentation shows how to map use cases to activity diagrams; let me quote:

"... it can be convenient to group activities into logical Use Cases. Enterprise Architect provides a convenient method of overlaying Use Cases onto activity diagrams while maintaining readability...".

The page is: http://www.sparxsystems.com.au/resources/map_uc.html

Further down on the same page I find:

"The Red bordered areas above are linked to existing Use Cases by setting the classifier. These 'Use Case Instances' then can be overlayed onto the associated Activities to indicate how particular business process is going to be implemented in the proposed system."

I believe this to be extremely useful in arriving at, and documenting, use cases and their design... but I have tried unsuccessfully to find more precise details on how to achieve this... i.e. given an activity diagram, given a use case, what are the steps to create such an use case  overlay onto an activity diagram??

Cheers,
-olaf.

12

General Board / Re: EA6 - export/re-import of diagram fails

« on: November 30, 2005, 08:00:54 pm »

Alright, here's the answer (for the record)... Sparx came back with a reply. Whew. Almost a show-stopper for us.

When exporting a package with 'Enable Full EA Roundtrip', the 'Export Diagrams' option (on the Export dialog) is not only not selected, but also disabled (i.e. not changeable for some unfathomable reason) --- tricking me into not really noticing it (or assuming its irrelevance). Therefore, the default behavior is to export packages without diagrams.

However, export of diagrams can be enabled in 'Tools -> Options -> XML Specifications'.

As if somebody would want to round-trip import/export of packages without being interested in any diagrams. BY DEFAULT! And, secondly, who would expect to specify such esoteric export options in a dialog titled "XML Specifications"?

Hmmm... I must be dense and not see the obvious.

cheers,
-olaf

13

General Board / EA6 - export/re-import of diagram fails

« on: November 30, 2005, 02:42:20 pm »

I have the scenario where I have a number of packages (which contain diagrams - use case, class, etc.) that I had exported previously (from v6 repositories) into xmi files.

Upon re-import these xmi files into a v6 repository, the package appears to import fine with the exception that all contained diagrams are "lost"; that is, they do _not_ import correctly.

Seeing that v5 xmi file import correctly into v6 repositories, and scanning the (exported) v6 xmi file for "diagrams", it appears that the export is where the failure already occurs (not in the re-import).

(This issue seems somewhat related to http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.pl?board=general;action=display;num=1132922234 but less severe...)

Can somebody else confirm this? Has anybody seen similar symptoms? (I have filed a bug report with Sparx which, of course, takes its sweet time...) Anybody suggestions as to a work-around?

cheers,
-olaf

14

General Board / Re: import / export of model transform template

« on: August 17, 2005, 12:15:46 am »

Well, one advantage of not getting an immediate reply is that one has to solve the problem on his/her own, right? Or, rather, think and do before post?

Now, for the public interest, here it is... suggestions and improvements welcome...

cheers,
olaf.

• Only changed / modified templates will be exported. The assumption here seems to be that _every_ EA model contains the same default set of templates - and thus only the modified ones need exporting.
  
• When exporting such (altered) templates, their ID is carried along; that is, the altered template is not so much identified by the "Transformation Type" (e.g. Java) and its name within that transformation type, but by its ID (or both - don't know).
  
• The previous point implies that simply exporting (say) some Java transformation, changing its name to (say) MyJavaTransform and re-importing will not work --- as the keys will be duplicates. (The importer reports duplicate key errors or some such).
  

So, if we want to prepare a model transformation that is to be imported elsewhere, the following procedure is the easiest to follow:

• In the sand-pit model, create a new transformation type; this will give you a half-dozen or so empty default templates;
  
• These empty templates now need to be populated with whatever you want them to do. If that is similar to (say) Java, well, cut and paste from the Java transformation templates (all within EA); yes, tedious, I know...
  
• Test proper functioning;
  
• Export the Transformation Type to file - using {{Tools->Export Reference Data}}; the newly-created transformation type will appear in the export dialog as "MyJavaTransform_Transform_Template";
  
• In the "target" model, import from file using {{Tool->Import Reference Data}} --- and hope like hell that the IDs haven't been taken up otherwise and are unique (although in the worst case, you could always manually set up the transformation type and cut and paste from the xml file ;-)
  
• Once the transformation type has been loaded into the target model successfully, repeated exporting and importing (for changes, improvements and such) is no trouble at all. In fact, this can be done bi-directionally.
  
• You might want to consider importing / maintaining such transformation types as part of "base" models such that any newly-created models (based on such a "base" model) will automatically pick them up during their creation.
  

Yes, I know, quite tedious... but, remember, after the initial export/import cycle the pain eases.

15

General Board / import / export of model transform template

« on: August 15, 2005, 09:58:17 pm »

I am trying to develop a new model transform template in my sandpit model, export the thing and then re-import it into the "real" model.

Now, the Java Transform template seemed a good starting point... first question:

1) how can I designate a new transform to be based on an existing one?

Well, I thought, all else failing, let's do the crude thing and export it (Reference Data export), change its name, and re-import it...  

Well, I had a look at the exported XML file. Hardly anything in it?! Certainly, I don't seem to see any of the "sub-templates".  Further, it seems that GUIDs and such are exported as well... In short, that doesn't quite look like the way to go...

So, question

2): what is the procedure to export a "complete" model transform template (including all sub-templates etc.)?

Any ideas? Help? Pointers to doco?