Rapport Arij Yosra Workflow

Remerciements
Nous tenons à remercier dans un premier temps, notre encadrant académique,

Dr. Ahmed HADED, pour son aide précieuse,ses conseils judicieux, pour le
temps qu’il nous a consacré tout au long de la période du travail, répondant
avec bienveillance à toutes nos interrogations.
Nous tenons à exprimer une sincére reconnaissance à notre encadrant professionnel,

M. Kais ELJENZRI , Chef de la service technique au sein de la municipalité
sousse , pour la confiance qu’il nous a accordée pendant notre stage ainsi que
pour l’expérience enrichissante et pleine d’intérêt et qu’il nous a fait vivre durant
ces trois mois. Nous le remercions pour sa participation active ‘a l’élaboration
de ce rapport.
Nous remercions également toute l’équipe pédagogique de l’Institut Supérieur

de Gestion de Sousse et les intervenants professionnels responsables de la formation
de Licence Fondamentale en Informatique Appliquée a la Gestion, pour avoir
assurée la partie théeorique de celle-ci.
1
Table des matières
1 Etude préalable 9
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Contexte du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Présentation de la société d’accueil : . . . . . . . . . . . . . . 9
1.2.2 Services offerts : . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Étude préalable : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.1 Le workflow : . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.2 Gestion electronique de document . . . . . . . . . . . . . . . 14
1.3.3 Présentation du sujet . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Cahier de charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.1 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.2 L’application de la municipalité : . . . . . . . . . . . . . . . . 17
1.4.3 l’application de R’ads . . . . . . . . . . . . . . . . . . . . . . 19
1.5 Critique de l’existant : . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6 Spécification des besoins : . . . . . . . . . . . . . . . . . . . . . . . . 21
1.6.1 Les besoins fonctionnels : . . . . . . . . . . . . . . . . . . . . 21
1.6.2 les besoins non fonctionnels . . . . . . . . . . . . . . . . . . 22
1.7 Solution proposée : . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.8 Architecture envisagée : . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.9 Planning des tâches : . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.10 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 Elaboration 26
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2 Méthode et outils de modélisation choisis . . . . . . . . . . . . . . 26
2.2.1 Méthode de modélisation choisie : . . . . . . . . . . . . . . . 26
2.2.2 Choix de la laungage de conception : . . . . . . . . . . . . . 27
2.2.3 Outil de modélisation (MS Visio) : . . . . . . . . . . . . . . . 29
2.3 Modèle métier (Diagramme de Cas d’utilisation) : . . . . . . . . . 30
2
2.3.1 Diagramme de cas d’utilisation : . . . . . . . . . . . . . . . . 30
2.3.2 Identification des acteurs : . . . . . . . . . . . . . . . . . . . 31
2.3.3 Diagramme processus métier : . . . . . . . . . . . . . . . . . 32
2.4 Spécification des cas d’utilisation : . . . . . . . . . . . . . . . . . . . 33
2.4.1 CU : S’authentifier . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.2 CU : Gérer utilisateur : . . . . . . . . . . . . . . . . . . . . . 35
2.4.3 CU :Gerer Demande : . . . . . . . . . . . . . . . . . . . . . . 38
2.4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.5 Identification des cas d’utilisation du système : . . . . . . . 44
2.4.6 Diagramme sequence systéme : . . . . . . . . . . . . . . . . . 46
2.5 conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3 Analyse et conception 51
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1 Modèle d’analyse (Diagramme de traçabilité et diagramme
de classe d’analyse) . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2 Modèle du domaine (Diagramme de Classe) . . . . . . . . . 61
3.3 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3.1 Diagrammes de séquence . . . . . . . . . . . . . . . . . . . . 62
3.3.2 Diagramme de déploiement : . . . . . . . . . . . . . . . . . . 73
3.4 conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4 Réalisation du système 77
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2 Environnement de développement . . . . . . . . . . . . . . . . . . . 77
4.2.1 Environnement matériel : . . . . . . . . . . . . . . . . . . . . 77
4.2.2 Environnement logiciel : . . . . . . . . . . . . . . . . . . . . . 77
4.3 Présentation des exemples d’interfaces de l’application . . . . . . . 86
4.3.1 Présentation des interfaces administrateur : . . . . . . . . . 86
4.3.2 Présentation des interfaces utilisateur : . . . . . . . . . . . . 86
4.3.3 Présentation des interfaces client : . . . . . . . . . . . . . . . 86
4.4 Conclusion : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3
Table des figures
1.1 Logo du la Municipalité "Sousse" . . . . . . . . . . . . . . . . . . . 9

1.2 : Fiche technique de la "Municipalite" . . . . . . . . . . . . . . . . 10
1.3 L’organigramme de la municipalité sousse . . . . . . . . . . . . . . 10
1.4 exemple BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5 Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6 Structure descriptif du projet . . . . . . . . . . . . . . . . . . . . . . 17
1.7 Interface de l’application de municipalité . . . . . . . . . . . . . . 18
1.8 Interface de l’application de municipalité . . . . . . . . . . . . . . . 19
1.9 Interface de l’application de R’ads . . . . . . . . . . . . . . . . . . . 20
1.10 Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.11 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1 les phases de processus unifié . . . . . . . . . . . . . . . . . . . . . . 27
2.2 Logo d’UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3 Logo de MS visio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4 cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5 Raffinement de cas Gérer utilisateur . . . . . . . . . . . . . . . . . 35
2.6 Raffinement de cas : Gérer demande(Admin) . . . . . . . . . . . . 38
2.7 Raffinement de cas : Gérer demande . . . . . . . . . . . . . . . . . 38
2.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.9 Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.10 Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.11 Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.12 Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.13 Caption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1 Traçabilité du cas d’utilisation « Gérer les Utilisateurs » . . . . . 52
3.2 Traçabilité du cas d’utilisation « Gérer Demande : Client » . . . 54
3.3 Diagramme de classe d’analyse du cas « Gérer Demande : Client » 55
3.4 Traçabilité du cas d’utilisation « Vérifier Demande » . . . . . . . 57
4
3.5 Diagramme de classe d’analyse du cas « Vérifier Demande » . . . 57
3.6 Traçabilité du cas d’utilisation « Ajouter un PV » . . . . . . . . . 59
3.7 Diagramme de classe d’analyse du cas « Ajouter un PV » . . . . . 60
3.8 Méthode MVC [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.9 Diagramme de Séquence « Authentification » . . . . . . . . . . . . 64
3.10 Diagramme de Séquence « Ajouter Utilisateur » . . . . . . . . . . 65
3.11 Diagramme de Séquence « Modifier Utilisateur » . . . . . . . . . 67
3.12 Diagramme de Séquence « Supprimer Utilisateur » . . . . . . . . 68
3.13 Diagramme de Séquence « Déposer Demande » . . . . . . . . . . 69
3.14 Diagramme de Séquence « Modifier Demande » . . . . . . . . . . 71
3.15 Diagramme de Séquence « Vérifier Demande » . . . . . . . . . . . 72
3.16 Diagramme de Déploiement . . . . . . . . . . . . . . . . . . . . . . 74
5
Liste des tableaux
2.1 Scénario de cas "S’authentifier" . . . . . . . . . . . . . . . . . . . . 34

2.2 Scénario de cas :"consulter liste utilisatuers" . . . . . . . . . . . . 35
2.3 Scénario de cas :"Modifier utilisateur" . . . . . . . . . . . . . . . . 36
2.4 Scénario de cas :"Suprimer utilisatuer" . . . . . . . . . . . . . . . . 37
2.5 Scénario de cas :"déposer demande " . . . . . . . . . . . . . . . . . 39
2.6 Scénario de cas :"Créer Compte" . . . . . . . . . . . . . . . . . . . 40
2.7 Scénario de cas :"Modifier compte" . . . . . . . . . . . . . . . . . . 41
2.8 Scénario de cas :"Consulter Demande " . . . . . . . . . . . . . . . . 42
2.9 Scénario de cas :"Ajouter PV" . . . . . . . . . . . . . . . . . . . . . 42
4.1 Matériels de developpement . . . . . . . . . . . . . . . . . . . . . . 77
6
Introduction générale
Dans la plupart des secteurs de nos jours, les déclarations papier sont en voie
de disparition pour faire place à l’informatique L’usage de cette dernière dans la
domaine urbain tunisienne souffre de nombreux aspects négatifs.Les processus
de contrôle du développement et de délivrance des permis de construire sont des
raisons important dans les developments urbaine ,financières ,sociale ,peut être
aussi économique .pour surmonter plusieurs problèmes il est évident d’introduire
une technologie puissante qui peut être utilisée pour délivrer des permis de
construire.
Le besoin de construire de nouveaux bâtiments résidentiels et de service est

un absolu doit, mais cette sectuer malgré son importance n’a aucune developments
au niveau de logiciels pour rendre les services de la municipalité tunisienne plus
productifs et éviter tous les types des corruptions afin de mettre les citoyens au
processus de délivrance de permis de construire Il est donc essentiel d’équilibrer
les éléments du développement urbain avec les outils de la nouvelle technologies.
A cet effet, le travail que nous préparons, dans le cadre du projet de fin
d’études, à l’Institut Supérieur de Gestion de Sousse , en vue de l’obtention
du diplôme de licence fondamentale en informatique appliquée à la gestion,
consiste à développer une application dédiée à la municipalité "sousse" qui
fornir une espace collaboratif de trvail entre l’equipe de département technique
, permet de achiver les documents de chaque demande ,connaitre l’hostorique
de delivrance de demande ,Notre application met en valeur la relation entre
les citoyens et la municipalité par le suivi de procedure de etude pour chaque
demande et de savoir la décision en ligne afin de limiter plusieur probléme au
secteur de urbanisme.
Notre rapport se subdivise en quatre chapitres principaux dans lesquels nous

détaillons les diérentes activités du processus Unifié : expression des besoins,
conception et implémentation. Pour ce faire, nous suivons la structure suivante:
Ce rapport est clôturé par une conclusion où nous résumons notre projet et
présenterons les diérentes perspectives que nous pouvons y apporter.
7
Chapitre 1: Etude préalable
1.Introduction
2.contexte de travail
2.1 Présentation de la société d’accueil
2.2 Services offerts
3.Étude préalable
3.1 Le workflow
3.2 Gestion electronique de document
3.3 Présentation du sujet
4 . Cahier de charge
4 Étude de l’existant
4.1 L’appliaction de la municipalité
4.2 l’application de R’ads
5. Critique de l’existant
6. Spécification des besoins
6.1 Les besoins fonctioneels
6.2 Les besoins non fonctioneels
7 . Soulution proposée
8. Architecture a envisagée
9. Planning de tâches
10.Conclusion
8
Chapitre 1
Etude préalable
1.1 Introduction
Nous allons essayer tout d’abord de mettre notre application dans son contexte
général. Pour cela, ce chapitre sera consacré à la présentation de l’organisme
d’accueil et à l’exposition de la problématique menant à l’idée de ce projet
dont nous révélerons brièvement ses objectifs. Ainsi on va essayer de détailler
les concepts de base à utiliser.
1.2 Contexte du travail

1.2.1 Présentation de la société d’accueil:
Nous présentons l’organisme d’accueil "Municipalité de

Sousse" dans lequel nous avons effectué notre stage de fin
d’études.
– La commune de Sousse est une collectivité locale, dotée de
la personnalité civile et de l’autonomie financière et chargée
de la gestion des intérêts municipaux. Elle participe dans
le cadre du plan national de développement à la promotion Figure 1.1
économique sociale et culturelle de la localité. – Logo du la
Municipalité
"Sousse"
9
Figure 1.2 – : Fiche technique de la "Municipalite"
Fiche de renseignements généraux :

L’organigramme de la municipalité sousse :
La structure de la municipalité est simple et bien ordonnée. Les différents

services qui existent assurent des multitâches complémentaires afin de réaliser
les bonnes conditions de travail.
L’organigramme du la municipalité :
Figure 1.3 – L’organigramme de la municipalité sousse
10
1.2.2 Services offerts:
Les services municipaux placés sous l’autorité du Maire sont dirigés par
le secrétaire général de la ville. Ces services sont organisés en sept directions
générales opérationnelles et logistiques dont les activités correspondent aux
principales compétences de la commune.
Direction du développement municipal:
Service de l’Etat Civil.
Service des Affaires Economique et Sociales.
Services de la Culture et des Loisirs.
Services de la Jeunesse, de l’Enfance et des Sports.
Direction des affaires municipales :
Service d’Ordre Central, de la Documentation et des Archives.
Service des Fonctionnaires et des Ouvriers.
Direction des affaires financières :
Services du Budget et des Prêts.
Services de la Comptabilité Analytique.
Service des Marchés et de l’Approvisionnement.
Service du Magasin Municipal.
Direction des ressources municipales:
Services des Affaires Foncières des Participations et des Publicités.
Services des Taxes Immobilières.
Services des Marchés et Abattoirs.
Direction générale technique
Direction de l’affaire urbaine :
Service des Etudes des Aménagements Urbains et d’Architecture.
Service des Lotissements, de la Technologie et de la Cartographique.
Service Autorisation de Bâtir et des Exploitations des Bâtiments.
Directions de travaux :
Services des Bâtiments Administratifs.
Service de la Sauvegarde de la Medina et des la Réhabituions des Monuments
Historiques et Religieuses.
Services de Modernisation des Routes et des Réseaux.
Services des Chaussées et de l’Embellissement de la ville.
Service d’Entretien et d’Eclairage.
Direction de la propreté ,de la sante et de l’environnement :
Service de la Propreté
11
Service de l’Environnement et de l’Amélioration de la qualité de vie.
Service de l’Aménagement des Espaces Vertes et du Pépinières.
Service de la Santé Vétérinaire Générale.
Service de la Réglementation d’Hygiène
1.3 Étude préalable :

1.3.1 Le workflow:
Définition du workflow :
Le workflow est un processus qui fait apparaitre une suite de tâches et

d’opérations effectuées par une personne, ou par une entité (groupe, organisme. . . ).
Il s’agit de modéliser l’ensemble des tâches à accomplir et de mettre en évidence
les différents acteurs qui y sont impliqués dans le cadre d’un processus métier
(interactions sous forme d’échange d’informations entre les différents acteurs
d’une entreprise).
Les concepts de base :
La norme de modélisation des processus métier (BPMN) est une méthode

d’organigramme qui modélise de A à Z les étapes d’un processus métier planifié.
Élément clé de la gestion d’un processus métier, elle permet de représenter
visuellement une séquence détaillée des activités commerciales et des flux d’informations
nécessaires à la réalisation d’un processus.
Son objectif est de modéliser des façons d’améliorer l’efficacité, de prendre

en compte un nouveau contexte ou d’acquérir un avantage compétitif. Cette
méthode fait l’objet d’un effort de normalisation depuis quelques années déjà
et est souvent nommé légèrement différemment : Business Process Model and
Notation, dont l’acronyme reste BPMN. Elle se distingue du Business Process
Mapping, qui modélise des processus actuels pour la normalisation, la formation,
le contrôle qualité ou la conformité avec un audit. Le BPMN est aussi l’équivalent
en entreprise du Langage de modélisation unifié (UML) utilisé dans la conception
de logiciels
Événements: Il s’agit d’un élément déclencheur qui commence, modifie ou
termine un processus. Parmi les types d’événements : message, minuterie, erreur,
compensation, signal, annulation, escalade ou lien. Ils sont représentés à l’aide
12
de cercles contenant d’autres symboles qui changent en fonction du type d’événement.
On les classe en deux catégories, « receveur » ou « lanceur » selon leur fonction.
Activité: Il s’agit d’une activité ou d’une tâche particulière effectuée par
une personne ou un système. Elle est représentée par un rectangle aux angles
arrondis. Elle peut être assortie de sous-processus, de boucles, de compensations
et d’instances multiples.
Passerelle Il s’agit d’un point de décision qui peut ajuster le chemin en fonction
des conditions ou des événements. Les entrées sont représentées par des losanges.
Elles peuvent être exclusives ou inclusives, parallèles, complexes ou basées sur
des données ou événements.
Flux de séquence Indique l’ordre des activités à effectuer. Il est représenté
par une ligne droite fléchée. Il peut s’agir d’un flux conditionnel ou d’un flux
par défaut.
Figure 1.4 – exemple BPMN
13
Les avantages du workflow
À un niveau global, la notation BPMN est utile à toutes les parties prenantes
d’un processus métier, car elle permet de mieux le comprendre grâce à une
représentation visuelle accessible de toutes ses étapes. À un niveau plus détaillé,
elle est destinée aux personnes qui mettront en œuvre le processus en donnant
suffisamment de détails pour permettre son application. Elle offre un langage
standardisé et commun à tous les personnels impliqués, qu’ils soient techniques
ou non : analystes commerciaux, participants au processus, managers, développeurs
techniques, mais aussi équipes externes et consultants. Dans l’idéal, elle fait le
lien entre l’intention du processus et sa mise en œuvre en fournissant suffisamment
de détails et de visibilité sur la séquence des activités de l’entreprise.
Un schéma peut se révéler bien plus facile à comprendre qu’un texte. Il
permet de communiquer et de collaborer plus facilement pour atteindre un
processus efficace, produisant un résultat de grande qualité. Il contribue également
à la communication menant à la création des documents XML (Extensible
Markup Language) nécessaires à l’exécution de divers processus. L’une des
principales normes XML est appelée Business Process Execution Language for
Web Services ou, en version abrégée, BPEL/BEPEL4WS.
1.3.2 Gestion electronique de document

La GED, qu’est-ce que c’est ?
La Gestion Electronique des Documents (ou Gestion Electronique de l’Information
ou de Documents Existants "GEIDE") regroupe toutes les techniques permettant
de gérer les flux de documents qui entrent, sortent ou circulent au sein de
l’entreprise. Elle s’inscrit dans un processus métier de travail collaboratif, de
capitalisation et d’échanges d’informations.
La gestion électronique des documents (GED) est un outil informatique prenant
en charge directement les opérations de gestion des documents :
la création (selon des droits d’approbation définis)
l’archivage et le stockage
le classement (constitution de dossiers)
l’indexation (association d’informations ou « attributs »)
la recherche et la restitution
le contrôle (gestion des droits d’accès, verrouillages).
Les avantages d’une Gestion électronique des documents:
14
La gestion électronique des documents recèle de multiples avantages. Elle permet
de
rendre l’information disponible immédiatement pour tous les utilisateurs quel
que soit leur lieu de travail .
limiter au minimum la circulation des documents papier afin d’éviter les pertes
des données .
rassembler dans un unique dossier informatisé l’ensemble des documents disséminés
dans toute l’organisation .
éviter la multiplication des documents pour faciliter leur mise à jour ;
sécuriser le stockage et l’accès aux documents et aux dossiers. favoriser la
sauvegarde des documents sensibles.
La GED au service des démarches ISO (qualité, sécurité et/ou environnement):
Dans la cadre de la maîtrise documentaire attendue par la norme ISO 9001,
l’entreprise doit définir et respecter les modalités d’élaboration, de codification,
de diffusion, de gestion des versions périmés des documents ainsi que les modalités
de conservation (accessibilité, durée, lieux) des enregistrements.
Pour y répondre, les entreprises dressent de longues listes de documents,

qu’il est difficile de tenir à jour. La GED est en ce sens un outil plus intuitif
pour gérer ces aspects de manière automatique dès lors que les règles ont été
définies et paramétrées.
Dans le cadre du management environnemental, la GED est aussi un levier

qui permet de réduire les consommations papier .encore, grâce à la dématérialisation.
15
Figure 1.5 – Caption
1.3.3 Présentation du sujet

Notre projet intitulé "Gestion de permis de batir " sert à développer une
application web qui met en relation les clients avec la municipalité "Sousse".
Cette application permet de gérer tous les types d’autorisations de droit des
sols, d’assurer le suivi des délais et la dématérialisation des pièces. Toutes les
demandes reçues à la municipalité passe par un enchaînement des étapes afin
de rendre la décision finale aux clients, donc on doit utiliser la méthode de
gestion des processus métier (BPM) afin d’automatiser le système, connecter
les agents, suivi de l’activité. Je simplifie l’idée: le client dépose la demande en
ligne. Tout d’abord Il doit remplir le formulaire par les informations nécessaires
telles que (le nom, prénom, CIN...) et il dépose les documents nécessaires en
formats PDF. Puis après un délai fixé il doit, soit déposé le dossier en papier
directement à la municipalité soit envoyé par poste. Dès que le dossier est reçu,
l’agent de vérification doit vérifier la conformité de dossier. Si le dossier est
accepté la demande " a complter".
16
Figure 1.6 – Structure descriptif du projet
1.4 Cahier de charge

1.4.1 Étude de l’existant
L’étude de l’existant permet de déterminer les points faibles et les points forts
d’un produit actuel pour pouvoir déterminer les besoins de l’administration, en
vue d’en prendre en considération lors de la conception et la réalisation de
notre application. Dans cette section, nous présentons une analyse de quelques
exemples d’applications au sein de la municipalité. Ensuite, nous formulerons
une solution de la problématique.
1.4.2 L’application de la municipalité :

L’application disponible dans la municipalité est une application basée sur
l’interaction humaine, en effet, après l’acceptation des dossiers de demande de
permis de bâtir par les citoyens, l’agent récapitule les coordonnées trouvées dans
le dossier et faire la saisie de données au formulaire de l’application. les données
saisies seront enregistrées dans la base de données, ce qui permet aux agents de
la municipalité de consulter une demande, de vérifier son existence, ainsi que
de faire la recherche selon le nom de demandeur de service ou selon son numéro
de carte d’identité.Cependant, certains problèmes peuvent rencontrer l’agent
17
lors de l’utilisation de cette application, en fait : les interfaces ne sont pas assez
visibles et claires ; Le manque de fiabilité de quelques fonctions à savoir la
recherche de données. Ainsi, l’application ne permet pas aux agents d’attacher
les documents relatifs à chaque demande et exige la présence d’un dossier en
papier. En plus, l’agent et même les citoyens sont incapables de faire le suivi
d’avancement de traitement des dossiers et la consultation de décision finale.
En outre, l’application ne permet pas aux agents de travailler en collaboration,
en fait, les tâches de traitement de chaque dossier nécessitent le déplacement à
plusieurs bureaux et sur plusieurs étapes d’où viennent la perte de temps et le
retard de décision
Voici quelques figures du l’application utilisée :
Figure 1.7 – Interface de l’application de municipalité
18
Figure 1.8 – Interface de l’application de municipalité
1.4.3 l’application de R’ads

R’ads est une solution informatique de la société française "SIRAP" Créée en
1979, spécialiste del’informatique de gestion à destination des services techniques,
cette application permet de gérer d’une manière ouverte tous les types de
dossiers d’urbanisme (Permis de construire, de Démolir, Déclarations préalables,
Certificats d’Urbanisme, permis d’Aménager, Renseignements d’Urbanisme, DIA. . . )
pour toutes les parties prenantes dans un dossier d’autorisation du Droit des
Sols (service instructeur, demandeur, mairie, services consultés....
R’ads répond aux évolutions des obligations réglementaires en vigueur mais
elle manque de convivialité, a eu une mauvaise interface utilisateur, en plus
l’application n’est pas adaptable au processus de travail de notre pays.
Voici une interface de l’application :
19
Figure 1.9 – Interface de l’application de R’ads
1.5 Critique de l’existant:

Dans cette partie, nous essayons de déceler les insuffisances de la situation
existante, nous présentons ses défailliances pour arriver enfin à proposer une
solution.
À l’échelle nationale, nous avons constaté que l’utilisation de systèmes d’informations
présente certaines limites dans le domaine d’urbanisme ce qui pose beaucoup
des problèmes au niveau de gestion des demandes
Afin de rendre la décision finale au client, chaque demande passe par plusieurs
étapes administratives. En effet, la méthodologie existante dans la municipalité
pose beaucoup de problèmes, parmi lesquels nous pouvons citer :
Problèmes vis à vis des données clients : les sources d’erreurs sont
multiples au niveau des traitements des dossiers des clients telless que les fautes
de saisie, des erreurs de manipulations de demandes
possibilité de pertes de données : les sauvegardes des données en masse
manuellement peuvent entraîner des pertes
Problèmes de corruption : la corruption est un problème majeur qui menace
les développements de notre pays, réduire la qualité des services rendus aux
municipalités
20
Problèmes administratifs: généralement l’administration tunisienne est lourde,
peu efficace c’est pourquoi on trouve plein de problèmes vis-à-vis des clients
problémes de temps: l’absence de coordination entre les agents et les réunions
inutiles au sein de la municipalité engendre une perte de temps considérable.
problémes d’organisations: la mauvaise circulation de l’information entre
les acteurs peut entraîner des obstacles pour l’étude d’une demande et des
problèmes d’organisation de travail
1.6 Spécification des besoins:

Nous avons en général recouru à développer une application permettant
d’informatiser diverses fonctionnalités l’application doit être en ligne et accessible
à plusieurs utilisateurs à la fois, ainsi que la mise à jour des données qui doit
être à temps réel. Il doit être aussi facile aux utilisateurs, de bien consulter
et de déposer à distance tout type de demandes Désormais, on peut passer
à la présentation de notre projet en matière des fonctionnalités. Alors, nous
présentons les spécifications fonctionnelles et non fonctionnelles de notre application
1.6.1 Les besoins fonctionnels :

Notre application web permet de Gérer les demandes de permis de bâtir à
partir du dépôt de dossier jusqu’à la prise de décision . Elle doit donc répondre
aux besoins suivants :
Déposer demande et le suinvi en ligne
Le travail en callobaration entre les agents de la municipalité
Prendre décision et le rendre aux cityones en utilisant le systéme
Inviter l’architecte aux commission par mail
Consrver l’historique de chaque demande
les statistiques
la gestion des utilisateurs
l’ajout d’un resulat de controle et de etude sur le systéme
la recherche muliticrétere
Utilisation da la signature electronique
21
1.6.2 les besoins non fonctionnels
Interface graphique et ergonomie : Interface simple, moderne, bien
structurée et conviviale pour favoriser une prise en main rapide des fonctionnalités
de l’application.
Responsive : Une application responsive est devenue une approche de conception
Web incontournable dans tous les projets de développement, qui vise l’élaboration
de sites orant une expérience de lecture et de navigation optimales pour l’utilisateur
quelle que soit sa gamme d’appareils (téléphones mobiles, tablettes, liseuses,
moniteurs d’ordinateur de bureau, etc.).
Sécurité : Les utilisateurs inscrits ont tous un identifiant unique qui permet
de les identifier dans le middle office et le back office.
Les données d’authentification doivent être cryptées dans la base de données.
Performance et disponibilité : L’application doit être hautement disponible
et fluide afin de garantir une meilleure qualité de service. Le code de l’application
doit être bien lisible, compréhensible et bien documenté pour pouvoir la maintenir
rapidement. L’application doit être évolutive pour répondre aux changements
des besoins.
Compatibilité : Certaines fonctionnalités dans les pages de l’application middle
office ne sont pas compatibles avec certaines versions de navigateurs antérieurs.
Utiliser une version récente de navigateur et mettre à jour la version de votre
navigateur pour assurer la compatibilité.
Maintenabilité et Extensibilité : afin d’encourager la réutilisabilité du code
en tout ou parties dans d’autres applications, et la facilité de sa maintenance ,
il est requis que le code source soit lisible et compréhensible; pour ceci il faut
tenir compte de sa documentation détaillée
Portabilité : L’application doit pouvoir s’exécuter sous différents environnements
1.7 Solution proposée:

L’étude de l’existant nous a permis de dégager les objectifs de notre première
aplicatiion en Tunisie qui regroupe toutes les fonctionnalités. Notre solution
peut:
- Gérer les dossiers d’urbanisme d’une manière professionnelle.
- Numériser l’archive municipale.
- Réduire les délais d’attente et donc les coûts.
22
- Répondre plus facilement aux demandes des clients.
- l’application doit être rapide et offre la possibilité de collaborer le travail entre
le staff administratif.
1.8 Architecture envisagée :

Dans l’architecture à 3 niveaux (appelée Notre application fait recours à
architecture 3-tier), il existe un niveau intermédiaire, c’est-à-dire que l’on a
généralement une architecture partagée entre:
Le client:le demandeur de ressources
Le serveur d’application: (appelé aussi middleware) le serveur chargé de
fournir la ressource mais faisant appel à un autre serveur
Le serveur secondaire(généralement un serveur de base de données), fournissant
un service au premier serveur
1.9 Planning des tâches :

Diagramme de Gantt:
Le diagramme de Gantt, couramment utilisé en gestion de projet, est l’un des
outils les plus efficaces pour représenter visuellement l’état d’avancement des
différentes activités (tâches) qui constituent un projet. La colonne de gauche du
diagramme énumère toutes les tâches à effectuer, tandis que la ligne d’en-tête
23
représente les unités de temps les plus adaptées au projet (jours, semaines, mois
etc.). Chaque tâche est matérialisée par une barre horizontale, dont la position
et la longueur représentent la date de début, la durée et la date de fin. Ce
diagramme permet donc de visualiser d’un seul coup d’œil :
- Les différentes tâches à envisager.
- La date de début et la date de fin de chaque tâche.
- La durée escomptée de chaque tâche.
- Le chevauchement éventuel des tâches, et la durée de ce chevauchement.
- La date de début et la date de fin du projet dans son ensemble.
Figure 1.11 – Diagramme de Gantt
1.10 Conclusion:
Cette étude de l’existant nous a permis de présenter le cadre de projet,
de reconnaitre la méthodologie à adopter et les limites déjà existantes afin de
faciliter le processus de délivrance des permis(construire ,démolir , renouvellement...)
et d’impliquer tous les acteurs en réalisant un logiciel qui répond aux besoins
spécifiques .
Le chapitre suivant sera consacré pour détailler cette étude ainsi que spécifier
les besoins.
24
Chapitre 2: Elaboration
1.Introduction
2. Méthode et outils de modélisation choisis
2.1 Méthode de modélisation
2.2 laungage de conception
2.3 Outil de modélisation (MS Visio)
3. Modèle métier (Diagramme de Cas d’utilisation)
3.1 Diagramme de cas d’utilisation
3.2 Identification des acteurs
3.3 Diagramme processus métier
4 . Spécification des cas d’utilisation
5.Conclusion
25
Chapitre 2
Elaboration
2.1 Introduction
La phase de spécification des besoins est une étape primordiale pour réaliser
une application avec succès.
Dans ce chapitre, nous identifions d’abord les différents acteurs impliqués dans
notre application ainsi que leurs besoins fonctionnels représentés par les cas
d’utilisations. Ensuite, nous spécifions et raffinons les cas d’utilisation. Enfin,
nous présentons les besoins non fonctionnels à prendre en considération dans la
phase de développement.
2.2 Méthode et outils de modélisation choisis

2.2.1 Méthode de modélisation choisie:
On a choisi comme méthode de développment le processus unifié (PU) qui
est un processus de développement logiciel itératif, centré sur l’architecture,
Piloté par des cas d’utilisation et orienté vers la diminution des risques.
C’est un patron de processus pouvant être adaptée à une large classe de systèmes
logiciels, à différents domaines d’application, à différents types d’entreprises, à
différents niveaux de compétences et à différentes tailles de l’entreprise
Le processus unifié répond aux exigences fondamentales suivantes :
- être guidée par les besoins des utilisateurs
- être centrée sur l’architecture logicielle
- être itérative et incrémentale les phases d’un processus de développement sont
des états de celui-ci à un instant T. Le cycle de développement du processus
26
Unifié organise les tâches et les itérations en quatre phases
- Analyse des besoins: Cette phase porte essentiellement sur les besoins principaux
(du point de vue de l’utilisateur), l’architecture générale du système, les risques
majeurs, les délais et les coûts
- Elaboration : L’élaboration reprend les éléments de la phase d’analyse des
besoins et les précise pour arriver à une spécification détaillée de la solution à
mettre en oeuvre.
L’élaboration permet de préciser la plupart des cas d’utilisation, de concevoir
l’architecture du système et surtout de déterminer l’architecture de référence.
Au terme de cette phase, les chefs de projet doivent être en mesure de prévoir
les activités et d’estimer les ressources nécessaires à l’achèvement du projet.
-Construction : La construction est le moment où l’on construit le produit.
L’architecture de référence se métamorphose en produit complet.
Le produit contient tous les cas d’utilisation que les chefs de projet, en accord
avec les utilisateurs ont décidé de mettre au point pour cette version.
-Transition : Le produit est en version bêta. Un groupe d’utilisateurs essaye le
produit et détecte les anomalies et défauts.
Cette phase suppose des activités comme la formation des utilisateurs clients, la
mise en oeuvre d’un service d’assistance et la correction des anomalies constatées.
Figure 2.1 – les phases de processus unifié
2.2.2 Choix de la laungage de conception :

UML est un langage visuel qui fournit une multitude de représentations
graphiques appelés diagrammes qui sont des représentations graphiques d’un
ou plusieurs éléments du système et ce selon un aspect particulier du système;
il s’agit de vue.
En effet, une vue est une collection de diagrammes décrivant les aspects similaires
d’un projet.
27
UML aperçoit un système logiciel à développer selon trois vues à savoir : la vue
fonctionnelle,la vue statique et la vue dynamique.
En effet, une vue est une collection de diagrammes décrivant les aspects similaires
d’un projet.
UML aperçoit un système logiciel à développer selon trois vues à savoir :
la vue fonctionnelle, la vue statique et la vue dynamique.
En utilisant UML, nous nous servons donc d’une modélisation de très haut
niveau indépendamment des langages et des environnements, et garantirons la
réalisation d’objectifs réputés que visent assurée l’approche objet, à savoir :
— La décomposition du processus de développement.
— La prise en compte de l’évolution de l’analyse et du développement.
— La compréhension de représentations abstraites complexes.
— La factorisation du code, son organisation et sa réutilisabilité dans
d’autres applications.
— La création d’un formalisme pour la conception d’un système logiciel.
— L’expression visuelle des solutions proposés.
— Limiter les ambiguïtés et les incompréhensions.
— Un gain de précision et de stabilité.
Dans sa version 2.3, UML s’appuie sur 14 diagrammes, chacun modélisant sous
un aspect particulier le système désiré
Figure 2.2 – Logo d’UML
28
2.2.3 Outil de modélisation (MS Visio) :
Toute méthode de développement de logiciels est mieux épaulée par un outil.
Notre conception fait l’usage de l’outil MS Visio.
Qu’est-ce que Visio ? :
Visio, officiellement "Microsoft Office Visio", est une application de la suite

Microsoft Office System, cette application "bureautique" fait partie de la gamme
de logiciel de "schématique" ou de "diagrammes et synopsis", son domaine
d’application ou d’utilisation est donc la construction de schémas de modélisation;
d’ailleurs, elle couvre un spectre assez large puisqu’elle permet notamment de
réaliser des :
— Plans d’architecture et plans d’occupation d’espace intérieur d’habitation
— Modèles d’architecture logiciel (UML, ....) et modèles de base de données
— Schémas électroniques et dessins industriels (ou d’ingénierie)
— Diagrammes de Gantt et réseaux PERT
— Diagrammes de flux fonctionnel simple et croisé
— Diagrammes de flux fonctionnel simple et croisé
— Diagrammes TQM, IDEFO ou Ishikawa (causes à effets)
— Et bien d’autres encore.
Ses points forts:
Parmi les points forts de Visio nous citerons que :

C’est un logiciel de dessin vectoriel, les schémas ainsi créés peuvent être
redimensionnés sans perdre au niveau de la qualité et détail du dessin.
— Il intègre des fonctions de liens natives entre les formes ainsi il suffit
d’approcher un connecteur d’une forme pour que celui-ci détecte les points
de connexion de la forme est s’y attache
— Il est orienté objet à destination de l’utilisateur final ainsi ce dernier
pourra à travers une interface unique définir ou redéfinir toutes les propriétés
connues de chaque forme.
— Il est généraliste et peut être complété avec des extensions qui apportent
de nouveaux modèles. Ces extensions peuvent être développées par la
communauté. Dans sa version 2007 édition Professionnel, il permet aux
utilisateurs de relier facilement leurs diagrammes à un grand nombre de
sources de données et d’afficher les informations recueillies graphiquement.
29
Figure 2.3 – Logo de MS visio
2.3 Modèle métier (Diagramme de Cas d’utilisation) :

2.3.1 Diagramme de cas d’utilisation:
L’étape de saisie des besoins est une étape cruciale, Permettre une meilleure
compréhension du système, afin d’identifier les fonctionnalités principales du
système. La saisie de ces besoins est assurée par les cas d’utilisations, représentés
dans des diagrammes, qui permettent de mettre en évidence les fonctionnalités
complètes du système du point de vue de ses utilisateurs.
Définition:
Les diagrammes de cas d’utilisation sont des diagrammes UML utilisés pour
donner une vision globale du comportement fonctionnel d’un système logiciel.
Ils sont utiles pour des présentations auprès de la direction ou des acteurs d’un
projet, mais pour le développement, les cas d’utilisation sont plus appropriés.
Un cas d’utilisation représente une unité discrète d’interaction entre un utilisateur
(humain ou machine) et un système. Il est une unité significative de travail. Dans
un diagramme de cas d’utilisation, les utilisateurs sont appelés acteurs (actors),
ils interagissent avec les cas d’utilisation (use cases).
30
Éléments de base d’un diagramme de cas d’utilisation
— Acteur : Un acteur est un rôle joué par une personne externe, un processus
ou une chose qui interagit avec un système.
— Cas d’utilisation : un cas d’utilisation représente une fonctionnalité offerte
par le système, sans imposer son mode de réalisation.
— Relation : une relation d’association représente un canal de communication
reliant un acteur à un cas d’utilisation.
— Inclusion : La relation d’inclusion entre un cas d’utilisation A et un autre B,
signifie que le cas A ne peut avoir lieu qu’après exécution de B, e.g. la réalisation
de A exige la réalisation B.
— Extension : La relation d’extension entre deux cas d’utilisation indique que
le cas étendue peut faire appel à l’autre. Supposons qu’un cas d’utilisation A
étend B, ceci signifie que l’exécution de B peut entrainer l’exécution de A; on
parle alors d’une dépendance facultative.
— Généralisation : La généralisation est un type de relation entre acteurs et
même des cas d’utilisation. Il s’agit d’une migration de comportements entre
acteurs(ou cas d’utilisation). Par exemple, un acteur A est une généralisation
d’un autre B, dé- signe que B est un aspect particulier; qu’en plus des comportements
de A, l’acteur B possède d’autres qui s’y ajoutent
2.3.2 Identification des acteurs:

chef service: est un agent chargé d’assurer sur le terrain la direction, Il
a la possibilité de consulter les statistiques, consulter et signer les demandes
.d’autre part le chef service à la possibilité d’exporter un fichier pour l’utiliser
au système d’informations géographiques
chef commission: il a la possibilité de consulter les dossiers d’urbanisme pour
avoir la décision afin de signer avant chaque réponse au client
Agent de controle: il a la possibilité de consulter tous les dossiers d’urbanisme
pour Effectuer un contrôle et ajouter un procès-verbal sur les systèmes pour
chaque demande
Agent Technique:il est le responsable d’étudier, décider, d’ajouter sur les
systèmes un procès-verbal et de signer chaque décision pour certaines demandes
d’urbanisme
Agent d’etude :c’est le responsable qui est spécialisé aux études de dossier
de permis de bâtir .il a la possibilité d’ajouter un procès-verbal pour chaque
31
demande et de signer
Agent de Verfication:Il l’a possibilité de consulter les demandes et la responsabilité
de vérifier la conformité des documents déposés pour chaque demande .
Citoyen: il a la possibilité de déposer une ou plusieurs demande et le suivre
en ligne.
Adminstrateur: : l’administrateur contrôle directement l’application. Il est
le responsable de la gestion des utilisateurs, back offices , les demandes, et la
gestion du contenu de l’application.
2.3.3 Diagramme processus métier :

Nous commencerons par présenter le diagramme de cas d’utilisation global.
Ensuite, nous présenterons chaque rafnement, en spécifant les acteurs ainsi que
les diagrammes de cas d’utilisation détaillés.
32
Figure 2.4 – cas d’utilisation global
2.4 Spécification des cas d’utilisation :

Chaque processus est un ensemble des cas d’utilisations. Dans cette section,
nous procédons à la traçabilité entre le diagramme de processus métier et les
diagrammes de cas d’utilisations du modèle métier
33
2.4.1 CU : S’authentifier
Nom du cas S’authentifier

d’utilisation
Acteurs Administrateur, Chef service, Chef
commission,Agent technique, Agent de
vérfication ,Agent d’etude ,Agent de
controle
Description brève L’acteur s’authentifie en utilisant son
adresse e-mail et son mot de passe
Pré Condition Opération d’authentification demandée
par l’acteur.
Post Condition Acteur authentifié
Scénario de base
1. L’acteur saisit son e-mail et son mot de
passe.
2. Le système vérifie les données de
l’acteur.
3. Le système affiche un message de
succés d’authentification.
4. Le système affiche l’interface d’accueil
propre à l’acteur
Scénario d’exception
2. E-mail ou mot de passe non valide :
- Le système affiche un message d’erreur.
- Retour à l’étape 1 du scénario de base.
Table 2.1 – Scénario de cas "S’authentifier"
34
2.4.2 CU : Gérer utilisateur :
Figure 2.5 – Raffinement de cas Gérer utilisateur
Consulter les utilisateur
nom de cas d’utilisation Consulter les utilisateurs

Acteurs Adminstrateur
Description brève l’adminstrateur a la possibilité de consulter
les utilisateurs
Pré Condition
L’administrateur doit être authentifié
- Opération de consultation choisie
Post Condition - Consultation effectuée
Scénario de base
1. «include» s’authentifier.
2. L’adminsatrateur demande de consulter
la liste d’utilisateurs.
Table 2.2 – Scénario de cas:"consulter liste utilisatuers"
35
Modifier Utilisateur :
nom de cas d’utilisation Modifier utilisateur

Description brève L’adminstrateurr a la possibilité de modifier
les données d’un utilisateur
Pré Condition L’administrateur doit être authentifié
Opération de modification choisit
Post Condition les donnée d’un utilisateur modifié.
Scénario de base
1. « include » s’authentifier.
2. « include » consulter liste d’utilisateur.
3. L’administrateur demande la
modification d’un utilisateur
4. Le système demande la confirmation de
l’opération.
5.l’adminstratue valide la modification..
6. Le système vérifie la modification .
7. Le système enregistre la modification.
8.Le système affiche un message de
«Modification effectuée»
Scénario d’exception 5. Modification non valide
- Le système affiche un message d’erreur
- Retour à l’étape 2 de scénario de base.
Table 2.3 – Scénario de cas:"Modifier utilisateur"
36
Suprimer utilisateur:
nom de cas d’utilisation Suprimer utilisateur

Description brève L’administrateur choisit l’utilisateur et
selectionner l’icone "supprimer "
Pré Condition L’administrateur doit être authentifié
Opération de suppertion choisit
Post Condition Utilisateur suprimé.
Scénario de base
2. « include » consulter liste d’utilisateur.
3. L’administrateur demande la supression
d’un utilisateur
4. Le système demande la confirmation de
l’opération.
5. L’acteur valide l’opération.
6. Le système supprime les informations de
l’utilisateur de la base de données .
7. Le système dirige l’adminstrateur vers la
page d’accueil du site.
Scénario d’exception L’adminstrateur annule la suppression :
- Retour à l’étape 3 de scénario de base
Table 2.4 – Scénario de cas:"Suprimer utilisatuer"
37
2.4.3 CU :Gerer Demande :
Figure 2.6 – Raffinement de cas : Gérer demande(Admin)
Figure 2.7 – Raffinement de cas : Gérer demande
38
nom de cas d’utilisation Déposer Demande
Acteurs Client
Description brève .
Pré Condition demande choisit
Post Condition Demande deposé.
Scénario de base
1. "include " Déposer demande
2. Le client introduit sont coordonnée et
déposer les fichiers nécissaire
3. Le client valide les données de la
demande .
4. Le système vérifie la saisie et les fichiers
déposés
5. Le système enregistre les données de
demande
"Succès"
Scénario d’exception Le client annule l’envoi :
- Retour à l’étape 3 de scénario de base
Table 2.5 – Scénario de cas:"déposer demande "
39
2.4.4
nom de cas d’utilisation Créer Compte

Acteurs Client
Description brève Le client demande de Créer une Compte
Pré Condition ...
Post Condition Client authentifié.
Scénario de base
1. L’utilisateur clique sur créer compte.
2. Le système affiche le formulaire
d’inscription.
3. L’utilisateur saisit les données demandées
puis clique Enregistré
4. Le système crée le compte et affiche un
message de succès d’opération.
Scénario d’exception 3 Le Compte est déjà existant, dance ce cas
l’utilisateur est averti.
Table 2.6 – Scénario de cas:"Créer Compte"
40
nom de cas d’utilisation Modifier Compte
Acteurs Client
Description brève le client a la possibilité de modifier les
données de son compte.
Pré Condition
- Acteur authentifié.
- Opération de modification choisie.
Post Condition - Compte modifié
Scénario de base
1. «include» s’authentifier.
2. «include» consulter compte.
3. L’acteur modifie les données de son
compte.
4. L’acteur valide la modification.
5. Le système vérifie la modification.
6. Le système enregistre la modification.
«Modification effectuée»
Scénario d’exception 5. Modification non valide - Le système

affiche un message d’erreur «champs
manquants ou incohérents».
Table 2.7 – Scénario de cas:"Modifier compte"
41
nom de cas d’utilisation Consulter Demandes
Acteurs Adminstrateur , Chef service , Chef
commission ,Agent de vérification ,Agent
Etude ,Agent Technique ,Agent controle,
président
Description brève L’acteur demande de consulter les demades
Pré Condition L’acteur doit être authentifié le type de
demande choisit
Post Condition demande consultée .
Scénario de base
2. « include » consulter liste dde demande .
3. L’acteur choisit le type de demande
4. L’acteur sélectionne une demande à
consulter .
5. Le système fournit les doucments.
Scénario d’exception 3 La liste des plantes est vide :
Table 2.8 – Scénario de cas:"Consulter Demande "
nom de cas d’utilisation Ajouter PV

Acteurs Admnstrateur ,Agent Etude ,Agent controle
Description brève L’acteur demande de consulter les demades
Pré Condition L’acteur doit être authentifié le type de
demande choisit
Post Condition demande consultée .
Scénario de base
2. « include » consulter liste de demande .
3. L’acteur choisit le type de demande
4. L’acteur sélectionne une demande à
consulter .
5. Le système fournit les doucments.
Scénario d’exception 3 La liste des plantes est vide :
Table 2.9 – Scénario de cas:"Ajouter PV"
42
Figure 2.8
43
2.4.5 Identification des cas d’utilisation du système:
Dans cette partie, nous recensons les principales fonctionnalités offertes par
le système, tout en les associant aux acteurs qui devront en bénéficier.
44
Acteurs du Admin Chef Chef Agent Agent Agent Président Agent Citoyen
système service commission contrôle vérification technique Etude
Cas
d’utilisations
Ajouter utilisateur ✔
Modifier utilisateur ✔
Supprimer utilisateur ✔
Consulter les ✔
utilisateurs
Déposer demande ✔
Modifier demande ✔
Consulter les demandes ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Suivre demande ✔
Créer compte ✔
Modifier compte ✔
S’authentifier ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Ajouter PV ✔ ✔ ✔
Exporter fichier ✔ ✔
Consulter statistique ✔ ✔
Signer ✔ ✔ ✔ ✔ ✔ ✔ ✔
Imprimer PV ✔ ✔ ✔ ✔
Vérifier demande ✔ ✔
Prendre décision ✔ ✔
45
2.4.6 Diagramme sequence systéme :
46
47
48
2.5 conclusion:
Dans ce deuxième chapitre nous avons spécifié les acteurs et présenté les
besoins fonctionnels et non fonctionnels de notre application, nous avons ensuite
présenté les diffé- rents diagrammes de cas d’utilisation ayant servi a la modélisation
des besoins aussi la spécification des cas d’utilisation. Le chapitre suivant sera
réservé à la conception de ces cas d’utilisation.
49
Chapitre 3: Analyse et conception
1.Introduction
2.Analyse
2.1 Modèle d’analyse (Diagramme de traçabilité et
diagramme de classe d’analyse)
2.2 Modèle du domaine (Diagramme de Classe)
3.3.Conception
3.1 Diagrammes de séquence
3.2 Diagramme de déploiemant
4.Conclusion
50
Chapitre 3
Analyse et conception
3.1 Introduction
Ce chapitre se consacre, en premier lieu, à l’analyse des besoins décrits dans le
chapitre précédent, en les raffinant et en les structurant. L’objectif est d’accéder
à une compréhension plus aiguë des besoins et des exigences et d’en livrer
une description facile à entretenir, favorisant la structuration de l’ensemble du
système, y compris son architecture.
3.2 Analyse
3.2.1 Modèle d’analyse (Diagramme de traçabilité et diagramme
de classe d’analyse)
Le modèle d’analyse doit fournir une approche conceptuelle du problème.
Le but de ce modèle est de définir une structure robuste et extensible qui nous
servira de base pour la construction du système. Chaque type d’objet (entité,
contrôle et interface) apporte sa propre contribution à ces deux qualités. [1]
— Objets frontières : objets d’interface (interface
graphique, interface vers un autre logiciel).
— Objets contrôles : jouent un rôle de collaboration
avec les autres objets. Portent la responsabilité de la
réalisation des UC.
— Objets entités : objets métiers auxquels sont associés
des données. [2]
51
Analyse du cas d’utilisation « Gérer les Utilisateurs »:
Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas

d’utilisation « Gérer les Utilisateurs » :
Figure 3.1 – Traçabilité du cas d’utilisation « Gérer les Utilisateurs »
Diagramme de classe d’analyse du cas d’utilisation « Gérer les Utilisateurs

»:
52
IUListeUtilisateur : Cette interface permet à l’administrateur de consulter la
liste des utilisateurs et d’effectuer une recherche rapide. C’est à partir d’elle que
l’admin peut passer à la page d’ajout et de modification.
IUProfilUtilisateur : Cette interface permet à l’administrateur de consulter

le profil de l’utilisateur où on peut modifier les informations de l’utilisateur.
IUModifierUtilisateur : Cette interface permet à l’admin de modifier les informations

de l’utilisateur choisi dans la liste.
IUAjouterUtilisateur : Cette interface permet à l’ administrateur d’ajouter

un nouvel utilisateur.
Pour réaliser toutes ces opérations, le système se dote du contrôleur Utilisateur

permettant d’exécuter les fonctions. En effet, ce contrôleur extrait les données
nécessaires de la classe Utilisateur contenant les informations de tous les Utilisateurs
en relation avec la classe Utilisateur.
53
Analyse du cas d’utilisation « Gérer Demande: Client »:

d’utilisation « Gérer Demande: Client » :
Figure 3.2 – Traçabilité du cas d’utilisation « Gérer Demande: Client »
Diagramme de classe d’analyse du cas d’utilisation « Gérer Demande: Client

»:
54
Figure 3.3 – Diagramme de classe d’analyse du cas « Gérer Demande: Client »
55
Description :
IUConnexion : Cette interface permet au client de se connecter à
son compte en écrivant son e-mail et son mot de passe s’il a déja un
compte, sinon de passer à la page d’inscription.
IUCréerCompte : Cette interface permet au client de créer un
nouveau compte.
IUCompteClient : Cette interface permet au client de modifier les
informations de son compte et de consulter la liste de ses demandes
déposées. C’est à partir d’elle que le client peut passer à la page de
depôt d’une nouvelle demande et de page de notifications.
IUDeposerDemande : Cette interface permet au client de deposer
une nouvelle demaande.
IUNotifications : Cette interface permet au client de visualiser les
notifications qu’il a reçues.
Pour réaliser toutes ces opérations, le système se dote du contrôleur

Client et contrôleur Demande permettants d’exécuter les fonctions.
En effet, ces contrôleurs extraient les données nécessaires des classes
Client, Demande et Fichier.
Analyse du cas d’utilisation « Vérifier Demande »:

d’utilisation « Vérifier Demande » :
56
Figure 3.4 – Traçabilité du cas d’utilisation « Vérifier Demande »
Diagramme de classe d’analyse du cas d’utilisation « Vérifier Demande » :
Figure 3.5 – Diagramme de classe d’analyse du cas « Vérifier Demande »
57
Description :
IUListeDemandes : Cette interface permet à l’agent de vérification
de consulter la liste des demandes à vérifier. C’est à partir d’elle que
l’agent de vérification peut passer à la page de vérification et la page
de profil du client.
IUVerification : Cette interface permet à l’agent de vérification de
vérifier les fichiers de la demande reçue du client puis de l’accepter ou
de l’a réfuser.
IUDemande : Cette interface permet à l’agent de vérification de
consulter la demande reçue du client.
IUProfilClient : Cette interface permet à l’agent de vérification de
consulter le profil d’un client.

Demande et contrôleur Client permettants d’exécuter les fonctions.
En effet, ces contrôleurs extraient les données nécessaires des classes
Demande, Fichier et Client.
Analyse du cas d’utilisation « Ajouter un PV(Procès Verbal)

d’utilisation « Ajouter un PV » :
58
Figure 3.6 – Traçabilité du cas d’utilisation « Ajouter un PV »
Diagramme de classe d’analyse du cas d’utilisation « Ajouter un PV » :
59
Figure 3.7 – Diagramme de classe d’analyse du cas « Ajouter un PV »
Description :
IUListeDemandes : Cette interface permet à l’agent de contrôle de
consulter la liste des demandes. C’est à partir d’elle que l’agent de
contrôle peut passer à la page d’ajout d’un procès verbal et la page
consultation de demande.
IUPV : Cette interface permet à l’agent de contrôle d’ajouter un
procès verbal à la demande du client après avoir faire le contrôle, de
signer le procès verbal et de l’imprimer.
IUDemande : Cette interface permet à l’agent de vérification de
consulter la demande reçue du client.

Demande et contrôleur PV permettants d’exécuter les fonctions. En
effet, ces contrôleurs extraient les données nécessaires des classes
Demande et PV.
60
3.2.2 Modèle du domaine (Diagramme de Classe)
Définition
Le diagramme de classes est considéré comme le plus important de la modélisation

orientée objet, il est le seul obligatoire lors d’une telle modélisation.
Alors que le diagramme de cas d’utilisation montre un système du point de vue

des acteurs, le diagramme de classes en montre la structure interne. Il permet
de fournir une représentation abstraite des objets du système qui vont interagir
pour réaliser les cas d’utilisation. Il est important de noter qu’un même objet
peut très bien intervenir dans la réalisation de plusieurs cas d’utilisation. Les
cas d’utilisation ne réalisent donc pas une partition des classes du diagramme
de classes. Un diagramme de classes n’est donc pas adapté (sauf cas particulier)
pour détailler, décomposer, ou illustrer la réalisation d’un cas d’utilisation
particulier.
Il s’agit d’une vue statique, car on ne tient pas compte du facteur temporel
dans le comportement du système. Le diagramme de classes modélise les concepts
du domaine d’application ainsi que les concepts internes créés de toutes pièces
dans le cadre de l’implémentation d’une application. Chaque langage de Programmation
orienté objet donne un moyen spécifique d’implémenter le paradigme objet
(pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes
permet de modéliser les classes du système et leurs relations indépendamment
d’un langage de programmation particulier.
Les principaux éléments de cette vue statique sont les classes et leurs relations
: association, généralisation et plusieurs types de dépendances, telles que la
réalisation et l’utilisation. [3]
Présentation de diagramme de classes
Ci-dessous le diagramme de classe de notre application :
Identification des associations
61
3.3 Conception
3.3.1 Diagrammes de séquence
Définition
Le diagramme de séquence est la représentation graphique des interactions

entre les acteurs et le système selon un ordre chronologique dans la formulation
UML. Il peut être utilisé pour affiner le comportement ou la description d’un
cas d’utilisation.
Les éléments associés pour la modélisation d’un diagramme de séquences

sont :
— Les objets
— Les messages entre les objets
Le diagramme de séquence vous permet de voir facilement comment les

tâches sont distribuées entre les différents composants. [4]
Le modèle utilisé : MVC (Modèle Vue Contrôleur)
Le Modèle-Vue-Contrôleur (en abrégé MVC, de l’anglais Model-View-Controller)

est une architecture et une méthode de conception qui organise la conception
d’un site web. Cette organisation divise le travail (programmation) en un modèle
(modèle de données, script de référence), une vue (présentation, interface utilisateur,
HTML) et un contrôleur (logique de contrôle, programmation central, validation).
[5]
Le Modèle
Le modèle représente le comportement de l’application : traitements des
données, interactions avec la base de données, etc. Il assure la gestion de ces
données et garantit leur intégrité.
La vue
La vue correspond à l’interface avec laquelle l’utilisateur interagit. Sa première
tâche est de présenter les résultats renvoyés par le contrôleur. Sa seconde tâche
est de recevoir toutes les actions de l’utilisateur (clic de souris, sélection d’une
entrée, boutons. . . ). Ces différents événements sont envoyés au contrôleur. La
62
vue n’effectue aucun traitement, elle se contente d’afficher les résultats des
traitements.
Le Contrôleur
Le contrôleur prend en charge la gestion des événements de synchronisation
pour mettre à jour la vue et la base de données. Il reçoit tous les événements
de l’utilisateur et enclenche les actions à effectuer.
Figure 3.8 – Méthode MVC [6]
Présentation des diagrammes de séquences
Diagramme de Séquence « S’authentifier »
63
Figure 3.9 – Diagramme de Séquence « Authentification »
Description
Action de l’acteur Réaction du Système
1. L’utilisateur saisit son

e-mail et son mot de passe
2. Vérifie la validité des champs saisis.
3. Vérifie l’existence de l’utilisateur
dans la table «Utilisateur» de la BD.
4. Ouvre l’espace du travail
correspondant à l’utilisateur.
64
Enchainement alternatif
1. Si l’utilisateur oublie de remplir un champ :

• Le système affiche un message indiquant qu’il doit retaper
le saisi de
son e-mail et son mot de passe.
• Le scénario reprend à partir du 1
2. Si le statut retourné de la base de données indique que
l’utilisateur n’existe pas:
• L’utilisateur sera redirigé vers la page d’authentification
avec un
message d’erreur.
• Le scénario reprend du 1 .
NB : Le même scénario pour l’administrateur.

Diagramme de Séquence « Ajouter Utilisateur »
Figure 3.10 – Diagramme de Séquence « Ajouter Utilisateur »
Description
65
1. L’administrateur clique
sur le bouton ajouter pour
demander le formulaire
d’ajout.
2. Renvoie le formulaire d’ajout d’un
nouvel utilisateur.
3. L’administrateur saisit
les données de l’utilisateur.
4. Vérifie la validité des champs.
5. Enregistre les données du nouvel
utilisateur dans la table Utilisateur de
la base de données.
6. Redirection vers la liste des
utilisateurs.
1. Si l’utilisateur oublie de remplir un champ obligatoire :

• Le système affiche un message indiquant qu’il doit vérifier
les champs.
• Le scénario reprend à partir du 3 .
2. Si le CIN de l’utilisateur existe déjà dans la table Utilisateur de
la BD:
• L’administrateur sera redirigé vers la page d’ajout avec un
message
qui informe l’existence de CIN.
• Le scénario reprend du 3 .
Diagramme de Séquence « Modifier Utilisateur »
66
Figure 3.11 – Diagramme de Séquence « Modifier Utilisateur »
Description
1. L’administrateur
sélectionne l’utilisateur à
modifier. 2. Renvoie les données de l’utilisateur
dans formulaire.
3.L’administrateur modifie
les données de l’utilisateur. 4. Vérifie la validité des champs.
5. Enregistre les modifications dans
la table Utilisateur de la base de
données.
utilisateurs.
67

les champs.
• Le scénario reprend à partir du 1.
Diagramme de Séquence « Supprimer Utilisateur »
Figure 3.12 – Diagramme de Séquence « Supprimer Utilisateur »
Description
sélectionne l’utilisateur à
supprimer. 2. Demande la confirmation de la
suppression.
confirme la suppression. 3. Détruit l’utilisateur au niveau de la
BD.
68
1. Si l’administrateur ne confirme pas la suppression :

• La suppression de l’utilisateur sera .
• Le système affiche la liste des utilisateurs.
Diagramme de Séquence « Déposer Demande »
Figure 3.13 – Diagramme de Séquence « Déposer Demande »
Description
69
1. Le client choisit le type

de demande.
2. Renvoie le formulaire qui convient à
la demande choisie.
3. Le client remplit les

champs.
5. Enregistre les données de la
demande dans la BD.
6. Redirection vers la page d’accueil.

les champs.
• Le scénario reprend à partir du 3 .
Diagramme de Séquence « Modifier Demande »
70
Figure 3.14 – Diagramme de Séquence « Modifier Demande »
Description
1. Le client clique sur

modifier demande.
2. Renvoie les données de demande
dans un formulaire.
3.Le client modifie les
fichiers de la demande.
5. Enregistre les modifications dans la
table Fichier de la base de données.
6. Redirection vers le compte du
client.
71

les champs.
Diagramme de Séquence « Vérifier Demande »
Figure 3.15 – Diagramme de Séquence « Vérifier Demande »
Description
72
1. L’utilisateur sélectionne
la demande à vérifier.
2. Renvoie les données de demande.
3.L’utilisateur vérifie si
les fichiers relatifs à la 4. Enregistre le résultat de la
demande sont complet. vérification dans la BD.
demandes.
1. Si les fichiers ne sont pas complets :

• La demande va être réfusée jusqu’à la coplétude des
fichiers.
3.3.2 Diagramme de déploiement:

Définition:
Le diagramme de déploiement se rapproche de la réalité physique puisqu’il

identifie les éléments matériels (PC, Modem, Serveur, etc.), leur disposition
physique (connexions) et la disposition des exécutables (représentés par des
composants) sur ces éléments matériels. Chaque ressource étant matérialisée
par un nœud. [7]
73
Figure 3.16 – Diagramme de Déploiement
74
3.4 conclusion:
Dans ce chapitre nous avons présenté l’analyse et la conception de notre
application. Concernant la modélisation du système d’information nous avons
appuyé le langage de modélisation UML, détaillé les diagrammes de séquences
pour la modélisation dynamique en se basant sur le modèle MVC et présenté
le diagramme de classe pour la modélisation statique.
75
Chapitre 4: Réalisation du système
1.Introduction
2.Environnement de développement
2.1 Environnement matériel
2.2 Environnement logiciel
4.3.Présentation des exemples d’interfaces de
l’application
3.1 Interfaces Administrateur
3.2 Interfaces Utilisateur
3.3 Interfaces Client
4.Conclusion
76
Chapitre 4
Réalisation du système
4.1 Introduction
Après avoir effectué l’étude et la conception de notre application, nous
passons à la phase de Réalisation du système.
Nous allons présenter l’environnement matériel et logiciel de notre projet.
Par la suite nous allons présenter des captures d’écran des interfaces de l’application.
4.2 Environnement de développement

4.2.1 Environnement matériel:
Caractéristiques de Machine A Machine B

Marque DELL hp
Processeur Intel core i5 Intel core i5
Disque Dur 500 GB 500 GB
Ram 8 GB 4 GB
Système d’exploitation Windows 10 Pro Windows 10 Pro
Table 4.1 – Matériels de developpement
4.2.2 Environnement logiciel:

Outils utilisés:
Outil de rédaction du rapport: ShareLaTeX
77
ShareLaTeX est un environnement LaTeX complet et prêt à l’emploi, qui
fonctionne sur un serveur. ShareLateX prend en charge presque toutes les
caractéristiques LaTeX, y compris l’insertion d’images, les bibliographies, les
équations, etc.
De plus, ShareLaTeX est un éditeur collaboratif, il permet à plusieurs personnes
de travailler en même temps sur un même document LaTeX. Il n’y a qu’une
seule version maître de chaque document, à laquelle tout le monde a accès. Il
est ainsi impossible de créer des conflits de versions, et il n’est pas nécessaire
d’attendre que vos collègues vous envoient leur dernière version de travail pour
continuer à travailler. [8]
Outil de developpement: Eclipse
Eclipse est un projet, décliné et organisé en un ensemble de sous-projets

de développements logiciels, de la fondation Eclipse visant à développer un
environnement de production de logiciels libre qui soit extensible, universel et
polyvalent, en s’appuyant principalement sur Java.
Son objectif est de produire et fournir des outils pour la réalisation de
logiciels, englobant les activités de programmation, mais aussi d’AGL recouvrant
modélisation, conception, test, gestion de configuration, reporting. . . [9]
Serveur d’applications: APACHE TOMCAT
78
Tomcat est un serveur d’applications Java. Cela signifie deux choses : d’abord,
il est intégralement écrit en Java. Ensuite, les applications qu’il est capable
d’exécuter (nommées applications web) doivent être développées en Java.
Le rôle du serveur d’applications, nous l’avons compris, est double. Il doit
savoir exécuter des applications web pour répondre aux requêtes entrantes.
Il doit également être capable de convertir une requête en objet Java, pour
qu’elle soit exploitable par l’application. Et, en retour, savoir convertir l’objet
Java contenant la réponse générée, en réponse compréhensible par le serveur
web.[10]
Système de Gestion de Base de Données : PostgreSQL
PostgreSQL est un Système de Gestion de Base de Données (SBGD) libre

disponible sous licence BSD. Ce système multi-plateforme est largement connu
et réputé à travers le monde, notamment pour son comportement stable et pour
être très respectueux des normes ANSI SQL. Ce projet libre n’est pas géré par
une entreprise mais par une communauté de développeurs. [11]
Système de Gestion des documents:Alfresco
Alfresco est un système de gestion de contenu (en anglais ECM pour Enterprise
Content Management) créé par Alfresco Software en 2005 et distribué sous
79
licence libre. Il se distingue des autres systèmes par sa forme. En effet, il peut
se comporter sur un ordinateur comme un disque virtuel (se montant et se
démontant), ce qui permet à l’utilisateur de partager des fichiers simplement
en les déplaçant sur le disque dédié. Alfresco Content Services est basé sur un
noyau open source avec prise en charge des standards ouverts, des API ouvertes
et de diverses options de déploiement, y compris les configurations cloud, sur
site et hybride-cloud. La plate-forme puissante est facile à intégrer, à étendre
et à personnaliser pour répondre à vos besoins spécifiques.
Prise en charge immédiate des principales applications de productivité, notamment

Microsoft Office, Google Docs, Outlook et Salesforce.com
Une large gamme d’intégrations et de solutions préconstruites issues de la
communauté des partenaires Alfresco, notamment pour SAP, AutoCAD et bien
d’autres
API ouvertes et support inégalé pour les standards ouverts, notamment CMIS,
CIFS et WebDAV
[12]
Alfresco Share:
Alfresco Share est basé sur le référentiel ECM innovant d’ Alfresco et offre
une gestion de contenu collaborative prête à l’emploi. Alfresco Share simplifie
la capture, le partage et la récupération d’informations entre équipes virtuelles.
stimule la productivité; et réduit les besoins en bande passante réseau et les
volumes de courrier électronique entre les membres de l’équipe de projet [13]
outil de gestion de bases de données PostgreSQL: pgAdmin
80
pgAdmin est une plate-forme d’administration et de développement pour la
base de données PostgreSQL. Elle a été conçue pour répondre aux besoins de
tous les utilisateurs, depuis l’écriture de requêtes simples jusqu’au développement
de bases de données complexes. L’interface graphique donne accès aux fonctionnalités
de PostgreSQL les plus récentes, faisant de l’administration un véritable jeu
d’enfant. L’application comprend également un constructeur de requêtes, un
éditeur SQL, un éditeur de code server-side et bien plus encore. [14]
outil de gestion et d’automatisation de production des projets:

Apache Maven
Maven est un outil de construction de projets (build) open source développé

par la fondation Apache, initialement pour les besoins du projet Jakarta Turbine.
Il permet de faciliter et d’automatiser certaines tâches de la gestion d’un projet
Java.
Il permet:
• d’automatiser certaines tâches : compilation, tests unitaires et déploiement
des applications qui composent le projet.
• de gérer des dépendances vis-à-vis des bibliothèques nécessaires au projet.
• de générer des documentations concernant le projet. [15]
moteur de workflow: Activiti
81
Activiti est un moteur de workflow destiné à exécuter des processus métier
modélisés en BPMN 2.0. Il est écrit en Java et s’exécute dans un conteneur web
de type Tomcat.
Cet outil trouve son utilisation dans des projets divers tels que la dématérialisation
des processus Métiers, l’administration électronique, les Ressources Humaines,
la gestion de contrats, etc. [15]
Le moteur Activiti a un objectif clair d’être léger et facile à utiliser pour les
développeurs Java.
Voici les différents composants Activiti se combinant pour former une solution
complète de BPM dans un contexte complet de développement de logiciels.
Activiti Engine
C’est le cœur du projet Activiti. C’est un moteur de processus Java qui fonctionne
nativement en BPMN 2.
Activiti Explorer
C’est un exemple d’application Web qui donne accès à l’exécution du moteur
Activiti pour tous les utilisateurs du système. Elle comprend la gestion des
tâches, l’inspection des processus en instance, les fonctions de gestion et la
visualisation des rapports basés sur les données historiques.
82
Activiti Modeler
Il peut être utilisé pour créer des processus BPMN 2.0 graphiquement à l’aide
d’un navigateur. Les fichiers de processus sont stockés par le serveur dans un
référentiel de modèles en base de données.
Activiti Designer
C’est un plugin Eclipse qui vous permet de modéliser les processus BPMN
2.0 à partir de votre environnement IDE. Il supporte également les extensions
spécifiques à une activité pour v
ous permettre d’utiliser le plein potentiel de vos processus et du moteur.
Alfresco Alfresco fournit un produit open source qui offre beaucoup de fonctionnalités,
y compris document, contenu Web et gestion des enregistrements. Avec des
millions de téléchargements, Alfresco est utilisé dans beaucoup d’entreprises.
Pour répondre aux besoins de l’entreprise, Alfresco fournit une version Alfresco
Enterprise du produit Alfresco Community open source, qui offre plus d’outils
d’administration, un large éventail de bases de données prises en charge, détaillées
documentation et support 24/7. [16]
Langages de programmation:
LATEX
LaTeX est un langage créé pour séparer le fond de la forme lors de la

création d’un document ou d’une publication. Plus clairement, l’auteur tape
des instructions dans une sorte de bloc-notes et structure son texte grâce à des
mots et des commandes propres à LaTeX.
En résumé, LaTeX est un langage de description donnant à l’auteur les
moyens d’obtenir des documents mis en page de façon professionnelle sans avoir
à se soucier de leur forme. [17]
J2EE(Java Enterprise Edition)
83
Le terme « Java EE » signifie Java Enterprise Edition, et était anciennement
raccourci en « J2EE ».
JEE est la version entreprise de la plate-forme "Java" qui se compose de
l’environnement "JSE" ainsi que de nombreuses API et composants destinés à
une utilisation "côté serveur" au sein du système d’information de l’entreprise.
Il s’agit donc d’une évolution du Java. [18]
L’objectif majeur de Java EE est de faciliter le développement d’applications
web robustes et distribuées, déployées et exécutées sur un serveur d’applications.
[19]
XML(eXtensible Markup Language)
Le XML, acronyme de eXtensible Markup Language (qui signifie: langage

de balisage extensible), est un langage informatique qui sert à enregistrer des
données textuelles. [20]
JavaScript
Le Javascript est un langage de script incorporé dans un document HTML.

84
Historiquement il s’agit même du premier langage de script pour le Web. Ce
langage est un langage de programmation qui permet d’apporter des améliorations
au langage HTML en permettant d’exécuter des commandes du côté client,
c’est-à-dire au niveau du navigateur et non du serveur web. [21]
CSS
Le CSS est un langage informatique utilisé sur l’internet pour mettre en

forme les fichiers HTML ou XML. Ainsi, les feuilles de style, aussi appelé les
fichiers CSS, comprennent du code qui permet de gérer le design d’une page en
HTML.
L’avantage de l’utilisation d’un fichier CSS pour la mise en forme d’un site
réside dans la possibilité de modifier tous les titres du site en une seule fois en
modifiants une seule partie du fichier CSS. [22]
BPMN 2.0 : un langage d’exécution
Parmi les principaux sujets traités par L’OMG, définir un schéma d’échange
standard basé sur XML pour l’échange de modèles exécutables, en était le
principal. Le format XML défini est un enjeu important car BPMN 2.0 a la
volonté de devenir un langage de modélisation exécutable en remplacement de
BPEL. L’intérêt étant bien sûr d’être en capacité d’exécuter directement les
modèles dans un moteur d’exécution. Pour mémoire, avant, il fallait « mapper
» manuellement BPMN 1.x avec BPEL pour exécuter les processus modélisés.
Html:HyperText Markup Language
L’HyperText Markup Language, généralement abrégé HTML, est le langage

de balisage conçu pour représenter les pages web. C’est un langage permettant
d’écrire de l’hypertexte, d’où son nom. HTML permet également de structurer
sémantiquement et logiquement et de mettre en forme le contenu des pages,
85
d’inclure des ressources multimédias dont des images, des formulaires de saisie et
des programmes informatiques. Il permet de créer des documents interopérables
avec des équipements très variés de manière conforme aux exigences de l’accessibilité
du web. Il est souvent utilisé conjointement avec le langage de programmation
JavaScript et des feuilles de style en cascade (CSS). HTML est initialement
dérivé du Standard Generalized Markup Language (SGML).
4.3 Présentation des exemples d’interfaces de l’application

4.3.1 Présentation des interfaces administrateur:
4.3.2 Présentation des interfaces utilisateur:
4.3.3 Présentation des interfaces client:
86
4.4 Conclusion:
Au cours de ce chapitre, nous avons décrit la présentation de l’environnement
matériels et logiciels sur lequel nous avons fait notre application. Ensuite,
nous avons présenté des captures d’écran de certaines des interfaces de notre
application.
Maintenant, nous passons à la conclusion générale de notre projet et aux
perspectives que nous souhaitons achever dans le futur.
87
Conclusion générale
L’objectif visé à travers ce rapport est de présenter l’application réalisée au
cours de notre stage de fin d’étude au sein de la Municipalité de Sousse
On a commencé par la présentation du contexte générale du projet, puis on

a consacré nos réflexions à l’étude de l’exstant, et on a critiqué les application
existantes pour améliorer notre application.
Cette étude nous a permis de citer les besoins de la municipalité et les répartir
en besoins fonctionnels et non fonctionnels. Puis on a passer à la phase la plus
importante ce qui est phase de conception détailée basée sur UML et MVC.
En effet, on a pu, dans ce temps limité , développer une interface qui répond
éventuellement aux exigences soulignées pendant l’analyse et la conception.
Même si on n’a pas fini toute l’application qui nous voulions, mais la partie la
plus complexe a été réalisée et approuvée par nos superviseurs.
Ce stage et cette expérience nous ont offert une bonne préparation à notre
futur car elle fut une expérience enrichissante et complète pour nous qui conforte
notre désir d’exercer notre futur emploi dans le domaine de l’informatique.
Les réunions régulières effectuées avec nos encadrants dans la municipalité

et à l’institut nous ont permis d’approfondir nos connaissances dans les bonnes
pratiques de la gestion de projet.
Les difficultés majeures qu’on a rencontrées durant ce projet résident essentiellement

dans la nouveauté et la complexité du workflow. Mais, les conseils de nos
encadrants dans la société et à l’école nous ont aidé et encouragé à réaliser
et réussir à finaliser ce projet.
Finalement, nous souhaitons très fortement que la municipalité adopte réellement

notre application.
88
Bibliographie
[1] http://www-igm.univ-mlv.fr/~dr/COURS/analyse/node6.html
[2] http://www.louvet.perso.math.cnrs.fr/documents/up_moocs.pdf
[3] https://laurent-audibert.developpez.com/Cours-UML/?page=diagramme-
classes
[4] https://fr.wikipedia.org/wiki/Diagramme_de_séquence
[5] www.jaime5a10.ca/upload/pdf/Documentation_MVC.pdf
[6] https://openclassrooms.com/courses/apprenez-a-programmer-en-
java/mieux-structurer-son-code-le-pattern-mvc
[7] http://lecourspratique.blogspot.com/2013/09/5-le-diagramme-
de-deploiement.html
[8] https://framalibre.org/content/sharelatex
[9] https://fr.wikipedia.org/wiki/Eclipse_(projet)
[10] http://www-igm.univ-mlv.fr/~dr/XPOSE2003/tomcat/tomcat.php?
rub=3
[11] http://sql.sh/sgbd/postgresql
[12]
[13]
[14] http://www.01net.com/telecharger/windows/Programmation/base_
de_donne/fiches/28430.html
[15] https://www.jmdoudoux.fr/java/dej/chap-maven.htm
[16] https://fr.wikipedia.org/wiki/Activiti_(logiciel)
[17] http://www.starxpert.fr/bonita/
[18]https://fr.wikibooks.org/wiki/Programmation_JEE/Pr%C3%A9sentation_
du_JEE
89
[19] https://openclassrooms.com/courses/creez-votre-application-
web-avec-java-ee/introduction-au-java-ee
[20] http://glossaire.infowebmaster.fr/xml/
[21]https://www.commentcamarche.com/contents/577-javascript-introduction-
au-langage-javascript
[22]http://glossaire.infowebmaster.fr/css/
90

Rapport Arij Yosra Workflow

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rapport Arij Yosra Workflow

Uploaded by

Copyright:

Available Formats

Remerciements

Nous tenons à remercier dans un premier temps, notre encadrant académique,

Nous tenons à exprimer une sincére reconnaissance à notre encadrant professionnel,

Nous remercions également toute l’équipe pédagogique de l’Institut Supérieur

1.1 Logo du la Municipalité "Sousse" . . . . . . . . . . . . . . . . . . . 9

2.1 Scénario de cas "S’authentifier" . . . . . . . . . . . . . . . . . . . . 34

Le besoin de construire de nouveaux bâtiments résidentiels et de service est

Notre rapport se subdivise en quatre chapitres principaux dans lesquels nous

1.2 Contexte du travail

Nous présentons l’organisme d’accueil "Municipalité de

Fiche de renseignements généraux :

La structure de la municipalité est simple et bien ordonnée. Les différents

Figure 1.3 – L’organigramme de la municipalité sousse

1.3 Étude préalable :

Le workflow est un processus qui fait apparaitre une suite de tâches et

Les concepts de base :

La norme de modélisation des processus métier (BPMN) est une méthode

Son objectif est de modéliser des façons d’améliorer l’efficacité, de prendre

Figure 1.4 – exemple BPMN

1.3.2 Gestion electronique de document

Pour y répondre, les entreprises dressent de longues listes de documents,

Dans le cadre du management environnemental, la GED est aussi un levier

1.3.3 Présentation du sujet

1.4 Cahier de charge

1.4.2 L’application de la municipalité :

Figure 1.7 – Interface de l’application de municipalité

1.4.3 l’application de R’ads

1.5 Critique de l’existant:

1.6 Spécification des besoins:

1.6.1 Les besoins fonctionnels :

1.7 Solution proposée:

1.8 Architecture envisagée :

Figure 1.10 – Caption

1.9 Planning des tâches :

Figure 1.11 – Diagramme de Gantt

2.2 Méthode et outils de modélisation choisis

Figure 2.1 – les phases de processus unifié

2.2.2 Choix de la laungage de conception :

Figure 2.2 – Logo d’UML

Qu’est-ce que Visio ? :

Visio, officiellement "Microsoft Office Visio", est une application de la suite

Ses points forts:

Parmi les points forts de Visio nous citerons que :

2.3 Modèle métier (Diagramme de Cas d’utilisation) :

2.3.2 Identification des acteurs:

2.3.3 Diagramme processus métier :

2.4 Spécification des cas d’utilisation :

Nom du cas S’authentifier

Table 2.1 – Scénario de cas "S’authentifier"

Figure 2.5 – Raffinement de cas Gérer utilisateur

Consulter les utilisateur

nom de cas d’utilisation Consulter les utilisateurs

Table 2.2 – Scénario de cas:"consulter liste utilisatuers"

nom de cas d’utilisation Modifier utilisateur

Table 2.3 – Scénario de cas:"Modifier utilisateur"

nom de cas d’utilisation Suprimer utilisateur

Table 2.4 – Scénario de cas:"Suprimer utilisatuer"

Figure 2.6 – Raffinement de cas : Gérer demande(Admin)

Figure 2.7 – Raffinement de cas : Gérer demande

Table 2.5 – Scénario de cas:"déposer demande "

nom de cas d’utilisation Créer Compte

Table 2.6 – Scénario de cas:"Créer Compte"

Scénario d’exception 5. Modification non valide - Le système

Table 2.7 – Scénario de cas:"Modifier compte"