49 0 5MB
Le Génie logiciel et La qualité logicielle - Introduction Dr. Youssef GAHI [email protected]
IGA Casablanca 2015-2016 1
Objectifs du cours (24 heures)
Saisir l’importance du génie logiciel
Comprendre le cycle de vie d’un logiciel et le rôle des différents intervenants.
Analyse, Conception, Implémentation, Support…
Se familiariser avec les modèles de conception.
Analyse des besoins, Contrôle de l’évolution…
Conception d’objets réutilisables, API, MDA…
Comment apporter de la qualité a un logiciel?
Design Patterns, Scrum, Tests unitaire…
2
Plan du cours
Introduction au génie logiciel (3h) Logiciel vs Génie logiciel Pourquoi le GL ? Les différents intervenants dans la production logicielle. Cycle de vie d’un logiciel. Modèles, Techniques et Processus de développement (4h) Cycle de développement Objets réutilisables, API, MDA
Etude de cas (2h) Outils permettant de créer des logiciels de qualités (6h)
Qualité logicielle (6h)
Outils de Conception Outils d’implémentation et de gestion Outils d’analyse Patrons de conception (Design Patterns)
Travaux Pratiques (3h)
3
Introduction au génie logiciel
4
Logiciel vs Génie logiciel
Qu’est ce que c’est logiciel?
Programmes et la documentation associée – cahier de charges, modèles, manuels
Qu’est ce que c’est génie logiciel?
Le génie logiciel comporte des aspects de gestion de projet et des notions de qualité (satisfaire le client) Ceci en utilisant des méthodes, des modèles, et des outils.
Quelle est la différence entre génie logiciel et informatique? 5
Génie logiciel
Développement en équipe d'un logiciel complexe
Un intervenant = une (petite) partie du travail
Programmation : entre 15% et 35% du travail
Analyse, conception, vérification, gestion de projet
Complexité croissante des logiciels Sécurité Coût du logiciel (>> coût du matériel)
6
Pourquoi le GL?
Si l'on veut maîtriser le développement de systèmes complexes, il faut :
rédiger de façon claire les spécifications du système (ce que le client attend du produit)
comment être sûrs que ces spécifications sont complètes ? comment être sûrs que ces spécification sont cohérentes ?
valider/vérifier toutes les étapes du développements
a-t-on des moyens de validation/vérification (mathématiques) ? de réutiliser des sous-systèmes déjà réalisés (mais pas n'importe comment) a-t-on des règles, des outils pour aider à la réutilisation ?
Maitriser les coûts.
7
Coût d’un logiciel
Coût de développement
Coût d’installation
Effort jour-homme (entre 500 et 1000 euros par jour)
Frais de déplacement, avion, hôtel…
Coût de support/maintenance
Résolutions des bugs, assistance… 8
Les défis devant le GL
9
Rôles des intervenants dans le développement logiciel
10
Les commerciaux Présenter des solutions pour les clients. Accompagner les clients dans la définition de leur besoin (avec l’aide des analystes fonctionnels)
11
Analyste fonctionnel-Concepteur Etude de faisabilité. Transformer le besoin fonctionnel en une architecture logiciel. Choix technologique
Type d’architecture Protocoles Estimation grosse maille
12
Chef de projets Piloter et suivre l’avancement des projets. Définir les différentes dates en collaboration avec les responsables de développements. Assurer des réunions avec le client final et les responsables de développements. Calculer et estimer les couts nécessaires ainsi que la rentabilité du projet.
13
Responsable de développements Architecture logicielle Suivre l’avancement de l’équipe Communiquer les livraisons ou Annoncer les retards. Assurer des réunions avec les différentes parties notamment les chef de projets.
14
Développeur
La réalisation de toute la matière logicielle du projet.
Codage des traitements Tests Préparation des binaires et des scripts Documentation
15
Intégrateur
Vérification des prérequis
Installation et configuration du produit
Validation des recettes de tests.
Rapport de missions
16
Les partenaires
Equipes externes
Sous-traitants
Institut
Stagiaires
17
Cycle de vie d’un logiciel
18
Cycle de vie d’un logiciel Analyse des besoins Spécifications (Contrat commercial) La conception fonctionnelle et technique La Réalisation Vérification et Validation L’intégration La recette interne et recette fonctionnelle La formation Documentations Maintenance et évolution
19
Analyse des besoins Fonctionnalités attendues du système Point de vue métier, de l'utilisateur Aider à formuler le besoin Produit un document textuel, avec schémas, intelligible par le client Conduit à la définition du cahier des charges => les "spécifications"
20
Spécifications Ce que doit faire le système Produit un document textuel avec schémas, lisible par toutes les parties Base du contrat commercial Base des tests de vérification de la phase d'installation
21
Conception générale Comment réaliser le logiciel ? Choix techniques : explorer plusieurs solutions… Décrire la solution retenue Architecture générale
Composants
Structures de données Fonctionalités
Interactions entre ces composants
Tous les éléments de la spécification doivent être pris en compte 22
Conception détaillée Décompose chaque composant en souscomposants, jusqu'au niveau où le codage devient facile Précise pour chaque composant :
Son interface Les algorithmes Le traitement des erreurs
Produits :
L'ensemble de ces descriptions Le plan des tests unitaires (jeux de données) 23
Implémentation Traduction dans un langage de programmation des différents modules Mise au point Tests de développements Commentaires
24
Vérification et Validation
Vérification
Revues des spécifications (checklist)
Validation
Analyse du produit: Sécurité, Gestion des mot de passes… Plateformes de tests indépendante. Beta et Alpha Test Recette des tests interne Tests de charge
25
Test (1) Dans la pratique, il convient d’intégrer les développements unitaires au sein de l’architecture technique cible, tout en testant la cohérence fonctionnelle et technique globale de l’application, avant livraison et installation sur le site du client.
Les tests réalisés seront :
Un test spécifique du Framework après développement sur la base de la conception définie au début de la conception fonctionnelle et technique,
Un test de réception des composants achetés pour le projet (modules sous-traités),
Les tests unitaires des fonctions développées,
Les tests d’assemblage sur les plates-formes de développement avec données réelles permettant entre autres le test des procédures de reprise, Les test d’intégration sur les plates-formes, 26
Les tests de charge sur chaque module.
Test (2)
Tests des composants externes
L’objectif de cette étape est de s’assurer que l’ensemble des composants externes à l’application sont conformes sur les plans fonctionnel et métier aux spécifications prévues dans les phases de conception. Sur un plan technique, il s’agit de s’assurer que le composant technique ne crée aucune interaction non-souhaitée (ou interférence) de par son installation, registration, instanciation,… Les composants externes sont par exemple et suivant les technologies employées des composants OCX, VBX, DLL… La qualification technique pourra avoir été réalisée dans le cadre d’un 27 projet antérieur
Test (3)
Ces tests sont réalisés au fil de l’eau par l’équipe de développement. Chaque personne de cette équipe consigne que le développement de la fonction X a été réalisé par lui et après exécution en environnement de développement ou sur simulateur. Il s’agit de confirmer que cette fonction est conforme aux spécifications fonctionnelles et techniques décrites.
Tests Unitaires
Tests d’assemblage
Ces tests sont réalisés par le chef de projet ou sous son autorité par une personne de l’équipe de développement détachée sur cette mission. Cette phase permet de s’assurer que l’ensemble des composants techniques développés ou acquis s’interfacent correctement : l’application fonctionne sans défaillance, les résultats attendus sont 28 conformes sur les axes règles de calcul et règles de gestion. Cette phase s’effectue sur le jeu d’essai de développement.
Test (4)
Cette phase de test s’effectue sur une plate-forme d’intégration déclarée conforme par le client à l’environnement de production. Cela concerne tant les aspects techniques (OS serveur, base, client) que les interfaces (entrantes notamment), ainsi que le jeu de données.
Tests d’intégration
Tests de charge
L’objectif de cette phase est d’effectuer une montée en charge des données entrantes et existantes dans l’application. La base de données sera chargée avec une volumétrie équivalente au fonctionnement nominal de l’application. Les transactions devront s’effectuer dans les temps de réponses prévues lors de l’élaboration du cahier de charge. A défaut de temps de réponse décrit, l’application devra prouver qu’elle fournit les réponses attendues avec la volumétrie nominale. 29
Installation Dernière étape avant exploitation Installer le logiciel dans son environnement opérationnel Vérifier le logiciel dans son environnement opérationnel Organiser la formation Planifier la transition
30
Recettes
Préparation des procédures de vérification/validation du logiciel
plan de validation
Version provisoire des manuels :
d'utilisation et d'exploitation du logiciel
31
Recettes (1)
Il s’agit d’une validation interne, effectuée par la direction projet, des livrables avant fourniture au client du lot réalisé. La recette interne assure que le chef de projet en charge du projet suit le déroulement des actions de la contractualisation à la mise en œuvre du résultat prévu.
La recette interne
La recette fonctionnelle
La recette fonctionnelle est effectuée par le client et plus spécifiquement par le Chef de Projet Utilisateur du Client. Elle est usuellement effectuée sur la plate-forme de développement ou la plate-forme d’intégration. Les compléments et/ou évolutions détectées lors de la recette fonctionnelle peuvent donner lieu à l’établissement 32 d’avenant(s) au contrat
Formations
La formation peut prendre plusieurs formes. Elle peut viser les utilisateurs mais aussi les équipes techniques (exemple : les équipes de maintenance). Différentes déclinaisons sont envisageables en fonction du contexte projet considéré :
Les sessions de formation : elles s’appuient sur l’alternance d’un enseignement théorique et des mises en pratiques immédiates (TP). Les sessions de formation doivent impérativement être intégrées dès le début dans le plan projet pour qu’elles soient optimales. Le transfert de compétences : il est principalement dédié aux équipes techniques d’exploitation ou de maintenance. L’objectif est de traiter sur la fin du projet l’ensemble des points critiques du projet en parfaite transparence. L’accompagnement en production : il se met en place lorsque la montée en charge et/ou le déploiement représente(nt) un enjeu majeur et critique du projet. Ainsi, l’ensemble des anomalies 33 pouvant survenir sont traitées en collaboration directe avec l’équipe projet.
Documentation Les manuels d'utilisation et d'exploitation doivent être prêts au plus tard lors de l'installation Selon la complexité du logiciel :
Guide d'installation Guide de l'utilisateur Guide de l'opérateur Manuel de référence Documentations des composants logiciels 34
Guide d’installation Fonctionnalités du logiciel Architecture Interfaces utilisateurs Comportements en cas d'erreurs Performances requises Interfaces avec autres logiciels Interfaces avec le(s) matériel(s) Contraintes de réalisations (matériels, logiciels, normes…)
35
Guide de l’utilisateur Le document décrivant l'architecture générale Un plan d'intégration, avec un plan des tests d'intégration (procédures de tests, jeux de données)
36
Maintenance et évolution
Corrections des erreurs
Prise en compte de nouveaux cas d'utilisation
Ajout de nouvelles fonctionnalités
37
Cycle de développement d’un logiciel
38
Rappel
C’est quoi un logiciel ? Programmes et la documentation associée – cahier de charges, modèles, manuels
C’est quoi Le Génie Logiciel ? Le génie logiciel comporte des aspects de gestion de projet et des notions de qualité (satisfaire le client) Ceci en utilisant des méthodes, des modèles, et des outils.
Les intervenants dans le Génie Logiciel?
Les Commerciaux, Analyste, Chef de Projets, Resp. de Dev, Développeur, Intégrateur, Partenaires.
Les étapes du Génie Logiciel ?
Analyse des besoins Spécifications (Contrat commercial) La conception fonctionnelle et technique La Réalisation Vérification et Validation L’intégration La recette interne et recette fonctionnelle La formation Documentations Maintenance et évolution
39
Le Cahier des charges
Le cahier des charges est un document par lequel un demandeur (entreprise, organisme privé ou public) exprime le besoin devant être satisfait par un objet à concevoir. Pour cela, il précise les fonctions de service qu'il doit assurer et les contraintes à respecter. C'est un contrat qui engage le concepteur.
Il servira de "consigne de recherche" pour que les idées abstraites de départ débouchent sur un projet concret. Pour chaque fonction, il définira également les critères rentrant en compte, le niveau de performance attendu et la flexibilité tolérée.
Pour ne rien oublier lors de la rédaction du CdCF on se doit d'être rigoureux et méthodique.
40
Le processus de définir les besoins Etude de faisabilité
Trouver les besoins et analyse Spécification des besoins Validation des besoins
Rapport de faisabilité Modèles du système Besoins d’usager et du système
Document des besoins (Cahier de charge) 41
Cahier des charges d'un robot aspirateur L'expression du besoin
Le besoin Réduire le temps consacré au ménage en réalisant de manière automatique le passage de l'aspirateur. La réponse actuelle au besoin De nombreuses entreprises fabriquant des aspirateurs traditionnels ont le projet de concevoir ce type d'aspirateur. Actuellement, très peu de produits fiables sont disponibles sur le marché. Les objectifs Réaliser un aspirateur robot fiable pouvant remplacer un aspirateur traditionnel, à un prix acceptable pour les ménages. Les interventions humaines 42 sont à limiter au maximum.
Cahier des charges d'un robot aspirateur
2 2 3
Fonctions de service et contraintes Aspirer la poussière au sol sans intervention de l'utilisateur Aspirer la poussière sous les meubles Aspirer le long des murs et des obstacles Éviter les obstacles en douceur
4
Passer sur des obstacles (tapis, seuils de porte...)
5 6
Ne pas tomber dans les escaliers Stocker la poussière aspirée
7
Assurer la sécurité des personnes et des animaux
8 9 10
Doit être esthétique Être transportable Pouvoir être rangé dans un placard
1
43
Cahier des charges fonctionnel Exemple : Support de téléphone portable Fonctions Doit permettre de maintenir un téléphone mobile. Doit être visible la nuit
Doit assurer la sécurité de l'utilisateur.
Doit plaire, Doit être beau, esthétique Doit être résistant Sera posé (support de téléphone mobile) sur un plan horizontal pour une lisibilité aisée de 44 l'écran.
Cahier des charges fonctionnel Application : Support de téléphone portable Fonctions Être réalisable au collège Être compétitif (coût matière maxi 5 euros) Doit être peu onéreux
Assurer une bonne autonomie
45
Le processus de logiciel
Activités
Spécification – qu’est ce que le logiciel doit faire et les contraintes posées au développement Développement - production logiciel Validation – vérification si le logiciel est celui qui est attendu du client. Evolution – modification du logiciel en accordance avec les besoins.
46
Modèles génériques Effet Tunnel Cascade Modèle en V Modèle en W Modèle en Spirales Développement évolutif et itératif Développement itératif incrémental Basé à l’assemblage de composants
47
L’effet tunnel Un jour, peut-être ...
Le départ est connu
Le modèle de développement en tunnel n’offre aucune visibilité sur l’état d’avancement du logiciel. 48
Le modèle en cascade
Cycle de vie linéaire sans aucune évaluation entre le début du projet et la validation
Le projet est découpé en phases successives dans le temps
Chaque phase ne peut remettre en cause que la phase précédente.
Le développement en cascade est en général rythmé par la génération de documents qui servent de validation pour le passage d’une phase à l’autre
Chaque phase est donc achevée avant que ne débute la suivante. 49
Cascade
50
Cascade
Problèmes
Avantages
Il est difficile de séparer les étapes On peut l’utiliser quand les besoins sont bien définis et ils sont stables. Bien documenté à chaque phase
Désavantages
Rigide (on ne peut pas de répondre au besoins nouveaux ou modifiés des clients) Les vrais projets suivent rarement un développement séquentiel. Etablir tous les besoins au début d’un projet est difficile. Aucune validation intermédiaire (aucune préparation des phases de vérification)
Sensibilité à l’arrivée de nouvelles exigences refaire toutes les étapes
51
Le modèle en « V »
A ce jour, le cycle en V reste le cycle de vie le plus utilisé. C’est un cycle de vie orienté test
A chaque activité créative (spécification, conception et codage) correspond une activité de vérification (validation, intégration, tests unitaire)
Chaque phase en amont prépare la phase correspondante de vérification (la vérification est prise en compte au moment même de la création). 52
Le modèle en « V »
53
Les limites des cycles de vie en « V » Les cycles de vie sont trop longs. Les relations entre les clients et les fournisseurs ne sont pas suffisamment formalisées. Ils ne gèrent pas les risques. L’intégration est trop tardive dans le cycle de vie. La documentation est réalisée d’abord et le logiciel après …
54
Cycle en V
Avantage:
La préparation des dernières phases (validationvérification) par les premières (construction du logiciel), permet de d’éviter d’énoncer une propriété qu’il est impossible de vérifier objectivement après la réalisation.
Inconvénients:
Construit-on le bon logiciel? le logiciel est utilisé très (trop) tard Il faut attendre longtemps pour savoir si on a construit le bon logiciel Difficile d’impliquer les utilisateurs lorsque qu’un logiciel utilisable n’est disponible qu’à la dernière phase. Idéal quand les besoins sont bien connus, quand 55 l’analyse et la conception sont claires.
Le modèle en « W » Ce modèle est une variante du modèle en « V ». Le cycle de développement ne commence que quand les problèmes ou les besoins sont parfaitement connus (cf. module de communication selon la méthode Merise). Un cycle en « W » peut être couplé à un cycle en « V », quand il est nécessaire de décomposer le système en sous-systèmes.
56
Le modèle en « W » Exigences brutes
Spécification des IHM du système
Vérification des flux logiques
Validation ou tests d’acceptation
Conception des sous-systèmes
Intégration et tests des sous-systèmes
Conception des modules
Intégration et tests des modules
2ème cycle de Goldberg Codage et tests unitaires
57
Le modèle en spirale
Ce modèle complexe est dû à Boehm. Il apporte une vue évolutive au modèle en cascade au travers d’une approche fondée sur l’analyse et la gestion des risques, puis la conception et la réalisation de prototypes évolutifs en fonction de l’avancement du projet. Le développement présente quatre grandes phases qui se succèdent au fur et à mesure de la construction de la spirale, Au dernier tour de la spirale, le produit est totalement défini, les risques résolus et le produit développé. 58
Développement spirale
59
Le modèle en spirale
Premier cycle : Analyse du risque → Prototype 1 → Simulations et/ou modélisations et/ou bancs d'essais → Définition de la mission (par la MO) → Planification de l'analyse (c'est-à-dire du cycle suivant, portant principalement sur un travail d'analyse) Second cycle : Analyse du risque → Prototype 2 → Simulations et/ou modélisations et/ou bancs d'essais → Définition (par la ME) et validation (par la MO) des besoins → Définition du plan de développement (c'est-à-dire des deux cycles suivants, consacrés à la conception, au codage, aux tests et à la mise en oeuvre du logiciel) Troisième cycle : Analyse du risque → Prototype 3 → Simulations et/ou modélisations et/ou bancs d'essais → Définition (par la ME), vérification (par la ME) et validation (par la MO) de la conception générale → Réajustement, le cas échéant, du plan de développement (ne concerne que la conception détaillée, le codage, les tests et la mise en oeuvre du logiciel) Quatrième cycle : Analyse du risque → Prototype 4 → Simulations et/ou modélisations et/ou bancs d'essais → Conception détaillée, codage, tests divers et mise en oeuvre du logiciel 60
Développement spirale
Secteurs
Préciser les objectifs Définir et minimiser le risque Développement et validation Planifier l’itération suivante
61
Processus évolutif
Aperçu de description
Spécification
Version initiale
Développement
Versions intermédiaires
Validation
Versions finale
62
Le cycle itératif incrémental Risques initiaux, portée du projet
Planification de l’itération Développement de l’itération Itération N
Évaluation
Révision du plan du projet Risques éliminés Révision des risques 63
Itération
Phase
Objectif
Itération préliminaire
Etude d’opportunité
Comprendre le problème
Décision Ressources pour l’élaboration
Itération d’architecture
Elaboration
Comprendre la solution
…xN
…
… Ressources pour la construction
Itération de développement
Construction
Réaliser la solution
…xN
…
… Livrer le produit (version bêta)
Itération de transition …xN
Transition …
Transmettre la solution … Recette client 64
Les avantages des cycles de vie itératifs et incrémentaux
Ces processus sont basés sur l’évolution de prototypes exécutables : L’utilisateur est placé devant des situations d’utilisation concrètes. Il est partenaire du projet. L’intégration est progressive et permet d’éviter l’effet « big bang » à l’approche de la date de livraison. Les progrès se mesurent par des programmes démontrables et non par des documents ou estimations. Le découpage par incréments permet de réduire la complexité du système en la ventilant dans les incréments. 65
Développement par composants
Spécification des besoins
Analyse des composants
Conception avec réutilisation
Modification des besoins
Développement et intégration
Validation
66
Origine et définitions
Problèmes
Fiabilité – comment l’utilisateur va croire que le composants ne va pas échouer Certification – qui va certifié le composant Les propriétés intégrales – comment les prévoir Compromis des besoins – comment faire le compromis entre les besoins assurés des différents composants
Caractéristiques
Standardisé Indépendant Composable Déployable Documenté 67
Interface de composants
Requires interface Defines the services from the component’s environment that it uses
Provides interface Component
Defines the services that are provided by the component to other components
68
Composants et objets Les composants sont déployables Les composants ne définirent pas des types L’implémentation des composants est opaque Les composants sont indépendant de langage Les composants sont standardisés
69
Modèles
Définition
Le modèle de composants c’est la définition des standard pour implémentation, documentation et déploiement du composant
Exemples
EJB .NET (COM+) Corba Component Model
70
Eléments du modèle Customisation
Naming convention Composition Interface definition
Specific interfaces
Interfaces
Documentation Meta-data access Usage information
Packaging
Evolution support
Deployment and use
Component model
71
Gestion des risques
Qu’est ce que c’est risque? La probabilité que quelque circonstances défavorables vont arriver
Types de risque
De projet – affecte l’emploi de temps ou les ressources De produit – affecte la qualité et le comportement du logiciel D’organisation – affecte le l’organisation
72
Gestion des risques Identification de risque Analyse de risque
Planifier le risque
Estimer la probabilité et conséquences; Plans d’éviter et minimiser les effet du risque;
Suivi du risque
73
Gestion des risques
Identification des risques
Analyse
Planifier
Suivi
Liste de risques potentiels
Liste prioritaire des risques
Plans pour éviter les risques et d’urgence
Estimer le risk
74
Gestion des risques
Identification du risque
Technologiques Personnel. Organisation. Besoins. Estimation.
Analyse – La probabilité et les effets du sinistre
Probabilité – très basse, basse, modérée, haute, très haute. Effets – catastrophique, sérieux, tolérable, insignifiant.
75
Gestion des risques
Planifier – pour chaque risque
Stratégie d’éviter le risque – diminuer la probabilité Stratégie de minimisation – minimiser l’effet du sinistre Plan d’urgence – quand l’événement arrive qu’est ce qu’on doit faire.
Suivi
Estimer chaque risque par périodes réguliers pour voir si la probabilité a changé. Estimer les effets de chaque risque Ne pas voir peur de discuter les problèmes
76
Annexe
Cahier de Charge:
est le recueil des exigences fonctionnelles demandées par la maîtrise d'ouvrage, il décrit des règles de gestion et de traitement dans le langage du métier (vue externe du système, c'est la vision utilisateur).
Cahier de Spécifications:
est la traduction du cahier des charges en termes plus techniques (données en entrée, données en sortie, description des écrans de l'IHM, règles de calcul, de transformation des données, ...) dont le but est de décrire de façon détaillée comment les exigences fonctionnelles vont être implémentées 77
Annexe (1)
Spécifications:
Des scenarii plus détaillés Base de la conception du système Ils peuvent être inclus dans le cahier de charge et dans le contrat On peut utiliser et des modèles du système (les UML diagrammes) Ils sont interdépendants avec l’architecture du système
78
Annexe (2)
Désavantages de la langue naturelle
Ambiguïté Sur-flexibilité Manque de structure
Alternatives
Langues structurées – formulaires, modèles, tableaux Langages spécifiques – rarement utilisés Notations graphiques – UML Spécifications mathématiques 79
Annexe (3) Modifier un item
Ajouter un item
Supprimer un item Consultation de l’inventaire
Commande fournisseur
Saisir livraison
Responsable des opérations Produire des rapports
80
Annexe (4)
Spécifications fonctionnelles
Le guichet doit vérifier la validité de la carte insérée Le guichet doit valider le code PIN. Le guichet doit allouer une somme maximum de 5000 DH
Spécifications non fonctionnelles:
Le système de Guichet doit être réalisé en C++ Le système doit utiliser un cryptage de 256 bits Le système doit vérifier le PIN en moins de 3 sec.
81
Méthodes d’analyse et de Conception
82
Analyse et Conception
Analyse du système
modélisation du domaine, modélisation de l’existant (éventuellement), définition d’un modèle conceptuel (ou spécification conceptuelle), plan de validation.
On élabore un dossier d’analyse plus un plan de validation.
Conception
proposition de solution au problème spécifié dans l’analyse organisation de l’application en modules et interface des modules (architecture du logiciel), description détaillée des modules avec les algorithmes essentiels (modèle logique) structuration des données
On élabore un dossier de conception plus un plan de test global et par module
83
Méthodes d’Analyse et de Conception
Proposition d ’une démarche distinguant les étapes du développement dans le cycle de vie du logiciel (modularité, réduction de la complexité, réutilisabilité éventuelle, abstraction)
Utilisation d ’un formalisme de représentation qui facilite la communication, l’organisation et la vérification
Production de documents (modèles) qui facilitent les retours sur conception et l’évolution des applications
84
Techniques de Conception
Méthodes fonctionnelles hiérarchiques
Méthodes données
Data-Flow/SADT/SA-SD, Structure-Chart, ...
Entité-Relation, MERISE, UML
Méthodes comportements
Réseaux de Pétri, ... 85
Méthodes fonctionnelles: SADT
SADT : technique structurée d'analyse et de modélisation
86
Méthodes fonctionnelles: SADT (2)
87
Méthodes fonctionnelles: SADT (3)
88
Méthodes fonctionnelles: Data Flow
sang
Paramètres du sang Capteur de glucose sanguin
Analyse de glucose sanguin
Niveau du glucose
Calcul du besoin d’insuline insuline
Instructions vers la pompe
Pompe d’insuline
Gestion de délivrance d’insuline
Besoin d’insuline
89
Méthodes fonctionnelles: Data Flow (2) Visio 2000
Visio 5.x From Flow Chart / Data Flow Diagram
From Software Diagram / Gane-Sarson DFD
From Flow Chart / Data Flow Diagram
ID #
Process Process
Process
Data Store Data Store
1
Data Store
ID #
External Entity
External Entity
External Entity
90
Méthodes fonctionnelles: Data Flow (3)
91
Méthodes fonctionnelles: Data Flow (4)
92
Méthodes données: Entité-Relation
Entité [définition de Chen] : chose qui peut être identifiée distinctement Propriété (ou Attribut) : les entités (et les associations) sont décrites par des propriétés caractérisées par un nom et un type Association [définition de Chen] : Lien entre entités elle peut être binaire, ternaire, n-aire
93
Méthodes données: Entité-Relation (2)
94
Méthodes données: Merise
Merise
Une approche systémique Approche fonctionnelle A une vision duale des données-traitements A trois niveaux d’abstraction
Niveau conceptuel Niveau logique Niveau physique
95
Méthodes données: Merise - MCT
96
Méthodes données: UML Système réel
Analyse Modèle d’Analyse
Conception Modèle de Conception
Réalisation Modèle de Réalisation
Déploiement Modèle de Déploiement
BOOCH, OMT, OOSE,…
UML (Unified Modeling Language)
97
Méthodes données: UML (2) Résumé • UML est une notation, pas une méthode • UML est un langage de modélisation objet • UML convient pour toutes les méthodes objet
Programmation Orientée Objet modéliser informatiquement des éléments d'une partie du monde réel en un ensemble d'entités informatiques (objets) Intérêt d'une méthode objet • définir le problème à haut niveau sans rentrer dans les spécificités du langage • définir un problème de façon graphique • utiliser les services offertes par l’objet sans rentrer dans le détail de programmation (Encapsulation) • Réutilisation du code 98
Méthodes données: UML (3) Voiture Numéro de série : Int Poids : double Immatriculation : String Kilométrage : double
FIAT-UNO-17 233434 : Numéro de série 1500 kg : Poids 8864 YF 17 : Immatriculation 33 000 : kilométrage
Démarrer () Arrêter() Rouler()
Renault-Clio-17 5323454 : Numéro de série 1500 kg : Poids 64 YFT 17 : Immatriculation 23 000 : kilométrage
Peugeot-206-75 3434 : Numéro de série 1700 kg : Poids 8634 YGG 75 : Immatriculation 15 000 : kilométrage
99
Méthodes données: UML (4)
Vues statiques Les diagrammes Les diagrammes Les diagrammes Les diagrammes Les diagrammes
de classes d’objets de cas d’utilisation de composants de déploiement
Vues dynamiques Les diagrammes Les diagrammes Les diagrammes Les diagrammes
de séquence de collaboration d’états-transition d’activités
100
Méthodes données: UML (5)
Cas d’utilisation
Acteur
Objectif du système, motivé par un besoin d'un (ou plusieurs) acteur(s) Personne ou composant d’origine d’une interaction avec le système Documente un élément du modèle
Note
Relation d’utilisation
Le cas source contient aussi le comportement décrit dans la cas destination
101
Méthodes données: UML (6)
102
Méthodes comportements Réseaux de Pétri
C'est un ensemble d'automates à états finis communicants Pour pouvoir analyser : on représente les états internes des automates et les communications entre les automates avec les mêmes primitives Graphe avec deux types de nœuds les états (partiels = des automates) sont des ronds ce sont les places les transitions (arcs dans la représentation des automates) sont des rectangles (barres) Les communications asynchrones : ajout (ou fusion) de places synchrones : fusion (ou ajout) de transitions 103
Méthodes comportements Réseaux de Pétri (2)
104
Outils d’Analyse et d’implémentation
105
Les outils de génie logiciel Outils Outils Outils Outils Outils Outils Outils Outils
d’Analyse de design de modélisation (diagrammes) de programmation de gestion de projet de prototype de qualité de maintenance 106
Outils d’Analyse Ces outils permettent de rassembler les besoin et les obligations. Vérifier les redondance et traduite automatiquement les spécifications textes vers des schémas basique. Exemples:
Accept 360. Visual Paradigm. CaseComplete. Visible Analyst. 107
108
Outils de Design Ces outils aident les concepteurs de logiciels pour concevoir la structure du bloc du logiciel qui peut en outre être décomposé en modules plus petits en utilisant des techniques de raffinement. Ces outils montrent l’interaction entre les différents gros modules. Exemples: Animated Software Design
109
110
111
Outils de modélisation Ces outils sont utilisés pour représenter les composants du système, les données et les flux de contrôle. Ces composants sont représentés en frome graphique tout en montrant l’interaction entre les différents objets. Exemples: Flow Chart Maker, jMerise, Rational Roze, ArgoUML.
112
113
114
115
Outils de prototypage Prototype de logiciel est une version simulée du logiciel prévu. Le Prototype fournit une première impression du produit et simule quelques aspect du produit réel. Un outil de prototypage est compose de plusieurs briques graphiques pour créer une version rapide. Exemples: Windev, Dreamweaver, Mockup Builder, Visual Sudio, NetBeans.
116
Outils de prototypage (2)
117
Outils de programmation
Ces outils consistent a construire les modules et les différents composants.
Ces outils permettent aussi de générer des livrables, simuler et tester les fonctionnalités.
Exemples: Eclipse, NetBeans, Visual Studio 118
Outils de programmation: Eclipse
119
Outils de programmation: NetBeans
120
Outils de programmation: V. Studio
121
Outils de Gestion de Projet Ces outils sont utilisés pour la planification du projet, le coût, l'effort, planification de projet et planification des ressources. Les gestionnaires doivent respecter strictement l'exécution du projet à chaque étape mentionnée dans la gestion de projet logiciel. Outils de gestion de projet aident à stocker et partager des informations sur le projet en temps réel dans toute l'organisation. For example: SCRUM.
122
Les méthodes agiles
Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme
Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des clients
Concepts formalisés en 2001 par le Manifeste Agile. 123
Les méthodes agiles (2) Les 4 principes essentiels du Manifeste Agile: L'équipe : Personnes et interactions plutôt que processus et outils
L'application :Logiciel fonctionnel plutôt que documentation complète La collaboration :Collaboration avec le client plutôt que négociation de contrat L'acceptation du changement :Réagir au changement plutôt que suivre un plan.
124
Scrum – Principes clés
Scrum est une méthode agile qui permet de produire la plus grande valeur métier dans la durée la plus courte. Méthode itérative et incrémentale:
Réalisation d’un ensemble de fonctionnalités par itération Itération d’une durée fixe (d’2 à 4 semaines)// sprint
Livraison d’un produit partiel fonctionnel par itération
Participation du client:
Définition des fonctionnalités prioritaires Ajout de fonctionnalités en cours de projet (pas pendant un sprint !)
125
Scrum – Les rôles
Les rôles:
Le product owner Le scrummaster L’équipe
12 6
Scrum – Planifier un projet LCL GUR Remaining 300
250
Number
200
150
100
50
0 0
1
2
3
4
5
6
7
8
9
10
11
12
Jour
Constitution du backlog produit par le product owner.
Répartition en sprints et en releases. 127
Scrum – Organisation 1/5
Source : www.scrumalliance.org
1. Backlog produit (ou catalogue des besoins) Besoins priorisés par le product owner Besoins évalués par l’équipe 128
Scrum – Organisation 2/5
Source : www.scrumalliance.org
2. Backlog de sprint Extrait du backlog produit Besoins éclatés en tâches 129
Scrum – Organisation 3/5
3. Sprint Développement des fonctionnalités du backlog de sprint Aucune modification du backlog de sprint possible 130
Scrum – Organisation 4/5
Source : www.scrumalliance.org
4. Mêlée quotidienne Point de contrôle quotidien de l’équipe Interventions régulées – 2 min. par personne 131
Scrum – Organisation 5/5
Source : www.scrumalliance.org
5. Incrément logiciel : livré au product owner à la fin du sprint. 132
Scrum – Indicateurs de projet 1/2
Le tableau des tâches
133
Scrum – Indicateurs de projet 2/2
Le burndown chart
134
Scrum – Ingénierie logicielle
Scrum est une méthode de gestion de projet
Doit être complétée par des techniques d’ingénierie logicielle
Complémentaire avec Extreme Programming :
Test Driven Development Intégration continue 135
Outil de qualité
Assurance de la qualité dans un développement logiciel consiste a mettre en place un processus d'ingénierie et des méthodes adoptées pour développer le produit conforme selon les normes du standard.
Qualité logicielle.
136
Qualité Logiciel
Les outils de versionning
Les tests unitaires
Junit
L’intégration continue
SCM, SVN, SubVersion
Hudson, Jenkins
Les outils de compilation Inspection de code
Sonar, 137
Qualité Logiciel: Versioning
Gérer les sources dans le temps
Conserver un historique de toutes les modifications - plusieurs versions de chaque fichier
Coordonner les travaux de plusieurs auteurs
Montrer les différences entre les versions d'un fichier
Modifications du document - la raison du changement
138
Qualité Logiciel: Versioning (2) client
checkout (first time)
(do some work, test) check status update (resolve conflicts) commit (do more work, test)
server
Envoyer la version ( n ) Vérifier s’il y a des changements Mettre a jour la version locale par celle du serveur Mettre a jour le serveur par le contenu local
Qualité Logiciel: Versioning (3) Repository parent dir
Root Project 1
Project 1
trunk
trunk
tags
tags
branches
Project 2
branches
Project 2
trunk
trunk
tags
tags
branches
branches
Qualité Logiciel: Versioning (4)
/var/svn/kuclock revision 4 revision 3 revision 2 revision 1 (initial repo structure)
revision 3: content diffs author date
reason for change (comment)
revision 2: initial project check-in ...etc...
Qualité Logiciel: Versioning (5) 0
Numéro de la révision est augmentée pour chaque transaction qui modifie le repository.
1
2
3
Propriétés d’un Repository
Histoire de toutes les modifications apportées aux fichiers et répertoires. Il est possible de récupérer une version précédente d'un fichier. Contrôle d’accès
Autorisation de lecture / écriture pour les utilisateurs et les groupes Les autorisations peuvent appliquer à repo, répertoire ou un fichier
Logging
Auteur du changement La date du changement La raison du changement
SVN cycle de vie Soumettre les changements
Créer une copie locale svn checkout svn update
Subversion Repository
svn commit 106
100
Fixer les conflits
Faire des changements svn add svn move svn delete
svn diff svn resolved 105
Vérifier ce qui a été changé
svn status -u
Mettre a jour la copie locale svn update
Qualité Logiciel: Les tests unitaires
Junit
145
Qualité Logiciel: Les tests de charge
jMeter
146
Qualité Logiciel: Les tests de non régression
Cahier de Tests
MyIcIphone Client
Tel : +33 (0)2 98 14 30 40
Doc Reference
Author Audited by Approved by
Fax : +33 (0)2 98 14 39 06
Mail : [email protected]
Title Test document
File Name MyIcIphone – MyIcTestGuide.doc
Fonction
Name
Ingénieur développeur Team Leader / Contact Administrative Manager
Y. Gahi
Alcatel-Lucent Services for Enterprise All Rights Reserved © Alcatel-Lucent 2007
147
Qualité Logiciel: L’intégration continue
Spécifications
Spécifications
Développeme nt
Intégration
Développement Intégration
148
Qualité Logiciel: L’intégration continue
149
Qualité Logiciel: L’intégration continue
Hudson
150
Qualité Logicielle: Outil de compilation
Debuggage
151
Qualité Logicielle: Inspection du code
Cobertura et Sonar
152
Qualité Logicielle 4 Build + Tests 5 Déploiement
$ Gcc –c *.c –o test Compiling… Compilation Sucessfull Testing… Junit tests … OK Integration tests … OK Performance tests … OK Code Inspection … 86% Deploying in test environnement … OK
Serveur de test
6 Notification
Serveur d’intégration 3 Update
Serveur de recette
2 Vérification des
modifs
Postes de dev
Serveur de production
1 Commit
SCM
Outils de maintenance
La maintenance du logiciel comprend des modifications dans le produit logiciel après sa livraison.
Des logs automatiques, des prise d’ecrans, rapports techniques…
Exemples: Bugzilla, JIRA.
154
Outils de maintenance (2): Bugzilla
Bugzilla
155
Design Patterns
156
Les patrons de conception
Patron de conception = design pattern
Un design pattern traite un problème de conception recurrent. Ne pas réinventer la roue. Facilite la communication entre développeurs
Il apporte une solution générale, indépendante du contexte Description de l'organisation de classes et d'instances en 157 interaction pour résoudre un problème de conception
les patrons de conception (2)
Quatre éléments principaux définissent un patron Objectif
Problème / Motivation
Quand appliquer le patron de conception Relations problématiques entre les classes
Solution proposée
Description de son utilité
Eléments impliqués Relations entre les éléments Schémas conceptuels (e.g., diagrammes UML)
Conséquences
Compromis éventuels Qualité de la solution 158
Catégories de Design Patterns
Création
Structure
Description de la manière dont un objet ou un ensemble d’objets peuvent être créés, initialisés, et configurés Isolation du code relatif à la création, à l’initialisation afin de rendre l’application indépendante de ces aspects Description de la manière dont doivent être connectés des objets de l’application afin de rendre ces connections indépendantes des évolutions futures de l’application Découplage de l’interface et de l’implémentation de classes et d’objets
Comportement
Description de comportements d’interaction entre objets Gestion des interactions dynamiques entre des classes et des objets
159
Design Patterns du GoF
160
Création
Abstraction du processus de création.
Encapsulation de la logique de création.
On ne sait pas a l'avance ce qui sera créée ou comment cela sera créé.
161
Création: Singleton
Problèmes:
Certaines applications possèdent des classes qui doivent être instanciées une seule et unique fois Assurer qu'il n'existe qu'une seule instance de la classe Fournir un moyen d'obtenir cette instance unique
Solution:
Une seule instance est renvoyée a chaque fois 162
Cas d’utilisation
le cas d’une classe qui implémenterait un pilote pour un périphérique, ou encore un système de journalisation. En effet, instancier deux fois une classe servant de pilote à une imprimante provoquerait une surcharge inutile du système et des comportements incohérents.
163
Meilleur Solution La première étape consiste à empêcher les développeurs d’utiliser le constructeur de la classe pour l’instancier déclarer privé tous les constructeurs de la classe.
Nous allons construire un pseudo constructeur.
il faut déclarer une méthode statique qui retournera un objet correspondant au type de la classe
164
Exercice
On veut créer un Aeroport ainsi que des objets de type Avion. Voici le code des classes Aeroport et Avion, ainsi que de la classe test de l'ensemble.
On souhaite que les clients, les objets de type Avion, ne puisse pas créer plus d'un Aeroport,afin qu'ils se situent tous dans un même Aeroport. Comment empêcher la possibilité à un Avion de créer un Aeroport s'il en existe déjà un ?
165
Création: Factory
Problèmes:
Le client ne peut déterminer le type d'objet à créer qu'à l'exécution Il y a une volonté de centraliser la création des objets
Solutions:
Concevoir une classe qui va instancier différents types d'objets suivant un paramètre fourni Des applications individuelles de définir elles166 mêmes leurs propres objets à créer
Cas d’utilisation
une usine va fabriquer des produits en fonction du modèle qu'on lui indique. L'idée la plus simple pour répondre à ce besoin est d'écrire une succession de conditions qui suivant le modèle demandé, instancie et retourne l'objet correspondant. Le problème avec cette implémentation, c'est que la classe correspondant à l'usine va être fortement couplée à tous les produits qu'elle peut instancier car elle fait appel à leur type concret. Or ce code va être amené à évoluer régulièrement lors de l'ajout de nouveaux produits à fabriquer ou de la suppression de certains produits obsolètes.
On se retrouve alors avec du code fortement couplé, qui risque d'être dupliqué à plusieurs endroits de l'application. 167
Meilleur Solution La première solution est de regrouper l'instanciation de tous les produits dans une seule classe chargée uniquement de ce rôle. On évite alors la duplication de code et on facilite l'évolution au niveau de la gamme des produits. L'utilisateur du produit fait appel à la Fabrique Simple pour obtenir un Produit. L'utilisateur du produit est donc fortement couplé uniquement à la Fabrique Simple et non à tous les produits 168 qu'il prend en charge.
Meilleur Solution (2)
Etape 1: Créer un interface
Etape2: Créer les Classes
Etape3: Créer le Factory
169
Meilleur Solution (3)
Etape4: utiliser le Factory
170
Exercice Modifier la structure pour Eviter les duplications et optimiser l’architecture a l’aide du concept Factory. Règles: 1) On définit un interface qui contient la méthode commune. 2) Toutes les classes implémente l’interface. 3) On définit une nouvelle classe qui se charge de la création des différents objets. 4) La nouvelle n’utilise pas le type Programme1,… mais plutôt l’interface générique. 5) Le client ne communique qu’avec cette classe.
171
Structure
Ces modèles de conception tentent de composer des classes pour bâtir de nouvelles structures.
Comment sont assemblés les objets.
Découpler l'interface de l'implémentation.
On obtient donc une structure plus large mais toujours facilement manipulable.
172
Structure: Adaptateur
Problème:
L’utilisation d’une classe existante dont l’interface ne nous convient pas. Utilisation de plusieurs sous-classes dont l’adaptation des classes est impossible par dérivation
Solutions:
L'Adapteur ou Adapter est un moyen commode de faire fonctionner un objet avec une interface qu'il ne possède pas. L'idée est de concevoir une classe supplémentaire qui se charge d'implémenter la bonne interface (L'Adapteur) et d'appeler les méthodes correspondantes dans l'objet à utiliser (L'adapté). 173
Cas d’utilisation
Le système doit intégrer un soussystème existant. Ce sous-système a une interface non standard par rapport au système.
Cela peut être le cas d'un driver bas niveau pour de l'informatique embarquée. Le driver fournit par le fabricant ne correspond pas à l'interface utilisée par le système pour d'autres drivers. 174
Meilleur Solution La solution est de masquer cette interface non stantard au système et de lui présenter une interface standard. La partie cliente utilise les méthodes de l'Adaptateur qui utilise les méthodes du soussystème pour réaliser les opérations correspondantes.
175
Structure: Composite
Problème:
Etablir des structures arborescentes entre des objets et les traiter uniformément.
Solutions:
Le modèle Composite cherche à éliminer toute différence entre un groupe d'objets et un objet. Il s'agit d'une démarche récurrente valable pour tous les problèmes qui font émerger de nouvelles structure par association.
176
Cas d’utilisation
Vous avez l'impression d'utiliser de multiples objets de la même façon, souvent avec des lignes de code identiques ou presque. Par exemple, lorsque la seule et unique différence entre deux méthodes est que l'une manipule un objet de type Carré, et l'autre un objet Cercle. Lorsque, pour le traitement considéré, la différenciation n'a pas besoin d'exister, il serait plus simple de considérer l'ensemble de ces objets comme homogène.
177
Meilleur Solution
Un exemple simple consiste à considérer l'affichage des noms de fichiers contenus dans des dossiers : Pour un fichier, on affiche ses informations. Pour un dossier, on affiche les informations des fichiers qu'il contient. Dans ce cas, le patron composite est tout à fait adapté : L'Objet est de façon générale ce qui peut être contenu dans un dossier : un fichier ou un dossier, L'ObjetSimple est un fichier, sa méthode affiche() affiche simplement le nom du fichier, L'ObjetComposite est un dossier, il contient des objets (c'est à dire des fichiers et des dossiers). Sa méthode affiche() parcourt l'ensemble des objets qu'il contient (fichier ou dossier) en appelant leur méthode affiche().
178
Comportement
Description de structures d’objets ou de classes avec leurs interactions.
Le modèle de comportement simplifie l'organisation d'exécution des objets.
ils définissent comment organiser les objets pour que ceux-ci collaborent (distribution des responsabilités) 179
Comportement: Observateur
On trouve des classes possédant des attributs dont les valeurs changent régulièrement.
Un certain nombre de classes doit être tenu informé de l’évolution de ces valeurs.
180
Cas d’utilisation
On considère une classe HeurePerso possédant dans le même attribut l’heure et la minute courante. Cette classe est utilisé par une autre classe AfficheHeure pour l’affichage de l’heure courante dans un écran. Quelle démarche adopter pour que la classe chargée de l’affichage soit tenue informée en temps réel de l’heure courante stockée dans la classe HeurePerso ? Deux solutions possibles:
Soit la classe d’affichage se charge de demander à la classe HeurePerso la valeur de son attribut soit c’est la classe HeurePerso qui informe la classe AfficheHeure lors de changements.
181
Meilleur solution: Obesrvateur L’interface Observateur sera implémenté par toutes classes qui souhaitent avoir le rôle d’observateur. la classe ObservateurConcret qui implémente la méthode actualiser(Observable). Cette méthode sera appelée automatiquement lors d’un changement d’état de la classe observée. On trouve également une interface Observable qui devra être implémentée par les classes désireuses de posséder des observateurs.
182
Comportement: Iterateur
Problème:
Une collection contient un ensemble d'objets stocké par différentes méthodes (un tableau, un vecteur...). L'exploitant qui accède a contenu de la collection ne souhaite pas être concerné par cette manière de gérer les objets.
Solution:
Un seule interface qui gère tout type d’objets
183
Meilleur Solution
Un itérateur ressemble à un pointeur disposant essentiellement de deux primitives: Accéder à l'élément pointé en cours (dans le conteneur) Se déplacer pour pointer vers l'élément suivant
184
Merci pour votre attention Questions / Réponses
185