Conception Et Réalisation D'un Système D'archivage Électronique Des Documents Au Niveau de SOMIPHOS Tébessa

Ministère de la Formation
et de l’Enseignement Professionnels
Institut National Spécialise Formation
Professionnelle Gestion Chihani Bachir-Tébessa
Code Branche: NT0703 GROUP NUM : 14
Mémoire de la fin d’études pour l’obtention

d’un diplôme de technicien supérieur
Informatique /Option : Bases de données
 Encadrée par
 Bourdja Hanen
 Réaliser par
 DJABRI ABDERRAZAK
 MELAZEM ABDE NOUR
 SADI ABDE LAZIZ
 ZEMMAL LEHBIB
Comité de discussion
Adjectif Grade Nom et Prénom
Président Directeur Belgacem Mounir
Présentateur 1 PSFEP CIP Bayaza Nesrine
Présentateur 2 VAC Menasria Abdel Ali
Encadreur PSFEP CIP Bourdja Hanen
Promotion: 2021/2023
Remerciements
Tous d’abord ; Louange à Dieu qui nous a guidé
pour cela et est heureux d’obtenir par nous accorder
toute réalisation de notre travail Et merci aussi le
professeur BOURDJA HANEN vertueux sur
l’acceptation de l’encadrement de notre travail.
Comme nous remercions tous nos professeurs
qui ont contribué à nous donner toutes
les informations grâce à notre programme d’études
et tout cela grâce à nos parents complets et
la famille qui a contribué.
Nous remercions nos amis qui étaient comme des frères.
Nous remercions tous ceux qui ont contribué
à nous aider de près ou de loin.
Merci à tous.
SOMMAIRE
SOMMAIRE
SOMMAIRE
Remerciements
Table de matière I–V
Sommaire VI – VII
liste de figure VI – VII
liste de tableau VIII - IX
Introduction général A
Problématique B
Objectif du travail C
Chapitre I: Etude de l’existan 5 - 15
Introduction 5
1. Présentation de l’entreprise 5
2. Organigramme générale de SOMIPHOS 7
3. Activités de SOMIPHOS 9
4. Détails des principales fonctions de SOMIPHOS 9
4.1. Président Directeur Général 9
4.2. Secrétariat 9
4.3. Assistant de Sécurité 9
4.4. CERAD 10
4.5. Complexe Minier de Djebel Onk 10
4.6. Direction Commerciale 10
4.7. Direction des Finances et de la Comptabilité : 10
4.8. Direction des Ressources 10
5. Champ d’étude 10
6. Etude de poste 11
7. Etude de documents 12
8. Etude de registre 13
Conclusion 15
Chapitre II : Généralités sur le langage De modélisation UML 16 - 30
Introduction 17
II
SOMMAIRE
1. Présentation du langage UML 17

1.1. UML: un langage de modélisation de type graphique 17
1.2. Historique de l'UML 17
1.3. UML: Termes clés 18
1.3.1. Méta modélisation 18
1.3.2. Unités linguistiques 20
1.3.3. Classe 20
1.3.4. Composants 20
1.3.5. Profil 20
1.3.6. Modèle 21
1.3.7. Action 21
1.3.8. Comportement 21
1.3.9. Activité 21
1.3.10. Distribution 21
1.3.11. Cas d’application 22
1.3.12. Flux d’information 22
2. Les diagrammes UML: leur utilisation et une brève introduction générale 22
2.1. Diagrammes de structure 22
2.2. Diagramme de classes 23
2.3. Diagramme d’objet 23
2.4. Diagramme des composants 23
2.5. Diagramme de structure composite 24
2.6. Diagramme d’ensemble 24
2.7. Diagramme de déploiement 25
2.8. Diagrammes de comportement 25
2.9. Diagramme de cas d’utilisation 25
2.10. Diagramme d’activité 26
2.11. Diagramme d’état-transition 26
2.12. Diagrammes d’interaction 27
2.13. Diagrammes de séquence 27
III
SOMMAIRE
2.14. Diagramme de communication 27

2.15. Diagramme de temps 28
2.16. Diagramme d’aperçu des interactions 29
2.17. Les diagrammes UML : vue d’ensemble 29
3. Pourquoi choisir UML? 29
3.1. Standardisation 29
3.2. Flexibilité 29
3.3. Modélisation orientée objet 30
Conclusion 30
Chapitre III : Modélisation du système 31 - 45
Introduction 32
1. Diagramme de cas d’utilisation 32
2. Diagrammes de séquence 33
2.1. Diagramme de séquence du cas d’utilisation « Authentifier » 33
2.2. Diagramme de séquence du cas d’utilisation « Versement document » 34
2.3. Diagramme de séquence du cas d’utilisation « Modifier document » 35
2.4. Diagramme de séquence du cas d’utilisation « Consulter un document » 36
4. Diagramme de classe 37
5. Modèle relationnel 38
5.1. Les règles de transformation du diagramme de Classes vers Modèle
38
relationnel
5.2. Transformation des entités/classes 38
5.3. Transformation des associations 39
5.4. transformation de l’héritage 41
5.4.1. Décomposition par distinction 42
5.4.2. Décomposition descendante (push-down) 42
5.4.3. Décomposition ascendante (push-up) 43
5.5. Transformation de l’héritage multiple 44
5.6. Agrégations UML 44
6. Le schéma relationnel de notre base de données 45
IV
SOMMAIRE
Chapitre IIV : Réalisation 46 - 49

Introduction 47
1. les outils de développement 47
1.1. Delphi 7 47
1.2. SQL server 47
1.3. StarUML 48
2. présentation de l’application 48
2.1. Interface d’authentification 48
2.2. Interface menu principale 49
Conclusion 49
Conclusion générale 50 – 51
Bibliographie 52 -
V
Liste De
Figure
LISTE DE FIGURE
LISTE DE FIGURE
Num Figure Page

1 Organigramme générale de SOMIPHOS 7
2 Organigramme Champ d’étude 10
3 Méta modélisation 19
4 Diagramme de classes 23
5 Diagramme d'ensemble 24
6 Diagramme de cas d'utilisation 25
7 Digramme de communication 28
8 digramme de temps 28
9 Diagramme de cas d’utilisation 32
10 diagramme de séquence du cas d’utilisation « « Authentifier » 33
11 Diagramme de séquence du cas d’utilisation « Versement document » 34
12 Diagramme de séquence du cas d’utilisation « Modifier Document » 35
13 Diagramme de séquence du cas d’utilisation « Consulter un document » 36
14 Diagramme de classe 37
15 Transformation des entités /classes 38
16 Associations un -a- plusieurs 39
17 Association plusieurs et -a-plusieurs et n-aires 40
18 Transformation d'une association n_aire 40
19 Transformation de l'héritage 41
20 décomposition par distinction d'une association d'héritage 42
21 Décomposition descendante ( push-down) d'une association d'hértage 43
22 Décomposition descendante (push-up) d'une association d'héritage 43
23 Décomposition d'une association d'héritage multiple 44
24 Transformation d'une composition 44
25 Interface d’authentification 48
26 Interface menu principale 49
VII
Liste De
Tableau
LISTE DE TABLEAU
LISTE DE TABLEAU
Num Tableau Page

1 étude de poste (chef service) 11
2 SECTION ARCHIVE ( CHEF SECTION ARCHIVE ) 11
3 étude de poste (agent chargé) 12
4 étude de document 12
5 étude de registre (registre retraité) 13
6 étude de registre (registre de suivi permanent de la sale) 13
étude de register (registre de versement des archives ai niveau de la
7 14
direction de l'unité suage)
8 étude register (registre de mouvement des fonds archivistique interne) 14
9 études de registre (registre éliminé) 15
IX
LISTE DE TABLEAU
INTRODUCTION
GENERAL
X
INTRODUCTION GENERALE
Introduction générale
Le progrès technologique a toujours été le moteur de l'amélioration de notre quotidien,

passant de la mécanique à l'électronique, à l'automatique et à l'informatique. Les nouvelles
technologies de l'information et de la communication incarnent cette évolution. La nécessité
croissante de gagner du temps, de préserver des données et de réduire les coûts effectifs est
stimulante pour les entreprises de toutes tailles cherchant des solutions informatiques
adaptées.
Aujourd'hui, bien que les entreprises exploitent pleinement le potentiel du papier pour
conserver des archives à des fins utilitaires ou légales, la croissance constante de la masse
documentaire pose des défis à une gestion optimale. C'est là qu'interviennent les nouvelles
technologies, telles que les systèmes d'archivage électronique (SAE).
Les SAE sont souvent utilisées pour résoudre les défis informatiques liés au stockage,
à la gestion et à l'archivage à long terme des documents électroniques. Ils répondent à la
nécessité croissante de gérer efficacement des volumes importants de documents tout en
assurant la sécurité et l'intégrité de l'information. Ces systèmes permettent le stockage de
documents variés et offrent des fonctionnalités telles que la gestion des versions, des droits
d'accès, des délais de conservation, ainsi que la vérification de l'intégrité et de l'authenticité
des documents.
Utilisés dans divers domaines tels que l'administration, les entreprises, les
gouvernements, les archives et les bibliothèques, les SAE améliorent l'efficacité et la sécurité
de la gestion des documents électroniques, répondant ainsi aux exigences de l'ère
électronique.
Dans ce contexte, votre projet de déploiement d’une SAE pour la société des mines de
phosphates "SOMIPHOS" est une louable initiative. En répondant aux besoins du bureau des
archives, il facilite le travail des agents.
A
Problématique
L’archivage des documents est une obligation légale pour les entreprises. Une bonne
gestion des archives participe aussi à l’amélioration de la productivité. Elle peut être vitale en
cas de sinistre
Et pour comprendre la problématique qui menace le développement des grandes

entreprises et administration on a effectué un bref stage au sein de la société des mines de
phosphates « SOMIFOS » dans le bureau d’archive, nous avons constaté qu’il présent
certaines lacunes tel que
 La perte de temps dans la recherche des archives

 Possibilité d’avoir des redondances d’information
 Etablissement la Brieux des rapports
 Risque de mélanger les documents ce qui peut être fatal
 L’abondance des documents papier dans l’Enterprise peut ralentir les services
B
Objectif du travail
En tenant compte des critiques et des besoins d’informatiser le service cité ci-dessus
on a proposé de concevoir et développer une application permettant de satisfaire au maximum
possible le bureau d’archivage pour cela l’application doit rependre aux besoins suivants :
 Avoir un logiciel qui respecte les principes des interfaces homme/machine (ihm) tels que
l’ergonomie et la fiabilité
 Réduire les taches manuelles qui nous permettraient de gagner le temps
 Archive les informations en tout confidentialité
 Restituer rapidement les données recherchées
C
Chapitre I
Etude de
l’existan
CHAPITRE I: ETUDE DE L’EXISTAN
Introduction
L’étude d’existant est la première phase qui permet de présenter Déroulement et le

Fonctionnement de système d’information actuel de notre Champ d’étude et à repérer ses
Dysfonctionnements majeurs afin d’y apporter Des solutions optimales. Pour cela nous
Commencerons par présenter notre Organisme et structure d’accueil. Ensuite, nous étudierons
le traitement des Réclamations existantes et l’affectation réelle des techniciens. Enfin, nous
Proposerons des solutions informatiques aux problèmes recensés. Étude de L’existant est la
première phase qui permet de présenter le déroulement et le Fonctionnement de système
d’information actuel de notre champ d’étude et repérer ses dysfonctionnements majeurs afin
d’y apporter des solutions Optimales. Pour cela nous commencerons par présenter notre
organisme et Structure d’accueil. Ensuite, nous étudierons le traitement des réclamations
Existantes et l’affectation réelle des techniciens. Enfin, nous proposerons des Solutions
informatiques aux problèmes recensés.
1. Présentation de l’entreprise
SOMIPHOS, société des mines de phosphates est issue de la restructuration de

FERPHOS (entreprise nationale du Fer et du phosphate), elle-même issue de la restructuration
de la SONAREM par décret 83/384 du 17 juillet 1983 Avec un capital social de 300 000 000
de Dinars algériens.
Son siège social se trouve à Tébessa du fait que c’est cette wilaya qui dispose des plus
grands centres miniers du Pays tels que les mines de l’Ouenza et Boukhara et le complexe
minier de Djebel Onk.
Le 18 octobre 2001, FERPHOS a conclu un partenariat avec le groupe Indien LNM

avec la cession des mines de L’Ouenza et de Boukhara ce qui a réduit à 30% son portefeuille
minier. Elle a alors axé son intervention à d’autres activités telles que :
 La mine de Nini à Sétif
 La mine de Ruina à Ain Defla
 La mine de Chabert El Ballot à Souk AHAs
 La mine de Béni Sa
 La mine de sidi Maalouf à Jijel
5
 Les installations portuaires de Annaba
 Le Complexe minier de Djebel Onk
 La Fonderie de l’Ouenza
 Le siège de l’unité de Tébessa
Les principales unités de SOMIPHOS :
La société des mines de phosphate, objet de notre étude, a été créée par décret 05/154 du
25/01/2005.
L’effectif de l’entreprise à fin 2006 était de 1387 employés de différentes catégories

socioprofessionnelles :
 Exécution : 690
 Maitrise : 551
 Cadres : 104
 Cadres supérieurs : 42
 Contractuels : 359
SOMIPHOS a pour siège social la ville de Tébessa et se compose de 04 principales

unités :
 Le complexe Minier de Djebel Onk
 Les installations portuaires de Annaba
 Le centre d’études et de recherché appliqués (CERAD) à Tébessa
 L’unité siège à Tébessa
Activités de SOMIPHOS
SOMIPHOS active dans les domaines suivants :
 La recherche
 L’exploitation
 Le traitement
 Le transport routier
 La commercialisation et l’exportation de phosphates
6
Les activités commerciales sont l’extraction de phosphate du complexe minier de

Djebel Onk qui contient une Réserve de phosphate de 2 milliards de tonnes, cette mine se
trouve à 90 km de Tébessa, à une distance de 5 Km ou sud-ouest de la ville de Bire El Acter
et à 350 km du port de Annaba. [1]
2. Organigramme générale de SOMIPHOS
Figure 1 : Organigramme générale de SOMIPHOS
7
8
3. Activités de SOMIPHOS
SOMIPHOS opère dans les domaines suivants :
 La recherche
 L’exploitation
 Le traitement
 Le transport routier
 La commercialisation et l’exportation de phosphates
Les activités commerciales consistent en l'extraction de phosphate du complexe minier

de Djebel Onk, qui renferme une réserve de phosphate de 2 milliards de tonnes. Cette mine
est située à 90 km de Tébessa, à 5 km au sud-ouest de la ville de Bire El Acter, et à 350 km du
port d'Annaba.
4. Détails des principales fonctions de SOMIPHOS
4.1. Président Directeur Général
Le président directeur du conseil d'administration, composé de neuf membres, se réunit

en sessions ordinaires et extraordinaires trimestrielles et semestrielles. Ses missions incluent :
 Orientation
 Stratégie de gestion des fonds
 Principale interlocuteur avec les hautes instances en tant que seul représentant de
l'entreprise.
4.2. Secrétariat
 Veiller à tout ce qui concerne le PDG
 Recevoir, classer, envoyer le courrier
 Planifier les rendez-vous
4.3. Assistant de Sécurité
 Veiller à la sécurité interne de l'entreprise
 Veiller à la sécurité des délégations étrangères et à leur prise en charge
9
4.4. CERAD
 Réalisation d'études et de recherches minières et agricoles
4.5. Complexe Minier de Djebel Onk
 Production des différents types de phosphate
 Chargement du phosphate dans des camions à destination du port d'Annaba
4.6. Direction Commerciale
 Commercialisation des produits de l'entreprise par la signature de contrats

conformément à la réglementation en vigueur
 Prise en charge de l'importation d'outils et/ou d'engins nécessaires à l'entreprise
4.7. Direction des Finances et de la Comptabilité :
 Gestion de toutes les finances de l'entreprise
4.8. Direction des Ressources
 Gestion des ressources humaines (personnel) et matérielles (informatique, bureautique,

papeterie) et organisation du travail
Les directions de l'administration générale, de la formation, du juridique et de

l'informatique dépendent hiérarchiquement et organisationnelle ment de cette direction
générale. [1]
5. Champ d’étude
Service archive
Section archive
"Chef de section archive"
Agent chargé des archives
Figure 2 : Organigramme Champ d’étude
10
6. Etude de poste
Leude des postes permet de comprendre les procédures administratives, les relations et
les liens entre les différents services. Par différents permet de déceler les postes surcharges et
les principaux défauts de l’organisation.
 POSET1 : chef service
 POSET2 : section archive (chef de section archive)
 POSET3 : AGENT CHARGE
Fiche descriptive du poste N°1

Désignation du poste : CHEF SERVICE
Dépend :
Responsabilité :
Description des taches
Taches Périodicité
Envoyer des documents de travail
Chef service
Demander des documents de travail
Tableau 1 : étude de poste (chef service)

Désignation du poste : SECTION ARCHIVE (CHEF DE SECTION ARCHIVE)
Dépend :
Responsabilité :
Extraire des documents de travail
Responsable de l’archive
Stocker les documents de travail
Tableau 2 : SECTION ARCHIVE ( CHEF SECTION ARCHIVE )
11

Désignation du poste : AGENT CHARGE
Dépend :
Responsabilité :
Organiser les documents dans l’archive Agent de l’archive
Tableau 3 : étude de poste (agent chargé)
7. Etude de documents
Leude des documents permet de déceler les principales couses du mauvais
fonctionnement de la gestion administrative.
Liste quelques documents en magasin
Entrepôts de conservation
Titre du document La description Période de La
Note
conservation (N) valeur
1. les documents de gestion des stocks

 enregistrer Livre de fonds 10 OUI Enregistrer
 enregistre Journal 10 OUI l’échantillon
 enregistre Livre d’Operations 10 OUI
2. le documents comptables :
 factures 10 OUI
 condition financière Réparation agents 10 OUI
 enregistre les engagements reforme 10 OUI
Enregistrer
 registre des dépenses 10 OUI
 déclaration de paiement des salaires Administration centrale 20 OUI
 fichiers de compte des salariés actifs 15 OUI
 fichiers de compte des salaries retraites 15 OUI
3. honnêteté :
 attestation administrative Preuve de facture 03 NON
 minutes de renonciation Equipement et mobilier 10 NON Exclusion
 correspondance Fournitures et outils de 01 NON
 détection de sorite bureau 05 NON
Tableau 4 : étude de document
12
8. Etude de registre
FICHE DESCRIPTIVE DU REGISTRE N°1
Désignation : registre retraité
Objectif : Garder les informations des retraités
1-Caracteristiques du document
Taux Procédure
Localisation Responsable Support
Code D’activité de sécurité
Bureau Responsable Registre
50/100 Aucune
Archive de l’archive papier
2- Contenu du document
N° Rubrique Type Longueur Obs.
01 Nom A 03
02 Prénom A 06
03 Matricule personnel NUM 17
04 Date de sortie NUM 12 JJ/MM/AAAA
05 N° Ordre NUM 05
06 N° Boite A/NUM 06 A/29/1
Tableau 5 : étude de registre (registre retraité)

Désignation : registre de suivi permanent de la sale
Objectif : enregistré les activités de chaque jour
Taux Procédure
Code Localisation Responsable Support
D’activité de sécurité
Bureau de Responsable Registre
0493 100/100 Aucune
L’archive de l’archive papier
01 Date DATE 04
02 Structure A 09
03 Document lieu classement A 22 JJ/MM/AAAA
04 N° Ordre NUM 07
05 N° Boite NUM/A 07 B/32/4
Tableau 6 : étude de registre (registre de suivi permanent de la sale)
13

Désignation : registre de versement des archives ai niveau de la direction de l’unité suage
Objectif : garder le document qui qui rester plus de 1 mois ou plus
Code Taux Procédure de
Localisation Responsable Support
D’activité sécurité
0687 100/100 Aucune
l’archive de l’archive papier
01 Description de l’article A 20
02 Date extrême A 03 JJ/MM/AAAA
03 Structure versement DATE 04
04 Date de versement DATE 07 JJ/MM/AAAA
05 N° Ordre NUM 07
06 N° Boite NUM/A 07 N/04/1
Tableau 7 : étude de register
(registre de versement des archives ai niveau de la direction de l'unité suage)

Désignation : registre du mouvement des fonds archivistique interne
Objectif : prendre le document de l’archive
Taux Procédure de
Bureau de Responsable Registre en
0678 100/100 Aucune
01 Structure A 05
02 Demandeur A 06
03 Date DATE JJ/MM/AAAA
04 Document NUM/A 07
05 N° Ordre NUM 08
06 N° Boite A/NUM 07 Z/44/7
Tableau 8 : étude register
(registre de mouvement des fonds archivistique interne)
14

Désignation : registre éliminé
Objectif : garder les informations de dossier éliminé
Taux Procédure de
0541 50/100 Aucune
01 Désignation A 11
02 Date d’extrême DATE 13 JJ/MM/AAAA
03 Type A 04
04 État A 04
05 N°
Ordre NUM 07
06 N°
Boite A/NUM 07 N/45/1
Tableau 9 : études de registre (registre éliminé)
Conclusion
L'étude de l'existant nous a permis d'avoir une idée précise sur le fonctionnement de la
structure d'affectation, sur ses possibilités ainsi que sur ses problèmes.
A ce stade de l'étude nous avons une vision plus claire des objectifs et des orientations
de la nouvelle gestion.
Il s'agit maintient d'entamer la conception du système projeté.
15
Chapitre II
Généralités sur
le langage
De modélisation
UML
CHAPITRE II : GENERALITES SUR LE LANGAGE DE MODELISATION UML
Introduction
Après avoir définit les différents besoins fonctionnels et non fonctionnels de notre
application, nous passons à la phase d'analyse et conception ou nous définissons n'utilisons le
langage UML, le Processus UP et les différents acteurs de système, ainsi que les diagrammes
de contexte, les diagrammes de cas d'utilisation, diagramme de séquence et le diagramme de
classe pour passer en fin à réaliser le modèle relationnel associé au diagramme de classe de
notre application.
1. Présentation du langage UML
1.1. UML: un langage de modélisation de type graphique
Le langage UML (Unifie Modeling Langage) est constitué de diagrammes intégrés

utilisés par les développeurs informatiques pour la représentation visuelle des objets, des états
et des processus dans un logiciel ou un système. Le langage de modélisation peut servir de
modèle pour un projet et garantir une architecture d’information structurée ; il peut également
aider les développeurs à présenter leur description d’un système d’une manière
compréhensible pour les spécialistes externes. UML est principalement utilisé dans le
développement de logiciels orientés objet. Les améliorations apportées à la norme dans la
version 2.0 la rendent également adaptée à la représentation des processus de gestion.
1.2. Historique de l'UML
Par rapport à la cinquantaine de méthodes d'analyse et de conception objet qui existaient

au début des années 90, seulement trois d'entre elles se sont détachées nettement au bout de
quelques années. En effet, la volonté de converger vers une méthode unifiée était déjà bien
réelle et c'est pour cette raison que les méthodes OMT, BOOCH et OOSE se sont démarquées
des autres.
OMT (Object Modeling Technique) de James Rembauche et BOOCH de GradyBooch

ont été les deux méthodes les plus diffusées en France et partout ailleurs durant les années 90.
Par ailleurs, OOSE de Ivar Jacobson s'est aussi imposée dans le monde objet pour la partie
formalisation des besoins. [2]
17
Pour aller plus loin dans le rapprochement, James Rembauche et GradyBooch se sont
retrouvés au sein de la société Rational Software et ont été ensuite rejoints par Ivar Jacobson
en se donnant comme objectif de fusionner leurs méthodes et créer UML (Unifié Method
Language).
Il est important de noter que contrairement à ce qui avait été envisagé au départ, le
processus de développement a été sorti du champ couvert par le projet de norme. UML est
donc une norme du langage de modélisation objet qui a été publiée, dans sa première version,
en novembre 1997 par l'OMG (Object Management Group), instance de normalisation
internationale du domaine de l'objet.
En quelques années, UML s'est imposée comme standard à utiliser en tant que langage
de modélisation objet. Aujourd'hui, au milieu de la deuxième décennie des années 2000, nous
avons déjà une dizaine d'années de recul sur l'enseignement et la pratique d'UML en
entreprise.
1.3. UML: Termes clés
Certains appellent "langage de modélisation unifié" la lingua franca parmi les langages
de modélisation, ce qui est vraiment ce qu’elle visait à devenir. Comme mentionné ci-dessus,
UML visualise les états des objets et les interactions entre eux au sein d’un système. Son
utilisation répandue peut être due à la grande influence des membres du groupe de gestion
d’objets (OMG) (y compris IBM, Microsoft et HP). La sémantique structurée y contribue
également. Les diagrammes UML montrent les composants systèmes suivants :
Objets individuels (composants de base) Classes (combinaison d’éléments ayant les

mêmes propriétés) Relations entre objets (hiérarchie et comportement / communication entre
objets) Activité (combinaison complexe d’actions et de composantes comportementales)
Interactions entre les objets et les interfaces.
1.3.1. Méta modélisation
UML 2.0 définit des unités de langage qui fonctionnent à différents niveaux. Vous les
utilisez pour exprimer la structure et le comportement d’un système. La méta-modélisation
inclut tous les éléments d’UML, y compris ceux qui décrivent UML lui-même. Il utilise
quatre niveaux hiérarchisés (M0 à M3).
Le niveau méta-meta M3 spécifie les métadonnées du langage de modélisation et ses

relations à l’aide de la fonction méta objet (MOF). Il définit le méta-modèle et permet
18
également le transfert des métadonnées. Le format XMI défini par les membres du groupe de
gestion d’objets est un outil pratique pour partager des données orientées objet au niveau
méta-méta entre les outils de développement. Le langage de contrainte d’objet (OCL), un
langage de programmation déclaratif, complète UML et régule les conditions limites de la
modélisation. En tant que langage texte, cependant, il n’est qu’un support et ne peut pas être
utilisé pour la modélisation.
Figure 3: Méta modélisation
La méta-modélisation montre la relation hiérarchique entre les niveaux de langue.
L’image montre que la méta modélisation d’UML 2.0, niveau M0 est le niveau de base.
Il représente des objets concrets, réels et des enregistrements de données individuels - par ex.
un objet ou un composant. Le niveau M1 comprend tous les modèles qui décrivent et
structurent les données du niveau M0. Ce sont des diagrammes UML tels que le diagramme
d’activité ou le diagramme de package (expliqué ci-dessous). Pour définir la structure de ces
modèles, les méta-modèles M2 définissent les spécifications et la sémantique des éléments du
modèle.
Si vous voulez créer un diagramme UML compréhensible, vous devez connaître le

méta-modèle UML et ses règles. Le niveau le plus élevé, M3, est un méta-modèle du méta-
modèle. La facilité de méta-objet mentionnée fonctionne à un niveau abstrait qui définit les
méta-modèles. Ce niveau se définit lui-même, car autrement, des méta-niveaux supérieurs
seraient créés. [3]
19
1.3.2. Unités linguistiques

UML (couche M2) définit les règles de sa propre sémantique. Les unités de langage
sont des termes définis dans la superstructure UML 2.0. Cela signifie qu’une représentation
formelle que toutes les personnes concernées peuvent comprendre est possible. Les unités de
langage abstraient des objets et des processus structurés et fonctionnant de la même manière
et leur donnent une forme visuellement représentative. Selon le niveau hiérarchique du
modèle, les éléments assument des tâches plus spécialisées ou définissent d’autres éléments
plus étroitement.
1.3.3. Classe
En tant qu’unité de langage, les classes sont un aspect central d’UML. Vous définissez
ce qu’est une classe et comment les classes interagissent entre elles. Cette unité linguistique
comporte quatre niveaux, allant d’éléments simples à des relations plus complexes :
Core (describes elements from the UML 2.0 infrastructure such as package, namespace,
attribute, etc.) Association modulization (classes whose instances are subclasses within this
class)
1.3.4. Composants
Les composants sont des modules logiciels qui séparent leur contenu du système
externe. Il n’y a qu’une connexion vers l’extérieur par l’intermédiaire d’interfaces ou d’un
port. Un connecteur de composition établit une connexion avec un autre composant via
l’interface. Le connecteur de délégation relie les éléments internes à une interface à la
frontière extérieure. Les composants sont modulaires et interchangeables.
Structure composite : La structure composite des unités de langage décrit les éléments
qui sont protégés vers l’intérieur et vers l’extérieur, comme les composants. Seuls les ports
connectent le contenu au système externe. Les classificateurs dits encapsulés sont composés
d’éléments appelés parties. Les pièces communiquent par l’intermédiaire de connecteurs.
1.3.5. Profil
Un profil configure UML 2.0 pour des besoins spécifiques. Des termes abstraits tels
qu’activité ou objet doivent être spécifiés pour certains projets afin d’améliorer la
compréhension. Vous pouvez utiliser un profil pour ajuster la sémantique et les notations qui
sont définies de manière approximative.
20
1.3.6. Modèle
Le modèle comprend tous les éléments nécessaires pour représenter une vue spécifique
de la structure ou du comportement d’un système. Cela inclut également les influences
externes telles que les acteurs.
1.3.7. Action
Lorsqu’il s’agit de décrire un comportement, les actions sont centrales. Ils représentent
une seule étape dans une activité - une activité, à son tour, est un comportement qui se
compose d’un ensemble d’actions. Voici quelques exemples d’actions :
 Ordre de remplissage
 Afficher la page d'erreur
 Ordre de process
1.3.8. Comportement
L’unité de langage "comportement" ou "description du comportement" désigne la

modélisation des aspects dynamiques d’un système. Il contient trois spécifications :
1.3.9. Activité
Les actions interagissent à travers les flux de données et de contrôle. Il en résulte un
système complexe de comportements - les activités. Interaction : Ce méta-modèle décrit
comment les flux de messages sont échangés entre les objets, quand un message est envoyé et
à quel objet, et quels autres éléments sont affectés par celui-ci. Des machines à états : Dans un
diagramme d’états, ce méta-modèle montre les états (situations aux propriétés immuables) et
les pseudo-états (états sans affectation de valeurs) ainsi que leurs transitions. Les objets d’un
état peuvent être affectés à des actions ou à des activités.
1.3.10. Distribution
Un réseau est constitué d’objets qui sont reliés les uns aux autres par des mailles. Un cas
particulier d’application existe si ces éléments représentent des logiciels exécutables ou des
artefacts. Ces artefacts s’exécutent sur des environnements d’exécution ou des périphériques
que UML 2.0 classe comme nœuds. L’artefact dépend donc du nœud. La distribution
représente cette relation de dépendance qui survient pendant l’installation. [4]
21
1.3.11. Cas d’application

Le cas d’application (en tant qu’unité linguistique) représente la configuration système
requise. L’acteur (une personne ou un système) est un élément qui détermine qui ou quoi doit
effectuer une activité particulière à travers le système. Le système peut également être une
classe ou un composant et est donc décrit comme un sujet. Le cas d’utilisation (en tant
qu’élément de modèle) informe seulement qu’un comportement nommé est attendu qui est
visible par le monde extérieur. Il ne montre généralement pas les actions exactes. Dans une
description comportementale, la modélisation assigne les exigences détaillées au cas
d’application.
1.3.12. Flux d’information

Cette unité de langage UML décrit l’unité d’information sur les éléments et le flux
d’information. Ces éléments de modèle définissent des techniques de description du
comportement qui peuvent être très détaillées, comme les activités ou les interactions. Cette
représentation simplifiée permet l’utilisation universelle de ces éléments de modélisation dans
tous les types de diagrammes UML.
2. Les diagrammes UML: leur utilisation et une brève introduction générale
Le langage de modélisation définit 14 types de diagrammes, qui sont divisés en deux

catégories. Les catégories principales "structure" et "comportement" représentent les concepts
de base représentés par les diagrammes UML. Dans le groupe des diagrammes de
comportement, UML spécifie la sous-catégorie "diagrammes d’interaction". Une quatrième
sous-spécification existe depuis l’élaboration d’UML 2.0 et définit la conception des
diagrammes du modèle.
2.1. Diagrammes de structure
Les diagrammes de structure représentent les éléments individuels d’un système. Ils
sont donc particulièrement adaptés à la représentation de l’architecture logicielle. La
représentation statique ne représente pas un changement, mais plutôt des états et des
dépendances à un moment donné. Les éléments individuels, ou objets, sont reliés les uns aux
autres. Par exemple, un objet appartient à une classe. D’autres composants sont des nœuds
d’ordinateur ou des artefacts - un artefact représente un résultat, par exemple un fichier script
fini.
22
Les diagrammes UML de cette catégorie représentent un système entier ou une sous-
structure. Cette dernière aide, par exemple, à clarifier la structure en détail. La langue de la
catégorie "structure" attribue sept types de diagrammes UML dans UML 2.0 :
2.2. Diagramme de classes
Si les objets ont un comportement commun ou la même structure, vous pouvez les
classifier ou les affecter à une classe. La classe est donc un élément de simplification et de
synthèse (abstraction) pour la représentation visuelle. Les classes et les objets sont reliés entre
eux à l’aide d’interfaces. Tous ces composants et leurs relations entre eux peuvent être
représentés dans un diagramme de classes. Une classe représente ses diagrammes à l’aide
d’un rectangle. Le nom de la classe est en caractères gras, comme indiqué ci-dessous.
Figure 4: Diagramme de classes
La classe "Person" a les attributs "first Name" et "last Name". Les opérations
déterminent si l’instance est affichée (display) ou masquée (hide).
2.3. Diagramme d’objet
Un diagramme d’objets a une structure similaire à celle d’un diagramme de classes. Au

lieu du nom tel qu’il apparaît dans le diagramme de classes (voir "personne" ci-dessus),
le diagramme d’objets met le nom avec le nom du classificateur/catégorie. Selon la
spécification, ceci est souligné (ex. : Helga : Person)
2.4. Diagramme des composants

Un composant est un module isolé du système externe et interagit avec d’autres
composants via des interfaces définies. C’est un sous-type de la classe. Par conséquent, les
23
caractéristiques structurelles telles que les opérations et les attributs définissent plus
clairement le composant. Il existe deux options d’affichage pour la modélisation, selon les
besoins : la vue boîte noire (le contenu est masqué) et la vue boîte blanche (le contenu est
visible).
Vue en boîte blanche d’un composant. Les interfaces nécessaires sont représentées sous
forme de boîtes ("socket") ou de cercles ("Lollipop").
2.5. Diagramme de structure composite
Les objets appartiennent à des classes qui, à leur tour, peuvent également être
classifiées. Ces soi-disant méta-classes sont appelées classificateurs en UML. Le diagramme
de structure composite représente les différents éléments et connecteurs d’un classificateur.
Les pièces font toujours partie de l’ensemble, même si elles ne sont pas nécessairement
nécessaires pour compléter le classificateur. Les connecteurs sont les liens entre les pièces.
Les fonctions ou les services qui nécessitent des composants en dehors du classificateur
envoient des pièces via une interface.
2.6. Diagramme d’ensemble

Un package combine des éléments tels que des interfaces ou des classes dans un espace
de noms (voir note ci-dessous). Les paquets peuvent également fusionner avec d’autres
paquets (fusion de paquets), les importer (importation de paquets), ou contenir d’autres
paquets (sous-paquets). Les diagrammes de structure de paquet lient les contenus
hiérarchiquement, comme dans un diagramme en arbre. Le diagramme de package est utilisé,
par exemple, dans le méta-modèle d’UML 2, et est modulaire dans les systèmes logiciels.
Strictement spécifié, un paquet se compose d’une tête et d’une zone de contenu.
Figure 5: Diagramme d'ensemble
Dans l’en-tête, le mot-clé "package" décrit l’élément. Dans la zone de contenu, le

package comprend une interface et deux classes
24
2.7. Diagramme de déploiement

Un diagramme de déploiement modélise la distribution physique des artefacts sur les
nœuds. Les nœuds sont soit du matériel (nœuds de périphérique) qui peuvent fournir de la
mémoire, soit du logiciel (nœuds d’environnement d’exécution) qui fournit un environnement
pour exécuter des processus. Ils sont représentés sous forme de cuboïdes tridimensionnels.
Ceux-ci contiennent le nom du fichier. Pour les distinguer d’une classe, les cuboïdes ont des
stéréotypes tels que <<artéfact>>>. Le diagramme convient à l’affichage des dépendances
entre les nœuds et les artefacts, appelées relations de distribution.
Diagramme de profil : Les diagrammes de profil sont utilisés au niveau du méta-

modèle. Ils sont utilisés pour assigner un stéréotype à des classes, ou un profil à des packages.
Au niveau méta, il est possible d’adapter le modèle à une autre plate-forme ou domaine. Par
exemple, si vous limitez la sémantique UML dans un profil, elle transmet les spécifications
aux classes subordonnées.
2.8. Diagrammes de comportement
Les diagrammes de comportement couvrent les autres spécifications sous UML.

Contrairement aux diagrammes de structure, ils ne sont pas statiques, mais représentent des
processus. Les diagrammes de comportement comprennent également des diagrammes
d’interaction (voir ci-dessous).
2.9. Diagramme de cas d’utilisation
Les diagrammes de cas d’utilisation montrent le comportement attendu d’un système

ultérieurement. Cette modélisation convient non seulement pour les systèmes logiciels, mais
aussi pour prédire les procédures dans l’entreprise, par exemple. Le cas d’utilisation implique
un acteur (humain ou système) avec un but. Le diagramme porte généralement le nom de la
cible. Les différents cas d’utilisation au sein du système répondent à l’objectif de l’acteur.
Le diagramme de cas d’utilisation représente UML à l’aide d’un rectangle intitulé "cas
d’utilisation". L’expéditeur est l’acteur (il est représenté sous la forme d’un bâton, même s’il
s’agit d’un système - voir ci-dessous). L’acteur est connecté au cas d’application (ellipse avec
étiquette) dans un système (rectangle avec étiquette <<system>>, et nom du système).
25
Figure 6: Diagramme de cas d'utilisation
Le diagramme de cas d’utilisation dans l’exemple a un acteur qui peut s’attendre à deux
cas d’utilisation dans le système "réseau social XYZZZY".
2.10. Diagramme d’activité

Les activités consistent en un réseau d’actions reliées par des flux de données et de
contrôle. Alors que le diagramme de cas d’utilisation montre la configuration système requise,
le diagramme d’activité montre comment ces cas d’utilisation s’exécutent. Dans ce type de
diagramme, les jetons jouent un rôle. Dans les processus parallèles, ils sont un marqueur pour
lequel les processus sont priorisés et reçoivent des ressources (par exemple, la mémoire de
travail).
2.11. Diagramme d’état-transition
Une machine à états, aussi appelée automate fini, représente un ensemble fini d’états
dans un système. Si une condition fixe est remplie dans le système (c’est-à-dire qu’un
déclencheur se déclenche), une réaction correspondante se produit. Il peut s’agir d’activités ou
d’interactions. Sous UML 2.0, un état représente cette situation. Les états sont considérés
comme des sommets et sont affichés sous forme de rectangles aux coins arrondis. En outre, le
diagramme machine d’états modélise les transitions d’un état (nœud source) à l’autre (nœud
cible). [5]
26
2.12. Diagrammes d’interaction

Les diagrammes d’interaction sont un sous-type des diagrammes de comportement. Ils
décrivent également les processus. Ils sont particulièrement adaptés à la modélisation des
comportements dans lesquels les éléments échangent des informations. Les diagrammes
définissent le rôle des objets impliqués. Ils nomment et classent par ordre de priorité les
messages qui sont envoyés d’un objet à l’autre. Les diagrammes d’interaction montrent
également comment ces messages affectent les éléments comportementaux, tels que le
démarrage ou l’arrêt des activités :
2.13. Diagrammes de séquence

En tant que diagramme d’interaction, le diagramme de séquence représente l’échange de
messages entre objets. Le type de diagramme UML modélise ces objets comme une ligne de
vie. En ce sens, il est similaire à d’autres diagrammes comportementaux tels que le
diagramme d’activité. Contrairement à ces derniers, cependant, un diagramme de séquence
n’est pas utilisé pour obtenir une vue d’ensemble du comportement d’un système, mais pour
présenter en détail un comportement possible parmi tant d’autres. Il prescrit une chronologie,
et une ligne pointillée représente le cours du temps. UML 2.0 affiche des messages
synchrones (une flèche à tête remplie) et asynchrones (une flèche à tête ouverte). Les
messages synchrones sont des messages qui bloquent un canal jusqu’à ce qu’ils reçoivent une
réponse de l’objet cible. Ils déterminent les caractéristiques comportementales sous forme
d’opérations synchrones. Les messages asynchrones contrôlent l’objet source appelant. Il
s’agit aussi bien d’opérations asynchrones que de signaux (paquets de données envoyés entre
les actions).
2.14. Diagramme de communication

Semblable à un diagramme de séquence, les diagrammes de communication modélisent
un transfert de message à l’aide de lignes de vie. Cependant, ce diagramme UML n’utilise pas
de lignes pointillées pour les séquences de temps, mais numérote les séquences avec des
chiffres et des lettres. Ces termes de séquence sont situés au-dessus d’une flèche dont
l’extrémité pointe dans la direction du récepteur. Les chiffres représentent l’ordre dans lequel
les messages sont envoyés, les lettres pour le niveau hiérarchique (comme indiqué dans la
figure ci-dessous).
27
Figure 7: Digramme de communication
Les messages asynchrones 1a et 1b sont envoyés en parallèle. Le message avec

l’étiquette 1a.1 envoie l’objet : B avant le message 1a.2b. Objet :D envoie le message 1a.2b.1
seulement après réception du message 1a.2b.
2.15. Diagramme de temps

Un diagramme de temps permet de montrer en détail le comportement des systèmes
sous l’aspect du séquençage temporel. Les systèmes en temps réel, par exemple, doivent
achever certains processus dans un certain laps de temps. Pour mieux représenter un plan de
temps, UML 2.0 modélise les diagrammes de temps en diagrammes bidimensionnels, avec un
axe des x et un axe des y. Dans cette sous-catégorie du diagramme de séquence, les états des
objets se trouvent sur l’axe des y, et les séquences temporelles qui leur sont affectées se
déroulent sur l’axe des y.
Figure 8: digramme de temps
28
Diagramme de temporisation d’une lampe à LED avec changeur de couleur : les

instances de couleur alternent et sont actives pendant le même intervalle de temps.
Diagramme de temporisation d’une lampe à LED avec changeur de couleur : les

instances de couleur alternent et sont actives pendant le même intervalle de temps.
2.16. Diagramme d’aperçu des interactions
Le diagramme de vue d’ensemble des interactions récemment ajouté dans UML 2.0
permet d’afficher un système très complexe dans un schéma approximatif quand un
diagramme d’interaction normal serait trop confus. Un diagramme de séquence convient pour
un affichage détaillé. Le diagramme UML est similaire au diagramme d’activités avec nœuds.
Il représente les flux de contrôle entre les interactions. Ceci est différent d’un diagramme
d’activités, car un diagramme d’interaction entier peut être imbriqué dans des nœuds qui
représentent des activités. Ces imbrications peuvent être affichées directement dans le
diagramme (en ligne) ou se référer au modèle (mot clé : réf) qui est montré en détail ailleurs.
2.17. Les diagrammes UML : vue d’ensemble
La vue d’ensemble suivante montre les catégories et les applications possibles des
différents types de diagrammes UML sous forme abrégée. Si vous souhaitez représenter
visuellement un système logiciel orienté modèle, vous devez d’abord sélectionner l’un des
types de diagramme UML conformément aux recommandations du groupe de travail UML.
Ce n’est qu’alors qu’il vaut la peine de choisir l’un des nombreux outils UML tools, car ceux-
ci nécessitent souvent une certaine méthode. Vous pouvez ensuite créer un diagramme UML.
3. Pourquoi choisir UML?
3.1. Standardisation
UML est un langage de modélisation standard reconnu et largement utilisé dans

l'industrie du logiciel. Il est soutenu par l'Object Management Group (OMG) et dispose d'une
vaste communauté de praticiens et de ressources disponibles. Cette standardisation facilite la
communication et l'échange de modèles entre les différentes parties prenantes.
3.2. Flexibilité
UML offre une grande flexibilité en termes de types de modèles et de perspectives de

modélisation. Il peut être utilisé pour modéliser différents aspects d'un système, tels que la
structure, le comportement, les interactions et les exigences. UML propose également
29
plusieurs diagrammes spécifiques pour représenter différentes vues d'un système, ce qui
permet de mieux répondre aux besoins de modélisation variés.
3.3. Modélisation orientée objet
UML est particulièrement adapté à la modélisation des systèmes orientés objet. Il

fournit des diagrammes tels que les diagrammes de classes, les diagrammes d'objets et les
diagrammes de séquence, qui permettent de représenter efficacement les concepts clés de
l'approche orientée objet, tels que les classes, les objets, les relations et les interactions.
-Support des méthodes de développement agiles : UML s'est adapté pour prendre en
charge les méthodes de développement agiles, telles que Scrum et Extrême Program ming.
Les diagrammes UML peuvent être utilisés pour capturer les besoins, les scénarios utilisateur
et les cas d'utilisation, et faciliter la collaboration entre les membres de l'équipe de
développement. [5]
Conclusion
Comme UML n'impose pas de méthode de travail particulière, il peut être intégré à
n'importe quel processus de développement logiciel de manière transparente, par conséquent
on s'est inspiré de processus unifiés (UP) pour le choix de la méthode de développement.
Cette méthode est dirigée par les cas d'utilisation, on a utilisé le diagramme de cas
d'utilisations et le diagramme de séquences pour modéliser l'aspect comportemental des objets
de notre système, et le diagramme de classes pour modéliser l'aspect structurel de ces objets.
30
Chapitre III
Modélisation
du système
CHAPITRE III : MODELISATION DU SYSTEME
Introduction
Dans ce chapitre, nous présentons la modélisation de notre système en utilisant le

langage UML, nous allons détailler les trois étapes :
Tous d’abord, nous commencerons par définir les diagrammes de cas d’utilisation et
leurs description textuelles, ensuite les cas d’utilisation vont être détaillés en plusieurs
diagrammes de séquences, après on définit les règles de gestion de notre système pour
pouvoir élaborer le diagramme de classe qui décrit la structure du système étudié et nous
terminerons par la représentation de schéma relationnel de notre base de données
1. Diagramme de cas d’utilisation
Il permet de décrire les interactions entre l’acteur et le système
Figure 9 : Diagramme de cas d’utilisation
32
2. Diagrammes de séquence
Le diagramme de séquence est une représentation graphique qui permet de présenter

les interactions entre l’acteur et les composants du système avec des messages présentés dans
un ordre chronologique. Dans cette partie, nous allons présenter les interactions des objets du
système pour les scénarios des cas d’utilisations les plus importants.
2.1. Diagramme de séquence du cas d’utilisation « Authentifier »
Figure 10: diagramme de séquence du cas d’utilisation « « Authentifier »
33
2.2. Diagramme de séquence du cas d’utilisation « Versement document »
Figure 11 : Diagramme de séquence du cas d’utilisation « Versement document »
34
2.3. Diagramme de séquence du cas d’utilisation « Modifier document »
Figure 12 : Diagramme de séquence du cas d’utilisation « Modifier Document »
35
2.4. Diagramme de séquence du cas d’utilisation « Consulter un document »
Figure 13 : Diagramme de séquence du cas d’utilisation « Consulter un document »
36
4. Diagramme de classe
Figure 14 : Diagramme de classe
37
5. Modèle relationnel
5.1. Les règles de transformation du diagramme de Classes vers Modèle relationnel
Nous donnons ci-après quatre règles (de R1 à R4) pour traduire un schéma conceptuel
entité association ou UML en un schéma relationnel équivalent. Il existe d’autres solutions de
transformation, mais ces règles sont les plus simples et les plus opérationnelles [10]
5.2. Transformation des entités/classes
 Réglé 1
Chaque entité devient une relation. L’identifiant de l’entité devient clé primaire pour
la relation.
Chaque classe du diagramme UML devient une relation. Il faut choisir un attribut de la
classe pouvant jouer le rôle d’identifiant.
Si aucun attribut ne convient en tant qu’identifiant, il faut en ajouter un de telle sorte

que la relation dispose d’une clé primaire (les outils proposent l’ajout de tels attributs).
La règle 1 a été appliquée à l’exemple "31' de manière à dériver deux relations
Figure 15 : Transformation des entités /classes
38
5.3. Transformation des associations
Les règles de transformation que nous allons voire dépendent des

cardinalités/multiplicités maximales des associations. Nous distinguons trois familles
d’associations :
 Un-à-plusieurs ;
 Plusieurs-à-plusieurs ou classes-associations, et n-aires ;
 Un-à-un. [6]
Associations un-à-plusieurs
 Réglé 2
Il faut ajouter un attribut de type clé étrangère dans la relation fils de l’association.
L’attribut porte le nom de la clé primaire de la relation père de l’association.
On peut se rappeler cette règle de la manière suivante : la clé de la relation père migre
dans la relation fils.
Les règles R1 et R2 ont été appliquées à l’exemple "32 ». La règle R2 fait apparaître la
clé étrangère "ncomp" dans la relation "fils Avion" qui a migré de la relation "père
Compagnie".
Figure 16 : Associations un -a- plusieurs
Associations plusieurs-à-plusieurs et n-aires
 Réglé 3 :
L’association (classe-association) devient une relation dont la clé
Primaire est composée par la concaténation des identifiants des entités

(classes) connectés à l’association. Chaque attribut devient clé étrangère si l’entité
(classe) connectée dont il provient devient une relation en vertu de la règle R1.
39
Les attributs de l’association (classe-association) doivent être ajoutés à la

nouvelle relation.
Ces attributs ne sont ni clé primaire, ni clé étrangère.
Les règles R1 et R3 ont été appliquées à l’exemple "33". La règle R3 crée la

relation "Affréter" dont la clé primaire est composée de deux clés étrangères.
L’attribut "date Aff" de l’association est ajouté à la nouvelle relation.
Figure 17 : Association plusieurs et -a-plusieurs et n-aires
Les règles R1 et R3 sont appliquées à l’association 3-aire "Affréter". On ne dérive

pas la relation "Jour" car c’est une entité (classe) temporelle. En conséquence, l’attribut
"dateaff" ne devient pas une clé étrangère, mais il est nécessaire pour composer la clé primaire
de la relation modélisant les affrètements
Figure 18 : Transformation d'une association n_aire
40
Associations un-à-un
La règle est la suivante, elle permet d’éviter les valeurs NULL dans la base de données
 Règle 4 :
Il faut ajouter un attribut clé étrangère dans la relation dérivée de l’entité ayant la
cardinalité minimale égale à zéro. Dans le cas de UML, il faut ajouter un attribut clé étrangère
dans la relation dérivée de la classe ayant la multiplicité minimale égale à un. L’attribut porte
le nom de la clé primaire de la relation dérivée de l’entité (classe) connectée à l’association.
Si les deux cardinalités (multiplicités) minimales sont à zéro, le choix est donné entre
les deux relations dérivées de la règle R1. Si les deux cardinalités minimales sont à un, il est
sans doute préférable de fusionner les deux entités (classes) en une seule.
Les règles R1 et R4 sont appliquées à l’exemple "35".
Figure 19 : Transformation de l'héritage
5.4. transformation de l’héritage
Trois décompositions sont possible s pour traduire une association d’héritage en

fonction des contraintes existantes :
 Décomposition par distinction ;

 Décomposition descendante (push-down). S’il existe une contrainte de totalité ou de
partition sur l’association d’héritage, il y aura deux cas possibles de décomposition ;
 Décomposition ascendante (push-up).
41
Nous verrons plus loin que l’héritage multiple se traduit également au niveau logique à
l’aide de ces principes. Nous utilisons ici des diagrammes UML que le lecteur pourra
aisément traduire sous Merise/2.
5.4.1. Décomposition par distinction
Il faut transformer chaque sous-classe en une relation. La clé primaire de la sur-classe

migre dans la (les) relation(s) issue(s) de la (des) sous-classe(s) et devient à la fois clé
primaire et clé étrangère.
L’exemple "36" applique la règle R1. L’association d’héritage est traduite en faisant
migrer l’identifiant de la sur-classe (Personnel) dans les deux relations déduites des sous-
classes.
Cet attribut devient aussi clé étrangère.
Figure 20 : décomposition par distinction d'une association d'héritage
5.4.2. Décomposition descendante (push-down)
Deux cas sont possibles : [6]
 S’il existe une contrainte de totalité ou de partition sur l’association, il est possible de ne
pas traduire la relation issue de la sur-classe. Il faut alors faire migrer tous ses attributs
dans la (les) relation(s) issue(s) de la (des) sous- classe(s).
 Dans le cas contraire, il faut faire migrer tous ses attributs dans la ou les relation(s)
issue(s) de la (des) sous-classe(s) dans la (les) relation(s) issue(s) de la (des) sous-
classe(s).
L’exemple "37" décrit une contrainte de partition dans l’association d’héritage (aucun
personnel ne peut être à la fois PNT et PNC et il n’existe pas un personnel n’étant ni PNT ni
42
PNC). Les deux relations héritent du contenu intégral de la relation issue de la sur-classe
(Personnel). La relation Personnel n’apparaît plus au niveau logique et n’est pas nécessaire,
car aucun personnel ne peut être ni PNT ni PNC. Ici, on peut dire que Personnel est une entité
Abstraite (il n’existera pas d’instance de cette entité)
Figure 21 : Décomposition descendante ( push-down) d'une association d'hértage
5.4.3. Décomposition ascendante (push-up)
Il faut supprimer la (les) relation(s) issue(s) de la (des) sous-classe(s) et faire migrer

les attributs dans la relation issue de la sur-classe.
L’exemple "38" décrit une association d’héritage UML sans contrainte. En appliquant
le principe de décomposition ascendante, nous obtenons une relation issue de la sur-classe
dans laquelle se trouve le contenu des relations issues des sous-classes.
Figure 22 : Décomposition descendante (push-up) d'une association d'héritage
43
5.6. Transformation de l’héritage multiple
Les trois décompositions que nous avons étudiées peuvent s’appliquer à

l’héritage multiple. Chaque association présente dans la hiérarchie pourra être traduite par
distinction, de manière descendante ou de manière ascendante. [6]
Figure 23 : Décomposition d'une association d'héritage multiple
Ainsi, pour le schéma "39", il est possible de combiner différentes décompositions

pour le même graphe d’héritage. Dans notre exemple, nous choisissons d’utiliser la
décomposition par distinction pour le premier niveau d’héritage, et la décomposition
ascendante (push-up) pour le second niveau d’héritage. Les relations finales sont notées en
gras.
5.7. Agrégations UML

Alors que l’agrégation partagée de UML se traduit au niveau logique comme une
simple association, il n’en est pas de même pour la composition. L’exemple "40" décrit le
schéma relationnel déduit d’une composition (on suppose que l’attribut a identifié la classe
composante et que l’attribut c identifie la classe composite).
Figure 24 : Transformation d'une composition
44
6. Le schéma relationnel de notre base de données
Après l’utilisation des règles de transformation, on a réalisé la base de données

suivante :
 Emplacement (ID_ Emplacement, libellé_emplac, référence_emplac, Descreption_emplac)

 Dossier (ID_Dossier, théme_dossier, nbr_document, #ID_emplacement)
 Document (Id_document, nom_document, Date_création, creé_par_emp,
extention_fichier, #ID_dossier, #ID_type_document)
 Type_document (ID_type_document, nom_type, chemin_type_doc)
 Index_document (ID_index,nom_index)
 Contient2 (#ID_Index, #ID_document)
 Demande_versement (ID_demande_versement, copie original, nom_employé_versant,
Date_demande_versement, #ID_service)
 Service (ID_servise, nom_service, descreption)
 Concerne (#ID_demande_versement, #ID_document)
 Demande_restitution (ID_demande_restitution, Date_demande, #ID_service,
#ID_demande_particulier)
 Demande_particulier (ID_demande_particulier, nom_demandeur, raison_demande)
 Elimination (ID_Elimination, Date_suppression, #ID_document)
45
Chapitre IIV
Réalisation
CHAPITRE IIV : REALISATION
Introduction
Après avoir présenté l’architecture de notre système dans le chapitre précèdent, Nous
allons maintenant introduire les outils utilisés dans la réalisation de notre système et les
environnements de développement, ainsi nous allons présenter les différentes interfaces pour
expliquer le fonctionnement des fonctionnalités de ce système.
1. les outils de développement
1.1. Delphi 7
Delphi est un langage compilé de haut niveau a types stricts qui gère la conception
structurée et orientée objet. Basé sur Object pascal, ses avantages incluent la lisibilité du code,
une compilation rapide et l’utilisation de multiples fichiers unité permettant une
programmation modulaire et il simplifie de nombreuses tâches liées à la programmation en
langage pascal
Les avantages de Delphi 7 :
 Langage puissant et convivial

 Compatibilité multiplateforme
 Bibliothèque de composant VCL et Firemonkey
 Performance
 Sécurité
 Support de bases de données
1.2. SQL server
Est un système de gestion de base de données (SGBD) en langage SQL incorporant

entre autres un SGBDR (SGBD relationnel) développé et commercialisé par la société
Microsoft. Il fonctionne sous les OS Windows et linux (depuis mars 2016), mais il est
possible de le lancer sur mac OS via Docker car il en existe une version sur le site de
Microsoft.
Fonctionnalités pour le développement
Le moteur OLTP de SQL server est doté de très nombreuses fonctionnalités qu’il serait
difficile de la toutes énumèrerez, en voici quelques-unes qui font la différence avec des SGBD
plus légers comme MySQL.
47
1.3. Star UML
Après l’étude de logiciel on a vu que la meilleure méthode qu’on utilise dans notre
projet c’est la méthode agile, pour sa facilité et sa commodité dans le court temps de travail
réduit puisque cette méthode ne compte pas sur tous les diagrammes en uml.
starUml est un logiciel de modelage UML qui est entré récemment dans le monde de
l’open source. Ecrit en Delphi il est modulaire et propose plusieurs générateurs de code.
2. présentation de l’application
2.1. Interface d’authentification
L’interface d’authentification : est la première fenêtre visualisée par l’utilisateur Il devra

taper son nom d’utilisateur, son mot de passe pour pouvoir accéder à la suite de l’application.
Figure 25 : Interface d’authentification
48
2.2. Interface menu principale
Représente l’interface juste après le succès de l’authentification elle permet d’accéder

aux différentes fonctionnalités offertes par l’application créer un document et verser et
imprimer et supprimer et rechercher sans les fonctions qui contient.
Figure 26 : Interface menu principale
Conclusion
Dans ce chapitre, nous avons présenté la partie de réalisation de notre projet, et nous
avons décrit les pages les plus importantes de notre application.
49
Conclusion
Générale
CONCLUSION GENERALE
CONCLUSION GENERALE
Ce projet fin d'étude nous a permis d'acquérir les compétences suivantes :
 Etudier et analyser un système d'information existant et prendre leur besoins en

considération pour les implémenter dans la nouvelle application.
 Utiliser les techniques paradigmes orientés objet.
 Modéliser les fonctionnalités avec des cas d'utilisation.
 Représenter les données du système avec un diagramme de classe.
 Maitriser la programmation avec le langage Delphi.
 Utiliser le système SQL server pour la définition et la manipulation des données.
Comme perspective, nous proposons d'étendre l'application par les fonctionnalités

suivantes :
 Héberger l'application sur le Web.

 Etendre l'application pour qu'elle permettre de gérer gérer tous les périphériques et les
composants des ordinateurs qui n'ont pas été mentionnés.
Finalement, nous espérons que notre travail sera un aide pour autre personne.
51
Bibliographies
BIBLIOGRAPHIES
BIBLIOGRAPHIES
[1] : Information provided by the Phosphate Mines Corporation SIMIPHOS

Tébessa, dated: 09/24/2023, time: 13:00
[2] UML (informatique), Information available on the website:
https://fr.wikipedia.org/wiki/UML_(informatique), Date of access: 29/08/2023, Time:
17:00
[3] Qu'est-ce que le langage UML (langage de modélisation unifié) ?, Information available
on the website: https://www.lucidchart.com/pages/fr/langage-uml, Date of access:
02/10/2023, Time: 14 :00
[4] Mohamed Nemiche, Modélisation UML Diagrammes de Cas d’utilisation, Cours création
pages dynamiques FI4, université beskra, alger, 2021/2022.
[5] Modèles et diagrammes UML, Information available on the website:

https://www.ibm.com/docs/fr/rational-soft-arch/9.5?topic=diagrams-uml-models, Date
of access: 04/10/2023, Time: 10 :00
[6] Robert Ogor, Modélisation avec UML, ENSET Bretagne mai 2003.
53
ANNEXE
ANNEXE
ANNEXE
2
ANNEXE
3
ANNEXE
4
ANNEXE
5
Résumé
Pour comprendre le problème qui menace le développement des grandes entreprises et des départements dans la
gestion des documents d'archives, nous avons mené une enquête appliquée sur l'une des institutions économiques les
plus importantes et les plus marquantes qui soutiennent l'économie algérienne, qui est la Société des Mines de
Phosphates « SOMIPHOS », précisément. au niveau du bureau des archives, car nous avons constaté qu'il souffre de
quelques défauts tels que :
 Perdre du temps à chercher des archives
 La possibilité de duplication d'informations
 Le risque de mélange de documents, pouvant entraîner une perturbation des tâches et de l'activité
 Le grand nombre de documents papier dans l'entreprise, qui peuvent ralentir les tâches
Compte tenu des critiques et de la nécessité d'informatiser le service précité, nous avons proposé de concevoir et
de développer une application de gestion du bureau d'archives, à condition que cette application réponde aux besoins
suivants :
 Disposer d'un logiciel respectant les principes de l'interface homme/machine (IHM) tels que l'ergonomie et la
fiabilité
 Réduire les tâches manuelles nous permettant de gagner du temps
 Archiver les informations en toute confidentialité
 Récupérez rapidement les données recherchées.
‫الملخص‬
‫ قمنا بإجراء التربص التطبيقي بأحد أهم وأبرز‬،‫لفهم اإلشكالية التي تهدد تطور الشركات واإلدارات الكبيرة في إدارة الوثيقة األرشيفية‬
‫" وبالضبط على مستوى‬SOMIPHOS" ‫المؤسسات اإلقتصادية التي تقوم على دعم اإلقتصاد الجزائري أال وهي مؤسسة مناجم الفوسفات‬
:‫ إذ الحظنا أنها تعاني من بعض العيوب مثل‬،‫مكتب األرشيف‬
‫ إضاعة الوقت في البحث عن األرشيف‬
‫ إمكانية وجود تكرار للمعلومات‬
‫ خطر خلط المستندات الذي قد يؤدي إلى تعطل المهام والنشاط‬
‫ كثرة المستندات الورقية في الشركة والذي يمكن أن يبطئ المهام‬
‫ اقترحنا تصميم وتطوير تطبيق لتسيير مكتب‬،‫ومع األخذ بعين االعتبار االنتقادات والحاجة إلى حوسبة الخدمة المذكورة أعاله‬
:‫األرشفة على شريطة أن يلبي التطبيق االحتياجات التالية‬
‫( مثل بيئة العمل والموثوقية‬HMI) ‫اآللة‬/‫ •امتالك برنامج يحترم مبادئ واجهات اإلنسان‬
‫ •تقليل المهام اليدوية مما يتيح لنا توفير الوقت‬
‫ •أرشفة المعلومات بسرية تامة‬
.‫ •استعادة البيانات التي تم البحث عنها بسرعة‬
Abstract
To understand the problem that threatens the development of large companies and departments in managing
archival documents, we conducted an applied investigation into one of the most important and prominent economic
institutions that support the Algerian economy, which is the Phosphate Mines Corporation “SOMIPHOS”, precisely at
the level of the archive office, as we noticed that it suffers from some defects such as :
 Wasting time searching for archives
 The possibility of duplication of information
 The risk of mixing documents, which may lead to disruption of tasks and activity
 The large number of paper documents in the company, which can slow down tasks
Taking into account the criticisms and the need to computerize the above-mentioned service, we proposed
designing and developing an application to manage the archiving office, provided that the application meets the
following needs:
 Have software that respects human/machine interface (HMI) principles such as ergonomics and reliability
 Reduce manual tasks allowing us to save time
 Archive information with complete confidentiality
 Recover searched data quickly.

Conception Et Réalisation D'un Système D'archivage Électronique Des Documents Au Niveau de SOMIPHOS Tébessa

Transféré par

Droits d'auteur :

Formats disponibles

Conception Et Réalisation D'un Système D'archivage Électronique Des Documents Au Niveau de SOMIPHOS Tébessa

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception Et Réalisation D'un Système D'archivage Électronique Des Documents Au Niveau de SOMIPHOS Tébessa

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de la Formation

Mémoire de la fin d’études pour l’obtention

pour cela et est heureux d’obtenir par nous accorder

toute réalisation de notre travail Et merci aussi le

professeur BOURDJA HANEN vertueux sur

l’acceptation de l’encadrement de notre travail.

Comme nous remercions tous nos professeurs

qui ont contribué à nous donner toutes

les informations grâce à notre programme d’études

et tout cela grâce à nos parents complets et

la famille qui a contribué.

Nous remercions nos amis qui étaient comme des frères.

Nous remercions tous ceux qui ont contribué

à nous aider de près ou de loin.

1. Présentation du langage UML 17

2.14. Diagramme de communication 27

Chapitre IIV : Réalisation 46 - 49

Num Figure Page

Num Tableau Page

Le progrès technologique a toujours été le moteur de l'amélioration de notre quotidien,

Et pour comprendre la problématique qui menace le développement des grandes

 La perte de temps dans la recherche des archives

CHAPITRE I: ETUDE DE L’EXISTAN

L’étude d’existant est la première phase qui permet de présenter Déroulement et le

SOMIPHOS, société des mines de phosphates est issue de la restructuration de

Le 18 octobre 2001, FERPHOS a conclu un partenariat avec le groupe Indien LNM

 La mine de Nini à Sétif

 La mine de Ruina à Ain Defla

 La mine de Chabert El Ballot à Souk AHAs

 La mine de sidi Maalouf à Jijel

 Les installations portuaires de Annaba

 Le Complexe minier de Djebel Onk

 Le siège de l’unité de Tébessa

Les principales unités de SOMIPHOS :

L’effectif de l’entreprise à fin 2006 était de 1387 employés de différentes catégories

SOMIPHOS a pour siège social la ville de Tébessa et se compose de 04 principales

 Le complexe Minier de Djebel Onk

 Les installations portuaires de Annaba

 Le centre d’études et de recherché appliqués (CERAD) à Tébessa

 L’unité siège à Tébessa

SOMIPHOS active dans les domaines suivants :

 La commercialisation et l’exportation de phosphates

Les activités commerciales sont l’extraction de phosphate du complexe minier de

2. Organigramme générale de SOMIPHOS

Figure 1 : Organigramme générale de SOMIPHOS

 La commercialisation et l’exportation de phosphates

Les activités commerciales consistent en l'extraction de phosphate du complexe minier

4. Détails des principales fonctions de SOMIPHOS

4.1. Président Directeur Général

Le président directeur du conseil d'administration, composé de neuf membres, se réunit

 Stratégie de gestion des fonds

 Veiller à tout ce qui concerne le PDG

 Recevoir, classer, envoyer le courrier

 Planifier les rendez-vous

4.3. Assistant de Sécurité

 Veiller à la sécurité interne de l'entreprise

 Veiller à la sécurité des délégations étrangères et à leur prise en charge

 Réalisation d'études et de recherches minières et agricoles

4.5. Complexe Minier de Djebel Onk