DAS Unidad3A: DISEÑO DETALLADO Y EVALUACIÓN DEL DISEÑO

Diseño y arquitectura de software Carrera de Software
Ph.D. Franklin Parrales 1
20/06/2021
DISEÑO DETALLADO Y
EVALUACIÓN DEL DISEÑO
Unidad 3A
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Diseño y Arquitectura de Software

20/06/2021
Objetivo general de la Unidad 3
Describir la interacción de los elementos que componen un
software mediante el uso de diversos patrones de diseño y
estilos arquitectónicos, permitiendo la posterior evaluación
de su arquitectura y diseño y mejorar así su especificación.

20/06/2021
Unidad 3: Diseño detallado y
evaluación del diseño
• Diseño Detallado.
– Patrones de diseño.
– Patrones Arquitectónicos.
– Diseño de sistemas en red y móviles.
– Notaciones de diseño (diagramas, clases y objetos, UML,
diagramas de estado DFD y especificación formal).
• Evaluación del Diseño
– Atributos de diseño (por ejemplo, acoplamiento, la
cohesión, la ocultación de la información, y la separación
de las capas).
– Métricas de diseño.
– Análisis formal del diseño.
Unidad 3A

20/06/2021
de las capas).

20/06/2021
Documentando el Diseño
• Un producto importante del proceso de Diseño
es un conjunto de documentos que describen el
sistema a construir.
• Referencia Cruzada a los Requerimientos
• Es la solución del problema

20/06/2021
Diseño detallado de software
Construcción de Software
Ingeniería de requerimientos
Diseño
y
Arquitectura
de
Software

20/06/2021
IEEE 1016-2009 SDD Table of Contents
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, acronyms
& abbreviations
2. References
3. Decomposition description
3.1. Module decomposition
3.1.1 Module 1 description
3.2 Concurrent process
decomposition
3.2.1 Process 1 description
3.3 Data decomposition
3.3.1 Data entry 1 description

20/06/2021
IEEE 1016-2009 SDD Table of Contents
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, acronyms
& abbreviations
2. References
3. Decomposition description
3.1. Module decomposition
3.2 Concurrent process
decomposition
3.3 Data decomposition
4. Dependency description
4.1 Intermodule dependencies
4.2 Interprocess dependencies
4.3 Data dependencies
5. Interface description
5.1 Module interface
5.2 Process interface
6. Detailed design
6.1 Module detailed design
6.1.1 Module 1 detail
6.2.2 Module 2 detail
6.2 Data detailed design
6.2.1 Data entity 1 detail
6.2.2 Data entity 2 detail
Architecture

20/06/2021
Relacionar casos de uso, arquitectura y diseño detallado
1. Caso de uso
(parte de los
requisitos)
“Los
automóviles
deberían poder
viajar desde la
cima de Smith
Hill a 65 mph,
viajar en línea
recta y llegar a
Jones Hollow
en 3 minutos.”
3. Arquitectura
2. Clases del
dominio
Auto
Carretera
Cable
Pylon

20/06/2021
Relacionar casos de uso, arquitectura y diseño detallado
1. Caso de uso
(parte de los
requisitos)
“Los
automóviles
deberían poder
viajar desde la
cima de Smith
Hill a 65 mph,
viajar en línea
recta y llegar a
Jones Hollow
en 3 minutos.”
3. Arquitectura
2. Clases del
dominio
Auto
Carretera
Support use case
Auto
Carre
tera
4. Diseño
detallado
Smith
Hill
Cable
Cable
Jones Hollow
Pylon
Pylon
(not specifically required)
(añadido para
detallar diseño)
Barandilla

20/06/2021
Diseño Detallado
• El diseño detallado tiene que ver con el diseño de
las micro-componentes de nuestro sistema.
• Obviamente, este diseño tiene que tener en cuenta
los requisitos del SRD (última versión) y el Diseño
arquitectónico.
• Para efectos del proyecto consideraremos que el
especificaremos el Diseño Detallado a través de:
– Diseño Detallado de Módulos
– Modelo de Navegación
– Interfaces de Usuario
– Diccionario de Datos
– Matríz de Trazado

20/06/2021
Diseño Detallado de Módulos

20/06/2021
Diseño Detallado de Módulos
Cada uno de los módulos del sistema se debe tener un
identificador, que luego será usado en el diccionario de
datos, para especificar:
ID, Nombre (o descripción), Subsistema, Función,
Parámetros de Entrada, Parámetros de Salida.
Para especificar esto se podría utilizar los casos de uso de
UML.

20/06/2021
Modelo de Navegación del Sistema
• Especificar el modelo de navegación del Sistema,
identificando cada uno de sus componentes.
• A continuación se muestran ejemplos de modelos de
navegación, para Web.

20/06/2021

20/06/2021
Interfaz de Usuario
Para la Interfaz de Usuario hay que definir:
3.3.1 Patrón de interfaz a usar (si hay alguno)
3.3.2 Diseño de cada Interfaz

20/06/2021
Patrón de Interfaz a Usar

20/06/2021
Diseño de Cada Interfaz
Se diseña cada interfaz, que guarde relación con el modelo de navegación
(3.2).

20/06/2021

20/06/2021
Diccionario de Datos
- El diccionario de datos complementa el diseño mostrado
en todos los puntos anteriores.
- El diccionario de datos tiene 2 componentes:
Especificación de Procesos y de Datos.
Especificación de Procesos/Pág.Web: Por cada
módulo especificado en el punto 3.1, se indica su
función, los parámetros que recibe, y los parámetros que
retorna.
Especificación de Datos: Por cada tabla se especifican
los campos y su formato.

20/06/2021
Ejemplo de Especificación de Procesos
ID: P1
NOMBRE: Ingreso de Alumnos
SUBSISTEMA: Administración de alumnos
FUNCIÓN: Este módulo permite al alumno el ingreso/actualización de sus datos personales, por
pantalla, a través de un browser.
ENTRADAS: RUT (Char(13)).
SALIDAS: No Hay.
RESPONSABLE: Juan Pérez
ULTIMA ACTUALIZACIÓN: 08/10/2005
REQ. DE SOFTWARE ASOCIADOS: RS001, RS019
ID: P2
NOMBRE: Solicitud de Certificado
SUBSISTEMA: Certificaciones
FUNCIÓN: Este módulo permite al alumno solicitar un certificado´tipo A, B, y/o C, por pantalla, a
través de un browser.
ENTRADAS: Número de matrícula (Char(9)).
SALIDAS: Número de solicitud (Entero Serial).
RESPONSABLE: Juan López
ULTIMA ACTUALIZACIÓN: 20/10/2005
REQ. DE SOFTWARE ASOCIADOS: RS021, RS025

20/06/2021
Especificación de Datos
Por cada tabla se especifican los campos y su formato

20/06/2021
Conclusiones
• El Documento de Diseño (DD) es el producto de la fase
de Diseño.
• Normalmente, a este documento lo puede acompañar
un prototipo del sistema diseñado (y es aconsejable que
así sea).
• El formato del documento de diseño depende un poco
del tipo de proyecto, y de las tecnologías involucradas.
• .... por lo tanto, pueden ajustarlo a sus necesidades.
• ... pero CUIDADO, en el DD no puede faltar nada, que
después se necesite durante la implementación.

20/06/2021
de las capas).

20/06/2021
¿Qué son los patrones?
… Son una forma de comunicar diseños !!!

20/06/2021
¿Para Qué debo Comunicar el Diseño?
• No reinventar soluciones a problemas conocidos.
• Reusar el conocimiento experto relativo a un diseño.
• Beneficios:
– inexpertos pueden diseñar como expertos,
– menos errores debido al uso de diseños ya probados,
– los diseños probados son más fácilmente mantenibles,
– el software puede diseñarse para tener ciertas
propiedades.
• ¿Es esta comunicación exitosa?
– sólo entre virtuosos,
– ¿por qué?

20/06/2021
Patrones de Software
• Propósito
– Compartir una solución probada, ampliamente
aplicable a un problema particular de diseño.
– El patrón se presenta en una forma estándar que
permite que sea fácilmente reutilizado.
• Cinco piezas importantes de un patrón
– Nombre
– Contexto
– Problema
– Solución
– Consecuencias (positivas y negativas)

20/06/2021
Estilos, Patrones e Idioms
• Los patrones de diseño se agrupan en tres
tipos
– Estilos arquitectónicos: Soluciones de
organización a nivel del sistema….
• YA REVISADO
– Patrones de diseño: Soluciones a problemas
detallados de diseño de software
– Idioms: Soluciones útiles para problemas
específicos en algún lenguaje de programación

20/06/2021
• “Son descripciones de clases y objetos
relacionados que están adaptados para
resolver un problema de diseño general
en un contexto determinado”.
Erich Gamma, Richard Helm, John Vlissides y Ralph Johnson
Patrones de diseño

20/06/2021
Patrones de diseño
.
Ingeniero Resuelve problemas
Aplicando estándares
Las buenas soluciones permanecen, las malas se rechazan.
Los ingenieros deben conocer y saber aplicar los estándares
conocidos

20/06/2021
• Se definen con un alto nivel de
abstracción.
• Son independientes de los lenguajes de
programación y de los detalles de
implementación.
• Los patrones promueven y facilitan la
reutilización de arquitecturas y diseños de
software que han demostrado su validez
en muchas aplicaciones.
Patrones de diseño

20/06/2021
Referencias
• Erich Gamma, Richard Helm, Ralph Johnson, John
Vlissides, “Patrones de Diseño: Elementos de
software orientado a objetos reutilizable”, Addison-
Wesley 2003
• Erich Gamma, Richard Helm, John Vlissides y Ralph
Johnson, “Design Patterns”. 1994

20/06/2021
• Describe una estructura dentro de la
cual catalogar y describir patrones
• Cataloga 23 patrones
• Destaca estrategias y aproximaciones
basadas en el diseño de patrones
Patrones de diseño

20/06/2021
• No crearon los patrones descriptos en
el libro.
• Los descubrieron como existentes
dentro de la comunidad del software
Patrones de diseño

20/06/2021
¿Por qué estudiar patrones de diseño?
• Reuso de soluciones de diseño.
• Establecer terminología común.
• Dan una perspectiva de alto nivel sobre el
análisis y diseño.
Patrones de diseño

20/06/2021
• Proporciona un esquema para refinar los
subsistemas o componentes de un sistema de
software, o las relaciones entre ellos.
• Describe estructuras repetitivas de
comunicación de componentes que resuelven
un problema de diseño en un contexto particular
¿Qué resuelve un patrón de diseño?

20/06/2021
•Programe para una interfaz, no para una
implementación.
Comience cualquier jerarquía que necesite
para solucionar su problema con una clase
abstracta, sin implementación de métodos. Que
solo describa los métodos que debe soportar.
Patrones de diseño

20/06/2021
•Favorecer la composición frente a la
herencia de clases.
Construir objetos que contengan otros
objetos. No cargue con todo el peso de
heredar métodos que no necesita
Patrones de diseño

20/06/2021
• Encuentre lo que varía y encapsúlelo.
Patrones de diseño
Lo que puede ser
cambiado en su diseño
encapsúlelo en una
clase , para no tener
necesidad de rediseñar.

20/06/2021
Patrones de diseño
Herencia de clases
Ventajas
•Se define estáticamente
•Fácil modificación de la implementación
Desventajas
•No se cambian implementaciones en
tiempo de ejecución
•Rompe encapsulamiento

20/06/2021
Composición de objetos
Patrones de diseño
Ventajas
•Se define dinámicamente
•No se rompe encapsulamiento

20/06/2021
Patrones de diseño
Que debería ser variable en su diseño
Que puede ser cambiado en su diseño, sin necesidad de rediseñar.
Encapsule lo que puede variar.
•Distintos algoritmos de ordenación de arreglos
•Encapsule cada algoritmo en una clase

20/06/2021
Patrones de diseño
• Manipular objetos en función de la interfaz definida por
la clase abstracta, de la cual extiende, tiene dos
ventajas:
– Los clientes no tienen que conocer los tipos
específicos de los objetos que usan, basta con que
estos cumplan con la interfaz que esperan los
clientes.
– Los clientes desconocen las clases que implementan
dichos objetos; sólo conocen la clase abstracta que
define la interfaz.

20/06/2021
1. Aceptarlos
2. Reconocerlos
3. Internalizarlos
Patrones de diseño

20/06/2021
Clasificación de patrones (GoF)
• Patrones de creación: Tratan de la inicialización y
configuración de clases y objetos.
• Patrones estructurales: Tratan de desacoplar interfaz e
implementación de clases y objetos.
• Patrones de comportamiento: Tratan de las
interacciones dinámicas entre sociedades de clases y
objetos

20/06/2021
Patrones de creación
• The Factory Method retorna una de las posibles
subclases de una clase abstracta dependiendo de los
datos que se le provee.
• The Abstract Factory Method retorna una de las varias
familias de objetos.
• The Builder Pattern separa la construcción de un objeto
complejo de su representación. Varias representaciones
se pueden crear dependiendo de las necesidades del
programa.
• The Prototype Pattern inicializa e instancia una clase y
luego copia o clona si necesita otras instancias, mas que
crear nuevas instancias.
• The Singleton Pattern es una clase de la cual no puede
existir mas de una instancia.

20/06/2021
Patrones estructurales
• Adapter: cambia la interfaz de una clase a la de otra.
• Bridge: permite mantener constante la interfaz que
se presenta al cliente, cambiando la clase que se usa
• Composite: una colección de objetos
• Decorator: una clase que envuelve a una clase
dándole nuevas capacidades.
• Facade: reúne una jerarquía compleja de objetos y
provee una clase nueva permitiendo acceder a
cualquiera de las clases de la jerarquía.
• Flyweight: permite limitar la proliferación de
pequeñas clases similares.

20/06/2021
Patrones de comportamiento
• Cadena de responsabilidad: permite que un conjunto
de clases intenten manejar un requerimiento.
• Interpreter: define una gramática de un lenguaje y usa
esa gramática para interpretar sentencias del lenguaje.
• Iterator: permite recorrer una estructura de datos sin
conocer detalles de cómo están implementados los
datos
• Observer: algunos objetos reflejan un cambio a raíz del
cambio de otro, por lo tanto se le debe comunicar el
cambio de este último.
• Strategy: cantidad de algoritmos relacionados
encerrados en un contexto a través del cual se
selecciona uno de los algoritmos.

20/06/2021
Otros tipos de patrones
• Patrones de programación concurrente
• Patrones de interfaz gráfica
• Patrones de organización de código
• Patrones de optimización de código
• Patrones de robustez de código
• Patrones de fases de prueba

20/06/2021
Plantilla GoF
• Nombre Un buen nombre es vital porque será parte del vocabulario
de diseño
• Nombres Alternativos Otros nombres de uso común para el
patrón.
• Propósito Qué problema pretende solucionar.
• Motivación Descripción del problema y su contexto
– Puede consistir en un ejemplo (un escenario) que ilustre la
clase de problemas que el patrón intenta resolver.
– En general se entienden mejor los problemas concretos
que los abstractos.

20/06/2021
• Estructura Representación gráfica de las clases de los objetos que
participan en el patrón y de sus relaciones estructurales (estáticas)
– Actualmente, lo más común es usar UML.
• Aplicabilidad ¿En qué situaciones puede/debe aplicarse el patrón?
• Participantes Las clases y objetos que participan en el patrón y sus
responsabilidades o roles
• Consecuencias ¿Qué efectos positivos y negativos implica el uso del
patrón?
» ¿Cuáles son los compromisos de diseño que implica su uso?
» ¿Qué aspectos de la estructura del sistema pueden variar de forma independiente?
• Colaboración Cómo colaboran los participantes para llevar a cabo sus
responsabilidades y proporcionar el comportamiento deseado
Plantilla GoF

20/06/2021
• Usos conocidos Al menos dos ejemplos de uso del patrón en
aplicaciones reales.
• Implementación ¿Cómo puede implementarse el patrón en un
lenguaje de programación?
» ¿Qué dificultades implica?
» ¿Hay aspectos dependientes del lenguaje de
programación?
• Código de ejemplo Fragmentos de código que ilustren cómo se
implementa el patrón en uno o varios lenguajes de programación
• Patrones relacionados ¿Cuáles son los patrones más
estrechamente relacionados con el dado?
» ¿Se usa en conjunción con otros patrones? ¿De qué
manera?
Plantilla GoF

20/06/2021
Beneficios de los patrones
• Los patrones favorecen la reutilización de diseños
y arquitecturas a gran escala.
• Capturan el conocimiento de los expertos y lo
hacen accesible a toda la comunidad software.
• Proporcionan un cuerpo de conocimiento utilizable
por toda la comunidad software.
• Favorecen la transmisión de conocimiento entre
profesionales y entre clientes y desarrolladores
• Proporcionan un lenguaje común. Los nombres de
los patrones forman parte del vocabulario técnico
del ingeniero software.

20/06/2021
Problema de los patrones
• Los patrones, no llevan de forma directa a la
reutilización del código, aunque dicha
reutilización se facilita mediante su uso.
• La integración de los patrones en el proceso de
desarrollo se hace todavía de forma manual.
• El número de patrones identificados es cada vez
más grande. Las clasificaciones actuales no
siempre sirven de guía para decidir cual usar.

20/06/2021
• El número de combinaciones patrones estilos y
atributos que se dan en la práctica son
incontables.
• Los patrones se validan por la experiencia y el
debate, no mediante la aplicación de técnicas
formales
Problema de los patrones

20/06/2021
Cómo seleccionar un patrón de diseño
• Considerar cómo los patrones de diseño
solucionan problemas de diseño.
• Buscar las intenciones de cada patrón.
• Estudiar cómo se interrelacionan los
patrones.
• Estudiar patrones de propósito similar.
• Examinar la causa de un rediseño.
• Considerar que debería ser variable en un
diseño.

20/06/2021
Cómo usar un patrón de diseño
• 1. Leer el patrón una vez para tener una
visión general
• 2. Volver y estudiar la estructura, los
participantes y las colaboraciones
• 3. Ver un ejemplo concreto codificado del
patrón
• 4. Elegir nombres para los participantes
del patrón que sean significativos en el
contexto de la aplicación

20/06/2021
Cómo usar un patrón de diseño
• 5. Definir las clases
• 6. Definir nombres específicos de la
aplicación para las operaciones en el
patrón.
• 7. Implementar las operaciones que
realizarán las responsabilidades y
colaboraciones del patrón.

20/06/2021
Problema a resolver
Existe un archivo de texto, el que se debe
leer en distintos momentos y bajo
condiciones variables.
Como lo resuelvo?

20/06/2021
Problema a resolver
Leer solo las palabras que comiencen con t
Leer las palabras de más de 5 caracteres
Leer los palíndromos
Varia la estrategia de lectura
Encapsular

20/06/2021
Clasificación de patrones: Exposiciones
grupales
Creación Estructurales Comportamiento
Clase Factory
Method
Adapter Interpreter
Template Method
Objeto Abstract
Factory
Builder
Prototype
Singleton
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

20/06/2021
Exposiciones

20/06/2021
de las capas).

20/06/2021
Comentario Problemas Soluciones
Fase de
Desarrollo
Patrones de
Arquitectura
Relacionados a la
interacción de objetos
dentro o entre niveles
arquitectónicos
Problemas arquitectónicos,
adaptabilidad a
requerimientos cambiantes,
performance, modularidad,
acoplamiento
Patrones de llamadas
entre objetos (similar a
los patrones de diseño),
decisiones y criterios
arquitectónicos,
empaquetado de
funcionalidad
Diseño inicial
Patrones de
Diseño
Conceptos de ciencia
de computación en
general, independiente
de aplicación
Claridad de diseño,
multiplicación de clases,
adaptabilidad a
requerimientos cambiantes,
etc
Comportamiento de
factoría, Clase-
Responsabilidad-
Contrato (CRC)
Diseño detallado
Patrones de
Análisis
Usualmente específicos
de aplicación o industria
Modelado del dominio,
completitud, integración y
equilibrio de objetivos
múltiples, planeamiento para
capacidades adicionales
comunes
Modelos de dominio,
conocimiento sobre lo
que habrá de incluirse
(p. ej. logging &
reinicio)
Análisis
Patrones de
Proceso o de
Organización
Desarrollo o procesos
de administración de
proyectos, o técnicas, o
estructuras de
organización
Productividad, comunicación
efectiva y eficiente
Armado de equipo,
ciclo de vida del
software, asignación
de roles,
prescripciones de
comunicación
Planeamiento
Idiomas
Estándares de
codificación y proyecto
Operaciones comunes bien
conocidas en un nuevo
ambiente, o a través de un
grupo. Legibilidad,
predictibilidad.
Sumamente
específicos de un
lenguaje, plataforma o
ambiente
Implementación,
Mantemimiento,
Despliegue

20/06/2021
Patrones o estilos arquitectónicos
• Un patrón arquitectónico es un esquema de
organización estructural probado para sistemas de
software.
• Sirven para sintetizar estructuras de soluciones
• Pocos estilos abstractos encapsulan una enorme
variedad de configuraciones concretas
• Definen los patrones posibles de las aplicaciones,
permiten evaluar arquitecturas alternativas con
ventajas y desventajas conocidas ante diferentes
conjuntos de requerimientos no funcionales

20/06/2021
Clasificación de patrones arquitectónicos
❑ Flujo de datos
– Datos fluyen entre los elementos funcionales
❑ Componentes independientes
– -- ejecución en paralelo, ocasionalmente se
están comunicando
❑ Máquinas virtuales
– Interpretador + programa en lenguaje de
propósito especial
❑ Repositorios
– Construido principalmente en torno a un gran
almacén de datos
❑ Capas jerárquicas (layers)
– Subsistemas, cada uno de los cuales depende
unidireccionalmente de otro subsistema
Garlan & Shaw

20/06/2021
Patrones
Arquitectónicos
Simples
Patrones Arquitectónicos
Capa n
Capa n - 1
Capa 2
Capa 1
.
.
.
.

20/06/2021
Patrones Simples
• Layers: Ayuda a estructurar aplicaciones que pueden
ser descompuestas en grupos de subtareas con
distintos niveles de abstracción (granularidad).
• Máquinas virtuales: Simulan funcionalidades no
nativas a hardware o software
• Tubos-y-Filtros: Provee una estructura para sistemas
que procesan datos de entrada. El procesamiento
puede estar encapsulado en uno o más procesos
(filtros).
• Pizarrón: Útil en problemas para los cuales no hay
una solución conocida. Generalmente provee
aproximaciones a la solución final.
• Repositorio: Ayuda a estructurar sistemas centrados
en los datos, haciéndolos más flexibles y adaptables.
.... Estos son modelos generales, que requieren
instanciaciones específicas.

20/06/2021
Layers
La arquitectura de layers o capas
ayuda a estructurar aplicaciones que
pueden descomponerse en grupos de
subtareas con diferentes niveles de
abstracción.
Capa n
Capa n - 1
Capa 2
Capa 1
.
.
.
.

20/06/2021
Arquitectura en capas (Layers)
• Resulta útil cuando se pueden identificar distintas clases
de servicios que pueden ser articulados
jerárquicamente.
• Puede verse como una jerarquía de máquinas virtuales
cada vez más poderosas y abstractas.
• Los componentes de cada capa consisten en conjuntos
de procedimientos.
• Las interacciones entre capas usualmente proceden por
invocación de procedimientos.
• Por definición, los niveles de abajo no pueden usar
funcionalidad ofrecida por los de arriba.
• Problema de diseño: cómo articular la funcionalidad de
cada capa.

20/06/2021
Layers: Contexto
• Hay sistemas que utilizan distinta granularidad y
naturaleza de servicios.
Layers: Problema
• Si los servicios no están bien organizados, el sistema
podría tener problemas de mantenibilidad,
adaptabilidad y escalabilidad.

20/06/2021
Layers: Solución
• Estructurar el sistema en un número apropiado de
capas.
• Empezar con la capa con el nivel más bajo de
abstracción.
• Poner la capa J sobre la J-1 hasta alcanzar la capa
N.
• Los servicios de J usan los servicios de J-1.
• No se requiere un orden en la implementación, ni
ninguna sofisticación.
• Dentro de cada capa, las componentes tienen el
mismo nivel de abstracción.

20/06/2021
Layers: Estructura de la Solución
• Características principales de la estructura:
– los servicios de la capa J se basan solamente en
los de la capa J-1;
– no existen otras dependencias entre las capas;
– la estructura puede verse como una pila o una
cebolla.
Usuario Nivel N
Nivel N-1
Nivel N-2
Nivel 2
Nivel 1
Nivel
Básico
Servicios Básicos
Servicios Utilizables
Usuario

20/06/2021
Layers: Otra Estructura
• Cada capa puede ser una entidad compleja
formada por distintas componentes.
• Una componente en la capa J puede llamar a:
– otra componente en la capa J,
– componentes en la capa J-1 directamente,
– una interfaz definida en la capa J-1.
comp. 2.1 comp. 2.2 comp. 2.3
comp. 1.1 comp. 1.2 comp. 1.3
Nivel 2
Nivel 1

20/06/2021
Layers: Dinámica
• Escenario 1:
– el usuario hace una solicitud a
la capa N, ésta lo pasa a la
capa N-1, y así sucesivamente
hasta la capa 1 que
efectivamente lo resuelve;
– eventualmente la respuesta
vuelve a la capa N y al usuario;
– generalmente una solicitud a la
capa J se traduce en varias
solicitudes a la capa J-1 (nivel
de abstracción).
• Escenario 2:
– se inicia una comunicación
bottom-up cuando la capa 1
detecta algún evento, por
ejemplo cierto input;
– esta notificación sube a
través de las distintas capas.
• Escenario 3:
– la comunicación sólo sucede
entre ciertas capas.
Debe definirse el comportamiento de las componentes para todos los
escenarios posibles.
En todo momento debe haber certeza respecto al comportamiento que
tomarán las componentes.

20/06/2021
Layers: Implementación
• Definir los niveles de abstracción para agrupar
las tareas.
– Considerando la distancia desde el hardware o la
complejidad conceptual;
– Ej. Ajedrez: piezas, movimientos básicos, tácticas
(ej.: defensa Siciliana), estrategias globales del
juego.
• Determinar el número de capas.
– decisión de compromiso; no siempre coinciden
con los criterios definidos para los niveles de
abstracción.
• Designar y asignar tareas a las distintas capas.
– la capa superior es el sistema tal como lo ve el
usuario.

20/06/2021
• Especificar los servicios de cada capa.
– es conveniente poner la funcionalidad dependiente
de la aplicación en las capas superiores, y mantener
las inferiores genéricas y sencillas.
• Refinar las capas iterando sobre los 4 pasos
anteriores.
– reorganizar las tareas de modo que sólo se
invoquen servicios de la capa inmediatamente
anterior.
• Especificar la interfaz de cada capa.
– se incluyen todos los servicios ofrecidos en la
interfaz y la capa se trata como una caja negra.

20/06/2021
• Definir la estructura de cada capa.
– distintos patrones pueden usarse para la estructura
interna.
• Especificar la comunicación entre las capas.
– push, pull, llamadas a procedimientos, RPCs,
mensajes.
• Desacoplar capas adyacentes.
– la capa J no debe saber quien usa sus servicios.
• Diseñar una estrategia de manejo de errores.
– los errores deben manejarse en la capa más baja
posible.

20/06/2021
Ejemplo: FTP de UNIX
FTP
TCP
IP
Ethernet
FTP
TCP
IP
Ethernet
Protocolo FTP
Protocolo TCP
Protocolo IP
Protocolo Ethernet
Conexión Física
Cada protocolo
virtual es estricto.

20/06/2021
Variantes
• Layers relajados:
– cada capa puede acceder a servicios en
cualquier capa inferior;
– capas parcialmente opacas;
– performance versus facilidad de
mantenimiento.
Otras Aplicaciones
• Máquinas Virtuales.
• APIs.
• Sistemas de Información.

20/06/2021
Layers: Consecuencias
• Beneficios:
– reutilización de niveles,
– soporte para la
estandarización,
– los cambios en el
código son locales a
cada nivel.
• Desventajas:
– ineficiencia
– excesivo trabajo,
– difícil establecer la correcta granularidad
de los niveles:
• pocos niveles no explotan el potencial
de reuso, portabilidad e
intercambiabilidad,
• muchos niveles crean complejidad e
ineficiencia.

20/06/2021
Arquitectura en capas
• Ventajas
– Modularidad (hasta cierto punto)
• Desventajas
– Es difícil razonar a priori sobre la separación en capas requerida
– Capas disjuntas requieren drivers de otras capas
– Formatos, protocolos y transportes de la comunicación entre
capas suelen ser específicos y propietarios
– Algunos componentes pueden estar lógicamente vinculados con
más de una capa
– En ocasiones, hay que pasar por encima de capas intermedias
– Otras veces, razones de performance hace que se sitúen
funciones en las capas indebidas (lógica de negocios en
procedimientos almacenados)
– La multiplicación de capas genera procesos adicionales de
comunicación y coordinación

20/06/2021
Arquitecturas de 2/3 Capas… para Web
3-Tiers Architecture
2-Tiers Architecture

20/06/2021
Ejemplo: Arquitectura de cuatro capas
• La capa inferior incluye software de soporte al sistema, por lo
general soporte de base de datos y sistema operativo.
• La siguiente capa es la de aplicación, que comprende los
componentes relacionados con la funcionalidad de la
aplicación, así como los componentes de utilidad que usan
otros componentes de aplicación.

20/06/2021
Ejemplo: Arquitectura de cuatro capas
• La tercera capa se relaciona con la gestión de interfaz del usuario y
con brindar autenticación y autorización al usuario.
• La capa superior proporciona facilidades de interfaz de usuario.
Desde luego, es arbitrario el número de capas.
• Cualquiera de las capas en la figura podría dividirse en dos o más
capas.

20/06/2021
Arquitectura de 5 Capas… para Web

20/06/2021
Data Access Interface (DAI)
Una alternativa para implementar la DAI:

20/06/2021
Patrones Simples
(filtros).

20/06/2021
Máquina virtual
• Simulan funcionalidades no nativas a hardware
o software
• Un intérprete posee por lo general cuatro
componentes:
– una máquina de interpretación que lleva a cabo la
tarea,
– una memoria que contiene el pseudocódigo a
interpretar,
– una representación del estado de control de la
máquina de interpretación, y
– una representación del estado actual del programa
que se simula.
Interpretador + programa en lenguaje de propósito especial

20/06/2021
Máquina virtual

20/06/2021
Máquinas Virtuales para simular hardware
• Permiten a la máquina física multiplicarse en varias
máquinas virtuales.
– Cada una ejecutando su propio sistema operativo.
• A la capa de software que permite la virtualización se le
llama monitor de máquina virtual o "hypervisor".
• Un monitor de máquina virtual puede ejecutarse o bien
directamente sobre el hardware o bien sobre un sistema
operativo ("host operating system").

20/06/2021
Máquinas Virtuales a nivel de software
• No fueron creadas con Java
• Existen desde 1950
– Máquina universal de bytecodes (UNCOL)
– 1968, Alan Kay: MV ligada a objetos
– 1972: Kay-Ingalls, MV de Smalltalk
– Scripting & lenguajes: Perl, Javascript, Windows
Script Host (WSH), Python, PHP, Pascal , Visual
Basic, Tcl/Tk
– CLR: máquina virtual independiente de lenguaje

20/06/2021
Máquina virtual
• Ventaja: simulación
• Desventaja: especificidad
• Ejemplos o demos:
– Lenguaje declarativo en framework procedimental.
– Uso del runtime como intérprete (previa compilación
a otro lenguaje o MSIL).
– Runtime universal como MV para cualquier
paradigma de lenguaje o scripting

20/06/2021
Patrones Simples
(filtros).

20/06/2021
Pipes y Filtros
El patrón de arquitectura de pipes y filtros
provee una estructura para procesar flujos de
datos. Cada paso de procesamiento se
encapsula en un filtro. Los datos se pasan
usando los “pipes” entre filtros adyacentes.
Recombinando los filtros pueden construirse
distintas familias de sistemas relacionados.

20/06/2021
Ejemplo: Compilador Portable de
MOCHA
• MOCHA: Modular Object
Computation with
Hypothetical Algorithms.
• AuLait: Another Universal
Language for Intermediate
Translation.
• CUP: Concurrent Uniform
Processor.
• AuLait corre en la máquina
virtual CUP.
Análisis
Lexicográfico
Análisis
Sintáctico/Parsing
Análisis
Semántico
Generación de
Código Intermedio
Optimización
Intel
MIPS SPARC Intérprete
texto ASCII (programa)
secuencia de tokens
árbol sintáctico abstracto
programa AuLait
árbol sintáctico aumentado
programa AuLait optimizado

20/06/2021
Pipes y Filtros: Contexto
• Procesamiento de flujos de datos.
• La funcionalidad del sistema debe ser
descompuesto en una serie de actividades.
• Las actividades transforman uno o más flujos de
datos de entrada, en uno o más flujos de datos de
salida en forma incremental.
• Cada actividad es un filtro.
• Los filtros se comunican solamente a través de
pipes:
– operación del sistema operativo que envía una
secuencia de datos de un proceso a otro.
Pipes y Filtros: Problema

20/06/2021
• El sistema es una secuencia de
transformaciones de los datos.
• Las transformaciones son:
– bien ordenadas,
– sin estado interno,
– independientes.

20/06/2021
• Fuerzas:
– es posible implementar cambios
intercambiando algunos filtros;
– pequeñas transformaciones son más
fácilmente reutilizadas;
– los datos pueden tener diferentes
formatos.

20/06/2021
Pipes y Filtros: Solución
• Involucra 4 elementos (según Mary
Shaw):
– Modelo de sistema: flujo de datos
entre componentes;
– Componentes: filtros (transformaciones,
procesamiento local, asíncrono);
– Conectores: pipes (streams);
– Estructura de control: flujo de datos.

20/06/2021
Pipes y Filtros: Solución
• Según Buschmann:
– el sistema se divide en varios pasos
secuenciales de procesamiento;
– los pasos se conectan con flujos de datos;
– cada filtro consume y procesa sus datos en
forma incremental;
– el origen de los datos, el destino y los filtros
se conectan con “pipes” que implementan el
flujo de datos entre los pasos de
procesamiento.

20/06/2021
Pipes y Filtros: Estructura
• Filtros:
– unidades de procesamiento;
– enriquece, refina y/o transforma datos;
– el procesamiento se inicia:
• el elemento siguiente solicita datos (pull),
• el elemento anterior envía datos (push),
• el filtro tiene un ciclo interno que solicita datos del filtro
anterior y envía datos al siguiente (filtro activo);
– los filtros no comparten estado;
– los filtros no saben de la existencia o identidad de
otros filtros.

20/06/2021
Pipes y Filtros: Estructura
• Pipes:
– conecta origen-filtro, filtro-filtro, y filtro-
destino;
– transferencia de datos con un buffer First-
In-First-Out.

20/06/2021
Pipes y Filtros: Dinámica
• Escenario 1: Push Pipeline.
– La acción se inicia “empujando” los datos
hacia el siguiente filtro.
Fuente de Datos
push
Filtro 1
push
Filtro 2
push
Destino de Datos
data
data
data
f1
f2

20/06/2021
Pipes y Filtros: Dinámica
• Escenario 2: Push/Pull Pipeline:
– origen y destino de datos pasivos,
– el filtro 2 juega el rol activo iniciando el proceso.
Fuente de Datos
Filtro 1
pull
Filtro 2
pull/push
Destino de Datos
data
data
data
f1
f2
read
write
read

20/06/2021
Pipes y Filtros: Implementación
• Dividir las tareas en una
secuencia de pasos de
procesamiento:
– los procesos deben ser
independientes y
ordenados.
• Definir el formato de los
datos transmitidos a través
de cada pipe:
– flexibilidad vs.
performance.
• Decidir implementación de
cada pipe:
– determina la
implementación de los
filtros (activo o pasivo).
• Diseñar e implementar
filtros.
• Diseñar política de errores.
• Instalar el sistema.

20/06/2021
Ejemplo: Compilador MOCHA
• Los sucesivos filtros
comparten un cierto
estado: la tabla de
símbolos.
• No es una
arquitectura Pipes y
Filtros estricta.
• La implementación
es un único
programa.
Analizador
Lexicográfico
Analizador
Sintáctico/Parser
Analizador
Semántico
Generador de
Código Intermedio
Tabla
de
Símbolos

20/06/2021
Pipes y Filtros: Consecuencias
• Beneficios:
– los archivos intermedios
no son necesarios,
– flexibilidad,
– reutilización de filtros,
– rápida prototipación,
– eficiencia con
procesamiento paralelo.
• Desventajas:
– compartir información de
estado es caro y poco
flexible,
– ineficiencia por
conversión de datos,
– errores pueden implicar
reiniciar el sistema.

20/06/2021
Tubería y filtros
• Ventajas:
– Es simple de entender e implementar. Es posible
implementar procesos complejos con editores
gráficos de líneas de tuberías o con comandos de
línea.
– Lineal: la conducta del sistema es la suma de la
conducta de los sucesivos filtros
– Fuerza un procesamiento secuencial.
– Es fácil de envolver (wrap) en una transacción
atómica.
– Los filtros se pueden empaquetar, y hacer paralelos o
distribuidos.

20/06/2021
Tubería y filtros
• Desventajas:
• El patrón puede resultar demasiado simplista,
especialmente para orquestación de servicios que
podrían ramificar la ejecución de la lógica de
negocios de formas complicadas.
• No maneja con demasiada eficiencia construcciones
condicionales, bucles y otras lógicas de control de
flujo. Agregar un paso suplementario afecta la
performance de cada ejecución de la tubería.
• No es posible que 2 o más filtros cooperen
• Eventualmente pueden llegar a requerirse buffers de
tamaño indefinido, por ejemplo en las tuberías de
clasificación de datos.

20/06/2021
Tubería-Filtros
• Desventajas
– No es apto para manejar situaciones interactivas,
sobre todo cuando se requieren actualizaciones
incrementales de la representación en pantalla.
– La independencia de los filtros implica que es muy
posible la duplicación de funciones de preparación
que son efectuadas por otros filtros (p. ej. el
control de corrección de un objeto de fecha).
– Es complicado manejar uniformemente gestión de
errores en filtros diferentes.
– Generalmente fuerzan mínimo común
denominador en representación de datos (texto
ASCII). Si se deben procesar datos tokenizados
de otra manera, se requieren parsers y
serializadores específicos.

20/06/2021
Patrones Simples
(filtros).

20/06/2021
Pizarrón
El patrón de arquitectura de pizarrón es útil para
problemas en que no se conoce una estrategia
determinística para calcular la solución. Varios
subsistemas especializados reunen su
conocimiento para construir una solución parcial
aproximada.
Variantes del Patrón: REPOSITORIO y CLIENTE-SERVIDOR

20/06/2021
Ejemplos
• Visión artificial,
reconocimiento
de imágenes y
voz.
• Inteligencia
artificial.
• Sistemas
colaborativos de
apoyo a la toma
de decisiones.
Pizarron
(datos compartidos)
bc1
bc2
bc3
bc7
bc6
bc5
bc4
cómputo
memoria
acceso
directo

20/06/2021
Pizarrón: Contexto
• Un dominio inmaduro en el cual no
existe una solución conocida o factible
de antemano.

20/06/2021
Pizarrón: Problema
• La descomposición del problema
abarca muchas áreas de especialidad.
• Cada solución parcial requiere distintas
representaciones y paradigmas.
• El conocimiento es incierto o
aproximado.

20/06/2021
Pizarrón: Problema
• Fuerzas:
– una búsqueda exhaustiva de soluciones no es
factible,
– los módulos deben ser intercambiables porque
ninguno es seguro que obtenga la mejor solución,
– existen algoritmos que obtienen soluciones
parciales,
– input, output y algoritmos usan datos con
diferentes representaciones,
– algunos algoritmos usan los resultados de los
otros.

20/06/2021
Pizarrón: Solución
• Colección de programas
independientes que trabajan
colaborativamente sobre
datos compartidos.
• Cada programa se
especializa en resolver parte
del problema.
• Los programas no se
comunican directamente sino
a través de los datos.
• Existe un control central que
coordina los programas
dependiendo del estado de
los datos (moderador):
resolución oportuna de
problemas.
• Se experimenta con
soluciones parciales, se las
combina y se las desecha.
• Los programas también
pueden tomar iniciativa e
interactuar con los datos.

20/06/2021
Variantes de Patrón Pizarra
• Variante repositorio
– Base de datos o almacenamiento persistente
– Es pasivo
– Los clientes accesan a datos compartidos cuando lo
requieren
• Variante pizarra propiamente dicha
– Es activo
– Pueden enviar notificación a suscriptores cuando la
información cambia
– El estado es el disparador de la acción a ejecutar

20/06/2021
Pizarrón: Estructura
• Pizarrón:
– almacenamiento central de
información,
– vocabulario: conjunto de
todos los datos que
aparecen en el pizarrón.
• Bases de Conocimiento:
– subsistemas independientes
especializados,
– escriben y leen del pizarrón,
– parte de diagnóstico y parte
de acción.
• Control:
– monitorea el estado del
sistema y decide la
próxima acción,
– las decisiones se basan
en el progreso o costo
del conocimiento,
– detecta estados finales
aceptables e insolubles.

20/06/2021
Patrones Simples
(filtros).

20/06/2021
Repositorio (Modelo de Depósito)
• Los subsistemas que componen un sistema
deben intercambiar información con el fin de
que puedan trabajar de forma conjunta y
efectiva.
• Existen dos formas:
– Todos los datos compartidos se ubican en una
base de datos central que pueda ser accedida
por todos los subsistemas (se denomina modelo
de deposito).
– Cada subsistema tiene su propia base de datos.
Los datos se intercambian con otros subsistemas
pasando mensajes entre ellos.

20/06/2021
Repositorio
• Ejemplo: Compilador implementado sobre
repositorio compartido

20/06/2021
Repositorio
• Ventajas
– Forma adecuada de manejar grandes volúmenes de
datos
– Administración centralizada
• Desventajas
– Los subsistemas tienen que estar de acuerdo en el
modelo de datos del repositorio
– La evolución de los datos es difícil y cara
– Difícil de distribuir con facilidad

20/06/2021
Patrones para
Sistemas
Interactivos
0
5
10
15
20
25
30
35
Food Gas Motel
Jan
Food Gas Motel
Jan
Feb
Mar
Apr
May
Jun
0
5
10
15
20
25
30

20/06/2021
Patrones para Sistemas Interactivos
– Modelo dirigido por eventos: se rigen por
eventos generados en el exterior.
– Modelo-View-Controlador: divide a una
aplicación interactiva en tres componentes:
modelo, vistas y controladores.
– Presentación-Abstracción-Control: define al
sistema como una jerarquía de agentes que
coorperan entre sí para implementar la
funcionalidad de la aplicación.

20/06/2021
Arquitectura basada en eventos
• Modelo de push a veces se vincula con
patrón Observador (Observer pattern)

20/06/2021
• Ventajas
– Simplicidad
– Evolución: se pueden reemplazar componentes suscriptores
– Modularidad: una sola modalidad para eventos diversos
– Puede mejorar eficiencia, eliminando la necesidad de polling
por ocurrencia de evento
• Desventajas
– Posibilidad de desborde
– Potencial imprevisión de escalabilidad
– Pobre comprensibilidad: Puede ser difícil prever qué pasará
en respuesta a una acción
– No hay garantía del lado del publisher que el suscriptor
responderá al evento
– No hay mucho soporte de recuperación en caso de falla
parcial

20/06/2021
• Dos modelos de arquitectura e implementación
• Tightly coupled events (TCE, eventos fuertemente acoplados)
– P. ej. COM Connection Points.
– Requiere que ambos componentes estén corriendo
simultáneamente. No hay forma de filtrar evento (p. ej. cuando
acción alcance cierto valor)
– Requiere conocer ambas interfaces específicas
• Losely coupled events (LCE, eventos débilmente acoplados)
– P. ej. COM+ Events
– Almacenamiento de eventos (COM+ Catalog)
– Referencia: MSDN Library – COM+ Technical Series: Losely
coupled events

20/06/2021
• Permiten invocación implícita de una herramienta
cuando otra herramienta produce un evento
• También se llama Invocación implícita
– Un componente anuncia un evento. Otros registran interés en
ese tipo de evento. Cuando se produce, el sistema (la “mano
invisible”) lo comunica a los suscriptores.
• Algunos incluyen a MVC en esta clase
• Modelo Publish / Subscribe
• MS: Registración de Eventos COM+, eventos (listeners)
de BizTalk Server, Notification Service de SQL Server

20/06/2021
• Herramientas en ambiente COM+/.NET
• En muchos casos no se requiere programación
de bajo nivel
• También hay profusión de herramientas
programáticas y servicios de “mano mágica”
• Administrative tools
– Component Services
• COM+ Applications
– .NET Utilities, Biztalk Server/Interchange

20/06/2021
Código VB.NET
Crea interface de evento ILceMsg, event class, event sink & Publisher
Imports System
Imports System.IO
Imports System.Reflection
Imports System.EnterpriseServices
Imports System.Runtime.InteropServices
<assembly: ApplicationName("EventDemo")>
<assembly: ApplicationActivation(ActivationOption.Library)>
<assembly: AssemblyKeyFile("EventDemoSvr.snk")>
Namespace EventDemo
Public Interface ILceMsg
Sub EventMethod(message As String)
End Interface
<EventClass()> _
Public Class LceClass
Inherits ServicedComponent Implements ILceMsg
Public Sub EventMethod(message As String) implements _
ILceMsg.EventMethod
End Sub
End Class
Public Class LceSink
Inherits ServicedComponent Implements ILceMsg
Public Sub EventMethod(message As String) implements _
ILceMsg.EventMethod
MessageBox.Show(message, "Event sink")
End Sub
End Class
End Namespace

20/06/2021
Código VB.NET
Publisher
Protected Sub Fire_Click(sender As Object, e
As System.EventArgs)_
Handles fireEvent.Click
Dim evt As ILceMsg = CType(New
LceClass(), ILceMsg)
evt.EventMethod("Hello events")
End Sub

20/06/2021

20/06/2021
Modelo-View-Controlador
El patrón de arquitectura de modelo-view-controlador (MVC)
divide una aplicación interactiva en tres partes.
• El modelo contiene los datos y la funcionalidad esencial.
• Las views despliegan la información al usuario.
• Los controladores manejan el input.
Las views y los controladores juntos componen la interfaz con
el usuario. El mecanismo de cambio-propagación asegura la
consistencia de la interfaz con el modelo.

20/06/2021
Modelo-Vista-Control (MVC)
• Utilizado para construir interfaces de usuario en Smalltalk-80.
• Basado en tres tipos de objetos:
– Modelo: objeto aplicación. Encapsula el
núcleo funcional y los datos involucrados.
– Vistas: presentación de información por
pantalla (al usuario).
– Controlador: define la forma en la que debe
reaccionar la interfaz del usuario, frente a la
entrada de datos (del usuario).
• Desacopla el modelo de las vistas.
• Hace a los sistemas más mantenibles, flexibles y adaptables.

20/06/2021
Ejemplo: Sistema de Información
• Sistema de elecciones
políticas.
• Los usuarios votan a
través de una interfaz
gráfica.
• La información se
muestra con distintos
formatos.
• Los cambios por
votación deben
reflejarse en forma
inmediata.
• Debe poderse integrar otras formas de
presentación de los resultados tales como la
distribución de candidatos en el parlamento.
• Las presentaciones deben ser portables.
Negro: 43%
Rojo: 39%
Azul: 6%
Verde: 10%
Otro: 2%
0
10
20
30
40
50
Negro Rojo Azul Verde Ot ro
Negro 43
Rojo 39
Azul 6
Verde 10
Otro 2

20/06/2021
Contexto: Aplicaciones interactivas con
interfaces humano-computador
cambiantes y flexibles.
Problema:
– Las interfaces de usuario son muy
frecuentemente cambiadas.
– Cambios en la funcionalidad deben
reflejarse en las interfaces.
– Puede haber interfaces a medida para
ciertos usuarios.
– Diferentes paradigmas de interfaz:
• digitar información,
• seleccionar íconos.
– Construir un sistema monolítico es caro y
difícil.

20/06/2021
Fuerzas:
– la misma información se presenta de
distintas formas,
– cambios en los datos deben reflejarse en
la interfaz inmediatamente,
– las interfaces deben modificarse
fácilmente, ojalá durante la ejecución,
– distintas interfaces portables no deben
afectar la operación esencial.

20/06/2021
Solución:
• MVC divide la aplicación en
procesamiento, input y
output.
• El modelo representa la
funcionalidad y los datos
esenciales, y es
independiente de la
representación en las
interfaces.
• La view obtiene datos del
modelo y los despliega para
el usuario.
• Cada view tiene asociada un
controlador. El controlador
recibe eventos como input
(movimientos del mouse,
activación de botones) y los
traduce a solicitudes de
servicios del modelo o la
view.
• El usuario interactúa con el
modelo solamente a través
de controladores.

20/06/2021
Modelo-Vista-Controlador
• Modelo.
– Administra el comportamiento y los datos del dominio de
aplicación, responde a requerimientos de información sobre su
estado (usualmente formulados desde la vista) y responde a
instrucciones de cambiar el estado (habitualmente desde el
controlador). Mantiene el conocimiento del sistema. No depende
de ninguna vista y de ningún controlador.
• Vista.
– Maneja la visualización de la información.
• Controlador.
– Interpreta las acciones del ratón y el teclado, informando al
modelo y/o a la vista para que cambien según resulte apropiado.

20/06/2021
Estructura:
• Modelo
– encapsula la información
esencial y exporta
procedimientos que realizan
procesamiento específico de
la aplicación;
– provee funciones para que las
views accedan a la
información;
– el mecanismo de cambio-
propagación mantiene
informados a las views y a los
controladores dependientes.
• View
– despliega los datos para
el usuario;
– tienen procedimientos de
actualización para recibir
nuevos datos.
• Controlador
– existe un controlador
para cada view;
– recibe los inputs de una
view como eventos y los
interpreta.

20/06/2021
Variantes del Modelo-Vista-Controlador
• Variante pasiva
– Un controlador manipula el modelo exclusivamente. Luego
informa a la vista que el modelo ha cambiado y debe
refrescar los cambios. No hay forma en que el modelo
notifique sus cambios.
– Ejemplo: HTTP. El browser responde al input del usuario,
pero no se notifica de los cambios en el servidor. Sólo
cuando se pide un refresco se pueden refrescar los
cambios.
• Variante activa
– El modelo cambia sin intervención del controlador.
Ejemplos:
• Display de cotizaciones de bolsa. El modelo detecta los
cambios en su estado y notifica a la vista para que refresque.
• Cambio de los menús visibles de acuerdo con el estado del
modelo.
• Variante Documento-Vista
– En aplicaciones gráficas, se relaja la distinción entre vista y
controlador.

20/06/2021
MVC - Clases (1)
Clase: Model
Colaboradores:
• View
• Controller
Responsabilidad:
• Proporciona el núcleo de funcionalidad
de la aplicación
• Registra los View y Controller
dependientes
• Notifica a los componentes
dependientes acerca de cambios en los
datos
•Encapsula los datos, proporciona métodos de acceso para las vistas
•“Controllers” invocan los métodos exportados para el procesamiento de
la aplicación
•El patrón “Observer” se puede usar para propagar los cambios

20/06/2021
MVC - Clases (2)
Clase: View
Colaboradores:
• Controller
• Model
Responsabilidad:
• Crea e inicializa su Controller asociado
• Obtiene datos de Model
• Despliega información al usuario
• Implementa el procedimiento update
• Cada View crea un Controller adecuado (uno a uno)
• Ofrece interfaces que habilitan a Controller para algunas
manipulaciones de despliegue que no afectan el modelo (p.e. scroll)

20/06/2021
MVC - Clases (3)
Clase: Controller
Colaboradores:
• View
• Model
Responsabilidad:
• Acepta entradas del usuario como
eventos
• Traduce eventos en solicitudes de
servicio para Model o View
• Si se precisa, implementa el
procedimiento update
• EL procedimiento update se implementa en caso de que el
comportamiento de Controller depende del estado de Model (p.e. un
cambio del modelo habilita o deshabilita un menú)

20/06/2021
MVC: Estructura del Ejemplo
• El modelo guarda los
votos acumulados para
cada partido político y
permite que las views
accedan a los números de
votos.
• Hay varias views: gráfico
de barras, de torta o tabla.
Torta
Controlador_Tr
Barras
Controlador_Ba
Tabla
Controlador_Tb
Base de votos

20/06/2021
MVC: Dinámica
• Escenario I: Input del usuario cambia el modelo
y gatilla el mecanismo de cambio-propagación.
Controlador Modelo View
evento servicio notificación
actualizar
desplegar
obtener datos
actualizar
obtener datos

20/06/2021
Implementación:
• Separar la funcionalidad
esencial de la interacción
humano-computador.
• Implementar el mecanismo
de cambio-propagación.
• Diseñar e implementar las
views.
• Diseñar e implementar los
controladores.
• Diseñar e implementar la
relación entre views y
controladores.
• Implementar:
– La inicialización del MVC
completo,
– La creación de dinámica de
views,
– La controladores que
capturan diferentes eventos,
– La infraestructura jerárquica
para views y controladores,
– La más desacoplamiento
de las dependencias del
sistema.

20/06/2021
Consecuencias:
• Beneficios:
– múltiples views para el
mismo modelo,
– views sincronizadas,
– views y controladores
intercambiables.
• Desventajas:
– mayor complejidad,
– excesivos cambios
potenciales,
– relación estrecha entre views
y controladores,
– gran acoplamiento entre
views y controladores con el
modelo,
– ineficiencia en el acceso a
los datos desde la view,
– cambios inevitables a las
views y controladores al
portarlos,
– difícil usar MVC con
herramientas gráficas
modernas.

20/06/2021
MVC: Ventajas y desventajas
• Ventajas
– Se pueden mostrar distintas variantes de display
simultáneamente, porque la vista no depende del modelo (ni el
modelo de la vista)
– La interface tiende a cambiar más rápido que las reglas de
negocios. Agregar nuevos tipos de vista no afecta al modelo.
• Desventajas
– Puede aumentar un poco la complejidad de la solución. Como
está guiado por eventos, puede ser algo más difícil de depurar.
– Si hay demasiados cambios en el modelo, la vista puede caer
bajo un diluvio de refrescos, a menos que se prevea
programáticamente (por ejemplo, actualizando varias
modificaciones en lotes)

20/06/2021
Modelo-Vista-Control
• Utiliza los siguientes patrones:
– Observer
– Composite
– Strategy
– Decorator
– Factory method
• ... Todos ellos son patrones de diseño.

20/06/2021
Ejemplo de arquitectura

20/06/2021

20/06/2021
Presentación-Abstracción-Control
(PAC)
El patrón de arquitectura PAC define una
estructura jerárquica de agentes cooperativos.
Cada agente es responsable de un aspecto
específico de la funcionalidad de la aplicación y
está compuesto por tres componentes:
presentación-abstracción-control. Esta subdivisión
separa los aspectos de HCI de los agentes, del
núcleo funcional de cada uno y de los mecanismos
de comunicación con otros agentes.

20/06/2021
Presentación-Abstracción-Control (PAC)
Ejemplo: Consideremos un Sist. de Información Electoral.
- Ofrece una hoja de cálculo para el ingreso de datos
- Ofrece varios tipos de tablas y de gráficos para representar los
distintos resúmenes de la información almacenada.
- Los usuarios interactúan con el software a través de la interfaz
gráfica.
0
10
20
30
40
50
60
70
80
90
1er
trim.
2do
trim.
3er
trim.
4to
trim.
Este
Oeste
Norte
1tr
3tr
4tr
2tr
1tr. 2tr. 3tr. 4tr.
Este 20 25 90 20
Oeste 30 38 32 32
Norte 47 47 45 45
Usuario Hoja de Cálculo

20/06/2021
Presentación-Abstracción-Control (PAC)
Ejemplo (cont.):
- Diferentes versiones, adaptan la interfaz de usuario a necesidades
específicas, por ej., para ver las bancas del parlamento en función
de los partidos políticos.
Contexto: Desarrollo de sistemas interactivos con la
ayuda de agentes.
Problema: Cómo organizar el conjunto de agentes que
forman parte de un sistema interactivo, para que
funcionen en forma integrada.

20/06/2021
Fuerzas:
- Los agentes normalmente mantienen su estado y sus
datos, sin embargo tienen que cooperar y trabajar en
conjunto.
- Los agentes proveen su propia interfaz de usuario pues
cada uno tiene una cierta interacción prevista con el
usuario. Sin embargo, las modalidades de interacción
deben ser similares para que la HCI del producto sea
homogénea.
- Separar la presentación, de la funcionalidad, para que los
cambios en la interfaz no afecten demasiado al resto del
sistema. De todos modos la presentación y la funcionalidad
deben tener parámetros de acoplamiento aceptables.

20/06/2021
Solución:
- Organizar la estructura del sistema, jerárquicamente, según 3
niveles de agentes: alto nivel, intermedio y bajo nivel.
- Los agentes de alto nivel proveen el núcleo de la
funcionalidad del sistema. Este tipo de agente es quien coordina
y estructura la funcionalidad del sistema (menúes, barras de
herramientas, etc).
- Los agentes de bajo nivel representan conceptos
autocontenidos, sobre los cuales los usuarios del sistema
actúan. Típicamente estos agentes soportan las operaciones de
los usuarios.
- Los agentes intermedios representan combinaciones o
relaciones entre agentes de bajo nivel. Por ejemplo, este tipo de
agentes puede representar diversas vistas sobre los datos.

20/06/2021
Solución:
- Ejemplo: veamos un sistema de información electoral.
Repositorio
Acceso a Datos
Controlador
de Vistas
Hoja de
Cálculo
Gráfico
Torta
Gráfico
Líneas
Gráfico
Barras
Alto nivel
Intermedio

20/06/2021
Solución:
- Cada uno de los agentes es responsable de una parte de la
funcionalidad de la aplicación y contiene 3 componentes:
presentación, abstracción y control.
- La presentación provee el aspecto visible del agente.
- La abstracción provee el modelo de datos del agente y las
operaciones para operar con estos datos.
- El control conecta los componentes de presentación y de
abstracción, y le agrega la funcionalidad necesaria para
comunicarse con otros agentes.

20/06/2021
Estructura: cada agente representado en la jerarquía
tiene la siguiente estructura.
Controlador de Vistas
Control
InteractionData
SendMsg
ReceiveMsg
GetData
PresentationData
Update
Open
Close
Zoom
Print
BarData
SetChartData
GetChartData
Presentation
Abstraction
Agente Graficador de Barras

20/06/2021
Dinámica: para cada escenario que sea representativo, es
necesario definir la dinámica de las clases que forman
parte de la estructura. Definir al menos un par de
escenarios.
Consecuencias:
- Beneficios: Separación de conceptos, soporte para el
cambio y la extensión, soporte multitarea.
- Complicaciones: Incrementa la complejidad del sistema,
presenta problemas de eficiencia y de aplicabilidad,
involucran componentes de control complejos.

20/06/2021
Patrones para
Sistemas
Adaptables
Patrones
Arquitectónicos

20/06/2021
Patrones para Sistemas Adaptables
– MicroKernel: Es usado en sistemas de software
que deben adaptarse a los cambios en los
requisitos. Este separa el núcleo funcional, la
funcionalidad extendida y los aspectos relativos al
cliente.
– Reflexion: Provee un mecanismo para cambiar la
estructura y el comportamiento de un sistema de
software, en forma dinámica. Este patrón divide a
una aplicación en dos partes: un meta nivel que
provee información acerca de las propiedades del
subsistema seleccionado, y un nivel base que
provee la lógica de la aplicación.

20/06/2021
MicroKernel
• Ejemplos de sistemas MicroKernel son los sistemas operativos:
NextSTEP, UNIX System V, MS Windows, OS/2 Warp.
Contexto: Desarrollo de aplicaciones que utilizan interfaces de
programación similares, sobre las cuales construye un núcleo de
funcionalidad similar.
Problema: El desarrollo de software de dominio específico es una
tarea no trivial (Sist. Operativos, GUIs, etc). Los tiempos de vida
de estos sistemas son largos, y tienen que incorporar los cambios
tecnológicos con el menor costos (y tiempo) posible.
Fuerzas:
- La plataforma de la aplicación debe contemplar los cambios
tecnológicos tanto en hardware como en software. Sin embargo,
considerar todas las posibilidades podría elevar el costo
innecesariamente.
- La plataforma de la aplicación debe ser portable, extensible y
adaptable, para permitir la integración de las tecnologías
emergentes. Estas tecnologías pueden ser actuales o futuras.

20/06/2021
MicroKernel
Solución:
- Encapsular los servicios fundamentales de la
plataforma de aplicación, en un componente
microkernel. El microkernel incluye la
funcionalidad que permite a otros
componentes, ejecutar en forma separada
(como proceso) y comunicarse entre ellos. Este
es conocido como internal server.
- Encapsular los servicios periféricos al núcleo
en subsistemas que agrupan servicio similares.
Estos son conocidos como external servers.
- Los clientes se comunican con los external
servers usando las facilidades de
comunicación provistas por el microkernel.

20/06/2021
MicroKernel
Estructura:
MicroKernel
Internal Server
External Server
Adapter Client
doTask
executeService
receiveRequest
executeMechanism
initComunication
findReceiver
createHandle
sendMsg
callInternalServer
callService
createRequest
receiveRequest
dispatchRequest
executeService
calls
sends
request
Calls service
activate

20/06/2021
MicroKernel
Dinámica: Idem a patrones anteriores.
Consecuencias:
- Beneficios: Portabilidad, flexibilidad,
escalabilidad, confiabilidad,
transparencia.
- Problemas: Performance, Complejidad
del diseño e implementación.

20/06/2021
Patrones para Sistemas Adaptables
– MicroKernel: Es usado en sistemas de software
que deben adaptarse a los cambios en los
requisitos. Este separa el núcleo funcional, la
funcionalidad extendida y los aspectos relativos al
cliente.
– Reflection: Provee un mecanismo para cambiar
la estructura y el comportamiento de un sistema
de software, en forma dinámica. Este patrón
divide a una aplicación en dos partes: un meta
nivel que provee información acerca de las
propiedades del subsistema seleccionado, y un
nivel base que provee la lógica de la aplicación.

20/06/2021
Reflection
Contexto: Desarrollo de aplicaciones que requieran
cambios constantemente. Sin necesidad de “desarmar” el
programa y volverlo a construir, es decir, poder agregar
nuevas capacidades al programa sin tener que reescribir o
cambiar extensamente toda la aplicación.
Problema: Una aplicación construida con software es
estática y hace lo mismo cada vez que se ejecuta. A
veces, sin embargo, desea poder reconfigurar la aplicación
fácilmente y hacerla adaptable.

20/06/2021
Reflection
Solución:
Hacer que el software sea autoconsciente.
Esta autoconciencia se puede logar a través de la
reflexión
Reflexión:
Capacidad de un programa para examinarse a sí mismo

20/06/2021
Elementos de su estructura:
Reflection

20/06/2021
Reflection
Nivel meta:
Proporciona una autorepresentación del software para
darle conocimiento de su propia estructura y
comportamiento, y consta de los llamados meta objetos.
Los meta objetos encapsulan y representan información
sobre el software.
Nivel base:
Define la lógica de la aplicación. Su implementación utiliza
los meta objetos para permanecer independientes de
aquellos aspectos que puedan cambiar.

20/06/2021
Reflection
MOP:
Permite a los clientes especificar cambios, como la
modificación de los mecanismos de llamada de función. El
protocolo de meta objetos en sí mismo es responsable de
verificar la exactitud de la especificación del cambio y de
realizar el cambio. Cada manipulación de meta objetos a
través del protocolo de meta objetos afecta el
comportamiento subsiguiente a nivel de base.

20/06/2021
Reflection
Estructura:
UserInterface
ComponentA
provides
Base Level
MOP
MetaobjectB
MetaobjectA
uses
Meta Level
retrieves
information
uses
modifies
access to
modifies
uses
uses
ComponentB

20/06/2021
Reflection
Beneficios:
• No es necesario modificar el software explícitamente
después de haber creado una aplicación adaptable que
utiliza Reflexión
• Los cambios en casi todas las escalas son posibles en
una aplicación que se construye alrededor del patrón
Reflexión
• El MOP hace que cambiar la aplicación sea seguro al
proporcionar una interfaz consistente para realizar la
adaptación

20/06/2021
Reflection
Consecuencias:
• Puede realizar cambios dañinos en la aplicación
mediante cambios incorrectos en el nivel meta .
• Las aplicaciones creadas en torno a la reflexión tienen
más componentes .
• Utilizar reflexión requiere un procesamiento adicional

20/06/2021
Patrón de Reflexión - Estructura
https://jarroba.com/reflection-en-java/

20/06/2021

20/06/2021
Patrón de Reflexión - Salida

20/06/2021
Recomendaciones
Generales

20/06/2021
Recomendaciones Generales
• Desempeño.
– Si el desempeño es un requisito crítico, la arquitectura debe
estar diseñada para albergar las operaciones críticas, dentro de
un número reducido de subsistemas (menos cambios de
contexto).
– Ojalá con poca comunicación entre ellos.
– Esto significa utilizar componentes de grano grueso, de esa
manera habrá menos componentes en el sistema.
• Seguridad.
– Si la seguridad es un requisito crítico, se debe utilizar una
arquitectura estratificada (por capas).
– Los recursos más críticos deben alojarse en las capas más
inferiores (internas).
– Cada capa debe proveer un mecanismo de validación, de
acuerdo a la información que ésta maneja.

20/06/2021
• Protección (de operaciones).
– Si la protección es un requisito crítico, la
arquitectura debe estar diseñada de tal forma que
las operaciones relacionadas con la protección, se
localicen en único subsistema o en un conjunto muy
reducido de estos.
– Esto reduce los costos y los problemas de
validación, y hace posible crear sistemas de
protección relacionados.
• Disponibilidad.
– Si la disponibilidad es un requisito crítico, como
parte de la arquitectura se deben incluir
componentes redundantes.
– Estos podrán reemplazar a los componentes con
problemas, en caso de fallas.

20/06/2021
• Mantenibilidad.
– Si la mantenibilidad es un requisito crítico, la
arquitectura debe estar diseñada utilizando
componentes autocontenidos de grano fino.
– Estos componentes pueden ser módulos o
componentes de software bien definidos.
– Estos podrán cambiarse o reemplazarse con
facilidad, y con un mínimo efecto sobre el resto del
sistema.
– Los productores de datos deben estar separados de
los consumidores.
– Las estructuras de datos compartidas deben
evitarse.
– La circulación de órdenes de control entre módulos
o subsistemas, también debe evitarse.

20/06/2021
Conclusiones
• Hay arquitecturas de son mejores que otras,
dependiendo del escenario de trabajo (dominio +
infraestructura previa), del tipo de software a
desarrollar, y de lo que se pretende obtener.
• Los patrones arquitectónicos brindan una
sugerencia (genérica) acerca de cómo resolver
algunos de los problemas arquitectónicos mas
comunes.
• Los patrones arquitectónicos no son la salvación
de nadie, pero generalmente ayudan….
• Se pueden utilizar mezclas de patrones, y
adaptaciones de ellos.

20/06/2021
de las capas).
Unidad 3A

20/06/2021
DISEÑO DETALLADO Y
EVALUACIÓN DEL DISEÑO
Unidad 3A
Material docente compilado por el profesor Ph.D. Franklin Parrales Bravo
para uso de los cursos de Diseño y Arquitectura de Software

DAS Unidad3A: DISEÑO DETALLADO Y EVALUACIÓN DEL DISEÑO

Recommended

Recommended

More Related Content

More from Franklin Parrales Bravo

More from Franklin Parrales Bravo (20)

Recently uploaded

Recently uploaded (20)

DAS Unidad3A: DISEÑO DETALLADO Y EVALUACIÓN DEL DISEÑO