4.3 Представлення результатів тестування пз (у хронологічному порядку, які помилки були виявлені і виправлені)

Як було описано вище, тестування проводилось за допомогою вбудованих засобів потужнього пакету для статичного аналізу SciToolsUnderstand. Серед усіх тестів, що були проведені для розробленого програмного забезпечення можна виділити три основні групи, або ж три критерії за якими тестувався код:

• невикористовувані екземпляри полів класу.

• невикористовувані екземпляри локальних зміних.

• невикористовувані методи класу.

Окрім трьох вищеописаних груп програмне забезпечення тестувалось ще на відповідність конвенції іменування ідентифікаторів мови Java, що була розроблена компанією Sun. Дана конвенція включаєправилаіменування наступних сутностей:

• файлів вихідного коду.

• класів.

• інтерфейсів.

• методів.

• пакетів.

• зміних.

Під час першого етапу прогонки файлів вихідного коду на помилки було отримано наступну ситуацію:

118 попереджень всього. З них

1 невикористовувана зміна.

2 невикористовуваних локальних зміних.

115 невикористовуваних методів.

Рисунок 4.3.1 – Список помилок при першому тестуванні.

Як видно з рисунку серед 118 помилок, аж 115 помилок займають невикористовуванні методи, але як таке може бути взагалі? На перший погляд може здатись, що багато написаного коду у программі взагалі не використовується, але ж насправді це не так. Справа в тому, що всі особливості мови Java можуть впливати тільки на процес кодування, але й на процес тестування. Така особливість мови Java як відсутність вбудованих засобів для опису структур змушує розробників описувати структури у вигляді класів з полями, які мають рівень доступу public, при цьому в цих класах не має жодного конструктора, лише поля. Таке вирішення проблеми є досить розповсюдженим і по суті правильним, але статичний аналізатор коду помітить в цьому очевидні помилки: ми не використовуємо цих зміних всередині класу, а отже вони є непотрібними. Насправді ж, як ми знаємо, ці зміні будуть використовуватись іншими класами всередині їх об’єктів. Аналогічно до вищеописаного прикладу подібна ситуація відбувається із методами класів. Для прикладу розглянемо метод run() діалоговоговікна, що зображений на рисунку 4.3.2. Даний метод потрібен для запуску вікна в автоматичному режимі, цей метод по суті потрібен, але викликатиметься він неявно, тому статичний аналізатор відніс його до розряду помилок. Таким чином можна сказати, що більша частина помилок є результатом неправильного трактування тексту програми статичним аналізатором.

Рисунок 4.3.2 – Приклад не використовуваного методу.

Тим не менш, значна частина підсвічених помилок є справді сигналізатором про невикористання деяких методів. На етапі проектування вважалося, що ці методи будуть потрібні, а потім виявилось, що вони не використовуватимуться.

Також, як ми бачимо з рисунку 4.3.1 є 2 локальних та 1 поле класу, що також не є використовуваними.

Було проведене виправлення вищевказаних помилок та повторне тестування, що дало наступні результати:

Рисунок 4.3.3 – Список помилок при другому тестуванні.

Як видно з рисунку – кількість не використовуваних методів була зменшена до незначної кількості, а досягнулось це завдяки фільтруванню методів, що використовуються неяно. При третьому тестуванні майже всі попередження зникли окрім деяких. Варто додатково сказати, що статичний аналізатор не видавав жодних помилок пов’язаних з неправильним іменуванням ідентифікаторів в програмі.

Таким чином, можна сказати, що тестування програми було проведено за допомогою статичного аналізатора з пакету SciTools Understand та кількість попереджень, що видавалась аналізатором під час тестувань була зведена до мінімальної кількості.

4.4 Результати оцінки якості розробленого програмного забезпечення на основі метричного аналізу.

Як відомо на основі метричного аналізу можна дізнатись про трудомісткість та об’єм логіки, що вкладені у програмну систему. Про дану систему говорять показники, що вимірюються у кількості рядків програмного коду, кількості функцій, класів, тобто функціонального коду, а також коментарів – пояснювального коду. Дані показники приведені в таблиці 4.1.

Таблиця 4.1 – Опис основних метричних показників розробленого ПЗ.

Значення метричних показників
CountDeclClass	141
CountDeclFile	25
CountDeclFunction	306
CountLine	7001
CountLineBlank	782
CountLineCode	5456
CountLineComment	954
CountStmtDecl	1186
CountStmtExe	2261
RatioCommentToCode	0,17

Також за допомогою метричних показників можна визначити цикломатичну складність програмного забезпечення. Цикломатична складність, як всім відомо, характеризує кількість логічних зв’язків, які наявні в програмі. Чим вища цикломатична складність, тим складнішою вважається програма.

Рисунок 4.4.1 – Стовпчата діаграма об’єму коду (кількості стрічок).

Якщо поглянути на діаграми (рисунки 4.4.4, 4.4.5 5.5.5), які візуалізують метричні показники представлені в таблиці, можна побачити, що загальна кількість стрічок перетнула позначку в 7 тис. рядків і 5.5 тис. рядків з них є функціональним кодом програми. Весь проект умістився в 25 окремих текстових файлів, а максимальна цикломатична складність програмного забезпечення досягнула позначки 7.

Всі ці дані говорять достатню складність проекту, а якщо розглядати його у рамках курсового проекту, то можка сказати, що складність є високою і було виконану велику кількість роботи.

Рисунок 4.4.2 – Стовпчата діаграма кількості файлів.

Рисунок 4.4.3 – Діаграма, що відображає цикломатичну складність програми.

4.5 Представлення результатів, що демонструють функціональність розробленого ПЗ.

В результаті нашої роботи було розроблено програмне забезпечення, яке полегшує управління підприємством служби таксі або ж таксопарком. Відбувається це шляхом автоматизації щоденних дій працівників підприємства (директора та операторів). Зменшення рутинної роботи для операторів стимулює їх до більш якісного та швидкісного прийняття замовлень, що в свою чергу підіймає якість сервісу обслуговування як такого. Також система допомагає якісно та легко вести статистику про пророблену роботу (про приняті замовлення, підрахунок грошових сум, що були зароблені і тд). Додатково система дозволяє вести облік працевлаштованих водіїв та налаштовувати індивідуальний графік роботи кожного з них. Вести облік машин, що зареєстровані у таксопарку, а також встановлювати тарифи на пасажирські перевезення.

Робота із системою розпочинається із процедури авторизації. Авторизація відбувається по логіну та паролю, які вводяться у вікно авторизації (Рисунок 4.6).

Рисунок 4.4.2 – Вікно авторизації у системі.

В системі можуть бути зареєстровані користувачі з трьома рівнями доступу:

• адміністратор (наділений найповнішими повноваженями такими як читання інформації з БД, запис, редагування та видалення).

• директор (наділений можливістю читати будь-які дані для її перегляду та ведення статистики).

• оператор (має доступ лише до потрібних даних, може оформляти заявки на пасажирські перевезення та підтверджувати виконані замовлення).

Вся інформація про користувачів та їх рівні доступу до даних зберігається у відповідній таблиці у базі даних. Після введення логіна та пароля користувача з рівнем доступу оператора відбувається запит до БД, який підтвердить, що даний користувач існує і відповідна функція поверне інформацію про рівень доступу. Після чого з’явиться наступне вікно (Рисунок 4.5). Вікно оператора розділене на дві частини: таблицю вільних водіїв (позначена зеленим) та таблицю водіїв, що є зайнятими в даний час (позначення червоним). У першу завантажуються всі водії, що знаходяться в даний момент на роботі, але очікуються нового замовлення, у другу ж водії, що знаходяться на замоленні. Оператор може змінювати статус водіїв у відповідності з інформацією, яку він отримав від них по рації.

Рисунок 4.4.2 – Головне робоче вікно користувача в режимі оператора.

Коли оператор робить подвійний клік по рядку з таблиці вільних водіїв, з’являється діалогове вікно прийняття замовлення (Рисунок 4.8). Туди вводиться відповідна інформація про клієнта, який здійснив замовлення, про місце відправки та призначення. Також фіксується час прийняття. Після того як замовлення буде прийняте, водій переноситься у верхню таблицю (зайнятих водіїв) і буде там знаходитись, доки не виконає замовлення. По закінченню водій повинен зв’язатись із оператором та сповістити про завершення замовлення, тоді також через подвійний клік з’являється вікно підтвердження замовлення, заповняється дані про кілометраж, ціну перевезення, вводиться коментар при необхідності та фіксується час. Замовлення вважається завершеним на вноситься у таблицю замовлень в БД.

Така ситуація продовжується циклічно до тих пір, поки не закінчується робоча зміна одним водіїв, та починається робоча зміна інших, вони замінюються в таблицях, а попердні вивантажуються.

Рисунок 4.4.2 – Головне вікно оператора. Прийом замовлення.

Також у системі доступний функціонал для роботи адміністратора. Головне вікно адміністратора зображене на рисунку 4.9. Андміністратор володіє найбільшими повноваженнями, як вже згадувалось раніше і це покладає на нього певні функції, він повинен:

• додавати нових користувачів та налаштовувати їх права доступу.

• додавати інформацію про нові авто, або ж видаляти стару.

• додавати інформацію про нових водіїв, або ж видаляти старі.

• додавати нові тарифи, або ж видаляти старі.

• додавання або ж видалення та редагування іншої інформації.

Рисунок 4.4.2 – Головне вікно адміністратора. Перегляд авто.

Усі дані якими оперує система TaxiManager 1.0 зберігаються у базі даних на основі сервера MySQL. Нарощення, заповнення, модифікація та видалення усіх даних, які зберігаються у різних таблицях бази даних виконується через код програми за допомогою JDBCконектора.

Конектор є лише механізмом, що дозволяє фізично під’єднатись до бази даних, але вся логіка обробки даних у БД винесена в окремий клас DataBaseManager.java.

Опис основних його функцій подано в зведеній таблиці 4.1.

Таблиця 4.1 – Опис основних функцій класу DataBaseManager.

№ п.п	Назва функції	Опис функції
1	checkLogAndPass(String ulog,String upass)	Функція перевіряє чи наявні дані логін та пароль в базі даних, а також повертає рівень доступу у вигляді числа, якщо такі дані відсутні в БД, то повертається -1.
2	DeleteOrder(int IDOrder)	Функція видаляє запис із таблиці замовлень із заданим Id.
3	ArrayList<DS_Order> selectOrders()	Функція здійснює вибірку усіх записів із таблиці замовлень та повертає їх у вигляді динамічного списку структур.
4	setOffline()	Функція встановлює фляжок наявності на роботі усіх водіїв в положення “вимкнено”.
5	setOnline(int numShift)	Функція виконує протилежні функції setOffline() дії.
6	ArrayList<DS_Driver> selectDrivers()	Функція здійснює вибірку усіх записів із таблиці водіїв.
7	ArrayList<DS_Driver> comboSelectDrivers()	Функція здійснює вибірку усіх записів із таблиці водіїв та авто.
8	ArrayList<DS_Client> selectClient()	Функція здійснює вибірку усіх записів із таблиці клієнтів.
9	ArrayList<DS_Car> selectCars()	Функція здійснює вибірку усіх записів із таблиці авто.

Продовження таблиці 4.1 – Опис основних функцій класу DataBaseManager.

№ п.п	Назва функції	Опис функції
11	ArrayList<DS_Driver_Free> getDriversFree()	Функція здійснює вибірку усіх водіїв, які в даний момент знаходяться на роботі, але є вільними.
12	ArrayList<DS_Driver_Busy> getDriversBusy()	Функція здійснює вибірку усіх водіїв, що в даний момент знаходяться на замовленні.
14	ArrayList<DS_Shift> selectShifts()	Функція здійснює вибірку усіх записів із таблиці робочих змін.
15	ArrayList<DS_Rate> selectRates()	Функція здійснює вибірку усіх записів із таблиці тарифів.
16	ArrayList<DS_User> selectUsers()	Функція здійснює вибірку усіх записів із таблиці користувачів системи.
17	setClient()	Функція додає нового клієнта до БД.
18	addOrder()	Функція додає нове замовлення до БД. (Але воно ще не є підтверджене)
19	acceptOrder()	Функція підтверджує замовлення в БД.
20	updateClient()	Функція редагує дані про клієнта. (Тобто вносить зміни до полів певного запису)
21	carSet()	Функція додає інформацію про новий автомобіль у таблицю авто в БД.
22	updateCar()	Функція редагує дані про клієнта. (Тобто вносить зміни до полів певного запису)

Кінець таблиці 4.1 – Опис основних функцій класу DataBaseManager.

№ п.п	Назва функції	Опис функції
23	driverSet()	Функція додає дані про нового водія у БД.
24	updateDriver()	Функція редагує дані про водія. (Тобто вносить зміни до полів певного запису)
26	driverSetBysy()	Функція встановлює водія у БД в положення “на замовленні”
27	driverSetOnline()	Функція встановлює водія у БД в положення “на роботі”
28	rateSet()	Функція додає новий тариф до БД.
29	updateRate()	Функція редагує дані в записі відповідного тарифу.
30	shiftSet()	Функція додає інформацію про нову робочу зміну певного водія.
31	updateShift()	Функція дозволяє редагувати інформацію про робочу зміну певного водія.
32	userSet()	Функція додає інформацію про нового користувача системи та налаштовує права доступу у відповідності з таблицею (Адміністратор, Директор, Оператор)