Chapitre 6 Modèle Conceptuel de l’Application

Modèle Conceptuel de l’Application

1. Introduction
La modélisation de notre application se fait par approche orientée objet, le langage UML
(Unified Modeling Language) est l’outil par excellence pour décrire cette modélisation.
UML offre plusieurs vues complémentaires qui permettent de décrire le cycle de vie d’une
application, ces vues utilisent les notions fondamentales de la conception objets, sa notation
graphique permet de visualiser une solution objet.
2-Generalités sur UML
a- Définition d’UML : (Unified Modeling Language, que l’on peut traduire par langage de
modélisation unifié) est une notation permettant de modéliser un problème de façon standard.
Ce langage est né de la fusion de plusieurs méthodes existant auparavant, et est devenu
désormais la référence en terme de modélisation objet, à un tel point que sa connaissance est
souvent nécessaire pour obtenir un poste de développeur objet.
b- Pourquoi UML ?
-UML est un langage pour visualiser : L’écriture de modèles en UML permet d’apporter une
solution aux problèmes liés à l’échange et au partage d’informations.
-UML permet d’utiliser au mieux les représentations textuelles ou graphiques en fonction des
besoins.
-UML est un langage pour spécifier : C’est-à-dire construire des modèles précis, sans
ambiguïté.
-UML permet la spécification de toutes les décisions importantes en matière d’analyse, de
conception et d’implémentation.
-UML est un langage pour construire : UML n’est pas un langage de programmation visuelle,
ses modèles peuvent être directement traduits dans les différents langages de programmation.
Cela signifie qu’il est possible de traduire un modèle UML dans un langage de
programmation tel que Java, C++ ou Visual Basic.
-UML est un langage pour documenter : UML permet de documenter l’architecture d’un
système dans ses moindres détails, fournit un langage pour exprimer les besoins et effectuer
des tests et propose un langage pour modéliser la planification du projet et la gestion des
versions.
-UML est un langage graphique : UML exprime ses concepts à travers différents diagrammes
graphiques qui correspondent à des vues particulières du système :

58
Chapitre 6 Modèle Conceptuel de l’Application

-La vue logique : elle fait référence aux diagrammes de classes (class diagrams). C’est au
niveau de cette approche que l’on va utiliser la plupart des concepts objets.
-Cas d’utilisation : qui fait référence aux diagrammes des cas d’utilisation (use cases
diagrams) et des acteurs. on va s’intéresser aux fonctionnalités du système.
-La vue des composants (component view) : elle représente l’ensemble des composants
logiciels ainsi que les taches.
-La vue déploiement (deployment view) : elle décrit les différentes ressources matérielles et
l’implantation du logiciel dans ces ressources.
Si on procède par classification, on a les diagrammes suivants :
- Les cas d’utilisation.
- Les diagrammes de classes.
- Les diagrammes de comportement :
- Diagrammes d’état –transitions.
- Diagrammes d’activités.
- Diagrammes de séquences.
- Diagrammes de collaboration.
- Les Diagrammes d’implémentation :
- Diagramme de composants.
- Diagrammes de déploiement.
c- Avantages et Inconvénients :
UML utilise des représentations diagrammatiques pour modéliser les aspects statique
(structurel) et dynamique (comportemental) des systèmes.
-Avantages :
-Représentation en 2D,
-Représentation sémantiquement riche,
-Chaque notation est simple => facilité d’apprentissage par les non informaticiens =>
validation possible par les utilisateurs finaux.
-Inconvénients :
-Sémantique pas totalement définie => risque d’interprétations variées,
-Beaucoup de diagrammes différents => difficulté à maîtriser toutes les notations,
3. Les diagrammes de « UML » ::
3.1 Diagrammes des cas d’utilisations :
Les diagrammes de cas d’utilisation se composent d’acteurs (représentés par des silhouettes)
et des cas d’utilisation (représentés par des ellipses),les traits entre les cas d’utilisation et les

59
 Chapitre 6 Modèle Conceptuel de l’Application

acteurs représentent les interactions. Ces diagrammes montrent les relations qui existent entre
des acteurs et des fonctionnalités du système.
Exemple :
Extends
Retrait Francs

Retrait

Retrait Devises Extends

Guichetier Système central

Fig. 11 Exemple de diagramme de cas

d’utilisation
3.2Diagramme de classes :
C’est un diagramme qui montre une collection d’éléments statiques (classes), leur contenu et
les relations entre eux. On distingue :
Les entités formées de trois parties :
-Les classes : Les classes se désignent par un nom (1ère partie), contiennent des attributs (2éme
partie) et des méthodes associées (3éme partie).
-Les attributs : sont des propriétés caractéristiques de la classe. Les attributs peuvent être
privés, publique, protégés. Ils sont le plus souvent privés. Les classes respectent le principe
d’encapsulation des données.
-Les méthodes : sont des procédures spécifiques à une classe. Elles sont le plus souvent
publiques. Elles peuvent être privés : on parle dans ce cas de méthodes d’implémentation.
3.2.1 Les relations interclasses :
Elles sont appelées associations. On a défini différents types d’associations :
-Association simple
-Agrégation
-Héritage (spécialisation, généralisation)
-Dépendance
Les noms de rôle : ceux sont les noms des relations interclasses.
Les multiplicités : associées aux associations, les multiplicités permettent de déterminer le
nombre d’occurrences d’une classe par rapport à une autre classe en utilisant le nom de rôle.
La navigation : c’est le sens de lecture du nom de rôle d’une association donnée.
L’association est symbolisée par une ligne qui lie deux classes.
La navigation est symbolisée par une flèche qui indique le sens de lecture du nom de rôle.
3.3Diagrammes de comportement (behavior diagrams):

60
Chapitre 6 Modèle Conceptuel de l’Application

3.3.1 Diagrammes d’états–transitions (state diagrams) :

Les diagrammes états-transitions décrivent les séquences d’états qu’un objet peut prendre au
cours de sa vie en réponse à un stimulus. On associe souvent un diagramme d’états-
transitions à une classe.
On distingue dans ces diagrammes :
-Les événements externes qui causent une transition d’un état à l’autre,
-Les événements internes qui induisent une action sans changer d’état,
-Les actions qui résultent d’un changement d’état,
-Les actions en sortie d’état,
-Les activités pendant l’état.
3.3.2 Les diagrammes d’activité « activity diagrams » :
Un diagramme d’activité est un cas spécial de diagramme d’état dans lequel tous (ou la
plupart) des états sont des états d’action dans lesquels toutes (ou la plupart) des transitions
sont déclanchées par achèvement des actions dans les états sources. Le diagramme entier est
rattaché à une classe, à l’implémentation d’une opération ou d’une cas d’utilisation. Le but de
ce diagramme est de visualiser les flux conduits par des processus internes.
Exemple :

Examiner demande de mise à

jour
[non visée par la société]

[non concernée par la société]

Retourner la demande de mise à
jour

Classifier la demande de mise à jour

Notifier l’acceptation ou le refus

Fig. 12 Exemple de diagramme d’activité

61
Chapitre 6 Modèle Conceptuel de l’Application

3.3.3 Les diagrammes de séquence :

Les diagrammes de séquences montrent les interactions qui surviennent dans une séquence de
temps. En particulier ils montrent la participation d’objets dans les interactions et les
messages qu’ils échangent dans un intervalle de temps. Ils ne montrent pas les associations
entre les objets.
Exemple :

Un objet Un autre objet Encore un objet

Un message

Un autre message

Fig.13 Exemple de diagramme de séquence

3.3.4 Les diagrammes de collaboration :

Les diagrammes de collaboration montrent les interactions et les liens entre objets.
Contrairement aux diagrammes de séquence les diagrammes de collaboration montrent les
relations entre objets mais pas la durée de vis des interactions. Ils ont en commun le fait de
tenir compte de la chronologie des interactions.
Les diagrammes de collaboration comme les diagrammes de séquence expriment la même
information, mais le montrent par des chemins différents.

62
Chapitre 6 Modèle Conceptuel de l’Application

Exemple :
(6) Débit compte

(4) Retrait espèces

(5) vérification solde
Guichetier compteSystème central

(7) autorisation
délivrance
(3)Demande
Type d’opération

(2) validation compte

Système Guichetier
(1) Saisie compte

Fig.14 Exemple de diagramme de collaboration

3.4 Les diagrammes d’implémentation :

On distingue Les diagrammes de composants qui montrent la structure du code et Les
diagrammes de déploiement qui montrent la structure du système lors de son exécution.
3.4.1 Les diagrammes de composants :
Les diagrammes de composants sont des graphes de composants connectés par des relations
de dépendance. Les composants sont des composants logiciels. On distingue les composants
de code source, de code binaire, et les composants exécutables. Un module logiciel peut être
représenté comme un type de composant. Certains composants existent lors de la
compilation, à l’édition des liens, et d’autres lors de l’exécution.
3.4.2 Les diagrammes de déploiement :
Les diagrammes de déploiement montrent la configuration des éléments de traitement
exécutés et de composants logiciels, traitements, et les objets qui sont impliqués. Les
instances de composants logiciels représentent les manifestations lors de l’exécution des
unités de code.
4. Utilisation de UML pour notre application :
Notre travail est basé sur le recalage de deux images IRM cérébrales. Les images sont
données au médecin pour qu’il puisse faire une bonne interprétation des pathologies du
patient
La conception de notre application est illustrée avec les diagrammes suivants :

63
Chapitre 6 Modèle Conceptuel de l’Application

4.1 Diagramme de cas d’utilisation :

Acteurs du système :

L'identification des acteurs participants dans le système est primordiale pour décrire et
préciser comment chacun d'eux se comporte pour servir ou être servie.

Les acteurs principaux de notre application sont l’utilisateur le Médecin et l’analyste (traiteur
d’images).

a)Acteur analyste :
L’analyste a deux cas d’utilisation :
-Traitement d’images bas niveau.
-Traitement d’images haut niveau (recalage).
Le cas d’utilisation traitement d’images bas niveau comporte les taches principales de :
- détection de contour.
-Seuillage.
-Le cas d’utilisation traitement d’images haut niveau comporte les taches suivantes :
-la sélection des points sur les deux images.
-le calcul des paramètres de la transformation.
-l’application de la transformation sur l’image source.
-affichage de l’image recalée.
b) Acteur Médecin :
-interviennent dans le traitement de haut niveau, pour définir l’image recalée, objet de son
interprétation
Le diagramme de cas d’utilisation de notre application est le suivant :

64
Chapitre 6 Modèle Conceptuel de l’Application

Traitement images
bas niveau

Analyste
(Traiteur
d’images) Traitement images
haut niveau

Médecin

Fig.15Diagramme de cas d’utilisation

4.2 Diagramme de séquence :

-Traitement d’images bas niveau :
Le médecin se connecte au système et entre les deux images à recaler.

: Analyste : Système

Entrer les deux images

Afficher les deux images

Appliquer contour

Afficher contour d’images

Appliquer Seuillage

Afficher image seuillée

65
Chapitre 6 Modèle Conceptuel de l’Application

-Traitement d’images haut niveau :

: Analyste : Système

Sélection des points

Afficher points sélectionnés

Chercher paramètres de la transformation

Afficher les paramètres

Appliquer la transformation

Afficher l’image recalée

: Médecin : Système

Demander image recalée

Afficher image recalée

66
Chapitre 6 Modèle Conceptuel de l’Application

4.3 Diagramme de classes :

1 1
Personne
Nom
Prénom
Date Naissance
Adresse

1..n 1..n
1..n
Images 1
ImgSource Point
ImgRéference
DateImg ()
PointSource
PointRéf
Nombre
Contourer()
Seuiller() SelectPoint ()
Afficher() AjouterPoint()

1
1

1
1
Recalage Paramètres
1 1
ImgS TransX,TransY
ImgR Sechelle
Rrot
Erreur
CalculerT()
Recaler() CalculerS()
Afficher() CalculerR()
CalculerE()

Conclusion :
On a utilisé UML pour présenter la conception de notre application par approche objet.
On s’est concentré sur le diagramme de cas d’utilisation et le diagramme de classes , sur le
quel se base notre implémentation dans le chapitre suivant.

67