conception de composants 3 quelques principes g

1
conception de composants3quelques principes
généraux darchitecture

• commencer par la fin rédiger la documentation
• la survie et les principes qui en dérivent
• lobservabilité et les principes qui en dérivent
• lorthogonalité et les principes en dérivent
• librairies de composants coordonnés
• penser en termes de protocoles

2
commencer par la fin
commencer par la fin rédiger dabord la
documentation des composants

• effet déconomie des mots
• ce quon ne parvient pas à formuler nest
  probablement pas clair
• on détecte rapidement les cas particuliers
• on tend à énoncer en termes dassertions
  universelles
• documentation trop longue, composant
  difficilement maîtrisable
• effet délaboration
• représentation mentale se substituant à
  limplémentation
• fait apparaître les états internes
  caractéristiques

3
principe de survie
un composant doit être programmé pour  survivre 

• quelles que soient les circonstances
  dutilisation
• un composant doit demeurer dans un état stable
• ne pas provoquer le plantage de lapplication qui
  lhéberge
• notifier (si cest spécifié) les anomalies
  dutilisation
• notifier (si cest spécifié) les anomalies
  détectées dans le contexte dexécution
• deux principes dérivés
• principe de lapplicabilité
• principe du contrôle

• la spécification doit clairement préciser
• le comportement normal du composant
• les usages défectueux et leur notification
  (exceptions, messages, etc.)

4
principe de lapplicabilité
toute opération doit pouvoir être déclenchée à
tout instant

• cela implique
• contrôle dapplicabilité (quand lopération
  peut-elle être valablement appliquée ?)
• contrôle des arguments (validation des paramètres
  actuels)
• si lopération nest pas validée, plusieurs
  possibilités
• déclenchement dexceptions opérations
  cruciales, traitements inaboutis, résultats faux
• comportement par défaut opérations secondaires
  ou décoratives
• parfois (souvent ?) adjonction dun paramètre
  pour un résultat par défaut
• parfois adjonction dun paramètre pour
  déclenchement ou non dexceptions

5
principe du contrôle
à la différence dune classe ad hoc, un
composant est destiné à être immergé dans des
contextes divers

• programmation soignée
• programmation encore plus soignée que pour une
  classe ad hoc
• contrôle et validation systématiques (contexte,
  opérations, paramètres)
• stratégies
• lancement dexceptions
• comportements par défaut (en général ignorer)

• trop dexceptions
• gestion des exceptions difficilement maîtrisable
• risque dune profusion de messages
  incompréhensibles pour lutilisateur
• trop de comportements par défaut
• traitements difficilement maîtrisables
• on ne sait plus ce que fait le composant

6
principe de lobservabilité
il ne suffit pas quun composant fasse quelque
chose, encore faut-il quil donne accès à son
état interne

• caractérisation de létat
• observabilité prévue dans la spécification
• valeurs caractéristiques de létat interne
• accès via des propriétés prévues à cet effet
• utilisations
• communications avec dautres composants
• gestion des affichages
• contrôles de validité complémentaires
• extensions du composant

7
principe des notifications
il ne suffit pas quun composant fasse quelque
chose, encore faut-il quil notifie ses
changements détat principaux

• articulation avec lobservabilité de létat
  interne
• notifications locales gestionnaires
  dévénements
• notifications diffusées protocole de diffusion
• utilisations (comme pour lobservabilité)
• communications avec dautres composants
• gestion des affichages
• contrôles de validité complémentaires
• extensions du composant

8
orthogonalité et indépendance des propriétés
quand une fonctionnalité est assumée, elle doit
lêtre de préférence dans toute sa généralité

• élaborer les fonctionnalités (et leur
  paramétrage)
• pour quils se présentent comme des dimensions
  indépendantes et combinables
• pour quils soient réguliers sur toute létendue
  des plages de valeurs
• gains
• simplification des spécifications (régularité)
• simplification du mode demploi
• favorise la réutilisation
• mais investissement non négligeable
• abstraction
• conception et spécification
• mise en œuvre et tests

éliminer à tout prix les cas particuliers
9
principe déconomie
imposer le moins de ce qui offre le plus de
possibilités

• en général
• principe de moindre action pour un effet maximal
• recoupe le principe dorthogonalité
• recoupe lélimination des cas particuliers

• en extension de composants
• retenir la plus petite altération du composant de
  base qui produit leffet souhaité
• réutiliser au maximum ce qui existe déjà
• demeurer compatible avec le reste du composant

10
principe de  triangulation 
si jai deux cas différents, ne pourrais-je pas
trouver un troisième cas plus général dont les
deux premiers ne seraient que des cas
particuliers ?

• principe dabstraction pour viser
• la généralité
• la régularité
• cf. le principe dorthogonalité

• toutefois
• ne pas alourdir abusivement le paramétrage
• une sémantique dopération trop complexe est
  difficilement maîtrisable
• le composant doit demeurer pensable

11
conception de composants corrélations entre
composants
on conçoit souvent des librairies de
composantset non un émiettement de composants
sans liens en eux

• concevoir des composants cohérents entre eux
• extensions de librairies proposant des composants
  cohérents
• toujours avoir le souci des extensions
• adaptation à des scénarios dutilisation
• les composants intègrent les articulations très
  probables
• préparent ou facilitent les connexions
• composants non visuels de traitement composants
  visuels daffichage

• conception de protocoles sous jacents
• élaborer dabord des protocoles
• accroître la généralité
• accroître la possibilité de connecter les
  composants entre eux
• puis implémenter des jeux de composants
  satisfaisant à ces protocoles

12
penser en termes de protocoles (1)
local
local
local

• les protocoles sont des sortes de schémas de
  contrôle

• les traitements  élémentaires  sont
   branchés  sur les protocoles

• les protocoles sont associés à un point de vue
  local

• dun point de vue local,les composants sont
  aussi des coupleurs de protocoles

• les procédés de diffusion sont transversaux

• la réification peut varier

13
penser en termes de protocoles (2)
les composants sont des coupleurs de protocoles
les protocoles sont des coupleurs de composants
effet de dualité local/local entre les
composants et les protocoles
14
petite synthèse provisoire
quest-ce que cest élaborer un composant, un
plugin, etc. ?
cest élaborer larticulation entre plusieurs
protocoles
pensez en termes de protocoles !