Bugs discovery - User experience and relationship between elements

[s3408663]

Dear janszpilewski,

Firstly, We are students from RMIT University Vietnam. Writing documentation is a very important task that we have to conduct. In our opinions, WhiteStarUML is a very good software that has many StarUML significant bugs being fixed. We are very glad to see your great effort in building better quality software for drawing standard UML diagrams. So we would like to participate in further improving WhiteStarUML by noticing bugs that affect the user's experience negatively.

The User experience bugs that we think will impact the usability remarkably are listed as follow:

1. Regarding the View Copy function, users may feel uncomfortable when they want to reuse a design because in both WhiteStarUML and StarUML, the copied version of an element cannot be interacted in a new project (We can use Model Fragments, but there is another bugs related to this which is listed below this section). So users have to either copy the model of the element to another project or recontruct it by themselves again. However, the user guide states that there is no way to select multiple models, and it is so tedious to copy each element in a design to another environment. Thus we consider that this copy feature is not quite convenient since it does not do the thing that user expected like drawing a connection from the copied view to their current elements, and the display of the copy element is not natural (a letter 'M' is placed on the corner of the copied element). If you could copy the Model along with the View to a different project, that would be awesome!

2. The reverse engineering mechanisms and rules are not specified in the user guide. Thus we expect this function to do the very usual way of overwriting files in another application: if the names and elements of the old and the new files are the same, overwriting them with the new one. However, in WhiteStarUML, the elements and diagrams of the same name with the new one are not overwritten, but the names of the old one are modified and kept. Since WhiteStarUML does not allow user to select multiple elements, it would be a tedious task to delete the old diagram and its elements for a design with more than 10 classes to clean the space for adding newly generated elements in to the model.

3. We test this function to identify whether a Model Fragment can work well when we create new project and import the fragment. Despite that the model is constructed in the new project, the relationships among its classes are not maintained. Since the user guide tell us that we can reuse a part of our design by using the Model Fragment, the relationship among them should be kept so that users do not have to redraw them again. For example: we create package A that has 2 classes, B and C, B extends C. When we export Model Fragment of package A and import it to another project, the A, B, C models are constructed correctly, but the relationship between B and C disappears. Therefore, we can not reuse this design totally.

4. We test this function to verify if the code generation function works well in C++, C# and Java 1.5 even if no profile is selected. Consequently, we can only generate code without specifying profile in C++ and C#, but not in Java. Specifically: In the menu bar select Tools → Options → Select Java 1.5 in Option category → Code Generation → in the Option Item frame, under General tag, check “generate code even when the profile is not selected” → click OK. After that, right click on an element, select Java 1.5 → Generate Code, an error occurred preventing us from generating Java code

Finally, we would like to provide some bugs that are caused by validation errors. These bugs may not happen if the users are expert engineers, however, students may make mistakes if they do not understand the OOP rules. If they generate code with these errors in their design, they can not compile the generated objects. The bugs are listed as follow:

1. A class cannot implement itself. So users should not be allowed to draw a self-realization relationship on a class. For example: if the user creates class A, select Realization connection and click on class A, a Realization connection is created.

2. A class cannot implement a class. So users should not be allowed to draw a realization relationship from one class to another class. For example: if the user creates class A and B, select Realization connection and drag from class A to class B, a Realization connection is created.

3. A class cannot extend an interface. So users should not be allowed to draw a generalization relationship from one class to another interface. For example: if the user creates class A and B, select Generalization connection and drag from class A to interface B, a Generalization connection is created.

4. A subclass cannot extend two super classes, so we test if we can find this invalid connection in WhiteStarUML. So users should not be allowed to draw a generalization relationship from one class to more than 1 class. For example: if the user creates class A, B and C, select Generalization connection and drag from class A to class B, and class A to class C, 2 Generalization connections from 1 class are created.

5. A class cannot extend by itself, so we test if we can find this invalid connection in WhiteStarUML. So users should not be allowed to draw a generalization relationship from one class to itself. For example: if the user creates class A, select Generalization connection in class diagram, then click on class A, a self-Generalization connection is created.

6. If class name is not validated, we can insert special characters in the class name, which will cause compilation error when we generate code. For example: Cl@ssA

7. Class name should not contain Java or C++ or C# keywords like extends plus space character, which in case of Java, will cause a class to extend twice if the class name includes the word “extend” and it has a generalization relationship with other class. Moreover, the class name should be a single word without spaces to guarantee that there will be no compilation error. For example: "ClassA extends ClassB", "Class A"

8. If function name is not validated, we can insert number at the beginning of the function name, which will cause compilation error. For example: 2functions()

9. If function name is not validated, we can insert special characters in the function name, which will cause compilation error when we generate code. For example: funct!ons()

10. In drawing Use case diagram, if we create a new use case and type “<=2121”, instead of reporting error, the WhiteStarUML does not respond for a very long time, and the dialog box area where the error occurs appears on the Window screen, overlap all the other windows until we kill WhiteStarUML task. However, if we just type "2121" when creating a new use case, no errors happen.

We know that it is not easy to develop WhiteStarUML. So we hope that our bug notification here, in the customer perspective, will help your program become outstanding among the other UML drawing applications available on SourceForge. We are happy to know about your opinion toward the severity of the above bugs.

Regard,

RMIT students

[Janusz Szpilewski]

Hello,

Thanks for your support and the feedback. You posted quite a lot of ideas, some may be considered in the future but generally various models validity checks at the UML level should not be based on the validity of generated code in a given programming language as UML may be used to model various kind entities not necessarily software based so limiting entity name format would be a serious deficiency.

Additionally given that the program is open source and marketed as extensible you should be able to create such a model validator extension yourself if needed. If it is not clear how to do it actually it is the problem I should put more efforts on. This program will never get anywhere as long as all work is done by a single person in his spare time.

You also signal various problems with copying elements and using model fragments.
The catch is to be aware that the relations are models just like classes. So if you create two classes with a relation between them and next move both classes to another package the relation will remain in the original package. Neither it will be exported if you save the second package as a model fragment.
To visualize what I am talking about use "Filter Elements" dialog in the Model Explorer and choose "Select Relations". Now you will see that you have to move the relation model too. After that the model fragment will be saved and read correctly. It may be pretty misleading and I may think about coding auto-moving relations but for now a good rule to follow is to create a dedicated package from the start for every serious model and avoid moving elements.

In another place you mention problems with "<=2121". As you type "<=" you should see a popup saying "Generalized from current" and it indeed has special meaning leading to create n classes derived from the current one. And creating over 2000 classes may take some time. Try a simpler form like "<=5".

Code generation and reverse engineering are indeed far from being perfect but as such a functionality is coded as plugins they may be replaced in the future with something more modern and easier to be updated.

[s3408663]

Hi Janusz Szpilewski,

Thank you for appreciating our contribution to WhiteStarUML. Firstly, before we posted these bugs, we have realized that WhiteStarUML is mostly developed by you with several helps from the community. Therefore, the bugs we posted before and today are just our views on a number of things, which if being fixed will result in a better software. We see that you develop WhiteStarUML in your spare time, thus some features will need more time to be improved to the next level, not immediately. But the important thing is, we highly appreciate your wonderful effort in developing WhiteStarUML.

Regarding the UML purposes, you are right, it does not only modelling software application, but also depicting business processes. Therefore, forcing an OOP relationship rules in View will restrict the flexibility of WhiteStarUML. However, should we concern about the OOP relationship validations rules when generating code? Because when users generate code, they have already selected the programming language, and the model that they want to generate as well. For this reason, it would be so great if you can detect invalid OOP relationship before generating code, since if an invalid relationship exists, the result of WhiteStarUML code generation process will be affected as well.

In terms of copying elements, we have tried the Model Explorer with relationships being selected by configuring the Filter Element in the Model Explorer. At the moment, it is a good way to copy the model while maintaining the relationship, but the auto-moving relation that you mentioned will be much more convenient than the current Model Fragment Export solution. Thus we are very happy to see it happens in the future.

I did not perceive the "<=" as the way it is, I thought it will convert "2121" as a name and create a class like what I tried by typing "<=Abcd". But thanks to your explanation, I see it has a different meaning. Maybe a little more specific in the pop-up guide will help users discover the variations of annotation usage. Moreover, we are very happy to hear that you will replace the code generation and reverse engineering features with a better engine. We hope that it will be a huge success for you.

Additionally, we have found a number of bugs related to memory violations, performance, and configuration issues as follows:

1. When we import a standard Java Framework by selecting File -> Import -> Framework -> Java 1.2 Standard Framework --> choose target model, then three packages java, javax, org are imported into a target model. However, when we attempt to delete the java, javax or org package, it took it quite a long time (more than 5 minutes) and the WhiteStarUML application does not respond during that time.

2. In Use Case Diagram, when we create a new use case with a name “<=Ab, Ac”, then pressing Enter, three use cases are created, then click on other place to defocus the three use cases. When we undo the action, a memory violation error message occur, and if we keep pressing undo, the error messages are displayed again. If we click on other element, like Actor, Model or Open new project, the error message occurs again, preventing us from continuing our actions.

3. In Class Diagram, when we create a new class with a name “<=Ab, Ac”, then pressing Enter, three classes are created. When we undo the action, a memory violation error message occur, and if we keep pressing undo until the primitive state, the error messages are displayed again, and the “Ac” class still remain there when we keep pressing undo. If we click on other element, like Enumeration, Class or Interface, the error message occurs again, preventing us from continuing our actions. However, when we switch to another program and switch back, the elements that Enumeration, Class and Interface that we did not see previously due to the memory violation error message, does appear in the View when we reopen WhiteStarUML.

4. In Class Diagram, after we create an element, we can rename it to “”, then we generate the code or verify model, there should be an announcement stating that there is a blank element in the design, it will cause compilation error if the blank element is an interface or class. In business modelling perspective, a descriptive or original name should be replaced when users try to remove all characters from the name, or a warning should be displayed to ensure that users will not forget to name their elements afterward.

5. In Unit Control, if we create a control unit on a model, then we make a change to the content of the control unit .unt file, and navigate back to the WhiteStarUML window. A dialog box appears, telling us that the file is modified, do we want to reload it? Click No, then WhiteStarUML cannot be opened again, usually to other application, if we select No, the program will continue to operate in its current state. If we select Yes, the file name is reloaded and the software continue to work.

6. This is a configuration error, my computer does not work when I try to Convert Sequence (Role) Diagram to Collaboration (Role), but my partner’s computer has no problem with this. When I select a sequence (Role) diagram, and select Model → Convert Diagram → Convert Sequence (Role) Diagram to Collaboration (Role), an error message appears stating “Can’t find script engine VBScripts”, I installed WhiteStarUML in the default location, and my computer configuration is as follow: CPU Intel core i5-2430M, RAM 6 GB, GPU Intel(R) HD Graphics Family.

7. When we drag different menu elements such as Main Menu, Diagram Explorer, Model Explorer, toolbox, Alignment, View, Standard, and Format to random positions in the middle of the WhiteStarUML screen, then we click on another position to defocus the last moved view. The Main Menu, Alignment, View, Standard and Format toolbars are displayed on the front, but the Model Explorer, Diagram Explorer and Properties windows are hidden in the back of the screen. Therefore, we cannot focus on the Model Explorer, Diagram Explorer or Properties to place them in a new position because they are not on the front of the WhiteStarUML window.

8. Regarding the Main Menu, there is a “Add or Remove Button” on the far right of the Main Menu, when we click on that button and choose “Reset Toolbar”, there will be a number of features in the Tools and Help tabs like code generation, documentation generator and help guides disappear.

9. We also found a number of parameters management errors in documentation generator. On Main Menu, select Tools → Documentation Generator → Choose a template (For example: Usecase Specification Document)→ Click Template Properties → In Detail, Click Parameters, Click the button on the right of the Parameters value → Click on Add Button → input the Name value as “TemplateFile”, Type is “String”, Default Value is “Test” → Click OK. Click on the newly created Template File, check the Default Value and Type, it is the same as the value of the default “TemplateFile”, not “Test” as we expected.

10. Related to bug number 9, but for parameter deletion feature, On Main Menu, select Tools → Documentation Generator → Choose a template (For example: Usecase Specification Document)→ Click Template Properties → In Detail, Click Parameters, Click the button on the right of the Parameters value → Click on Add Button → input the Name value as “TemplateFile”, Type is “String”, Default Value is “Test” → Click OK. On the parameters window, click on the newly created TemplateFile, then click on the delete button, the default “TemplateFile” parameter are deleted, not the new one.

We also found a number of security issues

1. When we create a new projects, then we select File → Save As, select the location where a dll file
   of a program being placed, then type the file name exactly the same as a .dll file in Windows, the software will ask a confirmation to overwrite, click Yes, the dll file will be overwritten. If WhiteStarUML is run in administration mode, we can save file in C:\Window folder. This exposes a security issue, the save function should only permit to save file if its extension is “.uml” to prevent certain forms of security exploitation.

2. Regarding User Guide File, in the main menu toolbar, when we select Tools → Options → General, then we can change the value of the user guide file location to execute a file out of WhiteStarUML directory by adding a text “....[an executable file name]”. We can modify the location to let WhiteStarUML executes a file like Google Chrome or other application. This means we can run a malicious program using WhiteStarUML as well.

3. In documentation generator feature, when we tick on a template, for example Pseudo Code (IMPP), then we click on “Template Properties” button, In Details, click on the Parameters Value, then click on the button on the right of the Parameters Value text field, double click the TemplateFile and modify the Default Value to “C:\Windows[an executable file]”. Then we navigate back to the WhiteStarUML Generator Window, click the “Open Template” button, we can run that executable file, it will be dangerous if someone use this feature to run a malicious software under WhiteStarUML session.

Again, we know that you are working on your spare time, and developing a software like WhiteStarUML is very challenging, thus these bugs can be fixed sometime in the future. We are very happy to discuss with you further about the bugs, and see a wonderful update of your software in the future, Janusz.

Happy New Year! We wish the best for you.

All the best,
RMIT students.