architecture des systèmes d’informationliberti/cal07/presentations/printz-cal07.pdf ·...
TRANSCRIPT
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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
Contenu informationnel – Complexités – Modèles de coût
CALIX, les 3-4 Octobre 2007Jacques Printz, Professeur au CNAM, Chaire de génie
logiciel
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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èmeNotion de CCI : complexités, complications et incertitudes
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 3
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)
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 4
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é
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 6
Exemple N°1 : les ports du SI
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 7
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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 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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 9
Exemple N°2 : Les chemin de données fondamentaux du SI – Flux
informationnels
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 10
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 11
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 12
Système en mode Action (SMA)Classe 1 : Manuel
Système S1de 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.
Horloge du système
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 13
Système en mode Action (SMA)Classe 2 : [semi] Automatique
Système S1de UA1 EME
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 14
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 15
Exemple N°3 : Langage interne et langages externes – Intégrité de
l’information
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 16
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 18
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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
ACID
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 21
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 22
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 24
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 25
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 26
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 ?
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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
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, …
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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é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)
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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 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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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
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 ?
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 31
Exemple N°1 : Prise en compte de l’intégration dans l’équation d’effort
COCOMO
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 32
É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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 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é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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 34
Exemple N°2 : complexité via le modèle d’estimation des coûts logiciel
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût Version V0 – Page 35
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