Messages

1

Suggestions and Requests / Re: Crete subtopic by theme in general board

« on: May 01, 2007, 11:57:19 pm »

I totally agree.

2

Suggestions and Requests / Re: Improvements for tagged values

« on: February 22, 2007, 12:55:30 am »

to 1.)
I see your point, IMHO it would faciliate the meta model development process. Otherwise meta modelling has to be more or less copleted before modelling can start. What about a new function doing the deletion of tagged values that do not appear in the meta model?

to 2.)I understand but what is the list box for then, if the stereotype is not applied? The message box you suggest, is a good compromise ;-)

3

Suggestions and Requests / Improvements for tagged values

« on: February 21, 2007, 09:17:20 am »

1. Sychronisation
Sychronisation can not handle the renaming of tagged values.

If an attribute name was changed and the profile is reimported and the tagged values are sychronised all elements that have the associated stereotype get the new tagged value, however the old one is not deleted. So you have to browse through all of your diagrams and delete the obsolete tagged value.

2. Applying stereotypes is not consistant
In my UML profile I extended the Meta Class "Activity Parameter".

Now as far as I have understood, I have two possibilities to apply this stereotype.

a.) create an element of type "Activity Parameter" (e.g. right click on Activty element --> Embedded Elements --> Activity Parameter) and in the field Stereotype select/fill in the custom ActivityParameter stereotype you have created in your profile or

b.) create an element of type "Activity Parameter with no indication of a stereotype. Then from your profile folder drag the stereotype on the element you have just created.

For me only b.) works a.) does not. The taged values of my activity parameter are not applied.

4

General Board / Re: XML schema import frustration

« on: August 21, 2007, 11:38:46 pm »

Please do it if you don't mind. I think you have a more complete insight in the topic.

5

General Board / Re: XML schema import frustration

« on: August 20, 2007, 09:04:10 am »

Is there any way at all to model an <<XSDimport>>?

I tried manually by nesting one schema package into the other and then drawing an "dependency" of stereotype <<xsdImport>> from one package to the other. But unfortunatly EA's XSD Schema Generator does not recognice this (according to David Carlson's suggestions for an XSD UML-Profile, which EA claims to be based on, it should work like this).

6

General Board / XSD Template: Generation of ref element

« on: August 17, 2007, 07:26:52 am »

Hi,

I would like to do a XSD-transformation of an 1:N association from class A to class B .

For this association a ref element should be created in the describtion of class A with the attributes minOccurs, and maxoccurs set according to the multiplicity of the association ends.

This is what I expect:


<xs:complexType name="ClassA">
 <xs:complexContent>
   <xs:sequence>
     <xs:element ref="ClassB" minOccurs="1"  maxOccurs="unbounded"/>
   </xs:sequence>
  </xs:complexContent>
 </xs:complexType>

Instead I get:        

<xs:complexType name="ClassA">
 <xs:complexContent>
  <xs:sequence>
    <xs:element name="ClassB" type="ClassB" minOccurs="1" maxOccurs="unbounded"/>
   </xs:sequence>
 </xs:complexContent>
</xs:complexType>

What I want is what has been presented in the XSD TRANSFORMATION help section, but to me it seems that EA actually behaves differently (?)

I am willing to write my own custom XSD transformation template to generate the addition ref element in classA, but   I don't know how to do that. I can only determine the multiplicity of a class when transforming the connectors, but how can I add an attribute (the ref element) to a class at that time?

Any help is appreciated! I guess this is a well known problem.

7

General Board / 7.0 Trial version installation problem

« on: August 06, 2007, 01:20:40 am »

Hi,

I have a (licenced) 6.5 version of EA installed, now I wanted to evaluate version 7.0 for my company. However, after a side-by-side installation, EA Trial 7.0 does not start saying that my evaluation period has already expired. What am I doing wrong?

8

General Board / Re: Assigning behaviour diagrams to State actions

« on: June 11, 2007, 12:57:09 am »

how to assign a Behaviour Diagram such as a Sequence or Activity Diagram to an action such as entry or exit inside a State

I needed the same for my project. My workaround was the following:

Inside the state I defined my operations as "Structured Activities". However the state does not recognize the "inserted "activities automatically.
Therefore I made this hierachy visible by dragging them below this state in the project browser.

If you find a better way, please post it here.

9

General Board / Re: Code generation of classes and interfaces only

« on: May 02, 2007, 11:14:07 pm »

Thanks a lot for giving me a "jump start". I will try to do it  with a plugin as you suggested.

10

General Board / Re: Code generation of classes and interfaces only

« on: May 02, 2007, 02:58:33 am »

Thanks for your answer. Sounds quite complicated. The code fragment I want to generate is rather small, I would prefer a more direct way (although I am quite interested in your mre general solution as well).

You say, that you think it is possible to generate code from behavioural diagrams with the Code Generation Framework. Cna you give me a hint, how?

Thanks in advance

11

General Board / Code generation of classes and interfaces only?

« on: May 02, 2007, 12:15:56 am »

Hi,

I would like to use EA to generate source code out of activity diagrams / state diagrams. However, I had to read in the user guide that code generation is only suppported for classes / interfaces.

If this is right, is ther any possibility in EA to generate source code out of other UML elements than classes and interfaces?

12

General Board / problems with XSD Schema import

« on: May 02, 2007, 04:49:02 am »

Hi,

When importing a XSD-Schema I observed the following phenomenons:
(1)
For all complexTypes (I tested only those) only xs:attributes are imported, that have the "type" attribute set. When the type-attribute is missing, the whole xs:attribute is omitted during import.

(2)
The value of the attribute "fixed" of the xs:atttribute  is not evaluated during import.
I expected that the attribute "fixed" for an xs:attribute would result in a class attribute that has
(a) the flag "const" set
(b) its "initial" value set to the value of the xs:attribute attribute "fixed"
Instead the attribute is created without these properties.

Is this a bug?

13

Uml Process / Re: Nesting /  Deviding of UML Profiles possi

« on: November 06, 2007, 06:58:34 am »

No new improvements as far as I know.

I did a (terrible) workaround:

I moved the abstract stereotype from the astract profile to the concrete profile, saved it as UML profile, and then moved it back to the abstract profile. Awful, I know but the only way.

Moreover there is another bug that may cause profile problems (at least in 6.5). Here is the copy of the bug description (workaround included) I posted on EA bug report page:

ISSUE DETAILS
>
> Subject:  
>
> Inheritance of attributes in exported UML Profile
>
>
> Details:  
>
> It may happen that a super stereotype is written below its
> sub stereotype in the exported UML-Profile.
>
> If this is the case then the values of the super type are set
> for instances of the sub stereotype instead of applying the
> value of the substereo type.
>
> An Example:
>
> Stereotype <<Parent>>
>   attr1 = ""
>
> Stereotype <<Child>> generalises <<Parent>>
>   attr1 = "childvalue".
>
> In the case of error if this profile is saved and used later  
> for modelling, an element of stereotype <<Child>> has an
> empty tagged value "attr1". Expected is attr1 = "child".
>
> A soon as you "manipulate" the exported profile in such a way
> that the element of stereotype <<Parent>> is above <<Child>>
> in the xml structure, and reimport this profile, everything works fine.
>
> However I could not find out, why (suddenly) my <<Parent>>
> stereotype is not on top of <<Child>> anymore.
>
> I know that one cna change the order of stereotypes before
> export however this applies for "concrete" stereotypes only,
> not for abstract one (my case).
>
>
>
> Steps to Reproduce:  
>
> Create a profile as described in the example above, if
> <<Child>> is below <<Parent>> change the order manually in
> the xml file and then Import it  in EA.
>
> Create an element with the stereotype <<Child>> and check its
> tagged values.
> Error is succsessfully reproduced if attr1 as no value.

14

Uml Process / Re: Nesting /  Deviding of UML Profiles possi

« on: June 12, 2007, 01:25:29 pm »

You are right, in my little example "Function" and "Message" have nothing in common, but what if they had.

Let's say we introduce an abstract stereotype in between (this is actually what happens in my profile).

So the example would look like the following:

<<profile>> Main
- <<metaclass>> Action
- <<stereotype>> AbstractAction (extends Action)
- <<stereotype>> Function (derived from AbstractAction)

<<profile>> Messages
- <<stereotype>> AbstractMessage (extends AbstractAction)
- <<stereotype>> Message1 (extends AbstractMessage)
- <<stereotype>> Message2 (sxtends AbstractMessage)

There is no way to make this working, right?
The only way is  to "dublicate" Action and AbstractAction for the profile Messages, however I can not "share" the AbstractAction between the profiles and by this "inherit" the metaclass Action.

15

Uml Process / Re: Nesting /  Deviding of UML Profiles possi

« on: June 10, 2007, 08:56:00 am »

I comprehend your approach however it does not fully solve my problem regarding the "reusage" of one metaclass in several profiles. Your approach explains how to bundle several profiles together however there nothing like a "hierachy" inside.

In my opinion it lacks the following usecase:

I would like to express in my profile that an Action is either a "Function" or a "Message".

<<profile>> Main
- <<metaclass>> Action
- <<stereotype>> Function (extends Action)

<<profile>> Messages
- <<stereotype>> AbstractMessage (extends Action)
- <<stereotype>> Message1
- <<stereotype>> Message2
...

With your appproach I have to add the metaclass Class in both profiles. Otherwise the stereotypes of the profile <<Messages>> are not exported, right?
However then I loose relation between Messages and Functions, because there is no hint anymore that they extend the same metaclass (Action).

Did you get my point?