- •1 Загальна частина
- •1.1 Аналіз предметної області
- •1.1.1 Аналіз інформаційного забезпечення
- •1.1.2 Постановка задачі
- •1.1.3 Аналіз існуючих програмних продуктів
- •1.1.3.1 Google Форми
- •1.1.3.2 Сервіс VirtualExS
- •1.1.4 Визначення основних термінів програмного продукту
- •1.2 Розробка sadt-діаграми
- •1.2.1 Виділення та опис бізнес-процесів програмного продукту
- •1.2.2 Документування бізнес-процесу програмного продукту на основі sadt-діаграм
- •1.3 Технічне завдання на розробку програмного продукту
- •1.3.1 Введення
- •1.3.2 Підстави для розробки
- •1.3.3 Призначення розробки
- •1.3.5 Вимоги до програмної документації
- •1.3.6 Техніко-економічні показники
- •1.3.7 Стадії і етапи розробки
- •1.3.8 Порядок контролю і приймання
- •1.4 Розробка засобів моделювання програмного продукту
- •1.4.1 Розробка логічної моделі
- •1.4.1.1 Діаграма прецедентів
- •1.4.1.3 Діаграма послідовності
- •1.4.1 Опис мови (середовища) програмування
- •1.4.1.1 Загальні відомості мови c#
- •1.4.2.2 Елементи мови c#
- •2 Спеціальна частина
- •2.1 Структура програмного продукту
- •2.2 Структура і функціональне призначення модулів програмного продукту
- •3 Економічний розділ
- •3.1 Розрахунок капітальних витрат на створення програмного продукту
- •3.2 Розрахунок річної економії поточних витрат
- •4 Розділ з охорони праці
- •4.1 Теоретична частина
- •4.1.1 Вимоги до освітлення
- •4.1.2 Вимоги до магнітних випромінювань
- •4.1.3 Організація робочого простору
- •4.1.4 Вимоги до електробезпеки
- •4.1.5 Вимоги до пожежної безпеки
- •4.1.6 Вимоги до режиму праці і відпочинку
- •4.2 Практична частина
- •4.2.1 Оцінка категорії важкості праці
- •4.2.2 Оздоровлення повітря робочої зони
- •4.2.3 Захист від шуму та вібрації
- •4.2.4 Оцінка ефективності заходів з охорони праці
1.3.8 Порядок контролю і приймання
Контроль здійснюється кінцевими користувачами системи, підключеними на етапі тестування системи.
Прийом комплексу здійснюється після його повної установки і настройки під конкретних користувачів і короткого курсу по навчанню користувачів.
Після закінчення розробки системи повинні бути проведені наступні види випробувань: тестування на захист від некоректного введення; тестування на повноту обміну інформацією між різними додатками.
1.4 Розробка засобів моделювання програмного продукту
1.4.1 Розробка логічної моделі
1.4.1.1 Діаграма прецедентів
Діаграма прецедентів (Use case diagram, діаграма варіантів використання) у UML – діаграма, що відображає відносини між акторами і прецедентами і є складовою частиною моделі прецедентів, що дозволяє описати систему на концептуальному рівні.
Прецедент – можливість модельованої системи (частина її функціональності), завдяки якій користувач може отримати конкретний, вимірний і потрібний йому результат. Прецедент відповідає окремому сервісу системи, визначає один з варіантів її використання та описує типовий спосіб взаємодії користувача з системою. Варіанти використання зазвичай застосовуються для специфікації зовнішніх вимог до системи.
Основне призначення діаграми – опис функціональності і поведінки, що дозволяє замовнику, кінцевому користувачеві і розробнику спільно обговорювати проектовану або існуючу систему.
На рисунку 1.4 показана діаграма прецедентів програми «Социологические исследования».
Рисунок 1.4 – Діаграма прецедентів програми «Социологические исследования»
На цій діаграмі показаний актор – користувач – та його можливі дії. Для початку роботи користувач повинен запустити програму. Після цього користувач може або перейти до створення опитувань, або вибрати опитування для проходження, або перейти до перегляду статистики. Якщо користувач вибере створення опитування, то йому треба буде задати назву опитування та додати запитання, до кожного з яких треба додавати варіанти відповіді. Якщо користувач вибере проходження опитувань, то він зможе переглядати запитання та надавати на них відповіді. Якщо користувач вибере перегляд статистики, то він зможе переглядати запитання, кількість відповідей на кожне з них та процентну частку кожного варіанту відповіді.
1.4.1.2 Діаграма класів
Центральне місце в ООАП займає розробка логічної моделі системи у вигляді діаграми класів. Діаграма класів (classdiagram) служить для представлення статичної структури моделі системи в термінології класів об'єктно-орієнтованого програмування. Діаграма класів може відбивати, зокрема, різні взаємозв'язки між окремими сутностями предметної області, такими як об'єкти і підсистеми, а також описує їхню внутрішню структуру і типи відносин. На даній діаграмі не вказується інформація про тимчасові аспектах функціонування системи. З цієї точки зору діаграма класів є подальшим розвитком концептуальної моделі проектованої системи.
Діаграма класів являє собою деякий граф, вершинами якого є елементи типу «класифікатор», які пов'язані різними типами структурних відносин. Слід зауважити, що діаграма класів може також містити інтерфейси, пакети, відносини і навіть окремі екземпляри, такі як об'єкти та зв'язку. Коли говорять про даній діаграмі, мають на увазі статичну структурну модель проектованої системи. Тому діаграму класів прийнято вважати графічним представленому таких структурних взаємозв'язків логічної моделі системи, які не залежать або інваріантні від часу.
Діаграма класів складається з безлічі елементів, які в сукупності відображають декларативні знання про предметну область. Ці знання інтерпретуються в базових поняттях мови UML, таких як класи, інтерфейси і відносини між ними та їх складовими компонентами. При цьому окремі компоненти цієї діаграми можуть утворювати пакети для представлення більш загальної моделі системи. Якщо діаграма класів є частиною деякого пакету, то її компоненти повинні відповідати елементам цього пакета, включаючи можливі посилання на елементи з інших пакетів.
У загальному випадку пакет статичної структурної моделі може бути представлений у вигляді однієї або декількох діаграм класів. Декомпозиція деякого уявлення на окремі діаграми виконується з метою зручності та графічної візуалізації структурних взаємозв'язків предметної області. При цьому компоненти діаграми відповідають елементам статичної семантичної моделі. Модель системи, у свою чергу, повинна бути узгоджена з внутрішньою структурою класів, яка описується на мові UML.
На рисунку 1.5 зображена діаграма класів програми «Социологические исследования».
Рисунок 1.5 – Діаграма класів програми «Социологические исследования»
На цій діаграмі показані зв'язку інформаційної системи з класами і операціями програми «Социологические исследования».
Клас «Опитування» є опитуванням, що створюється в програмі. Цей клас має такі атрибути, як «Назва», «Запитання» та «Кількість запитань».
Клас «Запитання» є запитанням, що включено до опитування. Цей клас має такі атрибути, як «Назва опитування», «Заголовок», «Варіанти відповіді» та «Кількість варіантів відповіді».
Класи «Статистика» є статистикою проведених опитувань. Цей клас має такі атрибути, як «Назва опитування», «Запитання» та «Обрана відповідь».
Всі класи програми мають спільний набір операцій, до якого входять операції «Введення даних», «Виведення даних», «Обробка даних» та «Збереження даних».
