UML Domine el lenguaje de modelado más utilizado en la actualidad

6. MODELAR LASACCIONES De cada uno de los objetos se desprende una línea discontinua que representa el paso del tiempo y constituye la otra gran sección de los diagramas de secuencia. La comunicación o intercambio de mensajes se refleja a través de una flecha dirigida que marca el sentido de la comunicación. Cada flecha es etiquetada con el nombre del mensaje, el cual se corresponde con un método definido en un objeto de nuestro sistema. Cada flecha que llega a un objeto simboliza la invo­ cación de un método de esa clase. Por ejemplo, en la figura 7 de la página ante­ rior vemos que se invocan varios métodos de la clase Cafetera: en el paso tres se invoca un método para agregar café, en el paso siguiente se invoca un método para agregar agua, mientras que finalmente en el paso 6 es invocado el método encargado de preparar el café. Similarmente, cada flecha que sale de un objeto no es otra cosa que la invocación a un método. Los métodos para agregar café y agua son invocados desde la clase Encargado, mientras que el método para pre­ parar el café es invocado desde la propia clase Cafetera. Existen diferentes tipos de mensaje. Los más comunes son los que representan invocaciones de métodos, pero también hay otros que crean objetos o que des­ truyen objetos, entre otros. Cada tipo de mensaje es mostrado gráficamente de diferente forma, de manera tal de poder transmitir únicamente con el modelo toda la información posible acerca del comportamiento del sistema. Las entidades que intervienen en un diagrama de secuencia no son clases, sino instancias de clases. Como estamos modelando un comportamiento en particu­ lar, es decir, una instancia concreta de ejecución, los elementos que intervienen son los objetos en sí, y no el concepto general de clase. Sincronizar los modelos Como vimos en la sección anterior, cuando en un diagrama de clases una flecha arriba a un determinado objeto, implica que un método de ese objeto está sien­ do invocado. Es importante entonces verificar que el método en cuestión esté definido en la especificación estática de la clase. Como siempre, el mecanismo sugerido de trabajo es ir desde la descripción está­ tica hacia la dinámica, y no el camino inverso. Cuando en un diagrama de secuencia queramos invocar un método que no forma parte de la descripción estática del objeto, lo que deberemos hacer primero será modificar el diagrama de clases correspondiente para agregarlo y, recién después, usarlo en el diagrama de secuencias. De esta forma, nos aseguramos de que cuando un método sea invocado, esté correctamente definido y especificado. Cómo vemos, los distintos modelos interactúan entre sí, dependen unos de otros y el comportamiento de cada uno puede impactar en los demás. Por esto, es impor­ tante que todos nuestros modelos estén sincronizados correctamente entre sí. En el caso de los diagramas de secuencia, debemos controlar los siguientes aspectos, ya que utilizar estas heurísticas nos ayudará a mantener sincronizados los modelos: 180