Ola a todos. Adoito aplico principios de enxeñería de sistemas no meu traballo e gustaríame compartir este enfoque coa comunidade.
Enxeñaría de sistemas - sen estándares, pero simplemente, é o proceso de desenvolvemento dun sistema como compoñentes bastante abstractos, sen referencia a mostras específicas de dispositivos. Durante este proceso, establécense as propiedades dos compoñentes do sistema e as conexións entre eles. Ademais, é necesario que o sistema sexa consistente e óptimo e que o sistema cumpra os requisitos. Neste tutorial mostrarei técnicas de enxeñería de sistemas usando o exemplo de deseñar un sistema de control de acceso (ACS) bastante sinxelo.
Formando a arquitectura inicial
Cando un sistema, pase o que pase, só comeza a desenvolverse, aparecen rectángulos con frechas na nosa cabeza ou no papel. Tales rectángulos son compoñentes sistemas. E as frechas son conexións entre compoñentes. E moitas veces non temos tempo para sentarnos a pensar como funcionarán todos os compoñentes que definimos entre si, e ao final comezamos a crear un montón de muletas, creando deseños redundantes.
É importante lembrar que desde o punto de vista do sistema e da súa arquitectura, un compoñente é algo máis ben abstracto. Por exemplo, se o noso sistema ten un microcontrolador, entón a nivel arquitectónico só é importante para nós que sexa un microcontrolador, e non que sexa STM32, Arduino ou Milander. Ademais, moitas veces non nos queda nada claro que será exactamente o sistema, e recorremos á enxeñería de sistemas para desenvolver os requisitos de equipos, software, etc.
Para o noso exemplo con ACS, tentaremos formular o seu propósito. Isto axudaranos a identificar os seus compoñentes. Entón, a tarefa do sistema de control de acceso é permitir que un círculo limitado de persoas entre na sala. É dicir, é unha pechadura intelixente. En consecuencia, temos o primeiro compoñente: algún tipo de dispositivo que bloquea e desbloquea a porta. Imos chamalo Pechadura da porta
Como sabemos que unha persoa pode entrar? Non queremos poñer un vixilante e revisar pasaportes, non si? Entreguemos á xente tarxetas especiais con etiquetas RFID, nas que rexistraremos ID únicos ou outros datos que nos permitan identificar con precisión a unha persoa. Entón, necesitaremos algún dispositivo que poida ler estas etiquetas. Xenial, temos un compoñente máis, Lector RFID
Vexamos de novo o que conseguimos. Lector RFID le algúns datos, o sistema de control de acceso fai algo con eles, e en base a iso contrólase algo Pechadura da porta. Fagamos a seguinte pregunta: onde almacenar a lista de persoas con dereitos de acceso? Mellor na base de datos. Polo tanto, o noso sistema debe ser capaz de enviar solicitudes e procesar respostas desde a base de datos. Entón temos un compoñente máis - DBHandler. Entón, recibimos unha descrición moi abstracta, pero suficiente para comezar, do sistema. Entendemos o que se supón que debe facer e como funciona.
En lugar dun anaco de papel, usarei System Composer, unha ferramenta especial para modelar arquitecturas de sistemas no ambiente Simulink, e crearei 3 compoñentes. Arriba describín as conexións entre estes compoñentes, así que conectámolos inmediatamente:
Ampliación da arquitectura
Vexamos o noso diagrama. Parece que todo está ben, pero en realidade non é así. Mira este sistema desde o punto de vista do usuario: o usuario trae a tarxeta ao lector e...? Como sabe un usuario se se lle permite ou se lle denega o acceso? É necesario avisalo dalgún xeito sobre isto! Polo tanto, imos engadir un compoñente máis: notificación ao usuario, UserNotify:
Agora imos baixar a un nivel inferior de abstracción. Tentemos describir algúns compoñentes cun pouco máis de detalle. Imos comezar co compoñente Lector RFID. No noso sistema, este compoñente encárgase de ler a etiqueta RFID. A súa saída debería conter algúns datos (UID, datos de usuario...). Pero espera, RFID, como NFC, é principalmente hardware, non software. Polo tanto, podemos supoñer que temos por separado o propio chip RFID, que transmite datos "en bruto" a algún tipo de preprocesador. Polo tanto, temos un hardware abstracto que pode ler etiquetas RFID e un software abstracto que pode converter datos no formato que necesitamos. Chamémoslles Sensor RFID и RFIDParser respectivamente. Como mostrar isto no System Composer? Pode eliminar un compoñente Lector RFID e poñer dous compoñentes no seu lugar, pero é mellor non facelo, se non perderemos a lexibilidade da arquitectura. En vez diso, imos entrar RFIDReader e engadir 2 novos compoñentes:
Xenial, agora pasemos a notificar ao usuario. Como notificará o sistema ao usuario que se lle denega ou se lle permite o acceso ao local? Unha persoa percibe mellor os sons e algo que parpadea. Polo tanto, pode emitir un determinado sinal de son para que o usuario preste atención e acechar o LED. Imos engadir os compoñentes axeitados a UserNotify:
Creamos a arquitectura do noso sistema, pero hai algo mal nela. Que? Vexamos os nomes das conexións. InBus и OutBus - nomes non moi normais que axudarían ao desenvolvedor. Deben ser renomeados:
Entón, observamos como se aplican os métodos de enxeñería de sistemas na aproximación máis aproximada. Xorde a pregunta: por que usalos? O sistema é primitivo, e parece que o traballo realizado é innecesario. Podes escribir código inmediatamente, deseñar unha base de datos, escribir consultas ou soldar. O problema é que se non pensas no sistema e entendes como os seus compoñentes están conectados entre si, entón a integración dos compoñentes do sistema levará moito tempo e será bastante dolorosa.
A principal conclusión desta parte é:
O uso de métodos de enxeñería de sistemas e modelado de arquitectura no desenvolvemento de sistemas permite reducir os custos de integración de compoñentes e mellorar a calidade do sistema desenvolvido.
Fonte: www.habr.com