Cours 8 Démarche d’application d’UML...SSinon le «Processus Unifié» et le 2TUP (2 tracksUnited Process) SValables pour les grands projets SPlusieurs démarches appliquées

Chap.2 1

S

Cours 8Démarche d’application d’UML

Comment bien utiliser UML ?Processus et bonnes pratiques

ConceptionArchitecture en couches, architecture MVC

MOOCSI, Miage M1 - Polytech, Univ. Lyon1© V. Deslandres

Analyse Conception Implémentation

MODELES PROGRAMMES

LANGAGES DE MODELISATION

(ex. : UML)

LANGAGES DEPROGRAMMATION

(ex.: JAVA)

DÉMARCHE DE DEVELOPPEMENT

Copyright V. Deslandres, Univ. Lyon12

Chap.2 2

Analyse à implémentation

Ex. de traduction d’un modèle

public class Etape {// réalisation de l'association avec les incidents d'étape :

private List<IncidentEtape> listeIncident;…// opérations de gestion :public Boolean ajouterIncident( IncidentEtape inc) {

listeIncident.addElement( inc);return true;

}public Boolean retirerIncident( IncidentEtape inc) {

int listeIncident.removeElement( inc);return true;

}public List<IncidentEtape> listerIncidents() {

List<IncidentEtape> clone = listeIncident.clone();return clone;

}} Copyright V. Deslandres, Univ. Lyon13

Analyse à implémentation

Ex. de traduction d’un modèle (2)

package SIVEx.metier.mission;…

public class IncidentEtape {

public IncidentEtape() {// constructeur de l’incident : def des attributs, etc.

}// rien sur l’étape où a lieu l’incident ?…..}


Chap.2 3

Avertissement

S Il n’y a pas UNE démarche officielleS Sinon le « Processus Unifié » et le 2TUP (2 tracks United Process)

S Valables pour les grands projets

S Plusieurs démarches appliquées par les professionnelsS fonction de leur culture, de leur passé

S des besoins, du type d’applications


Les impératifs

S Diagrammes lisibles

S Un diagramme doit tenir sur une page A4S Éventuellement imbriquer les diagrammes, zooms

S Titre clair, exploitation des notes explicatives

S Diagrammes traçables : documenter finement

S Dates, version, étapes, etc.

S Objectif : garder une trace de la réflexion menée

S Ne pas se précipiter sur les classes, penser indépendamment des langages cibles


Chap.2 4

Synthèse Démarche :1- Capture des besoins /

analyse


Synthèse Démarche :2- l’analyse détaillée


Chap.2 5

Synthèse Démarche :3- la conception


1. Diagramme de séquence système ou diagramme de contexte dynamique


acteur1

système

acteur2

Détail de la méthodologie UML (1)

10

Chap.2 6

Diag. de contexte dynamique SIVEX


SIVEx

: Client

: Réceptionniste

: Comptable

:

:Progiciel Comptabilité

: Répartiteur

: Chauffeur

: Opérateur de

Quai

: Responsable

Logistique

: Administrateur

Système

8: confirmation commande

25: en-cours

5: création, modification,

annulation commande6: création client

7: conditions commande

26: en-cours

2: règlement

3: factures

4: relance1: factures

13: incident mission

15: commande à traiter

16: état ressources

14: création, modification

mission

17: bordereaux

mission

18: arrêt/départ étape19: événement mission

20: identification colis

23: pointage colis24: début/fin inventaire

21: listes colis commande

22: étiquette

10: création,

modification 12: affectation ressources

11: statistiques

transport

9: création, modification

profil utilisateur

11

2. Cas d’utilisation et packages

S Identifier : les acteurs, les cas d’utilisation

S Structurer les cas d’utilisation en packages

S Décrire textuellement chaque cas d’utilisation à l’aide d’une fiche descriptive selon le standard proposé

2. Si nécessaire, représenter les différents chemin possibles de l’application par un diagramme global d’activitéS Points d’entrée, déroulement général par branche


Démarche proposée (2)

12

Chap.2 7

Démarche proposée :étape 3

3. Par cas d’utilisation : diagrammes d’activités et premières IHMs

S Détailler les cas d’utilisation par des diagrammes d’activités

S Identifier les principales IHMs

S Définir les règles de navigation entre les principaux écransproposés à l’utilisateur

S Lister les scénarios (point de vue utilisateur: nominaux,exceptions).


Démarche proposée (4)

4. Modèle du domaine

S Identifier les concepts métier manipulés par les acteurs et construire le diagramme des classes du domaine, par package

S Établir un glossaire des classes : liste des classes avec leurs attributs


Chap.2 8

Phase analyse à analyse détaillée

S A ce stade on a terminé la phase d’expressions des besoins utilisateur.S On peut être amené à donner le « Rapport d’analyse des Besoins » au Client pour

validation

S Certaines utilisations d’UML s’arrêtent là.

S La suite de la démarche concerne l’analyse détaillée : on va détailler commentfonctionnera le système envisagé.


Analyse détaillée

5. Enrichir les Diagrammes de Cas d’Utilisation

S Ajouter des informations supplémentaires comme :S la fréquence d'utilisation du cas,

S la volumétrie,

S les contraintes de performances,

S les IHM plus détaillée,

S et svt aussi un numéro de version.


Chap.2 9

Analyse Détaillée

6. Construire les diagrammes de séquences

S Pour chaque cas, distinguer :S le scénario nominal : le chemin « normal et usuel » pour atteindre

l’objectif du cas d’utilisation.

S les extensions : qui comprennent les chemins moins directs ainsi que les « exceptions ». Elles doivent se brancher sur le scénario nominal.

S Formaliser les scénarii avec des diagrammes de séquencesS en faisant apparaître les différents objets (internes au système) qui

interagissent

S Utiliser plusieurs diagrammes si nécessaire, vérifier la cohérence globale


Analyse détaillée (suite)

7 Compléter le diagrammes de classes des classes de l’application identifiées lors de la modélisation dynamique

S Ex. Classes Métier = Comptes, Clients

S Classes d’application : opérations, transactions


Chap.2 10

Acquis de la phase d’analyse

S A l’issue de l’analyse (analyse + analyse détaillée), on est capable de proposer un rapport d’analyse fonctionnelle propre et pertinent :

S Qui traduit l’expression des besoins fonctionnels

S Qui va permettre de valider avec le client et les utilisateurs l’application envisagée

Avant de passer à l’étape de Conception

S 80% des utilisations d’UML s’arrêtent là


Matrice de traçabilités

S Parfois pour pouvoir valider avec le Client, on dresse une « matrice de traçabilité » avec :S d’un côté : les exigences fonctionnellesS de l’autre : les use case

è Une croix montre où sont traitées les exigences fonctionnelles

è Prépare les tests d’acceptation

è Un exemple ?


Chap.2 11


Exigences

Cas d’utilisation

Stéréotypes de Jacobson

S En conception, on peut être amené à distinguer les éléments selon leur type :S Éléments d’interface, de contrôle ou entité (classe persistante)

S On utilise pour cela les stéréotypes de classes de Jacobson : « boundary », « control » ou « entity »S Que l’on mentionne en tant que stéréotype ou via les symboles :

Copyright V. Deslandres, Univ. Lyon122« entity » « boundary » « control »

Chap.2 12

Conception

9. Compléter les diagrammes de classes d’analyse :

S Ajouter : les identifiants, les types, énumérations, vérifier les navigabilités, ajouter les constructeurs et les get/set

S Attention le diagramme devient alors ILLISIBLE, il n’existe que pour la génération de code. C’est important de conserver un diagramme d’analyse propre, de le dupliquer juste pour la conception / génération de code.

S Rédiger les « contrats » des opérations complexes (MEYER, langage Eiffel) :pré/post conditions des méthodes, assertions, invariants

S Cf un exemple ci-après

S Compléter les « responsabilités » des classes et les réorganiser à l’aide d’interfaces

Copyright V. Deslandres, IUT de Lyon23

Ex.: réorganisation de classes

S Et on imagine pouvoir afficher : une ville et un chauffeur


S On va créer une interface spécifiant (labélisant) ce qui est Représentable (ici, qui a un nom et des infos complètes)

S Et une classe d’implémentation Affichechargée d’afficher un objet ‘Représentable’

Chap.2 13

Ex.: réorganisation de classes

25Source : Bernard Vinot

Conception (suite)

S Diagrammes de Séquences : on en redéfinit de nouveaux, plus techniques, pourapprofondir certains processus techniques complexes, en utilisant les stéréotypes deJacobson (svt à l’aide du reverse Engineering)


Chap.2 14

Conception (fin)


SystèmeBase

Données

S Développer quelques Diagrammes de Séquences Système : identification des différents composants ou serveurs externes, et de leurs interactions entre composants ou sous-systèmes

S Vérifier les dépendances fonctionnelles entre les packagesS Éviter les dépendances mutuelles

S Éviter les dépendances circulaires

Dépendances entre Packages

S Ici, cela signifie que :• Un élément de P2 au moins utilise

un élément public de P3 et de P1

• Un élément de P3 au moins utilise un élément public de P1

• P1, P2 et P3 peuvent utiliser les éléments publics de P0

Copyright V. Deslandres, IUT de Lyon28Il y a t-il des dépendances mutuelles ou circulaires ici ?

Chap.2 15

Architecture Logiqueen Couches

S Pourquoi ? Répondre au critère d’évolutivité:S Pouvoir modifier l’interface de l’application sans devoir modifier les règles métier ;

S Pouvoir changer de mécanisme de stockage sans avoir à retoucher l’interface, ni les règles de gestion.

S ObjectifS Isoler la logique métier des classes de présentation

S Interdire l’accès direct aux données persistantes par le « Client », i.e. les classes de la couche Présentation.


Architecture Logiqueà 3 niveaux

S Présentation:

Classes «IHM»

S Logique: Règles Métier

Ex. : Traiter passage en Caisse

S Stockage:

Copyright V. Deslandres, Univ. Lyon1Base De Données

Caisse EnregistreuseCaisse Enregistreuse

Numéro Quantité

Total Paiement

Saisie Article

Fin De Vente

Saisie Paiement

30

Chap.2 16

Composants des 3 couches


Niveau Logique: Règles Métier

Ex.: Traiter passage en Caisse

Chaque niveau n’interagit qu’avec les niveaux immédiatement proches

Architecture TechniqueMVC

S Cependant, cette décomposition en trois couches n’est pas suffisantepour la maintenance (objectifs de modularité et de réutilisabilité).S Elle conduit les objets graphiques de présentation à connaître le détail de la

couche logique, ce qui nuit à leur maintenabilité et leur réutilisabilité.

S Idée: Introduire un objet artificiel, appelé «Contrôleur», entre les objets d’IHM et les objets métier.

Architecture «Modèle Vue Contrôleur» (MVC)


Chap.2 17

Vue / Présentation

Objets Métier + Traitements Logique applicative

Persistance des Données


On récupère ici une chaîne de caractères, pas directement le champ ArticleLibellé de la table

MVC

IntermédiaireVue / Métier

Rappel : MVC

S Modèle : côté applicatifS Contient les classes Métier issues de l’analyse : classes du domaine et classes de

l’applicationS Représente les classes les plus stables de l’application

S Implémente les traitements (règles de gestion) des données manipulées par l'application;S Permet l'accès et la mise à jour des données (ex. connexion à un SGBD).

S Vue : côté visuel (IHM)S Présente les données brutes renvoyées par le modèle ;S Il peut y avoir plusieurs vues pour des mêmes données (camemberts, courbes, etc.) ;S Envoie au contrôleur les événements générés par les actions de l'utilisateur sur l'IHM.


Ex.: le compte bancaire

Ex.: une représentation du compte bancaire

34

Chap.2 18

Présentation MVC

S Contrôleur : côté événementiel

S Assure la synchronisation entre le modèle et les vues ;

S Analyse les événements liés aux actions de l'utilisateur et invoque les méthodes du modèle ;

S Renvoie ensuite la vue correspondant à la demande.


En résumé: Le modèle représente le véritable contenuLa vue est une représentation / visualisation du contenuLe contrôleur gère les actions de l'utilisateur et les répercute sur la vue et sur le modèle.

35

Architecture MVC


Signale les évènements liés aux actions de l'utilisateur sur

l'IHM

Modèle

Notifie changement de contenu

Met à jour les éléments visuels

Lit le contenuMet à jour le

contenu

VueContrôleur

Modèle en couches vs. MVC : flux de contrôle plus souple en MVC

Chap.2 19

MVC : points forts / faibles

S AvantagesS La séparation des couches permet des modifications de l'une d'entre elles sans

altérer le comportement des autres ;

S Les vues impactées par la modification du modèle sont mises à jour en même temps.

S InconvénientsS Complexification du logiciel

S effort de conception supplémentaire en amont

S Une certaine lourdeur en nb de classes S Alternative MVC2 : un seul contrôleur qui se charge de rediriger la requête vers

le bon traitement.


MVC vs. M-VC

S Il est parfois difficile de dissocier la vue du contrôleur, on parle alors de modèle M-VC

S C'est le cas de la Swing Java : S Swing s'appuie sur l'architecture MVC pour certains de ses

composants graphiques (pas tous !!)

S MVC adapté: la vue et le contrôleur sont combinés dans un même objet.


Chap.2 20

Couche Présentation :concepts clefs

S Concevoir ou documenter une couche de présentation revient à passer en revue les trois aspects :S le visuel

S fenêtres ou pages et leur contenu, que l’utilisateur voit, redimensionne, bouge et réduit

S le comportementalS les actions que l’utilisateur peut déclencher ; les changements d’aspects

S le fonctionnelS flux de données transmis via des listes de choix, des champs d’édition


Quelle description pour la couche Présentation ?

S La description statique des classes d’IHM est rarement faite en UML !

S Par contre, les comportements et descriptions de flux peuvent l’être…

S IDE modernes è construction immédiate de l’IHM statique :S force pour la productivitéS faiblesse pour l’apparente facilité qui masque les contraintes

d’architecture d’une conception.

S Eviter l’amalgame de responsabilités de niveau comportements, fonctionnels et applicatifs, au sein de la même classe d’IHM !


Chap.2 21

Traduction simple des visuels des IHM : à partir du DCL


Ex. SIVEX

S À chaque vue on associe un contrôleur :


(le contrôleur prend en charge les activités impliquant une coordination avec

la couche de l’application)

Chap.2 22

Etudes de Cas

S Illustration de la démarche :


Etude de cas Jeu de Dés

../../../etudesCas/jeuD%C3%A9s/EtudeCas_JeuD%C3%A9s.ppt

Documents

Cours 8 Démarche d’application d’UML...SSinon le «Processus Unifié» et le 2TUP (2 tracksUnited Process) SValables pour les grands projets SPlusieurs démarches appliquées