1 / 55

ANALYSE ET CONDUITE DE PROJETS

2. PLAN DU COURS. Partie I : Introduction : (

arleen
Download Presentation

ANALYSE ET CONDUITE DE PROJETS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    1. 1 ANALYSE ET CONDUITE DE PROJETS P. Bourmanne HELMo

    2. 2 PLAN DU COURS Partie I : Introduction : (#3) Présentation Evaluation Les métiers de l’informaticien dans le cadre d’un développement logiciel Buts du cours Partie II : Les méthodes d’analyse : (#17) Le modèle entité-association Le modèle de Bachman Bases de données : généralités Le modèle relationnel Partie III : La modélisation objet avec UML : (#78) Introduction (#80) UML : point de vue statique (diagrammes et notation) (#91) UML : point de vue fonctionnel (diagrammes et notation) (#111) UML : point de vue dynamique (diagrammes et notation) (#138) Tableau récapitulatif (#180) Vers une méthode de développement (#181) Applications (#187)

    3. 3 PARTIE I

    4. 4 INTRODUCTION: PRESENTATION Cours: 2 1.5 1.5 1.5 1.5 1.5 Patricia Bourmanne Laboratoires : 0 2 2 1.5 1.5 0 Patricia Bourmanne Danièle Bayers

    5. 5 SUPPORTS ET REFERENCES Syllabi : « Méthodes d’analyse »; A. Clarinval; septembre 2002 « Initiation aux bases de données »; P. Bourmanne, 2002 « Concepts et méthodes de la programmation par objets»; A. Clarinval; novembre 2002 Livres de référence : « Modélisation objet avec UML », P.A. Muller, éd. Eyrolles, 1997 « UML et C++, guide pratique du développement orienté objet »; R.C. Lee, W.M. Tepfenhart, éd. Prentice Hall, 1998 « Guide pratique du RUP », P. Koll, Ph. Kruchten, CampusPress, 2003 « UML 2 par la pratique », P. Roques, Eyrolles, 2005 « The unified modeling language, user guide », G. Booch, J. Rumbaugh, I. Jacobson, éd. Addison-Wesley, 1999 « UML 2 en concentré, manuel de référence », D. Pilone, éd. O’Reilly «  UML 2 et les design patterns, analyse et conception orientées objet et développement itératif »,C. Larman, éd. Pearson Education

    6. 6 SUPPORTS ET REFERENCES (suite) Diaporamas du cours (P. Bourmanne) Sites : http://www.hemes.be/saint-laurent/informatique/ressources.php http://www.gramme.be/infopb UML : http://www.omg.org/technology/documents/formal/uml.htm http://sparxsystems.com.au/uml-tutorial.html http://sparxsystems.com.au/UML2_tutorial/UML2_Tutorial_Intro.htm

    7. 7 INTRODUCTION: EVALUATION Votre participation active aux cours théoriques et pratiques Vos travaux lors des séances de laboratoires Une interrogation (le lundi 24 novembre) Un examen sur la théorie, des exercices à réaliser, un projet à présenter Modalités : cf. http://www.gramme.be/infopb/coursSL/analyse/evaluations/Modalites_generales.pdf Aucune absence ne sera tolérée Les présences seront prises à chaque foisAucune absence ne sera tolérée Les présences seront prises à chaque fois

    8. 8 INTRODUCTION : METIERS D’INFORMATICIEN Catégories: Développement logiciel Gestion d’un parc informatique Assistance clientèle (technique et/ou logicielle) Formation

    9. 9 INTRODUCTION: METIERS DU DEVELOPPEMENT LOGICIEL Les métiers de l’informaticien dans le cadre d’un développement logiciel: 1) Le chef de projet : responsable de l’élaboration et de la modification du plan de développement logiciel Rôle complexe : Les personnes Le produit = l’objectif Le processus = feuille de route de l’équipe Le projet à gérer, planifier, contrôler, rectifier Le budget Compétences différentes pour être capable d’une ORIENTATION et ADAPTATION dynamiques : Aptitudes techniques Talents de communication Sera jugé sur les résultats Demander aux étudiants le métier d’informaticien qu’ils imaginent faire dans quelques années – regrouper par catégorie Métiers : Développement logiciel Gestion d’un parc informatique Assistance clientèle (assistance technique et/ou logicielle) Formations Début du cours : métiers du développement logiciel Réf. Livre RPU (Kroll et Kruchten) pour les différents métiers Puis : Avant-propos du livre en conclusion Chef de projet : où, quand, qui Analyste : quoi, comment Chef de projet : Personnes : recruter, former, sous-traiter, … Produit = l’objectif Processus = feuille de route de l’équipe Projet : gestion, planification, contrôle Demander aux étudiants le métier d’informaticien qu’ils imaginent faire dans quelques années – regrouper par catégorie Métiers : Développement logiciel Gestion d’un parc informatique Assistance clientèle (assistance technique et/ou logicielle) Formations Début du cours : métiers du développement logiciel Réf. Livre RPU (Kroll et Kruchten) pour les différents métiers Puis : Avant-propos du livre en conclusion Chef de projet : où, quand, qui Analyste : quoi, comment Chef de projet : Personnes : recruter, former, sous-traiter, … Produit = l’objectif Processus = feuille de route de l’équipe Projet : gestion, planification, contrôle

    10. 10 INTRODUCTION: METIERS 2) L’analyste : responsable de définir et de communiquer aux intervenants les fonctionnalités qui sont attendues du système Tâches de haut niveau : Comprendre les besoins des différents intervenants (utilisateurs, investisseur, acheteur, chef de produit, …) Négocier les exigences et faciliter l’acceptation de l’application par le client Documenter, hiérarchiser et communiquer les exigences Implication dans les disciplines suivantes : Modélisation métier/système Gestion et expression des exigences Analyse (= modélisation de la description du problème) Conception (= modélisation de la solution du problème) Intervenants = personne ou entité concernée par un résultat du système: acheteur, chef de produit, investisseur, utilisateurIntervenants = personne ou entité concernée par un résultat du système: acheteur, chef de produit, investisseur, utilisateur

    11. 11 INTRODUCTION: METIERS L’analyste : (suite) Qualités requises : Habileté à gérer les relations entre plusieurs intervenants Bonne compréhension du domaine du problème ou capacité de l’acquérir rapidement Aptitude à communiquer oralement de façon claire et concise Capacité à rédiger succinctement et clairement les exigences Compréhension globale du cycle de vie du développement du logiciel

    12. 12 INTRODUCTION: METIERS 3) L’architecte logiciel : dirige et coordonne les activités techniques (technologies, structure et organisation du système logiciel) tout au long du projet; il est un centre de la communication Rôle pluridisciplinaire : Expérience des problèmes (compréhension approfondie des exigences) et de l’ingénierie logicielle (vision globale du projet, compréhension des technologies, …) Leadership technique ( ? chef de projet : leadership pour les aspects métier et administratif) Sens de la communication Concentration sur les objectifs et la proactivité: pour axer le projet sur les résultats Source de travail : principalement exigences établies par les analystes Doit être capable de cerner rapidement les situations et les problèmes, d’émettre des jugements avisés et critiques en l’absence d’informations complètes Collaboration étroite avec le chef de projet (architecte + chef de projet = gestionnaires) Architecture logicielle: Usage Fonctionnalité Performance Robustesse Réutilisation Compréhensibilité Contraintes et compromis économiques et technologiques Aspects esthétiquesArchitecture logicielle: Usage Fonctionnalité Performance Robustesse Réutilisation Compréhensibilité Contraintes et compromis économiques et technologiques Aspects esthétiques

    13. 13 INTRODUCTION: METIERS L’architecte logiciel : (suite) Architecture logicielle = structure du système logiciel + aspects suivants: Usage Fonctionnalité Performance Robustesse Réutilisation Compréhensibilité Contraintes et compromis économiques et technologiques Aspects esthétiques en se concentrant uniquement sur les décisions de conception importantes (effets à long terme sur les performances, la qualité, l’évolutivité du système)

    14. 14 INTRODUCTION: METIERS 4) Le développeur : chargé de traduire les exigences en code exécutable d’une qualité suffisante Tâches de haut niveau : Comprendre les exigences (notamment par les cas d’utilisation) et les contraintes de conception Maîtriser la technologie d’implémentation et des outils à utiliser Concevoir, implémenter et tester les logiciels et les bases de données Intégrer ses travaux de développement à ceux des autres développeurs Être créatif en restant rationnel Veiller à la qualité Collaboration étroite : avec l’architecte pour garantir que la conception respecte l’architecture globale avec l’analyste pour lui faire part d’incohérences ou de lacunes au niveau des exigences ; l’analyste pourra alors procéder aux corrections nécessaires

    15. 15 INTRODUCTION: METIERS 5) Le testeur : chargé de l’évaluation de la qualité du logiciel et du respect des objectifs Mission : évaluer le produit logiciel en fonction de critères appropriés (qualité perçue, conformité aux normes, découverte de défauts, …) Communiquer ses évaluations aux développeurs, aux managers, éventuellement aux clients résoudre les conflits entre les différentes visions d’une « bonne qualité » (rôle ingrat : coût de la qualité) Amener éventuellement l’équipe à se rendre compte que les spécifications n’étaient pas complètes Détecter les conditions exceptionnelles qui pourraient rendre le logiciel inutilisable Être accusé d’ignorer le facteur de coût à force de vouloir être perfectionniste dans la qualité (que l’on peut toujours améliorer) Normes : Standard d’ergonomie (ex : apparence du produit « comme Windows 2000 ») Normes médicales, de cartographie, …Être accusé d’ignorer le facteur de coût à force de vouloir être perfectionniste dans la qualité (que l’on peut toujours améliorer) Normes : Standard d’ergonomie (ex : apparence du produit « comme Windows 2000 ») Normes médicales, de cartographie, …

    16. 16 INTRODUCTION: METIERS Un rôle peut être tenu par une ou plusieurs personnes Une personne peut endosser plusieurs rôles, entièrement ou partiellement Remarque : Travail d’équipes n’entraîne pas une absence d’autonomie Membres de l’équipe travaillent de concert Parler du savoir-être de l’informaticienRemarque : Travail d’équipes n’entraîne pas une absence d’autonomie Membres de l’équipe travaillent de concert Parler du savoir-être de l’informaticien

    17. 17 INTRODUCTION : BUTS DU COURS Vous amener à être capable d’analyser un problème, une situation à modéliser Par ce cours et vos cours de programmation: vous amener à être capable de concevoir un logiciel de qualité: Correct : répond aux spécifications Robuste : résiste aux situations difficiles Extensible : peut être amélioré et étendu Réutilisable : peut être utilisé par d’autres logiciels Vous amener à communiquer Cf. avant-propos de RUP - Correct et robuste : pgm fiable - Extensible : pgm souple, résistant aux changements A la fin, demander aux étudiants d’écrire sur une feuille le métier d’informaticien logiciel dans lequel ils se voient le mieux dans quelques années et pourquoi ce choixCf. avant-propos de RUP - Correct et robuste : pgm fiable - Extensible : pgm souple, résistant aux changements A la fin, demander aux étudiants d’écrire sur une feuille le métier d’informaticien logiciel dans lequel ils se voient le mieux dans quelques années et pourquoi ce choix

    18. 18 INTRODUCTION : BUTS DU COURS (suite) Vous sensibiliser et vous former à la qualité : Conférence « Espace Horizon Qualité » par l’ASBL « Entreprise & Qualité » (le 16/09/2008 3ème info) Idées principales (cf. folder fourni) : Exigence de chaque client : « La qualité pour tous et partout » Qualité = atteinte de la satisfaction des clients internes et externes Qualité est un besoin universel et vital est la réponse adaptée à un ensemble de besoins (qui évoluent) ne s’improvise pas, se construit chaque jour La recherche de la qualité: se trouve à tous les niveaux de l’organisation et chacun y tient une responsabilité n’est pas une recherche du coupable, mais la recherche du progrès continu Apprentissage des principes du RUP (processus de développement logiciel)

    19. 19 ET VOUS ? Dans quelle catégorie métier vous voyez-vous le mieux actuellement ? Pourquoi ? Si vous travaillez dans le développement logiciel, quel métier vous semble le mieux convenir à votre idéal ? Pourquoi ?

    20. 20 PARTIE II

    21. 21 CONCEPT DE DONNEE 1. D’une façon générale, tout ce qui est manipulé par un ordinateur est appelé DONNEE. 2. Une DONNEE ELEMENTAIRE décrit un élément atomique du monde réel. 3. On appelle STRUCTURE DE DONNÉES l'association d'un ou plusieurs noms et d'un ensemble de données élémentaires auxquelles ce ou ces noms permettent d'accéder. 1) Données : 1500 € ? salaire, prix, …. 3 ans ? âge, durée d’études, … 2) Structure de données : employé : nom, prénom, salaire, ancienneté, … étudiant : nom, prénom, ddn, localité, …1) Données : 1500 € ? salaire, prix, …. 3 ans ? âge, durée d’études, … 2) Structure de données : employé : nom, prénom, salaire, ancienneté, … étudiant : nom, prénom, ddn, localité, …

    22. 22 TYPE (ABSTRAIT) DE DONNEES Quand un informaticien développe un programme, il est normal, qu'au départ, il ne se préoccupe pas de la représentation physique des données. On parle alors de TYPE ABSTRAIT DE DONNÉES. Celui-ci définit la syntaxe de la donnée ou de la structure de données et les opérations que l'on va effectuer sur ce type de données ou de structure. Int : ordre des bytes différent selon l’OS Structure : alignement, padding Entier : opérations : +, -, * , / , %Int : ordre des bytes différent selon l’OS Structure : alignement, padding Entier : opérations : +, -, * , / , %

    23. 23 NOTION D’ENTITE ENTITÉ = concept concret ou abstrait qui présente un intérêt pour les besoins de gestion de l'entreprise. Il est affecté d’un NOM et porteur de PROPRIETES (données élémentaires). INSTANCE D’ ENTITE = un élément particulier d'un type d'entités, caractérisé par un identifiant et des valeurs des propriétés. IDENTIFIANT = propriété ou ensemble de propriétés qui définit une et une seule instance d'un type d'entité. Entité = concept : concrétisation du réel perçu Exemples : concret : client (nom, adresse, …) abstrait : mariage (nom homme, nom femme, date mariage, localité mariage) Identifiants : Exemples : employé – identifiant = matricule ou (nom,prénom1,prénom2) Déterminer ensemble des identifiants de ETUDIANT : - numéro de matricule - nom, prénoms1,2,3 - nom,prénom,adresseEntité = concept : concrétisation du réel perçu Exemples : concret : client (nom, adresse, …) abstrait : mariage (nom homme, nom femme, date mariage, localité mariage) Identifiants : Exemples : employé – identifiant = matricule ou (nom,prénom1,prénom2)Déterminer ensemble des identifiants de ETUDIANT : - numéro de matricule - nom, prénoms1,2,3 - nom,prénom,adresse

    24. 24 NIVEAUX D’ABSTRACTION 3 niveaux de représentation : MCD : règles de construction et règles sémantiques. Par exemple : a) en cartographie, un MCD peut dire : une surface est déterminée par les lignes qui l’entourent Une ligne est déterminée par son point début et son point fin [Montrer transparents d’EDIGEO] b) Ordinateur : boîtier, carte mère, carte graphique, … c) Un client (d’une banque) possède un compte : - vue: au guichet : fiche visualisée : nom + adresse + numéro compte à vue - MCD : règle sémantique : 1 compte a un seul titulaire - niveau physique : BD ORACLE - niveau interne : très technique (accès, organisation, index,…)MCD : règles de construction et règles sémantiques. Par exemple : a) en cartographie, un MCD peut dire : une surface est déterminée par les lignes qui l’entourent Une ligne est déterminée par son point début et son point fin [Montrer transparents d’EDIGEO] b) Ordinateur : boîtier, carte mère, carte graphique, … c) Un client (d’une banque) possède un compte : - vue: au guichet : fiche visualisée : nom + adresse + numéro compte à vue - MCD : règle sémantique : 1 compte a un seul titulaire - niveau physique : BD ORACLE - niveau interne : très technique (accès, organisation, index,…)

    25. 25 LES NIVEAUX D’ABSTRACTION Le NIVEAU EXTERNE correspond à la vision particulière de chaque utilisateur par rapport au système d'informations de l'entreprise. Il est évident que chacune de ces vues externes est incomplète et partielle. Chaque utilisateur peut travailler sur des données différentes ou sur des données communes à d'autres utilisateurs. Le NIVEAU CONCEPTUEL ou schéma conceptuel constitue la synthèse de tous les schémas externes intégrés dans un schéma unique qui est un invariant de l'organisation, car il est indépendant des traitements et du type d'organisation des données choisi. Il va regrouper toutes les données élémentaires, tous les objets recensés dans les vues externes, toutes les associations entre objets et éventuellement toutes les règles auxquelles doivent satisfaire toutes les données.

    26. 26 LES NIVEAUX D’ABSTRACTION Le NIVEAU ORGANISATIONNEL OU LOGIQUE constitue une étape intermédiaire entre le niveau conceptuel et le niveau interne. La description logique des données devra par exemple tenir compte du type de base de données choisie, mais s'affranchira encore de la représentation spécifique en mémoire des données élémentaires par exemple. Le NIVEAU INTERNE ou schéma physique décrit les choix d'organisation physique des données (fichiers, BD, méthodes d'accès, types d'index...).

    27. 27 MODELE : DEFINITIONS Modèle conceptuel de données (MCD) : Ensemble de règles de structuration ou de modélisation de l'information . Ensemble de règles qui permet de passer du concret inaccessible (l'univers réel) à un abstrait manipulable . Un modèle ne doit pas seulement décrire l'organisation des données, mais aussi la façon dont on opère sur ces données ; il peut être perçu comme un ensemble de structures avec un ensemble d'opérations définies dessus . http://www.grappa.univ-lille3.fr/polys/access-1997/node28.html pour exemples Cours BD de Mathy : . Le schéma conceptuel: description de la sémantique des structures de données · Le schéma logique: description des structures de données telles qu'elles sont perçues par le programmeur (description liée au SGBD) · Le schéma physique: description des techniques d'implémentation des structures logiques (performance en temps et en espace)http://www.grappa.univ-lille3.fr/polys/access-1997/node28.html pour exemples Cours BD de Mathy : . Le schéma conceptuel: description de la sémantique des structures de données · Le schéma logique: description des structures de données telles qu'elles sont perçues par le programmeur (description liée au SGBD) · Le schéma physique: description des techniques d'implémentation des structures logiques (performance en temps et en espace)

    28. 28 METHODES D’ANALYSE: UTILITE Une méthode définit une démarche reproductible pour obtenir des résultats fiables Une méthode définit généralement une représentation (souvent graphique) qui permet: de manipuler aisément les modèles de communiquer et d’échanger l’information entre les différents intervenants - Cuisiniers : recettes de cuisine- Cuisiniers : recettes de cuisine

    29. 29 METHODES D’ANALYSE: LE MODELE ENTITE-ASSOCIATION Le modèle entité-association exprime la sémantique des données à l’aide des concepts: - d’entité - d’association entre entités - d’attribut décrivant les entités et associations

    30. 30 DEFINITION CONCEPTUELLE DE DONNEES : le modèle entité-association 1. ASSOCIATION = un lien logique entre 2 entités ou plus. Elle est souvent définie par un verbe ou un nom (lien sémantique) et une ou plusieurs propriétés. 2. CARDINALITÉS d'une entité dans une association qui le lie à une autre entité = le nombre minimum et le nombre maximum d'instances de l'association auxquelles doit être rattachée chacune des instances de l'entité. Entité : concept concret ou abstrait qui permet de modéliser une situation réelle: Client – commande – produit – facture Bibliothèque – livre – édition – exemplaires (http://www.grappa.univ-lille3.fr/polys/access-1997/node28.html) Fait associatif : exemple : client possède compte Exemples : Ouvrages-auteurs Clients-facturesEntité : concept concret ou abstrait qui permet de modéliser une situation réelle: Client – commande – produit – facture Bibliothèque – livre – édition – exemplaires (http://www.grappa.univ-lille3.fr/polys/access-1997/node28.html) Fait associatif : exemple : client possède compte Exemples : Ouvrages-auteurs Clients-factures

    31. 31 A FAIRE A DOMICILE Lire « Méthodes d’analyse »; A. Clarinval; septembre 2002 : chap. 3.1 : Le modèle entité-association « Initiation aux bases de données »; P. Bourmanne, 2002 : chap. 2 : Les données

    32. 32 DEFINITION LOGIQUE DES DONNEES : le diagramme de Bachman Enregistrement logique Entité ( = record = segment) avec ses champs (= fields) avec ses propriétés Lien Association diagramme de Bachman Exemples : N-1 : Clients ? factures N-N : ouvrages ? signatures et auteurs ? signatures N-N : vente de produits par des fournisseurs : produits ? tarifs et fournisseurs ? tarifs + donner les propriétés (insister sur le prix dans vente dans l’exemple 3)Exemples : N-1 : Clients ? factures N-N : ouvrages ? signatures et auteurs ? signatures N-N : vente de produits par des fournisseurs : produits ? tarifs et fournisseurs ? tarifs

    33. 33 DIAGRAMME DE BACHMAN Règles de transformation d’un modèle entité-association en un diagramme de Bachman : 1 entité ? 1 segment (propriétaire ou membre) segment propriétaire segment membre cardinalité (0,1) ou (1,1) 1 association porteuse d’au moins une cardinalité (0,1) ou (1,1) ? 1 lien 1 association totalement porteuse de cardinalités (0,N) ou (1,N) ? 1 segment membre + liens (autant de liens que d’entités associées à l’association)

    34. 34 A FAIRE A DOMICILE Lire « Méthodes d’analyse »; A. Clarinval; septembre 2002 : chap. 4 : Schéma logique du stockage des données « Initiation aux bases de données »; P. Bourmanne, 2002 : chap. 5.3. : Types de bases de données

    35. 35 Bases de données : généralités

    36. 36 Base de données : définition Ensemble structuré de données enregistrées sur des supports accessibles par l'ordinateur, représentant des informations du monde réel et pouvant être interrogé et mis à jour par une communauté d'utilisateurs. Fichiers informatiques regroupant un ensemble d’informations thématiques sous forme structurée et indexée.

    37. 37 Système de gestion de base de données Logiciel général qui permet à l'utilisateur, qu'il soit programmeur ou utilisateur final, de manipuler les données dans des termes abstraits, sans tenir compte de la façon dont l'ordinateur les voit. Un SGBD est un logiciel parmi les plus complexes que l'on trouve sur le marché. Un SGBD est un logiciel parmi les plus complexes que l'on trouve sur le marché.

    38. 38 Objectifs d’un S.G.B.D. Indépendance physique des programmes aux données : indépendance entre structures de stockage et structures des données du monde réel, indépendance entre schéma interne et conceptuel Indépendance logique des programmes aux données : possibilité de modifier un schéma externe (vue) sans modifier le schéma conceptuel et inversément Manipulation des données par des langages non procéduraux Administration facilitée des données (fcts pour définir les données et changer leur définition) Cfr. Chap. 3 de Gardarin (Bases de données) indép. Phys : on peut ajouter un index, regrouper 2 fichiers, … (= monde des informaticiens) sans que l’utilisateur ne le voit. Indép. Logique : ? indépendance entre les utilisateurs (vues différentes) Manip. Des données : doit pouvoir se faire par des non informaticiens (interrogation et mise à jour) Adm. Des données : évolution va vers le dévt d’outils intégrés capables de faciliter l’adm. des données et d’assurer la cohérence des descriptionsCfr. Chap. 3 de Gardarin (Bases de données) indép. Phys : on peut ajouter un index, regrouper 2 fichiers, … (= monde des informaticiens) sans que l’utilisateur ne le voit. Indép. Logique : ? indépendance entre les utilisateurs (vues différentes) Manip. Des données : doit pouvoir se faire par des non informaticiens (interrogation et mise à jour) Adm. Des données : évolution va vers le dévt d’outils intégrés capables de faciliter l’adm. des données et d’assurer la cohérence des descriptions

    39. 39 Objectifs d’un S.G.B.D. Efficacité des accès aux données (débit + temps de réponse) Partage des données Cohérence des données contrainte d’intégrité (= règle spécifiant les valeurs permises pour certaines données, éventuellement en fonction d’autres données, et permettant d’assurer une certaine cohérence de la base de données) : - unicité de clé - contrainte référentielle - contrainte de domaine Redondance contrôlée des données Sécurité des données (confidentialité + cohérence si panne : une transaction doit être totalement exécutée ou pas du tout) - Efficacité des accès : Débit = nb de transactions exécutées par seconde + Temps de réponse = temps d’attente moyen pour une requête ? il faut partager les ressources entres les différents utilisateurs partage : 1. dans le temps 2. Simultanément (réservation en même temps de la même place d’avion ? SGBD doit faire comme si séquentiel dans le temps) Cohérence : contraintes d’intégrité : valeur dans un domaine, intégrité référentielle, … contrainte d’intégrité : - unicité de clé - contrainte référentielle - contrainte de domaine redondance : les fichiers + ou – redondants seront intégrés dans un seul fichier partagé par les diverses applications Parfois bonne pour augmenter les performances, mais copie doit être invisible pour l’utilisateur (la redondance doit être gérée par le SGBD) Sécurité : droits d’accès + cohérence si panne (ex : prof modifie ses cotes par un facteur 1.1) - Efficacité des accès : Débit = nb de transactions exécutées par seconde + Temps de réponse = temps d’attente moyen pour une requête ? il faut partager les ressources entres les différents utilisateurs partage : 1. dans le temps 2. Simultanément (réservation en même temps de la même place d’avion ? SGBD doit faire comme si séquentiel dans le temps) Cohérence : contraintes d’intégrité : valeur dans un domaine, intégrité référentielle, … contrainte d’intégrité : - unicité de clé - contrainte référentielle - contrainte de domaine redondance : les fichiers + ou – redondants seront intégrés dans un seul fichier partagé par les diverses applications Parfois bonne pour augmenter les performances, mais copie doit être invisible pour l’utilisateur (la redondance doit être gérée par le SGBD) Sécurité : droits d’accès + cohérence si panne (ex : prof modifie ses cotes par un facteur 1.1)

    40. 40 Fonctions d’un S.G.B.D. Description des données : commandes pour définir les schémas interne, conceptuel et externe Recherche des données : commandes pour retrouver les données de la base répondant à un critère plus ou moins complexe (= qualification = expression logique de critères simples, chaque critère permettant soit de comparer un attribut à une valeur, soit de parcourir une association ) Mise à jour des données : commandes pour insérer des données dans la base, modifier des données, supprimer des données Fonctions qui assurent les objectifs précités (transformation des données, contrôle de l’intégrité des données, gestion de transactions et sécurité) - qualification : permet d’exprimer une condition qui doit satisfaire les résultats d’une question- qualification : permet d’exprimer une condition qui doit satisfaire les résultats d’une question

    41. 41 TYPES DE BD Modèle hiérarchique Modèle réseau Modèle relationnel

    42. 42 LE MODELE RELATIONNEL Introduit par Codd Résultat d'une approche formelle mathématique qui modélise dans une même théorie la notion de données et de manipulations de données et ne fait aucune référence au niveau physique Permet de répondre aux objectifs précités

    43. 43 Bibliothèque (hypothèse : 1 auteur/livre) montrer l’exemple des livres d’une bibliothèque (table) et demander de critiquer cette façon de stocker les données Faire le modèle entité-association + Bachmanmontrer l’exemple des livres d’une bibliothèque (table) et demander de critiquer cette façon de stocker les données Faire le modèle entité-association + Bachman

    45. 45 Définitions ATTRIBUT : champ ou propriété du lot d'informations RELATION (ou TABLE) : liste d'attributs a1, a2, ..., an; ensemble de lignes du tableau défini par les attributs. Notation : r(a1, a2, ..., an) où r est le nom de la relation

    46. 46 Définitions TUPLE (ou LIGNE) : ligne du tableau, instance du lot d'informations. Une relation est donc un ensemble de tuples et elle ne possède pas deux tuples identiques. COLONNE : attribut ou ensemble des valeurs de l'attribut

    47. 47 Définitions DOMAINE : ensemble de définition des valeurs des attributs. Soit r(a1, a2, ..., ai, ..., an) une relation, la liste des domaines: D1, D2, ...,Di, ..., Dn dans laquelle Di est le domaine de l'attribut ai. La relation r est un sous-ensemble du produit cartésien: D1 x D2 x ... x Di x ... x Dn.

    48. 48 Définitions ARITE d'une relation : nombre de ses attributs. La relation r(a1, a2, ..., ai, ..., an) est d'arité n. L'arité d'une relation est aussi le nombre de colonnes de la table. CARDINALITÉ d'une relation r : nombre de tuples (ou de lignes) de la table.

    49. 49 Définitions CLÉ D'UNE RELATION r: ensemble d'attributs dont les valeurs identifient un tuple et un seul de la relation r. Une relation possède toujours au moins une clé, c'est-à-dire l'ensemble de ses attributs: deux tuples d'une relation diffèrent entre eux au moins par les valeurs d'un attribut. 

    50. 50 Définitions CLÉ CANDIDATE : clé d'une relation telle que tout sous-ensemble d'attributs de cette clé n'est pas une clé. Une clé candidate constitue donc un sous-ensemble minimal d'attributs pouvant jouer le rôle de clé.   CLÉ PRIMAIRE : la clé unique qui sera retenue parmi les clés candidates. Par la suite, la clé primaire d'une relation sera désignée par le terme « clé ».

    51. 51 Définitions CLÉ ETRANGERE dans une table : clé primaire ou candidate dans une autre table

    52. 52 Définitions CONTRAINTES D'INTÉGRITÉ : règles sémantiques auxquelles les données d’une base doivent obéir. Elles font partie du schéma conceptuel. But : garantir la cohérence des données lors des mises à jour de la base (les données ne sont pas indépendantes)

    53. 53 Définitions Contrainte d’intégrité : Contrainte de domaine : exprime la sémantique des données au moyen de propriétés vérifiées par les attributs Contrainte d’intégrité d’entité : une table doit toujours avoir une clé primaire Contrainte d’intégrité référentielle : toute valeur attribuée à une clé étrangère dans une table doit exister dans la table où cette clé se retrouve comme clé primaire ou candidate Par exemple dans la relation r (employé, salaire, patron): "un salaire est compris entre 1 000 et 2 000 €" "un employé n'a qu'un seul patron" "un patron a au plus 15 employés" sont des contraintes d'intégrité définies sur la relation r.

    54. 54 ALGEBRE RELATIONNELLE Elle définira un cadre formel pour la définition d'un langage de manipulation de données dont les primitives seront les opérations de base. Ces primitives constitueront des opérations de haut niveau comparables à certains traitements classiques de fichiers (tri, fusion, extraction, édition)

    55. 55 Somme et différence La somme de deux relations r et s, notée r È s est l'union ensembliste des tuples de r et des tuples de s. La différence r - s est l'ensemble des tuples de r qui n'appartiennent pas à s. Les deux relations doivent avoir même arité. Dans la pratique, pour que la somme ait un sens, les attributs de même rang de r et s doivent avoir le même domaine. Toujours demander : arité = combien ? Cardinalité = ? Les deux relations doivent avoir même arité. Dans la pratique, pour que la somme ait un sens, les attributs de même rang de r et s doivent avoir le même domaine. Toujours demander : arité = combien ? Cardinalité = ?

    56. 56 Produit cartésien Soient les relations r et s d'arités respectives k1 et k2. Le produit cartésien r X s est la relation d'arité k1 + k2 dont les tuples sont le résultat de la concaténation des tuples de r avec ceux de s. Cardinalité = card1 * card2Cardinalité = card1 * card2

    57. 57 Projection Projection Ps(r) d'une relation r sur un sous-ensemble s de ses attributs : relation obtenue en supprimant dans la table les colonnes des attributs qui n'appartiennent pas à s et en ne gardant dans la nouvelle table ainsi définie qu'une seule occurrence de chaque tuple.

    58. 58 Sélection Soit : un ensemble d'opérateurs arithmétiques et logiques: =, ¹, <,>, OU, ET, NON des opérandes: attributs et constantes une formule F définie sur les attributs de r par les opérateurs et les opérandes. La sélection définie par F sur r, notée sF (r), est une relation, ensemble des tuples de r qui vérifient la formule F.

    59. 59 F1 : secteur = 17 et vente > 4 000 F2 : date <= 3/02 et vendeur = JFDF1 : secteur = 17 et vente > 4 000 F2 : date <= 3/02 et vendeur = JFD

    60. 60 Intersection Intersection de 2 tables r1 Ç r2 = r1 - ( r1 - r2) est définie comme une table qui est constituée des tuples communs aux relations r1 et r2

    61. 61 Jointure Jointure de 2 relations r et s suivant la relation i q j (? est un opérateur, i et j les rangs des attributs respectivement dans r et s) : ensemble des tuples du produit cartésien r x s qui satisfont la relation i ? j. On la note : r Ä s i q j i et j peuvent être remplacés par le nom des attributs correspondants. Cas particulier : équijointure r Ä s i = j

    62. 62 Schéma relationnel Règles de transformation d’un diagramme de Bachman en un schéma relationnel : Tout segment est transposé en une relation Une relation issue d'un segment propriétaire se voit attribuer, comme clé, l'identifiant du segment et comme propriétés les attributs du segment. Une relation issue d'un segment membre ayant un identifiant, se voit attribuer, comme clé, l'identifiant du segment et comme propriétés les attributs du segment ainsi que le ou les identifiants du ou des segments propriétaires. Une relation issue d'un segment membre n'ayant pas d'identifiant, se voit attribuer, comme clé, le ou les identifiants du ou des segments propriétaires et comme propriétés les attributs du segment membre.

    63. 63 Les formes normales

    64. 64 Bibliothèque (hypothèse : 1 auteur/livre) Rappel des notions vues : vocabulaire : attribut, arité, … demander de critiquer cette façon de stocker les données 3 modèles pour 1 livre/auteurRappel des notions vues : vocabulaire : attribut, arité, … demander de critiquer cette façon de stocker les données 3 modèles pour 1 livre/auteur

    65. Rappel d’algèbre relationnelle : - Décomposition par projection - Recomposition par jointureRappel d’algèbre relationnelle : - Décomposition par projection - Recomposition par jointure

    66. 66 Décomposition d'une relation universelle Relation universelle : Table unique dont le schéma est composé par union de tous les attributs des tables constituant la base Décomposition : Remplacement d’une relation R(A1,A2, …,Am) par une collection de relations R1, R2, …, Rn obtenues par des projections de R sur des sous-ensembles d’attributs dont l’union contient tous les attributs de R Décomposition sans perte : Décomposition d’une relation R en R1, R2, …, Rn telle que on ait : R = R1 Ä R2 Ä … Rn

    67. 67 Relation Voiture

    68. 68 Décomposition 1

    69. 69 Décomposition 2 Peut-on retrouver le type, la marque, la puissance, la couleur de chaque voiture ?Peut-on retrouver le type, la marque, la puissance, la couleur de chaque voiture ?

    70. Relations Vin1 et Vin2 Impossible de retrouver :- le degré d’un vin de numéro donné - la qualité d’un cru d’une année particulière exemple BD école et société (relation universelle, puis 3 schémas – d’abord 1 école, 1 société, puis n et n ) (table au tableau à faire ensemble : NN, nom, prénom, ddn, école,info école,société,info société) On peut : - soit envisager la décomposition directement - soit faire le MCD, puis revenir au relationnel Exemple Vente de produits (table au tableau à faire ensemble: code_fournisseur, code_produit, description_produit, prix_produit, adresse_fournisseur) (relation universelle, puis 3 schémas) Impossible de retrouver :- le degré d’un vin de numéro donné - la qualité d’un cru d’une année particulière exemple BD école et société (relation universelle, puis 3 schémas – d’abord 1 école, 1 société, puis n et n )(table au tableau à faire ensemble : NN, nom, prénom, ddn, école,info école,société,info société) On peut : - soit envisager la décomposition directement - soit faire le MCD, puis revenir au relationnel Exemple Vente de produits (table au tableau à faire ensemble: code_fournisseur, code_produit, description_produit, prix_produit, adresse_fournisseur) (relation universelle, puis 3 schémas)

    71. 71 Dépendance fonctionnelle Dépendance fonctionnelle : Soit une relation R(A1,A2, …, An), et X et Y des sous-ensembles de {A1,A2, …, An}. Y dépend fonctionnellement de X (X?Y) si pour tout tuple t1 et t2 de R, on a : ?X(t1) = ?X(t2) => ?Y(t1) = ?Y(t2) Clé de relation : Sous-ensemble X des attributs d’une relation R(A1,A2, …, An) tel que  X ? A1 A2 … An Il n’existe pas de sous-ensemble Y ? X tel que Y ? A1 A2 … An   Exemples : Livres voituresExemples : Livres voitures

    72. 72 Dépendance fonctionnelle Dépendance fonctionnelle élémentaire: Dépendance fonctionnelle de la forme X ? A, où A est un attribut unique n’appartenant pas à X et où il n’existe pas X’ ? X tel que X’ ? A Ecrire les dépendances F élém. trouvées ensemble au tableau (graphe-entourer les noms pour ne pas confondre avec Bachman) : exemple biblio : titre ? date achat, titre ? prix TVAC, titre ? auteur, auteur ? info auteur ; par transitivité : titre ? info auteur exemple voiture : NV ? type, NV ? couleur, type ? marque, type ? puissance ; par transitivité : NV ? marque, NV ? puissance Ecrire les dépendances F élém. trouvées ensemble au tableau (graphe-entourer les noms pour ne pas confondre avec Bachman) : exemple biblio : titre ? date achat, titre ? prix TVAC, titre ? auteur, auteur ? info auteur ; par transitivité : titre ? info auteur exemple voiture : NV ? type, NV ? couleur, type ? marque, type ? puissance ; par transitivité : NV ? marque, NV ? puissance

    73. 73 Forme normale 1 Père (numéro national, nom, prénom, prénom_enfants) Autres exemples : personne (NN,nom,prénom, professions) personne (NN,nom,prénom,sports_pratiqués) Autres exemples : personne (NN,nom,prénom, professions) personne (NN,nom,prénom,sports_pratiqués)

    74. 74 Forme normale 1

    75. 75 Forme normale 2 Tarif (nom, adresse, article, prix) déterminer ensemble la clé, les DF : Q : que pensez-vous de cette relation ? clé ? DF ? quel pourrait être le problème de cohérence de BD ? RA : adresse dépend fonctionnellement de nom et pas d’article. Q : que faut-il faire pour éviter ce problème de redondance, source d’incohérence ? RA : décomposition de la relation déterminer ensemble la clé, les DF : Q : que pensez-vous de cette relation ? clé ? DF ? quel pourrait être le problème de cohérence de BD ? RA : adresse dépend fonctionnellement de nom et pas d’article. Q : que faut-il faire pour éviter ce problème de redondance, source d’incohérence ? RA : décomposition de la relation

    76. 76 Forme normale 2 1. Au tableau (schéma d’une relation R) : R : K1 K2 X Y clé K = K1,K2 K ? X K2 ? Y D’où la décomposition en 2 relations (R1(K1,K2,X) et R2(K2,Y)) 2. Discussion sur la suppression (l’ajout) de tuple de R1 ou R2 : suppression R1 OK, R2 NOK ajout R1 NOK, R2 OK Conclusion : Tout nom de R1 doit apparaître dans R2 (intégrité référentielle), mais tout nom de R2 ne doit pas nécessairement apparaître dans R1 1. Au tableau (schéma d’une relation R) : R : K1 K2 X Y clé K = K1,K2 K ? X K2 ? Y D’où la décomposition en 2 relations (R1(K1,K2,X) et R2(K2,Y)) 2. Discussion sur la suppression (l’ajout) de tuple de R1 ou R2 : suppression R1 OK, R2 NOK ajout R1 NOK, R2 OK Conclusion : Tout nom de R1 doit apparaître dans R2 (intégrité référentielle), mais tout nom de R2 ne doit pas nécessairement apparaître dans R1

    77. 77 Forme normale 3 Vente(date, vendeur, nom_client, adresse_client) Q : que pensez-vous de cette relation ? DF ? quel pourrait être le problème de cohérence de BD ? RA : adresse client fonctionnellement de nom client. Q : que faut-il faire pour éviter ce problème de redondance, source d’incohérence ? RA : décomposition de la relation Q : que pensez-vous de cette relation ? DF ? quel pourrait être le problème de cohérence de BD ? RA : adresse client fonctionnellement de nom client. Q : que faut-il faire pour éviter ce problème de redondance, source d’incohérence ? RA : décomposition de la relation

    78. 78 Forme normale 3 1. Au tableau (schéma d’une relation R) : R : K X Y Z K ? X, K? Y, K ? Z X ? Z D’où la décomposition en 2 relations (R1(K,X,Y) et R2(X,Z)) 2. Discussion sur la suppression (l’ajout) de tuple de R1 ou R2 : supression R1 OK, R2 NOK ajout R1 NOK, R2 OK Conclusion : Tout nom de R1 doit apparaître dans R2 (intégrité référentielle), mais tout nom de R2 ne doit pas nécessairement apparaître dans R2 3. Exemple voiture : pas en 3NF ? décomposition1. Au tableau (schéma d’une relation R) : R : K X Y Z K ? X, K? Y, K ? Z X ? Z D’où la décomposition en 2 relations (R1(K,X,Y) et R2(X,Z)) 2. Discussion sur la suppression (l’ajout) de tuple de R1 ou R2 : supression R1 OK, R2 NOK ajout R1 NOK, R2 OK Conclusion : Tout nom de R1 doit apparaître dans R2 (intégrité référentielle), mais tout nom de R2 ne doit pas nécessairement apparaître dans R2 3. Exemple voiture : pas en 3NF ? décomposition

    79. 79 Forme normale de Boyce-Codd Q : Bien conçu ? RA : non, car comment encoder un prof (avec le sport associé) si pas encore d’inscrit à son stage ? Q : quelles sont les dépendances fonctionnelles ? quel pourrait être le problème de cohérence de BD ? RA : personne,sport ? entraîneur, entraîneur ? sport Q : que faut-il faire pour éviter ce problème de redondance, source d’incohérence ? RA : décomposition de la relation : stage (personne, entraîneur) entraîneurs (entraîneur, sport) Q : n’y-a-t-il pas perte d’une DF ? RA : oui : personne,sport ? entraîneur   Q : Bien conçu ? RA : non, car comment encoder un prof (avec le sport associé) si pas encore d’inscrit à son stage ? Q : quelles sont les dépendances fonctionnelles ? quel pourrait être le problème de cohérence de BD ? RA : personne,sport ? entraîneur, entraîneur ? sport Q : que faut-il faire pour éviter ce problème de redondance, source d’incohérence ? RA : décomposition de la relation : stage (personne, entraîneur) entraîneurs (entraîneur, sport) Q : n’y-a-t-il pas perte d’une DF ? RA : oui : personne,sport ? entraîneur  

    80. 80 Forme normale de Boyce-Codd Méthode expositive (synthèse) Au tableau (schéma d’une relation R) : R : K1 K2 X Y clé K = K1,K2 K ? X, K? Y X ? K2 D’où la décomposition en 2 relations (R1(K1,X,Y) et R2(X,K2)) Exemple 1: K1 = personne K2 = sport X = entraîneur Y = nb h/jour Perte des DF : K ? X, K? Y Exemple 2: K1 = rue K2 = ville X = code_postal Y = nb maisons Perte des DF : K ? X, K? Y Exercices de décomposition (cfr. Syllabus) : exercices 1 et 5: emprunts de livres : clé DF 1NF,2NF,3NF BCNF Demander de réfléchir à domicile sur l’emprunt de livre (n exemplaires/livre : relation universelle, décomposition) Exercices de MCD : Produits par marque Réservation de terrains de tennis Bar : facturer les boissons consommées pendant un certain temps Méthode expositive (synthèse) Au tableau (schéma d’une relation R) : R : K1 K2 X Y clé K = K1,K2 K ? X, K? Y X ? K2 D’où la décomposition en 2 relations (R1(K1,X,Y) et R2(X,K2)) Exemple 1: K1 = personne K2 = sport X = entraîneur Y = nb h/jour Perte des DF : K ? X, K? Y Exemple 2: K1 = rue K2 = ville X = code_postal Y = nb maisons Perte des DF : K ? X, K? Y Exercices de décomposition (cfr. Syllabus) : exercices 1 et 5: emprunts de livres : clé DF 1NF,2NF,3NF BCNF Demander de réfléchir à domicile sur l’emprunt de livre (n exemplaires/livre : relation universelle, décomposition) Exercices de MCD : Produits par marque Réservation de terrains de tennis Bar : facturer les boissons consommées pendant un certain temps

    81. 81 PARTIE III

    82. 82 PREREQUIS Relire le document ConceptionObjet.pdf de P. Bourmanne (cours de POO)

    83. 83 INTRODUCTION PLAN : Introduction : l’approche objet UML : introduction UML : définition UML : les trois points de vue de la modélisation UML : les diagrammes

    84. 84 Introduction : l’approche objet La métaphore du Client et du Serveur : syllabus « Concepts et méthodes de la programmation par objets » d’A. Clarinval Un programme orienté objets est conçu et réalisé comme un réseau d’objets clients et serveurs les uns des autres, qui s’échangent des messages. Les objets s ’échangent des MESSAGES La RESPONSABILITE est requise auprès de l’objet RECEPTEUR. La responsabilité est déclenchée à la réception d’un message OO : ensemble d’objets qui collaborent entre eux pour mener à bien des activités fonctionnelles La CLASSE porte le nom du CONCEPT métier Si UML ? programmation en OO (et pas en Pascal, C, …) Ex: Un abri de jardin a brûlé. Cela constitue un sinistre. L’objet sinistre demande au contrat d’assurance si l’abri de jardin lui appartient, car lui n’est pas responsable de cette information. Concepts : sinistre, contrat, couverture, sinistré (=abri de jardin) Un homme chotte dans un ballon. Le ballon (selon sa forme ronde, ovale, …) a la responsabilité de rouler (ou non) vers l’endroit voulu .Le ballon modifie son état, il en est responsable. L’homme donne l’énergie au ballon Après UML, voir : - design patterns - refactoring Les objets s ’échangent des MESSAGES La RESPONSABILITE est requise auprès de l’objet RECEPTEUR. La responsabilité est déclenchée à la réception d’un message OO : ensemble d’objets qui collaborent entre eux pour mener à bien des activités fonctionnelles La CLASSE porte le nom du CONCEPT métier Si UML ? programmation en OO (et pas en Pascal, C, …) Ex: Un abri de jardin a brûlé. Cela constitue un sinistre. L’objet sinistre demande au contrat d’assurance si l’abri de jardin lui appartient, car lui n’est pas responsable de cette information. Concepts : sinistre, contrat, couverture, sinistré (=abri de jardin) Un homme chotte dans un ballon. Le ballon (selon sa forme ronde, ovale, …) a la responsabilité de rouler (ou non) vers l’endroit voulu .Le ballon modifie son état, il en est responsable. L’homme donne l’énergie au ballon Après UML, voir : - design patterns - refactoring

    85. 85 UML : introduction UML = Unified Modeling Language (langage unifié pour la modélisation objet) Norme de standardisation des applications développées selon le concept de programmation objet, élaborée en 1994 par les Américains G. BOOCH et J. RUMBAUGH et le Suédois I. JACOBSON pour la société "Rational". Cette norme - basée sur la modélisation et la formalisation de projets informatiques, permettant de quantifier les besoins, ressources et relations existantes entres eux - facilite la ré-utilisation des composants programmés d'une application à l'autre. Standardisé par l’OMG (Object Management Group) depuis 1997 La méthode UML simplifie le processus complexe de conception d'un système informatique en définissant 3 points de vue (9 diagrammes) de modélisation . Utilisé par des centaines de projets dans le monde Indispensable à votre formation d’informaticien Unified : plusieurs méthodologies ont convergé vers UMLUnified : plusieurs méthodologies ont convergé vers UML

    86. 86 UML : définition UML est un langage d’analyse et de conception se basant sur la création de modèles successifs de plus en plus affinés afin de mettre en place une solution au problème étudié. Le cadre de cette modélisation est orienté objet. UML a pour objectif de se rendre indépendant de certaines parties techniques comme par exemple le langage de programmation. Les différentes phases du développement avec UML peuvent être représentées au moyen d’une série de diagrammes permettant de comprendre de manière visuelle les concepts définis. Tous les modèles s’enchaînent en passant de l’analyse à la conception, gagnant en complexité, s’affinant au fur et à mesure pour arriver à l’élaboration finale du modèle. Les diagrammes permettent de comprendre sous différents angles la globalité du cas étudié en présentant une vue fonctionnelle, statique et dynamique de celui-ci. Chaque diagramme exprime une partie de la structure totale, tout en étant un aspect particulier du système. Les diagrammes sont créés par un modélisateur (analyste); ils doivent généralement être validés par un expert métier (non informaticien) UML = moyen d’expression, de communication <> recette, processus de développement logiciel = langue pratiquée dans le processus de développement logiciel (ex. RUP) But UML : automatiser des systèmes d’information, de gestion humains Etapes : 1. comprendre un métier, maîtriser les concepts métier 2. modéliser (abstrait) NB : Abstraction sert à comprendre, à synthétiser, à simplifier ce qu’on a compris ? modéliser sa compréhension du système par UML: CU, diagr. Classes, diagr. Objets, catalogue métier, glossaire Remarques : 1) Approche métier : on voit des objets plutôt que des classes. Ils sont dans leur contexte. Analyse des objets dans leur contexte ? classe = abstraction(essentiel, pas les détails), conceptualisation 2) Le responsable métier donne souvent les détails, ne voit pas l’abstraction; il noie l’analyste de détails UML = moyen d’expression, de communication <> recette, processus de développement logiciel = langue pratiquée dans le processus de développement logiciel (ex. RUP) But UML : automatiser des systèmes d’information, de gestion humains Etapes : 1. comprendre un métier, maîtriser les concepts métier 2. modéliser (abstrait) NB : Abstraction sert à comprendre, à synthétiser, à simplifier ce qu’on a compris ? modéliser sa compréhension du système par UML: CU, diagr. Classes, diagr. Objets, catalogue métier, glossaire Remarques : 1) Approche métier : on voit des objets plutôt que des classes. Ils sont dans leur contexte. Analyse des objets dans leur contexte ? classe = abstraction(essentiel, pas les détails), conceptualisation 2) Le responsable métier donne souvent les détails, ne voit pas l’abstraction; il noie l’analyste de détails

    87. 87 MODELE, ANALYSE ET CONCEPTION Modèle = description abstraite d’un système ou d’un processus représentation simplifiée qui permet de : Comprendre Simuler Modélisation = Description d’un problème : ANALYSE Description de la solution d’un problème : CONCEPTION Analyse : - pas de vérification comme dans la programmation (où compilation, test de l’exécutable) - subjectif (analyste = « écrivain ») Analyse : - pas de vérification comme dans la programmation (où compilation, test de l’exécutable) - subjectif (analyste = « écrivain »)

    88. 88 UML : OBJECTIFS ET UTILISATION Objectif : Fournir une représentation de concepts qui facilite et rende efficace la communication entre les différents protagonistes d’un projet : Informaticiens Experts métier Utilisateurs Utilisations : Analyser et concevoir des logiciels informatiques Communiquer sur des processus logiciels ou d’entreprises Présenter sous forme détaillée l’analyse d’un système (représentation graphique, vue d’un système) Documenter un système, un processus ou une organisation existants

    89. 89 UML : les 3 points de vue de la modélisation FONCTIONNEL diagramme de cas d’utilisation STATIQUE DYNAMIQUE diagramme de classes diagramme d’états diagramme de packages diagramme d’activité diagramme d’objets diagramme de séquence diagramme de structure composite diagramme de collaboration (ou de communication)

    90. 90 UML : les 3 points de vue de la modélisation (suite) Statique: Identifier les concepts du métier, les modéliser en tant que classes Identifier les associations pertinentes entre les concepts Réfléchir aux multiplicités à chaque extrémité d’association Ajouter des attributs aux classes Dynamique: Répertorier tous les messages que les acteurs peuvent envoyer au système et recevoir Fonctionnel: Détailler les différentes façons dont les acteurs peuvent utiliser le système.

    91. 91 UML : diagrammes Point de vue fonctionnel : • Diagramme de cas d’utilisation : Première étape dans le processus de modélisation, un cas d’utilisation décrit textuellement une situation, une fonctionnalité, dans la problématique étudiée. Il s’agit d’un scénario typique accompli par un ou plusieurs objets modélisés. Le diagramme de cas d’utilisation illustre les liens entre les différents cas et les intervenants dans les différents scénarios considérés. Point de vue statique : • Diagramme de classes : Le diagramme de classes a pour caractéristique d’illustrer les différents acteurs, leurs compositions et leurs associations. Une classe est la description d’un groupe d’objets possédant des propriétés communes ainsi que des comportements similaires. L’objet est l’instance d’une classe particulière. Le diagramme de classes est une représentation statique des différentes classes du modèle développé.

    92. 92 UML : diagrammes (suite) Point de vue dynamique : • Diagramme d’états : Ce type de diagramme décrit les différentes transitions d’états qui s’opèrent au cours du temps de vie d’un objet. Un état se caractérise par sa durée et sa stabilité, il représente une conjonction instantanée des valeurs des attributs d'un objet et des liens avec d’autres objets. Les différents états de l’objet sont liés entre eux et leurs transitions sont déclenchées par certains événements. • Diagramme d’activité : Le diagramme d’activité représente les activités qui ont lieu dans le déroulement d’un processus. Ils reprennent des concepts des diagrammes d’états insistant plus sur la modélisation de certaines activités avec des notions de concurrence et de synchronisation. Les différentes activités représentent les réalisations de certaines opérations. Le diagramme permet donc de représenter la succession des opérations au cours des flux de travail (workflows).

    93. 93 UML : diagrammes (suite) • Diagrammes d’interaction : Le comportement dynamique des objets et des acteurs est représenté au moyen des diagrammes d’interaction : a) Diagramme de séquence : Dans ce type de diagramme, il se dégage une structure temporelle des messages qui sont échangés entre les différents objets impliqués dans la réalisation d’un cas d’utilisation. La dimension verticale montre les enchaînements temporels des messages. Les réponses des différents objets aux messages reçus sont aussi clairement représentées et compréhensibles (dynamique de fonctionnement). b) Diagramme de collaboration : Les diagrammes de collaboration sont une autre forme de représentation du comportement dynamique des objets illustrant la réalisation d’un cas d’utilisation. Cette représentation est équivalente, mais elle se focalise davantage sur l’organisation des objets : ils mettent en évidence les relations entre objets par la disposition des objets.

    94. 94 UML : POINT DE VUE STATIQUE PLAN: Concepts et définitions de base: Diagramme de classes Classe et objet Attribut et opération Association Agrégation et composition Généralisation, super-classe, sous-classe Dépendance Package Exercice : diagrammes de classes

    95. 95 DIAGRAMME DE CLASSE Objectif : décrire la structure des entités manipulées par les utilisateurs Représente la structure d’un code orienté objet Représentation : Classes (avec attributs et opérations), reliées par: des associations, ou des généralisations Diagr. De classe : modélisation des concepts du domaine Ex. organes du corps humain : chaque organe assume ses responsabilitésDiagr. De classe : modélisation des concepts du domaine Ex. organes du corps humain : chaque organe assume ses responsabilités

    96. 96 REPRESENTATION D’UNE CLASSE DANS UN DIAGRAMME DE CLASSE UML 2 p. 76 Muller p. 92 et 93UML 2 p. 76 Muller p. 92 et 93

    97. 97 CLASSE ET OBJET Classe : Représente la description abstraite d’un ensemble d’objets possédant les mêmes caractéristiques ? type d’objets Exemples : classe Voiture classe Personne Objet : Entité aux frontières bien définies, possédant une identité et encapsulant un état et un comportement ? instance (occurrence) d’une classe Exemples : ma voiture est une instance de la classe Voiture Ch. Mathy est une instance de la classe Personne Notation d’une classe et d’un objet: Clarinval : concepts p. 12 : Client, Compte Notation d’une classe et d’un objet: Clarinval : concepts p. 12 : Client, Compte

    98. 98 ATTRIBUT ET OPERATION Attribut : Représente un type d’information contenu dans une classe Exemples : cylindrée, numéro d’immatriculation de la classe Voiture Cas particulier : attribut dérivé Opération : Représente un élément de comportement (service) contenu dans une classe Exemples : démarrer(), avancer(), tourner() de la classe Voiture Notation d’une classe avec attributs et opération : Clarinval : concepts p. 11 : Client Attribut dérivé : Muller P. 94 Notation d’une classe avec attributs et opération : Clarinval : concepts p. 11 : Client Attribut dérivé : Muller P. 94

    99. 99 Visibilité des attributs et des opérations + public # protected - private Souligné : static (variables et opérations de classe) Ex. opération privée : un message envoyé à soi-même Attribut : donnée rémanente Donnée manipulée : Dans les effets des diagr. d’états Dans les conditions des diagr. d’étatsEx. opération privée : un message envoyé à soi-même Attribut : donnée rémanente Donnée manipulée : Dans les effets des diagr. d’états Dans les conditions des diagr. d’états

    100. 100 ASSOCIATION Association: Représente une relation sémantique durable entre 2 classes Exemple : la relation possède est une association entre les classes Personne et Voiture : une personne peut posséder des voitures Inversion de la position des cardinalités par rapport au modèle entités-associationsInversion de la position des cardinalités par rapport au modèle entités-associations

    101. 101 ASSOCIATION : caractéristiques L’association est nommée (indication – en italique - sur le type de la relation). Même si le terme qui nomme l’association semble privilégier un sens, une association entre concepts est par défaut bidirectionnelle. Donc, implicitement, l’exemple cité inclut également le fait qu’une voiture est possédée par une personne. Par défaut, un lien est donc navigable dans les 2 sens. Un objet (dit objet utilisateur) peut utiliser les services d’un autre objet (dit objet utilisé) selon le sens de navigation indiqué par l’association. Pour utiliser un service d’un objet, l’objet utilisateur envoie un message à l’objet utilisé. Notation : UML 2 P. 78 Röle : Muller P. 100-101 Exemple d’utilisation : Clarinval : concepts p. 11 : Client et Compte + cout (utilisation du service <<) Pour pouvoir utiliser les services d’un objet : - objet serveur connu mis en accès global (ex. cout) - objet référencé ( = donnée membre de la classe utilisatrice : par valeur, adresse, référence ou identifiant = clé étrangère (espaces distincts)) - objet reçu en paramètre (dépendance vers l’objet reçu) : association momentanée : la référence (pointeur ou identifiant) de l’objet serveur est passé comme paramètre à l’opération clienteNotation : UML 2 P. 78 Röle : Muller P. 100-101 Exemple d’utilisation : Clarinval : concepts p. 11 : Client et Compte + cout (utilisation du service <<) Pour pouvoir utiliser les services d’un objet : - objet serveur connu mis en accès global (ex. cout) - objet référencé ( = donnée membre de la classe utilisatrice : par valeur, adresse, référence ou identifiant = clé étrangère (espaces distincts)) - objet reçu en paramètre (dépendance vers l’objet reçu) : association momentanée : la référence (pointeur ou identifiant) de l’objet serveur est passé comme paramètre à l’opération cliente

    102. 102 ASSOCIATION : caractéristiques (suite) Indication de multiplicité aux 2 extrémités de l’association: intervalle d’entiers >= 0 ou * (= nombre quelconque) : nombre d’objets pouvant participer à la relation avec un objet de l’autre classe. L’indication par défaut (non notée) est 1..1 que l’on peut également noter 1. Exemple : une personne peut posséder entre 0 et un nombre quelconque de voitures; une voiture est possédée par une seule personne Possibilité d’indiquer le rôle joué par chaque objet dans la relation. Ex. entre les classes Societe et Personne : employeur, employe La personne voit la société comme son employeur; la société voit la personne comme son employé En général, les rôles sont indiqués si plusieurs associations relient 2 classes.

    103. 103 Valeurs conventionnelles de multiplicité

    104. 104 AGREGATION Agrégation : cas particulier d’association non symétrique* : une classe joue un rôle prédominant par rapport à l’autre. Exemple courant: agrégation exprimant une relation de contenance. Inutile de nommer cette association : implicitement, elle signifie : contient, est composé de * l’agrégat utilise les services du composant, pas l’inverse Notation = losange plein ou creux Muller : immeuble p. 107 Notation = losange plein ou creux Muller : immeuble p. 107

    105. 105 AGREGATION FORTE: composition Agrégation forte : agrégation non partagée : un élément ne peut appartenir qu’à un seul objet, dit agrégat composite Donc, multiplicité du côté de l’agrégat : 1 Responsabilité de l’agrégat composite concernant le cycle de vie des parties : la destruction de l’agrégat composite entraîne la destruction de tous ses éléments Exemples : le solde d’un compte les dents d’une personne Notation = losange plein Notation = losange plein

    106. 106 AGREGATION FAIBLE Agrégation faible : agrégation partageable L’existence du composant ne dépend pas de celle du composé ? un même composant peut faire partie de plusieurs agrégats Exemples : une équipe sportive est composée de personnes une classe de 2ème info est composée de personnes Notation = losange creux Notation = losange creux

    107. 107 GENERALISATION super-classe : classe plus générale reliée à une ou plusieurs autres classes spécialisées (sous-classes) par une relation de généralisation Les sous-classes héritent des propriétés de leur super-classe et peuvent comporter des propriétés spécifiques supplémentaires Exemples : les voitures, les bateaux, les avions sont des moyens de transport Une classe abstraite ne s’instancie pas. Elle se note en italique. Notation : UML 2 P 79Notation : UML 2 P 79

    108. 108 GENERALISATION : EXEMPLE

    109. 109 DEPENDANCE Relation d’utilisation unidirectionnelle Lien temporaire entre objets : association momentanée Par exemple : un objet A:a reçoit en paramètre d’un message une référence sur un objet C:c ? dépendance de A vers C (A utilise C) A > C Clarinval : Concepts p. 13Clarinval : Concepts p. 13

    110. 110 PACKAGE Package : mécanisme de regroupement d’éléments (classes et associations) Espace de noms Structuration d’un modèle en packages: Cohérence (regroupement des classes selon la sémantique) Indépendance (minimisation des relations entre classes de packages différents) Exemple : package Clientèle et package Voitures Notation : UML 2 p 80Notation : UML 2 p 80

    111. 111 CONVENTION DE NOMMAGE Nom de classe : commence par une majuscule Ex. : Client, Aeroport Nom d’attribut, d’opération, d’association, de rôle : commence par une minuscule, puis, éventuellement plusieurs mots concaténés commençant par une majuscule Ex. : nom, numTel, heureDepart Nom d’association en italique, et souvent par forme verbale (active ou passive) avec éventuellement un petit triangle dirigé vers la classe désignée par la forme verbale Ex. entre les classes Societe et Personne: <Travaille pour, <Est employee par Nom de rôle : forme nominale, ou participe présent/passé Ex. entre les classes Societe et Personne : employeur, employe Ex. entre les classes Client et Compte : titulaire (ou possédant), possédé Préférable : pas d’accents, de caractères spéciaux Rôle : Muller P. 100Rôle : Muller P. 100

    112. 112 EXERCICE Etude d’un système de réservation de vol (cf. pages 80 et suivantes de « UML 2 par la pratique », P. Roques, Eyrolles, 2005, 4ème édition ou pages 66 et suivantes dans la 2ème édition: http://www.gramme.be/infopb/coursSL\analyse\references\externes/Modelisation_statique_by_Roques.pdf ) Notions supplémentaires vues dans l’exercice (à noter !) : Instance persistante Attribut dérivé Classe d’association Contrainte sur une association({ordered}) Qualificatif Convention de nommage p.96 Instance persistante p. 94 Attribut dérivé p. 97 Classe d’association Contrainte ({ordered}) p. 84 et 98 Qualificatif p. 98 Donner énoncé et solution p. 104 ou 111 en copie Convention de nommage p.96 Instance persistante p. 94 Attribut dérivé p. 97 Classe d’association Contrainte ({ordered}) p. 84 et 98 Qualificatif p. 98 Donner énoncé et solution p. 104 ou 111 en copie

    113. 113 A FAIRE A DOMICILE Lire le chapitre 1 « Objet et message » du syllabus « Concepts et méthodes de la programmation par objets » d’A. Clarinval Lire le chapitre 3 « Le schéma conceptuel de données » : §3 « Apports du paradigme objet » du syllabus « Méthodes d’analyse » d’A. Clarinval Exercices (UML2 P. 118 ou EIT-UMLOOExes.ppt page 15) Un dossier contient des fichiers (agrégation forte (ou faible si pas destruction des fichiers à la destruction du dossier): 1 ----------- 0 ..* vers fichiers + vers lui-même) Une pièce contient des murs (agrégation faible : 1..2 ----------- 1 ..*) Exercices (UML2 P. 118 ou EIT-UMLOOExes.ppt page 15) Un dossier contient des fichiers (agrégation forte (ou faible si pas destruction des fichiers à la destruction du dossier): 1 ----------- 0 ..* vers fichiers + vers lui-même) Une pièce contient des murs (agrégation faible : 1..2 ----------- 1 ..*)

    114. 114 UML : POINT DE VUE FONCTIONNEL PLAN : Concepts et définitions de base: Acteur (principal/secondaire) Cas d’utilisation (CU) Scénario Exemples de cas d’utilisation

    115. Exemple de diagramme de cas d’utilisation

    116. Exemple de diagramme de cas d’utilisation Attention : Ne pas confondre la modélisation des actes humains (qui n’est pas à faire ou alors spécifier qu’il s’agit d’une action humaine) et la modélisation du système informatique (à modéliser !). Bien définir CE QUE l’application informatique va faire, à quoi va servir l’application CU = CE QUE doit faire le système Facile d’expliquer UML au client. Un dessin stimule l’esprit. Buts UML : diminuer les coûts de développement CU : haut niveau pour se concentrer sur l’essentiel Diagrammes : différentes vues du système « La vérité est dans le code » : c’est par l’utilisation de l’exécutable que l’on voit si cela fonctionne, si on a bien pensé Attention : Ne pas confondre la modélisation des actes humains (qui n’est pas à faire ou alors spécifier qu’il s’agit d’une action humaine) et la modélisation du système informatique (à modéliser !).Bien définir CE QUE l’application informatique va faire, à quoi va servir l’application CU = CE QUE doit faire le système Facile d’expliquer UML au client. Un dessin stimule l’esprit. Buts UML : diminuer les coûts de développement CU : haut niveau pour se concentrer sur l’essentiel Diagrammes : différentes vues du système « La vérité est dans le code » : c’est par l’utilisation de l’exécutable que l’on voit si cela fonctionne, si on a bien pensé

    117. 117 Diagramme de cas d’utilisation Un diagramme de cas d’utilisation : décrit les acteurs les cas d’utilisation le système contient des descriptions textuelles

    118. 118 Le système Le système est un ensemble de cas d’utilisation Le système ne comprend pas les acteurs.

    119. 119 Acteur Élément extérieur au système qui interagit avec le système Rôle typique joué par un humain ou un système connexe par rapport au système Ex. : un client, un guichetier, un responsable maintenance, … Une même personne peut jouer plusieurs rôles Ex. : Maurice est directeur mais peut faire le guichetier Plusieurs personnes peuvent jouer un même rôle Ex. : Paul et Pierre sont deux clients Un acteur n’est pas forcément un être humain (dispositif matériel, …) Ex. : un distributeur de billets peut être vu comme un acteur Un acteur exécute un ou plusieurs cas d’utilisation

    120. 120 Acteur Est représenté par: un petit bonhomme (stick man) avec son nom dessous ou par un rectangle contenant le mot-clé << actor>> avec son nom dessous ou Par un mélange de ces 2 représentations acteur humain acteur non humain Pour les identifier : Quelles sont les entités externes au système qui interagissent directement avec le système ?

    121. 121 Description des acteurs Pour chaque acteur : choisir un identificateur représentatif de son rôle donner une brève description textuelle

    122. 122 Utilité des acteurs La définition d’acteurs permet d’identifier les cas d’utilisation Ex. : que peut faire un guichetier ? un client ? le directeur ? de voir le système de différents points de vues de déterminer des droits d’accès par type d’acteur de fixer des ordres de priorité entre acteurs ...

    123. 123 Cas d’utilisation Un cas d’utilisation (use case) décrit: Une fonctionnalité du système vue par un acteur (et utile à ce dernier) une suite d’interactions entre un utilisateur et le système qui produit un résultat observable et intéressant pour un acteur particulier Un comportement attendu du système du point de vue d’un ou de plusieurs acteurs Un service rendu par le système Analyse : CU décrit CE QUE le futur système devra faire, sans spécifier COMMENT il le fera

    124. 124 Cas d’utilisation Est représenté par un ovale. Le nom du cas est inclus dans l’ellipse ou figure en-dessous Relié par des associations « participe à » à ses acteurs L’ensemble des cas d’utilisation décrit exhaustivement les fonctionnalités du système (1 CU : 1 fonction métier du système) Pour les identifier : par acteur, quelles sont les différentes manières d’utiliser le système ? UML 2 p. 17UML 2 p. 17

    125. 125 Description des cas d’utilisation Pour chaque cas d ’utilisation choisir un identificateur représentatif : commencer par un verbe à l’infinitif, puis un complément du point de vue de l’acteur (pas du point de vue du système) réaliser une description détaillée plus ou moins formelle : préciser ce que fait le système, ce que fait l’acteur Les cas d’utilisation ne doivent pas se chevaucher Si un cas d’utilisation concerne beaucoup d’acteurs, il faut probablement le découper en plusieurs CU Détails du CU (pas dans diagrammes de CU !) : Par le scénario Diagr. Activité Diagr. Séquence Un ACTEUR INITIE un CU Ne pas trop détailler un CU : ce serait polluer le diagramme de CU CU: donner un verbe pour indiquer l’intention de l ’acteur- le résultat du CU doit être tangible. Objectif du CU: servir de support à l’activité humaine pour obtenir un résultat tangibleDétails du CU (pas dans diagrammes de CU !) : Par le scénario Diagr. Activité Diagr. Séquence Un ACTEUR INITIE un CU Ne pas trop détailler un CU : ce serait polluer le diagramme de CU CU: donner un verbe pour indiquer l’intention de l ’acteur- le résultat du CU doit être tangible. Objectif du CU: servir de support à l’activité humaine pour obtenir un résultat tangible

    126. 126 Exemple de description détaillée d’un CU: sommaire d’identification

    127. 127 Exemple de description détaillée d’un CU: description des scénarios A faire au tableau (p. 28 et 29 données en copie ? Non car ne correspond pas à notre système belge ? faire ensemble les étapes pour un GAB connu): UML2 P. 29 : scénario : 1) texte par étapes numérotées 2) 2 colonnes : étapes numérotées, colonne 1 = les acteurs, colonne 2 = le système Enchaînements alternatifs et d’erreur : UML2 p. 30 à 33A faire au tableau (p. 28 et 29 données en copie ? Non car ne correspond pas à notre système belge ? faire ensemble les étapes pour un GAB connu): UML2 P. 29 : scénario : 1) texte par étapes numérotées 2) 2 colonnes : étapes numérotées, colonne 1 = les acteurs, colonne 2 = le système Enchaînements alternatifs et d’erreur : UML2 p. 30 à 33

    128. 128 Exemple de description détaillée d’un CU: exigences non-fonctionnelles

    129. 129 Exemple de description détaillée d’un CU: besoins IHM

    130. 130 Scénario CU = ensemble de scénarios d’utilisation d’un système reliés par un but commun du point de vue d’un acteur Le CU a un début et une fin identifiés Scénario = succession particulière d’enchaînements, s’exécutant du début à la fin du CU. Un enchaînement = unité de séquence d’actions Un CU contient en général: un scénario nominal différents scénarios alternatifs (qui se terminent de façon normale) des scénarios d’erreur (qui se terminent en échec) UML 2 p. 18UML 2 p. 18

    131. 131 DESCRIPTION TEXTUELLE D’UN CU (en résumé) Non normalisé par UML Exemple: 1) Identification : Titre Résumé Dates de création/modification Version Responsable 2) Description des scénarios (nominal, alternatifs, d’erreur) + préconditions + postconditions 3) Optionnel : Exigences non-fonctionnelles (fiabilité, fréquence, confidentialité, intégrité, …) et besoins IHM

    132. 132 Acteurs principaux et secondaires Acteur principal d’un CU Celui pour qui le CU produit un résultat observable A gauche des CU Rôle indiqué éventuellement sur l’association côté acteur : <<principal>> (valeur par défaut) Acteur secondaire d’un CU Celui pour qui le CU ne produit pas un résultat observable par l’utilisateur Souvent sollicités pour des informations complémentaires Peuvent uniquement consulter ou informer le système (pas d’objectif à part entière de la part de l’acteur secondaire) A droite des CU Rôle indiqué éventuellement sur l’association côté acteur : <<secondaire>> Ex. : système d’authentification appelé par le distributeur de billets UML2 p. 27 + généralisation p.26, et amélio p. 28 Bien expliquer ce qui se passe lors du retrait d’argent d’un client banque d’un client autre banque Solution complète p. 45UML2 p. 27 + généralisation p.26, et amélio p. 28Bien expliquer ce qui se passe lors du retrait d’argent d’un client banque d’un client autre banque Solution complète p. 45

    133. 133 Relations entre acteurs et cas d’utilisation Relation d’association (« participe à ») : Lien entre un acteur et un cas d’utilisation qu’il peut exécuter Un cas d’utilisation doit être relié au moins à un acteur

    134. 134 Relations entre cas d’utilisation Relation d’inclusion (utilisation) Utilisée pour enlever la répétition entre plusieurs cas d’utilisation Utilisation du stéréotype « include » Un cas A (identifier le client) est inclus dans un cas B (retirer de l’argent) si le comportement décrit par le cas A est inclus dans le comportement de B Le CU de base B incorpore explicitement le CU A de façon obligatoire à un endroit spécifié dans ses enchaînements Le CU inclus peut porter le stéréotype « fragment »

    135. 135 Relations entre cas d’utilisation (2) Relation d’extension optionnelle : le CU de base B incorpore un CU A de façon optionnelle : Ex. Le CU ‘Consulter solde’ se fait uniquement sur demande du client de la banque; il étend le CU ‘Retirer de l’argent’ Utilisée lorsqu’un cas d'utilisation est semblable à un autre, mais ajoute de la fonctionnalité. Utile pour représenter les exceptions Utilisée pour décrire une variation du comportement normal Souvent soumise à condition exprimée sous la forme d’une note Utilisation du stéréotype « extend » Compléter au tableau par le point d’extension : UML2 p. 42Compléter au tableau par le point d’extension : UML2 p. 42

    136. 136 Relations entre cas d’utilisation (3) Relation de généralisation Un cas A est une généralisation d’un cas B si B est un cas particulier de A Déposer de l’argent est cas d’utilisation généralisé. Il devient abstrait (italique) car il ne s’instancie pas directement, mais uniquement par le biais de l’un des 2 cas spécialisés Distinguer 2 CU spécialisés ? possibilité de leur associer des acteurs secondaires différents

    137. 137 Relations entre acteurs Uniquement relation de généralisation/spécialisation A est une généralisation de B si tous les CU accessibles à A sont accessibles à B, mais pas l’inverse

    138. 138 Structuration en package Si les cas d’utilisation sont nombreux les regrouper par acteur Opérations client Opérations administrateur etc. les regrouper par domaine fonctionnel Gérer les contrats Gérer les clients Etc.

    139. 139 ETAPES DE LA MODELISATION FONCTIONNELLE Identification des acteurs Identification des CU (par acteur) Réalisation des diagrammes de CU Description textuelle des CU (scénarios) * Organisation des CU (relations entre CU + packages) PUIS description graphique * * des CU : Modélisation dynamique: diagramme de séquence système diagramme d’activité * Pour communiquer facilement avec les utilisateurs et s’entendre sur la terminologie métier employée * * Pour mieux montrer la succession des enchaînements

    140. 140 EXEMPLES DE CAS D’UTILISATION Etude d’un guichet automatique de banque (GAB) (cf. pages 19 et suivantes de « UML 2 par la pratique », P. Roques, Eyrolles, 2005) Etude d’une caisse enregistreuse (cf. pages 52 et suivantes de « UML 2 par la pratique », P. Roques, Eyrolles, 2005) Notion supplémentaire vue (à noter !) : Navigabilité sur l’association Exercice (EIT-UMLOOExes.ppt page 10) Un bibliothécaire souhaite disposer d’un logiciel de gestion des emprunts des livres de sa bibliothèque. En voici l’organisation : L’emprunteur d’un livre peut être soit un employé de la bibliothèque soit un étudiant. Pour rechercher un livre, un emprunteur peut se baser sur un auteur du livre ou sur le titre. Lorsqu’il vient au bureau d’emprunt, il dispose de sa carte de membre et des livres qu’il souhaite emprunter. Le bibliothécaire scanne le code à barres de la carte de membre. Le système informatique vérifie si la dette de l’emprunteur ne dépasse pas 15€. Si c’est le cas, l’emprunt est refusé. Sinon, le système vérifie le nombre de livres déjà empruntés par l’emprunteur. Si la limite a été atteinte, l’emprunt est refusé. Sinon, afin d’enregistrer l’emprunt, le bibliothécaire scanne le code à barres de chaque livre à emprunter. Exercice (EIT-UMLOOExes.ppt page 10) Un bibliothécaire souhaite disposer d’un logiciel de gestion des emprunts des livres de sa bibliothèque. En voici l’organisation : L’emprunteur d’un livre peut être soit un employé de la bibliothèque soit un étudiant. Pour rechercher un livre, un emprunteur peut se baser sur un auteur du livre ou sur le titre. Lorsqu’il vient au bureau d’emprunt, il dispose de sa carte de membre et des livres qu’il souhaite emprunter. Le bibliothécaire scanne le code à barres de la carte de membre. Le système informatique vérifie si la dette de l’emprunteur ne dépasse pas 15€. Si c’est le cas, l’emprunt est refusé. Sinon, le système vérifie le nombre de livres déjà empruntés par l’emprunteur. Si la limite a été atteinte, l’emprunt est refusé. Sinon, afin d’enregistrer l’emprunt, le bibliothécaire scanne le code à barres de chaque livre à emprunter.

    141. 141 UML : POINT DE VUE DYNAMIQUE PLAN: Concepts et définitions de base: Diagramme de séquence (#140) Diagramme de collaboration (non vu en 2ème) (#147) Diagramme d’états (#148) Etat Transition Evénement Message Condition Effet : action ou activité Diagramme d’activité (#162) Interaction Overview Diagram (non vu en 2ème) (#178) Exemples de diagrammes dynamiques UML

    142. 142 Rôle des diagrammes dynamiques Montrer la succession des enchaînements Montrer la chronologie des messages envoyés et reçus Montrer à quel moment un acteur est sollicité

    143. 143 DIAGRAMME DE SEQUENCE: rôle Visualisation des interactions entre objets selon un point de vue temporel Insistance sur la chronologie des envois des messages Mise en évidence du fonctionnement du programme avec visualisation du temps UML2 p.35 De tels diagrammes seraient illisibles s'ils devaient représenter, dans leur entièreté et leur variété, toutes les opérations d'un programme. Ils sont donc utilisés pour schématiser des scénarios, c'est-à-dire des séquences partielles d'opérations. UML2 p.35 De tels diagrammes seraient illisibles s'ils devaient représenter, dans leur entièreté et leur variété, toutes les opérations d'un programme. Ils sont donc utilisés pour schématiser des scénarios, c'est-à-dire des séquences partielles d'opérations.

    144. 144 DIAGRAMME DE SEQUENCE: représentation Représentation des objets : UML2 p.35UML2 p.35

    145. 145 DIAGRAMME DE SEQUENCE : représentation (suite) Acteur principal : à gauche Objet représentant le système en boîte noire au milieu Acteurs secondaires : à droite Echange de message : flèche horizontale, de l’émetteur vers le destinataire Exercice : Muller p. 149 : communication téléphoniqueExercice : Muller p. 149 : communication téléphonique

    146. 146 DIAGRAMME DE SEQUENCE : représentation (suite) Flèche de retour en pointillé

    147. 147 DIAGRAMME DE SEQUENCE : utilisations Documentation des CU (description de l’interaction, pas de détail de synchronisation): Diagramme de séquence système : Scénario nominal Diagramme de séquence enrichi = Diagramme de séquence système + Principales actions internes du système Renvois aux scénarios alternatifs et d’erreur Usage + informatique : messages au sens des langages de programmation Exemple : UML2 p. 36 + 38 À donner comme exemple (photocopie)Exemple : UML2 p. 36 + 38 À donner comme exemple (photocopie)

    148. 148 DIAGRAMME DE SEQUENCE : catégories de messages Synchronisation des messages: Message simple (objet client et serveur agissent dans le même processus) Message synchrone (émetteur bloqué: attend que récepteur ait fini de traiter le message) Message minuté (comme synchrone, sauf que l’attente est limitée par un timeout) Message dérobant (minuté par un délai d’attente nul) Message asynchrone (émetteur non bloqué) Message réflexif : un objet s’envoie un message à lui-même (exemple : pour indiquer des interactions internes entre composants d’ un objet composite)

    149. 149 DIAGRAMME DE SEQUENCE : plus loin Précondition et postcondition : Inclusion : cadre ref pour faire référence à un autre diagramme de séquence Répétition : cadre loop Condition : cadre alt Exemple : UML2 p. 41 + [63 +] 65 + 67 bas Exercices : biblio (de EIT) (cf. #137 de CU) : 2 DSS des 2 CU Jeu où un joueur lance 2 dés. Si le total > 6, il gagne, sinon il perdExemple : UML2 p. 41 + [63 +] 65 + 67 bas Exercices : biblio (de EIT) (cf. #137 de CU) : 2 DSS des 2 CU Jeu où un joueur lance 2 dés. Si le total > 6, il gagne, sinon il perd

    150. 150 DIAGRAMME DE COLLABORATION Montre les objets, les liens qui les unissent et les messages qu’ils s’échangent Mise en évidence des relations entre objets Rem. : n’appartient pas à la matière de 2ème Simplifier le schéma d’analyse Clarinval 8.4Simplifier le schéma d’analyse Clarinval 8.4

    151. 151 DIAGRAMME D’ETATS = statechart = cycle de vie d’une instance générique d’une classe au fil de ses interactions avec le monde Utile : pour décrire avec précision des comportements complexes Seulement pour certaines classes du modèle statique : Comportement réactif: si la réaction à un événement d’un objet d’une classe dépend de son état ? état caractérise un type de réaction Nécessité d’états séquentiels pour préciser une chronologie d’événements Un objet suit globalement le comportement décrit pour sa classe Ex. feu de signalisation : 3 états : V ? O ? R ? V à nouveau (état de départ) Remarque : synchronisation des différents feux d’un carrefour nécessaire ? description de la synchronisation dans le classe Carrefour (synchronisation dépend de l’état du carrefour) EX. facture créée, annulée, …Ex. feu de signalisation : 3 états : V ? O ? R ? V à nouveau (état de départ) Remarque : synchronisation des différents feux d’un carrefour nécessaire ? description de la synchronisation dans le classe Carrefour (synchronisation dépend de l’état du carrefour) EX. facture créée, annulée, …

    152. 152 DIAGRAMME D’ETATS : construction Construction : Description du comportement nominal d’un objet : séquence d’états + transitions associées Ajout des transitions dues aux comportements alternatifs ou d’erreur (cf. CU) Représentation : graphe orienté d’états et de transitions UML 2 P. 153 État : rectangle arrondiUML 2 P. 153 État : rectangle arrondi

    153. 153 ETAT Représente une situation durant la vie d’un objet : Condition particulière satisfaite Activité particulière en cours Evénement particulier en attente Identification des états : Recherche intuitive basée sur l’expertise métier Etude des attributs et des associations : valeur seuil d’un attribut qui modifie la dynamique, … Etablissement des interactions dans le comportement de chaque classe Un état a une durée finie, variable selon l’arrivée d’événements Un objet est toujours dans un état donné pour un certain temps; il ne peut être dans un état inconnu ou non défini Un état est l’image d’une conjonction instantanée des valeurs des attributs de l’objet et de la présence (ou absence) de liens entre l’objet et d’autres objets Etat initial : création de l’instance Etat final : destruction de l’instance (il peut exister de 0 à n états finaux) système qui ne s’arrête pas conditions de fin différentes Exemples : ampoule : état(allumé,éteint) Magasin : état(ouvert,fermé) Adulte(en activité, au chômage, retraité) : état dépend De l’attribut âge de la présence ou non d’un lien vers une société Eau : état solide, liquide, gazeux Demander de trouver des exemples et de les présenterExemples : ampoule : état(allumé,éteint) Magasin : état(ouvert,fermé) Adulte(en activité, au chômage, retraité) : état dépend De l’attribut âge de la présence ou non d’un lien vers une société Eau : état solide, liquide, gazeux Demander de trouver des exemples et de les présenter

    154. 154 TRANSITION Description de la réaction d’un objet suite à un événement Connexion unidirectionnelle reliant 2 états (parfois non distincts) Passage d’un état à l’autre : instantané (car objet toujours dans un état connu) Constitution : Événement déclencheur Condition de garde Effet État cible

    155. 155 EVENEMENT Occurrence d’un stimulus localisé dans le temps et l’espace: sert de déclencheur pour que l’objet passe d’un état à un autre (objet contrôlé par les événements en provenance du système, d’un autre objet) 4 types : Signal : réception d’un message (envoi asynchrone) Call event : appel d’une opération sur l’objet récepteur (appel synchrone) Time event : passage du temps (after durée) Change event : changement de la satisfaction d’une condition (when expression_booléenne) Spécification: Nom de l’événement Liste des paramètres (information circulant entre objets) Objet expéditeur Objet destinataire Description de la signification de l’événement Ex. Muller p.162 Exemple d’événement interne : exception en cas d’overflow Création/suppression d’objet : événement = message (= signal) Synchrone/asynchrone : du point de vue de l’émetteur (qui doit attendre ou non la réponse du récepteur) Synchrone (l’émetteur se met en attente de la réponse : pour changer d’état, l’émetteur attend un message : la réponse du récepteur): le contrôle passe de l’émetteur au récepteur La transition du récepteur est réalisée L’opération (effet) de la transition est réalisée Le récepteur passe dans un nouvel état Le contrôle repasse à l’émetteur Ex. Muller p.162 Exemple d’événement interne : exception en cas d’overflow Création/suppression d’objet : événement = message (= signal) Synchrone/asynchrone : du point de vue de l’émetteur (qui doit attendre ou non la réponse du récepteur) Synchrone (l’émetteur se met en attente de la réponse : pour changer d’état, l’émetteur attend un message : la réponse du récepteur): le contrôle passe de l’émetteur au récepteur La transition du récepteur est réalisée L’opération (effet) de la transition est réalisée Le récepteur passe dans un nouvel état Le contrôle repasse à l’émetteur

    156. 156 MESSAGE Transmission d’information unidirectionnelle entre l’objet émetteur et l’objet récepteur Communication : Synchrone (ex.: call event) Asynchrone (ex.: envoi d’un message) La réception du message est un événement traité par le récepteur

    157. 157 CONDITION (ou condition de garde) Expression booléenne qui doit être VRAIE lorsque l’événement arrive pour que la transition soit déclenchée Concernée par : Attributs de l’objet Paramètres de l’événement déclencheur 1 événement ? plusieurs transitions possibles, si conditions de garde différentes Gardes d’un événement : mutuellement exclusives Notation : [condition] Ex. : 1) voiture chez le vendeur : - état 1 : en attente (d’être préparée, d’être envoyée à la casse, …) - événement = vente [à une personne]? effet = préparation (lavage, …) [à une société de casse] ? effet = retrait des ustensiles (triangle, radio, …) - état 2 : voiture préparée - état 3 : voiture vidée 2) Muller p. 163 : chaud 3) demander d’autres exemplesEx. : 1) voiture chez le vendeur : - état 1 : en attente (d’être préparée, d’être envoyée à la casse, …) - événement = vente [à une personne]? effet = préparation (lavage, …) [à une société de casse] ? effet = retrait des ustensiles (triangle, radio, …) - état 2 : voiture préparée - état 3 : voiture vidée 2) Muller p. 163 : chaud 3) demander d’autres exemples

    158. 158 EFFET Comportement optionnel de l’objet spécifié par une transition 2 types : Action (non interruptible) Activité : séquence atomique (non interruptible) d’actions L’action (ou les actions) correspond à une opération déclarée dans la classe de l’objet destinataire de l’événement A accès : aux paramètres de l’événement aux attributs de l’objet Exemples d’action : MAJ d’un attribut Appel d’opération Création/destruction d’un autre objet Envoi d’un signal à un autre objet … Notation : /effet

    159. 159 EFFET (suite) Effet d’entrée : entry / Effet de sortie : exit / Remarques : une transition réflexive entraîne l’exécution des effets de sortie et d’entrée Un événement interne n’entraîne pas l’exécution des effets d’entrée et de sortie Une activité interruptible sera associée à un état, non à une transition; il s’agit d’une activité durable (do-activity); notation : do/activité. Cas particulier : Lorsqu’une activité séquentielle se termine, une transition automatique (sans événement, avec garde éventuelle) est déclenchée

    160. 160 EFFET (suite)

    161. 161 Modélisation d’un message reçu/émis Message reçu ? événement qui déclenche une transition entre états Message émis ? action (effet) sur la transition

    162. 162 NOTATION GENERALE DU DIAGRAMME D’ETATS UML 2 p 156 Muller p. 174 : création et destruction d’un avionUML 2 p 156 Muller p. 174 : création et destruction d’un avion

    163. 163 EXERCICE Etude d’un publiphone à pièces (cf. pages 156 et suivantes de « UML 2 par la pratique », P. Roques, Eyrolles, 2005) Notions supplémentaires vues dans l’exercice (à noter !) : Diagramme de séquence : opérateur opt Diagramme d’états : Etat composite ou super-état Transition : propre (retour de l’objet au sous-état initial) interne (pas d’effet sur l’état courant) factorisée (un super-état permet de factoriser la transition) Pseudo-état history Envoi de message à un autre objet sur déclenchement d’une transition : / send cible.message Sol : CU : p. 158 : acteur = appelant --- système = publiphone --- acteur = standard --- syst. = téléphone --- acteur = appelé Diagr. de séqu. : p. 159 et 160, mais param. de message au lieu de valeur Travail préliminaire au diagr. d’états: UML2 p. 163 : répertorier les messages échangés entre les acteurs et le système Diagr. d’états : p. 166 fig. 5-14 (et 5-13) Expliquer éventuellement les erreurs de p.168 : 5-16 et 5-17 (évident pour programmeur !), puis sol p. 169, 170 P. 171: transition propre ? NOK, p. 172 : transition interne Sol. finale p.175 Sol : CU : p. 158 : acteur = appelant --- système = publiphone --- acteur = standard --- syst. = téléphone --- acteur = appelé Diagr. de séqu. : p. 159 et 160, mais param. de message au lieu de valeur Travail préliminaire au diagr. d’états: UML2 p. 163 : répertorier les messages échangés entre les acteurs et le système Diagr. d’états : p. 166 fig. 5-14 (et 5-13) Expliquer éventuellement les erreurs de p.168 : 5-16 et 5-17 (évident pour programmeur !), puis sol p. 169, 170 P. 171: transition propre ? NOK, p. 172 : transition interne Sol. finale p.175

    164. 164 EXERCICE Etude d’un réveil (cf. pages 181 et suivantes de « UML 2 par la pratique », P. Roques, Eyrolles, 2005) + exercice UML15.pdf : lavage automatique de voiture+ exercice UML15.pdf : lavage automatique de voiture

    165. 165 DIAGRAMME D’ACTIVITE Représentation de l’ensemble des actions réalisées par le système, avec tous les branchements conditionnels et toutes les boucles possibles : représentation de la dynamique globale du CU Graphe orienté d’actions et de transitions : Transitions automatiques* : franchies à la fin des actions éventuellement gardées par des conditions booléennes mutuellement exclusives Étapes : en parallèle ou en séquence * Pas de transition interne, ni de transition déclenchée par un événement À voir après les diagr. d’étas UML2 p.35 + exemple p. 37 Diagr. Activité : Déroulement d’une méthode Déroulement d’une activité humaine Activité: - flux de contrôle d’une activité à l’autre - piste pour trouver CU et acteursÀ voir après les diagr. d’étas UML2 p.35 + exemple p. 37 Diagr. Activité : Déroulement d’une méthode Déroulement d’une activité humaine Activité: - flux de contrôle d’une activité à l’autre - piste pour trouver CU et acteurs

    166. 166 REPRESENTATION

    167. 167 EXEMPLE DE TRANSITION GARDEE

    168. 168 FLOTS DE CONTROLE Les flots de contrôle connectent des actions (rectangles avec coins arrondis) pour indiquer que l’action pointée par la flèche ne peut pas démarrer tant que l’action source n’est pas terminée

    169. 169 FLOTS D’OBJETS Les flots d’objets connectent des nœuds d’objets (rectangles) pour fournir des entrées (inputs) aux actions. Le nom d’un état peut être mis entre crochets ( [nomEtat] ).

    170. 170 Exemple : activités d’une commande Muller p. 181 modifiéMuller p. 181 modifié

    171. 171 BARRE DE SYNCHRONISATION Une barre de synchronisation : représente une synchronisation entre flots de contrôle parallèles permet d’ouvrir (fork = barre d’embranchement) ou de fermer (join = barre de jointure) des branches parallèles au sein d’un flot d’exécution d’une méthode ou d’un CU

    172. 172 FORK fork : barre d’embranchement

    173. 173 FORK (suite)

    174. 174 JOIN join : barre de jointure (fusion de flots)

    175. 175 JOIN (suite)

    176. 176 ACCEPT TIME EVENT Accept time event

    177. 177 REGION D’EXPANSION Une région d’expansion est un nœud d’activité structuré qui s’exécute 1 fois pour chaque élément dans une collection d’entrées. Les entrées et sorties de la collection (nœud d’expansion) sont matérialisés sur la frontière de la région (rectangle en pointillés avec coins arrondis) par des petits rectangles de plusieurs compartiments

    178. 178 REGION INTERRUPTIBLE Une région interruptible est un ensemble de nœuds et d’arcs d’activité au sein duquel l’activité se termine si un événement désigné se produit. Cet événement d’interruption apparaît comme une flèche « éclair » Fournir exemple recette UML2 p. 200Fournir exemple recette UML2 p. 200

    179. 179 ENVOI/RECEPTION D’UN SIGNAL Exemple : Muller p. 182Exemple : Muller p. 182

    180. 180 EXERCICE Etude d’un guichet automatique de banque (GAB) (cf. pages 19 et suivantes de « UML 2 par la pratique », P. Roques, Eyrolles, 2005) : diagramme d’activité pour le retrait d’argent page 37

    181. 181 Interaction Overview Diagram Fusion des diagrammes d’activité et de séquence Actions remplacées par des interactions Rem. : n’appartient pas à la matière de 2ème

    182. 182 A FAIRE A DOMICILE Lire le chapitre 8 « Méthodes orientées objets» du syllabus « Méthodes d’analyse » d’A. Clarinval

    183. 183 TABLEAU RECAPITULATIF

    184. 184 VERS UNE METHODE DE DEVELOPPEMENT Cycle de vie itératif et incrémental: Abandon de la méthode en cascade pour un développement itératif Exemple : RUP (cf. le document : « Le processus RUP ») Muller p.232 Artefacts utiles dans un processus de développement logiciel (pas du UML): Catalogue des règles métiers Glossaire : terminologie commune à partager (entre client, analyste, chef de projet et même équipe de développement (notamment par utilisation de noms de variables longs et significatifs)) Ces artefacts (1 et 2) sont complémentaires aux CU Catalogues des besoins non fonctionnels : besoins et contraintes environnementaux, non fonctionnels: Temps de réponse BD héritée Respect culturel … « La valeur d’une application ne vaut que par la maîtrise du sujet, du domaine » « Développer un logiciel est facile; le faire évoluer, le maintenir est difficile » « Plus on maîtrise les concepts du domaine, plus on est capable de les faire évoluer » Lutte contre la non-factorisation du code (donc rejet du RAD où intelligence métier est dupliquée) « Une application doit être aussi riche en application console qu’en interface graphique » Ex : Où mettre « limiteCredit » : terme à bien définir d’abord (glossaire), puis réfléchir et décider de la classe qui en est responsable Domain Design Driven (DDD) : maîtrise des concepts métier: vie, relations, … Modélisation des concepts métiers par les CU – repérer les substantifs (= concepts métier) – puis diagr. de classe, d’objets, … Concepteur de classe <> Utilisateur de classe (développeurs différents, achats de librairies, …) ? Le concepteur doit prévoir une conception de classe la + robuste possibleMuller p.232 Artefacts utiles dans un processus de développement logiciel (pas du UML): Catalogue des règles métiers Glossaire : terminologie commune à partager (entre client, analyste, chef de projet et même équipe de développement (notamment par utilisation de noms de variables longs et significatifs))

    185. 185 VERS UNE METHODE DE DEVELOPPEMENT (suite) Extrait de l’avant-propos de : « Guide pratique du RUP », P. Koll, Ph. Kruchten, CampusPress, 2003

    186. 186 VERS UNE METHODE DE DEVELOPPEMENT (suite)

    187. 187 VERS UNE METHODE DE DEVELOPPEMENT (suite)

    188. 188 VERS UNE METHODE DE DEVELOPPEMENT (suite)

    189. 189 6 ETAPES d’un processus de développement (par Expert-IT SA) Un processus décrit: Quoi faire Comment le faire Qui le fera Quand le faire Pourquoi le faire Un processus : utilise UML comme langage de modélisation est un guide sur la manière d’utiliser UML 6 étapes d’un processus de développement logiciel: Besoins Analyse des Business Process (BP) Recueil des besoins du projet informatique Analyse et design de l’application Implémentation Logiciel fourni UML n’est pas un processus; un processus UTILISE UMLUML n’est pas un processus; un processus UTILISE UML

    190. 190 6 ETAPES d’un processus de développement (suite) Besoins : l’entreprise, décomposée en processus métier, subit les actions du monde extérieur Analyse des BP : analyse du système d’information humain: a) Est alimentée par : Business Process Modeling Notation (BPMN) Business Process Execution Language (BPEL) Business Process Modeling Language (BPML) Diagrammes d’activité Diagrammes d’état ? diagr. de classe Business UC b) Produit les artefacts suivants : BP Model Glossaire Model Concepts Business Process Modeling Notation (BPMN) est une notation graphique standardisée pour modéliser des procédures d'entreprise dans un workflow. Business Process Modeling Notation a été développée par la Business Process Management Initiative (BPMI), et est maintenant maintenue par l'Object Management Group (OMG) depuis leur fusion en 2005. Le but principal de BPMN est de fournir une notation qui soit réellement compréhensible par tous les utilisateurs de l'entreprise, depuis les analystes métier qui créent les ébauches initiales des procédures, jusqu'aux développeurs responsables de mettre en place la technologie qui va exécuter ces procédures, et finalement, jusqu'aux utilisateurs de l'entreprise qui vont gérer et monitorer ces procédures. Ainsi, BPMN crée un pont standardisé pour combler le vide entre la modélisation des procédures d'entreprise et la mise en place des procédures. Actuellement, il y a des dizaines d'outils de modélisation et de méthodologies pour les procédures d'entreprise. BPMN améliorera les possibilités des notations traditionnelles des procédures d'entreprise en gérant par nature les concepts de procédures B2B, comme les procédures publiques et privées et les chorégraphies, ainsi que des concepts de modélisation avancée, comme la gestion des exceptions et la compensation des transactions. En informatique, Business Process Execution Language (ou BPEL, prononcé 'bipeul', ou 'bipèl'), est un langage de description des procédures d'entreprise qui est issu des langages WSLF (Web Services Flow Language) et XLANG. Il est sérialisé en XML et vise à rendre possible le programming in the large. Les concepts de programming in the large et programming in the small distinguent deux aspects de l'écriture de procédures asynchrones à long terme qu'on voit généralement dans les procédures d'entreprise. Ce langage a été défini dans sa version 2.0 par une spécification du consortium OASIS à la fin du mois de mars 2007. BPML (Business Process Modeling Language) est un langage basé sur XML permettant de modéliser des processus métier La modélisation de procédure d'entreprise ou modélisation de processus métier ou modélisation de processus désigne la création d'un modèle mathématique d'une procédure d'entreprise. BPM est le sigle utilisé, en référence à l'anglais « Business Process Modeling ». Ce terme renvoie aux techniques et activités de la discipline de pilotage de procédure d'entreprise (ici BPM pour « Business Process Management »). La distinction fondamentale entre ces deux notions de BPM réside dans le fait que pour la seconde, on s'intéresse à donner à l'Entreprise les moyens de piloter et de maîtriser ses processus-métiers, tandis que la première ne consiste qu'à les modéliser (toujours avec un objectif venant de l'extérieur : optimisation de chaîne de production, expression de besoins fonctionnels pour un développement logiciel, ré-organisation suite à un rapprochement entre deux filiales d'une entreprise, par exemple). La modélisation de processus est utilisée en gestion de la qualité pour représenter des processus, mais également pour les procédures d'entreprise et workflows avec : le langage de modélisation de procédures (« Business Process Modeling Language » ou BPML), la notation de modèles de procédures (« Business Process Modeling Notation » ou BPMN). Qu'est-ce que le BPEL ? Le BPEL, Business Process Execution Language, est une représentation XML utilisée dans le cadre de la mise en place d'une architecture orientée services (SOA) en entreprise. Concrètement, dans cette architecture SOA, les applications de l'entreprise sont réunies au sein d'un socle commun afin de favoriser le dialogue entre applications et consolider l'existant. BPEL organise justement le dialogue entre les différentes applications de l'architecture SOA. Il se présente sous la forme d'un fichier XML lisible par des moteurs de gestion des processus métiers, ces derniers se chargeant d'appliquer les règles du fichier en question. Sans BPEL, les services Web ne pourraient pas dialoguer entre eux. Il organise donc le déroulement des processus métiers (workflow). Le fichier BPEL agit donc sur des éléments comme la transformation de données, l'envoi de messages ou l'appel d'une fonction. Business Process Modeling Notation (BPMN) est une notation graphique standardisée pour modéliser des procédures d'entreprise dans un workflow. Business Process Modeling Notation a été développée par la Business Process Management Initiative (BPMI), et est maintenant maintenue par l'Object Management Group (OMG) depuis leur fusion en 2005. Le but principal de BPMN est de fournir une notation qui soit réellement compréhensible par tous les utilisateurs de l'entreprise, depuis les analystes métier qui créent les ébauches initiales des procédures, jusqu'aux développeurs responsables de mettre en place la technologie qui va exécuter ces procédures, et finalement, jusqu'aux utilisateurs de l'entreprise qui vont gérer et monitorer ces procédures. Ainsi, BPMN crée un pont standardisé pour combler le vide entre la modélisation des procédures d'entreprise et la mise en place des procédures. Actuellement, il y a des dizaines d'outils de modélisation et de méthodologies pour les procédures d'entreprise. BPMN améliorera les possibilités des notations traditionnelles des procédures d'entreprise en gérant par nature les concepts de procédures B2B, comme les procédures publiques et privées et les chorégraphies, ainsi que des concepts de modélisation avancée, comme la gestion des exceptions et la compensation des transactions. En informatique, Business Process Execution Language (ou BPEL, prononcé 'bipeul', ou 'bipèl'), est un langage de description des procédures d'entreprise qui est issu des langages WSLF (Web Services Flow Language) et XLANG. Il est sérialisé en XML et vise à rendre possible le programming in the large. Les concepts de programming in the large et programming in the small distinguent deux aspects de l'écriture de procédures asynchrones à long terme qu'on voit généralement dans les procédures d'entreprise. Ce langage a été défini dans sa version 2.0 par une spécification du consortium OASIS à la fin du mois de mars 2007. BPML (Business Process Modeling Language) est un langage basé sur XML permettant de modéliser des processus métier La modélisation de procédure d'entreprise ou modélisation de processus métier ou modélisation de processus désigne la création d'un modèle mathématique d'une procédure d'entreprise. BPM est le sigle utilisé, en référence à l'anglais « Business Process Modeling ».

    191. 191 6 ETAPES d’un processus de développement (suite) Recueil des besoins du projet informatique: a) Est alimenté par : - diagrammes CU - diagrammes d’activité, d’état, de séquence, de classes b) Produit les artefacts suivants : - modélisation des concepts (UML) - catalogue des acteurs (UML) - catalogue des CU (UML) - catalogue des business rules (règles communes à tous les CU) - catalogue des besoins non fonctionnels (temps de réponse, infrastructure Web, multilinguisme, …) - glossaire (commencé éventuellement dans l’analyse des besoins)

    192. 192 6 ETAPES d’un processus de développement (suite) Analyse et design de l’application : (= comment va-t-on faire ?) : Organisation des classes du point de vue structurel et dynamique Point de vue technique, de l’infrastructure a) Est alimentée par : - diagrammes de classe - diagrammes dynamiques b) Produit les artefacts suivants : - diagrammes de classe - modélisation dynamique Implémentation du logiciel : D’où un feed-back sur les autres étapes b) Produit les artefacts suivants : - System Sequence Diagram (SSD): opérations système avec pré-conditions et post-conditions

    193. 193 6 ETAPES d’un processus de développement (suite) Logiciel fourni : A chaque itération d’implémentation, un incrément est fourni au client. Exemples d’incrément : - un écran de création de devis - association de l’écran à la création d’un plan média L’implication du client doit être forte Seront régulièrement réunis : analyste + développeur + client NB : Recommandation : un artefact doit être produit sur maximum 3 semaines (sinon prévoir de plus petits artefacts) + Parler de l’architecture trois tiers (cf. définition dans Wikipedia par ex. : http://fr.wikipedia.org/wiki/Architecture_trois_tiers ) + progwebphpmvc_250305.pdf+ Parler de l’architecture trois tiers (cf. définition dans Wikipedia par ex. : http://fr.wikipedia.org/wiki/Architecture_trois_tiers ) + progwebphpmvc_250305.pdf

    194. 194 Travaux pratiques Utilisation du logiciel Rational Rose Enterprise 2003 Rational Rose est le Leader Mondial en outil de Modélisation UML, c'est aussi l'un des plus coûteux. Rational propose par ailleurs de nombreux outil pour faciliter la gestion des projets de développement. Rational a par ailleurs passé un accord avec la Société Ensemble pour distribuer le Rose Link qui procure une liaison bidirectionnelle synchronisée entre un modèle UML de Rose et un code Java ou Delphi par exemple. Avec cette combinaison le reverse engineering à partir d'une application Java ou Delphi est possible. Rose Link Java est disponible pour Borland, JBuilder, Visual Café, Oracle JDeveloper, & IBM's VisualAge. Utilisation du logiciel Microsoft Office Visio 2003 (cf. http://www.microsoft.com/france/office/visio/decouvrez.mspx ) Cf. les 6 TPs proposés sur http://www.gramme.be/infopb/coursSL/analyse/TP

    195. 195 Avec de l’expérience … Etre compétent en UML, c’est comprendre ce que chaque type de diagramme peut offrir et savoir quand il faut l’utiliser. Souvent, un concept pourra être exprimé au moyen de plusieurs diagrammes; l’utilisateur expérimenté d’UML saura utiliser le(s) plus adapté(s) à sa modélisation.

More Related