Ingénierie du Développement Logiciel

lab-sticc.univ-brest.fr/~babau/ Ingénierie du Développement Logiciel dirigée par les modèles Jean-Philippe Babau Département Informatique, UFR Sciences, Laboratoire Lab-STICC Plan du cours 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) 2 1

Construire un pont 2 1 Pont Sublicius, Rome, 650 avant JC 3 4 le Ponte dei Salti (Lavertezzo, Suisse) Viaduc de Millau Mike Lehmann, Mike Switzerland March 2008 3 2 1 Des outils pour la construction et pour l organisation de la construction 4 3 4 2

Construire une maison : documents et suivi 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 5 Construire un avion : des modèles spécifiques 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 Quels modèles : 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 6 3

Construire un système 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 7 Construire un logiciel 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 8 4

Maitrise du développement En 2004, le Standish Group a évalué à 34% la part des projets qui aboutissent dans les conditions prévues, soit 18% de plus qu il y a 10 ans. 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. 9 Quantification des activités 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% 10 5

Les points clés de la construction de logiciel 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 11 Les points clés de la construction de logiciel 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 12 6

Les défis 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 13 Le développement d un logiciel concerne 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 14 7

Construire un logiciel=> intégration de divers aspects 15 Diverses préoccupations Cycle de développement Préoccupations du développeur Préoccupations de la maintenance Préoccupations de la gestion de projet 16 8

Quelques aspects liés au développement 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, ) 17 Quelques aspects liés au développement 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 18 9

Limites de la compréhension humaine => séparation des préoccupations 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 19 Un point de préoccupation 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 20 10

Des informations pour des activités 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 21 Lao Tseu "Trop de précision tue" Limites de la compréhension humaine => abstraction 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» 22 11

Modélisation pour appréhender la complexité 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 23 Introduction sur la notion de modèles «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 le représentant. Le premier et principal intérêt du modèle est d aider à expliquer en 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 24 12

Modèles et abstraction 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 25 Des modèles pour 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 26 13

Communiquer 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 27 Représentations 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 28 14

Formalisation 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 29 Bilan 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 30 15

Plan du cours 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) 31 Objectifs de l UE 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 32 16

Intervenants NEDELEC Olivier onedelec@irvi.fr BABAU Jean-Philippe babau@univ-brest.fr PAULY Yann Yann.pauly@univ-brest.fr LALLALI Mounir mounir.lallali@univ-brest.fr 33 Evaluation 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 34 17

Plan du cours 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é 35 Plan du cours 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 36 18

Plan du cours 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 37 Plan du cours Phase 4 : test logiciel (M.Lallali) Notions de base sur le test Test objet Test basés sur les modèles Introduction à la preuve 38 19

Plan du cours 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 39 Plan du cours Introduction à l ingénierie pour le développement logiciel Organisation du cours Introduction à la modélisation UML 40 20

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 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 21

UML : la genèse 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 43 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 22

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 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

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 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 24

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 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 25

Utilisation des diagrammes UML Un seul modèle mais plusieurs points de vue Un point de vue = un diagramme 51 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 26

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 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 27

Interprétation des diagrammes 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 55 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 28

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 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 29

UML 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) 59 Des modèles «One and three chairs», Joseph Kossuth, 1965 30

Bibliographie 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 61 31