US Software Capstone Design Project

GNAT - Graphical Network Analysis Tool

Design Document

 

 

Design Team:

Matt Ericson

John Kobinski

Matt Petro

Rob Waltz

 

 

Client:

Rich Ames, US Software

 

 

 

 

v1.2

January 1, 1998

Last revision: 1/29/98

Table of Contents

Executive Summary *

1. Software Design *

1.1. Context level diagram *

1.2. Data Dictionary *

1.3. OMT Diagrams *

Object Model *

Dynamic Model *

Functional Model *

2. Preliminary Schedule * 2.1. Gantt chart *

2.2. PERT chart *

3. Preliminary Test Plan * 3.1. White box test strategy *

3.2. Black box test strategy *

 

Executive Summary

 

This design document is the culmination of the US Software team’s design effort over the past three months. The document contains the complete contents of our object modeling work, which covers object, functional and dynamic modeling of the Graphical Network Analysis Tool software package. Also, this document contains preliminary schedules which outline the work which we intend to complete from January 12 through April 30, 1998. Finally, this document outlines our intended testing strategies for both white box and black box testing. This document does not describe specific test plans, but does detail the methods we will use for deriving all necessary test plans.

 

 

  1. Software Design
    1. Context level diagram
    2. The context level object model, which is attached to this document, gives an overview of the GNAT’s internal structure. The user interacts with the software via the GUI, which presents a standard windows-style interface, making use of dialog boxes, pull-down menus, etc. The GNAT will be able to output an ASCII-text file which contains analysis data in human readable form. This is useful if the user wishes to save the results of some analysis or a listing of network packets which the user deems relevant.

       

      The GNAT takes its input solely from the Snoop file, which contains a trace of all packets as they were captured from the network which is being studied. Once a user opens a Snoop file, the software will parse the Snoop file, extract all packets and perform various analyses, as stated in the specifications document.

       

      The analyses and results will be stored in various classes which are designed to process network packet data. The CheckSums, ZeroWindow and Retransmissions classes will maintain data about packets which have bad checksums, zero windows and have been retransmitted, respectively. The PacketList class will store a list of all the packets contained within the Snoop file. This class will represent the entire Snoop file, but with only the data which is relevant to the analyses performed by the GNAT.

       

    3. Data Dictionary
      1. CheckSums – Stores a list of PacketReference objects which refer to packets with bad checksums. Also contains a list of Connection objects which store data about connections on which packets with bad checksums were generated. This class interacts with the PacketList class and the GUI. When a new Packet is added to the PacketList, it calls a method in CheckSums which verifies the checksums of the packet. If the checksum is not correct, the CheckSums class adds a PacketReference object to its own list and set the Corrupted attribute in the Packet to TRUE. Also, when the user wants to see the packets with bad checksums, the GUI interacts with the CheckSums class to obtain the data. Finally, CheckSums can interact with the output file to generate ASCII text output.
      2. Connection – Stores data related to TCP/IP connections which are detected in the Snoop file. When a new connection is detected in the Snoop file during parsing, a new Connection object is constructed and the sockets at both ends of the connection are stored. This class interacts with the CheckSums, ZeroWindow, Retransmission and PacketList classes, as all of these classes contain lists of Connections.
      3. GUI – The GUI interacts with the user and displays analysis data in graphical and textual form. The user can use pull-down menus to make selections as to what he/she wishes to see. The GUI then interacts with the CheckSums, ZeroWindow, Retransmissions and PacketList classes to get the data which it needs to display. The GUI then takes the data given to it by whichever class it consulted and displays it appropriately (bar graph, histogram, etc.)
      4. List – This is a superclass from which CheckSums, ZeroWindow, Retransmission and PacketList inherit. It contains the attributes and methods which are common to all four of these classes. An object of this class will never be declared, so it won’t directly interact with other objects. For interactions involving classes which inherit from it, see CheckSums, ZeroWindow, Retransmissions and PacketList.
      5. Node – This is a superclass from which PacketReference and Packet classes inherit. It contains the attributes and methods which are common to these two classes. An object of this class will never be declared, so it won’t directly interact with other objects. For interactions involving classes which inherit from it, see PacketReference and Packet.
      6. Outputfile – This class is able to write out various data in ASCII text format. If the user wishes to save certain analysis data for later review, he/she can choose to do so. Outputfile can obtain either analysis data or packet data and write this into a text file. Since this class primarily obtains data for writing, it interacts with the classes which inherit from List.
      7. Packet – This class stores all the relevant data about a packet which is stored in a Snoop file. As the Snoop file is parsed, a list of Packets is built and stored in the PacketList class. A Packet object will exist only within the PacketList, so Packets only interact with this class.
      8. PacketList – This class is the workhorse of the program. Its constructor will be responsible for parsing the Snoop file, creating a list of Packet objects and informing CheckSums, ZeroWindow and Retransmissions classes that they should examine a new Packet for the data each is concerned with (ie: CheckSums verifies that the checksum is correct). During parsing, PacketList also determines when connections are opened and closed and creates a list of Connection objects to store data about every connection encountered in the Snoop file. PacketList obviously interacts with CheckSums, ZeroWindow and Retransmission classes, and it also interacts with the GUI and output file.
      9. PacketReference – This contains a reference to a Packet object. This class will be used within CheckSums, ZeroWindow and Retransmission classes to store references to packets which are relevant. For example, the ZeroWindow class will contain a list of PacketReferences which refer to Packets which have a window field of zero. The Packets which PacketReferences refer to will be stored in the PacketList class. Since this class will be used only in the CheckSums, ZeroWindow and Retransmission classes, it will interact only with these classes.
      10. Retransmissions - Stores a list of PacketReference objects which refer to packets which were retransmitted. Also contains a list of Connection objects which store data about connections on which retransmitted packets were generated. This class interacts with the PacketList class and the GUI. When a new Packet is added to the PacketList, it calls a method in Retransmissions which checks to see if the packet was retransmitted. If so, the Retransmission class adds a PacketReference object to its own internal list. Also, when the user wants to see the packets which were retransmitted, the GUI interacts with the Retransmissions class to obtain the data. Finally, Retransmissions can interact with the Outputfile class to generate ASCII text output.
      11. Snoopfile – This class will not be coded by the team. Instead, this class represents the physical Snoop file which provides the input to the GNAT. The Snoop file contains two important attributes, other than its filename. It contains a header which identifies it as a Snoop file, version 2, and it contains a sequence of packets which were recorded from an Ethernet-based TCP/IP network. This class will interact only with the PacketList class, as PacketList is responsible for parsing the Snoop file and extracting all relevant data.
      12. ZeroWindow - Stores a list of PacketReference objects which refer to packets which show zero in the TCP header’s window size field. Also contains a list of Connection objects which store data about connections on which zero window packets were generated. This class interacts with the PacketList class and the GUI. When a new Packet is added to the PacketList, it calls a method in ZeroWindow which checks to see if the packet has a zero window. If so, the ZeroWindow class adds a PacketReference object to its own internal list. Also, when the user wants to see the packets which were retransmitted, the GUI interacts with the ZeroWindow class to obtain the data. Finally, ZeroWindow can interact with the Outputfile class to generate ASCII text output.
    4. OMT Diagrams
      1. Object Model – This model describes the objects which make up the GNAT. The most critical section of this model is the classes which inherit from the List class. These classes store data regarding packets which have certain attributes and this data is later used to compute various statistics which may be of interest to the user. The most important class in this diagram is the PacketList class, as this is responsible for parsing the Snoop file and extracting and storing data about each packet which it encounters.
      2. Dynamic Model – The model titled Event_Flow_Diagram gives a complete description of the flow of events in the GNAT. This model is fairly straightforward.
      3.  

        The diagrams labeled event2 and eventexceptions are event trace diagrams, showing all of the events which can occur within the GNAT. These also are straightforward, with the event2 diagram showing interactions in the ideal scenario, whereas eventexceptions show events which occur when an error is encountered. The most common errors we expect the software to encounter are a file which is not a Snoop file and errors while parsing the Snoop file. In the event that the user chooses to open a file which is not a Snoop file, the GNAT will detect that the file does not contain the proper header for a Snoop file (see RFC 1761) and will give the user a warning. Also, the GNAT may encounter problems while parsing a Snoop file. This may result from a Snoop file which contains unexpected data (ie: a Snoop file generated on a network which was not a TCP/IP network) or from a bug in the parsing algorithm, although we hope to eliminate all of these by the first release of the software. If the GNAT does encounter a parsing error, it will give the user a warning of the error.

      4. Functional Model – The model titled context-level gives a very high level view of the system, showing input coming from the user and the Snoop file and output going back to the user and to the output file, which will be a text file which can contain packet information or analysis results.
     

    The level 1 diagram, entitled dfd-level1, shows a breakdown of the basic functional units within the GNAT. Primarily, the software will parse the Snoop file to extract packet data, construct mini packets (these will be Packet objects as described in the Data Dictionary), and analyze these packets. The user can then choose to see graphs of the results, or write data out to the output file.

     

  2. Preliminary Schedule
    1. Gantt chart
      1. Attached to this document or see http://www.cse.nau.edu/~synthesis/Path_to_Synthesis/EGR486/CSE/97-Projects/ussoftware
    2. PERT chart
      1. Attached to this document or see http://www.cse.nau.edu/~synthesis/Path_to_Synthesis/EGR486/CSE/97-Projects/ussoftware
  3. Preliminary Test Plan
    1. White box test strategy
      1. Unit test – Since we will be using an object-oriented approach and an object-oriented language, we will implement class testing as our unit test approach. As each concrete class is coded, the team member responsible for coding the class will also design, execute and document a series of class test cases. These test cases should be designed to exercise all of the code contained in all of the class’ methods, as well as verify the correctness of all attributes. We will use control structure testing techniques to generate test cases. Primarily, we will use statement coverage to ensure that all lines of code are being executed. Because we are using an object oriented language, all of the code is not necessarily a part of some function which is explicitly called. A prime example is constructors. In order to ensure that all code within a class is execute, we will develop test cases that construct classes so as to execute all code within a constructor. We will, of course, also use path, branch and condition coverage to ensure that code within each method is executed and functions properly.
      2. Integration test – In order to test the correct interaction between classes as the software system is built, we will use thread-based testing. After classes which make up a thread are coded and tested, one team member will be responsible for designing, executing and documenting a series of thread test cases. In order to test the interaction between classes, the test cases will exercise all possible transactions which could occur amongst the classes. This amounts to "interaction coverage," which is similar to statement coverage, but instead of verifying that each line of code is exercised, it will verify that each interaction between classes is executed.
      3. System test – System testing will be similar to integration testing, although system testing will be one level higher than integration testing. Instead, system testing will test the interaction between the threads which make up the final build of the system. For this level of testing, all team members will be involved in testing. We will design, execute and document a series of tests which will exercise all possible interactions which could occur amongst various threads.
       
    2. Black box test strategy
      1. Unit test – Since we are using an object-oriented language, we will conduct unit testing at the class level. After each class has been coded and white box tested, the team member responsible for coding the class will design, execute and document a series of black box test cases. The initial test case should exercise the minimum test sequence for the class. This will be followed by a minimum of five random test sequences in order to exercise the class. Also, the input domain for each class will be equivalence partitioned to generate a set of test data. The boundaries of the input domain will be added to the test data and this test data will be used to ensure proper functionality.
      2. Integration test – Once classes which form a thread have been integrated and white box tested, we will use fault-based testing to verify that the thread performs correctly. One or more team members will design, execute and document a series of test cases which will test any boundary conditions which the thread may encounter. Also, equivalence partitioning will be used.
      3. System test – In order to test the system as a whole, the most obvious method is scenario-based testing. Once the system has been completely integrated and white box tested, all team members will develop use cases and create possible scenarios to test. These scenarios will be documented and executed by various team members. Also, we will use fault-based testing to verify the functionality of the software system at the boundaries of the input it is expected to encounter and we will use equivalence partitioning to divide up the input domain.
 
 
Specification Number Testing Level Unit or Build
1 Unit Build 1
1.1 System Build 4
2.1.1.1 Unit Retransmissions class
2.1.1.2 Integration Build 2
2.1.1.3 System Build 4
2.1.2.1 Unit Retransmissions class
2.1.2.2 Unit Retransmissions class
2.1.2.3 Unit Retransmissions class
2.1.2.4 Unit Retransmissions class
2.1.2.5 Integration Build 2
2.1.2.6 System Build 4
2.2 Unit CheckSums class
2.2.1 System Build 4
2.2.2 System Build 4
2.3.1 Integration Build 2
2.3.2 Integration Build 2
2.3.3 Integration Build 2
2.3.4 Integration Build 2
2.3.5 Integration Build 2
2.3.6 System Build 4
2.4 System Build 4
2.5 Integration Build 3
2.6 Integration Build 3
2.7 System Build 4
3 Integration, System Builds 3 & 4
4 System Outputfile class