CONCEPTION ET REALISATION D’UN LOGICIEL DE GESTION DE …

MINISTERE DE L’EDUCATION NATIONALE ET DE LA RECHERC HE

UNIVERSITE D’ANTANANARIVOECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENTS FILIERE

Mémoire de fin d’études en vue de l’obtention du Diplôme d’Ingénieur en

CONCEPTION ET REALISATION D’UN

LOGICIEL DE GESTION DE PARC

Présenté et soutenu par : MAHAIMALALA Rinah

Directeur de mémoire : Monsieur ANDRIAMANOHISOA HeryZo

Enseignant Chercheur à l’Ecole Supérieure Polytechnique Antananarivo

Date de soutenance : 16 Sept 2011

Promotion : 2010

MINISTERE DE L’EDUCATION NATIONALE ET DE LA RECHERC HE SCIENTIFIQUE

UNIVERSITE D’ANTANANARIVO ECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENTS : GENIE MECANIQUE ET PRODUCTIQUE GENIE ELECTRIQUE

FILIERE : GENIE INDUSTRIEL

Mémoire de fin d’études en vue de l’obtention du Diplôme d’Ingénieur en Génie Industriel



AUTOMOBILE

MAHAIMALALA Rinah

Monsieur ANDRIAMANOHISOA HeryZo


16 Sept 2011


: GENIE MECANIQUE ET PRODUCTIQUE






UNIVERSITE D’ANTANANARIVOECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENTS FILIERE




Présenté par : MAHAIMALALA Rinah

Président du jury :Monsieur RANARIJAONA Jean Désiré

Examinateurs : - Monsieur RAMAHAROBANDRO Germain

- Monsieur RAMELINA Lala Arimonjy

Directeur de mémoire : Monsieur ANDRIAMANOHISOA HeryZo,

Enseignant Chercheur à l’ESPA

MINISTERE DE L’EDUCATION NATIONALE ET DE LA RECHERC HE SCIENTIFIQUE

UNIVERSITE D’ANTANANARIVO ECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENTS : GENIE MECANIQUE ET PRODUCTIQUE GENIE ELECTRIQUE

FILIERE : GENIE INDUSTRIEL

Mémoire de fin d’études en vue de l’obtention du Diplôme d’Ingénieur en Génie Industriel



AUTOMOBILE

MAHAIMALALA Rinah

RANARIJAONA Jean Désiré, Enseignant Chercheur à l’ESPA.

RAMAHAROBANDRO Germain, Enseignant Chercheur à

RAMELINA Lala Arimonjy, Enseignant Chercheur à l’ESPA

Monsieur ANDRIAMANOHISOA HeryZo,

Enseignant Chercheur à l’ESPA

Promotion : 2010


: GENIE MECANIQUE ET PRODUCTIQUE




, Enseignant Chercheur à l’ESPA.

Chercheur àl’ESPA

i

REMERCIEMENTS

A l’occasion de l’achèvement de ce mémoire de fin d’études, je tiens à exprimer mes vifs

remerciements à :

� Dieu Tout Puissant, sans lui je n’aurais pas pu atteindre ce stade.

� Monsieur ANDRIANARY Philippe, Directeur de l’Ecole Supérieure Polytechnique

d’Antananarivo, qui a toujours contribué ses expériences professionnelles pour réussite

de notre formation.

� MessieursRAKOTOMANANA Charles Rodin et RAKOTONIANAINA SolofoHery,

respectivement Chef de Département Génie Mécanique et Productique et Chef de

Département Génie Electrique de la filière Génie industriel, qui ont assumé leur

responsabilité dans le bon fonctionnement des enseignements au sein du département.

� Monsieur ANDRIAMANOHISOA HeryZo, Enseignant à l’ESPA, encadreur du

présent mémoire, pour son dévouement et ses conseils lors de ce travail.

� Monsieur RANARIJAONA Jean Désiré, Enseignant à l’ESPA, qui a eu la

bienveillance de présider les membres de jury de la soutenance de ce mémoire.

� Monsieur RAMAHAROBANDRO Germain, Enseignant à l’ESPA, Monsieur

RAMELINA Lala Arimonjy, Enseignant à l’ESPA, qui ont voulu examiner ce travail,

malgré leurs multiples occupations.

� Tous les enseignants de l’Ecole Supérieure Polytechnique d’Antananarivo qui ont

contribué à notre formation dans cette école ;

� Mes chers parents qui n’ont pas cessé de me soutenir aussi bien financièrement que

moralement au cours de mes longues études.

� Toute ma famille, tous mes amis et tous ceux qui ont contribué de près ou de loin à la

réalisation de ce mémoire.

ii

TABLE DES MATIERES

Remerciements ............................................................................................................................ i

Table des matières ...................................................................................................................... ii

Liste des tableaux ...................................................................................................................... iv

Liste des figures ........................................................................................................................ vi

Liste des abréviations ................................................................................................................ vi

Introduction ................................................................................................................................ 1

Chapitre I : NOTION SUR LE LANGAGE UML (Unified Modeling Language) .................. 2

I.1 INTRODUCTION ............................................................................................................. 2

I.2 HISTORIQUE ................................................................................................................... 2

I.3 LA VUE "4+1" DE KRUCHTEN ..................................................................................... 3

I.4 DIAGRAMMES UML ...................................................................................................... 5

I.4.1 DIAGRAMMES STATIQUES .................................................................................. 5

I.4.2 DIAGRAMMES DYNAMIQUES ........................................................................... 17

Chapitre II : NOTION SUR LA PROGRAMMATION ORIENTEE OBJET ET LA BASE DE DONNEES ......................................................................................................................... 20

II.1 LA PROGRAMMATION ORIENTEE OBJET ............................................................ 20

II.1.1 DEFINITION .......................................................................................................... 20

II.1.2 APPROCHE ORIENTEE OBJET .......................................................................... 20

II.1.3 LANGAGES ORIENTES OBJETS ........................................................................ 22

II.2 LA BASE DE DONNEES ............................................................................................. 23

II.2.1 GENERALITES ...................................................................................................... 23

II.2.2 SYSTEME DE GESTION DE BASES DE DONNEES ........................................ 23

II.2.3 MODELE RELATIONNEL.................................................................................... 26

II.2.4 MODELE OBJET ................................................................................................... 29

Chapitre III : APPROCHE DU SUJET ................................................................................... 31

III.1 .PRESENTATION DU SUJET .................................................................................... 31

III.1.1 PROBLEMATIQUE .............................................................................................. 31

III.1.2 OBJECTIFS DE L’ETUDE ................................................................................... 31

III.1.3 DEROULEMENT DE TRAVAIL ......................................................................... 31

III.2 MODELISATION AVEC UML .................................................................................. 33

III.2.1 INTRODUCTION ................................................................................................. 33

III.2.2 REPRESENTATION DES DIAGRAMMES UML .............................................. 33

Chapitre IV : LOGICIEL « GPAuto 1.0 » .............................................................................. 41

IV.1 CONCEPTION DU LOGICIEL .................................................................................. 41

IV.1.1 LANGAGE DE PROGRAMMATION C++ ......................................................... 41

IV.1.2 COMPILATEUR ................................................................................................... 43

iii

IV.1.3 IMPLEMENTATION DES CLASSES ................................................................. 44

IV.2 PRESENTATION DU LOGICIEL .............................................................................. 47

IV.2.1 INSTALLATION ET LANCEMENT DU LOGICIEL......................................... 47

IV.2.2 INTERFACES GRAPHIQUES ............................................................................. 48

Conclusion ................................................................................................................................ 53

Annexe ........................................................................................................................................ I

Bibliographie ............................................................................................................................ IV

Webograhie ............................................................................................................................... V

iv

LISTE DES TABLEAUX

Tableau I-1 : Différents types de visibilité ............................................................................... 10

Tableau I-2 : Différentes cardinalités et leurs significations .................................................... 12

Tableau II-1 : Exemple de représentation de relation .............................................................. 27

v

LISTE DES FIGURES

Figure I-1 : La vue "4+1"de Kruchten ........................................................................................ 3

Figure I-2 : Exemple de diagramme de cas d'utilisation ............................................................ 7

Figure I-3 : Exemple d'association réflexive et de classe-association ..................................... 13

Figure I-4 : Représentation d'un composant et de ses interfaces requise et offerte ................. 16

Figure III-1 : Déroulement de travail ....................................................................................... 32

Figure III-2 : Diagramme de cas d’utilisation ......................................................................... 33

Figure III-3 : Diagramme de séquence pour « Enregistrer une voiture »................................. 36

Figure III-4 : Diagramme de séquence pour « Enregistrer un chauffeur» ............................... 37

Figure III-5 : Diagramme de séquence pour « Inscrire un client » .......................................... 37

Figure III-6 : Diagramme d’activités ....................................................................................... 38

Figure III-7 : Diagramme de classes ........................................................................................ 40

Figure III-8 : Diagramme d’objets ........................................................................................... 40

Figure IV-1 : Icône de GPAuto 1.0.exe.................................................................................... 48

Figure IV-2 : Interface d’Accueil ............................................................................................. 48

Figure IV-3 : Interface Inscription de chauffeur ...................................................................... 49

Figure IV-4 : Interface Voir la liste .......................................................................................... 50

Figure IV-5 : Interface Recherche ............................................................................................ 51

Figure IV-6 : Interface Planning .............................................................................................. 51

Figure IV-7 : Interface Formulaire de contrat .......................................................................... 52

vi

LISTE DES ABREVIATIONS

BD : Bases de Données

DLL : Dynamic Link Library

IBM : International Business Machines Corporation

ISO :International Standards Organization

OMG : Object Management Groupe

OMT (Object Modeling Technique)

OOD (Object Oriented Design)

OOSE (Object Oriented Software Engineering)

POO :Programmation Orientée Objet

RAM : Random Access Module

SGBD : Système de Gestion de Bases de Données

STL : Standard Template Library

UML : Unified Modeling Language

INTRODUCTION

RinahMahaimalala 1

INTRODUCTION

Depuis l’apparition des premiers ordinateurs à la fin de la Seconde Guerre mondiale

jusqu’ à nos jours, la science du traitement automatique de l’information dite l’informatique

ne cesse de tenir une grande place dans la vie humaine car elle est presque présente dans la

plupart des domaines de la vie professionnelle et privée. D’ailleurs, elle intervient également

dans les sciences appliquées, dans les entreprises, l’enseignement, les banques, les

commerces, etc.

Grace à sa potentialité, l’informatique a tout d’abord une mission de pallier les

insuffisances humaines en matière de calcul numérique. Alors, les ordinateurs sont capables

de manipuler d’importantes masses de données dans un minimum de temps. Mais

l’informatisation de chaque domaine nécessite un bon choix de logiciel qui correspond à son

besoin.

C’est pourquoi, ce présent mémoire intitulé : « Conception et réalisation d’un logiciel

de gestionde parc automobile » a pour but de réaliser un outil de travail informatisé pour

améliorer la méthode de travail et pour satisfaire les clients à leur besoinau sein d’un parc

automobile.

Pour bien atteindre ces objectifs, notre travail se divise en quatre chapitres : dont le

premier va informer à propos de notionsur le langage UML; le second exposera la notion sur

la programmation orientée objet et la base de données ; le troisième abordera l’approche du

sujet et le dernier parlera de logiciel GPAuto 1.0.

NOTION SUR LE LANGAGE UML

RinahMahaimalala 2

Chapitre I : NOTION SUR LE LANGAGE UML (UnifiedModelingLanguage)

I.1 INTRODUCTION

La description de la programmation par objets dépend de la définition des classes avec

leurs liens, des attributs, des méthodes et des interfaces.Pour programmer une application, il

faut d’abord organiser ses idées et définir les étapes de la réalisation. Cette démarche est

appelée modélisation et son produit est un modèle.

Grâce au modèle il est possible de représenter simplement un problème, un concept et le

simuler. La modélisation comporte deux composantes :

• L'analyse portant sur l'étude du problème

• La conception concernant la mise au point d'une solution au problème

L’UML (UnifiedModelingLanguage ou en français langage demodélisation unifié)est

un langage qui sert à formaliser les besoins, c'est-à-dire à les représenter sous une forme

graphique suffisamment simple pour être compréhensible par toutes les personnes impliquées

dans le projet. En plus, il permet de construire plusieurs modèles de système dont certains

montrent le système du point de vue des utilisateurs, d’autres indiquent sa structure interne,

d’autres encore donnent une vision globale ou détaillée. Ces modèles se complètent et

peuvent être assemblés. Ils sont élaborés tout au long du cycle de vie du développement d’un

système c'est-à-dire depuis le recueil des besoins jusqu’à la phase de conception.

I.2 HISTORIQUE

Dans les années 1980, les méthodes utilisées pour organiser la programmation étaient

fondée sur la modélisation séparée des données et des traitements (Merise, Axial,…). Au

début des années 1990, lorsque la programmation par objets prend de l’importance, la

nécessité d’une méthode qui lui soit adaptée devient évidente. Entre 1990-1995, plus de

cinquante méthodes apparaissent (Booch, Classe-Relation, Fusion, OOSE, OMT, OOD, etc.)

mais aucune ne s’est réellement imposée.

En 1994, le premier consensus se fait autour de trois méthodes :

• OMT(Object Modeling Technique) de JamesRumbaugh(General Electric) qui

représente les vues statiques, dynamiques et fonctionnelles d’un système ;

• OOD (Object Oriented Design) de GradyBooch, défini par le Department of

Defense, introduit le concept d’élément d’organisation des modèles : package;


RinahMahaimalala 3

• OOSE (Object Oriented Software Engineering) d’Ivar Jacobson (Ericsson)

quifonde l’analyse sur la description des besoins des utilisateurs.

Entre 1995-1997, l’unification et la normalisation des méthodes ont évolué par étapes.

En 1995, GradyBooch, JamesRumbaughet d’autres se sont mis d’accord pour élaborer une

méthode unifiée nommée UnifiedMethod 0.8 ; en 1996, Ivar Jacobson les a rejoints pour

fonder UML 0.9.Les acteurs les plus importants dans le monde du logiciel s’associent alors à

l’effort (IBM, Rational, Microsoft, Oracle, Unisys, etc.). Cette collaboration a donné

naissanceà l’UML 1.0, un langage de modélisation bien défini, expressif, puissant, et

généralement applicable. UML 1.0 est soumis à l'OMG en janvier 1997. Et en Novembre

1997, UML 1.1 est devenu une norme de l'OMG, ce qui lui a permis de s'imposer en tant que

méthode de développement objet et d’être reconnu et utilisé par de nombreuses entreprises.

I.3 LA VUE "4+1" DE KRUCHTEN

Une architecture décrit les choix stratégiques qui déterminent en grande partie les

qualités du logiciel telles que son adaptabilité, sa performance et sa fiabilité donc elle

constitue un facteur clé du succès du développement. C’est pourquoi, Philippe Kruchten

propose des différentes perspectives indépendantes et complémentaires qui permettent de

définir un modèle d’architecture comme indique la figure ci-après. La représentation des cinq

façons de voir un système (la vue « 4+1 ») qui ont fortement inspiré UML.

Figure I-1 : La vue "4+1"de Kruchten

Les caractéristiques de la vue "4+1":

La vue logique

la vue logique se concentre sur l'abstraction et l'encapsulation, et modélise les

éléments et les mécanismes principaux du système;

Vue logique Vue des composants

Vue des processus

Vue de déploiement

BESOINS DES UTILISATEURS


RinahMahaimalala 4

elle identifie les éléments du domaine, ainsi que leurs relations et interactions. Ces

éléments sont liésau métier de l'entreprise et indispensable à la mission du système.

selon les critères purement logiques, cette vue organise les éléments du domaine en

catégories (repartir les tâches dans les équipes, regrouper ce qui est générique,

isoler ce qui est propre à une version donnée, etc.)

La vue des composants

La vue des composants appelée aussi vue de réalisation montre:

l'allocation des éléments de modélisation dans des modules (fichiers sources,

bibliothèques dynamiques, bases de données, etc.);

les modules qui réalisent les classes de la vue logique;

l'organisation des modules en sous-système, les interfaces des sous-systèmes et

leurs dépendances.

La vue des processus

La vue des processus est très importante dans les environnements multitâches car elle montre:

la décomposition du système en termes de processus;

les interactions entre les processus;

la synchronisation et la communication des activités parallèles.

La vue de déploiement

La vue de déploiement a un rôle considérable dans les environnements distribués parce qu'elle

décrit les ressources matérielles et la répartition du logiciel dans ces ressources portant sur :

la disposition et la nature physique des matériels ainsi que leurs performances;

l'implantation des modules principaux sur les nœuds du réseau;

les exigences en termes de performance comme le temps de réponse, la tolérance

aux fautes et pannes…

La vue des besoins des utilisateurs

La vue des besoins des utilisateurs appelée aussi "vue des cas d'utilisation" mène lesquatre

autres vues de l'architecture. Elle consiste à:

dessiner le plan ou bien l'architecture d'un système informatique et le justifier;

définir les besoins des clients du système et l'architecture du système sur la

réalisation de ces besoins;

conduire à la définition d'un modèle d'architecture pertinent et cohérent à l'aide de

scénarios et de cas d'utilisation;

identifier les interfaces critiques et se concentrer sur les problèmes importants.


RinahMahaimalala 5

I.4 DIAGRAMMES UML

L’utilité des diagrammes UML est variable selon les cas, doncils ne sont pas

nécessairement tous produits à l’occasion d’une modélisation.Les plus utiles pour la maîtrise

d’ouvrage sont les diagrammes d’activités, de cas d’utilisation, de paquetages, de classes,

d’objets, de séquence et d’état- transitions. Les diagrammes de composants, de déploiement et

de collaboration sont surtout importants pour la maîtrise d’œuvre car ils permettent de

formaliser les contraintes de la réalisation et la solution technique.

Les diagrammes UML se repartissent en deux groupes:

Les diagrammes statiques (structures)

Il existe plusieurs types de diagrammes statiques :

Diagramme de cas d’utilisation : structure des fonctions nécessaires aux utilisateurs

du système ;

Diagramme des paquetages: structure du système en catégorie (vue logique) et

sous-système (vue des composants);

Diagramme de classes : un des plus importants en conception Orientée Objet et qui

fournit la modélisation des entités du système ;

Diagramme d'objets : illustre le diagramme de classes en terme d’Objets ;

Diagramme de composants : structure des composants d’exploitation ;

Diagramme de déploiement : structure du réseau informatique en charge du

système, installation des composants d’exploitation.

Les diagrammes dynamiques (comportements)

Ils se présentent sur plusieurs formes :

Diagramme de collaboration : organisation structurelle des objets qui envoient et

reçoivent des messages ;

Diagramme de séquence : ordre des échanges entre les objets du système ;

Diagramme d’états-transitions : cycle de vie commun aux objets d’une classe ;

Diagramme d’activités : règles d’enchainement des activités du système.

I.4.1 DIAGRAMMES STATIQUES

a) Diagramme de cas d’utilisation

L’utilité du diagramme

Le diagramme de cas d’utilisation permet de recueillir, d'analyser et d'organiser les

besoins des utilisateurs et de représenter visuellement une séquence d'actions réalisée par un

système. Il divise aussi les fonctions du système en unités cohérentes: les cas d'utilisation.


RinahMahaimalala 6

Les éléments constitutifs du diagramme

1. L'acteur:qui représente le rôle joué par une entité externe (utilisateur humain ou

non) qui interagit directement avec le système.

Un acteur est qualifié deprincipal pour un cas d'utilisation lorsque ce cas rend service à

cet acteur, et les autres acteurs sont alors dits secondaires. Un acteur principal obtient un

résultat observable du système tandis que l'acteur secondaire est sollicité pour des

informations complémentaires.Graphiquement, l’acteur est représenté par un petit bonhomme

ou un classeur contenant stéréotypé<<acteur>> avec son nom inscrit en dessous pour préciser

son rôle.

2. Le cas d'utilisation:quiest la manière spécifique d'utiliser un système réalise un

service de bout en bout avec un déclenchement, un déroulement et une fin pour l'acteur qui

l'initie.Graphiquement, le cas d’utilisation se représente par une ellipse contenant le nom du

cas (un verbe à l'infinitif) et un stéréotype ajouté optionnellement au-dessus du nom ou bien

un classeur stéréotypé <<use case>> si on veut présenter les attributs et les opérations du cas

d'utilisation.

3. Les relations: Association entre cas d'utilisation et acteurs

Une relation d'association est un chemin de communication entre un acteur et un cas

d'utilisation. Cette relation est représentée par un trait continu.

Si un acteur utilise plusieurs fois un cas d'utilisation, il faut ajouter à l'extrémité du cas

le symbole ″*″qui montre une relation d'association avec multiplicité. Plusieurs valeurs sont

possibles pour la multiplicité: ″n″s'écrit tout simplement″n″;″m″…″n″ signifie entre ″n″ et

″m″, etc. L'existence d'une multiplicité sur une relationn’implique pas nécessairement que les

cas sont utilisés en même temps.

Dépendance entre cas d'utilisation

Trois types de relation standard entre cas d'utilisation sont proposés par UML.

La relation d'inclusion, symbolisée par le stéréotype <<include>> ;un cas

d'utilisation a besoin d'un autre cas pour exécuter sa tâche.Les inclusions permettent aussi de

décomposer un cas compliqué en sous-cas plus simples.

La relation d'extension, symbolisée par le stéréotype <<extend>> ;un cas

d'utilisation augmente ses fonctionnalités à celles d'un autre cas. Une extension est souvent

soumise à une condition représentée sous forme d'une note qui contient une information

textuelle comme un commentaire, un corps de méthode ou une contrainte représentée par un

rectangle dont l'angle supérieur droit est plié.


RinahMahaimalala 7

La relation de généralisation (ou héritage),un cas d'utilisation dérivé est une

spécialisation d'un cas d'utilisation parent. La généralisation se représente par une flèche avec

un trait plein dont la pointe est un triangle fermé désignant le cas le plus généralisé.

Le schéma ci-dessous montre les relations citées auparavant, prenant comme exemplela borne

interactive d'une banque:

FIGURE: Exemple de diagramme de cas d'utilisation

Figure I-2 :Exemple de diagramme de cas d'utilisation

Héritage entre acteur La relation de généralisation est l'unique relation possible entre deux acteurs: un acteur

X est une généralisation d'un acteur Y si X peut être substitué par Y donc tous les cas

d'utilisation accessibles à X le sont aussi à Y mais l'inverse est impossible.

Frontière du système Nom du système

Client

Borne interactive d'une banque

Retirer argent

Vérifier solde

Consulter compte

Consulter sur Internet

<<include>>

<<include>>

<<extend>>

<<include>>

Condition:{si montant>5000Ar} Point d'extension: vérificationSolde

S'authentifier

Effectuer un virement

Point d'extension: vérificationSolde {après avoir

demandé le montant}

Relation d'inclusion

Relation d'extension

Relation de généralisation Note

Association Acteur

Cas d'utilisation


RinahMahaimalala 8

La description textuelle des cas d'utilisation

La description d'un cas d'utilisation se fait par des scénarios qui définissent la suite

logique des interactions lesquelles constituent le cas. Cette descriptionconsiste à définir son

contexte et à détailler la communication entre le cas et l'acteur.

Une description textuelle couramment utilisée se divise en trois parties.

Première partie:elle consiste à identifier le cas. Elle doit contenir: le nom du cas, un

résumé de son objectif, les acteurs impliqués (principaux et secondaires), les dates de création

et de mise à jour de la description courante et le numéro de version.

Deuxième partie:elle comporte la description du fonctionnement du cas sous la forme

d'une séquence de messages échangés entre les acteurs et le système. Elle contient toujours

une séquence normale qui décrit le fonctionnement normal du cas.

A la séquence normale s'ajoutent fréquemment des séquences alternatives (ce sont des

embranchements dans la séquence normale) et des séquences d'exceptions (en cas d'existence

d'erreur).

D'après Bertrand Meyer, on peut structurer les scénarios selon le programme par contrat :

Pré-conditions:conditions qui assurent le déclenchement du cas;

L'enchainement des messages: échanges d'évènements entre l'acteur et le

système;

Post-conditions:conditions qui décrivent l'état du système à l'issus des différents

scénarios.

Troisième partie:c'est une rubrique optionnelle qui renferme généralement les

spécifications non fonctionnelles (comme les spécifications techniques, par exemple l’accès

aux informations sécurisé). Elle contient éventuellement une description des besoins en

termes d'interface graphique.

b) Diagramme de paquetages


Le diagramme de paquetages permet la mise en œuvre de partitionnement des modèles

tout en préservant la cohérence de l'ensemble donc il renferme la base dans la construction

d'architecture du système.


RinahMahaimalala 9


1. Le paquetage:

C’est l'ensemble d'éléments d'organisation de modélisation. Il peut contenir tout

type d'élément de modèle: des classes, des relations, des objets, des diagrammes associés, des

paquetages imbriqués, etc.

Un paquetage se représente comme un dossier avec son nom inscrit dedans. Dans le cas où on

met le contenu du paquetage, son nom doit être placé dans l'onglet.

2. Les dépendances:

Les paquetages peuvent avoir des relations de dépendances UML classiques comme

l'association, l'héritage et des dépendances spéciales de type "package import" (importation de

paquetage) et "package merge"(fusion de paquetages).

Fusion de paquetages (package merge)

Un package merge est une relation entre deux paquetages et indiquant que leurs

contenus sont combinés alors il s'agit alors d'un mécanisme d'extension. Cette relation est

semblable celle relation de la généralisation dans le sens où l'élément source ajoute

conceptuellement les caractéristiques de l'élément du paquetage destination à ses propres

caractéristiques. Elle est représentée par une flèche avec un trait pointillé suivi d'un stéréotype

<<merge>>.

Import de paquetages (package import)

Un package import est une relation entre un paquetage important, un espace de nom et

un paquetage précisant que l'espace de nom qui importe ajoute les noms des membres du

paquetage à son propre espace de nom.Cette relation est représentée par une flèche avec un

trait pointillé accompagné d'un stéréotype <<import>> pour import public et <<access>> pour

import privé.

N.B.: Par défaut, une dépendance entre deux paquetages est comme une relation de type

package import.

c) Diagramme de classes


Le diagramme de classes est le point essentiel de tout développement orienté objet, donc

il doit obligatoirement représenter lors d'une modélisation. Ce diagramme qui montre la

structure interne d'un système permet de fournir une représentation abstraite des objets du

système qui vont interagir ensemblepour réaliser les cas d’utilisation.


RinahMahaimalala 10


1. La classe:c’est le type de donnée abstrait qui précise les attributs et les

fonctions communes à toute une famille d'objets et permettant de créer des objets ayant ces

caractéristiques.

Une classe est un classeur représenté par un rectangle séparé en trois parties:

La première partie: le nom de la classe Le nom de la classe doit évoquer le concept décrit par la classe. Il doit commencer par

une majuscule. On peut y ajouter aussi des informations complémentaires telles que le nom

de l'auteur de la modélisation, la date, etc.

La deuxième partie: les attributs

Les attributsdéfinissent les informations sur l'état de l'objet. Chacune de ces

informations décrit un nom qui doit être unique dans une classe, un type de données et une

visibilité qui peut être initialisée.

La syntaxe de la déclaration d'un attribut se présente comme suit:

VisibiliténomAttribut [multiplicité] : typeAttribut = Initialisation

Visibilitéqui indique l'accessibilité à l'attribut.

Tableau I-1 : Différents types de visibilité

Symbole Rôle Mot clé Description

+ Accès public Public Toutes les autres classes ont accès à l'attribut

# Accès protégé Protected Seules la classe elle-même et ses descendantes ont accès à l'attribut

- Accès privé Private Seule la classe elle-même a accès à l'attribut

Le nom de l'attributquine doit contenir ni espaces, ni de ponctuation, ni accents. A la place

des espaces, il faut utiliser le symbole _ ou mettre la première lettre du mot en majuscule.

Exemple:nom de l'attribut peut s'écrire nom_attribut ou nomAttribut.

La multiplicitéqui indique le nombre de fois où le donné caractérisant l'objet peut exister.

Exemple: une personne possède deux numéros de téléphone, on va écrirenumTelephone [2] au

numTelephone1 et numTelephone2.


RinahMahaimalala 11

Le type de l'attributqui peut être un nom de la classe, un nom d'interface ou un type de

donné prédéfini.

Exemples d'attribut:

� Attribut public nom de type string (chaine de caractère): + nom: string

� Attribut privé age de type int (entier): - age: int

La troisième partie: les méthodes

Les méthodes constituent l'ensemble des actions appelées opérations qui caractérisent

le comportement d'un objet. Une opération doit être unique dans une classe.

La syntaxe d'une méthode s’exprime comme suit:

VisibiliténomFonction (directionParamètrenomParamètre : typeParamètre) : typeRetour

Visibilitéest la même que celle des attributs;

Direction du paramètre peut être indiquée par: in (paramètre d'entrée), out (paramètre de

sortie) ou inout (paramètre d'entrée/sortie).

Exemples de méthode:

� Méthode publique getAge( ) retournant un entier: + getAge( ): int

� Méthode protégée calculerAge( ) prenant comme paramètre dateNaissance de type

Date et ne retourne rien (void): #calculerAge(in dateNaissance: Date): void

Les relations entre classes:

Association:

Une association est un lien qui exprime les connexions structurelles entre les instances

de deux classes (association binaire) ou plus (association n-aire).

Une terminaison d'association ou une propriété peut être paramétrée par :

Le nom de rôle: les extrémités d'association sont appelées rôles. un rôle symbolise

l'association. Une association peut donc avoir autant de nom de rôle que de terminaisons

(deux pour une association binaire et n pour une association n-aire);

Le nom d'association: les associations peuvent être nommées de forme verbale pour

faciliter la compréhension des modèles. On peut préciser le sens de lecture par un petit

triangle dirigé vers la classe désignée;

La multiplicité ou cardinalité: chaque rôle peut porter une multiplicité pour indiquer

le nombre d'objets de la classe (celle qui joue ce rôle) capable de lier à une instance de l'autre

classe par l'association.


RinahMahaimalala 12

Tableau I-2 : Différentes cardinalités et leurs significations

Cardinalité Signification

1 Un et un seul

0…1 Zéro à un

m…n De m à n (entier)

* Plusieurs

0…* De zéro à plusieurs

1…* D'un à plusieurs

On peut mettre aussi les éléments suivants pour bien clarifier l'association entre deux classes.

La contrainte:c’estune relation sur les éléments de modélisations pour définir les

proportions qui doivent être vraies afin d’assurer la validité du modèle. Elleest notée entre

accolade.

Le qualificateur:ilpermet de sélectionner un sous-ensemble d'objet (objet qualifié)

parmi l'ensemble des objets qui participent à une association. Le qualificateur agit toujours

sur une association avec multiplicité du côté cible.

L'objet sélectionné par la valeur du qualificateur est appelé objet cible. Un objet qualifié

et une valeur du qualificateur génèrent un objet cible. En considérant un objet qualifié, chaque

valeur du qualificateur indique un objet cible unique.

L'association réflexive:quis'applique à des objets de même classe et peut

s'exprimer à l'aide de rôles ou d'un syntagme verbal.

La classe d'association:c’est une classe qui réalise la navigation entre les instances

d'autres classes donc elle sert à connecter les classes entre elles.

La classe–association possède des attributs, des méthodes et les caractéristiques des

associations qui relient deux à plusieurs classes. Elle est caractérisée par un trait discontinu

entre la classe et l'association qu'elle représente.


RinahMahaimalala 13

Figure I-3 :Exemple d'association réflexive et de classe-association

Les raisons d'utilisation de classe-association et d'association réflexive sont été mentionnées

sur la figure ci-dessus:

� L'association ″Emploi″ entre une entreprise et une personne a ses propriétés

(exemple: salaire). Ces propriétés n'appartiennent ni à la société qui peut employer plusieurs

personnes, ni aux personnes qui peuvent avoir un ou plusieurs emplois. Il s'agit donc des

propres propriétés de l'association ″Emploi″. Pour les associations ne pouvant pas posséder de

propriété, il faut introduire la classe-association pour modéliser cette situation.

� Une personne n'est pas forcement le cadre d'une telle poste donc on ne peut pas

préciser absolument qu'une personne est le supérieur d'une autre personne. Une association

Supérieure dans le diagramme est alors illogique. Il s'agit donc d'une association réflexive sur

la classe-association Emploi mais non pas sur la classe Personne.

Agrégation

Une agrégation est une associationdissymétrique dans laquelle une des extrémités joue

un rôle prédominant par rapport à l'autre extrémité appelée agrégat, doncelle renforce la

dépendance entre les classes. Elle est symbolisée par une ligne accompagnée d'un losange

vide désignant l'agrégat ( ).

L'utilisation d'une agrégationsur la relation de deux classes exprime que:

− une classe (un élément)fait partie d'une autre classe (l'agrégat),

− une action sur une classe entraine aussi une action à l'autre,

0…2 Entreprise 2…* travaille pour

Nom d'association

0…1 cadre

ouvrier

dirige

1…*

employeur employé Personne

Cardinalité

Nom de rôle

Classe-association

Association réflexive Emploi

+Salaire: float

Sens de lecture du nom d'association


RinahMahaimalala 14

− un changement d'état d'une classe implique un changement d'état d'une autre,

− les objets d'une classe sont subordonnés aux objets d'une autre classe,

− Une instance d'élément agrégé peut exister sans agrégat et vice versa,

− à un même moment, une instance d'élément agrégé peut être liée à plusieurs

instances d'autres classes donc l'élément agrégé peut être partagé,

− la durée de vie de l'agrégat et celle de ses éléments agrégés peuvent être

indépendantes.

Composition La composition est uneagrégation forte (agrégation par valeur) qui lie les cycles de vie

des éléments ou les composants et de l'agrégat. Graphiquement, elle est représentée par une

ligne avec un losange plein du côté de l'agrégat ( ).

Pour la relation de composition:

� La multiplicitédu composite ne doit être supérieure à 1 (1 ou 0…1).

� Les cycles de vie des éléments et de l'agrégat sont dépendants,alorsla destruction de

l'agrégat entraine une destruction de ses composants.

� A un même instant, une instance de composant ne peut être liée qu'à un seul agrégat:

la composition est une agrégation non partagée.

Généralisation et héritage

La généralisation est une relation hiérarchique entre une classe appelée la super-classe

(classe dont on hérite)et une ou plusieurs sous-classes (classes qui héritent) c'est-à-dire elle lie

des classes lorsqu'une classe contient un sous ensemble d'éléments nécessaires à une autre.

Cette relation de généralisationse traduit par le concept d'héritage.

Elle est représentée par une flèche se terminant par un triangle fermé dirigé, la classe

dérivée(enfant) vers une classe de base ou parent ( ).

Les objectifs de l'héritage concernent:

− la classe enfant qui possède automatiquement toutes les caractéristiques de ses

classes parents sauf les caractéristiques privées,

− toutes les associations de la classe de base qui s'appliquent aux classes dérivées,

− un objet d'une classe qui peut être utilisé partout où une instance de sa classe parent

est attendue,

− une classe qui peut avoir une relation avec plusieurs parents, c'est l'héritage multiple.


RinahMahaimalala 15

Dépendance

La dépendance est une relation unidirectionnelle qui indique la dépendance entre des

éléments de modélisation.Elle est souvent utilisée quand une classe exploite une autre comme

argument dans la signature d'une opération donc son utilisation implique la modification de la

source s'il en a à la cible.

Cette dépendance est symbolisée par une flèche en pointillée accompagnée souvent de

stéréotype pour mieux clarifier la dépendance ( ).

d) Diagramme d’objets


Un diagramme d'objets représente des instances de classes et leurs relations pour rendre

plus évident le modèle de classes en montrant un exemple qui explicite le modèle. Pour

préciser certains aspects du système en évidence, des détails imperceptibles et une exception

en modélisant des cas particuliers ou des connaissances généralisables non modélisées dans le

diagramme de classe et pour prendre une image d'un système à un instant donné.

Lareprésentation du diagramme

Un objet est représenté par un rectangle contenant le nom de l'objet souligné précédé de

deux points ":" ou la syntaxe nom_objet:nom_classepourinsister sur le type de l'objet. On

peut mettre aussi le compartiment des attributs avec leurs valeurs affectées.

Les relations du diagramme de classes deviennent des liens. Un lien se représente

comme une relation mais s'il y a un nom, on doit le souligner et on ne met pas la multiplicité.

La relation de généralisation ne possède pas d'instance alors on ne la figure jamais dans le

diagramme d'objets.

e) Diagrammesde composants et de déploiement

Les diagrammes de composants et de déploiement sont les deux derniers types de

diagrammes statiques. Le premier présente le système modélisé sous forme de composants

réutilisables et leurs relations de dépendance. Le second montre les éléments

matériels(Modem, Serveur, Station de travail,…), leurs connexions et la disposition des

exécutables représentée par des composants sur ces éléments matériels.

Le diagramme de composants

Le diagramme de composants décrit l'architecture physique et statique d'une application

en termes de modules comme fichiers sources, DLL (Dynamic Link Library), etc.


RinahMahaimalala 16

Les éléments de base de diagramme de composants sont les suivants:

Le composant:c’est une unité indépendante représentée par un classeur avec deux

rectangles sortant du côté gaucheet qui fournit un service bien précis. Les fonctionnalités

qu'il encapsule doivent être cohérentes entre elles et génériques car il est réutilisable.

Ladépendance entre composants:elleindique qu'un élément de l'implémentation d'un

composant exploite les services offerts par un autre composant.

Lorsqu'un composant utilise une interface d'un autre, on peut représenter ce composant avec

ses interfaces requises (symbolisées par un cercle) et offertes (symbolisées par un demi-

cercle).

Figure I-4 :Représentation d'un composant et de ses interfaces requise et offerte

Le diagramme de déploiement

Le diagramme de déploiement illustre la disposition physique des différents nœuds qui

composent dans le système et décrit la répartition des composants sur ces nœuds. Il est

composé de dispositif physique (les nœuds), d'objets d'implantation associés aux nœuds (les

composants), de connexions et des artefacts.Les caractéristiques des ressources matérielles

physiques et des supports de communication peuvent être précisées par stéréotype.

Nœuds:Ce sont des ressources matérielles (calculateur, imprimante,…) représentées par

un cube comportant un nom et des attributs (capacité de mémoire, vitesse de processeur,….).

Connexions:Onutilise l'association représentée par de simple ligne et la

dépendancereprésentée par de flèche en trait pointillé;

Artefacts:Un artefact est une manière de définir un fichier, un programme, une

bibliothèque ou une base de données construite ou modifiée dans un projet. Il est représenté

par un rectangle contenant le stéréotype <<artifact>> et le nom de l'artefact.Les artefacts

mettent en œuvre des collections de composants qui sont consommées ou créées durant l'une

des étapes du processus de déploiement.

<<Stéréotype>>

Nom du composant


RinahMahaimalala 17

I.4.2 DIAGRAMMES DYNAMIQUES

a) Diagramme de collaboration


Le diagramme de collaboration permet de mettre en évidence les interactions entre

lesdifférents objets du système étudié, ainsi que les messages qu’ils échangent entre eux. En

plus, il assure la validation des associations entre des classes dans le diagramme de classes en

les utilisant comme support de transmission des messages. En général, ce diagramme est

utilisé pour rendre plus clair un cas d'utilisation ou pour présenter une opération.


1. L'objetest symbolisé par un rectangle contenant la syntaxe souligné:

[<nom_du_rôle>] : [<nom_du_type>]. Au moins, l'un des deux noms est spécifié dans le

rectangle mais les deux points ":"sont obligatoires.

2. Le lienest la relation entre deux objets, représenté par une ligne reliant un objet

avec un autre auquel il échange des messages. Les extrémités de cette ligne peuvent

accompagner de multiplicité.

3. Le message:Chaque message est représenté par un numéro de séquence

caractérisant l'ordre du message dans l'opération, le sens du message indiqué par une flèche

partant de l'objet qui envoie le message vers un autre qui le traite et l'expression du message.

b) Diagramme de séquence


Le digramme de séquence permet de visualiser l'aspect temporel des communications

entre objets et de mettre l'accent chronologie des envois de messages. En plus, il peut servir à

illustrer un cas d'utilisation. Contrairement au diagramme de collaboration, il ne décrit ni

contexte ni état des objets mais la représentation se concentre seulement sur l'expression des

interactions.


1. L'acteur

2. L'objet

3. La ligne de vie quise représente par un rectangle, auquel est accrochée une ligne

pointillée, accompagnéede la syntaxe [<nom_du_rôle>] :[<nom_du_type>]

4. Le message quidéfinit une communication particulière entre des lignes de vie.


RinahMahaimalala 18

Les différents types de message :

• Message simple : unmessage dont on ne spécifie aucune caractéristique d'envoi ni

réception particulière.

• Message minuté (timeout) : il bloque l'expéditeur pendant un temps donné (qui

peut être spécifié dans une contrainte), en attendant la prise en compte du message par le

récepteur. L'expéditeur est libéré sila prise en compte n'a pas eu lieu pendant le délai spécifié.

• Message synchrone : il bloque l'expéditeur jusqu'à prise en compte du message par

le destinataire. Le flot decontrôle passe de l'émetteur au récepteur (l'émetteur devient passif et

le récepteur actif) à laprise en compte du message.

• Message asynchrone : iln'interrompt pas l'exécution de l'expéditeur. Le message

envoyé peut être pris encompte par le récepteur à tout moment ou ignoré.

• Message dérobant : il n'interrompt pas l'exécution de l'expéditeur et ne déclenche

une opération chez lerécepteur que s'il s'est préalablement mis en attente de ce message.

c) Diagramme d’états-transitions


Le diagramme d’états-transitions décrit le comportement interne d’un objet à l’aide d’un

automate à états finis, c’est-à-dire une machine dont le comportement des sorties ne dépend

pas seulement de l’état d’entrées mais aussi d’un historique des sollicitations passées.


1. L’état qui estsymbolisé par un rectangle aux bords arrondisreprésente une période

dans la vie d’un objet pendant laquelle ce dernier attend un événement ou accomplit une

activité.Il existe aussi deux états prédéfinis : l’état initial qui est obligatoire et unique ; l’état

final, selon l’événement, il peut être plusieurs.

2. La transition: c’est le passage instantanéd’un état vers un autre. Sa représentation

symbolique est une flèche sur laquelle est annoté l'événement quiconcourt au changement

d'état. Il est possible de conditionner une transition à l’aide de «garde» : il s’agit d’une

expression booléenne qui permet lors de l’occurrence d’un événement d’accepter une

transition ou pas (encadrée par de crochet).

3. L’événement : c’est un stimulus qui peut transporter des informations.


RinahMahaimalala 19

d) Diagramme d'activités


Le diagramme d’activités permetde mettre l’accent sur les traitements. Ilest donc

particulièrement adapté à la modélisation du cheminement de flots de contrôle et de flots de

données du système. Ildécrit ainsi le comportement d’une méthode ou le déroulement d’un

cas d’utilisation.


1. L’activité : représente une exécution d’un mécanisme, un déroulement de manière

séquentielle.

2. La transition :c’est le passage d’une activité vers une autre. Elle est déclenchée

par la fin d’une activité et provoque le début immédiat d’une autre, c'est-à-dire elle est

automatique.

3. Le nœud d’activité :c’est le type d’élément abstrait permettant de représenter les

étapes le long du flot d’une activité. Il existe trois types de nœud d’activité : les nœuds

d’exécutions, les nœuds d’objets et les nœuds de contrôle.

4. Le couloir d’activité :ilpermet d’organiser les nœuds d’activités en opérant le

regroupement. Graphiquement, il est représenté par de ligne continue.

NOTION SUR LA POO ET LA BD

RinahMahaimalala 20

Chapitre II : NOTION SUR LA PROGRAMMATION ORIENTEE OBJET ET LA BASE DE DONNEES

II.1 LA PROGRAMMATION ORIENTEE OBJET

II.1.1 DEFINITION

La programmation orientée objet (POO), ou programmation par objet, est un paradigme

de programmation informatique élaboré par Alan Kay dans les années 1970. Il consiste à

modéliser informatiquement un ensemble d'éléments d'une partie du monde réel en un

ensemble d'entités informatiques appeléesobjets qui possèdent une structure interne et un

comportement. Il s'agit donc de représenter ces objets et leurs relations ; la communication

entre les objets via leurs relations permet de réaliser les fonctionnalités attendues, de résoudre

le ou les problèmes d’un système.

Par analogie avec l’équation de Wirth, on peut dire que la POO suit l’équation :

METHODES+DONNEES=OBJET

II.1.2 APPROCHE ORIENTEE OBJET

L’approche orientée objet considère le logiciel comme une collection d’objets dissociés,

identifiés et possédant des caractéristiques. Une caractéristique est soit attribut : une donnée

caractérisant l’état de l’objet, soit une entité comportementale de l’objet : une fonction. La

fonctionnalité du logiciel émerge alors de l’interaction entre les différents objets qui le

constituent. L’une des particularités de cette approche est qu’elle rapproche les données et

leurs traitements associés au sein d’un objet unique.

Les concepts de base d’approche orientée objet comprennent :

L’objet qui représente une entité du monde réel, ou de monde virtuel dans le

cas d’objets immatériels, et se caractérisent pas une identité, des états significatifs et par un

comportement.

L’identité d’un objet permet de distinguer les objets les uns par rapport aux autres,

indépendamment de son état. On construit généralement cette identité grâce à un

identificateur naturellement du problème.

L’étatcorrespond aux valeurs de tous les attributs caractérisant l’objet. A vrai dire, ces

attributs sont des variables stockant des informations d’état de l’objet.

Lecomportementd’un objet se définit par l’ensemble des opérations qu’il peut

exécuter en réaction aux messages envoyés par les autres objets, tel qu’un message

provoquel’exécution d’une opération d’un objet.


RinahMahaimalala 21

Exemple :On prend un exemple d’une Fenêtre : Identité : Fen1 ; Etat: position, taille,

bordure, titre ;Opérations: restaurer, fermer, agrandir.

Un Objet peut correspondre à :

− un objet concret du monde réel, ayant une réalité physique (une personne, une

voiture, un outil, un système mécanique, . . .)

− un concept abstrait telun compte bancaire, le temps, une vitesse, . . .

− une activité produisant des effets observables (un calcul numérique, un pilote

d’impression, . . .)

La classe :c’est un type abstrait de données caractérisées par des propriétés

communes : attributs et méthodes à tous les objets de même famille et un mécanisme

permettant de créer des objets ayant ces propriétés.

N.B. : Lorsque des objets ont les mêmes attributs et comportements, ils sont regroupés dans

une même classe et les objets appartenant à celle-ci constituent les instances de cette classe.

L’encapsulation :il s’agit de un mécanisme consistant à rassembler les données

et les méthodes au sein d’une structure en masquant les détails d’implémentation d’un objet,

en définissant une interface qui est la vue externe offrant un service accessible aux

utilisateurs.

Les intérêts de l’encapsulation peuvent se résumer comme suit:

• D’une part, elle facilite l’évolution du modèle en stabilisant l’utilisation des

objets, c'est-à-dire on peut modifier les détails internes d’une classe sans modifier son

interface ; la façon de s’en servir ne change pas pour les utilisateurs (modèles, programmes,..)

de la classe ;

• D’autre part, elle permet de garder une cohérence dans la gestion de l'objet,

tout en assurant l'intégrité des données qui ne pourront être accédées qu'à l’aide des méthodes

visibles, c'est-à-dire, elle peut interdire ou restreindre l’accès direct aux attributs des objets.

L’héritage :c’est le mécanisme de constructiond’une classe à partir d’une ou

plusieurs d’autres donc il permet d’assurer une grande variabilité dans la réutilisation des

objets.

Il existe deux techniques liées à l’héritage :

1. Laclasse abstraite qui est une classe ayant des propriétés qui ne permettent pas de

préciser des instances. Cette classe met en commun un certain nombre de propriétés à

des objets ;


RinahMahaimalala 22

2. L’héritage multiple qui permet à une classe d’avoir plusieurs classes dérivées et

d’hériter ainsi de tous les attributs et méthodes de ces ancêtres.

N.B. : -La classe de base(super-classe, classe mère, parente, ancêtre) transmet toutes ses

propriétés transmissibles(protected) aux classes dérivées (sous-classe, classe fille, enfant) ;

- La classe dérivée ne peut pas accéder aux membres privés de la classe de base ; elle

possède ses propres attributs et méthodes, que la classe de base ne connaît pas et en plus, elle

peut redéfinir ou améliorerles méthodes transmises par la classe de base.

Le polymorphisme :ilpermet de définir plusieurs formes pour une méthode

commune à une hiérarchie d’objets donc il représente la faculté d'une opération de s'appliquer

à des objets de classesdifférentes.

N.B. :Le concept de polymorphisme ne doit pas être confondu avec celui d'héritage multiple.

L'héritage multiple permet à un objet d'hériter des membres (champs et méthodes) de

plusieurs objets à la fois, alors que le polymorphisme réside dans la capacité d'un objet à

modifier son comportement propre et celui de ses descendants au cours de l'exécution.

II.1.3 LANGAGES ORIENTES OBJETS

a) Définition

Un langage est orienté objet s’il possède les mécanismes employant le style de

programmation orienté objet, c’est à dire, s’il procure les facilités qui rendent pratique l’usage

de ce style.

b) Historique

Les langages orientés objets sont nés dans les années 60 avec Simula 67, dérivé d’Algol,

conçuen Norvège à Oslo par Dahl et Nygaard. Simula est un langage destiné à faire de la

simulationpar évènements discrets en représentant directement les entités du monde réel

comme le bateau,le guichet de banque, le client,... par une structure informatique munie d’un

état et d’uncomportement.

En 1972, à partir de Sketchpad (système de manipulation d’éléments graphiques) et de

Simula,Alan Kay a inventéSmalltalk dans lequel on trouve la notion d’envoi de messages qui

estle seul mode de communication entre objets. Puis, en 1976, Smalltalk 76 a apporté la

notion de métaclasse. Enfin, au début desannées 80, Smalltalk 80 décline de manière

harmonieuse la notion d’objet, c’est àl’heure actuelle la référence en termes de langages

concevant tout en termes d’objets.

D’ailleurs, des langages objets conçus comme des extensions de Lisp (Flavors), ou

intégrésà Lisp (CLOS) apparaissent aussi. Puis, en 1986-1987, c’est l’apparition de C++, qui


RinahMahaimalala 23

emprunte àSimula et s’impose dans le monde industriel, et le début de la vogue d’addition

d’objets auxlangages traditionnels : Objective-C reprend des idées de Smalltalk, Object Pascal

(d’Apple) etTurbo-Pascal 6 de Borland appelé maintenant Delphi. Des Cobol et Fortran objets

ont euxaussi vu le jour récemment. Le paysage des langages orientés objets est donc

relativementfourni, même si les deux principaux (en nombre d’utilisateurs, et en dynamisme)

restent C++ etSmalltalkappelé maintenant VisualWorks. Enfin,Java est lancé par de Sun en

1995. Il deviendra de langage favori de certains programmeurs professionnels grâce à sa

sécurité plus favorable que celle de C++.

II.2 LA BASE DE DONNEES

II.2.1 GENERALITES

La base de donnéeest apparue en 1964 pour désigner un ensemble, en général

volumineux, d’informations, avec une caractéristique essentielle qu’on souhaite mémoriser de

manière permanente.

Elle permet de mettre des données à la disposition d'utilisateurs pour une consultation,

une saisie ou bien une mise à jour, tout en s'assurant des droits accordés aux utilisateurs. Cela

est d'autant plus utile que les données informatiques sont de plus en plus nombreuses.

Une base de données peut être locale, utilisable sur une machine par un utilisateur, ou

bien répartie, c'est-à-dire que les informations sont stockées sur des machines distantes et

accessibles par réseau. L'avantage majeur de l'utilisation de bases de données est la possibilité

de pouvoir être accédées par plusieurs utilisateurs simultanément.

II.2.2 SYSTEME DE GESTION DE BASES DE DONNEES

a) Généralités

Afin de pouvoir contrôler les données ainsi que les utilisateurs, le besoin d'un système

de gestion s'est vite fait ressentir dans les années 1990. La gestion et l’accès à une base de

données se font grâce à un ensemble de programmes qui constituent le Système de gestion de

bases de données (SGBD).

Le SGBD est un ensemble deslogiciels permettant d’accéder aux données de façon

simple, d’autoriser un accès aux informations à de multiples utilisateurs et de manipuler les

données présentes dans la base de données (insertion, recherche, suppression, mise à jour).

Ce système constitue alors une interface entre les utilisateurs et la mémoire secondaire

qui facilite le travail des utilisateurs en leur donnant l’illusion que sur toute information est

comme ils le souhaitent.


RinahMahaimalala 24

Ce système est composé de trois couches successives :

1. Le système de gestion de fichiers qui gère le stockage physique de l’information. Il

est dépendant du matériel utilisé tel que le type support, le facteur de blocage, etc.

2. Le SGBD interne quis’occupe du placement et de l’assemblage des données, de la

gestion des liens et de la gestion de l’accès rapide ;

3. Le SGBD externe qui porte surla présentation et la manipulation des données aux

concepteurs et aux utilisateurs, de la gestion de langages de requête élaborés et des

outils de présentation comme l’état, les formes, etc.

b) Objectifs et avantages de SGBD

Indépendance physique : le SGBD offre une structure canonique permettant la

représentation des données réelles sans se soucier de l’aspect matériel donc les disques, la

machine, les méthodes d’accès, les modes de placement, les méthodes de tris, le codage des

données ne sont pas apparents.

Indépendance logique : chaque groupe de travail doit pouvoir se concentrer sur ce

qui l’intéresse uniquement, c’est-à-dire qu’il peut arranger les données comme il le souhaite

même si d’autres utilisateurs ont une vue différente. D’ailleurs, l’administrateur doit pouvoir

faire évoluer le système d’information sans remettre en cause la vue de chaque groupe de

travail.

Manipulable par des non-informaticiens :le système doit permettre d’obtenir les

données par des langages non procéduraux. On doit pouvoir décrire ce que l’on souhaite sans

décrire comment l’obtenir.

Accès aux données efficace :le SGBD peut faciliterl’obtention des réponses aux

interrogations en un temps raisonnable. Il doit être optimisé et entre autres, c’est un

mécanisme permettant de minimiser le nombre d’accès disque.

Administration centralisée des données : le SGBD doit offrir aux administrateurs

des donnéesdes outils de vérification de cohérence des données, de restructuration éventuelle

de base, de sauvegarde ou de réplication.

Non redondance des données : le SGBD préserver la duplication d’informations

lors des mises à jours, chaque donnée ne doit se présenter qu’une seule fois dans la base.

Cohérence des données : le SGDB assurer une gestion automatique des contraintes

d’intégrités à chaque insertion, modification ou suppression des données.

Partageabilité des données : le SGBD permet à plusieurs utilisateurs d’accéder

simultanément aux données au même moment tout en conservant l’intégrité de la base, c’est-

à-dire chacun doit avoir l’impression qu’il est le seul à utiliser les données.


RinahMahaimalala 25

Confidentialité des données : les données doivent être protégées des accès non

autorisés. Le SGBD doit exister des mécanismes permettant d’autoriser, contrôler et enlever

des droits d’accès à certaines informations pour n’importe quel usager.

Sécuritédes données :le système qui est aussi être tolérant aux pannes, cas de

coupure de courant pendant l’exécution d’une opération sur la base, est capable de revenir à

un état dans lequel les données sont cohérentes.

c) Différents types de modèle de SGBD

Il existe cinq modèles de SGBD, différenciés selon la représentation des données qu'il

contient :

• Le modèle hiérarchique : les données sont classées hiérarchiquement, selon

une arborescence descendante. Ce modèle utilise des pointeurs entre les

différents enregistrements dont chacun n’a qu’un seul possesseur. Il s'agit du

premier modèle de SGBD.

• Le modèle réseau : comme le modèle hiérarchique, ce modèle utilise des

pointeurs vers des enregistrements. Toutefois la structure n'est plus forcément de

structure arborescente dans le sens descendant.

• Le modèle relationnelSystème de gestion de bases de données

relationnelles(SGBDR) : les données sont enregistrées dans des tableaux à deux

dimensions (leslignes et les colonnes). La manipulation de ces données se fait

selon la théorie mathématique des relations ;

• Le modèle déductif : les données sont représentées sous forme de table, mais

leur manipulation se fait par calcul de prédicats.

• Le modèle objetSystème de gestion de bases de données objet(SGBDO) : les

données sont stockées sous forme d'objets, c'est-à-dire de structures appelées

classes présentant des données membres. Les instances de ces classes constituent

les champs.

A la fin des années 90, les bases relationnelles qui ont constitué les bases de données les

plus répandues car ils ont tenu en effetenviron trois quarts des bases de données. Or, notre

travail se consacre à la manipulation de base de données orientée objet donc il vaut mieux

connaitre les caractéristiques de ces deux bases de données.


RinahMahaimalala 26

II.2.3 MODELE RELATIONNEL

a) Historique

Le modèle relationnel, introduit par E.F. Codd en 1970, repose surla théorie

mathématique des ensembles. Codd propose d’utilisercette théorie universellement connue

pour formaliser une base dedonnées (BD) ainsi que les opérations qui lui sont applicables.

Avec le recul, on s’aperçoit que ces propositions correspondent à une véritablerévolution dans

le domaine des bases de données.

En effet,en 1970, les modèles et systèmes de gestion de BD (SGBD) sont detype

hiérarchique et réseau ; leur utilisation qui requiert la connaissancede techniques

informatiques telles que le chaînage desvariables ou le parcours de graphes, était limitée aux

programmeursspécialisés. Les propositions de Codd se heurtent, dans un premiertemps, au

pragmatisme des informaticiens qui exigent des SGBDperformants. La société IBM queCodd

appartient et l’Universitéde Berkeley relèvent le défi de développer un SGBD conformeaux

concepts relationnels. Vers 1975, les premières présentationsdes prototypes System R (IBM)

et Ingres (Université de Berkeley)sont publiées dans une presse spécialisée.

Dès la fin des années 70,les systèmes relationnels deviennent une réalité industrielle

avecDatabase II d’IBM et Ingres commercialisé par la société RTI. La généralisation des

systèmes relationnels ne deviendra effective que versla fin des années 80 après avoir bénéficié

du succès des générateursd’applications sur micro-ordinateurs utilisant une BD de type

relationnel(Dbase, Foxbase, 4e Dimension).

b) Concepts de base

Une BD relationnelle contient un ensemble de relations. Chaquerelation est constituée

d’un ensemble de n-uplets tel qu’un n-uplet représente un groupe de N valeurs. Plus

formellement,une relation est un sous-ensemble du produit cartésiende plusieurs domaines.

Le domaineest un ensemble de valeurs atomiques caractérisant une entité du monde

réel.Exemples : les entiers, les réels, les chaînes de caractère, etc.

Les attributs sont des colonnes d’une relation et qui servent à la fois à indiquer le

contenu de cette colonne, et à la référencer quand on effectue des opérations. Un

attribut est toujours associé à un domaine et son nom peut apparaître dans plusieurs

schémas de relations.

Les tuples (ou n-uplets) sontdes lignes dans la représentation d’une relation sous

forme de table. En théorie, on connaît les valeurs de tous les attributs des tuples.


RinahMahaimalala 27

Le schéma de relation définit la structure des n-uplets, c’est-à-dire l’ensemble des

noms d’attributs constitutifs de la relation. En général, on omet le nom des

domaines qui leur sont associés.

Tableau II-1 : Exemple de représentation de relation

Prenons un exemple de relation ELEVE:

Les contraintes d’intégrité sont des assertions qui doivent être vérifiées à tout moment par les données contenues dans la base de données.

Il existe quatre types de contrainte d’intégrité :

• La contrainte de domaine liée au domaine de définition d’un attribut ;

• La contrainte de clé qui est une relation possédant une clé primaire (un groupe

d’attribut détermine un tuple d’une manière unique dans la table) ;

• La contrainte d’entité,c’est un attribut d’une clé et qui ne doit pas posséder de

valeurs nulles ou vides ;

• La contrainte de référence, c’est une contrainte exprimée entre deux tables. Tout

tuple d’une relation faisant référence à une autre relation doit se référer à un tuple qui

existe donc il s’agit de vérifier si l’information utilisée dans un tuple pour désigner un

autre tuple est validée, notamment si le tuple désigné existe bien. Et en d’autres

termes, quand on désigne un attribut comme une clé étrangère (toute clé primaire

apparaissant dans une autre table), les seules valeurs que peut prendre cet attribut sont

celles qui sont déjà saisies dans la table de référence.

Le contenu de la base de données peut ainsi être synthétisé par des opérations d'algèbre

relationnelle telles que l'intersection, la jointure et le produit cartésien pour procéder à des

CODE NOM PRENOM DATENAISSANCE CLASSE

102 RAKOTOHASINA Yves 02/05/1998 5èmeA

205 SOLOMANANA Feno 12/10/2000 6èmeC

108 VEROHANTA Njara 06/04/1995 3èmeA

056 RASOANIRINA Lalatiana 11/09/1999 6èmeC

attribut n-uplet schéma de relation


RinahMahaimalala 28

rapprochements entre les enregistrements et créer de nouvelles relations stockées dans la base

de données.

Il existe huit opérateurs d’algèbre relationnelle :

L’union :à partir de deux relations ayant un même schéma,on construit une

troisième relation constituée des tuples à chaque relation.

L’intersection : à partir de deux relations,on obtient une troisième relation dont les

tuples sont constitués à la fois des ceux appartenant àces deux relations.

La différence :opération portant sur deux relations ayant le même schéma et

construisant unetroisième relation dont les tuples sont constitués de ceux ne se

trouvant que dans une seule relation.

Le produit cartésien :à partir de deux relations,on en obtient une troisième qui

contient des tuples qui sont toutes les combinaisons possibles des tuples de la

première avec celles de la seconde.

La projection :opération qui consiste à supprimer des attributs d’une relation et à

éliminer les tuples en double apparaissant dans la nouvelle relation.

La sélection :opération permettant d’obtenir une seconde relation dont les valeurs

des tuples correspondent à des critèresdonnés, à partir d’une relation.

La jointure :opération qui consiste à faire le produit cartésien de deuxrelations, puis

à supprimer les tuples ne satisfaisant pas une condition portant sur un attribut de

lapremière relation et sur un attribut de la seconde.

La division cartésienne :à partir des deux relations, on peut obtenir une troisième

relation où la combinaison de chaque tuple de la seconde relation avec chaque tuple

de la troisième (c'est-à-dire le produit cartésien de la seconde et de la troisième

relation) existe dans la première relation.


RinahMahaimalala 29

II.2.4 MODELE OBJET

a) Historique

Les langages de programmation orientés objet sont apparus dans les années 1960 et sont

devenus populaires dans les années 1980. Les premiers systèmes de gestion de bases de

données (SGBD) objets sont apparus dans les années 1990, en même temps que se sont

répandus les langages de programmation orientés objet.

Les bases de données objet figurentparmi des technologies soutenues et standardisées

par le consortiumOMG (Object Management Group) qui a été fondé en 1989, dans l’intention

de soutenir et uniformiser les nouvelles technologies basées sur les objets. A cette époque là,

les SGBDrelationnelsétaient déjà bien implantés sur le marché et l'arrivée des SGBD à objets

a poussé plusieurs éditeurs de SGBD relationnels à modifier leurs produits en vue de leur

permettre de stocker des objets.

b) Concepts de base

Dans une base de données à objets, les informations sont regroupées sous forme de

collection d'objets: un conteneur logique qui englobe des informations et des traitements

relatifs à une chose du monde réel.Tout objet est défini alors conformément à un type abstrait

qui spécifie la description d’entité constitué de structures de données (attributs) et de

primitives d’accès (méthodes ou opérations).

Les objets persistés sont créés et manipulés par les langages de programmation orientée

objet. Donc ceux qui ont les même attributs et méthodes se regroupent en une classe, et une

classe peut en être dérivée d’une autre, dans ce cas elle hérite les caractéristiques de la classe

source.

c) Persistance et sérialisation

Les objets sont créés lors de l'exécution de programmes écrits en langage de

programmation orienté objet et ils disparaissent au plus tard à la fin de l'exécution du

programme. Les bases de données objet permettent de prolonger la durée de vie des objets au-

delà de la durée de l'exécution du programme. Ce phénomène s’appelle la persistance.

La sérialisation est un mécanisme de persistance qui permet d’enregistrer un graphe

d’objets dans un fichier séquentiel de bits. A la suite de la sérialisation d’un tel graphe, la

même ou une autre application peut recharger en mémoire le graphe précédemment sérialisé.


RinahMahaimalala 30

Les points forts de la sérialisation concernent :

� la simplicité d’emploi du mécanisme ;

� la possibilité de faire circuler des objets entre applications distribuées sans encodage

ni décodage spécifiques à programmer.

Les faiblesses de la sérialisation portent sur :

� L’ensemble d’un graphe d’objets est mémorisé/rechargé en une seule opération alors

que peut-être seulement une partie de ce graphe serait utile pour le traitement en

cours ;

� L’absence totale d’un concept de transaction ne permet pas d’envisager le partage de

données entre plusieurs applications différentes.

APPROCHE DU SUJET

RinahMahaimalala 31

Chapitre III : APPROCHE DU SUJET

III.1 PRESENTATION DU SUJET

III.1.1 PROBLEMATIQUE

La façon de gérer manuellement le parc automobile entraine plusieurs problèmes et

notamment des difficultés de:

� faire la mise à jour des données en cas de modification ou de suppression ;

� exécuter un travail fiable et rapide ;

� gérer efficacement le travail de chaque voiture et ainsi que chaque chauffeur ;

� connaître le plus rapidement possible la voiture et le chauffeur disponible à une

telle mission ;

� localiser une voiture et son conducteur ;

� ne pas assurer la continuité de travail provoquant ainsi une perte pour la société.

III.1.2 OBJECTIFS DE L’ETUDE

Afin d’améliorer les fonctions et le processus de travail au niveau d’un parc automobile,

nous allons concevoir et réaliser un système d’information de gestion des voitures et des

chauffeurs permettant de répondre aux besoins perçus du parc automobile.

Le système à réaliser apportera des remèdes aux problèmes cités précédemment. Par

conséquent, ce système doit posséder certaines caractéristiques comme:

� Manipulable : facile à utiliser pour l’utilisateur;

� Fiable : aptitude à fournir les résultats voulus, c'est-à-dire l’exactitude des

résultats ;

� Rapide : temps d’exécution satisfaisant ;

� Efficace : aptitude à satisfaire les besoins des utilisateurs.

III.1.3 DEROULEMENT DE TRAVAIL

La représentation du déroulement de travail nous permet de connaitre tous les circuits

de tâche par lesquels on doit passer jusqu’ à la validation d’une mission et ainsi que les

acteurs qui interviennent dans les échanges d’informations.

APPROCHE DU SUJET

RinahMahaimalala 32

Figure III-1 : Déroulement de travail

N. B. : Le cadre rouge montre la tâche exécutée par le client et le bleu celle de l’opérateur de

saisie.

Enregistrer chauffeur

Enregistrer voiture

Faire une réservation : − Donner la date de mission ; − Donner le nombre de place de voiture voulue

Traiter une commande : − Exécuter la recherche de voiture et de

chauffeur disponible ; − Voir le calendrier de travail de chaque

voiture et de chauffeur obtenus sur la recherche ;

− Choisir la voiture convenable au besoin et le conducteur.

Valider une mission : − Enregistrer les informations sur la voiture et

le conducteur choisi, la date de mission, le lieu de destination et le renseignement du client;

− Remplir le fiche de contrat ; − Imprimer le fiche.

Signer le contrat

Inscrire le client

APPROCHE DU SUJET

RinahMahaimalala 33

III.2 MODELISATION AVEC UML

III.2.1 INTRODUCTION

L’UML qui est un langage de modélisation au sens de la théorie des langages contient

les éléments constitutifs de tout langage : des concepts, une syntaxe et une sémantique. De

plus, il propose aussi une notation qui permet de représenter graphiquement les éléments de

modélisation.C’est pourquoi qu’on va utiliser ce langage UML pour représenter les modèles

de notre système, mais on précise qu’il ne définit pas le processus d’élaboration de ces

modèles en question. A vrai dire, un modèle est une simplification de la réalité qui permet de

mieux comprendre le système qu’on va développer en réduisant la complexité de ce système.

Pour mieux comprendre, décrire nos besoins, résoudre la problématique de

développement et établir l’architecture de notre logiciel, nous allons réaliser le diagramme de

cas d’utilisation, le diagramme de séquence, le diagramme d’activité, le diagramme de classes

et le diagramme d’objets de notre système.

III.2.2 REPRESENTATION DES DIAGRAMMES UML

a) Diagramme de cas d’utilisation

Figure III-2 :Diagramme de cas d’utilisation

Responsable

Gestion d’un parc automobile

Enregistrer une voiture

Enregistrer un chauffeur

Traiter une réservation

Enregistrer une mission

Inscrire un client

APPROCHE DU SUJET

RinahMahaimalala 34

Description textuelle :

� Cas d’utilisation : Enregistrer une voiture

Acteur :responsable

Description :

1er. Cas Inscription d’une nouvelle voiture :

Les informationsà savoir concernant les voitures portent sur: la marque, le numéro

d’immatriculation, le nombre de place, la couleur,…dans l’ordre de leur arrivée au parc. Les

renseignementssur chaque voiture nous permettent de savoir si elle est disponible ou non.

Dans le cas où une voiture ne serait pas renseignée dans le système, on l’y ajoute

également.

2e. Cas Modification de renseignement d’une voiture:

Parfois l’utilisateur veut faire une modification en cas d’erreur pendant la saisie ou en

cas de changement sur l’information d’une voiture.

3e. Cas Annulation d’une voiture au parc :

Parfois une voiture n’est plus considérée comme faisant partie du parc si elle est vendue

ou périmée.

� Cas d’utilisation : Enregistrer un chauffeur

Acteur :responsable

Description :

1er. Cas Inscription d’un chauffeur :

On saisit l’état civil du chauffeur et les renseignements sur chaque chauffeur nous

permettent de connaitre s’il est disponible ou non à conduire une voiture.

2e. Cas Modification de renseignement d’un chauffeur:

Parfois l’utilisateur veut faire une modification en cas d’erreur pendant la saisie ou de

changement sur l’information concernant un chauffeur.

3e. Cas Supprimer un chauffeur :

Si le chauffeur est licencié ou démissionné, son existence est déclarée nulle dans le

système.

APPROCHE DU SUJET

RinahMahaimalala 35

� Cas d’utilisation : Inscrire un client

Acteur :responsable

Description :

1er. Cas Inscription d’un client :

On saisit l’état civil du client comme le nom, le prénom, le numéro de téléphone, le nom

de la société s’il s’agit d’une société,… Ces informations nous aident à connaitre les

renseignementssur client, en cas de besoin.

2e. Cas Modification de renseignement d’un client:

Parfois l’utilisateur veut faire une modification en cas d’erreur pendant la saisie ou de

changement sur l’information d’un client.

3e. Cas Supprimer un client:

Si le client est exclu de la société, son existence est déclarée nulle dans le système.

� Cas d’utilisation :Traiter uneréservation

Acteur : opérateur de saisie

Description :

On saisit d’abord la date de mission pour prospecterla voiture et le conducteur

disponibles à cette date ainsi que l’état civil du client. Ensuite, si le résultat de recherche est

supérieur un, on choisit la voiture convenable au besoin du client.

Cas d’utilisation :Enregistrer une mission

Acteur : opérateur de saisie

Description :

1er. Cas Enregistrer une mission:

On enregistre tous les renseignementsconcernant le client, le chauffeur et la voiture

disponibles, la date de l’utilisation de voiture et le lieu de destination. Puis, on remplit la fiche

de contrat contenant les informations détaillée sur la mission.

2e. Cas Annuler une commande:

Si le client annule sa réservation.

APPROCHE DU SUJET

RinahMahaimalala 36

b) Diagramme de séquence pour le cas d’utilisation

� Diagramme de séquence pour « Enregistrer une voiture »

1. Diagramme de séquence pour le cas d’utilisation « Enregistrer une voiture »

Figure III-3 :Diagramme de séquence pour « Enregistrer une voiture »

APPROCHE DU SUJET

RinahMahaimalala 37

� Diagramme de séquence pour « Enregistrer un chauffeur »

Figure III-4 :Diagramme de séquence pour « Enregistrer un chauffeur»

� Diagramme de séquence pour le cas d’utilisation « Inscrire un client »

Figure III-5 :Diagramme de séquence pour « Inscrire un client »

APPROCHE DU SUJET

RinahMahaimalala 38

c) Diagramme d’activité pour tout traitement d’une réservation et

enregistrement d’une mission

Responsable

Voiture/Chauffeur existe ? Non Oui

Le logiciel de gestion d’un parc automobile

: Début d’activité ; : Nœud de décision ; : Fin d’activité

Figure III-6 :Diagramme d’activités

Fournir la liste des voitures et des chauffeurs disponible

avec leurs informations

Saisir la date de départ et la date d’arrivée

Choisir la voiture et le chauffeur

Fournir le calendrier des missions

Inscrire le client Enregistrer le client

Traiter le contrat Enregistrer le contrat

APPROCHE DU SUJET

RinahMahaimalala 39

Explication :

Pour traiter une commande, il faut suivre les étapes suivantes :

Etape 1. Le responsable saisit d’abord la date de départ et la date d’arrivée de voiture et

le conducteur à rechercher dans le système. Ensuite, le logiciel de gestion d’un parc

automobile lui donne la liste des voitureset de chauffeurs disponiblesavec leurs

informations correspondantes.

Etape 2. Si la voiture et le conducteur existent, le responsable les choisit en respectant le

besoin du client et la cohérence de travail de chaque voiture et chaque chauffeur.

Etape 3. Le responsable saisit tous les renseignements concernant le client (nom,

prénom, adresse, numéro téléphone,…). Après, le logiciel de gestion les enregistre.

Etape 4. Le responsablesaisit tous les renseignementssur la mission et le logiciel de

gestion les enregistre. Ensuite, ilremplit le contrat qui est préétabli dans le système

etqui va être enregistré par le logiciel.

d) Diagramme de classes

L’étude de gestion d’un parc automobile consiste à simplifier le système de réservation de

véhicule et à harmoniser le travail en respectant les conditions suivantes.

1. L’agence propose des différentes voitures et des chauffeurs avec leurs informations.

2. Une voiture possède un conducteur.

3. Un chauffeur peut conduire n’importe quelle voiture.

4. Un client peut réserver un ou plusieurs voitures en même temps.

5. Une réservation est effectuée uniquement par un seul client.

6. Une réservation peut être annulée ou confirmée.

7. Une voiture et son conducteur ont une destination bien définie à la sortie du parc.

8. Une voiture et le chauffeur ont une date de départ et une date d’arrivée.

APPROCHE DU SUJET

RinahMahaimalala 40

Figure III-7 :Diagramme de classes

N.B. : Les détails de chaque classe se trouvent dans l’annexe N°1.

e) Diagramme d’objets

Le diagramme d’objets illustre le modèle de classes donc on va prendre un exemple qui

montre les instances de classes et leurs relations.

Le diagramme de classes qu’on vient de représenter montre qu’un client peut réserver

plusieurs missions et qu’un seul chauffeur et une voiture participent à une mission. Le

diagramme d’objets modélise lui un client CL1 qui passe une commande de deux missions

M1 et M2.

Figure III-8 :Diagramme d’objets

Voiture Chauffeur

* 1

Client

1

1

1

1

Mission

CL1 : Client M1 : Mission M2 : Mission

C1 : Chauffeur V1 : Voiture C2 : Chauffeur V2 : Voiture

LOGICIEL « GPAuto 1.0 »

RinahMahaimalala 41

Chapitre IV : LOGICIEL « GPAuto 1.0 »

IV.1 CONCEPTION DU LOGICIEL

IV.1.1 LANGAGE DE PROGRAMMATION C++

a) Présentation du langage C++

Le C++ est un langage de programmation qui permet la programmation sous de

multiples paradigmes parmi lesquels la programmation procédurale, la programmation

orientée objet ainsi que la programmation générique.En somme, le C++ est un langage

populaire avec un large spectre d’applications grâce à une très grande quantité de

bibliothèques et ressources disponibles. Et en plus, Il est un langage libre, c'est-à-dire non

propriétaire donc n’importe qui peut l’utiliser sans autorisation ni obligation de taxe pour

avoir le droit d’utilisation.

Au début des années 1980, le langage C++ a été initialement développé comme

extension du langage C par Bjarne Stroustrup au sein de Bell Labs. Cette extension du C est

devenue progressivement un langage à part entière, réellement différent du langage C. En

1998, le langage C++ a été finalement adopté et normalisé par l’ISO et actuellement, il

devient l’un des langages de programmation les plus utilisés.

Le but de standardisation consiste dans la portabilité d’un programme, moyennant la

recompilation de son code source. En effet, le C++ est conçu pour être compilé en un

exécutable spécifique à une plateforme donnée.

L’avantage du langage C++ sur la puissance, sa fonctionnalité, sa portabilité et sa

sûreté, il est choisi pour notre projet.

b) Bibliothèque standard utilisée

Le C++ possède une bibliothèque standard qui est une bibliothèque de classes et de

fonctions standardisées. Elle résulte de l’évolution de plusieurs bibliothèques, parfois

développées indépendamment par plusieurs fournisseurs d’environnements C++, et qui ont

été fusionnées et normalisées afin de garantir la portabilité des programmes qui les utilisent.

Une des principales composantes de cette bibliothèque est le STL (Standard Template

Library).

Le STL utilise fortement les templates C++ et le concept de généricité. Il représente

ainsi de nombreux modèles de classes et de fonctions génériques parmi lesquelles les

conteneurs et les algorithmes les plus courants. Une particularité importante résident dans son


RinahMahaimalala 42

approche orientée itérateurs. L’utilisation du STL permet d’augmenter de manière

significative sa productivité en C++ en écrivant du code fiable, performant et portable.

c) Trois composants du STL

1. Les conteneurs :ce sontdes objets qui permettent de stockerd’autres objets donc ils

représententune collection d’éléments.Ils sont inscritsdans des classes génériques

représentant les structures de données logiques les plus couramment utilisées comme

les listes, les tableaux, les ensembles, etc. Ces classes sont dotées de méthodes

permettant de créer, de copier, de détruire ces conteneurs, d’y insérer, de rechercher ou

de supprimer des éléments.Pour la gestion de la mémoire, l’allocation et la libération

de la mémoire, est contrôlée directement par les conteneurs, ce qui facilite leur

utilisation.

Il existe différentes sortes de containeurs disponibles :

• Vector : conteneur reprenant la notion de tableau qui autorise les accès directs

sur ses éléments. Les opérations de mise à jour comme l’insertion et la

suppression sont réalisées en un temps constant à la fin du conteneur et en

temps linéaire (dépendant du nombre d’éléments) aux autres endroits.

• List : conteneur correspond au concept de liste doublement chainée, ce qui

signifie qu’on y disposera d’un itérateur bidirectionnel permettant de parcourir

la liste à l’endroit ou à l’envers. Les opérations de mise à jour sont effectuées

en un temps constant à n’importe quel endroit du conteneur.

• Deque : conteneur offrant des fonctionnalités assez voisines de celles du

vector, effectuant de plus les opérations de mise à jour en début de conteneur

en un temps constant.

• Set : conteneur implantant les ensembles et dans lequel les éléments ne

peuvent être présents au plus qu’en un seul exemplaire.

• Multiset :conteneur implantant les ensembles et où les éléments peuvent être

présents en plusieurs exemplaires.

• Map : conteneur formant des ensembles et où un type de données appelé clé

est associé aux éléments à stocker. On ne peut associer qu’une seule valeur à

une clé unique. On appelle aussi ce type de conteneur tableau associatif ;

• Multimap : conteneur similaire au map supportant l’association de plusieurs

valeurs à une clé unique.


RinahMahaimalala 43

• Stack : conteneur destiné à la gestion de piles de type LIFO (Last In, First

Out), c'est-à-dire, dernier entré et premier sorti. Dans le Stack, on ne peut

qu’introduire (push) des informations qu’on empile les unes sur les autres et

qu’on recueille, à raison d’une seule à la fois, en extrayant la dernière

introduite.

• Queue : conteneur destiné à la gestion de files de type FIFO (First In, First

Out), premier entré et premier sorti. On y place des informations qu’on

introduit en fin et qu’on recueille en tête, dans l’ordre inverse de leur

introduction.

Parmi ces différentes sortes de conteneur, pour notre projet, nouspréférons utiliser le

vectorpour stocker les données parce qu’il a la même sémantique que le tableau donc il

permet un accès rapide à tous ses éléments.

2. Les itérateurs :il s’agitd’une généralisation des pointeurs qui permettent d’accéder aux

éléments et de spécifier une position à l’intérieur d’un conteneur. Ils peuvent être

incrémentés ou déréférencés selon la manière des pointeurs utilisés avec l’opérateur de

déférencement symbolisé par ‘* ’.A vrai dire, ils assurent le lien entre les conteneurs et

les algorithmes.

3. L’algorithme :il forme un ensemble de fonctionspour parcourir les éléments du

conteneur lors d’une recherche, une copie, une suppression, un triage,…

IV.1.2 COMPILATEUR

Un compilateurest unprogramme informatique qui traduit un langage appelé le langage

source en un autre: le langage cible, généralement dans le but de créer un exécutable. Alors, il

sert le plus souvent à traduire un code source écrit dans un langage de programmation en un

autre langage.

A noter que C++ ne suffit pas pour développer mais il nécessite le compilateur comme

pour notre projet, on utilise le compilateur wxDev-C++ qui est un environnement de

développement intégré (IDE) basé sur le populaire Dev-C++ de nombreuses nouvelles

fonctionnalités n’étaient pas disponible dans ce dernier.Et en plus, wxDev-C++ est un logiciel

libre et téléchargeable gratuitement.

Précisons qu’un logiciel est dit libre s’il confère à son utilisateur d’abordla liberté

d'exécuter le programme, pour tous les usages,ensuite la liberté d'étudier le fonctionnement du

programme et de l'adapter à ses besoins,puis la liberté de redistribuer des copies du

programme (ce qui implique la possibilité aussi bien de donner que de vendre des copies) et


RinahMahaimalala 44

enfin la liberté d'améliorer le programme et de distribuer ces améliorations au public, pour en

faire profiter toute la communauté.

IV.1.3 IMPLEMENTATION DES CLASSES

Les fichiers sources sont en général découpés en deux catégories : les fichiers en-tête

(.h) qui contiennent les déclarations des fonctions, des structures et les fichiers

d’implémentation (.cpp) qui renferment la définition des fonctions, la déclaration des

variables globales.

a) Classe Fstream

La classe Fstreamappartient à la bibliothèque standard de C++ qui dérive de classe

‘iostream’. Elle est spécialisée sur l’écriture et la lecture d’un fichier sur le disque dur d’une

machine.

Cette classe est composée des fonctions suivantes :

� Open()qui assure l’ouverture d’un fichier ;

� Read () et Write() qui sont utilisées respectivement pour la lecture et l’écriture ;

� Close ()qui assure la fermeture et la sécurité des données ;

� Seekg() et Seekp()qui sont des fonctions que l’onpeut utiliser pour positionner les

pointeurs d’écriture et de lecture ;

� Is_Open()quiteste si on a réussi à ouvrir ou non le fichier.

Les paramètres d’utilisation de cette classe sont :in pour la lecture, outpour l’écriture et

binary pour spécifier que les données sont stockées en tant que données binaires.

b) Classe FCString (Fixed Capacity String)

Au moment où on veut stocker de donnée, il faut définir leur taille et qui ne change

plus. Par contre, dans la classe string de C++, la taille des objets augmente au fur et à mesure

que la chaine de caractère s’allonge.

Le principe de fonctionnement de l’instance de FCString consititueà remplirl’espace

vide avec le caractère espace ‘ ‘ et couper la chaine qui dépasse la capacité.

Voici le header de FCString :

#include<string>

class FCString

{

public:


RinahMahaimalala 45

FCString(int capac);

~FCString(void);

private:

int capacity;

int length;

char* pdata;

public:

void SetCapacity(int xcapac);

int GetCapacity(void);

int GetLength(void);

FCString&operator=(const std::string& s);

FCString&operator+=(constchar* s);

FCString&operator+=(const std::string& s);

char&operator[](unsignedint i);

std::string ToString(void);

void SetText(const std::string& s);

void Clear(void);

char* Data(void);

static int Len(constchar*s);

};

c) Classe File

La classe File assure la création d’une table, la création d’un nouveau champ et le stockage des données dans notre projet. Voici le code header de cette classe :

#include<fstream>

#include"FCString.h"

using namespace std;

#define ENREGMAX 2000

classFile{

private:


RinahMahaimalala 46

boolrecdata;

size_tsizerec;

size_tsizerow[999];

unsigned int type[999];

voidCalcSize();

voidCalcSizeRow(unsigned int ii);

unsigned intnbchamp,nbpage,nblastrec,numpage,nbrec;

stringdirectory,name,pathmtb,pathfdb,path,filename;

boolisopen;

boolIs_Full(void);

public:

File(void);//constructeur

~File(void);//destructeur

voidOpen(stringxpath);//ouvrir une table

voidAddNewChamp(stringxnamechamp,unsignedintxtype);//ajouter un nouveau champ

void Close(void);//fermer une table

voidCreateTableWith(string xnewname,stringxnewpath,stringxnamecopytable,stringxcopypath);//creer une table de meme metadata sans de meme different

voidCreateNewTable(stringxpath);

boolAddDataI(unsigned intnrow, intidata);// data type int

boolAddData(unsigned intnrow, string sdata);//data type string

boolValidData();//accepte l'enregistrement

voidReinit();//reinitialisation

intGetDataI(unsigned int nrec=1, unsigned intnrow=1);

stringGetDataS(unsigned int nrec=1, unsigned intnrow=1);

stringGetData(unsigned intnrec=1,unsigned intnrow=1);

string GetNameTable();//nom de la table

stringGetNameChamp(unsigned int i=1);//nom du champ

boolIs_open(void);};


RinahMahaimalala 47

d) Classe Connector

Pendant l’utilisation d’un logiciel, les données stockées dans le disque dur sont envoyés

automatiquement dans la mémoire vive, c'est-à-dire, le disque dur est l'organe de l'ordinateur

servant à conserver nos données de manière permanente, contrairement à la mémoire vive, qui

s'efface à chaque fois qu’on ferme notre logiciel. Pour faciliter ce phénomène,

nousélaboronsla classe Connector qui garantit le transfert de donnée entre le disque dur et le

RAM(Random Access Module).

Voici le fichier en tête :

#pragma once

#include"File.h"

#include<string.h>

#include"ClassV.h"

using namespace std;

classConnector{

stringpathv;

int rec;

public:

Connector();

~Connector();

ClassVConnect();//remplir le conteneur

voidReinit();//réinitialisation

voidDisConnect(ClassV, int i);//remplir le table

int GetRec();// nombre de champ

};

IV.2 PRESENTATION DU LOGICIEL

GPAuto (Gestion de Parc Automobile) est un logiciel conçu pour assurer de façon

concrète et précise en temps réel l’ensemble des tâches de gestion, de réservation et de suivi

des véhicules par le ou les responsables de cette activité.

IV.2.1 INSTALLATIONET LANCEMENT DU LOGICIEL

1. Cliquer deux fois sur GPAuto 1.0.exe;

2. Choisir la langue ;

3. Choisir le bouton sur l’accord de licence ;


RinahMahaimalala 48

4. Saisir le mot de passe ;

5. Choisir le répertoire où l’application va être installée et cliquer sur suivant pour

poursuivre l’installation ;

6. La fenêtre suivant demande si onveut réaliser la sauvegarde des fichiers remplacés

lors de l’installation. Passer à l’écran suivant ;

7. Le résumé d’installation récapitule les paramètres choisis. Appuyer sur suivant,

l’installation est terminée.

Pour lancer le logiciel, il suffit de cliquer deux fois sur l’icône GPAuto 1.0.exe.

Figure IV-1 : Icône de GPAuto 1.0.exe

IV.2.2 INTERFACES GRAPHIQUES

a) Interface d’accueil

Figure IV-2 :Interface d’Accueil


RinahMahaimalala 49

La fenêtre principale renferme le menu principal qui montre toutes les opérations

possibles pour: Voiture, Chauffeur, Client, Mission et Aide. Chacundes quatre premiers

menus possèdent des sous menus : Inscription, Voir la liste et Recherche sauf le menu

Aidequi contient tout simplement Rubriques d’aide et A propos de GPAuto. Le menu

Mission a deux supplémentaires sous menus tels que : Planning et Formulaire de contrat.

b) Sous menus : Inscription, Voir la liste et Recherche

Pour la représentation de l’interface de ces trois sous menus, on va prendre le cas du menu

Chauffeur.

� Inscription :

Figure IV-3 :Interface Inscription de chauffeur

Le bouton Valider : pour enregistrer le renseignement du chauffeur. Après avoir

cliqué à ce bouton, on peut enregistrer aussi la photo du chauffeur.

Le bouton Nouveau : pour inscrire un autre chauffeur ;

Le bouton Quitter : pour fermer l’interface.


RinahMahaimalala 50

N.B. : l’utilisateur ne doit plus changer le code car il est déjà automatique et le nom de photo

du chauffeur doit être identique au code pour faciliter la recherche.

� Voir la liste :

Figure IV-4 :Interface Voir la liste

On trouve sur cette interfacedes informationsconcernant le chauffeur qu’on a enregistré

sur l’interface précédente. En cliquant sur la ligne de tableau, on a tous les renseignementssur

le chauffeur sélectionné en haut du tableau (sur Description) et ainsi sa photo sur la partie

droite.

Concernant les trois boutons :

Modifier : pour changerl’information du chauffeur ;

Supprimer : pour supprimer de chauffeur dans la liste ;

Quitter : pour fermer l’interface.


RinahMahaimalala 51

� Recherche :

Figure IV-5 :Interface Recherche

Sur cette interface, on peut faire une recherche. Tout d’abord, parmi les trois

critères,ondoit choisirceluiavec lequel on veut faire l’opération en sélectionnant le bouton.

Puis, on doit saisir sur la zone de saisie le mot qu’on veut chercher. Ensuite, on clique sur le

bouton Rechercher.Enfin, le résultat avec l’information surle chauffeur s’affiche dans la

partie droite de l’interface, si le critère existe. Sinon, il y a une boite de message qui

apparait,informe qu’il n’existe pas.

c) Sous menus : Planning et Formulaire de contrat

� Planning :

Figure IV-6 :Interface Planning


RinahMahaimalala 52

Sur la zone Recherche :

� On peut faire la recherche de voiture et de chauffeur disponible en complétant la date

de départ et d’arrivée et en cliquant sur le bouton Rechercher, le résultat s’affiche sur

la zoneRésultats de Recherche s’il en a ; sinon une boite de message apparait pour

informer que tout est occupé.

� Le bouton Annuler pour arrêter la recherche.

Sur la zone Description, on peut trouver l’information de chaque voiture et chauffeur en

cliquant sur la ligne de liste qu’on veut voir.

Sur la zone Liste Chauffeur et Voiture :

� On peut voir la date de mission de chaque voiture et chaque chauffeur durant trois

mois successifs et le délai de la mission est coloré s’il en a.

� On clique sur le bouton Précédentquand on veut connaitre la mission au mois

précédent et Suivantpour le mois suivant.

� Formulaire de contrat :

Sur ce menu, l’utilisateur peut remplir le formulaire de contrat préétabli ou de même créer un

nouveau et l’imprimer.

Figure IV-7 : Interface Formulaire de contrat

CONCLUSION

RinahMahaimalala 53

CONCLUSION

Le recours à l’informatisation des gestions des activités deviennent actuellement

incontournable en cette ère où la concurrence bat son plein. Or, ce nouveau procédé requiert

des outils efficients entre autres un logiciel adéquat.

Ainsi, notre étude sur la conception d’un logiciel pour un parc automobile est basée sur

le stockage des données et de les manipuler à tout moment. L’utilisation de cet outil tient une

grande place à la gestion rationnelle de production dans le parc car il permet d’assurer la

concrétisation et précision des tâches de gestion, de réservation et de suivi.

Dans cet ouvrage, nous avons pu connaitre la modélisation UML, les différentes

méthodes pour élaborer le système de gestion et la relation entre objet.

Notre étude s’achève sur la réalisation de base de la gestion, mais ce projet pourrait

éventuellement s’améliorer selon l’évolution de la technologie informatique. Certes, notre

terrain d’investigation concerne le parc automobile, en revanche, l’application de ce logiciel

peut s’étendre dans de multiples domaines avec de simples paradigmes de données à traiter.

ANNEXE

RinahMahaimalala I

ANNEXE

ANNEXE 1: Représentation des attributs et des opérations de classe

Classe Attributs Opérations

Voiture -modele: string -marque: string -num_Immatriculation: string -nb_Place : int -couleur : string -type_Carburant: string -code_Voiture: string

+Set Modele() ; +Set Marque() ; +Set Num_Immatriculation() ; +Set Nb_Place() ; +SetCouleur (); +Set Type_Carburant() ; +Set Categorie() ; +Get Modele() ; +GetMarque() ; +GetNum_Immatriculation() ; +Get Nb_Place() ; +GetCouleur (); +Get Type_Carburant() ; +GetCode_Voiture() ;

Chauffeur -nom : string -prenom : string -date_Naissance -lieu_Naissance: string -num_Cin : string -adresse: string -num_Persmis_Conduire : int -num_Tel : string -code_Chauffeur: string

+SetNom() ; +SetPrenom() ; +SetDate_Naissance() ; +SetLieu_Naissance() ; +SetNum_Cin() ; +SetAdresse() ; +SetNum_Permis_Conduire() ; +SetNum_Tel() ; +GetNom() ; +GetPrenom() ; +GetDate_Naissance() ; +GetLieu_Naissance() ; +GetNum_Cin() ; +GetAdresse() ; +GetNum_Persmis_Conduire() ; +GetNum_Tel() ; +GetCode_Chauffeur() ;

Client -nom : string -prenom : string -date_Naissance -lieu_Naissance: string -num_Cin :string -adresse: string -num_Tel :string -email : string -nom_Societe : string -adresse_Societe : string -code_Client: string

+SetNom() ; +SetPrenom() ; +SetDate_Naissance() ; +SetLieu_Naissance() ; +SetNum_Cin() ; +SetAdresse() ; +SetNum_Tel() ; +SetEmail() ; +GetNom() ; +GetPrenom() ; +GetDate_Naissance() ;

ANNEXE

RinahMahaimalala II

+GetLieu_Naissance() ; +GetNum_Cin() ; +GetAdresse() ; +GetNum_Tel() ; +GetNum_Fax() ; +GetEmail() ;

Mission -jour_depart : int -mois_depart : int -annee_depart : int -jour_arrivee : int -mois_arrivee: int -annee_arrivee : int -delais : int -date_depart : string -date_arrivee : string -destination: string -ville: string -province: string -carte_carburant: string

+SetJourDep(); + SetMoisDep(); + SetAnneeDep(); +SetDatDep(); +SetJourArr(); +SetMoisArr(); + SetAnneeArr(); +SetDatArr(); +SetDelai(); +SetDest(); +SetVil(); +SetProv(); +SetCartCarb(); +GetJourDep (); +GetMoisDep (); +GetAnneeDep (); +GetJourArr (); +GetMoisArr (); +GetAnneeArr (); +GetDelai(); +GetDest(); +GetVil(); +GetProv(); +GetCartCarb();

ANNEXE

RinahMahaimalala III

ANNEXE 2 : Exemple de formulaire de contrat

CONTRAT DE LOCATION DE VOITURE

Le présent contrat a pour objet la location d’une voiture avec chauffeur entre M/Mme/Société……………………ayant son siège social……………………………………Tel :……………d’un part et M/Mme/Société……………………….ayant son siège social………………………………….Titulaire de la carte d’identité n°………………Tel :……………..d’autre part.

Le véhicule loué porte la modèle ………………, la marque ………………et le n° d’immatriculation……….et de …………places. Il est conclu pour une durée de ……… dont la date de départ aura lieu le………………..et ……………………..la date d’arrivée ; le lieu de destination est………………………ville de………………… et de province……………

Le tarif de la location est fixé à………………………………... Ariary, à compte de la date et d’heure du départ du siège jusqu’à la date et heure d’arrivée à ce même point de départ.

Cette période peut être prolongée à la demande du locataire en fonction de la nécessité de service.

N.B. : le carburant et les lubrifiants sont à la charge de la société.

Lu et approuvé

Le client La Société

BIBLIOGRAPHIE

RinahMahaimalala IV

BIBLIOGRAPHIE

- [1] Bjarne Stroustrup « Le langage C++ », 2004, p.1100.

- [2] Christian Casteyde « Cours de C/C++ », 2002, p.468

- [3]Cyril GRUAU « Conception d’une base de données », 2006, p.44

- [4] Fabrice Popineau « Introduction à la Conception Orientée Objet et à UML »,2000,p.53.

- [5] Georges Gardarin, « Maitriser les bases de données », 1993, p.378.

- [6] Henri Garreta « Le langage C++ », 2002, p.74.

- [7] Laurent Piechocki « UML, le langage de modélisation objet unifié », 2007, p.60.

BIBLIOGRAPHIE

RinahMahaimalala V

WEBOGRAPHIE

- [1] www.besoindaide.com/com/bdd

- [2] www.wikipedia.org/wiki/histoiresgbd

- [3]uml.free.fr

- [4] www.wikipedia.org/wiki/algorithme.html

- [5] www.guideinformatique.com/langagec++/htm

- [6] www.commentcamarche.net

Titre :CONCEPTION ET REALISATION D’UN LOGICIEL DE G ESTION DE PARC AUTOMOBILE

Nombre de page : 53

Nombre de figure : 19

Nombre de tableau : 3

RESUME

Cet ouvrage permet de concevoir un outil de programme de traitement des informations

contenant les procédures et les données nécessaires au sein d’un parc automobile.

Pour bien mener à terme le travail, on a utilisé le langage UML, la technologie Orientée

Objet manipulant la puissance du langage C++.

ABSTRACT

This work makes it possible to design a tool of programme of data processing containing

the procedures and the data necessary within an automobile park.

We have used the language UML and the technology Oriented Object handling the power

of the language C++.

Rubrique : Informatique

Mots clés : UML, POO, base de données, parc automobile.

Auteur : MAHAIMALALA Rinah

Adresse : 3TL15 TsaralalanaTsiroanomandidy

Contact : 033 20 186 59/ Email : [email protected]

Directeur de mémoire : Monsieur ANDRIAMANOHISOA HeryZo

Documents

CONCEPTION ET REALISATION D’UN LOGICIEL DE GESTION DE …