Monografia pipeline

1,262
-1

Published on

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,262
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
31
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Monografia pipeline

  1. 1. UNIVERSIDAD NACIONAL DE TRUJILLO Facultad de Ciencias Físicas y Matemáticas Escuela Profesional de Ingeniería Informática “ARQUITECTURA PIPELINE” CURSO : Tópicos especiales en Metodología e Ingeniería de Software CICLO : VI PROFESOR : Díaz Pulido Arturo ALUMNA : Malpartida Aranda Vanessa Jaqueline TRUJILLO - PERU 2014
  2. 2. INDICE ÍNDICE…………………………………………………………………………….……1 DEDICATORIA…………………………………………………………………….…..2 INTRODUCCIÓN……………………………………………………………….……...3 I. Capitulo: Arquitectura de Software……………………………………….…….…...4 1.1 Antecedentes Históricos……………………………………………..…….…..4 1.2 Definición……………………………………………………………….….….6 1.3 Importancia de la Arquitectura de Software……………………………….…..7 1.4 Arquitecturas de Software………………………………………….……….…8 II. Capitulo: Arquitectura Pipeline…………………………………………..….....…...11 2.1. Antecedentes Históricos…………………………………..…………...…..….11 2.2. Definición……………………………………………………….…...…….....12 2.3. Ventajas y Desventajas…………………………………………...…….….....13 CONCLUSIONES………………………………………………………….….………14 REFERENCIAS BIBLIOGRÁFICAS…………………………………….….….……15 1
  3. 3. DEDICATORIA Primeramente a dios por haberme permitido llegar hasta este punto y haberme dado salud, ser el manantial de vida y darme lo necesario para seguir adelante día a día para lograr mis objetivos, además de su infinita bondad y amor. A mi familia por el apoyo brindado en todo momento, por la motivación constante que me ha permitido directa o indirectamente a realizar culminar este documento. A mi maestro por su apoyo constante ofrecido en este trabajo, por haberme transmitidos los conocimientos obtenidos y haberme llevado pasó a paso en el aprendizaje. 2
  4. 4. INTRODUCCION En el desarrollo de este estudio, se describirá en forma sucinta algunas arquitecturas de software representativas y señalado su breve reseña historia, una vez descrito las distintas arquitecturas, en la sección siguiente, se dedicará otro apartado para examinar de forma determinada la arquitectura de software pipeline (llamada también arquitectura basada en filtros). Como sabemos la arquitectura en pipeline consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior, con almacenamiento temporal de datos o buffering entre los procesos. 3
  5. 5. I. Capitulo: Arquitectura de Software 1.1 Antecedentes Históricos La Arquitectura de Software acostumbra remontar sus antecedentes al menos hasta la década de 1960, su historia no ha sido tan continua como la del campo más amplio en el que se inscribe, la ingeniería de software. Después de las tempranas inspiraciones del legendario Edsger Dijkstra, de David Parnas y de Fred Brooks, la Arquitectura de Software quedó en estado de vida latente durante unos cuantos años, hasta comenzar su expansión explosiva con los manifiestos de Dewayne Perry de AT&T Bell Laboratories de New Jersey y Alexander Wolf de la Universidad de Colorado. Cada vez que se narra la historia de la arquitectura de software, se reconoce que en un principio, hacia 1968, Edsger Dijkstra, de la Universidad Tecnológica de Eindhoven en Holanda y Premio Turing 1972, propuso que se establezca una estructuración correcta de los sistemas de software antes de lanzarse a programar, escribiendo código de cualquier manera. Dijkstra, quien sostenía que las ciencias de la computación eran una rama aplicada de las matemáticas y sugería seguir pasos formales para descomponer problemas mayores, fue uno de los introductores de la noción de sistemas operativos organizados en capas que se comunican sólo con las capas adyacentes y que se superponen “como capas de cebolla”. Inventó o ayudó a precisar además docenas de conceptos: el algoritmo del camino más corto, los stacks, los vectores, los semáforos y los abrazos mortales. De sus ensayos arranca la tradición de hacer referencia a “niveles de abstracción” que ha sido tan común en la arquitectura subsiguiente. Aunque Dijkstra no utiliza el término arquitectura para describir el diseño conceptual del software, sus conceptos sientan las bases para lo que luego expresarían Niklaus Wirth como stepwise refinement y DeRemer y Kron como programming-in-the large (o programación en grande), ideas que poco a poco irían decantando entre los ingenieros primero y los arquitectos después. Años más tarde, en 1975, Brooks, diseñador del sistema operativo OS/360 y Premio Turing 2000, utilizaba el concepto de arquitectura del sistema para designar “la especificación completa y detallada de la interfaz de usuario” y consideraba que el arquitecto es un agente del usuario, igual que lo es quien diseña su casa, empleando una nomenclatura que ya nadie aplica de ese modo. 4
  6. 6. Así mismo identificaba y razonaba sobre las estructuras de alto nivel y reconocía la importancia de las decisiones tomadas a ese nivel de diseño. También distinguía entre arquitectura e implementación; mientras aquella decía qué hacer, la implementación se ocupa de cómo. En la misma época, David Parnas, demostró que los criterios seleccionados en la descomposición de un sistema impactan en la estructura de los programas y propuso diversos principios de diseño que debían seguirse a fin de obtener una estructura adecuada. Parnas desarrolló temas tales como módulos con ocultamiento de información, estructuras de software y familias de programas, enfatizando siempre la búsqueda de calidad del software, medible en términos de economías en los procesos de desarrollo y mantenimiento. Aunque Dijkstra, con sus frases lapidarias y memorables, se ha convertido en la figura legendaria por excelencia de los mitos de origen de la Arquitectura de Software, Parnas ha sido sin duda el introductor de algunas de sus nociones más esenciales y permanentes. Uno de los acontecimientos arquitectónicos más importantes del año 2000 fue la hoy célebre tesis de Roy Fielding que presentó el modelo REST, el cual establece definitivamente el tema de las tecnologías de Internet y los modelos orientados a servicios y recursos en el centro de las preocupaciones de la disciplina [Fie00]. En el mismo año se publica la versión definitiva de la recomendación IEEE Std 1471, que procura homogeneizar y ordenar la nomenclatura de descripción arquitectónica y homologa los estilos como un modelo fundamental de representación conceptual. En el siglo XXI, la AS aparece dominada por estrategias orientadas a líneas de productos y por establecer modalidades de análisis, diseño, verificación, refinamiento, recuperación, diseño basado en escenarios, estudios de casos y hasta justificación económica, redefiniendo todas las metodologías ligadas al ciclo de vida en términos arquitectónicos. Todo lo que se ha hecho en ingeniería debe formularse de nuevo, integrando la AS en el conjunto. La producción de estas nuevas metodologías ha sido masiva, y una vez más tiene como epicentro el trabajo del Software Engineering Institute en Carnegie Mellon. Hoy se percibe también un conjunto de posturas europeas que enfatizan mayormente cuestiones metodológicas vinculadas con escenarios y procuran inscribir la arquitectura de software en el ciclo de vida, comenzando por la elicitación de los requerimientos. 5
  7. 7. 1.2 Definición Definición General: Es la serie de decisiones que debemos tomar al momento de implementar un sistema de software esto incluye componentes, principios y fundamentos entre otros, con sus responsabilidades y efectos que influyen en su respectivo desarrollo y la estructura del sistema. Debemos tener en cuenta el funcionamiento e interacción entre las partes del software y el hardware el cual nos forma un marco de referencia necesario para su correcto desarrollo e implementación. Otras definiciones “La arquitectura de software, tiene que ver con el diseño y la implementación de estructuras de software de alto nivel. Es el resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema.” (Philippe Kruchten) “La arquitectura de software de un programa o sistema de computación es la estructura o estructuras del sistema, las cuales comprometen elementos de software, las propiedades externamente visibles de esos elementos y las relaciones entre ellos” (Arlow and Neustad) “Toda la arquitectura es diseño, pero no todo el diseño es arquitectura. La arquitectura representa las decisiones de diseño significativas que le dan forma a un sistema. Donde lo significativo puede ser medido por el costo del cambio” (Grady Booch) “Es la organización fundamental de un sistema incorporada en sus componentes, en sus relaciones mutuas y el entorno, y los principios que guían su diseño y evolución” (IEEE Standard 1471-2000). “Uno de los aspectos que motivan el estudio en este campo es el factor humano, en términos de aspectos como inspecciones de diseño, comunicación a alto nivel entre los miembros del equipo de desarrollo, reutilización de componentes y comparación a alto nivel de diseños alternativos” (Kazman, 1996). 6
  8. 8. 1.3 Importancia de la Arquitectura de Software La arquitectura de software es de especial importancia ya que la manera en que se estructura un sistema tiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema. Ejemplos de atributos de calidad son el desempeño, que tiene que ver con el tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta introducir cambios en el sistema. Los atributos de calidad son parte de los requerimientos (no funcionales) del sistema y son características que deben expresarse de forma cuantitativa. La manera en que se estructura un sistema permitirá o impedirá que se satisfagan los atributos de calidad. Por ejemplo, un sistema estructurado de tal manera que una petición deba transitar por muchos componentes antes de que se devuelva una respuesta podría tener un desempeño pobre. Por otro lado, un sistema estructurado de tal manera que los componentes estén altamente acoplados entre ellos limitará severamente la modificabilidad. Curiosamente, la estructuración tiene un impacto mucho menor respecto a los requerimientos funcionales del sistema. Por ejemplo, un sistema difícil de modificar puede satisfacer plenamente los requerimientos funcionales que se le imponen. Además de los atributos de calidad, la arquitectura de software juega un papel fundamental para guiar el desarrollo. Una de las múltiples estructuras que la componen se enfoca en partir el sistema en componentes que serán desarrollados por individuos o grupos de individuos. La identificación de esta estructura de asignación de trabajo es esencial para apoyar las tareas de planeación del proyecto. Finalmente, los diseños arquitectónicos que se crean en una organización pueden ser reutilizados para crear sistemas distintos. Esto permite reducir costos y aumentar la calidad, sobre todo si dichos diseños han resultado previamente en sistemas exitosos. 7
  9. 9. 1.4 Tipos de Arquitecturas de Software La Arquitectura de Software es, a grandes rasgos, una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferenciamiento del detalle inherente a la mayor parte de las abstracciones". Según Paul Clements en 1996 publicó una lista sobre los tipos de arquitecturas de software más comunes, a continuación se describirá cada una de ellas. Arquitecturas de Pizarra En esta arquitectura hay dos componentes principales: una estructura de datos que representa el estado actual y una colección de componentes independientes que operan sobre él. En base a esta distinción se han definidos dos subcategorías principales del estilo: Si los tipos de transacciones en el flujo de entrada definen los procesos a ejecutar, el repositorio puede ser una base de datos tradicional Si el estado actual de la estructura de datos dispara los procesos a ejecutar, el repositorio es lo que se llama una pizarra pura o un tablero de control. Model-View-Controller Es un patrón de arquitectura de software que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello el Modelo Vista Controlador propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario. Este patrón de diseño se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento. 8
  10. 10. Arquitectura Basadas en Atributos La Arquitectura Orientada a Servicios es una arquitectura para diseñar y desarrollar sistemas distribuidos. Las soluciones SOA han sido creadas para satisfacer los objetivos de negocio las cuales incluyen facilidad y flexibilidad de integración con sistemas legados, alineación directa a los procesos de negocio reduciendo costos de implementación, innovación de servicios a clientes y una adaptación ágil ante cambios incluyendo reacción temprana ante la competitividad. Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda una forma bien definida de exposición e invocación de, lo cual facilita la interacción entre diferentes sistemas propios o de terceros. Arquitectura en Capas La arquitectura basada en capas se enfoca en la distribución de roles y responsabilidades de forma jerárquica proveyendo una forma muy efectiva de separación de responsabilidades. El rol indica el modo y tipo de interacción con otras capas, y la responsabilidad indica la funcionalidad que está siendo desarrollada. El estilo de arquitectura basado en capas se identifica por las siguientes características:     Describe la descomposición de servicios de forma que la mayoría de la interacción ocurre solamente entre capas vecinas. Las capas de una aplicación pueden residir en la misma maquina física (misma capa) o puede estar distribuido sobre diferentes computadores (ncapas). Los componentes de cada capa se comunican con otros componentes en otras capas a través de interfaces muy bien definidas. Este modelo ha sido descrito como una “pirámide invertida de re-uso” donde cada capa agrega responsabilidad y abstracción a la capa directamente sobre ella. 9
  11. 11. Arquitectura de Máquinas Virtuales La arquitectura de máquinas virtuales se ha llamado también intérpretes basados en tablas. De hecho, todo intérprete involucra una máquina virtual implementada en software. Se puede decir que un intérprete incluye un seudo-programa a interpretar y una máquina de interpretación. El seudo-programa a su vez incluye el programa mismo y el análogo que hace el intérprete de su estado de ejecución. La máquina de interpretación incluye tanto la definición del intérprete como el estado actual de su ejecución. De este modo, un intérprete posee por lo general cuatro componentes: 1. Una máquina de interpretación que lleva a cabo la tarea, 2. Una memoria que contiene el seudo-código a interpretar, 3. Una representación del estado de control de la máquina de interpretación 4. Una representación del estado actual del programa que se simula. El estilo comprende básicamente dos formas o sub-estilos, que se han llamado intérpretes y sistemas basados en reglas. Ambas variedades abarcan, sin duda, un extenso espectro que va desde los llamados lenguajes de alto nivel hasta los paradigmas declarativos no secuenciales de programación, que todo el mundo sabe que implementan un proxy (una especie de nivel de impostura) que encubren al usuario operaciones que en última instancia se resuelven en instrucciones de máquinas afines al paradigma secuencial imperativo de siempre. Arquitectura Basadas en Componentes La arquitectura basada en componentes consiste en una rama de la Ingeniería de software en la cual se trata con énfasis la descomposición del software en componentes funcionales. Esta descomposición permite convertir componentes pre-existentes en piezas más grandes de software. Este proceso de construcción de una pieza de software con componentes ya existentes, da origen al principio de reutilización del software, mediante el cual se promueve que los componentes sean implementados de una forma que permita su utilización funcional sobre diferentes sistemas en el futuro. Se debe entonces, para terminar de definir la arquitectura basada en componente, saber que es un componente de software. Un componente de software se define típicamente como algo que puede ser utilizado como una caja negra, en donde se tiene de manera externa una especificación general, la cual es independiente de la especificación interna. 10
  12. 12. II. Capitulo: Arquitectura Pipeline 2.1. Antecedentes Históricos Siempre se encuadra este estilo dentro de las llamadas arquitecturas de flujo de datos. Es sin duda alguna el estilo que se definió más temprano y el que puede identificarse topológica, procesual y taxonómicamente con menor ambigüedad. Se relaciona con las redes de proceso descriptas por Kahn hacia 1974 y con el proceso secuenciales comunicantes (CSP) ideados por Tony Hoare cuatro años más tarde. Ha prevalecido el nombre de tubería-filtros por más que se sabe muy bien que los llamados filtros no realizan forzosamente tareas de filtrado, como ser eliminación de campos o registros, sino que ejecutan formas variables de transformación, una de las cuales puede ser el filtrado. En uno de los trabajos recientes más completos sobre este estilo. Históricamente, los primeros compiladores operaban conforme a un estilo de tubería y filtro bastante puro, en ocasiones en variantes de proceso por lotes. A medida que los compiladores se tornaron más sofisticados, se fueron añadiendo elementos tales como tablas de símbolos, generalmente compartidas por varios filtros. El añadido de formas intermedias de representación, gramáticas de atributo, árboles de parsing de atributos, compilaciones convergentes a formatos intermedios y otras complicaciones y añadiduras, fueron haciendo que el modelo de tubo secuencial llegara a ser inadecuado para representar estos procesos, siendo preferible optar por otros estilos, como el de repositorio. 11
  13. 13. 2.2. Definición Es un término perteneciente a la ingeniería de software, y consiste en una cadena de elementos de procesamiento ordenados de tal manera que la salida de cada elemento es la entrada del siguiente. Suena complicado pero no lo es; el nombre quiere decir en español "tuberías", y el sistema es básicamente como el agua que circula por cañerías o tubos. En este caso el agua vendría a ser la información o los procesos. La arquitectura en pipeline consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior, con almacenamiento temporal de datos o buffering entre los procesos. Es una popular arquitectura que conecta componentes computacionales (filtros) a través de conectores, de modo que las computaciones se ejecutan a la manera de un flujo. Los datos se transportan a través de las tuberías entre los filtros, transformando gradualmente las entradas en salidas. Debido a su simplicidad y su facilidad para captar una funcionalidad, es una arquitectura ideal cada vez que se trata de demostrar ideas sobre la formalización del espacio de diseño arquitectónico, igual que el tipo de datos stack lo fue en las especificaciones algebraicas o en los tipos de datos abstractos. El sistema se percibe como una serie de transformaciones sobre sucesivas piezas de los datos de entrada. Los datos entran al sistema y fluyen a través de los componentes. En el estilo secuencial por lotes (batch sequential) los componentes son programas independientes; el supuesto es que cada paso se ejecuta hasta completarse antes que se inicie el paso siguiente. Garlan y Shaw sostiene que la variante por lotes es un caso degenerado del estilo, en el cual las tuberías se han vuelto residuales. 12
  14. 14. 2.3. Ventajas y Desventajas Una lista parcial extraída de La Facultad de Ingeniería de Montevideo presenta las siguientes ventajas y desventajas de la arquitectura Pipeline. Ventajas         Permite comprender el comportamiento de entrada /salida de un sistema como la composición del comportamiento de los filtros individuales. Facilita el mantenimiento y crecimiento. Permiten realizar análisis de ‘deadlock’ y rendimiento. Soporte de ejecución concurrente. Facilita la reutilización de transformaciones Es intuitivo Fácil agregar / quitar transformaciones Relativamente sencillo de implementar, a nivel concurrente o secuencial Desventajas  Frecuentemente tienden a una organización de procesamiento batch  No son buenos para aplicaciones interactivas.  Pueden complicarse al tener que mantener dos flujos separados pero relacionados.  Puede ser necesario agregar a los filtros conversión de datos de entrada y salida  Pérdida de performance e incremento de complejidad delos filtros.  Es difícil soportar interacciones basadas en eventos 13
  15. 15. CONCLUSIONES En la siguiente presentación podemos concluir que la arquitectura de software, con alrededor de 15 años de vida, ha emergido como una disciplina de gran importancia dentro de la ingeniería de software. Una arquitectura adecuada es pieza clave para lograr tanto los requerimientos funcionales como no funcionales de un sistema. Por otro lado, una arquitectura no adecuada puede ser catastrófica. La arquitectura también juega un papel importante en otros aspectos del desarrollo de software, como mejorar la comprensión de sistemas grandes y complejos, permite una mejor comunicación entre los diferentes interesado en el sistema además de eso mejora las posibilidades de reuso y proporciona planos para la construcción. Se concluye también la utilidad de Pipeline en sistemas operativos multitarea ya que ejecutan una serie de procesos de manera simultánea, los cuales son ejecutados luego de manera secuencial mediante un administrador de tareas dándoles diferente prioridad y capacidad de procesamiento. Es común verlo también en el desarrollo de programas para el intérprete de comandos, ya que se pueden concatenar comandos fácilmente con tuberías, es una arquitectura muy natural en el paradigma de programación funcional, ya que equivale a la composición de funciones matemáticas. 14
  16. 16. REFERENCIAS BIBLIOGRÁFICAS 1. REYNOSO, Carlos (2004). Introducción a la Arquitectura de Software. Universidad de Buenos Aires. Argentina 2. RAMOS, Juan Carlos (2004 - 2012). Diseño de Software basado en Arquitecturas 3. SHAW Mary, GARLAN David. (1996). Software Architecture, Perspectives on an Emerging Discipline. 4. Anónimo. (2007). Arquitectura de Software- Estilos de Componentes y Conectores. Paper 5. KICCILLOF, Nicolás. (2004). Estilos y Patrones en la Estrategia de Arquitectura de Microsoft. Universidad de Buenos Aires. Tesis. Argentina 6. ALLEN, Robert. (1997). A formal approach to Software Architecture. Technical Report. CMU-CS-97-144.1997 7. KAZMAN, Rick. (2001). Software Architecture. En Handbook of Software Engineering and Knowledge Engineering. World Scientific Publishing, 8. LEE, Yugi. (2013). Software Architecture – Pipe and Filter Model. Monografia 15

×