Amharic Teaching Software DocumentGroup 5

Amharic Teaching Software
A Senior Project Documentation Submitted to Debre Berhan

University in Partial Fulfillment of the Requirement for the
Degree of Bachelor of Science in Computer Science
By Group five
NAME ID NO
1. Hailegebrial Tekletsadik 022/06

2. Ruth Mesfn 033/06
3. Atrsew Terfe DBU07003462UR
4. Meseret Yemataw 026/06
5. Sofanit Ketema 035/06
Supervised By: -Chalew Tesfaye
College of Computing, Department of Computer Science

Debre Berhan University, Debre Berhan, Ethiopia JUN,
2017
AMHARIC TEACHING SOFTWARE 2017
Approval letter
This is to certify that the project is original and has not submitted for partial fulfillment
of Bachelor of Science in computer science. Our project member name and Signature.
Name Signature
1. Hailegebrael Tekletsadik
2. Ruth Mesfin
3. Atrsew Terefe
4. Meseret Yemataw
5. Sofanit Ketema
College: - College of Computing
Department: - Computer science
Project title: -Amharic Teaching Software
I certify that this project satisfies all the requirements as a project for the degree of
Bachelor of Science.
Name of program coordinator Signature
------------------------------------- ----------------------
This is to certify that I have read this project and that in my opinion it is fully adequate, in
scope and quality, as a thesis for the degree of Bachelor of Science.
Name of advisor Signature
------------------------------------- ----------------------
Examining committee members signature Date
1. Examiner 1 ____________ ____________ __________
2. Examiner 2 ____________ ____________ __________
3. Examiner 3 ____________ ____________ ___________
I|Page
4. Examiner 4 ____________ ____________ ___________
5. Examiner 5 ____________ ____________ ___________
It is approved that this project has been written in compliance with the formatting rules laid
down by the college of the university
II |Page
Acknowledgement
First and for most we would like to express our special thanks to almighty God for helping
us through all our steps start and finish of our work in such beautiful manner.
Then the team would like to thank to the project advisor, Chalew Tesfaye. for the
valuable guidance and advice. He inspired us greatly to work in this project. His
willingness to motivate us contributed tremendously to the project. Besides, the team
would like to thank the authority of Debrebrhan University collage of computing for
providing us with a good environment and facilities to complete the project.
Also, we would like say thank you to our families for caring, helping and supporting in every
aspect and also the team would like to take this opportunity to thank to the department
computer since for offering this subject, developing this final year project. Without helps of
the particular persons that mentioned above, we would face many difficulties while doing
this project.
Last but not list our thanks for ourselves for doing such a merciless, attractive and
addressable efficient works we made by sharing our efforts to success in our work. We are
making this project not only for marks but also increase our knowledge.
III |Page
Table of Contents
Approval letter ......................................................................................................................................... I
Acknowledgement ................................................................................................................................. III
List of Figures ........................................................................................................................................ VII
VII
List of tables ......................................................................................................................................... I
Abbreviations ......................................................................................................................................... IX
CHAPTER
ONE ......................................................................................................................................... 1
1.1 Introduction ............................................................................................................................ 1
1.2 Background Information of the Organization ......................................................................... 1
Vision of
1.2.1 DBU .................................................................................................................. 1
1.2.2 Mission of DBU ................................................................................................................ 1
1.3 Background of the project ...................................................................................................... 2
1.4 Problem Description ............................................................................................................... 2
1.4.1 Statement of the Problem .............................................................................................. 2
1.4.2 Proposed solution ........................................................................................................... 3
1.5 Significance of the project ...................................................................................................... 3
1.6 Objective of the project .......................................................................................................... 4
1.6.1 General objective ............................................................................................................ 4
1.6.2 Specific objective ............................................................................................................ 4
1.7 Scope and Limitation of the project........................................................................................ 4
1.7.1 Scope ............................................................................................................................... 4
1.7.2 Limitation of the project ................................................................................................. 5
1.8 Feasibility study....................................................................................................................... 5
1.8.1 Economic Feasibility ........................................................................................................ 5
1.8.2 Technical Feasibility ........................................................................................................ 7
1.8.3 Operational Feasibility .................................................................................................... 7
1.8.4 Schedule Feasibility ......................................................................................................... 8
1.9 Methodology of the project .................................................................................................... 8
1.9.1 Methodology for data collection .................................................................................... 8
1.9.2 Methodology for system analysis and design ................................................................. 8
1.10 Management Issue .................................................................................................................. 9
1.10.1 Team configuration and management ........................................................................... 9
1.10.2 Communication plan ..................................................................................................... 10
IV | P a g e
1.10.3 Change management .................................................................................................... 10
1.11 Project schedule .................................................................................................................... 12
Chapter Two .......................................................................................................................................... 13
Existing System ..................................................................................................................................... 13
2.1 Introduction of The Existing System ..................................................................................... 13
2.2 Player of the existing system ................................................................................................ 13
2.3 Major activities of the existing system ................................................................................. 13
2.4 Form and other document of the existing system................................................................ 14
2.4.1 Method to teach Amharic ............................................................................................. 14
2.4.2 Amharic Based Dictionaries form used ......................................................................... 16
2.4.3 Other documents .......................................................................................................... 17
2.5 Proposed Solution for The New System ............................................................................... 20
2.6 Requirements of the Proposed System ................................................................................ 20
2.6.1 Functional requirement ................................................................................................ 20
2.6.2 Nonfunctional requirement .......................................................................................... 21
Chapter Three ....................................................................................................................................... 22
System Analysis ..................................................................................................................................... 22
3.1 System models ...................................................................................................................... 22
3.1.1 Scenarios ....................................................................................................................... 22
3.1.2 Use case model ............................................................................................................. 24
3.1.3 Use Case Description..................................................................................................... 25
3.1.4 Object model ................................................................................................................. 33
3.2 Dynamic model ..................................................................................................................... 36
3.2.1 Sequence Diagram ........................................................................................................ 36
3.2.2 Activity Diagram ............................................................................................................ 41
3.2.3 State Diagrams .............................................................................................................. 49
3.2.4 User interface (navigational paths and screen mock-ups) ........................................... 53
Chapter Four ......................................................................................................................................... 56
System
Design ....................................................................................................................................... 56
4.1 Introduction .......................................................................................................................... 56
4.1.1 Purpose of the system .................................................................................................. 56
4.1.2 Design goals .................................................................................................................. 56
4.2 Current software architecture .............................................................................................. 57
4.3 Proposed software architecture ........................................................................................... 57
V|Page
4.3.2 Overview ....................................................................................................................... 58
4.3.3 Subsystem decomposition ............................................................................................ 58
4.3.4 Hardware/software mapping ........................................................................................ 59
4.3.5 Persistent data management ........................................................................................ 60
4.3.6 Access control and security ........................................................................................... 62
4.4 Subsystem services ............................................................................................................... 64
4.5 Component Diagram ............................................................................................................. 64
4.6 Deployment Diagram ............................................................................................................ 65
CHAPTER
FIVE ....................................................................................................................................... 66
OBJECT
DESIGN ..................................................................................................................................... 66
5.1 Introduction .......................................................................................................................... 66
5.2 Object design trade of........................................................................................................... 66
5.3 Interface documentation guidelines ..................................................................................... 67
5.4 Package ................................................................................................................................. 68
CHAPTER
SIX.......................................................................................................................................... 70
IMPLEMENTATION AND
TESTING ......................................................................................................... 70
6.1 Introduction .......................................................................................................................... 70
6.2 Sample code of the system ................................................................................................... 70
6.3 Final testing of the system .................................................................................................... 74
6.4 Hardware software acquisition ............................................................................................. 74
6.4.1 Hardware........................................................................................................................... 74
6.4.2 Software ............................................................................................................................ 75
6.5 User manual preparation ...................................................................................................... 75
6.6 Training ................................................................................................................................. 75
6.7 Installation process ............................................................................................................... 75
6.8 Startup strategy .................................................................................................................... 77
CHAPTER
SEVEN.................................................................................................................................... 78
CONCLUSION AND
RECOMMENDATION .............................................................................................. 78
7.1 Conclusion ............................................................................................................................. 78
7.2 Recommendation .................................................................................................................. 78
7.3 Appendix ..................................................................................................................................... 80
References ............................................................................................................................................ 81
VI | P a g e
List of Figures
Figure 1Method to teach alphabet using different pictures in Soresa primary and kindergarten school
17
Figure 2 Reference Book To teach Amharic word from Atse Zereayakob primary school cage.........18
Figure 3The Method of teaching of Amharic alphabet in Atse Zereayakob primary school................18
Figure 4Picture from Soresa primary and kindergarten school............................................................ 19
Figure 5 Use case model..................................................................................................................... 24
Figure 6 Analysis level Class Diagram (Conceptual Modeling).......................................................... 35
Figure 7 Sequence Diagram for create account................................................................................... 36
Figure 8Sequence Diagram for Take lesson........................................................................................ 37
Figure 9 Sequence Diagram for currency convertor............................................................................ 38
Figure 10 Sequence Diagram for Dictionary....................................................................................... 39
Figure 11Sequence Diagram for quiz.................................................................................................. 40
Figure 12 Activity Diagram for Register............................................................................................. 41
Figure 13 Activity Diagram for use Dictionary................................................................................... 42
Figure 14 Activity Diagram for calendar convertor............................................................................. 43
Figure 15 Activity Diagram for currency convertor............................................................................ 44
Figure 16 Activity Diagram for play game.......................................................................................... 45
Figure 17Activity Diagram for help.................................................................................................... 46
Figure 18Activity Diagram for translation.......................................................................................... 47
Figure 19 Activity Diagram for Take lesson....................................................................................... 48
Figure 20 State Diagrams for Take lesson........................................................................................... 49
Figure 21 State Diagrams for quiz....................................................................................................... 50
Figure 22 State Diagrams for play game............................................................................................. 51
Figure 23State Diagrams for use Dictionary....................................................................................... 52
Figure 24 Homepage Interface............................................................................................................ 53
Figure 25 ATS Tool Interface............................................................................................................. 54
Figure 26 ATS interface Navigation paths.......................................................................................... 55
Figure 27 Subsystem decomposition................................................................................................... 59
Figure 28 Hardware/software mapping............................................................................................... 60
Figure 29 Database Design.................................................................................................................. 62
Figure 30 Subsystem services............................................................................................................. 64
Figure 31 Component Diagram........................................................................................................... 65
Figure 32 Deployment Diagram.......................................................................................................... 65
Figure 33 package diagram................................................................................................................. 69
VII | P a g e
List of tables
Table 1 cost of the project.....................................................................................................................6
Table 2 Team composition.................................................................................................................. 10
Table 3 Schedule................................................................................................................................. 12
Table 4 Amharic Alphabets................................................................................................................. 14
Table 5 Amharic Numerals................................................................................................................. 17
Table 6 Scenario of the existing system in the school......................................................................... 22
Table 7 Scenario of the existing system application............................................................................ 22
Table 8 Scenario of the existing system in the internet........................................................................ 23
Table 9 Use case description for Registration..................................................................................... 25
Table 10 Use case description for Login............................................................................................. 26
Table 11 Use case description for Take Lesson................................................................................... 26
Table 12 Use case description for Provide quiz................................................................................... 27
Table 13 Use case description for Translate CUS............................................................................... 28
Table 14 Use case description for Play Games.................................................................................... 28
Table 15 Use case description for View Help..................................................................................... 29
Table 16 Use case description for View Report.................................................................................. 30
Table 17 Use case description for Use Dictionary............................................................................... 30
Table 18 Use case description for Use Calendar................................................................................. 31
Table 19 Use case description for Use Calendar Converter................................................................. 31
Table 20 Use case description for Use Currency Convertor................................................................ 32
Table 21 Account data Dictionary....................................................................................................... 33
Table 22 Lesson Data Dictionary........................................................................................................ 33
Table 23 Quiz Data Dictionary............................................................................................................ 33
Table 24 Game Data Dictionary.......................................................................................................... 33
Table 25 Dictionary Data Dictionary.................................................................................................. 34
Table 26 Persistent data management/mapping................................................................................... 61
Table 27 Access control and security.................................................................................................. 62
Table 28 documentation guidelines..................................................................................................... 67
VIII | P a g e
Abbreviations
➢
ATS – Amharic Teaching Software
➢
CUS – Commonly Used Sentences
➢
EC – Ethiopian Calendar
➢
GC – Gregorian Calendar
➢
OOSAD – Object Oriented System Analysis and Design
➢
C# – C Sharp
➢
MS – Microsoft
➢
SRS – System Requirement Specification and Analysis
➢
BR – Business Rule
➢
UI – User Interface
➢
UC – Use Case
IX | P a g e
CHAPTER ONE
1.1 Introduction
In Ethiopia, more than 84 languages are spoken. This number (84) implies only the known
languages. The languages of Ethiopia are classified into four categories. These are Semitic,
Cushitic, Omotic and Nilo-Saharan. Through language learning we can connect with other people
and make sense of our experiences. Strong language skills are an asset that will promote a
lifetime of effective communication. As a parent, teacher, or other type of caregiver, you shape a
child’s language development to reflect the identity, values, and experiences of your family and
community. Amharic is one of the mostly spoken language in Ethiopia, it is spoken by most
people in Ethiopia, and Eritrea according 2008 national census of Ethiopia, and it is the 2nd most
spoken Semitic language (after Arabic) in the world. It is the official working language of
Ethiopia. Outside Ethiopia, Amharic is the language of around 2.7 million emigrant more than
18.7 million people speaks Amharic in Africa. We are interested to develop Amharic language
teaching software to make people understand the language easily. So, this Software Requirement
Specification document specifies the product which is Amharic Teaching Software. This Amharic
Teaching Software is a Desktop based application which is to be used to teach Amharic language
for the intended users of this application software.
1.2 Background Information of the Organization

Debre Birhan University, which is 10 years’ young university, established in the 630 years
young historical town- Debre Berhan – a town situated in Amhara Region, North Showa
zone, 130 km away from Addis Ababa in the north. The most powerful explanation of the
establishment of the University is the government`s commitment towards the expansion of
quality higher education as well as ensuring a reasonable distribution of higher education in
the country.
1.2.1 Vision of DBU

The vision of Debre Birhan University is to be the best university in Ethiopia by 2020.
1.2.2 Mission of DBU

➢ Producing efficient graduates by offering research assisted quality education
1|Page
➢ Undertaking a problem-solving research based on national need and

benefiting the community with the outcome.
➢ Offering government and community centered training, consultancy

service, transferring technology and undertaking innovation.
1.3 Background of the project

Amharic is one of the mostly spoken languages in Ethiopia. So being able to speak Amharic
will give a great advantage in Ethiopia, as it’s one of the most popular languages spoken in
the country and it is an official language in Ethiopia. Amharic has become media of
instruction in primary education and is taught as a common subject at all levels in the
Ethiopia. Even though Amharic is the most popular language in Ethiopia there is a few works
for development of language that is done in software area on desktop application in our
country. So, in order to optimize this problem, we prepare ourselves to develop this
application. Like most other Ethiopian languages, whether Semitic, Cushitic, or Omotic
Amharic is arguably one of the easiest languages in Africa, for it does not contain any
“
unpronounceable sounds or tones” as found in many western languages which use Latin
alphabets. Amharic is written with a geez alphabet called Fidel
1.4 Problem Description
1.4.1 Statement of the Problem

There is Amharic to English dictionary in the market but there is no Amharic language
teaching desktop application software available prior to this one in the current market.
Previously developed Amharic teaching materials such as books or dictionary have the
following drawbacks such as: -
➢
Book which means reading a book is not attractive with respect to desktop application.
➢
It may be difficult for Blind person to learn from previous materials because book is
written material with no sound and usually different application have no Amharic
sound pronunciation
➢
As an official language in Ethiopia most people where in difficult to understand it and
foreigners are obligating to pay for translator.
➢
They need more stationary material and human power
➢
The problems involved in present Amharic learning system is Manual based and some
application software that used as dictionary.
2|Page
1.4.2 Proposed solution
➢ The proposed system which means Amharic teaching software attractive with
respect to human psychology.
➢ This proposed system has ways of learning Amharic language through text,
picture, games and sounds.
➢ As an official language in Ethiopia most people where in easy to understand

this software and foreigners or children under age seven or other language speaker are
do not obligating to pay for translator only easy access this software use it.
➢ They need not more stationary material and human power for learning
Amharic language
➢ The Amharic learning system is computerized way.
1.5 Significance of the project

After successful implementation of the application, user learns Amharic language any time
anywhere, save money spent to train Amharic language, using a new Amharic language
desktop learning application. Foreigners in the country can easily communicate for their day
to day activities. They do not need to employ translator for simple task they do every time by
using this application translator tools. It will make it easy for any people who would like to
learn the language without teacher because it will be easy to access the application from
personal computer or laptop. The application also will guide user who use the application for
far learning of the language. As Amharic language is one of the languages most spoken in the
Ethiopia, there is few works for development of the language that done in software’s area.
Thus, this work may become one from few works that contribute for the development of
language in general the outcome of this project is that, any Ethiopian or foreigners can make
use of this desktop Amharic learning application to get the translation of words from Amharic
to English or from English to Amharic.
3|Page
1.6 Objective of the project

1.6.1 General objective
The general objective of the project is to develop a system for teaching Amharic language.
1.6.2 Specific objective
In order to achieve the general objective mentioned above the project will have the
following specific objective
➢ To perform requirement analysis.
➢ To find a solution to the existing problem.

➢ To design the architecture for the proposed system.
➢ To develop user friendly and interactive system.
➢ To test the developed system.
1.7 Scope and Limitation of the project
1.7.1 Scope
The Amharic Teaching Software is desktop-based application software with the purpose of
teaching Amharic language to users without the need to go to language schools or
employing private teacher.
➢ This software integrates user friendly and simple language lessons with
quizzes to evaluate the user’s status,
➢ English to Amharic dictionary aided with voice output,
➢ Commonly used sentences translation with translator

➢ Games aided with voice output
➢ And tools, which include calendar, translation between EC and GC and
Currency Exchange calculator.
Foreigners especially Tourists and children under age seven with the intention of learning
Amharic language will find this Amharic Teaching Software easier, fast and effective.
Users with no Amharic language can use the commonly used sentences Translator feature
of this software as a language mediator to make their day-to-day activity effective without
the need of human language mediator.
4|Page
1.7.2 Limitation of the project

➢ The proposed system doesn’t provide paragraph translation
1.8 Feasibility study

All projects are feasible given unlimited resources and infinite time. Unfortunately,
the development of computer-based system in many cases is more likely to be plagued
by scarcity of resources and delivery date.
The feasibility report of the project holds the advantages and flexibility of the project. This
is divided into four sections:
➢ Economic Feasibility
➢ Technical Feasibility
➢ Operational Feasibility
➢ Schedule Feasibility
1.8.1 Economic Feasibility

A key factor in choosing language learning software is most certainly the price tag. When
we calculate the cost of some software or hiring a tutor, the fact that costumer can go from a
very basic level of proficiency to fluent using language learning software for under $10. For
this case, more and more people are choosing home study via language learning software’s.
Thus, project seems economically feasible.
Benefit Analysis
Tangible benefits
➢ Reduce the cost
➢ Improvement of management control through the following ways
▪ The resource can be saved online.
▪ Can’t be removed/stolen like books or dictionary.
▪ Easy to keep safe and control.
➢ Increase flexibility
➢ Increase speed of learning activity
5|Page
Intangible benefits
➢ Improving resource utilization and control
➢ Competitive necessity(advantage)
➢ Increase the good will of learner
➢ Availability of new, better, or more information to the learner by providing

different videos, audios, games and the like.
Cost Analysis
Tangible cost
To save man power and time needs, hardware cost, operational cost
Cost of the project
The costs we need during the development of this project includes are shown on the
following table.
Table 1 cost of the project
Resource Price
Hardware development
➢
We use two PC: total cost about 21,754.29 birr
cost
Software development
➢
VS.net set up: costs about 8 birr to download from
cost internet.
➢
Some additional software’s: costs 15 birr to download
from internet.
Transportation cost for ➢ 200 birr for different transportation during analysis
analysis
Overhead cost ➢ 28 birr for phone call
➢ 180 birr for internet usage
Miscellaneous cost
➢
320.29 birr
Total 22305.29
6|Page
1.8.2 Technical Feasibility

The proposed system can be easily maintained, portable, available and reliable. It is also
support multiuser, data handling system and easy to install. Generally, the system is technical
feasible. As part of technology and system feasibility study we have investigated the
technological resources necessary for the project. Since we find them available, the project
qualifies in this factor. Thus, the project seems technically feasible.
To design and implement Amharic teaching application the following tools software’s
and hardware’s used:
Software
➢ MS word 2016: for documentation.
➢ Visual paradigm UML: for diagrams and chart.
➢ MS-Window Office Visio 2007: for diagrams and chart.
➢ MS Power point for presentation.
➢ C# with SQL studio for coding parts.
Hardware
➢ Disk Drivers: 8GB flash disk or CD-Drive for storing data.
➢ Flush: for transfer of data from one computer to another.
➢ Printer: for printing document.
➢ Two Laptops or Personal computer: for all works.
1.8.3 Operational Feasibility

The proposed system is operationally feasible because the system is operated on intended
system by the user of the system for providing effective processing system there by greatly
satisfies users need.
➢ The proposed system offers greater level of user-friendliness.

➢ The proposed system produces best results and gives high performance.
➢ The proposed system can be implemented easily.
7|Page
1.8.4 Schedule Feasibility

The schedule for this project will be feasible due to proper information exchange between the
developing team and the Advisor. And also, the time set to develop the application is enough
to complete at the predefined day and time since the project is supposed to be completed in 8
months i.e. 4 months for documentation and the rest 4 months for implementation and testing.
1.9 Methodology of the project

In order to accomplish the project, the Application requirement we will follow
methods, tools, and techniques as mentioned below.
1.9.1 Methodology for data collection

1. Primary method of data collection
➢ Interviewing
We will gather information formally through interview of different people,

students and other non-native Amharic language speakers Example Atse
Zereayakob primary school, Soresa primary and kindergarten school
➢ Observation
This method is also used to collect data, done by direct seeing the working
environment. Example Soresa primary and kindergarten school uses different
refreshing and teaching videos sometimes in Television, manual paper based such
as work sheet, books and different puzzle for teaching Amharic and English
language
2. Secondary method of data collection
➢ Published material such books, dictionary and others.
1.9.2 Methodology for system analysis and design
For this project, we will be using the Advance Analysis & Design Methods, like object
oriented system analysis and design (OOSAD) because of the following reasons. Used to
Model the functions of the system (use case modeling), Find and identify the business
objects, organize the objects and identify the relationship between them and finally model the
behavior of the objects and specifically it provides:
➢ Improved quality by providing the application on time, on budget and meet

user expectations.
8|Page
➢
Increased chance of project success since OOSAD is the best way to develop
systems quickly and inexpensively(Balegurusamy, pp. August 30, 2013).
➢
Managed complexity Expect the software we build today will need to be changed
tomorrow
Software tools
➢ For this project system development, we will be using (c sharp) for the front
end as means of communication between application and the user. This enables the
application to be friendly interactive and we use SQL as a back-end tool to define the
structure of the system for storing all the records because of the following reasons.
More storage engines, Better performance, advanced run time, Reliability, Easy to
adopt, Fast execution
1.10 Management Issue

Management issue is about the team members and the way in which we are going to use
our effort on the system and a plan how we go with time based on the schedule to
accomplish within the time we have.
1.10.1 Team configuration and management

The team members have its own responsibility for activities of this project work is
organized and grouped based on the rules of Debre Birhan university computer science
department on Amharic Teaching Software. We are five in number, namely: -
Hailegebrael T/Tsadik, Ruth Mesfin, Sofanit Ketema, Meseret Yemataw, Atrsew Terefe
did their own activities of system.
9|Page
Table 2 Team composition
Project Amharic Teaching Software(ATS)

Title
Prepared No Name Responsibility ID No

By
1 Hailegebrael T/Tsadik requirement analysis and 022/06
coding,
2 Ruth Mesfin Project manager 033/06
3 Sofanit Ketema requirement analysis, design 035/06

and coding
4 Meseret Yemataw requirement design, testing 026/06
5 Atrsew Terefe requirement analysis design and 3462/06

coding.
Date Jun 2017
Advisor Ins Chalew Tesfaye
1.10.2 Communication plan

As a team member, we communicate each other by discussing on the issues in general, for
example we design on paper before writing on the system. And sometimes we divide and do
a separate task to facilitate the project to proceed based on the schedule. And we regularly
contact our advisor (necessarily ones a week) to submit the progression of work and
irregularly to ask questions related to the project development, to get advice, information
and resources necessary to our system development.
1.10.3 Change management

Change management is an approach to transitioning individuals, teams to a desire future
state. And it is about how we group members are responsible for controlling change
10 | P a g e
processes within the project’s scope. As a group member, we have the following rules
and regulations for the performance of our project:
➢ Our group members have their own responsibility in all steps of the works to
rise and comment on each step.
➢ If we or our advisor found any updating part, we group members will

have discussion for any changes.
➢ We group members can rise any ideas daily for more improvement and
every members have an obligation to discuss and rise comments accordingly.
➢ Disclosing of a system to another person is forbidden.
➢ Any member has a right to express his idea freely.

➢ We should use our resources properly such as budget, software, and
another material.
Generally, our projects have its own rules and regulation in which all group members have to
accumulation accordingly to respond for any changes.
11 | P a g e
1.11 Project schedule

Table 3 Schedule
Starting from October 17/2017 up to June 15/2017 6
Schedule
activities October October December January February May

27/2017- 11/2017-
17/2017- 25/2017- 07/2017- 19/2017-
February May
October December January June
10/2017 18/2017
06/2017 26/2017
24/2017 02/2017
1 weak 6 weak 7 weak 2 weak 14 weak 2 weak
Project proposal
Requirement
analyses phase
System and object

design
Par (Rest) time
Implementation
Documentation and
project submission
12 | P a g e
Chapter Two
Existing System
2.1 Introduction of The Existing System

The current system uses manual based learning technics aided with different materials such
as books that have different lesson, dictionaries to translate words from English to
Amharic meaning, and use sculpture to teach Amharic, English alphabets and numbers and
other means of getting word translation is using different software dictionaries
2.2 Player of the existing system

school: teachers, students.
System: application software
Persons: foreigner, translator person
2.3 Major activities of the existing system

One means of getting translation of English to Amharic word is using the print versions of
Amharic dictionary. Using the printed version of the dictionary has been only means of getting
word translation, but now it is not convenient means especially in today's rashly world and due to
the above-mentioned drawbacks. The other means of getting word translation is using application
software. Application software dictionaries solve some of the drawbacks of the printed version
dictionaries. Despite the fact that application software dictionaries are better means of getting the
translation of the word than the printed version of dictionaries, most of the application software
Amharic dictionaries have the following draw backs
➢ Dictionary and other paper based resource translate from English to Amharic
with no sound pronunciation.
➢ Display the meaning of the word using text. Therefore, text based
meaning of the word is difficult to speak especially for non-Ethiopians or non-
Amharic speakers.
Even if the existing application software dictionaries have some drawbacks, it solves the
problem existed in the printed version of dictionaries. The application software dictionary is
13 | P a g e
convenient to many people since it is accessible any time anywhere, many people would like
to use application software dictionary for any learning and translating.
2.4 Form and other document of the existing system
2.4.1 Method to teach Amharic

They use the following type of symbol called fidel for teaching learning process in order
to teach Amharic alphabet.
Table 4 Amharic Alphabets
ሀ HA ሁ HU ሂ HI ሃ HA ሄ HE ህ H ሆ HO
ለ LE ሉ LU ሊ LI ላ LA ሌ LE ል L ሎ LO
ሐ HA ሑ HU ሒ HI ሓ HA ሔ HE ሕ H ሖ HO
መ ME ሙ MU ሚ MI ማ MA ሜ ME ም M ሞ MO
ሠ SE ሡ SU ሢ SI ሣ SA ሤ SE ሥ S ሦ SO
ረ RE ሩ RU ሪ RI ራ RA ሬ RE ር R ሮ RO
ሰ SE ሱ SU ሲ SI ሳ SA ሴ SE ስ S ሶ SO
ሸ SHE ሹ SHU ሺ SHI ሻ SHA ሼ SHE ሽ SH ሾ SHO
ቀ KE ቁ KU ቂ KI ቃ KA ቄ KE ቅ K ቆ KO
በ BE ቡ BU ቢ BI ባ BA ቤ BE ብ B ቦ BO
ተ TE ቱ TU ቲ TI ታ TA ቴ TE ት T ቶ TO
ቸ CHE ቹ ቺ CHI ቻ CHA ቼ CHE ች CH ቾ CHO

CHU
ኃ HA ኁ HU ኂ HI ኃ HA ኄ HE ኅ H ኆ HO
ነ NE ኑ NU ኒ NI ና NA ኔ NE ን N ኖ NO
14 | P a g e
ኘ GNE ኙ GNU ኚ GNI ኛ ኜ GNE ኝ GN ኞ GNO

GNA
አ A ኡ U ኢ I ኣ A ኤ E እ I ኦ O
ከ KE ኩ KU ኪ KI ካ KA ኬ KE ክ K ኮ KO
ኸ HA ኹ HU ኺ HI ኻ HA ኼ HE ኽ H ኾ HO
ወ WE ዉ WU ዊ WI ዋ WA ዌ WE ው W ዎ WO
ዐ A ዑ U ዒ I ዓ A ዔ E ዕ I ዖ O
ዘ ZE ዙ ZE ዚ ZI ዛ ZA ዜ ZE ዝ Z ዞ ZO
ዠ ZHE ዡ ZHU ዢ ZHI ዣ ZHA ዤ ZHE ዥ ZH ዦ ZHO
የ YE ዩ YU ዪ YI ያ YA ዬ YE ይ Y ዮ YO
ደ DE ዱ DU ዲ DI ዳ DA ዴ DE ድ D ዶ DO
ጀ JE ጁ JU ጂ JI ጃ JA ጄ JE ጅ J ጆ JO
ገ GE ጉ GU ጊ GI ጋ GA ጌ GE ግ G ጎ GO
ጠ TE ጡ TU ጢ TI ጣ TA ጤ TE ጥ T ጦ TO
ጨ CHE ጩ CHU ጪ CHI ጫ ጬ CHE ጭ CH ጮ CHO

CHA
ጰ PE ጱ PU ጲ PI ጳ PA ጴ PE ጵ P ጶ PO
ጸ TSE ጹ TSU ጺ TSI ጻ TSA ጼ TSE ጽ TS ጾ TSO
ፀ TSE ፁ TSU ፂ TSI ፃ TSA ፄ TSE ፅ TS ፆ TSO
ፈ FE ፉ FU ፊ FI ፋ FA ፌ FE ፍ F ፎ FO
ፐ PE ፑ PU ፒ PI ፓ PA ፔ PE ፕ P ፖ PO
15 | P a g e
The teachers teach simply the alphabet but they do not teach the meaning.it is difficult to
teach all Amharic alphabet for child and nonnative Amharic speaker. it takes long period of
time to give Amharic teaching. After understanding those alphabets, it is difficult to know the
meaning of the word and sentences.
2.4.2 Amharic Based Dictionaries form used

Most of Amharic based Dictionaries are doing the translation of English word to Amharic.
Their method of displaying the meaning of the word is different but almost all dictionaries
display the meaning using text.(Abebe, 2004)
Simple Amharic sentences that is in some dictionary
One may construct simple Amharic sentences by using a subject and a predicate Here are a few
simple sentences
Amharic =ኢትዮጵያ አፍሪቃ ውስጥ ናት

Amharic_English=ʾItyopp̣yạ ʾAfriqa wǝsṭ nat
English ='Ethiopia is in Africa.'
Amharic =ልጁ ተኝቷል

Amharic_English =Lǝǧu täññǝtʷall.
English ='The boy is asleep.'
Amharic= አየሩ ደስይላል

Amharic_English=Ayyäru däss yǝlall.
English ='The weather is pleasant.'
Amharic= እሱ ወደከተማ መጣ
Amharic_English=Essu wädä kätäma mäṭṭa.
English= 'He came to the city
.
Amharic=እንግሊዘኛመናገርትችላለህ?
Amharic_English=Englizena manager tchlaleh?
English =Do you speak English?
Numerals that is in the book is like as follow
16 | P a g e
These numerals developed from the Greek alphabet, possibly via Coptic(dr.Hadise, 2002).
Table 5 Amharic Numerals
፩ ፪ ፫ ፬ ፭ ፮ ፯ ፰ ፱
አንድ ሁለት ሶስት አራት አምስት ስድስት ሰባት ስምንት ዘጠኝ
And hulet Sost Aratt Ammest seddest Sebatt Semment Zatann
1 2 3 4 5 6 7 8 9
፲ ፳ ፴ ፵ ፶ ፷ ፸ ፹ ፺
አስር ሃያ ሰላሳ አርባ ሃምሳ ስልሳ ሰባ ሰማንያ ዘጠና
Asr Haya Selasa Arba Hamsa Selsa Seba Semanya Zetena
10 20 30 40 50 60 70 80 90
Method of teaching number is they use different material such as wood, artificial plastics etc. for
example
2.4.3 Other documents
Figure 1Method to teach alphabet using different pictures in Soresa primary and
kindergarten school
17 | P a g e
Learning Teaching Method
Figure 2 Reference Book To teach Amharic word from Atse Zereayakob primary school cage
Figure 3The Method of teaching of Amharic alphabet in Atse Zereayakob primary school
➢ Teacher nominate an alphabet and tell the pronunciation using sound and
students rehearse what the teacher said
➢ Color that is in some color print materials
18 | P a g e
ሮዝ≡Roz=pink/Violet
ሃምራዊ≡Hamrawee=Purple
ሰማያዊ≡Semayawee=Blue
አረንጓዴ≡Areanguade=Green
ቢጫ≡Beecha=Yellow
ብርቱካን≡Birtukan=Orange
ቀይ≡Qaey=Red
➢ Picture and Arts used to teach Amharic and English language
Figure 4Picture from Soresa primary and kindergarten school
19 | P a g e
2.5 Proposed Solution for The New System
➢ The proposed system which means Amharic teaching software attractive with
respect to human psychology.
➢ This proposed system has ways of learning Amharic language through audio,
picture, games and sounds.
➢ As an official language in Ethiopia most people where in easy to understand

this software and foreigners or children under age seven or other language speaker are
do not obligating to pay for translator only easy access this software.
➢ They need not more stationary material and human power for learning
Amharic language
➢ The Amharic learning system is computerized way.
2.6 Requirements of the Proposed System
2.6.1 Functional requirement
➢ ATS (Amharic Teaching Software) provides a voice aided translation service of

commonly used alphabets, phrases and sentences.
➢ ATS (Amharic Teaching Software) provides different recreational games that will
develop the skill of the user through attractive and playful games. Example: -click sound
icon from the left sidethen match the Appropriate to the right side
➢ Continuously assess the performance of the user by conducting quiz.
Any collection of data including audio and we use external device to listen sound like
headphone and speaker
➢ ATS (Amharic Teaching Software) provides EC to GC and GC to EC date conversion

service.
20 | P a g e
2.6.2 Nonfunctional requirement

In order to give satisfaction to the client is should do all the operations of existing system in
interactive and easy way with fast response time and maximum through put. Generally, the
following are some of non-functional requirements of the system
➢
Usability: -Since the system is easily accessed it is easily used everywhere in
which computer is available.
➢
Maintainability: -The Amharic Teaching Software should be easy to extend. The
code should be written in a way that it favors implementation of new functions. The
SRS and Design document also enhances the upgrading and maintenance process in
the future use.
➢
Efficiency: -The system can assume to run within two second. To achieve
efficiency this system, use SQL database, this is efficient in query and processing
➢
Operability: -Every operation of the system must be as simple as possible for the
people to use simply. This by providing simple user interface using easy language
so that users understand and operate the software easily
➢
Access permissions: -every user can access this software by own name without
password only for profile management
➢
Performance: - the Amharic Teaching Software can be accessed only by one user at
a time. Only 10 users can register to the application. If the number of users is already 10
a new user must delete a previous profile to register to the application.
➢
Reliability: -The information provided by the Amharic Teaching Software is accurate and
realistic. The lessons provided by the Amharic Teaching Software teach the exact and correct
language lessons to the user.
➢
Correctness: -The Amharic Teaching Software provides an accurate and correct response to
every user requests.
➢
Portability: -The Amharic Teaching Software is portable application software which can
operate on both windows 7, windows 8 and above operating system platforms, and can run
on any hardware platform of the specification described on the hardware requirements
section above.
21 | P a g e
Chapter Three
System Analysis
3.1 System models

3.1.1 Scenarios
Purpose: Scenario that describes how user take lesson by a representative student
Scenario:
Table 6 Scenario of the existing system in the school
Name Teach
Actor Teacher
Description Teacher teaches student on the class room
Trigger Having class /arranging class
1. Must have teacher in the class
Pre-Condition
2. Must have students in class
Post-Condition Teacher teach Student
1. Student present in the class
2. The teacher get in to the class
3. Teacher write on the board
Basic course of
4. Teacher read the text in the board
action
5. Student rehears that the teacher says
6. Time is gone
7. Class end
Table 7 Scenario of the existing system application
Name Dictionary
Actor User
Description Application used to refer words
Trigger Open the application
22 | P a g e
Pre-Condition User decide to use dictionary
Post-Condition Display the equivalent out put
1. User open the application
2. Insert words
Basic course of
3. Click search button
action
4. The system display equivalent meaning
5. Use case end
Table 8 Scenario of the existing system in the internet
Name Translation
Actor User
Description Used to translate sentence
1. Connect computer to the internet
Trigger
2. Open browser
Pre-Condition Write url on the browser google translate
Post-Condition Display the meaning of sentence or word
1. User b rows google translate on internet
2. User insert words or sentence on the text box
Basic course of
3. Select the language that you want to convert
action
4. Server display the meaning
5. End use case
23 | P a g e
3.1.2 Use case model

o
uc Use Case
Use case Diagram
Create Account
Take Lesson
Game
«extend»
User
Take Quiz
Translation
View Report
Calendar
View Help
Conv erter
Use Dictionary
Figure 5 Use case model
24 | P a g e
3.1.3 Use Case Description

Table 9 Use case description for Registration
Use Case Name Create account
Use Case ID UC-1
Actor User
Use Case Description Allow the user to create their own account for status management
Trigger The user press the Create account button
Pre-Condition 1. The User decide to create account
Post-Condition 1. Account created successfully for the User.
1. The User click “Create Account” menu

2. The System Display “Create Account” form
3. The user fills “Create Account” form
4. The user click “Create Account” button
Basic course of
5. The system Validate the data (A5: if data is invalid)
action
6. The System Create user account form the user (A6: if User
name already exist)
7. The system display the main page
8. End use case.
A5: If user entered invalid data
1. The system highlights the invalid field(s)
Alternative course 2. The system resume to step 3
of action A6: If the username already exists
1. The System display “Username already exist” message

2. The system resume to step 3
25 | P a g e
Table 10 Use case description for Login
Use Case Name Login

Use Case ID UC-2
Actor User
Use Case Description Used to know the status and to save the activity where is
Trigger The user press login button
Pre-Condition 1. The user must have user account
Post-Condition The application main menu is displayed
1. The user inputs/select his/her user name into the application.
2. The ATS verifies the user is eligible to login into the
Basic course of action Application. (A2: if logged in failed)
3. The system display main menu
4. End use case.
A2) if logged in failed

Alternative course of
1. The system display “Login failed” message
action
2. The system resume to step 1
Table 11 Use case description for Take Lesson
Use Case Name Take Lesson

Use Case ID UC-3
Actor User
The “Take Lesson” use case enable the user to learn (take different
Use Case Description
lesson) based on his/her level
Trigger The user click the take lesson button from the home screen
Pre-Condition 1. The user decides to take lesson
Post-Condition The user took different lesson
1. The user clicks the “Take a lesson” icon from the home screen.
Basic course of 2. The ATS display a lesson for the user
action 3. The user selects the lesson
4. The user take the lesson
26 | P a g e
5. The system follows up the lesson (A5: if the user successfully
finish the lesson)
6. The user finish learning/taking a lesson
7. End use case.
A5: if the user successfully finish the lesson
1. The system display “Do you want to take Quiz, Previous or
Repeat or” message
2. If the user respond “Repeat”
Alternative course 2.1. The system resume to step 2
of action 3. If the user respond “take Quiz”
3.1. Use case end
3.2. The system extends to “Take Quiz” use case
A5.2: if the user respond “No”
1. The use case end.
Extends “Take Quiz” use case
Table 12 Use case description for Provide quiz
Use Case Name Take Quiz

Use Case ID UC-4
Actor User
Use Case Description Test user status
Trigger The user click take quiz button at the end of each lesson
Pre-Condition The user decides to take quiz
Post-Condition The system display quiz
1. At the end of every chapter the ATS loads chapter quiz.
2. The user take quiz
Basic course of 3. The system checks if the user pass
action 4. The user will proceed to the next lesson chapter.
5. End use case.
Alternative course of action
27 | P a g e
Table 13 Use case description for Translate CUS
Use Case Name Use Translation CUS

Use Case ID UC-5
Actor User
Translate different commonly used sentence such as simple greeting,
asking question, asking for direction, ordering etc..
Trigger User click use translation button from the home screen
Pre-Condition The user decides to translate sentence
System display different list of Commonly Used Sentences that use in
Post-Condition
greeting
1. The user clicks the Translate icon from the home screen.
2. The ATS display the Translate screen.
3. The user selects the Translation category.
Basic course of
4. The ATS display list of CUS of the selected category.
action
5. The user select that you want to translate.
6. The ATS provide output of the selected sentence.
7. End use case.
Alternative course of
action
Table 14 Use case description for Play Games
Use Case Name Play Games
Use Case ID UC-6
Actor User
Use Case Description Have different recreational game to play
Trigger User click play game button from the home screen
Pre-Condition User decide to play game
Post-Condition Game play
28 | P a g e
1. The user clicks “Game” icon from the home screen.

2. The ATS load the Game screen.
Basic course of
3. The user clicks a game from the list of games on the Game screen.
action
4. The user plays the game.
5. End use case.
Alternative
course of action
Table 15 Use case description for View Help
Use Case View Help

UC ID UC-7
Actor User
System display animation that how to use this system software from the
begin to the internal part of the system
Trigger User click help button from the screen
Pre-Condition User need help
Post-Condition System display help
8. The user will click the “Help” icon on the home screen.
9. The ATS will load the help screen containing “User Guide” and
Basic course of
10. The user clicks “User Guide” icon.
action
11. The ATS will help tool.
12. End use case.
Alternative course
of action
29 | P a g e
Table 16 Use case description for View Report
Use Case Name View Report
Use Case ID UC-8
Actor User
Use Case Description To display the status of user/learner that result from the assessment
Trigger User click report button from home screen
Pre-Condition The user want to know the status
Post-Condition System display report
1. The user clicks the “Report” icon from the home screen.
Basic course of
2. The ATS display the report.
action
3. End use case.
Alternative course
of action
Table 17 Use case description for Use Dictionary
Use Case Name Use Dictionary

Use Case ID UC-9
Actor User
Use Case Description That Used to refer words
Trigger User click use dictionary from tool screen
Pre-Condition User inter word that you want to search
Post-Condition System display the meaning of searched word if present
1. The user clicks “Dictionary” icon from the Tools Screen.
2. The ATS will load the Dictionary screen.
Basic course of 3. The user will input an English word in the text box and clicks the
action Search icon (A3: if not found).
4. The ATS will provide an output of the inserted word
5. End use case
30 | P a g e
A3) A3: if not found

Alternative
1. Display the message “Sorry, No Match Found” text
course of action
2. Go to step 3
Table 18 Use case description for Use Calendar
Use Case Use Calendar
UC ID UC-10
Actor User
Use Case Description Used to show the calendar
Trigger User click use calendar from tool screen
Pre-Condition User decide to know the calendar
Post-Condition System display the calendar
1. The user will click the “Calendar” icon from the Tools screen.
2. The ATS will load the calendar screen containing.
Basic course of
3. The user will click the “next” and “previous” buttons to navigate to
action
the date he/she desires.
4. End use case.
Alternative course
of action
Table 19 Use case description for Use Calendar Converter
Use Case Name Use Calendar Convertor
Use Case ID UC-11
Actor User
Use Case Description Used to convert calendar
Trigger User click calendar converter button
Pre-Condition 1. User inter date that you want to convert
31 | P a g e
Post-Condition System display the output
Basic course of 1. The user will click the “Tools” icon from the home screen.
action 2. The user will click the “Calendar Convertor” icon from the Tools
screen.
3. The ATS will load the Calendar Convertor screen.
4. The user will input the calendar text box.
5. The user will select where to Convert (A5: if invalid input)
6. The ATS will display the corresponding calendar
7. End use case.

Alternative course of A5: if invalid input
action 1. Display the message “please inter the correct format/valid input”
2. The system resumes to step 4
Table 20 Use case description for Use Currency Convertor
Use Case Name Use Currency Convertor

Use Case ID UC-12
Actor User
Use Case Description Used to convert birr from one to other
Trigger User click currency converter button from tool screen
Pre-Condition 1. User insert birr that you want to convert
2. Select the conversion that birr being convert to
Post-Condition System display the converted value of birr
Basic course 1. The user will click the “Currency Convertor” icon from the Tools screen.
action 2. The ATS will load the Currency Convertor screen.

3. The user will input the amount of money (A5: if invalid input)
4. The ATS will display the converted output.
5.End use case.
Alternative of action A5: if invalid input

1. Display the message “please inter the correct format/valid input”
2. The system resumes to step 3
32 | P a g e
3.1.4 Object model

3.1.4.1 Data Dictionary
Table 21 Account data Dictionary
Field Name Data type Description

Holds User name that user used
User Name String
for status management
Table 22 Lesson Data Dictionary

Holds used to select level of
Lesson_Level String
lesson
Hold type of lesson that user
Lesson_type String
take
Describe the lesson uniquely
Lesson_id String
identified
Describe the sound when user
Item_sound Wav
take lesson
Table 23 Quiz Data Dictionary

Quiz_ Level String Describe level of quiz
Describe type of quiz that user
Quiz _type String
take
Used to Describe quiz
Quiz _id String
uniquely identified
Item_ sound
Table 24 Game Data Dictionary

Game_ Level String Describe level of game
Describe type of game that user
Game _type String
take
33 | P a g e
Describe the sound when user
Game _sound Wav
play
Used to Describe game
Game _id String
uniquely identified
Table 25 Dictionary Data Dictionary

Hold the word id to uniquely
Word _id String
identified
Used to Describe
Amharic_ word String Amharic_word meaning of
English_word
Describe the meaning of word
Sound Wav
in sound
Used to Describe
English_word String
English_word used to search
34 | P a g e
3.1.4.2 Analysis level Class Diagram (Conceptual Modeling)
class Class Diagram
Lesson Dictionary
- Lesson level: String - Phrase:: int

- Lesson name: String - Word:: String
+ Have(): int
have
have
Qiuz
Game
- Answer: boolean
- Game id: int - lessonlevel: string
- Game level: int - Qustion level: int
- Game name: int
+ Have(): int
+ Have(): int
Figure 6 Analysis level Class Diagram (Conceptual Modeling)
35 | P a g e
3.2 Dynamic model

3.2.1 Sequence Diagram
sd Register
User
Register Register<<controller>> Registration ATS <<DB>>
Form
<<UI>>
1:Press Button()
1.1Create
()
1.2Display()
2: Fill the registration form()
3:Click Create button()
3.1:Validate()
Save()
Return()
3.2 Acknowledgment ()
End
End End End End
Figure 7 Sequence Diagram for create account
36 | P a g e
sd Take Lesson
User
ATS Lesson <<UI>> Lesson << ATS<<DB>>
controller>>
1: click take lesson icon()
Request
()
Display()
2:User select lesson()
2.1:verify the user level()
Request()
Return()
2.2Replay()
2.2.1 Take Lesson()
End
End End End
End
Figure 8Sequence Diagram for Take lesson
37 | P a g e
sd Currency Conv erter
User
ATS ATS <<Controller>> Currenncy<<UI>>
1: click currency converter icon()
Request()
1.1:Display Currency Converte User Interface()
2:User Input Amount Of Money()
2.1:Validate()
2.2If invalid Display"incorrect value"()
2.3:Display the Converted Money()
End End
End End
Figure 9 Sequence Diagram for currency convertor
38 | P a g e
sd Dictionary
User
ATS Dictionary <<UI>> Dictionary ATS DB
<<Controller>>
1: Click Dictionary Icon From Tools()
Request()
1.1 Display()
2:User input word()
3:Click Search()
3.1:Check()
3.2:Check validity()
3.2.1:If Not Valid Display "enter valid word"()
3.2.2If
Valid()
3.4:Check For Similarty()
3.4.1 Return Result()
3.2.2.1:If Not Exist Display "Sorry No Match Found"()
3.4.2:display the meanig of the word()
End
End End End End
Figure 10 Sequence Diagram for Dictionary
39 | P a g e
sd Quiz
User
ATS Quiz<<UI>> Quiz<<Controller>> ATS DB
1: ClickTake Quiz Icon()
Request()
Display()
2:User Select Quiz Level()
2.1:Check User Can Take Quiz()
2.2:Validat()
2.3:If Not Display you Can't take this Quiz()
I True Continue()
f
3.3:Return()
3.5:Take Quiz()
End End End End End
Figure 11Sequence Diagram for quiz
40 | P a g e
3.2.2 Activity Diagram
act Create Account
Start
Click Create Button
Fill Information
Not fill correct
Click Ok
Success Message
Filled correctly
Figure 12 Activity Diagram for Register
41 | P a g e
act Use Dictionary
Start
Insert Word
Click search
Display"sorry no much Display meaning

w ord" If not Present If Present
End
Figure 13 Activity Diagram for use Dictionary
42 | P a g e
act Calender conv erter
Start
Click Tool Icon
Click calender
Click calender Conv erter
If Invalid Date Format Insert Date/Month/Year
Select where to conv ert
ATS Displays the

if valid
conv erted Value
End
Figure 14 Activity Diagram for calendar convertor
43 | P a g e
act Currency Conv ertor
Start
Click Tool icon
Click Currency Conv ertor

icon
ATS displays the

conv ertor
Select Where To Conv ert

If Invalid Currency Insert the amount of
money
Click Conv ert Button
ATS displays the

If Valid Currency conv erted currency
End
Figure 15 Activity Diagram for currency convertor
44 | P a g e
act Games
Start
Click Game icon
Choose game type and

Click Button
ATS Display Games
End
Figure 16 Activity Diagram for play game
45 | P a g e
act Help
Start
Click help icon from

screen
ATS display user guide
End
Figure 17Activity Diagram for help
46 | P a g e
act Translation
Start
Click Translate icon
Select commonly used

setence
click translate button
ATA diplay an out put
End
Figure 18Activity Diagram for translation
47 | P a g e
act lesson
Start
Click Take Lesson Icon

from home page
Choose lesson type
click on lesson
ATS Display Lessons
End
Figure 19 Activity Diagram for Take lesson
48 | P a g e
3.2.3 State Diagrams

UML state chart diagrams depict the various states that an object may be in the transition
between those states. In other word, it has initial and final states in addition to transition that
is a progression from one state to another. States are represented as a rounded rectangle with
the name of the state shown in the system. Connecting states together are transitions. These
represent the events that cause the object to change from one state to another. The guard
clause of the label is again mutually exclusive and must resolve itself to be either true or
false. Actions represent tasks that run causing the transitions State chart diagrams show class
states and the events that cause them to transition between states.
stm Take lesson
Home Page Display Lesson page [Take Lesson]

[Idle State] [Activate State] [Select Lesson button]
Initial
EntryPoint
[After Take Lesson]
Lunch Quiz
Take Quiz
Take Next Lesson
ExitPoint
Final
Figure 20 State Diagrams for Take lesson
49 | P a g e
stm Quiz
[Idle State] [Activate State] Display Lesson [Taking Lesson] ATS Provide Quiz
page
Initial EntryPoint
[Take Lesson Again] [Take Quiz]
[Pass]
Take Next Lesson
ExitPoint
Final
Figure 21 State Diagrams for quiz
50 | P a g e
stm Game
Idel Display List Game running

[Click Game icon] of Game [Select
Game ]
Ini ti al
EntryPoi nt
[User Play]
Display won Gift
Animation
ATS Save Score

[If Won]
[Compare Score]
[If fail/timeout]
Display Game
Over/Fail
Exi tPoi nt
Fi nal
Figure 22 State Diagrams for play game
51 | P a g e
stm Use Dictionary
Tools
[Idle] [Activate State] Main Form [Display] Dictionary
Initial EntryPoint
[wait user]
Enter word
[Searching]
[found] [Not found]
Display Output Display "Not found"
ExitPoint
Final
Figure 23State Diagrams for use Dictionary
52 | P a g e
3.2.4 User interface (navigational paths and screen mock-ups)

Interface designs: There are various types of user-computer interface designs, each of
which has a typical character and ability. The design type is required to be suitable to the
system’s duties and to its users who will interact directly with the system. The design and
documentation of the user interfaces are as follows.
Figure 24 Homepage Interface

➢
Main content area action buttons description
✓ Lesson – will load the lesson screen.

✓ Translation – will load the translation screen.
✓ Game – will load the game screen.
✓ View Report – will load the view report screen.
✓ Tools – will load the tools screen.
✓ Help – will load the help screen.
✓ Exit – will load the login screen.
53 | P a g e
Figure 25 ATS Tool Interface
➢ Main content area action buttons description
✓ Back – loads the home Screen.

✓ Dictionary – loads the Dictionary screen.
✓ Calendar – loads the Calendar screen.
✓ Calendar Convertor – loads the Calendar Convertor screen.
✓ Currency Convertor – loads the Currency Convertor screen.
54 | P a g e
Hierarchical Structure
LOGIN
VIEWHELP
USE
TAKE USE PLAY
USE TOOL TRANSLATIO TAKE QUIZ
LESSON DICTIONARY GAME
N
USE
USE USE
CALEND
A
DICTIONARY CONVERTOR
R
CALENDA
CURRENCCY
CONVERTOR
CONVERTOR
Figure 26 ATS interface Navigation paths
55 | P a g e
Chapter Four
System Design
4.1 Introduction
This chapter discuss all about the system design for the programming language, the purpose
of the programming language, architecture of the system, overview, subsystem
decomposition, the security mechanisms, deployment and component diagram. System
design is the process of defining the architecture, component, module, interface, and data for
the system to satisfy specified requirements.
4.1.1 Purpose of the system

The purpose of our project is that to teach Amharic language for nonnative Amharic language
speaker and children who speak Amharic language in order to communicate with people who
speak Amharic language to perform different task for example foreigner or other language
speaker come to Amhara region for job he/she must know Amharic language effectively for
doing something, for asking, for getting help, for ordering different things and so on
4.1.2 Design goals

Design goals describe the qualities of the system that developers should optimize. Such goals
normally derived from the non-functional requirements of the system. Which stated in
chapter two of this document. They describe the qualities of the system. These goals consider
the following criteria’s. These are
➢ Performance criteria
➢ Safety criteria
➢ End user criteria
4.1.2.1 Performance criteria
The part of the system to use for the programming language should have a fast response time
(real time) with maximum throughput. Furthermore, the system should not be taking up too much
space in memory. The user get fast response time over throughput and hence the system should
try to be more interactive. The system should be more reliable in order to satisfy
56 | P a g e
the constraints than fast response time. As generalized the team member Measure the
Performance of system in the following Main Concepts.
RESPONSE TIME: quickly reacts to a user. Response request to the user with in Two
seconds.
THROUGHPUT: system can accomplish high amount of outputs within a specified

amount time.
AVAILABILITY: The system or component is always operational and accessible
when required for use.
ACCURACY: display accurate output
4.1.2.2 Safety Criteria

Information transmission is securely transmitted between the system and file system and
there are no any changes in information
4.1.2.3 End User Criteria

Usability: Usability is the extent to which a product can used by specified users to achieve
specified goals with effectiveness, efficiency and satisfaction in a specified context of use.
From the end users’ perspective, the system should be designed in such a way that it is easy
to learn and use, efficient and having few errors if any.
4.2 Current software architecture

The current software architecture is Two Tier Typically, when you are browsing the
Internet, you will be using Web Browser software such as Internet Explorer or Mozilla
Firefox. The computer which is running a browser is called a client, whilst the
machine which is providing Web pages is called a server.
4.3 Proposed software architecture

We use a one-tier architecture keeps all of the elements of an application, including the
interface, middleware and back-end data, in one place. UI (User Interface), BL (Business
Layer), and DB (Database Layer)(Hoffer, 2000). This is a single tier application that runs in a
single system driven by a single user. Since our desktop application has no any external
designated software to install, it does not have any direct software interfaces. The database is
managed by the File database and SQLite software library so when we use SQLite since
57 | P a g e
SQLite is a software library that implements a self-contained, server less, zero-
configuration, transactional SQL base engine.
Use Embedded means there is no need other software for integration purpose and since the
embedded system, the hardware and software often collaborate to deal with various input
signals from the outside and output the processing results through some form. The input
signal may be an ergonomic device (such as a keyboard, mouse, or touch screen) or the
output of a sensor circuit in another embedded system. The output may be in the form of
sound, another analog signal, or a record or file for a database.
4.3.2 Overview
Our proposed software architecture is a single tier application that runs in a single
system driven by a single user. Since our desktop application has no any external
designated software to install, it does not have any direct software interfaces
4.3.3 Subsystem decomposition

A subsystem is a collection of classes, operations, events and constraints that are interrelated
to provide a set of services to a system. These grouping of model elements that represent a
behavioral unit in a physical system(valacita, 2000). We used subsystem decomposition
diagrams to express how our system decomposed to smaller parts or set of related
operations that share a common purpose. Subsystem decomposition results into a set of
loosely dependent parts that make up of the system. In short, this is the process of adjusting
the subsystems and showing the relationship of theses subsystems with each other. The
subsystems of our application are the following: -
1. Tools: -This subsystem enable the user to use different type of tools such as currency
convertor, calendar converter that covert from one value to equivalent value.
2. Lesson: - this subsystem enable the user to take lesson based on the level of user
3. Game: - this sub system enable the user to play different recreational games for funs
as well as for performance up grading
4. Quiz: - this sub system enable the user to take quiz that test how student understand
the lesson and save the grade that student gain and display grades
5. Dictionary: this subsystem enable the user to know the meaning of word by inserting
the word and click search then ATS display the equivalent meaning
58 | P a g e
cmp Subsystem Decomposition
ATS
User Interface
Game
Lesson
Save Score
Take Lesson
Play Game
Tools
Quiz Convert Currency

Dictionary
Save Grade
Search word Convert Calandar
Display Grade Display Result Display Calendar
Figure 27 Subsystem decomposition
4.3.4 Hardware/software mapping

Define the how the software mapped to computer. Since the application is
desktop application
59 | P a g e
cmp hardware software mapping
«device»
Computer
ATS
<<ExcutionEnv iroment>>
window
OperatingSystem
Figure 28 Hardware/software mapping
4.3.5 Persistent data management

4.3.5.2 Mapping
In order to store information persistently we map objects into tables and the attributes
into fields to the specific table based on the objects found on the system. Therefore, we
identified the major tables that will be implemented on the selected DBMS. For this
reason, the mapping of objects to tables is shown as follows in Table (26) Here the following
are entities of our system
➢ Lesson
➢ Quiz
➢ Games
➢ Dictionary
➢ User
The relation is how they interact with each other.
60 | P a g e
Table 26 Persistent data management/mapping
No Entity name Attributes Data type Primary key Foreign key

Lesson_level Varchar (30)
Lesson_type Varchar (20)
1 Lesson Lesson_level
User_ID Int Quiz_Level
Quiz_Level Varchar (30)
Quiz_level Varchar (30)
Quiz_type Varchar (30)
2 Quiz Quiz_level Lesson_level
Lesson_level Varchar (30)
User_ID Int
3 User User_ID Int User_ID
Game_ID Int
Game_name Varchar (20)
4 Game
Game_type Varchar (20)
User_ID Int
Dic _id Int
English _word varchar (30)
6 Dictionary Dic _id User _id
Amharic _word varchar (30)
User _id Int
User _id Int
User _id
7 Take lesson Lesson _level varchar (30)
Lesson _level
Performance varchar (30)
Quiz _level varchar (30)
User _id Int
Quiz _level
8 Take quiz Pass varchar (30)
User _id
Fail varchar (30)
Score Int
Game _id Int
User _id Int
Game _id
8 Play game Pass varchar (30)
User _id
Fail varchar (30)
Score Int
61 | P a g e
4.3.5.3 Database Design

Although we use file database system the design is based on the diagram shown below
Figure 29 Database Design
4.3.6 Access control and security

Here we will describe the privileges or authorities of actors over the functionalities. The
privileges to gain access of the system for the actor who can directly interact with Amharic
Teaching Software can see as below.
Table 27 Access control and security
Activity’s User
Take lesson ✓
Take quiz ✓
62 | P a g e
Play game ✓
Use dictionary ✓
Use translator ✓
Use converter ✓
Get help ✓
View report ✓
Create account ✓
63 | P a g e
4.4 Subsystem services

cmp Subsystem Serv ices
Have different Lesson This display different

based on lesson type games for the user to
the user to take lesson play
Lesson Save the score
Take Lesson
Game
Manage the user

performance Sav e Score
Save Grade, Display
Grade
Quiz Play Game
Sav e Grade
Convert EC Date To GC
date ,US dollar to EH birr
Display Grade and Used translate
different phrase
Tools
Conv ert Currency
Conv ert Calandar
Display Calendar
Figure 30 Subsystem services
4.5 Component Diagram

In the unified modeling language, a component diagram depicts how components are wired
together to form large components or software systems(Ambler, 2004). They are used to
illustrate the structure of arbitrarily complex systems.
Show how the physical components of a system are organized. And also, shows which
component or objects will be accessed by whom and what type of security infrastructures it
is using. The diagram is simulated as follows.
64 | P a g e
cmp Component diagram
Dictionary
«use»
Lesson
User
«use»
«use»
Game FILE DATABASE
«use»
«use»
Quiz
«use»
Conv ertor
Translator
Figure 31 Component Diagram
4.6 Deployment Diagram

It describes the physical architecture of the hardware and software in the system(Pirsig,
1999). They depict the software components, processors, and devices that make up the
system’s architecture. A Deployment modeling depicts a static view of the run-time
configuration of processing nodes and components that run on those nodes. And it shows: -
i. The hard ware for the system
ii. The software that is installed on the hardware
iii. Depict the hardware/network infrastructure of an organization.
iv. Depict a major deployment configuration of a business application
deployment Deployment Diagram
«device»
Personal Computer
ATS.exe
Figure 32 Deployment Diagram
65 | P a g e
CHAPTER FIVE
OBJECT DESIGN
5.1 Introduction
It describes object design trade-offs made by developers, guidelines they followed for
subsystem interfaces, the decomposition of subsystems into packages and classes, and the
class interfaces. The ODD is used to exchange interface information among teams and as
a reference during testing.
5.2 Object design trade of

➢ Throughput vs. Latency:
Our project uses event based-control flow i.e. Each control response one at a
time. This increases the throughput but checking overhead slows down.
➢ Memory space vs. Response time:
Since our project, ATS system focuses on providing fastest response service to
user for every control, response time is the most important factor and so more
memory can be expended to speed up the software
➢ Functionality vs. Usability:
Our software incorporates functionalities which meets the requirement

specification. With SQL as database component, and c# as front-end the
usability of the ATS system is fully achieved.
➢ Efficiency vs. Portability
The system is efficiently designed by which porting from one environment to

another is made easy. With c# and flat file tools, portability is much easier to
support in various environment.
➢ Rapid development vs. Functionality
Traditionally the rapid application development (RAD) approach involves

compromises in usability, features, and/or execution speed. Our system is
designed to meet the functional specification with rapid application
development approach.
➢ Cost vs. Reusability
66 | P a g e
Our software interfaces & components can be reused within the system to
implement the functionality for other modules, the software is designed using
c# & SQL for data access which is quite cheap compare to other data access
tools.
5.3 Interface documentation guidelines

This section will give an insight about the Naming Convention to make the program more
understandable by making them easier to read
➢ Classes are named with singular nouns.
➢ Methods are named with verb phrases, fields, and parameters with noun phrases.
➢ Error status is returned via an exception, not a return value.
Table 28 documentation guidelines
Identifier Rules for Naming Examples

Type
The prefix of a unique package name is
always written in capital and all lowercase
ASCII letters except abbreviations like UI
is User Interface so as not to make lengthy
Packages package ATSUI;
package name. We’ve not used any top-
level domain names, currently com, edu,
gov, mil, net, org, or one of the English
two-letter codes identifying countries as
specified in ISO Standard 3166, 1981.
Class names should be nouns, in mixed class ATSDB;
case with the first letter of each internal class Quize;
word capitalized. We kept our class names
simple and descriptive. Nonetheless, we
Classes
used whole words and avoided acronyms
and abbreviations as far as possible (unless
the abbreviation is much more widely used
67 | P a g e
than the long form, such as DB for
database and UI for User Interface). Some
classes’ names also have numeral as it
makes us to feel the step of execution.
Interface names should be capitalized like
Interfaces interface ATS;
class names.
Methods Our Methods are verbs, in mixed case with register();
the first letter lowercase, with the first viweReport();
letter of each internal word capitalized.
Except for variables, all instance, class, public static int animal_locked
and class constants are in mixed case with = 0;
a lowercase first letter. Internal words start public static int
with capital letters. Variable names has no appearance_locked = 0;char
Variables
start with underscore _ or dollar sign $ c;
characters, even though both are allowed. public static string level =
null;
5.4 Package
A package is a grouping mechanism for organizing elements into groups to increase their
readability. In other words, it is a grouping of model elements, such as use cases, or activities,
defining scopes of understanding. Packages are used to deal with complexity in the same way
a user organizes files and subdirectories into directories.
Our ATS system comprises one main package ATS which in turn has 3 sub packages. Each
subsystem is depicted as a package.
68 | P a g e
AMHARIC TEACHING
SOFTWARE 2017
pkg Package Diagram
ATS
ATS Control Pack
Quize
Game Dictionary
«interface»
quize pack «interface» «interface»
Game Pack Dictionary Pack
quizeanswer Games Dictionary
Figure 33 package diagram
69 | P a g e
CHAPTER SIX
IMPLEMENTATION AND TESTING
6.1 Introduction
Implementation is the phase where objectives of physical operations of the application
turned into reality i.e. real working model. The crucial phase in the system development
life cycle is the successful implementation of the new application design. The process of
converting as new system into an operational one is known as system implementation.
This includes all those activities that take place to convert from a previous system to a new
system. The focus of our test strategy was simply prototyping testing on our application
due to the limited development period, freshness of the platform and the sheer variety and
number of components involved. The third-party user’s role is being carried out by the
implementation team itself. Therefore, it is made sure that the system meets the required
standards.
The system developers are in a position of converting all documents gathered and
designed into the code so that the system will be implemented for the user to be used
for the purpose it developed. Implementation refers to the Coding of the all documents
gathered starting from requirement analysis to Design phase. For the implementation of
this system, the user must have a desktop on which the system will be installed.
6.2 Sample code of the system

Coding is the process whereby the programmer turns in the physical design specification
created by the designers to working computer code.
70 | P a g e
User Registration code
#region create account

private void Registerok_Click(object sender, EventArgs e)
{
if (tb_user_name.TextLength == 0)
{
MessageBox.Show("first you have to enter your user name!!!!");
}
else
{
using (SqlConnection con = new SqlConnection(constring))
{
try
{
SqlCommand cmd = new SqlCommand();
cmd.CommandText = @"INSERT INTO UserAccount(username, lesson,
greating, animals, appearance, bodyparts, colors, food, home, relationships, inthecity,
wearable, nature, inthekitchen, time, occupation, measurement) VALUES (@user, @lesson,
@greating, @animals, @appearance, @bodyparts, @colors, @food, @home, @relationships,
@inthecity, @wearable, @nature, @inthekitchen, @time, @occupation, @measurement)";
71 | P a g e
cmd.Connection = con;
string text = tb_user_name.Text;
int x = 0;
cmd.Parameters.Add(new SqlParameter("@user", text));
cmd.Parameters.Add(new SqlParameter("@lesson", x));
cmd.Parameters.Add(new SqlParameter("@greating", x));
cmd.Parameters.Add(new SqlParameter("@animals", x));
cmd.Parameters.Add(new SqlParameter("@appearance", x));
cmd.Parameters.Add(new SqlParameter("@bodyparts", x));
cmd.Parameters.Add(new SqlParameter("@colors", x));
cmd.Parameters.Add(new SqlParameter("@food", x));
cmd.Parameters.Add(new SqlParameter("@home", x));
cmd.Parameters.Add(new SqlParameter("@relationships", x));
cmd.Parameters.Add(new SqlParameter("@inthecity", x));
cmd.Parameters.Add(new SqlParameter("@wearable", x));
cmd.Parameters.Add(new SqlParameter("@nature", x));
cmd.Parameters.Add(new SqlParameter("@inthekitchen", x));
cmd.Parameters.Add(new SqlParameter("@time", x));
cmd.Parameters.Add(new SqlParameter("@occupation", x));
cmd.Parameters.Add(new SqlParameter("@measurement", x));
con.Open();
int i = cmd.ExecuteNonQuery();
if (i == 1)
{
MessageBox.Show("user created successfully/ተጠቃሚው በትክክል ተመዝግቧል");
Register.Visible = false;
Login.Visible = true;
}}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}}
}#end region
72 | P a g e
Sample code validation
if (tb_user_name.TextLength == 0)
{
MessageBox.Show("first you have to enter your user name!!!!");
}
Sample code for lesson to play
private void animal_sheep_Click(object sender, EventArgs e)

{
using (var soundPlayer = new SoundPlayer(@"audio/animal/sheep.wav"))
{
73 | P a g e
soundPlayer.Play();
}
}
6.3 Final testing of the system

Once code has begun, the testing process can begin and proceed in parallel.AS each program
module is produced, it can be tested individually, as part of the larger program, and then as
part of larger system.
The following are different testing strategies. We will perform following testing techniques
for checking functionality of our proposed system.
➢
Unit testing: - First we will test each unit at each system. Each module of the
system can be tested check the working of each classes, methods and attributes of
the system. For immediately maintain at which the problem is occurred.
➢
Integrated testing: - In this testing part, all the modules will be combined together and
tested for their combinability with each other and with the systems functionality. If
error occurs in combining them, the module with problem will be identified and re
combined. All team members perform both units testing and integrated testing during
development. Here users cannot involve.
➢
System testing: - In this testing, the team performs over all functional testing
by checking whether it meets the required target or not.
➢
User Acceptance testing: - under this testing, there are another sub tastings, which
would be performed:
➢
Alpha testing: -representative of the user will come to us and test the system by
himself whether it meets their need or not.
➢
Beta testing: - The system will be tested by the users at their own working
place whether it meets their needs or not.
6.4 Hardware software acquisition
6.4.1 Hardware
➢
Computers: for running the system
➢
Network connection
➢
Printer: For printing Documentation
➢
Speaker: for sounding purpose.
74 | P a g e
6.4.2 Software
For the System implementation, the following software’s are used.
➢
Microsoft visual Studio 2012
➢
Microsoft office Visio Enterprise Architect for UML diagram drawing.
➢
S4BScreenRecorder for screen recorder
➢
Mobile sound cutter
➢
Browser: like UC Browser
➢
Wondershare Video Editor
➢
Format Factory
6.5 User manual preparation

Since our application is not web based, the system developed is software and it is installed
on a desktop. After the implementation has been completed, it is directly changed to setup.
To access the application, the user opens the application and the home screen will be
displayed then user select the help button After selection of the help button each of the things
will be displayed in video then after that the user can learn by looking the video, observing
the images and listening the sounds.
6.6 Training
During the deployment of the system, the project group members prepare video tutor in the
application help button so any user can take training from the video and explaining how the
system works and in what way they can use the system. Help activity integrated with desktop
application for the user.
6.7 Installation process

Since our project is desktop application that install on window operating system only the basic step to
install the project is
Step 1: download the ATS software from the internet using any browser
Step 2: After download, the software Right Click ATS.exe Run as administrator
Step 3: chose the folder that application installed

75 | P a g e
Step 4: click install
76 | P a g e
Step 4: then click next up to finish
Step 5: after finish installation run the application
6.8 Startup strategy

Find the software form internet
Install to desktop window operating system computer
77 | P a g e
CHAPTER SEVEN
CONCLUSION AND RECOMMENDATION
7.1 Conclusion
This Project is more or less fulfills the requirements That mentioned in the previous
chapters is flexible, accurate and attractive with easy and interactive GUI approach.
Generally, the team confidently can ensure that the software is completed successfully with
negligible errors. Finally, the team expects that the developed system used to teach Amharic
language for the intended users of this application and it provides an easy and effective way
of basic teaching of an Amharic language by providing different techniques like providing
lesson, training quiz, playing games and the likes and makes it more reliable and efficient
than the previous manual system.
7.2 Recommendation
While doing this project the team has faced different challenges. According to scope of our
project the team develops desktop based application. Because of the time constraint we
cannot do beyond to our scopes, but in the future the team believes that this system can be
fully operational by having enough time and full information. Next, the team would
recommend that further work should be done on the application in order to make the
system perform better like android based language learning of developed country and
language of technology all over the world because nowadays people are using the mobile
based apps rather than desktop application so we recommend further improvements to this
desktop application our project team start android application but didn’t finish do to time
constraint. To do this team member recommended Debrebrhan university department of
computer science satisfies the following things: -
➢ Android must give as one course in two terms
➢ Basic needs for department must be fulfilled on a time, i.e.

Internet access, lectures and etc.
78 | P a g e
➢ The group members strongly recommend the department that

for the coming students, it has to provide them with better service than
the present in better hard ware, guaranteed software’s, giving
orientations how to proceed, offering guest to provide them with more
experienced work, support morally, manually, forming good relation
with students, giving students description of each phases and so on. So
that it will get what it expects from its students and satisfy with them.
79 | P a g e
7.3 Appendix
Appendix A: diagram used during development
Symbol Definition
Actor
use case
Compo
Package
nent
Name
Component
Node
Activate
Message return
80 | P a g e
References
Abebe. (2004). amharic english dictionary.
Ambler. (2004). the object primer second edition.
Balegurusamy. ( 2nd Edition). Object Oriented programming with C++.
dr.Hadise. (2002). Habesha Amharic book.
Hoffer. (2000). Modern System Analysis and Design by Jeffery A.
Pirsig, R. (1999). Modeling with UML.
valacita, J. s. (2000). Essential System Analysis and Design. 2nd Edition.
81 | P a g e

Amharic Teaching Software DocumentGroup 5

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Amharic Teaching Software DocumentGroup 5

Uploaded by

Copyright:

Available Formats

Amharic Teaching Software

A Senior Project Documentation Submitted to Debre Berhan

1. Hailegebrial Tekletsadik 022/06

Supervised By: -Chalew Tesfaye

College of Computing, Department of Computer Science

College: - College of Computing

Department: - Computer science

Project title: -Amharic Teaching Software

Name of program coordinator Signature

Name of advisor Signature

Examining committee members signature Date

1. Examiner 1 ____________ ____________ __________

2. Examiner 2 ____________ ____________ __________

3. Examiner 3 ____________ ____________ ___________

5. Examiner 5 ____________ ____________ ___________

1.2 Background Information of the Organization

1.2.1 Vision of DBU

1.2.2 Mission of DBU

➢ Undertaking a problem-solving research based on national need and

➢ Offering government and community centered training, consultancy

1.3 Background of the project

1.4 Problem Description

1.4.1 Statement of the Problem

1.4.2 Proposed solution

➢ As an official language in Ethiopia most people where in easy to understand

1.5 Significance of the project

1.6 Objective of the project

1.6.2 Specific objective

➢ To find a solution to the existing problem.

1.7 Scope and Limitation of the project

➢ Commonly used sentences translation with translator

1.7.2 Limitation of the project

1.8 Feasibility study

1.8.1 Economic Feasibility

➢ Improvement of management control through the following ways

▪ The resource can be saved online.

▪ Can’t be removed/stolen like books or dictionary.

▪ Easy to keep safe and control.

➢ Increase the good will of learner

➢ Availability of new, better, or more information to the learner by providing

1.8.2 Technical Feasibility

➢ MS word 2016: for documentation.

➢ Visual paradigm UML: for diagrams and chart.

➢ MS-Window Office Visio 2007: for diagrams and chart.

➢ MS Power point for presentation.

➢ C# with SQL studio for coding parts.

➢ Disk Drivers: 8GB flash disk or CD-Drive for storing data.

➢ Flush: for transfer of data from one computer to another.

➢ Printer: for printing document.

➢ Two Laptops or Personal computer: for all works.

1.8.3 Operational Feasibility

➢ The proposed system offers greater level of user-friendliness.

➢ The proposed system can be implemented easily.

1.8.4 Schedule Feasibility

1.9 Methodology of the project

1.9.1 Methodology for data collection

We will gather information formally through interview of different people,

1.9.2 Methodology for system analysis and design

➢ Improved quality by providing the application on time, on budget and meet

1.10 Management Issue

1.10.1 Team configuration and management

Project Amharic Teaching Software(ATS)

Prepared No Name Responsibility ID No

2 Ruth Mesfin Project manager 033/06

1. Examiner 1 __

2. Examiner 2 __

3. Examiner 3 __ _

5. Examiner 5 __ _