A strange attractor exists in a system where behavior is random within a constraint. Usually the results are unexpected. The algorithm we shall use is the Sierpinski (Gasket) Triangle with modifications beyond triangles. You should design for an implementation in C# using Windows Forms.

Attractor with N control points:

1. Specify "n" control points (vertices) in the display window. Let CP[0] .. CP[n-1] represent the control points. I suggest an array of 10 to 30 control points (e.g., maxN = 10). If you have n control points you could add control point n in location (n + 1) mod maxN. Set points with mouse clicks.
2. Assume n >= 3
3. X = a randomly selected control point ( CP[0] .. CP[n-1]).
4. Y = a second randomly selected control point (assume not X).
5. Z = the point halfway between X and Y.
6. Draw Z.
7. X = Z.
8. Continue steps 4 through 7 until the user terminates drawing the attractor.

• Your source files should use .NET auto comment (on line doc documentation).

• Each member of the group must have a separate author dialog to be shown by the about menu. This dialog and the help system should be user defined controls. That is they can be used by other applications and if you use an IB must be selectable in the IB.

• A user interaction style that minimizes menu use. MenuBar should minimally have an file, about, and a usage menus. The file menu provides ability to open and save attractor control points and all properties of control points your application supports. You should also save any other current drawing states.

• Use icon labels and different size fonts on controls (not menu items).

• Handling of user interaction while drawing the attractor. Be responsive to user interaction. This is best done by using a timer to draw attractor points.

• The drawing area should automatically display scrollbars if needed.

• Initialize the control points with mouse clicks. Drawing can not start unless there are at least 3 control points.

• Enable the user to set (change) pixel shape, size, and color of points drawn.

• Have separate display properties (size, color, shape ) for each control point. Display properties of control point (Y) determines how the next point is drawn.
  • Control point properties could be set when point is set.
  • Control point properties could be viewed and changed while attractor is running.
  • Use slider for setting size

• User should be able to select a control point and drag it to another location on the display.

• The current attractor should be serializable into a file with an *.atr extension. You should be able to create (save-as) and load these files. When you open an existing *.atr file the attractor should start drawing. You are not saving a bitmap of the image to display. The control points should be editable, etc.

• Controls should be provided to:
  • Start (or continue) drawing (if at least 3 control points).
  • Stop drawing and retain control points.
  • Clear the display and retain control points, continue drawing. This option clears messy displays.
  • Delete the control points, enabled when in stop state.
  • Reset stop drawing, clear the display and delete control points.

You might want to consider some of these (not part of the required specification). Complete the required assignment before designing and implementing any extensions... Extensions can help your grade, but not much -- do these only if they are of interest to you.

• Interpolate colors between last point and control point.

• Interpolate size between last point and control point.

• When the application is minimized and then restored the attractor should be displayed, not redrawn. This means you need to have an off-screen buffer that you draw to and then display.

• Rotate control points while drawing.

• Save a ChristmanTree.atr attractor.

Submit the executable application, persistent data for 2 attractors, and all source files on electronic media (floppy, zip, and cd -- do not compress any files) in an 8 by 11.5" folder (I will provide some). If you want you can also submit a compressed (zip) file of the project directory in addition to the uncompressed files above. You do not need to print the source files - I'd rather search them with an editor to find what I want to read. Submit printed versions of:

• UML "lite" class diagram - showing classes, fields, methods (this can be hand drawn, drawn in paint or powerpoint program like the class notes, or with a tool like Visio. There are UML tools installed in the CS dept. labs and many have evaluation downloads.

• A "top level" event state transition table or diagram. This can be a UML state transition diagram.

• A 1 page (or less) description of how to run your program

• A printed screen capture of the the attract interface, author and usage dialogs.

• Any other information documentation you actually used to develop the application

• Aany features you want to point out for my appreciation/evaluation If you are pointing out parts of your project for me, please also have appropriate comments in your source files so I can search for the relevant code. Be sure the names of all group members are on the envelop and all other submitted material.

  I must be able to run your program -- this is your responsibility. I don't want to be compiling (and/or debugging) your programs at the point of evaluation. You must test that your submitted program runs on a system different from the one you developed it on. I am grading using the current release (not Beta) version -- Microsoft .NET Foundation V1.1 -- Visual Studio .NET 2003 professional, or Sharp Developer V1.1. If you are using Beta version it is your responsibility to recompile your projects on one of these versions -- they are available in the CS labs on the second floor of JD building.

Groups

You can work in groups of 2 if you wish. Each group has one submission and grade. If a member is not contributing their "fair-share" to the project the group can divorce before September 30. The group must share all work done up to the divorce. An email must be sent to me and the other member of the group requesting a divorce by 11/22/2005. After 8/30/05 groups can't divorce. This is a "no fault" divorce class.

Using Interface Builders

You can use an interface builder for the second assignment. I suggest Visual Studio .NET or Sharp Developer.
Warning. Regardless of the interface builder you use (if you use one) your software design should follow reasonable OOP principles and source code must be readable. When using interface builders many students tend to only use classes not to derive or design classes. Simply dragging and dropping an application together often generates a very ugly design and source listing. Your design and style are evaluated as well and how your application works and looks.