Modèles d'architecture

L'architecture logicielle implique la structure de haut niveau de l'abstraction du système logiciel, en utilisant la décomposition et la composition, avec un style architectural et des attributs de qualité. La conception d'une architecture logicielle doit se conformer aux principales exigences de fonctionnalité et de performance du système, ainsi que satisfaire les exigences non fonctionnelles telles que la fiabilité, l'évolutivité, la portabilité et la disponibilité.

Une architecture logicielle doit décrire son groupe de composants, leurs connexions, les interactions entre eux et la configuration de déploiement de tous les composants.

Une architecture logicielle peut être définie de plusieurs manières -

  • UML (Unified Modeling Language) - UML est l'une des solutions orientées objet utilisées dans la modélisation et la conception de logiciels.

  • Architecture View Model (4+1 view model) - Le modèle de vue d'architecture représente les exigences fonctionnelles et non fonctionnelles de l'application logicielle.

  • ADL (Architecture Description Language) - ADL définit l'architecture logicielle de manière formelle et sémantique.

UML

UML est l'acronyme de Unified Modeling Language. C'est un langage pictural utilisé pour créer des plans logiciels. UML a été créé par Object Management Group (OMG). Le projet de spécification UML 1.0 a été proposé à l'OMG en janvier 1997. Il sert de norme pour l'analyse des exigences logicielles et les documents de conception qui sont à la base du développement d'un logiciel.

UML peut être décrit comme un langage de modélisation visuelle à usage général pour visualiser, spécifier, construire et documenter un système logiciel. Bien que UML soit généralement utilisé pour modéliser un système logiciel, il n'est pas limité dans cette limite. Il est également utilisé pour modéliser des systèmes non logiciels tels que les flux de processus dans une unité de fabrication.

Les éléments sont comme des composants qui peuvent être associés de différentes manières pour créer une image UML complète, connue sous le nom de diagram. Il est donc très important de comprendre les différents diagrammes pour mettre en œuvre les connaissances dans des systèmes réels. Nous avons deux grandes catégories de diagrammes et ils sont ensuite divisés en sous-catégories, c'est-à-direStructural Diagrams et Behavioral Diagrams.

Diagrammes structurels

Les diagrammes structurels représentent les aspects statiques d'un système. Ces aspects statiques représentent les parties d'un diagramme qui forment la structure principale et sont donc stables.

Ces parties statiques sont représentées par des classes, des interfaces, des objets, des composants et des nœuds. Les diagrammes structurels peuvent être subdivisés comme suit -

  • Diagramme de classe
  • Diagramme d'objets
  • Diagramme de composants
  • Diagramme de déploiement
  • Diagramme de paquet
  • Structure composite

Le tableau suivant fournit une brève description de ces schémas -

N ° Sr. Diagramme et description
1

Class

Représente l'orientation objet d'un système. Montre comment les classes sont statiquement liées.

2

Object

Représente un ensemble d'objets et leurs relations au moment de l'exécution et représente également la vue statique du système.

3

Component

Décrit tous les composants, leur interrelation, leurs interactions et l'interface du système.

4

Composite structure

Décrit la structure interne du composant, y compris toutes les classes, les interfaces du composant, etc.

5

Package

Décrit la structure et l'organisation du package. Couvre les classes dans le package et les packages dans un autre package.

6

Deployment

Les diagrammes de déploiement sont un ensemble de nœuds et de leurs relations. Ces nœuds sont des entités physiques sur lesquelles les composants sont déployés.

Diagrammes comportementaux

Les diagrammes comportementaux capturent essentiellement l'aspect dynamique d'un système. Les aspects dynamiques sont essentiellement les parties changeantes / mobiles d'un système. UML a les types suivants de diagrammes comportementaux -

  • Diagramme de cas d'utilisation
  • Diagramme de séquençage
  • Schéma de communication
  • Diagramme graphique d'état
  • Diagramme d'activité
  • Présentation de l'interaction
  • Diagramme de séquence temporelle

Le tableau suivant fournit une brève description de ces schémas -

N ° Sr. Diagramme et description
1

Use case

Décrit les relations entre les fonctionnalités et leurs contrôleurs internes / externes. Ces contrôleurs sont appelés acteurs.

2

Activity

Décrit le flux de contrôle dans un système. Il se compose d'activités et de liens. Le flux peut être séquentiel, simultané ou ramifié.

3

State Machine/state chart

Représente le changement d'état d'un système en fonction des événements. Il décrit essentiellement le changement d'état d'une classe, d'une interface, etc. Utilisé pour visualiser la réaction d'un système par des facteurs internes / externes.

4

Sequence

Visualise la séquence d'appels dans un système pour exécuter une fonctionnalité spécifique.

5

Interaction Overview

Combine les diagrammes d'activité et de séquence pour fournir une vue d'ensemble du flux de contrôle du système et des processus métier.

6

Communication

Identique au diagramme de séquence, sauf qu'il se concentre sur le rôle de l'objet. Chaque communication est associée à un ordre de séquence, un numéro plus les messages passés.

sept

Time Sequenced

Décrit les modifications par messages d'état, de condition et d'événements.

Modèle de vue d'architecture

Un modèle est une description complète, basique et simplifiée de l'architecture logicielle qui se compose de plusieurs vues d'un point de vue ou d'un point de vue particulier.

Une vue est une représentation d'un système entier du point de vue d'un ensemble de préoccupations liées. Il est utilisé pour décrire le système du point de vue de différentes parties prenantes telles que les utilisateurs finaux, les développeurs, les chefs de projet et les testeurs.

4 + 1 voir le modèle

Le modèle de vue 4 + 1 a été conçu par Philippe Kruchten pour décrire l'architecture d'un système gourmand en logiciels basé sur l'utilisation de vues multiples et simultanées. C'est unmultiple viewmodèle qui répond aux différentes caractéristiques et préoccupations du système. Il normalise les documents de conception du logiciel et rend la conception facile à comprendre par toutes les parties prenantes.

Il s'agit d'une méthode de vérification d'architecture pour étudier et documenter la conception d'architecture logicielle et couvre tous les aspects de l'architecture logicielle pour toutes les parties prenantes. Il fournit quatre vues essentielles -

  • The logical view or conceptual view - Il décrit le modèle objet de la conception.

  • The process view - Il décrit les activités du système, capture les aspects de concurrence et de synchronisation de la conception.

  • The physical view - Il décrit le mappage du logiciel sur le matériel et reflète son aspect distribué.

  • The development view - Il décrit l'organisation ou la structure statique du logiciel dans son développement d'environnement.

Ce modèle de vue peut être étendu en ajoutant une autre vue appelée scenario view ou use case viewpour les utilisateurs finaux ou les clients de systèmes logiciels. Il est cohérent avec les quatre autres vues et est utilisé pour illustrer l'architecture servant de vue «plus un», (4 + 1) modèle de vue. La figure suivante décrit l'architecture logicielle à l'aide du modèle à cinq vues simultanées (4 + 1).

Pourquoi s'appelle-t-il 4 + 1 au lieu de 5?

le use case viewa une signification particulière car il détaille les exigences de haut niveau d'un système tandis que d'autres vues détaillent - comment ces exigences sont réalisées. Lorsque les quatre autres vues sont terminées, il est effectivement redondant. Cependant, toutes les autres vues ne seraient pas possibles sans elle. L'image et le tableau suivants montrent la vue 4 + 1 en détail -

Logique Processus Développement Physique Scénario
La description Affiche le composant (objet) du système ainsi que leur interaction Affiche les processus / règles de flux de travail du système et comment ces processus communiquent, se concentre sur la vue dynamique du système Donne des vues de blocs de construction du système et décrit l'organisation statique des modules du système Affiche l'installation, la configuration et le déploiement de l'application logicielle Montre que la conception est terminée en effectuant la validation et l'illustration
Visionneuse / titulaire de pieu Utilisateur final, analystes et concepteur Intégrateurs et développeurs Programmeur et chefs de projets logiciels Ingénieur système, opérateurs, administrateurs système et installateurs système Tous les points de vue de leurs opinions et évaluateurs
Considérer Exigences fonctionnelles Prérogatives non fonctionnelles Organisation du module logiciel (réutilisation de la gestion des logiciels, contrainte des outils) Exigence non fonctionnelle concernant le matériel sous-jacent Cohérence et validité du système
UML - Diagramme Classe, état, objet, séquence, diagramme de communication Diagramme d'activité Composant, diagramme de package Diagramme de déploiement Diagramme de cas d'utilisation

Langages de description d'architecture (ADL)

Un ADL est un langage qui fournit la syntaxe et la sémantique pour définir une architecture logicielle. Il s'agit d'une spécification de notation qui fournit des fonctionnalités pour modéliser l'architecture conceptuelle d'un système logiciel, qui se distingue de l'implémentation du système.

Les ADL doivent prendre en charge les composants de l'architecture, leurs connexions, leurs interfaces et leurs configurations qui constituent le bloc de construction de la description de l'architecture. C'est une forme d'expression à utiliser dans les descriptions d'architecture et offre la possibilité de décomposer des composants, de combiner les composants et de définir les interfaces des composants.

Un langage de description d'architecture est un langage de spécification formel, qui décrit les fonctionnalités logicielles telles que les processus, les threads, les données et les sous-programmes ainsi que les composants matériels tels que les processeurs, les périphériques, les bus et la mémoire.

Il est difficile de classer ou de différencier une ADL et un langage de programmation ou un langage de modélisation. Cependant, il y a des exigences suivantes pour qu'une langue soit classée comme ADL -

  • Il devrait être approprié pour communiquer l'architecture à toutes les parties concernées.

  • Il doit être adapté aux tâches de création, de raffinement et de validation d'architecture.

  • Il doit fournir une base pour une mise en œuvre ultérieure, il doit donc être en mesure d'ajouter des informations à la spécification ADL pour permettre à la spécification système finale d'être dérivée de l'ADL.

  • Il doit avoir la capacité de représenter la plupart des styles architecturaux courants.

  • Il doit prendre en charge les capacités analytiques ou fournir des implémentations de prototypes de génération rapide.