Modularity and Software Engineering in Prodigy

Modularity and Software Engineering in Prodigy

Because Prodigy was partially designed as a test-bed for learning methods programmers need to be able to add new learning modules to it easily. Several of Prodigy's properties are directly designed around good software engineering principles to help achieve this capability. Specifically, the modular design of the Prodigy architecture and the utilization of a uniform knowledge representation (or data structure) with uniform accessibility were all based on software engineering principles.

While having independent and complete modules does seem wise from this software engineering perspective, such self-contained units do present a variety of problems. First, the modules must maintain a uniformity in the interface between separate modules. This is accomplished in Prodigy with its uniform knowledge representation. However, this representation precludes modules taking advantage of differing, more natural (and perhaps more expressive) representations for the individual modules. Secondly, it may be difficult to enable the modules to interact synergistically when insulated from one another. Both articles on Prodigy (see references) mention the desire for this type of behavior. Finally, in an article specifically addressing modularity, Minton discusses the uncertainty of deciding both when to create a module (grainsize) and if a new module is actually the right one (functional decomposition).


Return to the Issues Index for this Architecture.

Return to the top of this architecture.

Go to a Discussion of this issue for multiple architectures.


Current Location: Prodigy-Issues-Modularity

Go to NEXT page.