Comment puis-je déterminer les attributs et les opérations dont une classe sera responsable dans un diagramme de classes de conception?

Question

Je suis en train de créer un diagramme de classes de conception basée sur le cas d'utilisation ci-dessous:

Préalables: L'utilisateur est connecté

1. Le système présente la liste des demandes de remboursement qui ont été autorisées pour le paiement.
2. L'utilisateur sélectionne une demande de remboursement dans la liste.
3. Le système affiche tous les éléments enregistrés en dessous.
4. L'utilisateur sélectionne l'une des deux options suivantes: (a) pour confirmer la demande de paiement, ou (b) pour revoir plus loin.
5. option IF (a) est sélectionné,

5.1 Le système enregistre la confirmation du paiement et notifie les comptes département.

AUTRE 5.2 Ne rallongez examen des demandes de

END IF

Comment puis-je décider quelle classe (entre le compte et le système) est responsable de quels attributs et les opérations? Est-ce que je décide en fonction de ma propre interprétation ou y a-t-il une méthode établie?

C'est ce que j'ai jusqu'à présent: design class diagram

Answer 1

Conception d'un diagramme de classes est généralement quelque chose qui est ouvert à l'interprétation de la personne qui en fait. Je ne suis pas sûr des autres méthodes possibles, mais voici comment j'aborde ce problème:

1. Identifiez les types d'objets (c'est-à-dire les classes) qui existent dans le scénario. Ce sont des éléments individuels qui existent dans votre scénario (par exemple, Utilisateur, ExpenseClaim, ExpenseItem). Une bonne pratique pour identifier ceux-ci sont des éléments qui ont généralement des éléments de données (c'est-à-dire des propriétés) ou remplissent une fonction (c'est-à-dire des méthodes). En général, vous pouvez vous tromper en identifiant autant de choses que possible car l'idée est que chaque classe est censée faire une chose spécifique et pas plus que cela (vous allez probablement réviser ceci en effectuant les étapes suivantes) . Cependant, ne confondez pas les objets avec les acteurs - le système est en réalité ce que le diagramme de la classe entière explique, donc il ne devrait jamais être considéré comme une classe.
2. Pour chaque type d'objet, examinez les données qu'ils contiennent et traduisez-les en propriétés ou en relations avec d'autres types d'objet. Vraiment essayer et limiter la quantité de données que chaque objet a; Si un objet a beaucoup de propriétés, il est probablement prêt à le diviser en plusieurs objets. Prenant l'exemple de ExpenseClaim et ExpenseItem, il est clair que chaque ExpenseClaim a une liste de ExpenseItem, vous pouvez donc les lier avec une flèche de composition. Maintenant, observez chacun et pensez aux choses que les autres objets pourraient essayer de faire pour changer les données de l'objet - ce seront probablement vos méthodes. Pour un objet ExpenseClaim, il aura probablement une méthode confirm() pour changer l'état d'une propriété isConfirmed :: boolean. Encore une fois, essayez vraiment de limiter la quantité de fonctionnalités au rôle spécifique joué par l'objet - si un objet a trop de fonctions ou une fonction qui ne lui convient pas vraiment, cela signifie probablement qu'il y a un autre objet (nouveau) convient mieux.