Будь ласка, використовуйте цей ідентифікатор, щоб цитувати або посилатися на цей матеріал:
https://er.chdtu.edu.ua/handle/ChSTU/9032| Назва: | Особливості проектування WEB додатку та дослідження можливостей шаблону проектування |
| Автори: | Куницька, Світлана Юріївна Данилюк, Богдан Анатолійович |
| Ключові слова: | АВТОМАТИЗОВАНА ІНФОРМАЦІЙНА СИСТЕМА;WEB-ДОДАТОК;RUBY ON RAILS;ПРОГРАМНИЙ ПРОДУКТ;ПАТЕРН MODEL-VIEW-CONTROLLER;AUTOMATED INFORMATION SYSTEM;WEB- ADDITION;RUBY ON RAILS;SOFTWARE PRODUCT;MODEL-VIEW-CONTROLLER PATTERN |
| Дата публікації: | 16-гру-2021 |
| Короткий огляд (реферат): | АНОТАЦІЯ
Метою кваліфікаційної роботи магістра є підвищення ефективності ведення сімейного бюджету за рахунок створення сучасних інструментів обліку та аналізу особистих і сімейних фінансів та їх реалізації у додатку, що дозволяє перегляд фінансового стану сім'ї у простому інтерфейсі зрозумілому усім віковим категоріям населення та керування фінансовими операціями по забезпеченню стабільності сімейного бюджету.
Об'єкт дослідження - проектування автоматизованої інформаційної системи фінансового ведення бюджету.
Предмет дослідження – методи та інструменти керування автоматизованої інформаційної системи, контролерів, модулів, реляційних баз даних та алгоритмів автоматизованої інформаційної системи.
У першому розділі проаналізовано обрану предметну область, виявлено технічну проблему, яка потребує розв'язання, принципу побудови автоматизовано-інформаційної системи, а також наведено особливості класифікації Web-додатків та визначено, до якого виду належить додаток, що розробляється. Проведено варіантний аналіз засобів та обґрунтовано вибір фреймворку для вдосконалення інструментів керування автоматизованої інформаційної системи ведення сімейного бюджету.
Другий розділ містить аналіз принципів розробки Web-додатків, особливостей розробки бази даних контролерів, моделей, вигляду та міграцій. Для реалізації системи розроблено патерн Model-View-Controller для вдосконалення інструментів керування автоматизованої інформаційної системи, структуру бази даних Web-додатку.
Третій розділ наводить методи тестування та результати тестування розробленої автоматизованої інформаційної системи. Проведене тестування підтвердило ефективність і правильність функціонування розробленої автоматизованої інформаційної системи ведення сімейного бюджету обліку.
У додатки винесено, лістинг коду основних частин розробленого програмного забезпечення та результати дослідження.Програмний продукт розроблений за допомогою об’єктно-орієнтованої мови програмування Ruby on Rails. Використаний шаблон проектування Model-View-Controller, головною перевагою якого є розділення коду інтерфейсу користувача і іншого коду.
Пояснювальна записка містить 113 сторінок. У кваліфікаційній роботі застосовано 32 рисунки, 5 таблиць та 3 додатки з представленою в них програмою і графічним матеріалом. Для виконання роботи використано 20 літературних джерел. ABSTRACT The purpose of the master's qualification work is to increase the efficiency of family budgeting by creating modern tools for accounting and analysis of personal and family finances and their implementation in the application, which allows viewing the financial condition of the family in a simple interface understandable to all ages and managing financial transactions stability of the family budget. The object of study - the design of an automated information system of financial budgeting. The subject of research - methods and tools for control of automated information system, controllers, modules, relational databases and algorithms of automated information system. The first section analyzes the selected subject area, identifies a technical problem that needs to be solved, the principle of building an automated information system, as well as features of the classification of Web-applications and determines what kind of application is being developed. The variant analysis of means is carried out and the choice of a framework for perfection of tools of management of the automated information system of conducting the family budget is proved. The second section contains an analysis of the principles of Web-application development, features of database controller development, models, appearance and migrations. To implement the system, the Model-View-Controller pattern was developed to improve the control tools of the automated information system, the structure of the Web-application database. The third section provides testing methods and test results of the developed automated information system. The conducted testing confirmed the efficiency and correct functioning of the developed automated information system for keeping the family budget. In the application contains a listing of the code of the main parts of the developed software and the results of the study. The software product is developed using the object-oriented programming language Ruby on Rails. The Model-View-Controller design template is used, the main advantage of which is the separation of user interface code and other code. The explanatory note contains 113 pages. In the qualifying work used 32 figures, 5 tables and 3 appendices with the program presented in them. 20 literary sources were used to perform the work. |
| URI (Уніфікований ідентифікатор ресурсу): | https://er.chdtu.edu.ua/handle/ChSTU/9032 |
| Розташовується у зібраннях: | 121 Інженерія програмного забезпечення (Інженерія програмного забезпечення) |
Файли цього матеріалу:
| Файл | Опис | Розмір | Формат | |
|---|---|---|---|---|
| Кваліфікаційна робота магістра Данилюк Богдан Анатолійович.pdf Restricted Access | 2.92 MB | Adobe PDF | Переглянути/Відкрити Запит копії |
Усі матеріали в архіві електронних ресурсів захищено авторським правом, усі права збережено.
Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ АВТОМАТИЗОВАНИХ
СИСТЕМ
Пояснювальна записка
до кваліфікаційної роботи магістра
на тему: «Особливості проектування WEB-додатку та дослідження
можливостей шаблону проектування»
Виконав: студент 2 курсу групи МПЗ-2004
Напряму підготовки:
121 «Інженерія програмного забезпечення»
Богдан ДАНИЛЮК
Керівник
к.т.н., доцент Світлана КУНИЦЬКА
Рецензент
к.т.н., старший викладач кафедри
інформаційних технологій ЧНУ
ім. Б. Хмельницького Тетяна СТАБЕЦЬКА
Черкаси 2021 року
Форма № Н-9.01
Черкаський державний технологічний університет
Факультет Інформаційних технологій і систем
Кафедра Програмного забезпечення автоматизованих систем
Освітньо-кваліфікаційний рівень Магістр
Напрям підготовки 121 – Інженерія програмного забезпечення
Освітня програма Інженерія програмного забезпечення
ЗАТВЕРДЖУЮ
Завідувач кафедри _______ Станіслав ПЕРВУНІНСЬКИЙ
“_____” ________________ 2021 року
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Данилюку Богдану Анатолійовичу
(прізвище, ім‘я, по батькові)
1. Тема роботи «Особливості проектування WEB-додатку та дослідження
можливостей шаблону проектування»
Керівник роботи к.т.н., доцент Куницька Світлана Юріївна
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «21» вересня 2021 р. № 288/01
2. Строк подання студентом роботи 10 грудня 2021 року
3. Вихідні дані до роботи:
- реляційна база даних;
- патерн Model-View-Controller;
- Засоби SQLITE;
- Мова програмування Ruby on Rails.
4. Зміст розрахунково-пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
Розділ 1 Проектування інформаційної системи
Розділ 2 Особливості роботи програмного продукту
Розділ 3 Дослідження та вдосконалення інформаційної системи
Висновки
Список використаних джерел
Додатки
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів):
Додаток А - Специфікація
Додаток Б – Текст програми
Додаток В – Графічний матеріал
6. Консультанти розділів роботи
Підпис, дата
Прізвище, ініціали та
Розділ
посада завдання видав завдання прийняв
консультанта
7. Дата видачі завдання 21.09.2021 р.
КАЛЕНДАРНИЙ ПЛАН
Строк виконання
№ з/п Назва етапів дипломного проекту (роботи) Примітка
етапів роботи
1 Затвердження теми роботи 21.09.2021 виконано
2 Постановка задач 22.09-20.10 виконано
3 Обґрунтування актуальності виконання 21.10-31.10 виконано
досліджень
4 Оцінка стану проблеми, виокремлення 01.11-10.11 виконано
дослідницьких задач, постановка задачі
дослідження
5 Викладення результатів дослідження 11.11-15.11 виконано
6 Практичне застосування результатів 16.11-25.11 виконано
дослідження
7 Оформлення результатів в пояснювальну 26.11-08.12 виконано
записку
8 Подання роботи на рецензування 09.12.2021 виконано
9 Подання роботи на відгук 10.12.2021 виконано
Студент-магістрант ____________________________ Богдан ДАНИЛЮК
(підпис)
Керівник роботи ____________________________ Світлана КУНИЦЬКА
(підпис)
АНОТАЦІЯ
Метою кваліфікаційної роботи магістра є підвищення ефективності
ведення сімейного бюджету за рахунок створення сучасних інструментів
обліку та аналізу особистих і сімейних фінансів та їх реалізації у додатку, що
дозволяє перегляд фінансового стану сім'ї у простому інтерфейсі
зрозумілому усім віковим категоріям населення та керування фінансовими
операціями по забезпеченню стабільності сімейного бюджету.
Об'єкт дослідження - проектування автоматизованої інформаційної
системи фінансового ведення бюджету.
Предмет дослідження – методи та інструменти керування
автоматизованої інформаційної системи, контролерів, модулів, реляційних
баз даних та алгоритмів автоматизованої інформаційної системи.
У першому розділі проаналізовано обрану предметну область, виявлено
технічну проблему, яка потребує розв'язання, принципу побудови
автоматизовано-інформаційної системи, а також наведено особливості
класифікації Web-додатків та визначено, до якого виду належить додаток, що
розробляється. Проведено варіантний аналіз засобів та обґрунтовано вибір
фреймворку для вдосконалення інструментів керування автоматизованої
інформаційної системи ведення сімейного бюджету.
Другий розділ містить аналіз принципів розробки Web-додатків,
особливостей розробки бази даних контролерів, моделей, вигляду та
міграцій. Для реалізації системи розроблено патерн Model-View-Controller
для вдосконалення інструментів керування автоматизованої інформаційної
системи, структуру бази даних Web-додатку.
Третій розділ наводить методи тестування та результати тестування
розробленої автоматизованої інформаційної системи. Проведене тестування
підтвердило ефективність і правильність функціонування розробленої
автоматизованої інформаційної системи ведення сімейного бюджету обліку.
У додатки винесено, лістинг коду основних частин розробленого
програмного забезпечення та результати дослідження.
Програмний продукт розроблений за допомогою об’єктно-орієнтованої
мови програмування Ruby on Rails. Використаний шаблон проектування
Model-View-Controller, головною перевагою якого є розділення коду
інтерфейсу користувача і іншого коду.
Пояснювальна записка містить 113 сторінок. У кваліфікаційній роботі
застосовано 32 рисунки, 5 таблиць та 3 додатки з представленою в них
програмою і графічним матеріалом. Для виконання роботи використано 20
літературних джерел.
Ключові слова: АВТОМАТИЗОВАНА ІНФОРМАЦІЙНА СИСТЕМА,
WEB-ДОДАТОК, RUBY ON RAILS, ПРОГРАМНИЙ ПРОДУКТ, ПАТЕРН
MODEL-VIEW-CONTROLLER.
ABSTRACT
The purpose of the master's qualification work is to increase the efficiency
of family budgeting by creating modern tools for accounting and analysis of
personal and family finances and their implementation in the application, which
allows viewing the financial condition of the family in a simple interface
understandable to all ages and managing financial transactions stability of the
family budget.
The object of study - the design of an automated information system of
financial budgeting.
The subject of research - methods and tools for control of automated
information system, controllers, modules, relational databases and algorithms of
automated information system.
The first section analyzes the selected subject area, identifies a technical
problem that needs to be solved, the principle of building an automated
information system, as well as features of the classification of Web-applications
and determines what kind of application is being developed. The variant analysis
of means is carried out and the choice of a framework for perfection of tools of
management of the automated information system of conducting the family budget
is proved.
The second section contains an analysis of the principles of Web-application
development, features of database controller development, models, appearance and
migrations. To implement the system, the Model-View-Controller pattern was
developed to improve the control tools of the automated information system, the
structure of the Web-application database.
The third section provides testing methods and test results of the developed
automated information system. The conducted testing confirmed the efficiency and
correct functioning of the developed automated information system for keeping the
family budget.
In the application contains a listing of the code of the main parts of the
developed software and the results of the study.
The software product is developed using the object-oriented programming
language Ruby on Rails. The Model-View-Controller design template is used, the
main advantage of which is the separation of user interface code and other code.
The explanatory note contains 113 pages. In the qualifying work used 32
figures, 5 tables and 3 appendices with the program presented in them. 20 literary
sources were used to perform the work.
Keywords: AUTOMATED INFORMATION SYSTEM, WEB-
ADDITION, RUBY ON RAILS, SOFTWARE PRODUCT, MODEL-VIEW-
CONTROLLER PATTERN.
ЗМІСТ
ВСТУП…………………………………………………………………….…...….4
РОЗДІЛ 1 ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ………………10
1.1 Обґрунтування необхідності проектування аналітично-інформаційної
системи …………………………………………………………………………..10
1.2 Визначення можливостей спроектованої системи …………..………...12
1.3 Вибір оформлення та адаптивності дизайну ………………….….….…13
1.4 Особливості проектування інформаційної системи……………………18
Висновки до першого розділу ……………………………….………….…..23
РОЗДІЛ 2 ОСОБЛИВОСТІ РОБОТИ ПРОГРАМНОГО ПРОДУКТУ……....24
2.1 Характеристика мови Ruby on Rails для програмування інформаційної
системи………………………………………………………………………...…24
2.2 Використання фреймворку Ruby on Rails та Bootstrap ….…...………..25
2.3 Вибір інструментальних засобів програмування Sublime Text …….…27
2.4 Опис встановлення автоматизованої інформаційної системи на
локальний сервер ………………………………………………………………..28
2.5 Особливості проектування реляційної структури моделі..……………31
2.6 Особливості побудови зв’язків між табличними даними……………..36
2.7 Можливість змінювати схему бази даних за допомогою Active
Record…………………………………………………………………………….42
2.8 Використання шаблону проектування для створення системи……….43
2.9 Проектування Моделей для створення системи…………………….…45
2.10 Проектування Контролерів для створення системи………………….51
2.11 Проектування Вигляд для створення системи………………………..56
Висновки до другого розділу ………………………………..…………......61
РОЗДІЛ 3 ДОСЛІДЖЕННЯ ТА ВДОСКОНАЛЕННЯ ІНФОРМАЦІЙНОЇ
СИСТЕМИ ………………………………………………………….…………... 62
3.1 Основні аспекти та оцінка працездатності системи ………………...…62
3.2 Функціональне тестування системи……...……….………………….... 66
3.3 Структурне тестування програмного продукту …………………….…70
3.4 Регресійне тестування (REGRESSION TESTING)……………………..77
3.5 Подання звітів про тестування…………………………………………..83
Висновки до третього розділу ..……………………………...……….….…85
ВИСНОВКИ ………………………………………………………….….….…...87
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ…..…………………………………...89
ВСТУП
Актуальність теми. Стрімкий розвиток мережі інтернет, яка на
сьогоднішній день обєднала майже всю земну кулю спричинив активний
розвиток web-технологій. Усі технології вдосконалюються для того щоб
забезпечити стабільну та продуктивну роботу мереж, а також надати своїм
користувачам зручні інтерфейси роботи з мережевими додатками.
З появою Web-технологій виділяють дві важливі типові групи. З одного
боку, це керівники крупних організацій, президенти банків, топ-менеджери,
впливові державні чиновники і, звичайно, з іншого боку, це представники
найширших верств населення – це прості користувачі, домогосподарки,
пенсіонери, діти, студенти.
Web-технологія обєднала можливості роботи та інформації. І такі
достатьо традиційні критерії розвитку обчислювальної техніки, як
продуктивність, пропускна спроможність, ємкість пристроїв, що
запам'ятовують, не враховували головного «вузького місця» системи -
інтерфейсу з людиною. Попередній механізм взаємодії людського
потенціалу та можливостей інформаційної системи стримував розвиток
нових технологій. І тоді, коли зрозумілий за видом та дією інтерфейс був
спрощений до легкого сприйняття людиною, відбувся зрозумілий ріст
інтересу до можливостей будь-якої обчислювальної техніки.
Також серед різних верств населення стало популярним читати
літературу, газети, журнали на інтернет-сайтах, а також здобувати любу
потрібну інформацію за запитом, а також сортувати її за необхідністю. Все
більше та активніше читаємо інтернет-книги та знайомимось з новинами у
світі, залишаючись на робочому місці.
Сьогодні у інформаційному світі майже кожен користувач має свій
малий куток: власний сайт, власна сторінка у соціальних мережах. Але
розвиток мобільні телефони та планшети насамперед краща ніж
використання стаціонарних комп’ютерів і ноутбуків особливо для верств
населенняя, що подорожує.
"World Wide Web" - це саме велике сховище інформації у електронній
формі, яке забезпечить гідну інформаційну підтримку існуючих проблем з
зберіганням інформації чи бізнесу.
Автоматизована інформаційна система - це реалізований в мережі
Інтернет Web-додаток, шляхом створення Web-сервера для послуг ведення
сімейного бюджету. Переваги цієї системи перед паперовими носіями тим що
облік фінансів можна вносити як з комп’ютера, так і зі смартфону з доступом
в Інтернет. А розроблений програмний продукт по керуванню
автоматизованої інформаційної системи наділено основними вимогами до
сучасного прогресивного web-розробника: постійно навчатись новому,
розуміти принципи актуальних парадигм програмування, працювати із
сучасними базами даних, а при використанні фреймворків знати і розуміти
прикладний програмний й інтерфейс фреймворку [].
Метою кваліфікаційної роботи магістра є підвищення ефективності
фінансового ведення сімейного бюджету за допомогою створення сучасних
інструментів обліку та аналізу особистих і сімейних фінансів та їх реалізації
у додатку, що дозволяє перегляд фінансового стану сім'ї у простому
інтерфейсі зрозумілому усім віковим категоріям населення та керування
фінансовими операціями по забезпеченню стабільності сімейного бюджету.
Постановка проблеми.
Правильне використання сучасних мов програмування та сучасний
прикладний програмний інтерфейс по керуванню фреймворку дозволяє
створювати інструменти обліку та аналізу особистих фінансів нашої
автоматизованої системи. У багатьох випадках, персональна бухгалтерія
допомагає вирішити і проблему з обліком доходів, витратами, боргами і
кредитами та іншими фінансовими потребами користувача.
З огляду на вище написане було виділено основні задачі, що
вирішуються при розробці автоматизованої аналітично-інформаційної
системи наступні:
1. Проектування реляційної бази даних для
автоматизованої інформаційної системи.
2. Розробка моделей, контролерів, виглядів та
інструментів по вдосконаленню роботи інформаційної системи
для ведення сімейного бюджету за рахунок сучасних технологій
та простоти інтерфейсу.
3. Дослідження програмного продукту методами
тестування автоматизованої інформаційної системи.
Об'єкт дослідження - проектування автоматизованої інформаційної
системи фінансового ведення бюджету.
Предмет дослідження – методи та інструменти керування
автоматизованої інформаційної системи, контролерів, модулів, реляційних
баз даних та алгоритмів автоматизованої інформаційної системи.
Методологічна основа і методи дослідження. У процесі дослідження
використовувалися: методи розробки автоматизованої інформаційної
системи під усі браузери, методи роботи з базою даних SQLite, методи
створення контролерів, модулів і вигляду, методи передачі даних при
синхронізації локальної і серверної бази даних, методи створення графічного
представлення даних.
В наш час стає поширеним застосовувати для управління сімейним
бюджетом різні сучасні технології: спеціально розроблені програми для
персонального комп'ютеру, куди ви вносите свої дані по грошовим доходам і
витратам. Програмний продукт, що було розроблено під час виконання
кваліфікаційної роботи, представлено як універсальну автоматизовану
інформаційну систему засобами дослідження та вдосконалення інструментів
керування аналітично-інформаційної системи.
Короткий огляд літературних джерел з даної тематики.
Сьогодні у інформаційному світі майже кожен користувач має свій
малий куток: власний сайт, власна сторінка у соціальних мережах. Розробка
web-додатків (сюди в першу чергу можна віднести браузерні додатки) на
сьогодні являється чи не найперспективнішим напрямом для молодого
спеціаліста, який прагне пов'язати своє професійне життя із ІТ-сферою
діяльності у подальшому та розвитатися у цьому напрямку.
За допомогою спроектованого додатку можна не тільки проаналізувати
рівень витрат і доходів, а також спланувати бюджет на певний проміжок
часу, що є дуже досить актуальним для людей з постійним фінансовим
бюджетом.
Для реалізації стистеми розроблено патерн Model-View-Controller для
вдосконалення інструментів керування автоматизованої інформаційної
системи, структуру бази даних Web-додатку [1]. В даному підході до
побудови додатків варто пам’ятати, що модель не повинна містити
відображення на екран, а вигляд маніпуляцій та звернень до моделі (можливі
виключення).
Створення інструментів керування автоматизованої інформаційної
системи є структурованою за принципом дії і, в одночас, складна задача, що
розбивається на підзадачі кожна з яких вирішується окремо. Так за ієрархією
складності йде постійне розбиття на маленькі, але зрозумілі підзадачі, поки е
буде їх при ведення до елементарних. Потім відбувається їх обєднання в
єдиний алгоритм розв'язання вихідної задачі, що і є необхідною умовою
швидкої розробки програмних продуктів [2-5].
Наукова новизна отриманих у процессі розробки результатів полягає
у підвищенні ефективності програмного продукту, що дозволяє вирішувати
питання пов'язані із накопиченням, сортуванням збереженням та аналізом
архівної інформаційної бази спроектованої автоматизованої системи та
вдосконаленням можливостей аналітично-інформаційної системи завдяки
методам та засобам графічного представлення даних.
Наукова новизна одержаних результатів:
− розроблено автоматизовану інформаційну систему
взаємодії багатокористувацького режиму доступу користувача до
аналітичної інформації системи можливостями реляційної бази даних;
− вдосконалено програмного продукту можливостями
сучасних фреймворків з використанням інших розроблених бібліотек
на мові програмування;
− досліджено програмну систему на різнотипові помилки
завдяки методам тестування;
− вдосконалено автоматизовану інформаційну систему
завдяки запропонованій новій організації бази даних, що не
використовує парадигму клієнт-сервер, а надає бібліотеку для
компіляції програмою і тому конвеєр стає складовою частиною
програми, що дозволяє значно підвищювати продуктивність та приріст
швидкості розробки системи визначається великою кількістю готових
до роботи штатних інструментів Ruby on Rails.
Спроектована автоматизована інформаційна система орієнтовна на
використання усіх пристроїв у яких є браузер та призначена для спрощення
ведення та аналізу особистого та сімейного бюджету, внесення доходів та
витрат у режимі реального часу, перегляду та аналізу даних.
Розроблено алгоритми та програмні засоби для вдосконалення
автоматизованої інформаційної системи ведення сімейного бюджету, яка
орієнтовна на використання користувачами будь-якого пристрою де є
браузер.
З усього вищесказаного, можна зробити висновок, що розвиток ринку
інструментів керування автоматизованої інформаційної системи може
задовільнити потреби сучасного користувача шляхом написання програмного
продукту реалізації роботи автоматизованої інформаційної системи [6-9].
Структура. Кваліфікаційна робота магістра має наступну структуру:
вступ, 3 розділи, висновки, спискок використаних джерел та 3 додатки з
отриманими результатами роботи.
В першому розділі було проаналізовано обрану предметну область,
виявлено область дослідження, яка потребує розв'язання, структурним підхід
побудови автоматизованої інформаційної системи, а також наведено
особливості класифікації Web-додатків. Також проведено варіантний аналіз
засобів та обґрунтовано вибір фреймворку для вдосконалення інструментів
керування автоматизованої інформаційної системи ведення сімейного
бюджету.
Для розробки автоматизованої інформаційної системи визначено для
подальшого дослідження існуючі аналоги, відокремлено їх переваги та
недоліки. Також зроблено огляд класифікації таких систем і визначено, що
розроблена система належить до Web-додатку, оскільки вона написана під
усі платформи, які мають браузер та надає користувачу послуги, а саме -
можливість обліку його
фінансового стану. Обґрунтовано обране середовища програмування.
Другий розділ містить аналіз принципів розробки Web-додатків,
особливостей розробки бази даних контролерів, моделей, вигляду та
міграцій. Для реалізації системи розроблено патерн Model-View-Controller
для вдосконалення інструментів керування автоматизованої інформаційної
системи, структуру бази даних Web-додатку. Завдяки використанню різних
елементів управління (серверних і користувацьких), застосуванню каскадних
таблиць стилів і тем оформлення, бутстрапу та простого дизайну вдалося
створити привабливий, функціональний, зручний у використанні і
інтуїтивно-зрозумілий інтерфейс користувача з можливістю швидкої
модернізації у разі потреби. Програмний код додатку завдяки можливості
модифікації та сумісності портативних пристроїв під кросбраузерний режим
дає змогу працювати Web-додатку у будь якому пристрої де існує Web-
браузер та вихід у мережу.
Третій розділ наводить методи тестування та результати тестування
розробленої автоматизованої інформаційної системи. Проведене тестування
підтвердило ефективність і правильність функціонування розробленої
автоматизованої інформаційної системи ведення сімейного бюджету обліку.
У додатки винесено, лістинг коду основних частин розробленого
програмного забезпечення та результати дослідження та графічний матеріал.
РОЗДІЛ 1
ПРОЕКТУВАННЯ ІНФОРМАЦІЙНОЇ СИСТЕМИ
1.1 Обґрунтування необхідності проектування аналітично-
інформаційної системи
Стрімкий розвиток мережі інтернет, яка на сьогоднішній день
об’єднала майже всю земну кулю спричинив активний розвиток web-
технологій. Усі технології вдосконалюються для того щоб забезпечити
стабільну та продуктивну роботу мереж, а також надати своїм користувачам
зручні інтерфейси роботи з мережевими додатками.
Важливим питання введення сімейних витрат належить до правильного
планування бюджету, не хаотичного розподілу та закупки необхідних
продовольчих та непродовольчих. Але, спочатку, необхідно розуміти, що це
також кропітка робота, яка потребує часу, уваги, концентрації і рішучості.
Існує безліч програмних ресурсів, на сьогодні, методів ведення і
планування сімейного бюджету, а також програмних вбудованих програм.
Проте кожен обирає для себе той спосіб, який зручний в розумінні та
введенню, аналізу та збору інфрмації. Цілі по досягненню певної мети,
являють собою якісний показник роботи системи, але критерії такі як
надійність, захищеність, швидкість опрацювання, легкість в розуміння,
візуальне сприйняття середовища роботи, інноваційний підхід,
користувацький інтерфейс також є важливими складовими успіху роботи
інформаційної системи. Тому, звичайно, ці характеристики найточніше
характеризують нашу проектну ціль при розробці.
Захищенність даних це найважливіше питання для користувачів
певного характеру, тому критерію надійності системи надається значна увага
роботи системи з точки зору апаратних та технічних можливостей. Оскільки
спроектована система є довідниково-інформаційною системою, де йде
постійне накопичення свих статей доходів та витрат, то слід врахувати такий
фактор як невідказність роботи системи.
Але у нашому прикладі захищеність стосується як певного
користувача, так і сімї в цілому. Це залежить від прописаного доступу до
входу до тієї чи іншої табличної форми витрат чи доходів. Кожний
користувач має свій власний профіль за допомогою якого він може
працювати у системі. Ця можливість групового або індивідуального
користування надається авторизацією та реєстрацією у системі. Дані
користувача мають бути захищені з середини системи і це дають здійснювати
вхід в базу або в певні форми. Ця персоналізація доступу реалізується
завдяки створеній окремій таблиці даних, що містись всі поля та шляхи
доступу користувачів, так званої “сесії користувача”, середовищем мови
програмування Ruby on Rails. Тобто в загальному розумінні доступ
користувачам до своєї інформації буде лише після авторизації або реєстрації
у системі, що спроектовано у нашій автоматизованій системі.
Швидкість обробки даних впливає на безліч факторів роботи системи.
Якщо ми говоримо про обробку користувацького запиту, то це є
першочерговим значенням при роботі системи. Але є невиключним питання
правильно організованим пріоритетність виконання користувацьких запитів.
Також для повноцінної роботи інформаційної системи потрібно
середовище на виконання. В нашому проекті цю важливу функцію виконує
браузер користувача, а саме Web-переглядач сторінок, але тоді є відкритим
системним питанням сумісності спроектованої системи з іншими носіями.
Проблема кросплатформенності цілком лягає на розсуд користувача.
Ідеальним підходом до розробки було б створити умови для повної реалізації
роботи системи за всіма технічними можливостями та враховуючи апаратну
підтримку. Що значно зменшує виникнення помилок будь-якого характеру в
подальшому при відображенні інформації на сторінках [9-11].
Враховуючи, що головний потенціал зосереджено на використанні
версіях сучасних мов програмування та синхронізації роботи користувача,
ціїє проблемо можливо уникнути. Для програмування ми обрали мову Ruby
on Rails, а створюваний на даному етапі проектування інтерфейс з
використанням особливостей Bootstrap максимально допоможе користувачу.
Всі інформативні дані у системі повинні бути збережені у відповідній
за змістом базі даних на довгий термін, дані особистих профілів, отримані
результати на запити в зберігаються в окремій базі даних, що наділена
SQLite-база даних реляційного типу і вона повністю відповідає потребам
розробки додатку. Зрозумілість у використанні табличних форм та простота
використання бази даних mysql а програмному рівні створює зручний спосіб
її використання.
Задані цілі і дали нам можливість побачити шляхи вирішення завдання
проектування. Оглядаючи всі критерії щодо роботи Web-додатку стає
зрозумілим та точнішим виконання поставленого завдання [12].
Аби досягти поставленої мети роботи необхідно вирішити такий ряд
задач для створення автоматизованої інформаційної системи:
‒ проаналізувати особливості розробки бази даних для Web-додатків;
‒ розробити структуру бази даних;
‒ розробити моделі Web-додатку;
‒ розробити структуру Web-додатку;
‒ розробити базу даних автоматизованої інформаційної системи
ведення сімейного бюджету;
‒ розробити алгоритм функціонування Web-додатку;
‒ розробити інтерфейс;
‒ здійснити програмну реалізацію Web-додатку;
‒ протестувати розроблений програмний продукт.
1.2 Визначення можливостей спроектованої системи
Головні функції програмного продукту, що необхідно застосувати в
спроектованій автоматизованій інформаційній системі для ведення сімейного
обліку представлені нижче:
‒ комфортна форма для підрахунку доходів і витрат;
‒ зручний перегляд для ведення статистики у вигляді діаграм;
‒ розподіл доходів і витрат за категоріями і групами;
‒ створення табличних форм реляційної бази даних;
‒ здатність програмного продукту імпортувати та експортувати дані;
‒ наявність різних додаткових інструментів (нагадування про подію);
‒ якісна система захисту даних і синхронізація з усіма пристроями.
Основна перевага автоматизованої системи полягає в універсальності
та багатокористувацькому доступі до інформаційної системи, а саме: усі
користувачі можуть легко користуватися Web-додатком, переглянути каталог
та зробити запис, якщо є вихід до мережі Інтернет при наявності пристрою у
якого є браузер, що є дуже зручним для користувача.
Програмний продукт що було розроблено під час виконання даної
кваліфікаційної роботи це, насамперед, просте та лаконічне керування
автоматизованою інформаційною системою. Основними вимогами до
сучасного прогресивного web-розробника є бажання постійно навчатись
чомусь новому, розуміти принципи актуальних парадигм програмування,
працювати із сучасними системами баз даних, при використанні фреймворків
знати і розуміти API фреймворку [13].
1.3 Вибір оформлення та адаптивності дизайну
Кольори відіграють велике значення в кожному аспекті нашого життя і
нерідко описують більше, як слова. Аналогічно, кольори відіграють важливу
роль при розробці Web-сайту. Часто можна спостерігати, що сайт,
незважаючи на великий функціонал і контент не в змозі залучити і втримати
своїх відвідувачів. І це можливо через невідповідність кольорового дизайну
сайту по його призначенню. Тому проектувальник повинен правильно
підібрати набір кольорів і врахувати можливість їх поєднання з іншими
елементами Web-дизайну при розробці сайту. Перед вибором кольорів варто
враховувати різні фактори і для цього необхідне розуміння кольорів і їх
значення.
Оформлення сайту повинно відповідати його тематиці. Якщо це
серйозний корпоративний сайт, то не варто робити його строкатим і
застосовувати дуже яскраві кольори, він повинен бути строгим, лаконічним. І
навпаки, якщо сайт присвячено організації свят, то тьмяне оформлення
навряд чи надихне потенційного клієнта.
Окрім відповідності сайту до тематики, дизайн повинен бути
побудований так, щоб не порушувати основні закономірності впливу
кольорів на психологічну реакцію організму. Вона має відповідати стійким
гармонійним поєднанням кольорів.
Існують певні закономірності для вибору дизайну:
‒ кольори повинні відповідати фірмовому стилю;
‒ комбінація кольорів має відповідати аудиторії даного сайту;
‒ не варто використовувати велику кількість кольорів;
‒ кольори повинні гармоніювати між собою;
‒ потрібно забезпечити контраст між фоном і звичайним текстом;
Колір в дизайні є доволі суб'єктивною категорією. У однієї людини він
може збудити одні відчуття, а в іншої – абсолютно протилежні. Іноді
сприйняття залежить від особливостей, іноді – від культурних традицій
оточення. Теорія кольору це давня і глибока наука. Деякі фахівці роблять
кар'єру, вивчаючи питання, що пов'язані з впливом кольору на індивідуумів і
групи людей. І там дійсно є що досліджувати. Елементарна зміна відтінку або
насиченості кольору може спровокувати абсолютно несподівані емоції.
В світі дизайнерів однією з головних помилок при проектуванні
дизайну сайту є некоректне використання колірної гамми. Невміло підібрана
колірна палітра свідчить про непрофесійність дизайнера [14].
При підборі колірної гамми необхідно враховувати, що сайт буде
переглянуте великою кількістю людей з своїми поглядами і смаками.
До найбільш поширених кольорів у Web-дизайні відносять (рисунок
1.1):
‒ червоний – потужний колір, позначає сильні емоції пристрасті,
азарту, любові, енергії; стимулює тіло і розум. Використовується,
щоб привернути увагу і спонукає користувача до швидшого
прийняття рішення. У Web-дизайні досить популярний і
використовується для виділення певних елементів, посилюючи до
них увагу відвідувача;
‒ чорний – колір, який найчастіше використовується для оформлення
текстового контенту. Він підтримує витонченість, формальність і
елегантність і може бути використаним на будь-якому сайті;
‒ синій з його королівським закликом і спокійним ефектом є
хорошим кольором для Web-дизайну. Його поєднання з іншими
кольорами, наприклад з червоним, жовтим, зеленим, надає бажаний
ефект. Це найкращий колір для сайтів;
‒ зелений – колір природи, росту, достатку і злагоди. Він є
найкращим для рекламування природніх чи органічних товарів на
сайті. Для сайтів про здоров’я доречним буде саме цей колір;
‒ сірий – надає відчуття зрілості, серйозності, поміркованості,
професіоналізму і якості. Він з успіхом може бути використаним
для відображення саме цих якостей на сайті;
‒ коричневий – вважається земним, природнім, простим кольором.
Він передає відчуття надійності, корисності і консерватизму. З
іншої сторони він сприймається трохи скучно, але його можна
комбінувати з більш яскравими кольорами. Цей колір також
пов’язується з старовинними фотографіями, матеріалами і може
застосовуватися для навіювання ностальгії;
‒ жовтий – хоча колір і асоціюється з енергією, яскравістю,
обачністю, щастям і застосовується для захоплення уваги, але варто
бути з ним обережним, оскільки зловживання призводить до
негативних результатів. Надмірне його застосування не є приємним
для відвідувача, що може його відштовхнути;
‒ оранжевий – теплий, яскравий колір, який асоціюється з енергією і
яскравістю. Хоча він і менш агресивний, як червоний, але також
використовується для привертання уваги і виділення важливих
областей дизайну. Оранжевий без крику робить серйозний виклик.
Оранжевий часто передає відчуття дружелюбності, а в умілих руках
може зберегти серйозність і професіоналізм;
‒ фіолетовий - зазвичай асоціюється з таємницею і духовністю, а
глибокий фіолетовий – з процвітанням, багатством, роялті і
благородством. Досить сильний колір, який в обережному
використанні може забезпечити хороший контакт на сайт;
‒ білий - добре поєднується з будь-яким кольором і асоціюється з
чистотою, невинністю, добротою. І твердження, що біле є скучним
у Web-дизайні – помилкове.
Рисунок 1.1 - Найкращі кольори для вибору дизайну
Кольори фону і основного тексту повинні бути контрастними. Чим
текст контрастніше, тим він краще сприймається. Щоб кольори з їх
ефективністю викликали бажану реакцію відвідувачів, варто враховувати
наступні чинники:
При виборі кольорової гами Web-сайту дуже важливо знати правлення і
потреби користувацької аудиторії.
Кожна культура по своєму трактує кольори. В одному поселені колір
може викликати позитивні емоції, тоді як в іншому він несе негативне
значення. Це впливає на вибір дизайну для сайтів, які обслуговують різні
культури.
Для підвищення візуального сприйняття сайту варто тримати рівновагу
між кольорами фону і тексту. Використання кольорів повинно бути таким,
щоб полегшити читання, зменшити навантаження на зір відвідувачів. В
додаток до цього ще й чіткість також є важливим фактором. Частини сайту,
які вимагають уваги повинні бути виділеними і легко візуалізуватися
користувачами.
Оскільки сайт призначений для всіх, то варто подбати про кольори для
будь-яких користувачів і таку кольорову комбінацію, яка дозволяє легко
читати вміст.
Кольорові комбінації – важливий аспект Web-дизайну і сайт з
правильною комбінацією кольорів дозволить позитивно вплинути на
користувачів.
CSS - це мова, яку використовують для опису сторінок, написаних
мовами розмітки даних. Саме таблиця стилів позиціонується розробниками
як якоїсь єдиної системи подання стилів в електронному документі,
заснованої на використанні спеціальних модулів для відображення.
CSS використовується Web-дизайнерами та відвідувачами Web-
сторінок, щоб визначити кольори, шрифти, верстку та усі аспекти вигляду
сторінки. Одна з головних переваг - можливість розділити зміст сторінки
(або контент, наповнення, зазвичай HTML, XML або подібна мова розмітки)
від вигляду документу (що описується в CSS).
CSS має порівняно простий синтаксис і використовує небагато
англійських слів для найменування різних складових стилю, що складаються
зі списку правил, які в свою черге мають один або більше селектор та блок
визначення оточеного фігурними дужками списку властивостей.
У разі помилки інтерпретації HTML-коду браузером, поганий зв'язок з
сервером, зовнішній файл опису сторінки може не завантажитися, а стиль для
потрібних елементів HTML не буде перевизначено.
CSS надає розробнику електронних документів набагато ширший набір
можливостей роботи з текстовою інформацією, ніж стандартний HTML. Крім
способів виділення тексту (підкреслення, курсив, жирне накреслення, вибір
гарнітури і розмір шрифту), за допомогою засобів CSS можливо змінювати
такі параметри, як міжрядковий інтервал, застосування малих та великих
літер і багато іншого. Також каскадні таблиці стилів CSS принесли багато
нового і помітно розширили функціональність форматування структурних
елементів електронного документа: div, селектори, тощо. Стилі не нагадують
структуру HTML. Вони використовують формат «властивість: значення» і
велика частина властивостей може використовуватися для більшості HTML-
тегів.
Переваги використання таблиці стилів:
‒ код легше підтримувати у подальшому;
‒ код краще оптимізовано для пошукових систем;
‒ правила стилю можна застосовувати до безліч сторінок;
‒ однотипний дизайн;
‒ точність контролю (позиціонування, розмір, поля та ін.);
‒ теги більше не використовуються не за призначенням
(наприклад,<blockquote> для форматування);
‒ немає необхідності в позиціонуванні невидимих картинок;
‒ користувачі можуть переписувати стильові таблиці автора;
‒ прискорення завантаження сайту.
1.4 Особливості проектування інформаційної системи
Будь-який програмний продукт побудований на інформативній базі,
якщо мова йде про нракопичення інформації, про її збереження, сортування,
аналіз чи обробку, але всі вони мають різний характер цільового
призначення, тому й можуть дуже сильно розрізнятися по своїх функціях,
архітектурі, реалізації в залежності від предметної області:
1 Якщо інформаційні системи лише призначені для збору, зберігання і
обробки інформації, то в їх основі лежить середовище зберігання і доступу
до даних.
2 Якщо інформаційні системи розроблені для кінцевого користувача
без певної кваліфікації в сфері застосування обчислювальної техніки то
особливій увазі приділяється простому, зрозумілому у використанні
інтерфейсу, що одразу містить відомі та необхідні для роботи функції, але в
той же час не дає йому можливість виконувати які-небудь зайві дії, без
можливості зміни та структури загальної бази.
Таким чином, при розробці інформаційної системи доводиться
вирішувати дві основні задачі:
‒ завдання розробки бази, призначеної для зберігання інформації;
‒ завдання розробки графічного інтерфейсу користувача клієнтських
застосувань.
З огляду на вище описане, виникає необхідність розглянути
проектування автоматизованої інформаційної системи з огляду на рівні
архітектури бази даних, що необхідно знати при розробки, а саме:
Зовнішній рівень – представлення бази даних з точки зору кінцевих
користувачів (рисунок 1.2):
Рисунок 1.2 – Зовнішнє представлення спроектованої системи
‒ описує ту частину бази даних, яка відноситься до кожного
користувача;
‒ представлення окремого користувача називається зовнішнім
представленням;
‒ зовнішнє представлення – це вміст бази даних, яким його бачить
певний користувач, тобто зовнішнє представлення містить тільки ті
сутності і зв'язки “реального світу”, які необхідні користувачеві;
‒ зовнішнє представлення складається з множини екземплярів
кожного типу зовнішнього запису;
‒ кожне зовнішнє представлення визначається засобами зовнішньої
схеми, яка в основному складається із визначень кожного типу
записів у зовнішньому представленні.
Концептуальний рівень – узагальнююче представлення бази даних,
забезпечує представлення всієї бази даних спроектованої системи (рисунок
1.3):
‒ описує те, які дані зберігаються в базі даних, а також зв'язки, що є
між ними;
‒ рівень містить логічну структуру всієї бази даних;
‒ компоненти:
‒ всі сутності, їх атрибути, зв'язки;
‒ обмеження цілісності даних;
‒ семантична інформація про дані;
‒ інформація про міри безпеки та підтримки цілісності даних.
Рисунок 1.3 – Незалежність даних при концептуальному представленні
Внутрішній рівень – фізичне представлення бази даних (рисунок 1.4).
Будь-яка база даних має стандартний набір функцій системи керування
базами даних, перелічимо їх:
‒ збереження, видача та оновлення даних;
‒ каталог, доступний кінцевим користувачам;
‒ підтримка транзакцій;
‒ служби керування паралельною роботою;
‒ служби відновлення;
‒ служби контролю доступу до даних;
‒ підтримка обміну даними;
‒ служби підтримки цілісності;
‒ служби підтримки незалежності від даних;
‒ допоміжні служби.
Рисунок 1.4 – Взаємозв’язок даних внутрішнього рівня
А також існують стандартні компоненти:
‒ процесор запитів;
‒ диспетчер бази даних;
‒ диспетчер файлів;
‒ препроцесор мови DML;
‒ компілятор мови DDL;
‒ диспетчер словника/каталогу;
‒ модуль контролю прав доступу;
‒ процесор команд;
‒ засоби контролю цілісності;
‒ оптимізатор запитів;
‒ диспетчер транзакцій;
‒ планувальник;
‒ диспетчер відновлення;
‒ диспетчер буферів.
Представимо у графічному вигляді один з компонентів бази даних на
рисунку 1.5.
Рисунок 1.5 – Компоненти диспетчера бази даних
Наша база даних приймає наступного вигляду при врахуванні всіх
перелічених особливостей, функцій, рівнів та компонентів при проектуванні
бази даних (рисунок 1.6).
Рисунок 1.6 - Представлення всієї бази даних спроектованої системи
Висновки до першого розділу
В першому розділі роботи обґрунтовано необхідність проектування
автоматизованої інформаційної системи, розробки реляційної бази даних для
підвищення ефективності та зрозумілості ведення сімейних розрахунків.
Автоматизована інформаційна система - це реалізований в мережі
Інтернет Web-додаток, шляхом створення Web-сервера для послуг ведення
сімейного бюджету. Переваги цієї системи перед паперовими носіями тим що
облік фінансів можна вносити як з комп’ютера, так і зі смартфону з доступом
в Інтернет.
Оформлення сайту повинно відповідати його тематиці, не варто робити
його строкатим і застосовувати дуже яскраві кольори, він повинен бути
строгим, лаконічним, а сам дизайн повинен бути побудований так, щоб не
порушувати основні закономірності впливу кольорів на психологічну
реакцію організму, тобто має відповідати стійким гармонійним поєднанням
кольорів. А завдяки розглянутим в розділі особливостям проектування
інформаційної системи було виділено три рівні проектування з огляду бази
даних на архітектурному підґрунті та виділені основні графічні взаємозв’язки
даних в межах архітектурної будови.
РОЗДІЛ 2
ОСОБЛИВОСТІ РОБОТИ ПРОГРАМНОГО ПРОДУКТУ
2.1 Характеристика мови Ruby on Rails для програмування
інформаційної системи
З точки зору системи типізації, Ruby on Rails є мовою програмування з
динамічною типізацією. Немає необхідності явного визначення типу змінних,
хоча така можливість існує. В разі звернення до змінної, інтерпретатор PHP
трактує її тип відповідно до контексту. За необхідності можливе приведення
змінної до певного типу за допомогою відповідних конструкцій мови. Це
може знадобитись, якщо зважити, що значення змінної можуть трактуватись
по-різному в залежності від її типу. Також можливе визначення типу
відповідної змінної на певному етапі виконання сценарію. Імена змінних
чутливі до регістру символів.
Ruby - це скриптова мова високого рівня для швидкого і зручного
об'єктно-орієнтованого програмування. Вона має незалежно від операційної
системи реалізацію multi, сувору динамічну типізацію, «збирач сміття» та
багато інших можливостей. Ruby близька за особливостями синтаксису до
мови Perl, та за об'єктно-орієнтованим підході до Smalltalk. Також деякі риси
мови взяті з Python, Dylan та CLU.
Кросплатформеність реалізації інтерпретатора мови є повністю
вільною, поширюється з відкритими вихідними текстами, можливістю
копіювання та модифікації. Ruby on Rails - об'єктно-орієнтований
програмний каркас для створення Web-додатків, написаний мовою
програмування Ruby. Мова Ruby on Rails надає каркас модель-
представлення-контролер (Model-View-Controller) для Web-додатків, а також
забезпечує їх інтеграцію з Web-сервером і сервером бази даних. Ruby on Rails
є відкритим програмним забезпеченням і розповсюджується під ліцензією
MIT [15].
Ruby on Rails визначає принципи розробки застосунків:
‒ застосунки не повинні визначати власну архітектуру, оскільки вони
використовують готовий каркас модель-вид-контролер;
‒ мова Ruby дозволяє використовувати нотацію, що легко читається,
для визначення семантики Web-застосунків (таких як відносини між
таблицями в базі даних);
‒ Ruby on Rails надає механізми повторного використання, що
дозволяють мінімізувати дублювання коду у Web-застосунку
(принцип Don'tRepeatYourself — не повторюй себе);
‒ за замовчуванням використовуються угоди по конфігурації, типові
для більшості Web-застосунків (принцип
Conventionoverconfiguration - угоди над конфігурацією). Явна
специфікація конфігурації потрібна тільки в нестандартних
випадках.
2.2 Використання фреймворку Ruby on Rails та Bootstrap
Фреймворк Ruby on Rails - це фреймворк, розроблений на мові
програмування Ruby, що працює завдяки архітектури MVC і є вільним
програмним продуктом.
Мова програмування Ruby не для новачків, і для того щоб навчиться
програмувати на Ruby, програмісту необхідно мати хороші знання інших мов
і досвід програмування. Через це Ruby on Rails програмістом може стати
досвідчений Web-розробник з великим запасом знань, достатній досвід
розробки проектів на будь-яких інших мовах, з розумінням принципів
програмування та прекрасним розумінням Web-розробки в цілому.
Застосування фреймворку Ruby on Rails разом з Ruby, як мови
програмування має достатні переваги. Перш за все це швидкість розробки
проектів, яка зменшується на 30-40 відсотків по відношенню до будь-якої
іншої мови програмування або фреймворку за рахунок вбудованих готових
до роботи штатних інструментів Ruby on Rails наборів готових рішень, які
можна вибрати шаблоном застосувань, і , звичайно, простота програмування.
Доступність та соціальність є характерною особливістю культури Ruby
on Rails. Головним є те, що створені проекти можна легко завантажити та
зберігати для загального огляду створених можливостей. Системи
автентифікації, авторизації, коментування, системи платежів, поштові
розсилки та багато іншого. Це дозволяє впровадити розробки, реалізовані
кимось іншим, протестовані і рекомендовані численним спільнотою
Bootstrap - це насамперед, фреймворк для створення сучасних, крос-
браузерних і стандартизованих інтерфейсів, що легко співпрацює з обраною
мовою програмування. А чітка логічка структура коду HTML, JavaScript і
CSS дає безмежні можливості створювати різні модифікації сайтів з
елементами різного призначення. Створити будь-який web-інтерфейс з
шаблони Bootstrap з точки зору розробника Bootstrap має наступні
можливості:
‒ Bootstrap використовує сучасні можливості HTML і CSS та
можуть не підтримуватися старими версіями браузерів, але
починаючи з версії Bootstrap 2 всі створювані макети з його
допомогою стали адаптивними;
‒ Less є основною перевагою використання Bootstrap з
можливостями динамічна стилів мови, що істотно розширює
можливості CSS. З її допомогою розробники можуть створювати
змінні, вкладені колонки, керувати кольорами. Ці самі властивості
притаманні й Less.
Розглянемо основні інструменти Bootstrap:
‒ сітки - заздалегідь задані розміри колонок, які можна відразу ж
використовувати, наприклад ширина колонки 90px відноситься до
класу .span2, який ми можемо використовувати CSS описі
документа;
‒ шаблони - фіксований чи гумовий шаблон документа;
‒ типографіка - опису шрифтів, визначення деяких класів для
шрифтів таких як код, цитати;
‒ медіа - представляє можливості керування зображеннями та відео;
‒ таблиці - засоби оформлення таблиць, аж до додавання
функціональності для забезпечення можливості сортування;
‒ форми - класи для оформлення не тільки форм, але і деяких подій,
що відбуваються з ними;
‒ навігація - класи оформлення для вкладок, сторінок, меню і панелей
інструментів;
‒ алерти - оформлення діалогових вікон, підказок і спливаючих вікон.
Як і в більшості мов програмування, в Ruby можна використовувати
широкий набір сторонніх бібліотек.
Велика частина з них реалізована у формі гема. RubyGems - менеджер
пакетів Ruby, створений для спрощення процесу створення, поширення і
установки бібліотек (в якомусь сенсі це розподілений пакетний менеджер,
схожий, скажімо, на apt-get, але націлений на Ruby додатки). З версії Ruby 1.8
RubyGems використовуються за замовчуванням, хоча для попередніх версій
його потрібно було встановлювати вручну.
Для розробки компонентів системи довелося встановити наступні
розширення:
gem 'bootstrap-sass', '~> 3.3.6'
gem 'devise'
gem 'carrierwave'
gem 'mini_magick'
gem 'pry'
gem 'chartkick'
gem 'groupdate'
gem 'active_median'
2.3 Вибір інструментальних засобів програмування Sublime Text
Розглянемо швидкий кросплатформений редактор Sublime Text, що
притаманний для початкових текстів програм з підтримкою плагінів, що
розроблені засобами мови програмування Python. Візуальні теми містяться у
редакторі, але з можливістю завантаження додаткових індивідуальних тем.
За розташуванням та наповненням дуже зручно спостерігати весь свій
код в правій частині екрану у вигляді міні-карти та при натисканні
здійснювати навігацію. Існує кілька розташованих режимів екрану, де один з
них включає від 1 до 4 панелей, за допомогою яких можна показувати до
чотирьох файлів одночасно. Free modes, як повноцінний режим зображує
тільки один файл без будь-яких додаткових навколо нього меню.
Sublime Text підтримує велику кількість мов програмування і має
можли-
вість підсвічування синтаксису для C, C ++, C #, CSS, D, Dylan, Erlang,
HTML, Groovy, Haskell, Java, JavaScript, LaTeX, Lisp, Lua, Markdown,
MATLAB, OCaml, Perl, PHP, Python, R, Ruby, SQL, TCL і XML.
На додаток до тих мов програмування, які включені за замовчуванням,
користувачі мають можливість завантажувати плагіни для підтримки інших
мов.
Sublime Text може бути оснащений менеджером пакетів, який дозволяє
користувачеві знаходити, встановлювати, оновлювати і видаляти пакети без
перезавантаження програми. Менеджер підтримує встановлені пакети в
актуальному стані, завантажуючи нові версії з репозиторіїв. Крім того, він
надає команди для активації і деактивації встановлених пакетів.
2.4 Опис встановлення автоматизованої інформаційної системи на
локальний сервер
Обов'язковим, для запуску довідково-інформаційної системи є
локальний сервер та фреймворк. Враховуючи, що Ruby on Rails - один з
найпопулярніших фреймфорків для розробки сайтів і Web-додатків, а мова
програмування Ruby разом з фреймворком Rails значно спрощує процес
розробки розглянемо детальніше процес встановлення за застосування їх для
взаємозв’язку з базою даних. Так як не існує готового пакету з Ruby on Rails,
встановлення та налаштування середовища розробки викликає деякі
труднощі. Завдяки таким засобам як RVM (Ruby Version Manager - менеджер
версій Ruby), встановлення може бути спрощеним [16].
При запуску системи проведемо наступні завантаження:
1 >\curl -L https://get.rvm.io | bash -s stable --rails --autolibs=enabled.
2 Запускаємо rvm>source
3 Шлях до к директорії */.rvm/scripts/rvm.
4 Далі встановлюємо потрібну версію, а саме >source >rvm install
1.9.3 >.
Тепер можна переходити до створення проекту:
1 Створюємо папку two_app, заходимо в неї;
2 Пишемо у термінал >sudo gem install bundler, >rails new two_app.
При створенні проекту будуть згенеровано усі потрібні директорії і
конфігураційні файли у вказаній папці.
Для створення серверу потрібно:
1 Перебуваючи в корені папки з створеним проектом запустити
команду >rails -s, де s - команда запуску серверу;
2 Для запуску консолі набираємо >rails -c, де с- скорочення від
консолі.
Щоб працювати з постгресом, додаємо в кінець файлу Gemfile, який
повинен знаходиться в корені проекту, рядок >gem 'pg' зберігаємо файл і
пишемо далі у терміналі >bundle install.
Створюємо модель >rails g model user. Назву моделі пишемо в однині -
таблиця в базі даних буде у множині. Ця команда створить файли моделі і
міграції в / app / models / user.rb і app / db / migrate /
20130425081208_create_users.rb. всі файли контролерів і моделей мають
розширення .rb, а уявлень - .html.haml (в нашому випадку використання
haml).
За допомогою міграції ми будемо управляти роботою з таблицями та
табличними даними в реляційній базі через консоль, що вельми зручно, так
само вони забезпечують простоту перенесення програми, на інший сервер.
Зберігаємо і пишемо у консоль >rake db:migrate. В результаті дії цієї
команди виконуються всі невиконані методи up з файлів міграцій в
директорії / app / db / migrate /. Всі відомості про стан таблиць можна
подивитися у файлі/ app / db / shema.rb.
У файлі моделі / app / models / user.rb визначаємо поля таблиці, які
будуть доступні для зміни з контролера, в цілях безпеки. Для цього пишемо в
ньому наступне: class User < ActiveRecord::Base attr_accessible :name, :role
end.
До речі, синтаксис haml дуже чутливий до табуляції - їх дуже добре
можна відстежувати в редакторі.
Rails-консоллю: >user = User.new(name:"Test",role:"true") застосовують
для перевірки створених т аблиць на їх функціонування, але за умови не
працюючої програми на цей момент. Щоб перевірити чи є об'єкт в базі даних,
можна використовувати find:>User.find(1).
Модель. Створюємо контролер: >rails g controller users. В результаті
цієї команди будуть створені файл контролера: / app / controllers /
users_controller.rb і директорія для уявлень: app / views / users /. Кожному
методу контролер буде відповідати уявлення з такою ж назвою, в цій папці.
Їх можна створювати вручну, а можна і відразу при створенні
контролера: >rails g controller users index,list. У цьому випадку файли
представлень створяться автоматично в папці / app / views / users / і будуть
називатися (якщо ви не забули підключити haml) index.html.haml і
list.html.haml. Видалити контролер можна так: >rails d controller users, де d-
скорочення від destroy.
Вміст нашого контролера users буде таким: class UsersController <
ApplicationController def list @users_list=User.all end end. У users_list буде
масив об'єктів користувачів, яких ми вже добавили з консолі, а "@" означає,
що змінна буде передана в шаблон.
Вигляд. Тепер створюємо уявлення, просто створив цей файл в
потрібній директорії: / app / views / users / list.html.haml.
Документацію по HAML треба вивчати, знадобиться мінімум знань про
нього, наприклад те, що замість відкривання і закривання тега в ньому
використовується "% tag". Тобто після рендеринга шаблону, що містить %
html, ми отримаємо сторінку.
Маршрути. І залишився тільки один маленький крок - редагування
файлу-конфігурації маршрутів (url) - routes.rb. Він знаходиться в app / config
/. У ньому описуються всі маршрути нашого проекту. Зараз там буде тільки
два записи: App::Application.routes.draw do root :to => "users#index" #GET Urls
get "users/list", як шлях на інтерфейсну частину сторінку буде показуватися
вміст шаблону /users/index.html.haml, навіть незважаючи на те, що метод
index в контролері не визначений і шлях до сторінці виведення списку
користувачів.
Після написання коду, та розміщення на сервері з додатком можна
починати працювати надалі вважатимемо що проект розміщено та запущено
у localhost/і’мя проекту/www, для цього в браузері слід написати
«localhost:3000», і ми потрапимо на головну сторінку додатку.
При завантажені сайту автоматизованої інформаційно-довідкової
системи, перед користувачем постає, головна сторінка сайту де представлено
логін, меню, та вхід у систему користувачами.
Після всіх приготувань з додатком можна починати працювати для
цього в браузері слід написати «localhost:3000», і ми потрапимо на головну
сторінку інформаційної системи, що є поліструктурним об'єктом і включає
взаємопов'язану сукупність комплексу апаратно-програмних засобів для
збирання, передачі і обробки інформації, відповідної інформаційної бази і
користувачів, який бере участь у обробці, збиранні, передачі і використанні
інформації.
2.5 Особливості проектування реляційної структури моделі
Реляційні системи в сукупності елементів утворюють реляційну модель
роботи з даними, що відтворює всю збережену інформацію як набір логічно
взаємопов'язаних кортежів, записів і атрибутів в таблиці з відображенням
ключів та повязаних полів.
Системи управління базами даних такого типу використовують
структури у вигляді табличних форм представлення даних для зберігання і
роботи з даними. Кожен стовпець (атрибут) містить свій тип інформації.
Кожен запис в базі даних, що володіє унікальним ключем, передається в
рядок таблиці, і її атрибути відображаються в стовпцях таблиці.
SQLite – це також реляційна система керування базами даних, але
обмеженої направленої дії. Має вигляд бібліотеки, з певною особливістю - не
використовує парадигму клієнт-сервер, тобто SQLite не є окремим процесом,
з яким взаємодіє додаток, а надає бібліотеку, з якою програма компілюється і
рушій стає складовою частиною програми. Виклики функцій (API) бібліотеки
SQLite зменшують накладні витрати, час відгуку і спрощує програму та
використовується як протокол обміну, в одночас SQLite зберігає всю базу
даних (включаючи визначення, таблиці, індекси і дані) в єдиному
стандартному файлі. Блокування файлу, де зберігається вся реляційна база
даних надає можливості простоти реалізації, а створення файлу-журналу
відбувається завдяки ACID-функцій.
Враховуючи той факт, що одночасно може оброблятися декілька
процесів та потоків зчитувати дані з єдиної бази даних все ж таки можливо, а
робити запис в базу можна здійснити, коли немає черги на виконання
попередніх запитів у цей час. Інакше спроба запису закінчується невдачею і в
програму повертається код помилки. Іншим варіантом розвитку подій є
автоматичне повторення спроб запису протягом заданого інтервалу часу.
Функціональна клієнтська частина дозволяє демонструвати реалізацію
функцій основної бібліотеки та має вигляд виконуваного файлу sqlite3, в
свою чергу, клієнтська частина працює з командного рядка і дозволяє
звертатися до файлу загальної бази даних на основі типових функцій
операційної системи.
Завдяки архітектурі можливо використовувати SQlite як на вбудованих
(embedded) системах, так і на виділених машинах з гігабайтними масивами
даних.
Переваги використання SQLite:
‒ не потрібно встановлювати додаткове програмне забезпечення;
‒ дані зберігаються в локальному файлі, що створює прозорість їх
контролю, тобто їх можна переглядати і редагувати незалежно від
вашого додатку;
‒ завжди є можливість імпорту табличних форм представлення даних
або експорту в інші системи управління базами даних;
‒ типові SQL-запити використовуються в програмному коді і це
дозволяє в будь-який момент перевести додаток на роботу з іншими
системами управління базами даних.
При постановці завдання було визначено початкові таблиці, які повинні
становити основну структуру бази даних сайту. Нижче зображено табличний
вигляд табличних форм представлення даних. Отже, база даних складається з
5 таблиць, опишемо кожну таблицю (таблиці 2.1-2.5). Зв’язки вказуються
безпосередньо в коді моделей за допомогою методу в якому і описуються всі
потрібні зв’язки. Завдяки такому підходу ми економимо час на написання
запитів на додавання зовнішніх ключів, зв’язування та складні запити на
вибірку типу InnerJoin тощо.
Даний інструмент дає багато переваг, однією з яких є зрозуміле та
зручне складання архітектури бази даних та встановлення зв’язків між
таблицями. А також надає змогу проглянути схему зв’язків таблиць в
графічному вигляді.
Особливості SQLite:
‒ всі дії атомарні, послідовні, ізольовані, і міцні (ACID) незважаючи
на збої системи або живлення;
‒ не потребує конфігурації — ані установки, ані адміністрування;
‒ база даних зберігається в одному кросплатформовому файлі на
диску;
‒ підтримка терабайтних розмірів баз даних і розміру рядків і
BLOBів;
‒ малий розмір коду: менше ніж 350KB повністю налаштований, і
менш 200KB з опущеними додатковими функціями;
‒ швидший за популярні клієнт-серверних баз даних для
найпоширеніших операцій;
‒ простий, легкий у використанні API;
‒ написана в ANSIC, включено взаємозв’язок до TCL; доступні також
взаємозв’язки для десятків інших мов;
‒ добре прокоментований серцевий код зі 100% тестовий покриттям
гілок;
‒ доступний як єдиний файл сирцевого коду на ANSIC, який можна
легко вставити в інший проект;
‒ автономність: немає зовнішніх залежностей;
‒ кросплатформеність: підтримується Unix (Linux і MacOSX), OS/2,
Windows (Win32 і WinCE). Легко переноситься на інші системи;
‒ підзавантажується з командного рядка автономним клієнтом
інтерфейсу, який може бути використаний для управління базами
даних SQLite.
Аби створити наші табличні форми даних ми створюємо файл shema.rb
та пишемо код на Ruby:
ActiveRecord::Schema.define(version: 20171208181330) do
create_table «comes», force: :cascade do |t|
t.string «type»
t.integer «user_id»
t.integer «value»
t.text «comment»
t.date «date»
t.datetime «created_at», null: false
t.datetime «updated_at», null: false
t.index [«user_id»], name: «index_comes_on_user_id» end
create_table «contacts», force: :cascade do |t|
t.string «name»
t.string «email»
t.string «phone»
t.text «comment»
t.datetime «created_at», null: false
t.datetime «updated_at», null: false end
create_table «users», force: :cascade do |t|
t.string «email», default: «», null: false
t.string «encrypted_password», default: «», null: false
t.boolean «admin», default: true
t.string «reset_password_token»
t.datetime «reset_password_sent_at»
t.datetime «remember_created_at»
t.integer «sign_in_count», default: 0, null: false
t.datetime «current_sign_in_at»
t.datetime «last_sign_in_at»
t.string «current_sign_in_ip»
t.string «last_sign_in_ip»
t.datetime «created_at», null: false
t.datetime «updated_at», null: false
t.string «avatar»
t.string «name»
t.index [«email»], name: «index_users_on_email», unique: true
t.index [«reset_password_token»],
name: «index_users_on_reset_password_token», unique: true
end end
Таблиця 2.1
Попередні версії (ar_internal_metadata)
Назва Тип Опис поля
Key String Унікальний ідентифікатор
Value integer Сума
Created at Integer Дата створення
Updated_at Text Дата створення
Таблиця 2.2
Доходи (comes)
Назва Тип Опис поля
id string Унікальний ідентифікатор
type integer Тип
user_id integer Ідентифікатор користувача
value text Значення суми
commen date Коментар
date datetime Дата
created_at datetime Дата створення
updated_at datetime Дата оновлення
Таблиця 2.3 –
Користувачі (users)
Назва Тип Опис поля
id string Унікальний ідентифікатор
email string Електрона адреса
encrypted password string Зашифрований пароль
admin boolean Тип входу
reset_password_token string Зміна паролю
remember_created at datetime Запамятати мене
Продовження табл. 2.3
sing_in_count datetime Дата входу
current_sing_in_at integer Тип входу
last_sign_in_at datetime Дата логіну
current_sign_in_ip datetime IP-адреса користувача
last_sign_in_ip stringe Остання IP-адреса користувача
created_at stringe Дата створення
avatar string e Аватар користувача
name string e Імя
Таблиця 2.4
Контакти (contacts)
Назва Тип Опис поля
name String Імя
email String Електрона адреса
phone String Телефон
comment Text Коментар
created_at datetime Дата створення
updated_at datetime Дата оновлення
Таблиця 2.5
Міграції (schema_migrations)
Назва Тип Опис поля
Version String Унікальний ідентифікатор
2.6 Особливості побудови звязків між табличними даними
Розглянемо тепер проектування реляційної моделі даних з різних видів
аспектів.
1. Структурний аспект - дані в реляційній базі сприймаються
користувачем, як таблиці.
2. Аспект обробки - користувач має набір операторів
маніпулювання даними, які генерують нові таблиці на основі уже
існуючих таблиць.
3. Аспект цілісності даних - таблиці задовольняють певним
умовам цілісності.
4. Інформаційний принцип - увесь інформаційний вміст бази
даних представляється явним задаванням значень, що розміщуються
в позиціях стовпчиків в рядках таблиці.
Компоненти реляційної моделі мають наступний зміст:
‒ необмежений набір скалярних типів;
‒ генератор типів відношень і відповідна інтерпретація для таких
згенерованих відношень;
‒ можливість визначення змінних-відношень для таких згенерованих
типів відношень;
‒ операція реляційного присвоєння для присвоєння реляційних
значень таким змінним відношенням;
‒ необмежений набір загальних реляційних операторів для отримання
значень відношень з інших значень відношень.
Домени, як формат представлення:
1 Домен – це не що інше, як тип даних;
2 Тип даних – це іменована множина значень – всіх можливих
значень даного типу;
3 Для кожного типу існують свої допустимі оператори – значеннями
заданого типу можна маніпулювати тільки за допомогою
операторів, визначених для цього типу;
4 Треба розрізняти типи даних самі по собі та фізичне представлення
значень цих типів усередині системи;
5 Кожне значення обов'язково має деякий тип: Я – ціле число; Я –
номер постачальника; Я – геометрична точка;
6 Кожний тип даних може бути скалярним або нескалярним:
‒ нескалярними є всі типи даних, явно визначені таким чином, що в
них є компоненти, видимі для користувача;
‒ скалярні типи видимих компонентів не мають.
З огляду програмного представлення домени мають наступний вид:
‒ TYPE SNUM POSSREP { CHAR } ;
‒ TYPE NAME POSSREP { CHAR } ;
‒ TYPE QTY POSSREP { INTEGER } ;
‒ TYPE POINT
‒ POSSREP CARTESIAN { X RATIONAL, Y RATIONAL P }
‒ POSSREP POLAR { R RATIONAL, THETA RATIONAL } ;
Визначення кожного можливого представлення змушує автоматичне
визначення наступних операторів.
Оператор-селектор, який дозволяє користувачеві визначати або
вибирати значення даного типу.
Множина операторів the_, які дозволяють користувачеві звертатися до
відповідних компонентів можливого представлення даного типу.
‒ CARTESIAN ( 5.0, 2.5 )
/* Вибирає точку з координатами х = 5.0, у = 2.5 */
‒ CARTESIAN ( X1, Y1 )
/* Вибирає точку з координатами х = X1, у = Y1, где */
/* X1 і Y1 - змінні типу RATIONAL */
‒ POLAR ( 2.7, 1.0 )
/* Вибирає точку з координатами r = 2.7, theta = 1.0 */
‒ ТНЕ_Х ( Р )
/* Вказує координату х точки в */
/* Р, де Р - змінна типу POINT */
‒ THE_R ( P )
/* Вказує координату r точки в Р */
‒ THE_Y ( ехр )
/* Вказує координату у точки, визначеної */
/* виразом ехр (яке відноситься до типу POINT) */
‒ OPERATOR CARTESIAN ( X RATIONAL, Y RATIONAL ) RETURNS POINT ;
BEGIN ;
VAR P POINT ; /* P - змінна типу POINT */
<компонент X фізичного представлення Р := Х> ;
<компонент Y фізичного представлення Р := Y> ;
RETURN ( P ) ; END ; END OPERATOR ;
‒ OPERATOR POLAR ( R RATIONAL, Q RATIONAL ) RETURNS
POINT ; RETURN ( CARTESIAN ( R * COS ( Q ) , R *
SIN ( Q ) ) ) ;
END OPERATOR ;
‒ OPERATOR POLAR ( R RATIONAL, Q RATIONAL )
RETURNS POINT ; BEGIN ;
VAR P POINT ;
<компонент X фізичного представлення Р := R * COS (Q)> ;
<компонент Y фізичного представления Р := R * SIN (Q)>;
RETURN ( P ) ; END ; END OPERATOR ;
− OPERATOR ТНЕ_Х ( Р POINT ) RETURNS RATIONAL ;
RETURN ( <компонент X фізичного представлення Р> ) ;
END OPERATOR ;
− OPERATOR THE_Y ( P POINT ) RETURNS RATIONAL ;
RETURN ( <компонент Y фізичного представлення Р> ) ;
END OPERATOR ;
− OPERATOR THE_R ( P POINT ) RETURNS RATIONAL ;
RETURN ( SQRT ( THE_X ( P )2 + THE_Y ( P )2 ) ) ;
END OPERATOR ;
− OPERATOR THE_Q ( P POINT ) RETURNS RATIONAL ;
RETURN ( ARCTAN ( THE_Y ( P ) / THE_X ( P ) )) ;
END OPERATOR ;
− OPERATOR ABS ( Z RATIONAL )
RETURNS RATIONAL ;
RETURN (
CASE
WHEN Z >= 0.0 THEN +Z
WHEN Z < 0.0 THEN -Z
END CASE ) ;
END OPERATOR;
− TYPE LINESEG POSSREP { BEGIN POINT, END POINT } ;
− OPERATOR DIST ( P1 POINT, P2 POINT ) RETURNS LENGTH ;
RETURN {
WITH
THE_X ( P1 ) AS X1 , THE_X ( P2 ) AS X2 ,
THE_Y ( P1 ) AS Y1 , THE_Y ( P2 ) AS Y2 :
LENGTH ( SQRT (( X1 - X2 )2+ ( Y1 - Y2 )2 ) ) );
END OPERATOR ;
− OPERATOR EQ ( P1 POINT, P2 POINT ) RETURNS BOOLEAN ;
RETURN (
THE_X ( P1 ) = THE_X ( P2 )
AND
THE_Y ( P1 ) = THE_Y { P2 )) ;
END OPERATOR ;
− OPERATOR GT ( Q1 QTY, Q2 QTY ) RETURNS BOOLEAN ;
RETURN ( THE_QTY ( Q1 ) > THE_QTY ( Q2 )) ; END OPERATOR ;
− OPERATOR REFLECT ( Р POINT ) UPDATES P ;
BEGIN ;
THE_X ( P ) := - THE_X ( P ) ;
THE_Y ( P ) := - THE_Y ( P ) ;
RETURN ; END ;
END OPERATOR ;
Отже, система повинна мати інформацію про те, який саме вирази є
допустимими і яким повинен бути тип результату для кожного такого
допустимого виразу. Загальний набір типів для конкретної бази даних
повинен представлять собою замкнуту множену. З цього випливає, що тип
результату кожного допустимого виразу повинен бути типом, відомим
системі. Замкнута множина типів повинна також включати логічний тип,
оскільки в іншому випадку ні один оператор порівняння не буде допустимим.
З того факту, що системі повинен бути відомий тип результату кожного
допустимого виразу, випливає, що системі повинно бути відомо, які операції
присвоєння та які операції порівняння є допустимими.
Тепер опишемо кортежі, що є важливим при побудові загальної схеми
звязків між полями та даними табличних форм:
‒ кожний кортеж містить точно одне значення (відповідного
типу) для кожного з своїх атрибутів;
‒ для компонентів кортежу не передбачено впорядкування,
наприклад, зліва на право. Ця властивість випливає з того, що
поняття кортежу визначено на основі множини компонентів, а в
математиці множини не характеризуються впорядкуванням своїх
елементів;
‒ кожна підмножина кортежу представляє собою кортеж (а
кожна підмножина заголовка є заголовком).
Рисунок 2.1 – Структурована схема бази даних
Значення відношення R складається з заголовка і тіла:
‒ заголовок відношення R представляє собою заголовок
кортежу. Відношення R має ті самі атрибути і ту ж ступінь, як і
заголовок;
‒ тіло відношення R представляє собою множну кортежів, що
мають один і той же заголовок; кардинальність відношення R
визначається кардинальністю цієї множини;
‒ кожний атрибут містить точно одне значення (відповідного
типу) для кожного атрибута;
‒ атрибути не впорядковані і кортежі не впорядковані;
‒ у відношеннях відсутні дублікати кортежів;
‒ заголовок будь-якої заданої змінної відношення може
розглядатися як предикат, а кортежі, присутні в цій змінні
відношення в будь-який конкретний момент часу, можуть
розглядатися як істинні висловлювання, отримані з цього предиката
шляхом підстановки фактичних параметрів відповідного типу
замість формальних параметрів предикату;
‒ тіло змінної відношення в будь-який конкретний момент
часу містить ті і тільки ті кортежі, які відповідають висловленням,
що є істинними на цей момент часу.
З цього можемо побудувати логічні зв’язки між табличними формами
даних, тому представимо цю структурну схему взаємозв’язків на рисунку 2.1.
2.7 Можливість змінювати схему бази даних за допомогою Active
Record
Міграції - це особливість Active Record, що дозволяє змінювати схему
вашої бази даних час від часу. Замість того, щоб записувати зміни схеми на
чистому SQL, міграції дозволяють використовувати простий Ruby DSL для
опису змін в ваших таблицях.
Міграції - це зручний спосіб змінювати схему вашої бази даних
простим чином і відповідно, нова міграція породжує нову версію бази даних.
Вони використовують Ruby DSL. Тому вам не потрібно писати SQL вручну,
дозволяючи вашій схемі бути незалежною від бази даних.
Постійні зміни міграцій змінює схеми додаючи або прибираючи
таблиці, стовпці або записи, при цьому Active Record знає, як оновлювати
вашу схему з часом, переносячи її з певної точки в минулому в останню
версію. Active Record також оновлює ваш файл db / schema.rb, щоб він
відповідав поточній структурі вашої бази даних.
Ось приклад міграції, для створення таблиці Контакти:
class CreateContacts < ActiveRecord::Migration[5.1]
def change
create_table :contacts do |t|
t.string :name
t.string :email
t.string :phone
t.text :comment
t.timestamps
end
end end
Ця міграція додає таблицю contacts зі строковим стовпцем name, email,
phone, текстовим стовпцем description. Первинний ключ, названий id, також
буде неявно доданий за замовчуванням, так як це первинний ключ за
замовчуванням для всіх моделей Active Record. Макрос timestamps додає два
стовпці, created_at і updated_at. Ці спеціальні стовпці автоматично
управляються Active Record, якщо існують.
Відзначте, що ми визначили зміна, яку ми хочемо, щоб сталося під час
руху вперед у часі. До запуску цієї міграції таблиці немає. Після - таблиця
буде існувати. Active Record також знає, як звернути цю міграцію: якщо ми
відкатуємо цю міграцію, він видалить таблицю.
2.8 Використання шаблону проектування для створення системи
Для рішення другою поставленої задачі роботи застосуємо патерн MVC
- Model-View-Controller. Шаблон проектування MVC передбачає поділ даних
програми, користувальницького інтерфейсу і керуючої логіки на три окремі
компоненти: модель, вигляд і контролер – таким чином, що модифікація
кожного компонента може здійснюватися незалежно.
Рисунок 2.2 - Модель-вигляд-контролер у вигляді схеми
Модель (Model) відкликаючись на команди контролера змінює стан та
нанадає дані предметної області поданням.
Вигляд (View) реакцією на зміни, що відбуваються в моделі, є
відображення відображення даних предметної області моделі користувачеві.
Контролер (Controller) необхідний тоді, коли виникає потреба у зміні
моделі, і тоді відбувається інтерпретація дій користувача.
Екземпляр класу ModuleControl, що ініціалізує всі модулі, які реагують
на дії користувача, і управляє порядком їх роботи лежить в основі всього
функціоналу даного патерну.
Порядок виконання дій:
‒ ініціалізація середовища: визначення базових констант і змінних;
‒ створення примірників класу ModuleControl.;
‒ контролер шукає всі наявні модулі та ініціалізує їх;
‒ відбувається запуск модулів, що відповідають за авторизацію
користувача;
‒ якщо необхідна обробка дій користувача також потрібно запустити
модулі;
‒ якщо виникає необхідність створення динамічних сторінок на
основі шаблонів та даних такоє відбувається завантаження модулів,
що надали до цього;
‒ необхідне завантаження модулів, що відповідає за виведення
користувачеві створеної сторінки.
Додаток, що створений на основі сесій, має стандартну структуру, яку
цілком підпадає під визначення патерну модель-вигляд-контролер. Принцип
дії якого можна зрозуміти завдяки наступному зображенню. На основі даної
діаграми, структуру додатку можна розділити на такі частини:
2.9 Проектування Моделей для створення системи
Active Record це Model в MVC - модель що в системі відповідає за
подання бізнес-логіки і даних, значно спрощує створення і використання
бізнес-об'єктів, дані яких вимагають постійного зберігання в базі даних. Сама
по собі ця реалізація патерну Active Record є описом системи ORM (Object
Relational Mapping).
В Active Record об'єкти містять і збережені дані, і поведінка, яке
працює з цими даними. Логічне забезпечення доступу до даних, як частини
об'єкта, дає напрям чк правильно читати або записувати дані в базу.
Object Relational Mapping (ORM) - це техніка, що з'єднує складні
об'єкти додатки з таблицями в системі керування базами даних. З
використанням ORM, властивості і взаємини цих об'єктів додатки можуть
бути з легкістю збережені і отримані з бази даних без безпосереднього
написання виразів SQL, і, в підсумку, з меншим сумарним кодом для доступу
до бази даних.
Active Record надає нам кілька механізмів, найбільш важливими з яких
є здібності для:
‒ уявлення моделей і їх даних;
‒ уявлення зв'язків між цими моделями;
‒ уявлення ієрархій успадкування за допомогою пов'язаних моделей;
‒ валідації моделей до того, як вони будуть збережені в базу даних;
‒ виконання операцій з базою даних в об'єктно-орієнтованому стилі.
При написанні програми з використанням інших мов програмування
або фреймворків часто потрібно писати багато конфігураційного коду.
Зокрема, це справедливо для фреймворків ORM. Однак, якщо слідувати
угодам, прийнятим Rails, вам доведеться написати зовсім небагато змін (а
іноді зовсім не доведеться) при створенні моделей Active Record. Ідея в тому,
що в більшості випадків ви налаштовуєте свої додатки однаковим чином, і
цей спосіб повинен бути способом за замовчуванням. Таким чином, явна
конфігурація буде потрібно тільки тоді, коли ви не дотримуєтесь угодами з
якоїсь причини.
За замовчуванням Active Record використовує деякі угоди по
іменування щоб дізнатися, як повинна бути створена зв'язок між моделями і
таблицями бази даних. Rails утворює множину для імен класу, щоб знайти
відповідну таблицю бази даних. Так, для класу Book слід створити таблицю
бази даних з ім'ям books. Механізми утворення множини Rails дуже потужні,
вони здатні утворювати множину (і єдине) число як для правильних, так і для
неправильних слів. При використанні імен класу, створених з двох і більше
слів, ім'я класу моделі має слідувати угодам Ruby, використовуючи форму
CamelCase, тоді як ім'я таблиці має містити слова, розділені знаком
підкреслення. приклади:
‒ таблиця бази даних - багатозначна форма зі словами, розділеними
знаком підкреслення (тобто, book_clubs);
‒ клас моделі - єдине число з першої великої буквою в кожному слові
(тобто, BookClub).
Active Record використовує угоди про іменуванні для стовпців в
таблицях бази даних, що залежать від призначення цих стовпців.
Зовнішні ключі - ці поля повинні іменуватися за зразком
singularized_table_name_id (тобто, item_id, order_id). Це поля, які шукає
Active
Record при створенні зв'язків між вашими моделями.
Первинні ключі - за замовчуванням Active Record використовує
числовий стовпець з ім'ям id як первинний ключ таблиці. Цей стовпець буде
автоматично створений при використанні міграцій Active Record для
створення таблиць.
Також є деякі опціональні імена стовпців, що додають додаткові
особливості для примірників Active Record:
‒ Created_at - автоматично будуть встановлені поточні дата і час при
первісному створенні запису.
‒ Updated_at - автоматично будуть встановлені поточні дата і час
кожного разу, коли оновлюється запис.
‒ Lock_version - додає оптимістичну блокування до моделі.
‒ Type - вказує, що модель використовує Single Table Inheritance.
‒ (Association_name) _type - зберігає тип для поліморфних зв'язків.
‒ (Table_name) _count - використовується для кешування кількості
належних по зв'язку об'єктів. Наприклад, стовпець comments_count
в класі Article, у якого може бути кілька пов'язаних примірників
Comment, закешує кількість існуючих коментарів для кожної статті.
Створювати моделі Active Record дуже просто. Все, що необхідно
зробити, це створити підклас ApplicationRecord, і готово:
class Product <ApplicationRecord
end
Це створить модель Product, зв'язавши її з таблицею products в базі
даних.
Зробивши так, також з'явиться здатність зв'язати стовпчики кожного
рядка цієї таблиці з атрибутами примірників вашої моделі. Припустимо, що
таблиця products була створена з використанням такого виразу SQL:
CREATE TABLE products (
id int (11) NOT NULL auto_increment,
name varchar (255),
PRIMARY KEY (id)
);
Дотримуючись вищевказаною схемою, можна буде писати подібний
код:
p = Product.new
p.name = "Some Book"
puts p.name "Some Book"
ApplicationRecord успадковується від ActiveRecord :: Base, який
визначає ряд корисних методів. Можна використовувати метод ActiveRecord
:: Base.table_name = для вказівки імені таблиці, яка повинна бути
використана:
class Product <ApplicationRecord
self.table_name = "my_products"
end
Якщо так зробити, потрібно вручну визначити ім'я класу, що містить
фікстура (my_products.yml), використовуючи метод set_fixture_class у
визначенні тесту:
class ProductTest <ActiveSupport :: TestCase
set_fixture_class my_products: Product
fixtures: my_products
end
Також можливо перевизначити стовпець, який повинен бути
використаний як первинний ключ таблиці, за допомогою методу
ActiveRecord :: Base.primary_key =:
class Product <ApplicationRecord
self.primary_key = "product_id"
end
CRUD це скорочення для чотирьох дієслів, використовуваних для
опису операцій з даними: Create (створити), Read (прочитати), Update
(оновити) і Delete (видалити). Active Record автоматично створює методи, що
дозволяють з додатком читати і впливати на дані, що зберігаються в своїх
таблицях.
Об'єкти Active Record можуть бути створені з хеша, блоку або з вручну
зазначених після створення атрибутів. Метод new поверне новий об'єкт, в той
час як create поверне об'єкт і збереже його в базу даних.
Наприклад, для моделі User з атрибутами name і occupation, виклик
методу create створить і збереже новий запис в базу даних:
user = User.create (name: "David", occupation: "Code Artist")
Використовуючи метод new, об'єкт може бути ініціалізовано без
збереження:
user = User.new
user.name = "David"
user.occupation = "Code Artist"
Виклик user.save передає запис в базу даних.
Нарешті, якщо надано блок і create, і new передадуть новий об'єкт в цей
блок для ініціалізації:
user = User.new do | u |
u.name = "David"
u.occupation = "Code Artist"
end
Active Record надає багатий API для доступу до даних в базі даних.
Нижче кілька прикладів різних методів доступу до даних, наданих Active
Record.
Поверне колекцію з усіма користувачами - users = User.all.
Поверне першого користувача - user = User.first.
Поверне першого користувача з ім'ям David - david = User.find_by
(name: 'David').
Знайде всіх користувачів з ім'ям David, які Code Artists, і сортує їх по
created_at в зворотному хронологічному порядку:
users = User.where (name: 'David', occupation: 'Code Artist'). order
(created_at:: desc).
Як тільки об'єкт Active Record буде отримано, його атрибути можуть
бути змінені, і він може бути збережений в базу даних:
user = User.find_by (name: 'David')
user.name = 'Dave'
user.save
Скороченим варіантом для цього є використання хеша з атрибутами,
пов'язаними з бажаними значеннями, таким чином:
user = User.find_by (name: 'David')
user.update (name: 'Dave')
Це найбільш корисно, коли необхідно оновити кілька атрибутів за раз.
Якщо, з іншого боку, необхідно оновити кілька записів за раз, корисний
метод класу update_all:
User.update_all "max_login_attempts = 3, must_change_password = 'true'"
Більш того, після отримання, об'єкт Active Record може бути знищений,
що прибере його з бази даних:
user = User.find_by (name: 'David')
user.destroy
Якщо необхідно видалити відразу кілька записів, можна
використовувати метод destroy_all:
‒ знайти і видалити всіх користувачів з ім'ям David
User.where (name: 'David'). Destroy_all
‒ видалити всіх користувачів
User.destroy_all
Створені моделі автоматизованої інформаційної системи:
application_record
come
contact
income
outcome
user
Реалізація моделі user:
class User < ApplicationRecord
mount_uploader :avatar, AvatarUploader
has_many :incomes
has_many :outcomes
has_many :come
Include default devise modules. Others available are:
:confirmable, :lockable, :timeoutable and :omniauthable
devise :database_authenticatable, :registerable,
recoverable, :rememberable, :trackable, :validatable end
2.10 Проектування Контролерів для створення системи
Controller це C в абревіатурі MVC. Після того, як роутер визначить,
який контролер використовувати для обробки запиту, контролер
відповідальний за осмислення запиту і генерацію відповідного відповіді. На
щастя, Action Controller робить за вас більшу частину брудної роботи і
використовує елегантні угоди, щоб зробити це по можливості максимально
просто.
Для більшості додатків, заснованих на RESTful, контролер отримує
запит (це невидимо для вас, як для розробника), витягує або зберігає дані в
моделі і використовує вигляд для створення результуючого HTML. Якщо
контролеру необхідно працювати трохи по іншому, не проблема, це всього
лише найбільш поширений спосіб роботи контролера [17-18].
Таким чином, контролер можна розглядати як посередника між
моделями і виглядами. Він робить дані моделі доступними вигляду, так що
вона може відображати ці дані користувачеві, і він зберігає або оновлює дані
від користувача в модель.
Угода по іменування контролерів в Rails встановлює перевагу множини
в останньому слові імені контролера, хоча строго це не потрібно. Наприклад,
ClientsController більш кращий, ніж ClientController, SiteAdminsController
більш кращий, ніж SiteAdminController або SitesAdminsController, і так далі.
Контролер - це клас Ruby, успадкований від ApplicationController і
містить методи, як і будь-який інший клас. Коли ваш додаток отримує запит,
роутинг визначає, який контролер та стрілялки потрібно запустити, потім
Rails створює екземпляр цього контролера і запускає метод з ім'ям:
class ClientsController <ApplicationController
def new
end
end
Як приклад, якщо користувач перейде в / clients / new в вашому
додатку, щоб додати нового клієнта, Rails створить екземпляр
ClientsController і викличе метод new. Відзначте, що порожній метод з
вищенаведеного прикладу буде прекрасно працювати, так як Rails за
замовчуванням отрендеріть вигляд new.html.erb, якщо в екшені не буде
вказано інше. Метод new може зробити доступною для вигляд змінну
примірника @client для створення нового Client:
def new
@client = Client.new
end
ApplicationController успадкований від ActionController :: Base, який
визначає кілька корисних методів. Тільки public методи можуть бути
викликані як екшени. Доброю практикою є зменшення області видимості
методів за допомогою private або protected.
Фільтри - це методи, які запускаються "до", "після" або "до і після"
екшна контролера. Фільтри успадковуються, тому, якщо ви встановите
фільтр в ApplicationController, він буде запущений в кожному контролері
вашого застосування. Фільтри "before" можуть переривати цикл запиту.
Звичайний фільтр "before" - це, наприклад, той, який вимагає, щоб
користувач був авторизований для запуску екшна.
Метод фільтра можна визначити наступним чином:
class ApplicationController <ActionController :: Base
before_action: require_login
private
def require_login
unless logged_in?
flash [: error] = "You must be logged in to access this section"
redirect_to new_login_url перериває цикл запиту
end
end
end
Метод просто записує повідомлення про помилку під flash і
перенаправляє на форму авторизації, якщо користувач не авторизувався.
Якщо фільтр "before" рендерить або перенаправляє, стрілялки не запуститься.
Якщо є додаткові фільтри в черзі, вони також будуть скасовані.
У цьому прикладі фільтр доданий в ApplicationController, і тому все
контролери в додатку успадковують його. Це призводить до того, що все в
додатку вимагає, щоб користувач був авторизований, щоб користуватися
ним. Зі зрозумілих причин. Не всі контролери або екшени повинні вимагати
його. Ви можете не допустити запуск цього фільтра перед певними строками,
за допомогою skip_before_action:
class LoginsController <ApplicationController
skip_before_action: require_login, only: [: new,: create]
end
Тепер, екшени LoginsController new і create працюватимуть як раніше,
без вимоги до користувача бути зареєстрованим. Опція: only
використовується для пропуску фільтра тільки для цих екшнів, а також є
опція except, яка працює навпаки. Ці опції можна використовувати і при
додаванні фільтрів, тому необхідно додати фільтр, який буде працювати
тільки для обраних екшнів в першу чергу.
Виклик одного і того ж фільтра кілька разів з різними параметрами не
працюватиме, оскільки останнє визначення фільтра перезапише попередні.
На додаток до фільтрів "before", можна запустити фільтри після того, як
стрілялки був запущений, або "і до, і після".
Фільтри "after" схожі на "before", але оскільки вже був запущений, у
них є доступ до даних відгуку, які будуть відіслані клієнту. Очевидно,
фільтри "after" не можуть зупинити екшн від запуску. Зверніть увагу, що
фільтри "after" виконуються тільки після успішного виконання екшна, але не
при виникненні виключення в циклі запиту.
Фільтри "around" відповідальні за запуск пов'язаних з ними екшнів за
допомогою yield, подібно до того, як працюють проміжні програми Rack.
Наприклад, на Web-сайті, де для змін є процедура затвердження
інформації, адміністратор може легко їх переглянути, просто застосувавши їх
усередині транзакції:
class ChangesController <ApplicationController
around_action: wrap_in_transaction, only:: show
private
def wrap_in_transaction
ActiveRecord :: Base.transaction do
begin
yield
ensure
raise ActiveRecord :: Rollback
end
Відзначте, що фільтри "around" також обертають рендеринг. Зокрема,
якщо в вищевказаному прикладі вигляд сама почне зчитувати з бази даних
(наприклад через Скоуп), вона це здійснить в транзакції, надавши, таким
чином, дані для попереднього перегляду.
Можна не викликати yield і створити відгук самостійно, в цьому
випадку стрілялки НЕ буде запущений.
Створені контролери автоматизованої інформаційної системи:
admins_controller
application_controller
users_controller
welcome_controller
analitiks_controller
comes_controller
contacts_controller
users_controller
Реалізація контролеру comes_controller:
class Admin :: ComesController <AdminsController
before_action: find_user, only: [: create,: index,: edit,: destroy]
def index
@incomes = current_user.incomes
@outcomes = current_user.outcomes
@comes = Come.all
end
def new
@come = Come.new
end
def show
end
def edit; end
def create
if come_params [: type] == "Income"
@come = @ user.incomes.create (come_params)
end
if come_params [: type] == "Outcome"
@come = @ user.outcomes.create (come_params)
end
@ come.user_id = @ user.id
if @ come.save
redirect_to admin_user_comes_path (@user)
else
render 'new'
end
end
def update
@come = Come.update (come_params)
redirect_to admin_user_comes_path (@user)
end
def destroy
@user = User.find (params [: id])
@ user.destroy
redirect_to admin_root_path
end
private
def find_user
@user = User.find (params [: user_id])
end
def come_params
params.require (: come) .permit (: type,: value,: comment,: date,: user_id)
end end
2.11 Проектування Вигляд для створення системи
У Rails Web-запити обробляються Action Controller і Action View.
Зазвичай Action Controller відповідальний за зв'язок з базою даних і
виконання екшнів CRUD. Тоді як View відповідальний за компіляцію
відгуку.
Шаблони Action View пишуться за допомогою тегів вбудованого Ruby,
змішаних з HTML. Щоб уникнути захаращення вигляд шаблонним кодом,
загальна поведінка для форм, дат і рядків представлено поруч класів хелпера.
В існуючу програму також легко додавати нові хелпери.
Деякі особливості Action View пов'язані з Active Record, але це не
означає, що Action View залежить від Active Record. Action View - це
незалежний пакет, який можна використовувати з будь-якою бібліотекою
Ruby.
Для кожного контролера є пов'язана директорія в директорії app /
views, що містить файли шаблонів, які формують вигляд, пов'язані з цим
контролером. Ці файли використовуються для відображення вигляд, що є
результатом кожного екшна контролера.
Давайте поглянемо на те, що робить Rails за замовчуванням, коли
створює новий ресурс за допомогою генератора скаффолда:
$ Bin / rails generate scaffold article
invoke scaffold_controller
create app / controllers / articles_controller.rb
invoke erb
create app / views / articles
create app / views / articles / index.html.erb
create app / views / articles / edit.html.erb
create app / views / articles / show.html.erb
create app / views / articles / new.html.erb
create app / views / articles / _form.html.erb
У Rails є угода по іменування вигляд. Як правило, ім'я вигляд
збігається з відповідним екшном контролера, як ви могли бачити вище.
Наприклад, index контролера в articles_controller.rb буде використовувати
файл вигляд index.html.erb в директорії app / views / articles. Повний HTML,
повернутий клієнту, складається з комбінації цього файлу ERB, шаблону
макета, обертається його, і всіх партіалов, на які вигляд може посилатися. У
цьому керівництві є більш детальний опис кожного з цих трьох компонентів.
Як уже згадувалося, підсумковий HTML складається з трьох елементів
Rails: шаблонів (Templates), партіалов (Partials) і макетів (Layouts). Нижче
короткий огляд кожного з них.
Шаблони Action View можуть бути написані декількома способами.
Якщо у файлу шаблону розширення .erb, то він використовує суміш ERB
(Embedded Ruby) і HTML. Rails підтримує кілька систем шаблонирования і
використовує розширення файлу, щоб розрізняти їх. Наприклад, файл HTML,
який використовує систему шаблонирования ERB, матиме розширення файлу
.html.erb.
У шаблоні ERB код Ruby може бути включений за допомогою тегів
<%%> і <% =%>. Теги <%%> використовуються для виконання коду Ruby,
який нічого не повертає, такого як умови, цикли або блоки, а теги <% =%>
використовуються, коли вам потрібен результат виконання.
Розглянемо наступний цикл для імен:
<H1> Names of all the people </ h1>
<% @ People.each do | person | %>
Name: <% = person.name%> <br>
<% End%>
Цикл налаштований за допомогою звичайних вбудованих тегів
(<%%>), а ім'я вставлено за допомогою виводять вбудованих тегів (<% =%>).
Відзначте, що це не просто рада з використання: звичайні функції для
виведення, такі як print і puts НЕ будуть рендери у вигляд в шаблонах ERB.
Тому, так буде неправильно:
<% WRONG%>
Hi, Mr. <% Puts "Frodo"%>
Щоб заборонити попередні і завершальні прогалини можна
використовувати <% - -%> замість <% і%>.
Для кожної сторінки є частини, які відоображаються для всіх однаково,
наприклад header для авторизованого користувача:
<nav class="navbar navbar-inverse">
<div class="container-fluid">
<div class="navbar-header">
<a class="navbar-brand" href="#">WebSiteName</a>
</div>
<ul class="nav navbar-nav">
<li class="active"><%= link_to 'Home', root_path %></li>
<% if current_user %>
<li><%= link_to "analitiks", admin_analitiks_path %></li>
<li><%= link_to 'My comes', admin_user_path(current_user) %></li>
<li><%= link_to 'sign_out', destroy_session_path(current_user), method:
:delete %></li>
<% else %>
<li><%= link_to 'sign_in', new_user_session_path %></li>
<li><%= link_to 'sign_up', new_user_registration_path %></li>
<% end %>
</ul>
</div>
</nav>
Також для кожної сторінки є частини, які відоображаються не для всіх
однаково, наприклад коли користувач авторизований:
<!DOCTYPE html>
<html>
<head>
<title>TwoApp</title>
<script src="https://d3js.org/d3.v4.min.js"></script>
<%= csrf_meta_tags %>
<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-
track': 'reload' %>
<%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload'
%>
</head>
<body>
<nav class="navbar navbar-inverse">
<div class="container-fluid">
<div class="navbar-header">
<a class="navbar-brand" href="#">WebSit</a>
</div>
<ul class="nav navbar-nav">
<li class="active"><a href="#">Home</a></li>
<% if current_user %>
<li><%= link_to "analitiks", admin_analitiks_path %></li>
<% if current_admin %>
<li><%= link_to 'My comes', admin_user_path(current_user) %></li>
<% end %>
<li><%= link_to 'sign_out', destroy_session_path(current_user), method:
:delete %></li>
<% else %>
<li><%= link_to 'sign_in', new_user_session_path %></li>
<li><%= link_to 'sign_up', new_user_registration_path %></li>
<% end %>
<li><%= link_to 'contact', new_admin_contact_path %></li>
</ul>
</div>
</nav>
<%= yield %>
</body>
</html>
Висновки до другого розділу
Розділ існуючих рішень та обґрунтування вибору прийнятого принципу
побудови додатку приводиться з метою з'ясування необхідності та
актуальності розробки програмного продукту та проаналізовано його
архітектуру та структуру з використанням шаблону проектування Model-
View-Controller, головною перевагою якого є розділення коду інтерфейсу
користувача і іншого коду.
В даному підході до побудови додатків варто пам’ятати, що модель не
повинна містити відображення на екран, а вигляд маніпуляцій та звернень до
моделі.
Створення автоматизованої системи це складна задача і необхідна
умова швидкої розробки програмних продуктів. Здійснено розробку
структури бази даних, модель, контролер і вигляд, який належить до
розгалуженого типу.
Розроблені інструменти керування автоматизованої інформаційної
системи для ведення сімейного бюджету є Web-додатком, оскільки вона
написана під усі платформи, які мають браузер та надає користувачу послуги,
а саме - можливість обліку його фінансового стану, та представлення у
графічному вигляді.
РОЗДІЛ 3
ДОСЛІДЖЕННЯ ТА ВДОСКОНАЛЕННЯ ІНФОРМАЦІЙНОЇ
СИСТЕМИ
3.1 Основні аспекти та оцінка працездатності системи
Після створення сайту, його викладають в мережу (Інтернет).
Процедура розміщення сайту в Інтернет не є складною. Для цього потрібно
зареєструвати для сайту доменну адресу і визначитися з хостингом - місцем
на сервері провайдера, де буде знаходитися сторінка.
Коли сайт розміщено в Інтернеті, то перш, ніж його просувати і
рекламувати, слід перевірити сайт на працездатність. Можливо, якісь
скрипти виконуються з помилками або десь пропущено важливу і цінну
інформацію або потрібна картинка.
Тестування програмного забезпечення - це процес технічного
дослідження, який виконується на вимогу замовників, і призначений для
виявлення інформації про якість продукту відносно контексту, в якому він
має використовуватись; процес аналізу або експлуатації програмного
забезпечення з метою виявлення дефектів.
Тестування передбачає "аналіз" або "експлуатацію" програмного
продукту. Тестова діяльність, що пов'язана з аналізом результатів розробки
програмного забезпечення, називається статичним тестуванням. Воно
передбачає перевірку програмних кодів, контроль та перевірку програми без
запуску на комп'ютері. Тестова діяльність, що передбачає експлуатацію
програмного продукту, називається динамічним тестуванням. Динамічне та
статичне тестування доповнюють одне одного.
Тестування вирішує декілька основних завдань:
‒ дає упевненість як кінцевий продукт, підтверджує, що всі заявлені
функціональні вимоги реалізовані, додаток їм відповідає і не має
помилок в програмному коді;
‒ підтверджує, що додаток здатний виконуватися у всіх заявлених
режимах і на всіх підтримуваних ОС або web-браузерах коректно;
‒ гарантує, що дані, що зберігаються і оброблювані, надійно захищені
від стороннього доступу і "злому";
‒ визначає, яка максимальне навантаження на сервер, локальну
мережу, БД може бути коректно оброблена додатком;
‒ дозволяє переконатися в тому, що користувач може "інтуїтивно"
використовувати ваш продукт або послугу, не плутаючись в
складних переплетеннях інтерфейсів.
Тестування програмного коду - процес виконання програмного коду,
спрямований на виявлення існуючих в ньому дефектів. Під дефектом тут
розуміється ділянка програмного коду, виконання якого за певних умов
призводить до несподіваного поведінки системи (тобто поведінки, не
відповідає вимогам). Несподівана поведінка системи може призводити до
збоїв у її роботі і відмов, в цьому випадку говорять про суттєві дефекти
програмного коду. Деякі дефекти викликають незначні проблеми, що не
порушують процес функціонування системи, але трохи ускладнюють роботу
з нею. В цьому випадку говорять про середні або малозначні дефекти.
Мета застосування процедури тестування програмного коду -
мінімізація кількості дефектів (особливо істотних) в кінцевому продукті.
Тестування само по собі не може гарантувати повну відсутність дефектів у
програмному коді системи. Однак, в поєднанні з процесами верифікації та
валідації, спрямованими на усунення суперечливості і неповноти проектної
документації (зокрема - вимог на систему), грамотно організоване тестування
дає гарантію того, що система задовольняє вимогам і веде себе відповідно до
них у всіх передбачених ситуаціях.
Для роботи із базою даних потрібне постійне і надійне з'єднання. Дана
функція встановлює постійний зв'язок із базою даних а також при збої
транзакцій бази даних автоматично відновлює їх. Тестовий запис інформації
у базу даних показав хороший результат виконання транзакцій у часі, що дає
змогу розробити оптимізований алгоритм тестування.
Тестування технології полягало у надсиланні тестових запитівна сервер
із передачею параметрів. Параметри визначались як тестова інформація для
передачі скриптам Web-сервера. Тестування швидкості надсилання запитів
показало що всі запити досить швидко відправлялись та оброблялись
тестовими скриптами на сервері. Не було виявлено затримки та відповіді від
сервера-приймача.
При реєстрації чи або авторизації користувача завірюється
запрограмований код створення сесії користувача. При тестовому
навантаженні реєстрації користувачів, сесії були автоматизовано присвоєні
всім користувачам без явної затримки. Це дає змогу оцінити з якісної
сторони алгоритм аутентифікації у системі. Працездатність роботи
алгоритму роботи сесій користувача була на найвищому рівні за всіма
показниками.
Текст
програми
Результати
Помилки Виправлення
тестів
Тестування Оцінювання Відлагодження
Інтенсивність
Початкові дані Очікувані помилок
для запуску результати
Модель
надійності
Прогноз надійності
Рисунок 3.1 - Інформаційні потоки процесу тестування
При використанні бази даних у тестовому варіанті наповнення даними
не було виявлено затримок та простою. Таблиці заповнювались даними без
зайвих проблем та зауважень. Кожна таблиця бази даних має режим
хешування даних, тому час ви конання запитів до бази даних значно менший.
При запуску Web-додатку на різних версіях браузера не було суттєвої
різниці у якості відображення Web сторінок та її контенту. Всі Web сторінки
відображались коректно та злагоджено, що свідчить про адаптивність вед
додатку у різних сімейств браузерів.
Представимо загальну структуру по видам існуючих тестів на рисунку
3.2.
Рисунок 3.2 – Загальні види тестувань
Тестування є вкрай важливим для репутації сайту. Що зробить
відвідувач, якщо не зможе додати запис у форум, або якщо стаття, що
цікавить його, буде не доступною, оскільки до неї невірно прописано шлях?
Правильно, він може піти і більше не повернутися [18-19]. Тестування не
може показати відсутність дефектів (воно може показувати тільки
присутність дефектів).
На вході процесу тестується три потоки:
- текст програми;
- вихідні дані для запуску програми;
- очікувані результати.
Розглянемо декілька з представлених видів тестувань на нашому проекті.
3.2 Функціональне тестування системи
Розпочнемо перевірку системи на тестування логічної побудови
вцілому. Основна ідея в тестуванні системи як «чорного ящика» полягає в
тому, що всі матеріали, які доступні тестувальнику - вимоги на систему, що
описують її поведінку, і сама система, працювати з якою він може, тільки
подаючи на її входи деякі зовнішні впливи і спостерігаючи на виходах
деякий результат. Всі внутрішні особливості реалізації системи приховані від
тестувальника, таким чином, система являє собою «чорний ящик»,
правильність поведінки якого по відношенню до вимог і належить
перевірити.
З точки зору програмного коду «чорний ящик» може представляти з
собою набір класів (або модулів) з відомими зовнішніми інтерфейсами, але
недоступними вихідними текстами.
Основне завдання тестувальника для даного методу тестування полягає
в послідовній перевірці відповідності поведінки системи вимогам. В
результаті тестування зазвичай виявляється два типи проблем системи:
невідповідність поведінки системи вимогам та неадекватна поведінка
системи в ситуаціях, не передбачених вимогами.
Звіти по обох типах проблем документуються і передаються
розробникам. При цьому проблеми першого типу зазвичай викликають зміну
програмного коду, набагато рідше - зміну вимог. Зміна вимог в даному
випадку може знадобитися через їх суперечливості (кілька різних вимог
описують різні моделі поведінки системи в одній і тій самій ситуації) або
некоректності (вимоги не відповідають дійсності).
Проблеми другого типу однозначно вимагають зміни вимог через їх
неповноту - у вимогах явно пропущена ситуація, яка веде до неадекватної
поведінки системи. При цьому під неадекватною поведінкою може
розумітися як повний крах системи, так і взагалі будь-яка поведінка, не
описана в вимогах.
При тестуванні системи як білого ящика тестувальник має доступ не
тільки до вимог до системи, її входів і виходів, а й до її внутрішньої
структури, тобто бачить її програмний код [19-20]. Тестування за методом
«чорного ящика» називають також тестуванням за вимогами, тому що це
єдине джерело інформації для побудови тест-плану.
Рисунок 3.3 - Тестування реєєстрації автоматизованої інформаційної системи
Тестування технології полягало у надсиланні тестових запитів на
сервер із передачею параметрів через термінал. Параметри визначались як
тестова інформація для передачі скриптам Web сервера. Тестування
швидкості надсилання запитів показало що всі транзакції досить швидко
відправлялись та оброблялись тестовими скриптами на сервері.
При використанні бази даних у тестовому варіанті наповнення даними
не було виявлено затримок та простою. Таблиці заповнювались даними без
зайвих проблем та зауважень. Кожна таблиця бази даних має режим
хешування даних, тому час ви конання запитів до бази даних значно менший
(рисунок 3.3).
Рисунок 3.4 - Тестування входу в інформаційну систему
Для тестування автоматизованої системи ведення сімейного обліку
застосовано функціональний вид тестування на бразеурі Chronium. При
даному підході текст програми не доступний, і програма розглядається як
«чорний ящик».
Метою тестування автоматизованої інформаційної системи є
визначення того, на скільки коректно вона виконує свої функції. У даному
випадку додаток повинен надавати інформацію про бюджет зареєстрованого
користувача. Якщо ж користувач не зареєстрований - надати йому
можливість зареєструватися. Після автоматизовано-інформаційної системи
додатку з’являється головна сторінка.
Далі натиснувши на пункт меню Увійти ми потрапляємо на сторінку
авторизації, в якому користувачу необхідно ввести свій логін і пароль. Якщо
ж користувач не зареєстрований, йому необхідно перейти на сторінку
реєстрації, про успішну реєстрацію (рисунок 3.4). Система видає правильний
результат направивши нас на головну сторінку, отже, тестування функції
реєстрації користувача пройшло успішно.
Також, для віновлення паролю, є пункт у формі входу, при якому
генерується випадковий пароль та скидається на імейл користувача (рисунок
3.5).
Рисунок 3.5 - Тестування входу в автоматизовану систему
Заходим на сторінку Контакти, та заповнюємо форму, натискаємо
Додати повідомлення після чого дані відправляються в базу данних.
При вході на сторінку Юзери, бачимо зареєстрованих користувачів, та
можемо видалити їх, натиснувши на посилання Знищити, якщо все вірно, то
система відправляє нас на головну сторінку (рисунок 3.6).
На сторінці Аналітика можемо побачити, графіки які створенні та
повністю відповідають нашій спроектованій базі даних (рисунок 3.7).
Потрапивши на сторінку облік, ми потрапляємо на профіль, де є
посилання на таблицю обліку, яке працює коректно.
Рисунок 3.6 - Тестування входу в систему
Рисунок 3.7 - Аналітика інформаційної системи
Опинившись на сторінці ведення обліку можемо додати дохід чи
витрату. Після натиснення Додати зміни, значення записуються у базу
данних, якщо ми потрапляємо на сторінку таблиці обліку, то все працює
коректно.
При запуску Web-додатку на різних версіях браузера не було суттєвої
різниці у якості відображення Web-сторінок та її контенту. Всі Web-сторінки
відображались коректно та злагоджено, що свідчить про адаптивність
розробленого додатку у різних сімейств браузерів.
Отже, протестувавши основні функції мобільного додатку методом
«чорного ящика» збоїв і помилок у роботі не виявлено, програма
функціонально працює коректно.
3.3 Структурне тестування програмного продукту
Розглянемо другий спосіб класичного тестування, це структурне
тестування або тестування «білого ящика», яке необхідне для перевірки
правильності роботи програмного забезпечення. Особливості наступні:
відома внутрішня структура програми. Тобто, об'єктом тестування тут є не
зовнішня, а тільки внутрішня поведінка програми. Перевіряється коректність
побудови всіх елементів програми і правильність їх взаємодії один з одним.
Зазвичай аналізуються керуючі зв'язку елементів, рідше - інформаційні
зв'язки. Тестування за принципом «білого ящика» характеризується
ступенем, в якій тести виконують або покривають логіку (вихідний текст)
програми [20].
Зазвичай тестування «білого ящика» засноване на аналізі керуючої
структури програми. Програма вважається повністю перевіреної, якщо
проведено вичерпне тестування маршрутів (шляхів) її графа управління.
Досліджуються: внутрішні елементи програми та зв'язки між ними:
„ Білий ящик ”
Х Y
Входи Виходи
Рисунок 3.9 – Загальне представлення тестування «білого ящика»
У цьому випадку формуються тестові варіанти, в яких:
‒ гарантується перевірка всіх незалежних маршрутів програми;
‒ проходяться гілки True, False для всіх логічних рішень;
‒ виконуються всі цикли (у межах їх меж і діапазонів);
‒ аналізується правильність внутрішніх структур даних.
Проведемо тестування тієї частини програмного кода, яка прописана
для закупівель будь-якого характеру для сімейного споживання. Це можуть
бути як оптові закупівлі на базах, так і штучні покупки в магазинах будь-
якого призначення.
Тому проведемо деякі цікаві тестування програмного коду:
1 Тестування на введення даних.
При введені кількості товару можна випадково ввести букву і після
цього в програмі виникає помилка (рисунок 3.10 – 3.11):
Рисунок 3.10 - Введення не коректних даних
Рисунок 3.11 – Помилка при введені не коректних даних
Ця проблема вирішується за допомогою процедури на натиснення
клавіші, тобто в поле можна ввести лише цифри , а «#8» це код натиснення
клавіші «Backspace», для того щоб можна було редагувати кількість.
Програмно це має наступний вигляд:
procedure TfrmKolichestvo.edtKolichestvoKeyPress(Sender: TObject;
var Key: Char);
begin
if Not (Key in ['0'..'9', #8])then Key:=#0;
end;
end.
2 Тестування умов.
Рисунок 3.12 – Введені не всі дані
Дана процедура призначена для додавання товару в загальну базу
сімейних закупок, оскільки для додавання в таблицю потрібно щоб всі поля
були заповнені я розробив наступну умову щоб запобігти помилкам (рисунки
3.12-3.13).
Рисунок 3.13 – Помилка що виникає при введені не всіх даних
Програмний код виглядає наступним чином:
procedure TfrmAddTovar.AddBtnClick(Sender: TObject);
begin
DataModule1.qry1.Active:=False;
DataModule1.qry1.SQL.Clear;
DataModule1.qry1.SQL.text:='select * from Tovar where id_tovara = '+
num.Text+' or name_tovara='+ QuotedStr(name.Text) ;
DataModule1.qry1.Active:=True;
if DataModule1.qry1.RecordCount > 0 then
begin
ShowMessage('№ товару або назва товару вже існує');
num.SetFocus;
end
else
begin
DataModule1.tblTovar.Edit;
DataModule1.tblTovar.Append;
DataModule1.tblTovar.Fields[0].Value:= num.Text;
DataModule1.tblTovar.Fields[1].Value:= name.Text;
DataModule1.tblTovar.Fields[2].Value:= Proizvod.Text;
DataModule1.tblTovar.Fields[3].Value:= cena.Text;
DataModule1.tblTovar.Post;
DataModule1.qry1.SQL.Clear;
DataModule1.qry1.SQL.Text:= 'INSERT INTO sklad (id_tovara,
kolichestvo) VALUES ('+num.Text+', 0)' ;
DataModule1.qry1.ExecSQL;
frmAddTovar.Close;
end;
end;
Тому, щоб уникнути даної помилки потрібно поставити умову, яка б не
виконувала додавання до таблиці, коли пропущені деякі поля:
procedure TfrmAddTovar.AddBtnClick(Sender: TObject);
begin
if (Length(num.Text) =0) or
(Length(name.Text)=0) or
(Length(Proizvod.Text)=0) or
(Length(cena.Text)=0) or
(Proizvod.Text = 'Натисніть ЛКМ')
then
ShowMessage('Заповніть всі поля') else
begin
DataModule1.qry1.Active:=False;
DataModule1.qry1.SQL.Clear;
DataModule1.qry1.SQL.text:='select * from Tovar where id_tovara = '+
num.Text+' or name_tovara='+ QuotedStr(name.Text) ;
DataModule1.qry1.Active:=True;
…
end;
При цьому помилки в програмі не буде, а лише з’явиться вікно з
повідомленням (рисунок 3.14):
Рисунок 3.14 – Повідомлення коли пропущене хоча б одне поле
3 Тестування запитів.
Помилка виникає в процедурі створення накладної при закупівлі
побутових або харчових товарів. Помилка виникає тому що в процедурі
«TfrmNakladna.FormShow» при звертанні до об’єкта qry1 не має даних, це
викликано там що об’єкт qry1 не виконує запит що був йому переданий
(рисунок 3.15).
Рисунок 3.15 – Помилка при звертанні до об’єкта qry1
Програмно це виглядає так:
procedure TfrmNakladna.FormShow(Sender: TObject);
var date: TDateTime;
begin
DataModule1.qry1.SQL.Clear;
DataModule1.qry1.SQL.Text:='SELECT * FROM jyrnal_naklad';
nomnaklad.Text:= IntToStr( DataModule1.qry1.RecordCount +1);
date:=Now;
data.Text:=FormatDateTime('dd.mm.yy', date);
nomnaklad.ReadOnly:=True;
data.ReadOnly:=True;
DataModule1.qry1.SQL.Clear;
DataModule1.qryNakladna.SQL.Clear;
DataModule1.qryNakladna.SQL.Text:='SELECT tovar.id_tovara,
tovar.name_tovara, nakladna.cena, nakladna.kolichestvo, nakladna.summa'+
' FROM nakladna, tovar WHERE
nakladna.id_tovara=tovar.id_tovara AND
nakladna.id_naklad='+nomnaklad.Text;
DataModule1.qryNakladna.Active:= True;
end;
Тому потрібно знайти рядок запиту qry1 і після нього активувати
запит:
procedure TfrmNakladna.FormShow(Sender: TObject);
var date: TDateTime;
begin
DataModule1.qry1.SQL.Clear;
DataModule1.qry1.SQL.Text:='SELECT * FROM jyrnal_naklad';
DataModule1.qry1.Active:= True;
…
end;
4 Тестування циклів.
При виконанні наступної процедури, а саме збереження накладної
відбувається віднімання кількості товару із складу, але при її виконанні
програма входить в безкінечний цикл, тому потрібно шукати помилку в
умові:
procedure TfrmNakladna.N1Click(Sender: TObject);
var kol:Integer;
begin
if Length(zPdv.Text) > 0 then
begin
DataModule1.qry1.SQL.Clear;
DataModule1.qry1.SQL.Text:='INSERT INTO Jyrnal_naklad (id_naklad,
data, sum_bez_pdv, sum_z_pdv) VALUES('+nomnaklad.Text+','+
QuotedStr(DateToStr(date))+','+ bezPdv.Text+','+ zPdv.Text +')';
DataModule1.qry1.ExecSQL;
DataModule1.qryNakladna.First;
while not DataModule1.qryNakladna.Eof do
begin
kol:=0;
DataModule1.qry1.SQL.Clear;
DataModule1.qry1.SQL.Text:='SELECT kolichestvo FROM sklad WHERE
id_tovara='+DataModule1.qryNakladna.Fields[0].AsString;
DataModule1.qry1.Active:=True;
kol:= DataModule1.qry1.Fields[0].AsInteger -
DataModule1.qryNakladna.Fields[3].AsInteger;
DataModule1.qry1.SQL.Clear;
DataModule1.qry1.SQL.Text:='UPDATE sklad SET kolichestvo ='+
IntToStr(kol)+' WHERE
id_tovara='+DataModule1.qryNakladna.Fields[0].AsString;
DataModule1.qry1.ExecSQL;
end;
Close;
end else
begin
ShowMessage('Ââåä³òü òîâàð!!!');
end;
end;
procedure TfrmNakladna.N1Click(Sender: TObject);
…
while not DataModule1.qryNakladna.Eof do
begin
…
DataModule1.qryNakladna.Next;
end;
Close;
end else
begin
ShowMessage('Ââåä³òü òîâàð!!!');
end;
end;
3.4 Регресійне тестування (REGRESSION TESTING)
Це вид тестування спрямований на перевірку змін, зроблених в додатку
або навколишньому середовищі (усунення дефекту, злиття коду, міграція на
іншу операційну систему, базу даних, веб сервер або сервер додатки), для
підтвердження того факту, що існуюча раніше функціональність працює як й
раніше. Як правило, для регресійного тестування використовуються тест
кейси, написані на ранніх стадіях розробки та тестування. Це дає гарантію
того, що зміни в новій версії програми не пошкодили вже існуючу
функціональність.
У Microsoft Test Manager визначено основний тестовий план, й для
кожного PBI відповідні тести функцій (рисунок 3.16) та збирається білд й
починаємо тестувати додаток згідно з планом (рисунок 3.17).
З досвіду розробки ПЗ відомо, що повторна поява одних й тих же
помилок – випадок досить частий. Іноді це відбувається через слабку техніки
управління версіями або з причини людської помилки при роботі з системою
управління версіями. Але настільки ж часто вирішення проблеми буває
«недовго живуть»: після наступного зміни в програмі рішення перестає
працювати. І нарешті, при переписуванні якої-небудь частини коду часто
спливають ті ж помилки, що були в попередній реалізації.
Рисунок 3.16 - Визначення основного тестового плану
та відповідні тести функцій
Опишемо три основних визначення регресійного тестування:
‒ регресія багів (Bug regression) – спроба довести, що виправлена
помилка насправді не виправлена;
‒ регресія старих багів (Old bugs regression) – спроба довести, що
нещодавня зміна коду або даних зламало виправлення старих
помилок, тобто старі баги стали знову відтворюватися;
‒ регресія побічного ефекту (Side effect regression) – спроба довести,
що нещодавня зміна коду або даних зламало інші частини додатку
що
розробляється.
Тим самим тестувальник може значно заощадити час на перевірку
білду, й провести тільки ті тести, в код програми яки було внесено зміни
програмістами. Залежно від контексту терміну "Регресійне тестування", може
мати різний зміст.
Рисунок 3.17 - Початок тестування додатоку згідно з планом
Рисунок 3.18 - Проходження всіх тестів для програмного продукту
Проходження всіх особливостей представлено на рисунку 3.18.
Надалі виникає потреба показати наочно всі результати проходження
проекту та виявлення особливостей при регресійному тестуванні (рисунок
3.19).
Рисунок 3.19 – Результати проходження
Регресійне тестування може бути використано не тільки для перевірки
коректності програми, а також використовується для оцінки якості
отриманого результату. Так, при розробці компілятора при прогоні
регресійних тестів розглядається розмір одержуваного коду, швидкість
виконання й час компіляції кожного з тестових прикладів.
На запитання, коли і як проводити регресійне тестування, та які тести
ставити в першу чергу відповісти не просто. Усе визначається видом
розроблювального ПЗ, тривалістю життєвого циклу, термінами тестування,
кількістю членів команди.
Наприклад, внесемо зміни для тестування в програмий код, тоді
отримаємо наступні дії, що зображено на рисунку 3.20.
Проходження регресійного тестування це етап обовязковий після
кожної зміни програмного кода вцілому або хоча б деякої змістовної його
частини.
Рисунок 3.20 - Зміни в коді програми
Особливості проведення регресійного тестування:
1 Регресійне тестування проводиться в кожній новій версії.
2 Починають регресійне тестування з тестів верифікації версії. Якщо
програма приходить від розробника у вигляді повноцінної
інсталяції, то тести верифікації починаються з перевірки інсталяції,
після чого проводиться короткий набір тестів функціональності.
Якщо хоча б один з тестів failed, версія передається на
доопрацювання, регресійне тестування припиняється, а тестер
повертається до тестування останньої "робочої" версії.
3 Після успішного проходження тестів верифікації версії, проводять
серію тестів верифікації багів.
4 З тестів регресії проводять лише ті, які пов'язані зі зміненою в новій
версії ділянкою коду.
5 Аналогічним чином (п.4) відбираються тести в групу регресії на
"закритих" багах.
6 Тести регресії, виконані успішно (pass) двічі вважаються
"закритими".
7 Для тестів регресії, які передбачається проводити більше 3-5 разів
рекомендується писати скрипти для автоматизації процесу. Це
відноситься до всіх груп тестів регресії.
8 Відбір тестів для фінального регресійного тестування здійснюється
за такими принципами:
‒ у першу чергу відбирають тести забраковані (failed) два та
більше разів, а також й ті, які виявляли баги, вимагають
доопрацювання (re-do);
‒ у другу чергу відбираються тести забраковані один раз, й
успішно пройдені повторно;
‒ далі відбираються всі тести, які були пройдені успішно (pass),
але проводилися тільки один раз;
‒ потім проводяться всі інші тести, залежно від поставленого
завдання.
Значні переваги регресійного тестування:
‒ при регулярному проведенні регресійного тестування – значне
скорочення кількості дефектів в системі до моменту релізу;
‒ виключення деградації якості системи при зростанні
функціональності;
‒ •зменшення ймовірності критичних помилок в дослідно-
промисловій експлуатації.
3.5 Подання звітів про тестування
Найкращім видом та поданням звітності по будь-якій проведенній дії є
її графічне зображення у вигляді графіків або діаграм. Тому ми також
вирішили зробити підсумкові звіти у належному стані, та показати
оформлення та можливості спеціальних програм для надання звітності.
Наприклад ми маємо змогу побачити графік пройдених тест-кейсів по
кількості дефектів, що зображено на рисунку 3.21 або наприклад, графік
пройдених тест-кейсів по модулям, який наочно покаже, який обсяг роботи в
кожному з модулів вже пророблений та допоможе виявити проблеми, що
зображено на рисунку 3.22.
Рисунок 3.21 - Графік пройдених тест-кейсів по кількості дефектів
Рисунок 3.22 - Графік пройдених тест-кейсів по модулям
До діаграми або графіку можливо такожо надати зведений графік з
усіма даними та інформацією про виявлені помилки в ході тестування
різними способами та за різним призначенням, з якими доводилося мати
справу за весь період розробки. Це зображено на рисунку 3.23.
Рисунок 3.23 – Загальний графік з інформацією про помилки
Висновки до третього розділу
В розділі зроблено тестування програмного продукта різними
класичними методами тестування. Програмний продукт обґрунтовано та
протестоване на наявність помилок завдяки розглянутим в роботі методам
тестування, а саме розподілимо їх на відповідні категорії, тобто на ті, що
зустрічаються найчастіше:
1 Функціональні недоліки властиві програмі, якщо вона не робить того,
що повинна, виконує одну зі своїх функцій погано або не повністю. Функції
програми мають бути детально описані в її специфікації, і саме на основі
затвердженої специфікації тестувальник будує свою роботу.
2 Недоліки призначені для користувача інтерфейсу. Оцінити зручність і
правильність роботи призначеного для користувача інтерфейсу можна тільки
в процесі роботи з ним. Бажано, щоб в цій роботі брав участь сам користувач.
3 Недостатня продуктивність. При розробці програмного продукту
дуже важливою його характеристикою може виявитися швидкість роботи,
іноді цей критерій задається у вимогах замовника. Погано, якщо у
користувача створюється враження, що програма працює повільно.
4 Некоректна обробка помилок. Процедури обробки помилок – дуже
важлива частина програми. Правильно визначивши помилку, програма
повинна видати про неї повідомлення.
5 Помилки обчислень. Сюди належать помилки, викликані
неправильним вибором алгоритму обчислень, неправильними формулами.
Найпоширенішими є помилки округлення.
6 Помилки управління потоком. За логікою роботи програми услід за
першою дією повинна бути виконана друга. Якщо замість цього виконується
третя або четверта дія, значить, в управлінні потоком припустилися помилки.
7 Перевантаження. Збої в роботі програми можуть відбуватися із-за
нестачі пам’яті або відсутності інших необхідних системних ресурсів.
Тестування автоматизованої системи проведено функціональним
методом, під час якого текст програми не доступний, і вона розглядається
як «чорний ящик». Тестування підтвердило ефективність та правильність
функціонування розробленої автоматизовано-інформаційної системи для
ведення сімейного бюджету.
Зазвичай тестування «білого ящика» засноване на аналізі керуючої
структури програми. Програма вважається повністю перевіреної, якщо
проведено вичерпне тестування маршрутів (шляхів) її графа управління.
Також проведено регресійне тестування (REGRESSION TESTING), яке
спрямоване на перевірку змін, зроблених в додатку або навколишньому
середовищі (усунення дефекту, злиття коду, міграція на іншу операційну
систему, базу даних, веб сервер або сервер додатки), для підтвердження
того факту, що існуюча раніше функціональність працює як й раніше. Як
правило, для регресійного тестування використовуються тест кейси,
написані на ранніх стадіях розробки та тестування. Це дає гарантію того, що
зміни в новій версії програми не пошкодили вже існуючу функціональність.
Та зроблено графічний аналіз проведених тестувань і представлено у
вигляді графіків та діаграм.
ВИСНОВКИ
В першому розділі роботи обґрунтовано необхідність проектування
автоматизованої інформаційної системи, розробки реляційної бази даних для
підвищення ефективності та зрозумілості ведення сімейних розрахунків.
Автоматизована інформаційна система - це реалізований в мережі Інтернет
Web-додаток, шляхом створення Web-сервера для послуг ведення сімейного
бюджету.
Розглянуто візульне покращення сайту у вигляді підбору палітри
кольорів, що робить його лаконічним, а сам дизайн повинен бути
побудований так, що не порушує основні закономірності впливу кольорів на
психологічну реакцію організму, тобто відповідає стійким гармонійним
поєднанням кольорів.
А завдяки розглянутим в розділі особливостям проектування
інформаційної системи було виділено три рівні проектування з огляду бази
даних на архітектурному підґрунті та виділені основні графічні взаємозв’язки
даних в межах архітектурної будови.
Другий розділ існуючих рішень та обґрунтування вибору прийнятого
принципу побудови додатку приводиться з метою з'ясування необхідності
та актуальності розробки програмного продукту, проаналізовано його
архітектуру та структуру з використанням шаблону проектування Model-
View-Controller, головною перевагою якого є розділення коду інтерфейсу
користувача і іншого коду. Розроблені інструменти керування
автоматизованої інформаційної системи для ведення сімейного бюджету є
Web-додатком, оскільки вона написана під усі платформи, які мають
браузер та надає користувачу послуги, а саме - можливість обліку його
фінансового стану, та представлення у графічному вигляді.
В третьому розділі розглянута основна ідея дослідження програмного
продукту у вигляді тестування системи і полягає воно в тому, що всі
матеріали, які доступні тестувальнику - вимоги на систему, що описують її
поведінку, і сама система, працювати з якою він може, тільки подаючи на її
входи деякі зовнішні впливи і спостерігаючи на виходах деякий результат.
Всі внутрішні особливості реалізації системи приховані від тестувальника,
таким чином, система являє собою «чорний ящик», правильність поведінки
якого по відношенню до вимог і належить перевірити. Основне завдання
тестувальника для даного методу тестування полягає в послідовній перевірці
відповідності поведінки системи вимогам. Проте в реальності в результаті
тестування зазвичай виявляється два типи проблем системи: невідповідність
поведінки системи вимогам, неадекватна поведінка системи в ситуаціях, не
передбачених вимогами.
А також проведено структурне тестування, що дозволило на аналізі
керуючої структури програми виявити недоліки в таких напрямках, як:
тестування циклів, де при виконанні процедури програма входить в
безкінечний цикл, тому потрібно шукати помилку в умові. Програма
вважається повністю перевіреної, якщо проведено вичерпне тестування
маршрутів (шляхів) її графа управління; тестування запитів, де помилка
виникає в процедурі створення накладної при закупівлі побутових або
харчових товарів. Помилка виникає тому що в процедурі при звертанні до
конктерного об’єкта не має даних, це викликано там що об’єкт не виконує
запит що був йому переданий; тестування на введення даних, де при введені
кількості товару можна випадково ввести букву і після цього в програмі
виникає помилка; тестування умов для запобігання виникнення помилок при
заповненні табличних форм бази даних.
Також проведено регресійне тестування, яке спрямоване на перевірку
змін, зроблених в додатку для підтвердження того факту, що існуюча раніше
функціональність працює як й раніше. Як правило, для регресійного
тестування використовуються тест кейси, написані на ранніх стадіях
розробки та тестування. Це дає гарантію того, що зміни в новій версії
програми не пошкодили вже існуючу функціональність.
Зроблено графічний аналіз проведених тестувань і представлено у
вигляді графіків та діаграм.
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
a. 1 «Розробка бази даних засобами SQLITE та проектування web-додатку
патерном MODEL-VIEW-CONTROLLER» Проблеми інформатизації :
восьма міжнародна науково-технічна конференція – 26-27 листопада
2020 року. Черкаси: ЧДТУ; Баку: ВА ЗС АР; Бельсько-Бяла: УТіГН;
Полтава: ПНТУ; секція 4. 2020.
2 Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки
программного обеспечения. – СПб.: Питер, 2002. – 496 с.
3 Орлов С.А. Технологии разработки программного обеспечения:
Учебник для вузов. 3-е издание. – СПб.: Питер, 2004. – 528 с.
4 Мюллер Р. Д. Базы данных и UML: Проектирование. – М.: Лори, 2002.
– 420 с.
5 Макконнелл С., Профессиональная разработка программного
обеспечения, – М.: Символ-Плюс, 2007. –240 с.
6 Мартин Р. Быстрая разработка программ. Принципы, примеры,
практика. М.: Вильямс, 2004. – 746 с.
7 Пущин М.Н. Проектирование информационных систем: Учебное
пособие. – М.: Изд-во МИЭТ, 2008. – 234 с.
8 Золотов С.Ю. Проектирование информационных систем : учебное
пособие / С.Ю.Золотов. – Томск : Эль Контент, 2013. – 88 с.
9 Гвоздева Т.В. Проектирование информационных систем : учебное
пособие / Т.В. Гвоздева, Б.А. Баллод. – Ростов н/Д : Феникс, 2009. – 508
с.
10 Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системи баз даних. Повний
курс. М.: Вильямс, 2003. - 412-465 с.
11 Internet, Сервiси, HTML i web дизайн. Глинський. Деол, 2002 - 168 с.
12 Камер Дуглас Компьютерные сети и Internet / Дуглас Камер - М.:
Вильямс, 2007. - 640 с.
13 Джамса К. Эффективный самоучитель по креативному Web - дизайну.
Перевод с англ. / Крис Джамса, Конрад Кинг, Энди Андерсон - М.:
ДиаСофтЮП, 2005. - 672 с.
14 Фрейн Б. HTML5 и CSS3. Разработка сайтов для любых браузеров и
устройств / Бен Фрейн - СПб.: Питер, 2014. - 304 с.
15 Гарретт Дж. Веб-дизаин: книга Джесса Гарретта. Элементы опыта
взаимодействия / Дж. Гарретт - М.: Символ-Плюс, 2008. - 192 с.
16 Язык программирования Ruby, Флэнаган Д., Мацумото Ю., 2008
17 Гибкая разработка веб-приложений в среде Rails (4-е изд.), Руби С.,
Томас Д., Хэнссон Д. Х., 2011. - 448 с.
18 Ruby on Rails Tutorial, Хартл М., 2011 - 247 с.
19 Дэн Сидерхолм - CSS3 для веб-дизайнеров. Издательство: Манн,
Иванов и Фербер, год издания: 2013, 125 стр.
20 Дронов В. А. HTML 5, CSS 3 и Web 2.0. Разработка современных Web-
сайтов. — СПб.: БХВ-Петербург, 2011. — 416 с.
ДОДАТОК А
«Затверджую»
Завідувач кафедри ПЗАС
проф. Станіслав ПЕРВУНІНСЬКИЙ
__________________
“___” _____________ 2021р.
Особливості проектування WEB-додатку та дослідження можливостей
шаблону проектування
Специфікація
482.ЧДТУ.212120-001
Листів 2
Розробник _______________ Богдан ДАНИЛЮК
Керівник _____________ Світлана КУНИЦЬКА
Черкаси 2021
2
482.ЧДТУ.212120-001 ПЗ
Позначення Найменування Примітка
482.ЧДТУ. 212120-01 12 01
Текст програми
482.ЧДТУ. 212120-01 90 01
Графічний матеріал
ДОДАТОК Б
Особливості проектування WEB-додатку та дослідження можливостей
шаблону проектування
Текст програми
482.ЧДТУ.212120-01 12 01
Листів 13
Розробник: ______________Богдан ДАНИЛЮК
Черкаси 2021
class AdminsController < ActionController::Base
layout 'admin/application'
end
class ApplicationController < ActionController::Base
protect_from_forgery with: :exception
helper_method :current_admin
before_action :configure_permitted_parameters, if: :devise_controller?
private
def current_admin
@current_user.admin
end
protected
def configure_permitted_parameters
attributes = [:email, :password, :password_confirmation, :avatar, :name]
devise_parameter_sanitizer.permit(:sign_up, keys: attributes)
devise_parameter_sanitizer.permit(:account_update, keys: attributes)
end
end
class UsersController < ApplicationController
def show
@user = User.find(params[:id])
end
end
class WelcomeController < ApplicationController
def index; end
end
class Admin::AnalitiksController < AdminsController
def index
@incomes = current_user.incomes
@outcomes = current_user.outcomes
@comes = Come.all
end
end
94
class Admin::ComesController < AdminsController
before_action :find_user, only: [:create, :index, :edit, :destroy]
def index
@incomes = current_user.incomes
@outcomes = current_user.outcomes
@comes = Come.all
end
def new
@come = Come.new
end
def show
end
def edit;end
def create
if come_params[:type] == "Income"
@come = @user.incomes.create(come_params)
end
if come_params[:type] == "Outcome"
@come = @user.outcomes.create(come_params)
end
@come.user_id = @user.id
if @come.save
redirect_to admin_user_comes_path(@user)
else
render 'new'
end
end
def update
@come = Come.update(come_params)
redirect_to admin_user_comes_path(@user)
end
def destroy
@user = User.find(params[:id])
@user.destroy
redirect_to admin_root_path
end
95
private
def find_user
@user = User.find(params[:user_id])
end
def come_params
params.require(:come).permit(:type, :value, :comment, :date, :user_id)
end
end
class Admin::ContactsController < AdminsController
before_action :find_contact, only: %i[show/]
def new
@contact = Contact.new
end
def create
Contact.create(contact_params)
redirect_to root_path
end
private
def contact_params
params.require(:contact).permit(:name, :email, :phone, :comment)
end
def find_contact
@contact = Contact.find(params[:id])
end
end
class Admin::UsersController < AdminsController
def index
@users = User.all
end
def show
@user = User.find(params[:id])
end
def destroy
@user = User.find(params[:id])
@user.destroy
96
redirect_to admin_root_path
end
end
class ApplicationRecord < ActiveRecord::Base
self.abstract_class = true
end
class Come < ApplicationRecord
belongs_to :user
end
class Outcome < Come
belongs_to :user
end
class Income < Come
belongs_to :user
end
class Contact < ApplicationRecord
end
class User < ApplicationRecord
mount_uploader :avatar, AvatarUploader
has_many :incomes
has_many :outcomes
has_many :come
# Include default devise modules. Others available are:
# :confirmable, :lockable, :timeoutable and :omniauthable
devise :database_authenticatable, :registerable,
:recoverable, :rememberable, :trackable, :validatable
end
<%= javascript_include_tag "//www.google.com/jsapi", "chartkick" %>
<%= pie_chart Come.group(:type).count %>
<%= line_chart Come.group(:type).group_by_day(:date).count, xtitle: "Date", ytitle: "Value" %>
<h1>New come</h1>
<%= form_with scope: :come, url: admin_user_comes_path do |f| %>
<div class="field">
<%= f.label :value %><br />
<%= f.text_field :value %>
</div>
97
<div class="field">
<%= f.label :comment %><br />
<%= f.text_field :comment %>
</div>
<div>
<%= f.label :date %>
<%= f.date_field :date %>
</div>
<div>
<%= f.label :type %>
<%= f.select :type, ["Income", "Outcome"], default: "income" %>
</div>
<%= f.submit %>
<% end %>
<h1>New come</h1>
<div class="row">
<div class="col-md-3"></div>
<div class="col-md-6 form form-group">
<%= form_with scope: :come, url: admin_user_comes_path do |f| %>
<p>
<div class="field">
<%= f.label :value, class: "label label-default form-control" %><br />
<%= f.text_field :value, class: "form-control" %>
</div>
</p>
<p>
<div class="field">
<%= f.label :comment, class: "label label-default form-control"%><br/>
<%= f.text_field :comment, class: "form-control" %>
</div>
</p>
<p>
<div>
<%= f.label :am_or_pm, class: "label label-default form-control" %>
<%= f.date_field :date, {class: "form form-group form-control"} %>
</div>
</p>
<p>
<div>
98
<%= f.label :type, class: "label label-default" %>
<%= f.select :type, ["Income", "Outcome"], class: "btn btn-primary",
default: "income" %>
</div>
</p>
<%= f.submit 'add come', class: "btn btn-lg btn-primary" %>
<% end %>
</div>
</div>
<div class="col-md-6 form form-group">
<%= form_with scope: :contact, url: admin_contacts_path do |f| %>
<p>
<div class="field">
<%= f.label :name, class: "label label-default form-control" %><br />
<%= f.text_field :name, class: "form-control" %>
</div>
</p>
<p>
<div class="field">
<%= f.label :email, class: "label label-default form-control" %><br />
<%= f.text_field :email, class: "form-control" %>
</div>
</p>
<p>
<div class="field">
<%= f.label :phone, class: "label label-default form-control" %><br />
<%= f.text_field :phone, class: "form-control" %>
</div>
</p>
<p>
<div class="field">
<%= f.label :comment, class: "label label-default form-control"%><br/>
<%= f.text_field :comment, class: "form-control" %>
</div>
</p>
<%= f.submit 'add contact', class: "btn btn-lg btn-primary" %>
<% end %>
</div>
</div>
$('#user_ <%= @user.id %>').remove()
99
<div class="row">
<div class="col-md-2"></div>
<div class="col-md-8 table-striped">
<table class="table">
<thead>
<tr>
<th>email</th>
<th>admin</th>
<th>avatar</th>
<th>action</th>
</tr>
</thead>
<tbody>
<% @users.each do |user| %>
<tr>
<th><%= user.email %></th>
<th><%= user.admin %></th>
<th><%= image_tag(user.avatar.url(:thumb).to_s) %></th>
<th><%= link_to 'destroy', admin_user_path(user), method: :delete, remote: true
%></th>
</tr>
<% end %>
</tbody>
</table>
</div>
<div class="col-md-2"></div>
</div>
<h1>Профиль</h1>
<p>email: <%= @user.email %></p>
<p>name: <%= @user.name %></p>
<%= image_tag(@user.avatar.url(:thumb).to_s) %>
<%= link_to 'show comes', admin_user_comes_path(@user) %>
<!DOCTYPE html>
<html>
<head>
<title>TwoApp</title>
<script src="https://d3js.org/d3.v4.min.js"></script>
<%= csrf_meta_tags %>
<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>
</head>
100
<body>
<nav class="navbar navbar-inverse">
<div class="container-fluid">
<div class="navbar-header">
<a class="navbar-brand" href="#">WebSit</a>
</div>
<ul class="nav navbar-nav">
<li class="active"><a href="#">Home</a></li>
<% if current_user %>
<li><%= link_to "analitiks", admin_analitiks_path %></li>
<% if current_admin %>
<li><%= link_to 'My comes', admin_user_path(current_user) %></li>
<% end %>
<li><%= link_to 'sign_out', destroy_session_path(current_user), method: :delete %></li>
<% else %>
<li><%= link_to 'sign_in', new_user_session_path %></li>
<li><%= link_to 'sign_up', new_user_registration_path %></li>
<% end %>
<li><%= link_to 'contact', new_admin_contact_path %></li>
</ul>
</div>
</nav>
<%= yield %>
</body>
</html>
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<style>
/* Email styles need to be inline */
</style>
</head>
<body>
<%= yield %>
</body>
</html>
<!DOCTYPE html>
<html>
<head>
<title>TwoApp</title>
<%= csrf_meta_tags %>
101
<%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>
</head>
<body>
<%= render 'shared/admin/header' %>
<%= yield %>
</body>
</html>
<nav class="navbar navbar-inverse">
<div class="container-fluid">
<div class="navbar-header">
<a class="navbar-brand" href="#">WebSiteName</a>
</div>
<ul class="nav navbar-nav">
<li class="active"><%= link_to 'Home', root_path %></li>
<% if current_user %>
<li><%= link_to "analitiks", admin_analitiks_path %></li>
<li><%= link_to 'My comes', admin_user_path(current_user) %></li>
<li><%= link_to 'sign_out', destroy_session_path(current_user), method: :delete %></li>
<% else %>
<li><%= link_to 'sign_in', new_user_session_path %></li>
<li><%= link_to 'sign_up', new_user_registration_path %></li>
<% end %>
</ul>
</div>
</nav>
class AvatarUploader < CarrierWave::Uploader::Base
include CarrierWave::MiniMagick
storage :file
def store_dir
"uploads/#{model.class.to_s.underscore}/#{mounted_as}/#{model.id}"
end
version :thumb do
process :resize_to_fill => [100, 100]
end
102
def extension_white_list
%w(jpg jpeg gif png)
end
end
ActiveRecord::Schema.define(version: 20171208181330) do
create_table "comes", force: :cascade do |t|
t.string "type"
t.integer "user_id"
t.integer "value"
t.text "comment"
t.date "date"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
t.index ["user_id"], name: "index_comes_on_user_id"
end
create_table "contacts", force: :cascade do |t|
t.string "name"
t.string "email"
t.string "phone"
t.text "comment"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
create_table "users", force: :cascade do |t|
t.string "email", default: "", null: false
t.string "encrypted_password", default: "", null: false
t.boolean "admin", default: true
t.string "reset_password_token"
t.datetime "reset_password_sent_at"
t.datetime "remember_created_at"
t.integer "sign_in_count", default: 0, null: false
t.datetime "current_sign_in_at"
t.datetime "last_sign_in_at"
t.string "current_sign_in_ip"
t.string "last_sign_in_ip"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
t.string "avatar"
t.string "name"
t.index ["email"], name: "index_users_on_email", unique: true
t.index ["reset_password_token"], name: "index_users_on_reset_password_token", unique:
true
end
103
end
class DeviseCreateUsers < ActiveRecord::Migration[5.1]
def change
create_table :users do |t|
## Database authenticatable
t.string :email, null: false, default: ''
t.string :encrypted_password, null: false, default: ''
t.boolean :admin, default: true
## Recoverable
t.string :reset_password_token
t.datetime :reset_password_sent_at
## Rememberable
t.datetime :remember_created_at
## Trackable
t.integer :sign_in_count, default: 0, null: false
t.datetime :current_sign_in_at
t.datetime :last_sign_in_at
t.string :current_sign_in_ip
t.string :last_sign_in_ip
## Confirmable
# t.string :confirmation_token
# t.datetime :confirmed_at
# t.datetime :confirmation_sent_at
# t.string :unconfirmed_email # Only if using reconfirmable
## Lockable
# t.integer :failed_attempts, default: 0, null: false # Only if lock strategy is :failed_attempts
# t.string :unlock_token # Only if unlock strategy is :email or :both
# t.datetime :locked_at
t.timestamps null: false
end
add_index :users, :email, unique: true
add_index :users, :reset_password_token, unique: true
# add_index :users, :confirmation_token, unique: true
# add_index :users, :unlock_token, unique: true
end
end
class AddAvatarToUsers < ActiveRecord::Migration[5.1]
def change
add_column :users, :avatar, :string
add_column :users, :name, :string
end
end
class CreateComes < ActiveRecord::Migration[5.1]
def change
104
create_table :comes do |t|
t.string :type
t.references :user, foreign_key: true
t.integer :value
t.text :comment
t.date :date
t.timestamps
end
end
end
class CreateContacts < ActiveRecord::Migration[5.1]
def change
create_table :contacts do |t|
t.string :name
t.string :email
t.string :phone
t.text :comment
t.timestamps
end end end
<h2>Log in</h2>
<%= form_for(resource, as: resource_name, url: session_path(resource_name)) do |f| %>
<div class="field">
<%= f.label :email %><br />
<%= f.email_field :email, autofocus: true %>
</div>
<div class="field">
<%= f.label :password %><br />
<%= f.password_field :password, autocomplete: "off" %>
</div>
<% if devise_mapping.rememberable? -%>
<div class="field">
<%= f.check_box :remember_me %>
<%= f.label :remember_me %>
</div>
<% end -%>
<div class="actions">
<%= f.submit "Log in" %>
</div>
<% end %>
<%= render "devise/shared/links" %>
ДОДАТОК В
Особливості проектування WEB-додатку та дослідження можливостей
шаблону проектування
Графічний матеріал
482.ЧДТУ.212120-01 90 01
Листів 8
Розробник: ______________Богдан ДАНИЛЮК
Черкаси 2021
Додаток В.1 – Слайд 1
Додаток В.2 – Слайд 2
Додаток В.3 – Слайд 3
107
Додаток В.4 – Слайд 4
Додаток В.5 – Слайд 5
Додаток В.6 – Слайд 6
108
Додаток В.7 – Слайд 7
Додаток В.8 – Слайд 8
Додаток В.9 – Слайд 9
109
Додаток В.10 - Слайд 10
Додаток В.11 – Слайд 11
Додаток В.12 – Слайд 12
110
Додаток В.13 – Слайд 13
Додаток В.14 – Слайд 14
Додаток В.15 – Слайд 15
111
Додаток В.16 – Слайд 16
Додаток В.17 – Слайд 17
Додаток В.18 – Слайд 18
112
Додаток В.19 – Слайд 19
Додаток В.20 – Слайд 20
Додаток В.21 – Слайд 21