Diagrammes de composants – Diagrammes de déploiements

Par experience, les développeurs ont du mal à comprendre le niveau d’exigence et ce que traduit ces diagrammes.

Un seul diagramme de composants

Ce qu’il faut bien noter c’est qu’il n’y a qu’un diagramme de composants et plusieurs diagrammes de déploiement par projet

Qu’est-ce qu’un composant ? Un WAR, un JAR

Unité de déploiement. C’est tout ce qui se déploie. Tout ce qui se déploie est un composant.

Qu’est-ce qui se déploie ?

Eclipse ne se déploie pas : c’est le moyen de créer mon logiciel.

En java, je crée des jar, ou des war si je fais du web : ce sont bien des fichiers déployés, il n’y a pas d’ambiguité, ce sont des unités de déploiement.

Le composant a une vue système, on le voit, exemple, un fichier, un repertoire. Si on l’enlève, ça ne fonctionne plus.

Par contre, le WAR/JAR a besoin de TOMCAT pour s’executer.

Ca veut dire qu’il existe une dépendance entre le WAR/JAR et TOMCAT.

Tomcat est un composant système. Il est pratique, physqiue, et pas thorique.

Mais, c’est plus qu’un composant, car à l’execution, il se matérialise en « serveur » et plus précisément, un process système qui s’execute et qui permet l’execution de mes web archives.

Une base de donnée est un composant système: pour simplifier, c’est un process qui écoute sur un port et qui accède à des fichiers. (via le driver JDBC sur le port TCP)

Le nom des composant est très précis : il incluse les numéros de versions.

Mais, au début, on fait un bench, on ne sait pas ce qu’on va avoir comme serveur web, par exemple Apache, ou IIS. Au fur et à mesure qu’on va avancer, on va pouvoir renseigner davantage les briques et les versions

A chaque users stories, on enrichit le diagramme de composants.

Donc on doit le mettre à jour à plusieurs : les nouvelles users stories apparaitront

Il nous montre les liens logiciels entre les composants. Un composant figure UNE ET UNE SEULE FOIS sur ce diagramme

Une question? Posez-la ici

Quand est-ce qu’on livre un digramme de composants ?

En release 0, on a un diagramme de composants dans sa version préliminaire, pourquoi ? Parce qu’on ne peut pas penser à tout. Il sera en version définitive à la fin du projet.

A chaque mise à jour

Le diagramme de déploiements

C’est la vision dont on va répartir le code sur les différentes machines.

On a autant de fois de composants qu’ils sont déployés sur autant de machines.

Il montre la façon dont les instances de composants sont déployés sur les machines.

Si un logiciel déployé sur 2 clients différents, on aura 2 façons différentes de le déployer, donc, 2 diagrammes de déploiement.

Exemple, dans une petite PME, je mets le même serveur SQL Serveur sur le même serveur que le serveur web IIS.

Dans un grand groupe, il y aura davantage de charge : je mets le serveur SQL sur un serveur et un serveur IIS sur un autre serveur.

Je dois étudier les avantages et les inconvénients de cette conslidations.

Prendre en compte les contraintes géographiques : je rapproche la base de donnée plutôt vers le site du siège social, plutôt que sur le site délocalisé.

Par contre, si on a une entreprise avec 2 sites de même taille, on peut décider de mettre 2 bases sur 2 endroits et répliquer les bases : le soft ne change pas, mais l’installation est différente.

Une question? Posez-la ici

Exemple d’architecture

Le diagramme de composants

RMI, ActiveMQ

Base de production, base Postgress, SQL Server

En mode Agile, je vais extraire mes données manuellement tous les jours, avant de fournir une interface automatisée. Tous les jours mon client execute historic-client, un programme Java classique.

CLI = Command line interface

Quelles sont les dépendances ? Lire la base de donnée PostGress pré-prod (c’est un composant executable, avec une version 8.0 et un port TCP sur lequel je peux me connecter et envoyer des requetes) pour extraire les données.

Ces données je vais les envoyer vers un RMI, livré avec la JRE, sur le port 1099

Ensuite le client se connecte sur le port 1099 pour récupérer l’adresse du serveur qui au préalable s’est enregistré sur le même port.

RMI TCP 1099. Derrière ce port se cache l’interface car la méthode lookup est bien l’interface de Regitry.

JAVA.RMI.REGISTRY possède 2 méthodes : « bind » et « report » .

Les composants écrits en JAVA ont des dépendances vers les JRE

Une fois que j’ai récupéré mes données via le RMI registry, le client se connecte au serveur en RMI toujours. Donc j’ai un port RMI (symbolisé en rectangle)

Public interface HistoricDataFlusher extends java.rmi.remote

Ce sont des méthodes sur la classe HistoricDataFlusher

Transformation des données

Les données sont récupérées de Postgress, il faut que je les transforme

API : transform-apt-5.1.6 que j’implemente dans un projet à part.

Je cree une interface DataTransform dans laquelle j’implemente ma transformation

Public class SimpleDataTransform implements DataTransform

Ca veut dre que mon client qui est mon service, va utiliser le composant jar différent transform-api, car ce sont 2 projets différents au sens MAVEN.

Il faut que le composant 1 a dans son classpath le 2eme jar : ils seront dans le même process.

Interet : si demain je veux faire évoluer ma transformation, qui est-ce qui change ? Juste l’implémenation.

Mes données sont envoyées dans une file ActiveMq protocole AMQP (serveur executable) en utilisant l’API ActiveMQ ; port TCP 5672

Puis ensuite les données sont insérées dans la base de donnée de consolidation sql server protocol tcp 1443

Une question? Posez-la ici

Le diagramme de déploiement

Tous les composants du diagramme de déploiement doivent être sur le diagramme de composants.

L’inverse n’est pas forcément vrai.

Représentation du réseau local où sont déployés les composants :

• client
• base postgress
• registry
• serveur activeMS
• serveur de transformation
• 2eme serveur de transformation
• 2 agents d’insertion
• Switch réseau

Exemple : le composant client est déployé sur une machine avec les composants suivants : historic-client, linux OS, JDBC PostgreSQL, JRE.

Des questions?