TCLethbridge edited this page Aug 29, 2015 · 2 revisions
Clone this wiki locally

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.

Log entries

NOTE: Entries are listed in reverse chronological order.

Dec 18th 2012 (part 2)

With Direction from Professor Lethbridge, I have done further testing on which features of Umple can be imported into Papyrus successfully, and which need further patches to be functional. My work was delayed by family issues, preventing work beyond the gathering of information.

Basic methodology: Identify elements to test. Find or edit example documents that display those features and few if any others. Compile umple file to generate Papyrus code. Import the new project into Papyrus (Eclipse, Juno version). See what structures were reflected, if any.

Simple Classes -> Testing umple files with simple classes. All classes reflected appropriately in Papyrus.

Simple Method -> Testing umple classes with simple methods. The classes is loaded correctly in Ppayrus, but the method is not present.

Simple Associations -> Testing some assorted simple, undirected associations. Multiplicity and direction reflected. Names of the ends seem anomalous (LS will have lower case copy of class as name, RS will be the same but with a 's' appended). Test file taken from http://cruise.site.uottawa.ca/umple/Multiplicity.html

More Associations -> Testing some more associations, particularly asymmetric associations. Directed associations do not appear to be reflected in Papyrus. Rather than asymmetric association (unidirectional), standard symmetrical (bidirectional) association is used in Papyrus. As an interesting note, the A-B association indicates neither direction is navigable, something I have not seen elsewhere. Test file take from: http://cruise.site.uottawa.ca/umple/AssociationDefinition.html

Role Names -> Testing names of associations. Naming in umple is translated to papyrus. Association name is class1_class2: rolename1_rolename2 with the appropriate substitutions. The end of the association with the role name will have the rolename label. Test file taken from: http://cruise.site.uottawa.ca/umple/RoleNames.html

Reflexive Associations -> Testing symmetric and asymmetric reflexive associations. All associations appear to be functioning correctly and represented accurately in Papyrus. Test file associated from: http://cruise.site.uottawa.ca/umple/ReflexiveAssociations.html

Association Class -> Testing Association Classes. The association class is represented in Papyrus accurately as a series of classes. There is no special notation to represent an Association Class (which Papyrus does have). Test file taken from: http://cruise.site.uottawa.ca/umple/AssociationClassDefinition.html

Generalization -> Testing generalization ('isA' clause). Generalization is imported into papyrus just fine. No problem. Test file taken from: http://cruise.site.uottawa.ca/umple/isAclause.html. As indicated by interface testing; decided to test one class with multiple generalizations (like in interface example from interfaceDefinition), only one generalization was reflected in Papyrus.

Interface -> testing implementation of interfaces (a specific use of the 'isA' clause). The test file taken from http://cruise.site.uottawa.ca/umple/interfaceDefinition.html causes error (Null Pointer Exception) when loaded into papyrus. Removing 'depend' clause does not help. Removing methods does not help. Removing multiple generalization does not help. Conclusion: interfaces are not supported by Papyrus.

State Machine -> Testing for implementation of state machines. Loading into Papyrus does not cause errors, however data is not complete. Only class describing the outer layer of the state machine and attributes of that class are present, all methods and internal structure are absent. Test file taken from: http://cruise.site.uottawa.ca/umple/BasicStateMachines.html

Dec 9th 2012 (part 2)

Following are my notes on where I believe further modification to generating Papyrus content should be directed.

So far, I have modified Umple so that instead of creatinga single file named FILENAME.uml, it creates a directory called FILENAME filled with three files, .project, model.di, model.notation, and model.uml. The older Papyrus generation material goes into the model.uml file. At the moment, .project, model.di and model.notation are filled with a bare minimum to allow the material to be loaded into Papyrus.

When loaded into Papyrus, all of the classes and associations exist, but a diagram is not created visually. I believe, to make a visual diagram, what must be improved is the generation of the model.notation file.

I began by examining the model.notation file generated after loading a simple mentor-Student example into Papyrus, and dragging and dropping the elements onto the canvas.

The classes appear to be represented by elements with a <children> tag and a "notation:Shape" type. These elements have a number of sub structures, including <eAnnotations>, <children>, <element> and <layoutConstraint>.

  • The <element> tag links back to the Classes in the model.um file with syntax: "FILENAME.uml#CLASSNAME". One of the children tags does this as well (I beleve, to get the name of the class it is representing)
  • In the element <layoutConstraint>, x and y are specified. Given that all of the <children> tags with the shape notation do have this element, and not all have other elements that specify x/y, I conclude this dictates the positioning of the class object.

After the <children> with notation:Shape are declared, there is a <styles> tag, I believe just identifying this as a diagram.

then there is an <element> tag, which links back to the model.uml file again. I believe this is where the document is explicitly made to reference the other file.

Following this are a number of elements described as <edges>. These appear to be the associations between classes. The 'source' and 'target' fields are references the xmi:id fields of the shapes specified earlier.

  • <children> tags here seems to describe additional decorations, with specific "type" variable specifying the data to display.
  • <styles> tags seem to note font size.
  • <element> tags here are directed towards the associations these edges describe in the model.uml.
  • <bendpoints> tags appear to describe the route the edge takes.

everything is wrapped up with a </notation:Diagram>.

I believe for moving forward, what will need to be done is that a model.notation file that adequately describes the uml diagram will need to be generated. This will give Papyrus a layout to display, and make importing into Papyrus more rewarding.

To do this, the general form of the main papyrus code generator should be used. That is to say, a string should be built which will contain the file contents. The string is built by looping through all of the classes in the umple file, and then all of the associations.

For each class, the program should add to the string a all the appropriate formatting. This will be fairly easy as the majority of it can be copied verbatim from examples which can be easily generated with Papyrus; most parts of the <children xmi:type="notation:Shape" …> elements do not seem to change significantly. Of particular note that must be specified are the <element> element which must be directed towards the model.uml file, and the <layoutConstraint> element, which must specify a valid position (in pixels) for the class to appear on the diagram.

Following this, for each association, an <edge> element should be constructed. Again, a bulk of this can be taken from easy to generate examples created in Papyrus. Of particular note is that the 'source' and 'target' must be specified, these should refer to the xmi_id fields generated for the classes above. The <element> element should reference the appropriate association in the model.uml file. And the <bendpoints> element should be spatial positioned in an appropriate manner.

Dec 9th 2012

Work on step 1 complete.

No particular part of the implementation was very problematic.

Updates from Java 6 to Java 7 have caused some issues; as my current development environment is Java 6 and cannot be upgraded (Mac OS X 10.6.8). This is preventing me from creating a proper patch at this time.

It's looking unlikely that I will be able to move on to step 2. I am focussing remaining work on recording what I have learned and describing recommendations for next steps. Perhaps I will be able to continue work on this project in coming semesters.

Documentation on using new features to create Papyrus has also been written. PapyrusGeneration.

Dec 5th 2012

Proceeding with work on step 1 as described in previous log entry. (That is to say, making the Papyrus Generator put newly generated .uml files in their own folder, ready to be imported as a papyrus project.) The actual modifications to the code base seem simple, and I've been able to get them created rather easily.

Updating the tests so that they check for the new conditions and pass / fail in the correct situations is proving tricky. (Yes, I am aware that strictly speaking I have violated test-driven development practices). Seeking to work on test cases so they test for correct situations.

Specifically, having trouble with the tests described in PapyrusGeneratorTest.java. The Papyrus and Associations tests both follow a fairly simple two step process of asserting an umple template for a file, and checking that a file was created. Need to direct one or both of these to look for files in a different folder then the home folder. (Also, must update the tearDown() method...)

Will work on understanding the 'assertUmpleTemplateFor(...) function used in these tests better. Perhaps this will resolve issues.

Dec 4th 2012

Moving along from previous log entry:

Running the command “java -jar umple.jar -g Papyrus [filename].ump will create a file called [filename].uml. This file will describe the classes and relations contained in the umple diagram described.

In an inelegant manner of doing things, this uml file can be loaded into an empty Papyrus project by changing the name to match the uml file in the Papyrus project, and then copy pasting. For example if the Papyrus project has the files {“model.di”, “model.notation” and “model.uml”}, rename your newly created uml from umple file “model.uml” and move it into the same folder as the Papyrus project, replacing the older .uml file.

This new project can be opened in eclipse as described earlier.

In the 'model explorer' section you will be able to see all the different classes and relations described in the Umple file. However, as is to be expected given the emptiness of the notation file, there will be no diagram to speak of.

A diagram can be easily created by clicking major components in the model explorer and dragging them onto the diagram in the main canvas. This can then be saved, reopened and so forth normally.

This however, is not the optimal solution.

What would be more desirable is for the Umple program to produce a more robust file to start with, one which is easier to load into a Papyrus project, and one which has a diagram created automatically.

The Papyrus generating code is (at the time of writing this) on line 234 of Generator_Code.ump. It appears to be a fairly self explanatory (though still uncommented) process of creating a very large string describing the umple code in xml, and then writing that to a file.

Step 1 will be to modify the above to create a folder with essentially empty .notation and .di files to facilitate the easy loading of the created papyrus diagram into Eclipse.

Step 2 will be to populate the .notation file so that it contains actual content and draws a Papyrus diagram. This will probably involve looking at the umple online code to get some ideas of spacing.

As a note; this site: http://wiki.eclipse.org/Papyrus_User_Guide#Tutorials_on_UML_modeling_with_Papyrus appeared to have some helpful information, but appears to be out of date, as the instructions described no longer apply.

Nov 16th 2012

Blows the dust off. There's no real excuse for the lack of updates, I'm pretty awful at this. Moving along:

I have been continuing to work on Papyrus, and interpreting the XML it generates. I still have not found a specification of how Papyrus saves it's XML files. As recommended by Prof. Lethbridge, have been working on designing common Umple examples in Papyrus and seeing how these are saved.

Progress so far has generally been positive. The examples created, as well as my notes on the matter, are attached (or not). Be warned, the notes are fairly stream-of-conciousness.

On further discussion with Prof. Lethbridge, will be redirecting focus to the existing Papyrus generating code in Umple. More information to follow.

It seems I'm having some trouble attaching files to the wiki, so Iwill copy paste my Papyrus notes here.

How does Papyrus save it's XML?

There appear to be 4 or so components of even a very simple Papyrus project. Each of these appears to be an xml file with specific names.

  • project <-- Seems to identify the project for eclipse, so far only has name, perhaps ties in to other java projects?
  • odel.di <-- Does not appear to have any useful content? Perhaps related to when several diagrams are part of the project?
  • odel.notation <-- Appears to have content about the diagrams. At a glance, this would seem to be data for displaying and formatting the diagram. (References to fonts, x/y coordinates, etc.)
  • odel.uml <-- Would seem to be the place where the main elements of the diagram are specified.

To start with, it appears that in 'model.uml', there are a number of items referred to as “packagedElement”s. These packaged elements seem to have a number of elements, such as 'xmi:type', 'isUnique' and the rather useful 'name'.

For example when creating the simple Person –> Mentor/Student relation, there was a Packaged Element for each class.

As an experiment, I tried changing the “name” variable of one of these classes. Saving this change and refreshing the document in eclipse successfully changed the name, progress!

Looking through, I can see various simmilar, relatively readable, encodings. For example, the 'Person' class has an owned attribute which based on it's naming, corresponds to the named variable added in the examples. The Student and Mentor classes have a 'Generalization' element, which apepars to point back to the 'Person' class. Yet another element is the one identified as 'xmi:type=association' which seems to describe the Mentor-Student relation fairly explicitly.

So far, this is surprisingly straight forward.

Each item appears to have an 'xmi:id' field which is a unique identifier. Many elements (such as associations) reference these fields rather then anything else. It does not appear that the xml:id needs to have any specific relationship to the content, because experimenting with editing the xml:id field of items in the document and then reloading in eclipse have so far worked. A full definition of the field as defined for xml can be found here: http://www.w3.org/TR/xml-id/

Papyrus Projects can be loaded into Eclipse by selecting File > Import > Existing Project > desired Papyrus project.

Tried creating a new Papyrus model by writing in xml. The model is simple and contains four classes which are not related and have no interesting properties. Loading the model into Eclipse was successful!

Editing the model in Eclipse and then saving the changes causes the appropriate elements to be created and added in to the xml files. The more human readable xmi:id fields I used (such as 'alphaid') appear to have been accepted and are in use by other elements.

Upon experimentation (loading a model.uml file without a corresponding model.notation file) indicates that the model.uml file contains the objects and properties thereof for the model; while the model.notation file contains all of the details regarding the display of these models visually.

It seems relevant to note that a model.uml can be loaded into a blank project, and Eclipse will recognize the objects (classes, associations, etc.) described in it, but will not display them. On the other hand, when loading a model.notation into a blank project, nothing much happens at all. This does not match the behaviour of importing a project where if either side is inconsistent, eclipse generates an error.

Adding associations to my prototype class so far continues to result in errors; I suspect I have created / copied the contents of the model.notation incorrectly.

Oct 22nd 2012

I have been investigating Papyrus and the capabilities it offers. Learning the ins-and-outs of Papyrus has been slow so far. The majority of Papyrus documentation on the old development site (unfortunately, the first result in google) is in the form of silent videos; lacking descriptive voice overs or explanatory text these can be a bit tricky to follow. Making good progress so far despite this, especially after finding the more recent development site and wiki.

Locating the specification of the format Papyrus saves XML files in and loads files from is proving troublesome. Continuing to search for this while learning the ins and outs of using papyrus.

Sept 30th 2012

I've finished the first patch for issue 337 (on Google Code), and sent it to umple-dev. Details of the process and what I did are in that issue.

I'm beginning to become more comfortable with the architecture, language, and build process of umple, which is gratifying.

I'm not sure what I'd like to do as a my project for the remainder of the semester. I think I will continue working on this issue, and the related issues for the moment to keep me busy. I'll investigate the papyrus code base to see if that's something I'd like to work with. I'll also investigate other possible projects.

Sept 29th 2012 (Aft)

Today made good progress in learning the architecture of Umple (usually by breaking it).

Wrote a number of simple umple files to use for testing; as well as the tests which call them. I've also written a method that should sufficiently test for the desired cases, and throw the appropriate errors (without regex, I could cut the lines of code down to a quarter using regex).

Tomorrow I will be working on finding the approrpiate places to call the new method to generate the appropriate errors. Then tidying everything up and hopefully submitting it all as a patch.

Sept 29th 2012 (Morn)

Getting set up yesterday was relatively painless, if a bit on the slow side. The documentation is a decent step-by-step guide; but does not provide very much (or much of any) feedback on why certain things are being done, or how to fix them when they go awry.

Selected my first issue (337) to work on. I've consulted with Tim and Andrew about how to resolve the issue and reviewed the sample solution to 295. I've so far been working on identifying the desired specification, as well as locating where the class name is assigned and examining other tests.

I think the identifiers for the UmpleClass are stored in the variable named "name" which is inherited from UmpleElement. I still need to locate where and how this is assigned in a class constructor. Following Andrew's suggestion I have been using search tools (in Eclipse) rather then trying to memorize the umple architecture.

Sept 24th 2012

Completed the technology review advised by Tim Lethbridge. Some difficulties running JUnit tests from command line, but no other difficulties.

Successfully installed and run umple compiler from command line and eclipse.

Continuing review of umple code, design and philosophy. I'm going to write some test programs in umple and see if they compile to similar programs as if I would have written it in java.

Replace this with the date e.g. Mar 22nd 2012

Replace this with the text of your entry.