Architecture Logicielle

Transcription

1 Architecture Logicielle Chapitre 3: UML pour la description et la documentation d une architecture logicielle Année universitaire 2013/2014 Semestre 1

2 Rappel L architecture d un programme ou d un système informatique est la structure (ou les structures) du système qui comprend les éléments logiciels, leurs propriétés visibles et leurs relations, 2

3 Rappel L architecture d un système est sa conception de haut niveau. N importe quel système complexe est composé de sous-systèmes qui interagissent entre eux. La conception de haut niveau est le processus qui consiste à identifier ces sous-systèmes ainsi que les relations qu il entretiennent. L architecture d un système est le résultat de ce processus. 3

4 Rappel L architecture implique plusieurs choix dont les technologies, les produits et les serveurs a utiliser. Il n y a pas une architecture unique permettant de réaliser le système, il y a plusieurs, Le concepteur ou l'architecte tâchera de choisir la meilleure architecture selon plusieurs critères dont la nature de projet, les compétences de l équipe, les budgets, et outils disponibles, etc. 4

5 Représentation des architectures Il existe plusieurs représentations graphiques des architectures. Une des représentations les plus utilisées est la représentation C&C: Composant et Connecteurs. Un composant est un module logiciel (application, bibliothèque, module, etc.) ou un entrepôt de données (Base de données, Système de fichiers, etc.). Le connecteur représente les interactions entre les composants. La représentation C&C est un graphe contenant des graphes et des connecteurs. 5

6 Composants Un composant est un module logiciel ou un entrepôt de données. Un composant est identifié par son nom qui indique son rôle dans le système. Les composants communique entre eux en utilisant des ports (ou interface). Les architectures utilisent des composants standards: Serveurs, Base de données, application, clients, etc 6

7 Serveurs et Clients Un serveur est un module logiciel qui reponds aux requêtes d autres modules appelés clients. Généralement, les services et les clients sont hébergés dans des machines différentes et communiquent via le réseau (Intranet/Internet). Par exemple, le serveur http répond aux requêtes des clients qui sont les navigateurs Web. 7

8 Application Une application est un module logiciel qui a un rôle défini dans le système logiciel. Par exemple, une application d envoi de mails. 8

9 Base de données Une base de données est un entrepôt stockant les données sous un format normalisé. L interrogation et la modification des données se fait en utilisant un langage spéciale SQL. SQL server, Oracle,Mysql, sont des SGBD connus sur le marché. 9

10 Vue C&C 10

11 Connecteurs Le connecteur modélise une interaction entre deux composants. Un connecteur peut modéliser une interaction simple (appel de procédure) ou une interaction complexe ( par exemple utilisation d un protocole comme http) 11

12 Exemple site JSP 12

13 Vue physique et Vue logique La vue logique d une architecture logiciel définit les principaux composants d une architecture sans se soucier des détails physiques (équipements, machines, etc). La vue physique s intéressent au déploiement physique les différents services. La vue physique est peu précise lors de la conception. Elle devient concrète lors de la phase de déploiement. 13

14 Vue physique et Vue logique 14

15 Vue physique et Vue logique 15

16 Utilisation de l architecture Donne un aperçu de haut niveau qui va faciliter la communication et la compréhension. Aide a comprendre des systèmes existants. Décompose le système en sous systèmes et sous modules ce qui réduit la complexité et facilite la distribution des tâches. Facilite l évolution en remplaçant uniquement le sous système désiré. 16

17 UML pour la description et la documentation d une architecture logicielle

18 UML pour la description et la documentation d une architecture logicielle Diagrammes Structurels ou Diagrammes statiques (Structure Diagram) Diagramme de classes (Class diagram): il représente les classes intervenant dans le système Diagramme d'objets (Object diagram): il sert à représenter les instances de classes (objets) utilisées dans le système Diagramme de composants (Component diagram): il permet de montrer les composants du système d'un point de vue physique, tels qu'ils sont mis en oeuvre (fichiers, bibliothèques, bases de données...) Diagramme de déploiement: il sert à représenter les éléments matériels (ordinateurs, périphériques, réseaux, systèmes de stockage...) et la manière dont les composants du système sont répartis sur ces éléments matériels et interagissent avec eux Diagramme des paquetages (Package Diagram): permet de représenter la hiérarchie des paquetages du projet, leur organisation et leurs interdépendances, simplifie les diagrammes (donc plus simple à comprendre) Diagramme de structures composites (Composite Structure Diagram) : permet de décrire la structure interne d'un objet complexe lors de son exécution (c'est à dire, décrire l'exécution du programme), dont ses points d'interaction avec le reste du système 18

19 UML pour la description et la documentation d une architecture logicielle Diagrammes Comportementaux ou Diagrammes dynamiques (Behavior Diagram) Diagramme des cas d'utilisation (Use case diagram): il décrit les possibilités d'interaction entre le système et les acteurs, c'est-à-dire toutes les fonctionnalités que doit fournir le système Diagramme états-transitions (State Machine Diagram): il montre la manière dont l'état du système (ou de sous-parties)est modifié en fonction des événements du système Diagramme d'activité (Activity Diagram): variante du diagramme d'états-transitions, il permet de représenter le déclenchement d'événements en fonction des états du système et de modéliser des comportements parallélisables (multithreads ou multi-processus) Diagramme d'interactions (Interaction Diagram): Diagramme de séquence (Sequence Diagram): la représentation séquentielle du déroulement des traitements et des interactions entre les éléments du système et/ou des acteurs. Diagramme de communication (Communication Diagram): la représentation simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les objets Diagramme global d'interaction (Interaction Overview Diagram): variante du diagramme d'activité où les nœuds sont des interactions, permet d'associer les notations du diagramme de séquence à celle du diagramme d'activité, ce qui permet de décrire une méthode complexe Diagramme de temps (Timing Diagram): la représentation des interactions où l'aspect temporel est mis en valeur; il permet de modéliser les contraintes d'interaction entre plusieurs objets, comme le changement d'état en réponse à un évènement extérieur 19

20 UML pour la description et la documentation d une architecture logicielle Le modèle 4 +1 de Kruchten (1/6) Le modèle de Kruchten dit modèle des vues est celui adopté dans le Processus unifié. Ici encore, le modèle d'analyse, mentionné vue des cas d'utilisation, constitue le lien et motive la création de tous les diagrammes d'architecture. 20

21 UML pour la description et la documentation d une architecture logicielle Le modèle 4 +1 de Kruchten (2/6) 1. La vue des cas d'utilisation La vue des cas d'utilisation est un modèle d'analyse formalisé par Ivar Jacobson. Un cas d'utilisation est défini comme un ensemble de scénarios d'utilisation, chaque scénario représentant une séquence d'interaction des utilisateurs (acteurs) avec le système. L'intérêt des cas d'utilisation est de piloter l'analyse par les exigences des utilisateurs. Ceux-ci se sentent concernés car ils peuvent facilement comprendre les cas d'utilisation qui les concernent. Cette méthode permet donc d'aider à formaliser les véritables besoins et attentes des utilisateurs; leurs critiques et commentaires étant les briques de la spécification du système. L'ensemble des cas d'utilisation du logiciel en cours de spécification est représenté par un diagramme de cas d'utilisation, chacun des scénarios de celui-ci étant décrit par un ou plusieurs diagrammes dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou d'états-transitions. 21

22 UML pour la description et la documentation d une architecture logicielle Le modèle 4 +1 de Kruchten (2/6) 2. La vue logique La vue logique constitue la principale description architecturale d'un système informatique et beaucoup de petits projets se contentent de cette seule vue. Cette vue décrit, de façon statique et dynamique, le système en termes d'objets et de classes. La vue logique permet d'identifier les différents éléments et mécanismes du système à réaliser. Elle permet de décomposer le système en abstractions et constitue le cœur de la réutilisation. En effet, l'architecte récupérera un maximum de composants des différentes bibliothèques et cadriciels (framework) à sa disposition. Une recherche active de composants libres et/ou commerciaux pourra également être envisagée. La vue logique est représentée, principalement, par des diagrammes statiques de classes et d'objets enrichis de descriptions dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou d'états-transitions. 22

23 UML pour la description et la documentation d une architecture logicielle Le modèle 4 +1 de Kruchten (2/6) 3. La vue des processus (comportement) La vue des processus décrit les interactions entre les différents processus, threads (fils d'exécution) ou tâches, elle permet également d'exprimer la synchronisation et l'allocation des objets. Cette vue permet avant tout de vérifier le respect des contraintes de fiabilité, d'efficacité et de performances des systèmes multitâches. Les diagrammes utilisés dans la vue des processus sont exclusivement dynamiques : diagrammes d'activités, de séquence, diagrammes de communication ou d'étatstransitions. 23

24 UML pour la description et la documentation d une architecture logicielle Le modèle 4 +1 de Kruchten (2/6) 4. La vue de réalisation (implémentation) La vue de réalisation permet de visualiser l'organisation des composants (bibliothèque dynamique et statique, code source...) dans l'environnement de développement. Cette vue permet également de gérer la configuration (auteurs, versions...). Les seuls diagrammes de cette vue sont les diagrammes de composants. 24

25 UML pour la description et la documentation d une architecture logicielle Le modèle 4 +1 de Kruchten (2/6) 5. La vue de déploiement La vue de déploiement représente le système dans son environnement d'exécution. Elle traite des contraintes géographiques (distribution des processeurs dans l'espace), des contraintes de bandes passantes, du temps de réponse et des performances du système ainsi que de la tolérance aux fautes et aux pannes. Cette vue est fort utile pour l'installation et la maintenance régulière du système. Les diagrammes de cette vue sont les diagrammes de composants et les diagrammes de déploiement. 25

26 UML et Architecture logicielle Plusieurs formalismes peuvent décrire une architecture logicielle. UML2 est un bon moyen de représenter une architecture logicielle. Le diagramme de composants peut servir à représenter la vue logique d une architecture. Le diagramme déploiement permet de servir à représenter la vue physique d une architecture 26

27 Diagramme de composants Un composant est une unité autonome dans un système. Un composant définit un système ou un sous système de n importe quel taille. Les diagrammes de composants permettent de modéliser les composants et leurs interactions. Les composants d un système sont facilement réutilisés ou remplacés. 27

28 Diagramme de composants Montre la répartition physique du code Souvent répartis dans des paquetages Les relations s expriment à travers leurs interfaces et des dépendances 28

29 Caractéristique d un composant Un composant est une entité modulaire avec des interfaces bien définies. Les interfaces définissent comment le composant peut être appelé ou intégré. L implémentation de composant est cachée aux entités externes. 29

30 Représentation UML 30

31 Caractéristique d un composant Un composant à un nom unique. Un composant peut être étendu par un stréotype (subsystem, database, executable, serveur, client, ) 31

32 Exemples stéréotypes 32

33 Interfaces Un composant définit l interface en terme d interfaces fournies et d interfaces requises Une interface est une collection d opérations ayant un lien sémantique et qui n ont pas d implémentation. L implémentation des interfaces se fait par une ou plusieurs classes implémentant le composant. Les noms des interfaces commencent par I. Un contrat par C1 et C2 est défini quand C1 fournit une interface I est requise par C2. 33

34 Interfaces: exemple 34

35 Interfaces: exemple 35

36 Interface fournie Une interface fournie définie les fonctions qu un composant pourrait faire. Un exemple: un serveur web peut gérer les requettes HTTP de type get et post. 36

37 Interface requise Définit la (les) interfaces que un composant attend de son environnement. 37

38 Assemblage Un assemblage entre deux composants est lorsqu une même interface est requise pour un composant et fournie par l autre 38

39 Utilisation Un composant C1 dépend d un autre composant C2 lorsque C1 requiert C2 pour son implémentation (C1 appel un des services de C2) En d autres mots, l exécution de C1 requiert la présence de C2. 39

40 Composition Un composant peut être lui-même composé par d autres composants. On parle alors de composition. Par exemple, le navigateur est composé de GetManager (gestionnaire des requêtes get), PostManager( gestionnaire des requêtes post) et Gui (interface). 40

41 Délégation Un composant peut avoir des sous-composants qui incluent des interfaces fournies ou des interfaces requises. La délégation consiste a transférer les interfaces/ requises du composant interne vers le composant externe 41

42 Délégation Exemple 1 Exemple 2 42

43 Paquets Les paquets peuvent être utilisés dans les diagrammes de composants pour organiser les composants 43

44 Styles architecturaux 44

45 Introduction Un style architectural est un modèle définissant comment sera le système. Un style architectural définit quels sont les composants, les connecteurs et les contraintes définissant l architecture d un système. 45

46 Avantages Un style architectural aide a avoir un aperçu du système avant son développement. Les styles sont indépendants des technologies. Plusieurs technologies peuvent réaliser un certain styles. Facilite la réutilisation. Un système peut s appuyer sur plusieurs styles. 46

47 Styles standards Pipe / Filtre Client / Serveur 3-tiers/N-tiers Multi-couches MVC Cloud computing 47

48 Pipe / Filtre Permet à l information d être traitée par plusieurs composants d une manière séquentielle La configuration détermine l ordre de traitement Le filtre est un composant qui traite l information. La pipe est un canal par lequel transite l information. 48

49 Pipe / Filtre fonctionnement Exemple: Unix shell, Windows Powershell 49

50 Pipe / Filtre Avantages Forte décomposition du systèmes Filtres facile à réutiliser Facilite la maintenance La dépendance entre les filtres est faible Inconvénients Ne convient pas aux applications à haute interactivité Les performances dépendent des filtres. 50

51 MVC - définition MVC= Model view Controller Le modèle représente les entités du système Le contrôleur implémente la logique métier et la logique des interactions La vue représente L interface utilisateur 51

52 MVC-Exemple 52

53 MVC Avantages Modèle de conception largement apprécié de la communauté des développeurs Séparation de la logique des interfaces Testabilité accrue Inconvénients Assez complexe Plus d effort de développement car chaque tâche concerne trois couches 53

54 Client-Serveur Le système est composé de deux composants principaux se trouvant généralement dans des machines séparées. Le client envoie des requêtes au serveur Le serveur réagit des requêtes en renvoyant des réponses. L interface est au niveau du client. 54

55 Exemple 55

56 Client-Serveur Avantages Séparation des taches Simple à utiliser Inconvénients Souvent insuffisant pour des cas complexe 56

57 Architecture N-tiers Fragmente le système a plusieurs niveaux Le niveau présentation, le niveau logique ou le niveau données sont des exemples de niveaux Chaque niveau dépend uniquement du niveau qui est supérieur 57

58 Exemple 58

59 Architecture N-tiers Avantages Séparation poussée des tâches Haute fléxibilité Inconvénients Nécessite des ressources matérielles importantes 59

60 SOA- Définition SOA (Service oriented architecture) est une évolution du modèle client serveur SOA est basée sur des services faiblement couplés, indépendants des protocoles, basés sur les standards distribués. Chaque ressources disponible sur le réseau est utilisé comme service. 60

61 Caractéristique des services Les services sont autonomes Les services sont composables Les services sont réutiulisable Une architecture SAO est basé sur un consommateur de service, un fournisseur de service et un registre de service. Un consommateur utilise le service Un fournisseur assure le service Le registre fait le lien entre le fournisseur et le consommateur 61

62 Composant SOA 62

63 Avantages Indépendance et facilité de découverte Permettant l utilisation des application depuis n importe quel équipement 63

64 Cloud Computing Le Cloud computing est une technologie basé sur internet qui permet de fournir des ressources d une manière évolutive sur internet. Le cloud computing est la base de Saas (software as service) Avec Saas, les utilisateurs ne se soucient plus de l évolution et de la maintenance des logiciels. Le cloud permet aux entreprise une réduction des coûts. 64

65 Cloud privé Le cloud est dit privé lorque l entrprise decide de mettre en ouvre le cloud dans sa propre infrastruture 65

66 Diagramme de deploiement 66

67 Introduction Le diagramme de composant s intéresse à l architecture de point de vue logique tandis que le diagramme de déploiement s y intéresse de point de vue physique. le diagramme de déploiement s intéresse aux relations entre les composants et les équipements Les équipements hébergeant des unités logicielles sont appelés nœuds (nodes) 67

68 Introduction Le diagramme de déploiement montre la répartition des processus qui composent le système Il est Important dans le cas d architecture distribuée Concepts fondamentaux: Les noeuds : dispositifs capables d héberger une partie du logiciel Les arcs (Connecteurs): liens physiques connectant les noeuds 68

69 Introduction Le diagramme de déploiement est composé de nœuds et de connecteurs Un nœud représente un équipement dans le système Un connecteur représente une communication entre les nœuds. 69

70 Nœud Un nœud peut être stéréotypé par: device: pour représenter un équipement hardware execution environement: pour déterminer un environnement ou les processus s exécute. 70

71 Exemple Un composant réside physiquement dans un nœud L artifact est la manifestation physique d un composant ou tout autre élément physique (document, exécutable, code source.) 71

72 Exemple Exemple 1 Exemple 2 72

73 Exemple Exemple 3 73

74 Lien de communication Exemple 1 Exemple 2 74