Critical Assessment of the Role of UML for

Information System Development

Motto: System analysis using UML should not be mere graphic representation of the software
code for the application developed.

Vojtěch Merunka
Katedra informačního inženýrství
PEF ČZU
Kamýcká 129
160 00 Praha 6 - Suchdol
e_mail: merunka@pef.czu.cz

Keywords: UML, object-oriented analysis and design, object-oriented modeling, business objects,
conceptual objects, software objects, objects hierarchies, object databases, C++, Java.
Abstract: UML is currently among the most widely used modeling tools. Upon critical insight in this
tool's textbooks, however, we discover that in many areas concerning software development, how
many concepts are explained and used is at least questionable. The conclusions drawn by the author
of the article are based upon his own experience from the analysis and development of object-oriented
applications. This experience has been acquired at IT projects of Deloitte&Touche as well as during
teaching and university research activities in the area of object-oriented modeling.

1. Introduction
This document has been prepared as a critical response to how UML and its concepts are explained
and used in the practice. The UML itself, as known in general, has been created as an ambitious
modeling tool by three greatest software engineers - James Rumbaugh, Grady Booch and Ivar
Jacobson. The objective of UML has been and is to replace older methodologies of the aforesaid
authors by one methodology that is a combination of the best of the older ones. In addition, there are
other objectives of UML, such as exact syntax, extensibility and many more.

2. Object-oriented approach and the origin of UML

Before the arrival of UML in 1996, we had several competing object-oriented methodologies with
mutually very different notations. These were so called first generation object-oriented methodologies.
Many software companies used a combination of several methodologies instead of just one
methodology - mostly object models from OMT along with interaction diagrams from the Booch
method and the Use-Case approach of the Jacobson OOSE method. [5] Most of these methodologies
have later become the foundation for UML [1]:
UML has brought along a unification of the previous notations. The UML notation is mostly based on
OMT2 and has become a recognized standard. UML includes many different elements from the
original methodologies. There is, for example, the so called "business extension" from the original
Jacobson method that has been added in version 1.2, or the prepared version 2.0 that will absorb the
SDL methodology for supporting real-time processes. [1]

SYSTEMS INTEGRATION 2003 445

 VOJTĚCH MERUNKA

3. Is UML a method?
Obviously not. UML is "only" a graphic language. That, itself should not be a problem - it is good that
since 1996 we have had a standard for object modeling. The problem, however, is that fact that for the
"universal" language there is no adequate methodology and therefore mere knowledge of UML is
often considered a methodology.
Vast majority of professional publications on UML pretends to their readers that the methodology is
not the problem and that the knowledge of modeling in UML can be acquired by learning how to draw
individual diagrams. The author has similar negative experience with training sessions on "modern
object-oriented modeling".

4. Is UML a simple and comprehensible tool?

Experience proves that it is not. UML is definitely not a tool that could be understood by a problem
domain experts in reasonable time (for instance in 15 minutes at the beginning of a meeting with
analysts) to be able to read and understand the diagrams. This is not an unrealistic requirement because
in the past it was possible to work like this with entity-relational and data-flow models. Unfortunately,
in object-oriented modeling we do not have such an elegant and simple tool usable for requirement
capture procedure. Instead, we send customers to attend long training sessions on UML, where we
make them work with CASE tools.
People who are not familiar with computer programming find UML too difficult, and then they
incorrectly interpret the entire object-oriented approach. [3,4,9] It is possible to pick an acceptable set
of concepts out of UML for non-programmers; nevertheless, most professional books and training
sessions are too often unnecessarily based on deep programmer experience. Comprehensibility and
simplicity of UML is corrupted by the following facts:
1. UML models contain too many concepts. The concepts are at different levels of abstraction,
and sometimes they semantically overlap (e.g., associations between use-cases); and even their
concepts sometimes differ. The same model can therefore be interpreted differently by an
analyst and a programmer (the typical example is associations between objects).
2. There are several ways in the UML diagrams to show certain details in models (e.g., qualifiers
and association objects or state diagrams that are unintelligible mix of Mealy and Moore
automata). It is up to the analyst, which option he/she chooses.
3. Some concepts are insufficiently defined (- such as events in status diagrams versus messages
in interaction diagrams); one UML symbol covers several different concepts (e.g., in sequence
diagram the data flow between objects blends with controlling flow, which - among other
things - complicates implementation).
4. Although UML is generally good from the graphics aspect, some analysts do not like its visual
design in some aspects. It is, for example, the same symbol of a rectangle for instance and
class (they are differentiated only by internal description) as well as the direction of the
inheritance arrow that leads toward the parent object in spite of the fact that in the codes of
programming languages (even in theoretical explanations) inheritance is represented by
opposite direction - from the parent object toward the descendant.

5. Is UML object-oriented?
It is, according to the definition of the authors of UML themselves. UML supports many object-
oriented concepts, and there is currently no other "more" object-oriented as well as standard visual
modeling language. The success of UML in practical usage is based on many successful projects
where the software has been developed in C++ or Java, i.e., mixed languages that use object-oriented

446 SYSTEMS INTEGRATION 2003

 CRITICAL ASSESSMENT OF THE ROLE OF UML FOR INFORMATION SYSTEM DEVELOPMENT

approach together with classical imperative programming paradigm. But let us look at the "object-
orientation" of UML in detail:
5.1 IS-A is not a hierarchy of types or inheritance
Hierarchy of inheritance and hierarchy of types in one system do not necessarily mean the same thing.
Plus, when using inheritance, we have tools in modern programming languages for hiding the methods
and data of objects inherited. The hierarchy of object in the phase of problem formulation is not totally
identical with inheritance or the hierarchy of types. Nevertheless, UML expresses these three similar,
but not identical hierarchies in the same way. In modeling, it is necessary to look at them as follows:
1. From the designer's perspective - new object designer. This hierarchy is a hierarchy of
inheritance because inheritance is a tool for the physical programming of new objects.
2. From the user's perspective. This perspective can be further divided as follows:
• From the perspective of polymorphism - a view of a conceptual modeler who needs to
identify the use of the objects in his system but does not develop them. The object in
lower levels of hierarchy then must be capable of receiving the same messages and serve
in the same or similar context, such as high level objects. Therefore this "behavioral"
hierarchy is the hierarchy of types.
• From the perspective of the user and business domain analyst - the instances of lower-
level classes then must be elements of the same domain that also includes the instances of
the classes of the superior class. It means that a lower-level domain is a sub-set of a
higher-level domain. Here is no reason for introducing software inheritance yet. This
hierarchy is also called IS-A. In specific cases, it can differ from the hierarchy of types
because it does not deal with the behavior of the objects at the interface; rather it deals
with the object as a whole including its internal data structure.
• In simple problems it is obviously true that the three above-mentioned hierarchies are
identical. Therefore this fact is not really addressed in UML cookbooks. In more complex
problems, however, this is not true - e.g., in the design of system libraries that are often re-
used when developing specific systems. [18,19]
The issue of object hierarchies is not easy. Therefore, when designing a system, it is best to postpone
inheritance to later phases and treat it as mere implementation tool. First, it is necessary to recognize
the hierarchy at the level of real-world objects as is-a, and then define it according to the specific types
for conceptual objects and then consider optimal implementation of types using software object
inheritance. In most programming languages we can find the means (which, however, are very little or
incorrectly used) to differentiate types and classes.
UML can obviously be used for all things discussed. But we have supported in UML only one visual
symbol for generalization-specialization hierarchies, it significantly depends on the competence of the
analyst who needs to ensure correct interpretation of his models. Analysts often have a strong
tendency to understand all models as illustrations of source code structures for target programming
environment.
5.2 Object classes and object sets
The concept of Class in object modeling can be viewed in two different ways [6,10]:
1. A class is an object-type implementation; in a class we keep the description of the structure of
the objects of this type and the set of its operations/methods. In purely object-oriented
languages (e.g., CLOS, Smalltalk, Beta, Oberon, OODB languages), a class - unlike hybrid /
less object-oriented languages (e.g., C++, C#, VB, Object Pascal in Delphi and Java) can be
treated as a standard object; the discussed description of the structure along with the

SYSTEMS INTEGRATION 2003 447

 VOJTĚCH MERUNKA

operations are its data, that can be used while the program is running, changed, added to, or
deleted.
2. A completely different view of the class is to see it as a set that defines the occurrence of
objects of one particular type.
Unfortunately in UML, both views of a class are mixed together and there is no distinction between
class as an object itself and class as a virtual set formed by all objects that belongs to the specific class.
In its specification, UML includes so called multi-objects that can be understood as sets of instances.
UML also includes so called powertypes that can be used in representation of classes as objects, but
this option is not used by most analysts, neither is it supported in commonly used CASE tools. The
implementation of UML in CASE tools is generally only a part of the entire UML. This is because of
major part of software project today still does not use object data model and object-oriented databases,
but use "non object-oriented" databases based on relational tables that are conceptually related to both
"object classes" and "object sets".
Incorrect combination of the two concepts (e.g. classes and object sets) results in all sets of objects in
model system being modeled as classes, which has negative impact on implementation. UML analysts
often tend to create new object class for each collection of objects. The possibility of design some
object set having elements as instances of one or more existing object classes is ignored, because it is
not supported easy in UML.
5.3 UML and pure object programming languages and object databases
There is no doubt that UML is a strong tool for modeling that results in implementation in mixed
programming language. A typical UML project is programmed in C++ or in Java, and the solution
uses relational database server. The question is how UML supports pure object-oriented programming
in language such as Smalltalk and how it helps in database analysis and design for non-relational
object databases such as Gemstone. [2] Developers who work in these environments agree that UML
is not the most suitable tool, and they underline the following problems:
1. UML works with typed data models, which does not suit the dynamic purely object-oriented
languages. The same applies to object databases.
2. UML does not directly support some relations between objects (e.g., dependency between
objects and polymorphism without the presence of inheritance) that do not know mixed
languages but are important for pure object-oriented programming. In such cases, UML only
offers the possibility to define own stereotypes.
3. Most sophisticated object-oriented algorithms are based on cooperation of several objects in
an appropriate data structure. In UML, such solutions must be drawn into separate diagrams
describing separately the static data structure, the calculation mechanism, and the states and
transitions of the objects - by individual objects (one diagram cannot show mutual connections
between mutual operations, states and transitions of several objects).
If UML is to be a truly universal modeling language, which would certainly be beneficial, it should
better support other programming "cultures" than just programming style with objects in mixed
languages and with relational databases.

6. How does UML support project development phases?

If we want to/must use OOP in all phases of development of a software system lifecycle, it is
necessary to work with the concept of object. [11,12,14,15,16,19]
During system development it is necessary to gradually transform the model into a form that is
necessary for physical implementation of the system in the specific programming language.
Completion of the model in such a detail level that corresponds with the means of the environment

448 SYSTEMS INTEGRATION 2003

 CRITICAL ASSESSMENT OF THE ROLE OF UML FOR INFORMATION SYSTEM DEVELOPMENT

used (programming language, database, ...) can be viewed as the moment of completion of the object-
oriented design and possible commencement of implementation.
The concept of object, including its properties, changes in the course of development of the IS. An
object is understood differently by a programmer during the implementation in a specific
programming language, and by the customer, because for the customer, an object is a representation of
an entity of the real world that is within his scope of interest when formulating the problem. If system
modeling is commenced with software-oriented concepts we rid most interested parties at the
supplier's side of the ability to observe the project from its very beginning.
According to our experience, which we have incorporated in the proposal of our own methodology,
BORM [14,15,16,18,19], it is useful to divide the objects during system development as follows:
1. Software objects, used in the models of the final stages of IS development. These objects
contain concepts directly corresponding with the structures from concrete target programming
languages and environments. The models in this project phase shall also respect code
refactoring, code re-usability, and connection between the code and the so-called "legacy"
systems.
2. Conceptual objects, used in the models of the middle stages of the development when we need
to focus on the implementation of the problem formulation but we are not yet under the
restricting influence of the implementation environment. These objects contain basic concepts
of the object-oriented paradigm, such as object polymorphism, encapsulation, composing,
delegation, classification of objects according to different dimensions, object dependency,
classes and sets (collections) of objects, etc. It is true that some of the conceptual concepts are
identical with software concepts, but a significant portion needs to be transformed during the
transition to software objects because the current used programming languages (e.g., C++)
support the OOP concepts only in a limited manner.
3. Essential objects, also known as "Business objects". Models of these objects fill in the gap
between the problem formulation - i.e., the understanding at the customer's application level,
and the conceptual object model.
Based upon the above information, we can expect that the individual attributes and associations
between objects will change in the course of development of the IS and that each following element of
the model will probably have its predecessor from the previous phase, from which it will be derived by
some recognized knowledge. The concepts and associations of various UML diagrams, however, lack
any hierarchy. From the UML specification we do not know which concepts and associations belong
to which phase of the project development. Except few exceptions we do not know the relations
between them. An exception, for example, is the association between the objects and composing
between objects, because composing is defined as a special case of association - which can be also
understood as if composing could be derived from associations during model refinement. But both
associations are belong to the same diagrams. The association can therefore be used also in the
diagram describing a detailed design right before implementation, and we can also use composing as
early as in the models of the initial analysis.
6.1 Business objects
Business objects cannot be viewed only as initial simplification of future software objects, as the
common error of the analysts in UML. [2,6,9] The business model is simpler but - at the same time - it
contains concepts that are not directly supported by current programming languages. They have, for
example, different forms of object polymorphism, concurrent behavior etc.
In the work on major projects, IS analysts deal with the problem when not all system requirements are
known at the start of the project and the customer expects that discovery and refinement of it will be
part of the project. The problem is even more complicated because the function of the major systems
built has impact on the organizational and management structure of a company or organization where

SYSTEMS INTEGRATION 2003 449

 VOJTĚCH MERUNKA

the system is implemented - such as new or modified job positions, management changes, new
positions, new departments, etc. Therefore it is desirable to address also the change of all these related
structures during the work on information systems.
Process models composed from business objects represent a proven and actually used method of
analysis, design and implementation of organizational changes with active participation of the
customers and with related development of the information system. The UML tool set includes use-
case diagrams but if we need to model greater details we have to use either the diagrams from the so-
called "business extension UML", or - which, unfortunately, is more common - the diagrams meant for
representation of software structures such as object interaction diagram or class diagram.
6.2 Conceptual and software objects
In the UML tools, the "conceptual" and "software" objects are not distinguished, and the same
diagrams are used for these objects. In the analysis phase, however, we need to acquire the best
possible knowledge of the problem formulation, and the implementation details may cause trouble. On
the other hand, in the design phase we need to focus on implementing the outputs from the analysis
but we do not need to know some aspects of the reality modeled.
Underestimation of the model differences in the individual phases of development of an information
system results - in some instances of "real programmers" - in such a simplification where analysis
using UML is viewed as mere graphic representation of the future software code - typically in C++.
Analytic models are then used not to specify the problem formulation with the potential users of the
system who are also stressed by the complexity of the models that are presented to them. Projects in
UML very often suffer from this problem. In response to that, there are two "remedial" approaches
used in practice:
1. "Extreme programming" that - with regard to the topic discussed - can be characterized as an
approach that uses the qualities of mature development environments of object-oriented
languages for programming and testing of system parts. System modeling is limited almost to
zero and in quick - several days at the most - iterations, the problem formulation is specified
gradually according to software implementation of the system. Models and documentation, as
known from traditional methods, are prepared later, based upon the gradually formed code.
[8]
2. Domain Specific Methodologies. In their scope and procedures, these methodologies are
similar to traditional methods, although they work with concepts that are specific for a
particular area (e.g., telecommunications, chemical industry, ...). In their scope of use, these
methods achieve significantly better results because expression means of UML are
insufficient here, they make the analyst to transform the issue modeled into a condition that
does not allow capturing all the necessary details of the problem formulation. Such a
conceptual model is insufficient for the development of a code, and the developers must
therefore go back to the issue modeled and refine the system details. Then they consider
UML to be a little useful and unnecessarily laborious transition between the problem
formulation and implementation. [7]

7. Conclusion
The objective of this article is not to suggest that UML is a bad tool. On the contrary, UML is a high-
quality and rich tool. The fact that it is not perfect in all areas is not anything horrible. [17] UML is the
first successful attempt to introduce a reasonable object-oriented standard, and it is good to use it. We
only wanted to point out some of the problems that are connected with the use of the UML. We see a
danger that results in the fact that the UML is often taught and used incorrectly. The problems
discussed can be summarized as follows:
1. UML is not a method; it is "only" visualization tool.

450 SYSTEMS INTEGRATION 2003

 CRITICAL ASSESSMENT OF THE ROLE OF UML FOR INFORMATION SYSTEM DEVELOPMENT

2. UML is complicated - people who are not familiar with programming have difficulty learning
it.
3. Books on UML look at modeling through the eyes of software implementation and are
written in a language for programmers and particularly programmers in C++ or Java.
4. UML does not emphasize which concepts are to be used in the analysis phase and which only
in the design and implementation phase.
5. UML insufficiently supports purely object-oriented programming languages and object
databases.
6. UML insufficiently supports the design of graphic user interface.
7. UML does not really help in situations when problem is not completely formulated at the
beginning of a project.
8. Analysis in UML must not be a representation of the future source code of the application.
9. Although UML is supported by major companies and by important names, using UML does
not automatically mean better quality in comparison with other approaches.
10. It is necessary to read carefully the publications by the UML authors themselves and study
the published standard and not rely only on derived literature on UML.
The thoughts described in this article are a synthesis of our own experiences from object-oriented
modeling at Deloitte&Touche, from research activities [14,15,16], and from teaching the development
of information systems at the universities.

Bibliography
1. UML documents, http://www.omg.org or http://www.rational.com/uml
2. Ambler, Scott W: Be Realistic about the UML, http://www.agilemodeling/essays/ references.htm
3. Ambler, Scott W: Toward executable the UML, http://www.sdmagazine.com
4. Thomas, David: UML - The Universal Modeling and Programming Language?, September 2001,
from the library at http://www.ltt.de
5. Cook, Steve; Daniels, John: Object-Oriented Methods and the Great Object Myth, Object in
Europe, SIGS Publications, Vol 1. Nr. 4, 1994
6. Taylor, D., A. Business Engineering with Object Technology, John Wiley 1995.
7. Domain Specific Methodology - 10 Times Faster Than UML. Metacase Ltd., Finland,
http://www.metacase.com
8. Extreme programming approach, http://www.xprogramming.org and also another page at
http://www.extremeprogramming.org
9. Graham, Ian; Simons, Anthony J H: 30 Things that Go Wrong in Object Modeling with UML 1.3,
University of Sheffield & IGA Ltd. http://www.iga.co.uk
10. Goldberg A., Rubin K. S.: Succeeding with Objects - Decision Frameworks for Project
Management, Addison Wesley, Reading Mass, 1995.
11. Ambler S.: Process Patterns - Building Large-Scale Systems Using Object Technology, SIGS
Books 2000, ISBN 0-521-64568-9
12. Ambler S.: More Process Patterns - Delivering Large-Scale Systems Using Object Technology,
SIGS Books 2000, ISBN 0-521-65262-6
13. Molhanec Martin: UML – několik kritických poznámek, ve sborníku 28. ročníku Tvorba softwaru,
Ostrava 2002, ISBN 80-85988-74-7.

SYSTEMS INTEGRATION 2003 451

 VOJTĚCH MERUNKA

14. Knott, Roger P.; Merunka, Vojtěch; Polák, Jiří: Process Modeling for Object Oriented Analysis
using BORM Object Behavioral Analysis, in Proceedings of Fourth International Conference on
Requirements Engineering, Chicago 2000.
15. Merunka, Vojtěch; Polák, Jiří; Rivas, Luis: BORM - Business Object Relation Modeling, in
Proceedings of WOON - Fifth International Conference on Object-Oriented Programming, St.
Petersburg 2001.
16. Merunka, Vojtěch; Polák, Jiří: Úvod do metody BORM - Minikurz, in the proceedings of 5th
Annual National Conference, "Objekty 2000", Prague 2000, http://objekty.pef.czu.cz
17. Merunka, Vojtěch; Virius Miroslav: UML - Jazyk modelovací, unifikovaný, CHIP, Vogel
Publishing s.r.o., series of articles February - April 2002
18. Carda Antonín, Merunka Vojtěch, Polák Jiří: Umění systémového návrhu, Grada 2002, ISBN 80-
247-0424-2
19. Knott Roger P., Merunka Vojtěch, Polák Jiří: The BORM methodology: a third-generation fully
object-oriented methodology, Knowledge-Based Systems 3(10) 2003, Elsevier Science
Publishing, New York.

Summary
This document has been prepared as a critical response to how UML and its concepts are explained
and used in the practice. UML is currently among the most widely used modeling tools. Since 1996,
the objective of UML has been and is to replace older object-oriented methodologies by one
methodology that is a combination of the best of the older ones. It is the first successful attempt to
introduce a reasonable object-oriented standard. Among the problems of UML discussed in the paper
is the problem of complexity, the problem of modeling in different phases of development, the fit of
UML to pure object-oriented languages and databases, and the ability of UML for requirement
capture. The conclusions are based upon their own experience from the analysis and development of
object-oriented applications. This experience has been acquired at IT projects of Deloitte&Touche as
well as during teaching and university research activities in the area of object-oriented modeling.

452 SYSTEMS INTEGRATION 2003