Arquitecturas de software

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

Transcript of Arquitecturas de software

Page 1: Arquitecturas de software

Arquitectura de So ftware

Dr. Pedro Mejia AlvarezCova Suazo Nancy Noemí Pérez Reséndiz Marisol

CINVESTAV – IPNSección de Computación

Page 2: Arquitecturas de software

Capítulo 1

Ciclo de la Arquitecturade Negocios

Page 3: Arquitecturas de software

. 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).

INTRODUCCIÓN

Page 4: Arquitecturas de software

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)”.

Architecture Business Cycle - ABC

Page 5: Arquitecturas de software

¿Cómo surgen las arquitecturas?

Influencias en la Arquitectura

Page 6: Arquitecturas de software

Stakeholders

Page 7: Arquitecturas de software

La composición de la organización.

La formación y la experiencia de los arquitectos.

El ambiente técnico.

INFLUENCIAS EN LAS ARQUITECTURAS

Page 8: Arquitecturas de software

Las arquitecturas afectan a los factores que las influencian

Ciclo de la Arquitectura de Negocios

Page 9: Arquitecturas de software

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.

Las arquitecturas afectan a los factores que las influencian

Page 10: Arquitecturas de software

Definir el caso de estudio para el sistemaEntender los requerimientosCrear o seleccionar la arquitecturaComunicar la arquitectura

Analizar y evaluar la arquitecturaImplementar el sistema basado en la arquitectura

Asegurar que la implementación sea conforme a la arquitectura

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

Page 11: Arquitecturas de software

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.

¿Qué hace buena a una arquitectura?

Una arquitectura debería ...

Page 12: Arquitecturas de software

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.

Reglas estructurales para la arquitectura

Page 13: Arquitecturas de software

Capítulo 2

Qué es una Arquitecturade So ftware ?

Page 14: Arquitecturas de software

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, yLas relaciones entre los mismos.

DEFINICIÓN

Page 15: Arquitecturas de software

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.

Page 16: Arquitecturas de software

ELEMENTO 1

ELEMENTO 2 ELEMENTO 3 ELEMENTO 4

EJEMPLO. Representación de una Arquitectura de Software poco informativa.

Page 17: Arquitecturas 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.

OTRAS DEFINICIONES DE LA ARQUITECTURADE SOFTWARE

Page 18: Arquitecturas de software

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.

Page 19: Arquitecturas de software

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.

EjemplosPartes de un Compilador.Partes de un Sistema manejador de Base de Datos.

Page 20: Arquitecturas de software

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.

Page 21: Arquitecturas de software

Comunicación entre las personas involucradasLa arquitectura representa una abstracción que puede ser base para el entendimiento, concenso, negociación y comunicación.

Decisiones tempranas de diseñoDefine 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.

POR QUÉ ES IMPORTANTE LA ARQUITECTURADE SOFTWARE ? (1)

Page 22: Arquitecturas de software

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.

POR QUÉ ES IMPORTANTE LA ARQUITECTURADE SOFTWARE ? (2)

Page 23: Arquitecturas de software

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.

ESTRUCTURAS Y VISTAS

Page 24: Arquitecturas de software

Estructuras

Módulos

Descomposición

Uso

Clases

Capas

Componente-Conector

Cliente-Servidor

Concurrencia

Proceso DatosCompartidos

Asignación

DespliegueImplementaciónAsignación de

Trabajo

Page 25: Arquitecturas de software

Capítulo 7

Diseño de la Arquitectura

Page 26: Arquitecturas de software

La Arquitectura en el Ciclo de Vida SoftwareConcept

Design of Architecture and

System Core

Develop aVersion

Ellicit Customer Feedbak

Incorporate Customer Feedback

Deliver the Version

Preliminary Requirements

Analysis

Develop Final Version

Ciclo de Vida de Entregas Evolutivas

Page 27: Arquitecturas de software

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.

Page 28: Arquitecturas de software

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

Sistema de Puertas Automáticas para un Garage

Page 29: Arquitecturas de software

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.

Pasos para realizar el diseño

Page 30: Arquitecturas de software

Escoger los patrones Arquitecturales

User Interface

Non-Performance Critical Computation

Performance Critical Computation

Scheduler That Guarantees Deadlines

Virtual Machine

Patrón Arquitectural que utiliza tácticas en el SAPG

Page 31: Arquitecturas de software

Instanciar los módulos, asignar la funcionalidad a cada uno y representarlos usando múltiples vistas.

Primer nivel de descomposición del SAPG

User Interface

Raising/Lowering Door

Obstacle Detection

Scheduler That Guarantees Deadlines

Diagnosis

Sensor/Actuator (Control) Virtual Machine

Communication Virtual Machine

Page 32: Arquitecturas de software

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.

Representación usando múltiples vistas

Page 33: Arquitecturas de software

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.

FORMAR EQUIPOS DE TRABAJO

Page 34: Arquitecturas de software

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.

Crear un esqueleto del sistema

Page 35: Arquitecturas de software

Caso Práctico

SIMULACIÓN DE VUELOS

Page 36: Arquitecturas de software

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.

INTRODUCCIÓN

Page 37: Arquitecturas de software

RELACIÓN CON LA ARQUITECTURA DEL NEGOCIO

Page 38: Arquitecturas de software

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.

Page 39: Arquitecturas de software

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)

Page 40: Arquitecturas de software

PROBLEMAS

1. Los costos para pruebas, cambios y eliminación de errores exceden los costos de desarrollo.

2. No es clara la planeación entre la estructura de software y la estructura de los simuladores.

Page 41: Arquitecturas de software

SOLUCIÓN

Modelo de Referencia para el Simulador de Vuelos

Vehículo Aéreo

Ambiente

Estación del Instructor

Desplegados en cabina

Sist. Visual

Sist. de movimiento

Sist. Auditivo

TRIPULACIÓN

Controles de Cabina

Page 42: Arquitecturas de software

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.

Page 43: Arquitecturas de software

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.

Page 44: Arquitecturas de software

Sincronizador del TiempoSecuenciador periódico

Manejador de EventosSustituto

Módulos del Modelo de Ejecución

Page 45: Arquitecturas de software

Controlador de SubsistemasPasa 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.

Módulos del Modelo de Aplicación

Page 46: Arquitecturas de software

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