Embed Size (px)
Citation preview
INTEGRATION OF INFORMATION SYSTEM MODELS BY USING LAYERS AND ELISION
Zoltán Farkas
Bachelor’s thesis
JYVÄSKYLÄ POLYTECHNIC
1
CONTENTS
1 INTRODUCTION.....................................................................................................4
2 INTEGRATING VIEWS IN UML..........................................................................6
2.1 Definitions ............................................................................................................6
2.2 The axiom of the modeling ..................................................................................6
2.3 Integration ............................................................................................................7
2.4 The diagrams of UML..........................................................................................8
2.4 Dimension of views..............................................................................................9
2.5 Meta-data of interrelationship ............................................................................11
2.5.1 Automatic transformation............................................................................11
2.5.2 Visualization................................................................................................12
3 COLLECTING DATA TO KNOW THE NEEDS OF THE USERS.................13
3.1. The goal of collecting data ................................................................................13
3.2 The methods of collecting data ..........................................................................13
3.3 The subjects of the data collection .....................................................................14
3.4 Analysis of information collected ......................................................................15
3.4.1 Modeling needs of the subjects ...................................................................15
3.4.2 Tool-using needs of the subjects .................................................................20
4. THE ISVIS PROTOTYPE ....................................................................................24
4.1 Multiple windows vs. layers in three dimensional (3D) space...........................24
4.2 Overview, zoom, details .....................................................................................27
4.3 Automatic arrangement ......................................................................................29
4.4 Navigation ..........................................................................................................32
5 USABILITY OF THE PROTOTYPE ...................................................................34
5.1 Definitions of the usability engineering .............................................................34
2
5.2 Methods of the usability engineering .................................................................34
5.3 Results of the experiment ...................................................................................36
6. DISCUSSION, LIMITATIONS, AND FUTURE WORK..................................41
REFERENCES ...........................................................................................................43
3
FIGURES
Figure 1 The taxonomy of structure and behavior diagrams (UML2 2003, Figure 464)
................................................................................................................................8
Figure 2 Dimension of views (Egyed 1999, Figure 8) ...................................................9
Figure 3 Using models for designing information system ...........................................16
Figure 4 Realized advantages of creating models ........................................................16
Figure 5 Realized disadvantages of using models........................................................17
Figure 6 Knowledge of the subject about the diagrams of UML.................................19
Figure 7 Utilized devices for modeling........................................................................21
Figure 8 Disadvantages of the modeling tools .............................................................21
Figure 9 Advantages of the modeling tools..................................................................22
Figure 10 Frequency of using modeling tools..............................................................23
Figure 11 Multiple windows ........................................................................................25
Figure 12 Layers in 3D space.......................................................................................26
Figure 13 Overview......................................................................................................27
Figure 14 Zoom and filter ............................................................................................28
Figure 15 Details on demand........................................................................................28
Figure 16 The behavioral and the structural parts of the space....................................30
Figure 17 The sub-space of the parent diagram ...........................................................30
Figure 18 Middle point of the sub-space......................................................................31
Figure 19 The efficiency of finding diagrams..............................................................37
Figure 20 The efficiency of the related diagram finding..............................................38
Figure 21 Automatic arrangement without intelligent zoom .......................................38
Figure 22 Automatic arrangement with intelligent zoom ............................................39
4
1 INTRODUCTION
”As the complexity of the system gets greater, the task of building the
software gets exponentially harder.”
Martin Fowler (Fowler, 2002)
What makes information systems so complex and so difficult to grasp is the fact that
the amount of information loaded onto a single person is vastly exceeding the
capabilities of the human mind. We are not able to handle thousands of pieces of
information at any given time. Instead, it seems that human short-term memory is
quite limited in that respect. The 7±2 rule is a well-known example. This rule states
that the human mind can usually only handle 7 distinct things (plus or minus 2) at the
same time (Miller, 1956). To develop huge information systems that contain much
more than 9 pieces, we have to utilize the concept of modeling. Modeling is one of the
fundamental ways in which human beings understand the world.
The standard modeling language of software designers is the UML (Unified Modeling
Language) “for specifying, visualizing, constructing, and documenting the artifacts of
information systems” (Booch, Jacobson & Rumbaugh, 1997). The latest version of
this language is the UML 2.0 (UML2), which provides various diagram types for
describing a system from different perspectives or abstraction levels. Hence, various
UML models of the same system are dependent and strongly overlapping. The
multiple diagrams often lead to inconsistencies between these diagrams. Because of
this, the designers using information system models must integrate and maintain
information among multiple and physically separate diagrams.
There are several tools that support the managing numbers of diagrams and check
their consistency but those tools do not completely meet the requirements of the
software designers. The existing modeling tools display the diagrams independently
and their contents are not fully integrated with the contents of the other views to
ensure their conceptual integrity. Numerous visualization techniques can support this
integration and decrease the cognitive efforts of the software designers in reading
diagrams.
5
The modeling tools used nowadays do not adequately represent the connection
between diagrams and related elements contained by different diagrams. Huotari et al.
(Huotari, Lyytinen & Niemelä 2003) showed that connecting lines with DFD and
ERD on large screens improves the search accuracy when compared to multiple
separate diagrams. Connecting lines might be utilized with UML diagrams and other
visualization techniques can help with the integration of information system models.
The existing modeling tools use multiple windows to represent information system
models. Using this technique, the size of the windows may be too small or a window
may overlap with another. In both cases, this might cause relevant information to be
hidden that may slow down the search performance of the software designer and result
in reading errors that later cause omissions and inconsistencies in the final designs.
Several techniques exist which can avoid this problem, such as intelligent-zoom,
elision, and the use of 3D space instead of a multiple window.
The remainder of the thesis is organized as follows. In section 2 the reason for and the
importance of the integration of views are reviewed. In order to be able to evaluate an
information modeling tool, the usability engineer needs to know what the user really
wants and needs. In the next section, the method and the results of the information
collected are described. In section 4, the ISVIS prototype, in which several
visualization techniques are implemented, such as connecting lines, bushing-and-
linking, elision, automatic arrangement, navigation methods and intelligent-zoom, is
presented. In section 5, an experiment is formulated. The results of the experiments
are used to evaluate the usability of the prototype. In the final, section some
conclusions are drawn and implications of the research are discussed.
6
2 INTEGRATING VIEWS IN UML
” No model is correct, but some are useful”
Albert Einstein
2.1 Definitions
A model is an abstraction of reality. The model can contain diagrams, which are a
“graphical presentation of a collection of model elements, most often rendered as a
connected graph of arcs (relationships) and vertices (other model elements)” (UML 2).
Although the diagrams show the information system models from different
perspectives, a number of views are needed for displaying the levels of abstraction
from the same viewpoint. The IEEE Draft Standard 1471 (IEEE 1471) refers to a view
as something which “addresses one or more concerns of a system stakeholder.” The
stakeholder is an individual or a group which shares concerns or interests in the
information system (e.g. requirement managers, system engineers, users, customers,
etc.). “A view is a piece of the model which is still small enough for us to comprehend
and which also contains relevant information about a particular concern.” (Egyed,
1999)
2.2 The axiom of the modeling
A generally accepted axiom of modeling states that views should represent as little
as possible explicitly while still supporting the solution of the problem at hand.
Unnecessary representation in a view simply makes it more difficult to focus on the
important aspects of the problem. This is consistent with the viewpoint of Alabastro et
al. (Alabastro, Beckmann, Gifford, Massey & Wallace, 1995) that diagrams
“significantly increase the speed and quality of model development” by focusing
attention on what is absent and important (and should therefore be added) and what is
present and unimportant (and should therefore be eliminated). All of this is to say that
7
an ideal view will have one and only one entity for each relevant entity in the system
modeled, and that for each relevant relationship between entities, there will be one and
only one relationship in the model. The relationships in both worlds should behave
similarly.
Naturally, an information system model should contain enough information so that it
may be useful throughout the entire development life-cycle. Each task and each
stakeholder may need different views which show the system from different
perspectives, hence, several entities and relationships can be contained in more
diagrams. (Nuseibeh, 1996) wrote that “multiple views often lead to inconsistencies
between these views – particularly if these views represent, say, different stakeholder
perspectives or alternative design solutions.” Since a view represents only one aspect
of the system to be modeled, multiple views are meant to be together in order to
fully describe the system. However, we also need those views to be different (and
independent) enough to provide useful meaning to their respective stakeholders.
Therefore, what we need are views which are independent and can stand on their own,
but with their contents being fully integrated with the contents of the other views to
ensure their conceptual integrity. Thus, we need view integration.
2.3 Integration
The term Integration is used in a way, to determine the semantic integrity of
development models (or views, diagrams, etc.) in order to evaluate or improve quality
aspects of the development model. Desirable qualities we would like to see in a
development model (or its instances, such as the product or domain models) are
consistency, completeness, correctness, and so forth.
According to Zowghi and Gervasi (Zowghi and Gervasi 2003) consistency refers to
situations where a specification contains no internal contradictions, whereas
completeness refers to situations where a specification entails everything that is
known to be “true” in a certain context. From a formal point of view, correctness is
usually meant to be the combination of consistency and completeness. From a
8
practical point of view, however, correctness is often more pragmatically defined
as satisfaction of certain business goals.
2.4 The diagrams of UML
UML uses structural and behavioral object models. Structural models (also known as
static models) emphasize the structure of objects in a system, including their classes,
interfaces, attributes and relations. Behavioral models (also known as dynamic
models) emphasize the behavior of objects in a system, including their methods,
interactions, collaborations, and state histories.
The choice of what models and diagrams one creates has a profound influence upon
how a problem is attacked and how a corresponding solution is shaped. Abstraction,
the focus on relevant details while ignoring others, is a key to learning and
communicating. Because of this:
• Every complex system is best approached through a small set of nearly
independent views of a model. No single view is sufficient.
• Every model may be expressed at different levels of fidelity.
• The best models are connected to reality.
In terms of the views of a model, UML defines graphical diagrams (See Figure 1).
Figure 1 The taxonomy of structure and behavior diagrams (UML2 2003, Figure 464)
9
These diagrams provide multiple perspectives of the system under analysis or
development. The underlying model integrates these perspectives so that a self-
consistent system can be analyzed and built. These diagrams, along with supporting
documentation, are the primary artifacts that a modeler sees, although the UML and
supporting tools will provide for a number of derivative views.
2.4 Dimension of views
Egyed (Egyed, 1999) divided views into three major dimensions: horizontal, vertical
and process (See Figure 2). The vertical and horizontal dimensions are also often
referred to as layers and partitions, whereas the process dimension reflects the life-
cycle (time). These three dimensions are briefly described in the following.
Figure 2 Dimension of views (Egyed 1999, Figure 8)
10
The vertical dimension reflects the system decomposition. Usually, higher levels
(layers) show the system in a more abstract fashion, whereas lower levels show the
system in more detail. Each layer should represent a complete system; however, it
might not do so in one diagram. Mismatches between vertical views are, therefore,
mismatches where one layer does not represent the same interrelationships (within and
between diagrams) as another layer. In UML, system decomposition is primarily
achieved through class/object diagrams and associated packages. Other diagrams,
such as state diagrams, do not reflect the system decomposition. They may, however,
still be used in each layer to repeat the same modeling constructs in an increasingly
detailed and abstracted form.
Horizontal views are frequently further divided into static (structural) and dynamic
(behavioral) views. The difference in these two groups is related to the presumed
execution time. Dynamic views represent the system (or more likely a partition of it)
at a particular point of time or time interval. For instance, object diagrams show the
objects that exist at a particular time; sequence diagrams show the calling
dependencies between various objects during a time interval. Dynamic views often
represent samples of the state or interaction of the system and its components during
their execution. Class diagrams, on the other hand, are static representations of all
allowed dependencies of a system and its components throughout the execution.
Views in that category represent more general aspects of the system behavior and their
constructs are always applicable.
Although process view integration is often ignored, it is actually very important. The
integration over time (or process integration) reflects the integration of product
artifacts during the life cycle. It does not mean making sure that a process model is
followed consistently but making sure that the changes a product artifact goes through
over time are captured. This activity is also often referred to as version control or
configuration management but it is also another dimension of the view integration
problem.
11
2.5 Meta-data of interrelationship
To integrate different diagrams, meta-data is needed. This meta-data describes how
the different diagrams are related to each other and how the elements of those
diagrams are related to each other. UML 1.x is not quite complete and its definition is
ambiguous in many places and many interrelationships between views are not defined.
The UML 2.0 defines the missing interrelationships but this version is under the
finalization process and it is not in widespread use yet.
2.5.1 Automatic transformation
Numbers of interrelationship can be found by automatic transformations. The issue of
transformation is often considered the core of view integration. Although this is not
entirely true, view transformation nevertheless constitutes a major challenge because
the modeling information provided by one view is not readily compatible with other
views. ”Thus, we need transformation to translate views in such a way so that their
elements can be shared, exchanged, or compared (same types of model elements and
the same level of abstraction).” (Egyed, 1999)
Egyed implemented a tool, which automatically integrates architectural views in
UML. UML/Analyzer supports model transformation and consistency checking and
also implements the abstraction technique discussed in (Egyed, 2002).
Selonen et. al. (Selonen, Koskimies & Sakkinen, 2001) studied the relationships of
different diagrams types in UML, and transformation operations that are based on
those relationships. A transformation operation takes a UML diagram as its operand
(source diagram), and produces another diagram of another type as its result (the
target diagram). They divide the transformations into the following categories:
• Full transformation: The target diagram contains (almost) the same information
as the source diagram.
• Strong transformation: The target diagram contains a significant amount of
information and is close to a diagram that a person might have drawn by hand for
the same part of the system model.
12
• Supported transformation: The transformation is useful when supported by
additional information given as tagged values or stereotypes. Without such support
the transformation becomes generally weak or even useless.
2.5.2 Visualization
The rules and constraints that are implemented in those works for automatically
transforming and identifying mismatches are not guaranteed to yield correct results
under all circumstances. Thus, mismatches that are identified with automatic
techniques must be regarded merely as potential mismatches but not as factual ones.
Another restriction of those works is the issue of mismatch resolution, which needs
feedback from the software designers.
Several visualization techniques can help integration. The integration of information
across multiple diagrams has been studied in the context of diagrammatic reasoning
(Kim, Hahn & Hahn 1999). By analyzing the verbal protocols of the subjects, they
found that diagram presentation significantly influences information integration.
Huotari et. al. (Huotari, Lyytinen & Niemelä 2003) studied the impact of visual
integration techniques and they found that elision and connecting lines decrease the
cognitive efforts of the designers in reading multiple diagrams. The results of their
work were utilized for developing the ISVIS prototype.
13
3 COLLECTING DATA TO KNOW THE NEEDS OF
THE USERS
”if you can’t measure it, you probably can’t manage it.”
Deborah Hix (Hix and Hartson, 1993)
3.1. The goal of collecting data
In order to be able to evaluate an information modeling tool, the usability engineer
needs to know what the user really wants and needs. The first step of the evaluation
was to determine the user task and the level of expertise of the test users. The
modeling skill and the tool-using skill of the users were measured because both of
them are needed for information system modeling today.
3.2 The methods of collecting data
There are several ways in which information can be gained from the intended users.
These methods will elicit information about the user group or the user task and can be
used for gathering information about both. Task analysis is geared to eliciting
information about the task. Sometimes it is difficult to separate user characteristics
from the task and the usability engineer should bear this in mind when carrying out
activities to elicit information about task and user group characteristics.
Gould (Gould 1988) recommends talking with users. He believes that discussions
with users can bring to light all sorts of information about the system and the way in
which it needs to operate. Users are not expert designers but they do have opinions
about whether or not a particular design will work in their environment. They can
often give insights into the current system that designers fail to see. It is possible to
learn a lot about what users want simply by listening to what they have to say. There
14
is another advantage to talking with users in that they are made to feel part of the
process of designing and building a system.
The author of this thesis gathered information about current work practices and
opinions on the system by talking and by the use of a questionnaire. Questionnaires
are a good source of subjective responses (a measure of user attitude) but they are less
reliable when it comes to collecting objective data. They produced a vast amount of
data that was useful for the analysis. The interviewer asked questions and filled in the
answers as the subject responded. The advantages of interviewer-administered
questionnaires are that there is a control of the returns of the questionnaire and there is
an opportunity to explain to the subject what the question means.
Both open and closed questions were used. The open questions were good for
gaining information because they allowed the respondents to answer in any way they
chose. The problem with open questions was that they produced too much data that
was not easily analyzed because it was so diverse. For example, an open question was:
Why do you use models when you design information systems?
The closed question limited the subject’s response to a given range of possible
answers. It was much easier to classify the responses to closed questions and,
therefore, to analyze the data but the possible answers could affect the answer. A
closed question was: Which modeling tool(s) have you used?
3.3 The subjects of the data collection
The subjects of the questionnaires were undergraduates at the Jyväskylä Polytechnic
and they were expected to have a Bachelor of Engineering’s degree in the field of
Information Technology. Each student had experience in designing and implementing
information systems because they had worked on projects during their studies. The
subjects were from four different countries (Czech Republic, Hungary, Poland and
Slovak Republic) and they had different majors and minors at their home universities.
In order to make the software product usable we need to know what the task is that the
user will be performing with them. The first part of the interview contains questions
15
about the modeling habits of the subject. Those questions provided a method for
discovering
• whether or not the subjects use models when they design information system
models,
• if they use them, why they do so,
• what they guess the advantages and disadvantages of modeling are,
• what kind of notation they use,
• why they use it.
The second part of the interview addressed the tool-using habits of the subjects. The
interviewer collected information regarding:
• whether the subjects model on paper or use tools,
• when they use which one,
• what the advantages and the disadvantages of modeling on paper and with using
tools are,
• whether the subjects prefer the dedicated tools or the drawing tools for modeling,
• what the level of expertise of the subjects is in using tools.
3.4 Analysis of information collected
Although the number of the subjects (14) was not enough to prove the hypotheses, it
was a suitable basis of the subsequent experiences which will be conducted next
March. (See Section 6)
3.4.1 Modeling needs of the subjects
Half of the subjects often use models when they develop information systems. The
other half utilizes modeling only sometimes or very rarely. (See Figure 3) Each
subject knew the importance of modeling for information system development and
he/she could mention advantages of modeling. Open questions were created for
16
asking why the subjects use or feel using models important. The reason is that the
possible answer might affect his/her real answer. Almost everyone can see the
advantages of modeling if the possible answers are shown to him/her but it is
important to know what people really think is an advantage, without being shown. The
answers of the subjects were different but they can be divided into seven main
categories. (See Figure 4) During the interview each subject referred to modeling as a
tool that simplifies modeling, and it must be utilized to create complex systems.
0
1
2
3
4
5
6
7
8
Often Sometimes Rarely
Nu
mb
er o
f th
e su
bje
ct
Figure 3 Using models for designing information system
54
12
12
3
8
0
2
4
6
8
10
12
14
Nu
mb
er o
f th
e su
bje
cts
Communication
Show the relationships betweenthe model elementsSimplifying the developing
Support the changing the system
Support the documentation
Support the implementaion
Support to develop complexsystems
Figure 4 Realized advantages of creating models
17
Although all subjects found modeling important, only a few of them used it often.
One main reason for this is the lack of education on modeling in schools. The majors
of the subjects were software engineer and mathematician, electrical engineer,
software developer, information technologist, and physicist, but only four students had
information system modeling knowledge from school. 78.6 percent of the subjects
used their own notation because they had not learnt any standard modeling language,
or they had not become familiar enough with it. Each subject wanted to learn UML
because they thought it was necessary for designing complex systems.
Several disadvantages of modeling were mentioned by the subjects as well. The
reason for using open questions for collecting this information was the same that was
described above. The answers addressed four main issues as the weakness of
modeling (See Figure 5).
7
6
4
2
0
1
2
3
4
5
6
7
8
Nu
mb
er o
f th
e su
bje
cts
Learning a modelinglanguage is difficult
Need a huge amount of(wasted) time
The modeling languageis too complicated
The models also mustbe changed if thesystem changes
Figure 5 Realized disadvantages of using models
One main advantage of object-oriented software development is the reusability of the
system components, which was and probably still is one of the strongest drivers of the
object-oriented movement. The subjects found modeling to be a process, which wastes
their time. All of them threw away the models created during a project because they
did not think them reusable. They preferred to create new diagrams to reuse the
diagrams of a previous project. It takes time to understand the diagrams again, which
18
were created long time ago, but it would take even more time to recall the
connection between different diagrams if the interrelationships were not stored. The
integration of an old model into a new system is always a hard task, because it can
cause inconsistency and currently, consistency checking is probably still the largest
development activity that is done almost entirely manually. Modifications of the
models during software development were also reflected as an inefficient option. The
modification of one element can require checking of several elements and
modification of a whole part of the system can require even more.
Advanced visual integration techniques significantly reduced errors in both the search
and the recall of diagrams, especially with respect to individuals with low spatial
visualization ability (Huotari et. al. 2003). Those techniques such as connecting lines
and brushing-and-linking, help represent the interrelationships between diagrams and
decrease the efforts of consistency checking hereby.
The number of the UML specification pages has grown and grown over the years.
Although a more precise specification can support a greater number of problems, it
also takes longer to read, understand and learn. The UML matured in expressiveness
and precision but it made the relationships between elements barely understandable
for beginners. Subjects complained about the difficulty of learning information system
modeling languages and the complexity of those is not fictitious.
According to Fowler (Fowler, 2003), the mythical 20 percent of UML helps you to do
80 percent of your work. The tool which would like to support modeling should
concentrate on this fraction to reduce the required learning time and increase the
effectiveness. It should also represent interrelationships between different diagrams
and elements of the diagrams to increase the understanding of the UML models,
which became more and more complex.
Figure 6 shows the subjects’ knowledge of the diagrams of UML. The leftmost row
contains the names of the diagrams. The data of every subject is represented in two
19
columns, where the M represents the meaning of the diagrams and their elements
and the N represents their names. The green color indicates full knowledge, the yellow
partial knowledge, or some mistakes in the recognition and the red means very low
knowledge or no knowledge about the given items. The pilot study showed that the
class and the use case diagram are the most known, the object and the sequence
diagrams follow them and the second user has the greatest knowledge about diagrams.
(See Figure 6)
M N M N M N M N M N M N M N M N M N M N M N M N M N M N
Activity Diagram
Class DiagramCommunication DiagramComponent DiagramComposite Structure Deployment DiagramInteraction Overview
Object DiagramPackage DiagramSequence DiagramState Machine Diagram
Timing DiagramUse Case Diagram
: low knowledge
M: Meaning of the diagrams and their elementsN: Name of the diagrams and their elements
: full knowledge
:partial knowledge
Figure 6 Knowledge of the subject about the diagrams of UML
The best known diagram is the class diagram. It is not only widely used by the
software designer but “also subject to the greatest range of modeling concepts”
20
(Fowler 2003). A class diagram describes the types of objects in the system and the
various kinds of static relationships that exist among them. Class diagrams also show
the properties and operations of a class and the constraints that apply to the way
objects are connected. Some subjects were familiar with the object diagram. An object
diagram shows the instances of the classes. That is why it is strongly related to the
class diagram.
The elements and relationships of a use case diagram are also well-known. Use cases
are a technique for capturing the functional requirements of a system. Use cases
work by describing the typical interactions between the users of a system and the
system itself, providing a narrative of how a system is used. Use cases are a valuable
tool to help understand the functional requirements of a system, and they show the
behavioral views of the system.
Interaction diagrams describe how groups of objects collaborate in some behavior.
The UML defines several forms of interaction diagrams, of which the most common
is the sequence diagram.
The most used diagrams in software development are the class, sequence and the use
case diagrams. The data collected showed that those are the best known as well. The
tools must concentrate mainly on those diagrams.
3.4.2 Tool-using needs of the subjects
Only 7 percent of the subjects used tools during the whole development process. Most
subjects utilized both the tools and the paper to create models. Each of them drew on
paper the first stage of the development and recreated almost the same diagrams with
the help of tools. 36 percent of the subjects had never used tools to model information
systems. (See Figure 7)
21
Both57%
Paper36%
Tool7%
Figure 7 Utilized devices for modeling
2
5
4
2
3 3
5
4
0
1
2
3
4
5
6
Nu
mb
er o
f th
e su
bje
cts
Expensive
Hard to learn
Hard to handle the changes
Not able to show more diagramsin a timeScreen is small
Slow
Tool dictate the rules / Limitation
Tool-using is difficult
Figure 8 Disadvantages of the modeling tools
The subjects complained about several disadvantages of the modeling tools (See
Figure 8). They found them hard to learn and use, because the existing modeling
tools implement numbers of features but do not provide an overview of the available
functions. The navigation in the model can also be difficult because the connections
between the related diagrams and their elements are not represented. Modeling on
paper offers more freedom than with modeling tools. The tools define rules in order
to support consistency checking and to help with reducing potential mistakes. The
tools should provide possibilities to disable those very useful features in the beginning
of the modeling, or when those disturb the user. The screens used nowadays are very
small for displaying huge amounts of information at a time. The size of the diagrams
22
is often bigger than the size of the screen, and the frequent scrolling disturbed a part
of the group of subjects. Some subjects chose the modeling on paper instead of
modeling with tools because the existing modeling tools do not provide the
possibility of studying more than one model at a time. Although the multiple
window system used by the existing tools supports the utilization of more windows,
those windows are too small to present the whole diagram at one time and the frequent
switching between them slows down the search efficiency.
The subjects mentioned several advantages of the modeling tools as well (See Figure
9). Every subject emphasized the appearance of the diagrams and their elements. The
diagrams drawn by hand have the style of the designers but the tools present the
diagrams in the same way regardless of the designers’ handwriting. Although the nice
looks of the elements are very important but the tools, which really want to support
the work of users, should follow the standard notations of modeling languages as
well. Some users found checking the correctness of the model a vital feature of the
modeling tools. The multiple views can cause inconsistency and incompleteness. The
subjects guessed they needed more and more assistance from the tool as the
information system became more complex. The modeling tools helped the subjects to
support the implementation and documentation.
2 2
9
1
3
8
0
1
2
3
4
5
6
7
8
9
10
Nu
mb
er o
f th
e su
bje
cts
Checking the correctness of themodel
Help to deal with complexity
Nice appearance
Support the documentation
Support the implementation
Support the notation
Figure 9 Advantages of the modeling tools
23
The users tried several modeling tools but none of them were professional (See
Figure 10). They utilized them only for one or two projects. The most well-known
tools were Microsoft Visio and Rational Rose. The usability test was created by
Rational Rose because it is used widely by software designers, the Jyväskylä
Polytechnic had a licence for it and the school gave a free run of it.
0
1
2
3
4
5
6
Nu
mb
er o
f th
e su
bje
cts
Use
Try
Use 4 1 1 3 2 1 1
Try 1 1 0 1 0 0 0
Microsoft Visio
Poseidon SmartDrawRational
Rose
Sybase Power
Designer Prosa Edge32
Figure 10 Frequency of using modeling tools.
Referring to the description of the subject’s tool-using needs, the users are not
satisfied with the multiple window technique used by existing tools because it needs
frequent scrolling and switching between diagrams, which sometimes disturbs the
users. The visualization techniques for representing information, which help with
dealing with complexity, are very important for increasing the effectiveness of the
model comprehension. Although the modeling tools should provide users with as
much freedom as the modeling on paper, they should support the standard notation
and apply the visual appearance, which the users had got used to by using other tools.
24
4. THE ISVIS PROTOTYPE
”My particular ability does not lie in mathematical calculation, but
rather in visualizing effects, possibilities, and consequences.”
Albert Einstein
4.1 Multiple windows vs. layers in three dimensional (3D) space
One third of the subjects, who have experience in using tools, emphasized the size of
displays used today as a disadvantage of modeling with tools. Small screens are not
capable of displaying the whole diagram at once and scrolling down to show the
hidden elements disturbs the user in the process of understanding. Some subjects
chose modeling on paper instead of with a tool because they could study multiple
diagrams at the same time on paper but the same task with a tool required frequent
switching between or resizing of windows. In addition, Smith and Duggar (Smith &
Duggar 1965) showed relatively early that common large screens result in a 15%
faster search performance in groups when compared with each user on his or her
individual screens.
Existing modeling tools utilize multiple windows for displaying information system
models (See Figure 11). If the user worked with multiple windows at the same time,
some relevant parts of the diagram could become hidden. In the case of cascade
arrangement, the windows would overlap with each other and choosing the tile
arrangement would decrease the size of the windows excessively. Both effects can
occur without selecting methods of arrangement. Overlapping can be avoided by using
transparent backgrounds for the diagrams because the elements behind them would
remain visible. The transparency allows for display of the overlapped part of the
diagrams but sometimes it makes it difficult to find out which element is related to
which diagram.
25
Changing the size of a window in a tool does not necessarily mean that the elements
in the resized window will adjust their sizes accordingly.
Figure 11 Multiple windows
The other disadvantage of multiple windows is that the connection between the same
or related elements located in different diagrams is hard to visualize. Huotari et. al.
(Huotari et al. 2003) showed that connecting lines with DFD and ERD on large
screens improves the search accuracy when compared to multiple separate diagrams.
Connecting lines is not applicable when some of the elements are hidden.
Although the question of what benefits 3D representation offers over 2D still remains
to be answered, some experiments have given optimistic results. Ware and Franck
(Ware and Franck 1994) indicate that displaying data in three dimensions instead of
two can make it easier for users to understand the data. In addition, the error rate in
identifying routes in 3D graphs is much smaller than 2D (Ware et al. 1993). 3D
representations have been shown to better support spatial memory tasks than 2D
26
(Tavanti and Lind 2001). In addition, the use of 3D representations of software in
new media, such as virtual reality environments, is starting to be explored (Knight and
Munro 1999, Maletic et al. 2001).
Figure 12 Layers in 3D space
The ISVIS prototype utilizes layers in 3D space instead of multiple windows (See
Figure 12). The idea of the layers is based on the contract boxes used by Gil and Kent
(Gil & Kent 1998) for visualizing sequence diagrams in 3D. While the contract boxes
represented the different stages of one sequence diagrams, the layers in the ISVIS
prototype contain the whole diagram instead. The layers always display the whole
diagrams which used zoom in order to avoid the unnecessary scrolling for finding
hidden elements. The ISVIS prototype automatically resizes the elements according to
the size of the diagram to display each part of the diagrams for the user. The 3D space
is suitable for visualizing the interrelationships between the diagrams. Layers allow
the use of connecting lines (See Figure 12), because those lines do not cause too many
27
crossing lines and the automatic resizing of the elements enables the brushing-and-
linking technique because each related element and its blinking label is always visible.
4.2 Overview, zoom, details
As Ben Shneiderman explains in (Shneiderman 1992), the main goal of every
visualization technique is: “Overview first, zoom and filter, then details on demand”.
This means that visualization should first provide an overview of the whole data set,
then let the user restrict the set of data on which the visualization is applied, and
finally provide more details on the part the user is interested in. When the user opens a
model, the ISVIS prototype displays the two main diagrams of the model (the most
abstract use case that provides the behavioral view and class diagram that provides the
structural view of the information system) in the three-dimensional space and the rest
of the parts of the model are hidden (Figure 13).
Figure 13 Overview
The user can easily browse the model and find the elements using the navigation
methods of the prototype, such as fast navigation, precise navigation, and intelligent-
zoom navigation (See Figure 14).
28
Figure 14 Zoom and filter
Figure 15 Details on demand
During the navigation the data is filtered because too many pieces of information can
decrease the search performance of the users. Only the shape of the elements and the
label of the elements’ name are represented during the browsing. The filtered
information of an element, such as the name of its members is available by zoom in
the given element (See Figure 15). This technique, where parts of the structure are
hidden until they are needed, is called elision (Parker, Frank & Ware 1998).
29
Typically, this is achieved through collapsing a node that contains different kinds of
information into a single node.
4.3 Automatic arrangement
The existing tools use multiple windows to show the model from a different
perspective. The authors of (Storey, Wong & Müller 1999) evaluated several program
comprehension tools through a series of user studies, as well as by using naturalistic
observation techniques to study software maintainers for the purpose of investigating
the requirements of a tool that supports effective program comprehension. They found
that the multiple window approach used by these tools often disoriented the users. The
users were faced with the difficult task of accurately conceptualizing and integrating
the implicit relationships among the contents of individual windows. The reuse of
existing windows was not well accepted by some users. They preferred to open new
windows and wanted windows frozen by default, but often complained about the
multitude of windows that the freezing feature would cause. Hence, the ISVIS
prototype displays the diagrams in a space and uses automatic arrangement.
The 3D space is divided into two parts, called the behavioral part which contains the
behavioral diagrams, and the structural part which includes the structural diagrams.
The behavioral part is located in the upper half of the space and the structural part is
placed in the lower. If the user opens a model then the two main diagrams, one
behavioral and one structural, will be located in the corresponding places. (See Figure
16)
30
Figure 16 The behavioral and the structural parts of the space
Figure 17 The sub-space of the parent diagram
31
Every parent diagram has a sub-space that can be used to display the diagrams
related to the elements in the parent diagram. The positions of the diagrams are
defined by the auto-arrangement system. If the user double-clicks with the left mouse
button on a use case, the related diagram(s) will be shown in the following way. If the
related diagram(s) are opened, no states are changed. Otherwise, the automatic
arrangement system automatically rearranges the positions of the diagrams in the sub-
space. If the sub-space was empty before rearrangement, then the parent diagram(s)
move up in order to free space for the sub-space and the new diagram(s) will be
located in the middle of the sub-space in one row. (See Figure 17) Otherwise, only the
positions of the diagrams in the sub-space are changed in order to give room for the
new one(s). (If the start state of this case is described by Figure 17, the result is shown
in Figure 18)
Figure 18 Middle point of the sub-space
The prototype provides two ways to close diagram(s). The most abstract diagrams can
not be closed. If the user double-clicks with the right mouse button on a use case, then
every diagram related to this use case will be closed. The user can close a diagram by
32
clicking on the close button. In both cases, the sub-space will be rearranged. The
diagram(s) left in the sub-space will be moved so that there are an equal number of
diagrams on both sides of the middle point defined by the parent diagram. If the sub-
space becomes empty, the parent diagram(s) will move down.
The whole process is animated. The new diagram(s) fly out from the element which
was clicked and the closed diagrams fly back to their owner element. It can help the
user know how the opened and closed diagram(s) related to the element of their parent
diagram.
4.4 Navigation
The ISVIS prototype provides three different navigation methods to browse the
model: fast navigation, precise navigation, and intelligent-zoom navigation. Each of
them can be used in different situations.
Fast navigation supports free and quick browsing of the model. The user can fly to
the given area of the model from the present position in the space by moving the
mouse. This navigation method is fast but it misses intelligent support by the system,
and positioning an exact point can be hard by using this method.
Precise navigation supports attaining the exact position of the model. The user can
change the camera position by using the keyboard. This method is very precise but it
is slow for navigating through long distances in the model.
Intelligent-zoom navigation supports positioning a given area. If the user would like
to see a part of the model in more detail, the given area will be focused by clicking it.
It provides a detailed view of the given area but keeps its environment visible. This
method requires minimal effort but it does not support precise positioning and the
navigation between elements located far from each other can be slow.
The ISVIS prototype uses different methods from the existing modeling tools for
opening a given diagram. Existing tools apply browser windows that contain the
33
diagrams of the information system model in the tree structure, and in which the
diagrams are separated by their type.
To open a new diagram the appropriate element of the hierarchy must be expanded by
clicking the (+) sign; then the name of the diagram must be found and displayed by
double-clicking the name or icon in the browser window. In the ISVIS prototype the
contained diagrams can be opened by clicking the given element.
34
5 USABILITY OF THE PROTOTYPE
”through the eyes of the average user”
Jakob Nielsen
5.1 Definitions of the usability engineering
Ensuring that a product is usable is not easy and guaranteeing usability is even more
difficult. Usability engineering seeks to solve the problem of ensuring that the product
is what the user really wants and will actually use. The International Organization of
Standardization (ISO 9241) defines usability as “the effectiveness efficiency and
satisfaction with which specified users can achieve specified goals in particular
environments.”
• Effectiveness - the accuracy and completeness with which the specified users can
achieve specified goals in particular environments.
• Efficiency - is the resources expended in relation to the accuracy and
completeness of goals achieved. The specified user can accomplish the task in the
least time and with as little effort as possible.
• Satisfaction - is the comfort and acceptability of the work system to its users and
other people affected by its use.
5.2 Methods of the usability engineering
To measure the effectiveness of the ISVIS prototype the subject was given some
tasks; therefore, it could be observed whether he/she could accomplish them. The first
task was carried out to monitor how the user applies the prototype to complete a given
task. The complex task, which addresses each feature of the prototype, may be
partially completed. Because of this, it was broken down into subtasks that were
comparatively easy to measure with respect to whether or not they had been
completed.
35
The frequency of use of the various features or the evidence of use of particular
aspects of an interface gave us information about how effective the system is. The
prototype has redundant functionality, such as navigation and representation of the
connection between related elements. The ways of doing the task were observed and
the frequency of use of various functionalities was studied.
The ISO definition is about how much effort is required in order to accomplish the
task. An efficient system ought to require as little effort as possible:
• The time required to perform a selected task.
• The number of actions required in order to perform a task.
• The time spent using help.
• The time spent dealing with errors.
The first two metrics give a measurement of how much time and effort is needed to
expend on a particular task. Both the number of actions needed to perform the task
and the time taken were measured. The number and the type of the help requests and
errors were counted as well.
It might seem unlikely that it would be possible to measure the satisfaction a user feels
whilst using a system. Such a measurement would seem to be too subjective.
However, a useful measurement of user satisfaction can be made if the evaluation
team’s measurement is based on observations of user attitudes towards the system.
(Faulkner 2000)
The user attitudes were measured by using a questionnaire. Each question had a scale
from 1 to 5, where 1 means very bad and 5 means a very good rate. After each
subtask, the opinion and emotion of the subject were asked as well.
In the experiment, it was measured whether or not the user can find the information
that is needed for understanding the information system and whether the found
information is correct or not. This exercise did not address the understanding of the
system, which needs modeling skill, but it required the understanding of the elements
and the navigational methods, which need tool-using skill. The user, who has system
development experience, can replace the missing information with the conclusion
36
generated by existing data. To avoid this problem the language of the text in a
model was unknown for the subject; therefore, he could not conclude the meaning of
the graphical notation of UML from the meaning of the model elements.
The subtasks of this experiment were:
• Open/Close a model
• Navigation in the model
• by moving the mouse
• by left click
• by right click
• by clicking the maximize button
• by clicking the restore button
• Open model
• Close model
• by clicking the close button
• by right click
• Using the focus feature
• Recognize the name of
• the diagrams
• the entities
• the relationships
• Recognize the visualization techniques of connections
• brushing-and-linking
• connecting lines
5.3 Results of the experiment
The time and the effort of opening and closing a model in the ISVIS prototype is the
same than in other modeling tools because both use the function of the File menu to
accomplish those functions.
37
The ISVIS prototype uses a different method than the existing modeling tools for
opening a given diagram (See Section 4.4). Both opening methods were effective
because the subject could reach every type of diagrams (use case, sequence, class) in
both cases. The efficiency of finding diagrams is nearly equal as described by the
following diagram (See Figure 19).
85
18
1
5
25
0
5
10
15
20
25
30
Sec
on
ds
ISVISprototype
RationalRose
ISVIS prototype 8 5 18
Rational Rose 1 5 25
Class diagram Use case diagram Sequence diagram
Figure 19 The efficiency of finding diagrams
The opening time of a given type of element hardly depended on the position of the
diagram in the tree structure, which is based on the type of the diagram, or on the 3D
space, which is based on the relationship between diagrams. Neither the effort of
finding the given diagram nor the time of opening it showed big differences.
The time spent on searching the related diagrams in Rational Rose depends on
the related elements’ position in the tree structure. If those elements are close to
each other, a successful search can be very fast. Otherwise, it can be much slower than
with the ISVIS prototype. Using the ISVIS prototype this time is almost constant
and it fluctuates between 5 and 12 seconds (See Figure 20).
38
12
5
8
5
1
20
0
5
10
15
20
25
Sec
on
ds
ISVISprototype
RationalRose
ISVISprototype
12 5 8
Rational Rose 5 1 20
1st time 2nd time 3th time
Figure 20 The efficiency of the related diagram finding
Figure 21 Automatic arrangement without intelligent zoom
The subject was satisfied with both opening methods and he suggested that the ISVIS
prototype should utilize both of them. In the next iteration phase in the development
process of the prototype the tree structure of the diagrams will be implemented (See
Section 6). The idea of the opening process got a very good mark from the subject
because of automatic arrangement but he found incompleteness in it: when the user
39
is closed to the diagram new ones can be opened outside the visible area (See
Figure 21).
The solution to the problem is moving the camera position farther from the diagram
during automatic arrangement (intelligent zoom) (See Figure 22).
Figure 22 Automatic arrangement with intelligent zoom
The ISVIS prototype supports different navigational methods from the existing tools.
The existing tools provide two main navigation methods: using the browsing
windows or the Window menu for switching between the diagrams. The ISVIS
prototype utilizes three different navigation methods to browse the model: fast
navigation, precise navigation, and intelligent-zoom navigation (See Section 4.4).
The subject could navigate using both tools and its efficiency was almost the same.
Using Rational Rose the subject preferred the functions of the Window menu for
navigating diagrams and he utilized the options of the browser window for opening a
new diagram. The favorite navigation method of the user using the ISVIS prototype
was the intelligent-zoom navigation. The left double click on a diagram results in
intelligent zooming in, while the right results in zooming out. The idea of intelligent-
zoom navigation was valued very highly by the subject. He found it fast enough for
navigating, but he noticed that the zooming was sometimes not suitable, because the
40
camera did not focus in the center of the appropriate diagram but rather above it or
under it. This implementation fault was corrected.
The user could utilize every navigational method. He preferred the intelligent-zoom
navigation and he could solve almost every subtask of the experiment by using it. The
ideas of this navigation method were valued very highly by the subject but he found it
did not support movement well. The reason for the problem might be the use of the
touch pad because switching between moving and clicking needs more time when
using the touch pad, than using the mouse. The mouse generally has a tree button,
providing the possibility of using the mouse for rotation instead of the keyboard. The
user felt more freedom when he worked with the mouse.
Not only the differences between devices might cause different navigation preference,
as the above example proved, but the attribute of the user as well. One user would like
to move forward with the mouse to go closer to a diagram and another would like to
move backwards to do it. Hence, the ISVIS prototype will be more personalized in
the next iteration phase.
The subjects were able to identify almost every kind of diagram and element in the
ISVIS prototype. The only thing was members of the class which he misunderstood
the first time when he used the prototype. He thought that the colored button in front
of the name of the members meant the access levels (green means public, red means
private) of the methods. This misunderstanding demonstrated that the utilized
visualization technique for differentiating the attributes and methods in a class was not
effective enough. The color was changed and a line was added between the attributes
and methods to avoid the misunderstanding in the future.
41
6. DISCUSSION, LIMITATIONS, AND FUTURE WORK
”The journey of a thousand miles starts with a single step”
Chinese Proverb
The data collection, for getting to know the users’ needs, was only a pilot experiment.
Although the subjects were students from different countries, from different
universities with different majors and minors and they had different modeling and
tool-using knowledge, the sample was not representative and the number of the
subjects was too small for proving the hypotheses described in Section 2. The ISVIS
prototype might be useful in school because the needs of the students were measured.
The needs of software designers, who already work in the field, have to be measured
in order to know whether the prototype meets their requirements, as well. To assure
that the results of this pilot experiment were correct, another experiment is needed
with more representative subjects.
The development of the ISVIS prototype is an iterative and incremental process.
During the last nine months the first iteration phase was completed but the project has
not been finished yet. Some requirements of the next phases were recorded. Jouni
Huotari, who is the supervisor of this thesis, is going to conduct future experiments to
study the usability of the visualization techniques implemented by the ISVIS
prototype in March. The author of this thesis would like to support his supervisor’s
work as a PhD student of the University of Jyväskylä.
The usability test was completed by only one user. The usability test was divided into
two parts but only the first one, which measured the usability of tool-using, was
accomplished. Its results demonstrate some design and implementation errors of tool-
using that can affect the results of the second test, which would have measured the
usability of the modeling support of the prototype. Those errors are under correction
in order to provide a suitable system for the next tests in March. As a continuation of
this work the modeling habits of expert modelers will also be observed because it will
help to study how advanced visualization techniques support the understanding of
information systems.
42
The ISVIS prototype has several missing functions, which will be added in the next
iteration phases:
• After the first iteration stage the prototype can display three diagrams. In the next
iteration stage it should implement:
• the other ten UML 2 diagrams and
• the missing UML 2 symbols
• The prototype can only import models from Rational Rose. In the next iteration
stage it should expand the import function of the prototype according to the
XML Metadata Interchange – Diagram Interchange (XMI[DI]).
• The navigation in the 3D space was suitable but some users got used to the tree
structure of the diagrams. The prototype should provide both techniques; that is
why it could implement the tree structure for navigation as well.
• Modelers often move back and forth between different states of the model. The
user, who participated in the usability test, noticed that the prototype did not
support it. The prototype should record the history of navigation steps and should
give the users the possibility of browsing them.
43
REFERENCES
Alabastro, Mark S., Beckmann, Gerd, Gifford, Gina, Massey, Anne P. and Wallace
William A (1995): The Use of Visual Modeling in Designing a Manufacturing Process
for Advanced Composite Structures, IEEE Transactions on Engineering Management,
1995, 42:3, pp. 233-242.
Booch, G., Jacobson, I., and Rumbaugh, J.(1997): The Unified Modeling Language
for Object-Oriented Development, Documentation set, version 1.0, Rational Software
Corporation 1997
Egyed, A. (2002): Automated Abstraction of Class Diagrams, ACM Transactions on
Software Engineering and Methodology (TOSEM), Volume 11, Number 4, October
2002, pp. 449-491.
Egyed, Alexander (1999): Integrating Architectural Views in UML, Technical Report
USC/CSE-99-TR-514 March 10, 1999
Faulkner, Xris (2000): Usability Engineering (Grassroots) Palgrave Macmillan;
(March 2, 2000) ISBN: 0333773217
Fowler, Martin (2002): Patterns of Enterprise Application Architecture, Addison-
Wesley Pub Co; 1st edition (November 5, 2002) ISBN: 0321127420
Fowler, Martin (2003): UML Distilled: A Brief Guide to the Standard Object
Modeling Language, Third Edition Addison-Wesley Pub Co; 3rd edition (September
19, 2003) ISBN: 0321193687
IEEE Draft Standard 1471 (1998) Recommended Practice for Architectural
Description, Draft Std. P1471, IEEE 1998
ISO 9241 (2001): General information on ergonomics standards Part 11 Guidance on
usability specification and measures
44
Gil, Joseph (Yossi), Kent, Stuart (1998). Three dimensional software modelling. In
Proceedings of the 20th international conference on Software engineering, pages 105-
114. IEEE Computer Society.
Gould, J. D.:How to design usable systems, in M. Helander (cd.), Handbook of
Human-Computer Interaction, Elsevier Science Publishers, North-Holland, 1988,
pp.757--789.
Hix, Deborah and Hartson, H. Rex (1993): Developing User Interfaces : Ensuring
Usability Through Product & Process John Wiley & Sons; (April 1993) ISBN:
0471578134
Huotari, Jouni, Lyytinen, Kalle, and Niemelä, Marketta (2003): Improving Graphical
Information System Model Use with Elision and Connecting Lines ACM Interactions
2003, Issue 6, pp: 9-10
Kim, J., Hahn, J., and Hahn, H. (2000): How Do We Understand a System with (so)
Many Diagrams? Cognitive Integration Processes in Diagrammatic Reasoning.
Information Systems Research 11, 3, 284-303.
Knight, C. and Munro, M. (1999): Comprehension with[in] Virtual Environment
Visualisations, in Proceedings of Seventh IEEE International Workshop on Program
Comprehension (IWPC'99), Pittsburgh, PA, 5-7 May 1999, pp. 4-11.
Maletic, J. I., Leigh, J., Marcus, A., and Dunlap, G. (2001): Visualizing Object
Oriented Software in Virtual Reality, in Proceedings of International Workshop on
Program Comprehension, Toronto, Canada, May 21-13 2001, pp. 26-35.
Miller, George A. (1956): The Magical Number Seven, Plus or Minus Two: Some
Limits on Our Capacity for Processing Information, The Psychological Review, 1956,
vol. 63, pp. 81-97
Nuseibeh, B. (1996): Towards a framework for managing inconsistency between
multiple views, Proceedings of the Viewpoint 96: International Workshop on Multiple
Perspectives in Software Development.
45
Parker, G., Franck, G and Ware, C. (1998): Visualization of large nested graphs in
3D. special issue of the Journal of Visual Languages and Computing. 9, 299-317.
Selonen P., Koskimies K., Sakkinen M. (2001): How to Make Apples from Oranges in
UML. In Proc. of HICCS 34, IEEE Computer Society 2001.
Shneiderman, Ben (1992): “Tree Visualization with Tree-Maps: A 2-D Space-Filling
Approach”. In ACM Trans. of Computer-Human Interaction, vol. 11, no. 1, 1992, pp.
92-99.
Smith, S.L., and Duggar, B.C. (1965): Do Large Shared Displays Facilitate Group
Effort? Human Factors 7, 237-244.
Storey, M.-A.D., Wong K., and Müller, H. A. (1999): How Do Program
Understanding Tools Affect How Programmers Understand Programs? Science of
Computer Programming, 1999.
Tavanti, M. and Lind, M. (2001): 2D vs 3D, Implications on Spatial Memory, in
Proceedings of IEEE Symposium on Information Visualization (INFOVIS'01), San
Diego, CA, October 22-23 2001, pp. 139-148.
UML 2 (2003) UML 2.0 Superstructure Specification OMG Adopted
Specificationptc/03-08-02
Ware, C. and Franck, G. (1994): Viewing a Graph in a Virtual Reality Display is
Three Times as Good as a 2D Diagram, in Proceedings of IEEE Visual Languages,
1994, pp. 182-183.
Ware, C., Hui, D., and Franck, G. (1993), Visualizing Object Oriented Software in
Three Dimensions, in Proceedings of CASCON'93, Toronto, Ontario, Canada,
October 1993, pp. 612-620.
XMI [DI] (2003) Unified Modeling Language: Diagram Interchange version 2.0
ptc/03-07-03 Draft Adopted Specification
46
Zowghi, D. and Gervasi, V (2003): On the interplay between consistency,
completeness, and correctness in requirements evolution. Information and Software
Technology, 45(14):993-1009, Nov. 2003.
