Arquitectura de Software

El proceso de desarrollo de software

Etapas del proceso:

El proceso de desarrollo tradicional tiene etapas muy marcadas, que tienen entradas, procesos y
salidas que funcionan como entradas de la siguiente etapa.

Análisis de requerimientos: Todo nace de un disparador que nos crea la necesidad de crear un

artefacto o un sistema. Necesitamos entender cuál es el problema que queremos resolver. Hay
requerimientos de negocio, requerimientos funcionales, requerimientos no funcionales.

Diseño de la solución: Análisis profundo de los problemas para trabajar en conjunto y plantear

posibles soluciones. El resultado de esto debe ser el detalle de la solución, a través de
requerimientos, modelado, etc.

Desarrollo y evolución: Implementación de la solución, para garantizar que lo que se esta

construyendo es lo que se espera. Al finalizar esta etapa tendremos un artefacto de software.

Despliegue: Aquí vamos a necesitar de infraestructura y de roles de operación para poder poner el

artefacto a disponibilidad.

Mantenimiento y evolución: Desarrollo + despliegue + mantenimiento, en esta etapa estamos

atentos a posible mejoras que se hacen al sistema. En esta etapa el software se mantiene hasta
que el software ya deja de ser necesario.
Dificultades

En la etapa de diseño y desarrollo estamos concentrados en encontrar cuáles son los problemas
que queremos resolver. Estos problemas los podemos dividir en dos grandes tipos de problemas.

Esenciales: Los podemos dividir en 4.

1. La complejidad, cuándo lo que tenemos que resolver es complejo en si mismo, por

ejemplo calcular la mejor ruta entre ciudades.

2. La conformidad.

3. Tolerancia al cambio.

4. Invisibilidad.

**Accidentales:**Está relacionado con la plataforma que vamos a implementar, tecnología,

lenguajes, frameworks, integraciones, etc.
¿Cómo resolver las dificultades esenciales?

Roles

Es importante que diferenciemos el ROL del puesto de trabajo, hay roles que pueden ser
desarrollados por la misma persona.

Experto del dominio: En una metodología tradicional, es la persona a la que acudimos para
entender las necesidades del negocio. En metodologías Ágiles --> stakeholders.

Analista: funcional/de negocio, la persona responsable de definir los requerimientos que van a

llevar al software a u buen puerto. En el caso de Ágiles el dueño del producto es quien arma las
historias y que nos acompaña en el proceso de construcción del software.

Administrador de sistemas / DevOps: Es el rol de operaciones y desarrollo, son las personas

responsables de la infraestructura que alojara nuestra aplicación.

Equipo de desarrollo: QA / Testing se encargan de la evaluación de nuestro software, comprobar

que lo que se está haciendo es lo que se espera que se haga. Desarrolladores involucrados en la
construcción del software. Arquitecto, diseña la solución y análisis de los requerimientos, es un
papel más estratégico. La arquitectura emerja del trabajo de un equipo bien gestionado.

Gestor del proyecto / facilitador: Llevan al equipo a través del proceso iterativo e incremental,
entender lo que pasa con el equipo y motivar el avance en el desarrollo del producto.

¿Qué es arquitectura de software?

La arquitectura, más que un modelo es algo estructural. El concepto de arquitectura de software

se refiere a la estructuración del sistema que, idealmente, se crea en etapas tempranas del
desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que tiene dos
propósitos

 satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad)

 servir como guía en el desarrollo.

El no crear este diseño desde etapas tempranas del desarrollo puede limitar severamente el que el
producto final satisfaga las necesidades de los clientes. Además, el costo de las correcciones
relacionadas con problemas en la arquitectura es muy elevado. Es así que la arquitectura de
software juega un papel fundamental dentro del desarrollo.

Objetivos del arquitecto.

El arquitecto tiene varias partes interesadas “stakeholders” el cual tiene que conectar esto
requerimientos de cada stakeholders con la implementación del sistema.

Stakeholders involucrados con diferentes requerimientos:

• Cliente: Entrega a tiempo y que no rebase el presupuesto.
• Manager: Comunicación clara entre los equipos que participan en el desarrollo del sistema
• Dev: Que el desarrollo llevado acabo sea fácil de implementar y mantener
• Usuario: Disponibilidad del producto.
• QA/Tester: Fácil de pr006Fbar.

El arquitecto de software debe gestionar los siguientes puntos para cada Stakeholder:
• Encontrar los riegos más altas que afecten en el desarrollo del sistema (Cliente)
• Modularización y flexibilidad del sistema que se está desarrollando (Manager)
• Modularidad, mantenibilidad y capacidad de cambio del software (Dev)
• Desisdir estrategias para la disponibilidad del sistema (Usuario)
• Que el sistema pueda ser modularizado y cada una destas partes pueda ser probado de forma
fácil (QA).

La unión de estos requerimientos (funcionales / no funcionales) va a llevar al arquitecto a tomar

decisiones que impactan directamente en el desarrollo del software.
Arquitectura y metodologías

Entender el problema

La parte más importante de entender el problema es: separar la comprensión del problema de la

propuesta de solución, si no se entiende la diferencia entre estos dos puntos se tiende a
solucionar problemas inexistentes y a hacer sobreingeniería.

Problema:

Detalla ¿que es lo que se va a resolver? (y qué no se va a resolver) sin entrar en detalles del
“cómo”. -> (analisis del problema)

El espacio del problema nos ayuda a entender que es lo que vamos a resolver y exactamente como
imaginamos como esto va agregar un valor a nuestros usuarios sin entrar en detalle de cómo lo va
a resolver el sistema.
  Idea: ¿Qué queremos resolver?

 Criterios de éxito: ¿Cómo identificamos si estamos resolviendo el problema?

 Historias de usuario: Supuestos de historias de lo que va a ganar el usuario al utilizar la

solución usando las características del problema a resolver.
.

Solución:

Brinda el detalle del ¿“cómo” se va a resolver?, reflejando los detalles del problema detectado y
evitando resolver problemas que no se quiere o necesita resolver. --> (detalles técnicos)

Se refleja en el espacio del problema y trata de resolverlo teniendo en cuenta todos los detalles
técnicos necesarios.

Consta de:

 Diseño: todo lo referente a la planificacion del software, desde diseño UI, UX hasta diseño
de sistemas

 Desarrollo: escribir el codigo, configuraciones y contrataciones de servicios

 Evaluación: medir la eficiencia y eficacia del software frente al problema

 Criterios de aceptación: medir el impacto del software, no importa lo bueno que sea el

problema si los usuarios no lo usan o no le ven uso

 Despliegue (deploy): lanzar el software en ambientes productivos (mercado) y empezar a

mejorar las caracteristicas con un feedback loop (crear, medir, aprender)

Requerimientos

Los dividimos en 2 grandes grupos:** requerimientos del producto** (los que vienen fijados por
las partes interesadas) y los requeremientos de proyecto (fechas de entregas, planes,
disponibilidad de recursos humanos, etc).

R. Productos:

Los separamos en tres capas: negocio, **usuario **y funcional

Negocio: reglas de negocios alimentadas por los requerimientos del mismo. Ejemplo si quiero
conectar a personas que venden con personas que compran en un proyecto de market_place, el
sistema deberia tener la posibilidad de que los usuarios puedan subir artículos.

Usuario tiene que ver con las funcionalidades que va a requerir el usuario del sistema. Siguiendo
con el ejemplo del Market-place
sería que el usuario tuviera un panel de control y pueda autogestionarse la cuenta.
Funcional
¿qué cosas tienen que pasar operativamente? Ejempo que el sistema pueda cobrar a una tarjeta
de credito luego de concretar una venta.

Los requerimientos de producto se pueden separar en funcionales y no funcionales .

Los funcionales detallana especificamente como el sistema se va a corportar. Los requisitos

funcionales establecen los comportamientos del software.

Los No funcionales representan características generales y restricciones de la aplicación o sistema

que se esté desarrollando.
Ejemplos de No funcionales :

 El sistema debe ser capaz de procesar N transacciones por segundo. Esto se medirá por
medio de la herramienta SoapUI aplicada al Software Testing de servicios web.

 Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en

menos de 5 segundos.

 El sistema debe ser capaz de operar adecuadamente con hasta 100.000 usuarios con
sesiones concurrentes.

 Los datos modificados en la base de datos deben ser actualizados para todos los usuarios
que acceden en menos de 2 segundos.

Riesgos:

Un riesgo es un problema potencial -> Puede ocurrir o no.

Por tal razón es importante:

 Identificarlo

 Evaluar su posibilidad de aparición

 Estimar su impacto

 Establecer un plan de contingencia por si ocurre el problema

Los riesgos son importantes para priorizarlos y atacarlos en orden y asegurar que las soluciones
arquitectónicas que propongamos resuelvan los problemas más importantes. Una vez que
tenemos los riesgos identificados, debemos priorizarlos, recuerda que no es necesario mitigarlos
todos, debemos siempre tener en cuenta y dar prioridad a aquellos riesgos que ponen en peligro
la solución que se está construyendo.

Intenta tratar los riesgos con posibles escenarios de fracaso y que pasaría en caso de que ese
riesgo se haga real.

Veamos cómo identificar los riesgos:

o En la toma de requerimientos --> dificultad / complejidad

 A mayor complejidad mayor grado de riesgo

o En los atributos de calidad --> incertidumbre

 Cuanta más incertidumbre hay, más alto es el riesgo.

o Conocimiento del dominio --> Riesgo prototípico

 Son aquellos que podemos atacar de forma estándar o que ya otros los
han atacado y solucionado.

Restricciones

“Una restricción limita las opciones de diseño o de implementación disponibles al desarrollador.”

Cuando empezamos a trabajar, no vamos a tener disponibles todas las tecnologías, plataformas,
patrones de diseño, infraestructura, porque hay ciertas restricciones que nos da el contexto.

Usualmente, estas restricciones están dadas por las partes interesadas [stakeholders], que nos
van a poner limitaciones que tengan que ver con su ecosistema, o su contexto de negocio, o
regulaciones o legales.
Limitaciones por integraciones con otros sistemas, por ejemplo, la aplicación necesita conexión
a internet, eso nos va a limitar en la capacidad o contexto de despligue.
El ciclo de vida: A medida que crece la aplicación es más difícil de cambiar.

Arquitectura, panorama y definición

Panorama Arquitectónico
Hay muchas librerías, muchos frameworks, mucho conocimiento arquitectónico implícito entre las
comunidades.

¿Qué es un estilo de arquitectura?

Cuando hablamos de estilo de arquitectura hablamos de algo genérico.

Un estilo de arquitectura es una colección de decisiones de diseño, aplicables a un contexto

determinado, que restringen las decisiones arquitectónicas específicas en ese contexto
y obtienen beneficios en cada sistema resultante.

Estilos: Llamado y retorno

Cada uno de los componentes hacen invocaciones a los componentes externos y estos retornan
información.

Cada componente hace un llamado y espera una respuesta

Programa y subrutinas --> Instrucciones secuenciales que el programa ejecutaba una por una.
Luego se hacían instrucciones de salto, de aquí surgieron las funciones que son bloques de código
que podemos invocar en cualquier momento.

Orientado a objetos --> la abstracción es mayor en comparación con el paradigma anterior, se usa
para aplicaciones que ya sabemos que vamos a usar durante mucho tiempo. La abstracción ya no
es la subrutina, ahora tenemos objetos que se hacen llamados entre si y esperan respuestas.
Estilos: Flujo de datos

Lote secuencial
Lo importante es ejecutar una pieza de código y que al final de esa pieza todo lo procesado pase a
la siguiente pieza.
Tubos y filtros
Tenemos un flujo de datos continuo en dónde cada aplicación recibe continuamente esos datos,
los procesa y le da salida a otra aplicación o al final de ésta.

Estilos: Centradas en datos

Pizarrón:

 El pizarrón es el núcleo de la arquitectura. Donde componentes externos a el se

encargarán de procesar un dato y escribirlo en el pizarrón(Este funciona como
centralizador). Cuando el pizarrón ya tiene todos los datos necesarios; el mismo podría
generar una salida,Ejemplo: Sistema Fiscales

Centrado en base de datos:

 Es un estilo común; Se trata de que una cantidad de componentes comparte una misma
base de datos. de Ejemplo: aplicaciones que poseen comunicación por Internet.

Sistema experto Basado en reglas:

 Este sistema no se ve muy seguido en aplicaciones modernas; un componente A (Tipo

Cliente) consulta a uno B, donde este se encargará de tratar de entender si la petición del
cliente es una consulta o regla. Para que el componente B logre resolver la petición se va a
comunicar con un tercer componente © este trabajara como KDB: Knowledge DataBase.

Estilos: Componentes independientes

Existen dos grandes familias que tienen que ver con la forma en que se comunican los
componentes. (la invocación implicaita y explícita)

Invocación implícita:
Se tienen varios componentes y se cuenta con un BUS de eventos en el cual los componentes van
a escribir algunos eventos y luego el BUS los comunica a los componentes que les conciernan
dichos eventos. Existen varios tipos de BUS.
Tipos de BUS:
Publicar/suscribir: en donde el componente inicial es el que publica un evento y los componentes
que estan suscritos reciben la notificación de dicha publicación.
Orientado a servicios (Enterprise Service BUS): en este caso el BUS es un componente inteligente,
en el que los componentes notifican al BUS a través de eventos y el BUS decide a quien notificar
dichos eventos.

Invocación explícita:
Se tienen componentes desarrollados individualmente pero que todos se conocen entre sí, dichos
componentes tiene que publicar que via de comunicación existirá para comunicarse entre ellos y a
que se dedica cada uno.
Comparando estilos: ¿Cómo elijo?

Estilos monolíticos.

Estilos donde se despliegan un artefacto de software

1. **Eficiencia: **Al tener un solo artefacto se puede ser optimizado de manera más
personalizada. // En estilos distribuido, es un problema debido a los canales de
comunicación, red, intenet que comunican los componentes.

2. Curva de aprendizaje: El monolitico contiene toda la información allí. Un monolitico bien

diseñado permite tener todas las piezas en el mismo lugar, por lo que se facilita la lectura
y entendimiento. // El el caso distribuido hay que entender cada componente.Nota: Un
componente interno en un distribuido puede ser visto como un monolítico. Es la base de
los microservicios.

3. **Capacidad de prueba: **Son más fáciles de probar una funcionalidad de principio a

fin. // En distribuidos necesito tener todos lso componentes disponibles, incluyendo los
BUS de eventos.

4. Capacidad de modificación: Un cambio que se despliega todo junto garantiza menos

estaddos intermedios. Las versiones nunca coexisten // En distribuidos diferentes
compoentes tienen diferentes versiones, por lo que requiere de compatibilidad entre
versiones. Una modificación en un distribuido es más difícile hacer llegar.

Estilos distribuidos.

Componentes que luego de ser desplegados se conectan de alguna forma.

1. Modularidad: Es separar componentes que prestan servicios

2. **Disponibilidad:**Es mayor que en monolítica, podemos tener multiples copias de un

componente, que esté disponible significa que sea más barato, tener una copia entera de
un monolitco es mucho más caro que copiar el componente distribuido que necesitamos
que escale. Microservicios aprovecha recursos.

3. Uso de recursos: Es m{as f{acil gestionar los recursos del sistema

4. Adaptabilidad: Al ser distribuido se puede detewctar mucho más fácil qué componente
necesita ser adaptado del sistema y es más fácile realizar esa actualización // en monolítos
puede ser mucho más complicado, como lanzar una app en un sistema operativo
diferente.

¿Como elijo qué necesito?

Tener en cuenta los requisitos, los objetivos de negocio / arquitectura de software, atributos de
calida/ Estrategias de arquitectura, Escenarios/ Desiciones arquitectonicas. Con el fin de analizar
que sacrificios, riesgos y no riesgos cuento y como impacta en mi proyecto