[prog] Passing data between modules

[Jacinta Richardson]

I'm coming in late to this discussion because we had some server problems
and had to take it all down and restore from backups and all that kind of
fun stuff.  I wish hardware was as easy to manage as software.  Surely it
should just work and keep working and let me get on with my job?

But anyway, I was going to discuss this question of a huge modular
weather data processing thing.

My first piece of advice is to do it the right way.  If you've got a
Software Engineer (as in taught SE at University or College) now's the
time to use them.  You need to generate a few documents if you want to do
a project this large well.

1.  Software Requirements Specification (IEEE Std 830)
	(see also IEEE Std 1233, Guide to Preparing System Requirements
Specification)

This lists all the requirements for the project.  Working out what you
want before you start it will make designing easier.  Note that you can
start small, design, build and then come back and scope out more 
requirements, design, build, but having a decently scoped out
requirements documentation will save you tonnes of time, hassle and mess.

2.  Software Architectural Design (IEEE Std 1471-2000)
	(see also IEEE Std 1016-1998, Recommended Practice for Software
Design Descriptions)

The top level design.  You've done a lot of this by listing the modules
you want.  This covers how they're going to interact, what their
responsibilities is.  This is not program language specific.

This document MUST specify the interfaces between each module.

3.  Software Detailed Design (IEEE Std 1016-1998)

The lower level design.  This covers how your modules individually work.
This may include classes and methods if OO, or smaller  modules and
functions if not.  This should not be program language specific if
possible, althoug this is not always possible.

This document MUST specify the interfaces between each class/function
where these things are not "private/internal".

As well as these documents you need at least one further one.  

4.  Software Test and Integration Plan (IEEE Std 0829-1998)

This can be written as soon as the SRS is complete.  It should test that
each requirement is met, that all modules have integrated with each other,
and can be detailed enough to include your black and white box testing on
the lowest levels.


It's a huge load of documentation, but it means that the project gets
thought out properly and can then be implemented correctly the first time.
Typically these documents are used in the very expensive (time and
resource wise "waterfall model") but these are just as valid in the
"spiral model" and even at the top level in "extreme programming".
Someone somewhere has to know what the project is going to do, how it's
going to be broken up, what those smaller parts and going to do, and what
needs to be tested.  It's better if all those things get written down
before that person gets hit by the proverbial bus though.

I hope this helps a bit.

	Jacinta
-- 
   ("`-''-/").___..--''"`-._          |  Jacinta Richardson         |
    `6_ 6  )   `-.  (     ).`-.__.`)  |  Perl Training Australia    |
    (_Y_.)'  ._   )  `._ `. ``-..-'   |      +613 9354 6001         |  
  _..`--'_..-_/  /--'_.' ,'           | contact at perltraining.com.au |
(il),-''  (li),'  ((!.-'              |   www.perltraining.com.au   |