É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
^base.identifier(numClient)
Objet : activité ValidationEtat
Objet : flux de [inconnu] [connu]
[état] contrôle Afficher
Objet retourner
: flux des faux OK
artefacts ^ecran.afficherOK( )
: 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>
>> >

Image.java Component.jav
a