Comment modéliser la gestion des utilisateurs en utilisant un diagramme de classe UML?
J'ai un projet d'école où moi et mon équipe doivent construire un système de santé. Il se compose de différents modules, notamment:
n module pour les médecins : Il permet à un médecin d'accéder aux dossiers médicaux de ses patients, de leur envoyer des indications, consultez son agenda ...
n module pour les patients : Un patient peut prendre rendez-vous avec son médecin, signaler une urgence ou envoyer des indicateurs (niveau de glycémie, poids, pression artérielle). Il existe trois types de patients qui doivent être pris en charge par le système: les femmes avec une grossesse risquée, des diabétiques et des personnes souffrant d'Alzheimer. Ces derniers sont assistés par des personnes de leur famille ou de leur personnel médical.
n module de transport : Pour affecter et envoyer une ambulance à l'emplacement où un patient a signalé une urgence.
En essayant de modéliser la solution via un diagramme de classe UML (qui est en fait un document dû au projet), nous avons rencontré trois problèmes/dilemmes:
- Comment modéliser un patient?
Notre première pensée était de créer un tilisateur classe à partir de laquelle hériter les autres classes comme celle-ci:
.
Mais cela ne permettrait pas à un patient d'être enceinte et diabétique par exemple. Qui est gênant.
Après avoir recherché sur Internet, nous avons découvert du contrôle d'accès basé sur des rôles, nous ne l'avons pas approché, car nous pensions qu'il était destiné à la gestion et aux autorisations de compte, et non des affaires liées aux entreprises comme un patient ayant des rôles différents (diabétiques et enceintes pour Exemple).
Nous avons finalement accepté de créer une classe de pathologie et en ajoutant une liste de pathologies pour chaque patient. Cela viole-t-il un bon principe de conception? Y a-t-il un moyen standard ou meilleur de faire cela?
Un autre problème similaire apparaît avec l'assistant. Comme il peut être membre de la famille du patient ou du personnel médical, nous l'aurions toujours tomber dans la catégorie assistant classe sous tilisateur ou dans le MedicalAssistant classe sous -médicalstaff. Mais je pense que c'est le même problème que pour les pathologies du patient.
- Comment modéliser un assistant?
Encore une fois avec l'assistant, il est ici pour aider un patient souffrant d'Alzheimer: il fait des rendez-vous sur le médecin et est notifié s'il eurent trop loin (nous avons inclus un bracelet portable équipé d'un GPS dans la solution). Cela a suscité la question de la redondance depuis que nous avons des cours assistant et patient qui implémente la méthode Makeapment (médecin, date) . Cela a soulevé deux possibilités:
-si cette méthode est à la place de cette méthode?
-devrions-nous avoir une interface IAPPoindy contenant la méthode?
Personnellement, je pense que la méthode doit être déplacée vers la classe médecin (peut-être que ceci est même une base OOP chose).
- Comment représenter MVC?
Nous allons faire un site Web et une application mobile prenant en charge le système. Nous avons pensé à utiliser ASP.NET pour avoir une main dessus et apprenez à connaître le modèle de conception MVC. Après un peu de documentation (principalement à partir du "MVC in PHP" de Tom Butler et "Architectures d'interface graphique de Martin Fowler (à la fois sur leurs sites Web), nous sommes venus nous demander si Les couches de contrôleur et d'affichage doivent être représentées dans un diagramme de classe comme celui-ci:
.
Nous avons trouvé cet article sur Stackoverflow qui pose une question similaire:
Comment créer des diagrammes de classe UML pour MVC
Il est indiqué que seuls les modèles (classes liées aux entreprises) devraient être représentés. Mais est-ce une règle générale? Si le contrôleur et les classes de vue soient représentées? Comment se traduire dans un diagramme de séquence?
Je suis désolé pour le post étant si longtemps et les questions assez hétérogènes. Merci d'avance pour toute aide, conseils ou remarques que vous pourriez nous donner.
1. Comment modéliser un patient?
Votre conception, avec son Account, User, et les différents dérivés des utilisateurs sont déjà un bon départ.
Le Patient pourrait en effet être un type spécial de User. Cependant, le Patientest non aDiabetic, Alzheimer ou Pregnant. Il/elle a une pathologie comme Diabetes ou Alzheimer ou un état comme Pregnant. Il/elle peut même avoir plusieurs pathologies en même temps. Par conséquent, je recommande vivement d'aller pour une association d'un Patient avec un ou plusieurs Pathologies. Utilisez donc le principe de Composition sur héritage.
Comme vous êtes venu à cette orientation par vous-même, je ne peux que confirmer que vous êtes un le bon sens.
Comment modéliser un assistant?
L'assistant est ((( proxy pour un Patient, au moins au sens de l'entreprise. Il ne prend pas de rendez-vous pour lui-même: il prend rendez-vous au nom d'un patient. D'autres patients peuvent faire leurs rendez-vous eux-mêmes.
Donc, la méthode de prise de rendez-vous doit être proposée par le Doctor (ou plus précisément, par le calendrier du médecin). Mais cela ne s'oppose pas à aussi avoir une MakeAppointment() sur le Assistant, qui transmettra l'appel au Doctor.
Et au fait, un patient a également un calendrier: vous ne devriez pas en principe faire 2 rendez-vous en même temps pour le même patient. Cela apporte à un autre approche: vous pouvez très bien voir MakeAppointment en tant que "Script de transaction" , qui vérifie si le calendrier de médecin et de patient est gratuit à une date donnée. Il est temps, puis ouvre la nomination sur le calendrier du médecin, puis le livre sur le calendrier du patient.
. Comment représenter MVC?
En fait, cela dépend du but de votre diagramme UML.
S'il s'agit d'un modèle de domaine , il ne doit que contenir uniquement les objets de domaine (par exemple, patients, médecins, utilisateurs) et sans contrôleurs ou vues, qui ne ferait que rendre le modèle plus difficile à comprendre.
Toutefois, s'il s'agit d'un modèle de mise en œuvre, vous pouvez montrer quelle que soit la classe dont vous avez besoin pour construire votre logiciel, y compris les contrôleurs et les vues.
plus sur le modèle de rôle
Pour revenir sur le modèle, le problème décrit sur Pathology existe également dans la réalité pour d'autres rôles. Par exemple, un médecin pourrait aussi bien être un patient, s'il brise sa jambe.
Donc, un utilisateur pourrait avoir plusieurs rôles. Cela appellerait de la même manière à une conception de composition: le User supporterait l'identité et chaque utilisateur pourrait avoir plusieurs rôles. Vous devez alors penser à quels attributs sont généraux et appartiennent à l'utilisateur et lesquels sont spécifiques à un rôle.