Les FONDEMENTS de l ARCHITECTURE d ENTREPRISE Ingénierie de l organisation

Transcription

1 Les FONDEMENTS de l ARCHITECTURE d ENTREPRISE Ingénierie de l organisation Patrice Briol

2 Ingénierie de l organisation 1 ère édition La notation UML et le logo UML sont des marques déposées de l Object Management Group (OMG). SqEME est une marque déposée de SqEME Foundation. TOGAF est une marque enregistrée de l Open Group. Le cadre de référence Zachman est une marque déposée de John A. Zachman et de Zachman International. Les autres noms de produits ou de marques cités dans cet ouvrage sont des marques déposées de leurs propriétaires respectifs. Image de couverture : Construction de la tour Eiffel, décembre Source : Bibliothèque Nationale de France Du même auteur : - Ingénierie des processus métiers, de l élaboration à l exploitation - BPMN, the Business Process Modeling Notation, Pocket Handbook - XML, le langage des systèmes de gestion des processus métiers - PalmOS, Programmation, C & Java Première Édition ISBN : Copyright 2008 Briol Patrice

3 Sommaire Introduction... 5 L Entreprise, son organisation et ses processus...5 Organisation de l ouvrage...8 Chapitre 1 - Le langage de modélisation unifié UML La modélisation des systèmes avec UML Le cadre de représentation L annotation...16 Chapitre 2 - La perspective structurelle de l organisation Les diagrammes UML statiques Le diagramme de classes Le diagramme d objets Le diagramme de composants Le diagramme de déploiement Le diagramme de structures composites Le diagramme de paquetages Modélisation de la structure organisationnelle L organigramme Les objectifs Les fonctions Les produits et services...39 Chapitre 3 - La perspective comportementale de l organisation Les diagrammes UML dynamiques Le cas d utilisation et son diagramme...46 Le diagramme de cas d utilisation...46 La documentation des cas d utilisation Le diagramme d activités...51 Les activités...52 Les actions...54 Les flux et les noeuds...60 Les objets...72 Les partitions...77 Les interruptions et les exceptions Les diagrammes d interactions...83 Le diagramme de séquence...83 Le diagramme de communication...88 Le diagramme de synchronisation...89 Le diagramme de vue d ensemble d interactions Le diagramme d états...92

4 3.2 Modélisation du mode de fonctionnement de l organisation Les processus métiers Les interactions Chapitre 4 - L Architecture d Entreprise Le développement d architecture d entreprise avec SqEME Les principes de SqEME La gestion des processus métiers avec SqEME L utilisation des fenêtres de la méthodologie SqEME La reconfiguration des processus métiers L ajustement de la structure organisationnelle L organisation orientée service L architecture d entreprise avec SqEME Le cadre de référence Zachman Les principes du cadre de référence Zachman L utilisation du cadre de référence Zachman L aspect Donnée L aspect Fonction L aspect Réseau L aspect Collaborateur L aspect Durée L aspect Motivation L architecture de l Open Group TOGAF Les principes de TOGAF L Enterprise Continuum La base de ressources La méthode de développement d architecture ADM L architecture métier Le cadre de référence La création de la base de ressources La constitution de l Enterprise Continuum L évaluation de l organisation La collecte et l analyse des besoins Le développement des composants d architecture La validation de la nouvelle architecture La mise en œuvre de la nouvelle architecture L évaluation de la mise en œuvre Conclusion Figures Tables Index

5 Introduction L Entreprise, son organisation et ses processus L'entreprise est un système social composé d'individus poursuivant un but commun d'évolution dans un environnement changeant et concurrentiel. Sa structure organisationnelle et son mode de fonctionnement sont à l'origine de la production de biens et de services lui assurant ses revenus et son existence. La création de valeur ajoutée dépend de l'exploitation des ressources et des réponses apportées aux contraintes légales, techniques et règlementaires de son environnement. Dans cette situation, l'alignement de l'organisation sur les objectifs et les prises de décision stratégiques reposent sur la connaissance des flux d'informations circulant entre ses différentes entités. Cependant, ces seules informations ne permettent pas de créer une vision globale claire et précise de l'entreprise. La compréhension de la structure organisationnelle et du mode de fonctionnement de l'organisation complètent cette connaissance en facilitant son élaboration comme son amélioration. L'architecture d'entreprise structure cette information déclinée en deux volets complémentaires : L organisation s inscrit comme une construction conceptuelle et immatérielle formalisant les relations entre les individus. Un processus métiers représente une séquence ordonnée de tâches produisant un résultat à valeur ajoutée aux parties prenantes de l organisation. Les Analystes Métiers récoltent, consolident, traitent et communiquent les informations de l organisation et des processus métiers de l entreprise. La forme de représentation de l information la plus appropriée et la plus aisée à maintenir reste la forme graphique. La modélisation des divers concepts caractérisant l entreprise et son organisation «simplifie» la réalité en décrivant uniquement les aspects nécessaires à la compréhension des mécanismes internes de création de valeur de l entreprise. Une décision «sage» sur l avenir de l entreprise ne se prête qu à partir d une vision claire de ce qu elle produit et de comment elle le produit dans son environnement. Le langage UML est un langage de modélisation des systèmes d information (SI) orientés objet. De manière simplifiée, chaque système d information propose à ses utilisateurs des fonctionnalités diverses par le biais d interfaces utilisateur.

6 Ces fonctionnalités sont élaborées sur base de composants formant le système d information. L interaction de ces composants internes délivre les diverses fonctionnalités du système. Ce dernier cesse de fonctionner correctement lorsqu un composant en est séparé. La notion «d orienté objet» des systèmes d information repose sur trois concepts essentiels : Le système forme un assemblage d éléments en interaction poursuivant un objectif commun. On considère également qu il peut être défini comme un ensemble organisé de méthodes et de procédés assurant une fonction particulière. Le système reste dynamique et produit un résultat lorsqu il fonctionne ou s exécute, c est-à-dire lorsque les objets interagissent ensemble. Un objet représente un élément du système. Les objets s animent durant l exécution du système et produisent ensemble le résultat attendu. L exécution du système rythme le cycle de vie des objets. Chaque objet joue un rôle clairement établi avant l exécution du système. Un système comporte éventuellement plusieurs objets ayant des rôles similaires à un instant donné de son exécution. Une classe décrit le rôle de l objet. Chaque objet correspond à une instance de classe dans un système en cours d exécution. En prenant la liberté de considérer l Entreprise comme un système, ses ressources et ses moyens de production correspondent aux objets d un système d information. Cet ouvrage propose d évaluer la possibilité d adapter le langage UML à la modélisation de la structure organisationnelle et du mode de fonctionnement de l entreprise. Un processus métier prend son origine dans l interaction des ressources et des moyens de production de l entreprise. 6

7 L activité de modélisation les processus métiers de l entreprise s inscrit généralement dans une démarche de gestion des processus métiers ou «Business Process Management» en anglais. Le cycle de vie de gestion des processus métiers comporte un minimum de trois étapes : L élaboration des processus métiers établit la situation existante «AsIs» et les options d améliorations vers une situation désirée «ToBe». Cette étape consomme l essentiel de l effort de modélisation. La mise en œuvre des processus métiers transpose les modèles de processus métiers dans l environnement opérationnel de l entreprise. Les tâches exécutées manuellement sont remplacées par des systèmes d automatisation autant que possible. La supervision des processus métiers récolte et compare les mesures aux objectifs fixés. Les écarts déterminent la définition de nouvelles actions. Cet ouvrage illustre l utilisation du langage UML comme un moyen de formaliser graphiquement l organisation et ses processus métiers. L activité de modélisation des éléments de l organisation nécessite elle-même une démarche structurée. L architecture d entreprise représente une solution adéquate à l organisation et à la classification des informations de l entreprise. En réalité, l architecture d entreprise constitue les fondements de l entreprise et de son fonctionnement interne. La définition d une architecture d entreprise repose sur les modèles d organisation et de processus métiers classés dans un référentiel commun à l ensemble des parties prenantes. Toute nouvelle initiative repose sur les informations du référentiel. Chaque modification requiert une évaluation d impacts sur les informations du référentiel comme la détermination des moyens de production, des systèmes d automatisation des tâches et des systèmes d information, etc. 7

8 Organisation de l ouvrage Cet ouvrage propose un cheminement parcourant la modélisation UML jusqu à l élaboration d une architecture d entreprise en parcourant quatre chapitres. Le chapitre 1 décrit l origine et les grands principes du langage UML utilisé dans la modélisation des éléments de l architecture d entreprise. Le chapitre 2 décrit la perspective structurelle ou statique de l organisation comme l organigramme ou la composition des biens et services produits de l entreprise. Le chapitre 3 décrit la perspective dynamique ou comportementale de l organisation comme la modélisation des processus métiers ou le mode de fonctionnement de l entreprise. Le chapitre 4 présente l élaboration d une architecture d entreprise fondée sur trois approches classiques : SqEME, Zachman et TOGAF. Cet ouvrage comporte des termes délibérément maintenus dans leurs langues d origine. Ces derniers se rapportant à un vocable généralement utilisé dans les méthodes, techniques et outils d élaboration d architecture d entreprise décrits dans cet ouvrage. 8

9 Chapitre 1 Le langage de modélisation unifié UML L ingénierie des systèmes d information dispose de ses propres outils et standards comme le langage de modélisation unifié ou «Unified Modeling Langage UML» en anglais. Le langage UML s apparente aux autres langages courants. Il se positionne toutefois comme un moyen de communication visuel entre les individus. En préconisant l expression graphique plutôt que textuelle, ce langage tente de réduire les barrières naturelles d interprétation des mots du langage courant. La description d un système s établit en produisant des diagrammes fondés sur une spécification commune d éléments graphiques. En 1997, un groupe de spécialistes du secteur des technologies de l information «L Object Management Group OMG» a standardisé le langage UML en regroupant d autres langages visuels comme Booch ou OMT. Par hypothèse, plusieurs éléments structurés et organisés logiquement forment le système d information. Chaque élément représente un moyen de stockage d information et de traitements associés. L assemblage de ces composants élémentaires produit les fonctionnalités du système d information. L élaboration d un système d information consiste à décrire ses constituants pour ensuite les mettre en œuvre à partir d un code machine exécutable. En considérant l entreprise comme un système, son organisation et son mode de fonctionnement correspondent aux éléments d un système d information. En conséquence, la conception de l entreprise s établit de la même façon qu un système d information. Le langage UML constitue un moyen de modélisation des éléments statiques et dynamiques de l entreprise.

10 Les éléments graphiques du langage UML s emploient principalement dans les situations suivantes : La conception de systèmes d information. La modélisation des processus métiers. L acquisition des besoins et des attentes des clients. La documentation des systèmes, processus et organisations. La dernière version majeure de la spécification du langage UML se subdivise en plusieurs chapitres : La superstructure définit les éléments graphiques du langage L infrastructure définit la sémantique du langage Le langage de contrainte objet ou «Object Contraint Langage OCL» décrit un langage annexe d expressions associées aux éléments du langage UML. Le protocole d échange de diagrammes garantissant l interopérabilité des diagrammes entre outils de modélisation. Le lecteur désirant obtenir la spécification complète du langage UML se rendra sur l adresse Internet : La spécification du langage UML ne propose aucune méthodologie de mise en œuvre. Cette absence lui confère une grande liberté d adaptation aux besoins divers de modélisation comme celle des organisations et de leurs modes de fonctionnement. Le langage UML reste un moyen de modélisation et de communication de l information. Ce premier chapitre décrit les principes de base du langage UML, la structure des diagrammes et leurs éléments graphiques communs. 10

11 1.1 La modélisation des systèmes avec UML Tout système s observe sous deux perspectives distinctes : La perspective statique traduit sa structure interne en se focalisant sur les constituants et leurs relations. La perspective dynamique traduit l exécution du système en se focalisant sur les événements et leurs conséquences sur sa structure. La figure 1.1 illustre les perspectives statiques et dynamiques d un système. Figure 1.1 Les perspectives de modélisation La perspective dynamique couvre également deux aspects complémentaires : L aspect comportemental illustre la modélisation des scénarios du mode de fonctionnement du système. L aspect conversationnel illustre la modélisation des échanges d information entre les objets du système durant son exécution. Un modèle représente une abstraction de la réalité du système. Il conserve uniquement les informations nécessaires et suffisantes lui permettant de communiquer une structure précise et de simuler aisément son mode de fonctionnement. La table 1.1 décrit sommairement les treize diagrammes de la spécification du langage UML version 2 supportant la modélisation des aspects statiques et dynamiques du système. 11

12 Table 1.1 Description sommaire des diagrammes UML Diagramme Cas d utilisation Classe Objet Composant Structure composite Paquetage Déploiement Description Le cas d utilisation énumère les besoins fonctionnels tels qu ils sont perçus de l extérieur du système. Ce type de diagramme facilite la communication des informations entre le système et ses parties prenantes. Le modèle de cas d utilisation comporte un diagramme de cas d utilisation complété éventuellement d un ou plusieurs documents décrivant textuellement les différentes fonctionnalités attendues du système. Le diagramme de classes représente la structure et les associations entre les constituants élémentaires d un système. Les classes y sont décrites complètement, sans tenir compte de l utilisation de l une ou l autre information durant l exécution du système. Le diagramme d objets représente la structure et les associations entre les constituants élémentaires d un système à un instant précis de son exécution. Un diagramme de composants illustre les principaux éléments constitutifs d un système. Un composant forme un groupe cohérent de fonctionnalités du système. Il comporte éventuellement plusieurs classes d objets. Ce type de diagramme représente une vue globale du système organisé en composants. Un diagramme de structure composite représente la structure interne des éléments du système (classe, composant ou nœud de déploiement). Il illustre également la structure de comportements standardisés et réutilisables du système. Un paquetage regroupe plusieurs classes couvrant des fonctionnalités similaires ou ayant des liens de dépendances importants. La notion de paquetage s utilise également dans la résolution des espaces de nommage des classes. Le paquetage ne se situe pas au même niveau conceptuel que le composant. Un composant regroupe éventuellement plusieurs paquetages. Un diagramme de paquetage représente les paquetages et leurs liens de dépendances. Le diagramme de déploiement se rapproche de la réalité en représentant les modules physiques du système contrairement aux paquetages et aux classes ne représentant que la description conceptuelle du système. Ce type de diagramme illustre également les liens et dépendances entre le système et d autres systèmes annexes. 12

13 Diagramme Activité États/transitions Séquence Communication Synchronisation Vue d ensemble d interactions Description Le diagramme d activités illustre la représentation des séquences d activités en détaillant chaque étape ou action exécutée. Un diagramme d état/transition illustre la modélisation d une «machine à états» en se focalisant sur un objet particulier du système et de ses réactions aux événements du système ou de son environnement. Un diagramme de séquence illustre l interaction entre les objets durant l exécution du système. Il se focalise sur les échanges d information au cours du temps. Un diagramme de communication illustre l interaction entre les objets durant l exécution du système en se focalisant sur les relations entre les objets et les messages échangés. Dans les versions précédentes de la spécification du langage UML, ce type de diagramme était reconnu comme le diagramme de «collaboration». Les diagrammes de synchronisation illustrent les changements d états ou de valeurs d un ou plusieurs objets dans le temps. Un diagramme de vue d ensemble d interactions constitue un type particulier de diagramme d activité dans lequel les activités sont représentées par des diagrammes d interactions comme le diagramme de séquence. La table 1.2 classifie les treize diagrammes UML suivant leurs perspectives statiques ou dynamiques. Table 1.2 Les perspectives et les diagrammes UML Perspective Statique Diagrammes Classe Objet Composant Structure composite Paquetage Déploiement 13

14 Perspective Dynamique - comportementale Dynamique - Conversationnel Diagrammes Cas d utilisation Activité États/transitions Séquence Communication Synchronisation Vue d ensemble des interactions La spécification du langage UML propose également plusieurs éléments graphiques communs aux treize diagrammes comme le cadre de représentation et l annotation. Ces éléments sont indépendants de la forme statique ou dynamique du modèle. Ils apportent simplement un éclairage particulier sur certains éléments du diagramme. 14

15 1.2 Le cadre de représentation Par défaut, chaque diagramme se compose d éléments visuels répartis sur une surface de représentation limitée par ses contours physiques. La spécification du langage UML autorise l insertion d un ou plusieurs cadres de représentation sur cette surface. Un cadre de représentation est formé d un libellé et d un rectangle délimitant le diagramme comme l illustre la figure 1.2. Figure 1.2 Le cadre de représentation Le libellé figurant dans la zone située en haut à gauche du cadre de représentation détermine le type de son contenu. La spécification du langage UML propose à cet effet plusieurs acronymes : Activité (act) Classe Composant (cmp) Interaction (sd) Paquetage (pkg) Machine à états (stm) Cas d utilisation (uc) Le nom du cadre complète éventuellement le libellé du cadre de représentation. 15

16 1.3 L annotation La spécification du langage UML offre la possibilité d ajouter du texte libre directement dans les diagrammes sous la forme d une annotation. La figure 1.3 illustre la représentation graphique d une annotation dans un diagramme de classes. L association entre l annotation et l élément graphique précise le lien logique entre le contenu de l annotation et l objet modélisé. Figure 1.3 L annotation dans un diagramme UML 16

17 Chapitre 2 La perspective structurelle de l organisation La structure organisationnelle se compose de différents organes ou de départements chargés de produire un résultat à valeur ajoutée en tentant d atteindre les objectifs fixés par sa direction. L organigramme représente graphiquement les liens hiérarchiques existant entre les rôles des intervenants de l organisation. Ces liens forment une structure organisationnelle capable d exécuter plusieurs activités coordonnées. La structure se caractérise par une nature «statique» au contraire des activités ayant un aspect «dynamique». Il est d ailleurs parfois tentant de croire que de nouvelles activités puissent être intégrées dans une structure organisationnelle sans y apporter un effort d adaptation vers cette nouvelle structure. Or, ces deux aspects sont liés. La statique et la dynamique de l organisation forment un tout. La structure organisationnelle supporte les processus métiers et ces derniers renforcent la structure. La modélisation d une structure organisationnelle établit les éléments d architecture et leurs liens dans l entreprise sans tenir compte des aspects dynamiques et temporels de l organisation. L entreprise commercialise des biens et des services formés de composants. La conception ou l amélioration d une organisation s inscrit intuitivement en deux phases consécutives : La détermination de la structure organisationnelle correspondant à la partie statique de l entreprise. L identification des processus métiers représentant le mode de fonctionnement de l entreprise. Ce chapitre décrit les diagrammes UML supportant les aspects statiques de l entreprise comme sa structure organisationnelle ou la composition de ses produits.

18 2.1 Les diagrammes UML statiques La notation UML propose six diagrammes décrivant les structures statiques : Le diagramme de classes Le diagramme d objets Le diagramme de composants Le diagramme de structures composites Le diagramme de déploiement Le diagramme de paquetages La spécification du langage UML ne précise pas d ordonnancement ou d ordre de priorité entre les différents types de diagrammes. On peut cependant définir à priori une classification de ces diagrammes par niveau conceptuel comme l illustre la figure 2.1. Figure 2.1 La classification des diagrammes par niveau conceptuel Le diagramme de déploiement offre le niveau conceptuel le plus élevé en proposant une vision macroscopique des éléments du système contrairement au diagramme de structures composites décrivant très précisément la structure interne de ces éléments. 18

19 2.1.1 Le diagramme de classes Le diagramme de classes décrit visuellement les constituants du système et leurs associations. Une classe définit les caractéristiques et les fonctionnalités d un élément ou d un objet du système. Un rectangle complété d un libellé d identification représente une classe dans un diagramme de classes comme l illustre la figure 2.2. Figure 2.2 La représentation simplifiée d une classe La définition formelle d une classe comporte deux caractéristiques fondamentales : Les attributs définissent les propriétés intrinsèques de l objet. Chaque attribut comporte une valeur éventuellement modifiée au cours de l exécution du système. Les opérations définissent les fonctionnalités de l objet, c est-à-dire la façon d utiliser cet objet dans le système. L appel à une opération modifie le comportement de l objet et produit un résultat déterminé. La figure 2.3 illustre la représentation UML des attributs et des opérations d une classe. Le rectangle symbolisant la classe se subdivise en trois parties : le libellé d identification, les attributs et les opérations. Figure 2.3 La représentation des attributs et opérations d une classe 19

20 La spécification du langage UML ne définit pas de répartition prédéterminée des classes sur le diagramme de classes. Les classes sont réparties selon la logique, les principes et les bonnes pratiques de l analyste métier. Les associations complètent le diagramme de classes en précisant les liens logiques existants entre les classes comme l illustre la figure 2.4. Figure 2.4 Le diagramme de classe Une association désigne la relation logique entre deux classes comme la relation existant entre les roues fixées sur une voiture et la voiture elle-même. Conceptuellement, l association entre deux classes crée une liaison bidirectionnelle. La première classe «voit» la seconde classe et inversement. Ce lien traduit également une notion de communication tacite entre les classes. Chaque classe peut demander à l autre classe d exécuter ses opérations. L ajout d une droite reliant les deux classes sur le diagramme de classes illustre graphiquement cette association bidirectionnelle. En ajoutant une flèche sur cette droite, on fixe une direction à l association, c est-àdire que l on précise une classe source et une classe cible. La classe cible ne perçoit pas l existence de la classe source alors que la classe source peut demander l exécution d une opération de la classe cible. La spécification du langage UML précise plusieurs catégories d association permettant de donner différentes nuances du lien existant entre plusieurs classes. La table 2.1 décrit ces catégories d association et leurs représentations graphiques. 20

21 Table 2.1 Types d association entre classes Association Représentation Description Dépendance Association Agrégation Composition Généralisation La dépendance représente l association la plus faible entre deux classes. Elle dépeint une relation de type «utilise» entre deux classes. Elle exprime simplement qu une classe A utilise éventuellement une classe B. L association représente un lien plus fort que celui de la dépendance. Elle dépeint une relation de type «avoir» entre une classe A et une classe B. Le sens de la flèche indique la direction de la relation. Lorsqu elle n est pas précisée, l association est considérée comme bidirectionnelle. Ce type d association dénote une relation de possession plus importante que la simple association. Une classe A possède la classe B. La flèche indique la direction de l agrégation. Ce type d association représente la relation la plus forte entre deux classes. Elle exprime une relation «est constitué de». Cette relation illustre une association de généralisation ou spécialisation entre classes. Réalisation Ce type d association indique qu une classe A mets en œuvre une classe B. Elle différencie la classe abstraite de la classe de mise en œuvre. 21

22 L association, comme la classe, dispose de plusieurs propriétés essentielles : Un nom. Un rôle placé aux extrémités de l association spécifiant la responsabilité d une classe envers l autre. Un indicateur de multiplicité placée aux extrémités de l association indiquant une contrainte numéraire. La table 2.2 reprend les multiplicités courantes des associations et leurs significations. Table 2.2 Multiplicité de l association Multiplicité Définition 1 Seulement Éventuellement 1 * Plusieurs 3 Trois La figure 2.5 illustre la représentation des propriétés d une association. Figure 2.5 La représentation des propriétés de l association L association de dépendance entre classes comporte également plusieurs nuances comme le décrivent les éléments de la table

23 Table 2.3 Les types d association de dépendances Lien Appelle Crée Dérive Instancie Permet Réalise Raffine Substitue Trace Utilise Signification La source appelle une opération de la cible La source crée des instances de la cible La source dérive la cible La source instancie la cible. La cible permet à la source d accéder à des propriétés internes La source définit un moyen de mettre en œuvre sa définition décrite par la cible. Le raffinement indique une relation entre les différents niveaux sémantiques. La source remplace la cible. La source supervise les activités de la cible. La source nécessite la cible pour sa mise en œuvre. La nuance de l association de dépendance se représente sur le diagramme de classe en y ajoutant le libellé correspondant comme l illustre la figure 2.6. Figure 2.6 L association de dépendance entre deux classes La spécification du langage UML ne précise aucun niveau de détail nécessaire et suffisant des diagrammes de classes. Cet aspect dépend exclusivement de la méthodologie d analyse et de conception de l entreprise. 23

24 En pratique, on distingue généralement deux niveaux de détails : Le niveau supérieur précise uniquement les classes et leurs associations sans en détailler les propriétés comme les attributs, les opérations et les catégories d association. Ce niveau conceptuel s utilise généralement dans une première phase de conception ou d élaboration d une solution. Le niveau détaillé spécifie toutes les informations nécessaires à la mise en œuvre du système en complétant le diagramme de classes des attributs, des opérations, des catégories d association, etc. Ces deux niveaux peuvent également être subdivisés en niveaux inférieurs suivant les besoins d analyse. Cependant, cette approche nécessite d avantage d effort de maintenance et d adaptation aux changements inhérents à ce type d activité. 24

25 2.1.2 Le diagramme d objets Pour rappel, un objet représente l instance d une classe. Tout objet apparaît au moment de l exécution du système afin de remplir une fonction déterminée par son aspect dynamique. Le système comporte éventuellement plusieurs objets correspondant à la même classe. Pour une entreprise, l exécution de processus métiers nécessite généralement la manipulation d objets comme des formulaires. Le formulaire «vide» correspond à sa définition. Chaque copie du formulaire représente un objet du système. Un objet se représente visuellement comme une classe. Cependant, le libellé composé du nom de l objet et du caractère de ponctuation «:» distingue l objet de sa classe comme l illustre la figure 2.7. Figure 2.7 La représentation d un objet du système Le diagramme d objets est une image instantanée des éléments d un système lors de son exécution. Contrairement au diagramme de classes, le diagramme d objets représente uniquement les associations créées à un instant précis. La figure 2.8 illustre une représentation d un diagramme d objets complété de ses associations. Figure 2.8 Le diagramme d objets 25

26 En pratique, le diagramme d objets complète le diagramme de classes et d activités. Le diagramme d états illustre les changements d état d un objet lors de l exécution du système. 26

27 2.1.3 Le diagramme de composants Les classes définissent les éléments du système. Le langage UML propose également la possibilité de regrouper logiquement plusieurs classes dans un seul composant. Dès lors, ce dernier offre un niveau fonctionnel plus important que ses classes indépendamment les unes des autres. Le composant est un sous-système intégré dans un système et généralement réutilisable dans un autre système sans en modifier la structure. L interface représente l exposition des fonctionnalités d un composant vers ses pairs. La figure 2.9 illustre la représentation de l interface selon la spécification du langage UML. Figure 2.9 La représentation d une interface La figure 2.10 représente graphiquement le composant formé d un rectangle complété d une icône et d un libellé d identification. Figure 2.10 La représentation d un composant Le diagramme de composants regroupe visuellement les composants du système. La figure 2.11 illustre le positionnement des composants et de leurs associations dans un diagramme de composant. 27

28 Le socket représenté sur l association en forme de demi-cercle distingue le composant fournisseur du composant consommateur. Dans une relation client-fournisseur, le socket désigne le consommateur tandis que l interface indique le fournisseur. Figure 2.11 Le diagramme de composant Le langage UML prévoit également la possibilité de décrire le contenu d un composant en précisant ses classes comme l illustre la figure Figure 2.12 Les constituants d un composant 28

29 2.1.4 Le diagramme de déploiement La mise en œuvre des définitions des classes et des composants se matérialise en éléments physiques assurant l exécution du système. Chaque élément physique consomme éventuellement des ressources ou des matières premières. La spécification du langage UML propose la notion d artefact de représentation de ces ressources dans le diagramme de déploiement. La figure 2.13 illustre la représentation d un artefact composé d un rectangle, d un libellé et d une icône. Figure 2.13 Exemple d artefact La figure 2.14 illustre la représentation d un élément physique du système sous une forme cubique complétée d un libellé d identification. Dans le jargon du langage UML, cette forme prend la dénomination de nœud. Un nœud traite éventuellement plusieurs artefacts. Figure 2.14 Exemple de nœud 29

30 Le diagramme de déploiement regroupe les nœuds, les artefacts et leurs associations comme l illustre la figure Figure 2.15 Diagramme de déploiement En pratique, le diagramme de déploiement illustre la structure du mode de fonctionnement de l entreprise comme la répartition de ses automates et des intervenants. 30

31 2.1.5 Le diagramme de structures composites Une structure composite représente un assemblage temporaire d éléments répondant collectivement à une fonctionnalité du système durant son exécution. Le diagramme de structures composites représente les interactions internes d un élément du système comme les classes, les composants ou les nœuds de déploiement. La spécification de la notation UML identifie ces objets internes comme faisant partie de la structure du système. Le connecteur représente visuellement les liens entre un ou plusieurs objets d une structure. Il est symbolisé par une simple droite tracée entre les objets. La figure 2.16 illustre un connecteur entre les objets Moteur et Roue apportant la signification suivante à la relation : «à un instant donné, le moteur actionne les roues». Figure 2.16 Le connecteur entre deux objets de structure Chaque structure propose une ou plusieurs fonctionnalités à son environnement. L échange d information entre la structure et son environnement s effectue par le biais d un port. Ce dernier est symbolisé sur le diagramme de structure composite par un petit rectangle placé sur les limites graphiques de la structure. Chaque port est associé au contenu de la structure. Le connecteur représente graphiquement cette relation. La figure 2.17 illustre le service Retrait d argent du composant Guichet Automatique réalisé à partir du Distributeur de billets et du Système comptable. 31

32 Figure 2.17 Le port et la réalisation d une fonctionnalité Un diagramme de structures composites documente également les comportements standards identifiés selon la spécification du langage UML comme une collaboration. Celle-ci regroupe des objets interconnectés par des flux de communication produisant un comportement déterminé. La figure 2.18 illustre une forme ovale comportant les objets détaillant le comportement du système. Figure 2.18 La collaboration 32

33 2.1.6 Le diagramme de paquetages Un paquetage regroupe logiquement une ou plusieurs définitions d éléments du système. Contrairement au composant, un paquetage n expose pas de fonctionnalités spécifiques à son environnement. En général, un paquetage structure les classes du système en définissant une arborescence logique entre elles. Par exemple, les classes Voiture, Camion, Avion et Bateau se regroupent logiquement dans le paquetage Transport. La figure 2.19 représente la forme graphique d un paquetage. Figure 2.19 La représentation d un paquetage Le diagramme de paquetages représente le contenu de chaque paquetage en y inscrivant le nom des classes, des composants ou des autres paquetages comme l illustre la figure Figure 2.20 La représentation des composants du paquetage Un système est éventuellement composé de plusieurs paquetages ayant des liens de dépendance réciproques. La notation UML propose deux types de liens : L accès signifiant qu un paquetage accède au contenu d un autre. L importation avec laquelle un paquetage incorpore le contenu d un autre paquetage. 33

34 La figure 2.21 illustre les deux catégories de dépendance entre les paquetages. Figure 2.21 Le diagramme de paquetage 34

35 2.2 Modélisation de la structure organisationnelle Les diagrammes UML statiques permettent d élaborer des modèles de structuration des éléments de l entreprise comme son organisation ou ses produits. Les diagrammes de classes et de composants sont généralement utilisés dans le cadre de représentation de structures hiérarchisées comme : L organigramme Les objectifs Les fonctions Les produits et services L organigramme L organigramme représente graphiquement la structure organisationnelle de l entreprise en formalisant les rôles, les fonctions et les liens hiérarchiques comme l illustre la figure Figure 2.22 Représentation d un organigramme Les attributs des classes permettent de répertorier les membres de l organisation en tenant compte de leurs rôles respectifs comme l illustre la figure

36 Figure 2.23 Spécification des intervenants dans la définition d une classe La figure 2.24 illustre la représentation graphique des membres de la classe correspondant au rôle «IT» de l organigramme. Figure 2.24 La représentation d un détail de l organigramme 36

37 2.2.1 Les objectifs Les objectifs de l entreprise décrivent les buts à atteindre de l organisation. Ces derniers peuvent être structurés hiérarchiquement ou classés suivant le domaine couvert. La figure 2.25 illustre une répartition des objectifs suivant la définition des tableaux de bord prospectifs ou «Balanced Score Card» en anglais. Figure 2.25 La représentation des objectifs de l entreprise 37

38 2.2.3 Les fonctions Les relations hiérarchisées permettent également de décrire les relations entre les fonctions de l entreprise comme l illustre la figure Figure 2.26 Modélisation des objectifs avec le diagramme de classe 38

39 2.2.5 Les produits et services Un produit final se compose généralement de plusieurs éléments. La figure 2.27 illustre la représentation des différents composants d un avion. Figure 2.27 La représentation de la structure d un avion La figure 2.28 représente la transposition graphique des éléments du précédent schéma dans un diagramme de classes. 39

40 Figure 2.28 La représentation conceptuelle des éléments de l avion 40

41 Pour reprendre un autre exemple, la figure 2.29 illustre les composants d un système de traction électrique d une bicyclette. Figure 2.29 Illustration d un système de traction d une bicyclette Le diagramme de composants illustré par la figure 2.30 représente conceptuellement les composants du système de traction électrique. 41

42 Figure 2.30 La représentation des composants du système de traction Le choix de l un ou l autre diagramme dépend de l audience et des objectifs de la modélisation des produits. 42

43 Une structure hiérarchisée conduit également à la définition d un catalogue de produits comme l illustre Figure 2.31 La représentation de la structure d un catalogue de produits 43

44 La figure 2.32 illustre la représentation d une arborescence des services de l entreprise. Figure 2.32 La représentation d une arborescence de services 44

45 Chapitre 3 La perspective comportementale de l organisation Les résultats de l entreprise dépendent directement de son mode de fonctionnement en relation avec l affectation des ressources, la chronologie et l ordonnancement de ses activités. Le mode de fonctionnement de l entreprise se révèle généralement durant son exécution. L élaboration ou l amélioration du mode de fonctionnement consiste à définir au préalable l aspect dynamique de l entreprise comme la représentation de ses flux internes. La perspective statique de l entreprise fournit les éléments nécessaires aux interactions produisant la valeur ajoutée de l entreprise. Suite à une première ébauche de définition des rôles et des responsabilités des différents intervenants, l analyse métier détermine ensuite leurs relations et leurs flux d activités constituant les processus métiers de l entreprise. La modélisation des processus métiers s inscrit dans une démarche d amélioration du mode de fonctionnement de l entreprise. Cette approche se compose généralement d au moins trois étapes cycliques : L analyse de la situation existante et des améliorations éventuelles. La mise en œuvre des solutions retenues. La supervision des processus métiers. Ce chapitre présente les diagrammes UML supportant l aspect dynamique de l organisation comme les processus métiers de l entreprise.

46 3.1 Les diagrammes UML dynamiques Le langage UML propose quatre catégories de diagrammes dynamiques : Le diagramme de cas d utilisation Le diagramme d interaction Le diagramme d état/transition Les diagrammes d activités Le cas d utilisation et son diagramme Le cas d utilisation illustre le comportement d un système perçu de ses utilisateurs. Un système comporte éventuellement plusieurs cas d utilisation. Les fonctionnalités du système sont déclinées en séquences d événements produisant une réaction déterminée. Cette séquence définit un scénario en faisant intervenir le bénéficiaire ou la partie prenante identifié comme un acteur selon la spécification du langage UML. Un individu, un processus ou un autre système externe exerce le rôle d acteur interagissant avec le système durant l exécution du cas d utilisation. Le cas d utilisation est également considéré comme une technique de récolte des besoins des parties prenantes dans un projet d élaboration ou d amélioration d un système. Le diagramme de cas d utilisation Le diagramme de cas d utilisation représente une vision synthétique des interactions entre les acteurs et les cas d utilisation du système. L acteur est symboliquement représenté par une icône et le cas d utilisation par un ovale inscrit dans le rectangle délimitant le système comme l illustre la figure

47 Figure 3.1 Le diagramme de cas d utilisation Selon la spécification du langage UML, les acteurs ne peuvent communiquer directement entre eux, à l exception de la relation de généralisation. Cette relation détermine le lien de dépendance entre les définitions des acteurs. Par exemple, les acteurs Agent de change, Guichetier se généralisent par l acteur Employé comme l illustre la figure 3.2. Figure 3.2 Les relations ente les acteurs 47

48 La spécification du langage UML prévoit également la définition d associations entre les cas d utilisation du système : La généralisation. Un cas d utilisation spécialisé hérite du comportement d un autre cas d utilisation. Le cas d utilisation spécialisé remplace ou complète le cas d utilisation général. Suivant la vue prise dans l observation de cette relation, on parle également de spécialisation. L inclusion. Ce cas d utilisation intègre le comportement d un autre cas d utilisation. L extension. Ce cas d utilisation intègre un scénario distinct situé en dehors de son scénario principal. Le cas d utilisation ciblé est réutilisable. La réalisation. Cette association entre cas d utilisation dénote un lien existant entre la définition d une fonctionnalité et sa mise en œuvre. La figure 3.3 illustre les différentes associations entre les cas d utilisation. Figure 3.3 Les relations entre plusieurs cas d utilisation 48

49 Les principes suivants se déduisent de l exemple présenté par la figure 3.3 : Le cas d utilisation Acheter un livre est une spécialisation du cas d utilisation Acheter. Le cas d utilisation Acheter inclut le cas d utilisation Payer. Le cas d utilisation Traitement de la transaction réalise ou met en œuvre le cas d utilisation Payer. Le cas d utilisation Emballer dans du papier-cadeau est une option envisageable dans les scénarios du cas d utilisation Acheter un livre. La documentation des cas d utilisation Le diagramme de cas d utilisation se révèle insuffisant dans la description des scénarios. Il s avère nécessaire d y ajouter une description textuelle des scénarios aux cas d utilisation. Ces derniers doivent être facilement compréhensibles pour l ensemble des parties prenantes du système. Par défaut, il n existe pas de standard de documentation des cas d utilisation dans la spécification du langage UML. Cette description dépend de l approche choisie. Cependant, la pratique courante de définition d un document établi en plusieurs sections reprises dans la table 3.1. Table 3.1 La structure de la documentation d un cas d utilisation Section Nom Version Objectif Résumé Acteurs Préconditions Déclencheurs Séquence Description Le nom du cas d utilisation représente son identifiant unique. La version indique l historique des révisions du document original. L objectif décrit brièvement ce que l utilisateur attend des fonctionnalités du système. Le résumé présente une idée générale du cas d utilisation. Cette section décrit les acteurs associés au cas d utilisation. Cette section décrit les conditions nécessaires de l état du système pour déclencher le cas d utilisation. Cette section décrit l événement provoquant l initialisation du cas d utilisation dès que les préconditions sont remplies. Cette section décrit le scénario principal ou l enchaînement typique des 49

50 Section Description d événements événements également appelé «flux de base». Chemins alternatifs Postconditions Associations Règles métiers Commentaire Les cas d utilisation contiennent éventuellement des séquences d événements secondaires ou alternatifs illustrant les variations au scénario principal. Cette section décrit également les événements produits lors d exception survenant dans le scénario principal. Cette section décrit les changements d état du système produit suite à l exécution du scénario. La fin de l exécution du cas d utilisation garantit les valeurs des postconditions. Cette section décrit les liens de dépendances avec d autres cas d utilisation Cette section décrit les règles métiers régissant le scénario principal et ses alternatives du cas d utilisation. Cette section décrit des informations annexes nécessaires à la compréhension du cas d utilisation ne pouvant s insérer dans les autres sections. 50

51 3.1.2 Le diagramme d activités Une activité est considérée comme une notion générale désignant une action, une tâche ou encore une opération affectée à un responsable de son exécution. Elle véhicule également l aspect de transformation d une ressource en valeur ajoutée pour son bénéficiaire. L activité prend forme uniquement lorsque le système s exécute. Un diagramme d activités rassemble les actions et leurs associations en décrivant une séquence d exécution se prêtant aisément à la modélisation des processus métiers de l entreprise. La figure 3.4 illustre un diagramme d activités complété d annotations. Figure 3.4 Exemple de diagramme d activité 51

52 Les activités Une activité s interprète comme un processus ou sous processus composé d une séquence logique et chronologique de tâches ou d actions dans le contexte du langage UML. Lorsqu un diagramme d activités représente seul un processus métier, son nom suffit à l identifier. La spécification du langage UML prévoit également la possibilité d identifier plusieurs activités dans un seul diagramme en le délimitant par un rectangle aux coins arrondis comme l illustre la figure 3.5. Figure 3.5 L utilisation du cadre d activité Les activités sont éventuellement soumises à certaines conditions ou contraintes : Les préconditions sont vérifiées avant l exécution de l activité et sont considérées comme nécessaires et suffisantes pour le démarrage de l exécution de l activité. Les postconditions décrivent les résultats produits de l exécution de l activité. La figure 3.6 illustre un exemple de définition de préconditions et postconditions. Par exemple, le diagramme d activité Envoyer un nécessite que le sujet et le destinataire soient tous les deux connus avant de pouvoir commencer l activité d envoi du message. Le courrier électronique est envoyé lorsque l activité est terminée. 52

53 Figure 3.6 La spécification des préconditions et postconditions Certaines activités sont paramétrables. Leur exécution nécessite l affectation d un ou plusieurs paramètres. La spécification du langage UML propose deux alternatives de paramétrage d une activité : Les paramètres sont directement spécifiés dans le cadre de l activité en dessous du libellé de l activité comme l illustre la figure 3.7. Figure 3.7 Première forme de spécification de paramètre de l activité Les paramètres sont définis avec des nœuds de paramètres fixés sur les limites du cadre de l activité comme l illustre la figure 3.8. Cette seconde forme permet d identifier visuellement les entrées et sorties de l activité. 53

54 Figure 3.8 Seconde forme de spécification de paramètre d activité Les actions L exécution de l activité se traduit par le déclenchement successif de ses actions. Une action représente une étape de l activité. La spécification du langage UML identifie l action comme une unité de travail indivisible exécutée par un individu ou un automate. La figure 3.9 illustre l activité Démarrer la voiture comportant deux actions : introduire la clé et tourner la clé. 54

55 Figure 3.9 Les actions La spécification du langage UML ne précise pas de forme syntaxique particulière du libellé désignant l action. Cependant, la bonne pratique préconise plutôt l utilisation d un verbe soulignant clairement l action. Les associations relient les actions entre elles. Elles sont représentées au moyen de flèches donnant la direction de l enchaînement de l exécution des actions. Une activité caractérisée par un grand nombre d actions et d associations peut être considérée comme un processus complexe. Le suivi de l enchaînement des actions s effectue en introduisant dans la réflexion la notion de jeton virtuel. Ce dernier parcourt les flux créés entre les associations et les actions. Le jeton déclenche l action lors de chaque traversée. Le jeton est retransmis à l action suivante lorsque cette action est terminée. En l absence d associations, les actions sont exécutées simultanément. La figure 3.10 illustre la représentation de trois actions simultanées. L activité se termine lorsque toutes les activités sont également terminées. Figure 3.10 Le déclenchement simultané de plusieurs actions 55

56 L exécution des actions est éventuellement soumise à des préconditions et postconditions comme les activités. L ajout d une annotation précise ces deux conditions comme l illustre la figure Figure 3.11 Les préconditions et postconditions sur les actions La spécification du langage UML précise différentes catégories d actions : L action simple, exécutée directement. L action d envoi d un signal ou d un message sous forme d une information structurée. Le jeton continue son cheminement directement après l envoi du message. L action de réception d un signal ou d un message. L action temporisée ou exécutée après un délai prédéterminé. L envoi d un signal asynchrone vers une action de réception n attend pas le retour de cette dernière pour continuer la séquence initiale. Le jeton est directement transmis à l action suivante. La figure 3.12 illustre une activité Traiter document, dans laquelle l action Écrire la notice est directement exécutée suite à l envoi du document depuis l action Envoyer document. 56

57 Figure 3.12 Action d envoi d un signal L action d envoi de signal asynchrone respecte les règles suivantes : Le signal est envoyé dès l arrivée de la totalité des jetons sur l action. Lorsque l action est exécutée, un objet message est créé et envoyé. Le destinataire du message n est pas nécessairement spécifié. La transmission de l objet effectuée, il n y a pas d attente en retour. La réception d un signal est une action synchrone. Ce type d action stoppe la progression du jeton tant que le message n est pas réceptionné. La figure 3.13 illustre la réception d un document avec l action Recevoir le Document. L action Sauvegarder un document s exécute dès la réception du message. 57

58 Figure 3.13 Action de réception d un signal La réception d un signal respecte les règles suivantes : L action de réception est déclenchée à l arrivée d un jeton. Si l action ne comporte pas d entrées, elle est exécutée en même temps que l activité. L action en attente de réception d un message interrompt le passage du jeton. La réception du message est considérée comme un événement déclencheur. La réception d un message libère le jeton et complète l exécution de l action. L action continue à accepter tous les événements durant l exécution de l activité. Un temporisateur retient momentanément le cheminement du jeton et donc de la séquence. Dès que le délai de rétention est passé, le jeton est libéré et transmit à l action suivante. Par exemple, l action Comptabiliser les ordres n aura lieu qu après la clôture du marché à seize heures comme l illustre la figure

59 Figure 3.14 La temporisation Par défaut, une action simple de type «CallOperationAction» correspond à l exécution d une opération sur un objet. Les entrées de l action doivent être compatibles avec les paramètres de l opération. Il existe deux modes de comportement de l action lors de l appel à l opération sur l objet : L appel synchrone. L action attend en retour le résultat de l opération. Dans ce cas, l opération «bloque» le flux en attendant que le résultat soit transmis. L appel asynchrone. L action n attend pas le retour du résultat de l opération et continue. Le résultat retourné par l opération est alors perdu. La spécification du langage UML ne propose pas de symboles spécifiques permettant de distinguer ces deux modes. En général, l outil de modélisation UML propose un paramètre dans les propriétés visuelles de l action ou de son association. Il existe également un autre type d action «CallBehaviourAction» permettant d appeler un sous processus. La figure 3.15 illustre ce type d appel en ajoutant la symbolique de la spécification UML sur l action ciblée. 59

60 Figure 3.15 L appel à une sous activité Ce mécanisme permet d élaborer un modèle en fixant des niveaux hiérarchisés de détails entre les activités comme les sous processus d un processus métier. Une action comporte éventuellement plusieurs entrées et sorties. Toutes les entrées d une action sont synchronisées, c est-à-dire que l action attend tous les jetons avant de continuer son exécution. Un nouveau jeton est créé pour chaque sortie. La figure 3.16 illustre ce mécanisme en représentant plusieurs actions. Figure 3.16 Entrées et sorties multiples Les flux et les noeuds Les associations entre les actions d un diagramme d activités constituent le flux de contrôle ou le flux d activité selon la spécification du langage UML. Les flèches indiquent la direction du cheminement d exécution des actions. La notion de «flux» suggère le passage du contrôle d une action à l autre. La flèche entre deux actions permet d identifier une action d origine et une action cible. L action Remplir formulaire représente l action d origine et l action Envoyer formulaire correspond à l action cible comme l illustre la figure

61 Figure 3.17 Exemple de flux de contrôle L action cible ne peut être exécutée que si l exécution de l action d origine est complétée en émettant un jeton en sortie. La flèche d un flux de contrôle dispose de plusieurs caractéristiques facultatives : Un nom. Une condition de garde décrite par une expression booléenne conditionnant le passage à l action suivante. Un poids indiquant le nombre de jetons nécessaires avant de continuer le cheminement vers l action suivante. Par défaut, cette valeur est égale à «1» lorsque le poids n est pas spécifié. La figure 3.18 illustre la représentation des caractéristiques du flux de contrôle entre deux actions. Figure 3.18 Les caractéristiques du flux de contrôle 61

62 Une activité se décompose en nœuds connectés par des flèches formant un flux. La notion de nœud est conceptuelle et désigne différentes catégories d éléments : Les actions. Les contrôles. Les objets. Les structures. Les nœuds de contrôles gèrent le flux de l activité : Le nœud initial. Le nœud final. Le nœud final de flux. Le nœud de décision. Le nœud de fusion. Le nœud de synchronisation. Le nœud de jointure. Le nœud initial indique l entrée du flux lors du démarrage de l activité. Il crée un jeton transmis dans les séquences de flux. Une activité contient éventuellement plusieurs nœuds initiaux permettant une exécution simultanée de plusieurs flux dans une même activité. Comme il l a déjà été spécifié, une activité peut également exécuter simultanément plusieurs actions sans préciser de nœuds initiaux. Cependant, l ajout des nœuds initiaux dans le diagramme d activité en facilite la lecture. L exécution d un nœud final provoque l arrêt de tous les flux de l activité ainsi que l arrêt de l activité elle-même. Lorsque l activité comporte plusieurs exécutions de flux simultanés, il suffit qu un seul jeton atteigne un des nœuds finaux pour que tous les autres flux s interrompent. Si l activité est appelée par une action dans une autre activité, le jeton est retourné à cette action. Par exemple, dès qu une action comme Réaliser un produit 1 est terminée, les deux autres s arrêtent également comme l illustre la figure

63 Figure 3.19 Les nœuds initiaux et finaux La spécification du langage UML définit également le nœud final de flux. Contrairement au nœud final, lorsqu un jeton arrive sur un nœud final de flux, seuls les jetons qui atteignent ce nœud sont détruits. Lorsque l activité comporte plusieurs flux simultanés, le flux disposant d un nœud final de flux se termine et les autres continuent leur exécution. La spécification du langage UML distingue visuellement ces types de nœuds finaux en représentant le nœud final de flux par un cercle contenant une croix. La figure 3.20 illustre la situation dans laquelle le flux s interrompt lorsqu il n y a plus de pages à imprimer. Figure 3.20 La représentation d un nœud final de flux L exemple décrit dans la figure 3.20 laisse apparaître de nouvelles constructions comme le nœud de décision symbolisé par un losange. Ce type de nœud correspond à la prise de décision d un choix exclusif entre une ou plusieurs alternatives. 63

64 Le nœud de décision se compose d une entrée et de plusieurs sorties comme l illustre la figure Un jeton arrivant à son entrée est soumit au choix exclusif de la sortie à prendre. Chaque sortie est affectée d une condition de garde limitant l accès uniquement au jeton correspondant. Cette condition de garde est toujours représentée sous une forme textuelle placée entre crochets. La cohérence du diagramme exige que toutes les conditions de garde des sorties d un nœud de décision soient mutuellement exclusives. Figure 3.21 Le nœud de décision Une sortie par défaut peut être définie en y appliquant la condition de garde «sinon». Une seconde pratique consiste à définir l évaluation d une activité directement dans le nœud de décision. Le résultat de cette évaluation influence le choix de la sortie à prendre. La figure 3.22 illustre la représentation de l évaluation ajoutée sur le nœud de décision avec l annotation de catégorie «decisioninput». 64

65 Figure 3.22 Les entrées de décision Un nœud de fusion représente deux ou plusieurs chemins de contrôle se rejoignant comme l illustre la figure Ce nœud comporte deux ou plusieurs entrées et une seule sortie. Lorsqu un jeton arrive à l une des entrées, il est directement recopié en sortie, éliminant automatiquement les autres sorties. Cette construction est équivalente à celle définissant plusieurs entrées sur une action. Il est cependant conseillé d employer les nœuds de fusion autant que possible afin de rendre plus aisée la lecture du diagramme d activité. 65

66 Figure 3.23 Le nœud de fusion Un nœud de synchronisation permet de définir plusieurs flux simultanés. Ce nœud a une entrée et plusieurs sorties comme l illustre la figure Lorsqu un jeton arrive sur un nœud de synchronisation, il est dupliqué et transmis simultanément à toutes les sorties. Un nœud de jointure dispose de plusieurs entrées et d une seule sortie. Il synchronise les flux entrants, c est-à-dire que tous les flux d entrée doivent être présents pour continuer. Selon l exemple présenté dans la figure 3.24, l action Mise en œuvre est exécutée uniquement si les trois actions simultanées sont terminées. 66

67 Figure 3.24 Le nœud de synchronisation et de jointure Les nœuds d actions et de contrôle peuvent être regroupés en nœuds structurés afin de reproduire des comportements spécifiques caractérisant certaines situations. Ces constructions ne sont pas sans rappeler les structures des langages de programmation comme les boucles. Il existe quatre structures fondamentales : La condition en utilisant le nœud de décision. La boucle permettant de reproduire itérativement une suite d actions. La zone de propagation. La transformation en flots de données ou «Data Streaming» en anglais. Une boucle produit une construction permettant des itérations successives d un comportement déterminé. Son exécution se poursuit tant qu une condition spécifique est remplie. La boucle se compose de trois sections : la mise au point, le test et le corps, comme l illustre la figure

68 La section de mise au point est exécutée à l entrée de la boucle initialisant sa structure. Les sections de test et le corps sont exécutés itérativement jusqu à ce que la valeur du test soit fausse. Figure 3.25 La représentation d une boucle Une zone de propagation permet de représenter l exécution d une ou plusieurs actions sur chaque élément placé dans une collection de données en entrées tout en évitant le recours à la structure de boucle. Un nœud de propagation définit la collection d éléments en entrée ou en sortie. La spécification du langage UML représente la zone de propagation par un rectangle aux coins arrondis ayant une bordure en pointillé comme l illustre la figure

69 Figure 3.26 La représentation de la zone de propagation Une zone de propagation contient éventuellement plusieurs nœuds de propagation en entrées et en sorties. 69

70 Les éléments arrivant à l entrée de la zone de propagation sont placés dans le nœud de propagation représentée sous la forme de petits rectangles. Ces éléments sont ensuite extraits les uns après les autres du nœud de propagation pour être traités par les actions précisées dans la zone de propagation. Les nœuds de propagation spécifiés en sortie de la zone de propagation ont toujours la même taille que les nœuds de propagation en entrée de la zone de propagation. Par défaut, la zone de propagation exécute par itération successive chaque élément présent dans les nœuds de propagation. La spécification du langage UML permet également de définir l ordre d extraction des éléments du nœud de propagation en désignant textuellement cet ordre. Il existe quatre modes : FIFO pour «First In First Out» où le premier élément du nœud de propagation est extrait en premier. LIFO pour «Last In First Out» où le dernier élément du nœud de propagation est extrait en premier. Désordonné où les éléments n ont pas d ordre d extraction particulier. Ordonné, où l ordre des éléments suit une logique prédéfinie. La transformation en flux continu ou «streaming» en anglais correspond à l exécution d actions successives sans interruption. 70

71 Lorsque les diagrammes deviennent trop complexes par leur taille, la spécification du langage UML prévoit à cet effet un nœud connecteur. Ce type de nœud évite le chevauchement excessif de flux de contrôle dans un diagramme d activité. Un nœud connecteur est défini visuellement par un cercle complété d un identifiant comme l illustre la figure Figure 3.27 Le nœud connecteur 71

72 Les objets Le flux de contrôle active les actions les unes après les autres en transmettant le jeton. Pour rappel, le jeton active l exécution de chaque action. La spécification du langage UML prévoit également la possibilité d acheminer des informations structurées d une action à l autre. Pour ce faire, l action dispose d entrées et de sorties. Les données transmises aux actions sont regroupées dans un objet conforme à une description précisée dans une classe. La figure 3.28 illustre la représentation d un objet symbolisé par un rectangle et d un libellé d identification. Figure 3.28 La représentation d un objet La spécification du langage UML propose également la définition d un flux d objets comme un flux de contrôle. Sa symbolique de représentation est d ailleurs similaire aux flux de contrôle. On représente un objet dans un diagramme d activités comme un élément d entrée en lui affectant une flèche dirigée vers une action. La production d un objet en sortie d une action se représente par une flèche dirigée vers cet objet. La direction de la flèche indique le sens du flux d objets. Lorsqu une action traite un objet, il a la capacité de modifier l état de ce dernier. La spécification du langage UML propose de décrire l état courant de l objet en ajoutant à son libellé l état entre crochets comme l illustre la figure Figure 3.29 l état d un objet Par défaut, chaque nœud détient un nombre infini d objets. Cependant, il est parfois nécessaire de déterminer qu un nœud ne peut détenir qu un nombre fini d éléments. Pour cela, la contrainte de type «upperbound» est ajoutée avec une valeur définie indiquant le nombre maximum d objets. 72

73 Cette limite impose au nœud d accepter les objets entrants tant que la valeur maximum n est pas atteinte. La figure 3.30 illustre la représentation de cette contrainte. Figure 3.30 La représentation des limites De la même façon que la spécification d une contrainte, l ajout sur l objet d une règle de tri est envisageable comme l illustre la figure Par défaut, les objets entrants sont triés avec la règle de FIFO ou «First In, First Out», c est-à-dire le premier objet entrant est le premier sortant. Figure 3.31 L ordre des objets Un filtre est défini en ajoutant une contrainte de sélection directement sur les flèches représentant les flux d objets limitant le passage d élément. La figure 3.32 illustre la représentation de la contrainte sur le flux d objets en ajoutant une annotation sur l objet de type <<selection>>. 73

74 Figure 3.32 La sélection des objets La seconde version de la spécification du langage UML prévoit également la représentation des nœuds d objets sous une forme différente. Le langage introduit la notion de broche. Chaque broche est représentée visuellement par un petit rectangle placé sur le contour de l action comme l illustre la figure L identification de l objet est réalisée en ajoutant un libellé directement sur la broche. 74

75 Figure 3.33 Les broches Les flèches connectées aux broches donnent le sens des entrées et des sorties de l action. 75

76 Une action comporte éventuellement plusieurs broches d entrées et de sorties. Dans ce cas, l action est exécutée lorsque toutes les broches d entrées ont reçu leur objet. Lorsqu une broche est spécifiée sans source ni destination, une flèche lui est ajoutée afin de déterminer visuellement l entrée ou la sortie. L affectation d une constante déterminant le nombre d objets sur une broche d entrée est réalisée en ajoutant cette contrainte dans le libellé de la broche comme l illustre la figure Figure 3.34 Les broches de valeur Les contraintes de sélection et de transformations sur les flux d objets restent valables en utilisant des broches. Le nœud de mémoire tampon centralisé décrit un nœud fournissant un emplacement destiné à mémoriser les objets entrants et sortant des flux d objets. Plus précisément, cette mémoire est capable de retenir les valeurs de différentes sources et fournir ces valeurs à différentes cibles. L ordre des objets suit la même règle que le nœud d objet simple. La spécification du langage UML symbolise cette mémoire tampon sous la forme d un rectangle placé directement sur le flux de contrôle comme l illustre la figure Figure 3.35 La mémoire tampon Un nœud de stockage de données est un nœud acceptant des données de différentes sources transmissibles à plusieurs cibles. Au contraire du nœud de mémoire tampon, les informations traversant un nœud de stockage sont copiées. Ces données sont réutilisables par d autres actions tant que le flux de contrôle n atteint pas un nœud final. 76

77 La figure 3.36 illustre la représentation du nœud de stockage. Figure 3.36 Le nœud de stockage Lorsque le nœud final est atteint, les informations contenues dans le nœud de stockage sont détruites. Les partitions Suivant la nature des activités, il est nécessaire d indiquer le ou les responsables de certaines actions. Dans d autres cas, on cherche à regrouper des actions partageant certaines caractéristiques communes. Les partitions permettent d isoler des nœuds selon les besoins comme la correspondance entre une partition et une unité organisationnelle d un modèle métier. La spécification du langage UML symbolise les partitions sous la forme de rectangles comme l illustre la figure

78 Figure 3.37 Partition verticale La spécification du langage UML prévoit également la définition de partitions horizontales et leur croisement avec les partitions verticales afin de définir une structure à deux dimensions comme l illustre la figure

79 Figure 3.38 Les partitions verticales et horizontales Un libellé <<external>> est ajouté au libellé de la partition lorsqu il est nécessaire d y inclure des actions situées en dehors du système. 79

80 Les interruptions et les exceptions Il est parfois nécessaire d interrompre une activité en cours d exécution. La spécification du langage UML prévoit à cet effet la définition d une zone d interruption sur le diagramme d activité. Lorsqu une condition d interruption survient, les actions prédéfinies sont exécutées tandis que les autres flux de contrôle sont interrompus. Plusieurs éléments participent à l élaboration d une interruption dans un flux de contrôle : La zone d interruption détermine une zone de mise sous surveillance afin de réagir en cas d interruption. L action d interruption placée dans la zone d interruption détecte l interruption et crée un jeton. La flèche d interruption utilisée entre l action d interruption et le nœud de traitement de l interruption. Le nœud de traitement de l interruption chargé d exécuter les actions attendues. La figure 3.39 illustre la représentation de la zone d interruption. Figure 3.39 La zone d interruption 80

81 Une exception est une condition d erreur provoquée durant de l exécution d une action. Le langage UML propose la définition d une réponse adéquate lorsque survient une exception. La figure 3.40 illustre la flèche d exception associée à l action. L action est alors «protégée». Figure 3.40 La représentation d une exception Lorsqu une exception survient sur une action, celle-ci est interrompue et un jeton d exception est produit. Ce dernier contient l origine de l exception exploitable par un nœud de traitement. 81

82 Des exceptions peuvent également survenir sur les flux d objets. La spécification du langage UML prévoit dans ce cas une broche d exception ayant une sémantique similaire à celle utilisée précédemment. L identification d une exception sur la broche est réalisée en y ajoutant un petit triangle comme l illustre la figure Figure 3.41 Les broches d exception 82

83 3.1.3 Les diagrammes d interactions Selon la spécification du langage UML, une interaction est un échange d information entre les éléments du système. Cet échange d information prend la forme d un message ou d un signal transmis d un élément à l autre. Les diagrammes d interactions illustrent la communication d information entre les éléments d un système. Le langage UML propose différents types de diagrammes offrant chacun un aspect particulier de la communication : Le diagramme de séquence Le diagramme de communication Le diagramme de synchronisation Le diagramme de vue d ensemble d interactions Le diagramme de séquence Les éléments du système créent de la valeur en interagissant ensemble sous la forme d échange de messages ou de signaux. Le diagramme de séquence illustre graphiquement ces interactions sur un espace en deux dimensions : Le sens vertical du diagramme précise l aspect temporel des interactions. Le sens horizontal du diagramme précise les interactions entre les éléments impliqués. La figure 3.42 illustre un diagramme de séquence. Les éléments du système sont alignés dans l axe horizontal du diagramme. Pour chaque élément, une droite verticale et discontinue est ajoutée. Elle symbolise le temps et sa longueur représente la durée de vie de l élément durant son interaction. On la désigne communément comme la «ligne de vie» de l élément. 83

84 Figure 3.42 Exemple de diagramme de séquence Les flèches positionnées horizontalement sur un diagramme de séquence représentent les échanges de messages entre les éléments du système. L origine de la flèche identifie l élément source et la flèche correspond à l élément cible. Le langage UML précise deux modes d appels aux éléments : L appel synchrone symbolisé graphiquement par une flèche pleine. L élément source est bloqué tant que l élément cible ne lui retourne pas de réponse. L appel asynchrone symbolisé graphiquement par une flèche normale. L élément source est libre de continuer, sans attendre de réponse de l élément cible. La figure 3.43 illustre ces deux modes d appel. L élément Terminal est suspendu durant la recherche des informations sur l élément Compte. 84

85 Client Terminal Compte 1: Saisir identifiant 2: Rechercher les informations 3: Afficher détails Figure 3.43 Les deux modes d appels des éléments Le langage UML précise graphiquement la durée d activation d un élément en représentant un rectangle chevauchant la ligne de vie d un élément comme l illustre la figure Client Terminal Compte 1: Saisir identifiant 2: Rechercher les informations 3: Afficher détails Figure 3.44 La représentation des durées d activation des éléments 85

86 Les durées d activation des éléments sont symboliques. Elles donnent simplement une indication graphique de haut niveau. Le diagramme de séquence garde comme objectif l illustration des séquences d échanges de messages entre les éléments du système et non la description précise des durées d interaction. La spécification du langage UML propose l utilisation du diagramme de synchronisation représentant les détails temporels. Une flèche pointillée désigne le résultat retourné à l élément source comme l illustre la figure Client Terminal Compte 1: Saisir identifiant 2: Rechercher les informations Détails client 3: Afficher détails Figure 3.45 La représentation du retour d un appel 86

87 Un élément est éventuellement amené à créer ou détruire un autre élément. La figure 3.46 illustre cette situation en représentant graphiquement la destruction de l élément par une croix placée en fin de ligne de vie de ce dernier. Figure 3.46 La représentation de la création et destruction d un élément 87

88 Le diagramme de communication Le diagramme de communication se concentre sur la représentation graphique des échanges de messages entre les éléments placés librement sur la surface du diagramme comme l illustre la figure La notion de durée de vie n apparaît pas dans ce type de diagramme. Les échanges de messages sont représentés graphiquement par les flèches placées à proximité des associations reliant les différents éléments. Le sens de la flèche donne la direction de la transmission et de la réception du message. Figure 3.46 Le diagramme de communication La précédente version de la spécification du langage UML désignait ce type de diagramme comme étant le diagramme de collaboration. 88

89 Le diagramme de synchronisation Le diagramme de synchronisation illustre graphiquement les changements d état d un élément au cours du temps comme l illustre la figure Ce type de diagramme se compose d une abscisse d échelle de temps et d une ordonnée spécifiant les différents états. Le nom de l élément est inscrit verticalement à gauche du diagramme. La contrainte de temps est également précisée par un libellé comme l illustre la figure Figure 3.47 Le diagramme de synchronisation Le diagramme de synchronisation offre également la possibilité de représenter plusieurs éléments dont l état est modifié en fonction de leurs interactions, c est-à-dire par leurs échanges de messages ou d événements extérieurs comme l illustre la figure Les flèches entre les lignes de temps des différents éléments représentent les interactions entre ces derniers. 89

90 Figure 3.48 La synchronisation de plusieurs éléments 90

91 Le diagramme de vue d ensemble d interactions Le diagramme de vue d ensemble d interactions représente une construction graphique élaborée depuis les concepts simplifiés du diagramme d activités intégrant les diagrammes d interactions. Pour rappel, le diagramme d activités a comme objectif de représenter les enchaînements des activités du système. Le diagramme de vue d ensemble des interactions utilise le même concept à l exception des activités qu il remplace par des diagrammes d interactions comme l illustre la figure Ce type de diagramme permet de visualiser et d organiser les flux entre les diagrammes d interaction. Figure 3.49 Le diagramme de vue d ensemble d interactions 91

92 3.1.4 Le diagramme d états Un état est un ensemble de valeurs déterminées caractérisant les propriétés d un élément du système. Chaque élément change éventuellement d état en fonction du temps et de son cycle de vie dans le système. Un événement déclenche la transition d un état à l autre. Un événement représente toute cause capable de modifier l état courant d un élément en produisant différents effets : La modification des valeurs des propriétés de l élément. La transmission ou la réception d un message. L émission ou la réception d un signal. Tout événement provoqué à l intérieur du système et provenant éventuellement de l environnement du système déclenche un stimulus sur un ou plusieurs éléments. Ces derniers réagissent en produisant un effet en retour. Si le système comporte plusieurs éléments de même type, ils réagiront tous de la même façon à un événement déterminé. Le diagramme d états, parfois décrit comme «machine à états», spécifie le comportement dynamique d un élément en modélisant son cycle de vie. Chaque élément est traité comme une unité isolée réagissant aux événements de son environnement. Le diagramme d états décrit le comportement d un élément en l isolant des autres. Un état est représenté graphiquement avec un rectangle aux coins arrondis comme l illustre la figure Figure 3.50 La représentation d un état Le diagramme d états schématise les différents états d un élément. Il spécifie également les conséquences du déclenchement d un événement sur ce dernier en représentant graphiquement les transitions au moyen de flèches simples placées entre les états. 92

93 Par exemple, une fenêtre peut avoir trois états mutuellement exclusifs : Ouverte Fermée Verrouillée La figure 3.51 illustre ces trois états respectent une logique déterminée. Figure 3.51 Exemple de diagramme d états Certaines situations conduisent à déterminer un état initial et final correspondant respectivement au début et à la fin du cycle de vie de l élément. Ils diffèrent des états ordinaires en ne se déclenchant qu une seule fois. Il ne peut y avoir de transition vers un état initial et aucune transition ne peut être déclenchée depuis un état final. Le langage UML distingue visuellement ces deux états ou pseudo états. La figure 3.52 illustre les états de l essence dans son cycle de vie. Une fois extrait, le pétrole est raffiné et consommé. La consommation de l essence entraîne sa «destruction» ou sa «disparition» du système. Figure 3.52 La représentation des pseudo états initial et final Le diagramme d état accepte également la composition d états. Un état se compose d autres états comme l illustre la figure

94 Pour reprendre l exemple précédent, on obtient l essence en raffinant le pétrole brut. Or, durant l opération de raffinage, le pétrole subit plusieurs changements d état. Il est reste dans l état fragmenté jusqu à ce que l essence soit produite. Le langage UML définit également la représentation du choix dans l état composé sous la forme graphique de losange comme un pseudo état. Figure 3.53 La représentation d un état composé Les flèches entre les états ou pseudo états représentent les transitions. Cependant, le langage UML propose également d en spécifier certains détails en précisant la syntaxe Déclencheur [condition]/effet : Le déclencheur indique la condition nécessaire au déclenchement de la transition. La condition valide le déclenchement de la transition. Elle est évaluée lorsque l événement se produit. L effet spécifie l activité exécutée lors du déclenchement de la transition. Un état composé est éventuellement représenté en cachant ses détails. L ajout d un icône particulier le différencie des autres états ordinaires comme l illustre la figure Figure 3.54 La représentation d un état composé masquant les détails 94

95 3.2 Modélisation du mode de fonctionnement de l organisation Les processus métiers Les diagrammes d activités sont particulièrement bien adaptés à la modélisation des processus métiers. Pour rappel, un processus métier constitue une séquence logique et chronologique de tâches coordonnées permettant d atteindre les objectifs de la direction. La modélisation des processus métiers s effectue repose sur les diagrammes d activités du langage UML. La figure 3.55 illustre un diagramme d activités représentant un processus métier d achat en ligne. 95

96 Figure 3.55 Exemple de processus métier d achat en ligne 96

97 Les figures 3.56, 3.57 illustrent la modélisation de la situation initiale «AsIs» du processus métier d achat tandis que les figures 3.58, 3.59, 3.60 et 3.61 illustrent sa situation améliorée «ToBe». Figure 3.56 Exemple de processus métiers (partie 1) 97

98 Figure 3.57 Exemple de processus métiers (partie 2) 98

99 Figure 3.58 Exemple de processus métiers (partie 3) 99

100 Figure 3.59 Exemple de processus métiers (partie 4) 100

101 Figure 3.60 Exemple de processus métiers (partie 5) 101

102 Figure 3.61 Exemple de processus métiers (partie 6) 102

103 3.2.2 Les interactions La modélisation du mode de fonctionnement de l entreprise en diagrammes d activités nécessite éventuellement une étape préliminaire de mise en évidence des interactions entre les parties prenantes de l organisation. Le diagramme de communication représente les échanges de messages entre les différents intervenants de l entreprise. La figure 3.62 illustre l échange de message entre plusieurs individus en charge de rédiger, valider et transmettre un document au client. Figure 3.62 Exemple d échange de message entre plusieurs éléments 103

104 La représentation des relations entre les parties prenantes de l entreprise (client, fournisseur, actionnaire, employé, etc.) et ses processus métiers se représente en utilisant le diagramme de cas d utilisation. La figure 3.63 illustre la relation entre le client et le processus de demande de crédit. Figure 3.63 Exemple de relation entre le client et le processus 104

105 Chapitre 4 L Architecture d Entreprise La modélisation de l organisation et des processus métiers offre un moyen de communication efficace lorsqu elle est introduite dans une démarche globale de conception organisationnelle. L entreprise est une structure de coordination d activités alignées sur une stratégie poursuivant des objectifs déterminés. Les collaborateurs exécutent ces activités en employant les moyens et les ressources disponibles. L organisation détermine le mode de fonctionnement de l entreprise en cherchant à optimiser son efficience. Pour cela, elle tente de rendre les comportements individuels prédictifs aux événements ordinaires en élaborant des processus métiers alignés sur la stratégie de l entreprise. La conception d une organisation est comparable à celle d un édifice. Cette activité débute sur une vague idée de ce qui doit être réalisé pour ensuite s affiner jusqu à atteindre les résultats escomptés. L architecture d entreprise décrit les éléments de base de l organisation nécessaires à l alignement de ses processus métiers à la stratégie de l entreprise. La notion d architecture se définit comme la conception d une structure physique, réelle ou virtuelle.

106 L architecture inclut également un certain nombre de concepts fondamentaux : Un cadre de travail «Framework» ou un contexte de classification et d organisation des éléments d architecture. Une méthode de conception et de détermination des éléments d architecture. Une collection de principes ou de contraintes. Un plan structuré de l organisation et de ses éléments en interaction. L architecture d entreprise représente l assise sur laquelle s appuie l entreprise pour atteindre ses objectifs et réaliser sa vision des affaires. La définition de l architecture d entreprise devient dès lors l ensemble des principes, directives, politiques, modèles, normes et processus alignés sur la stratégie commerciale de l entreprise. Elle guide les choix d élaboration et de mise en œuvre des solutions dans un cadre de référence d exécution intégrant les collaborateurs et les ressources disponibles. Le mode de fonctionnement et la réussite de l entreprise dans la conduite des affaires dépendent amplement de la communication et des techniques de traitement de l information qu elle déploie. L architecture d entreprise est généralement complétée avec l architecture des systèmes d information. Cette agrégation d architectures contribue à l alignement des moyens sur la stratégie en dirigeant les divers aspects de l entreprise vers un objectif commun. La communication des informations repose sur la notion de partage de la connaissance à la source du patrimoine de l entreprise. L architecture d entreprise décrit les éléments architecturaux de l organisation. Lorsque l entreprise est perçue comme un système constitué d éléments ou de sous-systèmes, son analyse nécessite une approche holistique. L observation d un seul de ses éléments ne peut conduire à l identification du comportement de l ensemble. Chaque partie doit être considérée avec le système en prêtant également attention aux échanges avec son environnement. La communication et l utilisation des éléments de l architecture d entreprise nécessitent une organisation ou une structuration appropriée afin de rendre cette connaissance accessible et compréhensible à l ensemble des parties prenantes de l entreprise. L adoption d un cadre de référence supportant la définition et la maintenance d une architecture d entreprise garantit leur qualité tout en respectant les règles établies de conception. La définition ou la maintenance d une architecture nécessite l emploi d un cadre de référence. 106

107 Les modèles d architecture ont été développés depuis l introduction de la qualité dans les modes de fonctionnement des entreprises. La plupart d entre eux structurent les processus métiers génériques de l entreprise. Par exemple, la figure 4.1 illustre le modèle de chaîne de valeur de M. Porter distinguant deux catégories d activités dans l entreprise : les activités primaires et les activités de support. Figure 4.1 Chaîne de Valeur de M. Porter 107

108 La figure 4.2 illustre la structure des processus de gestion du développement de systèmes d information selon la norme ISO Cette norme propose un modèle d évaluation de la capacité et de maturité des processus métiers applicable au cadre de référence en l adaptant selon ses besoins. Figure 4.2 Modèle de structure de processus selon l ISO

109 La figure 4.3 illustre la représentation de la structure des processus métiers selon IDS-Scheer, éditeur de la solution ARIS et acteur majeur dans le monde de la gestion des processus métiers. Ce modèle, dit en «Y», établit les relations entre les processus de support, logistiques et d ingénierie. Figure 4.3 Modèle en Y d IDS-Scheer 109

110 Cet ouvrage décrit un cadre de référence fondé sur trois référentiels génériques : La méthodologie SqEME de développement d architecture d entreprise et de gestion des processus métiers propose un cadre d analyse holistique de l organisation d entreprise par le biais de quatre fenêtres. Cette méthodologie aligne les éléments d architecture sur la stratégie de l entreprise en se focalisant sur les relations existantes entre les différents concepts véhiculés dans l organisation comme la vision, la mission, la stratégie, les objectifs, les échanges d information, les parties prenantes, les ressources, les collaborateurs, l affectation des tâches, la modélisation des processus, les moyens de mesures, etc. Elle répond à la question «Comment réaliser l architecture d entreprise dans une perspective globale ou systémique?». Le cadre de référence Zachman classifie les éléments d architecture en tenant compte de perspectives et des aspects des affaires. Il répond à la question «Quels sont les éléments d architecture à produire et comment les classifier?». L architecture de l Open Group TOGAF propose un cadre de référence de stockage et d élaboration des éléments d architecture d entreprise. Ce cadre de travail répond à la question «Comment organiser le développement et la gestion des processus métiers?». Le cadre de référence proposé dans cet ouvrage utilise le langage UML comme moyen de modélisation des différents aspects de l entreprise. Ceci n empêche pas le lecteur d y introduire tout autre notation répondant à ses attentes dans le cadre de son environnement. 110

111 4.1 Le développement d architecture d entreprise avec SqEME Les principes de SqEME La méthodologie SqEME est une approche de mise en œuvre des processus métiers dans les organisations. Cette approche se fonde sur la perception de l entreprise comme un système social composé d interactions entre des individus placés au centre de l organisation. Les processus métiers représentent un point d entrée essentiel à toute initiative de développement ou d amélioration des résultats. Or, ces derniers dépendent des comportements individuels de chaque collaborateur. Contrairement aux systèmes d information, les systèmes sociaux sont, par nature, non prédictifs. Vouloir agir sur ce résultat nécessite une intervention sur les comportements individuels en leur donnant une direction déterminée. La méthodologie SqEME tente de dépasser les limites de la théorie de l organisation scientifique du travail avec le Taylorisme en proposant une approche globale fondée sur les processus métiers et la collaboration des individus. L évolution a demandé aux organisations plus de flexibilité et de créativité tout en augmentant les besoins de supervision et de contrôle. SqEME apporte une vision globale de l organisation en tentant de répondre aux questions suivantes : Quels sont les composants essentiels de l entreprise? Quels sont les liens existants entre les individus? Quelle est l organisation du travail mise en oeuvre? Comment les affaires sont-elles réalisées? 111

112 La méthodologie SqEME repose sur quatre principes idéologiques fondamentaux affinés au cours du temps : La gestion orientée «résultat» dans le contexte de la pensée inclusive et des systèmes ouverts. La pensée inclusive est la conscience qu un résultat n est obtenu que par la coopération de l ensemble des collaborateurs reléguant leurs ego à la seconde place devant les objectifs à atteindre. Les processus métiers sont formés des interactions entre les collaborateurs. L échange d information comme moyen de motivation d une organisation horizontale ou transversale. Les processus métiers fonctionnent sur base de la communication des informations. L organisation est perçue comme un système de traitement de l information. Son bon fonctionnement dépend de la qualité des informations échangées. L organisation horizontale ou transversale a levé les barrières entre ses organisations afin de faciliter cette communication. Les composants et modèles comme éléments de structuration des processus. La réduction de la complexité d une organisation s opère en la divisant en composants sans omettre par la suite les liens existants entre ces derniers. SqEME considère cette approche comme un moyen d identification des éléments comportementaux standards. Ces derniers justifient une intervention sur les processus métiers lorsqu ils sont combinés aux indicateurs de performance. La maturité professionnelle des collaborateurs comme point de départ. La qualité de l organisation dépend de la qualité de ses intervenants. La maturité professionnelle est un concept clé des organisations flexibles. Cette maturité est obtenue par l expérience, la capacité et les compétences de chaque individu. SqEME présuppose que les processus métiers sont exécutés par des professionnels. 112

113 La méthodologie SqEME propose l exécution des activités d identification, de modélisation, de supervision, de gestion et d amélioration des processus métiers par le biais d un schéma mental composé de quatre «fenêtres» : La fenêtre Constitution dépeint l entreprise sous l angle idéologique de sa gestion, de ses valeurs, de sa vision, de sa mission, de sa stratégie, de leur mise en œuvre. Elle cherche à éclaircir ses fondements, ses caractéristiques, sa raison d être et la perception de son image. La fenêtre Chimie dépeint ce qui donne vie à l organisation, ce qui l initie et la garde en mouvement comme l esprit de coopération, la communication entre les individus, les relations avec son environnement, et la valeur créée des interactions entre ses constituants. La fenêtre Construction décrit la réalité tangible, la manifestation des décisions dans la réalité comme la mise en œuvre des opérations, l utilisation des ressources, l affectation des tâches et la distribution des responsabilités dans l entreprise. La fenêtre Correspondance décrit le mode opératoire de l organisation par la prise de mesures et d analyses des écarts afin d en déduire des initiatives conformes aux trois autres fenêtres. La figure 4.4 illustre la représentation générale des quatre fenêtres de la méthodologie SqEME. Figure 4.4 Les quatre fenêtres SqEME Les fenêtres Constitution et Chimie décrivent les principes de l organisation alors que les fenêtres de Construction et de Correspondance décrivent les règles appliquées à l organisation. 113

114 Ces fenêtres ne sont pas directement connectées ensemble et il n existe aucune hiérarchie ni de séquences prédéterminées entre elles. Les flèches représentées sur la figure 4.4 illustrent uniquement la superposition d une fenêtre sur l autre. La méthodologie SqEME introduit dans son modèle de la subjectivité en offrant une perception de la réalité différente pour chaque utilisateur. La superposition des fenêtres conduit à la création de nouvelles perceptions de la réalité sur l organisation. La figure 4.5 illustre la symbolique de représentation de ces quatre fenêtres. Figure 4.5 Le symbole commun des quatre fenêtres SqEME Chaque fenêtre pose ses questions et détermine ses points d attention. Les réponses aux questions d une fenêtre sont obtenues en considérant les réponses données aux fenêtres précédentes. Il est également parfois nécessaire de modifier ou de revoir les réponses des fenêtres précédentes selon les nouvelles réponses. Dès lors, une réalité plus nette apparaît à chaque nouvelle itération de ce processus. Par exemple, si la réalité recherchée correspond à celle de l organisation, la fenêtre Constitution répond à la question «Quelle est la stratégie choisie?», la fenêtre Chimie répond à la question «Comment est organisée la communication entre les collaborateurs?», la fenêtre de Correspondance répond à la question «Quel est le système de supervision?» et enfin la fenêtre Construction répond à la question «Comment est structurée l organisation?». La méthodologie SqEME et ses quatre fenêtres s appliquent à déterminer différentes réalités de l organisation. Les processus métiers et l organisation étant indissociables, ce qui est envisageable pour l un, l est tout autant pour l autre. La méthodologie SqEME s adapte à la gestion des processus métiers en adaptant les questions et points d attention de chaque fenêtre. 114

115 4.1.2 La gestion des processus métiers avec SqEME La méthodologie SqEME considère la gestion des processus métiers comme un moyen de conception ou d adaptation d une organisation afin qu elle puisse répondre aux besoins et aux objectifs fixés. La gestion des processus métiers étant l affaire de tous, elle prescrit l implication de l ensemble des participants de l organisation dans la démarche en évitant un confinement au niveau supérieur de la hiérarchie. La collaboration entre les individus est rendue plus aisée en facilitant la communication. Cette affirmation constitue le fondement d une démarche d amélioration continue dans l entreprise. Les professionnels sont au centre de l organisation. En adoptant une perspective de gestion des processus métiers, le contenu des quatre fenêtres de la méthodologie SqEME est adapté en conséquence : La fenêtre Constitution est un aperçu de l organisation et de ses caractéristiques essentielles. Elle décrit la vision, la mission, les objectifs de l entreprise et leurs transpositions dans les zones de résultats clés. Cette fenêtre décrit également la structure organisationnelle avec ses composants, leurs interactions et leurs résultats intermédiaires. La méthodologie SqEME insiste sur la communication de ce type d information aux collaborateurs de l entreprise. L exécution correcte de la stratégie dépend de sa compréhension. La fenêtre Chimie décrit la collaboration et les échanges d information entre les intervenants. Ces échanges participent au bon fonctionnement de la mise en œuvre des processus métiers. Cette fenêtre détermine les significations communes à l ensemble de l organisation des données échangées nécessaires à l accomplissement de certaines tâches. La fenêtre Construction décrit l affectation des tâches et des responsabilités aux divers intervenants des processus métiers. Elle décrit également les modalités de définition et de mise en œuvre des ressources nécessaires à l accomplissement de certaines tâches. La fenêtre Construction dépeint la mise en œuvre des processus métiers dans leur environnement de production. La fenêtre Correspondance décrit les moyens de supervision et de contrôle des processus métiers comme les tableaux de bord. Cette fenêtre détaille également les activités des processus métiers. 115

116 La méthodologie SqEME appliquée à la gestion des processus métiers distingue huit modèles répartis sur les quatre fenêtres comme l illustre la figure 4.6. Figure 4.6 Le symbole commun des quatre fenêtres SqEME 116

117 La table 4.1 décrit sommairement le contenu de chaque fenêtre de la méthodologie SqEME appliquée à la gestion des processus métiers. Table 4.1 Description sommaire des éléments des quatre fenêtres Fenêtre Modèle Description Constitution Chimie Construction Correspondance Architecture d entreprise Zones de résultats clés Messages Préconditions Collaborateurs Ressources Performances Processus Modélisation de la structure de l entreprise et de ses composants essentiels supportant les zones de résultats clés. Diagrammes d interactions représentant les activités et leurs interactions. Une zone de résultat clé est représentée par une surface illustrant les dépendances entre les processus métiers clés de l entreprise. Spécifications des informations échangées entre les intervenants conduisant à la détermination formelle des éléments de collaboration. Spécifications des règles et contraintes règlementaires nécessaires au fonctionnement de l organisation et de ses processus métiers. Matrice comportant l affectation des rôles, responsabilités et autorités aux différents intervenants des processus métiers. Matrice comportant les ressources nécessaires à l accomplissement des tâches, leur disponibilité et leur affectation aux divers intervenants. Instruments de mesures sous forme tableaux de bord et indicateurs de performance permettant de superviser l exécution des processus métiers suivant les objectifs fixés. Diagrammes détaillés des séquences d activités des processus métiers et complétés de l affectation des rôles. 117

118 4.1.3 L utilisation des fenêtres de la méthodologie SqEME Pour rappel, la méthodologie SqEME ne définit pas de cycles ou de séquences d activités particulières entre ses quatre fenêtres. Elle prescrit uniquement un équilibre et une consistance entre leurs éléments. Cette absence de spécification laisse une grande flexibilité d utilisation dans son adaptation aux besoins divers de gestion des processus métiers. L utilisateur choisit le cheminement qu il souhaite selon son point de vue et les informations communiquées aux parties prenantes. J. van Oosten, dans son ouvrage «Process Management Based on SqEME» décrit neuf cas de mise en œuvre de la méthodologie SqEME comme la reconfiguration des processus et l ajustement de la structure organisationnelle. La reconfiguration des processus métiers La reconfiguration des processus métiers ou «Business Process Reengineering» en anglais, est une démarche de gestion des processus métiers consistant à «refondre» complètement l organisation. En général, cette méthode est appliquée lorsque les objectifs fixés ne peuvent être atteints avec les processus courants de l organisation. L approche préconise de «redéfinir» de nouveaux processus métiers sans tenir compte des processus existants. Les ressources et les actions nécessaires sont ensuite évaluées afin de répondre aux besoins sur les nouveaux processus métiers. Lors de l exécution des processus métiers, des mesures sont prises afin de confirmer les choix et l alignement des processus métiers sur les objectifs fixés. 118

119 La figure 4.7 illustre le cheminement entre les quatre fenêtres correspondant à l approche de reconfiguration des processus métiers. Figure 4.7 Le cheminement de reconfiguration des processus métiers Le cheminement de la démarche de la reconfiguration des processus métiers est décrit en huit étapes : 1. Définition et description de la vision, de la mission et des objectifs de l entreprise. Il est également nécessaire d établir les grandes étapes de la stratégie permettant d atteindre ces objectifs. 2. Identification des processus métiers essentiels à la réalisation des objectifs et conformes à la stratégie. 3. Identification des relations entre les processus métiers essentiels. Cette étape permet également de vérifier et valider la cohérence de l architecture d entreprise. 4. Identification et spécification des informations échangées entre les processus métiers essentiels. 5. Identification des règles métiers et de conformité contraignant l exécution des processus métiers. Cette identification s effectue de pair avec le point précédent en adaptant les informations échangées entre les processus si nécessaire. 6. Affectation des rôles et responsabilités aux activités en identifiant les actions éventuelles de mise à niveaux des professionnels en charge de l exécution des nouveaux processus métiers. 119

120 7. Définition et affectation des ressources matérielles nécessaires à la bonne exécution des activités. 8. Supervision de l exécution des processus métiers. Les actions d amélioration se basent sur les écarts entre les objectifs fixés et les valeurs mesurées. L ajustement de la structure organisationnelle Les acquisitions ou scissions d entreprises provoquent généralement un besoin d ajustement de la structure organisationnelle en rééquilibrant leurs processus métiers et les nouveaux objectifs tout en considérant les impacts sur les activités existantes de l entreprise. La figure 4.8 illustre les étapes de cheminement de l ajustement de la structure organisationnelle. Figure 4.8 Le cheminement d ajustement de l organisation Le cheminement de l ajustement de la structure organisationnelle est décrit en six étapes : 1. Identification des impacts sur l affectation des rôles et responsabilités. Cette étape permet également d identifier les besoins concernant les professionnels en charge de l exécution des processus métiers. 2. Identification et évaluation des impacts sur les processus essentiels. 120

121 3. Identification et analyse d impacts sur les échanges d informations entre les processus métiers. 4. Identification et évaluation des impacts sur l affectation des professionnels et des moyens matériels employés. Il est également nécessaire de prévoir les actions à entreprendre afin de réaligner la structure. Cette étape dépeint l exécution effective de la transition d une structure organisationnelle à l autre. 5. Identification des changements survenus nécessitant une adaptation de la description détaillée des processus métiers. 6. Évaluation des résultats suite à la transition en réalisant les mesures adéquates. L organisation orientée service L organisation orientée service ou «Service Oriented Organisation» en anglais, établit son mode de fonctionnement sur base d une relation Client-Fournisseur entre départements, branches, filiales, etc. Les niveaux de services attendus des bénéficiaires sont négociés en fonction de la qualité et du coût. D un point de vue organisationnel, un service correspond à l interface du processus sous-jacent. Le service considère uniquement les entrées et sorties du processus. La mesure est réalisée sur la performance du processus à produire le résultat attendu. La figure 4.9 illustre le cheminement des fenêtres de la méthodologie SqEME de définition d un service. Figure 4.9 Le cheminement de définition d un service 121

122 Le cheminement de définition d un service est décrit en quatre étapes : 1. Identification du propriétaire du Service. Comme les processus, le service requiert l identification d un rôle se portant garant de la prestation de service et des niveaux à atteindre. Les moyens de mesures sont également évalués. 2. Définition des services sur base des messages échangés entre les processus métiers et des règles ou contraintes liées à la prestation du service. Cette étape définit également les indicateurs clés de performance du service. Les valeurs ciblées sont évaluées en tenant compte du fonctionnement interne des processus et des besoins du client. Le contrat de niveaux de service représente l engagement du Fournisseur envers son Client et comporte les niveaux de services attendus ainsi que les annexes supportant la prestation des services. 3. Évaluation de la capacité des processus interne à atteindre les niveaux de service attendus. 4. Évaluation des écarts entre les niveaux de services mesurés et les valeurs prévues figurant dans le contrat de niveau de service. En cas de rupture, les actions correctives sont exécutées. 122

123 4.1.4 L architecture d entreprise avec SqEME Dans l ouvrage «Process Management Based on SqEME», l auteur décrit un modèle de référence d architecture d entreprise décomposé en quatre perspectives : La perspective de direction regroupe les processus de détermination des objectifs et de gestion de l entreprise. La perspective de préparation structure les processus de préparation à l exécution des tâches des activités primaires de l entreprise. La perspective d exécution regroupe les processus d exécution des tâches. La perspective d amélioration comporte les processus de supervision et d amélioration des activités de l entreprise. La figure 4.10 illustre la représentation des quatre perspectives d architecture d entreprise de l approche SqEME. Figure 4.10 L architecture d entreprise selon SqEME 123

124 Comme les autres modèles d architecture d entreprise présentés en début de ce chapitre : la chaîne de valeur de M. Porter, le modèle de la norme ISO15504 et le modèle en Y d IDS-Scheer, le modèle d architecture d entreprise de l approche SqEME propose uniquement une structuration générique des processus métiers de l organisation, c est-à-dire uniquement la partie dynamique de l entreprise. Le cadre de référence proposé dans cet ouvrage intègre également la perspective statique de l entreprise en se basant sur le cadre de référence Zachman. 124

125 4.2 Le cadre de référence Zachman Les principes du cadre de référence Zachman Le cadre de référence Zachman, du nom de son inventeur John A. Zachman, est apparu dans les années 1980 en réponse à l évolution et à la diversification des technologies intégrées aux systèmes d information des entreprises. Deux phénomènes sont à l origine de la prise de conscience de la nécessité d inclure l architecture des systèmes d information dans la stratégie de l entreprise : Le recours croissant et systématique des systèmes d information dans tous les métiers ayant comme conséquence l élargissement des besoins fonctionnels de ces systèmes à l intérieur, comme à l extérieur, de l organisation. La complexité croissante des systèmes d information basés sur des composants réutilisables, partagés et distribués. Le cadre de référence Zachman décrit et classifie les éléments de description de l architecture d entreprise depuis la stratégie jusqu à son exécution. Il permet de vérifier rapidement l alignement des rôles, des processus et des systèmes aux objectifs de l entreprise. En suivant ce modèle, tout développement d un nouveau système répond à des besoins métier alignés sur la stratégie de l entreprise. Le cadre de référence Zachman se veut neutre et indépendant de toute méthode ou technologie existante. Il peut donc s intégrer aisément dans les méthodes et techniques présentes dans les organisations. Cependant, le cadre de référence Zachman ne précise aucune méthodologie, ni formalisme spécifique de description des éléments d architecture d entreprise. Le cadre de référence Zachman représente également un excellent moyen de communication en intégrant les visions de chacun. Il comporte autant les aspects plus conceptuels de l entreprise comme sa stratégie que les aspects matériels comme la détermination des moyens de mise en œuvre et de réalisation des objectifs. L organisation d une entreprise exige l intervention de différentes disciplines et de spécialités ayant chacune un langage approprié à son métier. L organisation est une somme d interactions entre ses collaborateurs. Pour ces derniers, la perception de l entreprise est différente. Par exemple, la perception d un comptable n est pas celle d un juriste ou encore d un informaticien. 125

126 Le comptable perçoit l information de l entreprise sous forme de compte et de mouvements. L informaticien envisage l information de l entreprise sous un aspect technique de modélisation des logiciels. Le cadre de référence Zachman couvre ces différentes perceptions en les classant par niveau conceptuel ou d abstraction, du plus élevé pour la description de la stratégie et des objectifs à atteindre, jusqu au niveau le plus bas correspondant aux moyens de mise en œuvre. Chaque rôle est une perspective de l architecture d entreprise selon le modèle du cadre de référence Zachman. La description d un élément d architecture d entreprise prend différentes formes ou aspects dans le cadre de référence Zachman. La table 4.2 décrit les six perspectives et leurs rôles associés du cadre de référence Zachman. 126

127 Table 4.2 Description des rôles et des perspectives Rôle Perspective Description Planificateur Contextuel Rôle établissant le contexte et l environnement de l entreprise, son périmètre, ses constituants et son but. Propriétaire Conceptuel Rôle bénéficiaire ou utilisateur des produits ou des services de l entreprise. Cette perspective illustre la destination finale ou la raison de l élaboration des produits et services de l entreprise. Les éléments d architecture rassemblés en modèle métiers constituent la vue conceptuelle des produits et services. Concepteur Logique Rôle intermédiaire entre les produits et services conceptualisés représentant les attentes d utilisation des bénéficiaires et les possibilités techniques avec leurs limites physiques. Cette perspective rassemble les éléments d architecture formant un modèle système. Constructeur Physique Rôle déterminant la supervision, la réalisation et l utilisation du produit en tenant compte des limites et contraintes physiques. Cette perspective rassemble les éléments d architecture formant un modèle technique. Sous contractants Hors Contexte Rôle décrivant le détail des différents composants du système ou des constituants du produit à réaliser. Il est également responsable de la construction et de l assemblage des parties du produit ou service final. Les éléments d architecture constituent une représentation détaillée du produit final. La réalité Fonctionnement de l entreprise La réalité décrit la manifestation physique, tangible, du produit ou du service dans sa réalité avec toute sa complexité et ses contraintes. Les perspectives du cadre de référence Zachman illustrent le cycle de vie du produit ou du service, depuis sa conception en tenant en compte des attentes des bénéficiaires, jusqu à leur mise en œuvre dans la réalité de l entreprise. 127

128 La description d un produit ou d un service se décline également sur plusieurs aspects, depuis sa définition jusqu à la justification de son existence. Le cadre de référence Zachman décrit les produits et services de l entreprise sur six aspects figurant dans la table 4.3. Une question est associée à chaque aspect. Elle a pour objectif de mener la réflexion sur la réponse en termes d élément d architecture à produire. Table 4.3 Description des aspects Aspect Question Description Donnée Quoi? Cet aspect décrit la structure et la composition des composants du système. Fonction Comment? Cet aspect décrit les spécifications, modes de transformations, traitements et modes de production des composants du système. Réseau Où? Cet aspect décrit la localisation et la logistique des moyens de production intervenant dans le cycle de vie du produit ou du service. Collaborateur Qui? Cet aspect décrit les responsabilités des individus intervenant dans le cycle de vie du service ou du produit sous la forme de flux, d instructions, de procédures ou d organigrammes. Durée Quand? Cet aspect décrit les contraintes temporelles comme les cycles, les événements, les calendriers, les contraintes, etc. Motivation Pourquoi? Cet aspect décrit la justification de l élaboration du service ou produit comme les stratégies, les résultats attendus, les moyens nécessaires, etc. 128

129 En combinant les perspectives et les aspects de l architecture d entreprise, on obtient une matrice composée de trente-six cellules. Chaque cellule comporte un élément d architecture défini comme une primitive du modèle. Pour rappel, un élément d architecture désigne un modèle, un diagramme, une feuille de calcul, un tableau de bord, un document, ou tout autre élément descriptif de l entreprise. La connaissance de chaque primitive est relative à la compréhension du fonctionnement de l entreprise. En général, ce que l on crée, on peut le comprendre. En ce sens, le cadre de référence Zachman constitue une base de connaissance dont l objectif est d être compréhensible, flexible, intégrée et alignée sur les objectifs de l entreprise. Les tables 4.4 et 4.5 décrivent la matrice du cadre de référence Zachman composée de ses trente-six primitives. 129

130 Table 4.4 Le cadre de référence Zachman (partie1) Liste des éléments nécessaires à la conduite des affaires. Modèle conceptuel de données, d entité relation, etc. Liste des processus métiers de l entreprise Modèle métier Liste des lieux d exécution des activités de l entreprise Modèle logistique Modèle de données logiques Modèle de données physiques Architecture fonctionnelle des systèmes Modélisation de systèmes d information Architecture des systèmes d information distribués Architecture technologique Définition des données Programmes Architecture réseau Données métier réelles Code du programme Réseau physique 130

131 Table 4.5 Le cadre de référence Zachman (partie 2) Liste des individus et des organisations Liste des événements significatifs Liste des objectifs stratégiques Modèle hiérarchique Modèle temporel Modèles d objectifs Interactions entre individus Structure de traitement Modèle de règle métier Matrice organisation/processus Structure de contrôle Modélisation des règles Architecture de sécurité Établissement du calendrier Spécification des règles Organisation métier réelle Planification Stratégie réelle 131

132 La matrice complétée constitue un ensemble d hypothèses, de concepts, de valeurs, et de descriptions de pratiques correspondant à une certaine manière de percevoir la réalité de l entreprise. Le cadre de référence Zachman ne spécifie ni le résultat, ni la façon de remplir la matrice. Ce cadre se veut logique et non technique, c est-à-dire qu il n est pas nécessairement préconisé de donner une issue technologique ou de représentation aux différents intervenants. La cohérence du modèle repose sur certaines règles : Chaque colonne comporte un modèle générique simple et chaque cellule spécialise ce modèle. La conception des primitives du modèle débute en se basant sur son modèle générique. On l ajuste ensuite en accord avec les contraintes sémantiques de la ligne. Chaque cellule est unique. Il n existe pas de relations diagonales entre les cellules. Les intervenants des différentes perspectives utilisent souvent les termes similaires pour exprimer des concepts différents. La création de relations diagonales entre les cellules provoque une discorde sémantique en créant le risque d une mauvaise interprétation des informations de la matrice. Le cadre de référence Zachman est générique. Il classifie autant les artefacts correspondant à des concepts abstraits que concrets. La méthodologie de l entreprise complète l utilisation du cadre de référence Zachman en proposant la gestion du contenu et du niveau de détail des éléments d architecture. Celle-ci veillera également à inclure la définition, le stockage, la gestion du changement et les assemblages de différentes primitives de la matrice. 132

133 4.2.2 L utilisation du cadre de référence Zachman Le cadre de référence Zachman ne préconise aucune forme de notation particulière de description des primitives de la matrice. Le langage UML et ses diagrammes offrent l avantage de pouvoir être utilisés dans la plupart des perspectives et aspects de la matrice. Il est toutefois nécessaire d y introduire également d autres éléments comme du texte, des feuilles de calculs ou des graphiques. Plusieurs critères déterminent le choix de l une ou l autre forme de représentation : Le niveau conceptuel. Le niveau de connaissance. La signification donnée aux éléments graphiques. Le niveau de communication. Les interlocuteurs. Dans le cadre de cet ouvrage, seules les quatre premières perspectives sont détaillées par des modèles composés de diagrammes UML. Les tables 4.6 et 4.7 proposent la répartition des diagrammes UML à chaque primitive du cadre de référence Zachman. 133

134 Table 4.6 Les Diagrammes UML et le cadre de référence Zachman (1) Package Classe Cas d utilisation Cas d utilisation Activité Composant Interaction Objet Classe Structure composite Cas d utilisation Activité État/transition Séquence Communication Collaboration Classe Package Composant Classe Package Composants Cas d utilisation Activité État/transition Séquence Communication Cas d utilisation Activité État/transition Séquence Communication Déploiement Composant Déploiment Composant 134

135 Table 4.7 Les Diagrammes UML et le cadre de référence Zachman (2) Classe Activité Activité Synchronisation Activité Cas d utilisation Cas d utilisation Activité Classe Cas d utilisation Séquence Interactions Séquence Communication État/transition Séquence Classe Interactions État/transition Package Classe Séquence Communication 135