Fusebox

How to use Adalon with Fusebox and the Fusebox Lifecycle Process How Adalon supports Wireframing How you can architect a Fusebox application in Adalon How to generate Fusebox code skeletons that are fully Fusedoc'd

Audience
This tutorial assumes that readers are familiar with Fusebox and the basic concepts of Web application design. For background information on Fusebox please see:

http://www.fusebox.org

Before Getting Started
Before starting the tutorial, some readers may want to familiarize themselves with the basic concepts of Adalon and Adalon's unique support for Fusebox.

Adalon Overview Fusebox Support in Adalon

Sample Project Scenario
The customer for our sample project is Acme Corp. Like many other companies, Acme wants to promote collaboration among its employees. In order to facilitate the sharing of information, Acme Corp. wants to create an online discussion forum where employees can discuss everything from Web application functional design concepts, to Adalon, to Fusebox development. The project will be called "Acme Message Board."

Methodology
This tutorial will illustrate how to use Adalon to build a Fusebox application when using the Fusebox Lifecycle Process (FLiP). FLiP was originally developed by Hal Helms and the Fusebox community to support Fusebox application development. Adalon can also certainly be used effectively by teams who use other development methodologies such as the Rational Unified Process (RUP), for example, or one of the various Agile Methodologies. FLiP, however, employs a straightforward waterfall approach to development that helps succinctly illustrate all of the capabilities of Adalon. Additionally, readers not familiar with FLiP should be able to easily follow along.

FLiP divides an application development effort into a number of distinct activities and phases:

1. Wireframing -   Wireframing is a technique used to rapidly define a high level outline of basic application functionality and system requirements. This stage corresponds to what many other methodologies refer to as the "Analysis" phase.   Associated Adalon/Tutorial Activities: Creating a New Project Developing Wireframe Diagrams Documenting Application Requirements Generating HTML Wireframes     2. Prototyping -   The result of the Prototyping phase is a complete HTML mockup of an application. The great part about creating an HTML prototype is that it is a relatively inexpensive way to force customers, designers, and developers to completely define all application requirements. This stage corresponds to the Requirements and Design phases of other popular methodologies.   Associated Adalon/Tutorial Activities: Creating a Prototype Marking Up Your Prototype     3. Architecting -   This phase is about analyzing and defining how this application can be brought to life using Fusebox. The project architect designs all Fusebox elements based on the HTML prototype. The architect defines all of the Circuits, FuseActions, Fuses, and XFAs that make up a project, and creates all of the Fusedocs that define the inputs, outputs and responsibilities for each individual code file.   Associated Adalon/Tutorial Activities: Creating Fusebox Architecture Diagrams Connecting Screens to XFAs Designing your FuseActions Circuit Structures Fuse Design Defining Fuse Input and Output Data Fields Layout & Global Navigation     4. Coding -   After architecting a Fusebox application, coding should be a simple process of filling out the "work order" that is defined by each Fusedoc.   Associated Adalon/Tutorial Activities: Fusebox Code Generation

Let's get started by creating a new Fusebox project.

Step 1 - Creating a New Project

When you first create an Adalon project, you are creating a blank foundation upon which you can build your entire project, from wireframe, to requirements, to design, and finally to a development-ready code skeleton.

Step 2 - Quickly Creating Detailed Wireframe/Sitemap Diagrams

With Adalon, you can quickly and effectively capture a high level understanding of the functionality that the customer is looking for. Adalon allows you to rapidly create detailed wireframe/sitemap diagrams, and effortlessly generate a complete HTML wireframe click through of your application that can be shared with the customer.

Step 3 - Using Requirements to Make Wireframing Even More Powerful

In addition to allowing you to document screen responsibilities, like traditional wireframe tools, Adalon also allows you to globally document and track application requirements. You can create Requirements elements for each individual customer requirement and associate those Requirements with the various design elements that support that requirement.

Step 4 - Generating HTML Wireframes

After your wireframe design is complete, you can generate HTML wireframe click-throughs, or generate advanced wireframes that include your diagrams as clickable navigation.

Step 5 - Creating a Prototype

Building off of the wireframes created in the previous section, designers and HTML coders can confidently begin to construct their HTML prototypes. Note that Adalon is not an HTML code authoring tool, so it is left to the developer to use their favorite IDE to create the HTML prototype. Below are example prototype screens that could be developed based on our initial wireframing and requirements analysis.

Step 6 - Marking Up Your Prototype

Hal Helms developed a very elegant technique to bridge the world of prototypes into Fusebox architecture design. For simplicity, it is called "Marking up your Prototypes" and is an intuitive process that helps you begin to lay the foundations of your Fusebox architecture. Marking up your prototypes is very simple. This is what you do:      1. Print out each screen in your prototype. 2. With one color pen, circle every element on each printout that takes the user off of the page. This includes hyperlinked text and images, menu choices, form submit buttons, etc. 3. Next, give each element that you circled a name. These will become your XFAs. For example, a button that has the label "Submit" on it might be named "XFA_SubmitForm." In our example, a link that displays the list of messages inside a particular forum is given the name "XFA_ListMessages." 4. With a different color pen, write down what action should be performed as a result of clicking on each one of your circled items. For instance, if you have a login form and the submit button says "Login," your circled element (XFA) may have been called "XFA_Login" but the action that will be called is "ValidateUser." These new items will become your FuseActions. Most of the time FuseActions are a combination of a verb and a noun as in the case of "ValidateUser." Many times the XFA name and the FuseAction name are similar. That is OK. As long as you are consistent in the way you choose names for your XFAs and FuseActions, you will end up with an understandable design. 5. Because we are building a Fusebox application, we know that every screen is the result of calling a FuseAction. To finish marking up your prototypes, somewhere on each print out, write the name of the FuseAction that will create the screen you are currently looking at. For example, on a generic user welcome screen, the FuseAction might be "WelcomeUser". In the next steps, we are going to duplicate this "pencil and paper" design work in Adalon. Some users are able to look at a prototype in their browser and directly duplicate this process in Adalon, bypassing printouts. For people who like to work things out in their heads and on paper first, this technique encourages quick and thorough analysis, and gives you a great repeatable process for launching into your Fusebox architecture. Click on any of the screen shots below to see how we marked up the AcmeMessageBoard prototypes.

A Note on Global Navigation
At this point, you may have noticed that the wireframe diagrams created in Adalon do not completely match the prototypes that were created. The difference is that the prototypes add in global navigation links that were not included in the Wireframe. It is common to leave out global navigation because the number of links that that would have to be created and maintained would quickly become unmanageable.

When it comes to architecting your application, you as the architect get to decide how you want to handle things like global navigation and nested layouts. Fortunately, Fusebox was built to help us solve many of the complex problems.

To effectively model and build AcmeMessageBoard, we will consider the global navigation to be a separate piece of functionality for the time being. Almost as if it were in a separate frame. Towards the end of the tutorial, we will show you how to model the global navigation and integrate it with the rest of the project. The first diagrams that we will create will not take global navigation into account.

Step 7 - Moving from Wireframe to Architecture Diagrams

An easy way to move from your wireframe diagrams to creating designs for your Fusebox architecture, is to have Adalon make a duplicate of your existing wireframe diagrams and use them as a starting point.

Step 8 - Connecting Screens to XFAs

If you went through the process of marking up your prototype, the next two steps will simply be a process of entering that XFA and FuseAction design information into Adalon. In this step, you will create an XFA for each element you circled on the prototypes and connect the appropriate Screens to those XFAs. If you did not mark up your prototype, you can certainly use Adalon as your "pencil and paper" and go through the same mental process you would have as if you had printed the prototype pages.

Step 9 - Designing Your FuseActions

This step is a simple continuation of the previous step. Using our prototypes as a guide, we are going to add the appropriate FuseActions to our diagram. When a source FuseAction was identified as being responsible for generating a particular Screen, that FuseAction will be connected to the corresponding Screen on the diagram. XFAs will be connected to the FuseActions that they were designed to call. After all of the information from the marked up prototype has been entered, the Architect will still need to account for design information that was not readily apparent on the prototypes. This is particularly true in cases where one FuseAction calls another FuseAction, and where a FuseAction can have multiple outcomes.

Step 10 - Designing Your Circuit Structure

With Adalon's new Fusebox Tree, creating Circuits and assigning your FuseActions to them is a piece of cake. You can also use the new Fusebox Tree to view your Fusebox Architecture in a traditional mind mapper type of hierarchy.

Step 11 - Fuse Design

Fuse design in Adalon's new, enhanced support for Fusebox makes Fuse design as simple as drag-and-drop. This section of the tutorial will guide you through the process of creating Fuses and assigning them to their respective FuseActions. After Fuses have been assigned to their FuseActions, it is time to finish our XFA design by assigning XFAs to different source Fuses. XFAs in Adalon can have multiple source Fuses but only one target FuseAction. Notice that XFAs that have not been assigned to a source Fuse, appear as dashed circles. XFAs that have been connected to a destination FuseAction and have been assigned to at least one source Fuse or FuseAction appear has solid circles with a dot in the middle.

Step 12 - Defining Fuse Input and Output Data Fields

It all comes down to the data. The data flow of what a user sees and interacts with on each Screen drives the detailed design of our individual Fuses. Adalon allows you to easily assign Input and Output Data Fields to each Fuse. You can also assign scopes to the different variables. All of this information ends up in your Fusedocs when you generate code. Adalon can even generate code that initializes variables and checks them for compliance with your corresponding Data Rules. One great feature in Adalon is that you can import database fields. This saves a lot of time if you have an existing data design.

Step 13 - Layout & Global Navigation

At this point, after fully completing all of the above steps, we have a finished Fusebox architecture that will automatically generate a great, fully Fusedoc'd code skeleton from Adalon. The only problem is that we have not added our global navigation yet. Until we do... well, our Acme Corp. won't be too happy with the end result. It was mentioned above that things like global navigation can be modeled independently of core functionality. Looking back at our prototype, we are going to model the navigation as if it were its own application running in a separate frame. Although, as a Fusebox architect we have decided that we will not be running multiple frames. Instead our Fusebox layout file will include a call to a FuseAction that generates the navigation. This means that each request that the browser makes will actually be two requests. One for the main screen, and then another created by our layout that collects the content for our navigation. In designing the navigation FuseAction, we created a new architecture diagram and followed all of the steps above. The only thing left to do is connect the XFAs from the navigation architecture diagram to the FuseActions on our Forum architecture diagram.

Step 14 - Fusebox Code Generation

When part or all of an application design is complete, developers can generate Fusebox code skeletons with just a few mouse clicks.  All code is fully Fusedoc'd and a generated application will actually run in a browser right after generation.