2017

Unidad II.- Introducción a la POO

Programación I
Escuela de Ingeniería de sistemas Informáticos
01/01/2017
Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

INTRODUCCIÓN A LA PROGRAMACIÓN ORIENTADA A OBJETOS

Objetivo de la Unidad: Conocer los conceptos básicos de la Programación Orientada a

Objetos, estudiar sus técnicas y aplicarlas en la solución de problemas informáticos.

Contenido de la Unidad:
1. Programación Orientada a Objetos.
2. PE frente a POO.
3. Terminología Básica.
4. Técnicas de la POO.
5. El Lenguaje Unificado de Modelado (UML)
6. Diseño dirigido por responsabilidades.
7. Diagrama de clases
8. Diagrama de caso de uso

Introducción.

Los conceptos de la Programación Orientada a Objetos (POO) tienen origen en Simula 67,
un lenguaje diseñado para hacer simulaciones con naves aéreas. La idea surgió al agrupar
los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de
objetos de definir sus propios datos y comportamientos. Fueron refinados más tarde en
Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versión fue escrita sobre
BASIC) pero diseñado para ser un sistema completamente dinámico en el cual los objetos
se podrían crear y modificar en tiempo de ejecución en lugar de tener un sistema basado
en programas estáticos.

La Programación Orientada a Objetos se fue convirtiendo en el estilo de programación

dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++,
una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al
auge de las Interfaces Gráficas de Usuario (GUI), para las cuales la programación orientada
a objetos está bien adaptada.

Unidad II. Introducción a la POO Página 1 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

1.- Programación Orientada a Objetos

La Programación Orientada a Objetos es un enfoque conceptual específico para diseñar

programas. Es una forma de programar diferente concentrándose sobre todo en lo que se
requiere obtener y no en cómo obtenerlo.

Esta técnica, se basa en la representación del problema en modelos de objetos físicos o

simulados; aunque la idea es abstracta y parece muy complicada, cuando se aplica a
objetos físicos en términos de sus clases, componentes, propiedades y comportamientos,
se vuelve más clara.

La idea fundamental de la orientación a objetos y de los lenguajes que implementan este

paradigma de programación es combinar (encapsular) en una sola unidad tanto los datos
como las funciones que operan (manipulan) sobre los datos. Esta característica permite
representar los objetos del mundo real, mucho más eficientemente que con funciones y
datos de forma separada o independiente (como lo hace la Programación Estructurada,
PE).

La POO (Programación Orientada a Objetos), es un paradigma que utiliza objetos como

elementos fundamentales en la construcción de una solución. Un objeto es una
abstracción de algún hecho o ente del mundo real que tiene atributos que representan
sus características y propiedades; y métodos que representan su comportamiento. Todas
las propiedades y métodos comunes entre objetos se encapsulan o se agrupan en clases.

Las propiedades más importantes (técnicas) de la POO son:

 Abstracción.
 Encapsulamiento y Ocultación de datos.
 Polimorfismo.
 Herencia.
 Reusabilidad o Reutilización de Código

2.- Programación Estructurada Frente a Programación Orientada a Objetos

La POO difiere de la Programación Estructurada Tradicional, en la forma en son manejados

los datos y los procedimientos, en PE (datos y procedimientos) están separados y sin

Unidad II. Introducción a la POO Página 2 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

ninguna relación entre ellos; ya que lo único que se busca es el procesamiento de unos
datos de entrada para obtener otros de salida.

La Programación Estructurada anima al programador a pensar sobre todo en términos de

procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos
procedimientos manejan. Con esta técnica de programación, se diseñan módulos (o
funciones), que procesan datos.

Los programadores que emplean POO, en cambio, primero definen objetos para luego
enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

Para realizar una comparación, se listarán las ventajas y desventajas de estas dos formas
de programación:

Paradigma Ventajas Desventajas

Fomenta la reutilización del Curva de aprendizaje
código. mayor.
Permite crear sistemas más Depuración de código más
complejos compleja.
Agiliza el desarrollo de
POO software
Es soportado por los
lenguajes modernos de
programación
Es el estándar más utilizado
para programar
Son más fáciles de entender Cuando crece el código se
dificulta el manejo del
código fuente
La estructura de los La reutilización de código
programas es clara no se explota tanto como
en la POO
PE El mantenimiento es fácil No es apto para programas
complejos.
Los bloques de código son
casi auto explicativos
Programas más sencillos y
rápidos de confeccionar
Es más fácil realizar pruebas
y depuración de los bloques

La Programación Estructurada es la primera técnica formal de programación (nació a

Unidad II. Introducción a la POO Página 3 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

inicios de los años 60’s), sigue estando en vigencia y es muy utilizada para iniciar el
aprendizaje de la programación.

La Programación Orientada a Objetos es una mejora de la Programación Estructurada; sin

embargo, la mayor diferencia que existe entre ambas es la forma en que se organizan los
programas.

La Programación Estructurada es ideal para realizar programas sencillos y para iniciar la

programación. La Programación Orientada a Objetos es recomendada para resolver
problemas más complejos y requiere un mayor nivel de abstracción del problema.

3.- Terminología Básica

A continuación se definen algunos elementos básicos de la Programación Orientada a

Objetos con el objetivo de familiarizarse con esta forma de programación:

Objeto: es el centro de la Programación Orientada a Objetos. Un objeto es algo que se

visualiza, se utiliza y que juega un papel o un rol. En POO el objeto representa alguna
entidad de la vida real.

A través del estudio de ellos se adquiere el conocimiento necesario para (mediante la

abstracción y la generalización) agruparlos según sus características en conjuntos.
Un objeto es cualquier elemento del medio ambiente real del problema que se va a
resolver; posee características fundamentales:

 Identidad: En programación la identidad de los objetos sirve para verificar

mediante sus características si dos objetos son iguales o no.
 Comportamiento: El comportamiento de un objeto está directamente relacionado
con su funcionalidad y determina las operaciones que este puede realizar o a las
que puede responder ante mensajes enviados por otros objetos.
 Estado: El estado de un objeto se refiere al conjunto de los valores de sus atributos
en un instante de tiempo dado. El comportamiento de un objeto puede modificar
el estado de éste. Cuando una operación de un objeto modifica su estado se dice
que esta tiene "efecto colateral".

Atributos: son las características individuales que diferencian un objeto de otro y

determinan su apariencia, estado u otras cualidades; pueden ser también las propiedades

Unidad II. Introducción a la POO Página 4 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

del objeto. Estos datos o variables son los que con sus valores en un momento dado,
indican el estado de un objeto.

Por ejemplo, para un objeto automóvil, algunos de sus atributos son: propietario, marca,
año de matrícula, potencia etc.

Para un objeto estudiante, algunos de sus atributos podrían ser: carnet, nombre,
carrera, asignaturas aprobadas, etc.

La identidad y estado de los objetos, tienen que ver con los atributos, y estos pueden ser
modificados por el comportamiento de los objetos.

Clase: es la representación de un conjunto de objetos del mismo tipo, es decir que los
distinguen los mismos atributos y las mismas funciones (o comportamiento).
Es la definición (o implantación) de un tipo abstracto de datos; es decir que una clase
describe no sólo los atributos de los objetos que la forman, sino que también incluye sus
procesos (funciones o comportamiento).

Según Luis Joyanes Aguilar, “una clase es una caracterización abstracta de un conjunto de
objetos”.

Métodos: son las operaciones (acciones o funciones) definidas para los objetos, y
permiten crearlos, cambiar su estado o consultar el valor de los atributos. Cuando se llama
a una operación de un objeto se interpreta como el envío de mensaje a dicho objeto. En
otras palabras, un método es una subrutina asociada a una clase.

Algunos de los diferentes tipos de método que existen son los siguientes:

 Método Get (para ver o consultar valores de atributos).

 Método Set (para asignar valores de atributos).
 Métodos de actualización (para cambiar valores por medio de cálculos).

Relaciones entre Clases: los objetos del medio ambiente no permanecen aislados y
separados unos de los otros, todo lo contrario se comunican entre sí para poder apoyarse
y ayudarse entre sí. De la misma forma las clases que forman parte del ambiente de un
problema se relacionan entre sí y con ello se permite que los objetos colaboren entre sí e
intercambien información.

Las relaciones entre clases pueden ser las siguientes:

Asociación: Es la relación más importante y común entre clases. Refleja una relación
entre dos clases independientes que se mantiene durante la vida de los objetos de
dichas clases o al menos durante un tiempo prolongado.

Unidad II. Introducción a la POO Página 5 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

Agregación: Es un tipo especial de asociación en el que la clase de donde parte la

relación representa el “todo” y las clases relacionadas a ésta “las partes”. Es decir que
las partes pueden seguir funcionando aún sin el todo.

Composición: Este tipo de relación entre clases indica dependencia entre ellas, indica
que una clase es parte esencial de otra; es una relación mucho más fuerte que la
agregación ya que de eliminarse una clase, deja de existir la otra. Dicho de otra forma, si
la clase origen “el todo” se elimina o destruye, las otras clases (o “las partes”) también se
destruyen.

Dependencia: Esta relación indica la necesidad de una clase hacia otra, es decir que la
implantación de una clase depende de otra; los métodos u operaciones de una clase
requieren de los atributos de los objetos de la otra clase.

Herencia: Indica que una subclase hereda los métodos y atributos especificados por una
Superclase, por ende la subclase además de poseer sus propios métodos y atributos,
poseerá las características y atributos visibles de la superclase.

4.- Técnicas de la POO

4.1 Abstracción

Una forma de reducir la complejidad de un problema o situación es la abstracción. Las

características y procesos de cualquier sistema se resumen en los aspectos más esenciales
y relevantes. En computación, la abstracción es el proceso crucial de representar la
información en términos de su interfaz con el usuario.

Un ejemplo de abstracción expresada de diferentes formas según la aplicación a

desarrollar, puede ser un auto.

 Un auto es la composición de diferentes partes (motor, ruedas, puertas, asientos

etc.)
 Un auto es un término común que define a tipos diferentes de automóviles, es
decir es una categoría que puede servir para agrupar, por ejemplo las diferentes
marcas (BMW, Seat, Toyota entre otras) o por su categoría (deportivos, clásicos,
pick-up, etc).

Si los miembros de autos o las diferencias entre autos individuales no son relevantes,
entonces se utilizan expresiones y operaciones tales como: se fabrican autos, se usan
autos para trasladarse de un lado a otro, se descompone el auto en sus partes, etc.

Unidad II. Introducción a la POO Página 6 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

4.2 Encapsulamiento y Ocultación de Datos

La encapsulación es la reunión en una cierta estructura, de todos los elementos que a un

cierto nivel de abstracción se pueden considerar pertenecientes a una misma entidad y
también es el proceso de agrupamiento de datos y operaciones relacionadas bajo una
misma unidad de programación, lo que permite aumentar la cohesión de los componentes
del sistema.

Todos estos objetos que presentan características y comportamientos similares, se

agrupan en clases las cuales son utilizadas para encapsular los datos.

4.3 Polimorfismo

Es la capacidad del código de un programa para ser utilizado con diferentes tipos de datos
u objetos. También se puede aplicar a la propiedad que poseen algunas operaciones de
tener un comportamiento diferente, dependiendo del objeto (o tipo de dato) sobre el que
se aplican. Así, en un lenguaje de programación el operador “+” representa la suma de dos
números ( x + y ) de diferentes tipos: enteros, flotantes. Pero también, el mismo operador
puede definir la operación de sumar dos cadenas: concatenación. De modo similar,
suponiendo un número de figuras geométricas que responden todas al mensaje
CalcularArea; cada objeto reacciona a este mensaje haciendo el cálculo correspondiente
de la superficie, el cual difiere de una figura a otra.

Ilustración 1

Unidad II. Introducción a la POO Página 7 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

4.4 Herencia

Proporciona la facilidad de heredarle características de una superclase a una subclase y es

comúnmente utilizada en la POO. La idea principal es crear una clase que encapsule todos
los elementos o características generales que pueda y a partir de ésta, heredarle parcial o
totalmente las características a objetos de una subclase.

4.5 Reusabilidad o Reutilización de Código.

Se refiere al comportamiento y a las técnicas que garantizan que una parte o la totalidad
de un programa informático existente se puedan emplear en la construcción de otro
programa. De esta forma se aprovecha el trabajo anterior, se economiza tiempo, y se
reduce la redundancia.

La manera más fácil de reutilizar código es copiarlo total o parcialmente desde el

programa antiguo al programa en desarrollo. Pero es trabajoso mantener múltiples copias
del mismo código, por lo que en general se elimina la redundancia dejando el código
reusable en un único lugar, y llamándolo desde los diferentes programas. Este proceso se
conoce como abstracción. La abstracción puede verse claramente en las bibliotecas de
software, en las que se agrupan varias operaciones comunes a cierto dominio para
facilitar el desarrollo de programas nuevos. Hay bibliotecas para convertir información
entre diferentes formatos conocidos, acceder a dispositivos de almacenamiento externos,
proporcionar una interfaz con otros programas, manipular información de manera
conocida (como números, fechas, o cadenas de texto).

Para que el código existente se pueda reutilizar, debe definir alguna forma de
comunicación o interfaz. Esto se puede dar por llamadas a una subrutina, a un objeto, o a
una clase.

5.- Lenguaje de Modelado UML

El lenguaje utilizado para el modelado de los sistemas utilizando la Programación
Orientada a Objetos es el UML. A continuación se encuentran los conceptos básicos del
UML.

En la primera mitad de la década de los 90’s, los lenguajes de modelado que imperaban
eran OMT-2 (Object Modeling Technique), creado por James Rumbaugh, OOSE (Object
Oriented Software Engineering), creado por Ivan Jacobson y Booch93, creado por Grady
Booch.

Grady Booch llamó a James Rumbaugh y formaron equipo en una nueva empresa llamada
Rational Corporation (cuyo propietario era Grady) con el objetivo de fusionar sus dos

Unidad II. Introducción a la POO Página 8 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

métodos. En octubre de 1994, Grady y James comenzaron a trabajar en la unificación de

ambos métodos produciendo una versión en borrador llamada 0.8 y nombre “Unified
Method”. A partir de 1995 Jacobson se une. El primer fruto de su trabajo colectivo se
lanzó en enero de 1997 y fue presentado como versión 1.0 de UML. La gran ventaja de
UML es que fue recogiendo aportaciones de los grandes gurús de los objetos: David
Hasel con sus diagramas de estado; partes de la notación de Fusion, el criterio de
responsabilidad-colaboración y los diagramas de Rebeca Wirfs-Brock, y el trabajo de
patrones y documentación de Gamma-Helm-Johnson-Ulissides.

En 1997 OMG aceptó UML como estándar (versión 1.1) y nació el primer lenguaje de
modelado visual orientado a objetos como estándar abierto de la industria. En 1998, OMG
lanzó dos revisiones más, 1.2 y 1.3. En el año 2000 se presentó UML 1.4 con la importante
aportación de la semántica de acción, que describe el comportamiento de un conjunto de
acciones permitidas que se pueden implementar mediante lenguajes de acción. La versión
1.5 siguió a las ya citadas.

En 2004 finalizó la versión 2.0 con su especificación completa. UML 2 es ya un lenguaje de

modelado muy maduro. UML 2 ha incorporado numerosas mejoras a UML 1.x. Los
cambios más importantes se han realizado en el metamodelo (generador de modelos),
conservando los principios fundamentales y evolutivos de las últimas versiones. Los
diseñadores de UML 2.0 han tenido mucho cuidado en asegurar que fuera totalmente
compatible con las versiones anteriores para que los usuarios de éstas no tuvieran
problemas de adaptación. La versión UML 2.0 ha evolucionado para superar los nuevos
retos a los cuales se enfrentan el software y los nuevos desarrolladores de
modelos.

UML significa Lenguaje Unificado de Modelado (Unified Model Language) y es el lenguaje

estándar para el desarrollo de sistemas y de software utilizando POO. El lenguaje UML
tiene una gran aplicación en la representación y modelado de la información que se utiliza
en las fases de análisis y diseño del ciclo de vida de los sistemas.

Un modelo es una abstracción de cosas reales, es decir es una simplificación del sistema
real; en pocas palabras es la representación gráfica de una situación real, mediante una
simbología que esquematiza clases, objetos, relaciones, etc. Entonces, si un modelo es la
representación gráfica de una situación real; por lo tanto, modelado implica realizar un
esquema (gráfico o dibujo).

Con un lenguaje formal de modelado, el lenguaje es abstracto aunque tan preciso como
un lenguaje de programación. Esta precisión permite que un lenguaje sea legible y que
pueda ser interpretado, ejecutado y transformado entre sistemas.

Unidad II. Introducción a la POO Página 9 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

La siguiente figura presenta una forma de clasificación de los diferentes diagramas UML:

Ilustración 2

Los diagramas estructurados se utilizan para capturar la organización física de las cosas del
sistema. Por ejemplo, cómo se relacionan unos objetos con otros. Mientras que, los
diagramas de comportamiento se centran en el comportamiento de los elementos de un
sistema.

El Modelo Conceptual se ha diseñado para proporcionar un marco de referencia,

estructurado y claramente definido para relacionar los datos con las necesidades de los
usuarios.

La metodología utilizada en la construcción de este Modelo tiene como primer paso, la

identificación de los principales objetos que son de interés para los usuarios de la
información en un dominio particular. Cada uno de estos objetos clave, o entidades, sirve,
por tanto, como foco de un grupo de datos. Un modelo desarrollado usando estas
técnicas también representa la relación entre diferentes tipos de entidad.

Una vez que se ha establecido la estructura de alto nivel para el modelo mediante la
identificación de las entidades y las relaciones entre , el siguiente paso es identificar las

Unidad II. Introducción a la POO Página 10 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

principales características o atributos de cada entidad. A un nivel más concreto, el modelo

también puede describir la relación que pueda existir entre instancias.

En el diseño de cualquier modelo conceptual, dilucidar si algo es un atributo o una entidad

independiente es una decisión clave. El resultado de esta decisión depende del futuro uso
del atributo o entidad. Generalmente, las personas y los entes corporativos son entidades
independientes que podrían relacionarse con las otras entidades establecidas en el citado
modelo.

Convenciones Utilizadas en los Diagramas

a) Un rectángulo de línea continua representa una entidad (es decir, un objeto de

interés para los usuarios).
b) Un rectángulo de línea punteada alrededor de un grupo de dos o más entidades
indica que una relación representada por una flecha contigua a la línea de puntos
puede aplicarse a todas y cada una de las entidades representadas en el
rectángulo.
c) Una flecha de una punta sobre una línea representa una relación en la que cada
instancia de la entidad del otro extremo de la línea puede estar asociada con una
sola instancia de la entidad a la que apunta la flecha.

El objetivo de la Primera Etapa del Análisis de Sistemas Orientado a Objetos es desarrollar

un Modelo Conceptual o Cualitativo, del sistema de interés. Una vez que se hayan
definido claramente los objetivos del proyecto, se usan como base para abstraer del
sistema real aquellos componentes que son relevantes para abordar las preguntas
generadas.

A medida que se van seleccionando ciertos componentes y excluyendo otros, se van

definiendo los límites del sistema de interés. Luego, se clasifican los componentes del
modelo de acuerdo con el rol específico que tienen en la descripción de la estructura del
sistema y se identifican las relaciones entre los componentes que generan la dinámica del
sistema.

Posteriormente, se representa formalmente el modelo conceptual resultante usando un

diagrama de cajas y flechas. Las cajas representan los puntos de acumulación de material
y las flechas representan las rutas a través de las cuales el material fluye en el sistema.

Finalmente, se describen los patrones esperados del comportamiento del modelo por
medio de gráficos que representan los cambios a lo largo del tiempo en los valores de las
variables del sistema que se consideran más importantes.

Unidad II. Introducción a la POO Página 11 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

En muchos aspectos el desarrollo del modelo conceptual es la etapa del análisis de

sistemas que presenta el mayor desafío intelectual. La mejor base para tomar decisiones
(las que a menudo son subjetivas) acerca de cuáles componentes se deben incluir en el
modelo está dada por el conocimiento acerca del sistema real.

Existen dos estrategias generales para identificar los componentes del modelo: una de
ellas consiste en incluir pocos componentes y posteriormente añadir aquellos
componentes críticos que inicialmente fueron omitidos; la otra consiste en incluir todos
los componentes que podrían ser de importancia en la etapa inicial, para luego descartar
aquellos que parecen superfluos.

Teóricamente el resultado final de las dos estrategias debería ser un modelo conceptual
con el grado mínimo de complejidad que permita abordar el problema. En la práctica es
mejor comenzar con un modelo que sea lo más simple posible.

Etapas del Desarrollo del Modelo Conceptual

a) Definir los Objetivos del Modelo.

b) Definir los Límites del Sistema de Interés.
c) Clasificar los Componentes del Sistema de Interés.
d) Identificar las Relaciones entre los Componentes del Sistema.
e) Representación Formal del Modelo Conceptual.
f) Describir los Patrones Esperados del Comportamiento del Modelo.

Un Diagrama de Clases es una representación gráfica de las clases de un sistema. Sirve

para modelar el sistema en términos de sus clases, atributos y las relaciones entre estos
elementos. En el diagrama se representan los requerimientos y la arquitectura general del
sistema en estudio. Se utiliza para capturar las relaciones estáticas del software. Este tipo
de diagramas proporcionan un medio de capturar la estructura física de un sistema.

Este diagrama se utiliza en la etapa de análisis del problema y diseño de la solución. Los
símbolos más utilizados en este diagrama son:

RECTANGULO: representa una clase, dividido en tres partes, una para el nombre de la
clase, otra para los atributos y la última para los métodos o funciones.

Unidad II. Introducción a la POO Página 12 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

Ilustración 3

FLECHAS: indican la relación que existe entre dos clases. Las flechas pueden ser continuas
o punteadas, pueden tener punta o no y puede ser sustituída por rombos, según sea la
relación que indique, como se verá más adelante:

Ilustración 4

Multiplicidad o Cardinalidad en las Relaciones de Clases: indica el grado y nivel de

dependencia, se anotan en cada extremo de la relación y éstas pueden ser:

 uno a muchos: 1..* (1..n)

 0 a muchos: 0..* (0..n)
 número fijo: m (m denota el número).

Reglas para Nombrar Clases, Atributos y Métodos.

Para poder distinguir una clase de otra, siempre es importante y necesario identificarlos
con un nombre que las diferencie entre sí, para los atributos y métodos debe hacerse
también esta distinción. Existen las siguientes reglas básicas o convenciones que guardar
para nombrarlos:

1) Se usan letras preferiblemente, no se deben utilizar símbolos.

Unidad II. Introducción a la POO Página 13 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

2) La primera siempre va en mayúsculas, las demás en minúsculas.

3) Si se utilizan dos o más palabras, se escriben unidas, sin espacio y las iniciales con
mayúsculas (EstiloCamel).
4) Los nombres siempre van en singular.
5) Los nombres de atributos y métodos, se escriben con letras minúsculas.

Para poder ejemplificar un diagrama de clases, que incluye las clases y sus relaciones, se
va a ampliar un poco más sobre las relaciones de asociación y agregación, que son las que
se utilizan con frecuencia:

Asociación
Esta relación se establece cuando dos clases tienen una dependencia de utilización, es
decir que una clase utiliza atributos y/o métodos de otra clase para funcionar, ambas
clases tienen la misma jerarquía, es decir que ninguna es parte de la otra. La relación entre
clases conocida como Asociación, permite asociar objetos que colaboran entre sí.
Ejemplo:
Notar que las dos clases están unidas
por una línea y no por una flecha,
porque: Cuando las flechas van de
izquierda a derecha y de arriba hacia
abajo, se puede omitir la punta
Ilustración 5 de la flecha.
Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una Orden de
Compra sólo puede tener asociado a un cliente.

Agregación
Con este tipo de relación se indica que un objeto forma parte de otro objeto; por ejemplo
si se tiene el objeto: computadora, esta tiene un monitor, que es otro objeto; el monitor
forma parte de la computadora; por lo tanto tienen una relación de agregación. Esta
relación también es conocida como “forma parte de …” Ejemplo:
Aquí las flechas tienen punta ya que están
inclinadas.

El rombo vacío indica una relación de

agregación (siendo la clase Almacén
“el todo” y la clase cliente representa “la
parte”).

El rombo relleno indica una relación de

Ilustración 6
composición, otro tipo de relación.
Unidad II. Introducción a la POO Página 14 de 19
Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las
referencias, es decir el objeto que está formado por los otros: el todo y las partes).
Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta
asociados, en cambio no son afectados los objetos Cliente asociados.

Pasos para Crear el Diagrama de Clases (Sin Métodos)

1) Listar clases candidatas.

2) Representar las clases en un diagrama de clases.
3) Agregar asociaciones.
4) Agregar atributos necesarios.

Ejemplo de Creación de un Diagrama de Clases:

Enunciado: En un juego de dados, un jugador toma dos dados y los lanza. Luego, se suman
los valores de las caras superiores de los dados. Si el valor es 7 gana el juego, de lo
contrario pierde.

Listar clases:

 Juego de Dados
 Jugador
 Dado Atributo de cada Dado: Valor de la cara Resultado es la suma de las caras

2. Representar Clases en un Diagrama de Clases

Ilustración 7

3. Agregar asociaciones:

 Jugador lanza Dados

 Jugador juega Juego de Dados

Unidad II. Introducción a la POO Página 15 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

 Dados son parte del Juego de Dados

 Jugador utiliza Dado.

Ilustración 8

4. Agregar atributos:

 Jugador: nombre del jugador

 Dado: valor de la cara

De esta manera el Diagrama de clases, únicamente con atributos y relaciones, queda así:

Ilustración 9

Los conceptos básicos del paradigma OO son clase y objeto. En el modelo OO se combina
la estructura y el comportamiento de los datos en una única entidad, los objetos. Los
objetos son simplemente entidades que tienen sentido en el contexto de una aplicación
(dominio del problema).

Unidad II. Introducción a la POO Página 16 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

Todos los objetos son ejemplares o instancias de alguna clase, los términos instancia y
objeto son intercambiables. Los objetos de una misma clase tienen las mismas
responsabilidades. Los objetos con las mismas responsabilidades pueden ser agrupados en
una clase. Las clases son abstracciones que generalizan dominios de objetos.

Un proceso básico que enfrentamos en la resolución de problemas es la abstracción, o sea

la eliminación de los detalles irrelevantes, centrándonos únicamente en los aspectos
esenciales del problema (dominio del problema).

La POO se basa en el modelo OO. Los objetos del mundo real son representados como
objetos en el diseño y en la programación. En el modelo OO, toda entidad del dominio del
problema se expresa a través del concepto de objeto y éstos se generalizan a través del
concepto de clase. Entendemos por dominio del problema, al problema que se intenta
resolver en término de complejidades específicas, terminologías, retos, etc.

Ejemplo: Determinar los objetos presentes en un juego de ajedrez.

Comúnmente, como respuesta a este ejemplo se enuncia el peón, el caballo, la torre, etc.,
pero sin dudas estos son conceptos o abstracciones que agrupan a las piezas concretas
que aparecen en el juego de ajedrez, es decir, peón, caballo y torre entre otras,
constituyen clases, que entre sus responsabilidades tienen el color, la posición que
ocupan, la forma de avanzar y comer, etc. Los objetos son entonces los 16 peones (8
negros y 8 blancos), los 4 caballos, las 4 torres, el tablero, etc.

Durante una partida de ajedrez, dos peones negros que hayan sido comidos tienen
exactamente las mismas características y sin embargo son objetos distintos. Precisamente,
una de las características de los objetos que permite su identificación es su identidad.
“Identidad significa que los datos son divididos en entidades discretas y distintas,
denominadas objetos”.

Además los objetos pueden ser concretos o conceptuales, como el método de Gauss para
determinar raíces en sistemas de ecuaciones lineales.

Todo objeto tiene su propia identidad, que le es inherente, significa que los objetos se
distinguen por su propia existencia y no por las propiedades descriptivas que puedan
tener. Es esto lo que lo diferencia de los otros objetos semejantes. En otras palabras, dos
objetos son diferentes, incluso si todos los valores de sus características son idénticos.

Sin dudas que la forma de cada una de las piezas, el color, la manera de avanzar y comer,
en conclusión, las características (forma y color) y funcionalidades (manera de avanzar y

Unidad II. Introducción a la POO Página 17 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

comer) de cada una de las piezas, que no son más que sus responsabilidades, facilitaron
determinar los objetos en el ejemplo anterior.

6.- Diseño dirigido por responsabilidades

El concepto de diseño dirigido por responsabilidades (Chávez, 2003) es importante en las
etapas tempranas de la solución de problemas y cobra un alto valor notar que el
comportamiento de los objetos se puede estructurar en términos de las responsabilidades
de los mismos. Es por ello que en la identificación de las clases y objetos presentes en una
situación de análisis se debe considerar con fuerza la determinación de las mismas
(responsabilidades).

Los objetos analizados en una situación de análisis, tienen un estado determinado en

dependencia del valor de sus características. Por ejemplo, un niño tiene una edad
determinada y al cumplir año esta aumenta en uno, de igual forma un automóvil puede
pintarse para cambiar de color. Al mismo tiempo, estos objetos tienen un
comportamiento que viene dado por las acciones que pueden realizar. Por ejemplo, una
mamá duerme al niño, una persona se cepilla los dientes, etc.

Podemos concluir que el estado de un objeto viene dado por el valor de sus características
y el comportamiento del objeto por las acciones u operaciones que realiza. Es decir las
responsabilidades podemos dividirlas en dos grupos, aquellas que determinan el estado
(atributos) y las que determinan el comportamiento (métodos).

Otros autores denominan a los atributos de diversas formas: campos de datos o

simplemente campos (fields), propiedades o variables; mientras que a los métodos
también les suelen llamar: rutinas o funciones miembro.

Los atributos son valores almacenados por los objetos de una clase mientras que los
métodos son secuencias de pasos para determinar un comportamiento. Los métodos
pueden ser llamados (invocados) en principio, solamente desde dentro de la clase o a
través de una instancia u objeto de la misma.

Como se verá en secciones posteriores, es útil distinguir los métodos que tienen efectos
colaterales, es decir, que pueden cambiar el estado del objeto (métodos de
transformación), de los que apenas consultan el valor de algún atributo o realizan un
cálculo funcional sin modificar ningún el estado del objeto (método de consulta o acceso).

Unidad II. Introducción a la POO Página 18 de 19

Escuela de Ingeniería de Sistemas Informáticos UES/FIA
Programación I

Referencias
Chávez, R. P. (2003). Programación orientada a objetos con c#. La Habana: Universidad de Ciencias
Informáticas.

I, C. d. (2 de julio de 2003). Universidad Técnica Federico Santa María. Obtenido de Departamento

de Informática: https://www.inf.utfsm.cl/~ric/sia/textos/casos%20de%20uso.pdf

Kimmel, P. (2008). Manual de UML, Guia de aprendizaje. Mexico: Mc Graw Hill.

Unidad II. Introducción a la POO Página 19 de 19