Lavie Tobey

Lavie Tobey

Dr. Ralph Grove

 

Summer Internship 2003

CIPP/NSRAM

 

Introduction

           

            This internship is part of a grant that was originally awarded to George Mason, who passed on some of the work to James Madison.  I first heard about this from Taz Daughtry while attending (appropriately enough) his software development class.  Taz mentioned that this grant was looking for a few more students, and I immediately went into action.  Before lunch that day, I had met the bosses and filled out the application.  I feel that part of the reason I got this job is because I showed a tremendous amount of interest and persistence from the start. 

I spent this summer working on the Network Security Risk Assessment Modeling tool (NSRAM), which is part of the Critical Infrastructure Protection Project (CIPP).   I, along with 3 other students, were chosen to be part of this internship.  All of us are computer science majors.  Jae Yoo and Jon Bird are both entering their senior year.  Demitrius Middleton and myself are both entering our fifth year at James Madison.  Also working on the project are full-time staff members Phil Riley, Dan Kane, George Baker, and Ken Newboldt.  Professors Sam Redwine, Dr. Taz Daughtry, and Dr. Chris Fox have also contributed a great deal. New additions to the team also include full-time staff member Subir Vasanth and graduate assistant Kevin (last name).  This summer has certainly been a learning experience, to say the least.  Working alongside the people mentioned, it would be hard not to. 

Prior to this, all my programming experience was in the computer science courses, 139, 239, and 240.  Although those classes provided a firm foundation, much of what I did this summer required research.  Phil and Dan also provided their years of experience to help us along on our individual struggles.

 

The Project

 

When completed, the application will do a multitude of tasks, but the most important is the simulation tool.  The application will use random variables to run thousands of simulations on a user provided system (i.e. a computer network, electrical grid, etc.).  These sets of simulations are called Monte Carlo sets.  By analyzing the data compiled from these Monte Carlo sets, weaknesses and vulnerabilities can be spotted and fixed before disaster strikes.  An application such as this may have been able to prevent an outage like the one that occurred recently in the northeast. 

The application can also be used to test and improve theoretical systems before they are implemented. Since the application provides a way for the user to enter the model, a theoretical model can be entered and experimented on.

We have also incorporated the idea of a scenario into the simulation tool.  A scenario is an event or set of events that take place during a simulation.  For instance, the scenario of an IRC(internet relay chat) attack can be simulated.  By informing several elements in a model that on the Xth pass through the simulation, they are to send requests to a specific server, the user can observe the effects on the over all system.

 

            The project is being written in Java.  We are using a standard Model-Control-View architecture.  The model, namely the engine and data manager, are being written and designed by Phil Riley, Sam Redwine, and Dan Kane, The controller, by Subir Vasanth, and the view (GUI), by the students (with guidance, of course).

 

Rational ClearCase

 

            This project was my first introduction to versioned source control.  We used a program called Rational ClearCase.  ClearCase is quite an amazing program.  Every single class you write is saved on the ClearCase server, and in order to gain access to them, you must check them out, like a library book.  While checked out, you can make any changes you deem necessary.  Once you check all files back in, you can do a delivery to the server, notifying the administrator that some work has been accomplished and it needs to be reviewed and incorporated into the project.

 

 

Netbeans

 

            At the start of the summer, we had experimented with using the Netbeans platform as the platform for our application.  Netbeans is an open source project that contains both an IDE and a platform.  The platform is a bare bones java frame that provides the basic utilities that all programs need.  Netbeans also provides a set of components, similar to those in the Java API, but converted to fit perfectly into the Netbeans architecture. 

The basic unit of Netbeans is called a module.  A module is basically a JAR file that contain certain lines of code in its manifest.  These lines tell Netbeans how and where to install the files in the JAR.  The entire Netbeans application is built using modules.  Usually, any update or modification to Netbeans comes in the form of a module.   My specific task was to learn how to build and install modules into the platform.

            Unfortunately, there is a very steep learning curve when writing Netbeans modules.  The modules are not as simple to write as they would first appear to be.  My first project was to create and install an explorer-type tree view using a Netbeans module.  After about two long weeks of coding, I was able to create the explorer view, but it was far from perfect.  There were many defects in the code, many of which I felt were beyond my capabilities.  After wrestling with Netbeans for two or three weeks, the idea of using the Netbeans platform was put on the back burner.  The plan is to eventually come back to the Netbeans platform.

 

 

Designing a GUI

 

            Since Netbeans had been put aside, our next task was to try and build a GUI from the ground up.  This, too, proved to be a difficult task.  The four of us did, however, make progress and many of the ideas and concepts that we covered are still being applied to the current GUI. 

            One of the main obstacles we continuously encountered was where to start.  Even after we had gotten many ideas down on paper, we still came across this problem.  Some of us felt it would be best to start at the controller level and decide how it should work, while others thought it would be best to start at the user end and work towards a controller. 

            Eventually the four of us got a fairly comprehensive, although flawed, design together.  Once we presented our design of the GUI to the entire team, a decision was made to put us with Dan Kane and together design and implement a GUI.  The five of us worked for two days discussing design.  After three full whiteboards and many a pot of coffee, a design was agreed upon and we went to work coding. 

The design contained four main parts; A “message view” for system messages, a “model view” for the graphical representation of the model, a “tree view” to display a try like hierarchical view of the model, and a “property view” to display the properties of particular elements, or groups of elements in the model.  The controller was also discussed, but lightly.  It had been decided that the controller would be represented by a set of interfaces for now, and later be implemented.

 

The Property View

 

 

            I was assigned to work on the property view.  Over the next two weeks, I worked on coding the property view.  The property view provided a place to display the specific attributes of a particular element on the screen.  The design itself is quite simple, however implementation was a bit more challenging.  One of the main things I kept in mind while coding this view was that it had to look good.  While coding a continuously gathered criticism from my teammate on the look.  Once I agreed on the look of the component, I went to work on functionality. 

Since data comes in many different forms (i.e. integers, strings, percentages, etc), I had to create each one individually.  I ended up with seven different types of data:

1.      Integers – regular integers with no limits.

2.      Limited Integers – values that must be between two numbers.

3.      Decimals – numbers requiring decimal values.

4.      Percents – displays on a 0-100 scale, internally, on a 0-1.0 scale.

5.      Strings – any string of characters

6.      Multiple Selection – a set of possible values exists

7.      Boolean – true or false.

 

For each of these possible data types, it was necessary to create it own code.  Using the programming technique called polymorphism, it would be very simple to add more types of data with very little addition to the hard code. 

            This code, along with all code, also came with the added task of error handling.  This is where things get interesting.  Error handling is an art.  A common term used in the industry is “fail gracefully”.   If something goes wrong, and it is something that you can’t handle in code, fail with as little trouble as possible.  Most likely, anything big goes wrong, my only responsibility will be to notify my superior (i.e. the controller).  However, there are certain errors that I can handle without causing the entire program to become concerned.  For instance, if the user attempts to enter an alpha character into an integer attribute, I can just notify the user without much hassle.  However, if the controller sends me bogus data, a deeper problem may exist that the controller should know about. 

 

Advice

 

            The experience and credibility that I gained simply by participating in this internship will put me at a distinct advantage once I start looking for jobs.  An internship like this one is something that employers look for.  By working in a real life software development environment, I have something that most entry level college graduates don’t have.  My best advice to any computer science major is to do your research and make sure that if any internships, like this one, pop up, that you are the first one to apply.  Interest and persistence go a long way in the hiring process and employers like to see someone who is excited to be part of a team.

 

Best Lesson Learned

 

While working on this project, I was introduced to the concept of layered abstraction.  By using interfaces above and below the actual hard code,  we were able to create a very modular and easily updatable and upgradeable design.  Over the entire summer, I think this was the best lesson learned.  What we did was provide an interface for each of the views.  The interface contained the method signatures of the methods that the controller would need to make calls to.  On the other end, the controller provided a pair of interfaces, one for the GUI to use, and one for the model to use.  Each of us would simply put methods we needed to use into the controller’s interface with a short description, and later, when the controller gets implemented, the writer will know what methods to provide and why.  In the image below, you can see how the interfaces provide a barrier between the controller and the actual components.