I like the comparison of MHC to MVP and have found that analogy
useful before. I agree that you want a very thin layer covering the
hardware. I also think the model is benefits from not knowing the
form that readings come from the hardware. the conversion should be
unit testable as you suggest, so having it in the H part looses that.

1:1 alignment with MVP should not be your goal, but having a testable
design with clear separation of concerns should be. I would break
the MVP parallel in favor of having a hardware abstraction that
allows evolution of the hardware implementation. The conductor seem
like a fine idea.

when people do MVP and MVC here are not just three modules
(classes). There are the three roles. In these roles there are
often additional structure. I think your very thin hardware laver
could have a also very thin normalization laver over it specifically
for things like A/D where numbers of bits and calibration might be
needed. I suppose that the normalization could happen on the way
into the model as well, but it seem more natural as a part of a
hardware abstraction.

I would emphasize as it seems you are, keeping the hardest part to
test automatically really thin, your H. But keep the M very
independent of the hardware workings could be valuable when
supporting multiple hardware versions. maybe you have only one, so
maybe this won't matter or not until later anyway.

What you are doing sounds like very good work.

With test environment you described, what is your edit, compile,
link, download, run cycle time?

James

On Jan 11, 2007, at 9:50 PM, mkarlesky wrote:

>
> --- 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]
>
>
>

--------
James W. Grenning
Object Mentor, Inc.
cell: 847-331-9942
www.objectmentor.com
blog.objectmentor.com
--------





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