La conception du logiciel avec UML

Présentation au sujet: "La conception du logiciel avec UML"— Transcription de la présentation:

1 La conception du logiciel avec UML

2 Les applications informatiques
Les applications informatiques sont de trois sortes: Les applications à usage personnel Les application d’entreprise Les progiciels Pour une application personnelle - Vous définissez les fonctionnalités attendues - Vous connaissez le matériel et le système d’exploitation sur lesquels va tourner l’application - Vous décidez des technologies à utiliser (langage, stockage de données) - Vous organiser votre travail comme vous le désirez - Vous n’avez pas de réelles contraintes de temps ni de budget

3 Application à usage personnel
On définit seul les fonctionnalités attendues On connaît le matériel et l’OS On décide des technologies à utiliser On organise son travail à sa guise On n’a pas de contrainte de temps Le budget nécessaire est peu important La qualité est peu importante Pour une application personnelle - Vous définissez les fonctionnalités attendues - Vous connaissez le matériel et le système d’exploitation sur lesquels va tourner l’application - Vous décidez des technologies à utiliser (langage, stockage de données) - Vous organiser votre travail comme vous le désirez Vous n’avez pas de réelles contraintes de temps ni de budget La qualité est peu importante

4 Application d’entreprise
Malgré les progrès du génie logiciel, la réussite des projets informatiques reste faible. Des études récentes montrent des dépassements de budget et d’échéance encore importants. Et ces dérives affectent la majorité des projets. Pour une application personnelle - Vous définissez les fonctionnalités attendues - Vous connaissez le matériel et le système d’exploitation sur lesquels va tourner l’application - Vous décidez des technologies à utiliser (langage, stockage de données) - Vous organiser votre travail comme vous le désirez Vous n’avez pas de réelles contraintes de temps ni de budget La qualité est peu importante

5 Les chiffres 53% des projets coûtent au moins 200% des estimations initiales. 81 billion de dollars ont été dépensé en 1995 au U.S.A. sur des projets arrêtés avant la fin. Source: Rapport Standish, 1995

6 Les chiffres Selon un rapport de la British Computer Society en 2002:
16% seulement des projets aboutissent. 59% sont en dépassement budgétaire. 35% sont en dépassement de délais. 54% des fonctionnalités attendues sont manquantes.

7 Les chiffres (suite) Budget dépassé Partiellement réussi
Budget conforme Succès complet Abandonné Budget inférieur Fonctionnalités manquantes Dans les délais Hors délai Fonctionnalités conformes Fonctionnalités supplémentaires Sous les délais

8 Les causes d’échec Les principales causes d’échec sont dues à la mauvaise compréhension des besoins du client. Qu ’elles soient exprimées – les exigences fonctionnelles exprimées par le client. Ou existantes - les contraintes induites par l’environnement du projet. Ce dysfonctionnement est dû à la représentation mentale souvent erronée que l’on d’un besoin.

9 Les besoins On confond souvent un besoin et une demande.
Les utilisateurs expriment une demande mais elle correspond rarement à leurs besoins. On pense connaître parfaitement ses besoins mais ça ne signifie pas que l’on sache: Les exprimer clairement Comment il sera possible de les satisfaire et vous pensez légitimement connaître parfaitement vos besoins. Cela ne signifie pas, cependant que vous sachiez les exprimer clairement, et encore moins comment il sera possible de les satisfaire

10 Comprendre les besoins
Un logiciel doit remplir des fonctions bien précises. Il doit en plus s’intégrer à l’environnement informatique. On doit donc recenser l’ensemble des exigences et des contraintes du système: Qu ’elles soient exprimées Ou existantes d’ordre techniques et organisationnelles

11 Les exigences et les contraintes
Les contraintes permettent de voir le projet à travers les aspects fonctionnels techniques organisationnels Environnementaux Expliquez OMT, OOD, OOSE

12 Les exigences fonctionnelles
Pour construire le bon système, on doit recenser l’ensemble des fonctionnalités attendues. Or, la capture des besoins fonctionnels n’est pas facile. parce que l’utilisateur est incapable de les exprimer parce qu’il ne juge pas nécessaire de les préciser Ou parce qu’il n’en a pas conscience Expliquez OMT, OOD, OOSE

13 Les contraintes techniques
Les aspects techniques concernent  les aptitudes du système L’ergonomie et la documentation La performance La fiabilité ou la tolérance aux pannes L’adaptabilité l‘existant La plateforme système Les existants applicatifs à intégrer Les référentiels et annuaires Expliquez OMT, OOD, OOSE

14 Les contraintes organisationnelles
Les aspects organisationnels concernent:  La culture de développement orientée objet Procédurale Le processus utilisé Les usages de production documentaire Expliquez OMT, OOD, OOSE

15 Les contraintes environnementales
Les aspects environnementaux concernent: Les problèmes d’environnement physique Chaleur Vibration Etc … Expliquez OMT, OOD, OOSE

16 La qualité Gérer ces contraintes revient à définir le niveau de qualité d’un logiciel ! Les informaticiens ont toujours été confrontés à ces problèmes de qualité ! Mais qu’est-ce que la qualité logicielle ? « ISO 8402: Ensemble des caractéristiques d’une entité qui lui confèrent l’aptitude à satisfaire des besoins exprimés et implicites »

17 Les critères de qualité
Les caractéristiques d’un logiciel permettant de mesurer sa qualité sont principalement: La lisibilité du code La facilité de maintenance La réutilisabilité La portabilité L’adaptabilité La performance La tolérance aux pannes La sécurité la facilité avec laquelle un programme peut évoluer l’aptitude d’un programme à répondre aux résultats attendus la possibilité de réutiliser certaines parties d’un logiciel la capacité d’un logiciel à s’exécuter sur différentes plateformes l’aptitude d’un logiciel à bien réagir en cas de problèmes

18 Alors de quoi a-t-on besoin ?
La construction d’un logiciel est complexe parce qu’elle met en œuvre de nombreuses ressources. Humaine Matérielles Technologiques D’où la nécessité d’utiliser un processus bien défini un langage de modélisation éprouvé des techniques de modélisation rigoureuses pour prendre en charge les critères de qualité pour modéliser un système et le communiquer pour organiser les activités de développement

19 La méthodologie Une méthodologie peut être définie par la mise en œuvre des trois outils suivants: Une notation visuelle pour modéliser un système et le communiquer Un processus pour organiser les activités de développement Des techniques d’analyse et de conception pour prendre en charge les critères de qualité pour prendre en charge les critères de qualité pour modéliser un système et le communiquer pour organiser les activités de développement

20 Représentation d’une méthodologie
Notation Ces trois outils sont liés et interagissent fortement entre eux Processus Techniques

21 La modélisation avec UML

22 La modélisation est une technique d’ingénierie
Qu’est-ce que la modélisation ? La modélisation est une technique d’ingénierie qui permet de comprendre un système par l’établissement de modèles pour mettre au point une solution à un problème. Un modèle météorologique qui permet de prévoir les conditions climatiques Un modèle économique qui permet de simuler l’évolution de cours boursiers par exemple Un modèle démographique qui définit la composition et le comportement d’un groupe d’individus dans le but d’études statistiques Définir plus précisémment un modèle

23 Pourquoi modéliser ? La modélisation nous aident à représenter un système en précisant sa structure. en définissant ce qu’il fait; son comportement. en déterminant comment il le fait. en fournissant un canevas qui guide sa construction. en le documentant. Expliquez OMT, OOD, OOSE

24 Comment modéliser ? UML propose un moyen pour représenter diverses projections d’un système: les vues. Elles sont généralement constituées d’un ou plusieurs diagrammes UML : Qui sont des représentations graphiques qui s’intéressent à un aspect précis du modèle. Dont chaque type est composé d’éléments de modélisation prédéfinis. Dont la combinaison offre une vue complète des aspects fonctionnels, statiques et dynamiques d’un système. Expliquez OMT, OOD, OOSE

25 Les types de diagramme La version 1.4 d’UML représente un système, en se basant sur 9 diagrammes. Quatre pour la structure statique Diagramme d’objets Diagramme de classes Diagramme de composant Diagramme de déploiement Cinq pour le comportement dynamique Diagramme de cas d’utilisation Diagramme de séquences Diagramme d’activité Diagramme de collaboration Diagramme d’états transitions qui se répartissent en deux catégories

26 Les axes de la modélisation
Les concepteurs orientent leurs modélisations selon trois axes sur lesquels ils répartissent les diagrammes : L’axe fonctionnel qui est utilisé pour décrire le ce que fait le système à réaliser, L’axe structurel et statique qui est relatif à sa structure, L’axe dynamique qui est relatif à la construction de ses fonctionnalités. Expliquez OMT, OOD, OOSE

27 Les 3 axes de la modélisation
Fonctionnel Diagramme de Use Cases (Diagramme d’activités) (Diagramme de séquences) Expliquez OMT, OOD, OOSE Statique Dynamique Diagramme de classes Diagramme de composants Diagramme de déploiement Diagramme d’objets Diagramme d’activités (Diagramme d’états/transitions) (Diagramme de séquences) Diagramme de collaboration

28 Élaboration de la modélisation
UML est une avancée importante pour le génie logiciel mais ce n’est ni une méthode, ni un processus. Si UML permet de modéliser un système, il ne définit pas le processus d’élaboration des modèles. Dans quel ordre doit-on utiliser les neufs types de diagrammes ? A quel moment de la conception d’un système doivent-ils intervenir ? Seul un processus de développement peut répondre à ces questions ! Expliquez OMT, OOD, OOSE

29 Les processus de développement

30 Les points de vue d’un processus
Le processus de développement régit les activités de production du logiciel selon deux aspects. L’aspect statique qui représente le processus en terme de tâches à réaliser. L’aspect dynamique qui représente la dimension temporelle du processus. selon un cycle de vie et se décline avec leurs responsabilités comme le modèle

31 Aspect statique d’un processus
L’aspect statique définit: Le « qui ». Les intervenants Le « comment ». Les activités à réaliser Le « quoi ». Les résultats d’une activité selon un cycle de vie et se décline avec leurs responsabilités comme le modèle

32 Aspect dynamique d’un processus
L’aspect dynamique représente : Le nom et le nombre de phases du cycle de vie du processus L’organisation et l’ordre de réalisation des activités de développement selon un cycle de vie et se décline avec leurs responsabilités comme le modèle

33 Les étapes d’un processus
Un processus gère généralement les activités suivantes: L’expression des besoins La spécification des besoins L’analyse des besoins La conception L’implémentation Les tests fonctionnels et techniques La maintenance

34 L’expression des besoins
L’expression des besoins consiste pour le client à élaborer un cahier des charges décrivant: Les fonctionnalités du système à étudié La façon d’utiliser le système

35 La spécification des besoins
La spécification des besoins permet aux utilisateurs, experts, et aux informaticiens de finaliser le cahier des charges en levant les ambiguïtés en éliminant les redondances

36 L’analyse des besoins L’analyse des besoins ou « le quoi » vise à faire définir, par les experts, et les utilisateurs Les entités métier concernées par le système indépendamment de toutes considérations: techniques et informatiques

37 La conception La conception ou « le comment » concerne les experts informatiques. On y détermine la manière de résoudre techniquement le problème posé. Comment réaliser les fonctionnalités attendues.

38 L’implémentation L’implémentation consiste
A construire les programmes dans un langage de programmation donné. A organiser logiquement les programmes en fonction de l’architecture logique choisie. A distribuer les programmes sur le système informatique selon l’architecture physique retenue.

39 Les tests sont de deux sortes.
La maintenance et les tests Les tests sont de deux sortes. Fonctionnels. Ils vérifient que le système implémente bien les fonctionnalités attendues. Techniques. Ils vérifient que l’implémentation des fonctionnalités est techniquement correcte. La maintenance traite les évolutions et/ou les corrections à apporter au système.

40 Processus de fabrication
Produit + Rév A - Rév B + Pièce 1 - Sous-ens 1 Pièce 2 Pièce 3 Caractéristiques fab. Pt soudure 1 Pt soudure 2 Process + Rév A - Rév B Opération 10 Opération 20 Phase 1 Phase 2 Usine (Ligne) + Rév A - Rév B + Ilôt 1 - Ilôt 2 Poste 1 Poste 2 Doc Plan Ressources + Robots - Pinces Pince X Pince Y + Montages Catalogue de Moyens

41 Les types de processus On classe les processus selon deux types:
prédictif ou adaptatif

42 Processus de type prédictif
Les processus de type prédictif ne prévoient que sur le long terme, ils imposent: De finaliser et de figer les spécifications et leurs priorités en amont de la construction de figer un plan exact de livraison sans tenir compte de la vélocité réelle des équipes ils sont souvent erroné car entachés de trop d’incertitudes en dépit d’une identification incomplète des besoins

43 Le cycle de vie en cascade
Linéaire et séquentiel, il a pour caractéristique: de clarifier les fonctionnalités avant la conception de modéliser les entités métier avant la conception de définir complètement la conception Et pour défauts: de vouloir définir toutes les exigences dés le début d’accorder trop d’attention à la documentation de retarder la résolution des facteurs de risque d’entraîner un démarrage tardif du codage avant de la transmettre aux développeurs au détriment de la réalisation du logiciel D’entraîner des relations conflictuelles avec les parties prenantes

44 Expression des besoins
Le cycle de vie en cascade Expression des besoins Spécification Analyse Validation Conception préliminaire Tests D’intégration Expliquez OMT, OOD, OOSE Conception détaillée Tests unitaires Implémentation

45 Processus de type adaptatif
Les processus de type adaptatif permettent D’affiner les spécifications étape par étape D’ajuster le délai de livraison Ceci grâce à l’utilisation d’une démarche Itérative et incrémentale Guidée par les besoins des utilisateurs Centrée sur l’architecture Pilotée par les risques 2 en fonction de la vélocité réelle de l’équipe de développement 1 étape par étape 2 tout au long du développement 3 Les hiérarchisant selon leur criticité afin de les prendre en compte au plus tôt qui détermine en grande partie les qualités du logiciel

46 Cycle de vie d’un processus adaptatif
Analyse Conception Spécifications Implémentation Expliquez OMT, OOD, OOSE Expression des besoins Test Validation Déploiement

47 UP le processus unifié UP est un processus de type adaptatif, il est
Itératif et incrémental Guidé par les besoins des utilisateurs Centré sur l’architecture Piloté par les risques On le représente selon l’axe statique et dynamique des processus de développement. Expliquez OMT, OOD, OOSE

48 Représentation du processus UP

49 Expression des besoins
Disciplines et artefacts Disciplines Artefacts Expression des besoins Vision du projet Spécifications Modèle des cas d’utilisation Spécifications supplémentaires Glossaire Analyse Modèle du domaine Conception Modèle de conception Architecture logicielle Modèle de données Mise en oeuvre Modèle d’implémentation Tests Modèle de tests Gestion de projets Plan de développement Environnement Cas de développement Expliquez OMT, OOD, OOSE

50 UP est itératif et incrémental
Le développement d’un logiciel nécessite qu’on le découpe en plusieurs petits projets. Chaque projet représente une itération qui donne lieu à un incrément. Une itération désigne la succession des activités de développement un incrément correspond aux stades de développement du produit Expliquez OMT, OOD, OOSE

51 d = début a = affinement 1 itération = 1 cas d’utilisation
Réalisation des artefacts Artefacts Init. Elab. Const. Trans. Vision du projet d a Modèle des cas d’utilisation Spécifications supplémentaires Glossaire Modèle d’architecture Modèle du domaine Modèle de conception Modèle de données Modèle d’implémentation Modèle de tests Expliquez OMT, OOD, OOSE d = début a = affinement itération = 1 cas d’utilisation

52 Avantages d’un processus itératif
L’utilisation d’un processus itératif présente de nombreux avantages car il permet: De limiter les coûts De limiter les retards de mise en exploitation D’accélérer le rythme de développement grâce à des objectifs clairs et à court terme De tenir compte des besoins des utilisateurs en les dégageant des itérations successives Expliquez OMT, OOD, OOSE

53 UP est guidé par les uses case
Pour servir les attentes des utilisateurs, On centre le processus de développement sur leurs besoins. On fait apparaître ces besoins à l’aide de la technique des cas d’utilisation qui en: en capturant les besoins fonctionnels d’un système en orientant le travail de chaque itération vont guider le processus à travers l’utilisation des différents modèles UML qui représentent le système. Expliquez OMT, OOD, OOSE

54 Modèle d’implémentation Modèle d’architecture Diagramme des Uses Case
UP et les Uses Case Cahier des charges Analysés par Modèle du domaine Conçus par Modèle de conception Réalisés par Modèle d’implémentation Modèle d’architecture Structurés par Expliquez OMT, OOD, OOSE Testés par Modèle de tests Diagramme des Uses Case Déployés par Modèle de déploiement

55 UP est centré sur l’architecture
l’architecture doit prévoir la réalisation de tous les uses case et doit évoluer avec eux. Elle le fait en tenant compte de facteurs tels que: La plateforme d’exécution Matériel, système, BD, réseau,etc. Les composants réutilisables Librairies, caisse à outils, composants du commerce, etc. Les considérations de déploiement et les besoins non fonctionnels La performance, la fiabilité, la robustesse, etc. elle doit donc être mis en place dés le départ

56 UP est piloté par les risques
Un risque est un événement redouté dont l’occurrence est plus ou moins prévisible. Le pilotage par les risques c’est: Analyser les risques potentiels au plus tôt Hiérarchiser les risques Associer un ensemble de uses case à chaque risque Déclencher les itérations selon la criticité des uses cases qu’elles regroupent UP propose une gestion des risques. Ce qui constitue une avancée significative. Expliquez OMT, OOD, OOSE

57 Il existe donc des adaptations d’UP dont les plus connues sont:
Les adaptations de UP UP est un processus générique de développement. Il doit être adaptée au contexte du projet, de l’équipe et de l’organisation concernée. Il existe donc des adaptations d’UP dont les plus connues sont: Le Rational Unified Process (RUP) L’eXtreme Programming (XP) Le Two Tracks Unified Process (2TUP) Expliquez OMT, OOD, OOSE

58 Schéma d’application des processus
Ces trois processus mettent chacun l’accent sur un ensemble d’activités. Expliquez OMT, OOD, OOSE

59 La modélisation du système
La connaissance d’un langage de modélisation comme UML La mise en œuvre d’un processus de développement adaptatif comme UP Ne disent pas ce que doit faire le système ni comment le modéliser ! Nous avons besoin de techniques pour le spécifier, l’analyser et le concevoir. c'est-à-dire de comprendre les objectifs du système avec ses règles et ses contraintes

60 Techniques de spécification des besoins

61 Modèle d’implémentation Modèle d’architecture
La spécification des besoins Cahier des charges Analysés par Modèle du domaine Conçus par Modèle de conception Réalisés par Modèle d’implémentation Structurés par Modèle d’architecture Expliquez OMT, OOD, OOSE Testés par Modèle de tests Diagramme des UCs Déployés par Modèle de déploiement

62 Les cas d’utilisation Les cas d’utilisation sont une collection de scénarios de réussite et/ou d’échec. Ils décrivent la façon dont un acteur utilise un système pour atteindre un but. Ils sont de type boîte noire et décrivent un système en terme de comportement. Ce qu’il fera et non comment il le fera! Expliquez OMT, OOD, OOSE

63 Les scénarios Un scénario est un chemin particulier pris lors de l’exécution d’un use case. Nominal - c’est le scénario typique de succès. Alternatif – il correspond aux traitements alternatifs possibles. D’échec – il recensent les échecs dans le déroulement d’une étape de scénario. Expliquez OMT, OOD, OOSE

64 Identification des uses cases
Comment identifier les uses cases ? Les Processus Métier Élémentaires servent à atteindre le but d’un utilisateur du système. Ils sont de niveau Objectif utilisateur et sont analogues aux cas d’utilisation d’un système. Recenser les PME, permet de découvrir l’ensemble des cas d’utilisation d’un système. Expliquez OMT, OOD, OOSE

65 Les processus métier élémentaires
Un PME est une tâche effectuée par une personne : en un lieu et un temps donné en réponse à un événement et qui ajoute une valeur mesurable Expliquez OMT, OOD, OOSE

66 Description des uses case
Seule la forme textuelle permet de décrire les cas d’utilisation. Mais UML n’en propose aucune. Selon le niveau de précision, la rédaction d’un cas d’utilisation peut prendre deux formes: Résumée détaillée Quelle que soit la forme utilisée, on doit toujours se concentrer sur les intentions de l’utilisateur les responsabilités du système Expliquez OMT, OOD, OOSE

67 Le format résumé Le format résumé décrit brièvement, le comportement du cas d’utilisation. Il ne mentionne que l’activité et les échecs les plus significatifs. On les élabore en étendant la liste des objectifs par acteur. Expliquez OMT, OOD, OOSE

68 Contenu du format détaillé
Dans sa version étoffée, il contient jusqu’à 13 sections: Titre Description Acteurs Portée Niveau Parties prenantes et intérêts Pré conditions et déclencheurs Scénario nominal Scénarios alternatifs Scénarios d’erreur Post conditions (garantie de succès et d’échec) Variantes de données et de technologies Questions en suspens Expliquez OMT, OOD, OOSE

69 Description des scénarios
La forme textuelle est indispensable. Elle seule permet de communiquer de façon simple et précise. En revanche, elle n’est pas adaptée à la description des enchaînements d’un scénario aux interventions des acteurs secondaires. Expliquez OMT, OOD, OOSE

70 Modèle des cas d’utilisation
UML représente les cas d’utilisation par le diagramme de cas d’utilisation. On y montre les acteurs en relation avec les cas d’utilisation. Ce qui donne une vision spatiale et dynamique du système Expliquez OMT, OOD, OOSE

71 Les techniques d’analyse et de conception

72 Les patterns L’architecte Christophe Alexander est le premier à les avoirs évoqués en réponse à la question suivante. Les individus d’une même culture sont-ils tous d’accord sur ce qui peut-être considéré comme une bonne conception ? La réponse l’a conduit à découvrir des modèles pouvant servir de base objective à l’évaluation d’une conception: les patterns Question sur l’évaluation objective de la qualité en architecture Les patterns permettent de résoudre de façon similaire des problèmes récurrents.

73 Les différents types de pattern
Les patterns sont des solutions éprouvées pour résoudre des problèmes bien connus. On distingue plusieurs types de patterns selon la phase de modélisation ou l’on se trouve. Les patterns d’analyse. Les patterns de conception. Les patterns architecturaux. Les idiomes. Les frameworks ou cadres. des développeurs avertis se sont demandés si les concepts définis pour l’architecture pouvaient également s’appliquer à la conception de logiciels.

74 Techniques d’analyse des besoins

75 Modèle d’implémentation Modèle d’architecture
L’analyse des besoins Document de vision Analysés par Modèle du domaine Conçus par Modèle de conception Réalisés par Modèle d’implémentation Structurés par Modèle d’architecture Expliquez OMT, OOD, OOSE Testés par Modèle de tests Diagramme des UCs Déployés par Modèle de déploiement

76 Objectif de l’analyse Analyser les besoins, c’est rechercher les objets du domaine, leurs propriétés et leurs relations. Le diagramme de classe issu de cette activité représente: les classes conceptuelles ou les objets du domaine. les attributs de ces classes. les associations entre ces classes. Dans ce diagramme aucune opération ou méthode n’est indiquée

77 Mode opératoire Pour chaque cas d’utilisation, on déroule les étapes des scénarios que l’on analyse: Pour identifier les classes du domaine. Pour rechercher les attributs de ces classes. Pour recherches les associations entre ces classes. Pour typer ces associations. Expliquez OMT, OOD, OOSE

78 Identification des classes
Pour identifier les classes conceptuelles, plusieurs techniques existent: l’analyse linguistique. les listes de catégories. les classes de spécifications. les types de données non primitifs. les patterns d’analyse. Ou l’emploi de groupes nominaux. Les listes de catégories est complémentaire de l’analyse linguistique. Les classes de spécifications et les types de données non primitifs sont issus de l’analyse linguistique et des listes de catégories. Il vaut mieux sur spécifier un modèle du domaine avec de nombreuses classes à granularité fine que le sous spécifier.

79 Les attributs Un attribut est la valeur d’une donnée logique d’un objet. Une personne par exemple à un nom et un prénom qui doivent être connus. La classe conceptuelle Personne doit donc avoir des attributs Nom et Prénom. Expliquez OMT, OOD, OOSE

80 Les associations Une association est une relation significative entre des classes. Dans un Modèle du Domaine, on ne retient que deux sortes d’associations. Les associations mémorables. Les associations issues de la liste des associations courantes. Afin de juger quelles associations doivent être mémorisées, il faut connaître les relations qui doivent être conservées un certain temps. Connaître les objets entre lesquels on doit conserver la mémoire de la relation. Exemple: Il est indispensable de mémoriser les instances de LigneArticles associées à des instances de Vente. Sans cela, nous ne pourrions reconstituer les ventes, ni imprimer de ticket, ni calculer le total des ventes.

81 Les types d’association
On distingue plusieurs sortes d’associations : Les associations multiples La généralisation/spécialisation Les classes d’association L’agrégation L’association qualifiée L’association réflexive Expliquez OMT, OOD, OOSE

82 Enregistre-la-vente-de
Modèle du domaine Enregistre-la-vente-de Est-décrit-par 1 Specification Produits Catalogue Produits Descriptif Prix codeArticle 1..* 1 1 0..1 1 Est-utilisé-par 1..* 1 Ligne Article Magasin Décrit 1 * adresse nom 1 Stocke 0..* 1..* Article /quantite Héberge Journalise 1 Registre 1..* * Paiement Vente vente:Vente 1 1 montant date heure estTerminer Est-saisie-sur 1 Est-payée-par 1

83 Technique de conception

84 Modèle d’implémentation Modèle d’architecture
La conception générique Document de vision Analysés par Modèle du domaine Conçus par Modèle de conception Réalisés par Modèle d’implémentation Structurés par Modèle d’architecture Expliquez OMT, OOD, OOSE Testés par Modèle de tests Diagramme des UCs Déployés par Modèle de déploiement

85 L’activité de conception
La spécification et l’analyse des besoins ont permis de définir quel système construire. L’activité de conception, s’intéresse à la façon de construire le système. Elle vise à construire une solution qui satisfasse aux besoins du système. c'est-à-dire de comprendre les objectifs du système avec ses règles et ses contraintes

86 La conception orientée objet
L’adoption du paradigme objet et de ses principes fondamentaux. L’usage d’un langage de modélisation comme UML. La mise en œuvre d’un processus de développement adaptatif comme UP. Ne suffisent pas a orienter de façon qualitative l’activité de conception ! c'est-à-dire de comprendre les objectifs du système avec ses règles et ses contraintes

87 Les patterns d’affectation des responsabilités
Les principes de conception Pour concevoir une bonne solution, il faut penser en terme de responsabilités. Pour cela, il faut connaître l’une des principales techniques de conception Les patterns d’affectation des responsabilités

88 Les principes d’affectation
En conception, un système est vu comme une communauté d’objets qui collaborent entre eux. Ce mode de réflexion permet: d’identifier les objets qui contribuent à la réalisation d’un événement système. de définir les actions pour qu’ils s’acquittent de leurs responsabilités. 1) afin de réaliser les besoins exprimés

89 L’affectation des responsabilités
Les responsabilités sont affectées aux classes et sont de deux types: Les responsabilités de Faire comme: Créer un objet ou faire un calcul. Déclencher une action sur un objet. Contrôler les activités d’un objet. Les responsabilités de Savoir comme: Connaître les données encapsulées. Connaître les objets connexes. Connaître les éléments à dériver ou à calculer. 1) afin de réaliser les besoins exprimés

90 La réalisation des cas d’utilisation

91 Réalisation des cas d’utilisation
Pour chaque cas d’utilisation, on liste toutes les événements système que l’on modélise. en analysant les opérations système en identifiant les classes conceptuelles qui collaborent pour les réaliser. en affectant des responsabilités à chacune de ces classes. en matérialisant les choix d’affectation des responsabilités dans un diagramme d’interaction.

92 Les opérations système
Les opérations système gèrent les événements entrants. DSS Traiter une vente :Système :Caissier creerNouvelleVente() Ces événements système entrants invoquent des opérations système. L’événement système creerNouvelleVente invoque une opération système appelée creerNouvelleVente() et ainsi de suite. saisirArticles(codeArticle, quantite) Descriptif, total *[autres articles] terminerVente() Total avec taxes creerPaiement(montant) Monnaie à rendre, reçu

93 Les diagrammes d’intéractions
Quelque soit les problèmes de conception, on doit implémenter des méthodes pour les résoudre. Pour réaliser ce travail, les diagrammes d’interaction sont indispensables. Ils servent à représenter les actions réalisées par les objets en fonction de leurs responsabilités. Ces diagrammes sont de deux types: les diagrammes de séquence. les diagrammes de collaboration. qui propose une vue temporelle des messages échangés. qui propose une vue spatiale des messages échangés. fin) et leur possibilité de rétro ingénierie à partir du code source, car ceux-ci illustrent clairement la séquence de messages.

94 Réalisation SaisirArticle
Analyse: Une ligne article doit être créée et associée à une spécification produit et à la vente en cours. La quantité de la ligne article doit être renseignée. Responsabilité: qui doit créer la ligne article ? qui connait la spécification d’article à associer à la ligne article ? qui doit transmettre la quantité à la ligne article ?

95 Modèle de conception :Catalogue :Specification Produit Produit
:Registre :Vente saisirArticle(code, qte) Spec:= getSpecification(code) Spec:= chercher(code) creerLigneArticle(spec, qte) create(spec,qte) :LigneArticle

96 Enregistre-la-vente-de
Diagramme de conception Enregistre-la-vente-de Est-décrit-par 1 Specification Produits Catalogue Produits Descriptif Prix codeArticle 1..* getSpecification(code) 1 1 Chercher(code) 0..1 1 Utilisé-par * 1 Décrit Ligne Article Magasin 1 * adresse nom 1 Stocke 0..* 1..* Article /quantite Héberge Journalise 1 1..* Registre * Paiement Vente vente:Vente 1 1 montant date heure estTerminer Est-saisie-sur saisirArticle(code,qte) getMontant() 1 creerLigneArticle(spec,qte) 1 Est-payée-par

97 La modélisation architecturale

98 Modèle d’architecture Modèle d’implémentation
La modélisation architecturale Document de vision Analysés par Modèle du domaine Conçus par Modèle de conception Structurés par Modèle d’architecture Réalisés par Modèle d’implémentation Expliquez OMT, OOD, OOSE Testés par Modèle de tests Diagramme des UCs Déployés par Modèle de déploiement

99 Cette définition peut s’appliquer à la fabrication du logiciel.
Origine L’architecture c’est « l’art de concevoir et de construire un bâtiment selon un esthétisme et des règles techniques déterminées. » Cette définition peut s’appliquer à la fabrication du logiciel. A l’instar d’un bâtiment, un logiciel est: structuré par un plan, illustré par une maquette, réalisé par des procédés et des outils adaptés. 1) afin de réaliser les besoins exprimés

100 Dimension architecturale
L’architecture d’un système peut être vue selon deux angles principaux. La vue logique qui concerne l’organisation conceptuelle ou la structure du système. La vue de déploiement qui concerne l’organisation physique du système: Machines, OS, Réseaux, etc … ou le contexte d’exécution sur lequel est installé le logiciel. La décomposition proposée par la vue logique contribue à définir la distribution de la vue de déploiement.

101 La vue logique ou l’architecture logicielle décrit:
L’organisation générale d’un système. Les éléments qui le structurent et leurs interfaces. Les propriétés et les collaborations des éléments qui le composent. Elle contribue à une meilleure qualité du Logiciel en terme de: maintenance, évolutivité, réutilisation, performance, etc. 1) afin de réaliser les besoins exprimés

102 Architecture par couches
On l’applique aux applications munies d’une interface graphique et manipulant des données. Elle a pour but de séparer les différentes logiques d’une application: La présentation. La logique applicative. Le domaine métier. La gestion des données. Les modèles les plus connus sont: Modèle-Vue-Contrôleur ou MCV. Le modèle à 5 couches. Le modèle BCED La sortie d’un filtre correspond à l’entrée de l’autre.

103 Le modèle BCED Il s’inspire de l’approche MVC et du modèle à 5 couches. Dans ce modèle, on factorise les classes d’une application en quatre catégories: Classe boundary ou UI. Classe control ou UIP. Classe entity ou BE. Classe database interface ou DAL. Il facilite le déploiement en permettant de créer des composants se déployant naturellement. Il s’inspire de l’approche MVC et du modèle à 5 couches. Dans ce modèle, on factorise les classes d’une application en quatre catégories: Classe boundary. Classe control. Classe entity. Classe database interface.

104 La modélisation BCED La classe boundary représente une interface entre un acteur et le système. Elle appartient à la couche présentation. La classe control intercepte les événements et contrôle la logique de l’application. Elle appartient à la couche de coordination. La classe entity décrit les objets du domaine. Elle représente les données de la base de données et appartient à la couche Domaine. La classe DAL décrit les interfaces avec la base de données. Elle appartient à la couche persistance. 1)La classe boundary représente une interface entre un acteur et le système. Elle permette de représenter l’état du système sous forme d’interface graphique ou autre. Elle est de nature transitoire et appartient à la couche présentation. 2) La classe control intercepte les événements et contrôle la logique de d’application. Elle représente les actions d’un cas d’utilisation. Elle est de nature transitoire et appartient à la couche de coordination. 3)La classe entity décrit les objets du domaine de l’application. Elle représente généralement les structures de données de la base de données du système. Elle est de nature persistante. 4)Cette classe décrit les objets qui servent d’interface avec la base de données. Elle implémente les opérations de chargement et de sauvegarde des objets persistant. Elle implémente également les opérations de connexion, de configuration, etc. « db interface » DatabaseReader

105 La vue de déploiement La vue par niveau ou Tiers donne la vision physique d’un système. Elle distribue les couches logiques d’un système sur ses éléments physiques. Plusieurs de ces modèles ont vu le jour: Le modèle 1 Tiers. Le modèle 2 Tiers ou Client/Serveur ou Thick client. Le modèle 3 Tiers aussi appelé N-Tiers ou Thin client. Ceci concerne surtout les gros systèmes au fur et à mesure des capacités matérielles et des besoins.

106 Application serveur central Application monoposte
Le modèle 1 tiers Il correspond à un seul niveau physique où sont hébergées toutes les couches du système. Les applications monopostes ou sur système central sont de ce type. UI UIP BE UI UIP DAL Ceci concerne surtout les gros systèmes au fur et à mesure des capacités matérielles et des besoins. BE DAL Application serveur central Application monoposte

107 Le modèle 2 Tiers Le modèle Client/Serveur repose sur l’utilisation de bases de données relationnelles. Toutes les couches sont distribuées sur deux entités: le client et le serveur. Réseau UI UIP BE BD Ceci concerne surtout les gros systèmes au fur et à mesure des capacités matérielles et des besoins. DAL Poste client Serveur B.D.

108 Le modèle N-Tiers Dans ce modèle on répartit les couches logiques en trois niveaux ou plus. C’est le modèle par excellence pour les applications WEB. Réseau Serveur Windows Serveur de B.D. Unix UI UI UIP Client X Client Windows BE BD DAL

109 La conception détaillée

110 La conception détaillée
Document de vision Analysés par Modèle du domaine Conçus par Modèle de conception détaillée Structurés par Modèle d’architecture Expliquez OMT, OOD, OOSE Réalisés par Modèle d’implémentation Testés par Modèle de tests Diagramme des UCs Déployés par Modèle de déploiement

111 Dans le modèle BCED, on a identifié quatre catégories de classes:
Les classes d’analyse Dans le modèle BCED, on a identifié quatre catégories de classes: Entity, Boundary, Control, DataAccesLayer. On les appelle des classes d’analyse. Et ce sont les 3 dernières qui vont nous aider à finaliser la réalisation des cas d’utilisation. Il s’inspire de l’approche MVC et du modèle à 5 couches. Dans ce modèle, on factorise les classes d’une application en quatre catégories: Classe boundary. Classe control. Classe entity. Classe database interface.

112 Représentation des classes d’analyse
On représente généralement les classes d’analyse par les stéréotypes de Jacobson. pour les classes dialogues. pour les classes chargées de la coordination entre les classes dialogues et les classes entity. pour les classes métier ou classes du domaine. Pour les classes d’accès aux données. « Boundary » « control » Il s’inspire de l’approche MVC et du modèle à 5 couches. Dans ce modèle, on factorise les classes d’une application en quatre catégories: Classe boundary. Classe control. Classe entity. Classe database interface. « entity » « DAL »

113 Relations entre classes d’analyse
Les associations entre classes d’analyse suivent des règles assez strictes. Les “boundary” ne peuvent être reliées qu’aux “control”. Les “control” ont accès aux “boundary”, aux “entity” et aux autres contrôles. Les “entity” ont accès aux autres “entity”, aux “dal” et ne sont reliées qu’aux “control”. Les “dal” ont accès aux magasins de données et ne sont vus que par les “entity”. Il s’inspire de l’approche MVC et du modèle à 5 couches. Dans ce modèle, on factorise les classes d’une application en quatre catégories: Classe boundary. Classe control. Classe entity. Classe database interface.

114 Les règles d’associations
Représentation des règles strictes des relations entre classes d’analyse. Classes d’analyse Dialogue Control Entity « dal » DataAcces Il s’inspire de l’approche MVC et du modèle à 5 couches. Dans ce modèle, on factorise les classes d’une application en quatre catégories: Classe boundary. Classe control. Classe entity. Classe database interface. Relation bidirectionnelle Relations unidirectionnelles

115 Les classes participantes
Le diagramme résultant décrit les classes d’analyse et leurs relations. Il fait la jonction entre: le Modèle du domaine, les maquettes, Le Modèle de conception, l’architecture logique. Il s’inspire de l’approche MVC et du modèle à 5 couches. Dans ce modèle, on factorise les classes d’une application en quatre catégories: Classe boundary. Classe control. Classe entity. Classe database interface.

116 Application Conception de l’opération système SaisirArticle.
:Catalogue Produit :Specification Produit :Registre :Vente saisirArticle(code, qte) Spec:= getSpecification(code) Spec:= chercher(code) creerLigneArticle(spec, qte) create(spec,qte) :Ligne Article

117 SaisirArticle(code,qte)
Maquette d’architecture logique Presentation Control SaisirArticle(code,qte) Registre Domaine Catalog Vente click Spec Produit Ligne Article FrameTraiterVente Service Dal_LineArticle