Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Architecture du logiciel I.

Slides:



Advertisements
Présentations similaires
Module Systèmes d’exploitation
Advertisements

GEF 243B Programmation informatique appliquée Listes chaînées I – Tableaux de structures §15.1 – 15.2.
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes dexploitation Le matériel des ordinateurs Revue Pt II (Tanenbaum 1.4)
GEF 243B Programmation informatique appliquée
GEF 435 Principes des systèmes dexploitation Structure du logiciel dE/S Partie II (Tanenbaum & 5.3.4)
GEF 435 Principes des systèmes dexploitation Les systèmes dexploitation en général (Tanenbaum 1.1 et 1.3)
Hiver 2010JGA Beaulieu GEF 243B Programmation informatique appliquée Structure de base des programmes en C.
GEF 243B Programmation informatique appliquée
Les Systèmes d’Information Financière Atelier conjoint ACBF / Banque Mondiale / AFRITAC de l’Ouest Gérer l’application dans le temps, sur les plans fonctionnel,
Systèmes en temps réel Modélisation du comportement en temps réel avec UML.
GEF 243B Programmation informatique appliquée Boucles §
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Considération de temps.
GEF 435 Principes des systèmes dexploitation Communication Interprocessus (CIP) II (Tanenbaum 2.3)
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Tests.
GEF 243B Programmation informatique appliquée
GEF 435 Principes des systèmes dexploitation Communication Interprocessus (CIP) III (Tanenbaum 2.3)
GEF 435 Principes des systèmes d’exploitation
GEF 435 Principes des systèmes dexploitation Structure des systèmes dexploitation (Tanenbaum 1.7)
GEF 243B Programmation informatique appliquée Expressions et opérateurs §
GEF 243B Programmation informatique appliquée
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Architecture du logiciel II.
GEF 243B Programmation informatique appliquée
GEF 435 Principes des systèmes d’exploitation
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Modélisation II.
GEF 435 Principes des systèmes dexploitation Concepts des Systèmes dexploitation (Tanenbaum 1.5)
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Génie logiciel et Vérification et validation.
GEF 435 Principes des systèmes dexploitation Appels de système (Tanenbaum 1.6)
GEF 243B Programmation informatique appliquée Flot de contrôle et énoncés de sélection §
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Types, variables et constantes.
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Génie logiciel avec composantes.
GEF 243B Programmation informatique appliquée Types dérivés, structures et tableaux §
GEF 243B Programmation informatique appliquée Expressions de type mixte et blocs §
GEF 243B Programmation informatique appliquée
GEF 243B Programmation informatique appliquée
GEF 243B Programmation informatique appliquée
Hiver 2009Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation Informatique appliquée Introduction et synopsis du cours.
Hiver 2010JGA Beaulieu GEF 243B Programmation informatique appliquée Fonctions.
Hiver 2010JGA Beaulieu GEF 243B Programmation informatique appliquée Modules et masquage dinformation.
Hiver 2010JGA Beaulieu GEF 243B Programmation informatique appliquée Tableaux et pointeurs §10.1.
LOG4430 : Architecture logicielle et conception avancée
Reference Model of Open Distributed Processing
Vue d'ensemble Implémentation de la sécurité IPSec
1 Les technologies XML Cours 1 : Les Web Services et Architectures Orientées Services Fé vrier Version 1.0 -
Les Ateliers de Génie Logiciel
MIAGE MASTER 1 Cours de gestion de projet
GEF 447B Bring sample sensors Comportement Capt. Vincent Roberge.
Architecture Réseau Modèle OSI et TCP.
Réalisée par :Samira RAHALI
Sommaire Objectif de Peakup Principes de fonctionnement
Chap 4 Les bases de données et le modèle relationnel
Techniques de test Boulanger Jean-Louis.
Toujours partir du besoin métier – Pas dune envie de linformatique Concevoir les services – puis concevoir leur implémentation Le vrai bénéfice est.
Patrons de conceptions de créations
Stratégie d’entreprise - Alstom Transport – Marco Férrogalini
Supports de formation au SQ Unifié
INF8505: processeurs embarqués configurables
Vérification dans le cycle de vie GEF492A 2014 Référence: [HvV §14.2, 14.9] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et.
Le contenu est basé aux transparents du 7 ème édition de «Software Engineering» de Ian Sommerville«Software Engineering» de Ian Sommerville B.Shishedjiev.
Le web service
Théorie du projet architectural
© Petko ValtchevUniversité de Montréal Février IFT 2251 Génie Logiciel Conception Hiver 2002 Petko Valtchev.
Introduction au Génie Logiciel
Initiation à la conception des systèmes d'informations
Présentation AICHA REVEL INGENIEUR D’ÉTUDE STERIA DEPARTEMENT TRD
Problématique de la thèse Comment les outils provenant du management des connaissances peuvent ils être utilisés dans le cadre de la politique d'amélioration.
Architecture Client/Serveur
Diagramme de Composants
© Promaintech Novaxa – Tous droits d’utilisation réservés Plans factoriels Introduction à la statistique industrielle.
1 GREC INITIALES Formation de bassin Atelier Réalité Augmentée Groupe de formateurs ATELIER RÉALITÉ AUGMENTÉE.
Transcription de la présentation:

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Architecture du logiciel I

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Revue Nommez les 5 phases du cycle de vie du logiciel Quelle est la différence entre la vérification et la validation?

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Synopsis Quest-ce quest larchitecture? Larchitecture du logiciel Pipes et filtres Architecture en couches

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Quest-ce quest larchitecture? Les ingénieurs doivent être capable de communiquer leurs designs et idées tôt dans un projet pour être effectifs Dans la plus part des disciplines dingénierie, les designs sont communiqués avec des bleus Au plus haut niveau des bleus, les dessins montrent une abstraction de haut niveau pour le projet dans son ensemble Ces abstractions de haut niveau montre le style darchitecture pour le projet

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Quest-ce quest larchitecture? Les dessins darchitecture montrent plus que le produit fini; ils communiquent lintention de lingénieur et de larchitecte Par exemple, larchitecture dun pont montre limage du pont final et montre aussi comment le pont va être supporté, (suspension, compression, cantilever,…) sans montrer les détails de comment cela va être accomplit Les mots comme pont cantilever décrivent un style architectural ou un idiome architectural que les ingénieurs civils étudient et comprennent

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architecture du logiciel En génie logiciel, il ny a pas de bleus Cependant, les ingénieurs en logiciel ont besoin dune façon de communiquer leurs designs et leurs intentions Létude de larchitecture des logiciels est couramment dans son enfance Shaw et Garland, 1996 Même si larchitecture du logiciel nest pas encore une science mature, il y a plusieurs idées qui peuvent être utiles pour nous aider à communiquer nos designs

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architecture du logiciel Dans les quelques décennies où nous avons produits des produits logiciels, plusieurs idiomes architecturales ont été identifiés parce quils reviennent souvent et ont été prouvé par le temps Ces idiomes sont: Pipes et filtres En couches Abstractions de données Référentiels Client-serveur Contrôle de processus

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architecture du logiciel Larchitecture des logiciels nous aide: À identifier comment les composantes vont interagir entre elles En montrant comment les données et informations sont échangés entre les composantes En nous donnant un ensemble de symboles et un vocabulaire pour décrire nos systèmes En nous donnant les règles pour lutilisation des symboles et du vocabulaire Quand nous spécifions un style architectural, le design et limplémentation doivent respecter ce style

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architecture du logiciel Jusquà date, nous avons vus deux types de diagrammes qui nous permettent de décrire et communiquer nos designs: Les hiérarchies fonctionnelles: montrent les fonctions dun système et leurs relations les unes aux autres (relation dappel et réponse) Organigrammes: Représentation de bas niveau pour la logique dun algorithme Les diagrammes architecturales sont à un plus haut niveau dabstraction que les hiérarchies fonctionnelles

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architecture du logiciel Nous avons aussi parlés des modules; qui nous permettent dappliquer le principe du masquage de linformation Ces modules peuvent aussi être représentés dans une hiérarchie similaire à celle des fonctions pour montrer les relations de dépendance Cependant, les modules peuvent aussi être utilisés comme blocs ou composantes dans la construction des styles architecturales

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Pipes et filtres Possiblement un des styles architecturales les plus simples nous provient des systèmes de traitement en lots: Larchitecture de pipes et filtres Ce style est grandement utilisé pour les programmes écrits en Unix shell Dans une architecture de pipes et filtres, les données sont vues comme un flot continue qui est transformé par des filtres

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Pipes et filtres Les filtres sont indépendants les uns des autres; létat de chaque filtre est inconnu aux autres Un filtre ne sait pas quels autres filtres sont avant ou après lui La sortie des données à un filtre peut commencer avant que lentrée soit terminée (flot continue) Les connecteurs dans un P&F représentent les données qui sont fournies aux filtres et collectées des filtres de façon continue; de là le nom pipe Les pipes et les filtres peuvent avoir un type ou pas en avoir

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Pipes et filtres Filtres Pipes

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Pipes et filtres Larchitecture de pipes et filtres est utile pour les ingénieurs électriques qui utilisent du logiciel dans leurs solutions Plusieurs composantes utilisées dans lacquisition de données, le traitement des signaux, les systèmes de communication, les radars, la gestion de la puissance et plusieurs autres implémentations, utilisent les filtres logiciels parce quils sont hautement flexibles Le flot continu de données par pipes et les transformations par les filtres sadaptent bien au signaux digitaux

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Pipes et filtres Une fois développées, les filtres peuvent être réutilisés: i.e. un filtre passe-bas qui a été écrit peut être réutilisé en changeant les constantes du filtre Les compilateurs de première génération suivaient larchitecture des P&F Une des compagnies qui utilisent ce type darchitecture souvent dans ses produits est Tektronix – oscilloscopes

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architectures en couches Un autre style architectural qui a été grandement utilisé au travers des années est larchitecture en couches Dijkstra a introduit larchitecture en couches quand il fait le design du système dexploitation T.H.E. Dijkstra a proposé que les systèmes dexploitation devraient être une hiérarchie de couches Chaque niveau a ses responsabilités et fournit des services aux niveau plus haut.

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architectures en couches Couche 1 Couche 2 … Couche n-1 Couche n Couche 1 Couche 2

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architectures en couches Les architectures en couches devraient être utilisées quand: Vous avez identifié que votre système doit isoler des classes de services Vous devez fournir des mécanismes de contrôle pour des niveaux de sécurités Vous avez besoin de cacher le matériel ou le logiciel de bas niveau pour réduire la complexité du logiciel de haut niveau Vous voulez augmenter la portabilité du logiciel en remplaçant les niveaux inférieurs qui touchent à la plate forme Besoin de traiter les signaux asynchrones ou une haute variation dans les temps de réponse

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architectures en couches Le type de hiérarchie dans les architectures en couches diffèrent des hiérarchies modulaires ou fonctionnelles parce que chaque couche redéfinit les relations Les relations dans une hiérarchie fonctionnelle identifient quelles fonctions sont utilisées par les autres Les relations dans une architecture en couches identifient les fonctions qui fournissent les services et les fonctions qui appellent ces services

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architectures en couches Les fonctions dans une couche fournissent des services aux fonctions dans la couche supérieure; et sont des clientes pour la couche inférieure. Fctn 1Fctn 2Fctn 3 Fctn AFctn B My_prog

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architectures en couches Les architectures en couches peuvent être utilisées pour: Les projets qui implémentent des protocoles (communication, transformation,…) Les systèmes Interface Utilisateur Graphique (IUG) pour séparer les fonctions dinterface de la solution Systèmes robotiques, pour séparer les responsabilités dans des couches – Prise de décision, Navigation de haut niveau, Production de mappe, intégration des senseurs, lecture des senseurs, contrôle du robot.

Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Quiz Time Pourquoi utilise-t-on des idiomes architecturales (styles) en génie logiciel? Est-ce que les filtres dans une architecture de P&F sont dans une hiérarchie? Quelle est la différence entre une hiérarchie fonctionnelle et une hiérarchie dans une architecture en couches?