1

SELF-STUDY

Introduction
COURSE PURPOSE
This coursebook was developed for self-study training and will assist in preparing for the
jCert Level two Object Oriented Design and Anaylysis Exam. Along with comprehensive
instructional text and objectives checklists, this coursebook provides easy-to-follow
hands-on lab exercises and a glossary of course-specific terms. It also provides Internet
addresses needed to complete some exercises, although due to the constantly changing
nature of the Internet, some addresses may no longer be valid.

Object-Oriented Analysis and Design is a course that teaches you object-oriented analysis
and design techniques using the Unified Modeling Language (UML). The course
provides an overview of object technology and object-oriented principles such as
encapsulation, abstraction, inheritance, and polymorphism. The course provides specific
examples of UML diagrams as well as techniques used in requirements gathering,
analysis, and design. The course also includes a discussion of proper design techniques
and the object-oriented design metrics you can use to evaluate the strength of a design.
The course concludes with a brief discussion of the implementation and testing processes.

This coursebook will assist you during the class and serve as a valuable resource when you
return to your office or home. After completing this course, you will have experience
using UML to perform analysis and design. You may also consider Martin Fowler’s book
UML Distilled 2nd ed. as an excellent companion to this course.

COURSE GOALS
This self-study course will provide you with the information you need to complete the
following:

● Define object technology and identify its place in the evolution of software
engineering.
● Describe the differences between a structured approach and an object-oriented
approach to software development.
● Identify the advantages and disadvantages of an object-oriented approach to
software development.
● Describe the need for analysis and design.
● Identify the benefits of abstraction and encapsulation.
2 Introduction

● Define a simple object model using the "has a" and "uses a" relationships.
● Describe Jacobson’s application object types.
● Identify the benefits of inheritance, polymorphism, and multiple inheritance.
● Define software development life cycle, and describe various life cycle models.
● Describe the Unified Process, and identify its phases and core workflows.
● Describe the Unified Modeling Language (UML) and its views.
● Identify the role of CASE tools in the software development process.
● Identify the benefits and limitations of CASE tools, as well as criteria for selecting
a CASE tool.
● Install and use Argo/UML.
● Describe the purpose, activities and deliverables of the requirements workflow.
● Identify the actors and use cases of a system.
● Describe the four types of use-case relationship.
● Develop a use-case model to capture project requirements.
● Interpret and create activity diagrams to describe use cases.
● Identify the major goals of user interface design.
● Describe the different types of prototypes.
● Design a system interface.Use the Backus-Naur Form to create an interface control
document.
● Define use-case realization-analysis.
● Interpret and create collaboration diagrams to illustrate a rough vision of system
design.
● Use CRC cards to aid in developing collaboration diagrams.
● Identify aggregation and generalization relationships.
● Identify design subsystems and design classes.
● Use interaction diagrams to assist in creating use-case realizations-design.
● Create a flow-of-events-design.
● Define implementation requirements.
● Create deployment diagrams to describe system architecture.
● Use class diagrams to illustrate system design.
● Identify when it is appropriate to use associations, aggregation, and composition.
 Exercises 3

● Use generalizations to illustrate inheritance.

● Interpret and use sequence diagrams to illustrate the interactions between classes.
● Interpret and develop statechart diagrams to illustrate the internal workings of
individual classes.
● Identify elements of good design.
● Interpret and use object-oriented design metrics.
● Describe the implementation process, and identify executable components.
● Generate program code from design classes.
● Create an integration build plan.
● Describe the test workflow.
● Define test case, test procedure, and test component.

EXERCISES
The exercises in this manual are designed to give you hands-on practice working in both
stand-alone and network environments. It is suggested that you complete the exercises
when referenced. However, this may not always be convenient. If you need to skip an
exercise, you should plan on completing the exercise later when time and circumstances
allow.

You may find that there are some exercises that you are unable to complete due to
hardware or software requirements. Do not let this stop you from completing the other
exercises in this manual.

NOTICE:
The exercises in this self-study product are designed to be used on a system that is
designated for training purposes only. Practicing the exercises on a LAN or workstation
that is used for other purposes may cause configuration problems, which could require a
reinstallation and/or restoration from a tape backup of the original configuration. Please
keep this in mind when working through the exercises.
4 Introduction

SCENARIO-BASED LEARNING
This self-study manual uses a number of scenario-based learning exercises. In these, you
are presented with a situation similar to those you are likely to encounter in day-to-day
support and management. You will be provided with the information you need and
asked to determine the best solution. A suggested solution is provided at the back of the
self-study manual.

These exercises are being used to supplement hands-on practice and to help get you
started thinking critically about practical applications. In some cases, they have been
used as a replacement for hands-on practice for scenarios where it would be especially
difficult to emulate a real-world situation.

It is important that you take the time to work through the scenario-based exercises.
These are an important supplement to the training materials and are meant to reinforce
the text information in your manual.

MULTIMEDIA OVERVIEW
The Interactive Learning CD-ROM is a robust collection of learning tools designed to
enhance your understanding and prepare you for certification. You access these tools
from the Start menu: select Wave Interactive Learning and then select the appropriate
curriculum.

Simulations
Throughout the course, you will see icons asking you to practice the concepts you have
learned in that chapter using NEXTSim. NEXTSim is an interactive simulation product
that provides you with scenario-based training and hands-on experience in a safe
environment. This tool should be used strictly as a supplement to the course and not to
replace the course content.
 Multimedia Overview 5

Videos
A key element of the Interactive Learning CD-ROM included with this course is digital
video. Digital video lessons describe key concepts covered in the manual. Often concepts
are best understood by drawing a picture. Digital video segments provide a graphical
illustration, accompanied by an instructor’s narration. These lessons are ideal both as
introductions to key concepts and for reinforcement.

Assessment
As reinforcement and review for certification exams, the Challenge! Interactive is
significantly helpful. The Challenge! contains sample test items for each exam. The
sample tests are comprised of multiple-choice, screen simulation, and scenario questions
to better prepare you for exams. It is a good idea to take the Challenge! test on a particular
exam, read the study guide and then take the Challenge! test again. It is useful to take the
Challenge! tests as frequently as possible because they are such excellent reinforcement
tools.
6 Introduction

HARDWARE AND SOFTWARE REQUIREMENTS

Hardware Requirements

CIW hardware specifications Greater than or equal to the following

Processor Intel Pentium II (or equivalent) personal computer with processor speed
greater than or equal to 300 MHz
L2 cache 256 KB
Hard disk 2-GB hard drive
RAM At least 128 MB
CD-ROM 32X
Video adapter At least 4 MB
Monitor 15-inch monitor
Internet Connectivity 28.8 modem and ISP account
Sound 16-bit sound card or better with speakers
Network Interface Card 10BaseT and 100BaseT

Software Requirements
● Microsoft Windows 98, ME, 2000, NT 4.0 or higher.
● Netscape Navigator 4.5 or higher.
● Microsoft Internet Explorer 5.5 or higher
● Java Development Kit version 1.2.2 or higher ( http://java.sun.com )
 1

Introduction to Software Engineering

MMAAJJOORR T O P IICCSS

Objectives ........................................................................ 8

Pre-Test Questions........................................................... 8

Introduction .................................................................... 9

Evolution of Software Engineering................................... 9

Programmer vs. Engineer............................................... 11

Object Technology......................................................... 11

Object Oriented vs. Functional Programming ............... 13

Advantages of an Object-Oriented Approach ................. 13

Disadvantages of an Object-Oriented Approach ............ 14

Analysis and Design....................................................... 15

Summary ....................................................................... 16

Post-Test Questions ....................................................... 16

8 Chapter 1—Introduction to Software Engineering

OBJECTIVES
At the completion of this chapter, you will be able to:

● Define object technology and identify its place in the evolution of software
engineering.
● Describe the differences between a structured approach and an object-oriented
approach to software development.
● Identify the advantages and disadvantages of an object-oriented approach to
software development.
● Discuss the need for analysis and design.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What are advantages to an object-oriented approach to programming?

.....................................................................................................................................

.....................................................................................................................................
 Introduction 9

INTRODUCTION
The classical definition of software engineering given by F.L Bauer at a 1968 NATO
conference defines the practice as: “The establishment and use of sound engineering
principles in order to obtain economical software that is reliable and works efficiently on
real machines.” Today, software engineering tends to encourage the use of structured
development methods that promote ease in maintenence and provide viable
programming solutions. In the process of software development, the relationships
between the theoretical and functional stages require a variety of tools with which the
software engineer must be familiar. In application, each engineer may solve the same
problem with differerent tools; yet, common methodologies in which problems are solved
should be recognized. This chapter will discuss the initial steps taken by the software
engineer when approaching a problem and will also introduce the significance of the
analysis and design phase in object oriented programming.

EVOLUTION OF SOFTWARE ENGINEERING

Software engineering is a relatively young discipline. In the 1950s and 1960s, software
development seemed to be a more improvised process. Data was fed through a program,
and the results could be easily identified as either correct or incorrect. Information
capacities were growing, but processing was relatively simple and centralized.

As computers became more powerful, the demand for more complicated software systems
increased. Thus, software engineers looked for better ways to manage the design and
development of information systems. At the same time, structured and functional
programming languages were becoming available. By the early 1970s, analysis and design
methodologies became more formalized.

Analysis and design methodologies provide standardized methods for depicting an

information system before development begins. These early methods focused on the flow
of information into and out of functional subsystems. Figure 1-1 represents a simple
information system as depicted by early structured analysis and design methodologies.
10 Chapter 1—Introduction to Software Engineering

Shipment

Order Inventory Purchase Order

Inventory Order
Ship Order Supplier
Database Inventory

Customer
Order

Order Report
Take Generate
Order Database Management
Order Report
Orders

Order

Figure 1-1: Data flow diagram example

The flow of data is represented by arrows starting from a source, such as a customer, or
through processes, such as taking an order or generating a report, to information
consumers, such as management. By decomposing the system in this way, functional
subsystems can be developed individually. Many of the principles developed in these early
analysis and design models have been carried over into modern object-oriented analysis
and design methodologies.
 Programmer vs. Engineer 11

PROGRAMMER VS. ENGINEER

In any computer science environment where directed teams work together to accomplish
goals in the development of computer based applications, a distinction can be made
between an engineer and a programmer. The classifications of a programmer, or one who
repairs things or follows plans constructed by an engineer within the formal aspects of
coding, fail to address some distinctive duties of a programmer. A software engineer
solves problems by manipulating code and takes part in providing management
techniques and extensive knowledge of design methodologies. A programmer is also
concerned with structural methodologies; the design or organization of tools for solving
problems with coded applications is incomplete without an interaction between the
processes of analysis, design, and implementation. Programmers and software engineers
vitally interact with one another. For an individual to call himself a programmer and not
an engineer is a misunderstanding between the tasks of each. The concepts are inclusive,
and the solutions may be obtained only when one not only acknowledges the purpose
and tasks of the other but also incorperates them towards the accomplishment of the
common goal or solution.

O B J E C T TE C H N O L O G Y
Structured programming models focus their attention on the flow of information
through data-handling functions. Analysis and design allowed system designers and
developers to view software as a set of atomic functions that each performed a specific
task. This view allowed for more rapid development, fewer errors in code, and reduced
project risk. However, as computers became faster, smaller and cheaper, demand
developed for more complicated and less centralized information systems deployed over
multiple computer systems, operating environments, and locations.

Object-oriented methods attempt to address these issues. The fundamental component

of the structured model is its function. Data is generated outside the system and flows
through a set of functions before being stored or processed. In an object-oriented model,
data becomes the fundamental component in the form of objects.
12 Chapter 1—Introduction to Software Engineering

Examine the data flow in Figure 1-1. As a customer places an order, the order
information passes through a "Take Order" function and a "Ship Order" function. In an
object-oriented model, the order information would be identified as an object, which
maintains properties about its state. For example, an order object might maintain a list of
items included in the order, a shipping address, and a billing method.

There are several differences between an object and the data in a structured program. In a
structured program, data is passed through functions that operate on it. In an object-
oriented program, messages are sent to objects that instruct the objects how to operate on
themselves. Figure 1-2 illustrates an order object with the properties that define it.
Instead of passing the order object through a function, however, it is sent a "Ship Order"
message, and the order ships itself.

Ship Order Order

Items
Shipping Address
Billing Method

Figure 1-2: Order object

 Object Oriented vs. Functional Programming 13

OBJECT ORIENTED VS. FUNCTIONAL PROGRAMMING

As the complexity of software increases, understanding its structure becomes a
requirement. Although well-structured software may be efficiently developed using a
variety of methods, this section considers the difference between programming using a
functional programming language and using an object oriented language. Functional
programming is a language in which the evaluation of expressions assigns values to
statements. These statements can be manipulated as variables, unlike the methodical
commands given in an object-oriented environment. Functional programming is also
useful in sorting and processing lists and in providing the ability to define complex
mathematical functions. Functional languages, such as Standard ML, Miranda, or
Haskell, allow function definitions resulting from matched patterns within the program
as well as higher-order function definitions. Functional languages are also widely used for
defining program-specific algebraic types.

The analysis and design of a functional program is in many ways structurally similar to a
program constructed in an object-oriented framework. The organization of program
behavior is similar since the levels of data abstraction in both languages may accomplish a
similar task. However, the steps to reach the goal in a functional program may require
added complexity, which may be simplified in the use of an object-oriented language.
The next section gives a structured overview of these benefits.

ADVANTAGES OF AN OBJECT-ORIENTED APPROACH

Like structured programming, object-oriented programming is used to manage the
complexity of large software systems. However, object technology provides several other
advantages such as: easier maintainance, more reusable components, and greater scalable
ability.

Maintainable
Object-oriented programming methods make code more maintainable. Identifying the
source of errors is easier because objects are self-contained. Later in this course, certain
principles of proper object-oriented design that contribute to a program's maintainability
will be introduced.
14 Chapter 1—Introduction to Software Engineering

Reusable
Because objects contain both data and methods that act on data, objects can be thought
of as self-contained black boxes. This feature makes it easy to reuse code in new systems.
Messages provide a predefined interface to an object's data and functionality. With this
interface, an object can be used in any context. Later in this course, you will learn how to
expand on the functionality of objects, even if you know very little about their
implementation.

Scalable
Object-oriented programs are also scalable. As an object's interface provides a road map
for reusing the object in new software, and provides all the information needed to replace
the object without affecting other code. This way aging code can be replaced with faster
algorithms and newer technology.

DISADVANTAGES OF AN OBJECT-ORIENTED APPROACH

A few challenges present themselves in transitioning to an object-oriented approach for
software engineering. Many legacy systems are built with a structural framework.
Interfacing with these systems does not provide a technical challenge as much as a design
challenge. The goal is to minimize the effects of structural systems on the object-oriented
nature of the new designs.

Retraining can also be an issue. Object-oriented programming has existed since the early
1980s. However, object-oriented principles did not appear in educational curriculum
until about 1995.
 Analysis and Design 15

ANALYSIS AND DESIGN

Analysis and design are the first steps in the development of a software system. Analysis is
the process of gathering software requirements and recording them in a standardized
format that can be translated into design. Customers, managers, and end-users speak a
different language than software engineers. Analysis bridges the gap between those who
will use a software system and those who will design and code a software system.

Design is the process of translating the output of analysis into a blueprint for the actual
coding of a software system. Like a blueprint for a building, the design will show enough
detail to allow a diverse group of managers and programmers to develop the system
concurrently.

The focus of this course is on analysis and design. However, analysis and design do not
exist in a vacuum; they are part of a larger process of developing object-oriented software.
A development methodology details the entire process of software development, from
gathering requirements to design, coding, and deployment. To fully understand the roles
of analysis and design in the software development process, they will be taught in the
context of the Unified Software Development Process, or Unified Process.

Software crisis
Analysis and design serve several purposes. They allow developers to foresee technical
difficulties. They help ensure that the product will match users' needs and expectations.
Most importantly, they help managers to minimize risk. Developing software is a time-
consuming and expensive process. Because software is intangible, it can be difficult to
assess development progress. When product deployment is delayed as a result of problems
in software development, a software crisis is said to exist. Analysis and design procedures
and development methodologies help to prevent the software crisis by providing
managers with a framework to measure a development organization's performance and
potential for success.
16 Chapter 1—Introduction to Software Engineering

Exercise 1-1: Using an object-oriented approach

If you have prior experience with a structural programming language, the transition to an
object-oriented paradigm can be difficult. In this exercise, you will begin training yourself
to think from an object-oriented perspective.

1. Examine Figure 1-1. Identify possible objects that could form an object-oriented
system to perform the same task.
2. Identify the properties that define the objects found in Step 1 of this exercise.
3. Identify the messages that define the interface to objects found in Step 1.

SUMMARY
Software engineering is a relatively young discipline. Early analysis and design
methodologies focused on tracing the path of data through functional components.
Object-oriented analysis and design identifies objects, determines properties that define
objects, and determines messages to which objects should respond. Object-oriented
techniques make code more maintainable, reusable, and scalable. Analysis and design
help managers to minimize risk.

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. Why are objects often easy to reuse?

.....................................................................................................................................

.....................................................................................................................................
2. How do analysis and design help prevent a software crisis?

.....................................................................................................................................

.....................................................................................................................................
 2

Understanding the Object Paradigm

MMAAJJOORR T O P IICCSS

Objectives ...................................................................... 18
Pre-Test Questions......................................................... 18
Introduction .................................................................. 19
Classes ........................................................................... 19
Classes and Functions .................................................... 20
Abstraction .................................................................... 25
Adding and Naming Classes .......................................... 26
Operation Visibility ....................................................... 26
Class Responsibility ....................................................... 27
Instantiation .................................................................. 28
Object Communication ................................................. 28
Object Relationships...................................................... 28
Application Objects ....................................................... 30
Summary ....................................................................... 32
Post-Test Questions ....................................................... 32
18 Chapter 2—Understanding the Object Paradigm

OBJECTIVES
At the completion of this chapter, you will be able to:

● Explain the difference between classes and instances.

● Describe two common method types and their applications.
● Identify the benefits of abstraction and encapsulation.
● Describe communication among objects.
● Define a simple object model using the has a and uses a relationships.
● Describe Jacobson's application object types.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. How do abstraction and encapsulation augment the reusability of objects?

.....................................................................................................................................

.....................................................................................................................................
2. What three types of objects did Jacobson identify in object-oriented software
systems?

.....................................................................................................................................

.....................................................................................................................................
 Introduction 19

INTRODUCTION
In object oriented software design, object dynamics and object communication are vital
to system integrity. The organization and accessibility of object properties can be
implemented by a variety of structures, including classes, methods, and functions. These
are manipulated by processes, such as data instantiation, encapsulation, and abstraction.
The classification of object relationships also plays a vital role in organizing object
abstraction and inter-system communication.

CLASSES
Objects are the building blocks of an object-oriented software system. They model real-
world collections of information (such as a purchase order) and are able to modify
themselves.

A class provides the blueprint for an object. For example, a library check-out system
manages the movement of thousands of books, as patrons check them out and return
them. Each book is represented by an object that maintains properties, such as the title,
the author, and the ISBN. A class provides a blueprint for these objects. Throughout this
chapter and the next, you will study short code examples written in Java and C++. The
following Java code is the class definition of a book:
class Book
{
String title;
String author;
String isbn;
}
20 Chapter 2—Understanding the Object Paradigm

The same class is defined using C++ as follows:

class Book
{
char *title;
char *author;
char *isbn;
}
The properties that form a class are its member variables. The Book class has three
member variables: title, author, and ISBN. Once a Book object is instantiated, values can
be assigned to its member variables to define the unique characteristics of this book. Both
Java and C++ use dot notation to access member variables. The following Java code
assigns values to the member variables:
catcherInTheRye.title = "Catcher in the Rye";
catcherInTheRye.author = "J. D. Salinger";
catcherInTheRye.isbn = "0-316-76948-7";

CLASSES AND FUNCTIONS

In addition to member variables, classes have methods, which access and modify member
data. Programmers who have experience using structured programming languages, such
as C and Pascal, will recognize that methods are similar to functions. A method, however,
is specific to a particular class. It always takes an action, with respect to the class in which
it is defined.

As part of a specific class, a method is associated with any object of that class. While it is
possible for a class or object to have multiple methods, a method may only access
information pertaining to one object. This prevents the exchange of data among objects
and limits data corruption.
 Classes and Functions 21

Imagine a library system developed using a structural programming language. Two

abstract data types exist: one representing a book, and a second representing a binary
search tree of all books (a book collection). Using C, the code to add a book to the book
collection might be similar to the following:
addBook(bookCollection, book);
A function addBook takes two parameters: a Book to be added and a BookCollection to
which you add the Book. The addBook function is defined outside of the definition of the
BookCollection data type, even though the two are closely related. In an object-oriented
system, addBook would be defined as a method of a BookCollection class. Member
methods can be accessed using the same dot notation used to access member data:
bookCollection.addBook(book);
The addBook method can be thought of as a function in which an instance of
BookCollection is implicitly passed. This bundling of functionality with data is
fundamental to object-oriented programming.

Two common types of methods are accessors and mutators, which are used to access and
modify member data. They are used as an alternative to accessing member data directly
using the dot notation discussed in the previous section.
22 Chapter 2—Understanding the Object Paradigm

Accessors
Accessor methods can be used to ask an object about itself. Rather than accessing member
data directly, accessors provide a safe interface to an object. Following is the Book class
definition with accessors added using Java:
class Book
{
String title;
String author;
String isbn;

String getTitle();
String getAuthor();
String getISBN();
}
The same class is defined using C++ as follows:
class Book
{
char *title;
char *author;
char *isbn;

char *getTitle();
char *getAuthor();
char *getISBN();
}
In the new class definition, prototypes are added for three accessor methods: getTitle,
getAuthor, and getISBN. These methods are used to access the member data.
 Classes and Functions 23

Mutators
Mutators are member methods that are used to modify member data. Like accessors,
mutators prevent programmers from accessing member data directly. Following is the
Book class definition with mutators added using Java:

class Book
{
private String title;
private String author;
private String isbn;

public String getTitle();

public String getAuthor();
public String getISBN();

public void setTitle(String);

public void setAuthor(String);
public void setISBN(String);
}
24 Chapter 2—Understanding the Object Paradigm

The same class is defined using C++ as follows:

class Book
{
private:
char *title;
char *author;
char *isbn;

public:
char *getTitle();
char *getAuthor();
char *getISBN();

void setTitle(char*);
void setAuthor(char*);
void setISBN(char*);
}
Three mutators have been added to the Book class: setTitle, setAuthor, and setISBN.
The public and private keywords set access privileges for the Book class. The member data
is declared as private, which prevents member data from being accessed directly from
outside the class. To access the member data, you must use the publicly declared accessors
and mutators.

Encapsulation
The use of accessors and mutators offers many advantages. By hiding the implementation
of the Book class, you can make changes to the implementation without disrupting the
design of other classes. Consider the C++ class definition in the previous example.
Replace the character arrays used to hold the title, author, and ISBN with a string class.
Provided that all access to Book data is restricted to accessors and mutators, the change
will be transparent to the rest of the program. This type of data protection is called
encapsulation. Accessors and mutators can be thought of as surrounding the data that
forms a class. Figure 2-1 illustrates the encapsulation of the Book class.
 Abstraction 25

ge
N
SB

tTi
tI

tle
ge
title
author
isbn

getAuthor

Figure 2-1: Book class

ABSTRACTION
Encapsulation plays an important role in developing objects as black boxes. The process
of developing classes in terms of their interfaces and functionality, instead of their
implementation details, is called abstraction.

Abstraction is used to manage complexity; software engineers use abstraction to break

complex systems into smaller components. As development progresses, programmers
know the functionality they can expect from as yet undeveloped subsystems. Thus,
programmers are not burdened by considering the ways in which the implementation of
later subsystems will affect the design of earlier development.
26 Chapter 2—Understanding the Object Paradigm

ADDING AND NAMING CLASSES

As shown, each class has unique properties, which are known as the class definitions. In
the above examples, class definitions include the accessor methods of getTitle(),
getAuthor(), and getISBN(), and the mutator methods of setTitle(), setAuthor(), and
setISBN(). These definitions are part of a class. Before they can be used, however, an
instance must be created.

OPERATION VISIBILITY
In the above examples of mutators, the functions were grouped into two areas: private
and public. This exemplifies the used of object visibility. Object visibility specifies which
parts, if any, of a class are visible (i.e. modifiable or viewable) to other parts of a program.

There are three major classes of object visibility: public, protected, and private. Public
data are those that are visible from anywhere inside a program. In the above examples, the
mutators setTitle(), setAuthor(), and setISBN() are declared public. This occurs
because the entire program must be able to see and use those functions to modify the
Book class data.

Private data are only visible from within their class. The actual variables of Title, Author,
and ISBN in the above examples are private, because they do not need to be visible and/or
modifiable by the rest of the program. If users can use the publically declared mutators to
modify the private data, why make the variables private at all? Although there are many
reasons, safety is the most important. By making the data private and only modifiable by
the mutators, the data is not directly modifiable by other functions in the program. This
way, error checking can be performed before the data is modified, or there can be a log
recording which part of the program modified the data.

There is also the type of protected. Protected data will only be visible within a certain
hierarchy of classes. For example, in a class named Vehicle, which includes subclasses of
Car, Truck, and Van, protected data can be visible to the subclasses of Car, Truck, and Van.
 Class Responsibility 27

CLASS RESPONSIBILITY
Each class has its own data and actions, which are known as the class’s responsibilities.
Anything that the class has knowledge of and/or performs is known as its responsibilities.
Using the above examples, the Book class has responsibilities in the form of its Name,
Author, and ISBN number. It also has the ability to be checked in or out. This is
graphically described in the following diagram.

Figure 2-2: Class Responsibility

28 Chapter 2—Understanding the Object Paradigm

INSTANTIATION
Class definitions can be used to create objects. This process is called instantiation, and the
objects created are called instances. These instances serve as realizations of the class
definitions. Following is the Java code to instantiate a Book object:
Book catcherInTheRye = new Book();
The code to instantiate a Book object using C++ is as follows:
Book catcherInTheRye = Book();

OBJECT COMMUNICATION
Due to the black box nature of objects, communication between objects is carried out
through messages. Classes not only define objects, but also determine which messages are
related to those particular objects. Because all communication and functions of objects
are possible with a message interface, no other form of communication is needed. One
doesn’t even need to know what is contained by an object to use it.

In this type of communication, an object cannot be directly modified. Since, code and
data are fused within an object in object-oriented software, it is best that the information
within an object be left undisturbed so as not to disrupt the normal functionality of the
object. Thus, by only allowing communication with objects through their messages, the
code and data within the object is protected. This is known as information hiding, or
encapsulation.

OBJECT RELATIONSHIPS
Objects do not exist in isolation, but as part of a larger system of objects that must
interact with each other. The most fundamental relationship between objects is the has a
relationship. The Java implementation of the Book class has three String attributes: title,
author, and ISBN. String is a class, and the relationship between the Book class and the
String class is illustrated in Figure 2-3.
 Object Relationships 29

Figure 2-3: The has a relationship

The preceding figure is an example of a Booch class diagram. Grady Booch developed
this notation for representing the relationships between the classes that comprise a
software system. The simplest relationship is the has a relationship. The filled-in circle at
one end of the connecting line indicates that it is the Book that has the String.

Objects are more than abstract data types. In addition to their attributes, objects exhibit
behavior. In a library check-out system, for example, a library card is issued, a book is
checked out, and a patron pays an overdue fine. Accessors and mutators provide an access
layer to member data, but other methods exist to give the object more specific behavior.
These methods can be denoted with a uses a relationship. Figure 2-4 illustrates the
relationship between the Patron, Book and Fine classes.

Patron checks out Book

pays

Fine

Figure 2-4: The uses a relationship

30 Chapter 2—Understanding the Object Paradigm

APPLICATION OBJECTS
Ivar Jacobson identified three major types of objects that comprise an object-oriented
software system: entity objects, interface objects, and control objects. These types persist
in the Unified Process as entity classes, boundary classes, and control classes.

Entity objects
Entity objects model real-world objects. All of the objects you have studied thus far have
been examples of entity objects. The analysis process begins by identifying business
information entities, such as different types of reports, customer information, or
inventory information. Most of these information entities can be translated directly into
entity objects.

The business information entities of a library system include books, a book collection,
patrons, librarians, addresses, and fees. Each of these can be translated into an entity
object.

Interface objects
Interface objects bridge the gap between a system and its users. The objects that form a
graphical user interface are examples of interface objects. Interface objects often take the
form of window, terminal, or printer objects. Figure 2-5 illustrates the relationship
between interface objects and entity objects.

Card Catalog Book Collection

Patron Uses Searches
Terminal Database

Figure 2-5: Interface objects

 Application Objects 31

For example, patrons interact with a library's information system through a card catalog
terminal. In the preceding figure, the card catalog terminal is represented by an interface
object. In the completed software system, this interface object would implement the user
interface.

The Unified Process refers to interface objects as boundary classes because they act as the
boundary between a software system and its users.

Control objects
Control objects implement complex business logic that cannot be easily implemented in
either entity or interface objects. Control objects typically represent schedulers,
sequencers, and other concepts that can be used to tie a system together. Figure 2-6
illustrates the relationship between control objects and entity objects.

Book Collection
Database

Uses

Fine
Issues Fine Pays Patron
Scheduler

Figure 2-6: Control objects

For example, fines are issued when a book is overdue. In the preceding figure, the Fine
Scheduler object uses information it collects from the Book Collection Database to
determine when to issue a fine.
32 Chapter 2—Understanding the Object Paradigm

SUMMARY
Objects are the building blocks of object-oriented software systems. Instantiation is the
creation of an object based on class definitions. Encapsulation provides a barrier between
users of an object and an object's implementation details. Accessors and mutators
accomplish the goal of encapsulation. Encapsulation is closely related to the concept of
abstraction. Objects communicate through a message interface. Objects relate to each
other in several different ways, and class diagrams are used to denote the relationships
between objects. Most objects can be classified as one of three major object types: entity
objects, interface objects, or control objects.

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. Why do “uses a” and “has a” relationships make reusing objects more

complicated?

.....................................................................................................................................

.....................................................................................................................................
2. Why are class diagrams used?

.....................................................................................................................................

.....................................................................................................................................
 3

Inheritance and Polymorphism

MMAAJJOORR T O P IICCSS

Objectives ...................................................................... 34

Pre-Test Questions......................................................... 34

Introduction .................................................................. 35

Inheritance..................................................................... 35

Inheriting Attributes ...................................................... 37

Inheriting Methods........................................................ 38

Extending Components with Inheritance....................... 40

Polymorphism ............................................................... 43

Abstract Classes ............................................................. 44

Multiple Inheritance ...................................................... 47

Summary ....................................................................... 49

Post-Test Questions ....................................................... 49

34 Chapter 3—Inheritance and Polymorphism

OBJECTIVES
At the completion of this chapter, you will be able to:

● Identify the benefits of inheritance.

● Identify the benefits of polymorphism.
● Define the abstract class.
● Identify the benefits of multiple inheritance.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. How does inheritance enable software reuse?

.....................................................................................................................................

.....................................................................................................................................
2. How does polymorphism overcome some of the limits of inheritance?

.....................................................................................................................................

.....................................................................................................................................
 Introduction 35

INTRODUCTION
This chapter examines two powerful components of object oriented programing,
inheritance and polymorphism. Inheritance takes advantage of the similarities that exist
between various classes; its benefits include data generalization and code reduction.
Inheritance can be compared to scientific classification, because science begins with a
large collection of objects which are then split into refined classes (this is called
encapsulation). These classes are then organized hierarchically into more abstract classes
(inheritance). In software development, the design of classes and of the inheritance
hierarchies occurs simultaneously. Polymorphism uses inheritance to gain system
extensibility. For example, a parent class may contain a virtual function, which can be re-
defined by its children. Using polymorphism, new objects can be defined without
introducing new code.

INHERITANCE
In the previous lesson, you learned that objects can relate to each other with either a has a
or uses a relationship. Inheritance is a third type of relationship between objects: the is a
relationship.

For example, a library lends more than just books; it also lends magazines, audiocassettes,
and microfilm. On some level, all of these items can be treated in the same manner, since
all four types represent lendable assets. However, also consider the differences: A book has
an ISBN and a magazine does not; audiocassettes have a play length; and microfilm
cannot be checked out overnight.

Each of these assets should be represented by its own class definition. However, without
inheritance, each class must independently implement the characteristics that are
common to all lendable assets. All assets are either checked out, or available for checkout.
All assets have a title, a date of acquisition, and a replacement cost. Rather than duplicate
functionality, inheritance allows you to inherit functionality from another class, called a
superclass.
36 Chapter 3—Inheritance and Polymorphism

Rather than duplicate functionality, object-oriented programming allows you to define a

base class, such as LendableAsset, which maintains the characteristics common to all
lendable assets. Figure 3-1 illustrates the relationship between the LendableAsset class and
the classes that inherit from it.

LendableAsset

Book Magazine Audiocassette Microfilm

Figure 3-1: Inheritance

 Inheriting Attributes 37

INHERITING ATTRIBUTES
LendableAsset is a superclass that maintains only the data and methods that are common
to all lendable assets. Book, Magazine, Audiocassette, and Microfilm are subclasses of the
LendableAsset class, and so they inherit these characteristics. The inheritance
relationship is called the is a relationship. A Book is a LendableAsset, as are a Magazine,
an Audiocassette, and Microfilm. Following are the class definitions for the
LendableAsset, Book, and Audiocassette classes using Java:

class LendableAsset
{
String title;
Date acquisitionDate;
float replacementCost;
boolean checkedOut;
}

class Book extends LendableAsset

{
String author;
String isbn;
}
class Audiocassette extends LendableAsset
{
int playLength;
}
38 Chapter 3—Inheritance and Polymorphism

In the previous example, the LendableAsset class defines properties relevant to all
lendable assets. The Book and Audiocassette classes inherit these properties. In Java, the
extends keyword is used to indicate inheritance. When these subclasses are instantiated,
the properties they inherit from the LendableAsset class can be accessed using dot
notation. For example:
Book catcherInTheRye = new Book();
catcherInTheRye.title = "Catcher in the Rye";
catcherInTheRye.author = "J. D. Salinger";
catcherInTheRye.isbn = "0-316-76948-7";
catcherInTheRye.checkedOut = false;

INHERITING METHODS
Methods can also be inherited. Figure 3-2 illustrates the relationships between the Patron,
LendableAsset, Book, and Audiocassette classes.

Book

Patron checks out LendableAsset

Audiocassette

Figure 3-2: Inheritance relationships

 Inheriting Methods 39

A Patron can check out a LendableAsset. "Check out" is an example of a uses a

relationship, which often translate into class methods. The following code is modified to
include a checkOut method in the LendableAsset class:
class LendableAsset
{
String title;
Date acquisitionDate;
float replacementCost;
boolean checkedOut;
public void checkOut()
{
checkedOut = true;
}
}
Using this new LendableAsset class definition, the Book and Audiocassette classes
automatically inherit the ability to be checked out. The following Java code illustrates this
fact:
Book bookInPrint = new Book();
Audiocassette bookOnTape = new Audiocassette();

bookInPrint.checkOut();
bookOnTape.checkOut();
40 Chapter 3—Inheritance and Polymorphism

EXTENDING COMPONENTS WITH INHERITANCE

One of the most powerful features of inheritance is the ability to extend components,
without any knowledge of class implementation. The following code is a simplified class
definition for the Date class in the Java API:
public class Date extends objects
{
// Public Constructors
public Date();
public Date(long date);
// Methods
public boolean after(Date when);
public int getDate();
public int getDay();
public int getHours();
public int getMinutes();
public int getMonth();
public int getSeconds();
public int getYear();
public void setDate(int date);
public void setHours(int hours);
public void setMinutes(int minutes);
public void setMonth(int month);
public void setSeconds(int seconds);
public void setYear(int year);
}
 Extending Components with Inheritance 41

This class definition depicts only the publicly defined methods of the Date class. No
implementation details are known. The problem is that the Java Date class provides no
mechanism for determining the date three weeks in the future (when a LendableAsset is
due). Using inheritance, this functionality can be added in a derived class, called DueDate.
The following code defines the new DueDate class:
class DueDate extends Date
{
public void addDays(int days)
{
setDate(getDate() + days);
}

public void addHours(int hours)

{
setHours(getHours() + hours);
}
}
42 Chapter 3—Inheritance and Polymorphism

The new DueDate class inherits the functionality of the Java API Date class, and adds two
new methods to allow calculation of a due date. Figure 3-3 illustrates the relationship
between the LendableAsset class and the new DueDate class.

Book

Patron checks out LendableAsset

Audiocassette
has

DueDate

Date

Figure 3-3: DueDate Class

 Polymorphism 43

POLYMORPHISM
In the previous section, you learned that classes can inherit methods from other classes.
The Book and Audiocassette classes inherit the checkOut method from the
LendableAsset class. However, behavior may need to be modified depending on the
subclass. For example, all lendable assets have a due date. Books and audiocassettes can be
checked out for 21 days, but microfilm is due back within three hours. Polymorphism
allows subclasses to override methods defined in their base class. Because assets are
generally due in 21 days, the calculateDueDate method adds 21 days to the current date
to calculate a due date. Study the following code:
class LendableAsset
{
String title;
Date acquisitionDate;
float replacementCost;
boolean checkedOut;
DueDate dueDate;

public void checkout()

{
checkedOut = true;
}

public void calculateDueDate()

{
dueDate = new DueDate();
dueDate.addDays(21);
}
}
44 Chapter 3—Inheritance and Polymorphism

The Microfilm class can use polymorphism to override the calculateDueDate method
defined in the LendableAsset class, as shown:
class Microfilm extends LendableAsset
{
public void calculateDueDate()
{
dueDate = new DueDate();
dueDate.addHours(3);
}
}
When calculateDueDate is called on a LendableAsset object, a decision is made. If the
object is of type Book or Audiocassette, the calculateDueDate method defined in the
base class LendableAsset is called. If the object is of type Microfilm, the
calculateDueDate method defined in the Microfilm class is called. This process is called
late binding.

ABSTRACT CLASSES
In the preceding section, you learned that subclasses can override methods defined in the
classes from which they are derived. In the example, the Microfilm class defines a
method, CalculateDueDate, that overrides the same method defined in the base class
LendableAsset.

From a design perspective, this relationship seems incorrect. The LendableAsset class
defines the CalculateDueDate method that assumes the due date to be three weeks in the
future. While all instances of LendableAsset have a due date, not all calculate that due
date in the same way. It becomes the responsibility of the derived class to identify itself as
a special case and override this method to calculate a correct due date.
 Abstract Classes 45

The answer to this design issue is an abstract class. An abstract class declares methods
without providing any implementation. When a subclass inherits from an abstract base
class, it must override these methods to provide the requisite functionality. The abstract
class cannot be instantiated, it can only be extended. The following code is modified to
define LendableAsset as an abstract class:
abstract class LendableAsset
{
String title;
Date acquisitionDate;
float replacementCost;
boolean checkedOut;
DueDate dueDate;

public void checkout()

{
checkedOut = true;
}
public void calculateDueDate();
}

class Book extends LendableAsset

{
String author;
String isbn;

public void calculateDueDate()

{
dueDate = new DueDate();
dueDate.addDays(21);
}
}
46 Chapter 3—Inheritance and Polymorphism

class Audiocassette extends LendableAsset

{
int playLength;

public void calculateDueDate()

{
dueDate = new DueDate();
dueDate.addDays(21);
}
}
class Microfilm extends LendableAsset
{
public void calculateDueDate()
{
dueDate = new DueDate();
dueDate.addHours(3);
}
}
Notice that the calculateDueDate method is declared in the LendableAsset class, but is
only implemented by the derived classes Book, Audiocassette, and Microfilm.
LendableAsset is an abstract class, and because it is missing functionality, it cannot be
instantiated. The abstract class implements functionality in derived classes; it defines a
common interface to all derived classes without making unwarranted assumptions about
implementation.
 Multiple Inheritance 47

MULTIPLE INHERITANCE
Early in this chapter, you learned that inheritance allows the Book, Magazine,
Audiocassette, and Microfilm classes to inherit common characteristics from a base
class, LenadableAsset. Occasionally, however, single inheritance is not enough.

For example, a magazine is a lendable asset, and it is also a subscribable asset. The library
system must be able to track magazine subscriptions and automate subscription renewal.
If Magazine were the only class that ever exhibited these characteristics, you could build
the subscribable functionality into the Magazine subclass. However, newspapers can be
added to the library system. Recent newspapers are available for reading in the library, but
they are not lent out. Since newspapers are subscribable assets, the library system must
also be able to track its newspaper subscriptions.

Multiple inheritance allows the Magazine class to inherit characteristics from both the
LenadableAsset class and the SubscribableAsset class. The following C++ code
demonstrates multiple inheritance using the Magazine class:
class SubscribableAsset
{
public:
float subscriptionPrice;
DaterenewDate;

void renewSubscription();
}

class Newspaper : SubscribableAsset

{
public:
Date date;
}
48 Chapter 3—Inheritance and Polymorphism

class Magazine : SubscribableAsset, LendableAsset

{
public:
intvolume;
intissue;
}
The Newspaper class extends the SubscribableAsset class, and the Magazine class extends
both the SubscribableAsset class and the LendableAsset class. Figure 3-4 illustrates the
relationship between the Magazine class and both of its parent classes.

Subscribable
LendableAsset
Asset

Newpaper Magazine

Figure 3-4: Multiple inheritance

 Summary 49

Exercise 3-1: Using inheritance and polymorphism

1. Consider the grocery store inventory system from the previous chapter’s exercise.
Identify classes that could benefit from multiple inheritance.
2. Develop a revised class diagram to add multiple inheritance to the grocery store
inventory system.

SUMMARY
Inheritance is a third type of object relationship, known as the is a relationship.
Inheritance allows a class to inherit the attributes and functionality of a superclass, or base
class. Inheritance can be used to extend components even if very little is known about a
class's implementation. Polymorphism allows subclasses to override methods defined
higher in the class hierarchy. Abstract classes allow you to avoid making presumptions
about implementation before the design requires it. Multiple inheritance is available with
some object-oriented programming languages; it allows a class to inherit from two or
more superclasses.

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What is the responsibility of all subclasses that inherit from an abstract class?

.....................................................................................................................................

.....................................................................................................................................
2. Is an intricate knowledge of the implementation of a class necessary in order to
inherit from it?

.....................................................................................................................................

.....................................................................................................................................
50 Chapter 3—Inheritance and Polymorphism
 4

Software Development Life Cycle

MMAAJJOORR T O P IICCSS

Objectives ...................................................................... 52

Pre-Test Questions......................................................... 52

Introduction .................................................................. 53

Software Development Life Cycle Model ....................... 53

Waterfall Life Cycle Model ............................................ 56

V-Shaped Life Cycle Model............................................ 58

Incremental Life Cycle Model ........................................ 60

Spiral Life Cycle Model.................................................. 61

Summary ....................................................................... 63

Post-Test Questions ....................................................... 64

52 Chapter 4—Software Development Life Cycle

OBJECTIVES
At the completion of this chapter, you will be able to:

● Define software development life cycle.

● Describe the Waterfall life cycle model.
● Describe the V-Shaped life cycle model.
● Describe the Incremental life cycle model.
● Describe the Spiral life cycle model.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What is a software development life cycle?

.....................................................................................................................................

.....................................................................................................................................
2. What are the four main phases of the general software development life cycle
model?

.....................................................................................................................................

.....................................................................................................................................
 Introduction 53

INTRODUCTION
Software for business applications, whether it is intended to perform a single task or it is
intended for use as a company-wide, integrated system, should be tailored to fit the
company’s unique needs and goals. In the simplest terms, the software should be capable
of performing all the functions necessary to perform a task efficiently. While the software
should be inclusive, it should not be unduly cumbersome. Careful attention is required to
develop software that is both functional and efficient. Once the software is in use, it must
be maintained. In this chapter, we will discuss several processes which can serve as
guidelines for software development.

SOFTWARE DEVELOPMENT LIFE CYCLE MODEL

The term software development life cycle model is a way of describing the planning,
designing, coding, and testing of a software system, as well as the method in which these
steps are implemented. A variety of life cycle models exist, but they all include the same
constituent parts. All life cycle models take a project through several primary phases: a
requirements-gathering phase, a design phase, a construction or implementation phase,
and a testing phase. Figure 4-1 provides a simplified illustration of the general software
development life cycle model.

Requirements Design Implementation Testing

Figure 4-1: General software development life cycle model

Each phase produces feedback that affects the next phase. For instance, the requirements
gathered during the requirements phase influence the design, which is translated into
working software code during the implementation phase. The software code is verified
against the requirements during the testing phase.
54 Chapter 4—Software Development Life Cycle

Requirements-gathering
During the requirements-gathering phase, the needs of the company are outlined.
Managers and users (and in some cases, clients) make their “wish-lists” about what they
would like the software to do. Analysts ask questions about the intended use of the
software, what type of data will be processed, how the software should handle the data,
and how the data can be accessed once in the system.

Following the requirements phase, the software development team should have a detailed
list of functions that the system will perform. Emphasis is on the system's goals, rather
than the way in which the system will achieve those goals.

Design
In the design phase, the results of the requirements-gathering phase are translated into a
software design plan. Focus shifts from the system's results to the way in which those
results will be achieved and how the ideas of the requirements-gathering phase are
accomplished. Designers consider many different criteria, from the hardware and
operating system platform that hosting the software to the way subsystems will
communicate with each other.

In essence, during the design phase, the designers attempt to turn the dreams of the
managers and users into reality. Emphasis during this phase is on making a practical,
working design for what has been outlined in the requirements-gathering phase.
 Software Development Life Cycle Model 55

Implementation
In the implementation phase, the results of the design phase are translated into program
code. Software that does not meet the needs of the company is wasteful. During this
phase the programmers should make it their central goal to fulfill the requirements of the
company and to meet the design outlined in the design phase.

The classes and class interactions developed in the design phase are very explicit. They
translate directly into the code generated in the implementation phase. Later in this
course, design tools will be introduced that actually automate code generation from the
output of the design phase.

Testing
In the testing phase, the results of the implementation phase are run through a series of
tests to verify that it functions and that it meets goals of the requirements phase. A testing
plan is created to describe the unit tests and system tests that will be performed. Unit
testing is performed on individual software components. The process of integration
brings together all the software components to create a complete system. System testing is
performed on the software system as a whole.
56 Chapter 4—Software Development Life Cycle

WATERFALL LIFE CYCLE MODEL

The Waterfall life cycle model, also known as the classic or linear-sequential life cycle
model, is one of the simplest to understand and use. The Waterfall model is characterized
by a series of steps that must be completed in a linear, sequential order. Each phase is
completed and verified before development progresses to the next phase. Figure 4-2
illustrates the Waterfall life cycle model.

Requirements

Design

Implementation
and Unit Testing

Integration and
System Testing

Operation

Figure 4-2: Waterfall life cycle model

Following each phase is a formal review process that results in the decision to proceed to
the next phase. Testing is performed late in the development process, and phases do not
overlap. When one phase is completed, the entire development effort shifts to the next
phase. This cascading flow from one phase to another is the basis of the Waterfall model’s
name.
 Waterfall Life Cycle Model 57

Advantages of the Waterfall model

As a formalized approach to software development, the Waterfall model is simple and
easy to use. This model can be easy to implement and manage because each phase has a
specific purpose, and development occurs in only one phase at a time.

The Waterfall model is appropriate for small development projects in which the
requirements are well understood.

Disadvantages of the Waterfall model

Although the Waterfall model provides a good introduction to software life cycle models,
its usefulness is limited. Due to the rigidity of the model, all requirements must be stated
explicitly before development begins. If requirements change or are added, the project
must start over from the beginning. No working software is developed until very late in
the process, and this delay creates a great deal of uncertainty and risk. If errors are made
in requirements-gathering or design, they may not be discovered until very late in the
implementation or testing phases.

Due to these issues, the Waterfall model is inappropriate for complex projects. It should
not be used for developing object-oriented software, for long-term or ongoing projects, or
for projects in which requirements are unknown or subject to change.
58 Chapter 4—Software Development Life Cycle

V-SHAPED LIFE CYCLE MODEL

Like the Waterfall model, the V-Shaped life cycle model provides a sequential path of
discrete phases that must each be completed before development proceeds to the next
phase. The phase test plans are developed during each level of development, and once
coding is completed, the tests are conducted. Figure 4-3 is a simplified illustration of the
V-Shaped life cycle model.

System Test
Requirements System Testing
Planning

High Level Integration Test Integration

Design Planning Testing

Low Level Unit Test

Unit Testing
Design Planning

Implementation

Figure 4-3: V-Shaped life cycle model

The development effort begins with requirements gathering (in the upper-left point of
the V). During this phase, requirements are gathered and recorded as they are in the
Waterfall model. However, before development moves to the next phase, a system test
plan is created. The system test plan will focus on verifying the functionality specified in
the requirements definition.
 V-Shaped Life Cycle Model 59

As the V-model moves down the left side, developers focus on high-level system
architecture and overall system design. The integration test plan developed in this phase
will test the abilities of pieces of the finished software system to operate together. The
low-level design phases focus on the design of individual software components, and the
corresponding unit test plans developed in this phase are used to test individual
components.

Coding is performed at the bottom of the V, during the implementation phase. Once
coding is complete, development progresses up the right side of the V, moving through
the test plans developed during the earlier phases. If a problem arises during a testing
phase, the life-cycle reverts back to its corresponding development phase.

Advantages of the V-Shaped model

Like the Waterfall model, the V-Shaped model is relatively simple and easy to use.
Specific goals are defined for each phase. The focus on preparing test plans early in the
process gives the V-Shaped model a higher chance for success. Like the Waterfall model,
the V-Shaped model is appropriate for small development projects in which requirements
are well understood.

Disadvantages of the V-Shaped model

The rigidity of the V-Shaped model makes it inappropriate for most projects. Like the
Waterfall model, all requirements must be stated at the beginning of the project, making
it difficult to add or change requirements later in the development process. All software
development occurs in a single phase, so there are no early working versions or
prototypes. The emphasis in test planning appears to reduce risk, but, like the Waterfall
model, the V-shaped model risks time and energy in the absence of careful planning.
Should the last phase of training, which corresponds to the first phase of development,
reveal that a slight modification is necessary, the entire development process must be
repeated. Like the Waterfall model, the V-Shaped model is inappropriate for complex
projects.
60 Chapter 4—Software Development Life Cycle

INCREMENTAL LIFE CYCLE MODEL

The Incremental life cycle model builds an iterative approach into the Waterfall model.
Development projects are divided into several smaller, more manageable iterations. Each
iteration passes through a mini-Waterfall process. Requirement, design, implementation
and testing phases are completed for each iteration. Figure 4-4 illustrates the Incremental
life cycle model.

Requirements

Design

Implementation
and Unit Testing

Integration and
System Testing

Operation

Figure 4-4: Incremental life cycle model

Development begins with requirements gathering and high-level design, and then
requirements are divided into iterations. The Incremental model is evolutionary meaning
that a working version of the software is created by the end of the first iteration, and
subsequent iterations build upon the work of earlier iterations. Low-level design is
performed during each iteration, and unit testing evaluates the functionality added
during the current iteration. System testing evaluates the way in which the new
functionality affects the functionality of the entire system.
 Spiral Life Cycle Model 61

Advantages of the Incremental model

Unlike the Waterfall and V-Shaped models, the Incremental model generates a working
prototype early in the development process. The iterative nature of the Incremental
model makes it more flexible when adding or changing requirements. This model is also
easier to test and debug because testing is performed incrementally during each iteration
on a relatively small amount of new code.

The Incremental model is an effective tool for managing risk. Chancy portions of
development can be identified and carefully managed in their own iteration. In addition
to being performed incrementally, each iteration represents a measurable milestone.

Disadvantages of the Incremental model

Like the Waterfall model, the Incremental model exhibits some rigidity in that phases
cannot be overlapped. Because requirements-gathering and design are performed during
each iteration and not before development begins, projects developed using the
Incremental model may incur errors in early iterations. The Incremental model is less
risky than the Waterfall or V-Shaped models, but it may be inappropriate for large, long-
term projects.

SPIRAL LIFE CYCLE MODEL

The Spiral life cycle model is similar to the Incremental model but incorporates risk
analysis. It is divided into four phases: planning, risk analysis, engineering, and
evaluation. A project passes through each of these phases in sequence, repeatedly, in a
series of iterations called spirals. At the beginning of the development process, critical
requirements are identified for the first spiral. Subsequent spirals add functionality to this
baseline spiral.
62 Chapter 4—Software Development Life Cycle

The Spiral model is represented by a spiral passing through four quadrants, which
represent the four phases of development. Requirements gathering is performed in the
planning phase. During the risk analysis phase, a formal process is undertaken to identify
alternative courses of action and their relative risks. A prototype is also developed during
this phase. Software is coded and tested during the engineering phase. During the
evaluation phase, the customer has an opportunity to evaluate the output before the
project proceeds to the next spiral. Notice that the angular component represents the
progress in the current spiral, and the radius represents the project cost. Figure 4-5
illustrates the Spiral life cycle model.

Planning Risk Analysis

Risk
Requirements Analysis
Gathering
Prototyping

Cost
Project

Coding

Customer
Testing
Evaluation

Evaluation Engineering

Figure 4-5: Spiral life cycle model

 Summary 63

Advantages of the Spiral model

The focus on risk avoidance makes the Spiral model ideal for large-scale and mission-
critical products. At its core, the Spiral model is built on earlier software development
models, and it borrows from both the Waterfall and Incremental models. Working
software code is developed early; thus, the customer is given many opportunities to
evaluate the software and plenty of time to ease into adoption of the software.

Disadvantages of the Spiral model

The Spiral model can cost considerably more to implement than other life cycle models.
The risk analysis phase requires highly specific expertise, and the project's success
depends on the output of this phase. The Spiral model is inappropriate for use in small
and medium-scale projects that are not mission-critical.

SUMMARY
All software development life cycle models share common phases of development:
gathering of requirements, designing of the software system, coding of software, and the
testing of the system. The Waterfall life cycle model is one of the simplest and easiest to
use; it consists of five discrete phases that are executed sequentially. The V-Shaped life
cycle model adds an emphasis on testing to the Waterfall model. The Incremental life
cycle model applies a series of iterations to the Waterfall model. The Spiral life cycle
model builds upon the Waterfall and Incremental models and focuses on risk analysis.
64 Chapter 4—Software Development Life Cycle

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. Why are the Waterfall cycle model and V-shaped cycle model inappropriate for
large design projects?

.....................................................................................................................................

.....................................................................................................................................
2. How does the Spiral model overcome the limitation of the Waterfall cycle model
and the V-shaped cycle model?

.....................................................................................................................................

.....................................................................................................................................
3. Why is the Spiral model only appropriate for large-scale and mission critical
applications?

.....................................................................................................................................

.....................................................................................................................................
 5

The Unified Modeling Language

MMAAJJOORR T O P IICCSS

Objectives ...................................................................... 66

Pre-Test Questions......................................................... 66

Introduction .................................................................. 67

UML Notation .............................................................. 67

Aggregation ................................................................... 68

Generalization ............................................................... 69

Delegation ..................................................................... 70

Models........................................................................... 70

Views ............................................................................. 73

Summary ....................................................................... 74

Post-Test Questions ....................................................... 74

66 Chapter 5—The Unified Modeling Language

OBJECTIVES
At the completion of this chapter, you will be able to:

● Describe the history of the Unified Modeling Language (UML).

● Describe the purpose of a modeling language.
● Describe the purpose of models.
● Identify UML views.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What is Unified Modeling Language?

.....................................................................................................................................

.....................................................................................................................................
2. What is a UML view?

.....................................................................................................................................

.....................................................................................................................................
 Introduction 67

INTRODUCTION
The Unified Modeling Language, UML, is a method used to specify all aspects of a
software system. UML prescribes syntax for describing the structures of classes,
components, programs, and software systems. UML also describes the interactions
between these items. While the Unified Process relies heavily on UML, UML was
developed separately from it. UML was designed to be used with any iterative software
development process.

The object-oriented movement began with the introduction of Smalltalk in the early
1980s. By the late 1980s, work had begun on developing methods and notations to
describe object-oriented software systems. By the early 1990s, a wide variety of object-
oriented development methods existed, each with its own notation and modeling
language. While working at Rational Software Corp., developers Booch, Jacobson and
Rumbaugh created UML in an attempt to unify the notations each had created earlier. In
November 1997, the Object Management Group (OMG) adopted UML as a standard.

UML NOTATION
UML is used to model a system as a set of static structures and dynamic behaviors. Static
structures are the classes and components that comprise a system. Booch notation was
introduced earlier in the course and is used to specify class types and class relationships.
UML has its own notation, UML class diagrams that specify the static structures of a
software system.

The dynamic behavior of a system describes the steps in completing a task. The dynamic
behavior can be viewed from two levels: the life cycle of a single object from instantiation
to release, and the interaction of objects within a system. UML statechart diagrams are
state diagrams of a single object. Sequence diagrams and collaboration diagrams describe
the interactions between objects.
68 Chapter 5—The Unified Modeling Language

AGGREGATION
Aggregation is used in UML to describe part-of relationships. This includes relationships
where the different components are related so that they are aggregated into a separate
whole. As an example, a personal computer contains a processor, RAM and a hard disk. A
diagram that provides an explanation of aggregation within the PC is below:

Figure 5-1: Aggregation Representation

As shown, the RAM, hard disk and processor are all parts of a personal computer. These
parts aggregate to create a personal computer. The multiplicity indicators show that there
must be at least one component and there can be an unspecified number of components
per personal computer.

Having a variety of aggregates that make up one object can also be called composition.
Composition describes relationships between aggregates, and it also describes what
happens when the removal or addition of a certain component takes place. Will this lead
to the deletion or addition of other components? This is called cascading. Cascading
occurs when adding or removing elements of a composition affects other elements. For
instance, if there is a composition that includes employees, payroll and individual expense
accounts, then the removal of an employee will also lead to the removal of that employee’s
payroll entry and the employee’s expense account.
 Generalization 69

GENERALIZATION
Another kind of relationship that is modeled within UML is the generalized relationship.
These include a general class of something and a specific class that resides within the
general class. In the object-oriented paradigm, this is known as inheritance. These are
commonly referred to as supertypes and subtypes. The supertype will include a
generalized description, an abstract, of a category of objects. The subtype must conform
to all rules and actions that can be performed on the supertype. However, the subtype can
have rules and perform actions that the supertype cannot. One example that can be used
is an animal. In the following listing, animals are broken down into mammals, which is
further broken into whales. The subtype of whales then becomes a supertype for the
subtype of blue whales.

1. Blue whales are a type of whale.

2. Whales are a type of mammal.
3. Mammals are a type of animal.
When using generalization, it is important to make sure that all subtypes contain all
attributes of the supertype. A good test for the concept of generalization is the ability of
any subtype to be inserted where a supertype is used. If the program would run without
any other changes, then the generalization worked. This process in object-oriented terms
would be polymorphism. Generalization and polymorphism work because, as stated, all
subtypes inherit the attributes of the supertype. However, inserting a supertype into code
where a subtype is used will lead to problems because there should be attributes of the
subtype that are not available for the supertype. If the subtype does not include any
attributes not found in the supertype, then the subtype is unnecessary. In other words,
there is no need for the subtype if it is the same as the supertype.

Using the example from above, the method “breathe” is written for the animal supertype.
If the breathe method is called on the subtype whale, the whale should be able to perform
the action. However, the method “swim” that is written for the whale subtype cannot be
called on the supertype of animal because not all animals can swim.
70 Chapter 5—The Unified Modeling Language

DELEGATION
Another way to describe relationships is by delegation. Delegation is the ability of an
object to respond to a message that it receives and to issue a message to an object.
Consider a business model. When an employee finishes a project she will turn this project
in to a manager. That is, the employee object will send a message to the manager object.
The manager will then be able to take the message of the finished project and respond by
issuing another project to the employee. The employee can then take this new message
and begin work on the new project.

The delegation ability of the manager is important because it allows the manager to
respond to the employee. An extension of this example would be if the manager turned
the finished project over to a quality assurance department. The quality assurance
department would be able to respond to the project by beginning the process of editing
and testing the project. This would start a new process of delegation between the
manager and the quality assurance department.

MODELS
A model is a simplified representation of a complex idea or element. In the same way that
a blueprint is a model of a building, UML is a model of a software system or program.
The blueprint allows an architect to convey his or her vision to customers and
contractors, and UML serves the same purpose within the software domain. It allows a
developer to convey his vision to a programming team and management.

UML is a modeling language, and many different UML models can be used to describe
the elements of a software system. These elements include system requirements, user
interactions, system processing, system design, and system testing. UML is complete
enough to model most situations encountered in software development, but it is
extensible enough to handle unforeseen modeling issues.

The following examples of modeling levels will describe a trip to a grocery store,
beginning with the realization that a house is out of food and ending with the actual
purchasing of groceries.
 Models 71

Modeling levels
Various modeling levels are appropriate during the development of a software system.
The level of detail included in each model is modified as development progresses from its
initial stages through analysis, design, implementation, and testing.

High-level models
High-level models are created during the early stages of development. These models
provide a framework for ideas and often diverge in many directions. High-level models
are incomplete and will be heavily revised. Their purpose is to simply explore possible
solutions.

If the problem is a lack of food, possible solutions include growing a garden, driving to a
grocery store, or even stealing food from a neighbor. Some of these solutions are
obviously more feasible than others. The point of high-level modeling is to brainstorm in
as many directions as possible and to include all possibilities.

Abstract models
Abstract models are developed toward the end of analysis and the beginning of the design
phase. These models describe the system architecture and provide an overview of the
eventual system design. The solution revealed by the high-level model is elaborated into a
more refined model. However, the design is still incomplete, since much of the
implementation detail is omitted from abstract models. The goal is to verify the overall
system design before designing individual components.

In this phase of modeling, a concise solution has been chosen, and the design of the
solution can begin. Certain checks are used to ensure that the solution will work. Assume
that, from the possible solutions to the food problem, making a trip to the grocery store
was selected. The specifications that would have to be met include:

1. Making sure there is transportation

2. Knowing what to buy
3. Having money to buy the food
72 Chapter 5—The Unified Modeling Language

Full specification models

During design, full specification models are created to completely describe a software
system. Full specification models also describe the process of implementing a system,
including the following details:

1. All interfaces to a system

2. All classes and components
3. All interactions between classes and components
4. All business logic
When this stage of modeling is reached, all aspects of the design are required. Continuing
the grocery store example, this modeling level would specify:

1. What time they would go

2. Who would be driving to the store
3. Which grocery store would be used
4. What food would be purchased
5. How to pay for the food
Additional models can be developed to serve as partial descriptions or to provide
examples of the system in use. A partial model defines a subsystem or some portion of a
software system's functionality. The partial model is used to develop reusable
components that can be combined with other partial models to create complete systems.
An exemplar model describes a specific case of the software system in use. While exemplar
models cannot be used to fully describe the general-use software system, examples can
increase understanding of a complex system.
 Views 73

VIEWS
UML includes a variety of diagrams that are used in the analysis and design of a system.
UML is divided into eight views. Each view is a set of diagrams that depict some aspect of
a system. These eight views are grouped into three major areas: structural, dynamic, and
model management.

The structural view describes the static structure of a software system, including the
classes, the components, and their relationships. The dynamic view describes the
implementation of business logic in the design of individual classes and the interaction of
classes and components. The model management view describes the relationships
between UML models. In the preceding section, you learned that partial models are used
to describe subsystems. The model management view describes the relationships between
subsystems. The specifics of each of the UML views and diagrams will be discussed
throughout this course. Table 5-1 lists the eight UML views and the diagrams used to
develop each view.

Table 5-1: UML Views

Major Area View Diagrams
Structural Static view Class diagram
Use-case view Use-case diagram
Implementation view Component diagram
Deployment diagram
Deployment view Component diagram
Deployment diagram
Dynamic State machine view State chart diagram
Activity view Activity diagram
Interaction view Sequence diagram
Collaboration diagram
Model management Model management view Class diagram
74 Chapter 5—The Unified Modeling Language

SUMMARY
Booch, Jacobson, and Rumbaugh developed the Unified Modeling Language (UML) to
provide a complete language for specifying object-oriented software systems. UML was
adopted as an official standard by the OMG in 1997. UML models both the static
structures and the dynamic behaviors of a software system. Various modeling levels are
used depending on the level of detail required by each stage in the development process.
UML is divided into eight views, which are grouped into three major areas: structural,
dynamic, and model management.

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What are the three UML modeling levels?

.....................................................................................................................................

.....................................................................................................................................
2. What are the eight UML views?

.....................................................................................................................................

.....................................................................................................................................
 6

Computer-Aided Software Engineering

MMAAJJOORR T O P IICCSS

Objectives ...................................................................... 76

Pre-Test Questions......................................................... 76

Introduction .................................................................. 77

Selecting a CASE Tool ................................................... 78

Summary ....................................................................... 81

Post-Test Questions ....................................................... 81

76 Chapter 6—Computer-Aided Software Engineering

OBJECTIVES
At the completion of this chapter, you will be able to:

● Identify the role of CASE tools in the software development process.

● Identify the criteria for selecting a CASE tool.
● Identify the benefits and limitations of CASE tools.
● Install and use Argo/UML.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What is Computer-Aided Software Engineering?

.....................................................................................................................................

.....................................................................................................................................
2. What are the criteria should one consider in a CASE tool?

.....................................................................................................................................

.....................................................................................................................................
 Introduction 77

INTRODUCTION
Computer-Aided Software Engineering (CASE) is the integration of software-based
modeling tools into the software development process. Analysis and design
methodologies and modeling notations were developed to formalize the software-
engineering process; CASE tools automate that process by assisting in each step. Some
types of CASE tools are analysis and design tools, automated code generation tools, and
software testing tools. Analysis and design tools aid in the creation of diagrams and
project documentation. Automated code generation assists in the implementation phases.
Testing tools lead to a more thorough evaluation of an application. Table 6-1 provides a
chronological list of CASE tool development.

Table 6-1: CASE TOols Timeline

Time Period CASE Tools
Early 1980’s Documentation
Analysis and design diagramming
Mid-1980’s Analysis and design validation
Late 1980’s Automated code generation
Early 1990’s User interface reusability

Early CASE tools were used to create project documentation and to assist in the creation
of analysis and design diagrams. Later, CASE tools incorporated a type of intelligence
that assisted in validating designs and ensuring conformity of diagrams. By the late
1980’s, CASE tools were being used to automatically generate code, based on design
diagrams. In the early 1990’s, CASE tools had evolved into user-friendly interfaces that
could be used on multiple projects, but still contained the aspects that had made previous
CASE tools useful.
78 Chapter 6—Computer-Aided Software Engineering

S E L E C T I N G A C A S E TO O L
A wide variety of CASE tools exist to support different development environments.
Choosing the best tool for a project can be a challenging exercise. The criteria used to
select CASE tools include methodology, flexibility, collaboration, and diagram validation.

Methodology
Although a wide variety of software development methodologies exist, common themes
exist between all object-oriented methodologies. Most variations occur in their processes,
procedures, and notations. It is vital that the CASE tools selected support the
methodology followed by the project.

When using UML and the Unified Process as a methodology for software development, a
traditional process should be followed. This process consists of moving from high-level
models, through abstract models, and finally to the full specification model. High-level
models are general descriptions of the project, while abstract models include definitions
of the resources required and ensure the soundness system design. Finally, the full
specification model will completely describe the software and provide explicit directives
for the software design. Any CASE tool that is under consideration, must support this
methodology

Flexibility
It is impossible to foresee every project need before development has begun. For this
reason, choose tools that allow customization. The tool should allow custom
documentation and should provide support for multiple programming languages. The
best tools allow construction of custom schemas that can be used to generate code in
several programming languages. Even with a detailed methodology, unforeseen problems
and needs may arise throughout software development. Thus, the CASE tool cannot
force users to use a fixed design.
 Selecting a CASE Tool 79

Common CASE tool flexibilities include the ability to modify the target operating
system, language used, modeling language, size of the software, and the entire process.
Developers should not have to change the entire design of the software simply because
specific parts of the CASE tool must be modified. Experienced development teams are
flexible enough to deal with unforeseen problems and changes. The tools used by these
developers should be just as flexible.

Collaboration
One of the principal purposes of any software development methodology is to facilitate
collaboration. It is vital that CASE tools allow collaboration among developers; multiple
developers should be able to work on the project simultaneously. The tool should also
support distribution across multiple computers and multiple work areas.

Configuration management and version control software is critical to the development

process. It allows multiple developers to work on the same code simultaneously. With it,
engineers can manage multiple versions of a software segment, which targets multiple
platforms or customers. Engineers can also control the status of code between versions
and from one iteration to the next.

There are two parts to collaboration, both of which can heavily influence the selection of
the CASE tool. The first is the prerequisites of the design. The second is the knowledge
of the organization producing the code.

Sometimes the programmers on a team may have different visions of what the project
should accomplish. Having common project prerequisites will allow cleaner collaboration
within the team.

The actual organization that will be producing the code is also an important
consideration when choosing a CASE tool. The development team can range in maturity,
experience, and knowledge. These factors can heavily influence the CASE tool needed. A
highly evolved CASE tool might be too intimidating for some inexperienced teams, while
a simpler CASE tool could limit the efforts of a very experienced software organization.
80 Chapter 6—Computer-Aided Software Engineering

Diagram validation
Although diagrams are used to simplify the design of a complex system, diagrams
themselves can become fairly complex. Tools are available to validate analysis and design
diagrams. These tools help diagrams conform to the modeling syntax, and ensure
consistency across sets of diagrams.

Exercise 6-1: Using Argo/UML

Argo/UML, a UML CASE tool, supports use-case, class, state, activity and collaboration
diagrams. Argo/UML is written in Java and can be used to generate Java source code, and
it will be used to complete many of the exercises in this course. In this exercise, you will
install and explore Argo/UML.

1. Download and install a Java2-compliant virtual machine software, such as the Sun
Java2 Runtime Environment. You can download the Java2 Runtime Environment
from the following URL:
http://www.java.sun.com/products/jdk/1.2/jre/index.html
2. Download Argo/UML from the Tigris Web site at http://argouml.tigris.org/. You
will need two files: argouml070.jar and xml4j.jar. Place both files in the same
directory.
3. If you are using Microsoft Windows, double-click the argouml070.jar file to
launch Argo/UML. If you are using another system or you experience difficulty
with this method, create a batch file or shell script to execute Argo/UML. The file
should contain one line that uses the Java virtual machine to run the uci.uml.Main
class. Be sure to include the argouml070.jar and xml4j.jar files in the class path.
Use the following example as a guide:
java -classpath %CLASSPATH%;argouml070.jar;xml4j.jar uci.uml.Main
You may need to include the full paths to the Java interpreter and .jar files.
 Summary 81

4. Execute the batch file or shell script you created in Step 3 to start using
Argo/UML.
5. Open the projects included on the supplemental disk, and browse the diagrams
included in the projects.

SUMMARY
Computer-Aided Software Engineering (CASE) is the integration of software-based tools
into the software development process. These tools began appearing in the early 1980’s.
Today, CASE tools are used by software developers to create project documentation,
analysis and design diagrams, to perform analysis and design validation, and to create
program code from design diagrams. The criteria for selecting a CASE tool include the
methodology it supports, the flexibility it affords developers, the degree to which it
facilitates collaboration between developers, and its ability to validate analysis and design.

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What were early 1980’s CASE tools used for?

.....................................................................................................................................

.....................................................................................................................................
2. What were mid 1980’s CASE tools used for?

.....................................................................................................................................

.....................................................................................................................................
3. What were late 1980’s CASE tools used for?

.....................................................................................................................................

.....................................................................................................................................
82 Chapter 6—Computer-Aided Software Engineering
 7

Use-Case Modeling

MMAAJJOORR T O P IICCSS

Objectives ...................................................................... 84

Pre-Test Questions......................................................... 84

Introduction .................................................................. 85

Developing a Use-Case Model ....................................... 90

Summary ..................................................................... 100

Post-Test Questions ..................................................... 101

84 Chapter 7—Use-Case Modeling

OBJECTIVES
At the completion of this chapter, you will be able to:

● Identify the actors and use cases of a system.

● Describe the four types of use-case relationship.
● Develop a use-case model to capture project requirements.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What is the primary purpose of a use-case model?

.....................................................................................................................................

.....................................................................................................................................
2. What is a use-case?

.....................................................................................................................................

.....................................................................................................................................
 Introduction 85

INTRODUCTION
The principal medium for capturing requirements in the Unified Process is the use-case
diagram. Use-case diagrams illustrate the relationship between a software system and its
users. They also describe how each type of user will interface with the system. For
example, consider a library system. The librarian will check books in and out, and the
library patron will search the database. These relationships are illustrated with use-case
diagrams. The set of all use-case diagrams and their associated use-case descriptions
constitute the use-case model. The use-case model is one of the four principal deliverables
of the requirements workflow.

Actors
Users of a software system are represented as actors in a use-case diagram. Actors represent
specific users, groups of users, organizational users and even external software systems.
For example, a library may employ several librarians. Because all of these librarians will
access the system in the same manner, a single actor (Librarian) represents them. An actor
is represented by a labeled stick figure. Figure 7-1 is an example of a Librarian actor.

Librarian

Figure 7-1: Actor example

Multiple users may assume the role of a single actor. For example, all of the librarians will
play the role of the Librarian actor. In addition, a single user may assume the role of
multiple actors. For example, an actor may represent a Head Librarian who has the ability
to purchase new books and run audits on the system. A user acts as a Head Librarian only
while executing the special tasks of this position; in other instances, the same user will
assume the role of the Librarian actor.
86 Chapter 7—Use-Case Modeling

Organizational users of the library system include book publishers and other libraries.
The Web site interface to the library system is an external software system that can be
represented as an actor.

Use cases
Actors maintain relationships with use cases. A use case is a description of some software
activity that an actor may initiate. For example, a librarian can check out an asset, such as
a book. This activity is represented as a use case. Use cases are represented by an oval with
a label inside or beneath that identifies the use case. Figure 7-2 is an example of a Check
Out Asset use case.

check out
asset

Figure 7-2: Use case example

Use-case relationships
Use cases can participate in four types of relationships: association, generalization,
include and extend. Each relationship has its own purpose and notation. Table 7-1 lists
the four types of use-case relationships, their purposes and their notations.

Table 7-1: Use-case Relationships

Relationship Purpose Notation
Association Denotes a relationship between
an actor and a use case
Generalization Denotes inheritance between use
cases
 Introduction 87

Table 7-1: Use-case Relationships

Relationship Purpose Notation
Include Includes the functionality of one <<include>>
use case in another
Extend Extends the functionality of one <<extend>>
use case to another under certain
conditions

Association
The association relationship is the interface between an actor and a use case. It is
represented by a line between an actor and a use case. For example, a librarian will use the
library system to check assets out. Figure 7-3 illustrates this interface using an association
relationship. The box around the Check Out Asset use case represents the system
boundary.

Library System

check out
asset

Librarian

Figure 7-3: Association relationship

Generalization
The generalization relationship is a link between use cases. Use cases often share common
characteristics. Suppose you identified a second use case: Check In Asset. This second use
case shares certain features with the Check Out Asset use case. Both use cases perform a
transaction that affects the library's inventory. A generalization allows you to represent
this shared functionality in a third use case (the Perform Transaction use case) and inherit
its functionality in both the Check In Asset and the Check Out Asset use cases.
88 Chapter 7—Use-Case Modeling

The generalization relationship is represented by a solid line ending with an open

arrowhead. The arrow points from the child use case to the parent use case. Figure 7-4
illustrates the generalization between the Perform Transaction use case and the Check
Out Asset use case.

Library System

perform
transaction

check out
asset

Librarian

Figure 7-4: Generalization

Include
The include relationship allows one use case to include the functionality of another.
Before an asset can be checked out, the system must verify that the patron does not owe
any overdue fines. An include relationship allows the Perform Transaction use case to
include the functionality of a Check Account Balance use case.
 Introduction 89

The include relationship is represented by a dashed line with an arrowhead. The word
<<include>> is superimposed above the line to distinguish an include relationship from an
extend relationship. The arrow points from the use case that includes the additional
functionality to the use case being included. Figure 7-5 illustrates the include relationship
between the Check Account Balance use case and the Perform Transaction use case.

Library System

<<include>> check
perform
account
transaction
balance

check out
asset

Librarian

Figure 7-5: Include relationship

Extend
The extend relationship combines the functionality of one use case with the functionality
of another, if certain conditions exist. For example, if a library patron owes an overdue
fine, the system requires that the fine be paid before another asset can be checked out.
The Pay Overdue Fine use case extends the functionality of the Perform Transaction use
case only if an overdue fine is owed.
90 Chapter 7—Use-Case Modeling

The extend relationship is represented by a dashed line with an arrowhead. The word
<<extend>> is superimposed above the line. The arrow points from the use case that
provides the additional functionality to the use case that accepts the functionality. Figure
7-6 illustrates the extend relationship between the Pay Overdue Fine use case and the
Perform Transaction use case.

Library System

<<extend>> <<include>> check

pay overdue perform
account
fine transaction
balance

check out
asset

Librarian

Figure 7-6: Extend relationship

DEVELOPING A USE-CASE MODEL

The use-case model is one of the four principal deliverables of the requirements
workflow. The use-case model usually takes the form of a document that consists of the
following:

● Top-level use-case diagrams.

● Top-level use-case descriptions.
● Sub-level use-case diagrams.
Figure 7-7 is a use-case model document for the library system example. Note that the
use-case model document contains several pages.

The first step in developing a use-case model is identifying top-level use cases. Top-level
use cases are those use cases that interface directly with one or more actors. Candidate
requirements that are being formalized as use cases usually translate directly into top-level
use cases. Pages 2 and 3 of Figures 7-7 are top-level use-case diagrams.
 Developing a Use-Case Model 91

At a minimum, use-case descriptions for the top-level use cases should be included. They
are often included for sub-level use cases as well. Use-case descriptions provide a brief
narrative of the steps in executing a use case. Any special considerations that are not
adequately described in the use-case diagrams should also be included. Pages 4 and 5 of
Figures 7-10 and 7-11 are the top-level use-case descriptions for the library system.

Sub-level use-case diagrams include all use cases and any relationships between use cases.
Pages 6 and 9 of Figures 7-12 and 7-15 are the sub-level use-case diagrams.

Figure 7-7: Use-case model-page 1

92 Chapter 7—Use-Case Modeling

Figure 7-8: Use-case model-page 2

 Developing a Use-Case Model 93

Figure 7-9: Use-case model-page 3

94 Chapter 7—Use-Case Modeling

Figure 7-10: Use-case model-page 4

 Developing a Use-Case Model 95

Figure 7-11: Use-case model-page 5

96 Chapter 7—Use-Case Modeling

Figure 7-12: Use-case model-page 6

 Developing a Use-Case Model 97

Figure 7-13: Use-case model-page 7

98 Chapter 7—Use-Case Modeling

Figure 7-14: Use-case model-page 8

 Developing a Use-Case Model 99

Figure 7-15: Use-case model-page 9

100 Chapter 7—Use-Case Modeling

Exercise 7-1: Developing a use-case model

1. Create a list of actors and top-level use cases for the grocery store inventory system.
Use the candidate requirements document you developed in the previous chapter
exercise as a guide.
2. Using Argo/UML, create a top-level use-case diagram for the use cases you
identified in Step 1 of this exercise. Refer to Appendix A for assistance using
Argo/UML.
3. With a word processor, create a use-case description for each of the top-level use
cases you identified in Step 1.
4. Using Argo/UML, create sub-level use-case diagrams for each of the use cases you
identified in Step 1.

SUMMARY
Use-case diagrams illustrate the relationships between a software system and its users.
Actors are used to represent specific users, groups of users, organizational users and
external software systems. Actors maintain relationships with use cases. Use cases exist
within the system and represent specific ways the system can be used. Use cases can
participate in four types of relationships: association, generalization, include and extend.
An association is a relationship between an actor and a use case. A generalization is a
relationship between use cases that denotes inheritance. An include relationship allows
one use case to include the functionality of another use case. An extend relationship
extends the functionality of one use case to another if certain conditions are met.
 Post-Test Questions 101

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What can Actors represent in use-case modeling?

.....................................................................................................................................

.....................................................................................................................................
2. What are the four types of use-case relationship?.

.....................................................................................................................................

.....................................................................................................................................
3. What three things are typically included in a use-case model?

.....................................................................................................................................

.....................................................................................................................................
102 Chapter 7—Use-Case Modeling
 8

Activity Diagrams

MMAAJJOORR T O P IICCSS

Objectives .................................................................... 104

Pre-Test Questions....................................................... 104

Introduction ................................................................ 104

Conditionals ................................................................ 106

Branches and Merges ................................................... 106

Concurrency ................................................................ 108

Forks and Joins ............................................................ 108

Library System Activity Diagrams................................ 110

Iterations ..................................................................... 119

When This Is Useful .................................................... 120

Summary ..................................................................... 120

Post-Test Questions ..................................................... 121

104 Chapter 8—Activity Diagrams

OBJECTIVES
At the completion of this chapter, you will be able to:

● Describe the benefits of activity diagrams.

● Interpret activity diagrams.
● Create activity diagrams to describe use-cases.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What is the primary purpose of Activity Diagrams?

.....................................................................................................................................

.....................................................................................................................................

INTRODUCTION
A use-case diagram describes the relationships between actions and discrete units of a
system's functionality. A use-case description provides a brief overview of the purpose of
each use-case and the steps required to complete that purpose. An activity diagram can be
used to expand on a use-case description. Activity diagrams are similar to flow charts:
they describe the order of activity and the branch logic of a process. However, they differ
from traditional flow charts by allowing the representation of concurrent operations.
Activities that take place simultaneously (such as threads) can be represented using
activity diagrams. Activity diagrams can be used to supplement the use-case descriptions
within a use-case model.
 Introduction 105

Creating activity diagrams

Activity diagrams flow from top to bottom. The initial state is represented by a closed
circle. Activity proceeds through a series of activity states until it reaches its final state,
which is represented by a closed circle inside an open circle. Figure 8-1 is a simple activity
diagram for the Check Out Asset use-case.

scan library card

scan asset

Figure 8-1: Check Out Asset activity diagram

Boxes with rounded corners represent activity states. Each activity state is labeled with a
brief description of the activity it represents. The arrows between states, called transitions,
represent the shift from one activity state to the next.
106 Chapter 8—Activity Diagrams

CONDITIONALS
A conditional action in an activity diagram is an action that depends on one or more
defined requirements. For instance, in the above Check Out Asset use-case, before an
asset can be checked out, the system checks the patron's account balance. If the patron's
account information indicates an unpaid overdue fine, the system enters an alternative
thread of execution in which the library fine is paid. If no overdue fine is due, execution
continues along the primary path. Conditionals are represented in activity diagrams with
branches and merges.

BRANCHES AND MERGES

Branches represent places where conditionals are used for decisions in the activity flow.
When a transition enters a branch, a question is asked and a decision is made to continue
the flow in one of two or more possible paths of execution. The paths exiting a branch are
called alternative threads because execution continues along only one path. Figure 8-2
below, using the Check Out Asset use-case described above, adds a branch with two
alternative threads. A diamond represents the branch. The transitions exiting the branch
are labeled to indicate which alternative each represents. The alternative threads converge
at a merge, also represented by a diamond. By convention, the primary thread of
execution follows a straight path down the page.
 Branches and Merges 107

Figure 8-2: Check Out Asset branch and merge

108 Chapter 8—Activity Diagrams

CONCURRENCY
While branches are useful for describing when there are two or more options to take,
there are also situations where the action will flow along two or more paths at the same
time. This is known as concurrency. For instance, considering the Check Out Asset use-
case, when an asset is being checked out, there are two actions that must be performed at
the same time: adding that asset to the patron's account information and marking that
asset as checked out. These situations are described in Activity Diagrams through forks
and joins.

FORKS AND JOINS

Forks and joins distinguish activity diagrams from traditional flow charts. When a
transition enters a fork, execution branches off in two or more directions simultaneously.
The threads exiting a fork operate concurrently. Threads converge at a join.

Consider the Check Out Asset use-case described above. This sequence can be
represented using a fork. Figure 8-3 adds a fork, represented by a horizontal bar, with two
concurrent threads. After an asset is scanned, execution continues along each of these
threads simultaneously. The threads converge at a join, also represented by a horizontal
bar.
 Forks and Joins 109

scan library card

check account
balance

[unpaid overdue fine]

[no unpaid fine] pay overdue fine

scan asset

add asset to mark asset as

patron's account checked out

Figure 8-3: Check Out Asset fork and join

110 Chapter 8—Activity Diagrams

LIBRARY SYSTEM ACTIVITY DIAGRAMS

Activity diagrams provide a more complete description of a project's use-cases. Figures
8-4 through 8-12 are activity diagrams for the library system example. As you examine
these diagrams, consider how each is used to illustrate the sequence of activities involved
in a use-case interaction.

Figure 8-4: Add Asset to Database activity diagram

 Library System Activity Diagrams 111

enter asset

[asset checked
out]

[asset not checked out] remove asset from

patron's account

delete from asset

database

Figure 8-5: Delete Asset from Database activity diagram

112 Chapter 8—Activity Diagrams

access account
database

access asset
database

generate report

print report

Figure 8-6: Generate Report activity diagram

 Library System Activity Diagrams 113

scan library card

check account
balance

[unpaid overdue fine]

[do not pay fine]

[no unpaid fine]

[pay fine]

pay overdue fine

scan asset

add asset to mark asset as

patron's account checked out

Figure 8-7: Check Out Asset activity diagram

114 Chapter 8—Activity Diagrams

Figure 8-8: Check In Asset activity diagram

 Library System Activity Diagrams 115

scan unissued
library card

enter patron
information

create account
record

Figure 8-9: Issue Library Card activity diagram

116 Chapter 8—Activity Diagrams

scan library card

access account
database

display account
information

Figure 8-10: Access Account Information activity diagram

 Library System Activity Diagrams 117

Figure 8-11: Generate Overdue Notices activity diagram

118 Chapter 8—Activity Diagrams

Figure 8-12: Pay Overdue Fine activity diagram

 Iterations 119

ITERATIONS
While all of the above activity diagrams describe situations which follow a direct path
with no stops from beginning to end, there are situations which will require certain
actions to be performed more than once before an entire process can be completed. These
situations can be described using iterations. An iteration is a step in a process which will
repeat until a certain requirement is met.

In the following example, consider a student working on a test. Until all the problems on
the test are completed, the student will not be finished working on the test. The loop
above the activity state of Completing Test Questions indicates that this step will be
iterated until all the questions are answered.

Figure 8-13: Iterations

120 Chapter 8—Activity Diagrams

WHEN THIS IS USEFUL

Activity diagrams are a useful evolution in flowchart design, but they are not always the
best way of describing situations. They should be used with care, as with any software
design tool. Using an activity diagram when another method of modeling would be more
precise or informative can be a large hindrance to efficient software production.

A major advantage of using activity diagrams is the ability to describe parallel behavior, or
how behaviors in more than one use-case will interact. But activity diagrams are not
designed to describe which specific objects will perform which actions. Rather, an activity
diagram can be used to show that the actions taken will influence other actions. Other
types of diagrams, such as interaction or state transition diagrams, should be used when
attempting to describe objects and methods of messaging used between the objects.

Exercise 8-1: Creating activity diagrams

1. Examine the use-case diagrams you created in the previous chapter's exercise.
Identify use-cases that could benefit from further explanation using activity
diagrams. Most or all of your top-level use-cases should be included in this group.
2. Using Argo/UML, create an activity diagram for each of the use-cases you
identified in Step 1 of this exercise. Refer to Appendix A for assistance using
Argo/UML.

SUMMARY
Activity diagrams are similar to flow charts. They describe a process: the order of activities
and the branching logic. They can also represent concurrent operations. One common
use for activity diagrams is to supplement the description of use-cases. Activity diagrams
flow from top to bottom through a series of activity states. Branches are used to represent
the logic involved in a process. The paths exiting a branch represent alternative threads of
execution. Branches converge at a merge. Forks are used to indicate the beginning of
concurrent threads of execution. Forks converge at a join.
 Post-Test Questions 121

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. Contrast Branches and Forks?

.....................................................................................................................................

.....................................................................................................................................
2. What are the initial and final states of an Activity diagram represented by?

.....................................................................................................................................

.....................................................................................................................................
122 Chapter 8—Activity Diagrams
 9

Interface Design and Prototyping

MMAAJJOORR T O P IICCSS

Objectives .................................................................... 124

Pre-Test Questions....................................................... 124

Introduction ................................................................ 125

User Interface Design .................................................. 125

User Interface Prototyping........................................... 130

Specifying System Interfaces ........................................ 138

When This Is Useful .................................................... 139

Summary ..................................................................... 140

Post-Test Questions ..................................................... 141

124 Chapter 9—Interface Design and Prototyping

OBJECTIVES
At the completion of this chapter, you will be able to:

● Identify the major goals of user interface design.

● Describe the different types of prototypes.
● Create a paper prototype.
● Design a system interface.
● Use the Backus-Naur Form to create an interface control document.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What is the primary purpose of the user interface?

.....................................................................................................................................

.....................................................................................................................................
2. In designing a user interface, what are some things that should be considered?

.....................................................................................................................................

.....................................................................................................................................
 Introduction 125

INTRODUCTION
Object modeling languages are becoming increasingly expressive and complex. The use of
a language like UML can increase the abilities of user interface designers for modeling
application domains and interactive systems. The recent development of techniques
which assist in user interface design during the object-oriented development process
provide programmers with the tools necessary to develop robust, user friendly
applications. Some of the better techniques include task analysis or preliminary user
interface analysis using interface prototyping, which has proven significant in object
identification.

USER INTERFACE DESIGN

Designing user interfaces can be difficult. Large development projects will often employ
human interface analysts who specialize in designing user interfaces. Smaller projects may
have to rely on programmers to design user interfaces. For most programmers, user
interface design appears to be a trivial exercise. However, the user interface plays an
important role in creating customer satisfaction. A good user interface will be transparent
to customers, freeing them to judge the system on its process and output. A poor user
interface can be an obstacle to an otherwise well-implemented software system.

A good user interface follows user interface conventions. These may vary between
operating systems. For example, Microsoft publishes a manual of user interface design
guidelines, which describes the ways in which users expect a Windows application to
react. Other environments, such as the World Wide Web, have their own informal
conventions. Programmers often assume they understand these conventions, but
experience shows that applications do not conform without a well-established process for
user interface design.

In this chapter, you will learn to design user interfaces that accommodate ergonomic and
accessibility considerations. Later, you will learn to determine an interface design's
potential for success through user testing.
126 Chapter 9—Interface Design and Prototyping

User interface principles

User interface design incorporates more than mere aesthetics. A considerable body of
empirical data regarding human-computer interaction has been collected. This data has
been used to formulate a number of principles at play in modern software user interfaces.
These principles are the use of metaphors, self-evident components, consistency, and state
visualization.

Metaphor
It is often beneficial to design a user interface as a metaphor of a real-world object. The
Windows desktop is a good example. The desktop has folders that lie on top of it, and
folders contain documents. If you choose to use a metaphor in developing a user
interface, be sure to use it consistently across the entire project. Do not create a metaphor
that applies only to a very narrow aspect of the program. Also, realize that while
metaphors provide one way to design user interfaces, not all software systems employ
metaphors. Thus, a good balance must be struck between the arcane and useless
metaphors and a complete lack of designing interfaces that relate to the actual world.

As stated above, the desktop has become a very successful metaphor, and there are other
real-world objects that are being implemented for programs. For instance, there is work
being done on many platforms to have a file system explorer that is a metaphor for a real
storage area. Thus, directories with larger size on the hard disk will appear as larger
structures within the program. There are many other metaphors used in user interfaces,
but it is important to remember that not every situation will warrant a real-world object
metaphor.

Self-evidence
The most critical feature to build into a user interface is self-evidence. The function of
various user interface components should be readily apparent to even slightly experienced
users. However, in most cases, a large number of users will use a system, and each of these
users will approach the system from a different perspective.
 User Interface Design 127

Experienced computer users will look for controls that are common among applications.
Many Windows applications have a standard Windows toolbar that contains buttons to
execute common functionalities, such as opening a new or existing document or saving a
document. Experienced users will recognize these icons from other applications and feel
confident to explore the features specific to your application.

Novice users are often fearful of making mistakes. They may not recognize these icons.
Their hesitance may hinder their ability to use a system, which can leave many powerful
and useful aspects of a program unused. Making the user interface self-evident eases this
fear and facilitates learning. Figure 9-1 shows the standard Windows toolbar. Some of the
icons on the toolbar are intuitive. Most people will understand immediately that clicking
on the image of a printer will cause the current document to be printed.

For instance, in the example below, two pieces of paper on top of each other may indicate
“Paste” to experienced users, but may mean nothing at all to new users of a system.
However, the Paste Icon is not threatening and seems to imply that no harm will come to
a novice user for using that command. Thus, while the exact meaning of the icon may
not be grasped by every user, the knowledge that pressing that icon will not cause serious
harm to a program should be evident to all users.

Library System
File Edit View Insert Format Tools
ABC

Figure 9-1: Standard Windows toolbar

Consistency
User interfaces should be consistent. There are two types of consistency: internal
consistency and external consistency. Internal consistency is consistency within the
interface of a single software system. For example, if the library system allows users to
access a patron's account information by either scanning her library card or manually
entering her library card number, it should allow users to do the same when checking out
a book to a patron. This type of consistency makes learning the system easier and using
the system faster.
128 Chapter 9—Interface Design and Prototyping

External consistency is consistency between a piece of software and the underlying

operating environment. For example, Macintosh applications open multiple independent
document windows, while Microsoft Windows applications usually implement the
multiple-document interface in which a single application window contains multiple
document windows. Another example of external consistency between different recent
versions of Microsoft Windows is the Start Menu. For any Windows user, that user will

know that programs can be accessed through the Start Menu for any version of Windows
that has been produced since Microsoft Windows 95. This external consistency in the
operating system allows for smoother transitions for users when they switch between
different Microsoft products.

A well-designed user interface will follow the conventions of the operating environment
in which it resides, making sure to use the internal and external consistencies which are
already used.

State visualization
In the preceding chapter, you created activity diagrams for each of your top-level use
cases. These activity diagrams illustrate the life cycle of a use-case and the various states in
which it can exist, from initiation to completion. Often, these states correspond to a
request for input from the user. State visualization is the principle that visual cues should
be offered to illustrate the transition from one state to another.

For example, when a librarian checks a book out to a patron, he must first scan the
patron's library card. Following this state, the librarian will either be notified that the
patron owes an overdue fine, or he will begin scanning the book to be checked out. All of
these states should be visually distinct so that the librarian can learn to quickly identify
each. If the screen notifying the librarian of an overdue fine looks too similar to the screen
requesting the assets to be checked out, the process will be slowed down while the
librarian examines the screen to determine the new state.

Figure 9-2 is based on the activity diagram for the Check Out Asset use case. A dialog box
alerts the librarian if the patron owes an overdue fine. The screen used to pay an overdue
fine is visually different from the screen to used enter the assets being checked out. These
visual representations of state allow the librarian to work more efficiently.
 User Interface Design 129

State visualization is important, but be sure to avoid creating a modal interface. A modal
interface can exist in only one state at a time. For example, a modal interface might
restrict a librarian's ability to check out books if he is using the system to perform a time-
consuming task, such as generating overdue notices. Modal interfaces can be easy to use,
but they are inflexible.

Library System

Check Out Check In Accounts Admin

Patron

Account Number:

Name:

Address:

Library Assets

Done Overdue Fine

Patron owes an overdue fine.

OK

Library System

Check Out Check In Accounts Admin

Patron

Account Number: Create New Account

Name: Account Balance:

Address:

Pay Fine

Assets Checked Out: Account History:

Library System

Check Out Check In Accounts Admin

Patron

Account Number:

Name:

Address:

Library Assets

Done

Figure 9-2: State visualization

130 Chapter 9—Interface Design and Prototyping

USER INTERFACE PROTOTYPING

A prototype is a simulation of the actual system. User interface prototypes are used to test
the usability of the interface. Essentially, a prototype is a tool for defining and refining
requirements. A prototype may take the form of a piece of software that implements the
interface and most basic functionality of a system, or it may be as simple as a set of screen
shots called a paper prototype. Following are descriptions of several classes of prototypes.

● Horizontal prototype: implements a broad set of features and a shallow

implementation of each feature.
● Vertical prototype: implements a subset of the features with a more thorough
implementation.
● High-fidelity prototype: a software prototype designed to look and operate in the
same manner as the final software system.
● Low-fidelity prototype: a non-software prototype that uses diagrams, documents,
or presentations to communicate the user interface.
Each of these classes of prototypes can be created using either the rapid or paper
prototype process. The two prototype development processes are described below.

Rapid prototyping
Rapid prototyping is a process by which a working demonstration version of a piece of
software is created in a very short period of time. When designing a user interface, several
rapid software prototypes may be developed and tested with users before a final user
interface is agreed upon.

A software prototype is never developed into a fully operational system. The prototype is
used only for demonstration purposes. It communicates a vision of the final product's
appearance, and it serves as a catalyst for new ideas. Software prototypes are often
developed using Rapid Application Development (RAD) techniques. No emphasis is
placed on performance. Software prototypes are developed using RAD tools such as
Visual Basic or Delphi even if the actual software system will be developed using another
language.
 User Interface Prototyping 131

Paper prototyping
Paper prototyping is used to communicate the same information as a software prototype
without the expense of developing a working piece of software. Paper prototypes use
screen shots and storyboards to illustrate the system's appearance and functionality. Paper
prototypes may be part of a formal interface requirements document. Figures 9-3
through 9-9 are the interface requirements document for the library system, based on a
paper prototype process.

Figure 9-3: Interface Requirements Document—page 1

132 Chapter 9—Interface Design and Prototyping

Figure 9-4: Interface Requirements Document—page 2

 User Interface Prototyping 133

Figure 9-5: Interface Requirements Document—page 3

134 Chapter 9—Interface Design and Prototyping

Figure 9-6: Interface Requirements Document—page 4

 User Interface Prototyping 135

Figure 9-7 Interface Requiement Document-page 5

136 Chapter 9—Interface Design and Prototyping

Figure 9-8: Interface Requirements Document—page 6

 User Interface Prototyping 137

Figure 9-9: Interface Requirements Document—page 7

138 Chapter 9—Interface Design and Prototyping

SPECIFYING SYSTEM INTERFACES

Humans are not the only users of a software system. In today's wired world, computer
systems must often interface with other computer systems. For example, the library
system must be able to communicate with software systems at other libraries when
remote users search the asset database. Because this library system must conform to
existing communications standards, defining this interface is an important part of the
requirements-gathering process.

You can express the syntax of this communication using a metasyntax. The Backus-Naur
Form (BNF) is the most widely used metasyntax for expressing context-free grammars.
You can use BNF to define the syntax of a programming language, a configuration file, or
a communications protocol. Table 9-1 summarizes the Backus-Naur Form.

Table 9-1: Backus-Naur Form

Metasymbol Purpose
"literal word" Literal words are represented within double
quotation marks.
syntactic_category Syntactic categories are represented by words
without double quotation marks.
::= Two colons followed by an equal symbol
means "is defined as…"
[] Items contained within square brackets are
optional.
{} Items contained within curly brackets are
repeated zero or more times.
| Alternative items are separated by a vertical
line.
 When This Is Useful 139

The following is an example of a BNF grammar for an external search request:

search_request ::=
“search"
"author = '" author "'"]
"title = '" title "'"]
"isbn = '" isbn "'"]
"date = '" date "'"]
"subject = '" subject "'"]
The following line is a valid use of the preceding grammar:
search author = 'Booch' subject = 'software' subject = 'UML'

WHEN THIS IS USEFUL

Both interface design and prototyping are very useful when developing software. The
design of an interface is useful when beginning to put together the way a user will interact
with the software. Having users test the interface, allowing for changes that will possibly
have to be made, receiving feedback from users and developers on the user interface, all of
these are useful to the programmer(s) of a piece of software. Interface design provides
ways for the programming team to receive input and make changes early in the design
process that will save time and money for a company in addition to making an overall
better product.

Interface prototyping is a very important part of the interface design process because it
actually allows users and developers to study the interface being implemented and test the
interface for problems or unforeseen complications. Without prototyping there would
not be a way for the interface design process to receive feedback and testing, which would
nullify the entire purpose of interface design.
140 Chapter 9—Interface Design and Prototyping

Exercise 9-1: Defining interface requirements

1. Using a pencil and paper, create rough sketches of the user interface to the grocery
store inventory system you created in the preceding exercises.
2. The User Interface Components.jpg file is located in the
<CDROM:>\Supplemental_Files\Object_Oriented\Analysis_Design\Chapter 9
folder. This file contains basic user interface components that you can manipulate
using Paint Shop Pro (or another image-editing application) to demonstrate your
user interface. Download Paint Shop Pro from the Jasc Software site at the
following URL:
http://www.paintshoppro.com/
3. Create user interface diagrams; you can use the components provided in the User
Interface Components.jpg file if you wish. Import your diagrams into Microsoft
Word (or another word-processing application) to create a user interface design
document.
4. Using the Backus-Naur Form, create an interface control document that contains
the grammars for communication between the grocery store inventory system and
the hand-held computers used by employees shelving groceries.

SUMMARY
A good user interface is transparent to the user. Poorly designed user interfaces can be a
significant obstacle to users. It is often beneficial to design user interfaces as a metaphor
of some real-world object. User interface components should be self-evident, as well as
both internally and externally consistent. A well-designed user interface will provide
visual cues of the software's current state. Interface prototypes provide tools for defining
and refining requirements. Software prototypes implement the interface and basic
functionality in a simple software application. Paper prototypes utilize non-software tools
to describe a user interface. The interface between a software system and external software
systems can be defined using the Backus-Naur Form.
 Post-Test Questions 141

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. Describe how the term “metaphor” is used in interface design.

.....................................................................................................................................

.....................................................................................................................................
2. Describe the two types of software interface consistency.

.....................................................................................................................................

.....................................................................................................................................
3. Contrast Vertical and Horizontal prototyping.

.....................................................................................................................................

.....................................................................................................................................
142 Chapter 9—Interface Design and Prototyping
 10

Analysis Modeling

MMAAJJOORR T O P IICCSS

Objectives .................................................................... 144

Pre-Test Questions....................................................... 144

Introduction ................................................................ 145

Collaboration Diagrams............................................... 145

Flow of Events and Special Requirements .................... 151

Class-Responsibility-Collaboration Cards .................... 152

Class Analysis .............................................................. 153

When Is This Useful .................................................... 154

Summary ..................................................................... 155

Post-Test Questions ..................................................... 156

144 Chapter 10—Analysis Modeling

OBJECTIVES
At the completion of this chapter, you will be able to:

● Interpret collaboration diagrams.

● Create collaboration diagrams to illustrate a rough vision of system design.
● Create flow-of-events descriptions to accompany collaboration diagrams.
● Use CRC cards to aid in developing collaboration diagrams.
● Identify attributes.
● Identify aggregation and generalization relationships.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What do collaboration diagrams illustrate?

.....................................................................................................................................

.....................................................................................................................................
2. What is a sequence diagram?

.....................................................................................................................................

.....................................................................................................................................
3. What are CRC cards?

.....................................................................................................................................

.....................................................................................................................................
 Introduction 145

INTRODUCTION
In the preceding chapter, you were introduced to the three UML class stereotypes:
boundary, entity, and control. Boundary classes form the interface between a system and
its users. Entity classes represent data and real-life objects, and control classes represent
the actions and processes not represented in boundary or entity classes. In this chapter,
you will learn to combine these class types into collaboration diagrams. UML
collaboration diagrams describe, in a precise manner, the dynamics of a software’s
function and represent this information using automated processes. As a programmer,
collaboration diagrams provide simplified access to the functionality of a program,
therefore, providing timely and robust error analysis with improved options for system
upgrades.

COLLABORATION DIAGRAMS
Collaboration diagrams are a form of an interaction diagram that are used within the
analysis workflow to provide an overview of a system's design. They describe the
interaction between users and boundary classes and between classes themselves. Figure
10-1 is a portion of a collaboration diagram for the Check Out Asset use case. In this
example, a Librarian actor interacts with a boundary class, Check Out UI.

1: Select patron(patronID)

: Check Out UI
: Librarian

Figure 10-1: Collaboration diagram example

146 Chapter 10—Analysis Modeling

The labels associated with each of the actors and classes comprising a collaboration
diagram use the object : class notation, in which the class name appears after a colon. In
the preceding figure, the single boundary class is labeled Check Out UI. This notation
indicates that this class is of type Check Out UI. If you intend to specify an instance of a
class, you can use the object field to specify the name of the instance. For example, if the
activity depicted in the preceding figure could only be initiated by a librarian named
Mark, you could specify Mark by labeling the actor Mark : Librarian. Notice that at this
stage you need not be concerned with creating class names that conform to program
syntax or coding standards. Check Out UI is not a valid class name. The Check Out UI
boundary class actually represents a collection of classes representing windows, scroll bars,
and all the elements that form the user interface. For now, you are developing an
overview of the system, and details can be addressed later.

The line between the Librarian actor and the Check Out UI boundary class associates the
two. It provides a pathway for communication, which is in the form of messages. In this
case, a single message is passed from the Librarian to the boundary class. An arrow
illustrates the direction of this message.

Sequence numbers and parameter passing

Figure 10-2 expands on the preceding collaboration diagram. Notice that a control class,
Check Out Controller, has been added to the system. The control class is the center of
the Check Out Asset use case. It will act as a dispatcher, transmitting messages to other
classes that will perform the work of checking out an asset. The Check Out UI class sends
a message to the Check Out Controller class. Notice that both messages are labeled with
a sequence number. This numbering indicates the order in which messages are passed.
The first message is sent from the librarian to the Check Out UI class, which responds by
dispatching a message to the Check Out Controller class.

1: Select patron(patronID) 2: Select patron(patronID)

: Check Out
: Check Out UI
: Librarian Controller

Figure 10-2: Sequence numbers and parameter passing

 Collaboration Diagrams 147

The message to the Check Out Controller class is to select a patron. In order to perform
this action, the Check Out Controller class will need information about the patron being
selected. The patron's identification number (which is scanned or entered from the
library card) is passed as an argument to the Check Out Controller class. This notation is
intentionally formatted to the syntax of most programming languages. In most cases, the
messages sent between classes take the form of method calls.

Return values
Figure 10-3 expands on the preceding collaboration diagram. A third class, Patron
Account, has been added and is an entity class. A third message, Get Account Balance,
has been added between the Check Out Controller class and the Patron Account class.
This message takes no arguments because, in the final system, this message will be sent to
a specific instance of the Patron Account class. As noted previously, the Get Account
Balance can be thought of as a message call. The diagram can capture the return value for
use by the calling object. In this case, the return value is stored in a variable balance.

1: Select patron(patronID) 2: Select patron(patronID)

: Check Out
: Check Out UI
: Librarian Controller

3: balance := Get Account Balance

: Patron Account

Figure 10-3: Return value example

148 Chapter 10—Analysis Modeling

Message conditions
Figure 10-4 adds a second control class, the Pay Overdue Fine class. If the patron owes an
overdue fine, that fine must be paid before any library assets can be checked out. Thus a
condition is placed on message 4. The condition indicated by brackets indicates that the
Pay Overdue Fine message will only be sent if the account balance is greater than zero, or
balance > 0.

1: Select patron(patronID) 2: Select patron(patronID) 4: [balance > 0] Pay overdue fine

: Check Out : Pay Overdue

: Check Out UI
: Librarian Controller Fine Controller

3: balance := Get Account Balance

: Patron Account

Figure 10-4: Message condition example

 Collaboration Diagrams 149

Multiplicity
Once a patron has been selected and any outstanding overdue fines have been paid, the
librarian enters a cycle of adding assets to the list of assets to be checked out. This cycle
continues until all the assets being checked out have been added to the list. Figure 10-5
adds the Asset List class and the messages required to add assets to the list. The asterisk
next to message 5 indicates multiplicity; this message may be executed multiple times as
assets continue to be added.

1: Select patron(patronID) 2: Select patron(patronID)

5*: Add asset(assetID) 6: Add asset(assetID) 4: [balance > 0] Pay overdue fine

: Check Out : Pay Overdue

: Check Out UI
: Librarian Controller Fine Controller

3: balance := Get Account Balance

7: Add asset(assetID)

: Asset List : Patron Account

Figure 10-5: Multiplicity example

150 Chapter 10—Analysis Modeling

Figure 10-6 is the complete collaboration diagram for the Check Out Asset use case.

1: Select patron(patronID) 2: Select patron(patronID)

5*: Add asset(assetID) 6: Add asset(assetID)
8: Complete transaction 9: Complete transaction 4: [balance > 0] Pay overdue fine

: Check Out : Pay Overdue

: Check Out UI
: Librarian Controller Fine Controller

3: balance := Get Account Balance

7: Add asset(assetID)
10: Add assets to account
11: Mark assets as checked out

: Asset List : Patron Account

12: Mark assets as checked out

: Asset Database

Figure 10-6: Check Out Asset collaboration diagram

The collaboration diagrams created within the analysis workflow provide a rough
overview of how each use case will be implemented. Using an expanded notation,
collaboration diagrams can provide a more complete view of system design.
Collaboration diagrams during the design phase will be revisited.
 Flow of Events and Special Requirements 151

FLOW OF EVENTS AND SPECIAL REQUIREMENTS

Collaboration diagrams efficiently express the relationship between the classes in a use
case. However, it is difficult to fully comprehend the sequence of events. Collaboration
diagrams employ sequence numbering to assist in deciphering the order of events, but
tracing the path of messages can be time consuming.

Analysts can employ two methods to better communicate the sequence of message
passing within a collaboration diagram. One method is to create a second type of
interaction diagram called a sequence diagram. It contains all the same information
contained in a collaboration diagram, yet in a form that places greater emphasis on the
sequence of events than on specific object relationships. Creating sequence diagrams will
be discussed in a later chapter.

A second method is to supplement the collaboration diagram with a textual description

of the sequence of events called a flow-of-events description. The following is an example
of a flow-of-events description for the Check Out Asset collaboration diagram:

A librarian uses a bar code scanner or the keyboard to input a patron identification
number (1). The user interface dispatches the patron identification number to the
Check Out Controller (2). The Check Out Controller queries the Patron Account
for the patron's account balance (3). If the balance > 0, control is transferred to the
Pay Overdue Fine Controller (4). Once the patron's account balance is resolved,
the librarian may begin entering asset identification numbers, using a bar code
scanner or the keyboard. The asset identification number is dispatched from the
Check Out UI to the Check Out Controller, which adds the asset to a list of assets
being checked out. This process continues until all assets being checked out have
been added to the list (5, 6, 7). When the librarian has completed the process of
entering assets, he indicates to the Check Out UI that he wants to complete the
transaction (8). This message is relayed to the Check Out Controller (9). The
Check Out Controller adds the assets to the patron's account information and
marks the assets as checked out (10, 11, 12).
In addition to the flow-of-events description, each collaboration diagram may also be
accompanied by a special-requirements description. The special-requirements description
is a brief list of any non-functional requirements that should be considered.
152 Chapter 10—Analysis Modeling

CLASS-RESPONSIBILITY-COLLABORATION CARDS
Creating collaboration diagrams can be difficult, and the first design is rarely the final
design. Class-Responsibility-Collaboration (CRC) cards are a tool used to simplify the
analysis and design process.

Analysts use index cards to represent each prospective class. Each card is labeled with the
name of the class. A group of analysts and designers meet to discuss how the classes might
interact, and a list of fundamental responsibilities is created for each class. These
responsibilities are listed on the card. Next to each responsibility is the name of a second
class with which the class must collaborate to fulfill the responsibility. Figure 10-7
illustrates a sample CRC card for the Check Out Controller class. Responsibilities are
listed in the left column, and the collaborating classes are listed in the right column.

Check Out Controller

Pay Overdue Fine

Allow user to pay overdue fine
Controller

Check patron's account balance

Patron Account
Add assets to patron's account

Add assets to the list of assets being

checked out
Asset List
Mark assets as checked out

Figure 10-7: Example CRC card

Rather than continually redrawing collaboration diagrams, CRC cards can be shuffled
around a table as new scenarios are discussed. When analysts come to a consensus for a
particular use-case realization—analysis, they can begin translating the CRC cards into a
collaboration diagram. The resulting diagrams are then re-evaluated, perhaps several
times, until the team is satisfied with the design of the class interaction.
 Class Analysis 153

CLASS ANALYSIS
After completing collaboration diagrams, analysts take a closer look at individual analysis
classes. CRC cards and collaboration diagrams provide information about the classes in a
use-case realization—analysis, their responsibilities, and the classes with which they
collaborate. During class analysis, each class is analyzed more closely to identify class
attributes, aggregations, and generalizations.

Attributes
Class attributes are properties of a class. In Chapter 2, class member variables were
introduced. Think about member variables in terms of their data types. Within the
analysis workflow, analysis classes are assigned properties. Unlike programmers, analysts
are not concerned with specifics of implementation such as data type. Analysis class
attributes can be defined in more general terms. For example, a book has an ISBN; the
specifics of whether the ISBN will be stored as a string or as a set of integers can be
addressed in design.

Aggregation and generalization

One type of analysis relationship, the association, has already been introduced.
Collaboration diagrams depict associations between analysis classes. In Chapter 2, you
were introduced to the "uses a" relationship. Associations are "uses a" relationships; the
Check Out Controller uses a Patron Account. Two other relationships, the "has a"
relationship and the "is a" relationship, were also introduced. These relationships
translate to aggregation and generalization, which should be identified between classes as
within the analysis workflow.

Aggregation is the "has a" relationship. A patron's account information includes a list of
assets currently checked out. Within the system, a patron's account and the list of assets
are both represented by classes. The patron's account "has an" asset list. This relationship
is called an aggregation because an asset list is part of a patron's account. In many ways,
this relationship is identical to attributes.
154 Chapter 10—Analysis Modeling

Generalization is the "is a" relationship. You will recall from Chapter 3 that the "is a"
relationship denotes inheritance. A book "is a" lendable asset. In that way, a book inherits
all the attributes and functionality of a lendable asset.

WHEN IS THIS USEFUL

Many ways of describing processes include collaboration, sequence, and activity
diagrams. However, collaboration diagrams are most useful when providing information
on the specific relationships between all the classes that will be used throughout a process.
As shown above, relationships can be either very simple or extremely complex.

A few disadvantages of the way collaboration diagrams work include a lack of a clear
sequence of the process, or description of what happens when operations occur in
parallel. Thus, collaboration diagrams should be used only when a description of the
classes interacting is needed. When combined with the use of CRC cards, collaboration
diagrams provide a easy and efficient way to test class interactions as well as providing a
clear view of who will be involved with a process and how they will be involved.
 Summary 155

Exercise 10-1: Creating analysis models

In this exercise, you will conduct analysis modeling. Follow all the steps for each use case
you identified for the grocery store inventory system.

1. Identify high-level classes and create CRC cards for each class.
2. Using the CRC cards you created in Step 1, consider how the various classes might
interact. Determine responsibilities and collaborations for each class and write
them on the CRC cards.
3. Create a collaboration diagram to depict the relationships between classes.
4. Create a flow-of-events description.
5. If any special requirements exist, consider creating a special-requirements
description.
6. Identify attributes of the analysis classes you identified in Step 1.
7. Identify associations, aggregations, and generalizations of the analysis classes you
identified in Step 1.

SUMMARY
Collaboration diagrams are a form of interaction diagram used to describe the interaction
between classes in a use-case realization—analysis. A second type of interaction diagram,
called a sequence diagram, conveys the same information as a collaboration diagram, with
an emphasis on the sequence of events. A flow-of-events description can accompany a
collaboration diagram to better communicate the sequence of message passing. A special-
requirements description listing any nonfunctional requirements may also accompany a
collaboration diagram. CRC cards are a tool used to simplify the analysis and design
process.
156 Chapter 10—Analysis Modeling

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. How are CRC cards used in analysis modeling?

.....................................................................................................................................

.....................................................................................................................................
2. What is the purpose of a flow-of-events description?

.....................................................................................................................................

.....................................................................................................................................
 11

Class Diagrams

MMAAJJOORR T O P IICCSS

Objectives .................................................................... 158

Pre-Test Questions....................................................... 158

Introduction ................................................................ 159

Association................................................................... 160

Aggregation ................................................................. 163

Composition................................................................ 165

Generalization ............................................................. 167

Check Out Asset Class Diagram .................................. 168

Summary ..................................................................... 169

Post-Test Questions ..................................................... 170

158 Chapter 11—Class Diagrams

OBJECTIVES
At the completion of this chapter, you will be able to:

● Use class diagrams to illustrate system design.

● Describe the difference between reference objects and value objects.
● Identify when it is appropriate to use associations, aggregation, and composition.
● Use generalizations to illustrate inheritance.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What do class diagrams illustrate?

.....................................................................................................................................

.....................................................................................................................................
2. What three things does a UML class define?

.....................................................................................................................................

.....................................................................................................................................
 Introduction 159

INTRODUCTION
In the previous chapter, you were introduced to the UML class notation. This class
notation is used to represent a class name, variables, and the methods that comprise a
class's interface. Figure 11-1 illustrates the UML class notation for the Asset class.

Asset

title: String
acquisitionDate: Date
replacementCost: float
dueDate: DueDate

public checkOut()
public calculateDueDate()

Figure 11-1: UML class notation

In an earlier chapter, you were introduced to collaboration diagrams. Collaboration

diagrams illustrate the interaction between classes. Class diagrams are used to illustrate
the static relationships between the classes. Ultimately, the program code you will write is
a static set of relationships between the classes you define. The interactions between them
happen only at runtime. In this way, class diagrams are the foundation of the design
process. They form a snapshot of the system that will be constructed.

The UML classes, as illustrated in the preceding figure, are the building blocks of UML
class diagrams. They define a class' name, its attributes, and its public interface. These
elements are translated directly into program code. The static relationships also translate
into program code. Classes participate in four principal relationships:

● Association
● Aggregation
● Composition
● Generalization
160 Chapter 11—Class Diagrams

In this chapter, you will learn to define these static relationships between classes and
illustrate your design using class diagrams.

ASSOCIATION
The simplest relationship is an association. An association illustrates a "uses a"
relationship between instances of a class. An association provides a path for
communication between objects. In its most basic form, an association is represented by a
line between two classes. The examples in this chapter build upon the collaboration
diagram developed in Chapter 13. Figure 11-2 illustrates an association between the
CheckOutController class and the Patron class.

Patron
CheckOutController
name: String
accountID: String

Figure 11-2: Association example

The collaboration diagrams you developed earlier illustrated a relationship between the
CheckOutController and a Patron. This relationship is realized using a class diagram.
The association between them is a path for communication. The CheckOutController
class defines a pointer to a Patron object. The pointer will be used to communicate with
the patron.
 Association 161

Navigability
Note from the earlier analysis that a Patron does not need to communicate back to the
CheckOutController; the association between these classes is unidirectional. This
relationship is known as navigability and is represented using an arrowhead. Figure 11-3
illustrates the one-way association relationship between the CheckOutController class
and the Patron class.

Patron
CheckOutController
name: String
accountID: String

Figure 11-3: Navigability example

This figure clearly shows that the CheckOutController class must communicate with a
Patron but a Patron need not communicate with a CheckOutController. In the program
code, the CheckOutController will have a pointer to a Patron, but a Patron will not have
a pointer to a CheckOutController.
162 Chapter 11—Class Diagrams

Multiplicity
Multiplicity is used to denote the number of instances of a class involved in a
relationship. During the check-out process, the CheckOutController handles only one
patron at a time. Therefore the CheckOutController maintains an association with a
single Patron object. The multiplicity of a relationship is denoted by labeling its ends.
Figure 11-4 illustrates the multiplicity of the association relationship between the
CheckOutController class and the Patron class.

Patron
CheckOutController 1
name: String
accountID: String

Figure 11-4: Multiplicity example

Multiplicity can be represented by a single cardinal number, such as the example in the
preceding figure. It can also be represented using a range of numbers or an asterisk.
 Aggregation 163

AGGREGATION
Aggregation is used to show that one class is part of another class. Figure 11-5 illustrates
the aggregation relationship between the AssetList class and the Asset class. An asset list
contains assets; this is an aggregation relationship. This relationship is denoted using an
open diamond and a line between the classes. The open diamond on the AssetList side of
the relationship tells you that the AssetList "has an" Asset. The multiplicity indicator on
the Asset side of the relationship tells you that an asset list can have any number of assets,
from zero to infinity.

Asset

AssetList title: String

acquisitionDate: Date
* replacementCost: float
public addAsset() dueDate: DueDate
public deleteAsset()
public checkOut()
public calculateDueDate()

Figure 11-5: Aggregation example

It can be difficult to determine when aggregation is appropriate. Examine the Asset class
in the preceding figure. The Asset class has four attributes: title, acquisitionDate,
replacementCost, and dueDate. When this class diagram is translated into program code,
each of these attributes will translate into a class member variable. Each of these attributes
participates in a "has a" relationship. Just as an AssetList "has an" Asset, so too an Asset
"has a" String, a Date, and so on.

The difference between the two relationships is subtle. Instances of Asset are treated as
reference objects by the AssetList class. The attributes of the Asset class are treated as
value objects.
164 Chapter 11—Class Diagrams

Reference objects
An instance of Patron is an example of a reference object. Reference objects are said to
have identity. A patron named James Smith will be represented within the system by a
Patron object. Only one James Smith object will exist, and the classes that interact with
the James Smith object will pass object references to each other. In this way, any class with
a reference to the James Smith object can make changes to the object and the changes will
be reflected in all classes.

Value objects
Attributes are value objects. Value objects are a part of one, and only one, class. The Asset
class has an attribute dueDate. Many of the assets checked out on the same day will have
the same due date, but these objects do not have identity. If one asset is checked in the
following day and checked out by another patron, its dueDate will be changed to a new
dueDate. Even though multiple assets have the same original due date, only the dueDate
for the Asset being checked out will change because each maintains its own dueDate
value object. The dueDate object will exist only as long as the Asset object that owns it
exists. If the Asset object is destroyed, the dueDate will be destroyed along with it. Also,
queries about the due date of an Asset object will return a copy of the dueDate object, not
a reference.

In some circumstances, value objects must participate in complicated relationships with

other classes. It may be beneficial to the design to illustrate these relationships within a
class diagram. In these cases, a second type of "has a" relationship, called composition, is
used.
 Composition 165

COMPOSITION
Composition is a second type of "has a" relationship between a class and a value object. It
is represented by a closed diamond and a line between classes. Figure 11-6 illustrates the
composition relationships between the Patron class and the AssetList class, and between
the CheckOutController class and the AssetList class. The CheckOutController
maintains a list of assets being checked out. Therefore, it must contain an AssetList. A
Patron also contains an AssetList. The Patron always maintains a list of the assets he has
checked out. These lists are not the same. The CheckOutController’s list contains only
those assets currently being checked out. The Patron may already have assets checked out
and so his list is maintained separately. The AssetList class is included in the class diagram
because of the relationship it maintains with the Asset class.

Asset

title: String
acquisitionDate: Date
replacementCost: float *
dueDate: DueDate

public checkOut()
public calculateDueDate()

Patron AssetList

name: String
1
accountID: String
public addAsset()
public deleteAsset()

1 1

CheckOutController

Figure 11-6: Composition example

166 Chapter 11—Class Diagrams

As noted previously, classes involved in a composition relationship are similar to class

attributes. Indeed, an alternative notation for the composition relationship is to include
the component within the attributes section of its owner. Figure 11-7 illustrates the
alternative notation for the composition relationship.

Patron

name: String
accountID: String

AssetList

public addAsset()
public deleteAsset()

CheckOutController

AssetList

public addAsset()
public deleteAsset()

Figure 11-7: Alternative notation for composition

 Generalization 167

GENERALIZATION
Generalization is the "is a" relationship. It is used to denote inheritance within a class
diagram. A generalization is represented by a line and an open arrowhead. Figure 11-8
illustrates the generalization relationship between the Book and AudioCassette classes and
the Asset class. Notice that the name of the Asset class is in italic print. This indicates that
the Asset class is an abstract class. The AssetList class maintains an aggregation
relationship with the Asset class. Because the Book and AudioCassette classes inherit from
the Asset class, either class can be substituted in this relationship.

Book AudioCassette

author: String publisher: String

publisher: String playLength: int
isbn: String
public calculateDueDate() public calculateDueDate()

Asset

title: String
acquisitionDate: Date
replacementCost: float
dueDate: DueDate

public checkOut()
public calculateDueDate()
*

AssetList

public addAsset()
public deleteAsset()

Figure 11-8: Generalization example

168 Chapter 11—Class Diagrams

CHECK OUT ASSET CLASS DIAGRAM

Figure 11-9 is the complete class diagram for the Check Out Asset use case. Compare this
diagram to Figure 10-6, the Check Out Asset collaboration diagram. Consider how the
classes might communicate through this static structure to realize the functionality of the
Check Out Asset use case.

Book AudioCassette

author: String publisher: String

publisher: String playLength: int
isbn: String
public calculateDueDate() public calculateDueDate()

Asset
AssetDB
title: String
1 acquisitionDate: Date
* replacementCost: float *
public getAsset()
public updateAsset() dueDate: DueDate
public addAsset()
public deleteAsset() public checkOut()
public calculateDueDate()
1
Database

PatronDB
Patron AssetList
1 * name: String
1
public getPatron()
accountID: String public addAsset()
public updatePatron()
public addPatron() public deleteAsset()
public deletePatron()
1 1
1

CheckOutController

PayOverdueFineController

Figure 11-9: Check Out Asset class diagram

 Summary 169

In the next few chapters, you will learn how to create two new types of diagrams:
sequence diagrams and statechart diagrams. You will use sequence diagrams to illustrate
the flow of messages between design classes, and you will use statechart diagrams to
illustrate the design of individual classes.

Exercise 11-1: Creating class diagrams

1. Examine the collaboration diagrams you developed in Exercise 10-1. Consider
how each might be realized as a static class diagram.
2. Develop a class diagram for each collaboration diagram.

SUMMARY
Class diagrams illustrate the static relationships between classes in a system. Classes
participate in four principal relationships: association, aggregation, composition, and
generalization. Association is the "uses a" relationship. Aggregation and composition are
"has a" relationships. Aggregations are relationships between a class and a reference
object. Compositions are relationships between a class and a value object. Generalization
is the "is a" relationship, which is used to denote inheritance.
170 Chapter 11—Class Diagrams

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What are the four principal relationships classes participate in?

.....................................................................................................................................

.....................................................................................................................................
2. Which of the four principal relationships illustrates a “uses a” relationship, which
illustrates a “has a” relationship, and which illustrates an “is a” relationship
between instances of a class.

.....................................................................................................................................

.....................................................................................................................................
 12

Sequence Diagrams

MMAAJJOORR T O P IICCSS

Objectives .................................................................... 172

Pre-Test Questions....................................................... 172

Introduction ................................................................ 172

Return Values............................................................... 174

Message Conditions ..................................................... 175

Deletion....................................................................... 176

Multiplicity.................................................................. 176

Return Stack ................................................................ 178

Summary ..................................................................... 178

Post-Test Questions ..................................................... 179

172 Chapter 12—Sequence Diagrams

OBJECTIVES
At the completion of this chapter, you will be able to:

● Interpret sequence diagrams.

● Use sequence diagrams to illustrate the interactions between classes.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What is a sequence diagram?

.....................................................................................................................................

.....................................................................................................................................
2. In a sequence diagram, what does a box depict? What does a dashed line depict?
What does a arrow between boxes depict?

.....................................................................................................................................

.....................................................................................................................................

INTRODUCTION
In an earlier chapter, you were introduced to collaboration diagrams and you used them
to illustrate the flow of messages between objects. Sequence diagrams are a second type of
interaction diagram. Sequence diagrams convey the same information as collaboration
diagrams, but the sequence of events is more specific. You used collaboration diagrams
within the analysis workflow to illustrate the relationships between instances of analysis
classes. In this chapter, you will learn to use sequence diagrams to illustrate similar
relationships between instances of design classes.
 Introduction 173

Figure 12-1 is a simple sequence diagram. Objects are depicted using boxes across the top
of the diagram. A vertical dashed line called a lifeline extends down from each object.
Messages are passed from one object to another, depicted by an arrow. Each message is
labeled. At this stage in the development process, the labels should correspond directly
with class methods defined in the class diagram. In this example, a CheckOutController
object calls the PatronDB object's getPatron method. The patronID variable is passed as
an argument.

: CheckOutController : PatronDB

getPatron(patronID)

Figure 12-1: Sequence diagram example

174 Chapter 12—Sequence Diagrams

RETURN VALUES
The sequence of events proceeds down the diagram. Figure 12-2 includes a second
message between the CheckOutController object and the Patron object. You can see that
this message is delivered after the getPatron message because it appears lower in the
diagram.

: CheckOutController : PatronDB : Patron

getPatron(patronID)

balance := getBalance()

Figure 12-2: Return values example

As with collaboration diagrams, messages within a sequence diagram can have return
values. The getBalance method returns a patron's account balance. This value is stored as
a variable called balance. This variable can be used to set conditions on methods, or it can
be passed as an argument to subsequent methods.

The dotted arrow between the Patron object and the CheckOutController illustrates a
return from the getBalance method call. Returns could be included for all method calls
(including those without return values), but they are generally added only where they
contribute to the clarity of the diagram.
 Message Conditions 175

MESSAGE CONDITIONS
Example 12-3 adds a third message, the payFine message. The payFine message is a call to
the PayOverdueFineController object. It transfers control to the portion of the system
that handles overdue fines. This message should only be passed if the patron owes an
overdue fine. To illustrate this, a condition is placed on the message. The condition is
indicated between brackets. In this example, the payFine message will only be passed if
the patron's account balance is greater than zero (balance > 0).

: CheckOutController : PatronDB : Patron : PayOverdueFineController

getPatron(patronID)

balance := getBalance()

[balance > 0] payFine()

Figure 12-3: Message condition example

176 Chapter 12—Sequence Diagrams

DELETION
Notice the large X along the PayOverdueFineController lifeline in the preceding figure.
This X is called a deletion. A deletion indicates the death of an object. In this example,
the PayOverdueFineController is instantiated by the CheckOutController. Control is
transferred to the PayOverdueFineController object through the message payFine. Once
the overdue fine has been paid, the PayOverdueFineController deletes itself. The object
no longer exists and no additional messages can be sent to it. Objects may also be deleted
by other objects. A message arrow from one object's lifeline to a deletion on another
object's lifeline indicates that the deletion is performed by the first object.

MULTIPLICITY
Some messages may be sent multiple times. A patron may check out multiple assets
simultaneously. Figure 12-4 is the complete sequence diagram for the Check Out Asset
use case. The CheckOutController must add multiple assets to its AssetList object. The
addAsset method is called multiple times using a flow-control structure such as a while
loop. The multiplicity of this message is indicated with an iteration marker. The asterisk
next to the addAsset message indicates that this message may be sent multiple times.
 controllerList
: CheckOutController : PatronDB : Patron : PayOverdueFineController patronList : AssetList : AssetDB : Asset
: AssetList

getPatron(patronID)

balance := getBalance()

[balance > 0] payFine()

* addAsset(assetID)

getAsset(assetID)

checkoutAssets(controllerList)

* addAsset()

Figure 12-4: Check Out Asset sequence diagram

checkOut()
Multiplicity 177
178 Chapter 12—Sequence Diagrams

RETURN STACK
As one class's method makes a call to another class's method, a reference is placed on the
return stack so the CPU knows where to return to when the called method is complete. If
the called method calls a third method, a second reference is placed on top of the first. As
execution of each method completes, the references are removed from the stack in reverse
order and control is passed back to calling methods in reverse order. This process is
illustrated using the boxes (called activation boxes) along the lifelines of objects in a
sequence diagram. An activation box indicates a reference to one of the object's methods
on the return stack.

In the preceding figure, the CheckOutController makes a call to the Patron object's
checkoutAssets method. Notice that the activation box along the Patron object's lifeline
extends down the diagram past the checkOut message. This notation indicates that this
calling method remains active and on the stack until the methods it calls have returned.

Exercise 12-1: Creating sequence diagrams

1. Consider the class diagrams you created in the previous chapter's exercise. Identify
the sequence of message passing between objects that will realize each class
diagram's functionality.
2. Create sequence diagrams for each class diagram you created in the previous
chapter's exercise.

SUMMARY
Sequence diagrams are a form of interaction diagram. Like collaboration diagrams,
sequence diagrams illustrate the flow of messages between objects. Sequence diagrams are
used within the design workflow to illustrate the flow of messages between design classes.
 Post-Test Questions 179

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What does a X over a lifeline indicate?

.....................................................................................................................................

.....................................................................................................................................
2. How does one go about illustrating the return stack’s processes in a sequence
diagram.

.....................................................................................................................................

.....................................................................................................................................
180 Chapter 12—Sequence Diagrams
 13

Statechart Diagrams

MMAAJJOORR T O P IICCSS

Objectives .................................................................... 182

Pre-test Questions........................................................ 182

Introduction ................................................................ 182

States ........................................................................... 183

Transitions ................................................................... 183

Superstates................................................................... 185

Summary ..................................................................... 187

Post-Test Questions ..................................................... 187

182 Chapter 13—Statechart Diagrams

OBJECTIVES
At the completion of this chapter, you will be able to:

● Interpret statechart diagrams.

● Develop statechart diagrams to illustrate the internal workings of individual
classes.

PRE-TEST QUESTIONS
The answers to these questions are in Appendix A at the end of this manual.

1. What is a statechart diagram?

.....................................................................................................................................

.....................................................................................................................................
2. When is a superstate used in a statechart diagram?

.....................................................................................................................................

.....................................................................................................................................

INTRODUCTION
In an earlier chapter, you used class diagrams to illustrate how individual use cases will be
realized by a set of classes and static relationships. In this chapter, you will learn how
statechart diagrams can be used to illustrate the complete life cycle of a single object as it
exists throughout all use cases.

Statechart diagrams are similar to the activity diagrams you learned about in an earlier
chapter. As with activity diagrams, a closed circle represents the start of a sequence
diagram. Objects transition through a series of states until they destruct. States are
represented by rectangles with rounded corners, and transitions between states are
represented by arrows.
 States 183

STATES
States are represented by rectangles with rounded corners. Each state is labeled with a
state name. States may also be labeled with an activity. Figure 13-1 is an example of a
state. The state name is Adding Assets. Below the state name, the activity "do/add assets"
means that as long as the object remains in this state, it will be in the process of adding
assets.

Adding Assets

do/add assets

Figure 13-1: State example

TR A N S I T I O N S
The transition from one state to another is represented by an arrow. Figure 13-2 is a
statechart diagram for the CheckOutController class. The transition from the starting
point to the first state, Adding Assets, is automatic. As soon as a new
CheckOutController object is instantiated, it is moved into the Adding Assets state. Two
transitions exit the Adding Assets state; these transitions are labeled to indicate when each
will be followed.

The labels associated with transitions take the form of Event [Guard] / Action. All three
sections of the label are optional. The Event portion of the label describes an event that
will precipitate the transition. A Guard condition is a true-or-false condition that must be
true in order for the transition to be followed. The Action is a description of the action
that is taken following a transition.
184 Chapter 13—Statechart Diagrams

In Figure 13-2, two transitions exit the Adding Assets state. Notice that the Guard
conditions associated with these transitions are mutually exclusive: Only one can be true
at a time.

Adding Assets
[not all assets added]
do/add assets

[all assets added]

Verifying verified / complete

check out
Checking Out
do/verify eligibility Assets

Complete

Figure 13-2: Statechart diagram example

 Superstates 185

SUPERSTATES
Situations often arise in which multiple states want to transition to the same state
through a single transition type. In the library system example, a librarian may choose to
cancel the check-out process at any time before the CheckOutController object reaches
the Complete state. All three of the states (Adding Assets, Verifying, and Checking Out
Assets) can transition to the Cancelled state if the user decides to cancel. Figure 13-3
illustrates the difficulty in diagramming this situation.

Adding Assets
[not all assets added]
do/add assets

[all assets added]

Verifying verified / complete

check out
Checking Out
do/verify eligibility Assets

cancelled

cancelled
cancelled

Cancelled Complete

Figure 13-3: CheckOutController statechart diagram without superstate

186 Chapter 13—Statechart Diagrams

Instead, you can use a superstate. A superstate contains other states. Figure 13-4 is the
CheckOutController class statechart diagram using a superstate. The Adding Assets,
Verifying, and Checking Out Assets states are contained within a superstate called Active.
As substates, they inherit any transition in which the Active superstate can participate. A
single transition between the Active state and the Cancelled state makes this diagram
functionally equivalent to Figure 13-3.

Active

Adding Assets
[not all assets added]
do/add assets

[all assets added]

Verifying verified / complete

check out
Checking Out
do/verify eligibility Assets

cancelled

Cancelled Complete

Figure 13-4: CheckOutController statechart diagram with superstate

 Summary 187

Exercise 13-1: Creating statechart diagrams

1. Consider the design classes you identified in Exercise 15-1. Determine which
design classes would benefit from statechart diagramming.
2. Using Argo/UML, create a statechart diagram for each of the design classes you
identified in Step 1 of this exercise.

SUMMARY
Statechart diagrams are used to illustrate the complete life cycle of a single object as it
exists throughout all use cases. Statechart diagrams illustrate the series of state through
which an object will transition between its instantiation and destruction. States are
represented by rectangles with rounded corners. Transitions are represented by arrows.
Superstates can be used to make a statechart diagram easier to read.

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What do you use to represent a state in a statechart diagram?

.....................................................................................................................................

.....................................................................................................................................
2. What do you use to represent a transition in a statechart diagram?

.....................................................................................................................................

.....................................................................................................................................
188 Chapter 13—Statechart Diagrams
 14

Design Quality Issues

MMAAJJOORR T O P IICCSS

Objectives .................................................................... 190

Pre-Test Questions....................................................... 190

Introduction ................................................................ 190

Elements of Good Design ............................................ 191

Object-Oriented Design Metrics.................................. 193

Chidamber and Kemerer.............................................. 193

Metrics for Object-Oriented Design ............................ 196

Summary ..................................................................... 200

Post-Test Questions ..................................................... 201

190 Chapter 14—Design Quality Issues

OBJECTIVES
At the completion of this chapter, you will be able to:

● Identify elements of good design.

● Define cohesion.
● Define coupling.
● Use object-oriented design metrics.
● Interpret design metrics.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What characteristics does a well designed object-oriented system exhibit?

.....................................................................................................................................

.....................................................................................................................................
2. What is encapsulation?

.....................................................................................................................................

.....................................................................................................................................

INTRODUCTION
Every project should have a quality assurance process. This chapter will discuss common
quality assurance issues involved with creating software systems. The process should not
be thought of as something that occurs after most of the work is finished; it is an ongoing
process that occurs every step of the way.
 Elements of Good Design 191

ELEMENTS OF GOOD DESIGN

Properly designed object-oriented systems closely model the real world. Object-oriented
techniques are focused on data. Functionality is constructed around data to form classes.
Classes are blueprints for objects, which are instances of a class. Objects are digital models
of the parts of a real-world problem. Object-oriented techniques are used to effectively
manage the complexity of large software systems. When done properly, object-oriented
development results in software that is more maintainable, reusable, and scalable.

To achieve these goals, software designers must be mindful of proper design techniques.
Writing code for an object-oriented language does not guarantee an object-oriented
design. The language is only a tool. Indeed, it is possible to write object-oriented software
using non-object-oriented programming languages. You must pay attention to object-
oriented design principles to ensure that a proper object-oriented system is created. Well-
designed object-oriented software systems will exhibit the following characteristics:

● Encapsulation
● Abstraction
● High cohesion
● Loose coupling

Encapsulation
Earlier in this course, you learned how accessors and mutators are used to hide
implementation details. Accessors and mutators are intended to surround the data that
comprises a class. This technique is known as encapsulation, and it is critical to proper
object-oriented design.
192 Chapter 14—Design Quality Issues

Abstraction
Abstraction is closely related to encapsulation. In the first chapter, you learned that
software engineers think of objects as black boxes. Accessors and mutators provide an
interface to member data. Additional methods are defined to provide an interface to a
class’s functionality. The process of developing a class in terms of its interface and
functionality, rather than its implementation details, is called abstraction. No
implementation work is performed within the design workflow. The purpose of the
design workflow is to identify classes, define class interfaces, and describe class
interactions.

Cohesion
Classes are comprised of data and methods. Cohesion is a measure of how well these
pieces fit together. A cohesive class definition defines only the data and methods that are
relevant to the class. Consider the Book class. In the real world, a book has certain
attributes such as a title, an author, and an ISBN. A book can be checked out and then
checked back in. The class definition of a Book defines attributes for title, author, and
ISBN, as well as methods that allow a book to be checked in and out. The attributes
properly define a book, and the methods represent appropriate responsibilities for a book.
However, there may be a temptation to have the Book class perform less relevant
functions (such as verify a patron's account balance) before allowing itself to be checked
out. This represents an inappropriate responsibility of a Book and should be delegated to
another class.
 Object-Oriented Design Metrics 193

Coupling
Coupling is the degree to which classes are interdependent. Class relationships such as
"has a" and "uses a" tighten coupling. The more a class must interact with other classes,
the tighter its coupling; this means it can be more difficult to make changes to the system,
replace classes, or export class definitions for use in new software systems.

Classes necessarily maintain relationships with other classes, so a certain degree of

coupling is expected. The goal is to prevent classes from being so interdependent that
they are difficult to detangle. Remember that the purpose of using an object-oriented
approach is to create software that is more maintainable, reusable, and scalable. These
goals are accomplished when classes are designed with minimal coupling.

OBJECT-ORIENTED DESIGN METRICS

Proper design can be difficult to achieve, even for programmers with years of object-
oriented design experience. Before implementation work can begin, an effort should be
made to verify the soundness of the design. Until fairly recently, this exercise was limited
to a subjective review of the design. Today, a variety of objective measures have been
developed that have been proven to relate directly to product quality. In this section, you
will be introduced to a variety of object-oriented design metrics.

CHIDAMBER AND KEMERER

In 1994, Chidamber and Kemerer defined a suite of six object-oriented quality metrics.
These metrics provide an objective way to measure software quality. Three of these
metrics qualify as design metrics because sufficient information exists at design time to
perform metric calculations. In this section, you will learn how to apply these metrics and
evaluate their results.
194 Chapter 14—Design Quality Issues

Coupling between object classes (CBO)

The coupling between object classes (CBO) metric is a measure of how tightly coupled a
class is. CBO is the sum of all non-inheritance-related class dependencies. CBO is
effectively a count of all the "has a" and "uses a" relationships in which a class
participates. Lower numbers indicate loose coupling and are preferable. Classes with a
higher CBO depend more heavily on other classes. These classes may be more difficult to
maintain and less readily reused in new software systems. CBO can be evaluated visually
using a histogram. Figure 14-1 illustrates the proper distribution of CBO results. The
majority of classes should have a CBO between 0 and 2.

50%
% of Classes

40

20
10 8 7 6 5 4
0 1 2 3 4 5 6 7 8 9

Coupling Between Object Classes

Figure 14-1: Coupling between object classes (CBO) example

 Chidamber and Kemerer 195

Depth of inheritance tree (DIT)

The depth of inheritance tree (DIT) metric measures the depth of a class within the
inheritance hierarchy. A base class has a DIT measurement of 0. Its immediate children
have a DIT of 1, and its grandchildren have a DIT of 2. Classes with a DIT of greater
than 2 are fairly complex; maintenance of these classes is made difficult by the number of
methods that are inherited. A related metric is the number of methods inherited (NMI).
Figure 14-2 illustrates the proper distribution of DIT values.

50%
% of Classes

45
35

15
10
5
0 1 2 3 4

Depth of Inheritance Tree

Figure 14-2: Depth of inheritance tree (DIT) example

196 Chapter 14—Design Quality Issues

Number of children (NOC)

The number of children (NOC) metric is also related to inheritance. It measures the
number of subclasses that inherit directly from a class. Large NOC values are an
indication of effective code reuse, but values greater than 10 may be an indication that
subclasses are inheriting inappropriately. Figure 14-3 graphs NOC against DIT. Most
classes should fall below this line.
Depth In Tree

1 2 3 4 5 6 7 8 9 10

Number of Children

Figure 14-3: Number of children (NOC) example

METRICS FOR OBJECT-ORIENTED DESIGN

A second set of object-oriented metrics is the metrics for object-oriented design
(MOOD). MOOD is a set of six metrics that examine encapsulation, inheritance,
polymorphism, and message passing. MOOD metrics and Chidamber and Kemerer's
metrics complement each other. While Chidamber and Kemerer's metrics tend to
provide a fairly low-level perspective of software design by examining individual classes,
MOOD provides a system-level perspective. In this section, you will learn how to apply
the MOOD metrics and evaluate their results.
 Metrics for Object-Oriented Design 197

Method hiding factor (MHF)

The method hiding factor (MHF) is a measure of encapsulation. MOOD defines the
invisibility of a method as the fraction of classes for which the method is not visible,
excluding inherited methods. If a method is defined as private, it is visible only to itself
and its subclasses, and it is said to have an invisibility of 100 percent, or 1. Other
methods may range from 0 to 1. MHF is the average invisibility for all methods within a
system. Well-designed systems have an MHF of approximately 70 percent. Figure 14-4
illustrates the breakdown of invisibility measurements across classes in a well-designed
system.

50%
% of Methods

30
25
20
10 10
5
10 20 30 40 50 60 70 80 90 100%
Invisibility

Figure 14-4: Invisibility

Attribute hiding factor (AHF)

The attribute hiding factor (AHF) is closely related to the MHF. The invisibility of an
attribute is the fraction of classes for which the attribute is not visible, excluding inherited
methods. The AHF is the average invisibility for all attributes. In most cases, little reason
exists for AHF to be anything less than 100 percent.
198 Chapter 14—Design Quality Issues

Method inheritance factor (MIF)

The method inheritance factor (MIF) is a measure of inheritance. MIF is the number of
inherited methods divided by the total number of methods in all classes, including
inherited methods. Interpreting MIF can be difficult. A high MIF value indicates a lot of
inheritance and may be a signal that inheritance is being used inappropriately. A low
value indicates less inheritance and less code reuse.

Attribute inheritance factor (AIF)

The attribute inheritance factor (AIF) is also a measure of inheritance. AIF is the number
of inherited attributes divided by the total number of attributes in all classes including
inherited attributes. As with MIF, larger AIF values indicate higher use of inheritance.
Unlike a simple count of inherited classes, the MIF and AIF metrics measure the degree
to which inheritance facilitates reuse. If subclasses implement the majority of
functionality, then MIF and AIF values will be relatively low to reflect a lack of reuse.

Polymorphism factor (PF)

The polymorphism factor (PF) is a measure of the amount of dynamic binding in a
system. The PF is calculated by dividing the number of instances of polymorphism
(methods overridden by a subclass) by the total number of possible instances of
polymorphism (methods that could be overridden, including those that are overridden).
It is possible for the denominator in this equation (the number of possible instances of
polymorphism) to equal zero. In this special circumstance, PF is defined as zero. As with
MIF and AIF, a high PF value indicates a lot of inheritance and may indicate that
inheritance is being used inappropriately. A low value indicates less inheritance and less
code reuse.
 Metrics for Object-Oriented Design 199

Coupling factor (CF)

The coupling factor (CF) is a measure of how tightly coupled a design is. CF is defined as
the total number of unique coupling relationships between classes divided by the total
possible number of unique coupling relationships. Message-passing or semantic
relationships (i.e., "has a" and "uses a" relationships) are considered to contribute to
coupling and are counted toward the numerator. The total possible number of coupling
relationships is calculated as the square of the total number of classes minus the total
number of classes. A high CF value is an indication of tight coupling. A lower CF value,
representing loose coupling, is preferable. A well-designed system has a CF value of less
than 10 percent.

Exercise 14-1: Applying design metrics

1. Apply Chidamber and Kemerer's coupling between objects (CBO) metric to the
classes in your design model. Using a spreadsheet program, create a histogram to
illustrate the distribution of CBO values.
2. Apply the depth of inheritance tree (DIT) metric to the classes in your design
model. Using a spreadsheet program, create a histogram to illustrate the
distribution of DIT values.
3. Apply the number of children (NOC) metric to the classes in your design model.
Using a spreadsheet program, create a scatter graph to illustrate the distribution of
NOC values.
4. Determine the invisibility of methods defined in your design model. Using a
spreadsheet program, create a histogram illustrating the distribution of invisibility
values. Determine the method hiding factor (MHF) of your design.
5. Determine the attribute hiding factor (AHF) of your design.
6. Determine the method inheritance factor (MIF) of your design.
7. Determine the attribute inheritance factor (AIF) of your design.
8. Determine the polymorphism factor (PF) of your design.
9. Determine the coupling factor (CF) of your design.
10. Evaluate the results of Steps 1 through 9 to determine the strength of your design.
Consider the changes that could be made to improve your design.
200 Chapter 14—Design Quality Issues

SUMMARY
Properly designed object-oriented systems closely model the real world. A well-designed
object-oriented software system will exhibit encapsulation, abstraction, high cohesion,
and loose coupling. Encapsulation is the technique of wrapping data behind methods.
Abstraction is the process of developing a class in terms of its interface and functionality,
rather than its implementation details. Cohesion is a measure of how well the data and
methods that comprise a class fit together. Coupling is the degree to which classes are
interdependent. A variety of objective measures of design quality have been developed.
Chidamber and Kemerer identified six such metrics. The coupling between object classes
is a measure of how tightly coupled a class is. The depth of inheritance tree (DIT) metric
measures the depth of a class within the inheritance hierarchy. The number of children
(NOC) metric measures the number of subclasses that inherit directly from a class.
Another popular set of metrics is the metrics for object-oriented design (MOOD), which
provides a system-level perspective on design quality. The method hiding factor (MHF)
and attribute hiding factor (AHF) are measures of encapsulation. The method
inheritance factor (MIF) and attribute inheritance factor (AIF) are measures of
inheritance. The polymorphism factor (PF) is a measure of dynamic binding. The
coupling factor (CF) is a measure of coupling.
 Post-Test Questions 201

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What is abstaction?

.....................................................................................................................................

.....................................................................................................................................
2. What is cohesion?

.....................................................................................................................................

.....................................................................................................................................
3. What is coupling.

.....................................................................................................................................

.....................................................................................................................................
202 Chapter 14—Design Quality Issues
 15

Putting It All Together

MMAAJJOORR T O P IICCSS

Objectives .................................................................... 204

Pre-Test Questions....................................................... 204
Introduction ................................................................ 205
Detail Level.................................................................. 205
Tracing Forward and Backward Through OOAD
Artifacts ....................................................................... 206
Applying OOAD To Situations.................................... 206
Organizing Teams........................................................ 207
Deployment Diagrams................................................. 207
Refactoring .................................................................. 208
OOAD Artifacts and Implementation.......................... 209
Applying Patterns ........................................................ 210
Brokering..................................................................... 211
Summary ..................................................................... 211
Post Test Questions ..................................................... 212
204 Chapter 15—Putting It All Together

OBJECTIVES
At the completion of this chapter, you will be able to:

● Apply OOAD methods to real-life situations.

● Apply consistent methodologies when approaching OOAD.
● Solve OOAD design problems with the use of patterns.
● Understand the significance of use cases and logical program flow.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What are some variables to consider when configuring the process needed for a
project?

.....................................................................................................................................

.....................................................................................................................................
2. What are Use Cases?

.....................................................................................................................................

.....................................................................................................................................
3. The UML is divided into what application views?

.....................................................................................................................................

.....................................................................................................................................
 Introduction 205

INTRODUCTION
By this point in the text, you should be familiar with the process involved with OOAD,
as well as its functional capabilities. The goal of this chapter is to suggest real life areas of
application of the processes learned throughout this book.

DETAIL LEVEL
Why does someone need to bother to learn about OOAD? Are there any practical
benefits to using any non-UML based techniques? The main purpose of UML is to take
advantage of object-oriented languages. One might argue that a considerable goal of
software development is to develop programs with code that is completely functional and
objectively easy to maintain. If a programmer can accomplish these tasks in a timely
manner, then they may be considered a “successful programmer.” But there are other
points to consider rather than just delivery of software on time. OOAD provides the
software engineering practices that ensure that software accomplishes its tasks while
permitting easy reuse and maintenance. A development process that introduces one
abstraction at a time until the entire approach to the process has been painted allows the
process to be handled at levels necessary for understanding the components of each. Once
you’ve grasped the function of the essential components, you can configure the process
needed for each project. Some of the variables to consider are: team size, project size,
project complexity, timeline, skill levels, domain type, and organizational maturity.
206 Chapter 15—Putting It All Together

TR A C I N G F O R W A R D A N D B A C K W A R D T H R O U G H O O A D
ARTIFACTS
Throughout this book, we will learn about each OOAD level, as well as tools and utilities
to apply to each of these levels. To make good software, all artifacts must be combined
and put together according to their logically flowing connections to each other. The first
technique incorporates use cases. Use cases are the external picture of your system that
explain the system’s capabilities. A good collection of use cases is central to understanding
what the users want. Use cases are also good for interacting with the clients and getting
feedback. One of the prevailing theories of object-oriented analysis is that a use case
model is the glue that holds a development together. We should also consider the
significance of the domain model, which provides a definition of the environment or
framework where the program resides. The third technique is logical architecture, which
is best defined as the apparent structure of the system in a language that can be used to
communicate with the user*.

The traditional use case treats the system as a black box and shows how the entities in its
environment interact with it. These may be referred to as external use cases, as they show
how external entities in the domain model interact with the system. They are called use
cases because they establish how the external entities use the system to accomplish
planned processes.

*Daniel Rawsthorne: http://www.pols.co.uk/usecasezone/UseCaseConcepts.html

A P P L Y I N G O O A D TO S I T U A T I O N S
Situational OOAD seems to be the reason why many people study the details of object-
oriented programming. One can apply the methodologies taken from experience in
OOAD and incorporate them into solving problems in larger groups.
 Organizing Teams 207

O R G A N I Z I N G TE A M S
Organizing software development teams is an essential task in producing well structured,
robust, and functional programs in a timely manner. Software development teams are
common in the software engineering profession. In most cases, the productivity of teams
using OOAD produce significant improvements over strict individual software
development methods. Companies often organize teams that perform specific tasks then
integrate this work to produce a single working model or program. Large projects often
consist of quality checking teams, testing teams, and managers within programming
groups, teams that take advantage of the combined resources that OOAD has to offer.
Ultimately, we can recognize the application of patterns as powerful and effective tools.

DEPLOYMENT DIAGRAMS
The UML is divided into three application views: the static view, which is modeled using
the use-case and class diagrams; the dynamic view, which is modeled using state
transition diagrams; and a view called the architectural view, which is modeled using
deployment diagrams.

Deployment diagrams help in the visualization of how the software will be implemented
onto the hardware. Often projects fail to keep in mind the types of hardware that the
products will run on. A maintenence of platform independence and hardware use is
helped with the development of deployment diagrams. These are easy to create and
navigate because they have similar diagram notations.
208 Chapter 15—Putting It All Together

REFACTORING
Consider the principle of Software Entropy. This principle simply applies when a
program begins with a successful OO structure and, by adding functionality to the
program, results in a relatively complex mass of code. Part of this is problem depends
upon the scale of the program, often smaller programs become unnecessarily complex in
a short amount of time. For example, adding new features to a program is like building
on top of a structure that was initially unable to support certain functionality, but is now
“modified” to support what is needed. In such situations your options may be to redesign
the entire program or to only work on rewriting the new additions. Gradually added
complexity provides a small hurdle in the development timeline but often produces long-
term benefits of increased functionality.

Refactoring is used as a technique that reduces the smaller redesign problems. Refactoring
focuses not on redesigning the functionality of a program but in redesigning the
structure. Refactoring changes are usually done in small steps such as renaming a method,
moving a field from one class to another, or consolidating two similar methods in a
superclass. Martin Fowler has defined the following as successful refactoring principles.
(“UML Distilled” 2000)

● “Do not do both refactoring and adding functionality at the same time. Put a clear
separation between the two when you are working. You might swap between them
in short steps: half an hour refactoring, an hour adding new function, half an hour
refactoring the code you just added.
● Make sure you have good tests before you begin refactoring. Run the tests as often
as possible. That way you will know quickly if your changes have broken anything.
● Take short deliberate steps: moving a field from one class to another, fusing two
similar methods into a superclass. Test after each step. This may sound slow, but it
avoids debugging, and thus speeds you up.”
In application, one should consider refactoring their programs when older code becomes
exhaustive to navigate and maintain. Refactoring old code often results in overall
program efficiency and often reinforces overall understanding of program function.
 OOAD Artifacts and Implementation 209

OOAD ARTIFACTS AND IMPLEMENTATION

The primary artifacts of the UML may be defined from two perspectives: the definition
of UML and its use. To define a UML artifact we should examine UML semantics,
notation, and the language itself. UML semantics are used to present the UML
metamodel, its concepts (metaclasses), relationships, and constraints, as well as other
definitions.

The UML metamodel

The UML metamodel models elements and is similar to an object model, but its main
purpose is to provide common semantics of the elements of the UML. This metamodel
has not only allowed developers to agree on semantics, but it has also made team
organization easier by allowing members to unify and simplify common UML artifacts
and concepts.

The UML notation guide

The UML notation guide describes graphical UML notation and outlines the syntax
needed for model systems. These are representations of a user-level model, which is
semantically an instance of the UML metamodel.

Resolving implementation issues

Complex systems are constructed best by an organization of small models working in a
corresponding relationship with other models or artifacts. “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” (Rational Software 1997).
210 Chapter 15—Putting It All Together

APPLYING PATTERNS
The pattern is a fool-proof, repeated design that many programmers can use in similar
programming situations. Patterns give programmers a series of solutions and show
programmers what makes a good model and how to construct that model. It is similar to
a programmer's handbook that shows programmers how to do common things. Patterns
tend to look at the results of processes and example models, then describe common ways
of replicating the process. When teams are used for project design, it si an asset to have
knowledge about how to apply certain patterns and methods. It is not uncommon for
corporations to have a repository of documented patterns from the company’s history. A
software development group may then take each of these themes and describe them so
that other people can read the pattern and see how to apply it.

An important distinction to make between patterns and models is that a pattern must
include a description of its purpose and function. Patterns may consist of well
documented solutions, and they go beyond the basics of understanding a language or a
technique in modeling. Patterns provide not only solutions, but they establish proper
model construction and function. They tend to teach by example. Whenever someone
approaches a problem and implements OOAD, patterns often provide successful
solutions.

Combining layers
Pattern and model architecture is usually presented in a layered form. One should
consider combining similar layers when looking for simplicities in complex models or
patterns.
 Brokering 211

BROKERING
Brokering has become popular with the distribution of the CORBA architecture.
CORBA enables programs to communicate with each other, despite a difference in
programming languages or operating systems. The Object Request Broker (ORB), as
defined by the Object Management Group, is a component in the CORBA
programming model. The brokering of information acts as middleware between
networks. In the CORBA model, a client may request specific services without having a
specifically designated server. ORBs receive the requests and act as an interface to forward
appropriate information to the appropriate servers and send any relevant results back to
the client.

SUMMARY
The main purpose of UML is to take advantage of object-oriented languages. OOAD
provides the software engineering practices that ensure the software accomplishes its tasks
while permitting easy reuse and maintenance. Some of the variables to consider when
configuring the process needed for a project are: tean size, project size,project complexity,
timeline, skill levels, domain type, and organizational maturity. To make good software,
all artifacts must be combined and put together according to their logically flowing
connections to each other. The UML is divided into three application views: the static
view, which is modeled using the use-case and class diagrams; the dynamic view, which is
modeled using state transition diagrams; and the architectural view, which is modeled
using deployment diagrams.

Refactoring is the technique that reduces the smaller redesign problems. Refactoring
focuses on redesigning the structure of the program and not redesigning the functionality
of the program. Refactoring should be considered when the programs older code
becomes exhausting to navigate and maintain. Refactoring old code results in overall
efficiency and reinforces overall understanding of program function.
212 Chapter 15—Putting It All Together

The primary artifacts of the UML can be defined from two perspectives: The definition
of UML and its use. The UML metamodel models elements and is similar to an object
model. Its main purpose is to provide common semantics of the elements of the UML.
The UML notation guide describes graphical UML notation and outlines the syntax
needed for model systems. Complex systems are constructed best by an organization of
small models working in a corresponding relationship with other models. A pattern is a
full-proof, repeated design that several programmers can use in similar programming
situations. Pattern and model architecture is usually presented in a layered form.

P O S T TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What is refactoring?

.....................................................................................................................................

.....................................................................................................................................
2. What is the purpose of the UML metamodel?

.....................................................................................................................................

.....................................................................................................................................
3. What is the purpose of the UML notation guide?

.....................................................................................................................................

.....................................................................................................................................
 16

The Test Workflow

MMAAJJOORR T O P IICCSS

Objectives .................................................................... 214

Pre-Test questions........................................................ 214

Introduction ................................................................ 214

Test Cases .................................................................... 215

Test Procedures ............................................................ 217

Test Components......................................................... 218

Summary ..................................................................... 218

Post-Test Questions ..................................................... 219

214 Chapter 16—The Test Workflow

OBJECTIVES
At the completion of this chapter, you will be able to:

● Describe the test workflow.

● Define test case.
● Define test procedure.
● Define test component.

P R E - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What does a test model describe?

.....................................................................................................................................

.....................................................................................................................................
2. What three elements does a test model consist of?

.....................................................................................................................................

.....................................................................................................................................

INTRODUCTION
Within the test workflow, test designers develop a test model. The test model describes
how each build will be integration-tested and system-tested. The test model may also
describe tests to ensure that the system’s user interface components comply with the
interface requirements document. The test model consists of test cases, test procedures,
and test components. In this chapter, you will learn the purpose of each of the
components and how each is used to test the system before release.
 Test Cases 215

TE S T C A S E S
A test case describes one way of testing the system. It specifies the input to the system, the
conditions under which the test should be conducted, and the output expected. There are
two general types of test cases: black-box test cases and white-box test cases.

Black-box test cases do not involve the internal workings of the system. A black-box test
case verifies that the interaction between the system and its users complies with the use-
case model. Each black-box test case corresponds to a single use case (although a single
use case may have several black-box test cases associated with it). White-box test cases
verify the interaction between components of the system. These interactions were already
specified by use-case realizations-design, and each white-box test case corresponds to a
single use-case realization-design. Figure 16-1 illustrates the relationship between test
cases and the model elements that they verify.

X
Use Case Black-Box Test Case

X
Use-Case Realization--Design White-Box Test Case

Figure 16-1: Test cases

216 Chapter 16—The Test Workflow

Designing test cases

A test case describes one way in which a system will be tested. The test case specifies the
input to the system, the output from the system, and any conditions required to achieve
these results. Table 16-1 shows an example of a test case for the Check Out Asset use case.
This test case verifies that entering a valid account number results in the retrieval and
display of the account information associated with it.

Table 16-1: Test case for the Check Out Asset use case
Input The account number 987654321 is entered into the Account Number
Field.
Output The name "James Smith" appears in the Name field.
The address "14 Red Robin Ln, Orange, CA" appears in the Address
field.
Conditions Account number 987654321 exists in the account database.
The account record for account number 987654321 reflects the name
"James Smith" and the address "14 Red Robin Ln, Orange, CA."

While each black-box test case relates to a single use case, each use case is tested by
numerous test cases. Additional test cases may test other aspects of the Check Out Asset
use case. Some may be nearly identical to the preceding example (except for differences in
the specific inputs, outputs and conditions). For example, a second test case may be
created to ask test engineers to enter the account number 123456789.

Each test case is evaluated on a pass/fail basis. If the outputs exactly match those
described by the test case, then it is said to pass. Any deviation results in a failure. A
document detailing test results will reference each test case individually and describe
system performance in each case as "pass" or "fail."
 Test Procedures 217

TE S T P R O C E D U R E S
A test procedure describes the method for performing one or more tests. A test procedure
describes how input is entered into the system using the user interface, and how the user
interface reveals the results to the user. A single test procedure may apply to several test
cases, and each test case may be governed by multiple test procedures. Following is an
example of a test procedure that applies to the test case example presented earlier.

1. Begin execution of the librarian client by double-clicking the Library System icon.
2. From the opening screen, select the Accounts tab.
3. Click the Create New Account button.
4. In the dialog box that appears, enter the account number and information
provided by the test case.
5. Click the Done button.
6. Exit the librarian client by clicking the Close Window button (X) in the upper-
right corner of the window.
7. Reboot the client machine.
8. Begin execution of the librarian client by double-clicking the Library System icon.
9. From the opening screen, select the Check Out tab.
10. Enter the account number provided by the test case in the Account Number field,
and press ENTER.
11. The output should be displayed in the Name and Address fields on the same
screen.
Notice that the preceding test procedure is a general description of how the test case
should be implemented. This test procedure may be applied to all test cases designed to
verify the system’s ability to locate and display a patron’s account information.
218 Chapter 16—The Test Workflow

TE S T C O M P O N E N T S
Test components are used to automate the testing process. Test components are programs
or scripts that are executed against the system to perform testing. They may be developed
using scripting languages, proprietary test languages as part of a test-automation tool, or
as test classes that will be temporarily integrated with the system to perform testing.
Automated testing allows test engineers to more thoroughly test the system.

Exercise 16-1: Performing test modeling

1. Create two to five black-box test cases for each of the use-case realizations-design
in your design model.
2. Create two to five white-box test cases for each of the use cases in your use-case
model.
3. Create test procedures to describe how each test case should be performed.

SUMMARY
The test model describes how each build will be integration-tested and system-tested.
The test model consists of test cases, procedures, and components. A test case describes
one way of testing the system. Each test case specifies the input to the system, the
conditions under which the test should be conducted, and the output expected. A test
procedure describes the method for performing one or more tests. A test procedure
describes how inputs are entered into the system using the user interface and how the user
interface reveals the results to the user. Test components are used to automate the testing
process. Test components are programs or scripts executed against the system to perform
testing.
 Post-Test Questions 219

P O S T - TE S T Q U E S T I O N S
The answers to these questions are in Appendix A at the end of this manual.

1. What does a test case desribe?

.....................................................................................................................................

.....................................................................................................................................
2. What does a test procedure describe?

.....................................................................................................................................

.....................................................................................................................................
3. What are test components used for?

.....................................................................................................................................

.....................................................................................................................................
220 Chapter 16—The Test Workflow
 231
SELF-STUDY

Glossary
<APPLET></APPLET>
HTML (Hyper Text Markup Language - the language used to code web pages) tags used to embed an
applet.
abstract
A class or method that is incompletely defined, used to collect shared properties, behaviors, or
attributes in a single superclass.
Abstract Windowing Toolkit (AWT)
A package of Java classes that support GUI (Graphical User Interface) programming - part of the JFC
(Java Foundational Classes).
abstraction
The consideration of an object in terms of its functionality and not its implementing details (see also
abstract).
accessor
A method designed to allow outside classes to access information about an object while maintaining
the principles of encapsulation and information hiding.
add()
A method of Container used to add components to a GUI container.
addItemListener()
One of a series of methods that register a listener object with its source for notification of some
specified change of state; this method is always of the form addSomeListener().
ALIGN
Optional attribute which can be imbedded within APPLET tags in HTML code; specifies the
position of the applet.
allocate
Java sets aside (allocates) enough space in memory for a data structure as soon as it is fully defined;
connected with the idea of instantiation.
ALT
Optional information to embed an applet; allows you to display a comment to a Java-disabled
browser.
anonymous inner class
An inner class defined within an expression; not a top level class which is part of a package.
applet
A small Java program that must be run from a Web browser or the Appletviewer; more restricted in
permitted activities than applications for security reasons.
232 Application Programming Interface (API)

Application Programming Interface (API)

The pre-written code that provides the built-in functionality of Java. The term is also used to refer to
the organized descriptions of classes and their methods within this pre-written code.
arithmetic operators
Operators that perform manipulation on numbers.
ASCII
A standard means to represent characters as integers ranging from 0 to 127.
atomic process
Refers to an operation that is never interrupted or left in an incomplete state under any circumstance.
bitwise operators
Operators that perform logical manipulation comparing and changing each bit.
boolean expression
An expression that returns true or false; the result of a relational or logical operation.
BorderLayout
A layout manager that adds components in specified regions.
BoxLayout
A layout manager that adds components horizontally or vertically.
break
A statement that causes the current conditional or iteration statement to terminate.
bytecode
A platform-neutral file consisting of bytes that the JVM can execute.
callback
When an object refers back to a class to which it has gained reference.
casting
Converting values from one data type to another.
class
One of the most fundamental parts of Java (and other object-oriented languages) data structure.
Classes contain methods, variables, and even other classes. Top-level classes belong to a package.
class member
A variable or method that exists only once for the class regardless of how many objects are created;
designated by the keyword static.
CODE
Essential information needed to embed an applet; specifies the name of the applet class. Example:
<APPLET CODE=AppletSubclass.class WIDTH=anInt HEIGHT=anInt>
</APPLET>
code block
A sequence of statements contained in curly braces.
CODEBASE
Optional information to embed an applet; specifies a relative directory in which to save the applet
class. Example: CODEBASE="someDirectory/"
 event 233

Color
A class of the AWT that represents colors.
concatenation
The act of adding Strings together.
constructor
A special method having the same name as its class. It returns an instance of its class.
Container
An abstract, high-level component that offers JFrame and JPanel much of their functionality.
cooperative multitasking
A system of multitasking in which one task must willingly yield to another task.
coupling
The level of interdependency between objects.
daemon thread
A thread designed to service user threads. Daemon threads terminate after the last user thread
terminates.
dead
The state of a thread once it has been stopped or the run() method has exited.
deadlock
A condition that occurs when two or more threads reach an impasse due to competition for object
monitors.
default constructor
A constructor without parameters; Java assumes a default constructor until you define your own.
destroy()
The last method called in the life cycle of an applet; should be used to release system resources.
Domain Name System (DNS)
A system that converts domain names into corresponding IP addresses.
dot notation
A reference used to access a member of an object.
drawRect()
A method of the Graphics class.
encapsulation
The wrapping of variables and methods together; variables can only be accessed through the methods
provided.
entry condition/ exit condition
Condition based on whether the boolean expression is evaluated at the beginning or the end of the
loop.
Error
An inoperable condition that can occur in a program and cause it to terminate.
event
An occurrence or happening such as a pre-defined change of state in a component.
234 event delegation model

event delegation model

The event handling model used in JDK 1.1 and SDK 1.2.
event object
The informational object Java creates in response to an event.
Exception
An abnormal condition that occurs in a program; also the name of a class in java.lang. An elaborate
system of exception handling functionality exists within the JFC.
extends
The Java keyword that designates the class that a new class is to be derived from.
File
A Java class abstracting the nature of a system file.
FlowLayout
A layout manager that adds components centered on each line, top to bottom, in a flowing manner
similar to the layout of HTML pages.
Font
A class of the AWT that represents fonts.
getParameter()
A method of Applet used to obtain the name/value pairs sent by the HTML page.
Graphics
An abstract class used to get a graphics context of a Component or Image.
graphics context
The workable representation of the Graphics class for a Component or Image.
GridLayout
A layout manager that adds components in a grid-like format.
handleEvent()
The method most widely used in the JDK 1.0 to handle event processing.
ID
A way of distinguishing the type of event generated.
identifier
Another term for a variable name.
if statement
The basic conditional statement; chooses different control flow paths based on the value of some
boolean statement.
ImageIcon
A class that facilitates the display of images; implements the Icon interface
immutable
Unable to be changed; a characteristic of Strings.
implicit vs. explicit casting
Explicit casting requires you state the type name being converted to; in implicit casting, the type is
implied.
 JComponent 235

import
A statement that makes a package available for use within a class.
index
A numeric reference to a specific element of an array; the only way to access elements of an array.
inheritance
Properties or attributes of a class which are not explicitly stated but passed down from its
superclass(es).
init()
The first method called in the life cycle of an applet; it resembles a constructor.
inner class
A class defined within the body of another class.
InputStream
The abstract class from which all other input byte streams are derived.
InputStreamReader
A utility stream that converts a byte stream into a character stream for input.
instance and class variables
Variables defined outside of any method; they are available throughout the class.
instance member
A variable or method unique for each object (instance of the class).
instantiation
The use of a class definition to create an object.
interface
Term used to define a collection of method definitions and constant values which can be
implemented by classes that define this interface with the "implements" keyword.
IP (Internet Protocol) address
A numeric configuration used to identify a unique computer on the Internet.
java
The command given to execute bytecode (*.class) file.
Java 2 Software Development Kit (SDK)
A set of Java tools available from Sun for free; includes the Java compiler, interpreter and debugger,
along with documentation.
Java Virtual Machine (JVM)
The artificial computer that runs Java programs.
javac
The command that compiles a Java source file (*.java) into a bytecode file (*.class).
JButton
A simple clickable widget.
JComponent
A high-level Swing class from which many other components receive their core functionality.
236 JDK 1.0

JDK 1.0
The original release of the Java Software Development Kit, whose event model has now been
deprecated.
JFileChooser
A Swing component used to retrieve the names of files.
JFrame
The fundamental Window in Java; it cannot be contained in another container.
JLabel
A Swing widget used to place text in relation to an icon.
JPanel
A low–level Container used to hold other Containers; can also be used as a drawing surface.
JScrollBar
A Swing widget used to visually select a single value from a range.
JScrollPane
A Swing text-entry widget that adds scrolling functionality to other components.
JTextArea
A multiline text-entry widget in Swing
JTextField
A single-line text-entry widget in Swing.
label
An identifier that points to a specific line of the code to where a loop can break or continue.
layout managers
Objects used to control the positioning of Components within a Container.
length property
A characteristic of an array; more specifically, how many elements it contains.
life cycle
The life of an applet as defined by the init(), start(), stop() and destroy() methods.
listeners
Classes that listen for, and usually process, the events generated by an event source. Such classes will
implement an appropriate listener interface.
literal
A representation of an actual value for a data type. For example; 12 is a literal integer.
local variable
Variables defined inside of a method; they are not available when the method is not running.
logical operators
Operators &, |, ^, and ~ used on primitive data types to perform bitwise operations.
lower-level container
A Container that must be contained in another Container as in a JPanel.
main thread
The user thread created by the JVM from which all other user threads are generated.
 object 237

member
A general term for both methods and variables.
member inner class
An inner class defined at the same scope as a method or instance variable.
method
A “callable” block of code defined within a class.
method signature
The method name and parameter types; the return type is not included in the signature.
modal
A property designating that a component blocks its parent Component until properly responded to.
monitor
In essence, the lock and key for an object
multiprocessing
The ability to run multiple processes (applications) in parallel.
multitasking
The ability to perform more than one function simultaneously.
multithreading
The ability to perform multiple lines of instruction within a single process.
mutator
A method that modifies a variable.
MyCloseableFrame$ MyButtonListener.class
The $ is the notation that the Java Compiler uses to identify an inner class.
nesting
The use of Containers within Containers to achieve sophisticated layouts or the use of conditionals
within other conditionals.
networking
Computer-to-computer communication across a distance.
new
A keyword that signals the JVM to allocate space for an object.
new
The state of a thread once it has been instantiated.
no-arguments constructor
A constructor for a class having no parameters; the default constructor is an example.
not runnable
The state of a thread when it is removed from the runnable queue but is not dead.
object
A generic term for non-primitive data types; objects represent data and the operations on data.
object
An instance of a class, with unique data and operations.
238 OutputStream

OutputStream
The abstract class from which all other output byte streams are derived.
OutputStreamWriter
A utility stream that converts a character stream into a byte stream for output.
overloading
Two or more methods with the same name and different parameter types; they usually implement
similar types of operations.
overridden method
A method in a derived class with the same method signature as that of a method in the superclass; it
replaces the superclass method for the subclass.
package
A collection of classes designated by the package keyword; Java stores the classes in a directory
structure based on the package.
paint()
An inherited method from Container that allows painting to the applet surface.
paintComponent
(Graphics g)
A method inherited from JComponent that is passed a reference to the graphics context of that
component.
parameter
Information sent to a called method which includes data type and local name.
parameter tags
Optional name/value tags that send information to an applet from within the HTML page.
pass by reference
A pointer to the data is passed to a method; changes made to the data by a method are also made to
the original data. Although Java always uses pass by value for primitive data types, pass by reference is
used for non-primitive data types because the value for a non-primitive type is a reference.
pass by value
A copy of the value of the variable is available to the method; changes to the copy do not affect the
original value; used by Java for primitive data types.
persistent
The ability to maintain a prior state.
polymorphism
Using one method name to invoke many different methods.
port
An integer from 0 to 65535 representing a particular path for information flow, a specific protocol is
typically associated with a particular port; usually associated with networking.
pre-emptive multitasking
A system of multitasking in which one task can pre-empt another task if it has a higher priority.
primitive data types
The basic data building blocks of the language; all the primitives consist of a single value.
 servlet 239

private
Access modifier that is applied to the member only; restricts access to the class in which it is defined.
protected
Access modifier that allows the class to be seen by classes in the same package or subclasses in other
packages.
public
Access modifier that allows the class or member to be seen by every part of the program.
Reader
The abstract class from which all other input character streams are derived.
reference
Java stores the location of a non-primitive type in the variable; the actual memory for the type exists at
the pointed-to-memory location.
relational operators
Operators that compare values of variables; all evaluate to the boolean data type (false or true).
repaint()
A method of Component that is used to indirectly call paintComponent() for a graphics update.
run()
The method that contains the body of a thread.
runnable
The state of a thread once it has been started.
Runnable interface
An interface that prototypes the run() method, targeting it as a thread.
RuntimeException
A set of possible conditions that can occur in a program and cause an illegal operation.
sandbox
The strict security restrictions placed on applets.
scope
The range over which a variable is available for use.
SDK 1.2
The current release of SDK with a much improved event model.
SecurityManager
A Java class used by browsers to set security restrictions on an applet.
Serializable interface
An interface that marks an object to be serialized.
serialization
The process of maintaining an object's state by converting it into a byte stream.
ServerSocket
A class in Java that represents the socket model for servers.
servlet
A small Java application that runs on a server.
240 setColor()

setColor()
An overloaded method of the Graphics class that establishes the current color of the graphics
context.
short-circuit operators
Operators that do not evaluate all the relational operations unless necessary.
signed applet
A digitally signed applet; if accepted by the user, security limitations are reduced.
Socket
A class in Java that represents the socket model for clients.
source
The Component that generates the event object.
stand-alone application
A Java program that need not be run in a browser.
start()
The second method called in the life cycle of an applet.
start()
The method that starts a thread by calling the run() method.
static
A keyword used to designate a class variable (and also a class method). Class methods and variables
exist only one time, as opposed to instance methods and variables that exist for each object of the
class.
stop()
A method that works in conjunction with start(); should be used to suspend resource-draining code.
stream
A path of information from a source to a destination.
StringBuffer
A peer class to the String class; it is not immutable.
strongly typed
Requiring that the programmer specify the kind of information that each variable can hold; used to
describe a language.
super
The keyword used to refer to the superclass object; it allows you to call a method defined in the
superclass.
super
A keyword referring to the superclass of the current class.
superclass/subclass
The superclass is extended by the subclass. The subclass is derived from the superclass.
Swing
A GUI toolkit used by Java.
switch statement
A more complex conditional statement; chooses from multiple options.
 Writer 241

synchronization
Controlling the flow of multiple, simultaneous threads.
synchronized
The keyword used to access an object's monitor.
System.in
Java's version of standard input (usually the keyboard).
System.out
Java's version of standard output (usually the monitor).
tag an object
Implementing a dummy interface on an object for the sole purpose of giving that object a type.
TCP/IP
The premier set of networking protocols used for the Internet.
this
A keyword that refers to the current object.
thread
A division of execution within a program. Each thread can be started and stopped and can wait for
other threads to suspend or run concurrently with them.
thread racing
Competition between two or more threads for the same resource.
thread states
The various ways of describing the current state of a thread.
top-level container
A Container that cannot be contained in another Container as in a JFrame.
transient
A member marked as transient will not be serialized.
type
Identifies the kind of information that a variable can store.
user thread
A thread created by other user threads with the purpose of being controlled by the programmer.
widgets
A term used to refer to visual Components of a GUI.
WIDTH/HEIGHT
Essential information needed to embed an applet; determines the size of the applet.
WindowListener
One of many interfaces that allow an object to receive certain events.
wrapper
A class that wraps around other stream classes to add functionality.
Writer
The abstract class from which all other output character streams are derived.
242
 393
SELF-STUDY

Index
Symbols Applet .......................... 18, 39, 44, 57-59, 85,
93-95, 109, 111, 137, 198, 207, 239, 311
- ............................................................... 239 Applet features................................. 150, 160
"Event-to-property"................................. 144 Applet viewer............................................. 32
"Faux" variables ......................................... 70 Applet() .................................... 150, 159-160
% ............................................................. 239 Application programming interfaces
( ) ............................................................. 239 (apis) .................................................... 290
(Pme) paradigm ......................................... 14 Application template ............................... 190
* ............................................................... 239 Applications......................................... 17, 54
+............................................................... 239 Arranging and copying components........ 108
/ ............................................................... 239 Arranging components ............................ 109
=............................................................... 239 Array..........................283, 285-286, 300-301
= Null ........................................................ 46 Au, aiff, midi and wav ............................. 174
A Authentication......................................... 194
Awt ............................................................ 67
A project ......................................... 24-25, 35
Abstract...................................................... 45 B
Abstract windowing toolkit (awt) .............. 67 Background ............................................... 69
Action performed..................................... 127 Basic containers ......................................... 87
Actioncommand ................................ 73, 200 Bean........ 26, 63, 76, 225, 292, 296, 301-303
Actionevent.............................................. 131 Beaninfo ........................................... 297-298
Actionlistener................................... 127, 130 Beanname .................................................. 69
Actionperformed............... 126, 146-148, 200 Beans list......................................... 27-28, 35
Actionperformed feature.......................... 204 Beans list window................................ 28, 35
Actionperformed() ................................... 131 Block header .............................................. 41
Activex ..................................................... 291 Blue ........................................................... 43
Add ............................................................ 50 Body ........................................................ 161
Add (string) ............................................. 148 Boolean............................................ 234, 240
Add method ............................................... 93 Border...................................................... 100
Add(action).............................................. 154 Border layout........................................... 104
Adding new windows to an application... 206 Bound ...................................................... 299
Additem(string) ....................................... 149 Box .......................................................... 100
Addition................................................... 239 Box layout................................................ 107
Alignment.................................... 71, 99, 102 Break ....................................................... 280
All problems ............................................ 307 Browser.................................................... 208
An applet .............................................. 24-25 Bufferedreader ......................................... 216
Append(string)......................................... 153 Button ............................. 68, 73, 78, 86, 146
Button and checkbox components ............ 73
394 Index

Buttongroup ........................................ 79, 86 Configuring the compiler .......................... 59

Byte ......................................................... 234 Connect ................................................... 123
Byte code ............................................. 38, 40 Connectable............................................. 128
Connectable features ....................... 123, 204
C Connecting .............................................. 364
C++.................................................. 282, 290 Connecting a component to open
Canvas .................................... 85-86, 89, 146 a window.............................................. 206
Card......................................................... 100 Connecting menuitems ........................... 203
Card layout .............................................. 106 Connections....................................... 31, 141
Casting..................................................... 242 Constrained ............................................. 300
Casts ........................................................ 242 Constraints ........................................ 69, 105
Char................................................. 234, 240 Construction.............................................. 47
Checkbox ..................................... 68, 73, 147 Constructor ............................................. 237
Checkboxgroup....................... 73, 85-86, 149 Container........................................... 85, 114
Checkboxgroup/buttongroup .................... 90 Container properties.................................. 92
Checkboxmenuitem......................... 199, 201 Continue.................................................. 281
Choice.................................... 68, 74, 78, 149 Copy ........................................................ 111
Choice or list ............................................. 75 Copying ............................................ 110-111
Class ................. 12, 15, 43-47, 52, 56, 59, 62 Corba................................................ 291-292
Class file ........................................... 171-172 Create class smartguide ........................... 187
Class path .................................................. 62 Create method smartguide ...................... 188
Class/interface ........................................... 23 Creating.............................. 40, 46-48, 55, 59
Classes .......................... 39, 41, 43-45, 47, 52 Creating connections............................... 123
Clearselected() ......................................... 157 Cursor........................................................ 92
Clearselection .......................................... 154 Customization ......................................... 292
Clearselection()........................................ 155 Customizer .............................................. 298
Client....................................................... 359 D
Client-side security ........................... 183-184
CODE ..................................................... 173 Data entry category ................................... 68
Code ......................................... 172-173, 175 Data entry components ............................. 71
Code signing............................................ 194 Database .......................................... 292, 319
Columns .................................................... 72 Debugging ............................................... 307
Columns, rows........................................... 72 Declaration ........................................ 47, 236
Com......................................................... 291 Default....................................................... 60
Comments ................................................. 43 Default directories ..................................... 60
Common object request broker architecture Default layout manager ........................... 115
(corba) .................................................. 291 Definition .................................................. 47
Compact repository ................................... 52 Delete ........................................................ 50
Component........199, 288-292, 294-297, 302 Deleting components ................................ 53
component................................................. 30 Deleting connections ................................. 53
Component abundance ........................... 290 Deleting files.............................................. 52
Component palette ....... 27, 29-30, 33, 35, 45 Description .............................................. 299
Component properties..................... 146, 151 Design ......................20, 25-27, 29-30, 32-35
Components ........................... 28-31, 33, 114 Design window........25, 27, 29-30, 32-33, 54
Concepts.................................................. 310 Destruction................................................ 47
 Index 395

Dialog .......................................... 78, 85, 206 Exercise 9-2

Dialog forms............................................ 206 Using an interface................................. 179
Directory ................................................. 218 Exercise 10-1
Display name........................................... 299 Creating a quiz application ................... 192
Dispose ............................................ 223, 226 Exercise 11-1
Dispose() ...................150, 159-160, 207-208 Adding menus to the
Distributing............................................. 359 QuizApplication................................ 209
Division ................................................... 239 Exercise 12-1
Document........................................ 153, 158 Adding Open and Save options to
Double..................................................... 234 the QuizApplication.......................... 224
Exercise 13-1
E Using variables and arithmetic .............. 247
Echochar ............................................ 72, 158 Exercise 14-1
Editable....................................... 72, 155-156 Using conditional statements
Enabled...................................... 69, 152, 156 and arrays.......................................... 265
Enabling/disabling menu items ............... 205 Exercise 15-1
Encapsulation ........................... 9, 13-14, 293 Using loops........................................... 284
Environ ..................................... 150, 159-160 Exercise 16-1
Environment............................................ 350 Working with JavaBeans....................... 302
Event................................30-31, 34, 120-122 Exercise 19-1
Event handler................................... 129, 131 Creating and implementing anRMI interface
Event handling.................................. 119-120 using VisualAgefor Java..................... 361
Event listener ................................... 126, 129 Exit .......................................................... 280
Event sets................................................. 301 Exit menuitems in applet frames ............. 208
Event-based connections.................. 142, 144 Exit()........................................................ 208
Events listeners ........................................ 126 Exit() method .......................................... 203
Event-to-code connections....................... 144 Expert ............................................... 299-300
Event-to-method connection ................... 144 Export........................................................ 50
Exercise 2-1 Export smartguide ................................... 171
Creating your first applet ........................ 33 Export to a directory smartguide ............. 171
Exercise 3-1 Expressions .............................................. 241
Practice editing ....................................... 63 Extends ...................................................... 44
Exercise 4-1 F
Creating the quiz project ........................ 76
Exercise 5-1 Feature.............................................. 200-201
Using containers ..................................... 93 File........................................................... 218
Exercise 6-1 File dialog ................................................ 218
Working with layouts ........................... 112 Filedialog ............................................. 78, 85
Exercise 7-1 Filereader ................................................. 216
Making basic connections ..................... 135 Filewriter ......................................... 216, 221
Exercise 8-1 Finish......................................................... 50
Adding questions to the QuizApplet ..... 163 Fired events.............................................. 115
Exercise 9-1 Float......................................................... 234
Creating an applet ................................ 178 Flow......................................................... 100
Flow layout ....................................... 100-101
396 Index

Font ........................................................... 69 Import ............................................... 51, 351

Foreground ................................................ 70 Import project dialog................................. 51
Form properties ......................................... 92 Import smartguide..................................... 51
Format ..................................................... 232 Importing ................................................ 294
Frame...................................... 78, 85-86, 206 Increase...................................................... 59
Frame/jframe ............................................. 91 Indexed .................................................... 300
Inherit...................................................... 301
G Inheritance........................... 38, 44, 242, 297
Gamelan .......................................... 302, 312 Initialization/instantiation....................... 236
Generated code ........................................ 308 Input........................................................ 216
Get and set methods ................................ 163 Insert (string, int) .................................... 153
Getcodebase() ........................... 150, 159-160 Installing.................................................. 320
Getdocumentbase()................... 150, 159-160 Instance ....................... 13, 45, 235, 237, 239
Getparameter method.............................. 173 Instance variables....................................... 70
Getparameter(string) ................ 150, 159-160 Instantiates ................................................ 47
Getselectedindex() ................................... 149 Instantiation ........... 38, 45, 47, 236-237, 240
Getselecteditem()..................................... 149 Int............................................................ 234
Getselectedtext() ............................... 147-148 Integrated development environments
Getting started......................................... 310 (ides) ........................................................ 7
Gif ........................................................... 174 Interface............................................ 358-359
Graphical user interfaces (guis).................. 10 Internet.................................................... 311
Green team .................................................. 7 Introspection .................................... 292-293
Grid ......................................................... 100 Itemcount ................................................ 156
Grid layout ....................................... 102-103 Itemlistener.............................................. 130
Gridbag.................................................... 100 Itemstatechanged.......147-149, 152-156, 201
Gridbag layout......................................... 107 Ivatest package........................................... 61
Gui................................................... 231, 352 Ivj .............................................................. 45

H J

Height....................................... 172-173, 175 Japplet features ........................................ 159

Help......................................................... 310 Jar ......................................... 50-51, 295, 302
Hidden ............................................. 299-300 Java applications ...................................... 217
Hidden-state ............................................ 298 Java awt ..................................................... 67
Hierarchical ............................................. 319 Java database connectivity (jdbc) ............. 292
Hierarchy............................................. 44, 47 Java ides ................................................... 176
Horizontal gap......................................... 100 Java naming conventions ......................... 242
Hotjava ........................................................ 7 Java run-time environment........................ 54
Html parameters...................................... 170 Java virtual machine (jvm)........... 9, 176, 178
Hypercard................................................ 106 Java’s remote method interface (rmi) ...... 292
Javabeans .... 55, 115, 288, 292-294, 302, 318
I Javadoc....................................................... 43
Jbuilder .................................................... 314
Icon.......................................................... 298
Jbutton ................................... 78-79, 86, 152
Icons and menus...................................... 204
Jcheckbox................................................. 152
Implements........................................... 43-44
Jcombobox.................................... 78-79, 156
 Index 397

Jcomponent ............................................. 151 Length ..................................................... 283

Jdbc.......................................... 292, 329, 353 Libraries................................................... 290
Jdbc-odbc bridge...................................... 320 License agreement ..................................... 22
Jdialog................................................ 78, 160 Life cycle.................................................... 47
Jdk ................................... 7-8, 10, 33, 55, 78, Light weight components .......................... 86
170, 292, 311, 314, 320 Linewrap.................................................. 153
Jdk 1.0 ................................................. 7, 177 List............................................... 68, 74, 148
Jdk 1.1 ..................................................... 177 List components ........................................ 74
Jdk 1.1, ........................................................ 8 List or choice items.................................... 75
Jdk 1.2 ............................................. 176, 178 Listeners .................................................. 301
Jdk 1.2.2, java 2 ........................................... 8 Loadfile............................................. 222-223
Jdk 1.3 ......................................................... 8 Loadfile methods ..................................... 219
Jfilechooser ................................................ 78 Loading......................................... 48-49, 217
Jframe .......................................... 78, 86, 160 Local ................................................ 235, 237
Jlabel ................................................ 151, 157 Logical ..................................................... 309
Jlist .......................................................... 154 Long ........................................................ 234
Jpanel........................................... 78, 86, 151 Loops ....................................................... 283
Jpasswordfield.......................................... 158
Jpeg.......................................................... 174 M
Jradiobutton ............................................ 155 Machine code ............................................ 40
Jscrollbar.................................................. 158 Managers ................................................. 114
Jscrollpane ................................... 79, 86, 151 Maximum ................................................ 156
Jslider....................................................... 156 Menu ................................................ 199-200
Jtable........................................................ 157 Menu actions ........................................... 204
Jtablecolumn............................................ 157 Menubar .................................. 199, 202, 204
Jtextarea ........................................ 79-80, 153 Menuitem ................................ 199, 201, 204
Jtextfield ....................................... 78-79, 153 Menus.............................................. 199, 207
Jtoolbar .................................................... 154 Menus to ................................................. 202
Jtoolbarbutton ......................................... 154 Menuseparator................................. 199, 202
Jtoolbarseparator ..................................... 155 Method ...11, 14, 16, 26, 29-32, 34, 121-122,
Jtree ......................................................... 155 133, 297, 360
Just-in-time (jit)......................................... 10 Method call........................................ 12, 162
Jvm .......................................................... 357 Method definitions.................................. 161
Jwindow..................................................... 86 Method name .......................................... 161
K Methods in source code ........................... 161
Microsoft ................................................. 291
Keyboard accelerators .............................. 205 Midi......................................................... 174
Keylistener ............................................... 130 Minimum ................................................ 156
Keyword ................................... 43-44, 46, 64 Modal ...................................................... 218
Mode ....................................................... 218
L mode........................................................ 218
Label ........................ 45, 68, 71, 73, 146, 200 Model ....................................... 152, 154-157
Labelled ................................................... 282 Modulus .................................................. 239
Layout managers...................................... 114 Mouselistener .......................................... 130
Layouts ...................................................... 99 Moving .................................................... 111
398 Index

Multiplemode ............................................ 74 Pointers ............................................... 9, 245

Multiplication.......................................... 239 Policy tool................................................ 194
Multi-threaded ...................................... 8, 10 Popupmenu ..................................... 199, 202
Powerbuilder .................................... 291-292
N Preferred .................................................. 299
Name ....................................... 171, 173, 175 Primitive.................................................. 234
Nested containers .................................... 107 Printwriter............................................... 216
Nested layouts ......................................... 107 Privacy modifiers ..................................... 234
Netscape ...................................................... 7 Private ............................................... 46, 235
Network................................................... 319 Project ................................ 20, 24-26, 33, 35
New ......................................................... 237 Promote................................................... 298
Null ......................................................... 297 Properties ....14-15, 20, 28-30, 124, 292, 297
Property.................... 27-30, 33, 35, 200, 239
O Property feature....................................... 143
Property window ............................ 28-30, 35
Oak .............................................................. 7
Property-to-property connections .... 142-143
Object ........................................ 15, 175, 177
Protected ................................................. 235
Object-oriented ........................................... 9
Public .......................................... 43, 64, 235
Odbc........................................................ 320
Purge ......................................................... 52
Online help.............................................. 311
Open methods ......................................... 223 Q
Ordering a window to close..................... 207
Orientation .............................................. 158 Quick start................................................. 23
Output..................................................... 216 Quizapplet ............................................... 239

P R

Package ........................................... 24-25, 33 Record ............................................. 241, 319

Palette...................................................... 296 Reference ................................................. 310
Panel ....................................... 78, 85-86, 146 Register............................................ 115, 134
Param tag................................................. 173 Register an event listener......................... 130
Parameter ...................... 31, 34, 46, 121-123, Relational ................................................ 319
133, 161, 233 Relaxed security ....................................... 187
Parameter connection ...................... 126, 142 Relaxing client-side security
Parameter connections............................. 145 signed applets ....................................... 186
Parent ........................................................ 44 Relaxing server-side security
Parentheses (for organizing operations)... 239 servlets .................................................. 186
Passed-by-reference.................................. 243 Remote method ....................................... 356
Passed-by-value........................................ 243 Remote method invocation (rmi ............. 357
Paste ........................................................ 111 Remotehost.............................................. 361
Pasting ..................................................... 110 Remove(int) remove(string)..................... 149
Persistence ........................................ 292-293 Remove(string) ........................................ 148
Person........................................................ 13 Repository ................................ 48-52, 57, 60
Platform independence............................ 290 Repository explorer.................................... 52
Platform-independent ............................. 7, 9 Repository smartguide............................... 51
Pme paradigm ........................................... 15 Resizable .................................................... 92
Restore menu............................................. 52
 Index 399

Return...................................................... 233 Shortcut ............................................. 59, 200

Return type.............................................. 161 Show() .............................. 150, 159-160, 206
Rmi................... 292, 356-357, 359, 361, 364 Showgrid ................................................. 157
Rmic ........................................................ 358 Simplicity ................................................ 290
Robust ......................................................... 9 Sizewidthtofit()........................................ 157
Rows .................................................. 74, 153 Sizing ......................................................... 99
Run.................................. 21, 27, 32, 34, 184 Skeleton ............................ 356-359, 361, 365
Smartguide ................. 24-25, 48, 51, 57, 295
S Source ......................30-31, 33, 121-123, 134
Save bean ................................................. 247 Source code..........................39-44, 46-47, 63
Savefile.............................................. 222-223 Source code works ..................................... 39
Savefile methods ...................................... 219 Source features......................................... 141
Saving ...................................................... 217 Sql.................................................... 292, 319
Scope ................................................ 234-235 Sqlj........................................................... 350
Scripted languages ..................................... 10 Standardized connections ........................ 290
Scrollbardisplaypolicy ................................ 90 Start() ....................................... 150, 159-160
Scrollpane ....................... 79, 85-86, 146, 189 State................................................... 73, 201
Scrollposition............................................. 90 Stop()........................................ 150, 159-160
Secure .......................................................... 9 Stored ...................................................... 184
Select(int) ................................................ 148 Streams ............................. 216-217, 221, 227
Select(int, int) .......................................... 148 String....................................................... 240
Select(string) select(int) ........................... 149 String arithmetic...................................... 241
Selectall() .......................................... 147-148 Stub .......................... 300, 358-359, 361, 365
Selected............................................ 152, 154 Subclass ..................................................... 44
Selectedcheckbox ..................................... 149 Subtraction .............................................. 239
Selectedcolumn........................................ 157 Sun’s java servlet development kit (jsdk .... 54
Selectedindex ................................... 154, 156 Superclass .................................................. 44
Selectedindex selectedindexes .................. 148 Swing........................................... 67, 78, 297
Selecteditem............................................. 156 Swing components ............................ 78, 151
Selecteditem selecteditems....................... 148 Swing containers........................................ 86
Selectedrow.............................................. 157 Swing vs. awt ............................................. 80
Selectedtext.............................. 153, 155, 158 Syntactical ............................................... 309
Selectedvalue............................................ 154 Syntax ...................................... 39, 41, 43, 63
Selectionend .............................................. 72 T
Selectionstart ............................................. 72
Serializable....................................... 297, 359 Target ......................................... 31, 121-123
Serialized.................................................. 359 Target features......................................... 141
Server................................................ 358-359 Tasks........................................................ 310
Server-side security .......................... 183, 185 Test connection ....................................... 353
Servlet .......................................... 17, 54, 186 Text ........................71-72, 152-155, 157-158
Set of braces............................................... 41 Text files.................................................. 224
Seticon() .................................................. 128 Textarea................................. 68, 72, 79, 148
Setup.......................................................... 21 Textbooks ................................................ 313
Setvalueat( int, int) .................................. 157 Textfield ................................ 68, 71, 79, 147
Short ........................................................ 234 Textlistener.............................................. 130
400 Index

Textvaluechanged ............................. 147-148 Workbench ........................ 23-26, 45, 48, 52,

The java language ............................ 176, 178 54, 63, 75-77, 111, 225, 239, 297, 307-308
Title ........................................................... 92 Workbench window ........... 23-24, 26, 28, 33
Tool palette ............................................... 27
Translator ................................................ 350 Z
Trigger event ................................... 124, 134 Zip ............................................................. 51
Tutorial ................................................... 311
Type ........................................................ 234
Typemismatchederror ............................. 242
Types ....................................................... 234
V
Value................................................ 156, 173
Variable assignment................................. 239
Version ................................................ 48, 50
Versioned................................................... 52
Vertical gap.............................................. 100
Visible........................................................ 70
Visual age for Java...................................... 21
Visual Basic.............................................. 291
Visual Beans .................................... 115, 297
Visual Cafée ............................................. 314
Visual Model .................................. 39-40, 48
Visual Programming.................................. 10
Visualage...288, 291, 294-298, 300, 302-303,
314
Visually connect objects........................... 123
Void ......................................................... 233
W
Web .......................... 170-172, 176, 179, 311
Web browser.................................... 170, 176
Width ....................................... 172-173, 175
Window................................................ 85-86
Window features....................... 150, 159-160
Window/jwindow...................................... 91
Windowactivated...................... 150, 159-160
Windowclosed .......................... 150, 159-160
Windowclosing................. 150, 159-160, 207
Windowclosing() ..................................... 131
Windowdeactivated .................. 150, 159-160
Windowopened ........................ 150, 159-160
Windows ................................................. 291
Wizard ............................................... 22, 314