Tutorial UML

UML (Unified modeling language)

UML significa "Unified Modeling Language": Lenguaje de Modelado o Modelamiento Unificado. El Lenguaje de Modelado Unificado es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos a un sistema de software bajo desarrollo, así como para modelado de negocios y otros sistemas no software.

Puede ser utilizado con cualquier metodología, a lo largo del proceso de desarrollo de software, en

cualquier plataforma tecnológica de implementación (Unix, Windows etc.).

Es un sistema notacional (que, entre otras cosas, incluye el significado de sus notaciones)

destinado a los sistemas de modelado que utilizan conceptos orientados a objetos.

Los principales factores que motivaron la definición de UML fueron: la necesidad de modelar sistemas, las tendencias en la industria del software, unificar l os distintos lenguajes y métodos existentes e innovar los modelos para adaptarse a la arquitectura distribuída.

Es importante resaltar que un modelo UML describe lo que supuestamente hará un sistema, pero no dice como implementar dicho sistema.

DIFERENTES DEFINICIONES DE UML

?? El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.

? UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de

hardware, y organizaciones del mundo real.

?? El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación. Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión.

? UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a

objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar

Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.

Breve reseña histórica

El desarrollo de UML comenzó en octubre de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation comenzaron a trabajar en la unificación de los lenguajes de modelado Booch y OMT, desde este momento fueron reconocidos mundialmente en el desarrollo de metodologías orientadas a objetos. Así, en octubre de 1995, terminaron su trabajo de unificación obteniendo el borrador de la versión 0.8 del denominado Unified Method. Hacia fines de este mismo año, Ivar Jacobson (creador de la metodología OOSE – Object Oriented Software Engineer) se unió con Rational Software para obtener finalmente UML 0.9 y 0.91 en junio y octubre de 1996, respectivamente.

Igualmente, UML incorpora ideas de otros metodólogos entre los que podemos incluir a Peter Coad, Derek Coleman, W ard Cunningham, David Harel, Richard Helm, Ralph Johnson, Stephen Mellor, Bertrand Meyer, Jim Odell, Kenny Rubin, Sally Shlaer, John Vlissides, Paul W ard, Rebecca W irfs- Brock y Ed Yourdon.

Luego, muchas organizaciones como Microsoft, Hewlett-Packard, Oracle, Sterling Software MCI Systemhouse, Unisys, ICON Computing, IntelliCorp, i-Logix, IBM, ObjectTime, Platinum Technology, Ptech, Taskon, Reich Technologies, Softeam se asociaron con Rational Software Corporation para dar como resultado UML 1.0 y UML 1.1. Hoy en día llegamos hasta UML 1.4 y UML 2.0. En la siguient e figura se muestra de forma gráfica y resumida la evolución de UML.

Características de UML

?? UML es una especificación de notación orientada a objetos. Se basa en las anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto.

?? UML permite describir un sistema en diferentes niveles de abstracción, simplificando la complejidad sin perder información, para que tanto usuarios, líderes y desarrolladores puedan comprender claramente las características de la aplicación.

?? UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un ejemplo.

? El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos.

OBJETIVOS

Como objetivos principales de la consecución de un nuevo método que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:

?? El método debía ser capaz de modelar no sólo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientación a objetos (OO).

? Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas.

? Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables.

? Manejar los problemas típicos de los sistemas complejos de misión crítica.

Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los métodos más utilizados sigan evolucionando en conjunto y no por separado. Y además, unificar las perspectivas entre diferentes tipos de sistemas (no sólo software, sino también en el ámbito de los negocios), al aclarar las fases de desarrollo, los requerimientos de análisis, el diseño, la implementación y los conceptos internos de la OO.

Modelo: Nociones Generales

El UML es una técnica de modelado de objetos y como tal supone una abstracc ión de un sistem a para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación. Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión. Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los m úsicos representan la música en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: el modelo de objetos, que describe la estructura estática; el modelo dinámico, con el que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones funcionales entre valores. Mediante estas tres fases de construcción de modelos, se consigue una abstracción de la realidad que tiene en sí misma información sobre las principales características de ésta.

Los modelos además, al no ser una representación que incluya todos los detalles de los originales,

permiten probar más fácilmente los sistemas que modelan y determinar los errores. Según se indica en la Metodología OMT (Rumbaugh), los modelos permiten una mejor comunicación con el cliente por distintas razones:

? Es posible enseñar al cliente una posible aproximación de lo que será el producto final.

?? Proporcionan una primera aproximación al problema que permite visualizar cómo quedará el resultado.

? Reducen la complejidad del original en subconjunt os que son fácilmente tratables por

separado.

Se consigue un modelo completo de la realidad cuando el modelo captura los aspectos importantes del problema y omite el resto. Los lenguajes de programación que estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas reales porque necesitan una especificación total con detalles que no son importantes para el algoritmo que están implementando.

Con la creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informático o no, mediante los diagramas, es decir, mediante representaciones gráficas que contienen toda la información relevante del sistema. Un diagrama es una representación gráfica de una colección de elementos del model o, que habitualmente toma forma de grafo donde los arcos que conectan sus vértices son las relaciones entre los objetos y los vértices se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren representar para obtener el modelo se dibuja dé forma que se resaltan los detalles necesarios para entender el sistema.

Diagramas: Vistazo General

En todos los ámbitos de la ingeniería se construyen modelos, en realidad, simplificaciones de la realidad, para comprender mejor el sistema que vamos a desarrollar: los arquitectos utilizan y construyen planos (modelos) de los edificios, los grandes diseñadores de coches preparan modelos en sistemas CAD/CAM con todos los detalles y los ingenieros de software deberían igualmente construir modelos de los sistemas software.

Para la construcción de modelos, hay que centrarse en los detalles relevantes mientras se ignoran

los demás, por lo cual con un único modelo no tenemos bastante. Varios modelos aportan diferentes vistas de un sistema los cuales nos ayudan a comprenderlo desde varios frentes. Así, UML recomienda la utilización de nueve diagramas para representar las distintas vistas de un sistema.

Los diagramas de UML son los siguientes:

Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupándola en descripciones de acciones ejecutadas por un sistema para obtener un resultado.

Se utiliza para entender el uso del sistema

Muestra el conjunto de casos de uso y actores(Un actor puede ser tanto un sistema com o una persona) y sus relaciones: es decir, muestra quien puede hacer qué y las relaciones que existen entre acciones (casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.

Diagrama de Clases: muestra las clases (descripciones de objetos que comparten características comunes) que componen el sistema y cómo se relacionan entre sí.

Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus relaciones. A diferencia de los diagramas anteriores, estos diagramas se enfocan en la perspectiva de casos reales o prototipos. Es un diagrama de instancias de las clases mostradas en el diagrama de clases.

Diagrama de Secuencia: enfatiza la interacción entre los objetos y los mensajes que intercambian entre sí junto con el orden temporal de los mismos.

Diagrama de Colaboración: igualmente, muestra la interacción entre los objetos resaltando la organización estructural de los objetos en lugar del orden de los mensajes intercambiados.

El diagrama de secuencia y el diagrama de colaboración: muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.

Diagrama de Estados: Se utiliza para analizar los cambios de estado de los objetos. Muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.

Diagrama de Actividades: Es un caso especial del diagrama de estados, simplifica el diagrama de estados modelando el comportamiento mediante flujos de actividades. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.

Diagrama de Componentes: muestra la organización y las dependencias entre un conjunto de componentes. Se usan para agrupar clases en componentes o módulos.

Diagrama de Despliegue (o implementación): muestra los dispositivos que se encuentran en un sistema y su distribución en el mismo. Se utiliza para identificar Sistemas de Cooperación: Durante el proceso de desarrollo el equipo averiguará de qué sistemas dependerá el nuevo sistema y que otros sistemas dependerán de él.

Clasificación de Diagramas

Se dispone de dos tipos diferentes de diagramas los que dan una vista estática del sistema y los que dan una visión dinámica.

La practica de crear diagramas para visualizar sistemas desde perspectivas o vistas diferentes no está limitado a la industria de la construcción. En el contexto del software, existen cinco vistas complementarias que son las más importantes para visualizar, especificar, construir y documentar la arquitectura del software. En el UML las vistas existentes son:

1. Vista casos de uso: se forma con los diagramas de casos de uso, colaboración, estados y actividades.

2. Vista de diseño: se forma con los diagramas de clases, objetos, colaboración, estados y actividades.

3. Vista de procesos: se forma con los diagramas de la vista de diseño. Recalcando las clases y

objetos referentes a procesos.

4. Vista de implementación: se forma con los diagramas de componentes, colaboración, estados y actividades.

5. Vista de despliegue: se forma con los diagramas de despliegue, interacción, estados y actividades.

Como podemos ver el número de diagramas es muy alto, en la mayoría de los casos excesivos, y

UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos

UML esta pensado para el modelado tanto de pequeños sistemas como de sistemas complejos, y debemos tener en cuenta que los sistemas complejos pueden estar compuestos por millones de líneas de código y ser realizados por equipos de centenares de programadores.

En la práctica todos los diagramas son bidimensionales, pero el UML permite crear diagramas en

tres dimensiones como en modelos donde se puede "entrar" al modelo para poderlo visualizar por dentro.

Con UML nos debemos olvidar del protagonismo excesivo que se le da al diagrama de clases, est e

representa una parte importante del sistema, pero solo representa una vista estática, es decir muestra al sistema parado. Sabemos su estructura pero no sabemos que le sucede a sus diferentes partes cuando el sistema empieza a funcionar.

Diagramas Estáticos

Diagrama de Clases

En el diagrama de clases como ya hemos comentado será donde definiremos las características de cada una de las clases y relaciones de dependencia y generalización. Es decir, es donde daremos rienda suelta a nuestros conocimientos de diseño orientado a objetos, definiendo las clases e implementando las ya típicas relaciones de herencia y agregación.

Este diagrama sirve para visualizar las relaciones entre las clases que involucran el sistema, las

cuales pueden ser asociativas, de herencia, de uso y de contenido.

Se utiliza cuando necesitamos realizar un Análisis de Dominio: El analista se entrevista con el cliente con el objetivo de conocer las entidades principales en el dominio del cliente. Durante la conversación entre el cliente y el analista se deben tomar apuntes. Desde estos apuntes, se buscarán las clases para los objetos del modelo buscando los sustantivos (ej: proveedor, pedido, factura, etc.) y convirtiéndolos en clases. Después se verá que algunos de estos sustantivos pueden ser atributos de otros en vez de entidades por si mismas. También se buscarán los métodos para estas clases buscando los verbos (ej: Calcular, imprimir, Agregar,..)

Elementos

Un diagrama de clases esta compuesto por los siguientes elementos:

? Clase: atributos, métodos y visibilidad.

? Relaciones: Herencia, Asociación, Ensamblado y Uso.

Clase

Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones: En donde:

? Superior: Contiene el nombre de la Clase

? Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase

(pueden ser private, protected o public).

?? Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo:

Una Cuenta Corriente que posee como característica:

? Balance

Puede realizar las operaciones de:

? Depositar

? Girar

? y Balance

El diseño asociado es:

Atributos

Un atributo representa alguna propiedad de la clase que se encuentra en todas las instancias de la clase. Los atributos pueden representarse solo mostrando su nombre, m ostrando su nombre y su tipo, e incluso su valor por defecto.

Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:

Los atributos definen la estructura de una clase y de sus correspondientes objetos. El atributo define el valor de un dato para todos los objetos pertenecientes a una clase.

Ejemplo: Nombre, edad, peso, son atributos de la clase persona. Color, precio, modelo, son atributos de la clase automóvil.

Los atributos corresponden a sustantivos y sus valores pueden ser sustantivos o adjetivos. Ejemplo: Nombre, edad, color, son sustantivos. Juan, 24, son sustantivos, y verde es un adjetivo.

Se debe definir un valor para cada atributo de una clase. Los valores pueden ser iguales o distintos en los diferentes objetos. No se puede dar un valor en un objeto si no existe un atributo correspondiente en la clase.

Ejemplo: el valor del atributo edad puede ser "24" para l os objetos Juan Pérez y María López, y

"15" para Ramón Martínez.

Dentro de una clase, los nombre de los atributos deben ser únicos (aunque puede aparecer el mismo nombre de atributo en diferentes clases).

Ejemplo: Las clases persona y compañía pueden tener ambas un atributo dirección, en cambio no pueden existir dos atributos llamados dirección dentro de la clase persona.

Los atributos no tienen ninguna identidad, al contrario de los objetos.

Ejemplo: Los atributos nombre y edad de la clase persona tienen v alores simples. El valor para nombre puede ser "Juan" o "María", mientras que el valor para edad puede ser "17" o "25". (Nótese que pudieran existir dos objetos distintos con exactamente el mismo nombre y edad, donde estos identificarían dos personas distintas.)

Un atributo como se ha definido en esta sección se conoce también como atributo básico.

Diagrama de clases, para la clase Persona, conteniendo diferente nivel de detalle.

Identificadores

En el momento de incluir atributos en la descripción de una clase se debe distinguir entre los atributos los cuales reflejan las características de los objetos en el mundo real, y los identificadores los cuales son utilizados exclusivamente por razones de implementación. Estos identificadores internos del sistema no deben ser incluidos como atributos.

Ejemplo: Número del Seguro Social, o número de la licencia de conducir, son identificadores

válidos del mundo real, en cambio un identificador para distinguir entre objetos de tipo persona no se debe incluir en el diagrama. En la siguiente figura se muestra la forma incorrecta de incluir un identificador ("identificador : ID") en la clase del objeto, seguido por la forma correcta (omitido).

Atributos Derivados

Los atributos básicos son atributos independientes dentro del objeto. En contraste, los atributos derivados son atributos que dependen de otros atributos. Los atributos derivados dependen de otros atributos del objeto, los cuales pueden ser básicos o derivados. La notación es una diagonal como prefijo del atributo, como se muestra en la siguiente figura:

Ejemplo: El Area de un Rectángulo se puede calcular conociendo su Ancho y Largo, por lo cual no se define como una atributo básico de la caja, sino como un atributo derivado:

Restricciones de Atributos

Los valores de los atributos de una clase pueden restringirse. La notación para una restricción es incluir, por debajo de la clase y entre corchetes, la restricción para los valores del atributo, como se muestra en la siguiente figura

Ejemplo: Un Rectángulo puede restringir que su Ancho y Largo sean siempre iguales, lo que es equivalente a un Cuadrado. Así mismo, el Area del Rectángulo está definida como el Ancho por el Largo. Las dos restricciones se muestran a continuación:

Métodos

Un método u operación es la implementación de un servicio de la clase, que muestra un comportamiento común a todos los objetos. En resumen es una función que le indica a las instancias de la clase que hagan algo.

Las operaciones son funciones o transformaciones que se aplican a todos los objetos de una clase

particular. La operación puede ser una acción ejecutada por el objeto o sobre el objeto.

Ejemplo: Arrojar, atrapar, inflar, y patear, son operaciones para la clase pelota. Abrir, cerrar, ocultar, y dibujar, son operaciones para la clase ventana.

Las operaciones deben ser únicas dentro de una misma clases, aunque no necesariamente para diferentes clases.

Ejemplo: Las clases pelota y libro pueden las dos tener operaciones de comprar, pero no pueden

tener cada una dos operaciones comprar.

No se debe utilizar el mismo nombre para operaciones que tengan un significado totalmente diferente.

Ejemplo: No se debe utilizar el mismo nombre invertir para la operación de invertir una figura y para la operación de invertir una matriz, ya que son operaciones totalmente diferentes. Invertir una figura es rotarla por 180 grados, mientras que invertir una matriz M es encontrar su inverso N, para que MxN = 1. Se deben usar nombres diferentes, como invertir-figura e invertir-matriz.

Las operaciones pueden tener argumentos, o sea, una lista de parámetros, cada uno con un tipo, y pueden también devolver resultados, cada uno con un tipo.

Ejemplo: En la siguiente figura se muestra dos clases, Figura y Archivo, conteniendo atributos y operaciones. Mover y Rotar son operaciones de Figura conteniendo los argumentos V de tipo vector y Angulo, respectivamente. Ambas operaciones devuelven un resultado de tipo Booleano el cual devuelve un valor de Cierto o Falso (True o False).

Imprimir es una operación de Archivo conteniendo un argumento D de tipo dispositivo que pued e ser el nombre de una impresora, y el número N de copias a imprimir. El resultado puede ser un valor booleano.

Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:

Relaciones entre Clases

Existen tres relaciones diferentes entre clases, Dependencias, Generalización y Asociación. En las relaciones se habla de una clase destino y de una clase origen. La origen es desde la que se realiza la acción de relacionar. Es decir desde la que parte la flecha, la destino es la que recibe la flecha.

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacion ar dos

o más clases (cada uno con características y objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, es decir especifica cuantas instancias de una clase se pueden relacionar a una sola instancia de otra clase.

Se anotan en cada extremo de la relación y éstas pueden ser:

Diagrama de clases describiendo una multiplicidad de "muchos-muchos".

La notación para representar una relación opcional, donde la multiplicidad es "uno" o "cero", escribiendo una relación opcional, 0 o 1. Esto significa que dos objetos pueden o no estar conectados, y si lo están corresponden a una multiplicidad de 1.

Diagrama de clases describiendo una multiplicidad "opcional".

Herencia (Especialización/Generalización)

Las clases con atributos y operaciones comunes se pueden organizar de forma jerárquica, mediante la herencia. La herencia es una abstracción importante para compart ir similitudes entre clases, donde todos los atributos y operaciones comunes a varias clases se pueden compartir por medio de la superclase, una clase más general. Las clases más refinadas se conocen como las subclases.

Ejemplo: Las Impresoras Láser, de Burbuja, y de Matriz, son todas subclases de la superclase Impresora. Los atributos generales de una Impresora son el Modelo, Velocidad, y Resolución, mientras que sus operaciones son Imprimir y Alimentar.

La Herencia es útil para el modelo conceptual al igual que para la implementación. Como modelo conceptual da buena estructuración a las clases. Como modelo de implementación es un buen

vehículo para no replicar innecesariamente el código. Generalización define una relación entre una clase más generalizada, y una o más versiones refinadas de ella.

Ejemplo: La clase Impresora es una generalización de las clases Impresoras Láser, de Burbuja, y

de Matriz.

Especialización define una relación entre una clase más general, y una o más versiones especializadas de ella.

Ejemplo: Impresoras Láser, de Burbuja, y de Matriz, son todas especializaciones de Impresoras.

La superclase generaliza a sus subclases, y las subclases especializan a la superclase. El proceso de especialización es el inverso de generalización. Una instancia de una subclase, o sea un objeto, es también una instancia de su superclase.

Ejemplo: Cuando se crea un objeto de tipo Impresora Láser, este objeto incluye toda la información descrita en la subclase Impresora Láser, al igual que en la superclase Im presora; por lo tanto se considera que el objeto es una instancia de ambas.

La herencia es transitiva a través de un número arbitrario de niveles. Los ancestros de una clase son las superclases de una clase en cualquier nivel superior de la jerarquía, y los descendientes de una clase son las subclases de una clase en cualquier nivel inferior de la jerarquía.

Ejemplo: Si además de Impresora de Burbuja, se define una clase más especializada com o Impresora de Burbuja Portátil, entonces Impresora e Impresora de Burbuja son ancestros de la clase Impresora de Burbuja Portátil, mientras que Impresora de Burbuja e Impresora de Burbuja Portátil son descendientes de Impresora.

La herencia indica que una subclase hereda los métodos y atributos especificados por una Super

Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected), ejemplo:

En la figura se especifica que Auto y Camioneta heredan de Vehículo, es decir, Auto posee las

Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable,

en cambio Camioneta también hereda las características de Vehículo (Precio, VelMax, etc) pero posee como particularidad propia Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método Características aplicable

a instancias de Vehículo, Auto y Camioneta, pues tiene definición publica, en cambio atributos como

Descapotable no son visibles por ser privados.

(Los nombres de atributos y operaciones deben ser únicos en la jerarquía de herencia.)

Ejemplo: Una Impresora de Burbuja Portátil incorpora todas las características, primero de una Impresora, y luego de una Impresora de Burbuja, conteniendo valores para todos los atributos ancestrales y pudiéndose aplicar todas las operaciones ancestrales.

La generalización se puede extender a múltiples niveles de jerarquías, donde una clase hereda de su superclase, que a su vez hereda de otra superclase, hacia arriba en la jerarquía. En otras palabras, las relaciones entre subclases y superclases son relativas. La herencia define una jerarquía de clases donde existen ancestros y descendientes, que pueden ser directos o no.

Ejemplo: Un Barco tiene un Nombre, Fabricante, y Costo. Tipos especiales de Barco, como Velero, tienen además de estas características básicas, un Número de Velas, mientras que otro tipo especial de Barco, como Barco a Motor, tiene un Motor. Barco es la clase básica (la superclase) mientras que Velero y Barco a Motor son las clases refinadas (las subclases). Se debe definir las características básicas de los barcos una sola vez, y luego añadir detalles para veleros, barcos a motor, etc.

Diagrama de clases describiendo diferentes tipos de Mueble, Asiento y Mesa, con sus respectivas subclases.

Ejemplo: Una jerarquía conteniendo una superclase Mueble, y varias subclases Mesa y Asiento, puede ser extendida con nuevas subclases, como Mesa Circular, Mesa Rectangular, mientras que un Asiento puede extenderse con las subclases Silla, Sillón, y Taburete.

Cada clase tiene sus propios atributos los cuales se van especializando a medida que las clases son cada vez más especializadas. Nótese que no necesariamente todas las clases tienen que incluir

atributos.

si.

Asociación

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre

Una asociación describe la relación entre clases de objetos, y describe posibles ligas, donde una

liga es una instancia de una asociación, al igual que un objeto es una instancia de una clase.

Diagrama de clases conteniendo la asociación estudia-en entre Estudiante y Universidad.

Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.

Grado de la Asociación

El grado de una asociación se determina por el número de clases conectadas por la misma asociación. Las asociaciones pueden ser binarias, ternarias, o de mayor grado. Las asociaciones se consideran binarias si relacionan solo dos clases.

Ejemplo: La asociación entre Persona e Instituto es una asociación binaria.

Las asociaciones pueden ser de mayor grado si relacionan a la misma vez más de dos clases. Aparte de relaciones binarias, lo más común son relaciones ternarias (entre tres clases), relac iones de más alto nivel son mucho menos comunes. Mientras el grado de una relación aumenta, su comprensión se dificulta, y se debe considerar partir las relaciones en varias relaciones binarias.

Ejemplo: Puede existir una relación ternaria entre Estudiante, Profesor, y Universidad donde "un estudiante estudia con un profesor en una universidad".

El grado de las ligas corresponden al de las asociaciones.

Diagrama de clases describiendo una asociación ternaria entre Estudiante, Profesor y Universidad.

Asociaciones Reflexivas

Las asociaciones pueden ser reflexivas, relacionando distintos objetos de una misma clase. Ejemplo: Para una clase persona puede existir una asociación pariente que describe que dos

objetos de tipo persona, como Juan Pérez y Laura Pérez son parientes.

El grado de una asociación reflexiva puede ser binario, ternario, o de mayor grado, dependiendo del número de objetos involucrados.

Ejemplo: Para la clase persona puede existir una asociación ternaria entre tres personas donde uno es el abuelo, el otro es el hijo del abuelo, y el tercero es el nieto del abuelo.

Las asociaciones reflexivas relacionan distintos objetos de una misma clase.

Ejemplo: Juan Pérez es pariente-de Laura Pérez, donde ambos son objetos de tipo Persona, como se muestra en la Figura

Diagrama de instancias describiendo una asociación reflexiva objetos de la clase Persona.

Ejemplo: La asociación reflexiva pariente-de para la clase Persona se muestra en la siguient e figura

Diagrama de clases describiendo una asociación reflexiva para la clase Persona.

Atributos de Liga (o Asociación)

Al igual que un atributo de clase es propiedad de la clase, un atributo de asociación (o atributo de liga) es propiedad de una asociación. La notación es similar a la usada para los atributos de clases, excepto que se añade a la asociación, y no se incorpora un nombre de clase, como se muestra en la siguiente figura:

Ejemplo: Para una asociación entre Persona y Compañía, se puede definir los atributos salario y puesto como atributos de la asociación trabaja-para, como se muestra en la Figura de abajo:

Diagrama de clases para Persona y Compañía conteniendo los atributos de asociación salario y puesto.

Diagrama de objetos para Raúl González e IBM conteniendo el valor de $100,000 para el atributo de asociación salario, y gerente para el atributo de liga puesto.

Ensamblados: Agregación y Composición

Los ensamblados, en particular la agregación y composición, son formas especiales de asociación entre un todo y sus partes, en donde el ensamblado está compuesto por sus componentes. El ensamblado es el objeto central, y la estructura completa se describe como una jerarquía de contenido.

? Agregación:

(el objeto base utiliza al incluido para su funcionamiento). Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye.

? Composición:

(el Objeto base se construye a partir del objeto incluido). Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye.

Un ensamblado puede componerse de varias partes, donde cada relación se considera una relación separada. En el caso de agregación, las partes del ensamblado pueden aparecer en múltiples ensamblados. En el caso de composición, las partes del ensamblado no pueden ser compartidas entre ensamblados.

Ejemplo: Una Red de Computadoras se puede considerar un ensamblado, donde las Computadoras son sus componentes. Este también es un ejemplo de agregación, ya que las Computadoras pudieran ser partes de múltiples Redes de Computadoras a la vez. Adicionalmente, las Computadoras pueden existir independientemente de la existencia de la Red de Computadoras.

Ejemplo: Un Automóvil se puede también considerar un ensamblado, donde el Mot or y la

Carrocería son sus componentes. Este también es un ejemplo de composición, ya que el Motor y la Carrocería son partes del Automóvil, y a diferencia de la agregación, no pueden ser compartidos entre distintos Automóviles a la vez.

Adicionalmente, no tiene mucho sentido que el Motor y la Carrocería existan de manera independiente al Automóvil, por lo cual la composición refleja de manera importante, el concepto de propiedad.

El ensamblado tiene propiedades de transición: Si A es parte de B y B es part e de C; entonces A

es parte de C.

Ejemplo: Si el Motor es parte del Automóvil, entonces sus propiedades, como su posición y velocidad, están dadas por la posición y velocidad del Automóvil.

El ensamblado es antisimétrico: Si A es parte de B, entonces B no es parte de A. Estas propiedades se propagan entre el ensamblado y sus componentes.

Ejemplo: Si el Motor es parte del Automóvil, entonces el Automóvil no es parte del Motor.

? Se considera un ensamblado y no una asociación regular:

? Si se puede usar la frase "parte-de" o "consiste-de" o "tiene";

? Si algunas operaciones en el todo se pueden propagarse a sus partes;

? Si algunos atributos en el todo se pueden propagar a sus partes;

El ensamblado es común en los objetos interfaz. En un sistema de ventanas, por ejemplo, una ventana puede consistir de botones, menús, y barras ("scrollbars"), cada una modelada por su propio objeto interfaz. El resultado es una estructura de interfaz en forma de árbol. La decisión de usar ensamblados es un poco arbitraria, y en la práctica no causa grandes problemas la distinción imprecisa entre agregación, composición y asociación, aunque es bueno ser consistente.

La notación para un ensamblado, en particular para un agregado, es un diamante adherido al lado del objeto correspondiente al ensamblado total, conectado por una línea a sus componentes, como se muestra en la siguiente figura

Ejemplo: Una computadora personal (PC) está compuesta por uno o varios monitores, un sistema, un teclado y opcionalmente un ratón. El sistema tiene un chasis, un procesador central (CPU), varias tarjetas de memoria (RAM), y opcionalmente un ventilador. El diagrama se muestra en la siguient e figura