Object-Oriented Modeling with UML: A Study of Developers Perceptions

Transcription

1 Object-Oriented Modeling with UML: A Study of Developers Perceptions Ritu Agarwal and Atish P. Sinha The object-oriented (OO) approach provides a powerful and effective environment for modeling and building complex systems. It supports a variety of techniques for analyzing, designing, and implementing flexible and robust real-world systems, providing benefits such as encapsulation, polymorphism, inheritance, and reusability [5, 9]. During the analysis phase, systems analysts abstract concepts from the application domain and describe what the intended system must do, rather than how it will be done. They specify the functional behavior of the system, independently of concerns relating to the environment in which it is ultimately implemented. During the design phase, systems designers define how the application-oriented analysis model will be realized in the implementation environment. Finally, during the implementation phase, the design models are translated into program code using a chosen programming language and, often, into a database implementation using a specific DBMS. The Unified Modeling Language (UML) was adopted as a standard for OO modeling by the Object Management Group (OMG) in The UML has already found widespread use in diverse domains such as e-commerce, command and control, computer games, medical electronics, banking, insurance, telephony, robotics, and avionics [4]. However, the continued success of any new language, or of any new technology for that matter, depends extensively on its usability [11]. Much of the discourse on usability has focused on the interface between end users and the software programs or systems they interact with (see, for example, [11]), rather than on the tools or languages used by systems developers to build those programs or systems. But to predict the future success of a language like UML, it is important to address the issue of usability from the perspective of the ultimate users of the language: the systems developers (such as the analysts and designers) themselves. We report the results of an empirical study aimed at assessing the usability of UML. The study involved developers who had earlier received training in and gained Ritu Agarwal (ragarwal@rhsmith.umd.edu) is an associate professor in the Robert H. Smith School of Business at the University of Maryland. Atish P. Sinha (sinha@uwm.edu) is an associate professor in the School of Business Administration at the University of Wisconsin-Milwaukee. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee ACM 248 September 2003/Vol. 46, No. 9ve COMMUNICATIONS OF THE ACM

2 practical experience in developing OO models using the UML notation. Because UML supports a variety of modeling techniques, we address the usability of those techniques individually, as well as the usability of UML from an overall standpoint. We also examine what types of background are amenable to positive perceptions of usability; that is, we characterize the type of systems developer who is more likely to find UML easy to use. UML Diagrams UML can be used for visualizing, specifying, constructing, and documenting the artifacts of software systems [5]. The UML notation is useful for graphically depicting OO models. It is not only useful for specifying system requirements and capturing design decisions, but also for promoting communication among key individuals involved in a systems development project. UML allows modelers to represent multiple independent perspectives or views of a system using a variety of graphical diagrams, such as the use case diagram, class diagram, state diagram, sequence diagram, and collaboration diagram [5]. Those views are integrated so that the system can be analyzed, designed, and implemented in a complete and consistent fashion. Jacobson [9] pioneered the application of use case modeling for analyzing the functional requirements of a system. A use case model is developed during the early phase of requirements analysis. Use case modeling helps developers gain a clear understanding of the functional requirements of the system, without having to worry about how those requirements would be implemented. A use case model acts as an effective tool for communication between developers and end users. It is also traceable to the other UML models, thus promoting modifiability. A use case model consists of actors and use cases; an actor is an external entity that interacts with the system. A use case represents a sequence of actions initiated by an actor; it represents a complete functionality. A class diagram depicts the static structure of a system in terms of object classes, their attributes and operations, and their relationships with one another. Each class represents a set of objects that share a common structure and a common behavior. The external interface to a class is provided by its operations. Classes may participate in association relationships, generalization relationships, and aggregation relationships. A class diagram can capture many other types of application semantics, such as association roles, role constraints, association classes, abstract classes, abstract operations, polymorphic operations, derived elements, class-scope attributes and operations, generalization discriminators, and semantic constraints among subclasses. A state diagram depicts the various state transitions or changes an object can experience during its lifetime, along with the events that cause those transitions. While a class diagram portrays the static structure of a system, a state diagram captures its dynamic or behavioral nature, in terms of state transitions. A state is a condition during the life of an object during which it satisfies some condition(s), performs some action(s), or waits for some event(s). The state changes when the object receives some event; the object is said to undergo a state transition. The state of an object depends on its attribute values and links to other objects. An event is something that takes place at a certain point in time; it triggers a state transition. An object remains in a particular state for some time before transitioning to another state. A state diagram COMMUNICATIONS OF THE ACM September 2003/Vol. 46, No. 9ve 249

3 captures all the possible states of an object, the state transitions, the events or conditions that trigger those transitions, and the associated actions. In UML, an interaction diagram is used to show the pattern of interactions among objects for a particular use case. There are two types of interaction diagrams: sequence diagrams and collaboration diagrams. Both of them express similar information, but they do so in different ways. While sequence diagrams show the explicit sequencing of messages, collaboration diagrams show the relationship among objects. Both are useful for developing a dynamic model of a system in terms of object interactions. Objects communicate with one another by sending messages. Assessing the Usability of UML The participants in the empirical study were MBA and undergraduate students taking a course in Object-Oriented Analysis and Design. Most of the MBA students were professionally employed and were taking the course on a part-time basis, while all the undergraduate students were full-time students. As part of the course requirements, students worked in teams of four or five on a systems analysis and design project. Each team identified a real-world application for OO analysis and design, which involved developing a requirements analysis model using use case diagrams; a structural model using class diagrams; a dynamic model using state diagrams; and a dynamic model using interaction (sequence/collaboration) diagrams. While the use case diagrams pertained to the analysis phase, the other diagrams applied to the design phase as well. The diagrams resulting from the analysis phase were revised and refined in the design phase to reflect the needs of the implementation environment. The projects ran for about three months. All teams used Rational Rose, a CASE tool that allows developers to draw the different UML diagrams and document them. The projects ranged in scope from a customer and program tracking system for continuing education at a private university, to a customer services system for a large computer manufacturer, to reengineering of audit services of a large paper products company. Two surveys were administered to each subject. The first was used at the beginning of the course to gather background information about each participant. The information collected include the participant s history of prior course work in MIS and computer science; level of knowledge of traditional systems analysis and design techniques (such as data flow diagrams, data dictionaries, system flowcharts, and so forth) and OO techniques (such as object/class diagrams, use case diagrams, interaction diagrams, and so forth); level of knowledge of conceptual data modeling techniques (for example, E-R diagrams); level of experience in applying the various techniques; and level of proficiency with database management systems, CASE tools, and programming. The second survey was administered to each participant at the end of the course, after completion of the team projects. The questions were designed to assess the usability of each of UML s major modeling techniques: use case diagrams; class diagrams; state diagrams; and interaction diagrams. Questions were adapted from a widely used multi-item instrument to measure the ease of use of any new technology proposed by Davis [6]; the instrument has been validated by several empirical studies. For each type of diagram, the participants responded to whether they agreed or disagreed with four statements (see Table 1) relating to the ease-of-use of the diagram on a 7-point Likert scale, with 1 being strongly disagree, 4 being neither agree nor 250 September 2003/Vol. 46, No. 9ve COMMUNICATIONS OF THE ACM

4 Scale for Ease-of-use Learning to use UML use-case diagrams was not easy for me. It is easy for me to become skillful at using UML use-case diagrams. I found it easy to create a requirements model using UML use-case diagrams. I found UML use-case diagrams easy to use. Note: Similar items were used for each of the four UML diagrams, as well as UML overall. Table 1. Measuring the usability of UML diagrams. disagree, and 7 being strongly agree. To protect against respondent fatigue, some statements were purposely worded in the negative, for example, Learning to use UML use-case diagrams was not easy for me. In addition to collecting ease-of-use data on each of the individual UML diagrams, the questionnaire also included five questions relating to the overall ease-ofuse of the UML diagrams. For example, two of the statements that the participants responded to were: Overall, I found UML diagrams easy to use and I found it easy to create different types of object-oriented models using UML diagrams. The reliability of the measurement scale for each category, as determined by Cronbach s alpha, was more than adequate. The reliability figures were 0.79, 0.90, 0.94, and 0.93 for the ease-of-use scales for use case diagrams, class diagrams, state diagrams, and interaction diagrams, respectively. The reliability of the scale for overall ease of use was These high reliability scores increase confidence in the validity of this study s findings. Developer Reactions to UML We conducted one-sample t-tests to measure the ease-of-use for each of the five categories. Because 4 on our scale represents indifference ( neither agree nor disagree ) as to whether a diagram is easy or difficult to use, the t-tests examined if the mean of the usability scores given by the participants was different from 4. As Table 2 shows, for all the UML diagrams, except for interaction diagrams, the mean scores were significantly higher than 4, implying the participants perceived the diagrams as easy to use. The mean score for interaction diagrams was also higher than 4, but the difference was marginally significant (p = 0.057). The mean overall score was significantly greater than 4, suggesting that developers perceived UML diagrams as being easy to use overall. A repeated measures ANOVA procedure was applied to test the null hypothesis that there is no difference among the four types of UML diagrams in terms of usability. The null was rejected by the multivariate test (p =.000), as well as by the univariate test (p =.000). Because an overall difference was found, we conducted post hoc tests to determine which diagrams differed with respect to usability. In particular, we employed the Tukey procedure, setting the overall significance at.05, to test for pairwise differences between the UML diagrams. COMMUNICATIONS OF THE ACM September 2003/Vol. 46, No. 9ve 251

5 UML Diagram Ease-of-use score (N = 39) Mean Std Dev t-value Significance Use Case Class State Interaction Overall Table 2. Perceived usability of UML diagrams. UML Diagram Pairs Paired differences in ease-of-use of UML diagrams Number of pairs = 39 (I and J) Mean Difference (I J) Finding Use Case and Class.769 * Use Case > Class Use Case and State Use Case and Interaction.577 * Use Case > Interaction Class and State * State > Class Class and Interaction State and Interaction.814 * State > Interaction * Significant at overall α =.05. Table 3. Pairwise comparisons of usability. As Table 3 shows, both use case diagrams and state diagrams were perceived as being easier to use than class and interaction diagrams. In contrast, class diagrams and interaction diagrams were not perceived to be significantly better, in terms of usabil- 252 September 2003/Vol. 46, No. 9ve COMMUNICATIONS OF THE ACM

6 ity, than any of the other diagrams. The differences between use case and state diagrams, and between class and interaction diagrams, were not significant at the overall.05 significance level. For each of the UML diagrams, we also ran multiple regressions with the dependent variable being ease-of-use and the independent variables being prior knowledge and experience in process-oriented techniques; OO techniques; conceptual data modeling techniques; and system development (use of DMBS software, use of CASE tools, and programming). Each independent variable was measured by two or more items, with reliabilities ranging from 0.67 to Interestingly, we found that experience in conceptual data modeling or system development had no significant effects on the usability of any of the diagrams. However, as Table 4 shows, developers with more experience in OO analysis and design techniques perceived class diagrams and interaction diagrams as being easier to use than those with less experience. On the other hand, greater experience in process-oriented analysis and design techniques resulted in more positive perceptions of the usability of UML diagrams, overall. To gain additional qualitative insight, we also asked the developers to identify the aspects of UML modeling they liked best and the ones that frustrated them the most. Table 5 summarizes the most frequently recurring themes in their reactions. As one subject noted, use cases were especially useful in terms of documenting real world problems in a clear and understandable form, a sentiment echoed by many other respondents. However, many were frustrated at not knowing how much detail to put in a use case. With regard to class diagrams, many liked how relationships, attributes, and operations are represented, though others had problems with defining operations. As one subject noted, I found figuring out the operations the most difficult, because I had to really understand the class. A large number of respondents liked representing states and transitions in a state diagram; they found the diagram simple and easy to understand. Interaction diagrams evoked strong reactions, both positive and negative. While some found them to be a great way to start understanding the Ease of Use for UML Diagram Significant Independent Variables N = 39 Use Case Class None Object-Oriented Experience** State None Interaction Object-Oriented Experience** Overall Process-Oriented Experience** Notes: ** significant at p <.05 Table 4.The effects of experience on usability perceptions. COMMUNICATIONS OF THE ACM September 2003/Vol. 46, No. 9ve 253

7 UML Diagram Most Likable Parts of Diagram Most Frustrating Parts of Diagram Use Case use cases ease of understanding actors deciding on the level of detail for a use case extends & uses relationships understanding what a use case consists of Class relationships and inheritance hierarchies attributes & operations classes relationships & multiplicities defining operations interface objects State states & state transitions simplicity & ease of understanding identifying states Interaction sequence of events understanding of logic & connection to programming identification of classes & changes to class diagram collaboration diagrams synchronous & asynchronous messages Table 5. User reactions to UML diagrams. logic of the system and the first connection to real programming, others found them (especially collaboration diagrams) difficult to create and understand. Finally, when asked what diagram they liked the best and why, one subject observed: Use case easy to use and makes logical sense. Never approached a problem in such a manner! What Have We Learned about the Usability of UML? The results of this study suggest that novice developers usually have positive perceptions of the usability of UML. However, the means of ease-of-use scores indicate that subjects did not rate any of the UML diagrams as very high in terms of usability. The highest score, received by state diagrams, was only 5.30 out of a possible 7, implying that there is scope for improvement. In particular, future studies on usability should investigate why developers did not perceive UML class diagrams and interaction diagrams to be that usable, and explore what changes, if any, are necessary for improving that perception. Citing the number of diagrams as a major problem for UML, Dori [7], for example, advocates integration of structure and behavior is a single model, thereby making it simpler and more user friendly. The second (upcoming) version of UML [10], could address some of the usability issues. Future studies could 254 September 2003/Vol. 46, No. 9ve COMMUNICATIONS OF THE ACM

8 also explore the effects of different training methods on usability perceptions. Further, as Ambler [3] notes, the OO modeling approach adopted, that is, use case-driven modeling or class-driven modeling, may influence the usability of a particular type of diagram. Prior research exploring the effectiveness of the OO approach has found that developers experience problems in modeling the behavior-related aspects of an application (see, for example, [1]). In UML, sequence (interaction) diagrams capture a system s behavioral aspects in terms of messages, sequencing of messages, and invocation of operations by messages. In turn, those diagrams can help tackle the difficult problem of allocating behavior among object classes in a UML class diagram [12]. Given the interdependence of class and interaction diagrams in UML, it is critical that both researchers and practitioners address this issue and find ways to enhance the usability of those diagrams. Any major systems development effort involves several stakeholders in addition to systems professionals. UML diagrams promote communication among those stakeholders by providing a standard, method-independent notation [8]. For instance, systems developers can use UML diagrams to verify the requirements specified by end users, or to discuss a design with domain experts. Future studies should be directed at examining the effectiveness of UML diagrams in enhancing communication among various types of personnel involved during systems development. Perhaps the most promising finding of this study is that developers with prior experience in process-oriented modeling perceived UML diagrams as easy to use, overall. Prior studies have demonstrated the detrimental effects of such experience on OO modeling in general (for example, [2]). One of the reasons why the results of this study indicate otherwise may be the incorporation of use cases into UML. As Rosenberg [12] notes, it s good practice to drive the design of the static model (class diagrams) from the dynamic models, starting from use cases at the high level... By coalescing related transactions into identifiable chunks, use case diagrams focus on the dynamic behavior of a system at a macro level, which may explain why experience in process-oriented techniques resulted in a positive perception of the overall usability of UML diagrams. References 1. Agarwal, R., Sinha, A.P., and Tanniru, M. Cognitive fit in requirements modeling: A study of object and process methodologies. J. MIS 13, 2 (1996), Agarwal, R., Sinha, A.P., and Tanniru, M. The role of prior experience and task characteristics in object-oriented modeling: An empirical study. Internat. J. of Human Computer Studies 45 (1996), Ambler, S.W. How the UML models fit together. Software Development (Mar. 1998), SR4 SR Booch, G. UML in Action. Commun. ACM 42, 10 (Oct. 1999), Booch, G., Rumbaugh, J., and Jacobson, I. The Unified Modeling Language User Guide. Addison-Wesley, Reading, MA, Davis, F.D. Perceived usefulness, Perceived Ease of Use, and User Acceptance of Information Technology. MIS Q 13, 3 (Sept. 1989), COMMUNICATIONS OF THE ACM September 2003/Vol. 46, No. 9ve 255

9 7. Dori, D. Why significant UML change is unlikely. Commun. ACM 45, 11 (Nov. 2002), Fowler, M. Why use the UML? Software Development (Mar. 1998), SR19 SR Jacobson, I. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison- Wesley, Reading, MA, Miller, J. What UML should be. Commun. ACM 45, 11 (Nov. 2002), Nielsen, J. and Mack, R. L. Usability Inspection Methods. Wiley, New York, Rosenberg, D. UML applied: Nine tips to incorporating UML into your project. Software Development (Mar. 1998), SR13 SR September 2003/Vol. 46, No. 9ve COMMUNICATIONS OF THE ACM