Client-Server Multi-View Screen Application
MULTIVIEW SCREEN PROJECT REPORT | MULTIVIEW SCREEN SYSTEM
Project Overview
1.1. Brief
This is the documentation of Final Year Project of BS (CS) degree.
This document includes the detailed description of “Multi-View Screen
Application”. It covers all the phases of system development including
requirement analysis, designing, and implementation and testing.
The
Software shall allow the user to control multiple systems through a singular
system connected to it over a network connection. The Software shall allow user
to manipulate the environment of a system and grant the user the authority to
monitor and control connected systems over a network such as LAN or WIFI
(WLAN). Our research scope is to perform the application under different
Application layer protocols such as RFB, JRMP and RDP in order to understand
their constraints and limitations, in order to propose an optimized solution.
Client side
Client Side deals with the end users. End users will use MVS
application in their PC, laptops devices to communicate with MVS server.
Server side
MVS server plays an important role in the whole system. MVS server
application display multiple client screens on the server machine and control
these clients.
1.2. Relevance to
Course Modules
The course of “Computer Networking” provides us the basic
knowledge about network structure(i.e how data is transferred over the
network) which is the basic requirement
of our project. “Human Computer Interaction” helped us in designing user
friendly GUI.
“Object-oriented programming” , “Software Engineering” and
“Computer Graphics” was also very helpful during the course of the project.
1.3. Project
Background
Remote Desktop Connectivity is a rapidly Growing
branch of computer networks as it allows both control and organization of
multiple systems or environment over a distributed environment of computing
systems. We aim to understand and produce a solutions by allowing the user
access to multiple systems over singular system in a more optimized procedure.
1.4 .Methodology And Software Life Cycle
In this project Agile
method is used for the development. Agile methods are contemporary software
engineering approaches based on teamwork, customer collaboration, iterative
development, and people, process, and technology adaptable to change. Agile Modeling (AM) is a practice-based methodology
for effective modeling and documentation of software-based systems.
Chapter 2
Problem definition
2.1. Purpose
Our purpose is to
create a Multi-View screen application which displays the environment of the
connected systems. The Software shall be able to display and control the
connected systems from within its own environment and allow the user to control
the environment of the preferred system. It shall display all active systems on
a singular window and shall appear as a standard GUI window.
2.2. Product
Functions
The purpose of this software is to provide a multi screen view to the
users so it shall become convenient for them to share the resources with their
preferred system.
The main functionality of the
system can be divided into two components.
1. MVS Server
2.MVS Client
MVS server will provide an interactive
user interface to manipulate the active clients. Functionality of the MVS
Server is as follows:
·
Start server
·
Stop server
·
Display Limit
·
Widget Mode
·
Normal Mode
·
Show Status
MVS client will provide a mean for
communication with the server.
Functionality of the MVS Client is as
follows:
·
Start client
·
Stop client
·
Disconnect
·
Set server IP
·
Control
·
Exit
Chapter 3
Requirement Analysis
3.1. Functional
Requirements
FR-1
The
Client Application and Server Application Shall be on the same network.
FR-2
The
Client application Shall display a taskbar icon with the application icon.
FR-3 The Client Shall
request for Server IP if not previously entered by the user.
FR-4
The
Client Shall search and connect to the Server Application.
FR-5
The
Client Shall start sending screenshot of the displayed environment.
FR-6
The
Client shall receive file requests from the server application and display a
file dialog box.
FR-7
The
Client shall receive input events from the Server application and simulate it
on the operating environment.
FR-8
The
Server Application shall display a GUI Window with a Menu interface for the
user.
FR-9
The
Server Application shall accept new client application requests.
FR-10
The
Server Application shall allow the user to transfer a file from the Client
Application.
FR-11
The
Server Application shall show statistical data of the connected Client
Applications.
FR-12
The
Server Shall allow the user to close a Client application.
FR-13
The
Server Shall Reorder and rearrange connected clients.
3.2. Non
Functional Requirements
3.2.1. Usability
· A user who is trained in handling GUI applications (which allow multiple functional capabilities such as word processors and peer to peer chat software) it shall take 1 hour at least and 2 hours maximum in usage time for him/her to fully understand and adapt to the software environment.
· A user who is unaware of GUI applications or the environment of the Software should consult the product manual for instructions.
· Software shall be cross platform i.e., It shall run on multiple Operating systems and shall help in user ease of use as it shall allow the user to use the software on their preferred environment.
3.2.2 Reliability
Availability:
If no external application interference is encountered by the application, then
the uptime of the server is 99.9%.
Accuracy: If a optimal
network setting is discovered the accuracy of the remote connections shall be
95%-99.9%.
Average usage: The average
usage can be at least 12 hours.
Mean Time to Repair: 1
hour maximum.
3.2.3.
Supportability
The
supportability of our software shall be provided through proper documentation
of our finding while researching the optimum solution for the software. The
research documentation shall indicate our problem and recommended and
implemented solution for our end product.
3.2.4. Design
Constraints
Programming Language:
The
language through which the client and the server shall communicate and perform
the required functionalities shall be JAVA ™ as it provides cross platform
execution capability.
Development Tools:
Eclipse
3.7 IDE and Netbeans 7.0 IDE shall be used as the primary choice for the
development of the software.
Libraries and Software Components:
Libraries
of the respective protocols shall be used and shall be implemented using the
packages for RMI which is used by the JRMP and the RFB package which shall use
the package components of the RFB protocol.
Operating Environment:
The
software shall be cross platform which shall enable it to run on at least two
different forms of operating system environments such as Microsoft Windows and
Linux.
3.2.5
Licensing
Requirements
· This product is not for selling purpose but for research and development in the field of computer networks and computer science.
· All Java SDK 1.6, 1.7 libraries used in the making of this product are a property of ORACLE AMERICA, INC. ("ORACLE").
- NetBeans IDE and NetBeans Platform are based on
software from netbeans.org, which has been dual licensed under the Common
Development and Distribution License (CDDL) and the GNU General Public
License version 2 with Classpath exception.
· Windows Copyright © 2011 Microsoft Corporation. All Rights Reserved.
·
The Product Multi-View Screen (MVS)
is is free software: you can redistribute it and/or modify it under the terms
of the GNU General Public License as published by the Free Software Foundation,
either version 3 of the License, or (at your option) any later version.This
program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the
implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.
3.3. Use Case
Model
3.3.1 Use Case
Diagram
3.3.2 Actor Description
Client: This is the primary actor for the system. The person who is using the MVS Client side application.
Server: This is also the primary actor.
3.3.3. Use Case Description
1.Start
Transmission
Course of Events:
|
||||||||||||||||||||||||||
2.
Stop Transmission
Course of Events:
|
||||||||||||||||||||||||||
3. Display Limit
Course of Events:
|
|||||||||||||||||||||||||||||
4.
Start Server
Course of Events:
|
||||||||||||||||||||||||||
5.
Stop Server
Course of Events:
|
||||||||||||||||||||||||||
6.
File Sharing
Course of Events:
|
|||||||||||||||||||||||||||||
7.
Disconnect
Course of Events:
|
||||||||||||||||||||||||||
8.
Display Modes
Course of Events:
|
|||||||||||||||||||||||||||||
Chapter 4
The design
4.1. UML Structural Diagrams
4.1.1.
Class Diagram
4.1.2.Component Diagram
4.1.3.Package
Diagram
4.1.4.Deployment
Diagram
4.2 UML Behavioral
Diagrams
4.2.1.
Activity Diagrams
Client
Connection
Server Connection
Client Screen
capturer
Mouse move sender
Send Key Events
Receive File
Send File
4.2.2 State Diagrams
Client
Server
4.3. UML
Interaction Diagrams
4.3.1.
Sequence Diagrams
Connection Establishment
Taskbar menu
Transmission
Client
Transmission
server
File Transfer
Add Client
Window
Chapter 5
Implementation
5.1 System Implementation:
The
MVS System consists of multithreaded applications which are used to communicate
with each other over the network through their operating system environment by
using a Java Virtual Machine (JVM).
Implementation is divided into two main categories.
· Server side implementation
· Client side implementation
This diagram illustrates a portion of
the functionality of our collective System. This diagram only covers the
initial concept behind our system. Now we will discuss each application
separately to elaborate the implementation of our system.
5.1.1
Server Side Implementation:
Our
Server Side is divided into four parts:
· The main part
· The Window Components
· Remote Transmission Handler
· Input Event Listener and Sender
The Main Part of the Application
consists of the Parent Frame and the Connection Handler which holds and manages
all of the clients connected or are being connected with the Server
Application. The Parent Frame reorders the client windows and maintains a
layout for them for each operation occurred, apart from that the Parent window
performs window modes such as Widget Mode.
The Connection Handler waits for new
client connections and allocates exclusive communication ports for each client
(provided the clients are within the limit of the user) and sets up a receiving
server socket on that port. For each client lost due to disconnection, either
requested by the client or any other network issues such as client unreachable
, the server removes all the components used for communicating with that
certain client and
The Window Components Consist of the
Panel used to record mouse movements to be transmitted to the client to whose
window it belongs. Similarly it consists of Internal Frames which are
associated with each client successfully connected to the Server Application.
Remote Transmission Handler Works is
used to receive the Image Data from the Client Application and relay it to the
respective client window’s panel component.
Each Client window has its own Event
Sender Component and its own dedicated Events list which is sent by the sender
to their respected client over the network until and unless all the list
elements are empty.
The panel component uses three different
listeners.
· The Key Listener
· The Mouse Listener
· The Mouse Motion Listener
These three events are used to handle
the input received over the panel through the keyboard or mouse interface. For
each input received the data is sequentially inserted into the event list so
that the Event Sender can process and transfer it over the network.
5.1.2
Client Side Implementation:
Our
client side mostly consists of four parts:
· Screen Capturer
· Transmitter
· Event Handler
· File Sender
The Screen Capturer is a simple robot
class function which captures the display environment’s data and updates it
over the data to be transmitted. This is a repetitive process. The remote
object transmitted in the client end is only created once and is repetitively
overridden. This specifies that the data sent is not dependent upon the client
push or the server pull but as it is constantly being updated the client node
will send whatever is the recently updated form of image within the remote
data.
The Transmitter transmits this data to
the port assigned by the server to the client application until the server has
stopped or the user. If the server is stopped or is unreachable the client will
revert to its previous state and will relocate the client and request for a new
port for reconnection. After each reconnection the client will receive a new
port number and will initiate the transmitter once again to restart the
procedure of data transferred between the client and the server.
Event Handler is the component which
handles a list of instructions transmitted by the server and iteratively
executes it by performing them on the Operating System using the same Robot
Class that we used to capture the Image in the first place. The instructions or events list is populated
by the Event Receiving thread which receive the events sequentially from the
Event Sender from the server and implements it.
The
client also holds a Message Listening Port which is exclusively set to port
6060. This is created whenever a connection with the client is accepted, in
order to get instructions such as to close the client application or to send a
file from the client machine to the server. This Message Listener opens a
dialog box for the user so that they can view it from their respective child
window from the server application and select a file to be sent by the client.
Once the server selects a file, the file is sent over the port which is 200
times greater than the port assigned by the server and so the file is sent over
it.
Chapter 6
Testing &Evaluation
6.1. Verification:
This is an activity to verify whether we have built the system
right or not in the
development life cycle.
6.1.1
Functional Testing
Below are some of the test cases, verifying the system functional
abilities.
Test Case 1:
|
Test Case: Start Server (MVS Server) |
||||
|
Description:
The
User Selects Start Server Option |
||||
|
Data Requirement: None Required |
||||
|
Step No. |
Step Description |
Expected Result |
Transaction Name |
User Think Time (in Seconds) |
|
1 |
User clicks Server Menu |
Server menu shows menu Items |
Server_Menu |
5 |
|
2 |
User Selects Start Server |
Server is Initiated |
Server_Initiation |
5 |
Test Case 2:
|
Test Case: Stop Server (MVS Server) |
||||
|
Description:
The
User Selects Start Server Option |
||||
|
Data Requirement: None Required |
||||
|
Step No. |
Step Description |
Expected Result |
Transaction Name |
User Think Time (in Seconds) |
|
1 |
User clicks Server Menu |
Server menu shows menu Items |
Server_Menu |
5 |
|
2 |
User Selects Stop Server |
Server is Stopped and All clients are disconnected |
Server_Disconnection |
5 |
Test Case 3:
|
Test Case: Display Limit (MVS Server) |
||||
|
Description:
User
Selects Child Display Limits |
||||
|
Data Requirement: None Required |
||||
|
Step No. |
Step Description |
Expected Result |
Transaction Name |
User Think Time (in Seconds) |
|
1 |
User clicks Window Menu |
Window menu shows menu Items |
Window_Menu |
5 |
|
2 |
User Hovers Cursor over Display Limit |
Display Limit shows submenu Items |
Display_Limit_SubMenu |
5 |
|
3 |
User Selects a Display Limit SubMenu Item |
If the connected Clients are lower than the limit then the limit is asserted or else the User will be asked to close clients first |
Child Display Limit |
|
Test Case 4:
|
Test Case: Widget Mode (MVS Server) |
||||
|
Description:
Resizes
and relocates the parent window and reorders the Child windows |
||||
|
Data Requirement: None Required |
||||
|
Step No. |
Step Description |
Expected Result |
Transaction Name |
User Think Time (in Seconds) |
|
1 |
User clicks Window Menu |
Window menu shows menu Items |
Window_Menu |
5 |
|
2 |
User Clicks Widget Mode Menu Item |
The Parent Window is resized and relocated |
Widget_Mode |
5 |
Test Case 5:
|
Test Case: Start (MVS Client) |
||||
|
Description:
Starts
the Client Application functionality |
||||
|
Data Requirement: Server IP Address |
||||
|
Step No. |
Step Description |
Expected Result |
Transaction Name |
User Think Time (in Seconds) |
|
1 |
User clicks Start |
The Application searches for the Server Application on the network |
Start_Client_Transmission |
5 |
Test Case 6:
|
Test Case: Stop (MVS Client) |
||||
|
Description:
Stop
the Client Application’s Capture Component |
||||
|
Data Requirement: No Data Required |
||||
|
Step No. |
Step Description |
Expected Result |
Transaction Name |
User Think Time (in Seconds) |
|
1 |
User clicks Stop |
The Application will stop the client’s screen capturer. |
Stop_Client_Transmission |
5 |
Test Case 7:
|
Test Case: Disconnect(MVS Client) |
||||
|
Description:
Starts
the Client Application functionality |
||||
|
Data Requirement: No Data Required |
||||
|
Step No. |
Step Description |
Expected Result |
Transaction Name |
User Think Time (in Seconds) |
|
1 |
User clicks Disconnect |
The Application will disconnect the client from the Server Application. |
Disconnect_Client |
5 |
Test Case 8:
|
Test Case: Enter Server IP (MVS Client) |
||||
|
Description:
Enter
New Server IP |
||||
|
Data Requirement: No Data Required |
||||
|
Step No. |
Step Description |
Expected Result |
Transaction Name |
User Think Time (in Seconds) |
|
1 |
User clicks Set Server IP |
The Application shows input dialog box |
IP_Input_Dialog |
5 |
|
2 |
User Enters IP |
Application saves and overrides server IP |
Save_IP |
5 |
6.1.2.
Static Testing
Software coding is checked for any type of syntax errors and other
logical ones. It is
verified that system is in a stable condition and, will alert the
user if he/she is
performing any action whose prerequisite is not performed and will
not fail in any
process.
6.2. Validation
This is the activity to validate that we have built the right
product, in scope and
according to the requirements. It is validated that all the system
functions are in scope
and are same as defined in the requirements analysis phase.
6.3. Usability Testing
Usability testing is a
technique for ensuring that the intended users of a system can
carry out the intended
tasks efficiently, effectively and satisfactorily. The system is
tested in terms of
usability and results have shown complete success.
6.4. Unit Testing
Every module of the
code either it is server side or client is tested separately after
specifying some real
world scenarios. We have tested almost each part of the system
continuously either it
is big or small. After doing unit testing we can safely state that all
the units of the whole
system are in working condition.
6.5. Integration Testing
After the success of unit testing, we integrated each and every
module together and
made the final shape of the system. Then again we started testing
the system over some
real time scenarios and meet success in every scenario.
6.6.
System Testing
We implemented and tested our MVS application on Netbeans. System completely stable and operational on this
platform.
Future Work
Our current solution is still sluggish while
handling multiple clients on account of the server’s processing power. If
future researchers will implement our solution or a similar solution using our
approach they might be able to optimize the current proposed solution by
proposing better thread management scenarios and image processing solutions.
This solution will certainly help in creating new and better remote
connectivity solutions and will help in the advancement of networking
environment as a collective.
Chapter 8
GUI
8.1 MVS UI:
8.1.1
Normal Mode
8.1.2
Widget Mode
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.