-
Nommer l'interface de manière à refléter le rôle qu'elle joue dans le système.
-
Le nom doit être court, 1 ou 2 mots.
-
N'utilisez pas le mot "interface" dans le nom ; il est sous-entendu par le type d'élément de modèle (ex.
interface)
-
La description doit contenir les responsabilités de l'interface.
-
La taille de la description doit correspondre à un petit paragraphe.
-
La description ne doit pas simplement réitérer le nom de l'interface, elle doit éclairer sur le rôle que joue
l'interface dans le système.
-
Les noms donnés aux opérations doivent refléter les résultats de l'opération.
-
Lorsqu'une opération donne ou recueille des informations, il n'est pas nécessaire de répéter
donner ou obtenir dans le nom pour éviter la répétition. Donnez à l'opération le même nom qu'à la
propriété de l'élément de modèle qui est installé ou extrait. Une opération nommée de cette façon, sans paramètres,
récupère la propriété tandis qu'une opération nommée de cette façon (avec un paramètre) configure la
propriété.
Exemple
name() renvoie au nom de l'objet ; name(aString) fixe le nom de l'objet à aString.
-
La description de l'opération doit décrire en quoi consiste l'opération, y compris tout algorithme clé, et
quelle valeur elle a pour résultat.
-
Nommer les paramètres de l'opération pour indiquer quelle information est passée à l'opération.
-
Identifier le type de paramètre.
Le comportement défini par l'interface est spécifié en tant qu'ensemble d'opérations. Il peut s'avérer nécessaire de
faire passer des informations supplémentaires :
-
Comment les opérations sont-elles utilisées et dans quel ordre sont-elles exécutées (illustration dans des exemples
de diagrammes de séquence).
-
Les états éventuellement observables de l'extérieur dans lesquels un élément de modèle qui réalise l'interface est
susceptible de se trouver (illustrés par une machine d'état, voir Instructions : Diagramme état-transition).
-
Tester les plans et les scripts qui testent le comportement de n'importe quel élément de modèle qui réalise
l'interface.
Afin de grouper et de gérer ces informations, il faudrait créer un package qui contienne l'interface et les produits
qui lui sont associés.
Chaque interface représente une "couture" dans le système : un espace où le système peut être "démonté" puis
reconstruit ou re-conçu. Les interfaces représentent la séparation entre la spécification et la conception ou
l'implémentation. Les interfaces bien structurées :
-
sont simples mais complètes, fournissant toutes les opérations nécessaires, et suffisantes pour préciser un service
unique
-
sont compréhensibles, fournissant des informations suffisantes à l'utilisation et à la réalisation de l'interface
sans devoir examiner une utilisation ou une implémentation existante
-
sont faciles d'accès, fournissant des informations pour guider l'utilisateur vers ses propriétés clés sans être
submergé par les détails des opérations
Lorsque vous dessinez une interface,
-
utilisez la notation "sucette" chaque fois que vous devez simplement spécifier la présence d'une couture dans le
système. Vous en aurez le plus souvent besoin pour les sous-systèmes mais pas les classes.
-
Utilisez la notation "classe" étendue lorsque vous devez présenter les détails du service lui-même. Vous en aurez
le plus souvent besoin pour spécifier les services offerts par un package ou un sous-système.
|