RE: [Andromda-user] Validation Error: One Use-Case per package...

[Wouter Zoons]

Hello Frederic,   The reason for having only a single use-case per package is because the cartridge generates a lot of code that is implicitely derived from the model. This way the user only has to worry about putting a single use-case in a package, the alternative was modeling _everything_ (much like the cartridge behaved in andromda 2) and selecting the package from there .. this to avoid filename collisions   I think it’s a reasonable compromise between use-friendlyness and flexibility ..   Yes, you will have many packages as the project grows, but there are also a lot of files in each package, so what’s the alternative if you want to keep things organized ?   Thanks -- Wouter   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frederic Chapuis Sent: Friday, October 29, 2004 11:08 AM To: [EMAIL PROTECTED] Subject: [Andromda-user] Validation Error: One Use-Case per package...   Hi,   I switched to m3 recently and was trying a few things when I ran into this. The error is resolved by effectively dedicating a package to each use-case. My question is why should one package be dedicated to one modeled "process" ? I mean you could have several processes (eg. "User Management"=CRUD and "User Search") modelling an application part (or module) and it would be convenient to have all the classes within the same package. I'm not against this approach but this will lead to huge package structure as the model grows, and one can decide to organize (manually) its package structure like this if he wants to.   However, I also found that Boolean accessor "isXXX" is still generated and causes problems. Also I noticed that the hibernate mapping file uses lower-cased attributes (first letter only) which does'nt permit using upper-cased class members (although not a good practice) and causes problems if one accidentaly used an upper-cased member.   Cheers, Fred.