Дистанційна система навчання "Moodle"

Размещено на http://www.allbest.ru/

Вступ

moodle друкарня дистанційний програма

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

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

Дистанційне навчання розвивається дуже динамічно. Загальна кількість курсів дистанційного навчання у світі зростає більш ніж на 40% щорічно.

Дистанційна система навчання Moodle, добре справляється з поставленим завданням. Ця система відноситься до вільно поширюваного програмного забезпечення (Офіційний Internet сайт http://moodle.org).

Використання системи MOODLE не жадає фінансових витрат на придбання додаткових програмних продуктів і ми отримаємо ліцензійно чисте і на 100% легальне програмне забезпечення для організації дистанційного навчання. Легальність використання гарантується відкритою ліцензійною угодою GNU General Public License. Мета GNU GPL - надати користувачеві права використовувати, копіювати, модифікувати і поширювати програми.

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

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

1. Аналіз об'єкта проектування

1.1 Коротка характеристика підприємства

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

Базою практики була обрана друкарня «Добробут ». Основним видом діяльності є надання послуг з друку різної продукції. Друкарня має розвинену структуру й складається з декількох відділів. Організаційна структура друкарні «Добробут» відображена на рис. 1.1. Очолює фірму директор. Йому підкоряються наступні відділі:

1. Відділ збуту;

2. Бухгалтерія;

3. Планово-єкономічний відділ;

4. Виробничий відділ;

5. Складский відділ;

6. Склад;

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

Основними напрямками діяльності друкарні є:

- друк високоякісної рекламно-представницької продукції: журнали, буклети, брошури, листівки, плакати, папки, флаєри, візитки, листівки;

- друк бланкової продукції великими тиражами, тиражування на дуплікаторах, ксерокопіювання, виготовлення методичних посібників, брошур, книг у твердій та м'якій палітурці, інструкцій, каталогів;

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

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



Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис.

Рис. 1.2. Схема організаційної структури планово-економічного відділу

1.2 Аналіз предметної області

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

Пропонується встановити систему дистанційного навчання Moodle. Це програмне забезпечення подане як простий статичний HTML сторінка, так і складними системами управління навчанням, та навчальним контентом (Learning Content Management Systems), що буде реалізовувати функції бізнес-процесу «адміністрування». Бізнес-процес охоплює ряд функцій, які в комплексі ефективно вирішує поставлену задачу:

- налаштування повідомлень;

- налаштування зовнішнього вигляду; ;

- управління реєстрацією користувачів;

- створення звітів;

- налаштування мережевої взаємодії;

- налаштування сервера;

- створення комітетів;

Схема бізнес-процесу зображена на рис. 1.4. В табл. 1.1 наведена характеристика бізнес-процесу.

Таблиця 1.1. Характеристика бізнес-процесу «Створення комітету»

Назва характеристики	Значення характеристики
1	2
Ім'я бізнес-процесу	Створення комітету
Основні учасники	Адміністратор, президент комітету, член, сопредсідатель
Вхідна подія	Створення нового комітету
Вхідні документи	Розпорядження про створення нового комітету
Вихідна подія	Формування комітету
Вихідні документи	Розпорядження про створення комітету
Клієнт бізнес-процесу	Адміністратор



Рис. 1.3. Діаграма «Дерево функцій»



Рис. 1.4. Схема бізнес-процесу «Створення комітету»

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

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

Аналогами розроблюваної програми можуть бути такі програмні продукти: «Learning Space 5.0», «ДОЦЕНТ» та «Moodle».

1.3.1 «Learning Space 5.0»

Learning Space 5.0 (Lotus / IBM) - програмна освітнє середовище, яка поєднує в собі можливості "класичного" навчання з сучасними інформаційними технологіями, заснованими на автоматизації взаємодії викладача зі студентами. Інтерфейс програми приведений на рис. 1.5.

Рис. 1.5. Інтерфейс програми Learning Space

Learning Space 5.0, дає можливість вчитися і викладати в асинхронному режимі (звертаючись до матеріалів курсів у зручний час), також брати участь в on-line заняттях в режимі реального часу. Користувач може створювати зміст курсу в будь-яких додатках і потім розміщувати створений матеріал в Learning Space 5.0. Програма має гнучку систему редагування та адміністрування курсу, дозволяє вибирати різні режими викладання і стежити за поточними результатами роботи учнів. Learning Space 5.0, робить навчання незалежним від місця знаходження його учасників. Для участі в навчальному процесі необхідно мати тільки доступ в Інтернет.

Learning Space 5.0 виконує:

- гнучкість - можливість навчання в потрібному вам темпі;

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

- практичний досвід - курси засновані не на "лекціях", а на практичних заняттях;

1.3.2 «СДН Доцент»

СДН «Доцент» являє собою комплекс програмно-методичних засобів для автоматизації процесу дистанційного навчання, підвищення кваліфікації і визначення рівня компетенції персоналу. Дана система використовує сучасні Інтернет-технології і методики навчання, комп'ютерні навчальні програми та комп'ютерні тестуючи системи, технології дистанційного навчання і дистанційного консультування. А так само підтримує очну, очно-заочну та заочну форми навчання для різних схем організації навчального процесу.

При очному навчанні СДО «Доцент» може використовуватися:

- на етапі попереднього тестування - з метою формування груп з однорідним за складом рівнем підготовки учнів;

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

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

Очно-заочна форма навчання, для якої за кордоном використовується термін змішане навчання (blended learning), у всьому світі визнається найефективнішою формою організації навчального процесу у великих корпораціях. У цьому випадку до перерахованих вище варіантів використання СДН «Доцент» додаються:

-доступ до навчальних інформаційних ресурсів з робочих місць слухачів;

- можливість обміну повідомленнями електронною поштою між викладачем та слухачами;

- можливість проведення дистанційних консультацій та конференцій;

Інтерфейс програми приведений на рис. 1.6.



Рис. 1.6. Вікно «Каталог навчальних курсів»

Заочна форма навчання і самонавчання припускає, також як і інші форми навчання, доступ до навчальних матеріалів загального користування. Цей доступ організується в СДН «Доцент» за допомогою «Каталогу навчальних курсів» приведений на рис. 1.7.

Рис. 1.7. Вікно «Каталог навчальних курсів»

1.3.3 Система дистанційного навчання «Moodle»

Простими словами «Moodle», це система, яка містить в собі всі курси дисциплін і кожен студент може входити в цю систему і працювати з тим чи іншим курсом. Moodle розповсюджується безкоштовно як Open Source-проект, за ліцензією GNU GPL (іншими словами: Вам дозволяється копіювати, використовувати й змінювати програмний код). Інтерфейс програми приведений на рис. 1.8.



Рис. 1.8. Головне вікно системи дистанційного навчання «Moodle»

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

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

Блок Управління містить іконки і посилання на елементи редагування й адміністрування курсу.

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

Рис. 1.9. Вікно зміни налаштувань курсу

Розглянуті програми у повній мірі вирішують задачу дистанційного навчання (табл. 1.2). Та слід сказати, що системи «Learning Space 5.0», СДН «Доцент» є комерційними й дозволяють вирішувати дуже великий спектр задач, що позначається на ціні даних пакетів. Також з цими програмами може працювати лише спеціаліст.

З проведеного аналізу можна зробити висновки про основний функціонал, котрим наділені всі програмні продукти, та реалізувати його у своїй розробці. Найбільш функціональним рішенням з розглядаємих програмних продуктів є «Moodle». Бажано розробити інтерфейс для користувача з правами «Адміністратор» який буде реалізувати різні налаштування системи.

Таблиця 1.2. Порівняльна характеристика програмних продуктів

Фірма-розробник	Geolink technologies	Вінницький національний технічний університет	«Moodle»
Назва програмного продукту	«Learning Space 5.0»	СДН «Доцент»	«Moodle»
Версії продукту	5.0	1.5.3	2.0
Функціональність	1) Розподіленість - можливість навчатися в будь-якому місці і в будь-який час; 2) Гнучкість - можливість навчання в потрібному вам темпі; 3) Групове співробітництво - можливість індивідуального або групового навчання; 4) Вибір викладачів - можливість навчання у досвідчених експертів;	1) автоматизована система дистанційного навчання, перепідготовки і тестування слухачів; 2) інструментальні засоби створення навчальних і контролюючих програм; 3) графічна оболонка для створення та генерації індивідуальних тестів заданої складності;	1. Здачу завдань 2. Дискусійні форуми 3. Завантаження файлів 4. Оцінювання 5. Обмін повідомленнями 6. Календар подій 7. Новини та анонси подій (для різніх рівнів: сайт, курс, навчальна група) 8. Он-лайн Тестування
Можливість географічної прив'язки данних	Зручний Web-інтерфейс користувач з великою кількістю налаштувань	Зручний Web- інтерфейс з мінімальною кількістю налаштувань	Зручний Web-інтерфейс користувач з великою кількістю налаштувань
Допомога користувачу	Покрокове керівництво користувача	Керівництво користувача	Покрокове керівництво користувача

2. Розроблення вимог до програмного забезпечення

2.1 Глосарій проекту

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

Глосарій проекту представлений у табл. 2.1.

Таблиця 2.1 Глосарій проекту

Термін	Опис терміну
1	2
1. Основні поняття та категорії предметної області та проекту
СДН «Moodle»	середа дистанційного навчання Moodle.
Курс	навчальний простір в СДН Moodle, що включає набір вчителів або асистентів, студентів і учбових матеріалів. Курси створює адміністратор або творець курсів, призначаючи там вчителів або асистентів.
Категорії курсів	деревоподібна структура категорій і підкатегорій, що допомагає структурувати курси в СДН Moodle.
Модуль	Програмне розширення СДН Moodle, що додає нову функціональність. СДО Moodle підтримує наступні види модулів: - Елемент курсу; - Тип завдання; - Тип питання; - Блок; - Фільтр; - Формат курсу; - Тема оформлення;
LAMS	елемент курсу, що дозволяє завантажувати в СДН Moodle завдання створені в LAMS (Learning Activity Management System) - системі розробки завдань, які припускають спільну діяльність, і управляти ними

Таблиця

1	2
Ресурс	Елемент курсу, що дозволяє включити в курс практично будь-який цифровий (текстовий або графічний) матеріал. Ресурси бувають наступних типів: - Пояснення; - Текстова сторінка; - Веб-сторінка;
Управління	назва блоку, що надає вчителеві доступ до різних настроювань курсу, файлової області
Фільтр	Модуль, що дозволяє автоматично перетворювати введений текст в інші, більш складні форми
2. Користувачі системи
Адміністратор	роль, що надає користувачеві повний набір привілеїв по настройці СДО Moodle, а також у всіх курсах
Учитель	роль, що дозволяє користувачеві редагувати матеріали курсу і вести курс (управляти списком студентів, перевіряти роботи, виставляти оцінки)
Студент	роль, що надає користувачеві можливість навчатися на курсі
3. Вхідні та вихідні документи

2.2 Розроблення варіантів використання

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

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

2.2.1 Розроблення діаграми варіантів використання

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

Діаграма складається з наступних елементів:

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

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

- зв'язки між блоками використання і зв'язки між блоками використання та зовнішніми користувачами.

У нашій системі будуть працювати наступні користувачі:

- учень;

- вчитель;

- адміністратор.

На рис. 2.1 та рис. 2.2 відображені основні користувачі системи, а також основні завдання, які вони будуть виконувати під час роботи з системою.

Основними задачами учня є:

- вхід в систему;

- реєстрація в системі;

- реєстрація на курсі;

Основними задачами вчителя є:

- вхід в систему;

- створення курсу;

- редагування курсу;

Основними задачами адміністратора є:

- вхід в систему;

- створення комітетів;

- налаштування сайту;

- робота зі списком користувачів системи;

- створення, видалення та редагування інформації про користувачів.

Рис. 2.1. Узагальнена діаграма варіантів використання



2.2.2 Специфікація варіантів використання

Описи варіантів використання системи подані у табл. 2.2 - табл. 2.8.

Таблиця 2.2. Варіант використання «Вхід у систему»

Контекст використання	Використовується на початку роботи з програмним продуктом
Діюча особа	Еколог-аналітик
Передумова	Лаборант ПК надіслав дані про кількісні показники забруднення води
Тригер	Запуск системи
Сценарій	Працівник отримує інформацію, входить у систему, вводить свій логін та пароль
Постумова	Користувач зареєстрований у системі

Таблиця 2.3. Варіант використання «Внесення інформації до бази даних»

Контекст використання	Використовується для додавання нових даних та редагування існуючих
Діюча особа	Еколог-аналітик
Передумова	Еколог-аналітик отримав данні, які потребують занесення до бази даних, або існуючі дані потребують корегування
Тригер	Отримання нових даних з ПК або зміни у існуючих
Сценарій	Працівник отримує дані, запускає програмний продукт, вводить свій логін та пароль, додає новий запис до БД або редагує вже існуючі дані.
Постумова	Користувач має права на редагування даних БД

Таблиця 2.4. Варіант використання «Робота зі списком користувачів системи»

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

Таблиця 2.5. Варіант використання «Обслуговування БД»

Контекст використання	Використовується для підтримки продуктивності та захисту БД
Діюча особа	Адміністратор
Передумова	Необхідність підтримки БД у надійному стані та за захисті інформації БД
Тригер	Перевірка продуктивності БД
Сценарій	Адміністратор заходить в систему, вводить свій логін та пароль, виконує операції по обслуговуванню БД
Постумова	Користувач аутентифікований у системі

Таблиця 2.6. Варіант використання «Створення резервних копій БД»

Контекст використання	Використовується для створення резервних копій БД, щоб уникнути втрати диних
Діюча особа	Адміністратор
Передумова	Необхідність створення резервних копій ПД
Тригер	Планове створення копій бази даних
Сценарій	Адміністратор заходить в систему, вводить свій логін та пароль, створює резервні копії БД
Постумова	Користувач аутентифікований у системі

Таблиця 2.7. Варіант використання «Створення звітів»

Контекст використання	Використовується для створення звітів про екологічний стан поверхневих вод Харківської області
Діюча особа	Еколог-аналітик
Передумова	Користувач зібрав інформацію у повному обсязі, необхідну для створення звітів
Тригер	Отримання запиту на створення звіту
Сценарій	Користувач входить в систему, вводить свій логін та пароль, вводить необхідні запити до БД на основі яких будуть створюватися звіти
Постумова	Користувач аутентифікований у системі

Таблиця 2.8. Варіант використання «Аналіз стану поверхневих вод»

Контекст використання	Використовується для аналізу показників забруднюючих речовин і поверхневих водах Харківської області
Діюча особа	Еколог-аналітик
Передумова	Був отриманий та сформований набір даних, необхідних для аналізу
Тригер	Плановий аналіз інформації для подальшого створення звітів про стан поверхневих вод Харківської області
Сценарій	Користувач входить в систему, вводить свій логін та пароль, вводить необхідні запити до БД для аналізу існуючої інформації
Постумова	Користувач аутентифікований у системі

2.3 Специфікація функціональних та не функціональних вимог

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

Специфікація функціональних вимог до системи приведена у табл. 2.9.

Таблиця 2.9. Специфікація функціональних вимог

Ідентифікаторвимоги	Назвавимоги	Атрибути вимог
		Пріоритет	Контакт	Трудність
1	2	3	4	5
FR-UC-01	Додавання даних моніторингу	Обов'язкове	Еколог-аналітик	Середня
FR-UC-02	Редагування даних моніторингу	Обов'язкове	Еколог-аналітик	Середня
FR-UC-03	Видалення даних моніторингу	Рекомендоване	Еколог-аналітик	Середня
FR-UC-04	Побудова графіків по результатам моніторингу	Опційне	Еколог-аналітик	Середня
FR-UC-05	Додавання каристувачів	Обов'язкове	Адміністратор	Середня
FR-UC-06	Редагування даних про користувачів	Рекомендоване	Адміністратор	Середня
FR-UC-07	Видалення користувачів	Опційне	Адміністратор	Середня
FR-UC-08	Створення звітів	Обов'язкове	Еколог-аналітик	Середня
FR-UC-09	Вхід в систему	Обов'язкове	Адміністратор	Середня
FR-UC-10	Збереження звітів	Опційне	Еколог-аналітик	Середня

Специфікація не функціональних вимог до розроблюваної системи представлена у табл. 2.10.

Таблиця 2.10. Специфікація не функціональних вимог

Ідентифікаторвимоги	Назвавимоги	Атрибути вимог
		Пріоритет	Контакт	Трудність
1	2	3	4	5
1. Застосовність
SUPP-01	Час завантаження системи - не більше 5 сек.	Обов'язкове	Оператор	Середня
SUPP-02	Швидкість роботи мережевого обладнання - 100 Mbit/s	Рекомендоване	Оператор	Низька
SUPP-03	Зручний і функціональний інтерфейс користувача	Обов'язкове	Оператор	Середня
SUPP-04	Легкість обслуговування системи	Обов'язкове	Оператор	Висока
SUPP-05	Час відгуку серверу - не більше 30 сек	Рекомендоване	Оператор	С2ередня
2. Надійність
SUPP-06	Не велика кількість збоїв у роботі системи	Обов'язкове	Оператор	Висока
SUPP-07	Стійкість до збоїв, можливість продовжувати роботу з системою у випадку збою	Рекомендоване	Оператор	Висока
3. Робочі характеристики
SUPP-08	Можливість одночасного обслуговування великої кількості клієнтів без зниження продуктивності.	Рекомендоване	Оператор	Низька
SUPP-09	Час обробки запиту на пошук даних - не більше 3 сек.	Обов'язкове	Оператор	Висока
4. Експлуатаційна придатність
SUPP-10	Дотримання стандартів W3C при проектуванні системи	Рекомендоване	Оператор	Середня

Таблиця

1	2	3	4	5
5. Проектні обмеження
SUPP-11	Мова програмування РНР	Обов'язкове	Оператор	Середня
SUPP-12	СУБД - МуSQL	Обов'язкове	Оператор	Середня
6. Вимоги до призначеної для користувача документації і до системи допомоги
SUPP-13	Вивід повідомлень з попередженням про помилку	Рекомендоване	Оператор	Середня
SUPP-14	Наявність додаткової інформації, пов'язаної з системою	Обов'язкове	Оператор	Низька
7. Куповані компоненти
SUPP-15	Сумісність з браузерами Opera, Chrome, FireFox та Internet Explorer	Обов'язкове	Оператор	Середня
8. Інтерфейси
8.1. Інтерфейси користувача
SUPP-16	Єдине оформлення усіх сторінок системи	Обов'язкове	Оператор	Середня
SUPP-17	Зручний інтерфейс для роботи з БД	Обов'язкове	Оператор	Середня
8.2. Апаратні інтерфейси
SUPP-18	512 Мбайт ОЗП і вище	Обов'язкове	Оператор	Низька
SUPP-19	100 Мбайт вільного дискового простору;	Обов'язкове	Оператор	Низька
SUPP-20	Відеокарта з підтримкою роздільної здатності не менше 800 х 600 і можливістю відображення не менше 256 кольорів;	Обов'язкове	Оператор	Низька
SUPP-21	Монітор SVGA;	Обов'язкове	Оператор	Низька
SUPP-22	Процесор 800 МГц, або вище.	Обов'язкове	Оператор	Низька
SUPP-23	Мережевий адаптер 200 Мбіт/с	Обов'язкове	Оператор

Таблиця

1	2	3	4	5
8.3. Програмні інтерфейси
SUPP-24	Наявність операційної системи Windows	Обов'язкове	Оператор	Низька
SUPP-25	Наявність усіх компонентів для нормальної роботи в Inetrnet	Обов'язкове	Оператор	Середня
8.4. Комунікаційні інтерфейси
SUPP-26	Протокол обміну муж клієнтом і сервером здійснюється шляхом підключення до серверу БД - ТСР.	Обов'язкове	Оператор	Середня
SUPP-27	Наявність постійного високошвидкісного підключення до Inetrnet	Обов'язкове	Оператор	Середня
9. Вимоги до ліцензування
SUPP-28	Використання одної ліцензії на одне робоче місце	Обов'язкове	Оператор	Середня
10. Застереження щодо питань, пов'язаних з авторськими правами
SUPP-29	Авторські права захищені законом	Обов'язкове	Оператор	Середня
11. Вживані стандарти
SUPP-30	Стандарт якості програмного продукту ISO9001	Обов'язкове	Оператор	Середня

3. Проектні та технічні рішення

3.1 Математична постановка задачі

У комплексі задач автоматизованого модуля «Система обліку забруднення поверхневих вод Харківської області» є задачі, які належать до класу розрахункових.

Розрахунок перевищення концентрації забруднюючої речовини у воді від комунально-побутової норми ГДК буде виконуватися наступним чином:

,

де - перевищення комунально-побутової норми концентрації i-тої

забруднюючої речовини,

- поточна концентрація i-тої забруднюючої речовини у воді,

- коефіцієнт комунально-побутової норми ГДК i-тої

забруднюючої речовини.

Розрахунок перевищення концентрації забруднюючої речовини у воді від рибогосподарської норми ГДК буде виконуватися наступним чином:

,

де - перевищення рибогосподарської норми концентрації i-тої

забруднюючої речовини,

- поточна концентрація i-тої забруднюючої речовини у воді,

- коефіцієнт рибогосподарської норми ГДК i-тої забруднюючої речовини.

Розрахунок даних показників необхідний для подальшої побудови графіків перевищення ГДК i-тої забруднюючої речовини від комунально-побутової та рибогосподарської норми ГДК.

Процес розрахунку показників та побудові на їх основі графіків відбувається у наступній послідовності:

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

- обирає розділ «Огляд стану забруднення поверхневих вод»;

- у даному розділі спочатку обирає звітний рік, а потім звітний місяць;

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

3.2 Проектування структури бази даних

3.2.1 Опис вхідної та вихідної інформації

«Система обліку забруднення поверхневих вод Харківської області» автоматизує фунції лаборанта пункту спостереження та еколога аналітика, а саме:

- функції обліку забруднюючих речовин у воді;

- функції аналізу стану забрудення поверхневих вод Харківської області.

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

Документи, які використовуються при вирішенні задачі «Облік забруднюючих речовин у воді» наведені в табл. 3.1.

Таблиця 3.1. Інформаційний список документів задачі «Облік забруднюючих речовин у воді»

Код документу	Назва	Вхідний/вихідний
1	2	3
DC-01	Показники поверхневих вод	Вхідний
DC-02	Список водних об'єктів та пунктів контролю, закріплених за ними	Вхідний
DC-03	«Показники забруднюючих речовин у воді»	Вихідний

Документи, які використовуються при вирішенні задачі «Облік забруднюючих речовин у воді» наведені в табл. 3.2.

Таблиця 3.2. Інформаційний список документів задачі «Аналіз стану забрудненості поверхневих вод Харківської області»

Код документу	Назва	Вхідний/вихідний
1	2	3
DC-04	«Санітарні правила і норми охорони поверхневих вод від забруднення. СанПіН 4630-88»	Вхідний
DC-05	Звіт про стан поверхневих вод Харківської області за <місяць> <рік> року	Вихідний

На основі інформації вхідних і вихідних документів були сформовані списки реквізитів, на основі яких буде проектуватися структура бази даних.

Список реквізитів, які були отримані на основі вхідних документів, поданий у табл. 3.3.

Таблиця 3.3. Список реквізитів вхідних документів

№ п.п.	Найменування реквізиту	Фактичний/ Розрахунковий	Призначення реквізиту
1	2	3	4
1	Код пункту контролю	Фактичний	Описує сутність «Пункти контролю»
2	Назва ПК	Фактичний
3	Координата Х ПК	Фактичний
4	Координата У ПК	Фактичний
5	Назва відомства	Фактичний
6	Місце розташування ПК	Фактичний
7	Код водного об'єкта	Фактичний	Описує сутність «Водні об'єкти»
8	Назва ВО	Фактичний
9	Назва населеного пункту	Фактичний
10	Код показника	Фактичний	Описує сутність «Забруднюючі речовини»
11	Назва показника	Фактичний
12	Одиниця вимірювання	Фактичний
13	ГДК комунально-побутове	Фактичний
14	ГДК рибогосподарське	Фактичний

Список реквізитів, які були отримані на основі вихідних документів представлений у табл. 3.4.

Таблиця 3.4. Список реквізитів вихідних документів

№ п.п.	Найменування реквізиту	Фактичний/ Розрахунковий	Призначення реквізиту
1	2	3	4
1	Дата	Фактичний	Для формування масиву для занесення інформації моніторингу та оперативного масиву
2	Рік	Фактичний
3	Місяць	Фактичний
4	Код ПК	Фактичний
5	Назва ПК	Фактичний
6	Назва ВО	Фактичний
7	Код показника	Фактичний
8	Одиниця вимірювання	Фактичний
9	Кількість	Фактичний
10	ГДК комунально-побутове	Фактичний
11	ГДК рибогосподарське	Фактичний
12	Перевищення ГДК к-п	Розрахунковий
13	Перевищення ГДК рг	Розрахунковий

3.2.2 Словник даних

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

Таблиця 3.5 Словник даних

№ п.п.	Найменування елемента	Ідентифікатор	Тип та довжина	Призначення елемента
1	2	3	4	5
1	Адреса ел. пошти користувачі	user_mail	varchar(30)	Атрибут сутності «users» (Користувачі)
2	ГДК(к-п) забруднюючої речовини	agent_com_gdk	float	Атрибут сутності «agents» (Забрудюючі речовини)
3	ГДК(рг) ЗР	agent_fish_gdk	float	Атрибут сутності «agents»
4	Дата внесення інформації моніторингу	date	date	Атрибут сутності «monitoring» (Моніторинг)
5	Звітний місяць	month	enum('Січень', 'Лютий', 'Березень', 'Квітень', 'Травень', 'Червень', 'Липень', 'Серпень', 'Вересень', 'Жовтень', 'Листопад', 'Грудень')	Атрибут сутності «monitoring»
6	Звітний рік	year	year(4)	Атрибут сутності «monitoring»
7	Ім'я користувача	user_n	varchar(30)	Атрибут сутності «users»
8	Ім'я користувача системи для входу	username	varchar(255)	Атрибут сутності «users»
9	Кількість забруднюючої речовини	value	float	Атрибут сутності «monitoring agents» (Результати моніторингу)
10	Код відомства	inst_id	int(5)	Атрибут сутності «institution» (Відомства)
11	Код водного об'єкта	water_id	int(5)	Атрибут сутності «waters» (Водні об'єкти)
12	Код ЗР	agent_id	int(5)	Атрибут сутності «agents»
13	Код користувача	userid	varchar(255)	Атрибут сутності «users»
14	Код населеного пункту	loc_id	int(5)	Атрибут сутності «locality» (Населені пункти)
15	Код одиниці вимірювання	unit_id	int(3)	Атрибут сутності «units» (Одиниці вимірювання)
16	Код пункту контролю	cp_id	varchar(15)	Атрибут сутності «control points» (Пункти контролю)
17	Контактний телефон	user_phone	varchar(13)	Атрибут сутності «users»
18	Координата У ПК	cp_y	flo	Атрибут сутності «control points»
19	Координата Х ПК	cp_x	float	Атрибут сутності «control points»
20	Назва ВО	water_name	varchar(25)	Атрибут сутності «waters»
21	Назва ЗР	agent_name	varchar(30)	Атрибут сутності «agents»
22	Назва НП	loc_name	varchar(25)	Атрибут сутності «locality»
23	Назва ОВ	unit_name	varchar(25)	Атрибут сутності «units»
24	Назва ПК	cp_name	varchar(50)	Атрибут сутності «control points»
25	Номер запису результату моніторингу	record_id	int(5)	Атрибут сутності «monitoring agents»
26	Номер проведення моніторингу	rec_id	int(6)	Атрибут сутності «monitoring»
27	Опис ПК	cp_desc	varchar(100)	Атрибут сутності «control points»
28	Пароль користувача	password	varchar(255)	Атрибут сутності «users»
29	По-батькові користувача	user_ln	varchar(30)	Атрибут сутності «users»
30	Повна назва відомства	inst_name	varchar(50)	Атрибут сутності «institution»
31	Посада користувача	user_pos	varchar(30)	Атрибут сутності «users»
32	Права користувача	permission	enum('admin', 'ecolog')	Атрибут сутності «users»
33	Прізвище користувача	user_fn	varchar(30)	Атрибут сутності «users»
34	Скорочена назва відомства	inst_short	varchar(10)	Атрибут сутності «institution»
35	Скорочена назва ОВ	unit_short	varchar(10)	Атрибут сутності «units»
36	Характеристика відомства	inst_desc	varchar(100)	Атрибут сутності «institution»
37	Характеристика ВО	water_desc	varchar(50)	Атрибут сутності «waters»
38	Характеристика НП	loc_desc	varchar(100)	Атрибут сутності «locality»
39	Характеристика ЗР	agent_desc	varchar(50)	Атрибут сутності «agents»

3.2.3 Проектування моделей даних для функцій, що автоматизуються

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

«agents» - містить інформацію про забруднюючі речовини;

«control_points» - містить інформацію про пункти контролю;

«institution» - містить інформацію про відомства;

«locality» - містить інформацію про населені пункти;

«monitoring» - містить інформацію про внесення даних моніторингу;

«monitoring agents» - містить дані моніторингу;

«units» - містить інформацію про одиниці вимірювання;

«water» - містить інформацію про водні об'єкти Харківської області.

Схема зв'язків сутностей і атрибутів системи наведена на рис. 3.1.

Для кожної із сутностей у табл. 3.6 - табл. 3.13 охарактеризовані обмеження цілісності.

Рис. 3.1. Сутності, які використовуються для автоматизації функцій обліку та аналізу забруднання вод

Таблиця 3.6. Обмеження атрибутів сутності «agents»

№ п/п	Ім'я атрибуту	Тип	Розмір	Границі або допустимі значення	Структура (формат)	Умова	Значення за замовчуванням
1	agent_id	int	5	0..9		Первісний ключ
2	agent_name	varchar	30	А…Я,A..Z,0..9
3	unit_id	int	5	0..9
4	agent_desc	varchar	50	А…Я,A..Z,0..9
5	agent_com_gdk	float		0..9		>=0
6	agent_fish_gdk	float		0..9		>=0

Таблиця 3.7. Обмеження атрибутів сутності «units»

№ п/п	Ім'я атрибуту	Тип	Розмір	Границі або допустимі значення	Структура (формат)	Умова	Значення за замовчуванням
1	unit_id	int	3	0..9		Первісний ключ
2	unit_name	varchar	25	А…Я,A..Z,0..9
3	unit_short	varchar	10	А…Я,A..Z,0..9

Таблиця 3.8. Обмеження атрибутів сутності «control_points»

№ п/п	Ім'я атрибуту	Тип	Розмір	Границі або допустимі значення	Структура (формат)	Умова	Значення за замовчуванням
1	cp_id	varchar	15	А…Я,A..Z,0..9		Первісний ключ
2	cp_name	varchar	50	А…Я,A..Z,0..9
3	loc_id	int	5	0..9
4	water_id	int	5	0..9
5	inst_id	int	5	0..9
6	cp_desc	varchar	100	А…Я,A..Z,0..9
7	cp_x	float	6	0..9		>0
8	cp_y	float	6	0..9		>0

Таблиця 3.9. Обмеження атрибутів сутності «institution»

№ п/п	Ім'я атрибуту	Тип	Розмір	Границі або допустимі значення	Структура (формат)	Умова	Значення за замовчуванням
1	inst_id	int	5	0..9		Первісний ключ
2	inst_name	varchar	50	А…Я,A..Z,0..9
3	inst_short	varchar	10	А…Я,A..Z,0..9
4	inst_desc	varchar	100	А…Я,A..Z,0..9

Таблиця 3.10. Обмеження атрибутів сутності «locality»

№ п/п	Ім'я атрибуту	Тип	Розмір	Границі або допустимі значення	Структура (формат)	Умова	Значення за замовчуванням
1	2	3	4	5	6	7	8
1	loc_id	int	5	0..9		Первісний ключ
2	loc_name	varchar	25	А…Я,A..Z,0..9
3	loc_desc	varchar	100	А…Я,A..Z,0..9

Таблиця 3.11. Обмеження атрибутів сутності «water»

№ п/п	Ім'я атрибуту	Тип	Розмір	Границі або допустимі значення	Структура (формат)	Умова	Значення за замовчуванням
1	2	3	4	5	6	7	8
1	water_id	int	5	0..9		Первісний ключ
2	water_name	varchar	25	А…Я,A..Z,0..9
3	water_desc	varchar	50	А…Я,A..Z,0..9

Таблиця 3.12. Обмеження атрибутів сутності «monitoring»

№ п/п	Ім'я атрибуту	Тип	Розмір	Границі або допустимі значення	Структура (формат)	Умова	Значення за замовчуванням
1	2	3	4	5	6	7	8
1	rec_id	int	6	0..9		Первісний ключ
2	year	year	4	0..9	xxxx
3	month	enum		'Січень', 'Лютий', 'Березень', 'Квітень', 'Травень', 'Червень', 'Липень', 'Серпень', 'Вересень', 'Жовтень', 'Листопад', 'Грудень'
4	date	date		0..9	хх.хх.хххх
5	cp_id	varchar	15	А…Я,A..Z,0..9

Таблиця 3.13. Обмеження атрибутів сутності «monitoring agents»

№ п/п	Ім'я атрибуту	Тип	Розмір	Границі або допустимі значення	Структура (формат)	Умова	Значення за замовчуванням
1	2	3	4	5	6	7	8
1	record_id	int	5	0..9		Первісний ключ
2	rec_id	int	6	0..9
3	agent_id	int	5	0..9
4	value	float	6	0..9		>=0

Обмеження кортежів сутності «monitoring» системи наведене у табл. 3.14.

Таблиця 3.14. Обмеження кортежів сутності «monitoring»

№ п/п	Група атрибутів	Обмеження
1	year, date	year in date and year are same

Обмеження унікальності сутностей системи описані у табл. 3.15 - табл.3.22.

Таблиця 3.15. Обмеження унікальності в сутності «agents»

№ п/п	Атрибут чи група атрибутів	Унікальне серед атрибутів сутності «agents»
1	agents.agent_id agents.unit_id	Всіх екземплярів сутності «agents»

Таблиця 3.16. Обмеження унікальності в сутності «units»

№ п/п	Атрибут чи група атрибутів	Унікальне серед атрибутів сутності «units»
1	units.unit_id	Всіх екземплярів сутності «units»

Таблиця 3.17. Обмеження унікальності в сутності «control_points»

№ п/п	Атрибут чи група атрибутів	Унікальне серед атрибутів сутності «control_points»
1	control_points.cp_id control_points.loc_id control_points.water_id control_points.inst_id	Всіх екземплярів сутності «control_points»

Таблиця 3.18. Обмеження унікальності в сутності «institution»

№ п/п	Атрибут чи група атрибутів	Унікальне серед атрибутів сутності «institution»
1	institution.inst_id	Всіх екземплярів сутності «institution»

Таблиця 3.19. Обмеження унікальності в сутності «locality»

№ п/п	Атрибут чи група атрибутів	Унікальне серед атрибутів сутності «locality»
1	locality.loc_id	Всіх екземплярів сутності «locality»

Таблиця 3.20. Обмеження унікальності в сутності «water»

№ п/п	Атрибут чи група атрибутів	Унікальне серед атрибутів сутності «water»
1	water.water_id	Всіх екземплярів сутності «water»

Таблиця 3.21. Обмеження унікальності в сутності «monitoring»

№ п/п	Атрибут чи група атрибутів	Унікальне серед атрибутів сутності «monitoring»
1	monitoring.rec_id monitoring.cp_id	Всіх екземплярів сутності «monitoring»

Таблиця 3.22. Обмеження унікальності в сутності «monitoring agents»

№ п/п	Атрибут чи група атрибутів	Унікальне серед атрибутів сутності «monitoring agents»
1	monitoring agents.record_id monitoring agents.rec_id monitoring agents.agent_id	Всіх екземплярів сутності «monitoring agents»

Динамічні обмеження деяких атрибутів сутностей системи наведені в табл. 3.23 - 3. 29.

Обмеження посилкової цілісності сутностей подані в табл. 3.30 - 3.33.

Таблиця 3.23. Динамічні обмеження сутності «agents»

№ п/п	Атрибут чи група атрибутів	Обмеження
1	agent_id	agent_id= agent_id+1

Таблиця 3.24. Динамічні обмеження сутності «units»

№ п/п	Атрибут чи група атрибутів	Обмеження
1	unit_id	unit_id= unit_id+1

Таблиця 3.25. Динамічні обмеження сутності «institution»

№ п/п	Атрибут чи група атрибутів	Обмеження
1	inst_id	inst_id= inst_id+1

Таблиця 3.26. Динамічні обмеження сутності «locality»

№ п/п	Атрибут чи група атрибутів	Обмеження
1	loc_id	loc_id= loc_id+1

Таблиця 3.27. Динамічні обмеження сутності «water»

№ п/п	Атрибут чи група атрибутів	Обмеження
1	water_id	water_id= water_id+1

Таблиця 3.28 Динамічні обмеження сутності «monitoring»

№ п/п	Атрибут чи група атрибутів	Обмеження
1	rec_id	rec_id= rec_id+1

Таблиця 3.29. Динамічні обмеження сутності «monitoring agents»

№ п/п	Атрибут чи група атрибутів	Обмеження
1	record_id	record_id = record_id +1

Таблиця 3.30. Правила посилкової цілісності сутності «agents»

№ п/п	Батьківська сутність	Дочірня сутність	Правило видалення	Інші правила
1	units	agents	Каскадне

Таблиця 3.31. Правила посилкової цілісності сутності «control_points»

№ п/п	Батьківська сутність	Дочірня сутність	Правило видалення	Інші правила
1	location	control_points	Каскадне
2	waters	control_points	Каскадне
3	institution	control_points	Каскадне

Таблиця 3.32

Правила посилкової цілісності сутності «monitoring»

№ п/п	Батьківська сутність	Дочірня сутність	Правило видалення	Інші правила
1	control_points	monitoring	Каскадне

Таблиця 3.33

Правила посилкової цілісності сутності «monitoring agents»

№ п/п	Батьківська сутність	Дочірня сутність	Правило видалення	Інші правила
1	monitoring	monitoring agents	Каскадне
2	agents	monitoring agents	Каскадне

У нашій системі окрім функцій обліку та аналізу забруднення поверхневих вод також автоматизуються функції роботи зі списком користувачів системи. На рис. 3.2 зображена структура сутності «users».

Рис. 3.2. Сутність для забезпечення функцій для роботи зі списком користувачів

У табл. 3.34 описані обмеження атрибутів сутності «users».

Таблиця 3.34. Обмеження атрибутів сутності «users»

№ п/п	Ім'я атрибуту	Тип	Розмір	Границі або допустимі значення	Структура (формат)	Умова	Значення за замовчуванням
1	2	3	4	5	6	7	8
	user_id	varchar	6	А…Я,A..Z,0..9		Первинний ключ
	user_name	varchar	255	А…Я,A..Z,0..9
	password	varchar	20	А…Я,A..Z,0..9
	permission	enum		'admin', 'ecolog'
	user_n	varchar	30	А…Я,A..Z,0..9
	user_fn	varchar	30	А…Я,A..Z,0..9
	user_ln	varchar	30	А…Я,A..Z,0..9
	user_mail	varchar	30	А…Я,A..Z,0..9
	user_pos	varchar	30	А…Я,A..Z,0..9
	user_phone	varchar	13	А…Я,A..Z,0..9

Обмеження унікальності в сутності «users» приведене у табл. 3.35.

Таблиця 3.35. Обмеження унікальності в сутності «users»

№ п/п	Атрибут чи група атрибутів	Унікальне серед атрибутів сутності «users»
1	users. user_id	Всіх екземплярів сутності «users»

Динамічні обмеження сутності приведені у табл. 3.36.

Таблиця 3.36. Динамічні обмеження сутності «users»

№ п/п	Атрибут чи група атрибутів	Обмеження
1	user_id	user_id = user_id +1

3.2.4 Опис СУБД-орієнтованої моделі даних

В ході проектування бази даних були створені наступні сутності: «agents», «units», «control_points», «waters», «location», «institution», «monitoring», «monitoring agents», «users». Вони необхідні для найбільш зручної роботи з додатком, котрий цілком відповідає предметній області. Для забезпечення мінімальної надмірності повторювана інформація була винесена до окремих довідників. Посилкова цілісність забезпечується за допомогою зовнішніх ключів та функцій бази даних каскадного видалення та оновлення.

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

Сутність «units» використовується для збереження інформації про одиниці вимірювання. Містить код, назву, та скорочення одиниці вимірювання. Є батьківською сутністю для сутності «agents».

Сутність «control_points» використовується для зберігання інформації про пункти контролю. Містить код, назву, опис ПК, а також зовнішні ключі з сутностей «location», «institution» та «waters», які вказують на зв'язок ПК з населеним пунктом, водним об'єктом та відомством.

Сутність «waters» використовується для зберігання інформації про водні об'єкти Харківської області. Містить код, назву та описання водойми. Є батьківською для сутності «control_points», що вказує на те, що один водний об'єкт може мати декілька пунктів спостереження.

Сутність «location» використовується для збереження інформації про населені пункти, на території яких знаходяться ПК. Містить код, назву та опис населеного пункту. Є батьківською для сутності «control_points», що вказує на те, що один населений пункт може мати декілька ПК.

Сутність «institution» використовується для збереження інформації про відомства, яким підпорядковується пункт контролю. Містить код, назву, скорочену назву та опис відомства. Є батьківською сутністю для «control_points», що свідчить про те, що одному відомству може підпорядковуватися декілька пунктів контролю.

Сутність «monitoring» використовується для збереження інформації про проведення екологічного моніторингу. Містить наступну інформацію моніторингу: рік, місяць та дату проведення моніторингу, а також код запису та код ПК, який проводить моніторинг. Сутність «monitoring agents» використовується як проміжна таблиця для усунення зв'язку багато-до-багатьох між сутностями «monitoring» та «agents». Містить інформацію про кількісні показники забруднюючих речовин, які були отримані під час моніторингу. Сутність «users» використовується для зберігання інформації про користувачів системи та для обмеження доступу до системи. Містить інформацію про логін, пароль, прізвище, ім'я та по-батькові, посаду, контактний телефон, та посилання на роль користувача. Словник ролей використовується для розмежування доступу до різних функцій програми між екологом-аналітиком та адміністратором системи. На рис. 3.4 приведена глобальна фізична модель бази даних системи.

Рис. 3.3. Глобальна фізична модель бази даних «Системи обліку забруднюючих речовин Харківської області»

У додатку А поданий SQL-скрипт з командами генерації та внесення інформації до описаних вище об'єктів зберігання інформації.

3.3 Опис архітектури додатку. Розгортання програмного продукту

3.3.1 Мінімальні системні характеристики

У цьому пункті наведені вимоги до апаратного забезпечення клієнтської частини. Для нормального функціонування системи необхідна наступна мінімальна конфігурація персонального комп'ютера:

- 512 Мбайт ОЗП і вище;

- 100 Мбайт вільного дискового простору;

- відеокарта з підтримкою дозволу не менше 800 х 600 і можливістю відображення не менше 256 кольорів;

- монітор SVGA;

- процесор 800 МГц або вище;

- мережевий адаптер 100 М/біт.

Вимоги до апаратного забезпечення серверної частини:

- процесор Intel Pentium 4 або аналогічний з рейтингом 1.8 ГГц або вище;

- 1 Гбайт ОЗП;

- 1 Гбайт вільного дискового простору;

- відеокарта з роздільною здатністю не менше 800 х 600 і можливістю відображення не менше 256 кольорів;

- мережевий адаптер 1 Г/біт.

3.3.2 Вимоги до програмного забезпечення

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

- операційна система Windows XP, або Windows Vista, або Windows 7;

- Інтернет-браузер (Google Chrome, Mozila FireFox, Internet Explorer, Opera).

Вимоги до програмного забезпечення серверної частини:

- операційна система Linux CentOS 5.4;

- Web-сервер Apache 2.2;

- СУБД MySQL 5.6;

- РНР-інтерпретатор 5.3.

3.3.3 Спосіб виклику програми, запуск програми

Оскільки було розроблено додаток з Web-інтерфейсом, то для його запуску необхідно запустити Інтернет-браузер та перейти по наступній URL-адресі: http:/www.gidro-kharkiv.ho.ua.

3.3.4 Спосіб установки системи

Для того, щоб встановити додаток необхідно завантажити скрипти програмного продукту в кореневий каталог веб-серверу, внести відповідні налаштування до файлу конфігурації config.php, запустити скрипт завантаження дампу бази даних.

Висновки

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

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

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

Результати роботи були представлені на «Міжнародній науково-практичній конференції молодих вчених, аспірантів та студентів на тему «Актуальні проблеми науки та освіти молоді: теорія, практика, сучасні рішення»» та.

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