Дизајн на системско ниво. Дел 1. Од идеја до систем

Здраво на сите. Често ги применувам принципите на системско инженерство во мојата работа и би сакал да го споделам овој пристап со заедницата.

Системско инженерство - без стандарди, туку едноставно кажано, тоа е процес на развој на систем како прилично апстрактни компоненти, без повикување на конкретни примероци на уреди. Во текот на овој процес се воспоставуваат својствата на компонентите на системот и врските меѓу нив. Дополнително, потребно е системот да се направи конзистентен и оптимален и системот да ги исполнува барањата. Во ова упатство ќе прикажам техники за системско инженерство користејќи го примерот за дизајнирање на прилично едноставен систем за контрола на пристап (ACS).

Формирање на почетната архитектура

Кога системот, без разлика на се, само што почнува да се развива, правоаголници со стрели се појавуваат во нашите глави или на хартија. Такви правоаголници се компонентите системи. И стрелките се соединенија помеѓу компонентите. И многу често немаме време да седиме и да размислуваме како сите компоненти што ги дефиниравме ќе функционираат едни со други, и на крајот почнуваме да создаваме куп патерици, доаѓајќи до вишок дизајни.

Важно е да се запамети дека од гледна точка на системот и неговата архитектура, компонентата е прилично апстрактна работа. На пример, ако нашиот систем има микроконтролер, тогаш на архитектонско ниво ни е важно само да е микроконтролер, а не да е STM32, Arduino или Milander. Покрај тоа, честопати воопшто не ни е јасно што точно ќе има во системот и се обраќаме кон системско инженерство за да развиеме барања за опрема, софтвер итн.

За нашиот пример со ACS, ќе се обидеме да ја формулираме неговата цел. Ова ќе ни помогне да ги идентификуваме неговите компоненти. Значи, задачата на системот за контрола на пристап е да дозволи ограничен круг на луѓе во собата. Тоа е, тоа е паметна брава. Следствено, ја имаме првата компонента - некој вид на уред што ја заклучува и отклучува вратата! Ајде да му се јавиме Заклучување на вратата

Како да знаеме дека човек може да влезе внатре? Не сакаме да ставиме чувар и да ги проверуваме пасошите, нели? Да им дадеме на луѓето специјални картички со РФИД ознаки, на кои ќе снимиме уникатни лични карти или други податоци што ни овозможуваат прецизно да идентификуваме личност. Потоа, ќе ни треба уред кој може да ги чита овие ознаки. Одлично, имаме уште една компонента, RFIDReader

Ајде повторно да погледнеме што добивме. RFIDReader чита некои податоци, системот за контрола на пристап прави нешто со нив, и врз основа на ова нешто се контролира Заклучување на вратата. Да го поставиме следното прашање - каде да се зачува списокот на луѓе со права за пристап? Најдобро во базата на податоци. Затоа, нашиот систем мора да може да испраќа барања и да обработува одговори од базата на податоци. Значи, имаме уште една компонента - DBHandler. Значи, добивме крајно апстрактен, но доволен за почеток, опис на системот. Ние разбираме што треба да прави и како функционира.

Наместо парче хартија, ќе користам System Composer, специјална алатка за моделирање на системските архитектури во околината Simulink и ќе создадам 3 компоненти. Погоре ги опишав врските помеѓу овие компоненти, па ајде веднаш да ги поврземе:

Проширување на архитектурата

Ајде да го погледнеме нашиот дијаграм. Се чини дека се е во ред, но во реалноста не е. Погледнете го овој систем од корисничка гледна точка - корисникот ја носи картичката до читателот и...? Како корисникот знае дали му е дозволен или одбиен пристап? Потребно е некако да го известиме за ова! Затоа, да додадеме уште една компонента - известување за корисникот, UserNotify:

Сега да се спуштиме на пониско ниво на апстракција. Ајде да се обидеме да опишеме некои компоненти малку подетално. Да почнеме со компонентата RFIDReader. Во нашиот систем, оваа компонента е одговорна за читање на ознаката RFID. Неговиот излез треба да содржи некои податоци (UID, кориснички податоци...). Но, чекајте, РФИД, како и NFC, е првенствено хардвер, а не софтвер! Затоа, можеме да претпоставиме дека одделно го имаме самиот чип RFID, кој пренесува „суровини“ податоци до некој вид на препроцесор. Значи, имаме апстрактно парче хардвер што може да чита RFID ознаки и апстрактен софтвер што може да ги конвертира податоците во форматот што ни треба. Ајде да ги повикаме RFID сензор и RFIDпарсер соодветно. Како да се прикаже ова во System Composer? Можете да отстраните компонента RFIDReader и наместо тоа ставете две компоненти, но подобро е да не го правите ова, инаку ќе ја изгубиме читливоста на архитектурата. Наместо тоа, ајде да влеземе во RFIDReader и да додадеме 2 нови компоненти:

Одлично, сега да продолжиме да го известуваме корисникот. Како системот ќе го извести корисникот дека му е забранет или дозволен пристап до просториите? Човек најдобро ги перцепира звуците и нешто што трепка. Затоа, можете да издадете одреден звучен сигнал за корисникот да обрне внимание и да трепне ЛЕР. Ајде да ги додадеме соодветните компоненти на UserNotify:

Ја создадовме архитектурата на нашиот систем, но нешто не е во ред со тоа. Што? Ајде да ги погледнеме имињата на врските. InBus и OutBus - не сосема нормални имиња кои би му помогнале на развивачот. Тие треба да се преименуваат:

Значи, погледнавме како методите на системско инженерство се применуваат во најгрубо приближување. Се поставува прашањето: зошто воопшто да ги користите? Системот е примитивен и се чини дека сработеното е непотребно. Можете веднаш да напишете код, да дизајнирате база на податоци, да пишувате прашања или да залемете. Проблемот е што ако не размислите низ системот и не разберете како неговите компоненти се поврзани едни со други, тогаш интеграцијата на компонентите на системот ќе потрае долго и ќе биде доста болна.

Главното нешто од овој дел е:

Употребата на методи за системско инженерство и моделирање на архитектурата во развојот на системот овозможува да се намалат трошоците за интегрирање на компонентите и да се подобри квалитетот на развиениот систем.

Извор: www.habr.com