TY BSc.IT Blackbook Main Report

Repair Shop Management System
1 | P a g e
MAIN REPORT

2 | P a g e
1. INTRODUCTION
1.1 Organizational Profile
 Name of the Organization : A-1 Electronic Shop
 Situated at : Thane-400605.
 Year of establishment : 2001.
 Type of organization : Repair Shop.
 Address : Shop no 26, Near Shivaji Hospital, Kalwa
 Phone : 9892404231
 Email : a-1electronicshop@gmail.com
Modules:
There are mainly 2 modules in this software, Admin (Client) Module and User
(Client’s Customers) Module. In this system user can register using the app. User has
the power to add new appointments and can edit and delete a equipments detail. The
user can update his/her information. Admin can see the all information.
 Admin Module
 User Module
1.2 Introduction to Project
Repair Shop Management project is a user friendly software developed in Android
Studio as front end and SQLite database as back end. This project is designed to save
the data of all those persons who want to hire services of our client, which will reduce
manual work and helps the owner to save the records efficiently. This project is aimed
at developing a Repair Shop Software. It provides the simplest, cheapest and an less
time and energy consuming way of Tranck record and arrange appointments. In old
days, the Owner of the shop may have to keep records of the appointments manually.
This method of keeping the records is quiet time consuming and less efficient.

3 | P a g e
Also there are more chances of mistakes by keeping the records manually as
human beings are habitual of doing mistakes. So with the help of this, Repair Shop
Software, the chances of mistakes becomes very few. Also it is very efficient method of
keeping the records of appointmnets sold as well as tracking records of previous
repairs. It consumes very less time as compared to manual method. The application is
divided into three modules. The admin i.e. the Shop owner itself handles the whole
software . He managed the database as well as all the records.
1.2.1 Objective and Scope of Project
Objective:
The main aim of this project is to manage the transactions, make
payments online, Search records, manage the appointments. This can be enabled
to make online so that anyone can fix appointment by sitting at their own place.
Also searching should be very faster so they can find required details instantly.
The purpose of this project is to build an application program to reduce the
manual work for managing the Repair Shop. It tracks all the details of the user.
Basically the project describes how to manage for good performance and better
services for the user.
Functionalities/Modules of the project:
This project has the following functionalities/modules, to manage all the
requirements of the blood bank:
1. Manage the information and efficiency of Repair Shop.
2. Manage the information of the appointments.
3. Shows the information and details of customer.
4. Tracks the information of workshop equipment, delivery and archive.
5. Manage the feedback details.
6. Sends bill and reports over email.
7. Deals with monitoring the information and transaction of repaired items.
Scope:
This software can be used by an Repair shop owner so that he can
manage all his work digitally. This will reduce the paper work. This can also be
used by customers to track records of his equipments at any given time. This
application may help perfectly managing the details. In very short time, the
collection will be obvious, simple and sensible. It will help a person to know the
management of passed year perfectly and vividly.
 In computer system the person has to fill the various forms and number
of copies of the forms can be easily generated at a time.

4 | P a g e
 In computer system, it is not necessary to create the manifest but we can
directly print it; which saves our time.
 To utilize resources in an efficient manner by increasing the productivity
through automation.
 The system generates types of information that can be used for various
purposes.
 It satisfies the user requirement.
 Be easy to understand by the user and the operator.
 Be easy to operate.
 Have a good user interface.
1.2.2 Theoretical Background
A-1 Electronics is a Repair shop that deals with the repairing of equipments of customer.
It manages the details of each and every user. It provide services to customer such as
home pickup and repaired equipment delivery. It has some rule and regulation that must
be followed by the user. It keeps the record of day-to-day transaction of business and
record manually.
1.2.3 Definition of Problem
The Shop is having the records of the user in written format or sometime oral speech
which may lead to loss of some data. So, the repair shop is looking at simple and effective
system to solve this problem.

5 | P a g e
2. SYSTEM STUDY AND ANALYSIS
2.1 Problem Definition
The Repair Shop was suffering from a series of drawbacks. Since whole of the system
was to be maintained in a written format which may lead to loss of some or the other
data. The records are entered in the diary. Because of this there is a huge collection
loose pages, which would take more time for gathering the information of a particular
Customer. There would always be unnecessary consumption of time while entering
records and retrieving records. One more problem was that it was very difficult to find
errors while entering the records. Once the records were entered it was very difficult to
update these records. To avoid all this chaos we have provided many features. Present
system is partially automated (computerized), actually existing system is quite
laborious as one has to enter same information at many different places.
2.2 Feasibility
Feasibility study is conducted once the problem is clearly understood. Feasibility study
is a high level capsule version of the entire system analysis and design process. The
objective is to determine quickly at a minimum expense how to solve a problem. The
purpose of feasibility is not to solve the problem but to determine if the problem is worth
solving.
The system has been tested for feasibility in the following points.
1. Technical Feasibility.
2. Cost Feasibility.
3. Market Feasibility.
4. Operational Feasibility.
2.2.1.Technical Feasibility:
The project’shardware configurationrequirementinbothdeveloperandclientside is
verylesswhichmakesittechnicallyfeasible.Alsoitisusesadatabase made inSQLite
whichmakesiteasyto use as the software are easilyavailable.Itiscompletelymade
inAndroidStudioandthuseasyfor furtherdevelopmentsandchanges.The Language
usedto developmentisJavaandXML whichisverypopularand easyto understand.

6 | P a g e
2.2.2.Cost Feasibility:
The project is economical to develop, as all the technology used is open source.
Also software like SQLite and Android Studio is available freely on from the
internet. Also the hardware used is very standard without any special requirement
needed.
2.2.2.Market Feasibility:
As the project is an Android based application it is very feasible. As Android
Smartphone being a very common device these days the applications use becomes
very easy once a phone is configured.
2.2.3. Operational Feasibility:
The project is operationally very feasible as it over comes all the problems faced
by the old system. Also it Digitalize the current system eliminating the usage of
external medium like paper and pen.
2.3 System Analysis
System Analysis is the process of gathering and interpreting facts, diagnosing
problems and the information about the blood bank management system to recommend
improvements on the system. It is a problem solving activity that requires intensive
communication between the system users and system developers. System analysis or
study is an important phase of any system development process. The system is studied to
the minutest detail and analyzed. The system analyst plays the role of the interrogator
and dwells deep into the working of the present system. The system is viewed as a whole
and the input to the system are identified. The outputs from the organizations are traced
to various processes.
System analysis is considered with becoming aware of the problem,
identifying the relevant and decisional variables, analyzing and synthesizing the various
factors and determining an optimal or at least a satisfactory solution or program of action.
A detailed study of the process must be made by various techniques like interviews,
questionnaires etc. The data collected by these sources must be scrutinized to arrive to a
conclusion. The conclusion is an understanding of how the system functions. This system
is called as an existing system. Now the existing system is subjected to close study and
problems are identified. The designer now functions as the problem solver and tries to
sort out the difficulties that the enterprise faces. The solutions are given as proposals.
The proposal is then weighed with the existing system analytically and the best one is
selected. The proposal is presented to the user for an endorsement by the user. The
proposal is reviewed on the user request and suitable changes are made. This loop ends
as soon as the user is satisfied with the proposal.

7 | P a g e
2.4 Current System
The Shop Manager keeps records of the appointments manually on the papers. This
method of keeping the records is quiet time consuming and less efficient. Also there are
more chances of mistakes by keeping the records manually as human beings are
habitual of doing mistakes. There are several types of cost associated with manual
records.
2.5 Proposed system
The aim is to automate the existing manual system by the help of computerized
equipment and full-fledged computer software, fulfilling their requirements, so that
their valuable data/information can be stored for a longer period with easy accessing
and manipulation of the same. This system keeps the record of appointments,workshop
equipment and delivery data which can be easily updatable and deletable. Basically the
project describes how to manage for good performance and better services for the
client.
Advantages of the proposed system are:
 All the records and data have been computerized and are now persistent.
 Manual calculations have been automated.
 Access to all types of records made easy.
 The proposed system is a computerized system.
 Paper work is avoid.
 This system is User-friendly, interactive and easy to use.
 Save excess paper work.
 Time saving.
 No complexities.
 Data security and backup facility.

8 | P a g e
3. SYSTEM DEVELOPMENT
3.1 Gantt chart
A Gantt chart is a type of bar chart that illustrates a project schedule. Modern Gantt
charts also show the dependency relationships between activities and current schedule
status.
EXPECTED TIME ACTUAL TIME
Month
November December January February
Weeks Weeks Weeks Weeks
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Planning
Requirement
gathering
Analysis
Design
Coding
Testing
Implementation

9 | P a g e
3.2 LogicalDesign
The model based on which the project is delveloped is waterfall model. We
have choosen is model a this is a small scale project and it’s limitation can easily be
overcome and it can be easily implemented.
The Waterfall Model was the first Process Model to be introduced. It is also
referred to as a linear-sequential life cycle model. It is very simple to understand and
use. In a waterfall model, each phase must be completed before the next phase can
begin and there is no overlapping in the phases. The Waterfall model is the earliest
SDLC approach that was used for software development.
The waterfall Model illustrates the software development process in a linear
sequential flow. This means that any phase in the development process begins only if
the previous phase is complete. In this waterfall model, the phases do not overlap.

10 | P a g e
3.3 Use Case Diagram
Actor: A coherent set of roles that users of use cases play when interacting with the use
cases.
Use case: A description of sequence of actions, including variants, that a system performs
that yields an observable result of value of an actor.

11 | P a g e
3.4 Class Diagram
The class diagram is the main building block of object-oriented modeling. It is used for
general conceptual modeling of the systematic of the application, and for detailed
modeling translating the models into programming code. Class diagrams can also be used
for data modeling. The classes in a class diagram represent both the main elements,
interactions in the application, and the classes to be programmed.

12 | P a g e
3.5 Event Table
The event table is a table of data that is typically written to the logfile for
each scenario and also appears in the Analysis window. The event table contains timing
information about specific events that occur during the scenario. Only stimulus events
with event codes will appear in the event table.
ID Event Trigger Source Use Case Response Destination
1. Admin Login Login Status
Page
Admin Login Page Authenticates
Username &
Password
Admin
2. Appointment
request
New
Appointment
request
Customer Fixes
Appointment
Add
Appointment
data in
database
Admin
3. Checking of
appointments
Displaying List
of
Appointments
Admin Manages
Appointments
for Repairs
Fetches List of
Appointments
from Database
Admin
4. Checking of
Equipments to
be repaired
Displaying list
of Workshop
items
Admin Repairs the
equipment
Fetches List of
Workshop
items from
Database
Admin
5. Checking of
Equipments to
be Delivered
Displaying list
of Delivery
items
Admin Deliver the
equipment
Fetches List of
Delivery items
from Database
Customer
6. Payment
request
Total cost Customer Payment is
done
Final Payment
is done
Admin
7. Inventory
Management
Inventory
checklist
Admin Manages
inventory
Inventory
items gets
modified
Admin

13 | P a g e
3.6 Sequence Diagram
A sequence diagram in a Unified Modeling Language (UML) is a kind of interaction
diagram that shows how processes operate with one another and in what order. It
depicts the objects and classes involved in the scenario and the sequence of messages
exchanged between the objects needed to carry out the functionality of the scenario.

14 | P a g e
3.7 E-R Diagram
Entity-relationship (ER) diagram is a graphical representation of entities and their
relationships to each other, typically used in computing in regard to the organizations of
data within databases or information systems. An entity is a piece of data-an object or
concept about which data is stored.
Connectivity And Cardinality:
The basic types of connectivity for relations are: one-to-one, one-to-many, and many-
to-many. A one-to-one (1:1) relationship is when utmost one instance of an entity A is
associated with one instance of entity B. A one-to-many (1:N) relationships is when for
one instance of entity A, there are zero, one, or many instances of entity B, but for one
instance of entity B, there is only one instance of entity A. A many-to-many (M:N)
relationship, sometimes called non-specific, is when for one instance of entity A, there
are zero, one, or many instances of entity B and for one instance of entity B there are
zero, one, or many instances of entity A. The connectivity of a relationship describes the
mapping of associate.
Er Notation:
 Entities are represented by labeled rectangles. The label is the name of the entity.
Entity names should be singular nouns.
 Relationships are represented by a solid line connecting two entities. The name
of the relationship is written above the line. Relationship names should be verbs.
 Attributes, when included, are listed inside the entity rectangle. Attributes which
are identifiers are underlined. Attribute names should be singular nouns.
 Cardinality of many is represented by a line ending in a crow's foot. If the crow's
foot is omitted, the cardinality is one.
 Existence is represented by placing a circle or a perpendicular bar on the line.
Mandatory existence is shown by the bar (looks like a 1) next to the entity for an
instance is required. Optional existence is shown by placing a circle next to the
entity that is optional.

15 | P a g e

16 | P a g e
3.8 Data Flow Diagrams
A data flow diagram (DFD) is a graphical representation of the "flow" of data through
an information system, modeling its process aspects. Often they are a preliminary step
used to create an overview of the system which can later be elaborated DFDs can also
be used for the visualization of data processing (structured design).
Rules For DFD:
 Fix the scope of the system by means of context diagrams.
 Organize the DFD so that the main sequence of the actions.
 Reads left to right and top to bottom.
 Identify all inputs and outputs.
 Identify and label each process internal to the system with Rounded circles.
 A process is required for all the data transformation and Transfers. Therefore,
never connect a data store to a data Source or the destinations or another data
store with just a Data flow arrow.
 Do not indicate hardware and ignore control information.
 Make sure the names of the processes accurately convey everything the process
is done.
 There must not be unnamed process.
 Indicate external sources and destinations of the data, with Squares.
 Number each occurrence of repeated external entities.
 Identify all data flows for each process step, except simple Record retrievals.
 Label data flow on each arrow.
 Use details flow on each arrow.
 Use the details flow arrow to indicate data movements.
Arrow:-An arrow identifies data or data in motion, it is a pipeline through which
information flows.
Circle or Bubble:- It represents a process transforms in coming in data flow in to
outgoing data flow.

17 | P a g e
Open rectangle:-It is data store or data at rest.
3.8.1 Context Diagram

18 | P a g e
3.8.2 Diagram 0
3.8.3 DFD Fragments
First level:

19 | P a g e
3.8.4 Structure Charts
A Structure Chart (SC) in software engineering and organizational theory is
a chart which shows the breakdown of a system to its lowest manageable levels.[2] They
are used in structured programming to arrange program modules into a tree. Each module
is represented by a box, which contains the module's name. The tree structure visualizes
the relationships between modules.

20 | P a g e
3.8.5 System Flow Chart
A flowchart is a type of diagram that represents an algorithm, workflow or process,
showing the steps as boxes of various kinds, and their order by connecting them with
arrows. This diagrammatic representation illustrates a solution model to a given problem.
Flowcharts are used in analyzing, designing, documenting or managing a process or
program in various fields.

21 | P a g e
3.8.6 Menu Tree
A tree diagram is a diagram used in strategic decision making, valuation or probability
calculations. The diagram starts at a single node, with branches emanating to additional
nodes, which represent mutually exclusive decisions or events. In the diagram below, the
analysis will begin at the first blank node.

22 | P a g e
3.9 Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and
actions with support for choice, iteration and concurrency. Activity diagram is basically
a flow chart to represent the flow from one activity to another activity. The activity can
be described as an operation of the system

23 | P a g e
4. PROGRAM LIST
JAVA:
Appointment.java
DisplayAppointment.java
EditAppointmnet.java
NewAppointment.java
Archive.java
DisplayArchive.java
EditCustomer.java
FeedbackCustomer.java
ForgotPassword.java
Profile.java
Registration.java
SetAppointment.java
DBHelper.java
Delivery.java
DisplayDeliver.java
EditDelivery.java
AddComponent.java
EditComponent.java
EditSearchComponent.java
Inventory.java
InventoryAdapter.java
Notes.java
QtyCheck.java
QtyUpdate,java
Report.java
DisplayWorkshop.java
EditWorkshop.java
NewWorkshop.java
SwitchWorkshop.java
Workshop.java
Album.java
CustomerLogin.java
LoginTab.java
MainActivity.java
Myapp.java
SplashScreen.java
Welcome.java
MANIFEST:
AndroidManifest.xml

24 | P a g e
XML:
activity_add_component
activity_appointment
activity_archive
activity_customer_login
activity_customer_profile
activity_delivery
activity_edit_component
activity_edit_search_component
activity_feedback_admin
activity_feedback_customer
activity_forgot_password
activity_inventory
activity_login_tab
activity_main
activity_new_appointment
activity_new_workshop
activity_notes
activity_qtycheck
activity_qtyupdate
activity_registration
activity_report
activity_set_appointment
activity_splash_screen
activity_welcome
activity_workshop
admin_card
app_bar_feedback_customer
app_bar_set_appointment
app_baradminfeedback
app_barappointment
app_bararchive
app_barcustomer
app_bardeliver
app_barinventory
app_barwelcome
app_barworkshop
appointment_listview_row
archive_listview_row
content_adminfeedback
content_appointment
content_archive
content_customter
content_delivery
content_fan_data

25 | P a g e
content_feedback_customer
content_inventory
content_set_appointment
content_welcome
content_workshop
delivery_listview_row
form_appointment_display
form_appointment_edit
form_archive_display
form_delivery_display
form_delivery_edit
form_workshop_display
form_workshop_edit
form_workshop_std
nav_header_main2
simple_listview_1
simple_listview_2
workshop_listview_row

26 | P a g e
5. TABLE LIST
1)Table: Appointment
Name Data type Length Constraints
Appointment_id Integer 10 Primary Key
Customer_id Integer 10 Foreign Key
Customer_name Text 20 Not Null
Date Text - Not Null
Phone_no Integer 10 Not Null
Address Text 30 Not Null
Problem Text 30 Not Null
2)Table: Workshop
Workshop_id Integer 10 Primary Key

27 | P a g e
3)Table: Delivery
Physical Design
Delivery_id Integer 10 Primary Key
Solution Text 30 Not Null
Price Integer 4 Not Null
4)Table: Archive
Archive_id Integer 10 Primary Key
Date_entry Text - Not Null
Date_exit Text - Not Null

28 | P a g e
Solution Text 30 Not Null
Price Integer 4 Not Null
5)Table: Inventory
Item_id Integer 10 Primary Key
Item_category Text 20 Not Null
Item_name Text 20 Not Null
Qty Integer 2 Not Null
Unit_price Integer 5 Not Null
Total_price Integer 5 Not Null
6)Table: Report
Report_id Integer 10 Primary Key
Time Text - Not Null
Item_category Text 20 Not Null
Item_name Text 20 Not Null
Qty Integer 2 Not null

29 | P a g e
7)Table: Customer
Customer_id Integer 10 Primary Key
Gender Text 6 Not Null
Email_id Text 40 Not Null
Username Text 20 Not Null
Password Text 20 Not Null
Status Text 3 Not Null
8)Table: Feedback
Feedback_id Integer 10 Primary Key
Time Text - Not Null
Type Text 10 Not Null
Comment Text 40 Not Null

30 | P a g e
6. REPORT LIST
 Reports of All Appointments
 Reports of All Workshop equipments
 Reports of All Delivery Items
 Reports of All Archive Items
 Reports of All Inventory Items

31 | P a g e
7. SYSTEM TESTING AND CONCLUSION
Unit Testing:-
This is the testing process which we can do manually because in this testing program is
a tested individually using dummy record to see whether that program produce satisfied
output as the company and validation also.
Validation Testing:-
In this requirements established as part of software requirements analysis are validated
against the software that has been constructed. Validation testing provides final
Assurance that software meets all functional, behavioral and performance requirements.
Validation can be define in many ways but a simple definition is that validation
succeeds when software Function in a manner that can be reasonably by the customer.
1. Validation test criteria
2. Configuration review
3. Alpha and Beta testing (conducted by end user)
System Testing:-
System testing is actually a series different test whose primary purpose is to full
exercise the computer base system .Where the software and other system elements are
tested as whole .To test computer software, we spiral out along streamlines that
broadens the scope of testing with each turn. The last higher-order testing step falls
outside the boundary of software Engineering and in to the broader context of computer
system engineering, Software once validated, must be combining with order system
elements (e.g.hardware,people,databases). System testing verifies that all the elements
Mesh properly and that overall system function/performance is achieved.
1. Recovery Testing
2. Security Testing
3. Stress Testing

32 | P a g e
TestCases:-
Sr.
No
Name Input Expected
Output
Actual
Output
Remark
1 Admin
Login Page
Valid
credentials
Navigates
Admin to
Home Page
Navigates
Admin to
Home Page
Pass
2 User Login
Page
InValid
credentials
Popup
showing
invalid
password for
user
Popup
showing
invalid
password for
user
Pass
3 Registration
Page
Valid
credentials
Navigates to
login page of
user
Navigates to
login page of
user
Pass
4 Registration
Page
Existing
credentials
Popup
showing
User exist &
Navigates to
Registration
Popup
showing
User exist &
Navigates to
Registration
pass
5 Add
Appointmnet
Valid
credential
Add data and
navigate to
appointments
Add data and
navigate to
appointments
pass
6 Add
workshop
detail
Invalid
credential
Popup
showing
invalid data
Popup
showing
invalid data
pass
7 Archive
search
Enter non
existing data
Popup
showing data
not found
Popup
showing data
not found
pass

33 | P a g e
8 Inventory
update
quantity
Invalid id Popup
showing id
not found
Popup
showing id
not found
pass
9 Inventory
add item
Valid
credential
Data added
& navigate
to inventory
Data added
& navigate
to inventory
pass
10 Provide a
Feedback
Ratings and
Opinions of
User
Save
Feedback of
User in
database
Save
Feedback of
User in
database
pass
Conclusion of the project Repair Shop Management System
Our project is only a humble venture to satisfy the needs to manage their project work.
Several user friendly coding have also adopted. This package shall prove to be a
powerful package in satisfying all the requirements. The objective of software planning
is to provide a frame work that enables the manager to make reasonable estimates made
within a limited time frame at the beginning of the software project and should be
updated regularly as the project progress.
At the end it is concluded that we have made effort on following points:
 A description of the background and context of the project and its relation to
work already done in the area.
 Made statement of the aims and objectives of the project.
 The description of purpose, scope and applicability.
 We define the problem on which we are working in the project.
 We describe the requirement specifications of the system and the actions that
can be done on these things.
 We understand the problem domain and produce a model of the system, which
describes operations that can be performed on the system.
 We included features and operations in details, including screen layouts.
 We designed user interface and security issues related to system.
 Finally the system is implemented and tested according to test cases.

34 | P a g e
8. DATA ENTRY FORM
Admin Login Form Customer Login Form
Cutomer Registration Form Customer Appointment Form

35 | P a g e
Customer Feedback Form Admin Appointment Form
Admin Workshop Form Switch to Delivery Form

36 | P a g e
Inventory Item Form Quantity Update Form
Note Entry Form Archive Search Form

37 | P a g e
9. CODING CONVENTIONS
Conventions
We follow standard Java coding conventions. We add a few Android specific rules.
Package and Import Statements
The first non-comment line of most Java source files is a package statement. After that,
import statements can follow. For example:
package java.Activity;
import java.awt.peer.CanvasPeer;
Order Import Statements
The ordering of import statements is:
1. Android imports
2. Imports from third parties (com, junit, net, org)
3. java and javax
To exactly match the IDE settings, the imports should be:
 Alphabetical within each grouping, with capital letters before lower case letters (e.g.
Z before a).
 There should be a blank line between each major grouping (android, com, junit, net,
org, java, javax).
Fully Qualify Imports
When you want to use class Bar from package foo, there are two possible ways to
import it: import foo.*;
import foo.Bar;
Use the latter for importing all Android code. An explicit exception is made for java
standard libraries (java.util.*, java.io.*, etc.) and unit test code (junit.framework.*)
Number per Line
One declaration per line is recommended since it encourages commenting. In other
words,

38 | P a g e
int level; // indentation level
int size; // size of table
Class and Interface Declarations
When coding Java classes and interfaces, the following formatting rules should be
followed:
• No space between a method name and the parenthesis “(“starting its parameter list
• Open brace “{” appears at the end of the same line as the declaration statement
• Closing brace “}” starts a line by itself indented to match its corresponding opening
statement, except when it is a null statement the “}” should appear immediately after
the “{“ 2
class Sample extends Object {
int ivar1;
int ivar2;
Sample(int i, int j)
{
ivar1 = i; ivar2 = j;
}
int emptyMethod(){}
...
}
 Methods are separated by a blank line
Use Spaces for Indentation
We use 4 space indents for blocks. We never use tabs. When in doubt, be consistent
with code around you. We use 8 space indents for line wraps, including function calls
and assignments. For example, this is correct:
Instrument i = someLongExpression(that, wouldNotFit, on, one, line);
and this is not correct:
Instrument i = someLongExpression(that, wouldNotFit, on, one, line);

39 | P a g e
Follow Field Naming Conventions
 Non-public, non-static field names start with m.
 Static field names start with s.
 Other fields start with a lower case letter.
 Public static final fields (constants) are ALL_CAPS_WITH_UNDERSCORES.
For example:
public class MyClass
{
public static final int SOME_CONSTANT = 42;
public int publicField;
private static MyClass sSingleton;
int mPackagePrivate;
private int mPrivate;
protected int mProtected;
}
Naming Conventions
Naming conventions make programs more understandable by making them easier to
read. They can also give information about the function of the identifier-for example,
whether it's a constant, package, or class-which can be helpful in understanding the
code.
Packages: The prefix of a unique package name is always written in all lowercase
ASCII letters and should be one of the top-level domain names, currently com, edu,
Gov., mil, net, org, or one of the English two-letter codes identifying countries as
specified in ISO Standard 3166, 1981. Subsequent components of the package name
vary according to an organization's own internal naming conventions. Such conventions
might specify that certain directory name components be division, department, project,
machine, or login names.
For example:
com.sun.eng
com.apple.quicktime.v2
edu.cmu.cs.bovik.cheese
Classes: Class names should be nouns, in mixed case with the first letter of each
internal word capitalized. Try to keep your class names simple and descriptive. Use

40 | P a g e
whole words-avoid acronyms and abbreviations (unless the abbreviation is much more
widely used than the long form, such as URL or HTML).
For example:
class Raster;
class ImageSprite;
Interfaces: Interface names should be capitalized like class names and always prefix
with capital “I”.
For example:
interface IDelegate;
interface IStoring;
Methods: Methods should be verbs, in mixed case with the first letter lowercase, with
the first letter of each internal word capitalized.
For example:
run();
runFast();
getBackground();
Variables: Except for variables, all instance, class, and class constants are in mixed case
with a lowercase first letter. Internal words start with capital letters. Variable names
should not start with underscore _ or dollar sign $ characters, even though both are
allowed. Variable names should be short yet meaningful. The choice of a variable name
should be mnemonic- that is, designed to indicate to the casual observer the intent of its
use. One-character variable names should be 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.
For example:
int i;
char c;
float myWidth;
Constants: The names of variables declared class constants and of ANSI constants
should be all uppercase with words separated by underscores ("_"). (ANSI constants
should be avoided, for ease of debugging.)
For example:
static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;

41 | P a g e
Use Standard Brace Style
Braces do not go on their own line; they go on the same line as the code before them.
So: class MyClass
{
int func() {
if (something) {
// ...
} else if (somethingElse) {
// ...
} else {
// ...
}}}
We require braces around the statements for a conditional.
if (condition) {
body();
}
while Statements: A while statement should have the following form:
while (condition) {
statements;
}
do-while Statements: A do-while statement should have the following form:
do {
statements;
} while (condition);
switch Statements: A switch statement should have the following form:
switch (condition) {
case ABC: statements;
/* falls through */
case DEF: statements;
break;
case XYZ: statements;

42 | P a g e
break;
default: statements;
break;
}
Comment Formats
 Block comments are used to provide descriptions of files, methods, data structures
and algorithms.
 Short comments can appear on a single line indented to the level of the code that
follows.
 Very short comments can appear on the same line as the code they describe, but
should be shifted far enough to separate them from the statements.
 The // comment delimiter can comment out a complete line or only a partial line. It
shouldn't be used on consecutive multiple lines for text comments; however, it can be
used in consecutive multiple lines for commenting out sections of code.
Don't Ignore Exceptions
Sometimes it is tempting to write code that completely ignores an exception like this:
void setServerPort(String value) {
try {
serverPort = Integer.parseInt(value);
}
catch (NumberFormatException e) { }
}
You must never do this. While you may think that your code will never encounter this
error condition or that it is not important to handle it, ignoring exceptions like above
creates mines in your code for someone else to trip over some day. You must handle
every Exception in your code in some principled way. The specific handling varies
depending on the case.
Acceptable alternatives (in order of preference) are:
 Throw the exception up to the caller of your method.
void setServerPort(String value) throws NumberFormatException {
serverPort = Integer.parseInt(value);

43 | P a g e
}
 Throw a new exception that's appropriate to your level of abstraction.
void setServerPort(String value) throws ConfigurationException {
try { serverPort = Integer.parseInt(value);
}
catch (NumberFormatException e) {
throw new ConfigurationException("Port " + value + " is not valid.");
} }
 Handle the error gracefully and substitute an appropriate value in the catch {} block.
/** Set port. If value is not a valid number, 80 is substituted. */
} catch (NumberFormatException e) {
serverPort = 80; // default port for server
} }
 Last resort: if you are confident that actually ignoring the exception is appropriate
then you may ignore it, but you must also comment why with a good reason:
/** If value is not a valid number, original port number is used. */
} catch (NumberFormatException e) {
// Method is documented to just ignore invalid user input.
// serverPort will just be unchanged.
} }
Don't Catch Generic Exception
Sometimes it is tempting to be lazy when catching exceptions. Alternatives to catching
generic Exception:
 Catch each exception separately as separate catch blocks after a single try. This can
be awkward but is still preferable to catching all Exceptions. Beware repeating too
much code in the catch blocks.

44 | P a g e
 Refactor your code to have more fine-grained error handling, with multiple try
blocks. Split up the IO from the parsing, handle errors separately in each case.
 Rethrow the exception. Many times you don't need to catch the exception at this level
anyway, just let the method throw it.
Use Javadoc Standard Comments
Every file should have a copyright statement at the top. Then a package statement and
import statements should follow, each block separated by a blank line. And then there
is the class or interface declaration. In the Javadoc comments, describe what the class
or interface does.
/*
* Copyright (C) 2010 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied. * See the License for the specific language governing permissions and
* limitations under the License.
*/
package com.android.internal.foo;
import android.os.Blah;
import android.view.Yada;
import java.sql.ResultSet;
import java.sql.SQLException;
/**
* Does X and Y and provides an abstraction for Z.

45 | P a g e
*/
public class Foo {
...
}
Every class and nontrivial public method you write must contain a Javadoc comment
with at least one sentence describing what the class or method does. This sentence
should start with a 3rd person descriptive verb.
Examples:
/** Returns the correctly rounded positive square root of a double value. */
static double sqrt(double a) {
...
}
or
/**
* Constructs a new String by converting the specified array of
* bytes using the platform's default character encoding.
*/
public String(byte[] bytes) {
...
}
You do not need to write Javadoc for trivial get and set methods such as setFoo() if all
your Javadoc would say is "sets Foo". If the method does something more complex
(such as enforcing a constraint or having an important side effect), then you must
document it. And if it's not obvious what the property "Foo" means, you should
document it. Every method you write, whether public or otherwise, would benefit from
Javadoc. Public methods are part of an API and therefore require Javadoc.
Limit Variable Scope
The scope of local variables should be kept to a minimum. Each variable should be
declared in the innermost block that encloses all uses of the variable. Local variables
should be declared at the point they are first used. Nearly every local variable
declaration should contain an initializer. If you don't yet have enough information to
initialize a variable sensibly, you should postpone the declaration until you do. One
exception to this rule concerns try-catch statements. If a variable is initialized with the
return value of a method that throws a checked exception, it must be initialized inside a

46 | P a g e
try block. If the value must be used outside of the try block, then it must be declared
before the try block, where it cannot yet be sensibly initialized:
// Instantiate class cl, which represents some sort of Set
Set s = null;
try {
s = (Set) cl.newInstance();
} catch(IllegalAccessException e) {
throw new IllegalArgumentException(cl + " not accessible");
} catch(InstantiationException e) {
throw new IllegalArgumentException(cl + " not instantiable");
}
// Exercise the set
s.addAll(Arrays.asList(args));
But even this case can be avoided by encapsulating the try-catch block in a method:
Set createSet(Class cl) {
// Instantiate class cl, which represents some sort of Set
try { return (Set) cl.newInstance();
} catch(IllegalAccessException e) {
throw new IllegalArgumentException(cl + " not accessible");
}
catch(InstantiationException e) {
throw new IllegalArgumentException(cl + " not instantiable");
} }
...
// Exercise the set
Set s = createSet(cl);
s.addAll(Arrays.asList(args));
Loop variables should be declared in the for statement itself unless there is a
compelling reason to do otherwise:
for (int i = 0; i n; i++) {
doSomething(i);

47 | P a g e
}
and
for (Iterator i = c.iterator(); i.hasNext(); ) {
doSomethingElse(i.next());
}
Use Standard Java Annotations
Annotations should precede other modifiers for the same language element. Simple
marker annotations (e.g. @Override) can be listed on the same line with the language
element. If there are multiple annotations, or parameterized annotations, they should
each be listed one-per-line in alphabetical order.<
Android standard practices for the three predefined annotations in Java are:
 @Deprecated: The @Deprecated annotation must be used whenever the use of the
annotated element is discouraged. If you use the @Deprecated annotation, you must
also have a @deprecated Javadoc tag and it should name an alternate implementation.
In addition, remember that a @Deprecated method is still supposed to work.
 @Override: The @Override annotation must be used whenever a method overrides
the declaration or implementation from a super-class. 9
 @SuppressWarnings: The @SuppressWarnings annotation should only be used under
circumstances where it is impossible to eliminate a warning. If a warning passes this
"impossible to eliminate" test, the @SuppressWarnings annotation must be used, so as
to ensure that all warnings reflect actual problems in the code. When a
@SuppressWarnings annotation is necessary, it must be prefixed with a TODO
comment that explains the "impossible to eliminate" condition. This will normally
identify an offending class that has an awkward interface. For example:
// TODO: The third-party class com.third.useful.Utility.rotate() needs generics
@SuppressWarnings("generic-cast")
List blix = Utility.rotate(blax);
When a @SuppressWarnings annotation is required, the code should be refactored to
isolate the software elements where the annotation applies.
Treat Acronyms as Words
Treat acronyms and abbreviations as words in naming variables, methods, and classes.
The names are much more readable:
Good Bad
XmlHttpRequest XMLHTTPRequest
getCustomerId getCustomerID

48 | P a g e
class Html class HTML
String url String URL
long id long ID
Both the JDK and the Android code bases are very inconsistent with regards to
acronyms, therefore, it is virtually impossible to be consistent with the code around
you.
Use TODO Comments
Use TODO comments for code that is temporary, a short-term solution, or good-enough
but not perfect.
TODOs should include the string TODO in all caps, followed by a colon:
// TODO: Remove this code after the UrlTable2 has been checked in.
and
// TODO: Change this to use a flag instead of a constant.
If your TODO is of the form "At a future date do something" make sure that you either
include a very specific date ("Fix by November 2005") or a very specific event
("Remove this code after all production mixers understand protocol V7.").
Be Consistent
Our parting thought: BE CONSISTENT. If you're editing code, take a few minutes to
look at the code around you and determine its style. If they use spaces around their if
clauses, you should too. If their comments have little boxes of stars around them, make
your comments have little boxes of stars around them too. The point of having style
guidelines is to have a common vocabulary of coding, so people can concentrate on
what you're saying, rather than on how you're saying it. We present global style rules
here so people know the vocabulary. But local style is also important. If code you add
to a a file looks drastically different from the existing code around it, it throws readers
out of their rhythm when they go to read it.

49 | P a g e
10. SOURCE CODE
AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.sky.a_1electronics">
<uses-permission android:name="android.permission.SEND_SMS" />
<uses-permission android:name="android.permission.INTERNET" />
<application
android:name=".myapp"
android:allowBackup="true"
android:label="@string/app_name"
android:roundIcon="@drawable/ic_tools"
android:supportsRtl="true"
android:theme="@style/AppTheme">
<activity
android:name=".MainActivity"
android:screenOrientation="portrait" />
<activity
android:name=".Welcome"
android:label="Welcome" />
<activity
android:name=".AppointmentP.Appointment"
android:label="Appointment"
<activity
android:name=".WorkshopP.Workshop"
android:label="Workshop"

50 | P a g e
<activity
android:name=".DeliveryP.Delivery"
android:label="Delivery"
<activity
android:name=".InventoryP.Inventory"
android:label="Inventory"
<activity
android:name=".AppointmentP.NewAppointment"
android:label="Workshop"
<activity
android:name=".WorkshopP.NewWorkshop"
<activity
android:name=".ArchiveP.Archive"
<activity
android:name=".SplashScreen"
android:screenOrientation="portrait">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity
android:name=".FanData"

51 | P a g e
<activity
android:name=".LoginTab"
<activity
android:name=".CustomerLogin"
<activity
android:name=".InventoryP.AddComponent"
<activity
android:name=".InventoryP.EditSearchComponent"
<activity
android:name=".InventoryP.EditComponent"
<activity
android:name=".InventoryP.QtyCheck"
<activity
android:name=".InventoryP.QtyUpdate"
<activity
android:name=".InventoryP.Report"
<activity
android:name=".FeedbackAdmin"
<activity
android:name=".CustomerP.Registration"

52 | P a g e
android:screenOrientation="portrait"
android:label="Feedback"/>
<activity
android:name=".CustomerP.Profile"
<activity
android:name=".CustomerP.EditCustomer"
<activity
android:name=".AppointmentP.DisplayAppointment"
<activity
android:name=".AppointmentP.EditAppointment"
<activity
android:name=".WorkshopP.DisplayWorkshop"
<activity
android:name=".WorkshopP.EditWorkshop"
<activity
android:name=".WorkshopP.SwitchWorkshop"
<activity
android:name=".DeliveryP.DisplayDelivery"
<activity
android:name=".DeliveryP.EditDelivery"
<activity

53 | P a g e
android:name=".ArchiveP.DisplayArchive"
<activity
android:name=".CustomerP.SetAppointment"
<activity
android:name=".CustomerP.ForgotPassword"
<activity
android:name=".InventoryP.Notes"
<activity
android:name=".CustomerP.FeedbackCustomer"
android:label="@string/title_activity_feedback_customer"
android:theme="@style/AppTheme"></activity>
</application>
</manifest>

54 | P a g e
MainActivity.java
package com.example.sky.a_1electronics;
import android.Manifest;
import android.content.ContentValues;
import android.content.Intent;
import android.content.pm.PackageManager;
import android.database.sqlite.SQLiteDatabase;
import android.os.Build;
import android.os.Handler;
import android.support.annotation.RequiresApi;
import android.support.v4.view.GravityCompat;
import android.support.v4.widget.DrawerLayout;
import android.support.v7.app.AppCompatActivity;
import android.os.Bundle;
import android.util.Log;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;
import android.view.View;
import android.widget.Toast;
public class MainActivity extends AppCompatActivity {
Button loginbtn;
EditText eu,ep;
private static final int PERMISSION_REQUEST_CODE = 1;
@Override

55 | P a g e
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
loginbtn = (Button) findViewById(R.id.btn_login);
eu = (EditText) findViewById(R.id.input_username);
ep = (EditText) findViewById(R.id.input_password);
//Permissions
if (android.os.Build.VERSION.SDK_INT >=
android.os.Build.VERSION_CODES.M) {
if (checkSelfPermission(Manifest.permission.SEND_SMS)
== PackageManager.PERMISSION_DENIED) {
Log.d("permission", "permission denied to SEND_SMS - requesting it");
String[] permissions = {Manifest.permission.SEND_SMS};
requestPermissions(permissions, PERMISSION_REQUEST_CODE);
}
}
//Permissions
//login
loginbtn.setOnClickListener(new View.OnClickListener() {
public void onClick(View arg0) {
if (eu.getText().toString().equals("") && ep.getText().toString().equals(""))

56 | P a g e
{
// Start NewActivity.class
Intent myIntent = new Intent(MainActivity.this, Welcome.class);
startActivity(myIntent);
}
if (eu.getText().toString().length()==0)
{
eu.requestFocus();
eu.setError("FIELD CANNOT BE EMPTY");
Toast.makeText(MainActivity.this,"Enter a
Username",Toast.LENGTH_LONG).show();
}
else if (ep.getText().toString().length()==0)
{
ep.requestFocus();
ep.setError("FIELD CANNOT BE EMPTY");
Toast.makeText(MainActivity.this,"Enter a
Password",Toast.LENGTH_LONG).show();
}
else if (eu.getText().toString().equals("admin") &&
ep.getText().toString().equals("admin"))
{
// Start NewActivity.class
Intent myIntent = new Intent(MainActivity.this, Welcome.class);
startActivity(myIntent);
}
else
{
eu.requestFocus();
eu.setError("USERNAME AND PASSWORD DOES NOT MATCH");
ep.setText("");

57 | P a g e
Toast.makeText(MainActivity.this,"Username or Password
Incorrect",Toast.LENGTH_LONG).show();
}
}
});
}
boolean doubleback=false;
@RequiresApi(api = Build.VERSION_CODES.JELLY_BEAN)
@Override
public void onBackPressed() {
if (doubleback) {
//this.finishAffinity();
System.exit(0);
//super.onBackPressed();
//return;
}
else {}
this.doubleback = true;
Toast.makeText(this, "Please Click BACK again to exit",
Toast.LENGTH_SHORT).show();
new Handler().postDelayed(new Runnable() {
@Override
public void run() {
doubleback=false;
}
},2000);
}
}

58 | P a g e
activity_main.xml
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
xmlns:app="http://schemas.android.com/apk/res-auto"
android:background="#fff"
android:orientation="vertical"
android:paddingLeft="24dp"
android:paddingRight="24dp"
android:paddingTop="26dp">
<TextView
android:layout_height="wrap_content"
android:layout_marginBottom="8dp"
android:layout_marginTop="8dp"
android:text="Welcome in A-1 Electronics"
android:textSize="24dp"
android:textColor="#000000"
android:textStyle="bold"/>
<ImageView
android:id="@+id/imageView3"
android:layout_height="128dp"
android:src="@drawable/alogo"
/>

59 | P a g e
<LinearLayout
android:orientation="vertical">
<android.support.design.widget.TextInputLayout
android:id="@+id/username"
android:textColorHint="@android:color/black">
<EditText
android:id="@+id/input_username"
android:hint="Username"
android:inputType="textEmailAddress" />
</android.support.design.widget.TextInputLayout>
<android.support.design.widget.TextInputLayout
android:id="@+id/password"
android:textColorHint="@android:color/black"
app:passwordToggleEnabled="true">
<EditText
android:id="@+id/input_password"

60 | P a g e
android:hint=" Password"
android:inputType="textPassword" />
</android.support.design.widget.TextInputLayout>
<Button
android:id="@+id/btn_login"
android:layout_width="fill_parent"
android:padding="12dp"
android:text="Login"
android:textColor="#fff"
android:background="@drawable/bgselector"/>
</LinearLayout>
</LinearLayout>

61 | P a g e
11. SCREEN LAYOUT WITH TEST DATA AND TEST
RESULT
Splash Screen Customer Registration
Customer Login Customer Profile

62 | P a g e
Set Appointment Feedback Form
Customer Navigationbar Customer Logout

63 | P a g e
Admin Login Welcome Page
New Appointment(Admin) Appointment List

64 | P a g e
Appointment Display Appointment Switch
Workshop Search Workshop Display

65 | P a g e
Wokshop Switch Workshop Switch Form
Delivery List Delivery Switch

66 | P a g e
Archive Search Archive Display
Inventory Admin Logout

67 | P a g e
12. REPORTS LAYOUT
Appointments Workshop
Delivery Archive

68 | P a g e
Feedback Quantity
Report Items

69 | P a g e
Customer Apointments

70 | P a g e
13. BIBLIOGRAPHY/REFERENCE
Bibliography:
Software Engineering, “Ian Somerville”, 8th edition, Pearson Education. Software
project management by Walker Royse Object Oriented Modelling and Design with
UML| Michael Blaha& James Rumbaugh | Prentice Hall of India | 2nd Edition
Web References
Note: - The following websites were referred during the timespan of project development.
These websites were referred from 1 november 2017 till 13 march 2018
 www.github.com
 www.androidhive.com
 www.youtube.com
 www.stackoverflow.com
 www.developer.android.com
 www.tutorialpoints.com
 www.flaticon.com
 www.material.io
 www.loading.io

TY BSc.IT Blackbook Main Report

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to TY BSc.IT Blackbook Main Report

Similar to TY BSc.IT Blackbook Main Report (20)

Recently uploaded

Recently uploaded (20)

TY BSc.IT Blackbook Main Report