Statement and Confirmation of Own Work

Transcription

1 Statement and Confirmation of Own Work Programme/Qualification name: University of Wales BSc (Hons) in Business Computing and Information Systems All NCC Education assessed assignments submitted by students must have this statement as the cover page or it will not be accepted for marking. Please ensure that this statement is either firmly attached to the cover of the assignment or electronically inserted into the front of the assignment. Student declaration I have read and understood NCC Education s Policy on Academic Dishonesty and Plagiarism. I can confirm the following details: Student ID/Registration number: Name: Centre Name: Module Name: Module Leader: Project Supervisor: Francois Dempers CTI Durbanville Information Systems Project Islam Choudhury Paul Bocij I confirm that this is my own work and that I have not plagiarised any part of it. I have also noted the assessment criteria and pass mark for assignments. Due Date: Sunday 9th August 2009 Student Signature: Francois Dempers ( ) Submitted Date: Sunday 9th August

2 Detailed Design Chat (Francois Dempers August 2009) Table of Contents 1) Introduction ) Background ) Design Goals ) Architecture ) Introduction ) Data ) Communication...6 3) Development ) Process ) Tools...8 4) Module Design Chat ) Overview ) Application Model ) Data Model ) Operation ) User types ) Licensing ) Installation ) Miscellaneous ) Conformance with standards ) Expandability ) Security ) Glossary ) Bibliography ) Appendix A Data Dictionary

3 1) Introduction 1.1) Background This is the detailed design document for the chat module of the Open Groups project. This document serves as an component level overview of the module. Every group on the system will have its own chat component. The purpose of the module is to provide a platform for the members of a system group to interact with each other in real time, without the usual delays associated with traditional components such as a forum or a blog. A key goal of the system is to provide a platform for users to collaborate, the chat module is intended to provide users with this platform. The module allows users to do the following actions: Send and receive text messages Send and receive video/audio messages Draw diagrams on a shared whiteboard This document forms 1 half of the module's detailed design. The other half being a user interface prototype which will be developed using this document as a basis for its design considerations. Parts of this document have been reproduced from the high level design document of the system, available from the system's project website at Please refer to the high level design document for further background information. 1.2) Design Goals The module should be designed in such a way, that users will find it easy and intuitive to use. The module should be easy to navigate and understand. An efficient design is especially important, because if users are unable to use the module, then a major project goal may be left unfulfilled, namely to provide an effective platform to support collaboration amongst group members. 3

4 2.) Architecture 2.1) Introduction The system will be created using a client-server architecture using the following technologies: Adobe AIR 1.5 used to develop the client side code PHP used to develop the server side scripts MySQL 5.0 used as the database server of the application As all of these technologies are able to run cross platform, thus the system will have no problem being deployed on Windows, Macintosh and the various distributions of Linux. Client side the application will run on the user's desktop. Each group member will have their own desktop client. The desktop clients will interface with a web server which is hosted on the Internet. The web server in turn has access to a database server also hosted online. A separate server is used for the chat and real-time capabilities of the application. Figure 1 depicts the overall system architecture. Figure 1 Overall System Architecture (Deployment Diagram) 4

5 The system will be developed in 7 distinct phases. Each phase will have it's own associated client side, server side and database code. Figure 2 lists the system development phases and their target completion dates. The development phase for the chat module is highlighted in yellow. ID Phase Hours Start Date Target Date DP1 Application Shell / Core System Jul Jul 2009 DP2 Forum Jul Aug 2009 DP3 Chat 21 7 Aug Aug 2009 DP4 Calendar Aug Aug 2009 DP5 Media Gallery Aug Aug 2009 DP6 Management Tasks Aug Aug 2009 DP7 Polls and Survey Aug Aug 2009 Figure 2 System Development Phases (Work Schedule) As the end of each phase is reached, the deliverables of that phase gets integrated into the overall system. DP1 develops the core of the system, where all other subsequent modules can integrate into. There are thus no dependencies between the other modules. Figure 3 depicts the resulting internal structure of the system. The development phase for the chat module is highlighted in yellow. DP1 DP2 DP3 DP4 DP5 DP6 DP7 Figure 3 Internal System Architecture 2.2) Data The system will have 1 central relational MySQL database hosted online which will serve as the primary data source for all of the system modules. The database will only be accessible via the PHP web server as shown in figure 1. The database schemata for the module is provided in section 4, and the supplementary data dictionary is provided in Appendix A. 5

6 2.3) Communication Communication between the AIR client and the PHP web server will be done through the AMF protocol. AMF is a native data exchange format (Patrick, 2007) used by AIR. Using AMF, data is compressed into a very small format, thus reducing the amount of bandwidth utilized by the application. AIR is able to serialize and de-serialize data to the AMF format extremely quickly because AMF is native to AIR itself. This enables data to be sent across the network quickly, thus reducing latency in the application. To enable the PHP web server to understand and interpret AMF data streams (Arnold, 2007) an additional PHP library called AMFPHP will be used. This library translates incoming AMF data into native PHP data, and also translates outgoing data back into AMF data. AFCS (Adobe, 2009) will be used to develop the chat module of the application. AFCS is a component library and hosted online service with which real-time social applications can be developed rapidly. Infrastructure and deployment concerns are taken care of as the service is hosted on Acrobat.com by Adobe. No server side components thus have to be developed. Modules which require SMS message to be sent will make use of the SMS gateway provided by 6

7 3) Development 3.1) Process As previously stated, each system module will be developed as a distinct new phase. At the start of every phase a detailed module design will be produced which will include a requirements model, user interface prototype, database design and class level design. Once the design is complete the system module can be developed, and integrated into the overall system. At this point various testing activities will be carried out such as unit testing, acceptance testing, regression testing, performance testing and usability testing. A test report will be produced after this is completed. The final steps in the process is to produce user and API documentation for the module, and to deploy the system to a production environment. Figure 4 shows this process and its artefacts in detail. Process Activity Artefact Detailed Design Requirements Modelling Use Case Diagrams Time Scheduling User Interface Prototyping Application Modelling Data Modelling Deployment Modelling Gantt Chart Executable Prototype Class Diagram, Sequence Diagrams Entity Relationship Diagram, Data Dictionary Deployment Diagram Build Development Source Code Integration Test Test Planning Test Plan Unit Testing Regression Testing Performance Testing Usability Testing Executable System Test Cases / Test Report Test Report Test Report Test Report Implementation Deployment Deployed System Documentation Figure 4 Module Development Process User Guide, API Reference Documentation 7

8 3.2) Tools There are a number of tools available that can be used to speed up the module development process. The Flex Builder 3 IDE has a built in tool for developing user interface prototypes, downloadable from API documentation can be generated using the ASDoc utility which ships standard with the IDE. Unit testing can be automated by using a unit testing framework, such as Flex Unit 4 available from An article concerning its implementation was created by Elrom (2009) and is available at StarUML has been used to produce all of the UML diagrams in this document, available from MySQL Workbench 5.0 OSS was used to create all of the entity relationship diagrams in this document, available from 8

9 4) Module Design Chat 4.1) Overview Group members are able to perform the following actions when using the chat component of their group: Send and receive text messages Send and receive video/audio messages Draw diagrams on a shared whiteboard Figure 5 shows the use cases that have been defined for the module. Figure 5 Chat Use Case Diagram Figures 6 illustrates the typical sequence of events which should occur given the user interactions with the system provided by figure 5. Figure 6 Chat Sequence Diagram 9

10 Information Systems Project: Project Proposal 4.2) Application Model Figure 7 provides an overview of the classes utilized by the module. Figure 7 Chat Class Diagram 10

11 4.3) Data Model Figure 8 provides the database schema used by the module. An accompanying data dictionary is supplied in Appendix A. The module has an extremely basic data model as most of it's functionalities are based on real time technologies rather then complex data storage. The data requirement of the module centres around the chaturl column of the groups table, which stores the URL of the Adobe Flash Collaboration Service chat room for each group. Figure 8 Chat Entity Relationship Diagram 5) Operation 5.1) User types The system has 4 distinct user types, they are: System User Group Member Group Manager Administrator A system user is an individual who has an account on the system, but has not joined any groups. They only have limited functionality, such as having a profile page and updating his/her account settings. A group member is an system user who has joined 1 or more groups. They have access to the same functionalities as a system user, as well as the modules of their groups. Group managers are system users who have created 1 or more groups. They have access to the same functionalities as a system users and group members. They also have access to the management features of the groups they manage. An administrators is a system user who have access over all system functionalities, including system administration functionalities. 5.2) Licensing With the permission of NCC education and the University of Wales, the source code of the project be licensed under the open source GNU Lesser General Public Licence available at: 5.3) Installation The client side application will be installed using an AIR installer package. Flex Builder 3 has a built in function to generate this package. In order to run software created with Adobe AIR, version 1.5 of the AIR runtime environment has to be installed on the users operating system, available from: 11

12 6) Miscellaneous 6.1) Conformance with standards Adobe has made available a detailed document concerning Flex coding conventions, available at: Likewise, Zend has also made available a detailed document concerning PHP coding conventions, available at: These documents should be consulted whilst developing the system to ensure that code is created in a consistent manner. This will result in professional looking code that is well organised and maintainable. 6.2) Expandability It is important that the system be developed in such a way which allows future developers to be able to extend functionality and built their own modules. Therefore, a modular architecture has been chosen to create the system to allow for easy future expansion and development. However, the building of special tools and measures to allow this is beyond the scope of the project at present and will be the concern of future system iterations. 6.3) Security Only individuals with registered accounts on the system will be able to gain access to it. Upon start up of the application users will be prompted to provide an address and password combination. This combination will be validated against the list of registered users on the system. The result thereof will be used to either grant or deny system access to a user. Additionally, measures will have to be put in place in order to prevent deliberate system attacks such as SQL injection. SQL injection (Laksmono, 2008) is a well known technique that can be used by attackers to gain access to, corrupt and delete the data in an online database. It works on the principal of typing malicious SQL queries into the text input fields of a online application instead of legal values. An effective way to prevent this in PHP is to use a built in function such as mysql_real_escape_string(). Refer to the following articles on this subject for more information:

13 7) Glossary Acronym API FUG IDE RIA SQL UID Description Application Programmer Interface Document used by developers to understand and extend a system. Flex User Group Community of Adobe Flex developers Integrated Development Environment System that can be used to develop software products. Rich Internet Application Software that uses the Internet to deliver it's content Structured Query Language, Is the de facto standard language used to interact with relational databases Unique Identifier Unique value identifying a record in a table 8) Bibliography Adobe. (2009) Adobe Flash Collaboration Service, [Online], Available: Retrieved 18 May Arnold, W. (2007) Flash remoting for PHP: A responsive Client-Server Architecture for the Web, [Online], Available: Retrieved 18 May Elrom, E. (2009) FlashBuilder 4 will support FlexUnit 4 - tutorials and feature overview, [Online], Available: Retrieved 30 May Laksmono, G. (2008) Simple PHP MySQL Injection Prevention, [Online], Available: Retrieved 28 May Patrick, T. (2007) The ABC's of AMF, [Online], Available: Retrieved 17 May ) Appendix A Data Dictionary Entity: Groups Description: Stores the groups a user can choose from. Attribute Type Description groupuid VARCHAR(32) The primary key of the table. groupname VARCHAR(55) The name of the group. description TEXT The description of the group. logourl VARCHAR(1000) The URL where the group's logo can be found. isarchived BOOLEAN True if the group is no longer active. chaturl VARCHAR(1000) The URL to the group's AFCS chat room. 13