Unidad 3 - Diseño orientado a

objetos e Introducción a UML

PROGRAMACIÓN ORIENTADA A OBJETOS
Contenido
3.1 Los pilares del paradigma orientado a objetos
3.2. Introducción a UML.
3.3. Diagrama de clases.
3.4. Interacción de Clases.
Objetivos
3.1 Reconocer los 4 pilares del paradigma para la creación de modelos
orientado a objetos.

3.2 Construir diagramas de clases para el diseño y documentación de

un programa orientado a objetos.
Diseño orientado a
objetos
Proceso de desarrollo de software
Proceso de desarrollo de software
• Análisis
• Diseño
• Implementación
• Pruebas

Análisis Diseño Implementación Pruebas

Proceso de desarrollo de software
• Análisis: Enfatiza una investigación del problema y los requisitos, en
lugar de una solución. Por ejemplo, si se desea un nuevo sistema de
punto de ventas, ¿cómo se utilizará? ¿Cuáles son sus funciones?

• Identificar los requerimientos del sistema

• Productos de esta fase:
• Casos de usos del sistema
Proceso de desarrollo de software
• Diseño: Enfatiza una solución conceptual (en software y hardware)
que cumpla con los requisitos

• Se definen las clases del sistema y como interactúan entre ellas

• Productos de esta fase:
• Diagrama de clases
Proceso de desarrollo de software
• Implementación: Consiste en trasladar el diseño al lenguaje de
programación. Durante esta fase puede ser que se encuentren
fallos en el diseño que deben ser corregidos.
Análisis de
Requerimientos
Caso de estudio POS
• Un sistema de punto de ventas, POS, es una aplicación
computarizada usada (en parte) para registrar ventas y manejar
pagos.
• El proceso de venta es el siguiente: Un cliente llega a la caja con
artículos para comprar. El cajero utiliza el sistema POS para registrar
cada artículo comprado. El sistema presenta el total de la compra y
detalles de cada articulo comprado. A continuación el cajero ingresa
la información del cliente y del pago el cual el sistema lo valida y lo
registra. El POS se comunica con el sistema de inventarios y
actualiza el inventario de los productos. El cliente recibe un recibo y
luego se va con los artículos
Caso de estudio POS
• El sistema debe registrar el nombre, cédula y correo del cliente. Los
clientes afiliados al establecimiento reciben un precio especial en
sus productos.
• El POS debe ser capaz de manejar pagos en efectivo y con tarjeta de
crédito. De los pagos con tarjeta de crédito se debe guardar el
nombre del banco y el número de la tarjeta con el que se hizo la
compra. El cliente puede pagar con más de un medio de pago. Al
finalizar la compra se debe imprimir la factura de la compra con el
detalle del producto.
Análisis de requerimientos
• Los requeriminetos son capacidades y condiciones que el sistema
y, en términos más generales, el proyecto debe cumplir.

• En en el análisis de requerimientos debemos encontrar, comunicar

y documentar lo que realmente se necesita, en una forma que
hable claramente al cliente y a los miembros del equipo de
desarrollo.
Actores
• Un Actor es algo con comportamiento, como una persona
(identificada por rol), sistema informático u organización) que
interactua con el sistema
Caso de uso.
• Un caso de uso es la descripción de una acción o actividad que se
lleva a cabo en el sistema.
• Estudiante inicia sesión en el Sidweb
• Profesor publica tarea en el siweb

• Un caso de uso tiene uno o varios escenarios

• Estudiante inicia sesión en el Sidweb
• Escenario 1: Ingresa clave y contraseña, credenciales son válidas, se muestra la página
de inicio
• Escenario 2: Ingresa clave y contraseña, credenciales no son válidas, se muestra
mensaje de error y se vuelve pagina de inicio
Caso de estudio POS - ACTORES
• Un sistema de punto de ventas, POS, es una aplicación computarizada usada (en parte) para registrar ventas y manejar
pagos.
• El proceso de venta es el siguiente: Un cliente llega a la caja con artículos para comprar. El cajero utiliza el sistema POS
para registrar cada artículo comprado. El sistema presenta el total de la compra y detalles de cada artículo comprado
(nombre, precio unitario, cantidad). A continuación, el cajero ingresa la información del cliente y del pago el cual el
sistema lo valida y lo registra. El POS se comunica con el sistema de inventarios y actualiza el inventario de los
productos. El cliente recibe un recibo y luego se va con los artículos
• El sistema debe registrar el nombre, cédula y correo del cliente. Los clientes afiliados al establecimiento reciben un
precio especial en sus productos.
• En el caso de los clientes afiliados el sistema necesita saber su numero de afilicion y fecha desde las que se afilio
• El POS debe ser capaz de manejar pagos en efectivo y con tarjeta de crédito. De los pagos con tarjeta de crédito se
debe guardar el nombre del banco y el número de la tarjeta con el que se hizo la compra. El cliente puede pagar con
más de un medio de pago. Al finalizar la compra se debe imprimir la factura de la compra con el detalle del producto.
Caso de estudio POS
• Actores:
• Cajero
• Sistema de inventario
• Servicio de autorización de pago
Caso de estudio POS - CASOS
• CASO:
• ACTOR:
• PRECONDICIÓN:
• DESCRIPCIÓN:
Caso de estudio POS
• CASO: Iniciar sesión cajero POS
• ACTOR: Cajero
• PRECONDICIÓN: no hay una sesión abierta
• DESCRIPCIÓN:
• 1. Cajero ingresa usuario y contraeña.
• 2. Sistema valida las credenciales.
• 3. Se presenta pagina inicial pos
Caso de estudio POS
• CASO: Realizar nueva venta
• ACTOR: Cajero
• PRECONDICIÓN: cajero estaba autenticado
• DESCRIPCIÓN:
• 1. Cajero incia nueva venta.
• 2. Cajero registra un item.
• 3. Sistema registra el item en la venta y presenta información del item
• 4. Sistem calcula el total de la venta y lo presenta
• 5. Cajero ingresa información del cliente y de pago.
• 6. Sistema de autorizacion de pagos valida el pago
• 7. Sistema imprime el recibe
Caso de estudio POS
• CASO: Realizar nueva venta
• ACTOR: Cajero
• PRECONDICIÓN: cajero estaba autenticado
• DESCRIPCIÓN:
• 1. Cajero incia nueva venta.
• 2. Cajero registra un item.
• 3.1 El item ingresado no existe. Sistema presenta el error y no lo registra en
la venta
• 4. …
UML
UML
• UML significa Lenguaje Unificado de Modelado (UML, por sus
siglas en inglés, Unified Modeling Language)

• Usado ampliamente en la ingeniería de software ya que ofrece un

estándar para describir, visualizar, especificar, construir y
documentar gráficamente(diagramas) un sistema (modelo), este
incluye aspectos conceptuales de estructura y comportamiento.

http://www.uml.org/
UML – Tipos de diagrama
● Modelado de datos
○ Diagrama de clases, objetos, componentes, despliegue,
paquetes
● Modelado de comportamiento
○ Diagrama de casos de uso, actividades, estados, colaboración,
secuencia.
Diseño de la solución
Diagrama de clases
● Diagrama de la categoría de los diagramas estructurales( describir
la arquitectura de un sistema con bastante detalle. )
● Sirven para describir cómo se relacionan los elementos de un
sistema, qué atributos y operaciones les caracterizan.
Diagrama de clases
● Formato gráfico de una clase
– Atributos (Propiedades)
– Métodos (Operaciones)
Diagrama de clases
● Sintaxis de los atributos
visibilidad nombre: tipo = valor inicial
Animal
- nombre: String
- patas: int
Diagrama de clases

● Sintaxis de los métodos

visibilidad nombre(lista_parametros) : tipo_retorno
Diagrama de clases

● visibilidad
Interacción de Clases
Relaciones entre clases
Interacción de Clases
• Asociación
• Asociación Simple
• Agregación
• Composición
• Generalización (Herencia)
Interacción de Clases
Relación de asociación
● Relación estructural para indicar la vinculación entre
instancias de clases.
● Una asociación se forma al unir dos clases con una línea.
Interacción de Clases
Relación de asociación - Nombre de las relaciones
● El nombre de la asociación se coloca sobre la línea en la mitad (se lee
de izquierda a derecha)
● Buenas relaciones tienen sentido al leerlas.
Interacción de Clases
Relación de asociación - Roles
● Se escriben al final de una línea de asociación y describen el
propósito jugado por esa clase en la relación.
Interacción de Clases
Interacción de Clases
• Ejemplo de indicadores de multiplicidad y su significado
Interacción de Clases
Relación de asociación - Multiplicidad
● Indica cuántas instancias de una clases participan en la
relación
● La multiplicidad se puede indicar con un rango (0..1, 2..5), un
rango sin cota (0..*, 1..*), un valor (1) o una serie de valores
(1, 3, 5).

1 1..3
PEDIDO PIZZA
¿Dado un carro, cuántos dueños puede
tener?

1..* 1
Carro Dueño
¿Dada una pescera, cuántos peces puede
albergar?

0..* 1
Pez Pescera
Una cuenta bancaria puede tener dos
titulares

1..2 1..*
Cuenta
Titular
Bancaria
Interacción de Clases
• Modelar la relación entre un Escritor y un Libro.

• La asociación es llamada escribe

• El diagrama muestra los roles a cada extremo los roles
• Escritor: juega el rol de autor.
• Libro: juega el rol de texto.
Interacción de Clases
• Modelar la relación entre un Escritor y un Libro.

• La relación tiene multiplicidad - Cada objeto Libro está asociado a uno o más objetos Escritor
(1..*). Cada objeto Escritor está asociado a uno o más objetos Libros (0..*).
• La asociación tiene una dirección. Escritor puede invocar métodos en objetos Libro, pero no
viceversa.
• La dirección de la flecha al final de la línea de asociación me indica la dirección.
• Si la línea de asociación no tiene flechas a los extremos, la asociación es bideireccional
• Un objeto Estudiante está relacionado con 1 a 4 objetos Materia.
• Un objeto Materia está relacionado con 1 a muchos objetos
Estudiante
• Un objeto Profesor está relacionado con 1 a 4 objetos Materia.
• Un objeto Materia está relacionada con 1 a 3 objetos Profesor
Interacción de Clases

• Navegación:
• Podemos navegar de Estudiante a Materia y de Materia a Estudiantes.
• Podemos navegar de Profesor a Materia, pero no de Materia a Profesor
¿Cómo se representa esto en JAVA?
¿Cómo se representa
esto en JAVA?
Ejercicio
• ¿Cómo modelaría el dominio de que un estudiante puede tomar
múltiple materias en un año de clases?
Clase de asociación
• Una clase de asociación es esencialmente una clase atada a una
asocian que es usada para modelar una asociación como una clase
UML. Esta tiene su propio nombre, atributos y operaciones. Sin
embargo, estas clases describen atributos adicionales los cuales no
pertenecen a los objetos involucrados en la asociación.
• Por ejemplo, una clase Inscripción es añadida para mantener el atributo
año entre la clase Estudiantes y la clase Curso, pero este no pertenece ni a
la clase Estudiante ni a la clase curso
Clase de asociación
• ¿Cómo modelaría el dominio de que un estudiante puede tomar
múltiple materias en un año de clases?
Asociaciones ternarias
¿Cómo se representa
esto en JAVA?
Interacción de Clases
Relación de asociación - Reflexiva
● Es posible que una clase se asocie consigo
misma (asociación reflexiva)
Múltiples asociaciones entre dos tipos
• Dos tipos pueden tener múltiples asociaciones entre ellos. Esto no
es poco común. Por ejemplo en el dominio de una aerolínea
tenemos la relación entre a Flight y a Airport.
• Las asociaciones Flies-to y Flies-From son diferentes relaciones las cuales
deben ser modelas por separado.
Múltiples asociaciones entre dos tipos
Interacción de Clases
Relación de agregación
• Una relación de agregación es la que forma un todo con sus partes.
• Son un tipo especial de relación de asociación.
• Puede tener nombre, roles, multiplicidad.
• En las relaciones de agregación, un objeto que representa una parte
puede estar compartido por varios objetos que representan el
todo(un alumno está en un curso y también puede estar en un grupo
de amigos)
Interacción de Clases
Ejemplo relación de agregación
Interacción de Clases
Relación de composición
● Las relaciones de composición son un tipo especial de relación de
agregación.
● Los objetos parte siempre están asociados a un objeto todo y sólo
a uno, se crean y se destruyen con él (coche y ruedas).
● Los objetos parte no pueden compartirse entre varios objetos
todo.
Interacción de Clases
Interacción de Clases
Interacción de Clases
Relación de Herencia/Generalización
Se representa mediante una flecha, cuya punta es un
triángulo vacío. La flecha que representa a la herencia va
orientada desde la subclase a la superclase.
Interacción de Clases
Relación de Herencia
Interacción de Clases
Clase abstracta

• Una clase abstracta tiene métodos sin definición completa(métodos

abstractos)
• Usadas como superclases para jerarquía de herencia
• Una clase abstracta no se instancia
Interacción de Clases
Clase abstracta
• Se representa con el nombre de la clase y los métodos abstractos en
letra itálica
• Es común también ubicar la palabra abstracta bajo el nombre de la
clase
Interacción de Clases
Clase abstracta

https://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/index.html
Interacción de Clases
Interface
• Establece la forma que debe tener una clase (modelo o esqueleto)
• Tiene métodos abstractos, constantes y métodos por defecto.
• No es una clase. No puede ser instanciada.
• En una interfaz todos los métodos son públicos y abstract (no es
necesario especificar).
Interacción de Clases
Interface
• Es común ubicar la palabra
<interfaz> bajo el nombre
• Las clases que implementan la
interfaz apuntan a la misma
con una flecha, cuya punta es
un triángulo vacío y la línea
entrecortada
Interacción de Clases
Tipo Enum
• Un tipo enumerado restringe los
posibles valores que puede tomar
una variable
• Se representa mediante un
rectángulo de dos secciones. En la
sección superior va el nombre
acompañado de la palabra <Enum>.
En la sección inferior se ubican los
posibles valores.
Taller en clase
Desarrollando un Diagrama de Clases
Diagrama de clases

Identificar Identificar las

Identificar clases Identifica atributos responsabilidades relaciones entre
candidatas de cada clase
de la clase las clases
1. Identificar Clases Candidatas
Estrategias para Identificar clases conceptuales

1. Identificar sustantivos en la descripción del dominio o en los casos

de usos.
2. Usar una lista con categorías de objetos presentes en la mayoría de
sistema.
3. Eliminar clases redundantes o ambiguas.
1. Identificar Clases Candidatas
• Identificamos clases candidatas mediante el análisis de sustantivos y
frases en la descripción de los requerimientos del sistema y los
casos de usos
• Sustantivos que indiquen:
• Entidades físicas
• Individuos, roles, grupos, organizaciones
• Gestión de cosas reales, Registro datos, Rastreo datos,
• Personas, dispositivos o sistemas que interactúan con el producto.
1. Identificar Clases Candidatas
• Filtrando sustantivos
• Eliminar sustantivos que señalan propiedades porque ellas pueden llegar a
ser atributos.
• Remover frases identificando comportamiento porque ellas pueden llegar a
ser operaciones.
• Combinar diferentes nombres que represan la misma idea.
1. Identificar Clases Candidatas
• Clases que deben eliminarse:
• Clase redundantes: Si dos clases expresan la misma información, el nombre
más descriptivo debe mantenerse. Ej: En un sistema para un aeropuerto, se
elige: pasajero en lugar de cliente.
• Clases irrelevantes: Si una clase tiene poco o nada que ver con el
problema. Clases que no directamente interactúan con el sistema.
• Clases ambiguas: Una clase debe ser específica. Algunas clases pueden
tener límites no muy bien definidos o muy grandes.
• Construcciones de Implementación: aspectos de implementación no
deben estar dentro del modelo de análisis.
2. Identificar los atributos de las clases
• Buscar adjetivo y modificadores de los sustantivos.
• Usar nombre provenientes del dominio del problema
• Incluir solo aquellos tipos y multiplicidad indicadas en la descripción
del problema.
• No añadir atributos de la implementación.
3. Identificar responsabilidades de las clases
• Responsabilidades: Lo que una instancia de una clase debe ser
capaz de hacer o conocer.
• Responsabilidades de un objeto incluye:
• Crear un objeto o hacer un cálculo.
• Iniciar una acción en otro objeto.
• Controlar y coordinar actividades en otros objetos.
4. Identificar relaciones entre las clases
• Estrategias para identificar la relaciones entre objetos:
• Buscar por verbos y preposiciones describiendo la relación entre las
entidades del modelo.
• Buscar relaciones tales como:
• Proximidad o física o organizacional
• Control, coordinación o influencia
• Creación, destrucción o modificación
• Comunicación.
• Pertenencia o Contención.

• Usar una lista de relaciones comunes entre los entidades de un sistema

4. Identificar relaciones entre las clases
4. Identificar relaciones entre las clases
4. Identificar relaciones entre las clases
• Trate de limitar el número de asociaciones a máximo 2 entre
cualquier par de clases.
• Combinar diferentes nombres para la misma asociación.
• Hacer nombre de las asociaciones precisos y descriptivos.
4. Identificar relaciones entre las clases
• Añadiendo multiplicidad:
• Tomar pares de entidades asociados:
• Haz una clase el objetivo y la otra la fuente.
• Determina cuantas instancias de la clase objetivo pueden estar relacionadas a una
sola clase de la clase fuente
• Invierta el objetivo y la fuente para determinar la multiplicidad de la otra.
• Añadir solo multiplicidad importantes en el sistema.
Clases Conceptuales Especializadas
• Añade especificación o descripción a otras clases cuando:
• Hay necesidad de tener una descripción del ítem o servicio independiente
de la existencia actual de cualquier ejemplo de estos ítems o servicios
• Tenemos información redundante o ducplicada.

• La clase ProductSpecification no representa un item, este representa una

descripción de información acerca del ítem.
Ejercicio 1
• Una biblioteca tiene varios libros. Cada libro se caracteriza por su
nombre, tipo (novela, teatro, poesía, ensayo), editorial, año y autor.
De un ejemplar pueden haber una o varias copias. Los autores se
caracterizan por su nombre, nacionalidad y fecha de nacimiento.
Cada copia tiene un identificador, y puede estar en la biblioteca,
prestada, con retraso o en reparación. Los lectores pueden tener un
máximo de 3 libros en préstamo. Cada libro se presta por un
máximo de 30 días, por cada día de retraso en entregar el libro se
impondrá una “multa” de dos días sin posibilidad de coger un
nuevo libro.
• Realice un diagrama de clases y añada los métodos necesarios
para realizar el préstamo y devolución de libros.
Ejercicio 1
• Una biblioteca tiene varios libros. Cada libro se caracteriza por su
nombre, tipo (novela, teatro, poesía, ensayo), editorial, año y autor.
De un ejemplar pueden haber una o varias copias. Los autores se
caracterizan por su nombre, nacionalidad y fecha de nacimiento.
Cada copia tiene un identificador, y puede estar en la biblioteca,
prestada, con retraso o en reparación. Los lectores pueden tener un
máximo de 3 libros en préstamo. Cada libro se presta por un
máximo de 30 días, por cada día de retraso en entregar el libro se
impondrá una “multa” de dos días sin posibilidad de coger un
nuevo libro.
• Realice un diagrama de clases y añada los métodos necesarios
para realizar el préstamo y devolución de libros.
Identificación de clases candidatas,
atributos y relaciones
• Sustantivos
• Biblioteca, libro, copia libro, lector, autor ,préstamo, multa
• Sustantivos denotan propiedades o características
• libro caracterizado por nombre, tipo, editorial, año, autor
• copia tiene identificador, estado.
• autores caracterizan por nombre, nacionalidad y fecha nacimiento.
• Verbos
• autor presta copia libro
• autor devuelve copia libro
• biblioteca contiene copia libro (asociación)
Análisis Ejercicio 1
• Por qué necesitamos la clase libro y copia?
• Para evitar duplicación de información, si no creamos una clase copia, cada
instancia de un mismo libro tendría repetido información del título,
autores, etc
Ejercicio 1