I've been working on a project with a client recently, and they wanted to make some changes to a model that I'd been working on. I sent them the model, and later watched them try to make some changes to the model. Here are some of the observations I made:
1. Adding Attributes/Operations With the + icon is difficult. Finding just the right position that will cause the + to appear is difficult, and editing the attribute underneath the + is made difficult when the + shows up on top of the attribute that you want to edit. 2. Figuring out the associations/aggregations/compositions between classes is not really intuitive. This is partly due to a certain amount of naivete about UML, but partly due to the fact that we have at least 6 different ways of associating classes, and figuring out the right combination of settings that will result in the code you want is a bit of a hit-or-miss proposition. Drawing a "UniAssociation" between two classes and a "UniComposition" between two classes results in the same code. 3. When you create associations between classes the variables they create within the classes are public by default, and changing their visibility doesn't change the resulting code (I've filed an issue on this). 4. When you create attributes in a class, they are public by default, even though most people want them private by default. You have to explicitly type the - prior to entering the attribute name if you want them private. 5. If you don't remove associations from the model (not just the diagram), you end up with unusable code. Most people assume that if you delete something from the diagram, it's removed from the model. Yes, I know that there are separate "Delete From Model", "Delete From Diagram" menu items, but by default, when you press the delete key, you're really just deleting from the diagram. And there's no dialog that tells you what's going to happen. Perhaps having shortcut keys for these operations would help. 6. Creating packages and putting the classes in the packages is not easy. I've filed a couple of issues about this already. After a few minutes of watching them struggle with the changes, they printed out the diagram, scribbled the changes they wanted on it, and gave it back to me. In general, the UML-ishness of the user interface becomes confusing and daunting to people who don't use UML that often. People tend to work within a language, and don't spend that much time learning all the details behind UML. The results of the model will eventually become code (either manually or through code generation). So closing the gap between UML and the user's programming language is really important. What's confusing is UML terms for things in your language of choice. For example, you have an arrow that creates a Generalization between two classes. If I'm working in Java, I want to know that "Generalization" is UMLspeak for "extends". Similarly, knowing that "Realization" results in an "implements" declaration would also be useful. This might be accomplished by changing the stereotype on the diagram from "realizes" to "implements" or whatever your language of choice calls it. I realize these are really basic examples, but you get the idea. Hope this helps, Mark ------------------------------------------------------ http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2942574 To unsubscribe from this discussion, e-mail: [[email protected]]. To be allowed to post to the list contact the mailing list moderator, email: [[email protected]]
