--- In AgileEmbedded@yahoogroups.com, Thad Smith <ThadSmith@...> wrote:
>
> > So, to answer your central question, the value of the Conductor in
> > Model-Conductor-Hardware is that it allows the hardware control
logic
> > to be segregated from the business logic.
>
> So do two separate modules, business and hardware.

I think I understand what you mean when you say two separate modules,
but perhaps I don't. We think the value of three modules (Model,
Conductor, and Hardware) over a two module approach is this. If
hardware logic is contained in the hardware layer at all, then it can
only be tested by exercising the actual hardware (something we're
trying to avoid). The MCH approach allows all logic to live in the
realm of automated unit tests that do not require the hardware to be
present to be run. The Hardware layer consists of getters and setters
and ISR handlers. Decoupling the hardware logic from the hardware
allows it to be unit tested in a automated test suite - verifying that
when an interrupt occurs the expected subsequent operations happen in
response (for example, reads from Hardware and operations in the
Model). The Hardware layer is as thin as possible (i.e. no or little
logic) so that hardware logic can be tested independently. Decoupling
is good, so we further separate business logic from hardware logic; it
makes for better design and increased testability.


> > By testing the Conductor,
> > hardware conditions and event handling (interrupts, etc.) can be
> > tested apart from the data handling and number crunching logic of
the
> > Model.
>
> So do two modules, with a test driver for each.

In the system we've put together, we do eventually use a test driver -
in a system test that exercises the full hardware. Otherwise, a unit
test suite tests the hardware logic (C) and business logic (M) apart
from physical hardware.


> What I can imagine from your and Mr. Grenning's examples is that the
two
> interfaces, the MC and CH interfaces, are chosen such that
> 1. The MC interface is in terms of the natural core logic units and
concepts,
> somewhat independent of the particular hardware interface.
> 2. The CH interface is closely aligned to the particular hardware
interface,
> keeping the H layer thin.
>
> With that scheme, the C layer can translate units (as suggested in
Mr. Grenning's
> message), do hardware dependent sequencing, like your example of
taking a reading
> when the timer expires, and probably isolating the core logic from
at the lower
> levels of timing service. One of the keys to that type of mapping,
I think, would
> be determining the proper division between the core logic and the
conductor, since
> it doesn't seem as obvious as the division between the model and the
presenter in
> the MVP pattern: should input averaging be done in the C or M layer,
for example.
>
> Am I getting warm?

If I understand what you're saying, yes, you're getting warm in that
you're working to decouple distinct functions. In my mind, the
division is clear and unit conversion would go in the Model. The
Conductor's purpose is to decouple hardware logic from business logic.
There always seems to be unexpected gains in decoupling distinct
functionality. The MCH pattern encourages that decoupling. In my
temperature example, I see plenty to test. The Conductor would do the
following things:
1. Handle a timing interrupt (loop and check a flag in the Hardware)
2. Tell Hardware to initiate A-to-D
3. Handle the A-to-D complete interrupt
4. Fetch raw values from the A/D unit
5. Call a function in the Model with those values to convert them to a
meaningful number per the temperature sensor's formula.
6. Call a function in the Model to convert the value calculated in (5)
into proper units for the value to be displayed.

All this functionality is "conducting" - coordinating hardware events
and passing data to the right places. There's a lot going on in the
above. The Hardware and Model can be faked out so that order and
correctness of 1-6 can be tested. We can also test the calculation and
unit conversion methods (business logic) in the Model separately from
the Hardware and Conductor. With system tests, we can test that the
Hardware layer is interfacing with the actual hardware properly.


> As a suggestion to presentation, it helps me to see guidelines for
drawing the
> borders. Specifying an interface at some natural or logical level
seems to me to
> be a key here. The example in the paper I read basically had a
pass-through
> wrapper for the conductor, as I recall, so it wasn't obvious what
the benefit of
> such a layer would be. I think a more complex example, showing the
separation of
> the different abstractions at the two interfaces (and corresponding
conductor
> processing) would help me, as well as potentially others.

You're absolutely right. The example we have in the paper doesn't
really illustrate the Conductor's purpose well in that there is only
pass-thru operations and no real hardware logic. The intent of the
Conductor is that it operates much like a Presenter in MVP - receiving
events and dispatching a series of operations that interact with the
Hardware and Model in response. Having this dialogue with you causes
me to see that there is yet some understanding in our heads that we've
not yet effectively communicated.

In the end, MCH is what we've developed. It's worked well for us on
several projects and the basic ideas have precendent in MVP. None of
this is to say that it can't be further refined or entirely replaced.