CHAPTER is ultimately concerned with the technical aspects of

CHAPTER THREESYSTEM ANALYSIS & DESIGN3.1 IntroductionSystems analysis is essentially the study of a business problem domain to recommend improvements and specify business requirements and priorities for the solution. On the other hand, system design is the specification or construction of a technical, computer-based solution for the business requirements identified in a system analysis. The databases, programs, user interfaces, and networks required by the information system implement the technical blueprints and specifications developed during the system design phase.   The Unified Modelling Language, or UML, is the world standard for the specification of software engineering processes: it therefore follows that there will be a number of UML process models illustrating various functional aspects of the system under consideration.  3.2 System Requirement Specification System requirements, in a nutshell, encapsulate the needs of the eventual end users of a given information management system. With regards to the chat system, these requirements are as following corresponding to the core operational phases of the system:a. User authentication;b. Result generation; c. Group creation;d. Friend request;e. User authentication;f. Error resolution.3.3 System Design The system design is ultimately concerned with the technical aspects of system development: in the broad sense, it can be grouped into two distinct parts:a. The logical design; andb. The physical design.3.3.1 Logical Design The logical design specifies the intended operation and behaviour of the system, i.e. how the system will meet its desired goals and objectives. In this regard, the design scheme covers the overall general functions of the system – as earlier stated, these are user authentication, result retrieval and result error detection and resolution – as well as the specific details relevant to each of these core functions. These specific details are captured in the following areas of detail:a. Input;b. Output; andc. Navigation. Input Design In defining adequate input schemes for the system, the factors taken into consideration are:a. Accuracy: As is the case in all forms of public information, the system data must be correct and current in order to be credible. Thus the input scheme must make adequate provision for input validation and error control;b. Usability: In addition to being error-proof at all times, the input scheme must also be both accessible and comprehensible, meaning that the input scheme presents minimum difficulty in use for any user.c. The pre-existence of related data structures, especially for regular (i.e. desktop-size) devices: This single factor has the most impact on the input scheme, as it directly affects the scale of the application as a whole. If a chat group database already exists, then the application becomes merely a mobile-based widget; if not, then it becomes a full-fledged system in its own right. Output DesignThe design for the various system screens are given below; Menu Or Navigation Design The importance of the menu design to the success of the application cannot be overstated. The key considerations taken into account here include:a. AccessibilityThe navigation system has to be immediately accessible at all times to all users;b. Claritythe visual language used in the navigational scheme has to be completely understandable to all users.The navigational scheme used for the Chat system consists of two major parts: a. The main menu;b. The hyperlinks within each page.The main menu is composed of those links which would ordinarily be found on every screen of the application; these are:a. the Home button;b. the Back button;c. the Profile button;d. the About button;e. The Logout button; Use Case Diagram In object-oriented methodology, the necessity of the use case model is predicated on the fact that all real-world systems possess a human element, devoid of which such a system cannot possibly exist. Thus, use cases represent discrete units of interaction between a user (human or machine) and the system. The use case model for the internet / intranet Chat system is illustrated in Figure 3.1, and works as follows:a. Access to the system begins at the Login operation, where user enters login details (username and password), for onward verification by the system;b. Where Student, Lecturer or Staff has not initially registered on the system, or not renewed such registration for a new session, he or she may do so by confirming his personal details in the online registration form.c. User then activates his or her account using a link sent by the system to User’s email address.d. Once his or her account has been activated or renewed, Student, lecturer or staff will be granted access to the system in fulle. Figure 3.8. Use Case Model for the Chat online results checker application system. ACTIVITY DIAGRAM An activity diagram illustrates the business and operational workflows of components in a system, showing step-by-step the overall flow of control within the system. Figure 3.9. Activity diagram for the Chat examination results checker. The activity diagram depicts the Chat as a series of interconnected processes and decision points; these processes succeed each other depending on the outcome of preceding processes within the system, as determined from the decision points. The diagram illustrates the path that users travel in their use of the system; as is to be expected within multi-user environments, this path differs from user to user, depending on his or her user type. Class DiagramIn software engineering, a UML class diagram is a static structure diagram which describes the structure of a system by showing the system’s classes, their attributes, operations (or methods), and the relationships among the classes.The system structure illustrates the relationships among the classes in terms of the logical connection between them – this may occur either at the class or instance level – as well as the scale at which they occur: this is indicated by the multiplicity qualifiers applied to each relationship. Figure 3.10. Class Diagram illustrating the Chat system.   3.3.2 Physical Design In sharp contrast to the logical design, the physical design outlines the boundaries within, or to a greater degree, along, which the concepts outlined in the logical design are actualized in terms of software and hardware. Program SpecificationThe program specification represents a mathematical description of software or hardware which may be used to develop an implementation; in this regard, it stands to reason that the system performance is never correct in isolation, but only to the particular specification. The main aspects covered by the program specification are:a) the program application logic.b) Data structure Application Logic Specifications The application logic lies at the core of the program, coordinating data access, processing and presentation. A good grasp of what the solution does can be gleaned from the specification, and it is a general rule of thumb that a solution is correct only to the specification upon which it is based. A sample of the pseudo-code used in developing this system is shown in Figure 3.11.function login get username as user.username get password as user.password if (username and password are correct) then set session variables: username, usergroup, url, previousUrl if (access is permitted for user) then if (session.url is set) then go to session.url else go to home screen end if else go to access denied screen end if end ifend function function menu outline menu according to user.usergroupend function functionget_course_chats get result scores for student foreach (chatrequest as req) group according to chat class get grouped list get friend list return total friend list  as get_friend(is_friend))end function functionget_setting update getsettting request if (settting request is valid) if (user is admin) returnsettting string command else return “N/A”end function function logout go to prelogout screen click button if (button clicked is Yes) destroy session go to login screen else go to previous screen end ifend functionFigure 3.11 Section of the pseudocode underlying the Chat application. System ControlsSystem Controls are the mechanisms built into a system with the aim of maintaining the integrity of a system and protecting it from misuse.In proposed Chat system, the following controls have been included:  1 – Any intending user of the system must provide a valid user name and user password before he can be granted access. As a result, only duly registered students are granted access to the students section of the system and only valid administrative staff is granted access to the admin section of the system.2 – Data inputted by the users of the system are also validated for possible errors. The system checks to ensure that blank data is not submitted by the user. Also checks are performed to ensure that the data provided by the user is in the correct data format expected by the system.3 – The system also checks and provides warnings/error messages when a user attempts to perform an action that may place the system in an invalid state. Layout of Files/Table DesignThe database is implemented in MySQL and the layout of the database tables is given below.1. Registration table tableThe table maintains information on each student, staff and lecturer who has been registered on the systemFieldData TypeDescriptionUsernameVarchar(15)usernameOldnameVarchar(45)User oldnamePasswordVarchar(16)PasswordStatusVarchar(3)User statusUser emailVarchar(50)User email addressUser accessVarchar(50)User accessTable 3.3 Layout user table   2. Room tableThe room table maintains information on the chat systemFieldData TypeDescriptionroomIdVarchar(15)Room ID primary keyroomNameVarchar(10)roomName for register userTopicFloatRoom topicAccessInt Access to room chat table   Table 3.4Layout of chat room table          3. chat tableThe chat table maintains chats available on the systemFieldData TypeDescriptionPostidInt(11) Auto_increment (primary key)userIdVarchar(70)User ID from user tablePost_dateDatePost date chat was postedPost_timeTimePost time chat was postedPost_user Varchar(100)Post user IDPost messageVarchar(100)Post messagePost colorVarchar(100)Post colorAvatarVarchar(100)Avatar for the chatTable 3.5Layout of chat table 4. schsession tableThe session table maintains information about each chat session created in the systemFieldData TypeDescriptionsessionIDIntA unique value used to identify this academic session within the systemSessionnameVarchar(70)The name of the academic sessionTable 3.6Layout of session table of Database            Figure 3.12 Database structure            REFERENCESAdagunodo, E. R., Awodele, O., & Idowu, S. (2009). “SMS User Interface Result Checking System”. Issues in Informing Science and Information Technology, vol. 6: p. 105.binti Solaiman, Z. (2006). The Development of Java-Based SMS Exam Result System In Mobile Computing Environment. Undergraduate Project Report, Universiti Teknologi Mara, Shah Alam. Available: Schach, S. R. (2008). Object-Oriented Software Engineering. Boston: McGraw-Hill.Wikipedia (2001, October 19). Mobile Application Development. Retrieved August 10, 2011, from Wikipedia, the free encyclopedia: (2001, October 19). Mobile Phone. Retrieved August 10, 2011, from Wikipedia, the free encyclopedia: (2012, April 1). Software maintenance. Retrieved from Wikipedia, The Free Encyclopedia:, B. (1990, September 20). Software Testing Techniques (2nd ed.). New York: Van Nostrand ReinholdBinder, R. V. (1999).Testing Object-Oriented Systems: Objects, Patterns, and Tools. Addison-Wesley Professional. Hetzel, W. C. (1988). The Complete Guide to Software Testing, 2nd ed. Wellesley, Mass. : QED Information Sciences   Myers, G. J. (1979). The art of software testing,  New York : Wiley