Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Atelier n°1 Décrire sa base de données à l’aide d’un modèle conceptuel de donné

Atelier n°1 Décrire sa base de données à l’aide d’un modèle conceptuel de données Guillaume HARRY (DSI/CNRS) Marie-Claude QUIDOZ (CEFE/CNRS) FORMALISME UML MÉTHODE 2TUP 2 UML • Langage de modélisation • Unification par OMG en 1997 des modélisations objets – Ivar Jacobson (OOSE) – Grady Booch (BOOCH'93) – James Rumbaugh (OMT) • Utilisation de la notation graphique – solution visuelle – limite les ambiguïtés – indépendance par rapport aux langages • Objectifs – Représenter des systèmes entiers – Établir un couplage entre concepts et artefacts exécutables – Programmation sans programmer 3 UML • Langage de modélisation • Unification des modélisations objets de – Ivar Jacobson (OOSE) – Grady Booch (BOOCH'93) , – James Rumbaugh (OMT) • Normalisation par Object Management Group en 1997 4 UML • Vues statiques 1. diagrammes de cas d'utilisation 2. diagrammes de composants 3. diagrammes de déploiement 4. diagrammes de classes 5. diagrammes d'objets • Vues dynamiques 6. diagrammes de séquence 7. diagrammes de collaboration 8. diagrammes d'états-transitions 9. diagrammes d'activités 5 UML 6 UML 7 Nature Diagrammes Sémantique Statique cas d'utilisation décrit les besoins utilisateur classes définit la structure statique objet composants montre les unités de travail déploiement précise la répartition des processus Dynamique collaboration scénarios et flots de messages séquence états-transitions définit le comportement dynamique activités • Faire l’inventaire des besoins fonctionnels • Organiser les besoins entre eux, de manière à faire apparaître des relations (réutilisations possibles) • Un cas d’utilisation est un service rendu. – Il implique des séries d’actions plus élémentaires • Un acteur est une entité extérieure au système qui interagit directement avec ce système UML Cas d’utilisation 8 UML Cas d’utilisation 9 • Exemple UML Cas d’utilisation 10 • Inclusion : Le cas A inclut le cas B – B est une partie obligatoire de A • Extension : Le cas B étend le cas A – B est une partie optionnelle de A • Généralisation : Le cas A est une généralisation du cas B – B est une sorte de A UML Diagramme de classe 11 • Modélise à quoi sert le système • Permet de spécifier la structure et les liens entre les concepts dont le système est composé • Classe – Description d’un concept concret ayant une sémantique – Spécification des caractéristiques (attributs, méthodes et relations) UML Diagramme de classe 12 • Exemple UML Diagramme de classe 13 • Association – Représente une relation sémantique entre les classes – Multiplicité • Exemple : un article n’appartient qu’à une seule catégorie; une catégorie concerne plus de 0 articles, sans maximum UML Diagramme de classe 14 • Association – Navigabilité • Permet de spécifier dans quel(s) sens il est possible de traverser l’association à l’exécution – Parfois les 2 extrémités de l’association pointent vers la même classe  Association reflexive UML Diagramme de classe 15 • Association • Peut avoir ses propres attributsdevient une classe appelée « classe association » UML Diagramme de classe 16 • Agrégation – Forme particulière d’association – Décrit une relation de contenance ou de composition – Représente la relation d’inclusion d’un élément dans un ensemble • Composition – Forme particulière d’agrégation – Décrit une contenance structurelle – La destruction / la copie de l’objet composite (l’ensemble) impliquent la destruction / la copie de ses coomposants (parties) UML Diagramme de classe 17 • Exemple – D’agrégats • Chaise table – De compositions • Bâtiment, fenêtre, porte UML Diagramme de classe 18 • Héritage – Relation de généralisation/spécialisation permettant l’abstraction – Les éléments spécialisés héritent de la structure et du comportement des éléments plus généraux (attributs et opérations) – La classe enfant possède toutes les propriétés de ses classes parents (attributs et opérations) • La classe enfant est la classe spécialisée • La classe parent est la classe générale – Une classe enfant peut redéfinir une ou plusieurs méthodes de la classe parent – Toutes les associations de la classe parent s’appliquent aux classes enfant UML Diagramme de classe 19 • Exemple UML Diagramme de classe 20 • Encapsulation – Permet de protéger l’utilisation des attributs et opérations – Public (+) : propriété vaisible partout – Protected (#) : propriété visible dans la classe et par tous ses descendants – Private (-) : propriété visible uniquement dans la classe UML Diagramme d’activités 21 • Modélise les traitements – Comportement d’une méthode – Déroulement d’un cas d’utilisation – En s’affranchissant de la structure de l’application UML Diagramme d’activités 22 • Activité – Représente • une exécution d’un mécanisme • un déroulement d’étapes séquentielles – Les activités peuvent être imbriquées hiérarchiquement activités composites – Les activités peuvent être exécutées parallèlement  activités concurrentes (représentées avec des barres de synchronisation) UML Diagramme d’activités 23 • Transition – Spécifie l’enchaînement des traitements – Définit le flot de contrôle – Déclenchée dès que l’activité source est terminée – Provoque automatiquement le début immédiat de la prochaine activité à déclencher • Points de choix – Gardes conditionnelles • Transition ne pouvant être empruntée que si la garde est vraie UML Diagramme d’activités 24 • Nœud de contrôle • Un flot de contrôle qui atteint un « flow final » est détruit • Les autres flots de contrôle ne sont pas affectés • Tous les autres flots de contrôle de l’activité sont interrompus et détruits UML Diagramme d’activités 25 UML Diagramme de collaboration 26 • Modélise les interactions • Représente le séquencement des traitements UML Diagramme de collaboration 27 • Messages – Message synchrone • Bloque l’expéditeur jusqu’à la réponse du destinataire • Flot de contrôle passe de l’émetteur au récepteur – Message asynchrone • Ne bloque pas l’expéditeur • le message envoyé peut être pris en compte par le récepteur à tout moment ou ignoré – Numéros de séquence • Messages successifs sont ordonnés selon un numéro croissant • Messages envoyés en cascade portent un numéro d’emboitement 1.1, 1.2 UML Diagramme de collaboration 28 FORMALISME UML MÉTHODE 2TUP 29 2TUP 30 • Processus Séquence d’étapes, en partie ordonnées, qui concourent à l’obtention d’un système logiciel ou à l’évolution d’un système existant • Processus Unifié (Unified Process) – processus de développement logiciel construit sur UML – itératif et incrémental – centré sur l’architecture – conduit par les cas d’utilisation – piloté par les risques  Méthode Agile 31 2TUP Élaboration Construction Transition Processus projet Processus organisationnels Spécifications Analyse & Conception Implémentation Tests Déploiement Support du projet Configuration Gestion du projet Environnement Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m RUP 2TUP XP Itération Préliminaire Iter. #m+1 Analyse des besoins Phases Itérations 2TUP 32 • 2 Tracks Unified Process • Principe : Un système d’information est soumis à deux natures de contraintes – Définition du modèle fonctionnel en parallèle – Définition de l’architecture technique – Puis fusion des résultats S y stè m e In fo rm atiq u e C o n train tes fo n ctio n n elles C o n train tes tech n iq u es 2TUP 33 Contraintes fonctionnelles Contraintes techniques Branche fonctionnelle Branche technique Capture des besoins fonctionnels Analyse Conception préliminaire Capture des besoins techniques Conception générique Conception détaillée Codage et test Recette Les branches du « Y » produisent des modèles réutilisables – Branche gauche capitalise la connaissance du métier de l’entreprise – Branche droite capitalise un savoir-faire technique. 2TUP 34 Processus itératif et incrémental • Itération – séquence distincte d’activités avec • un plan de base • des critères d’évaluation – Porteuse d’améliorations ou d’évolutions du système – Peut être évaluée par les utilisateurs – Chaque itération passe en revue toutes les activités du processus en Y • Incrément – Différence entre deux productions à la fin de deux itérations successives 2TUP 1 - Étude préliminaire 35 2TUP 1 - Étude préliminaire 36 • Toute première étape du processus • 1er repérage des besoins fonctionnels et opérationnels • Prépare les activités plus formelles de – capture des besoins fonctionnels – capture des besoins techniques • Diagrammes très simples • Objectifs – Établir un recueil initial des besoins fonctionnels et opérationnels – modéliser le contexte du système en • identifiant les entités externes au système qui interagissent directement avec lui (acteurs) • répertoriant les interactions (émission/réception de messages) entre ces acteurs et le système 2TUP 1 - Étude préliminaire 37 2TUP 1 - Étude préliminaire 38 • Identifier les acteurs – Un acteur représente l’abstraction d’un rôle joué par des entités externes (utilisateur, dispositif matériel ou autre système) qui interagissent directement avec le système étudié – Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou en recevant des messages éventuellement porteurs de données – Acteurs candidats • Utilisateurs humains directs • Autres systèmes connexes – Ne pas confondre rôle et entité concrète ! – Éliminer les acteurs « physiques » au profit des « logiques » 2TUP 1 - Étude préliminaire 39 • Identifier les messages – Un message représente la spécification d’une communication unidirectionnelle entre objets qui transporte de l’information avec l’intention de déclencher une activité chez le récepteur – Un message est normalement associé àdeux uploads/Management/ decrire-sa-base-de-donnees-a-l-aide-de-modeles-conceptuels-2-sur-2.pdf