DUT SI Modelisation Partie 2

3.
Systèmes d’Information Web
La méthode UWE
1
Plan
 3.0 Un premier exemple d’application web
 3.1 Introduction à La méthode UWE
 3.2 Les étapes de la méthode
 3.3 Un deuxième exemple
 3.4 Modélisation des besoins fonctionnels
 3.5 Modélisation des contenus
 3.6 Modélisation de la navigation
 3.7 Modélisation de la présentation
 3.8 Modélisation de l’adaptation
2
3.0 Un premier exemple
d’application web
3
a. Le contexte
 Le site « monfournisseur.com » est le moteur de
recherche et de comparaison des prix sur Internet
dédiée aux libres services de proximité, un service
unique pour les consommateurs.
 Il permet de:
• Rechercher des produits
• Rechercher un fournisseur
• Comparer les prix
• Lancer des appels d’offre
• Prendre contact avec le fournisseur pour s’y rendre
4
b. Diagramme de cas d’utilisation
5
c. L’ internaute
 Il pourra rechercher les prix pratiqués par
des fournisseurs d’un produit spécifique en
effectuant :
• Une recherche directe (par mots clé)
• Une recherche guidée par catégorie (boissons,
luminaires...)
 Consulter les coordonnées des
fournisseurs (adresse, téléphone, mail…)
6
d. Le client
 Déposer des appels d’offre (le client peut

déposer une demande auprès des
fournisseurs pour un achat particulier, ex. :
un gros achat).
 Créer des favoris (c’est-à-dire, classer les
produits avec leurs fournisseurs par
préférence)
 Gérer son compte client
7
e. Le fournisseur
 Gérer ses produits (ajouter, supprimer,

modifier)
 Consulter les appels d’offres
 Gérer son compte fournisseur
8
Diagramme de classes
9
g. Diagramme de la structure de
navigation (acteur fournisseur)
10
h.Diagramme d’accès
(acteur fournisseur)
11
i. Diagramme de présentation
(acteur fournisseur)
12
UML: UnifiedModelingLanguage
 Diagramme de cas d’utilisation: fonctions du système du point de vue de

 l’utilisateur
 • Diagramme de classes: structure statique en termes de classes et de relations
 • Diagramme de séquence: représentation temporelle des objets et de leurs
 interactions
 • Diagramme de collaboration: représentation spatiale des objets, des liens et des
 interactions
 • Diagramme d’objets : Objets et leurs relations. Diagrammes de collaboration
 simplifiés, sans représentation des envois de message
 • Diagramme d’états-transitions: comportement d’une classe en terme d’états
 (Statecharts) [Harel, D. 1987. Statecharts: A Visual Formalism for Complex Systems.
 Science of Computer Programming vol. 8. ]
 • Diagramme d’activités: comportement d’une opération en termes d’actions
 • Diagramme de déploiement: déploiement des composants sur les dispositifs
 matériels
 • Diagrammes de composants: composants physiques d’une application.
13
3.1. Introduction à UWE (1)
 UWE : UML-based Web Engineering
 Définie par N. Koch et R. Hennicker
 Modélisation d’applications hypermédia fondées sur le web
 Utilise un profil d’UML
 Reprend la démarche du processus unifié de Jacobson
 Couvre tout le cycle de développement des applications
web
 Repose sur un méta-modèle, appelé Munich Reference
Model, formalisant les principes de fonctionnement des
applications web
 La méthode est accompagnée d’un outil : ArgoUWE
14
3.1. Introduction à UWE (2)
 Profils et Stéréotypes UML

• UML peut être adapté pour être un langage spécifique d’un
domaine (Domain Specific Language-DSL), appelé UML-Profile
• Les extensions spécifiques au domaine sont appelés les

STEREOTYPES, notées « stereotypes »
• Les stéréotypes représentent une extension des méta-classes

UML
• Avec des méta-attributs additionnels appelés « tags »
• Avec des contraintes additionnelles
15
3.2 Les étapes de la méthode
• Modélisation des besoins fonctionnels

• Diagramme des cas d’utilisation
• Diagramme d’activités
• Modélisation du contenu
• Diagramme de classes
• Diagramme d’états
• Modélisation de la navigation
• Diagramme de la structure de navigation
• Diagramme d’accès
• Modélisation de la présentation
• Modèle statique
• Modèle dynamique
• Modélisation de l’adaptation
16
3.3. Un deuxième exemple
 Système d’évaluation d’articles soumis à une conférence

scientifique
 Les acteurs
• Les utilisateurs du système
• Auteurs qui soumettent un article
• Membres du comité de programme qui évaluent les articles
• Le président du comité de programme
 Les besoins fonctionnels
• Soumettre un article
• Affecter un article à des évaluateurs
• Produire une évaluation
• Produire la liste des articles acceptés/refusés
17
 UnifiedModelingLanguage
 Langage unifié pour la modélisation objet
 J. Rumbaugh, G. Booch, I. Jacobson
18
3.4- Modélisation des besoins
fonctionnels (1)
 Fondée sur les vues utilisateurs (acteurs)

 Modélisés par les cas d’utilisation UML
 Affinés par les diagrammes d’activités UML
 Deux types de besoins pris en compte:
• Fonctionnels (comme pour les SI classiques)
• Navigationnels (spécifiques aux SI web)
19
3.4. Modélisation des besoins
fonctionnels (2)
 L’analyse des besoins suit le processus unifié
 Elle identifie les besoins fonctionnels des différents utilisateurs
 Les notions d’acteurs, les relations d’inclusion et d’extension
entre cas d’utilisation, les mécanismes de paquetage et de
vues conservent la sémantique d’UML
 Les notations graphiques sont celles d’UML2
 Des relations d’extension peuvent être définies entre cas
d’utilisation
 Des relations d’héritage peuvent être définies entre acteurs
20
3.4- Modélisation des besoins
fonctionnels (3) : « use cases »
login
 Exemple « extend »
register submit paper

User
« navigation »
browse review results
Author set preferences
Reviewer enter review

« navigation »
assign paper to reviewer list accepted/rejected
« extend »
papers
« navigation »
browse submitted papers « include»
PC chair
close reviewing process
21
fonctionnels (4): Diagramme d’activités
 Modélisation UML
 A réaliser pour chaque processus
22
fonctionnels (5): diagramme d ’activités
 Exemple : « submit paper » pour l’acteur « Author »
[user logged-in] enter title select select

[user not and abstract subject group paper location
logged-in]
[not complete]
login
[ok]
« datastore » upload send
Paper [new] paper notification
23
3.5. Modélisation des contenus (1)
 Aspects structurels
• Modélisation du domaine
• Diagramme de classes UML
 Aspects comportement
• Dépend du type et de la complexité de l’application
• Diagramme d’états/diagramme d’interactions
 Attention!!!
• On ne présente que le contenu d’un niveau
• Pas d’hypertexte ou de modélisation de la présentation
24
diagramme de classes
 Trouver les classes, indiquer les attributs et les
opérations, définir les structures hiérarchiques
 On utilise les concepts d’agrégation, de
composition, de généralisation et spécialisation
 Les classes et les associations sont décrites par
les attributs et les opérations (méthodes)
 Les classes et les associations peuvent être
organisées en paquetages UML
25
3.5. Modélisation des contenus(3):
 On représente la sémantique de l’application
hypermédia en considérant aussi les aspects
navigationnels et présentationnels => les
classes sont équipées d’un compartiment
optionnel qui s’ajoute à celui des attributs et
des opérations
 Ce compartiment peut recevoir des
informations adaptant le contenu de la classe
au profil utilisateur
 Ce modèle sert à créer des diagrammes
supplémentaires décrivant notamment la
navigation
26
3.5. Modélisation des contenus(4)
diagramme de classes UML
Conference
 Exemple : name * +user
submissionDate
Subject User
1..* reviewDate
name notificationDate name
description status organization
email
système 1..*
conferenceDate 1
login
newConference( )
de « reviewing » closeReviewing( )
passwd
+author loggedIn
* register( )
* *
Paper
0..3 +reviewer
Review paperID *
title +assignedPapers
originality abstract
0..3
technicalQuality url inv:
relevance +review reviewer.intersection(author) -> isEmpty
status
overallRating /result
entered( ) upload( )
assign( )
result = avg(review.overallRating)
submit
CameraReady( ) 27
3.5. Modélisation des contenus (5):
diagramme d’états
 Modélisation UML
 A réaliser pour le cycle de vie de l’objet
considéré
 Vérifier la cohérence avec le modèle de
classes
28
diagramme d’états UML
 Exemple : cycle de vie d’un papier (pour la classe papier)
assign( )
[#reviewers<3] submitCameraReady( )
created accepted
[result >= threshold]
upload( )
assigned reviewed inPrint

submitted
[date= [#reviewers=3]
(Conference.submissionDate + 1]
[result <
threshold] rejected
29
3.5- Modélisation des contenus (7)
Paper
 Exemple : paperID Cohérence avec le
title
abstract diagramme de classes
url
status
UML
/result
upload( )
assign( )
submit
CameraReady( )
assign( )
[#reviewers<3] submitCameraReady( )
created accepted
[result >= threshold]
upload( )
assigned reviewed inPrint

submitted
[date= [#reviewers=3]
(Conference.submissionDate + 1]
[result <
threshold] rejected
30
3.6. Modèles de navigation (1)
 Deux modèles :
• Diagramme de la structure de navigation qui
définit le QUOI (les objets visités)
• Diagramme d’accès qui définit le COMMENT
(ils sont visités)
 La modélisation est organisée en
NŒUDS et LIENS
• Les nœuds sont les objets
• Les liens relient les objets
31
3.6. Modélisation de la navigation(2)
 Objectifs
• Modélisation des nœuds et des liens de la structure de navigation
• Un nœud est appelé page ou document
• Modélisation des parcours de navigation
 Résultats
• Modèle de la structure de navigation:
• quelles classes du modèle de contenu peuvent être visitées par
navigation?
• Modèle d’accès:
• Affiner le modèle de la structure de navigation en y ajoutant les
éléments relatifs aux accès
• Pour chaque rôle utilisateur (acteur et ses use cases), développer
la structure de navigation et le modèle d’accès
32
3.6. Modélisation de la navigation (3)
 3.6.1. Structure de navigation

• « classes de navigation » pour les noeuds
• « liens de navigation » pour les liens
 3.6.2.Structure d’accès
• « « menu » » accès aux nœuds de classes différentes
• « « index » » accès aux nœuds individuels d’une classe
• « « guidedTour » » accès séquentiel à une liste de nœuds
• « « query » » recherche d’un nœud et accès direct
33
3.6.1.
Le diagramme de la structure de
navigation (1)
 Indique les classes du diagramme de classes qui peuvent être
visitées lors de la navigation
 Composé d’un ensemble de classes et d’associations de
navigation obtenues à partir du diagramme de classes
 Une classe de navigation est définie comme une classe
stéréotypée « classe de navigation » avec le même nom que la
classe correspondante du diagramme de classes
 Elle modélise une classe dont les instances (appelées objets
de navigation) sont visitées par l’utilisateur
 Les objets de navigation sont reliés en termes UML par des
liens qui représentent les instances des associations du
modèle de classe de navigation
34
3.6.1. diagramme de la structure
de navigation (2)
 Le modèle de classe de navigation peut être
vu comme un sous-graphe du diagramme de
classes
 Les classes non nécessaires à la navigation
sont éliminées, ou réduites à des attributs
d’autres classes. On utilise la notion
d’attribut dérivé noté /nomattribut. Les
valeurs de ces attributs sont calculables à
partir d’une expression OCL.
35
3.6.1 le diagramme de la
structure de navigation (3)
 Une association de navigation exprime une
possibilité d’accès direct à une classe de
navigation « cible » à partir d’une classe de
navigation « source ».
 Les associations du diagramme de classes
sont transformées en associations de
navigation (il faut alors que les classes du
diagramme de classes aient une
correspondance dans le modèle de la
structure de navigation)
36
3.6.1. Le diagramme de la
 Des associations de navigation peuvent être
créées pour offrir un accès direct à certaines
informations. Il faut alors:
• Préciser la sémantique associée
• Préciser la façon d’obtenir la ou les classes de
navigation cibles associées
37
3.6.1. Le diagramme de la structure
de navigation (5): Méthode
 Les classes et les associations de
navigation sont représentées
graphiquement dans un diagramme de
classes UML appelé « diagramme de
classes de navigation »
 La navigabilité est indiquée pour une
association par une flèche située à
l’extrémité de la ligne de cette
association
38
3.6.1. Le diagramme de la structure
 Si une flèche est localisée aux deux
extrémités de l’association, l’utilisateur
peut se diriger dans les deux directions
 Chaque lien comporte une « source » et
une « cible » navigationnelles
 Chaque extrémité de l’association
navigationnelle est renseignée à l’aide
d’une multiplicité explicite et
éventuellement d’un nom de rôle
39
3.6.1. Le diagramme la structure
 Si aucun nom de rôle ne peut être
donné, alors on utilise la règle suivante:
• Si la multiplicité de la classe cible est égale à
1, alors le nom de rôle donné est celui de la
classe
• Si la multiplicité de la classe cible est
supérieure à 1, alors le nom de rôle donné est
celui de la classe mais avec la marque du
pluriel
40
3.6.1. Diagramme de la
 Règles de détermination du modèle de la structure de

navigation
• Définir une classe de navigation pour chaque classe du

• Définir des liens de navigation pour les associations, agrégations
et compositions du diagramme de classes
• Ajouter les multiplicités et les noms de rôle existants dans le
• Ajouter des liens de navigation supplémentaires du fait de scénarii
relatif à l’analyse des besoins
• Ajouter des liens de navigation supplémentaires comme raccourcis
(Shortcuts)
41
3.6.1. Règles de génération du
modèle de navigation (9)
Contenu Navigation Accès Présentation
« classe » « classe de nœud objet de
navigation », nœud présentation
« liens » « lien de navigation » index, menu, query,

guidedTour
lien 1---1 *
« index » accès aux nœuds
individuels d’une classe Page Web
Index de B
lien *----*
42
3.6.1. Règles de génération des
modèles (10)
« menu » accès aux nœuds

de classes différentes
Page Web
Choix B Choix C
Index de B
Index de C
43
3.6.1. Diagramme de la structure de
la navigation (11): deuxième exemple
« navigation link » 1 1
 Exemple : 1
« navigation class » « navigation link »
Conference
« navigation link »
1
paper user *
acceptedPapers * « navigation link » 1..*
« navigation class » author « navigation class »
rejectedPapers * * « navigation link »
Paper User
* assignedPapers
* paper reviewer *
Vue du « navigation link » « navigation link »
PC chair * review « navigation link »
sur le système « navigation class »
Review *
de « reviewing » review « navigation link »
44
3.6.2. Le diagramme d’accès (1)
 A définir à partir du diagramme de la structure de
navigation
 Détermine comment les objets de navigation sont
visités
 Des éléments additionnels sont exigés pour exécuter
la navigation: ce sont des primitives d’accès
 Primitives d’accès: menus, index, visites guidées,
nœuds externes
 Il faut définir aussi les contextes de navigation
45
3.6.2. Le diagramme d’accès (2):
les primitives d’accès
 Un menu est un objet composite qui
contient un nombre fixe d’items. Chacun
d’entre eux a un nom et possède un lien
vers une instance de classe de
navigation ou un élément d’accès
46
 Une tour guidée donne accès au
premier objet d’un contexte de
navigation. Le déplacement d’un objet à
l’autre est dirigé séquentiellement. Le
tour guidé peut être commandé par
l’utilisateur ou par le système.
47
 Un index est un objet composite qui
contient un nombre arbitraire d’articles
d’index.
 Chaque article d’index est un objet qui
possède un lien vers une instance de
classe de navigation
 Il est membre d’une classe d’index qui
en définit la structure
48
 Une question est un objet qui a un
attribut composé d’une chaîne de
caractères correspondant à une query.
 La query peut être spécifiée sous forme
OCL.
49
 Un nœud externe est un nœud de
navigation appartenant à une autre
application hypermédia
 Permet de se déplacer vers une autre
application à travers le web via une
adresse URL
50
Règles de transformation pour permettre le
passage du modèle de structure de
navigation à celui du diagramme d’accès:
• Remplacer les associations de navigation bi-
directionnelles dont la multiplicité à chacune des
deux extrémités est supérieure à 1 par deux
associations de navigation uni-directionnelles
• Remplacer les associations de navigation bi-
directionnelles dont la multiplicité à l’une des deux
extrémités est supérieure à 1 par une association
de navigation uni-directionnelle orientée vers
l’extrémité de multiplicité supérieure à 1
51
Règles de transformation pour permettre le
passage du modèle de structure de navigation à
celui du diagramme d’accès (suite)
. Pour les associations unidirectionnelles du modèle
de structure de navigation ayant une multiplicité
supérieure à 1 du côté de l’extrémité qui porte la
flèche, choisir une ou plusieurs primitives d’accès
pour concrétiser la navigation. Les primitives d’accès
sont insérées entre la classe de navigation cible. Le
nom de rôle migre vers le niveau de l’élément
représentant la primitive
52
3.6.2. Diagramme d’accès(9):
Démarche de construction
 Autre formulation de la démarche:
• Introduire un index pour tous les liens de
navigation ayant une multiplicité supérieure à 1
• Introduire un menu pour chaque classe ayant
plus d’un lien de navigation sortant
• Utiliser les noms de rôle des liens de navigation
sortants comme des items de menu
53
modèles (10)

guidedTour
lien 1---1 *
Index de B
lien *----*
54
modèles (11)
Page Web
« guidedTour » accès séquentiel Page Web
à une liste de nœuds Page Web
« query » recherche d’un nœud

et accès direct Page Web
Query ….
Index de B
55
3.6.2 Règles de génération des
modèles (12)

Page Web
Choix B Choix C
Index de B
Index de C
56
« navigation class »
Conference
 3.6.2 Modèle
reviewd’accès (13): « menu » user
Conference
Menu
papers « index »
acceptedPapers UserIndex
« menu »
rejectedPapers Paper
Menu
search *
« query » « navigation class »
« index » SearchPaperByTitle User
AcceptedPapers searchPapers *
« index » « index »
« index » PapersByTitle PapersByID
RejectedPapers
* *
* « navigation class » * « index »
* Paper AssignedPapers
« index » « index » reviews « menu » authors « index »

ReviewingStatus Reviews PaperMenu Authors
*
Review ReviewedPapers
57
3.6.2- modélisation de la navigation (14):
cohérence des diagrammes de navigation et d’accès
« navigation link » 1..*

« navigation class » « navigation class »
Paper * « navigation link » author
User
 Exemple
assignedPapers
* paper reviewer *
« navigation link » User
* review « navigation link » *
Review *
review « navigation link »
Cohérence du modèle « navigation class » * « index »

Paper AssignedPapers
de structure
hypertexte « index » reviews « menu » authors « index »
Reviews PaperMenu Authors
et du modèle
d’accès *
« navigation class » * « index »
58
le contexte de navigation
 Se compose d’une séquence de nœuds de
navigation sur lesquels il impose une méthode
de parcours
 Dans un même contexte, des liens relient
chaque nœud de navigation au précédent et
au suivant
 Un contexte de navigation est dépeint comme
un objet avec le stéréotype «contexte de
navigation »
 Il est associé à une contrainte OCL qui définit
sa séquence de nœuds de navigation
 Les changements de contexte sont possibles
59
 Les types de contexte sont :
• Contexte de navigation simple
• Ex: tout le projet à partir des projets par noms
• Contexte de navigation groupé : séquence
extraite des séquences de nœuds de
navigation
• Ex: des projets par département
• Contexte de navigation filtré : choix
dynamique d’une collection d’éléments tirés
d’un contexte
60
3.6.2. Le diagramme d’accès(19):
 La notation pour les différents contextes

de navigation n’est pas imposée.
 Elle peut être adaptée à l’environnement
61
3.6.2. le diagramme d’accès (20):
 Les contextes d’une même classe de
navigation peuvent être groupés dans un
paquet UML appelé contexte
 Ils peuvent être reliés par des associations
spéciales qui indiquent les changements
de contexte de navigation possibles. Une
association stéréotypée est définie et est
appelée « changement »
62
3.6.2. Retour sur le deuxième exemple (21)
diagramme de classes UML
Conference
 Exemple : name * +user
submissionDate
Subject User
1..* reviewDate
name notificationDate name
description status organization
email
système 1..*
conferenceDate 1
login
newConference( )
de « reviewing » closeReviewing( )
passwd
+author loggedIn
* register( )
* *
Paper
0..3 +reviewer
Review paperID *
title +assignedPapers
originality abstract
0..3
technicalQuality url
relevance +review
status
overallRating /result
entered( ) upload( )
assign( )
submit
CameraReady( ) 63
3.6.2. Retour sur le deuxième exemple (22)
Diagramme de la structure de la navigation
« navigation link » 1 1
 Exemple : 1
« navigation class » « navigation link »
Conference
1
paper user *
acceptedPapers * « navigation link » 1..*
« navigation class » author « navigation class »
rejectedPapers * * « navigation link »
Paper User
* assignedPapers
* paper reviewer *
Vue du « navigation link » « navigation link »
PC chair * review « navigation link »
sur le système « navigation class »
Review *
de « reviewing » review « navigation link »
64
Conference
 3.6.2. Diagramme
review d’accès (23) « menu » user
Conference
Menu
papers « index »
acceptedPapers UserIndex
« menu »
rejectedPapers Paper
Menu
search *
« query » « navigation class »
« index » SearchPaperByTitle User
AcceptedPapers searchPapers *
« index » « index »
« index » PapersByTitle PapersByID
RejectedPapers
* *
* Paper AssignedPapers
« index » « index » reviews « menu » authors « index »

ReviewingStatus Reviews PaperMenu Authors
*
65
3.6.2. Modélisation de la Modèle de
présentation (24) présentation
statique
 Exemple : Pages de présentation du système de « reviewing »
« page » « page »
PaperPage AuthorPage
« presentation unit »
« presentation unit » « presentation unit »
Paper AuthorList Author
« text » « text » « text »
« anchor »
PaperID SubmissionDate Name
Author1
« text » « text »
Title « anchor » Affiliation
« text » Author2 « text »
Abstract E-mail
...
« anchor » « button »
FullVersion(Pdf) SubmitReview
« button »
« anchor »
Authors SubmitChanges
66
3.7. Modélisation de la présentation (1)
 Objectif:
• Représentation explicite de l’information de contexte et de ses
implications sur la présentation
 Approches:
• Modélisation statique
• Différents modèles de contexte
• Modélisation dynamique
• Un modèle + des règles d’adaptation
 Résultats:
• Modèle de personnalisation
67
 Définit la manière dont la structure de

navigation est présentée à l’utilisateur
 Elle comprend le modèle de la présentation
statique et le modèle de présentation
dynamique
68
 Modèle de présentation statique :
• Définit comment les nœuds de navigation

du modèle de navigation sont présentés à
l’utilisateur
• Consiste en une collection d’objets
d’interface utilisateur représentés par les
objets composites UML
• Un objet de représentation cadre sert à
regrouper ces éléments
69
Modèle de présentation statique :
• Un objet d’interface utilisateur est construit en

combinant des primitives appelées objet de
présentation
• Un objet de présentation dépend de l’état
d’un objet de navigation
• Les objets d’interface utilisateur peuvent avoir
leur propre état
• Leur comportement est décrit dans le modèle
de présentation dynamique
70
 Modèle de présentation statique :
• La sémantique des objets d’interface utilisateur est;
• Objet de présentation: composé à partir d’autres objets et
dépend de l’état d’un nœud de navigation
• Une ancre: secteur cliquable, point de départ d’une
navigation. Se compose d’une présentation (texte, bouton,
forme, image, vidéo) ainsi que d’un lien
• Un texte, séquence de caractères avec une information de
formatage
• Un bouton, secteur cliquable qui a une action associée
• Une forme, employée pour demander une information à
l’utilisateur. Est composée de champs d’entrée, de menus, de
checkboxes
• Les images, acoustique et vidéo peuvent être mises en
marche
71
 Concepts :
• « page »
• décrit une page représentant une unité de visualisation
• Peut être composée de plusieurs unités de présentation
• « unité de présentation »
• Sert à regrouper des unités de présentation reliées (fragments
logiques d’une page)
• « élément de présentation »
• « Anchor »
• « Text »
• « Image »
• Etc.
72
3.7. Modélisation de la Modèle de
présentation (7) présentation
statique
 Exemple : Pages de présentation du système de « reviewing »
« page » « page »
PaperPage AuthorPage
« presentation unit » « presentation unit »
Paper AuthorList Author
« text » « text » « text »
« anchor »
PaperID SubmissionDate Name
Author1
Title « anchor » Affiliation
« text » Author2 « text »
Abstract E-mail
...
FullVersion(Pdf) SubmitReview
« button »
« anchor »
Authors SubmitChanges
73
3.7. Règles de génération des
modèles (8)

guidedTour
lien 1---1 *
Index de B
lien *----*
74
3.7. Règles de génération des
modèles (9)
Page Web
« guidedTour » accès séquentiel Page Web
à une liste de nœuds Page Web
« query » recherche d’un nœud

et accès direct Page Web
Query ….
Index de B
75
3.7 Règles de génération des
modèles (10)

Page Web
Choix B Choix C
Index de B
Index de C
76
 Modèle de présentation dynamique
• Emploie des diagrammes de machines d’états UML

• Sert à définir la réaction des objets d’interface
utilisateur du modèle de présentation statique sur des
événements externes d’utilisateur (mouvements de
souris, clics de souris, touches de clavier enfoncées)
• Il en est de même pour la réaction aux événements
internes (arrêts, activations, désactivations)
• Exemple d’utilisation des machines d’états UML:
contrôler l’accès à une zone protégée par un mot de
passe dans un fenêtrage
77
 Exemple : Scénario du modèle de présentation

pour le système de « reviewing »
« page » « presentation « index » :ListOf « navigation
« page »
:Conference unit » :Assigned :Paper Assigned class »
:Paper
Homepage :NavigationBar Papers Papers :Paper
:Reviewer
navigate
show
navigate(assignedPapers) browse Modèle
d’interaction
select
dynamique
show
navigate(Paper) browse
create
show
loop(0, nrAssignedPapers) 78

• Fonctionnement des objets d’interface utilisateur
• A la réception d’un événement, il peut y avoir; changement
de la perception et de l’activation de variables, génération
de nouveaux événements, envoie de messages à d’autres
objets d’interface utilisateur ou à de objets de navigation
• Un objet d’interface utilisateur composite délègue à ses
composants les événements qu’il reçoit
• Les objets d’interface utilisateur ont un comportement par
défaut
79

• Deux sortes d’objets interface utilisateur:
• Ceux qui sont perceptibles à l’utilisateur
• Ceux qui sont en activité (peuvent recevoir des
événements de la part de l’utilisateur)
• Les variables « perception et activation » sont
employées respectivement dans chacun des deux
cas
80
 Modèle de présentation dynamique: La

variable perception
• Elle contient la liste des objets perceptibles à
l’utilisateur
• Elle recense plusieurs mécanismes: le lien avec les
événements internes SHOW et HIDE
• Chaque fois qu’un élément est mis dans la variable
perception, l’événement interne SHOW est produit
• Chaque fois qu’un élément est enlevé, l’événement
HIDE est produit
81
 Modèle de présentation dynamique: La variable activation
• Elle contient l’objet d’interface utilisateur de la liste des objets
perceptibles qui recevra les événements externes d’interface
utilisateur
• Chaque fois qu’un objet d’interface utilisateur est assigné à la

variable (activation)
• il recevra l’événement interne (activé)
• et l’objet précédemment assigné (activation) recevra
l’événement interne (désactivé)
• L’exception: le bouton. Le modèle de présentation

dynamique doit définir les actions qui sont effectuées quand
un bouton est appuyé
82
 Modèle de présentation dynamique: Méthode de
construction d’un objet de présentation
• On peut composer un objet de présentation pour une classe de
navigation. C’est un diagramme d’objet composite
• Un élément de niveau supérieur est un cadre modélisé par un

objet composite contenant des objets de présentation de plus
bas niveau
• Il peut contenir un nombre arbitraire de sous-cadres
• Un cadre est une instance d’une classe stéréotypée par «cadre »

avec une icône correspondante
83
 Modèle de présentation dynamique: Méthode de construction
d’un menu de présentation
• 1. Construire une présentation pour chaque classe de navigation et pour
chaque classe d’index du modèle d’accès
• 2. Choisir une classe de navigation comme racine pour la navigation
• 3. Considérer tous les chemins possibles dans le modèle d’accès de la

classe racine à la classe réelle pour chaque classe de navigation et pour
chaque index
• 4. Combiner les résultats des étapes 1 et 3 de façon à ce que n’importe

quel cadre contienne:
• un sous cadre droit avec la présentation de la classe de navigation ou
de la classe d’index (étape 1)
• Et un sous cadre gauche représentant l’arbre de navigation (étape 3)
84
3.8. Modélisation de l’adaptation (1)
 Objectifs : représentation explicite de
l’information de contexte et ses
implications sur la présentation
 Approches :
• Modélisation statique (différents modèles de
contextes)
• Modélisation dynamique (un modèle + des
règles d’adaptation
 Résultats : un modèle d’adaptation
85
• Fondée sur la notion de règles
• Une règle est modélisée par une classe
stéréotypée « rule »
• Elle set liée par une composition à une
classe « condition »
• Les conditions et les actions sont liées à des
classes du modèle utilisateur et du
86
• Les règles d’adaptation spécifient les conditions
d’adaptation des contenus, de la navigation et de la
présentation
• Les règles d’acquisition décrivent le mode
d’acquisition des informations au sujet de
l’utilisateur et donc la MAJ du modèle utilisateur
• Pour décrire le comportement observé du
système, on utilise la classe stéréotypée
«UserBehaviour »
• Les règles (conditions et actions) sont exprimées en OCL
• Des diagrammes de communication sont construits pour
mettre en évidence les enchaînements éventuels de règles
87
3.8. Modèle d’adaptation (4)
 Exemple : adaptation dynamique d ’un index dans le modèle
hypertexte
« menu »
PaperMenu
reviewer « customization »
reviews
papers All papers that are within the user’s
scope of interest
« index » « navigation class »

InterestingPapers Paper
88
3.8. Modèle d’adaptation (5)
« page »
 Exemple : PaperPage
Paper
PaperID SubmissionDate « customization »
« text » visible, if user currently
Title in role « reviewer »
« text »
Abstract
FullVersion(Pdf) EnterReview
« anchor »
Authors
89
4. Panorama des méthodes
 4.1. Vue Générale
 4.2. Les méthodes
 4.3. Modélisation du contenu
 4.4. Modélisation de la navigation
 4.5. Modélisation de la présentation
 4.6. Modélisation de l’adaptation
 4.7. Les autres méthodes
90
4.1. Vue Générale
System Usage
Role Business Process
Tasks Goals Adaption

Model
Web Application Model
Problem Navigation
Domain model Context
Model
Attribute Nodes & Links
Relations Access struct.

Rules
Functionality Process struct.
Presentation Model
91
4.2 Les méthodes
1. Orientées données
• L‘accent est mis sur :
• L‘information à présenter
• Les relations entre les informations
• Exemples:
• RMM = Relationship Management Methodology
• WebML = Web Modelling Language
92
Quelques approches
 2. Orientées hypertextes
• L‘accent est mis sur:
• La structure de l’hypertexte
• Exemples:
• HDM = Hypertext Design Model (W2000, HDM-lite)
• WSDM = Web Site Design Method
93
Quelques approches
3. Orientées objets
• L’accent est mis sur:
• La structure des objets avec les données et les méthodes
• Les processus qu‘effectuent les objets
• Exemples:
• WOLM = Web Object Life Cycle Model
• WISE = Web Information and Service Engineering
• OO-H = Object Oriented Hypermedia Method
• OOHDM = Object-Oriented Hypermedia Design Method
• UWE = UML-Based Web Engineering
94
4.2. Les méthodes (4)
 4. Par Prototypage
• L’accent est mis sur:
• Le prototypage informel et rapide
• Les petits sites web
• Exemple:
• DENIM = Design Environment for Navigation and
Information Models
95
4.3. Modélisation du contenu
System Usage

Model
Problem Navigation
Model
Contenu du domaine

Rules
Presentation Model
96
4.3.1. Modélisation du contenu en
WebML
 Diagrammes de classes simplifiés
• classes
Attributs typés list of persons
Pas de méthodes!
• relations
associations
héritages
• C’est le premier modèle de WebML Person
• Accès aux …
• … classes (fournisseur de contenu pour le modèle navigationnel)
• … relations pour la définition d’index

97
4.4. Modélisation de la
navigation
System Usage

Model
Problem Navigation
 Espace de Domain model Context
navigation Model
 contenus & Attribute Nodes & Links
structure Relations Access struct.
Rules
 accès Process struct.
Functionality
Presentation Model
98
4.4.1. Modélisation de la
navigation en WebML
Principe
• Structure de haut niveau du site web (site views, areas,

pages)
• Eléments exhibés dans les pages

• Accès et affichage de l’information (content units)
• Effectuer des opérations (operation units)
• Propriétés de navigation
• Liens explicites avec effets différents
• Liens implicites (home, landmarks, default, nested pages)
99
4.4.2. Vues et Champs
Vue du site: : un ensemble de pages web offrant une vue cohérente du site
Plusieurs vues peuvent être définies.
Customer Site View

Product Area Offers Area
Champ: Un ensemble
de pages web à l’intérieur
du site liés par un thème
commun.
100
4.4.3. Pages
Page: une page web unique

Peut contenir des sous pages
Customer Site View

Product Area Offers Area
Home Page Shopping Cart

Page
101
4.4.4. Navigation implicite
–navigation implicite (visibilité)

• Landmark
• Default Customer Site View
• Home Page Product Area Offers Area
L L
Home Page Shopping Cart

Page L
H,L
102
4.4.5. Visibilité
pages imbriquées
•
[Ceri, Fraternali & Bongio 2000]
103
4.4.6. Liens
• Contextual link
• Non-contextual link
• Transport link
[Ceri, Fraternali & Bongio 2000]
104
4.5. Modélisation de la Présentation
System Usage
 Distribution Tasks Goals Adaption

Model
 Présentation
 Tailles relatives
Problem Navigation
 Eléments visibles Context
Domain model
 Vues différentes Model
 Dépendance au contexte Attribute Nodes & Links
 … Access struct.
Relations
Rules
Presentation Model
105
4.5.1. Modélisation de la
présentation en WebML
• Pas de modélisation explicite de la représentation visuelle

• Couverture partielle de la spécification de la présentation au
moyen du modèle de navigation (informel)
outermost
leftmost rightmost
Issues Album
106
4.6. Modélisation de l’adaptation
System Usage

Model
 - Contexte à prendre en
Problem Navigation
compte Domain model Context
 Model
- Règles d‘adaptation

Rules
Presentation Model
107
4.6.1. Modélisation de
l’adaptation en WebML
Focus: prise en compte du contexte
Personnalisation
• Renforcement du modèle du domaine

• Adaptation en fonction de l’utilisateur et de son rôle
• Vues spécifiques aux groupes
108
4.6.2. Modélisation de l’adaptation
System Usage

Views
Views Model
Views
Problem Navigation
- Utilisateur Model
- Supports Nodes & Links
Attribute
- Connexion réseau
- Lieu Rules
- Temps Functionality Process struct.
- ...
Presentation Model
109
5. Les autres méthodes
5.1. HDM – Hypermedia Design Model
 C’est un modèle conceptuel et non une
méthode de conception
 Fondé sur Entité/Relation (E/R) enrichi
des caractéristiques des hypermédias
 …
110
5.2. RMM – Relationship
Management Methodology
 S’inspire du modèle HDM
 Méthode de conception et de construction d’applications
à base d’hypermédia
 Prend en compte les données qui subissent des
modifications au cours du temps
 Convient à des applications de e-commerce
 Elle utilise un modèle nommé RMDM (Relationship
Management Data Model) pour décrire les informations et
les mécanismes de navigation
 Fondée sur le modèle E/R auquel s’ajoute le concept de
« slice » pour regrouper les attributs et les primitives
d’accès pour modéliser la navigation
111
5.3. OOHDM – Object Oriented
Hypermedia Design Methodology
 S’inspire du modèle HDM
 Démarche de conception orientée objet
 A évolué vers UML
 Cinq étapes :
• Collecte des besoins suivant 5 (????) phases
• Identification des rôles et des tâches que l’application doit prendre en charge
• Spécification des scenarii par les utilisateurs
• Spécification des cas d’utilisation
• Spécification des diagrammes d’interaction utilisateur
• Modélisation conceptuelle suivant le formalisme UML
• Pour obtenir le diagramme de classes, on applique des règles de transformation aux diagrammes
d’interaction utilisateur
• Modélisation de la navigation : ce sont des vues du modèle conceptuel obtenues en 3
étapes
• Modélisation de la navigation par tâche
• Production du diagramme de contexte de navigation
• Spécification du modèle de navigation
• Modélisation de l’interface abstraite selon l’approche ADV (Abstract Data View) afin de
décrire l’interface utilisateur
• L’implémentation : les objets conceptuels, de navigation et d’interface sont traduits en
fonction de l’environnement choisi
112
5.4. WSDM – Web Site Design
Method
 Approche centrée sur l’utilisateur et ses besoins
 Etapes :
• Modélisation du public
• Classification des utilisateurs selon les besoins informationnels
et fonctionnels similaires => hiérarchie de classes
• Caractérisation plus fine des classes d’utilisateurs afin de
déterminer les sous-groupes d’utilisateurs (langue, niveau de
compétence, préférences pour la présentation, …)
• Modélisation conceptuelle
• Modélisation objet des besoins des classes d’utilisateur (E-R)
• Modélisation du domaine par fusion des modèles précédents
• Conception de navigation : modèle décrivant les
possibilités de cheminement à travers l’information
• Modélisation en vue de l’implémentation : définition des
pages constituant le site en termes de structure et
d’apparence
113
5.5. AWIS-M Adaptative Web Based
Information System Method
 Démarche inspirée par l’ingénierie des processus
 Exploite le méta-modèle du projet NATURE
 Ensemble de modèles de produits
• Modèles de produits de niveau conceptuel
• Modèle des objectifs des utilisateurs (description et
représentation des besoins)
• Modèles des utilisateurs (description des différentes
catégories d’utilisateurs)
• Modèle du domaine d’information web ( modèle objet
des concepts manipulés par le SIW)
• Modèle conceptuel de navigation (décrit les procédés
de navigation prédéfinis)
114
5.5. AWIS-M Adaptative Web Based
Information System Method (suite)
 Ensemble de modèles de produits (suite)
• Modèles de produits de niveau logique
• Modèle de présentation de l’hyper-espace
(traduction logique du modèle conceptuel de
navigation)
• Modèle logique des utilisateurs (représentation
logique des concepts de rôle, navigation, profil)
• Modèle mathématique de l’hyper-espace
(mécanismes de calcul de l’hyper-espace à
présenter à un utilisateur)
115
5.6. WebML Web Modeling
Language
 Langage de modélisation dédié à la conception de sites web
complexes
 Propose un ensemble de représentations graphiques
associées à une syntaxe XML
 Modèles et processus :
• Modèle structurel décrivant le contenu du site (E/R)
• Modèle de dérivation avec vues et regroupement des données
• Modèle de composition pour déterminer les pages du site
• Modèle de navigation : décrit la façon dont les unités et les
pages du modèle de composition sont liées pour former un
hypertexte (liens contextuels et liens non contextuels)
• Modèle de présentation pour l’apparence des pages
116
5.6. WebML Web Modeling
Language (suite)
 La personnalisation se fait à travers un modèle structurel
WebML (groupes d’utilisateurs et utilisateur individuel)
 Processus :
• Collecte des besoins (objectifs du site, public, exemples
de contenus, exemples de présentation, éléments de
personnalisation)
• Conception des données :
• Modèle structurel et modèle de dérivation
• Conception de l’hypertexte et détermination du nombre de
vues du site
• Pages et liens requis pour chaque vue
• Détermination des index, filtres pour l’accès à l’information
• Définition des chemins d’accès
• Modèle de présentation
117
5.7. HyperTIM – Hypermedia Task
Oriented Information Modeling
 Approche centrée utilisateur
 Modélise les tâches de l’utilisateur
 Etapes :
• Modélisation des tâches navigationnelles
(modélisation du comportement des
utilisateurs)
• Modélisation des données spécifiées lors de
la phase précédente
• Modélisation de la navigation à l’aide de
représentations graphiques
118
5.8. Comparaison des méthodes
(1)
 Eléments pris en compte
119
(2)
 Capacité d’adaptation
120
(3)
 Evaluation des capacités d’adaptation
121
6. Les Outils
Un exemple : ArgoUWE
122
ArgoUWE:
Etape 1 : Points de départ
 Diagramme de Cas d’utilisations

 Diagramme de contenu (de classes)
• Dans l'outil ArgoUWE, l'option "Create -
Conceptual Diagram" permet de saisir le
diagramme de contenu.
• Attention : une intégration de diagramme à
partir d’un autre logiciel est impossible
123
ArgoUWE Diagramme de cas d’utilisation
SYSTEME
D'INFORMATION
DES PLATES-
FORMES DE TESTS
PSA
124
Diagramme
de contenu
(cas
créer une demande
de test)
 Attention: ne
permet pas de
représenter
l’héritage
 Les associations
entre classes sont:
• nommées
• présentées avec
leurs cardinalités
125
ArgoUWE
Etape 2 : Diagramme de la structure
de navigation
 A partir du diagramme de contenu on génère
un diagramme de navigation comportant
l’ensemble des classes et des parcours
possibles.
• Utilisez l'option « Create - Navigation Diagram » après
avoir sélectionné l’ensemble du diagramme.
 Ensuite on crée un diagramme de navigation

propre à chaque acteur et ses cas d’utilisation
qui est un sous-ensemble du diagramme
précédent.
• On choisit les classes qui nous intéressent pour chaque
acteur et le cas d’utilisation concerné.
126
Diagramme de la structure de navigation
Acteur:
Demandeur
de test
127
ArgoUWE
Sens de navigation (1)
 Les flèches sont orientées vers les

cardinalités supérieures (ex. : *, 1..*)
1
1..*
128
ArgoUWE
Sens de navigation (2)
 Dans le cas de cardinalités multiples :
• Une navigation à double sens se transforme en 2
flèches de sens opposés.
• Attention, l’outil nécessite une intervention
manuelle. * *
• se transforme en :
*
129
ArgoUWE
Exemple (navigation à double sens)
130
ArgoUWE
Les attributs dérivés
 Cas de lien 1-1
 On peut remplacer un lien vers une classe
par un attribut dérivé dans la classe source :
A 1 1 B
• soit A
/B
131
ArgoUWE
Etape 3 : Diagramme d’accès (1)
 Le diagramme d’accès est généré à partir

du diagramme de navigation propre à
l’acteur.
 On transforme chaque lien (boutons
« Addindexes » et « Addmenus » ) de la
façon suivante :
• Lorsqu'une classe source possède plusieurs liens de
navigation sortants vers des classes cibles, un menu
est ajouté pour permettre à l'utilisateur de choisir un des
liens de navigation à partir de la classe source.
132
ArgoUWE
Exemple avec un menu
contenu accès
133
ArgoUWE
Diagramme d’accès (2)
• Lorsqu'un lien de navigation a une multiplicité
supérieure à 1 (cardinalité supérieure à 1 du coté de la
classe cible), un index est ajouté pour permettre
l'affichage d'une liste d'instances de la classe cible et la
sélection d'une de ses instances à partir de la classe
source (choix dans une liste)
• Autres choix possibles :
• Une question
• Un assistant (plusieurs pages se suivent pour
pouvoir guider la demande)
134
Exemple PSA
diagramme
d’accès
135
ArgoUWE
Etape 4 : Diagramme de présentation
 Le diagramme de présentation est généré
automatiquement à partir du diagramme
précédent (d’accès).
 Sur les pages de présentation on retrouve les
éléments du diagramme d’accès (menu,
index/liste, champ de saisie (question).
 On peut y ajouter d’autres éléments de
présentation propres au site Web. (Ancres,
images, texte …).
136
Exemple (accès -> présentation)
137
Exemple PSA (diagramme de présentation)
138
ArgoUWE
Exemple (adhérent)
139
ArgoUWE
Exemple (adresse)
140
ArgoUWE
Etape 5 : Génération du code
 ArgoUWE permet la génération du code :

• Java
• XMI (format d’export des schémas)
• XML
 Malheureusement l’outil ne permet pas de
générer le code php.
141

DUT SI Modelisation Partie 2

Transféré par

Droits d'auteur :

Formats disponibles

DUT SI Modelisation Partie 2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DUT SI Modelisation Partie 2

Transféré par

Droits d'auteur :

Formats disponibles

3.

Systèmes d’Information Web

 Déposer des appels d’offre (le client peut

 Gérer ses produits (ajouter, supprimer,

 Diagramme de cas d’utilisation: fonctions du système du point de vue de

 Profils et Stéréotypes UML

• Les extensions spécifiques au domaine sont appelés les

• Les stéréotypes représentent une extension des méta-classes

• Modélisation des besoins fonctionnels

 Système d’évaluation d’articles soumis à une conférence

 Fondée sur les vues utilisateurs (acteurs)

register submit paper

Reviewer enter review

close reviewing process

[user logged-in] enter title select select

assigned reviewed inPrint

assigned reviewed inPrint

 3.6.1. Structure de navigation

 Règles de détermination du modèle de la structure de

• Définir une classe de navigation pour chaque classe du

« liens » « lien de navigation » index, menu, query,

Contenu Navigation Accès Présentation

« menu » accès aux nœuds

« liens » « lien de navigation » index, menu, query,

Contenu Navigation Accès Présentation

« query » recherche d’un nœud

Contenu Navigation Accès Présentation

« menu » accès aux nœuds

« index » « index » reviews « menu » authors « index »

« navigation link » 1..*

Cohérence du modèle « navigation class » * « index »

 La notation pour les différents contextes

« index » « index » reviews « menu » authors « index »

 Définit la manière dont la structure de

• Définit comment les nœuds de navigation

• Un objet d’interface utilisateur est construit en

« liens » « lien de navigation » index, menu, query,

Contenu Navigation Accès Présentation

« query » recherche d’un nœud

Contenu Navigation Accès Présentation

« menu » accès aux nœuds

• Emploie des diagrammes de machines d’états UML

 Exemple : Scénario du modèle de présentation

 Modèle de présentation dynamique

 Modèle de présentation dynamique

 Modèle de présentation dynamique: La

• Chaque fois qu’un objet d’interface utilisateur est assigné à la

• L’exception: le bouton. Le modèle de présentation

• Un élément de niveau supérieur est un cadre modélisé par un

• Il peut contenir un nombre arbitraire de sous-cadres

• Un cadre est une instance d’une classe stéréotypée par «cadre »

• 2. Choisir une classe de navigation comme racine pour la navigation

• 3. Considérer tous les chemins possibles dans le modèle d’accès de la

• 4. Combiner les résultats des étapes 1 et 3 de façon à ce que n’importe

« index » « navigation class »

Tasks Goals Adaption

Relations Access struct.

Tasks Goals Adaption

Relations Access struct.