I just joined this group after seeing a message on comp.software-eng
by Mike Karlesky. I followed some links he provided and found an
interesting article, Effective Test Driven Development in Embedded
Hardware <http://atomicobject.com/files/EIT2006EmbeddedTDD.pdf>. It
has given me some ideas to pursue in my own development.

One thing I don't understand, though, is the point of the Conductor in
the Model-Conductor-Hardware (MCH) pattern. The model appears to be
the application logic (model appears to me to be a misnomer). The
hardware interface layer makes sense. The conductor seems to be a
layer without a purpose.

Since there was mention of being derived from the Model-View-Presenter
pattern, I followed a link to a paper on that topic. My understanding
from reading that paper (this is all new), is that the MVP is used for
GUI applications and that

1) the model is the application logic (model again seems a misnomer),
2) the view takes information from the application domain and maps it
to the user display and back, handling the issues of grouping
displays, mapping events and messages to application functions and
data. That I understand.
3) the presenter is the thin GUI layer that is worked around for
automatic testing.

I see the correspondence between the two model entities, and the
presenter and hardware layer for testing purposes. I don't see a
purpose for the conductor in MCH similar to the logic that is handled
by the view entity in MVP.

If there is no logic and everything maps straight over, wouldn't I
have a simpler system by eliminating the conductor entity?