Estoy comenzando en la programación de software incrustado usando un RTOS y, como ya soy desarrollador de aplicaciones de escritorio, me preguntaba cómo sería modelar software embebido utilizando diagramas UML, como Diagramas de actividad, Diagramas de secuencia, Casos de uso, etc.
¿El software integrado está diseñado con UML, de la misma manera que las aplicaciones de escritorio? ¿Es la mejor opción o hay una mejor? ¿Puedo tener algunos ejemplos?
¿Hay una herramienta específica que hace esto?
Hay extensiones en tiempo real de UML que fueron popularizadas por una compañía cuyo nombre se me escapa en este momento. Recuerdo haber hecho un trabajo sobre ello hace varios años. Bruce Powell Douglass escribió algunos libros sobre el tema del modelado de sistemas embebidos usando UML, pero no creo en su compañía.
Dicho esto, para hacernos eco de Wouter, no hay nada especial sobre el software incorporado en sí. Escribo software integrado todos los días para un sistema que se ejecuta en procesadores de la clase Pentium; UML es bastante aplicable. Además, recuerde que muchos aspectos del software de control se han agregado a UML a lo largo del tiempo: existe una sintaxis para especificar eventos síncronos o asíncronos junto con el tiempo de respuesta en los diagramas de secuencia. que los diagramas de estado pueden, etc.
OTOH, muchas personas prefieren modelar software integrado utilizando conceptos de diseño estructurado y flujo de datos. Se trata del tipo de sistema que estás diseñando y de lo que funciona mejor.
Al recurrir a un RTOS, generalmente estamos tratando con una aplicación que tiene muchas tareas simultáneas que deben programarse de manera óptima para que cada una de ellas cumpla sus plazos de entrega o comparta los recursos de forma segura. El marco RTOS que elija implementa un programador de tareas, y su trabajo (normalmente) es escribir estas tareas individuales con un determinado conjunto de propiedades (período, prioridad, etc.) y luego entregarlo al programador. Así que para la documentación, el enfoque que tomaría sería documentar cada tarea cuidadosamente.
La mayoría del software integrado y, por lo que sé, la mayoría de los RTOS no están escritos en un lenguaje orientado a objetos y, por lo tanto, no pueden beneficiarse de muchas cosas que están orientadas a diagramas de clase similares, por ejemplo.
Sin embargo, cuando documente sus tareas RTOS, cualquier diagrama que describa bien la tarea sería un gran beneficio. Me imagino que un diagrama de secuencia para cada tarea podría ser muy útil, por ejemplo. Junto con eso, puede especificar sus requisitos estrictos como su período / frecuencia, prioridad, cualquier recurso compartido que pueda usar, requisitos de prioridad, etc. También podría ser valioso documentar cómo ha configurado el RTOS y tal vez un estado. Máquina de su algoritmo de programación.
Sigue cualquiera de estos consejos que desees, no he jugado con cosas de RTOS desde mis días de universidad y nunca "documenté" el trabajo.
Se trata de modelar
saber qué aspecto es difícil y complejo en su aplicación,
encontrar una herramienta de modelado / lenguaje / abstracción / convención / notación apropiada para ese aspecto
diseñando ese aspecto
Por lo tanto, ninguna herramienta de modelado / enfoque / etc es apropiada para todas las situaciones. Es probable que un satélite sea un sistema multitarea en tiempo real, probablemente con más de un procesador. Los diagramas de estructura de tareas, las ETS y los diagramas de secuencia son probablemente útiles (solo para nombrar algunos). Si el proyecto se realiza en C, es menos probable que un diagrama de clase sea útil (si resulta ser muy útil, la elección de C probablemente fue incorrecta). No soy muy aficionado a los casos de uso, y un satélite que no tiene usuario. Los casos de uso son más apropiados en una situación en la que desea analizar los requisitos para su sistema con un usuario no técnico. Si esa es la situación en la que se encuentra con un proyecto satelital, algo salió mal.
No he diseñado nada que sea calificado para el espacio. Pero he trabajado para un subcontratista aeroespacial del Departamento de Defensa (DoD) y muchos de mis diseños fueron calificados para vuelo. Requieren una gran cantidad de documentación sobre sus diseños y proporcionan descripciones de elementos de datos (DID) que detallan exactamente lo que quieren ver.
Puede usar la
Como pregunta específicamente sobre un documento de diseño, aquí está el Descripción del diseño del software (SDD) DID. Destacan el uso de palabras para describir cada parte del diseño. Pero si el uso de UML, diagramas de estado, diagramas de flujo, pseudocódigo, etc. pueden mejorar la comprensión del diseño, entonces, por supuesto, les gustaría que lo incluyan.
El método de modelado que elija, como han dicho otros, depende de su diseño. Pero pensé que ver un DID para el software aeroespacial podría ayudarlo a escribir su documento de diseño, ya que su proyecto está relacionado con el espacio.