Conceptos básicos de la

orientación a objetos (POO)

Ingeniería de Software – Fase II
Por:
Mónica Penagos Martínez
Instructora
Coordinación UTI
 Contenido Programático
TEMA 4: CONCEPTOS BÁSICOS DE LA ORIENTACIÓN A OBJETOS
TEMA 1: ANÁLISIS Y VALIDACIÓN DE REQUISITOS Arquitectura del Sistema.
TEMA 2: HERRAMIENTAS CASE ✔ Modelado Estructural
TEMA 3: INTRODUCCION AL MODELADO Y DISEÑO ESTRUCTURADO ⮚ Clases.
Diagramas de Flujo de Datos ⮚ Relaciones.
Diccionario de Datos ⮚ Interfaces y Paquetes.
Especificación de procesos ✔ Modelado Del Comportamiento
Diagrama Entidad-relación ⮚ Interacción (Secuencia y Comunicación).
  ⮚ Estados.
⮚ Actividades.
✔ MODELADO ARQUITECTÓNICO
⮚ Componentes.
TEMA 5: ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS
Modelado Estructurado
Ingeniería de Software – Fase II
D
IA
G
R
A
M
A
S
-U
M
L
Diagrama de clases
 DIAGRAMA DE CLASES
Se utilizan para modelar la visión estática de un sistema. Esta visión soporta los requisitos
funcionales del sistema, en concreto, los servicios que el sistema debería proporcionar a sus
usuarios finales.

Normalmente contienen:
✔ Clases,
✔ Interfaces
✔ Relaciones (Asociación, Dependencia y/o de Generalización).
✔ Notas explicativas
 DIAGRAMA DE CLASES
Las clases describen un conjunto de objetos con
características y comportamiento idénticos, es decir, objetos
que comparten los mismos atributos, operaciones (métodos)
y relaciones.
Objeto
Es cualquier cosa, real o abstracta, acerca
de la cual almacenamos datos y los
métodos que controlan a los propios
datos.

Método
Especifican la forma en que se
controlan los datos de un objeto.
 Atributos: características
propias de los objetos de
una clase

Elementos del diagrama Nombre

Las clases se representan gráficamente por medio de

un rectángulo con tres divisiones internas. Los tres
compartimentos alojan el nombre de la clase, sus
atributos y sus operaciones (métodos),
respectivamente. En muchos diagramas se omiten
los dos compartimentos inferiores. Incluso cuando
están presentes, no muestran todos los atributos y
todas las operaciones.
Métodos: Operaciones
describen el
comportamiento de los
objetos de una clase
(Acciones)
 Atributos
Describen las características propias de los objetos de una

Sintaxis: Estudiante
Visibilidad nombre : tipo +Identificación: Int
+Nombre: String
+Apellido: String
La visibilidad puede ser: +Edad: Int
+Dirección: String
⮚ + (pública): hace que el atributo sea visible a todas las clases. +Teléfono: Int
+Grado: Int
⮚ - (privada): hace que el atributo sea visible sólo para la clase.
⮚ # (protegida): hace que el atributo sea visible a las subclases de la
clase.
 Métodos

Funciones que el objeto va a realizar, también Estudiante

llamadas Operaciones. Atributos

Sintaxis: +Constructor(Atributos: tipos)

+GetGrado(): int
Visibilidad nombre(parámetros): tipo de retorno +SetGrado(Grado:int): void
EL DIAGRAMA DE CLASES UML SE COMPONE DE:

1) Clases: Corresponde a los atributos y funciones que están involucrados para realizar

operaciones con los datos.
2) Conexiones: Corresponde a la relación entre clases y el tipo de relación.
⮚ Herencia, Propiedad que tienen las clases de heredar de sus superclases estructura
y/o comportamiento (Simple / Múltiple).
⮚ Constructores, método especial que permite inicializar los atributos del objeto.
Es el primero que se ejecuta.
 Tipos de Relaciones
Relación Descripción
Representan relaciones estructurales entre las clases (Pueden
ser bidireccional (Se lee “tiene un”)/unidireccional “Flecha
Asociaciones abierta/verbo”), Navegabilidad, Roles,
Multiplicidad(Cardinalidad).
Es una relación en la que una de las clases representa un todo
Agregación y la otra representa parte de ese todo.

Es una forma más fuerte de la agregación, en la que el todo

Composición
no puede existir sin sus partes.
Relación en la que una clase necesita (requiere) a otra para
Dependencia
poder funcionar.
Cuando una entidad general se puede particularizar en otras
Generalización
entidades.
 Relación de asociación
Multiplicidad (Cardinalidad):
Cuando se establece una multiplicidad al final de la línea de una
asociación, indica que para cada objeto de la clase en el lado opuesto
existen varios objetos en el otro extremo.

Ejemplo:
Se muestran los dos tipos de navegación, una
asociación entre las clases Persona y Coche.
En el primer caso un coche puede tener uno o más
propietarios y una persona es propietaria de cero o más
coches.
Mientras que en el segundo caso la asociación
navegable nos dice que una persona puede poseer cero
o varios coches, pero no nos informa sobre cuántas
personas son propietarias de un coche.
 Relación de agregación
Una agregación normal se denota dibujando una línea con un rombo sin rellenar al final de la misma del lado del todo
(del lado de la clase que contiene a la otra clase).

Ejemplo:
La flota contiene muchos barcos de guerra. Algunos barcos
pueden ser eliminados y todavía es una flota. Lo mismo
ocurre si se añaden barcos, pues sigue siendo una flota. Las
partes (los barcos de guerra) componen el todo (flota). El
rombo sin rellenar en el lado del todo, junto con la
multiplicidad 1, nos indica que se trata de una agregación
normal.
 Agregación compartida
Es aquella en la que las partes pueden ser partes en varios todos. Se representa de la misma forma que una
agregación normal. Para que una agregación se considere compartida es necesario que la multiplicidad en el lado del
todo sea superior a uno
Ejemplo: Cardinalidad >1
Un remix (mezcla de sonidos) está compuesto de varias
bandas sonoras; la misma banda sonora podría formar parte
de varias mezclas musicales. Se diferencia de la agregación
normal en que la multiplicidad en el lado del todo es superior
a 1. Los objetos tanto de la clase Remix como de la clase
Banda Sonora se encuentran ordenados, lo cual está indicado
por la restricción {ordenado}.
 Agregación de composición
Se denota dibujando una línea con un rombo relleno al final de la misma del lado del todo (del lado de la clase que
contiene a la otra clase). La multiplicidad en el lado del todo puede ser uno (1) ó cero-a uno (0..1), pero la
multiplicidad en el lado de la parte puede ser cualquier intervalo. Se trata de una relación de pertenencia muy fuerte.

Ejemplo: Cardinalidad (1) o cero-a

La ventana contiene muchos textos, cajas de listado de uno (0..1),

elementos, botones y menús. El tiempo de vida de las

partes coincide con la clase del todo, en este caso, la
clase Ventana. El rombo relleno en el lado del todo,
junto con la multiplicidad 0..1 o 1, nos indica que se
trata de una agregación de composición.
 Dependencia
La relación de dependencia se representa por una línea discontinua con una flecha en el lado del elemento
independiente.

Ejemplo:
Nos muestra un conjunto de cuatro clases junto con sus asociaciones y sus
dependencias, correspondientes a una parte de un sistema que gestiona la
asignación de profesores a los cursos en una universidad.

En el ejemplo hay una dependencia normal de la clase Planificación del

Curso respecto a la clase Curso, pues Curso se utiliza como parámetro en
las operaciones Añadir y Eliminar de Planificación del Curso.

Si proporcionamos la lista de parámetros en las operaciones, tal como se

puede observar en el ejemplo, entonces no es necesario mostrar la
dependencia, pues la utilización de la clase Curso ya figura de forma
explícita en la clase Planificación del Curso. Sin embargo, a veces
queremos que esta dependencia se dibuje, especialmente si hemos omitido
la lista de parámetros en las operaciones.
 Generalización (herencia)
La generalización normal es una relación de herencia entre clases, entre una general y otra específica. La clase
específica, llamada subclase, hereda todo de la clase general, llamada superclase. Se representa por una línea
continua desde la clase más específica (subclase) hasta la clase más general (superclase), con un triángulo sin
rellenar al final de la línea en la superclase.

Ejemplo:
Nos muestra un conjunto de cuatro clases junto con sus asociaciones
y dependencias, referidas a tipos de vehículos. En nuestro ejemplo la
clase Vehículo muestra las cosas comunes entre coches y barcos,
incluyendo la relación de asociación a la clase Persona. Se trata de
una clase abstracta que no tiene objetos, mientras que las clases
Coche y Barco son concretas. Estas subclases heredan el atributo
color y la operación Conducir de la superclase Vehículo. Dicha
operación está redefinida en las clases Coche y Barco, ya que no está
implementada en la clase Vehículo al aparecer junto a la operación la
palabra {abstracta} y además su implementación es diferente
dependiendo del tipo de objeto: coche o barco.
Generalización (herencia)

La clase Persona tiene una asociación, llamada conduce, hacia la clase

Vehículo. La clase Vehículo es abstracta; lo que significa que los objetos
actuales que la persona conduce se obtienen a partir de las subclases
concretas Coche y Barco. Cuando la persona ejecuta la operación
Conducir, el resultado depende de si el objeto usado en dicha situación
es un coche o un barco. Si es un objeto de la clase Coche, se pondrán en
marcha las ruedas (utilizando la implementación especificada en la clase
Coche). Si es un objeto de la clase Barco, se pondrá en marcha la hélice
(utilizando la implementación especificada en la clase Barco). Esta
técnica, donde un objeto de una subclase actúa según un objeto de una
superclase y una o más operaciones en la superclase son redefinidas en
la subclase, se llama polimorfismo.
 Como elaborar un Diagrama de Clases

Unos pasos que puedes utilizar de guía para construir estos diagramas son los siguientes:
1. Identifica los nombres de las clase. (Identificar los objetos primarios del sistema. Las clases suelen corresponder
a sustantivos dentro del dominio del problema).
2. Distingue las relaciones. (Determinar cómo cada una de las clases u objetos están relacionados entre sí. Busca
los puntos en común).
3. Crea la estructura. (Primero, agrega los nombres de clase y vincúlalos con los conectores apropiados, prestando
especial atención a la cardinalidad o las herencias. Deja los atributos y funciones para más tarde, una vez que esté
la estructura del diagrama resuelta).
 Ejemplos de relaciones

El diagrama de clases UML es implementado durante la fase de

análisis y diseño.
 Interfaces

Una interfaz es una entidad que declara una serie de atributos,

funciones y obligaciones. Es una especie de contrato donde toda
instancia asociada a una interfaz debe de implementar los
servicios que indica aquella interfaz. as interfaces se asocian a
clases. Una asociación entre una clase y una interfaz representa
que esa clase cumple con el contrato que indica la interfaz, es
decir, incluye aquellas funciones y atributos que indica la
interfaz. Su representación es similar a las clases, pero indicando
arriba la palabra <<interface>>.
Ejemplos diagramas de clases
Diagrama de Clases - Clínica Veterinaria
Ejemplos diagramas de clases
Diagrama de clases gestión de biblioteca
Diagrama de Paquetes
 Diagrama de Paquetes
Es uno de los diagramas estructurales, representa de forma
Paquet estática los componentes del sistema de información que está
siendo modelado. Es utilizado para definir los distintos
e
Dependenci paquetes a nivel lógico que forman parte de la aplicación y la
a dependencia entre ellos.

El objetivo principal del diseño debe maximizar la cohesión y

minimizar el acoplamiento.
 Diagrama de Paquetes

Este diagrama, típico de arquitecturas de aplicaciones en tres capas tiene 3 paquetes: Capa de Lógica
de Negocio, Capa de Presentación y la Base de datos. Estos dos últimos paquetes (presentación y
bbdd) dependen para su funcionamiento de la lógica de negocio.
 Ejemplo de un diagrama de paquetes
La aplicación, que tiene como finalidad la recepción y
gestión de quejas y sugerencias, estaría compuesta por los
siguientes paquetes:
1. Capa de presentación. Incluye a su vez los paquetes
Interfaz de Usuario e Interfaz Admin
2. Capa de Lógica de Negocio, con los siguientes
paquetes:
1. Subsistema de recepción de dudas y
sugerencias.
2. Subsistema de asignación de responsable.
3. Subsistema de creación de informes.
4. Gestor documental.
5. Subsistema de gestión de usuarios.
6. Envío de notificaciones.
3. Base de datos.
•CRM.
•DataWarehouse.