Modélisation

Présentation

La représentation schématique est indispensable à la bonne réalisation des projets informatiques. La modélisation des données pour la réalisation d’une base de données et la représentation des classes pour la création d’application sont les plus utilisés. Dans un objectif d’optimisation et de tests, on représente également les processus, les cas d’utilisations, les scénarios…

UML (Unified Modeling Language) est un langage de modélisation. Il est une synthèse de certaines méthodes de modélisation objet. UML a été normalisé en 1997.  Au delà des diagrammes, UML propose des méthodes d’analyse et de conception.

  • Structure Diagrams
    • Class Diagram
    • Component Diagram
    • Deployment Diagram
    • Object Diagram
    • Package Diagram
    • Profile Diagram
    • Composite Structure Diagram
  • Behavioral Diagrams
    • Use Case Diagram
    • Activity Diagram
    • State Machine Diagram
    • Sequence Diagram
    • Communication Diagram
    • Interaction Overview Diagram
    • Timing Diagram

Merise, moins populaire et apparue dans les années 70, est également utilisée pour la réalisation des systèmes d’informations.

  • Données
    • Modèle physique de données
    • Modèle logique des données
    • Modèle conceptuel de données
  • Flux
    • Modèle de contexte
    • Modèle conceptuel de flux
  • Traitements
    • Modèle opérationnel des traitements
    • Modèle logique des traitements
    • Modèle conceptuel des traitements

 

Métiers

  • Data Analyst
  • Business Intelligence Manager
  • Master Data Manager
  • Data Architect
  • Data Miner
  • Data Scientist
  • Database Administrator
  • Developer Back end
  • Developer Front end
  • Developer Full Stack
  • Lead Developer
  • Software Architect
  • Chief Information Officer (CIO)
  • Chief Data Officer (CDO)
  • Chief Technology Officer ( CTO )

 

Le modèle relationnel – ni Merise ni UML

Edgar Frank Codd, employé d’IBM, a défini le modèle relationnel dans les années 70 toujours utilisé pour la modélisation des données.

Relation et attributs

Une relation est caractérisée par un nom et regroupe plusieurs attributs. Un attribut correspond donc à une colonne d’une relation caractérisée par un nom. Les attributs calculés n’apparaissent pas dans le schéma relationnel (car les données sont calculées par traitement et pas stockées, pour une plus grande efficacité dans la mise à jour des données).

La relation Client regroupe les attributs : numéroCli, nom, prénom, adresse.

Tuple

Un tuple est un objet pour lequel on a une valeur correspondant à chaque attribut d’une relation

Dans ce tableau 2 tuples sont présentés.

Clé primaire

La clé primaire est l’attribut ou les attributs d’une relation qui permettent d’identifier sans ambiguïté les différents objets de la relation. Deux objets ne peuvent avoir la même valeur de clé primaire. Pour une valeur de la clé primaire, on peut déterminer les valeurs de tous les autres attributs de la relation. Par exemple dans la relation Client, il n’y a pas 2 clients qui ont le même numéro de client (numéro unique).

Clé étrangère

Dans un schéma relationnel, les relations sont liées entre elles : un attribut est commun à deux relations. Une clé étrangère est un attribut d’une relation qui est la plupart du temps la clé primaire d’une autre relation. On détermine la relation mère et la relation fille (une mère peut avoir plusieurs filles, une fille à une seule mère), et la mère donne sa clé primaire à sa fille (qui la fait donc figurer comme clé étrangère)

 Principales règles

  • Cohérence : toute valeur prise par un attribut doit appartenir au domaine sur lequel il est défini.
  • Unicité : tous les éléments d’une relation doivent être distincts.
  • Identifiant : attribut ou ensemble d’attributs permettant de caractériser de manière unique chaque élément de la relation.
  • Clé primaire : identifiant minimum d’une relation.
  • Intégrité référentielle : cette règle impose qu’un attribut ou ensemble d’attributs d’une relation apparaisse comme clé primaire dans une autre relation.
  • Clé étrangère : attribut ou ensemble d’attributs vérifiant la règle d’intégrité référentielle.
  • Valeur nulle : dans le modèle relationnel, la notion de nullité est admise. C’est une valeur représentant une information inconnue ou inapplicable dans une colonne. Elle est notée NULL.
  • Contrainte d’entité : toute valeur participant à une clé primaire doit être non NULL.

Schéma relationnel

Le dictionnaire des données

Objectif : le dictionnaire des données récapitule l’ensemble des données d’un cas et détaille leurs caractéristiques.
Propriété : c’est une donnée élémentaire du système d’information.
Contenu : le dictionnaire des données se présente généralement sous forme de tableau dont les colonnes sont :

1 – Nom mnémonique : nom court utilisé par l’outil informatique pour désigner la donnée
2 – Signification
3 – Type (+ longueur) : texte (ou alphanumérique), numérique, date, logique
4 – observation : calculé, identifiant séquentiel, domaine de valeur, format, etc.

Il doit être précis. Par exemple, en gestion commerciale une propriété ‘quantité’ ou une propriété ‘montant’ ne sont pas assez précise (quantité commandée par un client ? quantité en stock d’un produit ? montant hors-taxe ? montant TTC ? montant de la commande passée ? montant des produits disponibles et facturés ?)
Il ne doit pas y avoir de redondances (deux propriétés qui correspondent à la même information).

Exercice  :
Commande 12345 du 01/09/2005 pour 50 stylos bleus référence B24 à 0,20 € et 20 stylos rouges référence R32 à 0,30 €, soit un total de 16 € pour le client Henri Bullant (numéro 1532) résidant au 35 rue de la Forêt 76000 Rouen
Décomposer sous forme de tableau contenant le nom, la signification, le type et l’observation éventuelle.

 

Le diagramme de classes – UML

Au delà de son utilisation pour la programmation objet, le diagramme de classe est de plus en plus utilisé pour représenter la structure des données.

On pourra utiliser les logiciels suivants :

https://online.visual-paradigm.com/login.jsp
https://yuml.me/diagram/scruffy/class/draw

La représentation des classes

Le nom de la classe est toujours au singulier avec la première lettre en majuscule. Les attributs sont représentés en deuxième partie.

Les associations entre les classes

Le sens de lecture est optionnel.. La syntaxe de spécification des cardinalités minimales et maximales est décrite dans le tableau ci-après.

Spécification Cardinalités
0..1 zéro ou une fois
1 une et une seule fois
* de zéro à plusieurs fois
1..* de un à plusieurs fois

Les classes d’association

Si on souhaite enregistrer des attributs dépendants à la fois du client et du produit pour l’action commander, il est nécessaire de réaliser une classe d’association.

 

La représentation suivante est proche. La classe d’association fait apparaitre l’existence d’une commande seulement en lien étroit avec le client et le produit. Si l’un des deux disparait, la commande disparait également. Dans la seconde représentation, la suppression d’une des deux classes ne supprime pas conceptuellement la commande. On perd également le sens de l’attribut quantité. Quantité de la commande, à rattacher grâce à la cardinalité 1..1 à un produit. L’attribut quantité n’est pas explicite dans commande avec cette notation.

Si jamais on souhaite commander plusieurs produits à chaque commande. On ne peut pas mettre la quantité dans Commande. Elle va dépendre à la fois du produit et de la commande. On réalise donc une classe d’association.

 

Complément pour la modélisation de base de données aux BTS

 

L’héritage

 

Une classe est plus spécifique qu’une autre si toutes ses instances sont également instances de cette autre classe. La classe plus spécifique est dite sous-classe ou classe fille de l’autre classe. Cette dernière, plus générale, est dite surclasse ou classe mère. Les instances d’une classe sont aussi instances de sa ou de ses surclasses. En conséquence, elles profitent des attributs et des méthodes définis dans la ou les surclasses, en plus des attributs et des méthodes introduits au niveau de leur classe. Une classe hérite des attributs et méthodes de ses surclasses pour en faire bénéficier ses instances.

UML offre quatre contraintes sur la relation d’héritage entre une classe mère et ses classes filles :

  • La contrainte {incomplete} signifie que l’ensemble des sous-classes est incomplet et qu’il ne couvre pas la surclasse ou encore que l’ensemble des instances des sous-classes est un sous-ensemble de l’ensemble des instances de la surclasse.
  • La contrainte {complete} signifie au contraire que l’ensemble des sous-classes est complet et qu’il couvre la surclasse.
  • La contrainte {disjoint} signifie que les sous-classes n’ont aucune instance en commun.
  • La contrainte {overlapping} signifie que les sous-classes peuvent avoir une ou plusieurs instances en commun (contraire de disjoint).

Représenter le diagramme de classe suivant :
Une œuvre peut être soit un livre, soit un film. Un livre peut être une BD ou un roman. Tous ces éléments ont un auteur et un titre. On souhaite aussi enregistrer les peintures avec leur mouvement respectif (gothique, renaissance, romantique et impressionniste).

Complément pour la programmation Objet

Les types et les méthodes

Pour la programmation objet, on peut ajouter les types des attributs. Les noms des méthodes sont en dernier. Un nombre élevé de méthodes et d’attributs est déconseillé. Ceci reflète un problème de conception de la classe.

Visibilité

  •  – private
  • # protected
  •  + public
  • l’absence d’indication indique une visibilité au niveau du package du projet, visibilité inférieur à public.

Navigabilité

La navigabilité permet de spécifier l’implémentation des classes. Si l’association ne peut être traversée, l’objet ne sera pas présent dans la classe.
Ici le produit ne connait pas la commande, il n’y a pas d’objets Commande dans une instance de la classe Produit.
La commande connait le produit, il y a les objets produits dans chaque instance de la commande. La collection porte le nom produits

Par défaut, l’association est navigable dans les deux sens., inutile de mettre des flèches de chaque coté.

Variable et méthode static

Elles doivent être soulignées.

Classe abstraite

Le nom doit être en italique.

Interface

La classe Personne implémente l’interface Comportement.

Dépendance

La classe SocieteDAO est dépendante de la classe Societe.

La réflexive

Il est préférable de mettre le rôle de chaque coté de l’association.

Agrégation et composition

L’agrégation : association qui définit une appartenance faible. La suppression d’un élément n’entraîne pas la suppression de ce qui lui appartient. Moins utilisé que la composition.
La composition : c’est une association qui définit une appartenance forte entre deux concepts. L’existence de l’un est liée à l’existence de l’autre dans le système modélisé.

Modéliser les relations entre les concepts suivants:

-un château de cartes
-une classe et ses élèves
-les articles du magasin, leur référence magasin, les fournisseurs auprès desquels ils peuvent être acquis, leur référence chez leurs différents fournisseurs
-une poupée russe (c’est-à-dire une série de poupées contenues les unes dans les autres)
-une voiture, son modèle, son immatriculation
-un atelier et ses machines : meule, perceuse, presse
-un livre et ses pages
-les pages web et les images qui y apparaissent
-un hôtel et ses chambres

 

 

 

 

Le diagramme des cas d’utilisation – UML

Ce diagramme permet d’avoir une vision utilisateur. Il permet de recenser les grandes fonctionnalités du système. Il est possible de représenter le système qui répond au cas d’utilisation.

Il existe principalement deux types de relations, les dépendances stéréotypées, qui sont explicitées par un stéréotype (les plus utilisés sont l’inclusion et l’extension) et la généralisation/spécialisation.
Relation d’inclusion : les inclusions permettent de décomposer un cas complexe en sous-cas plus simples.
Relation d’extension : une extension est souvent soumise à condition. Graphiquement, la condition est exprimée sous la forme d’une note.

 

Le scénario ou Use Case détaillé – UML

Un scénario est une suite d’étapes qui décrivent une interaction entre un utilisateur et un système. Ce schéma permet d’écrire l’algorithme ou de décrire une partie de son fonctionnement.

Présentation des items :

  • Les acteurs, ce sont les acteurs déclencheurs du cas.
  • La liste des parties prenantes et intérêts met l’accent sur les objectifs métiers du cas, généralement les acteurs bénéficiaires du cas.
  • Le niveau nous donne une indication de lecture (les détails que l’on s’attend ou non à trouver).
  • Les préconditions définissent les conditions de déclenchement du cas.
  • Les post-conditions déterminent ce qui est vrai après l’exécution du scénario nominal réalisé avec succès.
  • Le scénario nominal est un scénario typique de succès. Il raconte, étape par étape, l’histoire des interactions entre acteur et système, dans le meilleur des cas, ou plus précisément dans le meilleur des scénarios.
  • Les extensions correspondent aux autres scénarios possibles, avec branchements et incidents de parcours, conduisant aussi bien au succès qu’à l’échec. Ils sont de la forme <condition : étapes numérotées >.

Un cas d’utilisation peut regrouper plusieurs scénarios d’utilisation du système avec un objectif commun, celui de l’utilisateur. Un cas d’utilisation contient en général un scénario nominal (le cas le plus fréquent) et plusieurs scénarios alternatifs.

 

Les diagrammes dynamiques

Diagramme de séquence – UML

Un diagramme de séquence permet la modélisation des interactions entre objets, suite à un évènement externe. Les éléments envoient des messages (flèches de l’émetteur vers le destinataire) : acteurs externes, objets du diagramme des classes.
Un objet peut s’envoyer des messages à lui-même

Ex :

Ce type de message correspond souvent à des opérations internes significatives.

Ligne de vie

On réalise une ligne de vie pour chaque objet. Le temps se lit du haut vers le bas : creation -> suppression : X.

Ex : CompteBancaire crée Opération (et met à jour montant)

Il est possible de mettre des conditions ([condition] message)

Les diagrammes de séquence permettent de compléter le diagramme de classes en ajoutant les informations suivantes :

  • les opérations : un message ne peut être reçu par un objet que si sa classe a déclaré l’opération publique correspondante.
  • la navigabilité des associations en fonction du sens de circulation des messages ou les dépendances entre classes.

Diagramme d’états-transitions – UML

Les diagrammes d’états-transitions permettent de décrire les changements d’états d’un objet ou d’un composant, en réponse aux interactions avec d’autres objets/composants ou avec des acteurs.

États, transition et événement, notation :

états et transition

Transition conditionnelle :

transition conditionnelle

Le diagramme d’états-transitions ci-dessous, montre les différents états par lesquels passe une machine à laver les voitures.
En phase de lustrage ou de lavage, le client peut appuyer sur le bouton d’arrêt d’urgence. S’il appuie sur ce bouton, la machine se met en attente. Il a alors deux minutes pour reprendre le lavage ou le lustrage (la machine continue en phase de lavage ou de lustrage, suivant l’état dans lequel elle a été interrompue), sans quoi la machine s’arrête. En phase de séchage, le client peut aussi interrompre la machine. Mais dans ce cas, la machine s’arrêtera définitivement (avant de reprendre un autre cycle entier).

super-état et historique

  • Un super-état est un élément de structuration des diagrammes d’états-transitions (il s’agit d’un état qui englobe d’autres états et transitions).
  • Le symbole de modélisation « historique », mémorise le dernier sous-état actif d’un super-état, pour y revenir directement ultérieurement.

Diagramme d’activités – UML

UML permet de représenter graphiquement le comportement d’une méthode ou le déroulement d’un cas d’utilisation, à l’aide de diagrammes d’activités (une variante des diagrammes d’états-transitions).
Une activité représente une exécution d’un mécanisme, un déroulement d’étapes séquentielles.
Le passage d’une activité vers une autre est matérialisé par une transition.
Les transitions sont déclenchées par la fin d’une activité et provoquent le début immédiat d’une autre (elles sont automatiques).

Activités et transition, notation :

activités et transitions

Transition conditionnelle

Pour représenter des transitions conditionnelles, utilisez des gardes (expressions booléennes exprimées en langage naturel), comme dans l’exemple suivant :

transition conditionnelle

Synchronisation

Il est possible de synchroniser les transitions à l’aide des « barres de synchronisation » (comme dans les diagrammes d’états-transitions).

Une barre de synchronisation permet d’ouvrir et de fermer des branches parallèles au sein d’un flot d’exécution :

  • Les transitions qui partent d’une barre de synchronisation ont lieu en même temps.
  • On ne franchit une barre de synchronisation qu’après réalisation de toutes les transitions qui s’y rattachent.

L’exemple suivant illustre l’utilisation des barres de synchronisation : barres de synchronisation

Couloirs d’activités

Afin d’organiser un diagramme d’activités selon les différents responsables des actions représentées, il est possible de définir des « couloirs d’activités ».

Il est même possible d’identifier les objets principaux, qui sont manipulés d’activités en activités et de visualiser leur changement d’état couloirs d'activités

2018-07-03T13:46:24+00:00By |Tags: |

Leave A Comment