Separacion de Responsabilidades

Universidad de Bogotá Jorge Tadeo Lozano
Daniela Corredor Cerón
Taller
Separación de responsabilidades
Arquitectura de Software
2023
Pregunta 1:
En el diseño de una aplicación de telemedicina, ¿cómo garantizarías que la capa de datos
mantenga una separación clara entre la lógica de negocio y la generación del consecutivo
numérico único para cada tele experticia de cada paciente? Proporciona ejemplos concretos y
discute cómo esta decisión impactaría en la escalabilidad y mantenibilidad de la aplicación.
Solución:
Una posible forma de garantizar que la capa de datos mantenga una separación clara entre la
lógica empresarial y la generación de una secuencia única de números para cada especialista
remoto. El paciente debe utilizar un patrón de diseño conocido como Repositorio 1. Este
patrón implica la creación de clases o interfaces que encapsulan operaciones de acceso a datos,
como consultar, insertar, actualizar o eliminar, y proporcionar métodos para realizar estas
operaciones.
Abstrae la lógica empresarial de los detalles de implementación de la capa de datos y le permite
cambiar fácilmente las fuentes de datos o las tecnologías según sea necesario.
La ventaja de usar este patrón es que la lógica de negocio no depende de los detalles de
implementación de la capa de datos, sino que solo se comunica con la interfaz.
Pregunta 2:
Sigues trabajando en el proyecto de telemedicina donde se requieren consultas complejas a la
base de datos para obtener información sobre las teleexperticias y así sacar los indicadores de
salud. ¿Cuáles serían los beneficios y desventajas de utilizar stored procedures en comparación con
realizar las consultas directamente a través de un ORM en la capa de lógica de negocio? Considera
el manejo del consecutivo numérico en tu análisis.
Solución:
Las ventajas y desventajas de utilizar procedimientos almacenados frente a realizar consultas
directamente a través de un ORM en la capa de lógica empresarial dependen de varios
factores, incluidos el rendimiento, la seguridad, la portabilidad, la mantenibilidad y la complejidad
de las consultas, tiene varios o algunos puntos a considerar:
• Rendimiento: Los stored pueden tener un mejor rendimiento que las consultas generadas
por un ORM.
• Seguridad: Los stored procedures pueden ofrecer una mayor seguridad que las consultas
generadas por un ORM.
• Portabilidad: Los ORM pueden ofrecer una mayor portabilidad que los stored procedures,
ya que permiten abstraer la lógica de acceso a datos del proveedor específico de la base de
datos, facilitando el cambio de tecnología si fuera necesario. Además, los ORM pueden
generar consultas compatibles con diferentes dialectos de SQL.
• Mantenibilidad: Los ORM pueden ofrecer una mayor mantenibilidad que los stored
procedures, ya que permiten escribir menos código y más legible para acceder a los datos,
reduciendo la complejidad y el riesgo de errores.
Pregunta 3:
Al aplicar el principio de responsabilidad única en el diseño de la aplicación de telemedicina,
¿cómo dividirías las responsabilidades entre las capas de presentación, lógica de negocio y
datos en relación con la creación de teleexperticias y la generación de PDFs con alto diseño y
envió por correo electrónico? Proporciona ejemplos específicos de cómo lograr una separación
efectiva.
Solución:
Una posible forma de aplicar el principio de responsabilidad única en el diseño de la aplicación
de telemedicina es la siguiente:
Capa de presentación: Esta capa se encarga de la interacción con el usuario, mostrando la
información y recibiendo los datos de entrada. En relación con la creación de teleexperticias y
la generación de PDFs, esta capa podría principales responsabilidades tales como las que
podrían ser:
• Muestra un formulario donde el usuario puede ingresar datos de expertos externos como
paciente, médico, fecha y diagnóstico.
• Valida los datos de entrada y muestra mensajes de error si faltan datos o no son válidos.
• Envíe datos de expertos externos a la capa de

lógica empresarial mediante solicitudes HTTP o servicios web.
También usar la Capa de lógica de negocios: esta capa es responsable de implementar reglas y
procesos de negocios, así como de la comunicación entre la capa de presentación y la capa de
datos. Para la creación remota de expertos y la generación de PDF, esta capa puede tener :
• Recibir los datos del experto remoto enviado por la capa de presentación y verificar que
sean válidos.
• Envíe datos de expertos remotos a la capa de datos llamando a la capa adecuada.
• Obtiene la secuencia única de números generada por la capa de datos y la devuelve a la

capa de presentación.
Adicional la Capa de datos: Esta capa se encarga del acceso y manipulación de los datos
almacenados en una fuente persistente, como una base de datos la cual brinda sus
principales características:
• Reciba datos de expertos externos enviados por la capa de
lógica empresarial y guárdelos en una tabla específica o en una colección de expertos
externos
• Utilice el campo de secuencia o incremento automático para generar una secuencia única
de números para cada experto remoto.
• Devuelva continuamente los números únicos generados a la capa de lógica empresarial.
Pregunta 4:
¿Cómo podrías lograr una alta cohesión y un bajo acoplamiento en el diseño de la aplicación de
telemedicina, considerando la necesidad de mantener el consecutivo numérico único y la
generación de PDFs? Proporciona ejemplos de cómo organizar y comunicar los componentes de
manera eficiente.
Solución:
Un posible enfoque para lograr una alta coherencia y un bajo acoplamiento en

el desarrollo de aplicaciones de telemedicina es el siguiente:
Utilizar el patrón de diseño del repositorio para separar la lógica de acceso a datos de la
lógica empresarial como se explica en la respuesta 1 anterior. De esta forma, se consigue una
alta coherencia asignando una única responsabilidad a cada componente (repositorio o servicio), y
un bajo acoplamiento reduciendo las dependencias entre ellos.
Utilizar el patrón de diseño de inyección de dependencia para inyectar instancias de repositorio en

servicios que las necesitan, en lugar de crearlas directamente en el servicio. De esta manera, se
logra un acoplamiento flexible, permitiendo que los servicios no dependan de una implementación
de repositorio particular, sino de interfaces o contratos.
La capacidad de inyectar diferentes implementaciones o simulacros desde el repositorio facilita

cambiar las fuentes de datos o ejecutar pruebas unitarias.
Utilizar el patrón de diseño de fachada para crear una clase o interfaz que proporcione una
interfaz unificada y simplificada para acceder a los servicios responsables de crear expertos
externos y generar archivos PDF. De esta manera, se logra una alta cohesión al
agrupar actividades relacionadas con el mismo subsistema, y un bajo acoplamiento se logra
aislando la capa de presentación de la complejidad del subsistema y las dependencias internas.

Separacion de Responsabilidades

Cargado por

Copyright:

Formatos disponibles

Separacion de Responsabilidades

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Separacion de Responsabilidades

Cargado por

Copyright:

Formatos disponibles

Universidad de Bogotá Jorge Tadeo Lozano

Daniela Corredor Cerón

• Envíe datos de expertos externos a la capa de

• Envíe datos de expertos remotos a la capa de datos llamando a la capa adecuada.

• Obtiene la secuencia única de números generada por la capa de datos y la devuelve a la

• Devuelva continuamente los números únicos generados a la capa de lógica empresarial.

Un posible enfoque para lograr una alta coherencia y un bajo acoplamiento en

Utilizar el patrón de diseño de inyección de dependencia para inyectar instancias de repositorio en

La capacidad de inyectar diferentes implementaciones o simulacros desde el repositorio facilita

También podría gustarte