Bok svima. U svom radu često primjenjujem principe sistemskog inženjeringa i želio bih podijeliti ovaj pristup sa zajednicom.
Inženjering sustava - bez standarda, ali jednostavno rečeno, to je proces razvoja sustava kao prilično apstraktnih komponenti, bez pozivanja na konkretne uzorke uređaja. Tijekom ovog procesa uspostavljaju se svojstva komponenti sustava i veze među njima. Dodatno, potrebno je sustav učiniti konzistentnim i optimalnim te da sustav zadovoljava zahtjeve. U ovom vodiču pokazat ću tehnike inženjeringa sustava koristeći primjer projektiranja prilično jednostavnog sustava kontrole pristupa (ACS).
Formiranje početne arhitekture
Kad se neki sustav, bez obzira kakav, tek počne razvijati, u našim glavama ili na papiru pojavljuju se pravokutnici sa strelicama. Takvi pravokutnici su компоненты sustava. I strelice jesu veza između komponenti. Vrlo često nemamo vremena sjediti i razmišljati o tome kako će sve komponente koje smo definirali raditi jedna s drugom, a na kraju počnemo stvarati hrpu štaka, smišljajući suvišne dizajne.
Važno je upamtiti da je sa stajališta sustava i njegove arhitekture komponenta prilično apstraktna stvar. Primjerice, ako naš sustav ima mikrokontroler, onda nam je na arhitektonskoj razini bitno samo da je to mikrokontroler, a ne da je STM32, Arduino ili Milander. Štoviše, često nam uopće nije jasno što će točno biti u sustavu, te se obraćamo inženjerstvu sustava za izradu zahtjeva za opremu, softver itd.
Za naš primjer s ACS-om, pokušat ćemo formulirati njegovu svrhu. To će nam pomoći u prepoznavanju njegovih komponenti. Dakle, zadatak sustava kontrole pristupa je omogućiti ograničenom krugu ljudi u prostoriju. Odnosno, radi se o pametnoj bravi. Dakle, imamo prvu komponentu - neku vrstu uređaja koji zaključava i otključava vrata! Nazovimo ga Ključanica
Kako znamo da osoba može ući unutra? Ne želimo postaviti čuvara i provjeravati putovnice, zar ne? Dajmo ljudima posebne kartice s RFID oznakama, na kojima ćemo bilježiti jedinstvene ID-ove ili druge podatke koji nam omogućuju točnu identifikaciju osobe. Zatim će nam trebati neki uređaj koji može čitati te oznake. Super, imamo još jednu komponentu, RFIDRader
Pogledajmo ponovno što imamo. RFIDRader očitava neke podatke, sustav kontrole pristupa s njima nešto radi i na temelju toga se nešto kontrolira Ključanica. Postavimo sljedeće pitanje - gdje pohraniti popis osoba s pravima pristupa? Najbolji u bazi podataka. Stoga naš sustav mora moći slati zahtjeve i obrađivati odgovore iz baze podataka. Dakle, imamo još jednu komponentu - DBHandler. Dakle, dobili smo krajnje apstraktan, ali za početak dovoljan opis sustava. Razumijemo što bi trebao raditi i kako funkcionira.
Umjesto komada papira koristit ću System Composer, poseban alat za modeliranje arhitektura sustava u Simulink okruženju, te izraditi 3 komponente. Gore sam opisao veze između ovih komponenti, pa ih odmah spojimo:
Širenje arhitekture
Pogledajmo naš dijagram. Čini se da je sve u redu, ali u stvarnosti nije. Gledajte ovaj sustav iz kuta korisnika - korisnik prinese karticu čitaču i...? Kako korisnik zna je li mu pristup dopušten ili odbijen? O tome ga je potrebno nekako obavijestiti! Stoga, dodajmo još jednu komponentu - obavijesti korisnika, UserNotify:
Sada se spustimo na nižu razinu apstrakcije. Pokušajmo malo detaljnije opisati neke komponente. Počnimo s komponentom RFIDRader. U našem sustavu ova komponenta je odgovorna za čitanje RFID oznake. Njegov izlaz trebao bi sadržavati neke podatke (UID, korisničke podatke...). Ali čekajte, RFID je, kao i NFC, prvenstveno hardver, a ne softver! Stoga možemo pretpostaviti da zasebno imamo sam RFID čip koji prenosi “sirove” podatke u neku vrstu predprocesora. Dakle, imamo apstraktni dio hardvera koji može čitati RFID oznake i apstraktni softver koji može pretvoriti podatke u format koji nam treba. Nazovimo ih RFIDSenzor и RFIDParser odnosno. Kako to prikazati u System Composeru? Možete ukloniti komponentu RFIDRader i umjesto toga staviti dvije komponente, ali bolje je ne činiti to, inače ćemo izgubiti čitljivost arhitekture. Umjesto toga, idemo u RFIDReader i dodamo 2 nove komponente:
Odlično, sad prijeđimo na obavještavanje korisnika. Kako će sustav obavijestiti korisnika da mu je zabranjen ili dopušten pristup prostorima? Osoba najbolje percipira zvukove i nešto što trepće. Stoga možete izdati određeni zvučni signal tako da korisnik obrati pozornost i trepće LED. Dodajmo odgovarajuće komponente UserNotify:
Stvorili smo arhitekturu našeg sustava, ali s njom nešto nije u redu. Što? Pogledajmo nazive veza. InBus и OutBus - ne baš normalna imena koja bi pomogla programeru. Treba ih preimenovati:
Dakle, pogledali smo kako se metode inženjeringa sustava primjenjuju u najgrubljoj aproksimaciji. Postavlja se pitanje: zašto ih uopće koristiti? Sustav je primitivan, a čini se da je učinjeni posao nepotreban. Možete odmah pisati kod, dizajnirati bazu podataka, pisati upite ili lemiti. Problem je u tome što ako ne razmislite o sustavu i ne razumijete kako su njegove komponente međusobno povezane, tada će integracija komponenti sustava trajati dugo i biti prilično bolna.
Glavni zaključak iz ovog dijela je:
Korištenje metoda sistemskog inženjeringa i modeliranja arhitekture u razvoju sustava omogućuje smanjenje troškova integracije komponenti i poboljšanje kvalitete razvijenog sustava.
Izvor: www.habr.com