Messages

1

General Board / [Feature Req] Attribute level of abstraction

« on: May 07, 2002, 01:56:21 am »

Hi all!

I'm putting this feature request in the forums because I'd be interested to see whether others would find this useful...  and maybe actually it can already be done, I don't know.

It's one thing to be able to construct classes and with EA's multiple view mechanism construct an analysis view and a design view (with design classes added) and an implementation view (with implementation classes added) but isn't it common that the actual analysis classes themselves have extra attributes that are added during design and implementation?

Anyway I think this is the case and I would like to vote for a feature where:

a)you can mark an attribute as 'analysis/design/implementation'
b) you can then select in your diagram options to what level you want to show your attributes.

Of course code generation wouldn't change -- this would always be the implementation level.

Can you preserve this characteristic in round-trip engineering?
- VB.NEt and C# you can just add extra custom attributes marking the abstraction level if it's anything other than 'implementation'.
- in Java you could add an extra javadoc tag '@abstractionLevel' or something which describes what it is. I haven't looked at codeGen of java recently but I assume EA's already generating javadoc comments for other things.

2

General Board / Re: The Nightmare of EA & the file system

« on: March 08, 2002, 05:44:07 pm »

Ok.... a few weeks later and this thing is still a major sticking point, luckily I rememebered I had the problem before and your comments Geoff were a help, this time on my project, I did what you suggested in response to my first question and it works. I

There's a very easy way in the current system to make this a little more intelligent: 1) automatically create a 'local path' for each language option. JAVA for java etc etc. Or java-src or something readable and sensible. THEN if the user, the first time, chooses a path that is RELATIVE to the current project, automatically make the substitution. This is at least a little better.

But if you happen to move the project, you'll get that same arrogant 'can't find the folder specified' error. Humf.

This brings up the SECOND part: 2) these 'local paths' should be intelligently-represented as local to the project directory if possible. That is, the way things are now, you should put a a variable %PROJECT% in the local path mappings themselves, or whatever, which can be embedded in other directory names. This effectively allows you to have local paths that are relative to the project.

This would mean someone could move the project around, and everything would work, all the time.

So example:

• Let's say you have your files in C:\Dox\Proj
  
• Default language was java.
  
• Simply by choosing 'generate code' the first time, you get a file chooser saying 'where exactly' and it appears in C:\Dox\Proj.
  
• You choose 'C:\Dox\Proj\autogen\
  
• This creates a new entry 'JAVA' which is '%PROJECT%\autogen\' (yes, nested substitution).
  
• The file path for each class is then as before: %JAVA%\autogen
  

Of course really you want your 'paths' to be specified in some cleaner way that they're relative to the project, but my suggestion would probably take less effort (and I'd see the changes sooner, which would be better

3

General Board / Re: The Nightmare of EA & the file system

« on: February 21, 2002, 02:52:46 am »

Thanks Geoff, as I've come to expect with Sparx, quick responses, consideration of possible ways to improve.

Where do I sign?  

If for my help and others, you could post notice of changes to dox and/or builds to this thread that'd be most appreciated.

cheers!
Julian.

4

General Board / Re: The Nightmare of EA & the file system

« on: February 20, 2002, 02:19:59 pm »

Hi Ronnie, thanks a bundle for your quick response!

You say:
>When you go to 'code engineering, generate source code'
>off of a package context menu then it asks you which
>objects within the package to generate and then prompts >for each file location and name if it's new, otherwise you can
>synchrinize

This doesn't happen for me. I select a package, and In the 'Generate Code' window, I choose 'includes all child packages', at which time the classes appear. The 'target file' column has a pathname for the 'EAExample' of 'C:\bin\JDK\demo\sound\src\...' which is not on my machine and I have no idea how to change this (this is a big part of my first question).

I then choose 'Overwrite code' and click 'Generate'... to which it says 'path not found: C:\Bin\...' etc.

??

cheers,
Julian.

5

General Board / The Nightmare of EA & the file system

« on: February 20, 2002, 02:15:22 am »

Hi all! (I'm reposting this as a registered user... I'm poised to buy this product, but I want to get this sorted out... someone please help

I've always been a fan of Enterprise Architect... but there's one thing that's been a brick wall for me with my latest attempt to use it... why on -earth- is the relationship between EA and the file system so difficult?

I've been wrestling with EA 3.1 for several hours today and I can't for the life of me find how to generate code properly. Here are my problems:

a) the documentation refers to menus that don't exist e.g. Reference/Code Generation Defaults
b) I have no idea how to specify the target language, the interface just makes no sense at all.
c) when I try and do a generation, having given up trying to find out how to change the paths, I'm stuffed -- the paths seem to be that of a Sparx developer and it just says 'error pathname not found'.

Heeeeeelp!


BTW Here's a design suggestion.

Project options:Code generation

Language: [popup with java etc, choose one]
Source directory: [choose one here] [ ] relative to project (checkbox)

how's that?

6

General Board / Re: Self-references and cardinality: text obscured

« on: March 08, 2002, 05:50:22 pm »

It's the coolest thing to see a feature request in a commercial product appear like, a WEEK after sending the request.

Superb. Nothing less.

Cheers Geoff and the rest of the Sparx team!

7

General Board / Re: Self-references and cardinality: text obscured

« on: March 03, 2002, 04:32:22 am »

Re: update to self-references... wow, that's just so amazing Geoff... send a request for a change in a commercial app and have it actually LIVE within a WEEK that's truly exceptional!

One question: this is more complex, but it's quite tedious to download the entire new app and deinstall/reinstall each time... is it possible in future to have a patcher? Much faster and easier for all!

cheers!
Julian.

8

General Board / Re: Self-references and cardinality: text obscured

« on: March 01, 2002, 04:00:56 am »

Thanks Geoff!

Re: Search engine, I'm talking about the forum search engine for the support forums here...

9

General Board / Self-references and cardinality: text obscured

« on: February 28, 2002, 03:48:05 am »

Hi guys...

hey cool, self-references are drawn really nicely (just click on a node, that defines the start and end point)!

-Except- when you add cardinality to them, then the arrow heads are obscured by the text.

So I suggest one of two things:

1) allow the resizing of the self-reference link
2) adjust the size of the self-reference loop when the cardinality is nonzero.

Right now I'm not putting cardinality on the diagram because it looks horrible.

cheers!
Julian

(PS could you change the default search engine date range to something like 700 days instead of 7 days? It's a bit silly to constrain the search by default to just the last week... thanks!)

10

General Board / Re: EAToolkiT 1.0 Released

« on: March 25, 2002, 02:28:45 pm »

Awesome work Steve! You and Geoff man... you're just Golden.

Testing... you know what would be the coolest is integration with Ant and JUnit.

For issue management, support for Test Track Pro (www.seapine.com) and the superb Scarab (scarab.tigris.org) would be the neatest thing.

I may well have a few weeks spare soon so I might just explore this world a little myself.

11

General Board / Re: Requirements View

« on: March 25, 2002, 02:23:15 pm »

Yes numbering schemes for requirements could be cool... but it gets complicated doesn't it because you want hierarchies of requirements to have nested numbers, and then this implies an order to the hierarchy and, well how do you rearrange them etc... and then they change so traceability gets screwed up when you have things outside EA referring to them.

Perhaps a global numbering scheme would work best, with optional prefix field per diagram (e.g. UCD for diagrams, UC for use cases etc like exemplified in EAExample). The main problem being that you must be able to assign a requirement a unique id that's permanent throughout time, to assist in traceability (that was requirement 14! no -that- was requirement 14!). How exactly this works with hierarchical numbers I'm not sure: moving them around makes them horribly complicated.

I think perhaps then a global, persistent requirement number with optional prefix and postfix chars would make the most sense.

12

General Board / Re: Multi language support

« on: March 08, 2002, 05:21:00 pm »

And I'll help on the Spanish one if you like.

13

General Board / Re: UML 1.4

« on: March 09, 2002, 02:14:44 am »

Sorry couldn't resist... may the thread die after this message

Steve,

I agree kinda.  But don't you have to standardize on something?  You standardize but enable enough flexibility to deviate only when necessary.

It is like the English language.  We have a baseline for the language.  New words and meanings are added as the human race matures.  Old words take on new meanings as well.  The word Gay in 1950s meant happy.  Today however it means something totally different.  But the way it is spelled and pronounced is the same.  We also have some spanish, latin, french, and other languages mized in with the etomology of english  but that does not mean we begin integrating with the english language pure spanish per se.  We do not want Spanglish but English.

Same with UML.  UML is a visual communications language and therefore will mature over time.  Adopt 1.1, when 1.2 comes out adopt it in full..1.3, 1.4 etc.  While there may be some changes, in the meanings of the notation, the notation stays the same.  It is the capturing of the change in the meaning that is paramount.

Rusty

Welll... come on though, English language is defined by its usage, not some arbitrary standard, albeit over a time scale that is a lot slower than other standards (but then, UML would change a lot more slowly if 2 billion people in the world used it every waking moment of their lives  Even grammar changes. The nounizing of verbs and verbizing of nouns are much more common in recent years to what it was. 'Yous' as plural for second person plural is increasingly common across the world. New words and vocabulary evolve even more rapidly with the internet. In other words, people run with it. Even 5 years ago, would you have had any idea what i meant by 'blog', 'spam', 'to text someone', etc etc sure I think you get my point.

Speaking of Spanglish, it's what's becoming increasingly common in Spanish. For instance there are two words for 'link' in Spanish: 'enlace' or 'vínculo' but here in Spain people just use 'link' as they do 'training', 'marketing', 'scope' etc. (A funny side is that people pronounce foreign brand names with a literal Spanish accent... like 'Oracle' for instance is pronounced 'orAH-kleh' and there was a time when I had absolutely -no- idea what they were saying until they wrote it down

New words are more often than not directly transplanted into other languages. It happened in English too, there are bundles of foreign words and concepts.

So I'm not so sure it's as clear-cut as that. I think it's ok to use these tools to communicate the intent of the design. You're not going to do sequence diagrams for every flow, only for core use cases for analysis (with Together actually, I've used the sequence diagram from code option to understand the method call stack, very powerful analysis tool).

My €0.02

14

General Board / Re: UML 1.4 (Java interfaces and constants)

« on: February 27, 2002, 03:13:32 pm »

To add my €0.02, Java interfaces CAN have constants, which would be represented as static attributes in EA, so I for one definitely recommend we keep this in, even if there's no actual way of representing this in UML 1.4 if you were to be strict, it would seem.

http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#35470

15

General Board / Re: just a small improvement request

« on: March 08, 2002, 05:46:49 pm »

I agree. Ctrl-Enter is a standard way of closing dialogs in most systems... count this as a second vote for this feature.

In general, Geoff et al... have you considered something like the Java Community Process where features are posted and people vote for what they want? That'd be really cool.