Design Methodology for Web Development
By: Naveed
Ahmad (Software Engineer LSI)
Motivation
The purpose of this document is to divide the components of a web-based application requirements gathering, design and finally development. And to further identify the dependencies, relationships among these components. The understanding of this is not only helpful for a system analyst/designer, but for a project manager who wants to distribute the application development process among different team groups / members.
The High Level Break
Web development consists of 4 major components i.e.
· Web Interface (HTML, Applets, JavaScript, Flash etc.)
· Front End Request Handling (CGI, ASP, JSP, Servlets etc.) (Can also mingle into the middle tier)
· Middle Tier (Usually the business logic implementation COM, CORBA)
· Database (Oracle, SQL Server)
View (Origin)
The process of gathering R&S is an iterative process, which requires continuous discussions with the client, understanding of his needs and giving him a prototype and further provoking his input and suggestions. Personal experience says that, it is better for the client to specify (or the team to purpose) the screen shots as part of the R&S and discussing and the flow of the application rather than adopting the prototyping model. While the application is developed, it should be made flexible enough to make the minor changes before the final deployment. This process serves the following purposes.
· Saves the designer of re designing / re implementation
· Creates an understanding between the client and development team (e.g. the client will not complain before deployment that a particular feature is missing)
· Gives you a an idea of the database design
· Leads you automatically into the next phase i.e. The Test Drive (informal term used for scenarios from the Responsibility Driven Design methodology)
Test Drive (The rigor of designing)
The meaning of a Test Drive is to pick a point from an application and drive through it till you reach another point. The purpose of a test drive is to review all the scenarios and identify all the fields (e.g. text fields), any new screen, any exceptions and flow, along the ride. For the sake of understanding, lets take a test drive through the login procedure of a web based emailing application (e.g. hotmail).
1. The first screen you think of is the login screen. Obviously by tradition or common sense, we think up of two fields i.e. the user ID and password field.
2. User types login and password (Use Case)
3. The user presses the ‘login’ button.
4. The fields’ values and the request have to be sent to a http handling process like a Java servlet.
5. The password for the user ID has to be retrieved from the database.
6. The password from the database and the password submitted are compared.
7. If the passwords are not equal the application directs the user for another drive i.e. ‘The Forgot Your Password’ drive.
8. If the password and user Id are equal we set a cookie on the clients machine that he is an authenticated user so we can maintain a session.
9. Then we present the user with the screen showing the list of emails he has in his inbox.
10. From here we can pick and review one of the many further test drives (i.e. creating a new mail, deleting a mail, logout etc).
But wait! Lets review. We missed something important on step 4. What if that user ID does not exist at all in the database, or is temporarily suspended etc.? We would then have to direct the user to ‘Create a New Account’ or ‘Account Renewal’ series of pages.
The above was an example of the imaginary iterations we go through the applications. We not only realized the data fields, but various new starting points for new test drives (which we might have overlooked till implementation) and an exception at step 4.
Result is that going through a number of these test drives we are able to:
1. Create a tree structure for the flow of the application each arc represent ting a test drive.
2. Identify data base fields to be in our database. (user ID Password)
3. Identify the programming logic for the business model.
4. Identifying the possible exceptions e.g. user ID did not exist.
5. Finding further nodes/points for new test drives (scenarios) e.g. ‘New Account’.
Data Base Schema
After identifying all the fields and their types (i.e. Strings numerical etc) that need to be stored we create the database schema. We group the fields into tables. Table design is done for both storage and retrieval efficiency and into logical grouping. The database is a derivative of the screen fields and some part of the programming logic (some internal fields not shown to the user).
The Business Model
The business model is the meat between the user interface and the backend. It encloses most of the programming logic pertaining to an application. For example Pcsdrades consisted of COM objects containing all the application specific algorithms. These objects gathered their information form the client side via web interface, ASP and MSMQ (the buffering medium) and the real time stock values from the backend via MSMQ and a few custom wrapper/interfacing COM objects. After the thinking process by the middle tier further action was taken (pager notifications etc). But the business tier can also be intermingled with the front end. For example the Online Testing Software Java Beans (for test question selection and flow control) are embedded right into the JSP code (which happens to be a http request handling script).
Dependencies
We saw that user interface is the originator of the whole application design. As it is said that 50% of the answer lies in the question, so is the importance of a user interface i.e. 50% of the application design lies on the user interface. Here is a diagram for the dependencies along with the time direction for the design process.
Division of Labor Models
Design is usually a joint effort by a small group. After the completion of the design, comes the task of distributing the work. Web design is a bit different from the conventional application with an object oriented design. In an object oriented application different teams can be assigned modules/classes/ with defined interfaces. But web development is a non uniform terrain, requiring a variety of skills. As mentioned before there are 4 components to web development.
· Web Interface (HTML, Applets, JavaScript, Flash etc.)
· Front End Request Handling (CGI, ASP, JSP, Servlets etc.) (Can also mingle into the middle tier)
· Middle Tier (Usually the business logic implementation COM, CORBA)
· Database (Oracle, SQL Server)
Eating the Elephant
There can be two approaches to eat the elephant. One is the vertical approach and the other is the horizontal approach.
Horizontal Approach
In the horizontal approach each team is assigned one of the components out of the four. For example one team may be working on the development of the forms, one for the query design, one for business logic development and one for handling the database. Each team develops a protocol and set of conventions for communication.
Vertical Approach
Each team picks a module of the application and develops it from the front to end i.e. the 4 components of the development. This obviously requires that each team is skillful in all the 4 technologies.
Comparison of The Approaches
Horizontal approach is a good methodology for a big project or when there are specialized teams or individuals for each of the components. If there is only one project the teams may be ill utilized since one team may have to wait for another to complete. But if the work load for each of the components requires dedicated expertise and there are many projects going on at once, then this approach would be appropriate. For example when a web interface team is waiting for the database team to finish they may proceed work with another project whose database is ready.
Vertical approach is good where an application can be broken down into autonomous sub applications or modules e.g. testing interfaces, admin interface, and user information interface. But it requires the team/developer to know all the four components of development. This approach is good for medium level applications. But if the application requires special dedicated work then the horizontal approach is better. The vertical approach is best for resource utilization since no team has to wait for the other to finish. They are autonomous at work.