Arquitecturas de software
Upcoming SlideShare
Loading in...5
×
 

Arquitecturas de software

on

  • 759 views

 

Statistics

Views

Total Views
759
Views on SlideShare
759
Embed Views
0

Actions

Likes
0
Downloads
29
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Arquitecturas de software Arquitecturas de software Presentation Transcript

  • Arquitectura de So ftware Dr. Pedro Mejia Alvarez Cova Suazo Nancy Noemí  Pérez Reséndiz Marisol CINVESTAV – IPN Sección de Computación
  • Capítulo 1Ciclo de la Arquitectura de Negocios
  • 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).
  • Architecture Business Cycle - ABCLos requerimientos no determinan del todo laarquitectura, más bien está es además resultado deinfluencias en los ambientes técnicos, sociales y delnegocio.Llamaremos a este ciclo de influencias, delambiente a la arquitectura y de la arquitectura alambiente como “El Ciclo de la Arquitectura deNegocios (Architecture Business Cycle - ABC)”.
  • ¿Cómo surgen las arquitecturas? Influencias en la Arquitectura
  • Stakeholders
  • INFLUENCIAS EN LAS ARQUITECTURAS La composición de la organización. La formación y la experiencia de los arquitectos. El ambiente técnico.
  • Las arquitecturas afectan alos factores que las influencian Ciclo de la Arquitectura de Negocios
  • Las arquitecturas afectan alos 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.
  • El Proceso de Software y ElCiclo 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
  • ¿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.
  • Reglas estructurales parala 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.
  • Capítulo 2Qué es una Arquitectura de So ftware ?
  • DEFINICIÓNUna Arquitectura de Sofware de un programa o deun sistema de cómputo es la estructura oestructuras de un Sistema. Dicha(s) estructura(s)comprenden: Elementos de software, Las propiedades visibles de dichos elementos, y Las relaciones entre los mismos.
  • Una arquitectura de software debe proporcionarcierta 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.
  • EJEMPLO. Representación de una Arquitectura deSoftware poco informativa. ELEMENTO 1 ELEMENTO 2 ELEMENTO 3 ELEMENTO 4
  • 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.
  • PATRONES DE ARQUITECTURAUn patrón de arquitectura es una descripción deelementos y los tipos de relación, junto con ungrupo de restricciones en cómo deben ser usados. Un ejemplo de este tipo, es la Arquitectura Cliente-Servidor.
  • MODELO DE REFERENCIAUn modelo de referencia es una descomposición deun problema en un cierto número de partes quecooperativamente resuelven el mismo.Ejemplos Partes de un Compilador. Partes de un Sistema manejador de Base de Datos.
  • ARQUITECTURA DE REFERENCIAEs un modelo de referencia planeado sobreelementos de software y el flujo de datos entreellos. Un elemento de software puede implementar parte de una función o de varias funciones.
  • 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.
  • 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.
  • 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.
  • Estructuras Módulos Componente-ConectorDescomposición Cliente- Clases Proceso Datos Servidor Uso Compartidos Concurrencia Capas Asignación Despliegue Asignación de Implementación Trabajo
  • Capítulo 7 Diseño de laArquitectura
  • La Arquitectura en el Ciclo de Vida Software Concept Ciclo de Vida de Entregas Evolutivas Preliminary Requirements Analysis Develop Final Version Design of Architecture and System Core Develop a Version Incorporate Deliver the Customer Version Feedback Ellicit Customer Feedbak
  • DISEÑO DE LA ARQUITECTURAAttribute-Driven Design (ADD), esta es unaaproximación basada en la recursiva descomposiciónde procesos, donde cada estado, tácticas y patronesarquitecturales son escogidos para satisfacer unconjunto de escenarios y entonces la funcionalidades asignada a módulos. La entrada a este métodoson todos los requerimientos funcionales, nofuncionales y las limitaciones del sistema.
  • Sistema de Puertas Automáticas para un GarageCUALIDADES 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
  • 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.
  • Escoger los patrones Arquitecturales User Interface Non-Performance Performance Critical Critical Computation Computation Virtual Machine Scheduler That Guarantees Deadlines Patrón Arquitectural que utiliza tácticas en el SAPG
  • Instanciar los módulos,asignar la funcionalidad a cada uno yrepresentarlos usando múltiples vistas. User Interface Diagnosis Raising/Lowering Obstacle Door Detection Communication Sensor/Actuator (Control) Scheduler That Virtual Machine Virtual Machine Guarantees Deadlines Primer nivel de descomposición del SAPG
  • 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.
  • 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.
  • 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.
  • Caso PrácticoSIMULACIÓN DE VUELOS
  • INTRODUCCIÓNLa creación y mantenimiento de estos sistemaspresentas 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 ModeloEstructural.
  • RELACIÓN CON LA ARQUITECTURA DEL NEGOCIO
  • REQUERIMIENTOS Y CUALIDADESSe 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.
  • ESTADOS DE EJECUCIÓNUn 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)
  • PROBLEMAS1. 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.
  • SOLUCIÓN Controles de Cabina Vehículo Aéreo Desplegados en cabina Sist. Visual TRIPULACIÓ Sist. de movimiento N Ambiente Sist. Auditivo Estación del InstructorModelo de Referencia para el Simulador de Vuelos
  • 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.
  • 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.
  • Módulos del Modelo de Ejecución Sincronizador del Tiempo Secuenciador periódico Manejador de Eventos Sustituto
  • 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.
  • 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