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.

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

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

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

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).

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

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

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

1-Recueil des besoins Acteurs Diagramme de contexte dynamique 9

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

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

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

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

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

1-Architecture physique Diagramme de composants 15

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

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

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

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

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

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

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

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

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

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.

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.

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

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

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

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é

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

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.

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é

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

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.

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

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

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

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

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

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

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…

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

Les diagrammes d’activité Colonne (Swimlane) Objet

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

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.

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

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.

Diagrammes d’état : sous-états

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

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

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

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

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

Wi http://wiki.capgemini.com/index.php/MagicDraw_Indus_Sud Liens Lien vers le wiki A&D : Wi http://wiki.capgemini.com/index.php/MagicDraw_Indus_Sud Lien vers CTF Indus A&D, Modélisation et Magic Draw : https://coconet2.capgemini.com/sf/docman/do/listDocuments/projects.fr_south_capgemini_industrializa/docman.root.03_poles.03_pole_cqp.docf1033038 FOR INTERNAL USE ONLY © 2010 Capgemini. All rights reserved.

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

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