简单来说:你的设计是正确的.您可以"做的是使 Address 成为 Contact 的嵌入类:

如果你愿意，你可以证明它应该被实现为关联数组:

Let's say there is an PHP subsystem which uses only associative arrays to store some kind of structured data. So in fact there is no mechanism on language level to constraint those structures but you want to define them in your design with the UML.

E.g.:

A contact could look like this as an associative array in PHP:

[
  'name' => 'John Doe',
  'birth' => '2000-04-01',
  'email' => 'john.doe@company.com',
  'address' => [
    'street' => '123 Main St',
    'city' => 'Anytown',
    'state' => 'NY',
    'zip' => '1234',
    'country' => 'US'
  ]
]

So I thought an diagram in UML could look like this:

But someone might criticize that this is wrong because it shows two classes and not two associative arrays. So we could use a (custom) stereotype to to show this is not a regular class but which (and how to define them)?

Or to question in more common: What would be the/a right way to define types of such data with the UML?

Simply speaking: your design is correct. What you "could" do is to make Address an embedded class of Contact:

And if you wish so, you could show that it shall be implemented as associative array: