-
-
Notifications
You must be signed in to change notification settings - Fork 196
UCOSPLogMarkGalloway
Kevin Brightwell edited this page Aug 26, 2015
·
1 revision
Each UCOSP participant is asked to log all their accomplishments as well as the difficulties they have getting set up to understand Umple and other experiences they have. Difficulties might include understanding how to model in Umple, using UmpleOnline, code that is difficult to figure out, and development tools that are hard to figure out, or don't seem to work properly. The more log entries added the more we can better get a grip on the usability issues with Umple, and the more we can help future new contributors come up to speed. Mention issue numbers and revision numbers in your log to help create hyperlinks.
Dev Environment
- OSX Mavericks
- Eclipse Luna with Papyrus
- Java SE 1.7_u56
Project Overview
- I was reading through my log and noticed that I had created a new warning for Issue 610 (on Google Code), but I had never created the corresponding webpage. I've now created and pushed this. https://code.google.com/p/umple/source/detail?r=4842
- I had to make a second commit as I made a typo. https://code.google.com/p/umple/source/detail?r=4845
- I was finally able to get the new Papyrus button to grey out if the Papyrus plugin was installed. It was a fairly painful process. I originally implemented an "action" for the button and menu item, much like how the other buttons are handled; However, I was unable to make it grey out based on a complex condition. Many hours were spent googling and reading eclipse docs, but there was no clear way of solving this problem. The majority of resources I did find pretty much all said the same thing, which was that "actionSets" are deprecated and people should start using the new "command" api for eclipse plug ins. This probably explains why I was having such a hard time finding the information I needed, as our plugin seems quite old. Moving on from this I started to implement the command style plugin for my new button. I was going to create a PropertyTester class which would have a function I could use to add logic to return a boolean which would decide whether or not the button would be enabled. However, I ran into some problems mixing this new stlye of plugin with the old one. After losing a few hours to this, I went back to struggling to find a way to solve this problem without rewriting the plugin. Luckily, after many more google searches and api reading, I was able to find that you can add "enablement" tags with conditionals for turning your actions on and off. However, what was not clear was what to specifiy in the flag. I found pretty much no documentation for this. Luckily, I was able to preform a lot of trial and error and figure out that I can specify a plugin install state in this flag. Once I had the proper plugin tag placed here, I was able to have the plugin greyed out in eclipse without modelling tools, and functional in eclipse with modelling tools.
- another issue i encountered was that I had to separate my "action" from the other "actionSet". The problems I had were getting the buttons to appear within the same dropdown menu. The toolbar was quite simple, but I was unable to get the second "actionSet'" button into the first's dropdown. After a lot of digging (again, which there wasnt many resources) I learned that you cannot specify a different actionSet's button to go into another actionSet's menu item. Luckily, shortly after I also found that if you declare the menu twice, with the same name and ID in each actionSet, the buttons would go into the same menu. It felt kind of ridiculous how much time was spent on getting things into the same menu, which leads me to the following point...
- The Eclipse plugin is very out dated. I will suggest to Tim that if further work is to be done on it, then a rewrite should be considered. I found a ridiculously large amount of resources and tutorials for the newer command api which seems to have more flexibility. Trying to find resources for the current deprecated actionSet api is a pain and a lot of time was lost to that fact. I don't think a rewrite would be entirely too difficult. I am fairly certain that most of the business logic in the java classes can be left intact.
- I am happy that the Eclipse plugin is complete. I feel like it was a fairly obscure task and I really stepped out of my comfort zone by trying to implement it, and I stuck with it through the frustration.
- I am slightly disappointed that the PapyrusGenerator code is still missing features. Unfortunately, there will be a substantial amount of work that needs to go into that, possibly a full term, so I will have to leave my issue as 'mostly done'
- The papyrus plugin code has been submitted as commit https://code.google.com/p/umple/source/detail?r=4826
- The plugin code is currently disabled. To implement it, uncomment the indicated ExtensionPoint in "cruise.umple.eclipse/plugin.xml". It is clearly labelled.
- Still working on the umple plugin. After discussion with Tim, I am trying to create a condition where the new button for Papyrus Generation is "greyed out" when Papyrus appears to not be installed. This is a fair bit more complex than it may seem on the surface. I could not find a way to do this with the current plugin implementation, which uses ActionSets. In fact, Action Sets are deprecated. I've instead decided to implement this part of the plugin using Commands, which seem to be the new way of designing buttons. My button now has it's own handler class, which I can then override the "isEnabled()" method of the super class. I can add logic here and then return a boolean which indicates whether the feature is enabled or not. However, in testing this I've found that the button is not greyed out until you click it, which creates a popup telling you the feature is disabled, and then the button finally becomes greyed out and unclickable. This seems pretty stupid. I'm searching for a better way, and there may be one. I can put conditions on the command such as "visibleWhen" and then specify the criteria. However, it is not entirely clear but I think I can create a custom function to decide this. I will need to look into it more.
- If I have time, I am going to migrate the current umple button/menu items to the new Command style so they are no longer using deprecated features. This should not be very involved.
- I've been doing a lot of googling and reading about eclipse plugins but I can not find any way of detecting whether or not the current IDE has modelling tools installed. There may not be an easy way of doing this, as usually you would simply define dependencies within your plugin. However, we only want a dependency for certain functionality of our plugin. I'm still going to keep looking into this, but there are some other options if it cannot be done. We could go into the plugin folder and try to detect if there are papyrus plugin file names... this is a bit hacky. Since the generated files aren't harmful or anything, we could simply generate them regardless but print to console telling the user that a papyrus diagram was generated and they must have modelling tools install to view it. Doing this may make users aware that this functionality is now available, but still it is not truly ideal. I will keep looking and also email Tim about what he thinks.
- Successfully have my new button to generating Papyrus diagrams into the current project folder when clicked.
- Added a project refresh functionality to the plugin after it generates code, as users must not enjoy manually refreshing the project every time they compile an umple file.
- Tested Papyrus generation in an Eclipse install without Modelling tools. The files are still generated for papyrus, but they are just meaningless XMI files that do not do anything. I was wondering what it would be like if we could not detect if Modelling Tools were installed or not. While we are generating useless files when the button is clicked, it is not really a dangerous thing. Still, I will continue to look into generating a message to tell the user they must have Modelling Tools for Papyrus diagrams.
- I still need to look into opening the diagram after it is generated, and also seeing if I can call the built in auto arrange functionality.
- I have pushed a patch for Issue 185 (on Google Code) which completes the code generator for Papyrus, along with the corresponding tests.
- Will continue work on the plugin integration now that the generator is complete.
- Successfully added a menu item and a button for the Papyrus generation. I believe the next step will be to set the language to generate as Papyrus upon when the button is pressed. I've found this tutorial to be quite handy with regard to buttons/menu items in Eclipse plugins: http://www.vogella.com/tutorials/EclipseCommands/article.html
- Also, I need to figure out how to detect whether or not modelling tools is installed. Rudimentary google searches haven't shown any results but there obviously must be a way so I will keep digging.
- Started looking into adding the new button for the Eclipse plugin which will generate (and possibly open) Papyrus diagrams.
- Added a vey rudimentary layout algorithm as suggested by Tim for class diagrams and state machines.
- Refactored some portions of the Papyrus generator, including modifying some of the existing uml generation code to further fit the XMI format that is generated by Papyrus, and in doing so found some small errors in the naming of association ends. These errors have now been fixed.
- I'm ready to commit my completed work on the Papyrus Generator, but I need to implement some tests for the new generated notation files. I have created the expected output files, but the generated files include unique IDs, so a straight comparison of the template to the generated output will not work. Tim suggested using a modified ant test which can use pattern matching to ignore certain parts of the file. I've done some googling on ant tests, but wasn't able to find exactly what he was talking about. I've emailed him asking if there are any tests currently written in the format he suggested.
- Spent a fair amount of time this weekend creating the notations for state machine diagrams. It was a bit more involved than classes and associations were. However, I now have state machine diagrams completely drawing. Again, the layout still remains a problem. With normal class diagrams in Papyrus, we can simply open the file and then select ArrangeAll from the menu, which provides a decent layout. One of the problems with the State Machine diagrams is that since all of the states are a part of of the same entity, the state machine, I have to actually select them all and then arrange them all. It would seem that the ArrangeAll feature only arranges the main entities as a whole. This could be slightly problematic for using Papyrus to make everything visually pleasing for us. I have some screen shots of the state machine diagrams, the first which is the layout we generate, and the second is after Papyrus Arranges the layout. https://drive.google.com/open?id=0B8VDATSEfCZPbmJ1QnNGSkxSNEk&authuser=1 https://drive.google.com/open?id=0B8VDATSEfCZPc3phcWd5eEcxMWc&authuser=1
- I was able to get the associations to draw and I expanded my example to include association classes as well, which also seem to draw nicely. I took some screenshots, the first of which shows the diagram of what we generate (and the poor quality of the layout). The second image shows the layout after using the Papyrus Arrange All feature, and the third image shows a manual arrangement by me, which would be a more aesthetically ideal arrangement. https://drive.google.com/open?id=0B8VDATSEfCZPb0dLR0EtcUoyWGs&authuser=1 https://drive.google.com/open?id=0B8VDATSEfCZPRmN2RlRBTk9LdXM&authuser=1 https://drive.google.com/open?id=0B8VDATSEfCZPZmdNc2FibG40MXc&authuser=1
- I was able to implement the desired code generation for model.notation inside Generator_CodePapyrus. The papayrus code that is now generated can be open and visually seen as a diagram with classes; however, there seems to be a slight problem with associations not being drawn that I have not been able to solve yet. Hopefully, it is just a simple code generation mistake on my part. I will need to look into this further.
- A further note on the UUIDs: I have noticed that if I generate model.notation code that does not contain UUIDs (see Oct 24) then once the Papyrus is opened and saved again UUIDs will be generated and stored in the file. I still cannot tell if we need to generate our own UUIDs for every xmi field, but if we do not then we know they can be generated by Papyrus later.
- I was able to get associations to draw as well. Since I now have a model.notation file output example which draws two classes and an association between them, I am going to modify the Generator_CodePapyrus.ump to generate a correct notation file and test if the generated Papyrus project can be loaded. If so, I can then expand generation to the other UML elements.
- I've come to the realization that there is a function within Generator_CodePapyrus.ump which generates XMI ID's in the described style below, I am still going to hold off on generating them for the moment as most of them do not seem to be needed at this time. Once I can generate generic code which can be loaded into Papyrus, I will revisit the completeness of the code to include generated UUIDs.
- I've updated Issue 185 (on Google Code) to include an overview of the work that needs to be done to satisfy this issue, which I feel I now have a fairly good grasp on.
- Begun integration of my manual XMI code into the generator. An issue that comes to mind is how to test my new generated model.notation file. Current tests for the model.uml file are simply to generate a file and compare it's output to an expected text file. While this kind of test does verify the generator is consistent in what it outputs, it does not verify that what it outputs is correct or even valid, as the expected output could easily be incorrect. I will think on this and perhaps google for some ideas.
- I was finally able to draw classes in the Papyrus window by adding to the model.notation file. It seems that our Papyrus generator does generate a (seemingly) valid model.uml file, but after removing the erroneous code from the model.notation file nothing is drawn. In order to fix this, I took a Papyrus model.notation file and started transcoding it into our own generated file to see what we could draw. An example of the notation generated by Papyrus for drawing simple class:
<children xmi:type="notation:Shape" xmi:id="_U7juIFgaEeS8OYa-1ViZ6w" type="2008">
<children xmi:type="notation:DecorationNode" xmi:id="_U7mKYFgaEeS8OYa-1ViZ6w" type="5029"/>
<children xmi:type="notation:BasicCompartment" xmi:id="_U7mKYVgaEeS8OYa-1ViZ6w" type="7017">
<styles xmi:type="notation:TitleStyle" xmi:id="_U7mKYlgaEeS8OYa-1ViZ6w"/>
<styles xmi:type="notation:SortingStyle" xmi:id="_U7mKY1gaEeS8OYa-1ViZ6w"/>
<styles xmi:type="notation:FilteringStyle" xmi:id="_U7mKZFgaEeS8OYa-1ViZ6w"/>
<layoutConstraint xmi:type="notation:Bounds" xmi:id="_U7mKZVgaEeS8OYa-1ViZ6w"/>
</children>
<children xmi:type="notation:BasicCompartment" xmi:id="_U7mKZlgaEeS8OYa-1ViZ6w" type="7018">
<styles xmi:type="notation:TitleStyle" xmi:id="_U7mKZ1gaEeS8OYa-1ViZ6w"/>
<styles xmi:type="notation:SortingStyle" xmi:id="_U7mKaFgaEeS8OYa-1ViZ6w"/>
<styles xmi:type="notation:FilteringStyle" xmi:id="_U7mKaVgaEeS8OYa-1ViZ6w"/>
<layoutConstraint xmi:type="notation:Bounds" xmi:id="_U7mKalgaEeS8OYa-1ViZ6w"/>
</children>
<children xmi:type="notation:BasicCompartment" xmi:id="_U7mxcFgaEeS8OYa-1ViZ6w" type="7019">
<styles xmi:type="notation:TitleStyle" xmi:id="_U7mxcVgaEeS8OYa-1ViZ6w"/>
<styles xmi:type="notation:SortingStyle" xmi:id="_U7mxclgaEeS8OYa-1ViZ6w"/>
<styles xmi:type="notation:FilteringStyle" xmi:id="_U7mxc1gaEeS8OYa-1ViZ6w"/>
<layoutConstraint xmi:type="notation:Bounds" xmi:id="_U7mxdFgaEeS8OYa-1ViZ6w"/>
</children>
<element xmi:type="uml:Class" href="model.uml#_U6uAoFgaEeS8OYa-1ViZ6w"/>
<layoutConstraint xmi:type="notation:Bounds" xmi:id="_U7juIVgaEeS8OYa-1ViZ6w" x="311" y="394"/>
</children>
- The above specifies the overall shape to draw, in this case a rectangular class container with 3 basic compartments corresponding to attributes, methods, and nested classifiers. It is somewhat complex in the fact that there are many generated UUIDs; however, most of these styles do not seem to be referenced (currently) and I was able to simply remove the UUIDs and produce the following:
<children xmi:type="notation:Shape" xmi:id="_Spaceship" type="2008">
<children xmi:type="notation:DecorationNode" type="5029"/>
<children xmi:type="notation:BasicCompartment" type="7017"/>
<children xmi:type="notation:BasicCompartment" type="7018"/>
<children xmi:type="notation:BasicCompartment" type="7019"/>
<element xmi:type="uml:Class" href="model.uml#Spaceship"/>
<layoutConstraint xmi:type="notation:Bounds" xmi:id="_Spaceship" x="311" y="394"/>
</children>
- This is much simpler, and generic, to generate for our purposes, and still draws a (seemingly) identical class visually and functionally. In the future, these UUIDs may need to be added in, and I believe they can be generated using the following package "EcoreUtil.generateUUID", which I believe comes from an outside library. I've chosen to not look into this currently as it may not matter (yet). Note that here the UUID for the class itself is substituted for the Shape notation. This is consistent with how we are using UUIDs in out generated code for model.uml and links this notation with the class information in model.uml for the "Spaceship" class that I have created.
- Another thing to note is the layoutConstraint for the drawing. There are X and Y coordinated for where the object is to be placed. For aesthetics, we will obviously want things to be spaced nicely. While there is an auto-arrange function inside Papyrus, we should not force the user to rely on this. A solution will have to be obtained for placing the diagram objects in a pleasing manner.
- I've checked out the code for the Eclipse plug in. I wanted to see how it works and how we can integrate Papyrus into it. Ideally, a third Umple button could transform a .ump file into the 3 required papyrus files and then open the .di file so it can be observed. I haven't yet decided the best way to go about transforming a Papyrus diagram into Umple code. This could be a fourth button, or some other means. I'm really interested in some other Eclipse plugins that have some sort of tab functionality on the bottom of the window to switch views. It would be super cool if you could use a tab like this to switch between Umple code and the Papyrus diagram, without using buttons. However, this could be incredibly involved and I will only really look into it if I have time near the end of term. If it is possible, then that would give Eclipse the best UmpleOnline-like capability possible.
- I've been experimenting with the Papyrus Generator code. Unfortunately, the XMI that it generates cannot be loaded into Papyrus and seems out of date and even elicits an error when I try to load it into Papyrus. I will most likely have to update this generator and verify it's correctness before proceeding with the plug in integration. In order to compare what exactly needs to be updated in the generator, I am going to draw some test diagrams. I will compare the generated XMI from both sources to see the differences.
- After some comparison, I've been able to notice that the notation file was actually getting some invalid code appended to it. By fixing this bug locally, the model actually opens in Papyrus without error now. However, the diagram is still completely blank. This could be a result of the out of date code, which seems much more complex than what Papyrus generates for me. I will continue to reverse engineer the generated sample until it shows up correctly in order to identify the problem XMI code. If that fails, I will update the Generator with the new XMI format. This should not be too complex as the logic of the Generator will stay the same, just the templating will change.
- Raised Issue 647 (on Google Code): The ability to to declare one end of an association as immutable. This issue adds one-sided immutability, which may need to be implemented before finishing Issue 610 (on Google Code)
- I had to create a two page project overview summary of the work I have done and will be doing for my Ualberta liaison. I've linked it here due to relevance. https://docs.google.com/document/d/1wF8ob2q8aGd9JA7X_naRN9LFassSufmZ2jEJ8RSuTtA/edit?usp=sharing
- I'm still currently trying to investigate the association class association immutability for issue 610 (on Google Code). Tim wants me to investigate whether error 17 is over-specified and whether or not we should be allowing immutability in one direction but not the other. I'm having some slight confusion on investigating this implication. It seems somewhat difficult to actually force the immutability to occur and to silently ignore these errors and see what the generated code will look like. I will need to look into it more.
- After discussing ProjectUG's with Tim, we have come to the conclusion that I will work on Issue 185 (on Google Code), which involves integrating UMPLE with Papyrus in Eclipse. I plan to get started on this soon by investigating how Papyrus works and how we can integrate this with the existing Umple plugin. Tim would like an agile, incremental solution so I will keep that in mind as I investigate.
- I've successfully installed Papyrus and made a few UML diagrams in order to see what the XMI looked like. I believe there is an already partial Papyrus Generator contained in Generator_CodePapyrus.ump. I've browsed it but have yet to attempt to translate anything to test functionality.
- Currently, to finish off Issue 610 (on Google Code), I am looking into making the association class associations immutable. Tim has asked me to investigate into error 17 to see if it is over-specified and we may in fact want to allow immutable associations in the many to 1 case.
- I had a meeting with my campus liaison for the UCOSP project. She was not happy that I haven't yet selected a UGproject. I've chosen one of the available ones and emailed Tim about it
- Continuing on issue 610 (on Google Code), I have committed a patch for the new warning, 1011, which is elicited for association class keys which do not contain all of the associations. It print as follows, Warning on line 13 : AssociationClass 'DownhillRaceEntry' missing needed 'race' key, provided [racer, number]. More information (1011).
- I have fixed the issue with regarding the warning 27 being elicited when you specify a key for an Association Class. After some debugging, it became clear that the association classes associations were not being analyzed until after keys were analyzed, which is the opposite of normal classes (which do not elicit this error). After changing the order so association classes associations are parsed before keys, I was able to compare these associations to the key tokens to validate the keys were correct and ensure the error is not thrown for valid keys. Patch submitted to Tim.
- I've realized that now since the associations are analyzed before keys that I can create the new partial key warning right in key analysis, which should make things much simple and I will have direct access to token position for the error throwing, rather than collecting tokens to analyze in post-token analysis. I believe this means my patch for the new warning will be finished soon.
- Wrote some tests for the for the expected error message about a Partial key missing expected associations in an Association Class. I also created the warning in en.error. Then, I added some logic to the UmpleInternalParser which compares the received key to the current key and stringified what is missing so the warning message will be informative. The only piece of the puzzle I am missing is to complete this task is actually throwing the warning. I've emailed Andrew about some of the problems I've had doing this and am waiting for his response.
- I started looking into the immutability constraint which was added onto issue 610 (on Google Code). If I try to make the associations immutable in Umple (to test my test), there is an error 17 thrown which indicates that two-way associations cannot be made immutable. I wrote Tim to see if we want to bypass this internally, or if I misunderstood what he actually wanted from the additional requirement.
- I've noticed that when you have an AssociationClass and you specifically define a key to include the associations, then a warning 27 is given which states that the class does not have the key members defined. However, the generated code is still correct. I believe this warning should not be thrown in this case. Furthermore, if we change the AssociationClass to just a class with 1--many relationships then this warning will not occur. It is possibly something to do with association classes and the way the UmpleInternalParser is analyzing keys to be correct. I will look into this with issue 610 (on Google Code) and the generated warning may interfere with my testing.
- I had to take a short break from Umple this past week due to many heavy deadlines overlapping each other. I emailed Tim about it and he was very understanding. Now that I've cleared everything up, I can schedule a full 10 hours for the rest of this week and will make up the lost time when I can, or during reading week.
- Continued on issue 610 (on Google Code). I've finished modifying the JET template and all test cases successfully pass now. I've created an additional test to ensure that a non-association class allows duplicate entries. I've created a patch for this and tested it out on a fresh checkout. I then emailed it to Tim for approval. Further work on this issue will involve the warning and immutability properties as discussed in the two previous entries.
- Attempted to make a change to the JET templates in order to continue progress on issue 610 (on Google Code), but had some compilation issues. After some struggling a bit, I found a previous commit which seemed to be causing my grief. I emailed Tim about it and he will get the problem fixed by the original committer.
* I continued on my issue 610 (on Google Code) during the code sprint. I have implemented the majority of the AssociationClass logic, including the tests. I have modified the postAnalysis of the parser to add the desired keys to AssociationClasses. The tests I had created before this development now pass. The remaining part of this issue includes the following work:
* Need to modify the JET template with some logic to only add our new code only when the class is an AssociationClass. I need to also add a test to ensure that a non-association class allows duplicate entries. Then I should submit a patch for this.
* Implement a warning to be generated if the class already has a key which does not contain the associations.
* Immutability was also added to my Issue, so I will look into that after the above is done, possibly as a third patch.
- First day of the UCOSP code sprint. Continuing on Issue 610 (on Google Code).
- Working with Andrew on the association class "key" issue, and raised Issue 630 (on Google Code)
- Worked with Andrew to create both failing and passing tests to demonstrate the functionality we would like to add with regard to Issue 610 (on Google Code). I was making a mistake, when I was originally trying to add the key manually, by typing
key {Flight, Passenger}as you would with an normal association; However, since this is an associationClass, we need to use lower case memberskey {flight, passenger}. We then modified the JET template in order to properly echo up the error into a RuntimeException. To complete this issue, I still need to do the following:- Write some Parser tests which verify that the key is being implicitly added (should fail)
- Modify the Parser to implicitly add keys for association classes
- Verify that the Parser tests that I added now pass
- Implement a warning to be generated if the class already has a key which does not contain the associations.
- Immutability was also added to my Issue, so I will look into that after the above is done, possibly as a second patch.
- My overall goal for this UCOSP semester and my work with Umple will be to learn how to successfully contribute to a large open source project and make a difference. My general area of interests are in the syntax, semantics, and code generation aspects of Umple. It is my desire to improve these areas of Umple to increase the usability and possibly even overall adoption of Umple as a standard UML tool. As a subgoal, I would also like to master the current development tools of Umple, such as ant, svn, and jet, which should help me to be a more experienced developer in the future.
- Arrived in Toronto. Met the rest of the team in person at the meet and greet.
- Having a hard time figuring out how to write tests. While it is mentioned in many places that you should write tests first, there is no real guide to writing tests or the test structure. Will have to ask about this at the code sprint. I am currently assuming that the tests we need to write should be in the "testbed" folder. However, I cannot find any tests there which relate to what I am currently working on, the associationClass. I have emailed Andrew asking him about this and if there is more documentation on the test layout and testing in general.
- Issue 610 (on Google Code): After discussing with Tim, we are going to look into defining a Key for the association class to be the associated objects. This will cause the equals and hashCode methods to be overridden by auto-generated variants similar to what I had implemented by hand previously. After some more investigation I have noticed that specifying a key of associations in a normal Class will indeed create the desired overrides with the desired functionality, but specifying a key of the associations in an association class has some strange side effects where these overridden methods are not comparing the keys as intended. I will look deeper into the code to see how these are being generated to see why they are not being generated the same for Association Classes. See the below snippet
For the class:
class PlayerOnTeam {
Integer year;
* -- 1 Player;
* -- 1 Team;
key { year, player, team }
}
//GENERATES:
public boolean equals(Object obj)
{
if (obj == null) { return false; }
if (!getClass().equals(obj.getClass())) { return false; }
PlayerOnTeam compareTo = (PlayerOnTeam)obj;
if (year != compareTo.year)
{
return false;
}
if (player == null && compareTo.player != null)
{
return false;
}
else if (player != null && !player.equals(compareTo.player))
{
return false;
}
if (team == null && compareTo.team != null)
{
return false;
}
else if (team != null && !team.equals(compareTo.team))
{
return false;
}
return true;
}
For the association class:
associationClass Booking {
* Flight;
* Passenger;
lazy seat;
key {Flight, Passenger}
}
//GENERATES:
public boolean equals(Object obj)
{
if (obj == null) { return false; }
if (!getClass().equals(obj.getClass())) { return false; }
Booking compareTo = (Booking)obj;
return true;
}
If we can get the key to work properly with the Association Class in umple, then this issue will become much easier. I will look into this further.
- Looked into issue 610 (on Google Code). The resulting reason for the reported error of duplicate entries in the list is because the code uses a List.contains(object) check. This does not reject the duplicate booking because while both bookings have the same values, they are different references/objects and are considering unequal to Java. To solve this problem, I will need to override the equals and hashCode methods of Object. I have preformed a test of this in Java code, and it performs the desired behaviour and rejects duplicates, which can be bubbled up into a runtime exception as desired. I need to look into Getting these override methods to be generated in the JET templates, but they are kind of confusing right now.
- Had issues installing JET which took some time.
- Had the weekly team video call meeting. We discussed that fixing Eclipse should be a priority for all of us over the next few days, so I will prioritize
- I have successfully been able to follow Nabil's steps for getting umple to work in Eclipse, which is merely building umple on the command-line and then using eclipse. However, if I compile using Master.ump, then my Eclipse problem returns.
- I delved into investigating the source of these eclipse errors, which seem to be in the Java code generation itself. I've emailed Tim about what I have found. I don't quit have a grasp on the problem so it is hard to summarize it for the moment.
- My week has been fairly busy, but luckily I am able to allocate a few hours to Umple today, and more over the following few days. My goals for tonight are to follow the DevelopmentSetUp steps again, and hopefully I will have less errors. And then I must pick my issues, as I seem to have slacked on doing that.
- I noticed that Ellen opened issue 625 (on Google Code), which seems to be what was giving me such a headache on September 7th. I'm glad others reported seeing it, because at the time I thought I was doing something very wrong. Hopefully, the issue is solved soon so I can do some work in Eclipse.
- Read about the ContributionProcessToUmple,Commiter resposibilities, CreatingAndApplyingPatches so I can fix the Hello World Examples Typo properly
- Fixed a small typo in the page https://code.google.com/p/umple/wiki/CommitterResponsibilities
- Fixed the typo in Hello World Example locally. Built the packageDocs and saw the change reflected. Preformed a full build and verified the test suite has no failures. There doesn't seem to be tests for the actual text documentation, only the example code, so I will email my patch to Tim for review and see if it is sufficient..
- I'm still not able to build in eclipse. I will summarize my problems in an email to the mentors/Tim, but otherwise I seem to be able to build fine by command-line. Perhaps I will use a different editor for now, until the bugs are ironed out.
- Sent an email to Tim about working on Issue 610 (on Google Code).
- Wasted a few hours trying to use the Eclipse plugin successfully. If I follow the steps at Install_Eclipse_Plugin, the ump file (containing the Hello World Example) will be compiled by Umple but the resulting Java files contain runtime errors. If I compile with the command-line Umple tool, then everything works fine. If I go onto UmpleOnline and then generate the Java code there, I can see the discrepency clearly: Generated by Eclipse
// line 14 "model.ump"
public static void main(String [] args){
Thread.currentThread().setUncaughtExceptionHandler(new .HelloWorld.UmpleExceptionHandler());
Thread.setDefaultUncaughtExceptionHandler(new .HelloWorld.UmpleExceptionHandler());
System.out.println("Hello World");
Generated by Command-line and UmpleOnline
// line 14 "model.ump"
public static void main(String [] args)
Thread.currentThread().setUncaughtExceptionHandler(new UmpleExceptionHandler());
Thread.setDefaultUncaughtExceptionHandler(new UmpleExceptionHandler());
System.out.println("Hello World");
I feel like I am wasting time trying to solve this right now, so I need to move on to setting up the development environment and I will either return to this or email Tim about it. further: Created some other examples from scratch, and noticed that anytime I declare the main method I get the "new .HelloWorld.UmpleExceptionHandler()" error, even though my new project has no references to anything HelloWorld related...
- Began setup of dev enviroment on OSX Mavericks.
- Set up SynchroSvnClient. Just the trial license, so will need to figure out something more permanent later. DONE: decided to use CL
- Checked out the code and built it using Ant. Everything seemed to work okay.
- Loaded the project into Eclipse and followed the steps outlined on the setup page. After compiling Master.ump, (Which doesn't really give any feedback if it's done or successful), and I try to run the Junit tests as described, I get told there are errors in the project, 14000 to be precise.
- Tried to run the build and compile functionality through ant, but now that keeps failing too. Going to give up on Umple for the night. Should probably start over from a fresh checkout. I feel the dev setup guide needs a lot of work.
- Had initial video meeting with team, led by Timothy, which included an overview of Umple and umple resources on google code.
- Encountered an issue with my university email not being able to access google code or google hangouts. This seems to be an issue on the University side. Opened a ticket, but it may prevent me from getting an early start. I can still read up on UMPLE, so that will have to suffice for now.
- Read through the Umple User Manual Basics.
- Typo in Hello World Examples:
"You will notice that Student is apparently defined twice.", should be "... Person is apparently defined twice." TODO: fix
- Played with the UmpleOnline tool, using both methods of generating code, through diagram creation and using Umple syntax.
- Downloaded the latest Umple jar from Github. Command line compilation of the Hello World example was quite simple and worked exactly as the user manual and downloads page explained. I was using Java 8, though. Whoops. No issues encountered, but that was most likely due to the simplicity of the Hello World Example.
- Added the plugin to Eclipse Modelling Tools smoothly. The red U icons appear as suggested in the installation guide. I still need to generate some Umple using the plugin.
- Wiki Home
- FAQ Frequently asked questions
- Examples
- Presentations
- PhilosophyAndVision
- Best practices for using Umple
- Publications and theses
- Tutorials
- Installing Eclipse plugin