Modelisation de L'architecture Logicielle

Mastère Professionnel co-construit
en Ingénierie Des Applications Web-Nuagiques

"MPWIN"
Modélisation de l’architecture logicielle SBS –-2020

Introduction
Pour faire face à la complexité croissante des systèmes d’information, de nouvelles méthodes et
outils ont été créées. Nous construisons des modèles parce qu’il est difficile, voire impossible, de
maîtriser la complexité sans modélisation abstraite au delà d’une certaine taille. En outre, le choix du
modèle à créer est important.
Un modèle est une abstraction de la réalité permettant de mieux comprendre le système, Il est
important d’étudier le système logiciel selon son architecture et d’exprimer comment ses
composants et ses entités interagissent pour remplir une fonction logiciel dans un langage donné.
La modélisation à base de graphiques est généralement plus précise qu’une description informelle
en langage naturel. C’est un premier niveau de formalisme, suffisamment léger pour être compris
par le client, suffisamment formel pour pouvoir proposer une première analyse.
Modélisation
Le processus de modélisation vise à obtenir une solution répondant aux exigences du client. La
solution finalement retenue n’est pas obtenue en une seule itération. Plusieurs étapes sont
nécessaires, ces étapes successives permettent de raffiner le niveau de détails du système à réaliser.
Les premières étapes donnent une vision à très gros grains et permettent d’avancer dans la
compréhension du problème.
Par analogie avec un architecte qui dessine plusieurs plans pour concevoir une maison, la conception
d’un système informatique est organisée dans une architecture de modélisation qui prévoit plusieurs
visions du même problème pour aider à trouver une solution acceptable. La cohérence entre les
différentes vues du système est importante, chaque vue ciblant des catégories différentes
d’intervenants ayant des besoins différents.
Lorsqu’une équipe collabore au développement d’un système informatique (de taille conséquente),
trop de détails empêchent d’avoir une vue synthétique compréhensible par tous les participants au
projet informatique, et trop peu d’informations conduit à des interprétations différentes et
contradictoires. À partir d’une certaine taille et complexité, l’informatisation d’un système nécessite un
processus de modélisation.
Quelque soit la taille du problème, une phase de modélisation est une aide au développement du
système informatique. Cependant, souvent, le nombre de personnes qui participent à la résolution du
problème (clients, équipe de développement, équipe de maintenance) est un des éléments jouant
fortement dans la décision de passer par une phase de modélisation. Plus le nombre de personnes est
important, plus les échanges de documents sont importants.
Le processus de modélisation est nécessaire pendant toute la durée de vie du projet : discussion avec
les clients, analyse du système à réaliser, documentation commune entre les développeurs, etc.
La pérennité de l’informatisation réalisée est un autre élément justifiant la décision de modéliser le
système. En effet, le développement mais aussi la maintenance corrective et la maintenance évolutive
du système bénéficient de l’existence du modèle en tant que documentation de référence.
Le modèle permet donc de spécifier le système à réaliser/réalisé, de valider le modèle vis-à-vis des
clients, de fournir un guide pour la construction du système pour organiser les structures de données
et le comportement du système, et de documenter le système et les décisions prises.
Un modèle est une abstraction de la réalité. C’est donc une simplification du monde réel. La
problématique consiste alors à trouver le bon niveau d’abstraction et à exprimer les concepts du
monde réel dans un langage assez abstrait mais aussi précis qu’un langage de programmation pour que
ce langage soit interprétable par un programme informatique.
Le processus d’informatisation consiste à définir des étapes pour aller d’un cahier des charges rédigé
en langage naturel à une mise en œuvre dans un code source particulier. Le modèle du système dans les
premières phases de ce processus est nécessairement une simplification du système réel. Le processus
de modélisation vise à mieux cerner les limites du système à réaliser. Ensuite, les modèles sont raffinés
de plus en plus pour aboutir au code.
Limites de la
modélisations
Le souci avec les modélisations est que on voit des diagrammes d’architecture dans tous les
systèmes d’information. On reconnaît leur utilité. La plupart des équipes en font pour documenter
leur solution. Les architectes s’en servent pour dessiner les interactions entre les systèmes. Par
contre, ils n’ont jamais le même formalisme
De plus, les outils permettant de modéliser sont également très hétérogènes. Il y a les outils dédié à
un standard, comme UML. Après on a les outils plus génériques comme Visio, draw.io, Google
Drawings… On voit également des diagrammes faits dans Powerpoint ou équivalent. Tout ceci ne
favorise pas vraiment le partage et la collaboration !
Enfin, la plupart des outils ne permettent pas de visualiser facilement différents niveaux
d’abstraction selon le but recherché : vue du système, détail d’un composant Finalement, on a besoin
d’une solution standardisée et simple.
C’est là qu’intervient C4
C’est quoi ce C4 ?
La modélisation C4 (de l'anglais « C4 model ») est une technique de notation

graphique allégée pour la modélisation d'architectures logicielles. Elle est basée sur
la décomposition structurelle d'un système en conteneurs et composants.
La décomposition plus détaillée de ces éléments architecturaux peut alors
s'appuyer sur des techniques de modélisation existantes telles que le langage de
modélisation unifié (UML) ou les diagrammes entité-associations.
C’est quoi ce C4 ?
C4 est l’acronyme de Context, Container, Component et Code.

La modélisation C4 a été créé par l'architecte logiciel Simon Brown entre 2006 et
2011 sur le base du langage de modélisation unifié (UML) et de l'approche de
visualisation architecturale 4+1 du Kruchten,
La modélisation C4 documente l'architecture d'un système logiciel en utilisant

l'approche des points de vue multiples. Ces points de vue permettent d'expliquer la
décomposition d'un système en conteneurs puis en composants, les relations entre
ces éléments, et, le cas échéant, les relations avec des éléments avec les utilisateurs.
Approche de visualisation architecturale 4+1 du Kruchten
Les points de vue du modèle C3 sont groupés selon leur niveau hiérarchique:
• Diagrammes de contexte (niveau 1)
• Diagrammes de conteneurs (niveau 2)
• Diagrammes de composants (niveau 3)
• Diagrammes de code (niveau 4)
La modélisation C4 s'appuie à ce niveau de détail sur des notations existantes bien

établies telles que UML (Unified Modeling Language), les modèles entité-
association ou encore des diagrammes générés par environnements de
développement intégrés (IDE)
Niveau 1 : Contexte
Le 1er niveau est un diagramme extrêmement

simple, qui permet de visualiser le(s) application(s) à
modéliser dans leur écosystème (ici le “Internet
Banking System”).
Les interactions avec les utilisateurs sont
représentées. On voit également l’intégration du
système dans l’existant, les échanges avec les autres
briques. Ici il n’est pas question de technique.
Cette vue très macro peut être utilisée avec des
personnes non techniques, par exemple des experts
du domaine métier.
Niveau 2 : Conteneur
Le terme n’a aucun rapport avec les technologies comme Docker ou équivalent. Cette vue permet de
visualiser les différentes briques logicielles qui composent le système modélisé : applications web et
mobile, APIs HTTP, bases de données… Les technologies utilisées sont écrites, les interactions sont
également plus précises en terme de protocole et format.
C’est un niveau intéressant pour décrire le fonctionnement global d’une application. C’est idéal par
exemple pour expliquer le contexte à un nouveau développeur qui intègre l’équipe. Ce diagramme
sera particulièrement utile sur une architecture orientée microservices, car il fera apparaître les
différents microservices et leurs relations. Si des équipes différentes travaillent sur différentes
briques d’un même système, ce schéma servira à montrer les frontières
Niveau 3 : Composant
Le 3ème niveau, “composant”, décrit l’architecture locale d’une des briques
logicielles. Le conteneur (voir niveau 2) est découpé sous la forme de multiples
composants. Chaque composant représente une fonctionnalité du conteneur.
Ce niveau est clairement destiné à l’équipe qui développe le conteneur en question.

On peut alors utiliser les différents composants comme base de découpage du code
! Ceci facilitera un découpage orienté sur le domaine métier plutôt que la technique,
par exemple via l’adoption du
Niveau 4 : Code
Ce niveau est optionnel, ce qu’indique
même Simon Brown, le créateur de c4
Model.
Il descend au niveau du code, des
interfaces et des classes. Il peut être
implémenté par un diagramme de
classes UML.
Conclustion
De bons diagrammes d'architecture logicielle facilitent la communication (à la fois à
l'intérieur et à l'extérieur de l'équipe de développement logiciel / produit),
Les diagrammes aident à aligner la compréhension de chacun sur le logiciel en cours

de construction, contribuant ainsi à rendre l'équipe plus efficace.
Le C4 model apparaît comme une solution simple pour modéliser une architecture
logicielle. Les différents niveaux de détail de visualisation sont très bien pensés et
permettent d’éviter de mettre trop de détails sur un diagramme. Ils servent
également à communiquer avec des publics différents de façon claire.

Modelisation de L'architecture Logicielle

Transféré par

Droits d'auteur :

Formats disponibles

Modelisation de L'architecture Logicielle

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Modelisation de L'architecture Logicielle

Transféré par

Droits d'auteur :

Formats disponibles

Mastère Professionnel co-construit

en Ingénierie Des Applications Web-Nuagiques

Modélisation de l’architecture logicielle SBS –-2020

La modélisation C4 (de l'anglais « C4 model ») est une technique de notation

C4 est l’acronyme de Context, Container, Component et Code.

La modélisation C4 documente l'architecture d'un système logiciel en utilisant

La modélisation C4 s'appuie à ce niveau de détail sur des notations existantes bien

Le 1er niveau est un diagramme extrêmement

Ce niveau est clairement destiné à l’équipe qui développe le conteneur en question.

Les diagrammes aident à aligner la compréhension de chacun sur le logiciel en cours

Vous aimerez peut-être aussi

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.