CONCEPTION des SYSTÈMES d`INFORMATION UML SOMMAIRE

Transcription

CONCEPTION des SYSTÈMES d’INFORMATION
UML
3 : Analyse des Données : le
Epitech 3 – Automne 2007
Bertrand LIAUDET
SOMMAIRE
ANALYSE DES DONNEES : DIAGRAMME DE CLASSES
2
1.
L’approche objet
3
2.
Le diagramme de classes
13
3.
Exercices corrigés
26
4.
Génération de C++
30
5.
Paquetages et vue logique
36
6.
TP : Visio
43
EPITECH - CSI - UML – Analyse des données - 2007-2008 - page 1/43- Bertrand LIAUDET
ANALYSE DES DONNEES :
DIAGRAMME DE CLASSES
Il est facile de décrire la méthode encore que son application exige à coup sûr savoir et
pratique.
Diagramme UML
ANALYSE DES
DONNEES
Diagramme de classes
La programmation fonctionnelle suit l’analyse fonctionnelle qui est calquée sur l’analyse
externe du problème. C’est une analyse descendante.
La programmation objet est moins intuitive que la programmation fonctionnelle. La
programmation objet s’intéresse au système en tant qu’ensemble d’objets en interaction. C’est
une analyse systémique.
Le diagramme de classe est le diagramme le plus important de la modélisation orientée objet. Il
contient les classes avec leurs méthodes. Mais il n’indique pas comment utiliser ces
méthodes. C’est une description statique du système. L’aspect dynamique sera apporté par les
diagrammes d’interaction (diagrammes de collaboration et de séquence).
La construction du diagramme de classes doit se faire après l’analyse fonctionnelle. Celle-ci,
bien réalisée, mettra utilement sur la voie d’un bon diagramme de classes.
La construction d’un diagramme de classes a intérêt à partir du concret : donc de diagrammes
d’interaction entre les objets (instances de classe) qui sont construits à partir de l’analyse
fonctionnelle (les diagrammes de séquences des scénarios).
A partir de ces premiers objets, on pourra commencer à construire le diagramme de classe.
1.
L’approche objet
Avantages de l’approche objet
•
Stabilité de la modélisation par rapport aux entités du monde réel.
•
Construction itérative facilité par le couplage faible entre les composants.
•
Possibilité de réutiliser les éléments d’un développement à un autre.
•
Simplicité du modèle. 5 concepts fondateurs :
1.
Objets
2.
Messages
3.
Classes
4.
L’héritage
5.
Polymorphisme
Programmation objet vs. programmation prodécurale
•
La construction d’un logiciel est une suite d’itération du genre : division-réunion. Il faut
décomposer (diviser) pour comprendre. Il faut composer - réunir - pour construire.
•
Le processus de décomposition a été traditionnellement dirigé par un critère fonctionnel.
Les fonctions du système sont identifiées puis décomposées en sous-fonctions, et ainsi de
suite jusqu’à l’obtention d’éléments simples programmables sous la forme de fonction et de
procédure. C’est la méthode cartésienne : analytique.
•
L’architecture du système est le reflet des fonctions du système. Il y a un fort couplage
entre architecture et fonctions.
•
L’approche objet ajoute à l’approche cartésienne une démarche systémique qui considère le
système comme un tout organisé. Elle propose une méthode de décomposition non pas
basée uniquement sur ce que le système fait, mais sur ce que le système est et fait.
Autrement dit, on s’intéresse aux données (ce que le système est) et aux fonction appliquées
à ces données (ce que le système fait).
•
En programmation fonctionnelle structurée, on a, schématiquement, une vision systémique
des fonctionnalités d’un côté et des données structurées radicalement séparées des
fonctionnalités de l’autre. En programmation objet, on ajoute à la vision systémique des
fonctionnalités (analyse fonctionnelle), une vision systémique des données (diagramme de
classe) auxquelles on associe directement les fonctionnalités.
Les objets
Objet = une identité + un état + un comportement
On dit aussi :
Objet = données (état) + méthodes (comportement)
D’un point de vue abstrait, un objet informatique est une représentation d’un objet du monde
extérieur. Un objet informatique est une sorte de miroir qui renvoie une image (une
connaissance) d’un objet qui existe dans le monde perçu par l’utilisateur.
D’un point de vue informatique, un objet informatique est une variable avec un ou plusieurs
champs qui seront manipulées (en lecture ou en écriture) par les méthodes de l’objets.
Etat
Valeurs instantanées des attributs (données) d’un objet.
Certaines partie de l’état peuvent évoluer au cours du temps.
D’autres parties de l’état peuvent être constantes.
Comportement
Le comportement regroupe les méthodes d’un objet.
Les méthodes sont des fonctions qui permettent d’accéder aux valeurs des attributs d’un objet.
Ces méthodes sont déclenchées par des stimulations externes : des messages envoyés par
d’autres objets (c’est-à-dire des appels de méthodes).
On parle aussi de compétences pour les méthodes d’un objet.
Identité
Chaque objet a une existence propre (une place en mémoire).
Les objets sont différenciés par leurs noms (comme un nom de variable).
Olivier
M. Liaudet
Toutefois, il est parfois difficile de nommer tous les objets : on peut donc les nommer du nom de
leur classe, avec « : » devant.
: Eleve
: Professeur
Chaque objet possède une identité attribuée de manière implicite à la création de l’objet et
jamais modifiée.
On peut donner un attribut clé à l’objet, qu’on appelle « clé naturelle » (par exemple, un numéro
de sécurité sociale). Il s’agit toutefois d’un artifice de réalisation. Cette clé appartient à l’état de
l’objet. Le concept d’identité est indépendant du concept d’état.
Encapsulation
Pour accéder, en consultation ou en modification, à l’état d’un objet (à ses données), il faut
passer par ses fonctions (ses méthodes). Il faut que ces fonctions soient appelées par d’autres
fonctions qui peuvent être des méthodes du même objet ou d’un autre.
Quand une méthode d’un objet 1 est appelée par une méthode d’un objet 2, on dit que l’objet 2
a envoyé un message à l’objet 1.
Donc, de façon générale, pour accéder à l’état d’un objet, il faut lui envoyer un message.
Les méthodes sont l’interface obligatoire d’accès aux données d’un objet.
Persistance des objets
Un objet persistant sauvegarde son état dans un système de stockage permanent, de sorte qu’il
est possible d’arrêter le processus qui l’a créé sans perdre l’information représentée par l’objet.
C’est la passivation de l’objet.
L’activation de l’objet consiste à reconstruire l’objet dans l’état dans lequel on l’avait
sauvegarder.
Par défaut, les objets ne sont pas persistants.
Transmission des objets
La transmission des objets consiste à faire passer un objet, par un moyen de communication
quelconque, d’un système à un autre.
Scénario de communication
L’objet révèle son vrai rôle et sa vraie responsabilité lorsque, par l’intermédiaire de l’envoi de
messages, il s’insère dans un scénario de communication (c’est-à-dire un cas d’utilisation
concret du système).
Atterir
: Tour de contrôle
: Avion
[en vol]
L’objet « Tour de contrôle » a dans ses données un objet avion ou un pointeur sur un objet
avion. Une méthode de l’objet « Tour de contrôle » peut donc envoyer un message à l’objet
« Avion ».
Communication entre objets
Un système informatique peut être vu comme une société d’objets qui communiquent entre eux
pour réaliser les fonctionnalités de l’application.
Le comportement global d’une application repose sur la communication
entre les objets qui la composent.
De ce fait, l’étude des relations entre les objets du domaine est de première importance dans la
modélisation objet.
De plus, la première communication étant la communication entre les acteurs (externes) et le
système, on peut aussi partir de l’analyse fonctionnelle pour trouver les classes.
Collaboration et communication
On peut parler indifféremment de communication ou de collaboration entre objet.
Cependant, on parle plutôt de collaboration quand on décrit les communications nécessaires
pour réaliser une fonctionnalité. La collaboration est plutôt finalisée.
On parle par contre indifféremment de communication pour une communication atomique ou
une collaboration.
3 catégories d’objet fonction de leur mode communication
Un objet peut être émetteur de message sans jamais en recevoir, destinataire de message sans
jamais en émettre, émetteur et destinataire de message.
• Les acteurs
Ce sont des objets à l’origine d’une interaction. Ce sont des objets actifs. Il possède un « fil
d’exécution » : un thread. Ils passent la main aux autres objets.
• Les serveurs
Ce sont des objets qui ne sont jamais à l’origine d’une interaction. Ils sont toujours
destinataire des messages. Ce sont des objets passifs.
• Les agents
Ce sont des objets qui cumulent les caractéristiques des acteurs et des serveurs. Ils peuvent
interagir avec les autres objets à tout moment, de leur propre initiative ou suite à une
sollicitation externe.
Les agents permettent le mécanisme de délégation : un objet se comporte comme un paravent
devant un autre objet. Les agents découplent les acteurs des serveurs en introduisant une
indirection dans le mécanisme de propagation des messages.
Le concept de message
•
L’unité de communication entre les objets est le message.
•
Le message est ce qui permet de reconstituer une fonction de l’application par la mise en
collaboration d’un groupe d’objets.
Messages concrets :
•
L’appel de procédure
•
L’événement discret (changement d’état)
•
L’interruption
•
Etc.
Le message acquiert toute sa force d’intégration lorsqu’il est associé au polymorphisme et à la
liaison dynamique.
Synchronisation des messages
La synchronisation précise la nature de la communication et les règles qui régissent le passage
des messages.
Message synchrone
Une fois le message envoyé, l’expéditeur est bloqué jusqu’à ce que le destinataire accepte le
message.
Un appel de procédure est un message synchrone.
Diagramme de collaboration correspondant :
Envoi simple
Un destinataire
Un expéditeur
Diagramme de séquence correspondant :
Un destinataire
Un expéditeur
Envoi simple
retour implicite
Message asynchrone
Il n’interrompt pas l’exécution de l’expéditeur.
L’expéditeur envoie le message sans savoir quand ni même si le message sera traité par le
destinataire.
Diagramme de collaboration correspondant :
Envoi simple
Un expéditeur
Un destinataire
Diagramme de séquence correspondant :
Un destinataire
Un expéditeur
Envoi simple
retour implicite
Demi flèche ou flèche simple peuvent représenter les envois asynchrones.
Message dérobant
Un message dérobant déclenche une opération seulement si le destinataire s’est préalablement
mis en attente du message.
Dans le cas d’un message synchrone, l’expéditeur accepte d’attendre ; dans le cas d’un message
dérobant, le destinataire accepte d’attendre.
Envoi dérobant
Message minuté
Un message minuté bloque l’expéditeur pendant un temps donné, en attendant la prise en
compte de l’envoi par le destinataire, ou la durée spécifiée dans le message.
Envoi minuté
Classe
Une classe est la description d’un ensemble d’objets ayant les mêmes méthodes et les mêmes
types de données.
La classe peut être vue comme une extension de la notion de type.
Les objets apparaissent alors comme des variables de type classe.
La démarche d’abstraction objet : un nouveau paradigme
Elle consiste à regrouper les éléments qui se ressemblent et à distinguer des structures de plus
haut niveau d’abstraction, débarrassées de détails inutiles.
La classe décrit le domaine de définition d’un ensemble d’objets.
Les généralités sont contenues dans la classe.
Les particularités sont contenues dans les objets.
Un objet est une instance de classe.
Avec les langages objet, le programmeur peut construire une représentation informatique des
abstractions qu’il a l’habitude de manipuler mentalement, sans traduction vers des concepts de
plus bas niveau, comme les variables, les types abstraits de données et les fonctions des langages
non objet.
Les langages objet réduisent la distance entre notre façon de raisonner et le langage compris par
les ordinateurs, de sorte qu’il est plus facile de réaliser une application avec un langage objet
qu’avec un langage procédural, même si l’approche objet demande un remise en cause des
habitudes acquises.
Les attributs d’une classe
Ils sont définis par un nom, un type et éventuellement une valeur initiale.
Chat
Nom :string
Age : int
Classe Chat
: Chat
Nom= ”Minou”
Age= 1
Un objet Chat
Les principales catégories d’opérations
•
Les constructeurs : pour créer les objets (création).
•
Les destructeurs : pour détruire les objet (destruction).
•
Les sélecteurs : pour renvoyer tout ou partie de l’état d’un objet (consultation).
•
Les modificateurs : pour modifier tout ou partie de l’état d’un objet (modification).
•
Les itérateurs : pour consulter le contenu d’une structure de données qui contient plusieurs
objets.
L’héritage
L’héritage est une technique qui permet de construire une classe (espèce) en lui faisant hériter
des attributs et des méthodes d’autres classes (genre, super-classe).
L’héritage est utilisé pour construire de nouvelles classes, pour classer les objets et pour la
conception abstraite (avec le polymorphisme).
Animaux
Chats
Chiens
Principe de substitution
On peut substituer n’importe quel objet d’une super-classe par n’importe quel objet d’une sous-classe.
La spécialisation ajoute des attributs et des opérations mais ni n’en détruit, ni n’en modifie.
Classe abstraite
Une super classe (classe genre) peut être instanciée ou pas.
Une classe qui ne peut pas être instanciée est une classe abstraite. Elle est super classe d’autre
classe qui seront instanciées. Les classes servent donc surtout pour la classification et le
polymorphisme.
Attention à l’héritage des associations !
Les associations sont héritées mais pas complètement ! ! !
Le plus souvent, les contraintes des associations ne sont pas transmises automatiquement de la superclasse vers la sous-classe. Les contraintes sont le plus souvent traduites par un bout de code implanté
dans la réalisation d’une opération. Comme les langages permettent la redéfinition des opérations dans
les sous-classes, les programmeurs peuvent involontairement introduire des incohérences entre la
spécification d’une super-classe et sa réalisation dans une des sous-classes.
Polymorphisme
•
Le polymorphisme décrit la caractéristique d’un élément qui peut prendre plusieurs formes
(l’eau peut être à l’état solide, liquide ou gazeux).
•
Le polymorphisme désigne le principe qui fait qu’un nom d’objet peut désigner des objets
différents (des instances de classes différentes) issus d’une même arborescence.
•
Le polymorphisme désigne surtout le polymorphisme d’opération : la possibilité de
déclencher des opérations différentes en réponse à un même message.
•
Le polymorphisme permet de manipuler des objets sans en connaître précisément le type.
•
Le polymorphisme est lié à la notion d’héritage. On peut manipuler des objets dont le type
est abstrait au niveau de la classe générale (abstraite). Le type deviendra concret quand
l’objet deviendra concret et portera le type de sa classe spécialisée.
•
Le polymorphisme n’influence pas l’analyse organique, mais il en dépend. Il ne faut pas
penser l’analyse en terme de polymorphisme, mais en terme d’abstraction. L’analyse en
terme d’abstraction rend possible le polymorphisme.
•
Les bénéfices du polymorphisme sont un plus grand découplage entre les objets : ils sont
avant tout récoltés durant la maintenance.
Vocabulaire
Instance
Un objet est une instance d’une classe.
L’instance est une notion générale : un lien est une instance d’une association ; une variable peut
être dite une instance d’un type.
Méthode et opération
La spécification d’une méthode correspond à son entête : on l’appelle aussi : l’opération.
L’implémentation de la méthode (l’algorithme), c’est ce qu’on appelle la méthode.
Méthode abstraite
Une méthode est dite abstraite quand on connaît son entête mais pas la manière dont elle peut
être réalisée.
Classe abstraite
Une classe est dite abstraite quand elle ne s’instancie pas directement et qu’elle sert donc
uniquement de spécification.
C’est une classe qui ne contient pas d’objets. Elle contient des sous-classes qui elles
contiendront des objets.
En phase de modélisation, une classe est aussi dite abstraite quand elle, ou une de ses classes
parents, définit au moins une méthode abstraite (et donc qu’elle ne peut pas, au moins
provisoirement, être instanciée).
2.
Le diagramme de classes
Notions générales sur les classes et formalisme UML
Classe
Personne
Nom de la classe
prénom : String
dateNaissance : Date
Liste d’attributs
sexe : {‘M’, ‘F’}
calculAge() : Integer
Liste des méthodes
renvoyerNom() : String
Le nom de la classe doit être significatif. Il commence par une majuscule.
Le nom de la classe peut être préfixé par son ou ses paquetages d’appartenance.
Si personne est dans le paquetage A, lui même dans le paquetage B, on écrira
B ::A ::Personne
Classe abstraite
FigureGéométrique {abstract}
Rectangle
typeTrait : Trait
dessiner() {abstract}
Dessiner()
FigurePleine {abstract}
La classe figure géométrique est abstraite parce quelle contient une méthode abstraite, c’est-àdire une méthode dont on connaît l’entête mais pas le corps.
Encapsulation
L’occultation des détails de réalisation est appelée : encapsulation. L’encapsulation présente un
double avantage :
•
Les données encapsulées dans les objets sont protégées.
•
Les utilisateurs d’une abstraction ne dépendent pas de sa réalisation, mais seulement de sa
spécification, ce qui réduit le couplage dans les modèles.
Le degré d’encapsulation peut être paramétré : c’est la notion de visibilité.
Visibilité des attributs et des méthodes
Par défaut, les attributs d’une classe sont « private » : les attributs d’un objet sont encapsulées
dans l’objet. Les attributs ne sont manipulable que par les méthodes de l’objet.
Par défaut, les méthodes d’une classe sont « public » : les méthodes d’un objet sont accessibles
par tous les « clients » de l’objet.
UML définit quatre niveaux de visibilité
La visibilité des attributs et des méthodes est précisée par des mot-clés ou des symboles
Symbole
Mot-clé
Signification
+
Public
Visible partout
Visible dans tout le paquetage où la classe est définie
#
Protected
-
Private
Visible dans la classe, dans ses sous-classes et par les amis.
Visible uniquement dans la classe et par les amis.
Attribut de Classe
Certains attributs ont une valeur identique pour tous les objets de la classe. Ce sont des sortes
de constantes définies au niveau de la classe. Ce sont les attributs de classe.
En UML, ces attributs sont listés avec les autres, mais ils sont soulignés.
Symbole
Mot-clé
Souligné
Signification
Valeur identique pour tous les objets de la classe
Attribut dérivé
Certains attributs peuvent être calculés à partir d’autres attributs de la classe.
En UML, ces attributs sont listés avec les autres, mais ils sont précédés d’un « / ».
Symbole
/
Mot-clé
Signification
Attribut dont la valeur est calculée à partir de celle d’autres
attributs
Méthode de Classe
Quand une méthode ne porte pas sur les attributs d’objet de la classe mais uniquement sur des
attributs de classe ou sur des valeurs constantes, cette méthode est dite méthode de classe.
En UML, ces méthodes sont listées avec les autres, mais elles sont soulignées.
Compartiment des responsabilités
Le compartiment des « responsabilités » liste l’ensemble des tâches que la classe doit réaliser.
C’est une façon de lister les méthodes dont on n’a pas encore défini l’entête. Quand la
conception sera achevée, ce compartiment devra disparaître.
Compartiment des exceptions
Le compartiment des « exceptions » liste les situations exceptionnelles devant être gérées par la
classe. Là encore, quand la conception sera achevée, ce compartiment devra disparaître.
Les classes actives
Les classes actives sont des classes dont les objets, eux-mêmes actifs, possède un flot de
contrôle propre se déroulant en parallèle avec ceux des autres objets actifs. Classe et objet actif
sont représentés par un cadre plus épais ou avec un trait double.
Relation de dépendance
Les relations de dépendances sont utilisées quand il existe une relation sémantique entre
plusieurs éléments qui n’est pas de nature structurelle.
Notons particulièrement :
<<ami>> est une relation de permission qui précise que l’élément source à accès à un l’élément
destination quelle que soit la visibilité de ce dernier.
<<utilise>> est une relation d’utilisation qui précise que l’élément source requiert la présence de
l’élément destination pour son bon fonctionnement.
A
<<ami>>
B
Associations entre classes
Comme dans le modèle entité-association (modèle conceptuel des données MERISE), on peut,
avec UML, établir des relations (des associations) entre les classes.
Il y a trois types d’associations entre classes :
•
Les associations simples
•
Les associations d’agrégation de composition
•
Les associations d’héritage
Les deux premières expriment des relations entre les objets de deux classes (ou plus).
L’association d’héritage permettent de définir des sous-ensembles dans un ensemble ou
inversement de définir un ensemble à partir de sous-ensembles. Elle exprime une relation entre
les classes et pas entre les objets.
Les associations simples
Association
Une association représente une relation structurelle entre des classes d’objets.
Une ligne entre deux classes représente une association.
Association binaire (arité = 2)
La plupart des associations sont binaires : elles ne réunissent que deux classes.
Association ternaire et plus (arité >2)
L’association et ses différents ornements
multiplicité
nom
multiplicité
rôle
rôle
Nom et sens de lecture des associations
L’association peut avoir un nom. Le nom explicite le lien entre les deux classes. C’est souvent
un verbe. Le sens de lecture
permet de préciser dans quel sens il faut lire le nom.
Personne
travaille pour
entreprise
Rôles des extrémités des associations
Personne
Employé
entreprise
Employeur
Le rôle est un pseudo-attribut. On peut préciser sa visibilité (+, -, #)
La plupart du temps, le nommage des rôles est limité en fonction de la navigabilité.
Navigabilité des associations
A
B
L’association n’est navigable que dans le sens de A vers B.
Une association navigable uniquement dans un sens peut être vue comme une demi-association.
Multiplicité (cardinalité) des associations
Chaque extrémité de l’association peut porter une indication de multiplicité qui montre combien
d’objets de la classe considérée peuvent être liés à un objet de l’autre classe.
1
Un et un seul
0..1
Zéro ou un
N
N (entier naturel qui peut être précisé)
M..N
De M à N (entiers naturels qui peuvent être précisés)
*
De zéro à plusieurs
0..*
De zéro à plusieurs
1..*
De un à plusieurs
Personne
Employé
0..*
1
Département
Employeur
Chaque personne est employée dans un département et un seul.
Les départements sont employeur de 0 ou plusieurs personnes.
Attention :
Les cardinalités sont mises à l’inverse du modèle entité-association (MCD) :
Personne
1.1
Emploi
0..N
Département
Classe-Association
Une association peut avoir ses propriétés qui ne sont disponibles dans aucune des classes qu’elle
relie.
Pour cela, on relie une classe à une association :
Personne
Employé
0..*
1
Département
Employeur
Poste
Fonction
Salaire
Date
La classe-association correspond à l’association non-hiérarchique du MCD.
Contraintes sur les associations
Toutes sortes de contraintes peuvent être définies sur les associations.
Certaines s’appliquent à une seule association :
•
{ordonné} : précise qu’une collection (0..*) doit être ordonnée.
Personne
Compte
1
0..*
{ordonné}
Certaines s’appliquent à plusieurs associations :
•
{sous ensemble} : précise qu’une collection est incluse dans une autre collection
•
{ou exclusif} : pour un objet donné, une seule association, parmi les associations contraintes
par le ou exclusif, est possible.
Parents d’élèves
*
{sous-ensemble}
Classe
d’école
2
Personne
*
Délégués
Qualification des associations (restriction)
La qualification des associations consiste à réduire le nombre d’occurrences d’une association.
Elle ne s’applique qu’à des association dont la multiplicité est supérieure à 1 (sinon, le nombre
d’occurrences ne peut pas être réduit).
donateurs
1
*
dons
Dans ce cas, la qualification ne peut s’appliquer qu’aux donateurs (un donateur peut faire
plusieurs dons).
donateurs
attribut qualifiant
1
dons
L’attribut qualifiant peut être extrait de la classe des dons.
donateurs
numéro du don
1
0.1
dons
donateurs
année du don
1
0.n
dons
ou encore :
La qualification restreint la relation aux seuls couples concernés par un qualifieur.
La qualification des associations est une forme d’association contrainte.
Agrégation et composition
Agrégation
L’agrégation est une association non symétrique dans laquelle une des extrémités, l’agrégat,
joue un rôle prédominant par rapport à l’autre extrémité, l’élément agrégé.
Agrégat
Elément agrégé
Quelle que soit l’arité de l’association, il ne peut y avoir qu’un seul agrégat.
L’agrégation représente en général une relation d’inclusion structurelle ou comportementale.
Ecole
Salle
Chaise
Fenêtre
Une école est composé de plusieurs salles, qui elles-mêmes sont composées de plusieurs fenêtres
et plusieurs chaises.
En général, les agrégations sont navigables uniquement dans le sens Agrégat vers Elément
agrégé.
En général, les agrégations sont des associations 1..*
Composition
La composition est un cas particulier d’agrégation.
Composite
Composant
0..1
*
La composition implique une coïncidence des durées de vie des composants et du composite : la
destruction du composite implique la destruction de tous ses composants.
La composition implique aussi une contrainte sur les valeurs de multiplicité du côté de
l’agrégat : elle ne peut être que 0 ou 1 : un composant ne peut pas être partageable.
Ecole
Salle
Chaise
Fenêtre
Si on supprime la salle, les fenêtres sont aussi supprimées. Ce qui n’est pas le cas des chaises.
Généralisation
Le terme généralisation désigne une relation de classification entre un élément plus général (le
genre) et un élément plus spécifique (l’espèce). La classe Chat est une espèce de la classe
Animal.
On parle de classe spécifique, ou sous-classe, ou classe enfant.
Et de classe générale, ou sur-classe, ou super classe, ou classe parent, ou classe mère.
Chat
Animal
Girafe
Chien
Ou encore :
Animal
Chat
Chien
Girafe
Distinction entre généralisation et composition
Un chat est un animal : c’est une généralisation. La classe chat est une partie de la classe animal.
Chaque objet « chat-x » appartient à la classe « chat » et à la classe « animal ».
Un chat a deux oreilles : c’est une composition. L’objet « oreille » est une partie de l’objet
« chat ». Pour tout objet « chat », il existe deux objets « oreille ».
Héritage
La classe spécifique contient des attributs et des méthodes qui lui sont propres.
La classe spécifique hérite de tous les attributs, méthodes et associations de la classe générale,
sauf pour ceux qui sont privées.
Une classe spécifique peut redéfinir une ou plusieurs méthodes. C’est le principe de la surcharge
des opérations. Un objet utilise les opérations les plus spécialisées dans la hiérarchie des classes.
Un objet spécifique peut être utilisé partout où un objet général est attendu : partout où on
attend un animal, on peut utiliser un chat.
Généralisation multiple
Une sous-classe peut avoir plusieurs sur-classes
Les classes Interface
Présentation
Une classe « interface » prend en charge la communication entre le système et son
environnement, que ce soit un utilisateur ou un autre système.
Ce comportement est caractérisé par un ensemble d’opérations ayant une visibilité « public ».
Ces opérations sont réalisées dans des classes « entité ».
L’interface peut regrouper des opérations communes à plusieurs classes.
Caractéristiques
Une interface est une classe avec le stéréotype « interface ».
C’est une classe particulière :
•
elle est abstraite : ell n’a pas d’instance qui la réalisent (pas d’objets).
•
elle ne contient pas d’attributs.
Une interface est réalisée par la classe à laquelle elle est reliée.
Les opérations de l’interface sont toutes abstraites (et définies dans la ou les classes qui la
réalisent).
Représentation des interfaces
une classe
une interface
une classe
<<interface>>
Vue A
La flèche
signifie que la source réalise la destination
<<interface>> est le nom d’un stéréotype
On peut préciser le stéréotype du lien : « réalise » (ce n’est pas obligé).
une classe
<<interface>>
<<réalise>>
Vue A
Si plusieurs classes partagent les mêmes méthodes d’interface (et non plus seulement opérations
abstraites), une seule classe réalisera l’interface, les autres l’utilisent : stéréotype « use ».
Classe 1
Classe 2
<<use>>
ou encore :
Classe 1
Classe 2
Méthode
Pour trouver les interfaces, il faut examiner toutes les paires : ( acteurs physiques - scénario ).
On a intérêt à créer une classe interface par cas et sous-cas d’utilisation (include et extend).
Les interfaces se trouvent à un haut niveau d’abstraction. On commence par renseigner les
besoins en interfaces utilisateur sans les implémenter. Ces classes seront affinées au fur et à
mesure.
On a intérêt à regrouper les interfaces dans un paquetage à part.
Les classes de variables et d’opérations globales : stéréotype <<utility>>
<<utility>>
Math
PI :Real=3,14
Sinus (angle): Real
Cosinus(angle): Real
Tangente(Angle):Real
Les classes paramétrables : template
Une classe paramétrable est un modèle de classe.
Une classe paramétrable a des paramètres formels.
Une classe paramétrable est liée à des paramètres effectifs pour devenir une classe paramétrée
qui pourra être instanciée.
Paramètres
formels
Classe paramétrable
Ce genre de classe n’apparaît généralement pas en analyse.
Les classes actives
Par défaut, les classes sont passives.
Une classe active possède son propre flot d’exécution.
Les classes actives peuvent être des <<processus>> ou des <<thread >>.
Un processus est un flot de contrôle lourd qui s’exécute dans un espace d’adressage
indépendant.
Un thread est un flot de contrôle léger qui s’exécute à l’intérieur d’un processus.
Une classe active cho un ou plusieurs flots de contrôle.
Représentation UML
Le rectangle de la classe est en gras ou en trait double.
Construction d’un diagramme de classes : 3 grands types de classe
3 points de vue guident la modélisation du diagramme des classes :
•
Le point de vue statique
•
Le point de vue fonctionnel
•
Le point de vue dynamique
Le point de vue statique : les classe « entité » ou « métier »
•
Il met l’accent sur les concepts du domaine et les associations qui les relient.
•
Les classes correspondantes sont parfois stéréotypées par le nom « entité » ou « entity »:
c’est le point de vue qui se rapproche le plus du MCD.
Méthode de construction du diagramme des classes « entité » :
•
Analyse du type de celle faite pour un MCD. Il s’agit de trouver les classes (entités), les
attributs et les associations à partir de la description « métier » du domaine.
•
En même temps ou à la suite, ajouter les méthodes (les responsabilités au sens large)
•
En même temps ou à la suite, organiser et simplifier le diagramme en utilisant l’héritage.
•
En même temps ou à la suite, ajouter les classes « interface » et « control »
•
Itérer et affiner le modèle
Le point de vue fonctionnel : les classes « interface »
•
Il met l’accent sur les interfaces : interfaces utilisateur ou interfaces avec d’autres systèmes.
•
Les classes correspondantes sont stéréotypées par le nom « interface » ou « boundary ».
•
Les classes « interface » constituent la partie du système qui dépend de l’environnement.
Méthode pour trouver les classes « interface » :
•
Examiner les paires acteur - scénario (occurrence de cas d’utilisation).
•
Les classes correspondent en gros à une étape de l’interaction avec l’utilisateur. Si on a
décrit des cas d’utilisation inclus ou étendus, chaque cas d’utilisation correspondra à une
classe interface. Dans le cas d’une extension, le cas d’utilisation qui regroupe les extensions
correspondra aussi à une classe interface.
•
Ne pas hésiter à travailler à un haut niveau d’abstraction : ces classes seront affinées
pendant la conception.
Le point de vue dynamique : les classes « control »
•
Il met l’accent sur l’implémentation.
•
Les classes correspondantes sont stéréotypées par le nom « control ».
•
Les classes « control » modélisent le séquençage comportemental (une séquence est une
suite ordonnée d’opérations ; le séquençage est la détermination de la séquence).
Méthode pour trouver les classes « control » :
•
Ajouter une classe « control » pour chaque paire acteur / cas d’utilisation.
•
Les classes « control » définies par le couple acteur/cas d’utilisation ne sont qu’un point de
départ : au cours de l’avancement de l’analyse, elle pourront être éliminées, éclatées ou
fusionnées.
Attention !!!
Les classes « interface » et « control » ne doivent pas conduire à dissocier le comportement et
les données :
•
Elles ne doivent pas conduire à revenir à la programmation procédurale !
•
Elles ne doivent pas appauvrir le diagramme des classes « entité ».
Le point de vue essentiel reste le point de vue des classes « entité ». Les deux autres points de
vue servent :
•
A rendre plus concrète la modélisation
•
A partir d’un niveau d’abstraction élevé
•
A affiner le diagramme des classes « entité ».
3.
Exercices corrigés
L’employé
Trouver le diagramme de classe de la situation suivante :
Un employé est caractérisé par son nom, son prénom, son sexe et son âge. Les responsabilités
de la classe sont, entre autres, le calcul de l’âge, le calcul du revenu de l’employé et le calcul des
charges patronales (ce que l’employeur paie en plus du salaire de l’employé). Les attributs de la
classe sont privés. Le nom, le prénom et l’âge de l’employé font partie de l’interface de la classe
employé.
Deux types de revenus sont envisagés : le salaire et toutes les autres sources de revenu. On
calcule les charges en appliquant un coefficient de 15 % sur le salaire et de 20% sur les autres
revenus.
Un objet de la classe « employé » peut être créé à partir du nom et de la date de naissance.
(d’après UML-2, édition Pearson Education).
Solution avec classe interface « lolipop » :
Employe
Interface Employés
-Charges Salaire : float = 0,5
-ChargesAutreRevenus : float = 0,2
-Nom : string
-Prénom : string
-Sexe : char
-DateNais : Date
+getNom() : string
+getPrenom() : string
+calculAge() : int
+Employe(entrée nom : string, entrée dateNais : Date) : Employe
+CalculRevenuNet() : float
+CalculCharges() : float
Représentation avec classe interface héritée :
«interface»Interface Employés
+getNom() : string
+calculAge() : int
Employe
-Charges Salaire : float = 0,5
-ChargesAutreRevenus : float = 0,2
-Nom : string
-Prénom : string
-Sexe : char
-DateNais : Date
+getNom() : string
+calculAge() : int
+Employe(entrée nom : string, entrée dateNais : Date) : Employe
+CalculRevenuNet() : float
+CalculCharges() : float
Explications complémentaires :
•
Les 3 opérations de la classes interfaces sont abstraites, comme la classe interface. C’est
dans la classe employé que les opérations seront réalisées.
•
2 attributs de classe (soulignés)
•
4 attributs d’instance
•
Les 3 premières opérations sont des opérations d’interface (calculAge, getNom,
getPrenom). Rien ne les distingue visuellement des opérations de la classe. Mais dans la
structure Visio, elles sont rangées dans la classe interface Employés.
•
On peut aussi représenter la classe interface comme une classe « normale » en montrant les
opérations de la classe. Rappelons que les classes interface sont des classes abstraites
•
Les 3 opérations suivantes sont celles de la classe Employés. Les opérations en italiques
sont celles qui sont encore abstraites. On ne connaît pas l’algorithme (on ne sait pas
comment on calcule le salaire et les charges patronales). On parle de « responsabilités »
pour les méthodes abstraites et de « méthode » pour les méthodes concrètes.
•
Remarque : il existe des opérations par défaut qu’il n’est pas nécessaire de préciser :
•
•
un constructeur
un destructeurs
un getAttribut par attribut
un setAttribut par attribut
Constructeurs C ++ correspondant :
─
─
Employes ( ) ;
//## constructeur de base, par défaut
Employes (const Employes &right) ;
//## constructeur de recopie, par défaut
Ou : Employes (const Employes &) ;
─
Employes (string, date);
//## constructeur spécifique
•
•
Destructeur C ++ correspondant :
─
~Employes ( ) ;
//## destructeur par défaut
Get et Set C ++ correspondant :
─
─
─
─
─
const String getNom () const;
void setNom (String value);
Ou : void setNom (String);
const String get_Prenom () const;
void setPrenom (String value);
Ou : void setPrenom (String);
etc.
L’hôtel
Trouver le diagramme de classes de la situation suivante :
Un hôtel est composé d’au moins deux chambres. Chaque chambre dispose d’une salle d’eau qui
peut être une douche ou une salle de bain. L’hôtel héberge des personnes. Il peut employer du
personnel et est dirigé par un des employés. L’hôtel a les caractéristiques suivantes : une
adresse, le nombre de pièces, la catégorie. Une chambre est caractérisée par le nombre et le type
de lits, le prix et le numéro. On peut calculer le chiffre d’affaires et le prix de la chambre en
fonction du nombre d’occupants. On gère aussi la réservation des chambres. On peut connaître à
tout moment la disponibilité des chambres.
(d’après UML-2, édition Pearson Education).
Solution :
Hotel
-Nom : string
-Adresse : string
-Catégorie : int
+calculCA() : float
+disponibilitéChambre() : Liste de Chambre
+réserverChambre()
+facturerOccupation()
Chambre
1
2..*
-Numéro : int
-nbLitSimple : int
-nbLitDouble : int
-nbLitEnfant : int
-salleDEau : string
facturation
Occupation
*
*
-dateArrivée : Date
-dateDépart : Date
-nbAdulte : int
-nbEnfant : int
-coût : float
+calculCoût()
emploie
est dirigé par
Personne
-Nom : string
-Prénom : string
-Adresse : string
*
1..*
-employés
-directeur
Client
Employé
1
Explications complémentaires :
•
L’hôtel est composé de chambres. Si on détruit l’hôtel, les chambres sont détruites. En
réalité, ce n’est pas un très bon exemple, à moins de considérer que l’hôtel est aussi
composé d’occupations et d’employés. La composition crée une liste de référence par
valeurs (et non pas par adresse comme dans le cas de l’agrégation simple).
•
Tous les liens qui partent de l’hôtel ne sont navigables que dans le sens de l’hôtel vers les
classes liées. En effet, c’est à partir de l’hôtel quelles sont les chambres de l’hôtel, quelles
sont les chambres disponibles, quelles sont les employés de l’hôtel. On pourra aussi calculer
le chiffre d’affaire à partir de l’occupation des chambres.
•
Les réservations sont gérées comme des occupations.
•
DisponibilitéChambre renvoie la liste des chambres. On l’utilisera pour faire la réservation.
•
RéserverChambre ne ressort rien : on met à jour les données et c’est tout.
•
Facturer l’occupation ne renvoie rien : le résultat est directement affecté à l’attribut coût de
l’occupation.
•
CalculCA renvoie le résultat. On en fera ensuite ce qu’on veut.
•
Personnes est une classe abstraite (en italique). Elle n’est jamais instanciée.
4.
Génération de C++
Classe
Classe A sans navigabilité vers B
A
a1 : Double
a2 : Date
B
1
b1 : Boolean
b2 : Integer
class A {
public:
//## Constructors (generated)
A();
A(const A &right);
//## Destructor (generated)
~A();
//## Assignment Operation (generated)
A & operator=(const A &right);
//## Equality Operations (generated)
int operator==(const A &right) const;
int operator!=(const A &right) const;
//## Le générateur de code génère un constructeur de base, un constructeur
de recopie, un destructeur, un opérateur d’affectation, un opérateur
d’égalité et un opérateur de différence.
private: //## Get and Set Operations for Class Attributes (generated)
//## Attribute: a1
const Double get_a1 () const;
void set_a1 (Double value);
//## Attribute: a2
const Date get_a2 () const;
void set_a2 (Date value);
//## Le générateur de code génère un un get et un set pour tous les
attributs. A noter que ces méthodes sont « private ».
private: // Data Members
// for Class Attributes
Double a1;
Date a2;
};
//## Get and Set Operations for Class Attributes (inline)
inline const Double A::get_a1 () const {
return a1;
}
inline void A::set_a1 (Double value) {
a1 = value;
}
inline const Date A::get_a2 () const {
return a2;
}
inline void A::set_a2 (Date value) {
a2 = value;
}
Classe et navigabilité
Classe A avec navigabilité vers 1 B
A
a1 : Double
a2 : Date
B
1
b1 : Boolean
b2 : Integer
class A {
public:
//## Get and Set Operations for Associations (generated)
const B * get_the_B () const;
void set_the_B (B * value);
// for Class Attributes
Double a1;
Date a2;
// for Associations
B *the_B;
};
//## Le générateur de code ajoute un attribut dans la classe A : « the_B »
qui est un pointeur sur un objet B. Il ajoute aussi un un get et un set pour
« the_B ». A noter que ces méthodes sont « public ».
//## Get and Set Operations for Associations (inline)
inline const B * A::get_the_B () const {
return the_B;
}
inline void A::set_the_B (B * value) {
the_B = value;
}
Classe A avec navigabilité vers 1..15 B
A
a1 : Double
a2 : Date
1..15
B
b1 : Boolean
b2 : Integer
class A {
public:
const BoundedSetByReference<B,15> get_the_B () const;
void set_the_B (BoundedSetByReference<B,15> value);
// for Associations
BoundedSetByReference<B,15> the_B;
};
//## Get and Set Operations for Associations (inline)
inline const BoundedSetByReference<B,15> A::get_the_B () const {
return the_B;
}
inline void A::set_the_B (BoundedSetByReference<B,15> value) {
the_B = value;
}
Classe, navigabilité et agrégation
Classe A avec navigabilité et agrégation vers 1 B
B * the_B;
//## On travaille par référence. En détruisant A, on ne détruit pas les 15
B.
A noter que c’est la même chose que la navigabilité toute seule. La notion
d’agrégation n’est qu’une façon d’appuyer sur le rôle plus fort de A par
rapport à B.
Classe A avec navigabilité et agrégation vers 15 B
B * the_B[15];
Classe A avec navigabilité et agrégation vers 0..1 B
B * the_B;
Classe A avec navigabilité et agrégation vers 1..10 B
BundedSetByReference <B, 10> the_B;
Classe A avec navigabilité et agrégation vers 1..n B
UnBundedSetByReference the_B;
Classe A avec navigabilité et agrégation vers n B
UnBundedSetByReference the_B
Classe, navigabilité et composition
Classe A avec navigabilité et composition vers 1 B
B the_B;
//## On travaille par valeur. En détruisant A, on détruit B (ou les B dans
les cas suivants).
Classe A avec navigabilité et composition vers 15 B
B the_B[15];
Classe A avec navigabilité et composition vers 0..1 B
OptionalByValue the_B;
Classe A avec navigabilité et composition vers 1..n B
UnbundedSetByValue the_B;
Classe A avec navigabilité et composition vers n B
UnbundedSetByValue the_B
Classe association
1
1..5
A
B
C
class C {
public:
const BoundedSetByReference<B,5> get_the_B () const;
void set_the_B (BoundedSetByReference<B,5> value);
const A * get_the_A () const;
void set_the_A (A * value);
// for Associations
A *the_A;
BoundedSetByReference<B,5> the_B;
};
Héritage
A
B
#include “A.h”
class B : public A {
...
};
5.
Paquetages et vue logique
Présentation
La vue logique est constituée par les classes et les paquetages.
L’organisation en paquetage est un élément clé de l’architecture.
Les principaux paquetages apparaissent très tôt dans la phase d’analyse.
Les paquetages
Un paquetage permet de regrouper les classes pour faciliter leur emploi, leur maintenance et leur
réutilisation.
Dans la version 2 d’UML, un paquetage peut regrouper n’importe quels éléments de
modélisations (les cas d’utilisation, etc.).
Client
Inclusion de paquetage
Un paquetage peut inclure un autre paquetage.
Un paquetage peut être inclus dans deux paquetages différents.
Les paquetages de cas d’utilisation définissent des sous-domaines fonctionnels du système
étudiés. Ces sous-domaines peuvent partager des cas d’utilisation.
Banque
Compte
Transaction
Nommage des paquetages
Banque ::Compte désigne le paquetage Compte défini dans le paquetage Banque
Si le cas d’utilisation « Retirer argent » se trouve dans le paquetage transaction, on écrira :
Banque ::Compte ::Retirer argent pour le désigner.
Dépendances entre paquetages
<<importe>> : ajoute les éléments du paquetage destination au paquetage source.
Si on ne précise pas le stéréotype, c’est « importe » par défaut.
<<importe>>
Les éléments du paquetage destination sont visibles dans le paquetage source. Toutefois, il n’y a
pas de relation de possession.
Paquetage métiers, paquetages interfaces et paquetages techniques
La vue logique est élaborée au début de la phase d’analyse architectonique avec les classes
« métier ».
Dès cette étape, on distinguera entre les classes métiers et les classes interfaces. On regroupera
aussi les classes interfaces dans un paquetage interface.
•
Paquetage Interface : il permet de regrouper les classes interfaces et ainsi de définir les
classes métier indépendamment de leur utilisation.
Ensuite, en fonction des choix de programmation effectués (langage, gestion d’une base de
données, gestion des erreurs, etc.), on pourra avoir d’autres paquetages dans l’architecture de la
vue logique :
•
Paquetage BaseDeDonnées : il permet de gérer le problème de la permanence des données.
•
Paquetage IHM : il contient des classes fournies par le langage de programmation.
•
Paquetage ClassesDeBase (global) : c’est un paquetage qui est utilisé par tous les autres
paquetages du système.
•
PaquetageGestionDesErreurs (global) : c’est un paquetage spécialisé dans la gestion des
erreurs et qui est utilisé par tous les autres paquetages du système.
Enfin, l’analyse des classes métiers permettra de les regrouper dans différents paquetages
métiers.
•
Paquetages Métiers : ils permettent de définir des ensembles de classes portables d’un projet
à un autre.
Amélioration de l’analyse des classes : notion de métaclasse
Une métaclasse est une classe (2) d’une classe (1). La métaclasse est telle qu’un objet de cette
classe contient des données et des opérations qui caractérisent plusieurs objets de la classe dont
elle est issue : classe (1).
Exemple :
Soit la classe des vols d’une compagnie aérienne. Cette classe contient les attributs suivants :
Vol
numéro
dateDépart
heureDépart
dateArrivée
heureArrivée
jour
Le numéro du vol caractérise tous les vols qui ont lieu le même jour de la semaine à la même
heure.
En réalité, cette classe modélise deux classes : la métaclasse des « genres de vols » VolGénérique - et la classe des vols concrets.
La classe des vols concrets ne contient que les attributs : dateDépart et dateArrivée.
VolGénérique
Numéro
heureDépart
heureArrivée
jour
Vol
1
décrit
*
dateDépart
dateArrivée
Détermination des paquetages métier et réduction du couplage
À partir de la première analyse des classes métiers, on va réfléchir à leur regroupement dans
différents paquetages métiers.
Cette analyse est en partie logique : on regroupe ensemble ce qui va ensemble, et en partie
intuitive : parfois les limites ne sont pas évidentes à trouver.
Le choix des frontières entre les paquetages se fera aussi en fonction du couplage entre les
paquetages c’est-à-dire de la navigabilité entre les classes.
Paquetage 1
Paquetage 2
Classe 1
Classe 2
Réduction de la navigabilité entre les classes et du couplage entre les paquetages :
Paquetage 1
Paquetage 2
Classe 1
Classe 2
Le choix de la navigabilité est fait en fonction de l’utilisation prévue pour les classes. Ce choix
doit être justifié.
Paquetage réutilisable
Un paquetage est réutilisable quand il ne dépend d’aucun autre paquetage.
Paquetage généralisé - paquetage spécialisé
Si on est amené à déterminer des classes abstraites qui seront donc spécialisées par d’autres
classes, on peut créer une frontière de paquetage entre la classe abstraite et ses classes
spécialisées.
Le paquetage contenant la classe abstraite est alors dit « paquetage généralisé ». Il n’est pas dit
paquetage abstrait car il peut aussi, par ailleurs, contenir des classes concrètes.
Le paquetage contenant les classes concrète est alors dit « paquetage spécialisé ».
La relation entre les deux paquetages est une relation de généralisation :
Paquetage spécialisé
Paquetage généralisé
Classe 1
Classe 2
Paquetage paramétré (ou générique ou template) et bound package
UML 2 introduit la notion de paquetage paramétré (ou paquetage générique, ou paquetage
template).
Les paquetages liés au paquetage paramétré sont appelés bound package.
Cette notion est encore très expérimentale !
Notion de pattern et de framework
Présentation
Les patterns sont des micro-architectures finies.
Les frameworks dont des architectures semi-finies.
Ils permettent d’élever la granularité de la modélisation, et d’éviter de réinventer la roue à
chaque projet !
Classes
Pattern
Framework
Granularité croissante
Caractéristiques des patterns
•
Les patterns synthétisent l’élaboration itérative de solutions éprouvées, qui ont évolué au
cours du temps pour fournir des structures toujours plus flexibles et plus facilement
réutilisables.
•
Les patterns forment un vocabulaire de très haut niveau et très expressif. Les informaticiens
habitués aux patterns identifient, nomment et parlent des problèmes et des solutions en
utilisant ce vocabulaire.
•
Les patterns sont indépendants de tout langage de programmation, ce qui leur confère une
grande généricité. En contrepartie, il n’y a pas de réutilisation de code et un effort de
programmation est requis pour les mettre en œuvre.
Les différents types de patterns
•
Les patterns de conception (design patterns) : ce sont les plus populaires car ce sont les
patterns des informaticiens.
•
Les patterns d’analyse ou patterns métier : les deux notions sont équivalentes. Ils
dépendent d’un secteur d’activité particulier.
•
Les patterns d’architecture : ils décrivent la structure des architectures logicielles, comme
la structuration en couches.
•
Les patterns organisationnels : ils fournissent des solutions à des problèmes
organisationnels, telle l’organisation des activités de développement logiciel.
•
Les patterns d’implémentation : ils expliquent comment exploiter un langage de
programmation pour résoudre certains problèmes typiques.
•
Les patterns pédagogiques : ils décrivent des solutions récurrentes dans le domaine de
l’apprentissage.
Exemple de design pattern : Le pattern « composite »
*
1
Elément
Nœud
Feuille
Ce pattern est décrit dans « Design Patterns : Elements of Reusable Object-Oriented Software,
E. Gamma et al., 1995, Addison-Wesley.
Il fournit une solution pour modéliser les arbres.
Caractéristiques des frameworks
•
Les frameworks définissent des ossatures pour des familles d’applications.
•
L’architecture d’un framework est générique, volumineuse et complexe.
•
Un framework est une architecture semi-finie dictant l’architecture générale de l’application
ou du sous-système à construire.
•
Un framework peut être représenté par : les cas d’utilisation (le comportement externe), les
paquetages (la macrostructure statique) et les collaborations (les patterns).
•
Il faut fournir un effort important pour comprendre l’architecture générale des classes qui
composent un framework et ainsi pour le maîtriser (cas des MFC : IHM sous Windows :
même si la création d’une fenêtre est une tâche aisée, il faut compter 6 mois pour maîtriser
les MFC).
•
Contrairement aux patterns, un framework est implémenté afin de permettre le
développement rapide de nouvelles applications. Il dépend ainsi du langage de
programmation utilisé pour son implémentation.
Classification des frameworks selon leur domaine d’utilisation
•
Les frameworks métier (framework verticaux) : ils encapsulent l’expertise d’un domaine
particulier.
•
Les frameworks d’application (framework horizontaux) : ils encapsulent l’expertise
technique applicable à plusieurs domaines.
Classification des frameworks selon leur structure
•
Les frameworks boîte blanche : ce sont des applications semi-finies dont la spécialisation
se fait par définition de sous-classes. Il faut connaître la structure interne des super-classes
pour les spécialiser.
•
Les frameworks boîte noire .
Intérêt des frameworks
Du fait de l’architecture générique qu’il propose, le framework permet :
•
Productivité accrue.
•
Prototypage rapide.
•
Évolution facilitée.
•
Maintenance facilitée.
6.
TP : Visio
Diagramme de classes
Créer un diagramme de structure statique.
Classe
Mettre des classes
Double cliquer sur la classe.
Changer le nom.
On peut choisir « is abstract » pour les classes abstraites.
Interface
Mettre une interface.
Relier la à la classe.
Avec bouton droit, on passe de la représentation « lolipop » à la représentation « classe ».
Attribut
Choisir la « catégories - attributs » : on va définir les attributs.
Pour définir le type des attributs, faire « propriété » puis « type ».
Pour les attributs de classe, choisir « portéePropriété » : « classificateur » et non pas « instance »
+ « modifiable » à « gelé ».
Méthode
Choisir la « catégories - opérations » : on va définir les opérations.
Pour définir le type des opérations, faire « propriété » puis « type ».
Généralisation
Choisir « Généralisation »
Lier les classes avec les points d’accroche.
Liens
Choisir « Association binaire », « Composition » ou « Classe d’association ».
Lier les classes avec les points d’accroche.
Double cliquer sur le lien. Modifier le nom de terminaison, la multiplicité, le isnavigable et
l’agrégation pour chaque terminaison de l’association.
On peut donner un nom à l’association et l’afficher avec bouton droit, option d’affichage des
formes.

CONCEPTION des SYSTÈMES d`INFORMATION UML SOMMAIRE

Transcription

Documents pareils

Laetitia Asse - Jose Antunes

TD Modelisation Vente Par Correspondance

VILLE DU TOUQUET-PARIS

Laetitia Asse - Jose Antunes

UML-2-par-la-pratique-etude-de-cas-et-exercices

UML

UML 2 - Modeliser une application web

IDENTIFICATION DESCRIPTION • Principes d`analyse informatique

Notes maîtrise iup MIAGe

CSI - UML – TP 1