Weather forecasting system

Chapter 1
INTRODUCTION
Nowadays, mobile applications (apps), which enable us to perform more and more tasks
through smart phones, tablets or other terminals, are becoming increasingly prevalent and
ubiquitous in our daily life. To accelerate the development of mobile apps, more and
more third-party services, which can be consumed as backend services of mobile apps,
are available in Mobile-Backend-as-a-Service (MBaaS) or Platform-as-a-Service (PaaS)
systems (e.g., Parse [12], Kinvey [13] and IBM Bluemix [14). Through consuming
mobile backend services, developers can release mobile apps with rich user experiences
much more rapidly than before. However, with the market growth of mobile backend
services, more and more equivalent services with same or similar functionalities (e.g.,
nearby restaurant recommendation service) are released in MBaaS or PaaS systems.
When facing more and more choices, it turns to be a more and more challenging process
for mobile developers to discover mobile backend services with high ROIs.
Many existing solutions have been proposed to recommend appropriate Web
services for web or desktop developers (e.g., based on keyword matching, popularity
ranking, consumer application clustering, and etc.), while few of them considers the
unique characteristics of mobile backend services. Therefore, their recommendation
results are not effective enough for mobile developers. Although most mobile backend
services are implemented and provided as traditional or RESTful Web services, they
indeed have multiple unique characteristics over traditional Web services from the
perspective of their consumers (i.e., mobile apps). For example, since various of device
data (e.g., screen resolution, network connection mode), sensor data (e.g., GPS sensor)
and user data (e.g., user’s orientation) in mobile devices can provide good hints to
improve results of mobile backend services (e.g., nearby restaurant recommendation), if a
mobile backend service makes good use of mobile data, the service probably will be more
suitable for the consumption of mobile apps. However, to the best of our knowledge,
there is no existing work that explicitly focuses on such unique characteristics of mobile
backend services. Therefore, directly applying existing solutions for the recommendation
of mobile backend services is not effective enough.

Dept. of CSE 2024-25 Page 1

Weather forecasting system

Chapter 2
MBaaS and Its Characteristics

2.1 MBaaS
Mobile Backend as a Service, also known as ‘MBaaS’, is an efficient computing
architecture that connects mobile applications to cloud computing services. These
platforms help you to reduce the time that is required to build the mobile applications.
MBaaS allows the developers to focus on complex and core features instead of the low-
level tasks. MBaaS platforms are also preferred over Mobile Enterprise Application
Platforms (MEAPs).

2.2 Characteristics of MBaaS

2.2.1 Mobile Data Sensitivity:
Mobile backend services usually rely on mobile data (e.g., mobile device characteristics,
real-time data collected by mobile device sensors, or user data stored in mobile devices)
to improve their analysis results. However, such personal data are very sensitive for users.
2.2.2 Data Traffic Efficiency:
To avoid high charges of users’ mobile data traffic, mobile backend services should not
introduce large data transmission volume.
2.2.3 Responsiveness:
Since mobile users usually have little tolerance for slow responses, mobile backend
services need to be implemented in right ways (e.g., asynchronous mode) to improve their
responsiveness.
2.2.4 Adaptiveness:
Since the user quantity of a mobile app is not predictable and can potentially have an
explosive growth in seconds or minutes, mobile backend services should also be adaptive
enough to react to such unpredictable changes.

Dept. of CSE 2024-25 Page 2

Weather forecasting system

Chapter 3
PROPOSED SYSTEM
Based on the summarized unique characteristics, we propose an intelligent
recommendation approach for mobile backend services. In the approach, given a specific
natural-language-based feature requirement description from mobile developers, our
approach first applies Natural Language Processing (NLP) based techniques to identify
feature-relevant mobile backend services, and then prioritize them based on ranking
scores that will be flexibly computed based on metrics corresponding to unique
characteristics of mobile backend services as well as interests or feedbacks of mobile
developers as shown in Fig 3.1. Note that, although currently we propose and implement
four metric analyzers for the above-mentioned unique characteristics of mobile backend
services, the approach supports the extending of metric analyzers. For example, if we find
a new unique characteristic of mobile backend services in the future, we can implement a
new metric analyzer with certain interfaces defined by the approach for the new
characteristic. Once new analyzer is provided, the approach can automatically use new
metrics to prioritize recommendation results.

Fig. 3.1 Approach Overview

In general, our approach includes two phases: the offline phase and the online
phase. In the offline phase, we first analyze feature concepts of mobile backend services
Dept. of CSE 2024-25 Page 3
Weather forecasting system

based on their specifications. Then we compute unique characteristic metrics of mobile

backend services based on their specifications stored in their registered repository and
their runtime monitoring data captured by their hosting platform. Section 3.1 describes
the availability of the inputs required by this phase. Section 3.2 and Section 3.3 describes
the details of the first step and the second step of this phase, respectively. In the online
phase, given a feature request from a mobile developer, we first apply NLP-based tech-
niques (e.g., topic analysis) to analyze main concepts of the feature request. Then,
through matching the main concepts of the feature request with feature concepts of mo-
bile backend services in the repository, we identify out the feature relevant mobile back-
end services. After that, we prioritize the identified mobile backend services based on
their unique characteristic metrics as well as preferences of the mobile developer. Finally,
the prioritized mobile backend services will be recommended to the mobile developer.
Section 3.4 describes the analysis process of main concepts of feature requests from mo-
bile developers. Section 3.5 describes the identification process of feature relevant mobile
backend services. Section 3.6 describes the prioritization process for the identified feature
relevant mobile backend services.

3.1 Availability of Inputs in the Offline Phase

The inputs of this phase includes a mobile backend service repository, which provides
limited mobile backend services in the form of RESTful Web Services with their specifi-
cations (e.g., feature description, input parameters with descriptions, and output parame-
ters with descriptions), and also runtime monitoring data, which captures performance or
runtime data (e.g., request timestamp, response time, input data size, output data size of
each consumption) during actual consumption scenarios.
With the rapidly growth of MBaaS or PaaS platforms, more and more backend
services are being deployed on and managed by those platforms. Since that almost each
of such platforms provides a catalog of its managed services, the input “mobile backend
service repositories” of this phase in our approach can be easily extracted from such cata-
logs. Besides that, since such services are totally managed and controlled by such plat-
forms, it will be very easy and natural for such platforms to monitor the runtime of

Their managed service instances. During the monitoring process, the input “run-
time monitoring data” required by our approach can also be easily captured.

Dept. of CSE 2024-25 Page 4

Weather forecasting system

Chapter 3
SYSTEM REQUIREMENTS SPECIFICATION
3. Functional Requirements

3.3.1 Software Requirements:

This software package is developed using Html, CSS for frontend and JavaScript for the
backend. Using Vs Code as a text editor and Google Chrome for the execution of our
code.
Required Specifications for our Device:

 Operating System: Windows 7, 8, 9, 10 .

 Language: Html , Css , Javascript.
 API : Openweathermap api

3.3.2 Hardware Requirements:

 Processor: Intel core i3 or above for a stable experience and fast
retrieval of data.
 Hard Disk: 4GB and above
 RAM: 256 MB or more, recommended 2 GB for fast reading and
writing capabilities which will result in better performance time.

3.4 Non-Functional Requirements:

3.4.1 Usability Requirements

 Our user interface should be interactive simple and easy to under-
stand . The system should prompt for the user and administrator to
login to the application for proper input criteria.
 Weather Application shall handle expected and non expected er-
rors in ways that prevent loss in information and long downtime
period.

3.4.2 Security Requirements

 System should be using secure web forecasting API.
 Normal users can just read information about the weather but they
cannot edit or modify anything except their personal and some
other information if required.

Dept. of CSE 2024-25 Page 5

Weather forecasting system

 System will have different types of users and every user has ac-
cess constraints.
 Proper user authentication should be provided.
 Personal details like location should not be stored for security
purpose

3.4.3 Availability Requirements

Availability requirements for a weather application using APIs are crucial to
ensure that the service is consistently accessible and operational.
Here are key availability requirements:
 Uptime Percentage: Maintain a high level of service availability,
such as 99.9% uptime. Users rely on the weather application for
real-time information, so a high uptime percentage ensures that the
service is consistently accessible.
 Load Balancing: Use load balancing to distribute incoming traffic
across multiple servers or instances. Load balancing helps distribute
the load evenly, preventing individual servers from becoming over-
whelmed and improving overall system performance and availabil-
ity.
 Monitoring and Alerting : Implement continuous monitoring of key
metrics and set up alerting systems to notify administrators of any
issues or anomalies. Proactive monitoring allows for the rapid iden-
tification and resolution of potential problems, minimizing down-
time.
 Scalability: Design the system to be scalable, allowing for the
seamless addition of resources during periods of increased demand.
Scalability ensures that the application can handle varying levels of
traffic and user activity without degradation in performance.
 Backup and Recovery : Regularly back up critical data and imple-
ment robust recovery procedures. In the event of data loss or system
failures, a well-defined backup and recovery strategy ensures that
the application can be restored quickly and efficiently.
3.4.4 Performance Requirements:
 The system shall accommodate high number of users simultaneously
and users can check the weather of any location any number of
times.
 Responses to view information shall take no longer than 5 seconds
to appear on the screen.

Dept. of CSE 2024-25 Page 6

Weather forecasting system

Chapter 4
SYSTEM DESIGN.

4.1 Architectural Design

The design phase in weather forecasting application development is a crucial stage
where the conceptual ideas and requirements are transformed into a detailed and vis -
ually appealing blueprint. This phase involves creating the Data flow Diagrams, ER
model design, and the overall architecture of the weather application

4.4.1 Data Flow Diagram of Weather Forecasting System :

Data Flow Diagram(DFD) :

serves as a visual representation of the flow of information within the system. This dia -
gram illustrates how data, such as weather information, user details, and API Transac -
tions in Weather Application.
Let's Draw a Dataflow Diagram for our project:

Data Flow Diagram for Weather Forecasting Project

Dept. of CSE 2024-25 Page 7

Weather forecasting system

4.4.2 ER Model for Weather Forecasting system :

An Entity-Relationship Diagram (ERD) for a Weather Application is the entities and

their relationships within the system.

Let's Draw an ER Diagram for our Weather Application:

ER Diagram for Todays Weather system

Entities:
 User: Attributes User Id (Primary Key)
 City: Attributes : City Name ( Primary Key ) , API Key value.
 Weather Details: Attributes: Temperature , Wind Speed , Weather Descrip-
tion , Humidity.
Relation:
 Enters: User enters the city name in the application.
 Returns: API returns an list of weather details having temperature , wind
speed , humidity and weather details

Dept. of CSE 2024-25 Page 8

Weather forecasting system

4.4.3 Use Case Diagram:

A use case diagram is a visual representation of the functional requirements of a system,
illustrating how users interact with the system and the system's responses. For a weather
forecasting app, the use case diagram will include actors such as "User," "Weather Data
Provider," or "Administrator".

Here's a simplified use case diagram for a weather forecasting system:

Use case Diagram for Weather Forecasting App

Description of the Use Case Diagram :

 View Current Weather:
o Actor: User
o Description: Allows the user to view the current weather condi-
tions for their selected location.
 View Hourly Weather Description:
o Actor: User
o Description: Enables the user to check the weather description
for the selected location.
 View Daily Forecast:
o Actor: User
o Description: Permits the user to access the daily weather forecast
for the chosen location.
 Set Location Preferences:
o Actor: User
o Description: Allows the user to set and manage location prefer-
ences for weather forecasts.
 Receive Weather Alerts:
o Actor: User
o Description: Enables the user to receive alerts for severe weather
conditions or customized weather events.

Dept. of CSE 2024-25 Page 9

Weather forecasting system

CONCLUSION
We first systematically studied and summarized out four unique characteristics of mobile
backend services (i.e., Mobile Data Sensitivity, Data Traffic Efficiency, Responsiveness,
and Adaptiveness). Based on such unique characteristics of mobile backend services, we
proposed an extendable recommendation approach for mobile backend services to help
mobile developers to efficiently identify what they really need. Through empirical evalua-
tions we conducted on hundreds of mobile backend services, we demonstrated the effec-
tiveness and efficiency of the proposed approach.

Dept. of CSE 2024-25 Page 10

Weather forecasting system

REFERENCES

[1]. ProgrammableWeb, URL: [Link]

[2]. André Ribeiro, and Alberto Rodrigues da Silva, Survey on CrossPlatforms and
Languages for Mobile Apps, International Conference on the Quality of Information and
Communications Technology.2012.
[3]. Meng S, Dou W, Zhang X, et al. KASR: A Keyword-Aware Service
Recommendation Method on MapReduce for Big Data Application, TPDS, 2013.
[4]. Li C, Zhang R, Huai J, et al. A Probabilistic Approach for Web Service Discovery
Services Computing, 2013.
[5]. Tang M, Jiang Y, Liu J, et al. Location-aware collaborative filtering for QoS-based
service recommendation, IEEE International Conference on Web Services (ICWS), 2012.
[6]. Ahmed W, Wu Y, Zheng W. Response Time based Optimal Web Service Selection,
IEEE Transactions on Parallel and Distributed Systems, 2013.
[7]. Zheng Z, Ma H, Lyu M R, et al. Collaborative web service QoS prediction via
neighborhood integrated matrix factorization, IEEE Transactions on Services Computing,
2013.
Dept. of CSE 2024-25 Page 11
Weather forecasting system

[8]. Cao B, Liu J, Tang M, et al. Mashup Service Recommendation based on User Interest
and Social Network, IEEE International Conference on Web Services (ICWS), 2013.
[9]. Xu W, Cao J, Hu L, et al, A Social-Aware Service Recommendation Approach for
Mashup Creation, IEEE International Conference on Web Services (ICWS), 2013.
[10]. Chen L, Hu L, Zheng Z, et al. Wtcluster: Utilizing tags for web services clustering,
Service-Oriented Computing, Springer Berlin Heidelberg, 2011.
[11]. StackOverflow, URL: [Link]
[12]. Parse, URL: [Link]
[13]. Kinvey, URL: [Link]
[14]. IBM Bluemix, URL: [Link]
[15]. Rapidvalue, URL: [Link]

Dept. of CSE 2024-25 Page 12