Umple

So, committed change... everything is working, I didn't do a test case for it, because I figure 1) that umpleSelf and the implementation files should take care of most that, and 2) that there isn't much of an architecture to do so. But yeah, if ... [More] you look in the jumpjet file, you will find the modularization of what I found to be the major sections(some less major, [Less]

OK. I see you point; this may be easier than I thought. Why don't you try to see if you can get it to work ... - Tim Timothy C. Lethbridge, PhD, P.Eng., I.S.P., CSDP Professor of Software Engineering and Computer Science / Professeur Titulaire de g�nie logiciel et d'informatique

But why automated? If we compartmentalize the main parts of the jet files, then those should never grow beyond their means, I mean, it's a simple copy paste of the aforementioned code into the jumpjet file at the various locations, we wouldn't have to worry about errors in postprocessing(because

Precisely. This is what needs to be automated. Timothy C. Lethbridge, PhD, P.Eng., I.S.P., CSDP Professor of Software Engineering and Computer Science / Professeur Titulaire de g�nie logiciel et d'informatique Facult� de genie / Faculty of Engineering University of Ottawa / Universit� d'Ottawa

Hey guys, so... i was thinking about this problem, couldn't we do something like this: <%=getAttributeCode(stringBuff er,uClass,gClass,gen,isFirst,t raceItem)%> <%return stringBuffer.toString(); } private String getAttributeCode(StringBuffer stringBuffer,UmpleClass uClass, GeneratedClass gClass, JavaGenerator gen, boolean isFirst,

Hi all, Constraints can now have negation operators (!, ~ or not). For example, you can now write a constraint like [ ! (age < 1)]. I have also committed the tests as well as the implementation. The master issue for this is 187. -- Cheers, Quinlan Jung

The post processing solution sounds a little error prone, and if we were to go down that route I would have those detailed covered by the code generator glue code and not via ant. One way that I reduced the amount of jet code generated was to ensure I only called a template once, otherwise jet will inject the same code multiple times.

It now raises an error when you try this code : class LightFixture { bulb { On {} || Off {} } At the moment, Umple can't allow concurrency between top level states, but only between nested state-machines. Change has been commited.

Hi again Geoffrey and others. (see the earlier message today if you are missing the context) I have studied the infamous getCode method in JavaClassGenerator.java that is now biting us again, and it would be fairly easy to write a relatively dumb post-processor that would refactor it by splitting out a series of

Hi, The issue of running over the 65K limit in the jet-generated getCode method is serious. The problem, as I understand it, is that in Java, a method's byte code cannot exceed this size. Jet does not know it is writing Java that when compiled will exceed this limit. We have run into this before a couple of times, and refactored to