sintesis

¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible

Interfaces Gráficos de Usuario

modeloVistaControlador

  • Trygve Reenskaug Smalltalk-80

  • Motivación

    • Proveer un interfaz de usuario con multiples vistas de datos como si estuviera trabajando con entidades del mundo real

¿Qué?

Modelo/Vista/Controlador

Participante Responsabilidad Colaboración

Modelo

  • manejar los datos y la funcionalidad del negocio

modeloVistaControlador
  • Propósito: Separar dominio de la aplicación, presentación y entrada de usuario

modeloVistaControladorSecuencia

Presentador del Modelo

  • manejar el Modelo con el que desea interactuar el usuario

Vista

  • presentar el Modelo y posibles acciones sobre éste circuncribiendose a la pantalla y controles de interfaz con los que interactúa el usuario. Posteriormene, redirigir las interacciones de los controles al Controlador

Controlador

  • actuar como puente entre las interacciones del usuario en la Vista con el teclado y el ratón y el resto de la aplicación. Consecuentemente, modificar oportunamente el Modelo a través del Presentador del Modelo

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad inherente

davidProyectoImplantacionDiseño

arbolMantenible

Interfaces Gráficos de Usuario

primerGUI

  • Frameworks: XWindows, Visual Basic, Swing, …​, DHTML?!?

evolucionGUI

Proceso de Desarrollo Software
  • Ivar Jacobson en Ericsson

    • Concepto de Caso de Uso

    • Metodología Objectory: trazabilidad de requisitos (casos de uso) con software (análisis/diseño de casos de uso)

    • Metodología Rational Unified Process con Grady Booch

vehicleUsecases

login

¿Cómo?

Modelo/Vista/Controlador

Evolución

  • Plataformas con controles de interfaz nativos del sistema operativo que atienden directamente las interacciones del usuario elevando eventos

modeloVistaControladorSSOOSecuencia
modeloVistaControladorSSOO
  • Baile de la Tríada

Mike Potel de Taligent Inc en 1991

Motivación

Propósito

  • Con la incorporación de la interacción de entrada en los controles de la interfaz nativos del sistema operativo, el Controlador se había quedado sin responsabilidad

  • Las pruebas unitarias no eran posibles en MVC porque la Vista asumía el estado, la lógica y la sincronizacion de la presentación que requería interacción para ejercitarla

  • El Presentador del Modelo adelgaza a la Vista asumiendo la lógica de presentación y el estado en mayor o menor grado; lo cual permite realizar pruebas unitarias sin intermediacion de la Vista

  • Separar dominio de la aplicación, interacción y la lógica de la presentación facilitando las pruebas del software de todo el sistema menos la fina capa de la vista achicada

modeloVistaControladorViejo
modeloVistaControladorNuevo
Participante Responsabilidad

Modelo

manejar los datos y la funcionalidad del negocio

Vista

manejar los controles de interfaz y minimizando el estado, lógica y sincronización de la presentación

Presentador

  • en mayor o menor grado,

    • el Estado de la presentación con variables para los campos a presentar por la vista, su activación, su visibilidad, …​

    • la Lógica de la presentación actualizando los campos a presentar por la vista, su activación, su visibilidad, …​

    • la Sincronización de la presentación actualizando en la Vista los campos a presentar por la Vista, su activación, su visibilidad

Modelo/Vista/Presentador con Presentador del Modelo

Autor

Martin Fowler

Fecha

Motivación

  • Realizar pruebas de unidad del Presentador hasta el punto de que se minimice el riesgo de no realizar pruebas de la Vista

    • Sin necesidad de un sustituto (mock, stub, …) de la Vista para realizar las pruebas de unidad del Presentador

Propósito

Desacoplar al Presentador de la Vista

mvpPM
mvpPMSecuencia
Participante Responsabilidad

Modelo

manejar los datos y la funcionalidad del negocio

Vista

manejar los controles de interfaz, la sincronización de la presentación pero eliminando el estado y la lógica de la presentación

Presentador

manejar la totalidad del estado y lógica de la presentación

Modelo/Vista/Vista-Modelo

Autor

Microsoft

Fecha

2004

Motivación

  • Reducir la codificación de la sincronización

Propósito

Incorporar el enlace de datos automático (data binding)

mvvm
mvvmSecuencia

Modelo/Vista/Presentador con Vista Pasiva

Autor

Martin Fowler

Fecha

Motivación

  • Realizar pruebas de unidad del Presentador exhauxtivamente hasta el punto de que se minimice el riesgo de no realizar pruebas de la Vista

    • Solo se requiere un sustituto (mock, stub, …) de la Vista para realizar las pruebas de unidad del Presentador

Propósito

Reducir la Vista a la minima expression sin lógica de presentación ni estado ni sincronización únicamente la gestión de controles de interfaz

mvpVP
mvpVPSecuencia
Participante Responsabilidad

Modelo

manejar los datos y la funcionalidad del negocio

Vista

manejar los controles de interfaz y eliminando el estado, lógica y sincronización de la presentación: Vista Pasiva

Presentador

manejar la totalidad del estado y lógica de la presentación

Modelo/Vista/Presentador con Controlador Supervisor

Autor

Martin Fowler

Fecha

Motivación

  • Realizar pruebas de unidad del Presentador exhauxtivamente hasta el punto de que se minimice el riesgo de no realizar pruebas de la Vista

    • Solo se requiere un sustituto (mock, stub, …) de la Vista para realizar las pruebas de unidad del Presentador

Propósito

Repartir, respecto a MVP-VP, el estado, la lógica y la sincronización entre la Vista, lo sencillo, y el Presentador, lo complejo

mvpSC
mvpSCSecuencia
Participante Responsabilidad

Modelo

manejar los datos y la funcionalidad del negocio

Vista

manejar los controles de interfaz y tareas sencillas e inmediatas de estado, lógica y sincronización de la presentación

Presentador

traeas complejas del estado, lógica y sincronización de la presentación

Resumen

Estilos Arquitectónicos

Modelo/Vista/Presentador con Presentador del Modelo

Modelo/Vista/Vista-Modelo

mvpPM2
mvvm2

Modelo/Vista/Presentador con Vista Pasiva

Modelo/Vista/Presentador con Controlador Supervisor

mvpVP2
mvpSC2

Diseño de la Arquitectura Software

Requisitos

Modelo del Dominio

Modelo de Casos de Uso

modeloMelany

casosUsoMelany

Prototipo de la Interfaz de Usuario Gráfcia/Consola/…​ del Usuario

Protocolo de la Interfaz de Comunicaciones con otros Sistemas que atacan al nuestro Sistema

interfazMelany

comunicacionesMelany

Análisis de la Arquitectura Software

  • Modelos, inspirándose en el vocabulario del Modelo del Dominio de Requisitos

  • Controladores/Servicios/…​, de cada Caso de Uso de Requisitos

  • Vistas Panel/Frame/Dialog/…​, de cada panel y sub-panel de la estructura del Prototipo de Interfaz Gráfica, Consola, …​ de Usuario de Requisitos

  • Vistas Despachadoras/Resource/Port/…​, de cada trama y sub-trama de la estructura del Protocolo de la Interfaz de Comunicaciones de Requisitos

clasesMelany

colaboracionMelany

Diseño de la Arquitectura Software

Comprensión profunda sobre los aspectos de los requisitos no funcionales y limitaciones relacionadas con:

  • sistemas operativos,

  • reutilización de componentes,

  • tecnologías de distribución y concurrencia,

  • tecnologías de gestión de transacciones,

  • tecnologías de bases de datos,

  • tecnologías de interfaz de usuario,

  • lenguajes de programación,

  • y así sucesivamente

melany

analisisDiseño

analisisDisenyoRUP

planProjectSequenceDiagram

Frameworks

Web con Múltiples páginas con MVC

  • Java Enterprise Edition, estilo arquitectónico Modelo/Vista/Controlador-Smalltalk V, donde la interacción del usuario la atiende el servidor web que retransmite al controlador:

    • El Servlet-Controlador

      • Recibe atiende la petición (Request-Evento) producto de la interacción del usuario con la vista

      • Opera sobre los Beans-Modelos

      • Selecciona el Java Server Page-Vista y le cede la ejecución

    • El Java Server Page-Vista

      • Se sincroniza obteniendo el estado de los Beans-Modelos para aplicar la lógica compleja

      • Genera dinámicamente HTML

jee
Java Enterprise Edition (JEE):

El navegador presenta un página HTML para que un cliente rellene un formulario y pulse el botón de enviar

El botón lleva asociado la URL del Servlet-Controlador que corresponde ejecutar y junto con los datos del formulario conforman la trama HTTP que se envía al servidor web

Éste localiza el Servlet-Controlador correspondiente a la URL y le pasa la petición (Request-Evento) y la respuesta (Response)

El Servlet-Controlador extrae los parámetros del Request-Evento, opera sobre los DAO para acceder a los Beans-Modelos y los trata según la funcionalidad del Servlet-Controlador para almacenarlos en la sesión

El Servlet-Controlador cede la ejecución al Java Server Page-View que combina HTML y sentencias de Java para la sincronización y lógica de presentación a partir de los datos obtenidos del estado de los Beans-Modelos accesibles desde la sesión

El Java Server Page-Vista se transforma en la siguiente página HTML a devolver en la respuesta (Response) al navegador que lo solicitó

Web con Múltiples páginas con MVP-PV

  • Symphony (PHP), Estilo arquitectónico: Modelo/Vista/Controlador con Vista Pasiva:

    • El Controlador-Presentador

      • Recibe atiende la petición (Request-Evento) producto de la interacción del usuario con la vista

      • Opera sobre los Modelos-Modelos y aplica la lógica necesaria para la siguiente página

      • Selecciona el Twig-Vista para sincronizar inyectando los datos necesarios

    • El Twig-Vista

      • Genera dinámicamente HTML con una lógica mínima

symphony
Symphony (PHP):

El navegador presenta un página HTML para que un cliente rellene un formulario y pulse el botón de enviar

El botón lleva asociado la URL del Controlador-Presentador que corresponde ejecutar y junto con los datos del formulario conforman la trama HTTP que se envía al servidor web

Éste localiza el Controlador-Presentador correspondiente a la URL y le pasa la petición (Request-Evento) y la respuesta (Response)

El Controlador-Presentador extrae los parámetros del Request-Evento, opera sobre los DAO para acceder a los Modelos-Modelos y los trata según la funcionalidad del Controlador-Presentador para almacenarlos en la sesión

El Controlador-Presentador aplica la lógica y sincroniza inyectando todos los valores del estado necesarios seggún la lógica de la presentación del Twig-Vista

El Twig-Vista es una plantilla orientada a diseñadores, no programadores, que acepta los valores del Controlador-Presentador

El Twig-Vista se transforma en la siguiente página HTML a devolver en la respuesta (Response) al navegador que lo solicitó

Web con Múltiples páginas con MVP-SC

  • Spring con FrontPage (Java), estilo arquitectónico Modelo/Vista/Controlador con Controlador Supervisor, donde la interacción del usuario la atiende el servidor web que retransmite al controlador:

    • El Controlador-Presentador

      • Recibe atiende la petición (Request-Evento) producto de la interacción del usuario con la vista

      • Opera sobre los Modelos-Modelos y ejecuta la lógica compleja para la presentación dejando la información en la sesión

      • Selecciona el Java Server Page-Vista y le cede la ejecución

    • El Java Server Page-Vista

      • Se sincroniza obteniendo el estado de los Modelos-Modelos para aplicar la lógica sencilla

      • Genera dinámicamente HTML

FrontPage
Spring con FrontPage :

El navegador presenta un página HTML para que un cliente rellene un formulario y pulse el botón de enviar

El botón lleva asociado la URL del Controlador-Presentador que corresponde ejecutar y junto con los datos del formulario conforman la trama HTTP que se envía al servidor web

Éste localiza el Controlador-Presentador correspondiente a la URL y le pasa la petición (Request-Evento) y la respuesta (Response)

El Controlador-Presentador extrae los parámetros del Request-Evento, opera sobre los DAO para acceder a los Modelos-Modelos y los trata según la funcionalidad del Controlador-Presentador para almacenarlos en la sesión con la lógica compleja

El Controlador-Presentador cede la ejecución al JSP-View que combina HTML y sentencias de Java para la sincronización y lógica sencilla a partir de los datos obtenidos del estado de los Modelos-Modelos accesibles desde la sesión

El JSP-Vista se transforma en la siguiente página HTML a devolver en la respuesta (Response) al navegador que lo solicitó

Web con Múltiples páginas con MVP-PM

  • Java Server Face, estilo arquitectónico Modelo/Vista/Presentador con Presentador del Modelo:

    • El Bean-Presentador

      • Recibe atiende la petición (Request-Evento) producto de la interacción del usuario con la vista

      • Opera sobre los Modelos-Modelos y ejecuta la lógica compleja para la presentación

      • Selecciona el Java Server Page-Vista y le cede la ejecución

    • El Java Server Page-Vista

      • Se sincroniza obteniendo el estado de los valores del Bean-Presentador para aplicar la lógica sencilla

      • Genera dinámicamente HTML

jsf
Java Server Face :

El navegador presenta un página HTML para que un cliente rellene un formulario y pulse el botón de enviar

El botón lleva asociado la URL del Bean-Presentador que corresponde ejecutar y junto con los datos del formulario conforman la trama HTTP que se envía al servidor web

Éste localiza el Bean-Presentador correspondiente a la URL y le pasa la petición (Request-Evento) y la respuesta (Response)

El Bean-Presentador extrae los parámetros del Request-Evento, opera sobre los DAO para acceder a los Modelos-Modelos y los trata según la funcionalidad del Bean-Presentador junto con la lógica compleja para la presentación

El Bean-Presentador cede la ejecución al XHTML-View que combina HTML y acceso para la sincronización y lógica sencilla de presentación a partir de los valores del Bean-Presentador

El XHTML-Vista se transforma en la siguiente página HTML a devolver en la respuesta (Response) al navegador que lo solicitó

Web con Múltiples Páginas con MVVM

  • .Net (C#), estilo arquitectónico Modelo/Vista/Presentador con Modelo/Vista/Vista-Modelo:

    • El Vista-Modelo-Vista-Modelo

      • Recibe atiende la petición (Request-Evento) producto de la interacción del usuario con la vista

      • Opera sobre los Modelos-Modelos y ejecuta la lógica compleja para la presentación

      • Selecciona el XAML-Vista y le cede la ejecución

    • El XAML-Vista

      • Se sincroniza mediante DataBinding con el Vista-Modelo-Vista-Modelo

      • Genera dinámicamente HTML

net
.Net (C#) :

El navegador presenta un página HTML para que un cliente rellene un formulario y pulse el botón de enviar

El botón lleva asociado la URL del Vista-Modelo-Vista-Modelo que corresponde ejecutar y junto con los datos del formulario conforman la trama HTTP que se envía al servidor web

Éste localiza el Vista-Modelo-Vista-Modelo correspondiente a la URL y le pasa la petición (Request-Evento) y la respuesta (Response)

El Vista-Modelo-Vista-Modelo extrae los parámetros del Request-Evento, opera sobre los DAO para acceder a los Modelos-Modelos y los trata según la funcionalidad del Vista-Modelo-Vista-Modelo junto con la lógica para la presentación

El Vista-Modelo-Vista-Modelo cede la ejecución al XAML-View que es una plantilla que combina "HTML" y se sincroniza mediante DataBinding con el Vista-Modelo-Vista-Modelo

El XAML-Vista se transforma en la siguiente página HTML a devolver en la respuesta (Response) al navegador que lo solicitó

REST con MVC en Servidor

  • Spring/JEE, estilo arquitectónico Modelo/Vista/Controlador-Smalltalk80:

    • El Recurso-Controlador

      • Recibe atiende la petición (Request-Evento) producto de la interacción del usuario con el cliente

      • Opera sobre los Modelos-Modelos

      • Construye la Data Transfer Object-Vista

    • El Data Transfer Object-Vista

      • Se sincroniza obteniendo el estado de los valores de los Modelos-Modelos para aplicar la lógica necesaria para la presentación

      • Genera dinámicamente JSON/XML

spring
Spring/JEE :

Un cliente web/móvil, mediante tecnología AJAX/RespTemplate realiza una petición HTTP con la URL del recurso, operación y parámetros oportunos para confrontar la trama HTTP que se envía al servidor Web

Éste localiza el Recurso-Controlador correspondiente a la URL y le pasa la petición (Request-Evento) y la respuesta (Response)

El Recurso-Controlador extrae los parámetros del Request-Evento, opera sobre los DAO para acceder a los Modelos-Modelos y los trata según la funcionalidad del Recurso-Controlador

El Recurso-Controlador construye el Data Transfer Object-Vista oportuna que se rellena con los valores de los Modelos-Modelos suministrados por el Recurso-Controlador

El Data Transfer Object-Vista se transforma en JSON/XML a devolver en la respuesta (Response) al navegador que lo solicitó

Web con Única página con MVVM en Cliente

  • Angular.js (JavaScript), estilo arquitectónico Modelo/Vista/Vista-Modelo:

    • El Controlador-Vista-Modelo

      • Recibe atiende la petición (Request-Evento) producto de la interacción del usuario con el HTML

      • Accede a los Modelos-Modelos que llegan del servidor y aplica la lógica para la presentación

    • El HTML-Vista

      • Se sincroniza obteniendo el estado de los valores de los Controlador-Vista-Modelo mediante DataBinding

      • Transforma el árbol DOM del HTML

angular
Angular.js (JavaScript) :

El navegador presenta un página HTML para que un cliente rellene un formulario y pulse el botón de enviar

El botón lleva asociado la URL del Controlador-Vista-Modelo que corresponde ejecutar

El Controlador-Vista-Modelo, mediante tecnología AJAX realiza las peticiones HTTP contra el servidor REST para acceder a sus Modelos-Modelos a partir del JSON/XML retornado (que a su vez era el Data Transfer Object-Vista del servidor)

Trata los Modelos-Modelos según la funcionalidad del Controlador-Vista-Modelo junto con la lógica compleja para la presentación

El Controlador-Vista-Modelo cede la ejecución al HTML-View que contiene directivas para la sincronización mediante DataBinding con el Controlador-Vista-Modelo

El HTML-View transforma el árbol DOM para la siguiente HTML

Móvil con MVP-PV en Cliente

  • Android (Java), estilo arquitectónico Modelo/Vista/Presentador con Vista Pasiva:

    • El Activity-Presentador

      • Recibe atiende la petición (Request-Evento) producto de la interacción del usuario con el XML-View

      • Accede a los Modelos-Modelos que llegan del servidor y aplica la lógica para la presentación

      • Se sincroniza su estado inyectando valores a los controles definidos en el XML-View

    • El HTML-Vista

      • XML-View

android
Angular.js (JavaScript) :

El móvil presenta una pantalla para que un cliente rellene un formulario y pulse el botón de enviar

El botón lleva asociado la operación del Activity-Presentador que corresponde ejecutar

El Activity-Presentador, mediante tecnología RestTemplate realiza las peticiones HTTP contra el servidor REST para acceder a sus Modelos-Modelos a partir del JSON/XML retornado (que a su vez era la Vista-Vista en el servidor)

Trata los Modelos-Modelos según la funcionalidad del Activity-Presentador junto con la lógica compleja para la presentación

El Activity-Presentador se sincroniza con el XML-View inyectando los valores necesarios para la presentación

El XML-View se actualiza en pantalla

Arquitectura Ágiles

Año Autor Publicación Referencia

2009

M. Fowler

Flaccid Scrum

2014

D. Thomas

Agile is dead, long live agility

2018

R. Jeffiers

Scrum is not an Agile Software Development Framework

2018

R. Jeffiers

Developers Should Abandon Agile

Arquitectura Hexagonal Arquitectura en Cebollá Arquitectura Limpia

Hexagonal architecture complex example

bien

CleanArchitecture

Arquitectura Hexagonal

Alistair Cockburn, antropólogo de proyectos
  • 1997, Surviving Object-Oriented Projects, experiencias en IBM

    • Addison-Wesley Professional

  • 2000, Writing Effective Use Cases

    • Addison-Wesley Professional

  • 2001, Agile Software Development

    • Addison-Wesley Professional

  • 2002, Patterns for Effective Use Cases, contributors,

    • Addison-Wesley Professional

  • 2003, People and Methodologies in Software Development

    • D.Ph. dissertation, University of Oslo Press

  • 2004, Crystal Clear: A Human-Powered Methodology for Small Teams, marco metodológico XP, RUP, …​ según tamaño y complejidad

    • Addison-Wesley Professional

  • 2005, Hexagonal Architecture *

  • 2006, Agile Software Development: The Cooperative Game

    • Addison-Wesley Professional

  • 2015, Movimiento Corazón Agile

  • Cuántas veces no hemos escrito y el usuario aprieta el botón de color azul o el registro de la persona se guarda en la base de datos). Estos casos de uso han ganado justificadamente un mal nombre en la industria por ser largos, difíciles de leer, aburridos, frágiles y costosos de mantener. ?!?!

  • El principio de inversión de dependencias de Bob Martin (también llamado Inyección de dependencias por Martin Fowler) ?!?!?!

Nombre Intención Propósito
  • Patrón: Puertos y Adaptadores

    • Sinónimo: Arquitectura hexagonal

    • Tipo: estructural

  • permite que una aplicación sea usada de la misma forma por usuarios, programas, pruebas automatizadas o batch scripts, y sea desarrollada y probada en aislamiento (isolated) de sus eventuales dispositivos y bases de datos en tiempo de ejecución

  • Pretende que todos los elementos externos son idénticos desde la perspectiva de la aplicación

Beneficio
  • Habilidad de poder ejecutar la aplicación en un modo totalmente aislado

    • ¿Aplicación == Controladores + Modelos? Lógica en POJO’s, POCO’s, …​, no acoplados a ningun framework, tecnología

    • ¿Contexto == Interfaz Gráfico de Usuario + Interfaz de Comunicaciones + Pruebas + …​ + Servidor de Bases de Datos + Dispositivo + Doble?

Hexagonal architecture barn door image 1

  • 1. Prueba unitaria o familiar o de componente del controlador y modelos, de la aplicación

  • 2. Prueba de integración de contexto y aplicación, sin persistencia!!!

  • 3. Prueba de integracion de aplicacion y persistencia, sin vista!!!

  • 4. Prueba del sistema o explotación

  • La especificación funcional de la aplicación, quizá en Casos de Uso, es hecha bajo la interfaz del hexágono interno y no en cambio en cualquier tecnología externa que podría ser usada

  • La palabra “puerto” tiene la intención de traer recuerdos de los “puertos” en un sistema operativo, donde cualquier dispositivo que cumple con los protocolos de un puerto puede ser conectado (plug-in) y en los “puertos” de gadgets electrónicos, donde otra vez, cualquier dispositivo que cumpla con los protocolos mecánicos y eléctricos puede ser conectado

    • El protocolo de un puerto es

      • dado por el propósito de la comunicación entre dos dispositivos

      • toma la forma de una interfaz de programación de aplicación (API)

Hexagonal architecture pic 1 to 4 socket

  • La aplicación tiene una interacción semántica con los adaptadores de todos sus lados, sin saber realmente la naturaleza de las cosas del otro lado de los adaptadores

  • Diagrama de contexto de casos de uso

    • ¿Puerto == Interfaz entre Contexto y Aplicación y viceversa?

    • ¿Adaptador == Vista: Interfaz Gráfica de Usuario Gráfica y/o Consola, Interfaz de Comunicaciones, Data Access Object (DAO), Servicio de Correo, …​

Hexagonal architecture complex example

Actor, Adaptador y Puerto primario, director, izquierdo y superior, API del lado del usuario Actor, Adaptador y Puerto secundario, dirigido, derecho, inferior, API del lado de los datos
  • Un “actor primario” es un actor que dirige la aplicación (lo que saca del lado inactivo para realizar una de sus dichas funciones).

  • Un “actor secundario” es aquel que la aplicación dirige, bien para obtener respuestas o simplemente para notificarlo.

  • Todo evento externo (i.e. como pedidos http) que llega a la aplicación por un puerto, es convertido, a través de un adaptador especifico a la tecnología del evento externo, en una llamada a un procedimiento o un mensaje entendible por la aplicación

  • Cuando la aplicación tiene algo que enviar, lo hace por un puerto a un adaptador, el cual crea las señales apropiadas, necesarias por la tecnología receptora (humana o automatizada)

  • lado que controla la aplicación

  • los “puertos primarios” y “adaptadores primarios” en el lado izquierdo (o superior) del hexágono

    • quien dispara (trigger)

    • Adaptador “director”

    • Adaptador “primario”

  • lado de obtención de datos

  • los “puertos secundarios” y “adaptadores secundarios” en el lado derecho (o inferior) del hexágono

    • está a cargo de la conversación

    • Adaptador “dirigido”

    • Adaptador “secundario"

  • La aplicación puede ser igualmente dirigida por suites de pruebas automatizadas a nivel de sistema, por un usuario humano, por una aplicación remota a través de http , o por otra aplicación local

  • La aplicación puede ser configurada para ejecutarse sin acoplamiento de bases de datos externas usando una base de datos de reemplazo en memoria, o “mock” o puede ser ejecutada bajo la base de datos de pruebas o producción

  • Test

import fit.ColumnFixture;
public class TestDiscounter
  extends ColumnFixture {

  private Discounter app = new Discounter(
    RepositoryFactory
      .getMockRateRepository());
  public double amount;

  public double discount() {
    return app.discount(amount); (1)
  }
}
1 Puerto
  • Controller

import repository.RepositoryFactory;
import repository.RateRepository;
public class Discounter {
  private RateRepository rateRepository;

  public Discounter(RateRepository r) {(1)
    super();
    rateRepository = r;
  }

  public double discount(double amount){(2)
    double rate =
      rateRepository.getRate( amount );
    return amount * rate;
  }

}
1 Principio Abierto/Cerrado cumpliendo Sustitución de Liskov: Inyección de Dependencias, Strategy, PluggIn, …​ ¿o una Fábrica Abstracta?
2 Puerto
  • Vista

Discounter app = new Discounter(
  RepositoryFactory.getRateRepository());

public void actionPerformed
  (ActionEvent event){
...
  String amountStr = text1.getText();
  double amount =
    Double.parseDouble(amountStr);
  discount = app.discount(amount));(1)
  text3.setText( "" + discount );
...
}
1 Puerto
  • Test

import app.Discounter;
import fit.ColumnFixture;
public class TestDiscounter
  extends ColumnFixture {

  private Discounter app = new Discounter(
    RepositoryFactory
      .getMockRateRepository());
  public double amount;

  public double discount() {
    return app.discount( amount);(1)
  }
}
1 Puerto
  • ¿Puerto primario, director, izquierdo y superior == Interfaz de Controlador, entre Vista de Actor y Controlador?

    • ¿Acoplamiento aferente del controlador?

  • ¿Puerto secundario, dirigido, derecho e inferior == Interfaz de Vista, entre Controlador y Vista de Servicio?

    • ¿Acoplamiento eferente del controlador?

La asimetría a usar no es sino
  • la que existe entre el lado “izquierdo” y “derecho” de la aplicación (el que dirige y el dirigido por la aplicación, o

  • la de los lados “superior” e “inferior” como se ve en la arquitectura 3 capas – la capa “superior”, la presentación, dirige a la aplicación y la capa “inferior”, fuente de datos, es dirigida o usada por la aplicación)

  • entre los lados “interno” y “externo” (la aplicación en sí y su contexto) de la aplicación.

    • Se debe obedecer la regla que todo código “interno” no debe fugarse a la parte “externa”

      • ¿fugarse == acoplarse?

        • ¿No fugarse == Principio Abierto/Cerrado de Bertrand Meyer?

        • ¿No fugarse == Principio Sustitución de Barbara Liskov?

          • ¿No fugarse == Principio de Inversión de Dependencias?

loDeSiempre
Aplicación: TicTacToe Solución: java
El hexágono no es un hexágono por que el número seis es importante
  • sino más bien para permitir que la gente que hace el esquema tenga espacio para insertar puertos y adaptadores cuando lo necesite, sin estar restringido a un esquema unidimensional en capas.

  • El hexágono tiene el propósito de resaltar visualmente

    • la asimetría interna-externa,

    • la naturaleza similar de los puertos y

    • la presencia de un número definido de diferentes puertos — 2, 3 o 4 (cuatro es lo mayor que he encontrado hasta hoy)

Lo que exactamente es y no es un puerto es en gran medida una cuestión de gustos
  • En un extremo cada caso de uso podría tener su propio puerto, produciendo cientos de puertos en muchas aplicaciones.

  • Alternativamente, uno podría imaginar juntar todos los puertos primarios y todos los puertos secundarios de tal forma que solo hubieran dos, el del lado izquierdo y el derecho.

  • Ninguno de estos extremos es bueno

    • No parece haber algún daño en escoger un número “equivocado” de puertos, por lo que está sigue siendo una cuestión de intuición.

    • Aún así prefiero escoger un número pequeño de puertos: 2,3 o 4

The ‘’Pedestal’’ pattern
  • PatternLanguages of Program Design

    • Coplien, J., Schmidt, D.

    • Addison-Wesley, 1995, pp. 119–150

      • Patterns for Generating a Layered Architecture

        • Rubel, Barry

  • describe un patrón en la creación de un eje de simetría en un software de control que es muy similar al de puertos y adaptadores.

    • propone implementar un objeto que represente cada dispositivo de hardware dentro del sistema, y enlazar esos objetos en una capa de control.

    • puede ser usado para describir cualquier lado de la arquitectura hexagonal, pero no resalta la similaridad entre adaptadores

Arquitectura en Cebollá

Jeffrey Palermo
  • 2008, Onion Architecture

  • 2009, ASP.NET MVC In Action

    • Manning Publications

  • 2010, ASP.NET MVC 2 In Action

    • Manning Publications

  • 2012, ASP.NET MVC 4 In Action

    • Manning Publications

  • 2019, .NET DevOps for Azure

    • Manning Publications

Arquitectura Tradicional Arquitectura en Cebollá
  • Propongo un nuevo enfoque para arquitectura

    • Honestamente, no es completamente nuevo pero lo propongo commo un patrón arquitectónico con nombre

tradicional

nueva

mal

bien

  • Las arquitecturas hexagonal y cebolla comparten la siguiente premisa:

    • Externalice la infraestructura y escriba el código del adaptador para que la infraestructura no se acople estrechamente

Arquitectura Limpia

Robert Cecil Martin, Tio Bob, preguntame lo que sea!!!
  • 1995, Designing Object-Oriented C++ Applications Using the Booch Method

    • Prentice Hall

  • 2002, Agile Software Development: Principles, Patterns, and Practices

    • Pearson Education

  • 2009, Clean Code: A Handbook of Agile Software Craftsmanship

    • Prentice Hall

  • 2011, The Clean Coder: A Code of Conduct for Professional Programmers

    • Prentice Hall

  • 2017, Clean Architecture: A Craftsman’s Guide to Software Structure and Design

    • Prentice Hall

  • 2019, Clean Agile: Back to Basics

    • Pearson Education

UncleBob

agilePrinciples

CleanCodeAHandbookOfAgileSoftwareCraftsmanship

theCleanCoder2

CleanArchitectureBook

cleanAgile

Valores y principios ágiles para una nueva generación “En el viaje hacia todas las cosas ágiles, el tío Bob ha estado allí, lo ha hecho y tiene tanto la camiseta como las cicatrices para mostrarlo. Este delicioso libro es en parte historia, en parte historias personales y toda sabiduría. Si quieres entender qué es Agile y cómo llegó a ser, este es el libro para ti
— Grady Booch
La frustración de Bob tiñe cada frase de Clean Agile, pero es una frustración justificada. Lo que hay en el mundo del desarrollo ágil no es nada comparado con lo que podría ser. Este libro es la perspectiva de Bob sobre en qué enfocarse para llegar a 'lo que podría ser'. Y él ha estado allí, así que vale la pena escucharlo
— Kent Beck
Los Principios son […​ SOLID …​] Aunque se presentan aquí como principios de diseño orientado a objetos, en realidad son casos especiales de principios de la ingeniería de software asentados hace tiempo
— Uncle Bob
El Principio de Única Responsabilidad. Este principio se describió en el trabajo de Tom DeMarco y Meilir Page-Jones. Lo llamaron cohesión
— Uncle Bob
El Principio de Inversión de Dependencias. En esta columna, discutimos las implicaciones estructurales del OCP y el LSP. La estructura que resulta del uso riguroso de estos principios puede generalizarse en un principio por sí solo. Lo llamo "El principio de inversión de dependencia" (DIP)
— Uncle Bob
  • Durante los últimos años, hemos visto una gran variedad de ideas sobre la arquitectura de los sistemas.

    • Éstos incluyen:

  • Hexagonal Architecture (a.k.a. Ports and Adapters) de Alistair Cockburn

    • Adoptado por Steve Freeman, and Nat Pryce en su maravilloso libro Growing Object Oriented Software

  • Onion Architecture de Jeffrey Palermo

  • Screaming Architecture de mi propio blog del último año

  • Lean Architecture de James Coplien, and Trygve Reenskaug

  • Boundary/Control/Entity de Ivar Jacobson de su libro Object Oriented Software Engineering: A Use-Case Driven Approach

  • Aunque todas estas arquitecturas varían algo en sus detalles, son muy similares.

    • Todos tienen el mismo objetivo, que es la separación de asuntos

    • Todos logran esta separación dividiendo el software en capas.

CleanArchitecture

CleanArchitectureRidiculo

CleanArchitectureRidiculo2

CleanArchitectureRidiculo3

Sintesis

sintesis

Bibliografía

Obra, Autor y Edición Portada Obra, Autor y Edición Portada
  • Patterns of Enterprise Application Architecture

    • Martin Fowler

    • Addison-Wesley; (2002)

PatternsOfEnterpriseApplicationArchitecture

  • Clean Architecture: A Craftsman’s Guide to Software Structure and Design

    • Robert C Martin

    • Prentice Hall; (2017)

CleanArchitecture

  • The Art of Software Architecture: Design Methods and Techniques

    • Stephen T. Albin

    • Wiley; (2003)

TheArtOfSoftwareArchitecture

  • Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

    • Nick Rozanski, Eóin Woods

    • Addison-Wesley; (2011)

SoftwareSystemsArchitecture

  • Software Architecture in Practice

    • Len Bass, Paul Clements, Rick Kazman

    • Addison-Wesley; (2012)

SoftwareArchitectureInPractice

  • Pattern-oriented Software Architecture: A System of Patterns

    • Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad

    • Wiley (1996)

PatternOrientedSoftwareArchitecture

  • Documenting Software Architectures

    • Paul Clements, Felix Bachmann, Len Bass ..

    • (2001)

DocumentingSoftwareArchitectures

  • Integrating Software Architecture-Centric Methods into Extreme Programming

    • Robert L. Nord, James E. Tomayko, Rob Wojcik

    • (2004)

IntegratingSoftwareArchitectureCentricMethods

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM