Kaixo guztioi. Sarritan sistemen ingeniaritza printzipioak aplikatzen ditut nire lanean eta ikuspegi hau komunitatearekin partekatu nahiko nuke.
Sistemen ingeniaritza - estandarrik gabe, baina besterik gabe, sistema bat osagai nahiko abstraktu gisa garatzeko prozesua da, gailu lagin zehatzei erreferentziarik egin gabe. Prozesu horretan, sistemaren osagaien propietateak eta haien arteko konexioak ezartzen dira. Gainera, beharrezkoa da sistema koherentea eta optimoa izatea eta sistemak baldintzak betetzen dituela. Tutorial honetan sistemen ingeniaritza teknikak erakutsiko ditut sarbide-kontrol sistema (ACS) nahiko sinple bat diseinatzeko adibidea erabiliz.
Hasierako arkitektura eratuz
Sistema bat, edozein dela ere, garatzen hasten denean, geziak dituzten laukizuzenak agertzen dira gure buruan edo paperean. Horrelako laukizuzenak dira osagaiak sistemak. Eta geziak dira konexio osagaien artean. Eta sarritan ez dugu esertzeko astirik definitu ditugun osagai guztiak nola funtzionatuko duten elkarren artean pentsatzeko, eta azkenean makulu mordoa sortzen hasten gara, diseinu soberantsuak ateratzen.
Garrantzitsua da gogoratzea sistemaren eta bere arkitekturaren ikuspuntutik osagai bat gauza nahiko abstraktua dela. Esaterako, gure sistemak mikrokontrolagailu bat badu, arkitektura mailan soilik garrantzitsua zaigu mikrokontrolagailua izatea, eta ez STM32, Arduino edo Milander izatea. Gainera, askotan ez dugu batere argi sisteman zer egongo den zehatz-mehatz, eta sistemen ingeniaritzara jotzen dugu ekipo, software eta abarretarako eskakizunak garatzeko.
ACSrekin dugun adibiderako, bere helburua formulatzen saiatuko gara. Horrek bere osagaiak identifikatzen lagunduko digu. Beraz, sarbide-kontrol sistemaren zeregina da jende zirkulu mugatu bat gelara sartzea. Hau da, sarraila adimenduna da. Ondorioz, lehen osagaia dugu: atea blokeatu eta desblokeatzen duen gailu mota bat! Dei diezaiogun Door Lock
Nola dakigu pertsona bat barrura sar daitekeela? Ez dugu zaintzailerik jarri eta pasaporteak egiaztatu nahi, ezta? Eman diezaiegun pertsonei RFID etiketa duten txartel bereziak, zeinetan pertsona bat zehaztasunez identifikatzea ahalbidetzen duten ID bakarrak edo beste datu batzuk erregistratuko ditugu. Orduan, etiketa hauek irakur ditzakeen gailuren bat beharko dugu. Bikaina, osagai bat gehiago dugu, RFID irakurgailua
Ikus dezagun berriro zer lortu dugun. RFID irakurgailua datu batzuk irakurtzen ditu, sarbide-kontrol-sistemak zerbait egiten du horrekin, eta horren arabera zerbait kontrolatzen da Door Lock. Egin dezagun galdera hau: non gorde sarbide-eskubideak dituzten pertsonen zerrenda? Datu-basean onena. Horregatik, gure sistemak datu-basetik eskaerak bidaltzeko eta erantzunak prozesatzeko gai izan behar du. Beraz, osagai bat gehiago dugu - DBHandler. Beraz, sistemaren deskribapen oso abstraktua, baina hasteko nahikoa, jaso dugu. Zer egin behar duen eta nola funtzionatzen duen ulertzen dugu.
Paper baten ordez, System Composer erabiliko dut, Simulink ingurunean sistema-arkitekturak modelatzeko tresna berezia, eta 3 osagai sortuko ditut. Goian osagai hauen arteko konexioak deskribatu ditut, beraz, berehala konekta ditzagun:
Arkitektura zabaltzea
Ikus dezagun gure diagrama. Badirudi dena ondo dagoela, baina errealitatean ez dago. Begiratu sistema hau erabiltzailearen ikuspuntutik -erabiltzaileak txartela irakurleari ekartzen dio eta...? Nola daki erabiltzaile batek sarbidea baimenduta edo ukatzen zaion? Beharrezkoa da horri buruz nolabait jakinaraztea! Beraz, gehi dezagun beste osagai bat - erabiltzaileen jakinarazpena, Erabiltzaileen jakinarazpena:
Orain goazen abstrakzio maila baxuago batera. Saia gaitezen osagai batzuk xehetasun pixka bat gehiago deskribatzen. Has gaitezen osagaiarekin RFID irakurgailua. Gure sisteman, osagai hau RFID etiketa irakurtzeaz arduratzen da. Bere irteerak datu batzuk eduki behar ditu (UID, erabiltzailearen datuak...). Baina itxaron, RFID, NFC bezala, batez ere hardwarea da, ez softwarea! Hori dela eta, pentsa dezakegu bereizita dugula RFID txipa bera, zeinak datu "gordinak" aurreprozesadore batera igortzen dituena. Beraz, RFID etiketak irakur ditzakeen hardware pieza abstraktu bat dugu, eta datuak behar dugun formatura bihur ditzakeen software abstraktua. Dei diezaiegun RFID sentsorea ΠΈ RFID Analizatzailea hurrenez hurren. Nola bistaratu hau System Composer-en? Osagai bat kendu dezakezu RFID irakurgailua eta bi osagai jarri ordez, baina hobe da hau ez egitea, bestela arkitekturaren irakurgarritasuna galduko dugu. Horren ordez, sar gaitezen RFIDReader barruan eta gehitu 2 osagai berri:
Primeran, orain pasa gaitezen erabiltzaileari jakinaraztera. Nola jakinaraziko dio sistemak erabiltzaileari lokalera sarbidea ukatu edo baimenduta dagoela? Pertsona batek soinuak eta keinu egiten duen zerbait hautematen ditu hobekien. Hori dela eta, soinu-seinale jakin bat eman dezakezu erabiltzaileak arreta jarri dezan eta LED-a keinu egin dezan. Gehi ditzagun osagai egokiak Erabiltzaileen jakinarazpena:
Gure sistemaren arkitektura sortu dugu, baina zerbait gaizki dago. Zer? Ikus ditzagun konexioen izenak. InBus ΠΈ OutBus - Garatzaileari lagunduko dioten izen arruntak ez dira. Izena aldatu behar zaie:
Beraz, sistemaren ingeniaritza metodoak hurbilketarik zakarrenean nola aplikatzen diren aztertu dugu. Galdera sortzen da: zergatik erabili? Sistema primitiboa da, eta badirudi egindako lana ez dela beharrezkoa. Berehala idatzi dezakezu kodea, datu-base bat diseinatu, kontsultak idatzi edo soldatu. Arazoa da sisteman pentsatzen ez baduzu eta bere osagaiak elkarren artean nola konektatzen diren ulertzen ez baduzu, sistemaren osagaien integrazioa denbora luzea izango dela eta nahiko mingarria izango da.
Zati honen ondorio nagusia hau da:
Sistemen ingeniaritza-metodoak eta arkitektura-modelizazioa sistemaren garapenean erabiltzeak osagaiak integratzearen kostuak murriztea eta garatutako sistemaren kalitatea hobetzea ahalbidetzen du.
Iturria: www.habr.com