Comparing two ways of applying use case models in object-oriented design with UML
Erik Syversen · NORA - Norwegian Open Research Archives · 2002
In software engineering most proposed technology have not been subject to a thorough investigation. Knowledge of the effects, strenghts, and weaknesses of technology is essential to ensure a successful transfer to industry and identify areas of improvement. For example, the Unified Modeling Language (UML) is becoming the de-facto standard for object-oriented software analysis and design. Constructing analysis- and design models of a software system is beneficial to gain a higher-level understanding of the system domain prior to implementation. Models provide blueprints of possible solutions and are beneficial to comprehending a complex system in its entirety, ensure a sound architecture, and to support communication among project developers and teams. However, UML does not prescribe a development process, nor has it undergone a thorough investigation to identify how it is best applied in a software development process. A use case driven development process, where a use case model is the basis for constructing an object-oriented design, is recommended with UML. An alternative way of applying a use case model is to use it to validate a design model made as part of another development process. We are interested in the differences imposed on design models constructed between such processes. In order to investigate the differences, we conducted a controlled experiment with 26 students as subjects. One half of the subjects were given guidelines on a use case driven process whereas the other half on a validation process. The resulting class diagrams were evaluated with regards to how well they were suited as a basis for automatic code generation. The results show that the validation process produced class diagrams better suited for automatic code generation than those produced in the use case driven process. In particular, the subjects applying the use case driven process primarily identified methods that were mapped directly from the use case descriptions, something that resulted in design models with fewer appropriate methods than those produced with the validation process. The results also show that the use case driven process resulted in more erroneous classes, and the validation process led to a larger variation in the number of classes in the class diagrams. This indicates that the use case driven process gave more, but not always more appropriate, guidance on how to construct a class diagram. In summary, our study implies that following a validation process is the better choice in similar conditions to our experiment.