Diagramme de com­po­sants : une mo­dé­li­sa­tion du système efficace grâce aux modules de logiciel

L’Unified Modeling Language, en français : « langage de mo­dé­li­sa­tion unifié » est un standard ISO universel pour le dé­ve­lop­pe­ment de logiciels mettant à dis­po­si­tion des ar­chi­tec­tures système plus complexes. Abrégé en « UML », ce langage de mo­dé­li­sa­tion utilise dif­fé­rents types de dia­grammes pour les pla­ni­fi­ca­tions et les processus de dé­ve­lop­pe­ment dans la pro­gram­ma­tion orientée objet.

Dans la version actuelle (UML 2.5), on distingue 14 types de dia­grammes, répartis gros­siè­re­ment entre deux ca­té­go­ries : les dia­grammes com­por­te­men­taux et les dia­grammes struc­tu­rels. Les dia­grammes de com­po­sants font partie de la deuxième catégorie. Dans cet article, nous vous ex­pli­quons ce qu’est un diagramme de com­po­sants et comment créer un tel diagramme à travers un exemple. D’autre part, vous dé­cou­vri­rez à quoi servent les dia­grammes de com­po­sants UML.

Les dia­grammes de com­po­sants UML re­pré­sen­tent les relations entre les dif­fé­rents com­po­sants d’un système dans une vue d’ensemble statique. Ils peuvent inclure des aspects de mo­dé­li­sa­tion à la fois logiques et physiques.

Dans le contexte de l’UML, les com­po­sants sont des éléments mo­du­laires d’un système. Ils sont in­dé­pen­dants et peuvent être remplacés par des com­po­sants équi­va­lents. Ces com­po­sants sont autonomes et en­cap­su­lent un certain nombre de struc­tures complexes. Les éléments en­cap­su­lés entrent uni­que­ment en contact avec d’autres com­po­sants via des in­ter­faces. Les com­po­sants peuvent mettre à dis­po­si­tion leurs propres in­ter­faces ou utiliser les in­ter­faces d’autres com­po­sants pour pouvoir accéder par exemple à leurs fonctions et leurs services. En parallèle, les in­ter­faces do­cu­men­tent dans un diagramme de com­po­sants les relations et dé­pen­dances au sein d’une ar­chi­tec­ture lo­gi­cielle.

Les com­po­sants en­cap­su­lent gé­né­ra­le­ment des classes et sont par con­sé­quent con­si­dé­rés comme une sous-forme ou une spé­cia­li­sa­tion de classe. À l’instar d’une classe, ils disposent d’une structure composite et peuvent notamment être définis plus pré­ci­sé­ment à l’aide d’attributs, de méthodes et d’opé­ra­tions. Les com­po­sants peuvent être cons­ti­tués d’un ensemble de classes et être im­plé­men­tés par une ou plusieurs classe(s) au moment de l’exécution. Bien que les com­po­sants soient souvent amalgamés avec les classes, ces éléments pré­sen­tent des dif­fé­rences dans certains domaines. En principe, les com­po­sants ont besoin d’in­ter­faces pour permettre une in­te­rac­tion. Les classes, quant à elle, peuvent accéder di­rec­te­ment à une méthode.

Le terme « composant » est très largement défini dans UML. Dif­fé­rentes parties du système – comme les bases de données, les paquets (packages), les fichiers et les bi­blio­thèques (par ex. Dynamic Link Libraries/DLLs) – font partie des com­po­sants. En dehors des com­po­sants tech­niques, qui sont par exemple né­ces­saires pour accéder à une base de données, il existe également des com­po­sants pro­fes­sion­nels pouvant concerner des domaines d’activités et des processus com­mer­ciaux. Pour tenir compte des rapports de ce type – qui peuvent être plus vastes – l’UML a prévu le sté­réo­type <<subsystem>>.

La mo­dé­li­sa­tion d’un système par le diagramme de com­po­sants est orientée sur la mise en œuvre. Par con­sé­quent, il existe des com­po­sants d’im­plé­men­ta­tion spéciaux qui mettent spé­ci­fi­que­ment en évidence les dif­fé­rents aspects de la mise en œuvre. Ces com­po­sants peuvent par exemple être utilisés pour im­plé­men­ter d’autres com­po­sants comme des Exe­cu­tables (fichiers exé­cu­tables avec l’extension *.exe) sous Windows.

Ras­sem­bler plusieurs com­po­sants permet de former une ar­chi­tec­ture système plus complète. Les com­po­sants peuvent alors contenir d’autres com­po­sants ou s’appuyer les uns sur les autres. Par con­sé­quent, un composant peut impliquer l’existence d’un autre composant (relation de dé­pen­dance). D’autre part, les modules logiciels peuvent concerner dif­fé­rentes phases de mise en œuvre : certains com­po­sants servent avant tout à la pla­ni­fi­ca­tion et à la pro­jec­tion lors de la phase de con­cep­tion ; d’autres ap­pa­rais­sent uni­que­ment à l’occasion de l’exécution d’un logiciel. On parle alors de com­po­sants de con­cep­tion et d’exécution.

Un diagramme de com­po­sants permet d’avoir une vue d’ensemble du système selon une pers­pec­tive aérienne. Cette vue d’ensemble documente l’or­ga­ni­sa­tion des com­po­sants du système ainsi que leurs relations et leurs dé­pen­dances mutuelles. Dans ce cadre, les dia­grammes de com­po­sants per­met­tent une vue orientée exécution et indiquent par exemple aux dé­ve­lop­peurs si le système fonc­tionne comme un tout et s’il remplit ses tâches et ses objectifs.

Parmi les objectifs im­por­tants et les uti­li­sa­tions prin­ci­pales de ce type de dia­grammes, on trouve la mo­dé­li­sa­tion de systèmes logiciels basés sur les com­po­sants, la spé­ci­fi­ca­tion d’une ar­chi­tec­ture lo­gi­cielle ainsi que la division d’un système en sous-systèmes (par ex. une interface graphique uti­li­sa­teur/GUI, un domaine d’activité et de per­sis­tance avec base de données re­la­tion­nelle). De plus, les sous-domaines et leurs in­ter­faces se voient attribuer des tâches et fonctions concrètes au sein du système.

En économie, les dia­grammes de com­po­sants UML cons­ti­tuent une base es­sen­tielle pour échanger avec le client. Grâce à une réduction notable de la com­plexité, les projets et les pla­ni­fi­ca­tions de­vien­nent ainsi plus tangibles et in­tel­li­gibles, ce qui simplifie con­si­dé­ra­ble­ment la com­mu­ni­ca­tion. Par ailleurs, les dia­grammes de com­po­sants fa­vo­ri­sent et fa­ci­li­tent l’ad­mi­nis­tra­tion du dé­ve­lop­pe­ment logiciel en re­grou­pant par exemple les classes pour former des com­po­sants gérables.

L’approche modulaire de ce type de dia­grammes participe d’autre part à la ren­ta­bi­lité et à l’ef­fi­ca­cité des projets puisque les systèmes logiciels peuvent également être modélisés sous forme de rapports fonc­tion­nels struc­tu­rés obtenus à partir de com­po­sants réu­ti­li­sables. Les dia­grammes de com­po­sants per­met­tent de vi­sua­li­ser ap­proxi­ma­ti­ve­ment à quels endroits d’une ar­chi­tec­ture des éléments peuvent être réu­ti­li­sés. La con­cep­tion des systèmes peut être axée de manière optimale sur la réu­ti­li­sa­bi­lité des com­po­sants et l’ef­fi­ca­cité de leur in­te­rac­tion.

Les systèmes logiciels basés sur les com­po­sants per­met­tent de gagner du temps et de l’argent dans la phase de pla­ni­fi­ca­tion et lors de la mise en œuvre des systèmes puisqu’ils s’appuient sur des éléments déjà existants. Par ailleurs, les modules logiciels testés et éprouvés réduisent les risques et les sources d’erreur notamment à l’occasion de la réa­li­sa­tion de projets plus complexes. Des modules de fa­bri­cants tiers per­met­tant la mise en œuvre de systèmes sont également dis­po­nibles moyennant paiement et per­met­tent de compléter vos propres con­nais­sances.

À partir de ces éléments de base, il est par exemple possible de créer un diagramme de com­po­sants simple à l’aide du logiciel open source gratuit JGraph.

La pro­fon­deur de re­pré­sen­ta­tion d’un diagramme de com­po­sants peut être augmentée en dé­fi­nis­sant les éléments concernés de façon plus précise con­for­mé­ment au standard UML. Une classe utilisée peut par exemple être précisée par des attributs et des opé­ra­tions. Notre article sur les dia­grammes de classes présente en détail les options pour une spé­ci­fi­ca­tion des classes plus détaillée. Les dia­grammes de cas d’uti­li­sa­tion (Use case diagramm) et les dia­grammes états-tran­si­tions offrent d’autres options de con­cep­tion et de mo­dé­li­sa­tion.