WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception d'une BD de contravention et accident de la route pour une circonscription

( Télécharger le fichier original )
par Emmanuel PILITHA
IUT Fotso Victor de Bandjoun - Licence 2007
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

II.1 ACTEURS DU SYSTEME

Acteurs

Tâches

1

Administrateur

C'est l'administrateur du système il veille sur tout le système : création des comptes utilisateurs, modification, suppression et mise à jour du système. L'administrateur est le Commissaire de Police

2

Utilisateur :

- utilisateur : un policier ;

- utilisateur : Caisse ;

L'utilisateur est chargé des enregistrements des contraventions et amandes. Il établi le reçu de payement des amendes. Il peut faire des recherches, imprime l'état de la journée. Utilisateur peut être un policier désigné par le Commissaire de Police.

3

Invité :

- invité : Accusé ;

- invité : Policier : Qui peut être une équipe de constat.

Accusé est la personne en état d'infraction. Il peut :

- S'informer ;

- Consulter la liste des contraventions ;

- Résoudre son problème d'amende

Ici c'est le policier qui est chargé de faire le constat quand une infraction est constatée.

Tableau 3 : Acteur du Système

II.2 DIAGRAMME DE CAS D'UTILISATION

Un cas d'utilisation est un moyen de représenter les différentes possibilités d'utiliser un système. Il exprime toujours une suite d'interactions entre un acteur et l'application. Il définit une fonctionnalité utilisable par un acteur.

Figure 2 : Diagramme de cas d'utilisation

II.3 SCENARIO DES CAS D'UTILISATION

La description d'un cas d'utilisation se fait par des scénarios qui définissent la suite logique des interactions qui constituent ce cas. On peut définir des scénarios simples ou des scénarios plus détaillés faisant intervenir les variantes, les cas d'erreurs, etc. Cette description se fait de manière simple, par un texte compréhensible par les personnes du domaine de l'application. Elle précise ce que fait l'acteur et ce que fait le système. La description détaillée pourra préciser les contraintes de l'acteur et celles du système.

1. Scénario cas d'utilisation: Ajout d'un nouveau compte

Description : Ajouter un nouveau compte

Auteur : Administrateur

Règle d'initiation : L'administrateur doit créer des comptes utilisateurs pour le système.

Description du Processus :

1- l'administrateur s'identifie ;

2- l'administrateur clique sur le lien <nouveau compte> ;

3- l'administrateur entre les paramètres personnels de l'utilisateur : nom, prénom, mot de passe ... via un formulaire crée à cet effet.

Règles de Terminaison : L'administrateur valide le formulaire par le bouton Créer et informe l'utilisateur de ses paramètres de connexion.

2. Scénario cas d'utilisation: Modification d'un compte

Description : Modification d'un compte

Auteur : Administrateur

Règle d'initiation : Pour une mesure de sécurité l'administrateur peut modifier les comptes utilisateurs une fois par mois ou par 2 mois.

Description du Processus :

1- l'administrateur s'identifie ;

2- l'administrateur clique sur le lien <Modifier compte> ;

3- l'administrateur modifie les paramètres de connexion (login et mot de passe) ... via un formulaire crée à cet effet.

Règles de Terminaison : L'administrateur valide le formulaire par le bouton Modifier et informe l'utilisateur de ses paramètres de connexion.

3. Scénario cas d'utilisation: Suppression d'un compte

Description : Suppression d'un compte

Auteur : Administrateur

Règle d'initiation : Pour un changement de personnel cas de force majeur par exemple : affectation ..., le compte de l'utilisateur peut être supprimé.

Description du Processus :

1- l'administrateur s'identifie ;

2- l'administrateur clique sur le lien <Supprimer compte> ;

Règles de Terminaison : L'administrateur valide la suppression par le bouton Ok.

4. Scénario cas d'utilisation: Mise à jour du système

Description : Mise à jour du Système

Auteur : Administrateur

Règle d'initiation : Reclassement des classes des contraventions, nouveau contravention ou modification.

Description du Processus :

1- l'administrateur s'identifie ;

2- l'administrateur clique sur le lien <Mise à jour> ;

3- Choisi l'option de mise à jour

Règles de Terminaison : L'administrateur valide par le bouton qui le concerne.

5. Scénario cas d'utilisation: Enregistrement des contraventions et pénalités

Description : Enregistrement des contraventions, pénalités

Auteur : Utilisateur

Règle d'initiation : Chargement de la base de données

Description du Processus :

1- l'utilisateur s'identifie ;

2- l'utilisateur clique sur le lien <nouveau contravention> ;

3- l'utilisateur entre : le code de la contravention, la classe de la contravention, l'amende, le retrait de point, la suspension du permis ...

Règles de Terminaison : L'utilisateur valide par le bouton <Enregistrer>.

6. Scénario cas d'utilisation: Etablir un reçu

Description : Etablir un reçu

Auteur : Utilisateur

Règle d'initiation : Accusé en état d'infraction constaté

Description du Processus :

1- l'utilisateur s'identifie ;

2- l'utilisateur rempli le formulaire reçu (entre le nom de l'accusé, recherche la contravention correspondante) ;

Règles de Terminaison : L'utilisateur imprime le reçu.

7. Scénario cas d'utilisation: Rechercher

Description : Recherche

Auteur : Utilisateur

Règle d'initiation : Pour retrouver une contravention

Description du Processus :

1- l'utilisateur s'identifie ;

2- l'utilisateur entre le code de la contravention à rechercher.

Règles de Terminaison : L'utilisateur valide par le bouton <Rechercher>.

8. Scénario cas d'utilisation: Ressortir état de la journée

Description : Ressortir l'état de la journée

Auteur : Utilisateur

Règle d'initiation : Bilan de payement d'amende de la journée

Description du Processus :

1- l'utilisateur s'identifie ;

2- l'utilisateur clique sur le lien <Bilan de la journée>

Règles de Terminaison : L'utilisateur valide par le bouton <Imprimer>

9. Scénario cas d'utilisation: Faire un constat

Description : Faire un constat

Auteur : Invité = Policier = Equipe de constat

Règle d'initiation : Infraction

Description du Processus :

1- le policier constate une infraction où est interpellé par une infraction;

2- le policier fait le constat

Règles de Terminaison : Ressort un rapport de constat.

10. Scénario cas d'utilisation: Etabli le ticket de constat et remet à l'accusé

Description : Etabli le ticket de constat et remet à l'accusé

Auteur : Invité = Policier

Règle d'initiation : Constat

Description du Processus :

1- le policier demande les pièces de l'accusé : CNI de accusé par exemple ;

2- rempli le ticket de payement.

Règles de Terminaison : Remet le ticket à l'accusé

11. Scénario cas d'utilisation: Dresse le PV

Description : Dresse le Procès verbal de l'infraction

Auteur : Invité = Policier

Règle d'initiation : Constat

Description du Processus :

1- le policier tient compte du jour, de l'heure de l'infraction, des témoins présent lors de l'infraction ;

2- le policier décrit les scenarios de l'infraction

Règles de Terminaison : Le policier et l'accusé signe le PV.

12. Scénario cas d'utilisation: S'informer

Description : Information

Auteur : Accusé

Règle d'initiation : Besoin d'être informé

Description du Processus :

1- l'accusé lance la plate forme de la base de données sur Internet via l'url ;

2- la plate forme s'ouvre et il peut avoir des informations sur les contraventions et amendes.

Règles de Terminaison : il quitte la plate forme.

13. Scénario cas d'utilisation: Consulter la liste des contraventions

Description : Consulter la liste des contraventions

Auteur : Accusé

Règle d'initiation : Besoin d'être informé

Description du Processus :

3- l'accusé lance la plate forme de la base de données sur Internet via l'url ;

4- la plate forme s'ouvre et il peut consulter des informations sur les contraventions et amendes.

Règles de Terminaison : il quitte la plate forme.

14. Scénario cas d'utilisation: Résoudre son problème d'amende

Description : Résoudre son problème d'amende

Auteur : Accusé

Règle d'initiation : Obligation d'obtempérer

Description du Processus :

1- l'accusé se rend au commissariat de la localité où l'infraction a été constaté ;

2- l'accusé s'adresse au service s'occupant de la contravention.

Règles de Terminaison :

1- Payement des frais d'amende ;

2- Retrait de points ;

3- Suspension de permis

15. Scénario cas d'utilisation: Valide le reçu de payement

Description : Valide le reçu de payement

Auteur : Caisse

Règle d'initiation : Reçu imprimé

Description du Processus :

1- l'utilisateur transmet le reçu imprimé à la caisse pour encaissement ;

2- la caisse valide le payement

Règles de Terminaison : la caisse communique le montant à payer au concerné qui est l'accusé.

16. Scénario cas d'utilisation: Encaisse l'amende

Description : encaisse l'amende

Auteur : Caisse

Règle d'initiation : Reçu validé

Description du Processus :

1- la caissière se logue ;

2- l'accusé paye son reçu ;

3- la caisse encaisse la somme due

Règles de Terminaison : la caisse remet le reçu de payement à l'accusé.

17. Scénario cas d'utilisation: Etat de la journée

Description : Etat de la journée

Auteur : Caisse

Règle d'initiation : Impression des états

Description du Processus :

1- la caissière se logue ;

2- la caissière clique sur le lien <Impressions des états> ;

Règles de Terminaison : la caissière valide par le bouton <Imprimer> ;

II.4 DIAGRAMME DES CLASSES

Un diagramme des classes décrit le type des objets ou données du système ainsi que les différentes formes de relation statiques qui les relient entre eux. On distingue classiquement deux types principaux de relations entre objets :

- les associations, bien connues des modèles entité/association utilisés dans la conception des bases de données ;

- les sous-types, particulièrement en vogue en conception orientée objets, puisqu'ils s'expriment très bien à l'aide de l'héritage en programmation.

Dictionnaire de données

Identifiant

Désignation

Type

Taille

Code_accuse

Code de l'accusé

AN

10

Nom_accuse

Nom de l'accusé

AN

255

Prenom_accuse

Prénom de l'accusé

AN

255

Adresse_accuse

Adresse de l'accusé

AN

255

Date_accusation

Date de l'accusation

D

08

Numero_cni

Numéro de la carte nationale d'identité

N

15

Code_commissariat

Code du commissariat

AN

10

Nom_commissariat

Nom du commissariat

AN

255

Nom_commisssaire

Nom du commissaire

AN

255

Nom_policier_const

Nom du policier ayant constaté

AN

255

Code_contravention

Code de la contravention

AN

10

Libelle_contravention

Libellé de la contravention

AN

255

Classe_contravention

Classe de la contravention

AN

10

Article_contravention

Article correspondant à la contravention

AN

10

Code_penalite

Code de la pénalité

AN

10

Amende

Amende liée à la contravention

AN

15

Retrait

Retrait de points lié à la contravention

AN

5

Suspension_permis

Suspension de permis liée à la contravention

AN

5

Code_caisse

Code de la caisse

AN

10

Montant

Montant à versement

N

15

Nom_agent_caisse

Nom agent de la caisse

AN

255

Dateversement

Date de versement

D

08

Date_delivr_cni

Date de délivrance de la carte nationale d'identité

D

08

quartier

Quartier de l'accusé

AN

255

arrondissement

Arrondissement accusé

AN

255

Date_nais

Date de naissance de l'accusé

D

08

Lieu_nais

Lieu de naissance de l'accusé

AN

200

Nom_pere

Nom du père de l'accusé

AN

255

Profession

Nom de la mère de l'accusé

AN

255

A : Alpha AN : Alphanumérique

N : Numérique D : Date

Figure 3 : Diagramme de classe

II.5 DIAGRAMME DE COMPOSANT

Les diagrammes de composants permettent de décrire l'architecture physique et statique d'une application en termes de modules : fichiers sources, librairies, exécutables, etc.
Ils montrent la mise en oeuvre physique des modèles de la vue logique avec l'environnement de développement.

Les dépendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en évidence la réutilisation de composants.

Les composants peuvent être organisés en paquetages, qui définissent des sous-systèmes. Les sous-systèmes organisent la vue des composants (de réalisation) d'un système. Ils permettent de gérer la complexité, par encapsulation des détails d'implémentation.

Figure 4 : Diagramme de composant

II.6 DIAGRAMME DE DEPLOIEMENT

Les diagrammes de déploiement montrent la disposition physique des matériels qui composent le système et la répartition des composants sur ces matériels.

Les ressources matérielles sont représentées sous forme de noeuds.

Les noeuds sont connectés entre eux, à l'aide d'un support de communication.
La nature des lignes de communication et leurs caractéristiques peuvent être précisées.

Les diagrammes de déploiement peuvent montrer des instances de noeuds (un matériel précis), ou des classes de noeuds.

Figure 5 : Diagramme de déploiement

III. VUE DYNAMIQUE DU SYSTEME

III.1 DIAGRAMME DE COLLABORATION

Les collaborations sont des interactions entre objets, dont le but est de réaliser un objectif du système (c'est-à-dire aussi de répondre à un besoin d'un utilisateur).

Payement des amendes

Accusé

Commissariat

Pénalité

Contravention

Caisse

Une contravention conduit à une pénalité

<Initiateur>

<Participant>

<Participant>

<Participant>

<Participant>

Figure 6 : Diagramme de collaboration

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Je ne pense pas qu'un écrivain puisse avoir de profondes assises s'il n'a pas ressenti avec amertume les injustices de la société ou il vit"   Thomas Lanier dit Tennessie Williams