Pozdravljeni vsi skupaj. Pri svojem delu pogosto uporabljam načela sistemskega inženiringa in ta pristop bi rad delil s skupnostjo.
Sistemski inženiring - brez standardov, ampak preprosto povedano, je proces razvoja sistema kot dokaj abstraktnih komponent, brez sklicevanja na specifične vzorce naprav. Med tem procesom se vzpostavijo lastnosti komponent sistema in povezave med njimi. Dodatno je treba narediti sistem konsistenten in optimalen ter da sistem izpolnjuje zahteve. V tej vadnici bom prikazal tehnike sistemskega inženiringa na primeru načrtovanja dokaj preprostega sistema za nadzor dostopa (ACS).
Oblikovanje začetne arhitekture
Ko se sistem, ne glede na to, šele začne razvijati, se v naših glavah ali na papirju pojavijo pravokotniki s puščicami. Takšni pravokotniki so komponente sistemi. In puščice so povezave med komponentami. In zelo pogosto nimamo časa, da bi sedeli in razmišljali o tem, kako bodo vse komponente, ki smo jih definirali, delovale med seboj, in na koncu začnemo ustvarjati kup bergel in se domisliti odvečnih dizajnov.
Pomembno si je zapomniti, da je z vidika sistema in njegove arhitekture komponenta precej abstraktna stvar. Na primer, če ima naš sistem mikrokrmilnik, potem nam je na arhitekturni ravni pomembno le, da je mikrokrmilnik, ne pa, da je STM32, Arduino ali Milander. Poleg tega nam pogosto sploh ni jasno, kaj točno bo v sistemu, in se obrnemo na sistemski inženiring, da razvijemo zahteve za opremo, programsko opremo itd.
Za naš primer z ACS bomo poskušali oblikovati njegov namen. To nam bo pomagalo pri prepoznavanju njegovih komponent. Torej, naloga sistema za nadzor dostopa je, da v prostor spusti omejen krog ljudi. To pomeni, da je pametna ključavnica. Posledično imamo prvo komponento - nekakšno napravo, ki zaklepa in odklepa vrata! Pokličimo ga Ključavnica
Kako vemo, da lahko človek pride noter? Nočemo postaviti čuvaja in pregledovati potne liste, kajne? Dajmo ljudem posebne kartice z RFID oznakami, na katere bomo zapisali unikatne ID-je ali druge podatke, ki nam omogočajo natančno identifikacijo osebe. Potem bomo potrebovali napravo, ki bo lahko prebrala te oznake. Super, imamo še eno komponento, RFIDRader
Poglejmo še enkrat, kaj imamo. RFIDRader prebere neke podatke, sistem za nadzor dostopa nekaj naredi z njimi in na podlagi tega se nekaj nadzoruje Ključavnica. Zastavimo naslednje vprašanje - kam shraniti seznam oseb s pravicami dostopa? Najboljše v bazi podatkov. Zato mora biti naš sistem sposoben pošiljati zahteve in obdelovati odgovore iz baze podatkov. Torej imamo še eno komponento - DBHandler. Dobili smo torej izjemno abstrakten, a za začetek zadosten opis sistema. Razumemo, kaj naj bi naredil in kako deluje.
Namesto lista papirja bom uporabil System Composer, posebno orodje za modeliranje sistemskih arhitektur v okolju Simulink in izdelal 3 komponente. Zgoraj sem opisal povezave med temi komponentami, zato jih takoj povežimo:
Razširitev arhitekture
Poglejmo naš diagram. Zdi se, da je vse v redu, a v resnici ni. Poglejte ta sistem z vidika uporabnika - uporabnik prinese kartico do čitalnika in...? Kako uporabnik ve, ali mu je dostop dovoljen ali zavrnjen? O tem ga je treba nekako obvestiti! Zato dodajmo še eno komponento – obveščanje uporabnika, UserNotify:
Zdaj pa se spustimo na nižjo raven abstrakcije. Poskusimo nekatere komponente nekoliko podrobneje opisati. Začnimo s komponento RFIDRader. V našem sistemu je ta komponenta odgovorna za branje oznake RFID. Njegov izhod mora vsebovati nekaj podatkov (UID, uporabniški podatki ...). Toda počakajte, RFID je tako kot NFC predvsem strojna oprema, ne programska oprema! Zato lahko domnevamo, da imamo ločeno sam RFID čip, ki prenaša "surove" podatke v nekakšen predprocesor. Torej imamo abstrakten kos strojne opreme, ki lahko bere oznake RFID, in abstraktno programsko opremo, ki lahko pretvori podatke v obliko, ki jo potrebujemo. Pokličimo jih RFIDSenzor и Razčlenjevalnik RFIDP oz. Kako to prikazati v System Composer? Komponento lahko odstranite RFIDRader in namesto tega postavite dve komponenti, vendar je bolje, da tega ne storite, sicer bomo izgubili berljivost arhitekture. Namesto tega pojdimo v RFIDReader in dodamo 2 novi komponenti:
Odlično, zdaj pa preidimo na obveščanje uporabnika. Kako bo sistem obvestil uporabnika, da mu je dostop do prostorov onemogočen ali dovoljen? Človek najbolje zaznava zvoke in nekaj utripajočega. Zato lahko izdate določen zvočni signal, tako da je uporabnik pozoren, in utripa LED. Dodajmo ustrezne komponente UserNotify:
Ustvarili smo arhitekturo našega sistema, vendar je z njo nekaj narobe. Kaj? Poglejmo imena povezav. InBus и OutBus - ne povsem običajna imena, ki bi pomagala razvijalcu. Treba jih je preimenovati:
Tako smo pogledali, kako se metode sistemskega inženiringa uporabljajo v najbolj grobem približku. Postavlja se vprašanje: zakaj jih sploh uporabljati? Sistem je primitiven in zdi se, da je opravljeno delo nepotrebno. Lahko bi takoj napisali kodo, oblikovali bazo podatkov, napisali poizvedbe ali spajkali. Težava je v tem, da če ne razmišljate o sistemu in ne razumete, kako so njegove komponente med seboj povezane, potem bo integracija sistemskih komponent trajala dolgo in bo precej boleča.
Glavni zaključek tega dela je:
Uporaba metod sistemskega inženiringa in modeliranja arhitekture pri razvoju sistema omogoča zmanjšanje stroškov integracije komponent in izboljšanje kakovosti razvitega sistema.
Vir: www.habr.com