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.

Présentation au sujet: "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."— Transcription de la présentation:

1 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.

2 Design Quand tout est suffisamment spécifié, on peut passer au
concerne le domaine de la solution on 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...

3 On choisit un ou des langages d’implémentation et on introduit des packages de « bas niveau ».

4 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.

5 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  !

6 On introduit des packages de classes de « bas niveau » :
par exemple

7 On reflète la présence des nouvelles classes dans les diagrammes de séquences...

8 On reflète la présence des nouvelles classes dans les diagrammes de classes et de packages...

9 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 ...

10 On s’attache ensuite à l’aspect physique de l’application en commençant par les diagrammes des composants

11 On s’attache ensuite à l’aspect physique de l’application en commençant par les diagrammes des composants

12 On complète la vue physique par le diagramme de déploiement ...

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

15 Interaction entre les use-cases (=processus) et les données permanentes

16 Prototypage et « Round trip Engineering »
Modélisation Génération Analyse du code

17 Les architectures logicielles « multi-niveaux » (et leurs patterns)
MVC, Document/View, EventListener, Contrôleur... Autre façon de voir ... Interface utilisateur Contrôleur Objet métier

18 Modélisons le logiciel de contrôle d’un système de lecture de bar-codes par une Machines à Etats Finis (FSM)

19 États + événements + transitions (+…) Outil de spécification formelle.
Qu ’est-ce qu ’une machine à états finis ? États + événements + transitions (+…) Outil de spécification formelle.

20 Notre machine « Pilotage du Lecteur de BarCode »

21 APPROCHE GENERALE DE LA METHODE
Vues et modèles multiples

22 On affiche ce que l ’on veut
Diagramme des classes On affiche ce que l ’on veut Différents stéréotypes...

23 Diagramme des classes

24 De l’agrégation... 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.

25 Association entre classes
Classes association ou associatives Association ternaire

26 Associations avec contraintes
Associations avec qualificateur

27 Machines à Etats Finis et Diagrammes d’états

28 Diagrammes d’états : un lecteur de carte

29 Diagrammes d ’états : les actions et les activités

30 La communication entre FSM

31 Forme complète d ’une transition

32 On spécifie que l’état doit avoir une mémoire (historique)
Diagrammes d’états : un état se souvient ... On spécifie que l’état doit avoir une mémoire (historique)