Introducción a la progrogramación orientada a objetos - UML

Introducción a la
Programación.
Unidad III: Introducción a la
Programación Orientada a Objetos.

3.1 Elementos fundamentales de la programación orientada a objetos.
3.2 Representación gráfica (UML.)
Unidad III: Introducción a la
Programación Orientada a Objetos.

Objetivos:
Conocer la filosofía de las clases.
Unidad II: Introducción a la
Programación Orientada a Objetos

Bibliografía
C++ para Ingeniería y
Ciencia. Editorial
Cengage Learning
Editores S. A. de C. V.
Segunda edición. 2007.
Gary J. Bronson. Ficha
9a . Páginas 64 – 88.

Bibliografía
Fundamentos de
Programación con el
Lenguaje de Programación
C++. Dpto. Lenguajes y
CC. Computación E.T.S.I.
Informática. 2017. Vicente
Benjumea y Manuel
Roldán. Capítulo 13.
Páginas: 167 - 168.

Bibliografía
C++ / OOP. Un enfoque
práctico. Ricardo Devis
Botella. Capítulo 1.
Páginas: 7 – 10, 13 – 15,
17 – 20, 22 – 26.

Diagrama de clases.
En ingeniería de software, un diagrama de clases en Lenguaje Unificado
de Modelado (UML) es un tipo de diagrama de estructura estática que
describe la estructura de un sistema mostrando las clases del sistema,
sus atributos, operaciones (o métodos), y las relaciones entre los
objetos.
 Miembros: UML proporciona mecanismos para representar los
miembros de la clase, como atributos y métodos, así como
información adicional sobre ellos.
 Visibilidad: Para especificar la visibilidad de un miembro de la clase
(es decir, cualquier atributo o método), se coloca uno de los siguientes
signos delante de ese miembro

Diagrama de clases.
+ Público
- Privado
# Protegido
/ Derivado (se puede combinar con otro)
~ Paquete

Diagrama de clases.
El diagrama UML de clases está formado por los elementos: clases,
relaciones e interfaces.
Las clases son el elemento principal del diagrama y representa, como su
nombre indica, una clase dentro del paradigma de la orientación a
objetos. Este tipo de elementos normalmente se utilizan para representar
conceptos o entidades del “negocio”. Una clase define un grupo de
objetos que comparten características, condiciones y significado. La
manera más rápida para encontrar clases sobre un enunciado, sobre una
idea de negocio o, en general, sobre un tema concreto es buscar los
sustantivos que aparecen en el mismo. Por poner algún ejemplo, algunas
clases podrían ser: Animal, Persona, Mensaje, Expediente…

Diagrama de clases.
Es un concepto muy amplio y resulta fundamental identificar de forma
efectiva estas clases, en caso de no hacerlo correctamente se obtendrán
una serie de problemas en etapas posteriores, teniendo que volver a
hacer el análisis y perdiendo parte o todo el trabajo que se ha hecho
hasta ese momento.
Bajando de nivel una clase está compuesta por tres elementos: nombre
de la clase, atributos, funciones. Estos elementos se incluyen en la
representación (o no, dependiendo del nivel de análisis).

Diagrama de clases.
Para representar la clase con estos elementos se utiliza una caja que es
dividida en tres zonas utilizando para ello lineas horizontales:
La primera de las zonas se utiliza para el nombre de la clase. En caso de
que la clase sea abstracta se utilizará su nombre en cursiva.
La segunda de las zonas se utiliza para escribir los atributos de la clase,
uno por línea y utilizando el siguiente formato:
visibilidad nombre_atributo : tipo = valor-inicial { propiedades }
Aunque esta es la forma “oficial” de escribirlas, es común simplificando
únicamente poniendo el nombre y el tipo o únicamente el nombre.
La última de las zonas incluye cada una de las funciones que ofrece la
clase. De forma parecida a los atributos, sigue el siguiente formato:

Diagrama de clases.
Tanto los atributos como las funciones incluyen al principio de su
descripción la visibilidad que tendrá. Esta visibilidad se identifica
escribiendo un símbolo y podrá ser:
(+) Pública. Representa que se puede acceder al atributo o función
desde cualquier lugar de la aplicación.
(-) Privada. Representa que se puede acceder al atributo o función
únicamente desde la misma clase.
(#) Protegida. Representa que el atributo o función puede ser accedida
únicamente desde la misma clase o desde las clases que hereden de
ella (clases derivadas).
Pueden incluirse otros tipos de visibilidad, según el lenguaje de
programación que se esté usando. Por ejemplo: (/) Derivado o (~)
Paquete.

Diagrama de clases.
Las relaciones en el diagrama de clases tienen varias propiedades, que
dependiendo la profundidad que se quiera dar al diagrama se
representarán o no. Estas propiedades son las siguientes:
 Multiplicidad. Es decir, el número de elementos de una clase que
participan en una relación. Se puede indicar un número, un rango…
Se utiliza n o * para identificar un número cualquiera.
 Nombre de la asociación. En ocasiones se escriba una indicación de
la asociación que ayuda a entender la relación que tienen dos clases.
Suelen utilizarse verbos como por ejemplo: “Una empresa contrata a n
empleados”

Diagrama de clases.
Tipos de relaciones
Un diagrama de clases incluye los siguientes tipos de relaciones:
 Asociación.
 Agregación.
 Composición.
 Dependencia.
 Herencia.

Diagrama de clases.
Tipos de relaciones
 Asociación.
 Agregación.
 Composición.
 Dependencia.
 Herencia.
Las relaciones de agregación se basan en
la idea de observar o entender un objeto
como una composición de otros objetos.
Desde nuestro punto de vista, las relaciones
de agregación se entenderán como relaciones
en las cuales una serie de clases aparecen
como tipos de los atributos de otra clase.

Diagrama de clases.
Tipos de relaciones
 Asociación.
 Agregación.
 Composición.
 Dependencia.
 Herencia.
Estas relaciones se conocen también como
relaciones “todo - partes”. El “todo” está
representado por la clase que aglutina a
las otras clases, y las “partes” están dadas
por las diversas clases que aparecen.

Diagrama de clases.
Tipos de relaciones
 Asociación.
 Agregación.
 Composición.
 Dependencia.
 Herencia.
La mejor forma de identificar si nos
encontramos ante una relación de agregación
es preguntarnos si la clase que queremos
definir “tiene un” (en Inglés, “has-a”) atributo
de la otra clase que estemos usando (de ahí
que en ciertas referencias se definan como
relaciones “has - a”).

Diagrama de clases.
Asociación
Este tipo de relación es el más común y se utiliza para representar
dependencia semántica. Se representa con una simple linea continua
que une las clases que están incluidas en la asociación.
Un ejemplo de asociación podría ser: “Una mascota pertenece a una
persona”.

Diagrama de clases.
Agregación
Es una representación jerárquica
que indica a un objeto y las partes
que componen ese objeto. Es
decir, representa relaciones en las
que un objeto es parte de otro,
pero aun así debe tener existencia
en sí mismo.
Se representa con una línea que
tiene un rombo en la parte de la
clase que es una agregación de la
otra clase (es decir, en la clase
que contiene las otras).

Diagrama de clases.
Agregación

Diagrama de clases.
Agregación
“CircunferenciaCentrada” es el resultado de la agregación de la clase
“Punto”, que permite representar el centro de la circunferencia, a la
clase “CircunferenciaCentrada”. De nuevo, se puede examinar la
validez de la relación entre ambas clases por medio del test: Una
“CircunferenciaCentrada” “tiene - un” atributo de tipo “Punto”. Además,
el diagrama de clases UML nos indica también cómo debemos
implementar posteriormente la relación de agregación que introduce.
En este caso, se hará por medio de un atributo de la clase “Punto”
dentro de la clase “CircunferenciaCentrada”.

Diagrama de clases.
Agregación
“CircunferenciaCentrada” resultado de agregar un atributo de la clase
“Punto” y un atributo de la clase “Circunferencia”. Esta representación
no tiene por qué ser errónea, pero podemos observar como gran parte
de los métodos que hemos requerido de la clase
“CircunferenciaCentrada” se encuentran replicados en la clase
“Circunferencia”. Una representación más adecuada será considerar
la clase “CircunferenciaCentrada” como una clase que “tiene un”
Punto (relación de agregración) y que “es una” “Circunferencia”
(relación de herencia), lo cual permitirá acceder directamente a todos
los métodos de la clase “Circunferencia”.

Diagrama de clases.
Agregación
Un ordenador es el resultado de “agregar” una serie de componentes,
como un “CPU”, una “Pantalla”, un “Teclado” y un “Raton” (y quizá
algunos adicionales). De nuevo podemos aplicar el “test” de un objeto
de la clase “Odenador” “tiene – un” “CPU” y “tiene – una” “Pantalla”, y
“tiene – un” “Teclado” y “tiene – un” “Raton”.

Diagrama de clases.
Composición
La composición es similar a la agregación, representa una relación
jerárquica entre un objeto y las partes que lo componen, pero de una
forma más fuerte. En este caso, los elementos que forman parte no
tienen sentido de existencia cuando el primero no existe. Es decir,
cuando el elemento que contiene los otros desaparece, deben
desaparecer todos ya que no tienen sentido por sí mismos sino que
dependen del elemento que componen. Además, suelen tener los
mismos tiempo de vida. Los componentes no se comparten entre varios
elementos, esta es otra de las diferencias con la agregación. Se
representa con una linea continua con un rombo relleno en la clase que
es compuesta. Un ejemplo de esta relación sería: “Un vuelo de una
compañía aerea está compuesto por pasajeros, que es lo mismo que
decir que un pasajero está asignado a un vuelo”

Diagrama de clases.
La diferencia entre agregación y composición es semántica, por lo que
a veces no está del todo definida. Ninguna de las dos tienen análogos
en muchos lenguajes de programación (como por ejemplo Java).
Un “agregado” representa un todo que comprende varias partes; de
esta manera, un Comité es un agregado de sus Miembros. Una reunión
es un agregado de una agenda, una sala y los asistentes. En el
momento de la implementación, esta relación no es de contención. (Una
reunión no contiene una sala). Del mismo modo, las partes del
agregado podrían estar haciendo otras cosas en otras partes del
programa, por lo que podrían ser referenciadas por varios objetos que
nada tienen que ver.

Diagrama de clases.
En otras palabras, no existe una diferencia de nivel de implementación
entre la agregación y una simple relación de “usos”. En ambos casos,
un objeto tiene referencias a otros objetos. Aunque no existe una
diferencia en la implementación, definitivamente vale la pena capturar la
relación en el diagrama UML, tanto porque ayuda a comprender mejor
el modelo de dominio, como porque puede haber problemas de
implementación que pueden pasar desapercibidos. Podría permitir
relaciones de acoplamiento más estrictas en una agregación de lo que
haría con un simple “uso”, por ejemplo.

Diagrama de clases.
La composición, por otro lado, implica un acoplamiento aún más estricto
que la agregación, y definitivamente implica la contención. El requisito
básico es que, si una clase de objetos (llamado “contenedor”) se
compone de otros objetos (llamados “elementos”), entonces los
elementos aparecerán y también serán destruidos como un efecto
secundario de crear o destruir el contenedor. Sería raro que un
elemento no se declare como privado. Un ejemplo podría ser el nombre
y la dirección del Cliente. Un cliente sin nombre o dirección no tiene
valor. Por la misma razón, cuando se destruye al cliente, no tiene
sentido mantener el nombre y la dirección. (Compare esta situación con
la agregación, donde destruir al Comité no debe causar la destrucción
de los miembros, ya que pueden ser miembros de otros Comités).

Diagrama de clases.
En la composición (o también agregación fuerte), los objetos agregados
no tienen sentido fuera del objeto resultante. También se puede
entender la composición como una relación en la que, los objetos
siendo agregados, deben dejar de existir cuando lo hace el objeto
compuesto.
Otro ejemplo, que podemos considerar de composición es la relación
que existe entre un libro y sus páginas.

Diagrama de clases.
Dependencia
Se utiliza este tipo de relación
para representar que una
clase requiere de otra para
ofrecer sus funcionalidades.
Es muy sencilla y se
representa con una flecha
discontinua que va desde la
clase que necesita la utilidad
de la otra flecha hasta esta
misma.
Un ejemplo de esta relación
podría ser la siguiente:

Diagrama de clases.
Herencia
Otra relación muy común en el
diagrama de clases es la herencia.
Este tipo de relaciones permiten que
una clase (clase hija o subclase)
reciba los atributos y métodos de
otra clase (clase padre o
superclase). Estos atributos y
métodos recibidos se suman a los
que la clase tiene por sí misma. Se
utiliza en relaciones “es un”. Un
ejemplo de esta relación podría ser
la siguiente: Un pez, un perro y un
gato son animales.

Diagrama de clases.
Relaciones
Una relación es un término general que abarca los tipos específicos de
conexiones lógicas que se pueden encontrar en los diagramas de clases
y objetos. UML presenta las siguientes relaciones:

Diagrama de clases.
Asociación
Una asociación binaria (entre dos clases) normalmente se representa
con una línea continua. Una misma asociación puede relacionar
cualquier número de clases. Una asociación que relacione tres clases se
llama asociación ternaria.
A una asociación se le puede asignar un nombre, y en sus extremos se
puede hacer indicaciones, como el rol que desempeña la asociación, los
nombres de las clases relacionadas, su multiplicidad, su visibilidad, y
otras propiedades.
Hay cuatro tipos diferentes de asociación: bidireccional, unidireccional,
agregación (en la que se incluye la composición) y reflexiva. Las
asociaciones unidireccional y bidireccional son las más comunes.

Diagrama de clases.
Por ejemplo, una clase vuelo se asocia con una clase avión de forma
bidireccional. La asociación representa la relación estática que
comparten los objetos de ambas clases.

Diagrama de clases.
Agregación
La agregación o agrupación es una variante de la relación de asociación
“tiene un”: la agregación es más específica que la asociación. Se trata de
una asociación que representa una relación de tipo parte-todo o parte-
de.

Diagrama de clases.
Agregación
En el ejemplo, un Profesor 'tiene una' clase a la que enseña. Al ser un
tipo de asociación, una agregación puede tener un nombre y las mismas
indicaciones en los extremos de la línea. Pero, una agregación no puede
incluir más de dos clases; debe ser una asociación binaria. Se puede dar
cuando una clase es una colección o un contenedor de otras clases,
pero a su vez, el tiempo de vida de las clases contenidas no tienen una
dependencia fuerte del tiempo de vida de la clase contenedora (de el
todo). El contenido de la clase contenedora no se destruye
automáticamente cuando desaparece dicha clase. Todo este conjunto es,
semánticamente, un objeto extendido que es tratado como una única
unidad en muchas operaciones, aunque físicamente está hecho de
varios objetos más pequeños.

Diagrama de clases.
Composición
El almacén esta compuesto de
cuentas, si se elimina el
almacén las cuentas por si
solas no tienen sentido como
una entidad separada del
almacén y se eliminan también.
El rombo sin rellenar muestra
una relación de agregación: el
almacén tiene clientes, si el
almacén cierra los clientes irán
a otro, su razón de existir sigue
teniendo sentido sin el almacén.

Diagrama de clases.
Composición
La representación en UML de una relación de composición es mostrada
con una figura de diamante rellenado del lado del la clase contenedora,
es decir al final de la linea que conecta la clase contenido con la clase
contenedor.

Diagrama de clases.
Diferencias entre Composición y Agregación
 Relación de Composición
 Relación de Agregación (o Agrupación)

Diagrama de clases.
1. Cuando intentamos representar un todo y sus partes. Ejemplo, un
motor es una parte de un coche.
2. Cuando se elimina el contenedor, el contenido también es eliminado.
Ejemplo, si eliminamos una universidad eliminamos igualmente sus
departamentos.

Diagrama de clases.
Ejemplo, el modelo de motor MTR01 es parte del coche MC01. Como tal,
el motor MTR01 puede hacer parte de cualquier otro modelo de coche,
es decir si eliminamos el coche MC01 no es necesario eliminar el motor
pues podemos usarlo en otro modelo.
Cuando el contenedor es eliminado, el contenido usualmente no es
destruido. Ejemplo, un profesor tiene estudiantes, cuando el profesor
muere los estudiantes no mueren con él o ella.
Así, una relación de agregación es a menudo "clasificar" o "catalogar"
contenido para distinguirlo del todo "físico" del contenedor.

Diagrama de clases. Caso de Estudio: Cinemas
Usted ha sido invitado a liderar el análisis y diseño orientado a objetos
del sistema, que una empresa requiere para administrar todo lo referente
al manejo de una taquilla de un cinema. Haciendo una analogía, el
sistema que se debe desarrollar es similar al sistema de Cine Paisito,
con algunas modificaciones que se describen a continuación. A nuestro
sistema le llamaremos MOVIESOFT.
El usuario le ha dicho que diariamente se proyectan películas en
diferentes centros llamados multiplex (que tienen un conjunto de salas), y
en diferentes horarios. Una película puede estar en diferentes salas en
un mismo multiplex. Una película proyectada debe almacenar toda la
información referente a sí misma como es: el director, la duración, el
idioma, un resumen, y otros datos básicos.

Las salas almacenan entre sus datos, la información de la capacidad de
ocupación. Es importante distinguir que puede exista en una sala
diferentes tipos de localidades, (ejemplo, general, preferencial, cinebar,
fumador, sin que estos sean los únicos tipos posibles.) El sistema debe
permitir realizar reservas de boletas para entrar a ver cualquier película.
Para esto, los clientes deben estar registrados ya que por seguridad un
cliente no puede usar una tarjeta de crédito que no esté registrada. Un
cliente registrado puede realizar reservas que serán cargadas
inmediatamente a su cuenta. Las reservas pueden ser máximo para 5
boletas. Cada sala de un multiplex, en cada una de sus localidades
puede manejar un precio de boleta diferente. El precio de las reservas
depende del precio que maneje cada sala en su localidad, y se
incrementa un valor determinado (cien córdobas) si la reserva se hace
por teléfono. Si la reserva es por Internet, el precio no se incrementa.

El sistema debe permitir realizar descuentos en compras al interior de los
multiplex. Ya que dentro de los multiplex el cliente puede adquirir comida,
y artículos de recuerdo de las películas proyectadas, el sistema debe
permitir registrar las compras de los clientes registrados y ofrecer un
descuento.
La venta de boletas en taquilla funciona de manera muy sencilla. Un
cliente se acerca a una taquilla y puede comprar
boletas para cualquier sala de cualquier multiplex en la misma ciudad. El
sistema debe controlar toda la información de las boletas vendidas para
cada película, cada sala, cada multiplex y cada localidad.

En esta primera definición de requerimientos del cliente, le ha dicho que
el sistema debe trabajar en una red que interconecte todos sus multiplex
a lo largo del país. Por ejemplo, una persona en San Carlos puede saber
exactamente las películas que se proyectan en Catarina, y hacer las
reservas que requiera. Para eso, el sistema de reservas debe trabajar
centralizado y con un sistema de seguridad que opere 7x24 (toda la
semana, todo el tiempo.)
La información debe centralizarse en una base de datos que maneja una
copia de seguridad local, y una remota. Cada multiplex maneja una base
de datos local donde almacena la información propia. Esto lo hace ya
que aunque todo el sistema debe funcionar como uno solo, cada
multiplex es una franquicia que se puede otorgar a una persona
diferente.

Introducción a la progrogramación orientada a objetos - UML

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Introducción a la progrogramación orientada a objetos - UML

Similar a Introducción a la progrogramación orientada a objetos - UML (20)

Más de Facultad de Ciencias y Sistemas

Más de Facultad de Ciencias y Sistemas (20)

Último

Último (20)

Introducción a la progrogramación orientada a objetos - UML