Está en la página 1de 10

ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

ANÁLISIS Y DISEÑO ORIENTADO A


OBJETOS
UNIDAD 1. ANÁLISIS ORIENTADO A OBJETOS

MATERIAL DE PROFUNDIZACIÓN: ELEMENTOS


AVANZADOS DEL DIAGRAMA DE CLASES
ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

Índice
Introductorio ........................................................................................................................................................ 3
Tema 1. Elementos avanzados del diagrama de clases ............................................................................................. 3
1.1 Asociación ................................................................................................................................................... 3
1.2 Agregación .................................................................................................................................................. 4
1.3 Dependencia................................................................................................................................................ 5
1.4 Generalización ............................................................................................................................................. 6
1.5 Interfaces (realización) ................................................................................................................................. 8
Ideas claves......................................................................................................................................................... 10

UNIDAD 1 – Material de profundización: Elementos avanzados del diagrama de clases 2


ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

Introductorio
Los diagramas de estructura estática comprenden tanto a la fase de análisis, como la de diseño con el diagrama de
clases. Ambos son distintos conceptualmente, mientras el primero modela elementos del dominio, el segundo
presenta los elementos de la solución. Sin embargo, ambos comparten los mismos códigos para los elementos que los
forman (clases y objetos) y las relaciones que existen entre los mismos (asociaciones).

Los elementos básicos de un diagrama de clases están definidos por clases, atributos, métodos y relaciones. Por su
naturaleza, las clases se relacionan entre ellas dadas ciertas condiciones que, a su vez, permitirán indicar el tipo de
relación en la que participan.

Los diagramas de clase, sin embargo, han generado decenas de nuevos códigos para otros conceptos. Éstos no se
emplean con frecuencia, pero hay ocasiones en las que resultan muy úti les

Tema 1. Elementos avanzados del diagrama de clases


Los elementos básicos de un diagrama de clases están definidos por clases, atributos, métodos y relaciones. Por su
naturaleza, las clases se relacionan entre ellas dadas ciertas condiciones que, a su vez, permitirán indicar el tipo de
relación en la que participan. A continuación revisaremos algunas de estas relaciones.

1.1 Asociación
El tipo de relación asociación involucra una o más clases entre sí, indicando fundamentalmente la cardinalidad que
las une. La asociación define un acoplamiento débil entre clases, pues aquellas involucradas en la relación podrían
seguir siendo relativamente independientes una de otra. Esto quiere decir que la relación no es fuerte, lo que implica
que no se exige dependencia ni encapsulamiento.

Una forma avanzada de realizar las asociaciones cuando la relación entre dos o más clases se torna compleja, es
tratarlas como clase de asociación, lo que permite agregar atributos, operaciones y otras características. Con es te fin,
es necesario definir en ella características que no es posible encontrar en forma aislada en las clases que componen
dicha relación.

UNIDAD 1 – Material de profundización: Elementos avanzados del diagrama de clases 3


ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

Fi gura 1: rel a ci ón de a s oci a ci ón. Fuente: el a bora ci ón propi a .

La relación entre estudiante y habilidad es de cardinalidad muchos a muchos, esto alude a que “un estudiante puede
poseer una o muchas habilidades y esa habilidad o habilidades es posible encontrarlas en muchos estudiantes”. Resulta
conveniente, dada la naturaleza de la problemática, definir el nivel de competencia que generan esas habilidades.
Dado el detalle que se necesita ejemplificar, se define la clase asociación competencia, que por su naturaleza tiene
atributos propios que la definen y se deducen de la relación entre estudiante y habilidad.

1.2 Agregación
Otra forma de esquematizar las asociaciones es la agregación, que implica un mayor nivel de acoplamiento entre
clases, formando un vínculo más fuerte entre ellas, considerando que una realiza un papel más importante que la otra
en la relación. La agregación concibe una relación en la que participa un “todo” y “partes de”, vistos como clases
interactuantes. O sea, un objeto del tipo “todo” tiene o se compone de objetos “parte de”.

Existen tres tipos de agregación:

a) Agregación normal: corresponde a un caso particular de multiplicidad de una asociación, ya que la cardinalidad
del lado fuerte (del todo) es solo una. Se expresa dibujando una línea con un rombo sin rellenar al final de la misma,
del lado de la clase que contiene a la otra. Al igual que las relaciones normales, tiene un nombre, puede ser
navegable, poseer roles y por supuesto, cardinalidad.

Fi gura 2: rel a ci ón de a grega ci ón norma l . Fuente: el a bora ci ón propi a .

La figura muestra como clase fuerte a “aviación militar”, la que por naturaleza está compuesta por una o muchas
aeronaves. Nótese que si se llegasen a eliminar o crear instancias de la clase aeronave, sigue existiendo la clase
aviación militar. Esto sería leído correctamente como “la aviación militar se compone de una o muchas aeronaves
y esa aeronave corresponde a solo una aviación militar”. El rombo sin rellenar denota al tipo de agregación
normal. Se observa, además, que para que exista la aviación militar, deben existir aeronaves y no al revés.

b) Agregación compartida: corresponde a aquella asociación en la que cada objeto visto como “parte” puede
corresponder o pertenecer a varios objetos del tipo “todo”. Es representada de la misma manera que una
agregación normal. La diferencia esquemática para que sea considerada agregación compartida, es que del lado
del “todo” la multiplicidad sea mayor a uno.

Fi gura 3: rel a ci ón de a grega ci ón compa rti da . Fuente: el a bora ci ón propi a .

UNIDAD 1 – Material de profundización: Elementos avanzados del diagrama de clases 4


ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

En la imagen se ilustra una agregación compartida. Un remix está generalmente compuesto por varias bandas
sonoras, pero la banda sonora podría estar presente en varios remix (observa que hay * en ambos lados de la
relación). Visto de forma general, para que exista un remix, debe necesariamente haber varias bandas sonoras
que lo compongan, esto no implica que sea obligatorio crear varios remix. Observa que existe la cláusula {ordered}
en la relación, lo que quiere decir que tanto los objetos de la clase remix como los objetos de la clase banda
sonora, deben estar ordenados.

c) Agregación de descomposición: este tipo de asociación se expresa como una línea con un rombo relleno del lado
de la clase fuerte (todo). La multiplicidad en este lado puede ser 0..1, mientras que en el lado de “la parte” puede
ser cualquier intervalo. Este tipo de relación es de tipo muy fuerte.

Fi gura 4: rel a ci ón de a grega ci ón de des compos i ci ón . Fuente: el a bora ci ón propi a .

La figura ilustra una agregación de composición. El objeto ventana contiene muchos objetos tipo caja de texto,
listas desplegables, botones y menús. Todos los objetos antes mencionados existen solo cuando se crea la
instancia ventana, por lo tanto, la vida útil de dichos objetos coincide exactamente con el ciclo de vida del objeto
ventana. El rombo relleno en el lado del “todo”, junto con la multiplicidad 0..1 o 1, indica que se trata de una
agregación de composición. También se observa que la caja de tex to es parte de una ventana, pero una ventana
no está obligada a contener siempre objetos de este tipo. De igual forma podría apreciarse con cualquier objeto
que tenga una naturaleza parecida.

Se ha visto que los tipos de agregaciones implican el grado de acoplamiento entre clases, pero además
es posible indicar, en un diagrama de clases, dos tipos de relaciones que involucran conexiones
semánticas y clasificaciones de las clases de acuerdo a cierto tipo.

1.3 Dependencia
Una dependencia corresponde a una conexión semántica entre dos objetos, uno de ellos independiente y el otro
dependiente. Esto quiere decir que un cambio en el objeto independiente afectará al objeto dependiente (esto
también tiene relación con el nivel de acoplamiento de las clases).

UNIDAD 1 – Material de profundización: Elementos avanzados del diagrama de clases 5


ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

Las situaciones en las que se puede apreciar de mejor manera el concepto de dependencia, se observan cuando una
clase tiene por parámetro en un método un objeto que pertenece a otra clase, o cuando una clase accede a un objeto
global de otra clase, como también cuando una clase invoca un método cuyo ámbito de operación está definido en
otra clase. La forma esquemática de representar la dependencia está dada por una línea discontinua con una flecha
en el lado del elemento independiente.

Fi gura 5: rel a ci ón de dependenci a . Fuente: el a bora ci ón propi a .

Respecto a la figura, es posible indicar que:

 La clase A depende de la clase B.


 La clase A conoce de la existencia de la clase B, pero esta no conoce a la clase A.
 La clase A usa la clase B.
 Dado el nivel de dependencia, todo cambio en la clase B afectará a la clase A,

Para realizar la operación guardarArchivo(), el objeto discoDuro requiere necesariamente de una instancia del objeto
archivo. Es imposible realizar dicha operación si el parámetro requerido en el método no es otorgado. Esto quiere decir
que el objeto discoDuro usa el objeto archivo. Por su parte, el objeto archivo no está obligado a utilizar el medio
discoDuro, pues no es el único dispositivo de almacenamiento existente. Se puede agregar que e l objeto archivo, al
ser modificado, afectará al objeto discoDuro debido a la naturaleza de la operación.

1.4 Generalización
La generalización corresponde a un tipo relación de clasificación entre un objeto genérico y otro específico. Es usada
por clases, casos de uso y también en el modelado de paquetes. El concepto asociado a generalización usado
normalmente corresponde a “herencia” entre clases. La clase general se conoce como “clase padre” o “superclase”,
mientras las clases específicas son conocidas como “subclases” o “clases derivadas”.

Los atributos, asociaciones y métodos son heredados. Además, todos los elementos que incluyan visibilidad pública en
la superclase, también lo harán en las subclases. Es importante mencionar que los atributos y métodos que tengan
visibilidad privada, también serán heredados pero no podrán ser vistos en la subclase.

Cuando los elementos definidos en la superclase tienen el modificador protegido, pueden ser vistos desde fuera de la
clase, pero solo en el caso que estas sean subclases de las clases en las que fueron declarados. Esto es pertinente de
realizar con el propósito de reducir la visibilidad de los elementos a otras clases que no participan de la relación y
además, por temas de seguridad al programar la solución en algún lenguaje orientado a objetos.

Para representar la relación de generalización, se usa una línea continua desde la clase más específica (subclase) hacia
la clase general (superclase), con un triángulo sin rellenar en el extremo final que va hacia esta última. Aquellas clases

UNIDAD 1 – Material de profundización: Elementos avanzados del diagrama de clases 6


ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

generales que no poseen instancias (sin objetos) son denominadas “abstractas”, normalmente utilizadas solo para
generar subclases, dado que, por naturaleza, no es posible definir objetos al nivel de la superclase.

La utilización de niveles de jerarquía en un diagrama de clases dependerá en su totalidad de la naturaleza del problema
y de las condiciones reales que se necesite modelar. Es por esto que puede implementarse un diagrama sencillo que
no demande este tipo de relación y en otros casos, puede ser necesario un mayor nivel de detalle, en donde se requiera
la utilización de un gran número de subclases.

Fi gura 6: rel a ci ón de genera l i za ci ón . Fuente: el a bora ci ón propi a .

La figura muestra la clase persona asociada con la clase vehículo, esto quiere decir que la persona conduce un vehículo.
La clase vehículo es abstracta. Nótese que el nombre de la clase y los métodos están escritos en cursiva, esto es una
notación que efectivamente indica que la clase, los atributos o métodos pueden ser abstractos. En algunos productos
de software que permiten modelar diagramas de clases, se utiliza la notación {abstract} a continuación del elemento,
pero su significancia es exactamente la misma.

Se puede apreciar que los objetos automóvil y barco son “tipos” de vehículos que podrían ser declarados en un mayor
nivel de detalle, pero con el ejemplo se quiere indicar que, independiente a la naturaleza de estos tipos, ambos tendrán
por herencia las características de la clase padre como atributos, métodos y relaciones de la clase vehículo. Esto resulta
interesante desde el punto de vista de su utilización, ya que en realidad las personas no conducen vehículos, sino
“tipos” de vehículos. En el diagrama es posible apreciar, además, un elemento denominado “notas”, que se representa
como un rectángulo con el borde superior derecho doblado, el cual sirve para representar aclaraciones al diagrama o
restricciones de los elementos seleccionados.

Hasta ahora se ha visto como las clases se pueden relacionar en lo semántico (dependencia) y en la
clasificación o tipos (generalización), pero es necesario acotar que, a nivel de implementación, un
diagrama de clases puede contener clases que no necesariamente definen todo lo que ha de realizarse
para su correcto funcionamiento. Es por ello que se agrega un nuevo elemento respecto a las
relaciones entre clases: las interfaces.

UNIDAD 1 – Material de profundización: Elementos avanzados del diagrama de clases 7


ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

1.5 Interfaces (realización)


Una interfaz describe solo operaciones abstractas, las que en su conjunto especifican el comportamiento de algún
elemento como clase, paquete o componente, que puede elegir soportar implementando la interfaz.

La diferencia entre una clase y una interfaz es que, declarativamente hablando, no especifican n inguna estructura,
esto quiere decir que no tienen atributos, tampoco contienen la implementación de los métodos declarados. Los
métodos declarados en la interfaz pueden tener visibilidad y restricciones, además, es posible que las interfaces
participen en relaciones de asociación, dependencia y generalización. Para representar gráficamente una interfaz se
utiliza un círculo pequeño con un nombre bajo él. Para conectar objetos a ella se utiliza una línea continua que
representa una relación de asociación cuya multiplicidad es 1..1.

Fi gura 6: i nterfa z. Fuente: el a bora ci ón propi a .

Las clases ServidordeArchivos y ServidordeImpresion implementan los métodos definidos en las interfaces
enviarArchivo y priorizar, esto quiere decir que todas las operaciones definidas en cada interfaz deberá n ser resueltas
en cada clase que las implementa. Se puede resumir que las operaciones definidas en ambas clases son las mismas,
pero su funcionalidad va a depender de la implementación en cada una de ellas.

Cuando una clase utiliza una interfaz implementada en una clase determinada, se conecta al círculo de dicha interfaz
mediante una relación de dependencia. Esta dependencia puede estar dada por una línea punteada o bien por una
línea continua que termina en un semicírculo en el objeto que define la inte rfaz.

Fi gura 7: rel a ci ón de dependenci a en l a i nterfa z. Fuente: el a bora ci ón propi a .

UNIDAD 1 – Material de profundización: Elementos avanzados del diagrama de clases 8


ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

En este ejemplo es posible apreciar que la clase A implementa las interfaces iterable y listener, por su parte la clase C
implementa la interfaz serializable. La clase B “usa” las interfaces implementadas por A y C, por consiguiente, la clase
C al usar de esta forma las interfaces, depende solo de los métodos declarados en las interfaces, no de los métodos de
las clases que las implementan.

Cuando se necesita un mayor nivel de detalle se puede indicar el estereotipo <<interface>> asociado al objeto que
declara los métodos, indicando que corresponde a una interfaz. Ten presente que solo cambia la forma simbólica de
representar la interfaz.

Fi gura 5: repres enta ci ón grá fi ca de <<interface>>. Fuente: el a bora ci ón propi a .

Del esquema expuesto, se puede acotar lo siguiente:

 La interfaz flyer declara tres métodos que son: despegar(), aterrizar() y volar(). Estos métodos son abstractos,
por lo tanto deben ser implementados.
 El aeroplano es un tipo de vehículo (subclase).
 El hidroavión y el Boeing son tipos de aeroplano.
 El pájaro y la persona son tipos de animal.
 El aeroplano y el pájaro implementan la interfaz “flyer”. Esto quiere decir que cada clase debe describir como
se comportarán los métodos declarados en la interfaz.
 La persona y el pájaro heredan el método comer().
 El hidroavión y el Boeing heredan los métodos implementados por su clase padre. Esto quiere decir que por
herencia sabrán despegar(), aterrizar() y volar().
 Vehículo es superclase de aeroplano.
 Animal es superclase de persona y pájaro.

UNIDAD 1 – Material de profundización: Elementos avanzados del diagrama de clases 9


ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

Ideas claves
En resumen, el nivel de detalle en un diagrama de clases depende, en un alto porcentaje, de la cantidad de clases y del
tipo de relaciones que se generen entre ellas. Por lo tanto, no es posible definir a-priori cuántas clases, atributos,
operaciones, asociaciones y dependencias será necesario crear.

De igual modo, se debe tener presente que, mientras mayor sea el nivel de detalle con el que se define el diagrama de
clases, mayor será el grado de comprensión a la hora de transformar este tipo de diagrama en líneas de programación.

UNIDAD 1 – Material de profundización: Elementos avanzados del diagrama de clases 10

También podría gustarte