Académique Documents
Professionnel Documents
Culture Documents
ABSTRACT
Unified Modeling Language (UML) [BRJ98] is fast becoming an industry standard
for modeling various aspects of software systems during development. Many
computer science departments would like to use UML as the modeling tool of
choice in their software engineering courses but the vast scope of the language
makes the task of teaching UML daunting. We have selected a subset of the
modeling diagrams and components that we feel represent a critical core of the
language. This subset is presented in this paper along with an explanation of how
these diagrams and components can be used in an undergraduate software
engineering course without overwhelming the students with details.
INTRODUCTION
The Unified Modeling Language (UML) [BRJ98] is a language for creating software
blueprints. It is fast becoming an industry standard for modeling various aspects of software
systems during the development process. As such, UML is a valuable tool for the aspiring
software engineer and ought to be taught in college software engineering classes. The language
is extremely expressive, allowing multiple aspects of a system to be modeled at the same time.
This expressiveness comes at a price, however. UML is extremely large, with many notational
possibilities. Students attempting to learn UML can easily become mired in detail, missing the
big picture view that is necessary for proper understanding of the goals and processes of
software engineering. In this paper, we present a subset of UML that will allow the instructor
of a software engineering course to communicate the essential details of UML as a tool without
overwhelming students with notational possibilities. This subset of UML will allow the student
to learn additional notational elements as needed in the modeling of increasingly sophisticated
software systems.
A model of a software system is an abstract representation of the system. Usually, a
model is represented visually by one or more diagrams. The model is an attempt to express the
essential aspects of the system. To be useful, the model must be unambiguous and precisely
understood. A modeling language is a way of expressing the models that we’ve developed.
Like other types of languages, a modeling language has a syntax, which determines which
JCSC 15, 5 (May 2000)
8 © 2000 by the Consortium for Computing in Small Colleges
CCSC: Northeastern Conference
elements are allowable on a diagram, and semantics, which determine what a particular diagram
means [PS99]. UML is an example of a modeling language with lots of rules concerning syntax
and semantics. The essential core of the language, however, is easy to learn and easy to
understand.
Although UML can be used with a variety of development methodologies, in this paper,
we will assume that the object-oriented paradigm is to be used throughout development. Of
course, in any development project, the first step is to create a requirements specification. To
begin development in the object-oriented paradigm, the requirements specification is examined
for all nouns. These nouns become the list of potential primary classes. The details concerning
the creation of the requirements specification and the determination of which of the potential
classes become actual classes is beyond the scope of this paper. A more complete discussion
of both of these issues can be found in [SL00].
The role of UML, or any notation for that matter, is to provide an unambiguous, concise,
and effective means to represent the system from a number of perspectives, supporting various
levels of abstraction. UML allows the system modeler to represent the system to be developed
in an abstract or progressively more detailed manner. As the system developers understand the
final system in increasing detail, UML allows this detail to be effectively represented. The
modeling process, therefore, parallels the progress of understanding the system and thus, helps
to control complexity. The desired result of analyzing and designing a system with UML is a
kind of blueprint for implementing the system.
Since modeling a system requires the representation of a number of different views of the
system, one must learn several diagramming methods, each of which expresses a different
aspect of the final system. In UML, the views of any system are divided into two types: static
and dynamic. A static view of the system concerns mostly structural issues such the instance
variables and methods required for each class. A dynamic view of the system expresses the
manner in which the various pieces of the system interact with each other during the actual
functioning of the system. There are several types of diagrams that help to model each of these
views of the system. These diagrams and their uses are the major focus of the rest of the paper.
USE CASES
A use case is a description of a scenario (or perhaps a set of closely related scenarios)
that illustrate the manner in which the system to be developed interacts with the users of the
system. The use cases are created from the requirements specification. The details of this
process are described in more detail in [SL00]. Through the development of the use cases, the
behavior of the system can be expressed without specifying how the behavior is implemented.
In other words, a use case specifies what the system does but not how the system should
accomplish its tasks. Use cases are typically defined informally, in a narrative format. The
following is an example of a use case taken from a Library Management System development
process:
Main flow of events: The use case starts when the system prompts the LibraryStaff for the
Patron's library number. The LibraryStaff can either scan in a card or type in a number and
9
JCSC 15, 5 (May 2000)
then commits the entry by pressing the Enter key. The system then checks to see whether the
library number entered is valid. If it is valid, the system displays the library record for the
Patron, thus ending this use case.
Exceptional flow of events: If the LibraryStaff enters an invalid library number, the system
cancels the entire transaction and this use case ends.
Exceptional flow of events: If the LibraryStaff enters a library number that has expired, the
system cancels the entire transaction and this use case ends.
During the analysis phase of development, use cases such as the above are created for
each major functionality (requirement) of the system. These use cases, along with the list of
primary classes created from the requirements specification, aid in the development of the class
diagrams that will be the basis of the entire development process. In a successful use of the
object-oriented methodology, the transition from use cases to class diagrams should flow
seamlessly. The specific processes used to create class diagrams from use cases can be found
in [SL00].
CLASS DIAGRAMS
Class diagrams model one aspect of the system, the composition of classes. Given that
class definitions are static when the system is in use, class diagrams model a static perspective
of the system. A given system may have many class diagrams, portraying various structural
aspects of the system. The objective of the class diagram is to portray the elements that are part
of a class and the essential relationships that exist between classes. The notational building
blocks of the class diagram, classes and relationships are shown in Figure 1.
The class diagram models the classes that comprise a system. The relationships that exist
between classes must also be shown in class diagrams. The three possible relationships
between classes in class diagrams are association, generalization and dependency and each
is represented by a different type of line and arrow, as shown in Figure 1.
10
CCSC: Northeastern Conference
11
JCSC 15, 5 (May 2000)
OBJECT DIAGRAMS
An object diagram models a set of objects and their interrelationships during a system
snapshot. A system snapshot is the state of the software system at a selected moment in time.
The notational elements comprising object diagrams are objects and links. Recall that an object
is an instance of a class. In a class diagram, two classes may be related to each other via an
association. In an object diagram, instances of two classes, called objects, are related to each
other via a link, which is simply an instance of the association relationship. An object diagram
models the states and interconnections of objects, and serves as another static design view of
the system.
Figure 4 shows an object diagram for the Library Management System. In this object
diagram, a particular Patron object of type Student currently has three Resource objects, all
of type Book, checked out. The object diagram shows that the student contains a List object
which lists the Resources currently checked out by the Patron. Unlike other diagram types,
an object diagram may contain multiple instances of a particular class. The representation of
multiple objects shows that more than one instance of a class may be allocated at a particular
point during execution. This information helps the developers of the system determine
cardinality on the relationships between classes.
12
CCSC: Northeastern Conference
13
JCSC 15, 5 (May 2000)
Figure 6 shows a use case diagram for part of the Library Management System. In the
diagram, the actors are connected to each use case via a solid line with no arrows. This
connection represents an association relationship between the actor and the use case. Some
of the actors represent real world entities that will be represented by classes within the software.
For example, a Patron is a real world entity that will be represented by a class in the software.
Other actors are real world entities with no analogous entity in the system. These actors are,
however, important to understanding the behavior of the software in at least one situation. A
Shelf is such an entity. Two actors that are connected to the same use case via association
relationships interact with each other via the use case. For example, a Patron is associated with
the CheckOutResource use case, as are the Resource and the LibraryStaff actors. This
piece of the use case diagram models the fact that patrons can check out resources and that
library staff assist them in this process. No label is placed on the association relationship
because the meaning of the relationship is contained in the use case name.
Use cases express both the functional requirements of the system and the functional
partitioning of the system. The role of functional partitioning in system development is to
specify well-defined subsets of functionality. These functional subsets of the system identify
logical iterations of the development of the final system. The use case can help to determine
a series of development goals. In other words, given an iterative development approach, use
cases express the manner in which the final system is to evolve during development. Each stage
of system evolution consists of the development of software to implement one or more use
14
CCSC: Northeastern Conference
cases. This functional partitioning is, thus, a means to manage complexity during development.
A particularly complex class may be partitioned into the attributes and methods that apply to
particular use cases in order to facilitate the analysis and design of that class. This partitioning
establishes different roles for the class.
INTERACTION DIAGRAMS
Class diagrams model static perspectives of a system while interaction diagrams model
the dynamic aspects of a system. In particular, class diagrams can be used to express the
structural aspect of a collaboration, in which multiple classes interact to produce a particular
behavior. In other words, a class diagram specifies which classes participate in a collaboration
to realize a particular behavior. An interaction diagram, on the other hand, specifies the
interaction among those classes required to produce that behavior. Two types of interaction
diagrams are defined in UML, collaboration diagrams and sequence diagrams. A
collaboration diagram emphasizes the structural organization of objects that send and receive
messages. A sequence diagram, on the other hand, emphasizes the time ordering of those
messages.
The graphic elements comprising interaction diagrams are shown in Figure 7. An object
is an instance of a class and is represented by a rectangle with the object name as a label. A
message is a method invocation and is the realization of an association between two classes. In
other words, if two classes are related to each other via an association, then instances of those
classes, called objects, are related to each other via a message or method invocation. In an
interaction diagram, we represent a use case as the interaction, via message-passing, between
a set of objects. In a class diagram, on the other hand, the use case is modeled very abstractly
as relationships between classes rather than relationships between actual objects.
COLLABORATION DIAGRAMS
Recall that a set of use cases is created during the analysis process. These use cases
represent general situations that should be able to be handled by the final system. During the
design phase of software development, a use case is modeled as a collaboration diagram. A
collaboration diagram captures some of the dynamic aspects of message passing that must
occur to realize a particular behavior.
15
JCSC 15, 5 (May 2000)
Figure 8 shows a collaboration diagram for the CheckOutResource use case. The
collaboration diagram in Figure 8 illustrates a particular scenario that might be undertaken when
a particular Patron attempts attempts to check out a particular Resource. The diagram shows
that an external actor, the LibraryStaff, assists the Patron by entering the Patron identification
number, via the enterPatron() method, and the Resource identification number, via the
enterResource() method, into the actual LibrarySystem. The LibrarySystem sends
information, again via method invocations, to the Patron object to determine whether the
Patron is valid and to store the Resource information in the Patron object. In addition, the
LibrarySystem sends messages to the particular Resource object (in this case, a Book) as
well as to the LibraryDatabase.
The collaboration diagram specifies what methods must be invoked between objects in
order to realize a particular behavior. The order in which these messages must be invoked may
be critical to the success of the behavior, however, and the collaboration diagram does not
provide this information.
16
CCSC: Northeastern Conference
SEQUENCE DIAGRAMS
A sequence diagram, like a collaboration diagram, shows the messages that are passed
between objects during the execution of a particular scenario. Unlike a collaboration diagram,
a sequence diagram specifies the time ordering of messages. Figure 9 shows a sequence
diagram modeling the CheckOutResource use case. Time is represented vertically in the
diagram. Thus, the first message generated is getResource(ResourceID) sent from the
LibrarySystem object to the LibraryDatabase, and the last message generated is
update(Patron) sent from the Patron object to the LibraryDatabase.
17
JCSC 15, 5 (May 2000)
diagram to the bottom represents the progression of time. Collaboration diagrams provide
information concerning the intervention of external actors while sequence diagrams do not show
such information. Collaboration diagrams are also somewhat easier to read than sequence
diagrams and this is why both diagrams are useful in illustrating dynamic behavioral aspects of
a system.
CONCLUSION
Because UML is quickly becoming the primary modeling language choice in industry, any
project-based software engineering class should present some aspects of UML. UML is a very
large language, however. Presenting the entire language during a semester is impossible.
Software engineering instructors should instead select important features of the language to
familiarize students with the concepts and allow students to learn the rest as needed. In this
paper, we have presented a subset of the Unified Modeling Language that can easily be taught
to undergraduates in a semester-long software engineering course. In particular, we have
presented information regarding class diagrams, use case diagrams, interaction diagrams,
sequence diagrams, collaboration diagrams, and object diagrams. Each of these diagrams has
specific syntax and semantics and is used to model a particular aspect of the system to be
developed. A student familiar with these aspects of UML will be able to model the most
important perspectives of most systems.
BIBLIOGRAPHY
[BRJ98] Booch, G. and Rumbaugh, J. and Jacobson, I. Unified Modeling Language User
Guide. Addison-Wesley, Reading, MA, 1998.
[PS99] Pooley, R, and Stevens, P. Using UML: Software Engineering with Objects and
Components. Addison Wesley Longman Limited, Harlow, England, 1999.
[SL00] Stiller, E. and LeBlanc, C. Object-Oriented Software Engineering: A Project-
Based Approach, Scott-Jones, Inc., El Granada, CA, to be published in 2000.
18