ingénierie du développement logiciellab-sticc.univ-brest.fr/~babau/cours/idl_intro.pdf ·...
TRANSCRIPT
23/02/2016
1
Jean-Philippe Babau
Département Informatique, UFR Sciences, UBOLaboratoire Lab-STICC
Ingénierie du Développement Logiciel
dirigée par les modèles
lab-sticc.univ-brest.fr/~babau/
UBO
• Introduction à l’ingénierie pour le développement logiciel
• Organisation du cours
• Introduction à la modélisation UML
• Introduction au MDE (M2 TIIL et M2 SIAM)
Plan du cours
2
23/02/2016
2
UBO Construire un pont
3
1
Pont Sublicius, Rome, 650 avant JC
2
le Ponte dei Salti (Lavertezzo, Suisse)
3
Viaduc de MillauMike Lehmann, Mike Switzerland March 2008
4
UBO Des outils pour la construction et pour l’organisation de la construction
4
1
4
3
2
23/02/2016
3
UBO Construire une maison : documents et suivi
5
• Un projet : une idée de maison
• Des normes et règlements– Déclarations obligatoires– Documents de conformité
• Des plans– Contrat de construction de maison individuelle « avec fourniture de plans »– Schéma électrique, eau, chauffage, aération– Plan cadastral
• Des études techniques– Résistance des matériaux– Capacité d’isolation
• Des documents spécifiques– Contrats, actes, déclarations, plans, …– Pour le notaire, l’état, le paysagiste, les techniciens, les constructeurs, les vendeurs
• Gestion du chantier– Planning, revues à base des contrats et des plans
UBO
Construire un avion : des modèles spécifiques
6
• Aérodynamique– Modèles physiques de l’écoulement– Modèles physiques de la structure
• Motorisation– Modèles de combustion– Modèles thermiques
• Systèmes de pilotage et de navigation– Normes de sécurité– Normes de communication
• Informatique– Embarquée et débarquée (suivi) : sous-partie du système
• Communications embarqué / débarqué – Aide à la conception : outils de manipulation des modèles physiques– SI des entreprises : outils de suivi des projets et des personnes
• Intervenants hétérogènes– Métiers– Cultures et langues
Quels modèles ?
23/02/2016
4
UBO Construire un système
7
• Des systèmes de plus en plus complexes … à produire de plus en plus vite– des systèmes personnalisables
• Des outils de conception et modélisation de plus en plus complexes• Des schémas hétérogènes et spécifiques
– pour évaluer, étudier• Des acteurs divers et différents aux points de vue divers et différents
• Faire les bons choix au bon moment
• Maitriser la gestion de projet• Automatisation des étapes et des processus
• Des documents pour contractualiser et communiquer• Des outils pour le suivi
– couts, délais, interaction avec les divers partenaires
UBO Construire un logiciel
8
• Des systèmes de plus en plus complexe … à produire de plus en plus vite– des systèmes personnalisables
• Des outils de conception et modélisation de plus en plus complexes• Des schémas hétérogènes et spécifiques
– pour évaluer, étudier• Des acteurs divers et différents aux points de vue divers et différents
• Faire les bons choix au bon moment• Intégrer une vision Métier et une vision Informatique
• Maitriser la gestion de projet informatique– Processus spécifiques
• Automatisation des étapes et des processus
• Des documents pour contractualiser et communiquer• Des outils pour le suivi
– couts, délais, interaction avec les divers partenaires
23/02/2016
5
UBO Maitrise du développement
9
• En 2004, le Standish Group a évalué à 34% lapart des projets qui aboutissent dans lesconditions prévues, soit 18% de plus qu’il y a 10ans.
• 15% sont arrêtés avant la fin, soit 16% de moins qu’il y a 10 ans.
• 51% sont en retard ou ont un coût supérieur au budget, soit 2% de moins qu’il y a 10 ans.
UBO
• Répartition des activités– Analyse et conception 45%– Réalisation et tests unitaires : 35%
• Codage 15 à 20% du total – Intégration et validation : 25%
• Dérives dans les estimations– Étude préalable : de 10 à 25 %– Conception : de 10% à 35 %– Réalisation : de 30% à 40%– Mise en œuvre : de 5% à 20%
Quantification des activités
10
23/02/2016
6
UBO Les points clés de la construction de logiciel
11
• Intégrer les besoins des utilisateurs
– Relation client / fournisseur
– Considérer l’ensemble des exigences de nature hétérogène• prix• délais• fonctionnalités• performance• sécurité• formation• déploiement• maintenance
– Valider les solutions vis-à-vis des attentes du client
UBO Les points clés de la construction de logiciel
12
• Choisir (ou développer) les bons outils– Pour le développement– Pour le déploiement
• Evaluer les solutions– Etude de l’existant– Solutions faisables
• Cout, complexité, disponibilité, …– Choix justifiées sur des critères objectifs– Proposer des solutions de bonne qualité
• En augmentant la réutilisation• En s’appuyant sur des règles métier• En suivant un processus maitrisé et reproductible (normes qualité)
• Maitriser le déroulement du projet– Développement– Déploiement– Maintenance corrective et évolutive
23/02/2016
7
UBO
• Maitriser le processus de développement– Étude, conception, développement, livraison et suivi
• Maitriser le lien Informatique et Métier– Echanger des informations dans les deux sens– Intégrer les concepts et les approches spécifiques métier au logiciel– Expliquer l’impact du traitement automatique de l’information au métier
• Changement d’outil => impact fort sur le système et son utilisation• Exemple : intégration d’un simulateur de conduite
– Impact sur l’apprentissage– Impact sur les constructeurs (tests en situation limite)
• Maitriser la communication technique– On ne communique pas avec un code …
Les défis
13
UBO Le développement d’un logiciel concerne
14
• Le client du produit développé
• Les utilisateurs
• Les administratifs– Coté client– Coté fournisseur
• Les administrateurs– Coté client– Coté fournisseur
• Les instituts de normalisation
• Le chef de projet• Les développeurs
– Les architectes– Les codeurs– Les testeurs– Les intégrateurs
• Les fournisseurs d’outils et de matériel
• Les vendeurs
• Les formateurs
informaticiens
23/02/2016
8
UBO
Construire un logiciel=> intégration de divers aspects
15
UBO
• Cycle de développement– Préoccupations du développeur– Préoccupations de la maintenance– Préoccupations de la gestion de projet
Diverses préoccupations
16
23/02/2016
9
UBO
• Les fonctionnalités– Données et services
• Le comportement– Comportement réactif– Sureté et vivacité
• La communication– Protocoles
• Les machines d’exécution– Machines et réseaux– OS– Middlewares
• Les aspects non fonctionnels– Temps réel– Sécurité– Ressources (consommation, …)
Quelques aspects liés au développement
17
UBO
• La structure– Modules– Paquetage – Composants– Déploiement
• La correction des programmes– Tests– Preuves (sémantique formelle)
• Le développement– Outils d’édition, de génération, de mise au point
• La méthodologie– Cycle de vie– Guide de style– Design pattern– Suivi de versions
Quelques aspects liés au développement
18
23/02/2016
10
UBO
• Analyser un problème complexe– Décomposition du problème en sous-problèmes
• Analyse architecturale• Décomposition fonctionnelle (SA-RT) et décomposition objet (UML)
– Modularité et abstraction
– « Separation of concern »• Dijskstra, " On the role of scientific thought" 1974• Reade, " Elements of Functional Programming “, 1989
– « Composition of concern »• Assembler des briques de base• Fusionner des aspects
Limites de la compréhension humaine =>séparation des préoccupations
19
UBO
• Une activité qui produit– des informations (modèles)
• Pas de document produit : pas d’activité
• Modèles distincts mais reliés– Traçabilité des concepts
Un point de préoccupation
20
23/02/2016
11
UBO Des informations pour des activités
21
• Décrire les exigences– Fonctionnalités attendues– Modèle du domaine– Intégration et déploiement du SI
• Accompagner Le développement– Analyser la structure (architecture)– Décrire le comportement– Choix des outils– Méthodes de développement
• Assurer le suivi– Formation des utilisateurs et des installateurs– Gestion d’erreurs (maintenance corrective) – Évolutions (maintenance évolutive)– Suivi de versions
UBO
• Lao Tseu– "Trop de précision tue"
• Nombre maximal de « token » dans un schéma– De 3 à 7 au maximum, mais plutôt 3 à 4– Limité par les capacités de compréhension du lecteur
• Toujours inférieur aux capacités du producteur des modèles concernés• Le producteur connait son modèle, le lecteur le découvre
• Des modèles simples– Attention : il faut savoir faire « simple mais pas simpliste »
Limites de la compréhension humaine =>abstraction
22
23/02/2016
12
UBO Modélisation pour appréhender la complexité
23
“Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose;”
“a model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality”
Jeff Rothenberg « The Nature of Modeling » ,1989
UBO
« la recherche d’une théorie nouvelle implique un niveau d’abstraction plus élevé . … La généralisation scientifique nous conduit à une plus grande intégration de la connaissance. …. Nous établissons un modèle, ou une succession de modèles reproduisant, sous une forme ou sous une autre, certains aspects de la situation présente. … Lord Kelvin disait qu’il lui était impossible de comprendre un phénomène s’il n’avait auparavant construit un simple modèle mécanique lereprésentant. … Le premier et principal intérêt du modèle est d’aider à expliqueren partie une théorie plus avancée dans les termes d’une théorie connue»
E.-H Hutten, Les concepts de la physique, Paris, Dunod 1969, trad. F. Eldin, pp 74 -75, 77-78
Introduction sur la notion de modèles
24
23/02/2016
13
UBO
• Accroitre le niveau d’abstraction pour le concepteur– Assembleur -> langage de programmation– Langage de programmation -> modèles
• Abstraction d’un aspect du développement– Organisation du code– Sécurité– Supports d’exécution– Suivi de version– …
• Un modèle est une représentation d’un aspect (c’est une abstraction)– Une vue de quelque chose
Modèles et abstraction
25
UBO
– Communiquer– Documenter
• Rapports, contrats– Expliquer
• Présentations • Groupes de travail
– Réfléchir• Schémas, dessins, graphiques
– Evaluer des propriétés• Point de vue sur le système vis-à-vis d’une problématique donnée
Des modèles pour …
26
23/02/2016
14
UBO
• Gérer la difficulté de communiquer
– Être précis• Termes connus et définis• Concision dans l’expression• Faire relire
– Être clair• Pas trop simple (simpliste), pas trop compliqué• Faire relire
– Être exhaustif• Faire valider
Communiquer
27
UBO Représentations
28
• Textuel – Langage naturel : tout le monde– Langages de programmation : les programmeurs– XML : les machines
• Graphique – Généralement lié à une représentation textuelle : les spécialistes du domaine
• Semi- graphique : certaines parties sont textuelles
• Mathématique – Basé sur des théories mathématiques : les mathématiciens
23/02/2016
15
UBO Formalisation
29
• Modèle informel– Il existe des interprétations différentes d’un même modèle– Langage naturel
• Modèle formel– Il n’existe qu’une interprétation unique pour un modèle donné– Grammaire bien formée– Sémantique sous-jacente– Traitement automatique possible (résultat prévisible a priori)
• Modèle semi-formel– Certaines parties sont formellement décrites et d’autres non
UBO Bilan
30
• Nombreuses activités• Spécification, documentation, architecture, gestion de projet
• Nombreux intervenants• Points de vue différents, spécialités différentes
• Nombreux documents• Pour les informaticiens et les non informaticiens
• Qualité de la communication• On ne communique pas avec un code
• Abstraction et séparation des préoccupations• Travail en équipe
• Organisation et suivi
• Manipuler des modèles (documents) et avoir de la méthode– Production et communication autour des modèles– Organisation des activités
• QQOQCCP : Qui fait Quoi Quand, Où Comment Combien et Pourquoi• Intégration des modèles
23/02/2016
16
UBO
• Introduction à l’ingénierie pour le développement logiciel
• Organisation du cours
• Introduction à la modélisation UML
• Introduction au MDE (M2 TIIL et M2 SIAM)
Plan du cours
31
UBO
• Maitriser les concepts de base de l'ingénierie logicielle
• Savoir décrire des exigences
• Savoir modéliser à l'aide de diagrammes UML les diverses productions des étapes du développement
• Connaitre et utiliser les outils support du développement logiciel
• Savoir établir un plan de tests
Objectifs de l’UE
32
23/02/2016
17
UBO
BABAU [email protected]
PAULY [email protected]
LALLALI [email protected]
Intervenants
33
NEDELEC [email protected]
UBO
• cours / TD / TP ( 48h )– Éléments de base pour le CC et le projet qui suit l’UE
• CC : un projet fil rouge
• 1 examen écrit ( 2/3 de la note )• 1 contrôle continu (1/3 de la note )
• Planning prévisionnel– Cours répartis sur 8 semaines du 08/01 au 28/02– Examen écrit prévu le 25/03
Evaluation
34
23/02/2016
18
UBO
• Contexte– Production industrielle de logiciels
• Phase 1 : introduction aux concepts de base en ingénierie logicielle (O Nedelec)– Cycle de vie du logiciel– Activités d'analyse– Formalisation d'exigences– Organisation– Qualité
Plan du cours
35
UBO
• Phase 2 : outils de gestion de projet de développement logiciel (Y. Pauly)
• Gestion de configuration
• Intégration continue (qualité de code, automatisation du processus, suivi de bugs,…)
• Mise en place et utilisation des outils
Plan du cours
36
23/02/2016
19
UBO
• Phase 3 : analyse et conception (JP Babau)
• Modélisation des processus, des données, des traitements– UML
• Organisation du code– Architecture logicielle– Les Design patterns
Plan du cours
37
UBO
• Phase 4 : test logiciel (M.Lallali)
• Notions de base sur le test
• Test objet
• Test basés sur les modèles
• Introduction à la preuve
Plan du cours
38
23/02/2016
20
UBO
• Phase 5 : le projet (JP Babau, J Rivière, Y Pauly)– Client, utilisateurs, fournisseur, experts (revue de pairs)
• Projet par équipe (6 personnes)
• Une semaine pour répondre au besoin
• Gestion de projet– Suivi des tâches– Deux jalons– Gestion des documents– Démos
Plan du cours
39
UBO
• Introduction à l’ingénierie pour le développement logiciel
• Organisation du cours
• Introduction à la modélisation UML
Plan du cours
40
23/02/2016
21
UBO OMG
L’ensemble des acteurs du monde informatique a fondé en 1989 l'OMG (Object Management Group), une organisation à but non lucratif, dont le but est de mettre au point des standards garantissant la compatibilité entre des applications programmées à l'aide de langages objet et fonctionnant sur des réseaux hétérogènes (de différents types)
• http://www.omg.org/
• des standards de l’OMG– Modélisation
• SysML : modélisation système• UML: modélisation logicielle• SPEM : modélisation de processus• OCL : modélisation de contraintes
– MOF• méta-modélisation
– Interopérabilité et communications• CORBA, CCM : modèles d’interopérabilité• DDS : modèles d’échange de données pour systèmes embarqués temps- réel• Échanges de données• XML et XMI : format d’échange de données (texte)• CWM
41
UBO Membres de l’OMG
• Contributeurs – Microsoft, HP, IBM, Oracle, Thalès, Eclipse Fundation, …
• Utilisateurs– EADS, Boeing, Adobe, France Telecom R&D, …
• Editeurs – NEC, Nokia, Tri-Pacific Software, Hitachi, …
• Universitaires– INRIA, ENSIETA, …
42
23/02/2016
22
UBO UML : la genèse
43
• Modélisation de logiciel
• Paradigme fonctionnel– SADT, SA, SA-RT– Pas d’encapsulation des données– Structuration hiérarchique des actions, mais pas des concepts– Modélisation orientée par le problème et non par le domaine
• Moins de réutilisation
• Paradigme objet– Encapsulation des données– Modularité via les objets et structuration des concepts via les classes– Modélisation orientée par le domaine
UBO Modèles objet
• en 1994 il existait plus de 50 méthodes objet, dont 3 principales– des méthodes graphiques– la méthode OMT de Rumbaugh– la méthode BOOCH'93 de Booch– la méthode OOSE de Jacobson (Object Oriented Software Engineering)
• 1994, Rumbaugh et Booch (rejoints en 1995 par Jacobson) mettent au point la méthode unifiée (unified method 0.8), incorporant les avantages de chacunes des méthodes précédentes
• La méthode unifiée à partir de la version 1.0 devient UML (Unified Modeling Language), une notation universelle pour la modélisation objet
• http://www.smartdraw.com/resources/tutorials/
44
23/02/2016
23
UBO UML et l’OMG
• UML 1.0 est soumise à l'OMG (Object Management Group) en janvier 1997, et est acceptée en novembre 1997 dans sa version 1.1, date à partir de laquelle UML devient un standard international
• Des versions depuis– 1995: Méthode unifiée 0.8 (Booch'93 et OMT)– 1995: UML 0.9 (+ la méthode OOSE)– 1996: UML 1.0 (proposée à l'OMG)– 1997: UML 1.1 (standardisée par l'OMG)– 1998: UML 1.2– 1999: UML 1.3– 2000: UML 1.4– 2003: UML 1.5– Nov. 2007: UML2.1.2
45
UBO Des points de vue différents …
• Des diagrammes différents– 14 types de diagrammes UML
• 3 types de diagramme– Structure : modélisation des aspects statiques– Comportement : modélisation des aspects dynamiques– Modélisation des aspects non fonctionnels
• les profils UML (QoS, MARTE)
46
23/02/2016
24
UBO Diagrammes UML
• Diagrammes statiques– diagramme de classes (Class diagram)– diagramme d’objets (Object diagram)– diagramme de composants (Component diagram)– diagramme de déploiement (Deployment diagram)– diagramme de paquetages (Package diagram)– diagramme de structures composites (Composite structure diagram)
• Diagrammes dynamiques – diagramme de cas d’utilisation (Use case diagram)– diagramme d’activités (Activity diagram)– diagramme d’états-transitions (State machine diagram)– diagrammes d’interaction (Interaction diagram)
• diagramme de séquence (Sequence diagram)• diagramme de communication (Communication diagram)• diagramme global d’interaction (Interaction overview diagram)• diagramme de temps (Timing diagram)
47
UBO Utilisation des diagrammes UML
• Documentation– Juste des schémas graphiques– Pour expliquer : rapport, présentation– Pour réfléchir : modèle d’un point de vue
• Vérification– Validité d’un schéma– Formalisation via une sémantique formelle
48
23/02/2016
25
UBO Utilisation des diagrammes UML
• Expression et analyse des besoins– Modélisation métier
• Diagrammes d’activité, diagrammes de classe– Besoins fonctionnels
• Cas d’utilisation, diagramme de séquence
• Conception– Architecture globale
• Aspects statiques : diagrammes de classe, de package, de composants• Aspect dynamique : diagramme de séquence
• Conception détaillée– Raffinement de l’architecture en modules
• Aspects statiques : diagrammes de classe, de package, de composants• Aspect dynamique : diagrammes de comportement, de séquence
49
UBO Utilisation des diagrammes UML
• Réalisation– Lien avec un langage de programmation (Java)
• Diagramme de classe– Environnement complet de modélisation/programmation
• Édition des diagrammes avec vérification, génération de code• Reverse code/modèle
• Déploiement– Modèle d’exécution
• diagramme de déploiement
• Documentation– Tout diagramme utile
• Intégration via une méthode– Quel diagramme à quel moment et quels sont les liens entre les diagrammes– UML n’est pas une méthode
50
23/02/2016
26
UBO Utilisation des diagrammes UML
• Un seul modèle mais plusieurs points de vue– Un point de vue = un diagramme
51
UBO Documentation sur les diagrammes
• Norme délivrée par l’OMG– OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2 – Description de chaque concept (une classe)
• Description description textuelle• Attributes attributs spécifiques (modélisation objet)• Additional Operations opérations spécifiques• Associations liens avec d’autres concepts• Contraints contraintes exprimée en OCL sur la description du concept• Semantic précision sur le comportement lié au concept• Semantic Variation point point de variation libre, sémantique non établie• Notation règles de représentation graphique ou textuelle• Presentation options points de variation dans la représentation• Style Guidelines style de la présentation• Examples
52
23/02/2016
27
UBO Interprétation des diagrammes
• Exemple : DataType• Description A data type is a type whose instances are identified only by their value. A
DataType may contain attributes to support the modeling of structured data types. • Attributes No additional attributes • Associations ownedAttribute: Property[*] The Attributes owned by the DataType. This
is an ordered collection. Subsets Classifier::attribute and Element::ownedMember • Contraints No additional constraints • Semantic All copies of an instance of a data type and any instances of that data type
with the same value are considered to be the same instance. Instances of a data type that have attributes (i.e., is a structured data type) are considered to be the same if the structure is the same and the values of the corresponding attributes are the same. If a data type has attributes, then instances of that data type will contain attribute values matching the attributes.
• Semantic variation point Any restrictions on the capabilities of data types, such as constraining the types of their attributes, is a semantic variation point.
• Notation A data type is denotated using the rectangle symbol with keyword «dataType» or, when it is referenced by (e.g., an attribute) denoted by a string containing the name of the data type.
• Examples
53
UBO Interprétation des diagrammes
• Exemples issus de la norme– Constraints
• An association specializing another association has the same number of ends as the other association.
self.parents()->forAll(p | p.memberEnd.size() = self.memberEnd.size()) • An element may not directly or indirectly own itself.not self.allOwnedElements()->includes(self)
– Semantic variation point • The order and way in which part instances in a composite are created is not defined
– Presentation Options pour les associations• When two lines cross, the crossing may optionally be shown with a small semicircular jog
to indicate that the lines do not intersect (as in electrical circuit diagrams)
– Style Guidelines• Lines may be drawn using various styles, including orthogonal segments, oblique
segments, and curved segments. The choice of a particular set of line styles is a user choice.
54
23/02/2016
28
UBO
• Sémantique opérationnelle de la communication– UML2 superstructure : “the manner of transmitting the request object, the amount of
time required to transmit it, the order in which the transmissions reach their receiver objects, and the path for reaching the receiver objects are undefined”
• Sémantique de consommation des messages par un objet– Envoi/réception de messages entre objets– Quid de la politique de stockage et de consommation des messages
• Non défini par UML
Interprétation des diagrammes
55
UBO Solutions pour une interprétation unique
• Via les outils– Les outils proposent une implémentation et donc … une interprétation
• usuellement une politique FIFO pour la gestion des messages
• Via des extensions d’UML– Profil spécifique
• Profil SDL : messages usuels traités en FIFO et messages urgents– Formalisation d’UML
• pUML (precise UML)– Préciser la sémantique via un modèle formel
• Automate communicants pour le comportement
56
23/02/2016
29
UBO Extensions d’UML par profils
• Mécanisme standard d’extension d’UML
• Ensemble cohérent de stéréotypes, de valeur marquées (taggedvalue) et de contraintes
• Principe général : on n’ajoute pas de méta classes (pas de nouveaux concepts ou diagrammes) mais des annotations aux méta-classes (diagrammes) UML existantes.
57
UBO UML
• Avant UML : beaucoup de langages de modélisation objets, mais aussi des langages de modélisation fonctionnel, composant, système, …
• Objectif d’UML : offrir un langage de modélisation universel …– « esperanto » de la modélisation– Définition et représenation des concepts (mots) de base du modeleur logiciel
• Des évolutions au cours du temps• Des différences d’interprétation (variation points)• Des spécialisations par extensions (profils)
• Au final beaucoup de sous-langages … mais une base commune
58
23/02/2016
30
UBO
• UML est standardisé par l’OMG• Interopérabilité• Formation
• UML est le langage de modélisation orienté objet le plus connu et le plus utilisé au monde• UML s’applique à plusieurs domaines• UML n’est pas une méthode, c’est un langage de modélisation
– Méthode UP
• Peu d’utilisateurs connaissent le standard, ils ont une vision outillée d’UML– 5% forte compréhension, 45% faible compréhension, 50% aucune compréhension
• UML est fortement critiqué car pas assez formel• UML est trop complexe
– 14 diagrammes et les extensions (profil)
– UML est outillé• Édition et vérification, génération de code• IBM a racheté Rational• Eclipse Modeling Tools (papyrus)
UML
59
UBO
Des modèles …
« One and three chairs », Joseph Kossuth, 1965
23/02/2016
31
UBO
• OMG et UML– http://www.omg.org/– http://www.uml.org/
• Cours de Jean-Marc Jézéquel– http://www.irisa.fr/prive/jezequel/enseignement/
• Cours de Laurent Audibert– http://laurent-audibert.developpez.com/Cours-UML/html/
• Cours d’Olivier Caron– http://www2.lifl.fr/~carono/
• Cours de Cédric Dumoulin– http://www2.lifl.fr/~dumoulin/enseign/
• Jean-Marie Nicolle– « Histoire des méthodes scientifiques », Paris, Bréal 2006
Bibliographie
61