Le diagramme de matériel informatique en réseau de la phase D Architecture technique de TOGAF - étape 39 du tutorial Modelio
Le diagramme de matériel informatique en réseau modélise le déploiement des composants d’application, tous types confondus, dans une architecture technique distribuée.
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 :
L’outil utilisé est le diagramme de déploiement UML (voir notre article : “ Le diagramme d’environnement et de localisation de la phase D Architecture technique de TOGAF - étape 37 de l’exemple Modelio “).
Les grandes organisation (corporate) ont souvent pour des raisons historiques un agrégat hétérogène de serveurs de type mainframe IBM fonctionnant sous MVS, des serveurs Microsoft Windows et des serveurs Linux en cluster tendant du reste à remplacer de nos jours les antédiluviens mainframe.
Dans cet exemple, une instance de l’application “:TripPortfolioManager-V2” accède à une instance du composant d’application de base de données “:PortfolioRepository” (par exemple DB2).
Ces 2 composants sont déployés dans un mainframe IBM “MVS server” connecté via un LAN au serveur d’application “Linux server”.
Une instance de l’application “:AccountingERP” accède à une instance du composant d’application de base de données “:AccountingRepository” (par exemple Microsoft SQL server).
Ces 2 composants sont déployés dans un serveur Microsoft “Windows server” connecté via un LAN au serveur d’application “Linux server”.
Le serveur Unix “Linux server” exécute 3 logiciels serveur stéréotypés composant d’application utilitaire.
Il s’agit :
- d’une instance d’un moteur de processus métier BPM (composant d’application utilitaire) “:BPEL server” (voir notre article : “ Le diagramme de traitements de la phase D Architecture technique de TOGAF - étape 38 de l’exemple Modelio “) dans lequel s’exécute le composant d’application de processus “:ReserveTrip”
- d’une instance de SGBR “:OrderRDB”, le commentaire UML indique qu’il s’agit de la base de données open source MySQL.
- d’une instance d’un logiciel serveur HTPP (composant d’application utilitaire) “:WEB server” exécutant une instance du composant d’application d’interaction correspondant au site internet “:TripReservationSite” développé en PHP comme le montre le commentaire UML.
- d’une instance du conteneur JEE (composant d’application utilitaire) “:Application server”, dans lequel s’exécute des composants d’application d’entité “:Client”, “:Order” et “:Trip” et de processus “:Invoicing”.
Ces composants d’entité ou de processus sont des services web avec leurs différentes typologies, services d’orchestration, fonctionnels, applicatifs, d’entités métier, ... (voir l’annexe 2 sur l’architecture SOA).
A noter le framework open source “Hibernate” qui assure la couche d’ORM (Object Relational Mapping) faisant la traduction d’un modèle de classe UML orienté objet en un modèle relationnel de SGBR.
Le langage HQL (Hibernat Query Language), traduit automatiquement en SQL du SBDR, les requêtes tout en conservant les concept objet et en faisant abstraction du mode physique de stockage (voir l’article consacré à l’ORM : “ A ma gauche Hibernate version 4.3.6 contre MyBatis version 3.2.8, qui va remporter le titre 2014 de champion ORM toute catégorie ? “).
Remarque : Oracle a confié les développements futurs de JEE à l’organisation open source Eclipse qui l’a renommé Jakarta EE.
Les postes de travail sont modélisés sous la forme générique “Workstation” connectés aux serveurs “MVS server” et “Windows server” avec des LAN et accède au serveur d’application “Linux server” via internet (HTTP) avec le navigateur de Microsoft.
Afin de bien vérifier que tous les acteurs internes “Marketing officer”, “Account manager”, “Invoicing officer” et externe “Client”, ont bien accès à leurs applications remplissant leurs besoins métier, on les représente en lien à leur poste de travail.
Conclusion
Le diagramme de matériel informatique en réseau constitue une cartographie des infrastructures informatiques hébergeant les composants applicatifs ainsi que les acteurs accèdant à ces composants.
Rhona Maxwel
@rhona_helena
“Une joie partagée est une double joie, un chagrin partagé est un demi-chagrin.”
Jacques Deval
Annexe 1 : 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
- Le diagramme de traitements de la phase D Architecture technique de TOGAF - étape 38 de l’exemple Modelio
Annexe 2 : l’architecture SOA (Service Oriented Architecture)
- 4/11 Projet informatique : passer du moyen âge à l'ère industrielle. Résolvez l'équation : ROI = SOA
- Gouvernance SOA : La phase de Design Time (1)
- Gouvernance SOA : la phase de Design Time (2)
- Gouvernance SOA : la phase de Design Time (3)
- Gouvernance SOA : la phase de Design Time (4)
- Gouvernance SOA : la phase de Design Time (5)
- Gouvernance SOA : la phase de Run Time
- Gouvernance SOA : la phase de Change Time
- Un bon contrat, n'est pas un contrat signé mais un contrat standardisé
- Le contrat standardisé (suite)
- Gouvernance SOA : lachez tout !
- Faites vos gammes : les design patterns de la gouvernance SOA
- Gouvernance SOA : métier ou informatique, à votre service !
- Gouvernance SOA : Principes de l'Architecture Orientée Service
- Gouvernance SOA : Concevoir un système orienté service
- Gouvernance SOA : Concevoir une architecture de référence
- Gouvernance SOA : Caractérisation des services
- Gouvernance SOA : Les services déduits des modèles de données
- Gouvernance SOA : Les services applicatifs
- Gouvernance SOA : Les services d'orchestration de processus
- Gouvernance SOA : Les services de communication
- Gouvernance SOA : Les services d'administration
- Gouvernance SOA : Les services de sécurité
- Gouvernance SOA : Identification des échanges
A découvrir aussi
- Le diagramme des concepts de la solution de la phase A Vision de TOGAF : étape 6 de l’étude de cas Modelio
- 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 réalisation des processus de la phase C Architecture des Systèmes d'Information de TOGAF - étape 29 du didacticiel
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 769 autres membres