In Computer Science/Object Oriented Programming terminology, there are two types of relationships that are defined:
“Is a” relationship. This would refer to inheritance, and “type” of a particular object.
“Has a” relationship. This refers to properties that an object contains
It is for this reason the address variable would be referred to as a “has a” relationship. Moreover, these terms are quite old, and very generic, so they predate Optionals. I believe the term “delegates to” is an incorrect reference to this property, since “delegate” has a very specific meaning in iOS.
The class HAS an address property. Whether it actually USES it (because it is nil) is another matter. The fact that a property can be optional should not negate the fact that it is a property belonging to a particular class. An example would be a bank account that belongs to an individual. This bank account is allowed to carry an amount of $0.00. The fact that the account is allowed to have no money does not negate the fact that it is still a bank account, which belongs to a particular person.
All in all, the reply from @syedfa is pretty spot on! Specifically,
It doesn’t matter whether the property is optional. If a class “has a” strong property (see note later about “uses” for weak), you nearly always show this as a solid, “has a” line.
By the way, this IS a strong reference, but it’s an optional type. That is, AddressViewController owns an Address, but it may not yet be set and be nil instead.
There is a “uses” relationship too — shown as a dashed line with solid pointer — but this often is used to indicate either (1) the relationship is to a weak property or (2) there isn’t a property relationship but rather it’s a type that’s “used,” such as a method input parameter but not held onto.
Since there is ambiguity, “uses” relationships are typically annotated for what they mean, via text next to the line.