Bienvenue !
Pierre-Julien VILLOUD
Introduction
Une crise du logiciel est survenue dans les années 60-70
- Des délais de livraison non tenus
- Des dépassements de 50% à 70% des coûts prévisionnels
- Des anomalies techniques
- Des décalages avec les besoins du client
- Des difficultés à réaliser des évolutions
- Des difficultés à réutiliser le logiciel dans d'autres contextes de développement
- ...
Le génie logiciel
Le génie logiciel a été introduit en tant que domaine de recherche fin 1968 afin d'adresser notamment la non fiabilité des logiciels et le dépassement quasi-systématique des délais.
- L'analyse du besoin
- Les spécifications
- La modélisation
- Le développement
- Les tests
- La maintenance
Nous aborderons principalement la modélisation dans ce cours.
Où en est-on ?
45 ans après le début des travaux de recherche, les problèmes ne sont toujours pas résolus...
1995
2015
Malgré une nette amélioration, les problèmes subsistent !
La modélisation
Que se cache derrière le terme de modélisation ?
- Un modèle permet de représenter de manière simplifiée des éléments du monde réel dans le but de pouvoir le décrire, le comprendre et le prévoir.
- La modélisation permet de s'assurer de la bonne compréhension d'un système et de supprimer tous les éléments superflus.
- La modélisation est orientée vers l'objectif du projet informatique (automatiser un ensemble d'actions, fiabiliser un processus...).
- Une bonne modélisation permet de développer un logiciel évolutif et maintenable.
- La modélisation ne permet pas juste de concevoir son modèle de base de données mais toute l'architecture du système !
Une bonne modélisation est donc essentielle pour ne pas basculer dans les travers classiques des projets informatiques.
La modélisation orientée objet
Il existe plusieurs méthodes de modélisation mais nous aborderons la plus commune, la modélisation orientée objet en s'inspirant fortement de la méthode Merise.
Les étapes de la modélisation orientée objet
- Etablir les règles de gestion métiers
- Définir le dictionnaire des données
- Identifier les dépendances fonctionnelles
Ces 3 étapes permettent ensuite de définir les entités de notre système et les relations entre ces dernières. De ces entités et associations découlent notre modèle conceptuel de données qui nous permettra de définir notre base de données.
Merise
Merise est une méthode française d'analyse et de conception de SI née dans les années 70 et qui a connu un fort succès en France et en Europe.
La méthode MERISE préconise d'analyser séparément données et traitements, à chaque niveau.
Par Devaux Sullivan reproduit avec autorisation de l'auteur original — {{Source: CIM, les nouvelles perspectives de la production, Jean-Baptiste Waldner, DUNOD, 1990, reproduit avec l'autorisation de l'auteur.}}, CC BY-SA 4.0, Lien
Malgré son grand âge, cette méthode reste toujours adaptée pour les gros projets même s'il est recommandé de garder une certaine souplesse dans l'application de la méthode.
Les règles de gestion métier
Cette étape consiste à recueillir le besoin des utilisateurs (ce qui est exprimé et ce qui ne l'est pas...) en le questionnant afin d'en extraire des règles de gestion métier.
Une règle de gestion est une déclaration de haut niveau exprimant une contrainte sur un système, que ce soit en terme de donnée ou de traitement.
Pour chaque véhicule, on doit connaître la marque, le modèle, la couleur, la finition, l'immatriculation, la date de mise en circulation, le kilométrage.
Un client peut être propriétaire d'aucun, d'un ou de plusieurs véhicules.
La vente d'un véhicule augmente le chiffre d'affaire du commercial du montant du véhicule.
La recherche et l'écriture explicite de ces règles permet de réduire le risque sur le projet.
Dictionnaire de données
Le dictionnaire de données permet de regrouper toutes les données qui seront manipulées dans le SI et d'en fixer les caractéristiques.
- Le code mnémonique
- La désignation
- Le type de donnée
- La taille
- D'autres informations...
- numeroImmatriculation
- Le numéro d'immatriculation d'un véhicule permet d'identifier ce véhicule et de le rattacher à son propriétaire
- Alphanumérique avec le format : AA-NNN-AA (par exemple AB-123-CD)
- 9 caractères
- Un véhicule neuf n'ayant jamais eu de propriétaire n'a pas de numéro d'immatriculation
Ces données doivent être atomiques et ne résultant pas d'un calcul.
Dépendances fonctionnelles
Si une donnée
d1 permet de connaître la valeur d'une autre donnée d2, on dit que ces deux données sont reliées par une dépendance fonctionnelle que l'on pourra noter d1 → d2. A noter que plusieurs données peuvent permettre de connaître la valeur d'une autre d1,d2 → d3 ou à l'inverse plusieurs données peuvent être connues à partir d'une seul donnée d1 → d2,d3
idVehicule → marqueVehicule, modeleVehicule, couleurVehiculenumeroImmatriculation → idVehiculenumeroImmatriculation → dateMiseCirculationVehicule, idProprietairenumeroClient → nomClient, prenomClient, codePostalClient, villeClient, adresseClient
Une dépendance fonctionnelle doit être élémentaire (si
d1 → d3 alors d1,d2 → d3 n'est pas élémentaire ) et directe (si d1 → d2 et d2 → d3 alors d1 → d3 n'est pas directe).
Modèle conceptuel de données
Le modèle conceptuel de données ou MCD permet de représenter graphiquement les entités et les relations entre ces entités.
Voyons d'abord comment identifier les entités et leurs relations.
Les entités
Une entité ou objet ou classe est un élément concret du monde réel qui est manipulé dans le SI et sur laquelle on peut définir des propriétés ou attributs atomiques.
Exemples d'entités
- Véhicule :
idVehicule, marqueVehicule, modeleVehicule... - Client :
numeroClient, nomClient, prenomClient... - Entretien :
numeroEntretien, dateEntretien... - ?
Entité
| Véhicule |
|
idVehicule marqueVehicule modeleVehicule couleurVehicule |
Table d'occurences
| idVehicule | marqueVehicule | modeleVehicule | couleurVehicule |
| 123456 | Peugeot | 208 | Rouge |
| 123457 | Renault | Mégane | Bleu |
| ... | ... | ... | ... |
Parmi les propriétés d'une entité, on doit trouver un identifiant qui est dépendance fonctionnelle vers toutes les autres propriétés de l'entité. Ainsi, chaque occurrence ou instance de l'entité doit avoir une valeur unique pour cet identifiant.
Les associations
Une association ou relation permet de définir un lien entre une ou plusieurs entités. Cela permet de satisfaire des règles de gestion portant sur des entités différentes. Voici un exemple de relation d'aggrégation.
| Véhicule |
|
idVehicule marqueVehicule modeleVehicule couleurVehicule |
0,1 0,n
| appartient à |
|
numeroImmatriculation dateMiseCirculationVehicule |
| Client |
|
numeroClient nomClient prenomClient adresseClient |
La relation d'aggrégation appartient à entre Véhicule et Client traduit les deux règles de gestion suivantes :
Un véhicule appartient à 0 ou 1 client.
Un client possède 0 ou plusieurs véhicules.
Les cardinalités, notées
X,Y définissent le nombre d'occurences minimum X et maximum Y qui peuvent être liées. On doit donc les écrire pour les deux sens de la relation. A noter que le formalisme UML inverse la position des cardinalités...
Héritage
Il existe un autre type de relation que l'on représente différement, les relations d'héritage. On dit qu'une entité B hérite d'une entité A si B possède les mêmes attributs de A et d'autres en plus.
| Client |
|
numeroClient nomClient prenomClient adresseClient |
Est un
| ClientProfessionnel |
|
numeroSiret raisonSociale |
On utilise aussi le terme de généralisation avec un sur-type (ou entité mère, ici
Client) et de
spécialisation avec des sous-types (entités filles, ici ClientProfessionnel).
Les contraintes d'héritage
Lorsqu'il y a plusieurs entités qui héritent d'une autre entité, on peut préciser des contraintes d'héritage.
| Client |
|
numeroClient nomClient prenomClient adresseClient |
T
| ClientProfessionnel |
|
numeroSiret raisonSociale |
| ClientParticulier |
|
numeroCarteFidelite |
Héritage par couverture. Toutes les occurrences de l'entité mère se trouvent dans au moins une des entité filles existantes.
La base de données
Une fois la modélisation terminée, on peut appliquer des règles de conversion pour passer du MCD à un vrai schéma de base de données relationnelle.
- Sauf exception, toute entité du MCD devient une table dont la clé est l'identifiant de cette entité. Chaque propriété de l'entité devient également un attribut de la table correspondante.
- Lorsqu'une entité a des relations d'aggrégation de cardinalités
0/1,nde chaque côté, on a alors une relation associative et la clé primaire est constituée des identifiants des entités reliées. - Lorsqu'une entité a une relation d'aggrégation de cardinalité
0/1,1, on ajoute une clé étrangère dans la table qui correspond à l'entité se situant du côté de cette cardinalité1,1qui fera donc référence à la clé de la table correspondant à la seconde entité reliée par l'association.- L'association ne peut pas contenir d'attributs car ils seraient en dépendances fonctionnelles directes avec l'identifiant de l'entité concernée par la clé étrangère.
- L'association doit être binaire (c'est-à-dire relier uniquement deux entités et pas plus).
- Lorsque deux entités sont toutes deux reliées avec une cardinalité
1,1par une même association, on peut placer laclé étrangère de n'importe quel côté. Par convention, on choisit de la placer du côté de la relation correspondant à l'entité ayant le plus de liaisons avec les autres.
Ces règles permettent d'avoir un schéma normalisé. Néanmoins, il faut savoir garder son esprit critique et on pourra éventuellement contourner ses règles pour des raisons de simplification.
Normalisation
Il existe beaucoup de niveau de normalisation, appelées aussi formes normales. On se concentrera sur les trois premiers niveaux.
- Pour être en première forme normale (1FN ou 1NF) : Les attributs d'une relation doivent être atomiques et doivent être en dépendance fonctionnelle avec la clef primaire de cette dernière.
- Pour être en deuxième forme normale (2FN ou 2NF) : Il faut être en 1FN et que toutes les dépendances fonctionnelles entre la clef primaire et les autres attributs de la relation soient élémentaires. Autrement dit, les attributs doivent dépendre de la totalité de la clef.
- Pour être en troisième forme normale (3FN ou 3NF) : Il faut être en 2FN et que toutes les dépendances fonctionnelles entre la clef primaire de la relation et les autres attributs soient directes.
Encore une fois, ces règles doivent vous guider dans la conception de votre modèle mais il ne faut pas non plus être rigide...