Diagramme de classes UML avec classes domaine et métier

Question

Lorsque nous demandons de dessiner des diagrammes de classes, la plupart des exemples identifient les classes de domaine du système et montrent la relation entre elles. Mais il montre également des méthodes d'affaires à l'intérieur de ces classes de domaine. Normalement, les classes de domaine agissent comme des DTO dans l'application et ne devraient avoir que des champs et le getter et les setters le savent.

Par exemple Doctor est une classe de domaine. Si oui, nous ne pouvons pas avoir la méthode createPrescription() droite? Cette méthode doit être dans une autre classe d'imples métier qui utilise la classe de domaine Doctor droite?

Vérifiez ci-dessous le lien pour un diagramme de classe dessiné.

http://umldiagramtutorial.blogspot.com/2012/10/hospital-management-system-class-diagram.html

Ce que je veux dire, est la classe de domaine Doctor ne devrait pas avoir les méthode plutôt qu'ils devraient être dans DoctorMgtImpl classe. Est-ce correct?

Answer 1

Ceci est plus une question de conception/POO qu'une question UML. Si vous adhérez aux principes SOLID, votre point est correct: ils donnent des responsabilités différentes à un objet (le médecin). De plus, le Doctor n'est pas une abstraction mais une chose très concrète. D'autre part, ce modèle de classe vous donne un aperçu général des entités actives dans le système, de leurs fonctions et de leurs interactions. Ce diagramme peut ensuite être implémenté en utilisant différentes classes (en utilisant MVC, en ajoutant des interfaces, etc.). Le diagramme UML est le point initial de l'implémentation, mais l'implémentation ne doit pas (et la plupart du temps) ne pas être exactement comme indiqué dans le diagramme (car alors pourquoi l'implémenter du tout?

Answer 2

Je suis d'accord avec @vainolo, votre question est uniquement liée à la mise en œuvre. J'ai contribué à un projet dont les entités étaient très similaires à ce hospital management system. Vous pouvez voir les entités principales que nous avons utilisées et nous n'avons pas mis tous les DTO, DAO dans le diagramme de classe de niveau supérieur. Concernant l'implémentation, l'architecture que nous avons adoptée était: classes de modèles de domaine persistants (ex Doctor.java), DAO pour gérer ces classes persistantes avec des opérations CRUD conviviales, une couche de gestion sans état ("managers") utilisant les DAO avec interfaces et implémentations , contrôleurs utilisant les gestionnaires. Il aurait fallu des jours pour modéliser toutes ces classes. Nous avons décidé que le but de vos diagrammes de classes UML n'était pas de représenter le code. Je recommande cette façon de faire :)