Exercice Gestion des contrats Facturation

Présentation au sujet: "Exercice Gestion des contrats Facturation"— Transcription de la présentation:

1 Exercice Gestion des contrats Facturation
06/11/00 Exercice Faites le MCD (Modèle conceptuel de données) de la gestion des contrats de ECRIT-SOFT, entreprise de conception et réalisation de logiciels. Le MCD doit contenir les informations qui permettront de faire la facturation. Nous postulons que la facturation est réalisée par un sous-système différent de celui de la gestion des contrats. Le MCD doit être sans redondance. Gestion des contrats Transmet les données De facturation Facturation Ecrit-Soft possède environ 50 clients qui lui confient des mandats, un mandat n’est accepté que s’il peut être réalisé dans un délai maximal de 3 mois. Un mandataire commercial de l’entreprise est chargé de conclure les mandats; lorsqu’il a signé un mandat, il remet le contrat au directeur qui en confie la réalisation à un chef de projet. Le chef de projet bénéficie de la collaboration d’un ou plusieurs programmeurs; un seul pour les petits projets et un maximum de 5 personnes de qualifications diverses pour les projets d’envergure. Chaque contrat se termine par l’envoi d’une facture au client. La facture doit mentionner la date de facturation, le montant de la facture, les nom et adresse du client, le descriptif du mandat, la date de signature du contrat, les dates de début et de fin de réalisation, les noms du mandataire commercial et du chef de projet; le montant de la facture est calculé en multipliant le nombre d’heures passées pour chaque collaborateur par le prix horaire de facturation qui lui est affecté en fonction de sa qualification dans l’entreprise. Le temps passé par le mandataire commercial et par le chef de projet est aussi pris en compte pour la facturation, en utilisant la même règle de calcul. Un employé peut fonctionner comme chef de projet pour un mandat et comme collaborateur pour un autre; dans les 2 cas, le taux de facturation est identique puisqu’il est lié à la qualification et non à une fonction. Remarque : Il ne faut pas tenir compte d’événements non explicitement décrits tels que : Changement du prix horaire de facturation. Changement de chef de projet en cours de réalisation. 06/11/00 ANA-02 V0-0 ANA-02 V0-0

2 Interfaçage de sous-systèmes
06/11/00 Interfaçage de sous-systèmes Dans une situation réelle, il y aurait lieu de définir précisément les modalités d’échange d’informations entre les 2 sous-systèmes: de gestion des contrats et de facturation. Souvent, c’est le système de facturation qui définit les modalités de l’échange en passant par l’intermédiaire de tables d’interfaçage. Zone d’interfaçage Gestion des contrats Facturation Clients Nous admettons pour cet exercice, que la date de facture et le montant de la facture sont gérés par le sous-système de facturation. Les données relatives au client et au mandat sont transmises par le sous-système de gestion des mandats. La structure de la base de données du sous-système de gestion des contrats ne devra contenir que les informations liées aux clients et celles liées aux modalités de réalisation du contrat. Elements de facturation 06/11/00 ANA-02 V0-0 ANA-02 V0-0

3 MCD (AMC*Designor) Solution A
06/11/00 MCD (AMC*Designor) Solution A Les termes « Mandats » et « Projets » sont considérés comme synonymes. Dans une vision contractuelle, Ecrit-Soft parle de mandats et dans une vision de réalisation le terme de projet prévaut. L’attribut Code a été rajouté à l’entité REMUNERATION pour servir de clé secondaire. La clé secondaire sert d’accès aux occurrences d’entités lorsque la clé primaire n’est pas significative. Un employé peut jouer un ou plusieurs rôles: Mandataire, Chef de projet ou Programmeur. Ce modèle est simple, il colle aux règles énoncées. Il permet une réalisation exempte de difficultés. 06/11/00 ANA-02 V0-0 ANA-02 V0-0

4 MCD (AMC*Designor) Solution B
06/11/00 MCD (AMC*Designor) Solution B L’entité ROLE doit contenir les occurrences correspondant aux divers rôles des employés {Mandataire, Chef de projet, Programmeur}. Chaque occurrence de l’association COLLABORE doit contenir un lien sur chacune des 3 entités: MANDAT, EMPLOYE et ROLE. Ce modèle prend en compte d’éventuelles évolutions des règles de réalisation d’un mandat. Ainsi, si Ecrit-Soft souhaite créer une fonction de documentaliste ou autre, il suffit de rajouter des occurrences dans l’entité ROLE. L’attribut LienProg va nous servir à mettre en place les contraintes d’intégrité que nous avions sur le modèle précédent. Tout mandat doit être: conclu par un et un seul mandataire; conduit par un et un seul chef de projet; réalisé par au moins un programmeur. 06/11/00 ANA-02 V0-0 ANA-02 V0-0

5 MCD (AMC*Designor) Solution C
06/11/00 MCD (AMC*Designor) Solution C L’entité MANDAT représente l’aspect contractuel de l’engagement pris par le client et le mandataire. L’entité PROJET représente les éléments techniques de réalisation du mandat. Un mandat peut être enregistré sans être lié à un projet; ainsi, le projet peut être défini postérieurement à l’enregistrement du mandat. Par contre, pour respecter la donnée, un projet est toujours associé à un et un seul mandat. Nous pourrions redistribuer les propriétés de l’entité MANDAT entre MANDAT et PROJET. Ce modèle permet de dissocier les aspects contractuels d’une part et de réalisation du mandat par un projet d’autre part. Les contraintes liées aux rôles de mandataire et de chef de projet sont explicites; par contre, l’association COLLABORE et l’entité ROLE permettent de garantir l’évolutivité du modèle par la création de nouvelles occurrences de rôle qui initialement ne contient que la valeur « Programmeur ». 06/11/00 ANA-02 V0-0 ANA-02 V0-0

6 Univalué Discrimant Stable Minimal Identifiant
06/11/00 Identifiant Univalué Client  Discrimant Stable La valeur d’identifiant reste identique pendant toute la vie d’occurrence d’entité. Chaque occurrence d’entité doit pouvoir être identifiée sans ambiguïté à l’aide d’un identifiant. Chaque valeur d’identifiant doit être unique (pour une entité), stable et discriminant. Souvent, il n’est pas possible de trouver parmi les attributs d’entités ceux qui satisfont aux exigences énoncées. Nous créons, alors, une propriété artificielle que, par référence au modèle relationnel des bases de données, nous nommons: Clé primaire. Minimal Un minimum d’attributs 06/11/00 ANA-02 V0-0 ANA-02 V0-0

7 Toute entité comporte un identifiant unique « Numero » auto-séquencé.
06/11/00 Clé primaire Toute entité comporte un identifiant unique « Numero » auto-séquencé. La clé primaire ne doit jamais changer de valeur car elle sert de référence pour l’établissement des liens entre occurrences d’entités dans une vision d’implémentation par un modèle relationnel. 06/11/00 ANA-02 V0-0 ANA-02 V0-0

8 Clés secondaires ou alternatives
06/11/00 Clés secondaires ou alternatives Toute entité doit disposer d’une clé d’accès significative pour les utilisateurs. Identifiant unique (clé primaire pour des individus). Clé secondaire pour les entités dont la clé primaire a comme fonction d’établir les liens entre tables du modèle relationnel. Propriété « Code » de type alphanumérique lorsqu’aucun élément n’est proposé par les utilisateurs. Par opposition à la clé primaire, une clé secondaire peut changer de valeur pendant la durée de vie de l’occurrence d’entité qu’elle référence. Selon les cas, une clé secondaire ou alternative peut être: Unique ou pas; contrainte UNIQUE Renseignée ou pas; contrainte NOT NULL Par exemple et selon l’exemple ci-dessus: CLIENT.Nom serait une clé secondaire non unique mais obligatoirement renseignée. REMUNERATION.Code est une clé secondaire unique et obligatoirement renseignée. 06/11/00 ANA-02 V0-0 ANA-02 V0-0

9 Lien entre structure statique et dynamique
06/11/00 Lien entre structure statique et dynamique Si une contrainte de structure de données doit se faire pour des occurrences d’entités particulières il faut disposer d’une information stable pour les identifier sans équivoques. Nous créons pour ce faire une propriété non modifiable « LienProg » de type alphanumérique. Par exemple, au niveau d’une gestion scolaire, nous mettrions ESNIG comme code d’une école. Si nous écrivons des contraintes de style: IF (ECOLE.Code = ‘ESNIG’) THEN /* Corps de la contrainte */ nous devrions revoir notre programme au cas où l’ESNIG deviendrait ENIG ou HESNIG! En initialisant la propriété LienProg avec la valeur initiale de Code WHEN Insert /* Trigger sur ajout */ Ecole.LienProg := Ecole.Code et en écrivant la contrainte avec la propriété LienProg IF (ECOLE.LienProg = ‘ESNIG’) THEN nous pouvons modifier la propriété Code à notre guise sans altérer les contraintes. 06/11/00 ANA-02 V0-0 ANA-02 V0-0

10 Date – Attribut ou entité?
06/11/00 Date – Attribut ou entité? Lorsque la date nous intéresse sous forme d’une simple valeur temporelle nous la modélisons sous forme d’attribut d’entité. Les propriétés peuvent porter un attribut indiquant l’optionalité ou non d’une valeur; cet attribut remplace l’information portée par la cardinalité minimale de l’association entre une entité quelconque et une entité DATE. Si l’entité DATE comporte comme seul attribut la date, l’approche anglo-saxone veut que cette entité soit remplacée par un attribut pour chacune des associations. Par contre, si nous avons une entité qui comporte d’autres propriétés que la date, il est alors utile de créer une entité, par exemple: L’entité JOUR représente des jours calendaires pour lesquels nous pouvons indiquer s’il s’agit de jours fériés ou de vacances. 06/11/00 ANA-02 V0-0 JOUR Date Ferie Vacances ANA-02 V0-0

11 06/11/00 Espace de nommage Les modèles entités-associations, tout comme le langage SQL de manipulation des bases de données relationnelles, attribuent des espaces de nommages aux entités et associations. L’espace de nommage est défini dans le langage SQL par l’opérateur d’indirection ‘.’ entre le nom de la table et le nom du champ: NomDeTable.NomDeChamp Exemple: EMPLOYE.Nom CLIENT.Nom 06/11/00 ANA-02 V0-0 ANA-02 V0-0

12 Comparaison des 3 solutions
06/11/00 Comparaison des 3 solutions Simplicité Evolutivité Robustesse A ++ -- + B - C Les 3 solutions respectent le cahier des charges énoncé dans la donnée; toutefois, chacune des 3 solutions présente un certain nombre d’avantages et d’inconvénients qu’il s’agit d’évaluer avant de choisir une version définitive. Le critère de simplicité permet de réduire les coûts de réalisation du logiciel. A est la solution la plus simple C nécessite la création de tables et de liens supplémentaires Le critère d’évolutivité permet de prendre en compte des besoins non exprimés. Avec A, la définition des rôles des employés ne pourra pas changer B permet d’ajouter et aussi de supprimer des rôles C permet d’ajouter des rôles Le critère de robustesse traduit la facilité de mise en œuvre des contraintes énoncées. La solution B ne permet de garantir la prise en compte des rôles obligatoires et uniques de mandataire et de chef de projet que par l’intermédiaire de contraintes difficiliment implémentable. 06/11/00 ANA-02 V0-0 ANA-02 V0-0

13 06/11/00 Les dates Conceptuellement les dates peuvent être modélisées sous forme d’entités. Néanmoins cette manière de faire est sujette à discussion: Une date est un type comme un autre (caractère, chaîne de caractère, entier..) alors pourquoi la traiter différemment? Les multiples associations liant les différentes entités à une entité Date alourdissent inutilement la lecture des diagrammes. La transformation automatique des entités en tables lors du passage au modèle logique de données provoquera la création d’une table Date inutile et redondante car tous les SGBD gèrent un type Date. Pour ces différentes raisons, nous conseillons de remplacer les couples (entité Date, association) par de simples attributs de type date dans tous les modèles conceptuels de données. Comme déjà indiqué, le caractère optionnel ou obligatoire de l’association Date peut être pris en compte par le même critère de la propriété Date. 06/11/00 ANA-02 V0-0 ANA-02 V0-0

14 MLD (AMC*Designor) Solution A
06/11/00 MLD (AMC*Designor) Solution A 06/11/00 ANA-02 V0-0 ANA-02 V0-0

15 MLD (AMC*Designor) Solution B
06/11/00 MLD (AMC*Designor) Solution B 06/11/00 ANA-02 V0-0 ANA-02 V0-0

16 MLD (AMC*Designor) Solution C
06/11/00 MLD (AMC*Designor) Solution C 06/11/00 ANA-02 V0-0 ANA-02 V0-0

17 Ecran de saisie MS-ACCESS (A)
06/11/00 Ecran de saisie MS-ACCESS (A) 06/11/00 ANA-02 V0-0 ANA-02 V0-0

18 MCD (AMC*Designor) Solution A étendue
06/11/00 MCD (AMC*Designor) Solution A étendue 06/11/00 ANA-02 V0-0 ANA-02 V0-0

19 MCD (AMC*Designor) Solution B étendue
06/11/00 MCD (AMC*Designor) Solution B étendue 06/11/00 ANA-02 V0-0 ANA-02 V0-0

20 MCD (AMC*Designor) Solution C étendue
06/11/00 MCD (AMC*Designor) Solution C étendue 06/11/00 ANA-02 V0-0 ANA-02 V0-0