Sembra che ci sia una soluzione semplice a questa confusione: le frecce in questi diagrammi non sono accurate per quanto riguarda la loro destinazione. Tutti indicano cose diverse quando le guardi esattamente. Alcuni puntano alla proprietà con il modificatore di visibilità, alcuni con l'altra operazione, altri con la classe stessa. Tuttavia, l'intenzione dell'autore sembra essere che ognuno di questi riguarda l'accesso al campo con l'interessante modificatore di visibilità.
In breve: #creationDate è accessibile dalla classe derivata, ma -name non lo è. Certo, l'autore potrebbe aver fatto più attenzione qui per evitare questa confusione.
Una piccola estensione sulla semantica attuale di questo. Quando dai un'occhiata alla specifica della sovrastruttura UML a pagina 141 vedrai il diversi tipi di visibilità e la loro semantica specificata. Un altro post su SO mostra dove guardare nell'SSS per scoprire che la visibilità predefinita (se nulla è scritto di fronte all'operazione) è pubblico. (Sì, l'SSS è una bestia difficile da leggere .. dovresti imparare a leggere quel documento prima di leggerlo effettivamente).
Solo per riferimento, qui ci sono le semantiche concrete definite nell'SSS di UML:
- A public element is visible to all elements that can access the contents of the namespace that owns it.
- A private element is only visible inside the namespace that owns it.
- A protected element is visible to elements that have a generalization relationship to the namespace that owns it.
- A package element is owned by a namespace that is not a package, and is visible to elements that are in the same package as its owning
namespace. Only named elements that are not owned by packages can be
marked as having package visibility. Any element marked as having
package visibility is visible to all elements within the nearest
enclosing package (given that other owning elements have proper
visibility). Outside the nearest enclosing package, an element marked
as having package visibility is not visible.
