Création d'un diagramme de classes UML pour le système d'entrée?

Question

Je regarde le système d'entrée d'une salle d'escalade. Le client entre dans le bâtiment, donne ses coordonnées à la réceptionniste, la réceptionniste entre les détails dans la base de données, vérifie les détails, la réceptionniste prend un paiement si le client n'est pas un membre et le client procède à l'intérieur.

J'ai quatre classes: client, réceptionniste, administrateur, base de données. J'ai non-membre et membre généralisé sous le client. il existe une relation plusieurs à un entre client et réceptionniste (beaucoup à la fin du client). un à un relation entre réceptionniste et base de données. un à un relation entre réceptionniste et administrateur.

sont corrects mes classes et relations?

Answer 1

ce n'est pas facile de répondre. Vous parlez de classes, donc je suppose que vous créez un diagramme de classes. Si c'est le cas, je ne suis pas sûr d'inclure une classe de réceptionniste (du moins pas pour ce cas d'utilisation). Une réceptionniste peut exister dans un diagramme de flux de données. Dans un diagramme de classes, une classe de réceptionniste peut exister dans le cadre d'un roulement de personnel ou d'un processus de paiement du personnel. Dans le système d'entrée, du point de vue de la programmation, comment votre classe de clients interagit-elle avec la classe des réceptionnistes? Quelles méthodes la classe de réceptionniste contient-elle pour cette interaction? Je suppose que non, la réceptionniste humaine réelle interagit avec le client de la vie réelle, mais la classe de clients n'interagirait pas avec la classe réceptionniste, sauf si vous étiez en train de journaliser quel réceptionniste a traité la transaction.

Même dans cette situation, je suppose que ce serait une autre classe qui gère cette action.

Si vous ne faites que cartographier les interactions entre de vraies personnes, je dirais que beaucoup de clients pourraient être servis par de nombreuses réceptionnistes. Je suppose qu'ils en emploient plus d'un.

Answer 2

Alors voici mes observations:

• Tous les attributs/opérations doivent commencer par une lettre minuscule (et que vous avez fait toutes les classes avec une majuscule). Ceci est une convention commune adoptée dans la liste de toutes les langues que je connais (qui n'est certainement pas complète, mais il est plus d'un ou deux)
• Vous utilisez la composition partagée avec Member et Non-Member. Il semble plutôt que cela devrait être une relation de généralisation. Donc, vous devez utiliser le triangle et non rempli à la place du diamant.
• Vous devez utiliser des noms de rôle avec les associations. C'est-à-dire que vous devriez noter administrator vers la classe Administrator. Cela en fera un attribut administrator de type Administrator à l'intérieur Receptionist.
• Vous ne devez pas définir les attributs ID dans un brouillon/modèle d'entreprise. L'ID est généralement dérivé lors de la compilation ultérieure de l'adresse de l'objet. Donc, vous référencez l'objet en soi, pas un ID. Il existe une relation entre Receptionist et Database. Je ne pense pas que ce soit une décision de conception sage ici. On ne sait pas à quoi la base de données sera utilisée. Probablement chaque classe sera en quelque sorte reflétée dans une base de données. Donc, à la place, ces classes devraient implémenter une interface Serializable qui permet de les mettre en miroir dans une base de données. Avoir Database comme classe dans un modèle d'entreprise n'est pas correct. Concentrez-vous sur les objets métier et implémentez une couche de persistance à un stade ultérieur.
• De votre description, je ne vois pas où le Administrator entre. Il semble assez paranoïaque d'avoir un administrateur par réceptionniste.