CONCEPTION DES LOGICIELS : Chapitre 1

Présentation au sujet: "CONCEPTION DES LOGICIELS : Chapitre 1"— Transcription de la présentation:

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

2 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

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

4 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 SE QOS 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

5 Les acteurs du développement
Maîtrise d’ouvrage MOA Analyse de la valeur, Gestion de risques, Contrat de service des usagers et Assurance qualité globale (recette), Expression de besoin et exigences comportementales 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

6 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 cible usager + 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

7 La vision temporelle : le cycle de vie (1/2)
Faisabilité Définition Développement et MCO Retrait 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

8 La vision temporelle : le cycle de vie (2/2)
Processus de spécification Processus de développement 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 VVT Nombre de RA/AC Exploitation et support QOS Référentiel produit : EB/EC+CG+CD+T/TU+VVT Mesure de la qualité de service Temps

9 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

10 Articulation des modèles – Qualité de l’information
Processus métier Flux Flux Cohérence de l’information Cohérence de l’information Contraintes ergonomiques Pragmatique Sémantique Cohérence des processus 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. ISO FURPSE) Architecture Cohérence globale du SI

11 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 PI Résultats du processus 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

12 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 ?

13 Complexité des modèles et traçabilité
Réalité Abstractions tirées de l’analyse de la réalité Abstractions fonctionnelles « MACHINERIE » métiers FLUX PROCESSUS PILOTAGE Correspondance complexe Abstractions intermédiaires CONTRÔLE Abstractions exécutables « MACHINERIE » informatique DONNÉES FONCTIONS  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

14 Traduction du besoin

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

16 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

17 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

18 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

19 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

20 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)

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

22 Les styles de programmation
Représentation sagittale de la correspondance ER r e f r e r f r r e r e e f Algorithme r e r r r f r r e e r r e e r r Flux / Phénomène entrant - E Flux / Phénomène ré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.

23 Extension et intention d’une fonction (1/5)
Représentation sagittale de la correspondance ER Représentation cartésienne r e f e1 e2 e3 ey en r1 r2 r3 rx rm  r f r e e f 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ène entrant - E Flux / Phénomène ré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

24 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)

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

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

27 Modèle de composant intégrable
Aspects comportementaux Fiabilité 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 partagées Données Statiques Dynamiques Données privées Flux d’événements non séquentiels Composant intégrable Flux d’événements non séquentiels Flux nominal en entrée Flux nominal en sortie Ressources Stimulus en ENTRÉE Nombre de points d’entrée Stimulus en SORTIE Nombre de points de sortie (y compris les sorties anormales) Nomenclature, caractéristiques, partage, etc.

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

29 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 »

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

31 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

32 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)

33 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

34 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

35 Les étapes de la conception (4/4)

36 Cycle de vie et traçabilité des modèles architecturaux
Formulation des règles d'architecture (axiomatique du/des modèles) Raisonnements par induction et généralisation Critères de simplicité et d'élégance (concision) SAVOIR-FAIRE DE L'ARCHITECTE Raisonnements par déduction. Critères de cohérence logique et d’évolutivité (puissance du modèle) Analogie avec d'autres modèles COMPROMIS Évolutions et adaptations Réutilisation de l’existant MODÈLE(s) CONCEPTUEL(s) MÉTIERS MODÈLE(s) LOGIQUE(s) selon niveau Description et mise en forme des éléments stables de la réalité Critères de fidélité et de précision ; rigueur Vérification expérimentale de la validité du modèle logique, en particulier le comportement (sûreté, performance) 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

37 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