Репозиторій ЧДТУ
Репозиторій ЧДТУ зберігає і дозволяє легкий і відкритий доступ до всіх видів цифрового контенту, включаючи текст, зображення, анімовані зображення, MPEG і набори даних
Дізнатися більше
Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/6911| Назва: | Веб-сервіс відстеження багів в реальному часі |
| Автори: | Карапетян , Анаіт Радіківна Сивоглаз, Дмитро Валерійович |
| Ключові слова: | веб-сервіс;відстеження;баг;Bugno;програмне забезпечення |
| Дата публікації: | 17-чер-2021 |
| Короткий огляд (реферат): | Ні для кого не секрет, що системи інформаційного забезпечення зайшли у всі сфери нашого життя. Якщо 20-30-40 років тому, написання програм відбувалося під конкретну задачу одним з фахівців, які знали одну мову програмування на підприємстві та все рушилося з процесом звільнення даного фахівця, то на сьогодні написання програмного забезпечення є основною роботою цілих ІТ компаній, що дорожать своєю репутацією та створюють модульне програмне забезпечення. Тому постає питання в правильності написання коду програми. Особливо потребують підтримки молоді початківці. Помилка, що закралася в код програми, несе грошові та репутаційні збитки. Тому питання перевірки коду на відловлення можливих багiв є актуальним. Багато компаній знаходять, що інтегрована система відстеження помилок зменшує час простою, збільшує продуктивність і підвищує задоволеність клієнта від роботи з їх системами. Разом з повним розкриттям інформації, відкрита система відстеження помилок дозволяє виробникам програмного забезпечення підтримувати контакт зі своїми клієнтами і реселерами, для передачі повідомлень про помилки по всьому ланцюгу управління даними. Багато корпорацій також виявляють, що відстеження помилок зменшує витрати, забезпечуючи службі підтримки IT систему обліку, телефонній підтримці – бази знань, а всім - добре зрозумілу систему для обліку проблем з програмним забезпеченням. Існує багато систем відстежування помилок у досить широкому діапазоні функціональності і вартості. Як критерій вибору відповідної системи для конкретної розробки можна вибрати оцінку надійності програмної системи, що розробляється, керуючись її мірою складності по Холстеду [1]. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/6911 |
| Розташовується у зібраннях: | 126 Інформаційні системи та технології (Web-технології, web-дизайн) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| РЕП_БАК_Сивоглаз_WebC-1911.pdf Restricted Access | 3.31 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ ПРОЕКТУВАННЯ
Пояснювальна записка
до кваліфікаційної роботи бакалавра
на тему:
«Веб-сервіс відстеження багів в реальному часі»
Виконав студент 4 курсу,
групи WebC-1911,
спеціальності 126 –
Інформаційні системи та
технології,
освітня програма – Web-
технології, Web-дизайн,
Сивоглаз Д.В.
Керівник к.т.н., доцент Карапетян А.Р.
Рецензент к.т.н., доцент, підполковник
служби цивільного захисту,
заступник начальника
факультету цивільного захисту та
управління, Черкаський інститут
пожежної безпеки імені Героїв
Чорнобиля Національного
університету цивільного захисту
України Землянський О.М.
Черкаси – 2021 року
ВСТУП
3
Ні для кого не секрет, що системи інформаційного забезпечення зайшли
у всі сфери нашого життя. Якщо 20-30-40 років тому, написання програм
відбувалося під конкретну задачу одним з фахівців, які знали одну мову
програмування на підприємстві та все рушилося з процесом звільнення даного
фахівця, то на сьогодні написання програмного забезпечення є основною
роботою цілих ІТ компаній, що дорожать своєю репутацією та створюють
модульне програмне забезпечення. Тому постає питання в правильності
написання коду програми. Особливо потребують підтримки молоді
початківці. Помилка, що закралася в код програми, несе грошові та
репутаційні збитки. Тому питання перевірки коду на відловлення можливих
багiв є актуальним.
Багато компаній знаходять, що інтегрована система відстеження
помилок зменшує час простою, збільшує продуктивність і підвищує
задоволеність клієнта від роботи з їх системами. Разом з повним розкриттям
інформації, відкрита система відстеження помилок дозволяє виробникам
програмного забезпечення підтримувати контакт зі своїми клієнтами і
реселерами, для передачі повідомлень про помилки по всьому ланцюгу
управління даними. Багато корпорацій також виявляють, що відстеження
помилок зменшує витрати, забезпечуючи службі підтримки IT систему обліку,
телефонній підтримці – бази знань, а всім - добре зрозумілу систему для обліку
проблем з програмним забезпеченням.
Існує багато систем відстежування помилок у досить широкому
діапазоні функціональності і вартості. Як критерій вибору відповідної системи
для конкретної розробки можна вибрати оцінку надійності програмної
системи, що розробляється, керуючись її мірою складності по Холстеду [1].
Метою кваліфікаційної роботи бакалавра є створення web-сервісу
відстеження багів в реальному часі. Програмна реалізація Bugno передбачає
створення сайту, на якому користувач може перевірити програмний код.
Планується створити програмне забезпечення для відстеження багiв в
реальному часі, яке автоматизує моніторинг та виявлення помилок у різних
4
середовищах, завдяки чому розробники можуть знаходити та виправляти
помилки, які мають значення, за лічені хвилини, на відміну від очікування
відгуку користувачів або звітів про помилки команди контролю якості.
Це допоможе швидко і безболісно створювати програмне забезпечення,
та безкоштовно і має відкритий код. Bugno буде мати інтерфейс дошки в стилі
канбан, щоб користувач міг спостерігати за всім від загальної картини до
найдрібніших деталей.
Задачі, що необхідно вирішити для досягнення поставленої мети:
1) розглянути існуючі аналоги на ринку послуг перевірки
програмного забезпечення;
2) розглянути основні принципи та методи тестування програмного
забезпечення;
3) виконати проектування web-сервіс відстеження багів в реальному
часі;
4) описати процес програмної реалізації створюваного сервісу.
5
РОЗДІЛ 1. ОГЛЯД ІСНУЮЧИХ АНАЛОГІВ ТА РІШЕНЬ.
Якщо розглядати сервіси для удосконалення програмного коду, то їх
можна поділити на прості, та складні. Прості сервіси передбачають
відшукання помилок, та вивід повідомлення про них. Складні сервіси
передбачають роботу команди програмістів, тестувальників та менеджерів над
проектом.
Якщо розглядати принцип перевірки програмного забезпечення, то його
можна зобразити у вигляді рисунку 1.1.
Рисунок 1.1 – Система відстеження помилок
На рисунку 1.1 зображено систему відстеження помилок, яка містить в
собі депозитарій системи відстеження помилок та депозитарій контролю
версій. Як ми бачимо, доцільно підключати мережу та розміщувати дану
систему на сервері для максимально наближеного доступу.
Розглянемо декілька існуючих систем, що дозволяють вирішувати схожі
задачі.
1.1 Система відстеження помилок Bugzilla
Bugzilla – застосування для відстеження помилок, розроблене компанією
Mozilla [2] . Фактично, Bugzilla використовується в багатьох корпораціях для
розробки власного програмного забезпечення для корпоративних потреб. За
6
минулий час Bugzilla став зрілим продуктом, що по праву гордиться
розвиненою функціональністю, куди, зокрема, входять:
інтегрована система безпеки з можливістю визначення безпеки на рівні
продуктів;
система залежностей помилок і виведення залежностей помилок в
графічному вигляді;
розвинена система складання звітів;
стабільний, перевірений часом back-end на основі RDBMS;
розвинена система конфігурації;
дуже зрозумілий і добре продуманий протокол виправлення помилок;
API для електронної пошти, XML, HTTP і консолі;
доступна інтеграція з системами управління автоматичної конфігурації
програмного забезпечення, зокрема Perforce and CVS (через інтерфейс
електронної пошти Bugzilla і скрипти для checkin/checkout) [2].
На рисунку 1.2 наведено інтерфейс системи Bugzilla.
Рисунок 1.2 – Інтерфейс системи Bugzilla для відловлювання багів
7
Система передбачає налаштування файлу, що завантажується.
Користувач налаштовує систему та може бачити зміни помилок протягом
життєвого циклу роботи системи. Налаштування представлено у вигляді
гіперпосилань, які можна редагувати. Після редагування дані будуть збережені
при натисканні відповідної кнопки у верхньому правому куті.
Дана програма працює з 1998 року та є відкритим програмним
продуктом. Дозволяє знаходити помилки як в проекті в цілому, так і в
програмному коді.
1.2 Система управління проектами Trac
Trac – це система управляння проектами, яка дозволяє організувати
робочий час та задокументувати проект, що був створений [3].
Основою даної системи є існування репозитарію (рисунок 1.3).
Рисунок 1.3 – Схема існування системи управляння проектами Trac
Якщо запустити Trac без Apache то система працюватиме як standalone
сервер. Також, до системи можливе підключення блоку автентифікації даних.
Основними функціями системи є:
1) Управління проектом та розділення його на етапи. Контроль за
виконанням проекту та відстеження робіт у часі.
8
2) Можливість залишення коментарів та врахування помилок, які
були знайдені.
3) Перегляд репозитарію дозволяє переглядати код з врахування
проведених перевірок та також внесених змін.
4) Розширення функціональних можливостей за рахунок
підключення додаткових модулів.
5) У Trac вбудована система WiKi з можливістю робити посилання
на milestone, roadmap, ticket.
Дана система буде корисна для всіх хто використовує Subversion.
Якщо говорити про студентів, то вони зможуть ознайомитися з
системою управління проектами, виконати деякі тренувальні вправи перед
співбесідами в ІТ компаніях та організовувати власний часовий простір.
Для фрилансирів допомагає уникнути помилок та задокументувати ідеї
та ToDo.
1.3 Відкритий серверний веб-додаток для управління проектами і
задачами Redmine.
Redmine - це гнучка веб-програма для управління проектами. Написаний
із використанням фреймворку Ruby on Rails, він є міжплатформенним та
міжбазовим [4].
Redmine є відкритим кодом і випущений на умовах Загальної публічної
ліцензії GNU v2 (GPL).
Основними перевагами Redmine є:
1) Підтримка декількох проектів.
2) Гнучкий контроль доступу на основі ролей.
3) Гнучка система відстеження проблем.
4) Діаграма Ганта та календар.
5) Управління новинами, документами та файлами.
6) Стрічки та сповіщення електронною поштою.
7) За вікі проекту.
9
8) За форумами проектів.
9) Відстеження часу.
10) Спеціальні поля для видань, записів часу, проектів та
користувачів.
11) Інтеграція SCM (SVN, CVS, Git, Mercurial та Bazaar).
12) Створення випуску електронною поштою.
13) Підтримка множинної автентифікації LDAP.
14) Підтримка самореєстрації користувачів.
15) Підтримка багатомовності
16) Підтримка декількох баз даних.
17) Докладніше про функції Redmine.
Спільну онлайн-демонстрацію можна знайти за адресою
http://demo.redmine.org/. Це було налаштовано, щоб дати зареєстрованим
користувачам можливість створювати власні проекти. Це означає, що після
реєстрації ви можете створити там власний проект і випробувати функції
адміністрування проекту.
Отримати власне демонстраційне середовище Redmine за адресою
http://m.redmine.org із повними правами адміністратора після заповнення
простої форми.
За результатами розглянутих аналогів побудуємо Таблицю 1.1 за
критеріями вибору систем відстеження помилок.
Таблиця 1.1 Критерії вибору систем відстеження помилок
Критерій Bugzilla Trac Redmine
Ліцензія Mozilla Public BSD variant GPL v.2
License
Мова реалізації Perl Python Ruby on Rails
Інтерфейс Web-email, RSS, Web Web, E-mail,
користувача Web service, Atom
commandline
Інтеграція з CVS, Subversion, Subversion, Darcs, Subversion, CVS,
системами Perforce, Bazaar, Mercurial, Bazaar, Darcs,
управління AccuRev Perforce, Git Mercurial, Git
10
Критерій Bugzilla Trac Redmine
Інтеграція або Інтегровані звіти Інтегрована wiki Інтегрована wiki,
генерація і діаграми, дискусійні
динамічної планування форуми, новинні
документації розкладу звітів блоги, email
інтеграція,
календарі
Інтеграція з Testopia – –
плануванням
тестів
Workflow, що Так Так Так
настроюється
Підтримка Так Так Так
юнікода
LDAP Так – Так
авторизація
Слід відмітити, що функціональність даних систем можна розширити за
рахунок окремих плагинів. Так як системи є з відкритим кодом, то необхідну
функціональність для конкретної роботи, можна самостійно додавати.
Щодо функціоналу відстеження помилок, то систему можна
налаштовувати на відсоткове допущення або недопущення кількості
помилкових рядків.
Тобто функціонал лише відстеження помилок у коді є недоцільним.
Необхідно створювати систему як відстеження помилок так і управління
проектом в цілому. Тому було прийнято рішення створення web-сервісу
відстеження багів в реальному часі у форматі дошки кабан.
1.4 Математичні моделі оцінювання надійності програмного забезпечення
Надійність програмного забезпечення - здатність програмного продукту
безвідмовно виконувати певні функції при заданих умовах протягом заданого
періоду часу з досить великою ймовірністю.
Ступінь надійності характеризується ймовірністю роботи програмного
продукту без відмови протягом певного періоду часу.
Існує чотири основні складові функціональної надійності програмних систем:
11
a) безвідмовність - властивість програми виконувати свої функції під
час експлуатації;
b) працездатність - властивість програми коректно (так як очікує
користувач) працювати весь заданий період експлуатації;
c) безпека - властивість програми бути не небезпечною для людей і
оточуючих систем;
d) захищеність - властивість програми протистояти випадковим або
навмисним вторгненням в неї.
На рисунку 1.4 наведено модель аналізу надійності програмних засобів.
Дестабілізуючі Методи Наслідки
фактори та попередження порушення
Об’єкти загрози помилок надійності
вразливості
надійності надійності Руйнування
Процес Внутрішні Попередження в обчислювальног
обчислення процесі о процесу
Помилка
проектування
Інформація БД проектування при Руйнування
постановці задач Системне інформації БД
Об’єктний код тестування
програми Помилки Руйнування
Обов’язкова програмного
Інформація для алгоритмізації
задач сертифікація коду
користувачів
Помилки Руйнування
програмування Оперативні інформації для
задач методи забезпечення
Недостатня підвищення діяльності
кількість засобів надійності
захисту Часові
Зовнішні надмірності
Помилки Інформаційні
персоналу надмірності
Спотворення Програмні
інформації в надмірності
каналах зв’язку
Рисунок 1.4 – Модель аналізу надійності програмних засобів.
12
До числа основних факторів, що впливають на надійність ПЗ віднесено:
взаємодія ПЗ з зовнішнім середовищем (програмно-апаратна
засоби, транслятори, ОС). Цей фактор вносить найменший внесок
в надійність ПЗ при сучасному рівні надійності апаратури, ОС і
компіляторів;
взаємодія з людиною (розробником та користувачем)
організація ПО (проектування, постановка задачі та способи їх
досягнення і реалізації) і якість його розробки. Цей фактор вносить
найбільший вклад в надійність;
тестування.
У боротьбі зі складністю ПО використовуються дві концепції:
a) Ієрархічна структура. Ієрархія дозволяє розбити систему за
рівнями розуміння (абстракції, управління). Концепція рівнів
дозволяє аналізувати систему, приховуючи несуттєві для даного
рівня деталі реалізації інших рівнів. Ієрархія дозволяє розуміти,
проектувати і описувати складні системи.
b) Незалежність. Відповідно до цієї концепції, для мінімізації
складності, необхідно максимально посилити незалежність
елементів системи. Це означає таку декомпозицію системи, щоб її
високочастотна динаміка була укладена в окремих компонентах, а
міжкомпонентні взаємодії (зв'язку) описували тільки
низькочастотну динаміку системи.
Методи виявлення помилок, які базуються на введенні в ПО системи
різних видів надмірності:
a) Тимчасова надмірність. Використання частини продуктивності
ЕОМ для контролю виконання та відновлення працездатності ПЗ
після збою.
13
b) Інформаційна надмірність. Дублювання частини даних
інформаційної системи для забезпечення надійності та контролю
достовірності даних.
c) Програмна надмірність включає в себе: взаємна недовіра -
компоненти системи проектуються, виходячи з припущення, що
інші компоненти і вихідні дані містять помилки, і повинні
намагатися їх виявити; негайне виявлення і реєстрацію помилок;
виконання однакових функцій різними модулями системи і
зіставлення результатів обробки; контроль і відновлення даних з
використанням інших видів надмірності.
Завдання забезпечення ПО стійкості до помилок спрямовані на
застосування методів мінімізації збитку, викликаного появою помилок, і
включають в себе:
обробку збоїв апаратури;
повторне виконання операцій;
динамічна зміна конфігурації;
скорочене обслуговування у випадку відмови окремих функцій
системи;
копіювання і відновлення даних;
ізоляцію помилок.
Дається 4 групи принципів забезпечення надійності:
попередження помилок;
виявлення помилок;
виправлення помилок;
забезпечення стійкості до помилок.
Дії, спрямовані на мінімізацію помилок і збоїв:
запобігання помилок за рахунок структурного програмування;
14
приховування інформації або дозований доступ до даних з боку
програмних засобів і об'єктів в об'єктно-орієнтованому
програмуванні;
налагодження;
стійкість до збоїв;
обробка виняткових ситуацій (перехоплення помилок, наприклад,
розподіл на нуль) і локалізація помилок і збоїв;
відновлення програми після збою.
Рішення, яке дозволить оцінити надійність будь-якого програмного
забезпечення з певною точністю поки не існує. Але розглянемо декілька
моделей, що дозволять підвести певні підсумки існуючих практик.
Особливістю є ефективність даних моделей у різних сферах написання
програмного забезпечення.
Наприклад, у моделі Джелінського-Моранді дані моделі
використовуються для оцінки очікуваної кількості відмов на інтервалі часу
тестування.
Дана модель відповідає наступним положенням:
1) Інтенсивність виявлення помилок ��(��) пропорційна поточній
кількості помилок в програмі, тобто початковій кількості помилок
за виключенням помилок, які вже виявлені на даний момент.
2) Всі помилки в програмі мають однакову ймовірність та не
впливають одна на одну.
3) Всі помилки важливі в рівній мірі.
4) В процесі виявлення помилок, нові помилки не з’являються.
5) Інтенсивність помилок залишається сталою на проміжку між будь-
якими двома суміжними моментами виявлення помилок.
На рисунку 1.5 наведено схему визначення моделей надійності програмного
забезпечення, що визначають час для удосконалення програм в процесі
тестування.
15
Рисунок 1.5 – Класифікація моделей надійності програмного забезпечення
За моделями, в основу яких покладено підрахунок відмов (у динамічних
моделях), роблять припущення, що концептуально в програмі наявна
скінчення кількість помилок.
Моделі підрахунку відмов використовують інтенсивність відмов, що є
основною характеристикою появи відмови. Інтенсивність кожної помилки є
або сталою функцією часу відлагодження або випадковою змінною із заданим
законом розподілу. Якщо інтенсивність відмов, пов’язується з помилками
16
певного типу, то їх інтенсивність обчислюють як добуток кількості помилок,
що залишилися в програмі, на інтенсивність відмов, які визвані даною
помилкою. Під час тестування на етапі відлагодження відбувається зміна
кількості помилок. Моделювання процесу відмов відбувається у процесі
представлення стохастичного процесу.
Програмне забезпечення, що містить помилки, несе ризики, що пов’язані
з відмовами. Необхідно розуміти момент зупинки процесу відлагодження
програмного забезпечення.
Під час тестування системи показник надійності є важливим критерієм
під час прийняття рішення про зупинку процесу відлагодження програмного
забезпечення. Частота відмов, вимоги до надійності та загальна вартість
системи визначають оптимальний час тестування програмного забезпечення.
Одним із критеріїв забезпечення надійності є оцінювання на основі
неоднорідного процесу Пуассона.
Процес відлагодження розглядають як визначену цільову функцію.
Параметри моделі оцінюють з використанням методу регресії.
Щоб краще описати поведінку надійності програмного забезпечення
використовують моделі надійності з використанням функцій зусиль
тестування.
Дані функції розраховуються в затрачених людино-годинах роботи над
процесом удосконалення програмного забезпечення.
Існують моделі як ідеального так і неідеального відлагодження програмного
забезпечення.
Моделі надійності у сучасному світі не дають адекватних результатів та
вимагають додаткових затрат. Тому, перестають бути достовірними, а отже
використовуваними.
1.5 Поняття web-сервісу
Веб-сервіс (англ. web service) – це програмна система, що ідентифікується веб-
адресою та має стандартизований інтерфейс. Веб-служби взаємодіють одна з
17
одною та сторонніми додатками засобами сповіщень, що діють на основі
певних протоколів. Веб- сервіси надають певні послуги в інтернеті.
Розглянемо деякі протоколи, які можуть використовуватися веб-сервісом.
Досить часто використовують FTP протокол передачі файлів. Він є
стандартним протоколом, що призначений для передачі файлів в мережі
інтернет. Його також можна використовувати для завантаження мережевих
сторінок та інших документів з приватного пристрою розробки на відкриття
сервера хостингу.
Можливе застосування мережевого протоколу SSH. Це є мережевий
протокол прикладного рівня, що дозволяє управляти операційною системою
на віддаленому рівні та створювати тунелювання TCP-з’єднань для кращої
передачі файлів. Даний протокол шифрує весь трафік раз з паролями, що
передаються. Протокол допускає різні алгоритми шифрування, а SSH-клієнти
та SSH-сервери є доступними для більшості існуючих операційних систем.
NNTP (англ. Network News Transfer Protocol) - є мережевим протоколом,
поширення, запиту, розміщення і отримання груп новин при взаємодії між
сервером груп новин і клієнтом [20] .
SNMP (англ. Simple Network Management Protocol - простий протокол
мережевого управління) - стандартний інтернет-протокол для управління
пристроями в IP-мережах на основі архітектур UDP/TCP. До підтримуючих
SNMP пристроїв відносяться маршрутизатори, комутатори, сервери, робочі
станції, принтери, модемні стійки і інші. Протокол зазвичай використовується
в системах мережного управління для контролю підключених до мережі
пристроїв на предмет умов, які вимагають уваги адміністратора. SNMP
визначено Інженерним радою інтернету (IETF) як компонент TCP/IP. Він
складається з набору стандартів для мережевого управління, включаючи
протокол прикладного рівня, схему баз даних і набір об'єктів даних [20].
LDAP (англ. Lightweight Directory Access Protocol - «полегшений протокол
доступу до каталогів») - протокол прикладного рівня для доступу до служби
18
каталогів X.500, розроблений IETF як полегшений варіант розробленого ITU-
T протоколу DAP. LDAP - відносно простий протокол, який використовує
TCP/IP і дозволяє проводити операції авторизації (bind), пошуку (search) і
порівняння (compare), а також операції додавання, зміни або видалення записів
[20].
SSL (англ. Secure Sockets Layer - рівень захищених сокетів) - криптографічний
протокол, який забезпечує встановлення безпечного з'єднання між клієнтом і
сервером. SSL спочатку розроблений компанією Netscape Communications.
Згодом на підставі протоколу SSL 3.0 був розроблений і прийнятий стандарт
RFC, що отримав ім'я TLS [20].
MySQL - вільна система управління базами даних. Розробка та підтримка
сайта MySQL здійснює корпорація Oracle, яка отримала права на торговельну
марку разом з поглиненої Sun Microsystems, яка раніше придбала шведську
компанію MySQL AB. Продукт поширюється як під GNU General Public
License, так і під власною комерційною ліцензією. Крім цього розробники
створюють функціональність за замовленням ліцензійних користувачів, саме
завдяки такому замовленню майже в найраніших версіях з'явився механізм
реплікації [20].
Virtual Network Computing (VNC) - система віддаленого доступу до робочого
столу комп'ютера, що використовує протокол RFB (англ. Remote FrameBuffer,
віддалений кадровий буфер). Управління здійснюється шляхом передачі
натискань клавіш на клавіатурі і рухів миші з одного комп'ютера на інший і
ретрансляції вмісту екрану через комп'ютерну мережу [20].
Веб-сайт — це сукупність логічно зв'язаної гіпертекстової інформації,
оформленої у вигляді окремих сторінок і доступної в мережі Інтернет [21].
Подібне визначення веб-сайту було правильним на початку існування
Інтернету, коли Мережа і веб-сайти використовувалися в основному як
розважальна система. До кінця 90-х років веб-сайти дійсно були в основному
статичними сторінками. Для створення веб-сайту було потрібне лише знання
19
мови гіпертекстової розмітки — HTML. Якщо ж сторінка надавала якісь
програмні засоби — це були виключно засоби, що міг надати сервер, на якому
розташований веб-сайт. Про зручність і красу тогочасних веб-сайтів взагалі
особливо не доводилося говорити. Час спливає, розвиваються мови
програмування, розширюються канали передачі інформації.
Зараз Інтернет вже є самодостатньою галуззю економіки, а веб-сайти стали
повноправними представництвами фірм в Інтернеті. Сьогодні мільйони людей
вранці встають і йдуть на роботу в Інтернет. Їх офісами є веб-сайти [21].
Веб-сайт — це сукупність програмних, інформаційних, а також медійних
засобів, логічно пов'язаних між собою. По суті ж веб-сайт — це віддзеркалення
успішності фірми, її обличчя [21].
Веб-сайт виконує такі основні завдання:
a) реклама продукції, послуг, ідей. Правильно зроблений веб-сайт із
легкістю приведе клієнта до висновку про необхідність покупки товару,
або послуг, або ідей, що пропагуються на ньому;
b) продаж товарів, послуг, інформації, ідей. У сучасної людини немає
багато часу для ходіння по магазинах. Тому можливість замовлення
товарів і послуг, не відходячи від комп'ютера, значно розширює
можливості і клієнта, і продавця;
c) безкоштовне надання інформації або послуг. Насправді надання
інформації або послуг — це засіб залучення відвідувачів до даного
ресурсу для здобуття, наприклад, статистичної інформації або ж для
показу реклами, якщо це рекламний майданчик;
d) підтримка клієнтів [21].
Веб-сайти поділяються за видами у відповідності до робіт, для яких вони були
створені. Розглянемо основні різновиди веб-сайтів.
1) Рекламні веб-сайти.
Веб-сайти можуть створюватися виключно в рекламно-промоутерських цілях.
Такі сайти безпосередньо не займаються продажем, їх завдання полягає в
20
донесенні до цільової аудиторії рекламної інформації, і створюються вони з
розрахунку на певне коло товарів або послуг. Зазвичай такі сайти виконуються
з використанням великої кількості графіки, flash-анімації. Для залучення
клієнтів на сайт використовують ігрові й розважальні методи [21].
2) Веб-сайти-продавці.
Для таких сайтів характерна наявність описового рекламного матеріалу для
товарів або послуг, каталог даних товарів або послуг, інформації про фірму-
продавця, а також контактна інформація. Додаткові сервіси, такі, як корисна
інформація, зручність замовлення через сайт у поєднанні із грамотною
розкруткою, можуть зробити веб-сайт привабливим для сторонніх
рекламодавців [21].
3) Веб-сайти-"альтруїсти"
Інформаційні веб-сайти, або сайти, які надають деякі безкоштовні сервіси, теж
потрібно обслуговувати, розвивати, а отже, вкладати в них кошти. Але
проекти, які не приносять прибуток, довго не живуть, тому для таких веб-
сайтів характерне заробляння грошей або на рекламі, або на зборі
статистичних даних. На таких сайтах дуже часто пропонують зареєструватися,
аби отримати маленький додатковий сервіс. І що в результаті про нас
дізнаються подібні веб-сайти? Все: від нашого браузера й роздільна здатність
екрану до місця роботи й рахунку в банку. Якщо ж ви не реєструєтеся на сайті,
то все одно можна взнати ваші смаки, психологічний портрет, приблизний вік,
ну й, нарешті, вам можна показати багато реклами [21].
4) Веб-сайти для підтримки
Останній тип веб-сайтів — це підтримка клієнтів. Зазвичай на таких сайтах
розміщують оновлення для програмних продуктів, новини; якщо йдеться про
сайт банку, це може бути система управління засобами клієнта.
Ці інтернет-ресурси є рекламою фірми, товару та ін [21].
5) Веб-сайт — офіс із безліччю відділів.
21
У загальному випадку для успішної роботи сайту необхідно, аби він виконував
декілька завдань одночасно. Уявіть, що ваш сайт — це офіс, у якому в одному
відділі сидять менеджери, які дають безкоштовні консультації, у другому —
маркетологи, у третьому — менеджери, які виставляють рахунки. Причому всі
ці відділи між собою успішно взаємодіють. Ще дуже важливо, аби у ваш
віртуальний офіс було легко потрапити. Для цього необхідні ефективна
реклама й адреса, яка легко запам'ятовується [21].
Висновок до розділу 1
В даному розділі розглянуті існуючі рішення створених систем
перевірки багів та управління проектами від ведучих фірм ІТ бізнесу.
Прийнято рішення створювати власний програмний продукт у форматі дошки-
кабан.
Виконано огляд моделей надійності програмного забезпечення та
наведено їх класифікацію. Наведено основні поняття, що стосуються веб-
сервісу та веб-сайту.
22
РОЗДІЛ 2. ПРОЕКТУВАННЯ WEB-СЕРВІСУ ВІДСТЕЖЕННЯ БАГІВ В
РЕАЛЬНОМУ ЧАСІ
Крім веб-додатків іншим важливим видом програмного забезпечення,
використовуваного в web-мережі, є web-сервіси (web services). Вони є набором
методів, які можна викликати на виконання із заданими параметрами за
допомогою НТТР- запитів, а результати їх виконання отримувати у вигляді
НТТР-відповідей [22].
Web-сервіси підтримуються, як і web-додатки, web-серверами і
призначені для використання будь-якими програмами, які можуть формувати
правильні HTTP-запити і розуміти отримані НТТР- відповіді, але не
користувачами (людьми). Вони не мають графічного призначеного для
користувача інтерфейсу. Такими програмами можуть бути web- додатки, інші
web-сервіси або навіть локальні програми [22].
Web-сервіси, так само як і web-додатки, повністю реалізуються з
використанням технологій і стандартів web-мережі. Вони мають URL-адреси,
за допомогою яких до них можна звертатися. Для передачі запиту на
виконання методів web-сервісів і повернення результатів використовується
мова XML. На рисунку 2.1 показана загальна схема взаємодії web-додатки з
web-сервісом.
Рисунок 2.1 - Загальна схема взаємодії web-додатки з web-сервісом [22]
23
Робота web-сервісів грунтується на використанні даних, описаних на
мові XML. Такі XML-дані повинні складатися відповідно до протоколу - SOAP
(Simple Object Access Protocol), який надає стандартний спосіб опису
повідомлень в XML-форматі. Він дозволяє розробникам описувати, що може
виконати сервіс, і робить надану функціональність доступною іншим
програмам [22].
Прикладом простого web-сервісу може бути сервіс Math, який включає
дві операції: додавання (Add) і віднімання (Subtract):
������������ �������� �������������������������� ������ (���� �������� ����, (������������ �� ��, ,������������ ������)�� { ����)�� ��{���� ��=�� �� �� ��+; ������;��}��; ���� ��; }.
XML-дані, сформовані відповідно до протоколу SOAP в якості
кореневого елемента, використовують елемент "Envelope", в який включені
два піделементи - "Header» (не обов'язковий) та "Body". В елементі "Header"
описується загальна інформація, пов'язана із запитом або відповіддю. А
елемент "Body" в запиті містить інформацію про викликається метод
(наприклад: Subtract) і переданих йому параметрах (х і у). Складений таким
чином XML-документ передається за допомогою протоколів HTTP або SMTP
[22].
Рисунок 2.2 - Приклад HTTP-запиту до веб-cepвіcy з використанням
SOAP [22]
24
При використанні протоколу HTTP даний XML-документ (Envelope)
включається в тіло HTTP-запиту, яке слід через порожній рядок після рядка
запиту (наприклад, POST / services НТТР / 1.1) та відповідних заголовків, як
показано на рисунку 2.2 – 2.3.
Рисунок 2.3 - Приклад HTTP-відповіді від web-cepвuca з використанням
SOAP [22]
Рисунок 2.4 - Фрагмент WSDL-описі web-cepвuca Math
25
Після отримання даного запиту web-сервер передає управління
середовищі виконання, яка викликає необхідний метод і передає йому
отримані параметри. Після виконання даного методу формується XML-
документ, що містить результати роботи методу, який оформляється
відповідно до протоколу SOAP.
На рисунку 2.4 показаний HTTP-відповідь, що містить результати
виконання web-сервісу (Subtract), який виконує віднімання значень перших
двох параметрів і повертає результат в третьому параметрі. Так як ці дані
передаються в HTTP-відповіді, то вони включаються після рядка стану і
відповідних заголовків [22].
Для того щоб користувачі сервісів (наприклад, web- додатки) могли
правильно складати запити і розуміти відповіді, web-сервіси також є
відповідальними за надання спеціальних описів, складених на мові WSDL
(Web Services Definition Language), який також використовує XML-формат.
Мова WSDL дозволяє розробникам описувати синтаксис виклику web-методів
сервісу. За допомогою WSDL можна описати різні елементи web- сервісу,
наприклад, такі, як типи даних (<wsdl: types>), повідомлення (<wsdl:
message>), типи портів (<wsdl: port>), зв'язування (<wsdl: binding>) і сам сервіс
(<wsdl: service>) [22].
Для отримання WSDL-документа з описом web-сервісу потрібно
відправити йому HTTP-запит <URL-адресу сервісу>? WSDL. В такому WSDL-
документі описується все, що клієнту необхідно для організації роботи з web-
сервісом [22].
Підходи по розробці веб-додатків поділяються на три категорії:
1) Підходи, засновані на програмуванні або скриптах: зовнішні програми
або скрипти; розширення web-сервсра.
2) Підходи, засновані на використанні шаблонів web-сторінок, що
включають вставки коду скриптів і спеціальних серверних тегів.
3) Об'єктні середовища (каркаси, фреймверкі, frameworks).
26
Дані категорії перетинаються між собою (а також різні думки про те, до
якої категорії відноситься конкретна технологія розробки), але більшість
широко відомих підходів пов'язані з однією конкретною категорією.
Розглянемо дані категорії більш детально.
1) Програмні підходи.
В даному підході web-додатком (динамічним ресурсом, пов'язаних з
URL-адресою) є зовнішня програма, складена на деякому універсальному мові
програмування високого рівня (наприклад, такому як Java або C ++), або
скрипт, складений за допомогою скриптової мови, виконання якого
проводиться також за допомогою зовнішньої програми - інтерпретатора
скриптів (script engine).
Основною проблемою з програмним підходом до розробки web-
додатків є їх орієнтація на написання коду. Розмітка HTML і інші конструкції
форматування вбудовуються в логіку роботи програми за допомогою
операторів виведення.
Це обмежує можливості web-дизайнерів вносити свій вклад в
оформлення створюваної додатком сторінки. Web-дизайнер може розробляти
макет сторінки, а програміст повинен потім перетворити його в код і зв'язати
зі скриптом або програмою. Для зміни практично будь-якого елементу
формованої сторінки потрібне втручання програміста, чи стосується це зміни
логіки роботи програми, які зміни оформлення і розташування елементів
сторінки [23].
2) Зовнішні програми.
Найпростіший спосіб динамічно формувати web-сторінки у відповідь на
HTTP-запит полягає в тому, щоб передати роботу по вирішенню необхідної
задачі і формування HTML-сторінки зовнішній програмі, яка повинна
отримувати передані в HTTP-запиті вхідні параметри і сформувати вихідну
сторінку на мові HTML.
27
Першою широко використовується, незалежної від типу web-сервера
програмної технологією створення і виконання web-додатків була технологія
Common Gateway Interface (CGI, загальний шлюзовий інтерфейс). Вона
визначала набір правил, яким повинна слідувати програма, щоб вона могла
виконуватися на різних НТТР-серверах і операційних системах [23].
Відповідно до CGI-технологією під час вступу до web-сервер HTTP-
запиту, який включає посилання не на статичну сторінку, а на CGI-програму
(наприклад: prog.exe), створюється новий процес, в якому запускається
необхідна прикладна програма [23].
Технологія CGI задає спосіб передачі такій програмі параметрів, що
входять до складу HTTP-запиту. Передача вхідних даних може виконуватися
або за допомогою фіксованого набору змінних середовища (environment
variables), які можуть створюватися однією програмою і використовуватися
іншими програмами, або через вхідні дані функції, з якої починається робота
програми (функція main ()), а результати роботи програми ( HTML-сторінка)
повертаються за допомогою стандартного потоку виводу STDOUT [23].
Технологія CGI дозволяє використовувати будь-яку мову
програмування, який може працювати зі стандартними пристроями введення /
виводу. Крім цього, CGI-програми можна писати з використанням скриптових
мов, які називаються "CGI-скриптами" [23].
Прикладами скриптових CGI-мов є, наприклад, Perl, Python або Tel. При
використанні скрипта web-ссрвср викликає на виконання зовнішню програму
- інтерпретатор скриптів (script engine), якій передаються дані HTTP-запиту і
ім'я файлу, в якому міститься запитуваний користувачем скрипт. А потім ця
програма виконує вказаний скрипт і повертає сервера сформовану HTML-
сторінку [23].
Процес проектування сайту як і будь-якої іншої програми містить
наступні кроки:
Крок 1 Опис мети сайта.
28
Рамки проекту задаються стратегією сайта. На стратегічному рівні
визначається не тільки те, що отримають від сайта його власники, але те, що
повинні отримати від сайта його користувачі. Наприклад в книжковому
магазині стратегічні цілі видно цілком ясно: користувачі хочуть купити книги,
а ми хочемо їх продати. Інші ж цілі сайту можуть бути не такими очевидними
[6].
Крок 2 Створення словника термінів.
Якщо розробляється великий сайт, то для полегшення спілкування
розробників сайта та замовників створюється словник термінів.
В процесі проектування і особливо в ході мозкових штурмів необхідне
створення і застосування докладного і точного словника. Технічний нюанс
проектування інтерактивних продуктів настільки важливий, що єдине
неправильно тлумачене слово, може стати причиною краху цілого проекту.
Буває, що різні учасники команди клієнта застосовують поширені слова
«кнопка» або «діалог» для позначення якісно різних речей. Буває, що десять
високооплачуваних фахівців протягом двох годинників запекло сперечаються
через те, що різні учасники користуються різними визначеннями одних і тих
же понять [6].
Крок 3 Варіанти використання сайта ( персонажі та дії ).
Перелік та опіс дій, що будуть виконуватися користувачами на сайті. Для
створення переліку потрібно маті модель корістувача (персонаж) [6].
Крок 4 Опис сценаріїв.
Це можливі послідовності дій для кожного варіанту використання, часто ці
сценарії називають бізнес-логікою, або просто логікою сайта. Розрізняють
сценарії для персонажа і сценарії для програмного забезпечення [6].
Крок 5 Інформаційна структура.
Структура визначає, яким чином різні функції і матеріали сайту
співвідносяться між собою. Те, які саме функції і матеріали повинні бути
присутні на сайті, визначається попередніми етапами проектування.
29
Деякі сайти, торгуючі книгами, мають функцію, що дозволяє користувачеві
зберегти свою адресу на майбутнє, щоб вона автоматично виставлявся при
наступній покупці. Питання - чи повинна ця або будь-яка інша функція бути
присутня на сайті вирішується на етапі визначення варіантів його
використання [6].
Крок 6 Створення схеми сайту.
Схема це конкретне зображення абстрактнішої структури сайту. Схема
визначає наприклад розташування елементів інтерфейсу на сторінці оплати;
структура ж визначає те, як користувачі потраплять на цю сторінку, і те, куди
вони зможуть потрапити після того, як оплата буде здійснена [6].
Під поверхнею сайту розташовується його схема, яка визначає розташування
кнопки закладок, фотографій і блоків тексту. Схема визначає і оптимізує
взаємне розташування елементів сторінки з метою досягти максимальної
ефективності і ефектності - щоб ви запам'ятали логотип сайту, або змогли
швидко знайти кнопку кошика, коли вона вам знадобиться [6].
Крок 7 Створення зовнішнього вигляду сайту
На поверхні ви бачите набір веб-сторінок, що складаються з графіки і тексту.
По деяких із зображень можна клацнути і виконати яку-небудь дію,
наприклад, заглянути в свій кошик. Інші ж зображення є лише ілюстраціями,
наприклад, фотографія книги або логотип сайту [6].
Крок 8 Підготовка текстового та іншого наповнення сайта
Будь-який сайт містить певну інформацію. На освітньому сайті, відповідно,
розміщують навчальні матеріали у формі текстів, таблиць, малюнків,
презентацій, аудіо та відео файлів тощо. Зазвичай переважає текстова
інформація і творці сайтів схильні думати, що сприйняття навчального тексту
з паперового підручника аналогічне сприйняттю того ж текста з екрана
монітора. Численні дослідження у галузі Юзабіліті (наука про створення
інтерфейсів програмного забезпечення максимально зручних для користувача)
довели хибність цієї думки [6].
30
Крок 9 Кодування та програмування.
Маючи проект сайта програмісти та HTML-кодери створюють програмний
код та шаблони для зовнішнього вигляду веб-сторінок [6].
Крок 10 Тестування.
Тестування проводиться у двох варіантах.
1) Тестування програмного забезпечення на відсутність помилок,
правильність обчислень, стійкість до перевантажень. Для перевірки на
відсутність помилок існує спеціальне програмне забезпечення, котре
дозволяє автоматизувати процес. Стійкість до перевантажень актуальна
для сайтів, які обслуговують одночасно велику кількість відвідувачів.
Наприклад, двадцять-тридцять користувачів неправильно
запрограмованого чату призводять до відмови апаратного програмного
забезпечення сервера. Перевірка на правильність обчислень є найбільш
працемісткою. На цьому етапі перевіряється правильність реалізації
сценаріїв. Як мінімум треба перевірити правильність повсякденних та
найбільш відповідальних сценаріїв [6].
2) Юзабіліті-тестування. В юзабіліті-тестуванні кожному користувачу
окремо щось демонструється (це може бути сайт, дослідний зразок
сайта, чи макети окремих сторінок) і далі його просять або спробувати
зрозуміти, що він бачить, або виконати певне завдання [6].
Отже, метою нашого сайту є забезпечення тестування програмного
забезпечення в реальному режимі часу та ведення документації проекту.
Побудуємо декілька діаграм, що проілюструють зв’язки web-сервісу
відстеження багів в реальному часі з усіма можливими учасниками.
Діаграми будуватимемо засобами MS Visio та ERwinDataModeler r7, для
кращої наочності і показу функціоналу.
Розробка моделі предметної області web-сервісу відстеження багів в
реальному часі починається з інформаційної структури, розподілення
обов’язків та прав [17].
31
Створена організаційна структура, яка відображає підрозділи системи.
На рисунку 2.5 зображена схема діяльності web-сервісу відстеження багів в
реальному часі.
Рисунок 2.5 – Схема діяльності web-сервісу відстеження багів в реальному
часі
Організаційна структура підпорядкованості web-сервісу відстеження багів в
реальному часі зображена на рисунку 2.6.
Адміністратор Користувач
Рисунок 2.6 – Організаційна структура web-сервісу відстеження багів в
реальному часі С
За даною структурою прослідковується зв’язок користувача та адміністратора
системи. Функціональна модель системи відображає функціональну
32
структуру об’єкту у вигляді конкретизації дії та зв’язків між цими діями (рис.
2.7).
До загальних функцій відносяться:
• можливість оновлення;
• перегляд загальної інформації про систему;
• налагодження системи;
• аналіз тексту програмного забезпечення;
• введення нових даних.
Рисунок 2.7 – Функціональна модель web-сервісу відстеження багів в
реальному часі
Візуальне моделювання є процесом ступеневого спуску від найбільш
загальної концептуальної моделі вихідної системи до логічної та фізичної
моделі мобільного застосунку, який нами розробляється. Тобто ми описуємо
процес функціонування web-сервісу відстеження багів в реальному часі.
33
Для детального аналізу відносин користувача та адміністратора
інформаційної системи будуємо таблицю функціональних можливостей, яка
відображає залежності виконаних робіт у відповідності до організаційних
ланок (таблиця 2.1)
Таблиця 2.1 Функціональні можливості
Функціональна область
Користувач X X X
Розробник X X X
Побудуємо модель функціональної області застосування web-сервісу
відстеження багів в реальному часі. Побудова моделі web-сервісу відстеження
багів в реальному часі починається з опису функціонування системи [18] у
вигляді контекстної діаграми (рисунок 2.8).
Рисунок 2.8 – Контекстна діаграма функціонування web-сервісу відстеження
багів в реальному часі
34
Внесення змін в
дані
Зміни вигляду
програми
Зміна коду
програми
Перегляд
інформації
Редагування
своїх даних
Взаємодія з навколишнім середовищем описується за допомогою входів
(«load new informations», «load new program»), виходів («view infomations»,
«analyze), управління («the norms of the Text» і «information technologies
development») [19].
User- люди, що використовують даного web-сервісу відстеження багів в
реальному часі.
Administrator – людина, що керує всіма процесами web-сервісу
відстеження багів в реальному часі.
load new informations, load new program– запити, що виконує користувач
до web-сервісу відстеження багів в реальному часі.
Viewinformation – перегляд інформації з інформаційної системи.
Виконаємо процес функціональної декомпозиції (рисунок 2.9) для
розуміння ролі проектованого web-сервісу відстеження багів в реальному часі.
Рисунок 2.9 – Діаграма декомпозиції web-сервісу відстеження багів в
реальному часі
35
Як видно з діаграми, весь процес функціонування web-сервісу
відстеження багів в реальному часі має два блоки:
Operation selection - розгалуження, що дозволяє користувачеві вибрати
потрібну операцію з web-сервісом відстеження багів в реальному часі.
ing information - надання користувачу всієї доступної інформації.
A
n Update– оновлення програми (оновлення інформації чи функціональної
aчастини).
l Для побудови якісної бази даних, що буде web-сервісом відстеження
yбагів в реальному часі створимо логічну модель бази даних, яка випливає з
мs оделі «To Be» та логічних зв’язків діаграми станів (рисунок 2.10).
e
– аналіз тексту програмного забезпечення.
Рисунок 2.10 – Логічна модель бази даних для web-сервісу відстеження багів
в реальному часі
36
Як ми бачимо з рисунка 2.10 майбутня база даних, що міститиме інформацію
про виконані роботи, зауваження та плани проекту, складається з 10 сутностей.
Кожна сутність має свої характеристики.
Техніки та методології моделювання даних використовуються для
моделювання даних у стандартний, послідовний і передбачуваний спосіб
задля керування ним як ресурсом.
Використання стандартів моделювання даних настійно рекомендується
для всіх проектів, що вимагають стандартні засоби визначення й аналізу даних
у межах організації, наприклад, моделювання даних використовується для:
допомоги бізнес-аналітикам, програмістам, тестувальникам, авторам
керівництв, вибірникам пакетів ІТ, інженерам, менеджерам, пов'язаним
організаціям і клієнтам зрозуміти та використати погоджену
напівформальну модель концепції організації та як вони стосуються
один одного;
керування даними як ресурсом;
інтеграції інформаційної системи;
проектування баз і сховищ даних (також відомі як репозитарії даних).
Моделювання даних може здійснюватися під час різних типів проектів і на
багатьох фазах проектів.
Висновок до розділу 2
У другому розділі розглянуто питання створення веб-додатків та веб-
сервісів. Створено моделі функціональної залежності системи з користувачем
та зовнішнім світом, а також, побудовані контекстні діаграми, що дозволили
отримати логічну модель даних.
37
РОЗДІЛ 3 ПРОГРАМНА РЕАЛІЗАЦІЯ WEB-СЕРВІСУ
ВІДСТЕЖЕННЯ БАГІВ В РЕАЛЬНОМУ ЧАСІ
3.1 Формальна постановка задачі
У відповідності до мети кваліфікаційної роботи бакалавра необхідно
програмно реалізувати web-сервіс відстеження багів в реальному часі.
Даний сервіс має задовольняти вимоги командної роботи та дозволяти
проводити відслідковування багів у режимі реального часу. Відомості про
знайдені недоліки в рядках програмного забезпечення та перевірки
зберігаються в базі даних.
3.2 Вхідна і вихідна інформація
Вхідною інформацією для роботи системи є:
дописи користувачів системи;
файли з текстом програми.
Вихідною інформацією є:
результати відшукання багів у коді;
облік знайдених багів;
облік виконаних дій на дошці оголошень системи.
3.3 Засоби розробки web-сервісу відстеження багів в реальному часі
Для реалізації проекту обрано JAM stack. Бізнес-логіка дій Backend
написана засобами Ruby on Rails, а зовнішній інтерфейс Frontend створено
засобами Angular 2+. Аутенфікація проводиться засобами github omniauth.
Авторизація – JWT, multiple devices. Розглянемо кожен засіб реалізації
власного програмного продукту.
3.3.1 Середовище Ruby on Rails
Ruby on Rails - фреймворк, написаний на мові програмування Ruby,
реалізує архітектурний шаблон Model-View-Controller для веб-додатків, а
також забезпечує їх інтеграцію з веб-сервером і сервером баз даних. Це
відкрите програмне забезпечення і розповсюджується під ліцензією MIT.
38
Розробником програмного продукту є Ханссон, Давид Хейнемейер, який
розміщується на офіційному сайті rubyonrails.org та був випущений у 2005
році. У 2021 вийшла остання версія 6.1.3.2.
Rails - фреймворк для веб-розробки, написаний на мові програмування
Ruby. Він розроблений, щоб зробити програмування веб-додатків простіше,
так як використовує ряд припущень про те, що потрібно кожному розробнику
для створення нового проекту. Він дозволяє вам писати менше коду в процесі
програмування, в порівнянні з іншими мовами і фреймворками. Професійні
розробники на Rails також відзначають, що з ним розробка веб-додатків більш
забавна.
Rails - свавільний програмний продукт. Він робить припущення, що є
"кращий" спосіб щось зробити, і він так розроблений, що стимулює цей спосіб
- а в деяких випадках навіть перешкоджає альтернативам. Якщо вивчіть "The
Rails Way", то, можливо, відкриєте в собі значне збільшення продуктивності.
Якщо будете наполягати і переносити старі звички з інших мов в розробку на
Rails, і спробуєте використовувати шаблони, вивчені десь ще, ваш досвід
розробки буде менш щасливим.
Філософія Rails включає два важливих провідних принципу:
1) Do not Repeat Yourself: DRY - це принцип розробки ПО, який
говорить, що "Кожен шматочок інформації повинен мати єдине
авторитетне уявлення в системі". Не пишіть одну і ту ж
інформацію знову і знову, код буде легше підтримувати, і він буде
більш розширюваним і менш помилковим.
2) Convention Over Configuration: у Rails є думки про найкращі
способи робити безліч речей в веб-додатку, і за замовчуванням
виставлені ці угоди, замість того, щоб змушувати вас по дрібницях
правити численні конфігураційні файли.
Rails поставляється з рядом скриптів, названих генераторами,
розроблених для полегшення життя розробника, створюючи все, що необхідно
39
для початку роботи над певним завданням. Одним з них є генератор нової
програми, що надає вам основу програми Rails, таким чином, вам не потрібно
писати його самим.
3.3.2 Angular 2
Angular є фреймворком від компанії Google для створення клієнтських
додатків. Перш за все він націлений на розробку SPA-рішень (Single Page
Application), тобто односторінкових додатків. В цьому плані Angular є
спадкоємцем іншого фреймворка AngularJS. У той же час Angular це не нова
версія AngularJS, а принципово новий фреймворк [24].
Angular дозволяє динамічно змінювати дані в одному місці інтерфейсу
при зміні даних моделі в іншому, шаблони, маршрутизація і так далі.
Однією з ключових особливостей Angular є те, що він використовує в якості
мови програмування TypeScript.
Але ми не обмежені мовою TypeScript. При бажанні можемо писати програми
на Angular за допомогою таких мов як Dart або JavaScript. Однак TypeScript
все таки є основною мовою для Angular.
Остання версія Angular - Angular 12 вийшла в травні 2021 року. Офіційний
репозиторій фреймворка на https://github.com/angular/angular [24].
Для роботи з Angular необхідно встановити сервер Node.js і пакетний
менеджер npm, якщо вони відсутні на робочій машині. При цьому особливого
якогось знання для роботи з NodeJS і npm не потрібно. Для установки можна
використовувати програму установки node.js. Разом з сервером вона також
встановить і npm [24].
Слід враховувати, що Angluar 12 підтримує ті версії node.js, які в
поточний момент знаходяться в статусі "Active LTS" або "Maintenance LTS".
На момент написання даної статті це версія від 14.15 і вище, але нижче версії
15.0 [24].
Перевірити статус певної версії node.js можна за адресою:
https://nodejs.org/en/about/releases/.
40
Те ж саме стосується і npm. Якщо версія занадто стара або, навпаки, одна з
останніх, то Angular може її не підтримувати. При роботі з Angular краще
покладатися на ту версію npm, яка встановлюється разом з LTS-версією
Node.js [24].
Після установки необхідних інструментів створимо найпростіше
додаток. Для цього визначимо на жорсткому диску папку програми. Шлях
вона буде називатися helloapp.
Angular дозволяє вам з "коробки" створювати великі і складні за
частиною бізнес-логіки додатка. Angular було повним переосмисленням
AngularJS, напевно, це було найболючіше, але воно того варте, сам фреймворк
став куди чистіше і гнучкіше, більш enterprise-подібним і з цієї точки зору має
високу масштабованість [25].
Переваги фреймворку:
1) Підтримка Google, Microsoft;
2) Інструменти розробника (CLI);
3) Єдина структура проекту;
4) TypeScript з "коробки" (ви можете писати строго типізований код);
5) Реактивний програмування з RxJS;
6) Єдиний фреймворк з Dependency Injection з "коробки";
7) Шаблони, засновані на розширенні HTML;
8) Кросбраузерності Shadow DOM з коробки (або його емуляція);
9) Кросбраузерності підтримка HTTP, WebSockets, Service Workers;
10) Не потрібно нічого додатково налаштовувати. Більше ніяких
обгорток;
11) Більш сучасний фреймворк, ніж AngularJS (на рівні React, Vue);
12) Велике ком'юніті.
Щоб залишатися чесними, варто виділити і мінуси:
41
1) Вище поріг входження через Observable (RxJS) і Dependency
Injeciton;
2) Щоб все працювало добре і швидко потрібно витрачати час на
додаткові оптимізації (він не супер швидкий, за замовчуванням,
але швидше AngularJS у багато разів і з кожною новою версією
стає все швидше);
3) Насправді, якщо ви плануєте розробляти велику enterprise-
додаток, то в цьому випадку у вас немає архітектури для
управління станом з "коробки" - потрібно додавати Mobx, Redux,
CQRS / CQS або інший state-менеджер;
4) Angular-Univesal має багато підводних каменів;
5) Динамічне створення компонентів виявляється нетривіальною
завданням.
Насправді, всі ці мінуси нівелюються власним досвідом розробника. Все, що
вам доведеться дізнатися в Angular для розробки продуктивних і швидко
працюють додатків будь-якого рівня складності, описано в нижче наступних
концепціях:
1) Form Builder - для розробки воістину складних форм, вам слід знати
реактивні форми, точніше принципово забути про декларативні форми.
Ось один з хороших прикладів (реактивна форма + валідація) [25];
2) Change Detection - так як Angular за замовчуванням використовує
двостороннє зв'язування моделі даних, то при роботі з великим об'ємом
таких даних ваші програми будуть працювати повільніше, тому в деяких
випадках варто подбати про правильну стратегію виявлення змін. Ви
можете подивитися на різні OpenSource проекти: PrimeNG, Angular
Material, Clarity UI, Angular Bootstrap і інші, всі вони використовують
ChangeDetection.OnPush [25].
3) Templating - синтаксис шаблонів з точки зору абстракції змінився не
дуже сильно в порівнянні з AngularJS, тобто ми так само можемо
42
написати умови, цикли, зв'язати модель даних та інше. Все, що вам слід
добре зрозуміти і розібратися в Angular шаблонах - що таке структурні і
декларативні директиви, а також що таке Input-параметри і Output-події
[25].
Routing - напевно, це одне з основних явищ у розробці веб-додатків. Тут
просто важливо розуміти, що маршрутизація так само, як і компоненти, має
свій життєвий цикл, розуміючи це, ви можете писати воістину круті додатки.
Ще варто відзначити: якщо на якійсь із маршрутів ви вішаєте модуль, а не
компонент, який відповідає за відображення сторінки по цьому маршруту, то
модуль буде довантажувати на сторінці на вимогу [25].
Annotations - до слова, багато новачків не знають, але варто відзначити.
Декоратори, які використовуються в достатку при написанні додатків на
Angular, не є якоюсь жорсткою магією TypeScript. Декоратори є
специфікацією EcmaScript і коли браузери почнуть підтримувати їх, вони
будуть нативної виконуватися в browser runtime. Насправді, декоратори
вельми корисні і забезпечують досить високою читаністю ваш код. Один із
прикладів - це валідація моделей даних з використанням декораторів або
десеріалізацію/сериализация даних [25].
Observables - насправді, тут варто відзначити тільки те, що незабаром
Observables будуть специфікацією EcmaScript і все це буде нативної
підтримуватися в браузерах. З точки зору теорії, якщо розкрити поняття
Observer (спостерігач) - це поведінковий шаблон проектування. Також
відомий як «підлеглі» (Dependents). Створює механізм у класу, який дозволяє
отримувати примірника об'єкта цього класу оповіщення від інших об'єктів про
зміну їх стану, тим самим спостерігаючи за ними [25].
Shadow DOM - це засіб для створення окремого DOM-дерева всередині
елемента, яке не видно зовні без застосування спеціальних методів, є
специфікацією W3C. Грубо кажучи, це зручний спосіб створення ізольованих
і переіспользуемих веб-компонентів [25].
43
Angular они перенесли всі працюючі приклади в документації на сучасну
онлайн IDE StackBlitz. Тобто тепер ваші проекти, які ви запускаєте у себе
локально, ідентичні прикладів з документації.
Якщо раніше вони всі були на SystemJS і працювали в Plunker, то тепер
вам достатньо зайти на офіційний сайт StackBlitz і запустити однією кнопкою
додаток на Angular або Ionic. Все це працює прямо в браузері, прямо там же ви
можете встановлювати npm-пакети і писати свій код на TypeScript [25].
Ви можете запустити будь-який GitHub-репозиторій з Angular-додатком
прямо на StackBlitz.
3.4 Інтерфейс web-сервісу відстеження багів в реальному часі
Побудуємо карту сайту web-сервісу відстеження багів в реальному часі.
Дана карта зображена на рисунку 3.1. На карті зображено посилання на
головні сторінки сайту. Карта має древовидну структуру, що полегшує її
аналіз.
З рисунку 3.1 видно, що на сайті є 12 вузлів (позначені червоним
хрестом), що містять можливі помилки чи заблоковані з метою збереження
іномації.
За результатами створення карти сайту за допомогою MS Visio
сформуємо звіт (таблиця 3.1).
Таблиця 3.1 Звіт за картою web-сервісу відстеження багів в реальному часі
Відомість
Ім"я зразка Кількість
HTML 338
Динамісна з"єднувальна лінія 355
Посилання XML 3
Посилання на векторний рисунок 3
Посилання на скрипт (на клієнті) 3
Посилання на таблицю стилей 3
Посилання на точечний рисунок 3
Універсальні посилання 3
44
У відповідності до проведеного аналізу бачимо, що сайт містить 338
можливих варіантів закладок, що поєднані між собою логікою дій.
45
Рисунок 3.1 – Карта сайту web-сервісу відстеження багів в реальному часі
46
Головною сторінкою при запуску web-сервісу відстеження багів в
реальному часі за посиланням https://github.com/activebridge/bugno-
api/issues?q=assignee%3Akatatsu12+is%3Aopen є зображення сторінки входу в
гікхаб на якій розміщено наш сервіс.
Рисунок 3.2 – Головна сторінка входу до web-сервісу відстеження багів
в реальному часі
На закладці Code містяться файли з відкритим кодом сервісу.
На закладці Issues ведеться облік багів, які були знайдені в процесі
перевірки програмного коду (рисунок 3.3).
47
Рисунок 3.3 – Закладка обліку багів
Як ми бачимо, то 2 травня 2020 року розробник #102 opened on 2 May 2020 by Alexey-
Lukin перевіряв своє програмне забезпечення, що написане на Ruby (рисунок
3.4)
Рисунок 3.4 – Інформація про користувача впровадженої системи
Наступною закладкою є сторінка обліку звертань до системи, так як вона є
дошкою завдань (рисунок 3.5).
Рисунок 3.5 – Сторінка звертань до web-сервісу відстеження багів в
реальному часі
48
З рисунку 3.5 видно, що до сервісу звертався бот для пеервірки завдань і стоять
помітки залежності виконаних робіт.
Сторінка Actions містить інформацію використання засобів web-сервісу
відстеження багів в реальному часі. Наводяться основні принципи
автоматизації робочого процесу від ідеї до виробництва (рисунок 3.6).
Рисунок 3.6 – Сторінка інформації про систему
На сторінці проектів Projects, що діє за посиланням
https://github.com/activebridge/bugno-api/projects знаходиться інформація про
поточні проекти, що виконуються за допомогою даного веб-сервісу (рисунок
3.7).
49
Рисунок 3.7 – Сторінка обліку прооектів
Сторінка Wiki веде облік проведених операцій з переврки програмного
забезпечення (рисунок 3.8).
Рисунок 3.8 – Сторінка обліку використання web-сервісу відстеження багів в
реальному часі
На сторінці в правому нижньому куті показуються виконавці проектів в
даному сервісі.
На сторінці Security описуються засоби захисту проектів, що розміщені
в репозиторії веб-сервісу (рисунок 3.9).
50
Рисунок 3.9 – Сторінка безпеки
Сторінка Insights містить залежності визначені у файлах маніфестів
bugno-api, таких як Gemfile, Gemfile.lock та package-lock.json (рисунок 3.10).
Рисунок 3.10 – Сторінка історії обліку подій
На рисунку 3.10 зображено внески для освоєння, за винятком об'єднаних
комітів та бот-рахунків.
Вибір звітності відбувається за допомогою активних посилань з лівого боку
сторінки. Хронологія останніх комітів до цього сховища та його мережі,
упорядкована останнім часом наведена на рисунку 3.11.
51
Риунок 3.11 – Хронологія коментарів до web-сервісу відстеження багів в
реальному часі
3.5 Опис основного коду web-сервісу відстеження багів в реальному часі
Основний код програми складається з 12 основних біблотек файлів (рисунок
3.12)
Рисунок 3.12 – Опис бібліотеки Frontend
Текст програми основних модулів наведений у додатку (Див. додаток Б).
3.6 Верифікація та тестування
Проведемо перевірку роботи системи на прикладі проекту events_spec.rb.
Завантажимо текст коду для перевірки.
# frozen_string_literal: true
describe API::V1::Projects::Events do
let(:user) { create(:user, :with_project_and_subscription) }
let(:project) { user.projects.first }
let(:base_url) { "/api/v1/projects/#{project.id}/events" }
let(:url) { base_url }
let(:headers) { user.create_new_auth_token }
let(:params) { {} }
let(:request_params) { [url, { params: params, headers: headers }] }
describe '#index' do
subject { -> { get(*request_params) } }
let!(:event) { create(:event, project: project) }
context 'return parent events' do
let!(:occurrence) { create(:event, project: project, parent_id: event.id) }
it { is_expected.to respond_with_json_count(1).at(:events) }
52
it { is_expected.to respond_with_status(200) }
end
context 'by status' do
let!(:muted_event) { create(:event, project: project, status: :muted) }
let(:params) { { status: :muted } }
it { is_expected.to respond_with_json_count(1).at(:events) }
end
end
describe '#occurrences' do
subject { -> { get(*request_params) } }
let(:event) { create(:event, project: project) }
let!(:occurrence) { create(:event, project: project, parent_id: event.id) }
let(:url) { "#{base_url}/occurrences/#{event.id}" }
it { is_expected.to respond_with_json_count(1).at(:events) }
it { is_expected.to respond_with_status(200) }
context 'when occurrence id' do
let(:url) { "#{base_url}/occurrences/#{occurrence.id}" }
it { is_expected.to respond_with_json_count(1).at(:events) }
end
end
describe '#create' do
subject { -> { post(*request_params) } }
let(:headers) { nil }
let(:url) { "/api/v1/projects/#{project.api_key}/events" }
let(:params) { attributes_for(:event) }
it { is_expected.to respond_with_status(201) }
it { is_expected.to change(project.events, :count) }
context 'when occurrence' do
let!(:parent_event) do
create(:event, :static_attributes, :with_project_error_trace, project: project,
status: :resolved)
end
let!(:params) { attributes_for(:event, :static_attributes) }
it 'updates parent event last_occurrence_at' do
is_expected.to change { parent_event.reload.last_occurrence_at }
end
it 'changes parent event status to active' do
is_expected.to change { parent_event.reload.status }
end
context 'when parent is muted' do
let!(:parent_event) { create(:event, :static_attributes, project: project, status:
:muted) }
it { is_expected.not_to change { parent_event.reload.status } }
end
end
context 'when missing subscription or it is expired' do
before { project.subscription.update(events: -1) }
53
it { is_expected.not_to change(project.events, :count) }
it { is_expected.to respond_with_status(422) }
end
context 'when missing api key' do
let(:api_key) { nil }
let(:url) { "/api/v1/projects/#{api_key}/events" }
it { is_expected.to respond_with_status(401) }
it { is_expected.not_to change(project.events, :count) }
end
context 'when api key is invalid' do
let(:api_key) { 'invalid_api_key' }
let(:url) { "/api/v1/projects/#{api_key}/events" }
it { is_expected.to respond_with_status(422) }
it { is_expected.not_to change(project.events, :count) }
end
end
describe '#show' do
subject { -> { get(*request_params) } }
let!(:event) { create(:event, project: project) }
let(:url) { "#{base_url}/#{event.id}" }
it { is_expected.to respond_with_status(200) }
end
describe '#update' do
subject { -> { patch(*request_params) } }
let(:event) { create(:event, user: nil, project: project) }
let(:url) { "#{base_url}/#{event.id}" }
let(:params) { { event: { status: :muted, user_id: user.id } } }
it { is_expected.to change { event.reload.status } }
it { is_expected.to change { event.reload.user_id } }
context 'when status changed' do
let(:occurrence) { create(:event, project: project, parent_id: event.id) }
let(:url) { "#{base_url}/#{occurrence.id}" }
it { is_expected.to change { occurrence.reload.status } }
end
end
describe '#destroy' do
subject { -> { delete(*request_params) } }
let(:event) { create(:event, project: project) }
let!(:occurrence) { create(:event, project: project, parent_id: event.id) }
let(:url) { "#{base_url}/#{event.id}" }
# let(:result) { EventSerializer.new(event).as_json }
it { is_expected.to respond_with_status(200) }
it { is_expected.to change(project.reload.events, :count) }
# TODO: fix wrong symbolize in this matcher
# it { is_expected.to respond_with_json(result) }
context 'when event has occurrences' do
it { is_expected.to change(Event.where(parent_id: event.id), :count) }
54
end
end
end
Даний код містить 141 рядок і займає об’єм 4.77 КВ.
Відповідно шукати вручну помилку не є зручним і ми витрачаємо велику
кількість часу. Тому перевіримо його засобами веб-сервісу. Результати
перевірки зображено на рисунку 3.13.
Рисунок 3.13 – Результати перевірки коду на наявність помилок
Як ми бачимо виправлено появу групування за трасуванням ( # 114 ) та надано
рекомендації щодо оновлення подій у проекті та додавання декількох функцій
(рисунок 3.14).
Рисунок 3.14 – Рекомендації щодо виправлення багів
55
На сьогоднішній день веб-сервісом підтримуються мови: Ruby, Javascript.
Передбачена можливість створення проектів командою. Для цього у сервісу є
дошка з багами, які відловлюються бібліотеками(плагінами), що підключені
до проектів (рисунок 3.15)
Рисунок 3.15 – Зображення дошки з Багами
Система передбачає призначення відповідальних за певні баги членів
команди. Окремий член команди призначається на відловлювання певного
виду багу, якщо він досить часто повторюється. Для цього допомагає система
електронного листування та нотифікацій. Кожному багу присвоюється
повідомлення та деталі аналізу. Баги групуються за типом та місцем коду, в
якому вони з’явилися.
Висновок до розділу 3.
В даному розділі сформульовано вимоги до системи, що програмно
реалізовувалася. Наведено вхідні та вихідні дані та засоби програмної
реалізації. Детально описано інтерфейс та проаналізовано карту сайту.
Виконано тестування програмного продукту.
56
ВИСНОВКИ
Відкрита система відстеження помилок дозволяє виробникам
програмного забезпечення підтримувати контакт зі своїми клієнтами і
реселерами, для передачі повідомлень про помилки по всьому ланцюгу
управління даними.
Відповідно до мети кваліфікаційної роботи бакалавра було спроектовано
та програмно реалізовано web-сервіс відстеження багів в реальному часі. В
проці виконання кваліфікаційної роботи було вирішено наступні задачі:
1) розглянуто існуючі аналоги на ринку послуг перевірки програмного
забезпечення;
2) розглянуто основні принципи та методи тестування програмного
забезпечення;
3) виконано проектування web-сервіс відстеження багів в реальному часі;
4) описано процес програмної реалізації створюваного сервісу;
5) проведено верифікацію роботи системи.
У першому розділі розглянуті існуючі рішення створених систем перевірки
багів та управління проектами від ведучих фірм ІТ бізнесу. Прийнято рішення
створювати власний програмний продукт у форматі дошки-кабан. Виконано
огляд моделей надійності програмного забезпечення та наведено їх
класифікацію.
У другому розділі розглянуто питання створення веб-додатків та веб-
сервісів. Створено моделі функціональної залежності системи з користувачем
та зовнішнім світом, а також, побудовані контекстні діаграми, що дозволили
отримати логічну модель даних.
У третьому розділі сформульовано вимоги до системи, що програмно
реалізовувалася. Наведено вхідні та вихідні дані та засоби програмної
реалізації. Детально описано інтерфейс та проаналізовано карту сайту.
Виконано тестування програмного продукту.
Мета кваліфікаційної роботи бакалавра досягнута.
57