cercetare stiintifica uml

Upload: vieru-cristina

Post on 03-Apr-2018

239 views

Category:

Documents


0 download

TRANSCRIPT

  • 7/28/2019 Cercetare Stiintifica UML

    1/15

    Does UML make the grade? Insights from the softwaredevelopment community

    Martin Grossmana,*, Jay E. Aronsonb,1, Richard V. McCarthyc,2

    aDepartment of Management, Bridgewater State College, Bridgewater, MA 02325, USA

    bDepartment of Management Information Systems, Terry College of Business, University of Georgia, Athens, GA 30602, USA

    cLender School of Business, Quinnipiac University, Hamden, CT 06518, USA

    Received 25 January 2004

    Available online 11 November 2004

    Abstract

    The Unified Modeling Language (UML) has become the de facto standard for systems development and has been promoted as a

    technology that will help solve some of the longstanding problems in the software industry. However, there is still little empirical evidence

    supporting the claim that UML is an effective approach to modeling software systems. Indeed, there is much anecdotal evidence suggesting

    the contrary, i.e. that UML is overly complex, inconsistent, incomplete and difficult to learn. This paper describes an investigation into the

    adoption and use of UML in the software development community. A web-based survey was conducted eliciting responses from users of

    UML worldwide. Results indicate a wide diversity of opinion regarding UML, reflecting the relative immaturity of the technology as well as

    the controversy over its effectiveness. This paper discusses the results of the survey and charts of the course for future research in UML usage.

    q 2004 Elsevier B.V. All rights reserved.

    Keywords: Unified Modeling Language; UML; Object-oriented analysis and design; OOAD; Task-technology fit

    1. Introduction

    Object-oriented (OO) technology has profoundly chan-

    ged the way software systems are designed and developed

    [44]. Proponents of OO technology are quick to claim the

    advantages over the traditional structured or process-

    oriented (PO) approaches, such as easier modeling,

    increased code reuse, higher system quality, and easier

    maintenance [17,26]. Indeed, object-oriented technology

    has often been promoted as a silver bullet, capable of

    solving many of the longstanding ills facing the software

    industry.

    The advent of the Unified Modeling Language (UML)

    has fueled the continued growth and acceptance of object-

    oriented technology. UML is a visual modeling language,

    composed of notations and textual components to express

    object-oriented system designs [16]. During the early 1990s,

    the object-oriented methods landscape was one of the

    contention and confusion. Prior to 1994, there were many

    competing visual modeling languages and methodologies

    on the market. All of these had their loyal followers as well

    as their detractors, and the selection of one technique over

    another was not an easy choice. The impetus behind UML

    was to fuse, or unify, the best practices from the strongest of

    these methods. Ultimately, three methods emerged as the

    primary contenders: the Booch Method [4], the Object

    Modeling Technique or OMT [33], and the ObjectoryMethod [25]. Elements from each of these methods make up

    the core of UML, and the primary authors, better known as

    the Three Amigos, are still working on the ever evolving

    UML specification, along with many other participants,

    under the tutelage of the Object Management Group

    (OMG).

    Although UML has achieved tremendous popularity

    and is rapidly becoming the standard for object-oriented

    systems development, there are many who feel that it is

    0950-5849/$ - see front matter q 2004 Elsevier B.V. All rights reserved.

    doi:10.1016/j.infsof.2004.09.005

    Information and Software Technology 47 (2005) 383397

    www.elsevier.com/locate/infsof

    * Corresponding author. Tel.:C1 508 531 2723.

    E-mail addresses: [email protected] (M. Grossman), jaronson

    @uga.edu (J.E. Aronson), [email protected] (R.

    V. McCarthy).1 Tel.:C1 706 542 0991.2 Tel.:C1 203 582 8468.

    http://www.elsevier.com/locate/infsofhttp://www.elsevier.com/locate/infsof
  • 7/28/2019 Cercetare Stiintifica UML

    2/15

    too difficult to use and that it is not fulfilling its promise.

    Commonly heard complaints about UML are that it is too

    big and complex, it is semantically imprecise, it is

    implemented in a non-standard manner, it has limited

    customizability, it has inadequate support for component-

    based development, and that it is unable to easily

    interchange model diagrams [28]. Much of the existingliterature relating to UML usage focuses on such short-

    comings [11,18,22,24,36,42]. However, there is still very

    little empirical evidence available describing the actual

    usage patterns or performance impacts of UML. There is a

    critical need for such empirical research to determine how

    UML is currently being used, how it is perceived by those

    individuals using it, and what individual, task and

    organizational factors are impacting its use.

    A number of research models have emerged that attempt

    to explain the acceptance and utilization of technology. One

    such framework is provided by task-technology fit (TTF)

    theory [19,20] which links performance with the fit between

    the task being performed and the particular type of

    technology being utilized. Researchers have used the TTF

    framework to investigate a wide assortment of information

    technologies, such as software maintenance tools [9],

    knowledge management systems [31], data warehousing

    [30], simulation modeling [10], the World Wide Web

    [7,38], e-commerce [43], manufacturing task support

    systems [40], group support systems [32,34,45] and

    enterprise resource planning [37].

    Assuming that we can learn to select technologies that

    are a better fit within the context of the organization, the

    research in this area has several important implications for

    managers planning enterprise wide strategy. The presentstudy was conducted to explore how the adoption and usage

    of UML can be explained using the TTF framework.

    2. Methodology

    2.1. Survey development

    A review of the literature surrounding UML usage led to

    the following questions:

    1. Do individuals who use UML perceive it to bebeneficial?

    2. Does UML provide a task-technology fit to individuals

    who utilize it?

    3. What are the characteristics that affect UML use?

    The survey research instrument was developed utilizing

    constructs that were originally developed by Goodhue and

    Thompson [19] and subsequently expanded by a number

    of other researchers [9,20,31]. The sample population

    for this survey consisted of information technology

    professionals with experience utilizing UML for systems

    development.

    The variables to be tested in this study are adapted from

    Goodhues task-technology fit instrument [19]. They

    include:

    1. Right data

    2. Accuracy

    3. Compatibility4. Flexibility

    5. Understandability

    6. Level of detail

    7. Training

    8. Ambiguity

    The survey questions were modified to reflect that the

    technology in question is UML and not information systems

    in general. The first part of the survey consists of UML

    usage questions mapped directly to the task-technology fit

    constructs as described by Goodhue [19] with some

    modifications to make it UML specific. These questions

    were presented in a random order to avoid clustering byvariable. Respondents were asked to indicate the answers to

    these questions using a Likert scale providing five possible

    levels of agreement (strongly disagree to strongly agree).

    The second part of the survey contained questions which

    asked for additional information, divided into four subsec-

    tions. The first subsection relates to individual character-

    istics such as gender, educational background, and

    experience level. The second subsection deals with project

    characteristics such as the type and complexity of

    application being developed. The third subsection focuses

    on organizational characteristics, such as corporate culture

    and industry sector. Subsection four contained questionsspecifically relating to UML and how it is being utilized in

    the specific environment of the respondent.

    2.2. Survey administration

    The sample population used in this study was derived by

    accessing various online newsgroups with threads relating

    to UML, object-oriented analysis and design tools and

    software development methodologies (e.g. The UML

    Forum, UML Cafe, Objects by Design Forum, UML

    Zone, The Precise UML Newsgroup, Rational Unified

    Process Forum, Sparx System Forum, Rose Forum, Object

    Technology User Group). The e-mail addresses of UML

    users were culled from the archives of these discussion

    groups as well as from other sources (e.g. UML related user

    groups, Web sites, conferences, and articles) and entered

    into a database of survey subjects. Targeting participants in

    this manner increased the chances that the population

    consisted only of those information technology pro-

    fessionals who have actually used UML on software

    development projects. Only those individuals believed to

    be serious users of UML, based on the context of the

    environment in which their name was encountered, were

    selected for the survey. There is a certain level of bias

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397384

  • 7/28/2019 Cercetare Stiintifica UML

    3/15

    inherent in survey research of this kind, since only interested

    parties can be solicited. Direct e-mails were sent to all of

    individuals in the database, asking them if they would

    volunteer to participate in a survey on UML usage and

    providing a link to the actual survey page.

    Of the 1507 e-mails initially sent, 133 did not reach their

    intended recipient, and bounced back. Of the remaining1374 emails, a total of 150 users responded to the survey

    (over 83% of whom responded within 72 h from the time the

    emails were initially sent). This represents a response rate of

    10.91%. Considering that no monetary incentives were

    offered to entice respondents to complete this survey, a

    practice typically used by commercial Internet researchers

    [12], this response rate was considered to be a reasonably

    good outcome. The response rate in this study can be

    attributed in part to the interest level of the targeted group of

    UML users solicited. Based on the percentage of subjects

    who provided additional comments on the survey (28.2%)

    and who indicated a willingness to participate in future

    studies (58.8%), one may conclude that the individuals who

    did respond to this survey were relatively opinionated

    regarding UML usage and eager to express their views.

    Nineteen surveys were eliminated from the sample due to

    incomplete responses, leaving the final sample size used in

    this study at 131.

    3. Results

    3.1. Instrument validity and reliability

    The present study consisted of 32 survey questions,

    mapped to eight variables. Variables were derived from the

    original task-technology fit study of Goodhue and Thomp-

    son [20], with some minor modifications to reflect UML

    usage. Cronbachs alphas were computed for each of the

    eight variables. Reliability coefficients for each of the

    variables are shown in Table 1.

    Three of the constructs (accuracy, compatibility and

    level of detail) exhibited Cronbachs alphas below the

    accepted value of 0.70 and were therefore eliminated from

    the study. To determine the validity of the remaining

    constructs, a Pearson product-moment correlation was

    performed. Strong positive correlations at the 0.01 level of

    significance were exhibited for flexibility, right data,

    understandability and training. The ambiguity variable

    however, exhibited a negative correlation at the 0.05 level

    (Table 2).

    3.2. Respondent characteristics

    To be included in this survey the respondent had to be

    directly involved with UML. Aside from that requirement,there were no other criteria for inclusion in the sample.

    One area of interest is the educational level of the

    respondents. Table 3 reveals that over 87% of the population

    had at least a Bachelors degree.

    Also relevant to the discussion of UML usage is that of

    experience in object-oriented technology. Experience level

    has been considered in a number of research studies on

    object-oriented analysis and design [1,14]. As revealed in

    Table 4, 57% of the respondents in the present study have

    over six years of experience using object-oriented

    technology while less than 5% have one year or less.

    This is significant because it indicates that our sample

    population is well qualified to assess the task-technology

    fit of UML.

    The likelihood of obtaining an international sample was

    greatly increased because the World Wide Web was used as

    the primary means of locating subjects. In this study, the

    sample population was representative of the global software

    development community, consisting of individuals from

    many different countries. This is reflective of the global

    following that UML has achieved and the fact that it is

    quickly becoming an international standard. Two survey

    questions asked for country data, one relating to country of

    origin of the developer and the other to the location of the

    organization in which UML is being used. Tables 5 and 6show the breakdown of countries in each of these categories.

    Table 1

    Cronbachs alpha reliability analysis

    Variable Number of items Reliability

    Right data 4 0.7732

    Accuracy 4 0.4446

    Compatibility 4 0.6003

    Flexibility 4 0.8175

    Understandability 4 0.7427

    Level of detail 4 0.6280

    Training 4 0.7517

    Ambiguity 4 0.7584

    Table 2

    Pearsons correlation coefficients for task variables

    Variable Correlation coefficient

    Flexibility 0.888**

    Right data 0.902**

    Understandability 0.664**

    Training 0.712**

    Ambiguity K0.174*

    **Correlation is significant at the 0.01 level (2-tailed). *Correlation is

    significant at the 0.05 level (2-tailed).

    Table 3

    Educational level

    Educational level Frequency Percent Cumulative

    percent

    No response 1 0.8 0.8

    Bachelors degree 57 43.5 44.3

    High school graduate 3 2.3 46.6

    Masters degree or above 57 43.5 90.1

    Some college 13 9.9 100.0

    Total 131 100.0

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397 385

  • 7/28/2019 Cercetare Stiintifica UML

    4/15

    Not surprisingly, the tables closely mirror one another.

    Most of the respondents are Americans working in

    organizations located in the United States. It is evident

    however, that UML has become a global phenomenon with

    activity in every corner of the world. The sample of UML

    users in this study originally came from 35 different

    countries while working at organizations in 32 countries.

    It is interesting to note the foreign nationalities in this

    sample with the most sizable representation of UML

    users (e.g. United Kingdom, Australia, and India) and

    the countries in which it is being used the most (e.g. United

    Kingdom, India, and Germany). This is not completely

    unexpected however, as the survey was only available in

    English. The data revealed that 57.2% of the respondents to

    this study were originally from English speaking countries,

    while 59.5% were working for organizations located in

    English speaking countries.

    Another demographic variable analyzed was current job

    title. In the present study, respondents were broken down

    into three primary groups: developers, analysts, andmanagers. As seen in Table 7, the majority of respondents

    Table 4

    Number of years experience with object-oriented technology

    Years

    experience

    Frequency Percent Cumulative

    percent

    01 6 4.6 4.6

    23 24 18.3 22.9

    45 26 19.8 42.7

    6C 75 57.3 100.0

    Total 131 100.0

    Table 5

    Country of origin

    Country Frequency Percent Cumulative

    percent

    USA 41 31.3 31.3

    United Kingdom 16 12.2 43.5

    India 8 6.1 49.6

    Australia 7 5.3 55.0

    Germany 6 4.6 59.5

    Belgium 4 3.1 62.6

    No response 3 2.3 64.9

    Austria 3 2.3 67.2

    Canada 3 2.3 69.5China 3 2.3 71.8

    The Netherlands 3 2.3 74.0

    Norway 3 2.3 76.3

    Sweden 3 2.3 78.6

    Estonia 2 1.5 80.2

    France 2 1.5 81.7

    Italy 2 1.5 83.2

    Nigeria 2 1.5 84.7

    South Africa 2 1.5 86.3

    Argentina 1 0.8 87.0

    Belarus 1 0.8 87.8

    Bulgaria 1 0.8 88.6

    Colombia 1 0.8 89.3

    Czech Republic 1 0.8 90.1

    Denmark 1 0.8 90.8Georgia 1 0.8 91.6

    Hungary 1 0.8 92.4

    Israel 1 0.8 93.1

    Jamaica 1 0.8 93.9

    Jordan 1 0.8 94.7

    Lithuania 1 0.8 95.4

    Pakistan 1 0.8 96.2

    Poland 1 0.8 96.9

    Saudi Arabia 1 0.8 97.7

    Sudan 1 0.8 98.5

    Taiwan 1 0.8 99.2

    Yugoslavia 1 0.8 100.0

    Total 131 100

    Table 6

    Location of organization

    Country Frequency Percent Cumulative

    percent

    USA 49 37.4 37.4

    United Kingdom 16 12.2 49.6

    India 7 5.3 55.0

    No response 6 4.6 59.5

    Germany 6 4.6 64.1

    Australia 4 3.1 67.2

    Belgium 4 3.1 70.2

    The Netherlands 3 2.3 72.5

    Sweden 3 2.3 74.8

    Austria 2 1.5 76.3

    Canada 2 1.5 77.9

    China 2 1.5 79.4

    Estonia 2 1.5 80.9

    Israel 2 1.5 82.4

    Italy 2 1.5 84.0

    Norway 2 1.5 85.5

    South Africa 2 1.5 87.0

    Sri Lanka 2 1.5 88.5Afghanistan 1 0.8 89.3

    Albania 1 0.8 90.1

    Argentina 1 0.8 90.8

    Bulgaria 1 0.8 91.6

    Czech Republic 1 0.8 92.4

    Denmark 1 0.8 93.1

    France 1 0.8 93.9

    Hungary 1 0.8 94.7

    Madagascar 1 0.8 95.4

    New Zealand 1 0.8 96.2

    Poland 1 0.8 96.9

    Saudi Arabia 1 0.8 97.7

    Taiwan 1 0.8 98.5

    Uruguay 1 0.8 99.2

    Yugoslavia 1 0.8 100.0Total 131 100.0

    Table 7

    Current job title

    Job title Frequency Percent Cumulative

    percent

    No response 3 2.3 2.3

    IT manager or supervisor 19 14.5 16.8

    Systems analyst 23 17.6 34.4

    Software developer 39 29.8 64.0

    Other 47 35.9 100.0

    Total 131 100.0

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397386

  • 7/28/2019 Cercetare Stiintifica UML

    5/15

    did not see themselves fitting into any of the categories

    offered, selecting the other category instead. Closer

    inspection of the actual entries written in by theserespondents revealed some other titles not captured in the

    original survey, such as consultant, student, researcher,

    engineer and architect. In general, it can be said that the

    sample population reflected a wide cross section of

    practitioners with direct hands-on experience using UML.

    The industry in which the respondent was working was

    also collected. Table 8 shows this breakdown, indicating

    that most respondents are working in the IT industry, but

    that the use of UML spans other industries as well.

    Responses within the other category exposed a number of

    other industry categories, not included in the survey, such as

    agriculture and transportation.

    3.3. Additional findings

    Aside from the demographic data described above, this

    study addressed the research question of whether or not

    individuals who use UML perceive it to be beneficial. A

    positive perception underlies task-technology fit [20] and

    can be analyzed further by examining all of the individual

    items originally included in the survey as well as aggregate

    TTF indices. In addition, other project and technology

    characteristics are examined.

    3.3.1. Raw survey results

    First, we look at the survey items themselves, broken

    down by variable type. Response frequencies for all

    questions are displayed in Tables 916.Inspection of these response frequencies reveal some

    interesting patterns in light of the negative descriptions of

    UML found in the literature [11,18,22,24,36,42]. For

    example, complexity of UML is frequently cited as an

    impediment to its usage. It does not appear however that

    most respondents feel this to be so, based on the responses in

    the survey items related to the understandability variable

    (Table 12). Similarly, the responses to those items in the

    accuracy and flexibility categories (Tables 9 and 11)

    reflect somewhat favorable perceptions on the part of most

    respondents. UML does not appear to be deemed overly

    inflexible or inaccurate to meet the needs of the majority of

    developers surveyed. Some survey items however did

    generate a greater percentage of negative responses from

    the sample. For example, items relating to both compat-

    compatibility and ambiguity generated a majority of

    negative responses for several questions (Tables 10 and 15).

    Nearly, 62% of those surveyed agreed with the statement

    that UML is insufficiently specified which allows for

    misinterpretation.

    3.3.2. TTF response indices

    Prior to performing statistical analysis, all responses

    were normalized to account for the wording of the survey

    questions. For example, some questions were posedpositively (e.g. UML provides sufficiently detailed dia-

    grammatic constructs), while others were cast in a negative

    format (e.g. I find UML to be too complex and difficult to

    understand). The normalization process was simply a matter

    of inverting the responses of negatively cast statements (e.g.

    strongly disagree changed to strongly agree). After normal-

    izing the data all numerical rankings were consistent, with 5

    indicating the highest level of approval of UML and 1

    indicating the lowest. Consistent with other TTF researchers

    [9,19,31,40], we were able to derive TTF indices for each

    Table 8

    Industry

    Industry Frequency Percent Cumulative

    percent

    Wholesale/retail 3 2.3 2.3

    Aerospace 3 2.3 4.6

    Insurance 5 3.8 8.4

    Government 5 3.8 12.2

    No response 6 4.6 16.8

    Healthcare 7 5.3 22.1

    Industrial/manufacturing 7 5.3 27.5

    Telecommunications 7 5.3 32.8

    Education 9 6.9 39.7

    Banking/financial services 10 7.6 47.3

    Other 18 13.7 61.1

    Information technology 51 38.9 100.0

    Total 131 100.0

    Table 9

    Right dataresponse frequencies

    Survey item Strongly

    disagree

    Somewhat

    disagree

    Neither

    agree nor

    disagree

    Somewhat

    agree

    Strongly

    agree

    The right data 1. UML is missing critical constructs that would be

    useful in performing analysis

    12 (9.2%) 30 (22.9%) 16 (12.2%) 52 (39.7%) 21 (16.0%)

    9. The diagrams and notational elements of UML are

    at an appropriate level of detail for my purposes

    4 (3.1%) 17 (13.0%) 16 (12.2%) 61 (46.6%) 33 (25.2%)

    17. It is more difficult to do my job effectively

    because some of the constructs I need are not

    available

    28 (21.4%) 41 (31.3%) 26 (19.8%) 22 (16.8%) 14 (10.7%)

    25. UML semantics do not adequately capture some

    important analysis and design concepts

    16 (12.2%) 32 (24.4%) 18 (13.7%) 45 (34.4%) 20 (15.3%)

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397 387

  • 7/28/2019 Cercetare Stiintifica UML

    6/15

    Table 10

    Accuracyresponse frequencies

    Survey item Strongly

    disagree

    Somewhat

    disagree

    Neither

    agree nor

    disagree

    Somewhat

    agree

    Strongly

    agree

    Accuracy 2. UMLs notational elements are accurate enough for

    my purposes

    4 (3.1%) 21 (16.0%) 9 (6.9%) 62 (47.3%) 35 (26.7%)

    10. There are accuracy problems in the UML

    constructs that I use or need

    14 (10.7%) 47 (35.9%) 35 (26.7%) 28 (21.4%) 7 (5.3%)

    18. UML leads me down the right path in developing

    systems

    3 (2.3%) 18 (13.7%) 42 (32.1%) 32 (24.4%) 36 (27.5%)

    26. UML models often lead to inaccurate represen-

    tations of the underlying system being developed

    18 (13.7%) 53 (40.5%) 24 (18.3%) 32 (24.4%) 4 (3.1%)

    Table 11

    Compatibilityresponse frequencies

    Survey item Strongly

    disagree

    Somewhat

    disagree

    Neither

    agree nor

    disagree

    Somewhat

    agree

    Strongly agree

    Compatibility 3. When it is necessary to compare or aggregatedata from two or more different UML diagrams,

    there may be unexpected or difficult inconsistencies

    3 (2.3%) 18 (13.7%) 39 (29.8%) 57 (43.5%) 14 (10.7%)

    11. There are times when supposedly equivalent

    information from two different UML diagrams is

    inconsistent

    9 (6.9%) 31 (23.7%) 41 (31.3%) 39 (29.8%) 11 (8.4%)

    19. Sometimes it is difficult or impossible to

    compare or aggregate data from two different UML

    diagram sources because the data is defined

    differently

    4 (3.1%) 26 (19.8%) 43 (32.8%) 53 (40.5%) 5 (3.8%)

    27. UML notations consistently mean the same

    thing regardless of where they are used

    8 (6.1%) 34 (26.0%) 40 (30.5%) 37 (28.2%) 12 (9.2%)

    Table 12

    Flexibilityresponse frequencies

    Survey item Strongly

    disagree

    Somewhat

    disagree

    Neither

    agree nor

    disagree

    Somewhat

    agree

    Strongly

    agree

    Flexibility 4. UML is too inflexible to be able to respond to the

    changes in system requirements models

    28 (21.4%) 65 (49.6%) 16 (12.2%) 17 (13.0%) 5 (3.8%)

    12. When business requirements change it is easy to

    change the selection and format of UML diagrams

    7 (5.3%) 32 (24.4%) 25 (19.1%) 58 (44.3%) 9 (6.9%)

    20. I t is difficult to change UML models. 35 (26.7%) 48 (36.6%) 21 (16.0%) 22 (16.8%) 5 (3.8%)

    28. UML provides enough flexibility to model any system 6 (4.6%) 24 (18.3%) 21 (16.0%) 54 (41.2%) 26 (19.8%)

    Table 13

    Understandabilityresponse frequencies

    Survey item Strongly

    disagree

    Somewhat

    disagree

    Neither

    agree nor

    disagree

    Somewhat

    agree

    Strongly

    agree

    Understandability 5. The UML diagrams that I need are

    displayed in a readable and understandable

    form

    3 (2.3%) 12 (9.2%) 7 (5.3%) 56 (42.7%) 53 (40.5%)

    13. The UML diagrams are presented in a

    readable and useful format

    2 (1.5%) 6 (4.6%) 11 (8.4%) 67 (51.1%) 45 (34.4%)

    21. I find UML to be too complex and difficult

    to understand

    54 (41.2%) 40 (30.5%) 17 (13.0%) 13 (9.9%) 7 (5.3%)

    29. UML adequately conveys the meaning and

    intent of the underlying system

    5 (3.8%) 24 (18.3%) 29 (22.1%) 56 (42.7%) 17 (13.0%)

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397388

  • 7/28/2019 Cercetare Stiintifica UML

    7/15

    dimension by averaging the scaled data. A cursory

    inspection of the obtained TTF indices (Table 17 and

    Fig. 1) indicates a response pattern that is slightly above

    neutral, which represents a generally positive perception of

    UML. Indices fell between 2.1 and 4.35, with an overall

    TTF index of 3.35.

    Breaking down the computed indices by TTF dimension

    (Table 18), reveals that perception of UML is by no

    means uniform across the variables used in this study.

    The understandability dimension, for example, was found to

    have the highest index (3.89), while ambiguity revealed a

    neutral index (3.0). As seen previously (Table 3), over 77%

    Table 14

    Level of detailresponse frequencies

    Survey item Strongly

    disagree

    Somewhat

    disagree

    Neither

    agree nor

    disagree

    Somewhat

    agree

    Strongly

    agree

    Level of detail 6. On the models that I deal with, the exact meaning of

    UMLs notational elements is either obvious, or easy

    to find out

    6 (4.6%) 26 (19.8%) 19 (14.5%) 50 (38.2%) 30 (22.9%)

    14. The exact definition of UML notational elements

    related to my tasks is easy to find out

    2 (1.5%) 22 (16.8%) 22 (16.8%) 58 (44.3%) 27 (20.6%)

    22. UML provides sufficiently detailed diagrammatic

    constructs

    3 (2.3%) 16 (12.2%) 21 (16.0%) 67 (51.1%) 24 (18.3%)

    30. UML contains too many notations and diagrams to

    be used effectively

    33 (25.2%) 45 (34.4%) 26 (19.8%) 19 (14.5%) 8 (6.1%)

    Table 15

    Trainingresponse frequencies

    Survey item Strongly

    disagree

    Somewhat

    disagree

    Neither

    agree nor

    disagree

    Somewhat

    agree

    Strongly

    agree

    Training 7. There is not enough training on how to understand,

    access or use UML

    18 (13.7%) 30 (22.9%) 25 (19.1%) 36 (27.5%) 22 (16.8%)

    15. I am getting the training I need to be able to use UML

    effectively in my job

    19 (14.5%) 21 (16.0%) 37 (28.2%) 32 (24.4%) 22 (16.8%)

    23. There is no one to go to for help when I encounter a

    problem using UML

    27 (20.6%) 36 (27.5%) 20 (15.3%) 35 (26.7%) 13 (9.9%)

    31. I received enough UML training to effectively use it 12 (9.2%) 25 (19.1%) 28 (21.4%) 38 (29.0%) 28 (21.4%)

    Table 17

    Distribution of TTF indices

    N Min. Max. Mean Std. dev.

    TTF 131 2.10 4.35 3.3481 0.4668

    Table 16

    Ambiguityresponse frequencies

    Survey item Strongly

    disagree

    Somewhat

    disagree

    Neither

    agree nor

    disagree

    Somewhat

    agree

    Strongly

    agree

    Ambiguity 8. There are so many different UML diagrams and

    notational systems, each with slightly different

    symbols, that it is hard to understand which one to

    use in a given situation

    23 (17.6%) 49 (37.4%) 17 (13.0%) 34 (26.0%) 8 (6.1%)

    16. UML diagrams are represented in so many

    different places and in so many forms; it is hard to

    know how to use them effectively

    18 (13.7%) 48 (36.6%) 22 (16.8%) 37 (28.2%) 6 (4.6%)

    24. Some UML models are insufficiently specified,

    allowing developers to interpret them in more than

    one way

    6 (4.6%) 21 (16.0%) 23 (17.6%) 53 (40.5%) 28 (21.4%)

    32. It is not always clear how to use UMLs

    notations across the different diagram types

    11 (8.4%) 39 (29.8%) 25 (19.1%) 48 (36.6%) 8 (6.1%)

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397 389

  • 7/28/2019 Cercetare Stiintifica UML

    8/15

    of the respondents in this survey had 4 or more years of

    experience in object-oriented technology. That, in conjunc-

    tion with the high degree of college education of the

    respondents (Table 4), may partially explain the relatively

    high index exhibited along this dimension. A major part of

    understanding UML is predicated on having a solid

    comprehension of the object-oriented model. Since most

    of our respondents were already highly experienced with

    this technology, one might assume that there would be little

    problem understanding the fundamental concepts under-

    lying UML, which is based on that paradigm. Although

    UML has a reputation for being overly complex [36,42], weshould also consider that most practitioners may only be

    using a subset of the language [13], exhibiting the

    phenomenon known in software engineering as the 80/20

    rule (i.e. 80% of the systems are developed using 20% of

    the language constructs). The relatively high understand-

    ability index may actually reflect usage of a smaller subset

    of UML, which is less complex and easier to work with.

    Several authors [2,35,36] have pointed to ambiguity as

    one of the most problematic aspects of UML. Ambiguity of

    UML constructs may indeed be related to the very way in

    which the standard was created, i.e. as a synthesis of already

    existing OOAD techniques. As if attempting to satisfy the

    widest range of participants involved in the standardization

    process, UML has incorporated a number of overlappingconstructs, which potentially introduce ambiguity in their

    usage. The relatively low index calculated for the ambiguity

    index in this study, may reflect this somewhat disjointed

    aspect of UML. Averages of scaled data for each of the TTF

    dimensions are displayed in Table 18.

    It is interesting to revisit the location data described

    previously, broken down according to TTF indices.

    Table 19 reveals that US developers have a slightly lower

    overall TTF index than those in most of the other regions

    represented in the survey. Particularly noteworthy are the

    differences between the US/Canada, Europe and Asia/Mid-

    dle East regions, each with sizable portions of the sample.Ironically, the level of satisfaction of US developers seems

    to be lower than those in Europe and Asia. Perhaps, this

    trend reflects the fact that non-US developers have been

    using OOAD methods longer than those in the US [27].

    Further investigation of the intercultural aspects of UML

    usage and adoption is warranted [21].

    3.3.3. Other characteristics of UML

    In addition to the primary questions, there were 19

    questions that related to other project and technology

    characteristics. These questions were designed to learn more

    about how UML is actually being used in the field and todetermine which factors might influence usage.

    One important variable, which was included in the

    primary study, is training. Table 20 reveals that all training

    categories presented are being utilized to some degree.

    Although 41% of the population received some type of

    formal training, an even greater percentage was self-taught,

    either through online tutorials or through other means

    Fig. 1. Histogram of TTF indices.

    Table 19

    TTF indices by geographic location of company

    Geographic region Frequency Percent Cumulative percent TTF index

    USA and Canada 52 40 40 3.24

    Europe 52 40 80 3.39

    Asia/Middle East 17 13 93 3.52

    Australia/New Zealand 5 3.8 97 3.15

    Africa 3 2.3 99 3.77

    South America 2 1.5 100 3.40

    Total 131 100.0

    Table 18

    TTF indices by dimension

    Right data Flexibility Understandability Training Ambiguity General TTF index

    3.17 3.53 3.89 3.15 3 3.35

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397390

  • 7/28/2019 Cercetare Stiintifica UML

    9/15

    (e.g. self-study, books, etc.). A smaller percentage had the

    added advantage of having access to a mentor.

    The survey asked respondents to indicate their primary

    purpose for using UML. Table 21 indicates the response

    breakdown. The other category included such entries as:

    business domain modeling, capture design level decisions,

    identify risks, and satisfy a certification or degree require-

    ment. It appears that most of the respondents of the survey

    are using what Fowler [16] calls UML by sketch, which is

    the most informal and dynamic approach to modeling and

    which utilizes UML constructs primarily to aid in

    communication. Using UML in this fashion does not require

    strict enforcement of every rule of the specification, as

    opposed to UML by blueprint and UML as programming

    language, two other approaches that are much more

    rigorous and more concerned with completeness.

    Project development costs were elicited and are pre-

    sented in Table 22. The results indicate that UML is used on

    projects of all sizes. About 15% were $150,000$499,000,

    and overall, some 52% were $150,000 or more. It is

    interesting to note that such a sizeable percentage (13.7%)

    of the projects had a cost less than $30,000. Given

    the relatively high experience level of the respondents

    (Table 4), it is curious that so many are engaged in suchlow-end projects.

    The project expected/realized benefit in dollars was also

    collected. A high percentage of respondents (39.7%) either

    failed to respond to this item or selected other, indicating

    that they were not privy to financial data. It is interesting to

    note that 30% of the respondents did not seem to have

    knowledge of the benefit of the project they were working

    on. Table 23 shows the breakdown for the respondents. The

    results seem to reflect the same pattern as the project costs

    (Table 22) above, i.e. a bimodal distribution, with 21.4% at

    the high end (over 1 million) and 16.0% at the low end (less

    than $30,000).Management buy-in is believed to be an important

    prerequisite for successful technology adoption [6,23,41].

    Table 24 displays the results of the survey question asking

    for the level of management involvement in UML usage.Results show a mixed level of management involvement

    across the sample population.

    UML is relatively new and has still not been adopted

    universally. This is reflected in Table 25. Only 27.5% of the

    sample, for example, has adopted UML as the primary

    development approach, using it consistently on all projects

    while over 44% use it only sporadically.

    These last two survey items (management involvement

    and use of UML in organization) warrant further

    discussion, since they represent aspects of UML utilization.

    The concept of utilization plays a key role in IT research.

    Utilization has been conceptualized as the extent to which

    the information system has been incorporated into the

    individuals work routines [19]. Such integration may be

    either by individual choice or by organizational mandate.

    Although a number of other ways have been used to

    conceptualize utilization, such as frequency of use and

    diversity of applications employed [8,39] the concept is

    still not well understood and is in need of refinement [19].

    Table 20

    Type of UML training

    Frequency Percent

    Formal course 51 41.2

    Mentor 37 28.2

    Online tutorial 71 54.2

    Other 55 42.0

    Table 21

    Main objective for using UML

    Frequency Percent Cumulative

    percent

    Capture and communicate

    requirements

    74 56.5 56.5

    Guide development of code 39 29.8 86.3

    Reverse engineering 13 9.9 96.2

    Other 5 3.8 100.0

    Table 22

    Project development costs

    Project cost Frequency Percent Cumulative

    percent

    No response 4 3.1 3.1

    Less than $30,000 18 13.7 16.8

    $30,000$39,999 1 0.8 17.6

    $40,000$49,999 1 0.8 18.4

    $50,000$59,999 5 3.8 22.2

    $60,000$74,999 4 3.1 25.3

    $75,000$99,999 4 3.1 28.4

    $100,000$149,999 6 4.6 33

    $150,000$249,999 10 7.6 40.6

    $250,000$499,999 10 7.6 48.2

    $500,000$999,999 7 5.3 53.5

    $1,000,000 or more 41 31.3 84.8

    Other 20 15.3 100.0

    Total 131 100

    Table 23

    Project expected/realized benefit

    Project benefit Frequency Percent Cumulative

    percent

    No response 14 10.7 10.7Less than $30,000 21 16.0 71.0

    $30,000$39,999 1 0.8 45.8

    $40,000$49,999 1 0.8 46.6

    $50,000$59,999 5 3.8 50.4

    $60,000$74,999 2 1.5 54.2

    $75,000$99,999 1 0.8 55.0

    $100,000$149,999 9 6.9 38.9

    $150,000$249,999 2 1.5 40.5

    $250,000$499,999 6 4.6 45.0

    $500,000$999,999 3 2.3 52.7

    $1,000,000 or more 28 21.4 32.1

    Other 38 29.0 100.0

    Total 131 100.0

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397 391

  • 7/28/2019 Cercetare Stiintifica UML

    10/15

    With this in mind, a closer inspection of the computed TTF

    indices was undertaken to determine if there was a

    relationship with utilization, derived from the surveyquestions on use of UML within the organization and

    management involvement, a related concept also believed

    to have an impact on successful adoption and use of object-

    oriented technology [23,41].

    Table 26 displays the indices broken down according to

    responses in both of the utilization related questions from

    the survey. The results of this analysis suggest that there is a

    relationship between TTF and utilization. As the degrees of

    both management involvement and extent of usage

    increases, so do the TTF indices. After operationalizing

    the survey responses (i.e. converting them from textual to

    scalar data), we ran regressions to see if this relationshipcould be further established. Table 25 shows the adjusted

    R-squares of 0.074 for use of UML within the organization

    and 0.088 for management involvement, suggesting that

    there is some relationship. We plan to investigate this more

    thoroughly in future studies.

    UML is just a notational language and does not include a

    methodology. Although the Unified Process [29] is the

    recommended approach, UML is meant to be independent

    of any specific software development methodology. It istherefore important to consider this, as it may impact

    successful usage of UML. Table 27 reveals that there is a

    wide variety of methods employed along with UML,

    including 21% who indicated they are using an older

    structured methodology. The majority of the respondents

    selected other, which on further inspection included a

    wide array of methodologies including: DSDM, ICONIX,

    modified Objectory approach, Catalysis, Contextual Design,

    Feature Driven Design, DOD specific methodologies, and

    in-house methods.

    The version of UML under investigation (1.X) has nine

    diagrams (the recently adopted UML 2.0 has 13 diagrams).

    Therefore, when we query users of UML, we need to take

    into account which of the diagrams they are using. There is

    quite a bit of variation with regard to how developers use

    UML. Again, we can look to Fowlers designation of the

    three types of UML usage (i.e. as sketch, blueprint or

    programming language) as a way to explain users selection

    of specific diagram types [16]. Depending on the specific

    needs of the developer, one might casually create use case

    and class diagrams, while another might pay stricter

    attention to the full Object Management Group specification

    and use all diagrams to model systems. Fig. 2 displays the

    ranking of diagrams in order of use. The three most

    important diagrams in terms of order of use are Use Case,Class and Sequence.

    Adoption of object-oriented analysis and design tech-

    niques takes time and the completion of several projects is

    generally necessary before gains are realized [23]. The

    present survey asked respondents to indicate how many

    UML-based projects they completed (Table 28). Over 50%

    of the respondents have completed less than five projects in

    UML, reflecting the relative immaturity of the modeling

    language. But, about 40% have done five or more projects;

    while 10% have done 10 or more. T he one data

    point indicating completion of 500 UML projects was

    considered an outlier. Given the relative immaturity ofUML, it is highly unlikely that this represents useful

    information.

    Table 24

    Management involvement

    Management involvement Frequency Percent Cumulative

    percent

    No response 2 1.5 1.5

    Does not seem to care about

    methods used as long as

    project is completed on time

    39 29.8 31.3

    Fully endorses and

    encourages the use of UML

    and allocates necessary

    resources

    40 30.5 61.8

    Moderate endorsement but

    limited spending

    36 27.5 89.3

    Other 14 10.7 100

    Total 131 100.0

    Table 25

    Use of UML in organization

    UML usage Frequency Percent Cumulativepercent

    No response 1 0.8 0.8

    Other 14 10.7 10.7

    Used consistently on all

    development projects

    36 27.5 27.5

    Used for large projects only 22 16.8 16.8

    Used sporadically with no

    mandate from management

    58 44.3 44.3

    Total 131 100.0 100.0

    Table 26

    TTF indices by utilization factors

    Right data Flexibility Understandability Training Ambiguity TTF index

    Management involvement

    (adjusted R2Z0.088)

    Full endorsement 3.76 4.08 3.88 2.74 3.47 3.57

    Moderate endorsement 3.17 3.47 3.94 3.06 2.95 3.32

    Indifferent 2.92 3.38 3.67 2.96 3.28 3.24

    Extent of usage (adjusted

    R2Z0.074)

    Used consistently 3.36 3.83 4.04 3.49 2.99 3.54

    Large projects only 3.18 3.51 4.18 3.44 2.73 3.41

    Sporadically 2.99 3.4 3.72 2.93 3.13 3.23

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397392

  • 7/28/2019 Cercetare Stiintifica UML

    11/15

    There are many products on the market aimed at helping

    software developers create UML diagrams. One of the most

    popular products comes from Rational Corporation, the

    employer of the Three Amigos and the company whose

    name is most closely associated with UML. It was not

    surprising that a large number of the sample uses Rose, the

    primary UML CASE tool offering of Rational. It was also

    interesting to see what other tools are being used by thesample population. Fig. 3 displays the distribution of UML

    tool usage. It is obvious that the selections offered on the

    survey missed the mark, since the majority of respondents

    selected the other category. Within the other category, there

    was one product that emerged as the clear leader. Over 80%

    of those selecting the other category were using Enterprise

    Architect, a product of the Australian company Sparx

    Systems (www.sparxsystems.com). Other tools represented

    in the sample were Together, Visio, and manual methods

    such as pencil and paper, whiteboards, or flipcharts.

    Over 28% of the respondents added comments to the

    survey. Though not statistically analyzed, these comments

    are important in that they provide additional insight into

    how UML is being used. The following responses, for

    example, support the idea that UML is really not a

    methodology, but simply a way to communicate using

    visual notations.

    Many of the questions imply that UML is more of a

    method than a way of communicatingand to many, I

    think it is. But to me, it is a way of communicating, and

    my only use for it is to allow the team to guess enough

    about the solution to begin writing tests and code. I use

    UML to communicate an idea that is too complex to

    describe by hand-waving. The moment we understand

    each other enough to start writing code, we stop writing

    UML. And the moment the code teaches us more than the

    UML diagram did, we abandon (rather than update) thediagram. We are also very sloppy with notation as long as

    the diagram communicates what we need to say.

    UML is not a complete and comprehensive solution to all

    of the challenges associated with defining requirements

    and designing software systems. It is however, a useful

    and valuable technique. It is by no means the only

    technique that an analyst or designer needs any more than

    a hammer is the only tool that a carpenter needs.

    These comments are consistent with the writings of agile

    methodology proponents [3,5,29], who warn against placing

    too much emphasis on UML itself, which is ultimately just anotational tool, and not enough on the fundamental

    processes underlying systems analysis and design.

    Other comments reflect the belief that UML is still too

    incomplete to adequately build complex systems as several

    authors have claimed [3,22].

    Examples include:

    UML is very powerful. Still it lacks the primary

    constructs for Systems Engineering and good architec-

    ture work. Many will be added in the SE working group

    and the architecture working group. Still there is a

    GREAT deal to do. We are inventing the language of

    engineering for the future. It may take a couple more

    years.

    UML is quite useful but adequate training is quite

    lacking. The notation itself is just the medium. Also,

    over engineered systems are (wrongly) linked to UML

    and this leads to a bad perception of it. UML can be

    simple and efficient, thought provoking and on the

    contrary help in *simplifying* overly complex designs or

    concepts. In that UML can add significant shareholder

    Table 27

    Methodology used in conjunction with UML

    Methodology Frequency Percent Cumulative

    percent

    No response 2 1.5 1.5

    Agile methodology 20 15.3 16.8

    None 21 16.0 32.8

    Structured approach 21 16.0 48.8

    Unified process 39 29.8 78.6

    Other 28 21.4 100.0

    Total 131 100.0

    Fig. 2. UML diagrams in order of use.

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397 393

    http://www.sparxsystems.com/http://www.sparxsystems.com/
  • 7/28/2019 Cercetare Stiintifica UML

    12/15

    value. In being wrongly used, it can for sure be

    subtracting value.

    And yet other comments shed light on the difficulties in

    adopting new technologies such as UML. For example:

    Relative to the total number of software developers, the

    number of those who actually use UML is quite small.

    The adoption pattern seems to be very much like that wesaw for structured methods. Many developers attend an

    introductory class on UML and make at least some

    attempt at applying it to real world problems.

    Inevitably, trying to apply the technique to realistic

    problems (as opposed to the small, contrived examples

    from the classroom) reveals shortcomings in both the

    technique and in the students knowledge. A few

    practitioners will be convinced enough of the potential

    benefits of the technique to work through these issues to

    find practical methods of application. Without a lot or

    encouragement and support, most developers will

    quickly abandon the new technique and return to more

    familiar ways of doing things.

    A future study will analyze these comments in more

    detail and solicit further input from the respondents to thissurvey.

    4. Implications

    There are a number of managerial implications that arise

    as we study UML in the context of task-technology fit. As

    UMLs popularity has increased, an entire industry provid-

    ing related products and tools has also begun to emerge.

    Companies are starting to invest in UML, hoping that it will

    facilitate more productive software development. But UML

    is not a trivial technology. Simply throwing it at developersdoes not mean that it will result in the performance gains

    desired. We need first to ask a number of important

    questions to determine how well the usage of UML will fit

    within the organizational context. How will UML be used,

    i.e. casually or at a more rigorous level of detail? Do the

    users have adequate object-oriented experience to under-

    stand the complexities of UML and to be able to use it

    successfully? Does management support the use of UML

    and/or is there a champion in the company who can guide

    the effort? Is there adequate training available? These are

    just a few questions that need to be considered. In short, we

    need to take into account the multitude of complex factors

    that make up the organizational environment, striving toachieve alignment between them. The implication for

    management is clear. The greater the fit between the

    individual, task and technology, the better the chances that

    UML will be perceived positively thus leading to greater

    performance impacts. The model utilized in this study

    shows modest support for what is so intuitively obvious

    regarding task-technology fit. However, as can be seen by

    the somewhat lackluster perception of UML, there is still

    much about the technology that is open-ended and poorly

    Table 28

    Number of UML projects completed by respondent

    UML projects

    completed

    Frequency Percent Valid percent

    No response 11 8.40 8.40

    0 8 6.11 14.51

    1 12 9.16 23.67

    2 20 15.27 38.93

    3 17 12.98 51.91

    4 10 7.63 59.55

    5 14 10.69 70.23

    6 6 4.58 74.81

    7 2 1.53 76.34

    8 2 1.53 77.87

    9 1 0.76 78.63

    10 15 11.45 90.08

    12 2 1.53 91.61

    15 3 2.29 93.90

    17 1 0.76 94.66

    18 1 0.76 95.42

    27 1 0.76 96.19

    30 3 2.29 98.4850 1 0.76 99.24

    500 1 0.76 100.00

    Total 131 100 100

    Fig. 3. UML tool usage.

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397394

  • 7/28/2019 Cercetare Stiintifica UML

    13/15

    defined to allow its users to perceive its benefit. As UML

    matures, it is tempting to conjecture that this situation will

    change and that a task-technology fit will be more

    definitively evident.

    4.1. Future research

    There is a critical need for further research in all areas

    relating to UML usage. Very few empirical studies have

    been performed to date. The present study served as a

    starting point from which to launch subsequent studies.

    A follow-up study will be performed that breaks down

    the population along different demographic factors. Good-

    hue and Thompson performed a similar analysis in their

    exploration of managerial level as a possible determinant of

    user evaluations of information systems [19]. The demo-

    graphic variables included in the present study (e.g.

    industry, country of origin, education level, etc.) should

    be analyzed in a similar fashion, to determine how they

    influence task-technology fit of UML usage. Specifically,

    intercultural studies along the lines of [15] would be

    interesting to see how cultural factors impact UML usage. In

    addition, much of the project, organizational and technology

    specific data collected via this survey should be further

    analyzed to see if other patterns emerge.

    Another future study could be based on longitudinal data.

    With the solidification of the new UML 2.0 standard and the

    increasing use of UML across the world, it would be

    informative to reevaluate the responses to this same survey

    several years from now.

    Through this research, task-technology fit was shown to

    be a promising framework to explore UML; however, muchwork needs to be done in order to improve the model used

    for study of this technology. We will continue to investigate

    other variables and plan to fine tune the model for future

    studies. A more robust conceptualization of UML utiliz-

    utilization will also be an important aspect of this effort.

    5. Summary and conclusion

    5.1. Summary

    The Unified Modeling Language (UML) has become the

    de facto standard for object-oriented systems development

    and will soon be an international standard. Promoted as a

    unified approach which incorporates the best practices of

    previous notational methods, UML promises to relieve

    some of the problems associated with object-oriented

    software development. However, there is a severe lack of

    empirical evidence supporting the claim that UML leads to

    greater performance and a number of problems continue to

    be reported concerning its usage (e.g. complexity, incon-

    sistency, difficulty to learn, incompleteness).

    This study used task-technology fit theory as a theoretical

    backdrop to examine UML. Task-technology fit theory

    suggests that for an information technology to impact

    performance, it must first meet the needs of the user, i.e.

    there must be a fit between the task requirements of the user

    and the functionality of the system. This study extended

    prior task-technology fit research by investigating how

    individual and task characteristics impact UML usage. In

    addition, it provided much needed data relating to currentusage of UML in the global software development

    community.

    UML users were identified from a number of online

    sources, such as newsgroups, conference proceedings, user

    groups, and directories involving individuals who have

    experience with UML. E-mail messages were sent to 1507

    UML users, inviting them to participate in the study by

    linking to the Web hosted survey. A final sample size of 131

    was obtained.

    Analysis involved inspection of the raw responses to

    individual survey items as well as examination of

    aggregated TTF indices. While there was a wide spectrum

    of opinion regarding UML usage, this analysis revealed

    some interesting patterns. For example, it appears that the

    UML community surveyed had a more positive perception

    of UML than some of the literature has suggested [11,18,22,

    24,36,42]. The majority of respondents viewed UML as

    accurate, consistent, and flexible enough to use on

    development projects. Further analysis is needed to

    determine which factors might have influenced such

    perceptions.

    Aggregating the TTF indices across dimensions provided

    some additional empirical data related to TTF. It was

    demonstrated that the ambiguity variable had the lowest

    index and understandability the highest index. An explora-tory attempt at establishing a relationship between the

    derived TTF indices and an ad hoc conceptualization

    of utilization also showed some promise. Although the

    R-squares were low, a definite effect was observed,

    supporting the idea that TTF is positively related to both

    the extent of UML use and to managements involvement in

    the use of UML on development projects.

    Finally, analysis of other survey questions demographic

    makeup of the sample population, as well as provided

    information regarding UML usage.

    5.2. Conclusion

    The characteristics identified in this study were right

    data, accuracy, compatibility, flexibility, understandability,

    level of detail, training, and ambiguity. Three variables were

    dropped from the model as a result of low reliability. These

    were accuracy, compatibility and level of detail.

    One of Goodhues original constructs [20], accuracy

    was meant to measure the correctness of the data. In the

    present study, accuracy was altered slightly to reflect the

    correctness of UMLs constructs. To some extent, it

    attempts to determine whether UML diagrams result in

    accurate depictions of the system, or whether they actually

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397 395

  • 7/28/2019 Cercetare Stiintifica UML

    14/15

    mislead the developer, as Simons and Grahams cogni-

    cognitive misdirection concept suggests [36]. The ques-

    tions in this category, although intuitively consistent, fail

    to hold together as evidenced by the low Chronbachs

    alpha. One reason could be the experience level of the

    sample population, which was very high (approximately

    77% of the respondents had 4 or more years experiencewith object-oriented technology). The concept of accuracy

    may not be relevant to this group of users, who already

    has a firm enough grasp of the object-oriented paradigm.

    The level of detail construct was also included in

    Goodhues questionnaire [20], and originally measured

    whether data in general was maintained at the right level

    of detail. In this survey it was meant to convey whether

    UML is easy to figure out or whether it is too detailed.

    Lack of cohesion within this variable might be related to

    the variety of ways in which UML is being used among

    those sampled. UML is used by some simply as a

    communications tool and by others as a formal mechan-ism for requirements definition and design [16]. To further

    complicate the matter, UML has fragmented into various

    dialects with separate domains for enterprise systems,

    Web-based systems, and real-time systems [13], which are

    evolving differently and which involve different levels of

    detail. We may also need to consider the process used

    along with UML (e.g. Unified Process, agile method-

    ologies) as well, since some of these methodologies are

    inherently more detailed than others.

    Like previous studies of other information technol-

    ogies, this study suggests that task-technology fit theory

    has some explanatory power, but due to the elusive

    nature of UML, there are still many questions that need

    to be answered. While the aggregated index of 3.35

    indicates a slightly positive perception of UML, it by no

    means represents an overwhelming endorsement. At this

    early stage in its evolution, it may be that the people

    using UML still do not have enough of a feeling for how

    this technology fits with the tasks they are trying to

    perform. The fact that respondents to this survey failed to

    express strong opinions may reflect the fact that UML is

    an immature standard that is still undergoing codification.

    The UML phenomenon presents an enigma. While it is

    increasingly being adopted throughout the world, there is

    really no consensus on how it should be used or onwhether it is providing beneficial effects. Much of the

    literature points to a technology that is complex, poorly

    understood, and used inconsistently. Perhaps, the results

    of this survey reflect a certain degree of confusion among

    the user community surrounding UML. Developers

    clearly seem eager to use this highly hyped technology

    which is spreading across the world. Yet, they are

    lacking an adequate enough understanding of the

    technology to determine if it is making any real

    difference in the way they are performing their develop-

    ment tasks.

    References

    [1] R. Agarwal, A.P. Sinha, M. Tanniru, The role of prior experience and

    task characteristics in object-oriented modeling: an empirical study,

    International Journal of HumanComputer Studies 45 (1996) 639

    667.

    [2] D.H. Akehurst, A.G. Waters, UML deficiencies from the perspective

    of automatic performance model generation, OOPSLA99 Workshopon Rigorous Modeling and Analysis with the UML: Challenges and

    Limitations, 1999.

    [3] S.W. Ambler, The Object Primer: The Application Developers Guide

    to Object Orientation and the UML, second ed., CambridgeUniversity

    Press, Cambridge, 2001.

    [4] G. Booch, Object-oriented Analysis and Design with Applications,

    second ed., Benjamin/Cummings, Redwood City, 1994.

    [5] A. Cockburn, Agile Software Development, Addison-Wesley,

    Boston, 2000.

    [6] J.G. Cooprider, J.C. Henderson, Technology-process fit: perspectives

    on achieving prototyping effectiveness, Journal of Management

    Information Systems 7 (3) (1991) 6787.

    [7] J. DAmbra, Preliminary investigations of user evaluation of the

    WWW, Proceedings of the Fifth Americas Conference on Information

    Systems, Milwaukee, WI, 1999.

    [8] F. Davis, R. Bagozzi, P. Warshaw, User acceptance of computer

    technology: a comparison of two theoretical models, Management

    Science 35 (8) (1989) 9821003.

    [9] M.T. Dishaw, D.M. Strong, Supporting software maintenance with

    software engineering tools: a computed task-technology fit analysis,

    The Journal of Systems and Software 44 (1998) 107120.

    [10] M.T. Dishaw, D.M. Strong, D.B. Brandy, Assessing task-technology

    fit in simulation modeling, Proceedings of the Seventh Americas

    Conference on Information Systems, Boston, MA, 2001.

    [11] D. Dori, Object-process methodology applied to modeling credit card

    transactions, Journal of Database Management 12 (1) (2001) 414.

    [12] T. Downes-Le Guin, P. Janowitz, R. Stone, S. Khorram, Use of pre-

    incentives in an internet survey, The IMRO Journal of Online

    Research, 2002, http://www.ijor.org/ijor_archives/articles/use_of_pre-incentives_in_an_internet_survey.pdf

    [13] J. Erickson, K. Siau, Unified Modeling Language: theoretical and

    practical complexity, Proceedings of the Ninth Americas Conference

    on Information Systems, Tampa, FL, 2003, pp. 13231327.

    [14] J. Fedorowicz, A.O. Villeneuve, Surveying object technology usage

    and benefits: a test of conventional wisdom, Information & Manage-

    ment 35 (1999) 331344.

    [15] T.W. Ferratt, G.E. Vlahos, An investigation of task-technology fit for

    managers in Greece and the U.S., European Journal of Information

    Systems 7 (1998) 123136.

    [16] M. Fowler, K. Scott, UML Distilled Third Edition: A Brief Guide to

    the Standard Object Modeling Language, Addison-Wesley, Boston,

    2004.

    [17] L. Garceau, E. Jancura, J. Kneiss, Object-oriented analysis and

    design: a new approach to systems development, Journal of Systems

    Management 44 (1) (1993) 2533.

    [18] M. Glinz, Problems and deficiencies of UML as a requirements

    specification language, Proceedings of the 10th International Work-

    shop on Software Specification and Design (IWWSSD-10), San

    Diego, CA, 2000, pp. 1122.

    [19] D.L. Goodhue, Development and measurement validity of a task-

    technology fit instrument for user evaluations of information systems,

    Decision Sciences 29 (1) (1998) 105138.

    [20] D.L. Goodhue, R.L. Thompson, Task-technology fit and individual

    performance, MIS Quarterly 19 (2) (1995) 213236.

    [21] M. Grossman, R.V. McCarthy, J.E. Aronson, Factors influencing

    Unified Modeling Language (UML) usage in the global software

    development community, Fourth Annual Global Information

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397396

    http://www.ijor.org/ijor_archives/articles/use_of_pre-incentives_in_an_internet_survey.pdfhttp://www.ijor.org/ijor_archives/articles/use_of_pre-incentives_in_an_internet_survey.pdfhttp://www.ijor.org/ijor_archives/articles/use_of_pre-incentives_in_an_internet_survey.pdfhttp://www.ijor.org/ijor_archives/articles/use_of_pre-incentives_in_an_internet_survey.pdf
  • 7/28/2019 Cercetare Stiintifica UML

    15/15

    Technology Management (GITM) World Conference, Calgary,

    Canada, 2003, pp. 294297.

    [22] T. Halpern, Augmenting UML with fact orientation, Proceedings of

    the 34th Hawaii International Conference on System Sciences, Maui,

    HI, 2001, pp. 110.

    [23] B.C. Hardgrave, Adopting object-oriented development: one com-

    panys experience, Proceedings of the Sixth Americas Conference on

    Information Systems, Milwaukee, WI, 1999, pp. 568570.

    [24] M. Hitz, G. Kappel, Developing with UML: some pitfalls and

    workarounds, The Unified Modeling Language, {UML}98Beyond

    the Notation, First International Workshop, Mulhouse, France, 1998.

    [25] I. Jacobson, P. Jonsson, G. Overgaard, Object-Oriented Software

    Engineering, A Use Case Driven Approach, ACM Press/Addison-

    Wesley, Reading, 1992.

    [26] R.A. Johnson, The ups and downs of object oriented systems,

    Communications of the ACM 43 (10) (2000) 68.

    [27] R.A. Johnson, B.C. Hardgrave, Object-oriented methods: current

    practices and attitudes, The Journal of Systems and Software 48

    (1999) 512.

    [28] C. Kobryn, Will UML 2.0 be agile or awkward? Communications of

    the ACM 45 (1) (2002) 107110.

    [29] C. Larman, Applying UML and Patterns: An Introduction to Object-

    Oriented Analysis and Design and the Unified Process, second ed.,

    Prentice Hall, Upper Saddle River, 2002.

    [30] R.V. McCarthy, J.E. Aronson, G. Claffey, Task-technology fit in data

    warehousing environments: analyzing the factors that affect utiliz-

    ation, Proceedings of the Eighth Americas Conference on Information

    Systems, Dallas, TX, 2002, pp. 4046.

    [31] R.V. McCarthy, J.E. Aronson, K. Mazouz, Measuring the validity of

    task technology fit for knowledge management systems, Proceedings

    of the Seventh Americas Conference on Information Systems, Boston,

    MA, 2001.

    [32] U.S. Murthy, D.S. Kerr, Task/technology fit and the effectiveness of

    Group Support Systems: evidence in the context of tasks requiring

    domain specific knowledge, Proceedings of the 33rd Hawaii

    International Conference on System Sciences, Maui, HI, 2000.

    [33] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenson,

    Object-Oriented Modeling and Design, Prentice-Hall, EnglewoodCliffs, 1991.

    [34] A.I. Shirani, M.H.A. Tafti, J.F. Affisco, Task and technology fit: a

    comparison of two technologies for synchronous and asynchronous

    group communication, Information & Management 36 (1999) 139

    150.

    [35] K. Siau, Q. Cao, Unified Modeling Language (UML): a complexity

    analysis, Journal of Database Management 12 (1) (2001) 26.

    [36] A.J.H. Simons, I. Graham, 30 things that go wrong in object modeling

    with UML 1.3, in: H. Kilov, B. Rumpe, I. Simmonds (Eds.), Precise

    Behavioral Specification of Businesses and Systems, Kluwer

    Academic Publishers, Boston, 1999.

    [37] R. Smyth, Challenges to successful ERP use (Research in Progress),

    The 9th European Conference on Information Systems, Bled,

    Slovenia, 2001.

    [38] A. Srivihok, R. Ho, F. Burstein, An instrument for web measurement:

    end user evaluation of Web application effectiveness, Proceedings of

    the Australian Conference on Information Systems, Brisbane,

    Australia, 2000.

    [39] R.L. Thompson, C.A. Higgins, J.M. Howell, Towards a conceptual

    model of utilization, MIS Quarterly 15 (1) (1991) 125143.

    [40] B. Tjahjono, D. Fakun, R. Greenough, J. Kay, Evaluation of a

    manufacturing task support system using the task technology fit

    model, Proceedings of the Twelfth Annual Conference of the

    Production and Operations Management Society, Orlando, FL, 2001.

    [41] I.B. Ushakov, Experience based approach to OO technology adoption:

    key success factors, OOPSLA98 Mid-year Workshop on Applied

    Object Technology, Denver, CO, 1998.

    [42] S. Wang, Experiences with the Unified Modeling Language (UML),

    Proceedings of the Seventh Americas Conference on Information

    Systems, Boston, MA, 2001, pp. 12891293.

    [43] J.D. Wells, S. Sarker, A. Urbaczewski, S. Sarker, Studying customer

    evaluations of electronic commerce applications: a review and

    adaptation of the task-technology fit perspective, Proceedings of the

    36th Hawaii International Conference on System Sciences

    (HICSS03), Maui, HI, 2003.

    [44] E. Yourdon, Rise & Resurrection of the American Programmer,

    Yourdon Press, Upper Saddle River, 1996.

    [45] I. Zigurs, B.K. Buckland, J.R. Connolly, E.V. Wilson, A test of task-

    technology fit theory for group support systems, The DATA BASE forAdvances in Information Systems 30 (3) (1999) 3450.

    M. Grossman et al. / Information and Software Technology 47 (2005) 383397 397