Re: [Adonthell-devel] Source Code reorganisation

[Kai Sterker]

On 09 Dec 2001 18:04:51 +0100 Alexandre Courbot wrote
 
> Why not separating the map stuff and future other stuff (like fights)?
> If we put everything in a data module it may turn messy.

Sure. As I said, it might be neccesary to divide some modules even further.


>> That would possibly be best. But as I said, we should get a pretty good
>> idea first what modules we'll have. Doing a complete design of the
>> framework before wildly moving stuff around might save a lot of work in
>> the long run. I can have a look at my Software Engineering papers and see
>> which of the methods in there suit us. I remember that there were a few
>> dealing with modeling modules and their interactions. 
> 
> That's a pretty good idea.

Okay. I don't have the stuff here, so it'll be probably tuesday before I
can post something definite.

One thing I remember pretty well, but I am not sure whether it will fit in
our situation: DFD's (Data Flow Diagram) after Yourdan/DeMarco. As the
name suggests, it mainly concentrates on the data flow and input/output
transformation between different modules. However, it came to my mind as
it starts at a very high level and gets more and more detailed.

Basically you start on level 0 with a context diagram, which shows The
Program(tm) and it's in- and outputs. Something like

                                           Map-data
      +------+  Commands    ---------     Map-updates  +-----------+
      | User |----------->/ Adonthell \<---------------| Adonthell |
      +------+<-----------\  Client   /--------------->|  Server   |
                   Map      ---------      Commands    +-----------+

That's far from complete, but ASCII is pretty unfit for complex diagrams ;).

Anyway, on level 1 you start to break the program into 3 - 7 modules with
the data flow between them. At this point data stores get introduced. They
represent persistent data (kept in files or a database). 

Each of the modules you get on level 1 are divided again (and again and
..) unless stuff is detailed enough. There are some rules of thumb when 
to quit, but I cannot remember them right now ;).

The main emphasis lies on the data flow and transformation, but by 
modelling that you also get a good idea of the modules you'll need and 
how they interact.

I did a search for online references of those DFD's, but I haven't
found anything useful.


Anyway, I'll give this a closer look next week.

Kai