Estoy empezando en programación de software embebido usando un RTOS y, como ya soy un desarrollador de aplicaciones de escritorio, me seguía preguntando qué es eso de modelo encajado software usando diagramas UML, diagramas de actividad, diagramas de secuencia, casos de uso, etc..
¿Diseña software embebido usando UML, de la misma manera que aplicaciones de escritorio? ¿Es la mejor opción o hay uno mejor? ¿Puede dar algunos ejemplos?
¿Existe una herramienta específica que hace esto?
Cuando se dirige a un RTOS, que se suele tratar con una aplicación que tiene muchas tareas simultáneas que necesitan ser programados de manera óptima en el orden de cada uno de ellos para cumplir sus plazos de tiempo o compartir recursos de forma segura. El RTOS marco que usted elija implementa un programador de tareas, y su trabajo (por lo general) es escribir cada una de estas tareas con un cierto conjunto de propiedades (periodo, prioridad, etc) y, a continuación, entregar para el programador. Así que para la documentación, el enfoque que iban a ser para documentar cada una de las tareas de cuidado.
La mayoría de software embebido y, hasta donde yo sé, la mayoría de los RTOS no está escrito en un lenguaje orientado a objetos y por lo tanto no se pueden beneficiar de un montón de cosas que están orientados a que, como los diagramas de clases, por ejemplo.
Cuando la documentación de sus RTOS tareas sin embargo, cualquier diagrama que describe la tarea que bien podría ser un gran beneficio. Me imagino un diagrama de secuencia para cada tarea podría ser muy útil, por ejemplo. Junto con la que se puede especificar su duro requisitos como su periodo/frecuencia, de prioridad, de todos los recursos compartidos se puede usar, de suscripción preferente de los requisitos, etc. De valor también podría ser el documento de cómo haya configurado el RTOS y tal vez una máquina de estados de su algoritmo de programación.
Tomar cualquiera de este consejo, sin embargo te gusta, no he metido con OTRS cosas desde mis días de colegio, y nunca realmente "documentado" el trabajo.
No he diseñado nada de lo que es espacio calificado. Pero he trabajado para el Departamento de Defensa (DoD) subcontratista aeroespacial y muchos de mis diseños fueron de vuelo calificado. Requieren una gran cantidad de documentación en sus diseños y proporcionar los Datos de Descripciones de objetos (DIDs) que detalle exactamente lo que quieren ver.
Usted puede utilizar el DoD AYUDAR Búsqueda Rápida para ver todos los DIDs, para los documentos que pueden ser necesarios si el tipo de "software" en la "Palabra(s) En el Título" de campo y haga clic en Enviar. (Me resulta curioso que un DoD sitio arroja un certificado de advertencia de seguridad, pero te aseguro que es seguro).
Desde que preguntar específicamente acerca de un Documento de Diseño, aquí es el Diseño de Software Descripción (SDD). Ellos enfatizan el uso de las 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, que por supuesto le gustaría incluir.
Que método de modelado que usted elija, como otros han dicho, depende del diseño. Pero pensé que ver a un DID para el sector aeroespacial software puede ayudarle a escribir su Diseño, Documento, ya que su proyecto es el espacio relacionados.
El modelado es todo acerca de
saber qué aspecto es difícil y complejo en su aplicación,
encontrar una herramienta de modelado/lenguaje/abstracción/convenio/notación apropiada para ese aspecto
el diseño de que ese aspecto
Por lo tanto no hay herramienta de modelado/enfoque/etc es apropiada para todas las situaciones. Un satélite es probable que sea en tiempo real multitarea del sistema, probablemente con más de un procesador. Tarea diagramas de estructura, enfermedades de transmisión sexual, y los diagramas de secuencia son probablemente útil (sólo para nombrar unos pocos). Si el proyecto está hecho en C un diagrama de clases es menos likley ser útil (si es que resulta ser muy útil, la elección de C fue probablemente equivocada). Yo no soy muy amante de los escenarios de uso, y un satélite an-sich no tiene ningún usuario. Los casos de uso son las más apropiadas en una situación donde usted quiere discutir los requisitos de su sistema con un usuario no técnico. Si esa es la situación en la que están con un proyecto de satélites que algo ha ido mal.
No son en Tiempo Real de las extensiones de UML que fueron popularizadas por una compañía cuyo nombre se me escapa en este momento. Recuerdo haber hecho un papel en él hace varios años. Bruce Powell Douglass escribió un par de libros sobre el tema de modelado de sistemas embebidos usando UML, pero su compañía no es el que yo estoy pensando.
Que dijo, haciéndose eco de Wouter, no hay nada especial acerca de software embebido en sí. Escribo embedded software cada día, para un sistema que se ejecuta en Pentium clase de procesadores; UML es muy aplicable. También, recuerde que muchos de los aspectos de software de control se han añadido a UML a lo largo del tiempo: no es la sintaxis para especificar sincrónica o asincrónica eventos a lo largo de con el tiempo de respuesta en los Diagramas de Secuencia, de redes de Petri tipo de comportamiento se puede encontrar en los diagramas de Actividad, Diagramas gráficos de estado del modelo de comportamiento, incluso mejor que el Estado de Diagramas, etc.
OTOH, una gran cantidad de personas prefieren el modelo de software embebido utilizando Estructurado Diseño de flujo de datos y conceptos. Es todo sobre el tipo de sistema que se está diseñando y lo que mejor funciona.
I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
