Le diagramme de traitements de la phase D Architecture technique de TOGAF - étape 38 de l’exemple Modelio
Le diagramme de traitements modélise les unités déployables de code et configuration ainsi que leur déploiement sur la plate-forme technologique.
Ce modèle est réalisé par les architectes technique avec comme référents les ingénieurs systèmes/réseau à destination des responsables d’exploitation et des développeurs.
Pour plus de précisions sur les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF, voir l’article :
Une unité de déploiement représente un regroupement de fonctions métier, de services ou de composants d'application.
Le diagramme de traitement permet d’identifier
- les composants d'application qui doivent être regroupés pour former une unité de déploiement
- les moyens de communication entre les unités de déploiement comme les topologies et types de réseaux (LAN, WAN) ainsi que les protocoles de transport (TCP/IP, …) et les protocoles applicatifs (HTTP + SOAP + WSDL pour SOA, …)
- la volumétrie, les capacités CPU, le dimensionnement des réseaux, ... à mettre en place pour satisfaire les estimations de charge.
Les unités de déploiement peuvent être présentées sous la forme (stéréotype UML) d'instances de composant d'application utilitaire (par exemple, un serveur d'application), hébergeant des composants d'application .
Les associations entre ces unités de déploiement représenteront les connexions (par exemple, un réseau), tandis que les flux d'informations indiqueront la nature des informations échangées.
Dans ces diagrammes, des indications sur les besoins en capacité sont fournies.
Les composants de l'application sont déployés dans les unités de configuration déployables, qui sont elles-mêmes des types spécifiques de composants d'application , au niveau de la technologie (serveur web, serveur BPM, serveur d'application, ...).
Une instance du composant d’application d’interaction “:TripReservationSite” est déployé dans le “WEB server” qui est une unité de déploiement stéréotypée composant d’application utilitaire (composant standard que l’on achète ou que l’on trouve en open source comme le serveur HTTP Apache).
De même les instances des composants d’application processus “:ReserveTrip” et “:Invoicing” sont déployés dans le serveur de BPM (Business Process Management) (par ex. en open source Bonita Soft, RedHat jBPM, …) utilisant le langage BPEL (Business Process Execution Language) qui peut être généré à partir des modèles BPMN (Business Process Model and Notation).
Le langage BPEL permet d’orchestrer les services web.
Ce serveur BPM qui regroupe des composants processus est une unité de déploiement.
Le langage BPEL permet d’orchestrer les services web.
Ce serveur BPM qui regroupe des composants processus est une unité de déploiement.
Enfin les composants d’application d’entité “:Trip”, “:Client” et “:Order” et le composant d’application utilitaire “:CreditCard”, qui sont utilisés par des services web déployés dans un serveur d’application comme par exemple Jakarta EE (nouveau nom de Java Enterprise Edition depuis qu’Oracle l’ait abandonné à l’organisation open source Eclipse) ( ex. de serveurs d’application : RedHat Wildfly, Oracle GlassFish, …).
Ces 3 unités de déploiement sont connectées dans l’exemple par des réseaux locaux (LAN) modélisés par des association UML sur lesquelles on a attaché des commentaires UML spécifiant les exigences de vitesse en terme de requêtes par seconde.
Conclusion
Le diagramme de traitements montre comment les composants d’application sont déployés dans les unités de déploiement correspondant aux technologies utilisées (HTTP, BPM, Jakarta EE, ...).
Afin de mettre l'accent sur les unités de déploiement, ce modèle utilise le déploiement de manière plus générique que le diagramme de réseau matériel et informatique dont on parlera dans le prochain article.
Rhona Maxwel
@rhona_helena
“La science a-t-elle promis le bonheur ? Je ne le crois pas. Elle a promis la vérité, et la question est de savoir si l'on fera jamais du bonheur avec la vérité.”
Emile Zola
Annexe : les précédentes étapes de notre étude de cas TOGAF
- Exemples d’études de cas d’architecture d’entreprise avec le framework TOGAF empruntés à l’outil français Modelio
- Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 1, les éléments de modélisation
- Exemple d’étude de cas TOGAF - Comment modéliser la phase A Vision de la méthode ADM : étape 2, matrice des parties prenantes (stakeholder)
- Tutorial, exemple d’étude de cas TOGAF - Analyser les objectifs - étape 3.1 de Comment modéliser la phase A Vision de la méthode ADM
- Etude de cas complète TOGAF, structure du projet et mode opératoire avec l’outil Modelio Business Analyst
- Comment modéliser les objectifs stratégiques et opérationnels en phase A Vision de la méthode ADM TOGAF ? (étape 3.2 de notre étude de cas)
- Cas complet de mise en œuvre TOGAF : l’artefact « catalogue d’objectifs » (étape 3.3 de notre didacticiel)
- Le catalogue des exigences de la phase A Vision de TOGAF : étape 4.1 de l’étude de cas
- Le diagramme SysML des exigences de la phase A Vision de TOGAF : étape 4.2 de l’étude de cas
- Le diagramme d’évènements de la phase A Vision de TOGAF : étape 5 de l’étude de cas Modelio
- Le diagramme des concepts de la solution de la phase A Vision de TOGAF : étape 6 de l’étude de cas Modelio
- Le diagramme de chaîne de valeur de la phase A Vision de TOGAF : étape 7 de l’étude de cas Modelio
- Comment modéliser la phase B Architecture métier de TOGAF - les éléments de modélisation - étape 8 de l’étude de cas
- Le dictionnaire métier de la phase B Architecture métier de TOGAF - étape 9 de l’étude de cas
- Le diagramme d’organisation des acteurs de la phase B Architecture métier de TOGAF - étape 10 de l’étude de cas
- Comment modéliser les flux échangés entre une entreprise et les acteurs externes en phase B architecture métier de TOGAF ? – étape 11 de l’étude de cas
- Diagramme des rôles joués par les acteurs en phase B architecture métier de TOGAF ? – étape 12 de l’étude de cas
- Diagramme d’organisation et de localisation en phase B architecture métier de TOGAF – étape 13 de l’étude de cas
- Diagramme de localisation en phase B architecture métier de TOGAF – étape 14 de l’étude de cas
- Diagramme de décomposition fonctionnelle en phase B architecture métier de TOGAF – étape 15 de l’étude de cas
- Diagramme objectifs-services métier en phase B architecture métier de TOGAF – étape 16 de l’étude de cas
- Diagramme de processus métier en phase B architecture métier de TOGAF – étape 17 de l’étude de cas
- Les règles métier en phase B architecture métier de TOGAF – étape 18 avec l’outil Enterprise Architect de Sparx Systems
- Diagramme de cas d’utilisation métier en phase B architecture métier de TOGAF – étape 19 de l’étude de cas Modelio
- Diagramme information - service métier en phase B architecture métier de TOGAF - étape 20 de l’étude de cas Modelio
- Diagramme supervision métier en phase B architecture métier de TOGAF – étape 21 de l’exemple complet emprunté à Modelio
- Diagramme des entités métier en phase B architecture métier de TOGAF - étape 22 du didacticiel
- Diagramme de cycle de vie des entités métier en phase B architecture métier de TOGAF - étape 23 de l'étude de cas
- Les éléments de modélisation avec UML de la phase C Architecture des Systèmes d'Information de TOGAF - étape 24 du tutoriel
- Le diagramme de communication des applications de la phase C Architecture des Systèmes d'Information de TOGAF - étape 25 du tutoriel
- Le diagramme de migration applicative de la phase C Architecture des Systèmes d'Information de TOGAF - étape 26 du cas complet Modelio
- Le diagramme de localisation des applications et des utilisateurs de la phase C Architecture des Systèmes d'Information de TOGAF - étape 27 de notre cas d’étude
- Le diagramme de cas d’utilisation applicatifs de la phase C Architecture des Systèmes d'Information de TOGAF - étape 28 de notre cas d’étude
- Le diagramme de réalisation des processus de la phase C Architecture des Systèmes d'Information de TOGAF - étape 29 du didacticiel
- Le diagramme de gestion d’entreprise de la phase C Architecture des Systèmes d'Information de TOGAF - étape 30 de l’exemple complet Modelio
- Le diagramme logique de données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 31 de l’exemple complet Modelio
- Le diagramme de dissémination de données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 32 du cas d’étude
- Le diagramme de sécurité des données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 33 du cas pratique
- Le diagramme de migration des données de la phase C Architecture des Systèmes d'Information de TOGAF - étape 34 du tutorial Modelio
- Le diagramme des données de service de la phase C Architecture des Systèmes d'Information de TOGAF - étape 35 du tutorial Modelio
- Les éléments de modélisation avec UML de la phase D Architecture technique de TOGAF - étape 36 de l’exemple Modelio
- Le diagramme d’environnement et de localisation de la phase D Architecture technique de TOGAF - étape 37 de l’exemple Modelio
A découvrir aussi
- Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture
- Comment modéliser les objectifs stratégiques et opérationnels en phase A Vision de la méthode ADM TOGAF ? (étape 3.2 de notre étude de cas)
- Le diagramme de migration applicative de la phase C Architecture des Systèmes d'Information de TOGAF - étape 26 du cas complet Modelio
Retour aux articles de la catégorie TOGAF -
⨯
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 769 autres membres