1. Software Reuse, Frameworks, and Client-server Systems September 8, 2005 Motivation for Software Reuse Frameworks Definition Object Oriented Model Client-server systems Definition Examples A client-server framework Application: knock-knock

2. 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

3. 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

4. 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.

5. 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.

6. Examples of Frameworks Payroll administration Frequent buyer clubs University registration E-commerce web sites Home security alarm systems

7. Framework Architectures

8. Client-Server Framework A 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, and One 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.

9. Examples of client-server systems –The World Wide Web Browsing E-mail –Network File Systems –Transaction Processing Systems ATM Course Registration –E-commerce Systems Amazon Airline reservations

10. 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 clients 6. 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.

11. States of a server (UML state diagram)

12. Example UML sequence diagram: server + 2 clients

13. Advantages of client-server systems 1. Work is distributed among different machines 2. Many clients can access services - from a distance - continuously 3. Design -separation -simplification 4. Data -Shared data can be managed centrally at the server -Non-shared data can be distributed among different clients 5. Opportunities for reuse

14. 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

15. Threads in a client-server system (another UML sequence diagram)

16. Object Client-Server Framework (OCSF)* (UML class diagram) ****** ConnectionToClient sendToClient close setInfo getInfo AbstractServer listen stopListening close clientConnected clientDisconnected serverStarted handleMessageFromClient serverStopped sendToAllClients getClientConnections serverClosed clientException listeningException *See Lethbridge and Lagagniere, chapter 3, for a detailed discussion. AbstractClient openConnection closeConnection sendToServer connectionEstablished connectionClosed handleMessageFromServer connectionException

17. 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.

18. The Client Side of OCSF The class AbstractClient m ust 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

19. Client Side: public interface of AbstractClient Controlling methods: openConnection closeConnection sendToServer Accessing methods: isConnected getHost setHost getPort setPort getInetAddress

20. Client Side: Slots and Hooks in AbstractClient (slot) Method that must be implemented: handleMessageFromServer (hooks) Methods that may be overridden: connectionEstablished connectionClosed

21. Client side: Using AbstractClient 1. Create a subclass of AbstractClient 2. Implement handleMessageFromServer slot 3. Write code that: Creates an instance of the new subclass Calls openConnection Sends messages to the server using the sendToServer Implements connectionClosed 4. Implement connectionException

22. 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

23. 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)

24. Server side: Public interface of AbstractServer Controlling methods: listen stopListening close sendToAllClients Accessing methods: isListening getClientConnections getPort setPort setBacklog

25. Server side: Slots and Hooks of AbstractServer (Slot) method that must be implemented: handleMessageFromClient (Hooks) Methods that may be overridden: serverStarted clientConnected clientDisconnected clientException serverStopped listeningException serverClosed

26. Server side: ConnectionToClient public interface Controlling methods: sendToClient close Accessing methods: getInetAddress setInfo getInfo

27. Server side: designing an application 1. Create a subclass of AbstractServer 2. Implement the slot handleMessageFromClient 3. 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 4. (optionally) Implement one or more of the other hooks

28. 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

29. Knock-knock Architecture > ChatIF display ChatClient handleMessageFromServer handleMessageFromClientUI quit ClientConsole accept display main AbstractClient EchoServer handleMessageFromClient serverStarted serverStopped main AbstractServer ConnectionToClient run kkServerProtocol * Server side Client side

30. 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

31. Key code in EchoServer public void handleMessageFromClient (Object msg, ConnectionToClient client) { System.out.println( "Message received: ” + msg + " from " + client); }

32. 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.

33. 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) { … } }

34. Key code in kkServerProtocol public 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. }

35. The Client When 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 ClientConsole Implements the interface ChatIF ; i.e., makes the display method output text to the console Accepts user input by calling accept in its run method Sends all user input to the ChatClient by calling handleMessageFromClientUI which, in turn, calls sendToServer

36. 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()); }

37. 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/ http://java.sun.com/docs/books/tutorial/

38. Additional Readings 1. Leveson, N. Medical Devices: the Therac-25, short version here. Medical Devices: the Therac-25 here 2. * Mann, Why Software Is So Bad Why Software Is So Bad 3. Lethbridge, Chap 1, Chap 2 Chap 1 Chap 2