cercetare stiintifica uml
Post on 03-Apr-2018
218 views
Embed Size (px)
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/infsof7/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.pdf7/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