Environnements de Développement

Transcription

1 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

2 Syllabus du cours 2 Objectifs Généraux Comprendre les architectures logicielles ainsi que leurs composants; Comprendre les principaux patrons de conception (Design Patterns) Etre capable de mettre en oeuvre certains patrons de conception Décrire une architecture logicielle et produire la documentation correspondante Pré-requis POO, UML, JAVA, GL1&2

3 Organisation du cours 3 I. Fondements de l architecture logicielle II. Styles Architecturaux III.Architecture J2EE IV. Les Patrons de Conception V. Conception Architecturale VI. Thèmes Connexes de GL

4 Chapitre I: 4 Fondements de l Architecture Logicielle Unité d enseignement: Environnements de Développement

5 PLAN Veuillez nous suivre 5 Introduction Historique Eléments Architecturaux Conclusion Références Modéliser avec UML Choix d une architecture Logicielle

6 Introduction 6 "The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution IEEE 2000

7 Introduction 7 L architecture logicielle décrit: La structure du système en terme de composants, relations entre composants et relations avec l environnement Déterminer et décrire les interactions et les interfaces entre les sous systèmes Décrire également les composants utilisés pour implanter les fonctionnalités des sous systèmes: les propriétés de ces composants, leur contenu, les machines ou dispositifs matériels sur lesquels ces composants seront déployés.

8 Introduction 8 Pourquoi développer une architecture logicielle? Architecturer pour la disponibilité (détection de fautes, recouvrement de fautes) Architecturer pour la modifiabilité Pour permettre à tous de mieux comprendre le système Pour permettre aux développeurs de travailler sur des parties individuelles du système en isolation Pour préparer les extensions du système Pour faciliter la réutilisation et la réutilisabilité

9 Introduction 9 Utilité 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. Réutilisation :favorise l identification des éléments réutilisables, parties de conception, composants, caractéristiques, fonctions ou données communes Construction :fournit un plan de haut-niveau du développement et de l intégration des modules en mettant en évidence les composants, les interactions et les dépendances Évolution :met en évidence les points où un système peut être modifié et étendu.

10 Introduction 10 Architecture vs Conception détaillée: L architecture impose des contraintes à la conception tout en laissant certaines décisions en suspens, l architecture ne définit pas une implantation. L analyse décrit le quoi alors que l architecture décrit le comment

11 Historique : Programmation Structuré Un programme informatique suite d étapes (flux de contrôle). Programmation Modulaire Un programme informatique ensemble de composants(les modules, fonctions, structures de donnée, types, etc.) : Apparition des nouvelles architectures logicielles: appels et retours (hiérarchie de contrôle), architecture centrée sur les données, architecture en flot de données, architecture en couches et architecture orientée objets : Développement de l architecture orientée objet Apparition de l architecture à trois couches centrée sur les données (3-tiers)

12 Historique : UML (Unified Modeling Language) norme internationale de représentation de l architecture logicielle. Apparition des systèmes de gestion de base de données (SGBD) Apparition des architectures distribuées. L architecture 3-tiers est maintenant réalisée par le triplet serveur de base de données, serveur d application web et navigateur web : Les bases de données distribuées rendu possible grâce aux technologies Migration de UML 1.1 vers UML 2. Architectures J2EE et SOA

13 Historique 13

14 Modéliser avec UML 14

15 Modéliser avec UML 15 Les vues (structurelles) d une architecture logicielle: Vue: «Représentation de l intégrité d un système selon une perspective lié à un centre d intérêts spécifiques» IEEE

16 Modéliser avec UML 16 Les vues (structurelles) d une architecture logicielle: Vue logique:représentation des fonctionnalités du système décomposé en sous-systèmes (modules + interface) et des relations d utilisation, décomposition et généralisation UML : diagramme de paquetages Vue d implémentation:description de l implémentation (physique) du système logiciel en termes de composants et de connecteurs UML : diagramme de composants Vue de déploiement: Description de l intégration et de la distribution de la partie logicielle sur la partie matérielle UML: diagramme combiné de composants et de déploiement

17 Modéliser avec UML 17 Diagramme de paquetages Diagramme de composants Diagramme combiné de déploiement/composants

18 Eléments Architecturaux 18 Deux ou plusieurs composants interagissent via un connecteur. Éléments architecturaux: composant, connecteur, interface, port.. Chaque élément architectural possède une structure et/ou comportement pouvant être décrit par un modèle UML approprié.

19 Eléments Architecturaux 19 Module: Décomposition modulaire approche naturelle pour appréhender la complexité d un système le module apparaît pendant le développement lors de l exécution on parle de composant Module est composé d une interface et de relations avec d autres modules. L importation et l exportation sont des relations Encapsulation, Abstraction, Couplage et cohésion

20 Eléments Architecturaux 20 Composant: Une partie physique et remplaçable d un système. Autonome servant de bloc de construction pour le système Encapsule un traitement et/ou des données Restreint l accès à ce sous-ensemble au moyen d une interface définie explicitement Exemple : Code source, fichiers binaires, scripts, fichiers exécutables, bases de données, applications, etc.

21 Eléments Architecturaux 21 Interface de composant: Spécifie les service qu offre le composant, elle permet de préciser sa sémantique et les contraintes pour son utilisation, elle permet de définir aussi les services qu il requière des autres composants 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 attachée à un port du composant Port = point de communication du composant Plusieurs interfaces peuvent être attachées à un même port

22 Eléments Architecturaux 22 Dépendances entre composants Dépendance = relation entre deux composants Types de dépendances Un composant peut dépendre d un autre composant qui lui fournit un service ou une information Un composant peut dépendre d une classe qui implémente une partie de son comportement. Dépendance de réalisation Un composant peut dépendre d un artefact (code source, fichier.jar, etc.) qui l implante concrètement.

23 Eléments Architecturaux 23 Connecteur élément architectural qui définit le type d interactions entre les composants et les règles gouvernant ces interaction Un connecteur relie les ports de deux ou plusieurs composants Un connecteur peut avoir un ou plusieurs rôles Communication:rôle le plus fréquent Coordination: contrôle du calcul, de la transmission des données, Conversion : permet l interaction entre composants développés indépendamment dans des langages différents Synchronisation: accès contrôlées aux données partagées, etc. Selon le(s) rôles qu il doit remplir un connecteur peut être: ProcedureCall (comm + coord), DataAccess (comm + conv), Event, Adaptor (conv), (Selon UniCon)

24 Exemple de diagramme de composant Connecteurs Composants Système de distribution de tickets

25 Exemple de diagramme de composant Le connecteur «ProcedureCall» Le composant «Planificateur»

26 Choix d une architecture logicielle Choix d une architecture: Dépend des exigences fonctionnelles et non fonctionnelles 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écomposition en composants (styles architecturaux) et de mode d interactions. => Quelles sont les différentes sortes de style architectural?