SlideShare une entreprise Scribd logo
Cours C++ (2002)
semaine 1
jour 1
Cours semaine 1, jour 1 Cours C++ (2002) 2
Plan du jour
 Présentation des langages orientés objets
 Messages et concepts objets
 Analyse et conception de systèmes, de
programmes
 eXtreme Programming, et après
Cours semaine 1, jour 1 Cours C++ (2002) 3
Langages orientés objets
 Langages orientés objets ou langages à
objets sont une évolution significative par
rapport aux langages procéduraux
 Ex : Pascal, COBOL, C
 Un peu moins de mathématiques, un peu plus
naturel
 Du point de vue du programmeur : abandon du
simple enchaînement des appels de procédures
et de fonctions
Cours semaine 1, jour 1 Cours C++ (2002) 4
Langages orientés objets (2)
 Du point de vue de l’analyse, l’homme a plutôt
tendance à utiliser des classifications (taxonomies)
 Elles permettent de diviser le monde en groupes et
sous-groupes : le monde devient plus facile à
appréhender et à modéliser
 Les classifications peuvent être variées et fondées sur
des analyses statistiques, par composantes principales,
ou, de façon moins formelle, par distinction de
caractéristiques littéraires communément admises
Cours semaine 1, jour 1 Cours C++ (2002) 5
Messages
 Un programme à base d’objets comporte
des entités clairement identifiées,
responsables de certains traitements sur des
types de données clairement identifiées
 Un programme est composé d’instances de
classes, les instances pouvant communiquer
les unes avec les autres
 Pas d’appel de fonctions : juste des invocations
Cours semaine 1, jour 1 Cours C++ (2002) 6
Messages (2)
 L’exécution d’une tâche correspond à
l’envoi d’un message à l’instance
responsable du traitement et à la réception
d’un message de réponse
 Après tout, on a la même chose avec un
empilement et un dépilement lors d’un appel de
fonction !?
 L’idée n’est pas la même 
Cours semaine 1, jour 1 Cours C++ (2002) 7
Messages (3)
 Naissance officielle des langages à objets
 Simula 67, langage de programmation dédié à
la simulation
 Introduction de la notion d’objets
 Simula 67 était une amélioration d’Algol
 Première présentation en 1962
 Simula est principalement fait pour supporter
l’exécution d’univers basés sur des interactions
faites par l’intermédiaire d’évènements discrets
Cours semaine 1, jour 1 Cours C++ (2002) 8
Messages (4)
 Événements discrets :
 Quelque chose arrive
 Quelqu’un s’en rend compte
 Il informe une ou plusieurs autres entités qui
réagissent en fonction de leurs états internes en:
 Fournissant l’information demandée
 Créant d’autres évènements
 C’est la base des langages de simulation et
l’idée initiale conduisant à leur définition
Cours semaine 1, jour 1 Cours C++ (2002) 9
Messages (5)
 Les langages de simulation ont introduits la
notion d’entité indépendante ayant un
traitement autonome
 Cette idée a été reprise pour la (fausse)
création des langages à objets
 Les objets, entre eux, ne s’échangent que des
messages
 Un message peut être local ou distant (le
principe est le même, pas l’implémentation)
Cours semaine 1, jour 1 Cours C++ (2002) 10
Principes de base en objet
 Les objets communiquent entre eux par
messages
 L’appelant (client) formate un message et
l’envoi au destinataire (serveur)
 Le destinataire vérifie qu’il sait traiter le
message reçu et le traite s’il peut
 Les objets ne sont pas monolithiques, ils
s’agglomèrent les uns les autres pour en
constituer des plus importants
Cours semaine 1, jour 1 Cours C++ (2002) 11
Principes de base en objet (2)
 Les principes de base en objets peuvent être
résumés suivant la règle « Apple PIE »
 Abstraction
 Polymorphisme
 Héritage (Inheritance)
 Encapsulation
 Nous reviendrons en détail sur ces principes
tout au long du cours
Cours semaine 1, jour 1 Cours C++ (2002) 12
Abstraction
 L’abstraction est une généralisation
 L’abstraction permet d’ignorer ou de cacher les
détails, permettant d’extraire des points communs
entre différentes entités
 Exemples
 « être humain » est une abstraction de « homme » et de
« femme »
 « animal » est une abstraction de « mammifère », qui
est une abstraction de « cheval », qui lui-même est une
abstraction d’ « ardennais »
Cours semaine 1, jour 1 Cours C++ (2002) 13
Polymorphisme
 Les abstractions sont faites à partir de
caractéristiques partagées
 Exemple : « cheval » et « dauphin » sont des
« mammifères »
 Ces abstractions ne se font pas uniquement
sur les données mais également sur les
traitements
 Exemple : les « mammifères » se déplacent et
se reproduisent
Cours semaine 1, jour 1 Cours C++ (2002) 14
Polymorphisme (2)
 Qu’une fonction soit disponible à un haut niveau
d’abstraction ne signifie pas que son
implémentation soit la même partout
 Un « cheval » ne se déplace pas de la même manière
qu’un « dauphin »
 Il est cependant possible de traiter un groupe
d’objets à un haut niveau en appelant des
fonctions finalement différentes
 DéplacerTousLesMammifères() = pour chaque
mammifère présent dans le système, appeler la fonction
déplacer(), quelque soit le traitement effectif
Cours semaine 1, jour 1 Cours C++ (2002) 15
Héritage
 L’héritage est le mécanisme qui permet de
réaliser l’abstraction
 Exemple : si la taxonomie précise que
« dauphin » est un « mammifère », alors
« dauphin » héritera de toutes les
caractéristiques et de tous les comportements
des « mammifères »
 Du plus spécifique au plus général :
abstraction
 Du plus général au plus spécifique : héritage
Cours semaine 1, jour 1 Cours C++ (2002) 16
Encapsulation
 Les langages orientés objet permettent de définir
des abstractions à partir d’un ensemble d’entités
connues
 Chaque entité élémentaire a des caractéristiques
(données) et des comportements (traitements). Les
classes abstraites en possèdent également.
 Considérer une entité comme le regroupement de
ses données et de ses traitements est une
encapsulation
 Les langages procéduraux ne permettent pas de
réaliser l’encapsulation
Cours semaine 1, jour 1 Cours C++ (2002) 17
Généralisons…
 Pourquoi utiliser des langages orientés objet
plutôt que des langages procéduraux ?
 Les langages procéduraux sont, après tout,
utilisés depuis bien longtemps et sont
parfaitement connus et maîtrisés.
 Oui, mais…
Cours semaine 1, jour 1 Cours C++ (2002) 18
Échecs des projets informatiques
 Échecs des projets informatiques
Types de projet Dépassement
des coûtsType 1 Type 2 Type 3
En moyenne 16,2 % 52,7 % 31,1 %
Gros projets 9 % 61,5 % 29,5 % 178 %
Projets moyens 16,2 % 46,7 % 37,1 % 182 %
Petits projets 28 % 50,4 % 21,6 % 214 %
Type 1 : respectent budget, délais et spécifications
Type 2 : dépassent délais et budget, respectent les spécifications
Type 3 : abandonnés au cours du cycle de vie
Cours semaine 1, jour 1 Cours C++ (2002) 19
Analyse et conception
 La réalisation de systèmes et de programmes
orientés objets diffère du mode de réalisation suivi
par l’analyse fonctionnelle et technique
 Vrai pour l’analyse
 Vrai pour la conception
 Vrai pour l’évolution d’un projet
 Généralement, pour les systèmes procéduraux,
gestion de projet « à la MERISE »
Cours semaine 1, jour 1 Cours C++ (2002) 20
Méthodologies
 Waterfall : le plus largement suivi
définition
analyse
design
développement
tests unitaires
tests intégration
tests système
livraison
maintenance
Cours semaine 1, jour 1 Cours C++ (2002) 21
Méthodologies (2)
 Modèle en V : le waterfall revisité
développement tests unitaires
design tests intégration
analyse tests système
définition livraison maintenance
Cours semaine 1, jour 1 Cours C++ (2002) 22
Méthodologies (3)
 Modèle en spirale : le « waterfall itératif »
 Incrémentations successives, les premières
pouvant être « purement » formelles
 Un des meilleurs modèles :
 Marche tout aussi bien pour de petits projets que
pour les grands
 Permet le prototypage durant toutes les phases : le
logiciel n’est pas fini mais fait « comme si »…
 Besoin important de management et d’analyse du
risque
Cours semaine 1, jour 1 Cours C++ (2002) 23
Méthodologies (4)
planning
analyse de risque
ingénierie
développement et
déploiement
évaluation par
l’utilisateur
discussion avec
l’utilisateur
Modèle en spirale
Cours semaine 1, jour 1 Cours C++ (2002) 24
Méthodologies (5)
 Une méthodologie ne suffit pas !
 Les méthodologies sont exposées dans les
livres,
 Elles sont toujours assez abstraites
 Elles sont assez peu pratique
 Elles sont presque toujours ressenties comme
imposées par ceux qui les utilisent
 Elles ne tiennent généralement pas compte de la
taille du projet (« one size fit all »)
Cours semaine 1, jour 1 Cours C++ (2002) 25
Processus
 Besoin d’un processus de développement
 Ils sont mis en place en fonction de
l’existant de l’organisation
 Ils donnent des orientations claires et
utilisables car ils sont adaptés à la réalité
quotidienne d’une entreprise
 Ils permettent à chacun d’améliorer sa
manière de travailler et d’interagir
Cours semaine 1, jour 1 Cours C++ (2002) 26
Processus (2)
 CMM, Capability Maturity Model, nous
vient du département de la défense
américain (comme toujours !)
 Il identifie différents niveaux de maturité
des processus informatiques dans
l’entreprise
 Il donne un guide (abstrait) à adapter à une
entreprise pour que celle-ci soit capable de
grandir (maturing) presque seule
Cours semaine 1, jour 1 Cours C++ (2002) 27
Processus (3)
 La maturité d’une organisation peut être
analysée à travers cinq niveaux différents :
 Niveau 1 : initial, peu de processus définis, le
succès d’un projet dépend des efforts
individuels, « Je fais comme je veux » (76 %
des organisations informatiques)
 Niveau 2 : répétable, processus de base pour la
gestion de projets, « Je gère et je contrôle ce
que je fais, mais ect-ce que je le fais
correctement » (15 %)
Cours semaine 1, jour 1 Cours C++ (2002) 28
Processus (4)
 Niveaux (suite) :
 Niveau 3 : défini, tous les projets utilisent la même
base d’activités qui sont documentées, organisées et
standardisées, « J’utilise les meilleures pratiques de
mon organisation mais je ne peux pas juger leur
qualité » (7 %)
 Niveau 4 : géré, gestion quantitative des processus, des
métriques sont définies et observées pour les processus
et la qualité, « J’utilise les meilleures pratiques de mon
organisation et je connais leur qualité » (> 1 %)
Cours semaine 1, jour 1 Cours C++ (2002) 29
Processus (5)
 Niveaux (suite) :
 Niveau 5 : optimisé, amélioration constante des
processus grâce à l’analyse des métriques
définies, « J’utilise les meilleures pratiques de
mon organisation, je connais leur qualité et je
les améliore constamment » (< 1 %)
Cours semaine 1, jour 1 Cours C++ (2002) 30
Processus (6)
Contrôle des
processus
Niveau 4
Géré
Mesure des
processus
Niveau 4
Défini
Définition de
processus
Niveau 2
Répétable
Contrôle de gestion
de projet de base
Niveau 1
Initial
Niveau 5
Optimisé
Pas de processus défini
Services répétables, mise en place de processus de base
Standardisation des services et
mise en place de processus de service
Contrôle quantitatif des
processus de services
Contrôle qualitatif des processus de
service, amélioration constante des
processus
Cours semaine 1, jour 1 Cours C++ (2002) 31
Processus (7)
optimisé
géré
défini
répétable
initial
Gestion du changement dans les processus
Gestion des changements/évolutions technologiques
Prévention des erreurs et disfonctionnements
Gestion de la qualité du logiciel
Gestion quantitative des processus
Gestion des problèmes
Coordination inter-groupes
Service Delivery
Gestion de service intégrée
Mise en place d’un programme de formation
Définition des processus de l’organisation
Respect des processus de l’organisation
Définition des services de l’organisation
Gestion de configurations
Gestion des imprévus
Service d’assurance qualité
Gestion de la sous-traitance
Gestion du suivi
Gestion du planning de livraison
Gestion des objectifs et besoins
Cours semaine 1, jour 1 Cours C++ (2002) 32
Processus (8)
 RUP, Rational Unified Process, provient de
chez Rational
 Il est basé sur l’Objectory Process de
Jacobson, modèle assez académique
 Il est intéressant et pleins de bonnes idées
 Mais beaucoup des outils le supportant sont
vendus par … Rational
Cours semaine 1, jour 1 Cours C++ (2002) 33
Processus (9)
 4 grandes phases :
 Étude : établit les besoins
 Élaboration : besoins détaillés, analyse et
design de haut niveau pour créer une
architecture de départ et un planning
 Construction : plusieurs itérations pour produire
un logiciel testé et répondant aux besoins
 Transition : test système et formation des
utilisateurs
Cours semaine 1, jour 1 Cours C++ (2002) 34
Processus (10)
Etude Elaboration Construction Transition
Itération
Préliminaire
Analyse
Design
Architecture
Implémentation
Plannification
Test / Acceptation
Itération
#1
Itération
#2…
Itération
#n+1
Itération
#…
Itération
#m
Itération
#m+1
Itération
#m+2
Intégration
Cours semaine 1, jour 1 Cours C++ (2002) 35
Analyse et conception (suite)
 Avoir une référence méthodologique est une
bonne chose
 Mettre en place un processus de gestion de
projet est encore mieux
 Il faut cependant penser à disposer d’un
langage permettant d’effectuer une
modélisation
Cours semaine 1, jour 1 Cours C++ (2002) 36
Modélisation
 Besoin d’une Lingua Franca
 Faire de la conception orientée objet ou utiliser
un langage orienté objet nécessite de faire une
analyse du monde de l’application à développer
 L’analyse doit être comprise par le client
 Il parle de son univers
 L’analyse doit être comprise par le développeur
 De plus : certains programmes antérieurs et
autres librairies doivent éventuellement être
intégrés
Cours semaine 1, jour 1 Cours C++ (2002) 37
Modélisation (2)
 À la différence de Fortran, Basic, Pascal ou
encore C, commencer à programmer sans
analyse du monde se révèle très
 Dangereux
 Inefficace
 Les langages orientés objet doivent donc
être utilisés comme il se doit !
 Un objet, et sa définition, se respectent !
Cours semaine 1, jour 1 Cours C++ (2002) 38
Modélisation (3)
 Différentes méthodes d’analyse orientée
objet existent, certaines étant spécialisées
comme, par exemple, pour le temps réel
 Méthodes générales : OMT, Booch, OOSE
 Temps réel : RTMM
 Une méthode particulière d’analyse
supplante désormais presque toutes les
autres :
 UML, Unified Modeling Language
Cours semaine 1, jour 1 Cours C++ (2002) 39
UML
 UML n’est pas une invention ab nihilo
 UML est en fait la fusion de plusieurs
méthodologies orientées objet dont chacune
avait ses forces et ses faiblesses
 Au début du cycle de conception de l’UML, de
plus en plus de méthodologies ont été analysées
et le meilleur en a été gardé
 UML peut presque, aujourd’hui, être qualifié de
synthèse des modélisations objet
Cours semaine 1, jour 1 Cours C++ (2002) 40
UML (2)
 UML est un VRAI standard
 La conception d’UML a commencé en dehors
du monde de la normalisation
 L’UML a ensuite été soumis à l’OMG, l’Object
Management Group
 L’OMG est également responsable, entre autre
chose, de CORBA…
 UML n’est cependant pas toujours implémenter
complètement, certains « oubliant » des types
de diagrammes
Cours semaine 1, jour 1 Cours C++ (2002) 41
UML (3)
 UML n’est pas une langue morte
 Au delà du fait qu’elle soit de plus en plus
utilisée, cette langue évolue encore
 UML participe désormais à une intégration très
large au sein de l’OMG
 UML en XML : XMI, XML Metadata Interchange
 MDA : Model Driven Architecture ; UML/XMI
comme base pour la définition d’applications et
l’échange de modèles entre entreprises (CORBA,
J2EE, .Net, services web)
Cours semaine 1, jour 1 Cours C++ (2002) 42
UML : élaboration
Méthode Booch
Méthode OOSE
Méthode OMT
Autres méthodes
Partenaires UML
OMG
Unified Method 0.8 - 1995
UML 0.9 - 1996
UML 1.0 – 1996/1997
UML 1.3 – 1999
UML 1.1 – 1997
Cours semaine 1, jour 1 Cours C++ (2002) 43
Origines d’UML
 Les trois méthodes de base de l’UML sont :
 Méthode Booch : Booch
 Méthode OMT : Rumbaugh
 Méthode OOSE : Jacobson
 Booch, Jacobson et Rumbaugh travaillent
ensemble chez Rational
 Étonnamment, Rational Rose est pour l’heure le
produit leader de modélisation UML…
Cours semaine 1, jour 1 Cours C++ (2002) 44
Composants d’UML
 UML comprend un ensemble de
diagrammes assez différents dont chacun a
un rôle
 Plus ou moins général
 Plus ou moins large
 Statique ou dynamique
 UML peut être vu à travers un diagramme
baptisé 4+1
 Une vue centrale, quatre vues annexes
Cours semaine 1, jour 1 Cours C++ (2002) 45
Composants d’UML (2)
Vue
processus
Vue
déploiement
Vue
composants
Vue logique
(design)
Vue
Cas d’utilisation
Utilisateur final
- Fonctionnalités
- Vocabulaire
Développeurs
- Développement et gestion
du logiciel
Analystes/Testeurs
- Comportement
Intégration de système
- Performance
- Capacité d’extension
- Capacité de charge
Ingénierie de système
- Topologie
- Déploiement et installation
- Communication
Cours semaine 1, jour 1 Cours C++ (2002) 46
Composants d’UML (3)
Vue
structurelle
Vue
d’implémentation
Vue
comportementale
Vue
environnementale
Vue utilisateur
Diagramme de classes
Diagramme objet
Diagramme de
cas d’utilisation
Diagramme de composants
Diagramme d’activité
Diagramme de séquence
Diagramme de collaboration
Diagramme d’états-transitions
Diagramme de déploiement
Cours semaine 1, jour 1 Cours C++ (2002) 47
UML : Use Case
 Les Use Case (cas d’utilisation) permettent
de faire l’étude préalable des fonctionnalités
recherchées par dialogue avec l’utilisateur
 Les Use Case diagrams sont un support à la
modélisation et à la discussion
 L’information est surtout informelle
 Scénarios (documents texte d’explication), copies
d’écran, etc
 Statique et dynamique
Cours semaine 1, jour 1 Cours C++ (2002) 48
UML : Use Case (2)
internaute
navigue
se connecte
paie son abonnement
« utilise »
Cours semaine 1, jour 1 Cours C++ (2002) 49
UML : Class Diagram
 Les diagrammes de classes permettent de
définir la taxonomie (classification) des
différents objets nécessaires au bon
fonctionnement du système
 Les diagrammes de classes sont statiques
 Les diagrammes de classes permettent de
faire la distinction entre l’appartenance à un
groupe et la composition d’un objet
Cours semaine 1, jour 1 Cours C++ (2002) 50
UML : Class Diagram, aparte
 Avant toute modélisation objet, il faut
clairement faire la distinction entre « est
un » (is-a) et « a un » (has-a)
 Un cheval est un mammifère, un homme est un
mammifère
 Un homme a des jambes
 Une fourmi a des pattes
 Ces deux mécanismes sont à la base de la
définition des classes
Cours semaine 1, jour 1 Cours C++ (2002) 51
UML : Class Diagram (2)
VêtementCheval Homme
Animal
MammifèreInsecte Jambe
Famille
1 2,4
1 1..*
1
1..*
Cours semaine 1, jour 1 Cours C++ (2002) 52
UML : Class Diagram (3)
 Dans un diagramme de classe, on marque le
lien is-a par l’héritage
 Le lien has-a est beaucoup plus raffiné, il
est possible de noter :
 Une association
 Une aggrégation
 Une composition
 Il est également possible de marquer des
cardinalité et des sens de navigation
Cours semaine 1, jour 1 Cours C++ (2002) 53
UML : Class Diagram (4)
TripTarif
Enumeration getZones()
Price getPrice( Zone )
price
zone
TripLeg
* *
Association : deux objets sont liés mais de manière
relativement indépendante. La relation est très
relâchée.
Cours semaine 1, jour 1 Cours C++ (2002) 54
UML : Class Diagram (5)
1
ExhaustSystem
Muffler Tailpipe
0..2
Aggrégation : plus forte que l’association, elle marque
un lien de composition fort. Les constituant peuvent
exister sans l’aggrégat mais cela n’a alors plus
beaucoup d’intérêt.
Cours semaine 1, jour 1 Cours C++ (2002) 55
UML : Class Diagram (6)
3
DistributeurDeTickets
SélecteurDestination
Composition : il s’agit du lien le plus fort : les
constituants ne peuvent pas exister sans l’aggrégat.
Note : le choix entre une aggrégation et une composition
dépend généralement de l’univers dans lequel se fait la
modélisation
Cours semaine 1, jour 1 Cours C++ (2002) 56
UML : Class Diagram (7)
 Lors de la définition d’un héritage entre
classes, il faut toujours commencer par le
plus général pour descendre vers le plus
particulier
 Autrement dit : ne pas faire de hiérarchies
inversées
 La racine d’un arbre doit être un objet très
général
 C’est grâce à cela que l’on peut réutiliser
Cours semaine 1, jour 1 Cours C++ (2002) 57
UML : Class Diagram (8)
Directeur
Manager
Employé
Employé
Manager
Directeur
Note : un diagramme
de classes n’est pas
un organigramme de
fonctions !
Cours semaine 1, jour 1 Cours C++ (2002) 58
UML : Class Diagram (9)
 Des classes peuvent être regroupées en
package (paquetage)
 Un package est un groupe de classes dont le
rôle est similaire ou qui possèdent la même
appartenance
 Package des mammifères
 Package de connexion réseau
 Un package permet d’obtenir un niveau
d’abstraction (il cache la foule…)
Cours semaine 1, jour 1 Cours C++ (2002) 59
UML : Class Diagram (10)
Collaborations Statechart Activity
Éléments dynamiques
Gestion du
modèle
Foundation
Use Cases
Common
Behavior
Cours semaine 1, jour 1 Cours C++ (2002) 60
UML : Exercice #1
 Créer un diagramme de classes dans le
domaine des transports en commun
 Définnissez une arborescence des moyens de
transport
 Définissez les constituants et l’environnement
de ces moyens de transport
 N’utilisez pas les packages…
Cours semaine 1, jour 1 Cours C++ (2002) 61
UML : Exercice #2
 Système d’enregistrement d’une conférence
 Créez la hiérarchie incorporant :
 Les organisateurs
 Les orateurs invités
 Les orateurs principaux
 Les orateurs annexes
 Les participants inscrits industriels
 Les participants inscrits académiques (profs)
 Les participants inscrits étudiants
Cours semaine 1, jour 1 Cours C++ (2002) 62
UML : Exercice #2 (2)
 Que se passe-t-il si
 Un organisateur est orateur annexe
 Un étudiant est orateur principal
 Un orateur principal décide de ne pas présenter
ses travaux mais assiste tout de même en tant
que participant inscrit académique
Cours semaine 1, jour 1 Cours C++ (2002) 63
UML : Exercice #2 (3)
 Conclusions :
 Un héritage simple est parfois insuffisant mais
 L’héritage multiple apporte beaucoup de
complication et d’illisibilité
 L’introduction / la création d’associations peut
être bénéfique
 Mais certaines conditions devront alors être
respectées
Cours semaine 1, jour 1 Cours C++ (2002) 64
UML : Object Diagram
 Les diagrammes d’objets montrent les
instances et les liens entre objets
 À la différence du diagramme de classes, le
diagramme d’objets est dynamique
 Il illustre des situations
 Il permet de présenter les structures des objets
et des données
 Il est en fait “presque” dynamique
Cours semaine 1, jour 1 Cours C++ (2002) 65
UML : Object Diagram (2)
c : Compagnie
d1 : Département
nom = "ventes"
p : Personne
nom = "Dupont"
id = 2718
emploi ="vendeur"
d2 : Département
nom = " R&D"
: Adresse
addresse = "rue"
Cours semaine 1, jour 1 Cours C++ (2002) 66
UML : Component diagram
 Les diagrammes de composants permettent
de représenter la structure physique de
l’implémentation
 Organisation du code source
 Compilation d’exécutables
 Bases de données physiques
 Ils sont proches des choix techniques
 Ils sont statiques
Cours semaine 1, jour 1 Cours C++ (2002) 67
UML : Component diagram (2)
index.html
find.html
nateng.dll
find.exe
dbacs.exe
Cours semaine 1, jour 1 Cours C++ (2002) 68
UML : Activity diagram
 Les diagrammes d’activité permette
d’obtenir une vision orientée métier d’un
processus
 Montre l’enchaînement des actions, les
synchronisations, les responsabilités des
acteurs
 Note : ils ont de plus en plus de succès pour
les modélisations dans les logiciels de
workflow
Cours semaine 1, jour 1 Cours C++ (2002) 69
UML : Activity diagram (2)
Donner #
remboursement
Client Ventes StocksComptabilité
Renvoyer
article
Informer
du renvoi
Réception
article
Stockage
article
Rembourser
article
Article
[renvoyé]
Article
[disponible]
Cours semaine 1, jour 1 Cours C++ (2002) 70
UML : Sequence diagram
 Les diagrammes de séquence permettent de
raffiner les Use Case diagrams en :
 Permettant d’identifier les objets participants
 Permettant de trouver des objets manquants
 Permettant de marquer les enchaînements
 Ils marquent également des durées
d’exécution
 Ils sont dynamiques
Cours semaine 1, jour 1 Cours C++ (2002) 71
UML : Sequence diagram (2)
sélectionBoisson()
récupérationMonnaie()
récupérationBoisson()
introductionArgent()
Client
Distributeur
de boissons
Cours semaine 1, jour 1 Cours C++ (2002) 72
UML : Collaboration diagram
 Les diagrammes de collaborations
permettent de représenter les interactions
entre classes
 Ils présentent les flux de contrôle
 Ils illustrent la coordination entre les objets de
structure et les objets de contrôle
 Ils sont dynamiques (orientés messages)
Cours semaine 1, jour 1 Cours C++ (2002) 73
UML : Collaboration diagram (2)
p : ODBCProxy
1 : crée
2 : prépareAction( a, d, o )
3 : détruit
c : Client
d2 : Département
2.1 : affecte( d, 3.14 )
2.2 : affecte( a, "CO" )
Cours semaine 1, jour 1 Cours C++ (2002) 74
UML : Statechart diagram
 Les diagrammes d’état-transition
correspondent à une version allégée des
diagrammes d’activité
 Plus de responsabilités, de synchronisation
 Ils pourraient typiquement être utilisé en
automatique pour modéliser le
comportement d’un automate
 Ils sont dynamiques (orientés évènements)
Cours semaine 1, jour 1 Cours C++ (2002) 75
UML : Statechart diagram (2)
Heures
clignotent
Secondes
clignotent
Minutes
clignotent
touche 2
touches 1 & 2
touche 2
touche 2
touche 1
touche 1
touches 1 & 2
touches
1 & 2
Incrément
heures
Incrément
secondes
Incrément
minutes
Arrêt
clignotement
Cours semaine 1, jour 1 Cours C++ (2002) 76
UML : Deployment diagram
 Les diagrammes de déploiement permettent
de capturer la topologie du système sur
laquelle est déployée l’application
 Permet de définir
 La distribution des composants
 De pré-identifier les éventuels goulots
d’étranglement
Cours semaine 1, jour 1 Cours C++ (2002) 77
UML : Deployment diagram (2)
réseau
serveur serveur serveur
serveur
primaire
serveur
données
imprimante
Cours semaine 1, jour 1 Cours C++ (2002) 78
UML de base et extensions
 Comme nous l’avons vu, UML comporte 9 types
de diagrammes différents
 Ces diagrammes ont TOUS leur utilité
 Certains peuvent cependant être inutiles dans un projet
 UML comporte également un ensemble de
fonctionnalités supplémentaires dans la notation
 Stéréotypes de classe : permettent de montrer
l’appartenance à un modèle « technique »
 Profils : extensions pour la persistance, le temps-réel,
etc.
Cours semaine 1, jour 1 Cours C++ (2002) 79
Points forts d’UML
 Du fait de sa standardisation par l’OMG, la
méthode est supportée par de nombreux
outils. Grâce à cela, une course aux
fonctionnalités s’est instaurée
 Prise en compte des bases de données
existantes
 Génération automatique de squelettes de code
 Possibilité d’importer ou d’exporter dans un
vocabulaire XML
Cours semaine 1, jour 1 Cours C++ (2002) 80
Un outil UML : Rational Rose
Cours semaine 1, jour 1 Cours C++ (2002) 81
Un outil UML: Rational Rose (2)
Cours semaine 1, jour 1 Cours C++ (2002) 82
Un outil UML: Rational Rose (3)
Cours semaine 1, jour 1 Cours C++ (2002) 83
Un outil UML: Rational Rose (4)
Cours semaine 1, jour 1 Cours C++ (2002) 84
Un outil UML: Rational Rose (5)
Cours semaine 1, jour 1 Cours C++ (2002) 85
Un outil UML: Rational Rose (6)
Cours semaine 1, jour 1 Cours C++ (2002) 86
Un outil UML: Rational Rose (7)
Cours semaine 1, jour 1 Cours C++ (2002) 87
Lourdeurs
 Les normes de modélisation, les processus
de gestion de projet, l’amélioration des
habitudes de travail par l’intermédiaire de
référentiels tels que CMM ou d’autres
 Tout ceci a un prix et demande du temps
 Tout ceci est lourd et difficile
 Tout ceci nécessite l’adhésion de tous
 Une fois en place, de telles méthodes se
révèlent gagnantes mais :
Cours semaine 1, jour 1 Cours C++ (2002) 88
Lourdeurs (2)
 Tout ceci en vaut-il toujours « la chandelle »
?
 Une petite structure de développement ou
une petite société peut-elle s’autoriser de
mettre en place de telles procédures,
administrativement lourde ?
 Certains ont eu une réaction négative et ont
eu une volonté d’allègement des processus
Cours semaine 1, jour 1 Cours C++ (2002) 89
eXtreme Programming
 XP (nom choisi avant que Microsoft ne lui
accorde une autre signification…) est une
méthodologie de développement objet
allégée d’un point de vue administratif
 D’un point de vue CMM, il s’agit d’un
niveau 1 très amélioré
 « À la mode » car prône pour une gestion
très réactive des projets, et des problèmes…
Cours semaine 1, jour 1 Cours C++ (2002) 90
eXtreme Programming (2)
 Il faut considérer XP comme une
organisation de gestion de projet applicable:
 Aux petites équipes
 Aux équipes effectuant un travail assez
autarcique et ayant donc relativement peu
d’interconnections avec des équipes extérieures
 Aux équipes dont les travaux seront peu
réutilisés par l’extérieur et où différents niveaux
de documentation ne sont pas nécessaires
Cours semaine 1, jour 1 Cours C++ (2002) 91
eXtreme Programming (3)
 Quatre valeurs mises en exergue :
 Communication
 Travail en groupe (2 programmeurs pour 1 poste)
 Simplicité
 Toujours faire au plus simple
 Temps de réponse
 Chacun doit répondre rapidement aux questions
 Courage
 Pour se remettre en question après les choix
Cours semaine 1, jour 1 Cours C++ (2002) 92
eXtreme Programming (4)
 Principes de base :
 Faible temps de réponse de la part des
développeurs eux-même ET des clients
 Aller au plus simple (rasoir d’Occam)
 Changements incrémentaux comme dans la
méthode itérative
 Acceptation du changement
 Travail de qualité
Cours semaine 1, jour 1 Cours C++ (2002) 93
eXtreme Programming (5)
 Activités de base :
 Codage, pour la communication et l’apprentissage
 Tests, automatisés, unitaires et système, « tout ce
qui ne peut pas être mesuré n’existe pas » (…)
 Écoute, des autres développeurs, des clients
 Design, tant du système à développer que de
l’équipe qui le développe
Cours semaine 1, jour 1 Cours C++ (2002) 94
Pratiques XP
 Planning
 Le client définit les besoins, la date de livraison
 Les techniciens en présentent les conséquences
pour les coûts et le planning détaillé
 Il s’agit bien des techniciens, pas des commerciaux !
 Petites releases fréquentes
 Une métaphore générale par projet
 Une idée ou un comcept central par projet
Cours semaine 1, jour 1 Cours C++ (2002) 95
Pratiques XP (2)
 Design simple
 Pas de réplication de la logique métier
 Le moins possible de classes et de méthodes
 Incorpore toutes les idées des développeurs
 Passe tous les tests
 Tests
 Procédures de test automatisé pour TOUTES
les fonctionnalités du système
Cours semaine 1, jour 1 Cours C++ (2002) 96
Pratiques XP (3)
 Réécriture
 Est-il possible de réécrire un programme
existant pour rendre l’ajout de nouvelles
fonctionnalités plus simple ?
 Après un ajout d’une fonctionnalité, peut-on
rendre le programme plus simple
 Programmation à deux
 2 personnes, 1 écran, 1 clavier, 1 souris
 1 pour une vue globale, 1 pour ici et maintenant
Cours semaine 1, jour 1 Cours C++ (2002) 97
Pratiques XP (4)
 Propriété collective
 Si un développeur trouve intéressant d’ajouter
une fonctionnalité dans un programme de
quelqu’un d’autre, il DOIT le faire
 Tout le monde peut simplifier les programmes
de tout le monde
 Intégration continue
 Le système est testé tous les jours, pas toutes
les semaines ou tous les mois
Cours semaine 1, jour 1 Cours C++ (2002) 98
Pratiques XP (5)
 Semaine de 40 heures
 Les heures supplémentaires sont un symptôme
de problèmes graves
 Présence du client
 Un utilisateur final est intégré à l’équipe
 Respect de standards de codage
 Pas de code dupliqué
 Faire comme il faut ou ne pas faire du tout
 Développeur non identifiable par le code
Cours semaine 1, jour 1 Cours C++ (2002) 99
Quelques défaut d’XP
 Les extrêmes auquels il ne faut pas aboutir :
 La conception est dans le code
 Ce genre de principe est naturel pour un logiciel
développé « à la maison »
 Les bidouilles et les GOTO à la Fortran/Basic sont
une des pires choses qui soient : les laisser aux
compilateurs et autres optimiseurs !
 La documentation est orale
 Personne n’est irremplaçable et
 Personne n’est éternel…
Cours semaine 1, jour 1 Cours C++ (2002) 100
XP, et après ?
 L’eXtreme Programming prend le contre-
pied des méthodes plus lourdes comme
CMM, RUP (également ITIL, SPICE,
Objectory, etc)
 Un des accents est mis sur le besoin
constant de tests par l’intermédiaire de
petits programmes automatisés (framework)
 Tests unitaires, système, d’intégration
Cours semaine 1, jour 1 Cours C++ (2002) 101
XP, et après ? (2)
 Cependant, les méthodologies plus lourdes
continuent à progresser tandis que la
recherche en génie logiciel essaie de
résoudre certains problèmes
 Question 1 : peut-on pousser plus avant les
capacités de génération de code ?
 Question 2 : peut-on prouver, au moins
partiellement, la correction d’un programme
donné ?
Cours semaine 1, jour 1 Cours C++ (2002) 102
Conditions
 Les réponses sont affirmatives !
 Technique importante : les pré-conditions et
les post-conditions
 Elles ont pour la première fois été introduites
dans le langage orienté objet Eiffel de Meyer
 Il existait déjà des choses en C
 Elles peuvent se retrouver aujourd’hui, à des
degrés moindres, dans C++ ou Java
 Et surtout : elles peuvent être définies à l’étape
de modélisation d’un système
Cours semaine 1, jour 1 Cours C++ (2002) 103
Conditions (2)
 En complément du langage Eiffel, Meyer a
mis au point une technique formelle de
conception orientée objet
 Design By Contract
 « Si tu promets d’appeler la méthode m en
respectant la pré-condition alors, en retour, la
méthode m promet de respecter la post-condition »
 La généralisation des contrats permet de définir
la responsabilité de chacun
Cours semaine 1, jour 1 Cours C++ (2002) 104
Méthodes formelles
 Introduite lors des phases de modélisation,
de telles techniques sont qualifiées de
formelles
 Une méthode formelle permet de définir au
niveau de l’appel d’une fonction :
 Les pré-conditions qui donnent les conditions
internes nécessaires au bon déroulement
 Les post-conditions qui permettent de contrôler
l’état des lieux après exécution
Cours semaine 1, jour 1 Cours C++ (2002) 105
Méthodes formelles (2)
 En complément des pré et post-conditions,
il est possible de définir l’algorithme de la
fonction de manière abstraite
 L’algorithmique définit ici est assez abstraite et
assez proche des mathématiques
 Cependant, il s’agit parfois presque de langages
de programmation !
 Il existe plusieurs méthodes. Nous en
présentons brièvement 2 : OCL et B
Cours semaine 1, jour 1 Cours C++ (2002) 106
OCL
 OCL signifie Object Constraint Language
 OCL permet de définir des :
 Des pré-conditions
 Des post-conditions
 Des algorithmes au niveau de chaque méthode
de chaque objet
 Encore une fois, cela ressemble parfois à un
langage de programmation mais
Cours semaine 1, jour 1 Cours C++ (2002) 107
OCL (2)
 OCL n’est pas un langage de
programmation (même s’il commence à
exister des compilateurs OCL…)
 Les contraintes OCL peuvent être analysées
automatiquement
 La totalité d’un système peut être modélisé
 Et enfin
 OCL fait partie de UML !
Cours semaine 1, jour 1 Cours C++ (2002) 108
OCL : Exemple
<JobCategory> <Facility>
reqs
<Job>
when: TimeInterval <Resource>
0..*
type
allocated
provides 0..*
0..1
inv Job::allocated<>0 ==> allocated.provides->includesAll(type.reqs)
--Any allocated resource must have the required facilities
inv Resource::jo1, jo2: Job::
(schedule->includesAll({jo1,jo2}) ==> jo1.when.noOverlap(jo2.when)
-- no double-booking of resources
schedule
0..*
Cours semaine 1, jour 1 Cours C++ (2002) 109
Méthodes formelles, conclusion
 Science-fiction ?
 Les logiciels des deux lignes de métro
dernièrement créés à Paris ont été conçus grâce à
la méthode B
 La RATP ne jure désormais plus que par B ! Ils
n’avaient jamais réussi à obtenir des logiciels de ce
niveau de qualité avant
 Tous les logiciels sensibles (avec des vies
humaines en jeu) seront très probablement conçus
avec de telles méthodes dans un avenir proche
Cours semaine 1, jour 1 Cours C++ (2002) 110
Méthodes formelles, conclusion (2)
 Les méthodes formelles vont au delà des
simples notions des langages orientés objet.
Cependant :
 Elles sont par exemple INTÉGRÉES dans
UML (versions 1.1 et maintenant 1.3)
 De plus en plus de langages orientés objet
intègre des capacités d’assertion qui permettent,
grosso modo, de faire des vérifications de
qualité du code sans passer par un débogueur
Cours semaine 1, jour 1 Cours C++ (2002) 111
Questions / Remarques

Contenu connexe

Tendances

Uml
UmlUml
Modélisation avec UML
Modélisation avec UMLModélisation avec UML
Modélisation avec UML
ECAM Brussels Engineering School
 
Uml upxp2
Uml upxp2Uml upxp2
Uml upxp2
Joubi Aaziz
 
Design Pattern: Développement et Bonnes pratiques
Design Pattern: Développement et Bonnes pratiquesDesign Pattern: Développement et Bonnes pratiques
Design Pattern: Développement et Bonnes pratiques
Alex Wilfried OUATTARA
 
Introduction à Uml
Introduction à UmlIntroduction à Uml
Introduction à Uml
Mireille Blay-Fornarino
 
U M L Analyse Et Conception Objet
U M L Analyse Et Conception ObjetU M L Analyse Et Conception Objet
U M L Analyse Et Conception Objet
Amine Chkr
 
Implanter l'AOP... Comment partir du bon pied?
Implanter l'AOP... Comment partir du bon pied?Implanter l'AOP... Comment partir du bon pied?
Implanter l'AOP... Comment partir du bon pied?
Elapse Technologies
 
Modélisation par Objets - Introduction - De Merise à UML
Modélisation par Objets - Introduction - De Merise à UMLModélisation par Objets - Introduction - De Merise à UML
Modélisation par Objets - Introduction - De Merise à UML
Mireille Blay-Fornarino
 
patron de conception
patron de conception patron de conception
patron de conception
Shili Mohamed
 
Cours de C++, en français, 2002 - Cours 2.5
Cours de C++, en français, 2002 - Cours 2.5Cours de C++, en français, 2002 - Cours 2.5
Cours de C++, en français, 2002 - Cours 2.5
Laurent BUNIET
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UML
Amir Souissi
 
CIDOC CRM et Linked Data
CIDOC CRM et Linked DataCIDOC CRM et Linked Data
CIDOC CRM et Linked Data
Equipex Biblissima
 
Cours de Génie Logiciel / ESIEA 2016-17
Cours de Génie Logiciel / ESIEA 2016-17Cours de Génie Logiciel / ESIEA 2016-17
Cours de Génie Logiciel / ESIEA 2016-17
Thierry Leriche-Dessirier
 
Chp6 - De UML vers C++
Chp6 - De UML vers C++Chp6 - De UML vers C++
Chp6 - De UML vers C++
Lilia Sfaxi
 
Uml
UmlUml
L Architecture Logicielle En Pratique
L Architecture Logicielle En PratiqueL Architecture Logicielle En Pratique
L Architecture Logicielle En Pratique
François Trudel
 
Présentation du CIDOC CRM 20151109
Présentation du CIDOC CRM 20151109Présentation du CIDOC CRM 20151109
Présentation du CIDOC CRM 20151109
Patrick Le Boeuf
 
CoursUML-SlimMesfar-Total
CoursUML-SlimMesfar-TotalCoursUML-SlimMesfar-Total
CoursUML-SlimMesfar-Total
Ahmed Mekkaoui
 

Tendances (20)

Uml
UmlUml
Uml
 
Modélisation avec UML
Modélisation avec UMLModélisation avec UML
Modélisation avec UML
 
Uml upxp2
Uml upxp2Uml upxp2
Uml upxp2
 
Design Pattern: Développement et Bonnes pratiques
Design Pattern: Développement et Bonnes pratiquesDesign Pattern: Développement et Bonnes pratiques
Design Pattern: Développement et Bonnes pratiques
 
Introduction à Uml
Introduction à UmlIntroduction à Uml
Introduction à Uml
 
U M L Analyse Et Conception Objet
U M L Analyse Et Conception ObjetU M L Analyse Et Conception Objet
U M L Analyse Et Conception Objet
 
Implanter l'AOP... Comment partir du bon pied?
Implanter l'AOP... Comment partir du bon pied?Implanter l'AOP... Comment partir du bon pied?
Implanter l'AOP... Comment partir du bon pied?
 
Modélisation par Objets - Introduction - De Merise à UML
Modélisation par Objets - Introduction - De Merise à UMLModélisation par Objets - Introduction - De Merise à UML
Modélisation par Objets - Introduction - De Merise à UML
 
patron de conception
patron de conception patron de conception
patron de conception
 
Cours de C++, en français, 2002 - Cours 2.5
Cours de C++, en français, 2002 - Cours 2.5Cours de C++, en français, 2002 - Cours 2.5
Cours de C++, en français, 2002 - Cours 2.5
 
diagramme de séquence UML
diagramme de séquence UMLdiagramme de séquence UML
diagramme de séquence UML
 
CIDOC CRM et Linked Data
CIDOC CRM et Linked DataCIDOC CRM et Linked Data
CIDOC CRM et Linked Data
 
Cours de Génie Logiciel / ESIEA 2016-17
Cours de Génie Logiciel / ESIEA 2016-17Cours de Génie Logiciel / ESIEA 2016-17
Cours de Génie Logiciel / ESIEA 2016-17
 
Chp6 - De UML vers C++
Chp6 - De UML vers C++Chp6 - De UML vers C++
Chp6 - De UML vers C++
 
Uml
UmlUml
Uml
 
L Architecture Logicielle En Pratique
L Architecture Logicielle En PratiqueL Architecture Logicielle En Pratique
L Architecture Logicielle En Pratique
 
Présentation du CIDOC CRM 20151109
Présentation du CIDOC CRM 20151109Présentation du CIDOC CRM 20151109
Présentation du CIDOC CRM 20151109
 
CM uml-diag-statiques
CM uml-diag-statiquesCM uml-diag-statiques
CM uml-diag-statiques
 
Cours uml
Cours umlCours uml
Cours uml
 
CoursUML-SlimMesfar-Total
CoursUML-SlimMesfar-TotalCoursUML-SlimMesfar-Total
CoursUML-SlimMesfar-Total
 

Similaire à Cours de C++, en français, 2002 - Cours 1.1

Cours de C++, en français, 2002 - Cours 1.4
Cours de C++, en français, 2002 - Cours 1.4Cours de C++, en français, 2002 - Cours 1.4
Cours de C++, en français, 2002 - Cours 1.4
Laurent BUNIET
 
Support de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdfSupport de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdf
YasushiTsubakik
 
PROGRAMMATION 2e GENIE PARTIE THEORIE.ppt
PROGRAMMATION 2e GENIE PARTIE THEORIE.pptPROGRAMMATION 2e GENIE PARTIE THEORIE.ppt
PROGRAMMATION 2e GENIE PARTIE THEORIE.ppt
EddySHANGA
 
Qualité de code et bonnes pratiques
Qualité de code et bonnes pratiquesQualité de code et bonnes pratiques
Qualité de code et bonnes pratiques
ECAM Brussels Engineering School
 
Darwin appliqué à LabVIEW : l’évolution de la gestion des données
Darwin appliqué à LabVIEW : l’évolution de la gestion des donnéesDarwin appliqué à LabVIEW : l’évolution de la gestion des données
Darwin appliqué à LabVIEW : l’évolution de la gestion des données
Luc Desruelle
 
Lecture_1_Concepts-fondamentaux_P01.pptx
Lecture_1_Concepts-fondamentaux_P01.pptxLecture_1_Concepts-fondamentaux_P01.pptx
Lecture_1_Concepts-fondamentaux_P01.pptx
BtnPrinciiIsral
 
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de ConceptionChp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de Conception
Lilia Sfaxi
 
CPOO.pdf
CPOO.pdfCPOO.pdf
POO-Cours.pdf
POO-Cours.pdfPOO-Cours.pdf
POO-Cours.pdf
BoubakerMedanas
 
Cours de C++, en français, 2002 - Cours 1.2
Cours de C++, en français, 2002 - Cours 1.2Cours de C++, en français, 2002 - Cours 1.2
Cours de C++, en français, 2002 - Cours 1.2
Laurent BUNIET
 
Entity_framework_db first
Entity_framework_db firstEntity_framework_db first
Entity_framework_db first
Zineb ELGARRAI
 
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
Guillaume Saint Etienne
 
python-Cours Officiel POO Python-m103.pdf
python-Cours Officiel POO Python-m103.pdfpython-Cours Officiel POO Python-m103.pdf
python-Cours Officiel POO Python-m103.pdf
trendingv83
 
Cours design pattern m youssfi partie 1 introduction et pattern strategy
Cours design pattern m youssfi partie 1 introduction et pattern strategyCours design pattern m youssfi partie 1 introduction et pattern strategy
Cours design pattern m youssfi partie 1 introduction et pattern strategy
ENSET, Université Hassan II Casablanca
 
Algo vol.2 sujets
Algo vol.2   sujetsAlgo vol.2   sujets
Algo vol.2 sujets
chrisdilane
 
UML use case class2UML use case class2.ppt
UML use case class2UML use case class2.pptUML use case class2UML use case class2.ppt
UML use case class2UML use case class2.ppt
ryoko1935
 
UML use case class une presentation sur uml .ppt
UML use case class une presentation sur uml .pptUML use case class une presentation sur uml .ppt
UML use case class une presentation sur uml .ppt
ryoko1935
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logicielle
cyrilgandon
 

Similaire à Cours de C++, en français, 2002 - Cours 1.1 (20)

Cours de C++, en français, 2002 - Cours 1.4
Cours de C++, en français, 2002 - Cours 1.4Cours de C++, en français, 2002 - Cours 1.4
Cours de C++, en français, 2002 - Cours 1.4
 
Support de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdfSupport de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdf
 
PROGRAMMATION 2e GENIE PARTIE THEORIE.ppt
PROGRAMMATION 2e GENIE PARTIE THEORIE.pptPROGRAMMATION 2e GENIE PARTIE THEORIE.ppt
PROGRAMMATION 2e GENIE PARTIE THEORIE.ppt
 
Qualité de code et bonnes pratiques
Qualité de code et bonnes pratiquesQualité de code et bonnes pratiques
Qualité de code et bonnes pratiques
 
Darwin appliqué à LabVIEW : l’évolution de la gestion des données
Darwin appliqué à LabVIEW : l’évolution de la gestion des donnéesDarwin appliqué à LabVIEW : l’évolution de la gestion des données
Darwin appliqué à LabVIEW : l’évolution de la gestion des données
 
Lecture_1_Concepts-fondamentaux_P01.pptx
Lecture_1_Concepts-fondamentaux_P01.pptxLecture_1_Concepts-fondamentaux_P01.pptx
Lecture_1_Concepts-fondamentaux_P01.pptx
 
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de ConceptionChp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de Conception
 
CPOO.pdf
CPOO.pdfCPOO.pdf
CPOO.pdf
 
POO-Cours.pdf
POO-Cours.pdfPOO-Cours.pdf
POO-Cours.pdf
 
Cours de C++, en français, 2002 - Cours 1.2
Cours de C++, en français, 2002 - Cours 1.2Cours de C++, en français, 2002 - Cours 1.2
Cours de C++, en français, 2002 - Cours 1.2
 
Entity_framework_db first
Entity_framework_db firstEntity_framework_db first
Entity_framework_db first
 
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
_(V3.0) Aux sources de la simplicité Bordeaux 2022.pptx
 
python-Cours Officiel POO Python-m103.pdf
python-Cours Officiel POO Python-m103.pdfpython-Cours Officiel POO Python-m103.pdf
python-Cours Officiel POO Python-m103.pdf
 
Cours design pattern m youssfi partie 1 introduction et pattern strategy
Cours design pattern m youssfi partie 1 introduction et pattern strategyCours design pattern m youssfi partie 1 introduction et pattern strategy
Cours design pattern m youssfi partie 1 introduction et pattern strategy
 
Algo vol.2 sujets
Algo vol.2   sujetsAlgo vol.2   sujets
Algo vol.2 sujets
 
Apprentissage du java
Apprentissage du javaApprentissage du java
Apprentissage du java
 
Generateur de code java (GenJAVA)
Generateur de code java (GenJAVA)Generateur de code java (GenJAVA)
Generateur de code java (GenJAVA)
 
UML use case class2UML use case class2.ppt
UML use case class2UML use case class2.pptUML use case class2UML use case class2.ppt
UML use case class2UML use case class2.ppt
 
UML use case class une presentation sur uml .ppt
UML use case class une presentation sur uml .pptUML use case class une presentation sur uml .ppt
UML use case class une presentation sur uml .ppt
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logicielle
 

Plus de Laurent BUNIET

Cours de C++, en français, 2002 - Cours 3.5
Cours de C++, en français, 2002 - Cours 3.5Cours de C++, en français, 2002 - Cours 3.5
Cours de C++, en français, 2002 - Cours 3.5
Laurent BUNIET
 
Cours de C++, en français, 2002 - Cours 3.4
Cours de C++, en français, 2002 - Cours 3.4Cours de C++, en français, 2002 - Cours 3.4
Cours de C++, en français, 2002 - Cours 3.4
Laurent BUNIET
 
Cours de C++, en français, 2002 - Cours 3.3
Cours de C++, en français, 2002 - Cours 3.3Cours de C++, en français, 2002 - Cours 3.3
Cours de C++, en français, 2002 - Cours 3.3
Laurent BUNIET
 
Cours de C++, en français, 2002 - Cours 3.2
Cours de C++, en français, 2002 - Cours 3.2Cours de C++, en français, 2002 - Cours 3.2
Cours de C++, en français, 2002 - Cours 3.2
Laurent BUNIET
 
Cours de C++, en français, 2002 - Cours 3.1
Cours de C++, en français, 2002 - Cours 3.1Cours de C++, en français, 2002 - Cours 3.1
Cours de C++, en français, 2002 - Cours 3.1
Laurent BUNIET
 
Cours de C++, en français, 2002 - Cours 2.4
Cours de C++, en français, 2002 - Cours 2.4Cours de C++, en français, 2002 - Cours 2.4
Cours de C++, en français, 2002 - Cours 2.4
Laurent BUNIET
 
Cours de C++, en français, 2002 - Cours 2.3
Cours de C++, en français, 2002 - Cours 2.3Cours de C++, en français, 2002 - Cours 2.3
Cours de C++, en français, 2002 - Cours 2.3
Laurent BUNIET
 
Cours de C++, en français, 2002 - Cours 2.2
Cours de C++, en français, 2002 - Cours 2.2Cours de C++, en français, 2002 - Cours 2.2
Cours de C++, en français, 2002 - Cours 2.2
Laurent BUNIET
 
Cours de C++, en français, 2002 - Cours 2.1
Cours de C++, en français, 2002 - Cours 2.1Cours de C++, en français, 2002 - Cours 2.1
Cours de C++, en français, 2002 - Cours 2.1
Laurent BUNIET
 
Cours de C++, en français, 2002 - Cours 1.5
Cours de C++, en français, 2002 - Cours 1.5Cours de C++, en français, 2002 - Cours 1.5
Cours de C++, en français, 2002 - Cours 1.5
Laurent BUNIET
 
Cours de C++, en français, 2002 - Cours 1.3
Cours de C++, en français, 2002 - Cours 1.3Cours de C++, en français, 2002 - Cours 1.3
Cours de C++, en français, 2002 - Cours 1.3
Laurent BUNIET
 
Cours de C++, en français, 2002 - Plan
Cours de C++, en français, 2002 - PlanCours de C++, en français, 2002 - Plan
Cours de C++, en français, 2002 - Plan
Laurent BUNIET
 

Plus de Laurent BUNIET (12)

Cours de C++, en français, 2002 - Cours 3.5
Cours de C++, en français, 2002 - Cours 3.5Cours de C++, en français, 2002 - Cours 3.5
Cours de C++, en français, 2002 - Cours 3.5
 
Cours de C++, en français, 2002 - Cours 3.4
Cours de C++, en français, 2002 - Cours 3.4Cours de C++, en français, 2002 - Cours 3.4
Cours de C++, en français, 2002 - Cours 3.4
 
Cours de C++, en français, 2002 - Cours 3.3
Cours de C++, en français, 2002 - Cours 3.3Cours de C++, en français, 2002 - Cours 3.3
Cours de C++, en français, 2002 - Cours 3.3
 
Cours de C++, en français, 2002 - Cours 3.2
Cours de C++, en français, 2002 - Cours 3.2Cours de C++, en français, 2002 - Cours 3.2
Cours de C++, en français, 2002 - Cours 3.2
 
Cours de C++, en français, 2002 - Cours 3.1
Cours de C++, en français, 2002 - Cours 3.1Cours de C++, en français, 2002 - Cours 3.1
Cours de C++, en français, 2002 - Cours 3.1
 
Cours de C++, en français, 2002 - Cours 2.4
Cours de C++, en français, 2002 - Cours 2.4Cours de C++, en français, 2002 - Cours 2.4
Cours de C++, en français, 2002 - Cours 2.4
 
Cours de C++, en français, 2002 - Cours 2.3
Cours de C++, en français, 2002 - Cours 2.3Cours de C++, en français, 2002 - Cours 2.3
Cours de C++, en français, 2002 - Cours 2.3
 
Cours de C++, en français, 2002 - Cours 2.2
Cours de C++, en français, 2002 - Cours 2.2Cours de C++, en français, 2002 - Cours 2.2
Cours de C++, en français, 2002 - Cours 2.2
 
Cours de C++, en français, 2002 - Cours 2.1
Cours de C++, en français, 2002 - Cours 2.1Cours de C++, en français, 2002 - Cours 2.1
Cours de C++, en français, 2002 - Cours 2.1
 
Cours de C++, en français, 2002 - Cours 1.5
Cours de C++, en français, 2002 - Cours 1.5Cours de C++, en français, 2002 - Cours 1.5
Cours de C++, en français, 2002 - Cours 1.5
 
Cours de C++, en français, 2002 - Cours 1.3
Cours de C++, en français, 2002 - Cours 1.3Cours de C++, en français, 2002 - Cours 1.3
Cours de C++, en français, 2002 - Cours 1.3
 
Cours de C++, en français, 2002 - Plan
Cours de C++, en français, 2002 - PlanCours de C++, en français, 2002 - Plan
Cours de C++, en français, 2002 - Plan
 

Cours de C++, en français, 2002 - Cours 1.1

  • 2. Cours semaine 1, jour 1 Cours C++ (2002) 2 Plan du jour  Présentation des langages orientés objets  Messages et concepts objets  Analyse et conception de systèmes, de programmes  eXtreme Programming, et après
  • 3. Cours semaine 1, jour 1 Cours C++ (2002) 3 Langages orientés objets  Langages orientés objets ou langages à objets sont une évolution significative par rapport aux langages procéduraux  Ex : Pascal, COBOL, C  Un peu moins de mathématiques, un peu plus naturel  Du point de vue du programmeur : abandon du simple enchaînement des appels de procédures et de fonctions
  • 4. Cours semaine 1, jour 1 Cours C++ (2002) 4 Langages orientés objets (2)  Du point de vue de l’analyse, l’homme a plutôt tendance à utiliser des classifications (taxonomies)  Elles permettent de diviser le monde en groupes et sous-groupes : le monde devient plus facile à appréhender et à modéliser  Les classifications peuvent être variées et fondées sur des analyses statistiques, par composantes principales, ou, de façon moins formelle, par distinction de caractéristiques littéraires communément admises
  • 5. Cours semaine 1, jour 1 Cours C++ (2002) 5 Messages  Un programme à base d’objets comporte des entités clairement identifiées, responsables de certains traitements sur des types de données clairement identifiées  Un programme est composé d’instances de classes, les instances pouvant communiquer les unes avec les autres  Pas d’appel de fonctions : juste des invocations
  • 6. Cours semaine 1, jour 1 Cours C++ (2002) 6 Messages (2)  L’exécution d’une tâche correspond à l’envoi d’un message à l’instance responsable du traitement et à la réception d’un message de réponse  Après tout, on a la même chose avec un empilement et un dépilement lors d’un appel de fonction !?  L’idée n’est pas la même 
  • 7. Cours semaine 1, jour 1 Cours C++ (2002) 7 Messages (3)  Naissance officielle des langages à objets  Simula 67, langage de programmation dédié à la simulation  Introduction de la notion d’objets  Simula 67 était une amélioration d’Algol  Première présentation en 1962  Simula est principalement fait pour supporter l’exécution d’univers basés sur des interactions faites par l’intermédiaire d’évènements discrets
  • 8. Cours semaine 1, jour 1 Cours C++ (2002) 8 Messages (4)  Événements discrets :  Quelque chose arrive  Quelqu’un s’en rend compte  Il informe une ou plusieurs autres entités qui réagissent en fonction de leurs états internes en:  Fournissant l’information demandée  Créant d’autres évènements  C’est la base des langages de simulation et l’idée initiale conduisant à leur définition
  • 9. Cours semaine 1, jour 1 Cours C++ (2002) 9 Messages (5)  Les langages de simulation ont introduits la notion d’entité indépendante ayant un traitement autonome  Cette idée a été reprise pour la (fausse) création des langages à objets  Les objets, entre eux, ne s’échangent que des messages  Un message peut être local ou distant (le principe est le même, pas l’implémentation)
  • 10. Cours semaine 1, jour 1 Cours C++ (2002) 10 Principes de base en objet  Les objets communiquent entre eux par messages  L’appelant (client) formate un message et l’envoi au destinataire (serveur)  Le destinataire vérifie qu’il sait traiter le message reçu et le traite s’il peut  Les objets ne sont pas monolithiques, ils s’agglomèrent les uns les autres pour en constituer des plus importants
  • 11. Cours semaine 1, jour 1 Cours C++ (2002) 11 Principes de base en objet (2)  Les principes de base en objets peuvent être résumés suivant la règle « Apple PIE »  Abstraction  Polymorphisme  Héritage (Inheritance)  Encapsulation  Nous reviendrons en détail sur ces principes tout au long du cours
  • 12. Cours semaine 1, jour 1 Cours C++ (2002) 12 Abstraction  L’abstraction est une généralisation  L’abstraction permet d’ignorer ou de cacher les détails, permettant d’extraire des points communs entre différentes entités  Exemples  « être humain » est une abstraction de « homme » et de « femme »  « animal » est une abstraction de « mammifère », qui est une abstraction de « cheval », qui lui-même est une abstraction d’ « ardennais »
  • 13. Cours semaine 1, jour 1 Cours C++ (2002) 13 Polymorphisme  Les abstractions sont faites à partir de caractéristiques partagées  Exemple : « cheval » et « dauphin » sont des « mammifères »  Ces abstractions ne se font pas uniquement sur les données mais également sur les traitements  Exemple : les « mammifères » se déplacent et se reproduisent
  • 14. Cours semaine 1, jour 1 Cours C++ (2002) 14 Polymorphisme (2)  Qu’une fonction soit disponible à un haut niveau d’abstraction ne signifie pas que son implémentation soit la même partout  Un « cheval » ne se déplace pas de la même manière qu’un « dauphin »  Il est cependant possible de traiter un groupe d’objets à un haut niveau en appelant des fonctions finalement différentes  DéplacerTousLesMammifères() = pour chaque mammifère présent dans le système, appeler la fonction déplacer(), quelque soit le traitement effectif
  • 15. Cours semaine 1, jour 1 Cours C++ (2002) 15 Héritage  L’héritage est le mécanisme qui permet de réaliser l’abstraction  Exemple : si la taxonomie précise que « dauphin » est un « mammifère », alors « dauphin » héritera de toutes les caractéristiques et de tous les comportements des « mammifères »  Du plus spécifique au plus général : abstraction  Du plus général au plus spécifique : héritage
  • 16. Cours semaine 1, jour 1 Cours C++ (2002) 16 Encapsulation  Les langages orientés objet permettent de définir des abstractions à partir d’un ensemble d’entités connues  Chaque entité élémentaire a des caractéristiques (données) et des comportements (traitements). Les classes abstraites en possèdent également.  Considérer une entité comme le regroupement de ses données et de ses traitements est une encapsulation  Les langages procéduraux ne permettent pas de réaliser l’encapsulation
  • 17. Cours semaine 1, jour 1 Cours C++ (2002) 17 Généralisons…  Pourquoi utiliser des langages orientés objet plutôt que des langages procéduraux ?  Les langages procéduraux sont, après tout, utilisés depuis bien longtemps et sont parfaitement connus et maîtrisés.  Oui, mais…
  • 18. Cours semaine 1, jour 1 Cours C++ (2002) 18 Échecs des projets informatiques  Échecs des projets informatiques Types de projet Dépassement des coûtsType 1 Type 2 Type 3 En moyenne 16,2 % 52,7 % 31,1 % Gros projets 9 % 61,5 % 29,5 % 178 % Projets moyens 16,2 % 46,7 % 37,1 % 182 % Petits projets 28 % 50,4 % 21,6 % 214 % Type 1 : respectent budget, délais et spécifications Type 2 : dépassent délais et budget, respectent les spécifications Type 3 : abandonnés au cours du cycle de vie
  • 19. Cours semaine 1, jour 1 Cours C++ (2002) 19 Analyse et conception  La réalisation de systèmes et de programmes orientés objets diffère du mode de réalisation suivi par l’analyse fonctionnelle et technique  Vrai pour l’analyse  Vrai pour la conception  Vrai pour l’évolution d’un projet  Généralement, pour les systèmes procéduraux, gestion de projet « à la MERISE »
  • 20. Cours semaine 1, jour 1 Cours C++ (2002) 20 Méthodologies  Waterfall : le plus largement suivi définition analyse design développement tests unitaires tests intégration tests système livraison maintenance
  • 21. Cours semaine 1, jour 1 Cours C++ (2002) 21 Méthodologies (2)  Modèle en V : le waterfall revisité développement tests unitaires design tests intégration analyse tests système définition livraison maintenance
  • 22. Cours semaine 1, jour 1 Cours C++ (2002) 22 Méthodologies (3)  Modèle en spirale : le « waterfall itératif »  Incrémentations successives, les premières pouvant être « purement » formelles  Un des meilleurs modèles :  Marche tout aussi bien pour de petits projets que pour les grands  Permet le prototypage durant toutes les phases : le logiciel n’est pas fini mais fait « comme si »…  Besoin important de management et d’analyse du risque
  • 23. Cours semaine 1, jour 1 Cours C++ (2002) 23 Méthodologies (4) planning analyse de risque ingénierie développement et déploiement évaluation par l’utilisateur discussion avec l’utilisateur Modèle en spirale
  • 24. Cours semaine 1, jour 1 Cours C++ (2002) 24 Méthodologies (5)  Une méthodologie ne suffit pas !  Les méthodologies sont exposées dans les livres,  Elles sont toujours assez abstraites  Elles sont assez peu pratique  Elles sont presque toujours ressenties comme imposées par ceux qui les utilisent  Elles ne tiennent généralement pas compte de la taille du projet (« one size fit all »)
  • 25. Cours semaine 1, jour 1 Cours C++ (2002) 25 Processus  Besoin d’un processus de développement  Ils sont mis en place en fonction de l’existant de l’organisation  Ils donnent des orientations claires et utilisables car ils sont adaptés à la réalité quotidienne d’une entreprise  Ils permettent à chacun d’améliorer sa manière de travailler et d’interagir
  • 26. Cours semaine 1, jour 1 Cours C++ (2002) 26 Processus (2)  CMM, Capability Maturity Model, nous vient du département de la défense américain (comme toujours !)  Il identifie différents niveaux de maturité des processus informatiques dans l’entreprise  Il donne un guide (abstrait) à adapter à une entreprise pour que celle-ci soit capable de grandir (maturing) presque seule
  • 27. Cours semaine 1, jour 1 Cours C++ (2002) 27 Processus (3)  La maturité d’une organisation peut être analysée à travers cinq niveaux différents :  Niveau 1 : initial, peu de processus définis, le succès d’un projet dépend des efforts individuels, « Je fais comme je veux » (76 % des organisations informatiques)  Niveau 2 : répétable, processus de base pour la gestion de projets, « Je gère et je contrôle ce que je fais, mais ect-ce que je le fais correctement » (15 %)
  • 28. Cours semaine 1, jour 1 Cours C++ (2002) 28 Processus (4)  Niveaux (suite) :  Niveau 3 : défini, tous les projets utilisent la même base d’activités qui sont documentées, organisées et standardisées, « J’utilise les meilleures pratiques de mon organisation mais je ne peux pas juger leur qualité » (7 %)  Niveau 4 : géré, gestion quantitative des processus, des métriques sont définies et observées pour les processus et la qualité, « J’utilise les meilleures pratiques de mon organisation et je connais leur qualité » (> 1 %)
  • 29. Cours semaine 1, jour 1 Cours C++ (2002) 29 Processus (5)  Niveaux (suite) :  Niveau 5 : optimisé, amélioration constante des processus grâce à l’analyse des métriques définies, « J’utilise les meilleures pratiques de mon organisation, je connais leur qualité et je les améliore constamment » (< 1 %)
  • 30. Cours semaine 1, jour 1 Cours C++ (2002) 30 Processus (6) Contrôle des processus Niveau 4 Géré Mesure des processus Niveau 4 Défini Définition de processus Niveau 2 Répétable Contrôle de gestion de projet de base Niveau 1 Initial Niveau 5 Optimisé Pas de processus défini Services répétables, mise en place de processus de base Standardisation des services et mise en place de processus de service Contrôle quantitatif des processus de services Contrôle qualitatif des processus de service, amélioration constante des processus
  • 31. Cours semaine 1, jour 1 Cours C++ (2002) 31 Processus (7) optimisé géré défini répétable initial Gestion du changement dans les processus Gestion des changements/évolutions technologiques Prévention des erreurs et disfonctionnements Gestion de la qualité du logiciel Gestion quantitative des processus Gestion des problèmes Coordination inter-groupes Service Delivery Gestion de service intégrée Mise en place d’un programme de formation Définition des processus de l’organisation Respect des processus de l’organisation Définition des services de l’organisation Gestion de configurations Gestion des imprévus Service d’assurance qualité Gestion de la sous-traitance Gestion du suivi Gestion du planning de livraison Gestion des objectifs et besoins
  • 32. Cours semaine 1, jour 1 Cours C++ (2002) 32 Processus (8)  RUP, Rational Unified Process, provient de chez Rational  Il est basé sur l’Objectory Process de Jacobson, modèle assez académique  Il est intéressant et pleins de bonnes idées  Mais beaucoup des outils le supportant sont vendus par … Rational
  • 33. Cours semaine 1, jour 1 Cours C++ (2002) 33 Processus (9)  4 grandes phases :  Étude : établit les besoins  Élaboration : besoins détaillés, analyse et design de haut niveau pour créer une architecture de départ et un planning  Construction : plusieurs itérations pour produire un logiciel testé et répondant aux besoins  Transition : test système et formation des utilisateurs
  • 34. Cours semaine 1, jour 1 Cours C++ (2002) 34 Processus (10) Etude Elaboration Construction Transition Itération Préliminaire Analyse Design Architecture Implémentation Plannification Test / Acceptation Itération #1 Itération #2… Itération #n+1 Itération #… Itération #m Itération #m+1 Itération #m+2 Intégration
  • 35. Cours semaine 1, jour 1 Cours C++ (2002) 35 Analyse et conception (suite)  Avoir une référence méthodologique est une bonne chose  Mettre en place un processus de gestion de projet est encore mieux  Il faut cependant penser à disposer d’un langage permettant d’effectuer une modélisation
  • 36. Cours semaine 1, jour 1 Cours C++ (2002) 36 Modélisation  Besoin d’une Lingua Franca  Faire de la conception orientée objet ou utiliser un langage orienté objet nécessite de faire une analyse du monde de l’application à développer  L’analyse doit être comprise par le client  Il parle de son univers  L’analyse doit être comprise par le développeur  De plus : certains programmes antérieurs et autres librairies doivent éventuellement être intégrés
  • 37. Cours semaine 1, jour 1 Cours C++ (2002) 37 Modélisation (2)  À la différence de Fortran, Basic, Pascal ou encore C, commencer à programmer sans analyse du monde se révèle très  Dangereux  Inefficace  Les langages orientés objet doivent donc être utilisés comme il se doit !  Un objet, et sa définition, se respectent !
  • 38. Cours semaine 1, jour 1 Cours C++ (2002) 38 Modélisation (3)  Différentes méthodes d’analyse orientée objet existent, certaines étant spécialisées comme, par exemple, pour le temps réel  Méthodes générales : OMT, Booch, OOSE  Temps réel : RTMM  Une méthode particulière d’analyse supplante désormais presque toutes les autres :  UML, Unified Modeling Language
  • 39. Cours semaine 1, jour 1 Cours C++ (2002) 39 UML  UML n’est pas une invention ab nihilo  UML est en fait la fusion de plusieurs méthodologies orientées objet dont chacune avait ses forces et ses faiblesses  Au début du cycle de conception de l’UML, de plus en plus de méthodologies ont été analysées et le meilleur en a été gardé  UML peut presque, aujourd’hui, être qualifié de synthèse des modélisations objet
  • 40. Cours semaine 1, jour 1 Cours C++ (2002) 40 UML (2)  UML est un VRAI standard  La conception d’UML a commencé en dehors du monde de la normalisation  L’UML a ensuite été soumis à l’OMG, l’Object Management Group  L’OMG est également responsable, entre autre chose, de CORBA…  UML n’est cependant pas toujours implémenter complètement, certains « oubliant » des types de diagrammes
  • 41. Cours semaine 1, jour 1 Cours C++ (2002) 41 UML (3)  UML n’est pas une langue morte  Au delà du fait qu’elle soit de plus en plus utilisée, cette langue évolue encore  UML participe désormais à une intégration très large au sein de l’OMG  UML en XML : XMI, XML Metadata Interchange  MDA : Model Driven Architecture ; UML/XMI comme base pour la définition d’applications et l’échange de modèles entre entreprises (CORBA, J2EE, .Net, services web)
  • 42. Cours semaine 1, jour 1 Cours C++ (2002) 42 UML : élaboration Méthode Booch Méthode OOSE Méthode OMT Autres méthodes Partenaires UML OMG Unified Method 0.8 - 1995 UML 0.9 - 1996 UML 1.0 – 1996/1997 UML 1.3 – 1999 UML 1.1 – 1997
  • 43. Cours semaine 1, jour 1 Cours C++ (2002) 43 Origines d’UML  Les trois méthodes de base de l’UML sont :  Méthode Booch : Booch  Méthode OMT : Rumbaugh  Méthode OOSE : Jacobson  Booch, Jacobson et Rumbaugh travaillent ensemble chez Rational  Étonnamment, Rational Rose est pour l’heure le produit leader de modélisation UML…
  • 44. Cours semaine 1, jour 1 Cours C++ (2002) 44 Composants d’UML  UML comprend un ensemble de diagrammes assez différents dont chacun a un rôle  Plus ou moins général  Plus ou moins large  Statique ou dynamique  UML peut être vu à travers un diagramme baptisé 4+1  Une vue centrale, quatre vues annexes
  • 45. Cours semaine 1, jour 1 Cours C++ (2002) 45 Composants d’UML (2) Vue processus Vue déploiement Vue composants Vue logique (design) Vue Cas d’utilisation Utilisateur final - Fonctionnalités - Vocabulaire Développeurs - Développement et gestion du logiciel Analystes/Testeurs - Comportement Intégration de système - Performance - Capacité d’extension - Capacité de charge Ingénierie de système - Topologie - Déploiement et installation - Communication
  • 46. Cours semaine 1, jour 1 Cours C++ (2002) 46 Composants d’UML (3) Vue structurelle Vue d’implémentation Vue comportementale Vue environnementale Vue utilisateur Diagramme de classes Diagramme objet Diagramme de cas d’utilisation Diagramme de composants Diagramme d’activité Diagramme de séquence Diagramme de collaboration Diagramme d’états-transitions Diagramme de déploiement
  • 47. Cours semaine 1, jour 1 Cours C++ (2002) 47 UML : Use Case  Les Use Case (cas d’utilisation) permettent de faire l’étude préalable des fonctionnalités recherchées par dialogue avec l’utilisateur  Les Use Case diagrams sont un support à la modélisation et à la discussion  L’information est surtout informelle  Scénarios (documents texte d’explication), copies d’écran, etc  Statique et dynamique
  • 48. Cours semaine 1, jour 1 Cours C++ (2002) 48 UML : Use Case (2) internaute navigue se connecte paie son abonnement « utilise »
  • 49. Cours semaine 1, jour 1 Cours C++ (2002) 49 UML : Class Diagram  Les diagrammes de classes permettent de définir la taxonomie (classification) des différents objets nécessaires au bon fonctionnement du système  Les diagrammes de classes sont statiques  Les diagrammes de classes permettent de faire la distinction entre l’appartenance à un groupe et la composition d’un objet
  • 50. Cours semaine 1, jour 1 Cours C++ (2002) 50 UML : Class Diagram, aparte  Avant toute modélisation objet, il faut clairement faire la distinction entre « est un » (is-a) et « a un » (has-a)  Un cheval est un mammifère, un homme est un mammifère  Un homme a des jambes  Une fourmi a des pattes  Ces deux mécanismes sont à la base de la définition des classes
  • 51. Cours semaine 1, jour 1 Cours C++ (2002) 51 UML : Class Diagram (2) VêtementCheval Homme Animal MammifèreInsecte Jambe Famille 1 2,4 1 1..* 1 1..*
  • 52. Cours semaine 1, jour 1 Cours C++ (2002) 52 UML : Class Diagram (3)  Dans un diagramme de classe, on marque le lien is-a par l’héritage  Le lien has-a est beaucoup plus raffiné, il est possible de noter :  Une association  Une aggrégation  Une composition  Il est également possible de marquer des cardinalité et des sens de navigation
  • 53. Cours semaine 1, jour 1 Cours C++ (2002) 53 UML : Class Diagram (4) TripTarif Enumeration getZones() Price getPrice( Zone ) price zone TripLeg * * Association : deux objets sont liés mais de manière relativement indépendante. La relation est très relâchée.
  • 54. Cours semaine 1, jour 1 Cours C++ (2002) 54 UML : Class Diagram (5) 1 ExhaustSystem Muffler Tailpipe 0..2 Aggrégation : plus forte que l’association, elle marque un lien de composition fort. Les constituant peuvent exister sans l’aggrégat mais cela n’a alors plus beaucoup d’intérêt.
  • 55. Cours semaine 1, jour 1 Cours C++ (2002) 55 UML : Class Diagram (6) 3 DistributeurDeTickets SélecteurDestination Composition : il s’agit du lien le plus fort : les constituants ne peuvent pas exister sans l’aggrégat. Note : le choix entre une aggrégation et une composition dépend généralement de l’univers dans lequel se fait la modélisation
  • 56. Cours semaine 1, jour 1 Cours C++ (2002) 56 UML : Class Diagram (7)  Lors de la définition d’un héritage entre classes, il faut toujours commencer par le plus général pour descendre vers le plus particulier  Autrement dit : ne pas faire de hiérarchies inversées  La racine d’un arbre doit être un objet très général  C’est grâce à cela que l’on peut réutiliser
  • 57. Cours semaine 1, jour 1 Cours C++ (2002) 57 UML : Class Diagram (8) Directeur Manager Employé Employé Manager Directeur Note : un diagramme de classes n’est pas un organigramme de fonctions !
  • 58. Cours semaine 1, jour 1 Cours C++ (2002) 58 UML : Class Diagram (9)  Des classes peuvent être regroupées en package (paquetage)  Un package est un groupe de classes dont le rôle est similaire ou qui possèdent la même appartenance  Package des mammifères  Package de connexion réseau  Un package permet d’obtenir un niveau d’abstraction (il cache la foule…)
  • 59. Cours semaine 1, jour 1 Cours C++ (2002) 59 UML : Class Diagram (10) Collaborations Statechart Activity Éléments dynamiques Gestion du modèle Foundation Use Cases Common Behavior
  • 60. Cours semaine 1, jour 1 Cours C++ (2002) 60 UML : Exercice #1  Créer un diagramme de classes dans le domaine des transports en commun  Définnissez une arborescence des moyens de transport  Définissez les constituants et l’environnement de ces moyens de transport  N’utilisez pas les packages…
  • 61. Cours semaine 1, jour 1 Cours C++ (2002) 61 UML : Exercice #2  Système d’enregistrement d’une conférence  Créez la hiérarchie incorporant :  Les organisateurs  Les orateurs invités  Les orateurs principaux  Les orateurs annexes  Les participants inscrits industriels  Les participants inscrits académiques (profs)  Les participants inscrits étudiants
  • 62. Cours semaine 1, jour 1 Cours C++ (2002) 62 UML : Exercice #2 (2)  Que se passe-t-il si  Un organisateur est orateur annexe  Un étudiant est orateur principal  Un orateur principal décide de ne pas présenter ses travaux mais assiste tout de même en tant que participant inscrit académique
  • 63. Cours semaine 1, jour 1 Cours C++ (2002) 63 UML : Exercice #2 (3)  Conclusions :  Un héritage simple est parfois insuffisant mais  L’héritage multiple apporte beaucoup de complication et d’illisibilité  L’introduction / la création d’associations peut être bénéfique  Mais certaines conditions devront alors être respectées
  • 64. Cours semaine 1, jour 1 Cours C++ (2002) 64 UML : Object Diagram  Les diagrammes d’objets montrent les instances et les liens entre objets  À la différence du diagramme de classes, le diagramme d’objets est dynamique  Il illustre des situations  Il permet de présenter les structures des objets et des données  Il est en fait “presque” dynamique
  • 65. Cours semaine 1, jour 1 Cours C++ (2002) 65 UML : Object Diagram (2) c : Compagnie d1 : Département nom = "ventes" p : Personne nom = "Dupont" id = 2718 emploi ="vendeur" d2 : Département nom = " R&D" : Adresse addresse = "rue"
  • 66. Cours semaine 1, jour 1 Cours C++ (2002) 66 UML : Component diagram  Les diagrammes de composants permettent de représenter la structure physique de l’implémentation  Organisation du code source  Compilation d’exécutables  Bases de données physiques  Ils sont proches des choix techniques  Ils sont statiques
  • 67. Cours semaine 1, jour 1 Cours C++ (2002) 67 UML : Component diagram (2) index.html find.html nateng.dll find.exe dbacs.exe
  • 68. Cours semaine 1, jour 1 Cours C++ (2002) 68 UML : Activity diagram  Les diagrammes d’activité permette d’obtenir une vision orientée métier d’un processus  Montre l’enchaînement des actions, les synchronisations, les responsabilités des acteurs  Note : ils ont de plus en plus de succès pour les modélisations dans les logiciels de workflow
  • 69. Cours semaine 1, jour 1 Cours C++ (2002) 69 UML : Activity diagram (2) Donner # remboursement Client Ventes StocksComptabilité Renvoyer article Informer du renvoi Réception article Stockage article Rembourser article Article [renvoyé] Article [disponible]
  • 70. Cours semaine 1, jour 1 Cours C++ (2002) 70 UML : Sequence diagram  Les diagrammes de séquence permettent de raffiner les Use Case diagrams en :  Permettant d’identifier les objets participants  Permettant de trouver des objets manquants  Permettant de marquer les enchaînements  Ils marquent également des durées d’exécution  Ils sont dynamiques
  • 71. Cours semaine 1, jour 1 Cours C++ (2002) 71 UML : Sequence diagram (2) sélectionBoisson() récupérationMonnaie() récupérationBoisson() introductionArgent() Client Distributeur de boissons
  • 72. Cours semaine 1, jour 1 Cours C++ (2002) 72 UML : Collaboration diagram  Les diagrammes de collaborations permettent de représenter les interactions entre classes  Ils présentent les flux de contrôle  Ils illustrent la coordination entre les objets de structure et les objets de contrôle  Ils sont dynamiques (orientés messages)
  • 73. Cours semaine 1, jour 1 Cours C++ (2002) 73 UML : Collaboration diagram (2) p : ODBCProxy 1 : crée 2 : prépareAction( a, d, o ) 3 : détruit c : Client d2 : Département 2.1 : affecte( d, 3.14 ) 2.2 : affecte( a, "CO" )
  • 74. Cours semaine 1, jour 1 Cours C++ (2002) 74 UML : Statechart diagram  Les diagrammes d’état-transition correspondent à une version allégée des diagrammes d’activité  Plus de responsabilités, de synchronisation  Ils pourraient typiquement être utilisé en automatique pour modéliser le comportement d’un automate  Ils sont dynamiques (orientés évènements)
  • 75. Cours semaine 1, jour 1 Cours C++ (2002) 75 UML : Statechart diagram (2) Heures clignotent Secondes clignotent Minutes clignotent touche 2 touches 1 & 2 touche 2 touche 2 touche 1 touche 1 touches 1 & 2 touches 1 & 2 Incrément heures Incrément secondes Incrément minutes Arrêt clignotement
  • 76. Cours semaine 1, jour 1 Cours C++ (2002) 76 UML : Deployment diagram  Les diagrammes de déploiement permettent de capturer la topologie du système sur laquelle est déployée l’application  Permet de définir  La distribution des composants  De pré-identifier les éventuels goulots d’étranglement
  • 77. Cours semaine 1, jour 1 Cours C++ (2002) 77 UML : Deployment diagram (2) réseau serveur serveur serveur serveur primaire serveur données imprimante
  • 78. Cours semaine 1, jour 1 Cours C++ (2002) 78 UML de base et extensions  Comme nous l’avons vu, UML comporte 9 types de diagrammes différents  Ces diagrammes ont TOUS leur utilité  Certains peuvent cependant être inutiles dans un projet  UML comporte également un ensemble de fonctionnalités supplémentaires dans la notation  Stéréotypes de classe : permettent de montrer l’appartenance à un modèle « technique »  Profils : extensions pour la persistance, le temps-réel, etc.
  • 79. Cours semaine 1, jour 1 Cours C++ (2002) 79 Points forts d’UML  Du fait de sa standardisation par l’OMG, la méthode est supportée par de nombreux outils. Grâce à cela, une course aux fonctionnalités s’est instaurée  Prise en compte des bases de données existantes  Génération automatique de squelettes de code  Possibilité d’importer ou d’exporter dans un vocabulaire XML
  • 80. Cours semaine 1, jour 1 Cours C++ (2002) 80 Un outil UML : Rational Rose
  • 81. Cours semaine 1, jour 1 Cours C++ (2002) 81 Un outil UML: Rational Rose (2)
  • 82. Cours semaine 1, jour 1 Cours C++ (2002) 82 Un outil UML: Rational Rose (3)
  • 83. Cours semaine 1, jour 1 Cours C++ (2002) 83 Un outil UML: Rational Rose (4)
  • 84. Cours semaine 1, jour 1 Cours C++ (2002) 84 Un outil UML: Rational Rose (5)
  • 85. Cours semaine 1, jour 1 Cours C++ (2002) 85 Un outil UML: Rational Rose (6)
  • 86. Cours semaine 1, jour 1 Cours C++ (2002) 86 Un outil UML: Rational Rose (7)
  • 87. Cours semaine 1, jour 1 Cours C++ (2002) 87 Lourdeurs  Les normes de modélisation, les processus de gestion de projet, l’amélioration des habitudes de travail par l’intermédiaire de référentiels tels que CMM ou d’autres  Tout ceci a un prix et demande du temps  Tout ceci est lourd et difficile  Tout ceci nécessite l’adhésion de tous  Une fois en place, de telles méthodes se révèlent gagnantes mais :
  • 88. Cours semaine 1, jour 1 Cours C++ (2002) 88 Lourdeurs (2)  Tout ceci en vaut-il toujours « la chandelle » ?  Une petite structure de développement ou une petite société peut-elle s’autoriser de mettre en place de telles procédures, administrativement lourde ?  Certains ont eu une réaction négative et ont eu une volonté d’allègement des processus
  • 89. Cours semaine 1, jour 1 Cours C++ (2002) 89 eXtreme Programming  XP (nom choisi avant que Microsoft ne lui accorde une autre signification…) est une méthodologie de développement objet allégée d’un point de vue administratif  D’un point de vue CMM, il s’agit d’un niveau 1 très amélioré  « À la mode » car prône pour une gestion très réactive des projets, et des problèmes…
  • 90. Cours semaine 1, jour 1 Cours C++ (2002) 90 eXtreme Programming (2)  Il faut considérer XP comme une organisation de gestion de projet applicable:  Aux petites équipes  Aux équipes effectuant un travail assez autarcique et ayant donc relativement peu d’interconnections avec des équipes extérieures  Aux équipes dont les travaux seront peu réutilisés par l’extérieur et où différents niveaux de documentation ne sont pas nécessaires
  • 91. Cours semaine 1, jour 1 Cours C++ (2002) 91 eXtreme Programming (3)  Quatre valeurs mises en exergue :  Communication  Travail en groupe (2 programmeurs pour 1 poste)  Simplicité  Toujours faire au plus simple  Temps de réponse  Chacun doit répondre rapidement aux questions  Courage  Pour se remettre en question après les choix
  • 92. Cours semaine 1, jour 1 Cours C++ (2002) 92 eXtreme Programming (4)  Principes de base :  Faible temps de réponse de la part des développeurs eux-même ET des clients  Aller au plus simple (rasoir d’Occam)  Changements incrémentaux comme dans la méthode itérative  Acceptation du changement  Travail de qualité
  • 93. Cours semaine 1, jour 1 Cours C++ (2002) 93 eXtreme Programming (5)  Activités de base :  Codage, pour la communication et l’apprentissage  Tests, automatisés, unitaires et système, « tout ce qui ne peut pas être mesuré n’existe pas » (…)  Écoute, des autres développeurs, des clients  Design, tant du système à développer que de l’équipe qui le développe
  • 94. Cours semaine 1, jour 1 Cours C++ (2002) 94 Pratiques XP  Planning  Le client définit les besoins, la date de livraison  Les techniciens en présentent les conséquences pour les coûts et le planning détaillé  Il s’agit bien des techniciens, pas des commerciaux !  Petites releases fréquentes  Une métaphore générale par projet  Une idée ou un comcept central par projet
  • 95. Cours semaine 1, jour 1 Cours C++ (2002) 95 Pratiques XP (2)  Design simple  Pas de réplication de la logique métier  Le moins possible de classes et de méthodes  Incorpore toutes les idées des développeurs  Passe tous les tests  Tests  Procédures de test automatisé pour TOUTES les fonctionnalités du système
  • 96. Cours semaine 1, jour 1 Cours C++ (2002) 96 Pratiques XP (3)  Réécriture  Est-il possible de réécrire un programme existant pour rendre l’ajout de nouvelles fonctionnalités plus simple ?  Après un ajout d’une fonctionnalité, peut-on rendre le programme plus simple  Programmation à deux  2 personnes, 1 écran, 1 clavier, 1 souris  1 pour une vue globale, 1 pour ici et maintenant
  • 97. Cours semaine 1, jour 1 Cours C++ (2002) 97 Pratiques XP (4)  Propriété collective  Si un développeur trouve intéressant d’ajouter une fonctionnalité dans un programme de quelqu’un d’autre, il DOIT le faire  Tout le monde peut simplifier les programmes de tout le monde  Intégration continue  Le système est testé tous les jours, pas toutes les semaines ou tous les mois
  • 98. Cours semaine 1, jour 1 Cours C++ (2002) 98 Pratiques XP (5)  Semaine de 40 heures  Les heures supplémentaires sont un symptôme de problèmes graves  Présence du client  Un utilisateur final est intégré à l’équipe  Respect de standards de codage  Pas de code dupliqué  Faire comme il faut ou ne pas faire du tout  Développeur non identifiable par le code
  • 99. Cours semaine 1, jour 1 Cours C++ (2002) 99 Quelques défaut d’XP  Les extrêmes auquels il ne faut pas aboutir :  La conception est dans le code  Ce genre de principe est naturel pour un logiciel développé « à la maison »  Les bidouilles et les GOTO à la Fortran/Basic sont une des pires choses qui soient : les laisser aux compilateurs et autres optimiseurs !  La documentation est orale  Personne n’est irremplaçable et  Personne n’est éternel…
  • 100. Cours semaine 1, jour 1 Cours C++ (2002) 100 XP, et après ?  L’eXtreme Programming prend le contre- pied des méthodes plus lourdes comme CMM, RUP (également ITIL, SPICE, Objectory, etc)  Un des accents est mis sur le besoin constant de tests par l’intermédiaire de petits programmes automatisés (framework)  Tests unitaires, système, d’intégration
  • 101. Cours semaine 1, jour 1 Cours C++ (2002) 101 XP, et après ? (2)  Cependant, les méthodologies plus lourdes continuent à progresser tandis que la recherche en génie logiciel essaie de résoudre certains problèmes  Question 1 : peut-on pousser plus avant les capacités de génération de code ?  Question 2 : peut-on prouver, au moins partiellement, la correction d’un programme donné ?
  • 102. Cours semaine 1, jour 1 Cours C++ (2002) 102 Conditions  Les réponses sont affirmatives !  Technique importante : les pré-conditions et les post-conditions  Elles ont pour la première fois été introduites dans le langage orienté objet Eiffel de Meyer  Il existait déjà des choses en C  Elles peuvent se retrouver aujourd’hui, à des degrés moindres, dans C++ ou Java  Et surtout : elles peuvent être définies à l’étape de modélisation d’un système
  • 103. Cours semaine 1, jour 1 Cours C++ (2002) 103 Conditions (2)  En complément du langage Eiffel, Meyer a mis au point une technique formelle de conception orientée objet  Design By Contract  « Si tu promets d’appeler la méthode m en respectant la pré-condition alors, en retour, la méthode m promet de respecter la post-condition »  La généralisation des contrats permet de définir la responsabilité de chacun
  • 104. Cours semaine 1, jour 1 Cours C++ (2002) 104 Méthodes formelles  Introduite lors des phases de modélisation, de telles techniques sont qualifiées de formelles  Une méthode formelle permet de définir au niveau de l’appel d’une fonction :  Les pré-conditions qui donnent les conditions internes nécessaires au bon déroulement  Les post-conditions qui permettent de contrôler l’état des lieux après exécution
  • 105. Cours semaine 1, jour 1 Cours C++ (2002) 105 Méthodes formelles (2)  En complément des pré et post-conditions, il est possible de définir l’algorithme de la fonction de manière abstraite  L’algorithmique définit ici est assez abstraite et assez proche des mathématiques  Cependant, il s’agit parfois presque de langages de programmation !  Il existe plusieurs méthodes. Nous en présentons brièvement 2 : OCL et B
  • 106. Cours semaine 1, jour 1 Cours C++ (2002) 106 OCL  OCL signifie Object Constraint Language  OCL permet de définir des :  Des pré-conditions  Des post-conditions  Des algorithmes au niveau de chaque méthode de chaque objet  Encore une fois, cela ressemble parfois à un langage de programmation mais
  • 107. Cours semaine 1, jour 1 Cours C++ (2002) 107 OCL (2)  OCL n’est pas un langage de programmation (même s’il commence à exister des compilateurs OCL…)  Les contraintes OCL peuvent être analysées automatiquement  La totalité d’un système peut être modélisé  Et enfin  OCL fait partie de UML !
  • 108. Cours semaine 1, jour 1 Cours C++ (2002) 108 OCL : Exemple <JobCategory> <Facility> reqs <Job> when: TimeInterval <Resource> 0..* type allocated provides 0..* 0..1 inv Job::allocated<>0 ==> allocated.provides->includesAll(type.reqs) --Any allocated resource must have the required facilities inv Resource::jo1, jo2: Job:: (schedule->includesAll({jo1,jo2}) ==> jo1.when.noOverlap(jo2.when) -- no double-booking of resources schedule 0..*
  • 109. Cours semaine 1, jour 1 Cours C++ (2002) 109 Méthodes formelles, conclusion  Science-fiction ?  Les logiciels des deux lignes de métro dernièrement créés à Paris ont été conçus grâce à la méthode B  La RATP ne jure désormais plus que par B ! Ils n’avaient jamais réussi à obtenir des logiciels de ce niveau de qualité avant  Tous les logiciels sensibles (avec des vies humaines en jeu) seront très probablement conçus avec de telles méthodes dans un avenir proche
  • 110. Cours semaine 1, jour 1 Cours C++ (2002) 110 Méthodes formelles, conclusion (2)  Les méthodes formelles vont au delà des simples notions des langages orientés objet. Cependant :  Elles sont par exemple INTÉGRÉES dans UML (versions 1.1 et maintenant 1.3)  De plus en plus de langages orientés objet intègre des capacités d’assertion qui permettent, grosso modo, de faire des vérifications de qualité du code sans passer par un débogueur
  • 111. Cours semaine 1, jour 1 Cours C++ (2002) 111 Questions / Remarques