Architecture des systèmes d’informationliberti/cal07/presentations/printz-cal07.pdf ·...

©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 –

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

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

CALIX, les 3-4 Octobre 2007Jacques Printz, Professeur au CNAM, Chaire de génie

logiciel


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èmeNotion de CCI : complexités, complications et incertitudes


PortsPorts

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

La machine logique de von NeumannOrgane 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)

D1D2

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)


Qq. Concepts vraiment fondamentaux

Opérations indivisibles (atomiques) sur la mémoireEspace 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 machineDistinction langage interne – langage(s) externe(s) ; compilation et interprétationProcessus séquentiels (cf. E.Dijkstra)Processus concurrents et synchronisation des processus (cf. les sémaphores)Intégrabilité


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


Exemple N°1 : les ports du SI


Processus informatique

Traitements automatisés

Déterminisme

Contraintes ergonomiques• Pragmatique• SémantiqueBon 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

Cohérence de l’information

Processus métier

Flux Flux

Cohérence globale du SI

DO

NN

ÉE

S

DO

NN

ÉE

S

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


É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 commandesselon 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 accessiblesLangages 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 informatiquesLangage(s) de commandesde 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

Tem

ps

hum

ain

Tem

ps m

achi

nes

et é

quip

emen

ts

Car

acté

rist

ique

s de

s «

orch

estr

atio

ns»

Tem

ps

cont

rain

t


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

informationnels


Système en mode réception (SMR)

Système S1de UA1EMR

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érateur pour validation et/ou enrichissement sémantique via les chemins C1, C2, C3, C4.

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

Sou

rces

/cap

teur

s d’

info

rmat

ion

Horloge du système


Système en mode émission (SME)

Système S1de 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

Ven

tila

tion

des

mes

sage

s ve

rs le

s ac

teur

s / a

ctio

nneu

rs c

lient

s

Horloge du système


Système en mode Action (SMA)Classe 1 : Manuel


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.

Horloge du système


Système en mode Action (SMA)Classe 2 : [semi] Automatique


EV

ER

Opérateur superviseur

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

EMREnsemble connu de types :{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).

Horloge du système


Intégration des machines logiques de transformation-traduction

MR1

MT_svSurveillance

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_ocOrchestrationet Contrôle

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


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

l’information


Le modèle du traducteur PTEPrésentation – Transformation - Édition

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

Vérification et Validation des entréesPré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

FI_RCPR

Adaptation I→R

Plusieurs couches selon complexité

Adaptateur de format

Cœur de la transformation PTE

Adaptateur de format

TransformationEMTR→RCPR

Interface publique

Interface privée


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


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

Client Fournisseur

Banque

Monde réel M1Argent 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


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

ACID


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


Modèle de composant intégrableContexte 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.

Don

nées

réfé

renc

ées

par I

TG (m

odal

ités

CR

UD

)

Intégrat ITGVersion.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 distinguersoigneusement les données :• Persistantes• NON persistantes (équivalentes à des phénomènes transitoires)

Comportement de l’intégrat


Vision architecturale : Identification des fonctions

M Moniteur d’enchaînement

RG

ME MSMé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


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

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


2ème Partie :Complexités textuelles, architecture et

modèle de coûtEssai de définition d’une « mesure naturelle » du

contenu informationnel d’un système du point de vue projet


Trois textes indispensables, présents dans tous les projets

Le référentiel projetC’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

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

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

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

Les testsDescription 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)

Historiques, traces et lignes de vie du système


Notion de CCILa notion intuitive [informelle] de complexité dans les projets agrège différents aspects [i.e. une intrication] :• Complexité intrinsèque

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

• Complexité ComplicationNotations utilisées pour programmer (syntaxe, symboles graphiques, …)Technologies sous-jacentes, machines réellesProcédures de décisions de l’organisation

• Complexité Incertitude – Risque Performance et fiabilité des équipementsPerformance et fiabilité des acteurs (maturité des acteurs et de l’organisation ; connaissances requises)Risques

Peut-on les séparer et isoler un noyau dur de complexité intrinsèque ?


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

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’instructionsPlus grande taille des tests, mesurée via un niveau de couverturePlus coûteux, plus long à réaliser, à intégrer, à modifier, …Densité des différentes matrices de couplages utilisées en intégrationPlus grand graphe, plus grand nombre cyclomatique, …


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étiersEn 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)


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 2

Modules de niveau 1

Intégratsde rang 0

Modules de niveau 1

Intégratsde rang 0

Intégratsde rang 0

. . .

. . .. . .

. . .

3 pa

liers

d’in

tégr

atio

n

Ce que livre les programmeurs

P1

P2

P3

Ce que livre les intégrateurs

Environnement de test

Environnement de test

Environnement de testAssurance 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 hocImportance 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


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

Validationmé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

ExigencesFURPSE + 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 ?


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

COCOMO


Équation de l’effort COCOMO

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

( ) α+×= 1 KLSkEffort

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

Fact

eurs

d’

infl

uenc

es


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égrationA

mpl

ifica

tion

des

coût

s

0,050,120,2

αξ nxEFFnxnEFF

=×

×=

)()(

Tout ajout de code génère un coût d’intégration qui ne dépend quedu terme complexité

Courbes établies à partir des équations COCOMONe dépend que du nombre

de modules intégrés


Exemple N°2 : complexité via le modèle d’estimation des coûts logiciel


Relation entre la complexité, les équations COCOMO, CQFD et FURPSE

( ) α+×= 1 KLSkEffort

( ) ε±×±= 3,0HAen annéeen )04,05,0( ED

C

Q

F

D

Rendement de l’effort IVVT exprimé en termes de :

• Taux de défauts résiduels

• Disponibilité de l’application ou du système

Complexité → (Taille, Nbre de pièces, Nbre de couplages)

Via la quantité/effort de tests en intégration IVVT

UF

RPSE

Taille de l’arbre d’intégration


Pour aller plus loin …

Architecture des systèmes d’informationliberti/cal07/presentations/printz-cal07.pdf ·...

Documents

Transcript of Architecture des systèmes d’informationliberti/cal07/presentations/printz-cal07.pdf ·...