Pour adapter le modèle de conception au modèle d'implémentation nous devons premièrement identifier les contraintes techniques avec lesquelles notre système doit être construit. Idéalement cette identification peut être réalisée dés l'analyse, avant la construction du modèle d'analyse comme cela joue sur le degré affecte que doit contenir le modèle d'analyse.
Que doit on placer dans l'environnement d'implémentation ?
Tous ce qui peut affecter la réalisation du projet.
En particulier le langage de programmation, le système matériel et son système d'exploitation, le gestionnaire de base de données, l'environnement graphique, les bibliothèques auxiliaires, les instances des acteurs non-humains.
Un des changements les plus fréquents est un changement dans l'environnement d'implémentation, il est donc préférable de définir cet environnement avec l'idée de changement en tête (comme le reste du système). Ceci implique (principe de localité) qu'un minimum d'objet doivent percevoir les contraintes dues à l'environnement effectif.
La stratégie est donc localité et encapsulation.
Ainsi les changements seront limités à un objet et ne changerons pas le comportement des autres. (Ceci n'est pas spécifique aux langages objets mais vient de la bonne programmation traditionnelle. Mais ici dans le modèle de conception nous avons un moyen de rendre cette approche apparente et de la contrôler.)
Quelques remarques:
Changement dans l'environnement cible.
Si nous devons être capables de changer des parties de l'environnement cible, alors nous allons créer des blocs qui matérialisent ces différentes occurrences. Si notre application utilise un système de fichier sur un OS. Nous devons créer un bloc qui va réaliser pour notre système la gestion de fichiers et qui sera l'interface avec le SGF de l'OS.
conception.sgfUn bloc pour encapsuler le système de gestion de fichier.
Le bloc système de fichiers peut soit avoir une implémentation différente pour des configurations différentes du système. Ce qui peut être fait grace à une classe abstraite d'interface avec des sous-classes spécifiques pour chaque plate-forme.
Ou encore l'objet peut, à l'exécution, sélectionner le bon code pour la plate-forme courante. Ou encore, comme en C, c'est au moment de la compilation de la configuration spécifique au système cible, que le bon code est compilé.
Le choix de la méthode dépend de votre mode de travail et du mode de production du système.
Le nombre et la localisation des processeurs doivent être étudiés ici.
Le langage de programmation a un impact prépondérant sur la conception.
Ici les questions suivantes doivent être mises en évidence.
Héritage, Héritage Multiple, Typage, portabilité, mécanisme de gestion d'erreurs (exceptions), Gestion mémoire et Glaneurs de cellules. Ceci en correlation avec le savoir faire de l'équipe de développement.
Les bibliothèques de composants (composants graphiques).
Les besoins en performances, les limitations sur l'espace mémoire. Ces besoins ont une forte incidence sur la conception. Par exemple une base de données très sollicitée et trop lente impose un réarrangement de la base ou l'introduction de nouveaux index, etc.
La stratégie reste de garder les optimisations pour plus tard dans le développement, et à ce stade il faut optimiser uniquement le développement. Ensuite, si nécessaire, on introduit des optimisations une fois que l'on a suffisamment de code implémenté pour pouvoir faire des tests de vitesse. Si vous n'êtes pas sur de l'efficacité d'une optimisation (un changement) ne la faites pas !
Les personnes et l'organisation.
Si la conception doit être distribuée (sur plusieurs sites), il faut diviser la conception. Le partage de la conception doit se faire en fonction du savoir faire des personnes ou des équipes. Les personnes étant une donnée essentiellement dynamique, les changements ne doivent pas avoir trop d'impact sur le système.
exercice: Faire une liste des problèmes liés aux personnes et donner des solutions pratiques à chaque cas.
Pour obtenir un résultat, le plus robuste possible, l'ensemble des points précédents doit avoir un impact aussi réduit que possible sur la conception. (C'est à dire qu'un changement de l'environnement n'a peu ou pas d'effet sur la conception du système).