TD 3 : Spécification et Modélisation

Exercice 1 - Examen de la session de contrôle 2011-2012

Question 1 - Définition du diagramme de contexte

Le diagramme de contexte (qui correspond au niveau 0 d'un diagramme de flots de données) définit la frontière du système d'information étudié et ses interactions avec l'environnement extérieur. Il modélise le système comme un processus unique et global (une « boîte noire ») et identifie les entités externes (acteurs, autres systèmes) avec lesquelles il communique, ainsi que la nature des flux de données entrants et sortants.

Question 2 - Diagramme de contexte du système de suivi

Dans un examen écrit, ce diagramme prend la forme d'un schéma. Voici la description textuelle exacte des éléments qui doivent figurer sur votre graphe :

Processus central (Le système) :

• Système de suivi des projets et de paiement (Processus 0)

Entités externes (Acteurs) :

1. Professionnel
2. Direction
3. Système de paiement (mentionné dans le texte comme étant alimenté par une disquette)
4. Système de facturation (mentionné de la même façon)
5. Horloge (acteur non humain explicitement mentionné : "à l'aide d'une horloge")
   • Note : On pourrait aussi considérer le "Client" comme entité externe si l'on suppose qu'il interagit avec notre système, mais le texte précise bien que le système produit une disquette pour le système de facturation aux clients. Il est donc plus rigoureux de relier notre système au système de facturation.

Flux de données (Les flèches orientées) :

• De Professionnel vers Système : Feuille de temps (contenant : num professionnel, num projet, type de tarification, temps consacré, frais de déplacement, frais de séjour).
• De Horloge vers Système : Unités de temps / Impulsions temporelles.
• De Système vers Direction : Bilan mensuel d'activités par projet.
• De Système vers Système de paiement : Disquette de paiement.
• De Système vers Système de facturation : Disquette de facturation.

Exercice 2 - Système de gestion de location de voitures « LOC »

Question 1 - Rôle d'un diagramme de flux de données (DFD)

Le diagramme de flux de données sert à cartographier le cheminement des informations au sein d'un système. Son rôle est d'identifier les processus qui transforment les données, les flux d'informations qui transitent entre ces processus, les entités externes qui émettent ou reçoivent des données, et les mémoires (stocks de données) où les informations sont conservées. Il permet de comprendre « ce que fait » le système de manière logique.

Question 2 - Diagramme de contexte du système « LOC »

Pour dessiner ce diagramme de niveau 0 :

• Processus central : Système de gestion de location de voitures « LOC »
• Entités externes : Client
• Flux de données :
  • Client vers Système : Demande de location (date de prise de possession, caractéristiques de la voiture, coordonnées du client).
  • Système vers Client : Contrat de location, Facture.
  • Client vers Système (implicite d'après l'énoncé, lors de la facturation) : On peut ajouter un flux "Paiement / Accord", bien que le texte s'arrête à "générant une facture". S'en tenir aux flux explicites est souvent plus sûr.

Question 3 - DFD Niveau 1 du système « LOC »

En lisant l'énoncé, on peut extraire trois grandes actions qui deviennent nos processus de niveau 1.

• Processus 1 : Chercher voiture
  • Flux entrant : Demande de location (depuis l'entité externe Client).
  • Stockage utilisé : Parc de voitures / Stock véhicules (pour vérifier les caractéristiques et les dates).
  • Flux sortant : Voiture disponible (vers le processus 2).
• Processus 2 : Établir contrat de location
  • Flux entrant : Voiture disponible (venant de P1), Coordonnées du client.
  • Stockages utilisés : Base Clients (pour enregistrer le client), Base Contrats (pour enregistrer le contrat).
  • Flux sortant : Contrat de location (vers l'entité externe Client), Informations du contrat (vers le processus 3).
• Processus 3 : Facturer la location
  • Flux entrant : Informations du contrat (venant de P2).
  • Flux sortant : Facture (vers l'entité externe Client).

Question 4 - Rôle d'un dictionnaire de données (DD)

Le dictionnaire de données est un référentiel qui définit de manière précise et univoque l'ensemble des données (flux et stockages) figurant dans les DFD. Il décrit la structure, la signification, le format et les règles de composition de chaque élément d'information, évitant ainsi toute ambiguïté lors du développement.

Question 5 - Dictionnaire de données pour une demande de location

En utilisant le formalisme classique de composition (le signe "+"), la description d'une demande de location tirée du texte est :

Demande de location = Date de prise de possession souhaitée + Caractéristiques de la voiture + Coordonnées du client.

Si l'on veut détailler selon les règles habituelles, on pourrait ajouter (bien que non exigé formellement par le texte) : Coordonnées du client = Nom + Prénom + Adresse + Téléphone.

Question 6 - Rôle d'un diagramme États-Transitions (E-T)

Le diagramme États-Transitions modélise le comportement dynamique d'une entité (ou d'un objet) au cours du temps. Il décrit l'ensemble des états possibles que peut prendre cette entité et les événements (ou conditions) qui déclenchent le passage (la transition) d'un état à un autre.

Question 7 - Diagramme États-Transitions pour une location

Voici les transitions logiques entre les états fournis dans l'énoncé. Dans votre copie, ce cheminement prend la forme de rectangles (états) reliés par des flèches (transitions déclenchées par des événements).

1. État initial (point de départ).
2. Événement : Réception de la demande de location.
3. État : Demandée
4. Événement : La voiture cherchée est disponible.
5. État : Confirmée
6. Événement : Établissement du contrat avec les coordonnées du client.
7. État : Enregistrée
8. Événement : Génération de la facture / Le client paie.
9. État : Payée
10. État final.

Cas particulier de l'état "Annulée" :

• Événement : Demande d'annulation par le client ou indisponibilité de la voiture.
• Transition : Les états Demandée, Confirmée, ou Enregistrée peuvent pointer vers l'état Annulée, qui mène ensuite vers l'état final.

Exercice 3 - Système de gestion des ventes

Question 1 - Diagramme de contexte de la gestion des ventes

L'analyse du texte nous donne les interactions de l'ensemble de la gestion des ventes avec son environnement.

• Processus central : Système de gestion des ventes
• Entités externes :
  1. Client
  2. Gestion des stocks
  3. Gestion comptabilité
  4. Gestion du personnels (ou "des personnels" selon l'énoncé)
• Flux de données :
  • Client vers Système : Ordre d'achat (commande), Règlement.
  • Système vers Client : Facture.
  • Système vers Gestion des stocks : Bon de livraison.
  • Gestion des stocks vers Système : Informations sur stocks, Informations sur les livraisons en cours.
  • Système vers Gestion comptabilité : Informations des montants de vente.
  • Gestion du personnels vers Système : Coordonnées des personnels.
  • Système vers Gestion du personnels : Informations de rémunération.

Question 2 - Diagramme de Flux de Données (DFD) Niveau 1

Ici, on "ouvre" la boîte du système de gestion des ventes. Le texte divise explicitement ce système en trois services qui deviennent nos trois processus.

• Processus 1 : Gestion des commandes
  • Entrant : Ordre d'achat (de Client), Infos sur stocks et livraisons (de Gestion des stocks).
  • Sortant : Bon de livraison (vers Gestion des stocks), Double commande (vers Processus 2), Double bon de livraison (vers Processus 2).
• Processus 2 : Gestion des factures
  • Entrant : Double commande (de P1), Double bon de livraison (de P1), Règlement (de Client).
  • Sortant : Facture (vers Client), Informations des montants de vente (vers Gestion comptabilité), Informations de ventes (vers Processus 3).
• Processus 3 : Gestion de la force de vente
  • Entrant : Informations de ventes (de P2), Coordonnées des personnels (de Gestion du personnels).
  • Sortant : Informations de rémunération (vers Gestion du personnels).

Question 3 - DFD Niveau 2 de la gestion de commandes

On zoome cette fois sur le "Processus 1 : Gestion des commandes". L'énoncé précise : "Une commande est un ordre d’achat passé par un client qui va être traité, enregistré et préparé par la gestion de commandes". Nous avons donc nos trois sous-processus.

• Processus 1.1 : Traiter la commande
  • Entrant : Ordre d'achat (du Client), Infos sur stocks (de la Gestion des stocks - pour valider si on peut traiter).
  • Sortant : Commande validée (vers le processus 1.2).
• Processus 1.2 : Enregistrer la commande
  • Entrant : Commande validée (de 1.1).
  • Stockage : Accès en écriture à une base/fichier "Commandes en cours".
  • Sortant : Commande enregistrée (vers le processus 1.3).
• Processus 1.3 : Préparer la commande
  • Entrant : Commande enregistrée (de 1.2).
  • Sortant : Bon de livraison (vers l'entité externe Gestion des stocks), Double commande et Double bon de livraison (vers le processus Gestion des factures).

Méthode

Face à une épreuve de modélisation systémique (DFD, diagramme de contexte) :

1. Lisez l'énoncé avec un surligneur : Une couleur pour les acteurs (les entités externes au système), une couleur pour les flux d'information (les documents, données, validations), et une couleur pour les actions (les verbes d'action qui deviendront les processus).
2. Respectez les frontières du système : Ne modélisez jamais les processus internes à une entité externe. Si le texte dit "le service comptabilité traite les salaires avec vos données", votre système s'arrête à l'envoi des données à la comptabilité.
3. Conservation des flux : C'est la règle d'or des DFD. Tout flux sortant du niveau 0 (diagramme de contexte) doit impérativement se retrouver en flux sortant vers une entité externe dans le niveau 1, et de même pour les niveaux inférieurs. Le niveau inférieur "éclate" le processus mais ne modifie pas ses interfaces avec l'extérieur.
4. Vocabulaire de l'énoncé : Nommez vos processus, entités et flux exactement avec les mots du texte (ex: "ordre d'achat" et non "demande client"). Le correcteur évalue votre capacité à traduire un cahier des charges spécifique, pas à inventer un système générique.