Tere kõigile. Rakendan oma töös sageli süsteemitehnilisi põhimõtteid ja soovin seda lähenemist kogukonnaga jagada.
Süsteemitehnika – ilma standarditeta, kuid lihtsalt öeldes on see protsess, mille käigus arendatakse süsteem üsna abstraktsete komponentidena, ilma konkreetsetele seadmenäidistele viitamata. Selle protsessi käigus luuakse süsteemi komponentide omadused ja nendevahelised seosed. Lisaks on vaja muuta süsteem järjepidevaks ja optimaalseks ning et süsteem vastaks nõuetele. Selles õpetuses näitan süsteemide inseneritehnikaid üsna lihtsa juurdepääsukontrollisüsteemi (ACS) kavandamise näitel.
Algse arhitektuuri moodustamine
Kui süsteem, ükskõik mis, alles hakkab arenema, ilmuvad meie peadesse või paberile nooltega ristkülikud. Sellised ristkülikud on komponendid süsteemid. Ja nooled on ühendused komponentide vahel. Ja väga sageli pole meil aega istuda ja mõelda, kuidas kõik meie poolt määratletud komponendid omavahel töötavad, ja lõpuks hakkame looma hunnikut karkusid, pakkudes välja üleliigseid kujundusi.
Oluline on meeles pidada, et süsteemi ja selle arhitektuuri seisukohalt on komponent üsna abstraktne asi. Näiteks kui meie süsteemis on mikrokontroller, siis arhitektuuri tasandil on meile oluline vaid see, et tegemist oleks mikrokontrolleriga, mitte aga STM32, Arduino või Milanderiga. Pealegi pole sageli meile üldse selge, mis täpselt süsteemis olema hakkab, ning pöördume seadmete, tarkvara jms nõuete väljatöötamiseks süsteemitehnika poole.
ACS-i näite puhul proovime sõnastada selle eesmärgi. See aitab meil selle komponente tuvastada. Seega on läbipääsusüsteemi ülesanne lubada ruumi piiratud ringi inimesi. See tähendab, et see on nutikas lukk. Järelikult on meil esimene komponent - mingi seade, mis lukustab ja avab ukse! Helistame talle Ukselukk
Kuidas me teame, et inimene pääseb sisse? Me ei taha panna valvurit ja passe kontrollida, eks? Kingime inimestele spetsiaalsed RFID-märgistega kaardid, millele salvestame unikaalsed ID-d või muud andmed, mis võimaldavad isikut täpselt tuvastada. Seejärel vajame seadet, mis suudab neid silte lugeda. Suurepärane, meil on veel üks komponent, RFIDReader
Vaatame uuesti, mis meil on. RFIDReader loeb mingeid andmeid, läbipääsusüsteem teeb nendega midagi ja selle põhjal midagi juhitakse Ukselukk. Esitame järgmise küsimuse – kuhu salvestada juurdepääsuõigustega inimeste nimekiri? Parim andmebaasis. Seetõttu peab meie süsteem suutma andmebaasist päringuid saata ja vastuseid töödelda. Nii et meil on veel üks komponent - DBHandler. Niisiis oleme saanud äärmiselt abstraktse, kuid alustuseks piisava süsteemi kirjelduse. Me mõistame, mida see peaks tegema ja kuidas see toimib.
Paberitüki asemel kasutan Simulink keskkonnas süsteemiarhitektuuride modelleerimiseks spetsiaalset vahendit System Composer ja loon 3 komponenti. Ülalpool kirjeldasin nende komponentide vahelisi ühendusi, nii et ühendame need kohe:
Arhitektuuri laiendamine
Vaatame oma diagrammi. Tundub, et kõik on hästi, aga tegelikult ei ole. Vaata seda süsteemi kasutaja vaatevinklist – kasutaja toob kaardi lugejani ja...? Kuidas kasutaja teab, kas tal on juurdepääs lubatud või keelatud? Sellest on vaja teda kuidagi teavitada! Seetõttu lisame veel ühe komponendi – kasutajateatise, UserNotify:
Nüüd läheme madalamale abstraktsioonitasemele. Proovime mõnda komponenti veidi üksikasjalikumalt kirjeldada. Alustame komponendist RFIDReader. Meie süsteemis vastutab see komponent RFID-märgise lugemise eest. Selle väljund peaks sisaldama mõningaid andmeid (UID, kasutajaandmed...). Kuid oodake, RFID, nagu NFC, on peamiselt riistvara, mitte tarkvara! Seetõttu võime eeldada, et meil on eraldi RFID-kiip ise, mis edastab “toored” mingisugusele eelprotsessorile. Seega on meil abstraktne riistvara, mis suudab lugeda RFID-silte, ja abstraktne tarkvara, mis teisendab andmed meile vajalikku vormingusse. Helistame neile RFID-andur и RFIDParser vastavalt. Kuidas seda System Composeris kuvada? Saate komponendi eemaldada RFIDReader ja pange selle asemel kaks komponenti, kuid parem on seda mitte teha, vastasel juhul kaotame arhitektuuri loetavuse. Selle asemel läheme RFIDReaderi sisse ja lisame 2 uut komponenti:
Suurepärane, nüüd jätkame kasutaja teavitamisega. Kuidas teavitab süsteem kasutajat ruumidesse sisenemise keelamisest või lubamisest? Inimene tajub kõige paremini helisid ja midagi vilkuvat. Seetõttu saate väljastada teatud helisignaali, et kasutaja tähelepanu pööraks, ja LED-i vilkuma. Lisame sellele sobivad komponendid UserNotify:
Oleme loonud oma süsteemi arhitektuuri, kuid selles on midagi valesti. Mida? Vaatame ühenduste nimesid. InBus и OutBus - mitte päris normaalsed nimed, mis arendajat aitaksid. Need tuleb ümber nimetada:
Niisiis, uurisime, kuidas süsteemitehnilisi meetodeid rakendatakse kõige jämedamal lähendusel. Tekib küsimus: milleks neid üldse kasutada? Süsteem on primitiivne ja tundub, et tehtud töö on tarbetu. Kohe sai kirjutada koodi, kujundada andmebaasi, kirjutada päringuid või jootma. Probleem on selles, et kui te ei mõtle süsteemi läbi ega mõista, kuidas selle komponendid on omavahel ühendatud, siis süsteemi komponentide integreerimine võtab kaua aega ja on üsna valus.
Selle osa peamine väljavõte on:
Süsteemitehniliste meetodite ja arhitektuuri modelleerimise kasutamine süsteemiarenduses võimaldab vähendada komponentide integreerimise kulusid ja parandada arendatava süsteemi kvaliteeti.
Allikas: www.habr.com