Architecture logicielle pour l'instrumentation scientifique

Question

Je commence à travailler avec un petit groupe sur la conception d'un système de contrôle complexe pour une instrumentation scientifique. Ce projet comprendra des éléments d'acquisition de données de matériel, de contrôle de matériel, de traitement de données scientifiques, d'accès à la base de données, de contrôleurs de retour, d'interface utilisateur, etc. génie logiciel. Je voudrais que ce soit un projet bien organisé qui sera intelligible à un nouvel arrivant pour travailler et maintenir de nombreuses années sur la route.

J'ai une sorte d'architecture MVC en tête mais je suis sûr qu'il existe d'autres paradigmes qui sont mieux adaptés à ce type d'application. Est-ce que quelqu'un peut offrir des conseils sur l'architecture logicielle à utiliser et sur les ressources auxquelles nous devrions nous référer dans la planification de notre projet? Merci.

(. Désolé du manque de détails du projet, mais je voulais garder ma brève question que je peux ajouter plus de détails sur demande.)

Answer 1

Vous êtes sur la bonne voie avec MVC - vous avez besoin séparation des préoccupations. Cependant, je pense que vous avez plus de 3 préoccupations. Gardez tout dans son propre module isolé.

Si vous avez une interface bien définie pour chacun de ces modules, vous pouvez facilement écrire des tests unitaires simples, simples à manipuler. où chaque module est isolé (les autres modules auxquels on accède sont remplacés par mock objects) de sorte que tous les cas possibles peuvent être bien testés et débogués. Ensuite, des groupes de modules peuvent être assemblés et avoir des tests d'intégration écrits contre eux.

Il y a plusieurs avantages à avoir un ensemble complet de tests unitaires. (1) Refactoriser un module devient simple car vous pouvez tout tester pour vous assurer que rien ne s'est cassé. (2) Faire les tests vous oblige à organiser votre code de manière plus propre. (3) Nous savons tous que, simplement parce que le code compile, cela ne signifie pas que cela fonctionne. (4) Si le logiciel doit être fortement distribué comme certaines applications scientifiques, il peut être extrêmement difficile de suivre les bogues dans un système distribué. En testant chaque module séparément, vous éliminez les bogues avant qu'ils ne pénètrent dans le système complexe.

Cette conception est agnostique de langue. À peu près n'importe quelle langue vaut la peine d'être développée dans au moins un cadre de test unitaire et un cadre moqueur. Cela ne nécessite même pas de programmation orientée objet - cela peut être fait dans n'importe quel langage procédural ou fonctionnel.