--- In AgileEmbedded@yahoogroups.com, James Grenning <grenning@...>
wrote:

> I think the something (Hardware or Conductor) might want to hide the
> hardware a little more by normalizing the temperature. so the model
> deals with degree's C, K, F, R as suitable, and does not have to
> worry about the scaling of the A/D values. This lets the model deal
> in the problem domain abstractions, making that code able to better
> stand the test of time.

The intent of the MHC pattern is to allow for maximum automated
testability; it does this by decoupling hardware from code. In MVP the
same thing is accomplished in decoupling widgets from event handlers and
code. If temperature normalization happens in the Hardware layer then
the only way to unit test the normalization is to exercise the sensor
hardware directly and use a debugger to inspect normalized values (one
of the things we're trying to avoid). If, instead, the normalization
code is simply a function in the Model that accepts raw A/D values, then
the vast majority of all the code can be tested apart from the hardware
in a unit test framework (we wrote a very small C-based framework for
just such a purpose). Doing this means we only have to ensure that all
the MCH triad components are "wired up" to pass data back and forth (if
they're not, it becomes quite obvious). It is conceivable that
normalization could happen in the Conductor. This would certainly allow
us to unit test the normalization. However, it violates the basic
architecture of the pattern in that the Conductor is really a conductor
- coordinating events and the transfer of data between the hardware and
the system logic. Temperature normalization fits very nicely in the
Model. I must admit that I don't see how a normalization function along
with a separate temperature calculation function in the Model will not
stand the test of time. Separating those two operations is good
programming practice - as you've pointed out. However, placing one
inside the Hardware layer makes automated testing difficult.


> Do you try to test the model and controller on the development
machine?

There's a variety of ways to run the unit tests (as I mentioned, we
wrote a small C-based unit test library & most recently we've been using
Ruby to auto generate C-based mocks to complement those unit tests).
It's possible to cross compile C code and run the Model and Controller
unit tests on a development machine instead of the target system. To my
knowledge, we've not yet done this. Another alternative is to run the
tests inside an emulator on the development machine; this we have done.
We've also used build scripts to grab a few tests, compile them together
with the production code, transfer that to the target system, run the
tests on the target system, and collect results.

At some point in the near future, we'll release our small embedded unit
test framework, Unity, to Open Source.

We've used our Model-Conductor-Hardware pattern and our unit test
framework on very small systems (e.g 8 bit PICs with 16k of program
memory and 255 bytes of RAM). It works well.




[Non-text portions of this message have been removed]