CS446 System Requirements

Summary
Your system is to provide flight planning for a VFR, cross-country flight of multiple legs. You are to compute time and fuel for each leg and include the legally mandated 45 minutes of reserve fuel. Totals as well as incrementals for time and fuel are to be calculated, and altitude, temperature, winds, and pressure are to be taken into account. You may assume a single altitude for the flight, whose stages will include:
1. Taxi and run-up
2. Take-off and climb to altitude
3. Transit to set-heading point
4. Transit to each waypoint
5. Determination of descent point and transit thereto
6. Descent to pattern entry
7. Entry into pattern, landing, taxi

More specifically:

  1. All geographic information will be given in terms of True Track (TT) and Distance (D) from a known point.
    In particular, a full flight itinerary will be given as
    • TT and D from Take Off (TO) to Set Heading Point (SHP)
    • TT and D from SHP to First Way Point (WP1)
    • ***
    • TT and D from WPN to Destination (Dest)
  2. The user should be able to provide
    • Altimeter setting (Alt), Temperature (Temp), Wind Track (WT), Wind Velocity (WV), Elevation (Elev)
      at ground level at TO, Dest, and any WP
    • Winds Aloft information (WT,WV at 3000, 6000, 9000, ... and Temp at 6000, 9000, ...)
      for TO, Dest, and any WP
    • Power setting (Engine RPM)
    • Descent in Feet Per Minute (FPM)
  3. The system should use TO altimiter, wind, and temperature information for take-off, climb, transit to SHP.
  4. The system should use the corresponding Dest information for descent, entry into pattern, landing
  5. The system should use interpolated altimiter, wind, and temperature information using the nearest two information sites for transit from SHP to Descent Point (DP)
  6. The system should compute stage time, total accumulated time, stage fuel, and total accumulated fuel for each stage of the flight
  7. The system should be able to compute the DP
  8. The system should account for the legally required 45 minutes of extra fuel to report a total fuel requirement

The Spreadsheet Example Annotated
The spreadsheet planner example that was handed out in class is available through this link with explanations.

A Growing List of Questions and Answers
The requirements document states that the user may specify "Altimeter setting (Alt), Temperature (Temp), Wind Track (WT), Wind Velocity (WV), Elevation (Elev) at ground level at TO, Dest, and any WP." Although we believe this point was addressed at an earlier briefing session, this is a matter of some contention within our company and as such, we would appreciate clarification of the use of the phrase "any WP". Does this mean that the user can specify Way Points for which no Alt, Temp, WT, etc information is provided? That is to say, can the user define a Way Point without providing a full range of data for that Way Point, and if so would we be correct in believing that the missing data should be interpolated from the two nearest WPs for which the information has been provided?

I will guarantee to provide Alt, Temp, WT, WV, Elev at TO and Dest. Indeed, you are encouraged to accept both a ground level and an "upper winds" report for these locations (that is Temp, WT, WV is given at ground, 3000', 6000', 9000', 12000, 18000';) (Elev. and Alt., of course, apply thoughout all altitudes.)

As for any WP, I may or may not give that information (ie. a WP may come WITHOUT any information about Alt, Temp, WT, WV, Elev. In such case, to obtain that information, interpolate linearly between the nearest such information ahead and behind.

On a further point of detail, if the user can indeed omit certain information from a WP, is the user constrained to provide either all of the information or none of the information, or can the user provide whichever of Alt, Temp, WT, etc he or she desires?

If the WP does have associated information, none of what you want will be missing. That is, whatever you need at TO and Dest will also be provided at the WP (ie. all of the above mentioned information).

A similar question arises in the specification of Winds Aloft information. Are there certain specified altitudes for which this information is provided, or can they be specified for any discrete range of altitudes?

One odd thing about the 3000' report is that it comes without associated Temp. Since you know the Temp at the ground and you know how Temp decreases with altitude (the "lapse rate"), the Temp at 3000' is always just approximated by the ground Temp minus the difference between 3000' and the Elev times the lapse rate. This estimate is much less accurate as you go higher, so actual temperatures are given at the other elevations.

Words of Wisdom
Your object is not just to slap together a system that computes flight plans in any way that can be managed. You must pretend that you are developing a product that you hope to sell and continue to maintain and develop for a significant lifetime. You want to design for clarity, flexibility, consistency. You want to use object oriented techniques to achieve this. You want to recognize, through abstraction, any elements of communality and any elements of utility and infrastructure that will simplify the design of your system, regularize it, and organize it elegantly. You will be judged on quality.

(In the following, an "agent" can be a procedure, an object, a class, a module, a subsystem)

* Encapsulation/Information Hiding
The details of an agent's representation and implementation should not be revealed unless absolutely necessary. If details have to be revealed, the design probably needs to be improved. (at the very least: no system-global variables, no public variables, but that is not the whole issue, merely a trivial observation.)

* Locality
Code that provides related services should be organized into a common, coordinated set of agents (and files). Each agent should be responsible for a clearly defined, clearly delimited number of services and data.

* Cohesion
Distinct functionality should be in distinct agents. Each agent should represent a logical, focussed coordinated set of services. (certainly not: everything gummed together into a single class or class hierarchy -- Note: the idea of a GP "sector" is that it is the container, the locality, of a cohesive functionality represented by as small a group of agents as possible)

* Abstraction
Look for generalizations for groups of agents you are thinking about designing. Concentrate the common behavior and the shared data that you find for a group of agents into a single, abstract agent, and represent the particularities of the actual agents as variations and additions. (hierarcy: the abstraction is a base class and the actual agents are derived classes forming an inheritance *tree* of "is-a" relationships -- Note, even if you only have one agent, such as an employee, you should imagine you will have several variations on that agent in the future and design for abstraction; this is how you will gain flexibility in your system)

* Composability
Agents that must carry out a broad range of activities are best designed as a composite of simpler agents, each of which specializes on some related set of activities. (has-a/uses-a: a composite object has other objects as member data; the composite provides services and actions simply by invoking the services of its member objects; this is the best way of resolving the tension that may arise between following the principles of locality and cohesion while building a system in terms of complex agents; this is the standard principle of divide-and-conquer/levels-of-detail design reformulated for object oriented design)

* Loose Coupling
As few pairs of agents as possible should interact with each other, and when two agents interact, the complexity of their interaction and the variety of information they exchange should be minimized. (observe: long argument lists to procedures should be avoided, bunches of data used together should be combined under a common name, strive for data-flow and interaction structures that involve few nodes and few edges, minimize the number of member functions in classes)

References
For some further amplification of Object Oriented Design approaches, look at OOD Notes 1 and OOD Notes 2.

For more direct information on the elements of C++ syntax that relate to these principles, I remind you that the course web page has a good C++ Tutorial link.