Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Spring 04 Midterm 2 Review: Tools for Space Scientists
1 Data Collection Documents: Containing live satellite data in a form appropriate for doing numeric calculations with.
2 Data Visualization Documents: Does 2-D and 3-D graphs of satellite data linked to it.
3 Data Planning Documents: For organizing modules both on the satellite and off for gathering and processing sensor data.
a. Explain how one (your choice which one) Design Pattern would be useful in building this application. Draw a UML class diagram of the portion of your design where the design pattern would be useful. (Note: You are not drawing the whole class diagram, nor are you showing me the structure of the Design Pattern. Rather, you are showing me a few classes in your application whose design would be based on the Design Pattern you've selected.)
All) The Satellite itself could be a Singleton. There is only one Satellite, but all of these documents need to look at it. A command by any of them should affect the satellite for all of them as well.
1) Adapter. The satellite provides data for you in a format that the satellite reads, but we need it in a format that is good for numeric calcutations. Adapt the Satellite to provide the data in the format that the DCDs need.
2) Factory (or Abstract Factory). We need kinds or families of graphs, but don't actually care what is necessary to visualize them. The user isn't going to request Graph3DTerrain or Graph2DTerrain, they'll ask for a terrain graph and want have multiple views. Each of these views will have the same interface, and the implementation needs to be transparent to the user.
3) Bridge can apply to the classes used to gather data on or offline. Where we're getting data shouldn't be important, just that we're getting it. The implementation is unimportant, but we'll always be requesting the same type of data. Bridge works well here, because the data gathering class can best decide how it will gather that data for others to use.
b. The Space Scientists think this object-oriented stuff is just silly. "Fortran was good enough for my advisor and for me and for my students," they say. "Why not just use that?" What are the advantages of object-oriented design and programming for this problem?
Note: I think my answers here are bad mostly because I'm not sure what these scientists need. I have no idea what Space Scientists do or how anything could help them.
Simulation is more productive in O-O. Look at simula. O-O was designed for simulation, and space is an important place for that. You need good simpulations and testing because you can't always be there in space.
Space is a horrible environment. One needs to see how each component will behave in the environment. A component oriented model will make it easier to test scenarios like "What if the ??? breaks while in space?" You can see if the error cascades through other classes or not. Each class can decide how to deal with this error, rather than the system having to constantly check on it. Each component will then be more self-reliant.
The patterns above help common problems in your programs. O-O brings these, and many others, with them.
a) For the suite, I'd use a factory pattern. This allows for the subclass to define what type of document it wants to be (Data Planning, Data Collection, or Data Visualization).
Link to this Page