Télécharger la présentation
La présentation est en train de télécharger. S'il vous plaît, attendez
Publié parLéonne Peltier Modifié depuis plus de 11 années
1
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage GEF 243B Programmation informatique appliquée Architecture du logiciel I
2
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?
3
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Synopsis Quest-ce quest larchitecture? Larchitecture du logiciel Pipes et filtres Architecture en couches
4
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
5
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
6
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
7
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
8
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
9
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
10
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
11
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
12
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
13
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Pipes et filtres Filtres Pipes
14
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
15
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
16
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.
17
Hiver 2005Maj JGA Beaulieu & Capt MWP LeSauvage Architectures en couches Couche 1 Couche 2 … Couche n-1 Couche n Couche 1 Couche 2
18
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
19
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
20
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
21
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.
22
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?
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.