Software Reuse, Frameworks, and Client-server Systems

September 8, 2005

Motivation for Software Reuse

FrameworksDefinition

Object Oriented Model

Client-server systemsDefinition

Examples

A client-server framework

Application: knock-knock

Motivation for Software Reuse

Challenges:

Maintaining legacy systems is costly.

Designing software is a complex task.

Opportunities:

New software has many familiar components

Reuse can:- reduce development cost

- simplify design

- increase reliability

Constraints on Reuse Why are so few systems are designed for reuse?

– Expediency

– Copyright concerns

– “Not invented here” syndrome

- Potential reusers must have confidence

- The quality of a software product is only as good as its lowest-quality reusable component

– Design for reuse is costly

- programming overhead

- Run-time overhead

What’s a Framework?

A framework is a reusable software component that implements a generic solution to a collection of related applications.

– It provides common facilities that can be implemented differently for different applications.

– It is often designed as a collection of classes, some of which are abstract.

Driving Principle: Applications that appear to be different often have similar designs.

Framework Characteristics

A framework is intrinsically incomplete.

A framework contains:– Slots: certain classes or methods that are defined in the

framework, but are unimplemented (user must implement them), and

– Hooks: certain unimplemented functional elements that user may or may not implement.

An Application Program Interface (API) has all of the framework’s public methods.

Examples of Frameworks

• Payroll administration

• Frequent buyer clubs

• University registration

• E-commerce web sites

• Home security alarm systems

Framework Architectures

Application Application

Horizontal framework

Verticalframework

Code to be provided to adapt the framework to theneeds of the application

Services offeredby the framework

Client-Server FrameworkA distributed system has:

– Different tasks performed by separate programs,– Programs communicating on separate computers,– Programs sharing information.

A Client-Server (distributed) system has:A server program that provides a particular service to other

programs that communicate with it, andOne or more client programs that access the server (or several

servers) to obtain services.

The server may be accessed by many clients asynchronously and independently.

Examples of client-server systems

– The World Wide Web

Browsing

E-mail

– Network File Systems

– Transaction Processing SystemsATM

Course Registration

– E-commerce SystemsAmazon

Airline reservations

Client-server event sequencing 1. The server starts running. 2. The server waits for clients to connect. (listening) 3. Clients start running and make requests to connect.4. When receiving such a request, the server may accept the

connection 5. The server waits for messages to arrive from connected

clients6. When a message from a client arrives, the server

responds, and then resumes waiting. 7. Clients continue functioning in this manner until they

decide to disconnect.8. Servers continue functioning until they decide to shut

down.

States of a server (UML state diagram)

Waiting for Connections

Handling a Connection

do: react to messages

handledisconnection

Waiting

start listening stop listening

For each connection:

For the server as a whole:

accept connection

Initializing

terminate

Example UML sequence diagram:

server + 2 clients

disconnect

send message

disconnect

send reply

listen for connections

stop listening

connect

Client 2

send message

connect

Client 1Server

Advantages of client-server systems

Work is distributed among different machines Many clients can access services

- from a distance- continuouslyDesign - separation - simplificationData - Shared data can be managed centrally at the server- Non-shared data can be distributed among different

clientsOpportunities for reuse

Activities of a client (UML activity diagram)

initiate a connection to a server

respond to server events,

respond to messages, and

handle server disconnection

interact with user,

send messages

to server as needed

terminate

initialize

Threads in a client-server system

(another UML sequence diagram)

kill clientdisconnect

reply to message

create

reply to message

connect

displaydisconnect

display reply

display reply

create

wait forconnections

interactwith user

wait for server events

wait for messages:

client A

interact withserver user

wait for messages:

client B

send message

send message

Client Side (Client A) Server Side

Object Client-Server Framework (OCSF)*

(UML class diagram)

******

ConnectionToClient

sendToClientclosesetInfogetInfo

AbstractServer

listenstopListeningclose

clientConnectedclientDisconnected

serverStarted

handleMessageFromClient

serverStopped

sendToAllClientsgetClientConnections

serverClosed

clientException

listeningException

*See Lethbridge and Lagagniere, chapter 3, for a detailed discussion.

AbstractClient

openConnection

closeConnectionsendToServer

connectionEstablished

connectionClosed

handleMessageFromServer

connectionException

Using OCSF

• Software designers using OCSF never modify these three classes.

• Instead, they:– Create application-dependent subclasses by

extending the abstract classes in the OCSF– Use features by calling public methods

provided by these three classes – Override slot and hook methods that are

designed to be overridden.

The Client Side of OCSF

• The class AbstractClient must be subclassed• That subclass must implement handleMessageFromServer and:– Take an action whenever a message is received

from the server– Implement the Runnable interface– loop in its run method for the lifetime of the

thread

Client Side:

public interface of AbstractClient

Controlling methods:openConnection closeConnection sendToServer

Accessing methods:isConnected getHost setHost getPort setPort getInetAddress

Client Side:

Slots and Hooks in AbstractClient

(slot) Method that must be implemented:handleMessageFromServer

(hooks) Methods that may be overridden:connectionEstablished connectionClosed

Client side: Using AbstractClient

Create a subclass of AbstractClient

Implement handleMessageFromServer slot

Write code that:• Creates an instance of the new subclass • Calls openConnection • Sends messages to the server using the

sendToServer • Implements connectionClosed

Implement connectionException

Client side: internals of AbstractClient

A Socket keeps all the information about the connection to the server

Two streams: – an ObjectOutputStream for messages to the server,

and

– an ObjectInputStream for messages from the server.

A Thread that runs using AbstractClient’s run method

Two variables that store the server’s hostid and port

The OCSF Server Side

Two classes:– AbstractServer: the thread that listens for

new connections, and– ConnectionToClient: a thread that

handles a connection to a client (one for each active client)

Server side:

Public interface of AbstractServer Controlling methods:

listen stopListening close sendToAllClients

Accessing methods:isListening getClientConnections getPort setPortsetBacklog

Server side:

Slots and Hooks of AbstractServer

(Slot) method that must be implemented:handleMessageFromClient

(Hooks) Methods that may be overridden:serverStarted clientConnected clientDisconnectedclientExceptionserverStoppedlisteningException serverClosed

Server side:ConnectionToClient public interface

Controlling methods:

sendToClient

close

Accessing methods:

getInetAddress

setInfo

getInfo

Server side:

designing an application Create a subclass of AbstractServer

Implement the slot handleMessageFromClient

Write code that:

Creates an instance of the subclass of AbstractServer

Calls the listen method

Sends messages to clients, using either:

getClientConnections and sendToClient, or

sendToAllClients

(optionally) Implement one or more of the other hooks

Server Side: Internals

setInfo and getInfo use the Java HashMap

Many methods are synchronized

The collected instances of ConnectionToClient are stored as a so-called ThreadGroup

The server pauses from listening every 500ms to see if the stopListening method has been called

Knock-knock Architecture<<interface>>

ChatIF

display

ChatClient

handleMessageFromServerhandleMessageFromClientUIquit

ClientConsole

acceptdisplaymain

AbstractClient

EchoServer

handleMessageFromClientserverStartedserverStoppedmain

AbstractServer

ConnectionToClient

run

kkServerProtocol

*

Server side

Client side

The Server Side

EchoServer is a subclass of AbstractServer

– The main method creates a new instance and starts

– It listens for clients and handles connections until the server is stopped

– Three slots and hooks display messages to the user:

handleMessageFromClient

serverStarted

serverStopped

Key code in EchoServer

public void handleMessageFromClient (Object msg, ConnectionToClient client){ System.out.println( "Message received: ” + msg + " from "

+ client);}

States of a Java Thread

Each thread t must have a run method.Thread begins when t.start() is called. Thread terminates when its run method exits.

Key code in ConnectionToClient thread

public void run() { server.clientConnected(this); try {

kkServerProtocol kksp = new kkServerProtocol();Object msg = kksp.processInput(null);sendToClient(msg);server.receiveMessageFromClient(msg, this);while (!readyToStop) { msg = kksp.processInput((String)input.readObject());

sendToClient(msg); server.receiveMessageFromClient(msg, this); } } catch (Exception exception) { … } }

Key code in kkServerProtocolpublic class kkServerProtocol { private static final int WAITING = 0; private static final int SENTKNOCKKNOCK = 1; private static final int SENTCLUE = 2; private static final int ANOTHER = 3; private static final int NUMJOKES = 3; private int state = WAITING; private int currentJoke = 0; private String[] clues = { "Turnip", "Little Old Lady", "Atch” }; private String[] answers = { "Turnip the heat, it's cold in here!", "I didn't know you could yodel!", "Bless you!"}; public String processInput(String theInput) { // process theInput and transition to next state. }

The ClientWhen each client program starts, it creates two objects:

A ChatClient A subclass of AbstractClient

Implements handleMessageFromServer by calling the display method of the user interface

A ClientConsoleImplements the interface ChatIF; i.e., makes the display

method output text to the consoleAccepts user input by calling accept in its run methodSends all user input to the ChatClient by calling handleMessageFromClientUI which, in turn, calls sendToServer

Key code in ChatClient

public void handleMessageFromClientUI (String message) { try { sendToServer(message); } catch(IOException e) { clientUI.display ( "Could not send message. " + "Terminating client."); quit(); }}

public void handleMessageFromServer (Object msg) {

clientUI.display(msg.toString());

}

Acknowledgments

Many of the above slides are adapted from Lethbridge, T. et al., Object Oriented Software Engineering Chapter 3: Basing Software Development on Reusable Technology.

The Knock-knock protocol is adapted from The Java Tutorial http://java.sun.com/docs/books/tutorial/

Additional Readings

1. Leveson, N. Medical Devices: the Therac-25, short version here.

2. * Mann, Why Software Is So Bad 3. Lethbridge, Chap 1, Chap 2