Unified Modeling Language

Transcription

1 Unified Modeling Language Sémantique et usage dans le de développement du logiciel Christelle URTADO LGI2P / ECOLE DES MINES D ALES Objectifs de ce cours Présenter le langage UML et son usage dans le de développement logiciel Eléments de spécification du langage Présentation des différents types de diagrammes Usage d UML pour soutenir le de développement logiciel UML demain : les tendances de l évolution Déroulement 6 heures de cours 6 heures de TD 1

2 Plan Introduction un langage pour modéliser Les principaux types de diagrammes diagrammes structurels de classes, d objets, de composants, de déploiement diagrammes comportementaux de cas d utilisation, de séquence, d états, d activité, de communication Usage d UML dans le de développement logiciel Conclusion UML demain : les tendances de l évolution Bibliographie UML, qu'est ce que c'est? UML est un langage destiné à modéliser des systèmes (souvent logiciels), (principalement) graphique, unifié et semi-formel. Un langage Un langage est une sorte de formalisme que l'on utilise pour décrire une réalité abstraite. On distingue plusieurs composantes d'un langage : le lexique (les mots), la syntaxe (la grammaire), la sémantique (le sens). Un langage est généralement redondant («trop» riche). destiné à modéliser des systèmes (souvent logiciels) Un système est une partie bien circonscrite d'un dispositif réel, matériel ou immatériel, existant ou en cours de construction. Un modèle est une représentation d'un système dirigée par des objectifs. Décrire un modèle (abstrait) nécessite d'utiliser un langage. 2

3 UML, qu'est ce que c'est? UML est un langage destiné à modéliser des systèmes (souvent logiciels), (principalement) graphique, unifié et semi-formel. (principalement) graphique Les mots sont des boîtes, des cercles, des arcs, des flèches,... La grammaire et la sémantique sont un ensemble de diagrammes : qui agencent les mots, qui sont destinés à exprimer quelque chose de particulier. unifié UML existe depuis UML est un langage qui résulte de la fusion de trois méthodes de conception orientée objet. Booch'93 de Grady Booch, OMT de James Rumbaugh, OOSE de Ivaar Jacobson. UML est standardisé par un consortium international l'object Management Group. La version actuelle d'uml est la 2.3 (publiée en Mai 2010) Au 3 Nov. 2010, le document de spécification de la version 2.4 est en cours de finalisation) UML, qu'est ce que c'est? UML est un langage destiné à modéliser des systèmes (souvent logiciels), (principalement) graphique, unifié et semi-formel. semi-formel Plus un langage est formel moins il est ambigu. Un langage formel est précis, compact. Moins un langage est formel plus il est «naturel» à utiliser. 3

4 UML, qu'est-ce que cela n'est pas? UML est n'est pas une méthode de développement orientée objet. UML n'est pas une méthode. A la différences des méthodes dont il est issu, Les diagrammes UML sont redondants entre eux; ils peuvent servir de support à différentes méthodes de développement orienté-objet; certains peuvent être plus adaptés à des systèmes particuliers... UML : à quoi ça sert? Modéliser. Pourquoi? Concevoir un système en devenir définir, exprimer, prendre du recul, maîtriser la complexité (décomposition), détailler (formaliser plus qu'une description en langage naturel). Analyser un système existant (rétro ingénierie) se représenter, prendre du recul, comprendre (pour corriger, pour re-concevoir, pour faire évoluer). Documenter garder une trace des choix, fournir une vue synthétique, discuter / juger avant la réalisation Générer, simuler, exécuter générer (autant que possible) du code et/ou de la documentation pour valoriser le travail réalisé en conception (ne pas re-faire), modéliser = réaliser? 4

5 UML : 13 différents types de diagrammes UML propose 13 différents types de diagrammes permettant de représenter différents aspects, facettes, points de vues du système. On classe ces diagrammes en 2 catégories : Diagrammes structurels vue statique du système (ce qu'il est) Diagrammes comportementaux vue dynamique du système (comment il fonctionne) Les diagrammes structurels : diagramme de classes diagramme d'objets diagramme de composants diagramme de déploiement diagramme de paquetage diagramme de structure composite UML : 13 différents types de diagrammes UML propose 13 différents types de diagrammes permettant de représenter différents aspects, facettes, points de vues du système. On classe ces diagrammes en 2 catégories : Diagrammes structurels vue statique du système (ce qu'il est) Diagrammes comportementaux vue dynamique du système (comment il fonctionne) Les diagrammes comportementaux : diagramme de cas d'utilisation diagramme de vue générale d interaction diagramme de séquence diagramme temporel diagramme d'activités diagramme de communication (collaboration) diagramme d'états 5

6 UML : 13 différents types de diagrammes Taxonomie des diagrammes de structure et de comportement Source: OMG «UML superstructure v2.1.2», annexe A, page 697, Nov 2007 UML : 13 différents types de diagrammes Collage of UML diagrams Source: Wikipedia, [11/03/2010]. 6

7 Diagramme de classes Sémantique Les diagrammes de classes représentent la structure statique du système en termes de classes (concepts) et de relations (relations entre concepts). Diagramme de classes nom de la classe attribut Différentes représentations d'une classe méthode Les classes représentent les concepts qui composent le système. Les attributs des classes sont les données (propriétés) relatives à ces concepts. Les méthodes des classes définissent les opérations que savent réaliser les classes, leur comportement. 7

8 Diagramme de classes Attributs et méthodes Un attribut : est une propriété des objets de la classe. est défini par un nom et un type complétés éventuellement par une visibilité et une valeur initiale. Une méthode : est une fonctionnalité de la classe, qui s applique sur les objets de classe. est définie par un nom, des arguments (couples nom :type séparés par des,) et un type de retour. Exemples : Signe Visibilité Signification - isvalidated : Boolean = false + centre : Point + public visible pour tous les utilisateurs de la classe - issmaller (compareto: Objet): Boolean + doublefloat () : float # - protégé privé visible pour toutes les instances des sous-classes de la classe visible pour les instances de la classe uniquement Diagramme de classes Relations entre classes Dans un système, les classes sont interdépendantes. Ces dépendances seront modélisées par des relations entre classes. UML propose différents types de relations (différentes sémantiques) : la relation de généralisation / spécialisation, l'association, l'agrégation, la composition. agrégation généralisation association 8

9 Diagramme de classes Relation d association La relation d association: indique que deux concepts sont liés, liera les instances des deux classes. association La relation «Mariage» relie éventuellement deux instances de la classe «Adulte». La relation «Filiation» relie toute instance de la classe «Enfant» à ses deux parents, instances de la classe «Adulte». Diagramme de classes Relation d association - Rôles et cardinalités Les rôles qualifient les extrémités d une association. Les cardinalités (multiplicités) permettent d exprimer le nombre d instances d une classe extrémité qui sont en relation. card 1 nom_assoc. card 2 Classe 1 Classe 2 rôle 1 rôle 2 Pour l association «nom_assoc.», la classe «Classe 1» joue le rôle «rôle 1» et ses instances sont en nombre «card 1» alors que la classe «Classe 2» joue le rôle «rôle 2» et que ses instances sont en nombre «card 2». Cardinalité Signification Exemples i exactement i 1 i..j de i à j 0..5 i..* au moins i (de i à l infini) 0..*, 1..* 9

10 Diagramme de classes Relation d'agrégation La relation d'agrégation est une relation d'association particulière, exprime la relation tout / partie, signifie «est composé de», «est constitué de». tout - composite agrégation partie - composant Le losange se situe du côté du composite. Diagramme de classes Relation d'agrégation - relation de composition La relation de composition est une spécialisation (plus contraignante) de l'agrégation : les composants sont exclusifs: un objet composant ne peut appartenir qu'à un seul objet composite, les composants sont dépendants: la destruction de l'objet composite entraîne la destruction des objets composants. composition La relation de composition se représente avec un losange noir. agrégation 10

11 Diagramme de classes Relation de généralisation La relation de généralisation / spécialisation : est une relation d'ordre partiel entre concepts (classes), permet d'organiser les concepts du plus général («en haut»), vers le plus spécifique («en bas»). signifie «est une sorte de». super-classe généralisation sous-classe On peut lire les relations de généralisation comme des inclusions ensemblistes : parmi l'ensemble des EtreHumain, il y a ceux qui sont des Enfant et ceux qui sont des Adulte. Diagramme de classes Paquetages Les paquetages permettent de faire des regroupements logiques de classes. Ils peuvent être mis en relation : Généralisation : factorisation de la définition des packages Inclusion : au sens ensembliste Import : indication que le package source importe les éléments publics du package destination Access : indication que le package source accède aux éléments publics du package destination Mon paquetage Mon second paquetage Classe1 Classe2 <<import>> Classe3 Classe4 Classe5 11

12 Diagramme de classes Les stéréotypes permettent d ajouter une information de type sur les classes, les associations. Ils se notent entre << et >> Les interfaces représentent des types abstraits (liste de fonctionnalités sans données). Elles se notent comme les classes avec le stéréotype <<interface>>. Interfaces et stéréotypes UneClasse <<interface>> UneInterface réalise, implémente Quelques stéréotypes prédéfinis : <<énumération>>, <<utilitaire>>, <<acteur>>, <<interface>>, <<exception>>. Diagramme d'objets Sémantique et notation Les diagrammes d objets : donnent une vue instantannée de la façon dont est instancié un diagramme de classes. permettent d illustrer : des états particuliers du systèmes (d un point de vue statique), la structure générale du système lorsque celle-ci est difficile à comprendre au niveau classe (par exemple, dans le cas de relations «récursives» entre classes). Différentes représentations des objets : nom de l objet nom de l objet:nom de la classe :nom de la classe :nom de la classe Il est possible de mentionner des valeurs pour des attributs significatifs et de nommer des états dans lesquels sont les objets. chauffagechambre:radiateur [chaud] température=35 12

13 Diagramme d'objets Martin:Famille Exemple Jean:Adulte mari femme Jeanne:Adulte Jonathan:Enfant Juliette:Enfant Jérémy:Enfant une instanciation possible Il n y a plus de cardinalités (elles valent toutes 1). Les rôles peuvent être représentés. Diagramme de composants Sémantique Un composant est une unité réutilisable : qui contient des classes, qui expose ses capacités sous la formes d interfaces ou de ports fournis et ses besoins sous la forme d interface ou de ports requis. Un diagramme de composants représente un assemblage de composants par connexion d interfaces ou de ports de types compatibles. composant interface requise interface fournie 13

14 Diagramme de composants Interfaces et ports Une interface présente un ensemble de fonctionnalités (toutes) fournies ou requises par un composant. Un port : est un concept de granularité plus élevée. regroupe des interfaces : toutes fournies, toutes requises ou des deux types. sert à représenter des collaborations du point de vue d un composant. port interface L assemblage des composants se fait par «type-matching» entre interfaces ou entre ports. Diagramme de déploiement Sémantique Les diagrammes de déploiement illustrent : la disposition physique des différents dispositifs sur lequel doit s exécuter l application. la répartition des différentes composants du système sur les différents dispositifs physiques. 14

15 Diagramme de déploiement Un diagramme de déploiement est constitué: de nœuds représentant les dispositifs physiques exemples: PC, serveur de BD, imprimante, terminal, serveur web,... de composants «attachés» à des nœuds de liens représentant les communications entre nœuds. Notation et exemple nœud composant lien Diagramme de cas d'utilisation Sémantique Les diagrammes de cas d'utilisation représentent les fonctions remplies par le système, du point de vue des acteurs de son environnement (utilisateurs, humains ou non). cas d utilisation acteur inclusion généralisation Les diagrammes de cas d utilisation capturent les besoins fonctionnels. 15

16 Diagramme de cas d'utilisation Les acteurs : sont des utilisateurs ayant des rôles différents, sont à l extérieur du système, Notation peuvent représenter des utilisateurs humains du système ou d autres systèmes automatisés pouvant agir sur le système. Les relations : Notation Nom Signification «include» communication généralisation include relation reliant un acteur au cas d utilisation qu il peut utiliser relation reliant un cas d utilisation à un autre, plus général relation reliant un cas d utilisation à un autre, qu il utilise (permet de «factoriser» des cas d utilisation). «extend» extend relation reliant un cas d utilisation à un autre, qui définit des extensions particulières (par exemple des cas d erreurs peu fréquents qu on ne souhaite pas inclure dans le cas d utilisation principal). Diagramme de séquence Sémantique Les diagrammes de séquence sont une représentation temporelle des objets et de leurs interactions. Particulièrement adaptés à la description de systèmes où le temps a une importance (temps réel) et où peu d objets sont impliqués dans la réalisation d une fonctionnalité. 16

17 Diagramme de séquence Notation objet ligne de vie d un objet message asynchrone émis par un objet message synchrone émis par un objet période d activation d un objet Diagramme de séquence Notation Les objets : sont des instances de classes du système, :unrole unobjet:uneclasse ou des acteurs qui agissent sur le système. La ligne de vie des objets : représente le temps pendant lequel il existe. si l objet est créé durant la séquence, le message de création pointe vers l objet. si l objet est détruit durant la séquence, sa ligne de vie se termine par une croix. La période d activation : représente la durée pendant laquelle un objet est actif et occupé à réaliser une action. unobjet:uneclasse <<create>> blabla () unautreobjet:uneautreclasse <<destroy>> 17

18 Diagramme de séquence Les messages : représentent les interactions entre objets appels de procédure, signaux, événements, Notation peuvent être synchrones ou asynchrones, représenter des retours du flot de contrôle (avec ou sans valeur de retour) comporter des étiquettes. appel synchrone (de procédure) retour Dans le cas d appels synchrones, le flot de contrôle ne revient à l appelant qu une fois les activités appelées terminées (imbrication). Diagramme de séquence Notation Lorsqu un objet s envoie à lui-même un message : on parle de réflexivité (voire de récursivité). Le rectangle d activation se «dédouble». Les structures de contrôle habituelles (boucles, alternatives, parallèle, ) se représentent grâce à des boîtes étiquetées contenant des «fragments d interactions». 18

19 Diagramme de collaboration Sémantique et notation Les diagrammes de collaborations sont une représentation spatiale des objets et de leurs communications. objet communication entre objets La base du diagramme de collaboration est un diagramme d objets auquel on rajoute les différentes communications (principalement appels de méthodes) entre objets, numérotées. La numérotation peut prendre une forme hiérarchique. Exemple : Les communications asynchrones sont représentées par une demi-flèche. Ces diagrammes sont largement redondants avec les diagrammes de séquence. Diagramme d'activités Sémantique et notation Les diagrammes d'activités représentent le comportement d'une méthode, d'un cas d'utilisation ou d un métier. état initial condition activité point de décision (alternative) état final 19

20 Diagramme d'activités Dans le cas où le diagramme représente un métier, on peut être amené à le partitionner. client fournisseur banquier Notation Trois partitions du diagramme global fork join Il peut exister des partitions selon deux dimensions (quadrillage). Diagramme d'états Sémantique Les diagrammes d états / transitions permettent de représenter la dynamique du comportement (interne) des instances d une classe. automate à états finis, formalisme des statecharts (David Harel) Un diagramme représente : les différents états internes possibles d un objet les évolutions possibles d un état vers un autre, en fonction d événements perçus par l objet (appel de méthodes, événements). Il y a au plus un diagramme d états par classe d objets. A tout instant, un objet occupe un seul état du diagramme. Pour sortir d un état, un objet ne franchit qu une seule transition, le menant à un seul nouvel état (déterminisme). 20

21 Diagramme d'états Sémantique et notation : les états Les états : identifient des situations particulières (désignables) d un objet : représentent des valeurs pour ces objets (c est à dire des combinaisons particulières de valeurs d attributs) représentent des «moments» durables dans la vie de l objet dont la fin sera déclenchée par l occurrence d un événement perceptible par l objet. Exemple Un radiateur est dans l état «en chauffe» si sa résistance est allumée. Il sortira de cet état si on tourne le thermostat de telle façon que la température cible soit inférieure à la température de la pièce ou si on l éteint. Les actions internes décrivent ce que fait l objet pendant qu il est dans cet état (en y entrant, avant d en sortir, tout au long). Deux pseudo-états : les états initiaux (exactement un) et finaux (éventuellement plusieurs). état initial état final Nom de l état Actions internes Sous états Diagramme d'états Sémantique et notation : les états Actions internes étiquette / liste d actions Etiquettes possibles : entry : liste d actions exécutées pour gérer l entrée dans cet état (en entrant), exit : liste d actions exécutées pour gérer la sortie de cet état (avant d en sortir), do : activité exécutée par l objet pendant qu il est dans cet état. L activité est exécutée jusqu à ce que l objet quitte l état (réception d un événement) ou que l activité s achève d elle même (événement de complétion implicite). «événement» : transition interne. A ne pas confondre avec une transition externe vers le même état. Nom de l état entry/ liste actions do / activité événement [condition] / liste actions exit / liste actions 21

22 Diagramme d'états Les transitions : représentent la réaction d un objet à l occurrence d un événement sous la forme d un changement d état de l objet. relient deux états de l objet (éventuellement le même), s «exécutent» de façon atomique : une fois déclenchées, il n est pas possible de les interrompre en cours d exécution, sont décrites par : un événement (ce qui survient et déclenche la transition) une condition (qui doit être satisfaite pour que la transition soit franchie) des actions réalisées au moment du franchissement Sémantique et notation : les transitions Etat 1 événement [condition] / actions Etat 2 Exemples de règles ECA : tropchaud() [été] / allumerclimatisation() tropchaud() [hiver] / ouvrirfenêtre() Diagramme d'états Sémantique et notation : règles ECA Evénement appel d une méthode publique de l objet, événements temporels : mot clé after suivi d une durée depuis l entrée dans l état, détection d un changement : mot clé when suivi d une condition qui devient vraie lorsque quelque chose change dans l environnement de l objet, Condition (garde) évaluée au moment du déclenchement de la transition, elle conditionne son franchisement, identifie une transition unique parmi celles sortant de l état courant déclenchées par un même événement, pseudo code portant sur les paramètres de l événement et toutes les valeurs accessibles depuis l objet courant. Exemples d événements : mettreenroute() after (5 sec) when (switch in state ON AND heatingelement not in state HOT) 22

23 Diagramme d'états Actions : suite d actions séparées par des, deux types d actions : Sémantique et notation : règles ECA exécution d une méthode de l objet, envoi d un message à un autre objet : en pseudo code, précédé par un ^ possibilité de récupérer les valeurs de retour dans des variables Exemple d actions : affiche(«servez-vous»), ^lapompe.demarre() Diagramme d'états Exemple alternative «create» En Attente «destroy» autoriser() when (le_pistolet in state Accoché) / arreter() [le_pistolet in state Accroché] [le_pistolet in state Décroché] / demarrer() Distribution en cours demarrer () Autorisée 23

24 Diagramme d'états Etats composites Deux façon de décomposer un état (composite) en un diagramme d états : Décomposition disjonctive (ou) le sous diagramme définit une disjonction de sous états : l objet n en occupe qu un seul à la fois. Décomposition conjonctive (et) un état est décomposé en un ensemble de sous diagrammes d états représentant chacuns une composante indépendante du super-état, un objet peut occuper un état dans chacune des composantes décrites. L état résultant est la conjonction des états occupés simultanément dans les différentes composantes. Deux exemples de décomposition conjonctive Diagramme d'états Etats composites Règles de transition vers / depuis un état composite un objet qui entre dans un état composite entre concrètement dans l un de ses sous-états, lorsqu un état possède plusieurs composantes, l objet entre simultanément dans l un des états de chacune des composantes, toutes les actions d entrée des sous-états concernés s appliquent, dans l ordre hiérarchique, un objet quitte un état composite en franchissant une transition qui amène l objet dans un nouvel état, les actions de sorties de tous les sous-états concernés s appliquent, dans l ordre inverse de la hiérarchie, un objet quitte simultanément toutes les composantes d un état. 24

25 Processus de développement Un? Des? Il n y a pas un qui, universellement suivi, garantit la qualité des développements. Cela ne signifie pas qu il n est pas important de suivre un. RUP (Rational Unified Process) essaie de donner des règles générales de gestion du développement à l aide d un et identifie les qualités que doivent posséder les. La suite du cours propose un, centré sur les cas d utilisation. Il existe d autre types de, par exemple des centrés sur l architecture. Processus de développement Ci-dessous des causes de problèmes dans le développement Compréhension imprécise des besoins utilisateurs Incapacité à gérer les changements des besoins utilisateurs Mauvaises pratiques Modules incompatibles Logiciel difficile à maintenir ou à étendre Découverte tardive de faiblesses sérieuses dans le projet Mauvaise qualité du logiciel produit Performances inacceptables Impossibilité de savoir qui a changé quoi, quand et pourquoi dans l équipe de développement Mauvais de livraison 25

26 Processus de développement Développer le logiciel itérativement Réduction du risque Satisfaction du client qui se rend compte de la progression Gérer les exigences (ingénierie des besoins) Identifier pour communiquer Hiérarchiser les priorités, filtrer, garder une trace Détecter les incohérences au plus tôt Utiliser les architectures à base de composants Modularité pour maîtriser la complexité Réutilisation Utilisation de frameworks standards Bonnes pratiques Processus de développement Bonnes pratiques Modéliser le logiciel visuellement Etre moins ambigu qu en utilisant la langue naturelle Outiller la modélisation par exemple pour disposer du niveau de détail souhaité (cacher ce qui n est pas nécessaire) S assurer de la qualité du logiciel Tout au long du Contrôler les changements du logiciel Pour accroître la traçabilité Outiller ce suivi pour mesurer et pour aider à la gestion de la cohérence des configurations 26

27 Processus de développement Les différentes activités du de développement Modélisation de domaine Comprendre la structure et la dynamique de l organisation Comprendre les problèmes posés dans le contexte de l organisation Ecrire d un glossaire Recueil des besoins (auprès des clients et parties prenantes du projet) Ce que le système doit faire Expression des besoins dans des cas d utilisation Spécifications des cas d utilisation en scénarii (scénario principal, scénarii secondaires, cas d erreurs) Limites fonctionnelles du projet Spécifications non fonctionnelles Critères de performance ou de sûreté de fonctionnement (par exemple: rapidité, qualité, fiabilité, sécurité, consommation de ressources) Planification et prévision de coût Le recueil et l expression des besoins doivent permettre de définir le contrat de développement de l application, en connaissance de cause. Processus de développement Maquettage de l IHM Le maquettage peut être réalisé avec n importe quel outil graphique : simples dessins d écrans Prototype d interface généré par un outil Intéressant pour décrire les interfaces avec des acteurs humains : dialogue avec le client, étape concrète de progression pour le client. Analyse et conception Transformation des besoins utilisateurs en modèles UML Modèle d analyse et modèle de conception Implémentation Développement itératif Découpage en couches Composants d architecture Unités indépendantes, équipes différentes Test, déploiement Les différentes activités du de développement 27

28 Processus de développement Activités / diagrammes diagr. de classes Modélisation de domaine diagr. d objets Recueil et expression des besoins Maquettage Analyse et conception Implémentation Déploiement diagr. de composants diagr. de déploiement diagr. de cas d utilisation diagr. de séquence diagr. de collaboration diagr. d états Test diagr. d activités Processus de développement Activités / diagrammes diagr. de classes Modélisation de domaine diagr. d objets Recueil et expression des besoins Maquettage Analyse et conception Implémentation Déploiement diagr. de composants diagr. de déploiement diagr. de cas d utilisation diagr. de séquence diagr. de collaboration diagr. d états Test diagr. d activités 28

29 Processus de développement Activités / diagrammes diagr. de classes Modélisation de domaine diagr. d objets Recueil et expression des besoins Maquettage diagr. de composants diagr. de déploiement diagr. de cas d utilisation Analyse et conception diagr. de séquence Implémentation Déploiement diagr. de collaboration diagr. d états Test diagr. d activités Processus de développement Modélisation du domaine La modélisation du domaine consiste à déterminer quels sont les concepts utilisés par l organisation dans le champ de l étude. Modéliser sans se restreindre au logiciel à produire Ce modèle contiendra des éléments qui seront plus tard repris dans le modèle du système mais aussi une description de l environnement (notamment des acteurs). Ne pas hésiter à «être trop large» Proposition de marche à suivre Interviews des clients et parties prenantes Identifier les «noms» : ce sont les concepts Identifier les «verbes» : ce sont les relations entre concepts Productions (délivrables) Un / des diagramme de classes Un document qui définit l ensemble des concepts figurant dans ce diagramme. 29

30 Processus de développement Recueil et expression du besoin Le recueil des besoins consiste à identifier l ensemble des besoins à modéliser / satisfaire. Cette étape cruciale du de développement permet de calibrer le projet et de limiter les malentendus ultérieurs. Cette étape conduit au cahier des charges, qui est un document contractuel. Le cahier des charges devra contenir des éléments de planification du projet de développement. Proposition de marche à suivre Cahier des charges informel (fourni par le client) et interviews du client et des parties prenantes Identification d objectifs fonctionnels Lister les fonctionnalités que le système doit produire Raffiner en détaillant les fonctionnalités secondaires, le traitement des erreurs Identification des objectifs non fonctionnels Le recueil et l expression des besoins doivent s appuyer sur le modèle de domaine notamment sur le glossaire) défini à l étape précédente. Ils doivent aboutir à la description des bornes du système. Processus de développement Recueil et expression du besoin Productions (délivrables) : Cahier des charges les diagrammes de cas d utilisation la description textuelle des acteurs et de leur rôle par rapport au système la description textuelle des cas d utilisation explicitant les scénarios d utilisation du système : scénario principal : fonctionnalité identifiée par le cas d utilisation début fin scénarios secondaires : étapes secondaires dans le déroulement de la fonctionnalité (inclusion et extension d autres cas d utilisation) scénarios exceptionnels : traitement des erreurs, identifications de contraintes éventuellement des diagrammes de séquence illustrant les scénarios décrits sous la forme d échanges de messages entre le système et les acteurs 30

31 Processus de développement Recueil et expression du besoin - Exemple de squelette de document Schéma Diagramme de cas d utilisation présentant les fonctionnalités et l environnement du système Acteurs Description des différents acteurs utilisant le système Nom : nom de l acteur. Description : définition de l acteur. Rôle : description du rôle de l acteur vis-à-vis du système Cas d utilisation < nom du cas d utilisation > Fonctionnalité : Description synthétique du service rendu par le système Acteur principal : acteur auquel s adresse principalement la fonctionnalité Acteurs secondaires : autres acteurs participant au cas d utilisation Début : Action qui détermine l entrée dans ce cas d utilisation. Fin : Action qui détermine la sortie du cas d utilisation. Processus de développement Recueil et expression du besoin - Exemple de squelette de document Scénarii Description des scénarios qui explicitent le déroulement typique de l utilisation de la fonctionnalité A. Principal Trame générale de l utilisation de la fonctionnalité B. Secondaires Trame détaillée de l utilisation de la fonctionnalité. Décrit les développements possibles de son déroulement en termes de points d inclusion et d extension d autres cas d utilisation. C. Alternatifs Présentation des différents scénarios exceptionnels (en général traitement d erreurs, information des utilisateurs, ). Contraintes non fonctionnelles (opt.) confidentialité, temps de réponse, disponibilité, fréquence, concurrence, volumétrie, concurrence 31

32 Processus de développement Recueil et expression du besoin - Outils de suivi Matrice des exigences rappelle l ensemble des exigences (besoins) et leur couverture par les différents scenarii des cas d utilisation s assurer de l exhaustivité de l ensemble des cas d utilisation permettre la traçabilité entre l expression du besoin informelle du client (cahier des charges préliminaire) et sa formalisation Cas d utilisation Scenarii Exigence 1 Exigence 2... Exigence n Cas «A» scenario A.1 scenario A.2 scenario A.3 Cas «B» scenario B.1 scenario B.2... Processus de développement Recueil et expression du besoin - Outils de suivi Définition des incréments - planning de réalisation définir les ensembles de cas d utilisation qui seront traités à chaque étape de l itération du de développement l incrément peut être fonction : du risque (haut, bas, moyen) : lever au plus tôt les risques de la priorité (haute, basse, moyenne) : satisfaire les besoins du client des dépendances entre cas d utilisation (les inclusions en premier, puis les cas de base et enfin les extensions) de la durée estimée de réalisation (commencer par le plus court pour délivrer des premiers résultats tôt) Cas d utilisation Risque Priorité Durée de réalisation Incrément Cas «A» Cas «B»... 32

33 Processus de développement Le maquettage permet de : Valider les besoins fonctionnels avec le client, dialogue, précisions, remises en cause et détection des incompréhensions Maquettage S entendre sur l apparence du logiciel produit l apparence est le mode d interaction de l utilisateur avec le logiciel les IHMs sont le bon niveau d information pour dialoguer avec le client tout client «se les représente» déjà c est concret et cela ne contient aucune information sur la réalisation Proposition de marche à suivre Réaliser une maquette simple des interfaces du système correspondant à chacun des scenarii décrits Utiliser un outil qui permet de dessiner les écrans (et génère du code) Productions (délivrables) Dans le cahier des charges, pour chaque scenario, ajouter une rubrique «Besoins d IHM» (opt.) Images et description des éléments d IHM nécessaires Processus de développement Analyse et conception Lors des phases d analyse et de conception, il s agit de détailler de plus en plus les réalisations à produire. Le premier modèle d analyse contient un extrait du modèle de domaine et des diagrammes de séquences réalisés à partir des cas d utilisation. Ces différents modèles sont raffinés et complétés au fur et à mesure (ajout au besoin d autres types de diagrammes) pour prendre en compte les choix techniques. 33

34 Processus de développement Implémentation, test, déploiement L implémentation doit être : tracée (qui fait quoi, quand, pourquoi), incrémentale. Le test doit permettre de produire du logiciel de qualité. Les tests à réaliser doivent être identifiés très tôt dans le, être systématiques et leurs résultats tracés. Tests unitaires fonction par fonction tester le cas normal et les cas d erreurs les plus fréquents Tests fonctionnels basés sur les scenarii implémentés, les diagrammes de séquences à chaque incrément de développement réaliser les nouveaux tests relatifs aux nouveaux scenarii concernés par l incrément réaliser à nouveaux tous les tests antérieurs pour vérifier la non-régression» une façon de procéder (à adapter au projet, notamment sa taille et son nombre d intervenants) : builds quotidiens et tests nocturnes avec rapport de tests tous les matins Les étapes du déploiement doivent être tracées pour être reproductibles. Tendances actuelles UML, et après? Evolution d UML Meilleur support de la programmation par composants, de la réutilisation. UML exécutable Objectif Simuler les modèles (pour valider autant que possible) avant de coder, Ne plus implémenter : exécuter les modèles. Ingénierie Dirigée par les Modèles (Model Driven Engineering) Modéliser pour transformer dans un autre formalisme de modélisation (bus de modèles), Modéliser pour transformer en code exécutable dans diverses plateformes techniques, Initiative MDA (Model Driven Architecture) de l OMG qui s appuie sur le MOF (MetaObject Facility), le méta-modèle d UML, Approches génératives s appuyant sur des transformations de modèles, modéliser au lieu d implémenter, gérer l évolution conjointe des modèles et de l implémentation (co-évolution). 34

35 Bibliographie et netographie spécifications, méta-modèle d UML, documents divers UML Modélisation objet avec UML. P.A. Muller, N. Gaertner. Eyrolles. UML en action. P. Roques, F. Vallée. Eyrolles. RUP The Rational Unified Process - An introduction. P. Kruchten. Addison-Wesley. The Unified Software Development Process. I. Jacobson, G. Booch, J. Rumbaugh. Addison-Wesley. 35