La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Chaque use-case génère un ou des scénarios, traduits par des diagrammes objets, qui permettent dintroduire et/ou de compléter les diagrammes des catégories.

Présentations similaires


Présentation au sujet: "Chaque use-case génère un ou des scénarios, traduits par des diagrammes objets, qui permettent dintroduire 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 dintroduire et/ou de compléter les diagrammes des catégories et de classes.

2 Quand tout est suffisamment spécifié, on peut passer auDesign concerne le domaine de la solution on soccupe des aspects liés à limplé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 dimplémentation et on introduit des packages de « bas niveau ».

4 Attention : Respecter Faible Couplage entre les classes métier et les classes dinterface utilisateur Les classes métier, telles que les classes Formation, Session, etc., ne doivent pas directement dépendre de la nature des classes dinterface utilisateur. Il est, par exemple, hors de question dy trouver des méthodes daffichage dépendant dune ou lautre technologie. Ceci enfreindrait le pattern Faible Couplage puisquil faudrait toujours ajouter les classes dinterface 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 daffichage dépendra donc des classes dinterface utilisateur (présentation des données) et pas des classes métiers. Celles-ci seront interrogées pour effectuer laffichage des informations utiles à un moment de lapplication. 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, puisquil faudra maintenant ajouter à nos classes métier la capacité de gérer le sauvetage vers une base de données. Ceci entraînera lajout 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 sattache ensuite à laspect physique de lapplication en commençant par les diagrammes des composants

11 11 On sattache ensuite à laspect physique de lapplication en commençant par les diagrammes des composants

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

13 13 Modélisons les données permanentes Avec UML !!! Table -> ClasseTuple -> 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 14 Modélisons les données permanentes

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

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

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

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

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

20 20 Notre machine « Pilotage du Lecteur de BarCode »

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

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

23 23 Diagramme des classes

24 24 La relation dagrégation par valeur indique que la durée de vie de lobjet 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 linstance 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 dune discipline de programmation. De lagrégation...

25 25 Association entre classes Classes association ou associatives Association ternaire

26 26 Associations avec contraintes Associations avec qualificateur

27 27 Machines à Etats Finis et Diagrammes détats

28 28 Diagrammes détats : un lecteur de carte

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

30 30 La communication entre FSM

31 31 Forme complète d une transition

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


Télécharger ppt "Chaque use-case génère un ou des scénarios, traduits par des diagrammes objets, qui permettent dintroduire et/ou de compléter les diagrammes des catégories."

Présentations similaires


Annonces Google