ABECS Proposal

[Android Based Ethiopian Calendar System]
A Senior Project Documentation Submitted to Debre Berhan University in Partial

Fulfilment of the Requirement for the Degree of Bachelor of Science in Information
Technology
By
Supervised by Mr. Henok E. (Msc.)
Department: Information Technology
College of Computing, Department of Information Technology, Debre Berhan University,

Debre Berhan, Ethiopia
August 2016
Approval
The Project is our own and has not been presented for a degree in any other university with this
functionality and all the sources of material used for the project/thesis have been duly acknowledged.
Name signature
1. Ibrahim Ahmed ……………………………………………………
I
2. Jemal Julla ……………………………………………………
3. Kasayanesh Demie ……………………………………………………
4. Tsegaye Tamiru ……………………………………………………
5. Habtamua Yeshidagna ……………………………………………………
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 project for the degree of Bachelor of Science.
…………………………… ……………………………………….
Name of Advisor Signature
Examiner Name Signature
1. Examiner 1 …………………………………. ………………………
2. Examiner 2 …………………………………. ……………………….
3. Examiner 3 …………………………………… ……………………….
4. Examiner 4 …………………………………… ……………………….
Android Based Ethiopian Calendar System
Acknowledgement
First of all, we would like to thank our God, who gives us love, patience, healthy, wisdom and ability to
walk through all the problems and obstacles during the period of our study. Then we would like to thank
our advisor instructor Henok Ephrem. for their constrictive opinion and willingness to participate in
each part of our project and their effective direction, assistance and guidance for the accomplishing of
Debre Berhan University, 2008 e.c

II
this project. We also wish to thank the manager of Ethiopian Orthodox Church priests and other skilled
persons, who give us the required and adequate information about the calendar calculation.
Our Special thanks is to our group members, who had generously provided us their participation
for this Project. Finally, we would like to express love, thanks, appreciation, and respect to our families.
Lastly we thank the teaching staffs of Information Technology who have contributed wholly to the
success of this project.
Abstract
This is the document of the project for developing an Android Based Ethiopian Calendar System. It
consists of the current back ground of the calendar calculation and problems having due to present
system and how we are going to overcome those matters through our proposal system.
After gathering requirement, we have found that almost all Ethiopian people are using a manual file
based system for calendar calculation except those, who have PC (Personal computer) or some other
who use smart phone. However, the smart phone users do not use the full Ethiopian calendar because

III
they do not gate the well-developed app like this. The project aimed to build a fully functional system in
order to achieve the efficiency in the Calendar calculation and use.
In the system android applications is developed. The application takes most of the activities such as
offline calendar calculation and memorization. The Android Based Ethiopian Calendar System have an
unbelievable capacity to calculate the largest and largest years of fasting and holidays. It can calculate
the calendar of billions of billions years. We called it The Eternal Calendar System based it’s
characteristic.
Keywords: Android, system, Calendar, Calculation
Key words
Amete Alem Wenber Elete Tebiban
Wengelawi Medeb Phagumie
Metkie Atsife Awurah Hitsets
Abektie Tewusak

IV
V
List of Acronym and Abbreviations
BR ---------------------------------------------------- Business Rule
ABECS --------------------------------------------- Android Based Ethiopian Calendar System
GB ----------------------------------------------------- Giga Byte
GUI --------------------------------------------------- Graphical User Interface
RAM -------------------------------------------------- Random Access Memory
UC ----------------------------------------------------- Use Case
UML ------------------------------------------------- Unified Modeling Language
PDF----------------------------------------------------- Portable Document File
SRS----------------------------------------------------- Software Requirement Specification
HW ---------------------------------------------------- Hardware
ID --------------------------------------------------- Identification; Identity
UPS -------------------------------------------------- Uninterrupted Power supply
CD --------------------------------------------------- Compact Disk
DVD ----------------------------------------------------- Digital Versatile disk
CDRW ------------------------------------------------- Compact Disk Rewritable
EHM -----------------------------------------------------Exception Handling Mechanism
ODD------------------------------------------------------Object Design Decomposition
UI----------------------------------------------------------User Interface
OS --------------------------------------------------- Operating System
HD --------------------------------------------------- Hard Disk
VI
Table of Contents
Approval..................................................................................................................................................II
Acknowledgement..................................................................................................................................III
Abstract..................................................................................................................................................IV
Key words...................................................................................................................................................V
List of Acronym and Abbreviations.......................................................................................................VI
Chapter One.................................................................................................................................................1
1.1. Introduction.....................................................................................................................................1
1.2. Background of the Project...........................................................................................................1
1.3. Problem statement.......................................................................................................................1
1.4. Team Composition.......................................................................................................................2
1.5. Objectives of the project..............................................................................................................3
General objective...................................................................................................................................3
Specific objective...................................................................................................................................3
1.6. Scope and Limitation...................................................................................................................3
1.6.1. Scope...................................................................................................................................3
1.6.2. Limitation............................................................................................................................4
1.7. Significance of the project...........................................................................................................4
1.8. Beneficiaries of the project..........................................................................................................4
1.9. Methodologies.............................................................................................................................5
1.10. System analysis and design......................................................................................................5
1.11. Development Tools..................................................................................................................6
Programming language........................................................................................................................6
Additional tools...................................................................................................................................6
Tools used...............................................................................................................................................6
Software tools......................................................................................................................................6
Hardware Tools...................................................................................................................................6
Testing procedures...................................................................................................................................7
1.14 Implementation................................................................................................................................7
1.15 Risks & contingencies.....................................................................................................................7
1.12. Project Plan..............................................................................................................................8
1.13. Team role and responsibilities..............................................................................................8
Page VII of LXXXII

Chapter Two: Description of the Existing System.......................................................................................9
2.1. Introduction......................................................................................................................................9
2.1.1. Overview...................................................................................................................................9
2.2. Players in the existing system.........................................................................................................15
2.2 Major functions of the Existing system......................................................................................15
2.3 Business rules............................................................................................................................16
2.4 Report generated in existing system..........................................................................................16
2.5 Forms and other documents of the existing system....................................................................16
2.7 Bottlenecks of Existing system........................................................................................................17
2.8 Practice to be preserved...................................................................................................................19
2.9 Alternative solutions..................................................................................................................19
2.10. Requirements of the Proposed Software.......................................................................................19
2.10.1 Functional Requirement..........................................................................................................19
2.10.2 Nonfunctional requirement.....................................................................................................20
Chapter Three: 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....................................................................................................................26
See holy days and fasting days..................................................................................................................26
See basic information’s of the year............................................................................................................27
See 33 The Gregorian Calendar.................................................................................................................27
See fixed holy days and fasting days.........................................................................................................28
3.1.4 Object model................................................................................................................................29
3.1.4.1 Data Dictionary......................................................................................................................29
3.1.4.2 Analysis level Class Diagram (Conceptual Modeling)..............................................................30
3.2. Dynamic model..............................................................................................................................30
3.2.1 Sequence Diagram....................................................................................................................30
3.2.2 Activity Diagram......................................................................................................................32
3.2.3 State Diagrams..........................................................................................................................35
3.2.4 User interface (navigational paths and screen mock-ups).........................................................39
3.2.5 Supplementary Specifications...................................................................................................40
Page VIII of LXXXII

1. Functionality..................................................................................................................................40
2. Usability........................................................................................................................................40
3. Reliability..................................................................................................................................40
4. Performance...............................................................................................................................40
5. Design Constraints.....................................................................................................................41
Chapter Four: System Design...................................................................................................................42
4.1 Introduction...................................................................................................................................42
4.1.1 Purpose of the system............................................................................................................42
4.1.2 Design goals..........................................................................................................................42
4.2 Current software architecture.........................................................................................................43
4.3. Proposed system software architecture...............................................................................................43
4.3.1. Overview.....................................................................................................................................43
4.3.2. Subsystem decomposition......................................................................................................44
4.3.3 Hardware/software mapping..................................................................................................47
4.3.4 Persistent data management...................................................................................................47
4.3.4.1 Mapping.................................................................................................................................49
4.4.3.4.2 Database Design.....................................................................................................................49
4.3.5 Access control and security....................................................................................................49
4.3.6 Global software control..........................................................................................................49
4.3.7 Boundary Conditions....................................................................................................................50
4.4 Sub system services...................................................................................................................50
4.5 Component Diagram........................................................................................................................50
4.6. Deployment Diagram......................................................................................................................51
Chapter Five: Object Design..................................................................................................................53
5.1 Introduction...............................................................................................................................53
5.2 Object Design trade-offs..................................................................................................................53
5.3 Interface documentation guidelines.................................................................................................54
5.3 Packages....................................................................................................................................56
5.5 Class Interfaces................................................................................................................................56
Chapter Six: Implementation and Testing............................................................................................58
6.1 Introduction.....................................................................................................................................58
6.2 Final Testing of The system.............................................................................................................58
Page IX of LXXXII
6.3 Hardware Software Acquisition.......................................................................................................58
6.4 User Manual Preparation.................................................................................................................58
6.4.1 The manual for Ethical application....................................................................................58
6.5 Training...........................................................................................................................................61
6.6 Installation Process..........................................................................................................................62
6.8 Coding...........................................................................................................................................62
Android - XML...................................................................................................................................62
Android-Java code............................................................................................................................66
Chapter Seven: Conclusion and Recommendation...............................................................................68
7.1 Conclusion.......................................................................................................................................68
7.2 Recommendation.............................................................................................................................68
Appendix...............................................................................................................................................69
Reference..............................................................................................................................................70
Conclusion.................................................................................................................................................71
Reference...................................................................................................................................................72
Page X of LXXXII
List of Tables
Table 1.1.1 Team composition....................................................................................................................2
Table 1.1.2 Project time line........................................................................................................................8
Table 2.1 Tewusak of days.........................................................................................................................12
Table 2.2 Tewusak of fasting and holidays................................................................................................13
Table 3.1 Scenario.....................................................................................................................................22
Table 3.2 use case description...................................................................................................................26
Table 4.1 Access control and security........................................................................................................49
Table 5.1 interface documentation guidelines..........................................................................................54
Page XI of LXXXII
List of Figures
Figure 1 Team role...........................................................................................................................8
Figure 2 General process of manual Calendar...............................................................................16
Figure 3 Calculate holidays use case.............................................................................................24
Figure 4 use case for Basic information of the year......................................................................25
Figure 5 Use case for Fixed holidays and fasting..........................................................................26
Figure 6Analytical class diagram..................................................................................................30
Figure 7 Sequence Diagram: Basic Information Sequence Diagram............................................31
Figure 8 Sequence Diagram: Fixed Holy and Fasting Days..........................................................31
Figure 9 Sequence Diagram: Holy Days and Fasting Date...........................................................32
Figure 10 Display basic information’s of the year activity diagram.............................................33
Figure 11 Display holy days and fasting days of activity diagram................................................34
Figure 12 Fixed holy days and fasting days’ activity diagram......................................................35
Figure 13 State chart diagram for View Holydays and Fasting.....................................................35
Figure 14 State chart diagram for Display Calendar.....................................................................36
Figure 15 State chart diagram for Display Holy Days and Fasting...............................................36
Figure 16 State chart diagram for Day of the Date........................................................................37
Figure 17 State chart diagram for Display Fixed Holydays and fasting........................................37
Figure 18 State chart diagram for Gregorian Date........................................................................38
Figure 19 User Interface................................................................................................................39
Figure 20 System Software architecture........................................................................................43
Figure 21 Subsystem decomposition.............................................................................................44
Figure 22 Hardware/Software mapping for ABEC.......................................................................47
Figure 23 Persistent data management..........................................................................................48
Figure 24 mapping for ABECS......................................................Error! Bookmark not defined.
Figure 25 Component diagram for ABECS...................................................................................51
Figure 26 Deployment Diagram for ABECS.................................................................................52
Page XII of LXXXII

Chapter One
1.1. Introduction
Ethiopian has own calendar and the stream of this calendar was Ethiopian Orthodox Tewahido
church. The chronology of the calendar follows the Era of Incarnation that is it dates from our
Lord’s birth; there is a difference of 7 or 8 years between the western and Ethiopian systems.
Because the Ethiopian church holds that our Lord was born 5500 years after the creation of the
world this gives the 7 or 8 years’ difference between the Gregorian and Ethiopian Chronologies.
The church uses the spiritual firmament book called Ethical; It is used to get the Ethiopian
Orthodox Tewahido Church fasting dates & Holidays, basic information in calculating calendar
of the church, specific date in Ethiopian calendar, public holydays and constant holy and fasting
dates. This performs many types of calculations such as finding ametealem (year of creation),
wengelawi, metenerabiet, finding new year (meskerem1 or enkutatash), finding medeb and
wenber; finding abektie and metqi, finding bealemetqi and mebaja hamer. These calculation is
performed by using manually. Those calculation is very ambiguous and time consume.
1.2. Background of the Project

Based on the problems we observe, we proposed Android Based Ethiopian Calendar mobile
application. The application is developed specially to meet the needs of the android mobile users.
Ethical mobile application performs find and display holy days and fasting, basic information’s
of the year, public holydays, fixed holy days and fasting. This application can use to access
easily in a specified period of time. This project introduces this Ethiopian Orthodox Church
calendar as public calendar and allows android (smart phone) users to install and use it easily.
1.3. Problem statement

The existing Ethiopian Calendar fasting and holyday calendar is calculated by using manually.
This leads the following Problems
It requires professional person
As we mention above to get different types of fasting and holy days it requires deferent types of
calculation. This calculation must be performed by pops and priests.
Inefficient use of time and resource.
Page 1 of 82
Because of the system is manually all of the work performed using pen and paper so this takes a
lot of time to do a calculation in a given period of time. For example, 1wenber is obtained by
subtracting 1 from 2Medeb and is useful for finding 3Metqi and 4Abektie which are used in
calculating fasting dates and holidays.
Inappropriate cost
As we mention the above all calculation performed by pen and paper. This lead the user to
inappropriate cost.
1.4. Team Composition

Table 1.1 Team composition
No. Name Task
1. Ibrahim Ahmed Title selection, Project proposal, requirement

analysis and design, coding.
2. Jemal Julla Title selection, Project proposal, requirement

3. Kasaynesh Demie Title selection, Project proposal, requirement

4. Tsegaye Tamiru Title selection, Project proposal, coding, requirement

analysis and design.
5. Habtamua Yeshidagna Title selection, Project proposal, requirement

elicitation, requirement design, coding.
Page 2 of 82
1.5. Objectives of the project
General objective
The general objective is to developed Android Based Ethiopian Calendar mobile application that
is free from any repetitive work, error, confusion, complexity and to give accurate service within
a period of time.
Specific objective
The specific objectives of the project are listed as follows.:
Perform a requirement analysis to find out the system functional and nonfunctional
requirements.
Design the system using object-oriented models for understanding the system and to
make the implementation easy.
Design the proposed System using UML diagram.
Design a user Interface for the proposed system.
Implement the Android application using Eclipse (adt-bundle-windows-x86-20130729).
Test the proposed system using different testing mechanisms.
1.6. Scope and Limitation of the project

1.6.1. Scope
The application will perform the following things:
Display the calendar of the input year in tabular form.

Convert Ethiopian calendar to Gregorian
Calculate and display holy days and fasting.
Calculate and displays basic information’s of the year.
Displays fixed holy days and fasting.
Enable the user to memorize the past and coming days of the week as Monday,
Tuesday …and so forth. This functionality requires the year, the month and the date
of the month as an input. After wards the system will automatically calculate and
display the result day of the week.
The limitation of our project is:
Page 3 of 82
The application will be developed only for android mobile user.
It does not calculate the Islamic calendar
The application work only in Ethiopian calendar.
The application does not initiate from the system date time.
1.7. Significance of the project

The significance of the project is listed as follows: -
Used to memorize historical days and events
Information can be gained easily.
Minimize the work load and time consumption.
It helps the user to easily access fasting and holy day information.
It helps them to share accurate and consistent information.
Minimizes resource and unwanted cost.
It helps to avoid miscalculation for fasting and holyday.
Easily know when start and end the fasting.
1.8. Beneficiaries of the project

Ethiopian people
Accurate and consistent information will be gain about fasting and holy day.
It will minimize inappropriate cost.
Minimize time consumption.
Minimize work load.
Improve self-decision making.
The developers
This project helps our team in developing a host of skills that are increasingly important in the
professional world positive group experiences, moreover, have been shown to contribute to us
learning about Ethiopian Orthodox Tewahido church fasting and holy day calendar. Like: -
Tackle more complex problems by ourselves.
Delegate roles and responsibilities.
Share diverse perspectives.
Pool knowledge and skills.
Hold one another (and be held) accountable.
Receive adviser and teachers support and encouragement to take risks.
Develop new approaches to resolving differences.
Page 4 of 82
Establish a shared identity with group members.
Improves our communication skill and team work.
Improve our knowledge in developing a system.
1.9. Methodologies
The methodology we will follow to gather information is by visiting the existing different books.
The methods that we are going to follow to collect data are as follows:
Interview: we will gather information about the Ethiopian orthodox Tewahido
church fasting and holy day calendar by interviewing different priests and deacons of
the Ethiopian orthodox Tewahido church.
Document analysis: we will try to see different type of Books like Abushaher,
Ethical, Bible, etc…
1.10. System analysis and design

In the development process of the project we will use object oriented approach. Because OOP
applications are easier to maintain, have more reusable components, and are more scalable, to
name a few.
Maintainable: OOP methods make code more maintainable. Identifying the source of errors
becomes easier because objects are self-contained (encapsulation).
Reusable: Because objects contain both data and functions that act on data, objects can be
thought of as self-contained “boxes” (encapsulation). This feature makes it easy to reuse code in
new systems.
Scalable: OO applications are more scalable then their structured programming roots. As an
object’s interface provides a roadmap for reusing the object in new software, it also provides you
with all the information you need to replace the object without affecting other code. This makes
it easy to replace old and aging code with faster algorithms and newer technology. By this
reasons we choose OOP for the development of the system.
1.11. Development Tools

Programming language
 Android-Eclipse (adt-bundle-windows-x86-20130729)
Page 5 of 82
Additional tools
Emulator
Microsoft office word 2016
Adobe Photoshop CS6
Blue stacks application player
Tools used
Software tools
Microsoft office word: - It is very useful because it takes less time to write and format the text,
communicative effectively smart diagram and chart tools, quickly assemble document. By
looking its useful properties, we use Microsoft office word to type our project work to get all the
above benefits of it.
Power point: -use to present the document in abstract forms. We use it to present our
presentation in short and brief way.
E-draw Max application for UML diagrams (for use case diagram, sequence diagram, class
diagram, Activity diagram, State chart diagram, component and deployment diagram).
Android-Eclipse: -software to design the proposed system. It is a multi-language integrated

development environment (IDE) comprised a base workspace and an extensible plug-in system
for customizing the environment.
Hardware Tools
Different hardware used to develop our project
Computer: -computer is a machine capable of doing many things. We use it to type on it and
install all software and programming language. Almost all tasks are done on computer.
Android based devices: - like smart phones and personal digital assistance, emulator, Blue stacks
to test the software we will develop.
Flash Disk and CD Hardware: - used for the movement of data from one machine to another.
We use both of them when we move our data from one machine to another.
Page 6 of 82
Testing procedures
We will use two different methods of testing technique.

Black box testing
The technique of testing without having any knowledge of the interior workings of
the application is Black Box testing. The tester is oblivious of to the system architecture and does
not have access to the source code. Typically, when performing a black box test, a tester will
interact with the system's user interface by providing inputs and examining outputs without
knowing how and where the inputs are worked upon.
White box testing

White box testing is the detailed investigation of internal logic and structure of the
code. White box testing is also called glass testing or open box testing. In order to perform white
box testing on an application, the tester needs to possess knowledge of the internal working of
the code. The tester needs to have a look inside the source code and find out which unit/chunk of
the code is behaving inappropriately.
1.14 Implementation
Prototype is divided into one phase: interface implementation, and logical implementation. In
interface implementation, we have tried to implement user- interface
1.15 Risks & contingencies

During the development of the project there may be different problems that we may face. These
are:
Unfortunate failure of system: To handle this problem the teams have some method to
resist not completely but partially by using back up mechanisms using flash disks,
CD/DVD and by storing the data on our Email account.
Power problem: we tried to use UPS to cover the gap happened to our project during
power failure.
Virus attack: It is difficult to control data from virus but try to scan the data, installing
and updating antivirus software and we use CDRW instead of flash.
Time management problem: we solve this problem by working cooperatively, divide
our time by schedule for each phase of the project and we try to use this schedule
effectively.
Page 7 of 82
Health problem: One of our group member might sick and we can’t cover his/her
responsibility.
1.12. Project Plan

Table 1.1 Project time line
No Task Start date (E.C) End date (E.C)
1 Feasibility study 12/12/2008 15/12/2008
2 Requirement elicitation 16/12/2008 19/12/2008
3 Requirement analysis 20/12/2008 25/12/2008
4 Designing diagrams and models 26/12/2008 30/12/2008
5 Implementation 12/2/2009 30/10/2009
1.13. Team role and responsibilities

Project Team Role and Responsibilities
Requirements Gathering System Design Implementation
Responsible person: Responsible person: Responsible person:

Ibrahim Ahmed Jemal Julla Kassynesh Deme
+ + +
Habtamua Yeshiwas Tsegaye Tamiru Tsegaye Tamiru
Figure 1.2 Team role
Chapter Two: Description of the Existing System

2.1. Introduction
The study of the existing system in detail is important to determine how it works and
improvement of the existing system. In this phase the following points are discussed.
Page 8 of 82
2.1.1. Overview
The Ethiopian Orthodox Tewahido church has its own calendar to perform the following
activity:
To calculate starting and ending fasting date.

To determine holy day.
To calculate 33 holy days of Virgin Saint Mary. However, we ignore the third function
because of the diversity of the Ethiopian people and their religious.
The following calculation is performed before to determine different type of fasting and holy
days.
Finding AmeteAlem(year of creation) and Wengelawi

AmeteAlem(year of creation) is the sum of the number of years before birth of Jesus Christ and
after the birth of Christ. The years before the birth of Christ (5500years) are called zemene_Fida,
zemene_kunenie or zemene_Bluy . But the years after are as a whole is called Amete_mihiret,
zemene_siggawe, zemene_haddis or zemene_mesih. The formula is as follows:
AmeteAlem = zemene_Bluy + zemene_haddis.
Example:-In 2009 E.C. AmeteAlem=5500+2009=7509. Wengelawi means writers of gospel. The

years are named after the four apostles, namely Mathewos (Mathew), Markos (Mark), Lukas
(Luke) and Yohannes (John). To get the Wengelawi divide AmeteAlem by four and if the
remainder is: -
 1, then it is Mathewos.
 2, then it is Markos .
 3, then it is Lukas .
 0, then it is Yohannes .
The quotient without the remainder is called MeteneRabiet.

Example:-In 2009 E.C(7509/4)=1877 remaining 1 Remainder 1 implies the Wengelawi is
Mathewos. And 1877 is MeteneRabiet.
Finding New year (Meskerem 1)
Page 9 of 82
To know the date the new year starts, add AmeteAlem(year of creation) and Metene Rabiet then
divide by 7.The remainder is given the name Tinte Qemer. Tinte Qemer is the first Tuesday at
which the numbers were begun.
If TinteQemer is: -
 0, then the New Year starts at Monday.

 1, then the New Year starts at Tuesday.
 2, then the New Year starts at Wednesday.
 3, then the New Year starts at Thursday.
 4, then the New Year starts at Friday.
 5, then the New Year starts at Saturday.
 6, then the New Year starts at Sunday.
Example:-In 2009E.C, (Recallthat AmeteAlem is 7509) ((7509+1877)/7) =1340 remaining 6

which is Tinte Qemer. Therefore, the year starts on Sunday (Meskerem 1).
Finding Medeb and Wenber
Medeb is obtained from the remainder of AmeteAlem(year of creation) divided by19(Nius-

kemer).
Wenber is obtained by subtracting 1 from Medeb and is useful for finding Metqi and Abektie
which are used in calculating fasting dates and holidays.
Example:-In 2009,
(7509/19)=395 remaining 4.
Therefore, Medeb of the year is 4 and Wenber is 4-1 = 3.
Note
 If remainder is 0, Medeb is 0 and Wenber is 18.

 If remainder is 1, Medeb is one and Wenber is 0.
Finding Abektie and Metqi
Page 10 of 82
Multiplying Wenber by 11 and if the product is greater than 30, it is then divided by 30.The
remainder in the division is called Abekte.
Note that for products less than 30 the product itself is taken as the Abekte value.
Similarly Metqi is obtained by multiplying Wenber by 19 and taking the remainder of the
quotient in dividing the product by 30.If the product is less than 30 the product itself will be the
Metqi of the year.
Example:-In 2009 E.C,
(3*11)/30=1 with remainder 3.This implies Abektie=3.
(3*19)/57=1 with remainder 27.This implies Metqi=27.
Note
Always Metqi + Abektie=30
If Abektie is 0 Metqi is 30
Finding BealeMetqi and Mebaja Hamer
Metqi is used to obtain fasting dates and holidays of the Ethiopian Orthodox Tewahido Church.
Beale Metqi is the date assigned by Metqi.
 If Metqi is greater than 14, then Beale-Metqi is in Meskerem (from Meskerem 15-30)
 If Metqi is less than 14, then Beale-Metqi is in Tikimt (from Tikimt 1-13)
NB: - Metqi cannot be 14. It cannot also be 1, 3, 6, 9, 11, 17, 20, 22, 25 and 28. There are only
19 numbers.
 If Beale-Metqi is in Meskerem, fasting date for Nineveh is in Tir.

 If it is in Tikimt, Nineveh is in Yekatit
 But if Beale Metqi is in Meskerem and it is added with Tewsak of the day to be greater
than 30, then Neneveh is in Yekatit by taking the extra days above 30.
If Beale Metqi is in Saturday, the number of days between the next day of Beale Metqi and
Nineveh is 128. 128 divided by 30 gives remainder 8. This remainder is called Tewsak of the
Saturday (Tewsak of the day). Similarly, the Tewsaks of the week are shown in the following
table:
Page 11 of 82
Table 2.1 Tewusak of days
Day NO of days up to Nenewa Tewsak of the day
Sunday 127 7
Monday 126 6
Tuesday 125 5
Wednesda 124 4
y
Thursday 123 3
Friday 122 2
Saturday 128 8
Mebaja Hamer is obtained by adding Beale Metqi and Tewsak of the day of Beale Metqi. If the
result is greater than 30 as usual the remainder is taken.
Example:- In 2009 E.C,
we saw that Metqi is 27.This implies that Beale Metqi is Meskerem 27 Since Meskerem 27 is
Friday, Meskerem 1 is Sunday ,Meskerem 8 is Sunday, Meskerem 15 is Sunday, Meskerem 22 is
Sunday, Meskerem 29 is Monday and, Meskerem 27 is Friday (go back two days).
Mebaja Hamer=27 + Tewsak of Friday=27+2=29.
Finding holy days and fastings
To obtain Fasting dates, first it is necessary to get the date for Neneveh. Neneveh fasting date is
directly the Mebaja Hamer number. The month is obtained by the rules indicated above for Beale
Matqi. i.e.
 If Matqi is above 14, Beale Matqi is in Meskerem then Neneveh is in Tir.

 If Matqi is below 14, Beale Matqi is in Tikimt then Neneveh is in Yekatit.
Tewsak of fasting dates and holydays are the number of days from the next day of Neneveh up to
Page 12 of 82
the date of that fasting (entrance date) or holiday.
If it is greater than 30, it's divided by 30 and the remainder will be Tewsak
Example:-For Debre zeit, the number of days after Neneveh is 41,
41/30=1 with remainder 11.
Therefore, the Tewsak of Debre zeit is 11. Similarly, Tewsaks of the fasting dates and holidays
are shown below.
Table 2.2 Tewusak of fasting and holidays
Fasting dates and holidays Tewsak
Abiy Tsome 14
Debre zeit 11
Hosanna 2
Good friday 7
Tinsaye 9
Rkbe Kahnat 3
Ascension 18
Paraclet 28
Fasting of Holy Apostles 29
Weekly fastiner 1
NOTE:-Neneveh doesn't have Tewsak.

Fasting dates & Holydays are obtained as follows:
 To obtain Neneveh directly take the Mebaja Hamer number as the date and the month as
explained above rule following the rules for Matqi and Beale Matqi.
 To obtain Abiy Tsome, Count 14 days after Neneveh.
 To obtain Debre zeit, Count 41 days after Neneveh.
 To obtain Hosanna, Count 62 days after Neneveh.
Page 13 of 82
 To obtain Good Friday, Count 67 days after Neneveh.
 To obtain Tinsaye, Count 69 days after Neneveh.
 To obtain Rikbe Khahnat, Count 93 days after Neneveh.
 To obtain Ascension, Count 108 days after Neneveh.
 To obtain Paraclet, Count 118 days after Neneveh.
 To obtain Fasting of Holy Apostles, Count 119 days after Neneveh.
 To obtain Weekly fastiner, Count 121 days after Neneveh.
Finding TinteOn and Specific days of the Dates
Finding TinteOn
TinteOn is the first Wednesday in which Sun, Moon and Stars were created. Add AmeteAlem &
Metene Rabiet and divide the sum by 7. Then remainder minus one gives TinteOn.
If TinteOn is
 1 then Meskerem 1 is Wednesday.

 2 then Meskerem 1 is Thursday.
 3 then Meskerem 1 is Friday.
 4 then Meskerem 1 is Saturday
 5 then Meskerem 1 is Sunday
 6 then Meskerem 1 is Monday
 7 then Meskerem 1 is Tuesday
Example:-In 2009 E.C.
(1877+7509)/7=1340 remainder 6.Therefore, 6-1=5 is TinteOn and Meskerem1 is Sunday.
AtsfeAwrha is the 2 days remained when 30 days of the month are divided by 7.
Finding Specific days of the Date
(TinteOn+ AtsfeAwrha+date+2(is called Tebiban))/7 If the remainder is: - 1. Sunday 2.
Monday 3. Tuesday 4. Wednesday 5. Thursday 6. Friday 7. Saturday
Example:-Find the day of Hidar 29, 2009 E.C
[5+6 +2+9] / 7 = 3 remainder 2.Threfore Hidar 29 is Thursday.
Note: Hidar is the 3rd month in Ethiopian Calendar.
Page 14 of 82
Generally, the existing system performed the above calculation by using manually.
2.2. Players in the existing system

The players in existing system are the following:
Ethiopian orthodox Church priests: The professional skilled persons that help people by
calculating and declaring the holydays and fasting at every new year.
The people: People are the main user of the calendar, even Islam and other religious
followers too.
The Bahire-Hsab book: The book of firmament and calendar, that helps to find dates,
holydays, fasting and related fields.
Calendar Seller: the publisher and seller of paper calendar
2.2 Major functions of the Existing system

The existing system has the following functions
Calculating calendar –Even if it is manual, the current system provides the calendar
calculation system for public use using the Ethical book. Even if there are some people
who use android base Ethiopian calendar, it is not adequate to depict all intended
calculation.
Declaring new year and other festivals: The priests and the government declares as the
coming festival is a ceremony or public day.
Document collection: Document is being collected from the prepared report according to
their function and submitted time to allocated place (it may be shelf, depends on the
organization).
Printing Service: The calendar of each year is printed in document format.
The general activity of the existing system is depicted bellow. Question Belief Religious
Input Process Output
1.Question
1. Paper Calculation Full Calendar
2. Religious
Figure 2.3 General process of manual Calendar
Page 15 of 82
2.3 Business rules
The calendar has their own business rule that shows which actions should be done and which are
forbidden to do for all users.
BR1. All Ethiopians should know their own calendar.
BR2. Ethiopians should use their calendar
BR3. Ethiopian calendar is not only for Ethiopian Orthodox Church but for all Ethiopians.
2.4 Report generated in existing system

Report preparation and generation: In the existing system is being prepared in the form of paper
documentation from the calendar formulator or other priests. However, there are also some
Ethical applications and websites of Ethiopian calendar. But it is not adequate for all Ethiopians,
who has not PC (Personal Computer) and internet access.
2.5 Forms and other documents of the existing system

There are so many types of calendar documents; Some of the are listed below:
I. The Ethical Document

It is a paper format which is known as the origin of the Ethiopian calendar.
We take the Ethical Calendar book as an example.
II. Slip paper calendar document
It is a paper format used to depict the new year holydays and fasting.
III. Other Forms
There are also other forms for different activities.
2.7 Bottlenecks of Existing system

In the existing system calendar calculation is done manually which is time taking, exhausting
and has no accuracy. The whole information is done and stored using paper and suspension
filing system for a long period of time.
Performance
 Doing activities using manual document results week performance
Page 16 of 82
 Is time consuming
Information (and Data)
 Outputs
 Lack of any necessary or relevant information

 Too much information – information overload
 Information that is not accurate
 Information that is not timely to its subsequent use
 Inputs
 Data is not captured in time to be useful

 Data is not accurately captured – contains errors
 Data is difficult to capture
 Data is captured redundantly – same data is captured more than once
 Too much and/or illegal data is captured
 Stored Data
 Data is stored redundantly in multiple files

 Data is not secure from accident or vandalism (because data is stored in
paper)
 Data is not well organized
 Data is not flexible – not easy to meet new information needs from stored
data
Economics
 Costs
 Costs are too high (needs too much employee)
 Profits
 New Construction who have a system can be explored
 Current dealing can be improved to systemized
Page 17 of 82
 Control (and Security)
 Too little security or control

 Input data is not adequately edited
 Crimes (e.g. fraud, theft, embezzlement) are (or can be) committed
against the data
 Ethics are breached on data or information – refers to data or
information getting to unauthorized people
 Redundantly stored data is inconsistent in different files or databases
 Processing errors are occurring by people
Efficiency
 People waste time
 Data is redundantly input or copied and processed.
 waste holdings and manpower
 Effort required for tasks is excessive (too much workers)
 Holdings required for tasks is excessive (e.g. paper)
Service
 The Existing system produces inaccurate, inconsistent and unreliable results
 It is not easy and awkward to use
 It is difficult to coordinate with other systems
2.8 Practice to be preserved

The current calendar system has an experience to be encouraged or the strong sides of different
operation of services. They are:
Keeping the calendar system as the domestic resource
Teaching
Declaring the new year and holydays
Selling different books for Ethiopian calendar
Page 18 of 82
2.9Alternative solutions
In order to overcome the current system problems that exist in the functioning of ABECS, our
project team members have put down alternative options. These are:
Change manual system and Ethical application in to mobile based system without
affecting the structure of the existing system.
Fetching records from paper or Ethical application to the new system.
2.10. Requirements of the Proposed Software

The system that we are proposed Android Based Ethiopian Calendar System, will store all the
details of the calendar in to the mobile application. In addition to this our proposed system has
several advantages including: User friendly and responsive interface (it is compatible to mobile),
Fast access to database, no error, more storage capacity, search facility, look and feel
environment, Easy to handle and feasible, cost reduction, fast and convenient and accurate. After
maintaining this system, the above problems of the existing system will be completely solved
and means of displaying information is within a short period of time.
2.10.1 Functional Requirement

Generally, our system has the following functionalities
Accepting year; The system shall accept any year and display the intended output.
Display Holidays and fasting; The system shall display the holidays and fasting
for the inserted year when the ‘Fasting and holidays’ button clicked.
Display Basic information of the given year; The system shall display the basic
information of the year based on the Ethical calendar calculation.
Year Conversion; The system shall Convert the Ethiopian Calendar to Gregorian.
Offline task; The system shall need no network.
The Eternal service; The system displays the result for any of the years entered
from the user.:. Billion and billions of years
Serve as memories; The system should memories the past and tell the coming
specific days the user need. For instance, if the user intended to know “What is the
day of the 12th Jan 2017?” The system should display the exact day of the given
date such as “Sunday” or “Monday”.
Display the calendar of the year in tabular form; The system should depict the
calendar of the requested year in tabular form.
Page 19 of 82
Display the fixed holidays and fasting; The system shall display the fixed
holydays and fasting which are not flexible when the user selects the fixed button.
Help option; The Calendar system should provide the help option for the new
users “Hoe they should use?”.
Give Guidance; The system shall provide the written document that helps the new
and doyen users to calculate the calendar system in their own.
2.10.2 Nonfunctional requirement

The following are nonfunctional requirement:
Performance:
 The system shall minimize errors and should display clear error message that guides
users.
 There shall be various ways of retrieving data and it shall take less time.
Usability
 The end user shall be use the application easily without ambiguity.
Availability
 As far as the users mobile exists the system shall be available for 24 hours and 7
days a week.
Correctness
 The results of the calendar system should be correct and accurate.
Flexibility
 The operation shall be flexible and reports shall be presented in different ways.
Maintainability
 After the deployment of the project if any error occurs then it should be easily
maintained by the software developer, by who knows the android code.
Portability
 The software shall work properly in any android smart phones.
Reliability
 The performance of the software shall be better which will increase the reliability
of the Service.
Robustness
Page 20 of 82
If there is any error in any window or module, then it should not affect the
remaining part of the software
Design Constraints:
The system shall replace the existing system.
Chapter Three: System Analysis
3.1. System models

3.1.1. Scenarios
Table 3.3 Scenario
Scenario name See holy days and fasting days.
Participating actor Ato.Dawit
Page 21 of 82
instances:
Flow of events: 1. Ato.Dawit wants to see holy days and fasting days.
He touches the Ethical application.
2. The application provides the user interface to enter
the year, month and date.
3. He enters the year and touch the holy days and fasting
days’ radio button and then touch calculate button.
4. The application calculates and displays the result.
Scenario name See basic information’s of the year.
Participating actor instances: Ato.Dawit
Flow of events: 1. Ato.Dawit wants to see basic information’s of the year.

He touches the Ethical application.
2. The application provides the user the interface to enter
3. He enters the year and touch the basic information’s of
the year radio button and then touch calculate button.
Scenario name See the Ethiopia calendar in Gregorian calendar.
Flow of events: 1. Ato.Dawit wants to Change the Ethiopian calendar to

Gregorian. He touches the Ethical application.
Page 22 of 82
3. He enters the year and touch “To Gregorian” radio
button and touch display button.
4. The application calculates and The Gregorian result.
Scenario name See fixed holy days and fasting days.
Flow of events: 1. Ato Dawit wants to see fixed holy days and fasting
days. He touches the Ethical application.
2. The application provides the user the interface to
enter the year, month and date.
3. He enters the year and touch the fixed holy days
and fasting days’ radio button and then touch
calculate button.
Page 23 of 82
3.1.2 Use case model
Figure 3.1 Calculate holidays use case
Page 24 of 82
Figure 3.2 use case for Basic information of the year
Page 25 of 82
Figure 3.3 Use case for Fixed holidays and fasting
3.1.3 Use Case Description

Table 3.4 use case description
Use case name: See holy days and fasting days
Participating actor: User
Description: This use case describes how the user views holy days and
fasting days of the application.
Flow of event: The use case starts when the user wishes to view holy days
and fasting days of the application.
1. The user touches the Ethical application icon.
2. The application provides the user the interface to
enter the year.
3. The user enters the year and touches the holy days
and fasting day’s radio button and then click calculate
Page 26 of 82
button.
Exit conditions If the use case was successful, the user views the result the of
application. Otherwise, the application state is unchanged.
Use case name: See basic information’s of the year.
Description: This use case describes how the user views See basic
information’s of the year.
Flow of event: The use case starts when the user wishes to view See basic
information’s of the year.
1. User touches the Ethical application icon.
the year.
3. He enters the year select the basic information’s of the
year radio button and touches calculate button.
Exit conditions If the use case was successful, the user views the result of the
Use case name: See 33 The Gregorian Calendar.
Description: This use case describes how the user sees the Ethiopian
calendar in Gregorian.
Page 27 of 82
Flow of event: The use case starts when the user wishes to view the Ethiopian
calendar to Gregorian.
3. The user enters the required information and selects the
“To Gregorian Calendar” radio button and then touches
calculate button.
4. The application provides the user interface to choose
from one of the following radio button.
5. The user touches the display button.
Use case name: See fixed holy days and fasting days.
Description: This use case describes how the user sees See fixed holy days
and fasting days of the application.
Flow of event: The use case starts when the user wishes to See fixed holy days
and fasting days.
the year.
3. The user enters the year and See fixed holy days and
fasting days’ radio button and touches calculate button.
Page 28 of 82
3.1.4 Object model

The first mode we are going to be use is a use case to identify a sequence of actions that
provides a measurable value to the actor which is participating in our system and our use case
describes a way to which the environment interacts with our system.
3.1.4.1 Data Dictionary

We have identified six classes:
Holyday_Fasting class:
 Performs the following activities:
 Display Holydays and fasting
Calendar class
 Displays tabular calendar
Basic_Info class
 Displays the basic information class
Day class
 Displays the day of the date
Fixed_Holidays
 Displays the fixed holydays and fasting
Gregorian class
 Displays the Ethiopian calendar to Gregorian
User class
 Uses the application
Page 29 of 82
3.1.4.2 Analysis level Class Diagram (Conceptual Modeling)
Figure 3.4 Analytical class diagram
3.2. Dynamic model

3.2.1 Sequence Diagram
We have identified the following use case objects for sequence diagram of our system.
Calculate Holydays and Fasting

Display Calendar
Display the Basic Information of the Year
Display the Day of the Date
Display Fixed Holydays and Fasting
Display Gregorian Calendar
Page 30 of 82
Figure 3.5 Sequence Diagram: Basic Information Sequence Diagram
Figure 3.6 Sequence Diagram: Fixed Holy and Fasting Days
Page 31 of 82
Figure 3.7 Sequence Diagram: Holy Days and Fasting Date
3.2.2 Activity Diagram

We depict the activity diagram of each use case.
Page 32 of 82
act display basic information’s of the year activ ity diagr...
Start
select basic information’s

of the year
enter year
is ? error message
display basic information

of year
End
Figure 3.8 Display basic information’s of the year activity diagram
Page 33 of 82
act display holy days and fasting days of activ ity diagram
Start
select holy and fasting day
enter year
incorrect
is? error message
correct
display holy and fasting

day
End
Figure 3.9 Display holy days and fasting days of activity diagram
Page 34 of 82
act fixed holy days and fasting days activ ity diagram
Start
select fixed holy and fasting day
enter year
is ? error message
correct
display fixed holy and

fasting days
End
Figure 3.10 Fixed holy days and fasting days’ activity diagram
3.2.3 State Diagrams

The state chart of the activity to be performed is depicted below
Figure 3.11 State chart diagram for View Holydays and Fasting
Page 35 of 82
Figure 3.12 State chart diagram for Display Calendar
Figure 3.13 State chart diagram for Display Holy Days and Fasting
Page 36 of 82
Figure 3.14 State chart diagram for Day of the Date
Figure 3.15 State chart diagram for Display Fixed Holydays and fasting
Page 37 of 82
Figure 3.16 State chart diagram for Gregorian Date
Page 38 of 82
3.2.4 User interface (navigational paths and screen mock-ups)
Figure 3.17 User Interface
Page 39 of 82
3.2.5 Supplementary Specifications
1. Functionality
This section lists functional requirements that are common to more than one use case.
Accessibility
All functionality shall be available every time for the mobile user. This may require the user
running on his mobile.
2. Usability
OS Compliance
The Ethical user-interface shall be Android 4.2 OS and above compliant.
Design for Ease-of-Use
The user interface of the Ethiopian Calendar System shall be designed for ease-of-use and shall
be appropriate for a mobile user with no additional training on the System.
3. Reliability
Availability
The Ethiopian Calendar Application shall be available 24 hours a day, 7 days a week as far as the
user and his mobile exists. There shall be no more than 1% and less down time.
Mean Time Between Failures
Mean Time Between Failures shall exceed 100 hours.
4. Performance
The performance characteristics of the system are outlined in this section.
a. Simultaneous Users
It is designed for single user; Hence the application shall not be busy.
b. Access Response Time
Page 40 of 82
The system shall provide access to ABECS access request with no more than a 2
second latency.
5. Design Constraints
a. Platform Requirements
The Android Based Ethiopian Calendar System shall operate on any mobile with a 4.0 processor
or greater. The Application shall require less than 1GB disk space and 1GB RAM.
Page 41 of 82
Chapter Four: System Design
4.1 Introduction
5. This document provides the details of architectural design and hardware software
mapping of Ethical mobile application.
4.1.1 Purpose of the system

The system is designed to implement a solution to an application domain which consists of an
Android Based Ethiopian Based Calendar System. This will be achieved by delivering a
software system that will interact with the corresponding user. The solution implemented will
allow better control of Calendar system in both Ethiopian and Gregorian. During system design
we concentrate on the process of data structures and software and hard ware components
necessary to implement it.
The main purpose of the proposed system is to improve some activities through mobilized way
that simplifies the workload of the existing system and speedup the operation of the system.
We all know the importance of automation. The application areas for the mbile have been
selected on the basis of following factors:
Minimizing the manual records kept at different circumstance.
There will be more data integrity.
Facilitate desired and quick information display
Facilitating various calendric statistical information
To reduce manual efforts in activities that involved repetitive work.
Because of its portability
4.1.2 Design goals

The design goals represent the desired qualities of the application and provide a consistent set
of criteria that must be considered when making design decisions. Based on the
nonfunctional requirements and the information elicited from the users, the following design
goals are identified.
Error handling and extreme conditions
The application will face interactions from users and each interaction may bring an invalid
input to the application. So, the application should be implemented to capture any invalid
Page 42 of 82
input data with error handling mechanism. If a user enters wrong inputs, the application
should recognize it and guide the user by providing informative error messages to make the
necessary correction.
Accessibility
The system should be accessible at any android mobile users.
4.2 Current software architecture

Currently there is no software architecture for Ethiopian Calendar System. The current system is
a paper based system that is outdated and unorganized. There is no full mobile based system for
handling the data to delivers the information of calendar.
4.3. Proposed system software architecture

4.3.1. Overview
The ABEC System in general will consist an android application:
The Software architect is depicted as follows:
Figure 4.4 System Software architecture
Page 43 of 82
4.3.2. Subsystem decomposition
Subsystem decompositions will help reduce the complexity of the system. The subsystems can
be considered as packages holding related classes/objects. During subsystem decomposition of
the system we consider the following issue: -
Divide the system into smaller subsystems with a strong cohesion.
The instruction between subsystems should have a loose coupling.
The Ethical Mobile Application under consideration is decomposed into subsystems as shown in
the figure below.
Figure 4.5 Subsystem decomposition
Page 44 of 82
Description of the subsystems is as follows:
Basic Information management: This subsystem handles to calculate and display the
following basic information on the given year.
 Calculate BealeMetqi .
 Calculate tint on.
 Calculate wengelawi.
 Calculate amete alem.
 Calculate Medeb.
 Calculate mebaja hamer.
 Calculate MeteneRabiet.
 Calculate abektie.
 Calculate Metqi.
 Calculate Wenber.
 View BealeMetqi .
 View tint on.
 View wengelawi.
 View amete alem.
 View Medeb.
 View mebaja hamer.
 View MeteneRabiet.
 View abektie.
 View Metqi.
 View Wenber.
Holy and fasting day management: This subsystem handles to calculate and display the holy
and fasting day of the given year.
 Calculate neneveh.
 Calculate fasting and holyApostles.
 Calculate scension.
 Calculate RikbeKhahnat
 Calculate Paraclet.
 Calculate meskerem1.
Page 45 of 82
 Calculate aby tsome.
 Calculate Hosanna.
 Calculate goodfriday.
 Calculate debrezeit.
 View neneveh.
 View fastingo fholyApostles.
 View scension.
 View RikbeKhahnat
 View Paraclet.
 View meskerem1.
 View aby tsome.
 View Hosanna.
 View goodfriday.
 View debrezeit.
FixedHolyAndFastingDay management: This subsystem handles to calculate and display

the fixed holy and fasting day of the given year.
 Assign fixed holyday.
 Calculate AtsfeAwrha.
 Assign fixed fasting day.
 View fixed holyday.
 View fixed fasting day.
HolyDaysOfTheWeek management: This subsystem handles to calculate and display the
HolyDaysOfVirginSaintMary day of the given year.
 Calculate AtsfeAwrha.
 Calculate The Day of the week
The Gregorian Management:
 It converts the Ethiopian calendar to Gregorian.
Page 46 of 82
4.3.3 Hardware/software mapping
The diagram shown below depicts the outline of the deployment scheme for the Android Based
Ethiopian Calendar System.
The following components make up the Android Based Ethiopian Calendar System:
Users Mobile
Ethical Android Application
The user simply clicks the Ethical Application and fill the required year and then the application
will respond the intended result.
Figure 4.6 Hardware/Software mapping for ABEC
4.3.4 Persistent data management

ABEC system will largely depend on a relational database to perform day-to-day operations and
storing log data.
The application will be accessible 24/7 via a mobile. The class included in the system:
Common class
Holydays and fasting
Calendar
BasicInfo
DayofTheDate
FixedHolyDays
Gregorian
Page 47 of 82
The application should be available all time.
Figure 4.7 Persistent data management
Page 48 of 82
4.3.4.1 Mapping
As the calendar system does not need storage(database), the Ethical application needs no
mapping diagram. Because the mapping is the model and visualization of the database.
4.4.3.4.2 Database Design

Android Based Ethiopian Calendar has no database as well as database design.
4.3.5 Access control and security
The Access control Matrix for the ABECS System is as follows:
Table 4.5 Access control and security
Action User
Start App Yes

Logging in No
User Settings Yes
Data Entry Yes
Create Schedule No
View Holydays Yes
Add Future No
Close App Yes
4.3.6 Global software control

The ABECS architecture is to have an explicit, centralized software control. The request
initiations are event-driven:
The User initiates the Application by touching the Ethical App.

The Ethical Main Interface will be initiated when a request is delivered
The User enters the year, which he need to see the calendar of.
The User choose the month of the year
The User Insert the date of the month
After wards the user choose the type of data he need and touch display button.
4.3.7 Boundary Conditions

Startup: go to Ethical App and open
Page 49 of 82
Shut Down: Touch close button and close the application.
Error Conditions:
Compatibility
 The application cannot have opened.
 The application is corrupted.
Data Entry
 The system fails when the user is entering information.
Monitor display
 The system crashes or the backup also crashes.
 The system hangs up.
 The application may fail up.
4.4 Sub system services
A. The User Interface (UI) Subsystem
Takes user input

Process user input
Displays system output
4.5 Component Diagram
We depict all physical aspects or executables, documents, files, forms, etc. to visualize the
organization and relationships among components in our system.
Page 50 of 82
View Holidays and
Fasting
View Calendar
View Day of the

Week
User (Ethical
Application) View Fixed Holidays
and Fasting
View Date in
Gregorian
View Basic
Information of the
Year
Figure 4.8 Component diagram for ABECS
4.6. Deployment Diagram

We depict the following deployment diagram to visualize the topology of the physical
components of our system where the mentioned software component diagrams are deployed.
Page 51 of 82
Mobile Application
Interface
User
Figure 4.9 Deployment Diagram for ABECS
Page 52 of 82
Chapter Five: Object Design
1.1Introduction
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 (Object Design Decomposition) is used to exchange interface information among
teams and as a reference during testing.
5.2 Object Design trade-offs

The following are the trade-offs found in our ABECS.
5.2.1 Buy Vs Build

We provide this ABECS system for all Ethiopian to buy and use it for a better work. Of course,
the system that we have can be divided into modules. If we need some module in the market with
most of the functionality that we need, then that system can be bought to save time, money and
human resources. When a solution module is bought, it provides ready functionality. The entire
system might have to be changed which would be costlier than expected. Therefore, based on
these requirements, in the ABECS, we can buy one module which is:
The Ethical Application

5.2.2 Guidelines and Convention:
5.2.3 Naming Conventions:
This section is described in 5.3 subsection in detail.
5.2.4 Boundary Cases:

We need to make sure there is enough space to the application. Minimize the size, it
needs.
We need to make sure the app should have to display the result of every entered year
We have an exception dialog, but we do not appear to store that information anywhere,
but that has not its own database.
The Year. We need to make sure it is an unsigned int to make sure it never rolls over and
becomes negative.
The entered year should be the stream of the result.
Page 53 of 82
5.2.5 Exception Handling Mechanisms:
The ABECS system is dealing with Android of java programming language construct to ensure
the fact that normal flow of execution takes place constantly. EHM is merely focused about what
are the constraints and raising these exceptions in a useful way to deal with any sort of problem
or semi-predicate problem as listed below:
a. Invalid year:
If the user tries to enters invalid year (string, symbols and special characters), the system should
not accept the input value.
b. Overflow exception:
When the user tries to inter too large number that the application does not perform, the Ethical
app should display overflow exception.
c. Invalid Data Exception:
This exception is invoked when any information mismatch to the data type is tried to display the
calculated result.
5.3 Interface documentation guidelines
We identify different constants, packages, and classes-which can be help us in understanding the
code.
This section will give an insight about the Naming Convention. They are described individually
in the table.
5.6 interface 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
Page 54 of 82
is User Interface so as not to make lengthy
package name. We’ve used any top-level
domain names, currently com, one of the
Packages Package BahireHasab;
English two-letter codes identifying
countries as specified in ISO Standard
3166, 1981.
Class names should be nouns, in mixed class MainActivity;
case with the first letter of each internal class Calendar;
word capitalized. We kept our class names
class ContactUs;
simple and descriptive. Nonetheless, we
Classes
used whole words and avoided acronyms
class BasicInfo;
and abbreviations as far as possible (unless
the abbreviation is much more widely used class HolyDays;
than the long form, such as DB for
class Help;
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 DataInterface;
class names.
Methods Our Methods are verbs, in mixed case with Calculate();
the first letter lowercase, with the first Diaplay ();
letter of each internal word capitalized.
Show();
Except for variables, all instance, class, int i;
and class constants are in mixed case with char c;
a lowercase first letter. Internal words start long int year;
with capital letters. Variable names have
Variables
no start with underscore _ or dollar sign $
characters, even though both are allowed.
Variable names are short yet meaningful.

The choice of a variable name is
Page 55 of 82
mnemonic- that is, designed to indicate to
the casual observer the intent of its use.
One-character variable names are avoided
except for temporary "throwaway"
variables. Common names for temporary
variables are i, j, k, m, and n for integers;
c, d, and e for characters.
Constants The names of variables declared class Public static final int
constants and of ANSI constants should be meteneRabit = 4;
all uppercase with words separated by
underscores ("_"). (ANSI constants should
be avoided, for ease of debugging.)
5.3 Packages.
The Ethical application has only one package called BahireHasab and encompasses different
classes and interfaces.
1. BahireHasabUI: This package represents the Main User interfaces for the user.
5.5 Class Interfaces.
5.4 Package: BAhireHasabUI:
5.4.1 Class MAinActivityForm
This is the main class of the application. It declares the user interface classes. And accepts input
from the user (The year, month and date)
5.4.2 Class CalendarForm

This class represents the calendar window in tabular form. This class allows the user to view
calendar in table.
5.4.3 Class HolydaysAndFastingForm

This class represents the holydays and fasting window of the application. this form of the
application displays list of holydays and fasting of the given year.
Page 56 of 82
5.4.4 Class BAsicInfoForm
This class represents the basic information of the year. This information is the base of other
results of the calendar.
5.4.5 Class DayoftheDate

This class represents the day of dates. This class has two parts, the Ethiopian date and Gregorian
day forms.
5.4.6 Class ExcptWin

This class represents the exception message displayed to the user.
Private void searchNotFound()

5.4.7 Class GregorianUI
This class represents the user interface displaying the conversion date from the Ethiopian
calendar to Gregorian.
6 Design Pattern:
There are two kinds of wrapper patterns namely Object Wrapper Pattern and Class Wrapper
pattern.
Our ABECS system focuses on Object Wrapper design pattern which contains an instance of the
ExtSystem class(Client) it wraps. In this situation, the Ethical (app) makes calculate calendar
instance of the wrapped object. Fundamentally, ExtSystem (Client) is not connected to database.
When the user calculates the calendar using the Display () method on its target object, the
request is translated into the corresponding specific request on the application.
Page 57 of 82
Chapter Six: Implementation and Testing
6.1 Introduction
Now a days every technology and software is being tested before implementing and using inside.
It is one of the obligations of the SW developers. Users also should check and test before buying
any technology results.
As we have seen everything about ABECS system.:. Now we will see the ‘implementation and
testing’ stages as follows.
6.2 Final Testing of The system

Before the ABECS system is going to implemented we have to test every functional and non-
functional functionalities using Blue stacks application player and android virtual device
manager (Emulator) in our local machine.
The system has been checked and tested correctly in team work. There was some errors and
faults during development stage and those errors has been also debugged completely.
6.3 Hardware Software Acquisition

In order to implement and use ABECS system, as it was described in ‘Hardware and Software
requirement’ in chapter one, Android based smart phone and the Ethical application are required.
Any user who are intended to use this system must have the Android based smart phone and the
Ethical application are mandatory.
Hardware Software
- Android Based Mobile (Smart) Ethical application
- Any version above 2.2 version 1.0 and above
6.4 User Manual Preparation

Here is the complete manual, that helps you how to use the Android Based Ethiopian Calendar
System.
6.4.1 The manual for Ethical application

The Ethical application is developed by adt-bundle-windows-x86-20130729 (Android) and use
java coding. The application can work without any network connection. That means it enables
the user to calculate calendar offline. Here is depicted on the following steps, that visualizes how
to use this Ethical application.
Step-1- Start the application: before use the Ethical calendar any user must open the application
first. In order to start the app, the user should have to press the Ethical application icon.
Page 58 of 82
Figure 5.2 starting the application
Step-2- Entering in to the system: after the application starts, it will provide the Main User
interface as follows:
Figure 5.3 Main interface of the application
Page 59 of 82
Afterwards the user can use it by simply entering any year he need.
Inserting Year: You can enter any year you need to see the required information.
5.4 Ethical application User Interface to enter year
1. Choosing Option
After you fill out the year field, then you can choose what you need from the option (from radio
buttons).
Page 60 of 82
5.5 Ethical application UI: Choosing Option
Here there are two types of options in the app; these are:
Options, which does not need date: This options need only year to display calendar
information. These are: “በዓላትና አፅዋማት”, “calendar (ቀን መቁጠሪያ)”, “የአመቱመሰረታዊ
መረጃወች” and “ቋሚ በዓላትና አጽዋማት”.
Options, that need date: This options needs all input field values (Year, month and
date). In this case the you are expected to enter the year and the date. If you ignore
entering(selecting) month, the system automatically set the month at “September” by
default.
6.5 Training
When organization or user buys this application, the training will be given to them at the time of
buying this system. The user manual itself can help them as tutorial about how to use the system.
Page 61 of 82
6.6 Installation Process
After all hardware and software requirements has been fulfilled, you can install simply by long
pressing the Ethical app and select “INSTALL” option.
6.8 Coding
In this phase the team wants to show the project done is turning the physical design specification
into code, the system design needs to be implemented to make it a workable system. Hear is
sample code for Android Based Ethiopian Calendar and display the result to main user interface.
Android - XML
Sample code for MAinActivity
<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:id="@+id/ScrollView1"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity" >
<LinearLayout
android:layout_height="wrap_content"
android:orientation="vertical" >
<TextView
android:id="@+id/mainEthiorthodox"
android:layout_width="fill_parent"
android:background="#0000FF"
android:gravity="center"
android:text="@string/ethical"
android:textColor="#FFFFFF"
android:textSize="17sp"
android:textStyle="bold" />
<LinearLayout
android:orientation="horizontal" >
<TextView
android:id="@+id/mainAmeteMihret"
android:layout_width="wrap_content"
android:gravity="left"
android:text="@string/yearTv"
android:textColor="#000000"
<EditText
android:id="@+id/YearMainId"
Page 62 of 82
android:layout_gravity="right"
android:ems="10"
android:hint="@string/year"
android:inputType="number"
android:textStyle="bold" >
<requestFocus />
</EditText>
</LinearLayout>
<LinearLayout
<TextView
android:id="@+id/mainWer"
android:text="@string/monthTv"
<Spinner
android:id="@+id/MonthMainId"
android:entries="@array/months"
android:prompt="@string/month"
android:textColor="#0000FF"
android:textStyle="bold" >
</Spinner>
</LinearLayout>
<LinearLayout
<TextView
android:id="@+id/mainQen"
android:text="@string/dateTv"
<EditText
Page 63 of 82
android:id="@+id/Datemainid"
android:hint="@string/date"
android:inputType="number"
</LinearLayout>
<TextView
android:id="@+id/mainChoose"
android:background="#A52A2A"
android:text="@string/option"
<LinearLayout
<RadioGroup
android:id="@+id/radioGroup1"
android:orientation="vertical" >
<RadioButton
android:id="@+id/Radio1"
android:text="@string/hollyDaysAndFasting" />
<RadioButton
android:text="@string/calender" />
<RadioButton
android:text="@string/basicInfo" />
<RadioButton
android:text="@string/dayOfTheWeek" />
<RadioButton
Page 64 of 82
android:text="@string/fixed" />
<RadioButton
android:text="@string/gregorianCalender" />
</RadioGroup>
<ImageView
android:id="@+id/imageView1"
android:contentDescription="@string/mary"
android:src="@drawable/calendar1" >
</ImageView>
</LinearLayout>
<LinearLayout
android:layout_height="50dp"
<Button
android:id="@+id/CalculateMainId"
android:layout_width="100dp"
android:background="@drawable/button_custom"
android:text="@string/button1"
<Button
android:id="@+id/ResetMainId"
android:background="@drawable/button_custom2"
android:text="@string/Reset1"
<Button
android:id="@+id/CloseMainId"
android:background="@drawable/button_custom"
android:text="@string/button2"
</LinearLayout>
</LinearLayout>
</ScrollView>
Page 65 of 82
Android-Java code
Sample code for Day of the date
else if(r4.isChecked())
{
//String date=eddate.getText().toString();
if (werIndex == 0)
{
atsfeAwrah = 0;
}
if (eddate.getText().toString().length() <= 0)
{
Toast.makeText(getBaseContext(), "መጀመርያ ቀኑን
ያስገቡ \n You have to Enter date first!",Toast.LENGTH_LONG).show();
}
else
{//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
long date
=Long.parseLong(eddate.getText().toString());
if (date <= 0 || date >= 31)
{
Toast.makeText(getBaseContext(), "እባክዎን
ትክክለኛ ቀን ያስገቡ \n You have to Enter Valid date!",Toast.LENGTH_LONG).show();
}
else if (werIndex == 12 && date > 5 &&
wengielawi != "ሉቃስ" || (werIndex == 12 && date > 6 &&
wengielawi.equals("ሉቃስ")))
{
Toast.makeText(getBaseContext(), "ለጳጉሜ
ትክክለኛ ቀን ያስገቡ \n You have to Enter Valid date for Phagumie!",
Toast.LENGTH_LONG).show();
}
else
{
QbealeMetqee = eleteTebiban + atsfeAwrah +
tinteOn + date;
x = QbealeMetqee % 7;
if (x == 1)
{
elet = "እሁድ";
day="Sunday"; // Sunday
}
else if (x == 2)
{
elet = "ሰኞ";
day="Monday"; //Monday
}
else if (x == 3)
{
elet = "ማክሰኞ";
Page 66 of 82
day="Tuesday";// Tuesday
}
else if (x == 4)
{
elet = "ረቡዕ";
day="Wednesday";//Wednesday
}
else if (x == 5)
{
elet = "ሐሙስ";
day="Thursday"; //Thursday
}
else if (x == 6)
{
elet = "ዓርብ";
day="Friday"; //Friday
}
else if (x == 7 || x == 0 || x < 0)
{
elet = "ቅዳሜ";
day="Saturday"; //Saturday
}
else
{
// Toast.makeText(getBaseContext(), "የፈለጉት
ቀን: " + elet + " ነዉ \n The Day You Need is:" + " " + elet,
Toast.LENGTH_LONG).show();
new AlertDialog.Builder(MainActivity.this)
.setTitle("የፈለጉት ቀን: \n The Day You Need:" )
.setMessage(elet + ", " + weralert + " " +
date + "," + " " + ameteMihret + " ዓ.ም" +"\n" + day + ", " + monthalert + " "
+ date + "," + " " + ameteMihret + " EC " + leapyear)
.setNeutralButton("OK", null)
.setIcon(R.drawable.qen2)
.show();
}
}//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
}
Page 67 of 82
Chapter Seven: Conclusion and Recommendation
7.1 Conclusion
In this project, we developed an Android Based Ethiopian Calendar System that facilitates the
various activities taking place at Calendar Calculation.
The system is Android Based Ethiopian Calendar System and called “Ethical”, named after the
name of Ethiopian calendar. Eth- indicates Ethiopian and Cal-indicates Calendar. The
application is version 1.0 and needs more upgrading. When we update it we will release it
immediately. We wish you a happy year and we are thanking full for you are using our
application.
7.2 Recommendation
To enhance the efficiency of the system, in the following we have listed some recommendations
and future works.
We believe that to increase the performance and efficiency of the Ethical application; adding
some futures like, fetching system date, alarm and diary are good functionalities. We recommend
that the coming developers to add these futures too,
Even if every calendar activity is done by the application, we recommend users to learn the
Ethiopian calendar to know how holydays, fasting days and days of the date calculated.
Page 68 of 82
Appendix
Appendix A: Paper Document in the Existing System
A calendar document of Ethiopian calendar
Figure 5.6 The main interface of the Ethical Application
Page 69 of 82
Reference
1) The holly Bible 81 1980 E.C

2) The Difference Between Ethiopian And European Calander ()
3) Abushahir, Ethiopian calendar formula (daikon Engineer Abreham Tenaw) 200 E.C
4) Bahire Hasab (Aleka YAred Fenta Welde Yohaness 2004 E.C
5) Timhirte Melekot (Asrat Gebre Maryam) 1991 E.C
6) Sir_ate Betekistiyan Like Kahinat Kinfe Gebriel Altaye and Kesis Getachew Dejenie )
1989 E.C
7) Spiritual Seremonies in Ethiopia September- September ( Memhir Degefaw Kassie )
1993 E.C
8) The right Ethiopian Calendar ( Hiruy Simie ) 2000 E.C
9) (Article submitted to www.debreselam.net by Deacon Ahadu Asres)
10) Ambler, Scott (2001) The Object primer: The application Developers Guide to Object
Oriented and the UML.2nd rev. Ed England: The Cambridge University Press.
11) Bruegge, Bernd (2000) Object oriented Software Engineering Conquering Complex
and Changing System. Upper Saddle River: Prentic Hall.
12) Chopra, R.N (1999) Dictionary of Library Science. New Delhi Anmol Publication
13) FUNDAMENTALS OF DATABASE SYSTEMS. (2003).

14) Sawyer, I. a. Requirement Engineering a good Practice.
15) Sawyer, S. &. Requirement Enginering.
Page 70 of 82

ABECS Proposal

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

ABECS Proposal

Uploaded by

Copyright:

Available Formats

[Android Based Ethiopian Calendar System]

A Senior Project Documentation Submitted to Debre Berhan University in Partial

Supervised by Mr. Henok E. (Msc.)

Department: Information Technology

College of Computing, Department of Information Technology, Debre Berhan University,

1. Ibrahim Ahmed ……………………………………………………

Name of Advisor Signature

Examiner Name Signature

1. Examiner 1 …………………………………. ………………………

2. Examiner 2 …………………………………. ……………………….

3. Examiner 3 …………………………………… ……………………….

4. Examiner 4 …………………………………… ……………………….

Android Based Ethiopian Calendar System

Debre Berhan University, 2008 e.c

Debre Berhan University, 2008 e.c

Keywords: Android, system, Calendar, Calculation

Debre Berhan University, 2008 e.c

Page VII of LXXXII

Page VIII of LXXXII

Page XII of LXXXII

1.2. Background of the Project

1.3. Problem statement

It requires professional person

Inefficient use of time and resource.

1.4. Team Composition

No. Name Task

1. Ibrahim Ahmed Title selection, Project proposal, requirement

2. Jemal Julla Title selection, Project proposal, requirement

3. Kasaynesh Demie Title selection, Project proposal, requirement

4. Tsegaye Tamiru Title selection, Project proposal, coding, requirement

5. Habtamua Yeshidagna Title selection, Project proposal, requirement

The specific objectives of the project are listed as follows.:

1.6. Scope and Limitation of the project

Display the calendar of the input year in tabular form.

The limitation of our project is:

1.7. Significance of the project

1.8. Beneficiaries of the project

1.10. System analysis and design

1.11. Development Tools

Android-Eclipse: -software to design the proposed system. It is a multi-language integrated

Different hardware used to develop our project

We will use two different methods of testing technique.

White box testing

1.15 Risks & contingencies

1.12. Project Plan

No Task Start date (E.C) End date (E.C)

1 Feasibility study 12/12/2008 15/12/2008

2 Requirement elicitation 16/12/2008 19/12/2008

3 Requirement analysis 20/12/2008 25/12/2008

4 Designing diagrams and models 26/12/2008 30/12/2008

5 Implementation 12/2/2009 30/10/2009

1.13. Team role and responsibilities

Requirements Gathering System Design Implementation

Responsible person: Responsible person: Responsible person:

Figure 1.2 Team role

Chapter Two: Description of the Existing System

To calculate starting and ending fasting date.

Finding AmeteAlem(year of creation) and Wengelawi

AmeteAlem = zemene_Bluy + zemene_haddis.

Example:-In 2009 E.C. AmeteAlem=5500+2009=7509. Wengelawi means writers of gospel. The

The quotient without the remainder is called MeteneRabiet.

Finding New year (Meskerem 1)