Author Topic: EA 6.0 (beta)  (Read 6098 times)

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6285
  • Karma: +52/-5
    • View Profile
Re: EA 6.0 (beta)
« Reply #30 on: November 01, 2005, 09:20:08 pm »
Sorry Bruce.  I missed that.

However, I had already mentioned it in a previous post.  (the 15th reply in this topic)
Simon

support@sparxsystems.com

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: EA 6.0 (beta)
« Reply #31 on: November 01, 2005, 09:29:36 pm »
 :-[
bruce
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

AshK

  • EA User
  • **
  • Posts: 137
  • Karma: +0/-0
    • View Profile
Re: EA 6.0 (beta)
« Reply #32 on: November 01, 2005, 09:36:33 pm »
Quote
EA is just creating additional compartments to divide features.  This is allowed in the UML 2 Superstructure.

If you have a problem with the way EA is drawing these, either think of them as named compartments in which the stereotype is supressed.


Hi all,

I'd like to back Simons statement that these headings should be considered as named compartments with the stereotype supressed.

For those who are interested, here's my speil on the feature:

We've added a new field to the stereotype dialog (FYI: config->UML->Stereotypes); there's now a group field for each stereotype.  

If this field is not empty, the associated feature will be grouped under said named compartments.  If it is empty, the stereotype name will be used for the groupname.

Group field permits duplicates so features with different stereotypes may be grouped under the same heading.
The Sparx Team
support@sparxsystems.com.au

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6048
  • Karma: +73/-83
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: EA 6.0 (beta)
« Reply #33 on: November 01, 2005, 11:00:07 pm »
Quote

Hi all,

I'd like to back Simon's statement that these headings should be considered as named compartments with the stereotype suppressed.

For those who are interested, here's my spiel on the feature:

We've added a new field to the stereotype dialog (FYI: config->UML->Stereotypes); there's now a group field for each stereotype.  

If this field is not empty, the associated feature will be grouped under said named compartments.  If it is empty, the stereotype name will be used for the groupname.

Group field permits duplicates so features with different stereotypes may be grouped under the same heading.
OK,

I'm also now comfortable that it is a StereotypeGroup not a Stereotype.   However, it might be worthwhile centering in the "band".

The reason for this suggestion is that the actual display order is StereotypeGroup within Inherited Class.

So you can get a very fractured display if you do a lot of inheritance and use a lot of stereotypes.

Should the Stereotype Group override the Inheritance?
Since the display no longer bears any relationship to the actual Feature order, I suspect it should.

The Feature could then display as:
Feature (::Class)

Thoughts?

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

AshK

  • EA User
  • **
  • Posts: 137
  • Karma: +0/-0
    • View Profile
Re: EA 6.0 (beta)
« Reply #34 on: November 02, 2005, 09:59:40 pm »
Quote
OK,

I'm also now comfortable that it is a StereotypeGroup not a Stereotype.   However, it might be worthwhile centering in the "band".

The reason for this suggestion is that the actual display order is StereotypeGroup within Inherited Class.

So you can get a very fractured display if you do a lot of inheritance and use a lot of stereotypes.

Should the Stereotype Group override the Inheritance?
Since the display no longer bears any relationship to the actual Feature order, I suspect it should.

The Feature could then display as:
Feature (::Class)

Thoughts?

Paolo


Thanks for your suggestions Paolo.

We've been experimenting with the current grouping, we've also found it gets quite fragmented when you add inherited features :-/.

We find the following grouping to be effective:

[GroupName]1
 [ClassName of inherited feature]2
   Feature
 
1 Shaded band, left aligned, optional
2 Italic, left aligned, optional eg: ParentClass::

I'd say that your suggestion for centered group names will be considered.

Ash :)


« Last Edit: November 02, 2005, 10:01:01 pm by AshK »
The Sparx Team
support@sparxsystems.com.au

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6048
  • Karma: +73/-83
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
StereotypeGroup display
« Reply #35 on: November 02, 2005, 11:41:41 pm »
Quote

Thanks for your suggestions Paolo.

We've been experimenting with the current grouping, we've also found it gets quite fragmented when you add inherited features :-/.

We find the following grouping to be effective:

[GroupName]1
  [ClassName of inherited feature]2
    Feature
  
1 Shaded band, left aligned, optional
2 Italic, left aligned, optional eg: ParentClass::

I'd say that your suggestion for centered group names will be considered.

Ash :)
 

 
Thanks Ash,

I've come across the fragmentation problem many times before! :D

However, based on your feedback, I think my suggestion should be modifed to:

Since the order is now Feature within AncestorClass within StereotypeGroup, it is normal reporting practice to indent each lower order from the left.

You could add a standard indent of 4 spaces (or whatever).

It's really important that the user's eye's get the visual cues that have now been long established practice.

The Agile aphorism "Prefer working code to Documentation" applies here.  If the display looks natural, then you don't have to explain it... ;D

(Besides, you can use this pattern elsewhere!  8) )

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6048
  • Karma: +73/-83
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
XSD Import/Export
« Reply #36 on: November 03, 2005, 06:27:12 am »
The progress Controls don't scroll.  Neither for import or export.

So It's difficult to see how far it gets before it hangs... :-X

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6048
  • Karma: +73/-83
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
ERM Notation
« Reply #37 on: November 03, 2005, 06:57:44 am »
ERM Notation is cool!  8)

BUT...

there are a number of competing IE style notations.

1)
[1:1] as ---|-
[0:1] as ---0-

2)
[1:1] as ---||-
[0:1] as ---0|-

3)
[1:1] as -----
[0:1] as ---0-

4)
[1:1] as -----
[0:1] as ---0|-

(Also there's the Oracle form (Barker) where half the line is dotted (I think, for optional))

There are possibly others.  

The current EA standard is 4) which is the most self inconsistent.  It's also inconsistent with the stated reference (AglieData - which shows option 2)

My preference is for 1).

The IDEF1X notation is flawed.  There is no optional end, and no use of P or Z.

There is also the question of whether EA will support the identifying relationship concept of IDEF1X.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: EA 6.0 (beta)
« Reply #38 on: November 03, 2005, 02:12:57 pm »
I'm not sure whether this is an issue or not.

Haveing finshed "playing" with the beta in a test project I moved on to "playing" with a copy of a real project.  But, instead of just copying the EAP file and using that, I created a new project in v6.0.776 using the existing project as the template - and resetting GUID's.

Now this project is quite mature and has many many reliances on the composite element feature to drill down through the design, for example, use case -> activity -> collaboration -> analysis class model.

When I opened the diagrams in 776 the elements are no longer shown as being composite (the "infinity" adornment is gone). Double clicking the element just brings up the element proerties window.  I can restore the prior behaviour by setting the element to composite but I have to do that twice, not just once.  It appears that the composite nature has gone into some Twilight Zone mode???

Is the reversion from composite expected behaviour on project creation?

bruce
« Last Edit: November 03, 2005, 02:14:38 pm by sargasso »
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

AshK

  • EA User
  • **
  • Posts: 137
  • Karma: +0/-0
    • View Profile
Re: EA 6.0 (beta)
« Reply #39 on: November 03, 2005, 03:19:41 pm »
Hi Bruce,

Thanks for reporting this bug.  The guid reference wasn't being updated.

Please find the behavior corrected in 777 (the next beta I think).

Ash

« Last Edit: November 03, 2005, 04:33:50 pm by AshK »
The Sparx Team
support@sparxsystems.com.au

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6285
  • Karma: +52/-5
    • View Profile
Re: ERM Notation
« Reply #40 on: November 03, 2005, 08:32:19 pm »
Quote
ERM Notation is cool!  8)

BUT...

there are a number of competing IE style notations.

[SNIP]

(Also there's the Oracle form (Barker) where half the line is dotted (I think, for optional))

There are possibly others.

Yes, there are other notations that are out there besides the ones supported by EA.  Ultimately I don't think it is reasonable to expect every notation, let alone the variants of a notation to be supported.

Quote
The current EA standard is 4) which is the most self inconsistent.  It's also inconsistent with the stated reference (AglieData - which shows option 2)

I tested this and it definately appears the we match with your option 2.  Are you sure you didn't set the multiplicity of the zero or one end incorrectly?
Simon

support@sparxsystems.com

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6048
  • Karma: +73/-83
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: ERM Notation
« Reply #41 on: November 03, 2005, 09:44:10 pm »
Quote
I tested this and it definitely appears the we match with your option 2.  Are you sure you didn't set the multiplicity of the zero or one end incorrectly?
Hi Henk,

My Beta is at home, I'm at work.  I use 1 to signify the mandatory singular, not 1.. or 1.*  does that affect things?

I'll check further when I get home.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 6048
  • Karma: +73/-83
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: EA 6.0 (beta)
« Reply #42 on: November 09, 2005, 03:20:53 pm »
I thought I'd already posted the question as to whether there were any DB changes and thus you could use the same model .EAP file between 5 and 6.

Can a Sparxian confirm I can use the same model file between both versions?

Thanx,
Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

Simon M

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 6285
  • Karma: +52/-5
    • View Profile
Re: EA 6.0 (beta)
« Reply #43 on: November 09, 2005, 03:36:28 pm »
You certainly can use the one model across both versions.

Of course when using 5.0 you miss out on all the cool new features from 6.0 ;) but they won't cause 5.0 to break.
Simon

support@sparxsystems.com