Unidad 02

2020
Unidad II.- Introducción a la POO
Programación I
Escuela de Ingeniería de sistemas Informáticos
01/01/2020
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 28

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
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.

Programación I
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 inicios

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

Programación I
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
del objeto. Estos datos o variables son los que con sus valores en un momento dado, indican
el estado de un objeto.

Programación I
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.

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.

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

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
métodos. En octubre de 1994, Grady y James comenzaron a trabajar en la unificación de

Programación I
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.

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

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.

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.

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:

Programación I
1) Se usan letras preferiblemente, no se deben utilizar símbolos.

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
Ilustración 5 abajo, se puede omitir la punta
de
Unlacliente
flecha. 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

Unidad II. Introducción a la POO composición, otro tipo de relación. Página 14 de 28
Programación I
Ilustración 6
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

Programación I
Ilustración 7
3. Agregar asociaciones:
• Jugador lanza Dados

• Jugador juega Juego de Dados
• 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í:

Programación I
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).
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.

Programación I
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
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).

Programación I
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).

Programación I
7.- Diagramas de casos de uso.

Un Caso de Uso es una descripción de los pasos o las actividades que deberán realizarse
para llevar a cabo algún proceso (Kimmel, 2008). Los personajes o entidades que
participarán en un caso de uso se denominan actores.
Un Caso de Uso es una secuencia de interacciones que se desarrollarán entre un sistema y

sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema.
Los Diagramas de Casos de Uso (DCU) sirven para especificar la comunicación y el

comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas.
O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso
en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo
la especialización y la generalización son relaciones.
Los DCU se utilizan para ilustrar los requerimientos del sistema al mostrar cómo reacciona
a eventos que se producen en su ámbito o en él mismo.
Los diagramas de casos de uso son responsables principalmente de documentar los

macrorrequisitos del sistema. Piense en los diagramas de casos de uso como la lista de
las capacidades que debe proporcionar el sistema. La finalidad de un caso de uso es describir
la manera en que se usará un sistema: describir sus finalidades esenciales. La finalidad de
los diagramas de casos de uso es captar en forma visual las finalidades esenciales.
Los diagramas de casos de uso parecen muy fáciles; constan de figuras de línea, líneas y
óvalos. La figura de palillos se llama actor y representa a alguien o algo que actúa sobre
el sistema. En el desarrollo de software, los actores son personas u otro software que actúa
sobre el sistema. Las líneas son punteadas o continuas, con varias flechas o sin ellas,
que indican la relación entre el actor y los óvalos. Estos últimos son los casos de uso y, en
el diagrama de casos de uso, los óvalos tienen algún texto que proporciona una descripción
básica.
Ilustración 10

Programación I
Que un diagrama de casos de uso sea fácil de crear es un elogio implícito para el uml.
Hallar los casos de uso correctos y registrar sus responsabilidades en forma correcta es la
decepción. Hallar los casos de uso correctos y describirlos de manera adecuada es el
proceso crítico que impide que los profesionales en el desarrollo informático pasen por alto
necesidades críticas y que inventen de manera innecesaria. En pocas palabras, los
diagramas de casos de uso constituyen un macrorregistro de lo que usted quiere
estructurar.
Macro en este contexto sencillamente significa “grande”. Los grandes objetivos, o
macroobjetivos, son los que se mencionan como los argumentos, o razones, poderosos de
las organizaciones para hacer algo. En los diagramas de casos de uso se captan los objetivos
grandes, importantes. En el texto de esos casos se captan los detalles de apoyo.
Esto es lo que se escapa en las imágenes de las figuras de línea de los diagramas
de casos de uso; se perdía de vista que, al registrar lo que el sistema hará y
lo que no hará, se registra y especifica el alcance de lo que se está creando; también se
pierde de vista que el texto que acompaña los diagramas de casos de uso rellena los
espacios en blanco entre los macroúsos y los microúsos, en donde micro significa usos
“menores, de apoyo”. Además de registrar los usos primarios y secundarios, los diagramas
de casos de uso nos proporcionan en forma implícita varias oportunidades significativas
para administrar el desarrollo.
Símbolos de actores.
La figura de palillos, mencionada como actor, representa participantes en los casos de

uso. Los actores pueden ser personas o cosas. Si un actor es una persona, entonces, en
realidad, nunca se puede representar por medio de un código. Si un actor es otro
subsistema, entonces se le puede observar como una clase o subprograma, pero todavía
representarse usando el símbolo de actor en los diagramas de casos de uso.
Los actores se descubren como resultado del análisis. Conforme se vayan identificando
los macrousos del sistema, se podrá identificar quiénes son los participantes para esos casos
de uso. En principio, se registra cada actor a medida que se descubre, agregando un símbolo
de actor a su modelo y describiendo cuál es su papel.
Casos de uso
El símbolo del caso de uso se utiliza para representar capacidades. Al caso de uso se
le da un nombre y una descripción mediante un texto. Este último debe describir cómo
inicia y finaliza el caso de uso, e incluye una descripción de la capacidad descrita por
el nombre de la misma, así como escenarios de apoyo y requisitos no funcionales

Programación I
Ilustración 11
Dado que los diagramas de casos de uso tienen múltiples actores y en virtud de que los
casos de uso pueden estar asociados con los actores y con otros casos de uso, se utilizan
los conectores para indicar la manera en que ambos están asociados. Además, los estilos
de conectores pueden cambiar para transmitir más información acerca de la relación
entre los actores y los casos de uso. Por último, los conectores pueden tener adornos y
anotaciones que suministran incluso más información.
Estilos de líneas para los conectores
Existen tres estilos básicos de líneas para los conectores. Un conector de línea simple se
llama asociación y se usa para mostrar cuáles actores están relacionados con cuáles casos
de uso. Por ejemplo, en la ilustración 10 se mostró que un patrón está asociado con el caso
de uso “Crear lista de trabajos”.
Un segundo estilo de conector es una línea punteada con una flecha direccional (ilustración
12). Este estilo de conector se conoce como dependencia. La flecha apunta hacia el caso de
uso del que depende. Por ejemplo, suponga que a los patrones de www.tecoloco.comse les
debe dar acceso para crear una lista de trabajos. Entonces podemos decir que el caso de
uso “Crear lista de trabajo” depende de un caso de uso “Entrar”. Ésta es la relación que se
ilustra en la ilustración 12.
Ilustración 12

Programación I
Un tercer estilo de conector es una línea dirigida con un triángulo hueco, al cual se le
conoce como generalización. La palabra generalización en el uml significa “herencia”.
Cuando mostramos una relación de generalización entre dos actores o dos casos de uso,
estamos indicando que el actor o el caso de uso “hijos” son un caso del actor o uso básico
y algo más. En la ilustración 13, se muestra una relación de generalización entre dos actores
y dos casos de uso.
Ilustración 13
Estereotipado de los conectores
Una notación común en los conectores es el estereotipo. Los estereotipos agregan detalles
a la relación entre los elementos en un diagrama de caso de uso. Por ejemplo,
en ilustración 12, donde se introdujo el conector de dependencia. Se puede usar un
estereotipo para ampliar el significado de este conector.
Anteriormente se dijo que un patrón puede crear una lista de trabajos y se ilustró con un
actor patrón, un caso de uso “Crear lista de trabajos” y un conector de asociación; sin
embargo, también se sabe que el patrón debe obtener acceso. Cuando un caso de uso
“Crear lista de trabajos” necesita los servicios de otro caso de uso —“Entrar”— entonces se
dice que el caso de uso dependiente incluye el caso de uso del que depende.
Un estereotipo se muestra como texto entre los caracteres « y » (comillas angulares).

Por ejemplo, si decimos que “Crear lista de trabajos” incluye a “Entrar”, entonces se puede
representar un estereotipo incluir colocando una anotación en el conector de dependencia como se
muestra en la ilustración 14.

Programación I
Ilustración 14
Uso de los estereotipos extender

El estereotipo extender se usa para agregar más detalle a una dependencia, lo cual significa
que estamos agregando más capacidades (como ejemplo, vea la ilustración 15). Como se
muestra en la figura, decimos que “Registrar las listas vistas” extiende (y depende de) “Ver
lista”.
En la sección anterior, no permitiríamos que un patrón creara una lista de trabajos

sin registrarse, pero en el caso del registro del caso de uso entrar es indiferente para la
reutilización del caso. En esta sección, a el caso de uso ver lista no le importa que la estén
registrando; en otras palabras, la característica registrar necesitará saber acerca de la
característica ver lista, pero no en sentido contrario.
Una perspectiva valiosa aquí es quién podría estar interesado en el registro. Es evidente que
al “Solicitante de trabajo” tal vez no le interese cuántas veces se ha visto la lista,
pero un patrón previsor podría estar interesado en cuánto tráfico está generando su lista.
Pasemos ahora por un momento a un dominio diferente. Suponga que el “Solicitante de
trabajo” fuera el comprador de una casa y que la lista lo fuera de residencias. Ahora tanto
el comprador como el vendedor podrían estar interesados en el número de veces que se
ha visto la propiedad. Una casa que ha estado en el mercado durante meses puede tener

Programación I
Ilustración 15
Inserción de notas
El uml es una taquigrafía para una gran cantidad de texto y de código, pero si lo necesita,
siempre puede agregar texto. Todos los diagramas, incluyendo los casos de uso, permiten
que se les agreguen anotaciones en forma de texto. Las notas se representan como un
trozo de papel con una punta doblada y una línea que une el cuadro de texto al elemento
que se le está haciendo la anotación (ilustración 16). Use las notas con moderación, porque
pueden abarrotar un diagrama y hacerlo difícil de leer.
Ilustración 16
Documentar los casos de uso
Documentar casos de usos no es una tarea fácil que se pueda dominar de un día para otro,
requiere de tiempo, disciplina y experiencia, sin embargo podemos definir una serie de
pasos identificables para escribir los casos de uso (I, 2003).
Programación I
1. Identifique a todos los actores que intervienen.
2. Identifique todas las tareas que realizará cada actor.
3. Agrupe las tareas repetidas.
4. Genere el diagrama(s) UML que represente esquemáticamente los Casos de Uso.
5. De una prioridad a cada caso de uso.
6. Por cada caso de uso escriba un documento detallado siguiendo la plantilla

especificada anteriormente.
Un ejemplo de plantilla a utilizar puede ser la siguiente:
RF- 01 Alta de socio

Objetivos asociados OBJ–02 Gestionar las socios
Requisitos asociados RI–02 Información sobre socios
Descripción El sistema deberá comportarse tal como se describe en el
siguiente caso de uso cuando alguien solicite su ingreso
como
socio
Precondición El solicitante no es un socio del vídeo–club y tiene su
documentación disponible
Secuencia Paso Acción
Normal 1 El empleado del vídeo–club solicita al sistema
comenzar el proceso de alta de un nuevo socio
2 El sistema solicita los siguientes datos del nuevo
socio: nº del DNI, nombre, apellidos, fecha de
nacimiento, sexo, dirección y teléfonos de
contacto
3 El empleado del vídeo–club solicita los datos
requeridos y la documentación al nuevo socio
4 El empleado del vídeo–club comprueba que los
datos
del nuevo socio coinciden con los de la
documentación aportada
5 El empleado del vídeo–club proporciona los
datos requeridos y solicita al sistema que los
almacene

Programación I
6 El sistema almacena los datos proporcionados,

imprime el carnet de socio e informa al
empleado del vídeo club de que el proceso ha
terminado con éxito
7 El empleado del vídeo–club entrega el carnet al
nuevo
socio
Postcondición El solicitante es socio del vídeo–club y el saldo de su
cuenta es
0
Excepciones Paso Acción
4 Si la documentación aportada no es correcta, el
empleado del vídeo–club cancela la operación, a
continuación este caso de uso termina
5 Si el sistema detecta que el nuevo socio ya es
socio
del vídeo–club, el sistema informa de la situación
al
empleado del vídeo–club permitiéndole
modificar los
datos proporcionados, a continuación este caso
de uso
continúa
5 Si el empleado del vídeo–club solicita cancelar la
operación, el sistema cancela la operación, a
continuación este caso de uso termina
Rendimiento Paso Cota de tiempo
4 5 segundos
Frecuencia esperada 10 veces/día
Estabilidad alta
Comentarios La frecuencia será mucho mayor durante los dos
primeros meses, probablemente 100 veces/día

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 02

Cargado por

Copyright:

Formatos disponibles

Unidad 02

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 02

Cargado por

Copyright:

Formatos disponibles

2020

Unidad II.- Introducción a la POO

INTRODUCCIÓN A LA PROGRAMACIÓN ORIENTADA A OBJETOS

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

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

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

1.- Programación Orientada a Objetos

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

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

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

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

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

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

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

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

Paradigma Ventajas Desventajas

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

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

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

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

3.- Terminología Básica

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

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

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

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

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

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

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

Las relaciones entre clases pueden ser las siguientes:

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

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

4.- Técnicas de la POO

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

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

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

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

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

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

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

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

4.5 Reusabilidad o Reutilización de Código.

5.- Lenguaje de Modelado UML

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

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

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

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

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

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

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

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

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

Convenciones Utilizadas en los Diagramas

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

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

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

Posteriormente, se representa formalmente el modelo conceptual resultante usando un

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