You are on page 1of 46

DEPARTMENT OF SOFTWARE ENGINEERING

Project Title: <A-Z Car Care>

Supervisor: < Dr. Omar Fuad Alsheikh Salem>

Group Members:

v
b
m
n

Page 1
Contents
Project description--------------------------------------------------------------5
Project submission--------------------------------------------------------------6
1.supervisor -------------------------------------------------------------------------6
2.project title ------------------------------------------------------------------------6
3.goals and objectives----------------------------------------------------------------6
4. Brief description of the project----------------------------------------------------6
5. References------------------------------------------------------------------------6
6. Project Requirements (Hardware & Software)------------------------------------7
7. Company or organization (If applicable)------------------------------------------7
8. Prerequisite------------------------------------------------------------------------7
9. Project Specialization--------------------------------------------------------------7
10. Time schedule--------------------------------------------------------------------7

Chapter 1: Proposal-------------------------------------------------------------8
1. Introduction------------------------------------------------------------------------8
2. Objective---------------------------------------------------------------------------8
3. Problem Statement-----------------------------------------------------------------8 4.
Motivation-------------------------------------------------------------------------8
5. Literature Review------------------------------------------------------------------8
6. Methodology-----------------------------------------------------------------------9
7. Research Plan----------------------------------------------------------------------10

Chapter 2: Requirement Engineering Part---------------------------------11


I. Domain Understanding-------------------------------------------------------11
1. Context-----------------------------------------------------------------------------11
2. Scope of the systems as-is----------------------------------------------------------12
3. Stakeholders------------------------------------------------------------------------12
4. Strengths and Weaknesses of the system as-is--------------------------------------12
5. Glossary of Terms------------------------------------------------------------------13

II. Requirement Elicitation-----------------------------------------------------14


1. Retained Requirement elicitation techniques---------------------------------------17

Page 2
2.Requirement Elicitations Documents-----------------------------------------------18 III.
Requirement Specifications-------------------------------------------------19
1. Business Requirements--------------------------------------------------------------19
2. System Requirements----------------------------------------------------------------19

IV Requirements Analysis-------------------------------------------------------21

V. Requirements Validation-----------------------------------------------------21

VI. Requirement Modeling-------------------------------------------------------23

Chapter 3: Software Requirement Specification-----------------------------25


1. Introduction-----------------------------------------------------------------------25
1.1 Purpose----------------------------------------------------------------------25 1.2
Scope------------------------------------------------------------------------25
1.3 Definitions, acronyms, and abbreviations------------------------------------25
1.4 REFERENCES--------------------------------------------------------------26
2. Overview---------------------------------------------------------------------------26
2.1 Product perspective----------------------------------------------------------26
2.2 Product Functions------------------------------------------------------------27
2.3 User Classes and Characteristics---------------------------------------------27
2.4 General Constraints----------------------------------------------------------27
2.5 Assumptions and Dependencies----------------------------------------------28
3. Specific requirements------------------------------------------------------------28
3.1 User Interface----------------------------------------------------------------28
3.2 External interface Requirements---------------------------------------------29
3.3 Functional requirement------------------------------------------------------29
3.4 Use Cass---------------------------------------------------------------------32
3.5 Non- Functional requirement------------------------------------------------33
3.6 Design constraints-----------------------------------------------------------33
3.7 Software system attributes---------------------------------------------------34

Chapter 4: Software Architecture----------------------------------------------35


1. Introduction----------------------------------------------------------------------35
2. Benefits of Software Architecture--------------------------------------------35
3. Architectural Style--------------------------------------------------------------35

Page 3
4. Client/Server Architecture in details----------------------------------------36
Chapter 5: Software Design------------------------------------------------------38
1. Overview --------------------------------------------------------------------------38
2. Class diagram--------------------------------------------------------------------38
3. Sequence diagram---------------------------------------------------------------39
4. ER Diagram----------------------------------------------------------------------40
5. User Interface UI----------------------------------------------------------------41
5.1 --------------------------------------------------------------------------41
5.2 ----------------------------------------------------------------------42
5.3 -------------------------------------------------------------------------43
5.4 ---------------------------------------------------------44
5.5 ------------------------------------------------------------------------45
5.6 --------------------------------------------------------------------46
5.7 ----------------------------------------------------------48
5.8 ------------------------------------------------------------------49
5.9 ----------------------------------------------------------50
5.10 -----------------------------------------------------------51

Chapter 6: Implementation------------------------------------------------------52
1. --------------------------------------------------------------------52
2. --------------------------------------------------------------------55
3. -----------------------------------------------------------------56
4. ---------------------------------------------------57
5. ------------------------------------------------------------------58
6. ---------------------------------------------------------59

Chapter 7: Testing -----------------------------------------------------------------60


1. Overview --------------------------------------------------------------------------60
2. Functional Testing --------------------------------------------------------------60

Chapter 7: Conclusion and future work---------------------------------------63

References----------------------------------------------------------------------------64

Page 4
Project Title:
A-Z Car Care

Project We have got three stakeholders, Customer, Admin, Mechanic, Shop,


Description: Parts Shop.
So, a client can have some parts for his car to be fixed or to be
picked up by the mechanic.

Student Name & Alwaleed Alshaghnoubi 201910727


Registration No: Heba AL-Shatarat 201820093
Ahmad Alrefai 201910780
Manhal Shahtout 201910252

Project Submission
1. Supervisor:
Dr. Omar Fuad Alsheikh Salem.
2. Project Title:
A-Z Car Care

3. Goals and Objectives:


To enable our application to ease the life of the customer when they want to fix their cars
4. Brief description of the project:
We have got three stakeholders, Customer, Admin, Mechanic, Shop, Parts Shop.
So, a client can have some parts for his car to be fixed or to be picked up by the mechanic.
5. References
1-Vehicle Maintenance (Auto) Application on app store.
2-My car service – Car management application on app store.
3-Advance Auto Parts Application on app store.

6. Project Requirements (Hardware & Software)

Page 5
1) Three laptops.
2) Microsoft Project.
3) Visio.
4) Visual Programming.
5) Flutter

7. Company or organization (If applicable)


None.

8. Prerequisite
90 credit hours.
9. Project Specialization (Software Engineering)
Application regarding car fixing.

10. Time schedule

Chapter 1: Proposal

Page 6
1. Introduction:

Nowadays, with the increasing use of technology in all fields of our life. Since most car
users spend their time at work, their time is often contrary to the working hours of the
workshops. We got an idea for the car maintenance application and this is what this document
contains. The main purposes of this application Offer the service of repairing and maintaining
your car through workshops and industrial centers through which you will be able to benefit
from the services you need by receiving cars and repairing them at an appropriate price and
evaluating your experience through the app.

2. Objective

Our objective is to save time and effort for vehicle owners so that they can do regular
maintenance\regular checkup or repairing their vehicle during workdays and by also
ordering spare-parts, comparing prices, and getting the best price and service.

3. Problem Statement

finding time for regular workers, also saving effort and making it easier to find the best
service providers.
Finding the nearest workshop to vehicle owners and the lack of solutions to problems state

4. Motivation:

The main motive behind choosing this topic is to provide easy access to workshops, and
to know the prices of parts or repairs.

Providing an improved and interactive interface between the vehicle owner and the
workshop

Provide feedback on workshops by letting Vehicle owners rate on the quality of service
provided by workshops.

5. Literature Review

Mismar:
A smart application is available on the Apple and Android store that provides a car
repair service and provides spare parts. Users can request comprehensive

Page 7
maintenance or periodic maintenance and set an appointment to receive the car, and
they can take advantage of the car-related discount offers.

Fix Card:
An electronic application that provides online fault cards at competitive prices, making it
easier for vehicle owners to reach reliable service providers, as it provides regular fault
tickets and periodic maintenance tickets approved by car agencies, in addition to
preventive maintenance tickets and inspection cards.

Asalehlak:
It is the company that owns the first application of its kind in the Arab world for car
service on the road, which consists of a team that aims to revolutionize the world of car
repair and to deliver every vehicle owner to the ideal vehicle with the click of a button so
that our country is free of idle cars on the road.

6. Methodology:
The waterfall model is a classical model used in the system development life cycle to create a
system with a linear and sequential approach. This model is divided into different phases and the
output of one phase is used as the input of the next phase. Every phase has to be completed
before the next phase starts and there is no overlapping of the phases.

The sequential phases described in the Waterfall model are:-

1. Requirement Gathering.
2. Analysis.
3. System Design.
4. Implementation.
5. Integration and Testing.
6. Maintenance.

Page 8
Figure 1 - waterfall

Why did we use the waterfall model?

We decided to use the waterfall model because it’s easy to understand and use,
which is one of the waterfall model's biggest strengths also, since the requirements
for this project are not ambiguous and there is a need for good documentation. It is
the best suited methodology that we can use for our own team.

Page 9
7. Research Plan

Chapter 2: Requirement Engineering Part

I. Domain Understanding
The project proposes to deliver IOS and Android which will provide:

Car services in a mobile friendly format, Based on similar car services apps and the questionnaire
of car owners the following features can also be included.

Booking a maintenance \cleaning \repair \pickup appointment with nearby car workshops.

contacting the workshop through the app.

1. Context:
Page
10
- Structure:
The Vehicle Owners must pay a fee to make an appointment with a workshop.

There is a limit to how many appointments a Vehicle Owners can make at a time.

The Vehicle Owners are able to check if their car is ready in the “Appointment status” tab.

The Vehicle Owners should be highly incentified to rate


the service he\she received.

- Business Policies:
The Vehicle Owners has to abide by the date of the appointment if he does not then the
appointment fee shall be given to the workshop without refund..

The basic car check service should be paid upfront regardless of repairs done, and the workshop
can only proceed with repairs after checking with the customer.

The workshop is responsible for repairing any damage done to the customers' cars by them.

The Vehicle Owners should notify the workshop of any delay that will happen to him (the
maximum delay allowed is 30 minutes more than that customer must arrange it with the
workshop) .

2. Scope of the systems as-is


Our project touches all the related boundaries of car services. A Vehicle Owners can make
an appointment for regular maintenance\regular checkup\ cleaning \ repairs, can check
appointment status, see different workshops near him, rate workshops he dealt with, view latest
workshops offers near him..

Whereas a workshop owner can set up his workshop profile on the app.

Will deliver a notification after completing the car service has been provided and the car is ready.

3. Stakeholders
Vehicle Owners : He needs maintenance for his car.

Maintenance Technician: Understand vehicle maintenance and repair procedures.

Workshops : Supervising and controlling all types of maintenance.

Pickup Driver : A tow truck driver that helps transport cars to workshops.
Page
11
Spare-Parts Seller: responsible for selling spare-parts.

4. Strengths and Weaknesses of the system as-is

Strengths
• The system will provide two languages(Arabic and English)  .
• The system will contain at chat between the vehicle owner and the workshop.
• The system will contain spare-parts, its prices.
• The system will have an option to rate the workshops services by the Vehicle Owners.
• The system can show the vehicle owner the nearest workshops.

Weaknesses

● The customer has to travel some distance to visit workshops.


● Lack of knowledge about which workshop offers best prices and/or quality.
● Lack of available time.
● Vehicle Owners are usually ignorant about spare part prices.
● Lack of experience about vehicles in general.

Our application will provide some solutions as follows:

1. The application will have the option to navigate to nearest workshop location.

2. Our application provides reviews from vehicle owners.

3. Our application will have an option to connect to a pickup driver to deliver the vehicle to a
workshop to save time.

4. Our application provides a price comparing function.

Page
12
5. Glossary of Terms
MD5 (Message Digest), which is considered one of the most popular shorthand
functions in cryptography and information security due to its ease of
implementation and difficult to hack.

II. Requirement Elicitation


We will use the questionnaire because it covers the largest possible number of
customers, this will help us to collect more requirements and thus understand the user
requirements well.[3]

Page
13
1. Retained Requirement elicitation techniques
Technique:

Questionnaire

Motivations:

To gather the largest number of responses.

Page
14
2.Requirement Elicitations Documents
Questions asked:

Page
15
Page
16
Responses gathered:
Page
17
Page
18
Page
19
Page
20
Page
21
III. Requirement Specifications

1. Business Requirements (if any)


-profision practice permit.

-spare-parts warranty.

-credit card money hold for appointments.

2. System Requirements

2.1 Hardware requirements (if any)

Mobile hardware: iOS devices (iPhone 4S or newer), And Snapdragon 660 or higher for
Android devices.

2.2 Software Requirement

Mobile operating systems: Android Jelly Bean, v16, 4.1.x or newer, and iOS 8

or newer.

Page
22
2.2.1 Functional Requirements

1. Sign Up: Vehicle Owners insert email and password then password again for
confirmation to Sign Up.
○ Workshops insert email and password then password again for
confirmation.
○ Pickup drivers insert email and password and password again for
confirmation.
○ Spare-parts seller insert email and password and password again for
confirmation.

2. Sign In: Vehicle Owners use their registered Email and password to sign in.
○ Workshops use their registered Email and password to sign in.
○ Pickup drivers use their registered Email and password to sign in.
○ Spare-parts seller use their registered Email and password to sign in.
.
3. Change password: Vehicle Owners should be able to change their password.
○ Workshops should be able to change their password.
○ Pickup drivers should be able to change their password.
○ Spare-parts seller should be able to change their password.

4. Profile: After Signing up Vehicle Owner will fill their profile including full
name, date of birth ,phone number, second phone number if any, address, personal
picture if desired.
○ Workshops after signing up and providing practice permits will fill their
profile including the name of the workshop, address, contact number, and
pictures of the workshop.
○ Spare-parts sellers after signing up and providing practice permits will fill
their profile including the name of their shop phone number and pictures
of the shop and address.
○ Pickup drivers after signing up and providing practice permits will fill
their profile with full name, contact number, address, and a personal
picture if desired.

5. Rate workshops: Vehicle Owners will be able to rate all workshops they have
dealt with through the app highest rating being 5-stars lowest being a half-star.

6. Search : Vehicle owners can search for workshops to make an appointment or


spare-parts to order..

7. Nearest workshop: Vehicle Owners can check and navigate location to the
nearest workshop.

Page
23
8. Request an appointment: Vehicle Owners can request for appointments with
workshops through the app to receive car services including repair, regular
checkups, regular maintenance,cleaning,car pickup to workshop.
.
9. Accept\reject appointment: a pickup driver will be notified of a request to tow a
car to a certain workshop.
○ workshop will be notified of a request they can either accept or reject the
appointment request.
.
10. Pickup location and dropoff: after the pickup drivers accept a request they will
be given car information, navigate to current location of the car and drop off
location.

11. Receipts to Emails: Vehicle Owners will receive an email containing the receipt.

12. View workshops ratings: All stakeholders can check workshops ratings through
the app.

13. Appointment status: Vehicle Owners can check their appointment status which
will display if the service is finished, the appointment has been made in xx date -
xx time, no current appointments \ serviced are requested.

14. Order car parts: Vehicle Owners can order car parts from spare-part sellers and
deliver them to a workshop.

15. Price comparison: compare prices of spare-parts or services.

2.2.2 Non Functional Requirements

- Usability:

1.Getting the job done takes less time.

2.Ease of use without directions.

3.The error message is clear in detailing the error.

- Performance:

The application should work quickly to provide the best service to the vehicle
owner, workshop and driver.

- Security:
Page
24
The program must ensure the integrity of the accounts information.
each user inside the system has an encryption password using the MD5 algorithm

- Reliability:
The application should be as reliable as possible because we have important information about
vehicle owners, workshop owners and drivers (vehicle license and payment terms).

- Availability:

The application will be available to everyone anywhere and anytime through internet service as soon
as they need it.

- Flexibility:

Application an open-source system that application management can customize the function
of the application as they need.

IV Requirements Analysis

We checked all the requirements and no conflicts were found, all functions are clear and there
was no ambiguity.

Page
25
V. Requirement Modeling Use-case:

Page
26
Class diagram:
Class diagram: is a type of static structure diagram that describes the structure of a system by

showing the system's class, their attributes, operations, and the relationships among objects.

Figure Class Diagram

Page
27
Chapter 3: Software Requirement
Specification

1. Introduction
This section gives a scope description and overview of everything included in this SRS
document. Also, the purpose for this document is described and a list of abbreviations and
definitions is provided.

1.1 Purpose
The purpose of this document is to give a detailed description of the requirements for the A_Z
Car Care. It will illustrate the purpose and complete declaration for the development of the
system. It will also explain system constraints, interface and interactions with other external
applications. This document is primarily intended to be proposed to a customer for its approval
and a reference for developing the first version of the system for the development team.

1.2 Scope
Our project touches all the related boundaries of car services. A Vehicle Owners can make
an appointment for regular maintenance\regular checkup\ cleaning \ repairs, can check
appointment status, see different workshops near him, rate workshops he dealt with, view latest
workshops offers near him..

Whereas a workshop owner can set up his workshop profile on the app.

Will deliver a notification after completing the car service has been provided and the car is ready.

1.3 Definitions, acronyms, and abbreviations:


Stakeholder Any person who has interaction with the system who is not a
developer
Profile A User's individual record. This contains personal contact
information

Page
28
1.4 REFERENCES:
http://www.lucidchart.com

www.figma.com

2. Overview:
This section will give an overview of the whole system. The system will be explained in
its context to show how the system interacts with other systems and introduce the basic
functionality of it. It will also describe what type of stakeholders that will use the system and
what functionality is available for each type. At last, the constraints and assumptions for the
system will be presented

2.1 Product perspective:


product perspective defines what the product does, not how it does so. This corresponds
with the external view of the product. Moreover, it also imposes clear conditions and criteria on
the formulation of product requirements. The following figure illustrates these key aspects of the
product perspective for"A_Z Car care" system : Product management is accountable for product
success and must therefore be responsible author of the product perspective. As an external view
on the product, the product perspective defines how the product contributes to fulfilling
stakeholder needs and adjacent systems assumptions.
Page
29
The following diagram describe the high-level business process of the appointment function:

Figure 9 Block diagram

2.2 Product Functions:


This subsection of the SRS should provide a summary of the major functions that the software
will perform.This software package is expected to offer the following services.

1. For Vehicle Owners:


save time and effort for any service needed for a vehicle by making appointments to a
workshop, chicking prices,or simply searching for the location of the nearest
workshops.

2. For Workshops:
Exposure for their business and to show what services can be provided by them.

2.3 User Classes and Characteristics:

This subsection of the SRS should describe those general characteristics of the
intended users of the product

a) Vehicle owner: people that need some service to their vehicle that generally either don’t have
the time or want to save the effort.

b) Workshop:is where most services are provided for vehicle owners including repairs and
maintenance.

Page
30
c) Pickup Driver: the people that provides the service of picking up a car and delivering it to the
workshop

d) Spare-Parts Seller: people that vehicle owners or workshops can order spare-parts for vehicles
from.

2.4 General Constraints:

This subsection of the SRS should provide a general description of any other items that
will limit the developer's options.
The Internet connection is also a constraint for the application. Since the application
fetches data from the database over the Internet, it is crucial that there is an Internet
connection for the application to function

2.5 Assumptions and Dependencies:

There are no assumptions made.

3. Specific requirements:

This section contains all of the functional and quality requirements of the system. It
gives a detailed description of the system and all its features.

3.1 User Interface:

Page
31
3.2 External interface Requirements:

This section provides a detailed description of all inputs into and outputs from the
system. It also gives a description of the hardware, software and communication
interfaces and provides basic prototypes of the user interface.

3. 2.1Communications interfaces:

The communication between the different parts of the system is important since
They depend on each other. However, in what way the communication is achieved is
not important for the system and is therefore handled by the underlying operating
systems for the mobile application.

3.3 Functional requirement:

Functional Requirement 1
ID:FR1
Title: Sign Up
Description: the user should be able to sign up
through the mobile application. The user must provide an email address and a password.
Rational: In order for a user to register on the mobile application.
Dependency:NON

Functional Requirement 2
ID:FR2.
Title: Sign In

Page
32
Description: Given that a user has registered, then the user should be able to log in to the mobile
application.The sign in information will be stored on the phone and in the future the user should be
signed in automatically
Rational:in order for a user to register on the mobile application.
Dependency: FR1

Functional Requirement 3
ID:FR3.
Title: Password Change
Description: Given that a user has registered, then the user should be able to change their password by
email.
Rational: in order for a user to change their password.
Dependency: FR2

Functional Requirement 4
ID:FR4.
Title: Profile
Description: On the mobile application, a user should have a profile page. On the profile page a user
can edit Their information, which includes the password, e-mail address and phone number. A user
should also be able to choose what language the mobile application should be set to. The different
language choices are English,Arabic.
Rational: in order for a user to have a profile page on the mobile application
Dependency: FR1, FR2

Functional Requirement 5
ID:FR5.
Title: Rate Workshop
Description: on the mobile application, the vehicle owner can rate workshops for services they
have received.
Rational: in order for vehicle owners to rate workshops.
Dependency: FR2

Functional Requirement 6
ID:FR6.
Title: Search
Description: Given that a user is logged in to the mobile app location, then the first page that is shown
should be the search page. The user should be able to search for a workshop, according to several search
options.The search options are Price, Destination,service type.
A user should be able to select multiple search options in one search.
Rational: in order for a user to search for a workshop or spare-parts sellers.
Dependency: FR2

Functional Requirement 7
ID: FR7
Title: Location navigation to workshop
Page
33
Description: user should be able to select a pin on a map or an element on a list. When a
selection is made,the location of the workshop or spare-parts sellers should be sent to the mobile
phone’ GPS-navigation program. The users should then be navigated to the destination. When
the destination is reached, a user should be able to go back to the search page on the mobile
application.
Rational: to navigate a user to a chosen workshop or spare-parts seller
Dependency: FR6

Functional Requirement 8
ID:FR8.
Title: Request an appointment.
Description: Vehicle owners should be able to request for an appointment for a service after
selecting the desired workshop
Rational: in order for the Vehicle owners to make an appointment.
Dependency: FR2, FR6

Functional Requirement 9
ID: FR9
Title: Accept\reject appointment
Description: workshops can accept or reject the appointment request they have received
Rational: in order for workshops to accept or reject appointments.
Dependency: FR2, FR8
Functional Requirement 10
ID: FR10.
Title: Pickup location
Description: Pickup drivers should receive the location and car information for a car needing to
be picked up
Rational: in order for pickup drivers to pick up a car.
Dependency: FR2,FR8

Functional Requirement 11
ID: FR11
Title: Drop off location
Description: Pickup drivers should receive the drop off location of the car after reaching their
destination.
Rational: in order for pickup drivers to drop off cars.
Dependency: FR2, FR10

Functional Requirement 12
ID: FR12
Title: Receipt to email
Description: Vehicle owners should receive a receipt of the services they have received to their
email address associated with their account.
Rational: in order for vehicle owners to receive a receipt.
Dependency: FR2, FR8
Page
34
Functional Requirement 13
ID: FR13
Title: Appointment status
Description: On the mobile application,Vehicle owners should be able to view their current
appointment status on the appointment status tab status include, no current appointment,
appointment made for xx:xx date and time, in workshop, Vehicle is ready.
Rational: in order for vehicle owners to view appointment status.
Dependency: FR2

Functional Requirement 14
ID: FR14
Title: View Workshop Ratings
Description: ALL users should be able to view all workshops ratings and see what other users
have experienced with said workshops..
Rational: in order for users to view workshop ratings.
Dependency: FR2, FR6

Functional Requirement 15
ID: FR15
Title: Compare Prices
Description: On the mobile application,Vehicle owners should be able to have a function to
compare prices of workshop services or prices in spare-parts.
Rational: in order for Vehicle owners to compare prices.
Dependency: FR2

Page
35
3.4 Use Cass:

Page
36
3.5 Non- Functional requirement:

- Usability:

1.Getting the job done takes less time.

2.Ease of use without directions.

3.Message error is clear in detailing the error.

- Performance:

The application should work quickly to provide the best service to the vehicle
owner, workshop and driver.

- Security:
The program must ensure the integrity of the accounts information.
each user inside the system has an encryption password using the MD5 algorithm

- Reliability:
The application should be as reliable as possible because we have important information about
vehicle owners, workshop owners and drivers (vehicle license and payment terms).

- Availability:

The application will be available to everyone anywhere and anytime through internet service as soon
as they need it.

- Flexibility:

Application an open-source system that application management can customize the function
of the application as they need.

Page
37
3.4 Design constraints
Hard drive space
ID:QR10
TAG:Hard Drive Space.
GIST:Hard drive space.
SCALE:The Application's Need Of
Hard drive space.
METER:MB.
MUST:No more than 70 MB.
PLAN:No more than 60 MB.
WISH:No more than 55MB.
MB: DEFINED:Megabyte

Application memory usage


ID:QR11
TAG:Application Memory Usage.
GIST:The amount of Operating
System memory occupied by the
application.
SCALE:MB.
METER:Observations done from
the performance log during testing
MUST:No more than 25MB.
PLAN:No more than 22MB
WISH:No more than 20MB
Operate System:DEFINED: The
mobile Operate System which the
application is running on.
MB: DEFINED:Megabyte.

Page
38
3.5 Software system
attributie

Performance.
Response timeID:QR1
TAG:Response Time
GIST:The fastness of the search
SCALE:The response time of a
search
METER:Measurements obtained
from 1000 searches during testing.
MUST:No more than 6 seconds
100% of the time.
WISH:No more than 3 second
100% of the time.

performance
Workload ID:QR2
TAG:Workload
GIST:Number of the users
supported by the application.
SCALE:The workload of the
application.
METER:Measurements obtained
from 500 hours of usage.
MUST:only 10000 users.
WISH: more than 10000 users .

Page
39
Usability ID:QR3
TAG:Usability
GIST:the ease of use of the
application and making
appointments.
SCALE:how much time the vehicle
owner needs to figure out the
system.
METER:Measurements obtained
from vehicle owners usage.
MUST:no more than 2 hours.
WISH:no more than 40 mins

Chapter 4: Software Architecture

Introduction:
Architecture serves as a blueprint for a system. It provides an abstraction to manage the
system complexity and establish a communication and coordination mechanism among
components.It defines a structured solution to meet all the technical and operational
requirements, while optimizing the common quality attributes like performance and
security.In Architecture, non-functional decisions are cast and separated by the functional
requirements.

Page
40
Figure 16 Architecture
Benefits of Software Architecture:
The primary goal of the architecture is to identify requirements that affect the structure
of the
application. A well-laid architecture reduces the business risks associated with building
a technical solution and builds a bridge between business and technical requirements.
Some of the other goals are as follows:
1. Expose the structure of the system, but hide its implementation details.
2. Realize all the use-cases and scenarios.
3. Try to address the requirements of various stakeholders.
4. Improve quality and functionality offered by the system.
5. Improve external confidence in either the organization or system

Architectural Style

Client/server:

Definition: Client-server architecture is a computing model in which the server hosts,


delivers and manages most of the resources and services to be consumed by the client. This
type of architecture has one or more client computers connected to a central server over a
network or internet connection. Client-server architecture is also known as a networking
computing model or client-server network because all the requests and services are
delivered over a network.

Page
41
We choose Client/server because:
Centralization of control: access, resources and integrity of the data are controlled by the
dedicated server so that a program or unauthorized client cannot damage the system. This
centralization also facilitates task of updating data or other resources

❖ Easy to maintain: you can replace, repair, upgrade, or even move a server, while
customers will not be affected by that change.
❖ Scalability: You can increase the capacity of clients and servers separately.
❖ Service Portability.
❖ High Performance.
❖ Reliability.

Client/Server Architecture in details.


● One or many servers provide services to instances of subsystems, called clients
● Each client calls on the server, which performs some service and returns the result
-The clients know the interface of the server
-The server does not need to know the interface of the client.
● The response in general is immediate
● End users interact only with the client.

- Components of Client Server Architecture: Client-server architecture contains


three components such as client, server, and networking devices and they are
connected with each other.

● Client: a piece of software or application that takes the input and sends requests to
the servers.

● Server:Server is an ultraperformer computer system that contains the fastest


memory,more hard drive space, and faster speed processors because they save and
service several requests which are coming from the client side. A server plays different
types of roles like mail server,database server, file server, and domain controller at the
same time duration.

● Network Devices: With the help of network devices; clients and servers are
connected with each other. Every network device has own functionality like as hub is
used for making connection between server to multiple clients, repeater is used for
moving data from one devices to another device, and bridges helps to isolate of all
network segments.
Page
42
      Chapter 5: Software Design 
Overview 
In this chapter we will introduce a design model for student portal mobile application. We
will start by showing the class diagram based on the same framework we used (Flutter)
Followed by sequence diagram to show the interactions between the objects. 
Then, the Entity Relationship diagram to show all entities of the system and the data to be stored
about them. Finally some Graphical User Interface designs will be specified. 

Class diagram: 
Class diagram describes the attributes and operations of a class and also the constraints imposed
on the system. The class diagrams are widely used in the modeling of object oriented systems
because they are the only UML diagrams, which can be mapped directly with object-oriented
languages. 

Sequence diagram  

are interaction diagrams that detail how operations are carried out. They capture the interaction
between objects in the context of a collaboration. Sequence Diagrams are time focus and they
show the order of the interaction visually by using the vertical axis of the diagram to represent
time, what messages are sent and when.
Page
43
Figure 6 – Sequence diagram 
 

              ER Diagram 
stands for Entity Relationship Diagram, also known as ERD is a diagram that displays the relationship of
entity sets stored in a database. In other words, ER diagrams help to explain the logical structure of databases.
ER diagrams are created based on three basic concepts: entities, attributes and relationships. 
 
ER Diagrams contain different symbols that use rectangles to represent entities, ovals to define attributes and
diamond shapes to represent relationships. 

Chapter 6: Implementation 
==============================================================================

Chapter 7: Testing 
Overview 
The purpose of this chapter is to show the results of the testing phase and verifications applied to
The Student portal application. 
A number of testing methods were chosen to insure that the system works correctly and is
matching the requirements specified earlier. 
The tests listed in this chapter do not include the unit testing performed during development
because it was a part of the construction phase. 

Functional Testing 
#test 
Test case  Input  Output  Result 
NO 
User login using an existing Loading indicator while checking then the
Valid user and
1  user and correct password  home screen is displayed Pass 
correct password
Loading indicator while checking then
User login with wrong ID or Wrong ID or
2  message about the wrong entry Pass 
password password 
Clicking at ”Create
3  Create Profile profile” button Create profile screen has shown for the user Pass 

4  Rate Workshop Pass 

Search screen has shown for the user to


Search workshops / car parts Clicking the “search” search for a workshop or spare-parts sellers
5  Pass 
sellers button 

 
               6        Location navigation to workshop   

Page
44
Clicking at ‘Request an Appointment screen has shown for
7  Request an appointment appointment’ button in workshops the user to make an appointment Pass 
screen 

      8        Accept/reject
appointment Pass 
        

      9       Receive Pickup Pass 


location 
    10      Receive Drop off
Pass 
location  

    11       Receipt to   email     Pass 

    12       View Ratings  Pass 

Clicking at ”Edit profile” button Edit profile screen has shown for the
    13      Edit Profile  Pass 
user

The visa is succeeded


    14      Credit card The visa is succeeded Pass 
payment             

15     Cancel an Clicking at the ‘Cancel your Alert message ‘’Cancel process has
Pass 
appointment  appointment’ button  been confirmed’’
 
Alert message ‘’Cancel process has
Clicking at the ‘‘Cancel your been confirmed’’ Pass 
    16     Cancel an order order’’button 

   17    Contact support Set the title and the details Message has been sent Pass 

Pass 
18 

Pass 
19 

20  

Page
45
Clicking at the 
   

Chapter 8: Conclusion And Future Work 


1. Conclusion  
A_Z car care is a helpful application that helps people save time and effort and find
the most suitable workshop to serve their cars.

2. Future work
More work could be done to the system by adding new functions to make the system
even better and complete such as: 
1- Add more car services.
2- Support more languages.
3- Helping workshops find applicants to apply for jobs.

References: 

1-Vehicle Maintenance (Auto) Application on app store.


2-My car service – Car management application on app store.
3-Advance Auto Parts Application on app store.

Page
46

You might also like