Patrons d architecture des Systèmes d Information

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

Download "Patrons d architecture des Systèmes d Information"

Transcription

1 P7 : Projet Bibliographique Dans le cadre du Mastère ASIG Patrons d architecture des Systèmes d Information Serveur Base de données Clients Mortier Mélanie 15 mai 2008 Mastère ASIG / Projet bibliographique

2 TABLE DES MATIERES INTRODUCTION 7 1 ARCHITECTURE D UN SYSTEME D INFORMATION NIVEAU PROCESSUS / ARCHITECTURE METIER NIVEAU FONCTIONNEL / ARCHITECTURE FONCTIONNELLE NIVEAU APPLICATIF / ARCHITECTURE APPLICATIVE NIVEAU TECHNIQUE / ARCHITECTURE TECHNIQUE 9 2 QU EST-CE QU UN PATRON D ARCHITECTURE? DIFFERENCIER LE PATRON D ARCHITECTURE DU PATRON DE CONCEPTION L UTILITE DES PATRONS D ARCHITECTURE LES DIFFICULTES LIEES A LA DESCRIPTION DES PATRONS D ARCHITECTURE 13 3 LES DIFFERENTES CLASSIFICATIONS DES PATRONS D ARCHITECTURE LES STYLES ARCHITECTURAUX LA CLASSIFICATION PAR «VUES» Définitions Les différentes «vues» La «vue en couche» La «vue des flux de données» La «vue centrée sur les données» La «vue adaptation» La «vue interface utilisateur» La «vue interaction entre composants» LE TRIPLET PROBLEME/CONTEXTE/SOLUTION Un exemple de classification suivant 4 catégories de problèmes La description d un patron d architecture suivant le triplet problème/contexte/solution LA CLASSIFICATION PAR LES QUALITES DES SYSTEMES 22 4 LES PATRONS D ARCHITECTURE FREQUEMMENT UTILISES POUR LES SIG LES PATRONS D ARCHITECTURE DANS LES SIG «Architecture en couches» «Pipes & Filtres» et «batch séquentiel» 28 CONCLUSION 30 Mastère ASIG / Projet bibliographique

3 TABLE DES ILLUSTRATIONS FIGURE 1 : LES QUATRE NIVEAUX D ABSTRACTION DES SI 8 FIGURE 2 : ARCHITECTURE EN COUCHES («LAYERS») 25 FIGURE 3 : PATRON CLIENT SERVEUR 27 FIGURE 4 : PATRON ARCHITECTURE 3TIERS 28 FIGURE 5 : PATRON PIPES ET FILTRES 29 Mastère ASIG / Projet bibliographique

4 GLOSSAIRE ET SIGLES UTILES MVC Model View Controller PAC Présentation Abstraction Contrôle SI Système d Information SIG Système d Information Géographique SEI Software Engineering Institute QAW Quality Attribute Workshop ATAM Architecture Trade-off Analysis Method POSA Pattern-Oriented Software Architecture BDD Base de données O.O. Orienté Objet OS Operating System Mastère ASIG / Projet bibliographique

5 REMERCIEMENTS Remerciement à Mr Olivier Boudeville du département SINETICS de chez EDF recherche et développement pour ses conseils concernant les choix bibliographiques autour de ce sujet. Egalement remerciement au centre de documentation de l ENSG, plus particulièrement à Mme Anne-Marie Ancel pour m avoir aidé à trouver les ouvrages dont j avais besoin. Mastère ASIG / Projet bibliographique

6 RESUME Il est question dans ce rapport des patrons d architecture utilisés pour les systèmes d information en général et pour les systèmes d information géographique en particulier. Nous verrons les problématiques associées à l étude des patrons d architecture. Ceci nous amènera à considérer l utilité de ces patrons pour choisir une architecture appropriée pour son système d information. Cela se traduit notamment par l étude des qualités associées aux patrons d architecture. Ensuite nous aborderons les différentes classifications des patrons d architecture. Pour finir, nous décrirons les patrons d architecture les plus utilisés dans le domaine du SIG. Mots-clés : patrons d architecture, système d information, système d information géographique, qualité. Mastère ASIG / Projet bibliographique

7 INTRODUCTION Ce rapport vient concrétiser un projet bibliographique dans le cadre du mastère architecture des systèmes d information géographique. Nous avons choisi de présenter une étude des patrons d architecture des systèmes d information (SI) en général et ceux des SIG en particulier. Cette étude devrait être approfondie. Ce sujet bien qu étudié plus fréquemment dans les filières informatiques trouve également une place dans le monde des SIG. En effet, n oublions pas que les systèmes d information géographique (SIG) sont un type particulier de SI, permettant de manipuler, gérer, mettre à jour de l information géographique. Mastère ASIG / Projet bibliographique

8 1 ARCHITECTURE D UN SYSTEME D INFORMATION Nous nous intéressons ici à l architecture logicielle des systèmes d information. L architecture logicielle décrit de manière symbolique les composants du SI et les relations entre ces différents composants. Avant de parler de patrons d architecture, il est intéressant de situer à quel niveau d abstraction du système d information ces derniers se situent. En effet, il existe plusieurs niveaux d abstraction dans un SI que nous décrirons brièvement : le niveau processus, le niveau fonctionnel, le niveau applicatif et enfin le niveau technique. Figure 1 : Les quatre niveaux d abstraction des SI SOURCE : Mastère ASIG / Projet bibliographique

9 1.1 NIVEAU PROCESSUS / ARCHITECTURE METIER L architecture métier décrit la distribution (cartographie) des processus métiers de l entreprise pris en charge par le SI sur des composants de type applications ainsi que les interactions entre les différents composants. Il existe plusieurs standards de modélisations pour décrire ces processus métiers dont le Business Process Reengineering (BPR) et le Business Process Management (BPM) entre autre. Nous ne verrons pas ces différentes modélisations ici, car ce n est pas le sujet de cette étude. Un architecte métier doit connaître les processus métiers de l entreprise, ses aspects organisationnels et stratégiques, connaître les besoins fonctionnels et non fonctionnels des acteurs de l entreprise, vis-à-vis du SI, et enfin, maîtriser les règles d urbanisme des SI. Voici un exemple de processus pour une banque : gestion des comptes par Internet. 1.2 NIVEAU FONCTIONNEL / ARCHITECTURE FONCTIONNELLE L architecture fonctionnelle décrit les blocs fonctionnels et leurs points d échanges. Les processus sont projetés sur des fonctions qui aident à réaliser ces processus. L exemple précédent peut se traduire en terme de fonctionnalités: gérer les comptes, gérer les sessions, gérer les périphériques d impression 1.3 NIVEAU APPLICATIF / ARCHITECTURE APPLICATIVE L architecture applicative permet de réaliser l architecture fonctionnelle. Les fonctions sont projetées sur des applications. A ce niveau d abstraction on peut envisager d utiliser l outil de modélisation UML. 1.4 NIVEAU TECHNIQUE / ARCHITECTURE TECHNIQUE C est le niveau d abstraction qui nous intéresse car c est ici qu on évoque les patrons d architecture. L architecture technique permet de réaliser l architecture applicative. L objectif est de décrire les types de systèmes à mettre en place et comment réaliser l intégration de ces systèmes. Mastère ASIG / Projet bibliographique

10 Un architecte technique doit connaître pour choisir une architecture : Les besoins fonctionnels définis par l architecture métier Les besoins non fonctionnels du SI (ou qualités recherchées) Les techniques de développement et maîtriser les techniques d intégration d applications. Mastère ASIG / Projet bibliographique

11 2 QU EST-CE QU UN PATRON D ARCHITECTURE? 2.1 DIFFERENCIER LE PATRON D ARCHITECTURE DU PATRON DE CONCEPTION L étude des patrons d architecture est une discipline qui est encore en évolution. La distinction entre la notion de patron d architecture (architectural pattern) et de patron de conception (design pattern) est parfois difficile à établir. Ceci d autant plus que certains patrons d architecture peuvent être déclinés en patrons de conception. Dans [3], une définition distincte pour chacune de ces notions est proposée : «An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.» «A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context.» Deux autres définitions tirées de la «software engineering radio» vont également dans ce sens: «Architectural Patterns are concerned with strategic aspects of a system. They have a global impact on the whole implementation of a system.» «Design Patterns are concerned with technical aspects of an implementation. They have a local impact on specific parts of the implementation of a system.» «Architectural Patterns are on a higher level of abstraction than Design Patterns.» Ce que nous pouvons dégager de ces définitions c est que les patrons de conception (design patterns) sont plus proches de préoccupations locales liées à l implémentation du SI (codes) que ne le sont les patrons d architecture (architectural pattern). Les patrons de conception sont présentés comme indépendants d un langage de programmation ou de modèles de programmation. Les patrons d architecture se situent à un niveau plus élevé d abstraction. Mastère ASIG / Projet bibliographique

12 Les patrons d architecture décrivent l organisation du SI en donnant les sous-systèmes qui le composent, ainsi que les relations entre ces sous-systèmes, leurs responsabilités, et inclus un ensemble de règles et de modèles à suivre pour organiser les relations entre elles. 2.2 L UTILITE DES PATRONS D ARCHITECTURE L idée pour un patron d architecture est de décrire une architecture de système qui a déjà fait ses preuves pour résoudre un problème dans un contexte particulier. Pour décrire ce patron il est nécessaire d utiliser un vocabulaire de base commun, qui puisse être compris de manière non ambiguë par les architectes des SI, il en va de même pour sa représentation graphique. Cependant, comme nous l avons évoqué plus haut, l étude des patrons d architecture est encore récente et aucune formalisation officielle n a été fournie aux architectes. A l heure actuelle, il existe parfois plusieurs termes pour désigner un même patron d architecture et, plus gênant, il n existe pas encore de vocabulaire et de représentation officiels uniques pour les patrons malgré des efforts d unification réalisés depuis les années Nous reparlerons des difficultés liées à la description des patrons d architecture dans la section suivante. Le but d un patron d architecture est de permettre aux architectes expérimentés de réutiliser des architectures connues, qui ont été validées par l expérience. En effet, avec la complexité croissante des systèmes et le besoin de les faire évoluer, les architectes des systèmes d information ont de manière informelle commencé à structurer leurs systèmes et à utiliser des termes génériques pour désigner des architectures déjà largement utilisées. Avec un vocabulaire unifié et des représentations graphiques communes, les architectes peuvent partager leurs idées concernant leur architecture SI et sur celles d autres architectes, qui auront pris la peine de documenter leur système. Le but étant pour les architectes expérimentés et les architectes en formation de se comprendre. Les patrons ont donc un rôle important dans la construction de nouveaux systèmes d information, ils permettent de ne pas tout réinventer mais au contraire de s inspirer de Mastère ASIG / Projet bibliographique

13 modèles d architectures devenus courants. Il reste alors au soin de l architecte qui a choisi un patron d architecture de l adapter à son problème particulier en suivant les grands principes du patron. 2.3 LES DIFFICULTES LIEES A LA DESCRIPTION DES PATRONS D ARCHITECTURE La jungle des descriptions des patrons d architecture demande au novice un apprentissage du vocabulaire qui n est pas standardisé. De plus, il existe quelques méthodes qui proposent une validation du choix du patron d architecture, mais elles ne sont pas officielles et restent marginales face aux choix d architecture par des ingénieurs architectes expérimentés. La difficulté majeure reste donc que plusieurs «écoles» subsistent et proposent leur classification des patrons d architectures suivant différentes philosophies et avec différentes représentations : Pour certains ils peuvent être regroupés en styles architecturaux et définis par une approche composants/connecteurs ; Pour d autres les patrons d architecture doivent être définis comme un triplet problème/contexte/solution ; Certains préfèrent les associer à des «vues» ; Et récemment des essais pour les classer suivant leurs qualités ont été menés. Nous allons maintenant voir les classifications évoquées ci-dessus ainsi que les définitions des patrons d architecture classés suivant les différentes écoles. Nous nous intéresserons plus particulièrement à la classification des patrons d architectures par les qualités recherchées dans les SI car ces qualités détermineront la pertinence du choix du patron par rapport à un autre. Mastère ASIG / Projet bibliographique

14 Nous remarquerons qu il existe d autres classifications des patrons d architecture, mais nous ne les donnerons pas toutes. Mastère ASIG / Projet bibliographique

15 3 LES DIFFERENTES CLASSIFICATIONS DES PATRONS D ARCHITECTURE Nous avons choisi de présenter quatre classifications de patrons d architecture. Et nous verrons également quels patrons d architecture s y inscrivent. Il existe de nombreuses classifications des patrons d architecture car il n en existe pas d officielle. Nous en avons quatre pour avoir un aperçu de la complexité de ce sujet en gardant à l esprit qu il faudrait plus de temps pour cerner les tenants et aboutissants des patrons d architecture. Cependant, rappelons que tous les patrons d architecture existants ne sont pas recensés dans ce rapport. De plus, nous parlons ici de patrons d architecture «purs», alors que dans les systèmes d information il est possible que plusieurs patrons coexistent. Il faudrait alors étudier les différentes combinaisons de patrons réalisables et voir si nous pouvons les classer à leur tour, si la classification s y prête... Les deux premières classifications sont plus orientées sur les solutions proposées. Les deux suivantes tentent d accorder leur attention à la solution mais également aux problèmes auxquels doivent répondre les patrons d architecture. Chaque classification à des avantages et des inconvénients. Certaines sont plus répandues et donnent une idée organisée des patrons existants, d autres sont nouvelles mais tentent d introduire une validation dans le choix du SI, d autres encore se placent d un point de vue particulier. Mastère ASIG / Projet bibliographique

16 3.1 LES STYLES ARCHITECTURAUX Cette classification est assez répandue. Elle fait appel à UML pour représenter ses patrons. Elle définit les patrons d architecture en terme de composants et de connecteurs, ces derniers reliant les composants entre eux. Voici une liste non exhaustive de styles architecturaux: Style flux de données : avec les patrons «pipes & filtres» et «batch séquentiel». Style requête-réponse ou aussi appelé «call and return» avec les patrons «décomposition fonctionnelle» ou «décomposition en programme principal et subroutines», «architecture O.O.» et «architecture en couches» dont le «Client Serveur». Style composants indépendants avec les «systèmes évènementiels» et «processus communicants». Style centrés sur les données : «hypertext system», «blackboards». Un style architectural définit un vocabulaire de composants, de types de connecteurs et met en place des contraintes sur la manière dont ils doivent être assemblés. Pour beaucoup de styles il peut exister un ou plusieurs «modèles sémantiques» qui spécifient comment déterminer les propriétés d ensemble du système à partir des propriétés de ses parties. 3.2 LA CLASSIFICATION PAR «VUES» Définitions Une «vue architecturale» est une représentation qui comprend des éléments du système et les relations entre les divers éléments. Nous verrons quels peuvent être ses éléments. Le «point de vue» permet de communiquer les vues sans ambiguïté grâce à la description des types d éléments et de relations, ainsi qu à des informations sur les données. Mastère ASIG / Projet bibliographique

17 Une «vue» peut être désignée comme une instance d un «point de vue» pour un système particulier, car les éléments et les relations contenues dans la «vue» sont des instances de types correspondants d éléments et de relations contenus dans le «point de vue». Une «vue» porte ses préoccupations sur un aspect précis du système que ce soit les interfaces, les flux de données, les adaptations possibles pour le système Un patron d architecture définit également des éléments et des relations qui sont organisés pour résoudre un problème particulier sous une certaine perspective. En fait, un patron d architecture peut être considéré comme une spécialisation d un «point de vue» dans la mesure où il propose une sémantique spécifique pour les types d éléments et les relations qui le composent, tout en leur posant des contraintes. Voyons comment les patrons d architecture peuvent s associer aux «vues». Là encore il existe plusieurs approches. Nous choisissons d exposer l une de ces approches. Ici, chaque patron d architecture est associé à une vue primaire. Mais il existe des cas où un même patron peut être utilisé dans une seconde ou troisième vue. Par exemple quand deux patrons d architecture issus de différentes vues sont combinés dans un même système, ces patrons peuvent être aperçus dans chaque vue. Les vues que nous reprenons contiennent deux types d éléments : les composants et les connecteurs entre les différents composants, comme pour les styles architecturaux. Mais dans d autres vues, d autres types d éléments peuvent être introduits. Les premières vues que nous présentons sont proches des styles architecturaux, mais des différences surviennent assez vite comme nous pouvons le constater Les différentes «vues» La «vue en couche» La «vue en couches» s intéresse à la façon dont un système complexe peut être décomposé en parties ou couches qui interagissent entre elles. On compte dans les patterns architecturaux de cette vue : le patron des «systèmes en couches», et celui des «couches unidirectionnelles». Mastère ASIG / Projet bibliographique

18 Les préoccupations de cette vue sont de savoir comment les différentes parties (couches) peuvent rester indépendantes tout en travaillant ensemble et bien sûr comment les qualités sont-elles supportées dans cette vue La «vue des flux de données» La «vue des flux de données» traite de comment un flux de données est successivement traité et transformé par ses composants. Les patrons associés sont les «pipes et filtres» ainsi que le «batch séquentiel». Les préoccupations de cette vue sont les suivantes : quels sont les éléments qui réalisent les transformations, quels sont les éléments qui portent les flux de données, comment ces éléments sont connectés, comment les attributs de qualités sont-ils supportés? Les éléments qui réalisent les transformations sont des composants indépendants qui ont des données en entrée et en sortie. Les éléments qui portent les flux de données sont les connecteurs, qui ont eux aussi des données en entrée et en sortie La «vue centrée sur les données» La «vue centrée sur les données» est appropriée quand l intérêt se porte sur comment une base de données centrale est accessible par différents composants. Les patrons concernés sont les «repositories» et «blackboards». Les préoccupations de cette vue sont comment les données sont partagées, accessibles et mises à jour. Comment les données sont distribuées, si le stockage est actif ou passif, les éléments qui accèdent aux données communiquent-ils entre eux directement ou par l intermédiaire des données partagées? La base de données et les éléments qui y accèdent sont des composants. La base de données est indépendante des composants et les composants entre eux sont généralement indépendants. Il peut y avoir plusieurs bases de données La «vue adaptation» La «vue adaptation» traite de comment s adapte un système pendant son évolution avec les patrons «microkernel», «reflection» et «interceptor». Dans la vue adaptation le système est perçu comme un noyau invariable et une partie modifiable/adaptable qui peut changer au cours du temps suivant les différentes versions du système. Mastère ASIG / Projet bibliographique

19 La «vue interface utilisateur» La «vue interface utilisateur» montre la structure des composants qui offrent une interface à l usager. Les patrons de cette vue sont le «Model View Controller» ou MVC, «présentation/abstraction/contrôle» et «C2» La «vue interaction entre composants» La «vue interaction entre composants» s oriente sur comment les composants individuels échangent des messages mais conservent leur autonomie. Les patrons évoqués sont «l invocation explicite» aussi appelée «processus communicants», «l invocation implicite» aussi appelée «système évènementiel», le «Client Serveur», le «PEER-TO- PEER». Il existe encore d autres vues moins utilisées. Nous ne les évoquerons donc pas ici. 3.3 LE TRIPLET PROBLEME/CONTEXTE/SOLUTION Un exemple de classification suivant 4 catégories de problèmes Dans cette classification, la description d un patron d architecture est présentée comme un couple problème/solution qui dépend d un contexte. Le patron doit répondre à une attente, autrement dit à un problème particulier. Il est important de bien identifier les problèmes pour en dégager les besoins et d y apporter les solutions adaptées. Au fur et à mesure, l analyse doit devenir de plus en plus fine pour aboutir à une solution technique. De part l attachement à l analyse des problèmes et de leur solution, le patron choisi sera «validé» pour répondre au problème. Pour classer les patrons d architecture suivant cette philosophie problème/contexte/solution, nous devons définir des catégories de problèmes, ces quatre catégories sont reprises de [3] : Structurer le système : comment décomposer le système en parties qui vont coopérer? On compte pour résoudre ce problème les patrons d architecture en «couches», les «pipes et filtres» et le patron «blackboard». Mastère ASIG / Projet bibliographique

20 Le patron en «couches» aide à structurer les applications qui peuvent être décomposées en groupes de sous tâches dans lesquels chaque groupe de sous tâches fait parti d un niveau d abstraction particulier. Un exemple du patron en couches bien connu est celui des protocoles réseaux avec ses sept couches (physique, liaison, réseau, transport, session, présentation et application) Le patron «pipes & filtres» offre une structure pour les systèmes qui traitent des flux de données. Chaque étape du traitement du flux de données est encapsulée dans un filtre. Le patron «blackboard» est utilisé lorsqu aucune stratégie de solution déterminée n est connue. Dans le «blackboard» plusieurs sous systèmes spécialisés assemblent leurs connaissances pour construire une solution partielle ou approximée. Ce patron est notamment utilisé dans la reconnaissance d image. Systèmes distribués : pour les systèmes qui ont des composants placés dans différents processus ou dans plusieurs sous-systèmes et composants. Les patrons relatifs à cette catégorie sont les patrons «broker», «pipes et filtres» et «microkernel», client serveur, reactor. Le patron «microkernel» est intéressant pour des systèmes qui requièrent des évolutions, des changements. Un cœur fonctionnel minimal est séparé de fonctionnalités supplémentaires et de parties spécifiques du système. Le patron «microkernel» a été développé pour concevoir de petits OS et leurs extensions avec de nouveaux services. Le patron «broker» peut être utilisé pour les structures distribuées avec des composants découplés qui interagissent par «remote service invocations». Un composant «broker» est responsable de la coordination de la communication, de la transmission des erreurs et des exceptions Systèmes interactifs : pour les systèmes qui demandent une interaction avec l humain en désirant conserver le cœur fonctionnel indépendant de l interface utilisateur. Le but pour ses systèmes est de permettre de changer l interface sans affecter les applications du système. On utilise les patrons «Model View Controller» MVC et «Présentation Abstraction Control» PAC pour ses systèmes. Mastère ASIG / Projet bibliographique

21 Le patron «MVC» partage une application en trois composants. Le composant «model» contient les fonctionnalités centrales ainsi que les données. Le composant «view» donne les informations à l utilisateur et le composant «controller» se charge de contrôler les entrées données par l utilisateur. L ensemble «view» et «controller» représente l interface. Ces deux parties doivent garder une cohérence lorsque l interface est modifiée. Le patron «PAC» défini une architecture sous la forme d une hiérarchie d agents coopérants. Chaque agent est en charge d un aspect d une fonctionnalité et est composé de trois composants : la présentation, l abstraction et le contrôle. Cette décomposition sépare les aspects de l interaction humain-ordinateur de l agent de son cœur fonctionnel et sa communication avec d autres agents. Les librairies Smalltalk utilisent ce patron d architecture. Systèmes adaptables : pour les systèmes qui doivent prévoir des évolutions, adaptations de leurs applications on parlera des patrons «microkernel» et «reflection». Le patron «reflection» offre un mécanisme pour faire changer la structure et le comportement d une architecture logicielle dynamiquement. Il supporte des modifications d aspects fondamentaux, comme les mécanismes de fonction d appel. Dans ce patron une application est divisée en deux parties. Une partie fournit des informations concernant les propriétés du système sélectionné et rend le logiciel conscient de lui-même (méta niveau). L autre partie comprend la logique de l application (niveau de base). Cette classification est incomplète car si l on rajoute de nouveaux patrons d architecture il faudra sans doute rajouter des catégories de problèmes La description d un patron d architecture suivant le triplet problème/contexte/solution Nous allons ici décrire de manière simplifiée le patron d architecture «layers» ou en «couches». Contexte : On a un système complexe qui doit être décomposé. Mastère ASIG / Projet bibliographique

22 Problème : Nous avons un système qui est caractérisé par des applications, fonctionnalités de hauts et bas niveaux. Les applications de haut niveau s appuient sur celles de bas niveau. Nous voulons que des changements dans une couche n aient pas de répercussion sur le système entier. Les parties/couches du système doivent pouvoir être remplacées sans affecter le système entier. Les composants complexes doivent être re-décomposés. Les responsabilités similaires doivent être groupées pour aider à la compréhension du système et sa maintenabilité Solution : Il faut structurer le système en un nombre approprié de couches et commencer par la couche de plus bas niveau. Ce sera la couche 1, la base du système. Puis on continue avec la couche de niveau supérieur jusqu à la couche de niveau supérieur N. Les services rendus par la couche J sont composés en partie des services de la couche J-1, c'est-à-dire que les services de la couche J dépendent de la couche J-1. Nous remarquerons que le problème a été simplifié par mes soins et que la solution ne dit pas comment faire les couches, ni si telle ou telle couche sera complexe 3.4 LA CLASSIFICATION PAR LES QUALITES DES SYSTEMES Cette classification prend appui sur le modèle du couple «problème/solution» évoqué précédemment en ajoutant une notion de qualités recherchées. Le problème et la solution s expriment par des besoins fonctionnels et non fonctionnels. Un besoin fonctionnel doit répondre à une fonctionnalité exprimée durant la phase de l analyse métier, tandis qu un besoin non fonctionnel correspond à des qualités que l on peut associer soit au système en général ou plus précisément à chacune des fonctionnalités. Parmi ces qualités on compte : La robustesse : le système donne-t-il des résultats similaires si l on modifie un peu ses paramètres? La performance : le système doit répondre à des critères de performance (temps de réponse, ressources utilisées). On peut parler de performance en terme de temps ou de place utilisée. La flexibilité : le système a-t-il la possibilité d évoluer facilement, les efforts pour le modifier devront-ils être importants? La portabilité : le système peut-il être intégré dans un autre environnement facilement? Mastère ASIG / Projet bibliographique

23 La sécurité : quel niveau de sécurité doit être mis en place pour protéger les données du SI? On remarquera que ce besoin peut également être assimilé à un besoin fonctionnel. L'interopérabilité : le SI a-t-il la capacité à communiquer et à utiliser les ressources de systèmes extérieurs? La compatibilité exprime la possibilité, pour un SI, de fonctionner correctement dans un environnement ancien (compatibilité descendante) ou plus récent (compatibilité ascendante). La validité exprime la conformité des fonctionnalités du SI avec celles décrites dans le cahier des charges. La vérifiabilité exprime la simplicité de vérification de la validité. L'intégrité exprime la faculté du SI à protéger ses fonctionnalités et ses données d'accès non autorisés. La fiabilité : le SI est-il en mesure de gérer ses erreurs de fonctionnement pendant l exécution? La maintenabilité exprime la simplicité de correction et de modification du SI. La réutilisabilité exprime la capacité de concevoir le SI avec des composants existants tout en permettant la réutilisation simple de ses propres composants pour le développement d'autres SI. L'efficacité exprime la capacité du SI à exploiter au mieux ses ressources. La transparence exprime la capacité pour un SI de masquer à l'utilisateur (humain ou machine) les détails inutiles à l'utilisation de ses fonctionnalités. La simplicité d'utilisation ou aussi l ergonomie décrit la facilité d'apprentissage et d'utilisation du SI par les usagers. On peut encore trouver d autres qualités, mais nous ne les décrirons pas toutes ici. Rajoutons que le système doit bien évidemment remplir les fonctionnalités métiers. Pour évaluer l importance de ces qualités pour le choix du SI, des buts peuvent être assignés pour chaque qualité et fonctionnalité désirée avec une priorité : élevée, moyenne ou faible. Cela permet de guider le choix d une solution suivant les besoins non fonctionnels. Les priorités sont déterminées par des experts au moyen des votes ou des consensus. «Un patron décrit à la fois un problème qui se produit très fréquemment dans votre environnement et l architecture de la solution à ce problème de telle façon que vous Mastère ASIG / Projet bibliographique

24 puissiez utiliser cette solution des milliers de fois sans jamais l adapter deux fois de la même manière» C. Alexander La validation d un patron d architecture consistera alors à prouver que : La solution préserve le comportement décrit et désiré pour répondre à la partie problème. La solution doit respecter les qualités désirées spécifiées au préalable. Ainsi les architectures en couches permettent la réutilisabilité des «layers» pour d autres systèmes d information et également de pouvoir changer une couche sans devoir changer le reste du SI. Donc la maintenabilité, la réutilisabilité et la flexibilité comptent parmi les qualités de ce patron d architecture. Par contre la performance est amoindrie car le système doit communiquer entre les couches, vérifier des messages, retransmettre les éventuelles erreurs. Cette classification est à faire. Mastère ASIG / Projet bibliographique

25 4 LES PATRONS D ARCHITECTURE FREQUEMMENT UTILISES POUR LES SIG Dans cette partie nous allons décrire les patrons d architecture les plus utilisés dans le domaine des SIG ainsi que pour des exemples de systèmes d information bien connus. 4.1 LES PATRONS D ARCHITECTURE DANS LES SIG «Architecture en couches» Ce type de système est organisé de manière hiérarchique, chaque couche effectue un service pour la couche de dessus et sert de client pour la couche de dessous. Dans certains systèmes les couches intérieures sont cachées de toutes les couches sauf des couches adjacentes. Les connecteurs sont les protocoles qui déterminent la façon dont les couches interagissent. Exemple : Protocoles de communication en couches pour des systèmes de base de données et OS. Figure 2 : Architecture en couches («layers») Mastère ASIG / Projet bibliographique

26 Avantages de ce patron d architecture: Possibilité de partitionner un problème en une séquence incrémentale de niveau d abstraction (couche). L amélioration : chaque couche interagit avec deux autres couches, le changement d une fonction d une couche affectera au maximum deux couches (comme pipes). La réutilisabilité : différentes implémentations d une même couche pourvu qu elles supportent la même interface aux couches adjacentes. Cela mène à la possibilité de définir des couches d interfaces standards. OSI ISO modèle et X Window System Protocols. Inconvénients : Difficultés à structurer le problème en couches d abstraction. Et même si on peut structurer logiquement en couches pour des raisons de performance on peut être obligé de rapprocher les couches. Difficultés de trouver les bons niveaux d abstraction en particulier pour les modèles standardisés. Difficulté à définir les protocoles de communication en OSI ISO parce que de nombreux protocoles font le pont entre plusieurs couches. Exemple de l architecture Client Serveur Cette architecture a été évoquée dans la classification par «vues» («vue interaction entre composants») mais aussi dans la classification par style architectural comme un exemple de patrons pour les «systèmes en couches». Cette architecture est classiquement utilisée dans les SIG pour permettre à plusieurs utilisateurs : les clients, d accéder à une base de données (BDD) commune. Les accès à la BDD sont gérés par le serveur. Mastère ASIG / Projet bibliographique

27 Figure 3 : Patron client serveur Cette architecture est utilisée quand deux types de composants différents ont besoin de communiquer. Ces composants sont indépendants les uns des autres. Les composants de ce patron d architecture sont le client et le serveur. La base de données dans cette architecture deux couches ou 2-Tiers est incluse dans le serveur. Le client initialise la communication pour demander un service au serveur. Le serveur est à l écoute du/des client(s) et doit être capable de répondre à plusieurs clients. Il existe également des architectures 3-Tiers. Cette architecture est similaire à l architecture «client serveur» si ce n est que le client demande à un serveur d application une requête, le serveur d application joue alors le rôle de client pour le serveur de base de données. Mastère ASIG / Projet bibliographique

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

RAPPORT DE CONCEPTION UML :

RAPPORT DE CONCEPTION UML : Carlo Abi Chahine Sylvain Archenault Yves Houpert Martine Wang RAPPORT DE CONCEPTION UML : Bamboo Ch@t Projet GM4 Juin 2006 Table des matières 1 Introduction 2 2 Présentation du logiciel 3 2.1 Précisions

Plus en détail

Modélisation des Systèmes d Information Jean-Yves Antoine

Modélisation des Systèmes d Information Jean-Yves Antoine Modélisation des Systèmes d Information Jean-Yves Antoine http://www.info.univ-tours.fr/~antoine Processus de développement logiciel Jean-Yves Antoine U. Bretagne Sud - UFR SSI - IUP Vannes année 2001-2002

Plus en détail

En informatique et en particulier en génie logiciel, la qualité logicielle est une appréciation globale d'un logiciel, basée sur de nombreux

En informatique et en particulier en génie logiciel, la qualité logicielle est une appréciation globale d'un logiciel, basée sur de nombreux Introduction En informatique et en particulier en génie logiciel, la qualité logicielle est une appréciation globale d'un logiciel, basée sur de nombreux indicateurs 1. La complétude des fonctionnalités,

Plus en détail

Brique BDL Gestion de Projet Logiciel

Brique BDL Gestion de Projet Logiciel Brique BDL Gestion de Projet Logiciel Processus de développement pratiqué à l'enst Sylvie.Vignes@enst.fr url:http://www.infres.enst.fr/~vignes/bdl Poly: Computer elective project F.Gasperoni Brique BDL

Plus en détail

Systèmes d Information Avancés (et répartis)

Systèmes d Information Avancés (et répartis) Systèmes d Information Avancés (et répartis) Université Lyon 1 MIAGE L. Médini, mars 2005 Plan des cours Protocole HTTP et programmation serveur Architectures réparties Objets distribués Introduction aux

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

Université de Bangui. Modélisons en UML

Université de Bangui. Modélisons en UML Université de Bangui CRM Modélisons en UML Ce cours a été possible grâce à l initiative d Apollinaire MOLAYE qui m a contacté pour vous faire bénéficier de mes connaissances en nouvelles technologies et

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

Merise. Introduction

Merise. Introduction Merise Introduction MERISE:= Méthode d Etude et de Réalisation Informatique pour les Systèmes d Entreprise Méthode d Analyse et de Conception : Analyse: Etude du problème Etudier le système existant Comprendre

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

L approche Bases de données

L approche Bases de données L approche Bases de données Cours: BD. Avancées Année: 2005/2006 Par: Dr B. Belattar (Univ. Batna Algérie) I- : Mise à niveau 1 Cours: BDD. Année: 2013/2014 Ens. S. MEDILEH (Univ. El-Oued) L approche Base

Plus en détail

Design Patterns. Pourquoi utiliser des patterns? Pourquoi utiliser des patterns? Les patterns vue de loin. D où viennent les design patterns?

Design Patterns. Pourquoi utiliser des patterns? Pourquoi utiliser des patterns? Les patterns vue de loin. D où viennent les design patterns? Noël NOVELLI ; Université de la Méditerranée ; LIF et Département d Informatique Case 901 ; 163 avenue de Luminy 13 288 MARSEILLE cedex 9 Design Patterns D où viennent les design patterns? D où viennent

Plus en détail

Use Cases. Introduction

Use Cases. Introduction Use Cases Introduction Avant d aborder la définition et la conception des UC il est bon de positionner le concept du UC au sein du processus de développement. Le Processus de développement utilisé ici

Plus en détail

Bienvenue dans le monde de la construction logicielle

Bienvenue dans le monde de la construction logicielle Chapitre 1 Bienvenue dans le monde de la construction logicielle Sommaire : 1.1 La construction logicielle, qu est-ce que c est? : page 3 1.2 Pourquoi la construction logicielle est-elle importante? :

Plus en détail

Talend Technical Note

Talend Technical Note Mars 2011 Page 1 sur 5 Le MDM offre un hub central de contrôle et une vision unique des données maître de l'entreprise, quelles que soient les disparités entre les systèmes source. Il assure que les données

Plus en détail

COMMENT DÉFINIR L ORIENTÉ OBJET

COMMENT DÉFINIR L ORIENTÉ OBJET COMMENT DÉFINIR L ORIENTÉ OBJET De manière superficielle, le terme «orienté objet», signifie que l on organise le logiciel comme une collection d objets dissociés comprenant à la fois une structure de

Plus en détail

1. Introduction. 2. Diagramme des exigences

1. Introduction. 2. Diagramme des exigences 1. Introduction La complexité des systèmes techniques est telle que, sans outils de représentations abstraites et progressivement enrichies, les intervenants d un projet auraient de nombreuses difficultés

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

PG208, Projet n 3 : Serveur HTTP évolué

PG208, Projet n 3 : Serveur HTTP évolué PG208, Projet n 3 : Serveur HTTP évolué Bertrand LE GAL, Serge BOUTER et Clément VUCHENER Filière électronique 2 eme année - Année universitaire 2011-2012 1 Introduction 1.1 Objectif du projet L objectif

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

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

Cours CCNA 1. Exercices

Cours CCNA 1. Exercices Cours CCNA 1 TD3 Exercices Exercice 1 Enumérez les sept étapes du processus consistant à convertir les communications de l utilisateur en données. 1. L utilisateur entre les données via une interface matérielle.

Plus en détail

Développement itératif, évolutif et agile

Développement itératif, évolutif et agile Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie

Plus en détail

Gé nié Logiciél Livré Blanc

Gé nié Logiciél Livré Blanc Gé nié Logiciél Livré Blanc Version 0.2 26 Octobre 2011 Xavier Blanc Xavier.Blanc@labri.fr Partie I : Les Bases Sans donner des définitions trop rigoureuses, il faut bien commencer ce livre par énoncer

Plus en détail

REseau qualité Enseignement supérieur et Recherche L APPROCHE PROCESSUS. Réunion du 00/00/2011 1

REseau qualité Enseignement supérieur et Recherche L APPROCHE PROCESSUS. Réunion du 00/00/2011 1 L APPROCHE PROCESSUS Réunion du 00/00/2011 1 MISSION QUALITE ET METHODE L APPROCHE PROCESSUS Xavier Darrieutort-Approche_PS-Janv_2012 L APPROCHE PROCESSUS 1. SOMMAIRE Définition d un PROCESSUS Caractérisation

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

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

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

Méthodologies de développement de logiciels de gestion

Méthodologies de développement de logiciels de gestion Méthodologies de développement de logiciels de gestion Chapitre 5 Traits caractéristiques des deux approches de méthodologie Présentation réalisée par P.-A. Sunier Professeur à la HE-Arc de Neuchâtel http://lgl.isnetne.ch

Plus en détail

Annexe 4 Programmes des classes préparatoires aux Grandes Ecoles

Annexe 4 Programmes des classes préparatoires aux Grandes Ecoles Annexe 4 Programmes des classes préparatoires aux Grandes Ecoles Filière : scientifique Voie : Technologie et biologie (TB) Discipline : Informatique Première et seconde années Programme d informatique

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

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes FICHE JANVIER 2009 THÉMATIQUE Direction de projets et programmes La représentation par les processus pour les projets Système d Information (SI) La modélisation de l'entreprise par les processus devient

Plus en détail

Management des processus opérationnels

Management des processus opérationnels Ecole Nationale Supérieure de Management Master Management des organisations Management des processus opérationnels Dr TOUMI Djamila Cours n 4: l approche processus et le management du système d informations

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

<< Crédit Club Auto >>

<< Crédit Club Auto >> Abbas Ahmad Année 2010/2011 Matin Bayramov Analyse et Modélisation des Systèmes Informatique (AMSI) Projet de Modélisation UML > Professeur encadrant : M. GUILLAUME PAQUETTE Projet

Plus en détail

Résumé du document «Programmes des classes préparatoires aux Grandes Écoles ; Discipline : Informatique ; Première et seconde années - 2013»

Résumé du document «Programmes des classes préparatoires aux Grandes Écoles ; Discipline : Informatique ; Première et seconde années - 2013» Résumé du document «Programmes des classes préparatoires aux Grandes Écoles ; Discipline : Informatique ; Première et seconde années - 2013» I Objectifs Niveau fondamental : «on se fixe pour objectif la

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

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

SYSTEMES D INFORMATION & CONCEPTION de BdD

SYSTEMES D INFORMATION & CONCEPTION de BdD SYSTEMES D INFORMATION & CONCEPTION de BdD PLAN CONCEPT DE SYSTEME D INFORMATION MODELISATION D UN SYSTEME D INFORMATION MODELISATION CONCEPTUELLE : les METHODES METHODE SYSTEMIQUE METHODE OBJET L3 Informatique

Plus en détail

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude

INF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude INF 1250 INTRODUCTION AUX BASES DE DONNÉES Guide d étude Sous la direction de Olga Mariño Télé-université Montréal (Québec) 2011 INF 1250 Introduction aux bases de données 2 INTRODUCTION Le Guide d étude

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

Solutions de gestion de la sécurité Livre blanc

Solutions de gestion de la sécurité Livre blanc Solutions de gestion de la sécurité Livre blanc L intégration de la gestion des identités et des accès avec l authentification unique Objectif : Renforcer la politique de sécurité et améliorer la productivité

Plus en détail

Génie logiciel avec UML. Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique

Génie logiciel avec UML. Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique Génie logiciel avec UML Notions sur le langage UML adapté pour les cours du programme Techniques de l informatique Claude Boutet Session hiver 2008 Modélisation de systèmes Table des matières TABLE DES

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

BOSTONI Sacha NGUYEN Linh. Rapport de projet : Annuaire des anciens élèves

BOSTONI Sacha NGUYEN Linh. Rapport de projet : Annuaire des anciens élèves BOSTONI Sacha NGUYEN Linh Rapport de projet : Annuaire des anciens élèves Tuteur : Mr Muller Mai 2007 SOMMAIRE Introduction 1/ Les utilisateurs du site 2/ Les fonctionnalités 3/ La réalisation Conclusion

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

L INFORMATION GEOGRAPHIQUE

L INFORMATION GEOGRAPHIQUE Champs sur Marne ENSG/CERSIG Le 19-nove.-02 L INFORMATION GEOGRAPHIQUE Archivage Le Système d information géographique rassemble de l information afin de permettre son utilisation dans des applications

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

L SIO I N O 3 & & PE P R E S R PE P C E TIV I ES E

L SIO I N O 3 & & PE P R E S R PE P C E TIV I ES E INTRODUCTION SOMMAIRE 1 Modélisation de processus et Workflows 2 - Méthodes et outils pour la Modélisation de processus Workflows 3 Notions de flexibilité et d adaptabilité dans les WorkFlow CONCLUSION

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

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

INDUSTRIALISATION ET RATIONALISATION

INDUSTRIALISATION ET RATIONALISATION INDUSTRIALISATION ET RATIONALISATION A. LA PROBLEMATIQUE La mission de toute production informatique est de délivrer le service attendu par les utilisateurs. Ce service se compose de résultats de traitements

Plus en détail

Machine de Turing. Informatique II Algorithmique 1

Machine de Turing. Informatique II Algorithmique 1 Machine de Turing Nous avons vu qu un programme peut être considéré comme la décomposition de la tâche à réaliser en une séquence d instructions élémentaires (manipulant des données élémentaires) compréhensibles

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

Mise en œuvre des serveurs d application

Mise en œuvre des serveurs d application Nancy-Université Mise en œuvre des serveurs d application UE 203d Master 1 IST-IE Printemps 2008 Master 1 IST-IE : Mise en œuvre des serveurs d application 1/54 Ces transparents, ainsi que les énoncés

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

Les Bonnes PRATIQUES DU TEST LOGICIEL

Les Bonnes PRATIQUES DU TEST LOGICIEL Les Bonnes PRATIQUES DU TEST LOGICIEL SOMMAIRE Qu est-ce que le test logiciel? Pourquoi le test est-il un maillon crucial de l ingénierie logicielle? Quels sont les différents types de tests? Qu est-ce

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

DÉPLOIEMENT D UN ERP. Cours dispensé pour les L3 MSI Elaboré par : Mehdi M tir 2013/2014 Chapitre 3 : Modélisation des besoins

DÉPLOIEMENT D UN ERP. Cours dispensé pour les L3 MSI Elaboré par : Mehdi M tir 2013/2014 Chapitre 3 : Modélisation des besoins 1 DÉPLOIEMENT D UN ERP Cours dispensé pour les L3 MSI Elaboré par : Mehdi M tir 2013/2014 Chapitre 3 : Modélisation des besoins LA CONDUITE D UN PROJET ERP La conduite d un projet d ERP est différente

Plus en détail

Modèle Client-Serveur Partage du serveur entre clients

Modèle Client-Serveur Partage du serveur entre clients Modèle Client-Serveur Partage du serveur entre clients Un serveur peut servir plusieurs clients Vu d un client particulier client requête réponse serveur Vu du serveur Gestion des requêtes (priorité) Exécution

Plus en détail

EXTENSION de Microsoft Dynamics CRM 2013. Réf FR 80452

EXTENSION de Microsoft Dynamics CRM 2013. Réf FR 80452 EXTENSION de Microsoft Dynamics CRM 2013 Réf FR 80452 Durée : 3 jours A propos de ce cours : Ce cours offre une information interactive et détaillée sur le développement d extensions pour Microsoft Dynamics

Plus en détail

Référence Etnic Architecture des applications

Référence Etnic Architecture des applications Référence Etnic Architecture des applications Table des matières 1. Introduction... 2 2. Architecture... 2 2.1 Démarche générale... 2 2.2 Modèle d architecture... 3 2.3 Découpe d une architecture applicative...

Plus en détail

Didacticiel - Etudes de cas. Montrer l utilisation de la macro complémentaire TANAGRA.XLA dans le tableur EXCEL.

Didacticiel - Etudes de cas. Montrer l utilisation de la macro complémentaire TANAGRA.XLA dans le tableur EXCEL. Objectif Montrer l utilisation de la macro complémentaire TANAGRA.XLA dans le tableur EXCEL. De nombreux utilisateurs s appuient sur EXCEL pour la gestion de leurs données. C est un outil relativement

Plus en détail

JXDVDTek - UNE DVDTHEQUE EN JAVA ET XML

JXDVDTek - UNE DVDTHEQUE EN JAVA ET XML BALLOTE Nadia FRIULI Valerio GILARDI Mathieu IUT de Nice Licence Professionnelle des Métiers de l Informatique RAPPORT DU PROJET : JXDVDTek - UNE DVDTHEQUE EN JAVA ET XML Encadré par : M. CRESCENZO Pierre

Plus en détail

Evaluer des élèves de Seconde par compétences en Sciences Physiques

Evaluer des élèves de Seconde par compétences en Sciences Physiques Evaluer des élèves de Seconde par compétences en Sciences Physiques Introduction Depuis quelques années, le terme de «compétences» s installe peu à peu dans notre quotidien ; aussi bien dans la vie de

Plus en détail

2. Technique d analyse de la demande

2. Technique d analyse de la demande 1. Recevoir et analyser une requête du client 2. Sommaire 1.... Introduction 2.... Technique d analyse de la demande 2.1.... Classification 2.2.... Test 2.3.... Transmission 2.4.... Rapport 1. Introduction

Plus en détail

Personnaliser et adapter SPIP Développeur SPIP

Personnaliser et adapter SPIP Développeur SPIP Personnaliser et adapter SPIP Développeur SPIP En Théorie Le fonctionnement de SPIP Qu est ce que SPIP? SPIP (Système de Publication pour l Internet Partagé) est un logiciel libre destiné à la production

Plus en détail

Sylvain Archenault Yves Houpert. Projet Informatique : Langage Java : Jeu De Dames en Java

Sylvain Archenault Yves Houpert. Projet Informatique : Langage Java : Jeu De Dames en Java Sylvain Archenault Yves Houpert Projet Informatique : Langage Java : Jeu De Dames en Java Projet GM3 Mai 2005 Chapitre 1 INTRODUCTION Le projet qui nous a été confié est de réaliser un jeu de dames en

Plus en détail

A propos de PC MACLAN pour Windows 95

A propos de PC MACLAN pour Windows 95 About PC MACLAN for Windows 95 A propos de PC MACLAN pour Windows 95 Ce chapitre explique ce qu est un réseau, les éléments qui le composent et les fonctions uniques de PC MACLAN for Windows 95. Les sujets

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

ITIL V2 Processus : La Gestion des Configurations

ITIL V2 Processus : La Gestion des Configurations ITIL V2 Processus : La Gestion des Configurations Auteur: Fabian PIAU, Master 2 MIAGE, Nantes La Gestion des Configurations est un processus issu d ITIL version 2 qui aide au soutien du service («Service

Plus en détail

Digital Workplace et Gestion des connaissances Concepts et mise en oeuvre

Digital Workplace et Gestion des connaissances Concepts et mise en oeuvre Avant-propos 1. Objectif du livre 17 2. Illustrations des exemples de ce livre 18 2.1 Office 365 comme plateforme technologique pour une digital workplace 18 2.2 SharePoint et Yammer à l honneur 18 3.

Plus en détail

En 2000 l OMG propose une approche nommée MDA Model Driven Architecture, S appuyant sur le standard UML pour

En 2000 l OMG propose une approche nommée MDA Model Driven Architecture, S appuyant sur le standard UML pour MDA (Model Driven Architecture) Ingénierie logicielle guidée par les modèles S.N Historique: En 2000 l OMG propose une approche nommée MDA Model Driven Architecture, S appuyant sur le standard UML pour

Plus en détail

Programmation de services en téléphonie sur IP

Programmation de services en téléphonie sur IP Programmation de services en téléphonie sur IP Présentation de projet mémoire Grégory Estienne Sous la supervision du Dr. Luigi Logrippo Introduction La téléphonie sur IP comme support à la programmation

Plus en détail

OPTION CREATION D INTERIEURS

OPTION CREATION D INTERIEURS BACHELIER EN ARTS PLASTIQUES, VISUELS ET DE L ESPACE OPTION CREATION D INTERIEURS Les cours de «bachelor en arts plastiques, visuels et de l espace option création d intérieurs» sont susceptibles de se

Plus en détail

UNIVERSITE DE LORRAINE CALCIUM

UNIVERSITE DE LORRAINE CALCIUM UNIVERSITE DE LORRAINE CALCIUM Outil pour la gestion des dossiers médicaux des étudiants dans les services universitaires de médecine préventive Table des matières CALCIUM... 0 I. L INFORMATION GÉRÉE PAR

Plus en détail

Philosophie des extensions WordPress

Philosophie des extensions WordPress 8 Philosophie des extensions WordPress Le concept L une des forces de WordPress dans la jungle CMS, c est la simplicité de création d extensions. Il y a plusieurs raisons à cela. Des raisons techniques

Plus en détail

Logiciels serveurs et outils d'administration pour le Web

Logiciels serveurs et outils d'administration pour le Web Introduction Le World Wide Web ou WWW, littéralement «toile d'araignée mondiale», est un système d'informations ouvert qui a été conçu spécifiquement pour simplifier l'utilisation et l'échange de documents.

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

Processus d Informatisation

Processus d Informatisation Processus d Informatisation Cheminement de la naissance d un projet jusqu à son terme, deux grandes étapes : Recherche ou étude de faisabilité (en amont) L utilisateur a une idée (plus ou moins) floue

Plus en détail

Dossier de conception. Conception d un site E-learning

Dossier de conception. Conception d un site E-learning Conception d un site E-learning Encadré par : Mr. LACHGAR Mohamed Réalisé par : LECHQER Younesse ELEOUAD Abdelhadi SOMMAIRE I. PERIMETRE DU PROJET... 2 1.1. ENJEUX ET VISION DU PROJET... 3 1.2. ARCHITECTURE

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

Correction de l examen final

Correction de l examen final IFT3902 : (Gestion de projet pour le) développement, (et la) maintenance des logiciels Correction de l examen final Yann-Gaël Guéhéneuc, cours et TPs guehene@iro.umontreal.ca Salah Bouktif, démonstrations

Plus en détail

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe

Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe Guillaume SOLDERA (B guillaume.soldera@serli.fr) SERLI Informatique Bull OW2 Consortium dans le cadre du projet JASMINe Avril 2008 Table des matières 1 Introduction 3 1.1 Rappel sur JASMINe.......................................

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

SysML : les diagrammes

SysML : les diagrammes SysML : les diagrammes DIDIER FGNON, STÉPHNE GSTON [1] L outil SysML est un langage constitué de nombreux diagrammes. Nous vous proposons une ressource sous la forme de fiches-outils qui trouveront une

Plus en détail

Rappel sur les bases de données

Rappel sur les bases de données Rappel sur les bases de données 1) Généralités 1.1 Base de données et système de gestion de base de donnés: définitions Une base de données est un ensemble de données stockées de manière structurée permettant

Plus en détail

0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage. 3- Organisation du cours

0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage. 3- Organisation du cours 0- Le langage C++ 1- Du langage C au langage C++ 2- Quelques éléments sur le langage 3- Organisation du cours Le présent cours constitue une introduction pour situer le langage C++, beaucoup des concepts

Plus en détail

GED: Gestion Electronique de Document (Support de cours) R. MAHMOUDI (mahmoudr@esiee.fr) www.research-ace.net/~mahmoudi 1 Gestion Electronique de Documents Plan du cours - Introduction générale - Spécificités

Plus en détail

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS Méthode de tests MODE D EMPLOI Cette première partie est destinée à ceux qui débutent en tests et permet une approche progressive et simple de la méthodologie des tests. L introduction vous aura permis

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

Le client/serveur repose sur une communication d égal à égal entre les applications.

Le client/serveur repose sur une communication d égal à égal entre les applications. Table des matières LES PRINCIPES DE BASE... 1 Présentation distribuée-revamping...2 Présentation distante...3 Traitements distribués...3 données distantes-rd...4 données distribuées-rda distribué...4 L'ARCHITECTURE

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

Management des processus opérationnels

Management des processus opérationnels Ecole Nationale Supérieure de Management Master Management des organisations Management des processus opérationnels Dr TOUMI Djamila Cours n 1: La vision processus dans le management des organisations

Plus en détail

et dépannage de PC Configuration Sophie Lange Guide de formation avec exercices pratiques Préparation à la certification A+

et dépannage de PC Configuration Sophie Lange Guide de formation avec exercices pratiques Préparation à la certification A+ Guide de formation avec exercices pratiques Configuration et dépannage de PC Préparation à la certification A+ Sophie Lange Troisième édition : couvre Windows 2000, Windows XP et Windows Vista Les Guides

Plus en détail

Rapport de Projet Vincent Sallé - Steven Thillier - Jeremy Torres Le deviseur Cs2icar Cs2i 9 avril 2012

Rapport de Projet Vincent Sallé - Steven Thillier - Jeremy Torres Le deviseur Cs2icar Cs2i 9 avril 2012 Rapport de Projet Vincent Sallé - Steven Thillier - Jeremy Torres Le deviseur Cs2icar Cs2i 9 avril 2012 VS - ST - JT Adresse électronique : jrmy.torres@gmail.com Cs2i Sommaire Étude préalable 2 Contexte

Plus en détail

Chapitre 1. Introduction aux Bases de Données. Cours de Bases de Données. Polytech Paris-Sud. Chapitre 1 : Quelques questions

Chapitre 1. Introduction aux Bases de Données. Cours de Bases de Données. Polytech Paris-Sud. Chapitre 1 : Quelques questions Cours de Bases de Données Chapitre 1 Polytech Paris-Sud Sarah Cohen-Boulakia LRI, Bât 490, Université Paris-Sud 11, Orsay cohen @ lri. fr 01 69 15 32 16 Introduction aux Bases de Données 1 2 Chapitre 1

Plus en détail