Характеристика та основні напрями діяльності друкарні "Добробут". Особливості дистанційної системи навчання "Moodle", сутність програми "Learning Space 5.0". Основне призначення діаграми використання, її склад: блоки використання, зовнішні користувачі.
Технічні досягнення знаходять застосування в навчальному процесі, і персональний компютер (ПК) в цьому сенсі не є винятком. Використання обчислювальної техніки дозволяє істотно підвищити ефективність процесу навчання, поліпшити облік і оцінку знань, забезпечити можливість індивідуальної допомоги викладача кожному студенту у вирішенні окремих завдань, полегшити створення і постановку нових курсів. Дистанційне навчання це нова форма навчального процесу, в якій використовуються традиційні та інноваційні способи навчання. Дистанційне навчання засноване на нових методах представлення даних і навчальних матеріалів в електронному вигляді (гіпертекстова розмітка документів, звук і відео вбудовані в електронний документ, інтерактивність при роботі з даними) та використання Internet технологій для доставки електронних навчальних матеріалів учням. Загальна кількість курсів дистанційного навчання у світі зростає більш ніж на 40% щорічно.Це програмне забезпечення подане як простий статичний HTML сторінка, так і складними системами управління навчанням, та навчальним контентом (Learning Content Management Systems), що буде реалізовувати функції бізнес-процесу «адміністрування». Метою допрацювання модуля адміністрування дистанційної системи навчання Moodle, є поєднання можливостей програмних продуктів, які можуть вирішувати задачі такого роду, при цьому модуль буде вирішувати тільки поставлену задачу. Аналогами розроблюваної програми можуть бути такі програмні продукти: «Learning Space 5.0», «ДОЦЕНТ» та «Moodle». Learning Space 5.0 (Lotus / IBM) - програмна освітнє середовище, яка поєднує в собі можливості "класичного" навчання з сучасними інформаційними технологіями, заснованими на автоматизації взаємодії викладача зі студентами.
Список литературы
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 СУБД - MYSQL Обовязкове Оператор Середня
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-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 Словник даних
№ п.п. Найменування елемента Ідентифікатор Тип та довжина Призначення елемента
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 А…Я,А..Z,0..9
3 unit_id int 5 0..9
4 agent_desc varchar 50 А…Я,А..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 А…Я,А..Z,0..9
3 unit_short varchar 10 А…Я,А..Z,0..9
Таблиця 3.8. Обмеження атрибутів сутності «control_points»
№ п/п Імя атрибуту Тип Розмір Границі або допустимі значення Структура (формат) Умова Значення за замовчуванням
1 cp_id varchar 15 А…Я,А..Z,0..9 Первісний ключ
2 cp_name varchar 50 А…Я,А..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 А…Я,А..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 А…Я,А..Z,0..9
3 inst_short varchar 10 А…Я,А..Z,0..9
4 inst_desc varchar 100 А…Я,А..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 А…Я,А..Z,0..9
3 loc_desc varchar 100 А…Я,А..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 А…Я,А..Z,0..9
3 water_desc varchar 50 А…Я,А..Z,0..9
Таблиця 3.12. Обмеження атрибутів сутності «monitoring»
№ п/п Імя атрибуту Тип Розмір Границі або допустимі значення Структура (формат) Умова Значення за замовчуванням
Динамічні обмеження деяких атрибутів сутностей системи наведені в табл. 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»
№ п/п Імя атрибуту Тип Розмір Границі або допустимі значення Структура (формат) Умова Значення за замовчуванням
Обмеження унікальності в сутності «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, запустити скрипт завантаження дампу бази даних.
Висновки
У результаті виконання даного дипломного проекту було розроблено спеціалізований програмний продукт. На основі аналізу предметної області були розроблені функціональні та не функціональні вимоги, діаграма варіантів використання та діаграма станів а також була спроектована база даних що вказує на повноту виконання поставленої задачі.
Завдяки розробці даної спеціалізованої системи, яка на даному етапі може бути впроваджена лише у відділі підключення клієнтів у підприємствах з надання послуг доступу до мережі Інтернет, було автоматизовано такі бізнес-процеси як ведення реєстру договорів та ведення реєстру підключення та перепідключення клієнтів, що значно скорочує час та трудовитрати на дані бізнес-процеси підприємства.
Дана версія продукту може бути впроваджена у відділ підключення у підприємствах з надання послуг доступу до мережі Інтернет.
Результати роботи були представлені на «Міжнародній науково-практичній конференції молодих вчених, аспірантів та студентів на тему «Актуальні проблеми науки та освіти молоді: теорія, практика, сучасні рішення»» та.
Наступні версії продукту будуть направлені на автоматизацію інших бізнес-процесів підприємств з надання послуг доступу до Інтернет для повної автоматизації їх роботи.
Список використаних джерел
1. Водний кодекс України від (213/95-ВР) 6 червня 1995 р. // Відомості Верховної Ради України, 1995, № 24. Ст. 189.
2. Закон України "Про забезпечення санітарного та епідемічного благополуччя населення" (4004-12) від 24.02.94 //Відомості Верховної Ради України, 1994, № 27. Ст. 218.
3. Закон України "Про охорону навколишнього природного середовища" від 26.06.91, ВВР, 1991, N 41, ст.547
4. Постанова Кабінету Міністрів України від 20 липня 1996 р. № 815 ( 815-96-п ) "Про затвердження Порядку здійснення державного моніторингу вод" // Зібрання постанов Уряду України. 1996. № 15. Ст. 403.
5. Постанова Кабінету Міністрів України від 30 березня 1998 р. № 391 (391-98-п) "Про затвердження Положення про державну систему моніторингу довкілля" // Офіційний вісник України, 1998. № 13. Ст. 495, зі змінами, внесеними постановою Кабінету Міністрів України від 16 травня 2001 р. № 528 ( 528-2001-п ).
6. Постанова Кабінету Міністрів України від 2 листопада 1998 р. № 1724 ( 1724-98-п ) "Про інформаційні послуги у сфері гідрометеорології" // Офіційний вісник України. 1998. № 44. Ст. 1626.
7. ДСТУ 3041-95. Гідросфера. Використання і охорона води. Терміни та визначення.
8. ДСТУ 3831-98. Охорона навколишнього природного середовища. Автоматизовані системи контролю якості природних вод. Типи та основні вимоги.
9. ГОСТ 7.1-84. Бібліографічний опис документа: Загальні вимоги та правила складання. - М.: Изд-во стандартів, 1984. - 77 с.
10. ГОСТ 17.1.1.02-77. Охрана природы. Гидросфера. Классификация водных объектов.
11. ГОСТ 17.1.3.07-82. Охрана природы. Гидросфера. Правила контроля качества воды водоемов и водотоков.
12. ГОСТ 27384-87. Вода. Нормы погрешности измерений показателей состава и свойств.
13. КНД 211.0.0.050-96. Зовнішній контроль якості вимірювань складу та властивостей проб обєктів довкілля. Основні положення.
14. КНД 211.1.0.009-94. Гідросфера. Відбір проб для визначення складу і властивостей стічних і технологічних вод. Основні положення.
15. КНД 211.1.2.008-94. Гідросфера. Правила контролю складу і властивостей стічних та технологічних вод.
16. Методичні рекомендації до оформлення звітів, курсових та дипломних проектів для студентів напрямки підготовкі 0804 «Компютерні науки» всіх форм навчання / Укл. І. О. Золотарьова, О.М. Беседовській, І. Л. Латишева, Г. О. Плеханова. - Харків: Вид. ХНЕУ, 2007. - 32 с.
17. МУ № 40. Методические указания по организации системы наблюдений и контроля за загрязнением морей и устьев рек. М.: Гидрометеоиздат, 1978.
18. РД 52.24.66-86. Система контроля точности результатов измерений показателей загрязненности окружающей среды.
19. Методика екологічної оцінки якості поверхневих вод за відповідними категоріями. Затв. наказом Мінекобезпеки від 31.03.98 № 44. Київ, 1998. 28 с.
20. Методические указания по принципам организации системы наблюдений и контроля за качеством воды водоемов и водотоков Госкомгидромета в рамках ОГСНК. Л.: Гидрометеоиздат, 1984.
21. Перечень предельно допустимых концентраций и ориентировочно безопасных уровней воздействия вредных веществ для воды рыбохозяйственных водоемов. Утв. Главрыбводом Минрыбхоза СССР 09.08.90 г. № 12-04-11. М., Минрыбхоз СССР, 1990.
22. Рекомендации по применению обобщенного показателя для оценки уровня загрязненнос
Вы можете ЗАГРУЗИТЬ и ПОВЫСИТЬ уникальность своей работы
