Showcase and discover digital art at yex

Follow Design Stacks

Subscribe to our free newsletter to get all our latest tutorials and articles delivered directly to your inbox!

Being organized and prepared

Being organized and prepared

While this article focuses on the implementation of a specific online retail application, several critical planning steps precede the writing of code for any purpose. You first need to understand the tasks that the application must perform, the technologies it will use, and its relationship to other computer systems. Among the most important best practices prior to coding is the creation of a set of artifacts, described next, that outline our goals and articulate how we will meet them.

Create a functional specification

The functional specification exhaustively describes what the application will do in plain, non-technical language:

  • Actors are the target users of the system. Since it is important to understand your target audience fully (age, demographic profile, goals, tastes), you should create realistic, but fictional, characters to represent each target actor, complete with a name and picture. Throughout the development process, continually review these character profiles to ensure you are building an application that your actors would want to use.
  • Use cases describe how an actor will interact with the system to perform a specific task. Examples of use cases in RbkCustom are “A consumer puts a shoe in their shopping cart” or “A consumer shares a recipe with a friend via e-mail.” Use cases explore these activities in detail, including information about prerequisites, side effects, results, and relationships to other use cases.
  • Schematics show the screens involved in the application and their relationships to each other. Schematics are a comprehensive set of wireframe sketches that focus on the layout and content of the screens. The visual treatment presented in the schematics complements the textual description in the functional specification.
  • Visual design is the “skin” of the application. The colors, fonts, and imagery used to build the application are developed to be consistent with its functionality and its target audience. We create visual designs for a small representative sample of the screens in the application. After iteratively revising this sample set, we create visual designs for the rest of the application.

Create a technical specification

The technical specification describes the technical architecture of the entire application in detail, including information about client code, server code, hardware platform, and external system integration. The client portion of this document covers the following topics:

  • Subsystems in the Flash application and the ways they interact internally
  • Sample classes used in the implementation of the application
  • Diagrams showing how the system will perform important representative tasks
  • Mechanisms by which Flash will communicate with the server
  • External system integration that occurs directly from Flash
  • Minimum quantified speed standards
  • Foundational software and libraries, such as the Flash v2 set of visual components or AsUnit, the open-source ActionScript unit testing framework.

Use object-oriented analysis and design

We use industry-standard Object-Oriented Analysis and Design (OOA&D) methodologies to articulate the details of the applications we build. These artifacts are a critical element of the technical specification document described in the prior subsection.

The goal of OOA&D is to understand how the system will accomplish what it needs to do. This documentation helps developers understand their individual tasks and helps coordinate the efforts of multiple cooperating developers.

Unified Modeling Language

Unified Modeling Language (UML) is a popular syntax for documenting the classes that make up a software system and the interactions between those classes. UML defines many different types of diagrams. We typically use three of them: class diagrams, sequence diagrams, and collaboration diagrams.

  • Class diagrams represent the structural relationships between the classes that make up the system. For RbkCustom, we created many class diagrams, including one to show how we associate configurable options with a shoe.
  • Sequence diagrams show the messages sent between specific objects to fulfill a task. We used a sequence diagram to show how a user would put a configured shoe in their shopping cart in RbkCustom.
  • Collaboration diagrams show how groups of objects represent specific situations in the application. We created collaboration diagrams in RbkCustom to show examples of pieces of configured shoes, such as an extra pair of laces that are wide and red.

Design patterns

Design patterns help developers learn from the experiences of other developers. They capture recurrent challenges faced by developers and suggest solutions to them, thereby offering elegant and proven solutions to many of the tasks they face. Design patterns constitute a common vocabulary among developers. Their use saves time in the initial development of a system and also facilitates ongoing maintenance.

You must understand design patterns in order to use them effectively. Some design patterns are particularly well suited for use in Flash applications. Some, in fact, are virtually impossible to avoid. For example, the prevalent event notification paradigm in Flash is an articulation of the Observer design pattern. We used the Singleton, Abstract Factory, Bridge, and Template Method patterns (among others) in the RbkCustom application.