Розробка програмного забезпечення для веб ресурсу "Планувальник навантаження викладачів кафедри"

Suffix

varchar(40)

Суфікс назви роботи індивідуального плану

TypeId

varchar(MAX)

Унікальний ідентифікатор розділу індивідуального плану

TabName

varchar(40)

Назва вкладки розділу індивідуального плану

Таблиця «PlanRemarks»

Id

varchar(MAX)

Унікальний ідентифікатор таблиці зауважень індивідуального плану

Semestr

varchar(20)

Семестр формування зауважень індивідуального плану

Date

datetime

Дата формування зауважень індивідуального плану

Remark

varchar(MAX)

Зміст зауваження

Signature

varchar(20)

Підпис завідувача кафедри

ApplicationUserId

varchar(MAX)

Унікальний ідентифікатор користувача

Таблиця «PlanConclusions»

Id

varchar(MAX)

Унікальний ідентифікатор таблиці висновків індивідуального плану

Semestr

varchar(20)

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

Date

datetime

Дата формування висновків індивідуального плану

Content

varchar(MAX)

Зміст висновків

Signature

varchar(20)

Підпис завідувача кафедри

ApplicationUserId

varchar(MAX)

Унікальний ідентифікатор користувача

Таблиця «PlanChanges»

Id

varchar(MAX)

Унікальний ідентифікатор таблиці висновків індивідуального плану

Semestr

varchar(20)

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

TypesOfJobs

varchar(20)

Типи робіт, що потрібні для змін

Changes

varchar(MAX)

Зміст змін

PlannedVolume

Int 32

Плановий обсяг

ActualVolume

Int 32

Фактичний обсяг

Base

varchar(MAX)

Підстава (накази, розпорядження, протоколи засідань кафедри, лікарняні листи)

Signature

varchar(20)

Підпис завідувача кафедри

ApplicationUserId

varchar(MAX)

Унікальний ідентифікатор користувача

Проектування глобальної інфологічної моделі даних.

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

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

Ідентичність - однакове семантичне значення двох або більше об'єктів моделі [38].

Агрегація - абстракція даних, що дає змогу трактувати сукупність різноманітних за природою об'єктів як новий об'єкт [37].

Узагальнення - абстракція даних, що дає змогу трактувати клас різних подібних типів об'єктів як один пойменований узагальнений тип об'єкта [36].

При організації БД ІС студентські профілі недоцільно зберігати в різних масивах і відповідно зображати у вигляді окремих типів сутностей.

Проектування глобальної даталогічної моделі даних.

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

Проектування даталогічної моделі даних.

Структура логічної моделі даних (рис. 2.12) відображає структуру елементів, що знаходяться у базі даних. Описується семантика предметної області і не враховується особливості конкретної СУБД. Дана логічна модель є реляційною, тобто всі таблиці нормалізовані. Завдяки цьому досягається більший рівень абстракції, ніж в ієрархічній чи мережевій. Для користувача простіше та доступніше сприймати інформацію, що знаходиться в таблицях. Також при зміні окремих функцій чи логіки програмного продукту, зміна даних буде неістотною, також набагато простіше використовувати дані для реалізації запитів.

Обґрунтування можливостей моделі бази даних.

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

Тому, до переваги реляційної моделі можна віднести: простота і доступність для розуміння (єдиною використовуваною інформаційною конструкцією є «таблиця»); суворі правила проектування, які базуються на математичному апараті; повна незалежність даних; для організації запитів і написання прикладного ПЗ немає необхідності знати конкретну організацію БД у зовнішній пам'яті.

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

Фізична модель визначає як структуру розміщення даних у зовнішній пам'яті, тому її називають внутрішньою моделлю системи.

Проектування фізичної моделі даних.

Фізична модель будується за приведеною логічною схемою (дод. В). Але відмінним є те, що враховуються особливості СУБД, наприклад типи даних, розмір об'єктів, тип, обмеження та найменування полів та ін. Реляційна схема бази даних, розроблена в рамках даної предметної області, не потребує додаткового проведення нормалізації та знаходиться в третьої нормальній формі. В табл. 2.7. та табл. 2.8. представлені обмеження до атрибутів даної бази, а саме динамічні обмеження унікальності.



Таблиця 2.7 Обмеження унікальності

№ п/п	Атрибут або група атрибутів	Серед яких примірників, якої сутності або зв'язку має місце унікальність
1.	IndivPlanFieldsValues.Id	Для всіх примірників сутності «IndivPlanFieldsValues»
2.	IndivPlanFields.Id	Для всіх примірників сутності «IndivPlanFields»
3.	IndPlanTypes.Id	Для всіх примірників сутності «IndPlanTypes»
4.	PlanConclusions.Id	Для всіх примірників сутності «PlanConclusions»
5.	PlanChanges.Id	Для всіх примірників сутності «PlanChanges»
6.	PlanRemarks.Id	Для всіх примірників сутності «PlanRemarks»
7.	ApplicationUsers.Id	Для всіх примірників сутності «ApplicationUsers»
8.	ApplicationUsers.Email	Для всіх примірників сутності «ApplicationUsers»

Таблиця 2.8 Динамічні обмеження

№ п/п	Атрибут або група атрибутів	Обмеження
1.	IndivPlanFieldsValues.Id	IndivPlanFieldsValues.Id = IndivPlanFieldsValues.Id +1 - значення атрибута може лише збільшуватися на одиницю
2.	IndivPlanFields.Id	IndivPlanFields.Id.Id = IndivPlanFields.Id.Id +1 - значення атрибута може лише збільшуватися на одиницю
3.	IndPlanTypes.Id	IndPlanTypes.Id = IndPlanTypes.Id +1 - значення атрибута може лише збільшуватися на одиницю
4.	PlanConclusions.Id	PlanConclusions.Id = PlanConclusions.Id +1 - значення атрибута може лише збільшуватися на одиницю
5.	PlanChanges.Id	PlanChanges.Id = PlanChanges.Id +1 - значення атрибута може лише збільшуватися на одиницю
6.	PlanRemarks.Id	PlanRemarks.Id = PlanRemarks.Id +1 - значення атрибута може лише збільшуватися на одиницю
7.	ApplicationUsers.Id	ApplicationUsers.Id = ApplicationUsers.Id +1 - значення атрибута може лише збільшуватися на одиницю
8.	ApplicationUsers.Email	ApplicationUsers.Email = є унікальним і для кожного користувача й повинне відповідати патерну лектронни адрес.

Сама форма представлення залежить від системи керування базами даних (СКБД). У якості СКБД обрано MS SQL Server, яка являється швидким і надійним рішенням.

Побудована база має всі властивості, необхідні для бази даних, а саме функціональну повноту; цілісність; узгодженість; актуальність; безпеку; логічна та фізична незалежність; ефективність [37, 38]. Структура фізичної моделі даних відображена на рис. 2.11.

Рисунок 2.11 - Структура фізичної моделі даних

Рисунок 2.12 - Структура даталогічної моделі даних

Програмна реалізація бази даних.

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



2.7 Розробленні архітектури програмної системи

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

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

Рисунок 2.13 - Діаграма класів

Діаграма класів відображає основні класи системи та зв'язки між ними. У розроблюваному модулі існує головний клас створення, редагування, перегляду записів таблиць за допомогою якого реалізується робота з таблицями [36].

UML - діаграма станів, які містять елементи графічного інтерфейсу користувача та основні принципи роботи з додатком наведені на рис. 2.14.

Відомо, що діаграми станів необхідні для того, щоб змоделювати динамічні аспекти системи, тобто як реагує система на певні чинники під впливом перебігу поді [41].



Рисунок 2.14 - Діаграма стану

2.8 Тестування програмної системи

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

тестування сторінки з модулем;

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

тестування функції створення нових користувачів та редагування їх даних;

тестування функції інтеграції з розкладом.

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

Тестування буде проводитися вручну в поєднанні з методами модульного, інтеграційного та системного тестування, що дасть змогу якнайкраще виявити недоліки в програмі [46].

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

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

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

Таблиця 2.9 Перевірка роботи адмінської частини веб - додатку

№ п/п	Виконання тесту	Очікуваний результат	Отриманий результат	Проход - ження тесту
1	2	3	4	5
1.	Після авторизації з роллю Викладач модератор перейти за посиланням «Індивідуальний план»	Після переходу за посиланням відкривається випадаючий список із роботами, для формування індивідуального плану	В залежності від вибору роботи, відкриваються відповідні сторінки	Тест пройдений
3.	Після авторизації з роллю Адміністратор перейти за посиланням «Індивідуальний план викладача»	Після переходу за посиланням починається завантаження звіту індивідуального плану викладача	Відкривається документ формату Excel де сформований індивідуальний план викладача	Тест пройдений
4.	На сторінці «Профілі студента» редагувати профіль	Профіль відредагований	Профіль відредагований	Тест пройдений

Таблиця 2.10 Перевірка редагування інформації користувачів

№ п/п	Виконання тесту	Очікуваний результат	Отриманий результат	Проходження тесту
1.	Після авторизації з роллю Користувач перейти за посиланням «Редагувати»	Повинна відкритися сторінка «Редагування даних»	Відкривається сторінка «Редагування даних»	Тест пройдений
2.	Після авторизації з роллю Користувач перейти за посиланням «Розклад»	Повинна відкритися сторінка «Розклад»	Відкривається сторінка «Розклад»	Тест пройдений
3.	Після авторизації з роллю Користувач перейти за посиланням «Нові користувачі»	Повинна відкритися сторінка «Нові користувачі»	Відкривається сторінка «Нові користувачі», де можна створювати нових користувачів системи	Тест пройдений

2.9 Розгортання програмного продукту

Розгортання додатку можливе на локальному та зовнішньому сервері. Для розгортання додатку на локальному сервері необхідно:

-- частота процесора 2Ггц або більше;

-- ОЗП не менше 1Гб;

-- IIS Internet Information Server;

-- Windows Server 2008 і вище;

-- SQL Server 2008 і вище;

-- наявність встановленої операційної системи Windows 7 та вище.

Для розгортання додатку на зовнішньому сервері:

-- частота процесора 2Ггц або більше;

-- ОЗП не менше 2Гб;

-- IIS Internet Information Server;

-- Windows Server 2008 і вище;

-- SQL Server 2008 і вище;

-- наявність встановленої операційної системи Windows 7 та вище.

Для розгортання програмного продукту необхідно виконати запуск проекту у Microsoft Visual Studio та у запиті в браузері прописати URL локального хосту [48]. Це дозволяє динамічно формувати автоматично оновлювані веб - сторінки з боку веб - сервера.

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



ВИСНОВКИ

В ході виконання переддипломної практики була проаналізована корпоративна мережі ХНЕУ імені Семена Кузнеця, а також був здійснений опис предметної області «Планування навантаження викладачів кафедри».

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

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

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

При виконанні переддипломної практики використовувалися такі інструментальні засоби: IBM Rational Rose, Ramus Educational, ERwin, Adobe Photoshop, Notepad++, Visual Studio 2015, Git, Source Tree, SQL Server Managment Studio.

Моделювання системи оптимізації комплексу задач було виконано за допомогою середовища ERWin та RationalRose, SQL Server Managment Studio. Програмне забезпечення реалізовано за допомогою: MS Visual Studio 2015 та MS SQL. При проектуванні системи було обрано структурний підхід.

Результати оптимізації планування роботи професорсько-викладацього складу кафедри впроваджені в веб ресурсі «Планувальник навантаження викладачів Харківського національного економічного університету імені Семена Кузнеця».

В результаті були вирішені наступні завдання:

-- проходження інструктажу з техніки безпеки;

-- ознайомлення з об'єктом управління;

-- визначення основних питань за проблемою;

-- проведення дослідження за поставленим завданням;

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

-- апробація результатів дослідження;

-- оформлення звіту.

При проектуванні модулю, були реалізовані наступні функції:

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

-- додавання, редагування та видалення інформації в цих індивідуальних планах;

-- збереження заповнених індивідуальних планів у базі даних;

-- друк сформованого індивідуального плану викладача.

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



СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. Про вищу освіту / Закон України від 01.07.2014 р. № 1556 - VІІ (зі змінами та доповненнями), 2014 р.

2. Норми часу для планування і обліку навчальної роботи та переліки основних видів методичної, наукової й організаційної роботи педагогічних і науково - педагогічних працівників ВНЗ / наказ Міністерства освіти України №450 від 07.08.02 р.

3. ДСТУ 1.5:2015 Національна стандартизація Правила розроблення, викладання та оформлення нормативних документів. Київ: ДП "УкрНДНЦ", 2015. 65с.

4. ДСТУ 7093:2009 Бібліографічний запис. скорочення слів і словосполук, пода-них іноземними європейськими мовами. Київ: Кн. палата України, 2017. 17c.

5. ДСТУ 3008-15 Інформація та документація. Звіти у сфері науки і техніки. Структура та правила оформлювання. Київ: ДП "УкрНДНЦ", 2016. 31с.

6. ДСТУ 3582:2013 Бібліографічний опис. Скорочення слів і словосполу-чень українською мовою. Загальні вимоги та правила. Київ: Мінекономро-звитку України, 2014. 15с.

7. Блэк Рекс. Ключевіе процессі тестирования. Планирование, подготовка, проведение, совершенствование. / Блэк Р. - М. : Лори, 2011. - 544с.

8. Гради Б. Объектно - ориентированній анализ и проектирование с примерами приложений. / Б. Гради, А. Роберт, Максимчук, У. Майкл. и др. - М. : Издательский дом "Вильямс", 2010. - 720 с.

9. Грибан В. Г. Охорона праці: навч. посібник. [для студ. вищ. навч. закл.] / В. Г. Грибан, О. В. Негодченко - К.: Центр учбової літератури, 2009. - 280 с.

10. Методичні рекомендації до виконання дипломного проекту освіньо - кваліфікаційного рівня «бакалавр» для студентів напряму підготовки 6.050101 «Комп'ютерні науки» всіх форм навчання / укл. І. О. Золотарьова, Ю. Е. Парфьонов, І. О. Ушакова та ін. - Х. : Вид. ХНЕУ, 2012. - 87 с.

11. Пономаренко В. С. Інформаційні системи в сучасному бізнесі: навч. посіб. / В. С. Пономаренко, І. О. Золотарьова, Р. К. Бутова, Г. О. Плеханова - Х. : Вид. ХНЕУ, 2011. - 484 с.

12. Управління якістю освіти у вищих навчальних закладах [Текст] : навч. посіб. : у 2 ч. Ч. 1: Теоретичні засади формування систем управління якістю надання освітніх послуг / кол. авт. ; за заг. ред. чл.-кор. НАН України В. С. Загорського. - Львів : ЛРІДУ НАДУ, 2011. - 136 с.

13. Ревак І.О. Корупція: теоретико-методологічні засади дослідження: монографія / І.О. Ревак. - Львів: ЛьвДУВС, 2011. - 220 c.

14. Методичні рекомендації щодо створення системи управління освітою об'єднаних територіальних громад / Авт.: Айдер Сеїтосманов, Олег Фасоля, Войцех Мархлєвский //Розроблено разом з Департаментом освіти і науки Хмельницької обласної державної адміністрації. - Хмельницький: 2016. - 22 с.

15. Евсеев С.П. Методология оценивания безопасности информационных технологий автоматизированных банковских систем Украины // Науково-технічний журнал “Захист інформації”. том.22. № 2. Київ. - 2016. - с. 297 - 309.

16. Евсеев С.П. Синергетическая модель оценки безопасности банковской информации // Науково-технічний журнал “Інформаційна безпека”. № 4. Сєвєродонецьк. - 2016. - С. 43 - 58.

17. Евсеев С.П. Модель нарушителя прав доступа в автоматизированной банковской системе на основе синергетического подхода //Науково-технічний журнал “Інформаційна безпека”. № 17. Сєвєродонецьк. - 2017. - С. 58 - 69.

18. Дудыкевич В.Б. Стратегия безопасности киберфизических систем / В.Б. Будыкевич, В.Н. Максимович, Г.В. Микитин // Информационные технологии в управлении, образовании, науке: Монография/ Под ред. В.С. Пономаренко - Х. : Вид-во ФОП В.В. Петров, 2016. - 464 с. (С. 286 - 300).

19. Евсеев С.П. Синергетические модели оценки безопасности в автоматизированных банковских системах / С.П. Евсеев, О.Г. Король// Інформаційні технології: проблеми та перспективи: монографія / за заг. ред. В. С. Пономаренка. - Х. : Вид. Рожко С. Г., 2017. - 447 с. (С. 203 - 221).

20. Hryshchuk R. The synergetic approach for providing bank information security: the problem formulation // R. Hryshchuk , S. Yevseiev / Безпека інформації. - 2016. - № 22 (1). - С. 64 - 74. - doi:10.18372/2225-5036.22.10456.

21. Тарасов О. В. Проектування схем баз даних. Практикум з навчальної дисципліни «Організація баз даних та знань»: навч. - практ. посіб. / О. В. Тарасов, Л. А. Павленко - Х. : Вид. ХНЕУ, 2012. - 100 с.

22. Ушакова І. О. Практикум з навчальної дисципліни «Основи системного аналізу об'єктів і процесів комп'ютеризації»: навч. - практ. Посібн / Ушакова І. О., Плеханова Г. О.. - Х. : Вид. ХНЕУ, 2010. - 344 с.

23. Ушакова І. О. Практикум з навчальної дисципліни «Основи системного аналізу об'єктів і процесів комп'ютеризації»: навч. - практ. Посібн / Ушакова І. О., Плеханова Г. О.. - Х. : Вид. ХНЕУ, 2010. - 344 с.

24. Вимоги до оформлення курсових і дипломних проектів: методичні рекомендації для студентів галузей знань 12 "інформаційні технології" та 18 "виробництво та технології" / укл. Гаврилова А. А., Євсеєв С. П., Коц Г. П., Пушкар О. І., Руденко О. Г. - Х. : Вид. ХНЕУ, 2018. - 49 с.

25. Шилдт Г. C# 4.0: полное руководство.: Пер. с англ. - М.: ООО "И.Д. Вильямс", 2011. - 1056 с.

26. ISO 690:2010 Information and documentation - Guidelines for biblio-graphic references and citations to information resources.



ДОДАТОК

Організаційна структура управління «ХНЕУ імені Семена Кузнеця»

Размещено на Allbest.ru