From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Discussions au sujet de NI LabVIEW
Bonnes pratiques documentation
Bonjour à tous, Beaucoup de choses ont été notées. Pour faire simple en quelques lignes...
-
Le minimum : La documentation « diagramme » et « face-avant » doit être conforme au LabVIEW style Checlklist
-
La structure de l’application principale est documentée dans un manuel programmeur. La structure repose, en générale, sur un framework de type QMH modifié « entreprise ». Les process ou Actors sont identifiés et documentés. La méthode de communication entre les process est expliquée. L’avantage d’utiliser le modèle de projet de NI, est d’utiliser la documentation html livrée avec le projet. Le design pattern est connu.
L’exemple de framework QMH de NI livré avec LabVIEW est vraiment un excellent exemple de documentation de structure d’application. Aide contextuelle des vi’s, description dans le diagramme et aide html du projet
Avec LabVIEW 2012 est arrivé les modèles de projet LabVIEW via le gestionnaire de projet. Il est livré quelques modèles, ou Framework, avec LabVIEW, dont les fameux QMH (Queue Driven Message Handler) ou modèle Gestionnaire de messages dans une file d'attente (GMF).
plus d'info Créer des modèles de projet personnalisés avec le gestionnaire de projet LabVIEW - Pourquoi ?
-
L’arborescence Windows du projet est documentée dans le manuel.
-
La génération d’un exécutable est également documentée dans le manuel, ainsi que la règle de gestion des versions (de préférence celle de LabVIEW avec les vis LabVIEW)
-
Le tree , Loader + Main + vi’s dynamiques et le projet .lvlib sont identifiés
-
Pour la documentation des class, le diagramme UML est livré, généré avec le toolkit G# StarUML
-
Les noms des vi’s respectent une règle « NomClient CodeFonction Action.vi ». La liste des CodeFonction est fixée et correspond à un code couleur pour l’îcone.
-
Les connecteurs des sous-vis sont de type 4x4. Si la fonction nécessite plus d’entrées ou sorties, elles sont regroupées dans une structure
cluster.
-
L’aide contextuelle, CTRL+H, est documentée. Elle explique la finalité du vi, afin de l’utiliser comme une « boite noire ».
-
Le diagramme d’un vi
-
se « lit » de la gauche vers la droite et les vis sont alignés sur le fil d’erreur pour plus de clarté.
-
il doit tenir dans une fenêtre de la taille de l’écran (écran de taille raisonnable).
-
Sont présents les clusters des gestions d’erreurs « error in » et « error out
-
Le code du diagramme doit être commenté pour être lisible, ou moins un commentaire par vi
A+
Luc ... quand on a fait tout ça ... on a plus le temps de coder !
je taquine 
... (intervention de ta part très intéressante .... comme dab)
ouadji a écrit :
Luc ... quand on a fait tout ça ... on a plus le temps de coder !
je taquine
Salut chef, quand on fait tout ça…. On est payé pour le faire…
A+
"...alors une fiche de validation que doit remplir le développeur ..."
my God ... ça me rappelle le temps ou j'avais ce "genre" de fiche à remplir :
durée : par tranche de 15min
quoi, ou, comment, pour qui, à la demande de qui, protocole utilisé (et pourquoi), matériel utilisé (et pourquoi), quantité ...
et "l'indice satisfaction client" ... ça, c'était le truc super top .. toujours trop bas (par définition)
Un matin, j'ai eu un flash ... je me suis dit ... pour vivre "ça", ou je m'auto-termine, ou je vais faire du fromage dans le Larzac.
J'ai choisi le fromage ! 
: ... et entre deux traites, je programme toujours
JB a écrit :
Je suppose qu'il s'agit de règles imposées à tous les développeurs.
Imposées mais partagées. Nous sommes tous des développeurs certifiés, au moins niveau CLD, et nous nous devons de respecter un développement niveau CLD, donc respecter le LabVIEW Checklist. C’est notre métier. Mais bien développer n’est pas une contrainte. Un code qui respecte les règles est un code plus simple à maintenir et à documenter. Au final, sur des projets de quelques semaines, plus rapide à développer.
Après je n’ai pas la prétention de dire que mon code est documenté à 100% correctement, mais le but est d’avoir une exigence à 90%. Nous devons être fier de notre code, et de ne pas avoir peur de le montrer.
Je préfére : règles partagées par tous les développeurs.
Sont-elles définies par écrit dans une sorte de "Directives de programmation" ? Oui, en plus du document de NI LabVIEW Checklist
Comment et par qui sont elles établies et actualisées en fonction des évolutions de LV et des manières de faire ? (par ex échange annuel entre développeurs)
Par rapport au sujet, honnêtement les règles de développement « sur le style de Vi’s » n’évoluent pas beaucoup. Les techniques de développement « oui ». Mais pas le style (la documentation, …). Une chose a évolué récemment en interne, les noms de VI’s dans les class, Xctl et lvlib, suivant les préconisations de NI. D'autres choses ont été modifiées mais sur le framework.
Le cycle de modification est donc de l’ordre de l’année. Les développeurs discutent et les décideurs décident.
Leur application dans la pratique est-elle vérifiée ?
Comme dans chaque équipe, il y a des revues de code. Parfois quelques tensions. Mais les règles sont du bon sens sur les méthodes de développement, elles sont partagées, l’appliquer ne génère pas de problème et puis ce sont les règles.
A._Dek... a écrit :
est ce qu'il y a un contrôle du code fait par un responsable qualité ?
Les développeurs sont responsables de leur code, ils sont CLD et ils font du « bon code » niveau LabVIEW Checklist. Nous sommes une petite équipe. Il n’y a pas de responsable qualité. Mais il y a comme dans chaque projet, un responsable du projet, l’architecte logiciel, qui est responsable du bon déroulement du projet dans son ensemble.
ou alors une fiche de validation que doit remplir le développeur et où il coche tous ces points ?
Le sujet du post étant « le style des VI’s LabVIEW », si tu veux une fiche de validation, tu peux prendre le LabVIEW style checklist, et cocher les cases ! Une bonne idée, c’est le but du document.
Sinon ne pas oublier les outils de National Instruments, notamment le NI LabVIEW VI Analyser Toolkit. Perso je l’utilise toutes les 2 à 4 semaines.
Pour finir, il n’y a rien de vraiment « extraordinaire » dans mes retours. Dans une équipe, il y a des règles car elles facilitent le travail.
Un développement LabVIEW est articulé, selon moi, autour de 3 axes :
-
La forme : le Style des vi’s. Le sujet du post. Personnellement, je pense que 80% de bonnes pratiques de développement, par rapport au style, sont dans le LabVIEW Style Checklist. Un développeur niveau CLD doit respecter ces consignes. Le NI LabVIEW VI Analyser Toolkit permet de le vérifier. Après il y a 20% de règles « Entreprise ». Le but est d’avoir une homogénéité dans le travail d’équipe, que le développeur A puisse reprendre le travail de B.
-
Le fond, la technique de développement du code des VI’s. Dans notre équipe nous avons « sensiblement » tous le même niveau « développement LabVIEW ».
-
La structure du Framework du projet: la traduction du diagramme d’états du logiciel, permet la transition entre les états, gestion des erreurs, lien entre les actors ou process. Dans 95% nous utilisons une structure de projet qui repose sur un "QMH modifié Entreprise".La documentation n'est pas une option du devis...
