EPS_GL2020-Corrigé

Examen National du Brevet de Technicien Supérieur - Session 2020

Spécialité/Option : GENIE LOGICIEL (GL)

Épreuve écrite : EPS

Crédit : 14

Durée : 6 heures

CORRECTION DÉTAILLÉE

Introduction

Ce document présente une correction détaillée de l’épreuve écrite d’EPS (Génie Logiciel) de la session 2020 du Brevet de Technicien Supérieur. L’épreuve est divisée en trois parties : modélisation structurée MERISE, modélisation orientée objet UML, et algorithmique avec structures de données avancées.

1 Partie 1 : Modélisation structurée « MERISE » (25 points)

1.1 A.1 – Délimitation du champ d’étude (2 points)

Le champ d’étude couvre le processus de gestion des expéditions de colis au sein de l’agence de messagerie PTA, depuis la prise en charge d’un colis jusqu’à la facturation des clients réguliers (CR). Il inclut :

• La différenciation des clients (CR et CT).


• La création et la circulation du Document de Transport (DT) en quatre exemplaires.


• Les étapes de réception, livraison et retour des DT.


• Le traitement des DT pour l’établissement des factures mensuelles des clients CR.


• Le contrôle des factures par la direction et l’envoi aux clients.


• La gestion des réclamations des clients CR.

Note : Les acteurs impliqués sont : l’expéditeur, le destinataire, l’agence d’expédition, l’agence réceptrice, le service des opérations statistiques et logistiques (SOSI), le département de messagerie et logistique (DML), la direction générale (DG), la direction administrative et financière (DAF) et la direction du contrôle opérationnel (DCO).

1.2 A.2 – Diagramme de circulation des informations (DCI) (5 points)

Le DCI décrit les flux d’informations entre les acteurs et les postes de travail. Ci-dessous une description textuelle schématisée :

Expéditeur → Agence expédition : fournit informations

Agence expédition → DT (4 exemplaires) : création

DT (2 exemplaires) → Colis : accompagnent le colis

Agence réception → DT : mentions de réception

Destinataire → DT : mentions de livraison

DT (original) → Direction générale : retour

DT → SOSI : dépouillement et classement

DT (CR) → DML : transmission

DML → Facture : établissement

Direction (DG, DAF, DCO) → Facture : contrôle

Facture visée → Client CR : envoi avec DT

Client CR → DML : décharge et réclamations éventuelles

1.3 A.3 – Modèle Conceptuel des Données (MCD) (10 points)

Entités :

• CLIENT : (NumClient, Nom, Prénom, Type [CR, CT], Adresse, Téléphone)


• COLIS : (NumColis, Poids, Dimensions, ValeurDéclarée)


• DOCUMENT_TRANSPORT : (NumDT, DateCréation, Statut [Créé, Expédié, Livré, Retourné])


• EXPEDITION : (NumExpédition, DateExpédition, Frais, AgenceDestination)


• LIVRAISON : (NumLivraison, DateLivraison, SignatureDestinataire)


• FACTURE : (NumFacture, DateFacture, MontantTotal, Statut [Visée, Rejetée])


• AGENCE : (CodeAgence, NomAgence, Adresse, Téléphone)


• DESTINATAIRE : (NumDestinataire, Nom, Prénom, Adresse, Téléphone)

Associations :

• Effectuer : CLIENT (1,1) – (0,n) EXPEDITION


• Concerner : EXPEDITION (1,1) – (1,1) COLIS


• Documenter : EXPEDITION (1,1) – (4,4) DOCUMENT_TRANSPORT


• Destiner : EXPEDITION (1,1) – (1,1) DESTINATAIRE


• Livrer : EXPEDITION (1,1) – (0,1) LIVRAISON


• Facturer : CLIENT (1,1) – (0,n) FACTURE (pour les clients CR seulement)


• Traiter : AGENCE (1,1) – (0,n) EXPEDITION (agence d’expédition)


• Recevoir : AGENCE (1,1) – (0,n) LIVRAISON (agence de réception)

1.4 A.4 – Règles de passage du MCD au MLDR (3 points)

1. Une entité devient une table avec ses attributs. L’identifiant de l’entité devient la clé primaire de la table.


2. Une association de type 1,1 – 1,n ou 1,1 – 0,n peut être traduite par l’ajout d’une clé étrangère dans la table du côté « n » ou « 0,n » qui référence la table du côté « 1 ».


3. Une association de type 1,1 – 1,1 peut être fusionnée dans l’une des deux tables, ou créée comme une table séparée avec les clés des deux entités.


4. Une association de type n,n devient une table de liaison avec les clés des deux entités et les éventuels attributs de l’association.


5. Les attributs composites sont éclatés en attributs simples.


6. Les attributs multivalués deviennent des tables séparées.

1.5 A.5 – Modèle Logique de Données Relationnelles (MLDR) (5 points)

CLIENT (NumClient, Nom, Prénom, Type, Adresse, Téléphone)

COLIS (NumColis, Poids, Dimensions, ValeurDéclarée, NumExpédition)

DOCUMENT_TRANSPORT (NumDT, DateCréation, Statut, NumExpédition)

EXPEDITION (NumExpédition, DateExpédition, Frais, AgenceDestination, NumClient, NumDestinataire, CodeAgenceExp, CodeAgenceDest)

LIVRAISON (NumLivraison, DateLivraison, SignatureDestinataire, NumExpédition, CodeAgence)

FACTURE (NumFacture, DateFacture, MontantTotal, Statut, NumClient)

AGENCE (CodeAgence, NomAgence, Adresse, Téléphone)

DESTINATAIRE (NumDestinataire, Nom, Prénom, Adresse, Téléphone)

TRAITEMENT_FACTURE (NumFacture, NumDT) -- table de liaison si nécessaire

2 Partie 2 : Modélisation orientée objet « UML » (25 points)

2.1 B.1 – Définitions (3 points)

UML (Unified Modeling Language) : Langage de modélisation graphique standardisé utilisé pour visualiser, spécifier, construire et documenter les artefacts d’un système logiciel.

Classe : Description d’un ensemble d’objets partageant les mêmes attributs, opérations, relations et sémantique. Une classe est un modèle pour créer des objets.

Objet : Instance d’une classe, représentant une entité concrète avec un état (valeurs des attributs) et un comportement (méthodes).

Cas d’utilisation (Use Case) : Description d’une séquence d’actions que le système doit exécuter, offrant un résultat observable à un acteur. Il capture les exigences fonctionnelles.

2.2 B.2 – Diagramme des classes (8 points)

(La correction indique un diagramme de classes avec les classes suivantes : Client, Expédition, Colis, DocumentTransport, Livraison, Facture, Agence, Destinataire. Les relations sont décrites dans le MCD précédent.)

2.3 B.3 – Diagramme des cas d’utilisation (8 points)

Les cas d’utilisation identifiés :

• Déclarer expédition


• Gérer facturation (pour clients CR)


• Traiter livraison


• Contrôler facture


• Gérer réclamation


• Authentifier utilisateur

Acteurs : Client (CR, CT), Employé agence, Responsable DML, Direction (DG, DAF, DCO).

2.4 B.4 – Relations entre cas d’utilisation (4 points)

Inclusion (« include ») : Un cas d’utilisation inclut un autre cas d’utilisation. Exemple : « Générer facture » inclut « Calculer frais ».

Extension (« extend ») : Un cas d’utilisation peut être étendu par un autre sous certaines conditions. Exemple : « Contrôler facture » peut être étendu par « Rejeter facture » si des anomalies sont détectées.

2.5 B.5 – Relations entre acteurs externes et cas d’utilisation (2 points)

Les acteurs externes sont en relation d’association avec les cas d’utilisation. Cette association signifie que l’acteur interagit avec le système via le cas d’utilisation. Exemple : L’acteur « Client » est associé au cas d’utilisation « Déclarer expédition ».

3 Partie 3 : Algorithmique et structure de données avancées (20 points)

On souhaite automatiser la gestion des expéditions. Les informations sont :

• Client : numéro, nom, prénom, type (CR ou CT).


• Expédition : numéro, agence destination, nom destinataire, numéro destinataire, date, frais, numéro client (expéditeur).


• Contraintes : maximum 10 000 enregistrements pour clients et colis.

3.1 Structures de données proposées (pseudo-code)

Constante MAX = 10000



Type Client = Structure

    numClient : Entier

    nom, prenom : Chaîne

    type : Chaîne // "CR" ou "CT"

FinStructure



Type Expedition = Structure

    numExpedition : Entier

    agenceDestination : Chaîne

    nomDestinataire : Chaîne

    numDestinataire : Entier

    dateExpedition : Date

    frais : Réel

    numClient : Entier

FinStructure



Tableau clients[1..MAX] de Client

Tableau expeditions[1..MAX] de Expedition

Entier nbClients, nbExpeditions



Procédure ajouterClient(nom, prenom, type)

    Si nbClients < MAX Alors

        nbClients