Sziasztok. Munkám során gyakran alkalmazom a rendszermérnöki elveket, és ezt a megközelítést szeretném megosztani a közösséggel.
Rendszertervezés - szabványok nélkül, de egyszerűen fogalmazva, ez egy rendszer fejlesztésének folyamata, mint meglehetősen absztrakt komponensek, anélkül, hogy konkrét eszközmintákra hivatkoznánk. Ennek során létrejön a rendszerelemek tulajdonságai és a köztük lévő kapcsolatok. Ezenkívül szükséges a rendszer konzisztenssé és optimálissá tétele, valamint az, hogy a rendszer megfeleljen a követelményeknek. Ebben az oktatóanyagban rendszermérnöki technikákat mutatok be egy meglehetősen egyszerű beléptetőrendszer (ACS) tervezésének példáján.
A kezdeti architektúra kialakítása
Amikor egy rendszer, bármi is legyen, éppen csak elkezd fejlődni, nyilakkal ellátott téglalapok jelennek meg a fejünkben vagy a papíron. Az ilyen téglalapok alkatrészek rendszerek. És a nyilak kapcsolat alkatrészek között. És nagyon gyakran nincs időnk ülni és gondolkodni azon, hogy az általunk meghatározott összetevők hogyan fognak működni egymással, és a végén elkezdünk egy csomó mankót létrehozni, és redundáns terveket készítünk.
Fontos megjegyezni, hogy a rendszer és architektúrája szempontjából egy komponens meglehetősen elvont dolog. Például, ha a mi rendszerünkben van mikrokontroller, akkor építészeti szinten nekünk csak az a fontos, hogy mikrokontroller legyen, és nem az, hogy STM32, Arduino vagy Milander legyen. Sőt, gyakran egyáltalán nem világos számunkra, hogy pontosan mi lesz a rendszerben, és rendszermérnökhöz fordulunk a berendezésekre, szoftverekre stb.
Az ACS-vel kapcsolatos példánkban megpróbáljuk megfogalmazni a célját. Ez segít az összetevők azonosításában. Tehát a beléptető rendszer feladata, hogy korlátozott számú embert engedjen be a helyiségbe. Vagyis ez egy intelligens zár. Következésképpen megvan az első alkatrész - valamiféle eszköz, amely zárja és kinyitja az ajtót! Hívjuk fel Ajtózár
Honnan tudhatjuk, hogy az ember bejuthat? Nem akarunk őrt börtönbe zárni és útleveleket ellenőrizni, ugye? Adjunk az embereknek speciális RFID címkés kártyákat, amelyekre egyedi azonosítókat vagy egyéb olyan adatokat rögzítünk, amelyek lehetővé teszik egy személy pontos azonosítását. Ezután szükségünk van egy olyan eszközre, amely képes olvasni ezeket a címkéket. Remek, van még egy komponensünk, RFIDReader
Nézzük újra, mit kaptunk. RFIDReader beolvas néhány adatot, a beléptető rendszer csinál vele valamit, és ez alapján vezérel valamit Ajtózár. Tegyük fel a következő kérdést – hol tároljuk a hozzáférési jogosultsággal rendelkező személyek listáját? A legjobb az adatbázisban. Ezért rendszerünknek képesnek kell lennie arra, hogy kéréseket küldjön és feldolgozza a válaszokat az adatbázisból. Tehát van még egy komponensünk - DBHandler. Tehát kaptunk egy rendkívül elvont, de kezdetnek elegendő leírást a rendszerről. Megértjük, hogy mit kell csinálnia és hogyan működik.
Egy darab papír helyett a System Composert, a Simulink környezetben a rendszerarchitektúrák modellezésére szolgáló speciális eszközt fogok használni, és 3 komponenst készítek. Fentebb leírtam ezen komponensek közötti kapcsolatokat, tehát azonnal kössük össze őket:
Az architektúra bővítése
Nézzük a diagramunkat. Úgy tűnik, hogy minden rendben van, de a valóságban nem. Nézze meg ezt a rendszert a felhasználó szemszögéből - a felhasználó hozza a kártyát az olvasóhoz és...? Honnan tudja a felhasználó, hogy engedélyezve van-e vagy megtagadva a hozzáférést? Erről valahogy értesíteni kell őt! Ezért adjunk hozzá még egy összetevőt - felhasználói értesítést, UserNotify:
Most menjünk le az absztrakció alacsonyabb szintjére. Próbáljunk meg néhány komponenst kicsit részletesebben leírni. Kezdjük az összetevővel RFIDReader. Rendszerünkben ez az összetevő felelős az RFID-címke kiolvasásáért. A kimenetének tartalmaznia kell néhány adatot (UID, felhasználói adatok...). De várjunk csak, az RFID az NFC-hez hasonlóan elsősorban hardver, nem szoftver! Feltételezhetjük tehát, hogy külön-külön megvan az RFID chip, amely „nyers” adatokat továbbít valamilyen előfeldolgozónak. Tehát van egy absztrakt hardverünk, amely képes olvasni az RFID-címkéket, és absztrakt szoftverünk, amely az adatokat a szükséges formátumba tudja konvertálni. Hívjuk fel őket RFID-érzékelő и RFIDParser illetőleg. Hogyan lehet ezt megjeleníteni a System Composerben? Eltávolíthat egy alkatrészt RFIDReader és tegyen helyette két komponenst, de jobb, ha ezt nem teszi meg, különben elveszítjük az architektúra olvashatóságát. Ehelyett menjünk be az RFIDReaderbe, és adjunk hozzá 2 új összetevőt:
Remek, most térjünk át a felhasználó értesítésére. Hogyan értesíti a rendszer a felhasználót, ha megtagadják vagy engedélyezik a belépést a helyiségbe? Az ember a hangokat és valami villogást érzékeli a legjobban. Ezért kiadhat egy bizonyos hangjelzést, hogy a felhasználó figyeljen, és villogjon a LED-en. Adjuk hozzá a megfelelő összetevőket UserNotify:
Megalkottuk a rendszerünk architektúráját, de valami nincs rendben vele. Mit? Nézzük a kapcsolatok neveit. A buszban и OutBus - nem egészen normális nevek, amelyek segítenék a fejlesztőt. Át kell nevezni őket:
Tehát megvizsgáltuk, hogyan alkalmazzák a rendszermérnöki módszereket a legdurvább közelítésben. Felmerül a kérdés: miért használjuk őket egyáltalán? A rendszer primitív, és úgy tűnik, hogy az elvégzett munka felesleges. Azonnal írhat kódot, tervezhet adatbázist, írhat lekérdezéseket vagy forraszthat. A probléma az, hogy ha nem gondolja végig a rendszert, és nem érti, hogyan kapcsolódnak egymáshoz az összetevői, akkor a rendszerelemek integrálása hosszú ideig tart és meglehetősen fájdalmas.
A fő kivonat ebből a részből a következő:
A rendszertervezési módszerek és az architektúra modellezés alkalmazása a rendszerfejlesztésben lehetővé teszi a komponensek integrálásának költségeinek csökkentését és a kifejlesztett rendszer minőségének javítását.
Forrás: will.com