Semantic and Structural Difficulties with the Unified Modelling Language Use-Case Notation version 1.3

A case study was undertaken to examine and apply the UML use-case notation version 1.3. This study shows that the notation is open to interpretation and the semantics of the use-case relationships are confusing. The attempt to bolt on the object-oriented inheritance structure to the use-case notation is shown to cause problems with users. Generalisation tries to give use cases an object-oriented feel despite the fact that use cases are fundamentally orthogonal to object-orientation [1]. The case study undertaken involved students developing a use-case diagram and descriptions for a proposed application. We describe a general explanation of the findings. The first finding is that there are risks in making use cases too generic. For example, in this study two of the use cases were combined into one by many of the students. This unification makes some sense, as the two functions appear to be the same except for what appeared to be small details. However, the requirements are very different: one is to request new equipment; the other is to move existing equipment to another room or computer. One could argue that the overall requirement would be to install equipment (hardware and/or software) but the effects on the problem domain would be different. The second finding was a concern that arose over the communication association lines. That is, how does one show a passive actor receiving some information? For example, a use case "Reply to Requests " show