Composition conceptuelle basée sur la relation Tout-Partie

Dimension: px
Commencer à balayer dès la page:

Download "Composition conceptuelle basée sur la relation Tout-Partie"

Transcription

1 École doctorale des sciences exactes et de leurs applications UFR sciences et techniques Composition conceptuelle basée sur la relation Tout-Partie THÈSE présentée et soutenue publiquement le 9 décembre 2004 pour l obtention du Doctorat de l Université de Pau et des Pays de l Adour (spécialité informatique) par Nicolas Belloir Composition du jury Rapporteurs : Pr Jean-Marc Jézéquel IRISA, Université de Rennes I Pr Yves Ledru LSR-IMAG, Université de Grenoble I Examinateurs : Pr Jeanine Souquières LORIA, Université de Nancy II Pr Gilles Motet LESIA, INSA de Toulouse Directeur : Pr Franck Barbier LIUPPA, Université de Pau et des Pays de l Adour Co-directeur : Dr Jean-Michel Bruel LIUPPA, Université de Pau et des Pays de l Adour Laboratoire d Informatique de l Université de Pau et des Pays de l Adour

2 Mis en page avec la classe thloria.

3 Remerciements Les remerciements. Président Rapporteurs Jury Directeur co-directeur équipe projet laboratoire autres i

4 ii

5 Je dédie cette thèse à la mémoire de ma mère, à Nadége et à Titouan. iii

6 iv

7 Table des matières Introduction 1 Partie I État de l art 7 Chapitre 1 Terminologie Concepts et définitions Du Cbd à la Cbse Composant logiciel Service de composant Interface Contrat Patrons de conception Canevas d applications Relation entre ces concepts Processus de développement d applications basées composants La réutilisation : un principe fondateur Acteurs du processus Étude du processus de développement Résumé du chapitre v

8 Table des matières Chapitre 2 Composition logicielle et composition niveau modèle Composition Illustration de la problématique par une étude de cas Éléments de définition Mise en œuvre de la composition logicielle Langages de script Langages de glu Modèles de composants Langages de description d architecture Langages de composition Bilan de la composition bas niveau Composition au niveau conceptuel Le patron de conception Composite Contrats Approche formelle pour la composition Bilan sur la composition au niveau conceptuel Chapitre 3 Uml et les composants Modélisation, métamodélisation et métamétamodélisation : une question d à propos Uml 1.x Uml Aperçu des améliorations Nouveaux concepts Diagrammes de composants Support pour la composition Nouveau métamodèle La composition conceptuelle en Uml Limites de la composition conceptuelle en Uml Nos solutions Apport d Uml 2.0 par rapport à Uml 1.x Problématique de notre thèse vi

9 Partie II Modèle de composition, une proposition basée sur la théorie de la relation Tout-Partie 67 Chapitre 4 Une approche pour la composition logicielle basée sur la relation Tout- Partie Étude de l application de la relation Tout-Partie à la composition logicielle Démarche, fondations et hypothèses de notre proposition Études des propriétés de la relation Tout-Partie pour la composition logicielle Classification des propriétés retenus selon les dimensions architecturale et dynamique Relations entre les propriétés de composition retenues Identification de différents types de relations Tout-Partie Résumé de l étude Définition d un métamodèle Uml pour la Cbse basé sur la relation Tout-Partie Discussion sur les choix de métamodélisation Proposition de métamodèle Contraintes Ocl Résumé de l application à Uml du modèle de composition Conclusion Partie III Outillage appliqué à la composition 101 Chapitre 5 WpcP : un profil Uml dédié à la composition logicielle Définition et démarches Définition Éléments d un profil Uml Démarche d élaboration d un profil et éléments de description Notre proposition : le profil WpcP Domaine du profil Définition technique Définition opérationnelle Réalisation et exemple d utilisation Limites dues à l outil et choix techniques Exemple d utilisation Bilan du profil vii

10 Table des matières Chapitre 6 Environnement de composition Java pour un déploiement de composants rigoureux Vers un assemblage contraint des composants logiciels : l environnement WpcE Un environnement de composition spécifique Pilotage de composants L environnement Jmx Présentation de Jmx Le service de relation Jmx Environnement de composition Java pour un développement rigoureux Construction de relations Tout-Partie Implémentation de la relation Tout-Partie Exemple d utilisation Bilan du chapitre Chapitre 7 Application de la technologie Bit pour la vérification des contrats de exprimés sur les états Contrats basés sur les états et vérification a posteriori Test de composant Spécificité du test de composant Le test intégré de composant La technologie Bit Le Contract testing Le State-based contract testing Outillage de la technologie Bit La librairie Bit/J Exemple d utilisation de la librairie Bit/J Bilan du chapitre Conclusions générale et perspectives 143 Bibliographie 151 viii

11 Annexes 163 Annexe A Les contraintes Ocl 165 Annexe B Présentation de Jmx 171 Annexe C Le profil WpcP 181 Glossaire des termes techniques 191 Index 195 Index des personnalités, projets, laboratoires et entreprises Index des méthodes, techniques et outils Index ix

12 Table des matières x

13 Introduction 1

14

15 Cadre général de la thèse La réutilisation de parties de logiciel déjà développées pour construire de nouvelles applications présente de nombreux intérêts. Notamment, elle permet une baisse des coûts de production des nouvelles applications, et également une meilleure qualité du code réutilisé : plus un code est réutilisé plus il y a de chances de voir son nombre de bogues diminuer. La technologie objet a été une approche prometteuse pour la réutilisation [MN98]. Cependant, force est de constater qu elle n a pas atteint ses objectifs. En effet, les objets sont des entités de granularité trop faible pour une réutilisation efficace. Il a donc été envisagé de réutiliser des entités de granularité plus importante, en tenant compte de nouvelles préoccupations telles que la prise en compte du comportement, de l hétérogénéité, de l importance du concept d interface et surtout de l impact du client/serveur et des systèmes distribués. Cela a abouti au concept de composant logiciel. En plus d être réutilisables, les composants facilitent le développement de systèmes logiciels plus flexibles et plus modulaires, risquant moins de devenir prématurément obsolètes [BBB + 00]. Cela améliore notamment les possibilités de développement rapide et de maintenance. La construction d une application est donc vue, non plus comme un développement intégral et complet, mais comme un assemblage de briques de bases réutilisables. On parle alors de composition logicielle. Cette évolution a conduit à une différenciation des métiers des acteurs du processus logiciel : on distingue maintenant le développeur de composants, qui a la charge de concevoir, créer et fournir des composants, du développeur d applications qui construit une application par assemblage de composants. Dans ce domaine, les technologies supportant la construction et l assemblage de composants ont atteint un premier niveau de maturité, notamment avec l avènement des standards de composants technologiques tels que Ejb (Entreprise JavaBeans ) [Mic99], Ccm (Corba Component Model) [OMG99a] ou (D)Com ((Distributed) Component Object Model) [Rog96, Gri97]. Le monde industriel, qui voit dans le développement basé composant (Cbd 1 ) un moyen de réduire le coût de développement et de maintenance des logiciels, a notamment dynamisé leur essor. Malgré cela, les techniques d ingénierie logicielle spécifiques à ce domaine (l ingénierie logicielle basée composant, appelée également la Cbse 1 ), dans des phases telles que la modélisation, la vérification ou la validation des applications à composants sont encore insuffisantes et demandent de plus amples efforts de recherche [Hig01]. Dans ce cadre, un point est particulièrement critique : il s agit de la combinaison des composants entre eux, et surtout de sa formalisation. L état actuel des standards permet de faire interagir des composants ensemble lorsqu ils ont été plus ou moins conçus pour cela. Dans le cas contraire, les composants sont adaptés, ou insérés au sein d adaptateurs (i.e., container, ou enveloppeur 2 ou code glu) les rendant compatibles entre eux. Ces actions ne sont pas triviales et représentent un frein à l essor du Cbd. Une des raisons à cela est que les efforts de recherche ont plus porté sur le concept de composant que sur celui de composition. Lorsqu on traite de la Cbse, il convient de considérer deux niveaux différents. Le premier est le niveau conception dans lequel les composants sont des entités abstraites de conception. Le second est le niveau déploiement, dans lequel les composants sont des entités exécutables. Actuellement, les besoins au niveau déploiement s avèrent satisfaits par des technologies matures telles que.net [SGM01], Ejb ou Corba [OMG02a]. À l inverse, les techniques de modélisation pêchent par manque de constructions de modélisation dédiées, bien formalisées et peut-être mieux inspirées de travaux de recherche précédents. Notre travail entre dans ce cadre et se propose d apporter des améliorations à cette limite. 1 Nous utiliserons dans ce document les acronymes anglais Cbd (Component-Based Development) et Cbse (Component- Based Software Engineering) à la place des équivalents français Dbc et Ilbc peu connus et rarement employés. 2 Wrapper en anglais 3

16 En particulier, le langage de modélisation Uml, qui est un standard de facto tant au niveau industriel qu au niveau de la recherche, n offrait jusqu à ce jour que peu de moyens permettant de modéliser les applications basées composants. La dernière évolution du langage, la version 2.0, a apporté des améliorations relativement significatives, palliant en partie à cette lacune. Cependant, de nombreuses incohérences sont encore présentes dans la définition du langage : la sémantique des concepts propres à la Cbse est parfois absente, peu précise ou même incohérente. Au niveau assemblage, les technologies actuelles permettent à des composants d interagir, mais sans évaluer leur compatibilité [SW02]. La meilleure prise en compte de la composition au niveau conception devra améliorer ce point. Objectif de la thèse Dans cette thèse, nous nous sommes intéressés à une approche nouvelle autour de la composition conceptuelle. Nous nous sommes pour cela fixés les objectifs suivants : Nous cherchons à modéliser la composition logicielle en y incluant le plus de sémantique possible (au sens Uml, c est-à-dire définie par un métamodèle et des contraintes). Pour cela, nous caractérisons la composition au travers d un certain nombre de propriétés spécifiques. Nous appliquons nos propositions à Uml. Nous cherchons à définir un cadre applicatif cohérent, tout au long du cycle de développement. Pour cela, nous voulons offrir les moyens de vérifier que les propriétés de composition sont correctement implémentées par l application réalisée. Nous explorons deux approches complémentaires. La première consiste à proposer un environnement contraint de déploiement dans lequel les propriétés de composition peuvent être implémentées telles quelles. La seconde fournit des moyens de test sur le comportement externe des compositions. L approche retenue, pour le modèle de composition, est basée sur la théorie de la relation Tout-Partie. À l origine, cette théorie a une base mathématique. Elle a été développée pour les ontologies. Notre but est de l adapter pour le génie logiciel et plus particulièrement la Cbse. Notre équipe a déjà exploré cette approche en l appliquant à la modélisation objet [BHSPLB03]. Elle a identifié un certain nombre de propriétés caractéristiques et les a formalisées. Nous nous proposons de partir de ces travaux, d étudier leur éventuelle application à la composition de composants et de proposer, dans le cadre d Uml, un modèle de composition à partir de cette étude. D un point de vue applicatif, nous proposons une plate-forme visant à garantir une cohérence tout au long du processus de réalisation. Il s agit de : un profil 3 Uml permettant d utiliser notre modèle de manière pragmatique, développé à l aide du module Profile Builder de l atelier de génie logiciel Objecteering ; un environnement de déploiement centré sur la composition logicielle, permettant la manipulation et le pilotage dynamique des assemblages de composants. L idée est de pouvoir directement implémenter les propriétés de composition spécifiées au niveau du modèle ; l utilisation d une technique de test de composants permettant la vérification du comportement externe des compositions logicielles. En particulier, notre proposition permet la description et la vérification de contrats basés sur les états. 3 Dans ce document, nous utilisons la traduction francisée du terme anglais «profile» : profil 4

17 Le contexte applicatif dans lequel s est déroulé cette thèse (projet européen Component+ 4 ) a eu des impacts sur l orientation que nous avons donnée à notre étude. En particulier, le projet a été mené en partenariat avec des industriels (notamment Philips Electronics (Angleterre) et Engineering Ingegneria Informatica (Italie)). Pour cette raison, le travail s est fortement attaché à produire des résultats concrets et des outils les soutenant. Organisation du mémoire Ce document est décomposé en trois parties (cf. Figure 1). La partie I présente l état de l art de notre problématique. Le chapitre 1 donne, dans un premier temps, une définition des concepts de base de la Cbse. Puis, le chapitre 2 présente un état de l art de la composition logicielle. Le chapitre 3 présente Uml et en particulier la manière dont Uml traite la composition de composants. Il se termine en dressant un bilan et en posant précisément notre problématique. La partie II définit et explique notre modèle de composition conceptuelle. le chapitre 4 présente notre approche basée sur la relation Tout-Partie et l applique au langage de modélisation Uml. Enfin, la partie III détaille l outillage que nous fournissons pour réaliser notre modèle : un profil Uml, détaillé au chapitre 5 ; un environnement d assemblage, présenté au chapitre 6, permettant le déploiement de composants respectant la modélisation de la composition établie grâce au profil ; une librairie permettant la vérification du comportement externe des compositions présentée au chapitre 7. I État de l art II Modèle de composition III Outillage Partie 1 Terminologie 2 3 État de l art UML sur la et la composition CBSE logicielle 4 Étude de la relation Tout-Partie et Métamodèle Uml basétout-partie 5 Profil Uml 6 Environnement de composition 7 Test intégré orienté contrat Chapitre Fig. 1 Représentation schématique de l organisation du mémoire 4 projet Européen Component+, http ://www.component-plus.org 5

18 6

19 Première partie État de l art 7

20

21 Chapitre 1 Terminologie Sommaire 1.1 Concepts et définitions Du Cbd à la Cbse Composant logiciel Service de composant Interface Contrat Patrons de conception Canevas d applications Relation entre ces concepts Processus de développement d applications basées composants La réutilisation : un principe fondateur Acteurs du processus Étude du processus de développement Résumé du chapitre Ce chapitre présente les concepts élémentaires du développement à base de composants. Tout d abord, la section 1.1 donne les définitions des principaux concepts que nous retenons. Nous présentons la Cbse, puis nous nous intéressons aux abstractions particulières que sont un composant, ses services, ses interfaces et les contrats exprimables à son égard. Nous introduisons également les notions de patrons et de canevas d applications qui sont des notions importantes du développement à base de composants. La section 1.2 présente le processus de développement d une application basée composants. Nous commençons par parler de réutilisation, puis nous présentons les acteurs de ce type de processus logiciel. Enfin, nous regardons plus en détail les particularités du développement orienté composants. 1.1 Concepts et définitions Cette section a pour objectif de définir les termes clés que nous employons dans la suite de ce mémoire. Nous présentons les concepts de base du développement à base de composants, discutons de leurs définitions dans le domaine et, le cas échéant, nous positionnons sur les éléments de définitions que nous retenons. En effet, tous les concepts abordés n ont pas une définition unique. Aussi, loin de prétendre détenir la définition absolue, il nous a paru important de donner au lecteur notre définition. Pour commencer, nous expliquons la signification des concepts Cbd et Cbse. 9

22 Chapitre 1. Terminologie Du Cbd à la Cbse Les concepts de Cbd et de Cbse sont parfois utilisés comme des synonymes. Pourtant leur signification n est pas la même. Le Cbd traduit l idée de création d une application par utilisation/réutilisation de composants. La Cbse désigne les méthodes, techniques et outils permettant la conception et la mise en œuvre d applications basées composants. Elle a ainsi permis au Cbd de passer d une approche artisanale à une approche industrielle. Les définitions des concepts inhérents à la Cbse sont encore mal formalisées et portent parfois à confusion. Le flou qui entoure certaines définitions vient de la manière dont la Cbse a été créée et a évolué, aux confins de plusieurs domaines. Nous citons les deux principaux : l approche orientée objet et les travaux portant sur les architectures logicielles. L expérience tirée de l approche objet a été fondatrice pour la prise en considération de l aspect réutilisation dans la Cbse. Les travaux sur les architectures logicielles ont montré l importance d une architecture clairement spécifiée pour la construction d applications. Les avantages d une telle paternité sont : la modularité de l application ; la possibilité de mieux organiser le développement de l application ; une identification claire des interactions entre les modules ; l amélioration très significative de la maintenabilité, car il est alors aisé de faire évoluer un module indépendamment des autres. Le Cbd intéresse de nombreux domaines aussi différents que le temps réel ou l informatique de gestion. Or ces domaines ont culturellement des méthodes pour le développement et des contraintes très différentes les unes des autres. Par exemple, le développement temps réel requiert un niveau de certification élevé et long à réaliser. À l inverse, le développement d applications Web nécessite une grande réactivité et des temps de développement très courts. Le Cbd a suscité un intérêt et un investissement très important dans le monde industriel. Plusieurs raisons peuvent l expliquer. D une part, les promesses de rentabilité et de qualité accrue des logiciels finalisés, avancées par cette technologie, ont poussé les industriels à investir dans ce domaine. D autre part, des moyens pour soutenir le Cbd ont rapidement été créés. Johnson prétend que le marché des composants est né avec Visual Basic [Mic] et les composants graphiques. Les modèles de composants industriels tels que Com [Rog96] et DCom [Gri97], implémentés dans le système Windows ont également conduit à créer une dynamique et une évolution rapide. Cette dynamique ne repose cependant ni sur des bases stables et admises, ni sur des standards. Comme nous le verrons dans le chapitre 2, il existe à l heure actuelle des moyens pour construire des applications à base de composants sur des environnements de déploiement fiables. Cependant, l expérience a montré que le Cbd nécessitait une approche systématique [CL00]. Les principales missions de la Cbse sont les suivantes [CH01] : 10 fournir un support pour le développement des composants ; supporter le développement des composants en tant qu entités réutilisables, c est-à-dire anticiper la réutilisation et concevoir la réutilisabilité ; faciliter la maintenance et l évolution des systèmes en permettant la modification et le remplacement de leurs composants.

23 1.1. Concepts et définitions Composant logiciel La notion de composant logiciel, bien qu étant le cœur de la Cbse n a pas de définition universellement acceptée. Parmi celles proposées, la plus couramment admise a été énoncée lors du Workshop on Component Oriented Programming en 1996 et reprise dans le livre de Szyperski et al. [SGM02]. Elle sert également de base à d autres définitions plus ou moins connexes [CHJK02b, ART03, CHJK02a, BBB + 00, ABB + 01]. Nous ne les reprenons pas intégralement mais discutons des points de désaccord entre ces définitions et celle de Szyperski. Celle-ci définit un composant en énumérant ses propriétés caractéristiques : «A software component is a unit of composition with contractually specified interfaces and context dependencies only. A software component can be deployed independently and is subject to composition by third parties». Trois propriétés caractéristiques sont mises en relief par cette définition. La première traite le côté architectural d un composant : un composant encapsule totalement son implémentation et communique avec son environnement au travers de ses interfaces [CHJK02a]. Atkinson et al. dans [ABB + 01] confortent ce point en parlant de «self-contained piece of software, with well-defined interaction points and nodes». La deuxième caractéristique porte sur la notion de composition. Un composant est une unité de composition et est sujet à composition ; il doit donc être conçu pour la composition, c est-à-dire pour être combiné avec d autres composants afin de construire des entités logicielles de taille plus conséquente. Enfin, la troisième caractéristique concerne la capacité de déploiement d un composant. Le déploiement est l action de mise en service d un composant au sein d une architecture spécifique. Nous en reparlons dans la section Elle doit être indépendante, c est-à-dire que l on peut déployer un composant indépendamment de toute autre partie d une application. Cela signifie également qu il doit pouvoir être déployé par une tierce personne, c est-à-dire une personne qui ne l a pas créé et qui ne le connaît pas. Cette notion est nouvelle dans le développement d applications. En effet, la modularité des applications basées composants permet de maintenir une partie du logiciel à la manière des systèmes d exploitation ou des systèmes de gestion de bases de données. On peut parler d administration d application. Cette propriété est particulièrement importante pour la réutilisabilité d un composant Différence entre objet et composant Chessman et Daniels dans [CD01] définissent les composants comme une extension de la technologie orientée objet (OO). À ce titre, un composant est vu comme une unité logicielle structurée selon les principes objets suivants : unification des données et des fonctions, encapsulation et identité unique. Un composant étend ces principes et se différencie d un objet par les points suivants : il fournit une représentation de sa spécification distincte de son implémentation à travers son interface ; il possède généralement des moyens de communication plus étendus que les objets (ces derniers se limitent généralement aux mécanismes de message) ; il a souvent des capacités de persistance là où un objet est limité à son état local ; il est généralement de granularité plus importante qu un objet et propose des actions complexes via ses interfaces. Le tableau 1.1 résume les différences entre objets et composants. La question de savoir si une classe seule peut être un composant est souvent posée. Nous soutenons que, si une classe est livrée avec ses interfaces de services requis et fournis, alors elle peut être considérée comme un composant de granularité faible. La définition précédente présente un point de vue intéressant : il s agit du fait qu un composant possède souvent des capacités de persistance. Ce point est en contradiction avec Szyperski qui dit qu un composant «has no (externally) observable state». Ces deux approches sont 11

24 Chapitre 1. Terminologie Propriété Objet Component Interface bien définie Possible Obligatoire Capacité à être déployé Non Oui Communication Invocation de méthode Invocation de méthode, de service, envoie de signal... Capacité de persistance État interne Possible Granularité Simple Variée Tab. 1.1 Résumé des différences entre un objet et un composant souvent débattues dans la communauté composant. L approche de Szyperski est une vue dans laquelle un composant ne peut être distingué des autres copies de ce composant. L approche dans laquelle un composant a des capacités de persistance implique le contraire. En effet, à partir du moment où un composant peut stocker des informations, il peut être distingué des autres copies de ce composant. Cette approche nous semble plus ouverte et plus intéressante car elle permet d utiliser la technologie composant pour un plus grand nombre de cas. Nous adhérons donc à la vue de Chessman et Daniels sur ce point Forme et cycle de vie d un composant Les définitions précédentes identifient les propriétés d un composant mais ne précisent pas exactement ce qu est, structurellement, un composant, notamment lors des différentes phases de son cycle de vie. Il est pourtant intéressant d en étudier les caractéristiques et d en différencier la sémantique : le terme composant ne qualifiant pas le même type d élément lorsqu on parle au niveau modèle ou au niveau déploiement. Dans [BBB + 00], un composant logiciel est définit comme suit : «A software component merges two distinct perspectives [...] : Viewed as implementations, components can be deployed, and assembled into larger (sub)systems. Viewed as architectural abstractions, components express design rules that impose a standard coordination model on all components. These design rules take the form of a component model, or a set of standards and conventions to which components must conform». Cette définition fait apparaître deux aspects physiques différents : le composant d implémentation qui est un programme ou une partie de programme, et le composant de conception qui est un modèle. [CD01] vas plus loin et identifie six notions caractérisant un composant (la Figure 1.1 représente cette proposition) : Standard de composants : un composant, pour pouvoir être assemblé afin de construire une application, doit se conformer à des règles précises définies par un standard. Par exemple, les standards tels que Ejb, Ccm, ou Com, sont des normes de composants. On trouve cette notion également sous l appellation de modèles de composants. Nous reviendrons plus loin sur cette notion (cf. p. 40). 2. Spécification de composant : afin de pouvoir utiliser un composant, il faut savoir précisément ce qu il peut faire. Cette règle est particulièrement vraie lorsque l utilisateur d un composant n est pas son créateur. Il faut donc fournir une spécification claire des composants. 3. Interface de composant : l interface d un composant est une partie importante de sa spécification. Elle permet de séparer sa spécification de son implémentation. Cela autorise, a priori facilement, le remplacement d un composant par un autre (implémentant la même interface). 4. Implémentation de composant : l implémentation d un composant est une mise en œuvre possible de la spécification d un composant. Il peut y avoir de nombreuses mises en œuvre d une même spécification, dans des langages différents par exemple.

25 1.1. Concepts et définitions 5. Composant installé (ou déployé) : il s agit de la forme que prend une implémentation de composant lorsqu elle est déployée sur un système. À chaque fois qu un composant est déployé, il crée un composant installé. 6. Composant objet : il s agit de la forme du composant lorsque l application est en exécution. Seuls les composants objets font réellement quelque chose. Cette définition est limitée à des composants OO. Elle peut toutefois être étendue à d autres formes de composants. On parlera alors plutôt d instances de composant. Interface de composant Interface supportées 1..* * Spécification de composant 1 réalisation * Implémentation de composant 1 Installation * Installation de composant 1 * Instance Composant objet Fig. 1.1 Spécialisation de la notion de composant en fonction de son cycle de vie [CD01] Dans un même esprit, Marvie [Mar02] étend la définition de Szyperski par quatre notions caractérisant celle de composant : le type d un composant, l implantation d un composant, le paquetage d un composant et l instance d un composant. En résumé, il est nécessaire de tenir compte de la forme structurelle d un composant au cours de son cycle de vie. Un composant, d un point de vue spécification, est une représentation conceptuelle d une entité informatique réutilisable. On parle de composant conceptuel. D un point de vue implémentation, il s agit de la représentation codée de cette entité conceptuelle. Il peut y avoir plusieurs représentations codées en fonction de la technologie dans laquelle le composant devra s intégrer. Il peut également y avoir plusieurs instances d une implémentation de composant. On peut même imaginer plusieurs instances de différentes implémentations d un même composant conceptuel. Ces instances et ces types auront cependant en commun les interfaces du composant Une forme particulière de composant : le composant sur étagère Nous introduisons ici un type de composant particulier : le composant Cots, pour Commercial Off- The-Shelf, appelé encore Cots tout simplement, et dont la traduction française est «composant sur étagère» 5. Ce type de composant répond à une demande forte du marché industriel. Il s agit de composants vendus, généralement sous forme binaire, par des fournisseurs de composants, à des utilisateurs 5 On utilisera plutôt l acronyme Cots pour sa concision. 13

26 Chapitre 1. Terminologie de composants : l idée est de proposer un large choix de composants directement exploitables (sans modification) et intégrables dans une application basée composants. Wallnau et Stafford, du laboratoire Sei (Software Engineering Institute) de Carnegie Mellon, définissent un composant Cots de la manière suivante [WS01] : une implémentation d une fonctionnalité livrée sous forme binaire, sujet à composition part une tierce personne, vendu ou fourni sous licence par un vendeur, souhaitant en tirer profit, sous une forme identique (c est-à-dire non modifiable). Oberndorf et al. [OBS00] ajoutent que le vendeur a la charge de fournir le support et les évolutions de ces composants. Les composants Cots sont à eux seuls une thématique complète comme le montre les nombreux travaux ou ouvrages et les nombreuses conférences 6 et ateliers qui leur sont dédiés. Ils posent des problèmes particuliers tant au niveau technique qu au niveau commercial et légal. D un point de vue technique, les Cots sont souvent de taille importante. Ils sont paramétrables pour pouvoir être intégrés à un grand nombre d applications. Cela implique des capacités de paramétrage importantes, mais également une complexité accrue, ce qui peut avoir des conséquences sur les performances. En outre, il est souhaitable qu ils soient certifiés et éprouvés pour des usages variés. Ils posent cependant des problèmes de validation et de certification au sein de leur nouvel environnement. Enfin, les applications à base de Cots nécessitent des nouvelles méthodes de développement, traitant notamment les aspects spécifiques comme la sélection des composants, la réutilisation, l évaluation [Kur01, Cra01]. Les questions d ordre commercial et légal sont également à prendre en compte. Il ne s agit plus de développements internes ou sous contrats mais d achats de produits finis, maintenus. Le choix des composants Cots peut être influencé par une politique commerciale (accords entre entreprises utilisatrices et fournisseurs) ou des restrictions légales : par exemple, se pose pour les entreprises des secteurs stratégiques la question de l opportunité d utiliser des Cots produits par des entreprises étrangères. Pour finir, citons une forme particulière de Cots que sont les Cots produits sous forme de logiciels libres. Ils permettent l accès au code source, et notamment la modification du code pour être adapté à un besoin particulier Taille des composants La taille des composants est très variable. Un composant, dans sa plus petite taille, peut être un simple objet ou une collection d objets. On parle alors de brique de base. Notons qu un composant a pour finalité d être déployé indépendamment d autres composants ; il doit contenir les moyens lui permettant de le faire [ACC02a] (caractéristiques de gestion de ressources ou de sécurité par exemple). Par composition, on peut construire, à partir de ces briques de base, des composants de taille plus importante. Dans certaines approches, un composant peut être considéré comme une application. C est le cas par exemple de certains composants Microsoft, comme Word ou Excel. Ces composants sont des Cots, puisqu ils sont utilisés uniquement sous forme exécutable. Les applications construites à partir des Cots sont appelées des produits basés-cots 7. Office est un produit basé-cots construit à partir des composants comme Word et Excel par exemple. Remarquons que ce point est discutable. En effet, il n est pas possible de remplacer dans Office un composant (Word par exemple) par un composant différent (un autre traitement de texte par exemple). Le débat sur la taille des composants peut également être présenté comme une différence de compréhension entre le monde académique et le monde industriel [Bos00]. Le monde académique a tendance à définir les composants comme des entités bien définies (souvent petites, avec des propriétés fonctionnelles et non fonctionnelles facilement compréhensibles) alors que pour le monde industriel, les composants sont 6 Par exemple International Conference on COTS-Based Software Systems http ://www.iccbss.org/ 7 Cots-based product en anglais 14

27 1.1. Concepts et définitions généralement des parties complètes de systèmes pouvant être réutilisées mais avec des interfaces n étant pas spécialement bien définies et avec peu d adéquation vis-à-vis des modèles de composants [Crn02]. Les Erp (Entreprise Resource Planning) comme Sap 8 en sont un exemple. Les systèmes de gestion de stock ou les systèmes de paie y sont vus comme des composants. Comme on peut le constater, cette vision est à la limite de la définition d un composant Déploiement des composants L aspect réutilisable des composants logiciels sous-entend leur utilisation dans des environnement différents. On parle alors de déploiement sur un environnement cible. Même dans le cas de composants à usage unique, le premier environnement de déploiement que connaît un composant est son environnement de développement. Il est généralement considéré comme différent de celui dans lequel il sera mis en exploitation. Ce concept n est pas propre à la Cbse ; on le retrouve par exemple en informatique embarquée, où les programmes sont souvent déployés sur des machines cibles dont l architecture machine est différente de celles de développement. Le Cbd a connu un engouement important notamment avec l avènement des architectures distribuées, où une application est souvent composée de plusieurs nœuds de déploiement. Cependant, les applications distribuées ne sont pas les seules candidates possibles au Cbd. En effet, il est tout à fait possible de développer des applications fonctionnant sur un seul nœud de déploiement avec l approche composant. Le déploiement est étroitement lié avec l aspect configuration des composants. En effet, la réutilisation amène à déployer un composant dans des environnements hétérogènes. Pour pouvoir s adapter à cette hétérogénéité, le composant doit être fourni avec des moyens de configuration. Ces moyens peuvent être accessibles via des interfaces de configuration comme discutés à la section Considérons un composant permettant l interrogation de bases de données : il devra être configuré en fonction du type de base de données avec lequel il devra interagir Notre position Nous sommes en accord avec la définition de Szyperski. Cependant, nous la spécialisons avec les éléments complémentaires que nous avons présenté. Nous considérons qu un composant a un état interne. Il peut être de granularité importante mais dans sa plus simple expression, un objet avec des interfaces clairement spécifiées peut être considéré comme un composant. Nous considérons le composant à travers les niveaux d abstraction suivants : le composant conceptuel, le type de composant, l implémentation de composant et l instance de composant. Les composants Cots sont considérés de la même manière. Nous les différencions uniquement par leur aspect boîte noire et leur côté commercial Service de composant Nous avons présenté une définition du concept de composant. Nous n avons pas encore parlé de son rôle, au sein d une application : un composant propose (respectivement requiert) des services à d autres composants. Il s agit d un échange de services de type client-serveur. Le composant, respectivement, est vu des autres composants, comme serveur pour les services qu il propose et comme client pour les services qu il requiert. Un service est défini comme suit par [BSW03] : «A service is a running instance (all the way down to supporting hardware and infrastructure) that has specific quality attributes, such 8 Pour plus d information voir http ://www.sap.com/solutions/business-suite/erp/index.aspx 15

28 Chapitre 1. Terminologie as availability, while a component needs to be deployed, installed, loaded, instantiated, composed, and initialized before it can be put to actual use». Cette définition est résumable en disant qu un service est une action possible fournie par le composant lorsque celui-ci est en exécution. Il s engage à fournir ce service sous réserve que certaines conditions soient remplies, notamment en terme de qualité de service (QoS) Interface Un composant doit être clairement différencié des autres composants et de leur contexte d exécution [CHJK02a]. Le mécanisme permettant cela est l interface. Les interfaces sont un mécanisme de contrôle des dépendances existantes entre les différents modules d un programme ou d un système [BBB + 00]. Par extension, elles ont le même rôle pour les composants. Une interface d un composant peut être définie comme une spécification de ses points d accès [SGM02], c est-à-dire qu elle offre la liste des services fournis ou requis par le composant. La différenciation de ces deux types d interfaces, communément appelées interface de services requis et interface de services fournis, est désormais acquise comme le montre leur prise en compte dans la version 2.0 d UML [OMG03b, OMG03d]. L existence d un troisième type d interface est sujet à discussion. Il s agit de la notion d interface de configuration [Bos00], appelée également «diversity interface» dans [Omm02]. Cette interface décrit notamment les capacités de configuration d un composant. Interface ProvInterPAM setcap settarget... Interface ReqInterPAM getforcevent getcapvent... component Pilote Automatique Marine légende interface interface Interface de configuration Interface ConfInterPAM settypebateau setinterfacerequise component composant interface de service fournis interface de service requis dependance Fig. 1.2 Un composant et ses interfaces La Figure 1.2 illustre la notion d interface en utilisant les notations définies dans Uml Elle représente un composant simple (un pilote automatique de bateau). Il propose trois interfaces : l interface de services fournis ProvInterPAM, l interface de services requis ReqInterPAM et l interface de configuration 9 Dans la suite de ce document, les notations utilisées pour les figures seront en Uml 2.0, sauf mention contraire précisée. Lorsqu une nouvelle notation est employée, elle est précisée en légende. 16

29 1.1. Concepts et définitions ConfInterPAM. Ce composant est conçu pour pouvoir être adapté à plusieurs types de bateaux. Lors de son déploiement sur un bateau, il faut le configurer en lui donnant le type du bateau pour qu il puisse paramétrer ses calculs. Cela se fait par le biais de l interface de configuration ConfInterPAM et l opération settypebateau. Il s agit d un service de configuration fonctionnel puisqu il est lié au métier du composant. L interface de configuration pose le problème des services de configuration fonctionnels et non fonctionnels. En effet, dans cet exemple l interface propose un service de configuration non fonctionnel, l opération setinterfacerequise, qui permet de spécifier le composant qui implémente l interface de services requis. Ce type d opération sera identique à tous les composants et a été ajouté durant le développement par ré-ingénierie. Ce type d interface est fortement lié à l implémentation choisie, et ne doit donc pas être inclue au modèle à ce stade de conception. Les interfaces de configurations sont proches des interfaces de services fournis. Elles s en différencient par leur côté préparation au fonctionnement du composant (paramétrage) que ce soit d un point de vue fonctionnel ou non fonctionnel. Les utilisateurs de ces interfaces ne sont pas les mêmes personnes. Les interfaces de configuration sont manipulées par les administrateurs d applications alors que les interfaces de services fournis sont manipulées par les utilisateurs de composants. Une interface se présente sous la forme d une collection de noms d opérations. Elle fournit, pour chaque opération, sa description et son protocole [Crn02]. L implémentation de ses opérations est encapsulée dans le composant. Comme indiqué dans [CHJK02a], cela permet de : remplacer l implémentation d un service sans modifier l interface, ce qui optimise localement un système sans impliquer sa reconstruction (à la manière d un driver dans un système d exploitation que l on peut mettre à jour sans avoir à recharger le système) ; ajouter de nouvelles interfaces et donc de nouvelles implémentations sans changer les implémentations existantes, ce qui permet d améliorer l adaptabilité des composants. La mise en œuvre de la notion d interface est maintenant aisée car de nombreux langages de programmation récents la supportent, comme par exemple Java. Dans le cas contraire, des langages de spécification d interfaces ont été également développés, indépendamment de tout type de langage, comme le langage Idl (Interface Definition Language) définit par le Dce 10 (Distributed Computing Environment). Un exemple de code est donné en Figure interface ProvInterPAM { 2 void setcap ( out int icap ) ; 3 void s e t T a r g e t ( i n f l o a t i L a t t i t u d e, i n f l o a t ilongitude ) ; 4 } ; Fig. 1.3 Exemple de définition d interface en IDL Contrat La plupart des techniques de description d interfaces se limitent à une seule description syntaxique. Meyer [Mey00] soutient que les langages de description d interface ne sont pas suffisamment expressifs pour décrire autre chose que la dimension architecturale. Ils ne décrivent pas le comportement du composant mais juste la liste de ses services. La notion de contrat [Mey97] permet notamment de pallier à cette lacune. Il est admis [SGM02, CHJK02a] que les contrats permettent de spécifier de manière plus rigoureuse le 10 Voir http ://www.sei.cmu.edu/str/descriptions/dce_body.html 17

30 Chapitre 1. Terminologie comportement des composants. Un contrat liste les contraintes globales que le composant doit maintenir (invariants). Pour chaque opération d un composant, un contrat liste également les contraintes qui doivent être assurées par le client (pré-conditions) et celles que le composant promet d établir en retour (postconditions). Les pré-, postconditions et invariants constituent une spécification du comportement d un composant. Un contrat peut se décomposer en quatre niveaux différents. Cette classification a été proposée par Jézéquel et son équipe dans [BJPW99]. Ces niveaux se différencient en terme de difficulté d automatisation des assemblages [ACC02a]. Ces niveaux sont, par ordre de difficulté de réalisation croisante : Niveau 1 : contrat syntaxique. Il s agit là de la plupart des contrats actuels. Le contrat n est assuré que par les signatures des opérations ; Niveau 2 : contrat par contraintes. Ce niveau décrit pour chaque service offert les conditions d utilisation et le résultat attendu ; Niveau 3 : contrat par synchronisation. Ce niveau garantit la bonne marche du système en cas d utilisation concurrente de l interface ; Niveau 4 : contrat de qualité de service. Ce type de contrat décrit les conditions d utilisation de l interface permettant de garantir la QoS de l interface. La plupart des modèles de composants actuels n imposent que le niveau 1. Ils n assurent que le typage correct des interfaces offertes et requises. Certains langages, comme Eiffel [Mey92] permettent une description des interfaces par contrats de niveaux 2, en introduisant dans leur syntaxe des pré, et post-conditions. Notons que sous réserve d atomicité d exécution des services, c est-à-dire que le service ne s appuie pas sur une cascade d autres services, le contrat de niveau 2 suffit à garantir le bon fonctionnement du composant [ACC02a]. Cependant, cette réserve est limitative dans les applications modernes où, bien souvent, des contraintes de parallélisme ou d exécution multiples sont nécessaires (applications clientserveur ou architectures trois tiers par exemple). Le rôle des contrats de niveau 3 est de décrire les contraintes de concurrence fixées par le composant. Ils permettent de considérer les interactions entre un composant et son environnement de manière non atomique. c est-à-dire que la description des transactions n est plus seulement envisagée au cas par cas mais dans sa globalité. Les opérateurs de composition permettent la définition d obligations telles que de fournir une description des entrées/sorties prenant en compte tous les cas potentiels possibles. Des contrats peuvent être également posés sur des assemblages de composants. On appelle cela des contrats de composition [Col03]. Enfin, le niveau 4 de contrat dérive d une demande forte de la communauté, notamment industrielle, pour garantir la QoS fournie par un composant. C est particulièrement vrai dans le domaine des applications temps-réel ou embarquées, dans lesquelles les conséquences d un composant n assurant pas une bonne QoS peuvent être dramatique. Par exemple, un composant assurant le transfert des données en 10ms, alors que le temps de transfert pour assurer la sécurité de l application est de 1ms, ne peut être candidat à un déploiement dans cette application. Un projet travaillant sur ce point est en cours de développement : il s agit du projet Artist Patrons de conception Les définitions des abstractions précédentes décrivent ce qu est un composant, ce qu il fait et comment il le fait. Nous nous intéressons maintenant à deux moyens aidant à réaliser une application basée composants. Les patrons de conception [GHJV95] forment une méthode de réutilisation des informations de conception. Ils ont été introduits dans le monde OO. Un patron est défini par Johnson comme suit [Joh97] : «A 11 Projet Européen ARTIST IST , http ://www.artist-embedded.org 18

31 1.1. Concepts et définitions pattern describes a problem to be solved, a solution, and the context in wich that solution works». Il s agit d une solution récurrente à un problème. Un patron peut également être adapté selon les circonstances spécifiques [SGM02]. On peut établir quatre catégories de patrons. Chaque catégorie est basée sur le niveau d abstraction à partir duquel ils sont utilisés [CHJK02b] : les patrons d analyse de Fowler [Fow96] aident à analyser les besoins et le système ; les patrons d architecture [AIS + 78] travaillent sur les propriétés globales et architecturales du système. Ils décrivent la structure globale du système, et fournissent des moyens de décrire l ensemble des sous-systèmes, de spécifier leur rôle et de décrire les relations existant entre eux ; les patrons de conception raffinent la structure et les comportements des sous-systèmes et des composants. Par leur aspect générique, les patrons sont considérés comme des micro-architectures visant à réduire la complexité, à promouvoir la réutilisation et à fournir un vocabulaire commun aux concepteurs [BM04]. Ils décrivent la structure et le comportement du système et des composants et les communications entre eux : les patrons de programmation sont dépendants des paradigmes et des langages de programmation utilisés. Client uses interface Cible operationrequise() Adaptée operationspecifique() Légende implements extends Association implémentation Héritage Adapter operationrequise() operationspecifique() Fig. 1.4 Patron de conception Adapter [GHJV95] La Figure 1.4 montre le patron de conception Adapter. Ce patron est utile lorsque l on désire utiliser une classe existante mais que l interface proposée n est pas satisfaisante ; il propose alors de définir une classe effectuant les actions d adaptation nécessaires. L interface Cible définit l interface désirée par le client, la classe Adaptée définit l interface existante des objets à manipuler, la classe Adapter effectue les actions nécessaires pour la réalisation des opérations suivant l interface désirée en se basant sur les opérations existantes. La classe Client manipule l objet suivant l interface désirée. Les patrons ont été appliqués avec succès dans la conception de nombreuses applications OO. Ils sont considérés comme des micro-architectures réutilisables qui contribuent à la bonne cohésion de l architecture complète. Cependant, la connaissance (terme consacré) contenue dans les patrons de conception est une connaissance non structurée qui est porteuse de nombreuses ambiguïtés à cause notamment de la description informelle des solutions. [CHJK02a] explique la relation existante entre patrons de conception et composants. Elle peut être vue comme suit : les patrons de conception, dans le processus de conception des applications basées composants, aident à déterminer les unités réutilisables et, le cas échéant, à les identifier sous la forme de composants existants, ou à les développer sous la forme d unités réutilisables. Enfin, les patrons de conception peuvent être utilisés pour décrire les compositions de composants. Il est envisageable de décrire dans des patrons, différents cas de composition type que l on pourrait utiliser. Nous reviendrons sur cette idée dans la section page 46 traitant du patron Composite. 19

32 Chapitre 1. Terminologie Les patrons sont souvent considérés comme des simples artefacts non logiciels, c est-à-dire de la documentation détaillée dans laquelle la solution est décrite dans un format particulier [KS98]. Un rapport de l Uqam (Université de Québec À Montreal) [BM04] identifie un certain nombre de problèmes liés à l utilisation des patrons : vérification de la bonne application du patron au résultat final ou complexité de certains patrons, par exemple. Par ailleurs, les patrons ne sont pas exprimables par un langage ou un environnement de modélisation utilisable directement. C est un des reproches récurrents adressés à cette approche. De nombreux travaux ont travaillé à corriger ce dernier point en proposant : l intégration des patrons dans un outil Uml [SGJ00] ; la définition d une représentation explicite des patrons basée sur les mécanismes d extensions d Uml [FL01] ; le développement d un profil Uml pour l utilisation des patrons [SA02] ; une approche de métamodélisation pour l intégration des patrons à l approche MDA [AAG01] ; l utilisation d Ocl [OMG03c], conjointement à celle de patrons, pour permettre la génération d un outil à partir d un métamodèle [AP03]. Notons les travaux de Keller et Schauer [KS98], qui ont proposé un environnement, basé sur les patrons de conception, maintenant une cohérence entre la conception, le développement et l exécution des composants. Cette approche présente deux limitations : d une part, la composition se limite à de l intégration de composants (nous revenons sur ce concept à la section ) ; d autre part, leur environnement est un environnement intégré dans lequel il est difficile d utiliser des composants développés extérieurement, et notamment des Cots. Un autre axe de travail particulièrement intéressant consiste à utiliser le coté extensible des patrons. L idée est de proposer un ensemble de patrons de conception, chacun capitalisant les règles de bonne forme pour un type particulier de composition. Dans ce cadre, [DAC99] propose de prouver les conceptions formellement. Ces conceptions forment alors un patron de conception pour la composition Canevas d applications Tout comme la définition de composant, la notion de framework, que nous traduisons par canevas d applications, est un second moyen aidant à réaliser une application basée composants. [Joh97] en donne deux définitions complémentaires. La première définition décrit la structure d un canevas : «A framework is a reusable design of all or part of a system that is represented by a set of abstract classes and the way their instances interact». La seconde définition concerne son but : «A framework is a skeleton of an application that can be customized by an application developer». Un canevas d applications peut être vu comme une conception réutilisable d une partie d un système, fournissant un ensemble de classes abstraites ainsi que les moyens de les faire interagir. Il peut être utilisé pour décrire quelque chose qui est utilisable, non seulement tel quel dans une situation particulière, mais également, après modification, dans une situation similaire à la situation conçue initialement. Cette modification peut avoir lieu durant la phase de conception ou d exécution, et est appelée instantiation du canevas [CHJK02a]. La contribution majeure des canevas est qu ils forcent les composants à effectuer leurs tâches à l aide de mécanismes contrôlés par le canevas lui-même, ce qui renforce le respect des principes architecturaux. Nous citons comme exemple de canevas d applications le Jaf 12 (pour JavaBeansTM Activation Framework). Un canevas sert non seulement à réaliser des applications très rapidement, mais permet aussi d obtenir des applications à structures semblables [GHJV95]. C est un gain en terme de maintenance (connaissance de la structure des applications). Cependant, cette contrainte est parfois trop forte. Le risque est alors de trop limiter la structure des applications et de devoir adapter les composants existants au canevas. 12 Voir http ://java.sun.com/products/javabeans/glasgow/jaf.html pour plus de détail. 20

33 1.1. Concepts et définitions Cela entre alors en contradiction avec l esprit de la Cbse, qui promeut la réutilisation telle quelle de composants Relation entre ces concepts Fig. 1.5 Relation entre les concepts pour une application basée composants [BBB + 00] Dans cette section, nous établissons les relations entre les concepts vus précédemment. Nous nous appuyons pour cela sur la Figure 1.5, tirée de [BBB + 00], qui schématise ces relations. Un composant (1) est une implémentation logicielle mettant en œuvre un ensemble de services décrits par une ou plusieurs interfaces (2). Les composants respectent certaines obligations qui sont décrites par des contrats (3). Ceux-ci assurent que des composants développés indépendamment obéissent à des règles d interaction, et peuvent être déployés dans un environnement de compilation et d exécution standard (4). Une application basée composants est construite à partir d instances de composants. Chaque composant est basé sur un type de composants (5). Un modèle de composants (6) est un ensemble de types de composants, de leurs interfaces, et éventuellement de patrons de conception décrivant les interactions entre les différents types de composants. Un canevas d applications (7) fournit un ensemble de critères de déploiement et d exécution (8) comme support au modèle de composants. La notion de canevas est souvent liée à celle de patron. Ils décrivent tous deux un groupe de participants et les relations entre eux, ce qui permet de les réutiliser dans toute situation semblable. Szyperski dans [SGM02] les différencie en ce sens que le canevas décrit une unité de conception de taille plus importante et plus spécialisée (orientée architecture) que les patrons. Les concepts de modèle de composants et de canevas sont également relativement liés. Un modèle de composants définit un ensemble de standards et de conventions utilisés par le développeur de composants alors qu un canevas de composants est une infrastructure support pour les modèles de composants [BBB + 00, CHJK02a]. 21

Introduction ( ) Source ( ) Introduction Source

Introduction ( ) Source ( ) Introduction Source Réutilisation, livraison pour la réutilisation, Biens logiciels, Bibliothèque de biens logiciels, Référentiel logiciel Patterns, frameworks, architectures à base de composants Introduction Source La notion

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement: Environnements de Développement Mme BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

Introduction aux Composants Logiciels

Introduction aux Composants Logiciels Introduction aux Composants Logiciels Christian Pérez LIP/INRIA Année 2010-11 Plan Introduction aux composants logiciels Pourquoi des composants logiciels Notions de composants logiciels Conclusion Survol

Plus en détail

Concevoir des applications Web avec UML

Concevoir des applications Web avec UML Concevoir des applications Web avec UML Jim Conallen Éditions Eyrolles ISBN : 2-212-09172-9 2000 1 Introduction Objectifs du livre Le sujet de ce livre est le développement des applications web. Ce n est

Plus en détail

Intégration du test dans les composants logiciels

Intégration du test dans les composants logiciels Intégration du test dans les composants logiciels Nicolas Belloir, Jean-Michel Bruel et Franck Barbier Université de Pau et des Pays de l Adour LIUPPA, B.P. 1155 64013 Pau CEDEX, France {belloir, bruel,

Plus en détail

Conventions communes aux profils UML

Conventions communes aux profils UML Conventions communes aux profils UML Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* Référence : Livrable 2.1 Date : Juin 2002 * : Les partenaires du

Plus en détail

Conception et Développement Orientés Objets Cours 1 : Introduction. 2 Les paradigmes de programmation. 3 Les concepts de la programmation objet

Conception et Développement Orientés Objets Cours 1 : Introduction. 2 Les paradigmes de programmation. 3 Les concepts de la programmation objet CNAM UV 19357 Année 2003-2004 David Delahaye David.Delahaye@cnam.fr Conception et Développement Orientés Objets Cours 1 : Introduction 1 Présentation de la valeur Ce cours s adresse à toute personne ayant

Plus en détail

EP 1 788 497 A1 (19) (11) EP 1 788 497 A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: 23.05.2007 Bulletin 2007/21

EP 1 788 497 A1 (19) (11) EP 1 788 497 A1 (12) DEMANDE DE BREVET EUROPEEN. (43) Date de publication: 23.05.2007 Bulletin 2007/21 (19) (12) DEMANDE DE BREVET EUROPEEN (11) EP 1 788 497 A1 (43) Date de publication: 23.0.07 Bulletin 07/21 (1) Int Cl.: G06F 17/0 (06.01) G06F 9/44 (06.01) (21) Numéro de dépôt: 00943.7 (22) Date de dépôt:

Plus en détail

les Design Patterns 11/02/2013 labsticc.univ-brest.fr/pages_perso/babau/ Département Informatique, UFR Sciences, UBO Laboratoire Lab-STICC

les Design Patterns 11/02/2013 labsticc.univ-brest.fr/pages_perso/babau/ Département Informatique, UFR Sciences, UBO Laboratoire Lab-STICC labsticc.univ-brest.fr/pages_perso/babau/ les Design Patterns Jean-Philippe Babau Département Informatique, UFR Sciences, Laboratoire Lab-STICC 2 1 Plan Introduction aux Design patterns Quelques Design

Plus en détail

Architecture Logicielle

Architecture Logicielle Architecture Logicielle Chapitre 3: UML pour la description et la documentation d une architecture logicielle Année universitaire 2013/2014 Semestre 1 Rappel L architecture d un programme ou d un système

Plus en détail

Le génie Logiciel (suite)

Le génie Logiciel (suite) Le génie Logiciel (suite) Lors du cours précédent, on a étudié différents cycles de vie, dont la cascade, ou la spirale. Analyse des besoins L analyse des besoins est une étape menant à l élaboration de

Plus en détail

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE»

MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» MODELISATION UN ATELIER DE MODELISATION «RATIONAL ROSE» Du cours Modélisation Semi -Formelle de Système d Information Du Professeur Jean-Pierre GIRAUDIN Décembre. 2002 1 Table de matière Partie 1...2 1.1

Plus en détail

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 MDA : Un Tutoriel Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 1 Sommaire Table des matières 1 Sommaire 1 2 Introduction 2 2.1 A qui s adresse ce tutoriel......................

Plus en détail

THÈSE. Manipulation de Lignes de Produits en UML

THÈSE. Manipulation de Lignes de Produits en UML N o d ordre : 3083 THÈSE présentée devant l université de Rennes 1 pour obtenir le grade de : Docteur de l université de Rennes 1 Mention Informatique par Tewfik ZIADI Équipes d accueil : IRISA-TRISKELL

Plus en détail

Positionnement de UP

Positionnement de UP UNIFIED PROCESS Positionnement de UP Unified Process Langage Méthode Outil logiciel UML UP RUP 6 BONNES PRATIQUES développement itératif gestion des exigences architecture basée sur des composants modélisation

Plus en détail

Modèle d implémentation

Modèle d implémentation Modèle d implémentation Les packages UML: Unified modeling Language Leçon 5/6-9-16/10/2008 Les packages - Modèle d implémentation - Méthodologie (RUP) Un package ou sous-système est un regroupement logique

Plus en détail

Description et illustration du processus unifié

Description et illustration du processus unifié USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins

Plus en détail

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base

SOA et Services Web. 23 octobre 2011. SOA: Concepts de base SOA et Services Web 23 octobre 2011 1 SOA: Concepts de base 2 Du client serveur à la SOA N est Nest pas une démarche entièrement nouvelle: années 1990 avec les solutions C/S Besoins d ouverture et d interopérabilité

Plus en détail

OpenPaaS Le réseau social d entreprise. Tâche 3.2.2 : Métamodèle support à la caractérisation des utilisateurs et des collaborations

OpenPaaS Le réseau social d entreprise. Tâche 3.2.2 : Métamodèle support à la caractérisation des utilisateurs et des collaborations OpenPaaS Le réseau social d entreprise Tâche 3.2.2 : Métamodèle support à la caractérisation des utilisateurs et des collaborations Propriétés du Document Source du Document Titre du Document FSN OpenPaaS

Plus en détail

Développement J2EE. avec Eclipse. et WSAD. Karim Djaafar. Olivier Salvatori. avec la contribution de. Groupe Eyrolles, 2003, ISBN 2-212-11285-8

Développement J2EE. avec Eclipse. et WSAD. Karim Djaafar. Olivier Salvatori. avec la contribution de. Groupe Eyrolles, 2003, ISBN 2-212-11285-8 Développement J2EE avec Eclipse et WSAD Karim Djaafar avec la contribution de Olivier Salvatori Groupe Eyrolles, 2003, ISBN 2-212-11285-8 Avant-propos Depuis la sortie de la plate-forme J2EE (Java 2 Entreprise

Plus en détail

Profiles UML et langage J : Contrôlez totalement le développement d applications avec UML

Profiles UML et langage J : Contrôlez totalement le développement d applications avec UML White Paper UML Profile Builder Softeam 1999 Page 1/12 Profiles UML et langage J : Contrôlez totalement le développement d applications avec UML White Paper Softeam 1999 Le profile UML est conçu pour structurer

Plus en détail

Analyse,, Conception des Systèmes Informatiques

Analyse,, Conception des Systèmes Informatiques Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance

Plus en détail

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013

UML Mise en œuvre dans un projet. Emmanuel Pichon 2013 UML Mise en œuvre dans un projet 2013 Introduction Rôles et activités dans un projet Définir la méthode de votre projet Adapter la modélisation à la méthode de votre projet Conseils de mise en œuvre de

Plus en détail

Analyse abstraite de missions sous PILOT

Analyse abstraite de missions sous PILOT Analyse abstraite de missions sous PILOT Damien Massé EA 3883, Université de Bretagne Occidentale, Brest damien.masse@univ-brest.fr Résumé Nous étudions la possibilité de réaliser un analyseur par interprétation

Plus en détail

Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P

Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P EUROCOPTER SAS Groupe EADS Marignane Ecole des Mines d Alès Laboratoire de Génie Informatique et d Ingénierie de Production LGI2P Nîmes Proposition de sujet de thèse CIFRE EUROCOPTER / LGI2P Titre Domaine

Plus en détail

IFT2255 : Génie logiciel

IFT2255 : Génie logiciel IFT2255 : Génie logiciel Chapitre 6 - Analyse orientée objets Section 1. Introduction à UML Julie Vachon et Houari Sahraoui 6.1. Introduction à UML 1. Vers une approche orientée objet 2. Introduction ti

Plus en détail

Introduction au Génie Logiciel

Introduction au Génie Logiciel Introduction au Génie Logiciel Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec J.-M. Favre, I. Parissis, Ph. Lalanda Qu est-ce que le logiciel? programme, ensemble d instructions Caractéristiques

Plus en détail

Spring IDE. Mise en œuvre. Eclipse

Spring IDE. Mise en œuvre. Eclipse A Spring IDE Bien que Spring mette à disposition d intéressants mécanismes afin d améliorer l architecture des applications Java EE en se fondant sur l injection de dépendances et la programmation orientée

Plus en détail

Modélisation des processus métiers et standardisation

Modélisation des processus métiers et standardisation Modélisation des processus métiers et standardisation Octobre 2004 Table des matières Introduction... 3 Processus métier : un même mot, plusieurs domaines d application... 4 Les critères pour un standard

Plus en détail

Module Génie Logiciel à Objet

Module Génie Logiciel à Objet Module Génie Logiciel à Objet Chapitre 1 - Introduction Mohamed Bakhouya - Benoît Delahaye Université Internationale de Rabat - Université de Nantes Remerciements Pascal André Gerson Sunyé 2013 Jacques

Plus en détail

Noureddine Kerzazi noureddine.kerzazi@polymtl.ca

Noureddine Kerzazi noureddine.kerzazi@polymtl.ca Domaine de la modélisation des processus pour le génie logiciel. Noureddine Kerzazi noureddine.kerzazi@polymtl.ca DSL4SPM Domain-Specific-Language for Software Process Modeling Il s agit d un nouveau cadre

Plus en détail

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes

Plus en détail

Cours de Génie Logiciel

Cours de Génie Logiciel Cours de Génie Logiciel Sciences-U Lyon MDE Model Driven Engineering http://www.rzo.free.fr Pierre PARREND 1 Mai 2005 Sommaire MDE : principe MDE et le génie logiciel MDE et UML MDE et les Design Patterns

Plus en détail

Modèles de composants

Modèles de composants Master 2 Recherche Informatique Université de Bretagne Occidentale 2008-2009 Modèles de composants Nassima Saididj Encadrant : M. Beugnard 29 janvier 2009 1 Résumé L ingénierie des composants est une discipline

Plus en détail

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Architecture d'entreprise : Guide Pratique de l'architecture Logique Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam

Plus en détail

Nom de l application

Nom de l application Ministère de l Enseignement Supérieur et de la Recherche Scientifique Direction Générale des Etudes Technologiques Institut Supérieur des Etudes Technologiques de Gafsa Département Technologies de l Informatique

Plus en détail

SDL: 20 ans de programmation basée modèle

SDL: 20 ans de programmation basée modèle SDL: 20 ans de programmation basée modèle Emmanuel Gaudin emmanuel.gaudin @ pragmadev.com Principes MDE, MDA et MDD: Approche orienté modèle PIM: Platform Independant Model PDM: Platform Definition Model

Plus en détail

Patrons de Conception (Design Patterns)

Patrons de Conception (Design Patterns) Patrons de Conception (Design Patterns) Introduction 1 Motivation Il est difficile de développer des logiciels efficaces, robustes, extensibles et réutilisables Il est essentiel de comprendre les techniques

Plus en détail

Le génie logiciel. maintenance de logiciels.

Le génie logiciel. maintenance de logiciels. Le génie logiciel Définition de l IEEE (IEEE 1990): L application d une approche systématique, disciplinée et quantifiable pour le développement, l opération et la maintenance de logiciels. Introduction

Plus en détail

Les serveurs applicatifs et les architectures Java

Les serveurs applicatifs et les architectures Java 03 Lucas Part 02 Page 179 Lundi, 20. août 2001 2:58 14 Chapitre 15 Les serveurs applicatifs et les architectures Java Nous avons vu jusqu ici, dans les chapitres précédents, que les utilisateurs accèdent

Plus en détail

Software Design (Guide to the SWEBOK)

Software Design (Guide to the SWEBOK) Software Design (Guide to the SWEBOK) Slide 1 Guy Tremblay Dépt. d informatique UQAM MIG8500 Hiver 2002 Aperçu 1. Qu est-ce que le Software Design? 2. Comme le SD Knowledge Area du guide est-il organisé?

Plus en détail

Chapitre I : le langage UML et le processus unifié

Chapitre I : le langage UML et le processus unifié I. Introduction Les méthodes d analyse orientées objet sont initialement issues des milieux industriels. La préoccupation dominante de leurs auteurs est le génie logiciel, c est-àdire les principes et

Plus en détail

CORBA. (Common Request Broker Architecture)

CORBA. (Common Request Broker Architecture) CORBA (Common Request Broker Architecture) Projet MIAGe Toulouse Groupe 2 1 CORBA, introduction (1/4) Les systèmes répartis permettent de créer des applications basées sur des composants auto-gérables,

Plus en détail

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation Un peu d'organisation Conception et Programmation par Objets HLIN406 Marianne Huchard, Clémentine Nebut LIRMM / Université de Montpellier 2 Premières semaines Contrôle des connaissances Supports 2015 Sommaire

Plus en détail

INTRODUCTION À JAVA EE. Cours Master 2 - Java EE

INTRODUCTION À JAVA EE. Cours Master 2 - Java EE INTRODUCTION À JAVA EE 1 LA NÉBULEUSE JAVA Java Micro Edition (JME) développement d applications embarquées Java Standard Edition (JSE) développement d applications classiques Java Enterprise Edition (JEE)

Plus en détail

ADELFE : Atelier de développement de logiciels à fonctionnalité émergente

ADELFE : Atelier de développement de logiciels à fonctionnalité émergente ADELFE : Atelier de développement de logiciels à fonctionnalité émergente Gauthier Picard*, Carole Bernon*, Valérie Camps**, Marie- Pierre Gleizes* * Institut de Recherche en Informatique de Toulouse Université

Plus en détail

Service combinators for farming virtual machines

Service combinators for farming virtual machines Master d Informatique Fondamentale École Normale Supérieure de Lyon Sémantique du parallélisme Chantal Keller Service combinators for farming virtual machines K. Bhargavan, A. D. Gordon, I. Narasamdya

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

Programmation orientée domaine pour les services télécoms: Concepts, DSL et outillage

Programmation orientée domaine pour les services télécoms: Concepts, DSL et outillage Programmation orientée domaine pour les services télécoms: Concepts, DSL et outillage Areski Flissi Gilles Vanwormhoudt LIFL/CNRS (UMR 8022) Institut TELECOM 59655 Villeneuve d Ascq 59655 Villeneuve d

Plus en détail

Module B9-1 : sensibilisation à l UML

Module B9-1 : sensibilisation à l UML Module B9-1 : sensibilisation à l UML Session 5 : Conception et adaptation à l entreprise Olivier Habart : habart.olivier@gmail.com ENSTA B9-1 UML (Olivier Habart) Novembre 14 Diapositive N 1 Session 5

Plus en détail

Ingénierie des Modèles. Introduction Générale

Ingénierie des Modèles. Introduction Générale Ingénierie des Modèles Introduction Générale Eric Cariou Master Technologies de l'internet 2 ème année Université de Pau et des Pays de l'adour UFR Sciences Pau Département Informatique Eric.Cariou@univ-pau.fr

Plus en détail

Cours en ligne Développement Java pour le web

Cours en ligne Développement Java pour le web Cours en ligne Développement Java pour le web We TrainFrance info@wetrainfrance Programme général du cours Développement Java pour le web Module 1 - Programmation J2ee A) Bases de programmation Java Unité

Plus en détail

Paroles d expert. ITIL V3, accélérateur de la stratégie de services

Paroles d expert. ITIL V3, accélérateur de la stratégie de services 33 3 3 3 ITIL V3, accélérateur de la stratégie de Dans le référentiel ITIL V2, les ouvrages Business Perspective, Plan to Implement, et ceux traitant des processus eux-mêmes, ont, à divers degrés, abordé

Plus en détail

Vers une formalisation du métamodèle de composants Ugatze

Vers une formalisation du métamodèle de composants Ugatze Vers une formalisation du métamodèle de composants Ugatze Mourad Kmimech I,III, Mohamed Tahar Bhiri II, Philippe Aniorté I, Abdelmajid Ben Hamadou III I LIUPPA, IUT de Bayonne - Département Informatique

Plus en détail

Sujet de thèse CIFRE RESULIS / LGI2P

Sujet de thèse CIFRE RESULIS / LGI2P Ecole des Mines d Alès Laboratoire de Génie Informatique et d Ingénierie de Production LGI2P Nîmes Sujet de thèse CIFRE RESULIS / LGI2P Titre Domaine De l ingénierie des besoins à l ingénierie des exigences

Plus en détail

Testing : A Roadmap. Mary Jean Harrold. Présentation de Olivier Tissot

Testing : A Roadmap. Mary Jean Harrold. Présentation de Olivier Tissot Testing : A Roadmap Mary Jean Harrold Présentation de Olivier Tissot Testing : A Roadmap I. L auteur II. Introduction sur les test : les enjeux, la problématique III. Les tests : roadmap IV. Conclusion

Plus en détail

Aperçu général sur la technologie des Workflows

Aperçu général sur la technologie des Workflows Aperçu général sur la technologie des Workflows Zakaria Maamar Groupe Interfonctionnement Section Technologie des systèmes d'information Centre de recherches pour la défense Valcartier 2459 boul. Pie-XI

Plus en détail

Le Processus Unifié appliqué au projet MOOCS

Le Processus Unifié appliqué au projet MOOCS Le Processus Unifié appliqué au projet MOOCS Violaine Louvet GTN, 7 mai 2003, Orsay Le Processus Unifie applique au projet MOOCS p. 1 L objet Objet = entité regroupant des données (attributs) et des services

Plus en détail

Conception déclarative et Validation de Systèmes d information

Conception déclarative et Validation de Systèmes d information Proposition de sujet de Master Conception déclarative et Validation de Systèmes d information Résumé : De nombreux systèmes d information (SI) sont distribués sur le net, et font appel à des composants

Plus en détail

Modélisation objet Le langage UML

Modélisation objet Le langage UML Modélisation objet Le langage UML Brahim HAMID La base de contrôle Robot Zone à explorer brahim.hamid@irit.fr brahim.hamid@univ-tlse2.fr http://mass-cara.univ-tlse2.fr/~brahimou/ens/uml 1 Les méthodes

Plus en détail

Système de Gestion de Contenus d entreprises

Système de Gestion de Contenus d entreprises Système de Gestion de Contenus d entreprises OUDJOUDI Idir, H.HOCINI Hatem. Centre de développement des technologies avancées Cité 20 Août Baba Hassan Alger Algérie Tél. 0(213)351040, Fax : 0(213)351039

Plus en détail

Méthodologie de Développement Objet

Méthodologie de Développement Objet 1/47 Méthodologie de Développement Objet Troisième partie : Ingénierie des Modèles Christine Solnon INSA de Lyon - 4IF 2014-2015 2/47 Introduction Automatiser la production de logiciels? Saint Graal du

Plus en détail

Spécification du profil UML d assemblage cible EJB (version 1)

Spécification du profil UML d assemblage cible EJB (version 1) Spécification du profil UML d assemblage cible EJB (version 1) Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti) Référence : Livrable 2.2 Date : 31 mai 2002

Plus en détail

*4D, quand c est la solution qui compte. 4D démocratise les services Web

*4D, quand c est la solution qui compte. 4D démocratise les services Web *4D, quand c est la solution qui compte. 4D démocratise les services Web Table des matières I. INTRODUCTION page 3 II. VERS UNE DEFINITION DES SERVICES WEB 1. Qu est ce que c est? page 3 2. A quoi ça sert?

Plus en détail

Tamago: Une plateforme pour des comportements

Tamago: Une plateforme pour des comportements Tamago: Une plateforme pour des comportements d agent sûre Séminaire DESIR Hakim Belhaouari Encadrant: Frederic Peschanski Laboratoire d Informatique de Paris 6 & UMPC Paris Universitas Equipe SMA 18 février

Plus en détail

Conduite de projets et architecture logicielle

Conduite de projets et architecture logicielle s et architecture logicielle ABCHIR Mohammed-Amine Université Paris 8 15 février 2011 1/36 ABCHIR Mohammed-Amine (Université Paris 8) Conduite de projets et architecture logicielle 15 février 2011 1 /

Plus en détail

Évaluation et implémentation des langages

Évaluation et implémentation des langages Évaluation et implémentation des langages Les langages de programmation et le processus de programmation Critères de conception et d évaluation des langages de programmation Les fondations de l implémentation

Plus en détail

Approche dirigée par les modèles pour la spécification, la vérification formelle et la mise en œuvre des services Web composés

Approche dirigée par les modèles pour la spécification, la vérification formelle et la mise en œuvre des services Web composés Approche dirigée par les modèles pour la spécification, la vérification formelle et la mise en œuvre des services Web composés Christophe Dumez Laboratoire Systèmes et Transports (SeT) Université de Technologie

Plus en détail

Typologie du logiciel. Typologie du logiciel. Ordinateur? ORDINATEUR. Computer = Hardware + Software. Ordinateur = Matériel + Logiciel

Typologie du logiciel. Typologie du logiciel. Ordinateur? ORDINATEUR. Computer = Hardware + Software. Ordinateur = Matériel + Logiciel Architecture Logicielle des Systèmes d Information (ALSI) Ordinateur? ORDINATEUR MATERIEL Computer = Hardware + Software Septembre 2010 Sources: GJL, Wikipédia,, Internet Ordinateur = Matériel + Logiciel

Plus en détail

Modélisation Principe Autre principe

Modélisation Principe Autre principe Modélisation Principe : un modèle est une abstraction permettant de mieux comprendre un objet complexe (bâtiment, économie, atmosphère, cellule, logiciel, ). Autre principe : un petit dessin vaut mieux

Plus en détail

Workflow et Service Oriented Architecture (SOA)

Workflow et Service Oriented Architecture (SOA) White Paper Workflow et Service Oriented Architecture (SOA) Présentation Cet article offre une approche pragmatique de la SOA et du workflow à travers des problématiques d'entreprises, une méthodologie

Plus en détail

Customisation Rhapsody et Henri BOULOUET DITV/AEEV/EECH. approche méthodologique

Customisation Rhapsody et Henri BOULOUET DITV/AEEV/EECH. approche méthodologique Customisation Rhapsody et approche méthodologique Retour d expérience sur l implémentation d un langage et profil UML associé 1 Sommaire Principe d un développement méthodologique Evocation d ISR (Ingénierie

Plus en détail

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1 Génie logiciel Concepts fondamentaux Bruno MERMET, Université du Havre 1 Nécessité du Génie Logiciel Bruno MERMET, Université du Havre 2 Développement d un logiciel Caractéristiques souhaitées : Adéquation

Plus en détail

Sujet de thèse CIFRE RESULIS / LGI2P

Sujet de thèse CIFRE RESULIS / LGI2P Ecole des Mines d Alès Laboratoire de Génie Informatique et d Ingénierie de Production LGI2P Nîmes Sujet de thèse CIFRE RESULIS / LGI2P Titre Domaine De l ingénierie des besoins à l ingénierie des exigences

Plus en détail

IFT2251 Introduction au génie logiciel Plan de cours. 2. Description du cours et objectifs généraux

IFT2251 Introduction au génie logiciel Plan de cours. 2. Description du cours et objectifs généraux IFT2251 Introduction au génie logiciel Plan de cours Été 2008 Yann-Gaël Guéhéneuc 1. Introduction Les exigences et les attentes à l égard de la qualité logicielle sont de plus en plus grandes. La taille

Plus en détail

Processus de développement UP

Processus de développement UP Chapitre 1 Processus de développement UP I. Pourquoi UP? II. Définition III. Activités et phases IV. Modèles mis en place 1. Pourquoi UP? Les notions de base acquises dans le module ACOO1, notamment la

Plus en détail

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009 GPA 789 : Analyse et Conception Orientées Objet ETS Mickaël Gardoni Bureau A 3588 tel 84 11 Mise en œuvre UML 1/ 25 Introduction Mise en œuvre d UML UML n est pas une méthode 2/ 25 1 UML n est qu un langage

Plus en détail

Architectures logicielles pour les systèmes embarqués temps réel

Architectures logicielles pour les systèmes embarqués temps réel ETR 07 4 septembre 2007 Architectures logicielles pour les systèmes embarqués temps réel Jean-Philippe Babau, Julien DeAntoni jean-philippe.babau@insa-lyon.fr 1/31 Plan Architectures logicielles pour les

Plus en détail

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information. PACBASE «Interrogez le passé, il répondra présent.». Le Module e-business Les entreprises doivent aujourd hui relever un triple défi. D une part, elles ne peuvent faire table rase de la richesse contenue

Plus en détail

Un autre modèle de relation d association pour améliorer la réutilisation de composants de

Un autre modèle de relation d association pour améliorer la réutilisation de composants de Eric Mendizabal Université de Montpellier II DEA d Informatique Année 2002 / 2003 - Mémoire de DEA Un autre modèle de relation d association pour améliorer la réutilisation de composants de modèles UML

Plus en détail

Une méthodologie de conception des systèmes distribués basée sur UML

Une méthodologie de conception des systèmes distribués basée sur UML Une méthodologie de conception des systèmes distribués basée sur UML Nouvelles Technologies de la Répartition (NOTERE 2005) 1 er septembre 2005 Ludovic Apvrille Pierre de Saqui-Sannes Axelle Apvrille Page

Plus en détail

AADL. un langage pour la modélisation et la génération d applications. Thomas Vergnaud, thomas.vergnaud@enst.fr

AADL. un langage pour la modélisation et la génération d applications. Thomas Vergnaud, thomas.vergnaud@enst.fr AADL un langage pour la modélisation et la génération d applications, thomas.vergnaud@enst.fr Les langages de description d architecture la conception des systèmes devient complexe difficulté de compréhension

Plus en détail

Types d applications pour la persistance. Outils de développement. Base de données préexistante? 3 modèles. Variantes avec passerelles

Types d applications pour la persistance. Outils de développement. Base de données préexistante? 3 modèles. Variantes avec passerelles Types d applications pour la persistance Université de Nice Sophia-Antipolis Version 0.9 28/8/07 Richard Grin Toutes les applications n ont pas une complexité qui nécessite une architecture n- tiers Ce

Plus en détail

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

GÉNIE LOGICIEL (SOFTWARE ENGINEERING) GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 5ÈME PARTIE UML (UNIFIED MODELING LANGUAGE) Faculté des Sciences et Techniques http://labh-curien.univ-st-etienne.fr/~fj/gl Francois.Jacquenet@univ-st-etienne.fr Plan

Plus en détail

Configuration et Déploiement d Applications Réparties par Intégration de l Hétérogénéité des Implémentations dans un Langage de Description d

Configuration et Déploiement d Applications Réparties par Intégration de l Hétérogénéité des Implémentations dans un Langage de Description d Configuration et Déploiement d Applications Réparties par Intégration de l Hétérogénéité des Implémentations dans un Langage de Description d Architecture Doctorant: Directeurs de thèse: Bechir ZALILA

Plus en détail

Direction Générale des Études Technologiques. Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique

Direction Générale des Études Technologiques. Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique Direction Générale des Études Technologiques Institut Supérieur des Etudes Technologiques de Djerba Département Technologies de l informatique Génie Logiciel Mejdi BLAGHGI m.blaghgi@gmail.com Chapitre

Plus en détail

IFT2251 : Génie logiciel

IFT2251 : Génie logiciel 4.1. Introduction à UML IFT2251 : Génie logiciel 1. Approches de développement 2. Introduction à UML (une méthodologie basée sur l approche orientée aspect) 3. Rappel de quelques concepts objets Chapitre

Plus en détail

Les transactions étendues et quelques Frameworks qui les supportent.

Les transactions étendues et quelques Frameworks qui les supportent. Les transactions étendues et quelques Frameworks qui les supportent. Christophe Ponsen cponsen@info.fundp.ac.be Institut d Informatique, Université de Namur Résumé Les transactions étendues posent de nombreux

Plus en détail

Design patterns par la pratique

Design patterns par la pratique Alan SHALLOWAY James TROTT Design patterns par la pratique Groupe Eyrolles, 2002 ISBN : 2-212-11139 Table des matières Préface.................................................... XV SECTION I Introduction

Plus en détail

Méthodes d évolution de modèle produit dans les systèmes du type PLM

Méthodes d évolution de modèle produit dans les systèmes du type PLM Résumé de thèse étendu Méthodes d évolution de modèle produit dans les systèmes du type PLM Seyed Hamedreza IZADPANAH Table des matières 1. Introduction...2 2. Approche «Ingénierie Dirigée par les Modèles»

Plus en détail

Architecture à base de composants pour le déploiement adaptatif des applications multicomposants

Architecture à base de composants pour le déploiement adaptatif des applications multicomposants Architecture à base de composants pour le déploiement adaptatif des applications multicomposants Dhouha Ayed, Chantal Taconet, et Guy Bernard GET / INT, CNRS Samovar 5157 9 rue Charles Fourier 91011 Évry,

Plus en détail

Aide à la conception de Système d Information Collaboratif, support de l interopérabilité des entreprises

Aide à la conception de Système d Information Collaboratif, support de l interopérabilité des entreprises Aide à la conception de Système d Information Collaboratif, support de l interopérabilité des entreprises Jihed Touzi, Frédérick Bénaben, Hervé Pingaud Thèse soutenue au Centre de Génie Industriel - 9

Plus en détail

Conception et développement d applications avec OpenCCM

Conception et développement d applications avec OpenCCM * CE * URE Conception et développement d applications avec OpenCCM RNRT * * Philippe.Merle@lifl.fr Equipe GOAL Laboratoire d Informatique Fondamentale de Lille Revue finale CESURE, Marseille, 18 décembre

Plus en détail

XML, PMML, SOAP. Rapport. EPITA SCIA Promo 2004 16 janvier 2003. Julien Lemoine Alexandre Thibault Nicolas Wiest-Million

XML, PMML, SOAP. Rapport. EPITA SCIA Promo 2004 16 janvier 2003. Julien Lemoine Alexandre Thibault Nicolas Wiest-Million XML, PMML, SOAP Rapport EPITA SCIA Promo 2004 16 janvier 2003 Julien Lemoine Alexandre Thibault Nicolas Wiest-Million i TABLE DES MATIÈRES Table des matières 1 XML 1 1.1 Présentation de XML.................................

Plus en détail

COURS MGL 804 SUJET : ÉVALUATION DE LA MAINTENABILITÉ DES PRODUITS LOGICIELS DU CCI RAPPORT FINAL. Franklin Kamsong

COURS MGL 804 SUJET : ÉVALUATION DE LA MAINTENABILITÉ DES PRODUITS LOGICIELS DU CCI RAPPORT FINAL. Franklin Kamsong COURS MGL 804 SUJET : ÉVALUATION DE LA MAINTENABILITÉ DES PRODUITS LOGICIELS DU CCI RAPPORT FINAL Franklin Kamsong ÉCOLE DE TECHNOLOGIE SUPÉRIEURE UNIVERSITÉ DU QUÉBEC MONTRÉAL HIVER 2012 TABLE DES MATIÈRES

Plus en détail

Rational Unified Process

Rational Unified Process Rational Unified Process For Christiane DAVOINE-GUHUR Société GICAB - Vannes Christiane.Davoine@CA-GICAB.fr Table des Matières 1 INTRODUCTION... 1 2 LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS...

Plus en détail

Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech

Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech Projets Logiciels: Processus de développement pratiqué à TELECOM ParisTech INF380-2013! Sylvie.Vignes@telecomParistech.fr Département INFRES, groupe S3 Cadre du processus 2! q Basé sur un processus incrémental:

Plus en détail

SECTION 5 BANQUE DE PROJETS

SECTION 5 BANQUE DE PROJETS SECTION 5 BANQUE DE PROJETS INF 4018 BANQUE DE PROJETS - 1 - Banque de projets PROJET 2.1 : APPLICATION LOGICIELLE... 3 PROJET 2.2 : SITE WEB SÉMANTIQUE AVEC XML... 5 PROJET 2.3 : E-LEARNING ET FORMATION

Plus en détail

G en om3: Building middleware-independent robotic components. Comparaison de middleware: YARP, MS Robotics Dev Studio, URBI, OpenRTM-aist, ROS

G en om3: Building middleware-independent robotic components. Comparaison de middleware: YARP, MS Robotics Dev Studio, URBI, OpenRTM-aist, ROS G en om3: Building middleware-independent robotic components Comparaison de middleware: YARP, MS Robotics Dev Studio, URBI, OpenRTM-aist, ROS Pablo Rauzy 15 février 2011 Table des matières 1 G en om3 :

Plus en détail

FILIÈRE METHODOLOGIE & PROJET

FILIÈRE METHODOLOGIE & PROJET FILIÈRE METHODOLOGIE & PROJET 109 Gestion de projet METHODOLOGIE ET PROJET Durée 3 jours Conduite de projet COND-PRO s Intégrer les conditions de réussite d une démarche de management par projet. Impliquer

Plus en détail