Download - Cours GL-L3NTIE Lakhrissi
Le Génie Logiciel
IUP NTIE
2010/2011
Sophie Ebersold & Younes Lakhrissi
2
Le génie logicielPartie I
Notions de base & Principes
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 3
Plan de la Partie I
1 1 -- DDééfinitions de basefinitions de baseLogicielGénie logicielCritères de la qualité logicielle
2 2 -- Cycle de vie de logicielCycle de vie de logicielObjectifPhases nominales du développement logiciel
3 3 -- ModModèèles de cycle de vieles de cycle de vieModèles linéaires Modèles non linéaires
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 4
Logiciel ?
DDééfinition : finition : Un logiciel ou une application est un ensemble de programmes, qui permet à un ordinateur ou à un système informatique d'assurer une tâche ou une fonctionnalité
Physiquement :Une suite d’items ou d’objetsune structure d’informations Incluant programmes, données, documents, …
Le logiciel n’est pas seulement un ensemble de programmes, mais aussi la documentation pour :
l’installation,l’utilisation,le développement,la maintenance.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 5
Les différentes catégories de logiciel (1/3)
Sur mesureSur mesurePour un client spécifique
GGéénnéériqueriqueVendu sur le marché• un tableur (spreadsheet), un outil de base de donnée (database) • un outil de traitement de texte (word processor)• …
EmbarquEmbarquééssExécutent dans du matériel électronique isolé
machine à laver, télévision, lecteur DVD, téléphone mobile,magnétoscope, four à micro-ondes, réfrigérateur, joueur MP3, ...
Difficile à modifier
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 6
Logiciel Logiciel àà temps rtemps rééelelSystèmes de contrôle et de surveillanceManipulent et contrôlent le matériel techniqueRéaction immédiate requiseEnvironnement contraignant
Logiciel de traitement de donnLogiciel de traitement de donnééesesIls stockent, recherchent, transforment et présentent l'information aux utilisateursGrandes quantités de données avec des corrélations complexes, enregistrées dans les bases de donnéesLargement utilisés en administration des affairesFiabilité des résultatsSécurité dans l’accès aux données
Quelques fois les 2 aspects sont prQuelques fois les 2 aspects sont préésents dans un logicielsents dans un logiciel
Les différentes catégories de logiciel (2/3)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 7
Les systLes systèèmes distribumes distribuééssSynchronisent la transmission, assurent l’intégrité des données et la sécurité, ...Technologies utiliséesCORBA, DOM/DCOM/.NET, SOAP, EJB, …
Les systLes systèèmes de matmes de matéérielrielSystèmes d'exploitation, exécutions de matériel de bas niveau
Les systLes systèèmes d'entreprisemes d'entrepriseDécrivent les buts, les ressources, les règles et le travail réel dans une entreprise
Les différentes catégories de logiciel (3/3)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 8
La nature du logiciel (1/3)
Le logiciel est facile Le logiciel est facile àà reproduirereproduireTout le coût se trouve dans son développementPour d’autres produits, la fabrication est souvent le processus le pluscoûteux
Le logiciel est intangibleLe logiciel est intangibleIl est difficile d'estimer l’effort de développement
Le processus de dLe processus de dééveloppement est difficile veloppement est difficile àà automatiserautomatiserL’industrie du logiciel exige beaucoup de main d’œuvre
Même des informaticiens peu qualifiMême des informaticiens peu qualifiéés peuvent s peuvent arriver arriver àà bricoler bricoler quelque chose qui semble fonctionnerquelque chose qui semble fonctionner
La qualité d’un logiciel n’est pas apparente
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 9
Un logiciel semble facile Un logiciel semble facile àà modifiermodifierLa tentation est forte d’effectuer des changements rapides sans vraiment en mesurer la portée
Un logiciel ne sUn logiciel ne s’’use pasuse pasIl se détériore à mesure que des changements sont effectués
en raison de l’introduction d’erreurs ou par une complexification indue
Beaucoup de logiciels sont mal conBeaucoup de logiciels sont mal conççus et se dus et se dééttéériorent riorent rapidementrapidement
La demande pour du logiciel est toujours croissanteLa demande pour du logiciel est toujours croissante
La nature du logiciel (2/3)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 10
Raisons pour lesquelles le logiciel vieillit :Raisons pour lesquelles le logiciel vieillit :Maintenance (bug fixes)Erosion architecturaleInflexibilité dès le débutDocumentation insuffisante ou inconsistanteManque de modularitéComplexité croissante, …
Un logiciel est fiable sUn logiciel est fiable s’’il :il :Répond aux spécificationsNe produit jamais de résultat erronéNe jamais entrer dans un état incohérentRéagir de façon sensée et utile en présence d’une situation inattendue
La nature du logiciel (3/3)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 11
Art de produire du logicielArt de produire du logicielArt de spécifier, concevoir, réaliser, et de faire évoluer, avec des moyens et dans des délais raisonnables, des programmes, des documentations, et des procédures de qualité en vue d’utiliser un ordinateur pour résoudre certains problèmes.
Art de bien faire de bons LogicielArt de bien faire de bons LogicielArt : technique, créativité, esthétique,…Bien faire : réussite, rentabilité,…Bons : performance, fiabilité,…
On parle de processus de dOn parle de processus de dééveloppement de logiciels et gestion de veloppement de logiciels et gestion de projets projets
Gestion du personnel : Efforts Gestion des ressources : CoûtsAspects techniques : Conception & Réalisation Contraintes de réalisations : Planification
Le Génie Logiciel ?
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 1212
Le génie logiciel
Les points communs des dLes points communs des dééfinitions finitions Travail de groupe et non d’un individu isoléBesoins techniques et non-techniques
Connaissances informatiquesCapacité de communicationGestion de projet
Objectif du GLObjectif du GLDévelopper des logiciels considérés comme :
Logiciels fiablesLogiciels satisfaisant les besoinsLogiciels maintenablesLogiciels exploitables dans différents environnement
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 13
Le génie logiciel - Origine
Origine : Apparu en 1968, devant les insatisfactions gOrigine : Apparu en 1968, devant les insatisfactions géénnéérales en rales en matimatièère de logiciel : re de logiciel :
Fiabilité douteuseDépassement des délais Dépassement des coûtsErreurs résiduelles persistantesSensibilité aux erreurs humaines, aux pannes matériellesDifficultés de conversion, de mise en œuvreDifficultés d'évolution
+ Complexité croissante du logicielCoût croissant lié en grande partie à la maintenance (excessive)
+ Criticité des secteurs d'activité
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 14
Le génie logiciel - Risques
Risques majeurs du dRisques majeurs du dééveloppement logiciel veloppement logiciel Défaillance humaine
Calendrier et Budget irréaliste
Développement de fonction inappropriées
Développement IHM inapproprié
Produit « plaqué-or »
Volatilité des besoins
Composants externes manquants
Problèmes de performances,
….
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 15
Quelques statistiques
ÉÉtude du gouvernement amtude du gouvernement amééricain en 1979ricain en 1979
Payés mais jamais livrés 45%Livrés mais jamais utilisés 30%Abandonnés ou refaits 20%Utilisés après modification 3%Utilisés tel quel 2%
Part des erreurs
64%
36%
erreurs de définition.erreurs de codage
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 16
Les critères de qualité du logiciel
Validité
Robustesse
Extensibilité
Réutilisabilité
Compatibilité
Efficacité
Portabilité
Vérifiabilité
Intégrité
Facilité d'utilisation
: Conformité d'un logiciel avec sa spécification
: Capacité à fonctionner même dans des conditions anormales
: Facilité d'adaptation à des changements de spécifications
: Capacité à être réutilisé en tout ou partie dans une nouvelle application
: Facilité avec laquelle des composants logiciels peuvent être combinés
: Utilisation optimale des ressources matérielles
: Facilité de transfert dans différents environnements
: Facilité de préparation des procédures de validation
: Aptitude à protéger codes et données
: Ergonomie, Facilité d'apprentissage
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 17
Cycle de vie du logiciel ?
Le développement d’un grand système logiciel prend un temps considérableOn identifie un certain nombre d’étapes dans la période de développementCes étapes constituent le cycle de vie du logiciel
Définition :C’est le processus qui couvre le déroulement des phases de développement, de distribution et de disparition d’un logiciel Le logiciel est le résultat d’un processus d’élaboration constitué d’une suite d’étapes ou phases ayant pour objectifs de passer du QUOI (Spécification) au COMMENT (Conception).Chaque phase utilise des produits en entrée et génère des produits en sortie, qui sont utilisés dans les phases ultérieures.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 18
Cycle de vie du logiciel
ObjectifsObjectifsMaîtriser les coûts en terme de délai et de budget
Maîtriser les risquesAvoir une qualité conforme aux exigences
C’est la feuille de route du développement logiciel
Le cycle de vie est fortement lié à l’assurance qualité
Il faudra en permanence assurer la vérification et la validationVérification : Est-ce que nous construisons bien le produit ?
Validation : Est-ce que nous construisons le bon produit ?
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 19
Cycle de vie du logiciel
Phases du cycle de viePhases du cycle de vie
Définition des objectifs
Définition des besoins
Analyse des besoins
Planification et gestion de projet
Conception globale
Codage et tests unitaires
Intégration
Qualification
Maintenance
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 20
Phase de définition des objectifs/besoins
But : Première description du futur systèmeDescription de ce que doit faire le logiciel, indépendamment de l'implantation (QUOI et non COMMENT)
Définition des objectifsÉtude de faisabilitéStratégieDécider du besoin de produire le logicielÉlaboration du schéma directeur (vue globale, orientations, suggestion, planification)
Définition des besoinsÉtablir le Cahier des Charges (CDC)Lancement d’appel d’offresLe CDC décrit les fonctionnalités attendues du produit, les contraintes non fonctionnelles (temps de réponse, contraintes matérielles,…)
Produits issus de cette phase : Le cahier des chargeProduits issus de cette phase : Le cahier des chargess
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 21
Le cahier des charges
Définition C’est un document technique Rédigé par l’équipe marketing ou par le clientS’adresse au client et aux développeurs et sera à la base du contrat
Les besoins relevés dans le CDC doivent être :PrécisCohérentsCompletsTestables par une métriqueMaintenables et flexibles
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 22
Le cahier des charges
CritCritèères de succres de succèèssSe placer à un bon niveau de généralité
Décrire bien le problème posé
Définir les critères de validation
Exprimer facilement les changements au niveau des besoins
Le rédacteur du CDC doit avoir les qualités suivantes :Capable d’abstraction et de structurationCapable de connaître et anticiper le processus de développementAvoir un recul
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 23
Phase d’analyse des besoins
But Étude du domaine d'application et de l'état actuel de l'environnement du futur système :
FrontièresRôleRessources disponibles et requisesContraintes d'utilisation et de performance
DémarcheÉlaboration des spécificationsDescription des contraintes de réalisationÉbauche du manuel d’utilisation
Produits issus de cette phase :Une ébauche du manuel d’utilisateurUne ébauche du glossaire propre au projetLe dossier d’analyse
Doit fournir une description complète et détaillée des fonctions du produit dans sa relation avec l’environnementSera utilisé par le client et par les développeursDéfinit les termes du contrat passé entre le client et le fournisseur du logiciel
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 24
Dossier d’analyse (DA): principes de base
Le DA contient la description du produit vu de lLe DA contient la description du produit vu de l’’extextéérieur, pour en drieur, pour en déériver :river :La documentation clientLes jeux de test
Dossier dDossier d’’analyse : plan typeanalyse : plan typeIntroduction
Objectifs, fonctionnalités attendues, environnement, faisablité, éléments de coûts,…
Fonctions du produitConcepts et terminologie, description fonctionnelle externe (entrées-sorties, IHM,…)
Description interneInteraction avec environnement, contraintes,…
Questions ouvertes et réponses apportées par les développeurs
Éléments de livraisonCahier provisoire de recette
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 25
Phase de planification et gestion de projet
Démarche Découpage du projet en tâchesEnchaînement de tâches dans le tempsAttribution de durée et d’effort à chaque tâche
Produits issus de cette phase :Le plan qualitéLe plan projet destiné aux développeursUne estimation des coûts réelsUn devis destiné au client
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 26
Phase de conception
Conception architecturale Définition de l’architecture du logicielDécomposition du logiciel en composants plus simples et spécification modulaireÉlaboration des interfaces entre les différents modulesProduits issus de cette phase :
Le dossier de conceptionLe plan d’intégrationLes plans de testLe planning mis à jour
Conception détailléeEnrichir la description du logiciel de détails d'implantation afin d'aboutir à une description proche de la programmation.Produits issus de cette phase :
Pour chaque composant : description des fonctions à réaliser : algorithmes, représentation des données
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 27
Phase de codage et tests unitaires
Chaque module est codé individuellementEntrée : Résultat de la conception détailléeProduit : Ensemble de programmes ou de composants de programme
Chaque module est testé indépendamment des autresProduits issus de cette phase :
Les modules codés et testésLa documentation de chaque moduleLes résultats des tests unitairesLe planning mis à jour
Part de chaque activité dans l'effort total de développement
20%
40%
40% programmationSpécification et ConceptionValidation et Vérification
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 28
Phase de gestion de configuration et Intégration
Gestion de configurationPermettre la gestion des composantsEn maîtriser l'évolutionEn faire les mises à jour tout au long du processus de développementProduits issus de cette phase :
Documents relatifs au développement du logiciel
Intégration : Assemblage de composants pour obtenir un système exécutableChaque module testé est intégré avec les autres selon le plan d’intégrationL’ensemble des modules est testé conformément au plan de testsProduits issus de cette phase :
Le logiciel testéLes tests de régressionLe manuel d’installationLa version finale du manuel utilisateur
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 29
Phase de Qualification et Maintenance
QualificationLe produit est testé en vraie grandeur dans des conditions d’utilisation normalesÀ l’issue de cette phase, le logiciel est prêt à l’exploitation
MaintenanceAprès livraison, le logiciel entre dans la phase de maintenanceAu fur et à mesure que l’environnement change, le système doit s’adapter à ces changementsCe processus de changement s’appelle l’évolution du logicielLa maintenance d’un logiciel consiste à en corriger les erreurs et àmodifier le système pour refléter les changements de l’environnement
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 30
Activités transversales
Validation et vValidation et véérificationrificationBut :
Validation : Contrôler l'adéquation entre les besoins des utilisateurs spécifiés lors de l'analyse des besoins et les fonctionnalités du logicielVérification : Contrôler l'adéquation de la spécification globale et du logiciel
Moyens : Revues, Inspections de manuels et Maquettage pour la validationPreuves et Tests pour la vérification (tests unitaires, tests d'intégration, tests système)
MaquettageMaquettageUtilisé lors de la validation, afin de fournir un aperçu des fonctionnalités du système final (prototype rapide).Soumis à de scénarii en liaison avec les futurs utilisateurs : permet de préciser leurs souhaits ou leurs choix (maquette exploratoire)Expérimentation et confrontation de choix de conception différents (maquette expérimentale)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 31
Modèles de cycle de vie
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 32
Modèles ?
DDééfinition :finition :Un modèle est une abstraction de quelque chose de réel qui permet de comprendre avant de construire, ou de retrouver les informationsnécessaires pour effectuer des modifications et extensionsLe modèle simplifie la gestion de la complexité en offrant des points de vue et niveaux d’abstractions + ou - détaillés selon les besoins
JJ--L. L. LemoigneLemoigne, 1990, 1990«Action d’élaboration et de construction intentionnelle, par composition de symboles, de modèles susceptibles de rendre intelligible un phénomène perçu complexe et d’amplifier le raisonnement de l’acteur projetant une intervention délibérée au sein du phénomène : raisonnement visant notamment à anticiper les conséquences de ces projets d’action possibles»
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 33
Modèles de cycle de vie
DDééfinition :finition :Permettent d'avoir une méthodologie commune entre le client et la société de développement Définissent et concrétisent les étapes du développementDéfinit et planifier les documents à produire permettant de valider chacune des étapes avant de passer à la suivante
Le rôle des modLe rôle des modèèles les Faciliter la compréhension humaine et la communicationSupporter l’amélioration des processus de développement et de maintenanceSupporter la conduite et la gestion des processus de développement et de maintenanceAssurer un guidage automatique des acteursFaciliter l’automatisation des processus de développement et de maintenance
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 34
Modèles de cycle de vie
Les modLes modèèles linles linééairesairesLa cascadeLe modèle transformationnelLe modèle en YLe modèle en VLe modèle en XLe modèle en W
Les modLes modèèles non linles non linééairesairesLe prototypage Le modèle en spirale Le modèle par incrémentsLe modèle évolutif
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 35
Modèles de cycle de vie linéaires
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 36
La cascade
PrincipePrincipetoutes les étapes doivent être réaliséesordre respectépassage de l'étape n à l'étape n+1 qu'après acceptation de l'étape nremises en cause de l'étape n propagées uniquement jusqu'à l'étape n-1
Définition des besoins
ConceptionLogiciel
Intégration etValidation
Maintenance
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 37
La cascade
AvantagesAvantagesFacile à comprendreCe modèle est approprié lorsque les besoins sont bien clarifiés et les changements sont très limités durant la conception du processusPlus utilisé dans l’industrie
Limites Limites Pas transparent au client lors du développementDifficulté de répondre aux besoins changeants du clientPas de frontières claires entre conception et développementDifficulté d’apporter des changements après finalisation du processusUne phase doit être achevée avant de pouvoir passer à la phase suivante
Ce modCe modèèle est en gle est en géénnééral abandonnral abandonnéé au profit du modau profit du modèèle en V plus le en V plus rréécent et actuellement, dans les mcent et actuellement, dans les mééthodes objetthodes objet
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 38
Le modèle en V
Principe :Principe :La représentation en V tient d'avantage compte de la réalitépart du principe que les procédures de vérification de la conformité du logiciel aux spécifications doivent être élaborées dès les phases de conceptionIl montre que:
c'est en phase de spécification que l'on se préoccupe des procédures de qualificationc'est en phase de conception globale que l'on se préoccupe des procédures d'intégrationc'est en phase de conception détaillée que l'on prépare les tests unitaires
Chaque étape prend en entrée les résultats de l'étape précédente et les documents produits.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 39
Le modèle en V
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 40
Le modèle en V
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 41
Modèle en W
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 42
Le modèle en Y
Un processus en 2 chemins ou modUn processus en 2 chemins ou modèèle en Y le en Y
La branche fonctionnelle correspond La branche fonctionnelle correspond àà la tâche traditionnelle de la tâche traditionnelle de modmodéélisationlisation
du domainedu problème à résoudre des besoins des utilisateurs.
L'ajout d'une branche technique indL'ajout d'une branche technique indéépendante pendante il faut faire des choix en matière de techniques
La troisiLa troisièème branche : une synthme branche : une synthèèse des 2 chemins :se des 2 chemins :articuler le mieux possible des composants "métier" avec des composants technologiques pour produire une solution logicielle
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 43
Le modèle en Y
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 44
Le modèle en Y
La branche technique ; exemples de choix :La branche technique ; exemples de choix :Une BD centrale unique ou des BD réparties qui communiquent entre elles. mise en œuvre de composants autres que le seul stockage et accès sécurisé aux données :
interfaces utilisateurs,communication de l'information via des réseaux (locaux, intranet, internet...), présentation de l'information sur les postes de travail, etc.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 45
Le modèle transformationnel
Suppose un systSuppose un systèème automatique de transformation des me automatique de transformation des spspéécifications validcifications validéées en programmes. es en programmes.
Trois scTrois scéénarios dnarios d’’automatisation automatisation 1. les spécifications formelles des besoins sont traduites à l’aide d’outils
appropriés en un logiciel opérationnel2. les spécifications formelles des besoins sont décrites et traduites à
l’aide d’outils appropriés en des spécifications détaillées exécutables3. le code est généré à l’aide d’outils logiciels tels que les générateurs de
code
Spécification
Validation
Transformation
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 46
Le modèle en X
Repose sur le principe de la rRepose sur le principe de la rééutilisabilitutilisabilitééPropose deux processus de dPropose deux processus de dééveloppement concurrents des veloppement concurrents des logicielslogiciels
Le premier processus consiste en la réalisation de solutions logicielles réutilisables (DER ou « Build for Reuse »)Le second processus consiste à produire des solutions logicielles àpartir d’une base de solutions existantes (DAR ou « Build with Reuse »)
La rLa rééutilisabilitutilisabilitéé dans le moddans le modèèle le «« en Xen X »» peut être rpeut être rééalisaliséée e ààplusieurs niveaux :plusieurs niveaux :
au niveau de l’architecture logique ou physique des composants au niveau de l’architecture conceptuelle (domaine d’intérêt du sujet)au niveau des modèles du domaineau niveau des spécifications
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 47
Les modèles de cycle de vie linéaire - Synthèse -
Avantages :Avantages :Processus ordonné et discipliné du développementConception robuste Meilleur contrôle de la qualité et la maintenance
InconvInconvéénients :nients :Pas de recouvrement des phasesEffort de documentation important à chaque phaseReprises coûteuses en cas de divergences par rapport à la compréhension des besoins utilisateur
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 48
Les modèles de cycle de vie non linéaires
PrincipePrincipeLes logiciels réalisés suivant ces modèles sont développés par itérations ou incréments successifsLes détails de réalisation peuvent être reportés afin de produire une version opérationnelle du logiciel le plus tôt possible au cours du processus de développementCes modèles semblent plus appropriés pour prendre en compte le caractère évolutif des besoins des utilisateurs et les applications novatrices
Exemples de modExemples de modèèles non linles non linééairesairesLe prototypage Le modèle en spirale Le modèle par incrémentsLe modèle évolutif
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 49
Le Prototypage
DDééfinition : finition : l’élaboration de versions opérationnelles du futur logiciel dès le début du cycle de vie la mise en évidence et la clarification par expérimentation des problèmes les plus significatifsl’élaboration de prototypes qui constituent une base de discussion et de communication entre les utilisateurs, les informaticiens et les autres acteurs de l’organisation
Le logiciel est ensuite dLe logiciel est ensuite dééveloppveloppéé àà nouveau dans le souci de satisfaire nouveau dans le souci de satisfaire les critles critèères de qualitres de qualitéé
Consulter Client
Tester le prototype
Construire oumodifier prototype
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 50
Le prototypage
SpécificationsGrossières
Réalisation du Prototype
Evaluation Spécification du système
Conception etImplantation
Validation duSystème
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 51
Le prototypage
AvantagesAvantagesClient est acteur dans le processusClient reçoit des résultats rapidementPermettre de se concentrer sur les points critiques, les zones d’incertitudes très tôt dans le développementSimplifier l’élaboration des spécifications, de l’interface H/M: les spécifications ne sont plus écrites mais montrées
InconvInconvéénients :nients :Problèmes relatifs à la conduite du développementProblèmes relatifs à la gestion de projetQualité du produit développé est souvent faibleProduit non commercialisable
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 52
Le modèle par incréments ou par grappes
Principe : Principe : Développement du logiciel noyau puis développement et intégration des composants, successivement.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 53
Le modèle par incréments ou par grappes
AvantagesAvantages : : Développement moins complexe et itératif
Développement ascendant : des incréments généraux (fonctions utilitaires) aux incréments spécifiques (proches de l’application)
Intégrations progressives : Ordonnancement flexible des incréments (fonctions des ressources, de l’expérience de l’équipe, des demandes de la direction, et des clients, …)
Ordre des étapes du cycle de vie respecté pour chaque incrément
Relations entre incréments : chaque incrément peut être client d’incréments de niveau inférieur
Livraison et mise en service possibles après chaque intégration d’incrément
Effort de maintenance dune version provisoire généralement négligeable
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 54
Le modèle par incréments ou par grappes
InconvInconvéénients :nients :Il faut spécifier dès le début du développement de l’architecture globale du logiciel et les différents lots qui seront développés: le noyau, les incréments (qui doivent être indépendants fonctionnellement), leur intégration Risque de voir remettre en cause le noyau ou les incréments précédents un développement L ’ajout de composants peut être complexe Chaque développement est de + en + complexe, du point de vue de l ’intégration
Solutions :Solutions :Spécification noyau, incréments et interactions au début du projetIncréments aussi indépendants que possible (fonctionnellement et dans le temps) : Contradiction
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 55
Le modèle évolutif
Le dLe dééveloppement veloppement éévolutif consiste volutif consiste ààrrééaliser :aliser :
une version provisoire du logiciel (prototype) qui sera mise en exploitation
des nouvelles versions de ce logiciel opérationnel (prototype) comprenant de nouvelles fonctionnalités ou une version modifiée des fonctionnalités déjà installées
La version finale comportera toute la documentation, la formation, ...pour la mise en exploitation du logiciel
Détermination des besoins
Programmation
Expérimentation
Version n +1
Version n
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 56
Le modèle évolutif
InconvInconvéénientsnientsComme dans le modèle incrémental, la réalisation d’une nouvelle version comporte plus de risques que celle de la version précédenteDifficulté d’obtenir dans les délais les résultats de l’évaluation par les utilisateurs de la nouvelle version du prototypeDifficulté de gestion des différentes versions du logiciel et de traçabilitéde leurs composantsDifficulté de déterminer le niveau de qualité du prototype et de sa documentation
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 57
Le modèle en spirale
Principe : Principe : Cycles de développement successifs du logiciel
Un prototype identifié par cycle
Quatre quadrants représentant quatre phase de développement pour chaque cycle
Analyse préliminaire, détermination des objectifs du cycle, des alternatives, des contraintes
Analyse des risques, Evaluation des alternatives, Prototypage
Développement et Vérification de la solution
Tests, Revue des résultats, Planification du cycle suivant
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 58
Le modèle en spirale
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 59
Le modèle en spirale
Avantages :Avantages :Produit rapidement un logiciel opérationnel minimal. Permet de ce concentrer sur les aspects les plus incertains du développementSuppose une discipline stricte pour éviter de « coder/finaliser ». Il faut accepter les remises en cause de la part du client à chaque nouvelle évaluationOuverture à l ’ensemble des approches et technologies de développement existantes
InconvInconvéénients:nients:Difficultés pour mener à bien les premiers cycles de la spiraleRisque de remise en cause des spécifications des modules/versions déjàréalisés lors de l ’analyse de nouveaux modules/versionsDifficultés de mise en oeuvre au niveau procédural et de contrôle du processusOrganisation opérationnelle du développement souvent modifiée pour le client
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 60
Les modèles de cycle de vie non linéaires- Synthèse -
AvantagesAvantagesPermettre de livrer rapidement une version opérationnelle du logicielPermettre de cerner les besoins des utilisateurs et des développeurs avant d ’engager des dépenses plus importantesEliminer la maintenance: le logiciel entre dans un cycle de développement-évolution permanent
InconvInconvéénientsnientsRisque de blocage dans le cas où il y beaucoup d’utilisateurs pour évaluer les versions Risque d’itérations sans fin Conduit à coder avant de finaliserProblèmes relatifs à la gestion de projet: (dérive des coûts et des délais, changement du mode opérationnel du développement fréquent pour les clients, pb de gestion de versions, ... )
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 61
Les modèles de cycle de vie- Synthèse -
Dilemme :Dilemme :Quel modèle pour quel projet ?
62
Le génie logicielPartie II
Techniques d’Analyse/Conception
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 63
Plan de la partie II
11-- Techniques de SpTechniques de Spéécificationcification
22-- Techniques dTechniques d’’Analyse et de ConceptionAnalyse et de Conception
33-- Techniques de VTechniques de Véérificationrification
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 64
Spécification ?
DDééfinition :finition :Méthodes développées pour répondre à l’évolution des matériels, des systèmes, des langages de programmation et essentiellement à la complexité croissante des logiciels.Elles permettent de «normaliser » et «formaliser » les différentes activités afin de limiter les problèmes d’incompréhension entre les différents intervenants
On distingue 3 types de spOn distingue 3 types de spéécifications :cifications :spécifications informelles
en langue naturellesemi formelles
souvent graphiques, dont la sémantique est plus ou moins préciseformelles
quand la syntaxe et la sémantiques sont définies formellement par des outils mathématiques
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 65
Différentes techniques de spécification
Techniques informellesTechniques informellesLe dictionnaire des données ou glossaire,La table de décision, …
Techniques semiTechniques semi--formellesformellesLe modèle entité-association (Entity Relationship Model),Les diagrammes de flots de données (Data Flow),Les diagrammes de structure (Structured Charts), …
Techniques FormellesTechniques FormellesLes diagrammes états-transitions,Les réseaux de Pétri, …
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 66
Techniques de spécification informelles
DéfinitionElles sont très souples, conviennent pour tous les aspects, sont très facilement communicables à des non spécialistes. Elles manquent de structuration, de précision et sont difficiles àanalyser.Des efforts peuvent être faits pour les structurer (spécifications standardisées) :
chapitres, sections, items, justifications, etc
ExemplesLe dictionnaire des données ou glossaire :
Ensemble des spécifications des données utilisées aux différents niveaux d’analyse et de conception
La table de décisionReprésentation tabulaire de tous les cas des valeurs d’entrée d’un processus et des valeurs de sortie correspondant à chacune de ces combinaisons
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 67
Techniques semi-formelles
Souvent graphiques, dont la sémantique est plus ou moins précise
Le modèle entité-association (Entity Relationship Model),Les diagrammes de flots de données (Data Flow Diagram),Les diagrammes de structure (Structured Charts), …
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 68
Le modèle entité-association
Utilisé dans de nombreuses méthodes d’analyse sous sa forme initiale ou dans des méthodes à objets sous sa forme étendueparfaitement adapté à la conception de bases de données
Concepts mis en Concepts mis en œœuvreuvre : : classe d’entité : regroupement des propriétés communes à plusieurs entitésoccurrence d’entité : représentation d'un objet matériel ou immatériel du monde réelattribut : propriété (champ)identifiant (clé) : attribut d’une entité dont la valeur permet de la désigner sans ambiguïté. relation ou association : lien entre deux classes d’entitécardinalité de la relation : spécification du nombre d’occurrence d’entités concernées
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 69
Le modèle entité-association
concerne
(1,1)
est_concerné
(0,n)
(0,n)envoie
num_propdate_arrivéeétat
code_sociéténom_sociétéadresse_société
code_projetnom_projetnom_responsabledate_limite
est_envoyé(1,1)
Envoyer
PROPOSITION PROJET
SOC-SERVICE
concerner
Cardinalitésà tout X correspond :
ExempleExemple
au plus un Y
un et un seul Y
0 ou plusieurs Y
1 ou plusieurs Y
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 70
Les diagrammes de flots de données (Data Flow Diagramm)
CaractCaractééristiquesristiquesModélisation des traitements Permettent de montrer comment chaque processus transforme ses entrées successives (flots de données entrants) en sorties correspondantes (flots de données sortants) Les DFD décrivent des collections de données manipulées par des fonctions. Les données peuvent être persistantes (dans des stockages) ou circulantes (flots de données).La représentation graphique classique distingue :
les fonctions par des cercles
les stockages par des boîtes ouvertes
les flots par des flèches
les entités externes par des rectangles
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 71
Les diagrammes de flots de données (Data Flow Diagramm)
Un DFD est souvent accompagnUn DFD est souvent accompagnéé d'un d'un diagramme de contextediagramme de contexteReprésentation des échanges de flots de données avec les acteurs extérieurs au système à modéliser
Responsable du
Projet
Société de
servicesSélection
des
propositions
critères de sélection
Proposition
Lettre d'acceptation
Lettre de refus
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 72
Saisie
SOC_SERVICES
PROJET
PROPOSITION
Acceptation
Refus
Evaluation
Note
Proposition
Lettre de refus
Lettre d'acceptation
critères de sélection
Les diagrammes de flots de données (Data Flow Diagramm)
Exemple de DFDExemple de DFD
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 73
Techniques de spécification formelles
La syntaxe et la sémantiques sont définies formellement par des outils mathématiques
ExemplesExemplesLes diagrammes états-transitionsLes réseaux de Pétri
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 74
Les diagrammes états-transitions
Matérialisent l’incidence des événements sur les différents états du système en indiquant les actions à effectuer
Sont particulièrement bien adaptés pour modéliser le cycle de vie d’un objet
permettent de préciser les valeurs d'un attribut (ex : état soumis, en examen, accepté ou refusé) défini dans le modèle entité/association
Sont plus adaptés aux systèmes synchrones qu’asynchrones
C’est une technique formelle très largement répandu pour décrire les aspects liés au contrôle
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 75
Les diagrammes états-transitions
Exercice :Exercice :Réaliser un diagramme états/transitions sur le déroulement d’un appel téléphonique.
Quelques états : En attente, En Tonalité, En numérotation, En connexion, En sonnerie,…
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 76
Les réseaux de Pétri
DDééfinition finition Outil mathématique permettant de modéliser le comportement d'un système dynamique à événements discrets.Technique formelle est particulièrement bien adaptée pour décrire le comportement des systèmes asynchrones avec des évolutions parallèles
Constituants : Constituants : Places ( ) : états du systèmetransitions ( ) : changements d'étatmarquage ( jeton ) : permettent de définir l'état du système à un instant donné
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 77
Les réseaux de Pétri
SSéémantiquemantiqueChaque place peut contenir un ou des jetons
L’état du RdP est défini par le marquage de ses places.
Si toutes les places d’entrée contiennent au moins un jeton, la transition est franchissable :
ce qui retire un jeton de chaque place d’entréeajoute un jeton dans chaque place de sortie.
Attention aux Attention aux interblocagesinterblocages !!
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 78
Les réseaux de Pétri
P1P2
P3P6
P4P5
T1T4
T3T2
P1 : Appel d'offre en coursP2 : Enregistrement propositionP3 : Examen propositionP4 : Proposition acceptéeP5 : Proposition refuséeP6 : Appel d'offre terminé (annulé)
T1 : Début d'examen(transition simple)
T2 : Critères Satisfaits(condition)
T3 : Critères non satisfaits(condition)
T4 : Arrivée date limite(événement)
ExerciceExercice
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 79
11-- Techniques de SpTechniques de Spéécificationcification
22-- Techniques dTechniques d’’analyse et de conceptionanalyse et de conceptionMéthodes fonctionnellesMéthodes orientées objet
33-- Techniques de VTechniques de Véérificationrification
Plan
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 80
Méthodes d'analyse et de conception
On distingue les approches ascendantes et les approches descendantes.
MMééthode descendante : thode descendante : Démarche par affinages successifs consistant à partir de l’expression la plus générale du problème et à décomposer de façon itérative les tâches à réaliser en sous tâches jusqu’à un niveau d’expression assez élémentaire pour pouvoir être traduit dans un langage de programmation
MMééthode ascendante : thode ascendante : Réutilisation de composants logiciels préexistants et construction de nouveaux systèmes par combinaison d’éléments prédéfinis
Certaines approchent combinent les deux, notamment dans le Certaines approchent combinent les deux, notamment dans le domaine domaine ««objet objet »»
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 81
Méthodes fonctionnelles
CaractCaractééristiquesristiquesPlus orientées vers les traitements que vers les données, mettent en évidence les fonctions à assurer et proposent une approche hiérarchique, descendante et modulaire, en précisant les liens entre les différents modulesUtilisent des notations de type DFD
ExemplesExemplesSADT (Structured Analysis and Design Technique)SA (Structured Analysis )SD (Structured Design)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 82
SADT (Structured Analysis and Design Technique)
Couvre essentiellement la première partie du cycle de vie
Suite cohérente et hiérarchisée de diagrammes obtenus par raffinements successifs
Datagramme : Représentation des données (boites) et des activités qui les créent ou les utilisent (flèches)Actigramme : description de l’enchaînement des activités (boites) et des données qu’elles manipulent (flèches).
Activités de Contrôle
Activités Productrices
Activités Consommatrices
Données de Contrôle
Données d'entréeContrôle
Données de sortieContrôle
DONNEES ACTIVITES
Unité de stockage Unité de traitement
Datagramme Actigramme
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 83
Chaque boite peut être dChaque boite peut être déécomposcomposéée en un diagramme plus de en un diagramme plus déétailltaillééVérification de chaque étape de décomposition : Respect des
informations liées aux flèches
RemarqueRemarque : Plusieurs mod: Plusieurs modèèles SADT correspondant les SADT correspondant àà diffdifféérents rents points de vue sur le systpoints de vue sur le systèème sont rme sont rééalisaliséés pour une meilleure s pour une meilleure comprcomprééhension hension
Vérification de la cohérence entre les différents modèles : par vérification systématique de la cohérence entre données et traitements au moyen de contrôles croisés d’actigrammes et de datagrammes.
SADT (Structured Analysis and Design Technique)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 84
L'analyse structurée SA (Structured Analysis )
méthode descendante par raffinages successifs des traitements et des processus.
A chaque niveau de décomposition, utilisation de la notation des DFD :
Niveau le plus haut : ensemble du problème : diagramme de contexteNiveaux inférieurs : décomposition en plusieurs processus des processus des niveaux juste supérieurs, en respectant les flots de données entrant et sortant.
Niveau de granularité maximale : processus non décomposés : une mini spécification leur est attachée, sous une forme plus ou moins formelle, afin de préciser comment les sorties sont obtenues à partir des entrées.
Un dictionnaire des données précise également la définition des données, des processus et des fichiers (ou zones de stockage).
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 85
1
3 4
2
3.1
3.3 3.4
3.2
1.1
1.3
1.22.1
2.2
4.1 4.2
4.3
L'analyse structurée SA (Structured Analysis )
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 86
MMééthodes dthodes d’’analyse conception analyse conception orientorientéées objetes objet
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 87
Méthodes d'Analyse et de conception orientées objet
La conception propose une solution au problème spécifié lors de l’analyse :
architecture de l’application (architecture logicielle et architecture physique),description détaillée des modules, des interfaces utilisateurs, des données.
L'objet outil de modélisation : Une méthode d'analyse et de conception par objets apporte en plus une démarche pour faire émerger un modèle de données et une analyse de leur comportement. Idée : objet = unité principale de décomposition de systèmesPoint de départ : Travaux de G. Booch sur la conception de logiciels avec ADA
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 88
Classe :Classe :Décrit une collection d'objets ayant même structure et même comportement.
La structure (ensemble des données) est constituée des attributsLe comportement est décrit par des méthodes
Les instances de la classe sont les objetsPossède une interface (publique, protégée, privée)
Objet : Objet : Instance d’une entité particulièreA une identité uniquePossède un état : valeurs particulières de ses attributs Communique avec les autres objets par envoi de messages, activation de méthodes
Seules les méthodes de l'objet sont habilitées à modifier ses valeurs d'attributs La réalisation de l'action associée à un envoi de message dépend de l'objet récepteur qui gère ses propres attributs avec ses propres méthodes
Méthodes d'Analyse et de conception orientées objet - Concepts
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 89
HHééritage : ritage : Relation d'inclusion conceptuelle entre classes : les sous-classes héritent de la structure et du comportement de leurs super-classes.Enrichissement, spécialisation, fusion font partie du concept d'héritage.
Associations et liens :Associations et liens :Représentation au niveau des classes des liens qui unissent les objets (association, agrégation, composition)
Méthodes d'Analyse et de conception orientées objet - Concepts
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 90
Trois aspects : Trois aspects :
Dimension Structurelle :propriétés des objets et liens
Dimension TemporelleComportement des objets : description des changements d'états (valeurs, événements)
Dimension Fonctionnelle :fonctions réalisées par les objets par l'intermédiaire des méthodes
Méthodes d'Analyse et de conception orientées objet - Concepts
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 91
Méthodes d'Analyse et de conception orientées objet
Quelques mQuelques mééthodes :thodes :OOA -OOD (Coad et Yourdon)OODa, OOADa (Booch)OOSA (Shlaer et Mellor)OOSE (Jacobson)OOM (Rochfeld)OMT (Rumbaugh)HOOD (ESA)RAD(Rationnal)RUP (Rationnal)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 92
OMT (Object Modeling Technique)
DescriptionDescriptionCouvre les phases d'analyse et de conception en utilisant le même formalismeTrois points de vue analytiques (statique, dynamique, fonctionnel)Trois modèles : objet, dynamique, fonctionnel.
Avantages de OMT: Avantages de OMT: modèle statique très richenombreux domaines d'applications Unifiée avec la méthode OODa UML
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 93
OMT - Le modèle objet
Description graphique de la structure : Description graphique de la structure : diagramme des classes
Processus de construction du modProcessus de construction du modèèle objet : le objet : Identifier les classes d'objetsFaire un dictionnaire des donnéesIdentifier et ajouter les associations entre les classesIdentifier et ajouter les attributs aux classes et aux associationsOrganiser et simplifier les classes grâce à l'héritageTester les chemins d'accès en utilisant des scénariiGrouper les classes en modules
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 94
OMT - Le modèle objet
PERSONNE nomINSEEadresse déménager
ENTREPRISEnomadresse
travaille-pour
SERVICES………
salairefonction
salariéemployeur
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 95
OMT - Le modèle dynamique
DDéécrit les aspects temporels et le crit les aspects temporels et le ssééquencementquencement des opdes opéérations :rations :événements, scénarii, états, organisation des événements et des états
Formalisme graphique de reprFormalisme graphique de repréésentation : sentation : Diagrammes états-transitions
Processus de construction :Processus de construction :Préparer les scénarii de séquences d'événements typiquesIdentifier les événements entre objets et préparer pour chaque scénario une trace des événementsPréparer un diagramme de flots d'événements pour le systèmeDévelopper un diagramme d'états pour chaque classeVérifier la complétude et la cohérence des événements communs àplusieurs diagrammes d'états
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 96
OMT - Le modèle fonctionnel
DDéécrit les aspects licrit les aspects liéés s àà la transformation des valeurs des objetsla transformation des valeurs des objetsFonctions, contraintes, dépendances fonctionnelles
Formalisme de reprFormalisme de repréésentation : sentation : Diagrammes de flots de données
Processus de construction :Processus de construction :Identifier les valeurs d'entrée-sortieUtiliser des DFD pour montrer les dépendances fonctionnellesDécrire ce que fait chaque fonctionIdentifier les contraintesSpécifier les critères d'optimisation
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 97
La méthode MERISE
Version 1 :Version 1 :Approche systémique (liens système d'information - système opérant, SI - système de pilotage)
Couverture de tout le cycle de vie du logiciel (schéma directeur, études préalable, étude détaillée, étude technique, production de logiciels, mise en œuvre, maintenance)
Cycle d'abstraction sur trois niveaux (conceptuel, organisationnel, physique)
Séparation modèles de données et modèles de traitements
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 98
Merise : Les modèles
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 99
Merise - Niveau conceptuel
Modèle conceptuel des données (ou MCD), schéma représentant la structure du système d'information, du point de vue des données
les dépendances ou relations entre les différentes données du système d'informationpar exemple : le client, la commande, la ligne de commande, etc.,
Modèle conceptuel des traitements (ou MCT), schéma représentant les traitements, en réponse aux événements àtraiter par exemple : la prise en compte de la commande d'un client
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 100
Modèle Logique des Données (MLD), reprend le contenu du MCD précédent, mais précise la volumétrie, la structure et l'organisation des donnéestelles qu'elles pourront être implémentées. Par exemple, à ce stade, il est possible de connaître la liste exhaustive des tables qui seront à créer dans une base de données relationnelle
Modèle Logique des Traitements (MLT ou MOT), précise les acteurs et les moyens qui seront mis en œuvre. C'est ici que les traitements sont découpés en procédures fonctionnelles. décrit avec précision l’organisation à mettre en place pour réaliser une ou, le cas échéant, plusieurs opérations figurant dans le MCT. Il répond aux questions suivantes : qui ? quoi ? où ? quand ? À un MCT correspondent donc généralement plusieurs MOT.
Merise - Niveau logique ou organisationnel
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 101
Merise - Niveau physique
Modèle Physique des Données (MPD) permet de préciser les systèmes de stockage employés (implémentation du MLD dans le SGBD retenu)
le Modèle Physique des Traitements (MPT)permet de spécifier les fonctions telles qu'elles seront ensuite réalisées par le programmeur.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 102
Merise
Version 2 :Version 2 :Enrichissement des traitements au niveau conceptuel par l'introduction :
de diagrammes de flots de données
d'un Modèle Conceptuel des Traitements Analytiques (considération des données qui s'y rattachent dés la conception préparation de la validation)
de la notion de Cycle de Vie d'un Objet
Enrichissement au niveau logique par la prise en compte des structures , des moyens matériels et humains àmettre en place
la définition des interfaces avec les utilisateurs
les ressources logiques de traitements et de stockage, la répartition des données
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 103
Orientation Objet dans Merise
Version 3 : Version 3 : Trois dimensions : statique, dynamique, fonctionnelleProcessus :
Développement de la dimension fonctionnelle : permet de représenter les frontières du système à modéliser par rapport à son environnement.
Utilisation d'un diagramme de contexte.Définition des besoins par des DFD
Importance de la dimension statique, la plus stable dans le tempsRepose sur un modèle E/A étenduAssociation à chaque objet de son comportement, par l'intermédiaire des méthodes apparues dans le DFD
Représentation de l'enchaînement des opérations dans différents scénarii, les opérations pouvant rassembler les services de plusieurs objets : modèles de traitements classiques de MERISE + objets sur lesquels portent les traitements
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 104
Méthode Macao (IUT Blagnac)
Démarche participative par prototypage incrémental (spirale)MACAO utilise la notation UML
structure du logiciel en termes de classes et de composants, dynamique à l'aide de diagrammes d'interactions ou d'états/transitions
A partir des Cas d'Utilisation obtenus par interviews des utilisateurs, deux types de modèles originaux sont utilisés pour représenter l'IHM du logiciel :
un modèle conceptuel construit à partir du diagramme des classes et de patrons de conception un modèle de réalisation permettant une mise en œuvre optimum en langage JAVA sous Windows ou LINUX, ou en HTML pour les applications Intranet.
Afin de limiter les tests de non régression toujours très lourds et coûteux, MACAO applique à chaque prototype réalisé le principe de non régression basé sur l'encapsulation et l'héritage
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 105
Méthodes d'analyse/conception- Synthèse -
Tentative de standardisation des mTentative de standardisation des mééthodesthodes : : Applicables quel que soit le secteur d’activitéHarmonisation des méthodes existantesTerminologie uniqueNormalisationDéfinition d’un métamodèle : le modèle structurel
NNéécessitcessitéé dd’’introduire des techniques formelles et des outils pour introduire des techniques formelles et des outils pour spspéécifier et prouver les rcifier et prouver les réésultats de lsultats de l’’analyse et couvrir tout le analyse et couvrir tout le cycle de vie.cycle de vie.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 106
UMLUnified Modelling Language
DescriptionDescription
Il est né en début de 1997 dans l'optique d'unifier les méthodes d'analyse et de conception des systèmes.
Consensus autour des méthodes existantes (OMT, OOSE, OOA/OOD)
se définit comme le langage, standard, universel de modélisation graphique et textuelle.
Notation couvrant toutes les phases du cycle de vie logiciel
Issu de la recherche de l’OMG
L'OMG adopte en novembre 1997 UML 1.1 comme langage de modélisation des systèmes d'information à objets.
La version d'UML actuelle est UML 2.3 (mai 2010)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 107
UML
Diagrammes UML utilisables tout au long du projetanalyse → conception → implantation
les les composants composants
logicielslogiciels
la structuration la structuration des objetsdes objets
la dynamique la dynamique des objetsdes objets
les fonctions les fonctions du systdu systèèmeme
ll’’architecture architecture physiquephysique
Vue implantation
Diagrammescomposants
Vue externecas
d’utilisation
Vue logique statique
Diagrammes classes, objets, collaborations, séquences
Vue logique dynamique
Diagrammesétats, activités
Vue déploiement
Diagrammes déploiement
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 108
Diagramme de classes
Diagramme de composants
Diagramme d'objets
Diagramme de structure composite
Diagramme de packages
Diagramme de déploiement
Diagramme de séquence
Diagramme de communication
Diagramme de temps
Diagramme de vue d'ensemble des interactions
Diagramme d'états
Diagramme d'activités
Diagramme de cas d'utilisation
Diagramme comportementalDiagramme structurel
Diagramme UML2
Diagramme d'interaction
UML 2.3 (Mai 2010)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 109
UML – Cas d’Utilisation
Permet d'identifier les fonctionnalités que doit fournir le système Identifier les acteurs interagissant avec le système
Exemple :Exemple :Gérer les voitures
réparer
proceder à l'expertise
enregistrer
MecanicienElectricien
Maintenicien
effectuer le test
Client
ResponsableAtelier
ChefAgence
effectuer maintenance
<<extend>>
<<include>>
<<extend>>
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 110
UML – Diagramme de classes
représentant la Structure statique d'un modèle, à savoir les éléments classes et types, et leurs relations les uns par rapport aux autres.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 111
UML- Diagramme de Séquences
Exemple qui modélise l'envoi, par un enseignant, des notes d'une classe d'étudiants à l'administration et le traitement effectué sur ces notes.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 112
UML – Diagramme états/transitions
montre les différents états d’un objet ainsi que les transitions entre ces états
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 113
UML - diagramme de composants
Exemple :Exemple :
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 114
UML
SynthSynthèèsese
La version d'UML actuelle est UML 2.3 (mai 2010)
Les travaux d'amélioration d’UML se poursuivent !
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 115
11-- Techniques de SpTechniques de Spéécificationcification
22-- Techniques dTechniques d’’analyse et de conceptionanalyse et de conception
33-- Techniques de VTechniques de Véérificationrification
Plan
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 116
Test de Logiciel
DDééfinitionfinitionRecherche d'inadéquation d'un logiciel par rapport à des références établies : spécifications du logiciel, normes ou règles portant sur son code ou les documents le concernant
Classification des mClassification des mééthodes thodes Tests statiques ( traitent le texte du logiciel : spécifications ou programmes)Tests dynamiques (exécution effective du logiciel sur un sous-ensemble du domaine de ses entrées possibles)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 117
Approches de Vérification
Vérification dynamique : expérimenter le comportement de l’application (la tester) avec un ensemble bien choisi de données;
Les tests ont pour but de mettre en évidence les erreurs. Les tests peuvent prouver la présence d’erreurs mais ne peuvent pas prouver leur absence
Vérification statique : analyser les propriétés du système, sans exécution ;
Les techniques informellesLes techniques formelles
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 118
Test ou vérification dynamique
Les test unitaires de programmes ou de modulestest d’un programme isoléeffectué par simulation des comportement des modules appeléset par simulation les appels du module
Les tests d’intégrationAprès avoir testé unitairement les modules il faut tester leur intégration progressive jusqu’à obtenir le système complet
Les test de réceptioneffectué par le client, avec la participation du fournisseur, pour vérifier que les dispositions contractuelles sont bien respectées
Les tests de non régressioneffectué à la suite de la modification d'un logicielIl a pour but de montrer que les autres parties du logiciel n'ont pas étéaffectées par cette modification
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 119
Vérifications statiques
Lectures croisées et inspection :vérification d'un document par des relecteurs différents des auteurs, puis vérification par des groupes de relecteurs ayant des rôles différents sur le projet (chef de projet, auteur du document, responsables de tests,…)
Analyse d'anomalies : Établissement d'un critère d'acceptabilité des programmes testésConstruction d'un graphe (graphe de contrôle, flot de données, graphe de dépendances, réseau de Pétri, graphe de transitions,…) représentant un sous-ensemble des informations pour vérifier les critères choisisÉtude des chemins du graphe avec un prédicat portant sur la satisfaction des critères établis
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 120
Vérifications statiques
Les techniques informelles
Il s’agit d’activités réalisées par un groupe d’inspecteurs qui examinent un document à la recherche d’erreurs
parmi les erreurs classiques en programmation on peut citer :l’utilisation de variables non initialisées,les affectations incompatibles,les boucles infinies,les débordements de tableaux,les allocations et libérations impropres de zones mémoire,etc.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 121
Vérifications statiques
Les techniques formellesprouver formellement la correction d’un programme
Le programme est caractérisé par sa précondition (condition éventuelle àrespecter par les données du programme) et sa postcondition (condition vraie à la fin du programme qui définit donc son objectif)Technique basée sur les assertions logiques
Évaluation symboliqueSimulation de l'exécution du programme sur des données symboliques
expressions symboliques correspondant au texte des programmesUtilisation de graphe de contrôle Parcours du graphe à partir de données en entrée, jusqu'aux données de sortie : production d'une expression symbolique retraçant les calculs effectués et les conditions associées
122
Le génie logicielPartie III
Génie Logiciel Avancé
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 123
Plan
11-- ÉÉvolution des technologies dvolution des technologies d’’analyse conceptionanalyse conceptionOCL Object Constraint LanguagePatrons (patterns) Technologie des composantsL’architecture MVCProgrammation par Aspect (Aspect Oriented Programming)OMG-MDA Model Driven Architecture
22-- ÉÉvolution des processus de dvolution des processus de dééveloppementveloppementProcessus UnifiéMéthodes agiles
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 124
Les limites de la programmation par objets
Absence de vision globale de l'application Absence de vision globale de l'application les principaux concepts sont définis au niveau d'un objet individuel pas de notion de description globale de l'architecture
DifficultDifficultéé d'd'éévolution volution conséquence de l'absence de vision globale
Absence de services Absence de services les services nécessaires doivent être réalisés ''à la main'' (persistance, sécurité, etc.)
Conclusion Conclusion charge importante pour le programmeur incidence sur la qualité de l'application une partie du cycle de vie n'est pas couverte
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 125
Construction des systèmes complexes
Les nouvelles Exigences :Besoins fonctionnels en constante augmentationBesoins techniques complexes et évolutifsMultiples acteurs, …
Conséquence :des composants complexes et hétérogènes …
Symptômes :Dispersion : une fonctionnalité est distribuée dans tout le système, et non pas placée dans une unité bien identifiéeCouplage des fonctionnalités : le cas où une unité contient des éléments provenant de différentes préoccupations
!Réutilisation
Évolution
Traçabilité
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 126
Évolution des technologies en Génie Logiciel
Abandon de la Technologie Objets pour la Technologie Modèles (J. Bézivin)
Technologie des Procédures
Technologie des Composants
Technologieà Objets
Objets,Classes,
Smalltalk, C++,...
Procédures,Pascal,
C,...
Packages,Frameworks,
Patterns,…
1980 1995 2000
Raffinement Procédural
CompositionDes Objets
Technologie des Modèles
TransformationDe Modèles
Modèles, Méta-modèles,
UML, MOF,XML, XMI,,…
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 127
Qualité du logiciel : Evolution des technologies
Parlons les mêmes langages et partageons les mêmes technologies Parlons les mêmes langages et partageons les mêmes technologies !!Les standard de l’OMG : UML, XMI, CWM, CORBA, IDL, …
Expression de contraintes sur les modExpression de contraintes sur les modèèles UML les UML OMG-OCL
AdaptabilitAdaptabilitéé, extension d, extension d’’UMLUMLProfils UML
InteropInteropéérabilitrabilitééMéta-modélisationOMG-MDA
RRééutilisation des solutions utilisation des solutions Composants, Patrons de conception
SSééparation des prparation des prééoccupations occupations Aspect, pt vue
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 128
Object Constraint LanguageOCL
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 129
OMG - OCL (Object Constraint Language)
Pour spécifier complètement une application :Diagrammes UML seuls sont généralement insuffisantsNécessité de rajouter des contraintes
Comment exprimer ces contraintes ?Langue naturelle mais manque de précision compréhension pouvant être ambigüeLangage formel avec sémantique précise : par exemple OCL
OCL : Object Constraint LanguageOCL est un langage formel pour l’expression de contraintes, standardisé par l’OMG.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 130
OCL (Object Constraint Language)
Description
Langage de contraintes orienté-objet
S'applique sur les diagrammes UML
OCL se veut un langage formel permettant de décrire ces contraintes de façon déterministe.
Il se veut simple à écrire ainsi qu’à comprendre.
Langage formel (mais simple à utiliser) avec une syntaxe,
une grammaire, une sémantique (manipulable par un outil)
OCL est purement un langage interrogatif : en aucun cas il ne peut modifier le modèle auquel il se rapporte. On parle de langage sans effet de bord, ou side-effect free.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 131
Utilisation d’OCL
OCL permet principalement d'exprimer des contraintes sur l'état d'un objet ou d'un ensemble d'objets :
Des invariants qui doivent être respectés en permanence
Des pré et post-conditions pour une opération :Précondition : doit être vérifiée avant l'exécution
Postcondition : doit être vérifiée après l'exécution
Gardes sur transitions de diagrammes d'états ou de messages de diagrammes de séquence/collaboration
Des ensembles d'objets destinataires pour un envoi de message
Des attributs dérivés
Des stéréotypes
...
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 132
OCL par des exemples (1/3)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 133
OCL par des exemples (2/3)
ContexteUne expression OCL est toujours définie dans un contexteCe contexte est une instance d'une classeMot-clé : context
Un invariant exprime une contrainte sur un objet ou un groupe d'objets qui doit être respectée en permanenceMot-clé : inv:
Exemple : Pour toutes les instances de la classe Company, le nombre des employés doit toujours être supérieur à 50
context Company inv: self.numberOfEmployees > 50
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 134
OCL par des exemples (3/3)
Pour spécifier une opération :Précondition : état qui doit être respecté avant l'appel de l'opérationPostcondition : état qui doit être respecté après l'appelMots-clés : pre: et post:Exemple : La somme à débiter doit être positive pour que l'appel de l'opération soit valide :
context Compte::débiter(somme : int)pre: somme > 0post: solde = solde@pre – somme
Dans une contrainte OCL associée à un objet, on peut :Accéder à l'état interne de cet objet (ses attributs)Naviguer dans le diagramme : accéder de manière transitive à tous les objets (et leur état) avec qui il est en relation
context Companyinv: self.manager.isUnemployed = false inv: self.employee->notEmpty()
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 135
La rLa rééutilisation dans lutilisation dans l’’ingingéénierie logiciellenierie logiciellePatrons (patterns) Technologie des composants
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 136
Réutilisation dans l’ingénierie logicielle
DDééfinitionfinition ::Un composant réutilisable :
traite un problème récurrent de l’ingénierie des SI, capitalise un fragment de produit ou de processus, offre une solution conceptuelle et/ou logicielle testée, acceptée et adaptable.
La réutilisation ne doit plus être limitée aux produits logicielsUne très grande variété de composants réutilisables.Conséquences :
Nécessité de classifier, documenter, organiser, composer les composants…Nécessité de démarches centrées réutilisation.
ConsConsééquences sur les produitsquences sur les produits : : Plus rapides à développer, Plus faciles à maintenir, Certainement meilleurs, Moins originaux.
Technologie des composantsPatrons (Design patterns)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 137
Réutilisation dans l’ingénierie logicielle
Expression des besoins
Analyse (abstraction du monde réel)
Conception (solution technique)
Implantation (solution opérationnelle)
Patrons d’analyse Modèles de domaine Composants métiers conceptuels
Patrons d’architecture Patrons de conception ERP, Frameworks
Patrons d’implantationComposants métiers logicielsBibliothèques de classes
SpécificationsInformelles
ModèleDescriptif & Normatif
Informatisable
ModèleEffectif Informatisé
Logiciel
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 138
Technologie des patrons
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 139
Patron
IntroductionIntroduction
La beauté est-elle subjective ou existe-t-il des critères permettant de distinguer ce qui est beau de ce que ne l’ai pas ?
Par exemple, si une personne doit concevoir l’entrée d’une maison, peut-elle savoir objectivement si son projet est bon ?
les individus d’une même culture sont généralement d’accord sur ce qui peut être considéré comme une bonne conception.
Ces raisonnements peuvent être appliqués à la qualité d’un logiciel ?
en quoi une conception est-elle bonne au mauvaise? Quels aspects les différentient ?
les bonnes constructions qui rles bonnes constructions qui réésolvent le même problsolvent le même problèème ont des me ont des points communs (qualifipoints communs (qualifiéés de patrons).s de patrons).
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 140
Patron
DDééfinition: finition: « une solution apportée à un problème dans un contexte donné »« chaque patron décrit un problème récurrent dans notre environnement, puis le cœur de la solution qui sera réutilisable indéfiniment, quelle que soit la mise en pratique choisie »
Exemple: CrExemple: Crééation textile ation textile
Difficile !!!! Solutions prédéfinies Projet réussi
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 141
Intérêt des patrons
RRééutiliser les solutionsutiliser les solutions : : En utilisant des solutions prédéfinies, on évite les pièges de début de projet et on bénéficie de l’expérience d’autre concepteurs. On n’a pas àréinventer des solutions à des problèmes récurrents.
AmAmééliorer la communication et lliorer la communication et l’’apprentissageapprentissage : : Les patrons impliquent l’adoption d’une approche commune au sein d’une équipe de développeurs. Ils constituent une même référence pour tous lors des phases d’analyse et de conception d’un projet, ce qui simplifie bien évidement la communication.
Souplesse du logicielSouplesse du logiciel : : La plupart des design patterns facilitent la modification ultérieur du logiciel.
Ils apportent donc des solutions plus facilement modifiables queIls apportent donc des solutions plus facilement modifiables quecelles auxquelles vous pouvez penser en dcelles auxquelles vous pouvez penser en déébut de projet.but de projet.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 142
processus
entreprise
domaine
générique
analyse
concepti
on
implanta
tion
Coad GoF
SIP
Coad GoF
Ambler
Systèmes de patrons
[ LSR-IMAG ]
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 143
Systèmes de patrons
“Un patron processus fournit une collection de techniques, d’actions et/ou de tâches à suivre pour le développement des logiciels”. Ambler 98
« Un langage de patrons est une collection structurée de patrons construits l’un sur l’autre pour transformer les besoins et les contraintes dans une architecture ». C. Alexander / J. Coplien
Un patron constitue une base de savoir et de savoir-faire pour résoudre un problème récurrent dans un domaine
Un système de patrons est une collection de patrons coordonnés intégrant une démarche de conception pour résoudre un problème complexe
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 144
Patrons de Conception de GOF :
GOF: Gang of Four = la bande des quatreErich Gamma, Richard Helm, Ralph Johnson and John Vlissides.
Creational Structural Behavioral
Class • Factory Method • Adapter • Interperter
ScopeObject
• AbstractFactory
• Builder• Prototype• Singleton
• Adapter• Bridge• Composite• Decorator• Facade• Flyweight• Proxy
• Chain of Responsibility• Command• Iterator• Mediator• Momento• Observer• State• Strategy• Vistor
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 145
Exemple 1 : Patron Composite
ExerciceExercice
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 146
Exemple 1 : Patron Composite
Structure du patron CompositeStructure du patron Composite
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 147
Exemple 2 : Patron Observateur (E. Gamma)
ObjectifPermettre à un objet de prévenir un ensemble d'autres objets inconnus au moment de sa conception de certains changements de son état
ProblèmeCertains changements d'état d'un objet O sont susceptibles d'en intéresser d'autresCes autres objets sont inconnus lors de la conception de O
SolutionFaire gérer à O une liste d'observateurs (ou écouteurs) et les prévenir lors des changements d'états intéressants
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 148
Exemple 2 : Patron Observateur
1 sujet
Ouest = 33,5Nord = 12,4Est = 44,0Sud=10,1
2003
Ouest
Nord
Est
Sud
0
5
10
15
20
25
30
35
40
45
50
OuestNordEstSud
3 observateurs
Patron de conception Observateur (E. Gamma)Patron de conception Observateur (E. Gamma)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 149
Exemple 2 : Patron Observateur
Structure du patron ObservateurStructure du patron Observateur
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 150
Structure d’un patron
Description dDescription d’’un patronun patronNomIntentionMotivationIndication d’utilisationStructureConstituantsConséquencesImplémentationExemples de codeModèles apparentés
ProblemProblem
Context
SolutionSolution
Benefits
Related Patterns
Consequences
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 151
Ingénierie des patrons
Identifier les problèmes
Construire un
référentiel
Analyser lesmodèles existants
Identifier lesproblèmes
Intégrer le patron associé
dans le catalogue
Définir de nouveaux patrons dérivant des
patrons existants
Décomposer le problèmeen sous-problèmes
Définir nouvelle
solution
Problème déjà traité
raffinement d'unproblème
Nouveau problème
Problème décomposable
Spécifier les solutions
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 152
Technologie des composants
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 153
Composants : description
classe avec ses connexions figées (les associations avec les autres classes matérialisent des liens structurels), ne constitue pas une réponse adaptée à la problématique de la réutilisation
Description Description La réutilisation est l’aptitude d’un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applicationsLes composants permettent la construction d'applications par composition de briques de base configurables Un composant est un module logiciel autonome
unité de déploiement (installation sur différentes plates-formes) unité de composition (combinaison avec d'autres composants)
Facilite la compréhension globale du système outil de documentation
Facilite le processus d'évolution modification des composants (interface, réalisation) modification des relations entre composants modification du déploiement
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 154
PropriPropriééttéés s spécifie explicitement la ou les interface(s) fournie(s) spécifie explicitement la ou les interface(s) requise(s) peut être configuré
La programmation par composants constitue une évolution technologique soutenue par de nombreuses plateformes :
EJB (Enterprise JavaBeans) CORBA (Common Object Request Broker Architecture) WSDL (Web Services Description Language).Net, , …
Ce type de programmation met lCe type de programmation met l’’accent sur la raccent sur la rééutilisation du composant et utilisation du composant et ll’’indindéépendance de son pendance de son éévolution visvolution vis--àà--vis des applications qui lvis des applications qui l’’utilisent.utilisent.
Composants : description
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 155
Composants : modèle générique
Composant
Propriété configurables(interfaces spéciales avec accès restreint)
Contraintes techniques• placement, sécurité• transactionnel, persistance• interfaces fournies par le système (bibliothèques, etc.)
Interfaces requises(fournies par d’autres
composants)Interfaces fournies
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 156
Support logiciel pour composants
Pour assurer leurs fonctions, les composants ont besoin d'un supPour assurer leurs fonctions, les composants ont besoin d'un support port logiciel logiciel
Conteneur Conteneur encapsulation d'un composant prise en charge des services du système
nommage, sécurité, transactions, persistance, etc. prise en charge partielle des relations entre composants (connecteurs)
invocations, événements techniques utilisées : interposition, délégation
Structure d'accueil Structure d'accueil espace d'exécution des conteneurs et composants médiateur entre conteneurs et services du système
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 157
Mise en œuvre des composants
Structure d’accueil
Conteneur
Structure d’accueil
Conteneur
Conteneur
Composant
Composant
Composant
Client
Bus logiciel + services (désignation, persistance, transaction, sécurité,etc.)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 158
Composants : situation
Premiers produits, ne rPremiers produits, ne réépondent pas encore pondent pas encore àà tous les besoins tous les besoins Java Beans, (Enterprise Java Beans)COM (Component Object Model ) DCOM (Distributed COM ) .NET
DDéébut de normalisation but de normalisation Composants CORBA (OMG), normalisation en cours (CORBA 3)
Ce qui manque encore Ce qui manque encore Descriptions d'architectures
prototypes de recherche, produits encore attendus Support pour déploiement, évolution, configuration
travaux en cours à l'OMG (OSD : Open Software Description) Aide à la conception
travaux sur l'extension de l'UML
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 159
Exemple : CORBA (Common Object Request Broker Architecture)
Standard de lStandard de l’’OMGOMG
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 160
Réutilisation dans l’ingénierie logicielle
Expression des besoins
SpécificationsInformelles
Modèle Descriptif & Normatif
Informatisable
ModèleEffectif Informatisé
Logiciel
Analyse (abstraction du monde réel)
Conception (solution technique)
Implantation (solution opérationnelle)
CCOOMMPPOOSSAANNTTSS
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 161
Technologie des composants - Synthèse -
DDééveloppement pour et par la rveloppement pour et par la rééutilisationutilisation
Par réutilisationPour la Réutilisation
Concepteur de composants Ingénieur d’applications
Ingé
nier
ie
d’ap
plic
atio
ns
Application
Ingé
nier
ie d
e co
mpo
sant
s
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 162
L’architecture MVC
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 163
L’architecture MVC
ButIsoler la donnée elle-même de sa présentationDistinguer la consultation de la modification
PrincipePour une donnée, trois composantes distinguées et séparées
Le modèle (sa structure)La vue (sa représentation pour affichage)Le contrôleur (les moyens de modifier la valeur)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 164
L’architecture MVC
Utilisateur
VueContrôleur
Modèle Métier
utilise
Choisi la vue appropriée
manipule,
envoi de requête met à jour,
réponse
présente le résultat
StructureStructure
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 165
MVC - Le modèle
RôleEncapsuler les propriétés d'une donnéeÊtre indépendant des vues et contrôleurs
ConséquencesDéfinir les accesseurs aux propriétés de cette donnéeMaintenir une liste d'écouteurs (vues et contrôleurs se déclarent comme écouteurs)Prévenir les écouteurs lorsque la donnée est modifiée
Implantation du design pattern Observer
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 166
MVC - Le contrôleur
RôlePermettre à l'utilisateur de modifier la donnée encapsulée dans le modèle
ConséquencesDoit éventuellement s'enregistrer comme écouteur du modèle pour être mis à jour si le modèle est modifiéDoit appeler les accesseurs du modèle en fonction des actions de l'utilisateur
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 167
MVC – la vue
RôleReprésenter la donnée encapsulée via un modèleSe maintenir à jour lorsque le modèle est modifié
ConséquencesDoit s'enregistrer comme écouteur au niveau du modèle
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 168
Exemple : Application du MVC au web
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 169
La multiLa multi--modmodéélisationlisation
Programmation par Aspect(Aspect Oriented Programming)
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 170
La multi-modélisation
Séparation des préoccupations pour simplifier la modélisationDécomposition des exigences
Assemblage du système globalComposition de modèles partiels
Approches basées sur la séparation des préoccupations :Modélisation par aspect Modélisation par points de vueModélisation par sujet Etc.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 171
Programmation par aspects
Motivationsle principal problème dans l’évolution et la réutilisation des logiciels est un problème d’organisation des programmesDans toutes les approches de développement traditionnelles (fonctionnelle ou objet) la structuration d’une application repose sur sa décomposition en unités fonctionnelles.
Application basée sur l’orientée objet :
• Divers classes
• Chacune des classes possède son propre code
•Du code non fonctionnel peut venir ‘‘polluerpolluer’’ le code métier
Logger.log(‘SEVERE’, ‘appel 1’);
Ce n’est pas du code métier!
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 172
Programmation par aspects
Principe de découpageles services de base d’une application et ses propriétés (fonctionnalités transversales), correspondent à des fonctions indépendantes qui doivent être découplées
Un logiciel contient :Des préoccupations métierDes préoccupations de niveau système
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 173
Exemple : paiement par carte de crédit
Préoccupations métier :Effectuer des paiements : débiter un montant d'un compte défini
Préoccupations techniques :Intégrité de la transactionIdentification / authentificationSécurité (confidentialité)Performancesetc
AOP - Exemple
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 174
Le rouge montre les lignes de code qui traitent du logging Très mal modularisé
Copyright © aspectj.org
AOPDispersion du code
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 175
Point de jonction (join point) : désigne un endroit du programme où l’on souhaite ajouter un aspect.
Coupe (pointcut) : désigne un ensemble de point de jonction.
Code advice : bloc de code définissant le comportement d’un aspect (i.e ce que l’aspect greffe dans l’application).
AOPDefinition d’un aspect
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 176
Composants
C1 C2 C3 … Cn
Aspects
A1
A2
A3
….
An
Point de jonction
AOPDefinition d’un aspect
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 177
AspectJ
Extension Java permettant la programmation par AspectsExtension Java permettant la programmation par Aspectshttp://aspectJ.org
Principe de Principe de ddééveloppmentveloppmentIdentifier le préoccupations métier (classes) et techniques (aspects) Implémenter chaque préoccupation séparémentTisser les différentes préoccupations
Code Métier
Définition des aspects
CompilateurAspectJ
Code final
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 178
Un aspect en Concret
packagepackage aop.aspectjaop.aspectj;;
publicpublic aspectaspect tracertracer{{
pointcutpointcut tobetracedtobetraced(): (): call(public call(public voidvoid Client.newClientClient.newClient(..))|| call (public (..))|| call (public voidvoid Commande.newCdeCommande.newCde(..));(..));;;
before() before() : : tobetracedtobetraced()(){{System.out.println("PremierSystem.out.println("Premier Aspect executer le 01/10/2010Aspect executer le 01/10/2010””););}}
}}
Advicede
type before
coupecoupe
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 179
OMGOMG--MDAMDA
Model Driven Architecture
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 180
OMG - MDA
l’OMG, consortium de plus 1000 entreprises, initie la démarche MDA.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 181
L’approche MDA
DescriptionDescriptionLe MDA est l'outil qui permet à une industrie de décrire ses fonctions indépendamment des implémentations
Penser l'application au niveau du modèle et laisser le soin de l'implémentation aux outils
Interopérabilité au niveau des modèles : Il s'agit d'avoir la possibilitéd'écrire et de faire évoluer le modèle en fonction de l'organisation métier de l’application et non plus par les plate-formes.
Au niveau de l'organisation : PIM (Plateform Independant Model) Au niveau des plate-formes : PSM (Plateform Specific Model).
Une application complUne application complèète de MDA : un PIM et un ou plusieurs PSMte de MDA : un PIM et un ou plusieurs PSMLangage de description du MDA : UML. L'application sera ensuite implémentée sur un large éventail de systèmes.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 182
L’approche MDA
Les PSM peuvent communiquer entre eux en faisant intervenir plusieurs plate-formes qui ont à échanger des données ( CORBA par exemple) MDA est implémenté dans un outil qui intègre la modélisation et le développement. Il gère des classes servant les objets métiers, leur présentation et leur persistance.
avantages du MDA : une architecture basée sur MDA est prête pour les évolutions technologiques. plus grande facilité d'intégration des applications et des systèmes autour d'une architecture partagée. une interopérabilité plus large permettant de ne pas être lié à une plate-forme.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 183
Les standards de l’OMG
Architecture à quatre niveaux.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 184
Evolution des processus de développement
Les processus unifiLes processus unifiééssUPRUP2TUP
LL’’agilitagilitééXPRAD
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 185
UP - le Processus Unifié
DescriptionDescriptionUP (Unified Process) est une méthode générique de développement de logiciel.
Générique signifie qu'il est nécessaire d'adapter UP au contexte du projet, de l'équipe, du domaine et/ou de l'organisation (exemple:
R.UP : Rational Unified ProcessX.UP : Extreme Unified Process
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 186
UP - le Processus Unifié
Cadre gCadre géénnééralralLe processus unifié est un processus de développement logiciel : il regroupe les activités à mener pour transformer les besoins d’un utilisateur en système logiciel
CaractCaractééristiques essentielles du processus unifiristiques essentielles du processus unifiéé ::A base de composantsUtilise le langage UML Piloté par les cas d’utilisationCentré sur l’architectureItératif et incrémental.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 187
Le processus unifié : RUP
Rational Unified Rational Unified ProcessProcess, , Instanciation par Rational Software (IBM) des préceptes UP
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 188
Le 2 TUP
Cadre gCadre géénnééralralTwo Track Unified Process
CaractCaractééristiques essentielles du processus unifiristiques essentielles du processus unifiéé ::ItératifS’articule autour de l’architecturePropose un cycle de développement en Y « Détaillé dans UML en action »Pour des projets de toutes tailles
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 189
Le 2 TUP
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 190
Méthodes agiles
DDééfinitionfinitionméthodes de développement informatique permettant de concevoir des logiciels en impliquant au maximum le demandeur (client)se veulent plus pragmatiques que les méthodes traditionnelles. Le développement agile tire son nom du Manifeste Agile, document rédigé en février 2001 et signé par 17 personnalités du domaine. Douze principes ont été définis, dont :
Parvenir à la satisfaction du client par le biais d'un cycle de développement rapide, récurrent et incrémental de versions fonctionnelles;Se montrer apte à prendre en compte les changements de dernière minute à tout moment du projet;Mettre en place une coopération quotidienne entre développeurs et décideurs/commerciauxFaire simple, mais pas simpliste;Laisser l'équipe s'organiser au mieux de ses possibilités.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 191
Méthodes agiles
ExemplesExemplesMéthodes adaptées aux petites équipes
Crystal, XP, Scrum, …
Méthodes prévues pour des groupes conséquentsRAD ASD…
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 192
XP (eXtreme Programming)
cadre gcadre géénnééralralMéthode agileEnsemble de « best practices » de développement (travail en équipes, transfert de compétences, …)
CaractCaractééristiques essentielles du processus unifiristiques essentielles du processus unifiéé ::ItératifPas de phase d’analysePlutôt pour des projets à effectif restreint (10 personnes max)Valeurs :
CommunicationSimplicitéFeedback
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 193
XP (eXtreme Programming)
Cycle de dCycle de dééveloppementveloppement
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 194
RAD (Rapid Application Development)
1 - Initialisation
2 - Cadrage3 - Conception
4 - Construction 5 - Finalisation
Intégration, déploiement et maintenance
Cerner et stabiliser les objectifs Conception globale
et modélisation
Modélisation détaillée, prototypage et test
Préparer l’organisation du projet
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 195
RAD (Rapid Application Development)
InitialisationCette phase permet de définir le périmètre général du projet :
structurer le travail par thèmessélectionner les acteurs pertinentsamorcer une dynamique de projet
CadragePhase d’analyse et expression des exigences Exprime les besoins des utilisateurs lors d’entretiens de groupe
Conception Les utilisateurs sont également impliqués dans cette étape. Ils participent à l’affinage et à la validation des modèles organisationnels :
fluxtraitementsdonnées
Ils valident également le premier niveau de prototype présentant l’ergonomie et la cinématique générale de l’application
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 196
RAD (Rapid Application Development)
Construction Phase de prototypage et réalisation, Durant cette phase, l’équipe RAD doit construire l’application module par module. L’utilisateur participe toujours activement aux spécifications détaillées et à la validation des prototypes.Plusieurs sessions itératives sont nécessaires.
Finalisation Phase de recette et déploiementDes recettes partielles ayant été obtenues à l’étape précédente, il s’agit dans cette phase d’officialiser une livraison globale et de transférer le système en exploitation et maintenance
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 197
RAD – Répartition des charges
6 %9 %
23%
50 %
12 %
Initialis
ation
Cadrag
e
conce
ption
Constructi
on
Finalisa
tion
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 198
Conclusion Générale
Le génie logiciel a apporté un cadre formel au développement logiciel
Toutes les activités identifiées sont supportés par des techniques, des méthodes, des outils.
Encore des efforts à faire au niveau :
Réutilisation
Traçabilité (remonter jusqu’à l’origine d’un problème)
Interopérabilité
Evolution
La phase de capture des exigences (analyse des besoins) n’est pas assez valorisée dans les processus : elle devient une discipline à part entière.
Le Génie Logiciel – [ Y. Lakhrissi & S. Ebersold ] 199
Conclusion Générale
Dernier conseil : s’ouvrir !
Parce que les technologies et les méthodes avancent en vitesse, il faut :
Se tenir au courant,Être curieux
Lire …