Programmation orientée objet LabVIEW

Aperçu

La programmation orientée objet (POO) est un paradigme de programmation utilisé dans les langages de programmation, les environnements de développement et les industries. Dans cet article, nous aborderons les questions les plus fréquemment posées sur la POO LabVIEW. Veuillez noter que ce document suppose une compréhension de base de la terminologie et des processus de POO.

Contenu

Avantages de l’utilisation de la programmation orientée objet LabVIEW

Quelles sont les différences entre la POO en C++ et LabVIEW ?


C++ est un langage fonctionnel basé sur du texte. LabVIEW est un langage graphique de flux de données. Les différents paradigmes nécessitent des différences dans la manière dont ils présentent les fonctionnalités de POO :

  • LabVIEW possède une classe ancêtre ultime pour tous les objets. C++ n’en possède pas.
  • C++ possède des constructeurs. LabVIEW n’en a pas besoin.
  • C++ possède des destructeurs. LabVIEW n’en a pas besoin.
  • Le C++ possède une syntaxe de référence et de valeur pour le passage d'objets en tant que paramètres. LabVIEW possède uniquement une valeur de syntaxe, avec des références créées par l’intermédiaire d’autres fonctionnalités.
  • LabVIEW possède une mutation de données automatique permettant à l’utilisateur de récupérer d’anciennes données même si la classe a été éditée. Le C++ n’en possède pas, et il nécessite que l’utilisateur suive les modifications de version et écrive le code de mutation pour les données.
  • Le C++ possède des modèles. LabVIEW 8.2 et les versions ultérieures n’en possèdent pas.
  • Le C++ possède des fonctions virtuelles pures. LabVIEW 8.2 et les versions ultérieures n’en possèdent pas.
  • C++ possède de nombreux héritages. LabVIEW n’en possède pas.
     

Pour plus d’explications sur ces différences, veuillez vous référer à Programmation orientée objet LabVIEW : les décisions derrière la conception.

Quels sont les premiers avantages de l’utilisation de la programmation orientée objet LabVIEW ?


Quel est l’avantage pour un tout nouvel utilisateur de LabVIEW ?

  • La force de LabVIEW réside dans le fait qu’il rend la puissance de l’informatique accessible aux non-programmeurs. La programmation orientée objet LabVIEW met certaines des techniques de programmation les plus avancées à la portée des débutants. La POO nécessite plus d’engagement en matière de planification, et est par conséquent choisie uniquement si l’utilisateur est intégré au sein d’un large effort logiciel.
  • La POO fournit un moyen de planifier un logiciel à l’aide de termes qui correspondent aux spécifications d’une fonctionnalité. La description de la fonctionnalité concerne les éléments qui apparaissent sur l’écran, ou les portions de données que la fonctionnalité manipulera. Avec la POO, vous pouvez écrire du code qui se planifie autour de ces mêmes termes : objets de base de données, objets bouton, objets email.


Quel est l’avantage pour un programmeur expérimenté G qui ne pratique pas la POO ?

  • Facile à déboguer - un code plus modulaire vous permet de limiter la liste des VI où un bug peut se trouver.
  • Une maintenance plus facile - la conception de la POO conduit à plus de structure, ce qui aide les développeurs à être plus productifs au fil du temps. Les développeurs peuvent facilement identifier les zones où ils veulent ajouter des fonctionnalités, et ont moins de chance d’introduire des erreurs dans des sections de code sans rapport.


Qui devrait utiliser la programmation orientée objet LabVIEW ?
 

  • Les VIs devant être maintenus pendant longtemps
  • Les grandes applications
  • De nombreux développeurs travaillant sur les mêmes VIs


Qui ne devrait pas utiliser la programmation orientée objet LabVIEW ?
 

  • Les utilisateurs express
  • Pour un VI seul prenant une mesure rapide, les classes LabVIEW sont un peu surdimensionnées.


Quels sont certains exemples indiquant comment/où un client utiliserait la programmation orientée objet LabVIEW ?


Pour un test et un exemple de mesure qui oppose une approche basée sur la tâche et une approche orientée objet, référez-vous à l’exemple de Board Testing qui est livré avec LabVIEW 8.2 et les versions ultérieures.

labview\examples\lvoop\BoardTesting\Board Testing.lvproj

Comment utiliser la programmation orientée objet LabVIEW

Où puis-je en apprendre plus sur l’utilisation de la programmation orientée objet LabVIEW ? Existe-t-il par exemple des ressources pédagogiques, des notes d’application, des tutoriels, des scripts de démo, et des exemples ?


LabVIEW 8.2 et les versions ultérieures sont livrées avec plusieurs exemples de programmation orientée objet LabVIEW. Se référer aussi à la section Ressources supplémentaires de ce document.

Comment puis-je faire la transition pour passer à l’utilisation de la programmation orientée objet LabVIEW pour mes projets existants ?


Le démarrage le plus simple est de convertir les définitions de type existantes en classes LabVIEW. Vous pouvez faire cela à l’aide d’un clic droit sur une déf. de type dans la fenêtre de l’Explorateur de Projet et de la sélection de Convertir les Contenus en une Classe dans le menu local. Reportez-vous à l'Aide LabVIEW pour obtenir de plus amples informations sur la création de classes LabVIEW.

Remarque : LabVIEW ne préserve pas la valeur par défaut des commandes et des constantes au cours du processus de conversion. Pour accéder aux détails des définitions de type, ajoutez des VIs à ces classes qui ont besoin d’accéder à la définition de type. Ce groupement de VIs basé sur les données sur lesquelles ils agissent est fondamental à la programmation orientée objet. Reportez-vous aux deux présentations NI Week 2006 listées ci-dessous dans la section Informations supplémentaires pour en savoir plus sur la conception orientée objet.

Comment puis-je mettre en place une implémentation « par référence » dans la programmation orientée objet LabVIEW ?


Reportez-vous à l’exemple d’objet référence qui est livré avec LabVIEW 8.2 et les versions ultérieures.

labview\examples\lvoop\ReferenceObject\ReferenceObject.lvproj

Essentiellement, vous faites des données privées d’une classe une référence. L’exemple montre comment utiliser une référence unique de file d'attente à cette fin. Vous pouvez aussi utiliser le toolkit GOOP (reportez-vous à la section ci-dessous Programmation orientée objet LabVIEW & Toolkit GOOP).

Les classes LabVIEW fonctionnent-elles avec LabVIEW Real-Time ou avec toute cible autre que Desktop ?


Avec LabVIEW 2009, l’orientation objet est désormais prise en charge sur les cibles en temps réel de LabVIEW. La programmation orientée objet n’est pas prise en charge en temps réel avec LabVIEW 8.6 et les versions précédentes. 

Lors de la fermeture d’un VI, pourquoi LabVIEW ouvre parfois deux boîtes de dialogue Enregistrer les modifications, une pour le VI et les sous-VIs, et une autre pour les classes LabVIEW ? Pourquoi ne pas ouvrir une boîte de dialogue qui enregistre tout ?


Lorsque vous fermez un VI, LabVIEW connait tous les sous-VIs qui seront inutilisés à cause de la fermeture de ce VI, donc LabVIEW peut demander de tous les enregistrer en même temps. Les classes, cependant, ne peuvent pas quitter la mémoire avant que toutes les instances de données aient quitté la mémoire, et LabVIEW ne peut pas savoir si la fermeture d’un VI quelconque donné fermera réellement la dernière instance de données. Un VI peut n’avoir aucune référence à la classe dans son code, mais il peut encore avoir une instance de la classe stockée dans un variant quelque part. Si tous les VIs sont inactifs, LabVIEW peut déterminer combien d’instances de la classe quitteront avec cet ensemble de VIs et voir si cela représente toutes les instances de la classe restant en mémoire. Ainsi, LabVIEW saurait que la classe quitte la mémoire avec les VIs et pourrait demander la classe dans la même boîte de dialogue Enregistrer les modifications que les autres VI/bibliothèques. Mais si un VI quelconque est encore en cours d'exécution, le nombre d’instances peut fluctuer en permanence. Et pendant que les VIs sont en cours d'exécution, les données peuvent être cachées dans des emplacements impossibles à rechercher, tels qu’une file d'attente ou un notificateur, et ces espaces supplémentaires ne sont éliminés uniquement lorsque le VI devient inactif. Un VI en cours d’exécution peut aussi créer de nouvelles instances dans des emplacements que LabVIEW a déjà vérifié. Il est donc impossible de compter les instances pendant que les VIs sont en cours d'exécution. Comme LabVIEW n’abandonne pas l’exécution des VIs après avoir demandé s’il faut enregistrer ou non les modifications, LabVIEW ne peut pas déjà savoir si la classe quittera la mémoire. Même si tous les VIs étaient inactifs et que LabVIEW pouvait effectuer la recherche de données, cette recherche serait extrêmement lente, donc LabVIEW ne le tente pas du tout. Par conséquent, lorsque vous fermez un VI, les classes finissent habituellement par avoir leurs propres boîtes de dialogue Enregistrer les modifications.

La seule fois où LabVIEW peut inclure les classes avec tout le reste et offre une boîte de dialogue unique Enregistrer les modifications est lorsque vous fermez le projet. Dans ce cas, parce que tous les VI du projet seront fermés, LabVIEW sait que cela signifie que toutes les instances de données de la classe seront éliminées sans avoir à être considérées.

Programmation orientée objet LabVIEW & Toolkit GOOP

Qu’est-ce que le Toolkit GOOP ?


Vous pouvez trouver un téléchargement gratuit de la suite de développement GOOP sur le site Web de NI. 

Puis-je continuer d’utiliser GOOP dans LabVIEW 8.2 et versions ultérieures ?


Oui.

Comment GOOP et la programmation orientée objet LabVIEW peuvent-ils fonctionner ensemble ? Comment et quand devriez-vous utiliser le Toolkit Endevo GOOP en conjonction avec ou à la place de la programmation orientée objet LabVIEW ?


La plupart des utilisateurs trouveront que les classes LabVIEW fonctionnent le mieux pour leurs applications. Les classes LabVIEW se comportent exactement comme les clusters que les utilisateurs connaissent.

Vous pouvez utiliser des références pour traiter la communication entre les sections de code qui s’exécutent en parallèle. Pour les clients qui modélisent réellement des ressources système, le modèle de référence devient très utile, et ils peuvent souhaiter créer des classes GOOP. Les références sont aussi très précieuses lors de la création de graphes et de structure de données en arbre. Même dans ces cas, les champs de données au cœur de la classe GOOP peuvent bien être des classes LabVIEW. Cependant, lors de l’utilisation de références ou de tout autre moyen de communication entre des sections de code parallèle, vous devez savoir des choses sur le verrouillage, les situations de compétition, et les autres situations complexes qui surviennent.

Vous pouvez utiliser le modèle de référence pour garantir que vous ne dupliquerez jamais cette classe dans la mémoire. Pour une classe qui nécessite beaucoup de mémoire, cela peut être un avantage.

Devrais-je faire passer mon application qui utilise le Toolkit GOOP à la programmation orientée objet LabVIEW ? Quelles applications client existantes utilisant le Toolkit GOOP de Endevo devraient être implémentées en programmation orientée objet LabVIEW ?


Il n’y a aucune obligation de réécrire les classes GOOP existantes comme des classes LabVIEW. Une des raisons est que vous ne devriez jamais détruire un code qui fonctionne sans raison valable, et les classes GOOP continueront de fonctionner sous LabVIEW 8.2 et les versions ultérieures. Après tout, le Toolkit GOOP est écrit en LabVIEW. En outre, changer un code qui fonctionne par référence en entrée en un code qui fonctionne par valeur est une entreprise significative.

Une raison qui justifie une transition est la performance. Beaucoup de coûts généraux sont générés pour un objet lorsque chaque appel de fonction doit rechercher la référence, verrouiller l’instance, et extraire les données. Le Toolkit GOOP fait un superbe travail de minimisation de ces coûts généraux, mais ils sont néanmoins là. De plus, une opération utilisant un refnum empêche de nombreuses opérations qui pourraient sinon être exécutées en parallèle. Si vous avez une classe qui n’a pas besoin du comportement par référence et n’a pas besoin de meilleures performances, alors vous pouvez envisager d’effectuer une transition de la classe GOOP vers la classe LabVIEW.

Comment devrais-je effectuer la transition de mon application qui utilise GOOP vers la programmation orientée objet LabVIEW ?


C’est une question à laquelle il faut répondre en fonction des cas traités. LabVIEW n’a pas de manière automatisée d’effectuer la conversion.

Quelles sont les performances de la programmation orientée objet LabVIEW par rapport au Toolkit GOOP Endevo ?


A cause de la cohérence avec le flux de données et de la mise en œuvre du compilateur native du dispatch dynamique, les classes LabVIEW auront tendance à avoir des performances supérieures à celles des classes GOOP dans des situations équivalentes. Cela étant dit, il y a très peu de situations équivalentes. Les classes LabVIEW sont conçues pour remplacer des clusters et pour améliorer le flux de données. Les classes GOOP constituent une manière d’ajouter des références à LabVIEW. Elles servent deux objectifs différents dans le langage. Lors de la création de nouvelles classes, vous devriez choisir entre une classe GOOP ou une classe LabVIEW en fonction de la fonctionnalité dont la classe a besoin, et non en fonction des prévisions de performances.

Détails techniques

Quel est l’impact en matière de performances de l’utilisation d’une classe LabVIEW par rapport à une définition de type cluster ?


Un benchmarking sur une gamme d’ordinateurs montre que les performances des deux sont presque identiques. Reportez-vous à la question ci-dessous pour plus d’informations concernant les performances.  

Quels sont les coûts généraux de performance d’un appel de sous-VI dynamique (par rapport à un appel de sous-VI normal) ?


Un dispatch dynamique de sous-VI a des coûts généraux plus faibles lorsque LabVIEW recherche quel sous-VI doit être invoqué. Les coûts généraux sont constants. Ils n’augmentent pas lorsque vous ajoutez plus de classes ou lorsque vous ajoutez plus de VIs dynamiques à une classe. Il peut y avoir un ralentissement de performance si l’appel de sous-VI doit faire des copies supplémentaires des paramètres pour correspondre à la fonctionnalité du sous-VI réel invoqué par LabVIEW. Vous pouvez éviter cela en câblant les terminaux de face-avant d’entrée aux terminal de face-avant de sortie même sur les VIs dynamiques que vous ne prévoyez jamais d’appeler (par exemple, les VIs parents qui existent uniquement pour définir le connecteur nécessaire pour que les enfants puissent les outrepasser). Reportez-vous à programmation orientée objet LabVIEW : les décisions derrière la conception pour plus de détails sur la manière dont le dispatch dynamique est capable d’obtenir des performances de coûts généraux constantes.

Comment les bibliothèques de classes LabVIEW diffèrent-elles des bibliothèques de projet ?


Une classe LabVIEW est un type de bibliothèque de projet. C’est une bibliothèque de projet dédiée à la tâche de définition du type de données. Comme une bibliothèque de projet, la classe LabVIEW définit l’étendue et l’espace de noms pour ses VIs membres, et un VI peut appartenir à une classe LabVIEW uniquement. 

La classe LabVIEW a un contrôle des données privées. C’est un contrôle VI qui définit les valeurs des données de la classe. Ce contrôle spécial ne fait pas partie des autres types de bibliothèque, et est en fait enregistré à l’intérieur du fichier de classe. Les classe LabVIEW ont toutes les propriétés qu’ont les bibliothèques, ainsi que certaines propriétés supplémentaires. Vous pouvez voir les propriétés supplémentaires dans la boîte de dialogue Propriétés de la classe et sur les pages Héritage, Sondes et Apparence du fil de liaison.

La seule capacité des bibliothèques de projet que les classes LabVIEW ne possède pas est la capacité à contenir des sous-bibliothèques. 

Lors de l’utilisation de la programmation orientée objet LabVIEW, qu’est-ce qui est chargé et quand ?


Si un VI utilise une classe LabVIEW, alors le chargement des VIs charge la classe, de la même manière qu’un VI charge tous ses sous-VI. Une classe LabVIEW charge à son tour tous ses VIs membres et sa classe parent. Les classes parents ne déclenchent pas automatiquement le chargement de leurs classes enfants. Les parents n’ont aucun lien avec les enfants. Un VI membre d’un parent peut utiliser une classe enfant et par conséquent LabVIEW charge la classe enfant.

Qu’est-ce que « par valeur » et « par référence » signifient ? Quels sont les avantages et les inconvénients de chacun ?


« par valeur » signifie que le fil de liaison transporte des données réelles du type de fil de liaison. « par référence » signifie que le fil de liaison transporte une référence aux données du type, et que LabVIEW stocke les données réelles dans un certain référentiel central. La plupart des types de données dans LabVIEW, y compris les numériques, les tableaux, les booléens et les chemins sont par valeur. Habituellement, les seuls types qui sont par référence sont ceux qui utilisent des communications ou qui reflètent les ressources du système, tels que les refnums de fichier, les refnums de file d’attente, et les refnums de VI Serveur. Les classes LabVIEW sont par valeur. Dans une syntaxe par valeur, chaque objet a ses propres valeurs de données, que vous pouvez modifier indépendamment des autres objets. Dans une syntaxe par référence, il y a une instance unique de données à laquelle de multiples objets se réfèrent. Si un objet modifie les données, il doit faire attention à ne pas entrer en conflit avec d’autres objets qui sont en train de lire et d’écrire ces données. Les principaux avantages et inconvénients sont :

  • Par valeur est préférable dans un environnement extrêmement parallèle tel que LabVIEW, car cela évite les situations de compétition.
  • Par valeur permet à l’ordinateur de déterminer lorsque des copies de données ont besoin d’être effectuées, diminuant ainsi la charge de travail du programmeur.
  • Par référence fait porter au programmeur la responsabilité de l’allocation, ce qui est parfois un meilleur modèle pour les ressources à instance unique et les grands ensembles de données.


Pourquoi la programmation orientée objet LabVIEW est-elle « par valeur » ?


Veuillez vous référer à Programmation orientée objet LabVIEW : les décisions derrière la conception.

NI possède-t-il des outils UML pour la création/la gestion de classes LabVIEW ?


NI ne possède pas d’outil UML natif. Endevo fabrique un outil pour générer des classes à partir de diagrammes UML, et pour générer des diagrammes UML à partir de code. L’outil fonctionne actuellement pour les classes GOOP (reportez-vous à la section ci-dessus LabVIEW orienté objet & Toolkit GOOP), mais une version à venir prendra également en charge les classes LabVIEW.

Pourquoi ne puis-je pas utiliser « Désigner la valeur actuelle comme défaut » dans les commandes et indicateurs LabVIEW ? Pourquoi ne puis-je pas paramétrer les valeurs des constantes de programmation orientée objet LabVIEW ?


Désigner la valeur actuelle comme défaut
est une fonctionnalité précieuse de LabVIEW. Vous pouvez l’utiliser fréquemment pour la construction de VIs de test. Cette fonctionnalité n’est pas prise en charge pour les classes dans LabVIEW 8.2 et les versions ultérieures à cause de la complexité à fournir une bonne interface utilisateur afin que l’utilisateur sache quand les données sont autre chose que les données par défaut, même si l’utilisateur ne peut pas réellement voir les données, parce que les données sont privées. Cette fonctionnalité est une priorité élevée à inclure dans une future version de LabVIEW.

Pourquoi ne puis-je pas créer un VI dynamique réentrant ?


Les VIs dynamiques réentrants ne sont pas une fonctionnalité prise en charge dans LabVIEW 8.2. Parce que les nœuds sous-VI dynamiques, au moment de l’édition, ne savent pas quel sous-VI LabVIEW invoquera réellement lors de l’exécution, chaque nœud devrait créer des clones de tous les sous-VIs possibles. Cela s’avère être beaucoup trop coûteux en mémoire.

(LabVIEW 8.5) Vous pouvez utiliser des VIs dynamiques réentrants dans LabVIEW 8.5.

Vous pouvez configurer un VI de dispatch dynamique pour qu’il soit récursif, ou l’utiliser lui-même comme partie de sa propre définition. Les VIs récursifs peuvent s’appeler eux-mêmes sur leur propre diagramme, y compris le diagramme des sous-VIs. La récursivité est utile si vous voulez effectuer de multiples opérations sur la sortie du même processus. Vous pouvez configurer un VI membre d’un dispatch dynamique pour autoriser la récursivité en le paramétrant pour qu’il soit réentrant et pour partager les copies entre instances.

Effectuez les opérations suivantes pour configurer un VI pour la récursivité.

  1. Ouvrez ou créer un VI membre d’un dispatch dynamique.
  2. Désignez le VI comme réentrant.
     
    1. Sélectionnez Fichier»Propriétés du VI pour afficher la boîte de dialogue Propriétés du VI.
    2. Sélectionnez Exécution dans le menu déroulant Catégoriepour afficher la page Propriétés d’exécution.
    3. Cochez la caseExécution réentrante et sélectionnez Partager les copies entre instances.
       
  3. Développez le VI membre pour compléter une opération récursive.
     

Remarque : Ne pas prendre en compte la récursivité infinie provoque une utilisation de la mémoire inutile et peut faire planter LabVIEW. Pour éviter une récursivité infinie, envisagez d’appeler le VI récursif dans une structure Condition.

Informations supplémentaires

 

Was this information helpful?

Yes

No