Title of Project
Medical indigenous knowledge system-query service
Mentoring
Mr P Tarwireyi, lecturer for Computer Science, University of Zululand
Software Design Document (SDD)
Version 1.0
Title of Project
Medical indigenous knowledge system-query service
Mentoring
Mr P Tarwireyi, lecturer for Computer Science, University of Zululand
Student no: 201131437
Contents 1. Introduction 2 1.1. Purpose of the System Design Document 2 1.2. Scope 2 1.3. Glossary 3 1.4. References 3 1.5. Overview of document 3 2.0. Assumptions / Constraints / Risks 4 2.1. Assumptions 4 2.2. Constraints 4 2.3. Risks 4 3.0. Architecture design 5 3.1. Medical indigenous knowledge system web MVC architecture 5
Figure 1 Architecture Design 5 4.0. Design 5 4.1. Class diagram 5
Figure 2 show how classes interact to each other to compose the full MIK System 6 4.2. Data flow diagram 6
Figure 3 its show that how the data flow during the user/patient interaction with MIKS 7 5.0. Use cases 8
Figure 4 System user case Diagram 8 6.0. Use case realizations 11
Figure 5 System Sequence Diagram 11
Figure 6 Administrator Sequence Diagram 11
Figure 7 User/Patient Sequence Diagram 12 7.0. Activity diagram 13 7.1. Activity diagram for search information 13
Figure 9 Search for information activity diagram 13 7.2. Activity diagram for the Forum 13
Figure 10 Forum activity diagram 13 7.3. Activity diagram Chart-Room 14 activity diagram 14 8.0. Interface design 14
1. Introduction
1.1. Purpose of the System Design Document
This Software Design Document provides the design details of Medical indigenous knowledge system-query service (MIKS).
The expected audience is people who still believe in the use of indigenous medicine, including traditional healers and rural/urban committee members, the MIKS developers, and the people who will maintain the MIKS. It will also serve as a reference for health statistical use of indigenous medicine. 1.2. Scope
This document contains a complete description of the design of MIKS.
The basic architecture is a web server from a client server paradigm. The basic pages will be in HTML, PHP, JAVASCRIPT, jQUERY and CSS.
The designated administrator in charge of the MIKS will have full access to make changes, as he/she would be given an access to delete/denial access to users. The changes could include, but not limited to, changing the content and pictures in the main page since the webpage is design to be dynamic, data insertion for the users to query for, take comments of users and reply where necessary, and the ability to allow users to privately exchange messages on our chart . 1.3. Glossary Term | Definition | MIKS | Medical indigenous knowledge system | SDD | Software design document | PHP | Hypertext Pre-processor | CSS | Cascading style sheet | Html | Hypertext mark-up language | IEEE | Institute of Electrical and Electronic Engineers | SDD | Software Design Document | SRS | Software Requirement Specification | Web Site | A place on the world wide web |
1.4. References
[IEEE] The applicable IEEE standards are published in “IEEE Standards Collection,”
2001 edition.
[Bruade] The principal source of textbook material is “Software Engineering: An Object-
Oriented Perspective” by Eric J. Bruade (Wiley 2001). 1.5. Overview of document
The remaining chapters and their contents are listed below.
Section 2 discusses the system assumptions, constraints and risks.
Section 3 is the Architectural Design that specifies the design entities that collaborate to perform all the functions included in the system. Each of these entities has an Abstract description concerning the services that it provides to the rest of the system. In turn, each design entity is expanded into a set of lower-level design operations that collaborate to perform its services.
Section 4 concerns the Data Structure Design.
Section 5, 6 contains the Use Case Realizations. Each Use Case stated in the SRS Document can be traced by the given design objects.
Section 7 Activity diagram is a Deployment Diagram that shows the physical locations where the system actually exists. This allows a clear explanation of where each design entity will reside. Each part will work in unison to accomplish each requested task.
Section 8 discusses the User Interface Design, and how it can be created with maximum user efficiency and ease of use.
2.0. Assumptions / Constraints / Risks
2.1. Assumptions
It is assumed that the user/patient has the minimum basic knowledge on how to interact with the web applications and also will be connected to the internet. Lastly, the user/patient is assumed will be able to interact with other user/patient by the means of our forum/chart, in other words the user/patient is not naïve in social networks. 2.2. Constraints
Our first and foremost contracts are that user/patient will only able to access the MIKS application program via any kind of connectivity to the internet. 2.3. Risks
The risks about this system is first the crash of the host server and the other one is the crash of the system database yet even though there are means of duplication of our system but the performance maybe slow during this translation.
3.0. Architecture design
3.1. Medical indigenous knowledge system web MVC architecture Figure 1 Architecture Design
4.0. Design
4.1. Class diagram
Figure 2 show how classes interact to each other to compose the full MIK System
4.2. Data flow diagram
Figure 3 its show that how the data flow during the user/patient interaction with MIKS
5.0. Use cases System User case diagram
Figure 4 System user case Diagram
MIKS Home Page
Name: Medical indigenous knowledge system Home page
Type: Web page
Description: This is the home page presented to the user/patient upon connection with the host Server. There are five parts of the home page. One with links, search field, logo and posts, one with the site service, one to provide site portfolio, one to provide information about the site, one to contact the site administrator.
Operations:
Name: Select ()/click Returns: load content based on the user configuration Pre-condition: Connected to site Post-condition: want to search/view one of the page details or a transfer to another page (e.g. forum etc...) Exceptions: None
Flow of Events: 1. User/patient is presented with the MIKS Home Page. 2. User/patient clicks a one of the navigation then page will pull up that specific clicked navigation on top or take the user/patient to that page. 3. User/patient is provided with the (instant) search field for search of indigenous medical knowledge.
Forum (for user whose not log in)
Name: forum
Type: Web page
Description: When the user come to this page can only view all the posts, also by clicking show comment link then the user would then be able to only view comment for that specific post. For the user to add his/her post/comment must be login by clicking to the link provide on the top bar.
Operations:
Pre-condition: Connected to site Post-condition: view posts/comments Exceptions: None
Flow of Events: 1. user is presented with lists of posts and comment for each post (if any) 2. user/patient selects post from list of post then view comments under that post
Forum (for user whose login)
Name: forum
Type: Web page
Description: When the user come to this page can now view all the posts also create a new pots, also by clicking show comment link then the user would then be able to view comment also add comment for that specific post. The option for editing and deleting the posts is only appear to the user who has posted that post. For the user to go to chart-room/logout the user needs to click to the link provide on the top bar.
Operations:
Name: post/comment Arguments: None Returns: post/comment Pre-condition: Connected to site Post-condition: post/comment is created successfully Exceptions: None
Flow of Events: 1. user is presented with lists of posts and comment for each post (if any) 2. user/patient selects/add post from list of post then view/add comments under that post
Name:
Returns: created posts/comments Pre-condition: Connected to site Post-condition: view/add posts/comments Exceptions: None
Search for information/ for Users in the Chart-Room and Contact us
Name: Search for information/ for users in the chart-room and contact us
Type: Web page
Description: The user/patient can search for any traditional related medicine information in our system which uses the instant search mechanism (which filter information as the user type) to make query efficient. The user can search for the other user on our chart-room by simple type the username of that user. Most of our pages have form that allows the user to contact us, those complain or suggestions .etc. are directed to the administrator to reply on them where necessary.
Operations:
Submit (): suggestion/complain etc., query for traditional information and for the search of the users.
Returns: searched information and provide temporally feedback for those who has contacted us
Pre-condition: Connected to site
Post-condition: search and contact us
Exceptions: None
Flow of Events: 1. The user is on the search page. 2. The user type from the field that is provided to take that input. 3. The user/patient clicks submit since this system carter for both cases instant and manually search. 4. The host server queries the MIKS Database for the information 5. If the information is present, the host server will present it to the user. 6. 7.0. Use case realizations
Figure 5 System Sequence Diagram
Figure 6 Administrator Sequence Diagram
Figure 7 User/Patient Sequence Diagram
Figure 8 Search for information Sequence Diagram
7.0. Activity diagram
7.1. Activity diagram for search information
Figure 9 Search for information activity diagram
7.2. Activity diagram for the Forum
Figure 10 Forum activity diagram
7.3. Activity diagram Chart-Room
Figure 11 the Chart-room activity diagram
8.0. Interface design
The interface will use a similar design scheme matching the Web standard user interface used for today’s web pages to create a continuous effect.
Figure 12 Home page
This is what happens when the user/patient is searching for the traditional medical information
Figure 13 show the display of the searched result in the Home page
This is what happens when the user/patient is clicked read more option for the result return
Figure 14 show the display of the searched result in the subpage of home page
This is what happens when the user/patient is on the forum but not yet login
Figure 15 show the user/patient all posts and comments in the form
This is what happens when the user/patient is on the forum and login.
Figure 16 show the user/patient all posts and comments in the form and all fields to post and comment
This is what happens when the user/patient is on the forum and login.
Figure 17 show the user/patient only option to delete/edit the post that was posted by that specify user/patient
This is what happens when the user/patient is on the Chart-Room and login.
Figure 18 show the user/patient home page in the chart-room where the user can view all recent feeds option to delete/edit all posts
This is what happens when the user/patient is on the private messages page in theChart-Room
Figure 19 show the user/patient all private messages in the chart-room where the user can view/close and have option to delete/reply to all private messages
This is what happens when the user/patient is on the profile page in the Chart-Room.
Figure 20 show the user/patient profile picture. Poke and send massages buttons and the recent posts the user posted
This show the home page for the administrator after logging in.
Figure 21 show the administrator all options to maintain the web page and the data representation.
This show the administrator all information that users query for.
Figure 22 show the administrator all posts that contain information that users query for and provide option to delete and edit.
