Arquitectura en el proceso de desarrollo
Requisitos
-> Diseño ->Programación ->Test-> Mantenimiento
Diseño:
– Aclarar intenciones.
– Hacer explícitas las decisiones.
– Permitir análisis a nivel de
sistemas.
Mantenimiento:
Reducir
los costos de mantenimiento directa e indirectamente.
Arquitectura de Software
·
La arquitectura de un programa o sistema computacional
es la estructura o estructuras de ese sistema, y comprende las componentes del software, sus propiedades externamente visibles, y
las relaciones entre las mismas.
·
La arquitectura de software es un nivel de diseño diferente de los algoritmos y las estructuras de
datos.
“el
diseño y la especificación de la estructura del sistema como un todo es
entonces un nuevo problema.”
·
Los elementos estructurales incluyen:
o la organización y el
control globales,
o los protocolos de
comunicación,
o la distribución física,
o la composición de elementos
de diseño,
o la escalabilidad y el
rendimiento, y
o la elección entre distintas
alternativas de diseño.
Resumen:
• Un diseño de alto nivel.
• La estructura del sistema.
• Las componentes de un
programa o sistema,sus relaciones, y principios que gobiernan su
diseño y su evolución en el
tiempo.• Componentes y conectores.
• Componentes, conectores,
configuración y restricciones.
No hay una definición única…
¿Para qué la Arquitectura de Software?
·
Las personas necesitan pensar, diseñar, codificar, y
comunicarse en términos de
grandes
bloques conceptuales.Abstracción
·
Es necesario escapar de los desarrollos excesivamente
personalizados y estandarizar el diseño.Reutilización de patrones de arquitectura
·
Es necesario
diseñar sistemas de larga vida.Reutilización de
componentes particulares
·
Productividad en el desarrollo:actualmente solamente se reutiliza el
código y las estructuras de datos.
·
Atacar otros problemas del ciclo de vida del software:Modificabilidad, portabilidad,
escalabilidad,seguridad.
·
A medida que el tamaño del sistema crece, las soluciones
a estos problemas radican más en la arquitectura.
·
Tener un lenguaje
común para diseñadores, desarrolladores y usuarios.
Ciclo
de Vida de la Arquitectura
• Los objetivos de la organización influencian los requisitos.
• Los requisitos nos llevan a un diseño de arquitectura.
• La arquitectura da como resultado un sistema.
• Los sistemas construidos sugieren nuevas oportunidades para la
organización y nuevos requisitos.
Etapas de Desarrollo Basado en Arquitectura
1.
Hacer un caso de negocio para el
sistema
2. Comprender
los requisitos
3.
Crear o seleccionar una arquitectura
4.
Representar y comunicar la arquitectura
5.
Analizar o evaluar la arquitectura
6.
Implementar el sistema basado en la arquitectura
7.
Asegurar que la implementación se ajusta a la arquitectura
¿Cómo se hace una buena arquitectura?
• La
arquitectura debe ser producida por un solo arquitecto o un grupo
pequeño.
• El
arquitecto debe disponer de los requisitos técnicos del sistema y una lista
priorizada de propiedades cualitativas que se espera que el software satisfaga.
• La
arquitectura debe estar bien documentada usando
una notación acordada que todos los interesados puedan comprender con poco
esfuerzo.
• Se
debe facilitar la arquitectura a los interesados, los cuales deben estar involucrados
activamente en su revisión.
¿Cómo se hace una buena arquitectura?
·
La arquitectura debe analizarse para comprobar sus
medidas cuantitativas y propiedades cualitativas antes de que sea muy tarde
para cambiarla.
·
La arquitectura debe permitir crear un esqueleto de
sistema donde se reflejen todas las vías de comunicación pero con mínima
funcionalidad.
·
El diseño de la arquitectura debe dar como resultado un
conjunto específico de áreas críticas de consumo de recursos, cuya resolución
estará claramente documentada y mantenida.
¿Cómo es una buena arquitectura?
• Los
módulos deben diseñarse con el principio de separación de intereses
– distintos grupos de trabajo pueden
desarrollarlos independientemente
• La
información oculta incluirá todo aquello dependiente de la infraestructura
tecnológica.
• Cada
módulo tendrá una interfaz definida que oculta a los otros módulos los
aspectos cambiables.
• La
arquitectura no debe depender de una versión particular de un producto
comercial. De ser así, éste debe estar estructurado de modo que sea fácil y
barato cambiarlo.
¿Cómo es una buena arquitectura?
• Los
módulos que producen y los que consumen datos deben estar separados:
– esto
tiende a aumentar la mantenibilidad porque en general sólo una parte cambia.
• Cada
tarea o proceso debe describirse de modo que su asignación a un procesador
específico
pueda ser fácilmente cambiada, aún durante su ejecución.
• La
arquitectura debe seguir uno o unos pocos patrones de interacción:
– mayor
comprensión, menor tiempo de desarrollo, mayor confiabilidad, mayor
modificabilidad.
Importancia de la Arquitectura
•
comunicación entre las personas involucradas,
•
documentación temprana de las decisiones de diseño,
•
restricción de la implementación,
• la
arquitectura dicta la estructura organizacional,
•
facilita o inhibe propiedades del sistema,
•
permite predecir cualidades del sistema,
•
facilita la administración de la evolución,
• una
abstracción transferible del sistema,
• las
líneas de productos comparten arquitectura,
• base
para el entrenamiento de nuevo usuario.
Tenemos 2
vocabularios con focos complementarios:
Estructura: componentes y conectores
Propiedades: políticas y mecanismos
¿“Evaluable”?
¿“Manejable”?
Solución evaluable:
Debe permitir evaluar compromisos y opciones
• Por lo
tanto, debe tener rastreabilidad entre las partes de la solución y del
problema
• Proceso manejable: Debe ser particionada e indicar dependencias
•
Particiones: unidades naturales de asignación de
trabajo
•
Dependencias: la base para definir calendario
•
Solución
debe satisfacer requisitos
El arquitecto debe:
•
Describir un sistema
•
Describir un proceso para construirlo
• Una arquitectura debe ser más que una lista de
productos Y más que un mero modelo de componentes
Calidad de una
arquitectura
• Como se reconoce una
buena arquitectura?
Necesaria y
suficiente
Buena
arquitectura = buena descripción de buena solución
• 3 dimensiones clave
Efectiva: provee las funciones y propiedades
especificadas
Mínima: tiene las menos piezas posibles (“pocas
partes movibles”)
“Crece con uno”: anticipa mudanzas posibles y permite
trabajo futuro
Técnicas Rastreabilidad
• Noción fundamental de arquitectura
Rastreabilidad: poder
justificar una decisión en el contexto del documento
• Los modelos deben
proveer información
Refinamiento: explicado o
aparente (¿Contar una historia(Preguntar a kevin)?)
Capas: mapeables entre si
• Una buena arquitectura
“cuenta una historia” explicar no sólo el que y como, sino por qué permite
decisiones informadas a futuro
Resumiendo
• El papel del arquitecto...
Tiene sentido para proyectos y para organizaciones
Existe en un contexto de proceso y socios
Es fundamental para producir sistemas que
evolucionen y sean escalables
• Aplica a tecnología para
ayudar a una organización en un dominio
Representación de
arquitecturas
• Modelos del dominio vs.
modelos de software
• Refinamiento
–Refinamiento progresivo,
“contar una historia”
–Niveles de abstracción,
modelos en capas
• Vistas
–Vistas y perspectivas
–Vistas sincrónicas y
diacrónicas
–Booch, OMT, 4+1, RM
-ODP, Zachman
• UML, lenguajes de RM
-ODP, otras notaciones
•Architecture Description Languages
Vistas
•
Fuentes
de complejidad
–Imprecisión
–Intangibilidad
–Concurrencia en ejecución
–Concurrencia en construcción
–Diversificación
•
(Líneas
de productos)
–Tamaño
• Representación de un
(sub-)sistema...
–...parcial
–...basada en una
perspectiva
• Idea:
–participantes necesitan
razonar sobre el sistema
–entregar información que
suprima detalles irrelevantes
• Vista = representación de un conjunto de elementos del sistema y
relaciones asociadas con ellos (Clements)
• Perspectiva = preocupaciones propias de un participante
• Esquema de vistas = definiciones de vistas y perspectivas
asociadas
Estructuras y vistas
arquitectónicas
Las estructuras arquitectónicas
Pueden ser Divididas en 3 grupos fundamentales, dependiendo de la naturaleza De
sus elementos:
•
Estructuras de
Módulos
–Son unidades de
implementación.
–Se les asigna
responsabilidades funcionales.
–No interesa como se
manifiestan en tiempo de ejecución.
–Que funcionalidad se
asigna a que módulo?
–Que otros elementos de
software pueden ser utilizados por un módulo?
–Que elementos de software
son realmente utilizados por un módulo?
–Que módulos se relacionan
a partir de una generalización?
•
Estructuras de
Componentes y conectores
–Aquí los elementos son
Componentes (unidades principales de computo) y Conectores (medios de
comunicación entre los componentes).
–Los componentes y
conectores se manifiestan en tiempo de ejecución.
–Cuales son los
principales componentes ejecutables y como interactúan?
–Cuales son los
principales repositorios de datos?
–Que partes del sistema
están replicadas?
–Como fluyen los datos en
el sistema?
–Que partes del sistema se
ejecutan en paralelo?
Estructuras de Asignación
–Las estructuras de
asignación muestran la relación entre los elementos de software y los
elementos del ambiente o entorno en el cual el software es creado o ejecutado.
–En que procesador o
servidor ejecuta que elemento de software?
–Como se organizan los
elementos de software en el filesystem? En que archivos de código o proyectos
residen los elementos de software durante el desarrollo o el testing?
–Como se asignan los
elementos de software a equipos de desarrollo?
Usos de la Arquitectura
•Educación
–abstracta, fácilmente
entendible;
–familiarizar a las
personas con el sistema;
–nuevos miembros, nuevo
arquitecto, personas externas.
•Comunicación
–guía para la
construcción;
–base para la negociación
entre los distintos interesados;
–repositorio de decisiones
interrelacionadas.
•Análisis
–completa información para
analizar distintas características;
–distintos análisis
requieren distinta información:
•performance, seguridad,
usabilidad, disponibilidad, modificabilidad.
Tamaño de los Módulos
•“Un módulo es lo
suficientemente chico cuando, frente a un cambio, sería tan trabajoso modificarlo como recodificarlo.”
[Parnas86]
•Quien no es capaz de
estimar el tamaño y la complejidad del código de una componente no es
probablemente un arquitecto de software apropiado.
Interfaces
•Borde o límite (boundary)
a través del cual dos entidades independientes interactúan o se comunican
entre sí.
•Una interfaz es más que
un conjunto de servicios ofrecidos. ¿Qué más?
•La documentación de la
interfaz debe contener suficiente información para evitar interacciones
inesperadas, fruto de supuestos sobre el ambiente u otras entidades.
Vistas (views) o
Estructuras
•La arquitectura del
software es un artefacto complejo que no puede expresarse en una forma
simple y uni-dimensional.
•“Documentar una
arquitectura es documentar las vistas relevantes y luego agregar la
información que se aplica a más de una vista.”
•Una vista es la
representación de un conjunto de elementos del sistema y las relaciones
asociadas con los mismos.
•Las vistas usadas
dependen de las necesidades y el uso que se dará a la arquitectura.
-Vistas y Estilos
Tipos de Vistas
(viewtypes)
•Módulos
–estructura en términos de
unidades de implementación;
•Componentes y Conectores
(C&C)
–estructura en términos de
elementos interactuantes durante su ejecución;
•Allocation (distribución,
emplazamiento, asignación)
–relación entre el sistema
y las estructuras externas del ambiente.
•El tipo de vista limita
los elementos y relaciones que contiene una vista de ese tipo.
Estilos (styles)
•Un estilo de arquitectura
es una especialización de un tipo de vista que establece
–elementos y relaciones,
–una serie de
restricciones de cómo pueden usarse.
•Un estilo define una
familia de arquitecturas que satisface estas restricciones.
•La elección de un estilo
determina los elementos y las restricciones que habrá que documentar:
–guía del estilo.
•Estilo de capas
tipo módulo.
–El sistema tendrá ciertas
características de modificabilidad, portabilidad, independientemente del
contenido de los módulos.
•Estilo cliente
-servidor tipo C&C.
–Existen clientes,
servidores y protocolos,
–características como facilidad
para crear nuevos clientes.
•Los
estilos son especializaciones de los tipos de vistas, y las vistas son
instancias de un estilo para un sistema particular.
Mezcla de Estilos
•Distintas partes del
sistema pueden tener distintos estilos:
–hay elementos puente
entre las distintas vistas de cada estilo,
–generalmente mediante
distintas interfaces que le permiten interactuar con uno u otro estilo.
•Un elemento dentro de un
estilo está compuesto por elementos siguiendo otro estilo.
•Un mismo sistema puede
verse desde distintos puntos de vista como distintos estilos.
Módulos y Componentes
•Módulos
–unidades de diseño;
–encierran funcionalidad o
responsabilidad que se accede a través de una interfaz [Parnas72];
–no se replica;
–no interesa la ejecución.
•Componentes
–unidad de ejecución;
–tiene una interfaz
definida y accesible durante la ejecución;
–puede instalarse en forma
independiente;
–puede replicarse.
