CoursPOO UML

UE : INF1327
Conception, programmation objet avancé et méthodologie de la

production d'applications
1
Présentation
• Produire une conception détaillée en appliquant des

patrons de conception, la mettre en œuvre en utilisant des
bonnes pratiques de programmation orientée objet.
2
Objectifs
• Approfondissement de la modélisation objet pour

l’analyse, la conception et la programmation
• Compréhension et mise en œuvre de patrons de
conception (design pattern), éléments d'architecture
logicielle
• Notions avancées de programmation orientée objet
• Sensibilisation aux tests
3
Compétences acquises
• Analyse d’une solution informatique

• Conception technique d’une solution informatique
• Réalisation d’une solution informatique
• tests
4
Prérequis
• Bases de la programmation orientée objet

• Bases de la conception orientée objet
5
Plan du cours
Partie1: Rappel modélisation UML

Partie 2: Bonnes pratiques du génie logiciel
6
Partie1: Rappel modélisation UML
• I. Rappel sur quelques notions

• II. Modélisation orientée objet
7
I. Rappel sur quelques notions
1. Notion sur la qualité d’un logiciel

Utilité: adéquation entre le logiciel et les besoins des utilisateurs
Utilisabilité: facilité et satisfaction dans l’utilisation du logiciel
Fiabilité: capacité d'un logiciel de rendre des résultats corrects
Interopérabilité: interactions avec d'autres logiciels
Performance: utilisation raisonnable des ressources
Portabilité: capacité à fonctionner dans un environnement
matériel ou logiciel différent de son environnement initial
Facilité de maintenance: doit permettre une extensibilité et
corrections assez faciles
8
2. Cycle de vie
Pour obtenir un logiciel de qualité, il faut en maîtriser le processus
d'élaboration.
• La vie d'un logiciel est composée de différentes étapes.
• La succession de ces étapes forme le cycle de vie du logiciel.
• Il faut contrôler la succession de ces différentes étapes
 Etapes du développement
• Étude de faisabilité
• Spécification: déterminer les fonctionnalités du logiciel.
• Conception: déterminer la façon dont le logiciel fournit les différentes
fonctionnalités recherchées.
• Codage
• Tests: essayer le logiciel sur des données d'exemple pour s'assurer qu'il
fonctionne correctement.
• Maintenance
9
3. Définitions
Modélisation: Présentation sous forme de modèle formel. C’ est
la représentation d'un système complexe sous forme de
modèles.
Modèle: une représentation abstraite et simplifiée (i.e. qui exclut
certains détails), d’une entité (phénomène, processus, système,
etc.) du monde réel en vue de le décrire, de l’expliquer ou de le
prévoir
Objet: quelque chose de tangible appartenant au monde réel
10
4. Langages de modélisation
Un langage de modélisation définit :
La sémantique des concepts ;
Une notation pour la représentation de concepts ;
 Des règles de construction et d'utilisation des concepts.
11
4. Modélisation par décomposition fonctionnelle

Décomposer la fonction globale jusqu'à obtenir des
fonctions simples à appréhender et donc à programmer
12
5. Méthodologie de développement d’application
• Processus de développement:
Ensemble d'étapes partiellement ordonnées, qui concourent à
l'obtention d'un système logiciel ou à l'évolution d'un système
existant.
• Objectif : produire des logiciels
De qualité qui répondent aux besoins des utilisateurs
Dans des temps et des coûts prévisible
• A chaque étape, on produit :
modèles ;
 Des
De la documentation ;
Du code.
13

• Méthode de développement
Tout processus de développement s’appuie sur une
méthode.
Méthode = Démarche + Langage
14
• Méthode de développement
La méthode MERISE fournit :
Un langage de modélisation graphique (MCD, MPD, MOT, MCT...) ET
Une démarche à adopter pour développent un logiciel.
UML n'est qu'un langage :
Il spécifie comment décrire des cas d'utilisation, des classes, des
Interactions mais n’indique pas de la démarche à employer.
Méthodes s'appuyant sur UML :
RUP (Rational Unified Process) - par les auteurs d'UML ;
XP (eXtreme Programming) - pouvant s'appuyer sur UML.
15

• Modèles de cycles de vie linéaire.
Les phases du développement
se suivent dans l'ordre et sans retour
en arrière.
16
• Problèmes des cycles linéaires.
Risques élevés et non contrôlés :
 Identification tardive des problèmes ;
 Preuve tardive de bon fonctionnement ;
Améliorations : construction itérative du système :
 Chaque itération produit un nouvel incrément ;
 Chaque nouvel incrément a pour objectif la maîtrise d'une partie des
 risques et apporte une preuve tangible de faisabilité ou d'adéquation :
• Enrichissement d'une série de prototypes ;
• Les versions livrées correspondent à des étapes de la chaîne des
• prototypes.
17

• Production itérative d'incréments Itérations
A chaque itération, on refait :

1 Spécification ;
2 Conception ;
3 Implémentation ;
4 Tests.
18

• Elimination des risques à chaque itération
• C'est pendant Planification et exécution qu'on

répète
Spécification  Conception  Implémentation Tests.
19

• Rational Unied Process RUP
RUP est une démarche de développement qui est souvent
utilisé conjointement au langage UML.
• Rational Unifed Process est:
 Piloté par les cas d'utilisation ;
 Centré sur l'architecture ;
 Itératif et incrémental.
20

• Rational Unied Process RUP
• Organisation en phases du développement
Initialisation :
 Définition du problème.
Elaboration :
 Planification des activités, affectation des ressources, analyse.
Construction :
 Développement du logiciel par incréments successifs.
Transition :
 Recettage et déploiement.
21
II. Modélisation orientée objet
La Conception des architectures logicielles fondées sur les objets

du système, plutôt que sur une décomposition fonctionnelle.
22
Environnement de travail:
- JDK 8
- Eclipse/NetBeans
- Git
- PowerAMC
23
• Quelques notions de base en Java

Type de donnée:
Type de base Type Nombre de bits
boolean booléen 32 (effectifs)
byte entier 8
short entier 16
int entier 32
long entier 64
float virgule flottante 32
double virgule flottante 64
char caractère 16
24

Structure d’un programme basic en Java
25

Notion de package
Les packages permettent de ranger des classes Java dans une
structure hiérarchique que l’on peut définir soi-même. Un
package en réalité est un répertoire dans lequel sont rangées les
classes.
26

Lecture : Scanner sc = new Scanner(System.in);
Ecriture : System.out.println(" Exemple d’écriture" );
27
1. Diagramme de cas d’utilisation

• Modéliser les besoins permet de :
• Faire l'inventaire des fonctionnalités attendues ;
• Organiser les besoins entre eux, de manière à faire apparaître des relations.
Avec UML, on modélise les besoins au moyen de diagrammes de
cas d'utilisation.
• Le diagramme de cas d’utilisation savoir précisément à QUOI le
système à développer devra servir, c’est-à-dire à quels besoins il
devra répondre.
28

• Un cas d'utilisation est l'expression d'un service réalisé de bout
en bout,
avec un déclenchement, un déroulement et une n, pour l'acteur
qui l'initie.
Un acteur est une entité extérieur au système et qui interagit

avec celui-ci
29
Exemple de diagramme de classe.
30

Description textuelle du cas d’utilisation
• Le diagramme de cas d'utilisation décrit les grandes fonctions
d'un système du point de vue des acteurs, mais n'expose pas
de façon détaillée le dialogue entre les acteurs et les cas
d'utilisation.
31

• Description textuelle du cas d’utilisation
• Identification :
• Nom du cas : Créer cours
• Objectif : Détailler les étapes permettant à une enseignant de créer
un cours
• Acteurs : Enseignant
• Date : 08/03/2021
• Responsables: Afate
• Version: 1.0
32
2. Diagramme de classes
• Les diagrammes de
classes permettent de
spécifier la structure
et les liens entre les objets
dont le système est
composé.
Exemple
33
Une classe est la description d'un ensemble d'objets ayant une
sémantique, des attributs, des méthodes et des relations en
commun.
Elle spécifie l'ensemble des caractéristiques qui composent des
objets
de même type.
Une classe est composée d'un nom, d'attributs et d'opérations.
34
Les attributs et les opérations sont les propriétés d'une classe. Leur
nom commence par une minuscule.
Un attribut décrit une donnée de la classe.
Les types des attributs et leurs initialisations ainsi que les modificateurs
d'accès peuvent être précisés dans le modèle
Les attributs prennent des valeurs lorsque la classe est instanciée : ils
sont en quelque sorte des « variables » attachées aux objets.
Une opération est un service offert par la classe (un traitement que les
objets correspondant peuvent effectuer).
35
Exemple de classe en Java
36
• Concepts et instances
Une instance est la concrétisation d'un concept abstrait
Concept: Personne
Instance: AYELIM, AFATE
Un objet est une instance d'une classe
Classe: Personne
Objet : AYELIM, AFATE
37
• Relations entre classes
 Une relation d'héritage est une relation de
généralisation/spécialisation permettant l'abstraction.
 Une dépendance est une relation unidirectionnelle exprimant une
dépendance sémantique entre les éléments du modèle (èche ouverte
pointillée).
 Une association représente une relation sémantique entre les objets
d'une classe.
 Une relation d'agrégation décrit une relation de contenance ou de
composition.
38
• Une association est une relation structurelle entre objets.
Une association est souvent utilisée pour représenter les liens
possibles entre objets de classes données.
Elle est représentée par un trait entre classes.
39
La multiplicité permet le contrôle du nombre d'objets
intervenant dans chaque instance d'une association.
Exemple: Un cours est créé par un et un seul enseignant (1..1);
un enseignant crée un ou plusieurs cours sans limite (1..*)
40
• Navigabilité d'une association
La navigabilité permet de spécifier dans quel(s) sens il est possible de
traverser l'association à l'exécution.
On restreint la navigabilité d'une association à un seul sens à l'aide
d'une flèche.
Connaissant un
enseignant on connaît
ses cours
41
• Association unidirectionnelle de 1 vers 1
42
• Association bidirectionnelle de 1 vers 1
43
• Association unidirectionnelle de 1 vers *
44
• Association bidirectionnelle de * vers *
Plus difficile à gérer.
Todo: ajouter un exemple d’implémentation
45
• Associations réflexives
• Parfois, les deux extrémités de l'association pointent vers le
même classeur. Dans ce cas, l'association est dite réflexive .
46
• Classe-association
Une association peut être raffinée et avoir ses propres attributs,
qui ne sont disponibles dans aucune des classes qu'elle lie.
Comme, dans le modèle objet, seules les classes peuvent avoir
des attributs, cette association devient alors une classe appelée
« classe-association » .
47
• Associations n-aires
Une association n-aire lie plus de deux classes.
Notation avec un losange central pouvant éventuellement accueillir une
classe-association.
La multiplicité de chaque classe s'applique à une instance du losange.
Les associations n-aires sont peu fréquentes et concernent surtout les cas
où les multiplicités sont toutes « * ». Dans la plupart des cas, on utilisera
plus avantageusement des classes-association ou plusieurs relations
binaires.
48
• Association de type agrégation
Une agrégation est une forme particulière d'association. Elle
représente la relation d'inclusion d'un élément dans un
ensemble.
On représente l'agrégation par l'ajout d'un losange vide du côté
de l'agrégat.
49
• Association de type composition
La relation de composition décrit une contenance structurelle entre
instances. On utilise un losange plein.
La destruction et la copie de l'objet composite (l'ensemble)
impliquent
respectivement la destruction ou la copie de ses composants (les
parties).
Une instance de la partie n'appartient jamais à plus d'une instance de
l'élément composite.
50
• Relation d'héritage
Une relation d'héritage est une relation
de généralisation/spécialisation permettant
l'abstraction.
Exemple en UML:
51
• Relation d'héritage
52
• Encapsulation
L'encapsulation est un principe de conception consistant à
protéger
le cœur d'un système des accès intempestifs venant de
l'extérieur.
• La visibilité publique - public
• La visibilité protégée - protected
• La visibilité « package private »
• La visibilité privée - private
53
• Relation d'héritage et propriétés
La classe enfant possède toutes les propriétés
de ses classes parents (attributs et opérations)
La classe enfant est la classe spécialisée (ici
Etudiant et Enseignant)
La classe parent est la classe générale (ici
Personne)
La classe enfant toutefois n'a pas accès aux
propriétés privées.
54
Une classe enfant peut redéfinir (même signature) une ou plusieurs méthodes de la classe parent.
 un objet utilise les opérations les plus spécialisées dans la hiérarchie des classes.
 La surcharge d'opérations (même nom, mais signatures des opérations différentes) est possible
dans toutes les classes.
Toutes les associations de la classe parent s'appliquent, par défaut, aux classes dérivées (classes
enfant).
Principe de substitution : une instance d'une classe peut être utilisée partout où une instance de sa
classe parent est attendue. Par exemple, toute opération acceptant un objet d'une classe Personne
doit accepter tout objet de la classe Etudiant ou Enseignant (l'inverse n'est pas toujours vrai).
55
• Interface
Le rôle d'une interface est de regrouper un ensemble d'opérations
assurant un service cohérent offert par un classeur et une classe en
particulier.
Une interface est définie comme une classe, avec les mêmes
compartiments. On ajoute le stéréotype « interface » avant le nom de
l'interface.
On utilise une relation de type réalisation entre une interface et une
classe qui l'implémente.
56
• Attributs de classe
Par défaut, les valeurs des attributs définis dans une classe
diffèrent d'un objet à un autre. Parfois, il est nécessaire de
définir un attribut de classe qui garde une valeur unique et
partagée par toutes les instances.
Graphiquement, un attribut de classe est souligné
57
2. Diagramme d’objets
Objectif
• Le diagramme d'objets représente les objets d'un système à un
instant donné. Il permet de :
• Illustrer le modèle de classes (en montrant un exemple qui explique
le modèle) ;
• Préciser certains aspects du système (en mettant en évidence des
détails imperceptibles dans le diagramme de classes) ;
• Exprimer une exception (en modélisant des cas particuliers, des
connaissances non généralisables. . . ).
58
2. Diagramme d’objets
Exemple
59
Partie 2: Bonnes pratiques du génie logiciel
I. Design Patterns
60

CoursPOO UML

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CoursPOO UML

Transféré par

Droits d'auteur :

Formats disponibles

UE : INF1327

Conception, programmation objet avancé et méthodologie de la

• Produire une conception détaillée en appliquant des

• Approfondissement de la modélisation objet pour

• Analyse d’une solution informatique

• Bases de la programmation orientée objet

Partie1: Rappel modélisation UML

• I. Rappel sur quelques notions

1. Notion sur la qualité d’un logiciel

4. Modélisation par décomposition fonctionnelle

5. Méthodologie de développement d’application

5. Méthodologie de développement d’application

5. Méthodologie de développement d’application

A chaque itération, on refait :

5. Méthodologie de développement d’application

• C'est pendant Planification et exécution qu'on

5. Méthodologie de développement d’application

5. Méthodologie de développement d’application

La Conception des architectures logicielles fondées sur les objets

• Quelques notions de base en Java

• Quelques notions de base en Java

• Quelques notions de base en Java

• Quelques notions de base en Java

1. Diagramme de cas d’utilisation

1. Diagramme de cas d’utilisation

Un acteur est une entité extérieur au système et qui interagit

1. Diagramme de cas d’utilisation

Exemple de diagramme de classe.

1. Diagramme de cas d’utilisation

1. Diagramme de cas d’utilisation

Vous aimerez peut-être aussi