U.T.5.- Elaboración de diagramas de clases.

Presentación del tema: "U.T.5.- Elaboración de diagramas de clases."— Transcripción de la presentación:

1 U.T.5.- Elaboración de diagramas de clases.
5.1. Introducción a UML. 5.2. Clases. Atributos, métodos y visibilidad. 5.3. Objetos. Instanciación. Características de los objetos: estado, comportamiento e identidad. 5.4. Relaciones o asociaciones. Interacciones estáticas, herencia, composición, agregación. Interacciones dinámicas. 5.5. Notación de los diagramas de clases. 5.6. Herramientas de diseño de diagramas de clases del entorno de desarrollo. Herramientas alternativas. 5.7. Generación de código a partir de diagramas de clases. Ingeniería inversa. 5.8. Diagramas de objetos.

2 5.1. Introducción a UML. Para diseñar software, se realizan modelados o diagramas representando gráficamente la estructura de la aplicación y su funcionalidad, de una manera fácil de entender y rápida de crear. Antiguamente, los diagramas de cada diseñador eran únicos, ya que, salvo un par de diagramas conocidos por todos (como los diagramas de flujo o los diagramas de entidad-relación), cada diseñador o analista realizaba los diagramas de la manera que mejor los entendía, por lo que podría suponer un problema si varias personas tenían que entender los diagramas que uno o varios diseñadores les presentaban para definir el software. Con el fin de evitar ese problema se creó UML (Unified Modeling Language).

3 ¿Qué es UML? Es un conjunto unificado de estándares para las diferentes necesidades y usos que un diseñador puede tener a la hora de plantear una representación gráfica de un programa. Son diagramas de propósito general que se presuponen conocidos por todos, con unas técnicas de notación conocidas, de modo que cualquiera pueda crear diagramas entendibles por todos. En la versión 2.0 de UML se definió un completo árbol de superestructuras donde se relacionaban y complementaban todos los tipos de diagramas UML a la hora de definir un software por completo.

4 Teniendo presente la estructura de diagramas de UML, podríamos pensar que la tarea de definir y realizar dichos diagramas sería casi imposible, pero no es necesario ni se suelen realizar todos los diagramas para modelar un software. Por norma general se utilizan solo una serie de diagramas para modelarlo, lo más clásico sería la tríada diagrama de clases, de secuencia y de casos de uso.

5 UML es sólo una notación, no dicta estándares para el proceso de desarrollo. Sin embargo, UML condiciona dicho proceso de desarrollo al establecer los diagramas e información asociada que debe representarse. Los diagramas incluidos en UML, agrupados según su ámbito de aplicación, son: Análisis en el contexto organizacional Diagramas de Casos de Uso Análisis y diseño desde la perspectiva estática Diagrama de Clase Diagrama de Objetos Análisis y diseño desde la perspectiva dinámica Diagrama de Secuencia Diagrama de Colaboración Diagrama de estados Implementación Diagrama de Componentes Diagrama de Despliegue

6 5.2. Clases. Atributos, métodos y visibilidad.
Clases: Describen un conjunto de objetos con propiedades y comportamientos comunes. Ejemplo: Supongamos que queremos programar una aplicación de agenda telefónica. El objetivo de nuestra agenda telefónica es gestionar una serie de contactos. Cada uno de estos contactos representa a una «Persona». Cada uno de los contactos de la agenda está creado a partir de la misma plantilla «Persona», que es la abstracción de una persona del mundo real en el contexto de la aplicación de la agenda telefónica. Atributos: Definen las propiedades y características del objeto. Volviendo al ejemplo de la agenda telefónica, cada una de los contactos de la agenda va a tener una serie de datos de interés, que pueden o no variar a lo largo del tiempo (un contacto de mi agenda puede cambiar de número de teléfono, pero no es probable que cambie de apellidos) como nombre, apellidos y número de contacto.

7 Métodos: Especifican las acciones que podemos realizar con un objeto
Métodos: Especifican las acciones que podemos realizar con un objeto. Volviendo a la aplicación de la agenda, un ejemplo de método podría ser consultar el nombre de un contacto. Visibilidad: Indica el nivel de «acceso» que tienen el resto de clases a los datos y operaciones definidos. La encapsulación (que a veces recibe el nombre de ocultación de datos) es la combinación de datos y comportamientos en un paquete y la ocultación al usuario del objeto de la implementación de los datos. La clave para que la encapsulación funcione es tener métodos que nunca accedan directamente a los campos instanciados de una clase que no sea la suya propia. Los programas deben interactuar con los datos de un objeto únicamente a través de los métodos de los métodos de ese objeto.

8 5. 3. Objetos. Instanciación
5.3. Objetos. Instanciación. Características de los objetos: estado, comportamiento e identidad. Cuando construimos un objeto de una clase estamos creando una instancia de la misma. Volviendo al programa de la agenda telefónica, cada contacto de la agenda sería una instancia de la clase «Persona». Comportamiento: todos los objetos que son instancias de la misma clase comparten un comportamiento parecido. El comportamiento de un objeto está definido por los métodos a los que se puede llamar. Estado: Todo objeto almacena información acerca de sí mismo. Es el estado de ese objeto. Se refiere a cómo reacciona el objeto cuando se aplican sus métodos. Identidad: Cómo se distingue un objeto de otros que tienen el mismo estado y comportamiento.

9 5. 4. Relaciones o asociaciones
5.4. Relaciones o asociaciones. Interacciones estáticas, herencia, composición, agregación. Interacciones dinámicas. Las relaciones indican qué clases colaboran con otras. Las más comunes son: Asociación. Es la más básica de las relaciones, no tiene un tipo definido y puede ser tanto una composición como una agregación. Una agregación ( o relación «tiene-una») se da cuando los objetos de una clase se forman de la combinación de diversos objetos. Ejemplo: un ordenador se forma por la agregación de una torre, un teclado, un ratón,…. La composición define los componentes de los que se compone otra clase, se define además que la clase que contiene la composición no tiene sentido de existencia si la(s) agregada(s) desaparece(n). Ejemplo: una camisa está compuesta de cuerpo, cuello, manga, botones, ojales y puños. Si suprimimos la camisa, cualquiera de los otros componentes será inútil.

10 Dependencias ( o relación «usa-una»): relaciones de uso, especifican que un cambio en la especificación de un elemento puede afectar a otro que lo utiliza. Ejemplo: La clase «Pedido» utiliza la clase «Cuenta», ya que los objetos de «Pedido» tienen que acceder a los objetos «Cuenta» para comprobar el crédito. Sin embargo, la clase «Item» no depende de la clase «Cuenta», ya que los objetos «Item» nunca tienen que preocuparse de las cuentas de los clientes. Una clase depende de otra si sus métodos manipulan objetos de esa clase. Objetivo: intentar reducir el número de clases que dependen unas de otras (lo que se conoce como acoplamiento entre clases). Herencia ( o relación «es-una»): Expresa un vínculo entre una clase más específica y otra más general. Ejemplo: la clase específica «Cuadrado» está relacionada con la clase «Forma», mucho más general.

11 Interacciones dinámicas
Un objeto puede cambiar su clase dinámicamente. Al hacerlo puede ganar y perder atributos y asociaciones. Si los pierde, no se recuperan aunque vuelva a ser de nuevo la clase original. Si gana atributos, hay que inicializarlos.

12 5.5. Notación de los diagramas de clases.
El propósito de los diagramas de clases es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar su tarea en vez de objetos del sistema o de un modelo de programación. El diagrama de Clases es el diagrama principal para el análisis y diseño estático. Se usan durante las fases del desarrollo: -Análisis, diseño y construcción. La clase define el ámbito de definición de un conjunto de objetos. Cada objeto pertenece a una clase. Los objetos se crean por instanciación de las clases. Además de dibujar y representar las clases con sus atributos y métodos, también se representan las relaciones.

13 Cada clase se representa en un rectángulo con tres compartimentos:
• Nombre de la clase • Atributos de la clase • Operaciones de la clase La figura muestra un ejemplo de la notación UML que captura los atributos y acciones de una lavadora. Un rectángulo es el símbolo que representa a la clase y se divide en tres áreas: el área superior contiene el nombre, la central los atributos y la inferior las acciones. Un diagrama de clases está formado por varios rectángulos de este tipo conectados por líneas que muestran cómo las clases se relacionan entre sí.

14 El nombre de la clase se escribe con la primera letra en mayúscula por convención.
Si el nombre de la clase consta de más palabras, se unen y cada una comienza por mayúscula. A veces, necesitaremos agrupar las clases de un diagrama para indicar que forman parte de un subsistema particular. Para ello, los agruparemos en paquetes, que se representarán como carpetas.

15 Un ejemplo de paquete puede ser «Electrodomésticos», que agrupe las clases «Lavadora», «Microondas» y «Nevera». Si la clase «Lavadora» forma parte del paquete «Electrodomésticos», podremos darle el nombre «Electrodomésticos::Lavadora». A la izquierda de los dos puntos se pone el nombre del paquete y, a la derecha, el nombre de la clase. A este tipo de notación se la conoce como nombre de ruta.

16 Atributos Por convención, si el nombre consta de una única palabra, se escribe en minúsculas. Si el nombre consta de más de una palabra, cada una se unirá a la anterior y comenzará por mayúsculas, menos la primera que empezará por una minúscula. UML permite especificar el tipo del atributo: string, integer, float o boolean. Para especificar el tipo, se separa con dos puntos del nombre del atributo como puede verse en el ejemplo de la figura. También puede establecerse un valor predeterminado para un atributo.

17 Tipo: puede llegar a depender del lenguaje de programación a utilizar.
Visibilidad: está relacionado con el encapsulamiento. Multiplicidad: determinar si un atributo debe estar o no, y si posee un único valor o una lista de valores. Ordenamiento: especifica si el atributo determina alguna relación de orden dentro de la clase. Capacidad de cambio: permite definir atributos con valores constantes.

18 -Visibilidad: El encapsulamiento presenta tres ventajas básicas:
• Se protegen los datos de accesos indebidos. • El acoplamiento entre las clases disminuye. • Favorece la modularidad y el mantenimiento. Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos. Niveles de encapsulamiento: (-) Privado : Sólo será visible desde la propia clase. (~) Package : Sólo es visible dentro del mismo package. (#) Los atributos/operaciones protegidos serán visibles para las clases derivadas. (+) Los atributos/operaciones públicos son visibles desde otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulamiento).

19 -Multiplicidad 1: El atributo debe tener un único valor. 0..1: El atributo puede o no tener un valor. 0..*: El atributo puede tener varios valores o ninguno. 1..* El atributo puede tener varios valores, pero debe tener al menos uno. * El atributo puede tener varios valores. X..Y El atributo puede tener entre X e Y valores. Ejemplo:

20 Operaciones Si consta de una única palabra, se escribe en minúsculas por convenio. Si consta de más de una, se unen y comienzan por mayúsculas todas menos la primera. • Tipo devuelto: se puede indicar el tipo que devuelve. • Parámetros: argumentos de la operación. Se puede indicar su tipo. Estas secciones de información sobre una operación se conocen como firma de la operación.

21 • Visibilidad: está relacionado con el encapsulamiento.
Para indicar que únicamente se muestren algunas de las operaciones o atributos de la clase, se utilizan puntos suspensivos (tres puntos). A esto se le denomina abreviar una clase.

22 Uso de estereotipos Se utilizan cuando tenemos una lista larga de atributos u operaciones y queremos organizarlos para que sea más fácil entenderlos. Se agrupan los atributos u operaciones bajo un término encerrado entre «».

23 Responsabilidad En un área bajo la lista de operaciones, podemos mostrar la responsabilidad de la clase. La responsabilidad es una descripción de lo que hará la clase. Una lavadora, por ejemplo, tiene la responsabilidad de recibir ropa sucia y devolver ropa limpia.

24 Restricciones Una manera más formal es agregar una restricción. Una restricción es un texto libre bordeado por llaves que especifica una o varias reglas que sigue la clase. Ejemplo: supongamos que en una lavadora queremos restringir su capacidad a 7, 8 o 9 kilos.

25 Notas adjuntas Podemos agregar más información a una clase con el uso de notas adjuntas. A menudo necesitaremos agregar notas operaciones y atributos. Una nota puede contener tanto imagen como texto. El ejemplo de la figura, muestra una nota que se refiere a una normativa gubernamental que indica la manera en que se generan los números de serie.

26 Qué es lo que hacen las clases y cómo encontrarlas
Las clases son el vocabulario y terminología de un área del conocimiento. Conforme hablemos con los clientes, analicemos su área de conocimiento y diseñemos sistemas de computación que resuelvan los problemas de dicha área, comprenderemos la terminología y modelaremos los términos como clases en UML. En las conversaciones con los clientes hay que prestar atención a los sustantivos que utilizan para describir las entidades de sus negocios, ya que dichos sustantivos se convertirán en las clases del modelo. También presta atención a los verbos, dado que constituirán las operaciones de las clases. Los atributos surgirán como sustantivos relacionados con los nombres de la clase. Una vez que tengamos una lista básica de las clases, preguntaremos a los clientes qué es lo que cada clase hace dentro del negocio. Las respuestas indicarán las responsabilidades de la clase.

27 Supón que eres un analista que generará un modelo del juego de baloncesto, y que entrevistas a un entrenador para comprender el juego. La conversación podría discurrir así: Analista: «Entrenador, ¿de qué se trata el juego?» Entrenador: «Consiste en arrojar el balón a través de un aro, conocido como cesto, y conseguir una mayor puntuación que el oponente. Cada equipo consta de cinco jugadores. Cada equipo lleva el balón al cesto del equipo oponente con el objetivo de hacer que el balón sea encestado.» Analista: «¿Cómo se hace para llevar el balón al otro cesto?» Entrenador: «Mediante pases y driblando. Pero el equipo tendrá que encestar antes de que termine el lapso para tirar.» Analista: «¿El lapso para tirar?»

28 Entrenador: «Así es, son 24 segundos luego de que un equipo toma posesión de él.»
Analista: «¿Cómo funciona la puntuación?» Entrenador: «Cada canasta vale dos puntos, a menos que el tiro haya sido hecho detrás de la línea de los tres puntos. En tal caso, serán tres puntos. Un tiro libre contará como un punto. A propósito, un tiro libre es la penalización que paga un equipo por cometer una infracción. Si un jugador hace una falta a un oponente, se detiene el juego y el oponente puede realizar diversos tiros al cesto desde la línea de tiro libre.» Analista: «Hábleme más acerca de lo que hacen los jugadores.» Entrenador: «Todos los jugadores pueden burlar, pasar, tirar y rebotar». Analista: «¿Qué hay de las dimensiones de la cancha? Y ya que estamos en eso ¿cuánto dura el juego?»

29 Entrenador: «La cancha mide 28 metros de longitud y 15 de ancho
Entrenador: «La cancha mide 28 metros de longitud y 15 de ancho. El cesto se encuentra a 3.05 m de altura. En un juego profesional, el juego dura 48 minutos, divididos en cuatro cuartos de 12 minutos cada uno. En un juego colegial e internacional, la duración es de 40 minutos, divididos en dos mitades de 20 minutos. Un cronómetro lleva un control del tiempo restante.» Recopilando tenemos: -Sustantivos: balón, cesto, equipo, jugadores, tiro, lapso para tirar, línea de los tres puntos, tiro libre, infracción, línea de tiro libre, cancha, cronómetro del juego. -Verbos: tirar, avanzar, driblar (o burlar), pasar, hacer falta, rebotar. -Atributos: dimensiones de la cancha, el tiempo de juego y el lapso de un tiro.

30 A partir de esta información añadiendo alguna idea propia (por ejemplo, sabemos que el balón tendrá un diámetro y un volumen) podemos generar un diagrama como el de la figura:

31 Relaciones entre clases
En el esquema anterior creamos un conjunto de clases que representaban el vocabulario del baloncesto. Aunque nos sirva de base para entender lo que lo que es el baloncesto, le falta algo. Ese "algo" es cómo las clases se relacionan entre sí. En el modelo no se indica la manera en que un jugador se relaciona con un balón, ni cómo los jugadores conforman un equipo, ni la forma en que procede el juego. Los tipos de relaciones que vamos a ver son: Asociaciones. Herencia y generalización. Dependencia. Realización.

32 Asociación Cuando las clases se conectan entre sí de forma conceptual, esta conexión se conoce como asociación. El modelo inicial que hicimos del juego del baloncesto nos dará algunos ejemplos. Por ejemplo: la asociación entre un jugador y un equipo. Podemos caracterizar tal asociación con la frase: "un jugador participa en un equipo". Visualizaremos la asociación como una línea que conectará a ambas clases, con el nombre de la asociación ("participa en") justo sobre la línea. Es útil indicar la dirección de la relación, y lo haremos con un triángulo relleno que apunte en la dirección apropiada.

33 Cuando una clase se asocia con otra, cada una de ellas juega un papel o rol dentro de tal asociación. Podemos representar estos papeles o roles en el diagrama escribiéndolos cerca de la línea que se encuentra junto a la clase que juega el papel correspondiente. En la asociación entre un jugador y un equipo, si el equipo es profesional, éste es un empleador y el jugador es un empleado.

34 La asociación puede funcionar en dirección inversa: un equipo emplea a jugadores.
Podemos mostrar ambas asociaciones en el mismo diagrama con un triángulo relleno que indique la dirección de cada asociación. Las asociaciones pueden ser más complejas porque varias clases pueden conectarse a una. Por ejemplo, si tomamos a los defensas, los delanteros y los centrocampistas de un equipo como en la figura a la derecha.

35 Restricciones en las asociaciones
En ocasiones una asociación entre dos clases debe seguir cierta regla. Ésta se indica al establecer una restricción junto a la línea de asociación. Por ejemplo: un «Cajero» atiende a un «Cliente», pero cada «Cliente» es atendido en el orden en que se encuentre en la formación. Podemos capturar este modelo colocando la palabra ordenado entre llaves (para indicar la restricción) junto a la clase «Cliente», como se ve en la figura.

36 Otro tipo de restricción es la relación O (distinguida como {Or}) en una línea discontinua que conecte a dos líneas de asociación. La figura modela a un estudiante de educación media superior que elegirá entre un curso académico o uno comercial.

37 Clases de asociación Una asociación, al igual que una clase, puede contener atributos y operaciones. Cuando éste sea el caso, tendremos una clase de asociación. Una clase de asociación puede tener asociaciones con otras clases. La figura muestra una clase de asociación para la asociación "Participa en" entre un jugador y un equipo. La clase de asociación, «Contrato», se asocia con la clase «DirectorGeneral».

38 Vínculos Así como un objeto es una instancia de una clase, una asociación también cuenta con instancias. Si podemos imaginar a un jugador específico que juega para un equipo específico, la relación "Participa en" se conocerá como vínculo, y lo representaremos como una línea que conecta a dos objetos. Subrayaremos el nombre de un objeto y el del vínculo.

39 Multiplicidad Un equipo de baloncesto cuenta con cinco jugadores (sin contar a los sustitutos). La asociación debe participar en este recuento. En la otra dirección, un jugador puede participar sólo en un equipo, y la asociación "Participa en" debe responder de esto. Tales especificaciones son ejemplos de la multiplicidad: la cantidad de objetos de una clase que se relacionan con un objeto de la clase asociada. Para representar los números en el diagrama, los colocaremos sobre la línea de asociación junto a la clase correspondiente, como se denota en la figura.

40 Hay varios tipos de multiplicidades
Hay varios tipos de multiplicidades. Una clase puede relacionarse con otra en un esquema de uno a uno, uno a muchos, uno a uno o más, uno a ninguno o uno, uno a un intervalo definido (por ejemplo: uno a cinco hasta diez), uno a exactamente n (como en este ejemplo), o uno a un conjunto de opciones (por ejemplo, uno a nueve o diez). El UML utiliza un asterisco (*) para representar más y para representar muchos. En un contexto O se representa por dos puntos, como en "1..*" ("uno o más"). En otro contexto, O se representa por una coma, como en "5, 10" ("5 o 10"). La figura muestra cómo concebir las posibles multiplicidades. Cuando la clase A tiene una multiplicidad de uno a ninguno o a uno con la clase B, la clase B se dice que es opcional para la clase A.

41 Resumiendo: la multiplicidad en las relaciones puede ser
1 Un elemento relacionado. Uno o ningún elemento relacionado. 0..* Varios elementos relacionados o ninguno. 1..* Varios elementos relacionados pero al menos uno. * Varios elementos relacionados. M..N Entre M y N elementos relacionados. Algunos ejemplos de multiplicidad en asociaciones son:

42

43 Asociaciones calificadas
Cuando la multiplicidad de una asociación es de uno a muchos, con frecuencia se presenta un reto muy particular: la búsqueda. Cuando un objeto de una clase tiene que seleccionar un objeto particular de otro tipo para cumplir con un papel en la asociación, la primera clase deberá atenerse a un atributo en particular para localizar al objeto adecuado. Normalmente, dicho atributo es un identificador que puede ser un número de identidad. Por ejemplo, cuando realizamos una reserva en un hotel, el hotel asigna un número de confirmación. Para hacer preguntas respecto a la reserva, deberemos proporcionar el número de confirmación.

44 En UML la información de identidad se conoce como calificador
En UML la información de identidad se conoce como calificador. Su símbolo es un pequeño rectángulo adjunto a la clase que hará la búsqueda. La figura muestra la representación. La idea es reducir, con eficiencia, la multiplicidad de uno a muchos a una multiplicidad de uno a uno.

45 Asociaciones reflexivas
En ocasiones, una clase se asocia consigo misma. Esto puede ocurrir cuando una clase tiene objetos que pueden jugar diversos papeles. Ejemplo: Un «OcupanteDeAutomovil» puede ser un «Conductor» o un «Pasajero». En el papel del conductor, el «OcupanteDeAutomovil» puede llevar ninguno o más «OcupanteDeAutomovil», quienes jugarán el papel de «pasajeros». Se representa mediante el trazado de una línea de asociación a partir del rectángulo de la clase hacia el mismo rectángulo de la clase, y en la línea de asociación indicará los papeles, nombre de la asociación, dirección de la asociación y multiplicidad.

46 Tipos de asociaciones: agregaciones y composiciones
En ocasiones una clase consta de otras clases. Éste es un tipo especial de relación conocida como agregación o acumulación. Los componentes y la clase que constituyen son una asociación que conforma un todo. Ejemplo: una computadora es un conjunto de elementos que consta de gabinete, teclado, ratón, monitor, unidad de CD-ROM, una o varias unidades de disco duro, módem, unidad de disquete, impresora y, posiblemente, altavoces. Además de las unidades de disco, el gabinete contiene la memoria RAM, una tarjeta de video y una tarjeta de sonido (y tal vez algunos otros elementos).

47 Podemos representar una agregación como una jerarquía dentro de la clase completa (por ejemplo el sistema computacional) en la parte superior, y los componentes por debajo de ella. Una línea conectará el todo con un componente mediante un rombo sin relleno que se colocará en la línea más cercana al todo. La figura muestra el sistema de cómputo como una agregación.

48 Restricciones en las agregaciones
En ocasiones el conjunto de componentes posibles en una agregación se establece dentro de una relación O. Ejemplo: En ciertos restaurantes, una comida consta de sopa o ensalada, el plato fuerte y el postre. Para modelar esto, utilizaríamos una restricción: la palabra O dentro de llaves con una línea discontinua que conecte las dos líneas que conforman al todo, como lo muestra la figura .

49 Composiciones Una composición es un tipo muy representativo de una agregación. Cada componente dentro de una composición puede pertenecer tan sólo a un todo. Ejemplo: Los componentes de una mesa de café (la superficie de la mesa y las patas) establecen una composición. Otro ejemplo: un libro se compone de páginas. El símbolo de una composición es el mismo que el de una agregación, excepto que el rombo está relleno.

50 Asociaciones n-arias Son asociaciones que se establecen entre más de dos clases. Una clase puede aparecer varias veces desempeñando distintos roles. Las asociaciones n-arias se representan a través de rombo que se une con cada una de las clases. Ejemplo:

51 Contextos Al modelar un sistema podrían producirse, con frecuencia, agrupamientos de clases, como agregaciones o composiciones. En tal caso, habrá que enfocar la atención en un agrupamiento o en otro. El diagrama de contexto proporciona la característica de modelaje que se requiere para tal fin. Las composiciones figuran en gran medida dentro de los diagramas de contexto. Un diagrama de contexto es como un mapa detallado de alguna sección de un mapa de mayores dimensiones. Pueden ser necesarias varias secciones para capturar toda la información detallada. Ejemplo: supongamos que estamos creando un modelo de una camisa y la forma en que se podría combinar con algún atuendo y un guardarropa.

52 Un tipo de diagrama de contexto (figura) mostrará la camisa como un gran rectángulo de clase, con un diagrama anidado en el interior, el cual muestra cómo los componentes de la camisa están relacionados entre sí. Este es un diagrama de contexto de composición (dado que la sola camisa reúne a cada componente se le denomina de composición).

53 El diagrama de contexto de composición enfoca la atención en la camisa y sus componentes. Para mostrar la camisa en el contexto del guardarropa y de algún atuendo, tendremos que ampliar su ámbito. Lo hacemos con un diagrama de contexto del sistema. Podremos mostrar la forma en que la clase «Camisa» se conecta con las clases «Guardarropa» y «Atuendo», como se ve en la figura.

54 Herencia y generalización
Uno de los sellos distintivos de la orientación a objetos es que captura uno de los mayores aspectos del sentido común en cuanto a la vida diaria: si conocemos algo de una categoría de cosas, automáticamente sabremos algunas cosas que podremos transferir a otras categorías. Ejemplos: -Si sabemos que algo es un electrodoméstico, ya sabremos que contará con un interruptor, una marca y un número de serie. -Si sabemos que algo es un animal daremos por hecho que come, duerme, tiene una forma de nacer, de trasladarse de un lugar a otro y algunos otros atributos y operaciones que podríamos listar.

55 La orientación a objetos se refiere a esto como herencia.
UML también lo denomina generalización. Una clase (la clase secundaria o subclase) puede heredar los atributos y operaciones de otra (la clase principal o superclase). La clase principal (o madre) es más genérica que la secundaria (o hija). La jerarquía de la herencia no tiene que finalizar en dos niveles: una clase secundaria puede ser principal para otra clase secundaria. Ejemplo: Un «Mamífero» es una clase secundaria de «Animal», y «Caballo» es una clase secundaria de «Mamífero».

56 En UML representaremos la herencia con una línea que conecte a la clase principal con la secundaria.
En la parte de la línea que se conecta con la clase principal, colocaremos un triángulo sin rellenar que apunte a la clase principal. Este tipo de conexión se interpreta con la frase «es un tipo de». Un «Mamífero» es un tipo de «Animal», y un «Caballo» es un tipo de «Mamífero».

57 Con frecuencia las clases secundarias agregan otras operaciones y atributos a los que han heredado. Por ejemplo: un «Mamífero» tiene pelo y da leche, dos atributos que no se encuentran en la clase «Animal». Una clase puede no provenir de una clase principal, en cuyo caso será una clase base o clase raíz. Una clase podría no tener clases secundarias, en cuyo caso será una clase final o clase hoja. Si una clase tiene exactamente una clase principal, tendrá una herencia simple. Si proviene de varias clases principales, tendrá una herencia múltiple.

58 Normalmente la herencia simple es suficiente para modelar los problemas a los que nos enfrentamos pero en ciertas ocasiones conviene modelar mediante herencia múltiple. En el siguiente ejemplo podemos observar como se puede usar la herencia múltiple para representar especializaciones cuyos padres son disjuntos pero existen hijos con propiedades de ambos.

59 Usando discriminadores se pueden tener varias especializaciones de una misma clase padre.
En el ejemplo de la figura vemos que tenemos dos especializaciones distintas: una dependiendo del uso y otra dependiendo de la estructura.

60 Clases abstractas En el modelo del baloncesto, las clases «Jugador» y «Reloj» son útiles puesto que funcionan como clases principales para clases secundarias importantes. Las clases secundarias son importantes en el modelo dado que querremos tener instancias de tales clases. Para desarrollar el modelo, necesitaremos instancias de «Alero», «Pivot», «Base», «CronometroDeJuego» y «LapsoDeTiro». No obstante, «Jugador» y «Reloj» no proporcionan ninguna instancia al modelo. Un objeto de la clase «Jugador» no serviría a ningún propósito, así como tampoco uno de la clase «Reloj». Las clases como «Jugador» y «Reloj», que no proveen objetos, se dice que son clases abstractas. Una clase abstracta se distingue por tener su nombre en cursiva.

61

62 Dependencias En otro tipo de relación, una clase utiliza a otra. A esto se le llama dependencia. El uso más común de una dependencia es mostrar que un cambio en la operación de una clase puede afectar a otra. La dependencia se muestra con una línea discontinua señalando con una flecha al elemento del cual se depende. Ejemplo:

63 Interfaces Una interfaz es una colección de operaciones que especifica cierto aspecto de la funcionalidad de una clase y es un conjunto de operaciones que una clase presenta a otras. Describe un conjunto de especificaciones de operaciones (que tendrán una visibilidad pública) pero nunca su implementación. Al igual que una clase, una interfaz puede participar en relaciones de generalización, asociación y dependencia. Además, puede participar en relaciones de realización. Una realización es una relación semántica entre dos clasificadores en la que un clasificador especifica un contrato que el otro garantiza que va a llevar a cabo.

64 La realización se utiliza para señalar la relación entre una clase y una interfaz.
Existen dos formas de representar un interfaz en UML, la primera es mediante un círculo conectado a un lado de una clase o componente. La otra forma de representar una interfaz es mostrar una clase estereotipada que permite ver las operaciones y otras propiedades, y conectarla mediante una relación de realización con la componente o el clasificador que la contiene. Una realización se representa como una flecha de punta vacía con la línea discontinua.

65 Ejemplo: UML define dos tipos de interfaces: interfaz suministrada e interfaz requerida.

66 La interfaz suministrada es aquella que una clase efectivamente implementa.
Ejemplos: Las interfaces requeridas son aquellas que necesita una clase para realizar su cometido. El símbolo utilizado para representarlas es un semicírculo. Ejemplos:

67 En determinados contextos, sólo una o más interfaces tendrán sentido.
En este caso cada interfaz representa un rol que juega el objeto. Un rol denota un comportamiento de una entidad en un contexto particular, dicho de otra manera, un rol es la cara que una abstracción presenta al mundo. Ejemplo: la clase «Persona» y los roles que una persona puede desempeñar dependiendo del contexto en que se encuentre, como ejemplos de roles podemos tener: Madre, Asistente, Contable, Empleado, Directivo, Piloto, …. Cada uno de los roles que se han definido tendrá una correspondencia con un interfaz concreto.

68 5.6. Herramientas de diseño de diagramas de clases del entorno de desarrollo. Herramientas alternativas. A la hora de elaborar diagramas de clase, podremos recurrir a las disponibles en el entorno de desarrollo o usar herramientas de terceros. Por defecto, el módulo que permite trabajar con UML, no se instala en el entorno, por lo que habrá que agregarlo como si de una actualización se tratase. En Netbeans, todavía no hay un módulo para UML en la versión 7 (si en la 6). La herramienta alternativa que vamos a utilizar, se llama «Visual Paradigm». Se trata de un programa comercial que podemos evaluar durante 30 días, también hay disponible una versión libre para uso no comercial. Para descargar Visual Paradigm, vamos al enlace

69 Una vez en la página Web, hacemos clic en el botón «Get Community Edition».

70 Elegimos la versión de nuestro sistema operativo y hacemos clic en el botón «Get Community Edition».

71 Una vez finalizada la descarga, ejecutamos el fichero de instalación.
Veremos el cuadro de diálogo de la figura donde haremos clic en «Next».

72 Aceptamos las condiciones de la licencia.

73 Elegimos el directorio de instalación.

74 Dentro del «Menú Inicio», podemos cambiar la carpeta para los accesos directos.

75 Los proyectos de Visual Paradigm tienen extensión «
Los proyectos de Visual Paradigm tienen extensión «.vpp», aquí nos indica que va a asociar los ficheros con esa extensión a Visual Paradigm.

76 La instalación ha terminado y nos ofrece la posibilidad de arrancar el programa ahora o no.
Saltamos la ventana para el proceso de registro y hacemos clic en el botón «Start» para ejecutar el programa.

77 En el siguiente cuadro de diálogo elegiremos el espacio de trabajo donde se van a guardar nuestros proyectos. El programa detecta que nuestro idioma es el español y nos ofrece cambiar el idioma por defecto para mostrar los menús en castellano.

78 Una vez que abrimos el programa vemos que su uso es muy intuitivo.
Para crear un diagrama de clases, podemos usar la barra lateral o podemos hacerlo desde la central haciendo clic en «UML Modelling» y después en «Class Diagram».

79 Las otras formas de crear un diagrama de clases son: a través del menú «Archivo-Nuevo diagrama-Nuevo diagrama» o haciendo clic con el botón derecho del ratón en la barra lateral izquierda sobre «Diagrama de Clases-Nuevo diagrama de Clases».

80 Para agregar un elemento al diagrama, haremos clic en el mismo en la barra de la izquierda y después en el lienzo en la derecha.

81 Añadir atributos Clic con el botón derecho del ratón sobre la clase y elegimos «Añadir-Attribute» en el menú contextual y le damos un nombre.

82 Para editar un atributo, hacemos clic con el botón derecho del ratón sobre el atributo y elegimos «Abrir especificación». En el cuadro de diálogo elegimos su visibilidad, multiplicidad, tipo,…

83 Añadir operaciones Para añadir operaciones a la clase, hacemos clic con el botón derecho del ratón sobre la clase y elegimos «Añadir-Operación». Se accede al modo edición de la misma forma que en los atributos.

84 Añadir relaciones Cuando hacemos clic en una clase vemos a su alrededor una serie de botones que nos permiten establecer relaciones haciendo clic en el botón correspondiente. Al mover el cursor por encima vemos cuál es su utilidad. También podemos recurrir a los botones de la barra lateral.

85 Al igual que con atributos y operaciones, podemos editar la especificación de las relaciones y darles nombre, multiplicidad, roles,…

86 Herramientas alternativas
Algunas herramientas alternativas a Visual Paradigm gratuitas son: StarUML: puedes consultar información sobre sus características y descarga en la página ArgoUML: puedes consultar información sobre sus características y descarga en la página BOUML: puedes consultar información sobre sus características y descarga en la página FrameUML: puedes consultar información sobre sus características y descarga en la página También tenemos herramientas que son únicamente editores UML sin soporte para generar código o ingeniería inversa: Dia, UMLPad,..

87 5. 7. Generación de código a partir de diagramas de clases
5.7. Generación de código a partir de diagramas de clases. Ingeniería inversa. A partir del diagrama de clases, se puede generar el código en alguno de los lenguajes de programación que Visual Paradigm permite. Para Java, haríamos clic en el botón «Codigo-Java Bidireccional-Generador de código». Veremos el siguiente cuadro de diálogo que nos informa que esa característica está disponible en la «Standard Edition» y que si queremos cambiar a la misma. Hacemos clic en «OK» y el programa se reiniciará con la opción ya disponible.

88 A partir de ahora, al generar código veremos el cuadro de diálogo de la figura para que escojamos la carpeta de salida del código fuente generado a partir del diagrama .

89 En la figura vemos en la carpeta indicada los ficheros «
En la figura vemos en la carpeta indicada los ficheros «.java» generados.

90 Ingeniería inversa. La ingeniería inversa consiste en generar el diagrama de clases a partir del código fuente. Visual Paradigm es compatible con la mayoría de los entornos de desarrollo Java conocidos. A modo de ejemplo vamos a generar el diagrama de clases a partir de un proyecto desarrollado en Netbeans. Para ello hacemos clic en el botón «Código» y después en «Inversión instantánea-Java».

91 En el cuadro de diálogo que se abre, hacemos clic en el botón «Agregar Carpeta de origen» y seleccionamos la carpeta con el código fuente de las clases que queremos convertir en diagrama, elegimos el lenguaje y el tipo de diagrama.

92 En el «Repositorio de Clases», hacemos clic con el botón derecho del ratón sobre el proyecto que hemos agregado (directorio «Instant Reverse») y elegimos en el menú contextual que se convierta a «Nuevo diagrama de clases».

93 A la derecha se habrá generado el diagrama de clases correspondiente.

94 5.8. Diagramas de objetos. El Modelado de Objetos permite representar el ciclo de vida de los objetos a través de sus interacciones. En UML, un objeto se representa por un rectángulo con un nombre subrayado. Un diagrama de Objetos representa una situación concreta del dominio. Un diagrama de objetos congela un instante en el tiempo. Un diagrama de objetos es simplemente un diagrama que representa un conjunto de objetos y sus relaciones en un momento concreto. Ejemplo:

95 El proceso de crear objetos pertenecientes a una clase se conoce como instanciación, donde los objetos son las instancias de la clase. El objeto es la instancia de la clase a la que pertenece. Se utiliza un flecha punteada para mostrar los objetos como instancias de las clases. Ejemplo:

96 Un Objeto = Identidad + Estado + Comportamiento.
Cada objeto posee un oid (Object Identifier). El oid establece la identidad del objeto y tiene las siguientes características: Constituye un identificador único y global para cada objeto dentro del sistema. Es determinado en el momento de la creación del objeto. Es independiente de la localización física del objeto, es decir, provee completa independencia de localización. Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructura. No cambia durante toda la vida del objeto. Además, un oid no se reutiliza aunque el objeto deje de existir. No se tiene ningún control sobre los oids y su manipulación resulta transparente.

97 Estado El estado está representado por los valores de los atributos. Un atributo toma un valor en un dominio concreto. El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes. El comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto. Las operaciones de un objeto son consecuencia de un estímulo externo representado como mensaje enviado desde otro objeto. Comportamiento Los mensajes navegan por los enlaces, a priori en ambas direcciones. Estado y comportamiento están relacionados. Ejemplo: no es posible aterrizar un avión si no está volando. Está volando como consecuencia de haber despegado del suelo.

98 Ejemplos de diagramas de objetos:

99 Ejemplo de diagrama de clases y diagrama de objetos relacionado: