Principe de changement entre le modèle d'analyse et le modèle de conception.

Des changements peuvent et doivent avoir lieu mais ces changements doivent être justifiés et documentés.

Il nous faudra sans doute changer le modèle idéal (défini dans l'analyse), ces changements ce déclinent de quatre façons :

• Introduction de blocs non définis dans le Modèle d'analyse.
• Elimination de blocs
• Couper ou fusionner des blocs.
• Changer des associations entre blocs.

Ajouter des blocs pour s'adapter à l'environnement est normal. Ajouter des blocs pour des fonctionalités non définies dans le modèle d'analyse est anormal.
La destruction de blocs est très suspecte. Pourquoi détruire un bloc ? Si la raison vient de l'implémentation. Ok. Mais si la raison est un changement de la structure logique. Stop! recommencez dans le modèle d'analyse votre réflexion. Sinon un élément de votre réflexion est douteux.

Couper et fusionner semble aussi suspect car nous allons ici aussi à l'encontre de nos décisions d'analyse. Pour l'implémentation ou les performances, ces changements sont peut être nécessaires, dans ce cas ils devront être réalisés avec beaucoup d'attention et être soigneusement documentés.

Les changements d'association sont les plus communs. Ceci est d'autant plus vrai qu'entre en compte des problèmes comme la synchronisation de processus, ou la communication inter-processus ou de réseau. Un autre cas classique est le mode d'implémentation de l'association, mode que l'on doit spécifier ici. L'extension par exemple n'est pas un mode très souvent proposé par les langages de programmation. extension : Le comportement b1 est inséré dans le comportement b2. On cherche a écrire b2 de façon indépendante de b1. Idéalement b1 décide lui-même de s'insérer dans b2. Un tel mécanisme n'existe pas dans la plupart des langages de programmation standards (mais c'est possible facilement). La solution est de laisser l'initiative à b2 d'envoyer un stimuli à b1. ainsi l'association d'extension de b1 vers b2 se transforme en une association de connaissance entre b2 et b1. conception.b1b2Transformation d'une association

Dans notre exemple Gestion alarm étend Article déposé. C'est dans le bloc Article déposé que nous allons envoyer un message au gestionnaire d'alarme.

Les associations d'héritage doivent être revues si le langage de programmation ne propose pas le concept. Nous reviendrons sur ce point.

Pour notre exemple, l'environnement d'implémentation est simple un seul processus, en Objective C, pas de BD. Par contre comment interface t-on les différents organes matériels au système ? Nous supposerons l'existence d'interfaces primitives que nous encapsulons dans des programmes en C (ObjectiveC,C++) et nous créons les blocs correspondants à ces encapsulations dans notre modèle de conception.

Les bibliothèques de Composants. Il est nécessaire de choisir très tôt la librairie de composants logiciels que l'on va utiliser car cela a un impact très important sur la conception. En effet pour utiliser correctement et efficacement une bibliothèque de fonctions il faut être familié avec elle. Ce qui demande un temps d'apprentissage. Les fonctionalités des différentes bibliothèques disponibles doivent être étudiées avec soin. Nous supposerons dans l'exemple que nous utilisons une des bibliothèques standard de composant élémentaires.

Nous développerons plus loin des techniques de fabrication et d'utilisation de composants logiciels. Une des règles est de chercher des associations de connaissance de cardinalité [0..N] qui nous amènent typiquement à des tableaux ou des listes contenant plusieurs références. Soit dans l'exemple entre BaseDeReçu et article. Dépose article crée une instance de BaseDeReçu pour chaque client. BaseDeReçu contient en suite une référence d'article pour chaque type déposé ainsi que le nombre d'article déposé de ce type. Ce qui nous donne une première implémentation du bloc BaseDeReçu. conception.impl1Une première implémentation de basederecu en C++. conception.impl2Une première implémentation de basederecu en Objective C.

Les blocs ainsi identifiés vont correspondre aux modules dans lesquels le code sera inclus. Les blocs permettent de définir les regroupements de sources. Les blocs contiennent du code et des classes. Comme différents clients peuvent demander des configurations différentes, différents blocs peuvent être fournis.

Avant d'implémenter les blocs il faut décrire en détail leurs communications. Ceci est fait en définissant les stimuli qui vont de l'un à l'autre. Une fois l'interface des blocs clairement définie. Nous pouvons les développer indépendement et directement en utilisant les règles d'écriture de notre langage de programmation.