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

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

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

РОЗДІЛ 2

Проектування інформаційної системи

2.1. Аналіз і автоматизація інформаційних потоків мобільного додатку

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

Основними інформаційними об'єктами автоматизованої системи продажу квитків є:

- клієнт(користувач додатку);

- сервер(хмарне сховище);

- смартфон(iPhone);

- мобільний додаток;

- сервіс авторизації(OAuth).

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

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

В області розробки програмного забезпечення використовується спеціальна мова для графічного опису об'єктного моделювання - мова UML (Unified Modeling Language). При опису роботи програми створена абстрактна модель системи або підсистеми, звана UML- моделлю.

Рис. 2.1 Загальна модель діяльності користувача та хмарного сховища

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

- користувач реєструється на сервері, сервер зберігає інформацію про користувача;

- користувач робить запит(одержання списку файлів, відправку, видалення, завантаження файлу), сервер обробляє запит та повертає результат.

Рис. 2.2 Функціональна схема роботи додатку

2.1.1. Використання OAuth 2.0 для доступу до API

Якщо додаток відразу відправить запити до API сервер поверне помилку додатку, бо не було здійснено авторизацію самого додатку.

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

Маркери доступу видаються сторонніх клієнтів, сервера авторизації з твердження власника ресурсу. Клієнт використовує маркер доступу до доступу до захищених ресурсів, розміщених на сервері ресурсів. Наприклад, кінцевий користувач (власник ресурсу) може надати друк Послуги (клієнт) доступ до її захищені фотографії зберігаються в фото обміну послуги (сервер ресурсу), не розділяючи її ім'я і пароль зі службою друку. Замість цього, вона виконує автентифікацію безпосередньо з сервером довіреної службою обміну фотографіями (Сервер авторизації), який видає служби друку delegation - конкретні облікові дані (маркер доступу).

Рис. 2.3 Використання OAuth 2.0 для доступу до API

Абстрактний OAuth 2.0 потік показано на малюнку 1.1 описує Взаємодія між чотирма ролями і включає в себе наступні кроки:

- клієнт запитує дозвіл від власника ресурсу. Запит авторизації може бути зроблено безпосередньо на власника ресурсу (Як показано), або переважно побічно через авторизації Сервер в якості посередника;

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

- клієнт запитує маркер доступу, автентифікації з Сервер авторизації та подання грант авторизації;

- сервер авторизації автентифікацію клієнта і перевіряє давати дозвіл, і якщо діє, видає маркер доступу;

- клієнт запитує захищений ресурс з ресурсом Сервер і аутентифікацію по представляючи маркер доступу;

- сервером ресурсів перевіряє маркер доступу, і якщо діє, служить запит.

2.1.2. Аналіз активності додатку

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

Рис. 2.4 Діаграма активності