In software engineering most proposed technology have not been subjectto a thorough investigation. Knowledge of the effects, strenghts, andweaknesses of technology is essential to ensure a successful transferto industry and identify areas of improvement. For example, theUnified Modeling Language (UML) is becoming the de-facto standard forobject-oriented software analysis and design. Constructing analysis-and design models of a software system is beneficial to gain ahigher-level understanding of the system domain prior toimplementation. Models provide blueprints of possible solutions andare beneficial to comprehending a complex system in its entirety,ensure a sound architecture, and to support communication amongproject developers and teams. However, UML does not prescribea development process, nor has it undergone a thorough investigationto identify how it is best applied in a software development process.A use case driven development process, where a use case model is thebasis for constructing an object-oriented design, isrecommended with UML. An alternative way of applying a usecase model is to use it to validate a design model made aspart of another development process. We are interested in thedifferences imposed on design models constructed between suchprocesses. In order to investigate the differences, we conducted acontrolled experiment with 26 students as subjects. One half of thesubjects were given guidelines on a use case driven process whereasthe other half on a validation process. The resulting class diagramswere evaluated with regards to how well they were suited as a basis for automaticcode generation. The results show that the validation process producedclass diagrams better suited for automatic code generation than thoseproduced in the use case driven process. In particular, the subjectsapplying the use case driven process primarily identified methods thatwere mapped directly from the use case descriptions, something thatresulted in design models with fewer appropriate methods than thoseproduced with the validation process. The results also show that theuse case driven process resulted in more erroneous classes, and the validation process led to a larger variation in the number of classesin the class diagrams. Thisindicates that the use case driven process gave more, but not alwaysmore appropriate, guidance on how to construct a class diagram. Insummary, our study implies that following a validation process is thebetter choice in similar conditions to our experiment.