Wireless Internet Tutoring System Design Document. Nadya Belov, Dmitriy Bespalov, Ilya Braude, Immanuel Comer, Daniel Lapadat, Andrew Ragone

Transcription

1 Wireless Internet Tutoring System Design Document Nadya Belov, Dmitriy Bespalov, Ilya Braude, Immanuel Comer, Daniel Lapadat, Andrew Ragone

2 Contents Introduction 4. Goals and Guidelines Usability Testing General 4 2. Canvas Services Network Message Parser Client 5 3. ClientCanvas GUI WitsClient ClientSessionManager ClientServiceManager Server 6 4. ServerCanvas Session ServerServiceManager ServiceDescription User ServerSessionManager Client-Server Communication Protocol 7 6 UML Design 8 2

3 List of Figures Top-Level System Architecture General Architecture Client Architecture Server Architecture Data Flow Diagram

4 Introduction The Wireless Internet Tutoring System WITS, overcomes the problems of text-based messaging by allowing for an environment where text, symbols, and graphics can be manipulated and transmitted by persons involved in the tutoring session. WITS is the integration of special software with bleeding-edge hardware available today. WITS allows a tutor to help a student while being geographically separated. It provides the tools which allow a tutor to quickly and efficiently convey his knowledge about a particular math subject to his tutee using textual and graphical representations. This document presents the architectural design of WITS. The design outlines the high-level and low-level architecture specifying all of the objects that are necessary in WITS as well as their interaction with each other and the flow of information in the system. The architectural diagrams are presented using UML and provide detailed class headers along with several message protocols that are used for inter-component interaction. The proposed design is lightly coupled, modular and extensible. The overall architecture of WITS can be described as a client-server architecture, however, a notion of services is introduced. These services need not be specifically tailored to WITS and may be stand-alone applications that will service WITS along with other systems. A significant push in the light coupling design of the WITS system was done by the fast-paced technological advancement in the current world of computing.. Goals and Guidelines In assuring that the WITS is delivered on-time and satisfies all of the original requirements specified in the Requirements Document and reinforced in this document, careful outlining of development schedules and procedures as well as testing must be implemented. In order to assure that our system will be delivered on-time, our team has established development and testing guidelines. We plan on developing our client and server components concurrently. In developing each of those components, we will implement an evolutionary model to ensure that rudimentary functionality has been established before any complex features are implemented. At the completion of each of the development phases which will include a new set of functionalities, extensive testing will be implemented to make sure that the system as it currently stands can run on the chosen hardware (Treo 600) and a demonstration with a basic scenario can be accomplished..2 Usability Testing Usability of a particular system can augment the user in accomplishing a set task. In order to insure that WITS is usable by users of all skill levels (beginner, intermediate and expert), computational and heuristic usability testing methods will be employed at the final stage of testing. This effort will furthermore assist us in the creation of final documentation which will include user manuals and tutorials. 2 General 2. Canvas This is an abstract class that both ServerCanvas and ClientCanvas implement. Canvas provides and interface to receive and provide information into the chat, graphics and caption logs. 2.2 Services Services provide the system with additional capabilities that would not be included otherwise. Reasons may include CPU speeds, memory, complexity, or intensive calculations. Our client system is limited by the device that it is running on. Services allow the client to perform tasks that it otherwise would not have the power to 4

5 do. An example of this is LATEX rendering. The application that does the latex rendering is several Megabytes in size and would be processed slowly if rendered on the client. Services allow the clients to render the latex independently. They are autonomous and know nothing about the WITS system. They can implement their own protocols and even be distributed throughout the network or run locally. The modular design approach used in making the services and independent and non-critical components allows for a significant amount of freedom in the range of systems the WITS system can run on. If clients are on opposite ends of the world they can have their local services render the latex for them, hardware and software capabilities permitting. It must be noted that services are not limited to just rendering latex or even rendering capabilities. As our system evolves and becomes more sophisticated, so will the services that may be associated with our system that will provide WITS clients with certain capabilities. As shown in the UML diagram depicting the architecture of the WITS Server, the WitsServer object will contain a ServiceManager object that will be responsible for providing the services to the server. If the client, however, already knows about the available services, it will be able to use these services without accessing the WitsServer. This modular design also allow the services to provide other systems with their service. The services may have capabilities to make themselves known. Given such capabilities, both the client and server side of our architecture will be allowed to utilize these services simultaneously and independently. 2.3 Network The Network object sends and receives data from the network. Because of the time-critical nature of data exchanged between the server and client, our Network layer uses the TCP protocol as it s underlying transport format. TCP guarantees that data is received in the order that it was sent, and that it does not get corrupted along the way. WITS uses it s own protocol, described in Section 5 to handle client-server communications. Translation between Java objects and our protocol is handled by the Parser (Section 2.3.2). The Network object contains a Java Socket that it uses to communicate with the physical network. The exact Java code for establishing and maintaining a Java Socket will vary on the server and client platforms, but the function and interface are the same Message The Message class represents all messages that are passed throughout our system. Specific instances of this class can express information such as shape additions and deletions, chat messages, and session management directives Parser The Parser translates between the Message class and the WITS communications protocol. Received data gets transformed into a Message object and propagated upwards in the system. Conversely, Message objects are translated into a representation consistent with our protocol and sent through the network. 3 Client 3. ClientCanvas The ClientCanvas implements the Canvas object discussed prior in this document. The ClientCanvas object is customized specifically for the client-side of the WITS system and is responsible for providing the user-interface with which a user will interact with. ClientCanvas is a member of the GUI object. Together, the ClientCanvas 5

6 object and the GUI object provide a complete graphical user interface to the user. Specifically, the WITS system contains a notion of modes which are specific screen arrangements each providing a specific task for the user. For example, there are Draw and SplitScreen modes. ClientCanvas provides the user interface for the modes and augments the GUI object in capturing all of the changes made by the local user as well as the changes made by the other users in the same session. 3.2 GUI The GUI object, briefly mentioned in the description of the ClientCanvas object is a major component of the userinterface part of the WITS Client. The GUI object, contains a ClientCanvas object and uses it to create several modes which a user may use to enter and view information while using the WITS system. The modes are Draw, Text, SplitScreen and Options modes. For example, the SplitScreen mode provides the functionality of both the Draw and Text modes by displaying both and separating them via a divider. While the ClientCanvas is used to compose the modes, the GUI object will be responsible for acting on user-generated events such as various button presses or drawings and will furthermore provide the user with updates that were generated by the WitsServer object in an effort to bring all members of a session up-to date. 3.3 WitsClient This is placeholder class that has access to all objects on the client side. This is needed in case threading is not implemented on the client operating system. If it is not, a scheduling algorithm will be placed here that will poll the appropriate classes 3.4 ClientSessionManager The ClientSessionManger object contains information about the WitsServer. This information includes the IP address and port of the server, the user name, and the current session that the user is in. This will enable the client to automatically reconnect, should the connection be severed, and help in identifying the client when it initiates communications. 3.5 ClientServiceManager The ClientServiceManager object maintains a list of services available to the client. When an object cannot be serviced or rendered by the GUI and Canvas, it is passed to the Service Manager. The Service Manager tries to satisfy the request by using one of the services that are available to it. The output of the service or failure are returned back to the user. For an example, consider a LATEX string as input. The GUI and Canvas are not able to render the math formula due to device limitations. Therefore, the latex code is sent to a LATEX rendering service through the Service Manager. A JPEG image is then returned back to the GUI. 4 Server 4. ServerCanvas The ServerCanvas object implements the Canvas object described earlier in this document. The server component of the WITS system does not contain any graphical components or a user-interface because the server does not have a single user. ServerCanvas keeps an up-to-date representation of the session, including the shape modification and captions history, and the chat history. This will allow for new users to a session to instantly receive the current state for that tutoring session. A similar technique will be applied to users who reconnect 6

7 after a dropped connection. Updates to the canvas by a client will be propagated to the rest of the clients in the same session. 4.2 Session A Session objects describes a session between a tutor and several tutees. Each Session consists of a name, list of Users ( 4.4) in the session, and a ServerCanvas object. The Session object is responsible for propagation changes from a single client to the rest of the users in the session. 4.3 ServerServiceManager The ServerServiceManager handles all of the services present to the network. Only descriptive information about the services is stored within the Server list of ServiceDescriptions. The implementation of each service is hidden from the Server. Clients can obtain information about the available services on the network from this component. The server will be able to use these services as well if that is needed ServiceDescription The ServiceDescription object contains a host name, a port number, a service name, and a description of the service that it provides. 4.4 User The User object holds a user name, and the Network object that the user is using to communicate with the server. 4.5 ServerSessionManager The Session Manager handles all sessions that exist on the server. This is the object that users will initially establish a connection with before being given to a Session. The ServerSessionManager also handles the creation, removal of Sessions, the addition of users to a Session and the removal of users from a Session. 5 Client-Server Communication Protocol The main task of the Network Component is to interpret messages from the components above it and transfer them into a message suitable for transfer across the network. This message should contain any updates, additions and deletions done to the current state of the world in the session. The message that will carry all of this information must be very flexible, modular and extensible. The message format, the protocol of which is described below, will be passed onto the network component as a string. The message will consist of the following format: Magic String Version Number Message Class Message Type Message Message Body Length wits 8 bits 4 bits 4 bits 8 bits Message Length bytes As can be seen from above, a concept of a magic number specified in our protocol as Magic String is used as a means of authentication to assuring that the message originated from a WITS client or server. Furthermore, a version number is used to allow flexibility in the WITS system where it may be necessary to run a client and a server that are of different versions. Each version may have more or less capabilities and needs and by specifying the version number, the server will be able to service that particular client accordingly, or vice versa. Message 7

8 Class and Message Type are used to specify the exact operation and message that this particular message is used to carry. That is, for example, an update of a shape will have to have to specify that the Message Class is an update and Message Type is shape. Using these two concepts we can make the message protocol flexible enough to allow for additions and updates to the protocol without having to change the format of the message and thus allowing for multiple versions. The last two components of the message, Message Length and Message Body are used to specify the specifics that would come with the given Message Class and Message Type. To continue with the example presented above (shape update), the specific shape object description is saved and placed in the Message Body. Let us for example suppose, that the particular shape is a triangle. The Message Body would incorporate the length of each side and the angles of the triangle. The message protocol is flexible in allowing for variable length messages that can be composed of different information in the Message Body. Bandwidth is limited on the hardware platform, Treo, and it is impractical to pad some messages that will not necessarily need to be as large as others that may need to be significantly larger in size. The details of the actual identifiers used to specify the specific type of Message Class and Message Type are left to implementation and will be specified in the final documentation. 6 UML Design WitsServer propagate update update from a client propagate update WitsClient WitsClient WitsClient... Figure : Top-Level System Architecture 8

9 ServerCanvas ClientCanvas -socket: Socket -parser: Parser Network +getdata(): byte[] +senddata(byte[]): void -chatlog: Vector -figures: Vector -caption: String Canvas +drawjpeg(obj:witjpeg): void +drawcircle(obj:witcircle): void +drawrectangle(obj:witrect): void +drawline(obj:witline): void +drawtriangle(obj:wittriangle): void +drawtext(obj:string): void +drawfreehand(coordinates:vector): void +addchattext(text:string): void Parser +parse(data:byte[]): Message +encode(msg:message): byte[] Message +magic_str: String +version: int +class: String +type: String +message: String[] -name: String -network: Network -service_type: String Service LatexService +renderlatex(in latexcommand:string,out RenderedLatex:JPEG) Figure 2: General Architecture 9

10 data that GUI can not handle (service) data that GUI can handle -services_list: Vector -established_services: Vector ClientServiceManager +processmessage(message:message): Object WitsClient -session_manager: ClientSessionManager -gui: GUI -network: Network -service_manager: ClientServiceManager +processmessage(message:message): void -socket: Socket -parser: Parser Network +getdata(): byte[] +senddata(byte[]): void -name: String -network: Network -service_type: String * Service -name: String -server_ip: String -port: int ClientSessionManager +connect(): void +disconnect(): void -freehandbutton: JButton -linewidthbutton: JButton -linecolorbutton: JButton -shapesbutton: JButton -circlebutton: JButton -rectbutton: JButton -linebutton: JButton -arttextbutton: JButton -captionbutton: JButton -symbolbutton: JButton -drawmodebutton: JButton -chatmodebutton: JButton -splitmodebutton: JButton -preferencemodebutton: JButton -sendbutton: JButton -donecaptionbutton: JButton -chattext: JText -chatscrollbar: JScrollbar -userchattext: JText -captiontext: JText -drawpanel: JPanel -chatpane: JPanel -currentpanel: JPanel -splitmodepanel: JPanel -preferncemodepanel: JPanel +handlebuttonclick(button:jbutton): void +handlemouseclick(x:int,y:int,): void +handlemousemove(x:int,y:int,): void +handlekeyboard(letter:char): void +handlefreehandbutton(): void +handlelinewidthbutton(): void +handlelinecolorbutton(): void +handleshapesbutton(): void +handlecirclebutton(): void +handlerectbutton(): void +handlelinebutton(): void +handlearttextbutton(): void +handlecaptionbutton(): void +handlesymbolbutton(): void +handledrawmodebutton(): void +handlechatmodebutton(): void +handlesplitmodebutton(): void +handlepreferencemodebutton(): void +handlesendbutton(): void +handledonecaptionbutton(): void +eventmovesliptmode(): void GUI ClientCanvas Figure 3: Client Architecture 0

11 WitsServer -session_manager: SessionManager -service_manager: ServiceManager -sessions: Vector ServerSessionManager +addsession(): void +adduser(user:user,session:session): void +removesession(session:session): void +removeuser(user:user,session:session): void -service_list: Vector +getservicelist(): Vector +removeservice(name:string): void +addservice(service_description:servicedescription): void ServerServiceManager update from user stores update -canvas: ServerCanvas -users: Vector -name: String Session +processmessage(in message:message): void * +name: String +IP: String +port: int +service_type: String ServiceDescription * ServerCanvas propagate update User -name: String -network: Network -session: Session * list of services -socket: Socket -parser: Parser Network +getdata(): byte[] +senddata(byte[]): void Figure 4: Server Architecture GUI ClientServiceManager Service Network(for the service) ServiceServer Network(for WitsServer) Network(on WitsServer) User Session Users processmsg( msg ) sends data to sends data to be network sends msg according to Service Protocol passes JPG back returns JPG processes message passes JPG back passes JPG back draws JPG on Canvas sends data to sends data to passes msg to calls processmessage sends message to all users returns returns returns returns returns Figure 5: Data Flow Diagram