Vous êtes sur la page 1sur 11

UML FOR UNDERGRADUATE SOFTWARE ENGINEERING

Cathie LeBlanc, Evelyn Stiller


Department of Computer Science
Plymouth State College
Plymouth, NH 03264
cleblanc@oz.plymouth.edu, estiller@oz.plymouth.edu

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.

Figure 1. Notational Elements of Class Diagrams

10
CCSC: Northeastern Conference

An association is a labeled relationship between two classes. For example, a patron


checks out a resource. Therefore, the Patron class and the Resource class are associated
with each other through the ChecksOut relationship. A generalization is a hierarchical
relationship between two classes in which one class is the parent of the other class, as in an
inheritance hierarchy. For example, the Patron class is a generalization of the Student class.
In other words, a student is a particular type of patron. Finally, a dependency is a relationship
between two classes in which one class depends on another in some way so that changing one
class might require that the second class also change. For example, an OnlineCatalog object
is probably a collection of Resource objects. If the Resource class were to change, it is very
likely that the OnlineCatalog class has to change. At the very least, we must examine the
OnlineCatalog class to determine whether the Resource class change affects the
OnlineCatalog class. In this manner, the OnlineCatalog class depends upon the Resource
class. Figure 2 shows the class diagram for the Library Management System described in this
example.

Figure 2. Overall Class Diagram for Library Management System


A given class may appear in different class diagrams for different purposes. The class
diagram in Figure 2 shows all the classes that comprise the Library Management System.
During the development process, we may like to model a smaller structural aspect of the
system. For example, Figure 3 shows the classes that collaborate to allow a patron to check
out resources. Each of the classes in this Figure are also shown in other class diagrams but are
included in this class diagram to illustrate the structural component of the check out resource
requirement. A group of classes that interact with each other to implement a particular

11
JCSC 15, 5 (May 2000)

functionality is called a collaboration. In fact, each use case will be represented by a


collaboration.

Figure 3. Class Diagram for the CheckOutResource Collaboration

A collaboration names a set of classes that work together to produce a particular


behavior. A collaboration has two parts, the structural part, which is static, and the
behavioral part, which is dynamic. In a class diagram, we represent only the structural part of
the collaboration. The behavioral part of the collaboration will be discussed in the section on
collaboration diagrams.

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

Figure 4. An Object Diagram for the Library Management System

USE CASE DIAGRAMS


A use case is a description of the manner in which the system should behave in a particular
type of situation. Each use case is described narratively and then modeled more formally using
class diagrams. What has not yet been modeled, however, is how the behaviors of the system
fit together. In other words, we need a mechanism for describing the overall behavior of the
system and how the various behaviors interact with external actors and with each other. To
describe these interactions, we use a modeling technique called use case diagrams. Figure 5
shows the notational elements found in use case diagrams. As in class diagrams, use case
diagrams can model three types of relationships, dependency, association, and generalization.
In addition, use case diagrams contain representations of use cases and of actors, which are
external elements interacting with the system.

Figure 5. Notational Elements of Use Case Diagrams

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.

Figure 6. A Library Management System Use Case Diagram

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.

Figure 7. Notational Elements of Interaction Diagrams

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.

Figure 8. Collaboration Diagram for the CheckOutResource Use Case

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.

Figure 9. Sequence Diagram for the CheckOutResource Use Case

Several notational elements of sequence diagrams are identical to those of collaboration


diagrams. The portrayal of objects as rectangles with an optional, underlined object name
separated by a colon from its underlined class name is the same in both diagrams. The
representation of message passing between objects is also the same. Messages are shown as
method names above solid arrows pointing to the recipient of the message and from the
originator of the message.
In order to represent the time ordering of messages, however, sequence diagrams differ
from collaboration diagrams. In collaboration diagrams, objects are arranged in any manner
which shows message passing with a minimum of crossed lines. Sequence diagrams place
objects in an arbitrary horizontal sequence but vertical progression from the top of a sequence

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

Vous aimerez peut-être aussi