Зразок роботи
2 Практична частина
2.1 Опис програми та її алгоритмів
Проєкт реалізовано за принципами багатофайлової архітектури, що забезпечує зручність супроводу, масштабованість та розділення логіки. Усі файли організовані в єдиній структурі з чітким розподілом функцій між класами (рис. 2.1.1) [8].
Рисунок 2.1.1 – Багатофайлова архітектура застосунку
Архітектура проєкту включає такі файли:
1. Program.cs – точка входу в застосунок. Забезпечує запуск головної форми.
2. Form1.cs – основна форма інтерфейсу користувача. Реалізує логіку обробки подій, підписку на BoardManager та взаємодію з користувачем.
3. Form1.Designer.cs – автоматично згенерований файл із методом InitializeComponent(), що відповідає за компонування елементів інтерфейсу.
4. BoardManager.cs – клас для керування ігровим полем. Виконує побудову сітки, тасування плиток, перестановку та перевірку правильності складання картинки.
5. ImageSlicer.cs – клас для нарізки вихідного зображення на окремі фрагменти, які використовуються у вигляді плиток.
6. TileButton.cs – клас елемента плитки, який наслідує Button. Додає додаткові поля (наприклад, позицію в сітці, правильне місце) для роботи з ігровою логікою.
Основний функціонал програми охоплює:
побудову ігрового поля з урахуванням розміру сітки;
автоматичний розрахунок розміру плиток та їх розміщення на панелі;
відображення правильного індексу для кожної плитки;
можливість взаємодії з плитками через натискання (обробка подій);
перевірку правильності розташування плиток для визначення завершення головоломки;
динамічне масштабування ігрового поля відповідно до розміру вікна.
Таким чином, система реалізує як базові можливості відображення сітки, так і логіку інтерактивної взаємодії з елементами.
У процесі розроблення програмного забезпечення важливим етапом є визначення вимог до системи. Вимоги дозволяють сформувати чітке уявлення про очікувану поведінку програми, її можливості, обмеження та критерії якості. Для системи CollectThePicture вимоги поділяються на функціональні та нефункціональні.
Функціональні вимоги (таблиця 2.1.1) описують безпосередню поведінку програми та її функціонал, тобто, які саме операції система повинна виконувати. Це включає побудову ігрового поля, взаємодію з плитками, перевірку правильності зібраної картинки тощо. Вони визначають, що саме робить програма для користувача [9].
Нефункціональні вимоги (таблиця 2.1.2) стосуються характеристик системи, які не описують її функціонал напряму, але визначають якість, зручність та обмеження роботи. До них належать вимоги до продуктивності, масштабованості, зручності використання, супроводжуваності та естетичності інтерфейсу. Вони визначають, як саме система повинна виконувати свої функції [10].
Таблиця 2.1.1 – Функціональні вимоги
Таблиця 2.1.2 – Нефункціональні вимоги
Для повного опису структури та поведінки програмного забезпечення CollectThePicture використовуються UML-діаграми. Вони дозволяють візуально представити ключові елементи системи, взаємодію між користувачем та програмою, а також структуру об’єктів і їхні взаємозв’язки.
Діаграми прецедентів (Use Case) відображають основні сценарії використання системи з точки зору користувача. Вони показують, які дії користувач може виконувати в програмі, які функціональні можливості доступні та які системні відповіді очікуються. Для CollectThePicture це включає такі прецеденти, як завантаження зображення, перемішування плиток, зміна розміру сітки та складання картинки.
Діаграми класів (Class Diagram) демонструють структуру системи на рівні об’єктів. Вони відображають класи, їхні властивості, методи та зв’язки між класами, що дозволяє зрозуміти внутрішню архітектуру програми. У випадку CollectThePicture це включає класи Form1, BoardManager, TileButton, ImageSlicer та їхні взаємодії.
Використання UML-діаграм сприяє більш чіткому плануванню та аналізу системи, спрощує комунікацію між розробниками та дозволяє наочно продемонструвати логіку роботи програми як для технічної, так і для навчальної документації [11].
