hschindler
8 years ago
1 changed files with 575 additions and 0 deletions
@ -0,0 +1,575 @@ |
|||||
|
--- |
||||
|
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. |
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
Loading…
Reference in new issue