seniord.ece.iastate.eduseniord.ece.iastate.edu/projects/archive/may0525/finalre… · web viewthe...

ISEAGE Network Specification and Report System

Final Report

Client

ISU Information Assurance Center

Faculty Adviser

Dr. Douglas W. Jacobson

Team May 05_25

David C. N. Rodgers ComS, CprE Lijin Varghese CprE Derek J. Light CprE Justin Magnini CprE

DISCLAIMER: This document was developed as a part of the requirements of an electrical and computer engineering course at Iowa State University, Ames, Iowa. This document does not constitute a professional engineering design or a professional land surveying document. Although the information is intended to be accurate, the associated students, faculty, and Iowa State University make no claims, promises, or guarantees about the accuracy, completeness, quality, or adequacy of the information. The user of this document shall ensure that any such use does not violate any laws with regard to professional licensing and certification requirements. This use includes any work resulting from this student-prepared document that is required to be under the responsible charge of a licensed engineer or surveyor. This document is copyrighted by the students who produced this document and the associated faculty advisors. No part may be reproduced without the written permission of the senior design course coordinator.

Submission Date

05/03/05Table of Contents

i

1.Project Approach and Results......................................................................................... 11.1.Executive Summary................................................................................................ 1

1.1.1.Need for Project.............................................................................................. 11.1.2.Actual Project Activities.................................................................................. 11.1.3.Final Results.................................................................................................... 21.1.4.Recommendations for Future Work.................................................................3

1.2.Problem Statement.................................................................................................. 31.2.1.General Problem Statement.............................................................................31.2.2.General Solution Approach.............................................................................4

1.3.Operating Environment........................................................................................... 41.4.Intended Uses and Intended Users..........................................................................4

1.4.1.Intended Uses.................................................................................................. 41.4.2.Intended Users................................................................................................. 4

1.5.Assumptions and Limitations..................................................................................41.5.1.Updated Assumptions List...............................................................................51.5.2.Updated Limitations List.................................................................................5

1.6.Expected End Product and Deliverables..................................................................52.Project Approach and Results......................................................................................... 6

2.1. Functional requirements for the end product .........................................................62.2.Resultant Design Constraints..................................................................................62.3.Approach considered and one selected....................................................................62.4.Considered GIS Software.......................................................................................7

2.4.1.ArcGIS Desktop.............................................................................................. 72.4.2.MapServer....................................................................................................... 72.4.3.Selected GIS Software....................................................................................72.4.4.Reason for Selection........................................................................................ 7

2.5.Considered Graphical Packages..............................................................................72.5.1.wxWidgets...................................................................................................... 72.5.2.GIS in ArcGIS Desktop with a parser..............................................................82.5.3.Selected Graphical Package.............................................................................92.5.4.Reason for Selection........................................................................................ 9

2.6.Considered Databases............................................................................................. 92.6.1. Geodatabase................................................................................................. 102.6.2. GML ........................................................................................................... 102.6.3.XML............................................................................................................. 102.6.4.Selected Database.......................................................................................... 102.6.5.Reason for Selection...................................................................................... 10

2.7.Considered Database Languages...........................................................................112.7.1.C++............................................................................................................... 112.7.2.Kweelt........................................................................................................... 112.7.3.XQuery ........................................................................................................ 112.7.4.Selected Database Language.........................................................................112.7.5.Reason for Selection...................................................................................... 11

2.8.Considered Programming Languages....................................................................112.8.1.C................................................................................................................... 112.8.2.C++............................................................................................................... 122.8.3.C#................................................................................................................. 122.8.4.Java............................................................................................................... 122.8.5.Selected Language......................................................................................... 12

ii

2.8.6.Reason for Selection...................................................................................... 122.9.Considered Technical Approaches........................................................................13

2.9.1.Coding Standards..........................................................................................132.9.2.Brackets........................................................................................................ 132.9.3.Creation of Variables.....................................................................................132.9.4.Function Declarations....................................................................................142.9.5.Line Length................................................................................................... 142.9.6.Loops............................................................................................................ 142.9.7.Operations..................................................................................................... 152.9.8.Semicolons.................................................................................................... 152.9.9.Testing.......................................................................................................... 15

2.10.Detailed design................................................................................................... 152.10.1.XML Parser/ISEAGE Compiler..................................................................152.10.2. ArcGIS Usage............................................................................................20

2.11.Implementation Process Description...................................................................212.12.Testing of End Product and its Results................................................................222.13.End Product Results............................................................................................ 23

2.13.1.User Guide Evaluation Form.......................................................................243.Resources and Schedules.............................................................................................. 25

3.1.Resource Requirements......................................................................................... 253.1.1.Personnel effort............................................................................................. 263.1.2.Other Resources............................................................................................283.1.3.Financial Costs.............................................................................................. 29

3.1.3.1.Miscellaneous Parts...............................................................................293.1.3.2.Use in Design Document.......................................................................293.1.3.3.Binding.................................................................................................. 293.1.3.4.Non-Poster Printing...............................................................................293.1.3.5.Poster..................................................................................................... 293.1.3.6.Current Use............................................................................................ 293.1.3.7.Binding.................................................................................................. 293.1.3.8.Non-Poster Printing...............................................................................293.1.3.9.Poster..................................................................................................... 303.1.3.10.Computers............................................................................................ 303.1.3.11.ArcGIS License...................................................................................303.1.3.12.Windows XP Professional License.......................................................303.1.3.13.Future Total Projected Costs................................................................303.1.3.14.Binding................................................................................................ 303.1.3.15.Non-Poster Printing.............................................................................303.1.3.16.Poster................................................................................................... 30

3.2.Schedules.............................................................................................................. 303.2.1.Project schedules...........................................................................................313.2.2.Deliverable schedules....................................................................................32

4.Closure Materials......................................................................................................... 334.1.Project Evaluation................................................................................................. 33

4.1.1.Project Definition..........................................................................................334.1.2.Technology Considerations and Selection.....................................................334.1.3.End-product Design....................................................................................... 334.1.4.End-product Implementation.........................................................................344.1.5.End-product Testing......................................................................................34

iii

4.1.6.End-product Documentation..........................................................................344.1.7.End-product Demonstration..........................................................................344.1.8.Project Reporting..........................................................................................344.1.9.Final Project Score........................................................................................35

4.2.Commercialization................................................................................................ 354.3.Recommendations for Future Work......................................................................35

4.3.1.Optimizations................................................................................................ 354.3.2.Interactive Software Tutorial and Help Guides..............................................354.3.3.Pseudo-real-time reporting............................................................................36

4.4.Lessons Learned................................................................................................... 364.4.1.What Went Well............................................................................................ 364.4.2.What Did Not Go Well..................................................................................364.4.3.What Technical Knowledge Was Gained.......................................................364.4.4.What Non-Technical Knowledge Was Gained...............................................364.4.5.What To Do Differently If Starting Again.....................................................36

4.5.Risk and risk management....................................................................................374.5.1.Anticipated potential risks and planned management....................................374.5.2.Anticipated potential risks encountered and success in management.............374.5.3.Unanticipated risks encountered....................................................................374.5.4.Resultant changes in risk management made because of encountered unanticipated risks.................................................................................................. 37

4.6.Project Team Information.....................................................................................374.6.1.Client Information ........................................................................................384.6.2.Faculty Advisor............................................................................................. 384.6.3.Team Members.............................................................................................. 38

4.7.Closing summary.................................................................................................. 394.8.References............................................................................................................ 39

5. .................................................................................................................................... 457.Appendix 2................................................................................................................... 45

7.1.Overview.............................................................................................................. 467.1.1.Internal router data structures........................................................................47

7.3.Mapper binary Configuration file..........................................................................477.4.Mk_map............................................................................................................... 487.5.Text Configuration file format..............................................................................48

List of Figures

Figure 1 – ISEAGE Phase 1 Architecture..........................................................................2Figure 2 – Simulated Model of Internet.............................................................................3Figure 3 – ArcGIS Map With Roads, Streets, Rivers etc. . . .............................................9 Figure 4 - Standard for Bracket Usage..........................................................................13Figure 5 - Standard for Variable Declarations.................................................................14Figure 6 - Standard for Function Declarations.................................................................14Figure 7 - Standard for Line Length................................................................................14Figure 8 - Standard for Loop Usage................................................................................14

iv

Figure 9 - ISEAGE Attributes modeled into an ArcGIS data layer.................................21Figure 10 - Personnel effort............................................................................................. 28Figure 11 - Financial costs..............................................................................................30Figure 12 - Project schedules .......................................................................................... 31Figure 13 - Deliverables schedules..................................................................................32Figure 14 - Evaluation Scores for Milestone Completion................................................33Figure 15 - Editor Toolbar..............................................................................................41Figure 16 - Editor Toolbar Menu....................................................................................42Figure 17 - Attributes Window........................................................................................42Figure 18 - Save Edits.................................................................................................... 42Figure 19 - Exporting XML ...........................................................................................43

List of Definitions

Allegro – A cross-platform GUI library with many features.

Classes – Basic construct in object-oriented methods that categorizes elements of the problem.

Compiler – A program designed with the intent of translating one language for another; in this project, the compiler transforms XML from ArcGIS into a file readable by ISEAGE.

CVS – Acronym for Concurrent Versioning System, a tool to manage code devel-opment.

FLTK – A cross-platform C++ GUI toolkit for UNIX, Linux, Microsoft Windows, and MacOS X.

FOX – A C++ based toolkit for developing GUI’s easily and effectively across a range of platforms.

FreeBSD – A variant of the Berkeley Software Distribution (BSD) which imple-ments the UNIX operating system and its utilities.

GIS – Acronym for Geographical Information Systems, a database used to spa-tially locate any location on the Earth.

GNU – Acronym for GNU’s Not Unix and refers to software that is free for use.

GPL – Acronym for General Public License, a standard published for freely distributed software.

GTK – A multi-platform toolkit for creating GUIs.

v

Internet2 – A project aiming to facilitate research and education through advanced network applications using the Internet.

ISEAGE – A network simulator designed and built at Iowa State University for the purpose of analyzing Internet traffic.

IPv4, IPv6 – Internet Protocol versions 4 and 6 used by the Internet and other networks.

Java Swing – A set of Java class libraries that support building GUIs and graphics functionality for client applications that will run on multiple platforms.

Kylix – A rapid application development tool that provides components for quick development of GUIs, database connectivity, and internet content.

Landspeed Record – An open competition to achieve the highest bandwidth over the greatest distance on the Internet.

Linux – A popular version of UNIX that is open source software and freely available over the Internet.

Mac OS X – An operating system for the Apple Macintosh, built on Unix.

MFC – A framework on which applications can be developed for Windows.

Mozilla Framework – A comprehensive multi-platform framework used,among other things, to develop GUIs.

NetBSD – Secure, multi-platform UNIX-like open source operating system.

Notus – A multi-platform GUI library.

OpenBSD – A free variant of the Berkeley Software Distribution (BSD) which implements the UNIX operating system and its utilities.

Open Source – Software that is free for use and modification.

Parser – A program to determine if given text is in a language; in this program, it analyzes XML to determine if the compiler can function on it.

QT – A complete C++ application development framework which includes a class library and tools for cross-platform development and internationalization.

SDL – A library written in C++ for displaying and GUIs.

vi

UNIX – A computer operating system designed to be used by many people at the same time.

wxWidgets - A single, easy-to-use application program interface for writing GUI applications on multiple platforms.

X11 – A recent version of X Windows.

XML – Acronym for eXtensible Markup Language, a flexible way to define formats for data, and make both the format and the data available on the Internet.

X Windows – The X Window System is a network transparent window system which runs on a wide range of computing and graphics machines.

1 Project Approach and Results

This section aims to give the reader a brief look at the entire project without getting too technical. Among the various sections are the executive summary aimed at decision-makers who need simply an overall understanding of the project, a problem statement section talking about what the problem this project was trying to solve, and the intended users and uses.

1.1 Executive Summary

This section serves as a summary of the entire report and is broken down into several sections including the motivation behind the project, project activities, results and recommendations for the future.

1.1.1 Need for Project

The overall motivation behind the ISEAGE project, of which the end product is a subset, is to build a system that people can use to design and test out their own security ideas to evaluate their effectiveness. Normally, network simulations are done entirely through software and don't do an accurate job of representing the actual Internet environment. In ISEAGE, however, actual hardware is used to route traffic to simulate a very realistic image of the Internet. Such a system is especially needed today because of the threat of cybercrime faced by the U.S. after 9/11. The structure of ISEAGE is diagrammed in Figure 1.

The project specifically aimed at letting a user design a virtual network graphically, export the configuration to the ISEAGE system, and run out various scenarios against the virtual network. Also involved was a report system to let the user know the results of the simulation in either pseudo-real time or post-mortem.

1.1.2 Actual Project Activities

vii

The project activities centered around the problem of needing a virtual network configuration tool for ISEAGE. Since this is most easily done graphically, the team decided to build a GUI. After doing some research, the team discovered that the ArcGIS software that the team had to use to meet the GIS needs of the software would function well as the graphical interface for network configuration. To supplement the ArcGIS software, the team will develop an instruction manual by the deadline. Testing will be done both on the instruction manual as well as other software components at that point.

viii

Figure 1 – ISEAGE Phase 1 Architecture

1.1.3 Final Results

While the project is still in the process of being completed, the end product will include an extensive user guide to supplement the ArcGIS tools needed to configure a virtual network. The documentation will include instructions on creating a network in ArcMap, exporting the configuration file, running it through ISEAGE, and interpreting the reports. This documentation will be in electronic form and the team is considering producing a hardcopy version as well. A compiler was also created that parses through the XML network specification created by the user through ArcGIS and makes it more appropriate for the ISEAGE system. The last tool that comprises the end product is a ArcGIS layer

ix

created specifically for computer network components like routers.

1.1.4 Recommendations for Future Work

Since the project was an attempt at creating a working network configuration utility, it doesn't have all the desired, but not required, features. For example, one desirable feature was that the configuration tool be cross-platform. The team did look into this option but decided to not use it since ArcGIS was at the time only supported on Windows. This should change fairly soon, however, and it is encouraged that future teams to try to make the software as platform-independent as possible. Real-time reporting is another desirable feature for the software. Currently, the project reports back in either post-mortem or pseudo-real time. If users can see the results right as they're evaluated on ISEAGE, it would enhance the simulation process.

1.2 Problem Statement

This section talks generally about what the problem was and what solution the team adopted in order to do the project.

1.2.1 General Problem Statement

ISEAGE is a system designed to allow computer network analysis. Before a network can be analyzed, it must be specified and the end results of the analysis must be presented in a human readable form. This project is aimed at allowing both the specification and examination of the analysis by humans.

The client had required that the end product support GIS specification of routers as well as a topology. The networks may be real-world or fictitious. The internal functionality of ISEAGE is diagrammed in Figure2.

Figure 2 – Simulated Model of Internet

x

1.2.2 General Solution Approach

There are many GIS products on the market already so rather than attempt to design one from scratch, the team elected to adapt one to ISEAGE. This would fulfill the GIS-based requirement and, using a blank map, allow the end user to map network topologies. The team elected to use ArcGIS since it allows for C++ extensions and is site licensed by Iowa State University.

1.3 Operating Environment

While ISEAGE requires a cluster of computers, specifying a network can be done on any machine capable of running ArcGIS. Conventionally, this is a Windows XP system, but as long as ArcGIS runs, the specification system does as well. The report system is much more basic, being only a text document and therefore will be supported by anything capable of displaying ASCII characters.

1.4 Intended Uses and Intended Users

This section discusses the intended uses and the intended users of the end product.

1.4.1 Intended Uses

The intended users include any individual or group desiring to simulate a computer network to evaluate security. These networks may range from as small as two computers (e.g., to simulate fast file transfers, such as the research being done on Internet2 to gain the land speed record) to the entire State of Iowa. Creators of small networks include small business owners and student projects. The largest network will be created by Iowa’s Department of Homeland Security to simulate the entire State of Iowa.

1.4.2 Intended Users

One of the largest challenges will be deriving an interface that satisfies the network complexity needs of users. Some may want to create very simple networks, some very complex networks as well as users who want to follow the location of components and those who only want to monitor with respect to network topology. A very simple simulation can easily create one computer at a time, while a very complex simulation (especially with GIS information included) must be able to create many computers in their exact locations quickly and easily.

1.5 Assumptions and Limitations

xi

This section includes an updated list of assumptions and limitations that the team worked with in the execution of the project.

1.5.1 Updated Assumptions List

Following are the updated assumptions made by the team:

The end product will be used by only one user per simulation. If a user would like to configure different computer networks on the

same computer, he or she will have to start another copy of the software.

Functions licensed under the GPL license may be used. In such case, the end product may also be licensed under the GPL license.

The language of the user is English.

1.5.2 Updated Limitations List

Listed below are client-specified limitations:

The software must run on the Windows NT (NT, 2000, XP). The software must be GIS-based, i.e., it must be able to configure

computer networks that exist spatially. A GUI interface must be provided for ease in configuring the virtual

computer network. The software must be able to specify IPv4 networks since this is

currently the protocol in use by most networks. The simulation must output results into a text file format that will be

interpreted by ISEAGE.

1.6 Expected End Product and Deliverables

The end product consists of three main pieces: an ArcGIS reference guide, a parser for ArcGIS to ISEAGE conversion, and a ArcGIS template layer for computer network objects. The ArcGIS reference guide details how ArcGIS should be used for the specification of a computer network for ISEAGE. The guide features step-by-step instructions including illustrations on how the functionality of ArcGIS can be used for the network specification in ISEAGE format. Also in the list of deliverables is an ArcGIS layer and a database that was created to contain the required pieces of information to be used when parsing to ISEAGE specification. The parsing program will accept input from an ArcGIS generated XML file, and convert the data into a format usable in the ISEAGE system.

xii

2 Project Approach and Results

This section discusses the project more in depth. Some of the topics covered include client-specified functional requirements, the various approaches that were considered and which were selected and why, and also a detailed description of the actual design of the end product.

2.1 Functional requirements for the end product The following defines exactly what the proposed software should and should not do:

The software shall allow the configuration of virtual computer networks whether large or small.

The network specification may include different types of computers (IBM, Macintosh), routing devices (switches, bridges), etc.

The software shall allow network specification through the use of a GUI which provides graphical symbols representing computers, routers, wires, etc., all of which will be can be added in the software.

The software shall allow the user to specify a network using GIS software, i.e., to specify a network that is representative of a spatially-existent network.

The software shall allow network specification in a text file format. The software shall be able to read simulation data from the ISEAGE

system. The software shall allow the user to view traffic information of the

configured network.

2.2 Resultant Design Constraints

This section outlines the resultant design constraints of the software.

The software is Windows-compatible. The software provides a GUI for network specification. The software is GIS-based. The software provides output in a text file format. The software does not allow more than one user to simulate an

individual network. The software displays traffic information to the user.

2.3 Approach considered and one selected

This section discusses the various software technologies and the technical approaches that the team has researched in the process of deciding which tools and methods to use for the end product.

2.4 Considered GIS Software

Since the end product supports GIS functionality, several GIS applications were investigated. Discussed below are ArcGIS Server and MapServer.

2.4.1 ArcGIS Desktop

ArcGIS Desktop is an ISU site-licensed software for the development of custom GIS applications. Compared to its open source competitors, ArcGIS Desktop has the advantage of not only having support materials like free tutorials and documentation, but there is also a GIS lab facility in Durham with a full-time GIS staff that can provide help. In addition, it is certain that ArcGIS Desktop provides the various functionalities that the GUI application will need.

2.4.2 MapServer

MapServer is the open source equivalent of ArcGIS Desktop. Although it is certain after talking to some of the GIS staff that it supports some of the needed functionality, it is not at all certain that it has all the required functionality. On the other hand, MapServer has the advantage of being cross-platform whereas ArcGIS Desktop is only Windows-compatible. However, the client specifications state that the end product be Windows-compatible leaving anything beyond that up to the team.

2.4.3 Selected GIS Software

The team has decided to use ArcGIS Desktop to provide the needed GIS functionality.

2.4.4 Reason for Selection

Considering the lack of support available for MapServer, not to mention the uncertainty about its features, the team has decided to work with ArcGIS Desktop.

2.5 Considered Graphical Packages

This section considers the graphical packages the team researched in order to decide which will best support client specifications. The packages discussed are wxWidgets and the GIS built into ArcGIS Desktop with parser.

2

2.5.1 wxWidgets

wxWidgets is an open source C++ GUI framework that can be run on multiple platforms including Windows, UNIX, and Mac OS. The advantage of wxWidgets over other GUI frameworks is that the appearance of the windows is dependent on the platform. This is helpful because the end user will get the same “look and feel” of windows that they are used to in their operating system. The advantage of wxWidgets over the GIS plug-ins is its ability to shape the interface. Using GIS plug-ins one is restricted to a GUI similar to the GIS software. With wxWidgets, windows can be built in almost any form to meet the projects needs. The group does not have any experience with either GIS plug-ins or wxWidgets so there is no experiential advantage with either technology.

The major disadvantage that comes with wxWidgets is that it requires much work by the user to configure a location, for example the state of Iowa, realistically inside the GUI while representing the desired features like power lines, railroad tracks, etc.

2.5.2 GIS in ArcGIS Desktop with a parser

The major advantage of ArcGIS is that it can directly import into the GUI a physical map with the desired features like railroad tracks, power lines, roads, etc. with minimal interaction required by the user. The physical map with the existing features will additionally be based on the latest geographical information available for that location (see Figure 3). ArcGIS also allows the user to specify a network and export this network to a file. A parser would need to be written to convert this file to the proper text file format. This process would require the user to follow very few steps as compared to a more complicated one using wxWidgets.

3

Figure 3 – ArcGIS Map With Roads, Streets, Rivers etc. . . .

The disadvantage involved with ArcGIS is that it is not cross-platform like wxWidgets. However, the client has required only that the end product be Windows compatible. Anything beyond that is optional.

2.5.3 Selected Graphical Package

The team has decided to work with ArcGIS with a compiler added.


The ArcGIS plug-ins were selected because of the significantly lesser work involved in configuring the physical aspects of a location over which the network simulation was being run. Although the team would prefer to have the end product be cross-platform, the fact that it’s not a requirement also aids in the selection of the ArcGIS plug-ins.

2.6 Considered Databases

This section considers software that provides extra database functionality required for the end product. Also considered are the databases to store the user-defined computer networks.

4

2.6.1 Geodatabase

In addition to the database functionality that ArcGIS Server provides, the end product will need a GIS component called Geodatabase for further database capabilities. Like ArcGIS Server, Geodatabase comes in both commercial and open source packages. ISU has a supported site-licensed version of Geodatabase that provides the required functionality. The open source version, however, runs the risk again of a lack of documentation.

2.6.2 GML

GML is an extension of XML specifically designed for geographic data. GML is specifically designed for graphical representation. Some of its default objects include polygons, lines, points, etc. all of which are customizable. In addition, GML lets the user import image files to represent different computer network components like routers, firewalls, etc. The disadvantage that GML comes with, however, is that none of the team members have worked with it before. However, since GML is an extension of XML, something the team is somewhat familiar with, it is estimated that getting acquainted with GML will not involve significant effort.

2.6.3 XML

In the original specification, the program had to output XML, but the option existed to have only XML documents read from and written into. This reduces the amount of file interface code to be written, which in turn reduces the amount of testing and debugging. The primary disadvantage is that algorithms must be implemented within the program to select subsections of the network; however, this becomes less of a problem with the use of a XML querying language like Kweelt or XQuery (see Considered Database Languages).

Allowing the user to work with icons for various computer network objects is one functionality that the team will potentially implement. XML has the ability to import image files for these icons. However, this has to be hard-coded.

2.6.4 Selected Database

None of the above was selected since the client's requirements changed. Instead, the program outputs XML which is then sent through a compiler, outputting an ISEAGE specification.


5

ArcGIS exports XML, so this was used as a baseline. Outputting an ISEAGE specification was chosen because it is a requirement of the client.

2.7 Considered Database Languages

This section discusses the database querying languages investigated for searching through the user-defined database.

2.7.1 C++

It is possible to parse through the GML database using C++. However, this would involve significantly more work than if the team used XQuery or Kweelt.

2.7.2 Kweelt

Kweelt is a database querying language for XML databases similar to what SQL is for SQL Server. While this is more convenient than hard-coding queries in C++, its syntax is slightly more tedious than that of XQuery.

2.7.3 XQuery

XQuery is another language used to query XML databases. Since the project will work with GML databases, an extension of XML databases, XQuery will be a powerful querying tool. Also, XQuery’s syntax is more intuitive than that of Kweelt.

2.7.4 Selected Database Language

None of the above languages were chosen as a result of changes in client specifications.


None of the languages were chosen as a database query language.

2.8 Considered Programming Languages

This section discusses the various languages that the team considered in deciding on a primary language to use in the coding phase. Among the ones considered are C, C++, C#, and Java.

2.8.1 C

6

C is compiled code, instead of interpreted code, and if all else is equal, compiled code is at least as fast as interpreted code. This makes C preferable to an equivalent interpreted language. It is also a nearly universal language; at this level, almost anyone who would see the program's code will have used C at some point.

ISEAGE creates a simulation of a computer network which has discrete components connected to one another. This makes an object-oriented language preferable to a non-object oriented language. C, however, is non-object-oriented, and its advantages are shared by the similar, object-oriented languages C++ and C#, making C++ and C# preferable to C.

2.8.2 C++

The primary advantage of C++ is that the entire group has used it previously. It is also object-oriented making it well-suited to create many simulation objects with customized behavior since these objects can be represented by instances of virtual objects. All else being equal, being compiled code, C++ will be at least as fast as interpreted languages. Properly constructed C++ code is portable as long as the libraries used are available on the platform to which it is being ported.

The main disadvantage of C++ is that it has few built-in functions compared to C# and Java. Instead, it provides substantial low-level functionality which implies that the team must either locate the appropriate libraries or write the equivalent code from the ground up. A strong example of this is the lack of graphical libraries. However, this can be overcome by the use of software that either provides these libraries or the means to accomplish with ease what the libraries can. Both of these options are discussed in the considered graphical packages section.

2.8.3 C#

C# is more user-friendly than C++ or C because it has many built-in functions which do not require the manual inclusion of libraries. However, C# is not cross-platform.

2.8.4 Java

Java, like C#, has a lot of built-in functions that do not need the manual inclusion of libraries. Unfortunately, like C#, only two of the team members are comfortable with Java leading to the same problem of all members not being able to debug or test Java code.

7

2.8.5 Selected Language

The team has decided to use C++ as its compiler programming language and C# as its primary prototyping language.


The main reason is that the team members are all comfortable with C++ and C# is easy to learn and use. This cannot be said for Java. The team members do all have some experience with C, but as was stated before, C is not an object-oriented language making it considerably more difficult than C++ or C#. C++ also provides the team the opportunity to debug and test other members’ code. C# has an easy to use graphical package. Due to these factors, the team has decided to use C++ and C#.

2.9 Considered Technical Approaches

This section discusses various approaches that the team considered for the coding phase of the project.

2.9.1 Coding Standards

In order to improve the readability of the code, each member is expected to use the same style of format.

2.9.2 Brackets

Brackets always have a line in which only they appear. Opening brackets are at the same tab level as the preceding line, and all following lines will have one more tab preceding the line (see Figure4).

for(i=0; i<5; i++){

for(j=0; j<5; j++){

functionTabbedIn();}

}

8

Figure 4 - Standard for Bracket Usage

2.9.3 Creation of Variables

The creation of variables is done at the start of the function and only at the start of the function. The declaration of type is followed by exactly one type. Variables are declared in order of type, with exactly zero spaces between a variable and the following comma and exactly one space between a variable and the preceding comma (see Figure 5). Variables of the same type are declared on the same line unless this exceeds 80 characters, in which case a carriage return and tab replaces the last space on the line that would otherwise exceed 80 characters. The variables of the same type are declared in alphabetical order. Variables are initialized at their creation, or as soon as possible afterwards, but may be initialized to any suitable value; by default, this value is 0 for any variable storing integer-like data.

Figure 5 - Standard for Variable Declarations

2.9.4 Function Declarations

The return type of the function is followed by exactly one space, followed by the function name, beginning with a lowercase letter and with capital letters occurring at the start of any new word (instead of underscores, and without spaces), followed immediately by an opening parenthesis (see Figure 6). The type of and the variables sent into the function follow, in that order, with exactly one space between the return value and the variable. The order of these variables is alphabetic by type, then alphabetic by variable name. The variables also begin with a lowercase letter, with no spaces, and capital letters beginning subsequent words. After the last variable, a closing parenthesis and semicolon appears without any spaces.

int a, b, c, d, e, f, g, h, i, j, k, l;a=b=c=d=e=f=g=h=i=j=k=l=0;

int garbageFunction(char firstVariable, char secondVariable, int fourthVariable);

9

Figure 6 - Standard for Function Declarations

2.9.5 Line Length

Line length will be kept at or below 80 characters in order to facilitate printing of source code (see Figure 7).

Figure 7 - Standard for Line Length

2.9.6 Loops

Loops have zero spaces immediately before and after the parentheses. “for” loops have exactly zero spaces before the semicolons and exactly one space following them (see Figure 8). If multiple comparisons are done at once, with && or ||, then the individual comparisons are enclosed in parenthesis, with exactly one space between the parenthesis and the && or ||.

Figure 8 - Standard for Loop Usage

2.9.7 Operations

Both comparison and assignment are done with zero spaces before and after the operator (see example below). Other operators have exactly one space to either side, unless this would cause the line to exceed 80 characters.

Example: x=2 + 2;

2.9.8 Semicolons

Semicolons are never immediately preceded by white space.

Example: function();

2.9.9 Testing

One month was reserved for testing. Because the program is split into two large modules, there were two large modules of testing done: Graphical and non-graphical.

The graphical code may be imported from another source (see

12345678911234567892123456789312345678941234567895123456789612345678971234567898

for(i=1; (i<5) && (i%3); i++)

10

“Considered Graphical Packages”) and can therefore be expected to be relatively bug-free. If graphical testing must be done, the team shall attempt to explore each aspect of the GUI.

The non-graphical code will almost certainly need to be written by the team. Fortunately, automated testing is much easier to do with non-graphical code than graphical code and this is what will be utilized.

2.10 Detailed design

The detailed design section talks about the design of the end product. It is divided into two sections: the XML parser section and the ArcGIS user guide section.

2.10.1 XML Parser/ISEAGE Compiler

ArcGIS can output XML documents including information about the elements in a map, but ISEAGE requires a radically different format. The XML must be converted into an acceptable format.

Designs created for the specification files have been overhauled twice, and are being overhauled a third time, so this section is incomplete at this time. Initially, the project required an XML specification to be provided; the client changed this requirement in the second semester for the program to provide a simplified, non-XML text specification given in ISEAGE Traffic Mapper Design Specification v1.1 (see Appendix, item 2). This prevented a parser for the original XML specification from being developed. A finite automaton and regular expression were written to recognize the file format in the intentions of being able to reload a specification from a specification file; this was determined as unnecessary but may be a candidate for future work.

Following the discovery that ArcGIS can export XML documents, the group assumed that the format could be specified allowing another parser to be designed. This parser assumed that the format of XML would be as follows:

[. . .]<Board>

<Number>0</Number> <Router> <Number>0</Number> <Type>Outside</Type> <Name>Outside router</Name> <If_out>

<hwaddr>23:FF:45:12:45:55</hwaddr> <IP_addr>192.168.5.254</IP_addr> <IP_range>192.168.5.0</IP_range>

11

<CIDR>24</CIDR> </If_out> <If_out>

<hwaddr>23:FF:45:12:45:55</hwaddr> <IP_addr>192.168.6.254</IP_addr> <IP_range>192.168.6.0</IP_range> <CIDR>24</CIDR>

</If_out> <If>

<IP_addr>192.168.7.8</IP_addr> <hwaddr>23:22:45:12:45:55</hwaddr>

</If> <If>

<IP_addr>192.168.10.10</IP_addr> </If> <R_table>

<Dest>192.168.5.0</Dest> <Mask>24</Mask> <Board>1</Board> <Id>0</Id> <Interface>1</Interface>

</R_table> </Router>

</Board> . . .

Which is recognized by the following regular expression, ignoring whitespace both in the specification and regular expression, where < and > are literals and (DOT) represents a dot ("."):

((<Board> <Number>[0-9][0-9]*</Number> <Router>

<Number>0</Number> <Type>(Inside|Outside)</Type> <Name>(ASCII_CHAR)..............................</Name> (<If_out>

<hwaddr>[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]</hwaddr>

<IP_addr>[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..</IP_addr>

<IP_range>[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..</IP_range>

<CIDR>[0-9][0-9]*</CIDR> </If_out>)* (<If>


((EMPTY_STRING)|

12

<hwaddr>[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]</hwaddr>)

</If>)* (<R_table>

<Dest>[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..</Dest>

<Mask>[0-9][0-9]*</Mask> <Board>[0-9][0-9]*</Board> <Id>[0-9][0-9]*</Id> <Interface>[0-9][0-9]*</Interface>

</R_table>)* </Router>

</Board>) | (<Board>

<Number>[0-9][0-9]*</Number> <Router>

<Number>(0*[1-9][0-9]*)</Number> <Type>Inside</Type> <Name>(ASCII_CHAR)..............................</Name> (<If>


((EMPTY_STRING)| <hwaddr>[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:

[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]</hwaddr>)

</If>)* (<R_table>

<Dest>[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..</Dest>

<Mask>[0-9][0-9]*</Mask> <Board>[0-9][0-9]*</Board> <Id>[0-9][0-9]*</Id> <Interface>[0-9][0-9]*</Interface>

</R_table>)* </Router>

</Board>))*

Note that router 0 is exceptional in that only it can be of type outside or have if_out fields. This is checked for in the parser instead of in ArcGIS for practical reasons; specifically, ArcGIS doesn't allow for such checking. Additionally, the above regular expression only checks syntax, not semantics, which isn't an issue; it is the parser's duty to check syntax and the compiler's to check semantics. Unfortunately, since the XML format cannot be specified, ArcGIS' format must be used.

The exact format of ArcGIS' XML output is still under evaluation, but appears to be a context-sensitive language as far as ISEAGE is concerned. ArcGIS supports exporting one of two XML formats: Record

13

sets and Workspaces. While it would be possible to recognize both in a regular language, this project supports only record sets.

As far as information that ISEAGE requires, record sets take the following form; anything occurring after a > and before a < may be ignored as though it were whitespace.

<esri:Workspace><WorkspaceData xsi:type="esri:WorkspaceData">

<DatasetData xsi:type="esri:TableData"><DatasetName>ROUTER</DatasetName><Data xsi:type="esri:RecordSet">

<Fields xsi:type="esri:Fields"><FieldArray xsi:type="esri:ArrayOfField">

<Field xsi:type="esri:Field"><Name>router</Name>

</Field><Field xsi:type="esri:Field">

<Name>board</Name></Field><Field xsi:type="esri:Field">

<Name>type</Name></Field><Field xsi:type="esri:Field">

<Name>name</Name></Field><Field xsi:type="esri:Field">

<Name>if_out_mac</Name></Field><Field xsi:type="esri:Field">

<Name>if_out_ip</Name></Field><Field xsi:type="esri:Field">

<Name>if_out_cidr</Name></Field><Field xsi:type="esri:Field">

<Name>if_ip</Name></Field><Field xsi:type="esri:Field">

<Name>if_hrd</Name></Field><Field xsi:type="esri:Field">

<Name>r_table</Name></Field>

</FieldArray></Fields>

<Records xsi:type="esri:ArrayOfRecord"><Value xsi:type="xs:short">[0-9][0-9]*</Value><Value xsi:type="xs:short">[0-9][0-9]*</Value><Value xsi:type="xs:string">(Inside|Outside)</Value>

14

<Value xsi:type="xs:string">STRING</Value><Value xsi:type="xs:string">[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-

fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]</Value>

<Value xsi:type="xs:string">[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..</Value>

<Value xsi:type="xs:short">[0-9][0-9]*</Value><Value xsi:type="xs:string">[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9]

[0-9]..(DOT)[0-9][0-9]..</Value>(<Value xsi:nil="true"/> | (<Value xsi:type="xs:string">[0-9a-fA-F][0-

9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]</Value>))

<Value xsi:type="xs:string">[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..(DOT)[0-9][0-9]..,[0-9][0-9]*,[0-9][0-9]*,[0-9][0-9]*,[0-9][0-9]*</Value>

</Records> </Data></DatasetData>

</WorkspaceData></esri:Workspace>

In this format there is a list of fields which each have values. Each field corresponds to values found between the <Record> and </Records> flag; for example, whatever is the third instance of <Field> between <Fields> <FieldArray> and </FieldArray> </Fields> must correspond to the third instance of <Value> between <Records> and </Records>. The language is therefore not regular, but context-sensitive. This can still be evaluated by a compiler by creating a cursor immediately following the <FieldArray>, counting the number of instances of <Field>[. . .]</Field> until </FieldArray> is found, allocating memory for that quantity, then backtracking to the original <FieldArray> and determining which fields have the name router, type, name, if_out_mac, if_out_ip, if_out_cidr, if_ip, if_hrd, or r_table. The last field, r_table, is likely to be changed to the field’s r_table_ip, r_table_mask, r_table_board, r_table_id, and r_table_interface with its values similarly split up.

The output text document must have everything in the correct sequence; this sequence is board, router, type, name, if_out, if, and r_table. In order to permit this, a second, unsigned integer array is created, where traversing up the value in the position in the lookup array in the record array gives the correct sequence, so that looking up recordArray[1][lookupArray[0]] is the board number, recordArray[1][lookupArray[1]]is the router number, etc.

The 0th row of the two-dimensional record array contains the name of each column. Each following row then contains the value for that given record. In order to output to the file, the lookupArray is scanned from 0 to its highest coordinate, with recordArray[0][lookupArray[currentCoordinate]]"="recordArray[N][lookupArray[currentCoordinate]"\n" is output to the outfile which can then be directed to ISEAGE. Because ArcGIS does not allow duplicate names,

15

having the same type of classification multiple times must be followed with an _INTEGER, which will be ignored by the compiler. Whenever lookupArray[currentCoordinate] equals the size of lookupArray, an extra '\n' is output to a file in order to enhance readability.

Again, the final version of this design may change between the unbound and bound reports.

2.10.2 ArcGIS Usage

Since the team has decided to use ArcGIS for ISEAGE network specification, a user guide was created (see Appendix, Item 1). This guide will instruct the user how to use ArcGIS to create an ISEAGE network specification. An ArcCatalog database was created for use with the parsing software, which will output in a format in compliance with ISEAGE standards (See Figure 9).

Figure 9 - ISEAGE Attributes modeled into an ArcGIS data layer.

The ROUTER layer in the database was setup to contain the following Attributes.

ROUTER: BOARD:TYPE:NAME:IF_OUT_MAC:IF_OUT_IP:IF_OUT_CIDRIF_IPIF_HRD:R_TABLE_IPR_TABLE_1..4

16

Some of the larger ISEAGE attributes had to be split up into multiple sub-attributes, which can be seen with IF_OUT, IF, and R_TABLE. ArcCatalog does not support complex data types, and will not allow two attributes names to be identical. After the database was created, a sample entry was entered and the ArcGIS User Guide listed in the Appendix as item 1 was created.

2.11 Implementation Process Description

One of the project requirements was the use of GIS in the computer network specification, and for this reason the team decided to use ArcGIS. None of the team members had any prior experience with ArcGIS and the software was not readily available. The team discovered that ISU had a site-license for ArcGIS and as a result it was chosen to provide GIS functionality. However, with the site license came the restriction that the software could only be used on campus. A computer was obtained for team use and all the necessary software was installed. Unfortunately though the installation of the ArcGIS software was delayed because of unknown Internet problems which prevented the team from downloading a server license for ArcGIS. When we eventually were able to get the Internet problem fixed, each team member enrolled in an online ArcGIS class through the ERSI online community and proceeded to learn how to use ArcGIS. But the team only had one computer, and the tutorials were time consuming. Since this was also causing project delays, the team requested a second computer and soon the project was back on track.

After completion of the ArcGIS course modules, the team came to the realization that most of the project’s functionality and requirements were already being fulfilled by ArcGIS. Not only would following the team’s vision be redundant, but incredibly difficult and time consuming. The addition of an ISEAGE layer to a GIS map would be simple, and furthermore ArcGIS even exports data into an XML document. But the ISEAGE format had shifted away from XML, so the team decided it would have to build a parsing program, which would read the ArcGIS exported XML document and convert it into the format that ISEAGE now requires.

So the team started documenting the usage of ArcGIS, detailing how to use the software to create an ISEAGE network specification, and created the parsing software that would be used with the ArcGIS exported XML.

2.12 Testing of End Product and its Results

The testing process has not been started as yet on the end product. However, the team has planned out what the testing phase will look like. The instruction manual will be tested by both the team as well as independent testers. Independent testers will include people with a range of expertise with software applications ranging from students who would be considered novice

17

computer users all the way to a full-time GIS specialist, Patrick Brown, who works in Durham. The testers will be asked to fill out a feedback form as they're testing out the software to configure a virtual network on a computer. The requested configuration will be typical of the configuration that the average user would build. The feedback forms will form the basis for evaluating the testers' experience and changes will be made by weighing the tester comments against the team's knowledge of ArcGIS. The feedback form is on the following page.

Another component of the project that will be tested is the parser designed to read the configuration file created by the user and feed the data to the ISEAGE system. The team will build an automated testing process where files with errors as well as files without errors will be fed to the parser to test if it accepts only the right files. The parser testing will be done by any of the team members but David since he created it. The ArcGIS software itself will not be tested since even if we run into problems with it, there isn't anything the team can do to resolve it.

2.13 End Product Results

This section will talk about the status of two different project components – the user guide and the specification system. While neither of these are in their complete forms, the team expects to finish up both before the final deadline in a fully functional state.

18

2.13.1 User Guide Evaluation Form

Name: Date:

Rate your estimated level of comfort with software applications:

Applications?? NoviceIntermediate Experienced Expert

1. Follow the user guide and create a network with 3 routers that are all connected.

2. Export the specification to XML.

3. Run the XML parser.

4. Answer the following questions using this scale:

1 2 3 4 5Disagree Neutral Agree

1. The user guide clearly explained how to load a map.1 2 3 4 5

2. The user guide clearly explained how to add objects to a map.1 2 3 4 5

3. The user guide clearly explained how to change the properties of an object.1 2 3 4 5

4. The user guide clearly explained how to export the specification to XML.1 2 3 4 5

5. The user guide clearly explained how to run the XML parser.1 2 3 4 5

6. Rate the overall effectiveness of the user guide.

1 2 3 4 5 Poor Average Excellent

19

3 Resources and Schedules

This section discusses the cost of executing the project be it in personnel hours, project-related expenses, and income the team would earn in a industry setting.

3.1 Resource Requirements

This is a pure software project so the costs are limited to what must be produced for documentation, labor costs, licensed software, and borrowed hardware. The hardware will be returned at the end of the semester and Iowa State University has site licenses for Windows XP and ArcGIS, so there is no more cost for this group using either than there would have been otherwise. The entire cost comes from labor and documentation.

20

3.1.1 Personnel effort

Prob

lem

D

efin

ition

Tech

nolo

gy

Con

side

ratio

n an

d Se

lect

ion

End-

Prod

uct

Des

ign

End-

Prod

uct

Impl

emen

tatio

n

End-

Prod

uct

Test

ing

End-

Prod

uct

Doc

umen

tatio

n

End-

Prod

uct

Dem

onst

ratio

n

Proj

ect R

epor

ting

Tota

l

Original Projected UseDavid Rodgers 8 14 25 55 25 24 14 15 180

Lijin Varghese 10 10 30 41 20 30 14 20 175

Derek Light 7 12 26 58 25 21 14 7 170

Justin Magnini 7 9 30 60 22 20 14 10 172

Total 32 45 111 214 92 95 56 52 697

Projected Use in Design DocumentDavid Rodgers 3 14 20 28 12 12 9 10 108

Lijin Varghese 5 30 20 20 10 15 9 20 129

Derek Light 2 12 25 27 13 11 9 9 108

Justin Magnini 2 9 19 30 11 10 9 9 99

Total 12 65 84 105 46 48 36 48 697

Current UseDavid Rodgers 3 14 28 5 0 10 0 10 70

Lijin Varghese 5 30 24 0 0 23.5 0 16 102.5

Derek Light 2 12 25 7 0 10 0 9 65

Justin Magnini 2 9 21 12.5 0 1 0 9 65.5

12 65 76 24.5 0 44.5 0 43 303

Final UseDavid Rodgers 3 18 30 12 12 20 5 12 112

Lijin Varghese 5 30 30 0 14 25 5 22 131

Derek Light 2 12 25 8 8 24 5 16 100

Justin Magnini 2 9 23 15 16 16 5 16 102

12 69 108 35 50 85 20 66 445

Figure 10 - Personnel effort

3.1.2 Other Resources

21

As you can see from Figure 11, our original projections were off by a little. Our original projection was $120. This changed to roughly $76 by the end of the design document. Thanks to the fact that two computers were donated for team use, and that the ArcGIS which normally costs thousands of dollars was site-licensed, the team did not have to incur those potential expenses.

The final cost is almost $87 and this includes all binding expenses, printing of all drafts of reports, as well as the poster printing expenses.

Item CostOriginal Projected Costs

Printing Expenses Including Poster $75.00

1.1.1.1 Miscellaneous Parts $45.00

1.1.1.2 Use in Design Document1.1.1.3 Binding $2.40

1.1.1.4 Non-Poster Printing $1.50

1.1.1.5 Poster $72.00

1.1.1.6 Current Use1.1.1.7 Binding $2.40


1.1.1.9 Poster $72.00

1.1.1.10 Computers Donated

1.1.1.11 ArcGIS License Donated

1.1.1.12 Windows XP Professional License Donated

1.1.1.13 Future Total Projected Costs1.1.1.14 Binding $4.80


1.1.1.16 Poster $72.00

22

3.1.3 Financial Costs

Total financial costs sum up the personnel expenses and the other resources expenses.

Item W/O Labor With LaborOriginal Projected Costs

Parts and Materials: a. Printing expenses including Poster

$75.00 $75.00

b. Miscellaneous $45.00 $45.00 Subtotal: $120.00 $120.00Labor Expenses: David Rodgers $1800.00Lijin Varghese $1750.00Derek Light $1700.00Justin Magnini $1720.00

Subtotal $0.00 $6470.00Total $120.00 $6590.00

Revised Estimated CostsParts and Materials: a. Printing expenses $75.00 $75.00

23

including Poster b. Miscellaneous $14.80 $14.80 Subtotal

$89.80 $89.80

Labor Expenses:David Rodgers $1060.00Lijin Varghese $1350.00Derek Light $960.00Justin Magnini $1050.00 Subtotal

$0.00 $4420.00

Total

$89.80 $4509.80

Final CostsParts and Materials: a. Printing expenses including Poster

$75.00 $75.00

b. Miscellaneous $14.80 $14.80 Subtot

al$89.80 $89.80

Labor Expenses:David Rodgers $1120.00Lijin Varghese $1310.00Derek Light $1000.00

Item W/O Labor With LaborFinal Expenses (Contd.)

Labor Expenses (contd.):Justin Magnini $1020.00

Subtotal $0.00 $4450.00Total $89.80 $4539.80

Figure 11 - Financial costs

As is shown, the estimates have varied and the final expenses are especially different from the first estimate. The reason the original estimates were made as high as they were was that the team hadn’t yet discovered that ArcGIS already had a lot of the desired product features built into it. Once the team became aware of this available functionality, the team revised its estimates to a much more conservative one. The final expenses turned out to be a fairly close to the revised estimates.

3.2 Schedules

This project fell behind schedule due to technical issues; specifically, both ArcGIS and Windows XP require registration with a central server over the Internet. Unfortunately, the Internet is not guaranteed delivery, so

24

relying on delivery via Internet before allowing someone to use a product does not guarantee that that individual can use the product. Following the installation of Service Pack 2, the computer would boot, then after less than ten minutes, any attempt at DNS lookup would fail. This was shorter than the overhead of time required to install ArcGIS with the result that ArcGIS could not be installed. This was ultimately fixed by reinstalling Windows XP from scratch and not installing Service Pack 2. Unfortunately, the damage was already done to the schedule. The following pages hold Figures 12 and 13, the Project Schedule and Delivery Schedule. The lowest bar is the currently projected time for each element.

25

3.2.1 Project schedules

Figure 12 - Project schedules

26

3.2.2 Deliverable schedules.

Figure 13 - Deliverables schedules

27

4 Closure Materials

This part of the report deals with some concluding information. Included are the team's evaluation of itself based on the project, the lessons learned through the project, commercialization issues, and contact information.

4.1 Project Evaluation

This section describes the milestones for the project and the criteria used to evaluate the success of the completed project. For each milestone, the team evaluated the completeness and success of that item and assigned a score to it from Table 8 below. The team then took the scores for all of the individual milestones and multiplied them by their overall importance metric to get a final score for the project. A final score of greater than 85% is considered a success for the project.

Evaluation Result Numerical ScoreGreatly Exceeded 100 %

Exceeded 100 %Met 100 %

Almost Met 90 %Partially Met 80 %Did Not Meet 40 %

Did Not Attempt 0 %Figure 14 - Evaluation Scores for Milestone Completion

4.1.1 Project DefinitionDescription: The project had to be adequately defined before we could start designing the project. An accurate definition ensured all team members knew the functionality of the project approaches possible.Evaluation criteria: The team determined how well the project definition met their expectations and assigned a score from Figure 14.Overall importance: 15%Milestone score: 100%

4.1.2 Technology Considerations and SelectionDescription: Team members had to research available software technologies such as graphics packages, GIS software, programming languages, and databases. From these, the team selected the technologies that helped produce software that met all functional requirements with efficiency and effectiveness in mind.Evaluation criteria: The team determined how well all options for technology were considered. The team determined how well the selected technologies met the requirements of the project. From these, the team assigned a score from Figure 14.Overall importance: 10%Milestone score: 100%

28

4.1.3 End-product DesignDescription: The end-product design detailed all components of the final product. This expanded the functional requirements to include architectural details of the software and implementation-level design choices. The design provided interface specifications for software modules and classes.Evaluation criteria: The team determined how well the design accomplished the functional requirements and facilitated ease of implementing the design. The team assigned a score from Figure 14.Overall importance: 20%Milestone score: 90%

4.1.4 End-product ImplementationDescription: The prototype is the realization of the product design in actual software.Evaluation criteria: The team determined how well the prototype conforms to the functional requirements and design. The team assigned a score from Figure 14.Overall importance: 12%Milestone score: 90%

4.1.5 End-product TestingDescription: The end-product testing ensured that the product is free of bugs and errors.Evaluation criteria: The team determined the quality, usability, and lack of bugs of the software. The team assigned a score Figure 14.Overall importance: 15%Milestone score: 80%

4.1.6 End-product DocumentationDescription: The end-product documentation provides a user manual for the software.Evaluation criteria: The team determined how clearly the end-product documentation described the usage of the system. The team assigned a score Figure 14.Overall importance: 8%Milestone score: 80%

4.1.7 End-product DemonstrationDescription: The final software was presented to the client. The client was informed of the use of the software.Evaluation criteria: The team determined how well the end-product solved the intended purpose of the project. The team assigned a score Figure 14.Overall importance: 8%Milestone score: 80%

4.1.8 Project ReportingDescription: The team created several documents as the project progresses. These included the project definition, project plan, product poster, end-product design, and final report. The final reporting for the

29

project described all aspects of the system and included maintenance documentation that details the implementation of the project. The final report will be the longest surviving record of the project implementation and had to account for any changes to functional requirements, design, and architecture made through the development of the end-product.Evaluation criteria: The team measured how well the final report captures all salient aspects of the project for future reference. The team assigned a score Figure 14.Overall importance: 12%Milestone score: 90%

4.1.9 Final Project ScoreThe result of the project evaluation has resulted in an overall final project score of 89.4% which results in a successful project based on the criteria defined at the onset of the project.

4.2 Commercialization

At its heart, this program is an advertisement for a product, not a product itself, and is an extension of ArcGIS, already a commercial product. The actual product is ISEAGE which charges outside sources for analysis. Therefore, any attempt to commercialize the specification system itself is flawed. The cost to produce the product is no more than the printing or electronic copying costs of the documentation. The price of the ArcGIS extensions must be kept negligible, preferably zero. Because ArcGIS is a fairly expensive software product to begin with, this is not an issue since the primary client is the US government that required it be GIS based and also already has ArcGIS licenses. The potential market is anyone who would like to analyze a network, from graduate students to the Department of Homeland Security.

4.3 Recommendations for Future Work

This section makes recommendations for continued work on the project. This additional work includes items that were passed over in the infancy of the project and items that were passed over during the development of the software as it became clear that time constraints would not allow their completion. It should be noted that the majority of these items were not explicitly defined in the team’s design report, but were items that would be desirable in a finished product.

4.3.1 OptimizationsThe first recommendation for additional work would be to optimize the

specification tool. Due to the time constraints and adapting of 3 rd party software, the team did not have control of all of the capabilities of the software. One option would be to establish a GUI wrapper for the ArcGIS program. This would allow the user to specify a network in less time.

30

4.3.2 Interactive Software Tutorial and Help GuidesThe initial release of the project will include a manual and documentation

on the functionality of the project. However, an interactive tutorial would be useful to the user, providing a visual learning tool that would otherwise be absent in a set of hardcopy instructions.

4.3.3 Pseudo-real-time reportingThe initial release of the project will provide the user with a summary of

the traffic information from the simulation. A possible upgrade would be to show the replay of the results to the user in a graphical format showing what happened as time passed during the simulation.

4.4 Lessons Learned

This section discusses what the team gained from the experience of executing a 2-semester project. Included are things that went well in the project, things that didn't go as well, and what we would have differently.

4.4.1 What Went Well

One of the things that went best was how well the group got along. Despite the fact that the team was all guys and the leader had the bad habit of being testy at times, the team worked together very well.

4.4.2 What Did Not Go Well

The biggest problem the team encountered was when the Internet connection on the computer provided to the team for the project started acting up. This was a major problem as a steady network connection was needed to get the license to the ArcGIS software which was located on a server.

4.4.3 What Technical Knowledge Was Gained

As it turned out, ArcGIS became the centerpiece of the whole project and the team became well-acquainted with different tools within ArcGIS like ArcMap and ArcCatalog.

4.4.4 What Non-Technical Knowledge Was Gained

One of the non-technical lessons the team learned was the importance of building in time for unexpected problems into our schedule. The unfortunate thing is that even though problems were anticipated and time was even built in for those, the team was still not able to follow the planned schedule. Another lesson learned was the importance of inter-team communication. For example, if there seems to be tension between members, it is important for other members to not take sides but reason out the problems. This way all sides feel respected and are more willing

31

to work out problems.

4.4.5 What To Do Differently If Starting Again

If there was one thing htat could be changed, it would be to do a much more extensive job of evaluating risks and building contingency plans to deal with them although whether this is realistic for a class like this is not sure.

4.5 Risk and risk management

4.5.1 Anticipated potential risks and planned management

Loss of Team Member – Although unlikely, the team had to plan for the event a team member was forced to leave the team through internship, medical reasons, etc. The team resolved to keep documentation of all activities, and remain involved with all team activities so that in the event of a team member loss, the remaining group members would be able to take over the remaining assignments the lost member had been working on.

Communication problems – To prevent potential communication problems within the team, the group resolved to meet with the faculty advisor every other week, and frequent email correspondences. Meeting regularly was important to keep team members up-to-date and involved with the project.

Loss of important files – This potential risk was managed by deciding to use CVS which is a document repository that maintains backups and allows users to go back to any version in the past of their choosing.

4.5.2 Anticipated potential risks encountered and success in management

None of the anticipated risks have occurred.

4.5.3 Unanticipated risks encountered

Internet problems – The computer which the team had setup for the use of the ArcGIS software experienced several Internet problems. This caused a serious delay as the ArcGIS installation required a server license. After much troubleshooting the Internet was useable but unpredictable. The team requested a second computer for usage, which had the required software installed on it as well.

4.5.4 Resultant changes in risk management made because of encountered unanticipated risks

After the team started experiencing Internet problems, it became very

32

hard to stay on track. This caused confusion and loss of coordination. The team decided that regular weekly meetings would have to take place to stay on track. If nothing else, the team members would be aware of what the project status was, and what had to be accomplished. The team dealt with the Internet connection problem and proceeded to start working with ArcGIS more extensively.

4.6 Project Team Information

This section includes contact information for the client, the faculty adviser, and the team members. Team positions and major(s) of study are also listed.

4.6.1 Client Information

ISU Information Assurance CenterDr. Douglas W. Jacobson2419 Coover HallAmes, IA 50011515-294-8307 [email protected]

4.6.2 Faculty Advisor

Dr. Douglas W. Jacobson2419 Coover HallAmes, IA [email protected]

4.6.3 Team Members

David C. N. Rodgers (Team Leader)Computer Engineering, Computer Science210 Campus Ave., #6Ames, IA 50014563-333-3008 (cell)[email protected]

Lijin Varghese (Communications Coordinator)Computer Engineering410 Welch Ave., #8Ames, IA 50014847-910-1178 (cell)[email protected]

Derek J. LightComputer Engineering3115 Frederiksen Court

33

Ames, IA 50010515-572-8044 (phone)515-450-0099 (cell)[email protected]

Justin Magnini Computer Engineering217 S 5th, #6Ames, IA 50010515-233-4600 (phone)515-708-1102 (cell)[email protected]

4.7 Closing summary

ISEAGE is a necessary tool to allow professionals to analyze networks, but ISEAGE is useful only for calculation. This project will permit professionals to construct networks and analyze the results, making ISEAGE far more useful and user friendly than it would otherwise be.

4.8 References

GML Specification. Last Accessed: Nov 12, 2004. http://www.opengeospatial.org/docs/01-029.pdf

34

Appendix 1

User Guide

35

Creating ISEAGE Network Specification with ArcGIS

STEP 1: Create a new Map and import layers

o Start a copy of ArcMap

o Open an existing map containing the GIS information to be used with the ISEAGE layer or create a new blank map if desired.

NOTE: ArcMap chooses the default spatial reference for the map based on the first layer added to a blank map. Since the ISEAGE layers do not specify a geographic coordinate system, you may wish to add other layers first.

o Click the Add Data toolbar button, and add the ISEAGE layers to the map

STEP 2: Edit Layers/ Create routers

o Cli

ck the Editor Toolbar button to show the editor toolbar shown in Figure15.

Figure 15 - Editor Toolbar

o From the Editor Toolbar menu, choose “Start Editing” from the menu shown in Figure 16. You will be asked to select the database you wish to edit, choose ISEAGE.mdb

36

Figure 16 - Editor Toolbar Menu

o You may now Create, Modify or Delete features from the layers contained in the ISEAGE database.

o The Edit Tool can be used to selected different objects from the layers.

o The Sketch Tool can be used to draw new objects to add to the layer.

o The Attributes button when clicked will show the attributes of the selected object, which may then be modified by clicking on the Property and typing into the Value field, demonstrated in Figure 17.

Figure 17 - Attributes Window

STEP 3: Export XML document

o After all desired information has been entered onto the map, drop down the menu from the editor toolbar and choose “Save Edits,” as shown in Figure 18.

37

Figure 18 - Save Edits

o Save the map, and open ArcCatalog using the button on the ArcMap toolbar.

o Locate and expand the ISEAGE.mdb from the Catalog.o Right-Click on the ROUTER feature class, and choose Export->XML

Workspace Document as shown in Figure 19.

Figure 19 - Exporting XML

STEP 4: Run XML parser (To be completed, will be done from command line)

38

Appendix 2

ISEAGE Traffic Mapper

Design specification

Version 1.1

Last update: 12/28/04

39

4.9 Overview

The traffic mapper is composed of a single executable that resides on a processor board within an ISEAGE cube. Each traffic mapper is capable of recreating up to 50 routers and has a single Ethernet interface to the outside and an Ethernet interface used to transfer data to other processor boards. Each router on a processor board has a unique ID with ID 0 given to the router that connects to the outside interface. The outside interface can represent up to 10 different IP address ranges each with a router address and a hardware address. There are three types of routers that are supported on a given processor board. Each router can be connected to up to 10 routers within the mapper application. There is a fourth special router (called the input router) which if used is the only router allowed on the board.

Outside_router: The outside router is router 0 and provides a way for outside devices to connect to ISEAGE. This router will respond to ARP requests and replies along with ICMP messages. This router requires a route table and an outside interface configuration table, which are shown in this document.

Internal_router: The internal router has no connection to either Ethernet interface and is used to provide a placeholder for intermediate routers. This router has a route table and will also respond to ICMP messages.

Inside_router: the inside router is used to connect two boards together. It has a route table which is used to indicate which router on which board is connected to the inside router. This router will also respond to ICMP messages

Input_router: This router is used to insert data into ISEAGE from any source IP to any destination IP. The final specification for this router has yet to be completed.

The mapper is configured by a binary configuration file that can be created from a text file using mk_map or as an output from other programs. The format of the binary configuration file is shown below. The format of the text file is documented in the section on the mk_map utility.

This confidential document is property of Iowa State University & the ISEAGE Project.Each router has structure called router_entry that holds all of the configuration information about each router. In addition router 0 referrers to the outside_config structure to determine how to connect to the outside.

4.9.1 Internal router data structures

typedef struct in_if{ unsigned long v4ip; unsigned char hwaddr[6];} in_if;

typedef struct route_table_entry{ unsigned long dest; unsigned char cidr; unsigned char flags; unsigned long next; unsigned short next_id; unsigned short next_board; int interface; unsigned char hwaddr[6];} route_table_entry;

typedef struct router_entry{ unsigned short id; unsigned char type; unsigned char name[ROUTER_NAME_LEN]; in_if interfaces[MAX_ROUTER_INTERFACES]; route_table_entry route_table[MAX_NUM_ROUTE_TABLE_ENTRIES];} router_entry;

4.104.11 Mapper binary Configuration file

Name on disk: mapper.config.# Where # is the board number

Disk file layout:2 bytes – Version Number (Major, Minor)2 bytes – board numberXX bytes - outside_config structure1 byte – number of routersXX bytes – array of MAX_NUM_ROUTERS of router_entry

This confidential document is property of Iowa State University & the ISEAGE Project.

4.12 Mk_map

The mk_map utility is used to convert a text file into the mapper binary configuration file format. The output of the program is a configuration file for each board. The input is a simple text file as described below:

4.13 Text Configuration file format The file is a simple with each line starting with a # for a comment or one of several keywords. Each keyword is case independent and is followed by an ‘=’

Example #This is a test config file for a simple one board test caseboard=0router=0type=outsidename=Outside Router# hwaddr, interface ipaddr, ip range, maskif_out=23:FF:45:12:45:55,192.168.5.254,192.168.5.0,24if_out=23:22:45:12:45:55,192.168.6.254,192.168.6.0,24# interface ipaddr,[hwaddr]if=192.168.7.8,23:22:45:12:45:55if=192.168.10.10,# dest ip addr, mask, board, id, interfacer_table=192.168.5.0,24,1,0,1#this is board number 1board=1router=0type=outside

Key word Parameters DescriptionBoard Board numberUsed to indicate a new board. If not present then board 0

is assumedRouter Router

numberUsed to indicate the start of a router definition. This key word must start each new router.

Type

Outside

Inside

InternalInput

Used to specify the type of the router. More than one type can be specified, if none then type outside is assumedUsed to indicate the router is an outside router (only router 0 can be an outside router)Used to indicate the router is connected to the inside Ethernet interface (can be router 0)Used to indicate an internal routerUsed to indicate the special input router

Name Name Name of the router (30 chars max)

This confidential document is property of Iowa State University & the ISEAGE Project.

If_out

hwaddr

IP addrIP range

CIDR

Used to specify the outside interfaces. Only valid for router 0. Each parameter is separated by a commaThe hardware address of the interface in hex with each byte separated by a ‘:’ e.g. c0:ff:12:34:d4:09IP address of the interface in dotted decimal formatThe network address of the IP range connected to the outside interfaceThe CIDR value for the network address

If

IP addrhwaddr

Used to specify the interfaces for each router. Each parameter is separated by a commaIP address of the interface in dotted decimal formatThe hardware address of the interface in hex with each byte separated by a ‘:’ e.g. c0:ff:12:34:d4:09

R_tableDestMaskFlagBoardIDInterface

Used to specify the route table for each routerDestination IP address rangeCIDR mask for destination IP address rangeFlag to indicate the next router typeBoard number of the next routerID number of the next routerInterface number of the current router used as output

seniord.ece.iastate.eduseniord.ece.iastate.edu/projects/archive/may0525/finalre… · web viewthe...

Documents