Architecture des systèmes d`information - LIX

Transcription

C E N T R E
D E
MAITRISE DES
SYSTEMES ET
D U
LOG IC IEL
Architecture des systèmes
d’information
aaa
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
©2007 /J.Printz / Architecture des SI – Contenu informationnel, complexités et modèles de coût
Version V0 – Page 1
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
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 )
Périphérique pour
entrer l’information
dans la mémoire
(n1 ports en entrée)
Unité logique (organe de
calcul avec les fonctions
primaires de la machine)
D1
Entrées
Ports
Périphérique pour
extraire l’information
de la mémoire
(n2 ports en sortie)
D2
D4
D3
Données du programme
enregistré
Le contenu est conventionnel
• Cf. débat CICS-RISC selon les
technologies d’intégration VLSI
Mémoire
Ports
Sorties
Programme enregistré, avec
ses données et ses
instructions
Espace d’adressage de la
machine (N programmes en
concurrence)
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é
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
La machinerie informationnelle :
complexité de l’information
Monde M1
Processus métier
Flux
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
Processus
informatique
Traitements
automatisés
Déterminisme
Cohérence de
l’information
DONNÉES
Monde M2
Cohérence de
l’information
DONNÉES
Contraintes ergonomiques
• Pragmatique
• Sémantique
Bon sens
Flux
Cohérence globale du SI
Cohérence informatique
• Intégrité du modèle de données
• Caractéristiques non fonctionnelles (FURPSE)
• Architecture logicielle
Sphère de contrôle du langage naturel
Sphère de contrôle des langages informatiques
La frontière des mondes M1 et M2
IHM/GUI et Capteurs-Actionneurs
Opérateurs humains
Poste de
travail
Temps
contraint
Temps
humain
Temps machines
et équipements
Caractéristiques des
« orchestrations »
Autres informations et connaissances à disposition des
opérateurs hors de la sphère de contrôle du système informatisé
Ports
externes
Écrans
Commandes
Système IHM - GUI
Interfaces d’échanges informatiques
Automatisation de tout ou
partie des processus, tâches
et services métiers
Interfaces d’échanges informatiques
Système réactif pour
équipements virtuels
Capteurs
Actionneurs
Processus et tâches dans la réalité concrète –
Équipements à piloter – Équipements simulés
– Autres systèmes, interopérabilité
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
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é
Exemple N°2 : Les chemin de données
fondamentaux du SI – Flux
informationnels
Système en mode réception (SMR)
Sources/capteurs d’information
Opérateur
Messages
Reçus
Espace de visualisation EV
(Modèle de Données Utilisateur)
C3
EV
EMR
Ensemble connu de types :
{MR1, MR2, … , MRn}
Système S1
de UA1
ER
C1
Espace de réception
des Messages Reçus
EMR
C4
Espace de référence ER du
système
(Modèle de Données Internes)
C2
Horloge du système
Ô 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
Système en mode émission (SME)
C4
Messages
Émis
EV
Système S1
de UA1
ER
EME
Ensemble connu de type :
{ME1, ME2, … , MEm}
C3
C5
C6
Espace de travail des
Messages émis EME
Ventilation des messages vers les
acteurs / actionneurs clients
Opérateur
Horloge du système
Ô 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
Système en mode Action (SMA)
Classe 1 : Manuel
Opérateur
C1
C5
C3
EMR
{MR1, MR2, … , MRn}
C2
C4
EV
Système S1
de UA1
ER
EME
{ME1, ME2, … , MEm}
C6
Horloge du système
Ô 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.
Système en mode Action (SMA)
Classe 2 : [semi] Automatique
Opérateur superviseur
Cet opérateur programmé peut
être un Workflow paramétré
résultant des activités à effectuer
dans le métier
C3
Opérateur programmé
C1
{MR1, MR2, … , MRn}
C2
Notification des opérations
effectuées par le système
C5
EV
EMR
Système S1
de UA1
ER
C4
EME
{ME1, ME2, … , MEm}
C6
Horloge du 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).
Intégration des machines logiques de
transformation-traduction
ENTRÉE
MR1
ME1
ER1
Sphère de contrôle du système
MT1
MT2
...
MTn
SORTIE
MR2
Une ou plusieurs machines transductrices effectuant
les transformations et/ou les services demandés
ME2
ER2
Mécanisme d’intégration des machines logiques (Bus informationnel)
MT_sv
Surveillance
MT_oc
Orchestration
et Contrôle
Exemple N°3 : Langage interne et
langages externes – Intégrité de
l’information
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
Format externe
Adaptation E→I
FE_EMTR
EMTR→RCPR
Interface privée
Interface publique
Adaptateur de format
Format interne
Transformation
Langage de
l’acteur émetteur
FI_EMTR
Cœur de la transformation PTE
Format interne
Adaptation I→R
FI_RCPR
Adaptateur de format
Format externe
FI_RCPR
Édition
Édition graphique
Plusieurs couches
selon complexité
Vérification et Validation
des éditions
Édition textuelle
Édition autre …
Langage de
l’acteur récepteur
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
Le monde M1 est généralement irréversible – Toute
transformation à un coût (entropie) → Notion de compensation
Argent réel du client
(chèque – CB – DAB)
Monde réel M1
Client
Stock réel du
fournisseur en magasin
Fournisseur
Banque
Maintien de la cohérence M1 – M2
Système d’information
BD client
BD Banque
BD fournisseur
Monde informatisé M2 (monde virtuel)
Le monde M2 est par construction réversible
Pattern d’instruction généralisée : la
transaction
État en entrée de la transformation
DE1
DE2
TR_I
DR1
•••
DEn
{ Invariant TR_I }
garantissant la
cohérence de TR_I
Historique
DR2
•••
DRm
n entités mémoire en entrée
Transaction
TP_I
m entités mémoire en résultat
A
C
I
D
État résultat de la transformation
Règle de modularité 1 entrée – 1 sortie
Le contrat d’entrée dans
l’intégrat n’a pas été vérifié.
×
Bloc non conforme aux
règles de modularité
Opérations
antérieures
Entrée
Chemin
d’entrée C1
NON
Vérification du
« contrat » en entrée
...
B1
B2
Bn
Blocs de code constitutifs
Chemin de
sortie C2
Vérification du
« contrat » en sortie
Sortie
Suite des opérations
×
NON
Le contexte de la défaillance
est perdu. Le contrat de sortie
n’a pas été vérifié.
Modèle de composant intégrable
Contexte et données partagées
Niveau SDS
Données partagées
Niveau Système/S-Système
Données partagées
Niveau Composant applicatif
Données partagées
Sphère de contrôle
de l’intégrat
entrée
Statiques/Dynamiques
Données privées ITG
Intégrat ITG
Version.Révision
(+ ressource propres)
Sortie
nominale
Sortie non
nominale
Nomenclature, caractéristiques, niveau de partage,
comportement, etc.
/////
Il est impératif de distinguer
soigneusement les données :
• Persistantes
• NON persistantes (équivalentes
à des phénomènes transitoires)
Ressources consommées,
niveau de charge
Allocation / Restitution explicites
Pool de ressources partagées
entre plusieurs intégrats
Données référencées
par ITG (modalités CRUD)
Contexte de l’intégrat
Comportement de l’intégrat
Latence
Quantité d’information traitée
Vision architecturale : Identification
des fonctions
RG
Mémoire de stockage des RÈGLES DE
GESTION et de la programmation des
enchaînements
M Moniteur
d’enchaînement
Fonction F1
Fonction F2
F_GPE
Canal de lecture
[1:n1] ports d’entrée
ME
Mémoire de stockage
des messages
entrants
Fonction F3
T
...
F_GPS
MS
Canal d’écriture
[1:n2] ports de sortie
Mémoire de stockage
des messages
sortants
Fonction Fn
F_Ressources
Mémoire persistante / non persistante
R
Autres ressources
Allouées / Non allouées
Validation de la cohérence des
messages reçus
Réception d’un message connu dans l’espace des
messages reçus (EMR)
Règles lexico-syntaxiques
Aides à l’usager
Analyse lexico-syntaxique
du message
Défaillance
Messages non reconnus
Log
Règles de conversions
Conversions éventuelles dans la structure
spécifique du système S
Messages incohérents
Défaillance
Référentiel
Règles sémantiques
Analyse sémantique du
message – Syntaxe abstraite
Aides à l’usager
Mises à jour éventuelles / chargement
des espaces EV et ER
Retour aux procédures métier pour la suite des opérations à
effectuer dans S
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
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
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 ?
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, …
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)
Arbres et paliers d’intégration – niveau
application
Ce que livre les
intégrateurs
3 paliers d’intégration
Vers les
niveaux
systèmes
P3
P2
P1
Ce que livre les
programmeurs
Assurance qualité de l’intégrat
garanti par un niveau de test
unitaire (couverture à x%,
preuve, …)
Application
générique de
niveau 3
Modules de
niveau 2
...
Modules de
niveau 2
Modules de
niveau 1
Intégrats
de rang 0
Intégrats
de rang 0
Environnement
de test
Environnement
de test
Généralement
mono organisation
Modules de
niveau 2
...
Modules de
niveau 1
...
...
Intégrats
de rang 0
Environnement
de test
Pour les TU
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)
Mesure combinée texte du programme
+ Texte des tests
Exigences
FURPSE + PESTEL
Texte des
tests
Texte du
programme
Taille
Taille
Coût-Délai de fabrication
du programme
Coût-Délai de fabrication
des tests
Validation
métier
Vérification
technologie
(Le QUOI, POUR QUI)
(Le COMMENT)
Tests unitaires pour les
intégrats de rang 0
Tests d’intégration, selon
structure de l’arbre d’intégration
Coût de garantie de contrat de service (SLA)
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 ?
Coût complet = Programme + Tests
satisfaisant les exigences
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 ?
Effort = k × (KLS )
Facteurs
d’influences
Terme linéaire
Dépend de la puissance
expressive et du « grain »
sémantique du langage de
programmation
+ Expérience des acteurs
Facteurs de coût
1+α
Terme NON linéaire
Dépend de la complexité de
l’application et de la maturité du
processus de développement
Î α est le facteur d’intégration
Facteurs d’échelle
Impact du coefficient d’intégration α
EFF (n × x)
ξ=
= nα
n × EFF ( x)
2
Amplification des coûts
ª Tout ajout de code génère un coût
d’intégration qui ne dépend que
du terme complexité
1,8
1,6
0,05
0,12
0,2
1,4
1,2
20
18
16
14
12
10
8
6
4
2
1
Facteur d'intégration
Î Ne dépend que du nombre
de modules intégrés
Courbes établies à partir des
équations COCOMO
Exemple N°2 : complexité via le modèle
d’estimation des coûts logiciel
Relation entre la complexité, les
équations COCOMO, CQFD et FURPSE
Complexité → (Taille, Nbre de pièces, Nbre de couplages)
F
U
R
P
S
E
C
Q
Taille de l’arbre
d’intégration
Effort = k × (KLS )
1+α
Via la quantité/effort de
tests en intégration IVVT
F
Rendement de l’effort IVVT exprimé en termes de :
• Taux de défauts résiduels
D
• Disponibilité de l’application ou du système
Den année = (0,5 ± 0,04) × (Een HA )
0 , 3± ε
Pour aller plus loin …

Architecture des systèmes d`information - LIX

Transcription

Documents pareils

GLG105 - Génie logiciel

hello Nurith, J`ai vu ton film hier à Nice où je tourne en cette période

Appel EDC41 Architecture de l`information

FRANCOIS C. Chargé de statistiques Caisse Primaire d`Assurance

Offre de services Content management

CENTRE BELL

GLG102 - Ingénierie de la qualité et du contrat de service

Capacités à acquérir en classe de 4ème www.technologie

Art et technologie. L`art électronique