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)