Je commence dans la programmation de logiciels embarqués à l'aide d'un RTOS et, comme je suis déjà développeur pour des applications bureautiques, je me demandais à quoi ressemble la modélisation de logiciels embarqués à l'aide de diagrammes UML, comme les diagrammes d'activité, les diagrammes de séquence, les cas d'utilisation, etc.
Les logiciels intégrés sont-ils conçus en utilisant UML, de la même manière que les applications de bureau? Est-ce la meilleure option ou y en a-t-il une meilleure? Puis-je avoir quelques exemples?
Existe-t-il un outil spécifique pour cela?
Réponses:
Il existe des extensions UML en temps réel qui ont été popularisées par une entreprise dont le nom m'échappe pour le moment. Je me souviens d'avoir fait un article là-dessus il y a plusieurs années. Bruce Powell Douglass a écrit quelques livres sur le thème de la modélisation de systèmes embarqués en utilisant UML, mais son entreprise n'est pas celle à laquelle je pense.
Cela dit, pour faire écho à Wouter, les logiciels embarqués n'ont rien de spécial en soi. J'écris tous les jours des logiciels embarqués pour un système qui fonctionne sur des processeurs de classe Pentium; UML est tout à fait applicable. Rappelez-vous également que de nombreux aspects du logiciel de contrôle ont été ajoutés à UML au fil du temps: il existe une syntaxe pour spécifier les événements synchrones ou asynchrones ainsi que le temps de réponse dans les diagrammes de séquence, le comportement du type de réseau Petri peut être trouvé dans les diagrammes d'activité, le comportement du modèle Statecharts encore meilleur que les diagrammes d'état peuvent, etc.
OTOH, beaucoup de gens préfèrent modéliser des logiciels embarqués à l'aide de concepts de conception structurée et de flux de données. Tout dépend du type de système que vous concevez et de ce qui fonctionne le mieux.
la source
Lorsque nous nous tournons vers un RTOS, nous avons généralement affaire à une application qui a de nombreuses tâches simultanées qui doivent être planifiées de manière optimale afin que chacune d'entre elles respecte ses délais à temps ou partage ses ressources en toute sécurité. Le cadre RTOS que vous choisissez implémente un planificateur de tâches, et votre travail (généralement) consiste à écrire ces tâches individuelles avec un certain ensemble de propriétés (période, priorité, etc.), puis à les remettre au planificateur. Donc, pour la documentation, l'approche que j'adopterais serait de documenter soigneusement chaque tâche.
La plupart des logiciels intégrés et, pour autant que je sache, la plupart des RTOS ne sont pas écrits dans un langage orienté objet et peuvent donc ne pas bénéficier de beaucoup de choses qui sont orientées vers cela comme des diagrammes de classes par exemple.
Cependant, lorsque vous documentez vos tâches RTOS, tout diagramme décrivant bien la tâche serait un grand avantage. J'imagine qu'un diagramme de séquence pour chaque tâche pourrait être très utile par exemple. Parallèlement à cela, vous pouvez spécifier ses exigences strictes telles que sa période / fréquence, sa priorité, toutes les ressources partagées qu'il peut utiliser, les exigences de préemption, etc. machine de son algorithme de programmation.
Prenez n'importe lequel de ces conseils comme vous le souhaitez, je n'ai pas gâché les trucs RTOS depuis mes études, et je n'ai jamais vraiment "documenté" le travail.
la source
La modélisation, c'est avant tout
savoir quel aspect est difficile et complexe dans votre application,
trouver un outil de modélisation / langage / abstraction / convention / notation approprié pour cet aspect
la conception de cet aspect
Par conséquent, aucun outil / approche / etc. de modélisation ne convient à toutes les situations. Un satellite sera probablement un système multitâche en temps réel, probablement avec plus d'un processeur. Les diagrammes de structure des tâches, les MST et les diagrammes de séquence sont probablement utiles (pour n'en nommer que quelques-uns). Si le projet est fait en C, un diagramme de classe est moins susceptible d'être utile (s'il s'avère très utile, le choix de C était probablement faux). Je n'aime pas beaucoup UseCases, et un satellite qui n'a pas d'utilisateur. Les cas d'utilisation sont les plus appropriés dans une situation où vous souhaitez discuter des exigences de votre système avec un utilisateur non technique. Si c'est la situation dans laquelle vous vous trouvez avec un projet satellite, quelque chose a mal tourné.
la source
Je n'ai rien conçu de qualifié pour l'espace. Mais j'ai travaillé pour un sous-traitant aérospatial du ministère de la Défense (DoD) et beaucoup de mes conceptions étaient qualifiées pour le vol. Ils nécessitent beaucoup de documentation sur vos conceptions et fournissent des descriptions d'éléments de données (DID) qui détaillent exactement ce qu'ils veulent voir.
Vous pouvez utiliser la recherche rapide DoD ASSIST pour voir tous les DID des documents qui peuvent être requis si vous tapez "logiciel" dans le champ "Mot (s) dans le titre" et cliquez sur Soumettre. (Je trouve drôle qu'un site DoD lance un avertissement de sécurité de certificat, mais je vous assure que c'est sûr).
Puisque vous posez des questions spécifiques sur un document de conception, voici le SDD ( Software Design Description ). Ils mettent l'accent sur l'utilisation de mots pour décrire chaque partie de la conception. Mais si l'utilisation d'UML, de diagrammes d'état, d'organigrammes, de pseudo-code, etc., peut améliorer la compréhension de la conception, ils aimeraient bien sûr que vous l'incluiez.
La méthode de modélisation que vous choisissez, comme d'autres l'ont indiqué, dépend de votre conception. Mais je pensais que voir un DID pour un logiciel aérospatial pourrait vous aider à écrire votre document de conception car votre projet est lié à l'espace.
la source