Автоматизація ведення обліку замовлень на автомобільні перевезення

ЗМІСТ.

Вступ.

1. Розробка плану проекту.

1.1 Аналіз задачі, обгрунтування вибору моделі життєвого циклу для реалізації проекту.

1.2 Обгрунтування вибору апаратних ресурсів, мови програмування та CASE-засобів.

1.3 Розробка графіка виконання робіт по проекту у контексті обраної моделі життєвого циклу.

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

2. Розробка системної специфікації вимог до програмного забезпечення (за методом VORD).

2.1 Розробка користувальницьких вимог.

3. Розробка архітектури програмного забезпечення.

3.1 Автоматна модель ПЗ.

4. Кодування і тестування ПЗ.

4.1 Характеристика впливу особливостей мови програмування на процес кодування ПЗ.

4.2 Обгрунтування вибору методів тестування ПЗ (статичні чи динамічні аналізатори коду).

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

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

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

Висновки Література Додаток.

ВСТУП.

Поняття «інформаційна технологія» (ІТ) у сучасному контексті набуває особливої багатогранності та поширюється на всі області діяльності людини, оскільки інформація, що трансформується у дані, знання, інформаційні та програмні продукти, технологічні винаходи — є невід'ємною частиною сьогодення. Тому для ефективного вивчення ІТ-галузі необхідний усесторонній підхід, який дозволить об'єднати та узагальнити відомості ряду навчальних дисциплін, таких як «Комп'ютерні мережі та телекомунікації», «Інформаційні системи і технології» та «Сучасні Інтернет-технології». У навчальному посібнику авторами представлено нову концепцію комплексного аналізу ІТ-галузі, починаючи від базових термінів, таких як «технологія» та «інформація», до задач оптимізації створення інформаційного продукту, його захисту, технологій проектування інформаційних систем (ІС) і моделювання бізнес-процесів. Запропонований підхід орієнтований на економічну сторону ІТ та розглядає економічну інформацію, її властивості, способи формалізованого опису для класифікації та узагальнення. Проведений аналіз структури ІТ у посібнику дозволяє трактувати технологію як сукупність процесів, що використовують засоби та методи накопичення, обробки і передачі первинної інформації для отримання інформації нової якості про стан об'єкту, процесу або явища (інформаційного продукту). Створення нового інформаційного продукту, як правило, вимагає видобування знань шляхом обробки і узагальнення різнотипних даних економічного характеру, отриманих із різних джерел. Ця задача може бути вирішена з різним ступенем ефективності та великими часовими затратами, документальними способами отримання знань, такими як методи математичної статистики. Проте, ці методи не дозволяють знаходити і видобувати знання з масивів даних, а високі вимоги до кваліфікації кінцевих користувачів обмежують їх використання. Розглянуті у посібнику експертні технології видобування знань та прийняття рішень — виявлення знань в базах даних (Knowledge Discovery in Databases), технологія аналітичної обробки даних в реальному часі (OLAP), технологія аналізу сховищ даних (Data Mining), нейромережні технології штучного інтелекту та експертні системи дозволяють з більшою ефективністю отримати знання на основі аналізу прихованих закономірностей у масивах даних та прийняти оптимальне у певній ситуації рішення, використовуючи сучасні програмні засоби. Оскільки призначення ІТ полягає у виготовленні інформаційного продукту номінальної якості з оптимальними витратами, у посібнику досліджується галузь математичного моделювання бізнес-процесів та методів прийняття рішення з оптимізацією за заданим критерієм, з точки зору технологій динамічного програмування. Тенденція об'єднання комп’ютерів у мережі на сьогоднішній день набула завершеного вигляду, що втілилось у активний розвиток ІТ комп’ютерних мереж і, в тому числі, всесвітньої мережі Інтернет, а також галузі електронної комерції. У навчальному посібнику стисло викладено відомості про базові мережні технології, протоколи та сервіси, механізми пошуку, електронні платіжні системи. Окрему увагу приділено гіпертекстовій технології та технологіям створення web-вузлів — темі, що представляє особливий інтерес для творчих особистостей. Зважаючи на іншу сторону стрімкого розвитку ІТ, у посібнику неможливо було обминути гостро актуальні питання інформаційного піратства, розвинуті технології якого становлять суттєву загрозу інформаційному продукту. У посібнику розглянуто види інформаційних та програмних продуктів і можливі загрози для них в сучасному комп’ютерному середовищі. Детально досліджено питання захисту персональної інформації і протидії інформаційним та програмним продуктам шкідливого характеру, технологію забезпечення безпеки інформаційних систем, поняття ідентифікації, аутентифікації, політики безпеки тощо. Результати проведених досліджень та здійснених узагальнень щодо перетворення інформації на шляху до інформаційного продукту, необхідно враховувати і при проектуванні ІС, яка буде створювати інформаційний продукт. Для цього у навчальному посібнику проаналізовано етапи створення ІС та моделі її життєвого циклу, включно з архітектурою. Розглянуто також основні технології, що використовуються на кожному з етапів життєвого циклу ІС, для оптимізації процесів її проектування та функціонування.

1. РОЗРОБКА ПЛАНУ ПРОЕКТУ.

диспетчер проект програмний забезпечення.

1.1 Аналіз задачі, обґрунтування вибору моделі життєвого циклу для реалізації проекту.

Аналіз самої задачі, розбір її на складові частини та визначення вимог розпочинається насамперед з постановки завдання до проекту, те що від нас вимагається так би мовити в двох словах, а завдання до проекту звучить так:

Завдання проекту.

Створити програму, що допоможе диспетчеру таксі виконувати повсякденну роботу. Зберігати дані водіїв, дані автомобілів, замовлення. Передбачити внесення інформації про оплату, тариф, ефір, відсутність оплати, пільгове замовлення.

Передбачити: Додавання, видалення та перегляд інформації. Система повинна працювати під різними ОС.

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

Споживачі системи.

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

Мета проектування.

Метою проектування являється автоматизація ведення обліку замовлень на автомобільні перевезення і зменшення кількості рутинної з метою пришвидшення обслуговування клієнтів.

При проектуванні данної системи будуть використовуватись наступні терміни:

Словник термінів.

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

Диспетчер — користувач, який буде мати доступ тільки до створення та введення даних нового замовлення. Фактично, користувач, що прийматиме замовлення.

Замовлення — фактично, новий запис в таблиці Замовлення з інформацією про замовлення.

Ефір водія — фіксована сума, яку водій повинен заплатити один раз в місяць, працюючи на підприємстві.

Вибір моделі життєвого циклу ПЗ:.

Одним з ключових понять проектування інформаційних систем є життєвий цикл проекту — Project Life Cycle Management (PLCM). В загальному випадку, життєвий цикл визначається моделлю й описується у формі методології (методу). Модель або парадигма життєвого циклу визначає загальну організацію ЖЦ і, як правило, основні його фази та принципи переходу між ними. Методологія (метод) визначає комплекс робіт, їх детальний зміст і рольову відповідальність спеціалістів на всіх етапах вибраної моделі ЖЦ; рекомендує практики (best practices), які дозволяють максимально ефективно використовувати відповідну методологію та її модель.

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

Наведемо опис та особливості каскадної моделі життєвого циклу ПЗ.

Каскадна (водоспадна) модель.

Основна характеристика — cлідуючи каскадній моделі, розробник переходить від однієї стадії до іншої строго послідовно. Спочатку повністю завершується етап «визначення вимог», в результаті чого виходить список вимог до ПЗ. Після того, як вимоги повністю визначені, відбувається перехід до проектування, в ході якого створюються документи, що детально описують для програмістів спосіб і план реалізації зазначених вимог.

Після того як проектування повністю виконане, програмістами виконується реалізація отриманого проекту. На наступній стадії процесу відбувається інтеграція окремих компонентів, що розробляються різними командами програмістів. Після того як реалізація і інтеграція завершені, проводиться тестування і відладка продукту; на цій стадії усуваються всі недоліки, що з’явилися на попередніх стадіях розробки. Після цього програмний продукт впроваджується і забезпечується його підтримка — внесення нової функціональності та усунення помилок. Схема каскадної моделі ЖЦ подана на рисунку 1.1.1.

Рисунок 1.1.1 — Схема каскадної моделі ЖЦ Тим самим, каскадна модель має на увазі, що перехід від однієї фази розробки до іншої відбувається тільки після повного і успішного завершення попередньої фази, і що переходів назад або вперед або перекриття фаз — не відбувається. Кожен етап завершується випуском готового комплекту документації.

Каскадна модель виділяє такі основні етапи життєвого циклу програм:

§ Аналіз проблеми, постановка задачі і специфікація вимог до майбутньої програми. Як правило, цей етап повинен передбачати взаємодію між виконавцем та замовником. Результатом повинно бути технічне замовлення, сформульоване в письмовому вигляді.

§ Проектування. Повинен бути вибраний метод вирішення задачі та спроектований відповідний алгоритм.

§ Кодування, яке полягає в написанні тексту програми відповідно до розробленого алгоритму.

§ Відлагодження, яке полягає у виявлення та виправленні помилок.

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

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

§ Модифікація програми у випадку необхідності. Необхідність модифікації програми може бути пов’язана, наприклад, зі зміною умов її функціонування або з посиленням вимог до неї.

§ Зняття з експлуатації.

До переваг каскадної моделі належать:

— на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти і узгодженості;

— виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення всіх робіт і відповідні витрати.

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

Недоліками каскадної моделі є те, що перехід від однієї фази проекту до наступної пропонує повну коректність результату попередньої фази. Одна неточність якої небудь вимоги чи некоректна його інтерпритація в результаті приводить до того, що необхідно буде провести «відкат» до фази в проекті яка була раніше. Такі дії приводять до збільшення затрат на проект і не виключенно, до завершення проекту в формі, в якій він спочатку планувався.

Обгрунтування вибору:.

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

Оскільки всі вимоги до системи відомі нам на етапі проектування і вони будуть незмінними до його здачі, використання спіральної чи іншої ітераційної моделі є надлишковим та ресурсозатратним. Ідеальним варіантом в даному випадку є каскадна модель, тому ми її і обрали.

1.2 Обгрунтування вибору апаратних ресурсів, мови програмування та CASE-засобів.

Оскільки система буде виконувати розрахунково-зберігаючі дії: отримувати дані, опрацьовувати їх за певними алгоритмами та зберігати у постійній базі знань, а потім видавати ці дані на запит користувачів, то само собою постає питання про використання баз даних у проекті та відповідно вибору мови програмування, що дозволить легко та без особливих труднощів працювати з базами даних. В принципі на сьогоднішній день майже будь-яка мова програмування прекрасно працює з базами даних, тому можна було обрати традиційну і всіми добре знану, зарекомендовану мову С++, адже вона перевірена роками, чудово підтримує основні концепції об'єктно-орієнтованого програмування і рівень надійності програм написаних на цій мові досить високий. Проте у завданні звучало фраза, яка звужує коло мов програмування — система повинна працювати стабільно і чітко незалежно від платформи на якій вона буде запущена. Наскільки відомо, мова програмування С++ є машиннозалежною мовою, яка дуже прив’язується до платформи, і портування програм написаних на цій мові вимагають значних затрат зусиль та часу. Використання додаткових засобів та умінь. Без зміни початкового коду програми також не обійтись. Думаю, не варто говорити, що при цьому кожен раз потрібно перекомпільовувати усі модулі проекту та заново їх збирати. Який же вихід? А вихід такий: потрібно використовувати мову програмування, особливістю якої є так звана кроссплатформовість (незалежність від ОС). Однією з таких мов є мова програмування Java. Вона є більш сучасною, при цьому дуже схожою на мову С/С++. Вона увібралась в себе усі переваги мови С++ та була доповнена новими можливостями, що дозволяють крокувати в ногу з часом та новітніми технологіями. Серед основних переваг мови Java є звісно кроссплатформовість. Можливість працювати однаково на різних платформах цій мові дає змогу особливий підхід до виконання програми, а полягає він у тому, що програмний код виконує безпосередньо не процесор, а проміжна програма, що називається віртуальною машинною. При такому підході винахідникам мови доведеться адаптувати тільки віртуальну машину на різні платформи, при цьому весь код вищого рівня (прикладні програми) може залишатись незмінним. Це тільки одна з переваг мови Java, повний перелік її можливостей вказаний нижче:

1) переносимість, або кросcлатформовість;

2) об'єктна орієнтованість, створена ефективна об'єктна модель;

3) звичний синтаксис C/C++;

4) вбудована і прозора модель безпеки;

5) орієнтація на Internet-завдання, мережеві розподілені додатки;

6) динамічність, легкість розвитку і додавання нових можливостей;

7) простота освоєння.

Для зберігання даних у цьому проекті ми вирішили використати найпопулярнішу на сьогоднійшій день СУБД MySQL, до того тип цієї СУБД прекрасно працює у одній ланці з мовою Java. Переваги цієї СУБД у наступному:

· продуктивність (через що Google і Yahoo використовують саме MySQL).

· масштабованість (в компанії Omniture в реальному масштабі часу використовується 7000 серверів MySQL).

· надійність (в коді пропрієтарних продуктів міститься в десять з гаком разів більше вразливостей).

· простота використання, простота впровадження (за 15 хвилин можна скачати і запустити систему).

· відкрита і модульна розробка.

· низькі сукупні витрати (платити потрібно лише за потреби в підтримці).

В якості CASE-засобів ми вирішили обрати середовище розробки NetBeans та систему адміністрування базами даних SQL Manager for MySQL. Опис цих засобів знаходиться нижче:

NetBeans IDE — вільна інтегрована середовище розробки додатків (IDE) на мовах програмування Java, JavaFX, Python, PHP, JavaScript, C + +, Ада та ряду інших.

Основні можливості:

· Apache Ant використовується в якості машини побудови.

· Метадані проекту — це скрипти побудови Ant.

· Доступна можливість побудови додатків поза інтегрованої средис допомогою Ant, при цьому не потрібно ніякого спеціального дії (на кшталт «експорту в Ant»).

· Повністю інтегрована підтримка модульного тестування (JUnit).

· Вихідні файли показуються в контексті проекту в логічному вигляді.

· Користувач може працювати з декількома проектами одночасно.

· Все вищезазначене доступно прямо з коробки, від користувача не потрібно копатися в жодних налаштуваннях Рисунок 1.2.1 — Зображення середовища NetBeans IDE.

EMS SQL Manager for MySQL Freeware — це безкоштовний інструмент для розробки і управління базами даних MySQL, який значно спростить виконання основних адміністративних завдань. Він значно полегшить вашу роботу з сервером MySQL і зробить її більш ефективною.

Ключові особливості.

· Повна сумісність з версіями MySQL, починаючи з 3.23 по 5.6 включно.

· Підтримка даних UTF8.

· Швидка навігація та управління базами даних.

· Елементарне управління всіма об'єктами MySQL.

· Ефективні інструменти управління даними.

· Ефективне управління параметрами безпеки.

· Чудові графічні і текстові інструменти для побудови запитів.

· Вражаючі можливості імпорту та експорту даних.

· Конструктор звітів з зрозумілим майстром створення звітів.

· Потужний візуальний конструктор баз даних.

· Зручні майстри для виконання сервісів MySQL.

· Доступ до сервера MySQL по HTTP протоколу HTTP тунелю.

· Доступ до сервера MySQL по HTTP протоколу SSH тунелю Рисунок 1.2.2 — зображення EMS SQL Manager for MySQL.

1.3 Розробка графіка виконання робіт по проекту у контексті обраної моделі життєвого циклу.

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

Рисунок 1.3.1 — Діаграма Ганта.

Метод критичного шляху — це метод планування робіт в рамках проекту, включаючи управління цими роботами і складання графіку їхнього виконання. Ключовим моментом методу є поняття «критичного шляху».

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

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

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

Існуючі варіанти цього методу дозволяють вирішувати роботи, в яких фігурують імовірнісні закони розподілу тимчасових витрат і різних ресурсів, компромісні співвідношення між часом і ресурсами тощо. Найперша дата, коли робота може бути розпочата, називається датою раннього початку. Структуризація проекту. Сіткове і календарне планування проекту. Якщо до неї додати тривалість роботи, отримаємо дату її раннього завершення. Через те що виконання роботи може залежати від завершення якогось її елемента, існує остання дата, коли робота може бути завершена без затримки виконання проекту загалом. Ця дата обчислюється як сума дати пізнього початку та тривалості виконання роботи. Якщо дати пізнього та раннього початку різняться, то проміжок, коли робота може бути розпочата, називається резервом часу і визначається так:

Резерв часу = дата пізнього початку — дата раннього початку.

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

Рисунок 1.3.2 — Виконання проекту за методом критичних шляхів Рисунок 1.3.3 — Діаграма за методом критичних шляхів.

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

Загроза ризику (risk impact) — міра серйозності негативних наслідків, рівень збитків або оцінка потенційних можливостей, пов’я-заних з ризиком.

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

1. Випадки, які можуть статися.

2. Випадки, які матимуть великі наслідки, якщо вони відбудуться.

3. Випадки поза вашим контролем.

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

В залежності від джерела виникнення:.

— природно-кліматичні;

— технічні;

— виробничі;

— економічні;

— ринкові;

— фінансові;

— соціальні;

— політичні;

— інноваційні;

— регіональні;

— галузеві;

— ризики навмисних дій (вандалізм, нечесність).

В залежності від місця виникнення:.

— зовнішні;

— внутрішні.

В залежності від тяжкості проявів:.

— втрачена вигода;

— збитки;

— втрата;

— банкрутство.

За ступенем передбачуваності:.

— передбачувані з малою ймовірністю;

— непередбачувані.

Нижче сформульовані можливі ризики щодо розроблюваного нами проекту.

Таблиця 1 — Ризики за групами.

Таблиця 2 — Ризики за імовірністю прояву.

Таблиця 3 — Ризики за наслідками. Стратегії подолання ризиків.

2. РОЗРОБКА СИСТЕМНОЇ СПЕЦИФІКАЦІЇ ВИМОГ ДО ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ (ЗА МЕТОДОМ VORD).

2.1 Розробка користувальницьких вимог.

Регламентація функцій системи.

Система повинна виконувати наступні три групи функцій:

1). Группа: Функції пов’язані зі створенням бази даних.

2). Группа: Функційні вимоги до ситеми.

3). Группа: Функціональність графічного інтерфейсу користувача.

Атрибути системи:.

· Форма заповнення бази даних = за допомогою форм.

· Форма опитування = діалогова панель.

· Тип Бази Даних = MySQL.

· Тип СУБД = MySQL Manager.

· Тип ГІТ бібліотеки = Swing.

· Час запросу до БД = не більше 0,5 секунди.

· Мова програмування = Java.

· Операційна система = додаток повинен бути кроссплатформовим.

· Розмір головного вікна = приблизно ј екрану користувача.

Можливість використання в мережі = розглядається.

3. РОЗРОБКА АРХІТЕКТУРИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ.

3.1 UML-діаграми (8 видів).

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

При проектуванні вищеописаної системи були використанні такі UML-діаграми: діаграма варіантів використання, діграма слідування, діаграма класів та звісно ж концептуальна діаграма бази даних оскільки проектована програмна система буде містити базу даних (не відноситься до UML-діаграм).

3.1.1 Діаграма варіантів використання.

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

Як видно з діаграми в даній системі є тільки 4 дійових особи:

· Замовник.

· Диспетчер

· Водій TAXI.

· Адміністратор Замовник (тобто той, хто замовляє автомобільне перевезення) і водій мають доволі абстрактне значення, оскільки у використанні самої програми не будуть приймати участь, але у моделі взаємодії вони приймають безпосередню роль. Замовник — замовляє автомобільне перевезення, а — водій виконує його. Проте замовник не спілкується на пряму з водієм, а через диспетчера, який в свою чергу оформляє заявку на замовлення і створює відповідний запис у базі даних.

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

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

Рисунок 3.1.1 — Діаграма варіантів використання.

3.2.2 Діаграма класів.

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

1 — Діаграма класів.

Рисунок 3.2.2.

3.2.3 Концептуальна діаграма бази даних.

Концептуальна схема бази даних не являється UML діаграмою, але вона є невід'ємною при проектуванні програмної системи, що містить хоча б одну базу даних.

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

Рисунок 3.2.3 — Концептуальна схема бази даних.

3.2.4 Діаграма слідування.

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

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

Рисунок 3.2.4 — Діаграма слідування.

Рисунок 3.2.5 — Діаграма послідовності.

Рисунок 3.2.6 — Діаграма кооперації.

Рисунок 3.2.7 — Діаграма компонентів.

4. КОДУВАННЯ І ТЕСТУВАННЯ ПЗ.

4.1 Характеристика впливу особливостей мови програмування на процес кодування ПЗ.

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

— Зручний та інтуїтивно зрозумілий усім програмістам C-подібний синтаксис, що дозволяє швидко без зайвих проблем писати код програми, не звертаючись при цьому до якихось довідників.

— Потужній інструментарій у вигляді стандартних бібліотек коду, а також велика бібліотека контейнерів, колекцій та структур даних — Collections Framework, що дозволяють не витрачати додатковий час на їх написання та від лагодження і тестування.

— Розширенні можливості обробки виключних ситуацій, що дозволяють піднімати ступінь надійності коду. Обробка помилок та виключних ситуацій на «льоту» дозволяє без аварійного завершення програми обробити помилку та продовжувати виконання програми. Таким чином, це також дозволяє економити час при розробці програми.

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

— Набір стандартних класів для роботи з базами даних, окрем і з сервером баз даних MySQL.

— Разом з мовою Java компанія Oracle розробляє дуже зручні і хороші CASE-засоби у вигляді інтегрованого середовища розробки NetBeans. Що значно полегшує життя розробникам. Серед переваг середовища NetBeans є:

— Підсвітка коду.

— Виділення ключових слів.

— Підстановка та автогенерація коду.

— Інтеграція з системою контролю за версіями SVN.

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

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

4.2 Обгрунтування вибору методів тестування ПЗ (статичні чи динамічні аналізатори коду).

Як відомо, динамічний аналіз на практиці не може покрити всі розгалуження програми. Навіть хороші тести покривають не більше 80% програмного коду.

Щоб регулярно перевіряти проекти динамічними методами, необхідно створити спеціальну інфраструктуру. Потрібні спеціальні тести, паралельний запуск декількох екземплярів додатків з різними вхідними даними.

Оскільки динамічний аналіз проводиться на виконуваній програмі і зазвичай тестує графічні інтерфейси користувача, то динамічні аналізатори є дуже залежними від ПЗ, яке вони мають тестувати. Універсальний вже готових засобів для повноцінного тестування будь-якого ПЗ наперед не існує. Є лише деякі динамічні аналізатори, які дозволяють проводити тестування загального призначення, але такі аналізатори не підійдуть для тестування нашого ПЗ, альтернативою є розробка власних тесту вальних утиліт для побудови динамічних тестів, але часові ресурси не дозволяють нам писати власний динамічний аналізатор, тому для нашого проекту динамічні тести будуть замінені тестуванням людьми. Готова та запущена програма буде віддана на тестування двом користувачам і по закінченню тестування вони сповістять про всі недоліки, які замість них мали виявити динамічні аналізатори.

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

Для проведеня статичного аналізу нашого проекту ми вирішили використовувати пакет SciTools Understand.

Отже пакет володіє наступними перевагами:

— Гнучке та надійне стандартне статичне тестування.

— Наявність вже вбудованого редактора коду для виправлення вже знайдених помилок.

— Підтримка багатьох різноманітних та несхожих мов програмування (C/C++, C#, Fortran, Pascal, Ada, Java, Objective C, PHP, Python, Ruby інші).

— Визначення метрик ПЗ.

— Побудова графіків та представлення інформації в графічному вигляді (в тому числі і метрик).

— Побудова діаграм залежностей.

— Автоматична генерація звітів.

— Швидкий пошук по коду.

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

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

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

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

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

Окрім трьох вищеописаних груп програмне забезпечення тестувалось ще на відповідність конвенції іменування ідентифікаторів мови 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 — Опис основних метричних показників розробленого ПЗ.

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

Рисунок 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.5.1 — Вікно авторизації у системі.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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