CONCEPTOS BÁSICOS

DE ORIENTACIÓN A
OBJETOS
Inf-512 Programación I
UNIDAD I
OBJETIVOS DE LA UNIDAD

■ Introducir al estudiante en el ambiente y

conceptualización de la POO.
■ Introducir los conceptos y elementos esenciales de
POO.
Abstracción
■ El proceso de abstracción inicia con la remoción gradual
de los detalles excesivos que son de valor estético pero
que no contribuyen a la identidad del objeto como
elemento para almacenar información de interés.
Tomemos como ejemplo el procesamiento de
información de la nómina de un empleado.
Abstracción
■ Sobre el empleado existen muchos atributos como son:
nombre, estatura, cedula, fecha nacimiento, nss, intereses,
dirección, salario, entre otros.
■ Los atributos a usar para procesar la nómina serían: nombre,
cedula y salario.
■ Las operaciones a ejecutar son las siguientes:
Registro de empleado (incluirEmpleado), consulta (verDatos),
actualización (actualizarDatos).
 Lenguajes de modelado de objetos

■ Sirven para ayudar al proceso de abstracción, los

cuales están basados en un conjunto
estandarizado de símbolos y formas de
organizarlos para el modelado de sistemas de
software basados en tecnología de orientación a
objeto. UML (Lenguaje Unificado de Modelado)
es el más conocido.
Lenguaje Unificado de
Modelado
Unified Modeling Language (UML)
 Lenguaje Unificado de Modelado
UML es una metodología de diseño que consiste en una serie
de modelos textuales y gráficos de la solución propuesta.
Estos modelos definen el alcance del sistema.
UML fue creada desde principios de 1980. Es una forma
estándar y sistemática para modelar el diseño de programas
POO.
Esta industria fue creada y manejada por la Object
Management Group (OMG).
 Lenguaje Unificado de Modelado
También definen sus componentes, la interacción del
usuario con el sistema y como los componentes del sistema
interactúan entre si para implementar la funcionalidad del
sistema.
La fase de diseño es una de la más importante en el proceso
o ciclo de desarrollo de software.
Un proyecto de software fallido puede estar asociado a un
pobre diseño y a una comunicación inadecuada entre
desarrollador y consumidor.
 Lenguaje Unificado de Modelado
EJEMPLOS DE MODELOS UML
1. Especificación de Requerimiento de Software (Software Requirement
Specification –SRS-). Modelos 1-3 se usan para modelar los
2. Caso de Uso (Use Case). aspectos estáticos (organizativos) de
una solución OOP.
3. Diagrama de clases. Modelos 4-6 se centra en el modelado
4. Diagrama de secuencia. de los aspectos dinámicos (de
comportamiento) de una solución OOP.
5. Diagrama de colaboración.
6. Diagrama de actividad.
NOTA: Los modelos UML 4 y 5 de esta lista también
son conocidos como diagramas de interacción
 MODELO SRS
Especificación de Requerimiento de Software
(Software Requirement Specification –SRS-).

PROPÓSITOS
Definir los requerimientos funcionales del sistema.
Identificar los limites del sistema.
Identificar usuarios.
Describir la interación entre el sistema y los
usuarios externo.
Establecer comunicación entre clientes y desarrolladores
para describir el sistema deseado.
 Dar paso al siguiente modelo (caso de uso) ofreciendo
los elementos básicos.
 MODELO SRS
Especificación de Requerimiento de Software
(Software Requirement Specification –SRS-).

Para producir este modelo se debe hacer una entrevista al

dueño del negocio, empresa u organización y a los usuarios
finales del sistema.
El objetivo de la entrevista es documentar los procesos del
negocio y establecer el alcance del sistema.
El resultado es un documento formal que detalla los
requerimientos del sistema. Este documento establece
los acuerdos entre el cliente y el desarrollador.
 MODELO SRS
Especificación de Requerimiento de Software
(Software Requirement Specification –SRS-).

El SRS no hace referencia a los requerimientos técnicos del

sistema.
Una vez desarrollado este modelo (SRS) los requerimientos
funcionales contenido en el mismo se transforman en un
diagrama de caso de uso (segundo modelo en el proceso de
diseño).
 MODELO CASO DE USO
 Modelan los servicios que proporcionará el sistema.
Este modelo describe como las entidades externas pueden
usar un sistema. Las entidades externas pueden ser:
humanos u otros sistemas. En el contexto de UML estas
entidades son conocidos como actores.
El caso de uso ayuda a definir el alcance y limite del sistema.
Suele hacerse en forma de diagrama con una descripción de
la interacción que se produce.
 MODELO CASO DE USO
Los casos de uso son desarrollados tomando como punto de
partida el modelo SRS. Cada interacción que ocurre entre un
actor y el sistema debe ser modelado como un caso de uso.
El actor es cualquier entidad externa que interactúa con el
sistema, puede ser:
• Un usuario (humano) por ejemplo, un agente de cobro
• Otro sistema, por ejemplo, un software de facturación
• Una interfaz de un dispositivo, por ejemplo, un sensor de
temperatura.
Caso de uso
Recuerde que los casos de uso no se centran en cómo el
sistema realizará las funciones, sino en qué funciones deben
incorporarse en el sistema desde el punto de vista del
usuario.

Una vez que haya desarrollado los casos de uso del sistema,
puede comenzar a identificar los objetos internos del
sistema que llevará a cabo los requisitos funcionales del
sistema. Esto se hace usando un diagrama de clases.
 MODELO CASO DE USO
EJEMPLO. DIAGRAMA
DE CASO DE USO
SISTEMA
(diagrama genérico).
Con dos actores y tres
Actor 1 Caso de uso 1 casos de uso.
Nota: Estos casos de uso
Caso de uso 2
se convierten en
procesos del sistema.
Actor 2 Caso de uso 3
 MODELO CASO DE USO
Con este modelo se representa cada interacción que ocurre
entre un actor y el sistema. Por ejemplo, para la creación de
un sistema de una aerolínea se puede considerar el siguiente
caso de uso: ver información de vuelo.
Este a su vez es uno de los requerimientos del modelo SRS.

Ver
CLIENTE (Actor) información
de vuelo
 MODELO CASO DE USO
Se debe evitar los siguientes errores en el modelo de casos de uso:
1. No debe incluirse acción inicializada por el sistema.
Ejemplo: El sistema envía una confirmación al cliente vía correo
electrónico.
2. No debe incluir una descripción de los requerimientos técnicos del
sistema.
Es importante recordar que el enfoque no es cómo el sistema desarrolla
las funciones, sino cuáles funciones deben
Ser incorporadas en el sistema desde el punto de
Vista del usuario.
 DIAGRAMA DE CLASE
Con el siguiente modelo (Diagrama de clase) se procede a
identificar los objetos internos del sistema que llevaran a cabo
los requerimientos funcionales del sistema (tomados del
modelo SRS).
 MODELO DIAGRAMA DE CLASE
Sirve para visualizar las operaciones (métodos) y atributos
(campos) de las clases.
Ya sabemos que en la programación orientada a objeto los
conceptos de objeto y clase son fundamentales. Considerar
el siguiente ejemplo. CLASE Estudiante

Los objetos son instancias de la

Nombre
clase. Los cuales tienen
atributos (tamaño, tipo, color, Matricula
etc) y operaciones o eventos
que desarrollan (métodos) Inscripción
 MODELO DIAGRAMA DE CLASE
• Se identifica una lista de clase potencial que pudieran ser
necesarias tomando como referencia los modelos SRS y caso
de uso, observando los nombres comunes incluidos en el
SRS y la descripción de los casos de uso.
• Identificar los nombres comunes. Las clases estarán definidas
por los objetos identificados con sus atributos y
comportamiento comunes.
 MODELO DIAGRAMA DE CLASE

Al definir la estructura de la clase se determina a través

de sus atributos (campos) el tipo de información que
manejara. Las clases contienen atributos y operaciones
(métodos) que podemos visualizar a través del
diagrama de clase.
 HERRAMIENTAS PARA CREAR LOS
MODELOS
Para crear los modelos o diagramas usamos herramientas
CASE (Computer-Aided Software Engineering), por ejemplo:
1. Visio de Microsoft
2. Umlet
Esta segunda esta disponible de forma gratuita en la siguiente
dirección www.unlet.com
 EJEMPLO
SISTEMA WEB PARA RESERVACIÓN DE VUELO EN LÍNEA
• En el presente ejemplo tenemos un dueño de una pequeña aerolínea regional
interesado en ofrecer sus servicios a los clientes a través de un sistema web para
que estos consulten información de vuelo y hagan sus reservaciones en línea.
• Después de entrevistar a los gerentes del negocio, los representantes o agentes
de boletos y los usuarios finales del sistema, se procede a documentar
claramente los procesos del negocio y establecer el alcance del sistema. Este
proceso da como resultado un documento formal donde se detalla los
requerimientos funcionales del sistema. Ese documento es un SRS, Especificación
de Requerimiento de Software
(SRS por sus siglas en inglés, Software Requirement Specification), presentado a
continuación.
 Modelo SRS
• -Los usuarios no registrados pueden entrar al sitio web de la
aerolínea para ver las informaciones de vuelo pero no pueden
hacer reservaciones.
• -Los nuevos clientes interesados en reservar vuelo pueden
completar un formulario de registro con los siguientes datos:
nombre, dirección, nombre de la compañia, número de teléfono,
dirección de correo.
• -El cliente es clasificado como corporativo o cliente minorista.
• -El cliente puede hacer búsqueda de vuelos basado en el destino y
hora de partida.
 Modelo SRS
• -El cliente puede reservar vuelo indicando el número de vuelo y numero de
asiento solicitado.
• -El sistema envía una confirmación al cliente vía correo electrónico cuando el
vuelo es reservado.
• -Los clientes corporativos reciben millas de vuelo cuando sus empleadores
reservan vuelo.
• -Las millas acumuladas por vuelos frecuentes son usadas para hacer descuentos a
futuras solicitudes.
• -La reservación puede ser cancelada después de una semana con una devolución
del 80%.
• - Los representantes o agentes de boletos pueden ver y actualizar la información
de vuelo.
 Modelo Caso de Uso
Además de la representación gráfica, algunos diseñadores y CASO DE USO
desarrolladores de software suelen ofrecer una descripción información de vuelo
textual del caso de uso. Esta descripción debe ser breve y
enfocada en lo que está pasando no en como ocurre. Pueden
ser identificadas algunas condiciones previas y condiciones
posteriores asociadas al caso de uso, por ejemplo: Ver
información
• Descripción: El cliente ve la información de vuelo en la de vuelo
página. Hace búsqueda para visualizar la lista de vuelos o
informaciones disponibles de acuerdo a su criterio de CLIENTE
búsqueda.
• Condiciones previas: Ninguna.
• Condiciones posteriores: El cliente tiene la oportunidad de
registrarse y entrar a la página de reservación.
 Modelo Caso de Uso
• Descripción: El cliente suministra el numero de vuelo e CASO DE USO
indica el asiento solicitado. Después de hacer la solicitud Reserva de vuelo
recibe la información de confirmación.
• Condiciones previas: El cliente entro al sistema con su
usuario, tiene información sobre el vuelo desde la pantalla
de reserva. Reserva de
vuelo
• Condiciones posteriores: El cliente recibe un e-mail de
confirmación con los detalles del vuelo y las políticas de
cancelación de vuelo. CLIENTE

Importante. También se puede considerar otros casos de

uso: registro del cliente, cancelar vuelo, buscar vuelo,
actualizar vuelo.
 MODELO CASO DE USO
IMPORTANTE
SISTEMA Importante. También se puede
considerar otros casos de uso:
Ver
CLIENTE información registro del cliente, cancelar
de vuelo vuelo, buscar vuelo, actualizar
vuelo.
Reserva de
vuelo
 Caso de uso, extensión
Otra forma en que los casos de uso
se relacionan entre sí es a través de
la extensión.
El caso de uso base se amplía con
otros casos de uso.
Por ejemplo, podría tener un caso
de uso Registrar cliente que describa
el proceso central de registrar
clientes con dos casos de uso:
Registrar cliente corporativo y
Registrar cliente minorista para
ampliar el caso de uso base.
Caso de uso, inclusión
El caso de uso de reservar
asiento (asiento de reserva)
incluye el caso de uso Ver
información de vuelo.
Esta relación es útil porque
puede usar el caso de uso Ver
información de vuelo
independientemente del caso
de uso Reservar vuelo. Esto se
llama inclusión.
Extensión Vs Inclusión
La diferencia entre extensión e inclusión es que, en la
extensión, el caso de uso base que se amplía no se utiliza por
sí solo.
Cuando un caso de uso incluye otro caso de uso, el caso
de uso que se incluye debe ejecutarse como condición
previa. Pero puede usar el caso de uso que se incluye
independientemente del caso de uso principal.
 IMPORTANTE
También se puede considerar otras
NOTACION UML DE UNA CLASE clases: cliente, agente (agente de
boleto), usuario (usuario no
registrado), para conformar el
diagrama completo del sistema donde
EJEMPLO. clase vuelo. se indicara las relaciones entre clases.
Nombre de la clase Vuelo

Numero de vuelo
Fecha Miembros de la clase
Atributos o Origen
campos Destino
Hora despegue
Hora llegada
Capacidad de asiento

Operaciones
o métodos AsientosReservados()
AsientosSinReservar()
 Notación UML para una clase
vuelo

<NombreClase> Numero de vuelo

Fecha / Origen / Destino
Hora despegue / Hora
Miembros < atributos o campos>
llegada
de la clase Capacidad de asiento

AsientosReservados()
<métodos u operaciones> AsientosSinReservar()

{ información adicional }

Una clase esta hecha, básicamente, de un nombre único, un numero de atributos y de un conjunto de
operaciones; Toda la funcionalidad del sistema es definida por las operaciones de los objetos
de sus clases; permite tener información del estado del objeto o cambiar su estado.
 Sintaxis de miembros de una clase
La sintaxis para escribir los miembros de la clase es como sigue:
 Atributos o campos: es recomendable que el acceso siempre sea: -
acceso ( - , + ) ID : tipo = valor inicial { información adicional }

Ejemplo: - salarioMensual : double = 93456.23 { DOP }

 Métodos u operaciones: es recomendables que el acceso siempre sea +

acceso ( - , + , # ) ID (par1: tipo, par2: tipo, ... ) : tipo de retorno { info. adicional}

Ejemplo: + pagar( monto : double ) : boolean { si es true fue OK el pago }

Notación UML para una clase, aplicando
sintaxis de miembro.

UML: Lenguaje Unificado de Modelado

 CLASES,
EJEMPLOS
 nombre: CuentasPorCobrar
atributos: registro, fechaVencimiento, balance, historial,
comportamientos: actualizar, registrar, abonar,

 nombre: Inventario
atributos: registro, tipo, cantidad, control, proveedor
comportamientos: registrar, ingresar, descargar,
 nombre: Perro
atributos: patas, rabo, raza, nombre, peso, comidaPreferida,
comportamientos: ladrar, caminar, morder, jugar, estropear,

 nombre: FormularioWeb
atributos: fondo, marcos, URL, links, colores
comportamientos: navegar, grabar, marcarCopiarPegar, encuestar,
 nombre: Facultativo
atributos: especialidad, nombre, edad, peso,
comportamientos: diagnosticar, examinar, prescribir, demandar,

 nombre: Lubricante
atributos: nombre, precio, horasTrabajando,
comportamientos: chequear, comprar, escaparMotor, echar,
 nombre: Paciente
atributos: edad, enfermedad, peso, vidaUtil,
comportamientos: ingresar, egresar, comer, examinar,

 nombre: Estudiante
atributos: registro, nombre, peso, edad,
comportamientos: estudiar, jugar, rezar, trabajar, darBaja, evaluar,
promover,
Proceso para identificar las clases

■ El proceso inicia con La narrativa o declaración del

problema. Según UML el punto de partida seria el SRS.
■ El proceso de encontrar clases se realiza examinando la
narrativa o descripción del problema –SRS- (análisis
gramatical) y localizando nombres comunes, verbos y
adjetivos.
■ Luego de encontradas las clases será preciso identificar los
atributos y las operaciones asociada a cada clase.
Elementos del Elemento grammatical relacionado Ejemplo
modelo OO a
encontrar

Clases NOMBRES COMUNES Usuario

Haciendo una lista de nombres comunes, luego se procede a identificar
cuales aplican para formar las clases.

Comportamien VERBOS Reservar

tos o métodos Buscando y aislando los verbos del texto se puede encontrar las
operaciones

Atributos o ADJETIVOS Corporativo

campos Característica, cualidad, propiedad, particularidad, peculiaridad, singularidad,
rasgo, marca, carácter, idiosincrasia, naturaleza o condición del objeto;
Pasos para identificar las clases

■ Narrativa o declaración del problema, o SRS; Si no se tiene

las SRS, hacer el Análisis-dominio del problema.
■ Identificar los elementos gramaticales: nombres comunes,
verbos, abjetivos.
■ Hacer un listado, de los elementos gramaticales
identificados.
■ En el listado anterior eliminar los elementos redundantes.
Pasos para identificar las clases

■ Asociar cada elemento gramatical con el elemento del

modelo OO que le corresponde.
■ Hacer un listado de las clases encontradas, con sus
correspondientes atributos y operaciones.
■ Expresar las clases en notación UML aplicando la sintaxis
de miembro.
■ Hacer diagrama de clase modelando la relación entre
clases.
Modelado de la relación entre clases
■ En la ejecución de un programa en el ambiente de la programación
orientada a objeto ocurre que un conjunto de objetos deben
interrelacionarse para lograr cumplir la tarea esperada.
Por ejemplo, en la aplicación RESERVACIÓN DE VUELO, vista
anteriormente, para reservar un asiento en el vuelo la clase reservación
debe interactuar con la clase vuelo.
■ Lo anterior indica que existe una relación entre ambas clases y por lo
tanto puede ser modelada en la estructura de clase del programa. Esa
relación se puede expresar a través de un diagrama de clases.
■ Analizando los verbos en el modelo SRS se puede establecer las
relaciones.
Representación de las relaciones entre
clase a través de los diagramas de clase
ASOCIACIÓN
■ Este tipo de relación ocurre cuando una clase hace referencia o usa otra
clase formando una asociación entre ellas. Para representar dicha
asociación se traza una línea entre ambas clases y se agrega una etiqueta
con el nombre de la asociación.
■ EJEMPLO DE ASOCIACIÓN DE CLASE. La clase asiento se asocia
con la clase vuelo en el programa RESERVACIÓN DE VUELO

Contiene
VUELO ASIENTO
1 1..n
Asociación con múltiples instancias
■ Una instancia de una clase se puede asociar con múltiple instancia de
otra clase. Para representar dicha asociación se traza una línea entre
ambas clases.
■ Por ejemplo, en la aplicación RESERVACIÓN DE VUELO, cuando un
cliente realiza una reservación se establece una asociación entre la clase
cliente y la clase reservación, donde una instancia de la clase cliente se
puede asociar con múltiples instancias de la clase reservación, es decir,
un cliente puede hacer más de una reservación.
■ Se coloca la letra n al lado de la clase con varias instancias asociadas a la
otra clase. El siguiente diagrama de clase indica multiplicidad.

Realiza
Cliente Reservación
1 1..n
Auto asociación de clases
■ Cuando una instancia de una clase se asocia con múltiple instancias de la
misma clase.
■ Por ejemplo, en la aplicación RESERVACIÓN DE VUELO una instancia
de la clase piloto representa el capitán mientras otra instancia de la clase
piloto representa al co-piloto. El capitán dirige al co-piloto por lo tanto
se presenta una auto asociación de clase.
Dirige

Piloto
Co-
1
piloto
 Asociación de clases
Una vez que se establece la relación entre clases en un
programa se pueden presentar situaciones donde un atributo
(campo) no puede ser asignado a una clase por ser el
resultado de la asociación de varias clases. EJEMPLO,
Suple
una aplicación de inventario de pieza tendrá una clase
Suplidor Piezas
llamada piezas y una clase llamada suplidor.
1 1..n

Una pieza puede tener mas de un suplidor y el suplidor

puede suplir mas de una pieza. La situación en ese caso es,
donde colocar el atributo (campo) PrecioPieza ya que no
encaja como un atributo exclusivo de una de esas clases,
pero tampoco debe duplicarse o crearlo en cada una de las
clases. PrecioPieza
La solución es crear una asociación de clases que gestione
la información. Se crea una tercera clase llamada
PrecioPieza, dicha relación es representada como se
muestra aquí.
 HERENCIA
Es cuando múltiples clases comparten
algunas de las mismas operaciones y
atributos, la clase base contiene los
Cliente
elementos en común. La clase hijo
hereda de la clase base (clase padre).
En el diagrama de clase se representa Hereda Hereda

con una línea solida con una flecha

apuntando a la clase base. Por ejemplo,
en la aplicación RESERVACIÓN DE
VUELO las clases ClienteCorporativo ClienteMinoritario ClienteCorporativo
y ClienteMinoritario heredan atributos
y operaciones de la clase cliente.
 Diagrama de clases completo para la
aplicación reservación de vuelo
Cliente Reservacion Asiento
IdCliente NumeroDeFila
Realiza Reserva
Apellido NumeroDeReservacion
NumeroDeAsiento
Nombre 1 Fecha 1 1..n
0..n Precio
Direccion Estatus
Telefono
Correo 1..n
Contraseña Contiene
Hereda Hereda
1

Vuelo
ClienteMinoritario NumeroDeVuelo DIAGRAMA DE CLASE
ClienteCorporativo
Fecha Este diagrama muestra las clases,
LugarOrigen sus atributos y las DISTINTAS
NombreEmpresa RELACIONES.
TipoTargetaCredito MillasAcumuladas Destino
HoraDeSalida No muestra las operaciones
NumeroTargetaCredito NumeroFactura (métodos) relacionadas con cada
HoraDeLlegada
clase.
CapacidadAsiento
 Creación del programa. Transformar el
diseño en una implementación real.
■ Para hacer el programa que dará respuesta a la situación planteada se debe profundizar
un poco mas en los datos recopilados al principio (SRS, Caso de Uso, Diagrama de
clase).
■ El primer paso en este proceso es profundizar en las descripciones de los casos de uso y
crear un escenario más detallado de cómo se llevará a cabo el caso de uso.
■ Ver el ejemplo del sistema de pedido de suministro donde presenta un escenario que
describe una secuencia posible para llevar a cabo el caso de uso de inicio de sesión.

Ejemplo 1 Ejemplo 2
 Evitar algunos errores comunes de diseño
de programación orientada a objetos
Cuando comience a modelar sus propios diseños de programación
orientada a objetos, querrá asegurarse de seguir las mejores prácticas.
Las siguientes son algunas de las trampas comunes que debe evitar:

■ Tratar de modelar la solución completa al mismo tiempo: al

desarrollar sistemas complejos, divida el diseño y el desarrollo del
sistema en componentes manejables. Plan para producir el software
en fases. Esto proporcionará ciclos más rápidos de modelado,
desarrollo, prueba y lanzamiento.
 Evitar algunos errores comunes de diseño
de programación orientada a objetos
Las siguientes son algunas de las trampas comunes que debe evitar:
■ Esforzarse por crear un modelo perfecto: ningún modelo será perfecto
desde el principio. Los modeladores exitosos entienden que el proceso de
modelado es iterativo y que los modelos se actualizan y revisan
continuamente a lo largo del ciclo de desarrollo de la aplicación.
■ Pensar que solo existe una verdadera metodología de modelado: así
como existen muchos lenguajes de programación orientada a objetos
igualmente viables, existen muchas metodologías de modelado
igualmente válidas para desarrollar software. Elija el que funcione mejor
para usted y el proyecto en cuestión.
ANEXOS
• UML no es un lenguaje de programación, pero existen herramientas que se
pueden usar para generar código en diversos lenguajes usando los diagramas
UML. UML guarda una relación directa con el análisis y el diseño orientados a
objetos.
• Los lenguajes orientados a objetos dominan el mundo de la programación
porque modelan los objetos del mundo real. UML es una combinación de varias
notaciones orientadas a objetos: diseño orientado a objetos, técnica de
modelado de objetos e ingeniería de software orientada a objetos.
• UML usa las fortalezas de estos tres enfoques para presentar una metodología
más uniforme que sea más sencilla de usar. UML representa buenas prácticas
para la construcción y documentación de diferentes aspectos del modelado de
sistemas de software y de negocios
 Referencias
Beginning C# Object-Oriented Programming, Dan Clark.
Editora Apress, 2013

LUCIDCHART: Qué es el lenguaje unificado de modelado (UML)

https://www.lucidchart.com/pages/es/que-es-el-lenguaje-unif
icado-de-modelado-uml