monografia pipeline
TRANSCRIPT
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
1
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
2
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.
3
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.
4
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.
5
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.
6
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).
7
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.
8
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.
9
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 (n-
capas).
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.
10
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.
11
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.
12
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.
13
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
14
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.
15
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