Full Doc MBDA

Multi Lingual Android Mobile Dictionary Application
MOBILE DICTIONARY APPLICATIONS FOR

ANDROID SMART PHONE
A SENIOR PROJECT (DOCUMENTATION) SUBMITTED IN
PARTIAL FULFILLMENT OF THE REQUIREMENT FOR THE
AWARD OF DEGREE OF BACHLER OF TECHNOLOGY
(COMPUTER SCIENCE) (2016)
JIGJIGA UNIVERSTY COLLEGE OF ENGINEERING AND

TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE
Submitted by
NAME ID NUMBER
1. Bfitsum Beyene 1636/05
2. Enchalew Snishew 1648/05
3. Shishigu mersha 1679/05
4. Sefie Wedu 2098/04
5. Fuad Mehamed 1656/05
Jigjiga Ethiopia 4 February 2016
I|Page
JJU COET DEPARTMENT OF COMPUTER SCIENCE
APPROVAL SHEET
This is to certify that this project report entitled ANDROID MOBILE DICTIONARY
APPLICATION developed and submitted by For the Partial fulfillment for the requirement of
the Degree in Bachelor Science in (Computer Science)
Advisor: Mohamed Daud Signature ………Date………….

Co-Advisor: _____ Signature ………Date………….
Examiner(s)
1. Instructor.................…................................. Signature………..Date……………..
2. Instructor.................…................................ Signature………..Date……………..
II | P a g e
ACKNOWLEDGMENT
First and foremost and above all our biggest thanks would be to GOD and S.t Digll Maryam
because nothing could be possible without his free will and the completion of this project is
supported by him. Secondly, we are much appreciative to record our sincere appreciation to our
Advisor Mohamed Daued (M.S.C) for guiding and correcting various documents of ours with
attention and care. He has taken pain to go through the project and made necessary correction as
and when needed.
Also we would like to thank (Computing Department coordinator and our Instructor) for his
appreciation to work our project on mobile application and for his suggestion about the project.
At the last but not the least special thanks for our project member, our classmates and laboratory
assistance for their great help and keeping us to reach today.
III | P a g e
ABSTRACT
Today, mobile phones provide number of advanced functions, among which possibility of
running mobile applications seems to be the most interesting feature. It changes a standard
mobile phone into a mini size yet still powerful computer that is able to run various applications,
like map guide, dictionary, games and so on.
The system developed in this project, mobile based dictionary application that Provides users a
simple and efficient way of maintaining their dictionary application. It can be used by all user
easily. Throughout the project that focus has been on presenting word meaning to users of the
dictionary in an easy and understandable manner. The project is very useful for those who want
to know about Dictionary meanings and developed language skill by using mobile application
based. Proposed mobile based dictionary application system will eliminate all the ambiguity
word meaning and increase the speed of human mind understanding by giving the exact meaning
to the word. System will allow users to search word meaning from the system by using the word
that you want to know.
Dictionary is the list of words with their definitions. Android Mobile Dictionary Application is
an application that provides Amharic- English, Amharic-English, Amharic-Tigrigna, Amharic-
Oromigna, Amharic-Somali and Amharic-Guragie word translation. In addition to word
translation it has multimedia content i.e. pronunciation for words and viewing images.
Displaying the meaning of the word with multimedia content will help the users to understand
the meaning of the word very easily. The sound/voice support helps the user to know how the
word is pronounced correctly.
Android Mobile Dictionary Application has a client server architecture where the mobile client
act as a client and a file server for storing multimedia contents will be used as a server. The
dictionaries will be stored in the mobile phone. Whenever the user wants to see image or listen
pronunciation, he/she can download from the file server
IV | P a g e
List of Figures
Figure 1 Android Frame work ...................................................................................................... 10
Figure 2 Time scheduling ............................................................................................................. 12
Figure 3 snapshot of online dictionary.......................................................................................... 15
Figure 4 the snapshot of desktop application dictionary .............................................................. 15
Figure 5 Use case diagram ............................................................................................................ 24
Figure 6 sequence diagram for choose dictionary ........................................................................ 30
Figure 7 Sequence Diagram for search meaning .......................................................................... 31
Figure 8 sequence diagram for listen pronunciation ..................................................................... 32
Figure 9 sequence diagram for view image .................................................................................. 33
Figure 10 Activity diagram for select dictionary .......................................................................... 34
Figure 11 Activity diagram for select dictionary .......................................................................... 35
Figure 12 Activity diagram for Listen to pronunciation ............................................................... 36
Figure 13 Activity diagram for view image .................................................................................. 37
Figure 14 Class diagram for mobile dictionary applications ........................................................ 38
Figure 15 client server architecture............................................................................................... 42
Figure 16 Subsystem decomposition for the Dictionary application ............................................ 44
Figure 17 Deployment Modeling for Dictionary application ....................................................... 45
Figure 18 Mapping of tables ......................................................................................................... 46
Figure 19 persistent data of mobile dictionary systems ................................................................ 47
V|Page
List of Table
Table 1 Budget Table .................................................................................................................... 11
Table 2 cost for the existing paper format dictionaries................................................................. 17
Table 3 cost mobile dictionary application ................................................................................... 17
Table 4 Expected income per year ................................................................................................ 17
Table 5 Use case description for choose dictionary...................................................................... 25
Table 6 Use case description for search definition ....................................................................... 26
Table 7 Use case documentation for view image ......................................................................... 27
Table 8 Use case documentation for listen pronunciation ............................................................ 28
VI | P a g e
Content List
ACKNOWLEDGMENT............................................................................................................... III
ABSTRACT .................................................................................................................................. IV
List of Figures ................................................................................................................................ V
List of Table .................................................................................................................................. VI
Content List .................................................................................................................................. VII
CHAPTER ONE ............................................................................................................................. 1
1.1 Background and Introduction .............................................................................................. 1
1.1.1 Introduction ..................................................................................................................................... 1

1.1.2 Background ...................................................................................................................................... 1
1.2 Statement of The problem ....................................................................................................... 3
1.3 Objective Of The project ........................................................................................................ 3
1.3.1 General Objective ............................................................................................................................ 3

1.3.2 Specific Objective ............................................................................................................................. 3
1.4 Project Scope and Limitation .................................................................................................. 3
1.4.1. Project scope................................................................................................................................... 3

1.4.2. Project Limitation............................................................................................................................ 4
1.5 Methodology ............................................................................................................................. 4
1.5.1 Data collection ............................................................................................................................... 4

1.5.2 Analysis and Design ........................................................................................................................ 5
1.5.3 Development tools........................................................................................................................... 5
1.6 Significance of the project ........................................................................................................ 6
1.7 Risk assessment and management ............................................................................................ 6
1.8 Operating and Development Environment ............................................................................. 7
1.9 Budget and Time breakdown .................................................................................................. 11
1.9.1 Budget ............................................................................................................................................ 11
VII | P a g e
1.9.2. Time schedule ............................................................................................................................... 11

1.10 Document organization ......................................................................................................... 12
CHAPTER 2 ................................................................................................................................. 13
2. DESCRIPTION OF THE EXISITING SYSTEM .................................................................... 13
2.1. Introduction ............................................................................................................................ 13
2.2. The main activities ................................................................................................................. 13
2.3. Functions of the existing system ............................................................................................ 13
2.4. Players of the existing system ................................................................................................ 13
2.5. Report generating in the existing system ............................................................................... 14
2.6. Documents used in the existing system ................................................................................. 14
2.7. Weakness of the existing system ........................................................................................... 16
2.7 Strength of the existing system ............................................................................................... 16
2.8 Feasibility study................................................................................................................................. 16

2.8.1 Economical feasibility .................................................................................................................... 16
2.8.1.1. Cost Benefit Analysis .............................................................................................................. 16
2.8.2. Time Feasibility ............................................................................................................................. 18
2.8.3. Technical Feasibility .................................................................................................................... 18
2.9. Alternative solutions .............................................................................................................. 18
CHAPTER THREE ...................................................................................................................... 19
3. Requirement Specification and Analysis .................................................................................. 19
3.1. Introduction ............................................................................................................................ 19
3.1.1. Purpose ......................................................................................................................................... 19

3.1.2. Intended audience and reading suggestions ................................................................................ 19
3.1.3. Document convention .................................................................................................................. 20
3.2. Objective ................................................................................................................................ 20
3.3. Functional requirement .......................................................................................................... 20
3.4. Product prospective ................................................................................................................ 21
VIII | P a g e
3.5. Product function ..................................................................................................................... 21
3.6. Principal actors....................................................................................................................... 21
3.7 User Characteristics ................................................................................................................ 21
3.8 General Constraints ................................................................................................................. 21
3.9 Assumptions and Dependencies ............................................................................................. 22
3.10 Non-functional Requirements ............................................................................................... 22
3.11. System model ....................................................................................................................... 23
3.11.1 Use case diagram ......................................................................................................................... 23

3.11.2 Use case description .................................................................................................................... 25
3.11.3 Sequence diagram........................................................................................................................ 29
3.11.4. Activity diagram .......................................................................................................................... 34
3.11.5 Class Diagram ............................................................................................................................... 38
CHAPTER FOUR ......................................................................................................................... 39
4. SYSTEM DESIGN ................................................................................................................... 39
4.1 Introduction .................................................................................................................................... 39

4.2 Design Goals ........................................................................................................................... 39
4.2.1 Performance Criteria...................................................................................................................... 39

4.2.2. Dependability ................................................................................................................................ 40
4.2.3 Maintenance Criteria ..................................................................................................................... 40
4.2.4 End-user criteria............................................................................................................................. 41
4.3 System Architecture ................................................................................................................ 41
4.4. Subsystem Decomposition ..................................................................................................... 42
4.5. Deployment Diagram (hardware/ software mapping) ........................................................... 44
4.6 Persistent Data Management................................................................................................... 47
References ..................................................................................................................................... 47
IX | P a g e
CHAPTER ONE
1.1 Background and Introduction
1.1.1 Introduction
The system develop in this project, mobile based dictionary application that Provides users a
simple and efficient way of maintaining their dictionary application. It can be used by all user
easily. The project is very useful for those who want to know about Dictionary meanings and
developed language skill by using mobile application based. Proposed mobile based dictionary
application system will eliminate all the ambiguity word meaning and increase the speed of
human mind understanding by giving the exact meaning to the word. System will allow users to
search word meaning from the system by using the word that you want to know.
1.1.2 Background
A dictionary (also called a wordbook, lexicon, or vocabulary) is a collection of words in one or
more specific languages, often listed alphabetically (or by radical and stroke for ideographic
languages), with usage information, definitions, etymologies, phonetics, pronunciations, and
other information;[1] or a book of words in one language with their equivalents in another, also
known as a lexicon.[1] According to Nielsen (2008) a dictionary may be regarded as a
lexicographical product that is characterized by three significant features:[1] it has been
prepared for one or more functions; it contains data that have been selected for the purpose of
fulfilling those functions;[2] and its lexicographic structures link and establish relationships
between the data so that they can meet the needs of users and fulfill the functions[3] of the
dictionary.
A broad distinction is made between general and specialized dictionaries. Specialized
dictionaries do not contain information about words that are used in language for general
purposes-words used by ordinary people in everyday situations. Lexical items that describe
concepts in specific fields are usually called terms instead of words, although there is no
consensus whether lexicology and terminology are two different fields of study. In theory,
general dictionaries are supposed to be semasiological, mapping word to definition, while
specialized dictionaries are supposed to be onomasiological, first identifying concepts and then
establishing the terms used to designate them. In practice, the two approaches are used for both
types.[2] There are other types of dictionaries that don't fit neatly in the above distinction, for
instance bilingual (translation) dictionaries, dictionaries of synonyms (thesauri), or rhyming
1|Page
dictionaries. The word dictionary (unqualified) is usually understood to refer to a monolingual

general-purpose dictionary.[3]
A different dimension on which dictionaries (usually just general-purpose ones) are sometimes
distinguished is whether they are prescriptive or descriptive, the latter being in theory largely
based on linguistic corpus studies. This is the case of most modern dictionaries. However, this
distinction cannot be upheld in the strictest sense. The choice of headwords is considered itself
of prescriptive nature; for instance, dictionaries avoid having too many forbidden words in that
position. Stylistic indications present in many modern dictionaries is considered less than
objectively descriptive as well. [4]
Although the first recorded dictionaries date back to Sumerian times (these were bilingual
dictionaries), the systematic study of dictionaries as objects of scientific interest themselves is a
20th century enterprise, called lexicography, and largely initiated by Ladislav Zgusta. The birth
of the new discipline was not without controversy, the practical dictionary-makers being
sometimes accused of "astonishing (amazing)" lack of method and critical-self-reflection.[5]
According to the Manual of Specialized Lexicography’s a specialized dictionary (also referred
to as a technical dictionary) is a lexicon that focuses upon a specific subject field. Following
the description in The Bilingual LSP Dictionary lexicographers categorize specialized
dictionaries into three types. A multi-field dictionary broadly covers several subject fields. A
single-field dictionary narrowly covers one particular subject field (e.g., law), and a sub-field
dictionary covers a singular field (e.g., constitutional law). For example, the 23-language Inter-
Active Terminology for Europe is a multi-field dictionary, the American National Biography is
a single-field, and the African American National Biography Project is a sub-field dictionary.
In terms of the above coverage distinction between "minimizing dictionaries" and "maximizing
dictionaries", multi-field dictionaries tend to minimize coverage across subject fields (for
instance, Oxford Dictionary of World Religions) whereas single-field and sub-field dictionaries
tend to maximize coverage within a limited subject field (The Oxford Dictionary of English
Etymology).[7]
2|Page
1.2 Statement of The problem

Currently, most people of our country use paper format dictionaries and some of them, who can
get Internet access, use online dictionaries. Still most the people uses English to Amharic
dictionary but there not use Amharic to Orromic, Amharic to Somali, Amharic to tigrie,
Amharic to English and Amharic to guragie. In addition to that, some of the people use desktop
dictionary applications. To search definition or meaning of a single word from paper format
dictionary, the user should find the word among several pages by turning pages of the dictionary.
It may take more time to do that. If users want to get reference of five dictionaries, they should
buy those dictionaries. So, this forces to expense more. Since most people of Ethiopia live in
rural areas where internet connection is not available, they cannot use online dictionary
applications. For desktop dictionary application users, it is difficult for them to use everywhere
because it is not easily portable and also listen to pronunciations and viewing images is
unthinkable in paper format dictionaries.
1.3 Objective Of The project

1.3.1 General Objective
The general objective of this project work is to develop Dictionary application for mobiles that
translates Amharic to Orromic, Amharic to Somali, Amharic to tigrie, Amharic to English and
Amharic to guragie that enables users to get dictionary access everywhere.
1.3.2 Specific Objective

 Select the language as you want.
 Search words in the dictionaries.
 Give definition or meaning of words.
 Enable users to listen pronunciation of meanings.
 Enable users to view images of words.
1.4 Project Scope and Limitation

1.4.1. Project scope
This dictionary application will be applicable for cell phones which can run on the Android
platform. It will enable users to translate Amharic-to-English, Amharic-to- oromigna, Amharic-
to-Guragigna, Amharic-to-Tigrigna and Amharic-to-Somali and the system will be:
 Enable users to choose a dictionary
3|Page
 Enable users to search meanings

 Enable users view to images for some words or definitions.
 Enable users listen to pronunciation for some words or definitions
1.4.2. Project Limitation

The application will run on smart phones which can run on the Android operating system. We
cannot get better open source mobile application development environment rather than Android.
Corona is best for developing cross platform mobile applications. But it is not open source. The
application has no voice recognition capability.
1.5 Methodology
Among the different methodologies in practice we thoughtfully pay our time to work on
Objected Oriented Programming (OOP) approach for achieving effective and reliable working
system in the future. We will use OOP because of the following advantages
 Code reusability - new objects can be derived from old objects.
 Code Modularity - Everything in OOPL is an object, they can be interchanged or
removed to meet the user’s needs.
 Easier maintenance - Inheritance usually reduces maintenance.
 Design stability - Once you have developed a stable base class, new classes that you
derive may have less errors and bugs.
1.5.1 Data collection

For the collection of data in this project is document analysis and interview
 Document analysis: - To get more secondary source information and ideas about
mobile dictionary application, we will refer journals, project report documents and
other reading materials that are needed to develop this application. Additionally by
buying paper format dictionary that translates Amharic-to-English, Amharic-to-
oromigna, Amharic-to-Guragigna, Amharic-to-Tigrigna and Amharic-to-Somali.
 Interview: - we used interview to get information about existing system for developing
our project. We will conduct the interview with s p e a k e r o f t h a t l a n g u a g e and
students who learned in Jigjiga University.
4|Page
1.5.2 Analysis and Design

Among the different methodologies available we plan to use the object oriented design
methodology for the development of our system. Because it is best way to construct, manage and
assemble objects that are implemented in our system, and the composition of objects and
collaboration between objects on the system. Object oriented design methodology has two
phases:-
 Object Oriented Analysis (OOA): During this phase we looked at the problem
domain, and with the aim of producing a conceptual model of the information that
exists in the area which will be analyzed. And Modeled the functions of the system
(use case modeling), identifying the business objects, organize the objects and also the
relationship between them and finally model the behavior of the objects.
 Object Oriented Design (OOD): During this phase Model object interactions and
behaviors that support the use case scenario, and finally update object model to reflect
the implementation environment. And also transforms the conceptual model produced
in object-oriented analysis to take account of the constraints imposed to our system
format, so that we can use this phase to refine the use case model to reflect the
implementation environment.
1.5.3 Development tools

As described above in the requirement modeling it is expected to use Object Oriented
approach will be used for developing Mobile Dictionary Application. Object oriented
technology is of broad means used to handle highly structured application systems. Object
oriented technology provides numerous advantages in applications by making them easy
to use and maintain, it is plat form independent, portable and reliable by itself.
We will use different software, hardware tools and programming language. Hardware
tools such as computer (laptop) and android smart phone. Software tool such as
Eclipse, snipping Tools, Microsoft office word and PowerPoint.
5|Page
1.6 Significance of the project

 A five bilingual mobile dictionary application being built.
 It can be great use to the users.
 It can assist them in learning languages.
 It will also help in improving ones language skills.
 Foremost it will be an effective tool when traveling and communicating with people and
decrease purchasing cost for users.
 The application also saves time and energy for users, because in the case of paper format
dictionaries, to get the meaning of a single word, the user should search it among several
pages by turning manually.
 This wastes their time and to get use of five different dictionaries everywhere, users have
to carry those dictionaries.
 So our application will resolve these difficulties. In addition to search meanings, the
application will enable dictionary users listen –pronunciations and view images for some
words.
1.7 Risk assessment and management

Some of the risks might face during our project work is assumed as the following points.
 Unexpected man power failure:
 Virus attack on computer:
 Failure of electric power:
 Resource related problem:
 We can’t get words with meanings easily:
To manage the above risk we take the following as a solution
 We will manage the problem of failure man power by covering the tasks of
the victim with the remaining team members that they should take alternative
period.
 For virus infection, will use backup; duplicate files more than two computers,
backup files on CD-RW and external devices and we will also use antivirus in
order to resist problem.
6|Page
 To manage power problem we will use personal resources like laptop.

However, since all the team members do not have laptop computer, the group
members will be forced to get through any way during the time of for longed
power cut.
 To get the word with meanings we will buy hard copy Dictionary meanings.
 Our target source is through Google search, books unless we seek our advisors
help and other colleagues’ cooperation.
1.8 Operating and Development Environment

The programming tools that the project concentrates are the following:
 Software requirements:
 Android SDK
 ADT Plug-in
 JDK
 Eclipse
 MS word: for documentation.
 Paint: for editing
 Window 7 Operating system
 MS power point for presentation
 Edraw, MS Visio, Visual paradigm for drawing different diagrams
 Hardware requirements:
 Printer: for printing document
 Paper, pencil, pen, computer, etc.
Android Framework
Android is a software stack for mobile devices that includes an operating system, middleware
and key applications. The Android SDK provides the tool and the APIs necessary to begin
developing applications on the Android platform. Applications are written using the Java
programming language and run on Dalvik, a custom virtual machine specifically designed for
embedded use. Dalvik runs on top of a stripped down Linux kernel.
Android was originally developed by Google. Android was designed to be distributed based on
an open source license and to compete against other mobile platforms, including those from
7|Page
Microsoft, Research In Motion and Apple Inc. Google also announced the founding of the Open
Handset Alliance (OHA), a consortium of 47 technology companies devoted to advancing open
standards for mobile devices. Android isn’t currently completely open source but a large portion
of it is. Google and the OHA is committed to eventually making Android 100% open source.
Architectural Overview
The Android environment is built on top of a Linux kernel and includes a set of C/C++ libraries,
the Android Runtime environment, an Application Framework and a set of core applications as
described in the diagram below.
Linux Kernel
At the base of the Android environment is a stripped down Linux Kernel. Linux is used to
communicate with the mobile phone’s hardware and Android supports multiple phone
processors. Much of the Android work though happens in the layers above the OS [6] .
Android Runtime
The Android runtime environment consists of a set of core libraries and virtual machine. The
core libraries provide most of the functionality available in the core libraries of the Java
programming language.
On conventional computing devices software runs directly on the operating system kernel but an
Android application runs in its own process, with its own instance of the Dalvik virtual machine.
Dalvik has been written so that a mobile device can run multiple instances of it in an efficient
manner. Dalvik is not your typical JVM though it’s very similar. The Dalvik VM executes files
in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The
VM is register-based, and runs classes compiled by a Java language compiler that have been
transformed into the .dex format by the included "dx" tool.
The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and
low-level memory management.
Libraries
Android includes a set of C/C++ libraries used by various components of the Android system.
These capabilities are exposed through the Android application framework. Some of the core
libraries are listed below:
8|Page
 System C library - a BSD-derived implementation of the standard C system library (libc),

tuned for embedded Linux-based devices
 Media Libraries - based on Packet Video’s Open CORE; the libraries support playback
and recording of many popular audio and video formats, as well as static image files,
including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG
 Surface Manager - manages access to the display subsystem and seamlessly composites
2D and 3D graphic layers from multiple applications.
 LibWebCore - a modern web browser engine which powers both the Android browser
and an embeddable web view
 SGL - the underlying 2D graphics engine
 3D libraries - an implementation based on OpenGL ES 1.0 APIs; the libraries use either
hardware 3D acceleration (where available) or the included, highly optimized 3D
software rasterizer.
 Free Type - bitmap and vector font rendering
 SQLite - a powerful and lightweight relational database engine available
Application Framework
Developers have full access to the same framework APIs used by the core applications. The
application architecture is designed to simplify the reuse of components; any application can
publish its capabilities and any other application may then make use of those capabilities (subject
to security constraints enforced by the framework). This same mechanism allows components to
be replaced by the user.
Underlying all applications is a set of services and systems, including:
 A rich and extensible set of Views that can be used to build an application, including
lists, grids, text boxes, buttons, and even an embeddable web browser
 Content Providers that enable applications to access data from other applications (such as
Contacts), or to share their own data
 A Resource Manager, providing access to non-code resources such as localized strings,
graphics, and layout files
 A Notification Manager that enables all applications to display custom alerts in the status
bar
9|Page
 An Activity Manager that manages the life cycle of applications and provides a common
navigation back-stack
Generally, the Android SDK provides the tool and the APIs necessary to begin developing
applications on the Android platform. Applications are written using the Java programming
language. The Android SDK tools compile the code along with any data and resource files into
an Android package, an archive file with an .apk suffix. All the code in a single .apk file is
considered to be one application and is the file that Android-powered devices use to install the
application.[6]
Figure 1 Android Frame work
10 | P a g e
1.9 Budget and Time breakdown

1.9.1 Budget
When developed any software has its own budget. For the successful accomplishment of our
project, we estimated the costs associated to each item required. This will help us to limit the
constraints related to cost while the project is conducted
Description Quantity Unit Price Total Price

(Birr) (Birr)
CD ROM Disks 5 15.00 75.00
Flash Disk 1 (4GB) 250.00 250.00
Printer cost 200 pages 3.00 600.00
Photograph cost 5 photos 12.00 60.00
Photo copy cost 200 pages 0.5 100.00
Hard copy dictionary cost 5 100 500.00
Transport Total trip _ 200
Other Unspecified - 1000.00

costs
Total 2800.00
Table 1 Budget Table

1.9.2. Time schedule
The schedule for this project will be feasible (practical) due to proper information exchange
between the developing team and the Advisor. And also the time set to develop the application is
11 | P a g e
enough to complete at the predefined day and time since the project is supposed to be completed
in 6 months i.e. 2 months for documentation and the rest 4 months for implementation and
testing.
Figure 2 Time scheduling
1.10 Document organization

The project document is organized in four-chapters including the introduction section of the
project that include: -Introduction and Background, Statement of problem, objectives and
Methodology, project scope and Limitation, Risk Assessment and Management, Operating
Environment, significance of the projects and budgets and work break downs. The second
chapter of the document describes the detail description of the existing system which shows the
main activities, strength and weakness, report generating in the existing system, Feasibility
Study, function and players of the existing system and other issues in the existing system. The
third chapter is about requirement specification and analysis which contains the, Product
Perspective and function, General Constraints, Principal Actors, functional and non-functional
Requirements, Essential Use case Diagram, Use case Descriptions, sequence Diagram, class
Diagram and Activity Diagram. The fourth chapter deals about system design that contains
Design Goals, system architecture, subsystem decomposition, Persistent Data Management and
other subsections that describe the detail design of the proposed system
12 | P a g e
CHAPTER 2
2. DESCRIPTION OF THE EXISITING SYSTEM
2.1. Introduction
This chapter contains the description of the existing system and the problem that occurs in
system. This phase is pointing what the system needs and contains many diverse activities and
tasks that are extremely important to the overall success of the proposed solution. It includes
weakness, strengthens, documents used in the system, players of the system and description
(current system description), function of the existing system and alternative solution. This will
help to know about the existing systems all activity and improve the limitation of the existing
system in such a way
2.2. The main activities

The main activities of the existing system are listed below:
 Gives word’s meaning.
 Getting word translation.
 Search the word meaning touring the paper one by one.
 Search word meaning on internet connection.
 The word listed alphabetically.
2.3. Functions of the existing system

The current system provides good service for their users by using manual system. The
functions of the mobile dictionary application are the following:
 Give the unknown word meaning.
 Developing language skill.
 Developing knowledge.
2.4. Players of the existing system

The system has the following players:
 User: - user is someone, who can be read and understand any document.
That means users can write the word on the text filed, press search button to
get different word meanings. And also press the audio button to hear the
pronunciation of the word.
13 | P a g e
2.5. Report generating in the existing system

As we observed and also made interview the students and some other peoples which are
using dictionary report generating mechanism is manual that means any kind of report is paper
based and computer based. Using the paper format dictionaries have been only means of getting
word translation, but now it is not convenient means especially in today’s rashly world. The
other means of getting word translation is using online dictionaries. Online dictionaries solve
some of the drawbacks of the printed version dictionaries. One of the limitation of online
dictionaries is one has to have a computer and an internet connection otherwise it is unable to do
the translation of the word. Other dictionaries are found in the form of electronic portable
devices or CD-ROM. For CD-ROM dictionaries, they are not fully portable as they require
computers to use them.
Dictionary is an essential utility for every individual, but the convenience is however
compromised when expected to carry paper dictionary or device around to have a quick access to
words and their definitions. Besides, with paper dictionaries, users have to turn the pages of the
dictionary to search for a specific word. Because of the very large cost, a dictionary which is
written on paper has few opportunities for revisions.
2.6. Documents used in the existing system

The documents used in existing system are listed below.
The snapshot of online dictionary which is used to online dictionary application on computer that
means get words meaning with internet access.
14 | P a g e
Figure 3 snapshot of online dictionary

The snapshot of desktop dictionary application which is used for dictionary application on
computer that means search the word meaning without internet connection.
Figure 4 the snapshot of desktop application dictionary
15 | P a g e
2.7. Weakness of the existing system

The weaknesses of existing system are:
 There is no pronunciation of the words.
 It is limited on international language and some national languages.
 Online dictionary and desktop dictionary applications are using computer and an
internet connection otherwise it is unable to do the translation of the word.
 By using system to search one word meaning it takes much time in paper format
dictionary. search the word meaning touring the paper one by one and get
meanings
2.7 Strength of the existing system

The strengths of existing system are:-
 The paper format dictionary works country side (available for everywhere).
 Some existing online dictionary system was get the word meanings with partial
definition.
 It does not require specialized software.
 It is does not require android or smart phones.
2.8 Feasibility study

Any developed software has to satisfy the criteria for feasibility. This project is also going to
satisfy the following criteria:
2.8.1 Economical feasibility

Is the measure of cost effectiveness of the project? That is why sometimes economic feasibility
is called cost benefit analysis. For the project we are working on, we have the following benefits
and costs.
2.8.1.1. Cost Benefit Analysis
A. Tangible Benefits
Cost reduction for users (Production cost)
Cost for 10,000 word paper dictionaries
Dictionary Price(Birr)
16 | P a g e
Amharic to English 45.00
Amharic to Oromiffa 45.00
Amharic to Somali 45.00
Amharic to Guragie 40.00
 Amharic to Tigrie  40.00
Total cost 215.00
Table 2 cost for the existing paper format dictionaries
Cost for 10,000 word mobile dictionary app
Dictionary Price(Birr)
Mobile Dictionary app 100.00
Total cost 100.00
Table 3 cost mobile dictionary application

Difference b/n before and after deployment money required for dictionary
Cost Reduction for dictionary = 215.00 –100.00 birr = 115.00 birr
Dictionary Unit number of app will be

Price(Birr) sold per year
Mobile Dictionary app 100.00 1500
Total cost 150,000.00
Table 4 Expected income per year

Profit will be gained after development :150000.00 - 215.00 = 149785.00 Birr
17 | P a g e
B. Intangible benefits
The intangible benefits we suggest from the developing system are:
 Fast definition retrieval for words
 Increase reliability
 Increase portability
2.8.2. Time 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.
2.8.3. Technical Feasibility

Since we have enough knowledge of java programming, we can develop Android applications.
Because Android use java programming language for implementation and also the availability of
tools that are required for developing Android applications and the presence of android mobile
users make the project technically feasible.
2.9. Alternative solutions

 Web based application
In this option the overall tasks of the dictionary application are changed into web based
computerized system without affecting the current structure. Which means every activities
of the user to search the meaning of the word is done using a centralized database and
clients connected to it using a simple web browser everywhere in the globe.
 Desktop Application
The second solution for this problem is desktop application software that provides an easy
to get the word meaning to the users by their personal computer.
18 | P a g e
CHAPTER THREE
3. Requirement Specification and Analysis
3.1. Introduction
The project development team uses an object oriented system development methodology.
Because the Object system development approach gives easier and natural way to break down
problems into simple, small and manageable components so that it reduces the vague appearance
of the big problem. Moreover, it is predominately used and popular method in present software
development trend.
The major activities described in this chapter are constructing a use case model, documenting the
use case course of events, constructing sequence and activity diagram analysis level class
diagram and user prototype about the proposed system. The proposed system is a mobile
dictionary application for devices which can accept software and run on the Android platform or
operating system. It contains five bilingual dictionaries: Amharic-to-English, Amharic-to-
Oromigna, Amharic-to-Tigrigna, Amharic-to-Somali and Amharic to Guragie. It will enable
users to search the meaning of a word with a fast manner and enable to get dictionary service
everywhere on their mobile.
3.1.1. Purpose
The purpose of this section of the document is to provide an overview of the proposed
system, how to build the proposed system, to have clear view or model of the system, an
input for design phase and to obtain the information needed to develop the actual
implementation of our system.
3.1.2. Intended audience and reading suggestions

The document intended to serve several groups of audience. The intended audience of this
document includes:-
 Project Coordinators – to evaluate our project documentation so that it should
satisfy the standard quality of software documentation.
 Computer science department staffs
19 | P a g e
3.1.3. Document convention

Acronyms Description
 OOSDM--------------------------- Object Oriented System Development
Methodology
 GUI--------------------------------- Graphical User Interface
 OOA------------------------------- Object Oriented Analysis
 SRS--------------------------------- System Requirement Specifications
 UI------------------------------------ User Interface
 SI------------------------------------- System Interface
 JDK----------------------------------Java Development Kit
3.2. Objective
The objective of this phase is to develop the requirement specification and analysis as it
started from last section by using the information planned. The requirement specification
is the phase that leads to the designing and implementation; that the correct and accurate
designing has a great role to the system implementation. Based on this designing our
target is for providing the mobile application system to the mobile application, be attained
with the rapidly developing technologies.
3.3. Functional requirement

Functional requirements describe the interactions between the system and the users independent
of its implementation. The functional requirements of the proposed system are listed as follows
 The application should provide searching facility
 The application should display search results
 The application should enable users to select a dictionary.
 The application should provide an appropriate error message.
 The application should enable users to listen pronunciations
 The application should enable users to view images.
 The application should prompt error messages if search is not successful
20 | P a g e
3.4. Product prospective

The proposed Mobile application for Dictionary mobile application system which will be
developed by the project team member is mobile application. This system will provide to
choose the local language, shows the word want to know to the users of the apps.
3.5. Product function

The new proposed system will perform different tasks, such as:
 People can know their word meanings.
 People can developed language skill.
 People can developed knowledge.
 Save times and energy.
3.6. Principal actors

Users: - are someone who want to know the meanings of word. Choose the language want to
know word meaning that are also authorized to use the system and write the word in the text
filled who want to get the meaning.
3.7 User Characteristics

User characteristics are an important aspect for any project. It allows the team to clearly
define and focus on who the end users are for the project and also it allows the team to
check the progress of project. The team is developed the product for the correct users of
this system mostly used by the peoples.
Educational level: Users should be familiar with Amharic language and five local
language such as: - English, Tigrie, Orromic, Somali, Guragie.
Skills: users should have a little knowledge about the Dictionary application.
3.8 General Constraints

When developing this system, as we are a developer justify some constraints for the
accurate use of the developed system. The user must have a mobile phone that supports
android application.
21 | P a g e
3.9 Assumptions and Dependencies

 The system assumes that the developer has enough knowledge about eclipse and
java development kit (jdk).
 It is assumed the maintenance of the database will be assigned to the authorized
person only.
 External users or guests have right to view choose language menu.
3.10 Non-functional Requirements

User Interface: The developed system provides mobile application user interfaces that
are compatible for android operating system and easy to use. The application will provide
user interfaces that are compatible with Android platform.
No Redundancy: In the proposed system can be avoided reputation of data anywhere in the
database but there may be reputation in case of data backup. This would assure economic use
of storage space and consistency of the data stored in the database.
Hardware consideration: The users should have cell phones that can run on the Android
operating system.
Performance characteristics: The application will be accessed by the mobile owner. It should
be given more emphasis for the speed to retrieve definitions and suggestions.
System security: This application will not provide access privileges. Because it is assumed that
the users make their mobile secure by using security codes or other measures.
Quality issue: Information in database should be accurate.
Documentation: The activities and outputs of each system development stage in the project
workflow shall be properly documented for the successful completion of the project. These
documents produced at the end of each stage shall be organized and compiled together at the end
of the project for future reference, system maintenance, and system support.
Availability: All data in the system will be available at any time.
Error handling: When the users of the system interact with the system errors may appear. To
control these inaccuracies the system will generate different messages. Data errors which are
entered in to the system may not be completely avoided but they can be minimized. To do this,
most of the system execution buttons will be controlled according to the sequence which the user
22 | P a g e
is expected to follow or this can be done by generating different system responses to the input of
the users. This application handles wrong words, which are not available in the database, entered
by the user and display error message.
System modification: Some of the user interface and basic modification can be
performed by the collection developers but the system developers are the right persons to
update the system. This shows for one person who have the source code, this document is
helpful to know the full source code information. The system should be easily modifiable
by the developer side to release latest version of the application
3.11. System model

3.11.1 Use case diagram
The use case diagram for the dictionary application provides an external view of a dictionary.
In this system, the user enters the word to the system for finding meaning of the words.
The system searches the meaning for the given word. If the word is available in the database,
then the system retrieve and display the meaning for the word otherwise it shows the message
box that contains the word does not found in the dictionary.
 Identify Actor:
1. Dictionary User- people who get access of the application through their mobiles
 Use cases:
1. Choose Dictionary
2. Search definition/meaning
3. Viewing images
4. Listen to pronunciation
23 | P a g e
Figure 5 Use case diagram
24 | P a g e
3.11.2 Use case description

Use case name: Choose dictionary
Identifier UC1
Primary actor: Dictionary User
Description: This use case is used to select dictionaries
Somali: When the user wants to select dictionary
Preconditions: The Dictionary home layout is displayed
Basic course of action: Step 1. The user selects “English-to-Amharic”, “English-to-

Oromiffa”, “English-to-English”, Or “English-to-Tigrigna”
dictionary.
Step 2.the system displays search layout of the selected
dictionary.
Extends: --
Includes: --
Post condition: Search menu displayed
Table 5 Use case description for choose dictionary
25 | P a g e
Use case name: Search definition
Identifier UC2
Primary Actors: Dictionary User
Description: This use case is used to search definition of words
Somali: When the user wants to search definition of words
Preconditions: The user should select dictionary and search layout should be
displayed
Basic Course of Events: Step 1.the dictionary user enters the word
Step 2.Press the search button
Step 3.the system displays the result
Alternative Paths: 1.1 At step 3 if the word is not found, the system displays error
message
1.2 The system goes to step 1.
Extends: UC1
Includes: --
Post condition: Search result displayed
Exit condition User enter another word or choose another dictionary
Table 6 Use case description for search definition
26 | P a g e
Use case name: View image
Identifier UC4
Description: This use case is used to view images
Trigger: When the user presses the image button
Preconditions: The definition of the word should be displayed
Basic course of action: Step 1.the dictionary user presses the image button
Step 2.the system download the image from the file server
Step 3.Image displayed on the image view
Alternative action:
1.4 If image is not found, the system displays error message
Extends: Uc2
Includes: --
Post condition: Audio downloaded
Table 7 Use case documentation for view image
27 | P a g e
Use case name: Listen pronunciation
Identifier UC3
Description: This use case is used to listen pronunciation of definitions
Trigger: When the user presses the audio button
Preconditions: The definition of the word should be displayed
Basic Course of Events: Step 1.the dictionary user presses the audio button
Step 2.the system download the audio from the file server
Step 3.The user listens the pronunciation of the definition
Alternative Paths:
1.3 If the audio is not found, the system displays error message
Extends: UC2
Includes: --
Post condition: Audio downloaded
Table 8 Use case documentation for listen pronunciation
28 | P a g e
3.11.3 Sequence diagram

Sequence diagrams are an easy and intuitive way of describing the behavior of a system by
viewing the interaction behavior of the system and its environment. A sequence diagram shows
an interaction among objects in a time sequence. It shows the object participating in the
interaction by their lifelines and the messages they exchange arranged in time sequence.
A sequence diagram has two dimensions:
1. Vertical dimension –represent time.
2. Horizontal dimension represents different objects.
The vertical line is called the object life line. The life line represents the objects during the
interaction an object is shown as a box at the top of a dashed vertical line. However a sequence
diagram does not show the relationship among the roles (or) the association among the objects.
Each message is represented by an arrow between the lifelines of two objects. The order in
which these messages occur is shown top to bottom on the page. Each message is represented by
an arrow between the lifelines of objects. The order in which these messages occur is shown top
to bottom on the page. Each message is labeled with the message that an object sends to itself by
sending the message arrow back to the same lifeline.
The sequence diagram is very simple and has immediate visual object appeal. This is its great
strength. It is an alternative way to understand the overall flow of the control of a program.
Instead of locking at the code and trying to find out the overall sequence of behavior, we can use
diagram to quickly understand the sequence. [http://www.studentcpu.com/2009/12/sequence-
diagram-for-dictionary-system.html]
29 | P a g e
Figure 6 sequence diagram for choose dictionary
30 | P a g e
Figure 7 Sequence Diagram for search meaning
31 | P a g e
Figure 8 sequence diagram for listen pronunciation
32 | P a g e
Figure 9 sequence diagram for view image
33 | P a g e
3.11.4. Activity diagram

The purpose of the activity diagram is to model the procedural flow of actions that are part of a
larger activity. In projects in which use cases are present, activity diagrams can model a specific
use case at a more detailed level.
Figure 10 Activity diagram for select dictionary
34 | P a g e
Figure 11 Activity diagram for select dictionary
35 | P a g e
Figure 12 Activity diagram for Listen to pronunciation
36 | P a g e
Figure 13 Activity diagram for view image
37 | P a g e
3.11.5 Class Diagram

A class diagram is a component of unified modelling language that shows level of
association among classes and objects. It also shows multiplicity associations, that means
how many objects participate on the association. Class diagram shows the role of objects
or classes and aggregations. Class diagrams also describe the structure of the system in
terms of classes and objects. Classes are abstractions that specify the attributes and
behaviors of a set of objects.
Objects are entities that encapsulate state and behavior each object has an identity.
Figure 14 Class diagram for mobile dictionary applications
38 | P a g e
CHAPTER FOUR
4. SYSTEM DESIGN
4.1 Introduction
This chapter contains different tools and techniques to model the design of the project.
Purpose of designing is to show the direction how this system built and to provide clear
and enough information needed to drive the actual implementation of the system. It is
based on understanding of the model the software built on. The objective is to model the
system with high quality since the implementations of high quality system depend on the
nature of design created by the designing phase.
4.2 Design Goals

The objectives of designing are to model a system and subsystems diagrammatically.
Implementing of the system depends on the nature of the design created by the designer .If one
wants to make changes to the system after it has been put in to operation depends on the quality
of the system design. So if the system is designed perfectly, it will be easy to make changes to it.
The application is expected to run on smart phones that can run on the Android platform or
operating system. Therefore, the design goals criteria stated in this section consider this fact to
determine the performance, dependability, cost, maintenance and end user criteria.
The goal of the system design is to manage complexity by dividing the system in to
manageable pieces.
Some of the goals are listed below.
 Security: The system should be secured from unauthorized user.
 Modifiability: The system should have modifiability to modify different services
depending on the need of the organization.
 Flexibility: The system able to change to suit new condition or situation.
 Efficiency: The system must do what it is supposed to do efficiently without
problem.
4.2.1 Performance Criteria

Since the system is designed to be accessed by different users with different needs, it is
capable of handling and processing their queries quickly. Many users will be using the
39 | P a g e
system at a time simultaneously. However, if the system is being accessed by many, all
the users must feel that they are the only one using the system.
 Response time: the response time for searching definitions should be fast. To attain this
goal, coding should follow simple, efficient and fast algorithms. Especially looping
statements shall be avoided (if possible) or minimized. For example instead of using
loop for retrieving a specific record form a table use SQL statement.
 Memory: Since the memory of mobiles is small in size, size of the application should
not be large. To attain this store multimedia parts like pronunciation or audios on file
server and access them through internet
4.2.2. Dependability
 Reliability: The system shall be tested after and during development process to
verify that whether the specified services are available or not and also it should
give consistent and correct output for various type of input it is given.
 Availability: The multimedia contents shall be deployed on a file server that is
available 24hrs. Therefore sufficient [ample] care shall be taken when selecting the
deployment server.
 Fault Tolerance: Error handlers and Record Set control objects shall be used to
handle and tolerate fault that may arise during execution. For example, end of
Record Set shall be checked during traversing.
4.2.3 Maintenance Criteria

This system is designed using a latest software design technique (i.e. Object Oriented
Design Methodology). The approach we choose provides different facilities to maintain
the system when any problems are happen or upgrade the system easily and efficiently.
 Modifiability: In order to make the system flexible and easy to modify its functionality
some of its feature shall be modifiable.
 Portability: The application shall be developed to run on android environment therefore it
is not portable to run on any environment which is not android enabled.
 Readability: Coding shall incorporate significant and clear comments describing each
part of the code what it does and what its purpose is.
40 | P a g e
 Traceability of Requirement: The system shall be developed according to the system

analysis and the design specification and it shall not incorporate anything beyond.
Otherwise newly incorporated functionality shall be documented.
4.2.4 End-user criteria

 Usability: The application should be developed easier for user understanding. Especially
in developing the user interface it is better to keep the user dictionary in mind.
4.3 System Architecture

The aim of this application is to develop Android mobile dictionary application (Android-MD-
App) that will give Amharic- English, Amharic -Oromiffa, Amharic –Tigrigna, Amharic-Somali
and Amharic -Guragigna dictionary searching facilities for dictionary users. The definitions will
be stored locally in SQLite database which is a light weight database embedded in android SDK.
The application also will enable users listen to pronunciations of definitions and view images of
meanings.
The software architecture of the proposed system is a client-server architecture on which search
operation is performed by the mobile phone and the server used to store data but operations not
performed there but the client access data from server by using hypertext transfer protocol (http).
Thus the system shall be made up of the following components.
File Server: - This component of the system used to store pronunciations and images. The
mobile client get images and pronunciations of words by using image and voice URLs through
file transfer protocol (ftp).
Mobile client application: - This application is written in android SDK and can be installed in
android phones. It accepts words which entered by users and search from the local database and
display the meaning or definition of those words and downloads image and audio from the
multimedia file server when the dictionary user presses the image and voice button respectively
to the mobile client.
Data base application: - In this system we have one database, the mobile phone client local
database. This database is written for android phones and is stored in SQLite. It is used to store
words and their respective definitions and file names for images and audios that are stored in the
multimedia file server.
41 | P a g e
Figure 15 client server architecture
4.4. Subsystem Decomposition

The purpose of subsystem decomposition is to breakdown a given system into smaller systems,
which are loosely coupled with each other while each broken-down system has strong cohesion
among its components. In order to simplify and minimize the complexity of the solution domain,
the proposed Android mobile dictionary application is decomposed into four subsystems namely
Layout subsystem, Search subsystem, Dictionary subsystem and Server subsystem.
42 | P a g e
Each subsystem has its own function and there is also communication among them to exchange
information. The system is decomposed according to the specialized task it performs to ensure
high coherence. The level of coupling is relatively low because the interactions between
subsystems are only exchange of data.
Layout Subsystem: - This subsystem is responsible for providing explanation and description
about the developed system to the target environment, and for the mapping of graphics onto the
device.
Search subsystem: - This subsystem deals with the search facilities of the system. It involves
the interaction of the dictionary users with the system to get definitions or meanings of words,
images and pronunciations. Therefore, this subsystem provides the following facilities.
 search Amharic to English, Amharic to Oromiffa, Amharic to Tigrigna, Amharic to
Somali and Amharic to Guragigna dictionaries
 Get pronunciation and image using image and audio URLs from server
Dictionary Subsystem: - In this system we have one database. It is the dictionary which is the
mobile phone client local database. It is written for Android phones and is stored in SQLite. It is
used to store definitions and file names of images and pronunciations.
Dictionary is responsible to maintain information for all Amharic to English, Amharic to
Oromigna, Amharic to Tigrigna, Amharic to Somali and Amharic to Guragigna data. It deals
with maintaining requirements of the system that is required to display dictionary data and it is
also responsible for upgrading the database version.
Therefore dictionary subsystem provides the facilities

 Maintain dictionary data - the system allow the users to view definition or meanings of
words for the four dictionaries
 Upgrade the database version if new version is available
Server Subsystem: - This subsystem is responsible for storing pronunciations and images. It can
be a desktop computer. The mobile client get images and pronunciations of words by using
image and voice URLs.
43 | P a g e
Figure 16 Subsystem decomposition for the Dictionary application

(Folders represent subsystems, dashed lines represent dependencies)
4.5. Deployment Diagram (hardware/ software mapping)

This portion of this document depicts the deployment of the components described above
diagrammatically. The two devices involved on the system, having deployed appropriate
components. Component diagrams can be embedded into deployment diagrams effectively.
44 | P a g e
Figure 17 Deployment Modeling for Dictionary application
45 | P a g e
Figure 18 Mapping of tables
46 | P a g e
4.6 Persistent Data Management

Persistence modelling is used to communicate the design of the database. It is also used to
describe the persistence data aspect of the system. In relational database, the schema is made up
of tables, consisting of rows and columns, where each column has a name, and simple data type.
A tuple (row) of a table contains data for a single entity that correlates to an object (instance of
class) in an object oriented system. In addition to this the mapping essential to object and
relational integration are between a table and a class, between columns and attributes, between a
row and an object, and between stored procedure and method. Persistence models in our system
are used to communicate the design of database. In the following diagram the five classes have
one-to-one relation with the image class. Because a word may have different meanings with
different languages but it has one image for that word if the word is noun. For example the word
Elephant has different meanings with different languages but the image is the same.
Figure 19 persistent data of mobile dictionary systems

References
[1] Webster’s New World College Dictionary, Fourth Edition, 2002
47 | P a g e
[2] Sterkenburg 2003, pp. 155–157
[3] Sterkenburg 2003, pp. 3–4
[4] Sterkenburg 2003, p. 7
[5] R. R. K. Hartmann (2003). Lexicography: Dictionaries, compilers, critics, and users. Rout
ledge. P. 21ISBN 978-0-415-25366-6
[6] http://en.wikibooks.org/wiki/Android/Introduction Visited 03 December 2012
[7] http://en.wikipedia.org/wiki/Dictionary#Specialized_dictionaries
Visited 26 November 2012
http://www.uml-diagrams.org/use-case-diagrams-examples.html
Visited 05 December 2012
http://www.tutorialspoint.com/white-papers/uml-for-objective-c.htm
Visited 07 December 2012.
http://vinci.org/rlv/d/uml/deploymentx.html
Visited 08 January 2013 .
http://en.wikipedia.org/wiki/Object-oriented_programming
Visited 25 November 2012
Proceedings of the 1st EICTF October 27, 2011 Addis Ababa, Ethiopia
http://www.cs.vu.nl/~eliens/oop/1-3.html Visited 03 December 2012
48 | P a g e

Full Doc MBDA

Uploaded by

Document Information

Original Description:

Original Title

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

Full Doc MBDA

Uploaded by

Copyright:

Available Formats

Multi Lingual Android Mobile Dictionary Application

MOBILE DICTIONARY APPLICATIONS FOR

JIGJIGA UNIVERSTY COLLEGE OF ENGINEERING AND

Jigjiga Ethiopia 4 February 2016

Advisor: Mohamed Daud Signature ………Date………….

List of Figures ................................................................................................................................ V

List of Table .................................................................................................................................. VI

Content List .................................................................................................................................. VII

CHAPTER ONE ............................................................................................................................. 1

1.1 Background and Introduction .............................................................................................. 1

1.1.1 Introduction ..................................................................................................................................... 1

1.3 Objective Of The project ........................................................................................................ 3

1.3.1 General Objective ............................................................................................................................ 3

1.4.1. Project scope................................................................................................................................... 3

1.5.1 Data collection ............................................................................................................................... 4

1.7 Risk assessment and management ............................................................................................ 6

1.8 Operating and Development Environment ............................................................................. 7

1.9 Budget and Time breakdown .................................................................................................. 11

1.9.1 Budget ............................................................................................................................................ 11

1.9.2. Time schedule ............................................................................................................................... 11

2. DESCRIPTION OF THE EXISITING SYSTEM .................................................................... 13

2.1. Introduction ............................................................................................................................ 13

2.2. The main activities ................................................................................................................. 13

2.3. Functions of the existing system ............................................................................................ 13

2.4. Players of the existing system ................................................................................................ 13

2.5. Report generating in the existing system ............................................................................... 14

2.6. Documents used in the existing system ................................................................................. 14

2.7. Weakness of the existing system ........................................................................................... 16

2.7 Strength of the existing system ............................................................................................... 16

2.8 Feasibility study................................................................................................................................. 16

CHAPTER THREE ...................................................................................................................... 19

3. Requirement Specification and Analysis .................................................................................. 19

3.1. Introduction ............................................................................................................................ 19

3.1.1. Purpose ......................................................................................................................................... 19

3.3. Functional requirement .......................................................................................................... 20

3.4. Product prospective ................................................................................................................ 21

3.5. Product function ..................................................................................................................... 21

3.6. Principal actors....................................................................................................................... 21

3.7 User Characteristics ................................................................................................................ 21

3.8 General Constraints ................................................................................................................. 21

3.9 Assumptions and Dependencies ............................................................................................. 22

3.10 Non-functional Requirements ............................................................................................... 22

3.11. System model ....................................................................................................................... 23

3.11.1 Use case diagram ......................................................................................................................... 23

4. SYSTEM DESIGN ................................................................................................................... 39

4.1 Introduction .................................................................................................................................... 39

4.2.1 Performance Criteria...................................................................................................................... 39

4.4. Subsystem Decomposition ..................................................................................................... 42

4.5. Deployment Diagram (hardware/ software mapping) ........................................................... 44

4.6 Persistent Data Management................................................................................................... 47

dictionaries. The word dictionary (unqualified) is usually understood to refer to a monolingual

1.2 Statement of The problem

1.3 Objective Of The project

1.3.2 Specific Objective

1.4 Project Scope and Limitation

 Enable users to search meanings

1.4.2. Project Limitation

1.5.1 Data collection

1.5.2 Analysis and Design

1.5.3 Development tools

1.6 Significance of the project

1.7 Risk assessment and management