Mathilde VINCENT - Olivier JOURDAN Paris - le 7/2/2012 Démystifier la mise en œuvre de la programmation orientée objet sous LabVIEW Merci de votre présence L’objectif de notre présentation n’est pas de balayer l’ensemble des techniques liés à la POO, mais de présenter les concepts de bases sans lesquels la POO peut rester obscure et complexe. Mathilde VINCENT - Olivier JOURDAN Paris - le 7/2/2012

Qui sommes nous ? Une PME du Grésivaudan Créée en 1989 ! Plus de 15 développeurs certifiés LabVIEW Notre activité se compose de 3 pôles : Services : Développement d’applications de traitement de signal et de test sur cahier des charges, expertise, assistance technique… Produits : une application de relecture de fichier et 5 toolkits LabVIEW dont un gratuit Formation : Centre de formation agréé par NI, formation custom…

Programme Pourquoi ? Etude de cas Exemples d’applications Perspectives Passons maintenant au vif du sujet :

Historique 1990 : Adoption généralisée (JAVA, C++,…) 1950 : Apparition du concept de POO 1960 : Premiers langages « Orienté-Objet » 1990 : Adoption généralisée (JAVA, C++,…) 1994 : GOOP - Add-on LabVIEW 2006 : LabVIEW 8.2 - implémentation native Un concept ancien et éprouvé dans de très nombreux langages, mais jeune avec LabVIEW.

Bénéfices attendus Faciliter l’ajout des fonctionnalités Faciliter le travail en équipe Gagner du temps lors du développement Améliorer la maintenabilité du code

Etude de cas Développer une application capable de récupérer des données en provenance d’instruments multiples. Pour démontrer les apport de la POO nous allons étudier un cas concret simplifié. RS-232 GPIB USB

Exigences Lire pour chaque instrument Un identifiant Un numéro de série La valeur mesurée Pouvoir ajouter facilement d’autres instruments

Sans objet – solution 1 « Modulaire » Peu évolutif N’est pas un mauvais choix à priori, mais peu entrainer des difficultés au fur et à mesure de l’évolution du code. - code hétérogène - difficulté intégrer des fonctionnalité communes (moyennage, mise à l’échelle…) - duplication de code pour les instruments très proches - … « Modulaire » Peu évolutif Ne favorise pas un code homogène Risque de duplication de code

Sans objet – solution 2 « Modulaire » « Plus évolutif » Evolution possible pour répondre à certaine problématique comme l’ajout de fonctionnalité (par ex : moyennage sans faire initialisation-libération à chaque mesure) ou l’homogénéité du code (« obligation » de faire un « init », un « Read » et « un release ». Difficulté pour résoudre les cas particuliers, augmentation du nombre d’instrument = augmentation de la complexité du code « Modulaire » « Plus évolutif » Moins maintenable !

Solution OO Décrire le monde réel au sein du logiciel à l’aide d’objets Profiter des fonctionnalités de la POO pour obtenir un code évolutif et maintenable Manière de penser notre code sous forme « d’ objet » en liens avec la réalité physique Fonctionnalités intrinsèques à la POO

Concept : Encapsulation Une classe est un ensemble de données et de fonctions qui interagissent sur ces données Un objet est une instance spécifique d’une classe Objet 1 AG34401 B254255 1,4 mV Classe Instrument Données Identifiant Numéro de série Dernière valeur lue Fonctions Initialiser Ecrire Lire Libérer Objet 2 SP202 3367E 15,37g Objet 3 LSC480 S/2323A88 57,3K

Important L’accès aux données et fonctions d’une classe est cadré Le niveau d’accès aux données de la classe est privé Le niveau d’accès aux fonctions de la classe est configurable Données modifiées uniquement au sein de l’objet. Méthodes privées

Démo Présentation class dans projet : ctl, methodes privé, public. Créatoin objet et appel méthodes dans main. Démo

Concept : Héritage Les enfants héritent des fonctions et des données du parent Les enfants peuvent ajouter des données et des fonctions Enfants Parent Instrument GPIB Série Ancêtres Descendants

Concept : Redéfinition et dispatch dynamique Capacité de modifier le comportement d’une fonction parente Dispatch dynamique LabVIEW décide lors de l’exécution quelle fonction appeler Le choix est dicté par le type de l’objet

Classe Classe Classe Classe Classe Données Données Données Données Série Données Port COM Vitesse Bit de stop Fonctions Initialiser Lire Libérer Classe GPIB Données Adresse GPIB Fonctions Initialiser Lire Libérer Classe Série Données Port COM Vitesse Bit de stop Identifiant Numéro de série Dernière valeur lue Fonctions Initialiser Récupérer info Lire Libérer Classe Instrument Données Identifiant Numéro de série Dernière valeur lue Fonctions Initialiser Récupérer info Lire Libérer Classe GPIB Données Adresse GPIB Identifiant Numéro de série Dernière valeur lue Fonctions Initialiser Récupérer info Lire Libérer

Démo

Résumé

Résumé Un code structuré Un code évolutif Organisation de code par les classes « Protection » des données Développement des classes >< Utilisation des classes Un code évolutif Très facile d’ajouter de nouvelles fonctionnalités Très facile de faire évoluer le code principal

Exemple d’application - Topaze

Contexte Pouvoir s’adapter à tout type de fichiers Pouvoir proposer différentes configurations (traitements, visualisations, …) N’avoir qu’un seul exécutable

Solution Mettre en place une architecture plug-in Chargement dynamique de classes filles Enrichissement de l’exécutable au runtime grâce au dispatch dynamique Chargement dynamique Chargement statique Fichier CSV WAV AIFF TDMS …

Aller plus loin… De nombreux modèles de conception existent : Factory pattern Singleton Pattern … Débat ouvert entre « By value » et « By reference » Actor framework, G#, ...

Pour aller plus loin… NI Community : Forum LAVA Large LabVIEW Application Development Actor Framework 2011 G# Forum LAVA Formation Object-Oriented Design and programming in LabVIEW

Des questions ? www.saphir.fr https://decibel.ni.com/content/groups/saphir-toolkit https://decibel.ni.com/content/groups/saphir-topaze