CHAPTER 2. SYSTEM ANALYSIS AND DESIGN
2.1. The functional hierarchy diagram
The Manage iChat includes the following functions: Manage Profile, Make Friends, Chat, Create Groups and Manage Settings. The Profile Management includes the following functions: Add information and Edit information. The Make friends includes the following functions: Search, Add and Delete friends. The Chat includes the following functions: Send File, Image, Text and Video. The Make Group includes the following functions: Add, Delete and Search Member.
Fig 2.1. The functional hierarchy diagram 2.2. Use case diagram
2.2.1. Function overview
This is a use case diagram that summarizes the functions available in the system.
Chart name System use case diagram
Agent User
Step 1: Users login into the system according to the
Describe registered account
Step 2: After logging in to the system, users can use the following functions: chat, create groups, view friends list, add, delete friends or members in the group if that person is the creator group, manage profiles and settings.
Fig 2.2. System use case diagram 2.2.2. Account verification
Fig 2.3. Use case chart: Account verification
Function name Account verification Agent User
Pre-conditions Users are not logged in to the iChat application
Steps to take
Step 1: The user logs in to the application
Step 2: User password account authentication system in the database
Step 3: Login: - Success: Fulfill other requests;
- Failure: Switch to forked stream.
Step 4: Sign out
Event branching stream:
Step 1: User login failed
- The system sends a failed login message;
- Ask the user to re-login;
- The user agrees then go back to the first step of the login;
- The user does not agree to end the use case.
Step 2: User chooses forgot password
- At this time, the system automatically sends an email to the user's pre-registered email for the user to authenticate the account to change the new password;
- The user agrees to authenticate to change the password of the system to update the database;
- User does not agree to end the use case.
The following condition
The user is successfully logged in and can use the functions available to them in the chat application
2.2.3. Chat
Fig 2.4. Use case diagram: Chat Function name Chat
Agent User
Pre-conditions The user logged in to the iChat application.
Steps to take
Step 1: The user selects the chat function
Step 2: The system displays a list of chats including 1-1 chats and group chats
Step 3: The user selects any chat and performs the functions available in the chat
End of use case.
The following condition
Users can use the functions included in the chat to make their requests.
2.2.4. Group management
Fig 2.5. Use case diagram: Group management
Function name Group management
Agent User
Pre-conditions The user logged in to the iChat application
Steps to take
Step 1: The user chooses the group creation function Step 2: The system displays the interface to create groups and friends list for users to choose members to add to the group
Step 3: The user selects the friends to add to the group and selects "next"
Step 4: The system will add a list of friends to the group selected by the user
Step 5: Users name the group, change the avatar and can add members to the group if desired and select "next"
Step 6: The system will update the group information and the list of members of the group
End of use case.
The following
condition New group created successfully
2.2.5. Manage friends list
Fig 2.6. Use case chart: Manage friends list
Function name Manage friends list
Agent User
Pre-conditions The user logged in to the iChat application
Steps to take
Step 1: The user selects the friend icon
Step 2: The system displays a list of existing friends
Step 3: The user selects one of the existing functions in the interface displaying the list of friends such as search or remove friends and selects the confirmation button corresponding to each function
Step 4: The system will perform the function selected by the user and update the friend list
End of use case.
The following
condition Users have a list of friends at their disposal
2.2.6. Account management
Fig 2.7. Use case chart: Account management
Function name Account management
Agent User
Pre-conditions The user logged in to the iChat application
Steps to take Step 1: The user selects the account management function Step 2: Users select View personal information
Step 3: Users select Update personal information (Switch to forked stream)
Step 4: The system displays the user's personal information and ends the use case.
Event branching stream:
Step 1: The user selects Update Personal Information
Step 2: The system displays the items in the user profile that can be updated
Step 3: User update then select done
- Success: The system sends a successful message;
- Failure: Show failed update message;
- If the user chooses to update again, go back to the update step;
- If the user does not agree, end the use case.
The following
condition Users can view their personal information and can update the information accordingly.
2.3. Activity chart
2.3.1. Functional Analysis: Login
User login account and password. The system receives the login request and checks. If valid, the system will notify the successful login and redirect the user to the main interface. If it is not valid, the system will send a request for the user to choose to log in again or choose to forget the password in case the user does not remember his login password. If the user agrees then return to the initial login step. If the user does not agree then end the login.
Fig 2.8. Function activity chart: Login
2.3.2. Functional Analysis: Chat
The sender enters the content of the message to send and selects send. The system receives requests and checks. If the message is valid, the system will send it to the recipient and complete it. If it is invalid, the system will send an error message and ask the sender to compose the message again. If the user agrees, then proceed to compose the message to be sent. If the user does not agree, end the task.
Fig 2.9. Function activity chart: Chat 2.3.3. Functional Analysis: Manage friends list
The user logs into the system and selects the interface displaying the list of friends. Here the user selects any action such as adding, searching, or deleting friends
and chooses to execute the task. The system receives the request and conducts the check. If it is valid, it will notify you of the successful execution of the task and save the information to the system, and terminate the program. If it is not valid, the system will send a message to the user and ask to perform the task again. If the user agrees, then return to the task execution step. If the user does not agree, the program ends.
Fig 2.10. Function activity chart: Manage friends list
2.3.4. Functional Analysis: Group management
Users log into the system and choose to find groups or create new groups.
Select a task and execute the task. The system receives the request and conducts the check. If valid, the system will notify you to successfully execute and update the system, then terminate the program. If it is not valid, the system will send an error message and ask the user to perform the operation again. If the user agrees, the task execution phase is repeated. If the user does not agree, the program ends.
Fig 2.11. Function activity chart: Group management 2.3.5. Functional Analysis: Account management
The user logs into the system and selects the account management item. Select a task and proceed to execute the task included in that management list. The system
receives the request and conducts the check. If valid, the system will notify the successful action and update the information in the system. If it is not valid, the system will send an error message and ask to perform the task again. If the user agrees, then proceed to the task execution step again. If the user does not agree, the program ends.
Fig 2.12. Function activity chart: Account management
2.4. Sequence diagram 2.4.1. Login chart
Here is the log function sequence diagram. There are 3 main objects: user, system, and database. The login function processing flow is explained as follows: The user enters information including username and password and then sends the login information to the system. The system receives the login request and sends the user information to the database for checking. The database checks and returns the results to the system. The system returns the message to the user. If the user account already exists, the login is successful otherwise, the login fails.
Fig 2.13. Function sequence diagram: Login
2.4.2. Video call chart
This is the sequence diagram of the video call function. Consists of 3 main objects: user1, user2, and the database. The video call function processing flow is explained as follows: User1 logs into the system. The system receives the login information and sends it to the database for checking. The database returns the results and the system responds with a successful login.
User1 chooses the video call function for user2. The system receives the request and sends it to user2. User2 receives a call from user1 and responds to use1.
The system receives the request. If the user is busy, the connection fails. If user1 is
available then the connection is successful and user2's call is received.
Fig 2.14. Function sequence diagram: Video call
2.4.3. Add friend chart
This is a sequence diagram of the add friends function. Consists of two main objects: user, database.
Fig 2.15. Function sequence diagram: Add friend
Users here include user one and user two. The processing flow of the add friend function is explained as follows: User one conducts a friend search, the test database, and responds with a successful search result. User one chooses the add friends function and sends a request to the database.
The database receives the information and sends a friend request to user two.
User two receives information and sends feedback to user two. If user two agrees to make friends, the results will be returned to the database, the database will notify you of adding friends successfully and the system will automatically create a new conversation If user two does not agree to make friends, the system will The system notifies more friends of the person a failure.
2.4.4. Chat chart
This is the sequence diagram of the group chat function. There are 3 main objects: User, chat interface, and database. The flow of the group chat function is explained as follows: The user sends a request to see the friends list and the system sends the request to the database.
The database sends feedback about the friend list. The user chooses any friend and goes to the chat interface. The user enters the message content and sends it. The chat interface will send the content to the database and the database will respond to the status of the message whether it was sent successfully or failed.
Fig 2.16. Function sequence diagram: Chat 2.5. Database
2.5.1. Database tables
Num Table Describe
1 Users Table containing users information 2 Friends Table containing friends information 3 Conversation Table containing conversation information 4 Participant Table containing participant information 5 Message Table containing message information
6 Typeof_Message Table containing type of message information T2.1. Database tables
Table 1: USERS
- Purpose: used to store user's account information;
- Table name in the database: users.
ID Name Datatypes Key/ Constraint Meaning
1 Email Varchar(100) Not null Email
2 UserName nvarchar(100) PK User name
3 Password Varchar(40) Not null Password
4 Profile_pic text Not null Profile_pic
5 Connection_request varchar(200) Not null Connection request
6 Creation date datetime Not null Creation date
7 Creation time datetime Not null Creation time
8 Token string Not null token
9 Phone_number Int Not null Phone number
10 about text Not null about
T2.2. Table USERS
Table 2: MESSAGE
- Purpose: used to store information of messages;
- Table name in the database: message.
ID Name Datatypes Key/ Constraint Meaning
1 Mes_id int PK Messger ID
2 Sender_id int FK Sender ID
3 Active Nvarchar(50) Not null Active
4 Mes_Type_ID int FK Message type
5 Time Datetime Not null Time
6 Conver_id int FK Conver id
T2.3. Table MESSAGE Table 3: TYPEOF_MESSAGE
- Purpose: used to store information of message type;
- Table name in the database: typeof_message.
ID Name Datatypes Key/ Constraint Meaning
1 Mes_type_id int PK Message type id
2 Name text Not null Name
3 Datatype text Not null Data type
T2.4. Table TYPEOF_MESSAGE Table 4: PARTICIPANT
- Purpose: used to store group member information;
- Table name in the database: participant.
ID Name Datatypes Key/ Constraint Meaning
1 Par_id int PK Participant id
2 Conver_id int FK Conver id
3 User_id int FK User id
4 Status Nvarchar(20) Not null status
T2.5. Table PARTICIPANT Table 5: FRIENDS
- Purpose: used to store friends' information;
- Table name in the database: friends.
ID Name Datatypes Key/ Constraint Meaning
1 Friend_ID int PK Friend ID
2 User1_id Int FK User1 id
3 User2_id int FK User2 id
T2.6. Table FRIENDS Table 6: CONVERSATION
- Purpose: used to store chat information;
- Table name in database: conversation.
ID Name Datatypes Key/ Constraint Meaning
1 Conver_ID int PK Conversation ID
2 Conver_name Nvarchar(200) Not null Conversation name
3 Image Varchar(100) Not null Image
T2.7. Table CONVERSATION 2.5.2. Database diagram
This is a diagram of the relationship between the database tables including the tables: users, message, conversation, participant, typeof_message, friends. 1-1, N-N links are joined between the tables to represent the corresponding association of the tables together.
Fig 2.17. Database Diagram