CHAPITRE II : CONCEPTION
I. INTRODUCTION Bibliographie [II]
L'approche objet est incontournable dans le cadre du
développement de systèmes logiciels complexes, capables de suivre
les évolutions incessantes des technologies et des besoins applicatifs.
Cependant, la programmation objet est moins intuitive que la programmation
fonctionnelle. En effet, il est plus naturel de décomposer les
problèmes informatiques en termes de fonctions qu'en termes d'ensembles
d'objets en interaction. De ce fait, l'approche objet requiert de
modéliser avant de concevoir. La modélisation apporte une grande
rigueur, offre une meilleure compréhension des logiciels, et facilite la
comparaison des solutions de conception avant leur développement. Cette
démarche se fonde sur des langages de modélisation, qui
permettent de s'affranchir des contraintes des langages
d'implémentation.
Le besoin d'une méthode de description et de
développement de systèmes, prenant en compte à la fois les
données et les traitements, a grandi en même temps que la taille
des applications objet. Au milieu des années 90, plusieurs dizaines de
méthodes objet sont disponibles, mais aucune ne prédomine.
L'unification et la normalisation des trois méthodes dominantes,
à savoir Booch, du nom de son auteur, OOSE (Object Oriented Software
Engineering), d'IvanJacobson et OMT (Object Modeling Technique), de James
Rumbaugh, sont à l'origine de la création du langage UML (Unified
Modeling Language).
UML est une notation graphique conçue pour
représenter, spécifier, construire et documenter les
systèmes logiciels. Ses deux principaux objectifs sont la
modélisation de systèmes utilisant les techniques
orientées objet, depuis la conception jusqu'à la maintenance, et
la création d'un langage abstrait compréhensible par l'homme et
interprétable par les machines.
UML s'adresse à toutes les personnes chargées de
la production, du déploiement et du suivi de logiciels (analystes,
développeurs, chefs de projets, architectes...), mais peut
également servir à la communication avec les clients et les
utilisateurs du logiciel. Il s'adapte à tous les domaines d'application
et à tous les supports. Il permet de construire plusieurs modèles
d'un système, chacun mettant en valeur des aspects différents :
fonctionnels, statiques, dynamiques et organisationnels. UML est devenu un
langage incontournable dans les projets de développement.
Une méthode de développement définit
à la fois un langage de modélisation et la marche à suivre
lors de la conception. Le langage UML propose uniquement une notation dont
l'interprétation est définie par un standard, mais pas une
méthodologie complète. Plusieurs processus de
développement complets fondés sur UML existent, comme le Rational
Unified Process (RUP), de Booch, Jacobson et Rumbaugh, ou l'approche MDA (Model
Driven Architecture) proposée par l'OMG, mais ils ne font pas partie du
standard UML.
UML intègre de nombreux concepts permettant la
génération de programmes. C'est un langage de modélisation
fondé sur des événements ou des messages. Il ne convient
pas pour la modélisation de processus continus, comme la plupart des
procédés en physique. Ce n'est pas un langage formel, ni un
langage de programmation. Il ne peut pas être utilisé pour valider
un système, ni pour générer un programme exécutable
complet. Mais, il permet de produire des parties de code, comme le squelette
des classes (attributs et signatures de méthode).
Même si la version 2 apporte des avancées
significatives au niveau du formalisme, UML n'a pas encore atteint la rigueur
syntaxique et sémantique des langages de programmation.
UML est le résultat d'un large consensus,
continuellement enrichi par les avancées en matière de
modélisation de systèmes et de développement de logiciels.
C'est le résultat d'un travail d'experts reconnus, issus du terrain. Il
couvre toutes les phases du cycle de vie de développement d'un
système et se veut indépendant des langages
d'implémentation et des domaines d'application.
UML 2
UML 2 apporte des évolutions majeures par rapport
à UML 1.5, sans toutefois être révolutionnaire : les
principales fonctionnalités de base se ressemblent. Au niveau du
métamodèle, qui concerne surtout les développements
d'outils, UML 2 se rapproche davantage des standards de modélisation
objet proposés par l'OMG. En particulier, l'unification du noyau UML et
des parties conceptuelles de modélisation MOF ( Meta-Object Facility )
permet aux outils MOF de gérer les modèles UML ; l'ajout du
principe de profils permet de mieux définir les extensions du domaine ;
enfin, la réorganisation du métamodèle UML élimine
les redondances présentes dans les versions précédentes
(voir la fin de l'ouvrage pour plus de détails concernant la
structuration du langage UML).
Du point de vue de l'utilisateur, les changements concernent
certaines notations. La notation des diagrammes de séquence se rapproche
de la norme d'échanges de messages MSC
(Message Sequence Chart) de l'IUT (Union Internationale des
Télécommunications). Le concept de classeurs s'inspire des
avancées de l'ingénierie temps réel du langage de
description et de spécification SDL. De plus, UML 2 unifie la
modélisation des activités et la modélisation des actions
introduites dans UML 1.5 et utilise des notations de modélisation de
processus métier. Des éléments de modélisation
contextuels améliorent la souplesse et formalisent mieux le concept
d'encapsulation des classes et des collaborations.
Figure 5 : Organisation en quatre couches du langage
UML.
II. DIAGRAMME DE CAS D'UTILISATION :
1. CAS D'UTILISATION
Définition : Un cas d'utilisation est
une manière spécifique d'utiliser un système. Les acteurs
sont à l'extérieur du système ; ils modélisent tout
ce qui interagit avec lui. Un cas d'utilisation réalise un service de
bout en bout, avec un déclenchement, un déroulement et une fin,
pour l'acteur qui l'initie.
Les cas :
· saisir bil-ment d'énergie : : saisir bilan mensuel
d'énergie
· envoyer bil-ment d'énergie : envoyer bilan mensuel
d'énergie
· consulter bil-ment d'énergie : consulter bilan
mensuel d'énergie
· modifier bil-jour de centre : modifier bilan journalier
de centre
· saisir bil-jour de centre : saisir bilan journalier de
centre
· envoyer bil_jour de centre : envoyé bilan
journalier de centre
· consulter bil-jour de centre consulter bilan journalier
de centre
· envoyer bil-jour de STEP : envoyer bilan journalier de
STEP
· modifier bil-jour de STEP : modifié bilan
journalier de STEP
· saisir bil-jour de STEP : saisir bilan journalier de
STEP
· consulter bil-jour de STEP : consulter bilan journalier
de STEP
· envoyer bil-men d'unité : envoyer bilan journalier
de d'unité
· consulter bil-men d'unité : consulter bilan
journalier de d'unité
· envoyer avis : vérifier consolider des bilans
· authentification : cas interne pour l'identification
· chercher : cas interne de recherche du bilan
34 ACTEURS
| 
