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