Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

Bonnes pratiques documentation

Bonjour à tous, Beaucoup de choses ont été notées. Pour faire simple en quelques lignes...

 

  1. Le minimum : La documentation « diagramme » et « face-avant » doit être conforme au LabVIEW style Checlklist

    LabVIEW Style Checklist

     

  2. 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).

     

    code main.png

     

    plus d'info Créer des modèles de projet personnalisés avec le gestionnaire de projet LabVIEW - Pourquoi ?

     

  3. L’arborescence Windows du projet est documentée dans le manuel.

     

  4. 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)

     

  5. Le tree , Loader + Main + vi’s dynamiques et le projet .lvlib sont identifiés

     

  6. Pour la documentation des class, le diagramme UML est livré, généré avec le toolkit G# StarUML

    Deformation.png

     

  7. 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.

     

  8. 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.

    connecteurs.png

     

  9. L’aide contextuelle, CTRL+H, est documentée. Elle explique la finalité du vi, afin de l’utiliser comme une « boite noire ».

     

  10. 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+

 

 

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW
Auteur livre LabVIEW : Programmation et applications - Introduction à LabVIEW NXG
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD)
LabVIEW Champion

Message 11 sur 41
3 000 Visites

Luc ... quand on a fait tout ça ... on a plus le temps de coder !

 

je taquine Smiley clignant de l'œil ... (intervention de ta part très intéressante .... comme dab)

Message 12 sur 41
2 995 Visites

ouadji a écrit :

Luc ... quand on a fait tout ça ... on a plus le temps de coder !

 

je taquine Smiley clignant de l'œil ...


Salut chef, quand on fait tout ça…. On est payé pour le faire…

Smiley tirant la langue

A+

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW
Auteur livre LabVIEW : Programmation et applications - Introduction à LabVIEW NXG
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD)
LabVIEW Champion

Message 13 sur 41
2 992 Visites

oui, évidemment ... paramètre non négligeable.

 

Bon ... bein ... échec et mat ... j'accepte !   Smiley clignant de l'œil

Message 14 sur 41
2 989 Visites

Merci Luc pour cette réponse détaillée. Si j'applique la majorité des points, les autres sont une excellente source d'inspiration pour progresser.

 

Je suppose qu'il s'agit de règles imposées à tous les développeurs.

Sont-elles définies par écrit dans une sorte de "Directives de programmation" ?

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)

Leur application dans la pratique est-elle vérifiée ?

Message 15 sur 41
2 969 Visites

ce n'est pas pour rien qu'il est CLA...

C'est bien, ca me donne un objectif.

 

Moi aussi je suis curieuse et je réitère la question de JB, est ce qu'il y a un contrôle du code fait par un responsable qualité ?

ou alors une fiche de validation que doit remplir le développeur et où il coche tous ces points ?

Parce que j'applique irrégulièrement ces points (souvent une partie mais pas l'autre, selon le projet et le code...).

Chez moi, il n'y pas de responsable qualité, et une fiche de validation, ca m'irait bien. Allez hop, sur ma todo list !

 

merci pour le post.

 

Adeline.

Message 16 sur 41
2 966 Visites

"...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 !    Smiley très heureux:  ... et entre deux traites, je programme toujours  Smiley tirant la langue

Message 17 sur 41
2 962 Visites

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.


 

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW
Auteur livre LabVIEW : Programmation et applications - Introduction à LabVIEW NXG
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD)
LabVIEW Champion

Message 18 sur 41
2 930 Visites

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.


 

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW
Auteur livre LabVIEW : Programmation et applications - Introduction à LabVIEW NXG
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD)
LabVIEW Champion

0 Compliments
Message 19 sur 41
2 928 Visites

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...
banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW
Auteur livre LabVIEW : Programmation et applications - Introduction à LabVIEW NXG
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD)
LabVIEW Champion

Message 20 sur 41
2 924 Visites