Unidad V

Fundamentos del Diseño de Software

Responsable:
Ing. Duwlian Montalti

1
5. Principios del Diseño, Interacción entre diseño y
requerimientos
6. Diseño de atributos de calidad (mantenibilidad,
funcionamiento, usabilidad, seguridad, tolerancia,…).
7. Arquitecturas, patrones de diseño y reuso.
8. Estrategias de diseño: orientado a funciones, a
objetos, a estructura de datos, a aspectos.

2
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos

Sobre todo podemos destacar seis principios fundamentales, aunque son

bastantes más:

• Principio de responsabilidad única o Single responsibility principle (SRP)

• Principio de abierto - cerrado o Open-closed principle (OCP)
• Principio de sustitución de Liskov o Liskow substitution principle (LSP)
• Principio de inversión de dependencias o Dependecy inversion principle
(DIP)
• Principio de segregación de interfaces o Interface segregation principle
(ISP)
• Principio de Hollywood.

3
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos

Principio de responsabilidad única (SRP)

El principio de responsabilidad única dictamina que una clase debería

tener un único motivo de cambio. Definimos la responsabilidad como
una razón para el cambio. Veamos un ejemplo:

Supongamos que tenemos una clase Employee con un montón de

responsabilidades:

4
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos

Principio de responsabilidad única (SRP)

¿Estaría bien?
No, hace demasiadas cosas, no debería hacer tantas cosas.
Aplicando el principio de responsabilidad única debería quedar algo así:

5
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos
Principio de abierto - cerrado (OCP)

El principio de abierto - cerrado enuncia que las entidades software (clases,

módulos, funciones...) deberían estar abiertas para la extensión, pero
cerradas para la modificación. Cuando simple cambio a un programa resulta
en una cascada de cambios en módulos dependientes, el diseño adolece de
rigidez. Los cambios se deben hacer añadiendo código nuevo, no modificando
el que ya funcionaba.

Supongamos que tenemos que Cliente y Servidor son dos clases concretas. El
cliente usa el servidor, ¿qué pasa si queremos cambiar el
servidor? Tendríamos que cambiar la implementación del cliente.

6
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos
Principio de abierto - cerrado (OCP)

Podemos solucionar este problema teniendo una interfaz que se comunique

entre ambas implementaciones.

7
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos
Principio de sustitución de Liskov (LSP)

El principio de sustitución de Liskov dice que los subtipos deben poder ser
reemplazados por cualquiera de sus tipos base. Los objetos de un programa
deberían ser reemplazables por instancias de sus subtipos sin alterar el
correcto funcionamiento de un programa. Debemos asegurarnos de que las
clases derivadas extiendan la clase base sin alterar su comportamiento de
manera que se viole el contrato.

La violación de este principio, en Java, suele dar como resultado un

código repleto de expresiones del tipo instanceof en las cláusulas de
un if anidado. Tenemos que tener claro que los usuarios de los tipos base no
deberían hacer nada especial para tratar a los tipos derivados. De hecho, no
deberían ser conscientes siquiera de la existencia de esos subtipos.
Supongamos que tenemos una jerarquía de empleados en las que existen
empleados con un sueldo fijo y con un sueldo condicionado por las horas de
trabajo.

8
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos
Principio de sustitución de Liskov (LSP)

Supongamos ahora que tenemos un nuevo empleado que no tiene sueldo,

¿qué hacemos? recalculamos el método de calcular sueldo por 0? no tendría
sentido alguno, nos obligaria a poner en alguna parte del código un instanceof o
algo similar. La solución es muy sencilla, no incluir el nuevo empleado en la
jerarquía, pues no son un subtipo de empleado que cumpla todas sus
restricciones, en este caso tener un sueldo.

9
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos
Principio de inversión de dependencias (DIP)

El principio de inversión de dependencias enuncia que:

Los módulos de alto nivel no deberían depender de módulos de bajo nivel. Ambos deben
depender de abstracciones.

Las abstracciones no deben depender de detalles. Son los detalles los que deben
depender de abstracciones.

Es decir, hay que depender de abstracciones no de implementaciones concretas.

Programar para una interfaz no para una implementación. Veamos un ejemplo:

10
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos
Principio de inversión de dependencias (DIP)

Estamos haciéndolo justo al revés. Lo podemos solucionar utilizando una interfaz.

11
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos
Principio de segregación de interfaces (ISP)

Es mejor muchas interfaces específicas para cada cliente que una sola interfaz de
propósito general. Es decir, los clientes no deberían depende de métodos que no usan.
Este lo veremos con más calma pues en cierta medida llega a ser contradictorio. Por
ahora podemos fijarnos en:

Como es vital la segregación de las interfaces en casi cualquier refactorización de código.

12
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos
Principio de Hollywood.

El principio de Hollywood dictamina que debe ser una clase superior la que llame a
las clases inferiores, por ejemplo en la herencia debe ser la clase padre quien llame a
sus subclases. Es denominado principio de Hollywood porque se basa en el "Don´t call
us, we´ll call you", (no nos llame, nosotros le llamamos) tan empleado en Hollywood
cuando un actor va a un casting.

Los ejemplos más claros donde se puede ver cómo se aplica este principio son en los
conocidos patrones de diseño Observer, Factory Method, Strategy, y sobre todo, el más
evidente, el patrón Template Method. Este principio no es del todo correcto pues entra en
conflicto con otros principios, más adelante veremos cual es la finalidad concreta de este
principio.

13
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos

Son las razones por las que el rango completo de elecciones abiertas a un diseñador
seria restringidas. Estas pueden ser:

• Contractuales: Cuando los componentes requieren que se sigan

ciertos procedimientos o métodos a ser utilizados.
• Técnicos: El hardware y software existente limitan la libertad del diseñador desde el
principio.
• Expectativas del cliente: La participación del cliente influye en la estrategia del
diseño adoptada.
• Tipo de sistema: El sistema que se desarrolla es el que permite la elección de
los métodos de diseño y herramientas.
• Tipo de aplicación: Las implicaciones de diseñar un sistema de garantía o seguridad
crítica son diferentes del diseño de un prototipo.
• Ambiente del proyecto: Esto está referido, al ambiente en el que trabajamos desde el
punto de vista físico y en cuanto al ambiente del diseño en general; requisitos que ya
tenemos planteados en el diseño.
• Vista completa del ciclo de vida: Es el conjunto de actividades que los analistas,
diseñadores y usuarios realizan para desarrollar e implementar un sistema de
información.
• Requerimientos no funcionales: Esto está referido a los materiales y equipos que
no son función del sistema; pero que necesito para llevarlo a cabo.

14
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos

Los atributos de calidad conforman lo que se denomina

requerimientos no-funcionales.

Un atributo de calidad en tiempo de ejecución es la funcionalidad,

que es la habilidad del sistema de realizar su trabajo. Se alcanza a
través de la interacción, cooperación y sincronización de los
componentes.

15
 PUNTO 5
Principios del Diseño, Interacción entre diseño y requerimientos

Alcanzar un atributo de calidad puede tener un efecto

positivo o negativo sobre otros atributos de calidad.

Algunos atributos de calidad deben ser diseñados y evaluados a nivel

arquitectónico. Otros no son susceptibles de ser alcanzados a nivel
arquitectónico.

16
 PUNTO 6
Diseño de atributos de calidad
(mantenibilidad, funcionamiento, usabilidad, seguridad, tolerancia,…).

Atributos de calidad: Los atributos de calidad generales del software son

escalabilidad, seguridad, desempeño, y fiabilidad. Los requerimientos de los
atributos de calidad son parte de los requerimientos no funcionales de una
aplicación, la cual captura las múltiples facetas de cómo los requerimientos
funcionales de una aplicación son logrados. Para que tenga sentido los
requerimientos de atributos de calidad deben ser específicos de cómo una
aplicación debe lograr una necesidad dada.

Desempeño: Es una de las cualidades de una aplicación que pueden ser a

menudo cuantificados y validados. Un requerimiento de calidad de desempeño
define una métrica que indica la cantidad de trabajo que una aplicación debe de
realizar en un determinado tiempo y/o plazo que debe cumplir para el correcto
funcionamiento. Pero muchas aplicaciones necesitan procesar cientos, algunas
veces miles y decenas de miles de transacciones cada segundo y estos son
encontrados en muchas grandes organizaciones, especialmente en los mundos
de finanzas, telecomunicaciones y gobierno.

17
 PUNTO 6
Diseño de atributos de calidad
(mantenibilidad, funcionamiento, usabilidad, seguridad, tolerancia,…).
Diseños de atributos de Calidad - Desempeño
Desempeño usualmente se manifiesta asimismo en las siguientes características.
Rendimiento. Rendimiento es una característica de la cantidad de trabajo que una
aplicación debe de realizar en una unidad de tiempo. Es importante entender
precisamente lo que se entiende por un requerimiento de rendimiento. Es el
rendimiento promedio durante un periodo de tiempo determinado o un rendimiento
máximo? Esto es una distinción crucial.

Ejemplo:
Una aplicación para hacer apuestas en eventos como una carrera de caballos. La
mayoría del tiempo una aplicación de este tipo hace poco trabajo, y por lo tanto el
requerimiento promedio de rendimiento es bajo fácil de realizar. Pero todo el
tiempo hay un evento de carrera, por lo tanto cada tarde, el periodo de 5 o menos
minutos antes de cada carrera se ve cientos de apuestas en el mismo segundo. Si
la aplicación no es capaz de procesar estas apuestas, entonces el negocio pierde
dinero y los usuarios se disgustan. Por lo tanto para este escenario, la
aplicación debe ser diseñada para satisfacer es anticipadamente,
rendimiento máximo y no promedio de rendimiento. De hecho, soportando
solo promedio de rendimiento seria un desastre.
18
 PUNTO 6
Diseño de atributos de calidad
(mantenibilidad, funcionamiento, usabilidad, seguridad, tolerancia,…).
Diseños de atributos de Calidad - Desempeño
Tiempo de respuesta: Es una característica de latencia (tiempo en el que se
realiza una petición y es contestada) una aplicación muestra una transacción de
negocio en proceso. Tiempo de respuesta es más a menudo asociado en el tiempo
que una aplicación toma para responder a una entrada.

Ejemplo:
Una aplicación de punto de venta soportando un gran almacén. Cuando un artículo
es escaneado en la caja rápida, un segundo o menos responde desde el sistema
con el precio del articulo lo cual significa que el cliente puede ser atendido
rápidamente. Otra vez, es siempre importante distinguir entre los tiempos de
respuesta garantizados y los tiempos de respuesta promedio. Algunas
aplicaciones quizá necesiten que todas las solicitudes sean respondidas en
un tiempo limite definido a esto se le llama tiempo de respuesta garantizado.
Otras aplicaciones quizá especifiquen un tiempo de respuesta promedio
permitiendo tiempos de espera mayores cuando la aplicación esta
extremadamente ocupada (hora pico). También en el último de los casos para un
limite superior el requerimiento del tiempo de respuesta tiene que ser especificado.
Por ejemplo el 95% de las solicitudes deben de ser procesadas en menos de 4
segundos y ninguna solicitud debe tomar mas de 15 segundos.
19
 PUNTO 6
Diseño de atributos de calidad
(mantenibilidad, funcionamiento, usabilidad, seguridad, tolerancia,…).
Diseños de atributos de Calidad - Desempeño
Tiempo Límite. Todos han escuchado del sistema de pronóstico de tiempo que
toma 36hrs para producir el pronóstico del tiempo para el siguiente día. Es un
excelente ejemplo de un requerimiento para cumplir con el desempeño en un
plazo determinado de tiempo. Un sistema para el pago del seguro social debe de
completar el pago a tiempo para poder hacer el depósito en la cuenta del
reclamante en un día determinado. Si el pago se completa fuera de tiempo el
reclamante no tendrá su depósito en el tiempo esperado y esto puede causar
severos problemas no solo para el reclamante. En general cualquier aplicación
que tiene una ventana de tiempo límite debe tener un requerimiento de
rendimiento en un plazo determinado.

Desempeño para el sistema ICDE Desempeño en el sistema ICDE es un

atributo de calidad importante. La llave del requerimiento de desempeño
pertenece al carácter interactivo del ICDE. Como el usuario va a realizar sus
tareas, la parte del cliente en la aplicación ICDE es atrapar las acciones claves
y enviarlas al servidor del ICDE para almacenarlas. En consecuencia en muy
importante que los usuarios del ICDE no experimenten retrasos usando sus
aplicaciones mientras el programa del ICDE atrapa y almacena los eventos.
20
 PUNTO 6
Diseño de atributos de calidad
(mantenibilidad, funcionamiento, usabilidad, seguridad, tolerancia,…).

Escalabilidad Vamos a empezar con una definición representativa de la

escalabilidad. “como una buena solución a un problema va a funcionar cuando el
tamaño del problema aumenta” Esto es muy usual en un contexto de arquitectura.
Nos dice que la escalabilidad es acerca de cómo un diseño puede hacer frente
con algún aspecto de los requerimientos que aumentan de tamaño en la
aplicación. Para que se concrete el requisito de atributo de calidad, necesitamos
entender exactamente que es lo que se espera para ser grande.

Ejemplo:
Solicitud de carga Basado sobre alguna mezcla de solicitudes definidas sobre
una plataforma de hardware dada, una arquitectura para una aplicación de
servidor puede ser designada para soportar a 100 tps en una carga máxima, con
un promedio de un segundo de tiempo de respuesta.
Conexiones simultáneas Una arquitectura puede ser diseñada para soportar
1000 usuarios. Como va a responderla arquitectura si esta numero crece
significativamente? Si un usuario conectado consume algunos recursos, entonces
es probable que habrá un limite en el numero de conexiones que pueden ser
soportadas efectivamente. 21
 PUNTO 6
Diseño de atributos de calidad
(mantenibilidad, funcionamiento, usabilidad, seguridad, tolerancia,…).

Modificabilidad El atributo de calidad Modificabilidad es una característica de que

tan fácil es poder cambiar una aplicación para abastecer nuevos requerimientos
funcionales y no funcionales. Prediciendo que la modificabilidad requiere de un
costo estimado de esfuerzo y dinero para realizar cambios. Solo sabrás cuanto fue
el costo hasta que el cambio se haya completado entonces descubrirás que tan
bueno fue tu estimación.

22
 PUNTO 6
Diseño de atributos de calidad
(mantenibilidad, funcionamiento, usabilidad, seguridad, tolerancia,…).

Seguridad: Seguridad es un tema técnico complejo que puede solo ser tratado
con un poco de superficialidad. Seguridad se reduce al entendimiento de los
requerimientos precisos de seguridad para una aplicación y la elaboración de
mecanismos para soportarlos.

Autentificación: aplicaciones que verifican la identidad de sus

usuarios y otras aplicaciones con las cuales se comunican.
Autorización: Autentifica los usuarios y aplicación que tiene
derechos definidos de acceso a los recursos del sistema. Por ejemplo
algunos usuarios pueden tener solo acceso de lectura a los datos de
la aplicación mientras que otros tienen de lectura y escritura.
Encriptación: los mensajes enviados para/desde de la aplicación
son encriptados
Integridad: esta asegura que el contenido del mensaje en tránsito no
se alterado.
No-repudio: el remitente del mensaje tiene una prueba de envió y el
receptor se asegura de la identidad del remitente. Esto significa que
no puede negar su participación en el mensaje.
23
 PUNTO 6
Diseño de atributos de calidad
(mantenibilidad, funcionamiento, usabilidad, seguridad, tolerancia,…).

Disponibilidad está relacionada a la fiabilidad de una aplicación. Si

una aplicación no está disponible para ser usada cuando se necesita,
entonces es poco probable que este cumpliendo sus requerimientos
funcionales. Disponibilidad es relativamente fácil de medir. En términos
de especificación muchas aplicaciones de IT deben de estar
disponibles al menos durante horas de oficina. La mayoría de los sitios
de Internet desean un 100% de disponibilidad, porque en el Internet no
existen horarios de oficina. Fallas en aplicaciones pueden causar que
no estén disponibles. Las fallas atacan en la fiabilidad de una
aplicación, la cual usualmente es medida por el tiempo entre fallas. La
duración de cualquier periodo de no disponibilidad está determinado
por la cantidad de tiempo que toma detectar la falla y reiniciar el
sistema.

24
 PUNTO 6
Diseño de atributos de calidad
(mantenibilidad, funcionamiento, usabilidad, seguridad, tolerancia,…).

Integración Integración está relacionado con la facilidad con la cual una

aplicación puede ser incorporada en un contexto más amplio de la aplicación. El
valor de una aplicación o componente puede frecuentemente en gran medida ser
incrementado si la funcionalidad o datos pueden ser usados en diferentes caminos
que el diseñador originalmente no anticipo. La estrategia más generalizada para
proveer integración a través de la integración de datos o con una aplicación de
interfaz de programación (API).La integración de datos envuelve almacenar los
datos de una aplicación que manipula en diferentes maneras para que otras
aplicaciones puedan accesar. Esta puede ser una simple base de datos estándar
para almacenar datos, o quizás implementando mecanismos para extraer los
datos en un formato conocido como XML o con una coma que separa el texto del
archivo para que otras aplicaciones puedan accesar. Con la integración de datos,
las diferentes maneras en que los datos son usados por otras aplicaciones esta
fuera de control del dueño original de los datos. Esto es porque la integración de
los datos y las reglas del negocio impuestos por la aplicación son temporales.

25
 PUNTO 6
Diseño de atributos de calidad
(mantenibilidad, funcionamiento, usabilidad, seguridad, tolerancia,…).

Otros atributos de calidad

Portabilidad: que una aplicación puede ser ejecutada fácilmente
software/hardware en una plataforma diferente para la que fue desarrollada.
Portabilidad depende de las opciones de tecnología de software usadas para
implementar la aplicación, y las características de las plataformas donde necesita
ser ejecutada.
Capacidad de Prueba: que tan fácil o difícil se puede probar una aplicación? Las
decisiones de diseño tempranas pueden en gran medida afectar la cantidad de
casos de prueba que son requeridos. Entre mas complejo sea el diseño, mayor
será la dificultad para probarlo a fondo.
Soportabilidad: esta es una característica de que tan fácil una aplicación es
soportada una vez que ha sido implementada. Soporte típicamente envuelve el
diagnostico y solución de problemas que ocurren mientras la aplicación esta en
uso. Sistemas soportables tienden a proveer facilidades para diagnosticar, tales
como registros de errores que causan las fallas.

26
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.

Antes de comenzar el desarrollo de algún software o solución tecnológica,

conviene elegir la arquitectura adecuada que proporcione la funcionalidad y
atributos de calidad deseados. En ese particular, cobra importancia el conocer los
distintos patrones de arquitecturas, o maneras de abordar los temas de diseño de
aplicaciones complejas, esto con el propósito de obtener el mejor diseño antes de
iniciar algún esfuerzo en el desarrollo de software.

¿Qué es un Patrón de Arquitectura?

En términos generales, un patrón de arquitectura es la conceptualización de una
solución genérica y reutilizable, aplicable a un problema de diseño de software en
un contexto determinado, satisfaciendo las necesidades del negocio.

Los patrones arquitectónicos son la representación de las buenas prácticas y

estructuras de diseño probadas, de modo que puedan reutilizarse. El objetivo es
reutilizar las experiencias y conocimientos arquitectónicos que han dado buenos
resultados en el pasado.

27
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.

Un patrón arquitectónico es un conjunto de decisiones de diseño que se

repiten en la práctica, que tienen características bien definidas y que pueden
reutilizarse, describiendo así características de una arquitectura bien
diferenciada.

La elaboración de una arquitectura para una solución concreta puede verse

como un proceso de selección, adaptación y combinación de patrones. El
arquitecto de software debe decidir cómo reutilizar un patrón, hacer los
ajustes necesarios al contexto específico, a las restricciones del problema, y
a la solución que está diseñando.

28
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.

Seguidamente, se abordarán los patrones arquitectónicos más comunes

aplicados a desarrollos de software, con sus principales características.
Capas (Layer pattern)
Este patrón suele ser el más utilizado, y se enfoca en estructurar aplicaciones que
pueden descomponerse en grupos de subtareas o responsabilidades, las cuales se
encuentran en un nivel concreto de abstracción. Cada capa proporciona servicios a
la capa inmediatamente superior.
Las cuatro (4) capas más habituales de una aplicación en general, son las
siguientes.
• Capa de Presentación, también conocida como Capa de Interfaz de Usuario
(Front-End Layer).
• Capa de Aplicación, también conocida como Capa de Servicio (Services Layer).
• Capa de Lógica de Negocio, también conocida como Capa de Dominio o
Persistencia (Back-End Layer).
• Capa de Acceso a Datos, donde residen finalmente los datos almacenados en
algún gestor de bases de datos (Data Layer).
• Se utilizan en el desarrollo de:
• Aplicaciones generales de escritorio.
• Aplicaciones web en general.
29
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.

Seguidamente, se abordarán los patrones arquitectónicos más comunes

aplicados a desarrollos de software, con sus principales características.

Capas (Layer pattern)

30
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Cliente Servidor (Client-Server pattern)

Este patrón consta de dos (2) partes: un servidor y múltiples clientes. El

componente servidor proporciona servicios a múltiples componentes cliente. Los
clientes solicitan servicios al servidor, y éste proporciona los servicios pertinentes a
dichos clientes. Además, el servidor sigue escuchando las peticiones de los clientes.
Algunos ejemplos de su utilización son:
• Aplicaciones en línea como correo electrónico.
• Intercambio de documentos y banca.

31
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Maestro-Esclavo (Master-Slave pattern)

Este patrón consta de dos (2) partes: maestro y esclavos. El componente maestro
distribuye el trabajo entre componentes esclavos idénticos, y determina un resultado
final a partir de los resultados que devuelven los esclavos. Entre sus usos están:
• En la replicación de bases de datos, la base de datos maestra se considera la
fuente autorizada, y las bases de datos esclavas se sincronizan con ella.
• Periféricos conectados a un sistema informático (unidades maestras y esclavas).

32
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Filtros-Tuberías (Pipe-Filter pattern)

Este patrón puede utilizarse para estructurar sistemas que producen y procesan un
flujo de datos. Cada paso de procesamiento está encerrado dentro de un
componente de filtro. Los datos que se van a procesar pasan a través de tuberías.
Estas tuberías pueden utilizarse para almacenar o sincronizar datos. Se utiliza en
desarrollo de aplicaciones que impliquen:
• Compiladores. Los filtros consecutivos realizan el análisis léxico, el análisis
sintáctico, el análisis semántico y la generación de código.
• Procesos de Extracción, Transformación y Carga de Datos (ETLs), en soluciones
de datos, tales como poblar Data Warehouse o Data Marts, entre otras.

33
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Mediador (Broker pattern)

Este patrón se utiliza para estructurar sistemas distribuidos con componentes

desacoplados. Estos componentes pueden interactuar entre sí mediante
invocaciones a servicios remotos. Un componente Broker se encarga de coordinar
la comunicación entre los componentes.
Los servidores publican sus capacidades (servicios y características) en el Broker.
Los clientes solicitan un servicio a éste, y redirige al cliente a un servicio adecuado
de su registro. Se suele utilizar en soluciones de software, tales como:
• Software de intermediación de mensajes como Apache ActiveMQ, Apache Kafka,
RabbitMQ y JBossMessaging.

34
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Par-a-Par (Peer-to-Peer pattern)

En este patrón, los componentes individuales se conocen como Par (Peers). Los
pares pueden funcionar como clientes, solicitando servicios a otros pares, y como
servidores, proporcionando servicios a otros pares. Un par puede actuar como
cliente, como servidor o como ambos, y puede cambiar su función dinámicamente
con el tiempo. Entra sus aplicaciones prácticas se encuentran:
• Software de redes para intercambio de archivos tales como Gnutella o G2
• Protocolos multimedia tales como P2PTV y PDTP.
• Productos basados en Cadena de Bloques, tales como criptomonedas, Bitcoin y
Blockchain.

35
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Micronúcleo (Microkernel pattern)

Este patrón se ocupa en situaciones donde el software debe adaptarse a los

requisitos cambiantes, pero a la vez aislados. Se parte de un núcleo mínimo de
funcionalidades de cara al usuario final, para ir ampliando el software en la medida
de que van surgiendo las necesidades. Sirve además como conector para ampliar
las capacidades del software sin afectar al núcleo, así como para coordinar la
colaboración y el desarrollo de distintos equipos de trabajo.
Este patrón consta de dos (2) tipos de componentes de arquitectura: un sistema
básico y módulos enchufables. La lógica de la aplicación se divide entre módulos
enchufables independientes y el sistema básico del núcleo, lo que proporciona
extensibilidad, flexibilidad y aislamiento de las características de la aplicación.

36
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Micronúcleo (Microkernel pattern)

En ese sentido, se usa para implementar aplicaciones basadas en productos. Aquellas que se
empaquetan y se ponen a disposición para descargar sus versiones como un producto típico
de terceros. No obstante, muchas empresas también desarrollan y publican sus aplicaciones
empresariales internas como productos de software, con versiones, notas de publicación y
funciones conectables. Algunos ejemplos prácticos de la arquitectura de Micronúcleo son:
• El IDE de Eclipse, al descargar el producto Eclipse se obtiene poco más que un editor. Sin
embargo, una vez que se empieza a añadir Plug-Ins, se convierte en un producto altamente
personalizable y útil.
• Los antivirus de para computadores de escritorio, donde se van incorporando las semillas
de revisión de virus sin afectar la funcionalidad principal.
• Los parches de seguridad o mejoras de los principales productos de software que soportan
las operaciones en las empresas, tales como sistemas operativos, manejadores de bases
de datos, entre otros.

37
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Bus de Eventos (Event-Bus pattern)

Este patrón se ocupa principalmente de los eventos y comprende cuatro (4)

componentes principales: origen de eventos, oyente de eventos, canal y bus de
eventos. Los orígenes publican mensajes en determinados canales del bus de
eventos. Por otra parte, los oyentes se suscriben a canales en el bus. En ese
sentido, los oyentes reciben notificaciones de los mensajes que se publican en los
canales suscritos, y en consecuencia, envían las respuestas correspondientes.
Algunos ejemplos de su utilización son:
• En el desarrollo de Apps para Android.
• Servicios de notificación.

38
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Modelo-Vista-Controlador (Model-View-Controller pattern)
Este patrón, también conocido como patrón MVC, divide una aplicación interactiva
en tres (3) partes como:
• Modelo: Contiene la funcionalidad central y los datos.
• Vista: Muestra la información al usuario (se puede definir más de una vista).
• Controlador: Maneja las entradas del usuario.
• Esto se hace para separar las representaciones internas de la información de las
formas en que la información se presenta al usuario y es aceptada por éste.
Desacopla los componentes y permite una reutilización suficiente del código.
Ejemplo de su utilización:
• Desarrollo de aplicaciones de la World Wide Web en los principales lenguajes de
programación.
• Frameworks web como Django y Rails.

39
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Pizarra (Blackboard pattern)
Este patrón es útil para problemas para los que no se conocen estrategias de
solución deterministas. El patrón de la pizarra consta de tres (3) componentes
principales.
Pizarra - una memoria global estructurada que contiene objetos del espacio de
soluciones.
Fuente de conocimiento: módulos especializados con su propia representación.
Componente de control: selecciona, configura y ejecuta los módulos.
Todos los componentes tienen acceso a la pizarra. Los componentes pueden
producir nuevos objetos de datos que se añaden a la pizarra. Los componentes
buscan determinados tipos de datos en la pizarra, y pueden encontrarlos mediante
la concordancia de patrones con la fuente de conocimiento existente. Ejemplos de
su utilización:
• Reconocimiento de voz.
• Identificación y seguimiento de vehículos.
• Identificación de estructuras proteínicas.
• Interpretación de señales de sonar.

40
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Interprete (Interpreter pattern)

Este patrón se utiliza para diseñar un componente que descifra programas escritos
en un lenguaje específico. Especificamente para evaluar líneas de programas,
sentencias o expresiones escritas en un lenguaje de programación concreto. La
idea básica es tener una clase para cada símbolo del lenguaje. Entre los ejemplos
prácticos de su uso están:
• Lenguajes de consulta de bases de datos como SQL.
• Lenguajes utilizados para describir protocolos de comunicación.

41
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.

Microservicios (Microservices pattern)

Es uno de los patrones más recientes y se ideó con el objetivo de crear aplicaciones
más flexibles y para facilitar la migración de aplicaciones legadas y monolíticas. En
la práctica, se trata de varias aplicaciones ligeras desacopladas, que atienden
características concretas, que en su conjunto, conforman un programa principal con
múltiples funcionalidades.
Cada componente del software puede funcionar de manera autónoma e
independiente, implementando funcionalidades muy específicas de una aplicación
mucho más general.

42
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.
Microservicios (Microservices pattern)
Entre los ejemplos prácticos de aplicaciones basadas en microservicios, se tienen algunas de uso cotidiano,
que son incluso lideres en sus correspondientes nichos de mercado, entre estas se tienen:
• Netflix: Pionera en la implementación de este patrón arquitectónico, cuenta con una plataforma basada
Microservicios desde hace años. Según algunas publicaciones actualmente recibe una media de mil
millones de llamadas a sus diferentes servicios y es capaz de adaptarse a más de 800 tipos de
dispositivos mediante su API de streaming de vídeo, la cual realiza cinco solicitudes a diferentes
servidores para no perder nunca la continuidad de la transmisión.
• Amazon: Migró hace poco mas de tres años a la arquitectura de Microservicios siendo una de las
primeras grandes compañías que la implementaban en producción. Se desconocen las cifras
aproximadas de la cantidad de solicitudes que reciben diariamente, en tanto, no deben ser pocas en
virtud al crecimiento sostenido y progresivo que ha tenido Amazon Web Services (AWS).

43
 PUNTO 7
Arquitecturas, patrones de diseño y reuso.

44
 PUNTO 8
Estrategias de diseño:
Orientado a funciones, a objetos, a estructura de datos y a aspectos.

El Diseño de Software es un proceso para conceptualizar los requisitos de software

en implementación de software. El Diseño de Software toma los requisitos del
Usuario como retos e intenta encontrar soluciones óptimas. Mientras el software se
conceptualiza, se planea el mejor diseño para poder implementar la solución
deseable.
Hay muhas variantes de diseño de software. Estudiémoslas pues de manera breve:

Diseño Estructurado

El Diseño estructurado es la conceptualización de un problema en varios elementos

organizados de solución. Está básicamente centrado en el diseño de soluciones. El
beneficio del diseño estructurado es que da un mejor entendimiento sobre cómo se
resuelve el prolema. El diseño estructurado también simplifica el proceso al
diseñador, por tanto este último puede concentrarse en el problema de forma más
acurada.

45
 PUNTO 8
Estrategias de diseño:
Orientado a funciones, a objetos, a estructura de datos y a aspectos.

El Diseño estructurado se basa en 'dividir y conquistar', estrategia donde el problema

se rompe en otros pequeños problemas y cada uno es tratado por separado para
finalmente resolver la totalidad del problema.

Los pequeños problemas en los que se sudivide el problema principal se solucionan

y agrupan en módulos de solución. El Diseño estrucurado emfatiza en que los
módulos estén bien organizados con tal de que se consiga la solución precisa
requerida.

Estos módulos se organizan de manera jerárquica. Se comunican entre ellos. Un

buen diseño estructurado siempre sigue algunas normas de comunicación entre los
diversos módulos, llamadas

• Cohesión - Agrupar todos los elemntos relacionados por función.

• Acoplamiento - comunicación entre los distiontos módulos.
Un buen diseño estructurado tiene alta cohesión y bajo acoplamiento.

46
 PUNTO 8
Estrategias de diseño:
Orientado a funciones, a objetos, a estructura de datos y a aspectos.

Diseño orientado a la función

En Diseño orientado a la función, el sistema es comprimido en varios pequeños sub

sistemas concidos como funciones. Estas funciones son capaces de llevar a cabo
tareas significativas en el sistema. El sistema es considerado como la vista superior
de todas las funciones.

El diseño orientado a la función posee algunas propiedades inherentes del diseño

estructurado donde la metodología de dividir y conquistar se usa.

Este mecanismo de diseño divide la totalidad del sistema en pequeñas funciones, lo

cual nos aporta por medio de la abstracción ocultando la información y sus
operaciones. Estos módulos funcionales pueden compartir información entre ellos
pasando información y usando información disponible a nivel global.

47
 PUNTO 8
Estrategias de diseño:
Orientado a funciones, a objetos, a estructura de datos y a aspectos.

Diseño orientado a la función

Otra característica de las funciones es que cuando un programa acude a una

función, la función cambia el estado del programa, por lo que a veces no es
aceptado por otros módulos. El diseño orientado a la función funciona bien cuando el
estado del sistema no es importante y programa/funciones funcionan con entradas
en vez de con estados.

Proceso de diseño
• El sistema en su totalidad es visto según cómo fluyen los datos en éste por medio
de un diagrama de flujo de datos.
• El DFD representa cómo las funciones cambian los datos y el estado de todo el
sistema.
• El sistema se rompe de forma lógica en pequeñas unidades conocidas como
funciones en base a sus operaciones en el sistema.
• Cada función es descrita posteriormente en toda su extensión.

48
 PUNTO 8
Estrategias de diseño:
Orientado a funciones, a objetos, a estructura de datos y a aspectos.

Diseño orientado al objeto

El diseño orientado al objeto funciona alrededor de entidades y sus características

en vez de involucrando funciones en el sistema de software. Esta estrategia de
diseño se centra en entidades y sus características. Todo el concepto de solución de
software se centra en las entidades implicadas.

Veamos pues los conceptos importantes que abarca el Diseño orientado al objeto:

•Objetos - Todas las entidades implicadas en el diseño de la solución son

conocidas como objetos. Por ejemplo, persona, bancos, empresa, y clientes con
tratados como objetos. Cada entidad tiene algunos atributos asociados a éste y
tiene algunos métodos para actuar sobre los atributos.
•Clases - Una clase es una descripción general de un objeto. Un objeto es un
ejemplo de uan clase. La clase define todos los atributos que un objeto puede
tener y los métodos, lo cual define la funcionalidad del objeto.
En el diseño de la solución, los atributos se almacenan como variables y las
funcionalidades se definen por medio de métodos o procedimientos.
49
 PUNTO 8
Estrategias de diseño:
Orientado a funciones, a objetos, a estructura de datos y a aspectos.

Diseño orientado al objeto

• Encapsulación - En OOD, los atributos (variables de los datos) y los métodos

(intervención en los datos) se juntan, hablamos de encapsulación. La
encapsulación no solo une la iformación importante de un objeto en un mismo
lugar, también restringe el acceso a datos y métodos desde el mundo exterior.
Esto es llamado ocultación de información.
• Herenia - OOD permite clases similares para acumular de manera jerárquica
donde las sub clases pueden importar, implementar y reutilizar variables y
métodos permitidos de sus immediatas super clases. Esta propiedad de OOD es
conocida como herencia. Esto facilita a la hora de definir clases y crearlas desde
otras clases específicas.
• Poliformismo - Los lenguajes OOD nos dan un mecanismo donde los métodos
llevan a cabo tareas similares pero con variantes en los argumentos, se le puede
asignar el mismo nombre. Esto se llama poliformismo, lo que permite a una
interfaz única llevar a cabo tareas de diferente tipo. Dependiendo de como se
aplique la función, la parte del código respectiva se ejecuta.

50
 PUNTO 8
Estrategias de diseño:
Orientado a funciones, a objetos, a estructura de datos y a aspectos.

La Programación Orientada a Aspectos o POA (en inglés: aspect-oriented

programming) es un paradigma de programación que permite una adecuada
modularización de las aplicaciones y posibilita una mejor separación de
responsabilidades (Obligación o correspondencia de hacer algo).

Gracias a la POA se pueden encapsular los diferentes conceptos que componen una
aplicación en entidades bien definidas, eliminando las dependencias entre cada uno
de los módulos. De esta forma se consigue razonar mejor sobre los conceptos, se
elimina la dispersión del código y las implementaciones resultan más comprensibles,
adaptables y reusables. Varias tecnologías con nombres diferentes se encaminan a
la consecución de los mismos objetivos y así, el término POA es usado para referirse
a varias tecnologías relacionadas como los métodos adaptativos, los filtros de
composición, la programación orientada a sujetos o la separación multidimensional
de competencias.

51
 PUNTO 8
Estrategias de diseño:
Orientado a funciones, a objetos, a estructura de datos y a aspectos.

La Programación Orientada a Aspectos o POA

Objetivos
El principal objetivo de la POA es la separación de las funcionalidades dentro del
sistema:
• Por un lado funcionalidades comunes utilizadas a lo largo de la aplicación.
• Por otro lado, las funcionalidades propias de cada modelo
Cada funcionalidad común se encapsulará en una entidad.

52
 PUNTO 8
Estrategias de diseño:
Orientado a funciones, a objetos, a estructura de datos y a aspectos.

La Programación Orientada a Aspectos o POA

Conceptos de POA
Los siguientes 3 conceptos son los más importantes de la programación orientada a
aspectos general:
Aspecto (aspect): funcionalidad transversal (se repetirá a lo largo del sistema) que
será implementada de forma separada. Es el concepto principal de este paradigma
puesto que representa la sección de código que se separó del resto del programa.
Punto de corte (pointcut): es el que se encarga de especificar mediante
expresiones regulares (regex) en qué parte del programa se debe de insertar un
aspecto.
Consejo (advice): es el código que ejecutará el aspecto (cuerpo del algoritmo).

53
 PUNTO 8
Estrategias de diseño:
Orientado a funciones, a objetos, a estructura de datos y a aspectos.
La Programación Orientada a Aspectos o POA

Ventajas y desventajas (pros y contras)

Ventajas:
• Provee una fuerte herramienta para modularizar programas sin importar lo
extensos y complicados que estos sean.
• Vuelve más limpio el código fuente.
• Permite agilizar el proceso de creación de programas cuando muchas personas
están involucradas en el mismo proyecto, y/o están en lugares geográficos
diferentes.
• Puede mezclarse con cualquier otro paradigma de programación.
• Permite la comunicación entre diferentes lenguajes de programación que
comparten aspectos.
Desventajas:
• Sufre de un antipatrón de diseño: acciones a distancia.
• Vuelve difícil de comprender el código puesto que el programa hace tareas que no
están en los métodos que deberían estar.
• Es un poco complicado identificar cuándo es óptimo utilizar POA de forma
eficiente.
54
 PUNTO 8
Estrategias de diseño:
Orientado a funciones, a objetos, a estructura de datos y a aspectos.

Proceso de diseño

El proceso de diseño de Software se puede definir en una serie de pasos bien

definidos. Aunque cambie según el tipo de aproximación (orientado a la función o al
objeto), Debe seguir los siguientes pasos:

• Una solución de diseño se crea partiendo de un requisito o un sistema usado con

anterioridad y/o el diagrama de secuenia de un sistema.
• Los objetos se identifian y agrupan en clases según su similaridad con las
características del atributo.
• La jerarquía de clase y su relación entre ellos está definida.
• El borrador de la aplicación está definido.

55