Obtenir le pack complet des cours, TDs, TPs et projets sur UML !
Êtes-vous un étudiant passionné d'informatique et souhaitez-vous maîtriser UML ? Ne cherchez plus, nous avons le pack parfait pour vous.
Accédez à une collection complète de 131 supports de cours, de travaux dirigés (TD), de travaux pratiques (TP) et de projets concrets qui vous permettront de comprendre et d'appliquer efficacement UML dans vos projets.
Obtenir le pack maintenantIntroduction au Génie Logiciel Plan 1
• Introduction
• Définitions
• Le Génie Logiciel : Genèse et Objectifs
• Les Cycles de vie de développement industriel de Logiciels
• Les facteurs de qualité logiciel
• Des méthodes fonctionnelles aux méthodes “Objet” Introduction • Programmer n'est pas Concevoir un système informatique
• La technique ? nécessaire, mais pas si importante que ça !
• Le VRAI problème difficile : l'organisation, la gestion
– difficulté de formalisation
– multitude de paramètres, facteurs
– gestions des ressources (financiers, humaines, matériel, temps)
Introduction (2)
• Comment acquérir/développer un système sur mesure ?
– Que le logiciel soit
• développé en interne
• acheté, sous-traité
• Comment avoir/donner confiance
– respect des coûts, du calendrier
– respect des besoins fonctionnels Définitions
• Le génie logiciel (software engineering) est une science de génie industrielqui étudie les méthodes de travail et les bonnes pratiques des ingénieurs qui développent des logiciels. • Le génie logiciel s'intéresse en particulier aux procédures systématiques qui permettent d'obtenir des logiciels de grande taille, qui correspondent aux attentes du client, sont fiables, ont un coût d'entretien réduit et de bonnes performances tout en respectant les délais et les coûts de construction.[ Wikpédia]
• Ensemble de moyens (techniques, méthodes) mis en œuvre pour la construction – de systèmes informatiques – de logiciels
Genèse et Objectifs (1)
• Difficulté de maîtrise des coûts
• Difficulté de réalisation de plannings
• Difficulté de maîtrise des délais de réalisation
• Difficulté d’amélioration de la productivité et de la qualité des logiciels Genèse et Objectifs (2)
• Difficulté de gestion de projets logiciels de grande ampleur (Programming in the Large)
• Nombreux échecs : résultats fournis par les logiciels insatisfaisants pour les clients finaux.
Tout ceci dans un contexte de compétition
internationale sévère Difficultés liées à la nature du logiciel
•un logiciel ne s'use pas, sa fiabilité ne dépend que de sa conception
•mais, pour rester utilisé un logiciel doit évoluer
•pas de direction clairement exprimée,
•changements fréquents, •Contradictions des besoins
Difficultés liées aux personnes
•ne savent pas toujours ce qu'elles veulent, ou ne savent pas bien l'exprimer
• communication difficile entre personnes de métiers différents (jargons) • l'informaticien est souvent perçu comme introverti, peu solidaire du groupe (...ça change...)
• beaucoup d ’autodidactes qui croient savoir...
Difficultés technologiques
• courte durée de vie du matériel,
• beaucoup de méthodes, langages, ...
• Évolution des outils de développement
– adaptation – formation – Investissement lourds
Le coût de développement...
• Répartition : (Ref. Boehm)
– Analyse/Conception
• 33-34 % : Système d’exploitation, Aérospatiale
• 44-46 % : Contrôle et Régul. indus., Calcul scientifique, Gestion
– Codage
• 17-20 % : Système d’expl., Contrôle et Régul. indus., Aérospatiale
• 26-28 % : Calcul scientifique, Gestion
– Test/Intégration
• 28-34 % : Contrôle et Régul. indus., Calcul scientifique, Gestion
• 46-50 % : Système d’exploitation, Aérospatiale
– Maintenance
• coûts très importants...
• Peu de capitaux d’investissement nécessaires
• Frais de personnel élevés
ENSA de 2018/20193 LA NG AG E UM LENSAF15 Quelques thèmes tirés par le Génie Logiciel
• Qualification du personnel par la formation
• Procédures de gestion de la qualité logiciel
• Outils dédiés au GL
• Langages et environnements de programmation
• Prototypage
Il n’y a pas de remède miracle,
mais quelques voies à creuser...
• Méthodes formelles et semi-formelles
• Réutilisabilité
• L’approche ObjetL AN GA G
E UM LENSAF16 Les cycles de vie
•qu’est-ce qu’un cycle de vie logiciel?
– Enchaînement des activités de développement logiciel
– Définition des Pré et Post conditions pour chaque phase
– Procédures de gestion et d’encadrement
– Procédures de mesures
– Cycle de vie logiciel : synonyme de méthodologie logicielL AN GA G
E UM LENSAF17 Les cycles de vie (2)
Etapes d’un cycle de vie
• Analyse : opportunité fonctionnelle et faisabilité technique
• Conception : choix tactiques de réalisation et d’architecture
• Codage : réalisation informatique du détail des opérations
• Test : tests unitaires et d’intégration
• Exploitation / Maintenance
Les deux grandes catégorie de cycles de vie :
• Les cycles linéaires : succession d’étapes ordonnées
• Les cycles itératifs : réalisation incrémentale par évolutionsL AN GA G
E UM LENSAF18 Les cycles de vie linéaires
•Cycle en cascade : ouvre des points de visibilitésL AN GA G
E UM LENSAF19 Limites du modèle linéaire
• Les projets présentent bien souvent une part d’inconnu et donc de risques.
– Méconnaissance des besoins par le client
– Incompréhension des besoins par le fournisseur
– Instabilité des besoins
– Choix technologiques
– Mouvements de personnels
=> Le processus de développement d’un logiciel n’est pas naturellement linéaire...L AN GA G
E UM LENSAF20 Les cycles de vie itératifs
• Evaluation d’éléments concrets au cours du développement : élimination de l’effet tunnel – basé sur l’évolution de prototypes exécutables, mesurables
– diminution de l’importance des documents de spéc. Détaillée
– livraisons intermédiaires => résultats concrets réguliers de l’équipe de développement
– meilleurs anticipation et prise en compte des problèmes – meilleurs gestion de la prise en compte de modifications de spécification qui peuvent être intégrées dans une itération future
– intégration progressive de composants
– ...
ENSA de 2018/20194 LA NG AG E UM LENSAF21 Le cycle en spirale (Boehm)
• A chaque spire, il y a itération complète sur les phases :
– Analyse
– Conception
– Codage
– TestL AN GA G
E UM LENSAF22 Le cycle en spirale (2)
• A chaque itération, le logiciel doit être dans un état quasi commercialisable
• Grand intérêt en prototypage incrémental
• Très utilisé sur les projets reposant sur l’objet.
• La première spire doit comprendre les éléments les plus abstraits et Le coeur fonctionnel minimum du système
«Design a little, code a little»L AN GA G
E UM LENSAF23 Facteurs de qualité logiciel (1)
Facteurs externes (visibles par le client)
•Validité : aptitude d’un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications.
•Exactitude: le logiciel fournit les bons résultats
•Robustesse: le logiciel réagit correctement à des données fausses
•Fiabilité: exactitude + robustesse
•Stabilité: possibilité d’intégrer des modif. de spécification légèresL AN GA G
E UM LENSAF24 Facteurs de qualité logiciel (2)
Facteurs externes (visibles par le client)
•Efficacité: Utilisation optimales des ressources matérielles (performances d’exécution, encombrement mémoire,...)
•Facilité d’emploi : facilité d’apprentissage, d’utilisation, de préparation des données, d’interprétation des erreurs et de rattrapage en cas d’erreur d’utilisation.
•Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d’autres logiciels.L AN GA G
E UM LENSAF25 Facteurs de qualité logiciel (3)
Facteurs internes
•Vérifiabilité : facilité de préparation des procédures de test.
•Maintenabilité(support du temps..., testabilité, traçabilité)
•Portabilité : facilité avec laquelle un logiciel peut être transféré sous différents environnements matériels et logiciels.
•Intégrité : aptitude d’un logiciel à protéger son code et ses données contre des accès non autorisés.
•Cohésion: forte cohésion dans les modules
•Faible couplage entre les modulesL AN GA G
E UM LENSAF26 Des méthodes fonctionnelles aux méth. objet
•L’approche fonctionnelle
– Raisonnement en terme de fonctions du système
• l’accent est mis sur les fonctions et non sur les données
– Séparation des données et du code de traitement
• transposition dans les méthodes des contraintes du matériel
– Diffusion des responsabilités
• intégrité des données non garanties
• ajout possible de nouvelles opérations à tout moment
– Décomposition fonctionnelle descendante
ENSA de 2018/20195 LA NG AG E UM LENSAF27 L’approche fonctionnelle
• Représentation graphique d’une approche fonctionnelleL AN GA G
E UM LENSAF28 L’approche fonctionnelle (Exemple) LA NG AG E UM LENSAF29 L’approche Objet
•Regroupement données-traitements
•Diminution de l’écart entre le monde réel et sa représentation informatique (approche naturelle)
–Les informaticiens sont pervertis : le monde est avant tout objet
•Localisation des responsabilités : encapsulation
•Décomposition par identification des relations entre objets :
–association, composition , généralisation/spécialisationL AN GA G
E UM LENSAF30 L’approche Objet (Exemple)L AN GA G
E UM LENSAF31 Evolution des méthodesL AN GA G
E UM LENSAF32 Panorama des méthodes
• Méthodes structurées
– Programmation structurée (Dijkstra)
– Décomposition fonctionnelle descendante (SA/SD)
– SADT/SART
• Modélisation de Systèmes d’Information
– Diagrammes entités-relations
– Merise
• Méthodes Objet
– OOD : Booch (91,93)
– OOA : Coad-Yourdon (90)
– HOOD : pour Ada (88)
– OOM : Bouzeghoub (93) merise
– OOSE : Jacobson
– OMT : Rumbaugh (91,93)
ENSA de 2018/20196 LA NG AG E UM LENSAF33 La spécification UMLL AN GA G
E UM LENSAF34 Présentation d’UMLL AN GA G
E UM LENSAF35 Plan 2
• Introduction
• La modélisation
• Concepts de l’approche Objet • Historique d’UML
• Diagrammes d’UML
• Classification des digrammesL AN GA G
E UM LENSAF36 La modélisation
• Elle est essentielle pour :
– Comprendre le fonctionnement d’un système
– Maîtriser la complexité
– Faciliter la communication au sein de l’équipe
• Et particulièrement en génie logiciel :
– Être un facteur de réduction des coûtset des délais
– Être un facteur d’accroissement de la qualitédu produit
– Permettre d’assurer une maintenance facile et efficace
– Permettre de contrôler l’avancement d’un projet
Validité, fiabilité, extensibilité, réutilisabilité, compatibilité, intégrité, portabilité, vérifiabilité, efficacité...L AN GA G
E UM LENSAF37 Concepts de l’approche Objet
•Classe: type de donnée abstrait
– Caractéristiques : attribues et méthodes
•Encapsulation: masquer les détails d’implémentation d’un l’objet
– Facilite l’évolution d’une application
– Garantit l’intégrité des données
•Héritage: transmission les caractéristiques d’une classe vers une/plusieurs sous classe(s)
– Spécialisation et généralisation •Polymorphisme: faculté d’appliquer une méthode à des objets de classes différentes
•Agrégation: composition des objets, plus complexes, d’une classe à partir des objets d’autres classes de baseL AN GA G
E UM LENSAF38 Méthodologie OO
• Les méthodes de modélisation ‘classiques’ sont basées sur :
– Un modèle de données et un modèle des traitements séparés
– Une modélisation de flots de données
Insatisfaisantes pour modéliser des systèmes objet
• L'émergence des méthodologies objets (c.1990)
– Plus de 50 méthodes objet sont apparues
– Exemples : Booch, Classe–Relation, Fusion, HOOD, OMT,OOA, OOD, OOM, OOSE
– Toutes les méthodes avaient pourtant d’énormes points communs (objets, méthode, paramètres,...)
Aucune ne s’est réellement imposée
ENSA de 2018/20197 LA NG AG E UM LENSAF39 Méthodes OO de base • UML: un méta-langage de modélisation pour unifier les modèlesutilisés dans les méthodes
Méthode OODBOOCH Modélisation dynamique
Méthode OMT
RUMBAUGH
Modélisation statique
Méthode OOSE
JACOBSON
Cas d’utilisationUML Unified Modeling LanguageL AN GA G
E UM LENSAF40 Autres méthodesBooch’91 OMT-1 OOSEPartenaires
Booch’93 OMT-2
Méthode unifiée 08
UML 0.9
UML 1.0
UML 1.1
UML 1.2
UML 2.3
OOPSLA’95
Version bêta OOPSLA’96
Soumission à l’OMG
Soumission à l’OMG
Standardisation par l’OMG
Octobre 1995
Juin 1996
Janvier 1997
Septembre 1997
Novembre 1997
Mai 20102010
Dernière spécification révisée par l’OMG
juin 1998
UML 1.X1999-2002
Historique : évolution d’UMLL AN GA G
E UM LENSAF41 • UML est un langage graphique qui permet de modéliser tous les types de systèmes d’informatiques.
– Comprendre et de décrire les besoins
– Concevoir et construire des solutions
– Documenter un système tout au long du cycle de développement
– Communiquer entre les membres de l’équipe de projet
• C’est une notation qui laisse la liberté de conception
PrésentationL AN GA G
E UM LENSAF42 Les diagrammes d ’UML
9 types de diagrammes –Classes: les classes et les relations statiques –Objets : les objets et les liens –Cas d’utilisation : les acteurs et l’utilisation du système –Séquence : vision temporelle des interactions
–Collaboration : vision spatiale des interactions –Etats-Transitions : le comportement des objets –Activité : le flot de contrôle interne aux opérations –Composants : les composants d’implémentation et leurs relations –Déploiement : la structure matérielle et la distribution des objets et des composants
Structurel
Interaction
Comportement
Implémentation
4 nouveaux diagrammes sont ajoutés depuis la version 2.0
–Diagrammes de paquetages, de structures composites, global de collaboration, et de tempsL AN GA G
E UM LENSAF43 • L’ensemble des 9 diagrammes peut être réparti sur les trois axes de modélisation Diagramme de cas d’utilisation
Diagramme de classes
Diagramme d’objets
Diagramme de composants
Diagramme de déploiement
Diagramme de séquence
Diagramme de collaboration
Diagramme d’états
Diagramme d’activités
Fonctionnel
Statique
dynamique
Classification des diagrammesL AN GA G
E UM LENSAF44 Les diagrammes d ’UML
•Diagrammes structurels ou diagrammes statiques (UML Structure)
– diagramme de classes (Class diagram)
– diagramme d’objets (Object diagram)
– diagramme de composants (Component diagram)
– diagramme de déploiement (Deployment diagram)
– diagramme de paquetages (Package diagram)
– diagramme de structures composites (Composite structure diagram)
•Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)
– diagramme de cas d’utilisation (Use case diagram)
– diagramme d’activités (Activity diagram)
– diagramme d’états-transitions (State machine diagram)
–Diagrammes d’interaction (Interaction diagram)
• diagramme de séquence (Sequence diagram)
• diagramme de communication (Communication diagram)
• diagramme global d’interaction (Interaction overview diagram)
• diagramme de temps (Timing diagram)
ENSA de 2018/20198 LA NG AG E UM LENSAF45 Les diagrammes d ’UML
• Diagramme Use Case(ou de Cas d'utilisation) : Il répond à la question "qu'est-
ce que les utilisateurs attendent ?", c'est-à-dire les relations entre les acteurs et les fonctionnalités du système d'information. Niveau fonctionnel, point de vue externe. • Diagramme de Classeest l'ensemble des éléments qui constituent le monde réel et les relations qui existent entre ces éléments. • Diagramme d'objets: Il représente les objets et les liens qui les relient, permet de préciser un aspect particulier du diagramme de classe. • Diagramme de séquence: Il représente les messages échangés entre les objets qui s'enchaînent de façon séquentielle. LA NG AG E UM LENSAF46 Les diagrammes d ’UML (2)
• Diagramme State Chart (ou d’états/transitions) : Il définit les règles d'évolution, soit le cycle de vie des objets d'une classe • Diagramme d'activité: Il décrit les phases d'évolution du système et modélise les actions effectuées sur le système. Niveau abstrait • Diagramme de communication: montre les relations sémantiquement faibles entre les objets • Diagramme de composants: Montre le découpage du systèmes en unités pouvant être distribuées (logiciels). • Diagramme de déploiement: répartition des matériels : machines, systèmes d'exploitation et les liens réseaux entre ces machinesL AN GA G
E UM LENSAF47 Les diagrammes d ’UML (3)
• UML2 diagramme "interaction overview" ou synthèse des interactions: c'est un mélange des diagrammes de séquence et d'activité. • UML2 diagramme de timing: Il décrit les contraintes temporelles sur l'évolution du système. • UML2 diagramme des packages: Il montre les dépendances des éléments au niveau de la compilation. • UML2 diagramme des structures composites: Comme le diagramme des packages, il montre les dépendances des éléments, mais au niveau de l'exécution.