2- Le concept objet
2.1- Définition et caractéristiques de
l'objet
L'objet constitue le concept fondateur de l'approche du
même nom.
· Un objet est une entité aux frontières
précises qui possède une identité (un nom).
· Un ensemble d'attributs caractérise l'état
de l'objet.
· Un ensemble d'opérations (méthodes) en
définissent le comportement.
· Un objet est une instance de classe (une occurrence d'un
type abstrait).
· Une classe est un type de données abstrait,
caractérisé par des propriétés (attributs et
méthodes) communes à des objets et permettant de créer des
objets possédant ces propriétés.
2.2- Les autres concepts objets
Encapsulation.
Elle Consiste à masquer les détails
d'implémentation d'un objet, en définissant une interface..
L'interface est la vue externe d'un objet, elle définit les services
accessibles (offerts) aux utilisateurs de l'objet. L'encapsulation facilite
l'évolution d'une application car elle stabilise l'utilisation des
objets : on peut modifier l'implémentation des attributs d'un objet sans
modifier son interface.
28
Héritage.
Une classe peut être déclarée comme
héritant d'une autre classe. La classe qui hérite
possèdera toutes les propriétés (attributs,
méthodes) de la classe dont elle dérive .Mais en plus elle aura
certaines méthodes particulières.
3- Modélisation des vues statiques et dynamiques
3.1- Les vues statiques
Elles donnent une vue globale sur le système à
modéliser mais elles ne rentrent pas dans les détails
d'implémentation.
3.1.1- Les cas d'utilisation
· Il s'agit de la solution UML pour représenter le
modèle conceptuel,.
· Les use cases permettent de structurer les besoins des
utilisateurs et les objectifs correspondants d'un système.
· Ils centrent l'expression des exigences du système
sur ses utilisateurs :
ils partent du principe que les objectifs du
système sont tous motivés.
· Ils se limitent aux préoccupations
"réelles" des utilisateurs ; ils ne présentent pas de solutions
d'implémentation et ne forment pas un inventaire fonctionnel du
système.
· Ils identifient les utilisateurs du système
(acteurs) et leur interaction avec le système.
· Ils permettent de classer les acteurs et structurer
les objectifs du système et servent de base à la
traçabilité des exigences d'un système dans un processus
de développement intégrant UML.
Conceptualisation
Le but de la conceptualisation est de comprendre et structurer
les besoins du client. On ne cherche l'exhaustivité, mais clarifier,
filtrer et organiser les besoins. Une fois identifiés et
structurés, ces besoins :
définissent le contour du système à
modéliser (ils précisent le but à atteindre),
permettent d'identifier les fonctionnalités principales
(critiques) du système.
Le modèle conceptuel joue un rôle central, il est
capital de bien le définir .Il doit permettre une meilleure
compréhension du système et servir d'interface entre tous les
acteurs du projet. Les besoins des clients sont des éléments de
traçabilité dans un processus intégrant UML.
Le modèle conceptuel joue un rôle central, il est
capital de bien le définir.
29
Les Règles Métiers
Elles permettent de déterminer les contraintes
liées au système à modéliser. Elles constituent le
soubassement du logiciel. Dans le souci de donner une vue panoramique et claire
du système d'information, nous avons eu à regrouper les
règles métiers suivants certains critères :
o les règles relatives à l'architecture de la
formation
R1- L'architecture de la formation est fondée sur 3
grades (Licence, Master, doctorat).
R2- Les formations sont organisées en semestres et en UE
capitalisables.
R3- L'unité de base constitutive d'un parcours de
formation est l'UE.
R4- Les enseignements d'une UE peuvent prendre
différentes formes : Cours Magistraux (CM), Travaux Dirigés (TD),
Travaux Pratiques (TP), Travaux de Terrain, Recherche ou combiner ses
différentes formes.
R5- Chaque UE a une valeur définie en crédits
proportionnelle au travail (CM, TD, TP, Stage etc.) que l'étudiant doit
fournir pour la validation de l'UE.
R6- Dans la reforme LMD, le semestre est la durée
périodique des UE de formations contrairement à l'année
universitaire dans le système traditionnel ou ancien.
R7- Les 3 grades sont exprimés en semestre (L pour
6semestres, M pour 4 semestres après L, D au moins 6 semestres).
R8- Le semestre correspond à un volume horaire
établi et mesuré en crédits,
R9- Un crédit correspond à 20 heurs de travail
pour l'étudiant (CM, TD, TP, recherche, Travail personnel).
R10- Un parcours de formation est structuré en UE
obligatoires, optionnelles, ou libres.
o Les Règles relatives au cursus de formation
R1- L'offre de formation est présentée par
domaines déclinés en filières de formation.
R2- Le cursus de Licence est organisé sous forme de
parcours monodisciplinaires, transdisciplinaires et pluridisciplinaires.
R3- Chaque cursus comporte des UE obligatoires, libres et
optionnelles.
R4- Le cursus Master présente 2 voies de finalité
: l'une est celle de la recherche et l'autre est professionnelle.
R5- Le parcours est individuel au niveau de tous les cursus.
o Les règles relatives à l'inscription
pédagogique
R1- L'inscription pédagogique à un semestre
nécessite la satisfaction des prérequis éventuels des UE
le composant.
R2- L'inscription pédagogique est conditionnée par
celle académique.
R3- Un étudiant titulaire du Baccalauréat ou de
son équivalence peut s'inscrire en première année de
Licence LMD.
R4- Un étudiant titulaire d'une Licence peut s'inscrire
en première année de Master LMD.
30
-Les règles relatives aux évaluations et
résultats
R1- Les évaluations et résultats auront lieu dans
les 4 dernières semaines de chaque semestre.
R2- Les étudiants inscrits pédagogiquement sont
évalués une fois semestriellement et ceci pour chaque UE
choisie.
R3- Une UE est définitivement acquise dès que
l'étudiant a obtenu la moyenne requise : il capitalise ainsi les UE
requises jusqu'au moment où il obtient le grade auquel conduisent les
unités choisies.
R4- Pour prétendre valider les UE d'un semestre il faut
que l'étudiant un certain nombre de présentiel et assume une
charge de travail personnel.
Les diagrammes qui suivent présentent l'analyse du
domaine c'est-à-dire le modèle des besoins clients.
3.1.2- Diagrammes des cas d'utilisation.
Ils décrivent les fonctionnalités employées
par les utilisateurs. Il s'agit de la solution UML pour représenter le
modèle conceptuel.
· Les cas d'utilisation (ou use cases en Anglais)
permettent de structurer les besoins des utilisateurs et les objectifs
correspondants d'un système.
· Ils centrent l'expression des exigences du système
sur ses utilisateurs :
ils partent du principe que les objectifs du
système sont tous motivés.
· Ils se limitent aux préoccupations
"réelles" des utilisateurs ; ils ne présentent pas de solutions
d'implémentation et ne forment pas un inventaire fonctionnel du
système.
· Ils identifient les utilisateurs du système
(acteurs) et leur interaction avec le système.
· Ils permettent de classer les acteurs et structurer les
objectifs du système.
· Ils servent de base à la traçabilité
des exigences d'un système dans un processus de développement
intégrant UML.
Les cas d'utilisation, permettent de modéliser les
besoins des clients d'un système et ne doivent chercher
l'exhaustivité, mais clarifier, filtrer et organiser les besoins. Une
fois identifiés et structurés, ces besoins définissent le
contour du système à modéliser (ils précisent le
but à atteindre) et permettent d'identifier les fonctionnalités
principales (critiques) du système.
Ils ne doivent donc en aucun cas décrire des solutions
d'implémentation. Leur but est justement d'éviter de tomber dans
la dérive d'une approche fonctionnelle, où l'on liste une litanie
de fonctions que le système doit réaliser. Mais un modèle
conceptuel qui identifie les besoins avec un plus grand niveau d'abstraction
reste indispensable. Avec des systèmes complexes, filtrer l'information,
la simplifier et mieux l'organiser, c'est rendre l'information exploitable.
31
La sémantique
Acteur : entité externe au
système qui interagit avec le système.
Use case (cas d'utilisation):
ensemble d'actions réalisées par le système, en
réponse à une action d'un acteur.
Relation d'utilisation (« include ») :
le cas d'utilisation source contient aussi le comportement
décrit dans le cas d'utilisation destination.
Relation d'extension (« extends ») :
le cas d'utilisation source étend (précise) les
objectifs (comportements) du cas d'utilisation destination.
Package : regroupe les éléments
de modélisation suivant des critères purement
logiques.
Note ou documentation : documente un
élément du modèle.
A présent nous allons donner une vue des diagrammes de
cas d'utilisation réalisés.
32
Figure 3 : Cas Inscription
Pédagogique
33
Gestion des unités d'enseignement dans le cadre de la
reforme LMD à l'Université de Lomé
Figure 4 : s Mise à jour de
données
Cas de mise à jour
Les diagrammes qui suivent présentent de manière
schématique les cas d'utilisation liés à un
étudiant.
Figure 5 :Autres cas liés à
l'étudiant
Présenté et soutenu par Komi Klenam
ADJAFO-TRETU
34
Les diagrammes qui vont suivre présentent l'analyse
applicative et la conception. On modélise les aspects informatiques et
les rouages d'implémentation et on optimise les modèles.
3.1.3- Diagrammes des classes.
Ils représentent la structure des entités du
système.
Un diagramme de classes est une collection
d'éléments de modélisation statiques (classes,
paquetages...), qui montre la structure d'un modèle. Un diagramme de
classes fait abstraction des aspects dynamiques et temporels.
· Pour un modèle complexe, plusieurs diagrammes
de classes complémentaires doivent être construits.
On peut par exemple se focaliser sur :
o les classes qui participent à un cas d'utilisation (cf.
collaboration), o les classes associées dans la réalisation d'un
scénario précis,
o les classes qui composent un paquetage,
La sémantique
Attributs : c'est l'ensemble des informations
se présentant sous forme de variables et permettant de
représenter l'état de l'objet.
Méthodes ou opérations : C'est
une fonction liée à un objet.
Expression des cardinalités d'une relation en UML
:
n : exactement "n" (n, entier naturel > 0)
n..m: de "n" à "m" (entiers naturels ou variables, m >
n)
* : plusieurs (équivalent à "0..n" et "0..*")
n..*: "n" ou plus (n, entier naturel ou variable).
Dépendance: relation d'utilisation
unidirectionnelle et d'obsolescence(une modification de l'élément
dont on dépend, peut nécessiter une mise à jour de
l'élément dépendant). La flèche non pleine
représente l'héritage
Association n-aire : il s'agit d'une
association qui relie plus de deux classes.
Classe d'association : il s'agit d'une classe
qui réalise la navigation entre les instances d'autres classes. Elle est
représentée avec des pointillés .
Nous avons présenter premièrement les classes
documentées et ensuite le diagramme de classes présentant
l'analyse finale suite à certaines modifications apportées aux
différentes classes dégagées.
35
Figure 6 :La documentation des
classes.
36
Présenté et soutenu par Komi Klenam
ADJAFO-TRETU
37
Présenté et soutenu par Komi Klenam
ADJAFO-TRETU
La documentation des classes.
38
Présenté et soutenu par Komi Klenam
ADJAFO-TRETU
Présenté et soutenu par Komi Klenam
ADJAFO-TRETU
Suite et fin figure6 39
3.1.4-Diagrammes de déploiements
Ils représentent le réseau informatique supportant
le système et la manière dont les composants y sont
installés.
Sémantique
Relation entre les composants
Par souci de sécurité du réseau
Un établissement
CIC/CAFMICRO
Composant
Figure7 : Déploiement de
l'application
40
| 
