---
title: "Génie logiciel, Séance 7 et 8"
author: [SCHINDLER Hugo]
date: \today
titlepage: true
...

\newpage

Objectifs et Moyens

Qu'est ce qu'un bon logiciel ? Modularité, évolution, maintenance, ergonomique, compatibilité, efficacité, REPONSE AU BESOIN !

# Qualité du logiciel

**Fonctionnalité** : Répond aux besoins fonctionels avec exatitude (aptitude à la tâche, précision, sécurité)

Exemple de la balance

**Utilisabilité**

- Facilité à prendre en main le logiciel : fonctionnalité de base : respect des habitudes du métier, ergonomie, contraste, performance (réactif : mettre un sablier)
- Accompagner le changement (cession de formation, tuto video)
- Facile à installer, utiliser et administrer. Pour les gros logiciels : plusieurs Usecase (machine à café : utilisation café et rechargement)

**Fiabilité et robustesse**
Fiabilté exprimé en nombre de neuf: disponible 99.9% indisponible 1.44 minute par jour. Plus on a de 9, plus on est robuste (on fait de la redondance : même logiciel sur 2 machines, 2 machines avec OS, logiciels différents (codé avec 2 teams différents) unplug à chaud. Plus c'est robuste, plus c'est cher. Interuption = perte de données d'argent. On cherche que le cout de robustesse soit égale à la perte due à la robustesse. Avantage de notre profil : pont de vue double. Détecter les problèmes, risques : difficile. On veut fonctionner en mode anormal : analyser, prévoir els erreurs, trouver où est l'erreur et rattrapper les bugs. Méchanisme exception Java.

	 try{
		entrer
		sortie

		} catch(IOException(Exception e){
		  	code de tolérence : afficher un message d'erreur
			Qu'est ce que je fais si l'excecution à planter
		}

**Efficacité** :

- Temps de réponse (Exemple : logiceil de trading)
- Consommation de ressources

**Maintenance et évolutivité**

- Correction de bugs
- Facilité d'analyse et modification pour intégrer de nouveaux besoins
- Non regression et facilité à être testé (en cas d'ajout d'une fonction, cela ne perturbe pas se qui est fait avant)

**Portabilité**

- Facile à installer
- Facile à migrer
- Extensibilité du nombre d'utilisateur

**Objetctif du génie logiciel** : aboutir à une solution de qualité en respectant coût et délai.

**Taux de succès des projets**

- Succèes : Livrer en temps, cout ok : 25%
- Imparfait : 1 seul des 2 critères : 50%
- Echec : Projet dans le tiroir : 25%

Dans le BTP, ce serait le bazar

Les petis projets ont un meilleur taux de succès.

**Origines de rsiques liées au développement de logiciel :**

- incompréhension des besoins (logiciel unique, pas de référence commune comme en architecture)
- instabilité des besoins (besoins qui évoluent)
- Choix technologiques (developpement avec tel ou tel language, le language peut disparaitre à cause des architecture de technologies, support du créateur de language)
- Mouvement du personnel (documentation difficile et longue, transmission oral souvent n binome maintenant. Difficile de récupérer les compétance. Bus number : nombre de personnes qui peuvent etre percutés par un bus sans que le projet se casse la gueule.
- Pas de vecteur gravité (faire les choses dans le bon sens)

**L'ecosystème du développement** facteur

**Analyse de pestel:**

- politique (logiciel libre)
- economique (prix, formation logiciel)
- sociaux (evolution de carière de votre équipe : en Europe la partie developpe n'est pas bien considérer. Aux US, ils sont très bien payés comme les bons commercials)
- technologique (contrainte pour destop, tablette, smartphone, mais automatisation du code, veille technologique)
- écologique (développement : code qui utilise le moins d'enregie : execution sur GPU ou CPU, organisation de l'équipe)
- légaux (licence, CNIL (donnés personnelles))

**Programme des cours CM8 à 11:**

- qualité
- métrqique
- règles de bonne pratiques
- tests
- cycles et méthodes (concption, test, déployement)
- patrons (solution classiques à problèmes classiques)
- autres  outils suivant le temps restant
- conclusion

# Métrique

On ne juge pas les développeur mais le logiciel pour savoir où l'améliorer

## Metrique de code

**NCSS** : **Non Commenting Source Statement** : 40..70/ méthode

**CLOC** : **nombre de lignes de commentaires** : 10% ... 30%

## Métrique Orientés objets

**Profondeur de graphe d'héritage** : DIT : Profondeur 7 max hors bibliothèque

**Coupling Between Objects** CBO : nombre de classes qu'une classe utilise (par trop spécifique, favorise modularité)

**Weighted Methods per Class** (WMC) somme des métriques (complexité cyclomatique) pour toutes les méthodes

## Mesure du logiciel

**Points de Fonction** mesure de la richesse fonctionelle, taille du projet, en terme de fonctionnalités livrées à l'utilisateur

**Complexité cyclomatique** nbArs-nbNoeuds+nbENtres+nbSorties : nombre minimum de chemin possible (faire le dessin)

Exercice schéma 1

Métrique : on doit l'interpréter, des codes peuvent l'examiner.

puppycrawl.com/dtds/configuartion_1_3.dtd

**Théorie de la complexité** Cf FISDA

Il y a des logiciels pour faire les schémas (source monitor, testwell.fi, cmtjava, sonarqube (best), squale, klocwork)

**Bonnes pratiques de développement**

Toujours coder comme si celui qui maintient le code est un psycopathe qui sait où tu habites.

## Conventions

**Convention pour uniformiser le style du code :** facilite la relecture et maintenance par d'autres

- Nommage et organisation des fichiers (build et srs)
- Style d'indentation, taille des lignes
- Nommage des méthodes, CONSTANTE, variables
- Règles de commentaires et documentation, langue (anglais)
- Règle de parenthèsage
- Pas d'allocation dynamique si pas beaucoups de mémoire (code plus robuste)

Périmètre de référenciels:

- Code convention

Enironment, projet :

- .NET Coding techniques
- Linux Kernel coding

**Construction d'un référentiel:**

- identifiant publique (article 2563)
- public ciblé (architecte , développeur, testeur)
- type de règle (norme>recommendation(entrose possible si justification)>bonne pratique)
- regle courte mais multiple
- contexte
- controle de la règle (vérification manuelle, automatique)

Vérification d'echantillons dans le code (nouveau developpeur, code critique, code pas bon précédement)


# Test


Test
: exécution ou écvaluation d"='un système ou d'un composant ar des moyens automatiques ou manuels, pour vérifier qu'il répo,d à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus

**Composant**

- Données
- Objet
- Observation


Enjeux des tests : s'assurer du niveau de qualité du produit livré. non-qualité = risque de bugs, panne et coûts directs et coûts caché. 30% budget =test, 80% pour NASA

Un test= un investissement. Mais plus le bug est détecter tôt, moins il coûte cher.

**Limites **

- Pas de test exhaustif
- Prouve la présence de bugs mais pas son abscence comme les aliens
- Vu comme un poste de coût à réduire
- Tests sautés pour livrer à temps
- Testeur = fonction dénigré mais créatif et abstraction face au système

**Catégories de test :**

- A/ Proximité du code
- B/ Granularité
- C/ Qualité
- D/ Dynamisme

## Proximité du code

A/ Test boîte magique

**Test boîte noire :** point de vue de l'utilisateur. Est ce que ça marche ?

**Test boîte blanche :** comment ça marche ? Données temporaires bien effacé, protocole sécurisé.

**Test boîte grise :** Si on a pas accès à tout le code (appel de service extérieur), on les remplace par des bouchons pour tester.

## B/ Granularité

**test unitaire : **

- Déclarationd d'une assertion

- S'applique à une portion du code source

- Vérifiable dès que le code est implémenté.

**test d'assemblage**

bon fonctionnement technique et fonctionnel de l'application à l'assemblage de ses différents composants

+Gros : **Recette**

Test avec le client : 

- Exhaustivité des éléments fournis 
- Installation ok ?
- Bon fonctionnement après installation
- Cas d'erreur technique
- Audit de code

**Test en exploitation**

- Vérification d'aptitude à la bonne exploitabilité
- Test sur site pilote
- Vérification de services réguliers

**Test dans le cycle de vie**
Cycle en V.
On peut définir le test à chaque étape du cycle de vie.

## C/ Critères de qualité

**Assurance de qualité :**

- Tests fonctionnels
- Sécurité (tests hack classique)
- Performance (temps de réponse pour 1 utilisateur, tests de charge(nombre d'utilisateur, de requêtes -> dimensionnement d'infrastructure) Ramasse miette qui se déclache avec le temps toute les 1 minutes
- Non régression
- Utilisabilité / ergonomie
- Qualimétrie

## D/ Dynamisme

**Test statique**

Examens du code sans exécution : identifier les trus louches : variable jamais lue, écrite 2 fois d'affiler sans lecture intermédiaire, affectation non réalisé, code jamais atteint : Eclipse nous le dit

**Test dynamique**

Pas possible de tester avec tout

Comment concevoir les tests
- test fonctionnels : trouve trou
- test structurels : trouve erreur de programmation

### Test fonctionnels

**Test par partition d'équivalence** :
: Hyp : ca fonctionnne avec un élément de la plage, alors ça fonctionne avec tous.

**Test aux limites**
: On test aussi les limites. Permet de détecter les boucles mal réglé sur les tableaux, vérifie les > et $\geq$

**Test par table de décision**
: Recherche de trou dans les décisions

**Test par paires**
: Si grands nombre de test à faire, on test que les paires au lieu de faire tout les cas.

### Tests structurels :

**Couverture des branches**
: On choisit nos tests pour passer par tout les chemins.

**Couverture des blocs**
: Ne repésente pas le même travail si boucles dans le schéma.

**Test aléatoire**
: Un test complémenatire : détecte les erreurs de spécification. L'automatisation de la vérification de la sortie n'est pas facile.

## Utilisation du test

**Plannifier les tests : **

- Stratégie (selon les spécifications, riques ou estimation des erreurs)
- Tests (fonctionnel, sécurité)
- parraléliser en attendant pas le code final : utilisation de bouchons
- Priorite (plus critique, risque)
- A quel moment ? big-bang

descripton dans les standarts

**Automatiser les test**

- Framework génèrent des tests
- Framework pour tester aspects (code, GUI, ...)

**JUnit**
- Environnement de tests unitaire en java
- Definition des valeurs d'entrée
- Exécution automatique

On exprime le pourcentage de code testé au lieu du nombre de tests réalisés.

Graphisme et audio difficles à tester automatique

**Test par mutation**
 : On modifie une ligne, le programme de test doit tuer tout les mutants.

**Preuve formels**
: démonstration mathématique (boucle infini, nombre de passage de boucles)

Codage en B (ligne de métro météore)

# Les cycles et méthodes de développement

**Cycle en cascade**
: années 70 : analyse, conception, implémentation, test, maintenance

Inconvéniant :  effet tunnel : on ne sait pas si on satisfait les besoins du client.

**Cycle en V**
: Schéma 2, effet tunnel aussi

**Cycle itératif ou incrémental** 
: 1ere conception brute 

**Inrémental **
: on fait des morceaux complets

**Itératif**
: on fait des escisses.

**Unified Process**

- itératif et incrémental
- piloté par cas d'utilisation, modélisation visuelle
- architecture à base de composant (language objet)


Manifeste agile : méthodes agiles : 4 principes : cf diapo

Exemple de méthodes agiles :

* Srum mêlée quotidienne
* XP : eXtreme Programming : parie stratégique développées en binome rotatifs.
* lean : ex : kanban (limiter les stocks, on écrit que le nécessaire)
* Autres : ASD (Adaptative Developpement), crystal Clear, DSDM (Dynamic Systems Development Method)...

Meilleur succès avec agile (moins de fail), mais projets waterfall sont moins propices à l'abandon. C'est peut etre une bonne chose.

## Méthode d'estimation de coût du logiciel

**Lois de parjkinson**
: le projet se dilate sur le temps disponible

**Loi du marché**
: Combinen de temps je dois dire pour remporter le larché

**Méthode analogique**
: basé sur l'expérience des anciens projets

**Méthode analytique**
: somme de points coûts

**Intégration continue**
: basé sur une usine de développement logiciel. cf diapo

# Patrons de conception (design pattern)

Exemple : patron adaptateur

Code pour adaptateur :

     Cercle c=new Cercle(10, 2, 2);
     CercleAdapt ca= new CercleAdapt(c);
     lesMotifs.add(ca);
     
     ca.calculPerimetre();

cf Schéma 3

**Anatomie d'un patron**

- Nom
- But
- Motivation: utilisation d'une classe sans renomer classe de base
- Participant : target, adapter, adaptee, client
- Structure avec UML
- Exemple d'implémentation
- Cas d'utilisation réel dans 3 situations réels
- Problèmes connus
- Conséquences (la classe de base peut moins facilement évoluer. 
- Relation avec d'autres patrons

Catégories :
- Patrons de création
- Patrons structuraux
- Patrons comportementaux

hillside.net/patterns solutions qui existent déjà

## Singleton

**Singleton**
: Crer 1 seule instance d'une classe

Code de class singleton :

     public class Truc{
     	    int machin;
	    PRIVATE static Truc instanceUnique 
     	    PRIVATE Truc(int m){
	    	    this.machin=m;
     	    }
	    public static Truc getTruc(int m){
	    	   if (instanceUnique==null){
	   	       instranceUnique=new Truc(m);
	    	   }
	    	   return instanceUnique;
	    }
     }

Attention en monothread uniquement ! 

Code client :

     Truc t = new Truc();

Code autre :

     class Machin{
     	   int a
     	   public STATIC int double(){
	       	   return 2*a;
     	   }
     	   public int triple(){
     	   	  return 3*a;
    	    }
     }


c'etait un patron de création

On doit connaitre le patron observer, singleton et Adapter

Attente active : mettre des notifications à la place

Interbloquage : sémaphore : programme risque de se bloquer

Bad code smell : indice d'un problème.