Design na systémové úrovni. Část 1. Od nápadu k systému

Ahoj všichni. Ve své práci často aplikuji principy systémového inženýrství a rád bych se o tento přístup podělil s komunitou.

Systémové inženýrství – bez standardů, ale jednoduše řečeno, je to proces vývoje systému jako poměrně abstraktních komponent, bez odkazu na konkrétní vzorky zařízení. Během tohoto procesu se nastavují vlastnosti komponent systému a spojení mezi nimi. Kromě toho je nutné, aby byl systém konzistentní a optimální a aby systém vyhovoval požadavkům. V tomto tutoriálu ukážu techniky systémového inženýrství na příkladu návrhu poměrně jednoduchého systému řízení přístupu (ACS).

Formování původní architektury

Když se nějaký systém, bez ohledu na to, jen začne vyvíjet, objeví se nám v hlavě nebo na papíře obdélníky se šipkami. Takové obdélníky jsou komponenty systémy. A šipky jsou připojení mezi komponenty. A velmi často nemáme čas sedět a přemýšlet o tom, jak budou všechny komponenty, které jsme definovali, vzájemně spolupracovat, a nakonec začneme vytvářet spoustu berliček a vymýšlet nadbytečné návrhy.

Je důležité si uvědomit, že z pohledu systému a jeho architektury je komponenta spíše abstraktní věc. Pokud má například náš systém mikrokontrolér, pak na architektonické úrovni je pro nás důležité pouze to, že jde o mikrokontrolér, a ne, že jde o STM32, Arduino nebo Milander. Navíc nám často není vůbec jasné, co přesně v systému bude, a obracíme se na systémové inženýrství, abychom vyvinuli požadavky na zařízení, software atd.

Pro náš příklad s ACS se pokusíme formulovat jeho účel. To nám pomůže při identifikaci jeho součástí. Úkolem systému kontroly přístupu je tedy vpustit do místnosti omezený okruh lidí. To znamená, že je to chytrý zámek. V důsledku toho máme první komponent - nějaký druh zařízení, které zamyká a odemyká dveře! Zavolejme mu Zámek u dveří

Jak poznáme, že se člověk může dostat dovnitř? Nechceme dát stráž do vězení a kontrolovat pasy, že? Dejme lidem speciální karty s RFID štítky, na které budeme zaznamenávat unikátní ID nebo jiné údaje, které nám umožní přesně identifikovat osobu. Pak potřebujeme nějaké zařízení, které umí číst tyto značky. Skvělé, máme další součást, RFIDReader

Podívejme se znovu na to, co jsme dostali. RFIDReader přečte nějaká data, systém kontroly přístupu s nimi něco udělá a na základě toho se něco řídí Zámek u dveří. Položme si následující otázku – kam uložit seznam osob s přístupovými právy? Nejlepší v databázi. Náš systém proto musí být schopen odesílat požadavky a zpracovávat odpovědi z databáze. Takže máme ještě jednu složku - DBHandler. Obdrželi jsme tedy extrémně abstraktní, ale pro začátek dostačující popis systému. Chápeme, co to má dělat a jak to funguje.

Místo kusu papíru použiji System Composer, speciální nástroj pro modelování architektur systémů v prostředí Simulink a vytvořím 3 komponenty. Výše jsem popsal spojení mezi těmito komponentami, takže je okamžitě spojme:

Design na systémové úrovni. Část 1. Od nápadu k systému

Rozšíření architektury

Podívejme se na náš diagram. Zdá se, že je vše v pořádku, ale ve skutečnosti tomu tak není. Podívejte se na tento systém z pohledu uživatele - uživatel přinese kartu ke čtečce a...? Jak uživatel pozná, zda má povolen nebo odepřen přístup? Je potřeba ho na to nějak upozornit! Přidejme proto ještě jednu komponentu – upozornění uživatele, UserNotify:

Design na systémové úrovni. Část 1. Od nápadu k systému

Nyní pojďme dolů na nižší úroveň abstrakce. Zkusme si některé komponenty popsat trochu podrobněji. Začněme komponentou RFIDReader. V našem systému je tato komponenta zodpovědná za čtení RFID štítku. Jeho výstup by měl obsahovat nějaká data (UID, uživatelská data...). Ale počkat, RFID, stejně jako NFC, je především hardware, ne software! Můžeme tedy předpokládat, že máme samostatně samotný RFID čip, který přenáší „surová“ data do nějakého preprocesoru. Máme tedy abstraktní kus hardwaru, který dokáže číst štítky RFID, a abstraktní software, který dokáže převádět data do formátu, který potřebujeme. Zavolejme jim RFID senzor и RFIDParser respektive. Jak to zobrazit v System Composer? Komponentu můžete odebrat RFIDReader a místo toho vložte dvě komponenty, ale je lepší to nedělat, jinak ztratíme čitelnost architektury. Místo toho pojďme dovnitř RFIDReader a přidejte 2 nové komponenty:

Design na systémové úrovni. Část 1. Od nápadu k systému

Skvělé, nyní přejdeme k upozornění uživatele. Jak systém upozorní uživatele, že je mu odepřen nebo povolen přístup do areálu? Člověk nejlépe vnímá zvuky a něco blikajícího. Proto můžete vydat určitý zvukový signál, aby uživatel věnoval pozornost, a blikat LED. Přidáme vhodné komponenty UserNotify:

Design na systémové úrovni. Část 1. Od nápadu k systému

Vytvořili jsme architekturu našeho systému, ale něco na ní není v pořádku. Co? Podívejme se na názvy připojení. InBus и OutBus - ne úplně normální jména, která by vývojáři pomohla. Je třeba je přejmenovat:

Design na systémové úrovni. Část 1. Od nápadu k systému

Podívali jsme se tedy na to, jak jsou metody systémového inženýrství aplikovány v nejhrubší aproximaci. Nabízí se otázka: proč je vůbec používat? Systém je primitivní a zdá se, že vykonaná práce je zbytečná. Okamžitě můžete psát kód, navrhovat databázi, psát dotazy nebo pájet. Problém je v tom, že pokud systém nepromyslíte a nepochopíte, jak jsou jeho komponenty vzájemně propojeny, pak bude integrace komponent systému trvat dlouho a bude docela bolestivá.

Hlavní přínos z této části je:

Použití metod systémového inženýrství a modelování architektury při vývoji systému umožňuje snížit náklady na integraci komponent a zlepšit kvalitu vyvíjeného systému.

Zdroj: www.habr.com

Přidat komentář