我是否应该将内置类（例如日期）作为单独的类放置在我的 UML 中
我正在为库存系统创建 UML 类图，作为类作业的一部分。我在一些类中使用了 String 和 Date 等成员。我的小组成员说我应该包含一个 Date 类，因为它是一个对象。
我的假设是我们使用 Java 或其他带有内置 Date 对象的语言。
我需要明确声明日期类吗？那么 String 对象呢？
除了 Java 之外，还有哪些语言具有内置的 Date 类型，可用于开发客户端/服务器（例如库存系统）。
I'm creating a UML Class Diagram for an inventory system as part of a class assignment. I used members such as String and Date in a few of my Classes. My group members are saying that I should include a Date class because it is an object.
My assumption is that we were using Java or some other language with a built in Date object.
Do I need to explicitly state a class for Date? What about the String object?
What other languages besides Java has a built in Date type that can be used to develop a client/server such as an inventory system.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
UML 图不像建筑师的计划；它们只是一种视觉传达事物的方式。如果您在班级中使用日期类型，我会将其列为日期。
尝试尽可能地将语言和框架排除在图表之外，而只关注您自己的类的功能。这使其与语言/框架无关并且更灵活地进行更改。
请记住，改变是不可避免的；随着时间的推移，您将对类图进行大量更改。如果你把它做得太详细和复杂，你就会更不愿意改变它，并且图表将变得过时且无用。
应用程序的最终设计文档是代码，而不是 UML。
UML diagrams are not like architects plans; they are simply a way of communicating something visually. In your case where you’re using the date type in your class, I would just list it as date.
Try to keep the language and framework out of your diagrams as much as possible and just focus on the functionality of your own classes. This keeps it language/framework agnostic and more flexible to change.
Remember change is inevitable; you will make lots of changes to your class diagram over time. If you make it too detailed and complex you will be more resistant to changing it and the diagram will become out of date and useless.
The ultimate design document for your application is the code, not the UML.
对你来说，这取决于评分你作业的人想要什么，所以你应该问他们。
一般来说，添加它似乎没有什么意义（认为在大多数生成的 UML 中可以说没有什么意义）
For you it will depend on whatever the person marking your assignment wants so you should ask them.
In general there seems little point adding it (thought there is arguably little point in most UML that gets produced)
建模就是抽象出不重要的细节。因此，这取决于日期在图表中的导入方式。如果您大量使用该类的对象，您可能希望显示依赖性。如果您的图表与语言无关并且您需要日期功能，则可以在图表中创建一个代表 Date 类的接口。这样，如果使用您的图表创建的模型将用于生成不同语言的代码（这可能不太可能......），那么创建一个适配器（设计模式）将很容易，它将使用任何日期实现您的界面实现目标语言有。如果您想继承 Date 类（或包装它），那么您的图表中也需要 Date 类。如果您的图表将成为大模型的一部分，并且您想确定拥有哪些依赖项，那么创建表示底层系统/平台/库基础设施的接口（或类）并将它们放入单独的包中可能会很有用。
Modeling is about abstracting unimportant details. So, it depends on how import would Date be in your diagram. If you use heavily objects of that class you might want to show dependency. If your diagram should be language agnostic and you need date functionality, you might create an interface in your diagram which will represent the Date class. This way, if the model created usign your diagram will be used to generate code for different languages(which might not be so likely...) it would be easy to create an Adapter(design pattern) which will realize your interface usign whatever Date implementation target language has. If you want to inherit from Date class (or wrap it), than you will need the Date class as well in your diagram. If your diagrams are going to be a part of a big model and you want to be sure which dependencies you have, it might be useful to create interfaces(or classes) representing underlying system/platform/library infrastructure and put them into separate package.