Projetando software incorporado

11

Estou iniciando na programação de software embarcado usando um RTOS e, como já sou desenvolvedor de aplicativos de desktop, fiquei imaginando como é modelar software embarcado usando diagramas UML, como Diagramas de Atividades, Diagramas de Sequência, Casos de Uso etc.

O software incorporado é projetado usando UML, da mesma forma que os aplicativos de desktop? É a melhor opção ou existe uma melhor? Posso ter alguns exemplos?

Existe uma ferramenta específica que faz isso?

embedded software

— Cássio
fonte

8

Não há absolutamente nada específico sobre aplicativos incorporados. O que é especial são os aplicativos restritos a recursos , o mais comum dessas restrições são as restrições de tempo, por exemplo, requisitos rígidos em tempo real. Se você nos contar mais sobre os requisitos para sua inscrição, poderemos dar uma resposta específica.

— Wouter van Ooijen

3

Concordo totalmente com os comentários de @ Wouter sobre aplicativos com recursos limitados, mas acredito que existem nuances de design específicas associadas ao uso de um RTOS versus um ambiente de desenvolvimento de área de trabalho com agendamento suave, onde o bloqueio de chamadas é uma prática aceita.

— HikeOnPast

1

Cuidado com os sistemas embarcados de superengenharia. Veja também "A Torradeira do Rei" ee.ryerson.ca/~elf/hack/ktoast.html

— drxzcl

2

@drxzcl - Discordo. Em primeiro lugar, não acho que você possa tomar muito cuidado ao projetar software qualificado para o espaço . Em segundo lugar, a abordagem do engenheiro à torradeira do rei é a razão pela qual tanto pão é queimado. A maioria das torradeiras é muito simples para o que é realmente um trabalho não trivial.

— Rocketmagnet

1

@ Cassio: Eu estou com Wouter neste. Você precisa analisar o problema e mapear as partes importantes usando o sistema que achar apropriado. O problema com a escolha de uma representação antes de analisá-lo é que você fica parado vendo o problema de uma certa maneira. UML é uma representação que tem suas raízes no software corporativo, e você não deseja ser atraído para o design de software incorporado, como software corporativo.

— Drxzcl 30/07/12

8

Existem extensões em tempo real da UML que foram popularizadas por uma empresa cujo nome me escapa no momento. Lembro-me de escrever um artigo sobre isso há vários anos. Bruce Powell Douglass escreveu alguns livros sobre modelagem de sistemas embarcados usando UML, mas não estou pensando em sua empresa.

Dito isto, para ecoar Wouter, não há nada de especial em software incorporado em si. Eu escrevo software incorporado todos os dias para um sistema que roda em processadores da classe Pentium; UML é bastante aplicável. Além disso, lembre-se de que muitos aspectos do software de controle foram adicionados à UML ao longo do tempo: existe uma sintaxe para especificar eventos síncronos ou assíncronos, juntamente com o tempo de resposta nos Diagramas de Sequência, o comportamento do tipo de rede Petri pode ser encontrado em Diagramas de Atividades, comportamento do modelo Statecharts ainda melhor que os Diagramas de Estado podem, etc.

OTOH, muitas pessoas preferem modelar software incorporado usando os conceitos de Projeto Estruturado e Fluxo de Dados. É tudo sobre o tipo de sistema que você está projetando e o que funciona melhor.

— Lyndon
fonte

Obrigado @lyndon. Mas como você modela o software incorporado todos os dias? Você acha que os diagramas de atividades, as máquinas de estados e os diagramas de sequência serviriam para o problema? Na verdade, estou procurando o conceito do que projetar e, em seguida, quais são os esquemas a serem feitos para serem inseridos no Documento de Design, se houver algum para sistemas embarcados.

— Cassio

As construções mais frequentes que eu vejo são diagramas de estado / gráficos de estados e diagramas de sequência para o uso diário. Sinceramente, acho que poderíamos usar mais os diagramas de classe, mas acho que as pessoas tendem a criar "objetos divinos" maciços. Ah: a empresa em que eu estava pensando é a Artisan Software. Este link pode ser informativo: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

— lyndon

5

Ao migrar para um RTOS, geralmente lidamos com um aplicativo que possui muitas tarefas simultâneas que precisam ser agendadas de maneira ideal para que cada um cumpra seus prazos no prazo ou compartilhe recursos com segurança. A estrutura RTOS que você escolhe implementa um agendador de tarefas e seu trabalho (normalmente) é gravar essas tarefas individuais com um determinado conjunto de propriedades (período, prioridade, etc.) e depois entregá-lo ao agendador. Portanto, para a documentação, a abordagem que eu adotaria seria documentar cada tarefa cuidadosamente.

A maioria dos softwares incorporados e, até onde eu sei, a maioria dos RTOS não são escritos em uma linguagem orientada a objetos e, portanto, podem não se beneficiar de muitas coisas voltadas para isso, como diagramas de classes, por exemplo.

Ao documentar suas tarefas RTOS, no entanto, qualquer diagrama que descreva bem a tarefa seria um grande benefício. Eu imagino que um diagrama de sequência para cada tarefa possa ser muito útil, por exemplo. Junto com isso, você pode especificar seus requisitos rígidos, como período / frequência, prioridade, quaisquer recursos compartilhados que ele possa usar, requisitos de preferência, etc. Também vale a pena documentar como você configurou o RTOS e talvez um máquina de seu algoritmo de agendamento.

Aceite qualquer um desses conselhos da maneira que quiser, não mexo nas coisas do RTOS desde os meus dias de faculdade e nunca realmente "documentei" o trabalho.

— Jon L
fonte

Obrigado @JonL. Então, para ter um bom Documento de Design, eu precisaria apenas projetar as tarefas envolvidas no meu aplicativo? Além disso, não estou muito familiarizado com um algoritmo de agendamento, nunca preciso lidar com isso. Estou usando RTEMS.

— Cassio

@ Cassio, não estou dizendo para você fazer uma coisa ou outra, isso depende muito de você. Apenas tente fazer o que é necessário. Se você não está familiarizado com o seu RTOS, acho que apenas começar com ele primeiro e como você deve usá-lo seria um bom lugar para começar. Então você pode começar a projetar suas tarefas em torno dele.

— 31812 Jon L

Sim, ainda estou me familiarizando com os recursos do RTOS. E obrigado pela abordagem sugerida! Vai fazer isso! E como eu disse antes, sou novo em software incorporado, não tenho muita certeza do que é necessário. Seria bom ter uma arquitetura de software incorporado ou um documento de design. Você teria um desses?

— Cassio

"a maioria dos RTOS não é escrita em uma linguagem orientada a objetos". Mas, para um curso de modelagem e implementação em tempo real, usamos um RTOS simples (não preventivo) em C ++.

— Wouter van Ooijen

5

Modelagem tem tudo a ver

sabendo qual aspecto é difícil e complexo em sua aplicação,
encontrar uma ferramenta de modelagem / linguagem / abstração / convenção / notação apropriada para esse aspecto
projetando que esse aspecto

Portanto, nenhuma ferramenta / abordagem de modelagem / etc é apropriada para todas as situações. Um satélite provavelmente será um sistema multitarefa em tempo real, provavelmente com mais de um processador. Diagramas de estrutura de tarefas, DSTs e diagramas de sequência são provavelmente úteis (apenas para citar alguns). Se o projeto é feito em C, um diagrama de classes é menos provável que seja útil (se for muito útil, a escolha para C provavelmente está errada). Não gosto muito de UseCases, e um satélite an-sich não tem usuário. Os casos de uso são mais apropriados em uma situação em que você deseja discutir os requisitos do seu sistema com um usuário não técnico. Se essa é a situação em que você está em um projeto de satélite, algo deu errado.

— Wouter van Ooijen
fonte

Obrigado @Wouter. Você me apresentou um novo conceito: Diagramas de estrutura de tarefas, que bom! Portanto, está em C. O que você teria para um documento com todos os requisitos, se não o UseCases?

— Cassio

Na IMO, você precisa de uma lista de requisitos identificáveis, de emissão mais ou menos única, apenas para basear seus casos de teste. Para mim, o UseCases é apenas um método para chegar a essa lista. Um bom método, em alguns casos.

— Wouter van Ooijen

1

Não projetei nada com espaço qualificado. Mas eu trabalhei para um subcontratado aeroespacial do Departamento de Defesa (DoD) e muitos dos meus projetos eram qualificados para voos. Eles exigem muita documentação sobre seus projetos e fornecem DIDs (Descrições de Itens de Dados) que detalham exatamente o que eles querem ver.

Você pode usar a Pesquisa rápida do DoD ASSIST para ver todos os DIDs dos documentos que podem ser necessários se você digitar "software" no campo "Palavra (s) no título" e clicar em Enviar. (Acho engraçado que um site do DoD gere um aviso de segurança de certificado, mas garanto que é seguro).

Como você pergunta especificamente sobre um Documento de Design, aqui está o DID ( Descrição de Design de Software ). Eles enfatizam o uso de palavras para descrever cada parte do design. Mas se o uso de UML, diagramas de estado, fluxogramas, pseudo-código etc. etc. puder melhorar o entendimento do design, é claro que eles gostariam que você o incluísse.

Qual método de modelagem você escolhe, como outros já declararam, depende do seu design. Mas eu pensei que ver um DID para software aeroespacial poderia ajudá-lo a escrever seu Documento de Design, já que seu projeto está relacionado ao espaço.

— embedded.kyle
fonte