1.

Introduction

Systems design is the transformation of the analysis model into a system design model. This
section mainly concerned with the design part of the AIDANM system. This design document
presents the designs used or intended to be used in implementing the project. The designs
described, follow the requirements specified in the Software Requirements Specifications
document prepared for the project.

1.1. Purpose

The purpose of this document is to present a detailed description of the designs of the AIDANM
System, created for the BGRSB. Firstly, this document is intended for the programming group in
Team 1, to use the designs as guidelines to implement the project.

1.2. Design Goal

Defining design goals is the first step of the system design, which identifies the qualities that the
proposed system should focus on. Design goals represent the anticipated qualities of the system.
Most of the design goals of the system are derived from the non-functional requirements. The
design goals can be generally organized into performance, dependability, maintenance and
security. Design goals identify the qualities that the AIDANM system should focus on. The
following are the qualities of the AIDANM system that should be considered in designing the
system.

Performance Response time should be reasonable at any time. It also has to serve all parallel
users. Moreover since the system will be web-based application, it has to demand minimal memory
and reasonable processing power so that authenticate user can access it with available resources.

Security System users’ authentication with username and password are playing big roles in
ensuring security. Therefore, the system is secure from unauthorized user access.

Maintainability: The system should be extensible enough to incorporate additional functionalities

such like take non choice and practical exam online. It also should be easily modifiable when
requirements are changed. The programs should be platform independent so that it can be usable
with little modification. Also the code should be written using readable format for ease of
readability.
Dependability The system should be accessible as long as the internet connection are available.
The system should also be able to prompt the users for supplying user name and password before
appropriate access is granted. Moreover users may supply invalid input deliberately or because of
typing error, so the system should be able to validate all inputs supplied to the assigned control
value and must handle error using error handling mechanisms so that the user gets informed about
the errors and fix.

1.3. Scope

This document gives a detailed description of the software architecture of the AIDANM system.
It specifies the structure and design of some of the modules discussed in the SRS. It also displays
some of the use cases that had transformed into sequential and activity diagrams. The class
diagrams show how the programming team would implement the specific module.

1.4. Overview

This document is written according to the standards for Software Design Documentation explained
in “IEEE Recommended Practice for Software Design Documentation”. Sections 3 – 5 contain
discussions of the designs for the project with diagrams, section 6 shows samples of UI from the
system, and section 7 contains the class diagrams. The appendices contain the setup and
configuration needed for the UUIS, a list of functions that are implemented in this version, and
that are to be implemented in future version, and a list of tools and environment used in the entire
project, along with the time contribution of
team members. The appendices also include the test report and test cases.

1.5. Reference

1.6. Definition, Acronyms and Abbreviations

2. System Overview

Our proposed system have number of functionalities that perform inside the system. To make
clarity of the internal working process of the system for the end user and other system concerned
bodies we use number of UML diagram for each functionalities. Because system design is the
initial part to start the solution domain in a software development.
This section uses sequence diagram, which describe how groups of objects collaborate in some
behavior and sequence diagram show interaction between objects over specific period time as well
collaboration diagram, which illustrates several objects and the associations between them
describing architecture of the system. It also illustrates the collaboration of objects by passing
messages from one object to another; the persistent data management illustrates the relationship
between database tables.

Activity diagram which describe dynamic aspects of the system. It is basically a flow chart to
represent the flow form one activity to another activity. The activity can be described as an
operation of the system. The control flow is drawn from one operation to another

Finally deployment diagram which illustrates components deployed in to physical architecture of

the system. It shows the configuration of the hardware units (i.e. hardware for the system,
middleware to connect the separate machines) and how the software components are distributed
across the units.

3. System Architecture

This system architecture shows the overall organization and communication between the users, the
system, and its components: mobile phone client, web client and system server. Considering the
characteristics of the application anticipated by the client, the system is designed to have three-
tiered centralized client/server architecture. Following layered architectural style, the system will
have the user-interface level, the processing level and the data level. The user-interface layer
contains all that is necessary to directly interface with the user, such as display management. The
middle tier typically contains the processing logic. Finally at the bottom, the data level, actually
manages the data that is being acted on.

3.1. Proposed System Architecture

In this section we design the conceptual model of the Mobile based agricultural input data
collection and notification system. Here there are farmers who use this system on their cell phone
to get different services of the system. They can create account. During account creation the system
sends confirmation message to farmer to check whether the phone number is his/her. Once they
are registered they can submit and manage submitted data, manage their profile and send
complains to the server. When they submit data and send complains the system will store the data
and complains on the server database with their Id. There are also agricultural data collection office
workers (ADCOW) who uses web application on the internet enabled desktop computers to do
different operations. They can prepare form so that the farmers uses this form to provide data
needed, view and edit the data submitted from the farmers, generate reports based on the collected
data, and view different complains from the farmer.

The proposed software has three- tier architecture.

The presentation tier: is the top most level of the application. It is the one the clients directly
interacted.

It provides GUI to allow the client gaining access of the system.

Logical tier/ middle tier: It accepts inputs from the client and performs detailed processing. It is
a bridge between data access tier and presentation tier.

Data access tier: provides data persistence mechanism and storage to the data. It consists of a
mechanism to access the database without installing data base dependent drivers and libraries on
the client device.
3.2. Design Rational

4. Data Design

Databases are the store houses of data used in the software system. A database is a collection of
stored data organized in such a way that the data requirements are satisfied by the database. The
data is stored in tables inside a database. The general theme of database design is to handle
information as an integrated whole, with a minimum redundancy and improved performance.
Regardless of the type of data structure used, the objectives of the database are accuracy and
integrity and successful recovery from failure, privacy and security of data, and good overall
performance.

A table is designed as a collection of rows and columns, which are in turn called as tuples and
attributes. Tuple is nothing but a record in the table. A record is a collection of one or more
interrelated fields. The table is an object of Relational Database Management System (RDBMS),
which is used to store and retrieve the data much easier and faster. The tables should be carefully
designed because the efficiency of the software is based on the effective table design. Two essential
settings for a database are: -

 Primary key - The field that is unique for all the record occurrences.
 Foreign key - The field used to set relation between tables.

Normalization is a Technique to avoid redundancy in the tables. It is the transition of the data
models in to data structure. Database contains afield which is an Implementation of data attributes,
records which are a collection of fields and files and tables which are a collection of records. A
database which is simple, non-redundant, flexible and Adaptable is called good data model. If it is
not good data model system analyst can use Techniques called normalization to design it to make
simple, non-redundant, flexible and Adaptable. Database normalization is a series of steps
followed to obtain a database design that allows for Consistent storage and efficient access of data
in a relational database. These steps reduce data Redundancy and the risk of data becoming
inconsistent.

4.1. Entity Relationship Diagram

An entity-relationship diagram (ERD) is a graphical representation of an information system that

shows the relationship between people, objects, places, concepts or events within a system. An
ERD is a data modeling technique that can help define business processes and can be used as the
foundation for a relational database. Generally ERD has entity, Attribute and relationship.

 An entity is an atomic object that needs to be represented in the database. Entities are
represented by means of rectangles. Rectangles are named with the entity set they
represent.
 Attributes are the properties of entities. Attributes are represented by means of ellipses.
Every ellipse represents one attribute and is directly connected to its entity rectangle.
  A relationship is an association among several entities that needs to be represented in the
database. Relationships are represented by diamond-shaped box. Name of the relationship
is written inside the diamond-box. All the entities rectangles participating in a relationship
are connected to it by a line.

4.2. Data Dictionary

Field Name Data type Description

First name String Holds the First name of the farmer.
Last name String Holds the Last name of the farmer.
Kebeles String Describe the name of kebeles in which the farmer is found.
Woredas String Describe the name of woredas in which the farmer is found.
Zones String Describe the name of zones in which the farmer is found.
User Name String Describe the user name used when customer login to the system.
Password Varchar Describe the Id used when customer login to the account when he/she
perform some action.
Phone number integer Describes the phone address of farmers.
Field Name Data type Description
First name String Holds the First name of the employee.
Last name String Holds the Last name of the employee.
User Name String Describe the user name used when employee login to the
system.
Password Varchar Describe the password used when employee login to the account
when he/she perform some action.
Phone number integer Describes the phone of employee.
Address String Describes the address of employee

Field Name Data type Description

First name String Holds the First name of the administrator
Last name String Holds the Last name of the administrator
User Name String Describe the user name used when administrator login to the system.
Password Varchar Describe the password used when administrator login to the account
when he/she perform some action.
Phone number integer Describes the phone of administrator.
Address String Describes the address of administrator

Field Name Data type description

User name string Describe the user name used when user login to the system.
password varchar Describe the password used when user login to the account when
he/she perform some action.
Phone number integer Describes the phone user
Field name Data type description
Privilege type varchar The type that describe the type of the given privilege
Privilege id varchar Privilege id used to identify each privilege

Field name Data type description

report type varchar The type that describe the type of the given report
report date integer report date used to identify the report when generate

Field name Data type description

SMS type varchar The type that describe the type of the given SMS
SMS id integer SMS id used to identify each SMS

Field name Data type description

news type varchar The type that describe the type of the given news
news id integer news id used to identify each news

Field name Data type description

data type varchar The type that describe the type of the given data
data id integer data id used to identify each data

Field name Data type description

Complain type varchar Used to describe the type of complain from the farmer
4.3. Persistence Modeling
 5. Component Design

5.1. Logical Modeling

5.2. Interaction Modeling

5.2.1. Activity Diagram

An activity diagram shows the flow of activity to activity. Activity diagram is another important
diagram in UML to describe dynamic aspects of the system. Activity diagram is basically a flow
chart to represent the flow form one activity to another activity. The activity can be described as
an operation of the system. So the control flow is drawn from one operation to another. This flow
can be sequential, branched or concurrent. In projects in which use cases are present, activity
diagrams can model a specific use case at a more detailed level

5.2.2. Sequence Diagram

Sequence diagrams are used to model the logic of usage scenarios. Usage scenario is exactly which
its name indicates-the description of a potential way of the system is used. The logic of Usage
scenario developed here comprises the basic course of actions. The team use sequence Diagram in
order to easily define sequence of tasks that accomplished by the actors of the system. The
sequence diagram makes the system very flexible and understandable by users of the System. The
sequence diagram shows order of operations those enhances actors to perform Expected tasks
correctly. Where an actor is placed on a sequence diagram is important. Regardless of where an
actor is placed vertically, actors are always arranged horizontally with no two participants
overlapping each other. The boxes across top of the diagram represent classifiers or their instances;
typically use cases, Objects, classes or actors.

The dashed lines hanging from the boxes are called objects lifelines, representing the life span of
object during the scenario being modeled. The long, thin boxes on the long life lines are Method
invocation boxes indicating that the target object (class) to fulfill a message is performing
Processing. Messages indicate as labeled arrows, when the source and the target of a message is
an object or class label the signature of the method invoked in response to the message. However,
if either the source or target is the human actor, then the message is labeled with brief Text
describing the information is available.

5.2.3. Collaboration Diagram

A collaboration diagram, also called a communication diagram or interaction diagram, is an

illustration of the relationships and interactions among software objects. A collaboration diagram
shows an interaction organized around the objects in the interaction and their links to each other.
Unlike a sequence diagram, a collaboration diagram shows the relationships among the objects.
On the other hand, a collaboration diagram does not show time as a separate dimension, so
sequence numbers determine the sequence of messages and the concurrent threads.
5.3. State Dynamic Modeling

A State chart diagram describes a state machine. Now to clarify it state machine can be defined as
a machine which defines different states of an object and these states are controlled by external or
internal events. State chart diagram describes the flow of control from one state to another state.
States are defined as a condition in which an object exists and it changes when some event is
triggered. State chart diagrams are very important for describing the states. States can be identified
as the condition of objects when a particular event occurs. Before drawing a State chart diagram
we must have clarified the following points:-

 Identify important objects to be analyzed.

 Identify the states.
 Identify the events.

5.4. Dependency Modeling

5.4.1. Subsystem Decomposition

Subsystem decomposition describes the decomposition of systems into subsystems and the
responsibilities of each. This is the main product of system design. The main purpose of the
subsystem decomposition is reducing the complexity of the system. Agricultural Input Data and
Notification Management System consists of the following subsystem decomposition.
5.4.2. Component Diagram

The main purpose of the component diagram is to know the structural relationship between the
Components of the system. In UML a component diagram represent implementation items.
Generally components are considered autonomous, encapsulated unites with in a system or
Subsystem things that will typically be implemented using replaceable models.

In component based development, component diagrams after architects a natural format to begin
modeling a solution. Component diagram allow an architect to verify that a system’s required
Functionality is being implemented by components thus ensuring that the eventual systems will be
acceptable. Developers find the component diagram useful because it provides them with a high
level Architectural view of the system that they will be building .which helps developers being
formalizing a roadmap for the implementation and make decision about task assignments and
needed skill enhancement.

5.4.3. Deployment Diagram

Deployment diagrams show the physical view of the system, bringing the software into the Real
world by showing how software gets assigned to hardware and how the pieces communicate. In
other words, it shows which component of the software will install on which machine and how
they communicate with each other if they are on different machines. It is also used to show a
collection of nodes and also dependencies of associations among them. The associations between
nodes Represents a physical connection. The physical deployment Model provides a detailed
model of the way components will be deployed across the system Infrastructure. It details network
capabilities, server specifications, hardware requirements and other information related to
deploying the proposed system. The deployment diagram shows how a system will be physically
deployed in the working environment. Its purpose is to show where the different components of
the system will physically run and how they will communicate with each other. Deployment
diagrams shows how they are deployed in hardware. It is used to show the relationship among
run-time components and hardware nodes. It is representing the allocation of components to
different nodes and the dependencies among components.
6. Human Interface Design

6.1. Overview of User Interface

6.2. Screen Images

6.3. Screen Objects and Actions