2.3. Classe :
C'est un types d'éléments qui partagent les
mêmes propriétés (attributs, méthodes, relations,
sémantique).
Si les propriétés définies par la classe
sont immuables et ne dépendent pas des éléments, on parle
d'attributs ou de variables de classe et de méthodes de classes,
inversement si leur contenu dépend de l'élément on parle
d'attribut ou de variable d'instances et de méthodes.
Les propriétés d'une classe ont une
visibilité, c'est-à-dire que l'accès aux
propriétés d'une classe par une autre est
contrôlé.
Nom de classe
Attributs
Méthodes
Fig01. Représentation graphique des
classes.
2.4. Association :
Une association est une relation entre deux classes (association
binaire) ou plus (association n-aire), qui décrit les connexions
structurelles entre leurs instances.
Une association indique donc qu'il peut y avoir des liens entre
des instances des classes associées.
Entreprise : ENSEM
|
Un lien
|
|
|
Ahmed: Personne
|
|
Une association
|
|
|
ENSEM
|
Personne
|
|
|
|
Fig02. Les liens entre l'Entreprise et les Personnes
sont
tous des instances entre la classe Entreprise et la classe
. Agrégation :
L'agrégation est la forme particulière
d'association entre deux classes indiquant que des instances d'une classe, sont
contenues (ou agrégées) dans une instance d'une autre classe.
Dans l'agrégation les deux objets en relation sont
distingués : l'un est un composant de l'autre.
Au niveau logique, on considère que le composé est
responsable de la gestion de ses composants (c'est le composé qui
crée, modifie, ou détruit ses composants).
Agrégat Composant
Fig03. Représentation graphique de
l'agrégation
2.6. Généralisation et
spécialisation :
|
Une classe peut ~tre la généralisation d'une ou
plusieurs autres classes. Ces classes sont alors des spécialisations de
cette classe.
|
La generalisation Reunir des objets possedant des
caracteristiques communes dans une nouvelle classe plus generale appelee
super-classe.
La specialisation séparer des objets suivant des
caractéristiques plus spécifiques dans une nouvelle classe plus
spécifique appelée sous-classe
Fig04. Hiérarchies de classes
2.7. Héritage :
L'héritage est un principe de la programmation
orientée objet, permettant entre autres la reutilisabilite et
l'adaptabilite des objets. Elle se nomme ainsi car le principe est en quelque
sorte le mrme que celui d'un arbre genealogique. Ce principe est base sur des
classes dont les « filles » heritent des caracteristiques de leur(s)
« mère(s)».
2.8. Encapsulation :
L'encapsulation est un mecanisme consistant à
rassembler les donnees et les methodes au sein d'une structure en cachant
l'implementation de l'objet, c'est-à-dire en empêchant
l'accès aux donnees par un autre moyen que les services proposes.
L'encapsulation permet donc de garantir l'integrite des donnees contenues dans
l'objet.
2.9. Polymorphisme :
Le polymorphisme designe un concept de la theorie des types,
selon lequel un nom
d'objet peut désigner des instances de classes
différentes issues d'une mrme
arborescence.
La possibilite de redefinir une methode dans des classes
heritant d'une classe de base s'appelle la specialisation. Il est alors
possible d'appeler la methode d'un objet sans se soucier de son type
intrinsèque : il s'agit du polymorphisme d'heritage.
Ceci permet de faire abstraction des details des classes
specialisees d'une famille d'objet, en les masquant par une interface commune
(qui est la classe de base)
3. La notation UML : 3.1. Historique
:
Les premières methodes d'analyse
(années 70): Decoupe cartesienne (fonctionnelle et
hierarchique) d'un système.
L'approche systemique (années 80)
: Modelisation des donnees + modelisation des traitements (Merise
...).
L'emergence des methodes objet (1990-1995)
: Prise de conscience de l'importance d'une methode
specifiquement objet :
- comment structurer un système sans centrer l'analyse
uniquement sur les donnees ou uniquement sur les traitements (mais sur les
deux) ?
- Plus de 50 methodes objet sont apparues durant cette periode
(Booch, ClasseRelation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) !
- Aucun methode ne s'est reellement imposee. Les premiers
consensus (1995)
- OMT (James Rumbaugh) : vues statiques,
dynamiques et fonctionnelles d'un système
* issue du centre de R&D de General Electric.
* Notation graphique riche et lisible.
- OOD (Grady Booch) : vues logiques et
physiques du système
* Definie pour le DOD, afin de rationaliser de developpement
d'applications ADA, puis C++.
|
* Ne couvre pas la phase d'analyse dans ses 1ères
versions (preconise SADT).
* Introduit le concept de package (element d'organisation des
modèles). - OOSE (Ivar Jacobson) : couvre tout le cycle
de developpement
* Issue d'un centre de developpement d'Ericsson, en
Suède.
|
* La méthodologie repose sur l'analyse des besoins des
utilisateurs.
L'unification et la normalisation des
méthodes (1995-1997) : en octobre 1994, G.
Booch (père fondateur de la méthode Booch) et J. Rumbaugh
(principal auteur de la méthode OMT) ont décidé de
travailler ensemble pour unifier leurs méthodes au sein de la
société Rational Software. Un an après, I . Jacobson
(auteur de la méthode OOSE et des cas d'utilisation) a rejoint Rational
Software pour travailler sur
l'unification.
Les travaux sur ce langage ont continué avec son
adoption par de grands acteurs industriels comme HP, Microsoft, Oracle ou
Unisys. Ce travail a abouti en 1997 à UML 1.0. Le langage a
été soumis par Rational Software et ses partenaires à
l'OMG comme réponse à un appel d'offres sur la standardisation
des langages de modélisation.
Fig05. L'évolution de la norme UML
L'appel d'offres de l'OMG a recueilli un avis favorable,
puisque 6 réponses concurrentes sont parvenues à l'OMG. IBM et
Object Time (méthode ROOM pour les systèmes temps réel
réactifs) ont décidé de rejoindre l'équipe UML ;
leur proposition était en fait une extension d'UML 1.0. Certains autres
auteurs qui ont répondu à l'appel d'offres ont abandonné
leur proposition pour rejoindre à leur tour UML. En novembre 1997, UML a
été adapté par l'OMG.
. Définition :
UML (Langage de Modélisation Unifié) est une
notation utilisée en tant qu'outil de modélisation des
applications construites avec des langages objets.
Dans ce contexte et devant le foisonnement de nouvelles
méthodes de conception « orientée objet », l'Object
Management Group (OMG) a eu comme objectif de définir une notation
standard utilisable dans les développements informatiques basés
sur l'objet. C'est ainsi qu'est apparu UML (Unified Modified Language «
langage de modélisation objet unifié »), qui est issu de la
fusion des méthodes suivantes :
OMT (Object Modelling Technique) conçue par James
Rumbaugh. OOSE (Object Oriented Software Engineering) conçue par Grady
Booch. OOD (Object Oriented Design) conçue par Ivar Jacobson.
3.3. Objectif :
UML est un langage qui permet de
représenter des modèles, mais il ne définit pas le
processus d'élaboration des modèles.
UML est avant tout un support de communication
performant, qui facilite la représentation et la compréhension de
solutions objet.
UML est une représentation graphique, qui
s'intéresse à un aspect précis du modèle ; c'est
une perspective du modèle.
UML n'introduit pas d'éléments de
modélisation propres à une activité (analyse,
conception...) ; le langage reste le même à tous les niveaux
d'abstraction.
3.4. Les principes symboles utilisés
:
Les principes symboles utilisés dans notre étude,
et précisément dans les diagrammes d'UML sont regroupés
dans le tableau ci-dessous :
|
Symbole
|
Description
|
|
|
Acteur
|
|
|
|
: Nom l1 l'REjW
|
Objet
|
|
Connexion
|
&1N11'YtiliNIIIRn
|
|
Association
|
|
|
|
|
|
|
|
|
|
|
|
Agrégation
|
|
Début
|
|
Fin
|
|
Etat
|
|
|
|
|
|
[Condition]
|
Les conditions
|
|
1 ° Yd
|
|
|
|
|
|
|
|
Etat
|
Evénement [condition]
|
Etat
|
|
|
|
Les diagrammes d'UML :
UML permet de définir et de visualiser un modèle,
à l'aide de diagrammes. . Définition d'un diagramme
UML :
Un diagramme UML est une représentation graphique, qui
s'intéresse à un aspect précis du modèle. C'est une
perspective du modèle, pas "le modèle".
Chaque type de diagramme UML possède une structure (les
types des éléments de modélisation qui le composent sont
prédéfinis).
Un type de diagramme UML véhicule une sémantique
précise (un type de diagramme offre toujours la même vue d'un
système).
Par extension et abus de langage, un diagramme UML est aussi un
modèle (un diagramme modélise un aspect du modèle
global).
. Caractéristiques des diagrammes UML
:
Les diagrammes UML supportent l'abstraction. Leur niveau de
détail caractérise le niveau d'abstraction du modèle.
La structure des diagrammes UML et la notation graphique des
éléments de modélisation est normalisée (document
"UML notation guide").
. Les différents types de diagrammes UML
: Il existe 2 types de vues du système qui comportent
chacune leurs propres diagrammes :
a- les vues statiques :
*diagrammes de cas d'utilisation *diagrammes d'objets
*diagrammes de classes
* diagrammes de composants * diagrammes de déploiement
b- les vues dynamiques :
* diagrammes de collaboration * diagrammes de séquence
* diagrammes d'états-transitions * diagrammes
d'activités
. Les diagrammes de cas d'utilisation
:
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.
. Eléments de modélisation des cas
d'utilisation
a- L'acteur : la première
étape de modélisation consiste à définir le
périmètre
du système, à définir le contour de
l'organisation et à le modéliser.
|
Toute entité qui est en dehors de cette organisation et
qui interagit avec elle est appelé acteur selon UML.
|
|
|
|
b- Le cas d'utilisation : le cas
d'utilisation (ou use case) correspond à un objectif du système,
motivé par un besoin d'un ou plusieurs acteurs.
L'ensemble des use cases décrit les objectifs (le but) du
système.
c- La relation: elle exprime
l'interaction existant entre un acteur et un cas d'utilisation.
: Client
Fig06. Exemple de diagramme de cas
d'utilisation
Connexion
. Les diagrammes de classes :
le diagramme de classes exprime la structure statique du
système en termes de classes et de relations entre ces classes.
L'intér~t du diagramme de classe est de modéliser
les entités du systèm d'information.
Le diagramme de classe permet de représenter l'ensemble
des informations finalisées qui sont gérées par le
domaine. Ces informations sont structurées,
c'est-à-dire qu'elles ont regroupées dans des
classes. Le diagramme met en évidence d'éventuelles relations
entre ces classes.
Le diagramme de classes comporte 6 concepts : (classe,
attribut, identifiant, relation, opération, généralisation
/ spécialisation)
Nom : String
Date _naissance : entier
Age : String
Personne
Appartement
N-Immeuble: Entier Etage : Entier
Nb-Pièces : Entier
Fig07. Exemple de diagramme de classe
3.8. Les diagrammes d'objet : le
diagramme d'objets permet de mettre en évidence des liens entre les
objets. Les objets, instances de classes, sont reliés par des liens,
instances d'associations.
A l'exception de la multiplicité, qui est explicitement
indiquée, le diagramm d'objets utilise les mrmes concepts que le
diagramme de classes. Ils sont essentiellement utilisés pour comprendre
ou illustrer des parties complexes d'un diagramme de classes.
Salarié : Martin
Salarié : Dupont
Salarié : Durand
Fig08. Exemple de diagramme d'objet
3.9. Les diagrammes de déploiement :
les diagrammes de déploiement montrent la disposition
physique des différents matériels (les noeuds) qui entrent dans
la composition d'un système et la répartition des instances de
composants, processus et objets qui « vivent » sur ces
matériels.
Les diagrammes de déploiement sont donc très utiles
pour modéliser l'architecture physique d'un système.
3.10. Les diagrammes de collaboration :
le diagramme de collaboration permet de mettre en évidence les
interactions entre les différents objets du système.
Dans le cadre de l'analyse, il sera utilisé
- pour préciser le contexte dans lequel chaque objet
évolue
- pour mettre en évidence les dépendances entre les
différents objets impliqués dans l'exécution d'un
processus ou d'un cas d'utilisation.
Un diagramme de collaboration fait apparaître les
interactions entre des objets et les messages qu'ils échangent.
: Ascenseur
: Cabine
: Cabine
: Cabine
1 : Monter
3 : Fermer
2 : Allumer
Fig09. Exemple de diagramme de collaboration
. Les diagrammes de séquence :
le diagramme de séquence est une variante du diagramme de
collaboration.
Par opposition aux diagrammes de collaboration, les diagrammes
de séquence possèdent intrinsèquement une dimension
temporelle mais ne représente pas explicitement les liens entre les
objets.
Le diagramme de séquence permet de visualiser les
messages par une lecture de haut en bas. L'axe vertical représente le
temps, l'axe horizontal les objets qui collaborent. Une ligne verticale en
pointillé est attachée à chaque objet et représente
sa durée de vie.
Appelant
Ligne téléphonique
Appelé
Décroche
Tonalité
Numérotation
Indication de sonnerie Sonnerie
Décroche
Fig10. Exemple de diagramme de
séquence
Allo
. Les diagrammes
d'états-transitions:
ils ont pour rôle de représenter les traitements
(opérations) qui vont gérer le domaine étudié. Ils
définissent l'enchaînement des états de classe et font donc
apparaître l'ordonnancement des travaux.
Le diagramme d'états-transition est associé
à une classe pour laquelle on gère différents
états : il permet de représenter tous les
états possibles ainsi que les événements qui provoquent
les changements d'état.
Caractéristiques et règles de
construction :
a-Etat : un état correspond
à une situation durable dans laquelle se trouvent les objets d'une
classe.
On lui associe les règles de gestion et les
activités particulières.
b- Evénements et transitions :
un objet passe d'un état à un autre suite à
un événement, certain événement
pouvant ne pas provoquer de changement d'état. Une
transition est une relation entre 2 états. Elle est
orientée ce qui signifie que l'état 2 est possible si certains
événements sont vérifiés .Sa
représentation symbolique est une flèche sur laquelle est
annoté l'événement qui concourt au
changement d'état.
Fig11. Exemple de diagramme
d'états-transitions
[Après acquisition]
Disponible
[Après emprunt]
Non disponible
[Ouvrage abîmé ou non
restitué]
. Les diagrammes d'activités:
UML permet de représenter graphiquement le comportement d'une
méthode ou le déroulement d'un cas d'utilisation, à l'aide
de diagrammes d'activités (une variante des diagrammes
d'états-transitions).
Une activité représente une exécution d'un
mécanisme, un déroulement d'étapes
séquentielles.
Le passage d'une activité vers une autre est
matérialisé par une transition.
Les transitions sont déclenchées par la fin d'une
activité et provoquent le début immédiat d'une autre
(elles sont automatiques).
En théorie, tous les mécanismes dynamiques
pourraient être décrits par un diagramme d'activités, mais
seuls les mécanismes complexes ou intéressants méritent
d'être représentés.
Préparation de la commande
Attente de livraison suivie de la commande
Mise en stock de la marchandise
Fig12. Exemple de diagramme
d'activités
. Les diagrammes de composants: les
diagrammes de composants permettent de décrire l'architecture physique
et statique d'une application en termes de modules : fichiers sources,
librairies, exécutables, etc. IO11P RQI4-It11lI11P B4-114-n11oeDvI4-11pK
VqD4-11d4-111P odèles de la vue logique avec l'environnement de
développement.
Les dépendances entre composants permettent notamment
d'identifier les contraintes de compilation et de mettre en évidence la
réutilisation de composants.
Les composants peuvent être organisés en
paquetages, qui définissent des soussystèmes. Les
sous-systèmes organisent la vue des composants (de réalisation)
d'un système. Ils permettent de gérer la complexité, par
encapsulation des détails d'implémentation.
Le processus unifiés :
Un processus de développement définit une
séquence d'étapes, en partie ordonnée, qui concoure
à l'obtention d'un système logiciel ou à
l'évolution d'un système existant, pour produire des logiciels de
qualité, qui répondent aux besoins des utilisateurs dans des
temps et des coûts prévisibles.
Architecture, Pattern, Savoir-faire, sont des aspects qui
voient leur importance
dans le processus de développement bien
établie. Cependant, les modèles de
conception (design
patterns) ne font que commencer à être intégrés dans
les outils,
et d'une manière rarement normative. Il en est de mrme
pour la prise en compte des architectures logicielles.
L'explicitation de ces informations sous forme de
méta-modèles standard constitue un préliminaire à
leur opérationnalité et à la généralisation
de leur utilisation.
| 
