chaque use-case génère un ou des scénarios, traduits par des diagrammes objets, qui permettent...
TRANSCRIPT
Chaque use-case génère un ou des scénarios, traduits par des diagrammes objets, qui permettent d’introduire et/ou de compléter les diagrammes des catégories et de classes.
Etudiant
Système de facturation
Inscription à un cours
Gestion des cours
Administratif
Sélection d'un cours à donnerProfesseur
Mr. Baran : Administratif
Fiche : FicheNouveauCours
Vente 101 : Cours
1: setNom
2: setDescription
3: SetHeureJour
4: setLocalisation
5: setProfesseur
6: soumettre ( )
7: creer (typeCours)
8: sauver ( )
9: CoursCree
ListeClients
recherche()ajout()
Formation
getDatesSession()inscriptionListeAttente()
Inscription
inscriptionSession()
ListeAttenteListeFormations
getListeFormations()selectionne()
Session
getDates()estComplete()
Quand tout est suffisamment spécifié, on peut passer au
Designconcerne le domaine de la
solutionon s’occupe des aspects liés à l’implémentation :• définition correcte des hiérarchies
de classes,• ajout de packages logiques et de
classes réutilisées,• ajout de classes permettant une
implémentation correcte de certaines notions (collections, persistance, etc.)
On factorise ou on réutilise...
On choisit un ou des langages d’implémentation et on introduit des packages de « bas niveau ».
Attention : Respecter Faible Couplage entre les classes métier et les classes d’interface utilisateur
Les classes métier, telles que les classes Formation, Session, etc., ne doivent pas directement dépendre de la nature des classes d’interface utilisateur.Il est, par exemple, hors de question d’y trouver des méthodes d’affichage dépendant d’une ou l’autre technologie.
Ceci enfreindrait le pattern Faible Couplage puisqu’il faudrait toujours ajouter les classes d’interface utilisateur pour pouvoir utiliser les classes métier, ce qui est un non sens.
Le respect de ce pattern est directement visible dans le diagramme de packages à travers le sens des dépendances.
Attention : respecter « Faible Couplage » entre les classes métier et les classes d ’interface utilisateur
La logique d’affichage dépendra donc des classes d’interface utilisateur (présentation des données) et pas des classes métiers.Celles-ci seront “interrogées” pour effectuer l’affichage des informations utiles à un moment de l’application.
Dans la foulée, on renforce ainsi le pattern Forte Cohésion !
On introduit des packages de classes de « bas niveau » :
par exemple
On reflète la présence des nouvelles classes dans les diagrammes de séquences...
: ListeFormations
: Administrati f : FicheInscriptionSession
: Formation : Session : Inscription : ListeClients : ODBCStatement
1. enclenche1.1. getListeFormations( )
1.2. afficheFormations( )
2. selectionneFormation2.1. selectionne( )
2.1.2.
2.2. getDatesSession( )2.2.1. getDates( )
2.3. afficheDatesSession( )
3. encodageClient
4. encodageCoordonnées
5. validation
5.2. inscriptionSession( )
3.1. recherche( )
6. inscrireListeAttente6.1. inscriptionListeAttente( )
Si on n'a pas trouvé le client dans notre l iste.On en profite pour l'ajouter
4.1. ajout( )
Si la sesion est complète
5.1. estComplete( )
2.2.1.1.
2.1.1.
3.1.1.
4.1.1.
5.1.1.
5.2.1.
6.1.1.
On reflète la présence des nouvelles classes dans les diagrammes de classes et de packages...
ODBCBase(from odbcclasses)
ListeFormations
InterfaceUtilisateurs
ModèleBusiness
Window Support(from Application Architecture)odbcClasses
On reflète la présence des nouvelles classes dans les diagrammes de classes et de packages... Mais…Un œil averti remarquera immédiatement que nous avons ainsi porté atteinte à Forte Cohésion, puisqu’il faudra maintenant ajouter à nos classes métier la capacité de gérer le sauvetage vers une base de données. Ceci entraînera l’ajout de méthodes avec du code SQL dans les classes métiers.
Une autre solution consisterait à créer une classe ou un groupe de classes encapsulant les requêtes SQL et tous les traitements associés (gestion des verrous, des transactions, des exceptions et erreurs, etc…).Ceci renforcerait la cohésion de nos classes métiers, dont on exclurait les aspects de “ plomberie ” SQL, pour se concentrer sur leur rôle fondamental.Cette solution permet aussi de concentrer les problèmes liées aux bases de données dans quelques classes qui peuvent ainsi être maintenues par des spécialistes.
Il faut toujours considérer le rapport BENEFICE / EFFORT ...
On s’attache ensuite à l’aspect physique de l’application en commençant par les diagrammes des composants
Interfaces
ODBC
ClassesBusiness
MFC
Cours
Listes
Personnes
Cours
Listes
Personnes
11
On s’attache ensuite à l’aspect physique de l’application en commençant par les diagrammes des composants
ODBC<<DLL>>
ODBCClasses.h
ODBCClasses.cpp ODBC32.lib
librairie importation
12
On complète la vue physique par le diagramme de déploiement ...
<<Station de travail>><<Lecteur BarCode>>
<<Serveur BD>>
superPrinter
13
Modélisons les données permanentes
Avec UML !!!
Table -> Classe Tuple -> Instances Attributs -> Attributs
Nous allons réaliser un simple modèle des données, sans passer par un modèle « conceptuel », objet ou autre.
14
Modélisons les données permanentes
SESSION
LIEU : SMALLINTDATE1 : DATEDATE2 : DATEDATE3 : DATEDATE4 : DATEDATE5 : DATE
FORMATION<<Table>>
LIBELLE : VARCHAR(0)DESCRIPTION : VARCHAR(0)DUREE : SMALLINTMAXINSCRITS : SMALLINT
FORMATEURS<<Table>>
NOM : CHAR(30)ADRESSE : VARCHAR(50)DATE_NAISSANCE : DATETELEPHONE : VARCHAREMAIL : VARCHARDIPLOMES : VARCHAR
CLIENT<<Table>>
DATE_NAISSANCE : DATEADRESSE : VARCHAR(50)TELEPHONE : VARCHAREMAIL : SMALLINTNOM : CHAR(30)
INSCRIPTION
PAIEMENT : SMALLINT
0..*
0..1
0..*
0..1
15
Interaction entre les use-cases (=processus) et les données permanentes
Achat d'une place d'une place viale Web
T_Reservation(from S_0)
T_Salle(from S_0)
<<lecture>>
<<écriture>><<écriture>>
16
Prototypage et « Round trip Engineering »
Modélisation
Génération
Analyse du code
17
Les architectures logicielles « multi-niveaux » (et leurs patterns)
Logique del'application
Business Rules
Stockages desdonnées
Présentation,interface
utilisateur
MVC, Document/View, EventListener, Contrôleur...
Interface utilisateur
Interface utilisateur
Contrôleur
Objet métierObjet
métierObjet métier
Autre façon de voir ...
18
Modélisons le logiciel de contrôle d’un système de lecture de bar-codes par une Machines à Etats Finis (FSM)
LecteurCode
APIBarCode(from PiloteBarCode)
19
Qu ’est-ce qu ’une machine à états finis ?
etat1
etat2
#init
#evt1
#fin
#evt2
#evt3
États + événements + transitions (+…)
Outil de spécification formelle.
20
Notre machine « Pilotage du Lecteur de BarCode »
Il s 'agit de modéliser la classe qui pilote le lecteur de bar code et non le lecteur lui-même.
enLecture
entry/ checkCodeentry/ ^#codeOK ou #codeErrone
ErreurCode
carteErronee
entry/ Log("carte erronée")
pret
#init
#codeBarLu( valeur )
Pas encore de détails. On met dans le logFile si + de n erreurs avec même code
setPresence
entry/ ajoutPresence
#codeBarLu( valeur )
#codeBarLu( valeur )
#desactive
#codeErrone
#desactive
#codeOK
21
APPROCHE GENERALE DE LA METHODE
• Vues et modèles multiples
sémantique dynamique
sémantique statique
vue logique struct. des classes struct des objets vue physique arch. des modules arch. des process
22
• Diagramme des classes
NotreClasse
varMembre : SaClasse
setValue (val : String = "") : void
MaClasseAbstraite SaClasse
attribut1 : String = "Hello"
Boundary Business Actor
Business Entity
Business Worker ControlEntity
On affiche ce que l ’on veut
Différents stéréotypes...
23
• Diagramme des classes
Classe4
Classe2
Classe3
1
0..1
Classe5
Classe1
Spécialisation /généralisation
dépend de
1
0..1
membre
1
1..*1..*
1membre
24
La relation d’agrégation par valeur indique que la durée de vie de l’objet contenu est conditionnée par la durée de vie du contenant.Ce type de contenance sera généralement implémenté via une variable qui sera une instance de la classe contenue.
Toutefois, il est possible de rencontrer une autre approche.Une relation “ aggregate by value ” peut se traduire par ‘une référence à’ aussi bien que par ‘un pointeur vers’ l’instance contenue. Ceci implique une restriction dans la façon de gérer la variable contenue : elle doit être détruite, et probablement construite, avec la variable la contenant.Cette approche relève plutôt d’une discipline de programmation.
De l’agrégation...
25
Association entre classes
Classes association ou associatives
• Association ternaire
PersonneEntreprise
0..*1
Employeur Employé
1 0..*
< travaille pour
Utilisateur Workstation
0..*0..*
HomeDirectoryAutorisé
privilèges
0..* 0..*
Etudiant Enseignant
Salle
Cours
débutfin
<<Association ternaire>>
26
Associations avec contraintes
Associations avec qualificateur
PersonneClasse{sous-ensemble}
Parent d'élève
Délégués
Directory
Nom : String
Fichier
FileName : StringFileType
FileNameFileName
27
Machines à Etats Finis et Diagrammes d’états
e t a t D e p a r t
e t a t F i n a l
e t a t 1
e t a t 2
# e v e n e m e n t
28
• Diagrammes d’états : un lecteur de carte
actif
entry: lireCarteexit: ejecterCarte
enMaintenance
traitement
validation
sélectiontraitement
impression
#finMaintenance
validation
sélectiontraitement
impression
#maintenance
#carteDetectee
#cancel
#finOperations
#encore
29
Lecture Nom
entry: enEntrantexit: enSortantdo: activité
on évenement:
Lecture mot de passe
entry: Invite mot de passe
#nomLu / afficherOK
#état1 / opération
Diagrammes d ’états : les actions et les activités
30
La communication entre FSM
ACTIF#init
INACTIF
#vehiculeDetecte ̂Controleur.#detection#timeOut
Vert_Rouge#init
Orange_Rouge
#detection
Rouge_Vert
#timeOut
Rouge_Orange
#timeOut
#timeOut
31
Forme complète d ’une transition
état1
état2
#evenement( arg )[ arg>=0 ] / fermePorte ^Supervision.#porteFermée
32
Diagrammes d’états : un état se souvient ...
commande
backUp
collecteInfo
copie
nettoyage
H collecteInfo
copie
nettoyage
H
#interrogation
On spécifie que l’état doit avoir une mémoire (historique)