4.2. Application Domain Analysis 4.2.1 Usage
In developing this application application system has two actors: administrator, who manage all the data inside the system;
user who use application and give suggestion. The administrator is involved in manage database, manage
website, update database website, log in, and manage user. Edit password and login process involving both actors. User participates
in login, give suggestion, download latest database from website, searching, and setting.
At this point in this analysis, it was clear that there were two actors involved.
Figure 4.5 Use Case Diagrams
4.2.2 Use Case Narrative 4.2.2.1 Use Case Narrative for Login
USE CASE NAME:
Login
PRIMARY ACTOR:
Administrator User
DESCRIPTION:
Use case login is started when the actor login to the system, which is the system
is checked the username and password automatically. The administrator and the
user must do login if they wanted to accsess the system.
PRE-CONDITION:
The username and password must be inserted by the administrator, or by
register new user.
TRIGGER: Use case login is started when the actor
login to the system.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1: User is want to access the system.
Step 3: User type in username
and password.
Step 2: System will display the
form login.
Step 4: System will display the
menu if both
username and
password is
match.
ALTERNATE COURSES:
CONCLUSION: This use case will be finished when the
system display the content
POST-CONDITION:
Actor can do several tasks, and check much information.
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS ASSUMPTIONS:
The user has provided a valid username
i
r e
.
U
e
r a
i v
e s
USE CASE NAME:
Manage Database
PRIMARY ACTOR:
Administrator
DESCRIPTION: g
u
Use case Manage Database is started when the administrator is wants to view,
edit, delete, and insert the information database.
PRE-CONDITION: TRIGGER:
4
Use case Manage Database is started when the administrator is wants to
manage database.
TYPICAL COURSE 7
Actor Action System Response
OF EVENTS:
s e
- c
a s
Step 1
: Administrator will
choose the data that want to edited and
deleted, also insert.. Step
3:
Administrator will
do some action.
Step 2
: System
display the form or alert.
Step 4: System will
save the changes that user made.
ALTERNATE COURSES:
n a
If user forgets to fill in some of the requirements information or give the
wrong value, system will display the error message.
CONCLUSION:
r This use case will be finished when there
is no data to be managed.
POST-CONDITION:
t Administrator will easily manage the
database.
IMPLEMENTATION CONTRAINTS
AND SPECIFICATIONS
The result will be displayed in database.
ASSUMPTIONS:
and password.
Figure 4.6 Use-case narratives for login
4.2.2.2 Narrative for Manage Database
F
for manage database
4.2.2.3 Use Case Narrative for Manage Website USE CASE NAME:
Manage Website
PRIMARY BUSINESS
ACTOR:
Administrator
DESCRIPTION: Use case Manage Website is started when
the administrator is wants to view, add or delete content of website.
PRE-CONDITION:
There is website content.
TRIGGER: Use case Manage Website is started when
the administrator is wants to view, add or delete content of website.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1
: Administrator
will choose the data that want
deleted.
Step 3
: Administrator
will do some action.
Step 2: System will give a confirmation alert.
Step 4: System will save the changes.
ALTERNATE COURSES:
If user forgets to fill in some of the requirements information or give the
wrong value, system will display the error message.
CONCLUSION: This use case will be finished when there is
no data to be managed.
POST-CONDITION: Administrator will easily manage the data.
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS
The result will be displayed.
ASSUMPTIONS: Figure 4.8
Use-case narratives for manage website
4.2.2.4 Use Case Narrative for Manage User
USE CASE NAME: Manage User
PRIMARY BUSINESS
ACTOR:
Administrator
DESCRIPTION: Use case Manage User is started when the
administrator is wanted to edit, delete, and insert the user.
PRE-CONDITION: TRIGGER:
This use case is managing the user
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1
: Administrator
will choose user that
want to edited
and deleted,
also insert user.
Step 2
: Administrator
will do some action.
Step 2: System display the form or alert.
Step 4: System will save the changes that user
made.
ALTERNATE COURSES:
If user forgets to fill in some of the requirements information or give the wrong
value, system will display the error message.
CONCLUSION: This use case will be finished when there is
no data to be managed.
POST-CONDITION: Administrator will easily manage user.
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS
The result will be displayed.
ASSUMPTIONS: Figure 4.9
Use-case narratives for manage user
4.2.2.5 Use Case Narrative for Searching by Using Match Single Characters
USE CASE NAME: Searching
PRIMARY BUSINESS
ACTOR:
User
DESCRIPTION: Use case request searching is started when
the user started typing any character in colom.
PRE-CONDITION: Input data must be inserted first
TRIGGER:
Use case request searching is started when the user started typing any character in
colom.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1
: User
request for
searching.
Step 2: System will process and display the
request.
ALTERNATE COURSES:
CONCLUSION: This use case will be finished when user
finished.
POST-CONDITION: IMPLEMENTATION
CONTRAINTS AND SPECIFICATIONS
The result will be displayed.
ASSUMPTIONS: Figure 4.10
Use-case narratives for searching by using match single characters
4.2.2.6 Use Case Narrative for Translating USE CASE NAME:
Transla ting
PRIMARY BUSINESS
ACTOR:
User
DESCRIPTION: Use case Translating is started when the
user started translating result of searching.
PRE-CONDITION: Input data must be inserted first
TRIGGER:
Use case Translating is started when the user started translating result of searching.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1: the user started translating
result of
searching.
Step 2: System will display the result.
ALTERNATE COURSES:
CONCLUSION: This is use case will be finished when
system display the list of result
POST-CONDITION: IMPLEMENTATION
CONTRAINTS AND SPECIFICATIONS
The result will be displayed.
ASSUMPTIONS: Figure 4.11
Use-case narratives for translating
4.2.2.7 Use Case Narrative for Updating USE CASE NAME:
Updating
PRIMARY BUSINESS ACTOR:
User
DESCRIPTION:
Use case Updating is started when the user started click update menu button.
PRE-CONDITION:
Menu button must click first
TRIGGER: Use case Updating is started when the user
started click update menu button.
TYPICAL COURSE Actor
Action System Response
OF EVENTS: Step 1: the
user started click update
menu
button. Step 3: the
user close
application
Step 2: System will display the result.
Step 4: System read new database
ALTERNATE COURSES:
CONCLUSION:
This is use case will be finished when rewrite the database
POST-CONDITION: IMPLEMENTATION
CONTRAINTS AND
SPECIFICATIONS
The result will be displayed.
ASSUMPTIONS: Figure 4.12
Use-case narratives for updating
4.2.2.8 Use Case Narrative for Setting USE CASE NAME:
Setting
PRIMARY BUSINESS ACTOR:
User
DESCRIPTION:
Use case Setting is started when the user started click setting menu button.
PRE-CONDITION:
Menu button must click first
TRIGGER: Use case Setting is started when the user
started click update menu button.
TYPICAL COURSE Actor
Action System Response
OF EVENTS: Step 1: the
user started click
setting menu
button. Step 3: the
user setting application.
Step 2: System will display the layer.
Step 4: System read new setting.
ALTERNATE COURSES:
CONCLUSION:
This is use case will be finished when user click back button
POST-CONDITION: IMPLEMENTATION
CONTRAINTS AND SPECIFICATIONS
ASSUMPTIONS: Figure 4.13
Use-case narratives for setting
Administrator User
Administrator in this system is the person who develop application, operate website
and data modification. The one who
appointed by the Director. All of the users who use
the application
and website developer.
4.2.3 Describe Use Case Figure 4.14
Actor specification
In this phase writer give explanation for process which are mention on use-case narrative before.
4.2.3.1 Activity Diagram for Login
Figure 4.15 Activity Diagram for Login
Explanation :
Users of this system administrators and user started the activity log in by entering username and password on the login
box. Username and password are validated by the system. If the username and password are valid, then the system displays the
menu page and the user can access it. However, if the username
and password is invalid, then the system will ask user to type valid username and password.
4.2.3.2 Activity Diagram for Manage Database
Figure 4.16 Activity Diagram for Manage Database
Explanation :
Admin choose suggestion who already submitted to the website and do modification into the database.
4.2.3.3 Activity Diagram for Manage Website
Figure 4.17 Activity Diagram for Manage Website
Explanation
: Administrators manage content of the website by accessing
display main menu.
4.2.3.4 Activity Diagram for Manage User
Figure 4.18 Activity Diagram for Manage User
Explanation
: Administrators manage user position and activities.
4.2.3.5 Activity Diagram for Searching
Figure 4.19 Activity Diagram for Searching
Explanation :
The user type input in colom and user will searching in database and appear the result
4.2.3.6 Activity Diagram for Translating
Figure 4.20 Activity Diagram for Translating
Explanation :
User click the result which appeared in result and system will search the meaning in database, if that exist it will appear in result
layer.
4.2.3.7 Activity Diagram for Updating
Updating
Figure 4.21 Activity Diagram for
Explanation :
User click update button and the system will updating the software from website and software ask to reopen application
4.2.3.8 Activity Diagram for Setting
Figure 4.22 Activity Diagram for Setting
Explanation :
User click setting button and set new setting if that ok, system will set new setting into the application.
4.3.4 Functions Complexity Type
Function list describes the action specification for the user to understand the function more clearly. The following list
function will support the use case in several important functions of the proposed system:
Table 4.3 Function List
Functions Complexity
Type
1 Login
Username, password Simple
Update User Query database
Simple Read
2 Search
Searching character Medium
Read 3
Translate Get input meaning from database
medium Read
4 About
Display about application Simple
Read 5
User View Menu user
Simple Read
6 Suggestion
Input name Simple
Update 7
DatabaseHelper Installing database
Hard Read
8 DB
Declare database variable Simple
Read 9
Auto Link Link result
view into new searching
medium Read
10 Edit
Link into the database Simple
Read 11
Setting Font Size and total searching
medium Read
Set Auto Link medium
Read 12
Main Input colom
Simple Read
Result list Simple
Update 13
Splash Screen Install database
Hard Read
14 Update
Download database Medium
Read 16
Exit Close application
Simple Read
17 Register
Open register page Simple
Read 18
Forget Password Simple
Read
4.3.5 Interfaces
In this phase writer give explanation about interface process using sequence diagram.
4.3.5.1 Sequence Diagram for Login
Figure 4.23 Sequence Diagram for Login
Explanation of sequence diagrams for use case Log in can be explained as follows:
1. User and Administrator type username and password to the interfaces.
2. Form login initiating the parameter and call the send login to send the username and the password.
3. Con Login initiating to the Database dan call the method check validity to process the login.
4. If the validation is failed, the database will send the failed message to the Con Login.
5. Con Login will send a failed message to Form Login with method Send Messagefailed.
6. Con Login will send the success message to Form Login with method Send Message.
7. Form Login will send the success message to Administrator or user with method Show Message.
4.3.5.2 Sequence Diagram for Manage Database
Figure 4.24 Sequence Diagram for Manage Database
Explanation of sequence diagrams for use case Manage Database can be explained as follows:
1. administrator select database which will be update. 2. File will be process by the system.
3. System will send messages if database exist. 4. Administrator will see content of the database
5. Administrator can edit, insert, update n delete content of database.
6. System will process administrator request 7. After the input system will give announcement success
4.3.5.3 Sequence Diagram for Searching by Using Match Single Characters
Figure 4.25 Sequence Diagram for Searching by Using
Match Single Characters
Explanation of sequence diagrams for use case Searching can be explained as follows:
1. User input character to start searching 2. Every character typed by user will be searched by
system. 3. If none of character match it will send message failed
4. User will see message failed in application 5. If character exist system will give result in list
6. User will se the list in application 7. After user already done typing they can input the word
8. Word will send and search by system 9. If none of word match it will send message failed
10. User will see message failed in application 11. If word exist system will give result in list
12. User will se the list in application
Administrator Administrator
4.3.5.4 Sequence Diagram for Setting
Administrator
Figure 4.26 Sequence Diagram for Setting
Explanation of sequence diagrams for use case Setting can be explained as follows:
1. User click menu button on device. 2. Interface will display menu option.
3. User clickmenu button setting. 4. Interface will display setting menu.
5. User clicksetting to set up display application. 6. Click setting will send into system.
7. System will give result into the interface. 8. User can see new setting result.
Administrator Administrator
4.3.5.6 Sequence Diagram for Updating
Administrator
Figure 4.27 Sequence Diagram for Updating
Explanation of sequence diagrams for use case Updating can be explained as follows:
1. User click button update which is exist in user menu interface.
2. Interface will openurlconnection through the system. 3. System will check url and create a connection.
4. System will readdb into interface. 5. If database have problem it will appear messageerror.
6. If database work it will appear message reopen application.
4.3.5.7 Sequence Diagram for Suggestion
Figure 4.28 Sequence Diagram for Suggestion
Explanation of sequence diagrams for use case Suggestion can be explained as follows:
1. User clickmenu button on device 2. Interface will show menu option
3. User clickmenu edit 4. System receive request for edit from clickmenu
5. System open URL registration and type username and password
6. Website send typeusername and password into system 7. System check validation
8. If wrong it will send messagefailed 9. User will see messagefailed
10. If wrong it will send messagesucceed 11. User will see messagesucceed
12. User write suggestion through interface 13. Result suggestion will type into website
14. Suggestion send into system 15. System will check validation
16. If success system will send messagefailed into interface
17. User can see messagefailed 18. If success system will send messagesuccess into
interface 19. User can see messagesuccess
4.4 Architectural Design 4.4.1 Criteria
