
\documentclass[11pt]{article}
%\usepackage{mydraft}

\usepackage{TRmydraft}
\usepackage{wmff}
\usepackage{graphicx}
%\usepackage{graphalgb}

\pagestyle{myheadings}
\markright{}

\begin{document}

\reptitle{{\bf Object Oriented Programming}}
\author{Jos\'e M. Garrido}

\date{December, 2016}

\subtitle{{\bf Using OOSimL}}
\subsubtitle{An Overview - Part 1}
%\subsubtitle{Technical Report TR-CSIS-OOPsimL (Part 2)}

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

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

%\include{ch01} % progs and soft development
\section{Introduction}


The hardware in a computer system is driven and controlled by software\index{software}, which consist of the set of programs that execute in the computer. These  control, manage the hardware, and carry out system and user tasks. 

A program consists of data descriptions and instructions to manipulate this data.
The types of programs that carry out system tasks are known as {\it system programs}\index{system programs} and control the activities and functions of the various hardware components. An example of system programs is the operating system, such as Unix, Windows, MacOS, OS/2, and others.

User programs\index{application programs}, also known as {\it application programs}\index{application programs}, carry out tasks that solve specific problems for the users. These programs execute under control of the system programs. Application programs are developed by individuals and organizations for solving specific problems.

%\newpage

\section{Programming Languages}

A programming language\index{programming language} is a set of syntax and semantic rules for writing programs. It is a formal notation that is used to write the data description and the instructions of a program. The programming language's syntax rules describe how to write sentences. The semantic rules describe the meaning of the sentences. These two types of rules must be consistent. There are several levels of computer programming languages, basically low-level and high-level languages.


\subsection{Assembly Languages}

The symbolic machine languages are also known as assembly languages and are low-level programming languages. In these languages, various mnemonic symbols represent operations and addresses in memory. These languages are hardware dependent; there is a different assembly language for every computer type. Assembly language is still used today for detailed control of hardware devices; it is also used when extremely efficient execution is required.

\subsection{High-Level Programming Languages}

A high-level programming language\index{high-level programming language} provides a programmer the facility to write instructions to the computer in the form of a program. A programming language must be expressive enough to help programmers in  the writing of programs for a large family of problems.

High-level programming languages are hardware independent and more problem-oriented (for a given family of problems). These languages allow more readable programs, and are easier to write and maintain. Examples of these languages are Pascal, C, Cobol, Fortran, Algol, Ada, Smalltalk, C++, Eiffel, and Java. 

Simula was the first object-oriented language developed in the mid-sixties and used to write simulation models. The original language was an extension of Algol. In a similar manner, C++ was developed as an extension to C in the early eighties.

Java was developed by Sun Microsystems in the mid-nineties and has far more capabilities than any other object-oriented programming language to date, unfortunately, it has a relatively low-level syntax.

Languages like C++ and Java can require considerable effort to learn and master. Several newer and experimental, higher-level, object-oriented programming languages have been developed. Each one has a particular goal. One such language is {\em OOSimL}\index{OOSimL} (Object Oriented Simulation Language); its main purpose is to develop simulation models, make it easier to learn object-oriented programming principles, and help students transition to Java.

\subsection{Compiling a Java Program}

A program written in a programming language is compiled or translated to an equivalent program in machine language, which is the only programming language that the computer accepts for processing. 

In addition to {\em compilation}\index{compilation}, another step known as {\em linking}\index{linking} is required before a program can be executed. Programming languages like Java, require compilation and interpretation. This last step involves execution of the compiled program.

Two special programs are needed, the compiler and the interpreter. The Java compiler checks for syntax errors in the source program and translates it into {\em bytecode}\index{bytecode}, which is the program in an intermediate form. The Java bytecode is not dependent on any particular platform or computer system. To execute this bytecode, the Java Virtual Machine (JVM), carries out the interpretation of the bytecode.

\subsection{Compiling OOSimL Programs}

Programs written in OOSimL (an object-oriented language that is higher level than Java), are  compiled with the OOSimL compiler. This is a translator that checks for syntax errors in the language, and translates the program from OOSimL to Java. This compiler is a special program that is freely available from the following Web page:

\begin{quote}
\begin{verbatim}
http://ksuweb.kennesaw.edu/~jgarrido/oosiml.html
\end{verbatim}
\end{quote}



The OOSimL compilation is illustrated in Figure~\ref{fig:oosimltool}. Separate documents describe in further  detail how to use the OOSimL compiler\index{OOSimL compiler}.

\begin{figure}[h]
\vspace{.2in}
\centereps{3.5in}{0.463in}{figs/oosimlcomp.eps}
\caption{OOSimL Compilation to Java}
\label{fig:oosimltool}
%\vskip\baselineskip
\vspace{0.1in}
\end{figure}

\section{Software Development}

The main goal of software development is to solve a given real-world problem. This involves the following general tasks:
\begin{enumerate}
\item
 Understanding and describing the problem in a clear and unambiguous form
\item
 Designing a solution to the problem
\item
 Developing a computer solution to the problem.
\end{enumerate}

\subsection{Software Life Cycle}

A software development process involves carrying out a sequence of activities. These activities represent the life of the software from birth to retirement. In most cases, the development process is also known as the {\em software life cycle}. 

The software life cycle\index{software life cycle} basically consists of the following phases:

\begin{enumerate}
\item
Software development
\item
Operational activities that applies the software in the problem environment

\item
Maintenance activities that report defects in the software and the subsequent fixes and releases of new versions of the software

\item
Software retirement when it can no longer be maintained.

\end{enumerate}
 
The simplest model of the software life cycle  is the {\em waterfall model}\index{waterfall model}. This model represents the sequence of phases or activities to develop the software system through  installation and maintenance of the software. In this model, the activity in a given phase cannot be started until the activity of the previous phase has been completed.

Figure~\ref{fig:waterfall} illustrates the sequence of activities or phases involved in the waterfall model of the software life cycle. 

\begin{figure}[h]
\vspace{.2in}
\centereps{3.0in}{2.714in}{figs/waterfall.png}
\caption{The waterfall model}
\label{fig:waterfall}
%\vskip\baselineskip
\vspace{0.1in}
\end{figure}


The various phases of the software life cycle are the following:


\begin{enumerate}
\item
  Analysis that results in documenting the problem description and  what the problem solution is supposed to accomplish.  
 \item
  Design, which involves describing and documenting the detailed structure and behavior of the system model.
\item
  Implementation of the software using a programming language. 
 \item
  Testing\index{testing} and verification of the programs. 

 \item 
  Installation and maintenance\index{maintenance} that results in delivery, installation and maintenance of the programs. 

\end{enumerate}

In practice, the waterfall model is argued by many to be very inconvenient and difficult to use, mainly because for any non-trivial project, to get one phase of a software product's lifecycle completed and correct before moving on to the next phases. 


There are some variations proposed for the waterfall model of the life cycle. These include returning to the previous phase when necessary. Recent trends in system development have emphasized an iterative approach, in which previous stages can be revised and enhanced.  

A more complete model of software life cycle is the {\em spiral model\/}\index{spiral model} that incorporates the construction of {\em prototypes}\index{prototypes} in the early stages. A prototype is an early version of the application that does not have all the final characteristics. Other development approaches involve prototyping and rapid application development (RAD).


%\include{ch02} % intro to OO

\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.png}
\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.png}
\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.png}
\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.png}
\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.


%\include{ch03} % OO programs

\section{Programs}

An object-oriented program is an implementation of  the classes that were modeled in the  analysis and design phase of the software development process. This is the static view\index{static view} of a program that describes the structure of the program composed of one or more modules\index{modules} known as {\em classes}.

When the program\index{program} executes, objects\index{object} of these classes are created and made to interact among them. This is the dynamic view\index{dynamic view} of a program, which describes the behavior\index{program behavior} of the program while it executes. This behavior consists of the set of {\em objects\/}, each one exhibiting individual behavior and interacting\index{object interaction} with other objects.

\section{Definition of Classes}

A class defines the structure and the behavior of the objects in that class. The software definition of a class consists of:

\begin{itemize}

\item
The attribute declarations of the class

\item
Descriptions of the operations, known as methods or functions of the class

\end{itemize}

\begin{figure}[h]
%\vspace{.2in}
%\centereps{1.5in}{3.062in}{figs/classtruct.png}
\centering
\includegraphics[width=1.5in]{figs/classtruct.eps}
\caption{Structure of a typical class}
\label{fig:class_struct}
%\vskip\baselineskip
%\vspace{0.1in}
\end{figure}


The attributes in a class are defined as data\index{data} declarations declarations\index{declarations} of the class. The behavior\index{object behavior} of the objects of the class is represented by the descriptions of the operations of the class. 

The general structure of a class is shown in Figure~\ref{fig:class_struct} that illustrates the declarations of the attributes and the definitions of three operations: {\em OperationX}, {\em OperationY}, and {\em OperationZ}. Each of these operations\index{operations} consists of local data declarations\index{data declarations} and its instructions.


The smallest modular unit is an operation, also known as a function or method; it carries out a single task. It is not standalone unit because every function belongs to a class; a function is an internal decomposition unit.

\section{Implementation of Programs}

The software implementation of a program is carried out writing the code in a suitable programming language. Detailed design is often written in pseudo-code, which is a high-level notation at the level between the modeling diagrams and the programming language. 

\subsection{Programming Languages}

Programming languages\index{languages} have well-defined syntax and semantic rules. The syntax is defined by a set of grammar rules and a vocabulary (a set of words). The legal sentences are constructed using sentences in the form of {\em statements}\index{statements}. There are two groups of words: {\em reserved words}\index{reserved words} and {\em identifiers}\index{identifiers}. 

Reserved words are the keywords of the language and have a predefined purpose in the language. These are used in most statements with precise meaning, for example, {\bf class}, {\bf inherits}, {\bf variables}, {\bf while}, {\bf if}, and others. 


Identifiers\index{identifiers} are names for variables, constants, functions, and classes that the programmer chooses, for example, {\em emp\_number}, {\em employee\_name}, {\em salary}, {\em emp\_date}, and on.


The main variable declarations in a class are the attributes\index{attributes}. The other data declarations are the ones inside a function and are known as {\em local\/} variable declarations\index{local declarations}. The structure of object-oriented programs includes the following kinds of statements\index{statements}:



\begin{itemize}
 \item
   Class definitions
 \item
   Declaration of data constants
 \item 
   Declaration of simple variables
 \item 
   Declaration of object references
 \item
   Definition of methods or functions
\end{itemize}

Within the body of function definitions, language instructions are included to
create objects and to manipulate the objects created. 

\subsection{Implementing Classes}

A class definition is implemented with a class header and additional statements; these are: 

\begin{enumerate}
\item
The {\bf description} statement, which may be used to include a textual documentation or description of the class. This section ends with a start-slash (*/).

\item
The {\bf class} statement is used for the class header. This includes assigning a name to the class and other information related to the class. 

\item 
The {\bf private} keyword starts the section for the declarations of the private attributes of the class or definitions of the private operations.

\item
The {\bf protected} keyword starts the section for the declaration of protected attributes of the class or definitions of the projected operations.
\item 
The {\bf public} keyword starts section for the declarations of the private attributes or the definition of the public operations of the class. 

\item
The {\bf endclass} statement ends the class definition.

\end{enumerate}

With OOSimL, the general syntactic definition of a class is:

\newpage

\vspace{0.1in}
%\begin{quote}
{\tt %\footnotesize
\begin{algorithm}
{\bf description}
\ \ \ . . .
{\bf class} $\langle${\em class\_name} $\rangle$ {\bf is}
\ {\bf private}
\ \ \ \ . . . [data declarations]
\ {\bf protected}
\ \ \ \ . . . [data declarations]
\ {\bf public} 
\ \ \ \ . . . [data declarations]
\ {\bf private} 
\ \ [definitions of private operations]
\ {\bf protected} 
\ \ [definitions of private operations]
\ {\bf public}
\ \ [definitions of public operations] 
{\bf endclass} $\langle${\em class\_name} $\rangle$ 
\end{algorithm}
%\end{quote}
}
\vspace{0.1in}

%\newpage


\section{Data Declaration}

Data descriptions are the data declarations that define the class attributes. Three groups of data attributes can be defined in a class: constants, variables, and object references. 

\vspace{0.1in}
%\begin{quote}
{\tt %\footnotesize
\begin{algorithm}
\ \ {\bf constants}
\ \ \ \ . . .
\ \ {\bf variables}
\ \ \ \ . . .
\ \ {\bf object references}
\ \ \ \ . . .
\end{algorithm}
%\end{quote}
}
\vspace{0.1in} 

Each data declaration consists of:

\begin{itemize}
\item
A unique name to identify the data item
\item
An optional initial value
\item
The type of the data item

\end{itemize}

The name of a data item is an identifier and is given by the programmer; it must be different from any keyword in OOSimL (or in Java). 



%\vfill

\subsection{Data Names}

Text symbols are used in all algorithm description and in the source program. The special symbols that indicate essential parts of an algorithm are called {\em keywords}. These are reserved words and cannot be used for any other purpose. 
The symbols used for uniquely identifying the data items and are called {\em identifiers} and are defined by the programmer. For example, {\em x, y, z, s}, and {\em area}. 

The data items normally change their values when they are manipulated by the instructions in the various operations. These data items are known as {\em variables}\index{variables} because their values change when instructions are applied on them. Those data items that do not change their values are called {\em constants}\index{constants}. These data items are given an initial value that will never change.


%\vfill

\subsection{Data Types}

Data types can be of two groups: {\em elementary\/}\index{primitive types} (also known as primitive) data types and classes.

Elementary types are classified into the three following categories: 
\begin{itemize}
\item Numeric
\item Text
\item Boolean
\end{itemize}

There are three groups of numeric types: {\bf integer}, {\bf float}, and {\bf double}. The non-integer types are also known as real (or fractional), which means that the numerical values have a fractional part. 

Integer values are countable to a finite value, for example, age, number of automobiles, number of pages in a book, and so on. Real values (of type {\bf float}) have a decimal point; for example, cost amount of an item, the height of a building, current temperature in a room, a time interval (period). These values cannot be expressed as integers. Values of type {\bf double} provide more precision than type {\bf float}. 

There are of two basic types of text data items: {\bf character} and type {\bf string}. Data items of type {\bf string} consist of a sequence of characters. The values for these two types of data items are textual values.

%\vfill

Another data type is the one in which the values of the variables can take a truth-value (true or false); these variables are of type {\bf boolean}.

Complex types are the classes and are used as types for object reference variables in all object-oriented programs. Values of these variables are references to objects. 

\subsection{Data Declarations in OOSimL}

Each data description includes the name or identifier for variable or constant and its type. The initial value of a variable or constant is optional. There are two general categories of variables:

\begin{itemize}
  \item Variables of elementary or primitive type
  \item Object reference variables 
\end{itemize}

In object-oriented programming languages, the programmer defines classes as types for object reference variables, then creating objects of these classes. 


\subsubsection{Variables of Elementary Types}

The OOSimL statement for the declaration of variables of elementary types has the following form:

\vspace{0.1in}
%\begin{quote}
{\tt %\small
\begin{algorithm}
{\bf define} $\langle$ variable\_name $\rangle$ {\bf of type} $\langle${\em elementary\_type} $\rangle$
\end{algorithm}
}
%\end{quote}
\vspace{0.1in}

Examples of data declarations in OOSimL of two constants of types {\bf integer} and {\bf double}, and three variables of type {\bf integer}, {\bf float}, and {\bf boolean}.
 

\vspace{0.1in}
%\begin{quote}
{\tt \small
\begin{verbatim}
 constants
    define MAX_PERIOD = 24 of type integer
    define PI = 3.1416 of type double
 variables
    define number_elements of type integer
    define salary of type float
    define act_flag of type boolean
\end{verbatim}
}
%\end{quote}
\vspace{0.1in}

\subsubsection{Object References}

An object reference variable can refer to an object. The following OOSimL statement declares object references variables and has the structure:

\vspace{0.1in}
%\begin{quote}
{\tt %\small
\begin{algorithm}
{\bf define} $\langle${\em object\_ref\_name} $\rangle${\bf of class} $\langle${\em class\_name} $\rangle$
\end{algorithm}
%\end{quote}
}
\vspace{0.1in}

The following statements declare an object reference variable called {\em server\_obj} of class {\em Server}, and an object reference variable {\em car1\/} of class {\em Car}.

\vspace{0.1in}
%\begin{quote}
{\tt \small
\begin{verbatim}
object references
   define serverobj of class Server
   define car1 of class Car
\end{verbatim}
%\end{quote}
}
\vspace{0.1in}

\subsection{Temporal and Spatial Properties}
 
Additional properties of data items declared are important to fully understand identifying data items in software development, these concepts are:

\begin{itemize}
 \item
  The {\em scope\/}\index{scope} of a data item is that portion of a program in which statements can reference that data item. Variables and constants declared as attributes of the class can be accessed from anywhere in the class. Instructions in any functioned of the class can use these data items. Local declarations define data items that can only be used by instructions in the function in which they have been declared.
 \item
  The {\em persistence\/}\index{persistence} of a data item is the interval of time that the data item exists---the lifetime of the data item. The lifetime of a variable declared as an attribute of a class, exists during the complete life of an object of the class. Data items declared locally will normally have a life time only during which the function executes.
\end{itemize}

%\newpage


\section{Functions}

Classes consist of attribute declarations and definitions of functions\index{functions} (or methods\index{methods}). 

A function carries out a specific task of a class. Figure~\ref{fig:funstruct} illustrates the general structure of a function. The definition of a function consists of two basic parts: 

\begin{itemize}
\item
  Local data declarations
\item
  The sequence of statements with instructions that manipulate the data
\end{itemize}

\begin{figure}[h]
\vspace{.05in}
%\centereps{1.6in}{2.75in}{figs/funstruct.eps}
\centering
\includegraphics[width=1.5in]{figs/funstruct.eps}
\caption{Structure of a function}
\label{fig:funstruct}
%\vskip\baselineskip
\vspace{0.05in}
\end{figure}

The body of a function is composed of data declaration and instructions that manipulate the data. The scope of the data declared in the function is {\em local\/} to the function. The data\index{data} in a function only exists during execution of the function; their persistence is limited to the lifetime of the function. 

The brief documentation about the purpose of the function is described in the paragraph that starts with the keyword {\bf description} and ends with a star-slash (*/).  Other comments can be included at any point in the function to clarify and/or document the function. Line comments start with a double forward slash (//) and end with the line.

The name of the function is declared in the {\bf function\/} statement. This name is used when the function is called or invoked by some other function. In OOSimL, the basic form of a function definition is as follows.

\vspace{0.1in}
%\begin{quote}
{\tt %\small
\begin{algorithm}
\ {\bf description}
\ \ \ \ . . .
\ {\bf function} $\langle${\em function\_name} $\rangle$ {\bf is}
\ \ {\bf constants}
\ \ \ \ . . .
\ \ {\bf variables}
\ \ \ \ . . .
\ \ {\bf object references}
\ \ \ \ . . .
\ \ {\bf begin}
\ \ \ \ . . . [instructions]
\ {\bf endfun} $\langle${\em function\_name} $\rangle$ 
\end{algorithm}
}
\vspace{0.1in}

The keyword {\bf function} starts the header followed by the name of the function; the body of the function starts with the keyword {\bf is}. The function definition ends with the {\bf endfun} keyword and the name of the function. 

Similarly to the data declarations in the class, the data declarations\index{declarations} are divided into constant, variable, and object references. Constant, variable, and object declarations are optional. The instructions in the body of the function appear between the keywords {\bf begin} and {\bf endfun}. 

The special function, {\em main}, starts and terminates the execution of the entire program; it is the control function of the program.  One of the classes of the program must include this function.


%\include{ch04} % Functions
%\include{ch05} % Design and Prog Structures
%\include{ch06} % Selection
%\include{ch07} % Repetition
%\include{ch08} % arrays
%\include{chap_inherit} % Inheritance
%\include{adv_oo} % Advanced OO concepts

\end{document}
