Documents techniques

Plus de temps pour développer en LabVIEW

Rhône-Alpes LUG :

Rencontre développeurs 04/07/2013

Luc DESRUELLE – Certifié LabVIEW Architect - MESULOG

www.mesulog.fr

 Activité : Développement logiciel test et mesure

 Compétences : LabVIEW (Windows, RT, DSC, PDA, FPGA),

TestStand

 Localisation : Grenoble (Moirans, 38)

 Partenaire National Instruments (2001)

 Développeurs certifiés LabVIEW et TestStand

 www.mesulog.fr (exemples de réalisation)

 Ils nous ont fait confiance :

 AREVA T&D  ALSTOM Grid  ATMEL  BEAMIND  CEA (Commissariat à l'Énergie Atomique)  CETIAT (Centre Technique des Industries Aérauliques et Thermiques)  CNES (Centre National d'Études Spatiales)  CNRS (Centre National de la Recherche Scientifique)  EDF  HONEYWELL Security  LNE (Laboratoire National d'Essais)  NIST (National Institute of Standards and Technology)  NMIJ (National Metrology Institute of Japan)  PECHINEY  RADIALL  STMicroelectronics  THALES  VALEO  ...

Le présentateur

CLA

FORUMS

Chef Projet

Luc DESRUELLE

Le constat

Départ gestion

projet

Gestion projet : Juste avec

un bloc notes

Faire vite ou bien?

VITE

Coder vite ou bien

BIEN

BIEN

Gestion Projet :

Spécifications Réalisation Tâches Gestion code source Tests du code Livrables Distributions Gestion Versions Suivi des bugs Documentation Support Evolutions Machine de Dévelop.

VITE

et

un stylo MESULOG?

Livrer code

Evolution Traçabilité Version support

NON

Plus de temps

Les bons outils?

NON

OUI

Bien

Notre métier : chef de projet – développeur… LabVIEW

Mais…

Combien de temps passez-vous à coder par semaine?

70% : Technicien Développeur

10% - 20% : Architecte LabVIEW

30% : Chef de projet

Pas beaucoup de temps pour coder

 Discuter – Partager - Réfléchir

 Une vrai boite à outils pour trouver plus de temps pour coder

• Ne pas savoir où trouver de l’aide
• Pas de logiciel de gestion version
• Pas de centralisation de l’information
• Pas d’Analyse - ni Test du code source
• Pas de Planning - Gestion des bugs – Documentation
• Attendre la fin du projet pour générer l’exécutable
• Pas de gestion de la machine de développement

 L’histoire dont vous êtes le héros

 Où trouver de l’aide?

 Zoom sur : logiciel de gestion de code source

 FORGE (?)

 Logiciels d’analyse et test de National Instruments

 Autres outils dans la boite à outils

 Zoom sur : Machine Virtuelle

 La communauté travaille pour vous

 2 Forums National Instruments Francophone

 http://forums.ni.com/t5/Discussions-au-sujet-de-NI/bd-p/4171  http://forums.ni.com/t5/Discussions-au-sujet-des-autres/bd-p/4170

 1 communauté Francophone

 https://decibel.ni.com/content/community/regional/france/labview  Rencontre développeurs

 Mais aussi… l’ensemble des forums et communautés de NI

 LabVIEW Development Best Practices  ni.com/largeapps

 Des articles sur le site de NI

 « Le logiciel ne se limite pas au code » de l'équipe JKI :

 http://zone.ni.com/devzone/cda/pub/p/id/1743

 Communautés de NI

 LabVIEW Development Best Practices  ni.com/largeapps  …..

 Gestion projet chez MESULOG

Logiciel de gestion de code source

 Le contrôle du code source est l'un des aspects les plus

élémentaires du développement logiciel professionnel

 Mais aussi trop négligé

Qui utilise un logiciel de gestion code source?

Lequel?

Mais quelle utilité??

http://fr.wikipedia.org/wiki/Version_d%27un_logiciel

 Les logiciels évoluent = versions du logiciel

 Chaque étape d'avancement = version

 Les différentes versions sont liées à un ensemble

de modifications de fichiers

 « révision » d’un fichier VS la « version » d'un logiciel.

Cette activité étant fastidieuse et complexe, un appui logiciel est presque indispensable.

 Microsoft Windows

Un logiciel de gestion de code source pourquoi?

Pour répondre à :

 Comment faire pour gérer les révisions du code source ?

 Comment gérer les versions des exécutables ?

 Comment travailler à plusieurs développeurs ?

 Comment faire des tests et les conserver ?

 Comment revenir sur une ancienne version?

 ….

 Source Code Control : SCC

 Agit sur une arborescence de fichiers afin de :

 Conserver toutes les révisions des fichiers

(Historique)

 Ajouter un commentaire pour chaque livraison.  Identifier & retrouver le code source des différentes

versions du logiciel.

 Aider aux développements multi-développeur (fusion

de copies locale et distante, gestion conflits)

… beaucoup d’autres fonctionnalités

Logiciel de gestion de versions

Logiciels libres

Logiciels propriétaires PVCS (1985) D'importance historique SCCS (1972)

GNU RCS (1982) GNU CSSC

 1972 Source Code Control

Gestion locale

System (SCCS) est un système de gestion de versions pour les Systèmes d’IBM .

CVS (1990) CVSNT (1992) SVN (2000) Rational ClearCase (1992) CCC/Harvest (Années 70) CMVC (1994) Visual SourceSafe (1994) Perforce (1995) AccuRev SCM (2002) Sourceanywhere (2003) Rational Synergy (2006) GNU arch (2001) Darcs (2002) DCVS (2002) SVK (2003) Monotone (2003) Codeville (2005) Git (2005) Mercurial (2005) Bazaar (2005) Fossil (2007) Veracity (2011) BitKeeper (1998) Plastic SCM (2007)

Logiciels libres

 Puis RCS, CVS, puis

Client-serveur

Logiciels propriétaires

Subversion, Mercurial, Git,...

Logiciels libres

Décentralisé

Logiciels propriétaires

 Subversion (en abrégé svn)

 Mode client-serveur, avec :

 Un Serveur unique où se situent :

 les fichiers constituant la référence (le 'dépôt' ou 'référentiel')  un logiciel serveur Subversion tournant en 'tâche de fond'

 Des postes clients sur lesquels se trouvent :

 les fichiers recopiés depuis le serveur, éventuellement modifiés

localement depuis,

 un logiciel client permettant la synchronisation entre chaque

client et le serveur de référence

 Son nom vient de l'anglais Tortoise, « Tortue »

 Logiciel Libre

 S’intègre à l'explorateur de Windows :

 Superposition d'icône aux répertoires et fichiers permettant de

visualiser instantanément l'état

 « Menu contextuel » des actions

Serveur SVN

Avec Dépot ou

repository

 Architecture

Client SVN

Par exemple TortoiseSVN

Client SVN

Par exemple TortoiseSVN

Client SVN

Par exemple TortoiseSVN

 Création du dépôt sur le serveur

Chemin du dépôt :

Trunk Tags branches

 Exemple : Extraire sur un client

 Exemple : Commit ou livraison par un des clients

 Exemple : Mettre à jour ou Update par un autre client

 Exemple : revenir en arrière ou Revert

 Exemple : Tag ou étiquette : retrouver une

version

 Exemple : journal

4 3

1 1 1

Perforce Subversion ClearCase Git VSS Mecurial none

Source: 2010 ni.com/largeapps survey

Native LabVIEW Integration

 Perforce

Integration Through Standard API

 Microsoft Visual SourceSafe  Microsoft Team System  Rational ClearCase  PCVS (Serena) Version Manager  MKS Source Integrity  Seapine Surround SCM  Borland StarTeam  Telelogic Synergy  ionForge Evolution

Support through additional add-ons

 Subversion  Mecurial

 Gestion utilisateurs – mot de passe

 Accès https

 Branches

 Merge

 Lock

 …..

FORGE ?

 Bug tracker : outil de gestion de bug

 Identifier, Diffuser, sauvegarder  Associer à une version de code  Correctif code et distribution

 Quelques exemples

 FogBugz  Mantis  Bugzilla  Tuleap

 Diffusion documentation

 Box (box.com)  Tuleap

 Diffusion distribution

 Serveur FTP  Tuleap

 Gestion des tâches

 Trello  Tuleap

 Intégration Continue

 Jenkins

 Beaucoup de logiciels MAIS Logiciels séparés….

 FORGE?

 Système qui gère « les développements collaboratif de logiciel »  Système simple et efficace  Regroupe les outils

 TULEAP

 Mettre à disposition de tous les acteurs autorisés,

l'ensemble des données du projet :

 Documentation (doc #ID)  Code source (gestion sous Subversion, https, snv #ID)  Exécutables, installeurs (release #ID unique)  Suivi de tâches (task #ID unique)  Suivi de bugs (bug #ID unique)  Espace de téléchargement FTP  Forums de discussion et wiki  Les commentaires SVN sont croisés avec les tags #ID unique

des bugs - livrable - task. L'historique du projet est ainsi redoutable.

« La Suite ALM 100% Open-Source»

Test et Analyse du code

Requirements

Gathering

Application Architecture

Testing and Validation

Development

Deployment

LabVIEW Unit Test Framework

LabVIEW VI Analyzer

LabVIEW Desktop Execution Trace

Application Builder

Debugging &

Testing

Unit Test Framework

Functional Validation

of Code

Advanced

Desktop Execution Trace

Real Time Execution Trace

Dynamic Code Analysis

VI Analyzer Toolkit

Static Code Analysis

Simple

Low Risk

High Risk

Application Criticality

 Performance  Style  Complexité

 Possibilité d’ajouter des

fonctions de test (LV 2010)

 Fonctions de test

 https://decibel.ni.com/content/docs/DOC-28198

Trace During Run-Time:

• Event Structures
• Memory Allocation
• Queues / Notifiers
• Reference Leaks
• Thread ID
• Unhandled Errors
• Dynamic / Static SubVIs
• Custom User Strings

Input Values Output

VI Under Test

Unit Test Framework

Expected Output

Automated

Report Generation

Test vector = Input value(s) + Expected

output(s)

 L'enregistreur d'action utilisateur ... de Windows

 Fonction cachée de Windows 7.

 Enregistrer actions utilisateur à effectuer.

 Sauvegarde directement du descriptif des actions, images

et commentaires dans un fichier .mht

Dans le menu Démarrer de Windows, tapez les lettres "PSR":

 Autoit

 production de logiciel utilitaire pour Microsoft Windows.

 Automatiser des tâches communes, comme le contrôle

de site Web, le contrôle de réseau, la défragmentation de disques et la sauvegarde.

 Simuler des applications utilisateurs, par lequel un

script AutoIt pilote une application en lieu et place d'un contrôle manuel pendant le test d'un logiciel.

 NI Requirements Gateway : solution de traçabilité des

exigences qui relie vos documents de développement et de vérification aux exigences formelles stockées dans les documents et les bases de données.

 Notepad ++

 FileZilla

 Axialis

 Copie Ecrans

 Jenkins : intégration continue

 But : Virtualiser la plate-forme de développement

 Virtualisation : simuler l'existence de plusieurs machines

informatiques en utilisant une seule.

 Machine virtuelle illusion d'un appareil

informatique créée par un logiciel d'émulation.

 Simule la présence de ressources

matérielles et logicielles (mémoire, processeur, disque dur, système d'exploitation, pilotes)

 hyperviseur une plate-forme de virtualisation qui permet

à plusieurs systèmes d'exploitation de travailler sur une même machine physique en même temps

 Type 2 : VMware, VirtualBox, VirtualPC, sont quelques

logiciels de virtualisation

 Virtualisation des serveurs est le modèle le plus courant.

Il s'agit de faire fonctionner plusieurs serveurs virtuels sur un ou plusieurs serveurs physiques (hôtes).

 OS moderne simule une machine qui exécute MS-DOS;

 Machine de développement : une machine virtuelle par

plate-forme de développement (PDA, Windows, linux,..)

 Les avantages

 Sécurisation des plates-formes de développement (quelques

 Installation, déploiement et migration facile des machines virtuelles

 Une machine virtuelle par version de LabVIEW : plus de conflit de

 Facilité pour test de driver et logiciel

fichiers à copier) : sauvegarde – retour en arrière possible.

d’une machine physique à une autre (copier – coller)

version

 Les Inconvénients

 Le matériel est virtualisé donc lenteur réseau, port série, USB,…  Le matériel est virtualisé donc difficulté à installer un véritable

 Conseillé d’utiliser une « Grosse » machine physique (8 Go RAM,

 Gestion des licences : une Machine Virtuelle = une licence  Taille sur le disque de la machine virtuelle et de ses snapshots

matériel par exemple matériel National Instruments

processeurs muli-core,

 Logiciel libre par Oracle

 http://fr.wikipedia.org/wiki/TortoiseSVN

 http://fr.wikipedia.org/wiki/Version_d%27un_logiciel

 https://tuleap.net/?utm_source=forge&utm_medium=f

orge&utm_campaign=forge

 http://www.enalean.com/produits/tuleap/

 http://fr.wikipedia.org/wiki/Machine_virtuelle

 https://fr.wikipedia.org/wiki/Jenkins_(informatique)

 ni.com/largeapps

mars 2010 Nanocaractérisation de matériaux pour le CEA 58

 Sujets de réflexion :

 SCC : Base Centralisée VS décentralisée

 SCC : Principe de l’arborescence du dépôt : trunk,

branches, tags

 SCC : LVDiff

 IC : Intégration Continue : Jenkins

Merger

Code Revision

Developer 1

Locked for edit

Checked

Checked

Out

In

Get Latest Version

Code

Repository

Checked

Checked

Checked

Checked

Out

In

Out

In

Developer 2

 Graphical Differencing

• Provides a checklist of changes
• Useful for peer reviews
• Available via command-line

 Base Centralisée VS décentralisée

 Gestion de versions centralisée : un seul dépôt des

versions qui fait référence.

 Simplifie la gestion des versions  mais est contraignant pour certains usages comme le travail

sans connexion au réseau.

 Gestion de versions décentralisée plusieurs dépôts.

 Permet à chacun de travailler à son rythme, de façon

désynchronisée des autres, puis d'offrir un moyen à ces développeurs de s'échanger leur travaux respectifs.

 Ce système est très utilisé par les logiciels libres.

 Avantages de la gestion décentralisée :

 Contributeurs peuvent travailler sans être connecté au

gestionnaire de version ;

 Participation à un projet sans nécessiter les permissions par

un responsable du projet (les droits de commit/soumission peuvent donc être donnés après avoir démontré son travail et non pas avant) ;

 la plupart des opérations sont plus rapides car réalisées en

local (sans accès réseau) ;

 Permet le travail privé pour réaliser des brouillons sans devoir

publier ses modifications et gêner les autres contributeurs ;

 Permet toutefois de garder un dépôt de référence contenant

les versions livrées d'un projet.

 Désavantage de la gestion décentralisée :

 cloner un dépôt est plus long que récupérer une version pour

une gestion de version décentralisée car tout l'historique est copié ;

 il n'y a pas de système de lock (ce qui peut poser des

problèmes pour des données binaires qui ne se fusionnent pas).

 L'intégration continue vérifier à chaque modification de

code source que le résultat des modifications ne produit pas de régression dans l'application développée.

 Modifications de code -> Compiler et tester votre

application.

 Si erreur avertir les développeurs afin qu'ils puissent

tout de suite corriger le problème.

 Suivre la santé de votre projet