ENSTA : cours IN204 Introduction JAVA et UML - PowerPoint PPT Presentation

1 / 36
About This Presentation
Title:

ENSTA : cours IN204 Introduction JAVA et UML

Description:

Il faut conceptualiser le probl me du point de vue du client ... Use case : s quence d'actions r alis es par le syst me produisant un r sultat observable par un acteur ... – PowerPoint PPT presentation

Number of Views:56
Avg rating:3.0/5.0
Slides: 37
Provided by: sig9
Category:

less

Transcript and Presenter's Notes

Title: ENSTA : cours IN204 Introduction JAVA et UML


1
ENSTA cours IN204 Introduction à JAVA et UML
  • Olivier Sigaud
  • LIP6/AnimatLab
  • olivier.sigaud_at_lip6.fr
  • 01.44.27.88.53

2
Plan du cours 9
  • Cas d'utilisation
  • UML diagrammes de séquence
  • UML diagrammes états-transitions
  • Démarche d'utilisation d'UML
  • Cohérence entre les vues
  • Organisation du projet (2)

3
Diagrammes de séquence
4
Le diagramme de séquence
Application
Simulateur
Population
Genome
création
création
création
création
soumission
évaluation
Permet d'identifier les interactions entre objets
concernés
5
Conceptualisation
  • Il faut conceptualiser le problème du point de
    vue du client
  • Identifier les acteurs (entités externes agissant
    sur le système)
  • Use case séquence dactions réalisées par le
    système produisant un résultat observable par un
    acteur
  • Diagramme des cas ensemble des Use cases, doit
    décrire les exigences fonctionnelles du système
  • Permet de
  • développer orienté utilisateur
  • découper les grandes tâches
  • communiquer entre équipes et clients

Orienté SSII
6
Cas dutilisation
  • Description textuelle
  • nom, résumé, contexte, description, exceptions,
    acteurs, effets
  • on en extrait les objets, actions, états... de la
    modélisation
  • Diagramme des cas

Client
Traitement de commande
Facturation
Comptable
Réceptionniste
Gestion de compte client
Livreur
A chaque Use case correspond un diagramme
dobjets participants
7
Des cas dutilisation aux diagrammes de séquence
(1)
  • Un diagramme de séquence décrit un scénario
    dinteraction entre objets du système et acteurs
    externes
  • Un scénario peut être vu comme une des instances
    dun cas dutilisation
  • La description doit être suffisamment générale et
    exhaustive pour identifier tous les algorithmes

8
Des cas dutilisation aux diagrammes de séquence
(2)
  • Problème la combinatoire des interactions peut
    être immense.
  • décrire quelques scénarios dans les cas nominaux
  • décrire les scénarios aux limites
  • décrire les scénarios danomalie
  • Un analyste programmeur doit pouvoir coder en
    lisant des diagrammes de séquences

9
Le diagramme de séquence
Identifier les classes et méthodes d'interface
concernées
10
A éviter absolument
A un ensemble de diagrammes de séquence doit
correspondre un algorithme (simple)
11
Usage du diagramme de séquence
  • En tant que document danalyse sert à
    représenter de plus en plus précisément la
    dynamique du système
  • En tant que document de conception sert à figer
    les interactions entre les sous-parties du
    logiciel
  • En tant que document dimplémentation sert à
    décrire les algorithmes (la partie interaction)
  • Peut conduire à des re-découpages des vues
    statiques
  • Essentiel pour le passage de lanalyse à la
    conception

12
Automates
13
Le diagramme états-transitions
Source Statecharts (David Harel)
Etat final
Etat initial
Contrainte
Evénement
anniversaire age18ans
Mineur
Majeur
Permet de représenter sous forme dautomates les
objets dotés dune dynamique complexe
Très utile pour les applications
interactives Délicat à utiliser gt Ne pas en
abuser
14
Exemple réveil matin
  • 3 boutons alarme on/off, arrêt sonnerie,
    réglage alarme
  • Transition automatique à la fin de la sonnerie
  • Constat notation très compacte pour décrire
    toute la dynamique

alarme on(H alarme)
heure H alarme
Armé
do/sonner
Désarmé
alarme off
arrêt sonnerie
alarme off
15
Actions et activités
  • Envoi dévénement déclenchement dune
    transition.
  • Action opération instantanée déclenchée par une
    transition.
  • Activité opération durable, interruptible,
    associée à un état.
  • Action interne action qui nentraîne pas de
    transition
  • Transition automatique transition sans
    événement, déclenchée à la fin de lactivité.
  • Transition propre transition vers le même état
    (on en sort et on y retourne)

E3cond Y/action2
Etat do/activité action1
/action3
E1/action0
16
Action en entrée et en sortie
  • Action en entrée action exécutée à chaque
    entrée dans létat
  • Exemple redessiner le contenu de la fenêtre
    quand la souris y entre
  • Action en sortie action exécutée à chaque
    sortie de létat
  • Exemple mettre à jour un compteur de passage à
    la sortie
  • Intérêt de factoriser les actions de sortie dans
    le cas hiérarchique

Etat entry/a1 exit/a2
Etat
E1
E1/a1
E3
E3/a2
E2/a1
E2
E4
E4/a2
17
Ordonnancement
  • Entrée
  • action sur la transition d entrée (a0)
  • action dentrée (a1)
  • activité (activité)
  • Dans létat
  • interruption de lactivité (activité)
  • exécution de laction interne (a4)
  • reprise de lactivité
  • En sortie
  • arrêt de lactivité (activité)
  • action de sortie (a2)
  • action sur la transition de sortie (a3)
  • Transition propre
  • ordre de sortie (activité,a2), (a5), puis ordre
    dentrée (a1,activité)

18
Automates hiérarchiques
  • Les diagrammes détats à plat deviennent
    rapidement illisibles, il faut structurer
    hiérarchiquement.
  • Raffiner décomposer en sous-états
  • Synthétiser regrouper dans un même état

Etat père do/A
E2
E1
E1
E2
E3
do/A1
do/A2
19
Automates hiérarchiques
  • Un sous-état hérite de son sur-état des actions
    internes, des transitions de sortie, il nhérite
    pas des transitions en entrée ni des activités.

20
Hiérarchie et ordonnancement
  • Quand on entre dans létat englobant, on entre
    dans létat interne initial
  • On commence par entrer dans létat le plus
    englobant pour aller vers le plus interne
  • On commence par sortir de létat le plus interne
    pour sortir dun état englobant

21
Exercice
  • Indiquez les séquences dactions pour chaque
    événement reçu selon que lautomate est dans
    létat B ou C

E3/x3
Etat A entry/A_In E4/A_Interne exit/A_Out
E2/x2
E1/x1
E5
Etat B entry/ B_In exit/ B_Out
Etat C entry/ C_In exit/ C_Out
E6
22
Parallélisme et synchronisation
Etat composite
do/ A1
do/ A2
do/ A3
do/ A4
do/ A5
do/ A6
Activation de A1, A3 et A5 en même temps
Transition quand A2, A4 et A6 sont toutes finies
23
Dynamique de lélève
Eveillé
Endormi
Réveil sonne heureen retard
Pause !!!
En cours
duréegt10mn
Endormi
Eveillé
Prof crie
24
Diagramme dactivité
Chercher du café
Mettre un filtre
Remplir le réservoir deau
Prendre une tasse
Mettre du café
Allumer la cafetière
Le café passe
Servir
25
Démarche UML
26
Démarche densemble
  • Utiliser la redondance entre les vues
  • Travailler les différentes vues en parallèle
  • Vérifier la cohérence à chaque étape
  • Nombreux allers-retours
  • Faire valider régulièrement

Dynamique
27
Processus d'analyse
  • Le découpage en packages doit être fait tôt, mais
    nécessite des réaménagements
  • Diagramme des cas gt différents cas (et retours)
  • use case gt diagrammes des classes (et retours)
  • use case gt diagrammes de séquences/ajouts de
    classes
  • identifier les automates nécessaires
  • diagrammes de séquences gt automates (synthèse)

28
Processus de conception
  • Partir d'un modèle en analyse
  • partager le travail
  • détailler le contenu, les échanges
  • compléter les diagrammes de classes
  • compléter les diagrammes de séquence
  • identifier les doublons, les problèmes
  • modifier le partage (itérations)
  • Figer les interfaces
  • Classes et méthodes d'interface
  • Paramètres échangés, valeurs de retour
  • Passage à l'implémentation

29
Interaction classes-séquences
  • Les objets concrets représentés dans un scénario
    sont des acteurs ou des instances de classes
  • Construire le scénario peut faire apparaître de
    nouvelles classes
  • Cela fait surtout apparaître les méthodes et
    éventuellement les attributs
  • Attention, les classes abstraites napparaissent
    pas -gt ne pas se contenter des diagrammes de
    séquence !

30
Attention !
  • Les contraintes defficacité peuvent entraîner
    des modifications importantes entre analyse et
    conception
  • Quand cest le cas, il faut faire évoluer la
    documentation et consulter les partenaires
    concernés
  • Sefforcer de concevoir les interfaces de telle
    façon quelles ne soient pas concernées par les
    modifications
  • Sefforcer de faire les modifications de façon à
    ne pas toucher aux interfaces

31
Gestion de la documentation
  • Tout diagramme doit indiquer clairement ce quil
    représente
  • Rassembler les diagrammes représentant
    différentes instances dun même scénario
  • Assurer la traçabilité entre cas dutilisation,
    diagrammes de classe, diagrammes de séquence, et
    code produit
  • Recours intensif aux liens hypertextes

32
Organisation du projet
33
Travail à effectuer
  • Définir toutes les classes utiles (vu
    précédemment)
  • Identifier les traitements qui impliquent
    plusieurs classes
  • Faire des diagrammes de séquences pour mettre en
    évidence les interactions
  • Définir la signature des méthodes, ce quelles
    font
  • Identifier puis figer les interfaces en figeant
    les signatures
  • Cela définit le contrat engageant chaque équipe

34
Etape 3 (formalisation)
  • Pour chaque entité identifiée lors de lanalyse,
    finaliser la conception de linterface avec les
    équipes environnantes
  • Réaliser les diagrammes de séquences, nommer les
    méthodes, les paramètres, les valeurs de retour
  • Objectif séance 3 chaque équipe devient capable
    de travailler de façon autonome

35
Etape 4
  • Pour chaque entité identifiée lors de lanalyse,
    conduire la conception détaillée en interne
  • Réaliser les diagrammes de classes, de séquences
    et éventuels automates détaillés
  • Penser la généricité, la réutilisabilité
  • Objectif séance 4 chaque équipe sait de façon
    détaillée comment elle va faire

36
Etape 5
  • Pour chaque entité identifiée lors de lanalyse,
    validation définitive des interfaces avec les
    autres équipes
  • Recherche des incohérences, redondances,
    conflits
  • Objectif séance 5 validation globale de la
    conception tout le monde peut se mettre à coder
Write a Comment
User Comments (0)
About PowerShow.com