Unified Modeling Language (UML) Topics:

Cognitive Issues in UML ResearchDinesh Batra, Florida International University, USA

GuEst Editorial PrEfacE

i

This is the second of the two special issues on the Unified Modeling Lan-guage (UML); the first appeared in the January-March 2008 issue of the Journal of Database Management (Ba-tra, 2008), and included four papers on the topic. The first issue covered UML application topics: the use of UML in practice (Dobing & Parsons, 2008), the organizational inadequacies of UML (Smolander & Rossi, 2008), the need to maintain seamless traceability of business rules in UML (Loucopoulos & Kadir, 2008), and assessment of the effectiveness of domain models as aids to application models developed us-ing UML (Reinhartz-Berger & Sturm, 2008). In the current issue, the three papers address cognitive and ontologi-cal concerns related to UML.

Assuming the novice perspective, VanderMeer and Dutta (2009) assert that UML is complex and difficult to

learn. They evaluate the UML sequence diagram, which may be viewed as a bridge between a use case and its class diagram. By employing the cognitive complexity theory, they explore the difficulty in learning the sequence dia-gram. They then employ the principles of learner-centered design to develop recommendations for the student ana-lyst engaged in learning and developing the sequence diagram.

Gemino and Parker (2009) inves-tigate the usability of use cases and use case diagrams. Using the Cogni-tive Theory of Multimedia Learning (Mayer, 2001), they examine whether use case diagrams improve effective-ness of novice users working with use cases, which are text-based. They evaluate effectiveness by measuring comprehension, retention, and prob-lem-solving performance. The results indicate that participants viewing the

use cases with the supporting diagram perform significantly better in reten-tion and on problem-solving tasks. The study implies that use cases need to be complemented by use case diagrams to improve participant understanding.

Evermann and Wand (2009) employ an ontological perspective to examine behavioral aspects of conceptual model-ing, focusing on constructs that describe change and interaction. They argue that conceptual models based on a strong ontological foundation should be used instead of software models to represent an application domain. While languages for software design, such as UML, are available and widely used, no generally accepted language exists for concep-tual modeling. The authors provide rules for mapping ontologically-based conceptual models to software models. This approach can lead to ontologically-grounded software models represented in a popular language such as UML.

The seven papers in the two special issues cover a variety of UML topics. Some of the papers tend to suggest that UML suffers from a litany of shortcom-ings. Nevertheless, UML continues to enjoy significant adoption (Selic, Ramackers, & Kobryn, 2002), which in-dicates that the practitioners find UML useful and reasonably easy to use. The editorial preface in the previous issue discussed the possibilities for future UML research in general; this preface will attempt to reconcile some of the apparent contradictions between its usability problems and adoption while suggesting additional cognitive topics for future research.

Object-oriented technology has often been promoted as a silver bullet, capable of solving many of the long-standing ills facing the software indus-try (Grossman, Aronson, & McCarthy, 2004). While it is true that UML has achieved tremendous popularity and is rapidly becoming the standard for object-oriented systems development, there are many who feel that it is too difficult to use and is not fulfilling its promise. Commonly heard complaints about UML are that it is too big and too complex (Siau & Cao, 2001); semanti-cally imprecise (Evermann & Wand, 2006); difficult to learn (Siau & Loo, 2006); and has poorly-defined syntax, semantics, and spatial layout, and lim-ited customizability (Tilley & Huang, 2003). Additionally, some feels that it offers inadequate support for compo-nent-based development, and does not allow for the easy interchange among model diagrams (Kobryn, 2002).

Recent surveys however, indicate that some of these problems are not considered particularly serious by prac-titioners. For example, the complexity of UML is frequently cited as an im-pediment to its ease of use. Grossman et al’s (2004) questionnaire-based survey findings indicate that the respondents find UML to be fairly understandable. Further, the respondents rate UML as flexible and accurate. Agarwal and Sinha (2003) used ease-of-use mea-sures derived from Davis (1989) and found that subjects perceive use case, class, and state diagrams as reasonably easy to use. In the Dobing and Parsons (2008) survey, respondents did not find

ii

serious problems with UML usage although there was a strong concern about the lack of UML support for user interfaces, and some concern about the lack of support for security and database design. Lang and Fitzgerald (2006) note high adoption rates for some UML constructs such as use case diagrams/scenarios (72%), class diagrams (62%), and state diagrams (50%). Similar adoption results are reported by Dobing and Parsons (2006), although Grossman et al. (2004) report a somewhat lower (27.5%) overall adoption rate for UML.

For now, UML appears to be here to stay. However, the apparent contra-dictions between its usability problems and adoption do raise some issues. Is UML merely having its “15 minutes of fame” and we can expect it to fade away with time, or will it go on to dominate the software modeling arena? Is UML a complex language laden with rarely used constructs, or is it a flexible language with rich features that can easily be adapted to various contexts? Is UML complexity an artifact of the usability research focus on the novice designer? Is the widespread adoption of UML among practitioners an arti-fact of the need for standardization in practice? How will UML fare in the increasingly popular agile develop-ment environment? Future research can separate the myths from the facts, and provide answers to what may appear to be contradictory findings.

An obvious shortcoming of UML is its lack of grounding in systems theory (Kast & Rosenzweig, 1972).

The unit for analysis in UML is the use case, but it does not lend itself easily to decomposition. If we assume that the use case represents an aspect of an information system and provides some functionality, we should be able to decompose it into smaller use cases. There is no reason a use case should not be considered a sub-system; after all, it has parts that interact with each other as in any system or sub-system. In fact, use cases have been considered at very levels of abstractions.

Cockburn (2000) lists five levels of abstractions from highly summary to highly detailed for use cases: cloud, kite, sea level, fish, and clam, but he does not discuss how UML can provide transitions from one level to another. Perhaps, it is not the responsibility of the language itself to facilitate the transition. If so, we need a modeling approach that can provide the mapping from one abstraction level to another. Surprisingly, this fundamental systems issue has not attracted much attention, and we continue to see textbooks and practitioner literature in which the customary method is to show an in-formation system as a small number of interacting use cases in a use case diagram with a single-level description of each use case.

In contrast, the process-based structured systems analysis (Gane & Sarson, 1977), along with its data flow diagram, has a solid grounding in sys-tems theory. Functional decomposition is common in the structured approach, and one can discuss a system at any level of abstraction. Although the data

iii

flow diagram is not appropriate for object-oriented development and it is unlikely to supplant UML, it does pro-vide a lesson in systems decomposition, and in combining data, processes, and actors. After all, it is a basic premise of object-oriented development that data and processes be presented in an integrated fashion (George, Batra, Valacich, & Hoffer, 2007).

Some studies have concluded that it is difficult to model a correct and consistent application using UML, and to understand such a specification (Peleg & Dori, 2000). Dori (2002) claims that UML requires several models to completely specify a system, and is, therefore, low in usability. Dori (2001) has proposed the Object-Process Methodology (OPM) to provide a sim-pler methodology that offers a single, integrated graphic model. It achieves model integration by incorporating the three major system aspects—function, structure, and behavior—into a single model in which both data and processes are adequately represented without either one suppressing the other.

There is implicit support for the tenets of the OPM approach in the study by Masri, Gemino, and Parker (2008), which was conducted to evaluate the effectiveness of combining elements of UML diagrams when presenting information. They employed the notion of intrinsic, extraneous, and germane cognitive load to suggest ways to reduce the overall cognitive load by combin-ing appropriate pieces of diagrams. By adding the element of interaction with the combining of diagrams, they found

that subject performance increased significantly. One may thus infer that implicitly, there is a case for data flow diagram (DFD), which also combines function, structure, and behavior. Should we then compare, say, UML and DFD, to assess which one is better? It is possible that such a study would reveal some interesting findings. However, the DFD, by itself, is not amenable to object-oriented development, so the practical value of such a comparative study is questionable. Almost all new in-formation systems are developed based on the object-oriented approach.

Interestingly, there is a methodol-ogy that employs DFDs to come up with class diagrams. In an attempt to tie the structural and behavioral diagrams together, Shoval and Kabeli (2001) have proposed a methodology called Functional and Object-Oriented Analysis and Design Methodology (FOOM), which tries to blend the DFD, the entity relationship diagram (ERD), and object-oriented (OO) constructs. A laboratory experiment that compares FOOM, OPM, and Masri et al.’s (2008) combination diagram approach can likely provide findings that can improve the design and effectiveness of UML. Since there are subtle differences in the constructs underlying the three ap-proaches, such a study will invariably encounter the usual internal validity issues, especially with regard to the equivalence of the treatments (Gemino & Wand, 2001). Nevertheless, as long as some threshold level of equivalence is attained, we should obtain useful results that could potentially resolve the criti-

iv

cism that UML is weak in presenting a combined view of data and processes.

One may argue that the UML se-quence diagram already blends func-tion, structure, and behavior. After all, a sequence diagram is the principal behavior model for representing system functionality given that it is based on a use case. Also, it can only be developed accurately if the structure of entity ob-jects is known, perhaps from an entity-relationship (ER), or a domain model. At present, this argument is weak, however, because the entity objects are shown simply in a linear fashion without revealing the underlying relationships. Yet, the sequence diagram can be im-provised, perhaps by depicting a domain (data) model along side. Additionally, the sequence diagram can be further improved by an interface model, and a logic model (e.g., a decision table or a decision tree) placed alongside the sequence diagram or available on demand using a software tool.

Another concern regarding UML is its expansion of an already inflated specification: the number of diagrams in UML 2.0 has been augmented to 13, from the nine found in UML 1.0. Most of the diagrams added in UML 2.0 de-pict higher level views of the system under development, for the purpose of enhancing component-based develop-ment (Kobryn, 2002). The ideas behind the original UML diagrams have not changed much and are expected to remain the same for the foreseeable future (Dori, 2002; Miller, 2002; Selic et al., 2002). However, the number of diagrams is clearly large and will con-tinue to raise usability concerns.

Yet, UML has seen remarkable adoption. The two findings—UML’s complexity and its popularity—reveal a contradiction that needs to be resolved. One possibility is that the practical complexity of UML is limited (Siau, Erickson, & Lee, 2005), and that UML is, after all, a flexible language; analysts and designers can limit their cognitive complexity by adopting only what it is the most useful to them. This hypothesis may well explain the seemingly contra-dictory points of view regarding UML, but this claim needs to be strengthened by empirical validation.

This leads us to the next research question: do we really know how UML is used in practice? Questionnaire-based studies have provided some clues. For example, we know that the use case (and the use case diagram), the class dia-gram, and the sequence diagram are the most often used UML construct (e.g., Dobing & Parsons, 2006). Multiple case-studies, protocol-based studies, and action research may reveal how these constructs are used. Naturally, many research questions arise: are the UML constructs used formally with the support of case tools? Is the sequence diagram used to bridge the use case with the class diagram, or is it used to clarify the coding logic to the developer? Is UML primarily a way of communicat-ing (i.e., informal), or a means to design software (i.e., formal), or both? Does it provide cognitive support to develop-ers? Does it aid comprehension? Does it reduce cognitive load? Do program-mers perform better at writing code when aided by UML documentation? Do programmers perform better at

v

software maintenance when aided by UML documentation?

A few recent studies provide pre-liminary answers to such questions (Costain, 2008; Costain & Srinivasan, 2008; Lange, Chaudron, & Muskens, 2006). Costain (2008) found that UML documentation does support program-mers in writing code, in creating internal representations of the problems, in aid-ing comprehension, and in offloading notations from working memory to an external representation. Still, program-ming performance is largely dependent on experience. Industry-experienced developers use UML documentation more than novices do. Designers cus-tomize UML notations when offloading diagrams, say, on to paper. Overall, there is some evidence that UML does provide cognitive support.

Lange et al (2006) conducted a study on actual UML usage and found several significant problems suggest-ing that UML could be used somewhat loosely. For instance, they frequently found methods in class diagrams that are not called in sequence diagrams. Methods that are not called might not be used in interactions; alternatively, they might not be sufficiently described in terms of their interactive functionality. Conversely, they found messages in se-quence diagrams that do not correspond to any methods in class diagrams. Each message that an object in a sequence diagram receives must correspond to a method in the object’s class interface; otherwise the meaning of the message is unclear. The researchers also found classes without methods, which violates

the object-oriented paradigm, particu-larly the concept of encapsulation. A class without methods cannot interact with other classes and is, therefore, incomplete.

Lange et al (2006) also conducted a controlled experiment with 110 stu-dents and 48 practitioners to evaluate the usage of UML. The results showed that defects often remain undetected, even if the model is read thoroughly. For example, 61 percent of readers did not detect a sequence diagram message that lacked a corresponding method in the class diagram. Although several studies have suggested that UML has been widely adopted, the Lange et al (2006) study suggests that the nature of adoption may be in a perfunctory, loose fashion.

With the growing popularity of agile development with its informal practices and the need to simplify modeling, one wonders if UML will be used in the most formal manner (Ambler, 2004). Since the focus of agile development is on working software, it is likely that the syntactic inconsistencies will be ignored and semantic ambiguity will be tolerated. A “light” version of UML may address the complexity of UML. In a questionnaire-based survey of 180 students, Wrycza and Marcinkowski (2007) found that more than 90 percent of the respondents prefer a light ver-sion of UML 2.0. Four diagrams were selected as the components of a light version: use case, class, activity, and sequence diagrams.

It seems that for most tasks, a “light” or limited version of UML will

vi

be employed to manage the practi-cal complexity of UML (Dobing & Parsons, 2006; Siau et al., 2005). The use case, class, activity, and sequence diagrams may continue to be found the most useful as new additions to UML are proposed for specific applications. Developers will pick and choose and improvise based on their context, meth-odology, and culture.

How will we use UML or a similar language in future? Systems analysis methods have always been evolv-ing and this trend can be expected to continue. In the beginning, there were text descriptions. Diagrams quickly followed. These diagrams were soon managed using CASE tools. However, the CASE tools presented models as if they were on paper. For some reason, we have never seriously crossed the “paper-like” threshold of using the com-puter interface for presenting analysis information. So what awaits us if we do? We need to consider presentation options such as animation, narra-tion, dynamic highlighting, diagram combination, video, and many others. These presentation options are already available, but we have provided little guidance on how to use these interface elements effectively. Eventually, the goal is to conduct research that takes our well specified modeling techniques and presents the information contained within them in a way that is easily, clearly, and accurately understood.

In this research arena, academics have the opportunity to take the lead over the practitioners because of the need to understand both analysis and

design methods, and cognitive theory. For example, cognitive complexity, among other sources, may provide a theoretical basis to study the usability of UML. The theories of cognitive com-plexity have been applied to software engineering processes from coding or programming (Cant, Jeffery, & Hender-son-Sellers, 1995) to OO system design (Rosson & Alpert, 1990), and recently to UML (Sin & Batra, 2007). Cognitive complexity principles are also applied to other areas of research such as the design of user interfaces for informa-tion-intensive products (Reeves, 1999) and computer-based learning systems (Norman & Spohrer, 1996; Soloway & Pryor, 1996).

This special issue is the second of two and provides the concluding set of papers on UML topics that resulted from a call for papers made in late 2006. A large number of high-quality manuscripts were received and each submitted manuscript was sent out to three reviewers. Each of the accepted papers in the special issues went through one round of comprehensive revision based on reviewer comments. I thank the reviewers, most of whom are mem-bers of the AIS Special Interest Group on Systems Analysis and Design (SIG-SAND), for their meticulous reading of the papers, and for their substantive comments, which improved the quality of the papers. I thank Andrew Gemino for his feedback on some of the ideas presented in this preface. I am grateful to the editor-in-chief, Keng Siau, who counseled me on various matters. I am confident that the readers of the journal

vii

will find the papers of high quality, and I hope the ideas and issues discussed herein will lead to future research in this area of considerable contemporary interest.

REFERENCESAmbler, S. W. (2004). The object primer: Agile model-driven development UML 2.0 (3rd ed.). Cambridge, UK: Cambridge University Press.

Agarwal, R. & Sinha, A. P. (2003). Object-oriented modeling with UML: A study of developers’ perceptions. Communications of the ACM, 46(9), 248-256.

Batra, D. (2008). Unified Modeling Language (UML) topics: The past, the problems, and the prospects. Journal of Database Management, 19(1), i-vii.

Cant, S. N., Jeffery, D. R., & Henderson-Sellers, B. (1995). A conceptual model of cognitive complexity of elements of the programming process. Information and Software Technology, 37(7), 351.

Cockburn, A. (2000). Writing effective use cases. Boston, MA: Addison-Wesley Longman.

Costain, G.F. (2008). Cognitive support during object-oriented software develop-ment: The case of UML diagrams. Unpub-lished doctoral dissertation, The University of Auckland, 2008.

Costain, G.F. & Srinivasan, A. (2008) A modeling methodology for empiri-cally studying user behavior: The case of UML diagram usage. EMMSAD 2008, Montpellier, France, June 16-17. Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance

of information technology. MIS Quarterly, 13(3), 319-340.

Dobing, B., & Parsons, J. (2006). How UML is used. Communications of the ACM, 49(5), 109-113.

Dobing, B. & Parsons, J. (2008). Dimen-sions of UML diagram use: A survey of practitioners. Journal of Database Man-agement, 19(1), 1-18.

Dori, D. (2001). Object-process methodol-ogy applied to modeling credit card transac-tions. Journal of Database Management, 12(1), 4-14.

Dori, D. (2002). Why significant UML change is unlikely. Communications of the ACM, 45(11), 82-85.

Evermann, J. & Wand Y. (2006). Ontologi-cal modeling rules for UML: An empirical assessment. Journal of Computer Informa-tion Systems, 47(1), 14-29

Evermann, J. & Wand Y. (2009). Ontology based object-oriented domain modeling: Representing behavior. Journal of Data-base Management, 20(1), 48-77.

Gane, C., & Sarson, T. (1977). Structured systems analysis: Tools and techniques. Mcdonnell Douglas Information.

George, J. F., Batra, D., Valacich, J. S., & Hoffer, J. A. (2007). Object-oriented sys-tems analysis and design (2nd ed.). Upper Saddle River, NJ: Prentice Hall.

Gemino, A. & Wand, Y. (2001). Towards common dimensions in empirical compari-sons of conceptual modeling techniques. In K. Siau, T. Halpin, & J. Krogstie (Ed.), Seventh CAiSE/IFIP-WG8.1 International Workshop on the Evaluation of Modeling Methods in Systems Analysis and Design. Toronto, Canada.

viii

Gemino, A., & Parker, D. (2009). Use case diagrams in support of use case modeling: Deriving understanding from the picture. Journal of Database Management, 20(1), 1-24.

Grossman, M., Aronson, J.E., & McCarthy, R.V. Does UML make the grade? Insights from the software development community. Information and Software Technology, 47, 383-397.

Kast, F. E., & Rosenzweig, J. E. (1972). General systems theory: Applications for organization and management. The Academy of Management Journal, 15(4), 447-465.

Kobryn, C. (2002). Will UML 2.0 be agile or awkward? Communications of the ACM, 45(1), 107–110.

Lang, M., & Fitzgerald, B. (2006). New branches, old roots: A study of methods and techniques in Web/hypermedia systems design. Information Systems Management, 23(3), 62-74.

Lange, C.F.J., Chaudron, M.R.V., & Mus-kens, J. (2006). UML software architecture and design description. IEEE Software, 40-46.

Loucopoulos, P. & Kadir, W. (2008). BROOD: Business rules-driven object oriented design. Journal of Database Management, 19(1), 41-73.

Masri, K., Gemino, A., & Parker, D. (2008). Facilitating understanding of UML diagrams by interaction and combination. Symposium on Systems Analysis and De-sign, May 23-24, Provo, Utah.

Mayer, R. (2001). Multimedia learning. New York: Cambridge University Press.

Miller, J. (2002). What UML should be. Communications of the ACM, 45(11), 67-69.

Norman, D. A., & Spohrer, J. C. (1996). Learner-centered education. Communica-tions of the ACM, 39(4), 24-27.

Peleg, M. & Dori, D. (2000). The model multiplicity problem: Experimenting with real-time specification methods. IEEE Transactions of Software Engineering, 26(8), 742-759.

Reeves, W. W. (1999). Learner-centered design: A cognitive view of managing complexity in product, information, and environmental design. Thousand Oaks, CA: Sage Publications.

Reinhartz-Berger, I. & Sturm, A. (2008). Enhancing UML models: A domain analysis approach. Journal of Database Management, 19(1), 74-94.

Rosson, M. B. & Alpert, S. R. (1990). The cognitive consequences of object-oriented design. Human-Computer Interaction, 5(4), 345-379.

Selic, B., Ramackers, G., and Kobryn, C. (2002). Evolution, not revolution. Com-munications of the ACM, 45(11), 70-72.

Shoval, P. & Kabeli, J. (2001). FOOM: Functional- and object-oriented analysis & design of information systems: An inte-grated methodology. Journal of Database Management, 12(1), 15-25.

Siau, K. & Cao, Q. (2001). Unified Mod-eling Language (UML) - A complexity analysis. Journal of Database Manage-ment, 12(1), 26-34.

Siau, K., Erickson, J., & Lee, L. Y. (2005). Theoretical vs. Practical complexity: The case of UML. Journal of Database Man-agement, 16(3), 40-57.

Siau, K. & Loo, P.-P. (2006). Identifying difficulties in learning UML. Information Systems Management, 32(3), 43-51.

ix

Sin, T. & Batra, D. (2007). Improving usability of analysis sequence diagram in transaction-oriented applications. Sym-posium on Systems Analysis and Design, May 12-13, Tulsa, Oklahoma.

Smolander, K. & Rossi, M. (2008). Con-flicts, compromises, and political decisions - Methodological challenges of enterprise-wide E-Business architecture creation. Journal of Database Management, 19(1), 19-40.

Soloway, E. & Pryor, A. (1996). The next generation in human-computer interac-tion. Communications of the ACM, 39(4), 16-18.

Tilley, S. & Huang, S. (2003). A qualita-tive assessment of the efficacy of UML diagrams as a form of graphical documen-tation in aiding program understanding. Paper presented at the Twenty-First Annual International Conference on Documenta-tion, San Francisco, CA.

VanderMeer, D. & Dutta, K. (2009). Ap-plying learner-centered design principles to UML sequence diagrams. Journal of Database Management, 20(1), 25-47.

Wrycza, S. & Marcinkowski, B. (2007). Towards a light version of UML 2.X: Ap-praisal and Model. Organizacija, 40(4), 171-179.

Dinesh Batra is a Knight-Ridder research professor at the Department of Decision Sci-ences and Information Systems in the College of Business Administration at the Florida International University. Dr. Batra has published articles in journals such as Manage-ment Science, Communication of the ACM, Journal of MIS, International Journal of Human Computer Studies, Data Base, European Journal of Information Systems, Jour-nal of Database Management, Communications of the AIS, Decision Support Systems, Requirements Engineering, Computers and OR, Information Systems Management, and Information & Management. His research interests focus on systems analysis and design methods, usability issues in systems and databases, and distributed development. He is currently an associate editor in the Journal of Database Management, Communica-tions of the AIS, and Information Systems Management. He is a co-author of the book Object-Oriented Systems Analysis and Design. He has served as a president of the AIS Special Interest Group on Systems Analysis & Design (SIGSAND).

x