CS 232 Project 1.5: User Interfaces and Reuseable Code

Overview: Good coding style separates a program's computation (aka its Model), its user-interface (aka its View), and its control code (aka its Controller), because doing so maximizes the amount of reuseable code in the application. Software engineers know this as the MVC (Model-View-Controller) pattern, which is often structured as follows:

In this assignment, we will apply this pattern to our hostinfo program.

Details.

This project is to rewrite your hostinfo program in a more object-oriented fashion. The trick is to write it in such a way that a maximal amount of your code is reuseable. To gauge this, you are to build two user interfaces:

1. A console-based command-line-switch-driven user interface (behaving exactly like the one we used in Assignment 1), plus
2. either:
   1. A console-based menu-driven user interface, with a loop that let's the user keep retrieving information without re-running the program; or
   2. A graphical user interface (your choice)

To accomplish this goal, you are to isolate hostinfo's core functionality in a separate Model class. You should also build a class for each different View or user interface (e.g., CommandLineSwitchInterface, and a Controller class for each View. These Controller classes can then

1. Create an instance of the View to get values from the user and displays the results; and
2. Create an instance of the Model that provides methods to retrieve the host's information.

Your driver program hostinfo.cpp should be fairly simple:

1. Evaluate the command-line.
2. If the first switch exists and specifies command-line (e.g., -cl), create an instance of your the Controller for your command-line interface, passing it the command-line information (argc and argv).
   Otherwise (by default), create an instance of the Controller for your other interface class.
3. Send the Controller you've created the run() message to get it to perform its task.

If you find yourself writing redundant coding for any of these classes, store the redundant coding in a superclass, and derive your classes from this superclass. In a "worst case scenario", your design might look something like this:

Plan of Action.

1. Review your solution to Assignment 1. Identify what parts of your code contribute to the user-interface (the View), what parts control the execution (the Controller), and what parts are the core of the the "hostinfo" computation (the Model).

2. Decide which user interfaces you are going to provide, and design them to perform their task. Design each user interface class to get the information from the user, providing methods whereby the Controller can retrieve the information from the View.

3. Implement the Model, Controller, and View classes, as well as any superclasses needed to consolidate code these classes have in common.

5. Rewrite your host driver so that it checks the first command-line switch (if any), creates the appropriate Controller, and then sends it the run() message.

When your program is working, compare the results it produces to those of your previous version. (There should not be a significant difference.)

You are encouraged to recruit one or more people from outside of this class to serve as user-testers to evaluate your user-interface. If a "newby" cannot use your program, then your user-interface should be revised.

As before, you are free to talk to your classmates about algorithmic details, and general approaches you use in this project, provided you give proper credit in your documentation to ideas that are not your own. You are not to look at anyone else's code, for any reason.

Honors: Build all three interfaces (console-command-line, console-menu, GUI), each supporting the ability to request and retrieve information about the host.

Turn in: The project grade sheet, attached to a script file, in which you do the following:

1. Use cat to list the files you created for this project;
2. Use make to successfully compile your program; and
3. For each of your user-interfaces:
   Execute your program, showing its capability to process the various inputs (including invalid ones).

CS > 232 > Projects > 1.5