Arquitectura del Software Definiciones - GitHub Pages

Arquitectura del SoftwareE

scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Arquitectura del SoftwareDefiniciones

Jose Emilio Labra GayoCurso 2020/21


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

EsquemaDefiniciones de arquitectura software

¿Qué es arquitectura del software?StakeholdersAtributos de calidadRestricciones


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

¿Qué es la arquitectura?

Etimológicamente, viene del griego:Arquitectura = ἀρχιτέκτωνἀρχι- "jefe" τέκτων "creador"

Architecture = Proceso y producto de planificar, diseñar y construir edificios u otras estructuras


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Vitruvius, "De arquitectura"

Escrito entre 30 y 15 antes de Cristo3 pilares de una buena arquitectura

Utilitas (utilidad): Ser útil y funcionar bien para las personas que lo van a usar

Firmitas (durabilidad): Mantenerse de forma robusta y en buena condición

Venustas (elegancia): Ser agradable a las personas

Lo mismo puede aplicarse a los sistemas de software


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

¿Qué es arquitectura del software? (1)Arquitectura [ISO/IEC/IEEE 42010:2011, 3.2]

Conceptos fundamentales o propiedades de un Sistema en su entorno representados por sus elementos, relaciones y los principios de su diseño y evolución

Descripción de arquitecturaProducto de trabajo explícito que expresa una

arquitectura de un sistema, normalmente a través de modelos, texto o gráficos

Diseñar una arquitectura (architecting)Proceso de crear una arquitectura


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

¿Qué es arquitectura del software? (2)

Estructuras fundamentales de un sistema......que comprenden:

Elementos de softwareRelaciones entre ellosPropiedades de ambos


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Arquitectura vs diseño

Arquitectura se enfoca en estructura de alto nivel de un sistema de software

Decisiones de diseño principales del sistemaSi hay que cambiarlas ⇒ Coste elevado

"Toda arquitectura conlleva diseño pero no todo el diseño es arquitectura" G. Booch


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Arquitectura de edificios vs software

Entornos y contexto más establesServicio/producto físicoLímites físicosGran tradición e historia

Nos sirve para inspiración

Múltiples cambios en contextoServicio/producto virtual No suele haber límites físicosDisciplina relativamente nueva

Podemos aprender mucho de otras

Sistemas complejosDesarrollados por equipos/organizacionesUtilizados por personasAmbos emplean estilos, patrones, tácticas, ...Y están afectados por tendencias

Similaridades

Edificios tradicionales SoftwarePero muchas diferencias...


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Otras disciplinas similares

Ingenierías Civil, Mecánica, Aeronáutica...


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Otras arquitecturas

Arquitectura de negociosArquitectura empresarialArquitectura de sistemasArquitectura de la informaciónArquitectura de datos. . .Cosas comunes a todas: Estructura y visión


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Beneficios arquitectura del software

Proporcionar visión y mapa a seguir por equipoLiderazgo y coordinación técnicaResponder cuestiones sobre decisiones

significativas, atributos de calidad y otraspreocupaciones

Marco para identificar y mitigar riesgoGestión consistente de estándares y códigoFundamentos firmes del producto a desarrollarEstructura para comunicar la solución a

diferentes niveles de abstracción y audiencias


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Retos arquitectura del software

Arquitectos en la torre de marfilFalta de comunicación

Centralización de todas las decisionesArquitecto = cuello de botella

Tomar demasiadas decisionesRetrasar ciertas decisiones puede ser mejor que

deshacerlasBig Design Up-Front

Demasiados diagramas y documentos innecesariosRetardos debidos al proceso de arquitectura


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Arquitectura de software ágilArquitectura que puede reaccionar a cambios en

entornoAdaptación a cambios continuousTambién conocidas como arquitecturas evolutivasBuena arquitectura permite agilidadMejor comprensión de decisiones y soluciones de

compromisoAnti-patrón común: adopción de técnicas de

desarrollo de software ágil que creanarquitecturas que no son ágilesCausado por demasiado enfoque en funcionalidad


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Leyes de la arquitectura del software1er ley:

Todo en arquitectura del software es una solución de compromiso

2ª ley:Porqué es más importante que cómo

Cuestionar todoDocumentar decisiones tomadas

Corolario 1:Si un arquitecto piensa que no ha encontrado algo que no sea una solución de compromiso, lo más seguro es que no ha identificado la solución de compromiso todavía

Corolario 2:Todas las decisiones significativas tienen desventajas

Fuente: Fundamentals of Software Architecture, M. Richards, N. Ford


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Proceso de diseñar una arquitectura

Dominio del problema Dominio de la solución

Actividad de diseño

Objetivos deDiseño

RequisitosFuncionales

Atributos deCalidad

Restricciones

Preocupaciones (Concerns)

Entradas

Arquitecto

Diseño de La arquitectura

(salida)


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Motivaciones proceso de arquitectura

EntradasObjetivos de diseñoRequisitos funcionalesAtributos de calidadRestriccionesPreocupaciones


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Objetivos de diseño

Aclarar porqué se diseña un sistemaEjemplos:

Propuesta pre-venta: diseño rápido de una solucióninicial para obtener una estimación

Sistema a medida con un tiempo y coste establecidoque no puede variar mucho una vez enviado

Incremento Nuevo ó versión de un sistema que estácontinuamente evolucionando


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Requisitos funcionalesFuncionalidad que debe soportar los objetivos de negocio

Lista de requisitos como casos de uso o historias de usuario

User storiesUse cases


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Atributos de calidadCaracterísticas medibles de interés para usuarios o

desarrolladoresTambién conocidos como requisitos no-funcionales

Rendimiento, disponibilidad, modificabilidad, testabilidad,…También conocidos como –idades (-ities en inglés)

Pueden especificarse mediante escenariosTécnica estímulo-respuesta

“Si ocurre un fallo interno durante la operación normal, el sistema reanuda la operación en menos de 30 segundos y no se pierden datos”

Priorizados por:El cliente de acuerdo al éxito del sistemaEl arquitecto de acuerdo al riesgo técnico

ISO 25010: lista de algunos requisitos no funcionalesLista: https://en.wikipedia.org/wiki/List_of_system_quality_attributes

https://en.wikipedia.org/wiki/List_of_system_quality_attributes


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Atributos de calidadLos atributos de calidad determinan la mayoría de las

decisiones de diseño en arquitecturaSi la única preocupación fuese la funcionalidad, un

sistema monolíticos sería suficienteSin embargo, es habitual ver:

Estructuras redundantes para fiabilidadEstructuras concurrentes para rendimientoCapas para modificabilidad…

Priorizados por:El cliente de acuerdo al éxito del sistemaEl arquitecto de acuerdo al riesgo técnico


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

RestriccionesRestricciones del sistema que vienen impuestas

Muy poco software tiene libertad totalPueden ser técnicas u organizativasPueden surgir del cliente o también de la organización

de desarrolloLimitan las alternativas a considerar para decisiones de

diseño particularesEjemplos:

Marcos de aplicaciones (frameworks)Lenguajes de programación, ...

Normalmente son tus “amigos”


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Preocupaciones

Decisiones de diseño que deben tomarse aunqueno estén enunciadas explícitamente en losobjetivos o requisitos

Ejemplos:Crear una estructura física o lógica consistenteValidar campos de entradaGestión de excepciones y loggingMigración de datos y backupOrganización del código fuente…


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Creatividad vs método

CreatividadDivertidoArriesgadoPuede ofrecer soluciones nuevasPuede ser innecesario

MétodoEficiente en terrenos familiaresResultado predecibleNo siempre es lo mejorTécnicas de calidad contrastada

Arquitecto


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Tipos de sistemasSistemas greenfield en dominios nuevos

Ejemplo Google, WhatsappDominios innovadores poco conocidos

Sistemas greenfield en dominios madurosEjemplo: aplicaciones empresariales tradicionales, aplicaciones móviles, …Dominios conocidos, menos innovadores

Dominios brownfieldCambios a sistemas existentes

Greenfield: no urbanizadoBrownfield: antigua zona industrial


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Arquitecto del software

La disciplina evolucionaArquitecto debe conocer:

Avances en técnicas de construcciónEstilos y patrones

Mejor herramienta = experiencia (no silver bullet)Experiencia propiaExperiencia de la comunidad

Arquitecto


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Papel del arquitecto de software

PrincipiosPatrones

EstilosAnti-patrones

Arquitectode SoftwareExperiencia

de la comunidad

Stakeholders

Tecnología

Arquitectura

ObjectivosRequisitos funcionales

Atributos de calidad

RestriccionesPreocupaciones

Arquitectura del Software Definiciones - GitHub Pages

Documents

Transcript of Arquitectura del Software Definiciones - GitHub Pages