Modelos de diseño y tipo de visibilidad entre clases

Jorge Rodríguez
PDSW-01
08/03/2011

1. Modelos de diseño: Determinando visibilidad
Los diseños creados para los eventos del sistema ilustran los mensajes entre objetos. Para un objeto emisor que envía un mensaje a un objeto receptor, el emisor debe estar visible para el receptor y el emisor debe tener algún tipo de referencia o puntero al objeto receptor. La visibilidad es la habilidadpara “ver” o tener la referencia a otro objeto. Comúnmente la visibilidad entre un objeto A y un objeto B se puede denotar de cuatro formas:
* Visibilidad de Atributo: B es un atributo de A
* Visibilidad de parámetro: B es un parámetro de un método de A
* Visibilidad Local: B es un objeto local en un método de A
* Visibilidad global: B es de alguna manera globalmente visible
Laprogramación orientada a objetos cuenta con varios tipos de visibilidad, entre los más comunes están:
La visibilidad de atributos desde A hasta B existe cuando B es un atributo de A y es relativamente permanente siempre que A y B existan.
La visibilidad de parámetros desde A hasta B existe cuando B es pasado como parámetro a un método de A y es relativamente temporal porque persiste sólo en elámbito de aplicación del método.
La visibilidad local desde A hasta B existe cuando B se declara como un objeto local dentro de un método de A. Se trata de una visibilidad relativamente temporal porque persiste sólo en el ámbito de aplicación del método.
Dos medios comunes por los cuales se logra la visibilidad local son: Crear una nueva instancia local y asignarla a una variable local o asignar elobjeto que devuelve al invocar un meto y asignarlo a una variable local.
La visibilidad global desde A hasta B existe cuando B es global para A y se trata de una visibilidad relativamente permanente porque persiste mientras que A y B existen.
Finalmente es importante decir que UML tiene una notación para ilustra la visibilidad, pero son opcionales y normalmente no son llamados a menos que hayanecesidad de ser claros.

2. Modelos de diseño: creando diseños de diagramas de clases
La presentación de DDC sigue la creación de los diagramas de interacción en la práctica son usualmente creados en paralelo. Normalmente algunas clases, métodos y relaciones pueden ser bosquejados tempranamente en el diseño aplicando los patrones de asignamiento de responsabilidad, pero es importanterealizar estos diagramas y entonces actualizar los DDC, luego extender los diagramas de interacción.
Un diseño de diagrama ilustra especificaciones para las clases software e interfaces y normalmente incluye: las clases, asociaciones y atributos, las interfaces (con sus operaciones y constantes), métodos, tipos de atributos, navegabilidad y dependencias. Todo esto muestra las definiciones para lasclases software de una forma más asociada al mundo real.
Ya que el PU no define un diseño de diagrama de clases si define un modelo de diseño, los cuales incluyen más características al expresar la definición de las clases como componentes de software (modelo de dominio: clases conceptos, Modelo de diseño: clases como software).
En cuanto a los pasos de DDC como parte de un modelo de solución delsoftware, estas pueden ser encontradas revisando todos los diagramas de interacción y listando las clases mencionadas, el segundo paso es dibujar un diagrama de clases incluyendo los atributos previamente identificados. A la hora de añadir los nombres a los métodos el texto nos sugiere que pueden ser identificados analizando los diagramas de interacción, hablando en general el conjunto de todos losmensajes enviados a cierta clase por medio de todos los diagramas de interacción indica la mayoría de métodos que esa clase debe definir. Los tópicos de los nombres de los métodos se limitan a la interpretación de los creadores, la descripción de los métodos de acceso, la interpretación de los mensajes multiobjetos, la sintaxis del lenguaje independiente… en cuanto al primero, el creador indica...