Comparing to some other project I am involved with, simutrans is actually quite hierachiacal structures, as it was a learning project for OOP once.
It starts all with karte_t, which holds an array of planquadrat_t (a 2D coordinate), which holds arrays of grund_t (the actual ground, or foundations, tunnel, bridges, highways, water). Each ground holds a dinglist, which contains stuff (as dinge = stuff), like moving stuff (car, trains, airplanes, .. ) and other stuff like buildings, trees, ... The stuff is derived from ding_t and sits all in dinge/ folder.
Each stuff can have three periodic calls: for very regulary and fast actions which require exclusive access on the map (moving cars, collision avoidance) there is sync_step, called before every frame. Slower actions like route_finding, way building etc. is done in step(), where the map can change in between slightly. Some objects (most notable trees) require seasonal changes, which are covered by the relatively new action method of check_season();
The UI is completely separated from this. All dialogues are nowadays derived from gui_frame_t and fully object oriented.
Moreover the program was developed by a single person most of the time. It was a challenge enough, without writing documentation (which is for me rather like work, and surely not a spare leisure). There was some sketches from early development, which still holds, but the site containing them is currently down.
Honestly, I had to google what an uml diagram is. The wikipedia page is quite good for falling asleep while reading. I will translate the above stuff into UML. Not sure that will help you though ... [Ok, the two programs I looked are nearly completely unusable without reading lots of specs and manuals. Well go ahead and create a structure like I said above]
But other than that, most of simutrans is quite local and quite separate from other modules. Therefore it is imho best to just work locally on one issue, and submit a patch. You will get some critical reception then.
