CONCEPTION DES LOGICIELS : Chapitre 1

CONCEPTION DES LOGICIELS : Chapitre 1 GÉNÉRALITÉS – OBJECTIFS Modéliser pour comprendre

Plan du chapitre • Les acteurs et les processus impliqués dans l’architecture • Comment poser et résoudre le problème de l’architecte • Organisation des entités architecturales - Notion de « pattern » d’architecture • L’architecture au quotidien : Nature du travail effectué par le concepteur d’application

1ère partie Les acteurs et les processus impliqués dans l’architecture

Les acteurs majeurs de la conception Maturité des acteurs métiers Acteurs usagers du SI Acteurs développement Organisation de développement Organisation cible Usagers du système FURP INTERACTIONS QOS SE Organisation du MCO Complexité intrinsèque du système + maturité des technologies + maturité CMM/SE-CMM Maturité des exploitants + QOS (contrat de service) Acteurs exploitation/support

Les acteurs du développement Analyse de la valeur, Gestion de risques, Contrat de service des usagers et Assurance qualité globale (recette), Expression de besoin et exigences comportementales Maîtrise d’ouvrage MOA Architecte industriel Urbanisation Management de la réalisation en terme CQFD tel que fixé par la MOA, Méthodologie de développement, Choix des plates-formes, Architecture informatique, Intégration Validation Vérification et Tests (IVVT) système, Garantie qualité globale (engagement) Maîtrise d’œuvre MOE Chef de projet Sous-traitant de niveau 1 Développeur Chaque sous-traitant s’engage sur la qualité de la réalisation qui le concerne (Appels d’offres et contrats à prix fixes), vis à vis du MOE Chef de projet Sous-traitant de niveau 2 Développeur

Caractéristiques qualité du logiciel : FURPSE et l’organisation • Cf. Norme ISO/CEI 9126 (AFNOR Z67-133) – Évaluation des produits logiciels F Exigences fonctionnelles à développer U Exigences non fonctionnelles caractéristiques des besoins et exigences de l’organisation cibleusager + exploitant, en particulier l’exploitation du SI (facilité d’utilisation, fiabilité et rendement) R P S Exigences non fonctionnelles caractéristiques des besoins et exigences de l’organisation du MCO (maintenabilité et évolutivité du SI) + contrat de service (QOS) E

La vision temporelle : le cycle de vie (1/2) Développement et MCO Retrait Faisabilité Définition Prototype Compatibilité ascendante des versions successives Expérimentation Version N°1 Exploitation Réalisation de maquettes Réalisation de prototypes Version N°2 Exploitation N Cycles de Développement – Exploitation - Maintenance Validation fonctionnelle et non fonctionnelle au sens informatique Version N°n Exploitation Dominante MCO Validation fonctionnelle et comportements exigés en termes métier de la cible Dominante développement Vérification de la bonne prise en compte des règles architecturales au sein des projets (Revues + Inspections)  Grande variété de types de projets selon la nature des activités et « l’age » du système

La vision temporelle : le cycle de vie (2/2) Processus de développement Processus de spécification Expression de besoin et exigences Mesure de la maturité de l’EB/EC EB/EC (Spécification fonctionnelles) • Défauts détectés • Défauts propagés • Défauts ajoutés Conception générale CG Conception détaillée Implémentation CD Programmation et tests unitaires • Mesure du taux d’erreurs résiduelles Processus de conception P/TU Intégration (IVV&T) Mesure de la maturité (i.e. contrat de service) en exploitation Assurance qualité et activités transverses AQ Nombre de RA/AC VVT Exploitation et support QOS Référentiel produit : EB/EC+CG+CD+T/TU+VVT Mesure de la qualité de service Temps

La vision systémique de la conception : les rétroactions Expression de besoin et exigences EB/EC - STB (Spécification fonctionnelles) Conception générale Flux de Rapport d’Anomalies - RA CG Conception détaillée CD Programmation et tests unitaires P/TU Intégration (VV&T) VVT Exploitation et support Assurance qualité et activités transverses AQ

Articulation des modèles – Qualité de l’information Processus métier Flux Flux Cohérence de l’information Cohérence de l’information Cohérence des processus • Contraintes ergonomiques • Pragmatique • Sémantique Processus informatisés DONNÉES DONNÉES • Règles de typage • Syntaxe du type • Sémantique du type (règles d’interprétation) • Cohérence informatique • Intégrité du modèle de données • Caractéristiques non fonctionnelles (cf. ISO9126 - FURPSE) • Architecture Cohérence globale du SI

Modèle générique de processus métier et/ou informatique Pilote Externe PE Flux de contrôles Contrôle Pilote Interne Données du processus Résultats du processus PI Domaine des valeurs en entrée Domaine des valeurs en sortie Tâches et/ou activités à effectuer (i.e. fonctions et/ou actions transformant les flux) Contrôles entrées Contrôles sorties Flux d’échanges Flux d’échanges Validation Vérification Test (VVT) Flux de ressources allouées/restituées Allocation Restitution Stock de ressources nécessaires au processus Protocole

Aspect qualité des tâches - FURPSE Délai de restitution des résultats Le « QUAND » : conditions de déclenchement ; événements générateurs Le « QUOI » : ce que ça fait ; nature de la transformation PI TÂCHES ACTIVITÉS F U R P S E Pour « QUI » : identification précise de l’acteur pour qui la transformation est faite Entrée Résultat « COMMENT » : avec quelle qualité de service (QOS) ; pour quelle FINALITÉ « COMBIEN » : durée de vie, pérennité du besoin auquel répond la transformation Avec quelles ressources additionnelles ?

Complexité des modèles et traçabilité Réalité Abstractions tirées de l’analyse de la réalité Abstractions fonctionnelles PILOTAGE PROCESSUS FLUX « MACHINERIE » métiers Correspondance complexe Abstractions intermédiaires CONTRÔLE Abstractions exécutables FONCTIONS « MACHINERIE » informatique DONNÉES  Pièges : Imaginer que le FONCTIONNEL métier se projette 1 1 sur les ENTITÉS ARCHITECTURALES(Cf. méthode RAD utilisée hors contexte) et que la notation suffit à rendre le complexe intelligible

Traduction du besoin

2ème partie Comment poser et résoudre le problème de l’architecte

Une définition de l’architecture • La conception est terminée lorsque chacun des acteurs du développement sait ce qu'il a à faire, pourquoi il le fait et comment il doit le faire(i.e. les contraintes du modèle CQFD sont satisfaites)2 aspects : • Répartition individuelle des tâches • Répartition collective des tâches

Décisions et choix d’architecture optimisés sur la prévention • Anticiper les risques • contrôle du coût d’intégration • Niveau de parallélisme dans le processus d’intégration • contrôle du coût d’exploitation • Réduire les temps de latence ErreurDéfautDéfaillance • contrôle du coût d’évolution • Interfaces ouvertes et compatibilité ascendante • Automatiser la vérification • Tests « en-ligne » intégrés au code et gérés comme le code • Activation sur événements

Critères d’optimalité • Minimiser le nombre de fonctions, et le volume de code correspondant • Le nombre de défauts est une fonction croissante du volume de code • Ratio de l’instrumentation par rapport au fonctionnel • Doser la redondance • Topologie des ensembles {Fonctions} et {Données} • Ensembles denses, correctement partitionnés • Distance d’observation • Chemin parcouru entre deux points d’observation ; dépendances fonctionnelles

Le problème de l’architecte (1/2) • Traduire le besoin métier de l’organisation cible • C’est une représentation en extension d’un premier modèle (en UML, ce sont les cas d’emploi/use case) En entités informatiques : • données • instructions/fonctions • enchaînements/contrôles • C’est une représentation en intention d’un second modèle qui matérialise la compréhension de l’architecte • un algorithme • Un assemblage d’algorithmes (intégration) Objet

Le problème de l’architecte (2/2) • A partir des informations résultant de l’expression des besoins et des exigences comportementales (transformations des flux informationnels), l’architecte doit découvrir la « bonne » représentation de/des fonctions transformatrices correspondantes, • soit par réutilisation et assemblage d’éléments préexistants : • Bibliothèque de composants (« Design pattern » ou schémas de programmes) • Bibliothèques d’algorithmes • soit par invention d’un algorithme ad hoc qui satisfont le mieux les caractéristiques FURPSE (compromis CQFD)

Propriétés d’une bonne traduction • Le résultat de la traduction opérée par l’architecte doit être : • Fidèle (traçabilité métierinformatique) • Consistante (sans contradiction, déterministe) • Complète (sans omission, ni répétition) • Raisonnablement compacte (taille du programme) et économe en ressources de traitement (performance) • Compréhensible par des tiers qui n’ont pas participé à son élaboration (facilité d’emploi, maintenabilité) • Adaptable à de nouveaux besoins (évolutivité)

Les styles de programmation Représentation sagittale de la correspondance ER r f e r e r r f r e r e Algorithme f e r e r r r f r r e e r r e e r r Flux / Phénomèneentrant - E Flux / Phénomènerésultant - R • Programmation au cas par cas, dont la cardinalité est celle de l’ensemble des  , soit : • Programmation par algorithme (abstraction d’un cas général) + qq. Cas particulier à titre d’exception ; Minimise la quantité d’information.

e1 e2 e3 ey en r1 r2 r3 rx rm  Extension et intention d’une fonction (1/5) Représentation sagittale de la correspondance ER Représentation cartésienne r f e r f r e f e r r f r r e e r • Les cases de la matrice avec  représente l’extension de f • C’est une table de correspondance (très facile à programmer) Flux / Phénomèneentrant - E Flux / Phénomènerésultant - R • Les deux représentation sont duales l’une de l’autre (elles signifient la même chose) ; l’une peut se représenter par une procédure de traitement, l’autre par une simple table/fichier (qui peut être de très grand volume)  Dualité INSTRUCTIONS / DONNÉES constitutive du modèle de Von Neumann

Extension et intention d’une fonction (2/5) Obtention de l’extension par mesure et/ou expérience • Il existe des cas où la représentation en extension peut être remplacée par un procédé de calcul quand on dispose d’un algorithme : c’est la représentation en intention Arc de longueur x • La représentation en intention est généralement beaucoup plus compacte, mais elle nécessite une grande puissance de calcul pour obtenir les résultats (i.e. la représentation en extension qui seule intéresse l’ingénieur)

3ème partie Organisation des entités architecturales Notion de « pattern » d’architecture

Articulation des 3 niveaux d’intégration des systèmes informatiques 1 Système – N Applications N Systèmes fédérés - INTEROPÉRABILITÉ Appli N°1 Appli N°2 Appli N°n S1 S2 Sn ••• ••• Interopérabilité Communications inter-applications Bus interopérabilité  EAI, IAI, … RAS RAS Approche Client-Serveur structurée par niveau d’intégration Autres systèmes Périmètre de la fédération de systèmes sous contrôle de règles d’interopérabilité Périmètre du système sous contrôle de règles de communication 1 Application – N Composants Modèle des données persistantes de l’application IHM Fonctions Données Modèle des données non persistantes de l’application (communications par la mémoire) Communications via mécanismes OS RAS Périmètre de l’application sous contrôle strict de l’OS plate-forme Traces, historiques, etc. Autres applications

Modèle de composant intégrable • Aspects comportementauxFiabilité • Performance du composant (qualité de service) • Capacity planning • System management • Maintenabilité du composant Données partagées Hiérarchie et niveaux de partage Données partagées Données Données partagées Statiques Dynamiques Données privées Composant intégrable Flux d’événements non séquentiels Flux d’événements non séquentiels Flux nominal en sortie Flux nominal en entrée Ressources Stimulus en ENTRÉENombre de points d’entrée Stimulus en SORTIENombre de points de sortie (y compris les sorties anormales) Nomenclature, caractéristiques, partage, etc.

4ème partie L’architecture au quotidien : Nature du travail effectué par le concepteur d’application

Les 3 contraintes de la conception • Contraintes architecturales liées à la nature du produit logiciel à réaliser et à son contexte d’emploi (FURPSE) • Contraintes technologiques liées à la qualité des matériaux, aux méthodes et aux outils disponibles pour «usiner» les matériaux • Données • Algorithmes de transformation des données • Contrôles (séquentiels, non séquentiels, par messages et évènements, etc.) • Contraintes organisationnelles et humaines liées à la compétence et à l'expérience des individus, des équipes et des organisations • Courbes de maturité et expérience ; modèles de maturité CMM, ISO15504 SPICE Construction des «OBJETS »

Contraintes techniques(Liées à la nature de l’application)

Contraintes technologiques • Données • Mémoire centrale (non persistante) : variables scalaires et agrégats, typage fort, modèles objets • Mémoire persistante : fichiers (séquentiels, indexés, …), bases de données (Réseau/NDL, Relationnel/SQL, OBJET) • Algorithmes • Langages impératifs classiques : FORTRAN, COBOL, Ada, C… • Langages objets : C++, JAVA, … • Langages fonctionnels (diffusion anecdotique) • Enchaînement/Contrôle des processus/traitements • Langages de commandes (au niveau du système d’exploitation) : JCL constructeurs, Shell UNIX, Langage PERL, … • Moniteurs : « Batch », transactionnel, temps-réel

Les étapes de la conception (1/4) • Notion de système englobant • Le logiciel fait nécessairement partie d’un ensemble plus vaste qui détermine tout ou partie des comportements attendus (contraintes) • Systèmes d’information ; systèmes informatisés ; systèmes hybrides • Notion de modèle • C'est une représentation abstraite rigoureuse de tout ou partie d'un système en vue d'en étudier le comportement. L'étude peut être : • Qualitative : existence de telle ou telle propriété • Le système est-il stable ? • Quantitative : on sait associer une mesure à la propriété • Quel et le temps de réponse moyen? • Quelques mots clés • Représentation abstraite : syntaxe, sémantique, pragmatique • Isomorphisme / homomorphisme : règles de correspondance qui relie le modèle à la réalité, d’où : fidélité  vérification, validation, test • Observable : état du système qui a un sens par rapport à la réalité (observateur)

Les étapes de la conception (2/4) • Intérêts des modèles • Pouvoir d’anticipation : c'est la capacité à prédire • Détection et contrôle • Contrôle aérien et spatial, météo… • Pouvoir d’accélération : le modèle va plus vite que la réalité • Calcul numérique, simulation, recherches sur critères… • Aides à la décision ; magasin de données ; données cartographiques ; etc. • Pouvoir de substitution : on remplace la réalité par un modèle • Un conducteur de train • Le modèle prend toutes les décisions à la place du conducteur • Les comptables et employés aux écritures dans les banques • Système d'information • Tout système informatique est, par définition, un modèle

Les étapes de la conception (3/4) • Ces étapes indiquent un cheminement, une progression (i.e. une méthode, au sens littéral du terme), et non pas une séquence d’activités nettement séparées

Les étapes de la conception (4/4)

Cycle de vie et traçabilité des modèles architecturaux Formulation des règles d'architecture (axiomatique du/des modèles) • Raisonnements par déduction. • Critères de cohérence logique et d’évolutivité (puissance du modèle) • Analogie avec d'autres modèles • Raisonnements par induction et généralisation • Critères de simplicité et d'élégance (concision) SAVOIR-FAIRE DE L'ARCHITECTE COMPROMIS Évolutions et adaptations Réutilisation de l’existant MODÈLE(s) CONCEPTUEL(s) MÉTIERS MODÈLE(s) LOGIQUE(s) selon niveau • Vérification expérimentale de la validité du modèle logique, en particulier le comportement (sûreté, performance) • Description et mise en forme des éléments stables de la réalité • Critères de fidélité et de précision ; rigueur RÉALITÉ MÉTIER Recueil d'information métiers et élaboration des scénarios Sens normal de la progression !!! L’inverse peut conduire à des systèmes qui ne satisfont pas le métier

But de l'architecture - Synthèse • Trouver « dans les délais impartis » le meilleur compromis économique CQFD entre : • Coûts de fabrication  (court terme) • Permettre le travail en parallèle des différents acteurs et/ou projets • Isolation, confinement • Hiérarchie d'interfaces et services généraux • Coûts d'exploitation  (moyen terme) • Puissance nécessaire au bon fonctionnement de l'architecture • Certains mécanismes sont très coûteux (attention aux ressources lentes, en particulier les entrées-sorties, les réseaux) • Puissance utile aux applications des utilisateurs et des usagers (temps de réponse, délai de restitution des résultats) • Administration et qualité du service (QOS : entretien et mise à jour, sûreté de fonctionnement, sécurité) • Durée de vie  (long terme) • Permettre les évolutions/adaptations à coût marginal sur une longue période • Croissance du modèle initial • C'est un jeu à somme nulle

CONCEPTION DES LOGICIELS : Chapitre 1