3.2. Основні прецеденти

3.3. Прототип інтерфейсу

На початку створення системи постало питання, в якому вигляді її подати користувачеві. Було вирішено зробити консольну програму в якій будуть відображатися елементи матриці які означають різні стани клітини. Вони будуть змінюватися за заданим алгоритмом. Користувач може вводити дані з клавіатури які впливають на розміщення елементів в полі, а саме на початку роботи програми користувач повинен задати розмір поля (матриці) на якому буде відтворюватися візуалізація розповсюдження хвороби. Користувач повинен вручну переходити на наступний проміжок часу, який відображає поточний стан розповсюдження інфекції.

Створена система виглядає наступним чином: консольне вікно, в якому зображена матриця з заданим розміром, над матрицею показується якого стану набувають клітини на даному проміжку часу, а під матрицею нам задається питання: «Чи бажаєте ви продовжити(Y/N)».

Вводимо з клавіатури «Y»,нам буде представлено наступний проміжок. Якщо ми вводимо «N»,або якийсь інший символ то програма припиняє свою роботу. Якщо ввести «Y» кілька разів, то відображається стан клітин, яким він буде через декілька проміжків(скільки «Y», скільки проміжків пройде).

4. Опис архітектури системи

4.1. Поняття про архітектуру системи

Початок архітектурі програмного забезпечення як концепції було покладено в науково-дослідницькій роботі Едсгера Дейкстри в 1968 році і Девіда Парнаса на початку 1970-х. Ці вчені підкреслили, що структура системи ПЗ має важливе значення, і що побудова правильної структури - критично важливо. Популярність вивчення цієї області зросла з початку 1990-х років разом з науково-дослідницькою роботою по дослідженню архітектурних стилів (шаблонів), мов описання архітектури, документування архітектури і формальних методів.

У розвитку архітектури програмного забезпечення як дисципліни відіграють важливу роль науково-дослідницькі установи. Мері Шоу і Девід Герлан з університету Carnegie Mellon написали книгу під назвою «Архітектура програмного забезпечення: перспективи нової дисципліни в 1996 році», в якій висунули концепції архітектури програмного забезпечення, такі як компоненти, з'єднувачі (connectors), стилі і так далі. У Каліфорнійському університеті в Ірвайні інститут по дослідженню ПЗ насамперед досліджує архітектурні стилі, мови опису архітектури і динамічні архітектури.

Першим стандартом програмної архітектури є стандарт IEEE 1471: ANSI / IEEE 1471–2000: Рекомендації по опису переважно програмних систем. Він був прийнятий в 2007 році, під назвою ISO / IEC 42010:2007.

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

Архітектура системи – це структурна схема компонентів системи, взаємодіючих між собою через інтерфейси. Компоненти можуть складатися з послідовності більш дрібних компонентів та інтерфейсів. Розроблення архітектури ґрунтується на загальних довідниках, класифікаторах та ін. У ній ідентифікуються загальні частини системи, у тому числі готові програмні продукти і заново розроблені компоненти, а також багаторазово використовувані в інших застосуваннях.

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

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

Проектування системи може здійснюватися на основі об'єкто-орієнтованого моделювання методом UML, який дозволяє враховувати аспекти, властиві діючим особам (акторам) системи, створювати сценарії виконання системи тощо. Об’єктний стиль проектування – це декомпозиція майбутньої системи на окремі підсистеми (пакети), визначення функціональних і нефункціональних вимог і об’єктної моделі предметної області. Носіями інтересів, можливостей і дій в системі (або пакеті) є діючі особи – актори. Пакет може складатися з об’єктної моделі, варіантів використання, що визначають сценарії поведінки системи, склад об’єктів і методів їхньої взаємодії. Поведінка об’єктів відображується діаграмами, що задають послідовність взаємодії об’єктів (діаграми послідовностей, взаємодії), правилами переходу від стану до стану (діаграми станів), а також діаграмами кооперації, в яких діючі особи зображуються графічно. Об’єкти і відповідні їм діаграми варіантів використання задають загальну архітектурну схему системи, у рамках якої здійснюється реалізація структури і специфіки поведінки компонентів. Загальна концепція об’єктного проектування – це побудова всіх сценаріїв, екранних діаграм для керування ними і їх випробування в різних варіантах використання. На вибір варіантів використання впливають нефункціональні вимоги (наприклад, забезпечення конфіденційності, швидкодії й ін.). На основі моделі опису вимог і понять проводиться уточнення складу і змісту функцій системи, методів їхньої реалізації у вигляді сценаріїв і діаграм потоків даних, у яких відображається взаємодія об’єктів як обмін повідомленнями між елементами системи для передачі даних і одержання відповіді після виконання операцій. Моделі вимог визначають призначення і місце вимог у таких системах. Цьому сприяють розроблені національні, корпоративні і відомчі стандарти. Вони фіксують правила формування нефункціональних вимог, у яких відображаються відомості про взаємодію і захист даних у системі. При цьому поведінка об’єктів представляється діаграмами UML, вони можуть уточнюватися при перегляді моделей вимог і складу об’єктів системи. Перегляд починається з вимог і пошуку місць локалізації для внесення необхідних змін у модель. Зміни можуть стосуватися функціональних і нефункціональних вимог у зв’язку з уточненням замовником обмежень на структуру системи, використовувані ресурси й умови середовища її функціонування.[***]

4.2.