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.
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 :
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.
Quel est l’avantage pour un tout nouvel utilisateur de LabVIEW ?
Quel est l’avantage pour un programmeur expérimenté G qui ne pratique pas la POO ?
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
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.
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.
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).
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.
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.
Vous pouvez trouver un téléchargement gratuit de la suite de développement GOOP sur le site Web de NI.
Oui.
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.
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.
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.
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.
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.
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.
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.
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.
« 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 :
Veuillez vous référer à Programmation orientée objet LabVIEW : les décisions derrière la conception.
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.
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.
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é.
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.