UML - Conception technique

Présentation au sujet: "UML - Conception technique"— Transcription de la présentation:

1 UML - Conception technique
Formation Industrialisation AS France Utiliser les 4 derniers slides comme séparateur de grandes parties, ou bien pour annoncer la pause. FOR INTERNAL USE ONLY © 2010 Capgemini. All rights reserved.

2 Introduction Présentation du formateur Objectifs de la formation
A la fin de la session je dois être capable de : Réaliser une conception préliminaire ou une conception détaillée. Concevoir les diagrammes UML adaptés Utiliser l’outil de modélisation MagicDraw FOR INTERNAL USE ONLY. © 2010 Capgemini. All rights reserved. 2

3 Présentation des participants
Vos attentes ? FOR INTERNAL USE ONLY. © 2010 Capgemini. All rights reserved. 3

4 Contexte dans la démarche Rappel de la méthode Indus
Sommaire Contexte dans la démarche Rappel de la méthode Indus Présentation MagicDraw Construction Utilisation de MagicDraw Synthèse Contexte dans la démarche Rappels sur UML et de la méthode Indus Présentation MagicDraw Règles générales Présentation des étapes fonctionnelle et d’architecture Construction Utilisation de la modélisation pour la conception et la réalisation Utilisation de MagicDraw Synthèse © Capgemini - All rights reserved

5 UML en quelques mots UML = … Langage de modélisation
Essentiellement graphique ! UML offre des mécanismes d’extension Méta-modèle : sémantique et règles Unification de multiples notations Standard de l’OMG UML n’est pas une notation fermée Cette page pour fixer quelques bases avant de décrire le contexte. Les concepts: UML est un langage, donc UML sert à communiquer de l’information. Modéliser: pour gagner en clarté, en précision, en abstraction. UML est essentiellement graphique: meilleur pour la communication, moins bon pour le formalisme. Le méta-modèle définit la sémantique des éléments modélisés, et les règles de modélisation. UML est une unification de plusieurs notations existantes. UML est un standard, ce qui facilite l’interprétation des modèles. Approfondir: Langage: UML n’est que le langage, pas le processus. Il faut donc l’accompagner d’un processus. Modélisation: Que modélise-t-on? Des systèmes, des processus, des applications, des interfaces… Graphique: il y a malgré tout une définition très précise des éléments manipulés et représentés. Offre beaucoup de rigueur et de concision, permet d’obtenir différentes vues des mêmes éléments. Le méta-modèle: il fait partie du standard, il garantit que les utilisateurs parlent des mêmes choses, il permet d’échanger des modèles entre outils, il permet de construire des outils d’automatisation. Unification de notations: patrimoniales (machines à états, scénarios, entité-relation), issues des méthodes objet (OMT, pré et post conditions) et d’analyse (cas d’utilisation).

6 Un diagramme pour chaque besoin
Use-Case Diagrams Diagrammes de cas d’utilisation State Diagrams Diagrammes de classes Use-Case Diagrams Diagrammes d’activité State Diagrams Diagrammes d’objets State Diagrams Diagrammes de composants Use-Case Diagrams Diagrammes d’état transition State Diagrams Diagrammes de structure composite Scenario Diagrams Diagrammes de séquences Modèle State Diagrams Diagrammes de paquetage Structure James Rumbaugh = OMT Ivar Jacobson = OOSE Grady Booch = Booch Les diagrammes de cas d’utilisation (montrent les interactions de l’utilisateur avec l’application. Les diagrammes d’activité montrent le flux d’évènements dans un cas d’utilisation (notion de scenarii). Les diagrammes de classes représentent la structure logique tandis que Les diagrammes d’interaction représentent le comportement (la communication avec des messages qui définissent les responsabilités des objets) D’autres diagrammes sont utilisés pour montrer d’autres points de vue nécessaires dans certaines circonstances (diagrammes d’état-transition, de déploiement…) Scenario Diagrams Diagrammes de timing Scenario Diagrams Diagrammes de communication Scenario Diagrams Diagrammes global d’intéraction State Diagrams Diagrammes de déploiement Intéraction Comportement © Capgemini - All rights reserved

7 Contexte dans la démarche Rappel de la méthode Indus
Sommaire Contexte dans la démarche Rappel de la méthode Indus Présentation MagicDraw Construction Utilisation de MagicDraw Synthèse A passer rapidement si la formation méthode Indus a été faite juste avant, mais permet quand même de se repositionner dans le cycle de développement. © Capgemini - All rights reserved 7

8 Méthode de modélisation Branche fonctionnelle
Architecture conceptuelle Méthodes Ajustement Conception (SFG) Architecture logique Analyse (SFD) Architecture physique Conception applicative générale Conception technique détaillée Pilotage Codage et tests unitaires Intégration Recette Architecture Déploiement Fonctionnel Exploitation Maintenance Developpement © Capgemini - All rights reserved 8

9 1-Recueil des besoins Acteurs Diagramme de contexte dynamique 9

10 2-Analyse métier Diagramme de Cas d’utilisation Diagramme d’Activité
Diagramme de Séquence Diagramme de Classes métier 10

11 Synthèse Identifier les acteurs. Lister leurs besoins métier.
Établir le diagramme de contexte dynamique et les messages échangés. Identifier et documenter les cas d’utilisation. Décrire la logique métier par des diagrammes d’activité. Définir les paquetages des domaines fonctionnels. Spécifier les classes, attributs, associations, opérations réalisant les cas d’utilisation. Vérifier la complétude par des diagrammes de séquence mettant en jeu les objets métier. Ajuster le modèle et itérer. Valider la phase avec les utilisateurs. © Capgemini - All rights reserved

12 Méthode de modélisation
Branche fonctionnelle Architecture conceptuelle Méthodes Ajustement Conception (SFG) Architecture logique Analyse (SFD) Architecture physique Conception applicative générale Conception technique détaillée Pilotage Codage et tests unitaires Intégration Recette Architecture Déploiement Fonctionnel Exploitation Maintenance Developpement © Capgemini - All rights reserved 12

13 1-Architecture conceptuelle
Acteurs Diagramme de cas d’utilisation 13

14 1-Architecture logique
Découpage packages et communication Dépendances compilation 14

15 1-Architecture physique
Diagramme de composants 15

16 Contexte dans la démarche Rappel de la méthode Indus
Sommaire Contexte dans la démarche Rappel de la méthode Indus Présentation MagicDraw Construction Utilisation de MagicDraw Synthèse ppt Formation MagicDraw : § Présentation générale +§Les diagrammes © Capgemini - All rights reserved 16

17 Présentation générale de MagicDraw
Génération, rapports et exports © Capgemini - All rights reserved 17

18 Contexte dans la démarche Rappel de la méthode Indus
Sommaire Contexte dans la démarche Rappel de la méthode Indus Présentation MagicDraw Construction Utilisation de MagicDraw Synthèse © Capgemini - All rights reserved 18

19 Méthode de modélisation Branche fonctionnelle
Architecture conceptuelle Méthodes Ajustement Conception (SFG) Architecture logique Analyse (SFD) Architecture physique Conception applicative générale Conception technique détaillée Pilotage Codage et tests unitaires Intégration Recette Architecture Déploiement Fonctionnel Exploitation Maintenance Developpement © Capgemini - All rights reserved 19

20 La conception technique
Analyse (domaine métier) Conception d'Architecture Technique & prototypage Dossier de Conception Scripts de génération possibles, ex : « 1 classe métier issue de l ’analyse se dérive en 1 classe pour les opérations d ’accès aux données et une classe métier à proprement parler » Ces scripts dépendent de l ’architecture cible Conception objet Raffinement de ce qui vient de l ’analyse et de l ’architecture. Précisions pour préparer la génération de code Dossier de Conception Détaillée Génération Implémentation © Capgemini - All rights reserved

21 Une Bonne Conception Technique ?
Une Mauvaise application = Rigidité : Difficile à modifier sans toucher à tout Fragilité : Le moindre changement entraine des erreurs Immobilité : Pas de réutilisation possible Viscosité : Application modifiée et ne respectant plus son architecture Une bonne application = Robuste : Pas de régression au changement Extensible : Ajout de fonctions facile Réutilisable : Les composants sont réutilisables Les points définis pour une mauvaise application entraine généralement une dette technique : Les évolutions et la maintenance vont être couteuses. © Capgemini - All rights reserved

22 Démarche Partant De l’analyse métier qui définit l’ensemble des services métier à implémenter Des règles de conception générique issues de l’architecture Des services et interfaces offerts par le framework technique Définir l’ensemble des classes techniques en appliquant systématiquement les règles d’architecture Organisation en paquetages Règles de conception technique vues pour le framework technique Documenter la dynamique de l’utilisation de ces classes en enrichissant les diagrammes de séquence métier et en créant des diagrammes de collaboration Définir les composants du système au moyen de diagrammes de composants © Capgemini - All rights reserved

23 Organisation en paquetages
Les couches logicielles spécifiées en phase d’architecture se traduisent en autant de paquetages techniques Ceci étant décliné par domaine fonctionnel Il n’y a pas toujours correspondance 1 pour 1 entre le fonctionnel et la conception technique: eg une application, une IHM peuvent manipuler des données métier de divers domaines © Capgemini - All rights reserved

24 Exercice : TP Restaurant
Définir le Packaging du modèle de conception technique © Capgemini - All rights reserved

25 Les classes - Responsabilités
Une classe possède des responsabilités. Une responsabilité définit un des rôles de la classe pour le système : aussi bien en terme de stockage d’information (état), qu’en terme de comportement. Une même responsabilité ne peut être attribuée à deux classes différentes Une classe doit avoir au moins une responsabilité clairement définie.

26 Les classes - Notation Une classe décrit un groupe d’objets ayant des propriétés similaires (attributs), un comportement commun (opérations), des relations communes avec les autres objets ainsi qu’une même sémantique. Une classe est représentée par une icône divisée en 3 parties: le nom de la classe la liste des attributs la liste des opérations Une classe est définie dans un paquetage et est unique à l’intérieur de ce paquetage.

27 Les attributs – Notation
Les attributs sont représentés de la manière suivante : visibilité nom: type = valeur initiale { propriétés } visibilité : + : public. L’attribut est visible à l’extérieur de la classe ~ : package. L’attribut est visible pour les classes du package de la classe (visibilité par défaut) # : protected. L’attribut n’est visible que de la classe et de ses sous-classes - : private. L’attribut n’est visible que de la classe. nom : Nom de l’attribut. type : Nom indiquant le type de l’objet valeur initiale : Valeur initiale de l’attribut propriétés : Liste de propriétés, sous la forme d’une chaîne, applicables à l’attribut

28 Les opérations – Notation
Les opérations sont représentées de la manière suivante : visibilité nom (paramètres ) : type de retour { propriétés} visibilité : + : public. L’opération est visible à l’extérieur de la classe ~ : package. L’attribut est visible pour les classes du package de la classe (visibilité par défaut) # : protected. L’opération n’est visible que de la classe et de ses sous-classes - : private. L’opération n’est visible que de la classe. nom : Nom de l’opération. paramètres : Liste des paramètres sous la forme nom : type = valeur par défaut type de retour : Type de l’objet retourné par la méthode. propriétés : Liste de propriétés, sous la forme d’une chaîne, applicables à l’opération

29 Les classes et opérations abstraites
Une classe abstraite ne possède aucune instance. Elle ne peut être effectivement utilisée que par héritage. Une opération abstraite ne possède pas d’implémentation. Seule une classe abstraite peut contenir des opérations abstraites. Les classes et opérations abstraites sont affichées en italique

30 Les associations - Notation
Les associations sont représentées par un lien entre les deux classes participantes. Nom de l’association La flèche indique le sens de navigabilité de l’association Multiplicité : nombre d’instances de Classe2 pour une instance de Classe1 rien : un et un seul 0..1 : zéro ou un m..n : de m à n inclus 0..* : de zéro à plusieurs 1..* : de un à plusieurs Rôle joué par Classe1 dans l’association Le + indique la portée du rôle rien : implémentation + : public # : protected ~ : package - : privé

31 Les associations – Classe association
Une classe association : connecte des classes entre elles comme une association possède ses propres attributs et opérations possède ses propres associations avec d’autres classes

32 Les associations – Agrégation/Composition
L’agrégation est une variante de l’association. Elle indique une relation d ’appartenance entre les objets, sans que leurs durées de vie soient liées. La composition est une variante de l’association. Elle se traduit par un attribut sur un des rôles de l’association. Elle indique une relation d ’appartenance entre les objets, liant leurs durées de vie Lorsque la voiture est détruite, ses roues n’existent plus.

33 L’héritage – Définition
L’héritage définit une relation de classification entre une classe plus générale et une classe plus spécifique: généralisation : prendre des classes existantes et créer de nouvelles classes en prenant leurs parties communes. On va du plus spécifique vers le plus général. spécialisation : sélectionner des classes existantes et en dériver de nouvelles plus spécialisées, en spécifiant simplement les différences. Principe : lorsqu'une sous-classe hérite d'une super-classe, elle doit en assumer toutes les conséquences: les opérations et attributs hérités doivent être conservés avec la même sémantique si une opération est redéfinie, le contrat défini par la classe mère doit être respecté

34 L’héritage multiple Une classe peut avoir plus d’une classe mère. Plusieurs parcours d’héritage sont alors possibles. L’objectif est de fusionner en une nouvelle classe, et éventuellement les y spécialiser, des comportements appartenant normalement à des classes différentes. L’intérêt est de pouvoir fusionner des ascendants directs d’importance voisine ou d’ajouter à une classe d’autres fonctionnalités. Attention : l’héritage multiple n’est pas possible dans tous les languages, par exemple en Java, on doit utiliser les Interfaces

35 L’héritage : règle de modélisation
Il n’est pas souhaitable de se focaliser sur les relations d’héritage trop vite. L’héritage est une notion très structurante dans un modèle objet et de ce fait fige la structure sémantique des types d’objet. L’ajout d’une nouvelle classe est obligatoirement influencé par les relations d’héritages existantes. Il faut rester ouvert le plus longtemps possible. C’est uniquement quand on estime que toutes les classes du domaine fonctionnel ont été identifiées que l’on peut commencer à réfléchir sur les abstractions du système et ainsi construire les premières classes abstraites.

36 Exercice : TP Restaurant
Définir le diagramme de classe d’une commande © Capgemini - All rights reserved 36

37 Exercice : TP Restaurant
Définir le diagramme de classe DDL de la carte © Capgemini - All rights reserved 37

38 Diagrammes de séquence : définition, notation
Un diagramme de séquence montre les interactions entre des objets et instances d’acteurs, arrangés en séquences dans le temps. La séquence est montrée par la «ligne de vie» des objets et les messages qu’ils échangent ordonnancés dans le temps. Un objet Un acteur Un message Temps Ligne de vie de l’objet

39 Diagrammes de séquence : notation
Création d’objet Classe de l’objet Nom de l’objet Destruction d’objet

40 Diagramme de séquence : UML2
Introduction des notions : Option, Alternative, loop

41 Exercice : TP Restaurant
Définir le diagramme de séquence d’un passage de commande © Capgemini - All rights reserved 41

42 Les diagrammes d’activité
Permettent de représenter des activités séquentielles ou parallèles, des conditions de branchement. Une activité symbolise une action élémentaire d’un point de vue métier, use-case, traitement technique... Peuvent être utilisés pour représenter: L’organisation d’un cas d’utilisation en termes de séquences d’interactions. Un workflow complet. Le séquencement métier global d’un ensemble de cas d’utilisation. Egalement d’un point de vue technique: des threads d’exécution, des tâches, processus, traitements…

43 Les diagrammes d’activité
Etat initial Activité Barre de synchronisation Etat final

44 Les diagrammes d’activité
Colonne (Swimlane) Objet

45 Exercice : TP Restaurant
Définir le diagramme d’activité d’accueil des clients © Capgemini - All rights reserved 45

46 Diagrammes d’état : définition, notation
Un diagramme d’état représente une machine à états qui spécifie les séquences d’états qu’un objet doit occuper durant sa vie en réponse à des événements.

47 Diagrammes d’état : état, définition
Par principe, tout objet ou tout système possède un état à chaque instant. Un état est une situation dans la vie d’un système ou d’un objet durant laquelle il satisfait une condition, il effectue une activité ou il attend un événement donné. Deux états prédéfinis ayant une notation particulière : État de départ du système : État final du système

48 Diagrammes d’état : transition, définition
Une transition est une relation entre un état source et un état cible. Une transition est déclenchée par un objet en réaction à un événement et conduit à un changement d’état.

49 Diagrammes d’état : sous-états

50 Exercice : TP Restaurant
Définir le diagramme d’état transition d’une commande © Capgemini - All rights reserved 50

51 Contexte dans la démarche Rappel de la méthode Indus
Sommaire Contexte dans la démarche Rappel de la méthode Indus Présentation MagicDraw Construction Utilisation de MagicDraw Synthèse ppt Formation MagicDraw : § Génération, rapports et exports © Capgemini - All rights reserved

52 Fonctions avancées de MagicDraw
ppt Formation MagicDraw : § Génération, rapports et exports Java C++ C# SQL XML

53 Contexte dans la démarche Rappel de la méthode Indus
Sommaire Contexte dans la démarche Rappel de la méthode Indus Présentation MagicDraw Construction Utilisation de MagicDraw Synthèse © Capgemini - All rights reserved 53

54 Messages clés Chaque classe, composant a une responsabilité bien définie. La lecture complète du modèle Fonctionnel, logique et technique doit être faite. La validation du modèle (UC,DS,DC) doit être faite. Le use case doit servir de pivot à toute la conception. La traçabilité et le processus d’intégration se fait sur l‘unité de référence «  use case ». Les modifications de code doivent être tracées dans le code, évolution des «  use case ». Ne pas oublier les fondamentaux du cycle de vie « Y ». Les tests unitaires doivent être rédigés, joués et un compte rendu doit être fait à l’intégrateur par «  use case ». La modélisation de la conception technique doit être respectée. Les couches logicielles ne doivent pas être compromises et leur responsabilité ne doit pas être remise en jeux (métier, IHM,…) © Capgemini - All rights reserved

55 Wi http://wiki.capgemini.com/index.php/MagicDraw_Indus_Sud
Liens Lien vers le wiki A&D : Wi Lien vers CTF Indus A&D, Modélisation et Magic Draw : FOR INTERNAL USE ONLY © 2010 Capgemini. All rights reserved.

56 Suivi des modifications
Version Date Auteur Résumé et raisons des modifications 1.0 Octobre 2011 P. Boisgard & P. Blanc Version initiale et Redécoupage des formations UML et intégration de MagicDraw 1.1 Déc 2011 A.Piccardi Suppression des services Indus Slide masqué permettant de suivre l’évolution des différentes versions. Si vous avez des questions concernant ce document, Merci de contacter le(s) auteur(s) du document FOR INTERNAL USE ONLY. © 2010 Capgemini. All rights reserved. 56

57 Fin Dernier slide FOR INTERNAL USE ONLY © 2010 Capgemini. All rights reserved.