Ўсім прывітанне. Я часта прымяняю ў сваёй працы прынцыпы сістэмнай інжынерыі і хацеў бы падзяліцца гэтым падыходам з супольнасцю.
Сістэмная інжынерыя - без стандартаў, а па-простаму, гэта працэс распрацоўкі сістэмы як дастаткова абстрактных кампанентаў, без прывязкі да канкрэтных узораў прылад. У ходзе гэтага працэсу ўстанаўліваюцца ўласцівасці кампанентаў сістэмы і сувязі паміж імі. Дадаткова патрабуецца зрабіць сістэму несупярэчлівай і аптымальнай і што б сістэма адпавядала патрабаванням. У гэтым тутарыяле я пакажу прыёмы сістэмнай інжынерыі на прыкладзе праектавання дастаткова простай сістэмы кантролю доступу (СКУД).
Фарміруем пачатковую архітэктуру
Калі сістэма, не важна якая, толькі пачынае распрацоўвацца, у нас у галаве ці на паперы з'яўляюцца прастакутнікі са стрэлкамі. Такія прастакутнікі - гэта і ёсць кампаненты сістэмы. А стрэлкі - гэта злучэння паміж кампанентамі. І вельмі часта ў нас няма часу пасядзець і падумаць, як усе тыя кампаненты, якія мы вызначылі будуць сябар з сябрам працаваць, а ў выніку мы пачынаем ствараць кучу мыліц, прыдумляючы залішнія канструкцыі.
Важна памятаць, што з пункту гледжання сістэмы і яе архітэктуры кампанент - гэта дастаткова абстрактная штука. Напрыклад, калі ў нашай сістэме ёсць мікракантролер, то на ўзроўні архітэктуры нам важна толькі тое, што гэта мікракантролер, а не тое, што гэта 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