Intelligent Algorithms in Software Engineering: Proceedings of the 9th Computer Science On-line Conference 2020, Volume 1 Radek Silhavy - Read the ebook online or download it to own the full content
Intelligent Algorithms in Software Engineering: Proceedings of the 9th Computer Science On-line Conference 2020, Volume 1 Radek Silhavy - Read the ebook online or download it to own the full content
com
https://textbookfull.com/product/intelligent-algorithms-in-
software-engineering-proceedings-of-the-9th-computer-
science-on-line-conference-2020-volume-1-radek-silhavy/
OR CLICK HERE
DOWLOAD EBOOK
https://textbookfull.com/product/software-engineering-and-algorithms-
in-intelligent-systems-radek-silhavy/
textbookfull.com
https://textbookfull.com/product/cybernetics-and-algorithms-in-
intelligent-systems-radek-silhavy/
textbookfull.com
Advances in Intelligent Systems and Computing 1224
Intelligent
Algorithms
in Software
Engineering
Proceedings of the 9th Computer
Science On-line Conference 2020,
Volume 1
Advances in Intelligent Systems and Computing
Volume 1224
Series Editor
Janusz Kacprzyk, Systems Research Institute, Polish Academy of Sciences,
Warsaw, Poland
Advisory Editors
Nikhil R. Pal, Indian Statistical Institute, Kolkata, India
Rafael Bello Perez, Faculty of Mathematics, Physics and Computing,
Universidad Central de Las Villas, Santa Clara, Cuba
Emilio S. Corchado, University of Salamanca, Salamanca, Spain
Hani Hagras, School of Computer Science and Electronic Engineering,
University of Essex, Colchester, UK
László T. Kóczy, Department of Automation, Széchenyi István University,
Gyor, Hungary
Vladik Kreinovich, Department of Computer Science, University of Texas
at El Paso, El Paso, TX, USA
Chin-Teng Lin, Department of Electrical Engineering, National Chiao
Tung University, Hsinchu, Taiwan
Jie Lu, Faculty of Engineering and Information Technology,
University of Technology Sydney, Sydney, NSW, Australia
Patricia Melin, Graduate Program of Computer Science, Tijuana Institute
of Technology, Tijuana, Mexico
Nadia Nedjah, Department of Electronics Engineering, University of Rio de Janeiro,
Rio de Janeiro, Brazil
Ngoc Thanh Nguyen , Faculty of Computer Science and Management,
Wrocław University of Technology, Wrocław, Poland
Jun Wang, Department of Mechanical and Automation Engineering,
The Chinese University of Hong Kong, Shatin, Hong Kong
The series “Advances in Intelligent Systems and Computing” contains publications
on theory, applications, and design methods of Intelligent Systems and Intelligent
Computing. Virtually all disciplines such as engineering, natural sciences, computer
and information science, ICT, economics, business, e-commerce, environment,
healthcare, life science are covered. The list of topics spans all the areas of modern
intelligent systems and computing such as: computational intelligence, soft comput-
ing including neural networks, fuzzy systems, evolutionary computing and the fusion
of these paradigms, social intelligence, ambient intelligence, computational neuro-
science, artificial life, virtual worlds and society, cognitive science and systems,
Perception and Vision, DNA and immune based systems, self-organizing and
adaptive systems, e-Learning and teaching, human-centered and human-centric
computing, recommender systems, intelligent control, robotics and mechatronics
including human-machine teaming, knowledge-based paradigms, learning para-
digms, machine ethics, intelligent data analysis, knowledge management, intelligent
agents, intelligent decision making and support, intelligent network security, trust
management, interactive entertainment, Web intelligence and multimedia.
The publications within “Advances in Intelligent Systems and Computing” are
primarily proceedings of important conferences, symposia and congresses. They
cover significant recent developments in the field, both of a foundational and
applicable character. An important characteristic feature of the series is the short
publication time and world-wide distribution. This permits a rapid and broad
dissemination of research results.
** Indexing: The books of this series are submitted to ISI Proceedings,
EI-Compendex, DBLP, SCOPUS, Google Scholar and Springerlink **
Intelligent Algorithms
in Software Engineering
Proceedings of the 9th Computer Science
On-line Conference 2020, Volume 1
123
Editor
Radek Silhavy
Faculty of Applied Informatics
Tomas Bata University in Zlín
Zlín, Czech Republic
This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
Preface
Software engineering research papers and topics are presented in this proceedings.
This proceedings is a Vol. 1 of the Computer Science On-line Conference. Papers in
this part discuss intelligent algorithms, application of machine and statistical
learning in the software engineering research.
This book constitutes the refereed proceedings of the Intelligent Algorithms in
Software Engineering section of the 9th Computer Science On-line Conference
2020 (CSOC 2020), held online in April 2020.
CSOC 2020 has received (all sections) more than 270 submissions from more
than 35 countries. More than 65% of accepted submissions were received from
Europe, 21% from Asia, 8% from Africa, 4% from America and 2% from Australia.
CSOC 2020 conference intends to provide an international forum for the dis-
cussion of the latest high-quality research results in all areas related to computer
science.
Computer Science On-line Conference is held online, and modern communi-
cation technology, which are broadly used, improves the traditional concept of
scientific conferences. It brings equal opportunity to participate for all researchers
around the world.
I believe that you find the following proceedings exciting and useful for your
research work.
v
Organization
Program Committee
vii
viii Organization
xi
xii Contents
1 Introduction
management. This was clearly supported by Labels: Data Center, Downtime, www.
evolven.com (2014), and indeed software application downtime can cause the business
operation ceased. Business company has option that it can run an IT production support
team to provide support service to whichever business-as-usual (BAU) system running
in the organization. Another option is that it can engage service provider to provide the
same IT support service. Regardless whichever option is chosen, the time spent on con-
ducting root cause analysis on software application error is crucial. Without accurately
identifying the valid error, it creates impact to the service restoration to the software
application.
As of the fact, identifying the root cause of the software application error is crucial
before the resolution is decided and deployed into production environment. There are
several required actions in the root cause analysis activity. These actions are:-
Most of the time, collecting input information for root cause analysis is time con-
suming. This statement is supported by Management Logic (2012) stated that “The most
time consuming aspect of Root Cause Analysis (RCA). Practitioners must gather the all
the evidence to fully understand the incident or failure.”. On the other hand, Horvath
(2015) had also pointed out that “While the analysis itself can be time-consuming, the
chance to mitigate or eliminate the root causes of several recurring problems/ problem
patterns is definitely worth the effort.”. Hence, it is crucial to look for an efficient method
to reduce the prolonging time at the root cause analysis activity.
Generally, each software application has its built-in event logging ability. The pur-
pose of this event logging records the information of what activity is carried out or
even what incident is occurred at that exact time. This information includes appropriate
debugging information, and later the same information can be analyzed for software
application root cause analysis purpose. The concern raised to the required information
logging is that how much logging information is accepted as sufficient for software
application root cause analysis. In addition, what is the appropriate category for the
logging event such as information, error, debug, and fatal should be fetched as the input
information to the root cause analysis activity. In the situation that if the extensive event
logging level is enabled, this can lead to excessive logging information generated. With
that, there are two issues raised.
Fig. 1. Software Application is required sufficient server resources to execute all its functionality.
To identify the root cause of software application error, it can be prolong under the
following challenges.
With all the mentioned concerns and scenarios, by depending software application
log file alone is not sufficient to conduct software application root cause analysis when-
ever error is occurred beyond the software application layer. Hence a proposed research
is required for establishing a prescriptive analytical logic model. This proposed logic
4 H. M. Wong et al.
model incorporated the proposed algorithm to conduct the root cause analysis activity. It
must target to increase the accuracy for error identification, and to reduce the prolonging
time spent on the duration of root cause analysis. Therefore, this is a good potential to
contribute new knowledge to the software application analysis.
3 Motivations
There are three major motivations trigger the statement of problem.
The 1st Motivation
With the software application error log file alone, it may not be adequate for analysis to
identify the root cause of software application error if the cause is outside the software
application layer. The impacts are shown along with the involved components.
A Prescriptive Analytical Logic Model Incorporated 5
Environment Impact
Infrastructure Layer.
Equipment Impact
Insufficient of server resources such as CPU, Memory, Disk, Network Card
Bandwidth.
The 2nd Motivation
Time consuming to read through the software application log file manually during
root cause analysis activity. The impacts are shown along with the supporting points.
Management Impact
i. Software applications cannot afford to have downtime as it can impact the business
operation.
ii. High expectation on software application support team by the management to resume
software application service when software application service or certain functions
are unavailable.
People Impact
The time spent on analyzing the software application error manually will be longer if
the input information is taking longer time to analyze before the valid root cause is
identified.
The 3rd Motivation
The root cause analysis activity is conducted by human, it is very subjective to the
person would make a right or wrong judgment on the software application error. The
impact is shown along with the supporting point.
People Impact (Different from the 2nd Motivation)
Experience, Knowledge, Skill - Any wrong judgment on the valid software application
error would lead to a wrong direction to create a useless resolution and eventually end
up with wasting effort and time to fix a wrong software application error.
This has derived the following fish bone diagram to illustrate all the involved impacts
(Fig. 2).
The fish bone diagram illustrates that it has four major impacts contributed to
the statement of problem. These impacts are Management, People, Environment and
Equipment.
6 H. M. Wong et al.
Fig. 2. Fish bone diagram to illustrate issues contributed to the software application malfunction-
ing.
• Management is always looking for effective outcome as they have sat a big amount
as part of the yearly budge of the year to the software application support team
department.
• People is mainly referring to the support team member’s capability whether the person
is capable to analyze the software application error, or even whether the person is able
to work under pressure.
• Environment consists of infrastructure and software application layers. The issues
happened in Environment can lead to the statement of problem would be far more
complicated and hard to identify the root cause of the error, because of the complexity
of the software application running in a multiple tier environment.
• Lastly is the Equipment that is referring to insufficient of server resources will also
lead to the statement of problem.
4 Statement of Problem
The time duration of root cause analysis conducted on software application error carries
crucial impact to the service restoration of business operation.
Explanation: The total time taken to resolve the software application error consists of the
duration for conducting the root cause analysis activity, and the duration for applying the
resolution. The solution may or may not involve the Software Development Life Cycle
(SDLC) activity for developing the fix by depending on the requirements of the fix. The
proposed resolution is focusing on shorten the time consumption on conducting the root
cause analysis activity.
A Prescriptive Analytical Logic Model Incorporated 7
5 Research Objectives
(1) To mitigate prolonging time duration on conducting root cause analysis activity.
(2) To improve accuracy on identifying the root cause whenever error is occurred.
There are different perspectives derived from the two primary objectives and it
is required to be listed down for determination. The points from the three different
perspective are shown as follows:-
Business Perspective
Technical Perspective
6 Literature Review
According to the past research, Stewart (2012) is focusing on debugging real-time soft-
ware application error using logic analyzer debug macros, whereby Eick et al. (1994)
they are focusing on presenting the error logs in a readable manner. Moreover, Wendy
and Dolores (1993) suggested to focus on error detection in software application at the
time of software development and maintenance. However, Salfner and Tschirpke (2015)
are focusing on analyzing error logs by applying the proposed algorithms in order to
predict future failure. Their software application error analysis approaches focus on soft-
ware application error log obtained from software application database. Some literature
suggested that the software application error analysis would be better if it is built in dur-
ing the software development process. This approach is still within the same application
development boundary without factoring in any other area of concerns. It can cause the
software application failure. In another way of explanation, whenever hardware CPU and
memory utilization is running high, or even storage disk space is running low, software
application logging may not be accurate anymore. Hence, the root cause analysis would
not be accurate to identify the real issue to understand the main reason to cause the soft-
ware application failure. Murínová (2015) had attempted to integrate multiple log files
8 H. M. Wong et al.
from various software monitoring tool and network devices for better root cause analysis
on Web application error. However, there is no proposed model stated in the research.
Even until Landauer et al. (2018), they introduced an unsupervised cluster evolution
approach that is a self-learning algorithm that detects anomalies in terms of conducting
log file analysis. However, this approach is under machine learning rather than AHP.
From a different point of view, this approach is good because it can be adopted into the
proposed model to detect the software application error. Hence, this is a great potential
to propose a logic model to research a new approach towards developing an algorithm
for software application error analysis. At the same time to contribute new knowledge
in the area of software application root cause analysis using AHP. By comparing the
above secondary data with the proposed logic model, it can be noticed that the focus
boundary on software application analysis. The technique to identify the root cause of
software application is different. They focus on software application boundary whereby
the proposed model focuses horizontally on all possible boundaries. In addition, due to
the focus boundary is different, it leads to the technique to identify the root cause of
software application also different.
On the other hand, there is a valid question such that why the PAL does not incorporate
Machine Learning instead. According to Klass (2018), the simple definition of Machine
Learning is that the algorithm in an IT system has the ability to independently find
solutions to problems by recognizing patterns in databases. Which means, the required
data must be fed into the IT system and processed under the algorithm in advance in
order to recognize the patterns in the data stock with the predefined definitions. Lastly,
the IT system must also contain the following unique abilities as the requirements, which
are:-
unique abilities. However, by comparing Machine Learning with PAL, there are certainly
differences.
The primary objective of PAL is to mitigate prolonging on conducting root cause
analysis activity. Hence, to eliminate unnecessary log scanning activities must be avoid-
able during the root cause analysis. Indeed to fulfill the primary objective, the following
approaches of PAL are proposed as follows:-
• Using the “time” of software application error event when it occurred as the key to
extract out log events from all the related logs.
• Extract only the exact amount of input information is important. Then, scan the error
only from the extracted amount of log rows.
• Standard error events are easily classified based on keyword, except for those unknown
error events.
• The PAL’s standard analysis module does the specific action based on the specific
error event occurred.
• The PAL’s analysis activity is based on the configurations of “Standard” and “Com-
plex” analysis modules together with the studies of past analysis and applied resolution
retrieved from the proposed model’s knowledge-based database.
• The situation can be happened such as more than one possible resolution is applicable
to resolve the identified root cause. Decision making is required.
• All the current analysis activities and resolution steps will be stored into a knowledge-
based database for the future reference.
• PAL is trained by the real data sponsored by SRM, IBM.
10 H. M. Wong et al.
Based on the given primary objective of PAL, and along with the proposed
approaches. The detail feature differences between Machine Learning and PAL can
be further compared into the following Table 2.
With the comparisons, although PAL has certain similarities comparing with
Machine Learning. However, the primary objective and approaches are different. There-
fore, PAL cannot be categorized to have Machine Learning intelligent, but it has the
ability to make decision using AHP approach to fulfill the research objective, i.e. to
mitigate prolonging on conducting root cause analysis activity. Indeed, the proposed
algorithm in PAL is aiming to handle ad-hoc error with immediate action rather than
spending longer time to recognize the error pattern or to perform error prediction.
7 Research Proposed
With a server (regardless it is physical or virtual) box, you have multiple layers. Most
common logs that are required is:-
i. System monitoring log for server resources such as CPU, Memory and Hard Disk
usage.
ii. Network monitoring log for the server such as network communication within the
Local Area Network (LAN).
iii. Operating System event log for server.
The proposed scope of this research is to define the algorithm. The algorithm consists of
simple and complex analysis inside the prescriptive analytical logic model for software
application error analysis. Therefore, by having the proposed logic model in the pro-
duction environment, the logic model is required to react to software application error
when the error is detected in the software application log file. With this logic model, it
is also required to retrieve other related log files through various software applications
shown as Fig. 3. The proposed algorithm mainly consists of two analysis areas, which
are simple and complex analysis to form a prescriptive analytical logic.
A Prescriptive Analytical Logic Model Incorporated 11
Table 2. The detail feature differences between Machine Learning and PAL.
Fig. 3. The proposed software application analysis algorithm will analyze across multiple
databases.
area, by predicting the software application behavior, it performs the suggested steps
and carry out the action against the software application error based on the analysis.
This will prevent future application failure based on the permission given to the offered
mode by the IT support team.
By focusing into the re-occur software application errors, these errors occur in a
specific pattern or feature, and the solution is often straight forward (can be applied after
validating the specific pattern or feature) to resolve the incidents. The human involvement
on this type of incidents would require less analysis but more on validating activities.
Hence if the validating activities can be predefined into a checklist, the logic model can
pick up the ultimate predefined solution and react to the incident automatically. This can
be achieved by the combination of the answers (yield from the validating activities in
the checklist). This would be the preferred method in the logic model that handles the
common software application incidents. We call this logic as simple analysis. The same
simple analysis logic can be applied to manage Server (a physical or virtual box running
a vendor Operating System) or even Networking devices (such as switch or router) if
they have incidents occur in the specific pattern or feature.
The software application errors which have no uniform pattern or feature, for this
type of software application errors. The percentage of human involvement is high. This is
because the person who handles the incident requires to obtain the software application
log files and to search any similar error logged in the past. We call these files and
records as input information. With the input information obtained, the person conducts
the analysis activities before the person can identify the software application error root
cause. Only the preferred resolution steps is agreed then it is applied to resolve the
software application error.
For the first time occurring software application error. If both yielding input infor-
mation activities and analysis activities can be automated. Base on the outcome of the
analysis activities, human expects to see a list down of each possible root cause along
with the proposed resolution steps in a complete list. Then, the decision is on the per-
son to choose which is the preferred option. If the person chooses to proceed with the
suggested resolution steps, then the person will receive the final question. The question
is expecting the response from the person, whether agrees to let the automated activities
execute the same suggested resolution steps automatically in the future if the same inci-
dent occurs again. Of course, this logic has the ability to handle unpredictable software
application errors by performing simulated analysis activities comparing with human,
we call this logic as complex analysis.
Whenever the complex analysis is triggered. It will pull the related logs based on
specific time frame (duration) before and during the software application failure from
various application logs. These logs are:-
i. Software Application logs is the beginning to trigger the root cause analysis,
ii. Configuration management logs is for understanding any recent applied software
application patches or Operating System patches,
iii. Performing and capacity monitoring logs is for identifying any hardware resources
running insufficient, and
iv. Production support ticketing tool logs is for cross-checking any related issue recently
occurred under the predefined database scheme.
14 H. M. Wong et al.
These above logs as input information will be utilized crucially for root cause analysis
to resolve the software application issue.
Indeed, the simple analysis can be existed independently at the initial stage. How-
ever, when the specific number of reoccur incidents hits. The complex analysis will be
activated to perform the required analysis activities automatically. It will produce the
complete analysis report and suggestion(s). Base on this suggested design, the complex
analysis would have a loosely but it is fairly important relationship with the simple
analysis. This is because the complex analysis needs to understand how many times the
simple analysis has handled the same incidents in the past. This information is crucial
to make a decision on suggesting the reasonable resolution steps to the human after the
complex analysis produces the analysis report.
No. Algorithm
1 with the granted permission, retrieve and/or integrate various log files obtained from all
involved software application log files/databases
2 Identify whether the newly reported software application error is first time occurrence or
re-occurrence by cross-checking the database which is associated to the prescriptive
analytical logic
3 Identify possible log data and select the necessary log data for analysis under the defined
software application error classification
4 Allocate weight to each possible software application error based on Analytic hierarchy
process (AHP)
5 Shortlist the software application error under the highest weight
6 Analyze the selected log data for shortlisted software application errors and define
possible resolution option
7 Allocate weight to each possible resolution option based on AHP
8 Shortlist the preferred resolution option under the highest weight
9 Deploy the preferred resolution option to fix the software application error under the
predefined condition
10 Store the analysis result and resolution action into a database which is associated to the
prescriptive analytical logic for future reference and knowledge base activities
The architectural design of the PAL is derived from the proposed algorithm and the
Fig. 4 is shown as follows:-
The PAL algorithm design consists of simple and complex analysis design, proposed
analytic hierarchy process design and knowledge based database design. From the simple
A Prescriptive Analytical Logic Model Incorporated 15
and complex analysis design, it further derives to top-down and bottom up design. All of
these designs will form PAL algorithm design as the complete model design. The PAL
consists of two configuration files that are the brain of the PAL to identify the known
errors and the action of the preferred resolution. This can be explained bu using the
process flow design of PAL (Fig. 5).
The process flow design of PAL:-
The Process Flow Design explains the use of the configuration files (first and second)
during the execution of the PAL. First configuration file is for error cross-reference
and the second configuration file is for carrying out the preferred action based on the
recognized error. The entire flow is explained as follows:-
Process 1
Use any existing market approach to detect Software Application error. This is because
the PAL should not re-invent the wheel. It should utilize the existing available approach
from the market for software application detection.
Process 2
Validate the new found Software Application error (Cross check with the first Configu-
ration file). The first configuration file contains the information regarding to the involved
software application, databases, and the knowledge based database.
• Based on the date and time of the new found Software Application error, PAL extracts
the events from the involved software application and databases to form a dataset.
• Then, based on the new found software application error as well as any error found
in the dataset as per the given date and time, PAL can cross-reference from the first
configuration file to identify out whether it is a new error or known error. Which
means, PAL will require to map out any error defined in the first configuration file.
• Based on the defined error to identify the new found error is actually a known error
in either an Alert, Warning or Valid Error category, or it is unidentified and really a
new found error.
Exploring the Variety of Random
Documents with Different Content
Private Maurace R. Bolton, Canadian Infantry, son of Mr. William
Bolton, Town Head Cottages, Low Bentham, killed in action 8th
March, 1916. Aged 25 years.
Private George Leatt, South African Corps, son of Mr. George Leatt,
Pendle Street, Skipton, died of Fever in South Africa 28th April,
1916. Aged 33 years.
Private Thomas Leatt, Berks. Regt., son of Mr. & Mrs. George Leatt,
Pendle Street, Skipton, killed in action April, 1916.
Private Frank Thompson, York & Lancs. Regt., son of Mr. & Mrs.
Richmond Thompson, Harding House, Crosshills, died as the result
of a motor car accident in France 10th April, 1916.
Rifleman Harry Thornton, King’s Royal Rifles, of Barnoldswick, died of
wounds 30th April, 1916. Aged 20 years.
Private Fred Fisher, Duke of Well’s Regt., son of Mr. T. Fisher, 20,
Bolton Road. Addingham, died of wounds 5th May, 1916. Aged 21
years.
Rifleman Frederick Ryder, King’s Royal Rifles, formerly of Addingham,
presumed killed May, 1916. Aged 26 years.
Private J. Bell, Canadian Exp. Force, son of Mr. Thomas Bell, Castle
Hill, Settle, killed in action 14th June, 1916.
First Class P.O. Frank Collins, H.M.S. “Indefatigable,” of Crosshills,
killed in action in the Battle of Jutland, 1st June, 1916.
Lance Corporal Albert Lister, Canadian Corps, son of Mr. & Mrs. J. W.
Lister, Low Bentham, killed in action 3rd June, 1916. Aged 26 years.
Private L. Parker, Canadian Exp. Force, brother of Mr. James Parker,
Ives Scarr, Ingleton, killed in action 7th June, 1916. Aged 37 years.
Private Harry R. Toft, Royal Fusiliers, son of the late Reverend J. Toft,
formerly of Skipton, killed in action 7th June, 1916. Aged 23 years.
Private John Young, Duke of Well.’s Regt., son of the late Mr. John
Young, Burton-in-Lonsdale, died at Clipstone Camp, 30th June,
1916. Aged 30 years.
Private Fred Benson, Duke of Well.’s Regt., son of Mr. William Benson,
199, Crag View, Cowling, killed in action 11th July, 1916.
Private F. Baldwin, Canadian Exped. Force, son of Mr. & Mrs. D.
Baldwin, formerly of Settle, killed in action July, 1916.
Private Harry Crane, Duke of Well.’s Regt., son of Mr. James Crane,
49, Rainhall Road, Barnoldswick, killed in action 25th July, 1916.
Aged 22 years.
Private S. Cross, Royal Fusiliers, of Clapham, killed in action 7th July,
1916.
Private Maurice Robinson Crowther, Leeds Pals Regt., son of Mr. John
Crowther, Ridley House, Grassington, officially reported killed in
action 1st July, 1916.
Private Herbert Clarke, West Yorks. Regt. son of Mr. Clarke, Kirkgate,
Settle, officially presumed killed 14th July, 1916.
Private Parrington Dixon, Prince of Wales Yorks. Regt., only son of Mr.
& Mrs. T. Dixon, Gawthrop, Dent, presumed killed in action 1st July,
1916. Aged 19 years.
Private John Bruce Davidson, Duke of Well.’s Regt., son of Mr. Joseph
Davidson, Dent, died of wounds 14th July, 1916, Aged 22 years.
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
textbookfull.com