
\documentclass[11pt]{article}
\setlength{\textwidth}{5.5in}
%\setlength{\evensidemargin}{-0.5in}
\usepackage{TRmydraft} % title page report
\usepackage{wmff} % algorithm
\usepackage{yprob} % algorithm listing, code, report exercises

\usepackage{graphicx}

\pagestyle{myheadings}
\markright{Object Orientation\hfill}

\begin{document}

\reptitle{\bf Object Orientation}
\author{Dr. Jos\'e M. Garrido}

%\date{February, 2009}

\subtitle{{}}
\subsubtitle{}


\authoraffil{Department of Computer Science} 
 
%
%\halftitlepage
%

\titlepage

\mdraft
%\maketitle
%\newpage
%\tableofcontents
%\newpage

 \section{Modules} 

For complex problems or systems, the general approach is to divide the problem into smaller problems that are easier to solve. The partitioning of a problem into smaller parts is known as {\em decomposition}\index{decomposition}. These small parts are known as modules\index{modules}, which are easier to manage. 

System design usually emphasizes modular structuring, also called modular decomposition. A problem is divided into smaller problems (or subproblems), and a solution is designed for each subproblem\index{subproblem}. Therefore, the solution to a problem consists of several smaller solutions corresponding to each of the subproblems. This approach is called modular design. Object-oriented design enhances modular design by providing classes as the most important decomposition (modular) unit. A program structure is basically organized as an assembly of classes.


\section{Modeling Objects}

{\em Abstraction\/} is used to model the objects in a problem domain. This involves the elimination of unessential characteristics. A model includes only the relevant aspects of the real-world system. Therefore, only the relevant objects and only the essential characteristics of these objects are included in the model. 

Several levels of detail are needed to completely define objects and the collections of objects in a model. The activities in object-oriented modeling are:
\begin{enumerate}
\item
Identifying the relevant objects for the model
\item
Using abstraction to describe these objects

\item
Defining collections of similar objects
\end{enumerate}

An abstract representation is a simplified description and includes only the relevant or essential properties of part of a real system. A model\index{model} is such an abstract representation\index{abstract description} of some part of the problem domain. 

Real-world entities or real-world objects are the fundamental components\index{components} of a real world system. Identifying and modeling real-world entities in the problem domain are the central focus of the object-oriented approach. A real-world entity has the responsibility of carrying out a specific task. Real-world entities\index{entities} identified in the real-world environment are modeled as objects. 

Objects with similar characteristics are grouped into collections\index{collections}, and these are modeled as {\em classes}\index{class}. 

Objects and classes are described in a standard notation, the Unified Modeling Language (UML). This chapter and throughout the book simplified UML diagrams are employed when describing classes and objects. 

\subsection{Defining Classes}

In modeling a real-world problem, collections of similar objects are identified. Classes are then defined as abstract descriptions of these collections\index{collections} of objects, which are objects with the same structure and behavior. A class defines the attributes, and behavior for all the objects of the class.

 Figure~\ref{fig:collections} shows two collections of real-world objects and  the modeling of the classes. 

\begin{figure}[h]
\vspace{.2in}
\centereps{3.5in}{1.368in}{figs/robjects.eps}
\caption{Collections of objects}
\label{fig:collections}
%\vskip\baselineskip
\vspace{0.1in}
\end{figure}

An object belongs to a collection or class, and any object of the class is an {\em instance}\index{instance} of the class. 

A software implementation of class consists of:

\begin{itemize}
\item
  Data declarations that represent the attributes of the class
\item
  Behavior representation as one or more operations (also known as functions and methods)
\end{itemize}

A class is represented graphically in UML as a simplified class diagram. 
The following is an example of a representation of class\index{class} {\em Employee}, in a simplified UML diagram that shows the structure and behavior for all objects of this class. The attributes defined for this class are {\em salary}, {\em emp\_number}, {\em name}, and {\em emp\_date}. Figure~\ref{fig:employee} shows the diagram that describes class {\em Employee}.

\begin{figure}[h]
\vspace{.1in}
\centereps{1.65in}{1.75in}{figs/employee.eps}
\caption{Diagram of class {\em Employee}}
\label{fig:employee}
%\vskip\baselineskip
%\vspace{0.1in}
\end{figure}

Another example of a class is shown next. Figure~\ref{fig:account} shows the diagram that describes class {\em Account}.

\begin{figure}
%\vspace{.1in}
\centereps{2.0in}{1.75in}{figs/account.eps}
\caption{Diagram of class {\em Account}}
\label{fig:account}
%\vskip\baselineskip
%\vspace{0.1in}
\end{figure}




%\vfill

\subsection{Describing Objects}
 
Three basic categories of real-world objects can be identified:

\begin{itemize}
  \item
  Physical objects such as persons, animals, cars, balls, traffic lights, and so on
  \item
  Non-tangible objects such as contracts, accounts, and so on
  \item
  Conceptual objects that are used to represent part of the components or part of the behavior of the problem. 
\end{itemize}

Objects exhibit independent behavior\index{object behavior} and interact with one another. Objects communicate by sending messages to each other. Every object has:
  
\begin{itemize}
\item
State, represented by the set of properties (or attributes) and their associated values
\item
Behavior, represented by the operations, also known as methods, of the object
\item
Identity, which is an implicit or explicit property that can uniquely identify an object.
\end{itemize}

Two objects of class {\em Employee} are shown in Figure~\ref{fig:two_employees}. This is the UML diagram that shows the state \index{object state} of the objects. The diagram is basically a rectangle divided into three sections. The top section indicates the class of the object, the middle section includes the list of the attributes and their current values, and the bottom section includes the list of object operations\index{object operations}. 

\begin{figure}[h]
\vspace{.2in}
\centereps{3.25in}{1.75in}{figs/two_emp.eps}
\caption{Two objects of class {\em Employee}}
\label{fig:two_employees}
%\vskip\baselineskip
\vspace{0.1in}
\end{figure}

The state of an object is defined by the values of its attributes\index{attributes}. The two objects of class {\em Employee} have different states because their attributes have different values.

An object\index{object} of class {\em Account} is shown in Figure~\ref{fig:account}. This object has three attributes, {\em acc\_num\/}, {\em balance}, and {\em transdate}. The object also has and three operations, {\em deposit\/} and {\em withdraw}, and {\em query}. The values of these attributes are also shown. The behavior of this object is dependent on another object that can start any of these operations.

\section{Object Interactions}

Object interaction involves objects sending {\em messages}\index{messages} to each other. The object that sends the message is the requestor of a service that can be provided by the receiver object.

An object sends a message to request a service, which is provided by the object receiving the message. The sender object is known as the {\em client\/} of a service, and the receiver object is known as the {\em supplier\/} of the service. Passive objects perform operations in response to messages. 

An object of class {\em Employee\/} interacts with an object of class {\em Account}, by invoking an operation of the object of class {\em Account}. 

These interactions are object-specific; a message is always sent to a specific object. This is also known as {\em method invocation}\index{method invocation}.  A message normally contains three parts:

\begin{itemize}

\item
The operation to be invoked or started
\item
The input data required by the operation to perform
\item
The result of the operation

\end{itemize}

The standard UML\index{UML} diagram known as the {\em communication diagram}\index{communication diagram} is used to describe the general interaction between two or more objects (the sending of messages between objects). 

Figure~\ref{fig:obj_int} shows a simple communication diagram to describe the interaction between an object of class {\em Employee} with an object of class {\em Account}. In this example, the object of class {\em Employee} invokes the {\em deposit\/} operation of the object of class {\em Account}. The first object sends a message to the second object (of class {\em Account}). As a result of this message, the object of class {\em Account} performs its {\em deposit\/} operation. 

\begin{figure}[h]
\vspace{.2in}
\centereps{3.5in}{1.4in}{figs/obj_int.eps}
\caption{Communication diagram with two objects}
\label{fig:obj_int}
%\vskip\baselineskip
\vspace{0.1in}
\end{figure}

%\vfill

\section{Other Concepts of Object Orientation}

Object orientation provides enhanced modularity in developing software systems. An application is basically a set of well-structured and related {\em modules}\index{modules}. The class is the most basic module of a program, and is the main decomposition unit of a program. In other words, a program is decomposed into a set of classes. The application is organized as an assembly of classes. Figure~\ref{fig:assembly} illustrates the notion of an assembly of classes.

\begin{figure}[h]
\vspace{.2in}
\centereps{3.0in}{1.4in}{figs/softsys.eps}
\caption{An assembly of classes}
\label{fig:assembly}
%\vskip\baselineskip
\vspace{0.1in}
\end{figure}


This is the {\em static view\/} of a program (that implements an application). The {\em dynamic view\/} of the application is a set of objects performing their behavior and interacting among themselves.



\subsection{Encapsulation} 

The encapsulation\index{encapsulation} principle describes an object as the integration of its attributes and behavior in a single unit. There is an imaginary protecting wall surrounding the object. This is considered a protection\index{protection} mechanism. To protect the features of an object, an access mode is specified for every feature. 

The access mode specifies which features of the object can be accessed from other objects. If access to a feature (attribute or operation) is not allowed, the access mode\index{access mode} of the feature is specified to be {\em private}\index{private}. If a feature of an object is {\em public}\index{public}, it is accessible from any other objects. 


\subsection{Information Hiding}

As mentioned previously, an object that provides a set of services to other objects is known as a {\em provider\/} object, and all other objects that request these services by sending messages are known as {\em client\/} objects. An object can be a service provider for some services, and it can also be a client for services that it requests from other (provider) objects. 

The principle of information hiding\index{information hiding} provides the description of a class only to show the services the objects of the class provide to other objects and hiding all implementation details. In this manner, a class description presents two views:

%\newpage

\begin{enumerate}

\item
The {\em external view}\index{external view} of the objects of a class. This view consists of the list of services (or operations) that other objects can invoke. The list of services can be used as a service contract between the provider object and the client objects. 

\item
The {\em internal view}\index{internal view} of the objects of the class. This view describes the implementation details of the data and the operations of the objects in a class. This information is hidden from other objects.

\end{enumerate}

%\newpage


These two views of an object are described at two different levels of abstraction. The external view is at a higher level of abstraction\index{abstraction}. The external view is often known as the {\em class specification}, and the internal view as the {\em class implementation}. 

With the external view, information about an object is limited to that only necessary for the object's features to be invoked by other objects. The rest of the knowledge about the object is not revealed. 

In general, the external view of the objects should be kept separate from the internal view.  The internal view of properties and operations of an object are hidden from other objects.  The object presents its external view to other objects and shows what features (operations and attributes) are accessible.




\end{document}
