Лабораторна робота №1.2 Попереднє проектування архітектури програмного забезпечення

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

Теоретичні відомості

Процес проектування складається з декількох етапів. Етап здійсненності: виявлення допустимих концептів проектування в цілому [Error: Reference source not found]. Етап ескізу проекту: обрання і розробка найкращого концепту. Детальний етап: розробка технічного концепту проекту. Етап планування: оцінка та зміна концепції у відповідності з вимогами виробництва, розповсюдження, споживання і кінця життєвого циклу продукту. Є кілька альтернативних стратегій проектування: циклічна – процес може повернутися до більш ранньої стадії, паралельна – незалежні альтернативи розглядаються паралельно, пристосувальний («кладіть рейки, там, де проходите») – наступна стратегія проектування проектної діяльності вирішується в кінці поточного етапу, додаткова – кожен етап розробки розглядається як завдання поступового поліпшення існуючого проектного рішення. Згадаємо основні інженерні інструменти, які застосовують при проектуванні архітектури. Абстракція говорить, що треба надавати увагу деталям і абстрагуватися «вгору» до концепції, а потім додати докладну субструктуру і рухатися «вниз». Розділ відповідальності це поділ проблеми на незалежні частини. Розділ відповідальності часто передбачає багато компромісів: повної незалежності досягти доволі важко. Приклад з архітектури ПЗ: відділення компонентів (обчислення) від з’єднувачів (комунікації).

Основний інструмент при проектуванні ПЗ – це досвід. Досвід має бути релевантний і «відшліфований». Інженери навчаються на досягненнях та невдачах інших інженерів, конференціях, прикладах розробок ПЗ. Досвід може надати початковий набір «альтернативних проектних рішень для проектування». Архітектурні стилі і шаблони – це яскраві приклади досвіду, повторного використання. Архітектурний шаблон – це набір проектних рішень, які застосовуються до повторюваних завдань проектування і параметризовані для того, щоб врахувати різні контексти роботи ПЗ. Архітектурний стиль – це іменована колекція архітектурних проектних рішень, що обмежують множину можливих додаткових проектних рішень, та які можна застосувати у визначеному контексті розробки. Стилі добре підходять для визначення усього, починаючи від структури підсистеми до високорівневої структури ПЗ. До переваг використання архітектурних стилів можна віднести: повторне використання проекту, повторне використання коду, зрозумілість організації ПЗ, візуалізація архітектури ПЗ.

Стиль «Основна програма і підпрограми» складається з основної програми, яка викликає підпрограми, під час свого виконання. Об’єктно-орієнтований стиль: компоненти, це об’єкти, а з’єднувачі це повідомлення та ініціатори виклику методів. Об’єкти відповідальні за внутрішню цілісність їх подання; їх внутрішні структури приховані від інших об’єктів. Багаторівневий стиль визначає ієрархічну організацію системи. Кожен рівень діє як сервер і надає послуги верхнім рівням та/чи клієнту, який користується послугами нижчих рівнів. Стиль «Клієнт-сервер»: компоненти є клієнтами та серверами, сервери не знають кількість клієнтів, клієнти ж знають «позивні» сервера, з’єднувачі – це протоколи для обміну даними по мережі. Стиль «Пакетна послідовність»: окремі програми виконуються в заданому порядку; дані передаються між окремими програмами. З'єднувачами є «людські руки», що переносять дані поміж програмами. Стиль «Канали та фільтри»: компоненти – це фільтри, які перетворюють вхідні потоки даних на вихідні потоки даних та, можливо, роблять виведення деякої інформації користувачу. З’єднувачі – виступають у ролі каналів для потоків даних. Фільтри є незалежними і не мають інформації про інші фільтри. Стиль «Шкільна дошка» має два типи компонентів: центральну структуру даних – дошку та компоненти, що виконують операції на самій дошці. Контроль системи повністю здійснюється поточним станом «дошки». Стиль «На основі правил»: інтерфейс оброблює дані, введені користувачем і перевіряє чи це правило, чи запит. Якщо це правило, він додає запис до бази знань. У іншому випадку він подає запит до бази знань, щоб дати відповідь на запит користувача. Стиль «Інтерпретатор»: інтерпретатор аналізує і виконує введенні команди, та оновлює поточний стан самого себе.

Компонентами є командний інтерпретатор, програма виконання команд, інтерфейс користувача. З’єднувачами зазвичай є прямі виклики процедур. Високо динамічна поведінка можлива, коли набір команд можна змінювати динамічно. Архітектура ПЗ може залишатися без змін, а нові можливості будуть створені на основі існуючих примітивних конструкцій. Стиль «Мобільний код»: елемент даних (деяке зображення програми) динамічно перетворюється на компонент для обчислення даних. Стиль «Видавець – передплатник»: передплатники підписуються або відписуються для отримання специфічних повідомлень чи контенту. Видавці можуть передавати свої повідомлення передплатникам як синхронно, так і асинхронно. Стиль «На основі подій»: незалежні компоненти асинхронно передають та отримуються події, здійснюючи комунікацію за допомогою шини подій. Стиль «Peer-to-peer»: стан та вигляд передається через мережу «рівних», які можуть виступати у ролі клієнта або сервера. Компоненти є незалежними і мають свій власний стан та потік управління.

З’єднувачі – це архітектурні елементи, що моделюють обмін даними між компонентами та визначають правила, за якими буде проходити цей обмін. З’єднувачі можуть виконувати наступні ролі: комунікація, координація, перетворення, спрощення. Існують наступні типи з’єднувачів: виклик процедур, доступу до даних, подія, потік, зв'язок, дистриб’ютор, арбітр та адаптер.