Re: Complex application flow. Best approach ???

Alex,

Perhaps I'm just dreaming and hoping someone comes up with some "magic
technology" that could solve my problem ???

In case nobody does, I guess your advise to try to cut the giant FSM into
manageable pieces might be my only option.

So if anyone knows some "magic" technology, I really like to hear it. :-)

Thanks,
Jan


<alex99@xxxxxxxxxxxxxxxxx> wrote in message
news:1112958484.104612.153410@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Jan wrote:
> > <alex99@xxxxxxxxxxxxxxxxx> wrote in message
> > news:1112833219.263562.50590@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > Hi,
> > >
> > > I'm not sure what you mean by "re-design", do you mean rebuild from
> the
> > > ground up or refactor as in rearrange and refine your current
> > > investment?
> >
> > Alex,
> >
> > Thanks for your advice. Please find my comments below ...
> >
>
> You're welcome.
>
> > >
> > > My thoughts in a few words are refactor and do not rebuild.
> > >
> > > Sometimes it is not possible to leap from where we are to perfect
> code
> > > in one giant step. Often in my R&D I had to write spaghetti first
> > > before I knew what to do next. Everytime I rebuilt those spaghetti
> > > systems from scratch, now matter how much I vowed "this time will
> be
> > > different", I ended up building new spaghetti ;-|
> > >
> > > By refactoring and resisting the tempatation to start over again, I
> was
> > > able to tame the chaos and move step by step towards order.
> >
> > One of the factors pushing us to rebuild, is that we want to port the
> > software from VB6 to VB.NET.
>
> I can understand that, .NET looks hot ... says me who has never touched
> it (yet) ;-| but I'm a great fan of Anders Hejlsberg. Since his Turbo
> Pascal days, then Turbo Prolog, then Delphi and now I'm very confident
> that C#, .Net and VB.Net are just excellent. I wish I had more time...
>
> > On top of that, in meanwhile our knowledge of
> > the weighing-inspection-domain has increased a lot and the current
> > requirements are so different from the initial ones, that I'm still
> in favor
> > of a rebuild from scratch. Without doubt, refactoring will be
> required
> > during the rebuild to keep the rebuild "clean".
>
> Fair enough even the absolutely best written software must /eventually/
> be rewritten.
>
> > > A good IDE is important, it'll let you move things around easily.
> > > Regular backups (or version control) are also important.
> >
> > I fully agree. Guess the MS Visual Studio IDE is not too bad. We
> are using
> > it combined with Visual SourceSafe.
> >
>
> These days we are truly spoilt, so many brilliant IDE's, Visual Studio,
> Eclipse, Netbeans, IntelliJ, and so many more ... They drove me to give
> up vi.
>
> > >
> > > Sometimes nested switches are the best solution other times not,
> one
> > > alternative is the State Pattern, also have a look at some FSM
> > > compilers.
> >
> >
> > I have looked into the State Pattern, I have looked at some FSM
> compilers,
> > but my problem is meanly "how to get this complexity with an enormous
> number
> > of states" into a reasonable design. (be it a state-machine or
> something
> > else..) The problem with the current design is not really the giant
> "Select
> > Case".... The problem is that in each "Case" statement of the
> "Select
> > case", there are still plenty of "obscure and so called intelligent"
> > conditional statements and variables to keep track of context.
> Getting rid
> > of these "spaghetti like conditional-statements" would probably
> result in a
> > massive explosion in the number of states..... How to solve this
> ????? Any
> > hints, any advice ?
> >
>
> Oh I see.
>
> Frankly I may or may not have relevant info for you? 'Many states' is a
> relative term so I'm not sure? You many need some extra heavy duty
> solution but I can only speak from my own experience.
>
> I prefer to just break the problem down into smaller digestible chunks
> and take it from there.
>
> In my current (web) app I have many pages and states. I just break
> things down into Areas, Wizards, Pages, .... when I need to transcend
> those boundaries I just have a cart like "app/session" structure
> (model) that I put and get objects from.
>
> Each Area or Wizard or Page only knows about a /few states/ so I don't
> have a massive FSM issue. Though in reality the entire thing is just
> one giant FSM.
>
> So I have and haven't solved the problem if you know what I mean. I
> solved the giant-FSM problem by avoiding it. I'm not sure if that'll
> work in all cases. I suspect it would?
>
> > I'm also wondering about possible similarities between my problem and
> the
> > implementation of these types of computergames where an "electronic
> guy" is
> > walking or racing and living a life controlled by the player. There
> is an
> > almost unlimited number of states and scenarios, which emerges from
> > interaction between player and "electronic environment". I have no
> idea how
> > these games are implemented, but I can hardly believe, given their
> > complexity, that these games would be based on normal
> state-machines.....
> > Perhaps someone can advise on the technology used and whether
> studying this
> > type of problems might help me solve my own one.
> >
>
> I've written a couple of games, sprites, 3D math, collision detection,
> AI, ... but it's probably simpler if we leave them out of the picture
> and talk in terms of business systems. Gamers will do anything from the
> good, the bad, and the ugly just to make a game look good and play
> well. (BTW, I'm thinking of trying to get an XBox and or Playstation
> developer's kit if anyone has any tips, I've looked into it but it's a
> closed world :-( ... but as I say that's another story ...)
>
> > Thanks,
> > Jan
> >
> >
> >
> > >
> > > Regards,
> > > Alex
> > >
>
> Cheers,
> Alex
>


.