Should I place a built in Class (such as Date) as a separate class in my UML.

Question

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.

Answer 1

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)

Answer 2

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.

Answer 3

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.