クラス課題の一環として、在庫システムの UML クラス図を作成しています。いくつかのクラスで String や Date などのメンバーを使用しました。私のグループ メンバーは、オブジェクトなので Date クラスを含めるべきだと言っています。
私の推測では、Java や Date オブジェクトが組み込まれた他の言語を使用していたと思います。
Date のクラスを明示的に指定する必要がありますか? String オブジェクトはどうでしょうか。
Java 以外に、在庫システムなどのクライアント/サーバーの開発に使用できる日付型が組み込まれている言語はありますか。
UML ダイアグラムは建築家の計画とは異なります。それらは単に何かを視覚的に伝える方法です。クラスで日付型を使用している場合は、日付としてリストします。
言語とフレームワークをできるだけダイアグラムから除外し、独自のクラスの機能だけに集中してください。これにより、言語/フレームワークにとらわれず、より柔軟に変更できます。
変化は避けられないことを忘れないでください。時間の経過とともに、クラス図に多くの変更を加えるでしょう。あまりにも詳細で複雑にすると、それを変更することに抵抗が増し、ダイアグラムは時代遅れになり役に立たなくなります。
アプリケーションの最終的な設計ドキュメントはコードであり、UML ではありません。
あなたにとって、それはあなたの割り当てをマークする人が望むものに依存するので、あなたは彼らに尋ねるべきです。
一般に、それを追加する意味はほとんどないようです（生成されるほとんどのUMLにはおそらくほとんど意味がないと考えられています）
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.