Completando los diagramas de interacción, es posible identificar la especificación de las clases que participarán en la solución indicando detalles de su implementación, como por ejemplo los métodos. Entradas de los Diagramas de Clases 1. Diagramas de interacción, a partir de ellos se identifica las clases de software y sus métodos. 2. Modelo conceptual, a partir de éste se agrega detalle a la definición de las clases. Características Un diagrama de clases (DCD) representa las especificaciones de las clases e interfaces de software (por ejemplo, las interfaces de java) en una aplicación. Entre la información general que entregan se encuentran: Clases, asociaciones y atributos. Interfaces con sus operaciones y constantes. Información acerca del tipo de los atributos. Métodos. Navegabilidad. Dependencias. Modelo de Dominio vs Modelo de Diseño En el modelo de dominio, una Venta no representa una definición de software, sino que se trata de una abstracción de un concepto del mundo real acerca del cual estamos interesados en realizar una declaración. En cambio, los DCD expresan (para la aplicación de software) la definición de las clases como componentes de software. 1
Identificación y representación de las clases de software El primer paso de los DCD como parte del modelo de la solución es identificar aquellas clases que participan en la solución software. Se pueden encontrar examinando todos los diagramas de interacción y listando las clases que se mencionan. El siguiente paso es dibujar un diagrama de clases para estas clases e incluir los atributos que se identificaron previamente en el modelo del dominio que también se utilizan en el Diseño. Añadir los nombres de los métodos. Se pueden identificar los nombres de los métodos analizando los diagramas de interacción. En general, el conjunto de todos los mensajes enviados a una clase X a lo largo de todos los diagramas de interacción indican la mayoría de los métodos que debe definir la clase X. Venta Fecha escompleta: Boolean Hora CrearLineaDeVenta( ) :Registro 2: CrearLineaDeVenta(espec, cant) :Venta 2
Añadir los nombres de los métodos. Se deben tener en cuenta los siguientes aspectos especiales respecto a los nombres de los métodos. Interpretación del mensaje create(): Por ser la inicialización una actividad muy común, se acostumbra a omitir los métodos de creación. Se supone por default. Descripción de los métodos de acceso: Son aquellos que establecen o recuperan el valor de los atributos. Implican un accesor (de obtención) y un mutador (de cambio) para cada atributo. Por su amplia utilización se omiten. Se suponen por defecto. Se deben tener en cuenta los siguientes aspectos especiales respecto a los nombres de los métodos: Interpretación de los mensajes dirigidos a multiobjetos: Un mensaje a un multiobjeto se interpreta como si estuviera destinado al objeto contenedor /colección. Estas clases contenedor/colección son clases predefinidas de las bibliotecas, y rara vez sirve mostrarlas explícitamente en el diagrama respectivo porque incorpora ruido y aportan escasa información nueva. 3
:Venta 1*: st:=getsubtotal( ) :LineaDeVenta El mensaje getsubtotal( ) está destinado al objeto contenedor, no a una LineaDeVenta Añadir los nombres de los métodos. Es opcional mostrar el tipo de los atributos, los parámetros del método y los valores de devolver método. El diagrama de clases orientado al diseño debería elaborarse teniendo en cuenta la audiencia: Si vamos a crearlo con una herramienta CASE con generación automática de código se requerirán detalles completos y exhaustivos. Si vamos a crearlo para los diseñadores de software, el exceso de información puede influir negativamente en su efectiva comprensión. 4
Incorporación de asociaciones y navegabilidad. Cada extremo de la asociación se denomina Rol, y en los DCD el Rol podría decorarse con una flecha de navegabilidad. Navegabilidad: propiedad del rol que indica posibilidad de navegar unidireccionalmente a través de la asociación desde los objetos de la clase origen a la clase destino. La navegabilidad implica visibilidad normalmente visibilidad de atributo. Es necesario definir una asociación con una flecha de navegabilidad de A a B cuando: A envía un mensaje a B - A crea una instancia de B - A necesita mantener una conexión con B. La mayoría, por no decir todas, las asociaciones en los DCD deberían adornarse con las flechas de navegabilidad necesarias. Añadir relaciones de dependencia. UML incluye una relación de dependencia general, que indica que un elemento (de cualquier tipo, como clases, casos de uso, etc.) tiene conocimiento de otro elemento. Se representa mediante una flecha de línea punteada. En los diagramas de clase la relación de dependencia es útil para describir la visibilidad entre clases que no es de atributo; en otras palabras, la declaración de visibilidad de parámetros, local y global. 5
1. RESPONSABILIDADES. Una responsabilidad es un contrato o una obligación de una clase. Al modelar clases, un buen comienzo consiste en especificar las responsabilidades de los elementos. Una clase bien estructurada tiene al menos una responsabilidad (debería tener pocas). Gráficamente, las responsabilidades se expresan en una sección al final de la clase. Por ejemplo: 2. USO DE CLASES. Modelar la distribución de responsabilidades: Para modelar la distribución de responsabilidades en un sistema, hay que identificar un conjunto de clases que colaboren entre ellas para llevar a cabo algún comportamiento. Luego hay que identificar el conjunto de responsabilidades para cada clase. Por ejemplo: Observe cómo estas clases colaboran de forma que ninguna clase hace mucho ni muy poco. 6
3. RELACIONES. Las clases casi nunca se encuentran aisladas. Por lo general la mayoría de ellas colaboran con otras de varias maneras. Por tanto, al modelar un sistema también hay que modelar la forma en que las clases se relacionan. Las relaciones constituyen el camino para que se comuniquen los objetos. Se examinan los diagramas de interacción para determinar qué tipo de relación entre objetos tiene que existir para que pueda darse el comportamiento deseado Si 2 objetos necesitan comunicarse, debe haber una relación entre ellos. En el modelado orientado a objetos hay tres tipos de relaciones: dependencias, generalizaciones y asociaciones. 7
Una generalización conecta una clase general (llamada superclase o padre) con otra clase más especializada (llamada subclase o hijo). Es una relación "es-un" o "es-una". Por ejemplo, el CuadroDialogo es una Ventana. Las asociaciones son relaciones estructurales entre instancias, que especifican que los objetos de un elemento están conectados con los objetos de otro. Es legal que los objetos de una clase estén conectados con objetos de la misma clase. Hay cuatro tipos de ADORNOS" que se le pueden poner a estas relaciones: nombre, rol, multiplicidad y agregación. Ejemplo: Nombre: Una asociación puede tener un nombre, que se utiliza para describir la naturaleza de la relación. Para evitar ambigüedades, se puede indicar una dirección al nombre, es decir, la dirección en que se debe leer el nombre. Rol: Un rol es la cara que la clase de un extremo de la asociación presenta a la clase del otro extremo. Es el rol que juega la clase en la asociación. Multiplicidad: Representa el número de objetos que pueden conectarse a través de una relación de asociación. Se puede indicar una multiplicidad de exactamente uno (1), cero o uno (0..1), muchos (0..*), o uno o más (1..*). También se puede indicar un valor exacto (por ejemplo, 3). 8
Agregación: A veces se desea modelar una relación de tipo "todo/parte", en la cual una clase representa algo grande (el todo), que consta de elementos más pequeños (las partes). Este tipo de relación se denomina agregación, y es una relación "tiene-un" o "tiene-una". Empresa 1 * Departamento Composición: La composición es un tipo especial de asociación, que también modela relaciones "todo/parte". La diferencia es que tiene una fuerte relación de pertenencia y VIDAS COINCIDENTES de la parte con el todo. Las "partes" pueden crearse después del "todo", pero una vez creadas, viven y mueren con el "todo" (se pueden eliminar explícitamente antes). Significa que una "parte", solamente puede relacionarse con un "todo". Ventana 1 1 Marco 9
En el siguiente ejemplo se muestran algunas de las relaciones antes descritas. Observen el poder de expresión de esta notación. 10
TARJETAS CRC un método informal para modelado de software Qué son? Tarjeta indexada con información de un objeto, una clase, su comportamiento y sus interacciones. CRC Class Responsabilities Collaborators Introducidas por Kent Beck y Ward Cunningham Por qué se utiliza? Son portables, visualizan el funcionamiento del proyecto sin necesidad de software. Son útiles para el proceso de enseñanza del enfoque orientado a objetos. Pueden utilizarse como una metodología en sí mismo o como el frontend de una metodología en particular (Booch, OMT, etc). 11
TARJETAS CRC Características Normalmente miden 3x5 (7.6x12.7cm) ó 4x6 (10.2x15.2cm). Tienen la siguiente forma: Nombre de la Clase: SuperClase: SubClases: Responsabilidades Colaboradores 12
TARJETAS CRC No forman parte de UML pero son de gran utilidad: Identificación de clases y asociaciones Identificación de navegabilidad de las asociaciones Localización temprana de posibles problemas de cohesión y acoplamiento Una tarjeta CRC consta de: Nombre de la clase Responsabilidades de la clase Describen a alto nivel el propósito de la existencia de la clase. Normalmente una clase no debe tener más de tres o cuatro responsabilidades. Si tiene más, habría que plantearse describirla de forma más concisa o dividir la clase porque su cohesión es baja. Colaboradores de la clase Ayudan a ejecutar cada responsabilidad Si hay demasiados es que existe un excesivo acoplamiento 13
TARJETAS CRC Utilización de las tarjetas CRC Se recorren los casos de uso, resolviendo cómo el modelo de clases proporciona la funcionalidad requerida por los casos de uso y si hay elementos olvidados. Importante: se representa la comunicación entre objetos, no entre clases. Una técnica útil es: Asignación a cada miembro del equipo de una o más responsabilidades de las tarjetas CRC. Comprobación de la completitud del diseño representando diversos escenarios de los casos de uso relevantes: 14
TARJETAS CRC Las tarjetas se reparten. La petición inicial se le da a una persona cuyas tarjetas CRC representan una clase cuyas responsabilidades incluyen la realización de un escenario. Si en la implementación figurada de ese escenario la clase necesita la asistencia de uno de sus colaboradores, solicitará a la persona que tenga la tarjeta CRC correspondiente un mensaje solicitando que ejecute una operación. Esa operación debería formar parte de las responsabilidades de la tarjeta CRC de la clase que ha recibido la petición. Si no existe esa responsabilidad, o está asignada a otra clase, es que el diseño es defectuoso o incompleto: hay que cambiar la clase, crear nuevas responsabilidades o cambiar las colaboraciones. 15
TARJETAS CRC También son útiles para: Mejorar la colaboración en el equipo al participar todos en el diseño. Pueden utilizarse para hacer un borrador del diagrama de clases. Para terminar Las tarjetas es necesarias cuando un proyecto es muy grande y se divida en varios grupos de trabajo, ya que tiene la característica de comunicar la forma de las relaciones y la forma de actuación de un objeto del programa. La forma de plantear Clase-Responsabilidad- Colaborador, nos brinda una forma sencilla de realizar las conexiones entre objetos y así no se puede tener conveniente en el momento de la unificación. 16