UML: Démarche de Développement Objets PDF

Document Details

Uploaded by Deleted User

Polytech International

Dr. Aymen LOUATI

Tags

UML modélisation développement logiciel conception logiciel

Summary

This document provides an introduction to the Unified Modeling Language (UML) and its use in software design, with examples of its application in projects. The general topics presented in this document includes defining, designing, and improving models that can be applied to software design.

Full Transcript

Chapitre 0: Introduction générale Bien conduire son projet jusqu’à sa livraison Animée par: Dr. Aymen LOUATI Maître-assistant en Informatique (ISI Kef ) Mail contact: aymen.louati@live....

Chapitre 0: Introduction générale Bien conduire son projet jusqu’à sa livraison Animée par: Dr. Aymen LOUATI Maître-assistant en Informatique (ISI Kef ) Mail contact: [email protected] 17/09/2024 Phone contact: (+216) 95 33 53 1 75 Qui suis-je? 2015 PhD in Computer Science from CNAM Paris, France. (Highest level of distinction) Affiliation: CEDRIC, http://cedric.cnam.fr/ Available on line: https://tel.archives-ouvertes.fr/tel- Dr. Aymen LOUATI 01599827/document Certifié: 2009 SCRUM PSM Master in Computer Science and Electrical with High IBM Cloud Developer MS Data Base honors (UTM, Tunisia). 2005 Bachelor in Computer Science with Business, with High honors (University of Tunis) Domaines de Recherche Modélisation UML2 et Formalisation à base des Réseaux de Petri Vérification des Systèmes Temps-Réels et Model-Checking Publications: https://dblp.org/pers/hd/l/Louati:Aymen Thèse de doctorat en ligne: https://tel.archives-ouvertes.fr/tel-01599827 17/09/2024 3 ❑ Un processus très couteux + une non conformité des besoins. ▪ Dépassement de budget + dépassement d’échéance, ▪ Mauvaises fonctions livrées, erreurs et autres problèmes, ❑ Une difficulté d’estimation de l’effort de développement. ❑ Une difficulté à automatiser le processus de développement. 17/09/2024 4 ❑ Exigences massives de la main d’œuvre industrielle, ❑ Complexité croissante des systèmes de plus en plus, ❑ Coût élevé de l’échec dans les systèmes critiques, L’ingénierie du logiciel est une nécessité! un processus systématique au lieu d’un bricolage 17/09/2024 5 ❑ Maîtrise des coûts: rester dans les limites prévues au départ (respecter le budget), ❑ Maîtrise des délais: rester dans les limites prévues au départ, ❑ Maîtrise de la qualité logicielle: Aptitude du projet à satisfaire les besoins des utilisateurs, 17/09/2024 6 La gestion de projet une question d’équilibre + une bonne gestion des ressources ! 17/09/2024 7 Suivi des différentes phases Productivité, suivi et qualité du processus logiciel, (fiabilité, maintenance, évolutivité …) Offrir un cadre cohérent et uniforme de production. Besoins de Réutilisation, Modélisation, Abstraction ❑ Adaptation des outils CASE = Computer Aided Software Engineering = Génération automatique de l’application à partir des modèles. 17/09/2024 8 ❑ Production fiable et conformité des besoins. ❑ Bonne démarche de modélisation. ❑ Sécurité de communication et rapidité d’exécution. ❑ Séparation des problèmes et modularité. ❑ Anticipation du changement et construction incrémentale. 17/09/2024 9 Modélisation et Finalité ❑ Satisfaction du client et garantie d’une qualité logicielle. ❑ Décomposer le système en modèles. Utiliser les bon outils de communication ❑ Simplifier la manière d’aborder le problème et sa solution. La modélisation est une des caractéristiques d’un projet qui réussi! 17/09/2024 10 Pourquoi modéliser ❑ Fournir des spécifications claires, etc. ❑ Clarifier les objets, les concepts, les processus. Réponses possibles aux questions suivantes ❑ Pour quel processus je travaille? ❑ Quel rôle j’ai dans ce processus? ❑ Quel est l’ensemble des processus de mon entreprise? Modéliser ➔ Générer des modèles ❑ Abstraction de la réalité. ❑ Vue subjective mais pertinente de la réalité. 17/09/2024 11 Démarche de modélisation objet et agile Un bon Informaticien est un bon développeur, OUI c’est vrai ❑ UML mais est-il la bonne solution? ????? ❑ Comment appliquer la bonne démarche? ❑ UML estbon Très un ANALYSTE avantage pour la modélisation – Très ou une perte bon CONCEPTEUR ❑ de temps pour Comment livrerles générer un bon produit? modèles? 17/09/2024 12 ❑ Démarche linéaire (Modèle de la cascade) ❑ Processus Unifié (PU) (Modèle itératif et incrémental) ❑ 2Truck UP (Modèle en Y s’inspirant du PU) ❑ Démarche agiles (un travail en équipe et une livraison incrémentale) → Défi moderne du Génie Logiciel ❑ … 17/09/2024 13 Organiser le travail en se basant sur la structure du produit final. Projet Module est découpé en se décompose en 1 1..* 0..1 * ❑ Maîtriser le projet et réduire les délais planifiés, ❑ Répartir les responsabilités (travail en équipe), ❑ Avoir un développement itératif incrémental, ❑ Itérations à durée fixe et développement évolutif, (Raffinement progressif des besoins), 17/09/2024 14 ❑ Réagir au changement plutôt que suivre un plan (Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent les changements pour donner un avantage compétitif pour le client) ❑ Livrer rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. 17/09/2024 15 ❑ Les meilleures architectures, spécifications et conceptions émergent d’équipes auto organisées, ❑ Atteindre l’objectif en équipe, ❑ Répartition des besoins en sous-besoins, ❑ Livraisons incrémentales du produit, ❑ Incrément = nouveau besoin à livrer, 17/09/2024 16 ❑ Echanger avec son promoteur (client) ▪ Définir ensemble un diagramme de cas d’utilisation ▪ Valider ensemble les scénarios ▪ Notation de plus en plus répandue (connue, enseignée, supportée par les outils, …). ▪ Pas de nécessité d’avoir des compétences métier: fonctionnels et développeurs ont un langage commun. 17/09/2024 17 ❑ Analyser et concevoir chaque itération ▪ A partir des cas d’utilisation et des scénarios, définir le diagramme de classe. ▪ A partir des scénarios, définir les diagrammes d’interaction (enrichir les classes) ▪ Définir si besoins les diagrammes d’états….. 17/09/2024 18 Domaine d’application ❑ Les systèmes informatiques d’entreprise, ❑ Les banques, ❑ Les télécoms, ❑ Les transports, ❑ La défense, ❑ Le web et etc. ❑ Même les plus gros projets peuvent être spécifiés et maintenus en UML. Quelques problèmes de communication ❑ Diagrammes complexes: difficiles à comprendre. ❑ Panoplie de diagrammes: perdre la direction. 17/09/2024 19 Les diagrammes UML2.5 Vue statique Vue dynamique Diagramme de Diagramme Diagramme Machine Diagramme de cas classe d’objets d’activité d’états UML d’utilisation Diagramme de Diagramme de Diagrammes composants déploiement d’interaction Diagramme de Diagramme de séquence communication Diagramme de Diagramme de structure Diagramme de Diagramme global Diagramme de profile composite paquetages d’interaction timing Nouveaux sous UML2 ❑ Représentation Possibilité Diversité dede graphique visualiserpour diagrammes d’une et une manipuler séquence d’opérations des sous modélisation éléments ou dedela plusieurs modélisation structure angles d’un système 17/09/2024 20 Outil CASE + Environnement de développement du projet pivot à toute la conception. 17/09/2024 21 Suite Diagrammes de séquences (Modélisation Diagrammes de classes de scénarios par échanges de messages) (Modélisation du domaine) Diagrammes d’activités Diagrammes de classe de (Modélisation de processus conception d’affaires ou autres) (objets, Encapsulation, etc.) 17/09/2024 22 Un même type de diagramme peut : ❑ Modéliser des concepts différents ❑ Être utilisé à des moments différents du processus de développement ❑ Être à différents niveaux d’abstraction ❑ Ne pas être utilisé 17/09/2024 23 ASTUCES de cas d’utilisation Diagramme ❑Ne pas descendre QUAND trop bas dans la description, L’UTILISER? ❑Impossible de décrireles ❑ Aider à comprendre tous les scénarios, requis fonctionnels d’un système, ❑Sélection ❑ Utile dansdes scénarios phases les premières optimaux : interaction la plus d’un projet, ❑fréquente, Précède les spécifications détaillées, ❑Sélection des scénarios dérivés: certaines alternatives intéressantes, 17/09/2024 24 Introduction à la Modélisation 17/09/2024 25 Importance de la modélisation Une niche, une maison, un immeuble ❑Pour construire une niche - Quelques planches, des clous, un marteau et quelques outils. ❑Pour construire une maison familiale - Plans généraux, plans d'exécution détaillés (pièces, électricité, plomberie, chauffage). ❑Pour construire un immeuble - Planification détaillée, nombreux plans et études. 17/09/2024 26 Pourquoi modéliser? Mieux comprendre le système, le clarifier, éliminer les ambigüités Objectifs : 1. Nous aider à le visualiser tel qu'il est ou tel qu'il devrait être. 2. Spécifier la structure et le comportement d'un système. 3. Assurer la compréhension des systèmes naturels complexes. 4. Documenter les décisions qui ont été prises. Construire des modèles de systèmes complexes revient à la difficulté soumise à appréhender ces systèmes dans leur entièreté. Un modèle est une simplification de la réalité. La modélisation n’est qu’une représentation d’un système réel quelle qu’en soit sa forme: physique, graphique, mathématique, verbale ou mentale. 17/09/2024 27 Principes de modélisation - Le choix de quels modèles nous créons admet une influence profonde sur la manière d'attaquer le problème et de former une solution. - Tout modèle peut être exprimé à différents niveaux de précision. - Les meilleurs modèles sont bien reliés à la réalité (les plus proches). -Un seul modèle ne suffit pas, tout système peu compliqué sera mieux appréhendé à travers un ensemble de modèles presque indépendants. 17/09/2024 28 Modèle ? Abstraction de la réalité Processus qui consiste à identifier les caractéristiques intéressantes d'une entité, en vue d'une utilisation précise. L'abstraction désigne aussi le résultat de ce processus, c'est-à-dire l'ensemble des caractéristiques essentielles d'une entité, retenues par un observateur. Vue subjective mais pertinente de la réalité Un modèle définit une frontière entre la réalité et la perspective de l'observateur, ce n'est pas "la réalité", mais une vue très subjective de la réalité. Bien qu'un modèle ne représente pas une réalité absolue, un modèle reflète des aspects importants de la réalité, il en donne donc une vue juste et pertinente. 17/09/2024 29 Exemples de modèles 1. Modèle météorologique: à base des données d'observation (satellite...), permet de prévoir les conditions climatiques pour les jours à venir. 2. Modèle économique: permettre de simuler l'évolution de cours boursiers en fonction d'hypothèses macro-économiques (évolution du chômage, taux de croissance...). 3. Modèle démographique: définit la composition d'un panel d'une population et son comportement, dans le but de fiabiliser des études statistiques, d'augmenter l'impact de démarches commerciales, etc... 17/09/2024 30 Définition et Buts d’UML Unified Modeling Language : Langage unifié de modélisation graphique semi-formel, dont l’objectif est d’assister les développeurs lors du développement logiciel. - Modélisation du système complet (pas seulement le logiciel). - Relier les objets conceptuels au système «exécutable». - Contrôler la complexité. - Lisible par des humains et des machines. - Langage ouvert (mécanisme d'extensibilité). - Langage de spécification : signification claire et non ambiguë. 17/09/2024 31 Comment modéliser avec UML? 1. UML est un langage qui permet de représenter des modèles, mais il ne définit pas le processus d'élaboration des modèles ! 2. Lors d’une modélisation d'une application informatique, les auteurs d'UML 3. préconisent d'utiliser une démarche : Itérative et incrémentale (affiner l’analyse par étapes et favoriser le prototypage). Guidée par les besoins des utilisateurs du système. Centrée sur l'architecture logicielle. 4. Les auteurs d'UML confirment: un processus de développement qui possède ces qualités devrait favoriser la réussite d'un projet. 17/09/2024 32 Différents vues du langage UML Vue statique Vue organisationnelle Vue des utilisateurs Vue dynamique Vue des déploiement 17/09/2024 33 Description textuelle d’un cas d’utilisation 17/09/2024 34 Processus de description Cas d’utilisation UC1 : Nom_cas_d’utilisation Acteur principal : personne physique, morale ou dispositif faisant appel au système pour atteindre un but. Parties prenantes et intérêts : Décrivent et délimitent ce que le système devra faire, il s’agit de ce qui satisfait les intérêts des parties prenantes. Pré-condition(s) : définissent ce qui doit toujours être vrai avant le début d’un scénario. Elles impliquent que le scénario d’un autre cas d’utilisation s’est déroulé normalement, par exemple la connexion à un système. Post-condition(s) : définissent ce qui doit être vrai lorsque le cas d’utilisation se termine avec succès. Scénario principal : décrit le chemin type satisfaisant les intérêts des parties intéressées. Scénario(s) alternatif(s) (Extension) : ils indiquent tous les autres scénarios ou branchements possibles, tant en cas de succès qu’en cas d’échec. 17/09/2024 35 Exemple : Inscrire patient Cas d’utilisation : Inscrire patient Acteur principal : Accueil Parties prenantes et intérêts : Le système doit créer une nouvelle fiche afin d’inscrire le patient en cours, ainsi de l’orienter et le guider vers une visite ou bien une hospitalisation. Pré-condition(s) : Le patient est arrivé à l’hôpital Post-condition (s): L’opération « Inscription du patient dans l’hôpital » est effectuée avec succès Scénario principal - Saisir le code d’inscription - Affichage de la fiche d’inscription - Choix de l’opération : (visite ou hospitalisation) - Quitter Scénario(s) alternatif(s) : Inscription erronée ou erreur de saisie 17/09/2024 36 Scénarii Un scénario représente une succession particulière d’enchaînements, qui s’exécute du début à la fin du cas d’utilisation. Les scénarios sont aux cas d’utilisation ce que les objets sont aux classes. Ils ne sont pas décrits dans le langage UML, mais Ils font parti de la documentation des cas d'utilisation. Chaque cas d'utilisation est documenté par plusieurs scénarios. 17/09/2024 37 Généralisons Le comportement du système est caractérisé par des cas d'utilisation. Un cas d'utilisation est une fonctionnalité du système. Un acteur est quelque chose ou quelqu'un qui agit sur le système. Un diagramme de cas d'utilisation est une vue graphique du système. Chaque cas d'utilisation est documenté par plusieurs scénarios. 17/09/2024 38 / 2 0 2 Références 4 ❑ https://www.omg.org/uml/ (UML Source officielle) ❑ http://www.uml-diagrams.org (Documentation sur tous les diagrammes) ❑ GABAY J. - GABAY D - UML 2 Analyse et conception – Dunod – 2008 ❑ ROQUES P. – UML 2 par la pratique - Etude de cas et exercices corrigés – Eyrolles - 2011 39 Chapitre 0: Introduction générale Bien conduire son projet jusqu’à sa livraison Animée par: Dr. Aymen LOUATI Maître-assistant en Informatique (ISI Kef ) Mail contact: [email protected] 17/09/2024 Phone contact: (+216) 95 33 40 53 75

Use Quizgecko on...
Browser
Browser