Diseño de software integrado

Me estoy iniciando en la programación de software embebido usando un RTOS y, como ya soy desarrollador de aplicaciones de escritorio, no dejaba de preguntarme cómo es modelar software embebido usando diagramas UML, como Diagramas de Actividad, Diagramas de Secuencia, Casos de Uso, etc.

¿El software integrado está diseñado usando UML, de la misma manera que lo hacen las aplicaciones de escritorio? ¿Es la mejor opción o hay alguna mejor? ¿Puedo tener algunos ejemplos?

¿Hay alguna herramienta específica que haga esto?

No hay absolutamente nada específico acerca de las aplicaciones integradas. Lo que es especial son las aplicaciones con recursos restringidos , las más comunes de tales restricciones son las restricciones de tiempo, por ejemplo, los requisitos estrictos de tiempo real. Si nos dice más sobre los requisitos para su aplicación, es posible que podamos darle una respuesta específica.
Estoy totalmente de acuerdo con los comentarios de @Wouter sobre las aplicaciones con recursos limitados, pero creo que hay matices de diseño específicos asociados con el uso de un RTOS frente a un entorno de desarrollo de escritorio programado en software donde el bloqueo de llamadas es una práctica aceptada.
Gracias @WoutervanOoijen y @DeanB. Estaré participando en el desarrollo del software embebido para un satélite universitario. Y como recién estoy comenzando en este campo, quería saber cómo es modelar un software que no está orientado a objetos (es decir, C en este caso) y también su arquitectura (estoy acostumbrado a los diagramas de bloques TAM - Modelado de Arquitectura Técnica, de SAP). ¿Es UML apropiado, ya que es un estándar orientado a objetos?
Tenga cuidado con los sistemas integrados de ingeniería excesiva. Consulte también "La tostadora del rey" ee.ryerson.ca/~elf/hack/ktoast.html
@drxzcl - No estoy de acuerdo. En primer lugar, no creo que pueda tener demasiado cuidado al diseñar software calificado para el espacio . En segundo lugar, el acercamiento del Ingeniero a la Tostadora del Rey es la razón por la que se quema tanto pan. La mayoría de las tostadoras son demasiado simples para lo que en realidad no es un trabajo trivial.
@Rocketmagnet: Debo admitir que, en parte, solo esperaba una buena razón para compartir la historia de la tostadora. Estoy de acuerdo en que escribir software integrado requiere cuidado, pero en mi experiencia es un tipo de cuidado bastante diferente al que se necesita para el software empresarial. No estoy seguro, por ejemplo, UML es el adecuado también para el trabajo aquí.
@drxzcl Gracias por tu respuesta. ¿Puede compartir qué tendría para la herramienta en esta situación, si no es UML?
@Cassio: Estoy con Wouter en esto. Tienes que analizar el problema tú mismo y luego mapear las partes importantes usando cualquier sistema que creas apropiado. El problema de elegir una representación antes de analizar el problema es que te quedas atascado viendo el problema de cierta manera. UML es una representación que tiene sus raíces en el software empresarial, y no desea dejarse atraer por el diseño de software integrado como el software empresarial.
@Cassio: software empresarial, habitualmente define una gran cantidad de capas de abstracción internas. Esto es probablemente algo bueno para esa tarea, ya que anticipa cambios en los requisitos y permite que una gran cantidad de programadores relativamente poco sofisticados trabajen en la misma pieza de software al mismo tiempo con una sobrecarga de comunicaciones relativamente baja. Sin embargo, en un entorno en el que cada puntero utiliza una palabra de su preciada memoria de 32 KB y cada llamada de función consume su pila, las cosas son diferentes. UML como representación se enfoca en esas abstracciones internas, atrayéndote a esa mentalidad.

Respuestas (4)

Hay extensiones en tiempo real para UML que fueron popularizadas por una empresa cuyo nombre se me escapa en este momento. Recuerdo haber hecho un artículo sobre eso hace varios años. Bruce Powell Douglass escribió algunos libros sobre el tema del modelado de sistemas integrados mediante UML, pero su empresa no es en la que estoy pensando.

Dicho esto, para repetir Wouter, no hay nada especial en el software embebido per se. Escribo software integrado todos los días para un sistema que se ejecuta en procesadores de 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, el comportamiento del tipo de red de Petri se puede encontrar en los diagramas de actividad, el comportamiento del modelo Statecharts es aún mejor que los diagramas de estado, etc.

OTOH, mucha gente prefiere modelar software integrado utilizando conceptos de diseño estructurado y flujo de datos. Se trata del tipo de sistema que está diseñando y qué funciona mejor.

Gracias @lyndon. Pero, ¿cómo se modela el software integrado todos los días? ¿Crees que los Diagramas de Actividad, las Máquinas de Estado y los Diagramas de Secuencia harían el truco? De hecho, estoy buscando el concepto de qué diseñar, luego cuáles son los esquemas que se deben hacer para insertarlos en el documento de diseño, si hay uno para sistemas integrados.
Las construcciones más frecuentes que veo son diagramas de estado/gráficos de estado y diagramas de secuencia para el uso diario. Sinceramente, creo que podríamos sacar más provecho de los diagramas de clase, pero creo que la gente tiene una tendencia a crear "objetos divinos" masivos. Oh: la empresa en la que estaba pensando es Artisan Software. Este enlace puede ser informativo: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

Cuando recurrimos a un RTOS, generalmente nos enfrentamos a una aplicación que tiene muchas tareas simultáneas que deben programarse de manera óptima para que cada una de ellas cumpla con sus plazos a tiempo o comparta recursos de manera segura. El marco RTOS que elija implementa un programador de tareas y su trabajo (por lo general) es escribir estas tareas individuales con un determinado conjunto de propiedades (período, prioridad, etc.) y luego entregárselas al programador. Entonces, para la documentación, el enfoque que tomaría sería documentar cada tarea cuidadosamente.

La mayoría del software integrado y, hasta donde yo sé, la mayoría de los RTOS no están escritos en un lenguaje orientado a objetos y, por lo tanto, es posible que no se beneficien de muchas cosas que están orientadas a eso, como los diagramas de clase, por ejemplo.

Sin embargo, al documentar sus tareas de 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 configuró el RTOS y tal vez un estado- máquina de su algoritmo de programación.

Tome cualquiera de estos consejos como quiera, no me he metido con las cosas de RTOS desde mis días de universidad, y nunca "documenté" realmente el trabajo.

Gracias @JonL. Entonces, para tener un buen documento de diseño, ¿solo necesitaría diseñar las tareas involucradas en mi aplicación? Además, no estoy muy familiarizado con un algoritmo de programación, nunca tuve que lidiar con eso. Estoy usando RTEMS.
@Cassio, no te estoy diciendo que hagas una cosa u otra, eso depende de ti. Solo trata de hacer lo que sea necesario. Si no está familiarizado con su RTOS, creo que comenzar con él primero y cómo se supone que debe usarlo sería un buen lugar para comenzar. Luego puede comenzar a diseñar sus tareas a su alrededor.
Sí, todavía me estoy familiarizando con las características de RTOS. ¡Y gracias por el enfoque sugerido! ¡Lo haré! Y como dije antes, soy nuevo en el software integrado, no estoy muy seguro de lo que es necesario. Sería bueno tener una arquitectura de software integrada o un documento de diseño. ¿Tendrías uno de esos?
"la mayoría de los RTOS no están escritos en un lenguaje orientado a objetos" De hecho. Pero para un curso de modelado e implementación en tiempo real, usamos un RTOS simple (no preventivo) en C++.

Modelar se trata de

  • 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/enfoque/etc. de modelado es apropiado 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, STD y diagramas de secuencia probablemente sean útiles (solo por nombrar algunos). Si el proyecto se realiza en C, es menos probable que un diagrama de clases sea útil (si resulta muy útil, la elección de C probablemente fue incorrecta). No soy muy aficionado a los UseCases, y un satélite an-sich no tiene usuario. Los casos de uso son más apropiados en una situación en la que desea analizar los requisitos de 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.

Gracias @Wouter. Has introducido un nuevo concepto para mí: diagramas de estructura de tareas, ¡genial! Entonces, está en C. ¿Qué tendrías para un documento con todos los requisitos, sino UseCases?
En mi opinión, necesita una lista de requisitos identificables, más o menos de uso único, aunque solo sea para basar sus casos de prueba. Para mí, los UseCases son solo un método para llegar a esa lista. Un buen método, en algunos casos.

No he diseñado nada que esté calificado para el espacio. Pero trabajé para un subcontratista aeroespacial del Departamento de Defensa (DoD) y muchos de mis diseños estaban calificados para el vuelo. Requieren mucha documentación sobre sus diseños y proporcionan descripciones de elementos de datos (DID) que detallan exactamente lo que quieren ver.

Puede usar la búsqueda rápida de DoD ASSIST para ver todos los DID de los documentos que pueden ser necesarios si escribe "software" en el campo "Palabra(s) en el título" y hace clic en Enviar. (Me parece divertido que un sitio del Departamento de Defensa arroje una advertencia de seguridad de certificado, pero les aseguro que es seguro).

Dado que pregunta específicamente sobre un documento de diseño, aquí está el DID de descripción de diseño de software (SDD). 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., puede mejorar la comprensión del diseño, entonces, por supuesto, les gustaría que lo incluyera.

El método de modelado que elija, como han dicho otros, depende de su diseño. Pero pensé que ver un DID para software aeroespacial podría ayudarlo a escribir su documento de diseño ya que su proyecto está relacionado con el espacio.

Diseño de software integrado
RespuestasAquíPolítica de privacidad1y, 0v