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

Conception de Systèmes d’Information – S1 JPmP 1.1 ã Etude de Cas SI d ’un bureau d ’étude Hydraulique Michel TOLLENAERE professeur laboratoire GILCO Dominique.

Présentations similaires


Présentation au sujet: "Conception de Systèmes d’Information – S1 JPmP 1.1 ã Etude de Cas SI d ’un bureau d ’étude Hydraulique Michel TOLLENAERE professeur laboratoire GILCO Dominique."— Transcription de la présentation:

1 Conception de Systèmes d’Information – S1 JPmP 1.1 ã Etude de Cas SI d ’un bureau d ’étude Hydraulique Michel TOLLENAERE professeur laboratoire GILCO Dominique RIEU Professeur laboratoire LSR/équipe SIGMA Eric BLANCO Maître de Conférence laboratoire GILCO Khadidja GREBICI doctorante laboratoires GILCO / LSR.

2 Conception de Systèmes d’Information – S1 JPmP 1.2 ã Conception de Systèmes d ’Information Cours : Systèmes d ’Information Michel TOLLENEAR Dominique RIEU.

3 Conception de Systèmes d’Information – S1 JPmP 1.3 ã Notion de modèle  Qu’est ce qu’un modèle ? (Minsky 1968) A* est un modèle de A pour un observateur O ssi A* aide O à répondre aux questions qu’il se pose sur A. Système observé ModèleObservateur Où sont construites les ailes ?

4 Conception de Systèmes d’Information – S1 JPmP 1.4 ã  Objet: entité d ’un monde réel ou virtuel, capable de sauvegarder un état (une information) et qui offre des opérations (un comportement) pour observer ou modifier cet état.  Acteur: classe d ’utilisateur du système, personne physique ou morale, entité fonctionnelle ou organisationnelle.  Activité: opération interruptible exécutée durant un état zone d ’activités  Collaboration: interaction entre objets collaborants.  Relation: dépendance entre entités.  Paquetage: partition du modèle.  Cas d ’utilisation: manière dont les acteurs utilisent le système. notions de base: objet, acteur, collaboration, activité, Evénements, scénarios, états…

5 Conception de Systèmes d’Information – S1 JPmP 1.5 ã  Un événement est un stimuli externe visible, avec ses réponses. On commence la modélisation dynamique par l'extraction d'un résumé des séquences d'événements ; pour chaque objet il faut établir un diagramme d'états avec les événements entrants et sortants et qui montre les interactions entre objets. On n'établit pas d'algorithme, ce qui relève de l'implantation, si l'événement n'est pas externe. Ces diagrammes sont essentiels pour les systèmes interactifs, contrairement aux systèmes statiques comme les Bases de Données. Il faut aussi noter qu'ils ne sont pas suffisants pour les systèmes temps réel.  Un scénario est une séquence type d'événements, il permet de décrire les interactions courantes pour l'extraction des événements et l'identification des objets cibles. Le suivi des séquences et des états permet d'établir les diagrammes d'états et de les comparer afin d'obtenir la correspondance événement-objet. L'ensemble des diagrammes d'état définit le modèle dynamique.  Un état est une abstraction des valeurs des attributs et des liens d'un objet. Ces valeurs sont groupées selon les propriétés qui affectent le comportement de l'objet. Il faut établir, pour chaque objet non trivial un diagramme d'états qui décrit ses événements d'entrées et de sortie. Un scénario correspond à un chemin dans un tel diagramme. Pour ce faire il faut considérer un objet unique et ses interactions type, ce qui définit un chemin constitué d'un ensemble d'arcs étiquetés par les événements d'une colonne du suivi. L'intervalle entre deux événements correspond à une activité continue ou qui prend du temps ; c'est un état, représenté par un noeud et auquel on peut donner un nom si nécessaire. La modification d'un état par un événement donne lieu à une transition. ACTIVITE CHOMAGE Plus de 60 ans Perte d ’emploi recrutement RETRAITE EXEMPLE notions de base: objet, acteur, collaboration, activité, Evénements, scénarios, états…

6 Conception de Systèmes d’Information – S1 JPmP 1.6 ã • diagramme de classes • diagramme d’objets • diagramme de composants • diagramme de déploiement Statique (ce que le système EST) • diagramme de séquence • diagramme de collaboration • diagramme d’états-transitions • diagramme d’activités Fonctionnel (ce que le système FAIT) Dynamique (comment le système EVOLUE) • diagramme de cas d’utilisation • diagramme de collaboration • diagramme FAST Axes de modélisation d ’un système

7 Conception de Systèmes d’Information – S1 JPmP 1.7 ã Révision UML  UML: Définition  UML: Bibliographie et sites.  UML: Genèse  pourquoi UML?  UML, modèles et diagrammes, parcours général  Les Données : diagramme de classes - structure statique  Organiser les documents : les packages  Analyser par les Cas d’Utilisation  Compléments sur les langages et concepts

8 Conception de Systèmes d’Information – S1 JPmP 1.8 ã •langage semi formel •analyse et conception orientée objet •une notation • une méthode: « the Unified Software Development Process •outils : rational Rose, objecteering...

9 Conception de Systèmes d’Information – S1 JPmP 1.9 ã Bibliographie  « MODELISATION OBJET AVEC UML » P.Muller N.Gaertner, Editions Eyrolles - mars 2000  « UML EN Action : de l’analyse des besoins à la conception en Java » P.Roques F.Vallée, Editions Eyrolles - février 2000  «Advanced Object-Oriented Analysis & Design Using UML», Odell J., SIGS Publications,  « UML DISTILLED : A Brief Guide to the Standard Object Modeling Language » M.Fowler K.Scott, Addison & Wesley - août 1999  « LE GUIDE DE L’UTILISATEUR UML » G.Booch I.Jacobson J.Rumbaugh, Editions Eyrolles - février 2000  « LE PROCESSUS UNIFIE DE DEVELOPPEMENT LOGICIEL » I.Jacobson G.Booch J.Rumbaugh, Editions Eyrolles - juin  « UML POUR L’ANALYSE D’UN S.I. : Le cahier des charges du maître d'ouvrage » C.Morley J.Hugues B.Leblanc, Dunod - février 2000  « Business Modeling with UML : Business Patterns at work » H.Eriksson M.Penker Wiley & Sons - janvier 2000  « Concevoir des application Web avec UML », J.Conallen, Eyrolles, sept 2000

10 Conception de Systèmes d’Information – S1 JPmP 1.10 ã Bibliographie  « Unified Modeling Langage Reference Manual », J.Rumbaugh I.Jacobson G.Booch, Addison-Wesley,  « UML en Action », Pascal Rocques, Vallée F, Eyrolles, 2000.

11 Conception de Systèmes d’Information – S1 JPmP 1.11 ã Des sites...  Des sites en français –//www.uml.crespim.uha.fr/ (site de mulhouse) –//free.uml.fr/  Des sites industriels –//www.rational.com/uml –//www.objexion.com/ –//www.softeam.fr/  Des livres sur UML répertoriés par –//www.eyrolles.fr/php.informatique/Ouvrages/liste_ouvrages

12 Conception de Systèmes d’Information – S1 JPmP 1.12 ã Genèse d’UML OOAD Booch Méthode unifiée 0.8 UML 0.9 OMT Rumbaugh... OOSE Jacobson... Autres Méthodes UML 1.1 UML 1.0 UML 1.3 UML 1.2 UML 1.4 UML 2.0 Spécification sur internet Partenaires Novembre : Acceptation Septembre : soumission final Janvier : soumission OMG Révision Mineur Révision 1997

13 Conception de Systèmes d’Information – S1 JPmP 1.13 ã Pourquoi UML ?  Besoin d’un Langage de Modélisation –notation claire des diagrammes –de modèles variés/points de vue –flexibilité –unificateur  Besoin d’un Processus de Modélisation (dirigé par les cas d’utilisation) –modèles et vues intégrant l’architecture –itératif et incrémental –non standard mais à ADAPTER...  Pour Documenter –les besoins –l’architecture –la conception –le codage, les tests....  Dans X Environnements de systèmes à support logiciels : –SI de l’entreprise –Systèmes bancaires, financiers –Télécoms, transports –Aérospatiale, scientifique –Électronique, médical –Services Web

14 Conception de Systèmes d’Information – S1 JPmP 1.14 ã UML, Modèles et Diagrammes Parcours Général

15 Conception de Systèmes d’Information – S1 JPmP 1.15 ã  Modèle de Classes qui capture la structure statique  Modèle des Cas d’Utilisation – Use Case, UC – qui décrit les besoins, les fonctions  Modèle d’Interaction qui représente les scénarios et les flots de messages  Modèle des États qui exprime le comportement dynamique des objets, classes...  Modèle de Réalisation qui montre des unités de travail  Modèle de Déploiement qui précise la répartition des processus  Descriptions abstraites pour capturer la sémantique d’un système Un Modèle = Un point de vue sur le système

16 Conception de Systèmes d’Information – S1 JPmP 1.16 ã Diagrammes ClassesObjetsSéquenceCollaborationActivités Cas d'UtilisationÉtats-TransitionsComposantsDéploiement

17 Conception de Systèmes d’Information – S1 JPmP 1.17 ã lien d’héritage : «est un diagramme», chacun est une spécialisation de la classe diagramme Un diagramme est un « langage graphique » de phrases traduisant entre les concepts « éléments du vocabulaire du diagramme », icônifiés aux nœuds des relations matérialisées par des arcs du graphe, écrits avec un forme particulière. L’ensemble donne la syntaxe, graphique du langage associé Diagrammes ClassesObjetsSéquenceCollaborationActivités Cas d'UtilisationÉtats-TransitionsComposantsDéploiement

18 Conception de Systèmes d’Information – S1 JPmP 1.18 ã Diagrammes ClassesObjetsSéquenceCollaborationActivités Cas d'UtilisationÉtats-TransitionsComposantsDéploiement  Aspects structurels statiques  diagramme de classes : classes et relations statiques  diagramme des objets : objets et liens  Aspects fonctionnels et dynamiques  diagramme de cas d’utilisation : acteurs et utilisation du  système Diagrammes Ce que le système EST Ce que le système FAIT

19 Conception de Systèmes d’Information – S1 JPmP 1.19 ã Diagrammes ClassesObjetsSéquenceCollaborationActivités Cas d'UtilisationÉtats-TransitionsComposantsDéploiement Diagrammes  Aspects dynamiques  diagramme de séquence : vision temporelle des interactions  diagramme de collaboration : vision spatiale des interactions  diagramme d’états-transitions : comportement des objets  diagramme d’activités : flot de contrôle interne aux opérations comment le système EVOLUE

20 Conception de Systèmes d’Information – S1 JPmP 1.20 ã Diagrammes ClassesObjetsSéquenceCollaborationActivités Cas d'UtilisationÉtats-TransitionsComposantsDéploiement Diagrammes  Aspects implantation  diagramme de composants : codage  diagramme de déploiement : implantation, distribution  Les diagrammes des classes physiques participant aussi à cette description

21 Conception de Systèmes d’Information – S1 JPmP 1.21 ã Organiser les documents, Les Packages

22 Conception de Systèmes d’Information – S1 JPmP 1.22 ã Structurer : Package  Unité de stockage d’un ensemble d’informations variées ayant trait à une même unité d’information pour l’application modélisée.  Appliqué selon plusieurs points de vue : package exigences package analyse package conception package réalisation package maintenance Vue cycle de développement Pkg-projet Pkg-exigences Pkg-analyse Pkg-maintenance Pkg-conception «trace» Pkg-réalisation «realise»

23 Conception de Systèmes d’Information – S1 JPmP 1.23 ã Graphisme  Chaque package peut avoir divers modèles (UC, Classes, textes, ….) lesquels constituent une unité de documentation pour le niveau auquel on se trouve…. –Analyse –Conception –Réalisation Structurer : Package

24 Conception de Systèmes d’Information – S1 JPmP 1.24 ã Analyser par les Cas d’Utilisation, Cas d’Utilisation, Scénarios : Collaborations et Séquences

25 Conception de Systèmes d’Information – S1 JPmP 1.25 ã Diagrammes de Cas d’Utilisation  Un CU est :  une réponse à la question « dans quel cas tel acteur utilise-t-il le système?. C ’est un ensemble d ’interactions entre acteur et système.  une technique d ’expression des besoins mise en œuvre par Ivar Jacobson (objectory).  une manière spécifique d’utiliser un système  représenté dans un diagramme de CU faisant référence aux acteurs, i.e: « choses » externes au système qui communiquent avec ce dernier (principaux, secondaires, matériels ou non) et aux relations (communication, utilisation, extension)  de propriétés :  - exclusivité les uns des autres, le système est dans une situation donnée pour un acteur donné et à un instant donné.  - couverture d ’une utilisation complète depuis la connexion jusqu ’à la déconnexion.  L’analyse d’un cas d’utilisation par des scénarios :  Diagrammes de Collaboration (modèles organisationnels)  Diagrammes de Séquence (modèles chronologiques)  pour des regroupements et la mise en évidence des objets et des cas d’utilisation 

26 Conception de Systèmes d’Information – S1 JPmP 1.26 ã  Modéliser le comportement d’un : –élément, –système, –sous-système, –classe.  Un acteur fait avec le système qui lui offre ce service : –« un client fait un virement »  Ce que fait l’élément et NON Comment il le fait Diagrammes de Cas d’Utilisation « généralise » Identification Client Virement > Client distant Virement minitel

27 Conception de Systèmes d’Information – S1 JPmP 1.27 ã Exemple1 : Réserver sur un vol à une date donnée  Le client interroge le système, soit en passant dans une agence, soit par un système télé-informatique (minitel ou internet) pour s’assurer de pouvoir faire la réservation souhaitée.  La réservation peut concerner un déplacement de passagers (un ou plusieurs) ou une demande de transport de fret.  Une solution réalisable étant trouvée, il enregistre la réservation (nom des passagers ou volumes et caractéristiques du fret) et paye par le moyen adapté à l’environnement (liquide, chèque, carte de crédit).  Le ou les billets correspondants lui sont délivrés (directement, à l’agence, par la poste, par mise à disposition à l’aéroport pour télépayement ou aussi par impression de bons de transports sur connexion internet. Diagrammes de Cas d’Utilisation Client Réserver une note est attachée à tout UC, pour définir son rôle et son contenu

28 Conception de Systèmes d’Information – S1 JPmP 1.28 ã Exemple 1 – Requirements Diagrammes de Cas d’Utilisation Interroger au guichet Interroger par le net Interroger possibilité-vol Client (Système) RESERVER Vue analyse des besoins : un acteur, le client Le diagramme d’UC du package RESERVER, décompose l ’UC RESERVER Généralisation/spécialisation selon les « modes d ’accès »

29 Conception de Systèmes d’Information – S1 JPmP 1.29 ã Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements Interroger au guichet Interroger par le net Interroger possibilité-vol enregistrer réservation Client (Système) RESERVER Vue analyse des besoins

30 Conception de Systèmes d’Information – S1 JPmP 1.30 ã Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements Interroger au guichet Interroger par le net enregistrer fret enregistrer passagers Interroger possibilité-vol enregistrer réservation Client (Système) RESERVER Vue analyse des besoins Spécialisation par l’objet du transport

31 Conception de Systèmes d’Information – S1 JPmP 1.31 ã Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements Interroger au guichet Interroger par le net enregistrer fret enregistrer passagers Interroger possibilité-vol enregistrer réservation payer Client (Système) RESERVER Vue analyse des besoins

32 Conception de Systèmes d’Information – S1 JPmP 1.32 ã Interroger au guichet Interroger par le net enregistrer fret enregistrer passagers Interroger possibilité-vol enregistrer réservation payer Client obtenir billets Diagrammes de Cas d’Utilisation – Exemple 1 : Requirements les liens d’activation du système (Système) RESERVER Vue analyse des besoins

33 Conception de Systèmes d’Information – S1 JPmP 1.33 ã Exemple 1 – Analyse Diagrammes de Cas d’Utilisation Vue Analyse (raffinement) spécification Interroger au guichet Interroger par le net Client Gestionnaire des vols Interroger possibilité-vol Gestion interface (Système) RESERVER Sous-systèmes externes Généralisation/spéciali sation selon les « modes d ’accès »

34 Conception de Systèmes d’Information – S1 JPmP 1.34 ã enregistrer fret enregistrer passagers Interroger au guichet Interroger par le net Client Gestionnaire des vols Interroger possibilité-vol enregistrer réservation Gestion interface (Système) RESERVER Vue Analyse Spécialisation par l’objet du transport Diagrammes de Cas d’Utilisation – Exemple 1 : Analyse

35 Conception de Systèmes d’Information – S1 JPmP 1.35 ã enregistrer fret enregistrer passagers Interroger au guichet Interroger par le net Client Gestionnaire des vols Interroger possibilité-vol enregistrer réservation Gestion interface (Système) RESERVER Vue Analyse Gestionnaire financier payer Diagrammes de Cas d’Utilisation – Exemple 1 : Analyse

36 Conception de Systèmes d’Information – S1 JPmP 1.36 ã Diagrammes de Cas d’Utilisation – Exemple 1 : Analyse enregistrer fret enregistrer passagers Interroger au guichet Interroger par le net Client Gestionnaire des vols Interroger possibilité-vol enregistrer réservation Gestion interface (Système) RESERVER Vue Analyse Gestionnaire financier payer obtenir billets des acteurs secondaires des acteurs secondaire principal

37 Conception de Systèmes d’Information – S1 JPmP 1.37 ã relation d’extension : une évolution demandée avec indication de l’endroit où elle vient s’insérer Interroger possibilité-vol Consulter les promotions Interroger par le net > Extension : Systèmes Évolutifs Diagrammes de Cas d’Utilisation extension points : commande complémentaire - les bonnes occases- après rechercher un vol.

38 Conception de Systèmes d’Information – S1 JPmP 1.38 ã Exemple 1 – Conception Diagrammes de Cas d’Utilisation Télé-système Agence Gérer paiements ss-système Gérer-réservation Valider la commande Enregistrer demande Enregistrer passager Enregistrer fret Agent-réservation Éditer billet Client Réserver > Système de Réservation

39 Conception de Systèmes d’Information – S1 JPmP 1.39 ã Relations dans les Diagrammes d’UC  Pas de Composition-Décomposition: (pour le raffinement) mais un UC se décrit en détail à travers un package associé à l ’UC à détailler et décrit par des diagrammes d’UC définissant le contenu du package.  Inclusion « include »: (pour la réutilisation) A inclut B & l’utilise  relation de dépendance entre UC d’un même diagramme; l’UC, inclus, peut être réutilisé dans d’autres diagrammes ; (exemple type : Réserver, Éditer billet)  Extension « extend »: (pour l’extensibilité) B étend A, en...  relation de dépendance entre UC d’un même diagramme; l’UC, qui « étend », doit avoir un point d’insertion dans l’UC « étendu » ; (exemple : « Consulter les promotions »)  Généralisation : (pour les mécanismes d’héritages et de versions) relation hiérarchique (une spécialisation assure la fonction de l’UC parent) qui permet d’avoir plusieurs environnements pour le même objectif. (exemple : Interroger possibilité-vol et Interroger par le net…) Sans oublier entre les niveaux les dépendances de « trace » ou « réalisation »... Diagrammes de Cas d’Utilisation Cas d'utilisation ACas d'utilisation B > Cas d'utilisation BCas d'utilisation A > Lorsque la description textuelle fait apparaître des interactions communes à plusieurs cas. Pour éviter la ré-écriture. Permettre d ’étendre les interactions et donc les fonctionnalités décrites par les interactions typique d ’une situation optionnelle.

40 Conception de Systèmes d’Information – S1 JPmP 1.40 ã Diagrammes d’Interaction  Ensemble des objets, acteurs, systèmes qui collaborent pour contribuer à la réalisation d’un U.C.  A l’expression d’une collaboration est associé un diagramme de collaboration qui met en évidence les parties de système, acteurs et objets collaborants Deux Types : Collaboration ou Séquences

41 Conception de Systèmes d’Information – S1 JPmP 1.41 ã Diagrammes de Collaboration  Utilisé pour décrire des scénarios du modèle : formes de séquences des vies relationnelles des objets  Utilisé pour décrire les interactions entre objets –ensembles de messages échangés entre les objets, –liens créés par ces échanges et leurs successions et/ou alternatives –messages (orientés), flux de données  Syntaxe d’un OBJET 1-objet: joël:ETUDIANT :ETUDIANT un objet anonyme de la classe étudiant l ’objet, nommé Joël de la classe ETUDIANT objet, nommé 1-objet pas de classe associée Modéliser les Flux de Contrôle

42 Conception de Systèmes d’Information – S1 JPmP 1.42 ã  Ce scénario traduit ce qui se passe quand tout est OK  à étudier, les autres cas : pas de “vol” et pas de “place”  Dans ce modèle, on ne se préoccupe pas de l’aspect “gestion d’interface-client”, serveur d’agence ou de télécommunication, gestionnaire du dialogue, qui serait seul à communiquer avec les sous-systèmes du système de réservation. C’est ici une vue purement “fonctionnelle”  Séquencement chronologique sans notion d’écoulement de temps Message action : Verbe Chaque message crée un lien entre les objets, une relation entre leurs classes Un Use Case est un « classifier », unité de regroupement, de Scénarios Diagrammes de Collaboration Exemple : f : Gestionnaire financier b : Billets 7: éditer réservation c : Client r : Réserve 8: demander billet : Gestion interface 1: demander réservation 2: réserve 3: réservation possible 4: évaluer réservation 5: afficher prix à payer 6: payer 9: m à dispo-billet

43 Conception de Systèmes d’Information – S1 JPmP 1.43 ã 1 : demander réservation 2.0 [choix = OK]: confirme-réservation Exprimer une alternative : 2.0 [non(choix = OK)]: propose-alternatives 2.1 [non(choix = OK)]: choisir-alternative 2.2 [non(choix= OK)] : confirme-alternative Même numéro de séquence de l’action suivie d’une condition. Pour la cohérence du modèle, il faut que les conditions soient exclusives et totalement définies, mais rien dans les outils ne valide cela, pour l’instant Pour la lisibilité, il est souvent opportun de multiplier les modèles descriptifs chacun d’une situation, càd d’un scénario pour le cas « normal » et les exceptions Diagrammes de Collaboration c : Client r : Réserve

44 Conception de Systèmes d’Information – S1 JPmP 1.44 ã Diagramme de Séquence  Utilisé pour modéliser des scénarios du modèle entre des objets  Utilisé pour décrire les interaction entre objets selon un point de vue temporel : –ensembles d’opérations échangées entre les objets, liens, messages (orientés) –séquencement chronologique avec la notion de “vie de l’objet” –écoulement du temps vertical/échange de message horizontal avec du parallélisme d’existence, des alternatives...  Deux utilisations : –documentation des cas d’utilisation (événements,...) –représentation précise des interactions entre objets (messages,...)  Messages synchrones, asynchrones, délai de transmission, contraintes temporelles...  Création, destruction d’objets / durée d’activation d’un objet / boucles, conditionnelles  Utilisé aussi pour documenter la dynamique des processus au niveau de la conception physique du système Modéliser les Flux de Contrôle selon le Temps

45 Conception de Systèmes d’Information – S1 JPmP 1.45 ã :Unobjet :autreobjet Message asynchrone Retour explicite :Unobjet :autreobjet Message synchrone Retour implicite :Unobjet :autreobjet X création destruction Diagrammes de Séquence

46 Conception de Systèmes d’Information – S1 JPmP 1.46 ã c : Client r : Réserve f : Gestionnaire financier b : Billets : Gestion interface demander billet éditer réservation demander réservation réserve réservation possible évaluer réservation afficher prix à payer payer m à dispo-billet Exemple : Un dual du diagramme de collaboration avec insistance sur le temps Diagrammes de Séquence

47 Conception de Systèmes d’Information – S1 JPmP 1.47 ã Syntaxe  Entête des colonnes : –Objets –Acteur, si il est acteur de l’UC dont le DS est un scénario (rattachement)  Message : deux types –message synchrone : A attend la réponse de B –message asynchrone : A envoie un signal et ne s’en occupe plus  Alternatives entre les mêmes objets AB Diagrammes de Séquence

48 Conception de Systèmes d’Information – S1 JPmP 1.48 ã Diagrammes de Classes – Données Classes, Attributs, Opérations, Associations, Agrégation, Composition, Héritage

49 Conception de Systèmes d’Information – S1 JPmP 1.49 ã Classes - Propriétés  Les classes : ensemble d’objets ayant les mêmes attributs, les mêmes opérations, les mêmes relations et la même sémantique Responsabilités : représentées comme une note ou dans la doc de la classe Vol numVol hdep har définir-périodes() définit la desserte d’une ligne (ville de départ, ville d’arrivée) selon un horaire donné Représentation graphiques nom de classe (unique) attributs, typés ou non, simples ou multiples, avec valeur initiale éventuelle opérations() avec ou sans leurs paramètres Une classe peut être présentée sans ses attributs e/ou sans ses opérations.

50 Conception de Systèmes d’Information – S1 JPmP 1.50 ã Classes - Instances Une classe = un type + un conteneur d’objets de ce type « instancie » Grenoble-Paris1 :VOL GREPA01 5h37 6h41 Paris-Grenoble1 :VOL PAGRE01 7H15 8H20 Vol numVol hdep har définir-périodes()  Donc, il faut « classer », càd,  reconnaître les familles d’éléments, « ensembles » cohérents  leur rôle, « responsabilité »  les données associées « attributs »  les actions que font les éléments « actifs »  les actions que l’on fait sur les éléments « passifs »  les « signaux » qu’ils envoient les « opérations »

51 Conception de Systèmes d’Information – S1 JPmP 1.51 ã Responsabilités  Utiliser en phase d’analyse de besoins –pour décrire le rôle des objets de la classe par rapport à l’environnement –pour se concentrer sur le « pourquoi » avant d’aborder les structures : attributs –mettre en évidence les relations fonctionnelles pour l’utilisateur  Concerne particulièrement les «objets clients» – un badge, identifie une des personnes autorisées – un lecteur,  veille & détecte la présentation d’un badge et en lit le code  informe le système de contrôle et affiche le résultat du contrôle  … Diagrammes de Classes Exemple Contrôle d’Access

52 Conception de Systèmes d’Information – S1 JPmP 1.52 ã Propriétés Statiques - Attributs  Concernent la structure des données  Une syntaxe –[visibilité] nom [multiplicité] [ : type ][= valeur-initiale] –[ {chaîne-propriété} ]  Trois valeurs de visibilité : –+, public (visible de toute classe), –#, protégé (visible dans la classe et ses sous-classes), –-, privé (visible dans la classe uniquement), Diagrammes de Classes

53 Conception de Systèmes d’Information – S1 JPmP 1.53 ã Propriétés Dynamiques - Opérations  Une syntaxe et quelques propriétés –[visibilité] nom [ (liste-paramètre) ] [ : type-retour ] –[ {chaîne-propriété} ]  Des propriétés de contrôle de flots dynamiques : –sequential : coordination extérieure pour que les appels soient séquentiels (1à1) –guarded : contrôle d’intégrité sémantique, pas d’appels concurrents sur les gardes –concurrent Diagrammes de Classes

54 Conception de Systèmes d’Information – S1 JPmP 1.54 ã Exemples Les opérations de création d’un objet sont implicites car « standard ». Diagrammes de Classes Formation nom : String ajouter(nom : String) : void valider(nom : String) : void Inscription date : Date Sport nom ajouter() invalider() Étudiant nom : String numéro : Integer = 0 age : Integer grade ajouter(Nom : String) : void s-inscrire() : Boolean Formation : cycle d’étude auquel les étudiants peuvent s’inscrire dans le cadre de l’institution que l’on gère. Créée ou invalidée par l’administration après habilitation Archivée pour l’historique de la vie de l’établissement Note Lors de la création d’une classe, donner sa definition comme une Note ou avec la Documentation de la Classe

55 Conception de Systèmes d’Information – S1 JPmP 1.55 ã Variétés Spécifiques  «stéréotype» : type de méta-classe qui sert de «définition de type» pour une famille de classe – >, >, >... –«interface» : associée à une classe, elle décrit un comportement visible  Ne contient que des opérations (un type de stéréotype) POSterminal I-Store Store storeId : Integer POSlist : list create() login() find() getPOStotals() updateStoreTotals() get() > POSterminal I-Store getPOStotals() updateStoreTotals() get() Store storeId : Integer POSlist : list create() login() find() getPOStotals() updateStoreTotals() get() > Diagrammes de Classes Une classe « interface » est une Classe abstraire. Autre représentation

56 Conception de Systèmes d’Information – S1 JPmP 1.56 ã Les Relations  Lien entre les objets ou les classes qui crée des dépendances fortes entre les classes du diagramme  Trois types de liens de base, statiques, structurants : – association –agrégation, composition –héritage  Aussi, des liens de dépendance, plus faibles concernant la conception/réalisation du modèle de base  ce sont les dépendances : –« réalise » entre classe et une interface –« réalise » entre des composants logiciels et une classe –« trace » entre classe « utilisateur » issue de l’analyse et –classe « composant » qui est le résultat de la conception du logiciel Diagrammes de Classes

57 Conception de Systèmes d’Information – S1 JPmP 1.57 ã Étudiant nom : String numéro : Integer = 0 age : Integer grade ajouter(Nom : String) : void s-inscrire() : Boolean Formation nom : String ajouter() valider() n n Inscription > +inscrits Diagrammes de Classes – Les Relations Associations ! La formation à laquelle l’étudiant est inscrit ne figure pas en « doublon » dans les attributs de Étudiant  C’est la relation qui traduit la propriété. Rôle (pas nécessairement des deux côtes) Nom de la association (en italique) > Comment lire l’association Cardinalités (inversées)

58 Conception de Systèmes d’Information – S1 JPmP 1.58 ã Classe Associative Inscription date : Date Action pour un étudiant de s’inscrire à une formation de l’établissement, créé et daté par la scolarité lors de cette inscription. Archivé pour l’historique de la vie de l’étudiant Étudiant nom : String numéro : Integer = 0 age : Integer grade ajouter(Nom : String) : void s-inscrire() : Boolean Formation nom : String ajouter() valider() n n Inscription > +inscrits Classe associative : un objet de la classe est identifié par le « couple » d’objets liés par l’association Diagrammes de Classes – Les Relations – Association

59 Conception de Systèmes d’Information – S1 JPmP 1.59 ã Généralisation-Spécialisation Diagrammes de Classes – Les Relations Instance-Vol associerAvion() Instance-Pass res1 res2 réserver1() réserver2() associerAvion() Instance-Fret fret reserver-fret() associerAvion() Héritage Polymorphisme  Généralisation : plus général… –super-classe –sous-classe (hérite de)  Spécialisation : plus spécial  Généraliser : –factoriser attributs, opérations, contraintes  Spécialiser : –extension COHERENTE…au sens ensembliste...

60 Conception de Systèmes d’Information – S1 JPmP 1.60 ã Héritage Multiple Diagrammes de Classes – Les Relations – Généralisation-Spécialisation

61 Conception de Systèmes d’Information – S1 JPmP 1.61 ã « Classe Abstraite »  Classe, regroupant des propriétés communes à ses sous-classes  Pas d’instances propres, sert juste à la « factorisation », « abstraction » Diagrammes de Classes – Les Relations – Généralisation-Spécialisation Personne nom : String prénom : String n-insee : Integer adresse : String identifier() Employe salaire : Double indice : Double identifier() Etudiant n-inscription : Integer identifier() Nom en italique

62 Conception de Systèmes d’Information – S1 JPmP 1.62 ã Quelques Considérations  Sens : « est un », « est une sorte de », « est de la famille des »  Propriétés : –non réflexive : A n’hérite pas de lui-même ; il EST lui-même –non-symétrique : B sous-classe de A, interdit A sous-classe de B (pas de cycle) –transitive : C sous classe de B, B sous-classe de A => C sous-classe de A A A B A B C Diagrammes de Classes – Les Relations – Généralisation-Spécialisation

63 Conception de Systèmes d’Information – S1 JPmP 1.63 ã Diagrammes de Classes – Les Relations  Type de relation orientée, du tout vers les parties Forte : Composition Faible : Agrégation Agrégation Un module appartient à une seule filière (et disparaît avec elle) Les modules sont partagés par plusieurs filières composition = agrégation forte pas de partage mort simultanée Tout Partie

64 Conception de Systèmes d’Information – S1 JPmP 1.64 ã Dépendances  Réalisation  La dépendance  « type de dépendance » –bind, entre des classes paramétrées et les paramètres effectifs –derive, attribut dérivé : âge dérivé de date-de naissance –friend, visibilité du but par la source –instanceOf, instantiate pour des relations classe/objet –powertype dans une relation enfants d’un même parent –refine par raffinement d’abstraction de classe (analyse...implémente) Diagrammes de Classes

65 Conception de Systèmes d’Information – S1 JPmP 1.65 ã Dynamique des Classes Diagramme d’ État-Transition, Diagramme d’Activités.

66 Conception de Systèmes d’Information – S1 JPmP 1.66 ã Diagrammes d’États-Transitions  Automates d’états finis de type State Charts de Harel (visual Formalism for complexe systems, Sciences of Computer Programming vol 8).  Exprime contraintes dynamiques  Abstraction des comportements possibles –des objets d’une classe (le plus souvent...) –d’un U.C. –d’un système  Un état est caractérisé par une notion de durée et de stabilité  Automates déterministes avec un état initial et des états finaux  Transitions déclenchées par des événements –avec conditions, actions et activités  Décomposition disjonctive et composition conjonctive d’états  Historique Etat initial Etat intermédiaire Etat final ACTIVITE CHOMAGE Plus de 60 ans Perte d ’emploi recrutement RETRAITE

67 Conception de Systèmes d’Information – S1 JPmP 1.67 ã Exemple 1 Classe Diagrammes d’États-Transition Diagramme d’États-Transition pour la Classe Station-Lavage Attente > LavageRinçageSéchage Fin( programme ) Suite( Programme )Suite( programme ) Fin( programme ) Démarrer( programme ) [ présence(véhicule) ] Station-Lavage

68 Conception de Systèmes d’Information – S1 JPmP 1.68 ã événement transitions états Attente > LavageRinçageSéchage Fin( programme ) Suite( programme ) Fin( programme ) Démarrer( programme ) [ présence(véhicule) ] garde démarrer(programme) est un « signal » du Système de commande [présence(véhicule)] est une « garde », condition qui est évaluée pour accepter ou refuser la transition. Le développement des diagrammes d’états entraîne la mise à jour en cohérence des diagrammes de classes (statique) Syst-Commande « signal » démarrer(programme) fin(programme) Classes Station-Lavage Diagrammes d’États-Transition – Exemple 1

69 Conception de Systèmes d’Information – S1 JPmP 1.69 ã En regroupant toutes les transitions « fin programme » on met en évidence un sur-état Actif événement Diagrammes d’États-Transition – Exemple 1 Attente > Actif LavageRinçageSéchageLavageRinçageSéchage Démarrer( programme )[ présence(véhicule) ] Fin( programme ) Syst-Commande « signal » démarrer(programme) fin(programme) Classes Station-Lavage

70 Conception de Systèmes d’Information – S1 JPmP 1.70 ã Attente > Lavage Démarrer( programme ) [ présence(véhicule) ] RinçageSéchage Fin( programme ) Suite( programme ) Fin( programme ) Suite( programme ) Diagramme « hiérarchisé » Diagramme « plat » Attente > Actif... Démarrer( programme )[ présence(véhicule) ] Fin( programme ) Actif LavageRinçageSéchageLavageRinçageSéchage les sous-états héritent des transitions de sortie

71 Conception de Systèmes d’Information – S1 JPmP 1.71 ã État “historique” – indique un retour avec mémorisation Diagrammes d’États-Transition – Exemple 1 Actif LavageRinçageSéchage H LavageRinçageSéchage H Attente > Fin( programme ) ProblèmeDémarrage( programme )[ présence(véhicule) ] Histoire des sous-états dans un état

72 Conception de Systèmes d’Information – S1 JPmP 1.72 ã Concepts 1  État : (d’un objet ou d’une classe) : ensemble des valeurs, des attributs, des relations et des opérations exécutables (pour l’objet et ceux qui sont visibles par lui) – nom: nomme l’état, mais il peut être anonyme ; pas obligatoire –actions : d’entrée/sortie, opérations instantanées, non interruptive exécutées à l’entrée ou la sortie de l’état, (au passage de la transition) –transitions internes : transitions qui ne changent pas l’état, et s’exécutent sous le contrôle des sous états –sous états : états contenus dans l’état impliquant des sous-états, disjoints (séquentiels) ou concurrents –pseudo états : il existent trois :  état initial : correspond à l’état implicite “le diagramme d’états est crée”  état final : correspond à l’état implicite “le diagramme d’états est détruit”  état “indicateur d’historique” : une transition vers cet état déclenche une transition au dernier sous-état atteint lors du dernier passage à cet état Diagrammes d’États-Transition

73 Conception de Systèmes d’Information – S1 JPmP 1.73 ã Concepts 2  État “idle”, inactif, attente : état neutre de l’objet après une transition, il attend d’autres événements pour effectuer une transition.  État actif : état actif càd une activité se déroule pendant que l’objet est dans cet état, en attendant un événement déclencheur d’une transition (avec durée)  Activité - do/activity (faire/activité) –Ensemble d’opérations qui peuvent se produire pendant que l’objet est dans un état. Ex.: do/op1(a); op2(b); op3(c) –Séquence d’actions (chaque action est non interruptive) –Une activité met un certain temps à s’exécuter. –Elle est interruptive (entre deux actions) par un événement déclencheur. –Elle peut faire référence à un autre diagramme d’état qui la décrit ; Diagrammes d’États-Transition Transition d’État Événement[Garde]/Action États InitialFinal Nom Nom de l’État entry: action d’entrée entry: ^class.événement exit: action de sortir exit: ^ class.événement do: activité do: ^class.événement

74 Conception de Systèmes d’Information – S1 JPmP 1.74 ã Concepts 3  Les événements provoquant les transitions sont classables suivant 4 natures : –change event :changements de valeur, atteintes de limites –time event : date, jour-heure, fin ou début de période –signal : signaux venant d ’une autre classe (classe-active) avec ou sans paramètre –call event : appel de procédure qui déclenche une action qui fait transiter…  Comment les reconnaître ? Et trouver les états : –en examinant dans les scénarios, les appels de procédure inter-objets ou les signaux envoyés –en regardant les qualificatifs associés aux objets dans ces mêmes scénarios –en examinant les attributs des objets et leurs valeurs critiques –en établissant une trace des divers points importants du «calendrier » qui rythme la vie du système et des objets Diagrammes d’États-Transition État : une situation assez stable pour « durer » !

75 Conception de Systèmes d’Information – S1 JPmP 1.75 ã Exemple 2 Diagramme d’États-Transition pour une Classe Fax Diagrammes d’États-Transition super-état actions transitions sans déclencheur sous-état état final (fin du scénario) état initial (début du scénario) Attendre > Transmission Réception Connecté En-traitement do/ recevoir Effacer entry/ décrocher exit/ déconnecter Connecté En-traitement do/ recevoir Effacer Entête-Ok [ parité-Faux ] raccrocher Erreur / imprimer-rapport sonnerie Envoie-fax

76 Conception de Systèmes d’Information – S1 JPmP 1.76 ã Diagrammes d’Activités  Autre diagramme pour exprimer de la dynamique  un organigramme qui présente le flux de contrôle entre des activités  Utilisé principalement pour la modélisation d’étapes séquentiels (ou concurrents...) d’un processus de calcul  Modélise le comportement interne d’une méthode (d’un seul objet) ou d’un cas d’utilisation (d’une société d’objets)  Une variante du diagramme d’états transition –Diagramme d’États Transition : mis en valeur des états et des transitions –Diagramme d’Activités : mis en valeur des activités et des transitions  Zones d’activités –pour exprimer en analyse de besoin, les grandes étapes du système –pour montrer globalement des interactions avec le temps et les contraintes logiques

77 Conception de Systèmes d’Information – S1 JPmP 1.77 ã  A cause de la nature procédurale des opérations (la plupart des événements correspondent simplement à la fin de l’activité précédente) la distinction systématique entre état, activité et événement est parfois inutile  Les diagrammes d’activités offrent une manière simplifiée pour la visualisation des activités.  Par rapport aux Diagrammes d’Interaction, que mettent en valeur le flux de contrôle entre les objets, les Diagrammes d’Activités mettent en valeur le contrôle d’une activité vers une autre.  Les Diagrammes d’Activités peuvent exister pour qu’on puisse d’une manière indépendante, visualiser, spécifier, construire et documenter la dynamique d’un ensemble d’objets  peuvent aussi servir à modéliser le flux de contrôle d’une opération. Diagrammes d’Activités

78 Conception de Systèmes d’Information – S1 JPmP 1.78 ã Concepts 1  État d’Action et État d’Activité : –États d’Action : représentent un calcul exécutable atomique (ne peut pas être divisé)  des états du système que représentent chacun l’exécution d’une action.  Un État d’Action ne peut pas être décomposé  Un État d’Action est atomique : des événements peuvent se produire sans que l’action réalisée par l’état soit interrompue.  La durée d’exécution de l’action dans un état d’action est considéré non significative. –États d’Activités : sont des états dont l’activité peut éventuellement être représentée par d’autres diagrammes d’activités  un État d’Action peut être considéré comme un cas spécial d’État d’Activité qui ne peut plus être divisé.  Un État d’Activité peut être décomposé  Les États d’Activités ne sont pas atomiques : ils peuvent être interrompus par des événements  La durée d’exécution de l’activité dans un État d’Activité peut être mesuré, elle est significative Étudier devis index:= index + 1 Action simple Expression Début Construction() entry / bloquer() Action d’entre Contrôle Finance(f) Sous-diagramme Diagrammes d’Activités

79 Conception de Systèmes d’Information – S1 JPmP 1.79 ã Concepts 2  États Initial et Final : utilisés au même sens que dans les Diagrammes d’États Transition.  Transition : quand l’action ou activité d’un état se termine, le flux de contrôle passe immédiatement à l’activité suivante  ce flux est indiqué avec les Transitions que permettent de montrer le chemin entre les états d’action ou d’activité.  Division Conditionnelle du Flux : est utilisée pour spécifier les différents chemins qui peut prendre le flux à partir de l’évaluation d’une expression booléenne. –Un division doit avoir une transition entrante et une ou plusieurs transitions sortantes –Chaque transition sortante doit avoir une expression booléenne qui est évalue lorsque la division est atteinte  les conditions de garde de chacune de ces transitions doivent être mutuellement exclusives et doivent couvrir toutes les possibilités pour maintenir le déterminisme –On peut utiliser le mot clef else pour indiquer la transition que doit être suivie dans le cas où aucune autre n’est vrai État d’Action État 1 État 2 État initial État final Transition Ordre début des travails Attribuer taches Replanifier [matériel prêt] [matériel pas prêt] Condition de garde division Diagrammes d’Activités

80 Conception de Systèmes d’Information – S1 JPmP 1.80 ã Concepts 3  Synchronisation de Flux Concurrents: –Utilisées pour représenter la division et le regroupement de flux de contrôle parallèles. –Une fourche concurrente représente la division du flux de contrôle  au dessous de la division, les activités associées aux flux se développent en parallèle. –Une jonction concurrente peut avoir deux ou plus transitions entrantes et généralement une unique sortante  après que toutes les transitions aient atteint la jonction, la transition de sortie est réalisée. Diagrammes d’Activités

81 Conception de Systèmes d’Information – S1 JPmP 1.81 ã Concepts 4  Travées : –Est une division que peut être appliquée à un Diagramme d’Activités pour représenter les différents responsabilités d’un mécanisme ou d’une organisation. –Chaque responsabilité est assuré par un ou plusieurs objets et chaque action d’état ou activité est attachée à un une travée en particulier. –Chaque travée est divisée avec des lignes verticales. – Les transitions peuvent traverser les travées.  Flot d’Objet : –Est un ensemble composé d’une relation de dépendance entre un objet et l’action ou l’activité à l’origine de sa création, destruction ou modification. –Présente les objets qui participent au flux de contrôle d’un Diagramme d’Activités. –Peut présenter pour les objets qui participent du diagramme ses états et les valeurs de ses attributs. –Des objets peuvent être connectés à différentes actions d’états ou d’activités  son état est représenté pour faire la différence –Des flots d’objets peuvent être utilisés avec de diagrammes d’activités simples ou en travée. Diagrammes d’Activités

82 Conception de Systèmes d’Information – S1 JPmP 1.82 ã Diagrammes d’Activités – Concepts 4 : Travées et Flot d’Objets flot d’objet travées objet état flot d’objet

83 Conception de Systèmes d’Information – S1 JPmP 1.83 ã DEMARCHE ORIENTEE OBJET  Le domaine d ’étude n ’est pas le système d ’information dans sa globalité (l ’organisation n ’est pas prise en compte). Il est réduit au système informatique. La démarche proposée (à travers UML) vise donc à spécifier et à implanter les fonctions informatisées du système d ’information. A.Expression des besoins A.1 Cas d ’utilisation (Use Case) à partir des fonctions attenduesdu système informatique, établirun diagramme de cas d ’utilisation.A.2 Diagramme de séquence de hautniveaupour chaque cas d ’utilisation, décrirele scénario principal et éventuellementles scénarios secondaires en languenaturelle B.Analyse B.1 diagramme de séquenceintermédiaire«pour chaque diagramme de séquencesde haut niveau construire le diagrammede séquences intermédiaire qui exprimeles demandes de services fondamentalesentre objets.B.2 diagramme de classe intermédiaireconstruire progressivement le diagrammede classes: classes, attributs et associations.Ajouter les classes application et sesopérations (cas d ’utilisation définis dusystème. C.conception C.1diagramme de Séquences Détaillé à chaque diagramme se séquences interm.Construire le D S D: exprimer les demandesde services détaillées entre objets et spécifierleurs paramètres.C.2 Diagramme de Classe Détaillécompléter le diagramme de classeconformément aux Diagrammes de SéquencesDétaillés.C.3 Diagramme de Classes Généraliséprincipes d ’abstraction et de polymorphisme.C.4 Langage de conception D.Implantation

84 Conception de Systèmes d’Information – S1 JPmP 1.84 ã Démarche Orienté Objet Les étapes expression des besoins, analyse et conception sont menées de manière cyclique où les diagrammes d ’état-transition, d ’activité, de séquences… permettent d ’affiner le système informatique(selon des points de vue différents) en introduisant plus de détailles concernant les rôles, les objets, les liens… et par conséquent élargir le périmètre du SI. Conclusion

85 Conception de Systèmes d’Information – S1 JPmP 1.85 ã Etude de Cas

86 Conception de Systèmes d’Information – S1 JPmP 1.86 ã Décrire la Réalisation et son Implantation Diagrammes de Composant, Diagrammes de Déploiement

87 Conception de Systèmes d’Information – S1 JPmP 1.87 ã Diagrammes de Composants  Fournit une vue statique (l’architecture logicielle) représentant la mise en oeuvre d'un système, dessiné sous la forme d'un graphique de composants logiciels connectés par des relations : dépendance, généralisation, association et réalisation.  Éléments : composants (avec plusieurs stéréotypes) et interfaces.  Utilisés pour définir les dépendances et relations entre objets à un niveau “supérieure” à celui du diagramme de classes  les AGLs permettent de créer un lien entre les classes du modèle logique et les composants.  Modélisent la structure du logiciel et montrent les dépendances entre le code source, le code binaire et les composants exécutables, de sorte que l'impact d'une modification puisse être évalué  Les dépendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en évidence la réutilisation de composants.  Le composants peuvent être organisés en packages, qui définissent des sous-systèmes. Sybase® - PowerAMC™ - Modèle Orienté Objet Guide de l'utilisateur Version Janvier 2002

88 Conception de Systèmes d’Information – S1 JPmP 1.88 ã Exemple Diagrammes de Composants Cours UML : UML, le langage de modélisation objet unifié

89 Conception de Systèmes d’Information – S1 JPmP 1.89 ã Diagrammes de Déploiement  Architecture matérielle et répartition logicielle  Éléments : des nœuds (ressources matérielles) et des relations de dépendance et d’association  aussi des composants qui doivent résider sur un nœud et de packages.  Des Diagrammes de Classes centrées sur les nœuds d’un système  Stéréotypes utilisés pour les nœuds : >, >, >  Connections bi-directionnelles avec cardinalités des nœuds et des connections Diagrammes de Classes Diagrammes de Composants Structure du Logiciel Diagrammes de Séquences Diagrammes de Collaboration Diagrammes de États-Transition Diagrammes d’Activités Comportement du Logiciel Diagrammes de Déploiement A la frontière matériel/logiciel du système pour planifier la topologie des processeurs et des périphériques sur lesquels le système tourne

90 Conception de Systèmes d’Information – S1 JPmP 1.90 ã Exemple Diagrammes de Déploiement Cours UML : UML, le langage de modélisation objet unifié


Télécharger ppt "Conception de Systèmes d’Information – S1 JPmP 1.1 ã Etude de Cas SI d ’un bureau d ’étude Hydraulique Michel TOLLENAERE professeur laboratoire GILCO Dominique."

Présentations similaires


Annonces Google