Design på systemnivå. Del 1. Fra idé til system

Hei alle sammen. Jeg bruker ofte systemtekniske prinsipper i arbeidet mitt og vil gjerne dele denne tilnærmingen med samfunnet.

Systemteknikk - uten standarder, men enkelt sagt, er det prosessen med å utvikle et system som ganske abstrakte komponenter, uten referanse til spesifikke enhetsprøver. Under denne prosessen etableres egenskapene til systemkomponentene og forbindelsene mellom dem. I tillegg er det nødvendig å gjøre systemet konsistent og optimalt og at systemet oppfyller kravene. I denne opplæringen vil jeg vise systemteknikker ved å bruke eksempelet på å designe et ganske enkelt tilgangskontrollsystem (ACS).

Danner den opprinnelige arkitekturen

Når et system, uansett hva, så vidt begynner å utvikles, dukker det opp rektangler med piler i hodene våre eller på papir. Slike rektangler er komponenter systemer. Og pilene er forbindelse mellom komponenter. Og veldig ofte har vi ikke tid til å sitte og tenke på hvordan alle komponentene vi har definert vil fungere med hverandre, og til slutt begynner vi å lage en haug med krykker, og kommer opp med overflødige design.

Det er viktig å huske at fra systemets og dets arkitekturs synspunkt er en komponent en ganske abstrakt ting. For eksempel, hvis systemet vårt har en mikrokontroller, så er det på arkitektonisk nivå bare viktig for oss at det er en mikrokontroller, og ikke at det er STM32, Arduino eller Milander. Dessuten er det ofte ikke helt klart for oss hva som skal være i systemet, og vi henvender oss til systemteknikk for å utvikle krav til utstyr, programvare osv.

For vårt eksempel med ACS vil vi prøve å formulere formålet. Dette vil hjelpe oss med å identifisere komponentene. Så oppgaven til adgangskontrollsystemet er å tillate en begrenset krets av mennesker inn i rommet. Det vil si at det er en smart lås. Følgelig har vi den første komponenten - en slags enhet som låser og låser opp døren! La oss ringe ham Dørlås

Hvordan vet vi at en person kan komme inn? Vi ønsker ikke å sette en vakt i fengsel og sjekke pass, gjør vi? La oss gi folk spesielle kort med RFID-brikker, hvor vi vil registrere unike IDer eller andre data som lar oss identifisere en person nøyaktig. Da trenger vi en enhet som kan lese disse taggene. Flott, vi har en komponent til, RFID-leser

La oss se igjen på hva vi har. RFID-leser leser noen data, gjør adgangskontrollsystemet noe med det, og på bakgrunn av dette styres noe Dørlås. La oss stille følgende spørsmål: hvor skal du lagre listen over personer med tilgangsrettigheter? Best i databasen. Derfor må systemet vårt kunne sende forespørsler og behandle svar fra databasen. Så vi har en komponent til - DBHandler. Så vi har fått en ekstremt abstrakt, men tilstrekkelig til å begynne med, beskrivelse av systemet. Vi forstår hva den skal gjøre og hvordan den fungerer.

I stedet for et stykke papir vil jeg bruke System Composer, et spesialverktøy for modellering av systemarkitekturer i Simulink-miljøet, og lage 3 komponenter. Ovenfor beskrev jeg forbindelsene mellom disse komponentene, så la oss koble dem umiddelbart:

Design på systemnivå. Del 1. Fra idé til system

Utvide arkitekturen

La oss se på diagrammet vårt. Det ser ut til at alt er bra, men i virkeligheten er det ikke det. Se på dette systemet fra brukerens synspunkt - brukeren tar med kortet til leseren og...? Hvordan vet en bruker om de har tillatelse eller nektet tilgang? Det er nødvendig å på en eller annen måte varsle ham om dette! La oss derfor legge til en komponent til - brukervarsling, Brukervarsling:

Design på systemnivå. Del 1. Fra idé til system

La oss nå gå ned til et lavere abstraksjonsnivå. La oss prøve å beskrive noen komponenter litt mer detaljert. La oss starte med komponenten RFID-leser. I vårt system er denne komponenten ansvarlig for å lese RFID-taggen. Utdataene bør inneholde noen data (UID, brukerdata...). Men vent, RFID, som NFC, er først og fremst maskinvare, ikke programvare! Derfor kan vi anta at vi separat har selve RFID-brikken, som overfører "rå" data til en slags forprosessor. Så vi har en abstrakt maskinvare som kan lese RFID-tagger, og abstrakt programvare som kan konvertere data til formatet vi trenger. La oss ringe dem RFIDSensor и RFIDParser hhv. Hvordan viser jeg dette i System Composer? Du kan fjerne en komponent RFID-leser og sett inn to komponenter i stedet, men det er bedre å ikke gjøre dette, ellers vil vi miste lesbarheten til arkitekturen. La oss i stedet gå inn i RFIDReader og legge til 2 nye komponenter:

Design på systemnivå. Del 1. Fra idé til system

Flott, la oss nå gå videre til å varsle brukeren. Hvordan vil systemet varsle brukeren om at han nektes eller får tilgang til lokalene? En person oppfatter lyder og noe som blinker best. Derfor kan du gi et bestemt lydsignal slik at brukeren er oppmerksom, og blinker LED-en. La oss legge til de riktige komponentene til Brukervarsling:

Design på systemnivå. Del 1. Fra idé til system

Vi har laget arkitekturen til systemet vårt, men det er noe galt med det. Hva? La oss se på forbindelsesnavnene. InBus и OutBus - ikke helt normale navn som ville hjelpe utvikleren. De må gis nytt navn:

Design på systemnivå. Del 1. Fra idé til system

Så vi så på hvordan systemtekniske metoder brukes i den groveste tilnærmingen. Spørsmålet oppstår: hvorfor bruke dem i det hele tatt? Systemet er primitivt, og det ser ut til at arbeidet som er gjort er unødvendig. Du kan umiddelbart skrive kode, designe en database, skrive spørringer eller lodde. Problemet er at hvis du ikke tenker gjennom systemet og forstår hvordan komponentene er koblet til hverandre, vil integreringen av systemkomponenter ta lang tid og være ganske smertefull.

Den viktigste takeawayen fra denne delen er:

Bruk av systemtekniske metoder og arkitekturmodellering i systemutvikling gjør at man kan redusere kostnadene ved å integrere komponenter og forbedre kvaliteten på det utviklede systemet.

Kilde: www.habr.com

Legg til en kommentar