This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Design is a creative process of working out how to implement what the system is supposed to do. Design covers two aspects Architectural design which describes the main components and their interactions and Detailed design which is a component-based description including the structure and behavior of the components.
4.1 Architectural Design
4.1.1 MVC Architecture
Nowadays, there is a wide range of different design-patterns which software developers can choose from, that guides them on how to structure their web-applications. One of the most widely used design-pattern used in the web development industry is the Model-View-Controller (MVC) firstly introduced in 1979 by Trygve Reenskaug while he was working on Smalltalk at Xerox Palo Alto Research Laboratory (PARC) [1-2]. The goal of MVC, as described by Trygve Reenskaug and James O. Coplien (2009), is to "provide the illusion of a direct connection from the end user brain to the computer 'brain' (memory and processor)"  by splitting the whole system (application) into three types of objects, each specialized for a specific task. As the name implies MVC considers the following components:
Model (Business Logic): It is responsible for managing the behaviour and data of the application domain. Usually it is used to get or modify/update the data.
View (User Interface): It is responsible for displaying the model on the screen. A developer can have different views for the same data for example one view showing data as a line chart and another representing data as a pie chart.
Controller (Functional Logic): It is responsible for listening to events triggered by view, manipulating the model and causing the view to update based on these events. In general it controls the user interaction and coordinates views and models.
Figure 4.1 - MVC process[http://en.wikipedia.org/wiki/File:MVC-Process.png]
These components, as can be seen in figure 4.1, interact with each other to create the desired output and allow interaction with the user. Anyone using this design architecture should know that a model may have multiple views while a view has only one model and all views have to be updated when model changes.
Many PHP frameworks that are used in the industry today are based on the MVC architecture and whilst each one uses a slightly different version of it, all try to achieve a) separation between the view and the model and b) separation between the controller and the view, both leading to some substantial advantages over other design patterns. MVC promotes code reusability, maintainability (cleaner code, easier to modify) and testability (enables thorough testing to the code) [4-5].
4.1.2 CodeIgniter MVC
CodeIgniter, the chosen PHP framework for this project, is based on the MVC development pattern allowing great separation between application logic and presentation layer. In CodeIgniter the MVC pattern is defined as:
The Model represents your data structures. Usually a model class will contain functions enabling the application to create, insert, update, delete and retrieve information in/from the database. As a general rule models never contain HTML code.
TheÂ ViewÂ is what the user will be seen on the screen. Typically a view is a web page but a lot of developers have views to represent different parts of a page like a header, footer or a navigation menu. Views never access the database and they never use anything more complicated than loops and conditional statements.
TheÂ ControllerÂ acts like a "bridge" between the view, the model and any other resources needed to process the HTTP request and generate a web page. In general controllers call models to store and retrieve data, provide all data needed by the view and handle all error messages. They never contain HTML code. [http://ellislab.com/codeigniter/user-guide/overview/mvc.html]
A difference from the typical MVC approach, discussed in 4.1.1 MVC Architecture, is that in CodeIgniter models are not required and the whole application can be built minimally using only Controllers and Views. The MVC approach can also be found on how the URLs are represented in the framework. A typical URL will look like this:
The first part of the URL represents the controllerÂ class; the second part represents the classÂ function, or method, that should be called and the third, and any additional parts, represent any variables that will be passed to the controller's function.
CodeIgniter application flow
Figure 4.2 - How data flows throughout a CodeIgniter Application [http://ellislab.com/codeigniter/user-guide/overview/appflow.html]
Figure 4.2 illustrates how a typical CodeIgniter web application works. CodeIgniter User Guide has a fairly simple description on how data flows throughout the framework :
"The index.php serves as the front controller, initializing the base resources needed to run CodeIgniter. The Router examines the HTTP request to determine what should be done with it. If a cache file exists, it is sent directly to the browser, bypassing the normal system execution. Before the application controller is loaded, the HTTP request and any user submitted data is filtered for security. The Controller loads the model, core libraries, helpers, and any other resources needed to process the specific request. The finalized View is rendered then sent to the web browser to be seen. If caching is enabled, the view is cached first so that on subsequent requests it can be served."
4.1.3 Projects' Overall Architecture
As shown by Figure 4.3, the overall architecture of the system consists of a number of Controllers, Models and Views interacting together as explained in the section 4.1.2, three third-party classes and the database which is separate from the MVC architecture since CodeIgniter's database class [AR1] and Active Record [AR2] library facilitate the creation of database independent applications.
M_admin, M_users, M_graph and M_list are the main models of the system. All models extend CI_Model class and utilise the Active Record library to communicate with the database. Every model can be called from one or more controllers. Admin, Users, Welcome and Graph_con are the main controllers (all extend CI_Controller class) each dealing with different aspects of the system such us the login system or the presentation of data. Each controller can load one or more views depending on the request received by the user. Each page is constructed by combining three different views; header, main view and footer.
In addition to the Models, Views and Controllers, there are three third-party classes; chart class, grChartImg and JQuery UI. Chart class generates the graph and table based on the data retrieved by the model and passed to the view via the controller. grChartImg is responsible for converting the graph to image in order to be ready for download and JQuery UI is generating the calendar widget in the view.
C:\Users\USER\Desktop\University\Third year 2012-2013\Dissertation\images\ClassDiagram.png
Figure 4.3 - overall architecture of the system
4.2 Detailed Design
4.2.1 CodeIgniter and Third-party Libraries
CodeIgniter comes with many core libraries that provide ways to code applications much faster, easier and simpler than without libraries, removing much of the unnecessary code from applications. In this section four major CodeIgniter Libraries that are going to be used during the development of this project are covered; starting from the Database and Active Record Libraries, followed by the Session Library, the Form Validation and the Email Library.
Since CodeIgniter cannot provide all the required functionalities for the project, such as the ability to generate graphs using the data in the database, some third-party libraries have to be used. These include Google Chart Tools for creating graphs and JQuery UI.
Database and Active Record Libraries
One of the most important libraries in CodeIgniter that provides a simple but efficient way to interact with a Database is the Database Library which supports both traditional structures and Active Record patterns.
After the library has been loaded a SQL Query can be run on the database using the code:
or any of the Active Records' functions (See Appendix C tadeeee for some examples of how SQL Queries can be constructed using Active Record Library).
The Active Record Database Pattern used in CodeIgniter is quite different from the one found in Rails and other Frameworks. Active Record in CodeIgniter does not require that each database table is its own class file and it works by using different functions to build up the desired query. This allows data to be retrieved, inserted, and updated in the database with just few lines of code (in some cases one or two lines of code are enough to produce the desired result). Besides the simplicity of the code, another major benefit of using the Active Record library is that Active Record queries are independent of any type of Database SQL hence it facilitates the creation of database independent applications. [AR2-AR3] Active Record is the foundation of model layer. Each time the website is going to request data from the database or insert/update data Active Records will be used.
The Session [SESS] class is another useful library especially for websites that are required to have a lot of users with different privileges. It allows the developers to maintain a user's "state" and track their activity while they browse the website. In CodeIgniter a session is an array containing the user's unique Session ID (a randomly-generated string with very strong entropy, which is hashed with MD5 for portability, and is regenerated every five minutes), the user's IP Address, the user's User Agent data and the "last activity" time stamp. The session class stores this information as serialized data (which can optionally be encrypted) inside a cookie. It can also store the session data in a database for added security, as this means that the data in user's cookie must match against the stored session data. It doesn't make use of native PHP sessions. It generates its own session data, offering more flexibility for developers. It also permits the developer to work with session data, add his own data to the session, retrieve them or remove them. [AR2 - SESS]
Since this website will involve users, sessions are important to keep track of who is online. It will be the major part of the login system. When a user logs into the website a new session should be created containing all the information discussed above along with his username, user type and other data needed by the controllers and views. Among other benefits, this will enable the implementation of different views containing various functionalities based on what type the user is (administrator or user). The session should be destroyed as soon as the user logs out.
Form Validation Library
Form Validation Library [FORM] provides a great way to easily and efficiently validate and secure any form in the website. Running validations before submitting content is important, mainly for security reasons. Malicious users, for example, can type in some SQL code and retrieve data from the database. Therefore using validation rules is required if you want to prevent this type of users abusing the forms in your website. A list of rules and prepping functions provided by the library can be found in appendices section - appendix D. [AR2 - Form] In order to implement form validation, in CodeIgniter, three things are needed, two View files (one containing a form and the other containing a "success" message to be displayed upon successful submission) and a controllerÂ function to receive and process the submitted data. One can also implement form validation with just one view and one controller - the "success" message can be passed to the same view in a variable.
Form Validation will be used in all the forms in the website from the form included in the login system to the forms in the control panel used for adding/editing companies, units and projects. It is important to mark required fields and state their type and size to prevent the submission of irrelevant or malicious content.
CodeIgniter offers a robust Email class [EM] that makes sending emails from the application - whether this is a simple contact form or confirmation email upon user registration or even a mass mailing list - a fairly easy job. The Email class supports multiple protocols (the standard PHP mail function, sendmail, or Simple Mail Transfer Protocol (SMTP)), multiple recipients, CC and BCCs, HTML or plaintext email, Attachments, Word Wrapping, Priorities, BCC Batch Mode and email Debugging tools. [EM - AR2] Emails can be sent not only from inside Controllers but also from inside Models.
This library will most probably be used in the registration system. After the administrator has successfully registered a user, a confirmation email should be sent to the user containing his login credentials. It can also be used when the administrator updates the details of a specific user.
Chart Library (Google Chart Tools) and grChartImg library
grChartImg[CIMG] is a library specialized for Google Chart Tools. It uses the free canvg[canvg] library to transform interactive Vector Charts into HTML5 Canvas element enabling the user to see the graph as image in another window, copy the image to clipboard and even download the image to his personal computer.
Both Libraries will be used in the view responsible for generating the graph. They are going to be responsible for generating the graph containing the data passed on by the corresponding controller and for converting the graph to image ready for export.
4.2.2 Functionalities of the System
Functionalities of the system -State and discuss requirements (significant parts) - show a UML diagram (activity or sequence) describing the requirement
4.2.3 Database Design
Description of the DB - describe components that interact with it - Entity Relationship database diagram - normalized??? Redundancy and dependency
Figure 4.3 represents the database design along with the relationships between the foreign keys of the tables as it stands at the end of the project. One can observe that there are two distinguishable parts: the Article administration and User management. In the first category somewhat remote stands the entity of Archived Article, which seems to not have any connection/relation to Article, as one would assume based on the name. The reason for keeping with this design choice is that one is not interested in other entities except in recording the changes occurred to the article. Archived Article behaves like a specialized log or back-up device for the articles and should be separate from the overall design as the integrity of the database would probably suffer if the two tables were linked together. Also related to Article are the tables of tags and taggings which were included at a later stage as an aid for searching based on keywords.
The ER digram shown in the image above contains two entities -- people and cities. There is a single "Lives In" relationship. In our example, due to space constraints, there is only one attribute associated with each entity. People have names and cities have populations. In a real-world example, each one of these would likely have many different attributes.
When a relational database is to be designed, an entity-relationship diagram is drawn at an early stage and developed as the requirements of the database and its processing become better understood. Drawing an entity-relationship diagram aids understanding of an organization's data needs and can serve as aÂ schemaÂ diagram for the required system's database. A schema disgram is any diagram that attempts to show the structure of tha data in a database. AnÂ entity typeÂ is any type of object that we wish to store data about. Which entity types you decide to include on your diagram depends on your application. In an accounting application for a business you would store data about customers, suppliers, products, invoices and payments and if the business manufactured the products, you would need to store data about materials and production steps. Each of these would be classified as an entity type because you would want to store data about each one.
The data that we want to keep about each entity within an entity type is contained inÂ attributes. An attribute is some quality about the entities that we are interested in and want to hold on the database. In fact we store the value of the attributes on the database. Each entity within the entity type will have the same set of attributes, but in general differentÂ attribute values. For example the value of the attribute ADDRESS for a customer J. Smith in a CUSTOMER entity type might be '10 Downing St., London' whereas the value of the attribute 'address' for another customer J. Major might be '22 Railway Cuttings, Cheam'.
There will be the same number of attributes for each entity within an entity type. That is one of the characteristics of entity-relationship modelling and relational databases. We store the same type of facts (attributes) about every entity within the entity type. If you knew that one of your customers happened to be your cousin, there would be no attribute to store that fact in, unless you wanted to have a 'cousin-yes-no' attribute, in which case nearly every customer would be a `no', which would be considered a waste of space.
3.4 Primary Key
Attributes can be shown on the entity-relationship diagram in an oval. In Fig. 3.1, one of the attributes of the entity type CUSTOMER is shown. It is up to you which attributes you show on the diagram. In many cases an entity type may have ten or more attributes. There is often not room on the diagram to showÂ allÂ of the attributes, but you might choose to show an attribute that is used to identify each entity from all the others in the entity type. This attribute is known as theÂ primary key. In some cases you might need more than one attribute in the primary key to identify the entities.
In Fig. 3.1, the attribute CUS_NO is shown. Assuming the organization storing the data ensures that each customer is allocated a different cus_no, that attribute could act as the primary key, since it identifies each customer; it distinguishes each customer from all the rest. No two customers have the same value for the attribute cus_no. Some people would say that an attribute is a candidate for being a primary key because it is `unique'. They mean that no two entities within that entity type can have the same value of that attribute. In practice it is best not to use that word because it has other connotations.
As already mentioned, you may need to have a group of attributes to form a primary key, rather than just one attribute, although the latter is more common. For example if the organization using the CUSTOMER entity type did not allocate a customer number to its customers, then it might be necessary to use aÂ composite key, for example one consisting of the attributes SURNAME and INITIALS together, to distinguish between customers with common surnames such as Smith. Even this may not be sufficient in some cases.
Primary keys are not the only attributes you might want to show on the entity-relationship diagram. For example, in a manufacturing organization you might have an entity type called COMPONENT and you want to make it clear on the entity-relationship diagram that the entities within the type are not single components but a component type such as a BC109 transistor. There are thousands of BC109s in stock and any one will do for any application. It is therefore not necessary to identify each BC109 differently (they all look and work the same). However you might want to distinguish BC109s from another transistor type BC108. To make it clear that you are considering all the BC109s as one entity and all the BC108s as another entity, you might put the attribute QIS (quantity in stock) on the entity-relationship diagram as in Fig. 3.2. This makes it clearer at the entity-relationship model level that each entity in the entity type is in fact a stock item of which there will be several in stock. Any doubts on this point should be resolved by inspecting theÂ entity description, which shows all the attributes of the entity type and (ideally) their meaning. The primary key might be STOCK_NO and one of the attributes QIS, which should remove any doubt on this point.
Database normalizationÂ is the process of organizing theÂ fieldsÂ andÂ tablesÂ of aÂ relational databaseÂ to minimizeÂ redundancyÂ and dependency. Normalization usually involves dividing large tables into smaller (and less redundant) tables and defining relationships between them. The objective is to isolate data so that additions, deletions, and modifications of a field can be made in just one table and then propagated through the rest of the database using the defined relationships.