Progettazione di software incorporato

11

Sto iniziando a programmare software embedded usando un RTOS e, dato che sono già uno sviluppatore per applicazioni desktop, mi sono sempre chiesto cosa significhi modellare software embedded usando diagrammi UML, come diagrammi di attività, diagrammi di sequenza, casi d'uso, ecc.

Il software incorporato è progettato utilizzando UML, allo stesso modo delle applicazioni desktop? È l'opzione migliore o ce n'è una migliore? Posso avere qualche esempio?

Esiste uno strumento specifico che lo fa?

embedded software

— Cassio
fonte

8

Non c'è assolutamente nulla di specifico nelle applicazioni integrate. Ciò che è speciale sono le applicazioni con risorse limitate , le più comuni di tali restrizioni sono le restrizioni temporali, ad esempio i requisiti in tempo reale. Se ci dici di più sui requisiti per la tua domanda, potremmo essere in grado di darti una risposta specifica.

— Wouter van Ooijen,

3

Sono totalmente d'accordo con i commenti di @Wouter sulle applicazioni con risorse limitate, ma credo che ci siano sfumature di progettazione specifiche associate all'uso di un RTOS rispetto a un ambiente di sviluppo desktop pianificato in cui il blocco delle chiamate è una pratica accettata.

— HikeOnPast,

1

Prestare attenzione ai sistemi incorporati di ingegneria eccessiva. Vedi anche "The King's Toaster" ee.ryerson.ca/~elf/hack/ktoast.html

— drxzcl

2

@drxzcl - Non sono d'accordo. In primo luogo, non penso che si possa prestare troppa attenzione durante la progettazione di software qualificati per lo spazio . In secondo luogo, l'approccio dell'ingegnere al tostapane del re è la ragione per cui viene bruciato così tanto pane. La maggior parte dei tostapane sono troppo semplici per quello che in realtà è un lavoro non banale.

— Rocketmagnet,

1

@Cassio: sto con Wouter su questo. Devi analizzare tu stesso il problema e quindi mappare le parti importanti usando qualsiasi sistema che ritieni appropriato. Il problema con la scelta di una rappresentazione prima di analizzare il problema è che ti blocchi nel vedere il problema in un certo modo. UML è una rappresentazione che ha le sue radici nel software aziendale e non vuoi essere attirato nella progettazione di software embedded come il software aziendale.

— drxzcl,

8

Ci sono estensioni in tempo reale a UML che sono state rese popolari da una società il cui nome mi sfugge al momento. Ricordo di averci scritto un articolo diversi anni fa. Bruce Powell Douglass ha scritto alcuni libri sull'argomento della modellazione di sistemi embedded usando UML, ma la sua compagnia non è quella a cui sto pensando.

Detto questo, per fare eco a Wouter, non c'è nulla di speciale nel software incorporato in sé. Scrivo software embedded ogni giorno per un sistema che gira su processori di classe Pentium; UML è abbastanza applicabile. Inoltre, ricorda che molti aspetti del software di controllo sono stati aggiunti a UML nel tempo: esiste una sintassi per specificare eventi sincroni o asincroni insieme a tempi di risposta nei diagrammi di sequenza, il comportamento del tipo di rete di Petri può essere trovato ancora meglio in Diagrammi di attività, comportamento del modello di Statecharts di quanto possano fare i diagrammi di stato, ecc.

OTOH, molte persone preferiscono modellare il software incorporato utilizzando i concetti di progettazione strutturata e flusso di dati. Si tratta del tipo di sistema che stai progettando e di ciò che funziona meglio.

— Lyndon
fonte

Grazie @lyndon. Ma come si modella il software incorporato ogni giorno? Pensi che i diagrammi di attività, le macchine a stati e i diagrammi di sequenza farebbero il trucco? In realtà sto cercando il concetto di cosa progettare, quindi quali sono gli schemi da fare per essere inseriti nel Documento di progettazione, se ce n'è uno per i sistemi incorporati.

— Cassio,

I costrutti più frequenti che vedo sono diagrammi di stato / diagrammi di stato e diagrammi di sequenza per l'uso quotidiano. Sinceramente penso che potremmo sfruttare maggiormente i diagrammi di classe, ma trovo che le persone abbiano la tendenza a creare semplicemente "oggetti divini". Oh: la compagnia a cui stavo pensando è Artisan Software. Questo collegamento può essere informativo: werner.yellowcouch.org/Papers/rtuml/index.html#toc7

— Lyndon

5

Quando ci si rivolge a un RTOS, di solito abbiamo a che fare con un'applicazione che ha molte attività simultanee che devono essere pianificate in modo ottimale affinché ciascuna di esse rispetti le scadenze in tempo o condivida le risorse in modo sicuro. Il framework RTOS che scegli implementa un programmatore di attività, e il tuo compito (in genere) è quello di scrivere queste singole attività con un certo set di proprietà (periodo, priorità, ecc.) E poi consegnarlo allo scheduler. Quindi, per la documentazione, l'approccio che seguirei sarebbe quello di documentare attentamente ogni compito.

La maggior parte dei software incorporati e, per quanto ne so, la maggior parte dei RTOS non sono scritti in un linguaggio orientato agli oggetti e quindi potrebbero non beneficiare di molte cose che sono orientate verso simili diagrammi di classe, ad esempio.

Quando si documentano le attività RTOS, tuttavia, qualsiasi diagramma che descriva bene l'attività sarebbe un grande vantaggio. Immagino che un diagramma di sequenza per ciascuna attività possa essere molto utile, ad esempio. Oltre a ciò puoi specificare i suoi requisiti rigidi come il suo periodo / frequenza, priorità, qualsiasi risorsa condivisa che può usare, requisiti di prelazione, ecc. Inoltre potrebbe essere utile documentare come hai configurato RTOS e forse uno stato- macchina del suo algoritmo di schedulazione.

Prendi uno di questi consigli come preferisci, non ho fatto casino con le cose di RTOS dai tempi del college e non ho mai "documentato" veramente il lavoro.

— Jon L
fonte

Grazie @JonL. Quindi, per avere un bel Documento di progettazione, dovrei solo progettare le attività coinvolte nella mia applicazione? Inoltre, non ho molta familiarità con un algoritmo di pianificazione, non ho mai avuto a che fare con esso. Sto usando RTEMS.

— Cassio,

@Cassio, non ti sto dicendo di fare una cosa o l'altra, dipende davvero da te. Prova solo a fare ciò che è necessario. Se non hai familiarità con il tuo RTOS, penso che iniziare con esso prima e come dovresti usarlo sarebbe un buon punto di partenza. Quindi puoi iniziare a progettare le tue attività attorno ad esso.

— Jon L

Sì, sto ancora acquisendo familiarità con le funzionalità RTOS. E grazie per l'approccio suggerito! Lo farà! E come ho detto prima, sono nuovo nel software incorporato, non sono davvero sicuro di cosa sia necessario. Sarebbe bello avere un documento di progettazione o architettura software integrato. Ne avresti uno?

— Cassio,

"la maggior parte dei RTOS non sono scritti in un linguaggio orientato agli oggetti" In effetti. Ma per un corso di modellazione e implementazione in tempo reale utilizziamo un RTOS semplice (non preventivo) in C ++.

— Wouter van Ooijen,

5

La modellazione è tutto

sapendo quale aspetto è difficile e complesso nella tua applicazione,
trovare uno strumento di modellizzazione / linguaggio / astrazione / convenzione / notazione appropriato per quell'aspetto
progettando quell'aspetto

Quindi nessuno strumento di modellizzazione / approccio / etc è appropriato per tutte le situazioni. Un satellite sarà probabilmente un sistema multi-tasking in tempo reale, probabilmente con più di un processore. Diagrammi di struttura delle attività, STD e diagrammi di sequenza sono probabilmente utili (solo per citarne alcuni). Se il progetto viene eseguito in C, un diagramma di classe è meno probabile che sia utile (se risulta molto utile, probabilmente la scelta per C era sbagliata). Non sono molto affezionato a UseCases e un satellite non ha utenti. I casi d'uso sono più appropriati in una situazione in cui si desidera discutere i requisiti del proprio sistema con un utente non tecnico. Se questa è la situazione in cui ti trovi in un progetto satellitare, qualcosa è andato storto.

— Wouter van Ooijen
fonte

Grazie @Wouter. Mi hai introdotto un nuovo concetto: diagrammi di struttura delle attività, bello! Quindi, è in C. Cosa avresti per un documento con tutti i requisiti, se non UseCases?

— Cassio,

IMO è necessario un elenco di requisiti identificabili, più o meno a singola emissione, se non altro per basare i casi di test. Per me gli UseCases sono solo un metodo per arrivare a tale elenco. Un buon metodo, in alcuni casi.

— Wouter van Ooijen,

1

Non ho progettato nulla che sia qualificato per lo spazio. Ma ho lavorato per un subappaltatore aerospaziale del Dipartimento della Difesa (DoD) e molti dei miei progetti erano qualificati per il volo. Richiedono molta documentazione sui progetti e forniscono descrizioni degli elementi di dati (DID) che dettagliano esattamente ciò che vogliono vedere.

È possibile utilizzare la Ricerca rapida ASSIST DoD per visualizzare tutti i DID per i documenti che potrebbero essere richiesti se si digita "software" nel campo "Parola / e nel titolo" e si fa clic su Invia. (Trovo divertente che un sito DoD emetta un avviso di sicurezza del certificato, ma ti assicuro, è sicuro).

Dato che chiedi specificamente di un documento di progettazione, ecco il DID della descrizione del design del software (SDD). Sottolineano l'uso delle parole per descrivere ogni parte del design. Ma se l'uso di UML, diagrammi di stato, diagrammi di flusso, pseudo-codice, ecc., Può migliorare la comprensione del design, allora ovviamente vorrebbero che tu lo includessi.

Quale metodo di modellazione hai scelto, come altri hanno affermato, dipende dal tuo design. Ma ho pensato che vedere un DID per il software aerospaziale potesse aiutarti a scrivere il tuo documento di progettazione poiché il tuo progetto è legato allo spazio.

— embedded.kyle
fonte