Mathilde VINCENT - Olivier JOURDAN Paris - le 7/2/2012

Présentation au sujet: "Mathilde VINCENT - Olivier JOURDAN Paris - le 7/2/2012"— Transcription de la présentation:

1 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

2 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…

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

4 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 implémentation native Un concept ancien et éprouvé dans de très nombreux langages, mais jeune avec LabVIEW.

5 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

6 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

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

8 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

9 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 !

10 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

11 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

12 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

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

14 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

15 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

16 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

17 Démo

18 Résumé

19 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

20 Exemple d’application - Topaze

21

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

23 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 …

24 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#, ...

25 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

26 Des questions ? www.saphir.fr