Le language UML

RÉVISION DES PRIX AU NIVEAU DES MARCHES PUBLICS 

LE LANGUAGE UML

UML est l’accomplissement de la fusion de précédents langages de modélisation objet : Booch, OMT, ROOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar Jacobson, UML est à présent un standard défini par l’Object Management Group (OMG). La dernière version diffusée par l’OMG est UML 2.4.1 depuis août 2011.Le modèle en cascade est le premier modèle proposé pour répondre à la crise (1970), c’est un modèle linéaire qui possède les caractéristiques suivantes :

 Le projet est décomposé en phases, où chaque phase correspond à une activité bien précise qui produit un produit livrable (document ou code).
 Les phases sont exécutées successivement selon un ordre bien déterminé (Figure 4), le résultat d’une phase est utilisé par la phase qui la suit.
 Le passage à la phase suivante se fait lorsque la phase en cours aboutit à son objectif et le produit livrable est jugé satisfaisant.
 Une phase ne peut remettre en cause que les résultats de la phase qui la précède et non ceux de toutes les phases antérieurs.
 Le dernier point constitue la faiblesse principale de ce modèle. En effet, les erreurs commises durant les premières phases, besoins mal exprimés par exemple, ne sont détectées.

Le Modèle MVC (Le Modèle-vue-contrôleur)

Le patron Modèle-vue-contrôleur est un modèle destiné à répondre aux besoins des applications interactives en séparant les problématiques liées aux différents composants au sein de leur architecture respective. Modèle : Le modèle représente le cœur (algorithmique) de l’application :
 Traitements des données, interactions avec la base de données, etc.
 Décrit les données manipulées par l’application.
 Regroupe la gestion de ces données et est responsable de leur intégrité.
 Base de données sera l’un de ses composants. Le modèle comporte des méthodes standards pour mettre à jour ces données (insertion, suppression, changement de valeur).
 Offre aussi des méthodes pour récupérer ces données. Les résultats renvoyés par le modèle ne s’occupent pas de la présentation.
 Modèle ne contient aucun lien direct vers le contrôleur ou la vue.
 Communication avec la vue s’effectue au travers du patron Observateur. Vue :
 C’est avec quoi l’utilisateur interagit se nomme précisément la vue.
 S’occupe de présenter les résultats renvoyés par le modèle.
 Recevoir toute action de l’utilisateur (hover, clic de souris, sélection d’un bouton radio, coche d’une case, entrée de texte, de mouvements, de voix, etc.).
 N’effectue pas de traitement, elle se contente d’afficher les résultats des traitements effectués par le modèle et d’interagir avec l’utilisateur. Contrôleur :
 Prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le modèle et les synchroniser.
 Reçoit tous les événements de l’utilisateur et enclenche les actions à effectuer.
 Si une action nécessite un changement des données, le contrôleur demande la modification des données au modèle, et ce dernier notifie la vue que les données ont changée pour qu’elle se mette à jour.
 D’après le patron de conception observateur/observable, la vue est un «observateur » du modèle qui est lui «observable. »
 Certains événements de l’utilisateur ne concernent pas les données mais la vue, dans ce cas, le contrôleur demande à la vue de se modifier. Le contrôleur n’effectue aucun traitement, ne modifie aucune donnée.
 Analyse la requête du client et se contente d’appeler le modèle adéquat et de renvoyer la vue correspondant à la demande.

Table des matières

Introduction
Chapitre 1: Lieu du Stage
1. Lieu du stage 
1.1. Historique
1.2. Missions et actifs
1.3. Ses missions
1.5. Ses défis
1.6. Secrétariat d’Etat chargé l’Eau et d’environnement
1.7. Organigramme du service informatique
2. Présentation détaillée de la révision des prix au service marché
3. Problématique
3.1. Conditions de révision
3.2. Modalités de calcul
3.3. Solutions
4. Les objectifs
Chapitre 2 : Analyse et Conception
Introduction
1. Déroulement du stage
2. La méthodologie d’analyse
2.1. Langage UML
2.2. Le Modèle en cascade
2.3. Le modèle MVC (Modèle Vu-Contrôleur)
3. Etude préliminaire – La modélisation du contexte
3.1. Les acteurs et leurs rôles
3.2. Les messages émis et reçus
4. Capture des besoins 
4.1. Diagramme de packages
4.2. Diagrammes des cas d’utilisation
4.3. Diagrammes de séquences
4.4. Diagramme de classes
5. Base de données
Conclusion

Télécharger le rapport complet