Principes et conseils : Interface
Rubriques
- Nommez l'interface de façon à refléter le rôle qu'elle joue dans le système.
- Le nom doit être court, 1-2 mots.
- N'intégrez pas le mot "interface" dans le nom ;
cela est impliqué par le type d'élément de modèle (par ex. interface)
- La description doit transmettre les responsabilités de l'interface.
- La description doit comporter plusieurs phrases, voire former un paragraphe court.
- La description ne doit pas seulement reprendre le nom de l'interface, elle doit éclairer sur le rôle que l'interface joue dans le système.
- Les noms d'opération doivent refléter le résultat de l'opération.
- Lorsqu'une opération définit ou obtient des
informations, inclure définir ou obtenir dans le nom de l'opération est redondant. Donnez à l'opération le même nom que la propriété de l'élément de modèle qui est défini ou extrait. Une opération ainsi nommée, sans paramètres, extrait la propriété ; une opération ainsi nommée avec un paramètre définit la propriété.
Exemple
nom() renvoie le nom de l'objet ; nom(uneChaîne) définit le nom de l'objet sur uneChaîne.
- La description de l'opération doit décrire ce que fait l'opération, y compris les éventuels algorithmes clés, et quelle valeur il renvoie.
- Nommez les paramètres de l'opération pour indiquer quelle information est transmise à l'opération.
- Identifiez le type du paramètre.
Le comportement défini par l'interface est spécifié comme un ensemble d'Opérations.
Des informations supplémentaires peuvent avoir besoin d'être transmises :
- Comment les opérations sont utilisées et l'ordre dans lequel elles sont exécutées (illustré par des diageammes d'exemples de séquences).
- Les éventuels états observables de l'extérieur dans lesquels peut être un élément de modèle qui réalise l'interface (illustrés par un machine d'état, voir Principes et conseils :
Pattern d'état).
- Les plans et scripts de test qui testent le comportement de tout élément de modèle qui réalise l'interface.
Afin de grouper et gérer ces informations, un package doit être créé pour contenir l'interface et tous les artefacts en rapport.
Chaque interface représente une 'jonction' dans le système : un endroit où le système peut être "décomposé" puis reconstruit ou reconçu. Les interfaces représentent la séparation entre la spécification et la conception ou l'implémentation. Interfaces bien structurées :
- sont simples mais complètes, fournissant toutes les opérations nécessaires mais suffisantes pour spécifier un seul service
- sont compréhensibles, fournissant les informations suffisantes pour utiliser et réaliser l'interface sans avoir à examiner une utilisation ou une implémentation existante
- sont abordables, fournissant les informations pour guider l'utilisation vers ses propriétés clés sans être submergé de détails sur les opérations
Lorsque vous dessinez une interface,
- utilisez la notation en "sucette" chaque fois que vous devez simplifier la présente d'une jonction dans le système. Le plus souvent, vous aurez besoin de cela pour les sous-systèmes mais pas les classes.
- Utilisez la notation de "classe" étendu quand vous devez présenter les détails du service lui-même. Le plus souvent, vous aurez besoin de cela pour spécifier les services offerts par un package ou sous-système.
| |
|