\PassOptionsToPackage{unicode=true}{hyperref} % options for packages loaded elsewhere
\PassOptionsToPackage{hyphens}{url}
%
\documentclass[]{article}
\usepackage{lmodern}
\usepackage{amssymb,amsmath}
\usepackage{ifxetex,ifluatex}
\usepackage{fixltx2e} % provides \textsubscript
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
  \usepackage[T1]{fontenc}
  \usepackage[utf8]{inputenc}
  \usepackage{textcomp} % provides euro and other symbols
\else % if luatex or xelatex
  \usepackage{unicode-math}
  \defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase}
\fi
% use upquote if available, for straight quotes in verbatim environments
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
% use microtype if available
\IfFileExists{microtype.sty}{%
\usepackage[]{microtype}
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
}{}
\IfFileExists{parskip.sty}{%
\usepackage{parskip}
}{% else
\setlength{\parindent}{0pt}
\setlength{\parskip}{6pt plus 2pt minus 1pt}
}
\usepackage{hyperref}
\hypersetup{
            pdftitle={CSci 658: Software Language Engineering Object Oriented Software Development},
            pdfauthor={H. Conrad Cunningham},
            pdfborder={0 0 0},
            breaklinks=true}
\urlstyle{same}  % don't use monospace font for urls
\setlength{\emergencystretch}{3em}  % prevent overfull lines
\providecommand{\tightlist}{%
  \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
\setcounter{secnumdepth}{0}
% Redefines (sub)paragraphs to behave more like sections
\ifx\paragraph\undefined\else
\let\oldparagraph\paragraph
\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}}
\fi
\ifx\subparagraph\undefined\else
\let\oldsubparagraph\subparagraph
\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}}
\fi

% set default figure placement to htbp
\makeatletter
\def\fps@figure{htbp}
\makeatother

\usepackage{caption}
\DeclareCaptionLabelFormat{nolabel}{}
\captionsetup{labelformat=nolabel}

\title{CSci 658: Software Language Engineering\\
Object Oriented Software Development}
\author{\textbf{H. Conrad Cunningham}}
\date{\textbf{26 April 2018}}

\begin{document}
\maketitle

{
\setcounter{tocdepth}{4}
\tableofcontents
}
Copyright (C) 2017, 2018, \href{http://www.cs.olemiss.edu/~hcc}{H.
Conrad Cunningham}\\
Professor of \href{https://www.cs.olemiss.edu}{Computer and Information
Science}\\
\href{http://www.olemiss.edu}{University of Mississippi}\\
211 Weir Hall\\
P.O. Box 1848\\
University, MS 38677\\
(662) 915-5358

\textbf{Advisory}: The HTML version of this document may require use of
a browser that supports the display of MathML. A good choice as of April
2018 is a recent version of Firefox from Mozilla.

\hypertarget{object-oriented-software-development}{%
\section{Object-Oriented Software
Development}\label{object-oriented-software-development}}

\hypertarget{introduction}{%
\subsection{Introduction}\label{introduction}}

TODO: Add

\hypertarget{simplified-software-development-lifecycle}{%
\subsection{Simplified Software Development
Lifecycle}\label{simplified-software-development-lifecycle}}

For the purposes of this discussion, assume that software development
proceeds through the four lifecycle phases shown in the following
diagram.

\begin{verbatim}
    .__________________.
    |                  |
    |     Analysis     |<--:
    |__________________|   |
             |             |
             |             ^
    .________V_________.   |
    |                  |-->:
    |      Design      |   |
    |__________________|<--.
             |             |
             |             ^
    .________V_________.   |
    |                  |-->:
    |  Implementation  |   |
    |__________________|<--:
             |             |
             |             |
    .________V_________.   ^
    |                  |   |
    |   Maintenance    |-->:
    |__________________|
\end{verbatim}

\hypertarget{analysis}{%
\subsubsection{Analysis}\label{analysis}}

In the \emph{analysis} phase we move from a vague description of the
problem to be solved to a precise and unambiguous \emph{requirements
specification}.

The requirements specification might be a precise, but informal
description written in careful natural language text and diagrams.
Alternatively, the specification might be a formal description written
in a mathematically precise language. Or the requirements specification
might be something in between these.

The requirements specification should be:

\begin{itemize}
\tightlist
\item
  complete
\item
  consistent
\item
  readable by application domain experts and software developers
\item
  testable
\item
  independent of programming considerations
\end{itemize}

\hypertarget{design}{%
\subsubsection{Design}\label{design}}

In the \emph{design} phase, we move from a requirements specification to
a \emph{design specification}. The design specification gives the system
structure. The design tasks are to:

\begin{itemize}
\item
  Break the programming task into manageable parts.
\item
  Define the relationships among the parts.
\item
  Incorporate any required or appropriate pre-existing components.
\item
  Keep the design independent of implementation language and hardware
  \emph{details}. (We can, however, use knowledge of high-level
  architectures and language paradigms.)
\end{itemize}

\hypertarget{implementation}{%
\subsubsection{Implementation}\label{implementation}}

In the \emph{implementation} phase, we move from a design specification
to a \emph{tested executable system}. The implementation tasks are to:

\begin{itemize}
\item
  Translate the design into working software on appropriate hardware
\item
  Use the details of the programming language carefully
\end{itemize}

\hypertarget{maintenance}{%
\subsubsection{Maintenance}\label{maintenance}}

In the \emph{maintenance} phase, we move from a complete ``working''
system to a \emph{modified system}. The maintenance tasks are to:

\begin{itemize}
\item
  Repair any \emph{errors} in analysis, design, or implementation that
  have been found
\item
  Adapt to the \emph{changes} in requirements that have occurred
\end{itemize}

We observe the following.

\begin{itemize}
\item
  In successful software systems, the maintenance phase is more
  important than implementation.
\item
  Often more than half of the development effort will occur during
  maintenance.
\end{itemize}

We conclude that we should:

\begin{itemize}
\item
  Do initial analysis, design, and implementation \emph{very carefully}
\item
  \emph{Design for change!}
\end{itemize}

\hypertarget{programming-in-the-small-and-programming-in-the-large}{%
\subsection{``Programming in the Small'' and ``Programming in the
Large''}\label{programming-in-the-small-and-programming-in-the-large}}

The type of software development projects familiar to most students can
be described as \emph{programming in the small}. Such projects have the
following attributes:

\begin{itemize}
\item
  Programs are developed by a single programmer or perhaps a small group
  of programmers.
\item
  All aspects of the project can be understood by a single individual.
\item
  The major problem is the development of the algorithms and data
  structures needed to solve the task at hand.
\end{itemize}

\emph{Programming in the large} characterizes projects with the
following attributes:

\begin{itemize}
\item
  The software system is developed by a large team of programmers, often
  with considerable specialization.
\item
  No single individual can (likely) understand all aspects of the
  project.
\item
  The major problem is the coordination of the diverse aspects of the
  project--people and software systems.
\end{itemize}

The techniques of object-oriented design and programming are useful in
both programming in the small and programming in the large situations.
However, some of the techniques are best appreciated when the
difficulties of programming in the large are understood.

\hypertarget{object-orientation}{%
\subsection{Object Orientation}\label{object-orientation}}

In contemporary practice, most software engineers approach the design of
programs from an object-oriented perspective.

\begin{description}
\tightlist
\item[Key idea (notion?) in object orientation:]
The real world can be accurately described as a collection of objects
that interact.
\end{description}

This approach is based on the following \emph{assumptions}:

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  Describing large, complex systems as interacting objects make them
  \emph{easier to understand} than otherwise.
\item
  The \emph{behaviors} of real world objects tend to be \emph{stable}
  over time.
\item
  The different \emph{kinds} of real world objects tend to be
  \emph{stable}. (That is, new kinds appear slowly; old kinds disappear
  slowly.)
\item
  \emph{Changes} tend to be \emph{localized} to a few objects.
\end{enumerate}

Assumption 1 simplifies analysis, design, and implementation--makes them
more reliable.

Assumptions 2 and 3 support reuse of code, prototyping, and incremental
development.

Assumption 4 supports design for change.

The object-oriented approach:

\begin{itemize}
\item
  Uses the same basic entities (i.e., objects) throughout the lifecycle
\item
  Identifies the basic objects during analysis
\item
  Identifies lower-level objects during design, reusing existing object
  descriptions where appropriate
\item
  Implements the objects as software structures (e.g., Java classes).
\item
  Maintain the object behaviors.
\end{itemize}

\hypertarget{an-object-model}{%
\subsubsection{An Object Model}\label{an-object-model}}

See the sections on the
\href{ProgrammingParadigms.html\#object-oriented}{Object-Oriented} and
the related
\href{ProgrammingParadigms.html\#prototype-based}{Prototype-Based}
paradigms in the \href{ProgrammingParadigms.html}{Programming Paradigms}
notes.

\hypertarget{requirements-analysis}{%
\subsubsection{Requirements Analysis}\label{requirements-analysis}}

The task of the analysis phase is to define the problem and write a
clear, consistent, complete, and precise description of the system to be
constructed. The analysts must elicit the requirements for the system
from the clients and communicate the requirements to the system
designers, who have the task of designing the new system.

The analysts must determine the scope of the system: What must the
system accomplish? And, perhaps just as importantly, what behaviors are
clearly outside the system in its environment?

In approaching the requirements analysis for a new system, the analysts
should do the following.

\begin{itemize}
\item
  Read \emph{all} existing documents that potentially describe the
  requirements for the new system.

  This includes all documents that directly address the requirements as
  well as documents that may indirectly address them. The indirect
  sources include such items as memos, meeting minutes, problem reports
  from the (manual or automated) system being replaced, and employee,
  supplier, or customer complaints and suggestions. The indirect sources
  might also include information about how recent or expected future
  changes in the business, regulatory, social, or technological
  environment may impact the requirements for the system.
\item
  Examine system outputs carefully.

  This includes the outputs (e.g., reports) generated in the current
  system and the descriptions of outputs desired from the new system.
\item
  Interview users.

  The analysts should talk to a wide range of experienced users of the
  current system and its outputs and take careful notes. The experienced
  users are the ones who know how the system is ``really'' being used in
  practice -- what its strengths and weaknesses are, what works well and
  what must be worked around, who uses what aspect of the system or its
  outputs, etc.

  The users of the system may have many different relationships to the
  system and, hence, will likely have different perspectives on how it
  works. The users might include a wide range of employees of the
  organization (clerical personnel, computer operators, managers,
  technical professionals, factory workers, salespersons, etc.) and
  might also include customers or suppliers to the client organization.
\item
  Examine documentation of the current system.

  The analysts should review the official documentation on the current
  system (whether automated or manual) as well as any unofficial or
  personal notes users or maintainers of the system have.
\end{itemize}

Good analysts are good detectives! Among the mass of detail, the
analysts must find the clues that allow them to solve the mystery of
what system the client needs. It is important that analysts keep a
complete record of the information they have gathered and their
reasoning on any ``conclusions'' they reach about that information.

The result of the analysts' work is a document called the
\emph{requirements specification}. Typically this will be a natural
language (e.g., English) document. The writers of this document should
use great care, using the language in a clear, consistent, and precise
manner. The writers are establishing the vocabulary for communication
with the clients and among the designers, implementers, and testers of
the system.

Note: The accompanying slide set \href{UsingCRC.html}{Using CRC Cards}
discusses the processes of object-oriented requirements (this
subsection) and design (next subsection) using methods built around
Class-Responsibility-Collaboration (CRC) cards.

\hypertarget{object-oriented-design}{%
\subsubsection{Object-Oriented Design}\label{object-oriented-design}}

The goals of the design phase are to:

\begin{itemize}
\item
  Identify the \emph{classes}.

  What kinds of objects do we have?
\item
  Identify the \emph{responsibilities} (i.e., functionality) of each
  class.

  What does each kind of object do? What information does it hold?
\item
  Identify the \emph{collaborations} of each class (i.e., the
  relationships among the classes).

  Does one kind of object use another in some way? Is it a special case
  of another kind?
\end{itemize}

The actual design process is iterative. Elaboration of a class may lead
to identification of additional classes or changes to those already
identified.

Classes should be \emph{crisply} defined. It should be as easy as
possible to determine what class an object belongs in. Coming up with a
good categorization is often difficult in complex situations.

The responsibilities of a class are of two types:

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  to carry out some action -- that is, an \emph{operation}.
\item
  to hold some key information -- that is, an \emph{attribut}e (part of
  the state).
\end{enumerate}

Responsibilities should be defined precisely. Ambiguity and imprecision
will likely cause problems later in the design and implementation.

The collaboration relationships among classes should not be excessively
complex. A collaboration between two classes means that one class
depends upon the other in some way. A change in one class may
necessitate a change in the other.

The information gathered in the design phase is the basis for the
implementation. A good design makes the implementation easier and faster
and the resulting product more reliable.

The basic methods for identifying classes and responsibilities are as
follows.

\begin{itemize}
\item
  \begin{description}
  \tightlist
  \item[\emph{To find objects and their classes}:]
  Begin with the \emph{nouns} in the requirements specification.
  \end{description}
\item
  \begin{description}
  \tightlist
  \item[\emph{To find responsibilities}:]
  Begin with the \emph{verbs} in the requirements specification.
  \end{description}
\end{itemize}

\hypertarget{finding-classes-and-responsibilities}{%
\paragraph{Finding Classes and
Responsibilities}\label{finding-classes-and-responsibilities}}

\begin{description}
\item[As an example, consider the following telephone book example:]
\emph{You are to build an automated telephone book system for a
university. The telephone book should contain entries for each person in
the university community--student, professor, and staff member. Users of
the directory can look up entries. In addition, the administrator of the
telephone book can, after supplying a password, insert new entries,
delete existing entries, modify existing entries, print the telephone
book to a printer, and print a listing of all students or of all
faculty. The entries in a listing are to be arranged in alphabetical
order by family name.}
\end{description}

To develop an object-oriented design model for this application, as
designers we can carry out the following steps:

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  \textbf{Identify the candidate \emph{classes}.}

  Begin by listing the nouns, noun phrases, and pronoun antecedents from
  the requirements specification, changing all the plurals to singular.

  \begin{description}
  \item[In the telephone book example, these include:]
  \emph{you (the designer), automated telephone book system, university,
  telephone book, entry, person, university community, student,
  professor, staff member, employee, user, directory, administrator,
  password, printer, listing, faculty, alphabetical order, family name}
  \end{description}

  Other classes may be be implicit in the specification or may emerge as
  the design of individual classes proceed and the designer's knowledge
  of the application domain increases. For example, the design may need
  classes corresponding to:

  \begin{itemize}
  \item
    the ``subjects'' (i.e., actors) of passive voice sentences. To find
    these, a designer may need to restate the passive sentence as an
    equivalent active sentence.
  \item
    parts of items named. For example, the \emph{name}, \emph{address},
    and \emph{telephone number} fields of the \emph{entries} are not
    explicitly mentioned, but they are implicit in what is commonly
    meant by telephone book entries.
  \item
    known interfaces to the environment of the system. For example, user
    interface entities such as a \emph{menu} are implied by the need for
    some way for a user to interact with the application.
  \item
    data structures for storing the \emph{collection} of personal
    entries that make up the telephone book.
  \end{itemize}

  Several, but not necessarily all, of these will become classes in our
  design.
\item
  \textbf{Identify the candidate \emph{responsibilities}.}

  Begin by listing the verbs from the specification. Listing the objects
  of transitive verbs may also be helpful.

  \begin{description}
  \item[In the telephone book example, these include:]
  \emph{build, contain (entry), look (up entry), supply (password),
  insert (new entry), delete (existing entry), modify (existing entry,
  print (telephone book), print (all students), print (all employees),
  set (telephone number field), get (telephone number field), compare
  (entries), to be arranged}
  \end{description}

  \textbf{Transitive verbs} become operations that respond to inputs to
  the object. All of the above verbs except ``to be arranged'' are
  transitive and, hence, will likely give rise to operations.

  \textbf{Intransitive verbs} typically specify attributes of classes.
  For example, ``to be arranged in alphabetical order'' in the above
  example denotes an ordering property of the entries in a listing. It
  is not an operation. Of course, in some cases, this kind of attribute
  might require a ``sort'' operation.
\item
  \textbf{Eliminate classes and responsibilities that are outside of the
  system scope.}

  At this point, we may want to narrow the list of candidate classes by
  quickly dividing them into three categories based on their relevance
  to the system scope:

  \begin{enumerate}
  \def\labelenumii{\alph{enumii}.}
  \item
    \textbf{critical classes} (i.e., the ``winners''), which we will
    definitely continue to consider. These are items that directly
    relate to the main entities of the application.

    In the telephone book example, these might include \emph{telephone
    book, entry, student, faculty, staff member}, and so forth.
  \item
    \textbf{irrelevant candidates} (i.e., the ``losers''), which we will
    definitely eliminate at this point. These are items that are clearly
    outside the system scope.

    In the telephone book example, these might include \emph{university}
    which we do not need to explicitly model in this application) and
    \emph{printer} (which is handled by other software/hardware outside
    of this application).
  \item
    \textbf{undecided candidates} (i.e., the ``maybes''), which we will
    review further for categorization. These are items that we may not
    be able to categorize without first clarifying the system boundaries
    and definition

    In the telephone book example, these might include the
    \emph{automated telephone book system}, an item that definitely will
    be built (it is the whole system) but for which we may not need an
    explicit class.
  \end{enumerate}
\item
  \textbf{Combine synonym classes and synonym operations into single
  abstractions.}

  For example, \emph{automated telephone book}, \emph{telephone book},
  and \emph{directory} can be combined into a single \texttt{PhoneBook}
  class.

  Similarly, \emph{entry} and \emph{person} can be combined into a
  single \texttt{Person} class.

  In addition, all the \texttt{print} operations probably could be
  combined into a single \texttt{print} operation with the differing
  functionalities specified by the parameter.
\item
  \textbf{Distinguish attributes from classes.}

  Some candidate classes may turn out to represent information held by
  other classes instead of being classes themselves.

  A candidate class may be an attribute (i.e., a responsibility) of
  another class rather than itself a class if:

  \begin{itemize}
  \item
    it does not do anything -- i.e., it has no operations.
  \item
    it cannot change state.
  \end{itemize}

  For example, we might choose to make the entity \emph{name} an
  immutable string and make it an attribute of a class \texttt{Person}
  rather than have it a separate class.
\item
  \textbf{Be wary of adjectives.}

  Adjectives modify nouns. In our technique, nouns give rise to classes
  or objects.

  \begin{itemize}
  \item
    An adjective might be \emph{superfluous} as far as our object
    analysis is concerned. For example, the adjective ``automated'' in
    ``automated telephone book'' adds no extra information to
    ``telephone book'' because the adjective was implicit in the context
    of the specification anyway.
  \item
    An adjective may signal the need for an \emph{attribute} of the
    associated class. For example, the phrase ``red truck'' might imply
    the need for a color attribute of a \texttt{Truck} class--unless, of
    course, only one color of truck is needed in the application.
  \item
    An adjective may signal the need for a \emph{subclass}. For example,
    the phrase ``fire truck'' would likely call for a subclass
    \texttt{FireTruck} of class \texttt{Truck} if other kinds of trucks
    are needed in the application. A ``fire truck'' has several
    behaviors and attributes that differ from the generic concept of a
    ``truck''.
  \item
    An adjective might just indicate the need for an \emph{instance} of
    a class. For example, in a context where there is exactly one ``red
    truck'' and where ``red'' trucks need no different behaviors than
    any other trucks, it is sufficient for the ``red truck'' to simply
    be an instance of class \texttt{Truck}.
  \end{itemize}

  \emph{Prepositional phrases} may modify nouns in the requirements
  specification. Such phrases may lead to subclasses, objects, or
  instances as described above for adjectives.

  \emph{Adverbs} may modify adjectives in the requirements
  specification. They provide other information about the adjective that
  should be considered in the analysis. For example, a reference to a
  ``brilliantly red truck'' might signal the need for another attribute,
  subclass, or instance that is different from a plain ``red truck'' or
  from a ``dull red truck''.
\item
  \textbf{Consider architectural design issues.}

  \begin{itemize}
  \item
    \textbf{Identify \emph{hot spots}.} Structure classes and
    collaborations accordingly.

    A hot spot is a portion of the system that is likely to change from
    one system variant to another.

    To readily support change, encapsulate the variable aspects within
    components and design the interfaces of and the relationships among
    system components so that change to the architecture is seldom
    necessary.

    This technique enables convenient reuse of the relatively static,
    overall system architecture and common code. It makes change easier
    to implement at hot spots.

    In the telephone book example, we might consider aspects of the
    application that likely will need to change over time to meet the
    needs of the identified client. The hot spots identified might be
    how the telephone book information is stored, how the printed
    listings are formatted, what the user interface looks like, what
    exact information is stored in entries, what kinds of computing
    platforms the application executes on, what types of printers are
    used, etc. The detailed design decisions relative to these issues
    should be encapsulated within single components and documented well.

    Sometimes we need to approach the design of an application as the
    design of a whole \emph{product line} rather than the design of a
    single product.

    For example, we might consider what might change if we needed to
    modify the application to handle the needs of other organizations.
    In the telephone book example, what would need to change if we
    wanted to make it useful to other universities? to government
    agencies? to private nonprofit service agencies? to businesses? to
    institutions in other countries (i.e., internationalization)?
    Clearly, the categorization of student, staff, and professor would
    need to be flexible. The handling of the name and address data and
    of other aspects of the \texttt{Person} entries would need to be
    flexible.

    Similarly, we can consider what might need to change if we wanted to
    expand the application from just maintaining telephone book
    information to other types of membership applications. Can we
    separate the application-specific behaviors from more general
    behaviors? Can we make it so that it is easy to design new specific
    behaviors and plug them in to the overall application structure?
  \item
    \textbf{Use appropriate \emph{design patterns} to guide structuring
    of the system.}

    A \href{Patterns.html}{design pattern} is a design structure that
    has been successfully used in a similar context--i.e., a reusable
    design.

    Design patterns may be distillations of the development
    organization's experience -- or may be well-known general patterns
    selected from a catalog such as \emph{Design Patterns: Elements of
    Reusable Object-Oriented Software} by the ``Gang of Four'' {[}Gamma
    1995{]}.

    The use of the design pattern may require the addition of new
    classes to the design or the modification of core classes.

    An example of a high-level pattern is the \href{Pipes.html}{Pipes
    and Filters} pattern. In Unix for instance, a filter is a program
    that reads a stream of bytes from its standard input and writes a
    transformed stream to its standard output. These programs can be
    chained together with the output of one filter becoming the input of
    the next filter in the sequence via the pipe mechanism. Larger
    systems can thus be constructed from simple components that
    otherwise operate independently of one another.

    An example of a lower level pattern is the Iterator. This pattern
    defines general mechanisms for stepping through container data
    structures element by element. For instance, a Java object that
    implements the \texttt{Enumeration} interface is returned by the
    \texttt{elements()} of a \texttt{Vector} object; successive calls of
    the \texttt{nextElement()} method of the \texttt{Enumeration} object
    returns successive elements of the \texttt{Vector} object.
  \item
    \textbf{Take advantage of existing software \emph{frameworks}.}

    A framework is a collection of classes--some abstract, some
    concrete--that captures the architecture and basic operation of an
    application system. Systems are created by extending the given
    classes to add the specialized behaviors.

    Frameworks are ``upside down libraries'' -- system control resides
    in framework code that calls ``down'' to user-supplied code.

    Examples of software frameworks include graphical user interface
    toolkits like the Java AWT and some discrete event simulation
    packages.

    To fit an application into a framework may require addition or
    modification of core classes.
  \end{itemize}
\item
  \textbf{Associate the operations with the appropriate classes.}

  For example, in the telephone book example associate \texttt{lookup},
  \texttt{insert}, \texttt{delete}, and \texttt{modify} entry operations
  with the \texttt{PhoneBook} class, associate \texttt{compare},
  \texttt{setPhoneNumber} and \texttt{getPhoneNumber} with the
  \texttt{Person} class, etc.

  Sometimes there might be a choice on where to associate an operation.
  For example, the ``insert person into telephone book'' operation could
  be a operation of \texttt{Person} (that is, insert \emph{this} person
  into the argument telephone book) or a operation of \texttt{PhoneBook}
  (that is, insert the argument person in \emph{this} telephone book).

  Which is better? Associating the operation with \texttt{Person} would
  require the \texttt{Person} class to have access to the internal
  representation details of the \texttt{PhoneBook}. However, associating
  the operation with \texttt{PhoneBook} would not require the
  \texttt{PhoneBook} to know about the internal details of the
  \texttt{Person} class--except to be able to \texttt{compare} two
  entries. Thus making \texttt{insert} an operation of
  \texttt{PhoneBook} and \texttt{compare} an operation of
  \texttt{Person} would best maintain the encapsulation of data.
\end{enumerate}

\begin{description}
\tightlist
\item[\textbf{Principle:}]
\emph{An object cannot manipulate the internal data of another object
directly; it must use an operation of that object.}
\end{description}

During design we should not be concerned with the minute details of the
implementation. However, it is appropriate to consider whether there is
a ``reasonable'' implementation. In fact, it is better to make sure
there are two different possible implementations to ensure flexibility
and adaptability.

It is good to have more than one person involved in a design. A second
designer can review the first's work more objectively and ask difficult
questions -- and vice versa.

\hypertarget{coming-up-with-names}{%
\paragraph{Coming Up with Names}\label{coming-up-with-names}}

The selection of names for classes and operations is an important task.
Give it sufficient time and thought.

\begin{itemize}
\item
  Names of classes should be singular nouns. In Java and Scala, these
  names should normally begin with an uppercase letter.
\item
  Names of responsibilities (operations) should be verbs or short
  sequences of words containing one verb. In Java and Scala, these names
  should normally begin with a lowercase letter.
\item
  Names of booleans should indicate meaning of the \emph{true} value.
\item
  Names should be easily recognized and understood by domain experts.
\item
  Names should be short.
\item
  Names should be pronounceable (read them out loud).
\item
  Names should be consistent within the project (perhaps the entire
  development organization).
\item
  Names should be unambiguous, not having multiple interpretations. Use
  abbreviations with care.
\item
  Names should use capitalization and underscores, but avoid digits.
\end{itemize}

\hypertarget{finding-relationships-among-classes}{%
\paragraph{Finding Relationships Among
Classes}\label{finding-relationships-among-classes}}

Two classes in a design may be related in one of several ways. The three
relationships that are common are:

\begin{itemize}
\item
  \emph{use} or awareness (\emph{uses})
\item
  \emph{aggregation} (\emph{has-a}) -- sometimes called containment or
  composition
\item
  \emph{inheritance} (\emph{is-a}) -- sometimes called generalization,
  extension, or specialization
\end{itemize}

\hypertarget{use-relationship}{%
\subparagraph{Use Relationship}\label{use-relationship}}

Class A \emph{uses} B when:

\begin{itemize}
\item
  an operation of A receives/returns an object of B
\item
  an operation of A must examine or create an object of B
\item
  an object of A ``contains'' objects of B (as instance variables)
\end{itemize}

If objects of A can carry out all operations without any awareness of B,
then A \emph{does not use} B.

From the telephone book example, \texttt{PhoneBook} uses \texttt{Person}
objects (that is, it inserts, deletes, modifies, etc., the entries).
\texttt{Person} objects do not use \texttt{PhoneBook} objects.

If class A uses class B, then a change to class B (particularly to its
public interface) may necessitate changes to class A. The following
principle will make modification of a design and implementation easier.

\begin{description}
\tightlist
\item[Principle:]
\emph{Minimize the coupling between classes} (that is, the number of
classes used by a class.)
\end{description}

\hypertarget{aggregation-relationship}{%
\subparagraph{Aggregation Relationship}\label{aggregation-relationship}}

Class A uses class B for \emph{aggregation} if objects of A contain
objects of B.

Note: Object A \emph{contains} (\emph{has an}) object B if A has an
\emph{instance variable} that somehow designates object B--a Java
reference to B, the index of B, the key of B, etc.

Aggregation is a one-to-N relationship; one object might contain several
others.

Note: Aggregation is a special case of the use relationship. If asked to
identify the aggregation and use relationships, identify an aggregation
relationship as such rather than as a use relationship.

For example, objects of the \texttt{Person} class in the telephone book
example contain (\emph{has}) \texttt{name}, \texttt{address}, and
\texttt{phoneNumber} objects.

The Pascal \texttt{record} and C \texttt{structure} are aggregations;
they contain other data fields. They are not, however, objects.

\hypertarget{inheritance-relationship}{%
\subparagraph{Inheritance Relationship}\label{inheritance-relationship}}

Class D \emph{inherits from} class B if all objects of D are also
objects of B.

As noted previously,

\begin{itemize}
\tightlist
\item
  all B operations must be valid for D objects (perhaps implemented
  differently),
\item
  D objects can have additional operations and data fields.
\end{itemize}

In the telephone book example, we design \texttt{Professor} to inherit
from \texttt{Employee}; similarly, we design \texttt{Staff} to inherit
from \texttt{Employee}. We make \texttt{Employee} itself inherit from
\texttt{Person}; similarly, we design \texttt{Student} to inherit from
\texttt{Person}.

Inheritance can lead to powerful and extensible designs. However, use
and aggregation are more common than inheritance.

\hypertarget{object-oriented-implementation}{%
\subsubsection{Object-Oriented
Implementation}\label{object-oriented-implementation}}

The outputs of the object-oriented design phase include:

\begin{itemize}
\item
  descriptions of each class
\item
  descriptions of each operation (i.e., method)
\item
  diagrams giving relationships among the classes
\end{itemize}

The purpose of the implementation phase is to code, test, and integrate
the classes into the desired application system.

Object-oriented development involves an integration of testing with
implementation:

\begin{itemize}
\item
  Implement and test each class or cluster of closely related classes
  separately.
\item
  Once each cluster is working correctly, integrate it into the program.
\item
  Perhaps defer some operations until later--build a prototype rapidly
  to explore requirements.
\item
  If done carefully, incrementally evolve the prototype into a fully
  functional system.
\end{itemize}

Note: If we seek to evolve a prototype into a full program, we should
never hesitate to reopen the analysis or design if new insight is
discovered.

\hypertarget{conclusions}{%
\subsection{Conclusions}\label{conclusions}}

TODO: Add

\hypertarget{exercises}{%
\subsection{Exercises}\label{exercises}}

TODO: Add

\hypertarget{acknowledgements}{%
\subsection{Acknowledgements}\label{acknowledgements}}

In Fall 2016 and Spring 2017, I adapted these lecture notes from my
previous notes on this topic. The material from my previous notes is
based, in part, on the presentations in the following books:

\begin{itemize}
\item
  David Bellin and Susan Suchman Simone. \emph{The CRC Card Book},
  Addison Wesley, 1997.
\item
  Timothy Budd. \emph{Understanding Object-Oriented Programming with
  Java}, Updated Edition, Addison Wesley, 2000.
\item
  Paul A. Fishwick. \emph{Simulation Model Design and Execution:
  Building Digital Worlds}, Addison Wesley, 1995.
\item
  Cay S. Horstmann. \emph{Mastering Object-Oriented Design in C++},
  Wiley, New York, 1995.
\item
  Pete Thomas and Ray Weedom. \emph{Object-Oriented Programming in
  Eiffel}, Addison-Wesley, Workingham, UK, 1995.
\item
  Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener.
  \emph{Designing Object-Oriented Software}, Prentice-Hall, 1990.
\end{itemize}

I wrote the first version of these notes in Spring 1996 for my CSci 490
Special Topics course on object-oriented design and programming using
C++. I expanded the notes for the first Java-based version of CSci 211
(then titled File Systems) during Fall 1996.

I revised the notes incrementally over the next decade for use in my
Java-based courses on object-orientation, software architecture, and
computer simulation.

I partially revised the notes for use in my Scala-based classes
beginning in Fall 2008 and Lua-based classes beginning in Fall 2013.

For the CSci 450 Programming Languages class in Fall 2016, I moved the
discussion of the Object Model from the OO notes and combined it with
the discussion of programming paradigms from my Functional Programming
notes as part of a new introductory document for that course. (See the
notes on the
\href{http://www.cs.olemiss.edu/~hcc/csci450/notes/HaskellNotes/01Fundamental450.html\#object-oriented}{Object-Oriented
programming paradigm} in Chapter 1 of that document.) However, for
Spring 2018, I separated the discussion of programming paradigms from
the larger chapter into a separate document
\href{ProgrammingParadigms.html}{Programming Paradigms}.

In Summer 2017 and Spring 2018 I reformatted these notes to use Pandoc
Markdown, improved the presentation in a few places, and linked it into
the other documents.

I maintain these notes as text in Pandoc's dialect of Markdown using
embedded LaTeX markup for the mathematical formulas and then translate
the notes to HTML, PDF, and other forms as needed.

\hypertarget{references}{%
\subsection{References}\label{references}}

{[}Bellin 1997{]} : David Bellin and Susan Suchman Simone. \emph{The CRC
Card BookUs}Us, Addison Wesley, 1997.

\begin{description}
\tightlist
\item[{[}Budd 2000{]}]
Timothy Budd. \emph{Understanding Object-Oriented Programming with
Java}, Updated Edition, Addison Wesley, 2000.
\item[{[}Fishwick 1995{]}]
Paul A. Fishwick. \emph{Simulation Model Design and Execution: Building
Digital Worlds}, Addison Wesley, 1995.
\item[{[}Gamma 1995{]}]
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
\emph{Design Patterns: Elements of Reusable Object-Oriented Software},
Addison Wesley, 1995.
\item[{[}Horstmann 1995{]}]
Cay S. Horstmann. \emph{Mastering Object-Oriented Design in C++}, Wiley,
1995. (Chapters 3-6 on ``Implementing Classes'', ``Interfaces'',
``Object-Oriented Design'', and ``Invariants'' especially influenced my
views on object-oriented design and programming.)
\item[{[}Thomas 1995{]}]
Pete Thomas and Ray Weedom. \emph{Object-Oriented Programming in
Eiffel}, Addison-Wesley, Workingham, UK, 1995.
\item[{[}Wirfs-Brock 1990{]}]
Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener. \emph{Designing
Object-Oriented Software}, Prentice-Hall, 1990.
\item[{[}Wirfs-Brock 2003{]}]
Rebecca Wirfs-Brock and Alan McKean. \emph{Object Design: Roles,
Responsibilities, and Collaborations}, Addison-Wesley, 2003.
\end{description}

\hypertarget{concepts}{%
\subsection{Concepts}\label{concepts}}

TODO: Add

\end{document}