Zdravo svima. Često primjenjujem principe sistemskog inženjeringa u svom radu i želio bih podijeliti ovaj pristup sa zajednicom.
Sistemski inženjering – bez standarda, ali jednostavno rečeno, to je proces razvoja sistema kao prilično apstraktnih komponenti, bez pozivanja na specifične uzorke uređaja. Tokom ovog procesa uspostavljaju se svojstva komponenti sistema i veze između njih. Dodatno, potrebno je da sistem bude konzistentan i optimalan i da sistem ispunjava zahtjeve. U ovom tutorijalu pokazat ću tehnike sistemskog inženjeringa koristeći primjer dizajniranja prilično jednostavnog sistema kontrole pristupa (ACS).
Formiranje početne arhitekture
Kada sistem, bez obzira na sve, tek počne da se razvija, pravougaonici sa strelicama se pojavljuju u našim glavama ili na papiru. Takvi pravougaonici su komponente sistemima. I strelice su veze između komponenti. I vrlo često nemamo vremena da sjedimo i razmišljamo o tome kako će sve komponente koje smo definirali funkcionirati jedna s drugom, i na kraju krenemo stvarati gomilu štaka, smišljajući suvišne dizajne.
Važno je zapamtiti da je sa stanovišta sistema i njegove arhitekture, komponenta prilično apstraktna stvar. Na primjer, ako naš sistem ima mikrokontroler, onda nam je na arhitektonskom nivou bitno samo da je mikrokontroler, a ne da je STM32, Arduino ili Milander. Štaviše, često nam uopšte nije jasno šta će tačno biti u sistemu, pa se obraćamo sistemskom inženjeringu da razvijemo zahteve za opremu, softver itd.
Za naš primjer sa ACS-om, pokušaćemo da formulišemo njegovu svrhu. To će nam pomoći da identifikujemo njegove komponente. Dakle, zadatak sistema kontrole pristupa je da omogući ograničenom krugu ljudi u prostoriju. To jest, to je pametna brava. Shodno tome, imamo prvu komponentu - neku vrstu uređaja koji zaključava i otključava vrata! Hajde da ga pozovemo Brava
Kako znamo da osoba može ući unutra? Ne želimo da stavimo čuvara i provjeravamo pasoše, zar ne? Dajmo ljudima posebne kartice sa RFID oznakama, na koje ćemo snimati jedinstvene ID-ove ili druge podatke koji nam omogućavaju da precizno identifikujemo osobu. Zatim će nam trebati neki uređaj koji može čitati ove oznake. Odlično, imamo još jednu komponentu, RFIDReader
Pogledajmo ponovo šta smo dobili. RFIDReader čita neke podatke, sistem kontrole pristupa nešto radi sa njima i na osnovu toga se nešto kontroliše Brava. Postavimo sljedeće pitanje - gdje pohraniti listu osoba sa pravima pristupa? Najbolji u bazi podataka. Stoga naš sistem mora biti u stanju da šalje zahtjeve i obrađuje odgovore iz baze podataka. Dakle, imamo još jednu komponentu - DBHandler. Dakle, dobili smo izuzetno apstraktan, ali dovoljan za početak, opis sistema. Razumijemo šta bi trebalo da radi i kako funkcioniše.
Umjesto komada papira, koristiću System Composer, specijalni alat za modeliranje sistemske arhitekture u okruženju Simulink, i kreirati 3 komponente. Gore sam opisao veze između ovih komponenti, pa hajde da ih odmah povežemo:
Proširivanje arhitekture
Pogledajmo naš dijagram. Čini se da je sve u redu, ali u stvarnosti nije. Pogledajte ovaj sistem iz ugla korisnika - korisnik donosi karticu čitaču i...? Kako korisnik zna da li mu je dozvoljen ili odbijen pristup? O tome ga je potrebno nekako obavijestiti! Stoga, dodajmo još jednu komponentu - obavještenje korisnika, UserNotify:
Sada idemo dolje na niži nivo apstrakcije. Pokušajmo malo detaljnije opisati neke komponente. Počnimo sa komponentom RFIDReader. U našem sistemu, ova komponenta je odgovorna za očitavanje RFID oznake. Njegov izlaz bi trebao sadržavati neke podatke (UID, korisnički podaci...). Ali čekajte, RFID, kao i NFC, je prvenstveno hardver, a ne softver! Stoga možemo pretpostaviti da zasebno imamo i sam RFID čip, koji prenosi „sirove“ podatke u neku vrstu pretprocesora. Dakle, imamo apstraktni komad hardvera koji može čitati RFID oznake i apstraktni softver koji može pretvoriti podatke u format koji nam je potreban. Pozovimo ih RFIDsenzor и RFIDParser respektivno. Kako to prikazati u System Composer-u? Možete ukloniti komponentu RFIDReader i umjesto njih stavite dvije komponente, ali bolje je to ne raditi, inače ćemo izgubiti čitljivost arhitekture. Umjesto toga, uđimo u RFIDReader i dodamo 2 nove komponente:
Odlično, sada idemo na obavještavanje korisnika. Kako će sistem obavijestiti korisnika da mu je zabranjen ili dozvoljen pristup prostorijama? Osoba najbolje percipira zvukove i nešto što trepće. Stoga možete izdati određeni zvučni signal tako da korisnik obrati pažnju i treperiti LED dioda. Dodajmo odgovarajuće komponente UserNotify:
Napravili smo arhitekturu našeg sistema, ali nešto nije u redu s njom. Šta? Pogledajmo imena veza. InBus и OutBus - ne sasvim normalna imena koja bi pomogla programeru. Treba ih preimenovati:
Dakle, pogledali smo kako se metode sistemskog inženjeringa primjenjuju u najgrubljem aproksimaciji. Postavlja se pitanje zašto ih uopće koristiti? Sistem je primitivan i čini se da je urađeni posao nepotreban. Možete odmah napisati kod, dizajnirati bazu podataka, pisati upite ili lemiti. Problem je u tome što ako ne razmislite o sistemu i ne shvatite kako su njegove komponente međusobno povezane, onda će integracija komponenti sistema trajati dugo i biti prilično bolna.
Glavni zaključak iz ovog dijela je:
Upotreba metoda sistemskog inženjeringa i modeliranja arhitekture u razvoju sistema omogućava smanjenje troškova integracije komponenti i poboljšanje kvaliteta razvijenog sistema.
izvor: www.habr.com