This course to me is like huh! a BSD compiler that sucks and confusion of design concepts in different versions of BSD, since we follow freeBSD 4.4 in class and we do projects on 4.1BSD. yes, there is a formidable difference...double check with the issues below with a trust worthy source.

 

 

 

 

People might think that I am having a great time going out, visiting places and having fun in life then you might want to reconsider your thoughts after looking into this. Buying a car is easier than doing this project, imagine doing both. I submitted this project and gave away the car. Both of gave me problems so I decided to dispose();

 

http://www.filelodge.com/files/hdd2/18664/Graph%20Abstract%20data%20type.zip

 

Purpose:

This project requires you to build a graph class, using adjacency lists[1].  In Project #3 you will provide functions to evaluate a graph’s transitive closure, strong components, and order a directed acyclic graph’s nodes with a topological sort.  You will find the references below[2] to be very helpful for Project #3.  Please note that your submission should demonstrate all of the functional requirements with explicit tests and output.

 

There are two purposes motivating this project.  The first is to give you practice using STL containers and iterators.  The second is to show how a sequence of modules can cooperate to provide some major functionality.  The results of this project combine, in a very natural way, with the dependency analyzer you built in Project #1, to evaluate dependency structure of a large complex system.  Project #1 provides the basic direct dependency information, while this project can be used to investigate indirect dependencies and mutual dependencies as well.  You are not asked to make that combination in this project.

 

Requirements:

Your Graph program:             

1.       shall use standard C++[3] and the standard library, compile and link from the command line, using  VC++ 7.1, as provided in the ECS clusters and operate in the environment provided there[4].        

2.       shall use services of the C++ iostream library for all input and output to and from the user’s console[5] and C++ operator new and delete for all dynamic memory management.             

3.       shall implement a graph class, based on adjacency lists.  The adjacency list representation shall use at least two STL containers, and access their elements using iterators.  The graph class shall implement vertex and edge insertions and deletions.      

4.       The graph class shall use template arguments that specify types to be associated with vertices and with edges.  This would support, but not be limited to, associating string names with each vertex and edge.  You are encouraged to provide any traits and policies you think may be useful for user’s of your graph class.     

5.       The graph module shall provide a function that displays the adjacency list representation of any specified subset of a graph’s vertices, using some suitable formatting process.         

6.       The graph module shall provide a function to carry out depth first traversal.  The depth first traversal function shall accept a reference to an abstract operation class.  Applications will derive from this to carry out operations on each node visited.  This operation hook will be useful for demonstrating that you meet the other requirements by displaying visited nodes.             

7.       The graph class shall provide an iterator for the graph class that supports Depth First Search (DFS).               You may use this iterator as part of the implementation of the requirement above, if you wish.  

8.       The graph module shall provide a function to build one or more named graphs from an XML file.  A sample of the file syntax is provided below.  The function should return a collection of references (pointers or iterators) to each of the graph objects built.  You will use the references to conduct tests to demonstrate that requirements #3 - #7, above, are satisfied. 

The XML file format should use the following syntax (you should test graph<string,string> and graph<string,double>):

 

          <? xml version=1.0 ?>

         <graphs name=”Project #2” author=“Joe Code“>

           <graph name=”g1” application=“test1“ vt=”string” et=”string”>

             <v num=”1” vtv=“v1“><e num=”1” etv=”e1”>4</e><e num=“2“ etv=“e2“>7</e></v>

             <v num=“2“ vtv=“v2“><e num=“3“ etv=“e3“>5</e><e num=“4“ etv=“e4“>7</e></v>

             <v num=“3“ vtv=“v3“><e num=“5“ etv=“e5“>1</e></v>

             <v num=“4“ vtv=“v4“></v>

             <v num=“5“ vtv=“v5“><e num=“6“ etv=“e6“>6</e><e num=“7“ etv=“e7“>7</e></v>

             <v num=“6“ vtv=“v6“><e num=“8“ etv=“e8“>2</e></v>

             <v num=“7“ vtv=“v7“><e num=“9“ etv=“e9“>3</e></v>

           </graph>

           <graph name=“g2“ application=”test2” vt=”string” et=”double”> ....</graph>

         </graphs>

This was my first project in syracuse University. I sucked at this but later when the grades came I realized that I am not bad.......My first hand on such a project.

http://www.filelodge.com/files/hdd2/18664/Filedep.zip

 

Purpose:

When a team develops a large software system, management of file dependencies is critically important, due to the need for almost constant change.  Changes occur due to latent errors, performance problems, changes of requirements, and changes in design.  Files are the unit of change management and are the entities we deal with during unit test.  When we test a file it is important that the tested file depend only on already tested files.  Dependency defects, like mutual dependency and dense dependency relationships make change and test very difficult.

 

This project requires you to build a program that accepts a path and a set of file patterns on the command line, searches the directory tree rooted at that path, and analyzes each source code file found for its type-based dependencies on other files.  That is, the FILEDEP program finds each type declared and defined in the file collection of all analyzed files, then discovers all the Files that use the name of that type.  When analysis is complete, FILEDEP must show each file in the analyzed set, in alphabetic order, and after the name of each file show all the files on which it depends:

 

You should support fully qualified file names[1].  That is, show the path and file, like this:

 

            C:\homework\filedep.cpp

                        C:\homework\fileInfo.h

C:\homework\fileInfo.cpp

…

 

There are several interesting issues to think about.  Should you scan files and do analysis iteratively or recursively[2]?  In a single pass or in multiple passes?  Should you show types in the standard libraries and system libraries?  Note that you can’t follow the relationship chain into those libraries, as you don’t have their source code readily available.

 

Requirements:

Your DEPENDS program:

1.       shall use standard C++[3] and the standard library, compile and link from the command line, using  VC++ 7.0, as provided in the ECS clusters and operate in the environment provided there[4].          
           

2.       shall use services of the C++ iostream library for all input and output to and from the user’s console and C++ operator new and delete for all dynamic memory management, if you use any.       

3.       shall accept, from the command line, a path name to begin searching for files, and a set of one or more file name patterns[5].           

4.       shall display the ordered set of all source code files found in the tree rooted at the given directory path.           

5.       shall display, on the lines below each file in 4., the set of files on which it depends. 

 

Note that #include relationships are not strong enough to establish a dependency.  It occasionally happens during the evolution of a module that it may cease to depend on some other file due to changes made in its source, while the #include is inadvertently left intact.

                             These are few requirements that I had to implement for my Internet Programming Final project. I had a tough time not because it was this was too much of work or because i had to implement  this with ASP.NET but because I used the BETA version of Visual Studio Web Developer 2005. My fellow team mate was using Visual Studio 2003. We had 3 restless nights just to integrate our works on Visual Studio 2003 though both of us completed our job way a head of the deadline. Did we succeed?? guess || and try it out.

These were the requirements my professors posed to us:  The link to the code below has 2 part one project1a by me and project1b by SHREYAS my team mate.
http://www.filelodge.com/files/hdd2/18664/IP.zip

Purpose:
You are a consultant, often traveling to customer sites to discuss projects you are working on for them.  You need to be able to download Visual Studio Projects from your remote web server, demonstrate program operation , make customer suggested changes at their site, and upload the modified project to your server.  You also need to track bugs, record notes for future modifications, schedule future meetings through a web calendar, and write draft project specifications, all at customer sites and uploaded to your server.  You want to do all of this through an attractive web site that will impress your customers.

Requirements:
The requirements for this web site are to provide: 
1. Login access that forces a link to any page to verify that you are a valid user, by checking the current session to see if  you are currently logged in, otherwise redirecting you to a login page.  Please develop a user control for this that you will make part of every page.
2. Multi-file download and upload facility that manages the transport of any Visual Studio project between the server and your local machine.  Please use a web service to support this requirement.  Note that you can start an application on your laptop from a web page served to your laptop.  The application, in this case, is a client of a web service provided by your server.
3. A control on the file transfer web page that starts Visual Studio with the downloaded project.  To do this you will need to run msdev with appropriate command line arguments.  You will also have to configure your laptop so that it trusts your remote server .
4. A bug-tracker page that uses a DataGrid control to display, edit, add, and delete bug notes.  Each bug is allotted one line of the Grid display, but when double clicked will popup a form with details.
5. A notes facility that supports the display, editing, addition, and deletion of business notes.  You are encouraged to use code shared with the bug-tracker, but must support a different layout for both the Grid and popup displays .
6. A meeting scheduler that uses the .Net calendar control, and supports two levels of scheduling: recording and editing scheduled events that only your login allows, and requested events that are recorded through login accounts you make available to your customers and secretary.  Scheduled events and requested events should appear differently on the calendar (color coding is acceptable).  You should be able to convert a requested event to a scheduled event, from your login, using only a mouse click or two.  Each event must support the addition of background text that is accessible from a popup text screen by double clicking on the event.  Anyone accessing the calendar can access this information, e.g, you, your customers, and your secretary.  Please support all the data handling and role models for the calendar using a SQL server relational database.
7. A form used to record a draft project specification.  The form should provide the following:
a. Title
b. Customer name and address
c. Topic
d. Date
e. Itemized list view with full editing capability.  Each item is one requirement.
f. Free form text block at the end for notes.
8. The site is to be constructed using Asp.Net applications.
9. Use, and demonstrate that you use, ideas and contents of at least one of the papers, linked below.
 
Because this project is fairly ambitious you may work with one other person, if you wish.

Operating System 4.1 Free BSD

Let me not Blah Blah ... about how OS works what does what etc.. Let me zero it down to the design and few important issues which makes the design clear.

The link for the files in which the code was modified i.e kern_synch.c and kern_exec.c this link is a ZIP file inside it is a tar file. Unwrap the tar file to see those 2 files.

Note: This is just about okay as for as FSP idea is concerned. Its is not completely implemented.

 

Note: Fair share processes are given FAIR(key word) and a number(percentage the process is seaking) as arguments.

Eg:-   ./a.out FAIR 30

 

(no % symbol after 30.)

 

I implemented this  by modifying the roundrobin by hardcoding the cpu percent usage using unused arrays in proc.h file.
if a process id is not 0 and if the process is a user process then (p->p_usrpri = 127 ) we set the priority high so that it sits at the end of the queue. if not we assign a normal priority which keeps it ready to run. In kern_fork() we have hardcoded the priority value to a constants here in our case 40. The same is done in vfork and rfork to make sure that the child process get the same allocation(even though it takes the default values from parents.just in case).

1. [How can you identify a process as a FSP process and how can you assign the share to the process?]

All the processes that run in my User space are considered as FSP processes. If the user id of a process is equal to my user id of a system call, we consider that process as a  FSP process.
 We used the p_pad1[] array to actually store the value of the cpu percentage that has been allocated to a FSP process.

2. [How will you ensure that 50% of the CPU cycles will be dedicated to guaranteed processes? It is not essential that exactly 50% of the time is dedicated to the guaranteed processes, but over a significant time, say a minute (that is 6,000 time slices), the percentage shouldn’t deviate by more than a percent or two for processes that have been ready to run throughout that time period.]

We implemented an if statement in the roundrobin algorithm and then there is a comparision of the effective user id of the process to our groupid. if there is a match and the amount  of cpu percentage that has been allocated
is actually more than what had been demanded then the process priority is set to minimum. so the process would give the cpu.

3. [Over what window of time will you maintain the balance, and how will you account for process sleep times? The window should not be too large, else you will get into a situation where a process that may have slept for a long time will fall so far below its expected allocation of CPU that it would need 100% of the CPU for an extended period to make up the difference. You should pick a window of time and maintain CPU time histories for each process over that period.]
A window could be maintained for 1 sec. A process which is still in execution and has a priority less then the sum of other executing processes it sleeps and there is a roundrobin between process of same priority. If a procesces sleeps more then a sec it gains priority and gets it share the next second.

4. [How can you verify your solution within the current framework? You should write a few test programs. Some of the running processes in the system should be FSP processes and some should not. You must print necessary scheduling information either on the screen (which we prefer, for demo purposes) or in the kernel log.]

we can test the process by running a few user programs with the userid as our userid and then making some other user login into the same computer so that the userid is different for this user. so we can actually have two
kinds of processes running.

I thought of posting the actual documents <links> to the OCD's of Code Generator and Remote Testbed system.

 

1.OCD for Code Generator.

    I implemented a prototype of the privious OCD the link for that is below. Note: This is just a prototype which gives a glimpse of most of the features discussed in the OCD of code generator.

   

  Code for CODE GENERATOR Guess what? I coudn't Generate code for this

 

2. OCD for Remote Test-Bed System

   As I said the code will come here....so here it is.

May be due to many modules inside, people might get confused with execution but you shouldn't have problem if you have read the OCD and the comments in the code. Anyways. run the executable in RTestBed folder this is client's GUI. Run the executable in SERVER folder. Yup!!it is server ... GUI is ok enough to take you through.

I dont believe in beatification so the GUI might be not pleasing but you might want to look at how things have been implemented rather than how it looks. I am too lazy for that. I am always known to get my work done than perfection. As they say "Nobody is Perfect" not even the moon.

 

 http://www.filelodge.com/files/hdd2/18664/RTestBed.zip

 

 

 

   

We need to build a message passing system with queues on top of Remoting. The advantage of having a message passing system is all communication between the client (Test Master) and server (Slave) is in XML messages.

 

<RequestMessage>

<MessageType>TestRequest</MessageType>

<ClientIP>IPAddress</ClientIP>

<ClientPort>PortNo</ClientPort>

          <Tests>

                <Test>filename1</Test>

               <Test>filename2</Test>

</Tests>

</RequestMessage>

A server or a client request for a remote test machine, including the test files to perform tests on. Now the client has decodes the xml file and understand the command with the key work ‘RequestMessage”.

<ResponseMessage>

<MessageType>Testresult</MessageType>

            <Testname=”Testname1”>Contents1</Testname>

            <Testname=”Testname2”>Contents2</Testname>

</ResponseMessage>

Client sends the requested component. Encodes the result of each test contents and sends it back to the Server(Peer) who requested for the component

<Command>

<Command>Getconfig</Command>

<ClientIP>IPAddress</ClientIP>

<ClientPort>PortNo</ClientPort>

</Command>

Client sends the command type message to get  a specific task. A lot of xml messages has to be built and both the server and client must have the decode and encode functions to communicate.

 The server contains a single remotable object that implements a function ‘getMessage’. This function simply receives messages from all clients and places them in a queue. The messages of course need to follow some fixed format to allow the server to interpret each message distinctly. The clients of this server in turn need to implement a single ‘postMessage’ function that accepts a message string and places it in a queue to be sent to the remote server. This method ensures that neither the client nor the server has to wait for request and response, making the communication asynchronous. The diagram shows how the asynchronous communication between 2 Rem-test peers will take place. This layer is built on top of the Remoting layer.

 

The communication subsystem needs to use .Net threading also. The client that wishes to communicate with the server embeds the function call inside an XML message. This message is then placed in a message queue by the main process thread. These messages are pulled off the queue at the other end by the send thread and sent over the communication channel to the server. At the server end, there is a receive thread that keeps receiving messages from the client and placing them in a common queue. The main processing thread then removes the message from the other end of the queue, parses it, and makes the corresponding function call. The result of the call is embedded in an XML message and it goes through the same steps to get back to the client.

For synchronous communication, we build another layer on top of this layer. The only difference would be the send thread would block on a response from the remote object, instead of going ahead with its processing. Once the receive thread receives a response, the send thread starts sending again. Thus the communication system discussed above allows the peers to communicate synchronously as well as asynchronously.

Activity Diagrams:

 

                        Activity Diagram for Server i.e. Test Master

 

In the above diagram the server runs a test, First it load and processes the configuration file. It can run test on itself or distributes the load to the clients. If it wants to run tests on the same machine, it simply loads DLL gets the test collection sorted and runs the tests. The result is displayed on GUI. If it wants to distribute the load then it connects and send commands to the client. The tests are run on the remote machine and the results are sent to the server or the dependent module.

 

                                    Clients Activity Diagram

In client activity diagram we could see that it behaves in 3 different ways. When it acts as a test slave it gets the commands from the server loads required library to run the processes and sends the result back to the server retaining a copy for itself. A user at the client level has two options one to test his own module on the local machine which is called the Sand-alone mode. In this case the user has a already configured file which he uses and runs the tests. In the test master mode a user can test other modules other than his which are related to his module. He could configure the remote machine as the server has done. NOTE: the X in the above diagram means the test Master mode of the client. Its behavior is the same as the server.

 

Critical Issues:

 A remote test-bed system is no exception when it comes to critical issues.

Communication protocols:

When there are two computers communicating, the set of protocols the two follow must be very clear. In some cases when a system send a command or a message to the other system. It may understand the command but could not process the information due to insufficient information. It is very important to have a good send received acknowledgement which is state bound. With remoting we can use protocols like TCP, HTTP which are well designed and fits to our project requirement. Since we run tests on remote machine and if there is a connection loss, the test machine should finish the test and send it to the server when the connection is reestablished. In a network these things happen very often. We should also be able to handle situations like system overload, slow testing, multiple threads etc. These problems are critical when these issues are not considered during design.

Testing Problems:

The above application gives the user to pause or cancel the test running. In such a situation the application should act intelligently by storing the test status, number of test that passed and log them properly into the logger. A half run test should not be discarded.

In case of pause it should hold the current state till the process is resumed and all the dependent modules depending on the strength of the bonding should be paused or let run.

Since the server keeps getting the status every run it knows when a problem occurs and has to display that to user explicitly.

Errors:

General errors may crash the program. Properly unhandled threads crash the program with out a hint. Better error handling be should be implemented. All vulnerable code should be enclosed in try, catch/throw blocks.  Finalize statements should also be used to properly close open files, threads or resources.  Great care should be taken to avoid data access conflicts between threads. Error logger on the screen should be precise about connection failure or data corruption.

Performance:

A test-bed system is really useful when it performs on a machine with out overloading it. Since this application runs many test on the system it should be capable of handling many threads, communicates with the clients and transfer and uploading of the logger contents. This is a lot of work and a good system with a good configuration might not work properly. Test bed distributes its work with the clients but still the performance of the system might slow down slowing down the testing invariably. The only way to solve this problem is to upgrade the system.

DLL’s:

When a testing is done on some machine, instead of compiling the whole test program sending the DLL to the system will help in saving resources but the remote system might now know how to use the DLL’s. In such a situation a message should be attached to file saying what is to be done with the file.

Blocking queues:

A blocking queue is usually used on the client side to hold messages in the event that communication with the remote receiver fails and to free the main thread of the client so it can do other tasks. Likewise on the server side, in addition to separating the main thread from the communication thread, one uses a blocking queue to quickly remove messages from the socket buffer so that the socket buffer never fills. This kind of set up is more suited for asynchronous messages. For synchronous messages or direct calls, one does not need to have queues because the client calling thread has to block until it gets a response from the server so there is no risk of accumulation of messages and in the case of a network failure the client calling thread has to wait anyway. Remtest uses both kinds of messages. Moreover all messages ends up being collected by MsgHandler object on the server side. Which then discern their type and either processes them if they are asynchronous or hand them over to adapter if they are synchronous. Because of that one can have no blocking queue on the server side as for synchronous calls the enqueuing of messages in not needed. Only AsynMsgHandler (client) would need to have a queue for that.

Problems with threads:

Each system is going to be running several REMTEST instances with each instance having two to four threads. When running multiple threads on a single system two important issues need to be taken into account. One is deadlocks, and the other is the use of virtual memory. Deadlocks are pretty difficult to resolve and the system must be kept simple to prevent them.

Versioning:

In case if the server is testing the code and a user changes the code on his machine. There will be two different versions running. One the system testing and other will be the new version, the reports generated may be of the older version. In this situation all the code running in client, server and other remote clients should be stopped and the server should be informed about the new version of the code. This won’t help a big deal if we need the older version for some reason, in that case  the server has to take a decision and should store the old version with all its information in log file and create a separate folder for each version and each machine for each module.

Summary:

In this document we have discussed the need of  Test-bed system, who will use it, outline of what is expected and some issues that has to be carefully thought about. With few prototypes of how a GUI looks it gives the designer, architect a clear picture of what the requirements are. The remtest-bed system is broken down in to simple modules for better understanding and the activity diagram shows the behavior of this system in different roles in different situations. A careful thought is need in case of communication protocol settings and configuration files.

 

 

 FoR DIAGRAMS REFER TO THE PHOTO ALBUM LIST

 

 

 

 

 

 

 

REFERENCES

• www.ecs.syr.edu/faculty/fawcett
• Remote testbed by Rohit Misar
• Remote test harness by Sidharth Mulchandani

• Remote synchronous test harness by Ravi Ranganathan

Acknowledgements:

 

1.      Dr. James Fawcett, Instructor, CSE 681

The information could include the IP address of the remote system where the module is located and the port number where the server of that remote module is listening. These can be stored in a file. This file is not going to change often but should be capable of being changed easily by the user.

Use cases:

1. The user would initially need to configure the information of all the modules that it depends on. All this information can be stored in some network configuration file which can be opened and edited by the user.
2. The user can start a series of tests. The configuration of these tests is stored in configuration files which specify the location of the tests, the logging options and options for specifying the lower level modules that should be tested.
3. A user can ‘pause’ the test that is initiated by that particular remtest. This implies that the tests that were initiated on a remote machine by the test-master should be capable of being paused.
4. The user could resume the tests that were initiated by that particular remtest. This implies that the tests that were initiated on a remote machine by the test-master should be capable of being resumed.
5. The user could ‘abort’ the tests that were initiated by that particular remtest. All the tests that were initiated by this test-master including all those tests in all the test slaves should be capable of being aborted.

Test slave mode:

In the test slave mode the client machine receives the command from the test master in the form of Xml messages which is to be decoded and executed. The command can be to load new DLL and run files or start, stop or pause commands. When the command to report the test results come in the clients keeps a copy of test for it self and send one to the requesting machine.

Graphical user interface:

GUI is an interface where the user interacts with the system. A server, as in the figure shows the test modules which can be selected using a checked box list. A task pane that has mode, module and progress pages. The mode shows that the server is running 2 modules on a system on a system with ip address 123.53.23.22. A pause and start button to stop and pause the testing anytime. A stand alone mode is used when a module in the system itself is what to be 

                                    Server Remote Test bed

On the client side we have a similar interface with test master mode, stand alone mode and test slave mode. A client can run a test on itself in a test master mode. It can also run processes on remote machine with test master mode and tests get tested on itself in test slave mode.

Test slave processes In the task pane shows the processes being run in the background which is actually initiated by the server. The display progress in detail button shows how each is running what are the dll used and file transfer and test result. 

A server should be able to get all the test results update and the stop and pause button can stop and pause each module being tested on remote machine. This is in the task pane called progress in task pane.

Analysis:

Load analysis: At any given time several instances of the test harness can be executed on a single REMTEST by different users. This implies that several threads would be running at once independent of each other, which would drastically increase the time taken to run a single test. The x-axis of the above graph represents the number of test harness threads that are going to be running at a given time and the y-axis represents the net time taken to execute a single test.

 

If a user sitting at his system is running local tests on the modules that he has modified, and some other remtest module is using his machine as a test-slave, he would have to wait for a long time for his tests to complete as the processor is being used by other remtest.

Security: The remote test-bed is capable of causing a security breach in a company’s network, if the network is not properly configured.  The network then can close the network port, which is allowing the remote machines to communicate to the test master.  If the remote system is handling requests from the test masters and network breach causes the port to be shut down.  This would cause the test master to wait and perhaps time out and not successfully finish that test.  One security concern is that if network addresses are not correct or not properly configured if we are dealing with sensitive tests where test results are not to be disclosed.  That would be a major security breakdown.  There should be a database or some sort of check to make sure the addresses that are being used to connect to and from are valid and are supported by the remote test-bed system.  In other words, the networking element must be pre defined.  A secure routing table would be ideal.  This is especially critical when dealing with large distributed systems like Missile Defense systems.  Also, another concern is that the test results should be constant or write protected.  We do not want an intruder on the network if they are probing a specific port to be able to modify the test results. The network administrators have a big role in security for the remote test-bed. 

 

Cost: The cost of the remote test-bed system depends on how much the cost is for network security, network bandwidth, and possible upgrades for remote and local test machines.  The software that will be needed to secure the network should be installed on the network by the administrators.  The network bandwidth depending on what kind of connection is required might be the biggest expense for the remote test-bed to work efficiently. If the teams are located in the same building a simple intranet would be required.  Another cost might be a possible upgrade for the remote test machines.  If it turns out that the remote test machines performance is poor due to rigorous testing and intense test data then it would be practical for the development team to reconsider the hardware platform the system is operating on.  The systems must be ready to handle worst case scenario and while the worst case is being handle the CPU load should not exceed the benchmark set by the development team.  If it does, an upgrade should be strong considered. 

Context Diagram:

 

         The test master accepts the start command from user and provides a GUI to the user through which user generates events. Since it is a test master the user can select what test module to test, on which machine, code distribution with related libraries and communicates with the test slave i.e. client via a communication schema which is message passing using Xml. The details of the clients and their test code are stored in a Xml file in the file handler module along with the configuration file. The results obtained from the client is will be displayed to the user in the view form and saved in a file in the file handler.

         A client can act as a test master, test slave and stand-alone. We have seen how a test slave works. In stand alone there will be a test harness option which tests the module in the local machine. All the information regarding this will be stored in a configuration file which is used to run the test with out doing much of the changes. This option is like a ready to run option where the user just clicks on one button and testing of the local module stops and the result is displayed via GUI. A developer may want to run these test conditions several times on his code.

         A Test master mode works simply works like a server but it won’t have configuration files of the whole system. Thus a few dependent modules and their system code and test will be available to a local machine and it can perform server type options only on those machines.

 

Module Diagram:

 

                                    Module Diagram with User Options

Graphical User Interface:

This is the module that interacts with the user of the system. It can be considered as the entry point into the system when running as a test master. The module allows the user to select the tests to be executed, both on local and remote, or open an archived log file. The module simply passes the information about the test to be run and related logging option to the Test Aggregator module. In case of the user selecting the option to open a logged file, the module uses the File Handler module to open the XML file and display the contents in the UI window.

The two main responsibilities of the user interface modules are to allow user to input commands into the test masters and eventually influence the remote test machines.  The second responsibility is to give user a visual representation of the results.  Even though it may not seem as if User Interface does much of any processing, but it is the only module that user interacts with.  Also the user interface allows the users to clear the results display.

Test Aggregator:

The test aggregator module can be considered as an executive module of the test harness. It receives commands such as start test, pause test, resume test and abort test from the remtest executive. To execute tests it needs the configuration file to be setup. This configuration file will have a path, where it searches for tests in DLL files that are derived from the standard interface and executes them. It should have a list of all the tests which are executed one by one.

Test Master: This module is the executive module of the Remote Test-bed system.  It is responsible for processing the configuration file, initiating testing, and supporting commands such as start, pause and abort on user’s request and collecting reports and rearranging log files.

Stand-alone mode: In stand alone mode the user test the code in its machine and he may like that code to be tested with just one click of the mouse button.. To provide this feature it is proposed that the test harness would get all the required information from the user in the form of a configuration file. The file that was last used will be opened and the tests can be executed by clicking a button. Otherwise, the user would have options to modify the configuration file through a graphical user interface.

 

Test slave mode:

In the test slave mode the client machine receives the command from the test master in the form of Xml messages which is to be decoded and executed. The command can be to load new DLL and run files or start, stop or pause commands. When the command to report the test results come in the clients keeps a copy of test for it self and send one to the requesting machine.

Test code module:

This module contains the main test code. The module contains a test function that is invoked by the Test Aggregator module each time Run Test is called. The module in turn calls the Test Data Generation module, the Logger module and the Client module. The Test Code module gets the data to execute the test from the Test Data Generation module. It then uses the Logger module to log the results of the test to either the console or memory or a file. This module uses the Client module when it has to invoke functions synchronously on remote machines. The test results are then sent back to the Test Aggregator module.

Logger:

The input to this module is from the tester and the outputs can be directed to the memory, to a file or to the console. The logger is an output module which will receive the results of the tests from the tester and will be capable of putting the results either on the console, system memory or in a file on the disk as requested by the user. The logger will consist of a file logger, a console logger and a memory logger which will help to accomplish the required functionality.

 

Configuration Setup Module

 

This module is responsible for keeping test configurations for the test master as well as all the remote test machines.  The configuration file should contain the host name of the remote test system.  It should contain the MAC address of the network card and the IP address as well.  Once the administrators have setup the system properly no changes should be done without authorization.  The configuration file should contain the path to the test code and the files to be tested.  The configuration file is specific for each of the system.  Perhaps to add more decision making capability to the test master the test configuration file can contain the specifications of each of the remote machines.  A more robust remote testbed system would ideally have the knowledge of all the systems (local and remote) some on the fly decision making could be handled by the test master instead of having to pre-define a test configuration file.  As par for the project specifications the test configuration file will be a XML based file.

Communicational scheme:

 

The communication Scheme module is responsible for allowing the test master to send request to each of the remote machines and in case of a larger distributed system allowing each of the remote machines to communicate with each other.  In any case the communication layer should be reusable no matter who is communication on each side.  One practical way to implement such a communication scheme involves the use of sockets and message passing.  The sender sends the message either as XML message or binary data and the receiver get the message and decode the messages. 

 

 

Ideally we would like to architect the communication layer with a queue.  The sender has a queue which holds all the outgoing messages and the receiver has a queue in which it stores the incoming messages.  The sender should also have a queue allocated to incoming messages from multiple remote machines.  Each of the remote machines will also have a queue allocated to outgoing messages.  We essentially have two types of communication being implemented here:

• Asynchronous: results will be passed using this type of communication, where we do not wait till we get results.  They will be stored in the queue upon their arrival.
• Synchronous: the messages from test master will be passed down to the remote machines this way since we want them to take affect and the test master shall wait till the requests are properly executed.  

Test Vector Generator:

This module is instantiated by the test aggregator. The input to this module is from an xml file on disk and the output from this module goes to the application test, which is used to test product code.

The test vector generator is responsible for supplying the test with structured data as required by the functions of the project code. This test data will be stored in an xml file since the xml file helps to store the data in a structured manner. Hence the test data generator should have the ability to do some kind of xml processing to access these files and derive the test data from them in the appropriate format. This data is then given as an input to the application test.

 Communication Model:

The Remote Test-bed is a collection of tools running on different machines, and at the same time communicating with each other. A test master can invoke tests on the slave machine and also invoke functions on the remote module and get back the results from the function. Thus each Rem-Test consists of a client part and a server part. As a result, the communication model becomes the most important sub-system of the system. At almost every step of the system, there is communication between Rem-Test peers.

Remoting involves a protocol that one program can use to request a service from another program located on a remote system. The remote system contains an object that can be used by other machines. The local machine simply builds a proxy of the remote object and makes a call to it. The proxy in turn calls the remote object, gets back the results and sends it to the client. Although this is a very straightforward technique, it has some limitations. This model requires new functions to serve each new client request. It should be noted that we need to have synchronous as well as asynchronous communication between Rem-Test peers. For this purpose we need to build a communication system that can be used for both, i.e. make it reusable. The diagram below shows the basic remoting model.