Heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a1 UML – Langage unifié pour la modélisation objet.

Présentation au sujet: "Heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a1 UML – Langage unifié pour la modélisation objet."— Transcription de la présentation:

1 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a1 UML – Langage unifié pour la modélisation objet

2 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a2 Démarche Ce document de révision du cours UML a été réalisé sur la base de l’ouvrage: Le guide de l’utilisateur UML Booch / Rumbaugh / Jacobson Eyrolles (traduction française) [BRJ-00]

3 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a3 L’importance de la modélisation Qu’est qu’un modèle? Un modèle est une simplification de la réalité Pourquoi modéliser? Les modèles permettent de mieux comprendre le système que l’on développe Nous construisons des modèles pour les systèmes complexes parce que nous ne sommes pas en mesure d’appréhender de tels systèmes dans leur intégralité. [BRJ-00 p5-7]

4 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a4 Les quatre principes de modélisation 1.Le choix des modèles à créer a une forte influence sur la manière d’aborder un problème et sur la nature de sa solution. 2.Tous les modèles peuvent avoir différents niveaux de précision. 3.Les meilleurs modèles ne perdent pas le sens de la réalité. 4.Parce qu’aucun modèle n’est suffisant à lui seul, il est préférable de décomposer un système important en un ensemble de petits modèles presque indépendants. [BRJ-00 p8-9]

5 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a5 UML - Langage UML est un langage conçu pour: –visualiser –spécifier –construire –documenter les artefacts d’un système à forte composante logicielle [BRJ-00 p14]

6 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a6 Processus de développement (de) logiciel Un processus correctement défini aide à choisir: –les artefacts à produire –les procédures à développer –les intervenants chargés de leur création et de leur gestion –la manière d’employer ces artefacts pour évaluer et diriger le projet dans son ensemble [BRJ-00 p14]

7 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a7 UML - 3 sortes de briques Eléments –structurels –comportementaux –de regroupement –d’annotation Relations –de dépendance –d’association –de généralisation –de réalisation Diagrammes –de classes –d’objets –de cas d’utilisation –de séquence –de collaboration –d’états-transition –d’activités –de composants –de déploiement [BRJ-00 p18]

8 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a8 Les éléments structurels Conceptuels (représentent des concepts intellectuels –Les classes –Les interfaces –Les collaborations –Les cas d’utilisation –Les classes actives Physiques (représentent des réalisations concrètes) –Les composants –Les noeuds [BRJ-00 p19]

9 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a9 Les éléments comportementaux Les interactions –Les messages Les automates à états finis (machines états- transition –Les états [BRJ-00 p22]

10 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a10 Les éléments de regroupement, d’annotation Les paquetages Les notes [BRJ-00 p23]

11 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a11 Les relations La dépendance L’association La généralisation La réalisation [BRJ-00 p24] Cible Parent Contrat

12 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a12 Architecture [BRJ-00 p34] Vue de conception Vue d’implémentation Vue de déploiement Vue des processus Vue des cas d’utilisatio n Assemblage du système Gestion de configuration Performance Capacité à monter en charge Débit Vocabulaire Fonctionnalité Topologie du système Distributiuon Livraison Installation Comportement

13 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a13 Architecture [BRJ-00 p34] Vue de conception Vue d’implémentation Vue de déploiement Vue des processus Vue des cas d’utilisatio n Logical View Component View A créer! Use Case View Deployment View

14 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a14 Architecture [PK-00 p81] Vue logique Vue d’implémentation Vue de déploiement Vue des processus Vue des cas d’utilisatio n Programmeurs Assemblage du système Gestion de configuration Intégrateurs systèmes Performance Capacité à monter en charge Débit Utilisateur final Vocabulaire Fonctionnalité Ingénieurs système Topologie du système Distributiuon Livraison Installation Analystes/Testeurs Comportement

15 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a15 Modélisation des éléments non-logiciels 1.Modéliser sous forme de classes les abstractions que l’on porte sur les éléments 2.Créer de nouvelles briques à l’aide de stéréotypes [BRJ-00 p59]

16 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a16 Relation de dépendance La plupart du temps, les dépendances servent à montrer qu’une classe en utilise une autre comme argument dans la signature d’une opération. On parle alors de relation d’utilisation: si la classe utilisée change, l’opération de l’autre classe peut en être affectée… [BRJ-00 p66]

17 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a17 Diagramme d’activités L’illustration d’une chose intrinsèquement dynamique (comme le comportement d’un système) à l’aide de diagrammes (qui sont des artefacts intrinsèquement statiques, surtout lorsqu’on les dessine sur une feuille de papier, un tableau blanc ou au dos d’une enveloppe) présente des limites pratiques évidentes. Sur l’écran de l’ordinateur, on peut animer les diagrammes comportementaux afin qu’ils simulent un système exécutable… [BRJ-00 p105]

18 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a18 Modélisation d’un schéma logique de BD Les diagrammes de classes UML constituent un surensemble de diagrammes entités-associations (E-A), un outil de modélisation courant pour la conception des bases de données. Alors que les digrammes E-A classiques sont centrés sur les données, les diagrammes de classes vont un peu plus loin et permettent également la modélisation de comportements. Dans la base de données physique, ces opérations logiques sont en général transformées en déclencheurs (triggers) ou en procédures stockées ( stored procedures). [BRJ-00 p118]

19 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a19 Portée des attributs de classes La portée d’une caractéristique précise si cette caractéristique apparaît dans chaque instance du classificateur ou s’il n’y a qu’une seule instance de la caractéristique pour toutes les instances du classificateur. Dans l’exemple ci-dessus: header a une portée « instance » uniqueID a une portée « classificateur » ou constante de classe [BRJ-00 p133]

20 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a20 Modélisation de la sémantique d’une classe Responsabilités Sémantique globale Spécification du corps de chaque opération Spécification des pré et postconditions de chaque opération (texte structuré) Définir un automate à états finis Spécifier une collaboration Spécification des pré et postconditions de chaque opération (langage OCL) [BRJ-00 p142] + Informel + Formel

21 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a21 Interfaces et classes abstraites Les interfaces ressemblent aux classes abstraites (par exemple, ni les unes ni les autres ne peuvent avoir d’instances directes), mais elles en sont assez différentes pour être des éléments de modélisation distincts en UML. Les classes abstraites peuvent avoir des attributs, ce qui n’est pas le cas des interfaces. De plus, ces dernières chevauchent les fontières des modèles. Une même interface peut être réalisée à la fois par une classe (une abstraction logique) et par un composant (une abstraction physique qui fournit une manifestation de la classe). [BRJ-00 p171]

22 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a22 Les interfaces et les frontières des modèles [BRJ-00 p171] Abstraction logique Abstraction physique

23 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a23 Paquetages et classes Il existe une différence importante entre les classes et les paquetages: les classes sont des abstractions d’éléments rencontrés dans un problème ou dans une solution, alors que les paquetages sont des mécanismes utilisés pour organiser ces éléments dans un modèle. Les paquetages n’ont aucune identité (ce qui signifie que les instances de paquetages n’existent pas et qu’ils sont invisibles dans le système en exécution), tandis que les classes ont une identité (elles ont des instances, qui sont les éléments d’un système en exécution). [BRJ-00 p189]

24 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a24 Objets concrets et objets prototypes La différence sémantique entre objets concrets et objets prototypes est subtile et ne concerne vraiment que les concepteurs confirmés… Les objets concrets apparaissent dans des représentations statiques, telles que des diagrammes d’objets, des diagrammes de composants et des diagrammes de déploiement, alors que les objets prototypes apparaissent dans des diagrammes d’interaction et des diagrammes d’activités. [BRJ-00 p205]

25 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a25 Objets et rôles Les objets qui participent à une interaction sont des éléments concrets ou des prototypes… –Objet concret: Jean Dupont, le caissier –Objet prototype: un caissier On peut trouver des instances de classes, de composants, de nœuds et de cas d’utilisation dans le contexte d’une interaction. Même si, par définition, les classes abstraites et les interfaces ne peuvent pas avoir d’instances directes, il est possible de trouver des instances de ces éléments dans une interaction. Elles ne représentent pas des instances directes de la classe abstraite ou de l’interface, mais peuvent indiquer, respectivement, des instances indirectes (prototypes) de n’importe quels enfants concrets de la classe abstraite ou une classe concrète qui réalise cette interface [BRJ-00 p221]

26 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a26 Les messages Un message est la spécification d’une communication entre objets, qui transporte des informations et qui s’affiche dans le but de déclencher une activité. La réception d’une instance de message peut être considérée comme une instance d’un événement. Lorsqu’on transmet un message, l’action qui en résulte est un énoncé exécutable qui forme une abstraction d’une procédure de calcul. Cette action peut conduire à un changement d’état. [BRJ-00 p223]

27 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a27 Les actions déclenchées par les messages call return send create destroy [BRJ-00 p223] invoque une opération pour un objet. Un objet peut s’envoyer un message, qui résulte en l’invocation locale d’une opération renvoie une valeur à l’émetteur envoie un signal à l’objet crée un objet détruit un objet. Un objet peut se détruire lui-même

28 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a28 Application des cas d’utilisation On peut appliquer les cas d’utilisation à un système dans son intégralité. On peut également les appliquer à une partie d’un système, aux sous- systèmes ainsi qu’aux classes individuelles et aux interfaces. [BRJ-00 p235]

29 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a29 Les relations entre cas d’utilisation Un cas d’utilisation peut comporter des variantes. Dans tous les systèmes intéressants, on trouve des cas d’utilisation qui sont des versions spécialisées d’autres cas d’utilisation, des cas d’utilisation qui font partie intégrante d’autres cas d’utilisation et des cas d’utilisation qui élargissent le comportement d’autres cas d’utilisation essentiels. [BRJ-00 p235]

30 heg Haute école de gestion de Neuchâtel 14/11/01UML R01 V1-1a30 Généralisation, inclusion et extension [BRJ-00 p242]