SlideShare una empresa de Scribd logo
1 de 67
Por favor silenciar
micrófono y apagar
la cámara.
En Minutos daremos
inicio a la
conferencia.
BIENVENIDOS
CENTRO DE SERVICIOS Y GESTIÓN EMPRESARIAL – CESGE
Regional Antioquia
Instructores: Delia Herazo – Edinson Martinez
06/03/2024
Hora: 6:30 pm
Tecnólogo en Análisis y Desarrollo de Software
Fichas: 2781769 – 2764732 - 2758331
1. Saludo
2. Evidencias a orientar:
❑ Evidencias de Producto: Diagrama de Clases del proyecto de
software. GA4-220501095-AA2-EV04
3. Dudas e inquietudes
Tomado
de
:
https://goo.gl/R3b
UP7
Conferencia
220501095 - Diseñar la solución de software de acuerdo
con procedimientos y requisitos técnicos.
COMPETENCIA
Actividad de aprendizaje: GA4-220501095-AA2. Elabora
artefactos usando el paradigma de programación
orientada a objetos.
Resultado de aprendizaje: 220501095-01. Elaborar los
artefactos de diseño del software siguiendo las prácticas
de la metodología seleccionada.
INTRODUCCIÓN
• Los problemas suelen tener varias soluciones posibles.
• En programación existen diversas metodologías que nos ayudan
a enfrentar un problema.
• Cada metodología tiene diversos lenguajes que las soportan.
• Algunos lenguajes soportan varias metodologías.
Metodología Lenguaje
Estructurada Fortran, C, Pascal, Basic
Orientada a objetos (OOP) C++, Java, Smalltalk
Orientada a eventos VisualBasic
Programación Orientada a Objetos
Definición:
La Programación Orientada a Objetos (OOP) es un método de programación en
el cual los programas se organizan en colecciones cooperativas de objetos, cada
uno de los cuales representa una instancia de alguna clase, y cuyas clases son,
todas ellas, miembros de una jerarquía de clases unidas mediante relaciones de
herencia.
Comentarios:
• Usamos objetos en lugar de algoritmos como bloque fundamental
• Cada objeto es una instancia de una clase
• Las clases están relacionadas entre sí por relaciones tan complejas como la herencia
Objeto y Clase
Un objeto es algo de lo que
hablamos y que podemos
manipular.
• Existen en el mundo real (o en
nuestro entendimiento del
mismo)
Una clase describe los objetos del
mismo tipo
• Todos los objetos son instancias
de una clase
• Describe las propiedades y el
comportamiento de un tipo de
objetos
Clase
Atributo
s
Operaciones
Objeto:Clase
Atributo1=valo
r
Atributo2=valo
r
...
El diagrama de clases es el tipo de diagrama más útil
en UML, ya que traza claramente la estructura de un
sistema concreto al modelar.
Para esta evidencia elaboramos un diagrama de clases
de acuerdo con los requisitos, aplicando buenas
prácticas de diseño orientado a objetos.
DESCRIPCIÓN DE LA ACTIVIDAD
• Estudiar el componente formativo “Diseño del modelo
conceptual bajo el paradigma orientado a objetos”.
• Diagrama de clases del proyecto de software.
• Aplicar buenas prácticas de diseño orientado a objetos.
• Utilizar una herramienta tic para hacer diagramas.
• Se deben seguir las normas básicas de presentación de un
documento escrito, es decir el documento debe tener
como mínimo una portada, introducción y conclusiones.
DESCRIPCIÓN DE LA ACTIVIDAD 2
QUÉ ES DIAGRAMAS DE CLASES
Un Diagrama de Clases en Lenguaje
Unificado de Modelado (UML) es un tipo de
diagrama de estructura estática que
describe la estructura de un sistema
mostrando las clases del sistema, sus
atributos, operaciones (o métodos), y las
relaciones entre los objetos.
CARACTERÍSTICAS BÁSICAS DE LOS
DIAGRAMAS DE CLASES
Vamos a explicarlo a través de un
ejemplo: Digamos que estamos
creando un sistema para un
Zoológico. Vamos a representar
cada una de las cosas que están
en el sistema a través de clases.
Para comenzar a dibujar clases,
se pincha en el cuadro de clase
(el primero de la paleta), y se
marca algún punto del área de
dibujo. La clase aparecerá, con el
nombre genérico de "clase".
TIPOS DE DIAGRAMAS
• Diagramas de estructura: mostrar la estructura estática del sistema
que se está modelando
• Incluye: diagramas de clase, componentes y/o objetos.
• Diagramas de comportamiento: muestra el comportamiento
dinámico entre los objetos y el sistema.
• Incluye: diagramas de actividades, casos de uso y de secuencia
Diagrama de clase
• Es el más utilizado y más conocido de los diagramas orientados a
objetos. Es la fuente de generación de código.
• El diagrama de clase representa clases, sus partes y la forma en la
que las clases de los objetos están relacionados con otro.
• Una clase es una definición de un tipo de objeto.
Partes del diagrama de clases
• Atributos: describe las características de una clase de objetos.
• Operaciones: define el comportamiento de una clase de objetos
• Estereotipos: ayuda a entender este tipo de objeto en el contexto de otras
clases de objetos con roles similares dentro del diseño del sistema.
• Asociación: es un término formal para un tipo de relación.
• Herencia: permite organizar las definiciones de la clase para simplificar y
facilitar su implementación.
Clases
• Las clases son descripciones de un juego de objetos con características,
comportamiento, relaciones y semánticas comunes. Se usan para modelar un
juego de conceptos o entidades.
• Se denotan con un rectángulo con compartimentos.
• En ellos se ponen el nombre, los atributos, las operaciones y además se pueden usar para
anotar otras propiedades del modelo como son (reglas del negocio, responsabilidades,
excepciones, etc.)
• Pueden tener interfaces para especificar conjuntos de operaciones proporcionadas a su
ambiente. Todas las operaciones deben estar asociadas a métodos.
• Pueden tener relaciones de generalización con otras clases.
Atributos
• Son descripciones de características, se usan para modelar
información asociada con una entidad, sintaxis:
Nombre_atributo[multiplicidad]:Tipo = Valor_inicial
• La multiplicidad es opcional e indica el número de atributos por
instancia de la clase.
Operaciones
• Son descripciones del comportamiento, se usan para modelar los
servicios u operaciones asociados con una entidad, esto es, lo que
una entidad puede hacer, sintaxis:
Nombre_operación[parámetros:tipo]:Valor_retorno:tipo
Interfaces
• Son clases que definen un juego de operaciones externas accesibles
pero sin métodos. Se usan para modelar una serie de operaciones
que definen un servicio que puede ser ofrecido por diferentes
clases.
• Se representan como clases pero con el estereotipo <<interface>>.
• Solo contienen operaciones públicas
Todos los diagramas soportan el Diagrama de
Clase
Diagrama
de Clase
Diagrama
de Estados
Diagrama
de Colaboración
Diagrama
de Secuencia
Diagrama
de Objetos
Diagrama
de Actividades
Casos de
Uso
Diagrama de Objetos
• La clase define las reglas; los objetos expresan los hechos.
• La clase define que puede ser; el objeto describe que es.
• Se considera un caso especial del diagrama de clases.
• Puede construirse junto con el de clases.
• Describe una instancia de un diagrama de clase en un momento en
particular.
• Este diagrama contiene objetos y ligas.
Modelando Clases
• La representación de una clase es un rectángulo con 3 divisiones:
• El del nombre define la clase, (un tipo de objeto).
• El de los atributos contiene la definición de los datos.
• El de las operaciones contiene la definición de cada comportamiento
soportado por este tipo de objeto.
Ejemplo
La siguiente figura muestra un vuelo de una aerolínea
modelado como una clase UML.
Nombre
Atributos
Operaciones
Atributo: tipo de dato
Operación(parámetros:
Tipo de dato):valor de
retorno
Modelando un atributo
• Un atributo describe una pieza de información que un objeto tiene
o conoce de sí mismo. Para poder usar esta información se debe
asignar un nombre y especificar el tipo de dato.
• El tipo de dato puede ser primitivo o tipo de dato abstracto
(definido)
• Cada atributo puede tener reglas que limiten los valores asignados a
éste. Se puede usar un valor de default para protegerlo.
Visibilidad de un atributo
• La definición de un atributo debe especificar que otros objetos los
pueden ver. La visibilidad puede ser:
• Public (+) permite el acceso a objetos de las otras clases.
• Private (-) limita el acceso a la clase, solo operaciones de la clase tienen
acceso.
• Protected (#) permite el acceso a subclases. En el caso de generalización
(herencia), las subclases deben tener acceso a los atributos y operaciones
de la superclase, sino no pueden heredar.
• Package (~) permite el acceso a los otros objetos en el mismo paquete.
Ejemplo Especificación de un atributo
Elemento Ejemplo
Nombre del atributo compañía
Tipo de dato compañía:character
Valor de default (si hay) compañía:character = espacios
Restricciones compañía:character = espacios
{1 a 30}
Caracteres compañía:character = espacios{1
a 30 alfabéticos, espacios,
puntuación, no especiales}
Visibilidad - compañía:character = espacios
{1 a 30 alfabéticos, …….
Modelando una Operación
• Los objetos tienen comportamientos, cosas que puedan hacer y que
se les puedan dar a éstos.
• Las operaciones requieren un nombre, argumentos y a veces un
valor de retorno.
• Las reglas de privacidad se aplican en la misma forma que para los
atributos: Private, Public, Protected y Package.
Ejemplo Especificación de una operación
Elemento Ejemplo
Nombre totalOrderAmount
Definir argumentos/
Parámetros, corresponden
a una instancia de Order
totalOrderAmount (order:
integer)
Definir el tipo de dato de
retorno
totalOrderAmount (order:
integer) : Dollar
Identificar y describir
restricciones
totalOrderAmount (order:
integer) : {El total es la suma
de cada item (p.u. x cantidad)
Visibilidad + totalOrderAmount (order:
integer) : {El total es la suma ….
Diagrama de Clases: Asociaciones
• El propósito de la asociación puede expresarse en un nombre, verbo
o frase que describa como los objetos de un tipo (clase) se
relacionan con objetos de otro tipo (clase). Por ejemplo:
Una persona tiene un coche
Una persona maneja un coche
• Multiplicidad: cuantos objetos van a participar en la relación
Asociaciones
Se indica el rol y la multiplicidad.
Un vuelo está asociado con un avión y un avión
puede tener asociados ninguno ó varios números
de vuelo.
Dirección
• La dirección en las flechas de la asociación determinan en que
dirección puede recorrerse una asociación en el momento de la
ejecución.
• Una asociación sin flechas significa que se puede ir de un objeto a
otro y viceversa.
• Por ejemplo la siguiente el tipo de flecha en la asociación implica
que desde el objeto Reservación puedes recuperar (dirigirte hacia)
el objeto Cliente. También implica que del objeto Cliente puedes
recuperar el juego de reservaciones para ese cliente.
1….* hecha para 1
Reservación Cliente
1….* hecha para 1
Reservación Cuarto
Supongamos que los requerimientos para un sistema de reservaciones
requieren que “desde una reservación, que el sistema pueda
recuperar el cuarto
Clase Asociación
• Cuando se modela una asociación entre clases, a veces es necesario
incluir otra clase que contiene información valiosa acerca de la
relación.
• Se representa como una clase normal solo que la línea que la une
con la línea que conecta las asociaciones primarias es punteada.
• La siguiente figura muestra una clase asociación para el ejemplo de
los vuelos.
La asociación entre la clase Flight y FrequentFlyer es a través de una clase
llamada MileageCredit. Esto significa que debe haber una instancia en esta
clase cuando alguna instancia de la clase Flight se asocie con una instancia
de la clase FrequentFlyer
Pasos para el diagrama de clases
• Identificar las clases.
• Mostrar los atributos y operaciones (posteriormente)
• Dibujar asociaciones
• Etiquetar asociaciones y en caso necesario los roles
• Indicar multiplicidad
• Dibujar fechas de dirección
Asociación Reflexiva
• Una clase puede asociarse con sí misma. Una clase Empleado puede
relacionarse con sí misma a través del rol gerente/dirige.
• No significa que una instancia está relacionada consigo misma, sino
que una instancia de la clase está relacionada con otra instancia de
la misma clase.
Una instancia de Employee puede ser el gerente de otras instancias de
Employee. Como el rol manages tiene una multiplicidad de 0…*,
significa que puede no tener otros empleados a quien dirigir.
Una instancia de Employee tiene 1 sólo gerente ó un solo director.
Asociación Cualificada
• Un cualificador es un atributo de la clase en el lado opuesto de la
asociación, que permite hacer una búsqueda en función a su valor.
Por ejemplo “El cliente usa el numOrden para buscar una orden”.
• Un tipo de objeto usa el cualificador para accesar el otro tipo de
objeto.
cliente orden
numOrden:int
Diagrama de Clase: Agregación y Composición
• Cada agregación es un tipo de asociación.
• Cada composición es una forma de agregación.
Asociación
Agregación
Composción
AGREGACIÓN BASICA
• Es un tipo especial de asociación utilizado para modelar una
relación “whole to its parts”.
• Por ejemplo, Coche es una entidad “whole” y Llanta es una parte
del Coche.
• Una asociación con una agregación indica que una clase es parte de
otra clase.
• En este tipo de asociación, la clase hijo puede sobrevivir sin su clase
padre.
Para representar una relación de agregación, se dibuja una línea
sólida de la clase padre (total) a la clase hijo (parte), y con un
diamante en el lado de la clase padre.
Una llanta puede existir sin automóvil
AGREGACIÓN/COMPOSICIÓN
• En este caso el ciclo de vida de una instancia de la
clase hijo depende del ciclo de vida de una instancia
de la clase padre.
• A diferencia de la agregación básica, para
representarla el diamante no es hueco.
• Una instancia de la clase Company debe tener al
menos una en la clase Departamento.
• En este tipo de relaciones, si una la instancia
Company se elimina, automáticamente la instancia
Departamento también se elimina.
• Otra característica importante es que la clase hijo
solo puede relacionarse con una instancia de la
clase padre.
Generalización
• Son asociaciones entre elementos más generales y elementos más específicos,
en los cuales éstos últimos son consistentes totalmente con los primeros, por lo
que heredan las características proporcionadas por lo elementos generales y
además pueden aumentar información.
• Este tipo de relación también se conoce como herencia.
• En una generalización no hay multiplicidad ni roles. Una (Asociación define las
reglas de cómo los objetos se pueden relacionar entre ellos.)
• La visibilidad “protected” permite que solo objetos de la misma clase ó
subclase vean el elemento.
Elementos de la generalización
• Para dibujarla, hay que definir:
• Superclase: es una clase que contiene alguna combinación de atributos,
operaciones y asociaciones que son comunes a dos o más tipos de objetos
que comparten el mismo propósito.
• Subclase: es una clase que contiene una combinación de atributos,
operaciones y asociaciones que son únicas a un tipo de objeto definido por
una superclase.
• La superclase es reutilizada por la subclase.
Herencia
Perro
Collie Boxer Dalmata
Paquetes
• Es un elemento organizador que proporciona UML
al dividir el sistema en paquetes lo hace más fácil de
entender.
Interfaces
• Una clase tiene una instancia de su tipo, mientras que una interface
debe tener al menos una clase para implantarla. En UML, una
interface es considerada como una especialización de una clase.
• Una interface se dibuja como una clase, pero en el compartimento
superior del rectángulo aparece un texto ó una inicial que indica
que se trata de una interface y no de una clase.
• Una interface no es una clase.
Ejemplo interface
En el diagrama anterior las clases Professor y Student implementan a
la interface Person y no heredan de ésta, podemos deducirlo a
partir de:
1) El objeto Person de acuerdo a la simbología del diagrama está
como una interface y Professor y Student están como clases.
2) No se trata de herencia ya que la línea con la flecha está punteada y
no sólida.
Instancias
• Cuando se modela la estructura de un sistema, a veces es útil
mostrar ejemplos de las instancias de las clases.
• UML proporciona el elemento instance especification, que muestra
información importante utilizando un ejemplo.
• La notación es la misma que la de una clase, solo que en el espacio
superior el nombre se forma con:
nombre de la instancia : nombre de la clase
• Además de mostrar las instancias es muy útil
mostrar sus relaciones, el ejemplo muestra dos
instancias de la clase Flight, ya que el diagrama de
clase indica que la relación entre la clase Plane y la
clase Fight es 0 a muchos:
Roles
• Se puede incluir el rol de las clases, el siguiente
ejemplo de los roles jugados por la clase Employee
(de la asociación reflexiva), mostramos que la
relación es entre un Employee jugando el papel de
gerente y un Employee jugando el rol de miembro
del equipo.
Diagrama de clase: Caso de estudio
• Establecimiento del problema: para el sistema de control de inventario:
“Nuestro sistema está diseñado para inventariar y embarcar únicamente productos
identificados. Estos productos pueden ser comprados directamente de
proveedores y revenderlos, o podemos empacarlos juntos para crear un
producto especial. Los clientes colocan órdenes para uno ó más ítems pero
nosotros detectamos en el sistema clientes que hayan o no hayan comprado.
Cada ítem corresponde a un producto. Identificamos cada producto usando un
número serial único. El cliente puede preguntar sobre el estatus de su orden
utilizando el número de orden.
Los embarques de productos de los proveedores se reciben y se colocan en el
inventario. Cada producto es asignado a una ubicación con lo que se puede
encontrar fácilmente cuando se surten las órdenes. Cada ubicación tiene un
identificador único. Las órdenes para los clientes se embarcan a medida que los
productos están disponibles, por lo que puede haber más de un envío para
satisfacer una sola orden de compra, pero puede ser que un solo embarque
contenga productos de múltiples órdenes. Los ítems que no se entregaron son
colocados en una backorder con una referencia a la orden original”.
Construyendo el diagrama de clase
1. Identificar las clases, nombrarlas y definirlas con lo que sabes que
son parte del modelo.
2. Identificar, nombrar y definir las asociaciones entre pares de
clases. Tener cuidado con clases reflexivas, asignar multiplicidad.
3. Evaluar cada asociación para determinar si debe ser una
agregación y cada agregación para ver si debe ser una composición
4. Evaluar las clases para posible generalización (herencia).
EJEMPLOS DE DIAGRAMAS
DE CLASES
Clínica
Veterinaria
Zoológico
Una Tienda
Biblioteca
Centro
Educativ
o
EJERCICIO EN CLASE
Ejemplo de clases para un diagrama de clases de una tienda web.
En este ejercicio, se plantean algunas clases con sus atributos que
podrías incluir en el diagrama de clases de una tienda online:
Usuario:
idUsuario: Identificador único del usuario.
nombre: Nombre completo del usuario.
email: Dirección de correo electrónico del usuario.
contraseña: Contraseña del usuario.
dirección: Dirección de envío del usuario.
métodoDePago: Método de pago preferido por el usuario.
EJERCICIO EN CLASE
Producto:
idProducto: Identificador único del producto.
nombre: Nombre del producto.
descripción: Descripción detallada del producto.
precio: Precio del producto.
stock: Cantidad de unidades disponibles en el inventario.
Carrito de Compras:
idCarrito: Identificador único del carrito de compras.
productos: Lista de productos que el usuario ha añadido al carrito.
subtotal: Monto total del carrito antes de aplicar impuestos y descuentos.
impuestos: Monto total de impuestos aplicados al carrito.
EJERCICIO EN CLASE
Orden de compra:
idOrden: Identificador único de la orden de compra.
productos: Lista de productos comprados en la orden.
subtotal: Monto total de la orden antes de aplicar impuestos y descuentos.
impuestos: Monto total de impuestos aplicados a la orden.
envío: Monto del costo de envío de la orden.
total: Monto total de la orden incluyendo impuestos, descuentos y costo de
envío.
Categoría:
idCategoría: Identificador único de la categoría.
nombre: Nombre de la categoría.
Se desea construir un aplicativo de Gestión de factura conociendo lo siguiente:
Un cliente puede requerir varias facturas en un lapso de tiempo determinado
(una factura solo puede ser hecho por un cliente),
cada factura tiene un número de factura y la fecha de facturación y está conformado por varias
líneas de factura, cada línea de factura corresponde a un producto. Hay dos tipos de clientes:
El cliente normal tiene identificación, nombre, dirección,teléfono, sexo y el cliente empresarial
tiene
identificación nombre, dirección, teléfono, el cliente empresarial tiene contrato, cada
vendedor
se hace responsable de los clientes empresariales y cada cliente empresarial es atendido solo
por un cliente
Clases
Video explicativo de Diagrama de clases
https://youtu.be/nFvUZ2Q0CFY
Resumen Programación Orientada a Objetos 20_06_2023 (1).pptx

Más contenido relacionado

Similar a Resumen Programación Orientada a Objetos 20_06_2023 (1).pptx

Similar a Resumen Programación Orientada a Objetos 20_06_2023 (1).pptx (20)

Guía
GuíaGuía
Guía
 
Analisis y diseño de sistemas
Analisis y diseño de sistemasAnalisis y diseño de sistemas
Analisis y diseño de sistemas
 
Analisis Y Diseño De Sistemas Orientado A Objetos
Analisis Y Diseño De Sistemas Orientado A ObjetosAnalisis Y Diseño De Sistemas Orientado A Objetos
Analisis Y Diseño De Sistemas Orientado A Objetos
 
Analisis y diseño de sistemas
Analisis y diseño de sistemasAnalisis y diseño de sistemas
Analisis y diseño de sistemas
 
Patrones de programación y uml en java
Patrones de programación y uml en javaPatrones de programación y uml en java
Patrones de programación y uml en java
 
Programación Orientada a Objetos
Programación Orientada a ObjetosProgramación Orientada a Objetos
Programación Orientada a Objetos
 
programacion orientada a objetos
programacion orientada a objetosprogramacion orientada a objetos
programacion orientada a objetos
 
Implementacion informatica
Implementacion informaticaImplementacion informatica
Implementacion informatica
 
Primeraclaseobjetos clases
Primeraclaseobjetos clasesPrimeraclaseobjetos clases
Primeraclaseobjetos clases
 
Primeraclaseobjetos Clases
Primeraclaseobjetos ClasesPrimeraclaseobjetos Clases
Primeraclaseobjetos Clases
 
Primeraclaseobjetos Clases
Primeraclaseobjetos ClasesPrimeraclaseobjetos Clases
Primeraclaseobjetos Clases
 
Uml presentacion
Uml   presentacionUml   presentacion
Uml presentacion
 
PROGRAMACION ORIENTADA A OBJETO
PROGRAMACION ORIENTADA A OBJETOPROGRAMACION ORIENTADA A OBJETO
PROGRAMACION ORIENTADA A OBJETO
 
Diapositiva de Estudio: EXPOSICION UML.pptx
Diapositiva de Estudio: EXPOSICION UML.pptxDiapositiva de Estudio: EXPOSICION UML.pptx
Diapositiva de Estudio: EXPOSICION UML.pptx
 
2. lenguaje de modelado unificado uml
2. lenguaje de modelado unificado uml2. lenguaje de modelado unificado uml
2. lenguaje de modelado unificado uml
 
Manual de java_2
Manual de java_2Manual de java_2
Manual de java_2
 
manual 9
manual 9manual 9
manual 9
 
Manual de java 3
Manual de java 3Manual de java 3
Manual de java 3
 
MANUAL DE JAVA 2
MANUAL DE JAVA 2MANUAL DE JAVA 2
MANUAL DE JAVA 2
 
Manual de java 2
Manual de java 2Manual de java 2
Manual de java 2
 

Resumen Programación Orientada a Objetos 20_06_2023 (1).pptx

  • 1. Por favor silenciar micrófono y apagar la cámara. En Minutos daremos inicio a la conferencia. BIENVENIDOS
  • 2. CENTRO DE SERVICIOS Y GESTIÓN EMPRESARIAL – CESGE Regional Antioquia Instructores: Delia Herazo – Edinson Martinez 06/03/2024 Hora: 6:30 pm Tecnólogo en Análisis y Desarrollo de Software Fichas: 2781769 – 2764732 - 2758331
  • 3. 1. Saludo 2. Evidencias a orientar: ❑ Evidencias de Producto: Diagrama de Clases del proyecto de software. GA4-220501095-AA2-EV04 3. Dudas e inquietudes Tomado de : https://goo.gl/R3b UP7 Conferencia
  • 4. 220501095 - Diseñar la solución de software de acuerdo con procedimientos y requisitos técnicos. COMPETENCIA Actividad de aprendizaje: GA4-220501095-AA2. Elabora artefactos usando el paradigma de programación orientada a objetos. Resultado de aprendizaje: 220501095-01. Elaborar los artefactos de diseño del software siguiendo las prácticas de la metodología seleccionada.
  • 5. INTRODUCCIÓN • Los problemas suelen tener varias soluciones posibles. • En programación existen diversas metodologías que nos ayudan a enfrentar un problema. • Cada metodología tiene diversos lenguajes que las soportan. • Algunos lenguajes soportan varias metodologías. Metodología Lenguaje Estructurada Fortran, C, Pascal, Basic Orientada a objetos (OOP) C++, Java, Smalltalk Orientada a eventos VisualBasic
  • 6. Programación Orientada a Objetos Definición: La Programación Orientada a Objetos (OOP) es un método de programación en el cual los programas se organizan en colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son, todas ellas, miembros de una jerarquía de clases unidas mediante relaciones de herencia. Comentarios: • Usamos objetos en lugar de algoritmos como bloque fundamental • Cada objeto es una instancia de una clase • Las clases están relacionadas entre sí por relaciones tan complejas como la herencia
  • 7. Objeto y Clase Un objeto es algo de lo que hablamos y que podemos manipular. • Existen en el mundo real (o en nuestro entendimiento del mismo) Una clase describe los objetos del mismo tipo • Todos los objetos son instancias de una clase • Describe las propiedades y el comportamiento de un tipo de objetos Clase Atributo s Operaciones Objeto:Clase Atributo1=valo r Atributo2=valo r ...
  • 8. El diagrama de clases es el tipo de diagrama más útil en UML, ya que traza claramente la estructura de un sistema concreto al modelar. Para esta evidencia elaboramos un diagrama de clases de acuerdo con los requisitos, aplicando buenas prácticas de diseño orientado a objetos. DESCRIPCIÓN DE LA ACTIVIDAD
  • 9. • Estudiar el componente formativo “Diseño del modelo conceptual bajo el paradigma orientado a objetos”. • Diagrama de clases del proyecto de software. • Aplicar buenas prácticas de diseño orientado a objetos. • Utilizar una herramienta tic para hacer diagramas. • Se deben seguir las normas básicas de presentación de un documento escrito, es decir el documento debe tener como mínimo una portada, introducción y conclusiones. DESCRIPCIÓN DE LA ACTIVIDAD 2
  • 10. QUÉ ES DIAGRAMAS DE CLASES Un Diagrama de Clases en Lenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos.
  • 11. CARACTERÍSTICAS BÁSICAS DE LOS DIAGRAMAS DE CLASES Vamos a explicarlo a través de un ejemplo: Digamos que estamos creando un sistema para un Zoológico. Vamos a representar cada una de las cosas que están en el sistema a través de clases. Para comenzar a dibujar clases, se pincha en el cuadro de clase (el primero de la paleta), y se marca algún punto del área de dibujo. La clase aparecerá, con el nombre genérico de "clase".
  • 12. TIPOS DE DIAGRAMAS • Diagramas de estructura: mostrar la estructura estática del sistema que se está modelando • Incluye: diagramas de clase, componentes y/o objetos. • Diagramas de comportamiento: muestra el comportamiento dinámico entre los objetos y el sistema. • Incluye: diagramas de actividades, casos de uso y de secuencia
  • 13. Diagrama de clase • Es el más utilizado y más conocido de los diagramas orientados a objetos. Es la fuente de generación de código. • El diagrama de clase representa clases, sus partes y la forma en la que las clases de los objetos están relacionados con otro. • Una clase es una definición de un tipo de objeto.
  • 14. Partes del diagrama de clases • Atributos: describe las características de una clase de objetos. • Operaciones: define el comportamiento de una clase de objetos • Estereotipos: ayuda a entender este tipo de objeto en el contexto de otras clases de objetos con roles similares dentro del diseño del sistema. • Asociación: es un término formal para un tipo de relación. • Herencia: permite organizar las definiciones de la clase para simplificar y facilitar su implementación.
  • 15. Clases • Las clases son descripciones de un juego de objetos con características, comportamiento, relaciones y semánticas comunes. Se usan para modelar un juego de conceptos o entidades. • Se denotan con un rectángulo con compartimentos. • En ellos se ponen el nombre, los atributos, las operaciones y además se pueden usar para anotar otras propiedades del modelo como son (reglas del negocio, responsabilidades, excepciones, etc.) • Pueden tener interfaces para especificar conjuntos de operaciones proporcionadas a su ambiente. Todas las operaciones deben estar asociadas a métodos. • Pueden tener relaciones de generalización con otras clases.
  • 16. Atributos • Son descripciones de características, se usan para modelar información asociada con una entidad, sintaxis: Nombre_atributo[multiplicidad]:Tipo = Valor_inicial • La multiplicidad es opcional e indica el número de atributos por instancia de la clase.
  • 17. Operaciones • Son descripciones del comportamiento, se usan para modelar los servicios u operaciones asociados con una entidad, esto es, lo que una entidad puede hacer, sintaxis: Nombre_operación[parámetros:tipo]:Valor_retorno:tipo
  • 18. Interfaces • Son clases que definen un juego de operaciones externas accesibles pero sin métodos. Se usan para modelar una serie de operaciones que definen un servicio que puede ser ofrecido por diferentes clases. • Se representan como clases pero con el estereotipo <<interface>>. • Solo contienen operaciones públicas
  • 19. Todos los diagramas soportan el Diagrama de Clase Diagrama de Clase Diagrama de Estados Diagrama de Colaboración Diagrama de Secuencia Diagrama de Objetos Diagrama de Actividades Casos de Uso
  • 20. Diagrama de Objetos • La clase define las reglas; los objetos expresan los hechos. • La clase define que puede ser; el objeto describe que es. • Se considera un caso especial del diagrama de clases. • Puede construirse junto con el de clases. • Describe una instancia de un diagrama de clase en un momento en particular. • Este diagrama contiene objetos y ligas.
  • 21. Modelando Clases • La representación de una clase es un rectángulo con 3 divisiones: • El del nombre define la clase, (un tipo de objeto). • El de los atributos contiene la definición de los datos. • El de las operaciones contiene la definición de cada comportamiento soportado por este tipo de objeto.
  • 22. Ejemplo La siguiente figura muestra un vuelo de una aerolínea modelado como una clase UML. Nombre Atributos Operaciones Atributo: tipo de dato Operación(parámetros: Tipo de dato):valor de retorno
  • 23. Modelando un atributo • Un atributo describe una pieza de información que un objeto tiene o conoce de sí mismo. Para poder usar esta información se debe asignar un nombre y especificar el tipo de dato. • El tipo de dato puede ser primitivo o tipo de dato abstracto (definido) • Cada atributo puede tener reglas que limiten los valores asignados a éste. Se puede usar un valor de default para protegerlo.
  • 24. Visibilidad de un atributo • La definición de un atributo debe especificar que otros objetos los pueden ver. La visibilidad puede ser: • Public (+) permite el acceso a objetos de las otras clases. • Private (-) limita el acceso a la clase, solo operaciones de la clase tienen acceso. • Protected (#) permite el acceso a subclases. En el caso de generalización (herencia), las subclases deben tener acceso a los atributos y operaciones de la superclase, sino no pueden heredar. • Package (~) permite el acceso a los otros objetos en el mismo paquete.
  • 25. Ejemplo Especificación de un atributo Elemento Ejemplo Nombre del atributo compañía Tipo de dato compañía:character Valor de default (si hay) compañía:character = espacios Restricciones compañía:character = espacios {1 a 30} Caracteres compañía:character = espacios{1 a 30 alfabéticos, espacios, puntuación, no especiales} Visibilidad - compañía:character = espacios {1 a 30 alfabéticos, …….
  • 26. Modelando una Operación • Los objetos tienen comportamientos, cosas que puedan hacer y que se les puedan dar a éstos. • Las operaciones requieren un nombre, argumentos y a veces un valor de retorno. • Las reglas de privacidad se aplican en la misma forma que para los atributos: Private, Public, Protected y Package.
  • 27. Ejemplo Especificación de una operación Elemento Ejemplo Nombre totalOrderAmount Definir argumentos/ Parámetros, corresponden a una instancia de Order totalOrderAmount (order: integer) Definir el tipo de dato de retorno totalOrderAmount (order: integer) : Dollar Identificar y describir restricciones totalOrderAmount (order: integer) : {El total es la suma de cada item (p.u. x cantidad) Visibilidad + totalOrderAmount (order: integer) : {El total es la suma ….
  • 28. Diagrama de Clases: Asociaciones • El propósito de la asociación puede expresarse en un nombre, verbo o frase que describa como los objetos de un tipo (clase) se relacionan con objetos de otro tipo (clase). Por ejemplo: Una persona tiene un coche Una persona maneja un coche • Multiplicidad: cuantos objetos van a participar en la relación
  • 29. Asociaciones Se indica el rol y la multiplicidad. Un vuelo está asociado con un avión y un avión puede tener asociados ninguno ó varios números de vuelo.
  • 30. Dirección • La dirección en las flechas de la asociación determinan en que dirección puede recorrerse una asociación en el momento de la ejecución. • Una asociación sin flechas significa que se puede ir de un objeto a otro y viceversa. • Por ejemplo la siguiente el tipo de flecha en la asociación implica que desde el objeto Reservación puedes recuperar (dirigirte hacia) el objeto Cliente. También implica que del objeto Cliente puedes recuperar el juego de reservaciones para ese cliente.
  • 31. 1….* hecha para 1 Reservación Cliente 1….* hecha para 1 Reservación Cuarto Supongamos que los requerimientos para un sistema de reservaciones requieren que “desde una reservación, que el sistema pueda recuperar el cuarto
  • 32. Clase Asociación • Cuando se modela una asociación entre clases, a veces es necesario incluir otra clase que contiene información valiosa acerca de la relación. • Se representa como una clase normal solo que la línea que la une con la línea que conecta las asociaciones primarias es punteada. • La siguiente figura muestra una clase asociación para el ejemplo de los vuelos.
  • 33. La asociación entre la clase Flight y FrequentFlyer es a través de una clase llamada MileageCredit. Esto significa que debe haber una instancia en esta clase cuando alguna instancia de la clase Flight se asocie con una instancia de la clase FrequentFlyer
  • 34. Pasos para el diagrama de clases • Identificar las clases. • Mostrar los atributos y operaciones (posteriormente) • Dibujar asociaciones • Etiquetar asociaciones y en caso necesario los roles • Indicar multiplicidad • Dibujar fechas de dirección
  • 35. Asociación Reflexiva • Una clase puede asociarse con sí misma. Una clase Empleado puede relacionarse con sí misma a través del rol gerente/dirige. • No significa que una instancia está relacionada consigo misma, sino que una instancia de la clase está relacionada con otra instancia de la misma clase.
  • 36. Una instancia de Employee puede ser el gerente de otras instancias de Employee. Como el rol manages tiene una multiplicidad de 0…*, significa que puede no tener otros empleados a quien dirigir. Una instancia de Employee tiene 1 sólo gerente ó un solo director.
  • 37. Asociación Cualificada • Un cualificador es un atributo de la clase en el lado opuesto de la asociación, que permite hacer una búsqueda en función a su valor. Por ejemplo “El cliente usa el numOrden para buscar una orden”. • Un tipo de objeto usa el cualificador para accesar el otro tipo de objeto. cliente orden numOrden:int
  • 38. Diagrama de Clase: Agregación y Composición • Cada agregación es un tipo de asociación. • Cada composición es una forma de agregación. Asociación Agregación Composción
  • 39. AGREGACIÓN BASICA • Es un tipo especial de asociación utilizado para modelar una relación “whole to its parts”. • Por ejemplo, Coche es una entidad “whole” y Llanta es una parte del Coche. • Una asociación con una agregación indica que una clase es parte de otra clase. • En este tipo de asociación, la clase hijo puede sobrevivir sin su clase padre.
  • 40. Para representar una relación de agregación, se dibuja una línea sólida de la clase padre (total) a la clase hijo (parte), y con un diamante en el lado de la clase padre. Una llanta puede existir sin automóvil
  • 41. AGREGACIÓN/COMPOSICIÓN • En este caso el ciclo de vida de una instancia de la clase hijo depende del ciclo de vida de una instancia de la clase padre. • A diferencia de la agregación básica, para representarla el diamante no es hueco. • Una instancia de la clase Company debe tener al menos una en la clase Departamento. • En este tipo de relaciones, si una la instancia Company se elimina, automáticamente la instancia Departamento también se elimina. • Otra característica importante es que la clase hijo solo puede relacionarse con una instancia de la clase padre.
  • 42.
  • 43. Generalización • Son asociaciones entre elementos más generales y elementos más específicos, en los cuales éstos últimos son consistentes totalmente con los primeros, por lo que heredan las características proporcionadas por lo elementos generales y además pueden aumentar información. • Este tipo de relación también se conoce como herencia. • En una generalización no hay multiplicidad ni roles. Una (Asociación define las reglas de cómo los objetos se pueden relacionar entre ellos.) • La visibilidad “protected” permite que solo objetos de la misma clase ó subclase vean el elemento.
  • 44. Elementos de la generalización • Para dibujarla, hay que definir: • Superclase: es una clase que contiene alguna combinación de atributos, operaciones y asociaciones que son comunes a dos o más tipos de objetos que comparten el mismo propósito. • Subclase: es una clase que contiene una combinación de atributos, operaciones y asociaciones que son únicas a un tipo de objeto definido por una superclase. • La superclase es reutilizada por la subclase.
  • 46. Paquetes • Es un elemento organizador que proporciona UML al dividir el sistema en paquetes lo hace más fácil de entender.
  • 47. Interfaces • Una clase tiene una instancia de su tipo, mientras que una interface debe tener al menos una clase para implantarla. En UML, una interface es considerada como una especialización de una clase. • Una interface se dibuja como una clase, pero en el compartimento superior del rectángulo aparece un texto ó una inicial que indica que se trata de una interface y no de una clase. • Una interface no es una clase.
  • 48.
  • 49. Ejemplo interface En el diagrama anterior las clases Professor y Student implementan a la interface Person y no heredan de ésta, podemos deducirlo a partir de: 1) El objeto Person de acuerdo a la simbología del diagrama está como una interface y Professor y Student están como clases. 2) No se trata de herencia ya que la línea con la flecha está punteada y no sólida.
  • 50. Instancias • Cuando se modela la estructura de un sistema, a veces es útil mostrar ejemplos de las instancias de las clases. • UML proporciona el elemento instance especification, que muestra información importante utilizando un ejemplo. • La notación es la misma que la de una clase, solo que en el espacio superior el nombre se forma con: nombre de la instancia : nombre de la clase
  • 51. • Además de mostrar las instancias es muy útil mostrar sus relaciones, el ejemplo muestra dos instancias de la clase Flight, ya que el diagrama de clase indica que la relación entre la clase Plane y la clase Fight es 0 a muchos:
  • 52. Roles • Se puede incluir el rol de las clases, el siguiente ejemplo de los roles jugados por la clase Employee (de la asociación reflexiva), mostramos que la relación es entre un Employee jugando el papel de gerente y un Employee jugando el rol de miembro del equipo.
  • 53. Diagrama de clase: Caso de estudio • Establecimiento del problema: para el sistema de control de inventario: “Nuestro sistema está diseñado para inventariar y embarcar únicamente productos identificados. Estos productos pueden ser comprados directamente de proveedores y revenderlos, o podemos empacarlos juntos para crear un producto especial. Los clientes colocan órdenes para uno ó más ítems pero nosotros detectamos en el sistema clientes que hayan o no hayan comprado. Cada ítem corresponde a un producto. Identificamos cada producto usando un número serial único. El cliente puede preguntar sobre el estatus de su orden utilizando el número de orden. Los embarques de productos de los proveedores se reciben y se colocan en el inventario. Cada producto es asignado a una ubicación con lo que se puede encontrar fácilmente cuando se surten las órdenes. Cada ubicación tiene un identificador único. Las órdenes para los clientes se embarcan a medida que los productos están disponibles, por lo que puede haber más de un envío para satisfacer una sola orden de compra, pero puede ser que un solo embarque contenga productos de múltiples órdenes. Los ítems que no se entregaron son colocados en una backorder con una referencia a la orden original”.
  • 54. Construyendo el diagrama de clase 1. Identificar las clases, nombrarlas y definirlas con lo que sabes que son parte del modelo. 2. Identificar, nombrar y definir las asociaciones entre pares de clases. Tener cuidado con clases reflexivas, asignar multiplicidad. 3. Evaluar cada asociación para determinar si debe ser una agregación y cada agregación para ver si debe ser una composición 4. Evaluar las clases para posible generalización (herencia).
  • 61. EJERCICIO EN CLASE Ejemplo de clases para un diagrama de clases de una tienda web. En este ejercicio, se plantean algunas clases con sus atributos que podrías incluir en el diagrama de clases de una tienda online: Usuario: idUsuario: Identificador único del usuario. nombre: Nombre completo del usuario. email: Dirección de correo electrónico del usuario. contraseña: Contraseña del usuario. dirección: Dirección de envío del usuario. métodoDePago: Método de pago preferido por el usuario.
  • 62. EJERCICIO EN CLASE Producto: idProducto: Identificador único del producto. nombre: Nombre del producto. descripción: Descripción detallada del producto. precio: Precio del producto. stock: Cantidad de unidades disponibles en el inventario. Carrito de Compras: idCarrito: Identificador único del carrito de compras. productos: Lista de productos que el usuario ha añadido al carrito. subtotal: Monto total del carrito antes de aplicar impuestos y descuentos. impuestos: Monto total de impuestos aplicados al carrito.
  • 63. EJERCICIO EN CLASE Orden de compra: idOrden: Identificador único de la orden de compra. productos: Lista de productos comprados en la orden. subtotal: Monto total de la orden antes de aplicar impuestos y descuentos. impuestos: Monto total de impuestos aplicados a la orden. envío: Monto del costo de envío de la orden. total: Monto total de la orden incluyendo impuestos, descuentos y costo de envío. Categoría: idCategoría: Identificador único de la categoría. nombre: Nombre de la categoría.
  • 64. Se desea construir un aplicativo de Gestión de factura conociendo lo siguiente: Un cliente puede requerir varias facturas en un lapso de tiempo determinado (una factura solo puede ser hecho por un cliente), cada factura tiene un número de factura y la fecha de facturación y está conformado por varias líneas de factura, cada línea de factura corresponde a un producto. Hay dos tipos de clientes: El cliente normal tiene identificación, nombre, dirección,teléfono, sexo y el cliente empresarial tiene identificación nombre, dirección, teléfono, el cliente empresarial tiene contrato, cada vendedor se hace responsable de los clientes empresariales y cada cliente empresarial es atendido solo por un cliente
  • 66. Video explicativo de Diagrama de clases https://youtu.be/nFvUZ2Q0CFY