SDSU CS 596: Client-Server Programming
Spring Semester, 1997
Doc 1, Introduction

[To Lecture Notes Index]
San Diego State University -- This page last updated Jan 27, 1997

Contents of Doc 1, Introduction

  1. References
  2. Introduction to Course
  3. Computing "Paradigms"
      1. Centralized Multi-user Architecture
      2. Distributed Single-User Architecture
      3. Client/Server Architecture
  4. Introduction to Client-Server
    1. What is Client-Server?
    2. What Client-Server Requires of a Programmer
  5. Names
    1. Kinds of Comments
    2. Commenting Efficiently
    3. Commenting Techniques
      1. Commenting Individual Lines
      2. Commenting Paragraphs of Code
    4. Commenting Data Declarations
    5. Commenting Routines
  7. Object-Oriented Programming

Doc 1, Introduction Slide # 1


Code Complete by Steve McConnell

Doc 1, Introduction Slide # 2

Introduction to Course

Items To Cover
Java References

The Java Programming Language, Arnold and Gosling, Addison Wesley

Core Java by Cornell and Horstmann
On-line Java Documentation

Java 1.01

Java 1.1b3

SDSU Java Lib

CS535 Java Lecture Notes

Doc 1, Introduction Slide # 3

Computing "Paradigms"

Centralized Multi-user Architecture

Large central computers serving many users

Doc 1, Introduction Slide # 4

Motivating Factors
Service large number of users (200 to 10,000+)
Centralized storage for large data bases
Minimize data on slow networks

Very stable, very reliable, well supported
Cost-effective why to support thousands of users
Large pool of technical staff
Large number of business applications available
Proprietary hardware and software
Very expensive
Requires large support staff
Costly to incrementally add more capacity
Mind Set
Hierarchical organization (Bureaucratic heaven)

Doc 1, Introduction Slide # 5

Distributed Single-User Architecture

Motivating Factors
Low cost fast local area networks
Provide small number of users with compute power
Failure of MIS departments to be responsive and cost-effective

Doc 1, Introduction Slide # 6
Cheap hardware and software
Lots of third-party software
User is in complete control of environment
Low cost to add more users
Sharing of resources across many users is difficult
Networks and OS do not provide good control or management over computer resources
Multivender environments can cause operation, support and reliability problems

Mind set
Individualism (Lone Ranger syndrome)

Doc 1, Introduction Slide # 7

Client/Server Architecture

Motivating Factors
Limitations of other modes of computing
"Cool" applications like WWW
Utilize easy to use micro computers as front end to mainframe computers

Doc 1, Introduction Slide # 8
Cost-effective way to support thousands of users
Low cost to add more users
Cheap hardware and software
Provides control over access to data
User remains in control over local environment
Flexible access to information

Lack of Maturity
Lack of trained developers
A threat to the bureaucrats and the lone rangers

Doc 1, Introduction Slide # 9

Introduction to Client-Server

What is Client-Server?

Application that initiates peer-to-peer communication
Translate user requests into requests for data from server via protocol
GUI often used to interact with user

Any program that waits for incoming communication requests from a client
Extracts requested information from data and return to client
Common Issues
  • Authentication
  • Authorization
  • Data Security
  • Privacy
  • Protection
  • Concurrency
  • <hr>

Example: World Wide Web (WWW)

Server normally provides data to clients
Often utilizes some data base
WWW data is HyperText Markup Language (html) files
Client Server Programming
<H2>Client Server Programming</H2>

Doc 1, Introduction Slide # 10
How do the client and server interact
This is the glue that make client-server work
Involves using low level network protocols and application specific protocols
Designing application specific protocols is very important
WWW uses the HyperText Transfer Protocol

Doc 1, Introduction Slide # 11
Request= SimpleRequest | FullRequest
SimpleRequest=GET <uri> CrLf
FullRequest=Method URI ProtocolVersion CrLf
[*<HTRQ Header>]
[<CrLf> <data>]
<Method>= <InitialAlpha>
uri=<as defined in URL spec>
<HTRQ Header>=<Fieldname> : <Value> <CrLf>
<data>= MIME-conforming-message
What this Course is not

An advanced (or beginning) Networking course

How to use a client builder application/system

What this Course covers

The skills and knowledge required to build client-server applications

Doc 1, Introduction Slide # 12

What Client-Server Requires of a Programmer

Doc 1, Introduction Slide # 13


"Finding good names is the hardest part of OO Programming"

"Names should fully and accurately describe the entity the variable represents"

What role does the variable play in the program?
Data StructureRole, function

Some Examples of Names, Good and Bad
TrainVelocityVelt, V, X, Train
CurrentDateCD, Current, C, X, Date
LinesPerPageLPP, Lines, L, X

Doc 1, Introduction Slide # 14
OOP Names - Common Problems
class Stack 
   Vector theStack = new Vector();

   public void push( object x )
      theStack.add( x );

   // code deleted

class DriverProgram 
   public void static main( String[] args )
      // blah blah blah

      Stack stack;

      aFooFunction( stack );

      // more blah

   void aFooFunction( Stack aStack )

Doc 1, Introduction Slide # 15


"Comments are easier to write poorly than well, and comments can be more damaging than helpful"
What does this do?
for i := 1 to Num do
 MeetsCriteria[ i ] := True;
for  i := 1 to Num / 2  do begin
 j := i + i;
 while ( j <= Num ) do begin
  MeetsCriteria[ j ] := False;
  j := j + i;
for i := 1 to Mun do
 if MeetsCriteria[ i ] then
  writeln( i, ' meets criteria ' );

Doc 1, Introduction Slide # 16
How many comments does this need?

for PrimeCandidate:= 1 to Num do
   IsPrime[ PrimeCandidate] := True;

for  Factor:= 1 to Num / 2  do begin
   FactorableNumber := Factor + Factor ;
   while ( FactorableNumber <= Num ) do begin
      IsPrime[ FactorableNumber ] := False;
      FactorableNumber := FactorableNumber + Factor ;

for PrimeCandidate:= 1 to Num do
   if IsPrime[ PrimeCandidate] then
      writeln( PrimeCandidate, ' is Prime ' );

Good Programming Style is the Foundation of Well Commented Program
Doc 1, Introduction Slide # 17

Kinds of Comments

X := X + 1    /* add one to X

/* if allocation flag is zero */

if ( AllocFlag == 0 ) ...

Used to explain complicated or tricky code
*p++->*c = a

/* first we need to increase p by one, then ..
Make code simpler before commenting
(*(p++))->*c = a

ObjectPointer = *ObjectPointerPointer;
ObjectPointer ->*DataMemberPointer = a;

Doc 1, Introduction Slide # 18
/*  **** Need to add error checking here  **** */

Distills a few lines of code into one or two sentences
Explains the purpose of a section of code
{ get current employee information }   intent

{ update EmpRec structure }     what

Doc 1, Introduction Slide # 19

Commenting Efficiently

 * module: Print                   *
 *                                 *
 * author: Roger Whitney           *
 * date:   Sept. 10, 1995          *
 *                                 *
 * blah blah blah                  *
 *                                 *

  module: Print          
  author: Roger Whitney  
  date:   Sept. 10, 1995 
  blah blah blah         

Commenting Techniques

Commenting Individual Lines

Avoid self-indulgent comments
MOV AX,  723h        ;    R. I. P. L. V. B.

Endline comments have problems

MemToInit := MemoryAvailable(); { get memory available }

Not much room for comment
Must work to format the comment

Use endline comments on
Data declarations
Maintenance notes
Mark ends of blocks

Doc 1, Introduction Slide # 20

Commenting Paragraphs of Code

Write comments at the level of the code's intent

Comment the why rather than the how

Make every comment count

Document surprises

Avoid abbreviations
How verses Why
/* if allocation flag is zero */

if ( AllocFlag == 0 ) ...

/* if allocating a new member */

if ( AllocFlag == 0 ) ...

Even Better
/* if allocating a new member */

if ( AllocFlag == NEW_MEMBER ) ...

Doc 1, Introduction Slide # 21
Summary comment on How
{ check each character in "InputStr" until a 
  dollar sign is found or all characters have 
  been checked }

Done   := false;
MaxPos := Length( InputStr );
i      := 1;
while ( (not Done) and (i <= MaxLen) ) begin
   if ( InputStr[ i ] = '$' ) then
      Done := True
      i := i + 1

Summary comment on Intent
{ find the command-word terminator }

Done   := false;
MaxPos := Length( InputStr );
i      := 1;

while ( (not Done) and (i <= MaxPos ) ) begin
   if ( InputStr[ i ] = '$' ) then
      Done := True
      i := i + 1

Doc 1, Introduction Slide # 22
Summary comment on Intent with Better Style
{ find the command-word terminator }

FoundTheEnd      := false;
MaxCommandLength := Length( InputStr );
Index            := 1;

while ((not FoundTheEnd) and 
       (Index <= MaxCommandLength)) begin

   if ( InputStr[ Index ] = '$' ) then
      FoundTheEnd := True;
      Index := Index + 1;

Doc 1, Introduction Slide # 23

Commenting Data Declarations

Comment the units of numeric data

Comment the range of allowable numeric values

Comment coded meanings
   CursorX:      1..MaxCols;   { horizontal screen position of cursor }
   CursorY:      1..MaxRows;   { vertical position of cursor on screen }

   AntennaLength:   Real;   { length of antenna in meters: >= 2 }
   SignalStrength:   Integer;   { strength of signal in kilowatts: >= 1 }

   CharCode:      0..255;   { ASCII character code }
   CharAttib:      Integer;   { 0=Plain; 1=Italic; 2=Bold  }
   CharSize:         4..127;   { size of character in points }

Comment limitations on input data

Document flags to the bit level

Doc 1, Introduction Slide # 24

Commenting Routines

Avoid Kitchen-Sink Routine Prologs

Keep comments close to the code they describe

Describe each routine in one or two sentences at the top of the routine

Document input and output variables where they are declared

Differentiate between input and output data

Document interface assumptions

Keep track of the routine's change history

Comment on the routine's limitation

Document the routine's global effects

Document the source of algorithms that are used
procedure InsertionSort 
   Var   Data:      SortArray;    { sort array elements }
      FirstElement:   Integer        {index of first element to sort}
      LastElement:   Integer        {index of last element to sort}

Doc 1, Introduction Slide # 25

Object-Oriented Programming

Conceptual Level DefinitionAbstraction

"Extracting the essential details about an item or group of items, while ignoring the unessential details."
Edward Berard

"The process of identifying common patterns that have systematic variations; an abstraction represents the common pattern and provides a means for specifying which variation to use."
Richard Gabriel

Pattern:    Priority queue

Essential Details:   length 
   items in queue 
   operations to add/remove/find item

Variation:   link list vs. array implementation
   stack, queue

Doc 1, Introduction Slide # 26
Object-Oriented Programming
Conceptual Level DefinitionEncapsulation

Enclosing all parts of an abstraction within a container


Doc 1, Introduction Slide # 27
Object-Oriented Programming
Conceptual Level DefinitionInformation Hiding

Hiding parts of the abstraction


Doc 1, Introduction Slide # 28
Object-Oriented Programming
Conceptual Level DefinitionHierarchy

Abstractions arranged in order of rank or level

Class Hierarchy

Doc 1, Introduction Slide # 29
Object-Oriented Programming
Conceptual Level DefinitionHierarchy

Object Hierarchy