Différences entre versions de « UML »
(47 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 26 : | Ligne 26 : | ||
<!--****************** Commercez les modifications: Fiche-Disciplines-Thématiques *********************--> | <!--****************** Commercez les modifications: Fiche-Disciplines-Thématiques *********************--> | ||
− | |Domaine-Discipline-Thématique-1= | + | |Domaine-Discipline-Thématique-1= Informatique |
− | |Domaine-Discipline-Thématique-2= | + | |Domaine-Discipline-Thématique-2= L'Orienté Objet |
− | |Domaine-Discipline-Thématique-3= | + | |Domaine-Discipline-Thématique-3= Mdélisation de Base de Données |
|Domaine-Discipline-Thématique-4= | |Domaine-Discipline-Thématique-4= | ||
|Domaine-Discipline-Thématique-5= | |Domaine-Discipline-Thématique-5= | ||
Ligne 55 : | Ligne 55 : | ||
*'''''[1]Un pictogramme''''', '''également appelé pictographe, est une représentation graphique schématique, un dessin figuratif stylisé ayant fonction de signe. Dans toutes les langues du monde avec un système graphique, le pictogramme sert à expliquer une information d'ordre général.''' | *'''''[1]Un pictogramme''''', '''également appelé pictographe, est une représentation graphique schématique, un dessin figuratif stylisé ayant fonction de signe. Dans toutes les langues du monde avec un système graphique, le pictogramme sert à expliquer une information d'ordre général.''' | ||
− | + | ||
− | |||
− | |||
<!-- ******** Fin Définition Générale ***************************** --> | <!-- ******** Fin Définition Générale ***************************** --> | ||
Ligne 64 : | Ligne 62 : | ||
|Typologie= <!------------------------------------ Ne pas Modifier --> | |Typologie= <!------------------------------------ Ne pas Modifier --> | ||
<!-- ****************** Commercez les modifications ****************--> | <!-- ****************** Commercez les modifications ****************--> | ||
− | + | ||
− | |||
− | |||
− | |||
− | |||
{{@}} '''Caractéristiques''' Les principales caractéristiques d'UML sont: | {{@}} '''Caractéristiques''' Les principales caractéristiques d'UML sont: | ||
Ligne 95 : | Ligne 89 : | ||
UML offre une manière élégante de représenter le système selon différentes vues complémentaires grâce aux diagrammes. | UML offre une manière élégante de représenter le système selon différentes vues complémentaires grâce aux diagrammes. | ||
− | ........ | + | |
− | + | *'''UML permet d'économiser de l'argent | |
+ | ''' | ||
+ | Lorsqu'une entreprise désire un logiciel, elle le réalise parfois en interne, mais le fait plus généralement réaliser par une société de services. | ||
+ | |||
+ | Dans un cas comme dans l'autre il est nécessaire de définir l'ensemble des fonctionnalités que le logiciel doit possèder. Le demandeur du logiciel n'a parfois pas de compétences particulières en informatique et exprime donc ses souhaits sous forme d'un CdCF (Cahier des Charges Fonctionnelles), c'est-à-dire un document décrivant sous forme textuelle l'ensemble des particularités que le logiciel doit possèder, les conditions qu'il doit remplir (système(s) d'exploitation visé(s)), les écueils à éviter, ainsi que les délais impartis, éventuellement des clauses sur le coût, les langages à utiliser, ... | ||
+ | |||
+ | Le CdCF est ainsi distribué à différentes sociétés de services (dans le cas d'une sous-traitance) sous forme d'un appel d'offre, auquel les sociétés vont répondre par un coût, un délai, ... | ||
+ | |||
+ | Lorsqu'une société obtient le marché et qu'elle décide (si elle a le choix) d'opter pour un langage orienté objet, il lui faut dans un premier temps créer un modèle (c'est là qu'intervient UML) afin : | ||
+ | |||
+ | -de présenter au client la façon suivant laquelle elle compte développer le logiciel | ||
+ | |||
+ | -d'accorder tous les acteurs du projet (une application de grande envergure est généralement réalisée par modules développés par différentes équipes) | ||
+ | |||
+ | Ainsi, si le modèle ne convient pas au client, il sera "simple" à modifier, contrairement à une application directement implémentée (qui aurait mobilisé beaucoup plus de personnel, pendant une période plus longue), ce qui signifie une perte d'argent beaucoup moins importante pour la société de services, ainsi qu'une meilleure probabilité de rendre dans les temps (on parle généralement de dead line) une application conforme aux exigences du client (si l'application se conforme au modèle présenté au client, celui-ci peut difficilement contester la validité du logiciel). | ||
}}<!-- ******** Fin Fiche Didactique Définition ******************* --> | }}<!-- ******** Fin Fiche Didactique Définition ******************* --> | ||
Ligne 112 : | Ligne 120 : | ||
<!-- Remplacez, Adaptez, Ajoutez ou Supprimez les images et lignes non utilisées--> | <!-- Remplacez, Adaptez, Ajoutez ou Supprimez les images et lignes non utilisées--> | ||
− | Image: | + | Image:Uml.jpg|modele |
− | Image: | + | Image:Diagclasse.png|diagramme classe |
− | Image: | + | Image:Usecase.png|cas utilisation |
</gallery><!-- ************** Fin modification images***************************--> | </gallery><!-- ************** Fin modification images***************************--> | ||
Ligne 140 : | Ligne 148 : | ||
<!----------------- Commencez les modifications des Mots Clés ---------------------> | <!----------------- Commencez les modifications des Mots Clés ---------------------> | ||
− | |Mot-Clé-1= | + | |Mot-Clé-1=Processus unifié |
− | |Mot-Clé-2= | + | |Mot-Clé-2=Démarche de conception et d'analyse |
− | |Mot-Clé-3= | + | |Mot-Clé-3=Approche Objet |
− | |Mot-Clé-4= | + | |Mot-Clé-4=Démarche itérative et incrémentale |
− | |Mot-Clé-5= | + | |Mot-Clé-5=OMG |
− | |Mot-Clé-6= | + | |Mot-Clé-6=Diagramme de classe |
|Mot-Clé-7= | |Mot-Clé-7= | ||
|Mot-Clé-8= | |Mot-Clé-8= | ||
Ligne 163 : | Ligne 171 : | ||
<!-- ****************** Commercez les modifications *********************** --> | <!-- ****************** Commercez les modifications *********************** --> | ||
− | *..... | + | *UML, est conçu pour fournir une méthode normalisée pour visualiser la conception d'un système. Il est couramment utilisé en développement logiciel et en conception orientée objet. |
− | + | ||
− | .. | + | *UML n'étant pas une méthode, l'utilisation des diagrammes est laissée à l'appréciation de chacun. Le diagramme de classes est généralement considéré comme l'élément central d'UML. Des méthodes, telles que le processus unifié proposé par les créateurs originels de UML, utilisent plus systématiquement l'ensemble des diagrammes et axent l'analyse sur les cas d'utilisation (« use case ») pour développer par itérations successives un modèle d'analyse, un modèle de conception, et d'autres modèles. D'autres approches se contentent de modéliser seulement partiellement un système, par exemple certaines parties critiques qui sont difficiles à déduire du code. |
− | . | + | |
− | *. | + | *Une façon de mettre en œuvre UML est de considérer différentes vues qui peuvent se superposer pour collaborer à la définition du système: les vues sont les observables du système. Elles décrivent le système d'un point de vue donné, qui peut être organisationnel, dynamique, temporel, architectural, géographique, logique, etc. En combinant toutes ces vues, il est possible de définir (ou retrouver) le système complet. |
− | + | *UML et les diagrammes d'UML sont utilisés par deux types de vue : D'un point de vue statique ou structurelle du domaine avec les diagrammes de structure (Structure Diagrams). D'un point de vue dynamique avec les diagrammes de comportement (Behavior Diagrams) et les diagrammes d’interactions (Interaction Diagrams). | |
− | + | *UML est utilisé par les méthodes agiles ( comme Scrum) par le principe agile suivant: l'utilisation de modèles UML à des fins de documentation doit être restreinte au strict nécessaire, les méthodes agiles mettant plus l'accent sur la production rapide de code opérationnel que sur la documentation et minimisant donc la modélisation en amont: Les modèles UML utilisés par les méthodes agiles ne sont pas forcément à conserver et maintenir. Une fois qu'ils ont atteint leur but, on peut les jeter. | |
− | + | *Par contre l'approche Model-Driven, préconisée par l'OMG, s'appuie sur une modélisation UML très poussée visant à une génération automatique de code quasi-complète. | |
+ | |||
+ | |||
}}<!--************** Fin Fiche Didactique Explicitations ******************* --> | }}<!--************** Fin Fiche Didactique Explicitations ******************* --> | ||
− | |||
= {{Widget:Erreurs-confusions-Fiche}} = | = {{Widget:Erreurs-confusions-Fiche}} = | ||
Ligne 184 : | Ligne 193 : | ||
<!-- ****************** Commercez les modifications *************************--> | <!-- ****************** Commercez les modifications *************************--> | ||
− | * Confusion entre [[ | + | * Confusion entre [[Classe et Entité]] |
− | * Confusion entre [[ | + | * Confusion entre [[Include et Extend]] |
− | * Erreur fréquente: | + | * Confusion entre [[Diagramme de classe et Modèle Conceptuel de Données(MCD)]] |
− | *[[ | + | * Confusion entre [[Langage de modélisation et Méthode de conception]] |
+ | * Confusion entre [[les cardinalités dans un diagramme de classe et les cardinalités dans un Modèle Conceptuel de Données(MCD)]] | ||
+ | * Erreur fréquente: | ||
+ | |||
+ | *[[Sens de la flèche du stéréotype Include]] | ||
+ | *[[Besoins fonctionnels et besoins non fonctionnels]] | ||
}}<!-- ************** Fin Fiche Didactique Conceptions ********************* --> | }}<!-- ************** Fin Fiche Didactique Conceptions ********************* --> | ||
Ligne 199 : | Ligne 213 : | ||
<!-- ************ Commercez les modifications *********************--> | <!-- ************ Commercez les modifications *********************--> | ||
− | * [[ | + | * [[Pourquoi modéliser un projet informatique ?]] |
− | * [[ | + | * [[Mais quel est le lien de la modélisation avec UML ?]] |
− | * [[ | + | * [[C’est quoi l’approche objet ??]] |
+ | * [[Qu’est ce que ça veut dire une démarche itérative et incrémentale ?]] | ||
+ | * [[Quelle est la différence entre la méthode MERISE et UML?]] | ||
+ | * [[Est-ce que UML est une méthode ?]] | ||
+ | * [[ Comment élaborer les diagrammes UML pour faire quelque chose de cohérent ?]] | ||
}}<!-- ******** Fin Fiche Didactique Questions ******************* --> | }}<!-- ******** Fin Fiche Didactique Questions ******************* --> | ||
− | |||
= {{Widget:Liens-enseignement-Fiche}} = | = {{Widget:Liens-enseignement-Fiche}} = | ||
Ligne 218 : | Ligne 235 : | ||
<!-- ****************** Commercez les modifications ************************** --> | <!-- ****************** Commercez les modifications ************************** --> | ||
− | * | + | *'''Difficultés d'enseignements rencontrées:''' |
− | :* | + | |
− | + | :*Les étudiants veulent commencer à programmer sans avoir étudié le besoin des utilisateurs, et sans avoir fait une conception du logiciel en bonne et due forme. | |
− | :* ... | + | |
+ | :*Quand on fait la remarque, on reçoit généralement des réponses du type : | ||
+ | |||
+ | - On n’est pas vraiment obligé de modéliser un logiciel que l’on doit réaliser. | ||
+ | |||
+ | - À quoi modéliser le logiciel, puisqu'on sais exactement ce qu’il faut ? | ||
+ | |||
+ | - C’est une perte de temps. La réalisation de ce logiciel est urgente. | ||
+ | |||
+ | |||
+ | |||
}}<!-- ************************* Fin Idées-Enseignement ********************** --> | }}<!-- ************************* Fin Idées-Enseignement ********************** --> | ||
− | |||
== {{Widget:Aides et astuces-Fiche}} == | == {{Widget:Aides et astuces-Fiche}} == | ||
Ligne 235 : | Ligne 261 : | ||
<!-- ****************** Commercez les modifications ************************** --> | <!-- ****************** Commercez les modifications ************************** --> | ||
− | * . | + | |
− | :* . | + | * '''Les étudiants en informatique souhaitent préparer leurs projets logiciels avec UML, Ils souhaitent proposer une version visuelle de leurs projets et compréhensible de tous. |
− | * ... | + | ''' |
− | : | + | Pour ce faire: |
+ | |||
+ | * '''Il faut présenter le langage UML et réaliser, avec les étudiants, les premières analyses de besoin d’un projet logiciel à partir d'un | ||
+ | exemple concret.''' | ||
+ | |||
+ | * '''Voici une réponse par une analogie pour les étudiants qui veulent commencer à programmer sans avoir fait une conception du logiciel:''' | ||
+ | |||
+ | Est-ce que ça vous viendrait à l’idée de laisser un maître d’œuvre commencer la construction d’une maison sans avoir préalablement fait réaliser des plans par un architecte ? La réponse est bien sûr que non, à moins que l’on veuille bien accepter une maison qui ne réponde pas à nos besoins, qui soit bancale ou qui le deviendrait dans peu de temps, et dans laquelle il serait difficile de faire des travaux faute de plans. | ||
+ | |||
+ | Un logiciel qui a été réalisé sans analyse et sans conception risque lui aussi de ne pas répondre aux besoins, de comporter des anomalies et d’être très difficile à maintenir. | ||
+ | |||
+ | Tout comme la construction d’une maison nécessite des plans à différents niveaux (vision extérieure, plan des différents étages, plans techniques…), la réalisation d’un logiciel ou d’un ensemble de logiciels a besoin d’un certain nombre de diagrammes. | ||
+ | |||
+ | Cette étape de modélisation nous permet de ne pas perdre davantage de temps ultérieurement : | ||
+ | |||
+ | - Pour faire associer un logiciel déjà développé aux besoins (qu’on n’avait pas étudié, ni compris) ; | ||
+ | |||
+ | - Pour comprendre comment un logiciel a été créé avant d’y apporter des modifications. | ||
+ | |||
+ | |||
+ | |||
}}<!-- ************************* Fin Astuces-Enseignement ********************** --> | }}<!-- ************************* Fin Astuces-Enseignement ********************** --> | ||
Ligne 250 : | Ligne 296 : | ||
<!-- ****************** Commercez les modifications ************--> | <!-- ****************** Commercez les modifications ************--> | ||
− | :* .. | + | :* https://www.youtube.com/watch?v=dJd6azZr9Kg&list=PLRR7wjtXb1cBQCE8ddM0B1D9DFj-WL3BX |
− | :* | + | |
− | : | + | :* https://www.youtube.com/watch?v=VCMVJs5gi2Y |
}}<!-- ************ Fin Liens Education ********************** --> | }}<!-- ************ Fin Liens Education ********************** --> | ||
Ligne 266 : | Ligne 312 : | ||
<!-- ****************** Commercez les modifications *********************--> | <!-- ****************** Commercez les modifications *********************--> | ||
− | * . | + | * https://openclassrooms.com/fr/courses/2035826-debutez-lanalyse-logicielle-avec-uml/2035851-uml-c-est-quoi |
− | * .. | + | * https://laurent-audibert.developpez.com/Cours-UML/?page=introduction-modelisation-objet#L1-2-1 |
− | + | ||
− | + | ||
}}<!-- ************* Fin Fiche Didactique Bibliographie *************** --> | }}<!-- ************* Fin Fiche Didactique Bibliographie *************** --> | ||
{{Widget:Fiche-Conceptuelle-Bas}} | {{Widget:Fiche-Conceptuelle-Bas}} |
Version actuelle datée du 4 juin 2020 à 10:24
![]() ![]() |
Traduction

Définition
Domaine, Discipline, Thématique

Définition écrite
- Le Langage de Modélisation Unifié, de l'anglais Unified Modeling Language (UML), est un langage de modélisation graphique à base de pictogrammes[1] conçu pour fournir une méthode normalisée pour visualiser la conception d'un système. Il est couramment utilisé en développement logiciel et en conception orientée objet.
- L'UML est le résultat de la fusion de précédents langages de modélisation objet : Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard adopté par l'Object Management Group (OMG).
- UML 1.0 a été normalisé en janvier 1997; UML 2.0 a été adopté par l'OMG en juillet 2005. La dernière version de la spécification validée par l'OMG est UML 2.5.1 (2017).
- [1]Un pictogramme, également appelé pictographe, est une représentation graphique schématique, un dessin figuratif stylisé ayant fonction de signe. Dans toutes les langues du monde avec un système graphique, le pictogramme sert à expliquer une information d'ordre général.

Définition graphique
Concepts ou notions associés

Exemples, applications, utilisations
|
Erreurs ou confusions éventuelles
- Confusion entre Classe et Entité
- Confusion entre Include et Extend
- Confusion entre Diagramme de classe et Modèle Conceptuel de Données(MCD)
- Confusion entre Langage de modélisation et Méthode de conception
- Confusion entre les cardinalités dans un diagramme de classe et les cardinalités dans un Modèle Conceptuel de Données(MCD)
- Erreur fréquente:
Questions possibles
- Pourquoi modéliser un projet informatique ?
- Mais quel est le lien de la modélisation avec UML ?
- C’est quoi l’approche objet ??
- Qu’est ce que ça veut dire une démarche itérative et incrémentale ?
- Quelle est la différence entre la méthode MERISE et UML?
- Est-ce que UML est une méthode ?
- Comment élaborer les diagrammes UML pour faire quelque chose de cohérent ?
Liaisons enseignements et programmes
Idées ou Réflexions liées à son enseignement
- Difficultés d'enseignements rencontrées:
- Les étudiants veulent commencer à programmer sans avoir étudié le besoin des utilisateurs, et sans avoir fait une conception du logiciel en bonne et due forme.
- Quand on fait la remarque, on reçoit généralement des réponses du type :
- On n’est pas vraiment obligé de modéliser un logiciel que l’on doit réaliser.
- À quoi modéliser le logiciel, puisqu'on sais exactement ce qu’il faut ?
- C’est une perte de temps. La réalisation de ce logiciel est urgente.
Aides et astuces
- Les étudiants en informatique souhaitent préparer leurs projets logiciels avec UML, Ils souhaitent proposer une version visuelle de leurs projets et compréhensible de tous.
Pour ce faire:
- Il faut présenter le langage UML et réaliser, avec les étudiants, les premières analyses de besoin d’un projet logiciel à partir d'un
exemple concret.
- Voici une réponse par une analogie pour les étudiants qui veulent commencer à programmer sans avoir fait une conception du logiciel:
Est-ce que ça vous viendrait à l’idée de laisser un maître d’œuvre commencer la construction d’une maison sans avoir préalablement fait réaliser des plans par un architecte ? La réponse est bien sûr que non, à moins que l’on veuille bien accepter une maison qui ne réponde pas à nos besoins, qui soit bancale ou qui le deviendrait dans peu de temps, et dans laquelle il serait difficile de faire des travaux faute de plans.
Un logiciel qui a été réalisé sans analyse et sans conception risque lui aussi de ne pas répondre aux besoins, de comporter des anomalies et d’être très difficile à maintenir.
Tout comme la construction d’une maison nécessite des plans à différents niveaux (vision extérieure, plan des différents étages, plans techniques…), la réalisation d’un logiciel ou d’un ensemble de logiciels a besoin d’un certain nombre de diagrammes.
Cette étape de modélisation nous permet de ne pas perdre davantage de temps ultérieurement :
- Pour faire associer un logiciel déjà développé aux besoins (qu’on n’avait pas étudié, ni compris) ;
- Pour comprendre comment un logiciel a été créé avant d’y apporter des modifications.
Education: Autres liens, sites ou portails
Bibliographie
Pour citer cette page: ([1])
ABROUGUI, M & al, 2020. UML. In Didaquest [en ligne]. <http:www.didaquest.org/wiki/UML>, consulté le 3, mai, 2025