École Nationale des Sciences de
l’Informatique
ACOO
Chapitre 3
II2-ENSI
II2-ACOO
Plan
Partie 1 :
Les diagrammes de conception architecturale
Partie 2 :
Les diagrammes de conception
détaillée
Les diagrammes statiques
Les diagrammes dynamiques
DE L’ANALYSE À LA CONCEPTION DES
CLASSES
POSITIONNEMENT
Classification selon le point de vue/le
niveau d’abstraction
Algorithme du monde réel Algorithme du logiciel
(scénario) (scénario)
Objets du
Objets du Objets du
monde réel
logiciel langage
De quoi parle-t-on ? Comment ‘logique’ ? Comment ‘physique’ ?
Analyse Conception Code
Modèle conceptuel Modèle logique Modèle physique 4
POSITIONNEMENT
Où se situe les Diagrammes
structurels ?
Structurel
Vue Vue de
logique développement
Vue des cas
d’utilisation
Fonctionnel Vue de
Vue physique
Processus
Le DC et le DO sont les pièces maîtresses qui représentent
l’axe structurel d’un système et sa vue logique. 5
LES CONCEPTS SOUS-JACENT À LA
CONCEPTION (MODÈLE LOGIQUE)
Le résultat de la phase de conception
détaillée consiste en un document
contenant :
des diagrammes de classes décrivant la structure
statique,
des diagrammes associés aux aspects dynamiques
(diagrammes de séquence avec les classes de
conception, diagrammes états-transitions, diagrammes
d’actitivités et diagrammes de communication).
DIAGRAMME D’ANALYSE ≠ DIAGRAMME DE
CONCEPTION
Typage des attributs et des méthodes
Sens de navigation des relations
Rajout de détails, de cardinalité
Ajout de classes « utilitaires »
Prise en compte de contraintes d’implémentation
Tous ça est obligatoire maintenant
CONCEPTION DÉTAILLÉE DES CLASSES
Spécifier les visibilités des attributs et méthodes
Définir le type des attributs identifiés en analyse.
Type de base
Structure
Enumération
Conception des classes spécifiques
Conception détaillée des classes et des associations
INDICATEURS DE VISIBILITÉ
Public (+) : visible à l’extérieur de la classe
Protégé (#) : visible que dans la classe et ses sous-
classes
Privé (-) : visible dans la classe uniquement
Package (~) : visible dans la package uniquement
Par défaut, les attributs sont privés et les opérations
sont publiques
Remarques :
Utile lors de la conception et de l'implémentation, pas avant !
N'a pas de sens dans le modèle d’analyse
La sémantique exacte dépend du langage de programmation !
9
EXEMPLE
Date
- jour : int
- mois : int
- annee : int
Attribut calculé
- / noJourDansAnnee : int
- nomDesMois[12] : String={"janvier","février"...}
String={"janvier","février ...}
+ getJour() : int Attribut de classe
…
+ getFormatEtendu() : String
… Méthode de classe
+ getNomMois(in i : int) : String
10
CONCEPTION DÉTAILLÉE DES CLASSES
Spécifier les visibilités des attributs et méthodes
Définir le type des attributs identifiés en analyse.
Type de base
Structure
Enumération
Conception des classes spécifiques
Conception détaillée des classes et des associations
STRUCTURE
Définition : Ensemble d’attributs pouvant être regroupés.
<<structure>> <<structure>>
Date Adresse
numRue
jour rue
mois codePostal
ville
années pays Utilisation
Société
adrss: Adresse
dateDeCreation : Date
ENUMÉRATION
Définition : Ensemble de littéraux d’énumération,
<<enumeration>> <<enumeration>>
Jour Titre
Lundi Secretaire
Mardi President
Mercredi Tresorier
Jeudi VicePresident
Vendredi Membre
Samedi Utilisation
Dimanche
Association
nom : String
jourDeReunion : Jour
Responsable: Titre
CONCEPTION DÉTAILLÉE DES CLASSES :
C L A SS E S S P É C I F I QU E S 1 / 3
Classe emboîtée Classe
englobante
Déclarée à l’intérieure d’une autre
classe.
Classe interne
CONCEPTION DÉTAILLÉE DES CLASSES :
C L A SS E S S P É C I F I QU E S 2 / 3
Classe utilitaire
<<utilitaire>>
Les classes utilitaires: permettent Nom de la classe
de regrouper des éléments dans
un module sans pour autant
définir une classe complète.
Les classes utilitaires ne peuvent
être instanciées car elles ne sont
pas des types de données.
(Exemple: Classe Math, toutes les
méthodes sont statiques)
CONCEPTION DÉTAILLÉE DES CLASSES :
C L A SS E S S P É C I F I QU E S 3 / 3
Classe paramétrée (générique)
par exemple, List, Vector<String>,etc…
classe paramétrée
paramètres formels
paramètres effectifs
CONCEPTION DÉTAILLÉE DES ASSOCIATIONS
Spécifier la gestion des liens entre objets
1. Spécifier les contraintes de gestion
2. Spécifier les méthodes assurant la gestion
des liens
3. Préciser la portée des liens
Traiter les classes associatives
Optimiser la navigation
(1) Préciser les contraintes de gestion des liens
Par exemple :
• { ordered } : les éléments de la collection représentant le tissage des liens sont
ordonnés
• { NotUnique } : Il est possible d’avoir plus qu’un lien entre deux objets avec la
même association :répétitions possibles (UML2.0)
• { frozen } : le tissage des liens est fixé lors de la création et ne peut pas changer.
• { addOnly } : Il est possible de tisser de nouveaux liens mais impossible d’en
supprimer
lignes
Ligne
RelevéDeCompte Opération
*
{ordered,addOnly}
18
(3) Préciser la portée des associations
• Un lien existe dès lors qu'un objet possède une visibilité vis-à-vis d'un autre, c'est-à-
dire lorsqu'un objet a un rapport direct avec un autre
La portée visibilité des rôles
~ +, -, #
R
a b
-g +f
• Exemple:
APourCompte
salah : Client c1 : Compte
-titulaire +compte
OPTIMISER LA NAVIGATION
Ajouter un sens de navigation et/ou une c ontrainte d’appartenance
Ajouter de nouvelles associations,
Modifier/supprimer les anciennes associations
Exemple : Si on n’a besoin que de l’association a pour compte
1 0..*
Client Compte
titulaire compte
RAFFINER LES HIÉRARCHIES DE CLASSES
Les hiérarchies de classes ou classifications permettent de gérer la
complexité en ordonnant les objets au sein d’arborescences de
classes d’abstraction croissante.
La généralisation : il s’agit de prendre des classes existantes (déjà
mises en évidence) et de créer de nouvelles classes qui regroupent
leurs parties communes; il faut aller du plus spécifique vers le
plus général.
La spécialisation : il s’agit de sélectionner des classes existantes
(déjà identifiées) et d’en dériver de nouvelles classes plus
spécialisées, en spécifiant simplement les différences.
CLASSES ABSTRAITES
Une méthode abstraite : est une méthode dont on donne
uniquement le prototype (son implémentation est inconnue)
Si une classe possède une ou plusieurs méthodes abstraites elle
doit être déclarée abstraite
Une classe abstraite ne peut jamais être instanciée (seules les
classes non abstraites peuvent l’être)
Une classe héritant d’une classe abstraite doit donner une
implémentation à toutes les méthodes abstraites de sa super-
classe sinon elle est abstraite.
Les classes et les méthodes abstraites permettent de définir des
fonctionnalités sans spécifier leur implémentation.
LES CLASSES ABSTRAITES: EXEMPLE1
Figure
{abstraite}
centre : Point
translater()
surface() {abstraite}
Carre Cercle
coté : Double rayon : Double
surface() surface()
LES CLASSES ABSTRAITES: EXEMPLE2
D I VE R S IF I CAT IO N DE S I M P LÉ M E NTATI ON S
Le concept d’interface a été introduit dans UML pour modéliser
des techniques de description de composants qu’on trouve sur le
marché.
Une interface est la déclaration d’une collection d’opérations qui
peuvent être utilisées pour définir un service.
Les interfaces n’ont ni implémentation, ni attributs, ni états, ni
associations. Elles peuvent cependant disposer de relations de
généralisation.
INTERFACE & RÉALISATION
La réalisation est une relation sémantique entre une classe et
une interface. La classe doit donner l’implémentation de
toutes les méthodes de l’interface qu’elle réalise.
Une interface peut être réalisée par plusieurs classes
Une même classe peut réaliser plusieurs interfaces
Crédit
«utilise»
Entreprise Banque La classe Banque
réalise les deux
«utilise» interfaces Crédit et
Assurance
Client «utilise» «Interface»
Assurance
26
EXERCICE: DIAGRAMME DE CLASSES ?
public interface Dessinable { public class Cercle extends Figure {
public void dessiner ( ); private float rayon;
public void effacer ( ); private Point centre;
} public Cercle ( Point centre, float rayon) { ... }
abstract public class Figure implements public void dessiner ( ) { ... }
Dessinable { public void effacer ( ) { ... }
protected String couleur; }
protected String getCouleur ( ) { return public class Rectangle extends Figure {
couleur; } protected Point sommets[] = new Point[2];
protected void setCouleur ( String c ) { public Rectangle ( Point p1, Point p2) { ... }
couleur = c; } public void dessiner ( ) { ... }
} public void effacer ( ) { ... }
public class Point { }
private float x; public class Losange extends Figure {
private float y; protected Point sommets[] = new Point[2];
public float getX ( ) { return x; } public Losange ( Point p1, Point p2) { ... }
public float getY ( ) { return y; } public void dessiner ( ) { ... }
public void Point ( float x, float y) { ..} public void effacer ( ) { ... }
II2-ACOO
Plan
Partie 1 :
Les diagrammes de conception architecturale
Partie 2 :
Les diagrammes de conception
détaillée
Les diagrammes statiques
Les diagrammes dynamiques
Les diagrammes dynamiques
Diagrammes dynamiques de conception détaillée
Le diagramme de séquence
But : décrire les interactions entre objets (de la conception détaillée)
:Client :Menu :Loggin :Imprimante
retraitBillets( )
afficher( )
identifier( numRes)
rechercher(numRes )
[OK] : res
payer(somme) accepter(numClient )
valider(carte)
[carte OK]
imprimerBillet(res, numClient)
Les diagrammes dynamiques
Diagrammes dynamiques de conception détaillée
Le diagramme d’états transitions
But :
Décrire en détail le comportement des classes de conception détaillée
Validation
requête entry : Validation
éteindre Attente
do : identifier
exit :
Interrogation
Non identifié / annuler de la base
identifié
connu inconnu
Payé / imprimer Attente Paie
OK Erreur
entry : afficher prix
Impayé / annuler
Etat composite
Les diagrammes dynamiques
Diagrammes dynamiques de conception détaillée
Le diagramme d’activités
Buts :
1. Décrire en détail le comportement d’une opération
2. Modéliser les processus métiers
Opération : identifier client
Acteur 1 Acteur2
: activité
Interroger Activité
: sous base
Activité [ événement] processus
^[Link](numClient)
Objet : activité ValidationEtat
Objet : flux de [inconnu] [connu]
[état] contrôle Afficher
Objet retourner
: flux des faux OK
artefacts ^[Link]( )
: mise en
parallèle
: synchronisation
Les diagrammes dynamiques
Diagrammes dynamiques de conception détaillée
Le diagramme de communication
Buts :
1. Décrire l’interaction entre les objets
2. Valider les choix d’analyse et de conception (prototypage)
Aider à élaborer des diagrammes de classes de conception
1 : retraitBillets( )
1 : message : Client
x : ClasseA
: Menu
y : ClasseB [validation]
2 : message
3 : indentifier(numClient)
2 : afficher ( )
z : ClasseB
: Loggin
[Interrogation] 4.1 : accepter(numClient)
4.2 : refuser(numClient)
Exercice
1/ Que représente ce schéma? Quels types de vue et d'architecture
d'application modélise-t-il?
2/ Donnez une autre manière de modéliser en UML la réalisation et
l'utilisation de l'interface "ImageObserver"
<<interface>>
ImageObserv
er
<<use <<realize>
>> >
[Link] [Link]
a
