Arquitectura de Software

1
Arquitectura de Software
2
La Disciplina.

• Subdiciplina de la Ingeniería de Software.
• Los problemas de diseño en grande son
  cualitativamente diferentes.
• Las arquitectura no es sobre pantallas ni
  funciones
• Mayor abstracción (compknentes independientes,
  pero partes de un todo).
• Se habla de componentes y propiedades.
• Propósito y audiencia
• No es como hacer software,
• Sino qué software hacer (o reusar o comprar).

3
Disciplina.

• Se deben tener en cuenta
• Requerimientos funcionales.
• Requerimientos no funcionales.
• Restricciones Arquitecturales.

4
Disciplina

• La arquitectura sirve como
• Medio de Educación (introducción al sistema).
• Vehículo de comunicación entre stakeholders
  (participantes e interacción).
• Base para el análisis del sistema (análisis de
  desempeño).

5
De qué hablan los arquitectos?

• Postura 1 arquitectos de grandes sistemas de SW
  piensan en macro-componentes
• Capas (layers)?
• Procesos y pipes
• Clientes y servidores
• Postura 2 piensan en políticas y mecanismos
• Tolerancia a fallas, rendimiento
• Replicación --gt balanceo de carga
• Tenemos 2 vocabularios con focos complementarios
• Estructura componentes y conectores
• Propiedades políticas y mecanismos

6
Definiciones más formales 1/2

• IEEE 1471
• Architecture is the fundamental organization of
  a system, embodied in its components, their
  relationships to each other and to the
  environment, and the principles guiding its
  design and evolution.
• IEEE 1471
• An architecture is the highest-level concept of a
  system in its environment

7
Definiciones más formales 2/2

• Alan Cooper
• Architects synthesize people, technology and
  purpose, to create a vision of a solution.
• PerryWolfe (via Boehm)?
• SW Arch. Elements, Forms, Rationale/Constraints
  
• Software architecture deals with the design and
  implementation of the high-level structure of
  software, by assembling architectural elements in
  well-chosen forms to satisfy functional and
  non-functional requirements (e.g. performance,
  scalability, portability, availability)?

8
Modelos.

• No todo diagrama es un modelo
• Modelo representación simplificada de la
  realidad
• que puede ser manipulada para comprender mejor la
  realidad
• idealmente predictiva
• Modelos requeridos en arquitectura de SW
• del dominio (el problema)?
• del sistema (software) (la solución)?
• del proceso (para construir el sistema)?
• Los stakeholders hacen lecturas diferentes
• ...pero complementarias
• ...y deben ser consistentes (!)?

9
Vistas de Arquitectura.

• De requisitos a arquitectura
• En general, no hay una solución óptima
• La solución escogida depende de compromisos entre
  los stakeholders
• Espacios de decisión para compromisos
  Hofmeister00
• Tecnológico
• Organizacional
• Producto
• Para justificar los compromisos hay que mirar la
  arquitectura desde diferentes perspectivas
• Desde la organización al desarrollo y despliegue

10
Tipos de vistas.

• Viewtypes Clements 2002
• Maneras simultáneas de pensar sobre sistemas de
  software
• Restringen los elementos y relaciones disponibles
  en sus vistas
• 3 maneras propuestas
• módulos
• estructura como conjunto de unidades de
  implantación
• componentes-y-conectores
• estructura como conjunto de elementos con
  comportamiento e interacciones durante ejecución
• allocation (asignación)?
• relación con estructuras no-software del ambiente

11
Viewtype Módulos

• Módulo unidad de código que implementa un
  conjunto de responsabilidades
• Ejemplos clase, colección de clases, capa
• Propiedades responsabilidades, visibilidad,
  autor
• Relaciones parte-de, hereda-de
• Estilos de representación
• Descomposición (en sistemas, subsistemas, etc.)?
• Uso (dependencias)?
• Capas

12
Viewtype ComponentesConectores.

• Expresa comportamiento en ejecución
• Elementos componentes y conectores
• Descomposición componentesconectores
• Estilos de representación
• Pipe and filter
• Cliente-servidor
• Deposito

13
Viewtype Asignación

• Mapeo de elementos de software a elementos del
  ambiente
• Estilos de representación
• Despliegue (deployment) (mapeo de procesos a
  hardware)?
• Implantación (módulos a infraestructura de
  desarrollo)?
• Asignación de trabajo (módulos a equipos de
  desarrollo)?

14
Notaciones para vistas.

• 2 grandes formas
• Gráfica
• UML, otros
• Formal
• Arquitecture Description Languaegs (ADLs)?

15
UML

• UML es 3 cosas
• Notación
• para describir cosas con orientación a objetos
• Meta-modelo de sistemas de software
• clases, subsistemas, componentes, nodos
• Mecanismo extensible
• para describir cosas usando orientación a objetos

16
Patrones de arquitectura

• Derivados de patrones de diseño
• Propuesta inicial Buschman et al.
• Categorías y conceptos diferentes del diseño
• Patrones de EAA (Enterprise Application
  Architecture)?
• Propuesta más detallada pero micro Fowler et
  al.
• Soluciones a problemas específicos de tecnologías
  3 capas modernas
• Patrones de EAI (Enterprise Application
  Integration)?
• Sistemas grandes heterogéneos distribuidos

17
Patrones de Buschman

• Categorías de patrones
• Estructurales
• Capas (layers)?
• Pipes Filtros
• Sistemas distribuidos
• Sistemas interactivos
• MVC Model-View-Controller

18
Diseño ArquitectónicoIntroducción

• Proceso
• Definir la estructura del sistema
• Se descompone el sistema en subsistemas
• Se define la comunicación entre estos
• Modelar el control
• Se establece un modelo que representa las
  relaciones de control entre las partes del
  sistema
• Descomposición modular
• Los subsistemas son descompuestos en módulos

19
Diseño ArquitectónicoIntroducción

• Observación
• Subsistema
• Sistema por sí mismo cuya operación no depende de
  los servicios suministrados por otros subsistemas
• Está compuesto por módulos e interfaces que se
  utilizan para la comunicación con otros
  subsistemas
• Módulo
• Componente del sistema que suministra uno o más
  servicios a otros módulos
• Utiliza los servicios suministrados por otros
  módulos
• No se considera como un sistema independiente

20
Diseño Arquitectónico.

• Diagrama de Clases.
• Modelo de Deposito.
• Modelo de Control.
• Modelo de Componentes y Conectores.

21
Diseño ArquitectónicoEstructuración del sistema

• Modelo del depósito
• Formas
• Los datos compartidos se ubican en una base de
  datos central donde pueden ser accedidos por
  todos los subsistemas
• Cada subsistema tiene su propia base de datos.
  Comparten información a través de mensajes

22
Diseño ArquitectónicoEstructuración del sistema

• Modelo del depósito
• Ventajas
• Eficiente para compartir grandes cantidad de
  datos
• Los subsistemas no deben preocuparse de cómo se
  produce o usan los datos
• Actividades de control, seguridad, respaldo se
  encuentran centralizadas

• Desventajas
• Rigidez. Los subsistemas deben acodar respecto
  del modelo de datos
• Evolución costosa, difícil o infactible
• Difícil distribución redundancia e
  inconsistencia de datos

23
Diseño ArquitectónicoModelos de control

• Control centralizado
• Un subsistema toma la responsabilidad de
  gestionar la ejecución de otros subsistemas
• Tipos
• Modelo de llamada-retorno
• Modelo de subrutinas top-down donde el control se
  inicia en las jerarquías superiores y desciende
  por medio de llamadas. Es aplicable sólo a
  sistemas secuenciales
• Modelo del administrador
• Un componente del sistema controla el inicio, la
  detención y la coordinación entre los procesos
  del sistema. Un proceso es un subsistema o módulo
  que se ejecuta en paralelo con otros procesos.
  Aplicable a sistemas concurrentes y secuenciales.

24
Diseño ArquitectónicoModelos de control
Modelo llamada retorno
25
Diseño ArquitectónicoModelos de control
Modelo de sistema de tiempo real
26
Diseño ArquitectónicoModelos de control

• Control basado en eventos
• Se rigen por eventos generados externamente, no
  por variables de estado del sistema
• Tipos
• Modelos de transmisión
• Un evento es transmitido a todos los subsistemas,
  quién pueda manejar el evento responde a él
• Modelos dirigidos por interrupciones.
• Utilizado exclusivamente en sistemas de tiempo
  real. La interrupción es detectada por un
  controlador de interrupciones y, después, otro
  componente se encarga de su procesamiento

27
Diseño ArquitectónicoModelos de control

• Control basado en eventos Modelo de transmisión
• Efectivos para integrar sistemas distribuidos a
  lo largo de una red de computadores
• Los subsistemas registran su interés en eventos
  específicos. Cuando el evento ocurre, el control
  es transferido al subsistema que puede manejar el
  evento
• La política de control no se encuentra en el
  administrador. Los subsistemas deciden cuáles
  eventos son de su interés
• Los subsistemas no saben si un evento será
  manejado, ni cuando

28
Diseño ArquitectónicoModelos de control
Modelo de transmisión
29
Modelo de Componentes.

• Descrito en UML 2.0
• Identificación inicial de la arquitectura.
• Contiene componentes, conectores y definición de
  interfaces.

30
Modelo de Componentes.

• Descripción de componente debe definir una
  abstracción precisa con una interfaz bien
  definida, y permitir reutilización.
• Los componentes se pueden organizar en paquetes.
• UML define cinco estereotipos estándar que se
  aplican a los componentes
• Executable que se puede ejecutar en un nodo.
• Library Biblioteca de objetos estática o
  dinámica.
• Table Componentes que representa una tabla de
  una base de datos.
• File Componente que representa un documento que
  contiene código fuente o datos.
• Document Componente que representa un
  documento.

31
Modelo de Componentes.

• Ejemplo.