I use two tools for this. Starting off, I want to try out stuff, so I'm looking for a tool that makes it really simple to play around with ideas - work out what fuseactions I really want, and then what circuits to fit those in. I like Visual Mind (or any other mind mapping tool) for that. Really easy to make changes. At this point, I take my marked up prototype and fill in the fuseactions I have been able to identify. Then, I start filling in those that could not be identified from the prototype. I start with all the fuseactions, then look for common nouns to help me identify possible circuits. If I have "addItemToCart", "removeItemFromCart", and "displayCart", I probably want a circuit called "Cart".
I used to go on and define all my variables with Visual Mind, but then I had to copy them all over into Fusedocs, which was a drag. Now, though, I use Adalon for creating the application architecture. I get a visual tool, which is important to me, and the tools takes my input and produces Fusedocs, circuits, FBX_Settings and FBX_Switch files, and even what Synthis calls an "extended wireframe" or something like that. What it really is is much cooler than the name implies: it produces "fusestubs" for every single fuse in the application. You can run through the application immediately - it produces your first "daily build". As you fill in the actual code, the application begins to start working a piece at a time, like a jigsaw puzzle being filled in. Like John Beynon, I don't work for or have a financial interest in Synthis, but I do think Adalon 2.5 is a huge benefit to anyone doing Fusebox on a regular basis. Prior to 2.5, the people at Synthis asked me, "Why aren't you using Adalon?" I told them I thought the idea was great, but it just didn't support FLiP well enough. "So help us design a new Adalon," they said. So I did. -----Original Message----- From: Steve Bryant [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 4:11 PM To: [EMAIL PROTECTED] Subject: Architecting (was Who Uses Fusedocs?) Hal, That brings up a pretty big point to me. I am a big believer in architecting my applications. I do it on all my medium to large projects. However, I would certainly like to get more information on how other people architect their applications. I feel that the way that I have been doing it is lacking. I have been considering coming up with some higher level Fusedoc sort of thing - something that would map out an entire circuit or an entire application. Right now, I have been doing sort of an OO/UML approach. I generally start with a list of what all will need to be done and I put related tasks together in a circuit. I am interesting in hearing other approaches/suggestions how best to architect an application. At 10:10 AM 5/24/2002 -0400, you wrote: >Keith, > >Just throwing in my 2 cents here. The problem you're describing is a >common one. The reason for it is that the architecture hasn't been >sufficiently thought through before you begin to either Fusedoc or >code. Fusedocs document what you have planned, but if the planning >isn't sufficient, you'll find this out when you start writing your >code. In that case, a decision NOT to write Fusedocs is entirely >rational. > >Architecting an application - especially a large or complex one - is >hard work and sometimes frustrating work. There is *nothing* fun about >throwing away 6 hours of work because my architecting shows me that an >earlier decision will run into a dead end. Still, it's a lot better >than finding this out when coding. > >My experience has been that many of us developers don't spend much time >in architecting an application and that decision leads to a lot of >problems further down the line. I've had this experience in another >area: when I first start doing technical writing, I did magazine >articles. I found that I didn't need any real planning on these; I just >wrote them. When I wrote the first book, though, I ran into HUGE >problems due to my lack of planning. I would get to page 238 and >wonder, "Did I already say this?". I rewrote the book 4 complete times. >What a mess! > >Finally, someone said to me, "You need to architect a book, just like >you architect an application." The thing is architecting a book didn't >feel natural to me. In fact, I really did not like it. I felt I would >be constricted in the actual writing by decisions I made in planning. >It really was uncomfortable, but I stuck with it because I didn't like >the results of NOT architecting the book. Gradually, it got easier and >my fears diminished. I found that, quite apart from my worries, having >a detailed outline gave me a system into which I could put my thoughts. >Now, I'm actually starting to like architecting books and I *love* >architecting applications. ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
