CSI1502 Principes fondamentaux en conception des logiciels Chapitre 4 Classes et Objets.
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6Page 1...
-
Upload
narcisse-guillon -
Category
Documents
-
view
119 -
download
1
Transcript of J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6Page 1...
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 1
CONCEPTION DES LOGICIELS : Chapitre 1
GÉNÉRALITÉS – OBJECTIFS
Modéliser pour comprendre
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
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 3
1ère partie
Les acteurs et les processus impliqués dans l’architecture
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 4
INTERACTIONS
Les acteurs majeurs de la conception
Organisation de développementOrganisation de développement
Organisation du MCO
Organisation du MCO
Organisation cible
Usagers du système
Organisation cible
Usagers du système
Complexité intrinsèque du système + maturité des technologies + maturité
CMM/SE-CMM
Maturité des acteurs métiers
Maturité des exploitants + QOS (contrat de
service)
FURP
SE
QOS
Acteurs développement
Acteurs exploitation/support
Acteurs usagers du SI
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 5
Architecte industrielUrbanisation
Les acteurs du développement
Maîtrise d’ouvrageMOA
Maîtrise d’œuvreMOE
Sous-traitant de niveau 1
Sous-traitant de niveau 2
Analyse de la valeur, Gestion de risques, Contrat de service des usagers et Assurance qualité globale (recette), Expression de besoin et exigences comportementales
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)
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
Chef de projet
Développeur
Développeur
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 6
Caractéristiques qualité du logiciel : FURPSE et l’organisation
Cf. Norme ISO/CEI 9126 (AFNOR Z67-133) – Évaluation des produits logiciels
F
U
R
P
S
E
Exigences fonctionnelles à développer
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)
Exigences non fonctionnelles caractéristiques des besoins et exigences de l’organisation du MCO (maintenabilité et évolutivité du SI) + contrat de service (QOS)
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 7
Compatibilité ascendante des versions successives
La vision temporelle : le cycle de vie (1/2)
Faisabilité Définition Développement et MCO Retrait
Version N°1
Version N°2 Exploitation
Version N°n Exploitation
N Cycles de Développement – Exploitation - Maintenance
PrototypeExpérimentation
Réalisation de prototypes
Validation fonctionnelle et non fonctionnelle au sens
informatique
Validation fonctionnelle et comportements exigés en termes métier de la cible
Dominante MCO
Dominante développement
Exploitation
Vérification de la bonne prise en compte des règles architecturales au sein des projets (Revues + Inspections)
Réalisation de maquettes
Grande variété de types de projets selon la nature des activités et « l’age » du système
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 8
La vision temporelle : le cycle de vie (2/2)
Expression de besoin et exigences
Exploitation et support
Processus de conception
Processus de développement
Assurance qualité et activités transverses AQ
EB/EC(Spécification
fonctionnelles)
CG
CD
P/TU
VVT
Mesure de la qualité de service
Mesure de la maturité de l’EB/EC
• Défauts détectés• Défauts propagés• Défauts ajoutés
Conception générale
Conception détaillée
Programmation et tests unitaires
Intégration (IVV&T)
Implémentation
• Mesure du taux d’erreurs résiduelles
Nombre de RA/AC
Mesure de la maturité (i.e. contrat de service) en exploitation
Temps
Processus de spécification
QOSRéférentiel produit :EB/EC+CG+CD+T/TU+VVT
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 9
La vision systémique de la conception : les rétroactions
Expression de besoin et exigences
Exploitation et supportAssurance qualité et activités transverses AQ
EB/EC - STB(Spécification fonctionnelles)
CG
CD
P/TU
VVT
Conception générale
Conception détaillée
Programmation et tests unitaires
Intégration (VV&T)
Flux de Rapport d’Anomalies - RA
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 10
Articulation des modèles – Qualité de l’information
Processus informatisés
Contraintes ergonomiques• Pragmatique• Sémantique
Règles de typage• Syntaxe du type• Sémantique du type (règles d’interprétation)
Cohérence des processus
Cohérence informatique• Intégrité du modèle de données• Caractéristiques non fonctionnelles (cf. ISO9126 - FURPSE)• Architecture
Cohérence de l’information
Cohérence de l’information
Processus métierFlux Flux
Cohérence globale du SI
DO
NN
ÉES
DO
NN
ÉES
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 11
Modèle générique de processus métier et/ou informatique
PE
PI
Con
trôl
es e
ntr
ées
Con
trôl
es s
orti
esTâches et/ou activités à effectuer
(i.e. fonctions et/ou actions transformant les
flux)
Validation Vérification Test (VVT)
Stock de ressources nécessaires au processus
Dom
ain
e d
es
vale
urs
en
en
trée
Dom
ain
e d
es
vale
urs
en
sor
tie
Allocation Restitution
Flux d’échanges
Flux de contrôles
Flux d’échanges
Flux de ressources allouées/restituées
Protocole
Pilote Externe
Pilote Interne
Résultats du processus
Données du processus
Contrôle
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 12
Aspect qualité des tâches - FURPSE
TÂCHES ACTIVITÉS
F
URPSE
Entrée Résultat
Avec quelles ressources additionnelles ?
Délai de restitution des résultats
« COMMENT » : avec quelle qualité de service (QOS) ; pour quelle FINALITÉ
Pour « QUI » : identification précise de l’acteur pour qui la transformation est faite
PI
Le « QUOI » : ce que ça fait ; nature de la transformation
Le « QUAND » : conditions de déclenchement ; événements générateurs
« COMBIEN » : durée de vie, pérennité du besoin auquel répond la transformation
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 13
Complexité des modèles et traçabilité
Réalité
CONTRÔLECONTRÔLEDONNÉESDONNÉES FONCTIONSFONCTIONS
Abstractions fonctionnellesFLUXFLUX PROCESSUSPROCESSUS PILOTAGEPILOTAGE
Abstractions intermédiaires
Abstractions exécutables
« MACHINERIE » métiers
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
Abstractions tirées de l’analyse de la réalité
« MACHINERIE » informatique
Correspondance complexe
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 14
Traduction du besoin
TRADUCTION du BESOIN SYSTEME en FONCTIONS
Information (besoins et exigences comportementales ) Entités fonctionnelles (conception générale et/ou détaillée)
Domaine EB/EC Domaine CG/CD
Caractéristiques à traduire
(Cf. ISO 9126)
Monde du besoin et des exigences Besoin qualitatif et informel Description lisible par les humains
Monde de la pragmatique et des signes (symbologie)
Entités fonctionnelles : à la fois quantitatif et formel Décompositions en : { Données,
Instructions et Contrôles }
Monde de la syntaxe et sémantique des constructions informatiques
[F] Fonction Description en extension (à l’aide de scénarios)
Description en intention par un algorithme (i.e. un modèle)
[U] Facilité d’emploi et Utilisation
Modèle psycho-cognitif des usagers du système selon le type des usagers
Modèle des organisations qui utilisent le système
Modèles informatiques réalisant le(s) comportement(s) demandé(s)
[R] Fiabilité et garantie de Récupération
Taux de pannes acceptables, disponibilité, évaluation des risques
Tolérance de pannes, auto-tests, redémarrage à chaud et/ou à froid, reconfiguration
[P] Performance Ressources informatiques et équipements disponibles sur la ou les plates-formes d’exécution du système
Ressources nécessaire selon la charge générée par les usagers
Complexité algorithmique des traitements effectués
Métrologie et instrumentation (interne et externe au système)
Capacity planning et system management
[S] Evolutivité
maintenabilité niveau de Service
Durée de vie globale, nombre probable de versions, coût récurent souhaité pour le MCO
Architecture, interfaces, modules de construction
Stratégie d’intégration (règles de construction)
[E] Portabilité et Evolution
Indépendance souhaitable vis à vis de la plate-forme et des COTS ; 2ème source d’approvisionnement
Machine abstraite d’encapsulation pour les COTS sensibles et/ou de pérennité incertaine
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 15
2ème partie
Comment poser et résoudre le problème de l’architecte
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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
PROJ ET NOMINAL GRAND PROJ ET TRÈS GRAND PROJ ET
1 ÉQUIPE
Effectif moyen : 5-8 Personnes
Durée : 1-2 Ans
Effort moyen : 10-15 HA
Volume : 100 KLS
(Productivité moyenne entre 5-10 KLSdocumentées-testées par personne etpar an).
Le chef de projet est l’architecte.
3-4 ÉQUIPES
Effectif moyen : 20-30 Personnes
Durée : 2-3 ans
Effort moyen : < 100HA
Volume : < 500 KLS
Une politique de réutilisationcommence à devenir rentable.
(1 ou 2 architectes, dès le départ, sontindispensables).
Plus de 5 ÉQUIPES
Effectif moyen : > 75 personnesDurée initiale : > 3 ans
Effort initial moyen : > 100 HA
Volume : > 500 KLS
Durée de vie système : > 15 ans ;Nombreuses versions livrées.
Les partenariats + l’intégrationsystème nécessite une vraie équiped’architecture qui assurera lapérennité long terme du projet.
Respect des normes internes à l'équipe.
CMM niveau 2 + PSP
Respect des normes qualité del'entreprise.
CMM niveau 3 - 4
Ingénierie système et respect desnormes internationales afférentes.
CMM niveau 4 -5
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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’exploitationRéduire les temps de latence ErreurDéfautDéfaillance
contrôle du coût d’évolutionInterfaces 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
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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éesinstructions/fonctionsenchaî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 algorithmeUn assemblage d’algorithmes (intégration)
Objet
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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)
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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étierinformatique) 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é)
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 22
Les styles de programmation
Flux / Phénomène
entrant - EFlux / Phénomène
résultant - R
e
e
e
e
e
r
r
rr
r
rr
r
f
f
f
f
Représentation sagittale de la correspondance ER
e
e
e
e
e
r
r
rr
r
rr
r
Alg
ori
thm
e
• Programmation au cas par cas, dont la cardinalité est celle de l’ensemble des , soit :
ECardRCardfCard
• Programmation par algorithme (abstraction d’un cas général) + qq. Cas particulier à titre d’exception ; Minimise la quantité d’information.
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 23
Extension et intention d’une fonction (1/5)
Flux / Phénomène
entrant - EFlux / Phénomène
résultant - R
e
e
e
e
e
r
r
rr
r
rr
r
f
f
f
f
Représentation sagittale de la correspondance ER Représentation cartésienne
e1 e2 e3 ey en
r1
r2
r3
rx
rm
Les cases de la matrice avec représente l’extension de f• C’est une table de correspondance (très facile à programmer)
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
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 24
Extension et intention d’une fonction (2/5)
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
Obtention de l’extension par mesure et/ou expérience
)cos(x
)sin(x Arc de longueur x
sin
!5!3
sin53 xx
xx
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)
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 25
3ème partie
Organisation des entités architecturales
Notion de « pattern » d’architecture
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 26
Articulation des 3 niveaux d’intégration des systèmes informatiques
IHM Fonctions Données
Communications via mécanismes OS
Autres applications
1 Application – N Composants
Communications inter-applications
Autres systèmes
AppliN°1
AppliN°2
AppliN°n
1 Système – N Applications
Bus interopérabilité EAI, IAI, …
S1 S2 Sn
N Systèmes fédérés - INTEROPÉRABILITÉ
••••••
Périmètre de l’application sous contrôle strict de l’OS plate-forme
Périmètre du système sous contrôle de règles de communication
Périmètre de la fédération de systèmes sous contrôle de règles d’interopérabilité
Approche Client-Serveur structurée par niveau
d’intégration
Approche Client-Serveur structurée par niveau
d’intégration
Inte
rop
éra
bili
té
RASRAS
RASModèle des données non persistantes de l’application (communications par la mémoire)
Modèle des données persistantes de l’application
Traces, historiques, etc.
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 27
Modèle de composant intégrable
Composant intégrable
Ressources
Données privées
Données partagées
Données partagées
Données partagées
StatiquesDynamiques
Hiérarchie et niveaux de partage
Flux d’événements non séquentiels
Flux nominal en entrée
Flux d’événements non séquentiels
Flux nominal en sortie
Nomenclature, caractéristiques, partage, etc.
Stimulus en ENTRÉENombre de points d’entrée
Stimulus en SORTIENombre de points de sortie (y compris les sorties anormales)
Aspects comportementauxFiabilitéPerformance du composant (qualité de service)• Capacity planning• System managementMaintenabilité du composant D
onné
es
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 28
4ème partie
L’architecture au quotidien : Nature du travail effectué par le concepteur
d’application
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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 »
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 30
Contraintes techniques(Liées à la nature de l’application)
Domaine Structure dedonnées
Algorithmes Contrôle
Gestion Difficile Simple Simple (*1)
Systèmes d'information (C3I,SIC) Très difficile Difficile Très difficile
Analyse numérique, simulation Simple Difficile Simple (*2)
Télécommunication Simple Simple Très difficile
Compilateurs Très difficile Très difficile Très simple
Temps réel (Systèmes C2) Simple Difficile Très difficile
Traitement et analyse dedonnées
Très difficile(sémantique)
Difficile Simple
Systèmes d'exploitation Très difficile Très difficile Très difficile
(*1) sauf dans le cas du client-serveur(*2) sauf si temps réel
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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)
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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èleUn conducteur de train
Le modèle prend toutes les décisions à la place du conducteurLes comptables et employés aux écritures dans les banques
Système d'information
Tout système informatique est, par définition, un modèle
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 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
N° Description 1 Construction du modèle conceptuel
On élabore le modèle qui reflète l'état actuel et réel des procédures, des données, des événements et de toutes leurs relations statiques et dynamiques.
2 Validation du modèle conceptuel À l'aide de scénarios, et en étroite coopération avec les utilisateurs, on s'assure de la complétude, de la précision et de la fidélité du modèle conceptuel.
3 Construction des abstractions logiques À partir du modèle conceptuel, on effectue une première analyse en vue de détecter les abstractions qui vont permettre de séparer les aspects technologiques, des processus et des données essentielles du système qui doivent être indépendants des choix technologiques.
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 35
Les étapes de la conception (4/4)
4 Organisation des données À partir des objets et entités stables qui déterminent les activités fondamentales du système, on élabore la structure de données la plus appropriée à la finalité du système
5 Organisation des processus et des traitements À partir des événements auxquels le système répond et du contexte système, on détermine les différents processus nécessaires et les enchaînements, ainsi que le pilotage et le contrôle.
6 Spécification de l'architecture logique Reconstruction du modèle conceptuel en y intégrant toutes les contraintes techniques, technologiques et humaines.
7 Validation et approbation du modèle logique On vérifie que tous les résultats de l'étape N°2 sont toujours valide, et que les choix techniques et technologiques satisfont les exigences des utilisateurs ou de leurs mandataires maîtres d'ouvrages. L'architecture est formellement approuvée par toutes les parties prenantes.
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 36
Cycle de vie et traçabilité des modèles architecturaux
SAVOIR-FAIRE DEL'ARCHITECTE
SAVOIR-FAIRE DEL'ARCHITECTE
RÉALITÉMÉTIER
RÉALITÉMÉTIER
MODÈLE(s)CONCEPTUEL(s)
MÉTIERS
MODÈLE(s)CONCEPTUEL(s)
MÉTIERS
MODÈLE(s)LOGIQUE(s)selon niveau
MODÈLE(s)LOGIQUE(s)selon niveau
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
• 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
• Raisonnements par induction et généralisation
• Critères de simplicité et d'élégance (concision)
Recueil d'information métiers et élaboration des scénarios
Évo
luti
ons
et a
dap
tati
ons
Réu
tili
sati
on d
e l’
exis
tan
t
COMPROMIS
Sens normal de la progression !!!L’inverse peut conduire à des systèmes qui ne satisfont pas le métier
J.Printz / CNAM - CMSL / Conception des logiciels – chapitre 1 - Généralités / Vers. 5.6 Page 37
But de l'architecture - SynthèseTrouver « 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ériodeCroissance du modèle initial
C'est un jeu à somme nulle