Architecture des systèmes d’information

(1)

C E N T R E D E M A I T R I S E D E S S Y S T E M E S E T D U L O G I C I E L

Architecture des systèmes d’information

a a a

Contenu informationnel – Complexités – Modèles de coût

CALIX, les 3-4 Octobre 2007

Jacques Printz, Professeur au CNAM, Chaire de génie

logiciel

(2)

Plan de l’exposé

ª Liminaire : Machines abstraites et principes d’ingénierie de l’information

Ô Déterminisme des opérations programmées – Réversibilité et reconstruction de l’histoire des transformations

ª 1ère partie : Principes de décomposition fonctionnelle revisités

Ô Blocs fonctionnels – Traducteur/Transducteur

Ô « Orchestration et chorégraphie » – Surveillance, régulation et contrôles des enchaînements

ª 2ème partie : Complexités textuelles, architecture et modèle de coût

Ô Essai de définition d’une « mesure naturelle » du contenu informationnel d’un système

Ô Notion de CCI : complexités, complications et incertitudes

(3)

Ports Ports

Un modèle de simplicité pour l’ingénieur informaticien :

La machine logique de von Neumann

Organe de contrôle (le pilote général de la machine + surveillance + « drivers » des ports )

Mémoire Périphérique pour

entrer l’information dans la mémoire

(n1 ports en entrée)

Périphérique pour extraire l’information

de la mémoire (n2 ports en sortie)

D1 D2

D4

D3 Programme enregistré, avec

ses données et ses instructions Unité logique (organe de

calcul avec les fonctions primaires de la machine)

Données du programme enregistré

Le contenu est conventionnel

• Cf. débat CICS-RISC selon les technologies d’intégration VLSI

Entrées Sorties

Espace d’adressage de la machine (N programmes en

concurrence)

(4)

Qq. Concepts vraiment fondamentaux

ª Opérations indivisibles (atomiques) sur la mémoire

ª Espace d’adressage des processus et de la machine – Chemins d’adressage (data path) ª Redondances utiles et surveillance pour

l’intégrité des opérations et des états de la machine

ª Distinction langage interne – langage(s) externe(s) ; compilation et interprétation ª Processus séquentiels (cf. E.Dijkstra)

ª Processus concurrents et synchronisation des processus (cf. les sémaphores)

ª Intégrabilité

(5)

1ère Partie :

Principes de décomposition

fonctionnelle des systèmes en vue d’identifier la « machine » sous-jacente

Le SI vu comme une machine

de traduction

(6)

Exemple N°1 : les ports du SI

(7)

Processus informatique

Traitements automatisés

Déterminisme

Contraintes ergonomiques

•Pragmatique

•Sémantique Bon sens

Règles de typage

•Syntaxe du type

• Sémantique du type (règles d’interprétation) Règles d’intégrité

Cohérence des processus et des actions

Cohérence informatique

•Intégrité du modèle de données

•Caractéristiques non fonctionnelles (FURPSE)

•Architecture logicielle

Cohérence de l’information

Processus métier

Flux Flux

Cohérence globale du SI

DONNÉES DONNÉES

Sphère de contrôle du langage naturel Sphère de contrôle des langages informatiques

La machinerie informationnelle : complexité de l’information

Monde M1

Monde M2

(8)

Écrans Commandes Système IHM - GUI

La frontière des mondes M1 et M2 IHM/GUI et Capteurs-Actionneurs

Opérateurs humains

Capteurs Actionneurs Automatisation de tout ou partie des processus, tâches

et services métiers

Processus et tâches dans la réalité concrète – Équipements à piloter – Équipements simulés

– Autres systèmes, interopérabilité Interfaces d’échanges informatiques

Langage(s) de commandes selon le profil de l’opérateur :

•C Create

•R Retrieve

•U Update

•D Delete

•E Execute

Référentiel système des entités informatiques que l’opérateur peut utiliser grâce aux commandes qui lui sont accessibles

Langages internes Autres informations et connaissances à disposition des

opérateurs hors de la sphère de contrôle du système informatisé

Poste de travail

Système réactif pour équipements virtuels Interfaces d’échanges informatiques

Langage(s) de commandes de l’équipement, selon le type de l’équipement :

• Le référentiel système ne connaît que l’interface virtuelle, ce qui facilite les adaptations

•Interopérabilité

Ports externes

Temps humain

Temps machines et équipements

Caractéristiques des « orchestrations »

Temps contraint

(9)

Exemple N°2 : Les chemin de données fondamentaux du SI – Flux

informationnels

(10)

Système en mode réception (SMR)

Système S1 de UA1

EMR

EV

ER

Messages Reçus

Espace de réception des Messages Reçus

EMR

Espace de visualisation EV (Modèle de Données Utilisateur)

Espace de référence ER du système

(Modèle de Données Internes) Opérateur

Ensemble connu de types : {MR1, MR2, … , MRn}

C1 C2 C3

C4

Ô Le système reçoit de l’information via des messages de toute nature : messages formels avec typage des données,

messages textuels formels (via des schémas XML) ou semi formel (de niveau courrier électronique) ; il met à jour ses bases de données et présente l’information à l’opérateurpour validation et/ou enrichissement sémantique via les chemins C1, C2, C3, C4.

Ô Le système se comporte comme un puit d’information

Sources/capteurs d’information

Horloge du système

(11)

Système en mode émission (SME)

Système S1

de UA1 ^EME

EV

ER

Messages Émis

Espace de travail des Messages émis EME Opérateur

Ensemble connu de type : {ME1, ME2, … , MEm}

C5 C6 C3

C4

Ô Le système émet de l’information via des messages de toute nature ; il propage l’information qu’il contrôle vers ses correspondants destinataires via les chemins C3, C4, C5, C6 ; la qualité et la traçabilité des données propagées est primordiale pour l’intégrité de l’ensemble des systèmes intégrés. En cas d’action erronée il est primordial de pouvoir reconstituer l’histoire des transformations opérées.

Ô Le système se comporte comme une source d’information

Ventilation des messages vers les acteurs / actionneurs clients Horloge du système

(12)

Système en mode Action (SMA)

Classe 1 : Manuel

Système S1

de UA1 ^EME

EV

ER

Opérateur

Ensemble connu de types : {ME1, ME2, … , MEm}

EMR

Ensemble connu de types : {MR1, MR2, … , MRn}

C1

C2

C3 C4

C5

C6

Ô Le système reçoit et émet simultanément de l’information via des messages de toute nature ; il propage l’information qu’il contrôle vers ses correspondants destinataires ; le temps de latence réception→émission est court ; le risque de défaut d’intégrité est beaucoup important. La qualité globale {données traitements contrôles} est primordiale.

Ô Le système se comporte comme un transducteur; les messages reçus et émis constituent des langages formels (automatisme pur) ou semi-formel (si intervention de l’opérateur) ; tous les chemins peuvent être activés.

(13)

Système en mode Action (SMA)

Classe 2 : [semi] Automatique

Système S1

de UA1 ^EME

EV

ER

Opérateur superviseur

Ensemble connu de types : {ME1, ME2, … , MEm}

Ensemble connu de types : EMR

{MR1, MR2, … , MRn}

C1

C2

C3 C4

C5

C6

Opérateur programmé Cet opérateur programmé peut

être un Workflow paramétré résultant des activités à effectuer

dans le métier Notification des opérations

effectuées par le système

Ô Le système n’est plus directement sous contrôle de l’opérateur humain qui devient passif ; la décision est déléguée à un opérateur programmé paramétrable (selon niveau d’alerte qui détermine le risque).

Ô Tout est journalisé pour analyse après action et rejeu (préparation de scénarios pour les simulateurs d’entraînement).

(14)

Intégration des machines logiques de transformation-traduction

MR1

MT_sv

Surveillance

ME1 ER1

MT1 MT2 MTn MR2 ME2

ER2 . . .

Mécanisme d’intégration des machines logiques (Bus informationnel)

Une ou plusieurs machines transductrices effectuant les transformations et/ou les services demandés

MT_oc

Orchestration et Contrôle

ENTRÉE Sphère de contrôle du système SORTIE

(15)

Exemple N°3 : Langage interne et langages externes – Intégrité de

l’information

(16)

Le modèle du traducteur PTE

Présentation – Transformation - Édition

Entrée graphique Entrée textuelle Entrée autre …

Vérification et Validation des entrées

Présentation

Adaptation E→I

Format externe

Format interne

Édition

Édition graphique Édition textuelle Édition autre … Format interne

Format externe

Vérification et Validation des éditions

Langage de l’acteur émetteur

Langage de l’acteur récepteur

FE_EMTR

FI_EMTR

FI_RCPR

Adaptation I→R

Plusieurs couches selon complexité Adaptateur de format

Cœur de la transformation PTE

Adaptateur de format Transformation

EMTR→RCPR

Interface publique Interface privée

(17)

Exemple N°4 : les opérations atomiques sur les données – Notions d’intégrat

(« building block ») et de transaction

Granularité de niveau pièce

élémentaire d’un système (Intégrat de rang 0) – Le pas de

fabrication/construction du système

(18)

Modèle transactionnel : Gérer la cohérences des mondes M1 et M2

Client Fournisseur

Banque Monde réel M1 Argent réel du client

(chèque – CB – DAB)

Stock réel du fournisseur en magasin

Système d’information

BD client BD Banque BD fournisseur

Monde informatisé M2 (monde virtuel) Maintien de la cohérence M1 – M2

Le monde M2 est par construction réversible

Le monde M1 est généralement irréversible – Toute

transformation à un coût (entropie) → Notion de compensation

(19)

Pattern d’instruction généralisée : la transaction

DE1

TR_I

DE2

• • •

DEn

DR1 DR2 DRm

n entités mémoire en entrée

m entités mémoire en résultat

Historique

{ Invariant TR_I } garantissant la cohérence de TR_I

• • •

État en entrée de la transformation

État résultat de la transformation

Transaction TP_I

A C

D I

(20)

Règle de modularité 1 entrée – 1 sortie

Entrée

Sortie . . .

Blocs de code constitutifs

Suite des opérations

×

Le contexte de la défaillance est perdu. Le contrat de sortie

n’a pas été vérifié.

Bloc non conforme aux règles de modularité

×

Le contrat d’entrée dans l’intégrat n’a pas été vérifié.

Chemin d’entrée C1

Chemin de sortie C2

B1 B2 Bn

Vérification du

« contrat » en entrée

Vérification du

« contrat » en sortie NON

NON Opérations

antérieures

(21)

Modèle de composant intégrable

Contexte et données partagées

Pool de ressources partagées entre plusieurs intégrats

Données partagées Données partagées

Données partagées

Nomenclature, caractéristiques, niveau de partage, comportement, etc.

Données référencées par ITG (modalités CRUD)

Intégrat ITG

Version.Révision (+ ressource propres)

Données privées ITG Statiques/Dynamiques

entrée

Sortie nominale Sortie non

nominale

Niveau Composant applicatif Niveau Système/S-Système Niveau SDS

Sphère de contrôle de l’intégrat

Allocation / Restitution explicites

Ressources consommées, niveau de charge

Latence

Quantité d’information traitée

Contexte de l’intégrat

/////

Il est impératif de distinguer soigneusement les données :

•Persistantes

• NON persistantes (équivalentes à des phénomènes transitoires)

Comportement de l’intégrat

(22)

Vision architecturale : Identification des fonctions

M

^Moniteur

d’enchaînement

RG

ME MS

Mémoire de stockage des messages entrants

Mémoire de stockage des messages sortants

Mémoire de stockage des RÈGLES DE GESTION et de la programmation des enchaînements

Canal de lecture [1:n1] ports d’entrée

Canal d’écriture [1:n2] ports de sortie

Mémoire persistante / non persistante

Autres ressources Fonction F1 Fonction F2 Fonction F3

Fonction Fn

. . .

Allouées / Non allouées

F_GPE F_GPS

F_Ressources

R

T

(23)

Validation de la cohérence des messages reçus

Réception d’un message connu dans l’espace des messages reçus (EMR)

Analyse lexico-syntaxique du message

Analyse sémantique du message – Syntaxe abstraite

Retour aux procédures métier pour la suite des opérations à effectuer dans S

Défaillance

Conversions éventuelles dans la structure spécifique du système S

Mises à jour éventuelles / chargement des espaces EV et ER

Règles lexico-syntaxiques

Règles sémantiques Règles de conversions

Aides à l’usager

Aides à l’usager Log

Messages non reconnus

Référentiel

Messages incohérents

(24)

2ème Partie :

Complexités textuelles, architecture et modèle de coût

Essai de définition d’une

« mesure naturelle » du

contenu informationnel d’un

système du point de vue projet

(25)

Trois textes indispensables, présents dans tous les projets

ª Le référentiel projet

Ô C’est un méta-texte , explicite ou implicite, qui fixe les règles que les programmeurs devront impérativement respecter pour éviter l’anarchie et le chaos des initiatives individuelles

9 En particulier les interfaces, qui font l’objet de négociations entre les acteurs au sein d’une équipe et entre les équipes

ª La programmation

Ô Description statique de ce que l’ordinateur est censé faire (i.e. ce qui va réellement s’exécuter dans l’ordinateur)

9 Taille du programme en nombre d’instructions + Nomenclatures X-ref

ª Les tests

Ô Description dynamique de toutes et rien que les combinaisons autorisées qui permettent de vérifier et de valider ce qui a été programmé, compte tenu des exigences système (FURPSE + PESTEL)

9 Historiques, traces et lignes de vie du système

(26)

Notion de CCI

ª La notion intuitive [informelle] de complexité dans les projets agrège

différents aspects [i.e. une intrication] :

• Complexité intrinsèque

9 Du système (sémantique, sémiologie, … via une machine abstraite) 9 De l’organisation du projet de réalisation

• Complexité Complication

9 Notations utilisées pour programmer (syntaxe, symboles graphiques, …) 9 Technologies sous-jacentes, machines réelles

9 Procédures de décisions de l’organisation

• Complexité Incertitude – Risque

9 Performance et fiabilité des équipements

9 Performance et fiabilité des acteurs (maturité des acteurs et de l’organisation ; connaissances requises)

9 Risques

Peut-on les séparer et isoler un noyau dur

de complexité intrinsèque ?

(27)

Peut-on, et comment, « mesurer » la complexité

ª Constat : Il n’y a pas de mesure absolue de la complexité

Ô C’est une notion relative qui dépend du niveau d’organisation que l’on observe, et de l’acteur qui observe

9 Le meilleur exemple est l’ordinateur lui-même, depuis le transistor jusqu’à …

ª Quel sens donner à l’expression : « plus complexe » ?

Ô Plus grande taille du code, en nombre d’instructions

Ô Plus grande taille des tests, mesurée via un niveau de couverture Ô Plus coûteux, plus long à réaliser, à intégrer, à modifier, …

Ô Densité des différentes matrices de couplages utilisées en intégration

Ô Plus grand graphe, plus grand nombre cyclomatique, …

(28)

Processus d’intégration

ª En entrée :

• Interfaces et contextes + contraintes ( FURPSE ) des intégrats

• Ressources nécessaires et comportements attendus

• Paramètres d’instrumentation

• Cas d’emploi et chaînes fonctionnelles métiers

ª En sortie :

• Tests d’intégration et environnements d’exécution + bouchons éventuels

• Nombre de défauts détectés/corrigés + courbe de maturité

(disponibilité mesurée)

(29)

Arbres et paliers d’intégration – niveau application

Application générique de

niveau 3

Modules de

niveau 2 Modules de

niveau 2

Modules de niveau 1

Intégrats de rang 0

Modules de niveau 1

Intégrats

de rang 0 Intégrats

de rang 0

. . .

. . . . . .

. . .

3 paliers d’intégration

Ce que livre les programmeurs

P1 P2 P3

Ce que livre les intégrateurs

Environnement de test

Assurance qualité de l’intégrat garanti par un niveau de test unitaire (couverture à x%, preuve, …)

Chaque intégrat nécessite un environnement de test ad hoc

Importance de la standardisation pour faciliter les opérations de rejeu des tests (non régression)

Pb potentiels avec les COTS et le logiciel libre (en particulier incertitudes des ENF) Généralement

mono organisation

Pour les TU

Vers les niveaux systèmes

(30)

Mesure combinée texte du programme + Texte des tests

Texte du programme

Texte des tests

Taille

Coût-Délai de fabrication du programme

Taille

Coût-Délai de fabrication des tests

Validation métier

(Le QUOI, POUR QUI)

Vérification technologie

(Le COMMENT)

Coût de garantie de contrat de service (SLA)

Coût complet = Programme + Tests satisfaisant les exigences

Exigences FURPSE + PESTEL

Tests unitaires pour les intégrats de rang 0

Tests d’intégration, selon structure de l’arbre d’intégration

La taille du texte correspondant est une fonction monotone croissante de la complexité de l’arbre

d’intégration

•le pb est : convexe, ou concave ?

(31)

Exemple N°1 : Prise en compte de l’intégration dans l’équation d’effort

COCOMO

(32)

Équation de l’effort COCOMO

ª Peut-on justifier la forme de l’équation ?

( ) ⁺ ^α

×

= k KLS ¹ Effort

Dépend de la puissance expressive et du « grain »

sémantique du langage de programmation + Expérience des acteurs

Dépend de la complexité de l’application et de la maturité du

processus de développement Î α est le facteur d’intégration

Facteurs de coût Facteurs d’échelle

Terme linéaire Terme NON linéaire

Facteurs d’influences

(33)

Impact du coefficient d’intégration α

1 1,2 1,4 1,6 1,8 2

2 4 6 8 10 12 14 16 18 20

Facteur d'intégration

Amplification des coûts

0,05 0,12 0,2