Best
Practices
 Ever
wonder how a new program gets designed and built?
"There
are two ways of constructing a software design:
One way is to make it so simple that there are obviously no
deficiencies,
and the other way is to make it so complicated that there
are no obvious deficiencies.
The first method is far more difficult."
- C.A.R.
Hoare
InSite
Media uses methodology based on the FuseBox
Lifecycle Process (FLiP) and produces applications that
are compliant with the FuseBox
Open Source coding standard.
What Is Fusebox?
Fusebox is a framework consisting of
a set of helper files and organizational principles, and a
methodology consisting of a set of best practices for managing
web projects. Used by application designers, developers and
architects, the system addresses development problems such
as unmanageable complexity, wasteful redundancy of effort,
time-consuming code maintenance, and slow development speed.
Why have a coding standard? To put it
simply, it's to keep things organized. It is understood that,
on average, 70% of the total investment in application software
will go to maintenance over its lifetime. Applications get
larger. The interconnections between things get tangled. This
isn't anyone's fault. It's because every button, every field,
every screen, every thing, is connected to many others. This
is why most programmers would prefer to develop something
from scratch than modify someone else's software.
Figure 1: Application programming, the old way, now
called "Point-to-Point." Forms, screens, database
objects, etc., become intertwined in a complex "web"
of functionality that is often NOT documented anywhere.
This will be costly to maintain over time.
FuseBox, in contrast, provides an organized
structure with meaning that it is clear to the trained eye
at first sight. Best Practices ensure consistent naming conventions
and constructs are used. Each module, or "circuit"
in FuseBox terminology, is plugged into the central "fusebox"
which acts like a big switchboard.
For developers, the FuseBox is both a
convenient receptacle for new modules, and a high-level, self-explanitory
map of the application workings.
Figure 2: The "FuseBox"
provides a Plug-and-Play system that glues the modules together.
Perhaps the best part is that fusebox-compatible
applications can be installed inside other fusebox applications.
This leads to quantum leaps in productivity as a vibrant
developer community creates FuseBox-compatible modules. InSite
Media's library of FuseBox modules grows daily, which means
we can offer more functionality in less time and at less cost
than developers of equal skill using traditional "improvise-test-fix"
methods. Over time these differences are very significant.
Note that FuseBox is a language-independent
architecture. FuseBox arose from the Cold Fusion developer
community, but it has been ported to ASP, J2EE, PHP and environments
and is now used by an estimated 19,000 developers (Source:
FuseBox.org.)
How does FuseBox Work?
With Fusebox, a clear separation is made
between the framework and the methodology. The methodology
associated with Fusebox is called the Fusebox Lifecycle Process,
or FLiP.
The Fusebox Framework
The first part of Fusebox is the "framework". The
Fusebox framework consists of a series of files that aid in
the creation of a complex web application. These files, known
as the "core files" allow you to easily achieve
nested layouts, inherited variables and settings, and break
your application into more manageable pieces.
Additionally, a set of best practices for organizing applications
falls under the framework.
The goal of the Fusebox framework is to create a standard
process for architecting web applications. This goal extends
beyond a single technology. The core files have been duplicated
for multiple web application languages.
More about the FuseBox
framework.
Fusebox Lifecycle Process
"There
are two fundamental ideas behind FLiP. The first is to use
a process that is, at all times, closely tied to client
feedback. The second is to encourage inexpensive changes
in the design early in the process, resulting in a reduced
need for changes later in the process, when those changes
become progressively more expensive.
It
is also important to note that FLiP is designed for the
technical aspects of the project, starting at a point when
you are ready to begin building an application. For many
simple web projects, FLiP may be sufficient from the start
of the project. For more complex projects, other research
techniques may be necessary to understand the business model
before starting on the application development with FLiP."
*
The precise steps are modified slightly
depending on the scale of the project. Database-driven,
transaction processing applications of the kind associated
with e-Business will use the complete FLiP methodology. Smaller
applications and simple web sites are reliably and affordably
produced using a four-step process with some steps taking
place concurrently.
General
Design
Encompassing
steps 1 and 2 of FLiP, General Design captures and defines
general system requirements. Issues such as audience, scope,
expected visitor-system interactions (use case) are identified
and tabulated. A wireframe helps present how the application
is expected to work.
- Requirements
List
A requirements document outlines
the project goals and key features at a very high level,
and helps ensure that the ultimate design meets user expectations,
without prejudice as to 'how' the requirement will be
met.
- Wireframe
Overview
A wireframe is a set of pages that illustrate the basic
design of the program by describing what will happen on
each page. The wireframe is not intended to resemble the
finished application.
- Look
and Feel
Look and feel is a crucial aspect of most, if not all web
projects. At this stage, an artist will render visual designs
to choose from.
Detailed Design:
Encompassing steps 3 and 4 of FLiP, Detailed
Design defines detailed internal and visible function of the
proposed system. Issues such as security and performance considerations,
data organization and storage are carefully explored and the
design documented. Another prototype, a user-interface with
no "back end," may be presented to confirm the detailed
design with end users before construction begins.
- Detailed
Requirements Document
Confirms that the design addresses the requirements. All
requirements should have associated design elements
- Data
Structure Diagram
Logical organization of data, including rules for data integrity
(i.e. "An "order" always has exactly one
"customer," and not the other way around.").
- Advanced
Architecture Explorer *
Navigatable map of the application design including conditions,
required processing and system architecture. Developers
will write the code for each "fuse" the Architect
calls for.
Construction:
Having designed the system in great detail,
and possibly already being in possession of prototypes of
user interface components, construction proceeds in at an
impressive pace.
FLiP also provides an elegant testing
solution. In the Architecture step, fuse-by-fuse functions
are defined and documented (a fuse is the smallest unit of
processing FuseBox). These definitions form the basis of developer
assignments. Developers submit their fuses which are then
tested to ensure that they react to "stimuli" in
the expected way. This is like a testing an engine on the
bench before installing it in a vehicle. The testing "harness"
is the bench. It's a life-support system for the fuse, so
that it can run normally and think it's inside the finished
application and possibly communicating with a real database,
neither of which is the case.
Assignments can be distributed to developers
who are not necessarily familiar with every aspect of the
whole system. Thus, the fusebox architecture and FLiP methodology
is ideal for developers working on large applications in distributed
teams.
Another advantage of the approach and
tools InSite Media uses to embrace the FuseBox architecture
and FLiP methodology is that there are no throw-away components.
Materials and code throughout the process are incorporated
into the finished product. Competing methodologies often have
little use for the diagrams and components that were produced
in the early stages, which creates great redundancy in developer
activity, whereas we re-use most components in the finished
product. This "do it once and do it right" approach
is efficient and produces documented, stable and scalable
systems that can be easily maintained by any developer familiar
with FuseBox architecture, no matter how big the application
gets.
Figure 3: Logical organization of a FuseBox application
with four large modules (Circuits).
Final assembly is handled by the same
person who created the design, the Architect. Daily updates
result in a rapidly evolving prototype as developers submit
their sections for inclusion in the final assembly.
In summary, Fusebox architecture provides
a structural style that is highly productive for programmers,
and therefore cost-effective for clients. The FuseBox LifeCycle
Process (FLiP) provides a step-by-step approach for tackling
complex software projects and ensuring that your next project
is a success in every way.
* Source:
http://fusebox.org/index.cfm
Copyright (c) 2003 InSite Media, all rights reserved.
|
