Re: software architecture/design question

Responding to Ma740988...

For starters, I've done my homework and believe this is the right
group. That said apologies in advance if I'm not.
Now consider a system comprised of 7 COTS boards. For simplicity
assume each board had 1 processor - a power PC - but that's irrelevant.
Lets call each processor A, B, C, D, E, F and G.

Processor A serves as the 'master' and is required during initilization
to transmit via ethernet a 'configure' message to processor G. This
'configure' message is a composite type. So now lets assume the
command/response from a to g and g to a is as follows:

struct command_a_to_g { bool configure; };
struct response_g_to_a { bool configure; };

Unpon receipt of a statisfactory ( assume true) response from G. A
will now ask processors C, D and E to configure. Once again upon
receipt of a satisfactory response from C, D and E, A will now ask the
- last processor - B to configure.

By 'configure', each card essentially set's up a so called -
destination channel. Details aside they each allocate a bucket of
memory and each card could see each others memory ( a PCI translation )
that's been allocated.

The important thing though surrounds the fact that their is a
_specific_ order with with each processor needs to set up this so
called 'destination channel'. The master (A) is in control of all
this.
At issue.

Is A pretty much the same sort of hardware as B...G?

If so, then I don't think it should be up to A to understand the configuration sequencing. IOW, A is just another device driver to be configured by some unmentioned entity. One should separate the concerns of configuration _within a system_ from the concerns of configuring individual device drivers. So you need another layer on top of the card drivers to manage the system configuration.

OTOH, if A is explicitly responsible for managing the other cards in its hardware specification (e.g., a VXI Slot 0 controller card), then A is /supposed/ to understand the sequence. In that situation "hard-wiring" the sequence in the A driver as you indicate below is quite reasonable...


I'm not sure how to architect this. In essence setup my composite
type. Here's the brute force approach:

struct command_a_to_g { bool configure; };
struct response_g_to_a { bool configure; };

struct command_a_to_c { bool configure; };
struct response_c_to_a { bool configure; };

struct command_a_to_d { bool configure; };
struct response_d_to_a { bool configure; };

struct command_a_to_e { bool configure; };
struct response_e_to_a { bool configure; };

struct command_a_to_b { bool configure; };
struct response_b_to_a { bool configure; };

A composite type for each command/response. Trouble is that seem
downright _ugly_. So I'm thinking why not one composite type that'll
get passed to every one. They'll check for select 'things' in the type
and a return a 'select' response.
Software architecture/design and I wrestle from time to time so any
help appreaciated.

Whether this is ugly depends on how it is used. I assume there is a generic card driver API that is invoked with the appropriate struct information. So the real issue is "hard-wiring" the order of the calls to the individual cards and using the right struct on each call in the implementation of the A driver. (Assuming A is a special controller in problem space.)

I don't see a problem with that if the data in the structs is initialized based on external configuration data. However, a somewhat more elegant way to use such parametric polymorphism is via specification objects:

[Slot0Controller]
| 1
|
| R1 <<ordered>>
|
| configures
| * R2
[SlotCard] --------------- [SlotSpec]
* specifies 1

Now [SlotSpec] is a dumb data holder for the external configuration data in your structs whose instances are initialized from the external data at startup. Similarly, the external data identifies the slots (B, ...G) so that the R2 relationship can be instantiated.

The sequence of initialization is defined in the order of the R1 relationship as the Slot0Controller "walks" the collection. That can also be defined at startup fairly simply through the external configuration data when SlotCards are added to the collection.

The advantage of this approach is that one can change the sequence and the configuration details without touching the code in [Slot0Controller]. One just needs to modify the external configuration data in an appropriate manner. [If you are interested, the Invariants and Parametric Polymorphism category of my blog has more detailed examples of this sort of parametric polymorphism.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.