Post on 27-Mar-2022
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
CONCEPTION ET REALISATION D’UN
LOGICIEL DE GESTION DE PARC
AUTOMOBILE
MAHAIMALALA Rinah
Monsieur ANDRIAMANOHISOA HeryZo
Enseignant Chercheur à l’Ecole Supérieure Polytechnique Antananarivo
16 Sept 2011
MINISTERE DE L’EDUCATION NATIONALE ET DE LA RECHERC HE
: GENIE MECANIQUE ET PRODUCTIQUE
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
Enseignant Chercheur à l’Ecole Supérieure Polytechnique Antananarivo
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é 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
CONCEPTION ET REALISATION D’UN
LOGICIEL DE GESTION DE PARC
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
MINISTERE DE L’EDUCATION NATIONALE ET DE LA RECHERC HE
: GENIE MECANIQUE ET PRODUCTIQUE
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
, 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;
NOTION SUR LE LANGAGE UML
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
NOTION SUR LE LANGAGE UML
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.
NOTION SUR LE LANGAGE UML
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.
NOTION SUR LE LANGAGE UML
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é.
NOTION SUR LE LANGAGE UML
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
NOTION SUR LE LANGAGE UML
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
L’utilité du diagramme
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.
NOTION SUR LE LANGAGE UML
RinahMahaimalala 9
Les éléments constitutifs du diagramme
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
L’utilité du diagramme
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.
NOTION SUR LE LANGAGE UML
RinahMahaimalala 10
Les éléments constitutifs du diagramme
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.
NOTION SUR LE LANGAGE UML
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.
NOTION SUR LE LANGAGE UML
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.
NOTION SUR LE LANGAGE UML
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
NOTION SUR LE LANGAGE UML
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.
NOTION SUR LE LANGAGE UML
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
L’utilité du diagramme
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.
NOTION SUR LE LANGAGE UML
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
NOTION SUR LE LANGAGE UML
RinahMahaimalala 17
I.4.2 DIAGRAMMES DYNAMIQUES
a) Diagramme de collaboration
L’utilité du diagramme
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.
Les éléments constitutifs du diagramme
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
L’utilité du diagramme
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.
Les éléments constitutifs du diagramme
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.
NOTION SUR LE LANGAGE UML
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
L’utilité du diagramme
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.
Les éléments constitutifs du diagramme
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.
NOTION SUR LE LANGAGE UML
RinahMahaimalala 19
d) Diagramme d'activités
L’utilité du diagramme
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.
Les éléments constitutifs du diagramme
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.
NOTION SUR LA POO ET LA BD
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 ;
NOTION SUR LA POO ET LA BD
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
NOTION SUR LA POO ET LA BD
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.
NOTION SUR LA POO ET LA BD
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.
NOTION SUR LA POO ET LA BD
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.
NOTION SUR LA POO ET LA BD
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.
NOTION SUR LA POO ET LA BD
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
NOTION SUR LA POO ET LA BD
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.
NOTION SUR LA POO ET LA BD
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é.
NOTION SUR LA POO ET LA BD
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
LOGICIEL « GPAuto 1.0 »
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.
LOGICIEL « GPAuto 1.0 »
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
LOGICIEL « GPAuto 1.0 »
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:
LOGICIEL « GPAuto 1.0 »
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:
LOGICIEL « GPAuto 1.0 »
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);};
LOGICIEL « GPAuto 1.0 »
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 ;
LOGICIEL « GPAuto 1.0 »
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
LOGICIEL « GPAuto 1.0 »
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.
LOGICIEL « GPAuto 1.0 »
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.
LOGICIEL « GPAuto 1.0 »
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
LOGICIEL « GPAuto 1.0 »
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 : rnhmahaimalala@yahoo.fr
Directeur de mémoire : Monsieur ANDRIAMANOHISOA HeryZo