Article Preview
TopIntroduction
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.