Arquitectura de Software

1
Arquitectura de Software

• Dr. Pedro Mejia Alvarez
• Cova Suazo Nancy Noemí 
• Pérez Reséndiz Marisol
• CINVESTAV IPN
• Sección de Computación

2
Capítulo 1Ciclo de la Arquitecturade Negocios
3
INTRODUCCIÓN

• . La vista arquitectural de un sistema es
  abstracta, proporcionando detalles acerca de la
  implementación, los algoritmos, la representación
  de datos e incluso el comportamiento y la
  interacción entre elementos (cajas negras - black
  box).

4
Architecture Business Cycle - ABC

• Los requerimientos no determinan del todo la
  arquitectura, más bien está es además resultado
  de influencias en los ambientes técnicos,
  sociales y del negocio.
• Llamaremos a este ciclo de influencias, del
  ambiente a la arquitectura y de la arquitectura
  al ambiente como El Ciclo de la Arquitectura de
  Negocios (Architecture Business Cycle - ABC).

5
Cómo surgen las arquitecturas?
Influencias en la Arquitectura
6
Stakeholders
7
INFLUENCIAS EN LAS ARQUITECTURAS

• La composición de la organización.
• La formación y la experiencia de los arquitectos.
  
• El ambiente técnico.

8
Las arquitecturas afectan a los factores que las
influencian
Ciclo de la Arquitectura de Negocios
9
Las arquitecturas afectan a los factores que las
influencian

• La composición de la organización.
• Los objetivos de la organización.
• Los requerimientos del cliente.
• La experiencia de los arquitectos.
• Muy pocos sistemas influenciarán o cambiarán la
  cultura de la ingeniería de software, el ambiente
  técnico en el cual los sistemas operan y
  aprenden.

10
El Proceso de Software y El Ciclo de la
Arquitectura de Negocios (ABC)

• Definir el caso de estudio para el sistema
• Entender los requerimientos
• Crear o seleccionar la arquitectura
• Comunicar la arquitectura
• Analizar y evaluar la arquitectura
• Implementar el sistema basado en la arquitectura
• Asegurar que la implementación sea conforme a la
  arquitectura

11
Qué hace buena a una arquitectura? Una
arquitectura debería ...

• ser producto de un arquitecto o un pequeño grupo
  de arquitectos con un líder definido.
• estar bien documentada, con al menos una vista
  dinámica y una vista estática, utilizando una
  notación que los stakeholders puedan entender
  fácilmente.
• ser evaluada y analizada con métricas
  cuantitativas y cualitativas.
• presentarse como una implementación incremental,
  para poder diseñar un esqueleto del sistema,
  mostrando primero la mínima funcionalidad y
  después como puede ir creciendo.
• ser diseñada por arquitectos que cuentan con los
  requerimientos funcionales y no funcionales del
  sistema.

12
Reglas estructurales para la arquitectura

• La arquitectura debería tener bien definidos los
  módulos.
• Cada módulo debería tener bien definida las
  interfaces que encapsula. Estas interfaces
  permitirán desarrollar de manera independiente
  cada módulo.
• La arquitectura nunca debe de depender de una
  versión de un producto o herramienta comercial.
• Los módulos que producen datos deberán estar
  separados de los módulos que consumen datos. Esto
  permitirá que cuando un dato sea añadido solo
  tenga que modificarse un módulo.
• Cada tarea o proceso deberá ser bien documentado,
  para que este pueda ser fácilmente modificado,
  quizás incluso en tiempo de ejecución.
• La arquitectura deberá caracterizarse como un
  conjunto de simples interacciones, esto es para
  incrementar la confiabilidad, la manteneabilidad,
  reducir el tiempo de desarrollo, etc.

13
Capítulo 2Qué es una Arquitecturade Software ?
14
DEFINICIÓN

• Una Arquitectura de Sofware de un programa o de
  un sistema de cómputo es la estructura o
  estructuras de un Sistema. Dicha(s) estructura(s)
  comprenden
• Elementos de software,
• Las propiedades visibles de dichos elementos, y
• Las relaciones entre los mismos.

15

• Una arquitectura de software debe proporcionar
  cierta información
• La naturaleza de los elementos.
• Si los elementos son procesos, programas,
  objetos, etc.
• Las funciones de los elementos.
• El significado de las relaciones entre cada
  elemento.
• El significado de la distribución de los
  elementos.
• Por ejemplo. Elementos localizados en diferentes
  niveles.

16
EJEMPLO. Representación de una Arquitectura de
Software poco informativa.
17
OTRAS DEFINICIONES DE LA ARQUITECTURA DE SOFTWARE

• Arquitectura es un diseño de alto nivel.
• Arquitectura es la estructura general del
  sistema.
• Arquitectura es la estructura de componentes,
  relaciones, principios y pautas que definen su
  diseño y evolución sobre el tiempo.
• Arquitectura es componentes y conectores.

18
PATRONES DE ARQUITECTURA

• Un patrón de arquitectura es una descripción de
  elementos y los tipos de relación, junto con un
  grupo de restricciones en cómo deben ser usados.
• Un ejemplo de este tipo, es la Arquitectura
  Cliente-Servidor.

19
MODELO DE REFERENCIA

• Un modelo de referencia es una descomposición de
  un problema en un cierto número de partes que
  cooperativamente resuelven el mismo.
• Ejemplos
• Partes de un Compilador.
• Partes de un Sistema manejador de Base de Datos.

20
ARQUITECTURA DE REFERENCIA

• Es un modelo de referencia planeado sobre
  elementos de software y el flujo de datos entre
  ellos.
• Un elemento de software puede implementar parte
  de una función o de varias funciones.

21
POR QUÉ ES IMPORTANTE LA ARQUITECTURA DE SOFTWARE
? (1)

• Comunicación entre las personas involucradas
• La arquitectura representa una abstracción que
  puede ser base para el entendimiento, concenso,
  negociación y comunicación.
• Decisiones tempranas de diseño
• Define limitaciones en la Implementación.
• Dicta la Estructura Organizacional.
• Oculta o muestra los Atributos del Sistema.
• Hace más fácil controlar los cambios.
• Ayuda en el prototipado evolutivo.
• Proporciona Estimaciones de Costos y
  Calendarización más exactos.

22
POR QUÉ ES IMPORTANTE LA ARQUITECTURA DE SOFTWARE
? (2)

• Abstracción transferible de un sistema
• La arquitectura constituye un modelo de cómo esta
  el sistema estructurado y como sus elementos
  trabajan en conjunto por lo que puede ser
  aplicada a otros sistemas que exhiban similares
  requerimientos y atributos.

23
ESTRUCTURAS Y VISTAS

• VISTA. Representación de un conjunto de elementos
  y las relaciones entre ellos (escritos y leídos
  por clientes, usuarios, etc.).
• ESTRUCTURA. Conjunto de elementos que por sí
  mismos, existen en software o hardware.
• Se dividen en
• Módulos.
• Componentes-conectores.
• Estructuras de Asignación.

24
Estructuras
25
Capítulo 7Diseño de la Arquitectura
26
La Arquitectura en el Ciclo de Vida
27
DISEÑO DE LA ARQUITECTURA
Attribute-Driven Design (ADD), esta es una
aproximación basada en la recursiva
descomposición de procesos, donde cada estado,
tácticas y patrones arquitecturales son escogidos
para satisfacer un conjunto de escenarios y
entonces la funcionalidad es asignada a módulos.
La entrada a este método son todos los
requerimientos funcionales, no funcionales y las
limitaciones del sistema.
28
Sistema de Puertas Automáticas para un Garage

• CUALIDADES EN LOS ESCENARIOS
• los dispositivos y controles para abrir y cerrar
  la puerta
• los procesadores
• si se detecta un obstáculo, en el momento que se
  este cerrando la puerta, esta tendrá que
  detenerse y abrirse nuevamente en 0.1 segundos
• la puerta automática podrá ser checada y
  administrada desde el sistema de información
  casero, a través de un protocolo especifico

29
Pasos para realizar el diseño

• Escoger el módulo a descomponer.
• Refinar el módulo.
• Escoger los Drivers Arquitecturales.
• Escoger los Patrones Arquitecturales.
• Instanciar los módulos, asignar la funcionalidad
  a cada uno y representarlos usando múltiples
  vistas.
• Definir las interfaces de los módulos hijos.
  Documentar las interacciones y limitaciones entre
  cada módulo.
• Verificar y refinar casos de uso y escenarios.

30
Escoger los patrones Arquitecturales
Patrón Arquitectural que utiliza tácticas en el
SAPG
31
Instanciar los módulos, asignar la funcionalidad
a cada uno y representarlos usando múltiples
vistas.
Primer nivel de descomposición del SAPG
32
Representación usando múltiples vistas

• VISTA DE MÓDULOS (DESCOMPOSICIÓN).
• (VISTA DE COMPONENTE-CONECTOR) CONCURRENCIA.
• Dos usuarios haciendo cosas similares al mismo
  tiempo.
• Usuario ejecutando múltiples actividades
  simultáneamente.
• Encender el sistema.
• Apagar el sistema.
• Sincronización.
• (VISTA ESTRUCTURAS DE ASIGNACIÓN) IMPLEMENTACIÓN.

33
FORMAR EQUIPOS DE TRABAJO

• La estructura arquitectural repercute
  directamente en la formación de estos equipos,
  debido a que se elegirán dependiendo de la
  funcionalidad (dominio) de los módulos, es decir
  se organizarán tomando en cuenta a la gente más
  especializada o con mayores conocimientos en el
  área.

34
Crear un esqueleto del sistema

• Una vez que hemos diseñado la arquitectura del
  sistema y hemos formado los grupos de trabajo,
  tenemos todo lo necesario para poder hacer una
  implementación del sistema, el cual me permitirá
  estar interactuando con el cliente e ir
  realizando modificaciones sobre el mismo, hasta
  que se este en condiciones de entregar un
  producto final.

35
Caso Práctico
SIMULACIÓN DE VUELOS
36
INTRODUCCIÓN

• La creación y mantenimiento de estos sistemas
  presentas grandes retos de desarrollo
• Ejecución en tiempo real
• Modificabilidad (realizar cambios en los
  requerimientos)
• Escalabilidad (extender la funcionalidad)
• Integrabilidad (comodidad con la cual el
  desarrollo de elementos, incluyendo aquellos
  realizados por terceros, se pueden realizar
  sepradamente y finalmente juntarlos para
  satisfacer todos los requerimientos)
• El patrón creado para dicho sistema es un Modelo
  Estructural.

37
RELACIÓN CON LA ARQUITECTURA DEL NEGOCIO
38
REQUERIMIENTOS Y CUALIDADES

• Se tienen 3 roles
• Tripulación. El propósito es instruir al piloto y
  tripulación en cómo operar una nave aérea,
  ejecutar maniobras y responder ante ciertas
  situaciones en la vida real.
• Ambiente. Comprende la atmósfera, armas,
  amenazas, etc.
• Instructor. El instructor es responsable de
  monitorear el rendimiento de pilotos, así como de
  iniciar situaciones de entrenamiento (previamente
  contempladas o introducidas por el instructor).
  Cuenta conuna consola para monitorear las
  actividades, introducir funciones erróneas y
  controlar el ambiente.

39
ESTADOS DE EJECUCIÓN

• Un simulador de vuelos tiene diferentes estados.
• Operando (funcionamiento normal)
• Configuración (se realizan cambios a la sesión de
  entrenamiento)
• Detener (detiene la simulación)
• Repetición (usado para demostrar a la tripulación
  que fue lo que realizó durante la simulación)

40
PROBLEMAS

• Los costos para pruebas, cambios y eliminación de
  errores exceden los costos de desarrollo.
• No es clara la planeación entre la estructura de
  software y la estructura de los simuladores.

41
SOLUCIÓN
Modelo de Referencia para el Simulador de Vuelos
42
Tratamiento del Tiempo

• Existen dos maneras de controlar el tiempo en un
  simulador de vuelos.
• Control Periódico. Tiene un quantum fijo. Una
  simulación será capaz de mantener el tiempo de
  simulación y el tiempo real sincronizados tanto
  como cada proceso pueda avanzar su estado al
  siguiente periodo.
• Control Basado en Eventos.
• Agrega un evento a la cola de eventos.
• Mientras haya eventos, elegir el evento que tenga
  menor tiempo de simulación, se establece el
  tiempo del evento seleccionado y se invoca el
  proceso para dicho evento.

43
Patrón de la Arquitectura del Modelo Estructural

• Los componentes de dicho modelo al nivel más
  general son
• La parte de Ejecución. Maneja la coordinación de
  la sincronización entre procesos, la
  administración de eventos, integridad y
  compartimiento de datos.
• La parte de Aplicación. Maneja el cálculo de la
  simulación del vuelo. Sus funciones son
  implementadas por los subsistemas y sus hijos.

44
Módulos del Modelo de Ejecución

• Sincronizador del Tiempo
• Secuenciador periódico
• Manejador de Eventos
• Sustituto

45
Módulos del Modelo de Aplicación

• Controlador de Subsistemas
• Pasa datos para y desde otras instancias de
  controladores de subsistemas y a sus hijos.
• Controlador de hijos de los Subsistemas
• Pasa datos solamente para y desde sus padres.
  Pueden inicializarse con algún valor particular,
  pueden producir salidas anormales o reflejar una
  condición de malfuncionamiento.

46
Descomposición de Grupos y de Sistemas
La descomposición más general del modelo es el
grupo, los grupos se descomponen en sistemas y
los sistemas se descomponen en subsistemas. Estos
últimos proveen las instancias para los
controladores de los subsistemas. Uso de
Tablas n-Cuadros. Útiles para capturar la entrada
y salida de un módulo