Всім привіт. Я часто застосовую у своїй роботі принципи системної інженерії та хотів би поділитися цим підходом із спільнотою.
Системна інженерія – без стандартів, а по-простому, це процес розробки системи досить абстрактних компонентів, без прив'язки до конкретних зразків пристроїв. У ході цього процесу встановлюються властивості компонентів системи та зв'язку між ними. Додатково потрібно зробити систему несуперечливою та оптимальною і щоб система відповідала вимогам. У цьому туторіалі я покажу прийоми системної інженерії на прикладі проектування досить простої системи контролю доступу (СКУД).
Формуємо початкову архітектуру
Коли система, не має значення яка, тільки починає розроблятися, у нас в голові або на папері з'являються прямокутники зі стрілками. Такі прямокутники – це і є компоненты системи. А стрілки – це з'єднання між компонентами І дуже часто у нас немає часу посидіти і подумати, як усі ті компоненти, які ми визначили працюватимуть один з одним, а в результаті ми починаємо створювати купу милиць, вигадуючи надлишкові конструкції.
Важливо пам'ятати, що з точки зору системи та її архітектури компонент це досить абстрактна штука. Наприклад, якщо в нашій системі є мікроконтролер, то на рівні архітектури нам важливим є лише те, що це мікроконтролер, а не те, що це STM32, Arduino або Міландр. Більше того, часто нам взагалі незрозуміло, що саме буде в системі, і ми звертаємося до системної інженерії для вироблення вимог до обладнання, софту тощо.
Для нашого прикладу зі СКУД спробуємо сформулювати її призначення. Це допоможе нам у визначенні її компонентів. Отже, завдання СКУД – пропускати до приміщення обмежене коло людей. Тобто це розумний замок. Отже, у нас з'явився перший компонент - якийсь пристрій, що замикає і відчиняє двері! Назвемо його Замок
А як ми дізнаємося, що людина може потрапити усередину? Ми ж не хочемо садити вахтера та перевіряти паспорти? Давайте видавати людям спеціальні картки з RFID-мітками, на які записуватимемо унікальні ID або інші дані, що дозволяють точно ідентифікувати людину. Тоді нам знадобиться якийсь пристрій, який зможе читати ці мітки. Прекрасно, у нас є ще один компонент, RFIDReader
Погляньмо ще раз на те, що в нас вийшло. RFIDReader читає деякі дані, система СКУД щось із нею робить, і виходячи з цього чогось управляється Замок. Задамо наступне питання – а де зберігати список людей із правами доступу? Найкраще у базі даних. Отже, наша система має вміти надсилати запити та обробляти відповіді від бази даних. Таким чином, у нас є ще один компонент – DBHandler. Отже, ми отримали вкрай абстрактний, але достатній для початку опис системи. Ми розуміємо, що вона має робити і як це влаштовано.
Замість аркуша паперу я використовую System Composer, спеціальний інструмент для моделювання архітектур систем у середовищі Simulink і створюю 3 компоненти. Вище я описав зв'язки між цими компонентами, тому відразу з'єднаємо їх:
Розширюємо архітектуру
Подивимося на нашу схему. Здається, що все гаразд, але насправді ні. Подивіться цю систему з погляду користувача — користувач підносить карту до зчитувача і…? Як користувач дізнається, що йому дозволено чи заборонено доступ? Потрібно якось його ще сповіщати про це! Тому додамо ще один компонент – повідомлення користувача, UserNotify:
А тепер спустимося на рівень абстракції нижче. Спробуємо розписати деякі компоненти трохи докладніше. Почнемо з компонента RFIDReader. У нашій системі цей компонент відповідає за читання RFID-мітки. На його виході повинні бути деякі дані (UID, дані користувача ...). Але стривайте RFID, як і NFC — це в першу чергу залізо, а не софт! Тому можна припустити, що у нас окремо є сам чіп для RFID, який передає «сирі» дані до якогось передобробника. Отже, ми маємо абстрактну залізницю, яка вміє читати RFID-мітки, і абстрактний софт, який вміє перетворювати дані в потрібний нам формат. Назвемо їх RFIDSensor и RFIDParser відповідно. Як це відобразити у System Composer? Можна видалити компонент RFIDReader і замість нього поставити два компоненти, але так краще не робити, так ми втратимо читання архітектури. Замість цього зайдемо всередину RFIDReader і додамо 2 нових компоненти:
Відмінно тепер перейдемо до оповіщення користувача. Як система сповістить користувача про те, що йому заборонено чи дозволено доступ до приміщення? Людина сприймає найкраще звуки і щось миготливе. Тому можна видати якийсь звуковий сигнал, щоб користувач звернув увагу, і поблимати світлодіодом. Додамо відповідні компоненти в UserNotify:
Ми створили архітектуру нашої системи, але щось не так. Що ж? Подивимося на імена з'єднань. InBus и OutBus — не зовсім нормальні імена, які допомагали б розробнику. Їх треба перейменувати:
Отже, ми подивилися на те, як застосовуються методи системної інженерії в самому грубому наближенні. Постає питання — навіщо їх застосовувати взагалі? Система примітивна, і здається, що виконана робота зайва. Можна було б одразу писати код, проектувати БД, писати запити чи паяти. Проблема полягає в тому, що якщо не продумати систему, не зрозуміти як її компоненти пов'язані один з одним, то інтеграція компонентів системи буде довго і досить болісно.
Головний висновок із цієї частини такий:
Застосування методів системної інженерії та моделювання архітектур при розробці систем дозволяє скоротити витрати на інтеграцію компонентів та підвищити якість системи, що розробляється.
Джерело: habr.com