As we have seen, there are time and size penalties for using an object-oriented approach instead of a procedural approach. However the object-oriented approach allows us to build models that can be reused in a variety of different contexts, ranging from reuse by other applications, to reuse by adding a new user-interface.
In the Model-View-Controller pattern, the the Model (core functionality) of an application is isolated in one class, separate from its View (user-interface), and a driver (the Controller) coordinates the interaction between the two:
In this pattern, the Controller drives the behavior, getting information from the user-interface, passing it to the Model, geting the result(s) from the Model, and displaying them for the user. Each View can have its own Controller, or one Controller can coordinate multiple Views. The Model cannot "know" or assume anything about the View (user-interface), nor can the View "know" or assume anything about the Model.
By decoupling the core functionality from the user-interface, the resulting Model is easier to upgrade/maintain than its procedural counterpart.
Spend some time thinking about the forest-fire simulation problem. Look over its source code, and then write a paragraph that describes the behavior of simulation, giving a reasonable level of detail.
What are the nouns in your description?
What are the verbs?
Using these, construct a UML diagram for this problem.
When you are finished, compare it to mine. Modify yours if necessary.
By consolidating common code in superclasses, and isolating reuseable code in other classes, the OO approach allows us to build components that are reusable across multiple applications with a minimal amount of redundant code.
While this approach will undoubtedly incur a performance penalty, that penalty may be offset if the result makes it possible to write or maintain our high performance programs in less time. So some questions we want to address are these:
Build skeleton classes for each class in your UML diagram, with the has-a and is-a relationships indicated by the diagram. Create "stub" methods for each operation. Make sure that the name of each method is a verb, and the name of each class is a noun.
The resulting set of classes make up a framework that (with some work) will solve the problem.
This week's assignment is to "refactor" the C code from the parallel model you wrote last week into your OO framework.
Make this OO code as time-efficient as you can, without sacrificing the benefits of OOP. For example, use inline functions/methods wherever practical, to avoid the overhead associated with subprogram calls. (These will trade off size for speed, making your program potentially larger but faster.)
When you get your model working properly, compile it using the -O3 compilation flag. Then use the cluster to compare its performance to the procedural (C) version. Try to quantify (as a percentage) how much of a run-time penalty the OO version incurs.
Also compare its size to that of the procedural version, and quantify any differences there.
Create a separate View/Controller that uses the C stdio.h library instead of the C++ iostream library. Compare its size to your first OO version and your procedural version, and quantify the difference.
Can you find any other tricks to reduce the size of the C++ version?
|
Up to the HPC Homework Page |
Up to the Calvin HPC Course Page |