Hola a tots. Sovint aplico els principis d'enginyeria de sistemes en el meu treball i m'agradaria compartir aquest enfocament amb la comunitat.
Enginyeria de sistemes: sense estàndards, però simplement, és el procés de desenvolupament d'un sistema com a components força abstractes, sense fer referència a mostres específiques de dispositius. Durant aquest procés, s'estableixen les propietats dels components del sistema i les connexions entre ells. A més, cal fer que el sistema sigui coherent i òptim i que el sistema compleixi els requisits. En aquest tutorial mostraré tècniques d'enginyeria de sistemes utilitzant l'exemple de disseny d'un sistema de control d'accés (ACS) bastant simple.
Formant l'arquitectura inicial
Quan un sistema, sigui el que passi, tot just comença a desenvolupar-se, apareixen rectangles amb fletxes al cap o al paper. Aquests rectangles són els components sistemes. I les fletxes ho són connexions entre components. I molt sovint no tenim temps per seure a pensar com funcionaran tots els components que hem definit entre si, i al final comencem a crear un munt de crosses, aconseguint dissenys redundants.
És important recordar que des del punt de vista del sistema i la seva arquitectura, un component és una cosa més aviat abstracta. Per exemple, si el nostre sistema té un microcontrolador, aleshores a nivell arquitectònic només ens importa que sigui un microcontrolador, i no que sigui STM32, Arduino o Milander. A més, sovint no ens queda gens clar què hi haurà exactament al sistema, i ens recorrem a l'enginyeria de sistemes per desenvolupar els requisits d'equips, programari, etc.
Per al nostre exemple amb ACS, intentarem formular el seu propòsit. Això ens ajudarà a identificar els seus components. Per tant, la tasca del sistema de control d'accés és permetre que un cercle limitat de persones entri a l'habitació. És a dir, és un pany intel·ligent. En conseqüència, tenim el primer component: algun tipus de dispositiu que tanca i desbloqueja la porta! Anem a cridar-lo Pany
Com sabem que una persona pot entrar? No volem posar un vigilant i comprovar els passaports, oi? Donem a la gent targetes especials amb etiquetes RFID, en les quals registrarem identificacions úniques o altres dades que ens permetin identificar amb precisió una persona. Aleshores, necessitarem algun dispositiu que pugui llegir aquestes etiquetes. Genial, tenim un component més, Lector RFID
Mirem de nou el que tenim. Lector RFID llegeix algunes dades, el sistema de control d'accés fa alguna cosa amb elles, i sobre la base d'això es controla alguna cosa Pany. Fem la següent pregunta: on emmagatzemar la llista de persones amb drets d'accés? El millor de la base de dades. Per tant, el nostre sistema ha de ser capaç d'enviar peticions i processar respostes des de la base de dades. Així que tenim un component més: DBHandler. Així doncs, hem rebut una descripció extremadament abstracta, però suficient per començar, del sistema. Entenem què ha de fer i com funciona.
En lloc d'un tros de paper, utilitzaré System Composer, una eina especial per modelar arquitectures de sistemes a l'entorn Simulink, i crearé 3 components. A dalt he descrit les connexions entre aquests components, així que connectem-los immediatament:
Ampliació de l'arquitectura
Mirem el nostre diagrama. Sembla que tot està bé, però en realitat no ho és. Mireu aquest sistema des del punt de vista de l'usuari: l'usuari porta la targeta al lector i...? Com sap un usuari si se li permet o se li denega l'accés? Cal avisar-lo d'alguna manera! Per tant, afegim un component més: notificació d'usuari, UserNotify:
Ara baixem a un nivell inferior d'abstracció. Intentem descriure alguns components amb una mica més de detall. Comencem pel component Lector RFID. Al nostre sistema, aquest component s'encarrega de llegir l'etiqueta RFID. La seva sortida hauria de contenir algunes dades (UID, dades d'usuari...). Però espera, RFID, com NFC, és principalment maquinari, no programari! Per tant, podem suposar que tenim per separat el propi xip RFID, que transmet dades "crues" a algun tipus de preprocessador. Per tant, tenim un maquinari abstracte que pot llegir etiquetes RFID i un programari abstracte que pot convertir les dades al format que necessitem. Anem a cridar-los Sensor RFID и RFIDParser respectivament. Com es mostra això a System Composer? Podeu eliminar un component Lector RFID i poseu-hi dos components, però és millor no fer-ho, sinó perdrem la llegibilitat de l'arquitectura. En canvi, entrem a RFIDReader i afegim 2 components nous:
Genial, ara passem a notificar a l'usuari. Com notificarà el sistema a l'usuari que se li denega o li permet l'accés al local? Una persona percep millor els sons i alguna cosa que parpelleja. Per tant, podeu emetre un senyal de so determinat perquè l'usuari presti atenció i parpellejar el LED. Afegim els components adequats a UserNotify:
Hem creat l'arquitectura del nostre sistema, però hi ha alguna cosa malament. Què? Vegem els noms de les connexions. InBus и OutBus - noms no gaire normals que ajudin al desenvolupador. S'han de canviar el nom:
Així doncs, vam analitzar com s'apliquen els mètodes d'enginyeria de sistemes amb l'aproximació més aproximada. Sorgeix la pregunta: per què utilitzar-los? El sistema és primitiu, i sembla que la feina feta és innecessària. Podeu escriure codi immediatament, dissenyar una base de dades, escriure consultes o soldar. El problema és que si no penseu en el sistema i enteneu com els seus components estan connectats entre si, la integració dels components del sistema trigarà molt de temps i serà força dolorosa.
El principal aspecte d'aquesta part és:
L'ús de mètodes d'enginyeria de sistemes i modelització d'arquitectures en el desenvolupament de sistemes permet reduir els costos d'integració de components i millorar la qualitat del sistema desenvolupat.
Font: www.habr.com