Improving Sequence Diagram Modeling Performance: A Technique Based on Chunking, Ordering, and Patterning

Improving Sequence Diagram Modeling Performance: A Technique Based on Chunking, Ordering, and Patterning

Thant Syn (School of Business Administration, University of Miami, Coral Gables, FL, USA) and Dinesh Batra (College of Business Administration, Florida International University, Miami, FL, USA)
Copyright: © 2013 |Pages: 25
DOI: 10.4018/JDM.2013100101
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

The Unified Modeling Language (UML) has become the de facto standard for object-oriented software development. It has been widely adopted in both training and practice. However, UML has often been criticized for being overly complex and difficult to learn for novice analysts. Although some research studies have identified specific novice difficulties in learning UML, there is little research proposing viable techniques for addressing these difficulties. In particular, there is a lack of research evaluating the usability of the sequence diagram (SD), which models the interactions among objects of a software application. This paper reports a research study that proposes a technique called “CHOP” (CHunking, Ordering, Patterning), which is designed to improve novice analyst performance in modeling an SD. The CHOP technique is based on the Cognitive Load Theory (CLT) and was developed by addressing the three types of cognitive load encountered by novices. An experimental study testing the efficacy of the CHOP technique in comparison to the worked-example approach indicated that the CHOP technique significantly improves novice analyst’s ability to model interactions among objects; however, the worked-example technique was the more efficient during training. The study also found that subjects using the CHOP technique rated its perceived usefulness significantly higher than subjects using the worked-example approach.
Article Preview

Introduction

Contemporary practices in systems development indicate a shift from traditional software development to object-oriented (OO) development (Armstrong & Hardgrave, 2007). It is widely acknowledged that the Unified Modeling Language (UML) has become the de facto standard for modeling OO software systems in traditional development (Kobryn, 1999; Pender, 2003) as well as agile development (Erickson, Lyytinen, & Siau, 2005). UML is primarily used in specifying, visualizing, constructing, and documenting the artifacts of software systems (Booch, 2000).

While UML increases in popularity, concerns about its usability and complexity have been raised (Erickson, 2008; Siau, 2000; Siau, Long, & Ling, 2010). Bolloju and Leung (2006) conducted an experiment to understand the usability of UML diagrams and found multiple errors in solutions developed by novice analysts. They attributed these errors to novice analysts’ inexperience in problem-solving techniques such as decomposition; indeed, Burton-Jones and Meso (2006) found that analysis diagrams that manifest better decompositions increase analysts’ understanding of a domain. Siau and Loo (2006) reported that UML is difficult to learn for novice analysts and recommended that training should focus on core UML diagrams. However, with some exceptions, modeling techniques that may ease the difficulties of learning UML have, in general, yet to be proposed and evaluated.

Sien (2011) found severe difficulties in modeling sequence diagram (SD) and class diagram. Based on an experimental study, the author concluded: “Essentially, students do not know how to produce appropriate UML class and sequence diagrams.” In the Sien (2011) study, 67% of the subjects had significant errors and misunderstandings. About 70% of the subjects perceived producing sequence diagrams as difficult or very difficult. Most subjects had difficulty relating sequence diagrams with class diagrams.

Surveys have found that the class, the use case, and the sequence diagrams/models are the three UML constructs most commonly used by software developers (Dobing & Parsons, 2006). Given that a software system eventually implements classes, the class diagram is considered the most important UML diagram (Larman, 2005). The use case diagram depicts system behavior from an overview level, while the corresponding written use case details user requirements. The SD (or the collaboration/communication diagram) can be employed to translate use case activities into object interactions, which can then be used to develop class diagrams (Ambler, 2004; George, Batra, Valacich, & Hoffer, 2007; Selonen, Koskimies, & Sakkinen, 2003). Larman (2005) notes that novice UML modelers don’t pay enough attention to interaction diagrams (such as SD) even though they are incredibly valuable.

In most OO methodologies, the use case serves as the starting point for the analysis and design that lead to the class diagram. There are two major aspects of a class: attributes and operations. The attributes of the class approximately correspond to attributes of the data model, much like in an entity-relationship (ER) model. A large number of classes are entity classes because the backend of most transaction-based information systems has been traditionally built on relational databases (Siau, Nah, & Cao, 2011). For modeling entity classes, one can extrapolate knowledge gained from research in data modeling (Topi & Ramesh, 2002) to help novice analysts. The operations aspect, however, usually requires the use of SD (Quatrani & Palistrant, 2006; VanderMeer & Dutta, 2009), but there are currently no systematic guidelines for SD modeling.

Complete Article List

Search this Journal:
Reset
Open Access Articles
Volume 28: 4 Issues (2017)
Volume 27: 4 Issues (2016)
Volume 26: 4 Issues (2015)
Volume 25: 4 Issues (2014)
Volume 24: 4 Issues (2013)
Volume 23: 4 Issues (2012)
Volume 22: 4 Issues (2011)
Volume 21: 4 Issues (2010)
Volume 20: 4 Issues (2009)
Volume 19: 4 Issues (2008)
Volume 18: 4 Issues (2007)
Volume 17: 4 Issues (2006)
Volume 16: 4 Issues (2005)
Volume 15: 4 Issues (2004)
Volume 14: 4 Issues (2003)
Volume 13: 4 Issues (2002)
Volume 12: 4 Issues (2001)
Volume 11: 4 Issues (2000)
Volume 10: 4 Issues (1999)
Volume 9: 4 Issues (1998)
Volume 8: 4 Issues (1997)
Volume 7: 4 Issues (1996)
Volume 6: 4 Issues (1995)
Volume 5: 4 Issues (1994)
Volume 4: 4 Issues (1993)
Volume 3: 4 Issues (1992)
Volume 2: 4 Issues (1991)
Volume 1: 2 Issues (1990)
View Complete Journal Contents Listing