Modélisation de l'architecture d'un système logiciel

Article
06/10/2015

Pour garantir que votre application ou votre système logiciel satisfait les besoins de vos utilisateurs, vous pouvez créer des modèles dans Visual Studio Ultimate dans le cadre de votre description de la structure et du comportement globaux de votre application ou de votre système logiciel. À l'aide de modèles, vous pouvez également décrire des modèles utilisés tout au long de la conception. Ces modèles vous aident à comprendre l'architecture existante, discuter les modifications et communiquer clairement vos intentions.

L'objectif d'un modèle est de réduire les ambiguïtés qui se produisent dans les descriptions en langage naturel, et d'aider vos collègues et vous-même à visualiser la conception et à discuter de conceptions alternatives. Un modèle doit être utilisé avec d'autres documents ou discussions. Un modèle ne représente pas en lui-même une spécification complète de l'architecture.

Notes

Tout au long de cette rubrique, le « système » signifie le logiciel que vous développez.Il peut s'agir d'une importante collection comprenant de nombreux composants logiciels et matériels, d'une application unique ou encore d'une partie d'application.

L'architecture d'un système peut être divisée en deux zones :

Conception de niveau supérieur. Il s'agit d'une description des composants principaux et de la façon dont ils interagissent entre eux pour accomplir chaque spécification. Si le système est important, chaque composant peut avoir sa propre conception de niveau supérieur qui affiche la façon dont il est subdivisé en plus petits composants.
Modèles de conception et conventions utilisées dans les conceptions de composants. Un modèle décrit une approche particulière permettant d'atteindre un objectif de programmation. En utilisant les mêmes modèles dans toute une conception, votre équipe peut réduire le coût engendré par les modifications et le développement du nouveau logiciel.

Conception de niveau supérieur

Une conception de niveau supérieur décrit les composants principaux de votre système et de quelle façon ils interagissent entre eux pour atteindre les objectifs de la conception. Les activités dans la liste suivante sont impliquées dans le développement de la conception de niveau supérieur, bien qu'elles ne le soient pas forcément dans une séquence particulière.

Si vous mettez à jour le code existant, vous pouvez commencer par décrire les composants principaux. Assurez-vous que vous comprenez toutes les modifications apportées aux besoins des utilisateurs, puis ajoutez ou modifiez des interactions entre les composants. Si vous développez un nouveau système, commencez par comprendre les fonctionnalités principales des besoins des utilisateurs. Vous pouvez explorer ensuite des séquences d'interactions pour les cas d'usage principaux, puis consolider les séquences dans une conception de composant.

Dans chaque cas, il est utile de développer les activités différentes en parallèle, et de développer le code et les tests lors d'une phase préliminaire. Évitez d'essayer de terminer l'un de ces aspects avant d'en démarrer un autre. En général, les spécifications et votre compréhension de la meilleure méthode pour concevoir le système évolueront pendant l'écriture et le test du code. Par conséquent, vous devez commencer par comprendre et coder les fonctionnalités principales des spécifications et de votre conception. Remplissez les détails dans les itérations ultérieures du projet.

Compréhension des spécifications. Le point de départ de toute conception est une compréhension claire des besoins des utilisateurs.
Modèles architecturaux. Choix que vous avez faits concernant les technologies principales et les éléments architecturaux du système.
Composants et leurs interfaces. Vous pouvez dessiner des diagrammes de composants pour afficher les parties majeures du système et afficher les interfaces via lesquelles ils interagissent entre eux. Les interfaces de chaque composant incluent tous les messages que vous avez identifiés dans les diagrammes de séquence.
Interactions entre les composants. Pour chaque cas d'usage, événement ou message entrant, vous pouvez dessiner un diagramme de séquence qui affiche comment les composants principaux du système interagissent pour accomplir la réponse requise.
Modèle de données des composants et des interfaces. Vous pouvez dessiner des diagrammes de classes pour décrire les informations passées entre des composants et stockées à l'intérieur des composants.

Compréhension des spécifications

La conception de niveau supérieur d'une application complète est développée plus efficacement avec un modèle de spécifications ou une autre description des besoins des utilisateurs. Pour plus d'informations sur les modèles de spécifications, consultez Modélisation des besoins des utilisateurs.

Si le système que vous développez est un composant dans un système plus important, une partie ou toutes vos spécifications peuvent être personnifiées dans les interfaces de programmation.

Le modèle de spécifications fournit ces renseignements essentiels :

Interfaces fournies. Une interface fournie répertorie les services ou les opérations que le système ou le composant doit fournir à ses utilisateurs, s'ils sont utilisateurs humains ou d'autres composants logiciels.
Interfaces requises. Une interface requise répertorie les services ou les opérations que le système ou le composant peut utiliser. Dans certains cas, vous serez en mesure de concevoir tous ces services dans le cadre de votre propre système. Dans d'autres cas, surtout si vous concevez un composant qui peut être combiné avec d'autres composants dans de nombreuses configurations, l'interface requise sera définie par des considérations externes.
Impératifs de qualité de service. Performance, sécurité, robustesse et autres objectifs et contraintes que le système doit rencontrer.

Le modèle de spécifications est écrit du point de vue des utilisateurs de votre système, qu'il s'agisse de personnes ou d'autres composants logiciels. Ils ne savent rien des mécanismes internes de votre système. Par contraste, votre objectif dans un modèle architectural est de décrire les mécanismes internes et d'afficher la façon dont ils satisfont les besoins des utilisateurs.

Maintenir à part les spécifications et les modèles architecturaux s'avère utile parce que cela simplifie les discussions sur les spécifications avec les utilisateurs. Cela vous permet également de refactoriser la conception et de considérer d'autres architectures tout en conservant inchangées les spécifications.

Vous pouvez séparer les spécifications et les modèles architecturaux de deux autres manières :

Conservez-les dans la même solution mais dans des projets différents. Ils s'afficheront comme des modèles séparés dans l'Explorateur de modèles UML. Différents membres de l'équipe peuvent travailler en parallèle sur les modèles. Les genres limités de traçage peuvent être créés entre les modèles.
Placez-les dans le même modèle UML, mais dans des packages différents. Cela simplifie le traçage des dépendances entre les modèles, mais empêche plusieurs personnes de travailler en même temps sur le modèle. En outre, un modèle très important prendra plus longtemps à charger dans Visual Studio. Cette approche est par conséquent moins appropriée pour les projets importants.

La quantité de détails que vous devez indiquer dans un modèle de spécifications ou architectural dépend de l'échelle du projet, et de la taille et de la distribution de l'équipe. Une petite équipe sur un projet court peut ne pas passer autre que tracer un diagramme de classes des concepts d'entreprise et de quelques modèles de conception ; un grand projet distribué sur plusieurs zones aurait besoin de beaucoup plus de détails.

Modèles architecturaux.

Au début d'un développement, vous devez choisir les technologies et les éléments principaux desquels la conception dépend. Les zones dans lesquelles ces choix doivent être faits incluent les éléments suivants :

choix de technologie de base, tels que le choix entre une base de données et un système de fichiers, et le choix entre une application en réseau et un client Web, et ainsi de suite ;
choix d'infrastructure, tels qu'un choix entre Windows Workflow Foundation ou ADO.NET Entity Framework ;
choix de méthode d'intégration, par exemple entre un bus de service d'entreprise ou un canal point à point.

Ces choix sont fréquemment déterminés par les impératifs de qualité de service tels que l'échelle et la flexibilité, et peuvent être faits avant que les spécifications détaillées ne soient connues. Dans un système important, la configuration matérielle et la configuration logicielle sont intimement liées.

Les sélections que vous faites affectent l'utilisation et l'interprétation du modèle architectural. Par exemple, dans un système qui utilise une base de données, les associations dans un diagramme de classes peuvent représenter des relations ou des clés étrangères dans la base de données, tandis que dans un système basé sur les fichiers XML, les associations peuvent indiquer des renvois qui utilisent XPath. Dans un système distribué, les messages dans un diagramme de séquence peuvent représenter des messages sur le câble ; dans une application autonome, ils peuvent représenter des appels de fonction.

Composants et leurs interfaces

Les recommandations principales de cette section sont les suivantes :

Créez des diagrammes de composants pour afficher les parties principales de votre système.
Dessinez des dépendances entre les composants ou leurs interfaces pour afficher la structure du système.
Utilisez les interfaces sur les composants pour afficher les services que chaque composant fournit ou requiert.
Dans une conception importante, vous pouvez dessiner des diagrammes séparés pour décomposer chaque composant en plus petites parties.

Ces points sont développés dans le reste de cette section.

Composants

Les vues centrales d'un modèle d'architecture sont les diagrammes de composants qui affichent les parties principales du système et la façon dont ils dépendent les uns des autres. Pour plus d'informations sur les diagrammes de composants, consultez Diagrammes de composants UML : référence.

Diagramme de composant UML présentant les parties

Un diagramme de composant typique pour un système important peut inclure les composants suivants :

Présentation. Fournit l'accès à l'utilisateur, en s'exécutant en général sur un navigateur Web.
Composants de service Web. Fournit la connexion entre les clients et les serveurs.
Contrôleurs de cas d'usage. Guident l'utilisateur via les étapes de chaque scénario.
Cœur du métier. Contient les classes basées sur les classes dans le modèle de spécifications, implémente les opérations clés et impose des contraintes d'entreprise.
Base de données. Stocke les objets métier.
Composants de journalisation et de gestion des erreurs.

Dépendances entre composants

En plus des composants eux-mêmes, vous pouvez afficher les dépendances entre elles. Une flèche de dépendance entre deux composants indique que les modifications apportées à une conception pourraient affecter la conception de l'autre. Cela se produit habituellement parce qu'un composant utilise les services ou les fonctions fournies par l'autre composant, directement ou indirectement.

Une architecture correctement structurée a une disposition claire des dépendances, dans lesquelles ces conditions sont remplies :

Il n'y a pas de boucles dans le graphique de dépendance.
Les composants peuvent être réorganisés en couches dans lesquelles chaque dépendance part d'un composant dans une couche et va vers un composant dans la couche suivante. Toutes les dépendances entre deux couches vont dans la même direction.

Vous pouvez afficher directement des dépendances entre des composants, ou vous pouvez afficher des dépendances entre des interfaces obligatoires et fournies jointes aux composants. En utilisant des interfaces, vous pouvez définir les opérations qui sont utilisées dans chaque dépendance. En général, les dépendances sont indiquées entre des composants lorsque les diagrammes sont dessinés, puis ils sont remplacés par des dépendances entre des interfaces à mesure que des compléments d'information sont ajoutés. Les deux versions sont des descriptions correctes du logiciel, mais la version avec les interfaces fournit plus de détails que la version antérieure.

La gestion des dépendances est très importante pour la production de logiciel susceptible d'être mis à jour. Les diagrammes de composants doivent répercuter toutes les dépendances dans votre code. Si le code existe déjà, assurez-vous que toutes les dépendances sont affichées dans les diagrammes. Si le code est développé, assurez-vous qu'il n'inclut pas les dépendances qui ne sont pas planifiées dans le diagramme de composant. Pour vous aider à découvrir des dépendances dans le code, vous pouvez générer des diagrammes de couche. Pour vous aider à garantir que vos contraintes de dépendances planifiées sont respectées, vous pouvez valider le code par rapport aux diagrammes de couche. Pour plus d'informations, consultez Diagrammes de couche : référence.

Interfaces

En plaçant des interfaces sur vos composants, vous pouvez séparer et nommer les groupes importants d'opérations fournies par chaque composant. Par exemple, les composants dans un système de ventes basé sur le Web peuvent avoir une interface à travers laquelle les clients achètent des marchandises, une interface à travers laquelle les fournisseurs mettent à jour leurs catalogues et une troisième interface à travers laquelle le système est géré.

Un composant peut avoir un nombre quelconque d'interfaces fournies et requises. Les interfaces fournies affichent les services que le composant fournit à d'autres composants. Les interfaces requises affichent des services que le composant utilise dans d'autres composants.

Si vous définissez les deux interfaces fournies et requises, cela vous permet de séparer proprement le composant du reste de la conception et d'utiliser ainsi ces techniques :

Placez le composant dans un atelier de test dans lequel les composants environnants sont simulés par ce dernier.
Développez votre composant indépendamment des autres composants.
Réutilisez le composant dans d'autres contextes en associant ses interfaces aux différents composants.

Lorsque vous souhaitez définir la liste d'opérations dans une interface, vous pouvez créer une autre vue de l'interface sur un diagramme de classes UML. Pour ce faire, trouvez l'interface dans l'Explorateur de modèles UML et faites-la glisser sur un diagramme de classes. Vous pouvez ensuite ajouter des opérations à l'interface.

Une opération dans une interface UML peut représenter toute façon dont un comportement de composant peut être appelé. Cela peut représenter une requête de service Web, un signal ou une interaction d'un autre genre, ou un appel de fonction de programme ordinaire.

Pour déterminer les opérations à ajouter, créez des diagrammes de séquence pour indiquer de quelle façon les composants interagissent entre eux. Consultez Interactions entre les composants. Chacun de ces diagrammes de séquence affiche les interactions qui se produisent dans un cas d'usage différent. De cette manière, vous pouvez effectuer progressivement des ajouts à la liste d'opérations dans l'interface de chaque composant, à mesure que vous explorez les cas d'usage.

Décomposition d'un composant en parties

Vous pouvez appliquer la procédure décrite dans les sections précédentes à chaque composant.

Dans chaque composant, vous pouvez afficher ses sous-composants en tant que parties. Effectivement, une partie est un attribut de son composant parent, qui est un genre de classe. Chaque partie a son propre type, qui peut être un composant. Vous pouvez placer ce composant sur un diagramme et afficher ses parties. Pour plus d'informations, consultez Diagrammes de composants UML : indications.

Il est utile d'appliquer cette technique au système entier. Dessinez-le comme un composant unique et affichez ses composants principaux en tant que parties. Cela vous aide à identifier clairement les interfaces de votre système avec le monde externe.

Lorsque la conception de l'un de vos composants utilise un autre composant, vous avez fréquemment le choix entre le représenter en tant que partie ou en tant que composant séparé auquel vous accédez via une interface requise.

Utilisez les parties dans les situations suivantes :

La conception du composant parent doit toujours utiliser le type de composant de la partie. Par conséquent, la conception de la partie s'intègre à la conception du composant parent.
Le composant parent n'a aucune existence concrète en lui-même. Par exemple, vous pourriez avoir un composant conceptuel appelé Couche de présentation qui représente une collection de vrais composants qui gèrent les vues et les interactions utilisateurs.

Utilisez des composants séparés dont l'accès se fait via des interfaces requises dans ces situations :

Le composant requis peut être associé via ses interfaces aux différents composants fournissant au moment de l'exécution.
La conception est telle qu'il serait facile de remplacer un fournisseur par un autre.

L'utilisation d'interfaces requises est habituellement préférable à l'utilisation de parties. Bien que la conception puisse prendre plus de temps que prévu, le système qui en résulte est plus flexible. Il est également plus facile de tester les composants séparément. Cela limite les associations dans leurs plans de développement.

Interactions entre les composants.

Les recommandations principales de cette section sont les suivantes :

Identifiez les cas d'usage de votre système.
Pour chaque cas d'usage, dessinez un ou plusieurs diagrammes pour indiquer comment les composants de votre système parviennent au résultat requis en collaborant l'un avec l'autre et avec les utilisateurs. Habituellement, ce sont des diagrammes de séquence ou des diagrammes d'activités.
Utilisez les interfaces pour spécifier les messages reçus par chaque composant.
Décrivez les effets des opérations dans les interfaces.
Répétez la procédure pour chaque composant, en affichant les interactions entre ses parties.

Par exemple, dans un système de ventes basé sur le Web, le modèle de spécifications peut définir l'achat d'un client comme un cas d'usage. Vous pouvez créer un diagramme de séquence pour afficher les interactions qui existent entre le client et ses composants dans la couche de présentation, et pour afficher les interactions qu'ils ont avec les composants de la comptabilité et de l'entrepôt.

Identification des événements de lancement

Le travail effectué par la plupart des systèmes logiciels peut être divisé de manière commode par les réponses qu'il donne aux différentes entrées ou événements. L'événement de lancement peut être l'un des événements suivants :

Première action dans un cas d'usage. Il peut s'afficher dans le modèle de spécifications comme une étape dans un cas d'usage, ou une action dans un diagramme d'activités. Pour plus d'informations, consultez Diagrammes de cas d'usage UML : indications et Diagrammes d'activités UML : instructions.
Message à une interface de programmation. Si le système que vous développez est un composant d'un système plus important, il doit être décrit comme une opération dans l'une des interfaces du composant. Consultez Composants et leurs interfaces.
Condition particulière surveillée par votre système, ou événement normal tel qu'une heure.

Décrire les calculs

Dessinez des diagrammes de séquence pour indiquer comment les composants répondent à l'événement initial.

Dessinez une ligne de vie pour chaque instance de composant qui participe à une séquence typique. Dans certains cas, il peut y avoir plusieurs instances de chaque type. Si vous avez décrit votre système entier comme un composant unique, il doit y avoir une ligne de vie pour chaque partie qu'il contient.

Pour plus d'informations, consultez Diagrammes de séquence UML : indications.

Dans certains cas, les diagrammes d'activités sont également utiles. Par exemple, si vos composants ont une circulation de données continue, vous pouvez le décrire comme un flux d'objet. Si votre composant a un algorithme complexe, vous pouvez le décrire comme un flux de contrôle. Assurez-vous que vous présentez de manière claire le composant qui exécute chaque action, par exemple au moyen de commentaires. Pour plus d'informations, consultez Diagrammes d'activités UML : instructions.

Spécifier les opérations

Les diagrammes affichent des opérations exécutées par chaque composant, représentées en tant que messages sur un diagramme de séquence, ou en tant qu'actions dans un diagramme d'activités.

Rassemblez ces opérations pour chaque composant. Créez des interfaces fournies sur le composant et ajoutez les opérations aux interfaces. En général, une interface séparée est utilisée pour chaque type de client. Les opérations sont plus facilement ajoutées aux interfaces dans l'Explorateur de modèles UML. De la même manière, collectez les opérations utilisées par chaque composant à partir des autres composants, et placez-les dans les interfaces requises jointes au composant.

Il est utile d'ajouter des commentaires aux diagrammes d'activités ou de séquence, de noter ce qui a été accompli après chaque opération. Vous pouvez également écrire l'effet de chaque opération dans sa propriété Local Postcondition.

Modèle de données des composants et des interfaces

Définissez les paramètres et les valeurs de retour de chaque opération dans les interfaces de composants. Lorsque les opérations représentent des appels tels que les requêtes de services Web, les paramètres sont ces renseignements envoyés dans le cadre de la requête. Lorsque plusieurs valeurs sont retournées d'une opération, vous pouvez utiliser des paramètres dont la propriété Direction a la valeur Out.

Chaque paramètre et la valeur de retour a un type. Vous pouvez définir ces types à l'aide des diagrammes de classes UML. Vous n'avez pas à représenter le détail d'implémentation dans ces diagrammes. Par exemple, si vous décrivez des données transmises au format XML, vous pouvez utiliser une association pour représenter tout genre de renvoi entre nœuds du XML et utiliser des classes pour représenter les nœuds.

Utilisez les commentaires pour décrire des contraintes d'entreprise sur les associations et les attributs. Par exemple, si tous les éléments sur la commande d'un client doivent provenir du même fournisseur, vous pouvez décrire cela en faisant référence aux associations entre les éléments de la commande et les éléments figurant sur le catalogue de produits, et entre l'élément du catalogue et son fournisseur.

Modèles de design

Un modèle de conception est un cadre régissant la façon de concevoir un aspect particulier du logiciel, surtout un aspect qui se reproduit dans les différentes parties du système. En adoptant une approche uniforme à travers le projet, vous pouvez réduire le coût de conception, garantir la cohérence dans l'interface utilisateur et réduire le coût de compréhension et de modification du code.

Quelques modèles de conception généraux tels que l'Observateur sont bien connus et largement applicables. De plus, il existe des modèles qui sont seulement applicables à votre projet. Par exemple, dans un système de ventes Web, il y a plusieurs opérations dans le code lorsque des modifications sont apportées à la commande d'un client. Pour garantir que l'état de la commande est correctement affiché à chaque étape, toutes ces opérations doivent suivre un protocole particulier pour mettre à jour la base de données.

La partie du travail d'architecture logicielle consiste à déterminer quels modèles doivent être adoptés au niveau de la conception. C'est habituellement une tâche progressive, parce que de nouveaux modèles et des améliorations apportées aux modèles existants verront le jour au fil du projet. Il est utile d'organiser le plan de développement afin que vous testiez chacun de vos modèles de conception lors d'une phase préliminaire.

La plupart des modèles de conception peuvent être personnifiés en partie dans le code d'infrastructure. La partie du modèle peut être réduite afin d'obliger le développeur à utiliser des classes ou composants particuliers, tels qu'une couche d'accès à la base de données qui garantit que la base de données est correctement gérée.

Un modèle de conception est décrit dans un document et inclut généralement ces parties :

Nom.
Description du contexte dans lequel il est applicable. Quels critères doivent inciter un développeur à envisager l'application de ce modèle ?
Brève explication du problème qu'il résout.
Modèle des parties principales et de leurs relations. Il peut s'agir de classes ou de composants et d'interfaces, avec des associations et des dépendances entre eux. Les éléments se partagent habituellement en deux catégories :
- les éléments que le développeur doit dupliquer dans chaque partie du code où le modèle est utilisé. Vous pouvez utiliser des types de modèles pour décrire ces derniers. Pour plus d'informations, consultez Diagrammes de cas d'usage UML : référence ;
- les éléments qui décrivent des classes d'infrastructure que le développeur doit utiliser.
Modèle des interactions entre les parties, à l'aide de diagrammes de séquence ou d'activités.
Conventions d'affectation de noms.
Description de la façon dont le modèle résout le problème.
Description de variations que les développeurs peuvent être en mesure d'adopter.