Post on 08-Mar-2021
Cómo definir una buena arquitectura?
Agenda
• Aspectos para tener en cuenta al elaborar una arquitectura de software
• Ejemplos
• Una propuesta metodológica
• Algunos patrones arquitectónicos
Aspectos para tener en cuenta al elaborar una arquitectura de software
• Comprensibidad. – La arquitectura de software simplifica nuestra capacidad para
comprender grandes sistemas de sofware,
• Reuso. – Descripciones arquitectónicas contribuyen al reuso en múltiples
niveles. • Actualmente se utilizan en librerías de componentes
• Construcción. – Una descripción arquitectónica ofrece un blueprint para
desarrollo indicando los principales componentes y dependencias entre ellos
• Evolución. – Las arquitecturas de software pueden exponerlas dimensiones
sobre las cuales se espera se desarrolle.
GARLAN, David. Software Architecture: a roadmap. Carnegie Mello University
• Análisis. – Las descripciones arquitectònicas ofrecen nuevas
oportunidades para el análisis incluyendo la validación de consistencia, cumplimiento de limitaciones impuestas por el estilo arquitectónico
• Administración. – La experencia ha mostrado que los proyectos exitosos
ven en el mejoramiento de una arquitectura de software la clave para el desarrollo de software a nivel industrial.
GARLAN, David. Software Architecture: a roadmap. Carnegie Mello University
Aspectos para tener en cuenta al elaborar una arquitectura de software
1. Desarrollar un modelo mental de la aplicaciòn a un nivel alto. – Como si fuera una aplicaciòn pequeña...
… “ejemplo aplicaciòn de finanzas personales funciona al recibir o pagar dinero, en cualquier orden, controlado mediante una interfaz de usuario”.
2. Desglosar en las componentes requeridas.
– Buscar una cohesiòn alta y un acoplamiento bajo.
– Ejemplo: aplicaciòn de finanzas personales se desglosaen activos, proveedorese interfaz
3. Repetir este proceso para los componentes.
METODOLOGÍA PARA INICIAR LA SELECCIÒN DE LA ARQUITECTURA BÁSICA
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Descomponer en módulos auto contenidos.
2. Comparar con una arquitectura estándar (ej., Clasificación de Garlan y Shaw’s). Mejorar la descomposición. – Los datos fluyen en batch entre estaciones que los procesan?
• Flujo de datos batch secuencial
– Estaciones de procesamiento esperan los datos y entonces ejecutan?
• Flujo de datos pipe-and-filter
– Los procesos se ejecutan en paralelo?
• Procesadores que se comunican en paralelo
– Un proceso provee las necesidades de procesamiento de los usuarios?
• cliente-servidor
Seleccionar una Arquitectura (1)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
2. Comparar con una arquitectura estándar (ej., Clasificación de
Garlan y Shaw’s). Mejorar la descomposición (2).
– Un proceso únicamente reacciona a eventos que ocurren sobre él?
• Sistemas de eventos
– Cada ejecución es la interpretación de un script?
• interpretadores
– Es una aplicación centrada en un almacén de datos?
• repositorio
– Se agrupa en capas?
• En capas
Intente mínimo dos alternativas de arquitectura.
Seleccionar una Arquitectura (2)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
3. Evalué y seleccione una entre las alternativas identificadas.
4. Adicione las clases necesarias tomando como referencia el
análisis de requerimientos, que se ajusten a la arquitectura
seleccionada
– ej., flujo de datos: … controlar el flujo entre los elementos
– ej., sistemas de eventos: …controlar transiciones entre estados
5. Aplicar un framework existente y/o patrones de diseño.
– if a helpful one can be identified
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Seleccionar una Arquitectura (3)
6. Particionar las colecciones de clases en paquetes
– idealmente, 4-8 (paquetes anidados para aplicaciones muy grandes)
– Cada nombre de paquete debe tener significado en el lenguaje de la
aplicación (ej., “videos” está bien “grandes clases” no está bien)
7. Verificar alta cohesión en las partes; bajo acoplamiento entre las
partes, en otro caso ajustar la selección.
8. Considerar la introducción de un objeto/control Fachada para
controlar la interfaz de cada paquete
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Seleccionar una Arquitectura (4)
Metas de diseño
• Extensión – Facilitar la adición de nuevas características
• Cambio – Facilitar los cambios de requerimientos
• Sencillez – Hacerlo de fácil comprensión
– Hacerlo de fácil implementación
• Eficiencia – Lograr alta velocidad: ejecución y/o compilación
– Lograr un tamaño pequeño: tiempo en ejecutar y/o tamaño de código
Ejemplos
Una configuración física para un juego basado en Internet
Jugador m
Servidor de factiraciòn
de GameCorp
Jugador n
Clave:.
GUI
De encuentro
GUI
De encuentro
. . . .
Plataforma
De Hardware
Subsistema de
Software
Internet
Servidor
de encuentro
Maquina de
encuentro
Informador
de encuentro
Base de datos
de cuentas
Procesamiento
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Diagrama de un sistema de frenos de seguridad
Procesador de
control del auto
Clave :
Controlasor ABS
Hardware Subsistema de
Software
Sensor de
velocidad
Alerta de unbral
de velocidad
Unidad moduladora
de presiòn hidràulica
Luz de
advertencia
Controlador
de presiòn
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Cohesión y acoplamiento
1
2 3 4
5 6 Alta cohesiòn Bajo acoplamiento Puente
componente
componente
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Cohesión y acoplamiento 1
2 3 4
5 6 Alta cohesiòn
Bajo acoplamiento
Alto acoplamiento
Puente
componente
componente
componente
Soporte De acero
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
UNA PROPUESTA METODOLÓGICA
Arquitecturas de Software
Preparación
• Análisis
– Casos de Uso
– Mundo del Problema
– Requerimientos No funcionales
• Arquitectura de software
Aproximación funcional
• Los requerimientos funcionales son la guía para construir el modelo – Qué elementos aparecen referenciados en los RF y como deben
interactuar entre ellos?
• Se corre riesgo de definir arquitectura guiada por el problema
• Se construye diagramas de clase y diagrama de secuencia a la vez
AL FINAL DEL ANALISIS (1)
Tomado de Jorge Villalobos. Curso diseño de software basado en Patrones. Departamento de Sistemas y Comp. Universidad de los Andes
AL FINAL DEL ANALISIS
Tomado de Jorge Villalobos. Curso diseño de software basado en Patrones. Departamento de Sistemas y Comp. Universidad de los Andes
AL FINAL DEL ANALISIS
Tomado de Jorge Villalobos. Curso diseño de software basado en Patrones. Departamento de Sistemas y Comp. Universidad de los Andes
Definir arquitectura
• Conjunto de cajas grises • Debe tener en cuenta RNF, MN y RF • Debe ser completa • Se definen sobre este borrador los principales
“protocolos”
Tomado de Jorge Villalobos. Curso diseño de software basado en Patrones. Departamento de Sistemas y Comp. Universidad de los Andes
Refinar Arquitectura
• Ciclo de medición y refinación
• Aunque sea abstracta se debe poder explicar
Tomado de Jorge Villalobos. Curso diseño de software basado en Patrones. Departamento de Sistemas y Comp. Universidad de los Andes
Elementos de la Arquitectura
Tomado de Jorge Villalobos. Curso diseño de software basado en Patrones. Departamento de Sistemas y Comp. Universidad de los Andes
Se llega al diseño detallado
Tomado de Jorge Villalobos. Curso diseño de software basado en Patrones. Departamento de Sistemas y Comp. Universidad de los Andes
Qué es la arquitectura?
• Define las estructuras de alto nivel del sistema, en términos de:
– Componentes de software
– Las propiedades visibles de estos componentes (comportamiento y características)
– Relaciones entre ellos (conectores, protocolos, restricciones,...)
Tomado de Jorge Villalobos. Curso diseño de software basado en Patrones. Departamento de Sistemas y Comp. Universidad de los Andes
Corrientes principales
• Arquitectura estructural – SEI – Carnegie Mellon – Garlan, Shaw, Clements
– Variantes con modelos de datos (Medvidovic), radicales, formales (Moriconi-SRI), etc
• Arquitectura como etapa de la ingeniería de software orientada a objetos – James Rumbaugh, Grady Booch, Ivar Jacobson (“los 3…”), Craig Larman…
• Arquitectura basada en patrones – SEI – Redefinición de estilos como patrones POSA
– Microsoft Patterns & Practices
• Arquitectura procesual y metodologías – Kazman, Bass (SEI)
– Variantes de arquitectura basada en escenarios
Algunos patrones arquitectónicos
Estilos de arquitectura de software (Shaw & Garlan)
• Arquitecturas de flujo de datos
• Batch sequential
• Pipes and Filters
• Componentes independientes
• Procesos de comunicación paralela
• Sistemas Cliente-servidor
• Sistemas basados en eventos
• Maquinas virtuales
• Interpretadores
• Sistemas basados en reglas
• Arquitecturas de repositório
• Bases de datos
• Sistemas hipertexto
• Blackboards
• Arquitecturas de capas
Data Flow: Pipes and Filters
Couple Acquire To-XY Clip
Measure
Signal
Waveform Trace
Measurement
Dataflow pipe
filter Computation
Pipes and Filters
• Filtros – Transformar incrementalmente una cierta cantidad de datos de
entrada a la salida. • Transformaciones stream-a-stream
– Utilizar poco contexto local en el proceso corriente – No preservar ningún estado entre instanciaciones
• Pipe – Mover datos de la salida del filtro a la entrada del siguiente filtro – Pipes forman grafos de transmisión de datos
• Computación total – Correr pipes y filtros (no deterministicamente) hasta que no son
posibles más computaciones.
Repositorio orientado a los Datos (Blackboard)
Blackboard (shared
data)
ks1 ks2
ks3
ks4
ks5ks6
ks7
ks8
Acceso directo Computación
Memoria
El modelo Blackboard
• Fuentes de conocimiento
– El mundo y el conocimiento del dominio repartido en computaciones independientes
– Responder a los cambios en el blackboard
• Estructura de datos Blackboard
– Estado entero de la solución del problema
– Jerárquico, no homogéneo
– Solamente medios por los cuales las fuentes del conocimiento obran recíprocamente para conseguir la solución
• Control
– En el modelo, las fuentes de conocimiento son automáticas
Llamado-y-Retorno: Orientado a objetos
Llamado Proc
Gestor
obj es un manejador
op es una invocación
obj
obj
obj
obj
obj
obj
obj obj
op
op
op op
op
op op
op op
op
op
op
op op
op
op
Sistemas Llamada retorno
• Objetos
– Encapsular representaciones
– Proveer interfaces de acceso a servicios
• Conectores
– Llamado-retorno; servicio de invocación
• Razonamiento
– La corrección de un componente depende de la corrección de servicios que invoca .
Componentes débilmente acoplados: Invocación implícita
! !
! ! !
!
!
?
?
? ? ?
? ?
Invocación Implicita
Objeto o Proceso
Invocación-Implícita (Publicar-Suscribir)
• Componentes – Objetos, procesos – Tener un conjunto de métodos – Anunciar (publicar) eventos – via multicast – Suscribir a eventos por asociación de un procedimiento a un llamado
• Conector – Espacio del evento – Típicamente implementado como un despachador
• modelo Computacional – Cuando un evento es anunciado invoca procedimientos asociados (en
cualquier orden) – La corrección de un componente no debe depender de la corrección de los
componentes que suscriben a sus acontecimientos anunciados .
Cliente Servidor 3-Capas
Client-Server
Client-Server
Persistencia
Lógica de
negocio
Interfaz
Usuarios
Otros
• A menudo los estílos se usan en combinación
– Ejempo: Cada capa puede tener un estilo diferente internamente
– Ejemplo: un componente puede tener un subestuctura definida en un diferente estilo al que la rodea
• Muchos estilos se atan de cerca a los dominios específicos -- a menudo especializando un estilo más genérico
– Algunas veces llamados frameworks de integración de componentes
– Sistemas de N-capas
– Pila protocolo OSI
– Sistemas de instrumentación
• En muchos casos éstos se especializan a una familia de producto particular,
– Algunas veces llamados arquitectura de línea de producto
Estilo: CALL RETURN Subestilo: Sistema de capas
• Protocolos • Sistemas operativos • Front-end • Fachadas • proxies
Estilo: CALL RETURN Subestilo: Sistema de Objetos
• Componentes • Conectores • Distribuido o local
• Diseño por objetos • RMI • CORBA
SOAP • Object Oriented Middleware