Diseño de software embebido

11

Estoy comenzando en la programación de software embebido usando un RTOS y, dado que ya soy desarrollador de aplicaciones de escritorio, me preguntaba 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 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 alguna herramienta específica que haga esto?

embedded software

— Cassio
fuente

8

No hay absolutamente nada específico sobre las aplicaciones integradas. Lo que es especial son las aplicaciones de recursos restringidos , las restricciones más comunes son las restricciones de tiempo, por ejemplo, los requisitos de tiempo real. Si nos cuenta más acerca de los requisitos para su solicitud, podríamos darle una respuesta específica.

— Wouter van Ooijen

3

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 el que las llamadas de bloqueo son una práctica aceptada.

— HikeOnPast

1

Tenga cuidado con los sistemas integrados de ingeniería excesiva. Ver también "The King's Toaster" ee.ryerson.ca/~elf/hack/ktoast.html

— drxzcl

2

@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, la aproximación 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 es un trabajo no trivial.

— Rocketmagnet

1

@Cassio: Estoy con Wouter en este caso. Debe analizar el problema usted mismo y luego mapear las partes importantes utilizando el sistema que considere apropiado. El problema con 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 que le atraigan el diseño de software integrado como el software empresarial.

— drxzcl

8

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

Dicho esto, para hacer eco a Wouter, no hay nada especial en el software integrado per se. Escribo software incorporado todos los días para un sistema que se ejecuta en procesadores de clase Pentium; UML es bastante aplicable. Además, recuerde que a lo largo del tiempo se han agregado muchos aspectos del software de control a UML: existe una sintaxis para especificar eventos síncronos o asíncronos junto con el tiempo de respuesta en diagramas de secuencia, el comportamiento del tipo de red de Petri se puede encontrar en diagramas de actividad, el comportamiento del modelo de gráficos de estado aún mejor que los diagramas de estado, etc.

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

— Lyndon
fuente

Gracias @lyndon Pero, ¿cómo modelas software embebido todos los días? ¿Crees que los diagramas de actividad, las máquinas de estado y los diagramas de secuencia serían suficientes? 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.

— Cassio

Las construcciones más frecuentes que veo son diagramas de estado / diagramas 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 las personas tienden a crear "objetos de Dios" masivos. Oh: la compañía en la que estaba pensando es Artisan Software. Este enlace puede ser informativo: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

— lyndon

5

Cuando recurrimos a un RTOS, usualmente tratamos con una aplicación que tiene muchas tareas concurrentes que deben programarse de manera óptima para que cada uno de ellos cumpla con sus plazos de entrega a tiempo o comparta recursos de manera segura. El marco RTOS que elija implementa un programador de tareas, y su trabajo (típicamente) es escribir estas tareas individuales con un cierto conjunto de propiedades (período, prioridad, etc.) y luego entregarlo 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, pueden no beneficiarse de muchas cosas que están orientadas hacia diagramas de clase similares, por ejemplo.

Sin embargo, al documentar 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, podría especificar sus requisitos estrictos, como su período / frecuencia, prioridad, cualquier recurso compartido que pueda usar, requisitos preventivos, 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 como quieras, no me he metido con cosas RTOS desde mis días de universidad, y nunca "documenté" realmente el trabajo.

— Jon L
fuente

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 él. Estoy usando RTEMS.

— Cassio

@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. Entonces puede comenzar a diseñar sus tareas a su alrededor.

— Jon L

Sí, todavía me estoy familiarizando con las funciones RTOS. Y gracias por el enfoque sugerido! ¡Lo haré! Y como dije antes, soy nuevo en el software embebido, no estoy realmente seguro de qué es necesario. Sería bueno tener una Arquitectura de Software Embebido o un Documento de Diseño. ¿Te gustaría uno de esos?

— Cassio

"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, utilizamos un RTOS simple (no preventivo) en C ++.

— Wouter van Ooijen

5

El modelado se trata

sabiendo 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 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, las ETS y los diagramas de secuencia son probablemente útiles (solo por nombrar algunos). Si el proyecto se realiza en C, es menos probable que un diagrama de clases sea útil (si resulta ser muy útil, la elección de C probablemente fue incorrecta). No soy muy aficionado a 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.

— Wouter van Ooijen
fuente

Gracias @Wouter. Has introducido un nuevo concepto para mí: Diagramas de estructura de tareas, ¡genial! Entonces, está en C. ¿Qué tendría para un documento con todos los requisitos, si no es UseCases?

— Cassio

En mi opinión, necesita una lista de requisitos identificables, más o menos de emisión única, aunque solo sea para basar sus casos de prueba. Para mí, UseCases es solo un método para llegar a esa lista. Un buen método, en algunos casos.

— Wouter van Ooijen

1

No he diseñado nada 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 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 curioso que un sitio del Departamento de Defensa arroje una advertencia de seguridad de certificado, pero te aseguro que es seguro).

Como usted pregunta específicamente sobre un documento de diseño, aquí está el DID de descripción de diseño de software (SDD). Enfatizan 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.

— Embedded.kyle
fuente