Вхідною інформацією для програмного забезпечення буде інформація про конфігурацію силової підстанції, де має зазначатись інформація про трансформатори, що використовуються, їх конфігурацію, дані про лінії електропередач, тощо. Також інформація взята із відділу кадрів про робітників компанії та розпорядження для сформованих бригад на здійснення робіт у зазначених підстанціях.
До вхідних даних потрібно віднести довідникову інформацію про кабелі, проводи та коефіцієнти для розрахунку фізичних величин.
Вихідними даними будуть форми представлені користувачу із висвітленою інформацією, а також звіти. Звіти формуватимуться із відповідних зразків, із автоматичним занесенням даних для подальшого роздруку, щоб документацію засвідчити підписами фігуруючих осіб.
Вимоги до проектної документації
Проектна документація повина бути розроблена згідно державних стандартів України. Вона має містити максимальну інформацію щодо проекту, детальну інструкцію з використання, де кожен пункт повинен бути проілюстрований відповідними зображенням з детальним описом виконуваних дій і призначенням тої чи іншої функції. В той же час проектна документація має бути виконана з 1.5 інтервалом, 14 розміром шрифту Times New Roman.
Опис усіх етапів розробки має бути простим і легким для розуміння. Також в проектній документації повинні описуватись інструкції з інсталяції, оновлення, видалення, експорту. До документації мають додаватись всі особливості апаратної та програмної частин, тобто версії програм на яких написаний даний програмний продукт, версії всіх бібліотек і фреймворків, всі паролі доступів до серверів та баз даних.
Важливою частиною дипломного проектування є побудова графічних додатків, що б візуально демонстрували різні етапи роботи.
При проектуванні програмного продукту використати наявний інструментарій побудови UML-діаграм, що б наглядно демонстрували сам процес проектування, полегшили б подальшу програмну реалізацію, інсталяцію програми. Для цього слід реалізувати наступні UML-діаграми: діаграма використання, діаграма активності, діаграма компонентів, діаграма розгортання, діаграма послідовності дій.
Також слід провести проектування та нормалізацію бази даних програмного продукту. Результатом проектування має бути інфологічна модель бази даних, що слід відобразити також у графічних додатках.
Етапи проектування
На етапі проектування відбувається важливий процес створення архітектури системи, від даного кроку залежать всі наступні кроки розробки системи. Етап проектування структури бази даних можна розбити на такі кроки:
- визначення вимог до програмного забезпечення сервера баз даних:
- аналіз вхідних та вихідних даних;
- визначення зв’язків між сутностями;
- нормалізація структури даних.
Розробка інтерфейсу користувача:
- визначення з основними принципами побудови інтерфейсу;
- створення попереднього шаблону зовнішнього вигляду;
- розробка макетів;
- вибір зовнішнього оформлення інтерфейсу.
Проектування та розробка програмної частини:
- визначення середовища розробки та інших інструментальних засобів;
- визначення зовнішніх бібліотек та допоміжних засобів розробки;
- проектування архітектури системи;
- розробка класів для реалізації системної логіки.
Порядок тестування розробки
При тестуванні розробленого програмного продукту слід використати інтеграційне та модульне тестування. При цьому слід спиратись на наступні стандарти з перевірки і тестування модулів:IEEE 829:1996 і IEEE 1008:1987.
При проведенні інтеграційного тестування модулів системи слід врахувати роботу їх інтерфейсів під час виконання.
При проведені різних видів перевірок необхідно зібрати дані про помилки, дефекти, відмови тощо і оформити відповідну документацію.
Також слід виконати функціональне тестування системи для різних експлуатаційних випадків, станів програмної системи.
Для якісної роботи користувачів із системою слід виконати тестування користувацького інтерфейсу, що полягає у перевірці правильності навігації по об’єкту тестування та відповідність опису елементів до дій, які вони виконують.
У цьому розділі було здійснено короткий огляд причини створення спеціалізованого програмного забезпечення для енергопостачальних компаній, які залежать від процесів, що виконуються працівниками компанії стосовно силових підстанцій, та визначаються важкістю оперування великими об’ємами інформації про них.
Було визначено основні можливості, які потрібно реалізувати у дипломному проекті, та розписано, що вони мають здійснювати.
Проектування архітектурипрограмного продукту буде виконуватись за допомогою діаграм, які будуть відображати основні компоненти та об’єкти системи, функції, які вони мають виконувати.
Для визначення основних варіантів використання системи, що розробляється, використаємо діаграму прецедентів (Use Case), яка зображена на рисунку 2.1.
Основними зовнішніми сутностями є
Оператор та Працівник. Спершу оператор системи повинен здійснити певні дії, щоб
занести дані про енергетичні підстанції, задати параметри таким елементам, як:
оперативний струм, силовий трансформатор, лінії 10кВ, трансформатор напруги та
ін.. Після того, як Оператором було створено об’єкти для опрацювання, він має
ще занести до даних системи інформацію про співробітників робочих бригад, які в
свою чергу мають надати певні персональні дані.
Рисунок 2.1 - Діаграма прецедентів
(Use Case)
Коли необхідні для оперування дані в систему занесені, Оператор може здійснювати створення задач для бригади працівників на конкретних підстанціях. Працівники бригади заносяться до кожного завдання.
Деталізацію процесів системи
відображає діаграма послідовності дій показано на рисунку 2.2, яка відображає
взаємодії об’єктів впорядкованих за часом.
Рисунок 2.2 - Діаграма послідовності
(Sequence Diagram)
Як видно із діаграми для створення підстанції недостатньо вказати параметри елементів підстанції, а ще й обов’язково надати їй назву для задання ідентифікації, при відсутності якої, не відбудеться збереження даних у системі.
Процес, що показаний на діаграмі послідовності, можна деталізувати за допомогою іншої діаграми, а саме діаграми діяльності, на якій показано необхідні реакції на введені дані, чи виконані дії.
Отже, діаграма діяльності, що
зображена на рисунку 2.3, відображає, що для створення нової підстанції, як
зазначали раніше, потрібно ввести параметри системи, а саме: кількість
трансформаторів, їх потужність та тип, лінії електропередачі, їх довжину та тип,
трансформатор напруги, силу струму та інші дані. Пам’ятаємо, щоб дані
збереглися, потрібно надати назву підстанції, тому що іншому випадку система
проігнорує введені користувачем дані.
Рисунок 2.3 - Діаграма діяльності
створення нової підстанції
Схожий принцип і при додаванні
робітників у систему показано на рисунку 2.4.Тобто операторові необхідно взяти
персональні дані робітника та ввести їх у систему, після чого у ній
здійснюється перевірка на те, чи дані, введені оператором, відповідають
необхідним правилам, чи вони є коректними.Після цього буде відбуватись
збереження даних.
Рисунок 2.4 - Діаграма діяльності
добавлення робітника
Приведемо діаграму діяльності для
роботи проекту в цілому показано на рисунку 2.5. При вході в проект потрібно
здійснити підключення до серверу бази даних, якщо ж підключення відсутнє,
працювати із системою буде неможливо, адже дані проекту не завантажаться, і
потрібно буде перейти на гілку зміни параметрів підключення до серверу БД.
Рисунок 2.5 - Діаграма діяльності
роботи проекту
Якщо проект під’єднається до серверу БД, то можна буде здійснювати ряд функціональних можливостей, основні з яких відображені на діаграмі, а саме: вище розглянуте створення нової підстанції, добавлення робітників та створення завдання.
Завдання може бути двох типів заплановане та ремонтне. Зрозуміло, що це потрібно буде задати і при створені завдання, так само як і на якій підстанції виконати завдання, та яким робітникам доручено завдання. Після оформлення завдання відповідно буде з генерована звітність.
Використовуючи у проекті бази даних, потрібно звернути увагу на варіант розміщення даних, що також може вплинути на конфігурацію системи. Розрізняють два види архітектур бази даних: віддалений та локальний.
Локальний варіант передбачає розміщення даних безпосередньо на комп'ютері користувача. В цьому випадку користувач володіє монопольним доступом до даних, доступ до даних інших користувачі неможливий.
Віддалений варіант передбачає розміщення даних поза комп’ютерами користувачів - на файловому сервері мережі або на спеціально виділеному комп’ютері.
Використовуючи віддалений варіант зберігання даних потребує використання на персональномукомп’ютері мережевої плати, налаштованої під внутрішню мережу компанії, або до мережі Інтернет, що також надає можливість підключення до серверу бази даних. У такий спосіб буде використовуватись архітектура клієнт-сервер.
Дана архітектура є домінуючою концепцією у створенні розподілених мережних додатків і передбачає взаємодію та обмін даними між ними. В даній архітектурі для обробки даних виділяється сервер баз даних, який виконує функції обробки запитів, що надходять від клієнтів.
Перевагами даної архітектури є: зменшення навантаження на мережу, збільшення надійності роботи системи, зменшення вимог до потужності комп’ютерів-клієнтів, обробка і збереження даних відбувається в єдиному “центрі”, що призводить до збереження логічної цілісності структури даних.
До недоліків даної архітектури можна
віднести: відносна складність розробки програмних систем з використанням даної
архітектури, збільшення часу розробки і затрат матеріальних і інтелектуальних
ресурсів на створення програмних систем порівняно з системами з використанням
архітектури файл-сервер. Саме
таку клієнт-серверну
архітектуру використаємо для реалізації поставленого завдання.
Розробимо статичне представлення структури даних моделі використовуючи діаграму класів.
Діаграма отриманих класів зображена
на рисунку 2.6. Діаграма відображає основні класи з якими взаємодіє система, на
основі цих класів буде побудована база даних до системи. Класи складаються з
атрибутів та методів, які вони виконують у процесі розрахунків та створення
елементів енергетичної підстанції.
Рисунок 2.6 - Діаграма класів
Діаграма компонентів бази даних системизображена на рисунку 2.7.
Діаграма зображує компоненти з яких буде складатися база даних та зв’язки між
ними. Додатково потрібно зазначити, що на основі інтерфейсу бази даних потрібно
буде реалізувати власний модуль, за допомогою якого, буде здійснюватись обмін
даними між компонентами проекту та базою даних на сервері.
Рисунок 2.7 - Діаграма компонентів
бази даних системи
На основі створеної діаграми компонентів бази даних системи можна створити інфологічну модель бази даних системи. Для цього потрібно провести нормалізацію бази даних, тобто структурувати усю вхідну інформацію, розкласти початкове відношення на кілька простих відношень меншого розміру.
При аналізі отриманих таблиць були усунуті дублювання полів, перевірялась умова атомарності кожного поля. Після цього база даних була приведена до першої нормальної форми.
У процесі розбиття на таблиці до кожної з них був доданий первинний ключ, що є унікальним. Усі інші поля таблиці залежать від нього. Це дало можливість привести базу даних до другої нормальної форми.
Далі реалізували зв’язки між таблицями додавши вторинні (зовнішні) ключі у підлеглі таблиці. Ці поля зв’язали із відповідними первинними ключами головних таблиць.
Після цього був проведений аналіз отриманої структури бази даних на предмет наявності транзитивних залежностей. Оскільки таких залежностей виявлено не було, база даних відповідає вимогам третьої нормальної форми.
Проектування архітектури та структур даних системи показує, які основні компоненти будуть взаємодіяти в системі та як відбуватимуться дії, при певних діях користувача. На основі діаграми класів було розроблено структуру бази даних до створюваної системи з відповідними атрибутами та методами. На основі діаграм компонент визначено, які функції мають виконувати об’єкти системи. За допомогою діаграм визначено вхідні і вихідні дані до створюваної системи.
Проектування та подальша програмна реалізація інтерфейсу є дуже важливим етапом розробки програмного продукту, оскільки якісний інтерфейс забезпечує як функціональність програмного забезпечення, так і зручність роботи із нею.
Інтерфейс програми- сукупність засобів для обробки та відображення інформації, максимально пристосованих для зручності користувача; у графічних системах інтерфейс користувача реалізовується багатовіконним режимом, змінами кольору, розміру, видимості (прозорість, напівпрозорість, невидимість) вікон, їх розташуванням, сортуванням елементів вікон, гнучкими налаштовуваннями як самих вікон, так і окремих їх елементів (файли, папки, ярлики, шрифти тощо), доступністю багатокористувацьких налаштувань.
Було розроблено ряд макетів форм, що дозволять якісно спроектувати інтерфейс.
Насамперед спроектуємо інтерфейс головної форми проекту. Для цього розділимо умовно цю форму на три частини:
- заголовк форми, що має містити назву програмного продукту;
- головне меню програми, що забезпечить виконання основних функціональних можливостей;
- робоча область форми. Сюди будуть виводитись результуючі дані, завантажуватись додаткові форми, засоби керування ними.
Виходячи із обраного способу організації інтерфейсу додаткові форми будуть відображатись у робочій області головної форми. Інтерфейс таких форм буде типовим, змінюватись буде лише їх інформаційна наповнюваність, засоби керування.
Спроектований інтерфейс, архітектура, структури даних програмного продукту дозволяють перейти до етапу програмної реалізації проектних рішень, алгоритмів роботи під задач.
Для реалізації програмного виробу було обране IDE Microsoft Visual C# 2013 Express. Вибір цього середовища був не випадковим, оскільки він дозволяє розробляти як консольні додатки, так і додатки з графічним інтерфейсом, в тому числі з підтримкою технології Windows Forms для всіх платформ, які підтримують Microsoft Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact Framework і Microsoft Silverlight.Visual C# Express - інтегроване віртуальне середовище розробки додатків на мові програмування C# із закритим вихідним кодом, розроблене корпорацією Microsoft. У Microsoft Visual C# є всі інструменти для повноцінної розробки й налагодження програм на мові C# на платформі .NET Framework.C# Express є частиною продуктової лінійки Visual Studio Express family - вільного набору інструментів, які Windows розробники будь-якої кваліфікації можуть використовувати для створення власних додатків, використовуючи базові або розширені можливості. Visual C# створений для роботи над різними типами додатків, які виконуються в середовищі .NET Framework. Завдяки безлічі інновацій, Visual C# забезпечує швидку розробку додатків, при цьому зберігає виразність і елегантність, властиву мовам в стилі С: