View
2
Download
0
Category
Preview:
Citation preview
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 ?…..}
Copyright V. Deslandres, Univ. Lyon14
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
Copyright V. Deslandres, Univ. Lyon15
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
Copyright V. Deslandres, Univ. Lyon16
Chap.2 4
Synthèse Démarche :1- Capture des besoins /
analyse
Copyright V. Deslandres, Univ. Lyon17
Synthèse Démarche :2- l’analyse détaillée
Copyright V. Deslandres, Univ. Lyon18
Chap.2 5
Synthèse Démarche :3- la conception
Copyright V. Deslandres, Univ. Lyon19
1. Diagramme de séquence système ou diagramme de contexte dynamique
Copyright V. Deslandres, Univ. Lyon1
acteur1
système
acteur2
Détail de la méthodologie UML (1)
10
Chap.2 6
Diag. de contexte dynamique SIVEX
Copyright V. Deslandres, Univ. Lyon1
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
Copyright V. Deslandres, Univ. Lyon1
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).
Copyright V. Deslandres, Univ. Lyon113
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
Copyright V. Deslandres, Univ. Lyon114
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é.
Copyright V. Deslandres, Univ. Lyon115
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.
Copyright V. Deslandres, Univ. Lyon116
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
Copyright V. Deslandres, Univ. Lyon117
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
Copyright V. Deslandres, Univ. Lyon118
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à
Copyright V. Deslandres, Univ. Lyon119
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 ?
Copyright V. Deslandres, Univ. Lyon120
Chap.2 11
Copyright V. Deslandres, Univ. Lyon121
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
Copyright V. Deslandres, IUT de Lyon24
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)
Copyright V. Deslandres, Univ. Lyon126
Chap.2 14
Conception (fin)
Copyright V. Deslandres, IUT de Lyon27
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.
Copyright V. Deslandres, IUT de Lyon29
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
Copyright V. Deslandres, Univ. Lyon131
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)
Copyright V. Deslandres, Univ. Lyon132
Chap.2 17
Vue / Présentation
Objets Métier + Traitements Logique applicative
Persistance des Données
Copyright V. Deslandres, Univ. Lyon133
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.
Copyright V. Deslandres, Univ. Lyon1
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.
Copyright V. Deslandres, Univ. Lyon1
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
Copyright V. Deslandres, Univ. Lyon136
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.
Copyright V. Deslandres, Univ. Lyon137
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.
Copyright V. Deslandres, Univ. Lyon138
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
Copyright V. Deslandres, Univ. Lyon139
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 !
Copyright V. Deslandres, Univ. Lyon140
Chap.2 21
Traduction simple des visuels des IHM : à partir du DCL
Copyright V. Deslandres, Univ. Lyon141
Ex. SIVEX
S À chaque vue on associe un contrôleur :
Copyright V. Deslandres, Univ. Lyon142
(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 :
Copyright V. Deslandres, Univ. Lyon143
Etude de cas Jeu de Dés
Recommended