Intitulé du Master : MASTER PROFESSIONNEL en STIC

1ere année

Modélisation des applications

Web

Responsable: Dr. M. BOUZAHZAH

 Chapitre 02:
Construction des applications
web
 La construction d’une
application web( partie 01)
UML et la modélisation d’une
application web
 Introduction (1)
• La modélisation est un processus visuel
utilisé pour construire et documenter la
conception et la structure d'une application.
• C'est une bonne idée de faire au moins
quelques grandes lignes d'une application,
montrant les interdépendances et les
relations entre les composants et les sous-
systèmes, au cours du développement.
 Introduction (2)
• Les outils de modélisation facilitent ce
processus; lorsqu'un changement est apporté
au modèle, l'effet d'entraînement de ce
changement est indiqué.
• L'utilisation d'outils de modélisation donne
aux développeurs une vue de haut niveau de
ce qui pourrait représenter des milliers de
lignes de code.
 Concevoir une application
• Un obstacle majeur à une ingénierie réussie est
l’incapacité d’ analyser et de communiquer les
nombreuses activités d'interaction qui composent le
processus métier.
• Les langues conversationnelles s'avèrent trop ambiguës
pour être efficaces

• Ce qui est nécessaire est plutôt une technique qui

structure le langage conversationnel pour éliminer
l'ambiguïté, facilitant la communication et la
compréhension efficaces
 Pourquoi créer un modèle? (1)
• La modélisation est une technique efficace
pour la compréhension et la communication
qui a été utilisée pendant des siècles.
• Dans un modèle de processus, les détails
superflus sont éliminés, réduisant ainsi la
complexité apparente du système étudié
• Le détail restant est structuré pour éliminer
toute ambiguïté tout en mettant en évidence
des informations importantes.
 Pourquoi créer un modèle? (2)
• Les graphiques (images, lignes, flèches, normes
graphiques) sont utilisés pour fournir une grande
partie de la structure, de sorte que la plupart des
gens considèrent les modèles de processus comme
des représentations picturales.
• La modélisation du processus métier cible est une
première étape nécessaire dans le développement
d'une application
• Le modèle devient une carte routière qui établira
la destination finale
 Modélisation d'une application Web (1)

• Les applications Web deviennent de plus en

plus complexes et essentielles à la mission.
• La modélisation peut aider à gérer cette
complexité croissante.
• La norme actuelle pour la modélisation de
systèmes à forte composante logicielle est le
langage UML (Unified Modeling Language).
 Modélisation d'une application Web (2)

• Lors de la modélisation d'une application Web

avec UML, il devient évident que certains
composants ne correspondent pas
automatiquement aux éléments de modélisation
UML standard.
• Afin d'utiliser une seule notation de modélisation
pour un système complet comprenant des
composants Web et des composants de niveau
intermédiaire traditionnels, UML doit être
étendu.
 Le langage de modélisation unifié (1)
• La force d'UML est enracinée dans sa sémantique
ainsi que dans le méta-modèle qui constitue la
base des futures méthodes.
• Le méta-modèle est une couche d'une architecture
de méta-modelage à quatre couches.
• Le langage de modélisation unifié est un langage
de modélisation orienté objet permettant de
spécifier, de visualiser et de documenter les
artefacts d'un système orienté objet pendant le
développement.
 Le langage de modélisation unifié (2)
• UML est approprié pour les systèmes en temps
réel, fournissant un support pour les classes de
modélisation, les objets et les relations entre eux.
• Ces relations incluent l'association, l'agrégation,
l'héritage, la dépendance et l'instanciation.
• Les cas d'utilisation sont directement pris en
charge avec des scénarios pour des descriptions
détaillées du comportement du système requis.
 Le langage de modélisation unifié (3)
• Les scénarios de modèle sont représentés
graphiquement par des diagrammes d'interaction
qui peuvent inclure à la fois des annotations de
synchronisation et de synchronisation de
message.
• Les fonctionnalités en temps réel sont prises en
charge grâce à la modélisation améliorée des
machines à états finis, y compris la simultanéité,
la propagation d'événements et les états
imbriqués.
 Le langage de modélisation unifié (4)
• Les créateurs de l'UML ont réalisé qu'il n'est pas
toujours suffisant de capturer la sémantique
pertinente d'un domaine ou d'une architecture
particulière.
• un mécanisme d'extension formel a été défini afin
que les praticiens étendent la sémantique de
l'UML.
• Ce mécanisme permet de définir des stéréotypes,
des valeurs étiquetées et des contraintes qui
peuvent être appliquées aux éléments du modèle.
 Le langage de modélisation unifié (5)
• Un stéréotype permet de définir une
nouvelle signification sémantique pour un
élément de modélisation.
• Les valeurs marquées sont des paires de
valeurs clés pouvant être associées à un
élément de modélisation.
• Les contraintes sont des règles définissant la
meilleure façon d'exprimer un modèle:
 Les buts de l'UML (1)
• L'UML a sept objectifs:
1. Fournir aux utilisateurs un langage de
modélisation visuel expressif prêt à l'emploi pour
le développement et l'échange de modèles
significatifs
2. Fournir des mécanismes d'extensibilité et de
spécialisation afin d'étendre les concepts centraux
3. Être indépendant des langages de programmation
et des processus de développement spécifiques
 Les buts de l'UML(2)
4. Fournir une base formelle pour comprendre
le langage de modélisation
5. Encourager le développement du marché des
outils OO
6. Pour soutenir les concepts de développement
de plus haut niveau, y compris les
collaborations, les cadres, les modèles et les
composants
7. Intégrer les meilleures pratiques
 Les principes de l’UML (1)
• Un méta-modèle a été créé afin d'offrir une
déclaration commune et claire du modèle
sémantique de la méthode. Une fois ce
méta-modèle développé, des décisions sur la
syntaxe graphique de surface pour les
éléments visuels de ce modèle ont été
prises.
• Un certain nombre de principes pour guider
ces efforts ont été établis:
 Les principes de l’UML (2)
• Simplicité - Une méthode ne devrait nécessiter
que quelques concepts et symboles.
• Expressivité - Une méthode devrait être
applicable à une grande variété de systèmes de
qualité de production.
• Utilité - Une méthode doit uniquement se
concentrer sur des éléments significatifs pour
l'ingénierie système et logicielle.
 Les principes de l’UML (3)
• Problèmes courants: ils doivent être simples à modéliser.
Des problèmes plus rares doivent toujours être
exprimables, mais peuvent nécessiter une certaine
complexité correspondant à leur fréquence d'utilisation.
• Auto-consistance - Le même concept et le même
symbole doivent être utilisés de la même manière tout
au long de la méthode.
• Orthogonalité - Les concepts non liés doivent être
modélisés indépendamment.
 Les principes de l’UML (4)
• Concepts avancés- Les couches de concepts avancés
doivent être traitées comme des ajouts à la méthode
pour des concepts plus basiques.
• Stabilité - Les concepts et les symboles déjà compris et
utilisés doivent être adoptés.
• Imprimabilité - L'approche de la visualisation doit être
basée sur un format qui peut être étendu. Les
utilisateurs devraient être en mesure d'esquisser la
méthode manuellement ou de l'afficher en tant
qu'image imprimée.
 Les principes de l’UML (5)

• Adaptabilité - Les utilisateurs extensibles et les

constructeurs d'outils devraient avoir la
possibilité d'étendre et d'adapter la méthode
 Conventions e terminologie (1)
• En langage UML, l'explication de chaque
élément suit un modèle simple
• La sémantique du concept est décrite,
suivie de sa syntaxe graphique.
• Sémantique - Cette sous-section fournit
un bref résumé de la sémantique
 Conventions e terminologie (2)
• Notation - Cette sous-section explique la
représentation notationnelle du concept
sémantique
• Options de présentation: cette sous-section décrit
différentes options de présentation des
informations de modèle, telles que la possibilité
de supprimer ou de filtrer des informations,
d'autres manières de montrer des choses et
d'autres manières de présenter des informations
dans un outil.
 Les bases de l’UML2
• UML 2 s’articule autour de treize types de
diagrammes, chacun d’eux étant dédié à la
représentation des concepts particuliers d’un
système logiciel.
• Ces types de diagrammes sont répartis en
deux grands groupes
 Les diagrammes d’UML (1)
• Six diagramme structurels :
1. Diagramme de classe: Il montre les briques
de base statiques : classes, associations,
interfaces, attributs, opérations, généralisa-
tions, etc.
2. Diagramme d’objets - Il montre les instances
des éléments struc- turels et leurs liens à
l’exécution.
 Les diagrammes d’UML (2)
3. Diagramme de packages : Il montre
l’organisation logique du modèle et les
relations entre packages.
4. Diagramme de structure composite – Il
montre l’organisation interne d’un élément
statique complexe.
5. Diagramme de composants – Il montre des
structures complexes, avec leurs interfaces
fournies et requises.
 Les diagrammes d’UML (3)
6. Diagramme de déploiement – Il montre le déploiement
physique des « artefacts » sur les ressources matérielles.
• Sept diagrammes comportementaux :
1. Diagramme de cas d’utilisation - Il montre les
interactions fonc- tionnelles entre les acteurs et le
système à l’étude
2. Diagramme de vue d’ensemble des interactions - Il
fusionne les diagrammes d’activité et de séquence pour
combiner des fragments d’interaction avec des décisions
et des flots.
 Les diagrammes d’UML (4)
3. Diagramme de séquence - Il montre la séquence
verticale des mes- sages passés entre objets au
sein d’une interaction.
4. Diagramme de communication - Il montre la
communication entre objets dans le plan au sein
d’une interaction.
5. Diagramme de temps – Il fusionne les
diagrammes d’états et de séquence pour montrer
l’évolution de l’état d’un objet au cours du temps.
 Les diagrammes d’UML (5)

6. Diagramme d’activité - Il montre

l’enchaînement des actions et décisions au
sein d’une activité.
7. Diagramme d’états – Il montre les différents
états et transitions possibles des objets d’une
classe.
 Les diagrammes d’UML (6)
• Le diagramme de packages montre l’organisation
logique du modèle et les relations entre
packages. Il permet de structurer les classes
d’analyse et de conception, mais aussi les cas
d’utilisation.
 Les diagrammes d’UML (7)
• Les diagrammes de communication
représentent des échanges de messages entre
éléments, dans le cadre d’un fonctionnement
particulier du système.
 Les diagrammes d’UML (8)
• Le diagramme d’états représente le cycle de vie
commun aux objets d’une même classe. Ce
diagramme complète la connaissance des
classes en analyse et en conception en
montrant les différents états et transitions
possibles des objets d’une classe à l’exécution.
 Les diagrammes d’UML (9)
• Le diagramme d’objets est un instantané, une
photo d’un sous-ensemble des objets d’un
système à un certain moment du temps.
 Les diagrammes d’UML (10)
• Le diagramme de composants montre les
unités logicielles à partir desquelles on a
construit le système informatique, ainsi que
leurs dépendances.
 Les diagrammes d’UML (10)
• Le diagramme de vue d’ensemble des interactions
fusionne les diagrammes d’activité et de séquence pour
combiner des fragments d’inte- raction avec des
décisions et des flots.
• Le diagramme de temps fusionne les diagrammes
d’états et de séquence pour montrer l’évolution de l’état
d’un objet au cours du temps et les messages qui
modifient cet état.
• Le diagramme de structure composite montre
l’organisation interne d’un élément statique complexe
sous forme d’un assemblage de parties, de connecteurs
et de ports.
Les diagrammes UML utilisés pour la
modélisation d’une application web
 Un processus simplifié pour les
applications Web
• Un processus définit une séquence d’étapes,
partiellement ordonnées, qui concourent à l’obtention
d’un système logiciel ou à l’évolution d’un système
existant.
• L’objet d’un processus de développement est de produire
des logiciels de qualité qui répondent aux besoins de leurs
utilisateurs dans des temps et des coûts prévisibles.
• Un processus doit permettre de répondre à la question
fondamentale : « Qui fait quoi et quand ? ».
• Le processus à suivre pour le développement
d’applications web se situe à mi-chemin entre UP (Unified
Process) et les méthodes agiles.
 Le processus unifié UP (1)
• Un processus de développement logiciel « itératif et
incrémental, centré sur l’architecture, conduit par les cas
d’utilisation et piloté par les risques »

• Itératif et incrémental : le projet est découpé en itérations

de courte durée qui aident à mieux suivre l’avancement
global.

• À la fin de chaque itération, une partie exécutable du

système final est produite, de façon incrémentale.
 Le processus unifié UP (2)
(Les principes)
• Centré sur l’architecture : tout système complexe doit être
décomposé en parties modulaires afin de garantir une
maintenance et une évolution faciles. Cette architecture
(fonctionnelle, logique, matérielle, etc.) doit être modélisée
en UML
• Piloté par les risques : les risques majeurs du projet doivent
être identifiés au plutôt, mais sur tout levés le plus
rapidement possible. Les mesures à prendre dans ce cadre
déterminent l’ordre des itérations.
• Conduit par les cas d’utilisation : le projet est mené en tenant
compte des besoins et des exigences des utilisateurs. Les cas
d’utilisation du futur système sont identifiés, décrits avec
précision et priorisés.
 Le processus unifié UP (2)
(Les phases)
• Le processus est organisée suivant les
quatre phases suivantes : initialisation,
élaboration, construction et transition.
• La phase d’initialisation conduit à définir la «
vision » du projet, sa portée, sa faisabilité,
son business case, afin de pouvoir décider au
mieux de sa poursuite ou de son arrêt.
 Le processus unifié UP (3)
(Les phases)
• La phase d’élaboration poursuit trois objectifs
principaux en parallèle :
1. Identifier et décrire la majeure partie des
besoins des utilisateurs.
2. Construire l’architecture de base du système.
3. lever les risques majeurs du projet.
 Le processus unifié UP (4)
(Les phases)
• La phase de construction consiste surtout à concevoir
et implémenter l’ensemble des éléments
opérationnels
• la phase de transition permet de faire passer le
système informatique des mains des développeurs à
celles des utilisateurs finaux. Les mots-clés sont :
conversion des données, formation des utilisateurs,
déploiement, béta-tests.
• Le résultat de chaque phase est un système testé,
intégré et exécutable.
 Les principes de la méthode Agile(1)
• « Personnes et interactions plutôt que processus
et outils » : dans l’optique agile, l’équipe est bien
plus importante que les moyens matériels ou les
procédures.
• « Logiciel fonctionnel plutôt que documentation
complète » : il est vital que l’application
fonctionne. Le reste, et notamment la documen-
tation technique, est secondaire, même si une
documentation succincte et précise est utile
comme moyen de communication.
 Les principes de la méthode Agile(2)
• « Collaboration avec le client plutôt que
négociation de contrat » : leclient doit être
impliqué dans le développement. On ne peut se
con- tenter de négocier un contrat au début du
projet, puis de négliger les demandes du client.
• « Réagir au changement plutôt que suivre un
plan » : la planification ini- tiale et la structure
du logiciel doivent être flexibles afin de
permettre l’évolution de la demande du client
 La démarche de modélisation d’une
application web (1)

Cas d’utilisation
Diagrammes de séquence
système

Besoins
utilisateurs

Diagrammes d’interaction
Diagrammes de classes
participantes

Diagrammes de classes de
Maquette Diagrammes de navigation conception Code
 La démarche de modélisation d’une
application web (2)
• Les besoins donnent lieu aux cas d’utilisation et à une
maquette
• Une maquette est un produit jetable donnant aux
utilisateurs une vue concrète mais non définitive de la
future interface de l’application. Cela peut consister en
un ensemble de dessins réalisés avec des outils
spécialisés tels que Dreamweaver, Adobe Illustrator ou
plus simplement avec Powerpoint ou même Word.
• La maquette intégrera des fonctionnalités de navigation
pour que l’utilisateur puisse tester l’enchaînement des
écrans, même si les fonctionnalités restent fictives.
 La démarche de modélisation d’une
application web (3)
• Les diagrammes de classes de conception
représentent bien la structure statique du code, par
le biais des attributs et des relations entre classes.
• Les diagrammes d’interaction nous aident à
attribuer les responsabilités aux classes.
• Chaque cas d’utilisation est décrit textuellement de
façon détaillée, mais donne également lieu à un
diagramme de séquence simple représentant
graphiquement la chronologie des interactions
entre les acteurs et le système
 La démarche de modélisation d’une
application web (4)
• les diagrammes de classes participantes décrivent,
cas d’utilisation par cas d’utilisation, les trois
principales classes d’analyse et leurs relations : les
dialogues, les contrôles et les entités.
• Les classes qui permettent les interactions entre le
site web et ses utilisateurs sont quali- fiées de «
dialogues ». C’est typiquement les écrans proposés
à l’utilisateur : les formu- laires de saisie, les
résultats de recherche, etc. Elles proviennent
directement de l’analyse de la maquette.
 La démarche de modélisation d’une
application web (5)
• Les classes qui contiennent la cinématique de
l’application seront appelées « contrôles ». Elles font la
transition entre les dialogues et les classes métier, en
permettant aux écrans de manipuler des informations
détenues par un ou plusieurs objet(s) métier.
• Les classes qui représentent les règles métier sont
qualifiées d’« entités ». Elles proviennent
• directement du modèle du domaine, mais sont
confirmées et complétées cas d’utilisation par cas
d’utilisation.
 Conclusion
• Ce chapitre cite les différentes étapes à suivre
pour la modélisation d’une application web
• C’est étapes seront détaillées durant les
séances du TDs