Dois-je placer une classe intégrée (telle que Date) dans une classe distincte dans mon UML?

Question

Je crée un diagramme de classes UML pour un système d'inventaire dans le cadre d'une affectation de classe. J'ai utilisé des membres tels que String et Date dans quelques-unes de mes classes. Les membres de mon groupe disent que je devrais inclure une classe Date parce que c'est un objet. Mon hypothèse est que nous utilisions Java ou un autre langage avec un objet Date intégré. Dois-je indiquer explicitement une classe pour Date?

Qu'en est-il de l'objet String?

Quelles autres langues que Java ont un type Date intégré qui peut être utilisé pour développer un client/serveur tel qu'un système d'inventaire.

Answer 1

Les diagrammes UML ne sont pas comme des plans d'architectes; ils sont simplement un moyen de communiquer quelque chose visuellement. Dans votre cas où vous utilisez le type de date dans votre classe, je le listerais simplement comme date. Essayez de garder le plus possible le langage et le cadre hors de vos diagrammes et concentrez-vous sur la fonctionnalité de vos propres cours. Cela maintient le langage/cadre agnostique et plus flexible pour changer.

Rappelez-vous que le changement est inévitable; vous allez apporter beaucoup de changements à votre diagramme de classe au fil du temps. Si vous le rendez trop détaillé et complexe, vous serez plus réticent à le changer et le diagramme deviendra obsolète et inutile.

Le document de conception ultime pour votre application est le code, pas le code UML.

Answer 2

Pour vous cela dépendra de ce que la personne qui marque votre affectation veut que vous devriez demander.

En général, il semble inutile de l'ajouter (sans doute pensé qu'il y a peu de point dans la plupart UML qui obtient produit)

Answer 3

La modélisation est au sujet abstraire des détails sans importance. Donc, cela dépend de la date d'importation dans votre diagramme. Si vous utilisez beaucoup d'objets de cette classe, vous pouvez afficher une dépendance. Si votre diagramme doit être indépendant du langage et que vous avez besoin de fonctionnalités de date, vous pouvez créer une interface dans votre diagramme qui représentera la classe Date. De cette façon, si le modèle créé vous permet de générer votre code pour différentes langues (ce qui pourrait ne pas être si probable ...) il serait facile de créer un adaptateur (motif de conception) qui réalisera votre interface tout ce que Date la langue cible de la mise en œuvre a. Si vous voulez hériter de la classe Date (ou envelopper), vous aurez aussi besoin de la classe Date dans votre diagramme. Si vos diagrammes font partie d'un grand modèle et que vous voulez être sûr des dépendances que vous avez, il peut être utile de créer des interfaces (ou classes) représentant l'infrastructure système/plateforme/bibliothèque sous-jacente et de les placer dans un paquet séparé.