6th International Conference on Telecommunications

Maja Matijašević and Alen Bažant (eds.)

ConTEL 2001
June 13–15, 2001, Zagreb, Croatia

UML Based Object-oriented Development: Experience with Inexperienced

Developers

Mario Kušek Saša Dešić Darko Gvozdanović

Mario.Kusek@fer.hr Sasa.Desic@etk.ericsson.se Darko.Gvozdanovic@etk.ericsson.se

Department of Telecommunications Research & Development Centre Research & Development Centre
Faculty of Electrical Engineering and Ericsson Nikola Tesla d.d. Ericsson Nikola Tesla d.d.
Computing, University of Zagreb
Zagreb, Croatia, HR-10000 Zagreb, Croatia, HR-10000 Zagreb, Croatia, HR-10000

Abstract implementation; uncontrolled change propagation or

insufficient testing.
UML is becoming increasingly important in modern Some of the problems and their causes can be
software development. Many articles describe UML avoided by implementing more rigorous development
features, but only very few of them discuss its process. Deployment of notation language, like
usability in real projects. This article discusses UML, might facilitate communication between all
features and usability of UML in software projects participants in the development process. These are
based on experiments and pilot projects. In the some of the reasons for UML utilization in software
analysis some differences between UML and SDL development. Present article analyses the aspects of
(Specification and Description Language) are UML use in the development process.
emphasized. This article deals with the impact of
UML on newcomers in the world of object-oriented Second section explains UML roots, causes and
software development. The experiment with two purpose. UML diagrams are explained in brief. The
groups of students (one trained in UML) was carried third section describes one software development
out. Their goal was to develop the solution for process that utilizes UML. Examples and aspects of
particular software system. Advantages and UML utilization are shown in the fourth section. In
disadvantages of UML are also commented with section five are described the experiments with UML
respect to user’s level of knowledge, application type and inexperienced developers. Section six gives the
and requirements. summary of the results.

1. Introduction 2. UML
World development and lifestyle increasingly depend The unified modeling language (UML) is a graphical
on software. Software-intensive systems, as language for visualizing, specifying, constructing,
technological achievements, as well as social and documenting software-intensive systems. UML
demands, are growing in size, complexity, provides a standard way of writing system's
distribution and importance. However expansion of blueprints, covering conceptual things, classes
these systems changes the limits of software industry written in a specific programming language, database
know-how. As a result, building and maintenance of schemes and reusable software components. It is a
software becoming increasingly complex. standard notation, used by everyone involved in
software production, deployment and maintenance.
Various software development projects fail in
different ways but they all share common symptoms. UML includes nine diagrams for describing the
Some of them are: inaccurate understanding of end- system:
user needs; inability to deal with changing
o Class diagram describes a set of classes,
requirements; software that is not easy to maintain or
interfaces and their relationships. It shows the
extend or late discovery of serious project flaws.
view of the system’s static design. This diagram
Analysis of the symptoms reveal that their root
is very useful in modeling object-oriented
causes are: ad hoc management of the requirements;
systems.
ambiguous and unambiguous communication;
overwhelming complexity; undetected
inconsistencies in the requirements, design and

55
 M. Kušek et al.: UML Based Object-oriented Development: Experience with Inexperienced Developers

o Object diagram shows a set of objects and 3. Development process

snapshots of instances of the things found in
class diagrams. UML is a modeling language rather than a method.
For a successful project, however, modeling language
o Use case diagram shows a set of the use cases, is not enough. There are several developing methods
actors and their relationships. This diagram is (e.g. Extreme programming and Feature Driven
especially important in organizing and modeling Programming). Creators of UML have developed
behavior of a system. Rational Unified Process (RUP), which mostly
utilizes UML and incorporates best practices of
various projects. This section briefly explains
Rational Unified Process.
Rational Unified Process is an iterative and
incremental development process (Figure 2.).
Software is carefully being built up through the
process, step-by-step and functionality-by-
functionality. Subset of functionality is designed,
implemented and tested after every iteration,
During inception, first meetings are held to define
project goal and scope and to make rough cost-
benefit estimate).

Figure 1. Example of a use case diagram

Elaboration

Transition
Inception

o Sequence and collaboration diagrams are Construction

interaction diagrams, which describe interaction
between the objects. They show their 1 2 3 ...
relationships, including messages between the
objects. Interaction diagram explains dynamic Figure 2. Rational Unified Process
view of the system. Sequence diagram
emphasizes the time order of messages. Elaboration specifies more details about
Collaboration diagram emphasizes structural requirements and technologies involved, and
organization of the objects in interaction. Both comprises high-level analyses and design for creating
are isomorphic, meaning that a sequence baseline architecture. Plan for the construction phase
diagram can be transformed into collaboration is worked out at this phase too.
diagram and vice versa. Construction phase consists of iterations; each
o Statechart diagram shows a state machine built, tested and integrated production-quality
consisting of states, transitions, events and software satisfying a subset of project requirements.
activities. It addresses dynamic view of the The delivery may be external, to early users, or
purely internal. Iterations comprise all usual life
system. This diagram is very important in
cycle analytical steps, design, implementation and
behavior modeling.
testing.
o Activity diagram is a special kind of statechart Transition includes beta testing, performance
diagram. It emphasizes flow from the activity to tuning and user training. Optimization reduces clarity
the activity within the system. It is very useful and extensibility of the system in order to improve
in tracing concurrent activities in the system. performance.
o Component diagram describes organization and
dependencies among the components. It is
related to class diagrams with respect to
4. UML in practice
mapping the component to one or more classes,
interfaces, or collaboration.
o Deployment diagram explains configuration of 4.1. Experimental
run-time processing nodes and of their UML system modeling was tested experimentally.
components. It shows static deployment view of Two software systems had to be designed using UML
architecture. and the appropriate tool. The results were supposed
to show UML usability in various types of systems
and required levels of detail. For that purpose, we
launched two projects.

56
 M. Kušek et al.: UML Based Object-oriented Development: Experience with Inexperienced Developers

The first one, called JAMES, was the communication Requests

program based on the specific protocol. The program Mobile
Agent Processing
was divided into three main parts (Figure 3): Management Node
Node
o USI (User Side Interface) - control procedures
for the user side, Requests
Link
o NSI (Network Side Interface) - control
Agent’s way
procedures for the network side, and Requests

o GUI (Graphical User Interface) - graphical

interface. Figure 4. Bond: Model of the system
The user of that application had to be able perform
basic communication actions: Unlike JAMES project, BOND was architecturally
highly demanding, while behavior was left to the
o initiate connection establishment; implementers.
o communicate through file transfer, sending and It was not that these two kinds of projects enabled
receiving the messages and the analysis of UML utilization only, but also of the
o release the connection. potential use of the whole chain of formal methods,
such as UML to SDL converter followed by SDL
design.
That kind of the application was not demanding in
architectural design, but required precisely defined 4.2. Results
behavior. Exactly that situation was not suitable for
UML supported design, intentionally chosen to be the Having designed those two systems, we have arrived
part of our experiment. to the following conclusions: UML is superior in
early phases of development. Requirement analysis is
heavily supported, but the two types of diagrams
differ. Use-case and sequence diagrams provide
network everything needed for capturing all systems’ features,
User 1 User 2
yet simplicity must be preserved for the customer to
NSI
NSI

USI USI
understand the designed behavior. Misunderstanding
between the designers and customers is avoided with
the use of UML, but misunderstanding itself usually
Figure 3. James: Model of the system causes the projects fail. Negotiating practice with the
customers (who are frequently prone to changing
The second project, called BOND, was expected to
their mind) has not been very successful and should,
result in a distributed processing simulator (Figure 4).
therefore, be adjusted to UML. Another good side of
The distributed processing system could be, for
having use-cases is that they are valuable source for
example, a Web site with the cluster of Web servers.
creating test-case scenarios in testing and validating
The main purpose of the project was aimed to create
partly or fully implemented systems.
functional prototype of the simulation system. All
nodes in the system received the requests. Those UML diagrams give the means to express ideas, but
from highly loaded nodes could be re-scheduled to ideas come from experience. Less experienced
other nodes. designers may not understand the background of a
particular design of a senior designer, but they can
The prototype was extended by mobile agents
understand it and are definitely able to improve
responsible for the system maintenance and
themselves on it. UML helps in acquiring object-
monitoring. The agents collected the data about
oriented way of thinking. Less experienced designers
remote sites and saved them on the management site.
very often say: “I can’t express it with UML”, but in
In order to run the simulation, network topology and most cases this means there is something wrong with
load distribution had to be defined. Load distribution an object-oriented design. Hence, using UML is very
was specified as the incidence of job arrival per node. helpful to all categories of designers.
All that could be done through GUI. During
Unlike with SDL the developers find UML easy to
simulation, the user could change simulation
use in that it has no strict formal structure or
parameters (network topology and load distribution),
terminology, although some basic rules must be
view the system statistics and analyze overall system
respected. In SDL usage, the prerequisite is higher
performance in the course and after simulation.
level of expertise. As expected, experienced users
were more efficient in describing and designing the
system. Previous knowledge of the object-oriented
system development was very helpful in using UML.

57
 M. Kušek et al.: UML Based Object-oriented Development: Experience with Inexperienced Developers

UML was helpful for understanding and developing information from UML is kept and transferred into
object-oriented thinking. SDL. Consequently, visual design along with all the
possibility of system verification and validation
UML has tackled another important issue. Parallel
offered by the tools, remains available to designers.
design of different parts of the system is almost
obligatory, except of the very simple ones. System design with UML is very dependent on the
Precondition for proper system division comprises type of the system under development. The
two things: experiments support the conclusions arrived at. UML
is much more appropriate for designing the systems

definition of relatively independent subsystems,
having complex static architecture (e.g. data and
having appropriate functionality, and
GUI-related systems).

ensuring full collaboration of these subsystems,
SDL, on the other hand, is more appropriate for the
once they are designed.
systems with much internal communication. GUI
UML addresses them by packages and interfaces. systems and all systems involving a lot of
There are no package diagrams, but a designer can communication with the outer world can be
use class diagrams instead. By doing so, not only developed with SDL, although it is more difficult
implementation but also design is hidden behind the than with UML. The proposed solution is a
interfaces, facilitating subsequent changes and combination of UML and SDL. Figure 6 gives an
maintenance. It is even possible to develop particular example of such a design process that utilizes this
parts of the system using different tools (without any approach (Figure 6).
UML), and than to make reverse engineering into
The applied UML tool has code generators for
UML design (Figure 5). This particularly refers to
several most interesting programming languages.
GUI design. Given that redesigning and adding new
Preconditions for code generation are completeness
functionality is often the case (not usual with a brand
and correctness of the model. Hence, prior to code
new system), using legacy code can make substantial
generation there is always an automatic check of the
savings.
system design.
Major disadvantage of UML design in code
Agent

1 1
LocalManager
GlobalManager generation is the loss of much information. Code
generators use only class diagrams. Complete
s tartSimulation()
s topSimulation()
analyseOverallNetworkPerformance() updateMatrixElements(matrix)
updateLBMethods ()
setLBMethod() startModules() updateTopology()
moveToNextNode() stopModules()
startBalancer() openNetworkStructureEditor()
openLoadMatrixEditor()
stopBalancer() openLBMEditor()
1 getLoadInfo()

behavior has to be implemented manually. In some

openStatisticsWindow(s tats)

1 1
1
1
Database
Link
1

cases, like in JAMES project, most of the work is

connec tNode1
connec tNode2 1 updateStatistics()
T opology capacity getStatistics()
* Topology 1
nodes nodes LBMethods
links 1 links 1
lbMethods
addLink() LoadMatrix
addLink()

done through sequence and statechart diagrams. Class

addNode()
addNode() 1
removeNode() loadVector
Node removeLink() 1
removeNode() 1
removeLink() name *
physic alName
LBMethod

name

diagrams are very simple, representing static relations

fileName
s elected

Reverse
Engineering rather than dynamic behavior. In our case, code
Legacy generation is practically absent. However, it does not
Code
mean that all other diagrams are worthless. They are
used in describing and documenting the system.
Figure 5. Reverse engineering Otherwise generated code is very clean, readable,
(GUI and legacy code) well structured and documented. Notes added to
UML diagrams are included into generated code as
Obviously, UML handles architectural problems comments. Code is clearly classified into the sections
well. Defining behavior is its weaker side. There is a for attributes, constructors, and user defined methods.
whole lot of diagrams (sequence, collaboration, Another practical feature is that the generated code
activity and state-chart diagrams), but the designers clearly reflects the system design (relationship
can use them for their own needs only. They do not between classes, their associations, role names, etc.).
contribute at all to automatic code generators.
Capturing behavior of the mentioned communication UML tools in the development and system analysis
application is worthless in automatic code generation, help us to test the system manually. SDL tools,
but not in documenting the way it works. The though, have powerful capabilities for automatic
designers would definitely prefer the code to give inspection of the newly created systems. UML tools
some reflection of the captured behavior. do not support processes of validation and
Consequently, UML to SDL (Specification and verification available by SDL tools. They merely
Description Language [4]) converter offered by some provide basic structural check. This is another good
vendors is a big step forward. SDL is suitable for the reason for the use of UML and SDL approaches
in-depth system design and verification. Also, SDL is (Figure 6).
also successful in expressing system dynamic
behavior. With the use of a translator, a lot of

58
 M. Kušek et al.: UML Based Object-oriented Development: Experience with Inexperienced Developers

Figure 6. Software design process supported by UML/SDL combination

attributes. Judging from the amount (quantity) of the

5. Experiments with inexperienced developed documents, UML was apparently
developers extremely supported in designing (especially in
meeting the requirements and understanding the
overall system architecture).
5.1. Experimental
Many articles discuss great features of UML, but just
a few of them describe experimental results with
UML in real-life projects. It is hard to quantitatively
present the advantages of UML over common way of
software development. An experiment with a group
of students was carried out to demonstrate UML
usefulness. All students attended the courses (during
their university education) on C++, SDL basics, Java
basics and C.
The students were divided in two groups. The UML
group attended UML presentation and the non-UML
group did not. Both groups were divided in three
subgroups. Each subgroup was told to design a small
system. The systems were: Web service for exam
appliance, cache machine and automatic door
opening system. The non-UML group, having no
information about UML, had to design the system
using previous knowledge and sense. The key issue
was that nobody was experienced in the object-
oriented system design and development. Figure 7. Flow diagram created by Non-UML group

Implementation as a final goal of every development

5.2. Results process requires that many details be defined. The
It is hard to quantitatively measure the design and to level of detail was a parameter in comparing two
compare the progress of two different groups. One of groups and their work. The designs of the non-UML
the measurement parameters was the amount of group were on a very high level of abstraction and
created diagrams and materials. The non-UML group with few details. The programmer, responsible for
made a few rough descriptions of the system implementation, could not build a system with such
operation and some flow diagrams (Figure 7). Most input documents.
of the time they were trying to understand the internal On the other hand, the UML group used class
structure and architecture of the system. The UML diagrams containing many details and it prepared a
group was better. It created mostly use case, very good base for implementation. Other created
sequence (Figure 8) and activity diagrams, and even documents are also useful for system visualization
class diagrams that show classes, methods and and understanding of its function.

59
 M. Kušek et al.: UML Based Object-oriented Development: Experience with Inexperienced Developers

are shown with respect to several viewpoints of

development process. The results per areas are scored
1-10. Predicted results for full UML usage (UML by
definition) are added to the graph to emphases UML
superiority.

Requirements capture
10

8
Testing 6 Amount of materials

Figure 8. Sequence diagram created by UML group 2

0

The non-UML documents clearly show that the group Visualization Level of provided details

was slightly confused and disoriented. Unlike them,

the UML students were lead by UML diagrams and
stayed more concentrated and effective. The logical System dividing Procedure and process

flow of diagram usage helped maintain the right UML by definition

direction of design efforts. UML group
Non-UML group
The non-UML group failed to determine the system
classes, their methods and attributes. The UML group Figure 10. Summary of experimental results
succeeded by using powerful tools, such as sequence
and class diagrams (Figure 9). In that way, they were 6. Conclusions
driven to finding appropriate solution for system
classes and associations among them. UML offers many advantages. New projects have
better survival prospects with UML. The experiment
At the early stages of development, it is very has shown that UML has a very strong impact on
important to examine various scenarios and possible newcomers and that it can markedly increase their
irregularities in the system. The analysis employing work and design capabilities.
case and sequence diagrams can help find, develop
and explain the system states, where more then one Utilization of UML tools can additionally improve
option is possible. Unfortunately, UML group payed software design process. With these tools,
no attention to that. It was probably due to documentation process can be included into
participating in the UML project for the first time, or development process, because the documentation is
time restriction. created during design time.
Practical application of UML proved to be
successful. Requirement analysis and architectural
design benefit from UML. Additionally, UML to
SDL translation will also strengthen the process of
the systems’ dynamic structure design.

References
[1] G. Booch, J.Rumbaugh, I. Jacobson, The Unified
Modeling Language Use Guide, Addison-Wesley,
1999.
[2] M. Fowler, Kendall Scott, UML Distilled, 2nd edition
Addison-Wesley, 2000.
[3] P. Kruchten, The Rational Unified Process, 2nd edition
Addison-Wesley, 2000.
[4] J. Ellsberger, D. Hogrefe, A. Sarma, SDL Formal
Figure 9. Class diagram created with UML tool Object-oriented Language for Communicating
Systems, Prentice Hall 2000.
The non-UML group used flow diagrams that helped [5] O. Laitenberger, C. Atkinson, M. Sclich, K. El Amam,
system visualization. It is known to be a very useful An Experimental Comparison of Reading Techniques
method for facilitating development process. Like for Defect Detection in UML Design Documentation,
flow diagrams, UML diagrams help visualize the Fraunhofer, Kaiserslautern, 1999.
system. Flow diagrams visualize only behavior of the
system, whereas UML diagrams visualize all its
aspects.
Results of the experiment can be summarized in one
figure (Figure 10). The achievements of both groups

60