creo que en algunos casos los encabezados de Objective-C llevan menos información general, pero pueden mostrar las interfaces con mayor claridad.
Por ejemplo, utilizando los tiempos de ejecución modernos de Objective-C (para Mac OS e iOS) no es necesario declarar iVars privados o métodos privados en los encabezados; se pueden cambiar a una categoría en el archivo de implementación. Incluso puede redeclarar propiedades como readwrite en la implementación donde se declaran como readonly en el archivo de encabezado.
Esto significa que hay mucho más en juego en una clase de lo que se muestra en los archivos de encabezado, pero las interfaces públicas están claramente definidas por separado de la implementación privada, lo cual es bueno en un diagrama UML.
En cuanto a los nombres largos de métodos, eso es parte de la convención de Objective-C. Puede amarlo o detestarlo (personalmente lo amo). Pero en términos de escribirlos, los métodos no muestran sus parámetros. Por ejemplo: supongamos que tiene un método declarado como:
- (NSString *)resultStringWithOptions:(NSDictionary *)options withCharacterSet(NSCharacterSet *)charSet error:(NSError **)error:
El nombre real de este método es:
resultStringWithOptions:withCharacterSet:error:
que es más corto.
Tiene sentido, sin embargo, los diagramas de clase pueden ser confusos y, a veces, se deben incluir tipos para ayudar a dar claridad sobre la funcionalidad y la arquitectura de un sistema. En cuyo caso, el nombre del método se vuelve mucho más largo, especialmente para los métodos con más de 2 argumentos. – user559142