Design

The Tatam System Consultants team has discovered that a group discussion at the initial stage in the design phase gives the development team ownership in the design. This can alleviate any problems that may arise due to having a strict design thrust upon them. It also identifies the group's strengths and weaknesses, which can influence the design toward a system that draws upon the team's strengths. However, discovery of new technologies is also encouraged in this initial phase to determine if there is some alternative technology or technique that could assist it.

Both a component diagram and database schema are provided. These diagrams are an initial design and may be adjusted within the construction process if the change can be justified.

Some of these diagrams are shown here.

instant message

A component diagram shows the components and the relationships between these com ponents. A component can store data in its attributes (or properties) and has functions (or methods) that act upon this data or perform functionality directly related to the component.

Database schema

A database schema in this instance is a screen dump of the Microsoft Access database "Relationship" diagram. It shows the tables/field names and the relationships between these database components (Figure IV-2.1).

Figure IV-2.1. Database schema diagrams are used to visualize databases and their relationships.

Log-in

Tatam System Consultants uses sequence diagrams to define the crucial communication that must exist within a process. Through experience Tatam System Consultants has learned not to create a detailed specific sequence diagram, as it can constrain the developer. The use of primitive sequence diagrams ensures that developers can take ownership of the process, and in doing so promotes the developers' creativity.

As seen in the log-in flowchart (Figure IV-2.2), a user is prompted for a name and password. This information is authenticated, and if successful a user session is created (effectively logging the user in to the system).

Figure IV-2.2. Requirements reference: Functional requirement No. 2.

Figure IV-2.3. Flowcharts provide a mechanism with which to visualize program flow and decision making.

Once the technology has been chosen and the documentation finalized, the developers can start cutting the code.

Coding Standards

The team realizes they have to adhere to the TSC coding practices, but with the arrival of new MX suite there needs to be a revision of this practice. The variable- and component-naming standards currently assist in code readability as well as helping with the testing, debugging, and maintenance process. With that in mind, they moved forward with the following standards.

Documentation

It is the developer's responsibility to document his or her code. Self-documenting code is our objective. Code documentation will be applied to all code that needs explanation. Any branch in programming or business logic must be documented.

The following are proposed coding standards. Please feel free to discuss within the development team and any modifications will be addressed. This is an initial draft as our experience in this new technology is very limited.

A single-line comment in ActionScript is as follows:

 //thisisacomment 

There can also be a block comment:

 /* thiscommentisonadifferentline */ 

Server-side as well as client-side code needs to be documented.

The following are examples of ColdFusion MX code documentation:

 <!---********************************************* Filename:User.cfc ComponentPackage:au.com.tatam.User Description:  Definesallset/getmethodsforUserfieldvalues Assumptions:  Musthaveaccesstoau.com.tatam.Database.queryCFC AuthorDetails  Author:MattTatam  Emailaddress:[e-mail] Creationdate:16March2002 Changelog  Version:1.1   Date:28March   Author:MattTatam   Description:AddedCommentsandcleanedupdebugoutputetc **********************************************---> 

Here is a function within a CFC:

 <!---*********************************************  Functionname:createUserTable  Component:au.com.tatam.User.User  FunctionAccess:Remote  FunctionDescription:   CreatestheUserTable  FunctionParametersorattributes   ARGUMENTS    [REQUIRED]odatasourcename-for<CFQUERY>tag    [REQUIRED]odatasourceType-for<CFQUERY>tag  FunctionReturncodes   VariableName:rtn_success   VariableValue:    ReturnsTrueifTableiscreated    ORifERRORthenreturns"false"value  FunctionAssumptions:  AuthorDetails   Author:MattTatam   Emailaddress:[e-mail]  FunctionCreationdate:16March2002  FunctionChangelog:   Version:1.1    Date:28March    Author:MattTatam    Description:AddedCommentsandcleanedupdebugoutputetc ***********************************************---> 

A Hint attribute of the <cfcomponent> tag can be used in documentation as well as for developer information. To assist in code documenting, we should also use the Hint attribute in the <cfcomponent> tag, which is displayed in the Component cfcexplorer.

Placing all code in one frame allows any object to call the code, as well as serving to centralize the code. This centralization gives the developer the capacity to organize and manage code in one convenient area. The initialization function call should be the only function called:

 //firstframename=ActionScriptthis.init();  functioninit() { //tosetthestartingstateofthesystem } functionanother(){} //etcetc 

Any other function calls should be made only when an event is triggered.

Events

Previous versions of Flash gave the ActionScript developer access to events that handled server interaction, as well as mouse-click and keyboard activity (through the on event and onClipEvent). These events have been expanded in Flash MX to include text-field events, selection events, and other complex data events. This new event model has given rise to more interactive components that can be created and reused. It also enables the creation of all event code in the one frame.

Variables and Scope

We should adhere to the generally accepted ActionScript coding standard of naming data types and objects, as follows:

Variables start with a lowercase letter and are descriptive of their use:

 userID=LocalUser.getUserID();  

Constants are capitalized and should be placed together within the code:

 _global.GATEWAYURL="http://127.0.0.1/"; 

Objects should be descriptive of their purpose. They are in upper- and lowercase, and each word within them begins with a capital letter. For example:

 LocalUser=function(){}  ChatServer=newChatServerClass(); 

Functions should be descriptive of their role. They are in upper- and lowercase and start with a lowercase letter:

 userID=LocalUser.getUserID();  

Since Flash MX has a built-in code-completion feature, our variable naming for Flash components has changed slightly. To make it easier to take advantage of the completion support, the format consists of an underscore ( _ ) and then a suffix of the object type. For example,

Dialog_txt is a text field.

IndivCat_mc is a movie clip.

Other suffixes are _array,_str,_date,_xml,_sound,_color.

Variable scope is also a consideration when producing code. Variables can have different scopes depending on where and how they were instantiated.

The keyword var is used to declare all local variables. This declaration assures that the variable exists only within the block of code in which it is defined and cannot be overwritten by an external assignment. Like function parameters, local variables do not need to be scoped. When scoping variables, be aware of code portability. The scope _root is unique for each loaded movie, so a _root suffix may work in one system, but if it is reused within another, then it may not. A global variable, however, is accessible throughout the entire period of any movie that is loaded. To identify a global variable, the _global prefix is used. Scoping variables are beneficial to code reuse and gives the code a consistent look and readability. The scope succession is as follows: global, current movie, and then local variables.

This is an initial memo that will be entered into our document management system. As our MX experience grows we will be able to refine this document further.

The next chapter will discuss the development challenges the team encountered during the construction of the chat application.