In this final year’s eCommerce project eShopping process model, we are showing you the Process Model, Functional Decomposition Diagram, Data flow Diagram, User Interface diagram, and three-tier architecture. Chapter Two Part-2 continued…
3.2. Process Model
A Process Model tells us about how the data is processed and how the data flows from one table to another to gather the required information. This model consists of the Functional Decomposition Diagram and Data Flow Diagram.
3.2.1. Functional Decomposition Diagram
A decomposition diagram shows a top-down functional decomposition of a system and exposes the system’s structure. The objective of the Functional Decomposition is to break down a system step by step, beginning with the main function of a system and continuing with the interim levels down to the level of elementary functions. The diagram is the starting point for more detailed process diagrams, such as data flow diagrams (DFD). Figure 2 shows the Functional Decomposition Diagram for this project.
Figure 2 Functional Decomposition Diagram
3.2.2 Data Flow Diagram (DFD)
Data Flow Diagrams show the flow of data from external entities into the system, and from one process to another within the system. There are four symbols for drawing a
- Rectangles representing external entities, which are sources or destinations of data.
- Ellipses representing processes, which take data as input, validate and process it and output it.
- Arrows representing the data flow, which can either, be electronic data or physical items.
- Open-ended rectangles or a Disk symbol representing data stores, including electronic stores such as databases or XML files and physical stores such as filing cabinets or stacks of paper.
The Detailed DFD provides a more detailed and comprehensive view of the interaction among the sub-processes within the system.
Customer-Browse Context DFD:
Figure 3: Customer-Browse Context DFD
Customer – ShoppingCart Context DFD:
Figure 4: Customer – ShoppingCart Context DFD
Customer – ShoppingCart Detailed DFD:
Figure 5: Customer Shopping Cart Detailed DFD
Customer-Authentication Context DFD:
Figure 6: Customer-Authentication Context DFD
3.3 User Interface Design
Before implementing the actual design of the project, a few user interface designs were constructed to visualize the user interaction with the system as they browse for books, create a shopping cart and purchase books. The user interface design will closely follow our Functional Decomposition Diagram. Figures 7 â€“ 20 show the initial designs of the web pages.
Figure 7: Front Page of RupJayGri Shop with menu
The Magic of the Three-Tier Architecture
Generally, the architecture refers to the way we split the code that implements a feature of the application into separate components based on what they do and grouping each kind of component into a single logical tier.
In particular, the three-tier architecture refers to an architecture that is based on these tiers:
-The presentation tier
-The business tier
-The data tier
Figure: Example of information exchange among application tiers
The presentation tier contains the user interface elements of the site and includes all the logic that manages the interaction between the visitor and the client’s business. This tier makes the whole site feel alive, and the way you design it has crucial importance for the site’s success. Because your application is a web site, its presentation tier is composed of dynamic web pages.
The business tier (also called the middle tier) receives requests from the presentation tier and returns a result to the presentation tier depending on the business logic it contains. Almost any event that happens in the presentation tier usually results in the business tier being called (utilized), except events that can be handled locally by the presentation tier, such as simple input data validation, and so on. For example, if the visitor is doing a product search, the presentation tier calls the business tier and says, Please send me back the products that match this search criterion. Most of the time, the business tier needs to call the data tier for information to be able to respond to the presentation tier’s request.
The data tier (sometimes referred to as the database tier) is responsible for managing the application’s data and sending it to the business tier when requested. For the RupJayGri e-commerce site, you’ll need to store data about products (including their categories and their departments), users, shopping carts, and so on. Almost every client request finally results in the data tier being interrogated for information (except when previously retrieved data has been cached at the business tier or presentation tier levels), so it’s important to have a fast database system.
Choosing Technologies and Tools
No matter which architecture is chosen, a major question that arises in every development project is which technologies, programming languages, and tools are going to be used, bearing in mind that external requirements can seriously limit your options. We’re creating a web site using PHP 5, MySQL 5, and related technologies.
We really like these technologies, but it doesn’t necessarily mean they’re the best choice for any kind of project, in any circumstances. Additionally, there are many situations in which you must use specific technologies because of client requirements. The Requirements Analysis stage that is present in the most software development process will determine which technologies you must use for creating the application.
Although the book assumes some previous experience with PHP and MySQL, we’ll take a quick look at them and see how they fit into our project and into the three-tier architecture.
Using PHP to Generate Dynamic Web Content
PHP is an open-source technology for building dynamic, interactive web content. Its short description (on the official PHP web site, http://www.php.net) is PHP is a widely-used general-purpose scripting language that is especially suited for web development and can be embedded into HTML.
PHP stands for PHP: Hypertext Preprocessor (yes, it’s a recursive acronym) and is available for free download at its official web site. The story of PHP, having its roots somewhere in 1994, is a successful one. Among the factors that led to its success are the following:
- PHP is free; especially when combined with Linux server software, PHP can prove to be a very cost-efficient technology to build dynamic web content.
- PHP has a shorter learning curve than other scripting languages.
- The PHP community is agile. Many useful helper libraries or new versions of the existing libraries are being developed (such as those you can find in the PEAR repository or at http://www.phpclasses.org), and new features are added frequently.
- PHP works very well on a variety of web servers and operating systems (Unix-like platforms, Windows, and Mac OS).
Apache Web Server:
Apache offers various advantages to users, developers and Web administrators:
- Features. Apache has various useful features, including the implementation of the latest protocols.
- Customizable. Apache’s modular architecture allows you to build a server that is “made to measure.”
- Administration. Apache configuration files are in ASCII, have a simple format, and can be edited using any text editor. They are transferable, so one can effectively clone a server. One can control the server from the command line, which makes remote administration very convenient.
- Extensible. Apache server and API source code are open to the public. If there is any feature that you want but does not exist in Apache, you can write your own server module to implement it.
- Efficient. A lot of effort has been put into optimizing the Apache’s C code for performance. As a result, it runs faster and consumes fewer systems resources than many other servers.
- Portability. Apache runs on a wide variety of operating systems, including all variants of UNIX, Windows 9x/NT, MacOS (on PowerPC), and various others.
- Stability/Reliability. Apache’s source code is open to the public. When any bugs are found, they are often quickly communicated, and rapidly fixed. Updates are made and announced thereafter. This has resulted in Apache becoming more and more stable, and hence reliable, server over time.
- Support. Apache is supported by the Apache Group, a large number of dedicated users (many of whom can often be found in the Usenet newsgroup
comp.infosystems.www.servers.ms-windows), and by companies who market commercial versions of Apache.
In this project, MySQL is used as the back-end database. MySQL is an opensource database management system. The features of MySQL are given below:
-MySQL is a relational database management system. A relational database stores information in different tables, rather than in one giant table. These tables can be referenced to each other, to access and maintain data easily.
– MySQL is an open-source database system. The database software can be used and modify by anyone according to their needs.
-It is fast, reliable and easy to use. To improve performance, MySQL is a multi-threaded database engine. A multi-threaded application performs many tasks at the same time as if multiple instances of that application were running simultaneously.
Being multi-threaded MySQL has many advantages. A separate thread handles each incoming connection with an extra thread that is always running to manage the connections. Multiple clients can perform read operations simultaneously, but while writing, only hold up another client that needs access to the data being updated. Even though the threads share the same process space, they execute individually and because of this separation, multiprocessor machines can spread the thread across many CPUs as long as the host operating system supports multiple CPUs. Multi-threading is the key feature to support MySQL performance design goals. It is the core feature around which MySQL is built.
MySQL database is connected to ASP.NET using an ODBC driver. Open Database Connectivity (ODBC) is a widely accepted application programming interface (API) for database access. The ODBC driver is a library that implements the functions supported by ODBC API. It processes ODBC function calls, submits SQL requests to MySQL server, and returns results back to the application. If necessary, the driver modifies an application’s request so that the request conforms to syntax supported by MySQL.
For writing codes and making design, we use Macromedia DreamWeaver
For making the screenshot
For communicating between our team and showing our development.
Choosing Naming and Coding Standards
Although coding and naming standards might not seem that important at first, they definitely shouldn’t be overlooked. Not following a set of rules for your code will almost always result in code that’s hard to read, understand, and maintain. On the other hand, when you follow a consistent way of coding, you can almost say your code is already half documented, which is an important contribution toward the project’s maintainability, especially when multiple people are working on the same project at the same time.
Naming conventions refer to many elements within a project, simply because almost all of a project’s elements have names: the project itself, files, classes, variables, methods, and method parameters, database tables, database columns, and so on. Without some discipline when naming all those elements, after a week of coding, you won’t understand a single line of what you’ve written.
When developing RupJayGri Shop, we followed a set of naming conventions that are popular among PHP developers. Some of the most important rules are summarized here and in the piece of code that follows:
- Class names and method names should be written using Pascal casing (uppercase letters for the first letter in every word), such as WarZone.
- Public class attribute names follow the same rules as class names but should be prepended with the character. So, valid public attribute names look like this: $mSomeSoldier.
- Private class attribute names follow the same rules as public class attribute names, except they’re also prepended with an underscore, such as in $_mSomeOtherSoldier.
- Method argument names should use camel casing (uppercase letters for the first letter in every word except the first one), such as $someEnemy, $someOtherEnemy.
- Variable names should be written in lowercase, with an underscore as the word separator, such as $master_of_war.
- Database objects use the same conventions as variable names (the department_id column).
- Try to indent your code using a fixed number of spaces (say, four) for each level. (The code in this book uses two spaces because of physical space limitations)