Architecture matériel et logiciel 2

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

Download "Architecture matériel et logiciel 2"

Transcription

1 Architecture matériel et logiciel 2 Architectures Venera Arnaoudova

2 Concep8on architecturale 1. Introduc8on 2. Modéliser l architecture avec UML 3. Éléments architecturaux 4. Styles architecturaux 1. Architecture pipeline 2. Architecture avec référen8el de données 3. Architecture MVC 4. Architecture mul8 couches 5. Architecture n niveaux 5. Développer un modèle architectural 1/20/10 2

3 1. Introduc8on Qu est ce qu une architecture logicielle? L architecture d un logiciel est la structure des structures (modules) d un système Elle inclut Les composants logiciels Les propriétés externes visibles de ces composants Les rela8ons entre ces composants Cf. [Bass, Clements, and Kazman (1998) ] 1/20/10 3

4 Introduc8on Qu est que la descrip8on d une architecture logicielle? La défini8on de l architecture logicielle consiste à: Décrire l organisa8on générale d un système et sa décomposi8on en sous systèmes ou composants Déterminer les interfaces entre les sous systèmes Décrire les interac8ons et le flot de contrôle entre les sous systèmes Décrire également les composants u8lisés pour implanter les fonc8onnalités des sous systèmes Les propriétés de ces composants Leur contenu (e.g., classes, autres composants) Les machines ou disposi8fs matériels sur lesquels ces modules seront déployés 1/20/10 4

5 Introduc8on Pourquoi développer une architecture logicielle? Pour perme`re à tous de mieux comprendre le système Pour perme`re aux développeurs de travailler sur des par8es individuelles du système en isola8on Pour préparer les extensions du système Pour faciliter la réu8lisa8on et la réu8lisabilité 1/20/10 5

6 Introduc8on U8lité d une architecture logicielle [Garlan 2000] Compréhension : facilite la compréhension des grands systèmes complexes en donnant une vue de haut niveau de leur structure et de leurs contraintes. Les mo8va8ons des choix de concep8on sont ainsi mis en évidence Réu8lisa8on : favorise l iden8fica8on des éléments réu8lisables, par8es de concep8on, composants, caractéris8ques, fonc8ons ou données communes Construc8on : fournit un plan de haut niveau du développement et de l intégra8on des modules en me`ant en évidence les composants, les interac8ons et les dépendances 1/20/10 6

7 Introduc8on U8lité d une architecture logicielle [Garlan 2000] Évolu8on : met en évidence les points où un système peut être modifié et étendu. La sépara8on composant/connecteur facilite une implémenta8on du type «plug and play» Analyse : offre une base pour l analyse plus approfondie de la concep8on du logiciel, analyse de la cohérence, test de conformité, analyse des dépendances Ges8on : contribue à la ges8on générale du projet en perme`ant aux différentes personnes impliquées de voir comment les différents morceaux du casse tête seront agencés. L iden8fica8on des dépendances entre composants permet d iden8fier où les délais peuvent survenir et leur impact sur la planifica8on générale 1/20/10 7

8 Introduc8on D où vient l architecture? Décisions techniques Décision commerciaux De quoi dépendent les décisions de l architecte : Echéancier Type de système (ex. temps réel) Expérience 1/20/10 8

9 Introduc8on De quoi dépendent les décisions de l architecte (suite): Organisa8on (budget, forma8on des développeurs) Environnement technique Les architectures influencent les facteurs qui les influencent?! 1/20/10 9

10 Introduc8on Les par8es prenantes influencent l architecte : - Client (coût peu élevé, développement rapide, pas beaucoup de changements par la suite) - U8lisateur final (performance, sécurité, fiabilité, usabilité) - Développeur (facile à développer) - Chef de projet (coût peu élevé, développeurs occupés) - Développeurs qui main8ennent le logiciel (maintenance facile) 1/20/10 10

11 Introduc8on Propriétés prises en compte par l architecte: Performance Fiabilité Disponibilité Compa8bilité des plateformes U8lisa8on mémoire U8lisa8on réseau Sécurité Etc. 1/20/10 11

12 Introduc8on Ac8vités de l architecture logiciel: Créer les business cases du système évaluer le marché, es8mer un prix, temps visé, collabora8ons éventuelles avec d autre systèmes 1/20/10 12

13 Introduc8on Ac8vités de l architecture logiciel (suite): Comprendre les requis suivant le type du système, requis de qualité, réu8liser ou par8r de rien gamme de produits, prototypes Créer ou sélec8onner une architecture 1/20/10 13

14 Introduc8on Ac8vités de l architecture logiciel (suite): Communiquer l architecture aux par8e prenantes Evaluer l architecture Architecture Tradeoff Analysis Method (ATAM) Cost Benefit Analysis Method (CBAM) Implémenter l architecture Assurer la conformité à l architecture 1/20/10 14

15 2. Modéliser avec UML Les vues (structurelles) d une architecture logicielle Vue logique. Descrip8on logique du système décomposé en sous systèmes (modules + interface) UML : diagramme de paquetages Vue d implémenta8on. Descrip8on de l implémenta8on (physique) du système logiciel en termes de composants et de connecteurs UML : diagramme de composants Vue de déploiement. Descrip8on de l intégra8on et de la distribu8on de la par8e logicielle sur la par8e matérielle UML: diagramme combiné de composants et de déploiement 1/20/10 15

16 Rappel : vues d un système Diagramme de classes Diagramme de composants Diagramme combiné de déploiement/ composants Vue structurelle (modèle statique) Vue des cas d utilisation (modèle fonctionnel des exigences) Diagramme de packetages Diagramme de séquence interaction Vue du comportement et des interactions (modèle dynamique) Diagramme de cas d utilisation comportement Diagramme d états comportement Diagramme de communication interaction Diagramme d activités comportement 1/20/10 16

17 Modéliser l architecture avec UML Diagramme de paquetages 1/20/10 17

18 Modéliser l architecture avec UML Diagramme de composants 1/20/10 18

19 Modéliser l architecture avec UML Diagramme combiné de déploiement/ composants 1/20/10 19

20 3. Éléments architecturaux composant port connecteur dépendance Comp_A «realisation» interface requise Classe_C interface fournie Comp_B configuration Deux ou plusieurs composants interagissent via un connecteur Chaque élément architectural possède une structure et/ou comportement pouvant être décrit par un modèle UML approprié 1/20/10 20

21 Éléments architecturaux Composant compa Encapsule un traitement et/ou des données Encapsule un sous ensemble de fonc8onnalités et/ou de données du système Restreint l accès à ce sous ensemble au moyen d une interface définie explicitement Possède des dépendances explicitement définies pour exprimer les contraintes requises par son contexte d exécu8on ou sa réalisa8on 1/20/10 21

22 Éléments architecturaux Composant Unité autonome servant de bloc de construc8on pour le système Les composants implémentent typiquement des services spécifiques à l applica8on La manifesta8on concrète d un composant est appelé artéfact (instance du composant déployée sur le matériel) N importe quel type de code sur n importe quel support numérique Code source, fichiers binaires, scripts, fichiers exécutables, bases de données, applica8ons, etc. Order «manifestation» Order.jar 1/20/10 22

23 Éléments architecturaux Interface de composant Permet à un composant d exposer les moyens à u8liser pour communiquer avec lui Types d interfaces Interface offerte : définit la façon de demander l accès à un service offert par le composant Interface requise : définit le type de services (aide) requis par le composant Une interface est a`achée à un port du composant Port = point de communica8on du composant Plusieurs interfaces peuvent être a`achées à un même port 1/20/10 23

24 Éléments architecturaux Dépendances entre composants Dépendance = rela8on entre deux composants Types de dépendances Un composant peut dépendre d un autre composant qui lui fournit un service ou une informa8on Un composant peut dépendre d une classe qui implémente une par8e de son comportement. Dépendance de réalisa8on Un composant peut dépendre d un artefact (code source, fichier.jar, etc.) qui l implante concrètement. Dépendance de manifesta8on 1/20/10 24

25 Éléments architecturaux Connecteur Dans les systèmes complexes, les interac8ons peuvent cons8tuer un enjeu encore plus important que les fonc8onnalités des composants individuels Défini8on : élément architectural qui définit le type d interac8ons entre les composants et les règles gouvernant ces interac8ons Un connecteur relie les ports de deux ou plusieurs composants Un connecteur décrit un mécanisme de connec8on indépendant de l applica8on Représente un concept abstrait, paramétrable et indépendant des composants spécifiques qu il relie Les a`ributs du connecteurs décrivent ses propriétés comportementales E.g. sa capacité, le temps de latence, le type d interac8on (binaire/n aire, asymétrique/symétrique, détails du protocole), etc. 1/20/10 25

26 Éléments architecturaux Connecteur Un connecteur peut avoir un ou plusieurs rôles Communica8on :rôle le plus fréquent Coordina8on : contrôle du calcul, de la transmission des données, etc. Orthogonal aux autres rôles Conversion : permet l interac8on entre composants développés indépendamment dans des langages différents par exemple Facilita8on : permet l interac8on entre composants conçus pour interragir ensemble. Synchronisa8on, accès contrôlées aux données partagées, etc. Selon le(s) rôles qu il doit remplir et le type de communica8on souhaitée entre deux composants, choix d un type Procedure call (comm + coord), Data access (comm + conv), Event, Stream, Linkage, Distributor, Arbitrator, Adaptor (conv) 1/20/10 26

27 Éléments architecturaux Rôle Type de connecteur Attributs Valeurs d attributs 1/20/10 27 Software Architecture: Foundations, Theory, and Practice; R. N. Taylor, N. Medvidovic, and E. M. Dashofy; 2008 John Wiley & Sons, Inc.

28 Exemple d un diagramme de composants 1/20/10 28

29 Choix d une architecture Choix d une architecture Dépend des exigences fonc8onnelles et non fonc8onnelles du logiciel Choix favorisant la stabilité : l ajout de nouveaux éléments sera facile et ne nécessitera en général que des ajustements mineurs à l architecture Influencé par certains «modèles connus» de décomposi8on en composants (styles architecturaux) et de mode d interac8ons (e.g., orienté objet) 1/20/10 29

30 4. Style architecturaux Un style architectural Est un patron décrivant une architecture logicielle perme`ant de résoudre un problème par8culier Définit Un ensemble de composants et de connecteurs (et leur type) Les règles de configura8on des composants et connecteurs (topologie) Une spécifica8on du comportement du patron Des exemples de systèmes construits selon ce patron Cons8tue un modèle éprouvé et enrichi par l expérience de plusieurs développeurs Compréhensibilité, maintenance, évolu8on, réu8lisa8on, performance, documenta8on, etc. 1/20/10 30

31 Architecture pipeline Convient bien aux systèmes de traitement et de transforma8on de données Composants = filtre ; Connecteur = canal Filtre Traite indépendamment et asynchrone Reçoit ses données d un ou plusieurs canaux d entrée, effectue la transforma8on/traitement des données et envoie les données de sor8e produites sur un ou plusieurs canaux de sor8es Fonc8onnent en concurrence. Chacun traite les données au fur et mesure qu il les reçoit Canal Unidirec8onnel au travers duquel circulent un flot de données (stream). Synchronisa8on et u8lisa8on d un tampon parfois nécessaire pour assurer la bon fonc8onnement entre filtre producteur et filtre consommateur Exemples : applica8on de traitement de texte, de traitement de signaux. Compilateur (analyse lexicale, syntaxique, séman8que) canal de communication Filtre synchro 1/20/10 31

32 Architecture pipeline Système de traitement du son Encodeur pour sortie de microphone Filtrer l écho Filtrer le bruit Retirer les fréquences non vocales Égaliser les les intervalles dynamiques Encodeur de bruit ambiant Décompresser Recevoir Transmettre Compresser Encoder la sortie des haut-parleurs 1/20/10 32

33 Architecture pipeline Avantages Bon pour traitement en lot (batch) Très flexible Analyse facilitée : performance, synchronisa8on, goulot d étranglement, etc. Se prête bien à la décomposi8on fonc8onnelle d un système Inconvénients Mauvais pour le traitement interac8f D un point de vue concep8on Diviser pour régner : les filtres peuvent être conçus séparément Cohésion : les filtres sont un type de cohésion fonc8onnelle Couplage : les filtres n ont qu une entrée et une sor8e en général Abstrac8on : les filtres cachent généralement bien leurs détails internes Réu8lisabilité : les filtres peuvent très souvent être réu8lisés dans d autres contextes Réu8lisa8on : il est souvent possible d u8liser des filtres déjà existants pour les insérer dans le pipeline 1/20/10 33

34 Architecture avec référen8el de données (shared data) U8lisée dans le cas où des données sont partagées et fréquemment échangées entre les composants Deux types de composants : référen8el de données et accesseur de données Les référen8els cons8tuent le medium de communica8on entre les accesseurs Connecteur : relie un accesseur à un référen8el Rôle de communica8on, mais aussi possiblement de coordina8on, de conversion et de facilita8on Référentiel1 Référentiel2 A A A A A 1/20/10 34

35 Architecture avec référen8el Variantes Style tableau noir : les référen8els sont des agents ac8fs. Lorsqu ils reçoivent une données, ils informent tous les accesseurs concernés Style référen8el : les référen8els sont passifs. Simple voca8on de stockage. Les composants accèdent aux référen8els comme ils le désirent Exemples : applica8on de bases de données, systèmes Web, systèmes centrés sur les données (e.g. système bancaire, système de factura8on,etc.), environnement de programma8on 1/20/10 35

36 Architecture avec référen8el Environnement de programma8on Analyseur syntaxique Analyseur sémantique Optimiseur Compilateur Générateur de code Analyseur lexical Référentiel Arbre syntaxique Table de symboles Débogueur Éditeur syntaxique 1/20/10 36

37 Architecture avec référen8el Avantages Avantageux pour les applica8ons impliquant des tâches complexes sur les données, nombreuses et changeant souvent. Une fois le référen8el bien défini, de nouveaux services peuvent facilement être ajoutés Inconvénients Le référen8el peut facilement cons8tuer un goulot d étranglement, tant du point de vue de sa performance que du changement 1/20/10 37

38 Architecture Modèle Vue Contrôleur (MVC) Séparer la couche interface u8lisateur des autres par8es du système (car les interfaces u8lisateurs sont beaucoup plus suscep8bles de changer que la base de connaissances du système) Composé de trois types de composants Modèle : rassemble des données du domaine, des connaissances du système. Con8ent les classes dont les instances doivent être vues et manipulées Vue : u8lisé pour présenter/afficher les données du modèle dans l interface u8lisateur Contrôleur : con8ent les fonc8onnalités nécessaires pour gérer et contrôler les interac8ons de l u8lisateur avec la vue et le modèle 1/20/10 38

39 Architecture Modèle Vue Contrôleur Vus par les acteurs View E.g. Génère le code html pour le browser créer et mettre à jour E.g. Interprète les transmissions http «post» du browser Reçoit les événements des acteurs Consulter l état (i.e. les données) notifier changements Contrôleur Modèle modifier Le sous-système gérant l information. 1/20/10 39

40 Architecture Modèle Vue Contrôleur Modèle : noyau de l applica8on Enregistre les vues et les contrôleurs qui en dépendent No8fie les composants dépendants des modifica8ons aux données Vue : interface (graphique) de l applica8on Crée et ini8alise ses contrôleurs Affiche les informa8ons des8nées aux u8lisateurs Implante les procédure de mise à jour nécessaires pour demeurer cohérente Consulte les données du modèle Contrôleur : par8e de l applica8on qui prend les décisions Accepte les événement correspondant aux entrées de l u8lisateur Traduit un événements (1) en demande de service adressée au modèle ou bien (2) en demande d affichage adressée à la vue Implémente les procédures indirectes de mise à jour des vues si nécessaire 1/20/10 40

41 Architecture Modèle Vue Contrôleur Avantages : approprié pour les systèmes interac8fs, par8culièrement ceux impliquant plusieurs vues du même modèle de données. Peut être u8lisé pour faciliter la maintenance de la cohérence entre les données distribuées Inconvénient : goulot d étranglement possible D un point de vue concep8on Diviser pour régner : les composants peuvent être conçus indépendamment Cohésion : meilleure cohésion que si les couches vue et contrôle étaient dans l interface u8lisateur. Couplage : le nombre de canaux de communica8on entre les 3 composants est minimal Réu8lisabilité : la vue et le contrôle peuvent être conçus à par8r de composants déjà existants Flexibilité : il est facile de changer l interface u8lisateur Testabilité : il est possible de tester l applica8on indépendamment de l interface 1/20/10 41

42 Architecture mul8 couches Composants : chaque composant réalise un service Une couche offre un service (serveur) aux couches externes (client) Service créé indépendamment du logiciel ou spécifiquement Met à profit la no8on d abstrac8on, les couches externes sont plus abstraites (haut niveau) que les couches internes Connecteurs : dépendent du protocole d interac8on souhaité entre couches Système fermé : une couche n a accès qu aux couches adjacentes. Les connecteurs ne relient que les couches adjacentes Système ouvert : toutes les couches ont accès à toutes les autres. Les connecteurs peuvent relier deux couches quelconques Exemples : souvent u8lisé pour les systèmes implémentant des protocoles de communica8on (TCP/IP) 1/20/10 42

43 Architecture mul8 couches Encrypter/décrypter un fichier 1. Entrée d un mot de passe 2. Obtention d une clef d accès 3. Encryptage/décryptage du fichier 4. Fonctions d encryptage/décryptage 4. Cryptographie 3. Interface de fichiers 2. Gestion de clés 1. Authentification Chaque couche est un composant avec une interface bien définie u8lisée par la couche juste au dessus (i.e., externe) La couche supérieure (externe) voit la couche inférieur (interne) comme un ensemble de services offerts Un système complexe peut être construit en superposant les couches de niveau d abstrac8on croissant Il est important d avoir une couche séparée pour l IU Les couches juste au dessous de l IU offrent les fonc8ons applica8ves définies par les cas d u8lisa8on Les couches les plus basses offrent les services généraux E.g., communica8on réseau, accès à la base de données 1/20/10 43

44 Architecture mul8 couches Système fermé Reference Model of Open Systems Interconnec8on (OSI model) Application Présentation Transformation des données (encryption,etc.) Session Identifier et authentifier une connexion Transport Transmission (point à point) fiable des données Transmission des routing packets Réseau Transmission des data frames sans erreurs Ligne de données Interface matérielle du réseau Physique 1/20/10 44

45 Architecture mul8 couches Application Swing AWT X11 1/20/10 45

46 Architecture mul8 couches Interface utilisateur Logique applicative Accès au système d exploitation Accès à la base de données Communication réseau Application programs Screen display facilities User account management File system Kernel (handling processes and swapping 1/20/10 46

47 Architecture mul8 couches D un point de vue concep8on Diviser pour régner : les couches peuvent être conçues séparément Cohésion : si elles sont bien conçues, les couches présenter une cohésion par couche Couplage : des couches inférieures bien conçues ne devraient rien savoir à propos des couches supérieures et les seules connexions autorisées entre couches se font via les API Abstrac8on : on n a pas à connaître les détails d implémenta8on des couches inférieures Réu8lisabilité : les couches inférieures peuvent être conçues de façon à offrir des solu8ons génériques réu8lisables Réu8lisa8on : on peut souvent réu8liser des couches développées par d autres et qui proposent le service requis Flexibilité : il est facile d ajouter de nouveaux services construits sur les services de plus bas niveau An8cipa8on du changement : en isolant les composants dans des couches dis8nctes, le système devient résistant Portabilité : tous les services rela8fs à la portabilité peuvent être isolés Testabilité : les couches peuvent être testées indépendamment Concep8on défensive : les API des couches cons8tuent des endroits stratégiques pour insérer des asser8ons de vérifica8on 1/20/10 47

48 Architecture n niveaux Pour les systèmes distribués Comparable à une architecture par couches dont les couches seraient distribuées! N.b. L architecture mul8 couche est généralement u8lisée pour décrire la structure interne (non distribuée) d un composant qui peut lui même appartenir à une architecture (distribuée) n par8e Par abus de langage, la no8on de 8er a pris le sens de couche distribuée Composants : chaque niveaux est représenté par un composant qui joue le rôle de client et/ou de serveur Connecteurs : relient un client à un serveur. Connexion asymétrique. Doit supporter les communica8on distantes (e.g., requêtes RPC, HTTP, TCP/IP) Exemples Client serveur, Trois niveaux, Quatre niveaux 1/20/10 48

49 Architecture n niveaux Architecture 2 niveaux (client serveur ou client lourd) Client requête de service Serveur Architecture 3 niveaux (client léger) Navigateur Web requête de service Architecture 4 niveaux Logique applicative requête de service de B.D. Serveurs de base de données Client Présentation (partie web) Logique Applicative (calculs, business) Bases de données 1/20/10 49

50 Architecture n niveaux Architecture client serveur Exemple typique : un système d informa8ons u8lisant une base de données centrale. (cas spécial de l architecture avec référen8el) Clients : reçoivent les données de l u8lisateur, ini8ent les transac8ons, etc. Serveur : exécute les transac8ons, assure l intégrité des données Architecture pair à pair = une généralisa8on de l architecture client serveur Les composants peuvent tous à la fois être client et serveur Concep8on plus difficile: flot de contrôle plus complexe dû à la possibilité de deadlocks 1/20/10 50

51 Architecture n niveaux Architecture client serveur <<communication>> Échanger msg Client2 <<communication>> chercher adresse Client1 <<communication>> Échanger msg Client3 Serveur <<communication>> Échanger msg <<communication>> chercher adresse netscape:webbrowser diro:webserver iexplo:webbrowser lynx:webbrowser 1/20/10 51

52 Architecture n niveaux Architecture 3 niveaux Organisa8on en trois couches Couche interface: Composé d objets interfaces (boundary objects) pour interagir avec l u8lisateur (fenêtres, formulaires, pages Web, etc.) Couche logique applica8ve : Comporte tous les objets de contrôle et d en8tés nécessaires pour faire les traitements, la vérifica8on des règles et les no8fica8ons requises par l applica8on Couche de stockage : réalise le stockage, la récupéra8on et la recherche des objets persistants Avantage sur l architecture client serveur Permet le développement et la modifica8on de différentes interfaces u8lisateurs pour la même logique applica8ve 1/20/10 52

53 Architecture n niveaux Architecture 3 par8es Réseau Client X Serveur de B.D. Unix Base de données corporative Marché de données Client Windows Serveur Windows NT Serveur de B.D. Unix Dépôt de données Logique 1/20/10 53 applicative

54 Architecture n niveaux Architecture 3 niveaux Interface gestionnaire Gestion des dossiers À noter que la tendance veut que la par8e cliente soit De plus en plus mince, i.e., le client ne fait qu afficher un contenu HTML La logique applica8ve est alors responsable de créer les pages Web à afficher par le client Il faut dissocier logique applica8ve et présenta8on des données Base de données clients 1/20/10 54

55 Architecture n niveaux Architecture 4 niveaux Architecture dont la couche logique applica8ve est décomposée en Couche Présenta8on (JSP, servlets) Présenta8on du contenu sta8que: Contenu HTML ou XML affiché par le client Présenta8on du contenu dynamique : contenu organisé et créé dynamiquement par le serveur web (pour ensuite être affiché en HTML/XML par le client) Couche Logique applica8ve (calculs purs) : réalise le cœur des traitements de l applica8on Avantage sur l architecture 3 niveaux Permet de supporter un grand nombre de formats de présenta8on différents (propres à chaque client), tout en réu8lisant certains des objets de présenta8on entre les clients. Réduc8on des redondances Bien adaptée pour les applica8ons Web devant supporter plusieurs types de clients 1/20/10 55

56 Architecture n niveaux Architecture 4 niveaux Clients Serveur Serveur de base de données Interface ATM <<build>> Présentation Serveur Interface Web Interface employé de la banque <<submit>> <<build>> <<build>> <<submit>> Gestion opérations bancaires <<submit>> Accès base de données comptes clients Java Server Pages - Partie cliente - Partie serveur 1/20/10 56

57 Architecture n niveaux D un point de vue concep8on Diviser pour régner : de façon évidente, client et serveur peuvent être développées séparément Cohésion : le serveur peut offrir des services cohésifs au client Couplage : un seul canal de communica8on existe souvent entre client et serveur Réu8lisa8on : il est possible de trouver une bibliothèque de composants, interfaces, etc. pour construire les systèmes Toutefois, les systèmes client serveur dépendent très souvent de nombreuses considéra8ons liées in8mement à l applica8on Flexibilité : il est assez facile d ajouter de nouveaux clients et serveurs Portabilité : on peut développer de nouveaux clients pour de nouvelles plateformes sans devoir porter le serveur Testabilité : on peut tester le client et le serveur indépendamment Concep8on défensive : on peut introduire des opéra8ons de vérifica8on dans le code traitant les messages reçus de part et d autre 1/20/10 57

58 5. Développer un modèle architectural Commencer par faire une esquisse de l architecture En se basant sur les principaux requis des cas d u8lisa8on ; décomposi8on en sous systèmes Déterminer les principaux composants requis Sélec8onner un style architectural Raffiner l architecture Iden8fier les principales interac8ons entre les composants et les interfaces requises Décider comment chaque donnée et chaque fonc8onnalité sera distribuée parmi les différents composants Déterminer si on peut réu8liser un cadriciel existant (réu8lisa8on) ou si on peut en construire un (réu8lisabilité) Considérer chacun des cas d u8lisa8on et ajuster l architecture pour qu il soit réalisable Détailler l architecture et la faire évoluer 1/20/10 58

59 Développer un modèle architectural Décrire l architecture avec UML Tous les diagrammes UML peuvent être u8les pour décrire les différents aspects du modèle architectural Trois des diagrammes UML sont par8culièrement u8le pour décrire une architecture logicielle Diagramme de paquetages Diagramme de composants Diagramme de déploiement 1/20/10 59

60 Développer un modèle architectural Diagramme de paquetages Paquetage = Collec8on d éléments de modélisa8on UML (e.g., classes, use cases, etc.) groupés ensemble car liés logiquement Il faut essayer de maximiser la cohésion au sein des paquetages (éléments liés) et minimiser le couplage entre eux Dépendance : un paquetage est dépendant d un autre s il l u8lise SimpleChat OCSF Client Common <<import>> Client Server 1/20/10 60

61 Développer un modèle architectural Diagramme de composants Offre une vue de haut niveau de l architecture du système U8lisé pour décrire le système d un point de vue implémenta8on Permet de décrire les composants d un système et les interac8ons entre ceux ci Illustre comment grouper concrètement et physiquement les éléments (objets, interfaces, etc.) du système au sein de modules qu on appelle composants 1/20/10 61

62 Développer un modèle architectural Qu est ce qu un composant? Unité autonome faisant par8e d un système ou d un sous système qui encapsule un comportement (i.e., implémenta8on) et qui offre une ou plusieurs interfaces publiques Par8e cons8tuante d un système qui peut être remplacée ou/et réu8lisée Élément d implémenta8on (un soussystème, un fichier exécutable, une classe d implémenta8on (i.e., non abstraite, etc.) muni d interface(s) Chaque composant est le représentant d une ou plusieurs classes qui implémentent un service à l intérieur du système Composant Granularité? Un composant peut représenter quelque chose d aussi fin qu un objet, comme il peut représenter un sous système complexe Différence entre composant et instance de composant Composant : vue de haut niveau d un élément logiciel qui compose le système (~classe) Instance de composant : le composant effec8vement u8lisé (~objet) Exemples de composants: Binaire exécutable (<<executable>>), bibliotheque dynamique/sta8que (<<librairy>>), un fichier à interpréter (<<file>>) 1/20/10 62

63 Développer un modèle architectural Les composants et le principe de sépara8on des préoccupa8ons La sépara8on des préoccupa8on est le principe qui assure l intégrité fonc8onnelle d un composant Chaque composant réalise une, et seulement une fonc8on au sein du système, mais peut néanmoins exposer plusieurs méthodes. Typiquement, chaque composant est défini par une interface qui cons8tue son seul moyen d interagir avec les autres composants L u8lisa8on d une interface pour communiquer avec les autres composants du système facilite la maintenance puisqu on peut alors en changer l implémenta8on sans affecter les autres composants (induit un couplage plus faible du composant avec le reste du système) Les classes d un composant devrait être vues comme un patron cohésif qui implémente la fonc8onnalité du composant 1/20/10 63

64 Développer un modèle architectural Composants et interfaces Nota8on Personne Commande EntréeCmdes PaiementComptes interface requise composant interfaces offertes Commande <<provided interfaces>> EntréeCmdes PaiementComptes <<required interface>> Person 1/20/10 64

65 Développer un modèle architectural Composants et rela8ons nota8on Une flèche de dépendance permet de me`re en rela8on des composant via les interfaces requises et fournies Système de commande RechercheClient RechercheClient Repositoire Clients AccèsProduit (3) dépendance (1) composant AccèsProduit Système d inventaire (2) interface 1/20/10 65

LOG4430 : architecture logicielle et conception avancée

LOG4430 : architecture logicielle et conception avancée LOG4430 : architecture logicielle et conception avancée Yann-Gaël Guéhéneuc Architectures Partie 1/2 Tiré du cours de Julie Vachon Département de génie informatique et de génie logiciel École Polytechnique

Plus en détail

IFT2251 : Génie logiciel

IFT2251 : Génie logiciel Julie Vachon, Hiver 2006 IFT2251 : Génie logiciel Chapitre 5. Conception Section 2. Conception architecturale Conception architecturale 1. Architecture logicielle 2. A. Architecture pipeline B. Architecture

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

Environnements de Développement

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

Plus en détail

Évolu>on et maintenance

Évolu>on et maintenance IFT3912 Développement et maintenance de logiciels Évolu>on et maintenance Bruno Dufour Université de Montréal dufour@iro.umontreal.ca Modifica>on des logiciels Les modifica>ons sont inévitables Des nouveaux

Plus en détail

Gouvernance et étude de l impact du changement des processus mé6ers sur les architectures orientées services

Gouvernance et étude de l impact du changement des processus mé6ers sur les architectures orientées services Gouvernance et étude de l impact du changement des processus mé6ers sur les architectures orientées services 30/10/2012 u Soutenance de thèse Karim DAHMAN François CHAROY Claude GODART Evolu1ons des processus

Plus en détail

LOG4430 : Architecture logicielle et conception avancée

LOG4430 : Architecture logicielle et conception avancée LOG4430 : Architecture logicielle et conception avancée Abdou Maiga Revision Département de génie informatique et de génie logiciel École Polytechnique de Montréal Guéhéneuc, 2009; Khomh, 2010; Maiga,

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

PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES. h"p://www.sciencesconf.org

PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES. hp://www.sciencesconf.org PLATEFORME DE GESTION DE CONGRÈS SCIENTIFIQUES h"p://www.sciencesconf.org ! Sommaire Introduc9on Le portail Sciencesconf.org L espace conférence Site web Inscrip9on Ges9on scien9fique Soumission Sélec9on

Plus en détail

Les méthodes Agiles. Introduc)on aux méthodes Agiles Exemple : Scrum

Les méthodes Agiles. Introduc)on aux méthodes Agiles Exemple : Scrum Les méthodes Agiles Introduc)on aux méthodes Agiles Exemple : Scrum Défini)on de base Les méthodes Agiles sont des procédures de concep)on de logiciel qui se veulent plus pragma)ques que les méthodes tradi)onnelles

Plus en détail

IFT2255 Génie logiciel

IFT2255 Génie logiciel IFT2255 Génie logiciel Chapitre 7. Conception Julie Vachon et Houari Sahraoui 7.1.1. L activité de conception Étape cruciale du développement logiciel : pont entre l analyse des besoins et l implémentation

Plus en détail

Introduc)on à Drupal. Journées Mathrice, octobre 2010 par Kenji Lefèvre

Introduc)on à Drupal. Journées Mathrice, octobre 2010 par Kenji Lefèvre Introduc)on à Drupal Journées Mathrice, octobre 2010 par Kenji Lefèvre Sommaire 1. Présenta>on succincte 2. À qui s adresse Drupal? 3. Avantages et difficultés 4. Architecture, administra>on Drupal 5.

Plus en détail

DOCUMENTATION KAPTravel Module de gestion des appels de disponibilité

DOCUMENTATION KAPTravel Module de gestion des appels de disponibilité DOCUMENTATION KAPTravel Module de gestion des appels de disponibilité 01/06/15 KAPT Tous Droits Réservés 2 PRÉSENTATION Ce+e présenta3on va vous perme+re de prendre en main la plateforme de ges3on KAPTravel

Plus en détail

MTI820 Entrepôts de données et intelligence d affaires. Intégra*on des données et ETL

MTI820 Entrepôts de données et intelligence d affaires. Intégra*on des données et ETL MTI820 Entrepôts de données et intelligence d affaires Intégra*on des données et ETL Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaEi, C. Desrosiers 1 Le cycle de vie d un projet en BI

Plus en détail

2015-03- 09. Le cycle de vie d un projet en BI. Ques1on. Diagramme de flux de travail: Pourquoi est- il nécessaire de faire l intégra1on des données?

2015-03- 09. Le cycle de vie d un projet en BI. Ques1on. Diagramme de flux de travail: Pourquoi est- il nécessaire de faire l intégra1on des données? MTI820 Entrepôts de données et intelligence d affaires Intégra1on des données et ETL Département de génie logiciel et des TI MTI820 Hiver 2011 S. ChaIi, C. Desrosiers 1 Le cycle de vie d un projet en BI

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

Interface Homme- Machine. Interface pour le web

Interface Homme- Machine. Interface pour le web Interface Homme- Machine Interface pour le web Ergonomie du web : Importance Web U7lisateurs novices et nomades (accès libre) Ergonomie des interfaces Web 62% des acheteurs en ligne abandonnent au moins

Plus en détail

JAVA PROGRAMMATION. Programme. 1. Java, HTML et World Wide Web

JAVA PROGRAMMATION. Programme. 1. Java, HTML et World Wide Web PROGRAMMATION PUBLIC Professionnels informatiques qui souhaitent développer des applications et «applets» Java DUREE 4 jours 28 heures OBJECTIF Créer divers «applets» à intégrer dans un site Web dynamique,

Plus en détail

EPITA. Bases de données 2 ème par4e AppIng2-2015 Session 2014. Alexandra Champavert. Copyright 2010-2014 Alexandra Champavert - 1 -

EPITA. Bases de données 2 ème par4e AppIng2-2015 Session 2014. Alexandra Champavert. Copyright 2010-2014 Alexandra Champavert - 1 - EPITA Bases de données 2 ème par4e AppIng2-2015 Session 2014 Alexandra Champavert - 1 - Contenu du cours Le datawarehouse Principes de modélisa=on (flocon, étoile) Les ETL Les fonc=onnalités propres à

Plus en détail

Projet. Rappel VBA. Manuele Kirsch Pinheiro - UP1 / CRI / UFR06 Ges>on 28/02/15

Projet. Rappel VBA. Manuele Kirsch Pinheiro - UP1 / CRI / UFR06 Ges>on 28/02/15 Projet Rappel VBA 28/02/15 1 VBA : quoi & pourquoi? VBA : quoi? Langage et environnement de programma>on Orienté Objets A5aché aux documents MS Office VBA : pourquoi? Associer un comportement ac=f à des

Plus en détail

Découvrir Drupal. Les meilleurs thèmes et modules Drupal (présenta5on démo)

Découvrir Drupal. Les meilleurs thèmes et modules Drupal (présenta5on démo) Découvrir Drupal Les meilleurs thèmes et modules Drupal (présenta5on démo) Tour d horizon des principales fonc5onnalités de Drupal au travers de la présenta5on de quelques- uns de ses principaux modules

Plus en détail

«COMMUNICATION ET PRÉSENTATION DE PROJET»

«COMMUNICATION ET PRÉSENTATION DE PROJET» «COMMUNICATION ET PRÉSENTATION DE PROJET» Chefs de projet ou toute personne ayant à communiquer en publique Comprendre et u,liser la communica,on non verbale Comprendre et u,liser le communica,on verbale

Plus en détail

Le contrôle fiscal anno 2013

Le contrôle fiscal anno 2013 Le contrôle fiscal anno 2013 Carlos SIX! Administrateur général de la Fiscalité SPF Finances Ges$on des risques Contrôle fiscal CRM & Tolérance zéro ONDEMENT OBJECTIFS STRATEGIQUES Etude externe 2010 constata$ons

Plus en détail

CQP 112 Introduc/on à la programma/on. Thème 2 : Architecture d un système informa/que. Département d informa/que

CQP 112 Introduc/on à la programma/on. Thème 2 : Architecture d un système informa/que. Département d informa/que CQP 112 Introduc/on à la programma/on Thème 2 : Architecture d un système informa/que Département d informa/que CQP 112 : Introduc/on à la programma/on Plan 1. Historique des ordinateurs 2. Composants

Plus en détail

CSI4139 / CEG4399 Concep1on de systèmes informa1ques sécurisés Assurance & Évaluation

CSI4139 / CEG4399 Concep1on de systèmes informa1ques sécurisés Assurance & Évaluation CSI4139 / CEG4399 Concep1on de systèmes informa1ques sécurisés Assurance & Évaluation Préparé par Guy- Vincent Jourdan et Marc- André Paris- Clou9er, avec l aide des notes de Bishop pour Introduc9on to

Plus en détail

Recherche mul*média et indexa*on séman*que

Recherche mul*média et indexa*on séman*que Recherche mul*média et indexa*on séman*que Stephane Ayache ESIL MIRA 3 ème année Objec*fs du cours Mise en œuvre d un moteur de recherche MM Stockage Organisa*on des indexes en BD Métadonnées Algorithmes

Plus en détail

Unité de formation 1 : Structurer une application. Durée : 3 semaines

Unité de formation 1 : Structurer une application. Durée : 3 semaines PROGRAMME «DEVELOPPEUR LOGICIEL» Titre professionnel : «Développeur Logiciel» Inscrit au RNCP de niveau III (Bac+2) (JO du 23 Octobre 2007) (32 semaines) Unité de formation 1 : Structurer une application

Plus en détail

Les formations. Développeur Logiciel. ENI Ecole Informatique

Les formations. Développeur Logiciel. ENI Ecole Informatique page 1/8 Titre professionnel : Inscrit au RNCP de Niveau III (Bac + 2) (J.O. du 19/02/13) 24 semaines + 8 semaines de stage (uniquement en formation continue) Développer une application orientée objet

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

Cahier de charges (Source : "Java EE - Guide de développement d'applications web en Java" par Jérôme Lafosse) Module. Site Web dynamique JSP / Servlet

Cahier de charges (Source : Java EE - Guide de développement d'applications web en Java par Jérôme Lafosse) Module. Site Web dynamique JSP / Servlet Cahier de charges (Source : "Java EE - Guide de développement d'applications web en Java" par Jérôme Lafosse) Module Site Web dynamique JSP / Servlet Sujet : betaboutique Soutenance le 04 / 01 /2013 &

Plus en détail

Les formations. Développeur Logiciel. ENI Ecole Informatique

Les formations. Développeur Logiciel. ENI Ecole Informatique page 1/5 Titre professionnel : Reconnu par l Etat de niveau III (Bac), inscrit au RNCP (arrêté du 12/10/07, J.O. n 246 du 23/10/07) (32 semaines) Unité 1 : Structurer une application 6 semaines Module

Plus en détail

NFP111 Systèmes et Applications Réparties

NFP111 Systèmes et Applications Réparties NFP111 Systèmes et Applications Réparties 1 de 38 NFP111 Systèmes et Applications Réparties Cours 11 - Les Enterprise Java Beans (Introduction aux Enterprise Claude Duvallet Université du Havre UFR Sciences

Plus en détail

GL - 2 2.4 Architecture logicielle

GL - 2 2.4 Architecture logicielle GL - 2 2.4 Architecture logicielle Lydie du Bousquet Lydie.du-bousquet@imag.fr En collaboration avec Ph. Lalanda Activités logicielles Analyse : récolte des exigences Comment commencer la conception? Analyse

Plus en détail

Les termes du cloud CUMULO NUMBIO 2015 O. COLLIN

Les termes du cloud CUMULO NUMBIO 2015 O. COLLIN Les termes du cloud CUMULO NUMBIO 2015 O. COLLIN Agenda Pe$t glossaire du cloud : termes qui seront u$lisés lors de ce5e école Virtualisa$on CMP Environnement Bioinforma$que Linux Comment les machines

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

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

É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

14 Octobre 2008 TICPME2010 Sage et TICPME2010

14 Octobre 2008 TICPME2010 Sage et TICPME2010 Sage et TICPME2010 Une forte implica:on dans certains projets TICPME de par un posi:onnement dédié aux PME Base installée en France de 500 000 entreprises), 5 000 d'appels clients traités par jour Des

Plus en détail

Architecture Logicielle

Architecture Logicielle Architecture Logicielle Chapitre 2: Description des Architectures Logicielles Année universitaire 2013/2014 Semestre 1 Plan 1. Pratique Recommandée pour l établissement d une architecture (IEEE Standard

Plus en détail

Fiche Programme CSC4002 Conception et programmation orientées objet. Coordonnateurs : Christian Bac et Denis Conan Octobre 2012

Fiche Programme CSC4002 Conception et programmation orientées objet. Coordonnateurs : Christian Bac et Denis Conan Octobre 2012 Fiche Programme CSC4002 Conception et programmation orientées objet Coordonnateurs : Christian Bac et Denis Conan Octobre 2012 1 Mots-clés : conception orientée objet, programmation orientée objet, UML,

Plus en détail

Pasquier Barthelémy Ticula Omont

Pasquier Barthelémy Ticula Omont Pet Store Un magasin de vente en ligne générique basé sur: Le Kit de Développement Logiciel de Java 2, Edition Entreprise (J2EE) Pasquier Barthelémy Ticula Omont lundi 9 mars 2009 1/16 1) Objectif de l

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

Présentation Level5. Editeur de Logiciels. «If it s not monitored, it s not in production» Theo Schlossnagle #velocityconf

Présentation Level5. Editeur de Logiciels. «If it s not monitored, it s not in production» Theo Schlossnagle #velocityconf Editeur de Logiciels Présentation Level5 «If it s not monitored, it s not in production» Theo Schlossnagle #velocityconf «If you can not measure it, you can not improve it» Lord Kelvin vous accompagne

Plus en détail

Fédération des Agences Urbaines du Maroc MAJAL. Les projets et Démarches de dématérialisa3on. Séminaire de restitution. 29 Mars 2014.

Fédération des Agences Urbaines du Maroc MAJAL. Les projets et Démarches de dématérialisa3on. Séminaire de restitution. 29 Mars 2014. Fédération des Agences Urbaines du Maroc MAJAL Les projets et Démarches de dématérialisa3on Séminaire de restitution 29 Mars 2014! M2M Group Dématérialisa+on: Défini+on et Impacts Directs Dématérialisa+on

Plus en détail

Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines)

Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines) Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines) Module 1 : Programmer une application informatique Durée

Plus en détail

CX Print SA - Plane- Ville 24-1955 Chamoson - Tél +41 27 306 46 33 - Fax +41 27 306 46 77 info@cxprint.ch - www.cxprint.ch

CX Print SA - Plane- Ville 24-1955 Chamoson - Tél +41 27 306 46 33 - Fax +41 27 306 46 77 info@cxprint.ch - www.cxprint.ch Ges%on documentaire Concept : La ges%on documentaire Numériser et indexer vos documents papiers Indéxer vos documents numériques (Word, excel, powerpoint...) Archivage de vos documents papiers Serveur

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

Messagerie asynchrone et Services Web

Messagerie asynchrone et Services Web Article Messagerie asynchrone et Services Web 1 / 10 Messagerie asynchrone et Services Web SOAP, WSDL SONT DES STANDARDS EMERGEANT DES SERVICES WEB, LES IMPLEMENTATIONS DE CEUX-CI SONT ENCORE EN COURS

Plus en détail

IMN638 CHAPITRE 2 MODULE 1 PROCESSEURS GRAPHIQUES ET PIPELINE

IMN638 CHAPITRE 2 MODULE 1 PROCESSEURS GRAPHIQUES ET PIPELINE IMN638 CHAPITRE 2 MODULE 1 Automne 2014 Université de Sherbrooke Olivier Vaillancourt, Olivier Godin 2014-09- 26 1 Sommaire Introduc1on Concept de pipeline Étude détaillée du pipeline graphique Ges1on

Plus en détail

MAJEURE CESEM 4 MANAGEMENT DES SYSTÈMES D INFORMATION

MAJEURE CESEM 4 MANAGEMENT DES SYSTÈMES D INFORMATION " MAJEURE CESEM 4 MANAGEMENT DES SYSTÈMES D INFORMATION 28 janvier - 15 février 2013 Professeurs : Annie Falan*n (annie.falan)n@reims- ms.fr) Diana Mangalagiu (diana.mangalagiu@reims- ms.fr) Dominique

Plus en détail

IBM WebSphere ILOG JRules Business Rule Management System (BRMS) systèmes de gestion de règles métier

IBM WebSphere ILOG JRules Business Rule Management System (BRMS) systèmes de gestion de règles métier Automatisation des décisions métier et réduction du délai de lancement de nouvelles initiatives IBM WebSphere ILOG JRules Business Rule Management System (BRMS) systèmes de gestion de règles métier Gestion

Plus en détail

Vérifier la qualité de vos applications logicielle de manière continue

Vérifier la qualité de vos applications logicielle de manière continue IBM Software Group Vérifier la qualité de vos applications logicielle de manière continue Arnaud Bouzy Kamel Moulaoui 2004 IBM Corporation Agenda Analyse de code Test Fonctionnel Test de Performance Questions

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

Améliorez et industrialisez vos feedback produit

Améliorez et industrialisez vos feedback produit Améliorez et industrialisez vos feedback produit Jean- Philippe Gillibert, architecte logiciel et coach agile chez Introduc)on Retour d expérience sur un projet à la SNCF Méthode originale de traitement

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

Exécution des applications réparties

Exécution des applications réparties Exécution des applications réparties Programmation des Applications Réparties Olivier Flauzac URCA Master STIC-Informatique première année Olivier Flauzac (URCA) PAR : Exécution des applications réparties

Plus en détail

Objectifs. Maîtriser. Pratiquer

Objectifs. Maîtriser. Pratiquer 1 Bases de Données Objectifs Maîtriser les concepts d un SGBD relationnel Les modèles de représentations de données Les modèles de représentations de données La conception d une base de données Pratiquer

Plus en détail

Managment de la qualité Management de la qualité ISO 9001, 14001, 18001 iso TS...

Managment de la qualité Management de la qualité ISO 9001, 14001, 18001 iso TS... 1 sur 6 08/09/2012 21:38 Managment de la qualité Management de la qualité ISO 9001, 14001, 18001 iso TS... FAQ Rechercher Membres Groupes S enregistrer Profil Se connecter pour vérifier ses messages privés

Plus en détail

Chapitre 1 «mes chiffres clés à portée de mains»

Chapitre 1 «mes chiffres clés à portée de mains» Chapitre 1 «mes chiffres clés à portée de mains» Le volume des données manipulées par les acteurs du tourisme est de plus en plus important. Au delà des données mé6ers qui se complexifient, les données

Plus en détail

Bap$ste Morin Etude d approfondissement RICM 5

Bap$ste Morin Etude d approfondissement RICM 5 Bap$ste Morin Etude d approfondissement RICM 5 Déroulement Présenta)on Principaux services Principe Providers Evolu)on 2 Déroulement Présenta)on Principaux services Principe Providers Evolu)on 3 Présenta$on

Plus en détail

Tout pour monter son site Web. IUFM de Bourgogne

Tout pour monter son site Web. IUFM de Bourgogne Tout pour monter son site Web IUFM de Bourgogne Pourquoi utiliser les technologies Web? Visible par toutes les plates-formes (PC, Mac, Unix ) Technologies simples et descriptives Contenu principalement

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

Formation Webase 5. Formation Webase 5. Ses secrets, de l architecture MVC à l application Web. Adrien Grand Centrale Réseaux

Formation Webase 5. Formation Webase 5. Ses secrets, de l architecture MVC à l application Web. Adrien Grand <jpountz@via.ecp.fr> Centrale Réseaux Formation Webase 5 Ses secrets, de l architecture MVC à l application Web Adrien Grand Centrale Réseaux Sommaire 1 Obtenir des informations sur Webase 5 2 Composants de Webase 5 Un

Plus en détail

DEVELOPPEMENT D APPLICATIONS WEB & MOBILE

DEVELOPPEMENT D APPLICATIONS WEB & MOBILE DEVELOPPEMENT D APPLICATIONS WEB & MOBILE QUI SOMMES NOUS? Thot'em Interac.f est une société de services proposant des presta.ons de développement, d'hébergement et de maintenance de sites Internet et

Plus en détail

Architectures de communication. «Architecture protocolaire réseau» «protocolaire»

Architectures de communication. «Architecture protocolaire réseau» «protocolaire» Architectures de communication C. Pham Université de Pau et des Pays de l Adour Département Informatique http://www.univ-pau.fr/~cpham Congduc.Pham@univ-pau.fr «Architecture protocolaire réseau» Architecture

Plus en détail

Concepon et réalisaon

Concepon et réalisaon Concepon et réalisaon Vendée Etudes & Réalisaons de Soluons Informaques 10 rue des Sables 85540 Mouers les Mauxfaits h%p://sarl-versi.fr contact@sarl-versi.fr Mainate 2 une logiciel d aide à la communicaon

Plus en détail

IBM WebSphere MQ File Transfer Edition, Version 7.0

IBM WebSphere MQ File Transfer Edition, Version 7.0 Transfert de fichiers administré pour architecture orientée services (SOA) IBM, Version 7.0 Solution de transport polyvalente pour messages et fichiers Transfert de fichiers haute fiabilité basé sur la

Plus en détail

Web (Persistance) Andrea G. B. Tettamanzi. Université de Nice Sophia Antipolis Département Informatique andrea.tettamanzi@unice.fr

Web (Persistance) Andrea G. B. Tettamanzi. Université de Nice Sophia Antipolis Département Informatique andrea.tettamanzi@unice.fr Web (Persistance) Andrea G. B. Tettamanzi Université de Nice Sophia Antipolis Département Informatique andrea.tettamanzi@unice.fr Andrea G. B. Tettamanzi, 2014 1 CM - Séance 8 Organisation logicielle d'une

Plus en détail

Architectures web pour la gestion de données

Architectures web pour la gestion de données Architectures web pour la gestion de données Dan VODISLAV Université de Cergy-Pontoise Plan Le Web Intégration de données Architectures distribuées Page 2 Le Web Internet = réseau physique d'ordinateurs

Plus en détail

LANGAGUE JAVA. Public Développeurs souhaitant étendre leur panel de langages de programmation

LANGAGUE JAVA. Public Développeurs souhaitant étendre leur panel de langages de programmation ING 01 LANGAGUE JAVA Durée : 21 heures 1090 HT / jour Dates : à définir en 2012 Concevoir et développer des programmes en langage Java Comprendre le fonctionnement de la machine virtuelle S approprier

Plus en détail

24/11/2011. Cours EJB/J2EE Copyright Michel Buffa. Plan du cours. EJB : les fondamentaux. Enterprise Java Bean. Enterprise Java Bean.

24/11/2011. Cours EJB/J2EE Copyright Michel Buffa. Plan du cours. EJB : les fondamentaux. Enterprise Java Bean. Enterprise Java Bean. Plan du cours 2 Introduction générale : fondamentaux : les fondamentaux Michel Buffa (buffa@unice.fr), UNSA 2002, modifié par Richard Grin (version 1.1, 21/11/11), avec emprunts aux supports de Maxime

Plus en détail

LES FONCTIONS DE SURVEILLANCE DES FICHIERS

LES FONCTIONS DE SURVEILLANCE DES FICHIERS SYSLOG and APPLICATION LOGS Knowledge Module for PATROL - Data Sheet Version 1.5 Développé par http://www.axivia.com/ PRESENTATION DU PRODUIT SYSLOG and APPLICATION LOGS Knowledge Module for PATROL est

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

Solutions et Services. d'analyse prédictive

Solutions et Services. d'analyse prédictive ProbaYes Mastering Uncertainty Solutions et Services d'analyse prédictive Mai 2013 Copyright 2013 Probayes All Rights Reserved 1 Présenta)on Probayes Créée en 2003 Basée en France (Grenoble) Spin-off de

Plus en détail

IBM Tivoli Monitoring

IBM Tivoli Monitoring Surveiller et gérer les ressources vitales et les mesures sur diverses plates-formes à partir d une seule console IBM Tivoli Monitoring Points forts Surveille de manière proactive Aide à réduire les coûts

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 BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

Séminaire Aristote - 11 avril 2012 Jedeclare.com d'un Portail Déclara:f à une Plate- forme globale de dématérialisa:on au service d'une profession

Séminaire Aristote - 11 avril 2012 Jedeclare.com d'un Portail Déclara:f à une Plate- forme globale de dématérialisa:on au service d'une profession Séminaire Aristote - 11 avril 2012 Jedeclare.com d'un Portail Déclara:f à une Plate- forme globale de dématérialisa:on au service d'une profession Stéphane Gasch Directeur des études informa:ques du CSOEC

Plus en détail

L observa*on du développement de l enfant dans ses jeux symboliques

L observa*on du développement de l enfant dans ses jeux symboliques L observa*on du développement de l enfant dans ses jeux symboliques Sarah Landry, Ph. D. Professeure- chercheuse Faculté des sciences de l éduca*on Université de Montréal Courriel: sarah.landry@umontreal.ca

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

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

NetCrunch 6. Superviser

NetCrunch 6. Superviser AdRem NetCrunch 6 Serveur de supervision réseau Avec NetCrunch, vous serez toujours informé de ce qui se passe avec vos applications, serveurs et équipements réseaux critiques. Documenter Découvrez la

Plus en détail

BES WEBDEVELOPER ACTIVITÉ RÔLE

BES WEBDEVELOPER ACTIVITÉ RÔLE BES WEBDEVELOPER ACTIVITÉ Le web developer participe aux activités concernant la conception, la réalisation, la mise à jour, la maintenance et l évolution d applications internet/intranet statiques et

Plus en détail

Applications orientées données (NSY135)

Applications orientées données (NSY135) Applications orientées données (NSY135) 2 Applications Web Dynamiques Auteurs: Raphaël Fournier-S niehotta et Philippe Rigaux (philippe.rigaux@cnam.fr,fournier@cnam.fr) Département d informatique Conservatoire

Plus en détail

CONDUITE & GESTION DE PROJET

CONDUITE & GESTION DE PROJET LES THEMES DU PROGRAMME PEDAGOGIQUE CONDUITE & GESTION DE PROJET Techniques de gestion de projets Connaître le rôle d un chef de projet dans la conduite de projet. Les méthodes, les techniques et les outils

Plus en détail

Architectures web/bases de données

Architectures web/bases de données Architectures web/bases de données I - Page web simple : HTML statique Le code HTML est le langage de base pour concevoir des pages destinées à être publiées sur le réseau Internet ou intranet. Ce n'est

Plus en détail

Management des Risques dans les Projets Innovants

Management des Risques dans les Projets Innovants Nicolas VERVLIET Arts et Me(ers ParisTech, LCPI Management des Risques dans les Projets Innovants Nicolas VERVLIET, Ingénieur Qualité Chercheur LCPI Conférence Société des Ingénieurs Arts et Métiers Paris

Plus en détail

Chapitre 1 «mes chiffres clés à portée de mains»

Chapitre 1 «mes chiffres clés à portée de mains» Chapitre 1 «mes chiffres clés à portée de mains» Le volume des données manipulées par les acteurs du tourisme est de plus en plus important. Au delà des données mé6ers qui se complexifient, les données

Plus en détail

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN 1. DÉVELOPPEMENT D'APPLICATION (CONCEPTEUR ANALYSTE) 1.1 ARCHITECTURE MATÉRIELLE DU SYSTÈME INFORMATIQUE 1.1.1 Architecture d'un ordinateur Processeur,

Plus en détail

Page 1 2 La présente invention concerne le domaine des architectures informatiques, et en particulier un procédé pour le développement d applications destiné à un fonctionnement en réseau, par exemple

Plus en détail

SharePoint Server 2013 Déploiement et administration de la plate-forme

SharePoint Server 2013 Déploiement et administration de la plate-forme Présentation des technologies SharePoint 1. Historique des technologies SharePoint 13 1.1 SharePoint Team Services v1 14 1.2 SharePoint Portal Server 2001 14 1.3 Windows SharePoint Services v2 et Office

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

Institut Supérieure Aux Etudes Technologiques De Nabeul. Département Informatique

Institut Supérieure Aux Etudes Technologiques De Nabeul. Département Informatique Institut Supérieure Aux Etudes Technologiques De Nabeul Département Informatique Support de Programmation Java Préparé par Mlle Imene Sghaier 2006-2007 Chapitre 1 Introduction au langage de programmation

Plus en détail

LANGAGES & DéVELOPPEMENT. Une équipe à vos côtés pour toutes vos montées en compétences

LANGAGES & DéVELOPPEMENT. Une équipe à vos côtés pour toutes vos montées en compétences LANGAGES & DéVELOPPEMENT Une équipe à vos côtés pour toutes vos montées en compétences ASP.NET OPTION VB.NET OU C# 5 jours Permettre aux participants de mieux appréhender ce qu est la programmation pour

Plus en détail

Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform

Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform IBM Software Group Développement logiciel pour l Architecture Orientée Services avec IBM Rational Software Development Platform Thierry Bourrier, Techical Consultant thierry.bourrier@fr.ibm.com L Architecture

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

Le moteur de workflow JBPM

Le moteur de workflow JBPM Le moteur de workflow Claude Duvallet Université du Havre UFR Sciences et Techniques 25 rue Philippe Lebon - BP 540 76058 LE HAVRE CEDEX Claude.Duvallet@gmail.com http://litis.univ-lehavre.fr/ duvallet/

Plus en détail

Le moteur de workflow JBPM

Le moteur de workflow JBPM Le moteur de Workflow Le moteur de workflow 1 Claude Duvallet Université du Havre UFR Sciences et Techniques 25 rue Philippe Lebon - BP 540 76058 LE HAVRE CEDEX Claude.Duvallet@gmail.com http://litis.univ-lehavre.fr/

Plus en détail

DUT Informatique Module JAVA Apprentis Département Informatique 2008 / 2009. Travaux Pratiques n o 7 : RMI

DUT Informatique Module JAVA Apprentis Département Informatique 2008 / 2009. Travaux Pratiques n o 7 : RMI iut ORSAY DUT Informatique Département Informatique 2008 / 2009 Travaux Pratiques n o 7 : RMI Nom(s) : Groupe : Date : Objectifs : savoir créer des applications client-serveur mettant en jeu des machines

Plus en détail

SPIP. Gestion de la performance dans SPIP. Préoccupa)on historique

SPIP. Gestion de la performance dans SPIP. Préoccupa)on historique SPIP Gestion de la performance dans SPIP Préoccupa)on historique Intrinsèquement lié aux objec)fs du projet (indépendance des u)lisateurs / prestas techniques) par la typologie majoritaire des u)lisateurs

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