Реферат за темою випускної роботи

Вступ

В процесі розробки ПЗ потрібні заходи з виявленням помилок і недоліків в його роботі та вихідному коді. Для виконання даного завдання використовуються різні методи аналізу ПЗ. Аналіз ПЗ можна розділити на дві категорії: статичний і динамічний.

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

Дане дослідження загострює увагу на статичному аналізі програмного коду. Один з найстаріших методів виявлення дефектів у вихідному коді — це огляд коду (code review). Він полягає в спільному уважному читанні вихідного коду і висловленні рекомендацій щодо його поліпшення. [1] Однак з'являється бажання автоматизувати даний процес, тому придумані інші методи, які реалізовані в різних інструментах аналізу ПЗ.

Існує наступні основні форми статичного аналізу програмного забезпечення:

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

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

1. Актуальність теми

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

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

Наявність всіх можливостей СКВ у даних веб-сервісів, дозволяє їм зберігати вихідний код проєкту віддалено. У зв'язку з популярністю подібних веб-сервісів і наявності у них можливості зберігання коду, актуально розглянути інтегрування статичного аналізу з веб-сервісами для хостингу програмних проєктів.

Стаття Інтегрувальний статичний аналіз для програмного проєкту з використанням архітектурного стилю REST [2] представлена на III Міжнародній науково-практичній конференції Програмна інженерія: методи та технології розробки інформаційно-вичіслітельних систем (ПІІВС-2020). У ній описується докладно даний інтегрований підхід до статичного аналізу програмного проєкту.

2. Мета і задачі дослідження та заплановані результати

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

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

Основні завдання дослідження:

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

Об'єкти дослідження: статичний аналіз ПЗ і архітектурний підхід REST.

Предмет дослідження: інтеграція статичного аналізу ПЗ в існуючих програмний проєкт з використанням REST.

3. Огляд досліджень та розробок

Дослідження зачіпає такі області розробки ПЗ: метрики програмного забезпечення, візуалізація метрик і коду програмного проєкту, розподілені системи і архітектурний підхід до створення веб-сервісів REST. Розглянемо різні дослідження в кожній з цих областей.

3.1 Огляд досліджень в області метрик ПЗ

Різні автори розглядають різні метрики для програмного забезпечення. Дана робота розглядає метрики тільки для імперативних мов програмування, але навіть для імперативних мов є різне безліч метрик.

Моріс Голстед запропонував повноцінний набір метрик ПЗ, який зображає характеристики існуючої програми. [3] Дані метрики не покладаються на традиційний підрахунок рядків коду (LOC), а на підрахунок кількості операндів і операторів. Набір метрик поділяється на: базові показники, різні метрики обсягу програми, рівня якості, трудомісткості та витрат.

Томас Мак-Кейб описав метрику цикломатичної складності програми. [4] Метрика заснована на аналізі потоку передачі управління від одного оператора до іншого. Такий підхід дозволяє врахувати логіку програми. Програма представляється у вигляді керуючого орієнтованого графа, такий граф називають графом керування, графом потоку керування або керуючим графом програми. Метрика Мак-Кейба є цикломатичним числом графа управління, сума кількості ребер і вершин графа. Для даної метрики існують модифікації, запропоновані різними авторами, дві найвідоміші — Майерса і Хансена. [5]

Дані метрики розбираються в роботі магістра ДонНТУ Жукової Д.К., опублікованій на її особистому сайті. У роботі описуються різні метрики Холстеда, цикломатична метрика Мак-Кейба. Також крім цих метрик, розібрані різні метрики для об'єктно-орієнтованих мов: кількість викликаються віддалених методів (NORM), відгук на клас (RFC), зважена насиченість класу (WMPC1, WMPC2) і ін. Представлені кількісні метрики: кількість рядків коду (LOC), кількість класів (NOC), число відбуваються класів (NDC), число локальних методів (NLM) і т. д.

Віктор Базилі та Річард Селбі розглянули різні стратегії тестування. [6] Робота показує, що існує широкий діапазон стратегій тестування. Через наявність такого широкого діапазону стратегій тестування, корисно використовувати метрики, які підраховують кількість тестових випадків необхідних для кожної стратегії для заданої програми, наприклад, метрика Мак-Кейба може виміряти кількість тестових випадків, необхідних для структурного тестування.

Більшість сучасних мов підтримують модульність. Одним з намірів при розбитті програми на модулі — запобігти впливу зміни одного модуля на інший. Для того, щоб виміряти подібний зв'язок Норман Фентон запропонував класифікувати модулі на 6 класів зчеплення. [7] Надалі зчеплення для програми може бути побудований граф моделі зчеплення. Граф моделі зчеплення може надати хороший метод візуалізації зчеплень між модулями.

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

3.2 Огляд досліджень в області візуалізації ПЗ

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

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

Янг П. і Манро М. описали візуалізацію, засновану на тривимірних геометричних формах, таких як куби та циліндри [10]. Їх система складається з двох частин, CallStax і FileVis, які можна об'єднати в одну систему візуалізації. Є й інші види візуалізацій з використанням абстрактних структур: уявлення коду у вигляді реального світу (наприклад, міста), поліметричні уявлення, гіперболічні дерева, трімапінг, радар еволюції та ін.

3.3 Огляд досліджень в області розподілених систем і архітектурного підходу REST

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

Щолоков С. А. виділяє наступні вимоги до розподілених систем: відкритість, масштабованість, стабільність і безпеку. Він стверджує, що для задоволення цих вимог, система повинна включати додатковий рівень програмного забезпечення, який знаходиться між прикладним і транспортним рівнями по моделі OSI, званий проміжне програмне забезпечення. [11]

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

Проміжне середовище повинно забезпечувати обмін даними між компонентами розподіленої системи. В роботі Седневеца М.А. детально розібрано поняття проміжного середовища. Горін С.В., Крищенко В.А. стверджують, що існує дві концепції взаємодії компонентів ПЗ: обмін повідомленнями та віддалений виклик процедур (RPC) або віддалений виклик методів об'єкта. [12] Магістр Приходько С.А. розглядає механізм RPC і інші механізми взаємодії компонентів в розподіленій системі, а також наводить приклади архітектур з використанням даних механізмів. Наведено переваги та недоліки кожної з архітектур.

В мережі інтернет на базі протоколів TCP, HTTP можна побудувати протоколи більш високого рівня для реалізації віддаленого виклику процедур. Віддалений виклик процедур можна уявити як звичайний HTTP-запит (GET або POST, такий запит називають REST-запит). На цьому і заснований архітектурний стиль REST, який є одним зі способів обміну даними між компонентами розподіленої системи.

Архітектурний стиль REST запропонований Роєм Філдінгом у своїй дисертації «Архітектурні стилі та дизайн мережевих програмних архітектур» в Каліфорнійському університеті в Ірвайні у 2000 році. [13] По суті поняття REST відноситься не до архітектури, а до набору обмежень, що накладаються на архітектуру системи. Наведемо обов'язкові: приведення архітектури системи до моделі клієнт-сервер, відсутність станів між запитами, кешування запитів, однаковість інтерфейсу, шари (проміжні сервери), код на вимогу (необов'язкова вимога). Однаковість інтерфейсу — складна вимога, що складається з підпунктів: ідентифікація ресурсів; маніпуляція ресурсами через подання; самоописові повідомлення; гіпермедіа, як засіб зміни стану програми (HATEOAS). [14]

Таким чином, REST — це набір принципів при проєктуванні архітектури системи, а не архітектура або протокол. Також при проєктуванні не обов'язково чітко дотримуватися набору вимог, тоді подібна система буде називатися REST-like. Використання REST робить розробку розподілених веб-сервісів простий і гнучкою.

4. Підхід до статичного аналізу з інтеграцією з веб-сервісами хостингу проєктів

Як говорилося в попередньому розділі, інструмент для статичного аналізу коду повинен бути створений як веб-сервіс. Веб-сервіс простіше інтегрується з іншими інструментами збірки, розгортання і тестування проєкту. Це спрощує його використання в безперервної інтеграції (CI) [15] і в безперервному розгортанні (CD) [16]. Також веб-сервіс дозволяє зробити систему статичного аналізу крос-платформною, знизити навантаження на систему, в яку інтегрується статичний аналіз.

4.1. Вимоги до веб-сервісу для статичного аналізу коду

Наявність REST API у веб-сервісу дозволяє спростити інтеграцію з веб-сервісами для хостингу програмних проєктів. Всі популярні веб-сервіси для хостингу проектів, наприклад Github [17] або Gitlab [18], мають REST API. Тобто веб-сервіс для статичного аналізу повинен бути спроєктований з використанням архітектурного підходу REST.

Статичний аналіз існує в наступних формах: метрики ПЗ, візуалізація ПЗ і виявлення помилок в коді. Необхідно визначитися які види метрик і візуалізацій будуть використовуватися в системі статичного аналізу. У веб-сервісу присутній REST інтерфейс, відповідно для нього теж необхідно висунути вимоги.

4.1.1. Вимоги до метрик, які використовуються веб-сервісом

Веб-сервіc статичного аналізу повинен обчислювати наступні метрики ПЗ:

• різноманітні метрики рядків коду (SLOC, NCLOC, CLOC, кількість порожніх рядків коду, відсоток коментарів, середнє число рядків для функцій, середнє число рядків вихідного коду для функцій і т.д.);
• метрики Холстеда (покладаються на підрахунок операндів і операторів);
• метрики цикломатичної складності (для оцінки складності потоку керування програми);
• метрики покриттів коду для вимірювання складності тестування;
• метрики для вимірювання складності модулів програми (для мови C модулями виступають функції).

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

Найважливішим форматом для експорту метрик є CSV [19], тому що він дозволяє поліпшити інтеграцію з іншими утилітами. Також повинен бути хоча б один формат зручний для читання, наприклад, HTML [20].

4.1.2. Вимоги до візуалізацій, використовуваним веб-сервісом

Як підходи до візуалізації веб-сервіс повинен використовувати такі:

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

Також варто додати фільтрацію з використанням динамічних запитів по значеннях метрик при візуалізації ПЗ.

4.1.3. Вимоги до REST інтерфейсу і веб інтерфейсу сервісу

Запити до REST API можна поділити на 2 типи: записи та читання. Запити типу читання використовуються для отримання інформації про проєкт або обчислені метрики. Запити типу записи дозволяють створювати проєкт або змінювати його вміст. Головна ідея запитів типу записи в тому, що всі метрики обчислюються по зв'язаних із запитом файлів (або за проєктом в цілому). Надалі клієнт отримує просто інформацію про обчислені метрики за допомогою запитів читання.

Всі запити маніпулюють ресурсами проєкту за допомогою уявлень, які можна отримати через певний ресурс. Ресурси можуть бути вкладеними один в одного. У підсумку вони утворюють деревоподібну структуру. Дана структура ресурсів представлена на рис. 1.

Від кореня відгалужуються такі ресурси: register і :користувач (параметр, який вказується при запиті, наприклад, /omegadog). Використовуючи запит register, можна створити обліковий запис в системі. Потім, використовуючи ім'я користувача, вказане в акаунті, можна управляти проєктами цього акаунту. Таким чином ресурс /:ім'я_користувача/:назва_проекта (:назва_проекта — це параметр, який визначає ім'я проєкту на акаунті з ім'ям користувача :ім'я_користувача) є кореневим ресурсом для всіх запитів, які керують проєктом.

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

Ресурс /:ім'я_користувача/settings використовується для зміни налаштувань облікового запису з ім'ям користувача :ім'я_користувача.

Запити сервісу приймають різні параметри, існує 2 способи передачі параметрів: параметри запиту або в тілі запиту. Параметри, які передаються в тілі запиту, зазвичай складно уявити в параметрах запиту, наприклад, HTTP [21] посилання на інший ресурс. Тіло запиту описується в JSON форматі, параметри всередині тіла представляються у вигляді ключ-значення (поле-значення) JSON [22] об'єкта.

В запитах використовуються наступні методи HTTP: GET, PUT, POST. Метод POST використовується при створенні уявлення або ресурсу, наприклад, запит на створення проєкту. При запиті на створення проєкту, клієнт звертається до ресурсу /:ім'я_користувача/:назва_проекта з використанням методу POST і передає параметри необхідні для створення проекту. Для отримання уявлень використовується метод GET, клієнту при зверненні до ресурсу з використанням даного методу повертається JSON об'єкт (подання ресурсу). У разі, якщо клієнту необхідно тільки внести зміни в існуючий ресурс, то він проробляє той же протокол дій як і в випадку з методом POST, тільки використовує метод PUT.

Запити типу записи повинні бути аутентифіковано, тому при в запиті повинно бути поле для передачі HMAC [23] запиту. Якщо запит не був аутентифікований, то запит повинен повернути відповідь 403 Forbidden. Підписування запитів HMAC зроблено для того, щоб розмежувати права серед клієнтів. Для довірених клієнтів слід згенерувати секретні ключі, сервіс і дані клієнти повинні розділяти ці ключі.

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

Веб-інтерфейс повинен володіти мінімальними можливостями для створення та управління акаунтами, генерації та отримання секретних ключів для користування REST API сервісу. Інші можливості сервісу можуть бути додані в інтерфейс при подальшій розробці.

4.2. Приклад інтеграції веб-сервісу статичного аналізу з веб-сервісом хостингу проєктів

Розглянемо приклад інтеграції веб-сервісу статичного аналізу з веб-сервісом Github, який є найбільшим сервісом для хостингу проєктів на цей момент. Даний сервіс, як і багато подібних, підтримує підписку на події, які відбуваються в репозиторії проєкту. При виникненні події відправляється POST запит на вказаний URL REST інтерфейсу, дана можливість називається веб-хуками (webhooks) [24]. Сервіс підтримує різні події:

• create, Git гілка або тег створені;
• delete, Git гілка або тег видалені;
• fork, користувач створив форк сховища;
• pull_request, стався запит на отримання (git pull) гілки або тега сховища;
• push, один або кілька коммітов відправлені (git push) в гілку або тег сховища;
• і т.д.

З перерахованих подій нижче, для сервісу статичного аналізу найбільш важливим є push. Оскільки необхідно відстежувати зміни, які відбуваються в гілці сховища, і потім обчислювати метрики та візуалізації з урахуванням нових змін. Також REST інтерфейс сервісу статичного аналізу повинен володіти ресурсом для обробки веб-хуков, тобто для кожного проєкту повинен бути виділений ресурс для даного обробника. Наприклад, для обробника веб-хуков сервісу Github, можна виділяти наступний ресурс /:ім'я_користувача /:назва_проекта/webhook/github, де :ім'я_користувача і :назва_проекта — це параметри, які змінюються в залежності від акаунту власника проєкту та самої назви проєкту.

Веб-хук для події push передає велику кількість параметрів в тілі запиту, однак найважливішим параметром є after, який зберігає SHA-хеш [25] останнього відправленого комміту в гілку. Маючи дане значення хешу, сервіс надалі може обробити зміни в гілці сховища з використанням REST API Github.

Опишемо процес обробки змін в гілці сховища при отриманні веб-хука push сервісом статичного аналізу. Процес складається з наступних етапів:

1. Отримавши SHA-хеш останнього комміту, сервіс відправляє запит на отримання інформації про комміт з використанням запиту REST API Github /repos/:ім'я_користувача /:назва_проекта/git/commits/:хеш_комміта. У відповіді на запит, приходить багато параметрів, але важливим є параметр tree. Параметр tree — це об'єкт, всередині якого зберігається властивість sha. Властивість sha зберігає SHA-хеш дерева BLOB-об'єктів [26], на яке вказує комміт.
2. За допомогою запиту /repos/:ім'я_користувача/:назва_проекта/git/trees/:хеш_дерева, у відповіді на запит отримуємо структуру дерева. Дана структура зберігається в параметрі tree, це масив об'єктів JSON. Важливими параметрами кожного об'єкта є: path (шлях до файлу або директорії), type (BLOB або дерево (tree)) і sha (SHA-хеш BLOB-об'єкта або піддерево).
3. У разі виникнення нових шляхів, необхідно додати відповідні ресурси для проєкту.
4. Необхідно звірити для кожного вже існуючого шляху хеш значення зі значеннями, які зберігаються на сервісі статичного аналізу. У разі розбіжності значень і якщо шлях є типу BLOB, необхідно отримати вміст за допомогою запиту /repos/:ім'я_користувача/:назва_проекта/git/blobs/:хеш_blob. Для кожного нового шляху теж необхідно отримати вміст, якщо тип нового шляху BLOB. Відповідь на даний запит містить 2 поля: content (вміст BLOB-об'єкта) і encoding (кодування даних в полі content, наприклад, base64 [27]).
5. У разі розбіжностей хеш-значень і якщо шлях є піддерево (тип tree), рекурсивно повторити кроки 2-5. Для нового шляху з типом tree, теж повторити кроки 2-5 для піддерево.

На рис. 2 показаний конкретний приклад процесу обробки змін в гілці сховища при посиланні веб-хука push сервісу статичного аналізу, в даному прикладі в гілку репозиторію відправляється комміт, який змінює файл file1.c і додає file2.c.

Висновки

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

В рамках проведених досліджень:

• на підставі аналізу літературних джерел виділено основні метрики та візуалізації, які можуть бути використані в запропонованому підході до статичного аналізу проєктів;
• розглянуто архітектурний підхід REST і його застосування для інтеграції з веб-сервісами хостингу проєктів і іншими інструментами розробки ПЗ;
• розглянуто підхід до статичного аналізу з використанням архітектурного стилю REST, інтеграцією з веб-сервісами хостингу проєктів;
• розроблена програмна модель (веб-сервіс) даного підходу, висунуті вимоги до моделі та спроєктована її архітектура.

Подальші дослідження спрямовані на наступні аспекти:

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

При написанні даного реферату магістерська робота ще не завершена. Остаточне завершення: червень 2021 року. Повний текст роботи та матеріали на тему можуть бути отримані в автора або його керівника після зазначеної дати.

Перелік посилань

1. Статический анализ как часть процесса разработки Unreal Engine // Habr [Электронный ресурс]. — Режим доступа: https://habr.com/ru/company/pvs-studio/blog/331724
2. Чернышова А.В., Мазалов Р.А. Интегрируемый статический анализ для программного проекта с использованием архитектурного стиля REST // III Международная научно-практическая конференция Программная инженерия: методы и технологии разработки информационно-вычислительных систем (ПИИВС-2020). — Донецк, 2020. — С.125–128.
3. Maurice H. Halstead. Elements of Software Science [Text] : Elsevier. — 1st ed. — New York : Elsevier, 1977. — 127 pp. : illus.
4. T. J. McCabe. A complexity measure [Text] : IEEE. — 1st ed. — New York : IEEE, 1976. — 308–320 pp.
5. Hansen, W. J. Measurement of Program Complexity By the Pair (Cyclomatic Number, Operator Count) [Text] : ACM SIGPLAN Not.– vol. 13 no. 3 — New York : ACM SIGPLAN Not., 1978.– 29–33 pp.
6. Victor R. Basili, Richard W. Selby. Comparing the effectiveness of software testing strategies. [Text] / Victor R. Basili and Richard W. Selby // IEEE Transactions on Software Engineering., 1987. — p. 1278–1296
7. Norman E. Fenton. Software Metrics: A Rigorous Approach [Text] : Chapman & Hall. — 1st ed. — London : Chapman & Hall, 1992.
8. S. Henry, D. Kafura. Software structure metrics based on information flow. [Text] / S. Henry and D. Kafura // IEEE Transactions on Software Engineering,, 1981. — p. 510–518
9. Diana Sidarkeviciute. Program analysis and visualisation: Towards a declarative approach. [Text] / Diana Sidarkeviciute // Informatica., 1997. — p. 153–175
10. P. Young, Malcolm Munro. Visualising software in virtual reality. [Text] / CP. Young, Malcolm Munro // In Proceedings of the IEEE 6th International Workshop on Program Comprehension / IEEE Computer Society. — Ischia, 1998. — p. 19–26
11. Щелоков С.А. Проектирование распределенных информационных систем [Текст] : курс лекций по дисциплине «Проектирование распределенных информационных систем» / С.А. Щелоков, Е.Н. Чернопрудова; Оренбургский гос. ун-т. — Оренбург : ОГУ, 2012. — 195 с. : ил.
12. Крищенко В.А., Горин С.В. Поддержка разработки распределенных приложений в Microsoft .NET Framework [Текст] : 2 изд. — М. : Национальный Открытый Университет ИНТУИТ", 2016. — 249 с. : ил.
13. Fieldling R.T. Architectural Styles and the Design of Network-based Software Architectures. Master’s thesis. University of California, Irvine, 2000. https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
14. Mazalov R.A., Chernyshova A.V., Gilmanova R.R. Overview of REST architectural style // VI Международная научно-техническая конференция Современные информационные технологии в образовании и научных исследованиях (СИТОНИ-2019). — Донецк, 2019. — С.442–448.
15. Continuous Integration для новичков [Электронный ресурс] / Что такое CI // Habr. — Электрон. дан. — 2018. — Режим доступа: https://habr.com/ru/post/352282. — Загл с экрана.
16. Какая разница между Continuous Delivery, Continuous Deployment и Continuous Integration [Электронный ресурс] / Continuous deployment(непрерывное развёртываение) // Qaat. — Электрон. дан. — 2017. — Режим доступа: https://qaat.ru/kakaya-raznica-mezhdu-continuous-delivery-continuous-deployment-i-continuous-integration. — Загл с экрана.
17. Github: Where the world builds software [Электронный ресурс] / Github // Github. — Электрон. дан. — 2020. — Режим доступа: https://github.com. — Загл с экрана.
18. The first single application for the entire DevOps [Электронный ресурс] / Gitlab // Gitlab. — Электрон. дан. — 2020. — Режим доступа: https://gitlab.com. — Загл с экрана.
19. Описание формата CSV // FilesReview [Электронный ресурс]. — Режим доступа: https://filesreview.com/ru/info/csv
20. What is HTML? // W3C HTML [Electronic resource]. — Mode of access: https://www.w3.org/html/
21. HTTP [Электронный ресурс] / Определение // MDN. — Электрон. дан. — 2020. — Режим доступа: https://developer.mozilla.org/ru/docs/Web/HTTP. — Загл с экрана.
22. Работа с JSON [Электронный ресурс] / Определение // MDN. — Электрон. дан. — 2020. — Режим доступа: https://developer.mozilla.org/ru/docs/Learn/JavaScript/Объекты/JSON. — Загл с экрана.
23. Подписываем данные: HMAC на практике в API и Web-формах [Электронный ресурс] / Определение // Habr. — Электрон. дан. — 2015. — Режим доступа: https://habr.com/ru/post/262341. — Загл. с экрана.
24. About webhooks [Electronic resource] / Learn the basics of how webhooks work to help you build and set up integrations // Github Docs. — 2020. — Mode of access: https://docs.github.com/en/free-pro-team@latest/developers/webhooks-and-events/about-webhooks
25. Пошагово объясняем, как работает алгоритм хеширования SHA-2 (SHA-256) [Электронный ресурс] / Определение SHA-2 // Tproger. — Электрон. дан. — 2020. — Режим доступа: https://tproger.ru/translations/sha-2-step-by-step. — Загл с экрана.
26. Blob [Электронный ресурс] / Определение // MDN. — Электрон. дан. — 2020. — Режим доступа: https://developer.mozilla.org/ru/docs/Web/API/Blob. — Загл с экрана.
27. Кодирование и декодирование в формате Base64 [Электронный ресурс] / Определение Base64 // MDN. — Электрон. дан. — 2020. — Режим доступа: https://developer.mozilla.org/ru/docs/Web/API/WindowBase64/Base64_encoding_and_decoding. — Загл с экрана.