Programa de

Ingeniería de
Sistemas

INGENIERÍA DE
SOFTWARE
Sesión 7

Tema:

Diseño e implementación de la capa

Persistencia
Resultado de aprendizaje Evidencia de aprendizaje

Diseña la capa de dominio la construcción e Informe Académico individual de Capa de

implementación de un software para una Persistencia
empresa .
Contenido
Agenda

• Diseño e implementación de la capa Persistencia

• Guía de Práctica de Laboratorio 07
Revisa el
siguiente
video:
Después de haber visualizado el video en la slide anterior,
reflexionamos y respondemos las siguientes interrogantes:

01 ¿Cuál es la idea principal o el concepto clave que se destaca

en el video?

02 ¿Cómo se relaciona este tema con otros conceptos dentro

del mismo campo de estudio?

03 ¿Cuáles son las implicaciones prácticas o aplicaciones de

este conocimiento en la vida cotidiana o en el ámbito
profesional?
 Tema
Diseño e
implementación de la
capa Persistencia
Análisis y diseño de Sistemas - Sesión 7

Definiendo atributos válidos

Los atributos deben ser lo más simple posible
(color, numeroIPSS, ISBN) o tipos de datos
comunes( Date, Number, String,Boolean).

NO ES UN
ATRIBUTO
SIMPLE
Análisis y diseño de Sistemas - Sesión 7

Definiendo atributos válidos

La forma más usual de expresar que un cajero
registra la cobranza de la venta es con UNA
ASOCIACIÓN y no con un atributo.
Análisis y diseño de Sistemas - Sesión 7

Definiendo atributos válidos

Los atributos no primitivos deben ser representados como
clases. Un atributo es no primitivo si está conformado por
secciones separadas, o por atributos internos o es una
abstracción de uno o más tipos con las mismas
características.

Dirección podría ser atributo no primitivo porque puede

dividirse en Calle, Nro, Mzna.
CódigoBarras podría estar formado por el NroLote, el
NroCaja y un contador.
No hay una respuesta correcta, depende del significado
del concepto en el contexto en el que se utilizará.
Análisis y diseño de Sistemas - Sesión 7

Definiendo atributos válidos

Los atributos no deben ser utilizados para
relacionar clases. La violación más común de
este principio, es agregar un tipo de atributo llave
foránea como típicamente se hace en el diseño
de bases de datos relacionales.
Análisis y diseño de Sistemas - Sesión 7

Definiendo Los
atributos válidos
atributos deben ser lo más simple posible.

Atributo compuesto código distrito,

nombre distrito, código postal, etc……
Análisis y diseño de Sistemas - Sesión 7

Guías para identificar clases asociativas

•Un atributo está relacionado con la asociación.

•Las instancias de la clase asociativa dependen del
tiempo de vida de la asociación.
•En una asociación de muchos a muchos entre dos
clases y existe información asociada con la propia
asociación.
Análisis y diseño de Sistemas - Sesión 7
Análisis y diseño de Sistemas - Sesión 7
Análisis y diseño de Sistemas - Sesión 7

Actividad 1
1. Del caso de estudio Registrar compras, revise la especificación de los
casos de uso: “Registrar Compras”.
2. Luego, identifique las clases Entidad de la Capa de Dominio y
muéstrelas en un diagrama de clases sin relaciones.
Análisis y diseño de Sistemas - Sesión 7

Ejemplo
 Análisis y diseño de Sistemas - Sesión 7

Actividad 2

1. Revise nuevamente la especificación de los casos de uso: “Registrar

compra”
2. Identifique los atributos de las clases Entidad y muéstrelas en el
diagrama de clases.
Análisis y diseño de Sistemas - Sesión 7

Ejemplo
Análisis y diseño de Sistemas - Sesión 7

Actividad 3
1. Revise nuevamente la especificación de los casos de uso: “Registrar
compra”.
2. Identifique las relaciones entre las clases Entidad y muéstrelas en el

diagrama de clases. Asigne nombres a las relaciones de asociación y

su multiplicidad.
Análisis y diseño de Sistemas - Sesión 7

Ejemplo
 Análisis y diseño de Sistemas - Sesión 7

PATRONES DE DISEÑO GRASP

21
Análisis y diseño de Sistemas - Sesión 7

Ejemplo 1
Generar el siguiente esquema
¿ Que es un Patrón de diseño?
Los patrones de diseño (design patterns) son la base para la
búsqueda de soluciones a problemas comunes en el desarrollo de
software y otros ámbitos referentes al diseño de interacción o
interfaces.
Un patrón de diseño es una solución a un problema de diseño.
Para que una solución sea considerada un patrón debe poseer
ciertas características. Una de ellas es que debe haber
comprobado su efectividad resolviendo problemas similares en
ocasiones anteriores. Otra es que debe ser reusable, lo que
significa que es aplicable a diferentes problemas de diseño en
distintas circunstancias.
Análisis y diseño de Sistemas - Sesión 7

¿ qué es un patrón UML?

Los patrones UML son colaboraciones parametrizadas , esto es , son un grupo de
clases/objetos colaborando entre sí que se pueden abstraer de un conjunto de
escenarios general.
Los patrones son un medio excelente para lograr reutilización y desarrollo robusto.
A medida que los patrones se descubren en todo nuevo proyecto, se puede reutilizar
la plantilla básica del patrón desde modelos previos con los nombres de las variables
apropiadas modificados para el proyecto en curso.

"Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno
, así como la solución al mismo, de tal modo que podemos utilizar esta solución
un millón de veces más adelante sin tener que volver a pensarla otra vez."
Análisis y diseño de Sistemas - Sesión 7

Condiciones para usar un patrón UML

Los patrones generalmente describen cómo resolver un

problema abstracto y la tarea del usuario del patrón consiste en
modificar los elementos del patrón para cumplir las demandas
del compromiso actual.
Antes de comenzar a usar un patrón primero debe ser creado
como un diagrama estándar de UML o existir como tal en algún
repositorio
 Descripción de familias de patrones
Análisis y diseño de Sistemas - Sesión 7

GRASP: son patrones generales de software para asignación de

responsabilidades, es el acrónimo de "General Responsibility
Assignment Software Patterns" .
son una serie de "buenas prácticas" de aplicación recomendable en el
diseño de software.
Patrones GRASP; Experto , Creador , Bajo Acoplamiento ,Alta Cohesión
,Controlador
Descripción de familias de patrones
GOF: Es la abreviación del grupo Gang of Four, compuesto por Erich Gamma,
Richard Helm, Ralph Jhonson y John Vlisides, quienes en su publicación “ Design
Patterns” ( década de los 90s), describen 23 patrones de diseño comúnmente
utilizados y de gran aplicabilidad en problemas de diseño usando modelamiento
UML.
Estos patrones se agrupan en las siguientes categorías : Creacionales,
estructurales y de comportamiento.
Análisis y diseño de Sistemas - Sesión 7

Relación de familias de patrones de diseño

Experto

Creador

GRASP Bajo acoplamiento

Alta Cohesión
PATRONES Controlador

Fabrica, constructor, método

Creacionales de fabricación, prototipo ,
instancia única

Adaptador, puente, objeto

GOF Estructurales Compuesto, envoltorio, fachada,
Peso ligero, proxy

Cadena responsabilidad, orden,

Intérprete, iterador, mediador, recuerdo,
Comportamiento Observador, estado, estrategia,
método plantilla, visitante
Análisis y diseño de Sistemas - Sesión 7

Patrones GRASP
•GRASP.- General Responsability asignment Software Patterns
(Patrones Generales de SW para asignar responsabilidades).
•Describen los principios fundamentales de asignación de
responsabilidades a clases.
•Es la parte más difícil del DOO, consume > tiempo y esfuerzo,
obteniéndose calidad en el diseño.
•Patrones GRASP: Experto, Creador, Bajo Acoplamiento, Alta
Cohesión, Controlador, Polimorfismo, .....
 Responsabilidades
Análisis y diseño de Sistemas - Sesión 7

• Es el Contrato u obligación de una clase.

• Dos categorías de responsabilidades:
➢ Conocer
✓Datos encapsulados privados
✓Existencia de objetos conectados
✓Datos derivados o calculados
➢ Hacer
✓Algo a uno mismo
✓Iniciar una acción en otros objetos
✓Controlar y coordinar actividades en otros objetos.
 1. Patrón: EXPERTO
Análisis y diseño de Sistemas - Sesión 7

Problema: ¿Cuál es el principio fundamental para asignar Responsabilidad

a los objetos?

Solución: “Asignar la R al experto en Información: la clase que cuenta con

la información necesaria para cumplirla”

• Un modelo de clase puede definir docenas y hasta cientos de clases de

software.
• Una aplicación requiere de cientos o miles de responsabilidades
• Si se forma adecuadamente los sistemas: son fáciles de entender,
mantener y ampliar y reutilizar a futuro.
 Ejemplo 1
Análisis y diseño de Sistemas - Sesión 7

¿Quién es el responsable de conocer el total de una venta?

Análisis y diseño de Sistemas - Sesión 7

Para saber el TOTAL de la Venta se asignarán 3 R en 3 clases de

objetos:

CLASE RESPONSABILIDADES

Venta Conoce el Total de la venta

DetalleVenta Conoce el Subtotal de la Línea de Producto

Producto Conoce el Precio del Producto

33
Análisis y diseño de Sistemas - Sesión 7

Utilizando el Diagrama de Interacción (DS)

Análisis y diseño de Sistemas - Sesión 7

Estas responsabilidades serían métodos en las Clases

siguientes:

35
 Creador
Análisis y diseño de Sistemas - Sesión 7

El patrón creador nos ayuda a identificar quién debe ser el responsable de la

creación (o instanciación) de nuevos objetos o clases.
El patrón Creador guía la asignación de responsabilidades relacionadas con la
creación de objetos, tarea muy frecuente en los sistemas orientados a objetos.
El propósito fundamental de este patrón es encontrar un creador que debemos
conectar con el objeto producido en cualquier evento.
Al escogerlo como creador, se da soporte al bajo acoplamiento.
 2. Patrón: CREADOR
Análisis y diseño de Sistemas - Sesión 7

Problema: ¿Quién es responsable de crear una nueva instancia de una

cierta clase?

Solución:
a) Asignar a la clase B la responsabilidad de crear una instancia de una
clase A en los siguientes casos:
• B agrega / contiene /registra instancias / utiliza especialmente / los
objetos A
• B tiene los datos de Inicialización que serán transmitidos a A para
crearlo.
b) Si existe más de una opción, prefiera la clase B que agregue o
contenga la clase A.
Análisis y diseño de Sistemas - Sesión 7

Ejemplo 2
¿Quién debe encargarse de crear una instancia de el detalle
de Venta?

38
 Análisis y diseño de Sistemas - Sesión 7

39
Análisis y diseño de Sistemas - Sesión 7

Esta responsabilidad sería un método de la Clase Venta:

 Práctica
Análisis y diseño de Sistemas - Sesión 7

De la siguiente platilla genere:

Diseño de la capa de dominio (Diagrama de clase lógica), realizando los patrones de
diseño experto y creado coloque los métodos a las clases.
Autoevaluación
Sesión 7
 ¿Cuál es el objetivo principal de la capa de persistencia en un diseño
de software?

Gestionar la interfaz de usuario de la aplicación

Pregunta 1

Almacenar y recuperar los datos de manera eficiente y confiable

Controlar el flujo de ejecución del programa

 ¿Qué tipo de base de datos se utiliza comúnmente en la capa de
persistencia de una aplicación?

Base de datos relacional.

Pregunta 2

Base de datos NoSQL

Base de datos en memoria

 ¿Qué consideraciones de seguridad se deben tener en cuenta al
diseñar la capa de persistencia?

Encriptar los datos almacenados.

Pregunta 3

Establecer controles de acceso y autenticación.

Realizar copias de seguridad periódicas de los datos

Autoevaluación
¡Vamos por más logros!

¡Felicitaciones!
Ha concluido la autoevaluación
 • La capa de persistencia en el diseño de software se encarga de
Conclusiones

gestionar el almacenamiento y recuperación de los datos en una

aplicación.

• El diseño e implementación de la capa de persistencia implica definir

una estructura de datos para representar los objetos y establecer la
conexión con una base de datos u otro sistema de almacenamiento.

• Es importante tener en cuenta consideraciones de seguridad,

rendimiento y escalabilidad al diseñar e implementar la capa de
persistencia para garantizar un almacenamiento eficiente y confiable
de los datos
Aplicando lo
aprendido:

Ver Guía de Laboratorio de la Sesión

Referencias

Fuentes de Información
VILLADA, J. Desarrollo y optimización de componentes
software para tareas administrativas de sistemas [en línea].
Antequera (España): IC Editorial, 2016. Disponible en:
[Link]

COQUE, S. y LOHANA, L. Investigaciones sobre ingeniería de

software [en línea]. Editorial Abya-Yala, 2017. Disponible en:
Digitalia, [Link]