Cours CH1+2 (1) PDF

GL2 mme zaiter Matière fondamentale : UEF2 Crédits :6 Coefficient : 4 évaluation: Examen (60%) , contrôle continu (40%)  contenu Chapitre 1: Introduction Chapitre 2: Modélisation avec UML Chapitre 3. diagramme UML de cas d’utilisation Chapitre 4. diagramme UML de c...

GL2 mme zaiter Matière fondamentale : UEF2 Crédits :6 Coefficient : 4 évaluation: Examen (60%) , contrôle continu (40%)  contenu Chapitre 1: Introduction Chapitre 2: Modélisation avec UML Chapitre 3. diagramme UML de cas d’utilisation Chapitre 4. diagramme UML de classes et d’objets : vue statique. Chapitre 5. Diagrammes UML : vue dynamique (seq, état, activité) 2  Chapitre 6. Autres notions et diagrammes UML 1. Composants, déploiement, structures composite. 2. Mécanismes d'extension : langage OCL + les profils. Chapitre 7. Introduction aux méthodes de développement : (RUP, XP) Chapitre 8. Patrons de conception et leur place au sein du processus de développement 3  Chapitre 1: Introduction Chapitre 2: Modélisation avec UML 4  CRISE DU LOGICIELS & définition PROBLEMES: Développer des Logiciels Maintenir les Logiciels existants Répondre aux Besoins Définition du G.L Etablissement et utilisation de principes en vue d’obtention des logiciels à Moindre Coûts, qui sont Fiables, et qui fonctionnent efficacement sur des machines réelles. 5  définition & OBJECTIF le GL lutte contre : le Retards dans les livraisons (parfois des années). le Surcoûts considérables (dépassant largement les budgets prévus). La réalisation des Produits qui ne répondent pas aux besoins des usagers (peu performants, difficiles à maintenir, etc.). La réalisation des Produits peu sûrs (peu fiables: comportant des erreurs dont le nombre et l'emplacement sont souvent inconnus et ayant des répercussions graves sur la mission du système). 6  Génie Logiciel (principe) Fonder sur: des Bases Théoriques Un Ensembles de Méthodes et Outils Valider par la pratique Donc Pour développer des Logiciels il faut Définir des techniques de fabrications justifiées soit par la théorie soit par la pratique 7  Qualités attendues d'un logiciel En plus des fonctionnalités requises, d'autres facteurs caractérisent la qualité d'un logiciel. Fiabilité + Intégrité, Précision, Tests réussis pour tous les cas, Uniformité de conduite. Efficacité : Optimisation rationnelle des ressources + Economie de mémoire, Rapidité d'exécution, 8  Qualités attendues d'un logiciel Ergonomie : Interface utilisateur s'adaptant aux capacités réelles des usagers +Facilité d'utilisation, Accessibilité, Documentation pour l'utilisateur. Portabilité +Utilisation d'un langage standardisé, Indépendance du matériel, Indépendance du système d'exploitation. 9  Qualités attendues d'un logiciel Facilité de Maintenance (maintenabilité) : les logiciels ayant une longue durée de vie, doivent être conçus et réalisés de façon à minimiser les coûts des corrections d'erreurs non découverts dans les phases antérieures ainsi que ceux des adaptations aux évolutions éventuelles. +Ce qui exige :une bonne Structuration, une Facilité d'extension, une Lisibilité et une bonne documentation technique … 10  Qualités attendues d'un logiciel Remarque : Il est difficile d'optimiser tous ces facteurs en même temps car certains s'excluent mutuellement. Exemple : offrir une meilleure interface utilisateur peut réduire l'efficacité. Il est clair que dans ce cas, on doit effectuer des choix contradictoires. On est amené à trouver des compromis entre ces objectifs lors de la définition des besoins du système logiciel. 11  Qualités attendues d'un logiciel Exemple : Dans les systèmes temps réel, l'efficacité est de première importance. Toutefois, ceci risque d'accroître les coûts de manière exponentielle 12  le cycle de vie d’un logiciel le génie logiciel perçoit la fabrication des programmes comme un processus à étapes. L'ensemble de ces étapes (successives) forme ce qu'on appelle le cycle de vie du logiciel et Chacune des étapes, depuis la commande du logiciel par le maître d'ouvrage jusqu'à sa mise en exploitation, possède ses propres caractéristiques et une logique d'enchaînement des différentes étapes. 13 Modèles de cycle de vie Logiciel  1- Modèles Séquentiels Etapes (ou Phases): une étape se termine par la production de documents qui sont vérifiés et validés avant de passer à l’étape suivante Programmer et traquer les erreurs 15  1. Les flèches descendantes FAISABILITE matérialisent l’enchaînement des étapes (version initiale pas de retour ANALYSE DES BESOINS arrière) PLANIFICATION 2. Les flèches ascendantes expriment le fait qu’une étape ne remet en CONCEPTION cause que l’étape précédente PRELIMINAIRE (Version actuelle) CONCEPTION DETAILLEE CODAGE INTEGRATION 3.Les versions actuelles font apparaître les INSTALLATION validation et vérification dans chaque étape. EXPLOITATION MAINTENANCE 16  AVANTAGES Plus on avance dans les étapes, moins il devrait avoir de risque. On avance donc par pas. L'avantage de ce modèle est que chaque phase est finie, elle est donc gérable tant au niveau du temps que des ressources. Le code est créé assez tardivement, il y a donc une bonne compréhension du système. 17  INCONVENIENTS Au niveau des inconvénients, on peut noter que ce modèle ne représente pas la réalité. Il est possible de revenir en arrière, car des erreurs ont été découvertes, car on doit créer des tests ce qui implique du code. Il y a des risques de découvrir des erreurs qu'a la fin et qui nécessiteront de refaire toutes les étapes. L'ajout de nouvelle exigence implique qu'il faille refaire toutes les étapes. Plus un problème ou un changement doit être fait tard, plus il coûtera cher. 18  Adaptation séquentiel Ce modèle est encore très utilisé, mais a été revu dans sa version initiale. Dans la nouvelle version, il est possible de revenir en arrière et des prototypes sont créé à chaque phase. Il est ainsi dans cette nouvelle version, plus près de la réalité. Modèle approprié lorsque les besoins sont bien identifiés 19  2- Modèles Evolutifs ou Graduels Développer une implémentation initiale, l’exposer à l’utilisateur et raffiner à travers plusieurs versions Les activités de spécification, développement et validation sont menées d’une manière concurrente On a deux approches 20  OBJECTIF: Livraison du Système aux Utilisateurs Prototypage Exploratoire Systèmes Délivrés (Evolutif) Besoins Généraux Prototype Exécutable Prototypage Jetable + Spécification du Système OBJECTIF: Valider ou Obtenir les Besoins du Système 21 2-1: Développement Exploratoires Débuter par les parties du système qui sont comprises et évoluer en ajoutant les nouvelles caractéristiques Objectif: développer le système d’une manière évolutive 22  Prototypage Exploratoire (Evolutif) Développer une Construire un prototype Utiliser le Prototype Spécification Abstraite du système NON Livrer le Système OUI Système Approprié? 23  2-2: Prototypes Jetables Vise à Comprendre les besoins de l’utilisateur et mieux cerner les besoins du système. Se concentrer sur l’expérimentation des besoins mal compris et mal définis par l’utilisateur Objectif: Spécification du système 24  Prototype Jetable Etablir une Développer Prototype Spécification Abstraite Evaluer le Prototype Réutiliser des Composants Spécifier le Système Développer le Délivrer le Système Valider le Système Système 25  Avantages, Inconvénients Modèle efficace pour produire des systèmes qui répondent aux besoins immédiats. Les spécifications peuvent être développées d’une manière incrémentale au fur et à mesure que l’utilisateur à une meilleure compréhension de son problème Non visibilité car on produit des documents pour chaque version Pauvre structuration Nécessité d’avoir des outils et des techniques (expert pluridisciplinaire pour réaliser un bon prototypage) 26  Approche graduelle appropriée pour des systèmes de petites tailles (100,000 LOC) ou de tailles moyennes (jusqu’à 500,000 LOC) Pour des systèmes plus larges, combiner les deux approches: – Développer un prototype jetable pour résoudre les incertitudes dans les spécifications – Ré implémenter ce système en utilisant une approche plus structurée Exemple: développer les parties bien comprises par une approche séquentielle et développer les autres parties (interfaces avec les utilisateurs) par une approche exploratoire. 27  2-3: Développement Incrémental (Mills 1980) Spécification, Conception et Implémentation sont divisées et coupées en plusieurs séries d’incréments qui sont développer au fur et à mesure. Développer les besoins et délivrer le système d’une manière incrémentale Donner des opportunités aux clients de reporter les détails de leurs besoins (avoir une certaine expérience avec le système) 28  2-3: Développement Incrémental (Mills 1980) : processus L’utilisateur identifie une descriptions des services à fournir par le système (en commençant par ceux qui sont les plus importants) Un nombre d’incréments à développer sont définis. Chaque incrément doit répondre à un sous-ensemble de fonctionnalités du système. Les services prioritaires sont développés en premier au client. 29  2-3: Développement Incrémental (Mills 1980) : processus 1er Incrément: les services sont définis et l’incrément sera développé en utilisant un processus de développement approprié Durant ce temps, l’analyse des besoins des autres incréments peut s’effectuer sans changer l’incrément en cours de développement Une fois l’incrément en cours est complété et délivré, les utilisateurs peuvent l’utiliser pour expérimentation (clarifier les besoins des autres incréments) Lorsque des incréments sont complétés, ils seront intégrer aux incréments existants (amélioration du système à chaque addition de nouveaux incréments) 30 1ere Description Affecter les besoins Architecture et des Besoins aux Incréments Conception du Système Développer Valider l’Incrément l’Incrément du Système Complet Valider le Système Intégrer l’Incrément Système Final Non Complet 31  Avantages On n’est pas obligé d’utiliser le même processus pour tous les incréments (utiliser le modèle séquentiel pour les spécifications bien définies et les approches évolutives pour les spécifications mal définies) L’utilisateur n’attend pas jusqu’à la fin Utiliser l’incrément comme prototype Risque réduit Priorité aux services importants (donc ils sont les plus testés) 32  2-4: Modèle en V Le principe de ce modèle, est que chaque étape de décomposition du système possède une phase de test. Chaque phase du projet à une phase de test qui lui est associé. Beaucoup de tests (de différents formes) sont ainsi créés, ce qui implique une réflexion. 33 34  2-4: Modèle en V On sait progressivement si on s'approche de ce que le client désire. Ce modèle est convenable pour les projets complexes. C'est un modèle dérivé du modèle en cascade. 35  2-5 Modèle en spirale Ce modèle est plus récent, il date du milieu des années 80. Ce modèle est adapté pour les gros projets complexes. Il se base sur la notion du cycle; donc les risques sont sans cesse évalués à chaque cycle. L'emphase de ce modèle et mise sur la réduction des risques. 36 37  Un cycle est décomposé en étapes: 1.Analyse préliminaire pour le premier cycle, pour les autres cycles, on détermine les objectifs, contrainte à partir du résultat du cycle antérieur. 2.Analyse des risques, création de prototype 3.Développement et test 4.Planification du cycle suivant 38  2-5 Modèle en spirale:Le processus Les prototypes créés à chaque cycle permettent de réduire les risques et de guider la conception pour obtenir un système qui répond au besoin du client. Chaque cycle de la spirale fait en sorte que le système est de plus en plus complet. 39  3- Approche Formelle Produire des spécifications formelles par transformation en utilisant des méthodes mathématiques pour aboutir à un programme (préservation de la correction). 40 Définition Spécification Transformation Des Besoins Formelle Formelle Intégration et Test du Système 41  T1 T2 T3 T4 Spécification R1 R2 R3 Programme Exécutable Formelle P1 P2 P3 P4 (Preuve) 42 4- modèle W 43  Chapitre 2 Modélisation avec UML UML (Unified Modeling Language) est un langage unifié pour la modélisation objet. 44  Introduction Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du système. C'est également un bon moyen de maîtriser sa complexité et d'assurer sa cohérence. Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains détails), d'une entité (phénomène, processus, système, etc.) du monde réel en vue de le décrire, ou de l'expliquer; un modèle permet de réduire la complexité d'un phénomène. Il reflète ce que le concepteur croit important (dépendant des objectifs du modèle). 45  La Modélisation Orientée Objet L'approche considère le logiciel comme une collection d'objets dissociés, identifiés et possédant des caractéristiques. Une caractéristique est soit un attribut (i.e. une donnée caractérisant l'état de l'objet), soit une entité comportementale de l'objet (i.e. une fonction). La fonctionnalité du logiciel émerge alors de l'interaction entre les différents objets qui le constituent. L'une des particularités de cette approche est qu'elle rapproche les données et leurs traitements associés au sein d'un unique objet. 46  Eléments et mécanismes généraux Uml est incrémental (i.e. en divisant le développement en étapes aboutissant chacune à la construction de tout ou partie du système), centré sur l’architecture (au niveau de la modélisation comme de la production), conduit par les cas d’utilisation (modélisant l’application à partir des modes d’utilisation attendus par les utilisateurs), piloté par les risques (afin d’écarter les causes majeures d’échec) tel que le 2TUP (Two Tracks Unified Process). 47  Eléments et mécanismes généraux UML prend en compte de manière complètement intégrée l’ingénierie des besoins (cas d’utilisation). UML est automatisable pour générer du code à partir des modèles vers les langages et les environnements de programmation. UML est générique, extensible (en plus de couvrir les possibilités des différentes technologies objet existantes) et configurable. 48 Uml en application 49  Uml en application Il existe ce quand appel Atelier de génie logiciel (AGL), ou des outils CASE pour Computer Aided Software Engineering, qui désigne un ensemble de programmes informatiques permettant eux-mêmes de produire des programmes de manière industrielle. Exp: upper-CASE comme logiciel de modélisation UML STARUML. Lower case logiciel d’implémentation EXP : IDE net beans eclipse… 50  Démonstration TP (outils AGL CASE) Visual paradigm Staruml (à installer) Ms project (planification) IDE (remarque sur les logiciels utilisées l’année passé) …. 51  Les diagrammes UML UML n’impose pas de processus de développement logiciel particulier, même si celui sous-jacent est un processus itératif (précisant à chaque itération les degrés d’abstraction) UML se compose des diagrammes: de cas d’utilisation, de classes, d’objets, d’états- transitions, d’activités, de séquence, de collaboration, de composants et de déploiement Ces diagrammes constituent l’expression visuelle et graphique du futur système. (ils seront détaillés dans les chapitres suivants) 52  La notion du package le package donne une définition de vues partielles ou synthétique et même hiérarchiques d'une application (sous forme de partitionnement d’une application) SYNTHÈSE EN PACKAGES ENSEMBLE DES CLASSES DE L'APPLICATION N.B.: une classe appartient à un et un seul package 14/10/24 10:07 53  Exemple : Package entreprise Ensemble des packages terminaux de l’application Véhicules Livraisons Facturation Livreurs Clientèles Bilan Colis Commerciaux Personnel Tenue Comptes 14/10/24 10:07 54  Notion de package Un package est la représentation informatique du contexte de définition d’une classe C’est un élément structurant les classes – Modularisation à l'échelle supérieure – Un package partitionne l'application : Il référence ou se compose des classes de l’application Il référence ou se compose d’autres packages – Un package réglemente la visibilité des classes et des packages qu’il référence ou le compose – Les packages sont liés entre eux par des liens d'utilisation, de composition et de généralisation 14/10/24 10:07 55  Représentation d’un package Vue graphique externe et P1 interne+lien Vue graphique externe P1 C1 C2 P2 P3 14/10/24 10:07 56 Lien entre paquetage 57  Chapitre 3. Diagramme UML de ca d’utilisation : vue focntionnelle 58