Upload
trinhcong
View
220
Download
0
Embed Size (px)
Citation preview
Génie et Architecture des logiciels
E. RAMAT
Université du Littoral - Côte d'Opale
19 novembre 2012
E. Ramat (ULCO) GAL 19 novembre 2012 1 / 136
Déroulement du module
18h de cours
39h de travaux dirigés et pratiques
chaque séance de TD/TP :I un compte rendu en �n de séanceI une note
un projet �nal (24h = 4 jours de 6h)I un travail en groupeI un projet à traiter selon une méthodologie agile (Scrum + TDD + . . . )I une soutenance de retour d'expérience
note du module = 12examen + 1
2(moyenne des notes TD/TP + projet)
E. Ramat (ULCO) GAL 19 novembre 2012 2 / 136
Sommaire
introduction : rappel de Génie Logiciel
développement dirigé par les tests
gestion de versions
qualité de code et mesures
introduction à la métaprogrammation
méthodes agiles
intégration continue
E. Ramat (ULCO) GAL 19 novembre 2012 3 / 136
Introduction
E. Ramat (ULCO) GAL 19 novembre 2012 4 / 136
Motivations du GLMatériel versus logiciel
Systèmes informatiques
80% de logiciel
20% de matériel
Depuis quelques années, le coeur du matériel (processeur principalement) estassuré par quelques fabricants seulement
le matériel est relativement �able
le marché est standardisé
Les problèmes liés à l'informatique sont essentiellement des problèmes de Logiciel.
E. Ramat (ULCO) GAL 19 novembre 2012 5 / 136
Motivations du GLSpéci�cités du logiciel
Un Logiciel
un produit immatériel, dont l'existence est indépendante du support physique
semblable à une oeuvre d'art (roman, partition, . . . )
Un objet technique fortement contraint
fonctionne ou ne fonctionne pas
structure complexe
relève des modes de travail du domaine technique
Un cycle de production di�érent
la reproduction pose peu de problèmes, seule la première copie d'un logiciel aun coût
production à l'unité
semblable au Génie Civil (ponts, routes, . . . )
E. Ramat (ULCO) GAL 19 novembre 2012 6 / 136
Motivations du GLLa crise du logiciel
Étude sur 8 380 projets (Standish Group, 1995)
succès : 16 %
problématique : 53 % (budgets ou délais non respectés, défaut defonctionnalités)
échec : 31 % (abandonnés)
→ le taux de succès décroît avec la taille des projets et la taille des organisations.
Technique ou organisation
la technique ? nécessaire, mais pas si importante que ça !
le VRAI problème di�cile : l'organisation et la gestion :I di�culté de formalisationI multitude de paramètres et de facteursI gestion des humains
E. Ramat (ULCO) GAL 19 novembre 2012 7 / 136
Génie logicielDé�nition
Génie logiciel (software enginnering)
ensemble de moyens (techniques et méthodes) mis en oeuvre pour laconstruction de systèmes informatiques et de logiciels
Questions
comment faire des logiciels de qualité?
qu'attend-on d'un logiciel ?
quels sont les critères de qualité pour un logiciel ?
E. Ramat (ULCO) GAL 19 novembre 2012 8 / 136
Génie logicielQualité : utilité
Dé�nition
Adéquation entre :
le besoin e�ectif de l'utilisateur
les fonctions o�ertes par le logiciel
Solutions
mettre l'accent sur l'analyse des besoins
améliorer la communication (langage commun, démarche participative)
travailler avec rigueur
E. Ramat (ULCO) GAL 19 novembre 2012 9 / 136
Génie logicielQualité : utilisabilité
Dé�nition
E�ectivité, e�cacité et satisfaction avec laquelle des utilisateurs spéci�ésaccomplissent des objectifs spéci�és dans un environnement particulier
facilite d'apprentissage : comprendre ce que l'on peut faire avec le logiciel etsavoir comment le faire
facilite d'utilisation : importance de l'e�ort nécessaire pour utiliser le logicielà des �ns données
Solutions
analyser le mode opératoire des utilisateurs
adapter l'ergonomie des logiciels aux utilisateurs
E. Ramat (ULCO) GAL 19 novembre 2012 10 / 136
Génie logicielQualité : �abilité
Dé�nition
correction, justesse, conformité : le logiciel est conforme à ses spéci�cations,les résultats sont ceux attendus
robustesse, sûreté : le logiciel fonctionne raisonnablement en toutescirconstances, rien de catastrophique ne peut survenir, même en dehors desconditions d'utilisation prévues
Mesures
MTBF : Mean Time Between Failures
disponibilité (pourcentage du temps pendant lequel le système est utilisable)et taux d'erreur (nombre d'erreurs par KLOC - par milliers de lignes de code)
Solutions
utiliser des méthodes formelles couplé à du model checking : notation Z,méthode B, Réseaux de Petri, . . .
des langages et des méthodes de programmation de haut niveau : Ei�el, parexemple
véri�cations et tests : model checking, tests unitaires, . . .
progiciels
E. Ramat (ULCO) GAL 19 novembre 2012 11 / 136
Génie logicielQualité : interopérabilité
Dé�nition
Un logiciel doit pouvoir interagir en synergie avec d'autres logiciels
Solutions
bases de données (découplage données/traitements)
�externalisation� de certaines fonctions en utilisant des �middlewares� avecune API (Application Program Interface) bien dé�nie
standardisation des formats de �chiers (XML, par exemple) et des protocolesde communication (CORBA, XML/RPC, . . . )
Solutions
Rôle fondamental des normes !!!
E. Ramat (ULCO) GAL 19 novembre 2012 12 / 136
Génie logicielQualité : performance
Dé�nition
Les logiciels doivent satisfaire aux contraintes de temps d'exécution
Solutions
logiciels plus simples
veiller à la complexité des algorithmes
machines plus performantes
E. Ramat (ULCO) GAL 19 novembre 2012 13 / 136
Génie logicielQualité : portabilité
Dé�nition
Un même logiciel doit pouvoir fonctionner sur plusieurs machines
Solutions
rendre le logiciel indépendant de son environnement d'exécution
machines virtuelles : Java, Smalltalk, . . .
E. Ramat (ULCO) GAL 19 novembre 2012 14 / 136
Génie logicielQualité : réutilisabilité
Dé�nition
On peut espérer des gains considérables car dans la plupart des logiciels :
80 % du code est récurrent (que l'on retrouve à peu près partout)
20 % du code est spéci�que
Solutions
abstraction et généricité
construction à partir de composants prêts à l'emploi
�Design Patterns�
E. Ramat (ULCO) GAL 19 novembre 2012 15 / 136
Génie logicielQualité : maintenabilité
Constat
un logiciel ne s'use pas
pourtant, la maintenance absobe un très grosse partie des e�orts dedéveloppement
Maintenance corrective
corriger les erreurs : défauts d'utilité, d'utilisabilité, de �abilité, . . .I identi�er la défaillanceI localiser la partie du code responsableI corriger et estimer l'impact d'une modi�cation
Attention !!!I la plupart des corrections introduisent de nouvelles erreursI les coûts de correction augmentent exponentiellement avec le délai de
détection
la maintenance corrective donne lieu à de nouvelles livraisons (release)
E. Ramat (ULCO) GAL 19 novembre 2012 16 / 136
Génie logicielQualité : maintenabilité
Maintenance adaptative
ajuster le logiciel pour qu'il continue à remplir son rôle compte tenu dul'évolution des :
I environnements d'exécution (d'Oracle à PostgreSQL, de PHP à J2EE, . . . )I changement de règles (du Franc à l'Euro, par exemple)
Maintenance perfective
accroître / améliorer les possibilités du logiciel
exemples : les services o�erts, l'interface utilisateur, les performances, . . .
donne lieu à de nouvelles versions
E. Ramat (ULCO) GAL 19 novembre 2012 17 / 136
Génie logicielPrincipes
Généralisation
Regroupement d'un ensemble de fonctionnalités semblables en une fonctionnalitéparamétrable (généricité, héritage)
Structuration
Façon de décomposer un logiciel (utilisation d'une méthode bottom-up outop-down)
Abstraction
Mécanisme qui permet de présenter un contexte en exprimant les élémentspertinents et en omettant ceux qui ne le sont pas
E. Ramat (ULCO) GAL 19 novembre 2012 18 / 136
Génie logicielPrincipes
Modularité
Décomposition d'un logiciel en composants discrets
Documentation
Gestion des documents incluant leur identi�cation, acquisition, production,stockage et distribution
Véri�cation
Détermination du respect des spéci�cations établies sur la base des besoinsidenti�és dans la phase précédente du cycle de vie
E. Ramat (ULCO) GAL 19 novembre 2012 19 / 136
Génie logicielObjectifs
Production de logiciels
mettre en évidence les besoins
aspects organisationnelsI cycles de vie (en V, spirale, . . . )I démarchesI patrons d'organisations
aspects techniquesI qualitéI test (unitaire, fonctionnel, . . . )I spéci�cation et méthodeI design patterns (en M2)
E. Ramat (ULCO) GAL 19 novembre 2012 20 / 136
Génie logicielCycle de vie
Dé�nition
La qualité du processus de fabrication est garante de la qualité du produit.
Production de logiciels
pour obtenir un logiciel de qualité, il faut en maîtriser le processusd'élaboration
la vie d'un logiciel est composée de di�érentes étapes
la succession de ces étapes forme le cycle de vie du logiciel
il faut contrôler la succession de ces di�érentes étapes
E. Ramat (ULCO) GAL 19 novembre 2012 21 / 136
Génie logicielCycle de vie
E. Ramat (ULCO) GAL 19 novembre 2012 22 / 136
Génie logicielCycles de vie
Etude de faisabilité
déterminer si le développement proposé vaut la peine d'être mis en oeuvre,compte tenu des attentes et de la di�culté de développement
étude de marché : déterminer s'il existe un marché potentiel pour le produit
Spéci�cation
déterminer les fonctionnalités que doit posséder le logiciel
collecte des exigences : obtenir de l'utilisateur ses exigences pour le logiciel
analyse du domaine : déterminer les tâches et les structures qui se répètentdans le problème
E. Ramat (ULCO) GAL 19 novembre 2012 23 / 136
Génie logicielCycles de vie
Organisation du projet
déterminer comment on va développer le logiciel
analyse des coûts : établir une estimation du prix du projet
plani�cation : établir un calendrier de développement
assurance qualité du logiciel : déterminer les actions qui permettront des'assurer de la qualité du produit �ni
répartition des tâches : hiérarchiser les tâches et sous-tâches nécessaires audéveloppement du logiciel
E. Ramat (ULCO) GAL 19 novembre 2012 24 / 136
Génie logicielCycles de vie
Conception
déterminer la façon dont dont le logiciel fournit les di�érentes fonctionnalitésrecherchées
conception générale
conception architecturale : déterminer la structure du système
conception des interfaces : déterminer la façon dont les di�érentes parties dusystème agissent entre elles
conception détaillée : déterminer les algorithmes pour les di�érentes partiesdu système
Implémentation
écrire le logiciel
E. Ramat (ULCO) GAL 19 novembre 2012 25 / 136
Génie logicielCycles de vie
Tests
essayer le logiciel sur des données d'exemple pour s'assurer qu'il fonctionnecorrectement
tests unitaires : faire tester les parties du logiciel par leurs développeurs
tests d'intégration : tester pendant l'intégration
tests de validation : pour acceptation par le client
tests système : tester dans un environnement proche de l'environnement deproduction
tests de recette : faire tester par le client sur le site de développement et surle site de production
tests de régression : enregistrer les résultats des tests et les comparer à ceuxdes anciennes versions pour véri�er si la nouvelle n'en a pas dégradé d'autres
E. Ramat (ULCO) GAL 19 novembre 2012 26 / 136
Génie logicielCycles de vie
Livraison
fournir au client une solution logicielle qui fonctionne correctement
installation : rendre le logiciel opérationnel sur le site du client
formation : enseigner aux utilisateurs à se servir du logiciel
assistance : répondre aux questions des utilisateurs
Maintenance
mettre à jour et améliorer le logiciel pour assurer sa pérénité
pour limiter le temps et les coûts de maintenance, il faut porter ses e�orts surles étapes antérieures
E. Ramat (ULCO) GAL 19 novembre 2012 27 / 136
Génie logicielModèle de cycle de vie du logiciel
Modèle en cascade
Réalisation des étapes les unes après les autres avec un retour possible sur lesprécédentes
E. Ramat (ULCO) GAL 19 novembre 2012 28 / 136
Génie logicielModèle de cycle de vie du logiciel
Modèle en V
Mise en correspondance d'une relation entre les étapes descendantes etascendantes
E. Ramat (ULCO) GAL 19 novembre 2012 29 / 136
Génie logicielModèle de cycle de vie du logiciel
Modèle en spirale de Bohem
Production du logiciel par itération ; une itération = une version améliorée dulogiciel ; centré sur la gestion des risques
E. Ramat (ULCO) GAL 19 novembre 2012 30 / 136
Génie logicielModèle de cycle de vie du logiciel
Modèle itératif
Production du logiciel par itération ; une itération = un produit (un artéfact)→ les méthodologies agiles
E. Ramat (ULCO) GAL 19 novembre 2012 31 / 136
Développement dirigé par les tests
E. Ramat (ULCO) GAL 19 novembre 2012 32 / 136
Développement dirigé par les testsIntroduction
Démarche �habituelle�
j'écris tout le code
j'écris ensuite tous les tests (qui se résume souvent à quels exemplesd'utilisation)
je compile
j'exécute les tests
En TP, ça ne marche pas !!!
À la compilation :I tiens, ça ne compile pas ?I je perds beaucoup de temps à comprendre le tas de messages du compilateur
et à modi�er le code.
S'il reste du temps, j'écris les tests !
Panique !
Un code qui ne fait même pas le minimum requis !
E. Ramat (ULCO) GAL 19 novembre 2012 33 / 136
Développement dirigé par les testsDi�érents types de test
Test unitaire
test des unités élémentaires de développement (une fonction, une classe, . . . )
erreurs recherchées : erreurs de codage (structures de contrôles incorrectes,erreur dans le code fonctionnel, . . . )
Test d'intégration
test de l'assemblage des unités
erreurs recherchées : erreurs d'interface + erreurs de codage non détectéespar les tests unitaires
E. Ramat (ULCO) GAL 19 novembre 2012 34 / 136
Développement dirigé par les testsDi�érents types de test
Test système
test du système dans son ensemble, scénarios d'utilisation (use cases)
erreurs recherchées : absence de fonctionnalités ou fonctionnalités mal misesen oeuvre + erreurs non détectées par les tests unitaires et d'intégration.
Test de recette ou acceptation
e�ectué avec le client
E. Ramat (ULCO) GAL 19 novembre 2012 35 / 136
Développement dirigé par les testsModèle de cycle de vie et les tests
Modèle en V
Test en dernière étape : très ine�cace car :
les bugs doivent être détectés au plus tôt
on a tendance à sauter les tests pour tenir les délais
ce qui au �nal coûte très cher en maintenance
Conception puis codage
Peut ne pas marcher :
on peut très bien découvrir au codage un problème qui remet en cause laconception
alors on a perdu son temps et le projet est mis en péril.
E. Ramat (ULCO) GAL 19 novembre 2012 36 / 136
Développement dirigé par les testsModèle de cycle de vie et les tests
Cascade et validation
La seule manière de valider une idée :
c'est de la réaliser et de la faire tester par le client
tant que l'on est au stade des spéci�cations et des modèles : on n'a rien detangible ; on n'a rien à montrer
E. Ramat (ULCO) GAL 19 novembre 2012 37 / 136
Développement dirigé par les tests
Pratiques actuelles
Méthodes agiles, eXtreme programming, Test Driven Development, . . . ont encommun :
rôle fondamental donné au test
cycle de développement incrémental : fonctionnalité par fonctionnalité
cycle de développement itératif : on enchaîne les étapes sur des cycles courts
Avantages
on avance à petit pas testés
si on rate un pas, on n'a raté qu'un pas, sans grosses conséquences.
chaque pas est validé avec le client, fréquemment
E. Ramat (ULCO) GAL 19 novembre 2012 38 / 136
Développement dirigé par les tests
En deux mots
on écrit les tests avant d'écrire le code
une ligne de code n'est écrite que si un test la demande
Avantages immédiats
oblige à ré�échir à ce que fait le code avant de coder
impossible de livrer du code non testé
Autres avantages
La conception du système est aussi dirigé par les tests
il n'est pas �xé a priori
on laisse l'architecture émerger au �l du développement
E. Ramat (ULCO) GAL 19 novembre 2012 39 / 136
Développement dirigé par les tests
Comment commencer ?
on liste les fonctionnalités du système
on choisit la fonctionnalité qui est la plus signi�cative ou la plus prioritaire
on identi�e ses comportements
on choisit un comportement
on écrit un test qui illustre son fonctionnement
et c'est parti !
Le mantra du TDD
Red - Green - Refactor
Red : le test échoue (normal ! on n'a pas encore écrit le code)
Green : le test passe (on a écrit le code qui satisfait le test et uniquement letest !)
Refactor : on �réusine� (ou refactoring) (on améliore le code)
E. Ramat (ULCO) GAL 19 novembre 2012 40 / 136
Développement dirigé par les tests
Plus précisemment
1. écrire un test ;
2. l'exécuter et constater que la barre est rouge ;
3. écrire le code qui permet de faire passer le test (et rien que ce code) ;
4. lancer le test et véri�er qu'il passe (barre verte) ;
5. réusiner le code.
E. Ramat (ULCO) GAL 19 novembre 2012 41 / 136
Développement dirigé par les tests
Pourquoi écrire un seul test à la fois ?
principe du �petit pas�
le test représente un comportement
on ne passe au comportement suivant que lorsque le précédent a été validé
validé = �implanté et le test passe�
Pourquoi ne pas écrire tout le code fonctionnel d'un coup ?
on n'écrit que le code qui a besoin d'être validé par un test
très di�cile pour les néophytes
Sinon on risque :
d'introduire du code applicatif non testé
d'ajouter des fonctionnalités inutiles
Exemple : on n'ajoute un accesseur que si on en a besoin pour le test
E. Ramat (ULCO) GAL 19 novembre 2012 42 / 136
Développement dirigé par les tests
Pourquoi exécuter le test avant d'écrire le code ?
pas facile de comprendre la nécessité d'une barre rouge au début
permet de détecter des étourderies type :I constuire le test par copier-coller d'un autre test et oublier de le modi�er (→
barre verte)I oublier d'ajouter la méthode de test dans la suite des tests → test pas exécuté
et barre verte ;
Pour commencer par une barre rouge
En détaillant l'étape 2 et 3 :
2. barre rouge ou le test ne compile peut-être pas (si la méthode n'a pas étéimplantée du tout) ;
3.a commencer par écrire une méthode minimale qui compile ;
3.b relancer le test, qui cette fois doit échouer
écrire le code qui doit permettre de passer le test
E. Ramat (ULCO) GAL 19 novembre 2012 43 / 136
Développement dirigé par les testsCycle
E. Ramat (ULCO) GAL 19 novembre 2012 44 / 136
Développement dirigé par les tests
Pourquoi réusiner ?
on cherche d'abord à avoir un code qui fonctionne (= qui passe les tests auvert) ;
ce code peut être un cas particulier pour les besoins du test : on le généralisepuis on resteste ;
ce code peut être redondant ou très laid ;
on factorise (DRY principle - Don't Repeat Yourself ), on améliore, on rend lecode le plus lisible possible → éviter la redondance de code ;
le code a�reux n'est autorisé que le temps de faire passer un test.
E. Ramat (ULCO) GAL 19 novembre 2012 45 / 136
Développement dirigé par les tests
Avantages psychologiques
grâce aux petits pas, on a moins peur d'attaquer une tâche complexe ;
on a le sentiment d'avancer grâce à :I l'alternance rouge - vert ;I aux petits pas.
grâce au code testé :I on est serein ;I on plani�e mieux son travail ;I on évite les paniques de dernière minute.
E. Ramat (ULCO) GAL 19 novembre 2012 46 / 136
Développement dirigé par les tests
Avantages techniques
on passe beaucoup moins de temps à déboguer ;
on a toujours quelque chose à montrer au client (dont des tests) ;
test de non-régression facile ;
l'architecture est testable et de bonne qualité
E. Ramat (ULCO) GAL 19 novembre 2012 47 / 136
Développement dirigé par les testsJUnit
Organisation du code
les tests s'organisent autour de la classe TestCase et des classes Assert dupackage junit.framework (import junit.framework.*)
il su�t de dé�nir une classe héritant de TestCase et de développer desfonctions dont le nom commence par �test�.
TestCase
class MonTest extends TestCase{
public MonTest(String name) { super(name); }
public test1 (){
MaClasse a = new MaClasse ();
assertTrue(a.ma_fonction (2,5) == 0);}
}
E. Ramat (ULCO) GAL 19 novembre 2012 48 / 136
Développement dirigé par les testsJUnit
Le test
le test véri�e que ma_fonction retourne 0 si les paramètres sont égaux à 2 et5 ;
si le test échoue alors l'assertion est fausse et une exception(AssertionFailedError) est levée ;
Utilisation de junit.jar
Modi�cation de la classe $CLASSPATH pour prendre en compte le �chierjunit.jar :$ export CLASSPATH=$CLASSPATH:/usr/share/java/junit.jar
E. Ramat (ULCO) GAL 19 novembre 2012 49 / 136
Développement dirigé par les testsJUnit
La suite des tests
il faut dé�nir une classe qui regroupe les tests
cette classe doit disposer d'une méthode publique et statique �suite� quiretourne un objet Test
dans la méthode, on dé�nit une suite de tests via la classe TestSuite et onajoute
TestSuite
public class AllTests {public static Test suite() {
TestSuite suite = new TestSuite("Mes tests");
suite.addTest(new TestSuite(MonTest.class ));return suite;
}}
E. Ramat (ULCO) GAL 19 novembre 2012 50 / 136
Développement dirigé par les testsJUnit
L'exécution des tests
les tests sont exécutés par une classe TestRunner
il en existe plusieurs types :I textui : sortie dans la consoleI swingui : sortie dans une fenêtre graphique
TestRunner
On peut ajouter une méthode main dans la classe AllTests
public static void main(String args []){
junit.textui.TestRunner.run(AllTests.suite ());}
TestRunner en console sans dé�nir de main
$ java junit.textui.TestRunner AllTests
E. Ramat (ULCO) GAL 19 novembre 2012 51 / 136
Gestion de versions
E. Ramat (ULCO) GAL 19 novembre 2012 52 / 136
di� & patch
Les gestionnaires de versions s'appuient sur deux principes : les di�érences etl'opération d'appliquer une di�érence sur un �chier :
di� : Comparaison de �chiers ligne par ligneI indique les lignes ajoutées ou suppriméesI peut ignorer les casses, les tabulations, les espacesI option -u pour créer des patchs uni�és, avec plus d'informations.
patch : Utilise la di�érence entre deux �chiers pour passer d'une version àl'autre.
Exemple
$ diff toto.c toto -orig.c > correction.patch$ bzip2 correction.patch$ bzcat correction.patch.bz2 | patch -p 0 toto.c
E. Ramat (ULCO) GAL 19 novembre 2012 53 / 136
di� & patch
toto.orig.c
#include <stdio.h>
int main(int argc , char *argv []){
printf("Hello world !\n");return 0;
}
toto.c
#include <stdio.h>#include <stdlib.h>
int main(int argc , char *argv []){
printf("Hello world !\n");return EXIT_SUCCESS;
}
di� toto.orig.c toto.c
1a2> #include <stdlib.h>6c7< return 0;---> return EXIT_SUCCESS;
E. Ramat (ULCO) GAL 19 novembre 2012 54 / 136
di� & patch
toto.orig.c
#include <stdio.h>
int main(int argc , char *argv []){
printf("Hello world !\n");return 0;
}
toto.c
#include <stdio.h>#include <stdlib.h>
int main(int argc , char *argv []){
printf("Hello world !\n");return EXIT_SUCCESS;
}
di� -u toto.orig.c toto.c
--- toto.c 2010 -09 -20 15:36:22.000000000 +0200+++ toto.orig.c 2010 -09 -26 19:45:51.000000000 +0200@@ -1,8 +1,9 @@#include <stdio.h>
+#include <stdlib.h>
int main(int argc , char *argv []){
printf("Hello world !\n");- return 0;+ return EXIT_SUCCESS;}
E. Ramat (ULCO) GAL 19 novembre 2012 55 / 136
di� & patch : patch uni�é
Les di� peuvent comparer des hiérarchies de �chiers (option -r) :
Exemple
$ cp -r linux -2.6.35 linux -2.6.35 - orig$ cd linux -2.6.35$ vim [...]$ cd ..$ diff -r -u linux -2.6.35 - orig linux -2.6.35 > \
network -driver -b44.patch$ gzip -9 network -driver -b44.patch
$ cd linux -2.6.35$ zcat network -driver -b44.patch.gz | patch -p 1
L'option -p permet de laisser les chemins du patch au complet 0, en supprimant lepremier dossier 1, etc.
E. Ramat (ULCO) GAL 19 novembre 2012 56 / 136
Principe de base
Un gestionnaire de version, à partir des patchs, permet de :
conserver toutes les versions de tous les �chiers
conserver toutes les arborescences de �chiers
conserver les informations de qui écrit un patch, quelles sont sesmodi�cations, ses motifs : commits
permettre d'identi�er une arborescence de version de �chiers : branches
fournir des outils pour gérer le tout.
E. Ramat (ULCO) GAL 19 novembre 2012 57 / 136
BranchesDé�nitions
Quelques dé�nitions :
un tronc représente la version centrale du développement
une branche, une bifurcation du tronc ou d'une branche.
la tête (HEAD), le sommet d'une branche
l'index, ce qui n'est pas encore ajouté ou supprimé (après le HEAD)
Ici, 8 commits en 3 branches, donc trois têtes, a51, a6 et a31.
E. Ramat (ULCO) GAL 19 novembre 2012 58 / 136
BranchesFusion ou merge de branches
Quelques dé�nitions :
fusionner des patchs de plusieurs branches.
E. Ramat (ULCO) GAL 19 novembre 2012 59 / 136
Commandes générales
Les actions communes disponibles sur tous les gestionnaires de versions :
add : ajouter un �chier au prochain commit
remove : supprimer un �chier mais pas son historique et au prochain commit
log : historique d'un �chier ou d'une branche
di� : di�érence entre deux versions de �chier ou entre deux branches
commit : envoyer un patch au gestionnaire de versions
tag : poser un label sur un ensemble de version de �chiers
E. Ramat (ULCO) GAL 19 novembre 2012 60 / 136
Dépôts centralisés
E. Ramat (ULCO) GAL 19 novembre 2012 61 / 136
Dépôts centralisés
CVS ou Subversion
Toutes les versions des �chiers sont entreposées dans un unique dépôtaccessible aux développeurs (et contributeurs si autorisés).
Les clients ne travaillent que sur une partie des données, en général, unesimple branche et uniquement la tête du développement.
Impossibilité de travailler �O�-line �, sans faire de mass de commit.
Inclure un contributeur nécessite d'ouvrir le dépôt en écriture → besoinsd'étendre le cercle de con�ance pour un nouveau développeur sur le projet.
Chaque changement de branches nécessite un téléchargement de l'ensembledes données de la branche.
Mais pourquoi l'utiliser ?
Que des inconvénients → méthode historique des gestionnaires de versions - vieillelogique de développement de codes fermés / sécurisés / cachés etc.
E. Ramat (ULCO) GAL 19 novembre 2012 62 / 136
Dépôts décentralisés
E. Ramat (ULCO) GAL 19 novembre 2012 63 / 136
Dépôts décentralisés
Arch, Bazar-Ng, Git, monotone etc.
Chaque client possède l'ensemble des �chiers dans son dépôt localI Possibilité de travailler �O�-Line� (à la plage, à la montagne, dans le train,
. . . ).
Chaque client possède l'ensemble des �chiers dans son dépôt local
Aucune action du client ne nécessitent un accès au dépôt distant, sauf :I la mise à jour du dépôt local depuis l'extérieurI l'envoi d'information.
Le changement de branche est rapide et est donc, une des méthodes dedéveloppement : utiliser les branches
Les dépôts se gèrent par méls par un intégrateur, par un ensemble de dépôts,ou un dépôt centralisé.
Mais pourquoi est-ce si peu utilisé ?
Bonne question :)
E. Ramat (ULCO) GAL 19 novembre 2012 64 / 136
VCS décentraliséBranches locales, branches distantes
Dépôt décentralisé
Un dépôt en VCS décentralisé possède deux types de branches :
Les branches locales :I accessibles uniquement au développeur localI peuvent être fusionnées entre elleI peuvent être copiés sur une branche distante d'un dépôt distant
Les branches distantes :I pointent sur des dépôts distants en lecture et/ou écritureI doivent être mis à jour sur le dépôt local pour mettre à jour leur état
E. Ramat (ULCO) GAL 19 novembre 2012 65 / 136
VCS décentraliséCon�its ?
Les con�its sur dépôt centralisé
au téléchargement des modi�cations
Les con�its sur dépôt décentralisés
lors des fusions de branches : locale/locale, locale/distante ou distante/locale.
lors de l'application d'un patch.
E. Ramat (ULCO) GAL 19 novembre 2012 66 / 136
L'avant Git
Historique :
2001 - Linux est développé sur CVS
2002 à 2005 - Linux est développé avec un logiciel non-libre, Bitkeeper maiscelui-ci devient non utilisable pour Linux en 2004
2005 - Création de Git par Linus Thorvalds
avril 2005 - Utilisation de Git pour le développement de Linux.
Quelques précisions :
Certainement le gestionnaire de versions le plus rapide à appliquer des patchs
Git est distribué sous licence GNU GPL 2
Portable sur la plupart des Unix et Linux, MS Windows.
E. Ramat (ULCO) GAL 19 novembre 2012 67 / 136
GitQuelques phrases clés
Rôle de Git : stocker des objets et les identi�er par un clé Sha1
Git stocke les �chiers au complet par les di� et les gère comme un systèmede �chiers classiques
I gérer les objets d'assez bas niveauI compacter les objets en paquetI envoyer et recevoir des objets de plusieurs manièresI créer et manger des patchsI interroger les données, di�, grep et log ;I chercher les bugs ou plutôt quand et qui l'a introduit (si si)I importer les projets des autres gestionnaires de versions.
http://www.kernel.org/pub/software/scm/git/docs/
http://progit.org/book/
pour le reste, les manpages sont là :)
E. Ramat (ULCO) GAL 19 novembre 2012 68 / 136
SHA-1 ?Secure Hash Algorithm
SHA-1 est une fonction de hachage cryptographique de la NSA
fonction de hachage → grand ensemble de données en un ensemble plus petitet unique (à quelques 280 clés di�érentes)
Génère un � hash � de 160 bits.
Exemple
$ echo a > toto$ sha1sum toto3f786850e387550fdab836ed7e6dc881de23001b toto$ echo a >> toto$ sha1sum totod7c8127a20a396cff08af086a1c695b0636f0c29 toto
E. Ramat (ULCO) GAL 19 novembre 2012 69 / 136
Les typesRôle de Git : stocker des objets et les identi�er par un clé Sha1
Git utilise quatre types d'objets :
Blobs :I un blob représente le contenu d'un �chierI un blob par révision du �chierI pas de relation entre le nom ou l'emplacement du �chier et le blobI si un �chier est renommé, pas de changement dans le blob.
Trees :I les trees sont des ensembles de pointeurs vers des blobsI un tree associe les noms des �chiers et les pointeurs de blobsI un tree décrit l'état d'une hiérarchie de dossiers à un moment donnéI un tree peut pointer vers d'autres trees a�n de mémoriser l'arborescence de
�chiers.
E. Ramat (ULCO) GAL 19 novembre 2012 70 / 136
Les typesRôle de Git : stocker des objets et les identi�er par un clé Sha1
Commits :I un commit pointe vers un arbre dont on souhaite sauver l'étatI un commit pointe vers un ou plusieurs autres commits pour constituer
l'historique et les branches ;I un commit est associé à une chaîne de caractères décrivant son actionI un commit possède un auteur et un committer.
Tags :I le tag pointe vers un des objets précédents et porte un nom et une signature.
E. Ramat (ULCO) GAL 19 novembre 2012 71 / 136
Les typesPetit exemple
Par exemple, pour un petit projet de quelques blobs :
Remarque
Les trees et les commits sont contenus dans les blobs.
E. Ramat (ULCO) GAL 19 novembre 2012 72 / 136
Développeur seulLes commandes à connaître
Les commandes à connaître pour n'importe quelle utilisation de Git :
Commandes Rôlegit init création d'un dépôtgit log liste l'historiquegit status l'état du dépôt courantgit add, rm, mv ajoute, supprime ou déplace un �chier ou dossiergit commit création d'un commit
git reset suppression de modi�cation ou de commit
git merge fusion de branchesgit rebase ré-écriture d'une branchegit tag poser ou supprimer des tag
E. Ramat (ULCO) GAL 19 novembre 2012 73 / 136
Développeur seulCréation d'un nouveau dépôt
La création d'un dépôt, une commande simple
mkdir monprojetcd monprojetgit init
Création d'un dépôt Git sur un projet existant
cd monprojetgit initgit add .git commit -a
Création d'un dossier monprojet/.git
E. Ramat (ULCO) GAL 19 novembre 2012 74 / 136
Développeur seulPetit exemple
Petit �chier jouet : `toto.c'
#include <stdio.h>
int main(int argc , char *argv []){
printf("Hello world !\n");return 0;
}
Création du dépôt et du premier commit
mkdir projetcp /tmp/toto.c projetcd projectgit initgit add toto.cgit commit -a -m "Mon premier commit"
E. Ramat (ULCO) GAL 19 novembre 2012 75 / 136
Développeur seulgit branch, git log
Sur quelle branche locale se trouve t-on ?
git branch -av
* master 4f21f0b Mon premier commit
Histoire du dépôt
git log
commit 4f21f0bddfef0e34e9652ec2f802651d6e435ee1Author: Gauthier Quesnel <[email protected] >Date: Mon Sep 20 15:37:05 2010 +0200
Mon premier commit
E. Ramat (ULCO) GAL 19 novembre 2012 76 / 136
Développeur seulgit di�
Apportons des modi�cations à toto.c
#include <stdio.h>#include <stdlib.h>
int main(int argc , char *argv []){
printf("Hello world !\n");return EXIT_SUCCESS;
}
git di�
#include <stdio.h>+#include <stdlib.h>
int main(int argc , char *argv []){
printf("Hello world !\n");- return 0;+ return EXIT_SUCCESS;}
git status
# On branch master# Changed but not updated:# (use "git add <file >..." to# update what will be committed)# (use "git checkout -- <file >..."# to discard changes in working# directory)# modified: toto.c
E. Ramat (ULCO) GAL 19 novembre 2012 77 / 136
Développeur seulgit commit
Il reste à créer le nouveau commit
git commit -a -m "Plus de portabilite"git log
commit 7127 b286cd3b110bb07eed038ee0dfabf4dfbd00Author: Gauthier Quesnel <[email protected] >Date: Mon Sep 20 17:34:41 2010 +0200
Plus de portabilite
commit 4f21f0bddfef0e34e9652ec2f802651d6e435ee1Author: Gauthier Quesnel <[email protected] >Date: Mon Sep 20 15:37:05 2010 +0200
Mon premier commit
E. Ramat (ULCO) GAL 19 novembre 2012 78 / 136
Développeur seulAjoutons un Make�le
Make�le
all: toto
toto: toto.ogcc -o toto toto.o
toto.o: toto.cgcc -c toto.c -Wall -Wextra -pedantic -O2
Ajout au dépôt
git add Makefilegit commit -a -m "Ajout d'un Makefile"
E. Ramat (ULCO) GAL 19 novembre 2012 79 / 136
Développeur seulgit checkout
a0 a1 a2 a3 a4 a5
git commit -a -m "a0"git commit -a -m "a1"git commit -a -m "a2"git commit -a -m "a3"git commit -a -m "a4"git commit -a -m "a5"
E. Ramat (ULCO) GAL 19 novembre 2012 80 / 136
Développeur seulgit checkout
a0 a1 a2 a3 a4 a5
b0 b1
git commit -a -m "a0"git commit -a -m "a1"
git checkout -b b a # on copie la branche a en bgit commit -a -m "b0" # on commit b0 puisgit commit -a -m "b1" # puis b1
git checkout a # on passe sur la branche a (en a1 donc).git commit -a -m "a2"git commit -a -m "a3"git commit -a -m "a4"git commit -a -m "a5"
E. Ramat (ULCO) GAL 19 novembre 2012 81 / 136
Développeur seulgit checkout
a0 a1 a2 a3 a4 a5
b0 b1
c0 c1 c2
[...]git commit -a -m "b1" # puis b1
git checkout -b c b # on copie b en cgit commit -a -m "c0" # on commit ..git commit -a -m "c1"git commit -a -m "c2"
git checkout a # on passe sur la branche a (en a1 donc).git commit -a -m "a2"git commit -a -m "a3"[...]
E. Ramat (ULCO) GAL 19 novembre 2012 82 / 136
Développeur seulRésumons
git checkout permet
de créer des branches locales
de se déplacer entre les branches locales
Autres possibilités sur les branches locales
comment les supprimer ?I git branch -D ou git branch -d
comment les fusionner ?I git merge
comment modi�er l'historique ?I git rebase
comment modi�er les commits récents ?I git reset pour supprimer ou se mettre dans un étatI git commit �amend pour modi�er le dernier commit
E. Ramat (ULCO) GAL 19 novembre 2012 83 / 136
Développeur seulAccès aux commits
références références ?HEAD le sommet de la brancheHEAD∼x le xe commit depuis le sommetsha1 directement la clé sha1tag un tag posé sur un commitbranche une autre branche
$ git diff HEAD ~1.. HEAD~3 # sens important$ git log HEAD ~3.. HEAD~1 # sens important$ git log v1 .0.2.. v1.8.7 # depuis les tags$ git diff 57 bf1d95e7768f1ccb12d646c1b31d91a5fe8717 ..HEAD ~27$ git diff # diff entre HEAD et index$ git log # log entre HEAD et commit 0
E. Ramat (ULCO) GAL 19 novembre 2012 84 / 136
Développeur seulSupprimons des modi�cations
git reset −−hard : suppression des modi�cations en cours sur la branchelocale (la commande git di� ne donnera plus de résultat).
git reset −−hard ref : suppression des modi�cations en cours (dansl'index) et de tous les commits pour arriver dans l'état ref.
git reset −−soft ref : toutes les modi�cations dans l'index et tous lescommits pour arriver dans l'état ref sont supprimés mais les modi�cationssont laissées dans l'index.
E. Ramat (ULCO) GAL 19 novembre 2012 85 / 136
Développeur seulSupprimons des modi�cations
#include <stdio.h>#include <stdlib.h>#include <Win32.h>
int main(int argc , char *argv []){
printf("Hello world !\n");return EXIT_SUCCESS;
}
git reset −−hard
$ git diff
#include <stdlib.h>+#include <Win32.h>
int main(int argc , char *argv[)
$ git reset --hard$ git diff
~
E. Ramat (ULCO) GAL 19 novembre 2012 86 / 136
Développeur seulSupprimons des modi�cations
#include <stdio.h>#include <stdlib.h>#include <Win32.h>
int main(int argc , char *argv []){
printf("Hello world !\n");return EXIT_SUCCESS;
}
git reset −−hard HEAD∼1
$ git commit -a -m "Ajout d'un mauvais include"$ git reset --hard HEAD~1$ git log HEAD~1commit 7127 b286cd3b110bb07eed038ee0dfabf4dfbd00Author: Gauthier Quesnel <[email protected] >Date: Mon Sep 20 17:34:41 2010 +0200
Plus de portabilite
E. Ramat (ULCO) GAL 19 novembre 2012 87 / 136
Développeur seulSupprimons des modi�cations
#include <stdio.h>#include <stdlib.h>#include <Win32.h>
int main(int argc , char *argv []){
printf("Hello world !\n");return EXIT_SUCCESS;
}
git reset −−hard HEAD∼1
$ git commit -a -m "Ajout d'un mauvais include"$ git reset --hard HEAD~1$ git log HEAD~1commit 7127 b286cd3b110bb07eed038ee0dfabf4dfbd00Author: Gauthier Quesnel <[email protected] >Date: Mon Sep 20 17:34:41 2010 +0200
Plus de portabilite
E. Ramat (ULCO) GAL 19 novembre 2012 88 / 136
Développeur seulSupprimons des modi�cations
#include <stdio.h>#include <stdlib.h>#include <Win32.h>
int main(int argc , char *argv []){
printf("Hello world !\n");return EXIT_SUCCESS;
}
git reset −−soft HEAD∼1
$ git commit -a -m "Ajout d'un mauvais include"$ git reset --soft HEAD~1$ git diff#include <stdlib.h>
+#include <Win32.h>
$ git commit -a -m "Ajout d'un mauvais include 2"Author: Gauthier Quesnel <[email protected] >Date: Mon Sep 20 17:34:41 2010 +0200
Ajout d'un mauvais include 2
E. Ramat (ULCO) GAL 19 novembre 2012 89 / 136
Développeur seulgit merge : fusionner des branches
a0 a1 a2 a3 a4 a5
b0 b1
$ git checkout a # HEAD = a5
a0 a1 a2 a3 a4 a5
b0 b1
merge
$ git merge b # ajout d'un commit de merge
E. Ramat (ULCO) GAL 19 novembre 2012 90 / 136
Développeur seulgit merge : fusionner des branches
a0 a1 a2 a3 a4 a5
b0 b1
$ git checkout a # HEAD = a5
a0 a1 a2 a3 a4 a5
b0 b1
merge
$ git merge b # ajout d'un commit de merge
E. Ramat (ULCO) GAL 19 novembre 2012 90 / 136
Développeur seulgit rebase : réécrire l'histoire
a0 a1 a2 a3 a4 a5
b0 b1
$ git checkout a # HEAD = a5
a0 a1
b0 b1
a′2 a′3 a′4 a′5
$ git rebase b # modifie les commits de l'histoire de la branche# a pour intégrer à l'origine du fork les commit# de b
Pas de changement : BHEAD = b1 et AHEAD = a′5
E. Ramat (ULCO) GAL 19 novembre 2012 91 / 136
Développeur seulgit rebase : réécrire l'histoire
a0 a1 a2 a3 a4 a5
b0 b1
$ git checkout a # HEAD = a5
a0 a1
b0 b1
a′2 a′3 a′4 a′5
$ git rebase b # modifie les commits de l'histoire de la branche# a pour intégrer à l'origine du fork les commit# de b
Pas de changement : BHEAD = b1 et AHEAD = a′5
E. Ramat (ULCO) GAL 19 novembre 2012 91 / 136
Développeur seulgit tag : poser des tags
Poser des tags : plutôt que de parler sha1 couramment :
6c37cea2db3e4612ab080d7455c13609763767fceeabc7cc8d9b09a49be8b994fe0ff55058685c112beae21d56312f2b867729e896083201b3b10bea051 de86f330578dc229a170b1f7b267ee6bd7c88
Nous préférons poser des drapeaux ou tags sur les commits :
git tag v1.0.2 # pour ajouter un tag sur le HEAD
git tag v1.0.1 051 de86f330578dc229a170b1f7b267ee6bd7c88
git tag # pour lister les tags
git tag -d v1.0.2 # pour supprimer un tag
E. Ramat (ULCO) GAL 19 novembre 2012 92 / 136
Participer à un projet
Les commandes à connaître en plus pour participer à un projet disposant d'undépôt distant :
Commandes Rôlegit clone cloner un dépôt distantgit remote manipulation des branches distantesgit push envoyer des commits sur une branche d'un dépôt distantgit fetch récupérer des commits sur une branche distantegit format-patch récupérer des commits sur une branche distante
E. Ramat (ULCO) GAL 19 novembre 2012 93 / 136
Participer à un projetgit clone
La commande la plus simple : git clone
Quelques exemples
# Copier un depot Git depuis un acces au systeme de fichiergit clone /home/user/git/monprojet
# Copier un depot Git depuis le protocole Gitgit clone git://git.kernel.org/pub/scm/git/git.git
# Copier un depot Git depuis le protocole httpgit clone http ://git.kernel.org/pub/scm/git/git.git
# Copier un depot Git depuis le protocole ftpgit clone https :// git.kernel.org/pub/scm/git/git.git
# Copier un depot Git depuis le protocole ssh ,# necessite utilisateur et mot de passegit clone ssh:// [email protected]:port/home/~usern/git/myproject
# Git fonctionne egalement avec rsync ou ftp
E. Ramat (ULCO) GAL 19 novembre 2012 94 / 136
Participer à un projetgit remote
La commande git remote permet de manipuler les dépôts distants :
# une branche locale$ git branch -v* master 7127 b28 Plus de portabilité
# aucun depot distant$ git remote
# on ajoute un depot `depot ' distant en lecture/ecriture par ssh$ git remote add depot ssh :// [email protected]/home/user/git/prg
# le depot distant `depot ' est bien disponible$ git remote -vdepot ssh:// [email protected]/home/user/git/prg (fetch)depot ssh:// [email protected]/home/user/git/prg (push)
git remote permet de changer l'URL, renommer ou supprimer un dépôt distantmais aussi nettoyer les branches d'un dépôt distant.
E. Ramat (ULCO) GAL 19 novembre 2012 95 / 136
Participer à un projetgit fetch
Pour récupérer les modi�cations qui ont lieu sur un dépôt :
$ git fetch depot # telecharge tous les commits# tags etc. de toutes les branches
$ git merge depot/master # reste a fusionner les branches
$ git rebase depot/master # ou a changer l'histoire
E. Ramat (ULCO) GAL 19 novembre 2012 96 / 136
Participer à un projetgit init
Créons un dépôt Git dans le dossier /tmp :
$ cd /tmp # on se place dans le bon dossier$ GIT_DIR=copie.git git init # on demande la creation d'un depot
# accessible a distance$ cd copie.git$ ls -1branches/configdescriptionHEADhooks/ # des scriptsinfo/objects/ # tous les fichiers `tree ', `blob ', `commit ' et `tag 'refs/ # les branches et les tags disponibles
E. Ramat (ULCO) GAL 19 novembre 2012 97 / 136
Participer à un projetgit push
Di�usons nos commits :
$ cd $HOME/monprojet$ git remote add origin /tmp/copie.git$ git push origin master:masterCounting objects: 6, done.Delta compression using up to 2 threads.Compressing objects: 100% (4/4), done.Writing objects: 100% (6/6) , 657 bytes , done.Total 6 (delta 0), reused 0 (delta 0)Unpacking objects: 100% (6/6) , done.To /tmp/copie.git* [new branch] master -> master
Avec:
origin : le nom du dépôt distant accessible en écriture
master : le nom de la branche locale source de la copie
master : le nom de la branche distante, destination de la copie
E. Ramat (ULCO) GAL 19 novembre 2012 98 / 136
Participer à un projetgit format-patch
Créons des patchs pour l'intégrateur
git format -patch -2 # creation de deux patchs issus# de la tete du depot locale
0001-Mon -premier -commit.patch0002-Plus -de-portabilit.patch
Reste à envoyer ces �chiers à l'intégrateur qui pourra ou non, accepter vos patchs.
E. Ramat (ULCO) GAL 19 novembre 2012 99 / 136
Intégrateur
Les commandes à connaître en plus pour l'intégrateur :
Commandes Rôlegit am appliquer des patchs
E. Ramat (ULCO) GAL 19 novembre 2012 100 / 136
Intégrateurgit am
Quel travail di�cile :
git am 0001-Mon -premier -commit.patchgit am 0002-Plus -de-portabilit.patch
# ougit am *.patch
Il peut se donner du travail :
git am 0001-Mon -premier -commit.patch # applique le patchvim hello.c # modifie un fichiergit commit -a --amend # ajout ses modifications
# au commit courantgit format -patch -1 # genere un fichier patch
# Et zou , demande si le patch est bon au contributeur# original.mutt [email protected] -a 0001-Mon -premier -commit.patch < /dev/null
E. Ramat (ULCO) GAL 19 novembre 2012 101 / 136
IntégrateurInitiation d'un dépôt Git en ssh
côté serveur (ssh)
ssh -p port [email protected] $HOMEmkdir gitcd gitexport GIT_DIR=mondepot.gitgit init --barecd vle -dev.gitchmod a+x hooks/post -updatetouch git -daemon -export -ok
côté client
cd monprojetgit remote add origin \
ssh :// [email protected] \:port \/home/login/git/mondepot.git
git push origin master:master
E. Ramat (ULCO) GAL 19 novembre 2012 102 / 136
IntégrateurManipulation des branches distantes
Une seule commande git push
$ git push depot src:dest # copie branche locale sur# la branche distante
$ git push depot :dest # supprime du depot la# branche distante dest
$ git push depot +src:dest # copie branche locale sur# la branche distante# en forçant (aucune# verification)
E. Ramat (ULCO) GAL 19 novembre 2012 103 / 136
Développeur seul
Work�ow du développeur seul et sans branche
init edit
commit
Notes :
init = git init
edit = git add, git rm, git mv + édition des �chiers
commit = git commit -a
E. Ramat (ULCO) GAL 19 novembre 2012 104 / 136
Développeur seul
Work�ow du développeur seul avec un dépôt distant
init edit commit
push
Note :
Le développeur n'est pas obligé de faire des push à chaque commit.
E. Ramat (ULCO) GAL 19 novembre 2012 105 / 136
Contributeur
Work�ow du contributeur d'un projet externe
clone edit commit patch
fetchrebase
Note :
La commande rebase permet de maintenir ses branches locales dans le mêmeétat que le dépôt de l'upstream.
Dans ce work�ow, l'upstream n'accepte que des contributions sous forme depatchs.
E. Ramat (ULCO) GAL 19 novembre 2012 106 / 136
Intégateur
Work�ow d'un intégrateur
init am commit
push
patchreset
mailaccepté
refusé
Note :
Version simpli�ée de l'intégrateur. :)
E. Ramat (ULCO) GAL 19 novembre 2012 107 / 136
Centralisé / DécentraliséQue choisir ?
Gestion de versions centralisée (CVS, Subversion) :I un seul et unique dépôt des version : dépôt de référenceI simpli�cation des versionsI très contraignant pour jouer avec les branchesI toutes les opérations se font en ligne
Gestion de versions décentralisée (Mercurial, Darcs, Bazaar, Git, Monotone,GNU Arch):
I Promu par le LL et le développement communautaire : nouvelle vision de lagestion des versions
I SCM : un outil pour travailler à son rythme,I couper des autres ou désynchroniser,I une énorme facilité d'échange de travaux
E. Ramat (ULCO) GAL 19 novembre 2012 108 / 136
Centralisé / DécentraliséComment gérer son projet ?
L'� éthique hacker � :
Toute information est par nature libre.
Ne pas se �er à l'autorité, promouvoir la décentralisation.
Les hackers peuvent se juger par leurs prouesses, non par d'autres hiérarchiessociales (ce qui permettra à un jeune prodige d'une dizaine d'années derejoindre le groupe).
Art et beauté peuvent être créés avec un ordinateur.
Les ordinateurs peuvent changer et améliorer la vie.
Steven Levy
E. Ramat (ULCO) GAL 19 novembre 2012 109 / 136
Outils externes
Quelques outils autour de Git
gitk : interface graphique pour l'a�chage des logs, commits, branches, tags,etc.
git gui : pareil mais permet les modi�cations du dépôt
giggle : la même chose en Gtk
qgit : a�chage, création et application des patchs.
gitweb : interface web (script perl) pour l'a�chage d'un dépôt Git
gitstats : un générateur de statistiques
E. Ramat (ULCO) GAL 19 novembre 2012 110 / 136
Références
Quelques références utiles
http://git.or.cz/ : les sources de GitI http://www.kernel.org/pub/software/scm/git/docs/everyday.htmlI http://www.kernel.org/pub/software/scm/git/docs/gittutorial.htmlI http://progit.org/book/
http://github.com/ : un service web d'hébergement de dépôt Git
http://www.sourceforge.net/ : idem mais pas centré sur Git
E. Ramat (ULCO) GAL 19 novembre 2012 111 / 136
Métrique de qualité de logiciel
E. Ramat (ULCO) GAL 19 novembre 2012 112 / 136
Métrique de qualité de logicielIntroduction
Dé�nitions
mesure : indication quantitative de l'étendue, quantité, dimension, capacitéou taille d'un attribut de produit ou processus
mesurement : acte de détermination d'une mesure
métrique (IEEE Std. 610.12) :I mesure quantitative du degré avec lequel un système, composant, ou processus
possède un attribut donnéI peut lier des mesures individuelles
indicateur : métrique(s) donnant une indication sur le processus, projet, ouproduit
E. Ramat (ULCO) GAL 19 novembre 2012 113 / 136
Métrique de qualité de logicielIntroduction
Objectifs
identi�er les situations pour le développement ou l'amélioration du processusde maintenance (actions préventives ou correctives)
asé sur l'accumulation de métriques concernant la performance des équipes,unités, etc . . .
Métriques de produit
Mesure des caractéristiques de produit : complexité et caractéristiques de laconception
E. Ramat (ULCO) GAL 19 novembre 2012 114 / 136
Métrique de qualité de logicielMétrique de produit
Mesures de la taille (volume) du logiciel
KLOC - mesure classique de la taille du logiciel en millier de lignes de code
dépendant du langage
dépendant du style de programmation
di�cile à prédire avant que le code ne soit produit
Complexité structurelle / complexité des données
Mesurer la complexité des modules d'un programme en fonction des liens qu'ilsentretiennent. Pour chaque module, on utilise :
fin(m) est le nombre de �ux d'information entrant d'un module
fout(m) est le nombre de �ux d'information sortant d'un module
IF4i = Wi (fout fin)2 avec Wi est le poids du module calculé en fonction du
KLOC
IF4 =N∑i=1
IF4i
E. Ramat (ULCO) GAL 19 novembre 2012 115 / 136
Métrique de qualité de logicielMétrique de produit
CBO : Coupling Between Object classes
CBO : nombre de classes couplées
Deux classes sont couplées si les méthodes déclarées dans l'une utilisent desméthodes de l'autre ou instancie des variables dé�nies dans l'autre
Le relation est symétrique : si la classe A est couplée à B alors B est coupléeà A
WMC : Weighted Methods per Class
Calculée sur un ensemble de n classes contenant chacune Mi méthodes
WMC = 1n
∑n
i=0 ciMi
avec ci est la complexité de la méthode
deux variantes :I où la complexité ci est égale à 1I où seules les méthodes publiques sont prises en compte
E. Ramat (ULCO) GAL 19 novembre 2012 116 / 136
Métrique de qualité de logicielMétrique de produit
DIT (Depth of Inheritance Tree)
Distance maximale entre un noeud (une classe) et la racine de l'arbred'héritage de la classe concernée
Cette distance est calculée pour toutes les classes
NOC : Number of children
Nombre d'enfants dans l'arbre d'héritage par rapport à une classe donnée
Mesure du niveau de factorisation
E. Ramat (ULCO) GAL 19 novembre 2012 117 / 136
Métrique de qualité de logicielMétrique de produit
MVG : McCabe's Cyclomatic Complexity
Métrique la plus utilisée après le nombre de lignes de code d'une méthode
Mise en évidence la complexité structurelle du code :I On produit un graphe de contrôle qui représente un code ou on calcule le
nombre de points de décisions (if, for, while, case, ...)I C = π + 1
E. Ramat (ULCO) GAL 19 novembre 2012 118 / 136
Introduction à la métaprogrammationIntroduction
C'est quoi la métaprogrammation ?
c'est un programme qui produit des programmes
par exemple, yacc, un compilateur de compilateurs
les concepts de base :I le métalangage : le langage qui permet d'exprimer les règles de génération de
programmes (en Yacc, on utilise des grammaires et des fragments de code C,par exemple)
I les métadonnées : les données pour la génération de code
En Java : �Re�ection�
l'introspection (re�ect)
le chargement dynamique de classes
En C++: �template metaprogramming�
le métalangage : les templates
les métadonnées : les paramètres des templates
E. Ramat (ULCO) GAL 19 novembre 2012 119 / 136
Introduction à la métaprogrammationIntroduction
Pourquoi la métaprogrammation ?
produire des programmes génériques : qui sont capables de construire desnouveaux types, des nouvelles fonctions
optimiser des calculs mathématiques (déplier des calculs matriciels)
Factoriel en templates C++
template < long N >struct Factorial {
enum { value = N * Factorial < N - 1 >::value };};
template < >struct Factorial < 0 > {
enum { value = 1 };};
const long x = Factorial < 5 >::value;
E. Ramat (ULCO) GAL 19 novembre 2012 120 / 136
Introduction à la métaprogrammationIntroduction
// Without reflectionnew Foo (). hello ();
// With reflectionClass <?> clazz = Class.forName("Foo");clazz.getMethod("hello"). invoke(clazz.newInstance ());
E. Ramat (ULCO) GAL 19 novembre 2012 121 / 136
Introduction à la métaprogrammationRappel sur les templates en C++
Dé�nition 1
La généricité a pour but de paramétrer les classes ou les fonctions de manière à nepas à avoir à réécrire une classe alors que seul le type d'un attribut change, parexemple.
Dé�nition 2
Les templates sont des classes ou des fonctions dépendants d'un certain nombrede paramètres (type ou valeur).
E. Ramat (ULCO) GAL 19 novembre 2012 122 / 136
Introduction à la métaprogrammationRappel sur les templates en C++
Dé�nition 3
Une dé�nition d'une classe template s'e�ectue à l'aide du mot-clé template etd'une liste de paramètres.
template <class T> class A { ... };
La classe A peut utiliser T pour remplacer le type d'une donnée membre ou letype d'un argument d'une fonction membre ou le type de la valeur retournéepar une fonction membre ;
Une fois dé�nie, la classe template A pourra être instanciée avec un typeparticulier ;
La classe A ne peut pas être utilisée sans être instanciée.
A<int > x; ou A<B> y;
E. Ramat (ULCO) GAL 19 novembre 2012 123 / 136
Introduction à la métaprogrammationRappel sur les templates en C++
Un template peut dépendre de plusieurs paramètres ;
template <class T, class U> class A { ... };
Certains de ces paramètres peuvent être valués (int ou long);
template <class T, int size > class A { ... };const int n = 50;A < int , 10 > x; // instantiation par une valeurA < int , n > y; // instantiation par une variable const
A chaque instanciation, le code généré est dupliqué autant de fois que lesparamètres du template sont di�érents.
E. Ramat (ULCO) GAL 19 novembre 2012 124 / 136
Introduction à la métaprogrammationRappel sur les templates en C++
Paramètre par défaut
Un paramètre d'un template peut possèder un type ou une valeur par défaut.
template <class T, class S = size_t > class Vector {...};
E. Ramat (ULCO) GAL 19 novembre 2012 125 / 136
Introduction à la métaprogrammationSTL et functional
STL
une partie très importante du langage C++ : la STL (Standard TemplateLibrary)
la STL propose un grand nombre d'éléments :I des structures de données, tableaux, listes chaînes, piles, . . .I des algorithmes de recherches, de suppression, de tas, . . .
il existe principalement trois types d'éléments :I les conteneurs : stockent les donnéesI les itérateurs : parcourent les conteneursI les algorithmes : travaillent sur les conteneurs à partir des itérateurs
E. Ramat (ULCO) GAL 19 novembre 2012 126 / 136
Introduction à la métaprogrammationSTL et functional
functional
adaptateur de fonctions
opérateur d'appel de fonctions
opérations de base (addition, soustraction, . . . , comparaison, . . . )
basé sur le principe des functors
functor
class myFunctorClass{public:
myFunctorClass(int x) : _x(x) { }int operator ()(int y) { return _x + y; }
private:int _x;
};
int main(){
myFunctorClass addFive (5);std::cout << addFive (6) << std::endl;return 0;
}E. Ramat (ULCO) GAL 19 novembre 2012 127 / 136
Introduction à la métaprogrammationSTL et functional
STL et functor
Prenons l'exemple de l'algorithme for_each :
on itère sur l'ensemble des éléments d'une collection (vector, list, map, . . . )
pour chaque élément, on applique une fonction
la fonction peut être réprésentée par un functor dont le paramètre est dumême type que l'instantiation de la collection
functor
class additionneur{
double _sum;public:
additionneur () : _sum (0) { }void operator ()( double x) { _sum += x; }
};
std:: vector < double > V;...additionneur result = for_each(V.begin(), V.end(), additionneur ());std::cout << "La somme est " << result.sum << std::endl;
E. Ramat (ULCO) GAL 19 novembre 2012 128 / 136
Introduction à la métaprogrammationSTL et functional
Allons plus loin . . .
Recherche d'éléments d'une collection répondant à un critère
à partir d'un vecteur d'objets, on veut construire une nouvelle liste contenantles objets qui répondent à une condition
l'algorithme remove_copy_if répond à cet objectif
il faut spéci�er :I le début et la �n de la collection à parcourirI le point d'insertion dans la nouvelle collection des éléments copiésI la fonction de test
La signature de la fonction remove_copy_if
template < class InputIterator , class OutputIterator , class Predicate >OutputIterator remove_copy_if(InputIterator first , InputIterator last ,
OutputIterator result , Predicate pred){
for ( ; first != last; ++ first)if (not pred(*first)) *result ++ = *first;
return result;}
E. Ramat (ULCO) GAL 19 novembre 2012 129 / 136
Introduction à la métaprogrammationSTL et functional
La fonction de test
la fonction de test doit véri�er qu'un employé n'a pas un salaire supérieur àun seuil
la fonction doit donc prendre 2 paramètres (l'objet employé et le seuil)
la fonction attendue par remove_copy_if doit admettre seulement quel'objet employé
on utilise alors un adaptateur : bind2nd a�n de réduire le nombre deparamètres
E. Ramat (ULCO) GAL 19 novembre 2012 130 / 136
Introduction à la métaprogrammationSTL et functional
STL et bind2nd
class employee{
int salary () const;...
};
bool makes_less_than(const employee e, int amount){ return e.salary () < amount; }
std:: vector < employee > find_all_that_make_50k(std:: vector < employee >& employees)
{std:: vector < employee > rval;
std:: remove_copy_if(employees.begin(), employees.end(),std:: back_inserter(rval),std:: bind2nd(std:: ptr_fun (& makes_less_than),50000));
return rval;}
E. Ramat (ULCO) GAL 19 novembre 2012 131 / 136
Introduction à la métaprogrammationBoost et bind
functional avec Boost
Boost est un ensemble de bibliothèques open-source a�n d'étendre lesfonctionnalités du langage C++
plusieurs de ces librairies ont été acceptées pour être intégrés au Technical
report C++ - spéci�cation des nouveaux ajouts à la librairie standardC++-11
Les bibliothèques avec Boost
multithreading
tests unitaires
containers évolués : graphes, tableaux multi-dimensionnels, . . .
métaprogrammation
gestion mémoire : les smart pointers, par exemple
encapsulation du système de �chiers
mathématiques : random, integer, rational, . . .
. . .E. Ramat (ULCO) GAL 19 novembre 2012 132 / 136
Introduction à la métaprogrammationSTL, functional et Boost
Boost o�re des facilités pour encapsuler les appels de fonctions dans un cadrefonctionnel : boost::bind
dans l'exemple, on utilise le functor std::less qui permet de réaliser lacomparaison et std::bind lie les paramètres (une méthode et une constante)de la comparaison
std:: remove_copy_if(employees.begin(), employees.end(),back_inserter(rval),boost::bind(std::less < int >(),
boost ::bind(& employee ::salary , _1),50000));
std:: remove_copy_if(employees.begin(), employees.end(),back_inserter(rval),boost::bind(& employee ::salary , _1) < 50000);
Pourquoi faire ça ?
La fonction de comparaison pourrait être un paramètre de la fonction rightarrow
une fonction devient alors un objet comme un autre !E. Ramat (ULCO) GAL 19 novembre 2012 133 / 136
Méthodes agilesIntroduction
E. Ramat (ULCO) GAL 19 novembre 2012 134 / 136
Intégration continueIntroduction
E. Ramat (ULCO) GAL 19 novembre 2012 135 / 136
Licence
Licence
Module Génie et architecture logicielle
Copyright c© 2011-2012 - Eric [email protected] c© 2006-2012 - Gauthier [email protected]
Permission is granted to copy, distribute and/or modify this document under theterms of the GNU Free Documentation License, Version 1.2 or any later versionpublished by the Free Software Foundation; with no Invariant Sections, noFront-Cover Texts, and no Back-Cover Texts. A copy of the license is included inthe section entitled "GNU Free Documentation License".
E. Ramat (ULCO) GAL 19 novembre 2012 136 / 136