Advanced ActionScript 3: Design Patterns, Second Edition (2015)
Chapter 3. Decision-Making and Planning
The ability to make wise decisions is important when you’re doing something as demanding as building rich Internet applications (APIs). One decision you may have to make involves choosing to do what is best for you or what is best for the team. The choice may seem obvious on paper, especially if you’re a team player—but late nights and frustration with a project may begin to influence your decision about what’s best for you, rather than the team.
Making poor decisions about object-oriented practices may result in even more late nights and greater frustration for both you and your team. You can only make a sound decision when you really understand the problem you’re trying to solve. Only when you’ve analyzed any and all problem domains can you determine a plan of action. As Louis Pasteur said, “Chance favors the prepared mind”; and if you’re prepared, then if and when change is introduced, you’ll be able to address it effectively.
Object-Oriented Analysis (OOA)
Using OOP with RIAs offers a practical way to divide code into smaller and more manageable pieces. The act of OOP, as explained in Chapter 1, means strictly adhering to principles that enable your architecture to be flexible, modular, and maintainable. Your code will be properly encapsulated and separated from the inner workings of other behaviors that may require change. OOP, in short, helps you build quality objects that in turn enable flexibility, modularity, and easier maintenance.
Often, developers jump right in and implement objects at the beginning of a new project. Doing so molds rigidity into the system’s foundation. This “shoot first, ask questions later” mentality is understandable when time is working against you, but it will come back to haunt you. The next time you’re driving over a bridge or leaning over the balcony of a 10-story building, consider the possible result if a civil engineer had jumped right into the construction phase of the project.
In order to properly and successfully use a good structure, you must know all possible behaviors before you can devise a plan. You learn about the behaviors through an iterative process known as object-oriented analysis (OOA).
OOA is a process that aims to reveal all necessary behaviors and objects related to a given problem domain. Only when you’ve completed an analysis can you hope to construct a design. Such a design can then be used as the blueprint from which you model the implementation of a system. This design process has come to be known as object-oriented design (OOD).
Utilizing a micro-site from past experience, I will demonstrate the OOA & OOD process.
Suppose that as an RIA developer, you’ve been tasked to develop a microsite to promote a new line of windbreakers. The client has requested a site to demonstrate the weather conditions for which their product is the optimal apparel. They would like to focus on each product, the details of the product, and the colors it comes in. In addition, the client wants to show each product being used in the specified weather conditions.
At this point, you may or may not be a part of the conception phase; it depends on a clear definition of team roles. In this case, let’s assume that a creative team has already conceptualized what this site will look like, and you’ve just been tasked to build it.
The client request that was delivered to the designers is delivered to the developer team along with the designed compositions shown in Figure 3-1. Although the discussion in this section may vary based on your position and/or job description, as a developer, your role is ultimately to assemble the features required by a client using the presentation shown by a designer. Although the compositions reveal the end result of the project, they don’t deliver everything you need. A picture is worth a thousand words, so it’s easy for a message to be improperly delivered to the viewer. The intended audience may be the developer or the client. The people who see the comps can easily have their own interpretations, which can lead to future confusion. This is why your first decision as a developer must be to properly analyze the system.
Figure 3-1. Wireframe of the comps that I received
Turning Off the Volume
The material on the site has been designed by professionals to do exactly what it’s supposed to do. It may be supposed to grab your attention or guide your eyes to follow a particular path. Much like Odysseus and his men traveling past the islands of the sirens, you mustn’t allow the designer’s techniques to lure you in.
Instead of focusing on what is presented, you need to focus on what is necessary to devise a quality application. To keep yourself from being swayed by the visual messaging of the comps, you can rely on use cases to demonstrate the system’s goals.
Use Case Scenario
A use case is nothing more than sequential actions performed within the confines of a scenario. These steps move toward accomplishing a specific goal. Each scenario has a clear beginning and ending, and there is always only one goal per use case. In short, a use case is a story that explains the system.
Depending on the agency for which you work, getting your hands on the statement of work (SOW) is the optimal way to determine your use case. A SOW is a document that details the project requirements and defines the agency’s work activities. If you don’t have access to a SOW, ask the designer to detail the steps their comp demonstrates, as they understand them, and then walk through the comp with them.
Here’s are possible case scenarios for the example site:
· User Landing
A user comes to the site.
The user views a blurb about the product.
The site navigation is revealed.
· Product Gallery
A user selects a product.
Display product image and detailed specs.
User purchases the product.
· Image Gallery
A user selects a photo image.
Display weather conditions photo.
Present information callout.
User browses images.
Update information callout.
Because I didn’t have a SOW available, I relied on the designer’s understanding. You should build to these specifications and not to the visuals, because the visuals are more likely to change.
Your goal is to get rid of specifics in order to remain loose and general, because design assets may not be completed yet and, therefore, may change. Yet from the moment your kickoff began, so did the countdown toward your deadline. This is another reason to only concern yourself with the features requested by the client: these are the aspects of your system that are most solid and least likely to change.
Requirements from the Features
When you devise a list of features, it is possible to obtain additional requirement details from them. Keep in mind I say “possible” because many things can go hand in hand. For example, if I say “peanut butter and _____,” you may reply, “jelly.” This is because these two things often go together. Although your project features as stated may only include peanut butter, the clients may not realize that jelly is a key requirement for the peanut butter to be possible. Also, consider the creation of a form. While it may appear that this means a client requires a submit button and an email field, one may not consider the necessities of an error box, or the success message.
Therefore, site design takes advantage of the needs and wants of the users, and inferences are made to better support the abilities of the user.
Note: Requirements from features are susceptible to change, so it’s important not to mix them with what you assume to be constants.
If you review the features from the User Landing use-case scenario, you can determine related requirements for the project build. For instance, as Figure 3-2 shows, you can deduce that a preloader and a footer are possible development requirements, even though they aren’t marked as client features.
Figure 3-2. Supplemental requirements of the User Landing use-case scenario
You need the preloader when the site is ready to progress to the landing page. It is a way for users to understand that a process is taking place and they should be patient.
The footer is a general feature that’s part of the navigation. Specifics of what’s in the footer are generally geared toward the client and therefore don’t need to be added now, because they may change.
The Product Gallery use case, shown in Figure 3-3, illustrates that you need to write XML to contain a product and any specs the product requires. This way, you can keep specifics out of your system. And because the XML will be loaded into the application, you can adjust its language without having to republish any code. Because you don’t know how many products you’re showing at a given time, your system doesn’t include this information and only knows to iterate over the number of children in the XML.
Figure 3-3. Supplemental requirements of the Product Gallery use-case scenario
This raises the fact that the XML needs to be loaded. At this moment you’re uncertain whether it will be loaded before or after the landing page. And you know that if a product image needs to be displayed, you must load it as well. Again, when will it be loaded? For now it’s irrelevant, because all you’re doing is fulfilling supplemental requirements.
According to the client, each client has some form of navigation to go along with it. This is marked in Figure 3-3.
Finally, as shown in Figure 3-4, another preloader is required to help load the scenic photos.
Figure 3-4. Supplemental requirements of the Photo Gallery use-case scenario
Flow charts are another tool that can prevent dilemmas. A flow chart maps out the possible sequence of steps the user may take when navigating through a system. It’s beneficial because it helps to point out essential concepts that may not have been designed or considered. For example, if the user is asked to submit a form, what happens if an error occurs? How is the user redirected back into the system? What paths can they take from that point?
Figure 3-5 shows the different scenarios a user may face, based on their decisions. The user may directly or indirectly take the actions on the system.
Figure 3-5. The flow chart of your current user experience
Many software applications create flow charts, but the simplest approach is always to use paper. It’s not necessary to add a legend or note about who generated the flow chart, although doing so can help someone who hasn’t viewed the chart before—everyone has their own style in producing a flow chart, and you want to ensure that the viewer clearly understands the flow. What is required is the flow chart’s version number. This helps viewers to understand the model’s progression, lets you track changes, and indicates the version in which a change took place.
As indicated by the question marks in Figure 3-5, some paths require more clarification. What happens if a user decides to purchase a product? Are they redirected? Do you need to devise a new section? What if a user doesn’t have Flash—does the site have an HTML page? And what if the user clicks within the footer? Do they go to an external page, or do you display new content in the current page? The answers to these questions should be as generic as possible so they don’t interfere with your current process.
The next step in being preemptive toward problems requires both generic and specific information about your current system. You need to ensure that the site will work optimally before you back yourself into a corner with the implementation. Before you get into the next round of analysis, you should make sure you consider the limitations of ActionScript 3. Such limitations include the frame rate or the inability to access local or server-side resources, depending on how you compile your project. You also need to be aware of the number of server requests, the amount of time it takes to parse an XML file, and, always, how much memory your application requires. The Flash player is a browser plug-in, and this is also performance related. If a user doesn’t have the player installed, how will your application perform?
The type of RIA you’re building also helps determine the performance issues you need to consider. For instance, if you’re building a desktop application, you don’t need to be concerned with the browser’s connection to your application’s frame rate. Of course, there may be other performance issues you need to be concerned about.
Your first pass through the analysis doesn’t reveal any cause for poor performance. But having done your due diligence, you know to be careful about a few particulars. As you continue to analyze your system, be aware of how you store and load data. During every iteration of the analysis, new issues may arise that you can’t see at this stage.
You’ve gathered a satisfying amount of information from your initial analysis of the system. To recap what you have thus far, you’ve devised a use-case scenario to explain the features expected by the client, and you’ve determined what requirements accompany those features. From there, you determined whether additional requirements are necessary to ensure a smooth user experience. Finally, using the knowledge you’ve accumulated, you’ve noted any areas of performance concern that should be corrected before they cause issues in your system.
Layering is an iterative process that attempts to increase the amount of specifics to a structure in order to best combat unforeseen change. Of course, because change is a constant, anything may change at any time; but your work hasn’t been fruitless. The immediate goal is to remain ahead of the changes by separating the generic from the specific and remaining flexible. While you gather information, remain aware of potential concerns for the application.
Your initial analysis of the system revealed a great deal of information you can use. But as you saw in the flow chart in Figure 3-5, a few questions need to be answered in order for the application to run smoothly. Eventually, all generics must become specifics, or you’ll end up with an application that does nothing. You can consider each analytical pass to be another layer that tries to fill the gaps revealed by the layers below. Each pass grows more specific and reveals the modifications of behaviors that were once generic. The number of passes you make depends on the size of your application, the aspects of the application, and your desired level of magnification (that is, how closely you want to analyze each object).
Although each iterative pass may seem to analyze the same system, your analysis is applied to a new problem domain each time you add a layer of specifics. The repetition reveals the union (overlap) of objects in the system. This repetition makes you better acquainted with the system’s requirements and objects, which lets you handle change efficiently.
The beauty of layering is that each layer represents additional system behaviors you’ve added. It also magnifies your bird’s-eye view so you can zoom in on the system.
Having completed your first analytical pass, you must repeat the cycle to fill in the missing pieces. Currently you have three open-ended paths, as revealed in the flow chart in Figure 3-5. As long as paths remain open-ended, the system will include generalized behaviors as well as specialized behaviors. You need to concern yourself with the complete flow of the system.
Currently, you don’t know what happens if the user doesn’t have the Flash player plug-in, if the user clicks a footer link, or when a user purchases a product. We’re informed that the site should prompt the user via an HTML document that that they need Flash to view the site. The other two questions can only be answered by the project manager and the designer, and the answers may or may not be simple. Therefore, you’ll leave those questions unanswered until the answers are necessary.
Figure 3-6 reflects these changes, updates the legend to reveal a new symbol, and states the current version of the flow chart.
Figure 3-6. User flow chart reflecting the latest revisions
You’re said to be working at a low level when you look at your system as a whole. This is because to view a system in its entirety, you must back up to a specific distance to be able to see everything. Much as in real life, you often have to increase your distance from multiple objects to see them in the same frame. As you back up or zoom out, you also minimize the details of the items you’re trying to view. The loss of details lets you keep your focus on the system as a whole. When you manage to assess the big picture, you can begin to increase the magnification and look at details. The easiest way to do that is to break the whole into the sum of its parts.
You’ve already seen the features necessary to the client. Now you need to consider the specifics that the designer has added to achieve those features. By viewing the comps and speaking with the designer, you can understand their vision of how the product gallery will be presented.
According to the designer, the steps involved in a user selecting a product in the product gallery are as shown in the following use-case scenario:
· Product Gallery
· Product Selected
2. Display product image and detailed specs.
a. The user views the product image.
b. The user views the description.
c. The user views all available colors.
d. The user views all available sizes.
e. The user views interior navigation.
i. The user can purchase the current product.
ii. The user can navigate between products.
The new details added to the product-selection use-case scenario may also reveal developmental requirements that need to be added, as Figure 3-7 shows.
Figure 3-7. Updated requirements for the Product Gallery use case
You know you’re using XML; and if multiple parts will be pulled in, you can separate them into different nodes of the XML. Given what the designer has in mind for the page that shows the product and its description, you know what type of elements to use. As shown in Figure 3-7, you can add references to specific objects in ActionScript 3. Where the page has text, you know you use a text field. Where the page uses images, you require bitmaps. Because there are two display colors, you need a collection of the graphics object. There is an in-page navigation where the designer lets the user purchase a product and enhances the user experience by supplying Previous and Back buttons. And on the topic of the buttons, this is a good opportunity to find out what occurs if the user clicks Buy It Now.
A quick conversation with the designer and the project manager reveals that you aren’t responsible for the e-commerce section of the site. When a user clicks the Buy It Now button, they go to an external web page. You can reflect this in the flow chart, as shown in Figure 3-8.
Figure 3-8. Making a purchase opens an external page
Again you’ve reviewed and added to your system. Now you need to work on preventing performance problems: repeat the earlier performance analysis to see if you recognize any other potential issues due to your recent changes.
Nothing causes any concerns at the moment; but a problem could occur that’s so small, it can’t be foreseen. For example, an external link could hinder performance later, depending on what that page holds. Suppose you’re using a sound analyzer. If a second page from another domain opens and plays sounds, your analyzer will fail due to a security error. Because the sound analyzer is global to all players, it reads bytes from every player. When bytes are served from a server other than yours, if you can’t find a policy file with the proper permissions, the sound player will be prevented from reading those bytes.
In discussing the designer’s vision for the Image gallery, the designer reveals the approach used to lay out the design. Using this information, you can sprinkle another layer of specifics onto the original Image Gallery use-case scenario:
· Image Gallery
1. An image is chosen displaying an outdoorsman wearing the product.
a. The user views the image.
b. The user views the image Information callout.
i. The user clicks the information to read about the image.
ii. The user can download the current image in one of three resolutions.
Again, you attempt to gather any supplemental requirements from the use case. Figure 3-9 shows the necessary developmental requirements. Much as with the Product Gallery use case, you use XML to hold the information about the image.
Figure 3-9. Developmental requirements for the Image Gallery
With the new information provided by the detailed use-case scenario, you again come across a possible break in the flow of the user experience. If a user decides to download the current image in one of three possible resolutions, you have to account for any issues that may arise. You need to be aware of the File Reference object that ActionScript 3 uses to download a file. File Reference lets you listen in on specific events, but it doesn’t natively display any visual indication to the user about whether their download is complete or unsuccessful; it also doesn’t display a progress bar during the download. You need to add information that the designer didn’t think of. The updates shown in Figure 3-10 reflect the latest revisions.
Figure 3-10. The sequence reflecting the download of an image
The downloaded image may or may not require an error box or a success box that informs the user the status of the image they selected.
Because the footer is part of the site’s navigation, you need to refine what links a user will find there and the way you present them (see Figure 3-11):
1. The user views the footer navigation.
The user clicks Contact Us.
The user clicks Store Locator.
The user clicks Mailing List.
The user clicks Terms & Conditions.
Figure 3-11. The footer has five buttons
Again, we need to see if the footer links add to your system by talking to the designer and project manager to ensure these additional comps aren’t overlooked. We’re informed that we aren’t expected to add functionality to the system to reflect the footer links; they will take the user to eternal pages. Figure 3-12 shows the revised flow chart.
Figure 3-12. Each link in the footer opens an external page
Because the footer doesn’t add complexity, it shouldn’t cause any performance issues.
Wrapping Up the Analysis
When you’ve explored all possible user paths, you can be confident that you’ve analyzed all client features, designer features, and developmental features for the system. Having an overview of the system along with each subsystem’s parts gives you a starting point when determining objects and their associations during the design phase. Again, because change is a constant, you should have a documented list of all possible objects from your complete analysis before you make any further modifications.
In this case, the identified objects are as follows:
· Scenic Image XML
· Image Gallery
· Image XML
· Image Preloader
· Information Callout
· Info photo
· Information XML
· Progress bar
· Image description
· Product image XML
· Product Gallery
· Product XML
· Interior navigation
· Buy It Now
· Image Preloader
· Product image
· Available colors
· Available sizes
· Contact Us
· Store Locator
· Mailing List
· Terms & Conditions
This list contains what you believe to be all objects required for the application; you can only confirm this by making proper object associations. You can identify how the objects work together to fulfill the requirements. Much like a brand-new jigsaw puzzle spread on a table, you must assemble the pieces you currently have in order to identify any missing pieces or revealing pieces you no longer need.
Object Oriented Design (OOD)
Now that you’ve completed the analysis phase, you can begin to think about the objects and their relationships. At this stage, you evaluate each object’s necessity and continue to look for other objects that are required for the intended behaviors between associations. Being able to orchestrate the objects before you attempt to implement them gives you a greater ability to adapt their behaviors.
The following steps are required before you implement objects:
1. Review the current objects, and remove any duplicates or extraneous objects you’ve documented.
2. Document appropriate names and behaviors for the remaining objects. Each object should have only one defined behavior, which means it has only one reason to ever need to change.
3. Based on the behaviors, separate generalized objects from any behaviors that may require change. If behaviors don’t vary, there is no need for an abstract class.
4. Make associations, and create new objects if needed to achieve specific behaviors.
Unfortunately, to develop optimal associations and reuse elements, you must be aware of the many ways to do so. Even with years of experience, your object associations may prevent you from architecting a framework that enables your object-oriented goals. For now, you must stop here, to avoid making improper decisions about your objects until you know more about design patterns. You continue the OOD phase of this case study in Chapter 11.
OOP, meaning working with objects, doesn’t help you discover all the objects required for a system. But OOA does.
As you’ve seen in this chapter’s case study, iterative sweeps and incremental additions to the system help you develop the requirements to complete the system’s user flow. By remaining distant from the specifics, you can view the entire system. And by slowly layering on the specifics, you’re better able to see how they may affect the behavior or performance of the application, as well as recognize potential pitfalls before the build begins. The analysis phase, as repetitive and arduous as it is, is a must to achieve maximum flexibility in a system.
The case study illustrates why change is a constant. First and foremost when developing an application, you must pay strict attention to capturing all of the client’s desired features. The designer may attempt to enhance these features through presentation and/or user experiences, and may inadvertently make client-requested features less prominent or inject a feature that increases your workload. For example, if the designer added thumbnails for Facebook and Twitter icons, your workload could potentially increase by two days or more, depending on the additional screens, behaviors, or technology required.
Proper incremental analysis enables you to anticipate areas of concern during review and design, rather than during implementation.
OOD, on the other hand, uses conceptualized objects from the analysis and devises flexible and loosely coupled associations between them. OOD lets you realize class behaviors, establish elements for reuse, and reduce the dependencies among them.
· Building a perfect system is an iterative process.
· You should do most work on paper because you won’t try to salvage it and it’s faster.
· When you write code, you instinctually try to fix existing code.
· OOA and OOD make up 80% of project development.
· Ideas are often compounded.
· A flow chart’s version becomes a log of the analysis performed on the system.
· Use-case scenarios demonstrate the steps taken toward accomplishing a goal.
· OOA uses iterative passes to reveal all behaviors in the project.
· OOD models the associations of realized requirements.