República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Universitaria, Ciencia y Tecnología

Instituto Universitario de Tecnología Agro Industrial Los Andes
Programa Nacional de Formación en Informática
Delicias – Estado Táchira

Charles López Villalta

15.437.745

Delicias noviembre 2018

1
 TABLA DE CONTENIDO

INTRODUCCION .................................................................................................... 4

INTRODUCCION A LA PROGRAMACION ORIENTADA A OBJETOS .................. 5

CONCEPTOS BASICOS DE LA POO .................................................................... 7

OBJETO............................................................................................................... 7

CLASE ................................................................................................................. 7

MENSAJE ............................................................................................................ 7

MÉTODO ............................................................................................................. 7

EVENTO .............................................................................................................. 8

FUNDAMENTOS DE LA PROGRAMACIÓN ORIENTADA A OBJETOS ................ 8

ABSTRACCIÓN ................................................................................................... 8

ENCAPSULAMIENTO ......................................................................................... 8

POLIMORFISMO ................................................................................................. 9

HERENCIA .......................................................................................................... 9

MODULARIDAD................................................................................................. 10

PRINCIPIO ......................................................................................................... 10

RECOLECCIÓN ................................................................................................. 10

DEFINICION DE UML ........................................................................................... 11

DIAGRAMAS UML ................................................................................................ 13

ESTRUCTURALES ............................................................................................ 13

DIAGRAMA DE CLASES ................................................................................... 13

DIAGRAMA DE COMPONENTES ..................................................................... 14

2
 DIAGRAMA DE ESTRUCTURA COMPUESTA ................................................. 14

DIAGRAMA DE IMPLEMENTACIÓN ................................................................. 15

DIAGRAMA DE OBJETOS ................................................................................ 15

DIAGRAMA DE PAQUETES ............................................................................. 15

DE COMPORTAMIENTO .................................................................................. 15

DIAGRAMAS DE ACTIVIDADES ....................................................................... 15

DIAGRAMA DE COMUNICACIÓN..................................................................... 15

DIAGRAMA DE PANORAMA DE INTERACCIONES ........................................ 16

DIAGRAMA DE SECUENCIA ............................................................................ 16

DIAGRAMA DE MÁQUINA DE ESTADOS ........................................................ 16

DIAGRAMA DE TEMPORIZACIÓN ................................................................... 16

DIAGRAMA DE CASO DE USO ........................................................................ 16

ELEMENTOS DEL DIAGRAMA DE CLASES ....................................................... 16

CLASE ............................................................................................................... 16

ATRIBUTOS Y MÉTODOS ................................................................................ 17

RELACIONES ENTRE CLASES ........................................................................ 18

HERENCIA ........................................................................................................ 18

AGREGACIÓN ................................................................................................... 19

ASOCIACIÓN .................................................................................................... 19

DEPENDENCIA O INSTANCIACIÓN ................................................................ 20

CONCLUSION ...................................................................................................... 21

3
 INTRODUCCION

La programación hoy en día se ha dividido en 2 partes, una es la

programación en base a código simple (esta puede ser en cualquier lenguaje de
programación) en donde solo se usan lineas de programación para que el software
manipule diversos datos y posteriormente el usuario manipula el software con más
lineas de programación para que se entreguen nuevos resultados.

La segunda es la programación orientada a objetos, esta es la más común

actualmente, se basa en la manipulación de datos, objetos, patrones y cualquier
elemento programable dentro de un software, su fin básicamente es que la
programación que se asigne pueda interactuar con uno o varios objetos
determinados y de esta manera poder tener un entorno interactivo que obedezca
las ordenes de un usuario con un simple clic y sin tener que escribir más lineas
dentro del código base. La programación orientada a objetos permite agrupar partes
específicas de la información dada a un grupo de objetos, por ejemplo se puede
realizar un programa en el cual se asigne un botón para que se ingrese una imagen,
dicho botón debe servir para abrir un directorio y obtener la imagen, tras este botón
hay varias lineas de código que esperan el momento en que se obtenga la imagen
para proceder con la siguiente acción o instrucción.

4
INTRODUCCION A LA PROGRAMACION ORIENTADA A OBJETOS

La Programación Orientada a Objetos (POO) es un paradigma de

programación que busca que nuestra forma de programar sea más cercana a la
forma como nos relacionamos en nuestro día a día.

Un paradigma de programación es una propuesta tecnológica adoptada por

una comunidad de programadores y desarrolladores cuyo núcleo central es
incuestionable en cuanto que únicamente trata de resolver uno o varios problemas
claramente delimitados. Wikipedia

El nombre de "Orientado a Objetos" se debe a que nuestro código creará

objetos que se encargarán de manipular los datos de entrada para así obtener datos
de salida. Estos objetos tendrán propiedades y métodos.

UNA FORMA NUEVA DE PENSAR

Debemos aclarar que POO no se trata de nuevas características que le

damos a un lenguaje de programación. Con POO nos estamos refiriendo a una
nueva forma de pensar. Lo que se acostumbra a ver es la programación
estructurada. En donde tenemos un problema y lo descomponemos en distintos sub
problemas para poder llegar a tener soluciones más pequeños y simples.

Cómo lo mencioné anteriormente. POO busca ver la programación como en

la vida real. Donde los objetos son similares a los objetos en la vida real.

5
Vamos a poner un ejemplo de nuestra vida cotidiana: Pensemos en un gato. Éste
tiene diferentes características, como su raza, nombre, color, tamaño, etc. El gato
también cuenta con diferentes acciones, como arañar, maullar, correr, etc.

En Programación Orientada a Objeto el gato sería un objeto. Las

características son las propiedades del objeto y las acciones vendrían a ser los
métodos.

Ahora veamos un ejemplo en programación. Tenemos un artículo creado.

Este artículo tiene diferentes propiedades como el nombre, cantidad de imágenes,
autor, etc. Y también contaría con métodos, tales como "compartir" el cual serviría
para enviar el artículo a diferentes redes sociales, otro método sería el actualizar el
artículo. Y así diferentes acciones que le demos.

Así como el artículo, para nuestro blog por ejemplo, tendremos diferentes
objetos. Y estos los crearemos con clases, que vendrían a ser algo así como los
moldes. Ya que nos ayudarán a crear distintos objetos.

NO OLVIDEMOS LAS HERENCIAS

Otra de las cosas que hacen que POO sea muy usado es la herencia. La
herencia sirve para crear objetos que tengan (hereden) las propiedades y métodos
de otro objeto.

Volvamos al ejemplo con la vida real. Tenemos un objeto llamado Ave, en el

que las propiedades serían color, tamaño de alas. Y uno de sus métodos sean volar.
La herencia haría que yo cree un objeto Paloma que herede todo lo del objeto Ave

6
y le agrega sus propias propiedades y métodos. También podemos crear el objeto
Gorrión y hará lo mismo que la paloma. Heredará cosas del Ave y le agregará los
suyos propios.

CONCEPTOS BASICOS DE LA POO

OBJETO
Instancia de una clase. Entidad provista de un conjunto de propiedades o
atributos (datos) y de comportamiento o funcionalidad (métodos), los mismos que
consecuentemente reaccionan a eventos. Se corresponden con los objetos reales
del mundo que nos rodea, o con objetos internos del sistema (del programa).

CLASE
Una clase se puede definir de las propiedades y comportamiento de un tipo
de objeto concreto. La instanciación es la lectura de estas definiciones y la creación
de un objeto a partir de ella.

MENSAJE
Una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus
métodos con ciertos parámetros asociados al evento que lo generó.

MÉTODO
Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se
desencadena tras la recepción de un "mensaje". Desde el punto de vista del
comportamiento, es lo que el objeto puede hacer. Un método puede producir un
cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo
mensaje para otro objeto del sistema.

7
EVENTO
Es un suceso en el sistema (tal como una interacción del usuario con la
máquina, o un mensaje enviado por un objeto). El sistema maneja el evento
enviando el mensaje adecuado al objeto pertinente. También se puede definir como
evento la reacción que puede desencadenar un objeto; es decir, la acción que
genera.

FUNDAMENTOS DE LA PROGRAMACIÓN ORIENTADA A

OBJETOS

ABSTRACCIÓN
Denota las características esenciales de un objeto, donde se capturan sus
comportamientos. Cada objeto en el sistema sirve como modelo de un "agente"
abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse"
con otros objetos en el sistema sin revelar "cómo" se implementan estas
características. Los procesos, las funciones o los métodos pueden también ser
abstraídos, y, cuando lo están, una variedad de técnicas son requeridas para
ampliar una abstracción. El proceso de abstracción permite seleccionar las
características relevantes dentro de un conjunto e identificar comportamientos
comunes para definir nuevos tipos de entidades en el mundo real. La abstracción
es clave en el proceso de análisis y diseño orientado a objetos, ya que mediante
ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad
o el problema que se quiere atacar.

ENCAPSULAMIENTO
Significa reunir todos los elementos que pueden considerarse pertenecientes
a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la
cohesión (diseño estructurado) de los componentes del sistema. Algunos autores

8
confunden este concepto con el principio de ocultación, principalmente porque se
suelen emplear conjuntamente.

POLIMORFISMO
Comportamientos diferentes, asociados a objetos distintos, pueden compartir
el mismo nombre; al llamarlos por ese nombre se utilizará el comportamiento
correspondiente al objeto que se esté usando. O, dicho de otro modo, las
referencias y las colecciones de objetos pueden contener objetos de diferentes
tipos, y la invocación de un comportamiento en una referencia producirá el
comportamiento correcto para el tipo real del objeto referenciado. Cuando esto
ocurre en "tiempo de ejecución", esta última característica se llama asignación
tardía o asignación dinámica. Algunos lenguajes proporcionan medios más
estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y
la sobrecarga de operadores de C++.

HERENCIA
Las clases no se encuentran aisladas, sino que se relacionan entre sí,
formando una jerarquía de clasificación. Los objetos heredan las propiedades y el
comportamiento de todas las clases a las que pertenecen. La herencia organiza y
facilita el polimorfismo y el encapsulamiento, permitiendo a los objetos ser definidos
y creados como tipos especializados de objetos preexistentes. Estos pueden
compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto
suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o
enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más
de una clase se dice que hay herencia múltiple; siendo de alta complejidad técnica
por lo cual suele recurrirse a la herencia virtual para evitar la duplicación de datos.

9
MODULARIDAD
Se denomina "modularidad" a la propiedad que permite subdividir una
aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales
debe ser tan independiente como sea posible de la aplicación en sí y de las
restantes partes. Estos módulos se pueden compilar por separado, pero tienen
conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan
la modularidad de diversas formas.

PRINCIPIO DE OCULTACIÓN
Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de
objeto expone una "interfaz" a otros objetos que especifica cómo pueden interactuar
con los objetos de la clase. El aislamiento protege a las propiedades de un objeto
contra su modificación por quien no tenga derecho a acceder a ellas; solamente los
propios métodos internos del objeto pueden acceder a su estado. Esto asegura que
otros objetos no puedan cambiar el estado interno de un objeto de manera
inesperada, eliminando efectos secundarios e interacciones inesperadas. Algunos
lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto
de una manera controlada y limitando el grado de abstracción. La aplicación entera
se reduce a un agregado o rompecabezas de objetos.

RECOLECCIÓN DE BASURA
La recolección de basura (garbage collection) es la técnica por la cual el
entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular
la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos.
Esto significa que el programador no debe preocuparse por la asignación o
liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la
liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que

10
se extendieron para soportar el Paradigma de Programación Orientada a Objetos
como C++ u Object Pascal, esta característica no existe y la memoria debe
desasignarse expresamente.

DEFINICION DE UML

UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de

Modelado”. Se trata de un estándar que se ha adoptado a nivel internacional por
numerosos organismos y empresas para crear esquemas, diagramas y
documentación relativa a los desarrollos de software (programas informáticos).

El término “lenguaje” ha generado bastante confusión respecto a lo que es UML. En

realidad el término lenguaje quizás no es el más apropiado, ya que no es un lenguaje
propiamente dicho, sino una serie de normas y estándares gráficos respecto a cómo
se deben representar los esquemas relativos al software. Mucha gente piensa por
confusión que UML es un lenguaje de programación y esta idea es errónea: UML
no es un lenguaje de programación. Como decimos, UML son una serie de normas
y estándares que dicen cómo se debe representar algo.

UML es una herramienta propia de personas que tienen conocimientos

relativamente avanzados de programación y es frecuentemente usada por analistas
funcionales (aquellos que definen qué debe hacer un programa sin entrar a escribir
el código) y analistas-programadores (aquellos que dado un problema, lo estudian
y escriben el código informático para resolverlo en un lenguaje como Java, C#,
Python o cualquier otro). Por tanto si estás dando tus primeros pasos en
programación, te recomendaríamos que te olvides de UML hasta que tengas unos
conocimientos mínimos como uso de condicionales, bucles, y conocimiento de la

11
programación orientada a objetos. Esto es solo una recomendación, en realidad
prácticamente cualquier persona puede usar UML, incluso podría usarse para
realizar esquemas o documentación de procesos que no tengan que ver con la
informática.

Hemos dicho que UML es un estándar. Vamos a aclarar primero qué es un estándar.
Supongamos que vamos a definir un estándar llamado “LMAPR” o lenguaje de
modelado de aprenderaprogramar.com. Ahora definimos dentro de nuestro
estándar estas normas:

Un animal debe representarse con su nombre escrito enteramente en minúsculas

enmarcado dentro de un rectángulo doble. Encima del nombre debe etiquetarse el
tipo de animal así: <<Tipo de Animal>>. Por ejemplo, <<Gato>>.
Si un animal envía un mensaje a otro animal deben conectarse los dos animales
con una línea punteada terminada en flecha encima de la cual debe figurar el texto
msg(“Contenido del mensaje”).

Ahora supongamos que tenemos dos gatos, uno de los cuales le dice al otro “Caza
un ratón y tráemelo aquí por favor”. Veamos formas de representar esto:

Esta es una forma de representación. Sin embargo, no se adapta al estándar

que hemos definido por varios motivos: no indica <<Gato>> encima de los nombres

12
de los animales, no escribe los nombres en minúsculas, no representa los animales
con un rectngulo, etc.

Veamos la representación que sí se adaptaría al estándar definido:

Con este ejemplo sencillo hemos tratado de hacer explícito qué es y para qué sirve
UML: un conjunto de normas que nos dicen cómo hay que representar esquemas
de software. En el caso del software orientado a objetos, en vez de gatos tendremos
clases u objetos instanciados, y dispondremos de numerosos tipos de esquemas y
diagramas para representar distintas cosas. Un esquema que cumple las normas
UML podría tener este aspecto:

UML usa elementos y los asocia de diferentes formas para formar diagramas que
representan aspectos estáticos o estructurales de un sistema, y diagramas de
comportamiento, que captan los aspectos dinámicos de un sistema.

DIAGRAMAS UML

ESTRUCTURALES

DIAGRAMA DE CLASES
El diagrama UML más comúnmente usado, y la base principal de toda solución
orientada a objetos. Las clases dentro de un sistema, atributos y operaciones, y la
relación entre cada clase. Las clases se agrupan para crear diagramas de clases al
crear diagramas de sistemas grandes.

13
 Ventajas Desventajas
Genera un código automáticamente. Los diagramas de clases especifican
Propone soluciones a algunos errores. qué clases hay y cómo están
Representa las relaciones entre las relacionadas, pero no cómo interactúan
clases de sistema. para alcanzar comportamientos
Se diseña los componentes de los particulares.
sistemas. El método tiende hacer muy lento.
Se protegen los datos. La instalación es muy costosa
Se posibilita una reducción de
acoplamiento.
Mas fácil la comunicación entre los
programadores, descubrimiento de
fallas del sistema en el diseño Mejor
diseño del sistema ofrece más
documentación.

DIAGRAMA DE COMPONENTES
Muestra la relación estructural de los elementos del sistema de software, muy
frecuentemente empleados al trabajar con sistemas complejos con componentes
múltiples. Los componentes se comunican por medio de interfaces.

DIAGRAMA DE ESTRUCTURA COMPUESTA

Los diagramas de estructura compuesta se usan para mostrar la estructura interna
de una clase.

14
DIAGRAMA DE IMPLEMENTACIÓN
Ilustra el hardware del sistema y su software. Útil cuando se implementa una
solución de software en múltiples máquinas con configuraciones únicas.

DIAGRAMA DE OBJETOS
Muestra la relación entre objetos por medio de ejemplos del mundo real e ilustra
cómo se verá un sistema en un momento dado. Dado que los datos están
disponibles dentro de los objetos, estos pueden usarse para clarificar relaciones
entre objetos.

DIAGRAMA DE PAQUETES
Hay dos tipos especiales de dependencias que se definen entre paquetes: la
importación de paquetes y la fusión de paquetes. Los paquet
es pueden representar los diferentes niveles de un sistema para revelar la
arquitectura. Se pueden marcar las dependencias de paquetes para mostrar el
mecanismo de comunicación entre niveles.

DE COMPORTAMIENTO

DIAGRAMAS DE ACTIVIDADES
Flujos de trabajo de negocios u operativos representados gráficamente para mostrar
la actividad de alguna parte o componente del sistema. Los diagramas de
actividades se usan como una alternativa a los diagramas de máquina de estados.
DIAGRAMA DE COMUNICACIÓN
Similar a los diagramas de secuencia, pero el enfoque está en los mensajes que se
pasan entre objetos. La misma información se puede representar usando un
diagrama de secuencia y objetos diferentes.

15
DIAGRAMA DE PANORAMA DE INTERACCIONES
Hay siete tipos de diagramas de interacciones. Este diagrama muestra la secuencia
en la cual actúan.
DIAGRAMA DE SECUENCIA
Muestra cómo los objetos interactúan entre sí y el orden de la ocurrencia.
Representan interacciones para un escenario concreto.

DIAGRAMA DE MÁQUINA DE ESTADOS

Similar a los diagramas de actividades, describen el comportamiento de objetos que
se comportan de diversas formas en su estado actual.

DIAGRAMA DE TEMPORIZACIÓN
Al igual que en los diagramas de secuencia, se representa el comportamiento de
los objetos en un período de tiempo dado. Si hay un solo objeto, el diagrama es
simple. Si hay más de un objeto, las interacciones de los objetos se muestran
durante ese período de tiempo particular.

DIAGRAMA DE CASO DE USO

Representa una funcionalidad particular de un sistema. Se crea para ilustrar cómo
se relacionan las funcionalidades con sus controladores (actores) internos/externos.

ELEMENTOS DEL DIAGRAMA DE CLASES

CLASE
Las clases se representan por rectángulos que muestran el nombre de la
clase y opcionalmente el nombre de las operaciones y atributos. Los
compartimientos se usan para dividir el nombre de la clase, atributos y operaciones.

16
Adicionalmente las restricciones, valores iniciales y parámetros se pueden asignar
a clases.

En el siguiente diagrama la clase contiene el nombre de la clase en el

compartimiento más alto, el compartimiento siguiente detalla los atributos, con el
atributo del “centro” mostrando los valores iniciales. El último compartimiento
muestra las operaciones, las operaciones setWidth, setLength y setPosition
mostrando sus parámetros.

La notación que precede el nombre del atributo u operación indica la

visibilidad del elemento, si se usa el símbolo + el atributo y la operación tienen un
nivel público de visibilidad, si se usa un símbolo – el atributo u operación es privado.
Además, el símbolo # permite definir una operación o atributo como protegido y el
símbolo ~ indica la visibilidad del paquete.

ATRIBUTOS Y MÉTODOS
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:
public (+,): Indica que el atributo será visible tanto dentro como fuera de la clase, es
decir, es accsesible desde todos lados.
private (-,): Indica que el atributo sólo será accesible desde dentro de la Clase (sólo
sus métodos lo pueden accesar).
protected (#,): Indica que el atributo no será accesible desde fuera de la clase, pero
si podrá ser accesado por métodos de la clase además de las subclases que se
deriven (ver Herencia).
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:

17
public (+,): Indica que el método será visible tanto dentro como fuera de la Clase,
es decir, es accsesible desde todos lados.
private (-,): Indica que el método sólo será accesible desde dentro de la clase (sólo
otros métodos de la clase lo pueden accesar).
protected (#,): Indica que el método no será accesible desde fuera de la clase, pero
si podrá ser accesado por métodos de la clase además de métodos de las subclases
que se deriven (ver herencia).

RELACIONES ENTRE CLASES

Ahora ya definido el concepto de Clase, es necesario explicar como se
pueden interrelacionar 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,
se anotan en cada extremo de la relación y éstas pueden ser: – uno o muchos: 1..*
(1..n) – 0 o muchos: 0..* (0..n) – número fijo: m (m denota el número).

HERENCIA
Indica que una subclase hereda los métodos y atributos especificados por
una superclase, de esta forma la subclase además de poseer sus propios métodos
y atributos, poseerá las características y atributos visibles de la superclase (public y
protected), En este ejemplo, el objeto "Auto" heredaría todos los atributos
(velocidad, números de pasajeros, combustible) y los métodos (arrancar(), frenar(),
cambiarDirección()) de la clase principal ("Vehículo"), además de los atributos
específicos (tipo de modelo, número de puertas, fabricante del auto) y métodos de
su propia clase (Radio(), limpiaparabrisas(), aireacondicionado/calefacción()). La

18
herencia se muestra en un diagrama de clases por medio de una línea continua con
una flecha cerrada y vacía.

AGREGACIÓN
Para modelar objetos complejos, no es suficiente con los tipos de datos
básicos que proveen los lenguajes:

Enteros, reales y secuencias de caracteres. Cuando se requiere componer

objetos que son instancias de clases definidas por el desarrollador de la aplicación,
tenemos dos posibilidades:

Por Valor: 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. Este tipo
de relación es comúnmente llamada Composición (el Objeto base se construye a
partir del objeto incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida

del objeto incluido es independiente del que lo incluye. Este tipo de relación es
comúnmente llamada Agregación (el objeto base utiliza al incluido para su
funcionamiento).

ASOCIACIÓN
La relación entre clases conocida como Asociación, permite asociar objetos
que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el
tiempo de vida de un objeto no depende del otro. Asociación bidireccional: La
relación predeterminada entre dos clases. Ambas clases están conscientes una de
la otra y de la relación que tienen entre sí. Esta asociación se representa mediante
una línea recta entre dos clases.

19
 ASOCIACIÓN BIDIRECCIONAL En Diagrama De Clase En el ejemplo
anterior, la clase Auto y la clase Viaje están interrelacionadas. En un extremo de la
línea, el Auto recibe la asociación de "autoAsignado" con el valor de multiplicidad
de 0..1, de modo que cuando la instancia de Viaje existe, puede tener una instancia
de Auto asociada a ella o no tener instancias de Autos asociadas a ella. En este
caso, una clase CasaRodante separada con un valor de multiplicidad de 0..* es
necesaria para demostrar que un Viaje puede tener múltiples instancias de Autos
asociadas a ella. Dado que una instancia de Auto podría tener múltiples
asociaciones "iniciarViaje", en otras palabras, un auto podría realizar múltiples
viajes, el valor de multiplicidad se establece en 0..*

ASOCIACIÓN UNIDIRECCIONAL: Una relación un poco menos común entre

dos clases. Una clase está consciente de la otra e interactúa con ella. La asociación
unidireccional se dibuja con una línea de conexión recta que señala una punta de
flecha abierta desde la clase "knowing" a la clase "known".

DEPENDENCIA O INSTANCIACIÓN
Representa un tipo de relación muy particular, en la que una clase es
instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por
una flecha punteada. El uso más particular de este tipo de relación es para denotar
la dependencia que tiene una clase de otra, como por ejemplo una aplicación
Gráfica que instancia una ventana (la creación del Objeto Ventana esta
condicionado a la instanciación proveniente desde el objeto Aplicación)

20
 CONCLUSION

Hay mucho todavía que conocer de la POO ya que sólo hemos hecho
referencia a las cosas más básicas. También existen mecanismos como la herencia
y el polimorfismo que son unas de las posibilidades más potentes de la POO.

La herencia sirve para crear objetos que incorporen propiedades y métodos

de otros objetos. Así podremos construir unos objetos a partir de otros sin tener que
reescribirlo todo. Puedes encontrar en DesarrolloWeb.com un artículo completo
dedicado a la Herencia.

El polimorfismo sirve para que no tengamos que preocuparnos sobre lo que

estamos trabajando, y abstraernos para definir un código que sea compatible con
objetos de varios tipos. Puedes acceder a otro artículo para saber más sobre
Polimorfismo.

21