Trade Registration and Licensing Sysytem

TRADE REGISTRATION & LICENSE SYSTEM 2015
CHAPTER ONE
1.1 INTRODUCTION
Trade registration system allows traders to register their Trade nationally. Many traders
are legally required to register in order to operate in Ethiopia. The first important stage in Trade
registration is deciding upon which jurisdiction to establish your Trade in. It is important to
consider the financial and economic advantages and disadvantages of setting up Trade within
that jurisdiction. Once the jurisdiction has been chosen, the process of Trade registration and
licensing can then begin.
It is important to include certifications and professional references, as well as a detailed

outline of the structure of the company. In addition, the company must present a proposed
company name that complies with the jurisdiction’s legal requirements, which will be assessed
by that jurisdiction registrar general.
Trade registration is very important as it establishes the Trade as a legal entity. Without
Trade registration, the company cannot be legally considered as legal trader and will not be
protected under any grievance procedures etc. In addition, it will not be protected by the
jurisdiction from any economic, legal or social instability.
1.1.1 BACKGROUND ABOUT THE PROJECT

The project entitled Trade Registration and Licensing System (TRLS) is for
computerizing the working in Adama town trade registration office. The project takes care of all
the requirements of the trade registration office and is capable to provide easy and effective
storage of information related to traders that come up to the registration office for registration of
their trade and getting the trade license.
At the present, information system is necessary for Trade registration Office’s. The
project will use the information technology for managing all of trader data. That will make more
performance and more reliability of data storing. Therefore, this project is best alternative for the
trade registration office to turn their trade registration and licensing system to the more organized
FINAL YEAR PROJECT Page 1

form and simplify access of data, data management and easily modification of the records of
traders.
1.2 STATEMENT OF THE PROBLEM

The numbers of the traders have been increasing all the time. That affects the overall
performance of data storing system. The increasing amount of data makes more paper to be
used. The big amount of paper means to the data storing will have more complexity and hard
to find the one we want to see. This is the main problem in the trade registration system. This
implies that in the trade registration office, storing data in paper is not suitable.
The current trade registration activities and the issuance of trade licenses without the use of
modern technology, is unsuitable for data management. Beside to the difficulty in data
management there is a problem of proper authorization of trade name, difficulty in modifying
of trader data when changing the trade name. More than that processing of the registration
and license certification is time consuming. Another problem here to be discussed is that
there is no use of database for data storage.
 Some problems in the current system are the following:-
 Poor Data Storage: – More space and time needed to keep all records of traders and there is
no use of database for file storage which is susceptible for natural disaster like fire, flood,
volcanic eruption etc...
 Unproductive use of resources: - Paper takes up a massive amount of room in the site. If
computer systems were bought, there would be lots of more free space which could be used
for other purpose.
 Difficulty in modifying and editing data regarding the traders: - The existing traders’
record is difficult to be edited and updated.
 Lack of immediate data retrievals: -The information is very difficult to retrieve and to find
particular information. E.g. - To find out particular traders information, the user has to go
through various lists of all trader information. This results wastage of time.
 Manual control: -There is no means to control incorrect data inputs.
 Data redundancy: -There is no data redundancy control, for example, the same registration
number can be assigned to different trader due to human errors.

1.3 OBJECTIVE OF THE PROJECT
1.3.1 GENERAL OBJECTIVE

The general objectives of this project will develop a web-based trade registration system for the
Adama town trade registration office that gives more systematic registration processing;
minimize the paper works and manual record keeping of the traders.
1.3.2 SPECIFIC OBJECTIVES

The following are the specific objectives which help to achieve the general objective of the
project:-
 To solve the problems of the existing system

 Identify and design the requirement of the new system
 Developing the application software based on our requirement for the existing system
 Implement, test and install the new system in well manner.
 To build up a system that allows generating of license and registration certificates.
 To build up a system that allows updating, deleting of data records regarding traders.
 Developing a system that Controls records not to be stored again/to avoid data
redundancy.
 To create backup system for files of traders with the use of databases.
1.4 METHODOLOGY
1.4.1 DESIGN METHODOLOGY

Object Oriented Design/OOD; is the methodology that will be used throughout the
designing of the system. As it supports entity relationship model, which is very important in
identifying the actors and the users of the system easily. More than that OOD can mirror the
work that is done in real world organizations as it uses model to illustrate objects easily. For
these reasons we will select OOSAD as design methodology.

1.4.2 DATA GATHERING METHODOLOGY

Observation
We will analyze the current system by observation.
Interview
We will understand the system by interviewing the workers in Trade Registration Office
about the trade registration and license provision process as well as the overall activities involved
in the system.
Document Analysis
In all organizations documents such as forms, records, reports, and manuals are available.
These help in determining how the present system runs. So in addition to observation and
interview we will understand the existing system by reviewing different documents.
1.5 SCOPE AND LIMITATIONS OF THE PROJECT
1.5.1 SCOPE OF THE PROJECT

The Trade Registration and Licensing System will automate the Trade registration and
licensing operations. The project that we will try to focus on Trade Registration and Licensing
System will cover only for Adama town. As a jurisdiction issue, all other towns around Adama
town have the same rules and regulation as to paying taxes but this project will only focus on the
city Adama due to the difficulties and limitations of different inputs. The project will cover the
following activities:
 Registering information about the traders.

 Generating reports.
 Cancelling trade license.
 Update the trader information.
 Recording of license certificate.
 Searching or finding out trader information.
 Renewal of trade license.

 Prints registration and license certificate
1.5.2 LIMITATION OF THE PROJECT

There are many constraints within our propose system that limit their effectiveness of
performance. The most common constraints are:
Shortage of time is the one that will contribute limitation for the effectiveness of this project. Not
only this, there will be other constraints of resources.
1.6 SIGNIFICANCE OF THE PROJECT

The beneficiaries of the system are:-
Traders
The primary beneficiaries of the project will be the enterprises and those who plan to start
Trade. Registering an enterprise, obtaining a tax code, a statistics code and applying for a seal
permit will be greatly simplified as a result of this project.
 Trader can get their documents easily.
 Save the trader time.
The Organization
 Provide Security: only authenticated user can get access to the system.
 Provide performance and efficiency: in data retrieval and form filling during
registering applicants’ information into the system.
 Better data storage: by the use of database for file storage.
 Productive use of resources: save resources like time and space and reduce
wastages.
 Better quality work: reduce errors which are created on manual work.
 Reduce the workload: simplify the trade registration process.

1.7 FEASIBILITY STUDY OF THE NEW SYSTEM
The feasibility study is the preliminary study that determines whether a proposed
system project will financially, technically and operationally viable. The alternative
analysis usually include as part of the feasibility study identifies viable alternatives for
the system design and development.
1.7.1 ECONOMIC FEASIBILITY

The project is economically viable since it will expect benefits outweigh the expected
cost. The project has a total return on investment of within seven months estimated software life
cycle.
No Name of material Quantity Cost in birr Model
Per Total
unit
Table: 1 the
1 Pen 12 5 60 Lexi 5
overall cost of the
2 Pencil 4 5 20 Flexible project
3 Paper 2 desta 90 180 A4
4 Print 50 1.5 75 …… The Adama town
5 CD 4 12 48 ……. trade registration

office needs the
6 Flash 1 120 120 Sun disc
following business
7 Desktop 1 3000 3000 Dell 780 material in order
to operate the
8 Internet 6 month 200 1600 ….
some part of tasks
9 Microsoft 1 250 250 ….. using the new
access/SQL system:
10 Taxi 5 days 5 50 …
Total 0
No Name material Quantity Cost in birr Model
Per unit Total
1 Desktop 6 3000 18000 ….
2 Digital Printer 2 12000 24000 ….
3 Software 1 50,000 50,000 Web based

application
4 Cable 2 50 100 RJ_45
Total 10
Table 2: business material
1.7.2 TECHNICAL FEASIBILITY

We believe that building a working system with acceptable through, response time and
other performance parameter will involve through technical knowledge and technology
availability.
1.7.3 OPRATIONAL FEASIBILITY

The new system will support the major activities of Recording license and will take
advantage to solve the problem out lined in the statement of the problem section .The
Recording license head can operate the system with little training .so we can say that it is
operational feasibility.
1.7.4 SCHEDULE FEASIBILITY

Realized within the time duration, we have identified the activities in accomplishing the
project objective with their schedule requirement which is on the chart below.
GANT CHART

o Useful for depicting simple projects or parts of large projects
o Show start and completion dates for individual tasks
Task name Duration Start Finish Oct. Nov. Dec. Apr.
1.requirement 10 days 01/10/2017 11/10/2017

gathering
2.requirment 20 days 12/10/2017 01/11/2017

specification
3.design 30 days 02/11/2017 02/12/2017

document
4.implementatio 03/12/2017 06/042017

n
124 days
Of the project
5.testing& 20 days 07/04/2017 27/04/2017

installation
Table 3: time schedule for the project
PERT CHART
o Show order of activities

1.7.5 POLITICAL FEASI BILITY

The system that we will be develop does not conflict with any government directives,
because it gives services for the people effectively and efficiently, all the stakeholders also
agreed before the system developed. So the government is profitable and the system will be
politically feasible.
1.8 Management issues
1.8.1 Team Configuration and communication plan

In our project, we have four (4) members where each of us has specified work and also
the project is supervised by one of our members. The following are the types of tasks and
as well as the responsibility each of us can have.
Task name Group member

Project manager Abdurahman nesru
System Requirement and specification Estifanos hagos

(SRS) Gebreezgiabher gebreMariam
Analysts and Designer Bisrat fisaha

Abdurahman nesru
Implementation and Testing All group members
Table 4: team configuration

1.8.2 Communication plan

While we are working on our project, we use the following techniques in order to meet one
another and then exchange our suggestions or ideas. Those techniques are listed in the following
table.
Number Technical
1. Mobile phone
2. Schedule(Time table)
Table 5: team communication plan

2 CHAPTER TWO
2.1DESCRIPTION OF THE EXISTING SYSTEM
2.1.1 Why describe the existing system

First we must describe about the existing system, both its benefits & its limitation. By
doing so, we will be able to enhance the benefits more & solve the limitation problem by
proposing a new mechanism that will directly affect & effectively solve the problem that the
existing system have.
So by focusing on; what the current system lacks, the time taken to perform a task using
the existing system, and other mandatory requirement, it’s very important to further describe the
existing system.
2.1.2 OVERVIEW OF THE EXISTING SYSTEM

In the existing system records of traders are managed in their registration number and
categorized in years. The registration and license provision is done as follows:-first the trader
applies for registration or license certification, after that the workers of the trade registration
office ask the requirements for the registration or license certification then if the trader qualify
for the registration and license certification they will provide a service of license certification and
trade registration. In the system the registration and license provisions to the trader are done by
filling the registration form and license forms and stamping the seal to the form so that the
license could be regarded as a legal one. Besides to license certification and registration, the
system also cancels the license.
The cancellation process is described as follows, there will be two cases for license
cancellation one, by the will of the trader when the trader close his trade activity in this case the
license cancellation will be done as soon as the trader request is arrived in formal letter. The
second case, is when the trader does not renew the license with renewal time, in this case, before
the cancellation takes place the trade registration process coordinator will send a letter to the
trader for requesting the reason why the license is not renewed, then if the trader response is

satisfactory the license will not be cancelled otherwise cancellation will be done on un-renewed
license.
2.1.3 Report generating in the existing system

In the existing system, since most of the work is done manually, to generate a report with
a specific target is very difficult & time consuming. All the records are attached in a box-file and
the records are sub-divided by the year it was taken. I.e. if the customer got license in 2002EC,
the record is in a box-file labeled 2002E.C.
This type of taking record will be very difficult if the number of customers is very large
& will be ineffective & inefficient to gather report. Mostly for data warehouse purpose i.e.
gathering data for the purpose of research or survey, this type of report is unlikely to be used in
such scenario as it is not trust worthy and time taking. For example let us assume a survey need
to be conducted that focuses on “how many female customers have a trade license?” To conduct
this research, it is very difficult to look into all the box-files with a corresponding match. But if it
was a computerized system, the result will be received with in a second.

2.2 SYSTEM REQUEREMENT SPECIFICATION AND ANALSIS MODELING

(SRS)
2.2.1 Use case modeling

A use case is a sequence of action that provides a measurable value to an actor another
way to look at it is that a use case describes a way to which a real world to interacts with the
system. An essential use case sometimes called a business the case is simplified, abstract,
generalized use case that captures the intention of the user in a technology and implementation
independent manner.
The case models are used to document the behavioral (functional) requirement of a system or
the “what “of the system (Scott W. Ambler 2001)
 A use case describes a sequence of action that provides a measurable value to an actor
and draw as a horizontal ellipse.

 An actor is a person, organization, or external system that plays a role in one or more
interactions with the system and draw as stickman figure.
Relationship between actors and use cases exists whenever an actor is involved with an
interaction described by a use case and modeled as a line connecting use cases and actors.
Actor identification
1. Registration clerk.
2. Administrator.
3. Customer.
Use case identification

 Log in.
 Register traders.
 Creates account.
 Deletes account.
 Modifies/edit account.
 Cancels license.
 Renews license.
 Generate report.
 Provides license certificate.
 Search record.
 Print license.

System Use case diagram
Figure 1: use case diagram of trade registration

Use case description
Name: Log in.
Description: This describes how the actor logs into the System.
Pre-condition:The actor must have valid account & password.
Post-condition: The actor logged into the system get the available services.
Basic course of action:
1. The actor wants to log into the system.

2. The actor enters his/her user name and password.
3. The system validates the entered name and password and logs the actor into the
system.
4. The select the available service he wants.
5. The actor performs the registration process.
6. The actor updates the data base after providing the registration process.
7. Use case end.
Alternative course of actionA: The actor is Not Eligible to log in to the System.
A.2.The actor enters an invalid name and/or password, the system displays an error
message. The actor can choose to either return to the beginning of the Basic course of
action or cancel the login.
A.3.the system informs to enter username and password.
A.4.use case end.
Alternative course of actionB: The actor decides not to perform available services.
B.4. The actor views the list of services and does not see one which is critical to perform.
B.5. the use case ends

Name: Register traders.
Description: This describes how the trader is register in to the system.
Pre-condition:The system is in registration state and registration screen is displayed.
Post-condition: The system saves the information of trader and registration is informed to the
actor.
1. The trader applies to register.

2. The clerk enters trader information.
3. The trader gets the information from the system.
4. The actor validates the forms and gives to the registrar.
5. The system validates the information.
6. The system saves the information.
7. The actor already registers to the system.
8. The use case end
Alternative course of action A: The actor is not got information from the system.
A.3. the actor is not get the information available in that system and the system send a message
to the actor to know the information of the system.
A.4.the system informs to the actor to get the information.
A.5.the use case end.
A.4.the actor enters invalid information, the system displays error messages.
A.6.use case end.

Name: Creates account.
Description: The administrator creates an account for the customer those who comes to register
and license certification.
Pre-condition: The system is in the create account state and has the create account screen
displayed.
Post-condition: The system creates new account.
1. The administrator clicks create account button.

2. The administrator enters the user name and password.
3. The system prompts to confirm the password.
4. The administrator confirms password.
5. The system saves password and user name.
6. Verification message is displayed by the system.
7. If there is invalid information.

8. .System prompts error message on confirmation errors.
9. Use case end.

Name: Deletes account.
Description: administrator deletes an account of the customer when the leave the service.
Pre-condition: generating the customer’s request.
Post-condition: The system deletes account.
1. The administrator clicks delete account button.

2. The administrator enters the user name.
3. The system checks if user name exists.
4. The system prompts warning message.
5. The administrator clicks ok button on warning message box.
6. The system deletes account.
7. Verification message is displayed by the system.
8. Use case end.
Alternative course of action A: the user name is not exist
A.3.the system displays an error massage.

A.4. use case end.
Alternative course of action B: the warning massage box is not displayed.
B.5. the actor must have to return to the beginning page.
B.6.use case end.

Name: cancels license.
Description: This describes the cancelation flow and how to cancels when one user need to
interrupt the service.
Pre-condition: The system is in the cancels license state and has the cancels license screen
displayed.
Post-condition: The system cancels license.
1. The system prompts license cancellation form.

2. The administrator fills the form.
3. The administrator clicks cancel button.
4. The system prompts warning that data will be lost permanently.
5. The administrator clicks yes on the warning message.
6. The system removes the data and display message data is removed.
7. The system displays messages when the data to be removed is not exist on the
database.
8. Use case end.

Name: Generate reports.
Description: This is concerned with report generation on required information such as overall
trader registration, license renewal, and cancelation.
Pre-condition: The system is in the generate report state and has the generate report screen
displayed.
Post-condition: Trader status report is printed out.
1. The Registration clerk searches the trader data by using the registration number.
2. The system verifies if the data is found.
3. The system will display the data.
4. Registration clerk will see the trader details and click generate report button.
5. The system Print the report.
Alternative course of action:
A.4. the trader detail is not found the system prompts to re-search the data.
A.5. use case end.

2.2.2 CRC (Class Responsibility Collaboration)

A CRC model is a collection of standard index cards that have been divided into three
sections
CLASS – collection of similar objects
RESPONSIBILITY – something that a class knows or does
COLLABORATOR - another class that a class interacts with to fulfill its responsibilities
Admin<<actor>>
Name
Phone number Registration
Address
Creates account
Deletes account
Cancels license
Modifies account

license <<UI>>
License id Main menu screen
License number Administration
Tin number Request license
Cancel
renew
Registration clerk<<actor>>
Name
Phone number Trade requests
Address
Generates report
Renews license
Registers trader
Login
customer<<actor>>
Name
Phone number Registration request
Address
House number
Registration
FINAL YEAR PROJECT
request Page 23
Create account<<UI>>
Password Administration
Username
Login
Generate report<<UI>>
report screen displayed Clerk
2.2.3 Essential User Interface Prototyping

 Place where user directly interacts with systems.
 Low fidelity model, or prototype of the UI for your system.

 It represents the general ideas behind the UI, but not the exact details.
 Represents user interface requirements in a technology-independent manner.
 Beginning point of the user interface prototype for your system.
 Focus on your users and their usage of the system, not system features.
 Simple tools including whiteboards, flip chart paper and sticky notes.
 Don’t focus on the design.
Trade searcher
Trade number
Trade number Trade details
Registration request
Trade number
Trade name
Trade name
registration information
Trade name Trade list
Trade type Trade registration
Trade type and currently

taking
Registration items
and
Trade
requesting lists
description
Display request
Search request Details request
Trade location

Fig: User interface prototype
Help requester
2.3 Supplementary specification
BUSINESS RULES
 Business rules often pertain to
o Access control issues.
o business calculations or operating policies

and
o Principle of your organization.
The existing system has the following business rules:-
BR1. A Trader shall, before starting his Trade activity, apply for a
trade registration
By completing and submitting to the appropriate authority the application form,
Prescribed by the regulations, to which he shall attach the necessary documents;
BR2. An application for the alteration or modification of any entry of a trade
Registration shall be made to the appropriate authority within two months from the
Occurrence of such a situation by completing the application form prescribed by the
Regulation;
BR3. Where any application for registration is found acceptable, the appropriate
Authority shall register the applicant and issue a certificate of registration.
BR4. No person shall engage in any Trade activity unless registered in a trade register.
BR5. Any person shall principally register only once even though he carries on
Different Trade activities in different regions;

BR6. Although a trade name is one of the entries of a trade registration as provided for
Under Article 105 of the Registration number, trade registration shall be made without
Waiting for the registration of a trade name under Proclamation No. 67/1997.
BR7. The Trader shall submit, amongst others, together with the application, in two
Copies:
1. His recent passport size photograph;
2. A prior Trade and operating license, if any; Capital requirements: for someone to be registered
as a Trade man he/she has to have a capital of at least five thousand.
BR8. Trade workers can only renew their license if and only the paid the required payment
For their trade license renewal.
BR9. Cancelation period: if a trade license is not renewed within a year the licenses have by
No means is considered as legal trade license.
BR10. Renewal term: the term for trade license renewal is once a year from Hamile 1 E.C to
Thaisas 30 without penalty and from Tir 1 to Sene 30 E.C with penalty.
BR11. Age group: a trader can register if his/her age is greater than or equal to 18 years old.
BR12. Verifications: the registration will be successful if registering body has filled legal tax
Identification card number (TIN), can bring certificate of his capital from the bank and also
Bring a scanned copy of tax payment certificate.
BR13. Naming: the trade name has to be unique for each trader. And a registered company
And the trade name is the company’s name. This means the name of trade and company name
Must be the same.

2.3.1 FUNCTIONAL REQUIREMENTS

The following are the functional requirement that the system must meet:-
1. The system should allow registration of traders.

2. The system must allow the users to view the details of registered traders’ data from the
database.
3. The system must be capable of reporting functionality.
4. The system must be able renewal of the business license.
5. The system should allow license certification services.
6. The system is capable to allow cancellation of licenses.
7. The system must be able of updating, modifying and deleting of records.
2.3.2 NON FUNCTIONAL REQUIREMENTS

The system shall provide functionality to a single user on a Desktop computer without
failure in case of invalid inputs. In fact it is impractical to avoid errors but by checking the error
inputs and any invalid operations the system failure shall be reduced as possible.
 USABILITY
The system is supposed to be developed by using GUI supporting programming tools so

it will be easy for use.
The simplicity of the system for use shall be ensured by incorporating the following
functionalities into the system:-
 Well-structured user manuals.

 Informative error messages during invalid data entry and
 Well-formed graphical user interfaces.

 SECURITY
This is one of the project objective towards which we are working to achieve so the
following two securities are ensured to provide the system completely secure.
USER SECURITY
The system shall be password protected so anyone who has no user account and password
cannot get access to the system more over the access privileges to user is also limited to their
user account type
DATA SECURITY
As the system front-end is to be developed using modern programming languages, which

supports data security and the back-end is MYSQL. The system shall be secure because of those
modern programming languages supports’ data security by encapsulation and MYSQL database
is also password protected. We realize that by implementing a password protection only, we
cannot say an it’s fully secured, for e.g. eavesdropping (type of hacking) might be performed but
since this system is designed for intranet (LAN) purpose, vulnerability attacks as such will not
threaten the system.
 PERFORMANCE
Trade registration and licensing System shall not take longer than 15 seconds to respond to user.

2.3.3 Constraints
When developing and implementing the system, the constraints that we might face are: -
 The information of all user, must be stored in a database

 The design of the pages should be self-descriptive, which means it should not
mislead the user from using it correctly.
 Also the color used as background should not be harmful for the eyes of the user.
 Lack electric power.
 Lack of Internet connection or LAN.

 It’s not suitable for disable person, like blind people.
 Person that doesn’t have computer skill cannot operate the system.
 The system doesn’t work for those haven’t valid account.
2.4 ACTIVITY DIAGRAM

An activity diagram illustrates the dynamic nature of a system by modeling the flow of
control from activity to activity. An activity represents an operation on some class in the system
that results in a change in the state of the system. Typically, activity diagrams are used to model
workflow or business processes and internal operation. Because an activity diagram is a special
kind of state chart diagram, it uses some of the same modeling conventions. Activity diagrams
are mainly used as a flow chart consists of activities performed by the system. But activity
diagram are not exactly a flow chart as they have some additional capabilities. These additional
capabilities include branching, parallel flow etc.

Figure3:report activity diagram

Figure4: Login form activity diagram

Figure5: cancel License activity diagram

Figure6: delete Account activity diagram

Figure7: create an Account activity diagram

Figure 8: register trader activity diagram

CHAPTER Three
3 DESIGN DOCUMENT
3.1 Class modeling

Class diagrams describe the structure of the system in terms of objects, classes, attributes,
operations, and their associations. A class is an abstraction in object-oriented programming
languages. Like abstract data types, a class encapsulates both attributes and operation

 Class type layered approach.

 Inheritance relationship.
 Association relationship.
 Aggregation relationship.
 Composition relationship.
 Dependency relationship.
 Attributes.
 Methods.
 Municipality (cardinality and optimality)


3.2 SEQUENCE DIAGRAM
A sequence diagram is a UML interaction diagram. It represents the chronology of the
passing of messages between system objects and actors. It may be used to illustrate a possible
scenario of a use case, the execution of an operation, or simply an interaction scenario between
classes of the system.
You can use one or more sequence diagrams to pass a use case or to identify all the
possibilities of a complex behavior. A sequence diagrams conveys the same kind of information
it concentrates on the chronology of messages passing between the objects in place of their
structure.
A sequence diagram shows actors, objects (instances of classes) and the messages sent
between them. By default, Power Designer provides an "interaction frame", which surrounds the
objects in the diagram. Messages can originate from or be sent to any point on the interaction
frame, which acts as the exterior of the system being modeled, and these gates can be used in
place of actor objects

Main Window login link Login form Login Controller DB

: Register Clerk
1.clerk activates UI()
2.select login link()
3.display login form()
4.fill user name & password()
5.submit()
6.validate()
7.try again()
8. step 5 continue()
9.check()
10.Response()
Figure 9:login sequence diagram

report Link report Form report Controller DB

: Register Clerk
1.select report link()
2.Display report form()
3.fill report form()
4.submit()
5.Validate
6.Try Again()
7.Step 4 continue()
8.Check
9.Response()
Figure 10: report generating sequence diagram

Acc.Manager Acc.Manager Acc.Delete DB

: Admin
Link Form Controller
1.select Acc.Manager link()
2.Display Acc.Manager form()
3.fill delete criteria()
4.submit()
5.Validate
6.Try Again()
7.Step 4 continue()
8.Check
9.Response()
Figure11:delete account sequence diagram

License Link License Form License DB

: Admin
Controller
1.select license link()
2.Display license form()
3.fill license form()
4.submit()
5.Validate
6.Try Again()
7.Step 4 continue()
8.Check
9.Response()
Figure12:license cancelation sequence diagram

Account mgr Link Account create Account create DB

: Admin
Form Controller
1.select account link()
2.Display Account create form()
3.fill criteria to create account()
4.submit()
5.Validate
6.Try Again()
7.Step 4 continue()
8.Check
9.create()
10. Save
Figure13:create account sequence diagram

Register Link Register Form Register DB

: Register Clerk
Controller
1.select Register link()
2.Display Register form()
3.fill register form()
4.submit()
5.Validate
6.Try Again()
7.Step 4 continue()
8.Check
9.Response()
Figure14:trader registration sequence diagram

3.3 COLLABRATION DIAGRAM

A collaboration diagram is an illustration of the relationships and interactions among objects
in the unified modeling language.
1: 1.clerk activates UI()

Main 2: 2.select login link()
Window
login link
: Register Clerk 3: 3.display login form()

5: 5.submit()
6: 6.validate()
4: 4.fill user name & password()

9: 9.check()
Login
Controller 8: 8. step 5 continue()
Login form 7: 7.try again() DB
10: 10.Response()
Figure15: login collaboration diagram

report Link
1: 1.select report link()
3: 3.fill report form() report Form
2: 2.Display report form()
: Register Clerk
6: 6.Try Again()
9: 9.Response()
4: 4.submit()
8: 8.Check
5: 5.Validate
7: 7.Step 4 continue()
DB
report
Controller
Figure16: report generating collaboration diagram

Acc.Manager
Link
1: 1.select Acc.Manager link()
3: 3.fill delete criteria()

Acc.Manager
Form
2: 2.Display Acc.Manager form()

: Admin
6: 6.Try Again()
9: 9.Response()
4: 4.submit()
8: 8.Check
5: 5.Validate
DB
Acc.Delete
Controller
Figure17: delete account collaboration diagram

1: 1.select license link() License

Link
3: 3.fill license form()
License
Form
2: 2.Display license form()
: Admin
6: 6.Try Again()
4: 4.submit()
9: 9.Response()
5: 5.Validate
8: 8.Check
License
Controller DB
Figure18: cancel license collaboration diagram

Register
Link
1: 1.select Register link()
3: 3.fill register form()

Register
Form
2: 2.Display Register form()
: Register Clerk
6: 6.Try Again()
4: 4.submit() 9: 9.Response()
5: 5.Validate 8: 8.Check
Register DB
Controller
Figure19: register trader collaboration diagram

Account mgr
Link
1: 1.select account link()
3: 3.fill criteria to create account()

Account create
Form
2: 2.Display Account create form()

: Admin
6: 6.Try Again()
9: 9.create()
10: 10. Save
4: 4.submit()
5: 5.Validate 8: 8.Check
Account create DB
Controller
Figure20: create account collaboration diagram

3.4 USER INTERFACE DESIGN

Home Page: This form appears on the site in which the system deployed is opened and contains
some links which lead the user to other page according to his privilege, and if the user is authorized
user or has an account, he/she will directly go to the page that he want by entering correct
username ,password and role.
Fig16. Home Page

Fig17. Interface of Register Form

Fig18. Interface of Login Form
Fig19. Interface of Admin page

Fig20. Interface of Generate report

Fig21. Interface of Cancel license
Fig22. Interface of edit record

Fig23. Modification From
Fig24. Interface of create account

3.5 STATE CHART DIAGRAM

The state chart diagram used to show the sequence of states that an object goes
through the events that cause the transition from one state to the other and the actions that result
from a state change.
Initial state Idle Activate Login Normal exit Verify login
UN normal exit
Fail Evaluation
Final state
Confirm
Login
Complete state
Figure23: Login state chart diagram

intial state idle activate fill the form normal exit

send verify
request
un normal exit
Evaluation
leave the page
final state
confirm
request
complete state
Figure24: State chart diagram for trader register
intial state idle activate send search normal state verify search
request request
unnormal exit
book not found
Evaluate
final state
confirm
search
complete state
Figure25: State chart diagram for search trader

3.6 PERSISTENT MODELING/DATABASE DESIGN
3.6.1 DATABASE DESIGN
Database Design is the database structure that will be used as plan to Store and
manage the data. The database management system (DBMS) is the software used to implement a
database design. Modern database and applications development software is so easy to use that
many people can quickly learn to implement a simple database and Develop simple applications
within a week or so, without giving design.
Much thought, as data and reporting requirements become more complex, those same
people will simply and produce the required data by incorrectly adding more columns of tables
to the database

Figure26: database design diagram

3.6.2 Normalized physical database model
Before the normalization process the system has the following three Tables:
Register Table- This table has attributes: TIN number, Trade type, Trade name.
Person Table- has these attributes: FName, LName, Sex, DOB, country, city, sub city, kebele, wereda,
zone, house no, phone no.
License Table- has these attributes: TIN_No, Trade name, file number, issued date, register TIN no.
The above three tables will go through the normalization process as shown below:
1stNormal Form- the intersection of each row and column has only single value. Therefore the above
three table should be broken down as follows:
Register Table will be 1st normal form by decomposing the following attributes:
Trade type should be broken down in to supermarket and grocery.
Trade name should be broken down into Abebe, Almaz and Hagos.
Person Table will be 1st Normal form by decomposing:
Person name into- first name, middle name and last name.
License table will be in 1st Normal form by decomposing:
License should be broken down into renew license and cancel license.
2nd Normal Form- Each non primary key attribute is identified by the whole key (full functional
dependency). Therefore to achieve the 2nd normal form, the above tables should be broken down further
and it results the following table.
Register table (TIN number, Trade type, Trade name.)
Person Table (FName, LName, Sex, DOB, country, city, sub city, kebele, wereda, zone, house no, phone
no.)
License Table (TIN_No, Trade name, file number, issued date, register TIN no.)

3rd Normal Form- Non primary key attributes do not depend on each other (transitive dependency) The
3rd Normalization process will decompose person Table and license table & we obtain the following
additional table.
Person Type Table (user account, user account renew license, renew license)
After Normalization process, the entities, their attributes and their description are presented below.
Entity Description of Attributes Description of Attributes Data types Length

Entity
Clerk Registers TIN no Consists TIN No of the traders integer (20)

traders’s
Trade type Consists the type of trade Varchar (10)
information
Trade name Consists the name of the trade Varchar(20)
Table1: Register Table
Entity Description Attributes Description of Attributes Data types Length

of Entity
Administra Register the First Name Administrator first name Varchar(20)

tor traders
Last Name Administrators last Name Varchar (20)
Sex Consist administrator sex Varchar (5)
DOB Consist the date of birth of the Date

administrator
Table2: person Table

Entity Description of Attributes Description of Attributes Data types Length

Entity
Issued Contain the TIN no Consists the no of the license Integer (20)
paper traders
Trade name Consists the name of the trade Varchar (20)
permission
File no Consists the files number Integer(25)
Issued date Contain information about the Date

issued date
Register TIN no Contain the information about the Integer(20)

register TIN no
Table3: license Table
Entity Description Attributes Description of Attributes Data types

of Entity Length
person Register user account Contain information about the Varchar (20)
Type traders administrator
information
user account Consist information about the users Varchar (20)
renew license account for renewal license
renew license Consist the renewal request of Varchar (20)

traders
Table4: Person Type Table

3.7 Component diagram

In this Diagram components of the system will be wired showing that there is relation among
components, management of the system, database and operations performed on databases such
security issue. This in some extent shows which component or objects will be accessed by whom
and what type of security infrastructures it is using. The diagram is simulated below.
Fig27: Component Diagram

3.8 Deployment diagram
Deployment modeling is used to show the hardware of the system, the software that is installed
in the hardware and also the middleware that is used to connect the disparate machines to one
and other. It also shows how the software and the hardware components work together.
Fig28: Deployment Diagram

4 REFERENCE
1. Ambler, Scott (2001) The Object primer: The application Developers Guide to Object
Oriented and the UML.2nd rev. Ed England: The Cambridge University Press.
2. Bruegge, Bernd (2000) Object oriented Software Engineering Conquering Complex
and Changing System. Upper Saddle River: Prentic Hall.
3. Chopra, R.N (1999) Dictionary of Library Science. New Delhi Anmol Publication

Trade Registration and Licensing Sysytem

Uploaded by

Document Information

Original Description:

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

Trade Registration and Licensing Sysytem

Uploaded by

Copyright:

Available Formats

TRADE REGISTRATION & LICENSE SYSTEM 2015

It is important to include certifications and professional references, as well as a detailed

1.1.1 BACKGROUND ABOUT THE PROJECT

FINAL YEAR PROJECT Page 1

1.2 STATEMENT OF THE PROBLEM

FINAL YEAR PROJECT Page 2

1.3 OBJECTIVE OF THE PROJECT

1.3.1 GENERAL OBJECTIVE

1.3.2 SPECIFIC OBJECTIVES

 To solve the problems of the existing system

1.4.1 DESIGN METHODOLOGY

FINAL YEAR PROJECT Page 3

1.4.2 DATA GATHERING METHODOLOGY

1.5 SCOPE AND LIMITATIONS OF THE PROJECT

1.5.1 SCOPE OF THE PROJECT

 Registering information about the traders.

FINAL YEAR PROJECT Page 4

1.5.2 LIMITATION OF THE PROJECT

1.6 SIGNIFICANCE OF THE PROJECT

FINAL YEAR PROJECT Page 5

1.7.1 ECONOMIC FEASIBILITY

No Name of material Quantity Cost in birr Model

3 Paper 2 desta 90 180 A4

4 Print 50 1.5 75 …… The Adama town

5 CD 4 12 48 ……. trade registration

No Name material Quantity Cost in birr Model

Per unit Total

1 Desktop 6 3000 18000 ….

2 Digital Printer 2 12000 24000 ….

3 Software 1 50,000 50,000 Web based

4 Cable 2 50 100 RJ_45

Table 2: business material

1.7.2 TECHNICAL FEASIBILITY

1.7.3 OPRATIONAL FEASIBILITY

1.7.4 SCHEDULE FEASIBILITY

FINAL YEAR PROJECT Page 7

o Show start and completion dates for individual tasks

Task name Duration Start Finish Oct. Nov. Dec. Apr.

1.requirement 10 days 01/10/2017 11/10/2017

2.requirment 20 days 12/10/2017 01/11/2017

3.design 30 days 02/11/2017 02/12/2017

4.implementatio 03/12/2017 06/042017

5.testing& 20 days 07/04/2017 27/04/2017

Table 3: time schedule for the project

o Show order of activities

FINAL YEAR PROJECT Page 8

1.7.5 POLITICAL FEASI BILITY

1.8 Management issues

1.8.1 Team Configuration and communication plan

Task name Group member

System Requirement and specification Estifanos hagos

Analysts and Designer Bisrat fisaha

Implementation and Testing All group members

Table 4: team configuration

FINAL YEAR PROJECT Page 9

1.8.2 Communication plan

Table 5: team communication plan

FINAL YEAR PROJECT Page 10

2.1DESCRIPTION OF THE EXISTING SYSTEM

2.1.1 Why describe the existing system

2.1.2 OVERVIEW OF THE EXISTING SYSTEM

FINAL YEAR PROJECT Page 11

2.1.3 Report generating in the existing system