Memoire Online - Mise en place d'une application de valorisation des œuvres des ingénieurs architectes de la ville de Bukavu. Cas de Mega Engineering Company «MEC»

Nous pouvons soutenir que la solution manuelle n'est pas à rejeter mais à améliorer pour pallier aux caprices technologiques imprévisibles. Comme solution manuelle que nous pouvons proposer; il faut que les ingénieurs fassent beaucoup d'efforts pour sensibiliser la population de la ville de Bukavu sur l'importance de l'architecture dans la conception des bâtiments de la ville.

2. Solution Informatique

Ici nous conseillons à tous les ingénieurs d'utiliser la plateforme que nous allons mettre en place pour bien gérer les opérations de valorisation de leurs oeuvres dans notre chère ville de Bukavu.

3. Solution adoptée

De toutes les solutions énumérées, nous allons nous adapter à celles que nous qualifierons d'excellent pour non seulement alléger et actualiser le système en place, mais surtout pour optimiser le rendement de l'institution. Nous pensons jusque-là que c'est la solution informatique qui est la plus efficace que celle manuelle.

II.6.LA MODELISATION AVEC LE LANGAGE UML

Dans le cadre de ce point, nous allons définir quelques généralités portant sur la méthode et outils mettant en évidence la réalisation de notre projet. Nous allons commencer par présenter le langage de modélisation unifié UML (Unified Modeling Language), définir la démarche générique du processus de développements logiciel qui l'accompagne, énumérer les architectures réseaux et enfin nous allons présenter les principaux concepts de base des services web.

Pendant plusieurs décennies, le monde informatique a toujours rêvé d'un processus qui puisse garantir le développement efficace de logiciels de qualité, valable quelque soit la grandeur et la complexité du projet, et présentant de bonnes pratiques adaptées à la méthode en question, surtout que, de nos jours, les logiciels demandés sont de plus en plus imposants et exigeants qu'auparavant.

Le processus unifié semble être la solution idéale pour remédier à l'éternel problème des développeurs. En effet, il regroupe les activités à mener pour transformer les besoins d'un utilisateur en un système logiciel quelque soit la classe, la taille et le domaine d'application de ce système.

Le processus unifié utilise le langage UML (Unified Modeling Language). Ce langage de modélisation est une partie intégrante du processus unifié, ils ont été d'ailleurs développés de concret.

Essayons tout d'abord de présenter UML, car ses diagrammes sont utilisés dans chaque phase et activité du processus unifié, ensuite nous reviendrons sur la présentation du processus unifié.

UML (Unified Modeling Language), se définit comme un langage de modélisation graphique et textuel destiné à comprendre et à définir des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue. UML modélise l'ensemble des données et des traitements en élaborant des différents diagrammes. En clair, il ne faut pas designer UML en tant que méthode (Il y manque la démarche) mais plutôt comme une boite d'outils qui sert à améliorer les méthodes de travail.

UML dans sa version 2 s'articule autour de treize diagrammes, chacun d'entre eux est dédié à la représentation d'un système logiciel suivant un point de vue particulier. Ces diagrammes sont regroupés dans deux grands ensembles: les diagrammes structurels et les diagrammes de comportement.

L'ensemble des treize types de diagrammes UML peut ainsi être résumé de la manière suivante:Diagramme deComportement, Diagramme d'activité, Diagramme de cas, Diagramme d'état, Diagramme d'interaction, Diagramme de composant, Diagramme d'objet, Diagramme de classe, Diagramme de déploiement, Diagramme de structure composite, Diagramme de package, Diagramme de séquence, Diagramme de communication, Diagramme de vue d'ensemble d'interaction, Diagramme de Timing, Diagramme deStructure

Nous présentons ci-dessous les diagrammes UML 2, que nous avons utilisés dans le cadre de ce projet et quelques notions de base qui leurs étant associées.

Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au système. Il constitue un des diagrammes les plus structurants dans l'analyse d'un système. Le digramme des cas d'utilisation a des éléments suivants :

Ø Acteur : Représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié.

Ø Cas d'utilisation (use case) : Représente un ensemble de séquences d'actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier.

Ø Les relations entre acteurs : La seule relation entre acteur est la relation de généralisation. Quand un acteur fils hérite d'un acteur père, il hérite en réalité de toutes les associations du père.

- Relation d'inclusion : Une relation d'inclusion d'un cas d'utilisation A par rapport à un cas d'utilisation B signifie qu'une instance de A contient le comportement décrit dans B.

- Relation d'extension : Une relation d'extension d'un cas d'utilisation A par un cas d'utilisation A signifie qu'une instance de A peut être étendue par le comportement décrit dans B.

- Relation de généralisation : Les cas d'utilisation descendants héritent de la description de leurs parents communs. Chacun d'entre eux peut néanmoins comprendre des interactions spécifiques supplémentaires.

Il est question dans ce point de représenter les différents acteurs qui interviendront dans notre application. Ces acteurs ont tous, les rôles à jouer dans l'application. Ces rôles sont appelées ici « cas d'utilisation. »

LES ACTEURS	LES CAS D'UTILISATIONS
INGENIEUR	S'authentifier
	Ajouter une oeuvre
	Visualiser les oeuvres disponibles
	Chatter avec un client
	Chatter avec d'autres ingénieurs
CLIENT	S'authentifier
	Visualiser les oeuvres disponibles
	Chatter avec des ingénieurs
	Acheter une oeuvre
ADMINISTRATEUR	S'authentifier
	Gérer les utilisateurs
	Gérer les clients (Ajouter, modifier, supprimer)
	Gérer les ingénieurs (Ajouter, Modifier, Supprimer)
	Gérer les oeuvres (Ajouter, modifier, supprimer)
	Gérer les ventes (Ajouter, modifier, supprimer)

CU1	« Créer compte »
Résumé	Le CU1 permet aux utilisateurs d'avoir les comptes
Auteur	Administrateur, ingénieur et client
Précondition	Aucune
Scénario nominal	« DEBUT » 1. L'utilisateur ouvre le formulaire permettant la création d'un nouveau compte ; 2. Le système affiche le formulaire permettant la création d'un nouveau compte ; 3. L'utilisateur saisie les informations relatives à l'ouverture du compte ; 4. Le système vérifie la validité des données saisies ; 5. Le système enregistre ces informations dans la base des données ; 6. Le système envoie une notification de bon déroulement de l'opération.

CU2	«*Ajouter une oeuvre*»
Résumé	Le CU2 permet à l'Administrateur et ingénieur de mettre l'oeuvre en ligne
Acteur	Administrateur et ingénieur
Précondition	Login et password
Scénario nominal	« DEBUT » 1. Le système affiche le formulaire de connexion ; 2. L'agent fournit son login et son mot de passe ; 3. Le système vérifie les paramètres de connexion; 4. Le système affiche le formulaire d'ajout des oeuvres; 5. L'utilisateur enregistre les informations de l'oeuvre dans la base des données ; 6. Le système envoie une notification de bon déroulement de l'opération.
Scénario alternatif	A1 : si login et mot de passe incorrects : 7. Message d'erreur et se positionne au point 2 ; A2 : Informations existantes ou champ vides : 8. Message d'erreur et se positionne au point 5 Fin.

CU3	«*Gérer des oeuvres*»
Résumé	Le CU3 permet à l'administrateur de gérer les ventes en ligne
Acteur	Administrateur
Précondition	Login et password
Scénario nominal	« DEBUT » 1. Le système affiche le formulaire de connexion ; 2. L'agent fournit son login et son mot de passe ; 3. Le système vérifie les paramètres de connexion; 4. Le système affiche le formulaire de gestion des ventes; 5. L'utilisateur enregistre les informations de la vente dans la base des données ; 6. Le système envoie une notification de bon déroulement de l'opération.
Scénario alternatif	A1 : si login et mot de passe incorrects : 7. Message d'erreur et se positionne au point 2 ; A2 : Informations existantes ou champ vides : 8. Message d'erreur et se positionne au point 5 Fin.

Ce diagramme permet de décrire les scénarios de chaque cas d'utilisation en mettant l'accent sur la chronologie des opérations en interaction avec les objets.

- Scénario: Représente une succession particulière d'enchaînements, s'exécutant du début à la fin du cas d'utilisation, un enchaînement étant l'unité de description de séquences d'actions.

- Ligne de vie : Représente l'ensemble des opérations exécutées par un objet.

- Message: Un message est une transmission d'information unidirectionnelle entre deux objets, l'objet émetteur et l'objet récepteur. Dans un diagramme de séquence, deux types de messages peuvent être distingués :

- Message synchrone : Dans ce cas l'émetteur reste en attente de la réponse à son message avant de poursuivre ses actions.

- Message asynchrone : Dans ce cas, l'émetteur n'attend pas la réponse à son message, il poursuit l'exécution de ses opérations.

Légende : Pour que l'utilisateur arrive à se connecter, il doit d'abord saisir sont mot de passe et son login, et puis le système va vérifier s'ils sont corrects ; si oui, le système affiche la session utilisateur et renvoi à la case de départ dans le cas contraire

Légende : pour que l'utilisateur arrive à ajouter une oeuvre, il doit lancer le système, en étant connecté, il doit demander au système le formulaire de l'enregistrement des oeuvres ; après, il doit remplir le formulaire puis soumettre dans le système.

Ce diagramme donne une vision des enchaînements des activités propres à une opération ou à un cas d'utilisation. Il permet aussi de représenter les flots de contrôle et les flots de données.

Le diagramme de classes est le point central dans un développement orienté objet. En analyse, il a pour objectif de décrire la structure des entités manipulées par les utilisateurs. En conception, le diagramme de classes représente la structure d'un code orienté.

- Une classe : Représente la description abstraite d'un ensemble d'objets possédant les mêmes caractéristiques. On peut parler également de type.

- Un objet: Est une entité aux frontières bien définies, possédant une identité et encapsulant un état et un comportement. Un objet est une instance (ou occurrence) d'une classe.

- Un attribut : Représente un type d'information contenu dans une classe. [Roques06]

- Une opération: Représente un élément de comportement (un service) contenu dans une classe.

- Une association: Représente une relation sémantique durable entre deux classes.

- Une superclasse : Est une classe plus générale reliée à une ou plusieurs autres classes plus spécialisées (sous-classes) par une relation de généralisation. Les sous-classes« Héritent » des propriétés de leur superclasse et peuvent comporter des propriétés spécifiques supplémentaires.

Dans ce chapitre, nous avons présenté l'étude et la modélisation du système de valorisation des oeuvres des ingénieurs architectes de Bukavu. Nous avons commencé par identifier les besoins des différents acteurs du système, à savoir les ingénieurs architectes et le public.

Sur la base de ces besoins, nous avons proposé une architecture du système qui répond aux enjeux spécifiques du contexte de Bukavu. Cette architecture repose sur les technologies numériques, notamment les applications mobiles, le web et les réseaux sociaux.

Nous avons ensuite présenté un modèle du système qui décrit les différentes entités et les relations entre elles. Ce modèle permet de comprendre le fonctionnement du système et de faciliter sa conception et sa mise en oeuvre.

Dans les chapitres suivants, nous nous concentrerons sur la conception et la mise en oeuvre du système. Nous développerons les fonctionnalités du système en fonction des besoins des différents acteurs. Nous nous assurerons également que le système est compatible avec les contraintes du contexte de Bukavu.

Mise en place d'une application de valorisation des œuvres des ingénieurs architectes de la ville de Bukavu. Cas de Mega Engineering Company «MEC»

II.5. SOLUTIONS PROPOSEES

1. Solution manuelle

2. Solution Informatique

3. Solution adoptée

II.6.LA MODELISATION AVEC LE LANGAGE UML