Projektavimas sistemos lygiu. 1 dalis. Nuo idėjos iki sistemos

Sveiki visi. Savo darbe dažnai taikau sistemų inžinerijos principus ir norėčiau pasidalinti šiuo požiūriu su bendruomene.

Sistemų inžinerija – be standartų, o paprasčiau tariant, tai sistemos, kaip gana abstrakčių komponentų, kūrimo procesas, neatsižvelgiant į konkrečius įrenginio pavyzdžius. Šio proceso metu nustatomos sistemos komponentų savybės ir ryšiai tarp jų. Be to, būtina, kad sistema būtų nuosekli ir optimali, o sistema atitiktų keliamus reikalavimus. Šioje pamokoje parodysiu sistemų inžinerijos metodus, naudodamas gana paprastos prieigos kontrolės sistemos (ACS) projektavimo pavyzdį.

Pradinės architektūros formavimas

Kai sistema, nesvarbu, kokia, tik pradeda vystytis, mūsų galvose arba popieriuje atsiranda stačiakampiai su rodyklėmis. Tokie stačiakampiai yra komponentai sistemos. Ir strėlės yra jungtys tarp komponentų. Ir labai dažnai mes neturime laiko sėdėti ir galvoti, kaip visi mūsų apibrėžti komponentai veiks tarpusavyje, ir galiausiai pradedame kurti krūvą ramentų, sugalvodami nereikalingus dizainus.

Svarbu atsiminti, kad sistemos ir jos architektūros požiūriu komponentas yra gana abstraktus dalykas. Pavyzdžiui, jei mūsų sistemoje yra mikrovaldiklis, tai architektūriniu lygmeniu mums svarbu tik, kad tai būtų mikrovaldiklis, o ne STM32, Arduino ar Milander. Be to, dažnai mums visiškai neaišku, kas tiksliai bus sistemoje, ir mes kreipiamės į sistemų inžineriją, kad sukurtume reikalavimus įrangai, programinei įrangai ir pan.

Mūsų pavyzdyje su ACS pabandysime suformuluoti jo tikslą. Tai padės mums nustatyti jo komponentus. Taigi, prieigos kontrolės sistemos užduotis yra įleisti į kambarį ribotą ratą žmonių. Tai yra, tai yra išmanioji spyna. Vadinasi, turime pirmąjį komponentą – kažkokį prietaisą, kuris užrakina ir atrakina duris! Paskambinkime jam Durų užraktas

Kaip žinoti, kad žmogus gali patekti į vidų? Mes nenorime įdėti sargo ir tikrinti pasus, ar ne? Padovanokime žmonėms specialias korteles su RFID žymomis, kuriose įrašysime unikalius ID ar kitus duomenis, leidžiančius tiksliai identifikuoti asmenį. Tada mums reikės įrenginio, galinčio nuskaityti šias žymas. Puiku, turime dar vieną komponentą, RFIDReader

Dar kartą pažiūrėkime, ką gavome. RFIDReader nuskaito kai kuriuos duomenis, prieigos kontrolės sistema kažką su jais daro ir tuo pagrindu kažkas yra valdoma Durų užraktas. Užduokime tokį klausimą – kur saugoti prieigos teises turinčių žmonių sąrašą? Geriausias duomenų bazėje. Todėl mūsų sistema turi turėti galimybę siųsti užklausas ir apdoroti atsakymus iš duomenų bazės. Taigi turime dar vieną komponentą - DBHandleris. Taigi, gavome itin abstraktų, bet pradžiai pakankamą sistemos aprašymą. Mes suprantame, ką jis turi daryti ir kaip tai veikia.

Vietoj popieriaus lapo panaudosiu System Composer – specialų įrankį sistemų architektūroms modeliuoti Simulink aplinkoje ir sukursiu 3 komponentus. Aukščiau aprašiau šių komponentų ryšius, todėl nedelsdami sujunkite juos:

Projektavimas sistemos lygiu. 1 dalis. Nuo idėjos iki sistemos

Architektūros išplėtimas

Pažvelkime į mūsų diagramą. Atrodo, kad viskas gerai, bet iš tikrųjų taip nėra. Pažvelkite į šią sistemą iš vartotojo pusės – vartotojas atneša kortelę skaitytuvui ir...? Kaip vartotojas žino, ar jam leidžiama ar uždrausta prieiga? Būtina kaip nors jam apie tai pranešti! Todėl pridėkime dar vieną komponentą – vartotojo pranešimą, UserNotify:

Projektavimas sistemos lygiu. 1 dalis. Nuo idėjos iki sistemos

Dabar pereikime prie žemesnio abstrakcijos lygio. Pabandykime apibūdinti kai kuriuos komponentus šiek tiek išsamiau. Pradėkime nuo komponento RFIDReader. Mūsų sistemoje šis komponentas yra atsakingas už RFID žymos nuskaitymą. Jo išvestyje turėtų būti tam tikri duomenys (UID, vartotojo duomenys...). Tačiau palaukite, RFID, kaip ir NFC, pirmiausia yra aparatinė įranga, o ne programinė įranga! Todėl galime manyti, kad mes atskirai turime patį RFID lustą, kuris perduoda „neapdorotus“ duomenis į kažkokį išankstinį procesorių. Taigi, turime abstrakčią aparatinę įrangą, kuri gali nuskaityti RFID žymas, ir abstrakčią programinę įrangą, kuri gali konvertuoti duomenis į mums reikalingą formatą. Paskambinkime jiems RFID jutiklis и RFIDParser atitinkamai. Kaip tai parodyti System Composer? Galite pašalinti komponentą RFIDReader ir vietoj to įdėti du komponentus, bet geriau to nedaryti, kitaip prarasime architektūros skaitomumą. Vietoj to, eikime į RFIDReader ir pridėkite 2 naujus komponentus:

Projektavimas sistemos lygiu. 1 dalis. Nuo idėjos iki sistemos

Puiku, dabar pereikime prie pranešimo vartotojui. Kaip sistema praneš vartotojui, kad jam uždrausta arba leidžiama patekti į patalpas? Žmogus geriausiai suvokia garsus ir kažką mirksi. Todėl galite duoti tam tikrą garso signalą, kad vartotojas atkreiptų dėmesį, ir mirksėti šviesos diodu. Pridėkime atitinkamus komponentus UserNotify:

Projektavimas sistemos lygiu. 1 dalis. Nuo idėjos iki sistemos

Sukūrėme savo sistemos architektūrą, bet kažkas joje negerai. Ką? Pažvelkime į jungčių pavadinimus. InBus и OutBus – ne visai įprasti vardai, kurie padėtų kūrėjui. Juos reikia pervadinti:

Projektavimas sistemos lygiu. 1 dalis. Nuo idėjos iki sistemos

Taigi, mes pažvelgėme į tai, kaip sistemų inžinerijos metodai taikomi grubiausiu aproksimavimu. Kyla klausimas: kam juos išvis naudoti? Sistema primityvi, atrodo, kad atliktas darbas yra nereikalingas. Galite iš karto parašyti kodą, sukurti duomenų bazę, rašyti užklausas ar lituoti. Problema ta, kad jei negalvojate apie sistemą ir nesuprantate, kaip jos komponentai yra sujungti vienas su kitu, tada sistemos komponentų integravimas užtruks ilgai ir bus gana skausmingas.

Pagrindinis šios dalies akcentas yra:

Sistemų inžinerijos metodų ir architektūros modeliavimo panaudojimas kuriant sistemas leidžia sumažinti komponentų integravimo kaštus ir pagerinti kuriamos sistemos kokybę.

Šaltinis: www.habr.com

Добавить комментарий