UML – PRATIQUE DE LA MODÉLISATION

Big data
Baïdy THIONGANE
Présentation de l’enseignant
Baïdy THIONGANE
 Ingénieur Informaticien Diplômé de l’Ecole Polytechnique Fédérale de Lausanne
 Enseignant – Chercheur UVS
 Oracle Certified Master Java EE Enterprise Architect
 Oracle Certified Professional Java SE Programmer

2
Pré-requis et Objectifs généraux
Pré-requis
o Avoir de bonnes connaissances des Systèmes d’information.

Objectifs généraux
o Comprendre l’approche Orientée Objet
o Comprendre le langage de modélisation graphique UML afin de pouvoir utiliser les diagrammes
pertinents lors de l’Analyse et de la Conception Orientée Objet.
o Maîtriser la notation UML.

3
Références
• Object-Oriented Analysis And Design – Second Edition
o Auteur: Booch, Grady
o Editeur: Addison-Wesley, Santa Clara, California
o Publication: 1994

• UML 2 par la pratique : Etudes de cas et exercices corrigés – Edition 8

o Auteur: Roques, Pascal
o Editeur: Eyrolles
o Publication: 2018
o Disponible: ScholarVox
• https://www.uml-diagrams.org/

4
UML – PRATIQUE DE LA MODÉLISATION

INTRODUCTION
La crise du logiciel

«Alors que le matériel informatique a fait, et continue de

faire, des progrès très rapides, le logiciel, l'autre ingrédient
de l'informatique, traverse une véritable crise. Etant donné
que cette crise a été décelée en 1969 déjà et qu'elle dure
toujours, il serait plus approprié de parler d'une maladie
chronique.»

6
Le non-respect des coûts et des délais

Le coût de développement d'un logiciel est presque impossible

à prévoir et le délai de livraison n'est que rarement respecté.
On cite ainsi des dépassements moyens du coût budgété et
du délai prévu respectivement de 70% et 50%.

7
Une qualité déficiente

La qualité du logiciel livré est souvent déficiente. Le produit ne

satisfait pas les besoins de l'utilisateur, il consomme plus de
ressources que prévu et il est à l'origine de pannes.

8
Une maintenance difficile
La maintenance du logiciel est difficile, coûteuse et souvent à
l'origine de nouvelles erreurs. Mais en pratique, il est
indispensable d'adapter les logiciels car leurs environnements
d'utilisation changent et les besoins des utilisateurs évoluent.

9
Une réutilisation quasi-impossible

Il est rare qu'on puisse réutiliser un logiciel existant ou un de

ses composants pour confectionner un nouveau système,
même si celui-ci comporte des fonctions similaires. Tout
amortissement sur plusieurs projets est ainsi rendu
impossible.

10
 Coût d’un système informatique
1965 1975 2000
Matériel
10%
Matériel
30%

logiciel Matériel
50% 50%

logiciel
70%
logiciel
90%

11
Augmentation des Coût d’un SI
Cette augmentation des coûts d’un Système Informatique (SI) est
surtout due aux frais de maintenance, situés actuellement entre
40% et 75% du coût total d'un système informatique (matériel et
logiciel). Or ces frais de maintenance résultent avant tout de la
qualité déficiente du logiciel, au moment de sa livraison déjà ou
après qu'il ait évolué.

Augmentation 12
La raison de fond
Le fait étant qu'il est beaucoup plus difficile de créer des logiciels que
le suggère notre intuition. Comme les solutions informatiques sont
essentiellement constituées de composants immatériels, tels des
programmes, des données à traiter, des procédures et de la
documentation, on sous-estime facilement leur complexité.

13
 Analyse – Etat de l’art

«L’analyse consiste à
valider que le système
qu’on va concevoir
répond à un besoin
bien identifié. Sachant
qu’un besoin peut être
exprimé ou implicite,
avoué ou inavoué,
latent ou potentiel…»

14
La complexité
2025 2000 1 000 000

2015

2005
1990 100 000
1995
1980 50 000
1985

1975 1970 10 000

1965
1 2 3 4 5
Ligne de codes (SLOC en anglais, Source Lines Of Code)

Evolution du nombre de ligne de code en moyenne dans les logiciels

15
La réalité
Logiciel Lignes de codes

Word, Excel, Navigateur 5.000.000

Windows 7 ou Windows XP 40.000.000

Facebook 50.000.000

Voiture 100.000.000

Services Google 2.000.000.000

Génome humaine 3.300.000.000

16
La solution
Pour maîtriser la complexité des systèmes logiciels, il convient de
procéder selon une démarche bien définie, de se baser sur des
principes et méthodes, et d'utiliser des outils performants. On
arrive ainsi à gérer des projets complexes et à élaborer
scientifiquement des solutions.

17
Affirmation erronée n°1
par rapport aux estimations d’origine Les exigences peuvent être assez précises
dès le début du projet!
Hausse des exigences en %

Taille des projets en points de fonction

18
Source: Applied Software Measurement, Capers Jones, 1997.
Affirmation erronée n°2
Les exigences sont stables!
• Le marché bouge en permanence
• La technologie évolue
• Les besoins des clients et utilisateurs changent
• Les objectifs des intervenants changent

19
Affirmation erronée n°3
La conception peut être terminée…avant que ne débute la
programmation
• Demandez à un programmeur…
• Encore trop de variables, d’inconnues et de nouveautés
• Une spécification complète doit être aussi détaillée que le code lui-
même
• Il est beaucoup plus difficile de créer des logiciels que le suggère
notre intuition.

20
Le «CHAOS»

Imprédictible
Incertaine
Instable

Photo: Vitor Sá, 2013

Le rapport «CHAOS» - Constats
• 29% des projets informatiques sont réussis. Les projet ont été terminé dans les
temps et ils ont respecté le budget avec un résultat satisfaisant.

• 52% des projets sont terminés et opérationnels, mais ont dépassé le budget
et le délai initial, et sont livrés avec moins de services et de
fonctionnalités qu’initialement prévu.

• 19% des projets sont annulés en cours de route.

71%
Source: Standish Group, 2015
Facteurs d’échecs - Projets terminés en dépassement

Manque d’implication de l’utilisateur 12.8%

Exigences et spécifications incomplètes 12.3%
Changements aux exigences et spécifications 11.8%
Manque de soutien de la direction 7.5%
Incompétence technologique 7.0%
Manque de ressources 6.4%
Attente irréalistes 5.9%
Objectifs mal définis 5.3%
Calendrier irréaliste 4.3%
Nouvelle technologie 3.7%
Autres 23%
23
Facteurs d’échecs - Projets abandonnés
Exigences et spécifications incomplètes 13.1%
Manque d’implication de l’utilisateur 12.4%
Manque de ressources 10.6%
Attente irréalistes 9.9%
Manque de soutien de la direction 9.3%
Changements aux exigences et spécifications 8.7%
Manque de planification 8.1%
Besoin périmé 7.5%
Manque de management IT 6.2%
Incompétence technologique 4.3%
Autres 9.9%

24
Facteurs de succès – Projets réussis
implication des utilisateurs 15.9%
Soutien de la direction 13.9%
Exigences et spécifications claires 13.0%
Planification adaptée 9.6%
Attente réalistes 8.2%
Phases courtes et jalons resserrés 7.7%
Equipe compétente 7.2%
Propriété 5.3%
Vision et objectifs clairs 2.9%
Travail intense 2.4%
Autres 13.9%
25
En conséquence…

26
Communication
27
UML
Adopté et standardisé par l’Object
Management Group (OMG) depuis
1997, UML est aujourd’hui un outil
de communication incontournable,
utilisé sur des centaines de projets
de par le monde ;

28
Plan du cours

1. Introduction
2. L’approche Orientée Objet
3. Le langage de modélisation graphique UML
4. Analyse Orientée Objet
5. Conception Orientée Objet

29
UML – PRATIQUE DE LA MODÉLISATION

Approche Orientée Objet

Introduction Orienté Objet UML Fonctionnelle Statique Dynamique

Processus de développement logiciel
• Ceci n’est pas un cours sur un processus de développement logiciel! Toutefois, il
est difficile d’explorer les notions de modélisation UML sans évoquer la façon dont les
différentes étapes du développement logiciel s’articulent avec celles de la modélisation.
• Un processus de développement logiciel sont les étapes de l’organisation et de la
gestion du développement logiciel.
• Un processus de développement logiciel est constitué par un ensemble de cycles de
développement.
• Le cycle de développement d’un logiciel est la série de phases que celui-ci traverse,
depuis l’expression de besoin et exigences jusqu’à sa disparition en passant par
l’exploitation et support.

31
Cycle de développement d’un logiciel comprend…
Le cycle de développement d’un logiciel type comprend généralement les phases suivantes:

• Expression de besoin et exigences, c'est-à-dire l'expression, le recueil et la formalisation des besoins du demandeur (le client) et de
l'ensemble des contraintes.
• Analyse, c’est l’investigation du problème et la specification de la solution fonctionnelle
• Conception, c’est l’elaboration de la solution logique
• Implémentation, (codage ou programmation), soit la traduction dans un langage de programmation des fonctionnalités définies lors de
phases de conception.
• Tests unitaires, permettant de vérifier individuellement que chaque sous-ensemble du logiciel est implémentée conformément aux
spécifications.
• Intégration, dont l'objectif est de s'assurer de l'interfaçage des différents éléments (modules) du logiciel. Elle fait l'objet de tests
d'intégration consignés dans un document.
• Qualification (ou recette), c'est-à-dire la vérification de la conformité du logiciel aux spécifications initiales.
• Documentation, visant à produire les informations nécessaires pour l'utilisation du logiciel et pour des développements ultérieurs.
• Mise en production, c’est le déploiement de l’application et son utilisation.
• Maintenance, comprenant toutes les actions correctives (maintenance corrective) et évolutives (maintenance évolutive) sur le logiciel.
32
Cycle de développement
Ainsi il est possible de schématiser le cycle de développement d’un
logiciel type selon la structure de cycle de développement suivante:
Cycle de développement d’un logiciel type

Besoins Analyse Conception Implémentation Tests Déploiement*

Livrable
Phase
*Déploiement = Intégration, Qualification, Documentation, Mise en production, Maintenance
33
Modèle de cycle de développement
• Afin d'être en mesure d'avoir une méthodologie commune entre le client et la société de
service réalisant le développement, des modèles de cycles de vie ont été mis au point
définissant les étapes du développement ainsi que les documents à produire (livrables)
permettant de valider chacune des étapes avant de passer à la suivante. A la fin de
chaque phase, des revues sont organisées.

• Les phases peuvent être

o séquentielles (cycle en cascade ou cycle en V)
o itératives (cycle itératif, cycle en spirale, ou méthodes agiles)
o Parallèles (Méthodes UP (Unified Process))

34
Cycle en Cascade
Le cycle dure de 3 mois à 2 ans. Les phases sont successives, à l'issue de chaque phase des
documents sont produits (livrables) pour en vérifier la conformité avant de passer à la phase
suivante.

35
Cycle en V
C’est une amélioration du modèle en cascade qui permet en cas d'anomalie, de limiter un retour
aux étapes précédentes. Les phases de la partie montante doivent renvoyer de l'information sur les
phases en vis-à-vis lorsque des défauts sont détectés afin d'améliorer le logiciel.

36
Cycle en Spirale
Le cycle en Spirale reprend les différentes étapes du cycle en V. Par l'implémentation de versions
successives, le cycle recommence en proposant un produit de plus en plus complet et robuste.

37
Cycle Processus Unifié
Le processus unifié (PU), ou « unified process (UP) » en anglais, ou « Unified Software Development Process (USDP) » est une
famille de méthodes de développement de logiciels orientés objets. Elle se caractérise par une démarche itérative et
incrémentale, pilotée par les cas d'utilisation, et centrée sur l'architecture et les modèles UML. Elle définit un processus intégrant
toutes les activités de conception et de réalisation au sein de cycles de développement composés d'une phases de création,
d'une phase d'élaboration, d'une phase de construction et d'une phase de transition, comprenant chacune plusieurs itérations

38
Cycle Agile
Le cycle agile est basé sur une réponse itérative axée sur l’amélioration continue, le prototypage ainsi qu’un
périmétre adaptatif. Les livrables sont élaborés progressivement dans des itérations (appelées quelquefois des
«sprints»). Le logiciel est décomposé en besoins en attente («backlog») issus des cas d’utilisations («user
stories»). En début d’itération, l’équipe déterminera les besoins à satisfaire dans l’itération («sprint backlog»)

Exemple - Scrum 39
L’Orientée Objet - OO
L’Orientée Objet cherche ainsi donc à établir et à utiliser des
principes sains d'ingénierie dans le but de développer
économiquement du logiciel qui est fiable et qui fonctionne
efficacement sur des machines réelles.

40
Les objectifs de l’Orientée Objet
• Faciliter le développement, la maintenance et l’évolution
des applications ;
• Permettre la modularité du code ;
• Permettre la réutilisation du code;
• Augmenter la qualité des logiciels;
• Diminuer le coût de développement d’un logiciel;
• Respecter les délais de livraison.

41
Fondements de l’Orientée Objet
«L’ingénieur comme l’artiste doit avoir une
connaissance approfondie des matériaux de sa
discipline. Quand on utilise des méthodes
orientées objets pour analyser ou concevoir un
système logiciel complexe, les éléments de
construction fondamentaux sont les classes et
les objets.»
Grady BOOCH
Co-créateur d’UML

42
L’approche orientée objet
Système d’information
d’une bibliothèque

Décomposition par objet Décomposition par fonction

Catalogue Prêt Système

Enregistrer Ajouter un Gérer les

Bibliothèque Livre
un prêt document pénalités
Approche Orientée Objet Approche procédurale
43
 Orientation Objet et Orientation Procédurale
PROCÉDURALE OBJET
Que doit faire mon programme ? De quoi doit être composé mon programme ?
Le programme informatique est divisé en petites parties appelées Le programme informatique est divisé en petites parties appelées
fonctions objets
Conception du haut vers le bas Conception des interactions entre les objets
Réutilisation limitée du code Réutilisation du code
Code complexe Conception complexe
Centrée sur le partage des données Centrée sur la protection des données
Fondée sur la notion de traitement Fondée sur la notion de service
Langages: C, VB, Pascal, Fortan Langages: C++, Java, VB.NET, C#.NET
Moins lisible à la longue Devient plus lisible
Pas besoin d'aborder le polymorphisme, l’héritage, etc Nouvelles notions et utilisation du procédural
Le code sera moins bien compris par d'autres Séparations évidentes

44
L’Analyse et la Conception Orientée Objet…

Phases clés du cycle de développement d’un logiciel

Besoins Analyse Conception Implémentation

Expression Elaboration
des besoins Investigation Réalisation
de la solution
et exigences du problème codage
logique

Espace du problème Espace de la solution

45
L’Analyse et la Conception Orientée Objet

• Analyse orientée-objet
o Investigation du problème en termes d’objets du domaine

• Conception orientée-objet
o Élaboration d’une solution en termes d’objets logiciels inter-opérants

• Programmation orientée-objet
o Codage avec un langage de programmation orienté objet

46
L’Analyse et la Conception Orientée Objet
• Historiquement, la programmation orientée-objet est apparue en
premier (Simula : 1968, Smalltalk : 1970,etc.). Puis les concepts
objets ont remonté les niveaux d’abstraction, d'abord vers la
conception, puis l’analyse au début des années 90.

• Dans le cadre de ce cours nous mettrons un focus sur l’Analyse

Orientée Objet (AOO) et la Conception Orientée Objet (COO) en
partant des besoins du client.

47
Les 7 concepts de base de l’Orienté Objet
1. Objet
2. Abstraction
3. Composition et réutilisation des objets
4. Classe
5. Classification et héritage
6. Encapsulation
7. Polymorphisme

48
An object has state, exhibits some well-defined behavior,
and has a unique identity.

49
1. Objet
• Objet = entité aux frontières bien définies, possédant une
identité, encapsulant un état et un comportement.

• Objet = entité logicielle regroupant un ensemble des données

et de méthodes de traitements

• Objet = unité logique de la programmation orientée objet.

50
1. Objet - Etat
Il est défini à l’aide d’attributs (appelés aussi données membres ou
propriétés). Ce sont des variables associées à l’objet et qui stockent
des valeurs (des informations sur l'état de l'objet).

Attributs : Attributs :
marque = Nissan marque = Airbus
modèle = Qashqai modèle = A380
Couleur = grise Altitude = 8000 m
vitesse = 0 km/h Etat : A l’arrêt Etat : En vol
vitesse = 900 km/h
51
1. Objet - Comportement
• il est caractérisée par des méthodes (appelées parfois fonctions membres ou opérations) qui
permettent de modifier l’état de l’objet.

• Une méthode rattachée à l’objet permet de déclencher un des comportements associés à

l’objet.

• Il n’est pas possible d’agir directement sur les données d’un objet pour modifier son état; il est
nécessaire de passer par ses méthodes. On dit qu'on « envoie un message » (faire une requête)
à un objet.

• Un objet peut recevoir un message qui déclenche

o une méthode qui modifie son état et/ou …..
o une méthode qui envoie un message à un autre objet

52
1. Objet - Comportement
Attributs : Attributs :
marque = Nissan marque = Airbus
modèle = Qashqai modèle = A380
couleur = grise altitude = 8000 m
vitesse = 95 km/h vitesse = 900 km/h
Méthodes: Méthodes:
démarrer Etat : Roule décoller Etat : En vol
accélérer atterrir
freiner virer
éteindre

53
1. Objet - Identité
L'objet possède une identité, qui permet de le distinguer des autres
objets, indépendamment de son état.

Exemple:
Numéro de châssis
Plaque d’immatriculation
Numéro de la Carte Nationale d’Identité

54
1. Objet - Résumé
• Un objet est une variable améliorée: il stocke les données, mais on peut
effectuer des requêtes sur cet objet (on demande à l’objet de faire des
opérations sur lui-même), en envoyant un message à cet objet. Ceci est
équivalent à un appel de fonction.
• Il possède une structure interne et un comportement.
• Méthode =
o Un comportement d’un objet invoqué par un message
o Semblable à une fonction, mais appartenant à un objet
• L’exécution d’un système objet repose sur les objets et les liens entre objets.

55
1. Objet

méthode

• Etat = Attributs
• Comportement = Méthodes
• Identité = Données

56
Abstraction focuses upon the essential characteristics of some
object, relative to the perspective of the viewer.

57
2. Abstraction
Un objet est une abstraction
• Seules les propriétés pertinentes pour le modèle sont représentées
• Un objet peut être une abstraction pour une entité :
o matérielle - un avion, une voiture, une personne
o immatérielle - une commande, un compte
o interface homme-machine - le bouton « OK »
o informatique - une liste chaînée
o réseau – router, adresse IP

58
Modularity packages abstractions into discrete units.

59
3. Composition et réutilisation des objets
Composer ou créer un objet à partir d’autres objets est le cœur de la
programmation orientée objet. Cela permet:
• La construction d’objets plus complexes en partant de blocs de
constructions plus simples
o Par exemple: Un programme de dessin; il se composera d’objets tels que
des fenêtres, des menus, un cadre de dessin, une palette d’outils, une
palette de couleur, etc…L’application de dessin est construite en
ressemblant et en créant ses classes de composants et en les regroupant
en un ensemble intégré

60
3. Composition et réutilisation des objets
• La simplification de l’organisation des programmes
o Par exemple on peut utiliser la bibliothèque de base de java (Java JDK)
pour assembler rapidement et simplement les pièces d’un programme.
• La réutilisation des logiciels développés
o Par exemple: on peut utiliser les classes de l’application de dessin pour une
application de publication.
• L’agrégation spécifie une relation « tout - partie »
• La composition est une agrégation forte
o Une partie n’appartient qu’à un seul composite à un moment donné
o Si l’agrégat composite est détruit, alors toutes ses parties le sont aussi

61
A class represents a set of objects that share a common
structure and a common behavior.

62
4. Classe
• Une classe est un descripteur d'objets
o Un objet est une instance de classe
• Une classe (ou type d’objets) représente une famille d’objets qui partagent des
propriétés communes:
o Les objets qui ont les mêmes états et les mêmes comportements.
• Une classe regroupe les objets qui ont :
o La même structure (même ensemble d’attributs)
o Le même comportement (même méthodes)
• Les classes servent pour la création des objets
o Un objet est une instance d’une classe

63
4. Classe
• Un programme OO est constitué de classes qui permettent de
créer des objets qui s’envoient des messages.

• L’ensemble des interactions entre les objets défini un algorithme.

• Les relations entre les classes reflètent la décomposition du
programme.

64
4. Classe
• Champs (appelés aussi attributs ou données membres ou propriétés).
L’ensemble des champs définissent l’état d’un objet (chaque objet a ses
données propres).
• Méthodes (appelés aussi fonctions membres ou comportement). Les
méthodes définissent un ensemble d’opérations applicables à l’objet (On
manipule les objets par des appels de ses méthodes).
• L’ensemble des méthodes est appelé l’interface de l’objet.
o Une interface définit toutes les opérations qu’on peut appliquer à l’objet
(définit tous ce qu’il est possible de "faire" avec un objet).

65
Classification is the means whereby we order knowledge.

66
4. Arbre de classification
Véhicule

Spatial Aéronautique Terrestre Aquatique

Motricité humaine Automotrice

2 roues 4 roues

Voiture Camion

Nissan

Peugeot 67
4. Définition d’une classe
Une classe bien structurée:
• fournit une abstraction claire de quelque chose tiré du vocabulaire
du domaine du problème ou de celui de la solution;
• comprend un petit ensemble de responsabilités bien définies et les
réalise parfaitement;
• fournit une séparation nette entre les spécifications de l’abstraction
et son implémentation;
• est compréhensible et simple tout en étant extensible et adaptable.

68
5. Classification et héritage
• La réutilisation des objets ne se limite pas à leur composition. Elle exploite aussi une capacité
puissante de la programmation orientée objet connue sous le nom d’héritage. L’héritage permet
non seulement aux objets d’être utilisés en tant que tels, mais il autorise aussi la création de
nouveaux objets obtenus par extension et façonnage d’objets existants.
• La classification est une méthode générale d’organisation du savoir et elle est utilisé ailleurs
que dans la programmation orientée objet.
• L’héritage est le mécanisme de transmission des caractéristiques d’une sur-classe vers ses
sous-classes.
• Quand une classe en étend une autre, elle hérite de ses données et de ses méthodes. On parle
d’héritage simple. Si elle étend plusieurs classes on parle d’héritage multiple.
• Une classe hérite des attributs, des méthodes et des associations de toutes ses sur-classes.
• L’héritage évite la duplication, facilite la réutilisation et l’évolutivité
69
5. Classification et héritage
• Classification = généralisation + spécialisation
o Généralisation : regroupement des caractéristiques communes à un ensemble de
classes au sein d’une surclasse plus générale.

o Spécialisation : ajout de caractéristiques spécifiques dans une sous-classe, ou

adaptation des caractéristiques transmises.

o Une instance d’une sous-classe est également instance de toutes ses sur-classes.

o La classification correspond à un “OU” logique.

70
Encapsulation hides the details of the implementation
of an object.

71
6. Encapsulation
• L’encapsulation est le faite qu’un objet renferme ses propres attributs et ses méthodes.
Les détails de l’implémentation d’un objet sont masqués aux autres objets du système
à objets. On dit qu’il y a encapsulation de données et du comportement des objets.
• On précise trois modes d’accès aux attributs d’un objet.
o Le mode public avec lequel les attributs seront accessibles directement par l’objet lui-
même ou par d’autres objets. Il s’agit du niveau le plus bas de protection.
o Le mode private avec lequel les attributs de l’objet seront inaccessibles à partir d’autres
objets : seules les méthodes de l’objet pourront y accéder. Il s’agit du niveau le plus fort
de protection.
o Le mode protected : cette technique de protection est étroitement associée à la notion
d’héritage. Elle se comporte comme private avec moins de restriction. Une classe
dérivée à un accès aux membres protected mais pas aux membres private.

72
With polymorphism, large case statements are unnecessary,
because each object implicitly knows its own type.

73
7. Polymorphisme
• Le terme polymorphisme issu du grec signifie la faculté de prendre
plusieurs formes.
• Une entité est polymorphe si à l’exécution elle peut se référer à des
instances de classe différentes.
• Le Polymorphisme veut dire que le même service peut avoir un
comportement différent suivant la classe dans laquelle il est utilisé. C’est
un concept fondamental de la programmation objet, indispensable pour
une utilisation efficace de l’héritage.

74
7. Polymorphisme
• Le polymorphisme permet d’éviter les codes qui comportent de
nombreux embranchements et tests. En d’autres termes, le
polymorphisme est un mécanisme qui permet à une sous classe de
redéfinir une méthode dont elle a hérité tout en gardant la même
signature de la méthode.
Rectangle Carre Cercle

calculerSurface calculerSurface calculerSurface

75
The task of the software development team is to
engineer the illusion of simplicity.

76
L’excellence

«L'excellence est un art que l'on

n'atteint que par l'exercice
constant. Nous sommes ce que
nous faisons de manière
répétée. L'excellence n'est donc
pas une action mais une
habitude.»
Aristote
384-322 avant J.C

77
UML – PRATIQUE DE LA MODÉLISATION

UML

Introduction Orienté Objet UML Fonctionnelle Statique Dynamique