USING UML TO FACILITATE THE TEACHING OF

OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN*

Philip J. Burton and Russel E. Bruhn

Department of Information Science
Donaghey College of Information Science and Systems Engineering
University of Arkansas at Little Rock
2801 South University Avenue
AR 72204-1099
Phone: 501-6837265, Fax: 501-6837049
pjburton@ualr.edu
rebruhn@ualr.edu

ABSTRACT
This paper discusses how UML, withthe aid of a CASE (Computer Aided Systems
Engineering) tool, can help teach an Object-Oriented Systems Analysis and Design
(OOSAD) course. Today's students need to be actively involved in the learning
process and must be able to apply a concept while it is being taught. Most OOSAD
real-world problems are to complex to deal with in the classroom, so we have
chosen a simpler problem - consisting of a university setting - that all students are
familiar with. By using a CASE tool to draw UML diagrams students can visualize
the object-oriented concepts and see the relevance of what is being taught. UML
can help simplify OOSAD problems and at the same time actively engage students
in the learning process thus increasing the general interest level of the student. The
author's basic approach to teaching OOSAD material is to have the students
emulate the instructor when working through a problem. With enough concrete
practice like this, students soon build a strong foundationin UML diagrammatics and
in the process gradually abstract out the underlying OOSAD concepts. The aim is
to reach a point where students can make their own interpretation, apply OOSAD

___________________________________________

*
Copyright © 2003 by the Consortium for Computing Sciences in Colleges. Permission to copy
without fee all or part of this material is granted provided that the copies are not made or
distributed for direct commercial advantage, the CCSC copyright notice and the title of the
publication and its date appear, and notice is given that copying is by permission of the Consortium
for Computing Sciences in Colleges. To copy otherwise, or to republish, requires a fee and/or
specific permission.

278
 CCSC: Southeastern Conference

concepts independently, and ultimately devise their own extensions to UML to solve
a problem.

1 INTRODUCTION
Formal presentations of Object-Oriented Systems Analysis and Design (OOSAD) can
be heavily theoretical; many textbooks in this area are excessively wordy and as a result most
students do not even bother to read them. Students who have become used to a practical,
hands-on approach taken with systems programming courses, like Java [1], need to have a
similar approach taken with OOSAD [2]. They need to learn about UML diagrams by actually
drawing them with the instructor.
A growing body of experience [3, 4] suggests that the main requirements for teaching
today's students are:
- Students need to be actively involved in learning
- The ideas must be visually presented
- Students need to apply a concept while it is being taught
- The students must see the relevance of what is being taught
Incorporating the Unified Modeling Language (UML) [5] into an OOSAD course affords an
opportunity to achieve all of the above goals. If OOSAD is taught in a computer lab where a
CASE tool is installed, the style of instruction adopted can parallel that taken for a systems
programming course. The authors have found that this style of instruction works well for
students whose backgrounds are not academically strong.
Most real-world problems in OOSAD are too complex to deal with in the classroom and
the first task for the instructor is to choose a simpler problem whose knowledge domain is
familiar to the students. It is also necessary to choose a subset of UML and there is a collection
of diagrams that have now become standard for a beginner's course. The subject we have
chosen is based on the organization and operation of a typical university, with which all students
will have a natural familiarity. We will describe a teaching sequence taken from the first section
of a UML-CASE based OOSAD course [5].

2 CHOICE OF TOPICS
It is not necessary to teach all of UML in a beginning course; in fact, "Eighty percent of
OOSAD problems can be modeled with only twenty percent of UML", [6]. A typical choice
of diagrams is:
- Use Case and Scenario
- Class and Object
- Sequence and State
- Component and Deployment
We can relate these diagrams to the Analysis and Design phases of OOSAD [7]:

279
JCSC 19, 3 (January 2004)

Figure 1: Simplified UML Process (adapted from [7])

A greatly simplified OOSAD process can then be done as follows:

Analysis: Interview Users, Identify Classes, and Develop Use Cases and Sequence Diagrams.
Design: Refine Sequence Diagrams and Refine Class Diagrams. Draw other diagrams.
In this paper, due mainly to space constraints, we will illustrate our teaching approach for
the first part of the Analysis phase only. We will focus on the key UML diagram: the Class
Diagram. We choose to teach Classes and Objects first because OOP (Object Oriented
Paradigm) concepts are difficult and students need to start thinking about them as soon as
possible [8]. Thus, when teaching OOSAD, and for purely pedagogical reasons, we emphasize
a problem solving approach that puts identification of objects and classes first. This decision
results in a natural teaching sequence, organized as follows:
1. Classes, objects, attributes and operations; encapsulation, data hiding and scope.
2. Classes of objects and objects as instances of a class.
3. Associations and relationships.
4. Entities (as classes with attributes only) and Entity-Relationship Diagrams.
5. Inheritance.
6. Polymorphism.
7. Aggregation and Composition.
8. Interfaces as classes with operations only (for specifying behavior).
OOSAD can be applied to systems programming, databases and business systems
analysis. In this paper, we are assuming that an OOSAD course will emphasize applications to
systems programming and database design.

3 THE PROBLEM SPECIFICATION

A university may be viewed as a collection of colleges and departments together with its
employees, such as faculty, administrators and staff. The university keeps a record of which
faculty teaches which subjects and also the grades that were recorded.
We will analyze the university from these two aspects, using UML to describe:
1. The university organization in terms of classes.
2. The data structures, or entities, needed to record the grades for a particular subject,
semester and professor, as shown in the following tables.

280
 CCSC: Southeastern Conference

Subject Title Semester NrStudents Professor

IFSC Computer 1 50 J. Somers
1201 Literacy

IFSC Internet 2 90 R. Smith

1310 Technologies

IFSC O-O 3 30 R. Jackson

2300 Technologies

IFSC O-O System 4 40 P. Cotter

2310 Analysis
Table 1: Subject Table for a University

Subject Semester Grade NrStudents %

IFSC 1201 1 A 5 10

B 10 20

C 30 60

D 5 10

IFSC 1310 2 A 16 17.8

B 24 26.6
C 35 38.9

D 15 16.7

IFSC 2300 3 A 8 26.7

B 10 33.3

C 8 26.7

D 4 13.3

IFSC 2310 4 A 4 10
B 6 15

C 20 50

D 10 25
Table 2: Subject Grade Table for a University

281
JCSC 19, 3 (January 2004)

Identifying the parts of the system might produce the list:

P University organization: University (C), College (C), Department (C), Faculty (C),
Professor (C), Administration (C), Student (C), Administrative_Procedure (I).
P Student grade: Subject (E), Semester (E), Grade (E).
We have used the labels: C for Class, E for Entity and I for Interface.

4 TEACHING METHODOLOGY
The author's basic approach to teaching OOSAD material can be summarized as follows.
P Emulation
- The student uses the CASE tool to reproduce the diagram - and the idea it
represents - along with the instructor. Students seem to enjoy doing these
diagrams and this is the simplest and most effective teaching tool for OOSAD.
P Interpretation
- Here, the students are given a UML diagram to interpret. Students need to
see UML diagrams done by mature practioners of OOSAD to appreciate
what is possible.
P Application
- The students apply an idea to a situation, or part of a problem, and draw the
UML diagram independently.
P Synthesis
- Require the students to combine different UML diagrams to give a more
complete picture of a problem.
P Extension
- Require the students to extend the meaning of UML, using stereotypes, so
that UML may describe a situation beyond the standard UML elements.
It is pertinent to reiterate the main theme of this paper. The authors believe that teaching
OOSAD to academically weaker students is best done by incorporating the visual approach
of UML as much as possible into each topic. By 'academically weaker students' we mean
students who lack analytical and math skills and who need a great deal of guided instruction.
In the classroom, the authors have the students use a CASE tool, such as Enterprise Architect,
to draw diagrams along with the instructor. The aim is not only to illustrate the OOSAD
concept, but also to keep the students constructively engaged for the whole period. The aim is
to make an OOSAD class as analogous as possible to a laboratory based programming class.
Long theoretical presentations with software like PowerPoint are kept to a minimum.
Using a CASE tool - as opposed to drawing by hand - confers the following advantages:
P The visual representation of a difficult concept is much improved if the diagram is neat and
well organized - most people are poor artists, and even poorer visualizers
P A CASE tool allows easy manipulation and modification of a diagram

282
 CCSC: Southeastern Conference

P A good CASE tool tracks changes to labels, attributes and operations across a set of
diagrams
P Using a CASE tool allows the modeling process - the iterative transition from conceptual
to logical level - to be made easily (because of the above)
P Diagrams in electronic format are easy to exchange over an institutional network or the
internet; this facilitates communication between instructor and class and group work
between students

5 TOPICS
What follows is a description of the topic sequence in as self-contained manner as
possible; that is, we explain the UML elements and how they relate to OOSAD in general. It
is important to point out to students that there is more to OOSAD than just drawing UML
diagrams.

5.1 Objects, Attributes, Operations and Encapsulation

With the object-oriented approach, a university system is viewed as a collection of
interacting objects. That means that objects in a university system, as in the world around us,
are viewed as things. These things have certain features, or attributes, and they exhibit certain
behaviors, or operations. An object is a thing that can be distinctly identified and is something
that people think about, identify, act upon, or apply concepts to. We describe an object in
terms of the attributes and operations that are important to us.
A class of objects is often defined on the basis of having common attributes. These are
common to all the objects in the class. All professor objects have a name and a subject. An
attribute is one piece of information that needs to be known about the objects in the class. The
attribute values are part of what an object "knows" in the object-oriented approach. For
example, in Figure 2 the class 'Professor' has the attributes 'name' and 'subjects'.
When modeling a system's behaviors - also called operations - the object-oriented
approach is more extensible than procedural programming. Doing something implies that a
procedure is followed, so operations mean procedures. Operations of a class are those
procedures that the objects in a class know how to follow. In Figure 2 the class Professor
knows how to 'teach()' and 'grade()'.
Encapsulation means that several items are packaged together. Encapsulation lets us think
of the attributes and operations of the object as one unit. Hiding the internal structure of the
object from the environment is also provided for by encapsulation. Other objects cannot
change the data in the attributes or modify the procedures of an operation, so no unexpected
changes can be imposed on the object from the outside. Protecting the attributes in this way is
referred to as data hiding.
To grasp these concepts an instructor wouldn't think of giving such an important
assignment verbally. We have found that the best way for the students to learn these concepts
is to actually create diagrams incorporating attributes and operations. When students are

283
JCSC 19, 3 (January 2004)

actively engaged in the learning process the general interest level of the student increases [9].
This increased interest level translates into increased learning. Students seem to have a higher
retention rate for object-oriented concepts when they are actively engaged in the classroom.
The mind tends to remember a physical action, but can quickly forget a verbal command.
During the course of the lesson, the authors ask students to draw many diagrams like Figure 2
using a CASE tool, such as Enterprise Architect.
Figure 2 shows that for classes both the attributes and the operations of the class are
packaged together. Because of attributes the object knows things and from operations the
object knows how to do things. This is what makes the class or object much more than a data
entity. A data entity has attributes only. When modeling data a class is very much like a data
entity type. An example of a data entity type would be a table of data. An instance of an entity

Figure 2: Attributes, Operations and Encapsulation

type is data about one specific thing. We can adapt a UML class diagram to represent a data
entity using the idea of stereotypes to extend the originalmeaning of a UML element. See Figure
5.

5.2 Classes of Objects, Objects as Instances of a Class

In Figure 3, 'Student' is a class and this defines the data type 'Student'. Object 'jimmy' is
one specific instance of 'Student'. 'Student' is the general category and object 'jimmy' has
particular values given to its attributes. To a person experienced in object-oriented technologies
classes of objects and objects as instances of a class may seem easy to understand. To
students these concepts are not always easy to understand. To teach this concept we would
have the students draw the class diagram, then draw a number of instances each with its own
set of values for the attributes. Students could also be given object diagrams and asked to infer,
and draw, the class for which they are instances. This introduces the idea of abstraction, which
is a difficult one to teach to students. In a first approach to teaching abstraction, we would give
students a number of 'Student' instances, each with exactly the same attribute. It is then easy for
the student to guess the attributes of the class. Of course, there is more to abstraction than
simple generalization.

284
 CCSC: Southeastern Conference

5.3 Associations and Relationships

Class relationships are relationships between instances of the class. An object might be

Figure 3: Instantiation

naturally related to other objects or an association is created by the context in which we view
the objects. Figure 4 shows two class relationships where objects from the class on the left are
associated with objects from the class on the right. The nature of the association can be
described very precisely. In UML the multiplicity of a relationship among objects can be
one-to-one, zero-to-many, one-to-many, or many-to-many. In Figure 4, zero-to-many
students are associated with one-to-six professors. The numbers and symbols in UML
representing multiplicity include a "0" for zero, a "1" for one and an asterisk (*) for many. Using
this notation on the second diagram in Figure 4 one can see that one and only one subject is
associated with one-to-thirty students. When an object like 'Subject' has a one and only one
relationship to another object like 'Student' in UML, the relationship is considered mandatory.

Figure 4: Associations

285
JCSC 19, 3 (January 2004)

Figure 5: Entity-Relationship Diagram

5.4 Entity-Relationship Diagrams
An entity is "a thing (data object) with distinct and independent existence" [10]. When
identifying entities, we consider an entity to be a data reference that has separate and distinct
existence in the world of the users, and is of interest in that they need to make records about
it. Looking at Tables 1 and 2, we can define the entities: 'Grade' (attribute: code), 'Subject'
(attributes: name, title), 'Semester' (attribute: semester), 'SubjectSem' (attribute: nrEnrolled,
professor), and 'SubjectSemRating' (attributes: nrStudents, percent). These are things that can
have a distinct meaning when viewed by a user.
An entity type is a "class of entities" that are all the same kind of thing. The name 'Subject'
is really intended to stand for the general kind of thing described by the word subject. Entities
have attributes, but no operations or behaviors.
We need to define the representation of entities and how they interact. A relationship or
association is the interaction of two entities/classes and is represented by a verb. You visualize
the association as a line connecting the two classes or entities. When the 'Subject' class
associates with the class 'Semester' you can show the role the association plays near the line.
In Figure 5 the association shows that 'Subject' is associated with the 'Semester' offered.
An association can have attributes and operations, just like a class [11]. When this is the
case it is called an association class and we connect it via a dashed line. Figure 5 shows the
association class 'SubjectSemRating' for the association between the classes 'SubjectSem' and
'Grade' [12]. Figure 5 requires the student to combine different UML diagrams (that is,
synthesis) to give a more complete picture of the data structure.

286
 CCSC: Southeastern Conference

5.5 Inheritance
Inheritance is a mechanismwhereby classes can make use of the attributes and operations
of other classes. In Figure 6, class 'Professor' is a subclass (child) of the class 'Faculty' and
inherits all of the attributes and operations from it. In addition to the attributes and operations
subclasses inherit, they may define their own attributes and operations and also redefine the

Figure 6: Inheritance

meaning of inherited operations.

5.6 Polymorphism
Polymorphism means 'having multiple forms'. In Figure 7, there are three classes:
'MathProfessor', 'PhysicsProfessor' and 'ChemistryProfessor'. Each need to teach and do
research, but the actual procedure for teaching and doing research may be different for each
class. However, the message does not need to know which type of class it is being sent to. The
same message can be sent to the three classes of objects but different forms of the 'teach' and
'research' operations are invoked. Polymorphism is not an easy concept for students to
comprehend. It is easy for the instructor to lecture on the topic but many students sit
glassy-eyed and never truly understand polymorphism from a lecture. We have found that by
having the students create the UML diagram while the instructor is lecturing produces increased
learning. The old adage "Tell me and I forget, show me and I understand - let me do it and I

Figure 7: Polymorphism
287
JCSC 19, 3 (January 2004)

remember" holds particularly for an OOSAD lesson. Using the classroom as a place to actually
practice object-oriented systems concepts helps a student to learn the concepts more quickly.

5.7 Aggregation and Composition

There are two types of class relationships of concern: association relationships, which we
just discussed, and whole-part relationships. As stated above, an association relationship
means that objects of one class are naturally associated with objects of another class in some
way. In a whole-part relationship one class is regarded as being made up of one or more other
classes. Figure 8 shows two types of whole-part relationships: aggregation and composition.
UML distinguishes between aggregation and composition. Composition relationships have the
strongest associations and are represented by a filled diamond. Aggregation relationships are
depicted by an open diamond and may be entirely conceptual. Composition relationships are
stronger relationships and state that the part cannot exist independently of the whole. In Figure
8 the college is definitely made up of three departments. In other words, a department is in only

Figure 8: Aggregation and Composition

one College. 'Department_2' definitely has 'Faculty' and 'Staff' but a 'Student' can study in more
than one department.

5.8 Interfaces as Classes with Operations

A number of classes might include some standard operations - perhaps implemented in
a different way - but may not all be related to a particular parent or super class. Somehow we
want to be able to capture this reusable set of operations. In UML the interface construct
allows us to do this. In another use of the term, the interface of a class is the set of operations
that the class presents to other classes; that is, the classes behavior.
We model an interface the same way we model a class, with a rectangle icon. The
difference between a class and an interface is that an interface has no attributes, only operations,
and in addition the operations are 'empty'. That is, there is no code. To distinguish between a
class and an interface we place the stereotype <<interface>> above the name as shown in

288
 CCSC: Southeastern Conference

Figure 9. This demonstrates how the use of stereotypes allows the meaning of UML to be
extended.
The relationship between a class and an interface is called 'realization'. In Figure 9 it is
as though the class 'DepartmentChair' guarantees that part of its behavior will <<realize>>
'EnrollmentProcedure'. The class must implement all of the operations in the interface.
Realization is shown by a dashed line terminating in an open triangle that points to the interface.

Figure 9: Realizing an Interface

6 CONCLUSION
This paper has described how the use of UML, together with a CASE tool, facilitates the
teaching of OOSAD. Choosing a problem the students are familiar with helps them see the
relevance of what is being taught. The authors have observed in their classes that by using a
UML CASE tool the students can be actively engaged in the learning process and as a result
their level of interest increases [13, 14]. This increased interest level translates into increased
learning. Important concepts in OOSAD problems are simplified by UML because the students
can visualize what is happening in the system. For various reasons, it is preferable to use a
CASE tool to do UML diagrammatics [15]. Emulating an instructor is the most efficient way
for students to learn UML and it helps them understand the ideas that UML represents. By
interpreting and modifying existing UML diagrams students can understand complicated
relationships in OOSAD and appreciate what is possible with UML. Using a CASE tool the
instructor can have students combine different UML diagrams to give a more complete picture
of a problem (synthesis). Finally, using a CASE tool with UML, allows the students to more
easily extend the meaning of UML elements using stereotypes.

REFERENCES
[1] Budd, T., Understanding Object-Oriented Programming with Java, Addison Wesley,
2000.

289
JCSC 19, 3 (January 2004)

[2] Grutzner, I. and Bunse, C., "Teaching Object-Oriented Design with UML - A Blended
Learning Approach", 6th Workshop on Pedagogies and Tools for Learning Object
Oriented Concepts, June 11, 2002, Malaga, Spain.
[3] Mrozek, Z., Mrozek, B. and Adjei, O., "Teaching object oriented software engineering
withUML", 13th Annual Conference on Innovations in Education for Electrical and
Information Engineering (EIE), York 8-10 April 2002.
[4] Lesgold, A. The Nature and Method of Learning by Doing. American Psychologist 56,
11 (2001), 964 - 973.
[5] Booch, G., Rumbaugh, J. and Jacobson, I., The Unified Modeling Language User
Guide,Addison-Wesley, 1999.
[6] Daubisse, C., Ducateau, C., F., "An UML teaching experience in an IUT (Institut
Universitaire de Tecnologie): report and remarks", <<UML>>'2000 3rd International
Conference, 2 - 6 October, 2000, York, 2000.
[7] http://vancewilson.com/UMLtips
[8] Satzinger, J., W., and Orvik, T., U. The Object-Oriented Approach. Course
Technology, Thompson Learning. 2001.
[9] Crull, S., Computer Assisted Teaching. Teaching Sociology 15, 1 (1987) 82 - 83.
[10] D., A., Taylor. Object Technology: A Manager's Guide. Addison Wesley. 1998.
[11] D., W., Brown. An Introduction to Object-Oriented Analysis 2nd Edition. John Wiley
& Sons, Inc. 2002.
[12] Routledge, N., Bird, L. and Goodchild, A., "UMLand XML Schema", 13th Australsian
Database Conference (ADC2002), Melbourne, Australia.
[13] Henderson, D., and Heide, A. Active Learning in the Digital Age Classroom.
Available WWW: http://www.heinemann.com. Triflolium Books Inc., 2001.
[14] Carey, J., and Gunther, K., and Jon, O., and Tsatsarelis, C. Exploring Learning Through
Visual, Actional and Linguistic Communication: The MultimodalEnvironment of a Science
Classroom. In Educational Review 53, 1 (2001) 5 - 18.
[15] Burmark, L. Visual Literacy: Learn To See, See To learn. Available WWW:
http://www.ascd.org (2002).

290